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 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:
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 :
C’est un mot qu’on commence à voir apparaître un peu partout quand on parle de FPGA. On pourrait penser à un nouveau logiciel/projet mais non. C’est juste un nouveau mot valise inventé pour désigner le code ou les projets FPGA !
On avait le software pour le logiciel, le firmware pour le logiciel enfoui et le hardware pour désigner simplement le matériel. Et bien nous avons maintenant le gateware pour designer le logiciel (bitstream) du FPGA.
Gate : porte
Ware: qui concerne
Visiblement les origines du mot proviennent de M-LAB qui a nomme sa spécialisation dans le FPGA comme ça.
Ne dites plus : «je fait du FPGA», mais : «je fait du gateware».
Visiblement, wikipédia n’a pas envie de définir gateware, la page a été supprimée une dizaine de fois !
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:
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 :
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:
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 :
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.
Dans le domaine de la simulation libre du VHDL, on connait bien le simulateur GHDL qui est basé sur GCC, on connaît un petit peu le simulateur FreeHDL inclus dans le logiciel graphique de simulation électronique Qucs, mais on connaît moins le simulateur NVC qui pourtant est en train de faire son petit bonhomme de chemin.
NVC est écrit en langage C pur et compilé par défaut avec le compilateur LLVM concurrent de GCC. L’avantage de NVC par rapport à GHDL: c’est un programme indépendant de son compilateur là où ghdl n’est qu’une couche de GCC. Ce qui simplifie grandement la compilation de l’outils.
NVC n’a pas encore atteint sa première version stable, cependant le rythme des commits laisse penser que cela va venir. Et surtout il est déjà utilisable en l’état dans sa version git «master» .
L’outil a été intégré dans la partie VHDL du blp, il s’utilise de la même manière que ghdl avec une phase d’élaboration puis d’analyse avant d’être lancé en simulation.
Pour simuler le testbench permettant de tester le module anti-rebond du blp nous ferons les commandes suivantes dans le répertoire vhdl :
analyse
nvc -a ../test/test_button_deb.vhd ../src/button_deb.vhd
élaboration
nvc -e button_deb_tb
simulation (run)
nvc -r button_deb_tb -w
L’option de simulation -w permet de générer un fichier de sortie (*.fst) pour être lu par gtkwave.
Depuis quelques années, plusieurs nouveaux langages HDL basés sur des langages de programmations génériques émergent. Ces programmes peuvent être qualifiés de SSHDL pour Synchronous Synthesizable Hardware Description Language
HDL ?
Pour Hardware Description Langage, c’est un langage de description matériel. Un HDL permet de décrire le comportement d’un composant numérique, comme des bascule D, des ALU, ou des microprocesseurs complet.
Les deux HDL les plus connu sont bien sûr le VHDL et le Verilog. Se sont les seuls à être reconnu comme standard par tous les logiciels de synthèses du marché. C’est donc un passage obligé pour travailler sur les FPGA.
Synthesizable ?
Cela peut paraître étrange, mais VHDL/Verilog ont beau être supporté par tous les logiciels de synthèse du marché, se ne sont pas des langage que l’on peut considérer comme synthétisable. Seul un sous ensemble de ces deux langages l’est, le reste étant utilisé pour la simulation.
Une architecture décrite dans un langage synthétisable … sera synthétisable. Si une portion du code n’est pas synthétisable alors il y a une erreur de code.
Synchronous ?
C’est quelque chose qui est indispensable en conception HDL. Tout le design doit être cadencé avec la même horloge, même si nous cherchons à capturer un événements extérieur (comme une interruptions) il est nécessaire de le resynchroniser avec l’horloge principale. Dans un SSHDL, le fonctionnement synchrone est implicite. L’horloge qui cadence tout le design n’a pas a être indiqué à chaque registre.
Toutes personnes qui a travaillé sur un FPGA de taille raisonnable le sait, il est impossible de cadencer tout son design avec la même horloge, puisque certain sous ensembles comme les contrôleurs de RAM ou les sérialiseur/déserialiseur nécessitent leurs propres horloges qui n’est généralement pas synchrone avec l’horloge globale. Il est alors nécessaire d’introduire la notion de domaines d’horloges et de soigner la conception des franchissement de domaines d’horloges de nos signaux (Clock domain crossing) afin d’éviter la métastabilité.
C’est un des points sensible qui fait la qualité d’un SSHDL : comment est géré le franchissement de domaines d’horloges ?
Standards industriels ou joujoux universitaires ?
Pour que ces langages puissent avoir un minimum d’espoir d’être déployés dans l’industrie, il faut que l’on puisse les utiliser sur les FPGA du marché. Il faut donc des logiciels capables de les synthétiser. Il est illusoire de croire que les gros fabricant de FPGA adoptent ces petits langages open-source pour leurs FPGA. Le SystemC est un bon exemple de langage qui n’a pas percé par manque de logiciel de synthèse (par contre il est très utilisé dans la simulation, car très rapide).
C’est pour cette raison que ces nouveaux langages ont choisi de générer leur designs en VHDL et/ou Verilog. Toutes la conception/simulation se fait donc avec ces nouveaux langages, et quand on veut faire la synthèse on lance la génération du VHDL/Verilog pour tester sur FPGA.
On peut ainsi considérer le VHDL/Verilog comme un langage «assembleur» du FPGA/ASIC.
Petites listes de SSHDL
La liste des SSHDL connus peut être trouvé dans la rubrique HDL de ce blog.
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.
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é.
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» :
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.
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 ?
FPGA Manager & devicetree overlays: Présentation du nouveau mécanisme d’«overlay» dans le DeviceTree de Linux pour gérer le chargement/déchargement des FPGA «à chaud»
Digital mixed-language simulators: Une courte introduction sur comment faire un simulateur mixte (VHDL + Verilog) à partir des projets open-sources existant (GHDL + Icarus)
