Archives par mot-clé : Chisel

Prise en main du kit de dev HiFive1 (Freedom E310)

Chisel, Langages, Matériel, ,

Les chercheurs de Berkley qui ont fondé le set d’instruction (ISA) Risc-V (prononcez Risque failleve) ont également monté une société nommée SiFive.

Cette société conçoit des cœurs de processeurs nommés Freedom Everywhere et propose à ses clients de l’inclure dans des ASIC personnalisé. Les processeurs créés restent évidemment open-source, et l’intégralité du code (Chisel) est disponible sur le site de SiFive.

Pour promouvoir leur processeur, SiFive a fabriqué un microcontrôleur 32bits nommé Freedom E310. SiFive a également réalisé une carte «compatible arduino» qu’il est possible de commander en crowdsourcing pour prendre en main ce processeur.

C’est ce que nous allons tester ici. Le kit est livré «sec», pour l’alimenter il faut donc soit trouver un câble d’alimentation, soit décider de l’alimenter via l’USB comme expliqué dans le manuel de démarrage.

Kit HiFive1 (compatible arduino)

Le plus gros composant que l’on voit sur la carte est le convertisseur USB-Série et non le microcontrôleur. Le microcontrôleur se trouve à droite avec le «symbole superman».

Branchement

Le branchement du kit sur l’USB fait apparaître deux convertisseurs FTDI :

[16353.800810] usb 3-1: new high-speed USB device number 2 using xhci_hcd
[16353.941120] usb 3-1: New USB device found, idVendor=0403, idProduct=6010
[16353.941124] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[16353.941126] usb 3-1: Product: Dual RS232-HS
[16353.941139] usb 3-1: Manufacturer: FTDI
[16354.969029] usbcore: registered new interface driver usbserial
[16354.969056] usbcore: registered new interface driver usbserial_generic
[16354.969076] usbserial: USB Serial support registered for generic
[16354.986140] usbcore: registered new interface driver ftdi_sio
[16354.986162] usbserial: USB Serial support registered for FTDI USB Serial Device
[16354.986298] ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
[16354.986354] usb 3-1: Detected FT2232H
[16354.986609] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0
[16354.986634] ftdi_sio 3-1:1.1: FTDI USB Serial Device converter detected
[16354.986673] usb 3-1: Detected FT2232H
[16354.986906] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB1

La carte est livrée avec un bootloader faisant clignoter la led 4-couleurs D6. Il est possible de communiquer avec ce programme via le second port série :

$ sudo screen /dev/ttyUSB1 115200

On obtient le message de superman après avoir appuyé sur reset:

                SIFIVE, INC.

         5555555555555555555555555
        5555                   5555
       5555                     5555
      5555                       5555
     5555       5555555555555555555555
    5555       555555555555555555555555
   5555                             5555
  5555                               5555
 5555                                 5555
5555555555555555555555555555          55555
 55555           555555555           55555
   55555           55555           55555
     55555           5           55555
       55555                   55555
         55555               55555
           55555           55555
             55555       55555
               55555   55555
                 555555555
                   55555
                     5

               'led_fade' Demo 



55555555555555555555555555555555555555555555555
5555555 Are the LEDs Changing? [y/n]  555555555
55555555555555555555555555555555555555555555555
y
PASS

Compilons un programme pour l’E310

La mise en route du kit est relativement simple dans la mesure ou tout est décrit dans le document «getting started».

Évidemment, le cœur du proc est libre, du coup la chaîne de compilation l’est aussi pardi. Il suffit de la télécharger sur sa machine :

$ git clone --recursive https://github.com/sifive/freedom-e-sdk.git

Puis

cd freedom-e-sdk
make tools

Et attendre que ça compile en prenant son café.

Dans mon cas (Debian jessie) il fallait également installer les packets suivant pour que ça compile:

sudo apt-get install libmpc-dev

Un fois installé, on peut compiler la démo de gpio comme ça:

$ make software PROGRAM=demo_gpio BOARD=freedom-e300-hifive1

Puis la télécharger ainsi :

