k1g1 : le premier FPGA Libre…

Posté par . Édité par Davy Defaud, Benoît Sibaud et palm123. Modéré par Davy Defaud. Licence CC by-sa.
Tags :
43
4
nov.
2019
Matériel

Cette dépêche est tirée d’un journal annonçant le k1g1, le premier FPGA libre… à sa connaissance.

Parmi les premiers commentaires du journal, on peut noter la promesse du succès mais pas avant dix ou vingt ans, des discussions sur les sociétés du domaine, l’évocation d’une puce de test, archipelago, le FPGA virtuel, etc.

Sommaire

k1g1 : le premier FPGA Libre… à la connaissance de son auteur :

« Aujourd’hui est un grand jour pour moi, pour la communauté libre et, enfin, pour l’Humanité. Oui, rien que ça. En effet, je viens de valider en simulation au niveau porte logique (gate‐level simulation en anglais, voir la page « logic simulation ») le premier cœur FPGA libre basé sur ma propre architecture. »

Mais avant d’aller plus loin, un peu de contexte.

Un FPGA, c’est qu’est‑ce quoi ?

Pour schématiser grossièrement, il existe trois types de circuits intégrés : les ASIC, les processeurs et les FPGA.

ASIC

Les ASIC (Application‐Specific Integrated Circuit) sont des circuits intégrés dédiés à une application donnée, telle qu’un décodeur vidéo H.265, un mineur de crypto‐monnaie… Vu qu’ils sont conçus pour ne faire qu’une seule tâche, ils sont généralement plus performants et plus efficaces d’un point énergétique que le programme équivalant exécuté par un processeur. Mais leur conception est longue, coûteuse et, surtout, ils ne sont pas évolutifs : une fois la fonctionnalité gravée dans le silicium, impossible de la mettre à jour. Il faut obligatoirement créer un nouveau circuit.

Processeur

À l’opposé, les processeurs sont des circuits généralistes pouvant réaliser un grand nombre de tâches, à condition de leur fournir le programme idoine. Mais en comparaison, ils sont moins performants et consomment plus d’énergie.

FPGA

Les FPGA (Field‐Programmable Gate Array) sont un compromis entre les ASIC et les processeurs. Tout comme les processeurs, ils sont reprogrammables, et comme les ASIC, ils sont performants (mais moins que ces derniers). Un FPGA se compose habituellement de blocs logiques permettant d’implémenter des équations logiques et d’un réseau de routage pour interconnecter les blocs logiques. On pourrait en quelque sorte dire qu’un FPGA est un émulateur d’ASIC.

Mais pourquoi se lancer dans cette aventure ?

De 2014 à 2018, j’ai travaillé dans une start‑up qui concevait des eFPGA (le « e » veut dire « embeddable », signifiant que les FPGA sont intégrables dans des SoC). J’ai beaucoup aimé le concept, mais j’ai été extrêmement frustré par la grande fermeture de ce milieu : les outils pour concevoir les puces sont propriétaires, les PDK des fondeurs sont propriétaires, les FPGA sont propriétaires et les outils pour programmer les FPGA sont propriétaires. Bref, c’est proprio de A à Z.
Il est à noter qu’il existe des projets en Open Hardware utilisant des FPGA et que depuis peu il existe une chaîne d’outils libre ayant fait l’objet d’un journal permettant de programmer certains FPGA. Mais il manque le plus important, le FPGA libre lui‐même. Et c’est pourquoi j’ai décidé de créer une architecture de FPGA libre.

Open FPGA Platform, kFPGA et k1g1

Open FPGA Platform

Open FPGA Platform (OFP) est une chaîne d’outils visant la création, l’implémentation et la programmation de FPGA. À partir de modèles décrivant des architectures FPGA, la solution va permettre à l’utilisateur de créer son propre cœur FPGA ayant les caractéristiques voulus, de générer le flot de conception permettant de l’implémenter à destination du fondeur ou FPGA cible (oui, on peut faire de la « FPGA‐ception », ce qui est pratique pour la phase de développement) et de générer les outils de programmation.

Pour faire une analogie avec des processeurs, c’est comme si Bob, à partir des modèles d’architecture processeur Intel et ARM, utilisait OFP pour se créer un processeur compatible Intel composé de huit cœurs de calcul et un autre compatible ARM double cœur, qu’il utilisait OFP pour les implémenter respectivement pour une fabrication chez le fondeur Global Foundry et pour le faire tourner sur un FPGA Xilinx, et, qu’enfin, OFP générait les chaînes de compilation spécifiques à ces processeurs.

