La libération des FPGA et des ASIC bien engagée pour 2020

Posté par  (site web personnel, Mastodon) . Édité par Yves Bourguignon, BAud, Davy Defaud, Pierre Jarillon, gUI, ZeroHeure, Benoît Sibaud et Ysabeau 🧶. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
70
20
jan.
2020
Matériel

En début d’année 2019 se posait la question de savoir si ce serait l’année de la libération des FPGA. En ce début d’année 2020, essayons de faire un bilan.

FPGA, ASIC, HDL, RISC‑Ⅴ et PCB sont les chapitres que nous allons découvrir dans la suite de cet article. Si vous connaissez déjà ces sigles et acronymes, vous allez adorer ; mais si vous ne les connaissez pas, c’est indispensable car ces vocables sont à la base de la culture universelle de notre siècle.

Nous sommes actuellement arrivés à un moment clé pour le matériel informatique. Il en est au même point que le logiciel libre en était en 2000, quand il est devenu mature. Le mouvement est lancé et les projets deviennent utilisables. On ne rêve plus…

Sommaire

FPGA

À condition de choisir son FPGA cible, il est aujourd’hui possible de faire son développement intégralement à base de logiciels libres. Tout cela principalement grâce à Yosys et Nextpnr.

Les grandes avancées de Yosys

Yosys est un logiciel libre de synthèse Verilog. Il permet de convertir un modèle Verilog en une netlist. La netlist est tout simplement un schéma électronique comme on peut en faire avec un logiciel de saisie de schéma. On relie entre eux des connecteurs d’entrées‐sorties de composants pour réaliser un circuit électronique.

Cependant, en général, un logiciel de synthèse cible des FPGA ou des ASIC qui ont leurs propres bibliothèques de composants. Et la netlist générée est au format texte, même si une fonction de Yosys permet d’afficher le « schéma » au moyen de Graphviz.

Yosys augmente le nombre des FPGA officiellement pris en charge avec les FPGA de Gowin. L’ingénierie inverse du Gowin n’est pas encore terminée mais elle est déjà utilisable. C’est tout le travail de Pepijn De Vos avec son Project Apicula.

Plusieurs gammes de FPGA de Lattice sont désormais prises en charge. En plus du ICE40 initial, les ECP5 sont maintenant parfaitement utilisables et les nouveaux CrossLink (Nexus) sont en cours de « reverse engineering » (rétro‑ingénierie, voir ci‑dessous) avec le Project Oxide de David Sha.

Hormis la partie placement routage et bitstream, les FPGA de la série 7 de Xilinx sont assez bien gérés par Yosys (mais Yosys ne fait pas le placement‐routage). Et Google a fait un petit cadeau à la communauté libre en annonçant financer la prise en charge des (pas si) vieux Spartan3 et Spartan6.

NextPnR, le placement‐routage libre

Nextpnr est un logiciel libre permettant de faire le placement‐routage. Le principe est assez simple, un FPGA disposant d’une matrice de composants gravés sur la puce, il faut décider quel composant de la netlist générée par le logiciel de synthèse ira sur quel composant présent dans le FPGA. Une fois les composants placés, il faut router les entrées‐sorties en réalisant les connexions.

Nextpnr est aujourd’hui parfaitement utilisable pour les FPGA ICE40 et ECP5 de Lattice. Pour les FPGA de Gowin, cela ne saurait tarder à mon avis.

Rétro‑ingénierie

Pour configurer un FPGA (établir les liens entre les bascules) il faut télécharger un bitstream. Le format de ce bitstream n’est documenté par aucun constructeur de FPGA. Nous sommes obligés de passer par les outils (gratuits, en général) fournis par le constructeur pour le générer.
Bien que n’étant pas documenté, le format n’est pas non plus chiffré, il est donc parfaitement possible de l’étudier par ingénierie inverse pour le documenter.
De plus en plus de projets de FPGA par ingénierie inverse de bitstream voient le jour. Votre serviteur tente de maintenir une liste de ces projets sur son blog en donnant l’état d’avancement des projets.
On décompte au moins neuf projets plus ou moins avancés de rétro‑ingénierie :

  • icestorm : les ICE40 de Lattice ;
  • X-Ray : la série 7 de Xilinx : Artix7, Spartan7 et Virtex7 ;
  • prjoxide : les CrossLink‑NX de Lattice ;
  • rodinia : les CPLD AGM ;
  • mistral : le Cyclone Ⅴ d’Intel (anciennement Altera) ;
  • Apicula : les GW1N de Gowin ;
  • OpenFpga : un mélange de CPLD de différentes marques GreenPAK4, CoolRunner Ⅱ, PSoC 5LP (Silego, Xilinx et Cypress) ;
  • Trellis : les ECP5 de Lattice ;
  • prjbureau : les ATF1502AS de Microchip.

