jtremesay a écrit 372 commentaires

Le code source est disponible. Y'a qu'à crées un cœur spécifique FPGA répondant au besoin et trouver quelques milliers d'euros pour passer en fonderie :)

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.

Je suis informaticien. J'ai commencé avec un magnifique effet Dunning-Kruger avant de me rendre compte que tel Jon Snow, je ne savais rien. Depuis, je suis largement tombé dans le travers inverse…

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.

Tu connais Symbiflow ?

Oui, on en a un peu parlé dans les commentaires du journal

Pour ma défense, j'ai plus cherché sur github que dans les papiers de recherche ^'

Tu t'es déjà auto-répondu, mais je vais faire un complément de réponse.

Tu n'avais pas tout à fait tord, OFP ne sert pas qu'à créer les FPGA (-> génerer le RTL). C'est la trousse à outil multi-fonction qui fera tout. Il s'occupera aussi de générer et exécuter les flots d'implémentations et surtout de la programmation (synthèse, P&R, bitstream) des FPGAs. Mais je ne comptais pas réinventer la roue et dans l'idée OFP générera les bibliothèques technos spécifiques à l'architecture cible (ce genre de fichiers quoi) et appellera en sous main les outils dédiés.

Après, j'ai pas forcément fait une recherche ultra-détaillée sur l'existant (shame on me). Je connaissais déjà yosys et j'avais entendu parler de arachne-pnr (et son successeur nextpnr) via le projet IceStorm.
Mais comme avant d'envisager la programmation des FPGA il me fallait déjà des cœurs plus ou moins fonctionnels (qui ont au moins un RTL valide :p), j'avais pas creusé le sujet plus que ça.
Maintenant que je connais son existence, je tenterai de m'intégrer dessus pour gérer la programmation :)

Concernant ton blog, je sais, je t'avais envoyé un petit mail il y a quelques mois pour apporter une petite correction sur la toolchain de mon ancien employeur et pour vaguement mentionner ce projet :)

kFPGA
Un embryons de projet «fabless» de FPGA libre. À suivre !
Le premier modèle est bientôt sortie et se nomme k1g1

Je ne suis pas sûr de la pertinence de me mentionner parmi les vendeurs tant que je n'aurais pas au moins le K1G1k (1k logic elements !!!!!), mais c'est gentil :)

Il y a plein d'instructions spécialisées comme des CRC, des hash, toutes ne peuvent pas être dans un jeu d'instruction.

Concernant le CRC, il y a une instruction prévu pour dans le jeu d'instruction Intel (voir page 334), le compilateur peut donc émettre l'opcode lançant le calcul d'un CRC. Même principe pour les instructions accélérant le support du chiffrement/déchiffrement AES et autres.

Si j'ai bien compris le principe de tensorflow de google, ils ont simplement ajouter à un jeu d'instruction vectoriel, un jeu d'instruction matriciel (le vecteur de 4 peut aussi être une matrice 2*2)

De ce que je vois, ils n'ont pas rajouté d'instructions mais ont tout simplement utilisés les instructions vectoriels de calcul pour faire des maths sur des matrices. Il y a d'ailleurs un article d'Intel là dessus. Ne pas oublier que dans ce contexte, vectoriel n'a pas la définition mathématique de "matrice dont l'une des dimensions est de cardinal 1" (ou quelque soit la bonne manière de le formuler) mais "instruction agissant sur plusieurs données à la fois".

Je n'étais pas sûr d'avoir compris le sens de ta demande et je suis parti du mauvais côté de l'interprétation :D

Non, à ma connaissance il n'y a pas de processeur intégrant des FPGA.
Xilinx propose les Zynq qui dans le même SoC embarque un FPGA et un processeur ARM, mais le processeur accède au FPGA via un un bus classique comme il accéderait à un autre type de contrôleur.

À mon avis, pour voir arriver ce genre de solution, il faudrait que les créateurs de processeurs aient accès à des cœurs de FPGA pour pouvoir les intégrer. Hors, jusque là, les designs de processeurs était courant mais pas ceux de FPGA ;) Mais depuis qu'Intel a racheté Altera et possède donc le savoir faire sur les deux domaines, on peut envisager qu'ils se penchent sur l'idée.

J'ai pas relu dans le détail mon contrat, mais je pense que malgré mon départ je reste soumis à une clause de confidentialité ou truc du genre. Donc je vais me contenter de commenter ce qui a été rendu public

• Un testchip contenant un processeur Leon et un eFPGA Menta a été conçu lors d'un projet européen visant à définir l'électronique devant équiper l'armement de demain
• un testchip en GF 14nm a été fabriqué en 2016 pour XXX
• il semblerait qu'ils est étés sélectionnés pour intégrer un SoC destiné à faire de la 5G