Génération du RTL

Il s’agit de la partie générant le code décrivant le FPGA à partir de l’architecture sélectionnée et des paramètres de personnalisation spécifiés par l’utilisateur. Pour l’instant, seul le Verilog est pris en charge comme langage cible.

Implémentation

Pour les flots de conception, je vais prochainement intégrer la prise en charge de qflow pour les implémentations physiques et la gestion du Vivado de Xilinx pour cibler ses FPGA.
La prise en charge des FPGA Intel (ex‑Altera) et Lattice Semiconductor au travers de leurs outils respectifs est envisagé mais n’est pas une priorité. Offrez‐moi un de leur FPGA et peut‐être que la priorité augmentera. ;)

À plus long terme, je compte aussi ajouter la gestion des outils de chez Cadence, Synopsys et Mentor (les trois principaux éditeurs d’outils de microélectronique) pour faire les implémentations physiques, mais ça attendra que j’ai plusieurs centaines de k€ sur mon compte en banque pour me payer les licences nécessaires (si des commerciaux passent par là, n’hésitez pas à me faire une offre pour des licences de R & D non destinées à réaliser un tape‑out. ;)

Programmation

Pour la programmation des FPGA, je compte me baser sur Yosys pour faire la synthèse logique et sur nextpnr pour faire le placement‑routage.

En attendant, je fais la programmation à la main et c’est un peu relou… Voir ce code pour avoir un exemple.

kFPGA

kFPGA (killruana’s FPGA, oui, j’ai manqué d’inspiration pour choisir le nom) est une architecture FPGA destinée à être utilisée avec Open FPGA Platform. Il s’agit pour l’instant d’une architecture extrêmement simple : une grille de tuiles logiques composées chacune d’une boîte de commutation (switchbox) pour le routage et d’une grappe d’éléments logiques (Look‑Up Table suivie d’une Flip‑Flop débrayable).

Architecture kFPGAArchitecture kFPGA
Détail d’une tuileDétail d’une tuile

Tous les éléments sont paramétrables : le nombre de tuiles, le nombre d’éléments logiques par tuile, la taille des tables de correspondance (LUT dans les éléments logiques, la taille des bus d’interconnexion entre les tuiles, le nombre d’entrées‑sorties du cœur, le nombre de signaux d’horloge, de set, de reset et d’enable.

Je compte l’améliorer dans les itérations suivantes afin de me rapprocher de ce qu’on peut trouver dans les FPGA commerciaux (blocs de mémoire vive, DSP — processeur de signal numérique — de multiplication, nouvel élément logique plus polyvalent, etc.). Pour l’instant, il s’agit surtout d’une preuve de concept pour valider qu’il est possible de faire une architecture FPGA dans son garage. ;)

k1g1

k1g1 (nomenclature retenue pour le moment : kq) est un FPGA basé sur l’architecture kFPGA. Il possède une seule tuile logique contenant un seul élément logique constitué d’une LUT à deux entrées (là où la concurrence propose généralement de 4 000 à 150 000 éléments logiques constitués de LUT à six entrées…), et une paire d’entrées‑sorties par face. Bref, c’est le minimum syndical pour valider le concept.

En utilisant la chaîne d’outils libre qflow, j’ai pu réaliser une implémentation physique utilisant la bibliothèque de portes logiques OSU 0,350 µm. Le circuit obtenu est composé de 139 portes logiques, fait 208,0 x 130,0 µm, soit 27 040 µm² (0,02704 mm²), et peut tourner à la fréquence maximale de 200 MHz.

N’est‐il pas beau mon FPGA ?
Il est pas beau mon FPGA ?

Et voici la simulation du circuit configuré pour faire un « OU » logique :

Il est pas beau mon FPGA ?

Licence

Depuis le début, je parle de Libre. Mais je n’ai pas encore évoqué la licence choisie. Pour le moment, tous les projets (OFP, kFPGA et k1g1) sont sous licence CeCILL-B.

Le futur

À terme, j’aimerais créer une entreprise vendant du support autour du projet OFP (création d’architectures spécifiques, réalisation des implémentations physiques…).
Une fois que l’architecture sera suffisamment avancée, j’aimerais monter un financement participatif afin de financer la fabrication de FPGA (eFabless propose des prix intéressants et se base sur un flot de conception libre) à destination des hobbyistes, dans le double objectif de participer au Libre et de faire ma pub. Mais on n’y est pas encore…

Sources

