Archives mensuelles : juillet 2020

CocoTB 1.4.0, la maturité

[Dépêche publiée initialement sur LinuxFR]

C’est dans la soirée du 8 juillet que l’annonce est tombée : la version 1.4.0 de CocoTB est sortie. Cette nouvelle version est une belle évolution de Cocotb avec une bonne intégration dans le système de paquets de Python ainsi que l’abandon de la prise en charge de Python 2. On peut aujourd’hui dire que CocoTB est une alternative sérieuse pour écrire ses bancs de test HDL.

Sommaire

Mais qu’est‑ce que c’est ?

CocoTB est une bibliothèque de cosimulation permettant d’écrire (en Python) des bancs de test pour la simulation numérique HDL (Hardware Description Language). Historiquement, les deux langages de descriptions HDL que sont Verilog et VHDL embarquent tout le nécessaire pour écrire des stimuli permettant de tester le composant en simulation. Cela permet d’avoir un seul langage pour décrire le composant et le tester. Le simulateur exécutera tout cela sans problème.

Mais cela amène beaucoup de confusion entre la partie du langage utilisable pour la simulation uniquement et la partie « description du matériel ». Dans le cas de la partie « matériel » on parle alors de code « synthétisable ». Cette confusion entre du code synthétisable ou non est source de grandes frustrations au moment de passer à la synthèse. En effet, cette belle structure de données que l’on aura développée et testée aux petits oignons s’écroulera au moment de la synthèse quand on se rendra compte que le code n’est pas synthétisable. Il faudra tout reprendre.

Une des idées derrière CocoTB est donc de changer de langage pour la simulation, comme cela les choses sont claires : on utilise le VHDL ou Verilog pour la partie du composant qui est synthétisable, et on passe au Python pour le banc de test. Ce n’est pas le seul logiciel à proposer ce genre d’approche. Avec Verilator, par exemple, on va écrire toute la partie banc de test en C++ ou en SystemC. La partie synthétisable sera écrite en Verilog et convertie en un objet C++ par Verilator.

La seconde idée de CocoTB est de ne pas réinventer la roue en réécrivant un énième simulateur HDL. Ce qui évite également d’avoir à choisir son camp entre Verilog et VHDL ou les deux (simulation mixte). Non, CocoTB va se contenter de piloter les simulateurs disponibles sur le marché. Les simulateurs libres que sont GHDL, Icarus et Verilator sont naturellement pris en charge, même si dans le cas de Verilator c’est très récent. La plupart des simulateurs commerciaux le sont également, ce qui est un argument pour l’introduire dans son bureau d’étude. En effet, les managers sont en général moyennement chauds pour virer un logiciel acquis à grands frais. Et l’on peut continuer à profiter des interfaces proposées par notre simulateur habituel pour exécuter le simulateur, visionner les chronogrammes, faire de la couverture de tests, etc.
La version 1.4 de CocoTB introduit la gestion complète du simulateur Aldec Active HDL qui vient s’ajouter aux classiques de Cadence et de Mentor, Modelsim…

Les changements dans le code

Un gros changement initié depuis quelque versions déjà est l’utilisation du mot clef async en lieu et place du yield et du décorateur @coroutine. Python 3 gérant désormais l’asynchronisme, CocoTB l’utilise et le prend désormais complètement en charge. L’exemple donné dans le courriel de la publication est le suivant :

    @cocotb.test()
    async def my_first_test(dut):
         """Try accessing the design."""

         dut._log.info("Running test!")
         for cycle in range(10):
             dut.clk <= 0
             await Timer(1, units='ns')
             dut.clk <= 1
             await Timer(1, units='ns')
         dut._log.info("Running test!")

Qui se serait écrit comme cela dans « l’ancien système » :

    @cocotb.test()
    def my_first_test(dut):
        """Try accessing the design."""
         dut._log.info("Running test!")
         for cycle in range(10):
             dut.clk <= 0
             yield Timer(1, units='ns')
             dut.clk <= 1
             yield Timer(1, units='ns')
         dut._log.info("Running test!")

Cette écriture restant cependant valable.

Le gros avantage de cette nouvelle écriture est de ne plus avoir a réinventer la roue avec des décorateurs inutiles. Avec async et await, on utilise des interfaces intégrées à Python 3, ce qui évite tout un travail de gestion.

Installation

