Bonjour à tous
J'ai lu avec grand intérêt cet article qui annonçait il y a peu de temps la disponibilité d'une chaîne de développement complètement open source pour un FPGA : https://linuxfr.org/users/martoni/journaux/enfin-une-chaine-de-developpement-completement-open-source-pour-un-fpga
Depuis, l'idée me trotte dans la tête de me mettre à la programmation d'un FPGA, avant tout pour le fun. Une première application que j'y verrais serait de programmer un FPGA dans le but d'accélérer les compilations avec GCC, car c'est un traitement hautement parallélisable (et très utile pour beaucoup d'entre nous).
Ainsi, avec un FPGA qui aurait par exemple 40 unités de calculs, on pourrait lancer une commande du style :
make -fpga -j 40
Ce qui aurait pour effet d'utiliser les 40 unités de calculs du FPGA pour compiler notre programme.
Ce n'est qu'une idée, je n'ai aucune connaissance en programmation des FPGA pour l'instant (j'ai pas mal programmé en assembleur il y a quelques années) et j'imagine que la somme de travail à fournir est conséquente, mais ça n'est pas un problème puisque c'est avant tout pour m'amuser que je souhaite faire ça. Si ça peut servir à d'autres alors tant mieux.
Que pensez-vous de cette idée, et qu'est-ce que vous avez à dire à ce sujet ? Tous vos commentaires, vos suggestions, vos idées, vos remarques seront les bienvenus. Je n'en suis pas au stade de la conception, pour l'instant ce n'est qu'une idée et j'aimerais recueillir vos avis pour savoir à quoi m'attendre. On parle là de spécialiser des circuits électroniques pour accélérer des opérations de compilation, ce n'est pas rien, donc avant de me lancer dans un tel projet je préfère en faire un peu le tour.
Merci
# FPGA
Posté par max22 . Évalué à 7.
Je n'y connais pas grand chose en FPGA, mais ça me paraît extrêmement balaise.
Je pense qu'il faut s'imaginer la "programmation" des FPGA comme placer des composants électroniques (mémoires, portes logiques, bascules, etc) pour faire un circuit. Et au lieu de se placer les composants à la main, on utilise un langage qui va décrire le circuit, et après il sera envoyé dans le FPGA. C'est pour ça que j'ai mis "programmation" entre guillemets.
Ce qui fait qu'il faut s'imaginer compiler du C avec des portes logiques, des bascules, etc. C'est peut-être possible, mais pour un débutant ça me paraît bien trop balaise.
(J'espère ne pas avoir dit de connerie, mais comme il n'y avait pas de réponse…)
# Probablement une mauvaise idée...
Posté par X345 . Évalué à 5.
Enfin tout dépend de ce que tu veux veux faire, et j'ai l'impression que tu n'as pas forcément les idées super claires. Ce n'est pas un mal, c'est en exposant ces idées et en débattant qu'on apprend.
On ne "programme" pas vraiment un FPGA. Un FPGA c'est (en approximation à 10000 mètres d'altitude), un circuit électronique configurable. Tu peux voir ça comme un ensemble de portes logiques (des AND, des OR, des horloges, de la mémoire), dont tu peux changer le "cablage". Un sacré ensemble de portes logiques, les FPGA moyenne gamme ayant des centaines de milliers à des millions de portes. Mieux encore, tu n'as pas besoin de décrire le cablage des portes logiques fil par fil, mais tu peux faire une description plus haut niveau en VHDL ou en Verilog. On utilise ensuite un espèce de compilateur (ou synthériseur) qui tansforme le VHDL en description de cablage. Le FPGA est capable de changer de cablage tout seul. Programmer un FPGA, c'est changer son cablage interne.
Voila pour la description "physique" d'un FPGA. Alors qu'est-ce qu'on peut faire avec ce genre de bestiau ? Hé bien on peut décrire n'importe quel circuit électronique ! Une simple porte AND, par exemple. Plus complexe, on peut décrire le circuit électronique d'un radio-réveil. Ou un filtre passe-bas. Beaucoup plus complexe, on peut décrire un circuit électronique qui fait de l'encodage MPEG4.
Tu seras peut-être alors tenté de comparer un FPGA à microcontroleur (comme un Atmega, Arduino) ou a un SoC (comme le Rapsberry Pi). Après tout, je peux faire un radio-réveil, un filtre passe bas, ou encodeur MPEG4 avec un Rapsberry Pi (ou un Arduino). La différence est que dans le Rapsberry Pi ou l'Arduino, tu charges un programme qui executé. Tu ne modifies par le cablage interne (= les liens entre les portes logiques) du Rapsberry Pi.
Pour revenir un peu vers ton idée, tu voudrais faire un FPGA qui peut "exécuter" 40 instances de gcc en parallèle. gcc est un programme en C, que tu voudrais "compiler" pour le mettre dans le FPGA (en 40 exemplaires j'imagine). Or pour l'instant on ne sait pas transformer un programme C en cablage de FPGA (je suis même pas certain que ce soit théoriquement faisable). D'ailleurs si tu commences à comprendre ce qu'est un FPGA, tu dois commencer à te rendre compte de ce que ça représente, transformer un logiciel en C en une série d'instructions de cablage.
Ce qu'on commence à faire au niveau de la recherche académique (à vérifier, je suis pas vraiment au courant des dernière avancées), c'est transformer des kernels OpenCL en cablage de FPGA. Mais pour l'instant implémenter gcc dans un FPGA ça semble pas faisable.
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Si tu as un FPGA + une DRAM, si forcément. Il suffit d'avoir un modèle de cpu qui est mis dans le FPGA et le compilo cible l'assembleur du cpu.
Ensuite, tu peux imaginer l'élimination des opérateurs inutiles, ou la création de la combinaison d'opérateur. Tu peux avoir un modèle de cpu très complexe que tu simplifies pour ton code assembleur.
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par X345 . Évalué à 4.
Je me suis peut-être mal exprimé. Je voulais dire transformer un programme C en bitstream FPGA. Je suis pas sur que la sémantique du C soit transformable en matériel.
Implémenter un CPU dans un FPGA, ça n'a quasiment aucun intérêt (mais je suis suppose que je t'apprends rien, à avoir lu tes précédents commentaires). Premièrement parce que faire une architecture aussi efficace qu'Intel c'est pas gagné. Ensuite parce que la fréquence sera très basse (de l'ordre de quelques centaines de Mhz au lieu de plusieurs Ghz sur un ASIC).
Après oui, on pourrait se diriger vers une carte avec un CPU et un FPGA et "offloader" une partie des calculs liés à la compilation sur le FPGA (ou a défaut mettre le CPU et l'accélérateur sur le même FPGA si on a une carte avec juste un CPU). J'imagine que tu parlais de ça quand tu parlais de combinaison d'opérateur. Ça nécessiterait d'aller sacrément modifier le code source de GCC au passage. Je pense que ça n'apportera aucun gain par rapport à un CPU Intel classique (voir même que ce sera beaucoup plus lent). J'ai pas l'impression qu'il y ai beaucoup d'opérations de compilation "facilement" implémentable sur un FPGA, contrairement à du décodage vidéo.
[^] # Re: Probablement une mauvaise idée...
Posté par ntimeu (site web personnel) . Évalué à 2. Dernière modification le 09 juillet 2015 à 10:35.
Aucun intérêt, oui, mais ça reste tout de même assez intéressant dans une optique d'apprentissage. Et le fait d'avoir une chaîne de développement libre fait qu'il est plus simple de développer sur les FPGA pour un amateur (comme moi).
Concernant l'intérêt du compilateur déporté sur une carte accélératrice, personnellement je ne vois pas vraiment l'utilité : peu de projets nécessitent autant de compilation (à l'exception évidemment des dépôts de logiciels, comme ceux des *BSD ou de GNU/Linux).
A la rigueur un compilateur adapté à des cartes comme celle d'Adapteva serait plus utile, car ce sont des coeurs ARM (et donc le "CPU" est déjà conçu). Si on voulait faire du FPGA (comme le présente l'auteur de l'article), il faudrait :
EDIT: la seconde solution me paraît réalisable, mais pas la première (pour l'instant).
Comme sujet de recherche/découverte/essai, ça serait génial d'essayer la conception d'un tel projet, par contre pour une utilisation plus "industrielle"/utile, …
AMHA, l'important dans un compilateur c'est principalement la qualité du code généré, beaucoup plus que la vitesse de génération de code. Par contre, un FPGA pour accélérer les calculs au sein d'une application (compression, chiffrement, encodage, …), ça a du sens.
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'imagines que tu pars avec une solution simple genre gros FPGA relier à une grosse mémoire, dans un slot pci express.
Tu veux que cette carte accélère gcc, histoire de prendre un exemple précis. Tu dis que synthétiser un cpu dans un fpga n'est pas performant dans l'absolu. C'est une évidence. Mais cela revient pourtant très exactement à la synthèse direct vers un bitstream. Un core, c'est en général une grosse machine d'état avec quelques opérateur. Un cpu c'est exactement ça, seulement la machine d'état est encodé dans une mémoire sous forme d'assembleur.
Donc, tu as une dualité core/cpu. Compiler directement du C est complexe (certain le font déjà cf synfora pico c), le principal problème est la faible sémantique de la mémoire qui oblige à avoir une grosse mémoire adressable (type DRAM) ce qui ne rentre pas dans un FPGA seul.
Une fois que tu as un cpu, tu peux l'optimiser à mort comme tu le veux en fonction de la tâche à faire. C'est cette optimisation qui pourra te faire gagner du temps (VLIW, multicore,…) par rapport à l'execution sur x86.
L'optimiseur de cpu dispose du code C à compiler, il peut choisir les meilleurs options.
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par X345 . Évalué à 2.
Oui, enfin pas forcément dans un slot PCI-Express (mais peu importe)
Un programme informatique n'est pas forcément une machine d'état. C'est plutôt assimilable à une machine de Turing (qui permet de faire beaucoup plus de chose qu'une machine d'état). En particulier, GCC n'est pas exprimable sous forme d'une machine d'état puisqu'il sait parser autre chose que des languages réguliers (Chomsky Hierarchy).
Tout dépend de ce qu'on appelle un CPU. Un "CPU optimisé à mort", ça devient plus un CPU ça devient un circuit dédié à une tache spécifique. Un GPU n'est pas un CPU. Un encodeur MPEG4 n'est pas un CPU non plus. Même si l'encodeur MPEG4, le CPU et le GPU partagent le fait qu'ils vont transiter entre différents états, qu'ils vont éventuellement exécuter des instructions, qu'ils vont tous probablement avoir une horloge etc. Un CPU c'est Turing complet, un circuit dédié pas forcément.
Ici on voudrait transformer GCC (le code source de GCC) en un circuit dédié à la compilation. On voit bien que (i) CPU + assembleur de GCC et (ii) circuit à une instruction qui fait de la compilation, ça forme les deux extrémités d'un continuum.
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2. Dernière modification le 09 juillet 2015 à 14:03.
Je ne sais pas trop ou tu veux en venir. J'ai l'impression que tu es calé en logique/math, mais pas franchement en design hardware. La différence que tu fais sur la machine de Turing/machine d'état est artificiel.
Évidamment la machine d'état n'est pas seul, il faut rajouter des comparateurs et des opérateurs. C'est aussi de cette façon qu'est conçu un cpu. Puisqu'un cpu est un core.
Oui, si le code assembleur est gravé dans le marbre. Pas forcément, si la mémoire est modifiable. La structure d'un cpu est assez simple : registre, mémoire, operateurs, et instruction.
De plus, en plus.
Un encodeur MPEG4 est souvent composé de plusieurs DSP qui sont des cpus.
Oui mais ton circuit dédié peut être composé de cpu.
Oui, et c'est parfaitement possible, mais ce n'est pas garanti d'être rapide.
Ou veux-tu en venir ?
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par X345 . Évalué à 2.
Effectivement, je suis de formation informatique (et pas électronique/hardware). Je pense que c'est l'inverse pour toi, ce qui doit expliquer une partie de l'incompréhension. Après je suis une vraie catastrophe en maths (ahem…).
Ça non, je suis sur de mon coup. On est sur (= c'est démontré) qu'un automate d'états fini n'est pas Turing complet. Par conséquent, on ne peut pas exprimer tous les programmes informatiques comme un automate d'états fini. Par contre, c'est pas forcément hyper lié au sujet de base (mais c'est toi qui disait ça, hein).
Oui pour la vision globale. Mais ça c'est un CPU des années 80. Aujourd'hui c'est quand même plus complexe. Les instructions sont micro-codées, elles ne sont pas exécutées dans l'ordre, y'a un pipeline qui fait qu'en fait on les exécute par bouts, on a des architectures super-scalaires, de la prédiction de branchement etc. C'est pour ça que c'est une mauvaise idée de faire un CPU soi-même et de le mettre dans un FPGA. Sans compter les histoires de fréquence etc. (Je sais que tu sais sûrement déjà ça, mais je voulais pas qu'on donne la vision fausse qu'un CPU performant, c'est simple).
Je crois qu'on s'entend pas sur les définition de CPU. Et de "core" d'ailleurs. Je vois pas quelle définition tu leur donne.
Il me semble qu'un CPU, c'est un circuit générique, qui n'est pas optimisé pour exécuter un type de logiciel particulier. Un circuit dédié est optimisé pour exécuter un type de logiciel particulier. Surtout un CPU a un jeu d'instructions Turing complet. Un circuit dédié peut avoir un jeu d'instructions qui n'est pas Turing complet. Par exemple on peut imaginer un circuit dédié qui n'a pas d'instruction de branchement (jump).
Tu prends peut-être une définition très large de CPU au sens de "circuit qui accéde de la mémoire et exécute des instructions depuis cette mémoire". Note que même comme ça un encodeur MPEG4 impémenté dans un FPGA, c'est pas un CPU.
Soit on implémente toutes les opérations de GCC en logiciel (cas i) avec des instructions assembleur dans la mémoire qui sont exécutées par le CPU flashé dans le FPGA. Soit on implémente tout en matériel dans la configuration du FPGA (cas ii). Entre le deux on peut implémenter des "macro-opérations" en matériel (décomposition SSA par exemple, une partie du parcours de l'AST etc. ou la tokenisation) et d'autres en logiciel. Et on peut implémenter plus ou moins d'opérations en matériel.
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui mais personne n'utilise une FSM toute seul, c'est pour ça que j'ai préciser + opérateur et comparateur.
Tu mélanges la définition d'un cpu (== vue de l'extérieur) et son architecture.
Oui, c'est compliqué et surement lent, mais cela ne veut pas dire que ça l'est à coup sûr.
Un core est un bloc hardware. Un cpu, c'est une boite noire dans lequel plusieurs bus rentre et sorte, et qui est capable d’exécuter des instruction. On peut imaginer que ces instructions soient dans une ROM.
Non!! Tu racontes n'importe quoi. L'encodeur MP4 embarqué dans l'omap4 de TI, c'est 2 ARM M0 ou 4, qui pilote 2 DSP.
J'ai du oublier de dire, que c'est absolument n'importe quoi de croire que faire des va et vient avec le x86 pouvait avoir un intérêt. Je considère que tout est fait dans la carte d'extension, cela sera toujours trop lent sinon.
Je considère gcc uniquement comme un code C. Donc, le génerateur de bitstream peut déduire facilement les ensembles d'instructions les plus utiles et les fusionner ou dupliqué pour créer un CPU de fpga ultra rapide pour gcc. Il n'a pas connaissance de l'AST ou autre. Si c'est le cas, c'est que tu fais un design "custom" à la main, ce qui est un boulot délirant.
"La première sécurité est la liberté"
[^] # Re: Probablement une mauvaise idée...
Posté par X345 . Évalué à 2.
Je suis pas sur que ça suffise pour faire un truc Turing complet. Doit manquer une instruction pour faire des sauts. Cela dit, ça n'enlève rien à la distinction automate d'état fini/machine de Turing.
C'est vraiment une définition ultra large de CPU. Donc, ça explique une partie de l'incompréhension on avait pas la même. Donc je peux faire un "CPU" qui sait juste calculer "f(x) = 4*x" et "g(x) = 5*x" avec un jeu d'instructions qui comporte deux instructions "f" "g". A l'extreme, selon ta définition, une ALU c'est un CPU.
Tu mélanges tout sur ce coup. J'ai pas dit qu'on pouvait pas faire un encodeur MPEG4 avec un DSP ou un CPU.
Je dis qu'on peut faire un circuit spécifique qui fait du décodage MPEG4 qui n'est pas un CPU.
Très précisément, ça http://opencores.org/project,nova c'est pas un CPU. C'est un circuit dédié au décodage MPEG4.
C'est une évidence. Si on fait un CPU avec une architecture moins bonne et une fréquence divisée par 10… Les performances des CPUs implémentés dans les FPGA sont très très faibles. C'est d'ailleurs pour ça que des fabriquants mettent des cœurs ARM et un FPGA sur la même puce.
Oui, oui… Il faut tout faire sur le FPGA (on se comprend vraiment pas). Juste que le CPU implémenté sur le FPGA peut avoir des instructions qui font plus ou moins de choses. Soit on a que des instructions génériques (les cmp, add, sub, jmp, jne classiques des jeux d'instructions) (mon cas (i). Soit on fait un CPU a une seule instructions (compile) qui fait tout (mon cas (ii)). Entre les deux, on peut comme tu dis "détecter les ensembles d'instructions" utiles, les fusionner pour en faire une instruction unique qu'on ajoute à l'instruction set de notre CPU. C'est évidemment l'approche raisonnable.
Tu peux détailler ça ? Comment je passe de (Code source de gcc) -> (bitstream) ?
Est-ce que c'est :
1. J'ai un design de CPU générique flashable dans un FPGA. Je compile gcc pour ce CPU générique. J'obtiens le code assembleur de gcc.
2. Je détecte les ensembles d'instructions redondants dans l'assembleur générique généré par gcc. (Si ça existe, on utilise quoi comme genre de logiciels ?). On les instructions dans chacun des ensembles d'instructions pour créer des macro-instructions.
3. On ajoute ces macro-instructions au design de CPU générique qui devient un CPU "optimisé".
4. On modifie le code assembleur de gcc pour qu'il utilise les macro-instructions.
5. On flashe le CPU optimisé sur le FPGA. Et on exécute la version (4) de gcc sur le CPU optimisé.
Si on sait faire ça, c'est super impressionant ! Je serais intéressé si tu as des noms de logiciels / des tutoriels ou des papiers.
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Non, car il n'y a pas de gestion des instructions, par exemple.
Si tu compiles un code C, ayant
int f(int x) {return 4*x;}; int g(int x){ return 5*x;}
Cela aurait un sens que cela soit le résultat après simplification. Cela ne serait plus un cpu, c'est vrai. Sauf que ce n'est pas un code C qui fait quelques choses, typiquement, il n'y a aucune IO.
On peut toujours tout faire en hard, c'est moi qui avait pris un exemple. En plus, le tien est un décodeur, qui est infiniment plus simple qu'un codeur.
Non justement. Si tu pars sur un array de cpu vliw comme pattern de base, et tu compiles des blocs pour miner du bitcoin, ton code peut devenir une centaine de core avec des instructions sha cablé, qui seront bien plus rapide qu'un x86.
Oui si tu pars de cpu monocore simple, mais commence avec du multicore multithreadé en vliw, ce n'est pas automatique du tout.
Je ne pense pas que l'on a déjà fait. C'était ma proposition à la question du forum :)
On peut imaginer faire une machine virtuelle pour GCC, et générer le ou les cpu a partir d'un template de cpu et de ce code objet. C'est l'idée.
"La première sécurité est la liberté"
# Ressources contraintes
Posté par khivapia . Évalué à 6.
Sur un FPGA (comme en électronique sur un ASIC), quand tu le "programmes", en fait tu programmes les X millions d'unités qui calculent des fonctions booléennes de 4 ou 5 bits vers 1 bit.
Contrairement au logiciel, il n'y a pas (ou très peu) de mémoire, et jamais en quantité "virtuellement illimitée" mais toujours en quantité exacte à définir dès le début. Un peut comme si toutes les dimensions étaient hardcodées à la compilation en soft. Par exemple, dans un CPU, tout est hardcodé : la taille des instructions, leur séquencement en micro-instructions, le nombre des registres, leur taille, etc.
Autant dire qu'il est très certainement impossible de faire exactement ce que tu décris dans un FPGA. Par contre, il peut tout à fait servir à accélérer comme un coprocesseur des calculs qui seraient coûteux en soft, parallélisables ou pipelinables, et qui ne nécessitent pas trop de données. Pour la compilation, je ne sais pas, par contre ça peut s'envisager pour la sécurité (calculs crypto pas toujours hyper efficaces en soft, c'est pour ça qu'Intel a proposé les instructions AES et que VIA et AMD (Geode) avaient des coprocesseurs crypto), pour des calculs d'encodage ou de décodage vidéo, etc.
# MiST fpga
Posté par zurvan . Évalué à 4.
je n'y connais pas grand chose en fpga, mais j'ai un MiST, et c'est très chouette, ça recréé beaucoup de machines anciennes, des ordinateurs 8 et 16 bits (amstrad, atari, amiga) aux consoles de jeux (pacman, pong, pc engine, sega), du coup ça peut être un projet d'étude intéressant. Il existe d'ailleurs des machines qui n'ont pas encore été portée mais qui existent dans d'autres projets fpga, si ça t'intéresse.
http://code.google.com/p/mist-board/wiki/CoreStatus
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: MiST fpga
Posté par zurvan . Évalué à 2.
J'ai regardé un peu plus le projet, et il y a des bonnes choses pour les développeurs : déjà le wiki est assez fourni, et donne beaucoup de conseils. Ensuite, le développeur principal n'utilise que Linux donc on est sûr de ne pas tomber sur un moment dans la chaîne de compilation où il faudra passer par un logiciel qui ne fonctionne pas bien avec wine (même si certains logiciels ne sont pas libres).
La liste des projets qui tournent ou peuvent potentiellement tourner dessus :
http://code.google.com/p/mist-board/wiki/ListOfFPGAProjects
d'autres infos sur le développement :
http://code.google.com/p/mist-board/wiki/HowToDevelopForTheMist
La carte coûte 200 €
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# FPGA c'est Quoi
Posté par Miracle . Évalué à -2.
Les FPGA (Field Programmable Gate Arrays ou "réseaux logiques programmables") sont des composants VLSI entièrement reconfigurables ce qui permet de les reprogrammer à volonté afin d'accélérer notablement certaines phases de calculs.
L'avantage de ce genre de circuit est sa grande souplesse qui permet de les réutiliser à volonté dans des algorithmes différents en un temps très court.
Le progrès de ces technologies permet de faire des composants toujours plus rapides et à plus haute intégration, ce qui permet de programmer des applications importantes.Les circuits FPGA sont constitués d'une matrice de blocs logiques programmables entourés de blocs d'entrée sortie programmable. L'ensemble est relié par un réseau d'interconnexions programmable.
Les FPGA sont bien distincts des autres familles de circuits programmables tout en offrant le plus haut niveau d'intégration logique.
Il y a 4 principales catégories disponible commercialement:
Tableau symétrique.
En colonne.
Mers de portes.
Les PLD hiérarchique.
[^] # Re: FPGA c'est Quoi
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Recopie d'un contenu pris sur le net sans mention de l'auteur et sans hyperlien, le tout posé dans un commentaire sans vraiment de rapport avec le reste (pourquoi expliciter les FPGA ici et maintenant, et sans détailler suffisamment pour que cela présente un intérêt pédagogique), par un compte nouvellement créé et avec une adresse de courriel ressemblant à s'y méprendre à celles habituellement utilisées pour le spam. Alors je vais fermer ton compte. N'hésite pas à me contacter si je fais erreur.
# let's have fun
Posté par steph1978 . Évalué à 3.
Comme très bien décrit plus haut, un FPGA te permet d'implémenter une architecture de composant physique : processeur, mémoire, I/O.
Sur le web, on trouve des tutoriels pour implémenter des processeurs open-source par exemple. Ce qui veut dire que le FPGA va alors traiter des instructions spécifiques à l'architecture câblée ; à comparer à x86 ou ARM déjà implémenter par des ASICS.
Un autre exercice consisterait à implémenter une architecture de codeur/décodeur média, compression ou cryptographique.
Autre exemple, implémenter un ensemble carte ethernet , pile TCP IP et CPU pour une application réseau. Qui contrôlerait une machine par exemple.
En somme un FPGA traite un flux de données et y applique la logique câblée, les instructions processeurs étant un cas particulier.
Dans ton cas, j'imagine que tu veux envoyer un flux de source C et produire un code binaire en retour.
Le problème est qu'un compilateur est infiniment plus compliqué qu'un encodeur. Il a besoin de beaucoup plus de contexte pour opérer.
Pour conclure, je ne pense pas que ce soit l'exercice que tu recherche pour commencer à te faire plaisir avec un FPGA.
# Flow OpenCL dispo pour les FPGAs
Posté par maga . Évalué à 1.
Bonjour à tous,
Un flow de compilation OpenCL pour FPGA existe déjà depuis 2 ans chez ALTERA.
Il y a même une formation gratuite dans leurs locaux le 1 octobre pour découvrir la solution.
Cdlt
Marc
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.