Archives par mot-clé : verilog

Les BlackBox et RawModule de Chisel3

Quelque soit le langage HDL utilisé il est très important de se garder la possibilité d’intégrer des modules provenant d’autre langages et/ou n’ayant pas de descriptions HDL.

C’est par exemple le cas des primitives matériel permettant d’instancier des modules intégrés au FPGA du constructeur au moyen de «template» Verilog : sérialiseur/désérialiseur, PLL, entrées/sorties spécifiques, …

BlackBox

Pour intégrer ce genre de module dans son projet Chisel3 on utilise des «BlackBox».  L’idée est de décrire les entrées/sorties du module ainsi que ses paramètres, et Chisel se chargera de convertir ça en une déclaration Verilog.

Le problème est assez classique sur les kits de développement de Xilinx qui sont cadencé par une horloge différentielle : Obligé d’instancier un buffer différentiel pour pouvoir récupérer l’horloge. Ce qui n’est pas prévu dans la classe Module de base de Chisel3 puisque l’horloge − tout comme le reset − est implicite.

D’après la documentation Xilinx, le buffer différentiel IBUFDS doit être instancié de la manière suivante en Verilog pour que le logiciel de synthèse le repère et l’instancie correctement:

IBUFDS #(
    .DIFF_TERM("TRUE"),
    .IOSTANDARD("DEFAULT")
) ibufds (
    .IB(ibufds_IB),
    .I(ibufds_I),
    .O(ibufds_O));

Cette instanciation est composée de deux paramètres «generic» et de trois entrées sorties.

Une BlackBox() se comporte comme un Module() sans les horloges et reset implicites. De plus le nom des IO est recopié tel quel par Chisel, il n’ajoute pas le préfixe «io_» comme pour un module normale.

Pour déclarer ce buffer différentiel en Chisel il suffira donc d’écrire le code suivant:

import chisel3._
import chisel3.util._
import chisel3.experimental._

class IBUFDS extends BlackBox(
    Map("DIFF_TERM" -> "TRUE",
        "IOSTANDARD" -> "DEFAULT")) {
    val io = IO(new Bundle {
        val O = Output(Clock())
        val I = Input(Clock())
        val IB = Input(Clock())})
}

Le Map en paramètre de la class BlackBox() permet d’ajouter les paramètres «generic» et les entrées sortie sont déclarés par la variable io.

Il suffira alors de l’instancier dans notre module top :

val ibufds = Module(new IBUFDS)
ibufds.io.I := clock_p
ibufds.io.IB:= clock_n

Pour que le code Verilog soit correctement écrit dans le fichier final.

Top RawModule

Maintenant que nous avons notre entrée d’horloge, notre but est d’aller faire clignoter une led (quelle originalité !) en utilisant un compteur. Avec le module suivant:

class Blink extends Module {
    val io = IO(new Bundle {
        val led = Output(Bool())
        })

    val MAX_COUNT = 100000000

    val count = Counter(MAX_COUNT)

    count.inc()

    io.led := 0.U
    when(count.value <= UInt(MAX_COUNT)/2.U){
    io.led := 1.U
    }
}

Ce module étant un module «normal» l’horloge et le reset sont implicite, alors comment allons nous faire pour qu’il soit cadencé par la sortie du buffer IBUFDS ?

On peut simplement les intégrer dans un Module() classique que l’on appellera Top :

class Top extends Module {
  val io = IO(new Bundle {
    val clock_p = Input(Clock())
    val clock_n = Input(Clock())
    val led     = Output(Bool())
  })

  val ibufds = Module(new IBUFDS)
  ibufds.io.I := io.clock_p
  ibufds.io.IB:= io.clock_n

  val blink = Module(new Blink)
  blink.clock := ibufds.io.O
  blink.reset := 1'0
  io.led := blink.io.led }

