Designing Video Game Hardware in Verilog

Stephen Hugg est l’auteur d’un vieux jeux en shareware tournant sur Win95 nommé comet buster. C’est surtout un grand fan de rétro-gaming.

Or, à une époque les consoles de jeux fonctionnaient avec de la logique discrète à base de puces que l’on soudait sur un PCB pour réaliser le jeux. La seule horloge utilisée était l’horloge «pixel» de l’écran CRT qui servait à piloter le balayage du faisceau d’électrons sur le téléviseur.

Dans ce livre, l’auteur revisite l’architecture de ces vieilles consoles avec du Verilog. À l’époque ce langage n’existait pas, mais il est tout de même bien indiqué pour décrire les circuits de logique numérique qui étaient utilisés dans ces vieilles consoles de jeux.

L’ouvrage commence donc par un cours de Verilog avec les bases du langage. Puis il enchaîne sur les circuits de base utilisé à l’époque pour piloter un écran CRT. Avec les technique comme le slipping counter qui permettait d’économiser des portes logiques en jouant sur le compteur de ligne et de colonnes de l’écran pour déplacer une balle.

Le livre enchaîne ensuite sur l’architecture d’un processeur 8 bits puis d’un processeur 16bits.

Et pour que l’on puisse mettre la main à la pâte, un site internet permet de simuler les «programmes» décrit en verilog.

On peut donc tester en live tout les codes proposé dans le livre sur le site 8bitsworkshop.

Stephen Hugg n’en est pas à son coup d’essais en matière de livre sur les vieux jeux vidéo puisque ce livre est le troisième. Mais c’est le premier livre à parler d’architecture «électronique», les deux précédent parlaient surtout de programmation de jeux vidéo sur de vieille architecture.

C’est un excellent petit livre pour se mettre au Verilog de manière ludique. Et cela permet de se replonger dans l’histoire des vieux jeux vidéos.

Déballage du kit de développement Lichee Tang muni d’un FPGA Chinois Anlogic

La société chinoise SiPeed propose un kit de développement permettant d’évaluer le FPGA chinois EG4S20BG256 produit par Anlogic. Le kit peut être commandé pour une vingtaine de dollars sur le site de vente en ligne Seeed spécialisé dans les kits de développement en électronique «grand public».

Contenu du kit SiPeed coté FPGA
Contenu du kit Lichee Tang botto

Au branchement du kit Debian/Linux détecte un convertisseur USB-JTAG de chez Anlogic:

$ sudo dmesg -c
[30017.300586] usb 3-2: new full-speed USB device number 5 using xhci_hcd
[30017.441796] usb 3-2: New USB device found, idVendor=0547, idProduct=1002
[30017.441801] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[30017.441804] usb 3-2: Product: USB-JTAG-Cable
[30017.441807] usb 3-2: Manufacturer: Anlogic

L’environnement de développement est disponible en téléchargement (~100Mo) sous forme d’une archive rar ici. Sans comprendre pourquoi, unrar ne me la décompresse pas correctement (tous les fichiers dans le même répertoire ) avec la commande suivante :

$ unrar e ../TD_RELEASE_SEPTEMBER2018_RHEL.rar

Il faut, pour l’extraire, utiliser l’extracteur de gnome, puis mettre en exécutable le répertoire bin:

$ chmod +x bin/*

Et on peut ensuite lancer l’ide:

$ cd bin ; ./td -gui

La fenêtre suivante s’ouvre alors :

L’environnement de développement Tang Dynasty lancé sur Debia

C’est l’environement de développement le plus simple à installé que j’ai pu voir depuis que je bricole des FPGA. Même si la procédure d’installation est quand même étrange (un obscure .rar a télécharger puis à décompresser).

Pour synthétiser un premier design on va avoir besoin d’un minimum de documentation sur la schématique de la carte ainsi que sur le pinout du FPGA. On trouvera les schémas du kit en format pdf ici.

On trouve des exemples de code pour le kit sur github, notamment pour faire clignoter une led. La base du Hello World en électronique.

Pour tester la led qui clignote on crée un nouveau projet avec le fpga EG4S20BG256. On ajoute ensuite le source pour la led se trouvant dans le répertoire Tang_FPGA_Examples/0.LED/src/led.v

L’extension du fichiers de contrainte est en *.adc pour l’exemple de led le fichier se trouve dans le répertoire Tang_FPGA_Examples/0.LED/constraint/io.adc

Une fois les deux fichiers ci-dessus ajouté à notre projet on peut lancer la procédure complète pour générer le bitstream en double-cliquant sur l’icône «Generate Bitstream» dans l’encart «FPGA Flow» de l’ide.

La génération du bitstream est très rapide. Pour le télécharger ensuite dans le FPGA il faut bien sur que le kit soit connecté à l’usb.

Le configurateur se lance en allant dans le menu Tools -> Download.

Chez moi j’ai du lancer l’ide en sudo pour éviter un plantage fatal, à ce moment. Le configurateur se présente comme ci-dessous :

Il faut ajouter le fichier bitstream au moyen du bouton de gauche «Add» puis cliquer sur la ligne du tableur pour «dégriser» le bouton «run», qui permet de télécharger le bitstream pour configurer le FPGA.

Pour conclure, je pensais beaucoup plus souffrir à mettre en route ce kit à la documentation majoritairement en chinois. Mais la note de blog de JAEB et le projet d’exemples sur github m’ont beaucoup aidé à faire clignoter cette led tricolore rapidement. À l’avenir il faudra regarder si ce FPGA est vraiment nouveau ou si ça n’est pas une copie d’un constructeur bien connu. On doit pouvoir vérifier ça avec le bitstream généré.

Pour aller plus loin:

Sortie de la version 1.1 de Cocotb

La nouvelle vient de tomber sur la liste de diffusion: la version 1.1 de cocotb est sortie. C’est une grande nouvelle pour cette librairie python de cosimulation HDL. En effet, elle était bloquée dans sa version 1.0 depuis plus de 4 ans maintenant.

Mais les deux principaux mainteneurs travaillaient sur d’autres sujets et ne trouvaient plus le temps de s’occuper de ce projet. Malgré la communauté d’utilisateurs grossissante, les correctifs et les propositions d’améliorations restaient jusqu’ici lettre morte faute de temps pour eux de les relire.

Cette annonce de sortie d’une nouvelle version permet surtout au logiciel de sortir de sa torpeur. Les principaux développeur du projet ont réussi à s’organiser pour déléguer le développement et entrer dans un cycle vertueux de vérification/release.

Nous allons enfin pouvoir sérieusement écrire nos banc de tests en python et oublier les usines à gaz que sont UVM, UVVM et consorts. Tout en gardant notre logiciel de simulation HDL préféré, c’est toute la magie de la cosimulation.

2019, l’année de la libération des FPGA ?

En matière de liberté le monde du FPGA est resté dans les années 90. Une époque obscure où l’on cachait le mode de fonctionnement des logiciels, où il fallait signer des accords de non divulgation (NDA) avant de pouvoir simplement utiliser un logiciel. Une époque où l’on croyait encore que la sécurité par l’obfuscation était le summum de l’état de l’art pour sécuriser et protéger son logiciel et ses données. Mais il est possible que les nouvelles de sorties de nouveaux logiciels libre de fin d’année 2018 changent la donne.

Un FPGA est littéralement un champs de portes programmable. Le paysan-développeur ensemence son champs avec un fichier nommé «bitstream». Ce bitstream permet de configurer les liens entre les différentes portes logiques du FPGA et constituer ainsi un circuit électronique (numérique).

C’est ce fichier qui n’est documenté par aucun fabricant de FPGA.

Jusqu’à très récemment pour ses semailles, le développeur devait passer par le logiciel fourni par le fabricant pour générer son bitstream. À chaque modèle un logiciel spécifique, avec tous les défauts inhérent aux logiciels fermés :

  • Obligé d’utiliser un ordinateur et un système d’exploitation supporté officiellement par le fabricant (impossible de générer le bitstream sur un système embarqué ARM par exemple).
  • Grande difficulté à gérer les bugs du logiciels (et les bugs c’est vraiment pas ça qui manque)
  • Support aléatoire
  • Obligé de payer une licence pour les «gros» FPGA
  • Licence Gratuite pour les petits FPGA mais un système de gestion de ladite licence obligeant à être fliqué par le fabricant (serveur de gestion de licence, obligation d’identification, collectes de données personnelles, …) .

L’argument principale des fabricants est qu’ils risquent de perdre toutes crédibilités en matière de sécurité auprès des clients militaires. Et qu’ils risquent d’être plus facilement copié par les chinois (Même s’ils y a déjà des copies fabriquées en chine). Il a pourtant été démontré depuis longtemps qu’il est tout à fait possible de faire le reverse-engineering des bitstream. C’est notamment ce qu’avait fait en 2008 Jean-Baptiste Note et Éric Rannaud avec debit pour les FPGA de Xilinx. Mais c’est surtout ce qu’a fait Wolf Clifford en 2015 avec Icestorm pour servir notamment à son logiciel de synthèse Yosys en utilisant une plate-forme réel : les ice40 de Lattice.

Ce «déverrouillage» des ice40 a permis une véritable révolution dans le domaine du FPGA chez les bidouilleurs. Beaucoup de cartes électroniques utilisant un ice40 on vu le jours, et le projet à fédéré tout un tas de nouveau projet de logiciels libre.

À l’origine, icestorm permettait de faire la synthèse avec yosys (transformer du verilog en netlist), le placement routage avec arachne-pnr (placer les différentes portes dans le FPGA et les relier entre elles) ainsi que la génération du bitstream avec icestorm (icepack).

Un fois le bitstream généré il est nécessaire de vérifier que les temps de propagation entre les différentes portes soient inférieur au cycle d’horloge. Il est donc nécessaire de posséder la spécification des temps de propagation entre les portes dans le FGPA. Chose qui a également été faite dans le projet Icestorm (icetime).

Le problème qui persistait avec cette chaîne de développement était arachne-pnr qui ne prenait pas en compte les timings du FPGA pour faire son placement routage. C’est ce verrou qui vient de sauter fin 2018 avec la sortie du nouveau logiciel de placement routage nextpnr initié par Clifford mais fédérant une communauté de développeurs de plus en plus grosse.

En plus de faire du placement routage en fonction des temps de propagations, nextpnr possède une interface graphique permettant une visualisation du FPGA une fois le projet routé.

Vue de l'interface graphique de nextpnr
Vu de l’interface graphique de nextpnr (source github officiel)

Tous ces outils sont désormais regroupés dans un projet opensource ayant pour objectif de réaliser un IDE complet pour les FPGA et nommé SymbiFlow.

Le projet SymbiFlow a pour objectif de devenir le «GCC du FPGA et des ASIC». En plus de icestorm, SymbiFlow intègre d’autres projets de «reverse-bitstream», notamment:

  • icestorm: déjà longuement décrit dans cet article, permet de faire un développement complet avec des outils opensource.
  • X-Ray: Projet de rétro-ingénierie des FPGA de la série 7 de xilinx. Les «tuiles standard» de ces FPGA sont déjà bien documenté et il est possible de générer un bitstream pour des Artix 7.
  • Trellis: Projet de rétro-ingénierie des FPGA ECP5 de Lattice. Toute la matrice a été documenté, et il est désormais possible de faire un projet pour ECP5 de bout en bout avec des outils open-source.
  • 2064: Projet de rétro-ingénierie des FPGA XC2064 de xilinx. Bon ce projet peut être considéré comme annecdotique puisque il vise à reverser le premier fpga de Xilinx du début des années 80 : le xc2064.

Le projet SymbiFlow est un projet encore «en travaux» mais il permet de tracer une voie et fournir des outils permettant de faire la retro-ingénierie d’autres FPGA. Comme on le voit dans les différents projets intégrés il est possible de voir fleurir d’autre projets de retro-ingénierie de FPGA et voir émerger une solution opensource solide pour développer sur FPGA.

L’année 2018 s’est terminée en fanfare avec la présentation de nextpnr au 35c3. L’année 2019 sera-t-elle celle de la libération des FPGA avec une fédération des projets de rétro-ingénierie de tous les FPGA du Marché ? Un fabricant de FPGA osera-t-il publier la documentation des ses bitstream pour ses FPGA ? Vera-t-on l’émergence de nouveaux acteur du FPGA faisant du libre ?

Vous saurez tous cela en suivant le prochain épisode de l’année 2019 !

2018, l’année de la libération des processeurs ?

2018 aura été l’année du Risc-V. Ce jeux d’instructions libre existait bien sûr avant 2018 puisqu’il a été fondé en 2010, mais c’est véritablement en 2018 qu’il aura pris son envol.

Entendons nous bien, le Risc-V pour Reduced Instructions Set Computing version V n’est pas un microprocesseur. C’est une définition du jeux d’instructions ainsi que des registres internes du processeur. Bref cela doit être vu comme une standardisation open-source du langage d’un processeur. Libre aux fondeurs de développer leurs architectures de processeur compatible Risc-V. Il définit les instructions assembleur et leurs formats (encodage) mais il ne définit pas le nombre d’étages de pipelines, comment est géré la prédiction de branche ni le format de bus de données et d’instructions. Tout cela relève de l’implémentation.

Cette standardisation du jeux d’instructions intéresse beaucoup de créateurs de microprocesseurs. En effet, plus besoin d’adapter ou d’écrire les outils logiciels pour son processeur; comme c’est un standard il suffit d’utiliser les «toolchains» classique comme GCC OpenOCD ou LLVM qui bien sûr l’intègre désormais, mais également toutes une série d’outils non libres. Linux n’est pas en reste puisqu’il intègre complètement l’architecture dans ses versions récente. C’est également le cas des petits OS temps réel comme Zephyr .

C’est, entre autre, cette disponibilité des outils qui a poussé de nombreux labo à basculer leurs processeurs sur ce jeux d’instructions. On pense notamment à :

  • PULP (Parallel Ultra Low Power ): Une architecture multi-core pour l’embarqué développé par l’université de Zurich. Utilisé par les processeur GAP8.
  • Patmos: le processeur temps réel
  • Shakti: De l’université indienne de madras
  • …: certainement plein d’autre

Il existe une tripotée de processeur Risc-V «soft» que l’on peut synthétiser dans des FPGA. Mais, à ma connaissance, le premier composant silicium sortie des chaînes de fabrication de fondeurs est le E310 de la société SiFive. Ce composant est sorti en 2017 et il est possible d’acheter un kit de développement «compatible arduino» pour se faire la main dessus.
Le E310 est un microcontrôleur 32bits, qui a fait un peu parler de lui quand il est sorti mais qui reste un démonstrateur. La société SiFive souhaitant rester une entreprise «fabless».

Mais c’est véritablement en 2018 que les choses se sont accélérées avec le ralliement de grands noms de l’industrie électronique à la fondation Risc-V et la sortie de nombreux processeurs «en silicium» bien concret.

On pensera notamment à:

  • U540: Hifive Unleashed de la société SiFive (encore ;). Un quad core RV64G plus un core RV64I pour la supervision temps réel. SiFive à sortie un kit de développement permettant d’y faire tourner un Linux compatible desktop.
  • GAP8: de greenwave technologie, un processeur PULP de 8 cores pour l’IoT.
  • K210: de Kendryte, un microcontrôleur chinois dual core RV64I
  • RV32M1: de NXP (hé oui ! j’en suis le premier étonné) un microcontrôleur très spécial puisqu’il contient un core RV32I mais également deux cores ARM cortex-M0 et M4. Il ne manque plus que le MIPS pour avoir un beau pot-pourri des proc RISC du marché 😉

Toutes ces sorties ont commencées à faire très peur aux concurrents, et notamment à son concurrent principale : ARM. Qui a tenté une campagne de dénigrement de Risc-V avant de très vite se raviser et de lancer une timide «riposte» avec un partenariat Xilinx pour fournir gratuitement des cortex-Mx dans les FPGA de Xilinx.

Mais Risc-V a également fait bouger l’autre concurrent beaucoup moins connu : MIPS qui lui a … libéré son set d’instructions !

Risc-V reste pour l’instant dans le domaine de l’embarqué et du microcontrôleur, mais la fondation a clairement l’intention de couvrir les domaines des calculateurs et autres mainframes. Domaine où MIPS est déjà un peu plus installé.

Risc-V arrivera-t-il à gagner la bataille des supercalculateurs ? ARM adoptera-t-elle le set d’instructions Risc-V ? Intel sentira-t-il le roussi quand Risc-V viendra le titiller sur ses plate-bandes ? MIPS reviendra-t-il dans la course avec son ouverture en open-source ? Des questions auxquels nous pourrons peut-être répondre en 2019. Un combat qui promet d’être passionnant.

Mais une chose est sûr, en 2018 l’opensource a fait une grande avancée dans le domaine des processeurs grâce à ce set d’instruction de l’université de Berkeley !

Comme j’aimerai voir ça dans le domaine des FPGA 😉



Installing Libero on Debian 9

This is just an install success story of Libero on Debian 9 (stretch).  For the Risc-V contest, I recently acquired the Microsemi IGLOO2 development kit named FUTUREM2GL-EVB  distributed by Futur-Electronic.

The development software for the IGLOO2 is named Libero and according to Microsemi, should works on Linux. But officially support only RedHat, CentOS and SuSE … not Debian. Microsemi provide a Linux installation guide to install it. It’s useful but should be adapted for Debian.

Download and install Libero

The first thinks to do is to download the installing file for Linux (and not the SP1 file which is only an update).  Once downloaded we just have to launch it, if it’s not executable we can change rights with chmod command.

$ chmod 666 Libero_SoC_v11.9_Linux.bin
$ ./Libero_SoC_v11.9_Linux.bin

An install windows will raise and we can follow directives.

Licensing

Once installed, we need to install the license. For that, we need to know our mac address :

$ ip addr show dev eth0
[...]
link/ether 12:34:56:78:9a:bc [...]

The key that should be given to Microsemi is in upper case without ‘:’ :

$ ipython

In [1]: "12:34:56:78:9a:bc".replace(':','').upper()                                                                                                                                                             
Out[1]: '123456789ABC'

With this key we can then ask for a license file on microsemi website. The official Linux guide talk about license.dat file, but for me it was license.zip … Both are zip file in fact. We can then unflat it with unzip command:

$ unzip License.zip 
Archive:  License.zip
  inflating: License.dat

The unflated file is a text file that should be edited with you text edito as explained in guide (page 6).

License server

The license server deamon must be downoaded on official microsemi website. Choose «Linux deamon» in table. It’s an archive of several binaries that should be unflated :

$ cd
$ tar -zxvf Linux_Licensing_Daemon.tar.gz
Linux_Licensing_Daemon/
Linux_Licensing_Daemon/actlmgrd
Linux_Licensing_Daemon/lmgrd
Linux_Licensing_Daemon/lmhostid
Linux_Licensing_Daemon/lmutil
Linux_Licensing_Daemon/mgcld
Linux_Licensing_Daemon/snpslmd
Linux_Licensing_Daemon/syncad
Linux_Licensing_Daemon/synplctyd

Export shell variables

Before launching software, we have to export some paths in our .bashrc :

#Libero 
LIBERO_LICENSE_FOLDER=/home/giselle/flexlm
LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/:/usr/lib/x86_64-linux-gnu/
# For Floating License from a License Server
export LM_LICENSE_FILE=1702@gisellelaptop:$LM_LICENSE_FILE
export SNPSLMD_LICENSE_FILE=1702@gisellelaptop:$SNPSLMD_LICENSE_FILE
# <1702> is the port number
# martonilp is the license server host name
#For Node-Locked License
export LM_LICENSE_FILE=$LIBERO_LICENSE_FOLDER/license.dat:$LM_LICENSE_FILE
export SNPSLMD_LICENSE_FILE=$LIBERO_LICENSE_FOLDER/license.dat:$SNPSLMD_LICENSE_FILE
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib
export DISPLAY=:0
export PATH=/opt/microsemi/Libero_SoC_v11.9/Libero/bin:$PATH

On my computer, Microsemi softwares are installed in /opt/ directory.

Launching Libero

First launch license server :

$ cd
$./flexlm/lmgrd -c ~/flexlm/License.dat -log /tmp/lmgrd.log

Once license server launched we can run Libero :

$ libero
/opt/microsemi/Libero_SoC_v11.9/Libero/bin/libero_bin: /opt/microsemi/Libero_SoC_v11.9/Libero/lib/libz.so.1: no version information available (required by /usr/lib/i386-linux-gnu/libpng16.so.16)

I had a little problem with libz provided with libero package, then I removed it and linked libz of my distribution :

$ apt-file search libz.so
lib32z1: /usr/lib32/libz.so.1
lib32z1: /usr/lib32/libz.so.1.2.8
lib32z1-dev: /usr/lib32/libz.so
zlib1g: /lib/x86_64-linux-gnu/libz.so.1
zlib1g: /lib/x86_64-linux-gnu/libz.so.1.2.8
zlib1g-dev: /usr/lib/x86_64-linux-gnu/libz.so
...
$ cd /opt/microsemi/Libero_SoC_v11.9/Libero/lib
$ mv libz.so.1 oldlibz.so.1
$ ln -s /lib/x86_64-linux-gnu/libz.so.1 libz.so.1

And then managed to launch it :

$ libero

Hurrah \o/ that works

But it’s unfortunately not finished.

First, when I tryied to synthesize I had this message in error window :

/opt/microsemi/Libero_SoC_v11.9/Synplify/bin/synplify_pro: 137: [: unexpected operator
/opt/microsemi/Libero_SoC_v11.9/Synplify/bin/synplify_pro: 151: [: !=: argument expected
/opt/microsemi/Libero_SoC_v11.9/Synplify/bin/synplify_pro: 324: /opt/microsemi/Libero_SoC_v11.9/Synplify/bin/config/execute: Syntax error: "(" unexpected (expecting ";;")

The problem come from the shell Debian uses by default :

$ ls -lha /bin/sh
lrwxrwxrwx 1 root root 4 oct.  29 20:50 /bin/sh -> dash

This shell doesn’t work like bash and generate some error in synplify scripts. To solve it I simply changed the /bin/sh link to /bin/bash :

$ cd /bin/
$ sudo mv sh shold
$ sudo ln -s bash sh

And I managed to synthesize my design.

But it’s not finished ! Once my bitstream generated I would like to download it on the IGLOO2 on kit. For that, we have to install correctly drivers for FlashPro5.
Directives are given in the official Microsemi Linux install guide, but udev syntax is false on Debian :

BUS=="usb",SYSFS{idProduct}=="2008",SYSFS{idVendor}=="1514",MODE="0660",GROUP="",SYMLINK+="FlashPro5"
BUS=="usb",SYSFS{idProduct}=="6001",SYSFS{idVendor}=="0403",MODE="0660",GROUP="",SYMLINK+="FTDI232"

Right rules are following :

# FlashPro5
SUBSYSTEM=="usb", ATTR{idVendor}=="1514", ATTR{idProduct}=="2008", MODE="0666", GROUP="plugdev"
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", MODE="0666", GROUP="plugdev"

Should be written in /etc/udev/rules.d/70-microsemi.rules file.

Then fully works  and they lived happily and urged a lot of children

Sortie de Yosys Open Synthesis Suite 0.8

L’annonce a été faite mardi 16 octobre par W. Clifford : La version 0.8 de Yosis, un logiciel libre de synthèse Verilog est sortie.

Dans le process de développement FPGA/ASIC la synthèse est l’étape de conversion du modèle matériel simulé en « netlist RTL » d’où l’on peut dériver le circuit réel.

[La suite sur Linuxfr …  ]

Verilator 4.002

La version 4.002 de Verilator a été annoncée à la conférence ORConf2018 en Pologne.

Verilator est sans conteste le simulateur HDL open source le plus rapide du « marché ». Il permet de simuler des porte‐grammes écrits en Verilog synthétisable.

Le nouveau logo de Verilator

La suite sur la dépêche linuxfr

Computer Organization and Design RISC-V Edition

La référence en matière de livre sur l’architecture des processeurs. Tout y passe, l’arithmétique binaire, le langage assembleur, le datapath (le core d’un processeur), les pipelines et les différentes méthodes de prédiction de branches, les différentes architecture multicore, les GPU/VPU, la hiérarchie des mémoires, …

David A.Patterson est une superstar dans le milieu c’est lui qui est à l’origine de l’architecture de type «RISC». Et avec cette édition nous avons droit à une description fine du jeux d’instructions libre RISC-V très à la mode aujourd’hui. Tout en parlant principalement du RISC-V, le livre n’oublie pas les autres architectures célèbre comme x86, arm ou mips.

Le livre parait cher, mais vous en aurez pour votre argent tant le contenu est dense.

Et pourquoi pas portegramme ?

Quand on fait du code pour un FPGA/ASIC il est difficile de nommer la chose développée. On ne réalise pas un programme puisque ça n’est pas une suite d’instructions exécutées par un processeur. Au contraire même on peut réaliser un processeur avec le code que l’on est en train de développer.

Pour nommer cette chose on va souvent parler d’IP pour «Intellectual Property», ce qui est vraiment très moche comme nom en plus d’être un anglicisme. On entend aussi souvent parler de «core», mais c’est trop facilement associé à un cœur de processeur. En général je m’applique à parler d’architecture ou simplement de projet FPGA en français et de design en anglais pour parler de la chose.

Mais une «architecture» est vite associée à quelque chose de plus vaste, à une vue d’ensemble d’un projet et n’est pas nécessairement lié à du matériel.

On pourrait aussi parler de schéma puisque ce sont des portes logiques reliées entre elles. Mais comme on est en train de faire du code c’est étrange.

En anglais, j’ai pu lire sur le site de Sébastien Bourdeauducq qu’il parlait de gateware. Ce qui est assez parlant une fois que l’on a compris le sens. On parle de software pour du logiciel, de firmware pour du logiciel embarqué (profond) et de hardware pour le matériel. Pourquoi pas du gateware pour parler de fpga/asic ?

En effet, un projet/design/core fpga est une description de portes connectées ensemble ce qui colle bien au nom anglais gateware (gate=porte).

Si nous allons plus loin et que nous traduisons en français ce nouveau mot, nous pourrions parler de :

portegramme par analogie à programme.

Voila une idée à envoyer à l’académie française tiens !