L’OpenHW group a été lancé en juin dans la foulée du workshop RISC-V qui se tenait à Zurich.
L’OpenHW group est une organisation à but non lucratif ayant pour objectif de promouvoir le développement de composants électroniques libres (ASIC, FPGA, …).
C’est dans cette optique de l’OpenHW développe une série de microprocesseurs RISC-V nommés sobrement Core-V.
On en saura certainement plus sur cette organisation cet automne à l’occasion du forum OSDForum qui se tiendra à Ottawa.
FireAnt est un kit de développement «de la taille d’un pouce» concu par la société Xips Technology et permettant de se faire la main sur le FPGA Trion T8 de la société Efinix.
Le kit est en crowdsourcing sur la plate-forme crowdsupply pour $30.
Pour ce prix on a le droit à :
Efinix est une toute nouvelle société qui propose des petits FPGA gravés en 40nm. Pour les tout petits FPGA de leur gamme, la société propose ce qu’elle appelle un MPM pour «Mask Programmable Memory» -> la possibilité de figer le design en usine et de ne plus avoir à configurer le FPGA à chaque démarrage.
Un IDE permettant de faire la synthèse, le placement-routage et le bitstream est fourni «gratuitement». À condition de posséder un kit de développement (J’ai beau négocier, ils ne veulent pas me le donner tant que je n’aurais pas reçu le kit 😉 ).
Bref, il n’est pas encore question d’outils libres pour ces FPGA pour l’instant. Cependant, ça fait du bien de voir de nouveaux acteurs dans le domaine des FPGA «physique».
Wavedrom est un outils magique pour générer de très beaux chronogrammes à partir d’une base texte (JSON). Il existe un outils en ligne de commande pour générer des rendu en SVG ou PNG. Cependant, Wavedrom reste très lié au web, pas facile de l’intégrer dans un document wysiwyg comme libreoffice.
On peut bien sûr générer l’image puis l’intégrer à son document, mais cela éparpille très vite le nombre de fichiers source à gérer. Or, un des intérêt d’un document libreoffice est d’inclure toute les sources permettant de générer et modifier le document.
L’idéal serait d’avoir un plugin Libreoffice pour wavedrom, mais pour l’instant cela n’existe pas.
Krispy propose une solution/hack sur la mailing list de wavedrom.
Cette solution nécessite d’avoir un accès web et de faire son chronograme avec l’éditeur en ligne de wavedrom. Cet éditeur permet de «stocker» la description du chronograme dans l’URL. Il suffit pour cela de cliquer sur le menu sandwich en bas à droite et de sélectionner «expand url» pour avoir le contenu du chronogramme dans l’url comme ceci.
Il n’est pas utile de comprendre ce qui est écrit dans l’url, il suffit de cliquer dessus pour avoir le texte «lisible».
Pour l’intégrer à son document libreoffice il suffit de:
De cette manière, le source du chronogramme est bien embarqué dans le document. Il faudra certe refaire une manip légèrement fastidieuse à chaque modification, mais nous avons tout de même une solution viable.
C’est évident quand on y pense, mais très piégeux :
if(state == OPU_RSC || (state == OPU_WSTR))
if(timetick_pulse) begin
pwr_counter <= pwr_counter + 1;
end
else
pwr_counter <= 0;
On pense que le else se rapporte au premier if … et bien non !
Il faut écrire :
if(state == OPU_RSC || (state == OPU_WSTR)) begin
if(timetick_pulse) begin
pwr_counter <= pwr_counter + 1;
end
end else
pwr_counter <= 0;
Voila voila, si on peut vous éviter des heures de déverminage inutiles c’est cadeaux 😉
Les FPGA sont très liés aux ASIC. En effet, la plupart des outils utilisés en FPGA pour la synthèse HDL, la preuve formel, le placement routage ou l’analyse des timings sont les même que ceux à destination des ASIC. Seuls les librairies et les configurations changent. La grosse différence (de taille) avec les FPGA c’est que l’ASIC n’est pas reconfigurable, et les «frais d’initialisations» sont très élevés. Les délais de productions sont très long également (on parle en trimestre voir en semestre de délais).
Avec de telles contraintes, on comprend pourquoi les développeurs ne se mouillent pas trop avec des logiciels exotiques et restent sur ceux qu’ils connaissent. Vu les tarif de production, le coût des licences des logiciels est assez négligeable. Pourquoi «grenouiller» avec des outils open-source dans ce cas ?
Toutes ces contraintes n’ont pas découragé Tim Edwards de se lancer dans la conception et la fabrication d’un microcontrôleurs intégralement avec des outils open-sources.
C’est comme cela qu’est né le Raven, un microcontrôleur basé sur un cœur picoRV32 (conçu par Clifford Wolf) et réalisé principalement avec les outils qflow d’opencircuitdesign.com :
Grande surprise quand on se plonge dans ces outils open-source : Beaucoup sont très vieux. Les pages web de ses outils sont encore codé en web95 avec des frames et autre fonds hideux datant de l’époque frontpage.
Pourtant à y regarder de plus prêt, ces outils semblent toujours activement maintenus.
Mais alors pourquoi aucun fondeur FPGA ne les proposent dans leurs IDE ?
Une première série du microcontrôleur gravé en 180nm a été produite en mai 2018. Le composant est désormais fonctionnel avec les caractéristiques suivantes:
Il n’est pas possible d’acheter le composant pour se faire un montage chez soit pour le moment. Par contre l’«IP» est disponible dans la bibliothèque du fondeur efabless et peut être utilisé comme base pour réaliser son propre composant selon les besoins.
La simulation HDL génère assez vite des traces (waves) de plusieurs centaines de méga-octets, voir des dizaines de giga.
Ces traces sont le plus souvent au format VCD, qui n’est qu’un fichier texte répétant les même schéma au court du temps. Ces fichiers ayant énormément de redondance, ils se compressent très bien.
Si je prend par exemple un fichier vcd messignaux.vcd faisant ~500Mo :
$ ls messignaux.vcd
-rw-r--r-- 1 fabien fabien 504M avril 3 10:17 messignaux.vcdJe compresse avec zip en environ 30 secondes:
$ zip -c messignaux.zip messignaux.vcd
adding: messignaux.vcd (deflated 89%)
$ ls -lha messignaux.zip
-rw-r--r-- 1 fabien fabien 56M avril 5 14:16 messignaux.zip
Et je réduis mon fichier à 56Mo soit un rapport de presque 10.
Avec gzip on gagne la même chose à une queue de vache près :
$ gzip messignaux.vcd
$ ls -lha messignaux.gz
-rw-r--r-- 1 fabien fabien 57M avril 3 10:17 messignaux.vcd.gz
Et avec xz alors là on réduit environs à 20 fois plus petit, … mais il faut plus de 5 minutes à xz pour faire la compression:
$ xz -z messignaux.vcd
$ ls -lha messignaux.vcd.xz
-rw-r--r-- 1 fabien fabien 27M avril 3 10:17 messignaux.vcd.xz
Bref, si vos traces de simulation prennent trop de place sur votre pc, n’hésitez pas à les compresser.
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.
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».
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. Le fichier se décompresse avec la commande unrar:
$ unrar x ../TD_RELEASE_SEPTEMBER2018_RHEL.rar
Il faut ensuite 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 :
C’est l’environement de développement le plus simple à installer 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 à 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 sûr 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é.
Au bout de quelques temps, la licence du logiciel expire. Il n’est plus possible de synthétiser avec. Un site chinois donne le truc pour que ça remarche. Pour éviter ce piratage, il semble être maintenant possible d’utiliser Yosys pour la partie synthèse !
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.
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 :
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é.
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:
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 !
