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é.
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 !