Notez que pour connecter explicitement l’horloge, la technique est en phase de développement mais il faut désormais utiliser la classe withClockAndReset()  pour faire les choses proprement . Plutôt que :

  val blink = Module(new Blink)
  blink.clock := ibufds.io.O
  blink.reset := false.B
  io.led := blink.io.led

Faire :

withClockAndReset(ibufds.io.O, false.B) {
    val blink = Module(new Blink)
    io.led := blink.io.led
  }

Cette méthode va fonctionner mais elle va nous ajouter les signaux clock et reset implicites. Signaux qui ne serviront pas à grand chose dans notre cas et généreront des warning pénible dans le logiciel de synthèse:

module Top(
  input   clock,
  input   reset,
  input   io_clock_p,
  input   io_clock_n,
  output  io_led
);
  wire  ibufds_IB;
  wire  ibufds_I;
  wire  ibufds_O;
  wire  blink_clock;
  wire  blink_reset;
  wire  blink_io_led;
  IBUFDS #(.DIFF_TERM("TRUE"), .IOSTANDARD("DEFAULT")) ibufds (
    .IB(ibufds_IB),
    .I(ibufds_I),
    .O(ibufds_O)
  );
  Blink blink (
    .clock(blink_clock),
    .reset(blink_reset),
    .io_led(blink_io_led)
  );
  assign io_led = blink_io_led;
  assign ibufds_IB = io_clock_n;
  assign ibufds_I = io_clock_p;
  assign blink_clock = ibufds_O;
  assign blink_reset = 1'h0;
endmodule

C’est pour cela qu’une nouvelle hiérarchie de classe est en développement pour les Module().

Un module Top est un module un peu spécial en conception HDL. En effet, ce type de module se contente simplement de «relier des boites entre elles». Ce n’est que du tire-fils, pas besoin d’horloge, de registres et autre structures complexes ici.

Dans la nouvelle hiérarchie des classes Module nous avons donc une nouvelle classe appelée RawModule qui apparaît.  Ce module n’a plus aucun signaux implicite et se contente de relier les fils. Dans le code Chisel précédent nous pouvons juste renommer Module en RawModule pour voir que les signaux reset et clock disparaissent:

class Top extends RawModule {

Nous obtenons alors une entête Verilog plus propre :

module Top(
  input   io_clock_p,
  input   io_clock_n,
  output  io_led
);

Nous avons tout de même ce préfixe «io_» disgracieux qui peu devenir pénible pour l’intégration, notamment dans certaine plate-forme où le pinout est déjà fourni pour des noms de pin précis.

Il est possible de les éviter avec les RawModule simplement en utilisant plusieurs variable IO() sans Bundle :

class Top extends RawModule {
  val clock_p = IO(Input(Clock()))
  val clock_n = IO(Input(Clock()))
  val led = IO(Output(Bool()))

  val ibufds = Module(new IBUFDS)
  ibufds.io.I := clock_p
  ibufds.io.IB:= clock_n

  withClockAndReset(ibufds.io.O, false.B) {
    val blink = Module(new Blink)
    led := blink.io.led
  }
}

De cette manière c’est le nom exact de la variable qui sera pris en compte pour générer le Verilog:

module Top(
  input   clock_p,
  input   clock_n,
  output  led
);

Et voila comment nous pouvons désormais faire un projet proprement écrit en Chisel de A à Z, ce qui n’était pas le cas avant où nous étions obligé d’encapsuler le projet dans des Top.v écrit à la main, et obligé de les modifier à chaque changement d’interface.

Le code décrit dans cet article se retrouve sur le Blinking Led Projet, dans le répertoire platform. Pour pouvoir le tester correctement, ne pas oublier de télécharger sa propre version de Chisel3 et de merger la branche modhier comme expliqué dans le README.

SpinalHDL va-t-il remplacer Chisel ?

SpinalHDL est un langage HDL ressemblant à s’y méprendre à Chisel. Et pour cause, son créateur est un ancien utilisateur intensif de Chisel.