$ make upload PROGRAM=demo_gpio BOARD=freedom-e300-hifive1
work/build/openocd/prefix/bin/openocd -f bsp/env/freedom-e300-hifive1/openocd.cfg & \
/opt/freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb software/demo_gpio/demo_gpio --batch -ex "set remotetimeout 240" -ex "target extended-remote localhost:3333" -ex "monitor reset halt" -ex "monitor flash protect 0 64 last off" -ex "load" -ex "monitor resume" -ex "monitor shutdown" -ex "quit" && \
echo "Successfully uploaded 'demo_gpio' to freedom-e300-hifive1."
Open On-Chip Debugger 0.10.0+dev (2017-11-18-18:04)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 10000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
Info : dtmcontrol_idle=5, dbus_busy_delay=1, interrupt_high_delay=0
Info : dtmcontrol_idle=5, dbus_busy_delay=1, interrupt_high_delay=1
Info : Examined RISCV core; XLEN=32, misa=0x40001105
Info : Listening on port 3333 for gdb connections
Info : dtmcontrol_idle=5, dbus_busy_delay=1, interrupt_high_delay=2
Info : dtmcontrol_idle=5, dbus_busy_delay=1, interrupt_high_delay=3
Info : dtmcontrol_idle=5, dbus_busy_delay=1, interrupt_high_delay=4
Info : dtmcontrol_idle=5, dbus_busy_delay=1, interrupt_high_delay=5
Info : dtmcontrol_idle=5, dbus_busy_delay=1, interrupt_high_delay=6
Info : dtmcontrol_idle=5, dbus_busy_delay=1, interrupt_high_delay=7
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=7
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=8
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=9
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=10
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=12
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=14
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=16
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=18
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=20
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=23
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=26
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=29
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=32
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=36
Info : [0] Found 2 triggers
halted at 0x204000fe due to debug interrupt
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Info : Found flash device 'issi is25lp128' (ID 0x0018609d)
trap_entry () at /opt/freedom-e-sdk/bsp/env/entry.S:41
41	  STORE x27, 27*REGBYTES(sp)
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
halted at 0x204000fe due to debug interrupt
halted at 0x204000fe due to debug interrupt
cleared protection for sectors 64 through 255 on flash bank 0
cleared protection for sectors 64 through 255 on flash bank 0
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
halted at 0x204000fe due to debug interrupt
Loading section .init, size 0x6c lma 0x20400000
Loading section .text, size 0xbbe6 lma 0x2040006c
Loading section .rodata, size 0x1144 lma 0x2040bc58
Loading section .eh_frame, size 0x68 lma 0x2040cd9c
Loading section .data, size 0x9d0 lma 0x2040ce04
Info : Padding image section 0 with 6 bytes
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=40
Info : Retrying memory read starting from 0x80000000 with more delays
Info : dtmcontrol_idle=5, dbus_busy_delay=2, interrupt_high_delay=45
Info : Retrying memory read starting from 0x80000000 with more delays
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
halted at 0x80000004 due to software breakpoint
Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (SiFive, Inc.), part: 0x0e31, ver: 0x1)
halted at 0x80000004 due to software breakpoint
Start address 0x20400000, load size 55246
Transfer rate: 52 KB/sec, 6905 bytes/write.
halted at 0x20400004 due to step
halted at 0x20400004 due to step
shutdown command invoked
shutdown command invoked
A debugging session is active.

	Inferior 1 [Remote target] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Remote communication error.  Target disconnected.: Connection reset by peer.
Successfully uploaded 'demo_gpio' to freedom-e300-hifive1.

Malgrés l’erreur, visiblement le programme a bien été téléchargé dans le micro puisque les leds s’allument bien alternativement.
Et surtout, le message de démarrage s’affiche bien sur le /dev/ttyUSB1 :

core freq at 266646323 Hz
 
                SIFIVE, INC.

         5555555555555555555555555
        5555                   5555
       5555                     5555
      5555                       5555
     5555       5555555555555555555555
    5555       555555555555555555555555
   5555                             5555
  5555                               5555
 5555                                 5555
5555555555555555555555555555          55555
 55555           555555555           55555
   55555           55555           55555
     55555           5           55555
       55555                   55555
         55555               55555
           55555           55555
             55555       55555
               55555   55555
                 555555555
                   55555
                     5

