Journal k1g1 : le premier FPGA Libre…

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
84
4
nov.
2019
Ce journal a été promu en dépêche : k1g1 : le premier FPGA Libre….

Sommaire

…à ma connaissance (la dernière fois que j'ai regardé, il n'y en avait pas d'autres)

Camarades moules,

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, j'ignore la traduction exacte) 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 ASICs, les processeurs et les FPGAs

ASIC

Les ASIC (Application-Specific integrated circuit) sont des circuits intégrés dédiés à une application donnée tel 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 performant et plus efficace 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é 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 performant et consomment plus d’énergie.

FPGA

Les FPGA (Field-Programmable Gate Array) sont un compromis entre les ASICs et les processeurs. Tout comme les processeurs, ils sont reprogrammable et comme les ASICs ils sont performant (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.
Je laisse les moules plus compétentes que moi en pédagogie faire une meilleure explication dans les commentaires :)

Mais pourquoi me suis-je lancé 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 FPGAs sont propriétaires et les outils pour programmer les FPGAs 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'outil libre ayant a 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 du 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 CPU Intel et ARM utilisait OFP pour se créer un processeur compatible Intel composé de 8 cœurs de calcul et un autre compatible ARM bi-core, 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écifique à 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 supporté comme langage cible.

Implémentation

Pour les flots de conception, je vais prochainement intégrer le support de qflow pour les implémentations physique et le support de Vivado de Xilinx pour cibler leurs FPGA.
Le support 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 le support des outils de chez Cadence, Synopsys et Mentor (les 3 principaux éditeurs d'outil 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é à 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 ici 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é 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 switchbox pour le routage et d'un cluster d'éléments logiques (LookUp Table suivi d'une Flip-Flop débrayable).

Architecture kFPGA
détail d'une tuile

Tous les éléments sont paramétrable : le nombre de tuiles, le nombre d'élément logique par tuile, la taille des LUT dans les éléments logique, la taille des bus d’interconnexion entre les tuiles, le nombre d'entrées/sorties du cœur, le nombre de 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 RAM, DSP de multiplication, nouvel élément logique plus polyvalent, …). Pour l'instant, il s'agit surtout d'un PoC 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 4k à 150k éléments logiques constitués de LUT à 6 entrées…), et une paire d'entrée/sortie par face. Bref, c'est le minimum syndical pour valider le concept

En utilisant la chaîne d'outil libre qflow, j'ai pu réaliser une implémentation physique utilisant la bibliothèque de portes logiques OSU 0.350um. Le circuit obtenu est composé de 139 portes logiques, fait 208.0x130.0um soit 27040.0um² (0.02704mm²) et peut tourner à la fréquence maximale de 200MHz.

N'est-il pas beau mon FPGA?
Il est pas beau mon FPGA?

Et voici la simulation du circuit configuré pour faire un OR 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 choisi. Pour le moment, tous les projets (OFP, kFPGA et k1g1) sont sous licence CeCILL-B.

Le futur

À terme, j'aimerai crée 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é, j'aimerai monter crowfunding 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 y est pas encore…

Sources

Tous les projets sont auto-hébergé sur mon instance Gitea :
- Open FPGA Platform
- kFPGA architecture
- kFPGA k1g1 core

Quels sont les technos utilisés ?