Notons que la marque Lattice est très représentée, alors que Microsemi est absent (à ma connaissance) de ces projets.

ASIC

Les ASIC ne sont pas des FPGA. Une fois que l’on a envoyé nos fichiers de production au fondeur, les composants ne sont plus modifiables. Et comme la facture est en général particulièrement salée pour produire une série, il faut en produire beaucoup et surtout ne pas se planter.

Une (vénérable) suite de logiciels libres appelée QFlow existe depuis plus de trente ans pour concevoir ces circuits intégrés spécialisés. Mais le site officiel fait particulièrement peur, et laisse croire que le logiciel est à l’abandon depuis bien longtemps.
Il n’en est rien, ce logiciel est toujours maintenu et est utilisé par de plus en plus de concepteurs ASIC pour produire des puces libres. On pense notamment au Raven à base de PicoRV32 (RISC‑Ⅴ) qui avait été décrit dans les colonnes de LinuxFr.org. On pense également au projet de FPGA libre kFPGA décrit également dans ces colonnes.

Un autre composant à destination des amateurs de rétro‑informatique est en cours de production par Staf Verhaegen avec le projet Chip4Makers. L’idée de Staf est que la production de composants ASIC coûte très cher à l’unité, il n’est donc pas possible de concurrencer les composants du marché avec un composant conçu « dans son garage ».
Cependant, il existe une frange de hobbyistes prête à payer plus cher pour retrouver leur vieux processeur 6502 ou Z80. Ce sont donc ces processeurs que Staf a inclus dans un unique composant, et la pré‑série a été produite d’après un de ses tweets. Les sources du composant en question sont disponibles sur sa projet GitLab.

D’autres instituts et fondations s’intéressent de très près à l’émergence d’outils libres pour réaliser des microprocesseurs et ASIC. On pense notamment à :

HDL (Hardware Description Languages)

Yosys était jusqu’ici réservé à la synthèse Verilog. Mais grâce au travail de Tristan Gingold et Pepijn De Vos (principalement), il est désormais possible d’utiliser Yosys en conjonction de GHDL pour faire de la synthèse GHDL. Le projet est encore en beta‑test, mais Pepijn s’en sert pour faire de la synthèse TTL de ses porte‑grammes VHDL ainsi que de la vérification formelle.

Principalement grâce à Yosys, il est désormais tout à fait possible de faire de la vérification formelle pour valider ses composants. C’est le cheval de bataille de Dan Guisselquist, avec son projet de processeur nommé ZipCPU.

Le langage de haut niveau Chisel est maintenant relativement mature. Le projet fait partie de la fondation Linux et la conférence annuelle CCC (non pas Chaos Communication Camps mais Chisel Community Conference) est soutenu par des gros industriels comme Western Digital ou Cadence.
Toute la gamme des processeurs développés par SiFive est écrite avec Chisel, Google a utilisé le langage Chisel pour son processeur d’intelligence embarqué Edge TPU.

Le langage nMigen basé, lui, sur Python essaime aussi pas mal, mais surtout dans le milieu de la recherche.

CλaSH est sortie en version 1.0. Cela faisait des années qu’il se traînait avec des version 0.x, le passage à 1.0 est un signe de maturité. CλaSH est basé sur le langage au paradigme fonctionnel Haskell. Je ne peux hélas pas vous en dire plus aujourd’hui car je n’ai par réussi à percer le secret de cette logique de matheux qu’est le paradigme fonctionnel. :)

Cocotb a désormais un vrai rythme de développement et est utilisé en production pour de « grosse » IP comme l’USB. La version 1.3 est sortie en ce début d’année. Cocotb est un module Python permettant d’écrire des bancs de test HDL. Cocotb a la particularité de se connecter à un simulateur « du marché » pour lire et écrire les valeurs de signaux. Cela permet de garder son simulateur HDL parfois acquis à grands frais.

Verilator, le simulateur Verilog le plus rapide du « marché » (plus rapide que tous les simulateurs commerciaux) continue à être activement développé. Les récents commits permettent aujourd’hui de l’utiliser avec Cocotb. Et son passage à la version 4.0 permet une pleine utilisation des multiples cœurs de nos PC actuels, améliorant encore ses performances.

