Sortie de la version 0.10 de Yosys

Posté par  (site web personnel, Mastodon) . Édité par palm123, Benoît Sibaud, Pierre Jarillon et Nicolas Boulay. Modéré par patrick_g. Licence CC By‑SA.
45
4
oct.
2021
Matériel

Yosys est devenu le pivot opensource du développement des circuits intégrés FPGA et ASIC.

Le 27 septembre 2021 a été publiée la nouvelle version 0.10 de Yosys sur l’hébergeur de gestionnaire de versions GitHub.
Cette sortie tardive (la 0.9 date de 2019) est l’occasion de parler de ce logiciel libre de synthèse Verilog, pivot de la libération des FPGA (et des ASIC). Plutôt que de simplement présenter les changements nous allons présenter le logiciel et le principe de la synthèse «RTL».

Le manuel de Yosys représente les différentes couches d’abstractions utilisées en conception numérique.

Couche d’abstraction utilisées en synthèse numérique

Les couches «System Level» et «High Level» sont généralement des modèles écrits en C/C++/OpenCV/Matlab/… puis convertis en modèles «Behavioral» par un humain. Il existe quelques logiciels dit de «synthèse de haut niveau» qui permettent cette conversion en automatique, mais ça n’est pas la panacée, et (très) souvent verrouillé sur une seule marque de FPGA.

Le niveau «Behavioral» est celui dans lequel on décrit le comportement du composant en Verilog ou VHDL. Il est également possible aujourd’hui d’utiliser des langages comme Clash, Chisel ou Migen. Ces derniers généreront ensuite du code Verilog au niveau «RTL».
Comme son nom l’indique, la couche «RTL» est une description au niveau «transfert de registres». On y décrit le comportement des registres au rythme de l’horloge. Yosys utilise son propre langage nommé RTLIL pour cette étape, mais il est parfaitement possible d’utiliser Verilog ici.
Dans la couche «physique» on décrit le système au moyen de portes logiques disponibles dans le FPGA cible. À ce niveau on parlera souvent de «netlist». Cette netlist est souvent décrite au format EDIF, mais il est possible de la décrire en Verilog ou VHDL. Yosys propose également le format JSON bien connu des développeurs JavaScript.
Le niveau «switch level» n’est pas vraiment utilisé en synthèse sur FPGA. C’est la description des connexions entre transistors, elle ne fait pas vraiment de sens pour un FPGA dans la mesure où les cellules logiques sont figées dans le FPGA.

Arrivé au niveau portes (Physical Gate level) on quitte la synthèse – et donc yosys – pour passer à la mise en paquet (Pack), au placement puis au routage. Et on s’enfonce dans la jungle sombre et humide des logiciels gratuits-mais-pas-trop non libres fournis par les constructeurs. Il existe toutefois un logiciel libre nommé nextpnr, mais ça nous éloigne du sujet. Sachez juste que nextpnr est parfaitement utilisable pour certaines marques de FPGA (ICE40, Gowin, ECP5 notamment).

Yosys est un logiciel de synthèse Verilog, il prend en entrée un source Verilog dans la couche «Behavioral Level» pour descendre dans les couches jusqu’au niveau «Physical Gate».

commençons donc par l’exemple de l’inverseur synchrone suivant (fichier invert.v):

// inverseur
module syncinvert(
    input clock,
    input reset,
    input inval,
    output outval);
reg regval;

assign outval = regval;

always@(posedge clock, posedge reset)
begin
    if(reset)
        regval <= 1'b0;
    else
        regval <= !inval;
end

endmodule

Par défault, Yosys se présente sous la forme d’une console «REPL» (Read Eval Print Loop) et se lance en tapant son nom :

