Sauf que ton cas est complétement fictif, le but est de montrer l'effort d'un pays par rapport à sa richesse, cela permet de comparer les pays entre eux.
Mais attention sur les résultats, un même % de pib peut donner des moyens trés différent entre pays (France vs Suisse par exemple).
La démographie joue aussi un rôle, la France a beaucoup de jeunes par rapport aux autres.
Cela un sens d'avoir un AST de haut niveau pour faire des optims de haut niveau et ensuite de générer le C++ ?
J'avais regardé un jour l'AST de llvm, c'est très très bas niveau. Le truc marrant, c'est qu'ensuite un tel AST serait une cible de choix pour tout nouveau langage qui bénéficierait ainsi de tes optims + celle de C++.
Un autre point concernant l'AST, en général, il y a plus d'une centaine d'éléments différent. L'optimisation consiste à reconnaître des patterns (visiteur ?) puis remplacer le bout d'arbre par un autre, et même de le "faire en boucle" (Lisaac tournait jusqu'à obtenir un point bas).
Lisaac, avec son AST à ~15 classes, avait montré un truc hyper sympa : bien plus d'optimisations devenaient possibles. Vu qu'il n'y a qu'un seul moyen de faire une boucle, toutes les optimisations de boucle s'appliquaient tout le temps.
Je me demandais donc si c'était pensable de passer d'un AST pléthorique, à un truc plus simple pour rendre les optimisations plus simples à écrire.
Je pense avoir vu une présentation de Lisaac aux journées de la compilation françaises, à Aussois. Probablement donnée par toi ?
Non, c'est sans doute Benoit Sonntag.
Les fondements théoriques de Pythran sont assez flous et mouvants, mais il reste des choses amusantes à faire, soit au niveau du typage si c'est un truc qui te branche, ou également (mais c'est un gros chantier) sur l'ownership.
L'ownership, c'est le suivi du cycle de vie de la mémoire ?
Plus humblement, certaines fonctions de pythonic gagneraient à avoir une version vectorielle, ça peut être un bon sujet pour commencer !
Il s'agit de fonction de base à rendre vectorielle en C++ ?
Disons que l'optimisation, c'est mon dada (je suis trop vieux…). Après les archis de cpu avec le f-cpu, le langage ultrarapide, lisaac qui est mort-né, ton projet est tout de même pas mal intéressant :) Lisaac partait du principe que plus le langage est de haut niveau et chargé de sémantique et plus l'optimisation est facile.
Et le AoS ou SoA, non ?
Oui, mais c'est compliqué, car la bonne réponse peut changer en fonction des caches, des tailles de champs, des patterns d'accès, etc. Le trie de structure, cela marche toujours car cela réduit le padding, donc l'empreinte mémoire, donc l'usage du cache, etc….
Tu as un peu de temps de dev libre ? Tes remarques sont souvent ultra pertinentes ;-)
Est-ce que pour des raisons de performance tu peux modifier le layout mémoire utilisé en C++ ?
C'est souvent une des raisons que l'utilisation automatique de SIMD ne marche pas, c'est que le layout choisi par l'utilisateur n'est "pas gentil". Vu que tout est généré, est-ce que tu y touches ou est-ce que tu peux y toucher ? (l'optimisation de base étant de trier de façon décroissante les champs d'une structure)
Je ne sais pas si les mots suivants ont du sens pour toi, mais il faudrait que j'arrive à mettre en place un flot hiérarchique où je fais d'abord l'implémentation de la tuile logique puis que je l'utilise sous forme de hard macro dans le cœur.
Cela serait trop lourd de tout garder ensemble ? Concernant le routage tu semble faire du proche en proche, dans des FPGA type atmel, il avait des lignes qui faisaient toutes la hauteur du chip, l'idée est de perdre moins de temps sur un fils avec un gros fanout. Gérer du routage hiérarchique est aussi pour plus tard ?
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.
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)
Je suis donc persuadé que si le sujet n'avance pas, c'est que nos dirigeants n'ont pas envie que cela change
C'est facile, on veut pouvoir que nos sociétés exportatrices payent des impôts en France et non dans les pays de vente. Le problème n'est pas les GAFA mais la manière de fonctionner des sociétés exportatrices. Je fais du business dans un pays, mais je produit dans un autre. Sauf qu’aujourd’hui, elles peuvent choisir où enregistrer leur profit !
Il y a des projets de "lissage" pour répartir les gain, mais aussi les couts de production. Il faut une consolidation mondiale et une règle de répartition des bénéfices. L'OCDE travaille dessus, l'ACIS, et l'ACCIS était un projet européen mais repoussé par la France et l'Allemagne qui y trouve donc leur compte. Des petits pays comme les Pays Bas perdront 30% de leur IS, car l'activité ne se trouve pas dans ce pays.
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…).
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.
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.
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)
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.
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).
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.
[^] # Re: Pas de sous, pas de résultats
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Dégradation de la France. Évalué à 4.
Sauf que ton cas est complétement fictif, le but est de montrer l'effort d'un pays par rapport à sa richesse, cela permet de comparer les pays entre eux.
Mais attention sur les résultats, un même % de pib peut donner des moyens trés différent entre pays (France vs Suisse par exemple).
La démographie joue aussi un rôle, la France a beaucoup de jeunes par rapport aux autres.
"La première sécurité est la liberté"
[^] # Re: Question bête ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelques surprises techniques dans Pythran. Évalué à 3.
Cela un sens d'avoir un AST de haut niveau pour faire des optims de haut niveau et ensuite de générer le C++ ?
J'avais regardé un jour l'AST de llvm, c'est très très bas niveau. Le truc marrant, c'est qu'ensuite un tel AST serait une cible de choix pour tout nouveau langage qui bénéficierait ainsi de tes optims + celle de C++.
"La première sécurité est la liberté"
[^] # Re: Question bête ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelques surprises techniques dans Pythran. Évalué à 3.
Lisaac avait fait plus simple : un mot clef, Expanded. Ainsi, Ben a pu faire un OS où les pixels de l'écran sont des objets.
"La première sécurité est la liberté"
[^] # Re: Question bête ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelques surprises techniques dans Pythran. Évalué à 3.
Un autre point concernant l'AST, en général, il y a plus d'une centaine d'éléments différent. L'optimisation consiste à reconnaître des patterns (visiteur ?) puis remplacer le bout d'arbre par un autre, et même de le "faire en boucle" (Lisaac tournait jusqu'à obtenir un point bas).
Lisaac, avec son AST à ~15 classes, avait montré un truc hyper sympa : bien plus d'optimisations devenaient possibles. Vu qu'il n'y a qu'un seul moyen de faire une boucle, toutes les optimisations de boucle s'appliquaient tout le temps.
Je me demandais donc si c'était pensable de passer d'un AST pléthorique, à un truc plus simple pour rendre les optimisations plus simples à écrire.
"La première sécurité est la liberté"
[^] # Re: Question bête ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelques surprises techniques dans Pythran. Évalué à 3.
Non, c'est sans doute Benoit Sonntag.
L'ownership, c'est le suivi du cycle de vie de la mémoire ?
Il s'agit de fonction de base à rendre vectorielle en C++ ?
"La première sécurité est la liberté"
[^] # Re: Question bête ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelques surprises techniques dans Pythran. Évalué à 3.
Disons que l'optimisation, c'est mon dada (je suis trop vieux…). Après les archis de cpu avec le f-cpu, le langage ultrarapide, lisaac qui est mort-né, ton projet est tout de même pas mal intéressant :) Lisaac partait du principe que plus le langage est de haut niveau et chargé de sémantique et plus l'optimisation est facile.
Oui, mais c'est compliqué, car la bonne réponse peut changer en fonction des caches, des tailles de champs, des patterns d'accès, etc. Le trie de structure, cela marche toujours car cela réduit le padding, donc l'empreinte mémoire, donc l'usage du cache, etc….
Pourquoi pas.
"La première sécurité est la liberté"
# Question bête ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelques surprises techniques dans Pythran. Évalué à 3.
Est-ce que pour des raisons de performance tu peux modifier le layout mémoire utilisé en C++ ?
C'est souvent une des raisons que l'utilisation automatique de SIMD ne marche pas, c'est que le layout choisi par l'utilisateur n'est "pas gentil". Vu que tout est généré, est-ce que tu y touches ou est-ce que tu peux y toucher ? (l'optimisation de base étant de trier de façon décroissante les champs d'une structure)
"La première sécurité est la liberté"
[^] # Re: projet qui déchire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 2.
Non, c'est lié à la loyauté/confidentialité, on a pas le droit de sortir des informations secrètes d'une entreprise.
"La première sécurité est la liberté"
[^] # Re: Qflow
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche k1g1 : le premier FPGA Libre…. Évalué à 2.
Cela serait trop lourd de tout garder ensemble ? Concernant le routage tu semble faire du proche en proche, dans des FPGA type atmel, il avait des lignes qui faisaient toutes la hauteur du chip, l'idée est de perdre moins de temps sur un fils avec un gros fanout. Gérer du routage hiérarchique est aussi pour plus tard ?
"La première sécurité est la liberté"
[^] # Re: chip de test
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 3.
Pas besoin de modifier le compilateur, il faut juste insérer le code d'instruction assembleur dans une librairy.
Tu gardes tout justement. C'est l’intérêt principal.
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é"
[^] # Re: chip de test
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. É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 Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. É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: Pourquoi en faire une dépêche ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche k1g1 : le premier FPGA Libre…. Évalué à 10.
Profites de ton succès, et ne mets pas en marche le syndrome de l'imposteur !
"La première sécurité est la liberté"
[^] # Re: chip de test
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 3.
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: Si on arrêtait le mensonge et la diffamation ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Meta‑Press.es : un méta‑moteur de recherche pour la presse dans votre navigateur. Évalué à 4.
C'est facile, on veut pouvoir que nos sociétés exportatrices payent des impôts en France et non dans les pays de vente. Le problème n'est pas les GAFA mais la manière de fonctionner des sociétés exportatrices. Je fais du business dans un pays, mais je produit dans un autre. Sauf qu’aujourd’hui, elles peuvent choisir où enregistrer leur profit !
Il y a des projets de "lissage" pour répartir les gain, mais aussi les couts de production. Il faut une consolidation mondiale et une règle de répartition des bénéfices. L'OCDE travaille dessus, l'ACIS, et l'ACCIS était un projet européen mais repoussé par la France et l'Allemagne qui y trouve donc leur compte. Des petits pays comme les Pays Bas perdront 30% de leur IS, car l'activité ne se trouve pas dans ce pays.
"La première sécurité est la liberté"
[^] # Re: chip de test
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. É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 Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. É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 Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 4.
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.
Pas dans leurs accélérateurs hardware. (ex: https://coral.withgoogle.com/products/accelerator/ )
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 Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 4.
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 Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 4.
non, les coeurs sont séparés.
"La première sécurité est la liberté"
[^] # Re: chip de test
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 4.
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: projet qui déchire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 3.
Menta est une boite française à ce que je vois. Elle marche bien ?
"La première sécurité est la liberté"
[^] # Re: projet qui déchire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 8.
Des associés, cela se trouve. Partir à 2, même 2 techniques est toujours mieux que d'être seul.
"La première sécurité est la liberté"
[^] # Re: chip de test
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. É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é"
# chip de test
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre…. É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é"