Dans ce journal, 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 template Jinja2 pour générer le RTL des FPGA
  • qflow pour faire des implémentations physique
  • Xilinx Vivado pour faire des implémentation à destination des FPGA Xilinx et pour valider syntaxiquement le code généré
  • cocotb pour créer les bancs de test
  • le simulateur iverilog
  • le visualiseur de signaux GTKWave

  • # projet qui déchire ?

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 04 novembre 2019 à 09:35.

    Ca sent le projet qui déchire, qui n'arrivera pas à trouver des financements parce que ça bouleverse trop le milieu et notamment les gens/entreprises en place. Bref un gros succès, mais pas avant 10 ou 20 ans.
    Quand au Business modèle d'une entreprise vendant du support, ça me convient. Attention à ne pas se lancer avant d'être sûr d'avoir l'argent pour aller jusqu'au bout. Sinon, ne rien faire. Autrement les banques vont te demander d'être caution personnelle des emprunts et à la moindre difficulté pour avoir un supplément de financement (ça arrivera forcément), tu coules personnellement et potentiellement ta famille avec…

  • # chip de test

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

    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 ?).

    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.

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

    • [^] # Re: chip de test

      Posté par  (site web personnel) . Évalué à 6. Dernière modification le 04 novembre 2019 à 10:29.

      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.

      • [^] # Commentaire supprimé

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 04 novembre 2019 à 10:41.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: chip de test

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

        Oui, j'imagine qu'il faut commencer par une chaîne logicielle complète avant de complexifier.

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

        Ton IP a plein d'application potentiel comme du hardware dédié programmable dans un SoC par exemple. Le problème est toujours le rapport entre prix/flexibilité/puissance de calcul exploitable : accès à la DRAM facile ou pas, accès à des IOs, accès des DMA, connectivité avec un cpu ou pas. 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).

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

        • [^] # Re: chip de test

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

          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 ?"
          Titre de l'image

          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.

          • [^] # Re: chip de test

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

            Oui, il y a des IP de CPU

            Oula rien à voir. Les cpu softcore sont géniaux pour tout ce qui est "Control lent" et complexe, type méga grosse machine d'état. D'ailleurs d'un point de vue hardware, elle pourrait être plus rapide mais pas forcément plus petit qu'un softcore + son programme. (mon premier stage de conception en 2000 était justement de remplacer une machine d'état par un petit risc, on est passé de 7k portes à 3k.)

            Non, je pensais à l'inverse : tu prends un CPU classique Leon ou OpenRisc. Je suis persuadé qu'il existe des opcodes libres pour de futurs extension, ainsi tu rajoutes quelques instructions. Celles-ci sont réalisées par un bloc FPGA dans le CPU qui est à coté de l'ALU et du load/store. En gros, au lieu d'avoir un bloc externe complexe, tu as simplement un nouveau bloc d'opération. Dans ton cas simple, tu peux ainsi faire des pack/unpack dédié pour un processeur réseau par exemple. L'idée est de faire le cœur de calcul dans le FPGA et laisser gérer le reste par le cpu (IO, MUL, LOAD/STORE).

            L'énorme contrainte est que ton FPGA doit être assez rapide pour ne pas trop ralentir le reste du CPU. Si ton pack/unpack prend 5 cycles cpu, mais 1 avec ton FPGA, si le FPGA est 5 fois plus lent, c'est inutile.

            Je pense toujours qu'une instruction dédiée est toujours plus efficace qu'un "core" externe : pas de communication en plus, pas de code OS spécialisé. Il suffit de faire générer la bonne instruction assembleur par le compilateur. Un "driver" ne serait utile que pour changer le contenu du FPGA.

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

            • [^] # Re: chip de test

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

              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.

              • [^] # Re: chip de test

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

                Ça ne rejoindrait pas ce genre d'idée ?

                La connaissance libre : https://zestedesavoir.com

              • [^] # Re: chip de test

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

                Hors, jusque là, les designs de processeurs était courant mais pas ceux de FPGA ;)

                Justement, open risc est à la mode, donc ajouté plusieurs opération "FPGA" doit maintenant être possible. Cela serait génial d'ajouter la gestion du multicycle et du pipeline.

                Il y a plein d'instructions spécialisées comme des CRC, des hash, toutes ne peuvent pas être dans un jeu d'instruction. 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)

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

                • [^] # Re: chip de test

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

                  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".

                  • [^] # Re: chip de test

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

                    Concernant le CRC, il y a une instruction prévu pour dans le jeu d'instruction Intel (voir page 334)

                    Si tu regardes bien, c'est un CRC bien précis (polynomial 11EDC6F41H), et l'instruction ne sert à rien pour un autre polynôme. Avec un bout de FPGA tu peux faire ce que tu veux.

                    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.

                    Pas dans leurs accélérateurs hardware. (ex: https://coral.withgoogle.com/products/accelerator/ )

                    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".

                    Oui mais ce n'était pas vraiment le cas jusqu'à présent. Par exemple, le load multiple est très récent (un vecteur d'adresse pour un vecteur de résultat, et non une seul adresse pour chargé 4 valeurs). Idem pour les fonctions de réduction, comme additionner les 4 valeurs d'un même vecteur entre elles.

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

                    • [^] # Re: chip de test

                      Posté par  . Évalué à 2.

                      Je vois un problème à l'idée, c'est le coup de changement de contexte qui va exploser, car il faudra reprogrammer le fpga pour le nouveau process. Ca peut marcher sur un contexte de microcontrôleurs, mais ca devient réducteur du coup (mais étant donné la montée des RISCV dans ce domaine, ca peut être un marché).

                      • [^] # Re: chip de test

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

                        C'est sûr que l'instruction choisi ne peut pas beaucoup bougé. Mais dans le cas d'un code embarqué le CPU fait une seul chose en général.

                        De toutes façon, la reconfiguration à la volée n'a jamais vraiment décollé dans les FPGA.

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

              • [^] # Re: chip de test

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

                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

                Je dois avouer que je l'avais compris de travers aussi.
                De fait, je trouve l'idée très pertinente.

                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.

                En fait, ils peuvent aussi se partager de la mémoire, ce qui simplifie la communication.

                D'un autre coté, est arrivé avec la 4.19 le DFL, porté par Intel.

              • [^] # Re: chip de test

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

                Non, à ma connaissance il n'y a pas de processeur intégrant des FPGA.

                Avec RiscV on devrait pouvoir faire ce genre de truc. Vu que les extensions «customs» sont prévues dans le jeux d'instruction.

                J'ai plus qu'une balle

                • [^] # Re: chip de test

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

                  C'est faisable aussi avec un composant externe, des instructions génériques sont prévues sur les architectures MIPS pour utiliser un coprocesseur (sans préciser ce que le coprocesseur doit faire), et les FPU sur les processeurs x86 et 68000 ont longtemps été dans une puce séparée, se partageant le travail avec le processeur pour interpréter les instructions.

                  • [^] # Re: chip de test

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

                    C'est totalement impensable d'utiliser un composant externe. On ne tourne plus à 30Mhz de nos jours.

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

                    • [^] # Re: chip de test

                      Posté par  . Évalué à 2. Dernière modification le 05 novembre 2019 à 23:35.

                      PCIe ou OpenCAPI sont tout désignés pour ces usages. C'est sûr que pour l'embarqué c'est pas nécessairement la meilleure solution mais ce n'est pas impensable du tout vu les vitesses de transfert actuelles.
                      Selon la nature de la charge, la latence sera plutôt induite par la vitesse de reprogrammation à la volée du FPGA ou sa vitesse de calcul que par la vitesse du bus. C'est déjà ce qu'on peut constater avec le GPGPU ou le NVMe même sur du PCIe 3.

                      • [^] # Re: chip de test

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

                        Non vraiment, c'est absolument n'importe quoi. Il est totalement impossible de sortir d'une opération d'un CPU. Les latences énormes ne sont pas compatibles.

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

            • [^] # Re: chip de test

              Posté par  . Évalué à 2.

              Ce que tu racontes ça me fait penser à OpenCAPI https://opencapi.org/ d'IBM (à la base) : c'est pas pour se brancher « dans » le CPU, mais sur le bus d'interconnexion à assez bas niveau, en gérant correctement la cohérence des caches, et en s'arrangeant pour respecter les mappings de la MMU. C'est plus « simple » et bas niveau qu'une interco PCIe et moins contraignant niveau vitesse qu'un contrôleur RAM. Ça pourrait éventuellement ressembler à ce que tu décris, si j'ai bien compris le bouzin.

              • [^] # Re: chip de test

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

                Si cela respecte "correctement la cohérence des caches, et en s'arrangeant pour respecter les mappings de la MMU." ce n'est pas simple du tout.

                Je propose simplement de rajouter un bloc de calcul à coté de l'ALU qui soit un FPGA. L'intéret est que l'état (les donnés, les registres) sont géré par le CPU, ce qui enlève 90% de la complexité. Par contre, cela met une contrainte énorme sur la vitesse du bloc et sur ce qui l'est possible de faire (pas de stoquage d'information, sauf pipeline)

                En gros, ton ALU simple prend 2 entrées en provenance de la mémoire ou des registres et une sortie qui sera redirigé. Le FPGA a les mêmes IOs, mais il est programmable ainsi le cpu peut avoir une instruction spécialisée (cf les 4 instructions AES d'intel, etc…).

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

                • [^] # Re: chip de test

                  Posté par  . Évalué à 3.

                  Si cela respecte "correctement la cohérence des caches, et en s'arrangeant pour respecter les mappings de la MMU." ce n'est pas simple du tout.

                  Si j'ai bien compris, le but d'OpenCAPI c'est de te fournir les blocs qui te permettent de l'implémenter dans ton FPGA, comme le protocole d'invalidation est standardisé. Tu « n'a plus qu'à » synthétiser ça avec ton code à toi et roule ma poule (en théorie, et toujours selon ma compréhension limitée).

                  En gros, ton ALU simple prend 2 entrées en provenance de la mémoire ou des registres et une sortie qui sera redirigé.

                  Bref, tu perds tout l'intérêt des FPGA : I/O nombreuses, calcul parallélisé, etc. Je ne comprends pas l'intérêt de ton modèle.

                  • [^] # Re: chip de test

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

                    Bref, tu perds tout l'intérêt des FPGA : I/O nombreuses, calcul parallélisé, etc. Je ne comprends pas l'intérêt de ton modèle.

                    J'ai travaillé sur des SoC. Il y avait un accélérateur de crypto. Il était bien plus rapide le CPU arm… la plupart du temps. Comme c'est un élément externe, avant de lancer un calcul il faut le programmer, si le paquet à chiffrer est petit, autant le faire directement sur le cpu, c'est plus rapide. Ainsi le code en fonction de la taille du paquet utilise l'accélérateur ou non. Ensuite, c'est pratique un accélérateur AES, mais il existe une pléthore de mode d'utilisation qui n'était pas tous inclus.

                    De l'autre côté, Intel a ajouté 4 instructions et des registres 256 bits à ces cpu, elle correspond au cœur de calcul AES, les "modes" étaient faits avec les instructions classiques. Ainsi, intel a multiplié par 10 ses performances AES, dans tous les cas !

                    Les instructions spécialisées sont aussi bien plus simples à utiliser qu'un core externe : il suffit d'avoir un compilateur pour générer le bon code.

                    Pour utiliser un core spécialisé, il faut écrire un driver pour l'OS, il faut modifier la façon de travailler de certaine librairie pour transmettre et récupérer les blocs traités. Les temps de mise en route ne sont pas nuls, la gestion d'énergie peut être complexe. Il faut aussi trouver un moyen de partager l'accès à la ressource entre 2 logiciels utilisant la fonctionnalité.

                    Le problème évident des instructions spécialisées, c'est que l'on ne peut pas toutes les faire. Il faut choisir. Plusieurs instructions FPGA permettrait de faire certain traitement dédié rapidement. On peut imaginer plusieurs multiplieurs dans ce bloc.

                    Oui, les IOs ici ne rentrent pas en compte. Pour la puissance de calcul d'un FPGA, on peut en général utiliser des centaines de multiplieurs 16 bits (on est loin de float64), mais la complexité va être dans l'accès à la RAM et/ou à un autre CPU pour des besoins de communication sur IP ou sans fils par exemple.

                    On parle beaucoup de FPGA dans des applications de traitement du signal, mais finalement on utilise beaucoup de DSP pour ça, car c'est plus simple à utiliser.C'est plus flexible et des fréquences plus hautes, surtout si le problème est l'accès mémoire bien plus complet sur un cpu. Aujourd'hui, on peut même utiliser des cpu classique pour avoir un support d'OS plus aboutit (cas typique du lecteur MP3 ou l'on est passé de DSP spécialisé à des minuscules ARM)

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

                    • [^] # Re: chip de test

                      Posté par  . Évalué à 5.

                      Les instructions spécialisées sont aussi bien plus simples à utiliser qu'un core externe : il suffit d'avoir un compilateur pour générer le bon code.
                      Pour utiliser un core spécialisé, il faut écrire un driver pour l'OS

                      Je ne suis pas sûr duquel est le plus simple : modifier le compilo ou l'OS ?…

                      il faut modifier la façon de travailler de certaine librairie pour transmettre et récupérer les blocs traités.

                      Effectivement, car tu réutilises l'infrastructure du CPU. Du coup du perd la répartition de ressource et le parallélisme au passage.

                      Les temps de mise en route ne sont pas nuls,

                      Effectivement, c'est un handicap.

                      la gestion d'énergie peut être complexe.

                      Oui, mais tu as délégué la complexité au CPU, quoi.

                      Il faut aussi trouver un moyen de partager l'accès à la ressource entre 2 logiciels utilisant la fonctionnalité.

                      Oui, comme ce qui arrive aujourd'hui avec le multicore (façon NUMA) : la tendance est quand même de gérer aujourd'hui ce genre de complexité correctement car elle est de plus en plus présente partout.

                      mais la complexité va être dans l'accès à la RAM et/ou à un autre CPU pour des besoins de communication sur IP ou sans fils par exemple.

                      Ya bien des cartes qui font du RDMA… c'est pas si complexe (et de mieux en mieux intégré dans le noyau ces dernières années ; je ne suis pas utilisateur, je constate juste).

                      mais finalement on utilise beaucoup de DSP pour ça, car c'est plus simple à utiliser. […] on peut même utiliser des cpu classique

                      Tu vois, tu finis par te tirer une balle dans le pieds : inventer des traitements complexes dans un FPGA « pour la vitesse », ça marche pour quelques petits cas particuliers, mais au final le compromis spécialisation finit par casser quand on trouve un entre-deux à peu près correct.

                      J'ai l'impression même que ces derniers temps, les architectures hybrides ARM avec un Cortex-M secondaire qui map une partie de la RAM remplace les « petits » FPGA pour du traitement temps-réels (car ces CPU « assistants » ne sont pas si ridicule ! Et se programment simplement).

                      Merci pour les arguments, mais ce ne m'a toujours pas convaincu.

                      • [^] # Re: chip de test

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

                        Je ne suis pas sûr duquel est le plus simple : modifier le compilo ou l'OS ?…

                        Pas besoin de modifier le compilateur, il faut juste insérer le code d'instruction assembleur dans une librairy.

                        Du coup du perd la répartition de ressource et le parallélisme au passage.

                        Tu gardes tout justement. C'est l’intérêt principal.

                        comme ce qui arrive aujourd'hui avec le multicore

                        Gérer 2 cpu ou plus n'a rien à voir avec la gestion d'accélérateur.

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

  • # Archipelago

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

    …à ma connaissance (la dernière fois que j'ai regardé, il n'y en avait pas d'autres)

    À ma connaissance il y avait archipelago, mais c'est un FPGA virtuel.

    J'ai plus qu'une balle

  • # pourquoi pas SymbiFlow ?

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

    Génial, j'en rêve depuis 10 ans maintenant. J'ai même un blog pour parler de ça.

    Je me pose une question par contre:
    Pourquoi réinventer la roue avec OFP ?
    Pourquoi ne pas intégrer le FPGA au projet SymbiFlow ?
    SymbiFlow est déjà un outils fonctionnel pour les ice40, ecp5 et même pour la série 7 de Xilinx. Pourquoi ne pas mutualiser les efforts et faire émerger un standard ?

    J'ai plus qu'une balle

    • [^] # Re: pourquoi pas SymbiFlow ?

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

      Je me répond tout seul : OFP est un outils pour générer le FPGA. SymbiFlow est un outils pour synthétiser (placement, routage, bitstream …) sur FPGA.

      J'ai plus qu'une balle

    • [^] # Re: pourquoi pas SymbiFlow ?

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

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

Suivre le flux des commentaires

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