openFPGALoader est un utilitaire en ligne de commande, écrit en C++ et sous licence Apache 2.0. Il permet de configurer des FPGA de toutes marques. L’objectif du projet est de pouvoir prendre en charge tous les FPGA du marché ainsi que tous les adaptateurs et sondes de configuration.
Sommaire
- La chaîne de développement sur FPGA
- Chargement du bitstream ou « configuration »
- Quelques exemples
- Pour conclure
La chaîne de développement sur FPGA
Pour développer sur un FPGA, nous avons besoin d'un ensemble de logiciels et de formats spécifiques. La chaîne de développement sur FPGA peut se résumer par la figure ci-dessous:
L'architecture du composant est décrite dans un langage de description (HDL pour Hardware Description Language) matériel. Cette description est convertie en un schéma électronique (Netlist) par un procédé appelé «synthèse». Les composants de la Netlist sont ensuite placés dans la matrice du FPGA (placement) puis connectés ensemble (Routage) pour former le composant décrit au début.
Toutes ces informations sont ensuite décrites dans un fichier de configuration appelé bitstream (propriétaire). Et enfin, le fichier est transféré au FPGA pour le configurer.
À l'origine, toutes ces opérations sont réalisées par des logiciels privateurs, et les formats sont verrouillés. Quand on parle de libération des FPGA on aimerait bien sûr que toute la chaîne puisse être réalisée avec des logiciels libres et des formats ouverts. Mais le point le plus bloquant évoqué est souvent le format du bitstream, qui est LE maillon le plus critique de la chaîne jalousement gardé secret par (presque) tous.
Toutes ces étapes ont désormais des projets open source qui sont suffisamment avancés pour pouvoir développer sur FPGA librement. À condition de bien choisir le modèle.
Chargement du bitstream ou « configuration »
On en oublie souvent la dernière étape consistant à télécharger le bitstream dans le FPGA. Pourtant cette étape est également dépendante du constructeur qui propose l’adaptateur à vil prix (souvent une sonde USB-JTAG). Et le logiciel est en général intégré au lourd IDE du constructeur (binaire x86) qu'il n'est pas toujours facile de configurer sur sa distribution Linux et encore moins sur une architecture exotique (raspberryPi, Risc-V, …).
Le dessein d'openFPGALoader est donc d’être « l’anneau pour les programmer tous ». Pour cela il faut :
- prendre en charge les différentes sondes de programmation du marché. La documentation indique les 14 (familles de) sondes qui le sont déjà.
- gérer le plus de FPGA possible. Même si tous ne sont pas pris en charge, la liste des 22 FPGA compatibles (un total de 61 modèles différents) est déjà impressionnante. Le logiciel semble même être devenu une référence open source pour des FPGA qui ne sont pas encore sortis. On pensera par exemple au GateMate de CologneChip qui n’est pas encore sorti mais pour lequel l’entreprise a contribué pour la prise en charge de son composant.
- gérer également les différentes cartes électroniques intégrant les FPGA ainsi que les différents modes de configuration (RAM de configuration, EEPROM maître/esclave, Flash, EEPROM interne…).
Avec cette version 0.6.0, le logiciel peut être considéré comme mature. C’est tellement devenu une référence qu’il est même intégré dans quelques distributions Linux, dans buildroot. Le logiciel fonctionne également sur Mac et Windows avec cependant plus de problème du fait du passage par le pilote usb zadig.
C'est aujourd'hui un automatisme pour configurer un FPGA, de le tester d'abord avec openFPGALoader. Avant même d'utiliser l’outil constructeur. Le logiciel apporte un confort d'utilisation et de configuration qui n'a rien à envier aux autres.
Quelques exemples
Pour illustrer, un peu l'utilisation d'openFPGALoader, supposons que nous ayons notre bitstream permettant de faire clignoter la led de la carte Tang Nano 4K. L'avantage de cette carte est que l'adaptateur de programmation est inclus et que tout passe par le même port USB.
Une fois la carte branchée on peut commencer par détecter le FPGA avec --detect
:
$ openFPGALoader --detect
write to ram
Jtag frequency : requested 6.00MHz -> real 6.00MHz
index 0:
idcode 0x100981b
manufacturer Gowin
family GW1NSR
model GW1NSR-4C
irlength 8
Le format de bitstream pour les gowin possède l'extension fs
, on peut le configurer directement en donnant simplement le nom du fichier en argument :
$ openFPGALoader led_test/project/impl/pnr/led_test.fs
write to ram
Jtag frequency : requested 6.00MHz -> real 6.00MHz
Parse file Parse led_test/project/impl/pnr/led_test.fs:
Done
DONE
Jtag frequency : requested 2.50MHz -> real 2.00MHz
erase SRAM Done
Flash SRAM: [==================================================] 100.00%
Done
SRAM Flash: Success
Et si le bitstream nous satisfait on l’écrira dans la mémoire « flash » avec l’option -f
pour qu’il se reconfigure à chaque allumage.
$ openFPGALoader ide/gbhdmi/impl/pnr/gbhdmi.fs -f
write to flash
Jtag frequency : requested 6.00MHz -> real 6.00MHz
Parse file Parse ide/gbhdmi/impl/pnr/gbhdmi.fs:
Done
DONE
Jtag frequency : requested 2.50MHz -> real 2.00MHz
erase SRAM Done
erase Flash Done
write Flash: [==================================================] 100.00%
Done
CRC check: Success
Les fichiers de configuration à télécharger dans le FPGA peuvent être assez volumineux pour certain gros FPGA. Les sondes de configuration n'étant pas toujours très rapide, il est intéressant de pouvoir envoyer le bitstream compressé.
Cette option est bien sûr supporté par openFPGALoader.
Plutôt que de prendre le nom du fichier bitstream en argument, il est également possible de récupérer un «flux» sur l'entrée standard:
cat /path/to/bitstream.ext | openFPGALoader --file-type ext [options]
Méthode très pratique si l'on souhaite configurer son FPGA via le réseau par exemple:
# Carte connectée au FPGA
nc -lp port | openFPGALoader --file-type xxx [option
# Ordinateur distant
nc -q 0 host port < /path/to/bitstream.ext
Et si vous trouvez que cette dépêche manque (scandaleusement) de TapTempo, sachez qu'openFPGALoader fonctionne très bien sur le FPGA ECP5 présent sur la carte colorlight pour y configurer le bitstream TapTempo en VHDL :
$ openFPGALoader taptempo.bit
Open file taptempo.bit DONE
Parse file DONE
Enable configuration: DONE
SRAM erase: DONE
Loading: [==================================================] 100.000000%
Done
Disable configuration: DONE
Pour conclure
À l’heure où cette dépêche est mise sous presse, openFPGALoader a sorti une version mineure 0.6.1 (principalement pour réduire le nombre d’« assets » dans l’archive.
openFPGALoader est maintenant bien installé dans la constellation des logiciels libres pour développer sur FPGA. Même s’il n’a pas encore atteint la version 1.0, il est désormais tout à fait mature pour une utilisation en « production ». Il méritait bien une dépêche sur LinuxFR.
Aller plus loin
- La version 0.6.0 d'openFPGALoader (74 clics)
- Le dépot officiel (59 clics)
- La documentation (42 clics)
# Problème de mise en page.
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
Je crois qu'il y a un petit problème de mise en page pour la conclusion. Est-ce qu'un modérateur pourrait corriger ça svp ?
Merci
J'ai plus qu'une balle
[^] # Re: Problème de mise en page.
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Encore un souci de différence de rendu entre modération et publication… Corrigé, merci.
# Différences par rapport à xc3sprog
Posté par marzoul . Évalué à 4. Dernière modification le 18 décembre 2021 à 13:15.
Merci pour ces infos sur openFPGALoader.
Je connaissais son existence, mais je me suis toujours demandé quelles sont les différences avec son frère xc3sprog (lien en fin de message). Différences de concept ? d'architecture ? de mainteneur ?
Pour ceux et celles qui se posent la question, on dirait que:
- openFPGALoader supporte bien mieux les différents vendeurs de FPFA
- xc3sprog supporte beaucoup plus de références de FPGA Xilinx, mais le projet ne semble plus actif
Autres différences connues ?
https://github.com/UweBonnes/xc3sprog
[^] # Re: Différences par rapport à xc3sprog
Posté par gwenhael goavec-merou (site web personnel) . Évalué à 5.
Bonne remarque : une mise en contexte d'openFPGALoader vis-à-vis des autres outils aurait été utile.
En ce qui concerne les différences/équivalences avec xc3sprog :
openFPGALoader vise à supporter tous les fabricants et non seulement Xilinx (depuis le début de la semaine les GateMate de CologneChip le sont également donc même des composants qui ne sont pas encore disponibles). La liste des composants supportés par xc3sprog est très longue, celle de openFPGALoader pourrait/devrait être complétée en injectant, pour certains modèles, l'ensemble des IDCodes (les Artix, spartan6, cyclone ont étés suffisament testés pour considérer que le code est fonctionnel quelque soit la taille du composant)
La liste des câbles dans xc3sprog est relativement limitée (principalement du ftdi, du port parallèle et du cypress FX2) alors que openFPGALoader supporte pour le JTAG (évidemment) du FTDI (MPSSE et bitbang), les sondes altera USB-blaster, dirtyJTAG, orbtrace, … Mais également le DFU et l'accès direct aux flash SPI. Cette limitation des cables est parfois un soucis (sous l'impulsion de Uwe Bonnes - le mainteneur de xc3sprog - j'ai acheté une plateforme à base de coolrunnnerII avec une connecteur pour USB-blaster -> il a fallu faire usage de cables dupont pour tester avec xc3sprog et une sonde digilent)
Écrire un bitstream en flash, pour Xilinx et Altera/intel impose de charger en RAM un gateware dédié, avec xc3sprog, il doit être spécifié, avec openFPGALoader cet aspect est transparent pour l'utilisateur (utiliser un FPGA avec une flash interne ou externe se fait exactement de la même manière).
Et en effet, il semble que xc3sprog n'évolue plus trop, Uwe Bonnes semble se concentrer sur blackmagic à l'heure actuelle (et a contribué à openFPGALoader).
J'espère que ma réponse a clarifié ce point.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.