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 Jimmy . En réponse au journal Compiler pour un FPGA. Évalué à 5.
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.
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% ...