CocoTB est, depuis maintenant un certain temps, partie intégrante du système de gestion de paquets de Python pip. Et vous pouvez dès à présent l’installer sur votre système via la commande pip install :

    $ python -m pip install cocotb
    # Pour celles et ceux qui ont installé la version précédente n’oubliez pas le --upgrade
    $ python -m pip install --upgrade cocotb

Et on peut vérifier la version grâce à la commande cocotb-config suivante :

cocotb-config --version
1.4.0

En plus de votre composant écrit en VHDL ou Verilog, deux fichiers supplémentaires sont nécessaires pour tester avec CocoTB : le Makefile et le script Python de test proprement dit.

Avec cette nouvelle version, le Makefile a encore été simplifié puisqu’il n’est plus nécessaire d’intégrer les en‑têtes C++. Ces en‑têtes sont nécessaires pour compiler les interfaces VPI/VHPI/FLI qui permettent de piloter les simulateurs. On compile désormais cette partie à l’installation de CocoTB. Dans les précédentes version, cette compilation ce faisait à chaque fois que l’on relançait les tests.

Si l’on prend l’exemple de l’antirebond en Verilog du Blinking Led Project, nous avons le Makefile suivant :

    SIM=icarus                                   # Nom du simulateur
    export COCOTB_REDUCED_LOG_FMT=1              # Pour avoir des traces de log qui rentre dans l’écran
    VERILOG_SOURCES = $(PWD)/../src/button_deb.v # Inclusion des fichiers HDL
    TOPLEVEL=button_deb                          # Nom de l’entité 
    MODULE=test_$(TOPLEVEL)                      # Nom du script Python de test
    include $(shell cocotb-config --makefile)/Makefile.sim

L’exemple est un composant permettant de ne pas compter les rebonds d’un bouton comme des appuis successifs.
Le script de test en Python se trouve dans le dépôt Git du projet et se nomme test_buton_deb.py. Pour le lancer, il suffit de se rendre dans le répertoire blp/verilog/cocotb/ et de taper make :

     $ make
     [...]
     0.00ns INFO     Running test!
     0.00ns INFO     freq value : 95000 kHz
     0.00ns INFO     debounce value : 20 ms
     0.00ns INFO     Period clock value : 10000 ps
     0.02ns INFO     Reset complete

Un fichier de traces (chronogrammes) button_deb.vcd au format VCD est créé. Il peut être visionné en « temps réel » alors même que la simulation n’est pas terminée, grâce au visualiseur gtkwave :

   $ gtkwave button_deb.vcd
Vue de traces VCD avec GTKWave

Une organisation qui tourne

Le projet CocoTB est chapeauté par la FOSSi foundation qui fournit le « chef de projet » Philipp Wagner ainsi que des moyens financiers pour faire tourner des machines virtuelles de tests ainsi que pour payer les licences des simulateurs commerciaux.

Les statistiques de modification de cette version sont les suivantes :

  • 346 fichiers modifiés, 14 012 insertions (+), 10 356 suppressions (−) ;
  • 554 commits ;
  • 31 contributeurs ;
  • 2 nouveaux mainteneurs : Colin Marquardt et Kaleb Barrett.

Ces chiffres montrent que CocoTB est un projet qui fédère désormais une grosse communauté. C’est un projet mature qui compte dans le paysage des logiciels libres pour le matériel (FPGA et ASIC).

Google libère les ASIC avec un PDK open source en 130 nm

[Dépêche publiée initialement sur LinuxFR]

La libération des FPGA s’accélère à grands pas, il devient presque difficile de suivre toutes les nouvelles sur le sujet. Mais les FPGA ne doivent pas nous faire oublier leurs grands frères que sont les ASIC.
Un FPGA est un composant ayant un silicium déjà « gravé » mais où il est possible de reconfigurer les connexions entre les éléments logiques à volonté. Dans le cas d’un ASIC, on va cette fois graver directement les transistors sur un silicium vierge et les relier via des couches métaliques une fois pour toutes. Il ne faut surtout pas se planter à l’étape de conception car on ne pourra pas modifier les interconnexions une fois la production lancée.

Pour réaliser un ASIC, il faut fournir un plan des masques de chaque couche de dopage du silicium ainsi que des couches métaliques. Voici par exemple la représentation d’une bascule D :
Une bascule D