RISC‑Ⅴ

On peut aujourd’hui dire sans sourcilier que l’année de libération des processeurs est passée grâce au jeu d’instructions RISC‑Ⅴ.
Il n’est plus nécessaire de présenter ce jeu d’instructions aujourd’hui, et nous pouvons nous procurer tout un tas de microcontrôleurs basés sur RISC‑Ⅴ pour une somme d’argent (plus ou moins) modique.
Voici une petite liste de microprocesseurs RISC‑Ⅴ disponibles sur le marché :

Hormis l’U540 et, dans une certaine mesure, le K210, tous ces processeurs sont des microcontrôleurs orientés basse consommation. La question qui est sur toutes les lèvres aujourd’hui, c’est : RISC‑Ⅴ va‑t‑il percer dans le monde du serveur et du calcul parallèle ?

Circuits imprimés

Kicad est un logiciel de conception électronique pour fabriquer des circuits imprimés, également appelés PCB. C’est un logiciel initialement développé par un français (cocorico) qui inclut toute la suite de logiciels nécessaires à l’électronicien :

  • la schématique ;
  • le routage ;
  • et même maintenant la simulation de la gestion des coûts en composants (BOM) ;
  • etc.

Kicad est longtemps resté un logiciel anecdotique (mais parfaitement fonctionnel), jusqu’à ce que le CERN s’y intéresse et finance des ingénieurs pour améliorer la partie routage. Aujourd’hui, Kicad est soutenu par la Fondation Linux et a lui aussi sa conférence annuelle prestigieuse : la KiCon.

Ils sont emprisonnés depuis trop longtemps, mais nous ne les avons pas oubliés !

Pour conclure, nous pouvons affirmer que la libération des FPGA est maintenant bien engagée. Et nous assistons aujourd’hui à l’émergence du matériel libre du point de vue du cœur de la puce : le silicium.
La liberté dans ce monde stagnait depuis des dizaines d’années, mais les choses décollent aujourd’hui. Et on entend le même refrain contre le Libre que l’on entendait dans les années 2000 sur le logiciel. Pour quelqu’un qui chercherait un projet libre sur lequel se lancer pour faire ses armes, comme pour la conquête de l’ouest, l’espace est encore vierge et c’est le moment de se lancer.

