Journal Compiler pour un FPGA

Posté par  (site web personnel) .
Étiquettes : aucune
0
10
août
2005
Une boite vient de lancer un concept interrescant. Cela fait longtemps que l'on essait d'augmenter le niveau d'abstraction des langages pour que même des softeux se croit capable de coder pour du hardware (oui, je sais troll inside).

SystemC est la dernière tentative qui continue de survivre. C'est du C++ avec une librairy spécifique, et qui permet de prévoir un mix harware software.

Le nouveau concept propose de coder dans un langage, Mitrion-c, qui favorise tout de même le parrallélisme (mais qui est donc plus difficile à maitriser). L'innovation est dans le fait de ne pas essayer de traduire directement le langage en porte mais par passer par une machine abstraire qui est configurer en fonction du programme puis généré sous forme de HDL.

En gros, le compilateur créait un cpu dédié à la tache que demande le programme.

Un des gros problème pour traduire du C en hardware est la notion de mémoire/pointeur qu'il faut gérer. Pourtant en ciblant directement, un FPGA + une mémoire externe, on semble réduire le problème.

http://www.us.design-reuse.com/news/news11083.html(...)

  • # linux mag

    Posté par  . Évalué à 1.

    Pour info Il y a un article qui en parle dans ce numéro :
    http://www.linuxmag-france.org/produit.php?produit=393(...)
    ou celui là :
    http://www.linuxmag-france.org/produit.php?produit=389(...)

    • [^] # Re: linux mag

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

      Je crois que tu te trompes. Les articles sur le VHDL passé dans Lmag ne sont que des introductions rien de plus.

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

      • [^] # Re: linux mag

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

        Je n'ai pas vu/lu les articles en question : afin de savoir si cela vaut le coup de me casser la tête pour les trouver : de quoi cela traite-t'il? Du moyen de simuler du VHDL ou du Verilog sous Unix/Linux? Du langage à plus proprement parler? Est-ce un article "théorique" (concepts de VHDL/Verilog), ou pratique avec finalité de se rapprocher du monde hardware?

      • [^] # Re: linux mag

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

        Celui d'avril 2005 est pire qu'une introduction, il est plein d'énormités (de mémoire, par exemple, on nous explique que le RTL, c'est has been, que maintenant, on code en VHDL synthétisable -- sachant que RTL, c'est le niveau d'abstraction, et VHDL un language à ce niveau d'abstraction). L'autre, j'ai pas lu.

      • [^] # Re: linux mag

        Posté par  . Évalué à -1.

        C'est peut être juste des intro, j'ai franchement pas les compétences dans ce domaine :) Mais ça parlait bien du SystemC.

  • # Charabia

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

    Quel charabia.

    > L'innovation est dans le fait de ne pas essayer de traduire directement le langage en porte mais par passer par une machine abstraire qui est configurer en fonction du programme puis généré sous forme de HDL.

    Ca donne pas envie de comprendre ce qu'est le FPGA, HDL..

    Sinon en français ca donne quoi ?
    Ca doit être la différence entre les "softeux" et les "hardwareux".
    Les premiers sont obligés d'utiliser des couches d'abstractions et autres formules grammaticales. Les seconds sont des génies qui parlent en phonétique et directement en langage machine.

    Oups, je suis tombé dans le troll !




  • # Benchmarks?

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

    Il y a-t'il quelque part des benchmarks réels ou des performances théoriques qu'on pourrait attendre de ce genre de configurations?

    Ok, pouvoir convertir un code assembleur d'un RISC (pour rester dans un truc "simple") directement en portes logiques pour un FPGA ou tout autre CPLD présente un avantage certain, mais quid du gain de performance par rapport au même code en assembleur exécuté sur un bon vieil ASIC bien concu (comprendre, minimaliste et limite dédié à cette tâche)?
    Certes, on perd le degré de liberté de la reprogrammation, et donc une partie des possibilités offertes par ce genre de plateforme, mais je ne sais pas (je serais curieux de connaître des applications où cela pourrait être utiles) s'il y a beaucoup d'applications qui ne puissent être bien optimisées en se basant sur un bon RISC/CISC plus un ou plusieurs DSP périphérique(s), tout ce petit monde travaillant à une tâche bien particulière en parallèle.

    • [^] # Re: Benchmarks?

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

      Oula attention.

      Le but n'est absolument pas de remplacer le développement d'asic. Un asic de compression d'image sera toujours plus rapide qu'une version soft ou qu'une version FPGA.

      Mais il ne te viendrais jamais à l'idée d'essayer de faire rentrer GNU chess dans un asic. Or des téchniques comme celle montrer pourait le faire.

      Le FPGA est "juste" vu comme un cpu complexe et tordu. La machine "abstraite" doit être d'assez haut niveau pour pouvoir accélerer correctement le code, se baser sur un pauvre RISC voir même un vliw ne doit pas être super interrescant.

      Dans l'article, il précise que les netlist générés sont 2 à 10 fois plus grosses qu'un truc optimisé à la main. Mais évidement, le temps de développement et la compétence des codeurs est largement inférieur.

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

      • [^] # Re: Benchmarks?

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

        Un asic de compression d'image sera toujours plus rapide qu'une version soft ou qu'une version FPGA.

        Oky, on est d'accord.

        Mais il ne te viendrais jamais à l'idée d'essayer de faire rentrer GNU chess dans un asic.

        Effectivement : non, à moins d'avoir quelques années devant moi ;-).

        Or des téchniques comme celle montrer pourait le faire.

        Mais je me pose la question de l'intérêt : je ne suis pas un spécialiste des échecs (loin de là), mais je me doute que les algorithmes qui régissent les stratégies envisageables pour ces derniers sont "réductibles" et "ciblables" par un humain qui analyse son code, et il est éventuellement ensuite possible de les implémenter en les optimisant (toujours avec l'intervention humaine) sur un processeur de calcul dédié, pas forcément "reprogrammable" comme l'est le FPGA.
        Certes, l'intérêt du FPGA réside dans le fait qu'on peut, pour GnuChess, y implémenter une fonction de calcul dédiée, et ensuite en implémenter une autre pour, par exemple, le calcul 3D pour un autre jeu, ou ... (encore que je me pose la question de la limite sur un ordinateur à vocation généraliste, et qui plus est : multitâche), mais dans ce cas pourquoi avoir besoin du C ou d'un autre traducteur d'assembleur vers "portes logiques" : on peut très bien imaginer fournir directement le .sof/.pof (je ne connais que les FPGA Altera) en complément du programme en langage machine pour le processeur RISC/CISC central.
        Pour moi, l'intérêt du C/ASM->portes logiques réside dans le fait de permettre d'économiser l'apprentissage d'un langage de description matériel du type VHDL/Verilog et des outils associés à ceux/celles qui auraient déjà une maîtrise d'un langage de haut niveau du genre C ("haut niveau" : tout est relatif, mais au niveau matériel, c'est du haut niveau...).

        • [^] # Re: Benchmarks?

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

          L'interet est dans les perf atteintes pour des problèmes que l'on ne penseraistrésoudre qu'avec des cpus ou bien de gagner en temps de développement.

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

        • [^] # Re: Benchmarks?

          Posté par  . Évalué à 5.

          Un asic de compression d'image sera toujours plus rapide qu'une version soft ou qu'une version FPGA.
          Je suis d'accord aussi, mais avec une petite nuance : le coût. Le prix unitaire d'un FPGA est bien plus important que celui d'un ASIC, par contre le temps de développement et l'investissement de fabrication n'a rien à voir. De plus, un ASIC est figé, contrairement au soft et au FPGA sur lesquels on peut implémenter de nouveaux algorithmes selon les besoins. Dans ma boîte, on a arrêté de faire des ASICs de traitement d'image, au profit des FPGA.

          Certes, l'intérêt du FPGA réside dans le fait qu'on peut, [...] y implémenter une fonction de calcul dédiée, et ensuite en implémenter une autre
          Maintenant on peut faire de la "reconfiguration partielle" de FPGA, même en cours de fonctionnement. C'est pas simple, y'a des contraintes de conception, mais ca permet d'avoir plusieurs coprocesseurs dédiés pour le prix d'un, à condition de ne pas les utiliser au même moment. A ma connaissance, il n'y a pas besoin de System C pour ca.

          Pour moi, l'intérêt du C/ASM->portes logiques réside dans le fait de permettre d'économiser l'apprentissage d'un langage
          Hmm, je ne suis pas de cet avis. Un très bon softeux qui maîtrise le C/C++ sur le bout des doigts peut être un mauvais développeur *HDL, et inversement. Les subtilités de syntaxe sont à mon avis secondaires (le VHDL ressemble un peu à ADA ou Pascal, avec des begin/end), il s'agit plutôt d'une approche différente de la conception. Cela nécessite une bonne connaissance électronique, notamment pour les gestions d'horloges, les timings et synchonisations, l'allocation des ressources, la maîtrise d'un "style" facilement optimisable par les outils, et surtout le découpage du problème en modules parallèles. Ce ne sont pas des choses qu'on apprend en faisant "juste" du logiciel.

          Ajouter les notions de parallèlisme et d'horloge au C, ca revient à refaire un autre langage HDL [hardware description langage], juste avec une syntaxe plus répandue.

          Mais là où ca a un vrai intérêt, c'est dans une démarche de codesign. Souvent, au début de la définition d'un produit, les choix de répartition entre le soft etle hard sont faits de manière très arbitraire, alors que les algorithmes à implémenter ne sont pas encore bien définis ... Avec un langage mixte (hard+soft), on peut commencer à développer l'application, et la co-simuler, avant d'avoir figé l'architecture de traitement. On peut ensuite choisir son CPU, DSP, FPGA ou ASIC en connaissance de cause, selon les performances attendues. Le gros avantage, c'est que dans la phase de codage tout le monde bosse ensemble, en même temps : pas besoin d'attendre que le hardware soit validé pour commencer le soft, on gagne du temps.

          De toute façon, pour suivre l'évolution de la complexité des puces on va vers des niveaux d'abstraction de plus en plus élevés : tout comme on est passé du langage machine à l'assembleur, puis au langage compilé et ensuite aux langages objets interprétés, pour le design de puces on est passé du dessin de masques aux schémas de portes logiques, puis au HDL et à la réutilisation de modules fonctionnels (IP). Avec à chaque étape un gain de productivité, au prix d'une moins bonne optimisation. D'ailleurs, aucune des vieilles techniques n'est complètement abandonnée, elle est juste réservée aux éléments les plus sensibles. La prochaine étape, dont on parle ici, ne sera certainement pas la dernière ...

          Un autre aspect de la convergence entre le matériel et le logiciel, c'est l'intégraton de plus en plus poussée des différentes technologies électroniques dans une seule grosse puce. Il y a par exemple les Virtex4 de Xilinx, FPGA intégrant un ou deux processeurs PowerPC 405, ou bien les modules VHDL ayant une fonction de processeur comme le Nios ou le MicroBlaze (qui suportent tous les deux µCLinux). A l'inverse, ST vient de sortir des processeurs pour station de base 3G qui contiennent un CPU, un DSP, ... et un petit FPGA. http://www.st.com/stonline/prodpres/dedicate/wsinfra/digital/dsp.ht(...)

          Pour revenir sur le sujet du journal, il s'agit apparemment d'un paramétrage automatique de processeur, selon le code à exécuter, le tout implémenté en FPGA. J'imagine qu'il y a une grosse collection de modules de calcul tout faits en HDL, qui sont assemblés pour paralléliser au maximum un algo donné. Sinon je ne vois pas comment ils font pour traduire 180 lignes de "Mitrion-c" en 150,000 lignes de VHDL. Reste à voir si le gain de temps de développement est tel qu'il vaut une perte de ressources de 50% ...

          • [^] # Re: Benchmarks?

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

            D'après leur white paper cela ressemble vaguement à un énorme vliw, il parle de milliers d'éléments en parrallèle avec une gestion de la mémoire multi banque et gestion également de mémoire interne, donc d'une hierarchie de cache, etc...

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

    • [^] # Re: Benchmarks?

      Posté par  . Évalué à 2.

      Les notions mises en jeux ne sont pas du tout les meme entre un code executé et une realisation en hard (par cablage,fpga ou fpu).
      Le deux ne sont pas comparable, pour imager mon exemple, ecris en C une FastFourrierTransform ou une operation SINUS par DL, en code RISC ou CISC assembleur peut importe, et tente de comparer ca avec un composant qui te fait la meme chose en N cycle de l'horloge micro (N etant la limite de ton dl ou de la taille de ta table fft).On se rend parfaitement compte que la realisation cablé en dur est plus rapide d'un facteur 10 minimum.

      Certes, on perd le degré de liberté de la reprogrammation, et donc une partie des possibilités offertes par ce genre de plateforme, mais je ne sais pas (je serais curieux de connaître des applications où cela pourrait être utiles) s'il y a beaucoup d'applications qui ne puissent être bien optimisées en se basant sur un bon RISC/CISC plus un ou plusieurs DSP périphérique(s), tout ce petit monde travaillant à une tâche bien particulière en parallèle.

      Dans l'absolu tu as raison, en elevant la frequence et le nombre de core on peut arrivé a faire la meme chose. Mais d'un point de vue economique ca ne tiens pas . Un circuit generaliste (DSP ou CPU) utilisé a une fin précise sera sous-utilisé (il y a plein de truc qui ne servent a rien pour cette utilisation et qui sont sur le silicium) et au final revient plus cher qu'un circuit specialisé dédié. Exemple : dans un PC la carte graphique est a base d'asic ou de fpga plutot que de core cpu/dsp.

    • [^] # Re: Benchmarks?

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

      Apparemment, y'a un projet qui cherche à écrire des cores (ça se dit ?) libres pour accélérer des calculs cryptographiques.
      Moi j'y connais rien, mais peut être que ça te permetras de te faire une idée du gain de performance que l'on peut obtenir par rapport à des logiciels équivalents.
      http://openciphers.sourceforge.net/(...)

      En tout cas, c'est un projet intéressant.

      • [^] # Re: Benchmarks?

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

        Ce qui est pas top avec les cartes de crypto est que tu perds un temps fou dans le transfert de donné entre la carte et le cpu. Tu perds tellement de temps dans ses transferts qu'il peut être plus interrescant de faire les calculs sur le cpu que d'attendre la fin des transferts.

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

  • # Il y a bien mieu

    Posté par  . Évalué à 1.

    Salut,

    puisque l'on en est au concept des CPU / FPGA et autre :

    a lire l'excellent travail de Steve Bush : le WIZ processor


    http://www.steve.bush.org/WizdomR&D/index.html(...)

    bonne lecture.

Suivre le flux des commentaires

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