Pour ce faire, on va partir d’une description RTL (Register Transfert Level) du composant, similaire aux descriptions utilisées pour les FPGA – la plupart du temps du Verilog ou du VHDL — que nous allons « synthétiser » en une Netlist. La suite va ressembler (de loin) à du placement‐routage et de la simulation analogique‐numérique, comme on peut le voir avec la conception de carte électronique.

Le flot de conception typique du monde du matériel est donné dans une des diapositives de la présentation de Tim Ansell ci‑dessous :
Flot de développement ASIC/FPGA

La partie langage de description du matériel et simulation est déjà largement libérée. Il existe des tas de composants open source décrits en VHDL et/ou en Verilog à présent. Les outils de synthèse libres arrivent aujourd’hui à maturité avec Yosys, bien sûr, pour le Verilog (et bientôt mature pour le VHDL grâce au greffon GHDL-yosys), mais aussi Alliance pour le VHDL.

Les trois piliers logiciels (EDA pour les outils, PDK les données et RTL le design) permettant de réaliser un ASIC sont donnés dans une autre diapo de Tim ci‑dessous :
Schéma de principe développement ASIC

Une fois la description « RTL » du composant synthétisée, il nous reste beaucoup d’étapes à franchir avant d’obtenir une description des masques de gravure permettant la fabrication proprement dite. Toutes ces étapes nécessitent l’utilisation de logiciels spécifiques pour réaliser les masques, construire l’arbre d’horloge, simuler en analogique certaines parties, concevoir les alimentations… Beaucoup de logiciels libres existent pour cela, tous ne sont pas matures ou restent très universitaire dans leur version open source. Mais il est possible de les utiliser tout de même pour réaliser un composant, comme l’a démontré Tim Edwards avec le Raven (un microcontrôleur RISC‑V à base de PicoRV32).

Cependant, même s’il n’a utilisé que des logiciels libres pour réaliser le Raven, Tim n’a pas pu accéder à la description physique des composants numériques qu’il utilisait. Il a dû se contenter de « boîtes noires » représentant chaque fonction logique à assembler pour réaliser le microcontrôleur. En effet, tous ces logiciels libres demeurent quasiment inutiles si l’on n’a pas accès à la description physique de la technologie cible utilisée. Les fondeurs de silicium fournissent un PDK (process design kit) contenant des bibliothèques de composants avec la description physique de leurs technologies, ainsi que la géométrie de chaque transistor et les modèles de simulations spice permettant de valider le comportement analogique. Et pour avoir accès à ces PDK, la vente de vos deux reins ne suffira pas, même si vous signez les triples NDA (accord de non‑divulgation) avec votre sang. Ce PDK reste le gros frein à la libération du matériel, un caillou dans la chaussure du matériel libre. C’est ce que Google a bien compris en finançant le développement d’un PDK libre via la société SkyWater : le SKY130.

La publication du SKY130 vient d’être annoncée cette semaine par Tim Ansell lors d’un « dial‑up » de la FOSSi Foundation. Comme son nom l’indique, ce PDK cible la technologie 130 nm. Cette taille de gravure peut sembler obsolète quand on sait qu’Intel fabrique de plus en plus en 7 nm, et commence même à tester le 4 nm. Mais les chaînes de fabrication de silicium avec cette finesse de gravure permettent un coût de production très raisonnable pour des performances qui ne sont pas non plus ridicules. SiFive, par exemple, a sorti un microcontrôleur 32 bits RISC‑V (E310) gravé en 180 nm et tout de même cadencé à 320 MHz. Il est donc possible de réaliser beaucoup de chose avec du 130 nm.

Et pour promouvoir son PDK et fédérer une communauté de passionnés, hobbyistes, universitaires, « startupeuses », etc., Google a décidé de produire quarante projets à base de ce PDK tous les six mois et gratuitement. Le premier « shuttle » est prévu pour novembre. Pour être dans le wagon, il faut que son projet soit open source et le soumettre au site en ligne efabless.com. Visiblement, la méthode de choix des projets retenus n’est pas encore bien définie ; mais si vous êtes retenu, vous aurez une réponse par courriel.

Il est temps pour LinuxFr.org de faire passer TapTempo dans une autre sphère que le simple programme en Brainfuck et de proposer un composant électronique TapTempoASIC !

Et pourquoi ne pas proposer un FPGA en 130 nm ? Même si aujourd’hui les FPGA sont plus proches du 40 nm, un FPGA open source comme le kFPGA de killruana, ça aurait la classe.

Aller plus loin