CocoTB 1.4.0, la maturité

Posté par  (site Web personnel) . Édité par palm123, Davy Defaud et Nils Ratusznik. Modéré par Xavier Claude. Licence CC By‑SA.
Étiquettes :
26
17
juil.
2020
Matériel

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).

Aller plus loin

  • # CocoTB + tkinter pour rendre les simulations plus vivantes

    Posté par  (site Web personnel) . Évalué à 6 (+5/-0).

    J'ai commencé à utiliser CocoTB pendant le confinement, dans le cadre d'un enseignement à distance du VHDL.

    Habituellement, nous utilisons la suite Vivado de Xilinx pour la simulation et la synthèse, et des cartes Digilent pour les essais avec du vrai matériel.
    Pendant le confinement, il était impossible de fournir des cartes à tous les étudiants. Nous ne pouvions faire que de la simulation. Sachant que les étudiants travaillaient avec leur ordinateur personnel, j'ai rapidement écarté Vivado pour trois raisons :

    • Il n'est pas disponible sous OS X.
    • L'installation nécessite 20 Go d'espace disque libre.
    • Et surtout, la simulation sous Vivado n'est pas interactive : certes, on peut écrire un banc de test et afficher des chronogrammes, mais on ne peut pas créer une interface graphique avec des widgets simulant les entrées/sorties de la carte, comme on peut le faire par exemple avec le simulateur commercial Modelsim.

    Je me suis orienté vers une solution utilisant GHDL, GtkWave, CocoTB et tkinter.
    CocoTB est utilisé de deux manières :

    • D'abord pour automatiser des tests, ce qui est sa raison première.
    • Mais aussi pour faire l'interface entre, d'une part de petites interfaces graphiques écrites en Python avec tkinter (avec des boutons, des interrupteurs, des LED ou des afficheurs 7 segments), et d'autre part l'entité principale VHDL simulée par GHDL.

    Dans le premier cas, on veut que la simulation soit la plus rapide possible ; le temps simulé est relativement indépendant de la durée que prend le simulateur pour exécuter le design.
    Dans le deuxième cas, au contraire, si la description VHDL prévoit qu'une LED clignote toutes les secondes, on veut la voir clignoter à la bonne vitesse sur l'interface graphique. Il a fallu tricher un peu, et ça n'a pas toujours bien fonctionné lorsque les performances des PC des étudiants n'étaient pas suffisantes.

    En quelque sorte, CocoTB a sauvé nos TP de VHDL, et je pense même continuer à l'utiliser l'année prochaine.

    • [^] # Re: CocoTB + tkinter pour rendre les simulations plus vivantes

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 18/07/20 à 22:43.

      Super, merci pour ce retour d'expérience.
      En ce qui concerne la rapidité d’exécution du simulateur, pour avoir du «temps presque réel» il faut se tourner vers Verilator. C'est du Verilog mais avec l'avancée du plugin yosys-ghdl il doit même être possible d'écrire son composant en VHDL et de le convertir en Verilog.

      Même si pour le moment mes expérimentations de verilator avec cocotb ne sont pas super concluantes niveau temps d'exécution. Je pense que j'ai des configurations à revoir.

      Dans tout les cas, verilator avec un banc de test en C++ est ce qu'il y a de plus rapide sur le «marché».

Envoyer un commentaire

Suivre le flux des commentaires

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