SiFive E-Series Software Development Kit 'demo_gpio' program.
Every 2 second, the Timer Interrupt will invert the LEDs.
(Arty Dev Kit Only): Press Buttons 0, 1, 2 to Set the LEDs.
Pin 19 (HiFive1) or A5 (Arty Dev Kit) is being bit-banged
for GPIO speed demonstration.

.
Avec arduino

Ça n’est pas pour rien que le kit ressemble à s’y méprendre à un arduino : il est possible d’utiliser l’ide d’arduino pour se connecter à la carte.

L’ide arduino se trouvant dans ma debian est trop vieux pour pouvoir ajouter la toolchaine  sifive. J’ai donc du télécharger la 1.8 puis l’installer. Heureusement ça n’est pas très compliqué :

$ tar -Jxvf arduino-1.8.5-linux64.tar.xz
$ cd arduino-1.8.5/
$ ./install.sh 
$ ./arduino

Une fois lancé, il faut ajouter la configuration du package sifive en allant dans les préférences pour ajouter l’url suivante :

http://static.dev.sifive.com/bsp/arduino/package_sifive_index.json

Puis installer la plate-forme «sifive» via le board manager. Il faut également sélectionner «SiFive open ocd» comme programmeur.

Ne pas oublier de relancer l’ide et roulez jeunesse ! On peut facilement compiler/télécharger l’exemple de clignotement de led.

Les BlackBox et RawModule de Chisel3

Chisel, Chisel, Langages, verilog, , , , ,

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

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

BlackBox

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

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

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

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

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

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

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

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

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

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

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

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

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

Top RawModule

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

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

    val MAX_COUNT = 100000000

    val count = Counter(MAX_COUNT)

    count.inc()

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

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

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

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

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

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

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

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

Faire :

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

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

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

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

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

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

class Top extends RawModule {

Nous obtenons alors une entête Verilog plus propre :

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

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

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

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

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

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

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

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

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

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

SpinalHDL va-t-il remplacer Chisel ?

Chisel, Langages, SpinalHDL, , , ,

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

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

Alors pourquoi ne pas utiliser Chisel ?

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

    Alors que sur SpinalHDL on fera:

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

    Ce qui est plus naturel.

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

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

Bonjour,

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

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

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

Pour la documentation officielle c’est par là.

Synchronisation d’un signal externe avec Chisel

Chisel, Langages, , ,

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

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

reg tmp, sig_s;

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

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

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

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

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

val  sig_s = ShiftRegister(sig, 2)

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

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

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

Du futur de Chisel

Comme on le sait, les membres du Berkeley Architecture Research group continuent à travailler d’arrache-pied sur Chisel.

On peut trouver un tutorial et les applications futures de Chisel ici (pdf).

Un modulateur PWM en Chisel

Chisel, Langages, ,

Pour changer des LED qui clignotent, voici un modulateur PWM écrit en Chisel avec son testbench.

Le code ci-dessous (PWM.scala) est du Scala standard utilisant la librairie Chisel.

import Chisel._
/* Classe contenant le comportement du module */
class PWM extends Module {
  /* Bundle io obligatoire */
  val io = new Bundle {
    val duty  = UInt(INPUT,  8)
    val out  = Bool(OUTPUT)
  }

  /* Registre 8 bits pour le compteur */
  val counter = Reg(UInt(width=8))
  counter := counter + UInt(1)

