Jonathan Bachrach vient de l’annoncer sur la liste de diffusion chisel-user : le premier instantané de Chisel 3 est officiellement sorti.
Chisel est un langage de description matériel (HDL) basé sur le langage Scala. Le langage n’étant pas reconnu par les principaux logiciels de synthèse, il génère du langage Verilog synthétisable à la « compilation ».
Sommaire
Qu’est‐ce que Chisel ?
C’est un langage libre développé et soutenu par l’université de Berkeley (UCB). Université bien connue pour avoir « lancé » pas mal de standards libres d’aujourd’hui (pour rappel, BSD signifie Berkeley Software Distribution, soit collection de logiciels de Berkeley).
Contrairement à VHDL et Verilog — les deux langages de description de matériel (HDL) considérés comme standards dans le monde du FPGA et des ASIC —, Chisel est un langage synthétisable et synchrone par construction. Ce qui signifie qu’une architecture décrite correctement (sans alertes) avec Chisel sera synthétisable directement.
Chisel est également un langage synchrone, tous les changements d’états se font donc au rythme d’une horloge globale qui est implicite par défaut. Il existe cependant des stratégies de changement de domaines d’horloges pour les circuits complexes.
Chisel fait partie de ces nouveaux langages de description de matériel que l’on pourrait qualifier de SSHDL — pour Synchronous Synthesizable Hardware Description Language —, dont font partie également Migen, Cλash et SpinalHDL.
Passage de Chisel 2 à Chisel 3
La grosse différence entre Chisel 2 et Chisel 3 est l’utilisation d’un langage de netlist — on parle généralement de langage RTL — intermédiaire nommé FIRRTL entre la description en Chisel et le Verilog généré.
Chisel 2 comportait un certain nombre de backends qui permettaient de transformer le programme Chisel en Verilog, modèle C++ ou SystemC pour la simulation. Avec Chisel 3 la génération de ces backends a été abandonnée. Chisel 3 ne génère que du FIRRTL, FIRRTL génère à son tour du Verilog. Et la génération du modèle C++/SystemC a été déléguée à l’excellent Verilator histoire de mutualiser les efforts de développement. Ce qui nous donne la chaîne de développement suivante :
Chisel3 -> FIRRTL -> Verilog |-> C++/SystemC
|-> simulation
|−> synthèse
Petit exemple Chisel
La documentation de Chisel donne comme exemple le calcul de PGCD au moyen de l’algorithme d’Euclide. Cet exemple permet de trouver le PGCD des deux entiers a et b donnés en entrée. La sortie se présente ensuite comme un entier sur 32 bits z et la sortie de validation v permet de signaler la fin du calcul.
import chisel3._
class GCD extends Module {
val io = IO(new Bundle {
val a = Input(UInt.width(32))
val b = Input(UInt.width(32))
val e = Input(Bool())
val z = Output(UInt.width(32))
val v = Output(Bool())
})
val x = Reg(UInt.width( 32))
val y = Reg(UInt.width( 32))
when (x > y) { x := x -% y }
.otherwise { y := y -% x }
when (io.e) { x := io.a; y := io.b }
io.z := x
io.v := y === 0.U
}On remarque le bundle d’entrée‐sortie io = IO(new Bundle {}) permettant de déclarer les différents ports du module. Ce qui marque d’emblée, c’est l’absence d’entrée clk. C’est justement parce que c’est un langage synchrone que l’on ne voit pas l’horloge, elle sera générée à la « compilation » en FIRRTL (*.fir), puis en Verilog (*.v).
La base de la logique synchrone de Chisel est le registre Reg(). Ça n’est rien d’autre qu’une bascule D Qui recopie sa valeur d’entrée sur la sortie sur front montant de l’horloge, ce qui permet de synchroniser des valeurs d’entrée qui n’arriveraient pas en même temps et de présenter ces valeurs au prochain cycle d’horloge.
La connexion du registre avec les signaux d’entrée‐sortie se fait ensuite avec le symbole de connexion « := ».
On retrouvera tous les noms des signaux déclarés en Chisel dans le code Verilog généré. Ce qui permet un débogage plus facile et une simulation avec tous les simulateurs du marché.
Voici l’en‐tête Verilog généré par Chisel pour le module GCD :
...
module GCD(
input clock,
input reset,
input [31:0] io_a,
input [31:0] io_b,
input io_e,
output [31:0] io_z,
output io_v
);
reg [31:0] x;
reg [31:0] GEN_4;
reg [31:0] y;
reg [31:0] GEN_5;
...Deux signaux d’entrées ont été ajoutés au module : ce sont l’horloge (clock) et la réinitialisation (reset). La conception étant synchrone, l’horloge est implicite et n’est ajoutée qu’au moment de générer le code synthétisable.
Comme Scala est un langage objet, il est possible de faire hériter le module GCD pour factoriser du code générique. Il est également possible d’instancier le module dans un module de niveau supérieur et de connecter ses entrées‐sorties avec d’autres modules.
D’une manière générale, l’utilisation d’un langage générique comme Scala pour définir un langage HDL permet de faire un code moins verbeux et décuple les possibilités de création et de développement HDL.
Chisel 3, tout comme ses concurrents Migen, Cλash et autre SpinalHDL sont désormais mûrs pour être utilisés dans de vrais projets industriels. C’est d’ailleurs la base du processeur RISC-V sodor et rocket-chip.
Pourtant, les SSHDL ne sont pas encore enseignés dans les universités qui continuent à former sur VHDL en Europe et Verilog aux États‐Unis.
Il est temps de passer à des langages HDL de plus haut niveau et de considérer VHDL/Verilog comme l’assembleur des FPGA et ASIC !
Aller plus loin
- Annonce de la sortie du premier « snapshot » 3 de Chisel (138 clics)
- Site officiel de Chisel (300 clics)
- FIRRTL (167 clics)
- Verilator (114 clics)
- GitHub de Chisel 3 (120 clics)
# RISC-V
Posté par gasche . Évalué à 10.
La collaboration entre RISC-V et Chisel est assez étroite, puisque les deux projets ont été lancé par la même équipe à Berkeley et qu'une partie des gens travaillent sur les deux. C'est très chouette parce qu'à ma connaissance (mais je connais mal ce domaine) c'est la première fois qu'on outil libre de description de hardware est utilisé pour un design "grand public", à forte diffusion, et pas juste à but pédagogique.
# Tout l'inverse du soft !
Posté par djano . Évalué à 6.
Merci pour cette dépêche qui me fait découvrir un monde étranger: les langages de description hardware.
Je suis frappé de voir à quel point ces langages sont proches des langages de programmation. Celui-ci tout particulièrement, puisque son design synchrone élimine l'horloge qui est la partie "exotique" pour un développeur software :)
Il est d'ailleurs cocasse de constater que le design hardware s'oriente vers du code synchrone alors que le design software s'oriente de plus en plus vers de l'asynchrone pour profiter du multicore.
Comment expliquez-vous cela ?
[^] # Re: Tout l'inverse du soft !
Posté par Fabrice Mousset (site web personnel) . Évalué à 8.
Les concepts synchrone/asynchrone dans le monde hardware n'ont rien à voir avec le monde du software.
On est ici dans le monde HW et il faut donc penser en terme de HW et non SW.
Je vais essayer de donner quelques clés sans entrer trop dans les détails.
Quand on parle de systèmes synchrones en HDL, on parle de design qui sont "sensibles" à une (ou plusieurs) horloges. Cela veut dire que l'état des sorties du système vont changer après un front (en général montant) de l'horloge. Le reste du temps les sorties sont stables (sinon on a un problème ;-) ).
Ceci est très vrai pour les circuits programmables type FPGA. Les FPGA sont des circuits avec une structure bien particulière, basée sur des blocs élémentaires très simples composés: d'une LUT (Look-Up Table => table de vérité), d'un inverseur, d'un multiplexeur et d'une bascule D (mémoire synchrone 1 bit). Cette structure très simple est la force des FPGA parce qu'il est plus facile de produire un circuit intégrer graver très finement (28nm pour les CycloneV Alera) avec une structure répétitive qu'un circuit avec une structure plus complexe (tels que les CPLD).
La conception d'un design FPGA passe par plusieurs phases:
1. la description du design à l'aide d'un langage HDL
2. la synthèse du design qui consiste à extraire de la description une "netlist" qui correspond à l'interconnexion des éléments HW (bascules, inverseurs, multiplieurs, etc.)
3. Le placement/routage ou l'on va tenter de placer les éléments de la netlist dans le FPGA
4. L'analyse de timing, qui est une étape essentielle qui consiste à s'assurer que les contraintes de temps seront respectées par le design générer.
Le point dur d'un design est en général l'étape 4, en effet pour que le design soit stable, il faut que les bascules D soit toutes bien utilisées. Il faut que le signal soit présent à l'entré de la bascule un certain temps avant le front actif de l'horloge (setup time) et reste stable un certain temps après le front actif (hold time). Et ceci pour toutes les bascules D utilisées par le design.
J'espère ne pas avoir été trop brouillon dans mes tentatives d'explication.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -8. Dernière modification le 13 novembre 2016 à 17:51.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 13 novembre 2016 à 23:19.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tout l'inverse du soft !
Posté par martoni (site web personnel, Mastodon) . Évalué à 10.
Il n'est pas possible de garantir le temps de propagation entre deux portes logique dans un FPGA à cause du placement routage.
En effet pour connecter la sortie d'une porte logique sur une autre il est nécessaire de passer par un nombre aléatoire de connexions qui seront différente à chaque synthèse/placement routage.
Si nos signaux d'entrées d'une porte logique «ET» par exemple n'arrive pas exactement en même temps, le résultat de sortie va passer par plusieurs valeurs fausses avant de se stabiliser.
Pour éviter de propager ces erreurs on va mémoriser le résultat à un moment précis − la plupart du temps sur le front montant d'une horloge principale − au moyen d'une Bascule D.
Ces la valeurs de sorties de la bascule D qui seront prisent comme résultat pour être propagées dans d'autre calculs. On parle de système synchrone quand toutes les Bascules D se déclenchent sur la même horloge.
L'analyse des timings consistera alors a s'assurer qu'entre deux bascules les signaux se propagent plus rapidement qu'une période de l'horloge.
J'ai plus qu'une balle
# Langage synchrone
Posté par syl . Évalué à 3.
Bravo pour ce journal qui nous éclairent sur un successeur (encore un ;-)) du couple fameux VHDL/Verilog.
Par contre, je suis surpris que ce langage prenne pour parti pris un tout-synchrone. J'ai certes arrêté la conception HW il y a quelques années, mais pour les designs complexe (au-delà de la dizaine de millions de portes), on parlait beaucoup de GALS (Globally Asynchronous Locally Synchronous). Comment un tel langage peut-il être compatible de ce paradigme ?
[^] # Re: Langage synchrone
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
Je ne trouve pas qu'il y en ait tant que ça perso. Mais c'est vrai que depuis 2 ou 3 ans ça commence à bouger. À ma plus grande joie ;)
C'est bien l'esprit du langage en fait. On est bien «localement synchrone» avec le concept de domaines d'horloges. Il est tout à fait possible de changer de domaines d'horloges d'un module à l'autre. Mais c'est au développeur de bien soigner ses traversées de domaines d'horloge. C'est encore un point noir de Chisel à mon avis, même s'il existe quelques fonctions comme la fifo asynchrone ou le registres à décalage pour faciliter ça.
J'ai plus qu'une balle
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.