Du C au Silicon: Comment implémenter une solution logicielle / firmware en tant que matériel?


13

À la lumière de cette question, je me demandais s'il existait un processus assez standard pour transformer une solution logicielle en implémentation matérielle. Pardonnez-moi et mon imagination, mais y aurait-il un compilateur qui pourrait prendre un programme C et le compiler en termes de schémas de transistors, résistances, etc. ou peut-être même des PCB bien connus?

Je me rends compte que je pourrais envisager ce scénario sous un mauvais angle. Historiquement, d'après ma propre expérience, vous avez généralement un morceau de matériel que quelqu'un a implémenté comme solution logicielle (pensez à l'émulation matérielle). Ce concept à l'envers existe-t-il même? Comment ces grandes entreprises le font-elles, comme le routage IP logiciel vs matériel?


Voir aussi "pourquoi ne puis-je pas rendre automatiquement mon programme C à tête unique multithread?"
pjc50

@ pjc50: Où puis-je voir "pourquoi ne puis-je pas automatiquement rendre mon programme C à tête unique multithread?" ?
davidcary

Je n'ai pas d'exemple précis en tête, mais c'est une question que j'ai déjà vu des gens poser. Il est également lié au fait que le matériel est intrinsèquement parallèle tandis que le logiciel est "naturellement" séquentiel en termes de la façon dont les gens y pensent et écrivent des programmes.
pjc50

Réponses:


11

Non, il n'y a pas de solution standard pour transformer un logiciel en matériel. D'une manière générale, prendre un logiciel qui n'a pas été écrit avec une implémentation matérielle à l'esprit ne peut pas être facilement converti en matériel sans gaspillage énorme et inefficacités. Habituellement, la meilleure chose à faire est de créer une puce dotée d'un processeur et d'une ROM et de mettre le logiciel dans la ROM.

Au fil des ans, il y a eu des compilateurs qui prenaient le code "C-Like" et le compilaient en matériel - de la même manière que VHDL ou Verilog peuvent être compilés en matériel. Mais l'essentiel est qu'il est "C-Like", et non C. Vous ne pouvez toujours pas prendre, par exemple, un programme C / C ++ qui calcule PI et le convertit comme par magie en matériel qui calcule PI. La plupart de ces langages C-Line ont disparu ou ne sont pas utilisés en nombre. SystemC est l'une des versions les plus populaires de celui-ci , mais il est important de noter qu'il ne s'agit pas de C / C ++ et qu'il n'est pas utile pour les génériques "écrivons un logiciel puis compilons-le en matériel". Vous devez encore "écrire du matériel, qui pourrait également être compilé dans le logiciel".

Les commutateurs et les routeurs ont généralement du matériel comme la plupart des fonctions de routeur critiques couramment utilisées et de vitesse (recherche de trucs dans les tables de routage, gestion des files d'attente, etc.) dans le matériel, puis utilisent un processeur pour effectuer toutes les fonctions moins courantes (gestion des exceptions, erreurs, mises à jour des tables de routage, etc.). À bien des égards, cela est similaire au fonctionnement du processeur moderne, où les opcodes les plus courants sont effectués dans le matériel et parfois certains opcodes sont en fait implémentés dans le logiciel (par exemple, les instructions à virgule flottante quand un FPU n'est pas présent).


Non seulement SystemC est un véritable C ++, mais c'est juste une bibliothèque C ++. Vous pouvez utiliser n'importe quel code C ++ ordinaire que vous aimez avec SystemC. Cela dit, SystemC n'a pas grand-chose à voir avec la génération automatique de matériel. Il est davantage orienté vers la simulation de systèmes, aidant à prendre des décisions architecturales et permettant aux équipes logicielles de démarrer avant que le matériel ne soit disponible.
Theran

Cela m'aide vraiment à comprendre pourquoi il existe un matériel spécifique qui effectue des tâches spécifiques.
Chad Harrison

Il existe de nombreux autres compilateurs C vers HDL qui ont été conçus à cet effet.
Anderson Green

5

Le plus proche serait le compilateur C-to-Hardware (C2H) d' Altera . Il peut faire ce que vous proposez. Mais il y a des mises en garde avec défi. Vous ne pouvez pas transformer n'importe quel code C en matériel, et vous ne le voudriez pas non plus. Mais les fonctions spécifiques fonctionnent plutôt bien et vous pouvez voir une augmentation spectaculaire des performances.

Généralement, vous implémentez un processeur softcore NIOS II dans un FPGA Altera. Vous écririez alors du code ANSI C comme vous le feriez pour n'importe quel autre processeur. Supposons ensuite que l'une des fonctions C que vous avez écrites implique des calculs lourds qui bénéficieraient aux performances d'une exécution parallèle. Vous invoquez le compilateur C2H, dites «Implémenter dans le matériel» et il transforme essentiellement cette fonction en périphérique du processeur softcore NIOS II.

Voici un exemple de codage d'un calcul Mandelbrot en ANSI C puis de l'implémenter dans le matériel:

L'algorithme Mandelbrot accéléré par le compilateur C2H entraîne une amélioration de la vitesse d'au moins 60x par rapport au même algorithme exécuté sur le processeur Nios II le plus rapide utilisant le niveau d'optimisation du compilateur 2 (-O2). Cette augmentation de vitesse est due au parallélisme et aux vitesses d'itération rapides que le matériel peut fournir, qui ne sont pas possibles à partir d'une unité de traitement à usage général.

Pour revenir à votre exemple, le processeur NIOS II peut exécuter Linux. Et certaines fonctions qui seraient nécessaires pour effectuer des tâches de routage pourraient bénéficier de l'accélération matérielle. Il fonctionnerait probablement mieux qu'un routeur logiciel pur. Mais il n'abordera jamais les performances des ASIC dédiés spécialement conçus.


1
Xilinx dispose d'un outil comparable appelé Vivado HLS (synthèse de haut niveau), anciennement AutoESL. Des mises en garde similaires s'appliquent: il fait un bon travail de conversion de code en RTL si c'est le type de code qui est facile à convertir automatiquement en RTL.
Theran

@Theran Je ne savais pas que Xilinx avait un produit concurrent. Je vais devoir vérifier cela. Merci!
embedded.kyle

2

Vous mentionnez «C to Silicon» dans votre titre et mentionnez les produits de niveau planche dans le corps. Je vais me concentrer uniquement sur la partie de cette équation qui existe -> Flux de conception "C vers silicium". C en soi n'est pas un ajustement naturel pour la description du matériel car il manque un support fondamental pour le parallélisme inhérent du matériel, la nécessité d'éviter les conditions de concurrence et d'autres problèmes, et il n'est pas particulièrement expressif de pouvoir représenter ces concepts. Ou pas autant que Verilog et VHDL.

Le code C qui est synthétisable (c'est-à-dire qui peut être rendu dans une description matérielle) et ici hardware = logique numérique, ne gagnerait aucun concours de codage jugé par les développeurs de logiciels.

Voici une liste de certains fournisseurs notables qui fournissent des outils C -> Silicon pour la foule de flux ASIC.

  • Forte Cynthesizer

  • Mentor Catapult

  • BlueSpec C

  • Synopsys Synphony (ex- Synfora)

  • Cadence C-à-silicium


1

Transformer un logiciel en matériel n'est pas une tâche complètement banale si vous vous attendez à un matériel raisonnable. Le matériel a tendance à nécessiter plus d'architecture pour gérer soigneusement l'utilisation des ressources qui se rapporte à la surface / au coût. Cela dit, il existe un certain nombre d'outils qui prennent C sous une certaine forme, vous permettent d'ajouter des informations spécifiques au matériel (par exemple, quelle est l'interface matérielle?), Et de générer du matériel optimisé. Les utilisateurs expérimentés peuvent facilement obtenir de meilleurs résultats en moins de temps que le RTL codé à la main.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.