Et «off the record», on a eu de nombreux de prospects qui ont évalués notre technologie et celle de la concurrence. D'après les retours qu'on a eu (les commerciaux sont un peu radins en retours vers les ingénieurs), il semblerait que notre solution était globalement la favorite (notamment grâce à l’extrême simplicité d'utilisation d'Origami Programmer) mais au final personne ne signait jamais.
Donc jusqu'à mon départ en 2018, elle tournait surtout grâce à l'argent injecté par les investisseurs.

C'est vrai aussi que ton IP peut se tester dans un autre FPGA :)

Ça a été un de mes premiers mind-blowing quand j'ai bossé pour la start-up qui concevait des eFPGA : « Attends, tu me dis que les FPGA se programment en verilog et qu'on écrit nos FPGA en verilog ? Et-ce que ça veut dire qu'on peut faire tourner un de nos cœur sur un autre ? Voir créer une FPGAception ?"

D'ailleurs, je me demande si quelqu'un à déjà penser à faire un bloc de calcul de cpu à base de FPGA ou si c'est trop lent (avantage: pas d'IO dédié, pas de drivers d'OS dédié, partage de ressource utilisant les registres CPU déjà gérés)

Oui, il y a des IP de CPU dans le catalogue de Xilinx, cf https://www.xilinx.com/products/design-tools/microblaze.html
Autre avantage non négligeable, c'est quand tu as déjà le programme qui fait la fonctionnalité demandé mais que ta cible ne comporte pas de CPU. Tu perds peut-être en performance, mais qu'est-ce que tu gagnes en temps de développement.

Il existe des programmes universitaires qui peuvent avoir accès à des fabrications de chip groupé. cf https://mycmp.fr/ L'idéal serait de bosser avec un labo pour faire un chip de démonstration (couplé avec un openrisc ?).

J'y ai pensé et je comptais me tourner vers le LIRMM (Laboratoire d'Informatique, de Robotique et de Microélectronique de Montpellier) vu que j'habite cette ville. Mais comme pour l'instant j'avais rien à montrer…

Au niveau de la cellule de FPGA, pourquoi ne pas avoir ajouter une "alu" c'est une des premières optimisations qui est ajouté, pour augmenter la vitesse des fonctions mathématiques.

Parce qu'il faut tout que je développe tout en parallèle : l'architecture FPGA, le générateur de RTL, la chaîne d'outils pour la programmation, … Du coup, je préfère faire aussi simple que possible et améliorer par petites itérations successives histoire de ne pas me noyer sous la complexité. Et il n'y a pas plus simple que juste des LUT et des flip-flops. Mais ça me demande quand même déjà pas mal de travail pour valider que l'architecture n'est pas bancale. Vu que je n'ai encore rien pour faire le placement routage (j'ai bricolé un truc avec yosys pour me faire la synthèse logique et le mapping vers de LUT), je suis obligé de générer le bitstream à la main.

Voila le bitstream que je viens de finaliser pour tester un cœur constitué d'une seule tuile de 4 logique éléments composé de LUT2 :

    bitstream = (
        ( # Switchbox
            ( # To LE[3].data[1]
                0b110 # from south[0]
            ) << 33
            | 
            ( # To LE[3].data[0]
                0b111 # from west[0]
            ) << 30
            | 
            ( # To LE[2].data[1]
                0b110 # from south[0]
            ) << 27
            | 
            ( # To LE[2].data[0]
                0b111 # from west[0]
            ) << 24
            | 
            ( # To LE[1].data[1]
                0b110 # from south[0]
            ) << 21
            | 
            ( # To LE[1].data[0]
                0b111 # from west[0]
            ) << 18
            | 
            ( # To LE[0].data[1]
                0b110 # from south[0]
            ) << 15
            | 
            ( # To LE[0].data[0]
                0b111 # from west[0]
            ) << 12
            | 
            ( # To west[0]
                0b11 # from le[3]
            ) << 9
            | 
            ( # To south[0]
                0b101 # from le[2]
            ) << 6
            | 
            ( # To east[0]
                0b100 # from le[1]
            ) << 3
            | 
            ( # To north[0]
                0b011 # from le[0]
            )
        ) << 20
        |
        ( # Logic block
            ( # Logic element 3
                0b1 << 4 # Enable LE DFF
                | 
                0b0111 # !(B & A)
            ) << 15
            |
            ( # Logic element 2
                0b1 << 4 # Enable LE DFF
                | 
                0b0110 # B ^ A
            ) << 10
            |
            ( # Logic element 1
                0b1 << 4 # Enable LE DFF
                | 
                0b1000 # B & A
            ) << 5
            |
            ( # Logic element 0
                0b1 << 4 # Enable LE DFF
                | 
                0b1110 # B | A
            )
        )
    )

Oui, c'est moche et error-prone… et la prochaine étape : le test d'un cœur multi-tuile pour faire un adder 4 bits o/

Donc les éléments logiques avec un peu plus d'intelligence (notamment inclusion d'un full-adder et la propagation des carry par du routage dédié) c'est prévu pour la deuxième génération de l'architecture.