  • Tout comme Chisel, SpinalHDL est basé sur le langage Scala.
  • Tout comme Chisel, les entrées/sorties sont décrites au moyen de Bundles.
  • Tout comme Chisel, Spinal génère un langage HDL pour la synthèse.

Alors pourquoi ne pas utiliser Chisel ?

  • Car SpinalHDL génère du VHDL pour la synthèse, et non du Verilog
  • Car SpinalHDL gère les domaines d’horloges de manière élégante
  • Car la déclaration des entrées sortie est plus «naturelle» pour un habitué de VHDL/Verilog. En effet, pour déclarer les des signaux comme entrée ou sortie d’un module sur Chisel il faut faire :
    
       val io = new Bundle {
         val a = Bool(INPUT)
         val b = Bool(INPUT)
         val c = Bool(OUTPUT)
       }
    

    Alors que sur SpinalHDL on fera:

    
       val io = new Bundle {
         val a = in Bool
         val b = in Bool
         val c = out Bool
       }
    

    Ce qui est plus naturel.

  • La gestion des blackbox est mieux intégrée.

De plus, Charles (dolu1990) m’informe qu’il y a maintenant une implémentation de RISCV avec 5 étages de mul/div/interruptions fonctionnel en SpinalHDL:

Bonjour,

Flash info Spinal XD
Il y a maintenant une implémentation de RISCV, 5 stages mul/div/interrupt
fonctionnel codée en Spinal.
Le cpu égualement débuggable via JTAG, fork openOCD, GDB et eclipse. (c'est
a ma connaissance la seul implémentation RISCV qui cible les FPGA avec
cette fonctionnalité)

Au plaisir de libérer les FPGA de leur asservissement.
Charles

Bref pas mal de choses intéressantes qui j’espère dynamiserons le développement de Chisel également et peut-être fusionnerons à terme ?

Pour la documentation officielle c’est par là.

Non non, vhd2vl n’est pas mort, contrairement à ce qui a été dit dans l’article de description du projet. Son auteur Larry Doolittle a publié une nouvelle version 2.5 l’été dernier (2015).

Et pour simplifier le développement collaboratif de ce programme un github a été ouvert. Comme il le dit sur sa page personnel du projet, Larry souhaite simplement intégrer son outils dans icarus (vhdlpp) de manière à pouvoir faire de la simulation VHDL avec. Mais pour faire une simple conversion VHDL->Verilog, vhd2vl est toujours d’actualité.

Fizzim, des machines d’états sans se fatiguer

Fizzim est un petit logiciel graphique écrit en Java permettant de dessiner des machines d’états. Ce qui le différencie des autres logiciels de «dessin» c’est que Fizzim est capable de générer le code Verilog et/ou VHDL synthétisable correspondant.

fizzimtest

Installation

L’archive est disponible sur le site officiel. Pour l’installer sous Linux, il suffit de la télécharger et de la dezziper dans le répertoire de son choix :

$ mkdir fizzim
$ cd fizzim
$ wget wget http://www.fizzim.com/mydownloads/fizzim_520.zip
$ unzip fizzim_520.zip

La documentation est disponible sous la forme d’un pdf. C’est un programme écrit en java il faut donc lancer «l’executable» avec la machine virtuelle java :

$ java -jar fizzim_v14.02.26.jar

Fizzim enregistre ses projets avec un format *.fzm. Pour générer du code Verilog ou VHDL il faut utiliser le script perl fourni :

$ perl fizzim.pl < test.fzm > test.v

Pour le VHDL faire:

$ perl fizzim.pl -language VHDL < test.fzm > test.vhd

Un petit programme qui ne paye pas de mine mais qui est bien utile, surtout que le développement FPGA fait un usage intense des machines d’états.

Une nouvelle release d’icarus verilog est désormais disponible sur le ftp officiel.

Pour l’installer sous linux, rien de plus simple :

$ wget ftp://icarus.com/pub/eda/verilog/v10/verilog-10.0.tar.gz
$ tar -zxvf verilog-10.0.tar.gz
$ cd verilog-10.0/
$ ./configure
$ make
$ sudo make install

Vérifier la bonne installation avec :

$ iverilog -v
Icarus Verilog version 10.0 (stable) (v10_0)

Copyright 1998-2015 Stephen Williams

  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License along
  with this program; if not, write to the Free Software Foundation, Inc.,
  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

iverilog: no source files.

Usage: iverilog [-ESvV] [-B base] [-c cmdfile|-f cmdfile]
                [-g1995|-g2001|-g2005|-g2005-sv|-g2009|-g2012] [-g]
                [-D macro[=defn]] [-I includedir]
                [-M [mode=]depfile] [-m module]
                [-N file] [-o filename] [-p flag=value]
                [-s topmodule] [-t target] [-T min|typ|max]
                [-W class] [-y dir] [-Y suf] source_file(s)

See the man page for details.

Synchronisation d’un signal externe avec Chisel

Quand on récupère un signal extérieur au fpga dont on ne maitrise pas le timing d’arrivée des fronts — typiquement un bouton ou une interruption — il est nécessaire de le synchroniser par rapport à l’horloge qui cadence le FPGA.

Il faut donc utiliser le montage classique des deux bascules. En Verilog et en VHDL cela se traduit par la déclaration d’un signal intermédiaire permettant la connection entre les deux bascules:

reg tmp, sig_s;

always @(posedge clk)
 begin
    tmp <= sig;
    sig_s <= tmp;
 end

Avec Chisel l’exemple donné dans le tutorial (page 14) est assez décevant car il impose aussi l’utilisation d’un signal intermédiaire :

s1 :=  signalA
s2 := s1;
signalB := s2

Pourtant il existe une méthode un peu plus élégante ne nécessitant qu’une seule ligne de code si on regarde du coté de la classe ChiselUtil : ShiftRegister()

Cette fonction permet de décaler un signal du nombre de coup d’horloge donné en argument, la synchronisation d’un signal par une double bascule n’étant rien de plus qu’un registre à décalage de deux coups d’horloge il suffit donc de l’utiliser avec un décalage de 2 :

val  sig_s = ShiftRegister(sig, 2)

Si on regarde le Verilog généré par le backend on obtient bien les deux bascules souhaitées:

always @(posedge clk) begin
[...]
sig_s <= R23;
R23 <= sig;
[...]
end

Voila qui nous simplifie grandement les design, et évite l’empilement des copier/coller de signaux temporaire pour synchroniser des grappes de signaux.

FPGA Prototyping By Verilog Examples: Xilinx Spartan-3 Version

 

185322_cover.indd

Très bon début pour commencer le Verilog pour le FPGA. Ce livre ne s’attarde pas trop sur les arcanes du langage, mais se contente de décrire les structures essentielles pour être rapidement opérationnel dans la conception de designs FPGA en Verilog.

Les exemples sont données pour le Spartan3 de chez Xilinx. Cependant ils sont de bonnes bases pour développer sur n’importe quel autre FPGA, même d’une autre marque.

Et si vous préférez vous mettre plutôt au VHDL, sachez qu’il existe exactement le même livre en version VHDL.

Projet IceStorm : le FPGA libéré !

Le jour du 27 mai 2015 sera à marquer d’une pierre blanche, en effet, c’est le jour où un FPGA a été libéré du joug des logiciels privateurs.

C’est le jour où Wolf Clifford a sorti une première version fonctionnelle du projet IceStorm permettant de synthétiser un design écrit en Verilog via Yosys et de faire le placement routage grâce à Arachne-pnr.

La conversion en bitstream et la programmation du chip se fait grâce aux utilitaires icepack et iceprog du projet IceStorm.

Pour l’instant le composant ciblé est le Lattice iCE40 HX1K-TQ144 pouvant être trouvé sur le kit d’évaluation lowcost (~$20) iCEstick.

Voici ci-dessous un petit howto rapide permettant de faire les manipulations se trouvant dans la vidéo de Clifford.

Icestorm howto

