URL: https://linuxfr.org/news/taptempo-en-verilog
Title: TapTempo en Verilog
Authors: martoni
 Yves Bourguignon, Ysabeau 🧶, Davy Defaud, BAud, Xavier Teyssier, Benoît Sibaud, Frédéric Massot, palm123, claudex, bobble bubble et mzf
Date: 2020年09月13日T14:25:36+02:00
License: CC By-SA
Tags: open_hardware, taptempo, matériel, hdl et verilog
Score: 79
Le projet [TapTempo](https://linuxfr.org/tags/taptempo/public) semble faiblir depuis quelques mois maintenant. En panne de langage informatique pour en faire une dépêche ?
N. D. M. — TapTempo est un _détecteur de tempo_ où _l’utilisateur frappe une touche en cadence régulière et le programme en déduit le tempo correspondant._ Il a été décliné en de multiples langages de programmation.
Laissez‐moi vous présenter un langage assez particulier puisqu’il ne sert pas à faire de la programmation. Ce langage permet de décrire le comportement numérique d’un composant électronique (on parle alors de langage de description de matériel — [HDL](https://fr.wikipedia.org/wiki/Langage_de_description_de_mat%C3%A9riel "hardware description language")) : le [Verilog](https://en.wikipedia.org/wiki/Verilog).
C’est aussi un langage utilisé pour faire de la synthèse numérique sur les circuits logiques programmables (FPGA). Dans cet exemple, nous utiliserons la carte de développement à bas coût [ColorLight 5A‐75B](https://github.com/q3k/chubby75/blob/master/5a-75b/hardware_V7.0.md).
![Vue d’ensemble du montage TapTempo](http://fabienm.eu/partage/taptempocolorlight.JPG)
----
[Le projet TapTempoASIC décrit en Verilog](https://github.com/Martoni/TapTempoASIC)
[La vidéo de TapTempo en action sur une carte Colorlight (ECP5)](https://www.youtube.com/watch?v=03z5ehVXYvc)
[ColorLight 5A-75B](https://github.com/q3k/chubby75/blob/master/5a-75b/hardware_V7.0.md)
----
Le Verilog
==========
Le Verilog est un langage conçu à l’origine pour rédiger des spécifications de circuits logiques en électronique numérique. Le langage permet de décrire le comportement de sortie par rapport à des entrées logiques. Un peu comme les logiciels de saisie de schéma électronique, le Verilog est très hiérarchique, on décrit des modules avec leurs entrées‐sorties. Que l’on assemble ensuite dans d’autres modules pour finir dans un module « top » qui décrit le composant final.
Dans le cas de TapTempo, le module « top » est déclaré [comme ceci](https://github.com/Martoni/TapTempoASIC/blob/master/hdl/taptempo.v) :
 
```Verilog
module taptempo #(
 parameter CLK_PER_NS = 40, // 25Mhz clock (ns)
 parameter TP_CYCLE = 5120, // timepulse cycle period (ns)
 parameter BPM_MAX = 250 // BPM max (bpm)
)(
 input clk_i,
 input btn_i,
 output pwm_o
);
//corps du module
endmodule
```
Le module possède deux entrées : l’horloge (`clk_i`) et le bouton (`btn_i`) ainsi qu’une sortie pwm (`pwm_o`) pour l’affichage. Les paramètres seront vus comme des constantes au moment de la simulation, ils permettent de configurer les composants en fonction de la cible. Le changement de valeur des signaux se fait dans des processus qui sont déclenchés sur événement. Ces processus sont décrits au moyen du mot clef `always@()` en Verilog.
Par exemple, dans le code suivant :
 
```Verilog
/* Detect rising edge*/
reg btn_old, btn_rise;
always@(posedge clk_i)
begin
 btn_old <= btn_i;
 if(btn_old == 0 && btn_i == 1)
 btn_rise <= 1;
 else
 btn_rise <= 0;
end
```
 
L’événement déclencheur du process est le front montant de l’horloge `clk_i`. À chaque fois qu’un front montant d’horloge se présente, le processus est exécuté de manière séquentielle.
L’opérateur `<=` est l’opérateur d’affectation dit « non bloquant ». Cela signifie que la valeur ne sera effectivement appliquée qu’à la fin de l’exécution du process. Donc, la valeur du signal `btn_old` ne sera pas nécessairement égale à `btn_i` à la ligne du `if()` comme on aurait pu instinctivement le croire.
Le langage Verilog a beaucoup de succès dans le monde du logiciel libre. En effet, il est relativement peu verbeux et ressemble au C pour de nombreux aspects. Il est par exemple possible de décrire des macros de la même manière qu’en C, il suffit de remplacer le symbole `#` par ` pour créer des constantes qui seront remplacées par le préprocesseur :
 
```Verilog
/* count tap period */
`define MIN_NS 60_000_000_000
`define BTN_PER_MAX (`MIN_NS/TP_CYCLE)
`define BTN_PER_SIZE ($clog2(1 + `BTN_PER_MAX))
```
Le Verilog reprend également les opérateurs booléen et binaire `&`, `&&`, `&#124;`, `&#124;&#124;`, etc., du C.
C’est le langage HDL le mieux pris en charge par les différents logiciels libres. Si l’on souhaite se lancer dans le domaine des FPGA et/ou des ASIC, il est préférable de commencer par lui. C’est également le langage « de sortie » de quasiment tous les générateurs de code HDL.
Architecture de TapTempo
========================
L’outil indispensable pour commencer un projet en Verilog est... le papier et le crayon. Il est en effet indispensable d’avoir une vue d’ensemble assez claire de ce que l’on souhaite réaliser avant de se lancer dans le code.
Voici donc l’architecture générale du composant TapTempo :
![Schema TapTempo au Crayon](http://fabienm.eu/partage/schema_taptempo_crayon.jpg)
Même si l’on doit revenir plusieurs fois (ce qui est le cas ici puisque les constantes ne sont pas à jour) sur ce schéma général en cours de développement, cette partie est très importante. Si elle est bien pensée, le reste coule de source.
Le composant va nécessiter quelques compteurs, mais l’horloge utilisée ici étant très rapide nous allons d’abord factoriser le comptage au moyen du module nommé `timepulse`, ce module va distribuer une pulsation qui servira de base aux autres compteurs pour leur fonctionnement interne.
L’entrée utilisateur se compose d’un bouton (touche télégraphique « morse »). Les fronts montant et descendant de cette entrée n’étant pas synchronisés sur l’horloge du système nous allons devoir le faire au moyen de deux bascules en série pour éviter la [métastabilité](https://en.wikipedia.org/wiki/Metastability_(electronics)).
```Verilog
/* Synchronize btn_i to avoid metastability*/
reg btn_old, btn_s;
always@(posedge clk_i or posedge rst)
begin
 if(rst) begin
 btn_old <= 1'b0;
 btn_s <= 1'b0;
 end else begin
 btn_old <= btn_i;
 btn_s <= btn_old;
 end
end
```
Le second problème que pose notre entrée est que l’appui sur le bouton ne génère pas des changements francs de son état. Chaque « appui et relâche » génère une série de rebonds et donc une série de 0 et de 1 avant de se stabiliser. Pour lisser le signal il va donc falloir faire passer le signal dans le bloc « antirebond » `debounce`.
Le bloc `percount` va ensuite se charger de mesurer le temps entre deux appuis sur le bouton. Cette période va devoir être transformée en fréquence « BPM » (_Beat Per Minute_) via le module `per2bpm`, puis en une valeur pseudo‐analogique (PWM) grâce au module `pwmgen`.
La carte cible ne possédant pas de bouton « _reset_ », il va falloir le générer grâce au module `rstgen` de manière à s’assurer de l’état de départ de notre système au démarrage.
Entrée‐sortie
-------------
La plupart des programmes TapTempo proposés jusqu’ici supposaient — en plus d’un processeur — la présence d’un clavier et d’une console texte de sortie (avec toute la pile de pilotes et de système d’exploitation associés). Ici, nous allons devoir tout définir dans le « [portegramme](http://www.fabienm.eu/flf/et-pourquoi-pas-portegramme/) » — dans l’industrie on va parler d’IP pour _Intellectual Property_, quel horrible nom.
L’idée est donc de simplifier au maximum l’entrée « clavier » et la sortie histoire de pouvoir les décrire simplement.
Pour l’entrée nous allons nous contenter d’un contact de type bouton, ou d’une touche de type télégraphe « morse » :
![TapTempoEntreeMorse](http://fabienm.eu/partage/taptempo_entree_morse_modif.jpg)
Comme on peut le voir dans le schéma ci‐dessus, quand la touche est appuyée, l’entrée « bouton » est mise à la masse et donne un niveau logique à 0 sur notre système. Lorsque l’on relâche le bouton, la résistance de tirage ramène le niveau de tension à Vcc pour avoir un niveau 1 sur l’entrée.
Pour la sortie, l’idée de mettre un écran complexifie énormément le système. En effet, il est nécessaire de faire une machine d’état assez complexe pour initialiser l’écran puis rafraîchir l’affichage. Il est souvent nécessaire d’ajouter un processeur « soft » rien que pour ça d’ailleurs (bon, il est vrai que le VGA n’est pas si compliqué, mais il reste plus complexe que la solution proposée ici).
Non, l’idée ici est d’utiliser les graduations de l’antique voltmètre à aiguille trouvé dans une cave et qui gradue de 0 à 300 comme on peut le voir sur la photo :
![vuemetretaptempo](http://fabienm.eu/partage/voltmetre_taptempo.jpg)
Et comme un système numérique ne sort que des 0 et des 1 sur ses broches, on va « simuler » une valeur analogique au moyen d’une modulation de largeur d’impulsion, en anglais _Pulse Width Modulation_ — PWM. Il suffit de changer le rapport cyclique entre le temps haut et le temps bas de notre signal pour faire varier la tension moyenne qui sera vue par le voltmètre. Si on l’ajuste correctement avec une résistance en série, il est relativement facile de forcer la valeur maximale (5 V) à 250.
![PWM](http://fabienm.eu/partage/pwm_taptempo.jpg)
La période de la modulation de largeur d’impulsion sera configurée suffisamment rapide pour que l’aiguille n’oscille pas.
Pulsation de temporisation ([timepulse](https://github.com/Martoni/TapTempoASIC/blob/master/hdl/timepulse.v))
--------------------------------------
Le module ne prend pas de valeur d’entrée hormis l’horloge et le _reset_ qui sont de rigueur dans tout le projet. Son signal de sortie `tp_o` est une pulsation de l’horloge émise toutes les 5 120 ns :
 
```Verilog
module timepulse #(
 parameter CLK_PER_NS = 40,
 parameter PULSE_PER_NS = 5120
)(
 /* clock and reset */
 input clk_i,
 input rst_i,
 /* output */
 output tp_o);
```
Pour pouvoir compter des périodes de 5 120 ns on définit un registre de comptage :
 
```Verilog
`define MAX_COUNT (PULSE_PER_NS/CLK_PER_NS)
`define MAX_COUNT_SIZE ($clog2(`MAX_COUNT))
reg [`MAX_COUNT_SIZE-1:0] counter = 0;
```
Puis on compte de manière synchronisée avec l’horloge :
 
```Verilog
always@(posedge clk_i or posedge rst_i)
begin
 if(rst_i)
 begin
 counter <= 0;
 end else begin
 if (counter < `MAX_COUNT)
 begin
 counter <= counter + 1'b1;
 end else begin
 counter <= 0;
 end
 end
end
```
La pulsation est émise lorsque le compteur passe par 0 :
 
```Verilog
assign tp_o = (counter == 0);
```
Gestion des rebonds ([debounce](https://github.com/Martoni/TapTempoASIC/blob/master/hdl/debounce.v))
------------------------------
L’entrée de ce module est le signal de bouton préalablement synchronisé avec l’horloge du système `btn_s`. Le compteur utilisera la pulsation `tp_i` généré par le module timepulse décrit ci‐avant.
La sortie du module est un signal btn_o proprement lissé. La période de temporisation de 20 ms est donné ici en paramètre `DEBOUNCE_PER_NS` :
 
```Verilog
module debounce #(
 parameter PULSE_PER_NS = 5120,
 parameter DEBOUNCE_PER_NS = 20_971_520
)(
 /* clock and reset */
 input clk_i,
 input rst_i,
 /* inputs */
 input tp_i,
 input btn_i,
 /* output */
 output btn_o
);
```
La gestion des rebonds est réalisée au moyen d’un compteur utilisé pour temporiser :
 
```Verilog
`define MAX_COUNT ((DEBOUNCE_PER_NS/PULSE_PER_NS)-1'b1)
`define MAX_COUNT_SIZE ($clog2(`MAX_COUNT))
/* Counter */
reg [`MAX_COUNT_SIZE-1:0] counter = 0;
```
Ainsi que d’une machine d’états à quatre états :
 
```Verilog
/* State machine */
localparam [1:0] s_wait_low = 2'h0,
 s_wait_high = 2'h1,
 s_cnt_high = 2'h2,
 s_cnt_low = 2'h3;
reg [1:0] state_reg, state_next;
```
Les transitions de la machine d’états sont données dans le code ci‐dessous dans un processus dit « combinatoire » (`always@*`) par opposition à un processus « synchrone ».
 
```Verilog
always@*
begin
 case(state_reg)
 s_wait_low:
 if(btn_i)
 state_next = s_cnt_high;
 else
 state_next = s_wait_low;
 s_wait_high:
 if(!btn_i)
 state_next = s_cnt_low;
 else
 state_next = s_wait_high;
 s_cnt_high:
 /* verilator lint_off WIDTH */
 if(counter == `MAX_COUNT)
 /* verilator lint_on WIDTH */
 state_next = s_wait_high;
 else
 state_next = s_cnt_high;
 s_cnt_low:
 /* verilator lint_off WIDTH */
 if(counter == `MAX_COUNT)
 /* verilator lint_on WIDTH */
 state_next = s_wait_low;
 else
 state_next = s_cnt_low;
 endcase;
end
```
L’état de la machine est tout de même synchronisé dans un second processus :
 
```Verilog
always@(posedge clk_i or posedge rst_i)
 if(rst_i)
 state_reg <= s_wait_low;
 else
 state_reg <= state_next;
```
Le principe de « lissage » des rebonds est donc le suivant : dans l’état initial `s_wait_low`, on attend que le bouton passe à la valeur 1, et lorsque le signal passe à 1, on change d’état pour `s_cnt_high`.
Le passage dans l’état `s_cnt_high` a pour effet de faire passer le signal de sortie à 1 et déclencher le compteur. Tant que le compteur compte et n’a pas atteint la valeur `MAX_COUNT`, on reste dans cet état quelles que soient les variations du signal d’entrée. Lorsque le compteur atteint la valeur maximale, la machine d’état passe dans l’état `s_wait_high` (en attente de valeurs hautes).
Dans l’état `s_wait_high` on surveille la valeur du bouton d’entrée, si elle passe à 0 on change d’état pour `s_cnt_low`. De manière symétrique à `s_cnt_high`, on déclenche donc le compteur en ignorant la valeur d’entrée, et, lorsqu’elle atteint son maximum, on passe à l’état initial `s_wait_low`.
La valeur « lissée » du bouton en sortie est donnée par l’état de la machine d’état :
 
```Verilog
assign btn_o = (state_reg == s_cnt_high) &#124;&#124; (state_reg == s_wait_high);
```
Mesure de la période de tempo ([percount](https://github.com/Martoni/TapTempoASIC/blob/master/hdl/percount.v))
----------------------------------------
L’interface du module `percount` se compose des entrées habituelles d’horloge `clk_i`, de reset `rst_i`, ainsi que de la pulsation `tp_i`.
Le signal de mesure en entrée est `btn_i` et la sortie est un vecteur `btn_per_o` donnant la valeur mesurée. La valeur est considérée comme valide uniquement lorsque la sortie `btn_per_valid` est à 1. Cette astuce permet d’économiser un registre si la sauvegarde de la valeur mesurée est inutile comme c’est le cas ici.
 
```Verilog
`define MIN_NS 60_000_000_000
`define BTN_PER_MAX (`MIN_NS/TP_CYCLE)
`define BTN_PER_SIZE ($clog2(1 + `BTN_PER_MAX))
module percount #(
 parameter CLK_PER_NS = 40,
 parameter TP_CYCLE = 5120,
 parameter PULSE_PER_NS = 5120,
)(
 /* clock and reset */
 input clk_i,
 input rst_i,
 /* time pulse */
 input tp_i,
 /* input button */
 input btn_i,
 /* output period */
 output [(`BTN_PER_SIZE-1):0] btn_per_o,
 output btn_per_valid);
```
Maintenant que nous avons un signal de bouton `btn_b` propre et lissé, nous pouvons entamer la mesure de la période entre deux appuis au moyen de... devinez quoi ? D’un compteur pardi !
```Verilog
reg [($clog2(`BTN_PER_MAX+1)-1):0] counter = 0;
reg counter_valid = 0;
assign btn_per_valid = counter_valid;
assign btn_per_o = counter;
```
Il nous faut tout d’abord détecter le front descendant du bouton :
 
```Verilog
reg btn_old;
wire btn_fall = btn_old & (!btn_i);
always@(posedge clk_i or posedge rst_i)
begin
 if(rst_i)
 btn_old <= 1'b0;
 else
 btn_old <= btn_i; 
end
```
Le signal `btn_fall` sert de remise à zéro du compteur ainsi que de validation de la valeur de sortie :
 
```Verilog
always@(posedge clk_i or posedge rst_i)
begin
 if(rst_i)
 begin
 counter <= 0;
 end else begin
 if(btn_fall) begin
 counter_valid <= 1'b1;
 end else if(counter_valid) begin
 counter <= 0;
 counter_valid <= 1'b0;
 end else begin
 /* stop counting if max, count tp_i */
 if(tp_i && counter < `BTN_PER_MAX)
 counter <= counter + 1'b1;
 end
 end
end
```
Le compteur compte le nombre de pulsations de `tp_i` jusqu’à atteindre la saturation `BTN_PER_MAX`. Si un front montant du bouton se présente avec `btn_fall`, on valide le compteur avec `counter_valid`. Et si le signal de validation passe à 1 (donc, le coup d’horloge suivant), on remet le compteur à zéro et on recommence à compter.
Calcul de la fréquence en Beat Per Minute ([per2bpm](https://github.com/Martoni/TapTempoASIC/blob/master/hdl/per2bpm.v))
---------------------------------------------------
Avec le module `per2bpm` on arrive dans la partie critique du projet, car il va nous falloir faire une division. On entre une période dans le module :
 
```Verilog
 /* inputs */
 input [(`BTN_PER_SIZE-1):0] btn_per_i,
 input btn_per_valid,
```
Et on doit en ressortir une fréquence (BPM) :
 
```Verilog
 /* outputs */
 output [`BPM_SIZE - 1:0] bpm_o,
 output bpm_valid
```
Suivant la formule :
 
$$ bpm = \frac{\frac{MIN\_NS}{TP\_NS}}{btn\_per\_i}$$
Il faut donc diviser la constante $\frac{MIN\_NS}{TP\_NS}$ par la variable $btn\_per\_i$
La division (tout comme la multiplication) est un point sensible en Verilog. En effet, l’opérateur de division existe bien dans le langage et il se peut que cela simule parfaitement.
C’est lorsque arrivera l’étape de la synthèse que l’on risque d’avoir quelques surprises. Il est possible que certains logiciels de synthèse réussiront à faire quelque chose en un coup d’horloge, mais il est certain que cela se fera au prix de très mauvaises performances en matière de ressources utilisées et de fréquence d’horloge. Il est surtout probable que votre logiciel de synthèse jette l’éponge.
Pour réaliser cette division, nous allons donc en revenir aux fondamentaux appris au primaire et poser la division. Une division, c’est la recherche du quotient et du reste de l’équation suivante :
 
$Dividend = Quotient \times Divisor + Remainder$
```Verilog
reg [(`REGWIDTH-1):0] divisor;
reg [(`REGWIDTH-1):0] remainder;
reg [(`REGWIDTH-1):0] quotient;
```
La taille des registres sera celle de la période en entrée `BTN_PER_SIZE` additionnée à la constante à diviser :
 
```Verilog
`define DIVIDENTWITH ($clog2(1 + `MIN_NS/(TP_CYCLE)))
`define REGWIDTH (`BTN_PER_SIZE + `DIVIDENTWITH)
```
La division s’effectue avec une série de soustraction du reste (`remainder`) et de décalage du diviseur.
À l’étape initiale, on place le diviseur à gauche du registre `divisor` et le dividende dans le reste `remainder` :
 
```Verilog
 divisor <= {btn_per_i, (`DIVIDENTWITH)'h0};
 remainder <= `MIN_NS/TP_CYCLE;
 // le résultat est initialisé à 0:
 quotient <= 0;
```
Puis, on effectue une série de comparaison‐soustraction‐décalage avec l’algorithme comme décrit ci‐dessous :
- si le diviseur (`divisor`) inférieur ou égal au reste (`remainder`), on soustrait le reste avec le diviseur et on décale le quotient à gauche en ajoutant 1 :
 
```Verilog
 if(divisor <= remainder)
 begin
 remainder <= remainder - divisor;
 quotient <= {quotient[(`DIVIDENTWITH-2):0], 1'b1};
```
- si le diviseur (`divisor`) est supérieur au reste, on décale le quotient à gauche en ajoutant 0. On ne touche pas au reste :
 
```Verilog
 quotient <= {quotient[(`DIVIDENTWITH-2):0], 1'b0};
```
- dans tous les cas, on décale le diviseur à droite :
 
```Verilog
 divisor <= {1'b0, divisor[(`REGWIDTH-1):1]};
```
La division est orchestrée par une machine à trois états :
 
```Verilog
localparam [1:0] s_init = 2'h0,
 s_compute = 2'h1,
 s_result = 2'h2;
reg [1:0] state_reg, state_next;
```
Et le résultat est disponible en sortie quand `state_reg` est dans l’état `s_result` :
 
```Verilog
assign bpm_o = quotient[(`BPM_SIZE-1):0];
assign bpm_valid = (state_reg == s_result);
```
Génération de la tension de sortie ([pwmgen](https://github.com/Martoni/TapTempoASIC/blob/master/hdl/pwmgen.v))
-------------------------------------------
La génération du signal pseudo‐analogique décrite en introduction est presque la partie la plus simple.
On compte (oui encore) de 0 à 250 (BPM_MAX) :
 
```Verilog
/* count */
always@(posedge clk_i or posedge rst_i)
begin
 if(rst_i)
 count <= BPM_MAX;
 else begin
 if(tp_i)
 begin
 if (count == 0)
 count <= BPM_MAX;
 else
 count <= count - 1'b1;
 end
 end
end
```
Et on passe le signal de sortie `pwm_o` à 1 lorsque le compteur est inférieur à la fréquence demandée :
 
```Verilog
assign pwm_o = (count <= pwmthreshold);
```
Il y a juste une subtilité consistant à sauvegarder la valeur de la fréquence donnée en entrée dans deux registres `pwmthreshold` et `bpm_reg` :
 
```Verilog
reg [($clog2(BPM_MAX+1)-1):0] bpm_reg;
reg [($clog2(BPM_MAX+1)-1):0] pwmthreshold;
/* Latching bpm_i on bpm_valid */
always@(posedge clk_i or posedge rst_i)
begin
 if(rst_i)
 begin
 bpm_reg <= 0;
 pwmthreshold <= 0;
 end else begin
 if(bpm_valid)
 bpm_reg <= bpm_i;
 if(count == BPM_MAX)
 pwmthreshold <= bpm_reg;
 end
end
```
Le premier registre `bpm_reg` est mis à jour lorsque le signal d’entrée `bpm_valid` est à 1. Pour mémoriser la valeur d’entrée et pouvoir l’utiliser au moment où l’on en a besoin. Le second `pwmthreshold` est rafraîchi en fin de cycle d’une période de la modulation de largeur d’impulsions. Pour éviter d’avoir un changement de valeur en cours de période, et donc un rapport cyclique faux.
Simulation de l’ensemble avec Cocotb
====================================
Jusqu’ici nous avons décrit le comportement du composant final en Verilog. Toutes les développeuses ou développeurs HDL le savent très bien, il est impossible de réaliser un projet Verilog (ou autre HDL) sans faire un minimum de simulation.
Pour simuler le composant, il est nécessaire de décrire les stimuli en entrée du composant et de lire/valider les sorties. On va généralement créer un composant hiérarchiquement au‐dessus du top de notre composant appelé « testbench », dans lequel nous décrirons les changements de valeurs des entrées au cours du temps. Cette partie peut tout à fait se faire en Verilog.
Cependant, l’idée de mélanger la partie banc de test et composant « synthétisable » n’est pas terrible. En effet, on va très vite confondre les deux parties et mélanger les codes. L’exemple de la division est criant : l’opérateur diviser « / » fonctionne très bien dans la partie `testbench` mais il pose de gros problèmes dans la partie « synthétisable ».
Pour éviter ce mélange des genres, une solution radicale consiste à utiliser un autre langage pour la partie banc de test. Le C++ et le [SystemC](https://accellera.org/downloads/standards/systemchttps://accellera.org/downloads/standards/systemc) sont utilisés depuis longtemps pour cela. S’ils sont utilisés en conjonction avec [Verilator](https://linuxfr.org/news/verilator-4-002), ils permettent d’atteindre des puissance et rapidité de simulation inégalées par les simulateurs « propriétaires ».
Une autre méthode consiste à piloter le simulateur Verilog avec un autre programme, on parle alors de cosimulation. C’est le cœur du fonctionnement du module Python [CocoTB](https://linuxfr.org/news/cocotb-1-4-0-la-maturite). L’idée ici est d’écrire son banc de test en Python, ce qui est nettement plus confortable que du Verilog ou même du C++ (SystemC est également une librairie C++).
Le test pour simuler l’ensemble du projet TapTempo se trouve dans le répertoire cocotb/test_taptempo. Pour le simuler, il suffit de s’y rendre et d’y exécuter un `make` ; à condition cependant d’avoir installé cocotb (en Python 3) et [Icarus](https://github.com/steveicarus/iverilog) pour la partie simulateur (on laissera l’appréciation de l’installation au lecteur en fonction de ses affinités linuxdistributive).
[La simulation](https://github.com/Martoni/TapTempoASIC/blob/master/cocotb/test_taptempo/test_taptempo.py) consiste à tester trois appuis sur le bouton à des intervalles différents :
 
```python
@cocotb.test()
async def debounce_upanddown(dut):
 td = TestTapTempo(dut)
 td.log.info("Running test!")
 await td.reset()
 td.log.info("System reseted!")
 await Timer(1000, units="us")
 td.log.info("up")
 await td.bounce_up(10, bounce_per=(10000, "ns"))
 await Timer(24, units="ms")
 td.log.info("down")
 await td.bounce_down(10, bounce_per=(10000, "ns"))
 await Timer(300, units="ms")
 td.log.info("up")
 await td.bounce_up(10, bounce_per=(10000, "ns"))
 await Timer(30, units="ms")
 td.log.info("down")
 await td.bounce_down(10, bounce_per=(10000, "ns"))
 await Timer(800, units="ms")
 td.log.info("up")
 await td.bounce_up(10, bounce_per=(10000, "ns"))
 await Timer(30, units="ms")
 td.log.info("Wait stable")
 await Timer(1000, units="us")
```
Cela génère un fichier de « traces » au format VCD particulièrement volumineux de 2,3 Gio (qui se compresse à 70 Mio avec xz !) permettant de visionner les signaux au cours du temps grâce à [GTKWave](https://linuxfr.org/news/simplifier-la-visualisation-de-chronogrammes) :
 
```Shell
$ gtkwave -g taptempo.vcd
```
Et donne la trace suivante :
![simulation_taptempo_full](http://fabienm.eu/partage/full_taptempo_simu.png)
Cette simulation est particulièrement longue (il m’a fallu environ une heure et demie sur mon vieux T430) et génère un fichier de trace monstrueux. En phase de développement, on va généralement lancer de petites simulations par modules, comme on peut le voir pour le module `debounce` dans le répertoire cocotb/test_debounce. On changera également certaines constantes de temps pour limiter les « pas » de simulation consommant inutilement du calcul processeur.
Il est également possible de laisser l’ordinateur écrire les stimuli grâce à la méthode de preuve formelle. C’est la méthode qui a été utilisée ici pour les modules. Les fichiers de configuration se trouvent dans le répertoire `formal/`.
Synthèse sur ColorLight
=======================
La [Colorlight](https://fr.aliexpress.com/item/32281130824.html) n’est pas initialement une carte de développement pour les FPGA. C’est une carte permettant de piloter des panneaux de LED qui nous agressent un peu partout dans les rues commerçantes. Cependant, [un petit malin](https://github.com/q3k/chubby75/tree/master/5a-75b) s’est rendu compte qu’elle était munie d’un FPGA de chez Lattice : l’[ECP5](https://www.latticesemi.com/en/Products/FPGAandCPLD/ECP5).
Ce FPGA possède deux gros avantages :
 
- il est relativement gros, suffisamment pour posséder des multiplieurs câblés, des sérialiseurs-désérialiseurs...
- on peut développer dessus avec une chaîne de développement intégralement _open source_ !
Jusqu’à la Colorlight, les kits de développement ECP5 n’étaient pas donnés puisque [les premières cartes débutaient à 100 US$ minimum](https://www.latticesemi.com/en/Solutions/Solutions/SolutionsDetails01/CommunitySourced). Mais avec la Colorlight, on tombe à 15 US,ドル ce qui en fait un kit de développement ultra bon marché pour se faire la main avec des FPGA.
Et comme tout est _open source_, il est aisé d’aller installer les logiciels permettant de synthétiser TapTempo sur sa distribution GNU/Linux préférée. L’explication de l’installation des outils est hors de propos de cet article (un article détaillé sur la Colorlight est disponible dans le [_Hackable_ n^(o) 35](https://www.hackable.fr/)), mais une fois les outils installés, il suffit de se rendre dans le répertoire `synthesis/colorlight` du projet et de faire `make` :
 
```Shell
$ make
[...]
Info: Device utilisation:
Info: 	 TRELLIS_SLICE: 328/12144 2%
Info: 	 TRELLIS_IO: 3/ 197 1%
Info: 	 DCCA: 1/ 56 1%
Info: 	 DP16KD: 0/ 56 0%
Info: 	 MULT18X18D: 0/ 28 0%
Info: 	 ALU54B: 0/ 14 0%
Info: 	 EHXPLLL: 0/ 2 0%
Info: 	 EXTREFB: 0/ 1 0%
Info: 	 DCUA: 0/ 1 0%
Info: 	 PCSCLKDIV: 0/ 2 0%
Info: 	 IOLOGIC: 0/ 128 0%
Info: 	 SIOLOGIC: 0/ 69 0%
Info: 	 GSR: 0/ 1 0%
Info: 	 JTAGG: 0/ 1 0%
Info: 	 OSCG: 0/ 1 0%
Info: 	 SEDGA: 0/ 1 0%
Info: 	 DTR: 0/ 1 0%
Info: 	 USRMCLK: 0/ 1 0%
Info: 	 CLKDIVF: 0/ 4 0%
Info: 	 ECLKSYNCB: 0/ 10 0%
Info: 	 DLLDELD: 0/ 8 0%
Info: 	 DDRDLL: 0/ 4 0%
Info: 	 DQSBUFM: 0/ 8 0%
Info: 	 TRELLIS_ECLKBUF: 0/ 8 0%
Info: 	 ECLKBRIDGECS: 0/ 2 0%
[...]
ecppack --svf taptempo.svf taptempo_out.config taptempo.bit
```
On voit ici que les ressources utilisées pour TapTempo sont ridicules par rapport au FPGA utilisé. La curieuse ou le curieux qui voudra « voir » le placement‐routage dans le FPGA utilisera l’option `--gui` dans la commande NextPnR pour avoir l’interface graphique :
 
```Shell
$ nextpnr-ecp5 --25k --package CABGA256 --speed 6 --json taptempo.json --textcfg taptempo_out.config --lpf taptempo.lpf --freq 25 --gui
```
Ce qui donne un autre aperçu du remplissage du FPGA :
![taptempo routage](http://fabienm.eu/partage/taptempo_routing.png)
Pour télécharger le _bitstream_ dans le FPGA, on pourra utiliser [openFPGALoader](https://github.com/trabucayre/openFPGALoader) en donnant simplement le nom du _bitstream_ :
 
```Shell
$ openFPGALoader taptempo.bit
```
Exercices de travaux pratiques
==============================
Pour celles et ceux qui ont suivi jusqu’ici et qui voudraient se faire la main avec ce projet, voici quelques propositions de « sujet de TP » :) :
 
- utilisation d’un multiplieur câblé de l’ECP5 pour faire la division dans per2bpm ;
- ajout un module de moyennage sur cinq échantillons pour coller à la spécification initiale de TapTempo ;
- utilisation d’autres plates‐formes FPGA à bas coût : [QuickFeather](https://www.crowdsupply.com/quicklogic/quickfeather), [FireAnt](http://www.fabienm.eu/flf/fireant-un-petit-nouveau-dans-le-monde-du-fpga-a-bas-cout/), [Tang Nano](https://tangnano.sipeed.com/en/)...
 
N’hésitez pas à me proposer des demandes d’intégration Git pour améliorer le projet.
Conclusion
==========
On voit que dès que l’on passe dans le domaine de l’embarqué les choses se compliquent et prennent plus de temps. Alors que sur un PC on aurait pu faire ça en [une ligne de code](https://linuxfr.org/users/zerodeux/journaux/taptempo-en-une-ligne), quand [on embarque ça dans un microcontrôleur](https://linuxfr.org/users/belegar--2/journaux/taptempo-sur-stm32f469i-discovery), c’est déjà plus compliqué. Mais si l’on passe dans le monde des FPGA et des ASIC, le projet prend une toute autre dimension. C’est la raison pour laquelle il faut toujours se demander si un FPGA est bien à propos pour notre projet, non seulement cela coûtera plus cher en composant qu’une solution sur étagère, mais en plus le temps de développement (et donc le coût) sera nettement supérieur.
 
L’idée d’utiliser une touche de télégraphe pour mesurer le tempo n’était peut‐être pas la meilleure, compte tenu des rebonds qui sont relativement violents. Même avec le module lisseur de rebond ([debounce](https://github.com/Martoni/TapTempoASIC/blob/master/hdl/debounce.v)), il subsiste quelques rebonds trop longs. Un tempo maximum à 250 n’est pas si rapide et l’on est vite frustré de l’atteindre alors qu’on pourrait mesurer des tempos de musiques plus... rythmées. On peut facilement passer à 300, mais ça reste lent. Si l’on veut un tempo plus rapide, il faut tout d’abord changer la graduation sur le voltmètre, puis modifier le paramètre `BPM_MAX` dans le code.
 
On a ici un modèle de projet qui est facile à synthétiser sur n’importe quel petit FPGA. C’est un projet qui peut être intéressant si l’on souhaite se sortir un peu les doigts des LED qui clignotent. La démonstration étant faite du fonctionnement de l’architecture globale, il est aisé de s’en servir pour la réécrire dans d’autres langages de description de matériel comme le VHDL, Chisel (même s’il y en a [déjà une](https://linuxfr.org/users/martoni/journaux/integration-de-taptempo-chisel-sur-apf27) pour taptempo), Migen/Litex, MyHDL, Clash (en plus, ça permettrait de débloquer [la dépêche _LinuxFr.org_](https://linuxfr.org/redaction/news/sortie-de-c-ash-1-0) sur le sujet)...
Pour le curieux, ou la curieuse, qui sera allé voir le code sur le projet GitHub, ce projet a été développé avec une dose de [preuves formelles](https://fr.wikipedia.org/wiki/M%C3%A9thode_formelle_(informatique)#Preuves_formelles) grâce au logiciel libre [Yosys-SMTBMC](http://www.clifford.at/papers/2017/smtbmc-sby/slides.pdf).
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/taptempo-en-verilog.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/taptempo-en-verilog.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>