Aller plus loin

  • # Typo

    Posté par  . Évalué à 6.

    Petite coquille :

    FPGA, ASIC, HDL, RISC‑Ⅴ et PCB sont les chapitres que nous allons découvrir dans la suite de cet article.

    Sinon merci pour ce super récapitulatif.

  • # Quid de la certification et de l'utilisation industrielle ?

    Posté par  . Évalué à 6.

    Je précise que ma question n'est pas polémique, bien au contraire.

    Nombre de "petites" structures (bureaux d'étude, SSII ou ESN) seraient bien contente de se libérer de licences hors de prix.

    Mais si j'en crois mes petits camarades de taf qui oeuvrent dans le domaine, le gros problème est le client. Il exige souvent des outils "certifiés", et donc utiliser des outils libres n'est même pas une question. C'est impossible… au moins pour l'instant.

    Du coup, je me demande l'utilité de ce genre d'outils en dehors (peut-être) du maquettage pour éviter de consommer des licences dans des phases d'étude, ou pour des stages, ou pour des labos de recherche… Ce dernier point n'étant évidemment pas à négliger.
    _
    Et donc la question est de savoir s'il est prévu que ces outils passent les mêmes certifications que les outils commerciaux ?_

    Mais j'imagine que ce genre de certification n'est pas gratuit, sans polémiquer bien sûr sur le fait que le coût de certification permet à quelques grands acteurs de verrouiller le marché comme c'est le cas pour les semences.

    • [^] # Re: Quid de la certification et de l'utilisation industrielle ?

      Posté par  . Évalué à 6.

      Effectivement, dans des domaines comme l'automobile, le ferroviaire ou l'aérospatial, la chaine de développement doit être certifiée. Cela limitera drastiquement le champ d'utilisation de ces outils, tant qu'il n'auront pas acquis une maturité suffisante.

      Cela dit, cela peut aller assez vite. Je connais des personnes qui travaillent sur de la génération et l'optimisation automatique de code et sur son implémentation dans des FPGA. Ce travail sera libre sous licence Cecill. En parallèle ils vérifient leur code avec des outils de preuve formelle, afin de garantir la validité des résultats.

      In fine, ont peut espérer des outils libres qui n'auront plus rien à envier aux logiciels propriétaires. Cette ouverture permettant de vérifier leur performances et leur intégrité, les grand donneurs d'ordre auront tout intérêt à demander leur utilisation.

    • [^] # Re: Quid de la certification et de l'utilisation industrielle ?

      Posté par  . Évalué à 10.

      Ce n'est qu'une question de temps. Linux aussi ne pouvait pas être utilisé dans un environnement critique il y a quelque années. Il faut bien démarrer quelque part et avancer.

  • # openFPGALoader

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    On vient de me faire remarquer que j'ai oublié de parler d'un nouvel utilitaire permettant de configurer les FPGA : openFPGALoader.

    Pour envoyer le Bitstream de configuration dans le FPGA on peut passer par tout un tas de protocole comme le SPI, le JTAG, du parallèle (SelectMap) ou même le PCIe.
    Le constructeur fourni toujours un utilitaire pour le faire. Mais c'est souvent bien galère à configurer (droits sur le port série, driver ftdi et consort en binaire …) et très orienté clic-clic (même s'il est généralement possible de scripter).

    Le projet openFPGALoader est un petit projet open source écrit en C++ qui a la prétention de pouvoir gérer la plupart des FPGA.

    Et il démarre assez bien puisqu'il supporte déjà 5 FPGA différents. De plus le chargement est toujours nettement plus rapide qu'avec les outils constructeurs !

    J'ai plus qu'une balle

    • [^] # Re: openFPGALoader

      Posté par  . Évalué à 3.

      A noter l'arrivée en 4.18 d'un framework FPGA pour linux.

      Celui ci permettra de charger des bitstreams depuis le soc lui-même, à condition que le constructeur développe un driver qui prend en charge cette API. Donc, à terme, d'uniformiser un peu le processus entre les différents fondeurs.

      J'ai vu passer des drivers pour au moins Xilinx et Altera.


      Voire, de faire des trucs rigolos en changeant de bitstream à la volée -

      • [^] # Re: openFPGALoader

        Posté par  (site web personnel) . Évalué à 1.

        En effet, il existe un framework dédié aux FPGA dans le noyau et l'idée de openFPGALoader n'est pas d'entrer en concurrence avec celui-ci.
        Le framework dans Linux a pour but de proposer une interface unifiée (plus ou moins) pour la configuration. Dans le cas des zynq ou socfpga les drivers correspondants vont taper directement dans la mémoire pour envoyer le bitstream. Dans le cas d'autres FPGAs tels que les ice40 ou machXO2 ils communiquent en SPI.

        Le soucis avec ce modèle est qu'il ne réponds pas aux contraintes des cartes d'évaluations qui, la plupart du temps, se programment en JTAG par le biais d'un convertisseur (souvent un FTDI). Pour ces cibles il faut avoir un logiciel en espace utilisateur (ou alors créer un pilote avec le risque d'enter en conflit avec ftdi_sio et de perdre le port série généralement disponible) qui, souvent, est un logiciel propriétaire.

        openFPGALoader a pour but de fournir un outil unifié pour répondre à ce cas de figure en bon voisinage avec le framework fpga du noyau.

  • # Commentaire supprimé

    Posté par  . Évalué à -3. Dernière modification le 10 février 2020 à 07:50.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # chips4makers, un design FPGA devient un chip

    Posté par  (site web personnel) . Évalué à 1.

    chips4makers, un design FPGA devient un chip:

    https://github.com/zoobab/manneken-pi

    Peut-etre un clone de Raspi entierement libre pour 2020?

  • # circuits imprimés

    Posté par  . Évalué à 4.

    Kicad est sans doute très bien, mais ayant une petite carte PCB à réaliser, je l'ai trouvé très compliqué à prendre en main (je ne suis pas électronicien).
    J'ai utilisé Fritzing (https://fritzing.org/home/) qui est peut-être plus limité, mais bien plus intuitif ! Et ma carte PCB a été correctement imprimée au final !

    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

    • [^] # Re: circuits imprimés

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Fritzing est très bien pour ce genre de besoin. De plus il est graphiquement beau et permet d'exporter les image pour les intégrer dans ses Tuto.
      Mais ça n'est pas le même usage. Fritzing n'est pas pertinent pour faire des PCB complexe, multi-couche ou pour générer les différents fichiers de fabrications à donner au sous traitant.
      Kicad si.

      J'ai plus qu'une balle

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.