$ yosys

 /----------------------------------------------------------------------------\
 |                                                                            |
 |  yosys -- Yosys Open SYnthesis Suite                                       |
 |                                                                            |
 |  Copyright (C) 2012 - 2020  Claire Xenia Wolf <claire@yosyshq.com>         |
 |                                                                            |
 |  Permission to use, copy, modify, and/or distribute this software for any  |
 |  purpose with or without fee is hereby granted, provided that the above    |
 |  copyright notice and this permission notice appear in all copies.         |
 |                                                                            |
 |  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES  |
 |  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF          |
 |  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR   |
 |  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES    |
 |  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN     |
 |  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF   |
 |  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.            |
 |                                                                            |
 \----------------------------------------------------------------------------/

 Yosys 0.10+0 (git sha1 070cad5f4, clang 8.0.0-svn345496-1~exp1+0~20181029105533.852~1.gbpf10f36 -fPIC -Os)

yosys>

Premier changement de cette version : l’auteur n’est plus Clifford Wolf mais Claire Xenia Wolf. Si la date du début du copyright n’a pas changée c’est que les deux sont une seule et même personne, elle a «juste» changé de prénom et d’état civil.

La ligne de commande se comporte comme une ligne de commande shell classique, avec le rappel des commandes par flèche haut/bas, et la complétion avec Ctrl+R et tabulation.
On charge son fichier source verilog avec la commande read_verilog.

yosys> read_verilog invert.v 
1. Executing Verilog-2005 frontend: invert.v
Parsing Verilog input from `invert.v' to AST representation.
Generating RTLIL representation for module `\syncinvert'.
Successfully finished Verilog frontend.

Yosys nous informe ici qu’il a bien lu et analysé le fichier source. Le «gateware» est bien conforme au standard Verilog-2005 et a été converti dans le langage interne nommé RTLIL (RTL Intermediate Language).

On peut lister les modules chargés en mémoire grâce à la commande ls.

yosys> ls

1 modules:
  syncinvert

Et afficher une vue graphique du module avec show:

yosys> show syncinvert 

