Les 10 ans de Cocotb était l’occasion rêvée pour sortir la version 1.8 😉
Archives par mot-clé : icarus
Découverte du FPGA européen, le GateMate de CologneChip
Nous l’attendions depuis au moins deux ans, le FPGA européen GateMate des allemands de CologneChip est désormais disponible dans votre crémerie habituelle.
La dimension européenne de ce FPGA n’est pas la seule nouveauté, c’est également un des premier (mais pas le premier) à privilégier les outils open source pour son utilisation. Que cela soit pour la simulation ou pour la synthèse tous les exemples donnés dans la documentation utilisent des logiciels libres (Icarus, GHDL et surtout Yosys). Même pour la visualisation des chronogrammes, gtkwave est utilisé par défaut en exemple.
[À noter que le kit de développement m’a été offert gracieusement par CologneChip]
Caractéristiques du GateMate
Les caractéristiques du GateMate le positionne au niveau d’un petit Spartan7 de Xilinx ou d’un Trion T20 de Efinix.
Le composant est gravé par GlobalFounderies en 28nm.
La cellule de base est nommée CPE pour «Central Programming Element».
On notera l’absence remarqué de blocs multiplieurs. Cette absence est compensée par le «fast signal path routing» qui permet de chaîner les CPE afin de construire un multiplieur de dimension voulue.
Caractéristiques du kit
Pour le moment, seuls les trois petit FPGA de la gamme GateMate semblent être en production. CologneChip propose un kit de développement muni du plus petit GateMate : le CCGM1A1
La carte de développement possède deux entrées USB:
- une pour l’alimentation
- et une pour la programmation et la communication avec le FPGA (FTDI 2232), mais qui peut également servir d’alimentation.
La magie du logiciel libre openFPGALoader permet de détecter le FPGA directement au branchement:
$ openFPGALoader --detect
Jtag frequency : requested 6.00MHz -> real 6.00MHz
index 0:
idcode 0x20000001
manufacturer colognechip
family GateMate Series
model GM1Ax
irlength 6En effet, avant même la sortie du gatemate, CologneChip avait déjà proposé le support du composant sur le dépot openFPGALoader.
Toolchain
CologneChip fourni un guide d’installation de la chaîne de développement sur son site internet.
Tous les outils sont connus du monde du FPGA opensource et leurs installations sont intensivement décrites dans les différents dépôts des projets.
Si l’on souhaite éviter la case compilation, l’entreprise fournie même des versions binaires. Ces binaires ne sont téléchargeable que via un compte enregistré sur leur site pour le moment. Deux paquets de logiciels sont nécessaires :
- Yosys compilé pour le gatemate: pour la synthèse Verilog
- p_r: le logiciel de placement routage.
Pour le moment, la version binaire proposée en téléchargement sur le site n’est disponible que pour windows. Ces «.exe» s’exécutent cependant parfaitement sous Linux au moyen de l’émulateur wine bien connu des Linuxiens.
L’archive téléchargée se décompresse simplement avec unzip :
$ unzip cc-toolchain-win.zip
Archive: cc-toolchain-win.zip
extracting: cc-toolchain-win/openFPGALoader-mingw64-v.0.8.0+80eeaef.zip
extracting: cc-toolchain-win/p_r-2022.04-001.zip
inflating: cc-toolchain-win/ug1002-toolchain-install-2022-04.pdf
extracting: cc-toolchain-win/yosys-win32-mxebin-0.15+57.zip La version windows de openFPGALoader ne fonctionne pas bien en émulation wine, il est préférable d’en compiler une version à jour à partir des sources officiels.
Pour le reste, on peut s’affranchir de compiler yosys en utilisant celle fournie. Et pour p_r, les sources n’étant pas fournies pour le moment, cette version est la seule que nous pourrons utiliser.
Pour les installer, il suffit de les décompresser :
$ cd cc-toolchain-win/
$ unzip p_r-2022.04-001.zip
$ unzip yosys-win32-mxebin-0.15+57.zipLa notice d’utilisation des commandes est données dans le pdf de l’archive nommé ug1002-toolchain-install-2022-04.pdf.
C’est l’installation la plus simple que j’ai pu avoir à faire pour des outils de développement FPGA. La place occupée sur le disque dur de son ordinateur est plusieurs milliers de fois plus petites que les logiciels habituels :
$ cd p_r-2022.04-001/
$ du -sh .
24M .
$ cd yosys-win32-mxebin-0.15+57/
$ du -sh .
32M .
Évidemment, c’est pour seulement un modèle de FPGA, mais cela reste beaucoup plus petit.
Clignotons
Il est temps de rentrer dans le vif du sujet et de faire clignoter les LED. L’exemple donné dans le document ug1002 est trop rapide pour voir les LED clignoter. Nous allons donc faire un clignoteur plus traditionnel comme visible ci-dessous en Verilog :
`timescale 1ns / 1ps
module blink(
input wire clk,
input wire rst,
output reg led
);
localparam MAX_COUNT = 10_000_000;
localparam CNT_TOP = $clog2(MAX_COUNT);
wire i_clk;
reg [CNT_TOP-1:0] counter;
assign i_clk = clk;
always @(posedge i_clk)
begin
if (!rst) begin
led <= 0;
counter <= 0;
end else begin
if(counter < MAX_COUNT/2)
led <= 1;
else
led <= 0;
if (counter >= MAX_COUNT)
counter <= 0;
else
counter <= counter + 1'b1;
end
end
endmoduleContrairement à beaucoup de FPGA, le GateMate ne définit pas d’états initial à 0 de ses registres. Une entrée reset est donc nécessaire.
Le pinout est décrit au moyen d’un fichier «ccf» :
## blink.ccf
Pin_in "clk" Loc = "IO_SB_A8" | SCHMITT_TRIGGER=true;
Pin_in "rst" Loc = "IO_EB_B0"; # SW3
Pin_out "led" Loc = "IO_EB_B1"; # D1Une fois que ces deux fichiers sont prêt il suffit de lancer yosys pour la synthèse :
$ wine ../../cc-toolchain-win/yosys-win32-mxebin-0.15+57/yosys.exe -l yosys.log -p 'read_verilog blink.v; synth_gatemate -top blink -vlog blink_synth.v'Wine génère tout un tas d’erreurs mais fini par nous lancer la synthèse tout de même
$ wine ../../cc-toolchain-win/yosys-win32-mxebin-0.15+57/yosys.exe -l yosys.log -p 'read_verilog blink.v; synth_gatemate -top blink -vlog blink_synth.v'
wine: created the configuration directory '/home/oem/.wine'
0012:err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046}
0012:err:ole:marshal_object couldn't get IPSFactory buffer for interface {6d5140c1-7436-11ce-8034-00aa006009fa}
0012:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80004002
0012:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, 80004002
0012:err:ole:get_local_server_stream Failed: 80004002
0014:err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046}
0014:err:ole:marshal_object couldn't get IPSFactory buffer for interface {6d5140c1-7436-11ce-8034-00aa006009fa}
0014:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80004002
0014:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, 80004002
0014:err:ole:get_local_server_stream Failed: 80004002
Could not find Wine Gecko. HTML rendering will be disabled.
Could not find Wine Gecko. HTML rendering will be disabled.
wine: configuration in L"/home/oem/.wine" has been updated.
On ne va pas recopier toute la trace de synthèse ici mais juste la partie ressources utilisées donnée en fin de synthèse :
2.49. Printing statistics.
=== blink ===
Number of wires: 49
Number of wire bits: 294
Number of public wires: 5
Number of public wire bits: 28
Number of memories: 0
Number of memory bits: 0
Number of processes: 0
Number of cells: 159
CC_ADDF 65
CC_BUFG 1
CC_DFF 25
CC_IBUF 2
CC_LUT1 24
CC_LUT2 5
CC_LUT4 36
CC_OBUF 1
2.50. Executing CHECK pass (checking for obvious problems).
Checking module blink...
Found and reported 0 problems.
2.51. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \blink..
2.52. Executing Verilog backend.
2.52.1. Executing BMUXMAP pass.
2.52.2. Executing DEMUXMAP pass.
Dumping module `\blink'.
End of script. Logfile hash: dcf7a4084e
Yosys 0.15+57 (git sha1 207417617, i686-w64-mingw32.static-g++ 11.2.0 -Os)
Time spent: 1% 19x opt_clean (0 sec), 1% 18x opt_expr (0 sec), ...Le fichier de sortie blink_synth.v est au format … Verilog également! C’était bien la peine de lancer Yosys tient !
Mais non, Verilog est un excellent format pour décrire une netlist autant que du RTL. Et de fait, le code Verilog généré n’est pas hyper lisible. Il est constitué d’une série d’instanciations et de connections des primitives du FPGA :
//...
CC_LUT2 #(
.INIT(4'h8)
) _051_ (
.I0(_041_[0]),
.I1(_041_[1]),
.O(_043_[2])
);
CC_LUT4 #(
.INIT(16'h0001)
) _052_ (
.I0(counter[15]),
.I1(counter[20]),
.I2(counter[23]),
.I3(counter[13]),
.O(_041_[0])
);
//...Code qui reste parfaitement simulable avec Icarus pour faire de la simulation post-synthèse comme expliqué dans la documentation officielle.
Maintenant que nous avons notre netlist passons aux choses sérieuses avec le placement routage :
$ wine ../../cc-toolchain-win/p_r-2022.04-001/p_r.exe -i blink_synth.v -o blink -lib ccag
GateMate (c) Place and Route
Version 4.0 (4 April 2022)
All Rights Reserved (c) Cologne Chip AG
...Comme pour la synthèse, nous n’allons pas mettre tous les messages ici. Une des information qui nous intéresse en priorité pour le placement routage est la performance en vitesse.
...
Static Timing Analysis
Longest Path from Q of Component 25_1 to D-Input of Component 33/1 Delay: 18215 ps
Maximum Clock Frequency on CLK 230/3: 54.90 MHz
...La vitesse d’horloge maximale est donc de 54.90Mhz. Cela peut sembler ridicule mais il faut prendre en compte que :
- L’architecture du «clignoteur» avec un énorme compteur pour diviser l’horloge n’est absolument pas optimisée. Pour faire bien il faudrait pipeliner le compteur mais ça n’est pas le sujet ici. Ces mauvais résultats sont cohérent avec ce qu’on pourrait obtenir avec un autre FPGA «mainstream».
- Ces performances sont «conservatrice» c’est le pire cas quand le FPGA est très chaud.
Bref, pour faire clignoter une LED, on peut raisonnablement doubler cette fréquence d’horloge si on veut 🙂 Mais comme nous n’utilisons pas de PLL ici, la fréquence d’entrée de 10Mhz rentre dans la specification.
Les statistiques d’utilisation du FPGA sont données à la fin de la synthèse :
CPE_USAGE_INPUT - CPE_COMBSEQ 1/8 : 0 / 21 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMBSEQ 2/8 : 11 / 21 ( 52.4%)
CPE_USAGE_INPUT - CPE_COMBSEQ 3/8 : 0 / 21 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMBSEQ 4/8 : 0 / 21 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMBSEQ 5/8 : 0 / 21 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMBSEQ 6/8 : 10 / 21 ( 47.6%)
CPE_USAGE_INPUT - CPE_COMBSEQ 7/8 : 0 / 21 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMBSEQ 8/8 : 0 / 21 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMB 1/8 : 3 / 3 ( 100.0%)
CPE_USAGE_INPUT - CPE_COMB 2/8 : 0 / 3 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMB 3/8 : 0 / 3 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMB 4/8 : 0 / 3 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMB 5/8 : 0 / 3 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMB 6/8 : 0 / 3 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMB 7/8 : 0 / 3 ( 0.0%)
CPE_USAGE_INPUT - CPE_COMB 8/8 : 0 / 3 ( 0.0%)
CPE_USAGE_INPUT - CPE COMBSEQ+COMB 1/8 : 3 / 24 ( 12.5%)
CPE_USAGE_INPUT - CPE COMBSEQ+COMB 2/8 : 11 / 24 ( 45.8%)
CPE_USAGE_INPUT - CPE COMBSEQ+COMB 3/8 : 0 / 24 ( 0.0%)
CPE_USAGE_INPUT - CPE COMBSEQ+COMB 4/8 : 0 / 24 ( 0.0%)
CPE_USAGE_INPUT - CPE COMBSEQ+COMB 5/8 : 0 / 24 ( 0.0%)
CPE_USAGE_INPUT - CPE COMBSEQ+COMB 6/8 : 10 / 24 ( 41.7%)
CPE_USAGE_INPUT - CPE COMBSEQ+COMB 7/8 : 0 / 24 ( 0.0%)
CPE_USAGE_INPUT - CPE COMBSEQ+COMB 8/8 : 0 / 24 ( 0.0%)
IO_USAGE : 3 / 144 ( 2.1%) of all IOs
IO_USAGE_TYPE - IBF : 2 / 144 ( 1.4%) of all IOs ( 66.7%) of used IOs
IO_USAGE_TYPE - OBF : 1 / 144 ( 0.7%) of all IOs ( 33.3%) of used IOs
IO_USAGE_TYPE - TOBF : 0 / 144 ( 0.0%) of all IOs ( 0.0%) of used IOs
IO_USAGE_TYPE - IOBF : 0 / 144 ( 0.0%) of all IOs ( 0.0%) of used IOs
CPE_USAGE_PHYS - CPE_COMB_ONLY : 73 / 20480 ( 0.4%) of all CPEs ( 60.3%) of occupied CPEs
CPE_USAGE_PHYS - CPE_SEQ_ONLY : 5 / 20480 ( 0.0%) of all CPEs ( 4.1%) of occupied CPEs
CPE_USAGE_PHYS - CPE_BRIDGE_ONLY : 0 / 20480 ( 0.0%) of all CPEs ( 0.0%) of occupied CPEs
CPE_USAGE_PHYS - CPE_CARRY_ONLY : 0 / 20480 ( 0.0%) of all CPEs ( 0.0%) of occupied CPEs
CPE_USAGE_PHYS - CPE_COMB+SEQ : 10 / 20480 ( 0.0%) of all CPEs ( 8.3%) of occupied CPEs
CPE_USAGE_PHYS - CPE_COMB+BRIDGE : 0 / 20480 ( 0.0%) of all CPEs ( 0.0%) of occupied CPEs
CPE_USAGE_PHYS - CPE_COMBSEQ : 21 / 20480 ( 0.1%) of all CPEs ( 17.4%) of occupied CPEs
CPE_USAGE_LOGIC - CPE_COMB : 8 / 20480 ( 0.0%) of all CPEs ( 6.6%) of occupied CPEs
CPE_USAGE_LOGIC - CPE_SEQ : 15 / 20480 ( 0.1%) of all CPEs ( 12.4%) of occupied CPEs
CPE_USAGE_LOGIC - CPE_COMBSEQ : 21 / 20480 ( 0.1%) of all CPEs ( 17.4%) of occupied CPEs
CPE_USAGE_LOGIC - CPE_BRIDGE : 0 / 20480 ( 0.0%) of all CPEs ( 0.0%) of occupied CPEs
CPE_USAGE_OVERALL : 121 / 20480 ( 0.6%) of all CPEs occupied
CPE_USAGE_LOGIC : 94 / 20480 ( 0.5%) of all CPEs used for customer logic
Component Statistics:
AND 32 19%
ADDF 2 1%
ADDF2 60 37%
C_OR 48 29%
Route1 4 2%
CP_route 15 9%
--------
Sum of COMB: 161
D 25 92%
C_0_1 2 7%
--------
Sum of SEQ: 27
Sum of all: 188
Et le bitstream généré est au format *.cfg (ascii) ou *.cfg.bit (binaire).
$ ls -lha blink_00.*
-rw-rw-r-- 1 oem oem 121K May 1 08:38 blink_00.cdf
-rw-rw-r-- 1 oem oem 1.4M May 1 08:38 blink_00.cfg
-rw-rw-r-- 1 oem oem 48K May 1 08:38 blink_00.cfg.bit
-rw-rw-r-- 1 oem oem 465 May 1 08:38 blink_00.pin
-rw-rw-r-- 1 oem oem 6.0K May 1 08:38 blink_00.place
-rw-rw-r-- 1 oem oem 65K May 1 08:38 blink_00.SDF
-rw-rw-r-- 1 oem oem 42K May 1 08:38 blink_00.used
-rw-rw-r-- 1 oem oem 79K May 1 08:38 blink_00.V
Pour configurer le FPGA nous utiliserons openFPGALoader en «natif» :
$ openFPGALoader -b gatemate_evb_jtag blink_00.cfg.bit
Jtag frequency : requested 6.00MHz -> real 6.00MHz
Load SRAM via JTAG: [==================================================] 100.00%
Done
Wait for CFG_DONE DONE
Et la LED clignote :
Ressources
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 cocotbEt 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.simL’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 completeUn 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
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).
Un ASIC conçu intégralement avec des logiciels libres
Les FPGA sont très liés aux ASIC. En effet, la plupart des outils utilisés en FPGA pour la synthèse HDL, la preuve formel, le placement routage ou l’analyse des timings sont les même que ceux à destination des ASIC. Seuls les librairies et les configurations changent. La grosse différence (de taille) avec les FPGA c’est que l’ASIC n’est pas reconfigurable, et les «frais d’initialisations» sont très élevés. Les délais de productions sont très long également (on parle en trimestre voir en semestre de délais).
Avec de telles contraintes, on comprend pourquoi les développeurs ne se mouillent pas trop avec des logiciels exotiques et restent sur ceux qu’ils connaissent. Vu les tarif de production, le coût des licences des logiciels est assez négligeable. Pourquoi «grenouiller» avec des outils open-source dans ce cas ?
Toutes ces contraintes n’ont pas découragé Tim Edwards de se lancer dans la conception et la fabrication d’un microcontrôleurs intégralement avec des outils open-sources.
C’est comme cela qu’est né le Raven, un microcontrôleur basé sur un cœur picoRV32 (conçu par Clifford Wolf) et réalisé principalement avec les outils qflow d’opencircuitdesign.com :
- Synthèse Verilog : yosys / ABC
- Analyse statique des timings : vesta
- Placement : graywolf
- Routage : qrouter
- Layout & DRC: magic
- LVS: netgen
- Simulation verilog : Icarus Verilog
- Cosimulation (pour les parties analogique): ngspice et Icarus
- Génération des masques : magic
Grande surprise quand on se plonge dans ces outils open-source : Beaucoup sont très vieux. Les pages web de ses outils sont encore codé en web95 avec des frames et autre fonds hideux datant de l’époque frontpage.
Pourtant à y regarder de plus prêt, ces outils semblent toujours activement maintenus.
Mais alors pourquoi aucun fondeur FPGA ne les proposent dans leurs IDE ?
Une première série du microcontrôleur gravé en 180nm a été produite en mai 2018. Le composant est désormais fonctionnel avec les caractéristiques suivantes:
- Cadencé à 100 MHz
- 16 GPIO
- 2 ADCs
- 1 DAC
- 1 Comparateur
- Alarme de température
- Oscillateur RC de 100 kHz
- Fonction configurables pour les sorties GPIO
- Interruptions configurable sur les entrées GPIO
Il n’est pas possible d’acheter le composant pour se faire un montage chez soit pour le moment. Par contre l’«IP» est disponible dans la bibliothèque du fondeur efabless et peut être utilisé comme base pour réaliser son propre composant selon les besoins.
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.
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:
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 ?