Verilator 4.002

Posté par  (site web personnel, Mastodon) . Édité par Davy Defaud, BAud, ZeroHeure, bubar🦥, palm123 et Benoît Sibaud. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
29
24
sept.
2018
Matériel

La version 4.002 de Verilator a été annoncée à la conférence ORConf2018 en Pologne.

Verilator est sans conteste le simulateur HDL open source le plus rapide du « marché ». Il permet de simuler des porte‐grammes écrits en Verilog synthétisable.

Le nouveau logo de Verilator

Synthétisable ? Ce point est important. En effet, le langage Verilog (tout comme son homologue VHDL) permet de décrire des modèles de circuits numériques destinés à être utilisés dans des FPGA mais aussi des ASIC. En plus de la partie « modélisation », Verilog (comme VHDL) inclut la partie tests. On peut donc écrire tout notre testbench en Verilog, puisque nous avons des fonctions d’affichage, d’accès aux fichiers, etc. Cependant, seule une sous‐partie du langage Verilog est capable de décrire le circuit final, c’est ce qu’on appelle la partie « synthétisable » car elle peut être synthétisée en un schéma électronique numérique.

Si verilator n’est capable de prendre en entrée que du Verilog synthétisable, c’est parce qu’il convertit ce code en un objet en C++ et/ou SystemC (le SystemC n’étant qu’une bibliothèque C++). La partie code de test sera donc écrite en C++/SystemC et le programme final compilé avec gcc.
Le binaire ainsi compilé peut ensuite être exécuté comme n’importe quel exécutable et lancera la simulation de notre modèle numérique (le porte‐gramme).

Le résultat est un temps de simulation incroyablement plus rapide qu’avec les simulateurs classiques. Le site officiel donne des vitesses 90 fois supérieures au célèbre simulateur Verilog open source Icarus. Personnellement, sur mon porte‐gramme d’anti‐rebond j’obtiens une vitesse 20 fois supérieure, mais c’est en enregistrant des traces très lourdes (700 Mio) permettant de visualiser les signaux une fois la simulation terminée.
Il est possible de faire tourner des modèles de microprocesseurs écrit en Verilog en « temps réel » (à quelques kilohertz).

Concrètement, si l’on prend l’exemple d’un porte‐gramme simple permettant de filtrer les rebonds d’un bouton (pour le code complet c’est par ici). On aura les ports d’entrée‐sortie suivants :

module button_deb(
    // sync design
    input    clk,
    input    rst,
    // in-out
    input    button_in,
    output button_valid);

Une fois « compilé » avec verilator :

verilator -Wall -cc src/button_deb.v --trace --exe test/test_button_deb.cpp

On obtient un objet que l’on peut instancier dans son programme principal :

    Vbutton_deb* top = new Vbutton_deb;

L’accès aux signaux d’entrée‐sortie se fait ensuite simplement comme un accès aux variables de l’objet :

top->rst = 1;
top->button_in = 0;
top->clk = 0;

On évalue les valeurs de sortie par l’appel à la fonction eval() :

top->eval();

C’est cet appel à la fonction eval() qui fera avancer la simulation d’un « pas ». À nous de connaître le temps que nous souhaitons avoir entre deux pas.

Hormis la collection de corrections de bogues, la fonctionnalité majeure de cette nouvelle version est la prise en charge de multiple fils d’exécution (multi‐threads), qui divise encore le temps de simulation de beaucoup, en fonction du nombre de cœurs présents sur sa machine.

Cette nouvelle version de Verilator prouve surtout que ce vénérable projet (créé en 1994 d’après la page Wikipédia) est encore largement actif, il est désormais pris au sérieux par tous les concepteurs de matériel. Et si l’on en croit son auteur, la plupart des équipes qui conçoivent des microprocesseurs l’utilisent intensément.

Bref, un très bel exemple d’outil de libération des FPGA. ;)