4. Generating Graphviz representation of design.
Writing dot description to `/home/fabien/.yosys_show.dot'.
Dumping module syncinvert to page 1.
Exec: { test -f '/home/user/.yosys_show.dot.pid' && fuser -s '/home/user/.yosys_show.dot.pid' 2> /dev/null; } || ( echo $$ >&3; exec xdot '/home/fabien/.yosys_show.dot'; ) 3> '/home/user/.yosys_show.dot.pid' &

Qui affiche l’image suivante

Rendu xdot de l’inverseur

Cette simple lecture du fichier verilog nous a fait passer la première étape de la synthèse. Nous sommes presque descendus au niveau de la couche «RTL» de la synthèse. Presque, car il faut encore «mapper» la procédure que l’on voit au centre avec la commande proc:

yosys> proc
10. Executing PROC pass (convert processes to netlists).
10.1. Executing PROC_CLEAN pass (remove empty switches from decision trees).
Cleaned up 0 empty switches.
10.2. Executing PROC_RMDEAD pass (remove dead branches from decision trees).
Removed a total of 0 dead cases.
10.3. Executing PROC_PRUNE pass (remove redundant assignments in processes).
Removed 0 redundant assignments.
Promoted 0 assignments to connections.
10.4. Executing PROC_INIT pass (extract init attributes).
10.5. Executing PROC_ARST pass (detect async resets in processes).
10.6. Executing PROC_MUX pass (convert decision trees to multiplexers).
10.7. Executing PROC_DLATCH pass (convert process syncs to latches).
10.8. Executing PROC_DFF pass (convert process syncs to FFs).
10.9. Executing PROC_MEMWR pass (convert process memory writes to cells).
10.10. Executing PROC_CLEAN pass (remove empty switches from decision trees).
Cleaned up 0 empty switches.
10.11. Executing OPT_EXPR pass (perform const folding).
Optimizing module syncinvert.

Le résultat ressemble beaucoup plus à la bascule D que l’on connaît.

Rendu xdot de l’inverseur «mappé»

On peut optimiser ce graphe avec la commande opt, ce qui supprimera la branche inutile BUF -> $0\regval[0:0].

S’ensuit toute une série de commandes d’optimisation comme memory pour détecter les tableaux et utiliser des blocs de ram si possible ou techmap pour «mapper» les cellules d’une bibliothèque donnée.

yosys> opt; memory; opt; techmap; opt

Rendu xdot de l’inverseur mappé avec `techmap`

Notez que toutes ces commandes étant des commandes d’optimisations, rien n’interdit de les relancer pour améliorer encore l’optimisation (ici les optimisation sont totalement inutiles vu la simplicité du schéma).

Beaucoup d’étapes dépendantes de la cible sont ensuite nécessaires pour obtenir une netlist correspondant au composant. Ces étapes étant différentes en fonction de l’architecture cible. Yosys inclut des scripts pour chaque composant supporté.

Par exemple, si nous voulons synthétiser pour icestick, le FPGA monté sur la carte est un ice40, nous pourrons donc utiliser le script nommé synth_ice40 :

yosys> synth_ice40 
[...]
37.47. Printing statistics.

=== syncinvert ===

   Number of wires:                  6
   Number of wire bits:              6
   Number of public wires:           6
   Number of public wire bits:       6
   Number of memories:               0
   Number of memory bits:            0
   Number of processes:              0
   Number of cells:                  2
     SB_DFFR                         1
     SB_LUT4                         1

37.48. Executing CHECK pass (checking for obvious problems).
Checking module syncinvert...
Found and reported 0 problems.

Le lecteur attentif reconnaîtra la LUT 4 entrées et la basculeD de l'ICE40 dans le schéma généré :

Rendu xdot de l’inverseur synthétisé pour ICE40

Pour connaitre les scripts de synthèse disponibles dans yosys il suffit d’utiliser la complétion de commande avec synth_ :

yosys> synth_<TAB>
synth_achronix     synth_coolrunner2  synth_ecp5         synth_gowin        synth_ice40        synth_intel_alm    synth_nexus        synth_sf2          
synth_anlogic      synth_easic        synth_efinix       synth_greenpak4    synth_intel        synth_machxo2      synth_quicklogic   synth_xilinx

Ce qui nous donne 16 modèles de FPGA supporté «officiellement» par Yosys.

Il n’est pas obligatoire d’avoir un script synth_ pour pouvoir synthétiser pour un modèle de FPGA du moment que l’on fournit la bibliothèque des primitives. Pepijn De Vos s’est par exemple amusé à synthétiser vers une bibliothèque de composants en logique discrète (la série des 74-* pour ceux qui connaissent un peu l'électronique). Il a ensuite produit, assemblé et soudé la carte électronique correspondante.

Mais! Pepijn est parti d’un gateware écrit en VHDL ! En quoi cela concerne-t-il yosys qui est censé être un logiciel de synthèse Verilog ?

Pepijn a utilisé pour cela une extension de yosys permettant de se connecter au logiciel GHDL. Avec cette extension (encore en bêta mais déjà bien avancée), le VHDL est décodé avec GHDL qui transmet ensuite les informations à Yosys pour la synthèse. Et comme yosys est capable de sortir une version verilog de sa représentation interne RTLIL, on peut s’en servir pour faire de la conversion VHDL->Verilog sans problème.

Notre inverseur est désormais synthétisé. Nous pouvons donc l’enregistrer au format de notre choix pour passer ensuite au placement routage.

On peut l’écrire au format Verilog par exemple si nous souhaitons le simuler ou tout simplement lire la netlist :

yosys> write_verilog invert_synth.v

41. Executing Verilog backend.
Dumping module `\syncinvert'.

Ce qui donnera les sources suivantes :

/* Generated by Yosys 0.10+0 (git sha1 070cad5f4, clang 8.0.0-svn345496-1~exp1+0~20181029105533.852~1.gbpf10f36 -fPIC -Os) */

