Sortie de Chisel 3, un langage de description matériel basé sur Scala

32
12
nov.
2016
Matériel

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 !

  • # RISC-V

    Posté par . Évalué à 10 (+8/-0).

    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 . Évalué à 6 (+4/-0).

    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 (page perso) . Évalué à 8 (+7/-0).

      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.

      • [^] # Re: Tout l'inverse du soft !

        Posté par . Évalué à -8 (+3/-3). Dernière modification le 13/11/16 à 17:51.

        Ton explication combinée à celle de Martoni (ci-après) donne une vue éclairante de la question.

        Par contre, ton affirmation que « les concepts synchrone/asynchrone dans le monde hardware n'ont rien à voir avec le monde du software » me heurte. En effet, dans les deux cas, les mots synchrones et asynchrones ont le même sens (synchrone : qui est simultané ; asynchrone : qui n'est pas simultané) et les problématiques sont du même ordre : l'impératif de maitriser l'ordonnancement des taches car d'une part certaines doivent en précéder d'autres et notamment certaines ne peuvent être simultanées (collision de deux tentatives de modification d'état d'un dispositif par deux voies différentes : laquelle doit primer ? - dans le domaine logiciel on pourra penser à deux accès concurrents en écriture à la même adresse mémoire), certaines doivent être simultanées (dans le domaine logiciel, pour faire une opération avec deux opérandes, il faut ces deux opérandes).

        Une spécificité des opérations matérielles électroniques par rapport aux opérations logicielles résident dans le fait que des résultats intermédiaires peuvent varier (être instables) pendant un certain temps de latence (notamment parce que certaines routes d'informations dits aussi "bus" servent à transporter diverses catégories de signaux comme des adresses mémoire ainsi que les données qui doivent être stockées à ces adresses), nécessitant de maitriser le moment du déclenchement de la prise en compte de ces résultats intermédiaires, pour garantir que ceux pris en compte sont nécessairement stabilisés à leur valeur nominale (correcte) par conception.

        Ainsi, pour la suite d'opérations logicielles atomiques (élémentaires, au niveau des instructions traitées par le processeur) comme pour la suite d'opérations électroniques sous-jacentes, la maitrise de la chronologie est primordiale :

        • les opérations doivent être effectuées dans un ordre déterminé ;
        • parfois l'évitement des simultanéités est nécessaire pour éviter des "collisions" ;
        • parfois au contraire la simultanéité est une nécessité.

        En généralisant à la vie de tous les jours : pour discuter de vive voix et en présence d'une personne il faut simultanéité de présence à un même endroit ; pour utiliser les toilettes pour déféquer, il vaut mieux éviter la simultanéité de présence sur le trône, voire prévoir un temps de latence suffisant entre deux usages du fait d'odeurs nauséabondes.

        Dans le domaine logiciel, la conception moderne privilégie l'usage d'opérations asynchrones (qui ne nécessitent pas d'être réalisées simultanément) pour pouvoir les répartir sur différents coeurs de calcul et maximiser la parallélisation des opérations (réduire le temps de calcul sur les processeurs multi-coeurs modernes ou les systèmes multi-processeurs). Dans le domaine matériel, la conception de domaines d'horloge distincts sur un même FPGA est possible, de manière à rendre indépendants les impératifs d'ordonnancement temporel de ces domaines et économiser de la latence (du temps d'attente pour synchroniser - la latence est typiquement utilisée pour réussir des rendez-vous ou simultanéités). Ainsi, deux opérations complexes distinctes comprenant des opérations intermédiaires qui ne sont pas corrélées (d'un domaine d'horloge à l'autre) peuvent être réalisées dans deux domaines d'horloges distincts, sans se soucier de simultanéité. Il se peut que les résultats finaux de chacune des deux opérations complexes aient vocation à être traitées comme une entrée d'une opération ultérieure, auquel cas, on retrouve le besoin d'établir une simultanéité (une synchronisation, un rendez-vous), ce qui peut être réalisé par une communication entre les deux domaines d'horloge, nécessitant pour l'un des deux de patienter pour que le résultat fourni par l'autre soit disponible.

        Mon propos est un peu verbeux, mais j'estime que la démarche pédagogique alliée à l'explicitation et l'établissement d'une vision synthétique (établissant les liaisons, prenant de la hauteur) accompagne fort bien l'exigence de précision et de certification de validité du discours, ce qui est très utile pour établir un monde de vérité et d'authenticité, tout le contraire du monde de duplicité dans lequel se déploient des médias corrompus et où chacun est incité à confier le traitement de ses informations à des machines pour lesquelles il n'a aucune garantie de conformité de fonctionnement par rapport à des spécifications ouvertes et auditées (parce qu'il peut y avoir des portes dérobées au niveau matériel, en dernier ressort). Je dis cela car plus nous serons nombreux à comprendre les enjeux sur le matériel, plus nous seront à même de participer à orienter les processus de production de ce matériel pour tendre vers cette garantie de conformité sus-mentionnée et donc vers l'établissement de vérités auditées, multi-sourcées, authentifiées, permettant de tendre vers l'établissement de diagnostiques convergents sur toutes les situations conflictuelles et ainsi de prendre des décisions éclairées tendant vers le consensus.

        • [^] # Re: Tout l'inverse du soft !

          Posté par . Évalué à -10 (+1/-3). Dernière modification le 13/11/16 à 23:19.

          /mode debug on

          Ainsi, deux opérations complexes distinctes comprenant des opérations intermédiaires qui ne sont pas corrélées (d'un domaine d'horloge à l'autre) peuvent être réalisées dans deux domaines d'horloges distincts, sans se soucier de simultanéité.

          Correction :

          […] peuvent être réalisées dans deux domaines d'horloges distincts, sans se soucier de simultanéité entre eux (mais bien sûr il y a des impératifs de cohérence temporelle (simultanéité ou pas, temps de latence non souhaité à prendre en compte, temps de latence à intégrer volontairement pour garantir la simultanéité) intrinsèques à chaque domaine d'horloge.

          / mode

          Je suppose que c'est la raison pour laquelle j'ai pris un -1 sur mon commentaire en première instance ;)

    • [^] # Re: Tout l'inverse du soft !

      Posté par (page perso) . Évalué à 10 (+9/-0).

      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.

  • # Langage synchrone

    Posté par . Évalué à 3 (+3/-0).

    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 (page perso) . Évalué à 2 (+1/-0).

      Bravo pour ce journal qui nous éclairent sur un successeur (encore un ;-)) du couple fameux VHDL/Verilog.

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

      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 ?

      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.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.