Aller plus loin

  • # Pourquoi seulement du Verilog synthétisable ?

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 24 septembre 2018 à 08:55.

    Verilator est sans conteste le simulateur HDL open-source le plus rapide du « marché ».

    Dans cette catégorie, il existe également GHDL pour le langage VHDL.
    Existe-t-il un comparatif entre Verilator et GHDL pour des benchmarks équivalents dans les deux langages ?

    Si verilator n'est capable de prendre en entrée que du Verilog synthétisable, c'est parce qu'il convertit ce code en un objet en C++ et/ou SystemC

    Je suis un peu étonné par cette phrase. Si le code Verilog est converti en C++, pourquoi serions-nous limité à du code synthétisable ?

    • [^] # Re: Pourquoi seulement du Verilog synthétisable ?

      Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 24 septembre 2018 à 09:14.

      Existe-t-il un comparatif entre Verilator et GHDL pour des benchmarks équivalents dans les deux langages ?

      Ça n'est pas vraiment comparable dans la mesure où GHDL est un simulateur «complet» qui simule toute la norme VHDL alors que Verilator se contente de la sous-partie «synthétisable».
      J'avais commencé à faire un comparatif verilator/icarus avec mon projet blp (blinking led project), il faudrait que j'ajoute GHDL au comparatif. Mais je suis certain que GHDL sera nettement plus lent que Verilator, le comparatif Icarus/GHDL serait plus pertinent.

      Il existe un projet d'adapter verilator (verilatorVHDL) pour supporter le VHDL, mais il n'est pas encore abouti à ma connaissance.

      Si verilator n'est capable de prendre en entrée que du Verilog synthétisable, c'est parce qu'il convertit ce code en un objet en C++ et/ou SystemC

      Je suis un peu étonné par cette phrase. Si le code Verilog est converti en C++, pourquoi serions-nous limité à du code synthétisable ?

      La différence fondamentale entre un simulateur «normal» et verilator (au dela du fait qu'il ne fasse que convertir le modèle en un objet C++) est qu'il ne gère pas le temps !

      Pour faire tourner le simulateur, on écrit des valeurs sur les ports d'entrées de notre design, on appel la fonction «eval()» qui va évaluer les valeurs de sorties. Puis on recommence.
      C'est à nous de gérer le temps en appelant la fonction eval() à interval régulier. Tous les #xx sont ignorés.

      J'ai plus qu'une balle

    • [^] # Re: Pourquoi seulement du Verilog synthétisable ?

      Posté par  . Évalué à 5.

      Dans cette catégorie, il existe également GHDL pour le langage VHDL.
      Existe-t-il un comparatif entre Verilator et GHDL pour des benchmarks équivalents dans les deux
      langages ?

      Il n'existe pas de comparatif direct mais Verilator est plus rapide vu qu'il utilise un algorithme de scheduling statique des évenements contrairement à GHDL ou Icarus Verilog qui se base sur une liste d'évènements à venir.

      Si verilator n'est capable de prendre en entrée que du Verilog synthétisable, c'est parce qu'il
      convertit ce code en un objet en C++ et/ou SystemC

      Je suis un peu étonné par cette phrase. Si le code Verilog est converti en C++, pourquoi serions-
      nous limité à du code synthétisable ?

      C'est un des choix de design de Verilator qui n'est pas lié a SystemC ou C++. Verilator a choisi de ne pas supporter certaines features du langage pour augmenter la rapidité.

      Verilator gagne en performance du fait que la granularité des évènements est connue, il évalue le design uniquement sur un changement de clock. Il schedule et optimise les évènements intermédiaires à la compilation plutôt qu'à l'exécution.

      • [^] # Re: Pourquoi seulement du Verilog synthétisable ?

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 24 septembre 2018 à 10:57.

        Verilator gagne en performance du fait que la granularité des évènements est connue, il évalue le design uniquement sur un changement de clock. Il schedule et optimise les évènements intermédiaires à la compilation plutôt qu'à l'exécution.

        OK. Merci pour ces précisions.

Suivre le flux des commentaires

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