Archives de catégorie : Langages

Verilog simulation Flags

Apparently, there is no Verilog standard to say «hey we are on simulation here». Each software have it’s own flag for that.

Xilinx iSim

`ifdef XILINX_ISIM
  // code for simulation with isim
`else
  // code for synthesis
`endif

Mentor Modelsim

`ifdef MODEL_TECH
  // code for simulation with modelsim
`else
  // code for synthesis
`endif

Icarus Verilog

?

Cocotb

`ifdef COCOTB_SIM
  // code for simulation with cocotb (should be cumulated with other simulator I think)
`else
  // code for synthesis
`endif

Chisel Tips

This page lists some tips for Chisel that I could glean here and there.

Bidirectional signal

Bidirectionnal signals are not possible inside an FPGA or an ASIC. But it can be usefull on the boundary to drive signal like tristate buffer.

To use Bidirectionnal signal use Analog() in conjonction with RawModule or BlackBox :

class TopDesign extends RawModule {
  val tristatebuf = Analog(1.W)
...
}

Connexion is made with bulk connector ‘<>’ :

tristatebuf <> myblackbox.io.tristate

dontTouch : keep register names in verilog

Tip from stackoverflow.

Sometimes, we have to keep register in verilog emitted code. But Chisel obtimize it and it often disapear. To keep it, use dontTouch() :

  val version = dontTouch(RegInit(1.U(8.W)))

Get following in verilog module:

  reg [7:0] version; // @[wbgpio.scala 20:34]
...
    if (reset) begin
      version <= 8'h1;
    end

DontCare output signals

All module output must be defined to avoid this kind of warning :

[error] (run-main-0) firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module ChisNesPad]  Reference io is not fully initialized.
[error]    : io.data.valid <= VOID
[error] firrtl.passes.CheckInitialization$RefNotInitializedException:  : [module ChisNesPad]  Reference io is not fully initialized.
[error]    : io.data.valid <= VOID
[error] Nonzero exit code: 1
[error] (Compile / runMain) Nonzero exit code: 1
[error] Total time: 12 s, completed 10 déc. 2019 13:25:11

But at the begining of a design, we don’t know what to write. To avoid this error we can use DontCare object :

  io.data.valid := DontCare

Keep signal and variables names in Verilog

See the good response from Jack Koening on stackoverflow.

UInt() to Vec()

An UInt() can be converted to a Vec of Bool() with asBools:

val foo = Vec(5, Bool())
val bar = UInt(5.W)

foo := bar.asBools
Initialize Vec() of Reg()

Split an UInt() in a Vec() of «sub» UInt()

Question asked on stackoverflow.

If we have a 16 bits register declared like that.

val counterReg = RegInit(0.U(16.W))

And we want to do indexed dibit assignment on module output like that :

//..
  val io = IO(new Bundle {
     val dibit = Output(UInt(2.W))
  })
//..
var indexReg = RegInit(0.U(4.W))
//..
io.dibit = vectorizedCounter(indexReg) //xxx doesn't work

We could do it like that:

io.dibit := (counterReg >> indexReg)(1, 0)

Initialize Vec() of Reg()

 val initRegOfVec = RegInit(VecInit(Seq.fill(4)(0.U(32.W))))

Concatenate value in one UInt()

Of course we can use Cat(), but it take only 2 parameters. With ‘##’ we can chain more signals:

val a = Reg(UInt(1.W))
val b = Reg(UInt(1.W))
val c = Reg(UInt(1.W))
val y = Reg(UInt(3.W))

y := a ## b ## c

With a Vec() declared like it :

val outputReg = RegInit(0.U((dibitCount*2).W)
val valueVecReg = RegInit(VecInit(Seq.fill(dibitCount)(0.U(2.W))))

ouptutReg := valueVecReg.reduce(_ ## _)

Initialize Bundle

Question asked on stackoverflow.

If we have a Bundle declared like that :

class RValue (val cSize: Int = 16) extends Bundle {
  val rvalue = Output(UInt(cSize.W))
  val er     = Output(UInt((cSize/2).W))
  val part   = Output(Bool()) /* set if value is partial */
}

And we want to make a register with initialized value we can use the new interface named BundleLiterals:

import chisel3.experimental.BundleLiterals._
...
val valueReg = RegInit((new RValue(cSize)).Lit(
          _.rvalue -> 1.U,
          _.er -> 2.U,
          _.part -> true.B)

Or if we just want to initialize to all 0 values we can do that :

val valueReg = RegInit(0.U.asTypeOf(new RValue(cSize))

Test some chisel code in console

Question asked on stackoverflow.

It can be usefull to be able to test code in console before launching the big compilation. It’s possible in directory where your project build.sbt is :

$ cd myproject/
$ sbt
sbt:myproject> console
scala>

And once in the scala console chisel import can be done :

scala> import chisel3._
import chisel3._
scala> val plop = "b0010101010001".U(13.W)
plop: chisel3.UInt = UInt<13>(1361)

Type Ctrl+D to quit.

For more Chisel Cookbook

See :

Liste de projets basés sur Chisel

Voici une liste de projets open-sources basés sur le langage de description matériel Chisel.

Processeurs

  • sodor: Un microprocesseur RISC-V pour l’éducation
  • rocket-chip: le générateur de processeurs RISC-V utilisé par SiFive
  • BOOM: The Berkeley Out-of-Order RISC-V Processor
  • leros: Un microcontrôleur microscopique optimisé pour les FPGA

Interfaces

  • spi2wb: Un maître Wishbone piloté par SPI
  • mdio: un maître MDIO (pour les Phy ethernet)
  • FastVDMA: une DMA rapide

Accélérateurs

  • Edge TPU : Il semblerait que cet accélérateur matériel développé par Google ait été conçu avec chisel3 d’après cette conférence.

Register size in bits

How to calculate register size in bits N

Chisel3 : log2Ceil()

import chisel3.util.log2Ceil

val Nsize = log2Ceil(N + 1)

Verilog : $clog2()

 parameter NSIZE = $clog2(N + 1);

VHDL : ceil(log2()

use IEEE.math_real."ceil";
use IEEE.math_real."log2";

Nsize := integer(ceil(log2(real(N + 1))));

Python: math.ceil(math.log(N+1, 2))

import math
Nsize = math.ceil(math.log(N + 1, 2))

CλaSH: ?

SystemC/C++: ceil(log2())

#include <math.h>       /* ceil and log */
Nsize = ceil(log2(N+1));

Digital Design with Chisel

«Digital Design with Chisel» n’est pas un manuel d’utilisation des ciseaux à bois.

Le livre de Martin Schoerberl «Digital Design with Chisel» est à ma connaissance le premier livre papier concernant le langage de description matériel Chisel.

Le livre — en anglais mais on s’en doute — est une excellente introduction au langage de description matériel Chisel. Avec lui il est même possible de commencer la conception numérique (digital design) en Chisel sans avoir à mettre les mains dans le VHDL ou le Verilog.

Ce manuel se veut un guide pratique de démarrage, on commence avec la description de l’installation des outils pour faire tourner Chisel tout en faisant une (très) rapide introduction à Scala. Scala est le langage utilisé pour Chisel.

Après avoir décrit les composants de bases du langage, l’auteur s’attaque à la description d’un projet Chisel avec l’architecture des sources, testbench et autres makefile et built.sbt . On attaque ensuite les différentes structures un peu plus avancées de la construction numérique comme les machines d’états, les FIFO, ports séries pour aller jusqu’à la conception d’un processeur simple.

Le livre se termine par un chapitre expliquant comment contribuer au projet initié à Berkeley.

C’est un excellent manuel pour mettre le pied à l’étrier de la conception numérique avec un langage moderne (SSHDL). Bien sûr ça n’est pas en 130 pages que l’on fera le tour du langage, ça n’est pas non plus un manuel de référence exhaustif. Pour le manuel de référence on se référera au site officiel, et pour se souvenir des mots clefs on ira télécharger la «cheat sheet».

Le livre est disponible en impression amazon pour ~10$. Comme c’est un livre «libre» il est également disponible avec ses sources sur le github de l’auteur.

Designing Video Game Hardware in Verilog

Stephen Hugg est l’auteur d’un vieux jeux en shareware tournant sur Win95 nommé comet buster. C’est surtout un grand fan de rétro-gaming.

Or, à une époque les consoles de jeux fonctionnaient avec de la logique discrète à base de puces que l’on soudait sur un PCB pour réaliser le jeux. La seule horloge utilisée était l’horloge «pixel» de l’écran CRT qui servait à piloter le balayage du faisceau d’électrons sur le téléviseur.

Dans ce livre, l’auteur revisite l’architecture de ces vieilles consoles avec du Verilog. À l’époque ce langage n’existait pas, mais il est tout de même bien indiqué pour décrire les circuits de logique numérique qui étaient utilisés dans ces vieilles consoles de jeux.

L’ouvrage commence donc par un cours de Verilog avec les bases du langage. Puis il enchaîne sur les circuits de base utilisé à l’époque pour piloter un écran CRT. Avec les technique comme le slipping counter qui permettait d’économiser des portes logiques en jouant sur le compteur de ligne et de colonnes de l’écran pour déplacer une balle.

Le livre enchaîne ensuite sur l’architecture d’un processeur 8 bits puis d’un processeur 16bits.

Et pour que l’on puisse mettre la main à la pâte, un site internet permet de simuler les «programmes» décrit en verilog.

On peut donc tester en live tout les codes proposé dans le livre sur le site 8bitsworkshop.

Stephen Hugg n’en est pas à son coup d’essais en matière de livre sur les vieux jeux vidéo puisque ce livre est le troisième. Mais c’est le premier livre à parler d’architecture «électronique», les deux précédent parlaient surtout de programmation de jeux vidéo sur de vieille architecture.

C’est un excellent petit livre pour se mettre au Verilog de manière ludique. Et cela permet de se replonger dans l’histoire des vieux jeux vidéos.

Verilator 4.002

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

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

Le nouveau logo de Verilator

La suite sur la dépêche linuxfr

Manage high impedance ‘Z’ state with Chisel

In previous (french) article, I described a technic to integrate a Chisel3 component named “TapTempo” in the APF27 board.  This board is made with an i.MX27 CPU and a Spartan3A FPGA.

To communicate with the FPGA, the i.MX27 is plugged on it with a memory bus named «WEIM». But the data signals used in WEIM are also connected on flash nand memory on the board, and this memory contain the Linux kernel and rootfs.

It’s not a problem if the FPGA “release” the data bus in high impedance when not used. Ant it’s the case when we use ctrl signal correctly (with oen signal -> output enable not)

In the first design, as tempo data are only output values read by the CPU, it was declared as “output” in chisel bundle :

class APF27TapTempo extends Module {
val io = IO(new Bundle {
val data = Output(UInt(16.W))
[...]

But with this data description, electrical value on physical data bus is continuously held by the FPGA. And when i.MX want to access nand flash memory it can’t. And we cannot start Linux as it require reading value in flash memory.

The solution is to set data bus as bidirectional signal and use WEIM signal oen to enable output on data bus, and when oen is not active the data bus is left on high impedance state ‘Z’.

In chisel, to manage bidirectional signal, we have to use the type “analog” as it :

class APF27TapTempo extends Module {
  val io = IO(new Bundle {
    val oen = Input(Bool())
    val data = Analog(16.W)
  [...]

And simply deactivate data when oen is ‘1’ ?

when(oen === '1'){
   data := "bZZZZZZZZZZZZZZZZ"
}.otherwize {
   data := taptempovalue
}

Would be so easy … But no, we can’t do that with Chisel3 🙁

In FPGA or ASIC, the high state value doesn’t exist in fact. All signals under FPGA must be input or output and set to ‘0’ or ‘1’. No other values are actually supported.

Other “high impedance” values like ‘Z’, ‘H’ or ‘L’ can’t be synthesized under the fpga. But these values (mostly ‘Z’ state in fact) can be synthesized on the boundary. If a bidirectional signal going out of FPGA, the xilinx synthesizer can instantiate an IOBUF and manage the high state.

Chisel doesn’t manage this high state. It’s a deliberate choice from chisel developers team to simplify Chisel3. But for some design, like on APF27 we need to implement it.

Verilog manage this kind of signal state, then we can write a verilog code to write ‘Z’ state and include it in our chisel design.

To do this, we use a module chisel type named BlackBox. And as we want to add directly verilog source in the chisel code we will add the Trait HasBlackBoxInline like described bellow :

// import verilog code with HasBlackBoxInline
import chisel3.util.{HasBlackBoxInline, HasBlackBoxResource}
...
// Describe blackbox with verilog code
class Apf27Bus extends BlackBox with HasBlackBoxInline {
  val io = IO(new Bundle {
    val dataout = Output(UInt(16.W))
    val dataio = Analog(16.W)
    val datain = Input(UInt(16.W))
    val oe = Input(Bool())
  })

  setInline("Apf27Bus.v",
    s"""
    |module Apf27Bus(
    |     output [15:0] dataout,
    |     inout [15:0] dataio,
    |     input [15:0] datain,
    |     input oen);
    |
    |   assign dataio = (oen == 'b0) ? datain : 'bzzzzzzzzzzzzzzzz;
    |   assign dataout = dataio;
    |endmodule
    """.stripMargin)
}
// Verilog will be written in separate file named Apf27Bus.v

...
// Then connect it in "Top" module
  val iobuf = Module(new Apf27Bus)
  io.data <> iobuf.io.dataio
  iobuf.io.datain := dataout
  iobuf.io.oen <> io.oen

As dataio is Analog type, we have to declare also analog on top bundle module :

class APF27TapTempo extends Module {
  val io = IO(new Bundle {
    val data = Analog(16.W)
    val oen = Input(Bool())
    val button = Input(Bool())
  })

With this method, we keep all our sources codes in the chisel sources and our high ‘Z’ bidirectional port is correctly synthesized with classical commercials software.

All sources of this project described in this article are available on my github project TapTempoChisel.

Intégration de TapTempo-Chisel sur APF27

Dans un premier article je décrivais le «core» de TapTempo en Chisel. Mais si nous souhaitons tester en réel il faut choisir une plate-forme sur laquelle le synthétiser. Ce choix implique nécessairement d’ajouter du code pour «packager» notre composant.

La carte APF27 et son kit de développement conçus par Armadeus Systems sont parfaitement indiqués. En effet la carte possède un FPGA de taille plutôt raisonnable de chez Xilinx : le spartan3A. Ce FPGA est couplé à un microprocesseur i.MX27 permettant de communiquer directement via un OS «évolué» (ici U-Boot). Et … comble du perfectionnement, le kit de développement est muni d’un bouton poussoir, qui nous servira de «touche tempo» !

L’idée est donc d’utiliser le bouton du kit pour la tempo et de venir lire le résultat mesuré par TapTempoChisel au moyen d’une lecture sur le bus de communication du processeur qui est connecté au FPGA.

Architecture du «packaging» de TapTempo
Architecture du «packaging» de TapTempo

On trouvera le code du packaging sur le github du projet. L’interface du Top est donc relativement simple, et se résume à deux signaux :

  • Le signal d’entrée (bouton)
  • Le signal de sortie (data)

Coté processeur,  il suffira de faire une lecture sur le bus pour pouvoir avoir la valeur en temps réel:

BIOS> md.w C8000000

Nous verrons plus tard que le design présenté ici est beaucoup trop simpliste et bloque le bus de l’apf27 ce qui entraîne une impossibilité de lancer Linux sur la carte.

Les différents éléments de notre architecture

Tout d’abord, pour éviter au maximum la métastabilité, il est nécessaire de synchroniser le signal d’entrée avec l’horloge du système. Pour cela nous devons faire passer le signal bouton par deux bascules D.

synchronization d'un signal externe par deux bascules
synchronisation d’un signal externe par deux bascules

Pour réaliser cela, dans un premier temps nous aurions tendance à déclarer deux signaux :

  • Un signal temporaire tmp
  • le signal synchronisé button_s

En chisel cela donnerait un truc dans le genre:

val tmp = RegNext(io.button)
val button_s = RegNext(tmp)

On déclare le registre en même temps que l’on connecte sa valeur d’entrée.

Pourtant à y regarder de plus près, ce montage de la double bascules n’est qu’un registre à décalage de 2 ! Et il existe une fonction pour ça dans la librairie «util» de chisel : ShiftRegister(sig, n)

Du coup nous pouvons réduire notre synchronisation en une simple ligne :

val button_s = ShiftRegister(io.button, 2)

Notre signal est maintenant synchronisé, mais nous n’avons pas filtré les rebonds. Or avec le genre de boutons que nous trouvons sur ces kits de développement c’est indispensable. Le FPGA étant cadencé à une fréquence élevé de 100Mhz nous allons «voir» tous les rebonds, et fausser par la même occasion notre mesure du tempo.

La plupart des «montages FPGA» permettant de faire de l’anti-rebond se basent sur des compteurs. Le tout étant de bien les dimensionner.

  val clk_freq_khz = 100000
  val debounce_per_ms = 20
  val MAX_COUNT = (clk_freq_khz * debounce_per_ms) + 1
  val debcounter = RegInit(MAX_COUNT.U)

La remise à zéro du compteur sera déclenchée par un front (montant ou descendant) du signal d’entrée. Nous déclarerons pour cela deux fonctions très commodes:

def risingedge(x: Bool) = x && !RegNext(x)
def fallingedge(x: Bool) = !x && RegNext(x)

Permettant de détecter respectivement le front montant et le front descendant du signal d’entrée.

Tant que le compteur debcounter n’a pas atteint sa valeur maximal, on ne fait que compter. Si le compteur est à sa valeur max et que l’on a un front sur le signal d’entrée, alors on remet le compteur à zero et on recopie la valeur du signal d’entrée.

  when(debcounter =/= MAX_COUNT.U) {
    debcounter := debcounter + 1.U
  }.otherwise {
    when(risingedge(button_s) || fallingedge(button_s)){
      debcounter := 0.U
      button_deb := button_s
    }
}

De cette manière on répercute rapidement un changement du signal d’entrée sans s’encombrer des multiples changement de valeurs rapide inhérentes aux rebonds.

Synthèse

Chisel est «vendu» à la base comme un langage HDL synthétisable, du coup nous allons le synthétiser, et avec un logiciel du marché s’il vous plaît : ISE.

Avant la synthèse nous avons besoin du code verilog généré. Pour le générer nous appellerons le ‘Driver’ déclaré dans le top:

object APF27TapTempoDriver extends App {
  chisel3.Driver.execute(args, () => new APF27TapTempo)
}

Au moyen de la commande sbt :

sbt 'runMain taptempo.APF27TapTempoDriver'

Le code verilog ainsi généré se retrouve dans le répertoire courant avec le nom APF27TapTempo.v

Notre projet comportant deux modules verilog (APF27TapTempo et TapTempo) leurs déclaration dans le fichier source se fait en partant de la fin -> le «top» est à la fin du fichier et le «core» au début:

...
module APF27TapTempo( // @[:@2517.2]
  input         clock, // @[:@2518.4]
  input         reset, // @[:@2519.4]
  output [15:0] io_data, // @[:@2520.4]
  input         io_button // @[:@2520.4]
);
...

Il ne nous reste plus qu’à intégrer ce source à un projet ISE en y ajoutant la description des signaux d’entrées sorties et leurs placement sur les pins du FPGA. Ce qui peut-être fait en intégrant le fichier de description APF27TapTempoChisel.ucf

# clock
NET "clock" LOC="N9" | IOSTANDARD=LVCMOS18;# CLK0
NET "clock" TNM_NET = "clock";
TIMESPEC "TS_clock" = PERIOD "clock" 10.4167 ns HIGH 50 %;
# data bus
NET "io_data<0>"  LOC="T5" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA0
NET "io_data<1>"  LOC="T6" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA1
NET "io_data<2>"  LOC="P7" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA2
NET "io_data<3>"  LOC="N8" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA3
NET "io_data<4>"  LOC="P12"| DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA4
NET "io_data<5>"  LOC="T13"| DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA5
NET "io_data<6>"  LOC="R13"| DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA6
NET "io_data<7>"  LOC="T14"| DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA7
NET "io_data<8>"  LOC="P5" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA8
NET "io_data<9>"  LOC="N6" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA9
NET "io_data<10>" LOC="T3" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA10
NET "io_data<11>" LOC="T11"| DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA11
NET "io_data<12>" LOC="T4" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA12
NET "io_data<13>" LOC="R5" | DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA13
NET "io_data<14>" LOC="M10"| DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA14
NET "io_data<15>" LOC="T10"| DRIVE=8 | IOSTANDARD=LVCMOS18; # DATA15
# Button
NET "io_button" LOC="C15" | DRIVE=12 | IOSTANDARD=LVCMOS33; # IO_L24N_1

Et nous pouvons lancer la synthèse/placement&routage/bitstream d’ISE. Une fois le bitstream généré il faut le transférer dans la mémoire de l’apf27 avec U-Boot :

BIOS> tftpboot ${loadaddr} APF27TapTempo.bit

Puis configurer le FPGA.

BIOS> fpga load 0 ${loadaddr}

Nous pouvons enfin lire la valeur du tempo avec la commande de lecture dans l’espace mémoire du bus fpga (WEIM) :

BIOS> md.w C8000000
c8000000: 010e 010e 010e 010e 010e 010e 010e 010e ................
c8000010: 010e 010e 010e 010e 010e 010e 010e 010e ................
c8000020: 010e 010e 010e 010e 010e 010e 010e 010e ................

La valeur est lue en hexadécimal. Et comme l’adresse n’est pas gérée, tant que ça reste dans la zone du bus FPGA, la même valeur se répète.

Ici nous avons donc un tempo de 0x10e soit 270bpm. Pour le calibrer, j’ai pris le chronomètre et tenté d’appuyer sur le bouton toutes les secondes, ce qui doit logiquement donner 60bpm -> 0x3c.

Nous n’en somme pas trop loin :
Test de la calibration de TapTempoChisel sur APF27

Il est désormais possible de l’utiliser dans le cas concret de la mesure du tempo du très mauvais «nuit de folie» du groupe «début de soirée» .

Mesure du tempo du très mauvais «nuit de folie» :

On obtient une valeur de 0x7B soit 123 coups par minute (bpm).

Ps: si vous voulez laver votre cerveau de cette horrible chanson pourquoi pas une petite guérilla ? À moins que vous soyez adepte du crou. Ne me remerciez pas, moi aussi j’ai beaucoup souffert à mesurer le tempo de cette horreur 😉