Le succès est à saisir dans les deux ans ou jamais. Comme j'ai bossé dedans, je sais que la demande de FPGA sur-mesure et embarquable dans des SoC est extrêmement forte auprès de certaines branches de l'industrie mais qu'aucune des start-up proposant ce genre de produits (Achronic, Flex Logic, Menta, NanoXplore, …) n'a encore signé de gros contrats. Et c'est une situation du type "Winner takes all" car aucun industriel ne veut être le premier à signer un gros chèque de peur d'avoir misé sur la mauvaise entreprise qui coulera dans 2 ans alors qu'ils ont besoin d'un support décennal des produits. Du coup, la première à signer un gros contrat et sécuriser sa situation financière risque fortement de récupérer les autres contrats.

L'avantage d'avoir un modèle basé sur le libre, c'est qu'au pire si je coule, ils pourront toujours reprendre le bazar en interne ou passer par un autre presta, ce qui devrait pas mal les rassurer :)

Mais sinon ouais, tant que je n'ai pas un cœur prêt à partir en fonderie et la chaîne d'outils pour le programmer, je ne compte pas me professionnaliser. En vrai, j'ai pas tellement envie de créer une boîte. Je suis un gens de la technique, pas un gestionnaire. je préfère taper du code que me taper de la compta :) Donc si j'arrive à trouver d'autres solutions pour me permettre de m'amuser sur le projet tout en m'assurant un revenue, why not?

1. c'est celui qui dit qui est
2. je mens pas, y'a aussi du JS. La preuve https://github.com/microsoft/vscode/blob/1.39.2/src/main.js
3. depuis quand il est nécessaire d'être objectif et exact pour troller ?

Les gros fichiers «bruts», il gère très bien.
Ça peut mouliner un peu si il faut appliquer de la coloration syntaxique sur un fichier de 100k lignes de codes…

Il dispose d'un système de plugins pour ajouter facilement des langages qui ne seraient pas supportés par défaut.

Je l'utilise pour tout ce qui n'est pas C++ (car dans ce cas j'ai une préférence pour Qt Creator), c'est à dire principalement python, bash, tcl, rust, verilog, plain text.

C'est une question rhétorique ou tu fais une supposition ?

J'utilise les flux RSS pour recevoir les news/journaux/liens, et à la vue de la taille du contenu, j'avais cru que c'était un lien et non un journal ^'

Mon point était que ça n'avait de sens de proposer des jeux trop complexe à des personnes dont le développement cérébral n'est pas encore suffisamment avancé pour les gérer.

Je vais prendre un exemple personnel avec le jeu de société Res Arcana. Sur la boite, il est recommandé pour à partir de 12 ans. Les adultes avec qui j'y ai joué n'ont pas eu trop de difficultés à saisir les mécaniques de jeu, même ceux n'étant pas spécifiquement ludistes ou adepte des jeux de stratégie. Par contre, avec une gamine de 10, à priori pas plus bête qu'un autre, ce fut la catastrophe. Il lui manquait notamment la concentration nécessaire pour garder en tête les règles et les capacités de projection pour mettre en place des stratégies. Au final, pour limiter sa frustration et garder un bon rythme de jeu, on s'est retrouver devoir à lui énumérer les différentes actions qu'elle pouvait faire avec leurs pros/cons à chaque fois que c'était son tour et elle en choisissait une plus ou moins au hasard.

Elle n'a pas gardé un trop mauvais souvenir de sa partie, mais je pense que c'est plus pour avoir jouer avec son grand frère, sa grande sœur et sa pièce rapporté de beau-frère que je suis que réellement parce qu'elle a apprécié le jeu. Et je suis certain qu'elle aurait passé un meilleur moment avec un jeu plus adapté à son âge.

Malheureusement pour elle, ma ludothèque est plutôt orientée stratégie velue. Je fais parti de ses gens pour qui plus un jeu est complexe (-> offre une grande variété de mécaniques de jeu), plus il est plaisant.

Un aperçu de ma ludothèque :

Une partie de Civilization à 3. Prévoir au moins 2h + 1h par joueur. Je n'ai jamais réussi à réunir suffisamment de gens motuvés pour faire une partie à 5 :'(

Parce que je ne comprends pas pourquoi tu t'es fait moinssé à ce point là (-10 au moment de l'écriture de ce commentaire) alors que tu te contentes de rapporter de manière plutôt neutre un fait montrant une fois de plus qu'il y a un problème systémique dans notre société.

Je pense que 0AD est trop complexe pour être pris en main avant 12~14 ans.
Il ne faut pas oublié que les enfants sont techniquement des adultes pas finis :)

Calculatrice autorisée ?

Sans aller jusqu'à dire que c'est illisible, mon confort de lecture en a quand même pris un sacré coup.

Il faut compter au moins 20k€ pour 50 testchips. Mais ça inclut la création le masque lithographique (en quelque sorte le négatif de la puce) (c'est le truc le plus cher dans le process de fabrication) que tu peux réutiliser par la suite.

C'est moins vrai.
Par exemple, pas mal de jeux utilisent le moteur Unity qui se code en C#.