  • Installation de Yosys
$ cd /opt
$ git clone https://github.com/cliffordwolf/yosys.git 
$ yosys_deps="build-essential clang bison flex libreadline-dev gawk
	       tcl-dev libffi-dev git mercurial graphviz xdot pkg-config python"
$ sudo apt-get install $yosys_deps
$ make config-gcc
$ make
$ make test
$ sudo make install
  • Installation d’IceStorm
$ sudo apt-get install libftdi-dev
$ cd /opt/
$ mkdir icestorm
$ wget http://www.clifford.at/icestorm/icestorm-snapshot-150526.zip
$ unzip icestorm-snapshot-150526.zip
$ make
$ sudo make install
  • Et enfin arachne-pnr
$ cd /opt/
$ git clone https://github.com/cseed/arachne-pnr.git
$ make && sudo make install
  • Synthèse, placement-routage, bitstream et programmation

Un exemple de «programme» est donné avec arachne-pnr dans le répertoire
example/rot. Cet exemple est composé du source en vérilog rot.v ainsi que du
placement des pin rot.pcf.

  • Synthèse (Génération du blif)
$ cd /opt/arachne-pnr/example/rot/
$ yosys -p "synth_ice40 -blif rot.blif" rot.v
  • Placement routage (Génération du txt)
$ arachne-pnr -d 1k -p rot.pcf rot.blif -o rot.txt

Le fichier généré rot.txt est la description finale du placement et du routage
du design dans le fpga. Cette description est parfaitement lisible en ascii
avec n’importe quel éditeur de texte.
Pour le télécharger dans le fpga nous devons le convertir en format binaire au
moyen de la commande «icepack» :

$ icepack rot.txt rot.bin

Nous avons un bitstream parfaitement compatible avec le ice40, il
nous faut maintenant le télécharger dans le fpga.
Et même pour cela, un logiciel libre est fourni : iceprog !

$ sudo iceprog rot.bin

On peut faire le tout en une seule ligne aussi si on veut :

yosys -p "synth_ice40 -blif rot.blif" rot.v;arachne-pnr -d 1k -p rot.pcf rot.blif -o rot.txt;icepack rot.txt rot.bin;sudo iceprog rot.bin

Et voila, bienvenue dans ce monde nouveau du FPGA libre !

Icarus vs Verilator

Plusieurs solutions de simulations s’offrent à nous quand on développe un composant en Verilog. On peut écrire le testbench en Verilog, de manière à être compatible avec la plupart des simulateurs du marché. Dans ce cas, le simulateur libre le plus célèbre est Icarus.

Mais la solution du «tout Verilog» est relativement lente en temps de simulation, et l’utilisation du langage Verilog est restrictive,  en effet il n’est pas facile de s’approprier toutes les subtilités du langage.

C’est là que la solution de Verilator devient très intéressante. Verilator permet de convertir un modèle de composant écrit en Verilog synthétisable en un modèle C++. De cette manière, écrire le code du testbench revient à instancier notre composant dans un main() en C++ et à décrire nos tests avec toute la liberté qu’offre ce langage.

Mieux encore, il est possible d’écrire notre testbench en SystemC, et de profiter ainsi de cette librairie conçue pour la simulation de circuit numérique.

L’idée va être ici de mesurer le temps effectif de simulation de chacune de ses deux solutions. On se servira pour cela du composant d’antirebond du projet «blinking led project» (blp) disponible sur github.

Le composant synthétisable

Le composant button_deb commute sa sortie button_valid à chaque front montant du signal d’entrée button_in. Pour que le fonctionnement soit un peu plus complexe qu’une simple commutation, et surtout pour bien coller au fonctionnement réel, le composant est muni d’un antirebond de 20 ms (par défaut). Quand le premier front survient, un compteur est déclenché et aucun autre front n’est pris en compte pendant 20 ms.

Voici ce que cela donne avec gtkwave:

blp_button_deb
Chronogramme du testbench avec GTKwave

Le testbench verilog (Icarus)

Tout comme en VHDL, un testbench en Verilog se présente sous la forme d’un module sans entrée/sortie.

La première chose à définir est le temps, avec la directive `timescale:

`timescale 1ns/100ps;

Le premier chiffre indique le pas de simulation, cela correspondra au temps d’attente que l’on retrouvera tout au long du code avec l’«instruction» ‘#’.  Le deuxième nombre indique la précision maximum.

Par exemple, pour simuler l’horloge à 95Mhz on écrira :

/* Make a regular pulsing clock. */
always
    #5.263158 clk = !clk;

Mais comme la précision indiquée en début de code est de 100ps, seule le 5.2 sera pris en compte pour la simulation, ce qui dans notre cas est tout à fait suffisant.

La simulation de l’appui sur le bouton avec rebond se fait ensuite dans un process que l’on appel souvent «stimulis» par convention :

/* Stimulis */
initial begin
    $display("begin stimulis");
    $dumpfile("simu/button_deb_tb.vcd");
    $dumpvars(1, clk, rst, button_in, button_valid, button);
    $monitor("At time %t, value = %h (%0d)",
        $time, button_in, button_in);
[...]
end

Le Verilog fourni tout un tas de primitive permettant de simplifier le debuggage. Notamment $display() et $monitor(), pour afficher du texte pendant la simulation. $display() ne fait qu’afficher du texte au moment où la fonction est appelée, alors que monitor va afficher le texte à chaque changement d’état de ses paramètres.

Les functions $dump* permettent de définir le format de fichiers des traces ainsi que les signaux a dumper. Dans ce cas précis on choisira le format vcd qui est un format non compressé, de manière à améliorer la comparaison avec verilator qui lui ne sait faire que du vcd. Mais cela génère vite de très gros fichiers, il sera préférable d’utiliser le format compressé lxt2, fst ou fsdb pour des simulations plus longues.

Pour factoriser un peu de code d’attente on décrit des tâches d’attentes wait_ms et wait_us :


/* some usefull functions */
task wait_us;
    input integer another_time;
    begin
        repeat(another_time) begin
            # 1_000;
        end
    end
endtask

task wait_ms;
[...]

Tâches qui seront appelées lors de la simulation des rebonds :

[...]
        button_in = 1;
        wait_us(`DEBOUNCE_PER_MS * 8);
        button_in = 0;
        wait_us(`DEBOUNCE_PER_MS * 8);
        button_in = 1;
        wait_us(`DEBOUNCE_PER_MS * 10);
        button_in = 0;
        wait_us(`DEBOUNCE_PER_MS * 10);
        button_in = 1;