Tous les projets sont auto‐hébergés sur mon instance Gitea :

Quelles sont les technos utilisées ?

Jusqu’à présent, je n’ai pas trop parlé du code derrière Open FPGA Platform. Tout simplement parce que je suis en plein prototypage et que rien n’est stabilisé. Ça marche, mais c’est moche et fortement couplé. Mais pour l’instant, j’utilise :

  • du Python et le moteur de gabarits Jinja2, pour générer le RTL des FPGA ;
  • qflow, pour faire des implémentations physiques  ;
  • Xilinx Vivado, pour faire des implémentations à destination des FPGA Xilinx et pour valider syntaxiquement le code généré ;
  • cocotb, pour créer les bancs de test ;
  • le simulateur Icarus Verilog ;
  • le visionneur de signaux GTKWave.

Aller plus loin

  • # Tu connais Symbiflow ?

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

    Ça bouge pas mal côté FPGA et Opensource ces derniers temps.

    Projet de "GCC" du FGPA: (par reverse engineering des architectures & outils)
    https://symbiflow.github.io/

    Nouveau FPGA (chinois) pas cher:
    https://hackaday.com/2019/11/03/the-5-fpga/

  • # Belle idée

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

    Très beau projet.

    J'espère qu'il va progresser car, à mon sens, le FPGA reste encore un des derniers bastions qui n'a pas été encore "ouvert".

  • # Pourquoi en faire une dépêche ?

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

    Plop, ici l'auteur du journal à l'origine de la dépêche.

    J'ai écrit le journal parce que j'étais content d'avoir franchi une étape dans le cadre de mon projet. Mais en vrai pour l'instant il n'y a pas grand chose. C'est un peu comme si Mr Torvald avait annoncé sur Usenet que son proto-noyau arrivait à se faire charger correctement et qu'il affichait un hello world (en somme la première étape des tutos d'OSDev). C'est cool pour lui, mais il lui reste beaucoup de travail avant de révolutionner le monde. Pis la qualité du journal est assez bof, c'est pas très clair, bref ça a été écrit au milieu de la nuit dans l'euphorie et la fatigue.

    Je comptais produire une dépêche, mais pas tout de suite. Je voulais attendre d'avoir des vrais trucs à présenter tel qu'un cœur FPGA fonctionnel avec au moins 1k éléments logique (le minimum pour être crédible dans l'industrie) et la chaîne d'outils pour le programmer.

    Je critique pas, je suis juste surpris de l'ampleur des réactions. Je m'attendais à finir avec un journal à +10 et 3 commentaires de félicitations de gens qui s'y connaissent en FPGA, pas à un journal à +68, des discutions techniques intéressantes, une dépêche et martoni< qui me cite déjà en tant que vendeur de FPGA sur son blog.

    • [^] # Re: Pourquoi en faire une dépêche ?

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

      Profites de ton succès, et ne mets pas en marche le syndrome de l'imposteur !

      "La première sécurité est la liberté"

    • [^] # Re: Pourquoi en faire une dépêche ?

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

      Tu ne t'en rend pas compte : nous les modérateurs on a soif de belles dépêches. Ton journal est super intéressant, ça fait vibrer nos cordes libristes. Or les journaux sont beaucoup moins lus que les dépêches. On s'est dit que ça méritait amplement « la une ».

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Pourquoi en faire une dépêche ?

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

      J'ai lu en diagonale le journal avant sa promotion. Je ne m'y suis pas attardé parce que 1) j'étais au taf 2) je n'y connais pas grand chose et 3) je l'ai bookmarké, pour quand j'aurai le temps.

      Les FPGAs, j'ai découvert leur existence sur linuxfr, dans mon esprit, c'est mêlé avec des termes du genre verilog, VHDL, eux-mêmes étant liés (toujours dans mon esprit) à "plus bas niveau que l'assembleur".

      Bref, me suis bookmarké ton journal parce que je pense qu'il me permettra d'augmenter ma compréhension de l'informatique de manière générale, et je pense que c'est un but qui est quand même vachement proche de ce que je suppose être un des objectifs du libre. Après tout, une des libertés est bien celle d'étudier, avec selon moi une connotation d'apprendre, de partager la connaissance.

      Du coup, je pense que ton journal est plus qu'éligible au "rang" de dépêche, même si tu parles d'un hello world.
      Accessoirement, c'est juste super cool de faire un hello world de ce style!

      PS: bon courage pour la suite et meilleurs voeux de réussite.

      • [^] # Re: Pourquoi en faire une dépêche ?

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

        dans mon esprit, c'est mêlé avec des termes du genre verilog, VHDL, eux-mêmes étant liés (toujours dans mon esprit) à "plus bas niveau que l'assembleur".

        Ça n'a pas grand chose à voir avec une programmation en assembleur. C'est plus proche de la conception électronique que logicielle. Ici tu programmes comme si tu concevais une puce ASIC ou un circuit avec des portes logique en composants discrets (TTL ou CMOS) et c'est d'ailleurs pour cette raison que c'est utilisé pour le prototypage de puces.

        • [^] # Re: Pourquoi en faire une dépêche ?

          Posté par . Évalué à 6 (+5/-0). Dernière modification le 06/11/19 à 09:33.

          Dans l'absolu, il a pas tord. C'est effectivement plus bas niveau que l'assembleur au sens où on manipule directement des portes logiques.

          Freem<, pour l'exemple, là je décris un simple additionneur 32 bits en verilog :

          module Adder(s, a, b);
              input [3:0] a, b;
              output [3:0] s;
          
              assign s = a + b;
          endmodule

          Ici, c'est ce que j'obtiens après un passage dans un outil de synthèse. Il m'a tout converti en portes logiques abstraites

          module Adder(s, a, b);
            wire _00_;
            wire _01_;
            wire _02_;
            wire _03_;
            wire _04_;
            wire _05_;
            wire _06_;
            wire _07_;
            wire _08_;
            wire _09_;
            (* src = "rtl/Adder.v:2" *)
            input [3:0] a;
            (* src = "rtl/Adder.v:2" *)
            input [3:0] b;
            (* src = "rtl/Adder.v:3" *)
            output [3:0] s;
            assign _00_ = a[1] ^ b[1];
            assign _01_ = ~(a[0] & b[0]);
            assign s[1] = ~(_01_ ^ _00_);
            assign _02_ = a[2] ^ b[2];
            assign _03_ = ~(a[1] & b[1]);
            assign _04_ = _00_ & ~(_01_);
            assign _05_ = _03_ & ~(_04_);
            assign s[2] = ~(_05_ ^ _02_);
            assign _06_ = ~(a[3] ^ b[3]);
            assign _07_ = ~(a[2] & b[2]);
            assign _08_ = _02_ & ~(_05_);
            assign _09_ = _07_ & ~(_08_);
            assign s[3] = _09_ ^ _06_;
            assign s[0] = a[0] ^ b[0];
          endmodule

          À partir de là, je peux lui demander de transformer cette logique en LUT pour cibler un FPGA (ici un ICE40 de chez Lattice)

          module Adder(s, a, b);
            wire _0_;
            wire _1_;
            (* src = "rtl/Adder.v:2" *)
            input [3:0] a;
            (* src = "rtl/Adder.v:2" *)
            input [3:0] b;
            (* src = "rtl/Adder.v:3" *)
            output [3:0] s;
            (* module_not_derived = 32'd1 *)
            (* src = "/home/killruana/opt/eda/yosys/usr/local/bin/../share/yosys/ice40/cells_map.v:56" *)
            SB_LUT4 #(
              .LUT_INIT(16'h9666)
            ) _2_ (
              .I0(b[1]),
              .I1(a[1]),
              .I2(b[0]),
              .I3(a[0]),
              .O(s[1])
            );
            (* module_not_derived = 32'd1 *)
            (* src = "/home/killruana/opt/eda/yosys/usr/local/bin/../share/yosys/ice40/cells_map.v:51" *)
            SB_LUT4 #(
              .LUT_INIT(16'h3cc3)
            ) _3_ (
              .I0(1'h0),
              .I1(b[2]),
              .I2(a[2]),
              .I3(_0_),
              .O(s[2])
            );
            (* module_not_derived = 32'd1 *)
            (* src = "/home/killruana/opt/eda/yosys/usr/local/bin/../share/yosys/ice40/cells_map.v:56" *)
            SB_LUT4 #(
              .LUT_INIT(16'h077f)
            ) _4_ (
              .I0(b[0]),
              .I1(a[0]),
              .I2(b[1]),
              .I3(a[1]),
              .O(_0_)
            );
            (* module_not_derived = 32'd1 *)
            (* src = "/home/killruana/opt/eda/yosys/usr/local/bin/../share/yosys/ice40/cells_map.v:56" *)
            SB_LUT4 #(
              .LUT_INIT(16'h6a56)
            ) _5_ (
              .I0(_1_),
              .I1(b[2]),
              .I2(a[2]),
              .I3(_0_),
              .O(s[3])
            );
            (* module_not_derived = 32'd1 *)
            (* src = "/home/killruana/opt/eda/yosys/usr/local/bin/../share/yosys/ice40/cells_map.v:46" *)
            SB_LUT4 #(
              .LUT_INIT(16'h0ff0)
            ) _6_ (
              .I0(1'h0),
              .I1(1'h0),
              .I2(b[3]),
              .I3(a[3]),
              .O(_1_)
            );
            (* module_not_derived = 32'd1 *)
            (* src = "/home/killruana/opt/eda/yosys/usr/local/bin/../share/yosys/ice40/cells_map.v:46" *)
            SB_LUT4 #(
              .LUT_INIT(16'h0ff0)
            ) _7_ (
              .I0(1'h0),
              .I1(1'h0),
              .I2(b[0]),
              .I3(a[0]),
              .O(s[0])
            );
          endmodule

          Ou alors de cibler une véritable bibliothèques de portes logiques (ici des standard cell OSU 035) pour ensuite fabriquer un circuit intégré

          module Adder(s, a, b);
            wire _00_;
            wire _01_;
            wire _02_;
            wire _03_;
            wire _04_;
            wire _05_;
            wire _06_;
            wire _07_;
            wire _08_;
            wire _09_;
            wire _10_;
            (* src = "rtl/Adder.v:2" *)
            input [3:0] a;
            (* src = "rtl/Adder.v:2" *)
            input [3:0] b;
            (* src = "rtl/Adder.v:3" *)
            output [3:0] s;
            NAND2X1 _11_ (
              .A(b[0]),
              .B(a[0]),
              .Y(_00_)
            );
            NAND2X1 _12_ (
              .A(b[1]),
              .B(a[1]),
              .Y(_01_)
            );
            INVX1 _13_ (
              .A(_01_),
              .Y(_02_)
            );
            NOR2X1 _14_ (
              .A(b[1]),
              .B(a[1]),
              .Y(_03_)
            );
            NOR2X1 _15_ (
              .A(_03_),
              .B(_02_),
              .Y(_04_)
            );
            XNOR2X1 _16_ (
              .A(_04_),
              .B(_00_),
              .Y(s[1])
            );
            OAI21X1 _17_ (
              .A(_00_),
              .B(_03_),
              .C(_01_),
              .Y(_05_)
            );
            AND2X2 _18_ (
              .A(b[2]),
              .B(a[2]),
              .Y(_06_)
            );
            NOR2X1 _19_ (
              .A(b[2]),
              .B(a[2]),
              .Y(_07_)
            );
            NOR2X1 _20_ (
              .A(_07_),
              .B(_06_),
              .Y(_08_)
            );
            XOR2X1 _21_ (
              .A(_05_),
              .B(_08_),
              .Y(s[2])
            );
            AOI21X1 _22_ (
              .A(_05_),
              .B(_08_),
              .C(_06_),
              .Y(_09_)
            );
            XOR2X1 _23_ (
              .A(b[3]),
              .B(a[3]),
              .Y(_10_)
            );
            XNOR2X1 _24_ (
              .A(_09_),
              .B(_10_),
              .Y(s[3])
            );
            XOR2X1 _25_ (
              .A(b[0]),
              .B(a[0]),
              .Y(s[0])
            );
          endmodule

          Et c'est la que je me rends compte que mon outil de synthèse est bof. Vu que dans ma bibliothèque de porte logique j'ai une porte de type full adder, il aurait pu me générer le résultat suivant :

          module Adder(s, a, b);    
              wire _00_;
              wire _01_;
              wire _02_;
          
              FAX1 _04_(
                  .A(a[3]),
                  .B(a[3]),
                  .C(_02_)
                  .YC(),
                  .YS(s[3])
              );
              FAX1 _05_(
                  .A(a[2]),
                  .B(a[2]),
                  .C(_01_)
                  .YC(_02_),
                  .YS(s[2])
              );
              FAX1 _06_(
                  .A(a[1]),
                  .B(a[1]),
                  .C(_00_)
                  .YC(_01_),
                  .YS(s[1])
              );
              HAX1 _07_(
                  .A(a[0]),
                  .B(a[0]),
                  .YC(_00_),
                  .YS(s[0])
              );
          endmodule

          Dans l'absolu, les deux résultats précédents sont fonctionnellement équivalents. Mais il y a de bonnes chances que la solution à base de full-adder soit plus intéressante au niveau vitesse de fonctionnement et surface utilisée.

  • # H1N1

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

    Super initiative, si le projet aboutit, ça va faire un carton!
    Tu peux me compter dans les premiers acheteurs.

    Un FPGA libre sur un PCB avec hdmi et 2 ports USB fera le bonheur des libristes fan de retrogaming/retrocomputing.

    • [^] # Re: H1N1

      Posté par (page perso) . Évalué à 4 (+2/-0).

      Un FPGA libre sur un PCB avec hdmi et 2 ports USB fera le bonheur des libristes fan de retrogaming/retrocomputing.

      Houla pas trop vite coco ! si tu veux du HDMI et de l'USB il va falloir aussi intégrer des pairs différentielles et autre sérialiseur/désérialiseur. Périphérique qui ne sont même pas toujours dispo sur les (tout) petits FPGA.

    • [^] # Re: H1N1

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

      Le HDMI demandant une licence relativement onéreuse, mieux vaut du DisplayPort, du DVI voire une sortie analogique.

      Sinon perso je suis pas hyper fan du concept. Les émulateurs apportent beaucoup trop d'améliorations diverses qui rendent l'expérience plus belle, confortable ou qui simplement rendent finissables certains jeux.

      • [^] # Re: H1N1

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

        Pour «émuler» de très vieilles consoles qui n'utilisaient même pas de microprocesseur c'est pas mal. C'est d'ailleurs le sujet du dernier livre de Steven Hugg : Designing Video Game Hardware in Verilog.

        • [^] # Re: H1N1

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

          Si un émulateur n'apporte pas d'améliorations ou ne peut pas simuler correctement certains circuits, effectivement c'est plus intéressant.

          Après je suis certain qu'il y a aussi un marché pour les puristes qui cherchent l'émulation parfaite, ça reste un compromis.

  • # Qflow

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

    En utilisant la chaîne d’outils libre qflow, j’ai pu réaliser une implémentation physique utilisant la bibliothèque de portes logiques OSU 0,350 µm. Le circuit obtenu est composé de 139 portes logiques, fait 208,0 x 130,0 µm, soit 27 040 µm² (0,02704 mm²), et peut tourner à la fréquence maximale de 200 MHz.

    Beaucoup de mots que pas grand monde ne doit comprendre ici ;) Par contre qflow est un (très vieil) outils vraiment intéressant. Tu crois que tu pourrais faire un tuto/article sur le sujet ? Peut-être que ça pourrait même intéresser des magazines comme Hackable/LinuxMag non ?

    • [^] # Re: Qflow

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

      beaucoup de mots que pas grand monde ne doit comprendre ici ;)

      Je sais, mais au moment de l'écriture du journal (minuit passé), je ne me suis pas senti motivé pour faire EDA 101…

      Par contre qflow est un (très vieil) outils vraiment intéressant.

      Pour avoir utiliser les outils des éditeurs Synopsys et Cadence, je trouve que ses deux seuls avantages sont d'être gratuits facile à utiliser pour des petits projets par son coté clickodrome.
      Maintenant que je vais devoir faire des trucs un peu plus complexe pour garder des temps d'implémentations raisonnable, j'ai peur que ça soit la merde. Il y a un gros manque de documentation ou d'exemple au niveau de qflow lui même et des outils utilisés.

      Je ne sais pas si les mots suivants ont du sens pour toi, mais il faudrait que j'arrive à mettre en place un flot hiérarchique où je fais d'abord l'implémentation de la tuile logique puis que je l'utilise sous forme de hard macro dans le cœur.
      Et je pense que le jour où j'y arriverai, je ferais un petit article pour ne pas perdre la connaissance :)

      • [^] # Re: Qflow

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

        Je ne sais pas si les mots suivants ont du sens pour toi, mais il faudrait que j'arrive à mettre en place un flot hiérarchique où je fais d'abord l'implémentation de la tuile logique puis que je l'utilise sous forme de hard macro dans le cœur.

        Cela serait trop lourd de tout garder ensemble ? Concernant le routage tu semble faire du proche en proche, dans des FPGA type atmel, il avait des lignes qui faisaient toutes la hauteur du chip, l'idée est de perdre moins de temps sur un fils avec un gros fanout. Gérer du routage hiérarchique est aussi pour plus tard ?

        "La première sécurité est la liberté"

  • # Icarus Verilog

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

    Est-ce que Icarus Verilog évolue encore ?
    Le site ne semble pas avoir bougé depuis de années.

Envoyer un commentaire

Suivre le flux des commentaires

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