  /* Registre de sortie avec le comparateur */
  io.out := Reg(next=(counter<io.duty))  
}

/* Point d'entrée du programme */
object Example {
  def main(args: Array[String]): Unit = {
    chiselMain(args, () => Module(new PWM()))
  }
}

Le code du modulateur ci-dessus est découpé en deux parties.

La première décrit le comportement du module. Elle comprend le bundle (similaire au record en VHDL) appelé io, qui doit être présent dans chacun des modules pour décrire les entrées et les sorties, un compteur 8 bits, et le registre de sortie qui est alimenté par le comparateur de rapport cyclique.

La deuxième partie est nécessaire pour le module qui se trouve au sommet de la hiérarchie afin de décrire le point d’entrée qui servira à la génération du code.

Il est aussi nécessaire de fournir le fichier build.sbt qui sert à indiquer a SBT (l’outil de build Scala) qu’il doit également aller chercher Chisel dans ses paquets avant de lancer la compilation. SBT va d’office compiler tout les fichiers Scala (avec l’extension .scala) qu’il trouve dans le répertoire courant.

libraryDependencies += "edu.berkeley.cs" %% "chisel" % "latest.release"

scalacOptions ++= Seq("-deprecation", "-feature", "-unchecked", "-language:reflectiveCalls")

Il faut ensuite s’assurer que Chisel génère du Verilog en lançant la commande

sbt 'run --v'

Il manque un banc de test pour exercer le design. Chisel propose de compiler également pour nous un modèle C++ du design qu’on peut obtenir
en utilisant la commande suivante :

sbt 'run --test --genHarness --vcd'

On va maintenant créer un testbench C++ qui permettra de générer les VCD. Appelons ce fichier main_pwm.cpp.

#include "PWM.h"
#include <iostream>

int main (int argc, char* argv[]) { 
  // Créer l'objet PWM
  PWM_t* c = new PWM_t();

  // Recupérer le nombre de cycles à exécuter
  int lim = (argc > 1) ? atoi(argv[1]) : -1;
  if(lim == -1) {
     cout << "wrong argument, should be :" << endl;
     cout << "a.out <n>" << endl;
     return 1;
  }
  // Initialiser le modèle
  c->init();

  // Ecrire l'entête du VCD
  c->dump_init(stdout);

  // Ecrire le rapport cyclique
  c->PWM__io_duty = LIT<8>(100);
  for (int t = 0; lim < 0 || t < lim; t++) {
    // Active le reset sur le premier cycle
    dat_t<1> reset = LIT<1>(t == 0);

    // Dump du VCD
    c->dump(stdout,t);

    // Avancer d'une période d'horloge
    c->clock(reset);
    } 
}

Il reste juste à compiler le tout avec g++.

g++ PWM.cpp main_pwm.cpp

À exécuter

./a.out 10000 > out.vcd

Et admirer le résultat dans gtkwave

gtkwave out.vcd

Compiler les exemples Chisel sur Jessie

Chisel, , ,

Chisel est un langage de description hardware développé par l’université de Berkley basé sur le langage Scala.

Les mainteneurs du projet Chisel fournissent un github de code d’exemples avec un tutoriel qui va avec. Le guide d’installation est par contre un peu léger et nécessite quelques adaptations pour tourner correctement sous Debian Jessie.

Dépendances

Les paquets debian à installé sont les suivants:

  • Scala
  • sbt
  • g++4.8
  • openjdk-7-jre

Que l’on peut installer sous Jessie avec les commandes suivantes:

sudo apt-get install scala
sudo apt-get install g++-4.8-multilib
sudo apt-get install openjdk-7-jre

sbt n’étant pas intégré dans Jessie, il est nécessaire de l’installer à la main en décompressant l’archive:

wget https://dl.bintray.com/sbt/native-packages/sbt/0.13.6/sbt-0.13.6.tgz
tar -zxvf sbt-0.13.6.tgz

Puis en l’ajoutant à son .bashrc :

# Scala built tool
export PATH=$PATH:"/opt/sbt/bin/"

Installation des tutoriels

Tout d’abord il nous faut descendre le git des tutoriels :

git clone https://github.com/ucb-bar/chisel-tutorial.git
cd chisel-tutorial/example

Puis tenter de compiler l’exemple Parity avec le makefile :

$ make Parity.out
set -e -o pipefail; sbt -Dsbt.log.noformat=true "run Parity --genHarness --compile --test --backend c " | tee Parity.out
/bin/sh: 0: Illegal option -o pipefail
../suffix.mk:61: recipe for target 'Parity.out' failed
make: *** [Parity.out] Error 2

Et c’est le drame !

Pour que ça fonctionne il faut taper la commande à la main sans le «set -e -o pipefail».

$ sbt -Dsbt.log.noformat=true "run Parity --genHarness --compile --test --backend c " | tee Parity.out

...

STEP 1 -> 10
 PEEK Parity.io_out -> 0x0
EXPECT Parity.io_out <- 0 == 0 PASS
RAN 10 CYCLES PASSED
PASSED
[success] Total time: 31 s, completed 27 oct. 2014 12:28:46
$