Archives de catégorie : verilog

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

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));

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

SymbiFlow, vers la synthèse libre pour la Série7 de Xilinx

Le projet IceStorm permettant générer des bitstreams à partir du verilog vers les FPGA ICE40 de Lattice étant maintenant très avancé, W.Clifford se lance avec d’autres dans le reverse-ingineering des FPGA de la Série 7 de Xilinx.

Pour cela, un nouveau projet nommé SymbiFlow est créé pour fédérer les différents outils permettant de développer autour des FPGA de Xilinx. L’objectif à terme étant d’intégrer également les ICE40 à SymbiFlow.

Le projet inclut un sous projet nommé sobrement «Project X-Ray» permettant de documenter les différents éléments du FPGA Artix7 sous forme de carte en ASCII et HTML. Se sous-projet vise à documenter le FPGA mais également à fournir des outils permettant de piloter Vivado avec des design simplistes permettant de générer des statistiques sur les bitstreams générés et approfondir la documentation.

Un des gros changement de SymbiFlow par rapport à Icestorm est la volontés de migrer le placement-routage de arachne-pnr vers VPR. Un sous-projet de VTR développé depuis bien plus longtemps que Arachne-pnr.

Vu le succès remporté par le projet IceStorm, avec la quasi totalité des FPGA ICE40 documenté ainsi que leurs timings, on peut espérer voir arriver rapidement une chaîne de développement libre pour les FPGA de la Série 7 de xilinx. Et voir ainsi le développement open-source sur FPGA devenir une réalité.

 

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.

IceStudio, du schéma au verilog

IceStudio est un logiciel graphique permettant de concevoir un design FPGA à la manière d’un schéma électronique.

Le logiciel est encore largement expérimentale (version 0.2) et centré sur les FPGA ice40 de chez lattice.

En fait, IceStudio se veut une extension graphique au projet IceStorm — chaine de synthèse/place&route/bitstream opensource —.

Architecturé en javascript autour de Nodejs, le logiciel permet de dessiner son projet au moyen de blocs reliés entre eux par des signaux.

icestudio-0.2-crono_

Les blocs peuvent être pris dans une librairie fourni avec le logiciel, mais il est également possible de créer des blocs «vierges» dans lesquels on écrira le code verilog correspondant au comportement souhaité.

icestudio-0.2-counter-inspection

Le format de sauvegarde du projet est en  JSON, un outils de conversion permet ensuite de le transformer en code Verilog pour la synthèse.

Installation

Pour l’installer nous aurons besoin du paquet «npm» :

sudo apt-get install npm

Puis de télécharger le projet git:

git clone https://github.com/FPGAwars/icestudio.git

Et enfin de lancer la commande d’installation comme décrite dans le README.md:

cd icestudio
npm install

Pour l’exécuter lancer simplement

npm start

Et si comme pour votre serviteur, cela ne marche pas du tout 😉 allez plutôt chercher la release sur https://github.com/FPGAwars/icestudio/releases. Dézippez la

unzip Icestudio-0.2.0-beta2-linux64.zip

Puis lancez le simplement :

./Icestudio

Le projet est encore jeune mais très prometteur.  Espérons que nous verrons rapidement l’intégration de nouvelles plateformes/FPGA, voir une version FPGA-Agnostic.

 

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.