(* top =  1  *)
(* src = "invert.v:2.1-19.10" *)
module syncinvert(clock, reset, inval, outval);
  (* src = "invert.v:3.11-3.16" *)
  input clock;
  (* src = "invert.v:5.11-5.16" *)
  input inval;
  (* src = "invert.v:6.12-6.18" *)
  output outval;
  (* src = "invert.v:7.5-7.11" *)
  wire regval;
  (* src = "invert.v:11.1-17.4" *)
  wire regval_SB_DFFR_Q_D;
  (* src = "invert.v:4.11-4.16" *)
  input reset;
  (* module_not_derived = 32'd1 *)
  (* src = "/usr/local/bin/../share/yosys/ice40/cells_map.v:12.34-13.52" *)
  SB_LUT4 #(
    .LUT_INIT(16'h00ff)
  ) inval_SB_LUT4_I3 (
    .I0(1'h0),
    .I1(1'h0),
    .I2(1'h0),
    .I3(inval),
    .O(regval_SB_DFFR_Q_D)
  );
  (* module_not_derived = 32'd1 *)
  (* src = "invert.v:11.1-17.4|/usr/local/bin/../share/yosys/ice40/ff_map.v:9.57-9.103" *)
  SB_DFFR regval_SB_DFFR_Q (
    .C(clock),
    .D(regval_SB_DFFR_Q_D),
    .Q(regval),
    .R(reset)
  );
  assign outval = regval;
endmodule

Les sources sont annotées avec des références au verilog initial. On repère bien la bascule SB_DFFR et la SB_LUT4 avec sa configuration.
Et dans la mesure du possible, les noms de registres ont été gardés, ce qui rend le fichier assez facile à lire.

Pour le placement routage, si on utilise nextpnr il faudra «sortir» au format json :

yosys> write_json invert.json

42. Executing JSON backend.

Le fichier invert.json est beaucoup plus large que la sortie verilog (9779 lignes).
Les différents formats de sortie disponibles sont visibles avec la complétion de commande write_ :

yosys> write_<TAB>
write_aiger       write_btor        write_edif        write_firrtl      write_intersynth  write_rtlil       write_smt2        write_spice       write_verilog     
write_blif        write_cxxrtl      write_file        write_ilang       write_json        write_simplec     write_smv         write_table       write_xaiger

Cette possibilité de convertir dans différents formats le verilog initial fait de Yosys le couteau suisse du gateware. On peut s’en servir pour faire de la synthèse à destination des FPGA bien sûr, mais il est possible de «mapper» sur d’autres bibliothèques pour faire des PCB «discret» comme on l’a vu avec Pepijn De Vos.
Il est également possible de faire de la synthèse à destination des ASIC. Yosys est d’ailleurs utilisé par la chaîne de développement opensource OpenLane.

Enfin, les modèles synthétisés par yosys peuvent servir à faire de la preuve formelle, à partir de sources verilog mais également VHDL.

En règle générale, il n’est pas nécessaire de connaître les détails des commandes de Yosys. L’utilisation de yosys est enfouie dans les scripts et autres Makefile des outils utilisés.

Bref, en quelques années, Yosys est devenu le pivot opensource du développement FPGA et ASIC. Il méritait bien une dépêche sur LinuxFr.org !

Aller plus loin

  • # Grand merci !

    Posté par  . Évalué à 4.

    Merci pour ce bel aperçu global, des détails et des exemples qui permettent de mieux appréhender les différents éléments du développement d'un CI.

    • [^] # Re: Grand merci !

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Welcome :)

      Par contre ça n'est que le début de la chaîne de développement d'un CI. Après il faut faire le placement routage, la verif des timings et le bitstream … pour les FPGA. Car pour les ASIC il y a encore plus de boulot une fois synthétisé.

      Peut-être un sujet pour de futures dépêches ;)

      J'ai plus qu'une balle

      • [^] # Re: Grand merci !

        Posté par  . Évalué à 3. Dernière modification le 05 octobre 2021 à 12:41.

        Ah, oui, ça peut être intéressant. Du coup, je me suis lancé dans la lecture d'un ouvrage sur le développement sur FPGA, ça me démangeait depuis longtemps. J'en ai pris un générique pour comprendre un peu mieux toute la chaîne, celui que j'ai pris se base sur du Verilog, mais je suis ouvert aux autres langages pour le moment, j'ai vu que Chisel est un niveau au dessus et permet de gagner du temps dans le développement par rapport à Verilog, mais, l'expérience logicielle (archi informatique + assembleur + C/C++/etc + langages de script, m'a montré qu'il est toujours bon de comprendre le bas niveau pour une bonne conception haut niveau.

        J'ai envie de m'amuser avec PicoRV32, une implémentation libre de RISC-V 32 bits pour FPGA, en Verilog, optimisé pour la taille. Avec ses 750 à 2000 LUT selon la configuration choisie ça lui permet de tenir sur n'importe quel FPGA et d'avoir encore de la marge pour expérimenter des co-processeurs ou extensions maison. Je ne me rend pas trop compte du travail que ça représente, mais sans s'y plonger, impossible de savoir. Dans tous les cas, ça sera une expérience amusante.

        • [^] # Re: Grand merci !

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          Du coup, je me suis lancé dans la lecture d'un ouvrage sur le développement sur FPGA, ça me démangeait depuis longtemps.

          Par curiosité, c'est quel ouvrage ? J'en ai plusieurs mais je n'ai toujours pas trouvé l'Ouvrage de référence sur le sujet ;)

          J'ai envie de m'amuser avec PicoRV32, une implémentation libre de RISC-V 32 bits pour FPGA, en Verilog, optimisé pour la taille.

          Yèp, par contre il y a plus petit en riscv : le SERV, c'est vrai qu'il est spécial cependant.

          Avec ses 750 à 2000 LUT selon la configuration choisie ça lui permet de tenir sur n'importe quel FPGA.

          Pas tout à fait, il est difficile à caser dans un petit gowin par exemple.

          J'ai plus qu'une balle

          • [^] # Re: Grand merci !

            Posté par  . Évalué à 5.

            Par curiosité, c'est quel ouvrage ? J'en ai plusieurs mais je n'ai toujours pas trouvé l'Ouvrage de référence sur le sujet ;)

            « Programming FPGAs - Getting Started with Verilog « de Simon Monk, je ne sais pas si c'est l'idéal, mais ça à l'air de faire le tour de ce que je voulais en tant que grand débutant:
            * Ça part d'un petit rappel des portes logiques, des fliplop.
            * Donne des exemples de cartes de dev (Elbert 2 (1.5KLUT), Mojo (9KLUT), Papilio (10KLUT), je ne prendrais certainement pas une de celles-ci, j'aimerais bien tester sur simulateur d'abord, mais je ne suis pas sûr que ça soit plus simple)
            * Ça passe par la partie logicielle (sous Windows, donc, je n'utiliserais pas les mêmes logiciels, je suis sous Linux).
            * Le timer, automate-fini => la base donc, et des exemples horloges/alarme)
            * PWM et Servomoteur => trop bien pour les applis embarquées
            * L'audio, générateur de ton, et lecteur d'échantillon => les bases pour faire un synthé
            * La vidéo (avec sortie VGA, des exemples de tracés géométriques simples => implémenter un simple GPU

            Yèp, par contre il y a plus petit en riscv : le SERV, c'est vrai qu'il est spécial cependant.

            Ah, très bon, dans la doc ils parlent de Verilator, un simulateur, c'est exactement ce que je cherchais (je viens de le mettre, 22M le package, c'est raisonnable) et ça répond à ma question du dessus, donc grand merci j’espère pouvoir tester des ce soir :). Par contre, je n'ai pas trouvé le nombre de LUT de son implémentation.

            Pas tout à fait, il est difficile à caser dans un petit gowin par exemple.

            Je regardais justement sur des cartes Sipeed (je suis vraiment content de la longan nano (RISC-V32+écran), puisque c'est de la Tang Nano dont il est question, et je l'avais vu, effectivement. On doit pouvoir y faire rentrer que l'implémentation la plus limitée. Mais je pensais à la (lichee)Tang(primer) (pourquoi 2 noms??). Il y a une implémentation de picorv32 pour cette carte (Anlogic de 20KLUT), avec RT thread et en lien sur cette page de Humingbird (HBird E203), autre cœur RISC-V également avec RT Thread, je préférerais faire du bare-metal (il y a un lien vers une version bare-metal mais sur carte MXO2 de PicoRV32). Cela dit RT-Thread permet aussi d'éviter de refaire des choses de base, et probablement de tester plus facilement pour commencer. Il y a aussi la Tang Nano 4K (également Gowin) qui me fait de l'œil, avec son contrôleur RISC-V (au lieu du Cortex-M3), elle à 4608 LUT (au lieu de 1152) et un port HDMI. Elles sont toutes programmables avec openFPGALoader, mais d'après ce que je vois, ça à l'air d'être le cas de la majorité des cartes. Je ne sais pas si le microcontrôleur de la carte est utilisé uniquement comme programmateur, ou si on peut aussi l'utiliser pour du calcul et le FPGA comme extension. Dans ce cas j'en prendrait peut être une primer (pour la place restante) + une Nano 4K pour partir d'une base RISC-V. Elles sont toutes les deux <= 20€ ce qui me paraît raisonnable pour tester. Le simulateur suffira peut être pour commencer ?

            • [^] # Re: Grand merci !

              Posté par  . Évalué à 1.

              Après vérification, Verilator est un compilateur de verilog vers C. Je ne suis pas sûr qu'on soit dans les mêmes conditions de ce fait.

              • [^] # Re: Grand merci !

                Posté par  (site web personnel, Mastodon) . Évalué à 5.

                Verilator transforme du Verilog synthétisable en une classe C++.
                Il ne te reste plus qu'à écrire ton testbench en C++ (ou SystemC qui n'est qu'une bibliothèque C++).

                Verilator est le simulateur le plus rapide du marché – et de loin ! –. C'est le simulateur utilisé pour les cœurs de processeur, notamment RISC-V, mais les autre l'utilise également.

                Le gros point noir de Verilator à mon avis c'est qu'il n'existe pas vraiment d'écosystème de bibliothèque de tests en C++ pour les différents composants et protocoles (UART, SPI, Wishbone, AXI, hdmi, …). On a l'impression de réinventer la roue à chaque fois qu'on écrit un banc de test.

                J'ai plus qu'une balle

                • [^] # Re: Grand merci !

                  Posté par  . Évalué à 3.

                  Je vois, oui effectivement, un dépôt, de recettes communautaires, sous formes de modules aiderait bien. Peut être qu'un site ou une base de donnée qui regrouperait les différents projets existants serait déjà un premier pas ? J'ai l'impression que c'est pareil pour Icarus dont il est question sur le site de Verilator et dans le lien vers l'ancien article Linuxfr.

                  Je suis tombé sur ce blog, qui explique comment utiliser SDL pour visualiser les sorties graphiques de FPGA via Verilator, il y a quelques articles sur le sujet de la géométrie et animations. Il parle d'apprentissage en une heure, ça fait rêver, je vais suivre son tuto :).

                • [^] # Re: Grand merci !

                  Posté par  . Évalué à 3.

                  Bon, du coup, j'ai fait mes tests verilator (d'abord avec 2 exemples Hello World de verilator (le second avec systemc) pour comprendre les principes de base (un bout de code initialisateur en c++ + le code verilog) avec succès et effectivement, je ne m'attendais pas à quelque chose d'aussi simple en terme de programmation. J'ai aussi regardé et testé les exemples SDL + affichage pareil (et regardé les variantes matérielles).

                  Vu avec ces exemples simples ça ressemble à de la programmation classique sur un processeur déjà fait, mais sans cette couche. Il y a bien les réglages d'horloge, mais on retrouve aussi ça dès qu'on gère un périphérique en bas niveau après tout. Il me faut un FPGA pour voir les étapes suivantes maintenant.

                  C'est fou les sites spécialisés dans les modèles de processeurs FPGA (ou leur transcriptions en ASIC), j'ai vu efabless.com et opencores.org je ne m'attendais pas à cette foison d'implémentations.

                  Par rapport à cette remarque:

                  placement routage, la verif des timings et le bitstream
                  Là j'ai vu la contrainte du masque, et un passage sous forme géométrique du schéma avec la bibliothèque python eigen avec des schéma de liaison entre des cellules je ne sais pas si ce sont les LUT ou à un niveau plus élevé ? Désolé, pour la course au LUT, comme certains font pour les mégapixels sur APN, dans les précédente réponses. C'est important pour que les projets disponibles tiennent pour commencer, mais ça n'est clairement pas la seule contrainte.

                  Dans les exemples de la simulation VGA avec SDL il y a une gestion du timing pour vsync/hsync. j'utilisais en logiciel, mais c'est intéressant de voir comment c'est mis en place à ce niveau. Il y a des exemples de sprites matériels aussi (pas en SDL, il faudrait une implémentation du système de balayage dans la partie SDL de la simulation). Cela nécessite l'émission des pixels au bon moment à l'intérieur d'une ligne de balayage, je crois que c'est un exemple de bitstream, la sync n'étant donnée qu'en début de ligne ? je ne sais pas si cela correspond bien.

                  • [^] # Re: Grand merci !

                    Posté par  . Évalué à 2.

                    En avançant sur le sujet, je m'aperçoit que le microcontrôleur de la Tang est un Cortex-M et non un RISC-V. Il y a par contre bien un RISC-V sur la carte, un Bouffalo BL702 (basé sur un core RV32 de SiFive), mais il est utilisé pour le USB-série et le JTAG. Contrairement au ICE40, cette carte nécessite encore du proprio pour la conversion vers le bitstream (le code envoyé à la carte FPGA, cité dans l'article, je me demandais dans le précédent commentaire ce que c'était), mais le projet Apicula (et module python Apycula), au sein de Yosys justement, à pour but de libérer les FPGA Gowin/GW1N.

                    Et du coup, intéressant aussi, YoWASP un port des outils du projet Yosys en WASM, et l'utilisation de WASM en dehors du navigateur avec WASI de façon a avoir des outils portable. Je ne suis pas sûr que ce soit plus pertinent que Python. J'ai peur d'un gouffre à Mo avec les programmes qui rembarquent toutes les libs (à la JavaScript ou Rust et autre snap/appimage), plutôt que de réutiliser celles déjà installées comme on à l'habitude sous Linux. On vit sur une planète finie sur des ordis finis, avec toute leur entropie. Ça peut toujours dépanner dans certains cas (les outils de survie sur une clé usb de 256Go ou sur la carte SD tu téléphone branché en stockage de masse).

                    • [^] # Re: Grand merci !

                      Posté par  . Évalué à 2.

                      En en lisant plus j'ai compris que je n'avais pas compris (justement) quelque chose, en fait il faut le comptage est en cellules logiques != LUT. La LUT (table de vérité) n'en est qu'un élément, avec les flip-flop/latch (bascule D), les Mux et l'additionneur. Les organisations de ces éléments varient visiblement grandement d'un constructeur à l'autre avec leurs avantages et inconvénients en terme d'efficacité.

  • # Synthèse VHDL pour FPGA Xilinx

    Posté par  (site web personnel) . Évalué à 3.

    Très intéressant.

    Ça fait longtemps que je rêve d'une suite d'outils libres, interopérables et faciles à installer, pour synthétiser du VHDL-2008 et générer un bitstream pour FPGA Xilinx.
    J'ai l'impression que ça avance bien mais ça ne paraît pas encore accessible à des débutants.

    • [^] # Re: Synthèse VHDL pour FPGA Xilinx

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      J'ai l'impression que ça avance bien mais ça ne paraît pas encore accessible à des débutants.

      Pour les débutants si on se restreint aux ICE40 il y a l'excellent IceStudio, qui permet de faire du FPGA graphiquement. L'IDE cible principalement les ICE40 (dont le Icestick) car ce sont les mieux supporté par la chaîne open source.

      J'ai plus qu'une balle

  • # Complément: explications de l'utilité de Yosys au C3

    Posté par  . Évalué à 3.

    Une conf qui date de 2016 (ou son upload sur youtube) du C3 explique les principes et utilité de Yosys, la différence et complément par rapport à un simulateur :

    Formal Verification of Verilog HDL with Yosys-SMTBMC (33c3).

Suivre le flux des commentaires

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