        wait_ms(`DEBOUNCE_PER_MS * 2);
[...]

Pour lancer notre testbench avec Icarus, la première chose à faire est de compiler le code au moyen de la commande suivante :

iverilog -o simu/button_deb test/test_button_deb.v src/button_deb.v

Icarus va ainsi créer un binaire exécutable nommé simu/button_deb que l’on lancera avec les arguments de dumps:

vvp simu/button_deb -lvcd

Le fichier de traces (VCD) généré fait une taille vénérable de 752Mo et peut être visualisé avec gtkwave en l’indiquant simplement en paramètre de la commande :

gtkwave simu/button_deb_tb.vcd

Sur un Lenovo T430, la simulation prend 1 minute et 17 secondes, ce qui est tout de même relativement lent pour une simulation d’appui sur un boutton 😉

Voyons maintenant ce que nous donne Verilator.

Le testbench C++

Un testbench Verilator se présente sous la forme d’un main() C++. Dans le main() du testbench nous instancierons l’objet correspondant au model verilog transformé par verilator.
Pour cela nous devons donc convertir notre bouton_deb.v en C++ au moyen de la commande Verilator suivante :

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

Cette commande va nous créer un projet avec le code source du modèle ainsi que le makefile pour compiler. Il suffira donc de se rendre dans le répertoire obj_dir et de faire «make» pour compiler le modèle.

Il ne nous restera plus qu’à instancier notre bouton dans notre testbench test_button_deb.cpp :

    Vbutton_deb* top = new Vbutton_deb;

Ainsi que l’objet tfp pour les dump VCD:

    VerilatedVcdC* tfp = new VerilatedVcdC;

Pour simuler notre objet «top» il faut assigner des valeurs aux signaux d’entrées :

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

Puis évaluer les sorties avec la méthode eval() :

        top->eval();

À chaque front d’horloge il faut donc changer la valeur de clk et évaluer :

        top->clk = !top->clk;
        top->eval();

Dans tout ce que nous venons de voir le temps n’intervient pas. En réalité, le temps n’est tout simplement pas géré dans les modèles Verilator, le modèle ne fait qu’évaluer les sorties en fonction des entrées, c’est à nous de gérer le temps comme nous le souhaitons.

Nous allons donc gérer le temps au moment du dump des signaux en lui indiquant le temps en argument:

        tfp->dump(10);

Pour éviter d’avoir à taper tout ça à chaque fois on pourra créer une fonction «time_pass» qui fait passer le temps, avec un compteur global pour incrémenter le temps:

#define BASE_TIME_NS ((1000*1000)/(CLK_FREQ*2))
int base_time = 0;

/* the time is passing */
void time_pass(VerilatedVcdC *tfp, Vbutton_deb *top) {
        top->clk = !top->clk;
        tfp->dump(base_time*BASE_TIME_NS);
        top->eval();
        base_time++;
}

À l’image du testbench verilog, on pourra aussi créer des fonctions d’attente wait_ms et wait_us:

/* wait for us */
void wait_us(VerilatedVcdC *tfp, Vbutton_deb *top, int timeus) {
    int wait_time = 0;
    while((wait_time * BASE_TIME_NS) < (timeus * 1000)) {
        wait_time++;
        time_pass(tfp, top);
    }
}

/* wait for ms */
void wait_ms(VerilatedVcdC *tfp, Vbutton_deb *top, int timems) {
    int wait_time = 0;
    while((wait_time * BASE_TIME_NS) < (timems * 1000 * 1000)) {
        wait_time++;
        time_pass(tfp, top);
    }
}

Le code simulant les rebonds du bouton ressemble ainsi à s’y méprendre au code Verilog:

[...]
        top->button_in = 1;
        wait_us(tfp, top, DEBOUNCE_PER_MS);
        top->button_in = 0;
        wait_us(tfp, top, DEBOUNCE_PER_MS);
        top->button_in = 1;
        wait_us(tfp, top, DEBOUNCE_PER_MS * 5);
        top->button_in = 0;
        wait_us(tfp, top, DEBOUNCE_PER_MS * 5);
        top->button_in = 1;
        wait_us(tfp, top, DEBOUNCE_PER_MS * 8);
        top->button_in = 0;
        wait_us(tfp, top, DEBOUNCE_PER_MS * 8);
        top->button_in = 1;
        wait_us(tfp, top, DEBOUNCE_PER_MS * 10);
        top->button_in = 0;
        wait_us(tfp, top, DEBOUNCE_PER_MS * 10);
        top->button_in = 1;

        wait_ms(tfp, top, DEBOUNCE_PER_MS * 2);
[...]

Pour lancer la simulation on va d’abord compiler le tout :

make -C obj_dir/ -j -f Vbutton_deb.mk Vbutton_deb

Puis le lancer simplement comme un vulgaire binaire exécutable :

./Vbutton_deb

La simulation crée un fichier VCD de 654Mo que nous pouvons visualiser avec gtkwave.
Sur le même Lenovo T430 la simulation ne dure cette fois que 17 secondes, ce qui est très nettement plus rapide qu’Icarus !

Mieux, si on optimise le code à la compilation avec l’option -O3 :

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

Le temps de simulation tombe à 3 secondes !

La rapidité d’exécution est telle que certain réussissent à faire «tourner» un soft-core avec son programme, à des fréquences allant jusqu’à la centaine de kilohertz.

Formidable !

C’est un peu l’expression que l’on a lors des premiers tests de verilator, pouvoir faire de la simulation 20 fois plus rapidement qu’Icarus semble formidable. Surtout quand cela passe par de la simplicité d’écriture du testbench en C++ ou SystemC.

Néanmoins il faut relativiser un peu notre ferveur, Verilator a encore un gros point noir: il ne gère pas le temps. Verilator n’est capable que de gérer des modèle Verilog synthétisable. Mais si ce code synthétisable inclu des primitives du constructeurs : RAM, Multiplieur, … et surtout PLL. Verilator ne sera pas capable de les simuler.

En ce qui concerne les Ram ou les multiplieurs cela ne pose pas trop de problème dans la mesure ou il est assez simple de les inférer. Mais pour les PLL cela devient bien plus compliqué, et je ne parle même pas des composants spécifique au constructeur (Bus serie, transceiver, core, …).

Ce «bug» a été répertorié il y 5 ans déjà mais pour l’instant personne ne semble s’être attelé à la tâche. D’après un des auteur de Verilator ajouter cette fonctionnalité devrait prendre quelques mois de programmation et de test. Mais cela vaudrait quand même le coup !

Alors qui s’y colle ?

vhd2vl: Convertir du vhdl en verilog

vhd2vl est un petit utilitaire écris en C (flex/bison) permettant de convertir du VHDL synthétisable en verilog. La page officiel présente la version 2.4, cette version ne compile qu’avec quelques modification sur une distribution récente.

Une version modifiée pour compiler sur debian jessie se trouve sur le github de Martoni. Pour l’utiliser il suffit de descendre le code avec git :

git clone git@github.com:Martoni/vhd2vl.git

Et faire un simple «make» dans le répertoire src/.

Pour convertir un fichier vhdl en verilog rien de plus simple (on pourra utiliser les exemples se trouvant dans les sources):

vhd2vl exemple.vhd > exemple.v

Le programme fonctionne plutôt bien à condition d’adapter son code vhdl de manière à générer un verilog correct.

En le testant sur mon «blinking led project» (blp), j’ai pu néanmoins constater quelques problèmes comme:

  • Support hasardeux du type CONSTANT: Le type constant est converti en un «reg» ce qui n’est pas reconnu comme une constante par les logiciels de synthèse. On doit pouvoir modifier ça simplement pour qu’il génère un «localparam» par exemple.
  • Pas de warnings sur les mots clef: Les mots clefs en vhdl ne sont pas les même qu’en verilog, vhd2vl ne râle pas quand il y a une variable en vhdl qui est un mot clef en verilog (par exemple avec le mot clef «edge»).
  • Pas de support de l’underscore ‘_’ pour les nombres. En verilog/VHDL on peut mettre des séparateur pour les milliers histoire que ça soit plus lisible 1_000_000, vhd2vl ne comprend pas.
  • Pas de support du type time (unité sec): bon ça c’est un peu tordu, car ça n’est pas synthétisable en l’état de toute manière.

Bref vhd2vl est un petit logiciel comportant peu de fichiers sources : en fait juste deux. S’il ne répond pas tout à fait à nos attentes il est très facile d’aller le modifier pour l’adapter.

Après discussion avec Larry, visiblement la version 2.4 sera la dernière car l’objectif est de l’intégrer au projet icarus verilog. Mais j’ai beau compiler la dernière version du trunk de icarus, je ne parviens pas à faire la même chose avec.

[EDIT 7 janvier 2016] Non non, vhd2vl n’est pas mort, Larry continu a le développer.