Sortie de la version 0.6.0 du configurateur de FPGA openFPGALoader

22
17
déc.
2021
Matériel

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

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:

Chaîne de développement FPGA

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 :

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

  • # Problème de mise en page.

    Posté par  (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

  • # Différences par rapport à xc3sprog

    Posté par  . É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  (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.