Quelle est la motivation de l'utilisation de Verilog ou VHDL sur C?

Je viens d'un milieu de programmation et je ne me suis pas trop occupé du matériel ou du firmware (tout au plus un peu électronique et Arduino).

Quelle est la motivation à utiliser des langages de description matérielle (HDL) tels que Verilog et VHDL sur des langages de programmation comme C ou certains assembleurs?

Cette question est-elle une question de choix?

J'ai lu que le matériel, dont le micrologiciel est écrit dans un HDL, a un net avantage à exécuter les instructions en parallèle. Cependant, j'ai été surpris de voir des discussions exprimant des doutes quant à l'écriture du firmware en C ou Assembly (comment Assembly est-il approprié si vous n'avez pas nécessairement de CPU?), Mais j'ai conclu que c'était aussi une option.

Par conséquent, j'ai quelques questions (n'hésitez pas à expliquer quoi que ce soit):

1. Un firmware peut vraiment être écrit en HDL ou dans un langage de programmation logicielle, ou est-ce juste une autre façon d'effectuer la même mission? J'adorerais des exemples du monde réel. Quelles contraintes résultant de chaque option?

2. Je sais qu'une utilisation courante du micrologiciel par rapport au logiciel est dans les accélérateurs matériels (tels que les GPU, les adaptateurs réseau, les accélérateurs SSL, etc.). Si je comprends bien, cette accélération n'est pas toujours nécessaire, mais seulement recommandée (par exemple, dans le cas de SSL et d'accélération d'algorithmes complexes). Peut-on choisir entre firmware et logiciel dans tous les cas? Sinon, je serais heureux des cas dans lesquels le firmware est clairement et sans équivoque approprié.

3. J'ai lu que le firmware était principalement gravé sur ROM ou flash. Comment est-il représenté là-dedans? En bits, comme un logiciel? Si oui, quelle est la profonde différence? Est-ce la disponibilité de circuits adaptés dans le cas de firmware?

Je suppose que j'ai fait une erreur ici et là dans certaines hypothèses, veuillez me pardonner. Je vous remercie!

Quelle est la motivation à utiliser des langages de description matérielle (HDL) tels que Verilog et VHDL sur des langages de programmation comme C ou certains assembleurs?

C et l'assemblage sont de bons langages pour dire à un CPU quoi faire. Ils décrivent les actions à effectuer séquentiellement par une seule machine d'état.

Les HDL sont de bons langages pour décrire ou définir une collection arbitraire de circuits numériques. Ils peuvent exprimer des opérations effectuées en parallèle d'une manière que les langages de programmation ne peuvent pas. Ils peuvent également décrire les limitations temporelles pour les interfaces entre les blocs d'une manière que les langages de programmation ne peuvent pas.

J'ai été surpris de voir des discussions exprimant des doutes quant à la nécessité d'écrire le firmware en C ou Assembly (en quoi Assembly est-il approprié si vous n'avez pas nécessairement de CPU?)

Dans cette question, ce qui est demandé est: "Si vous écrivez du code pour un microcontrôleur, y a-t-il une vraie différence si vous écrivez en assembleur ou en C ou dans un autre langage de haut niveau?".

Puisqu'il pose spécifiquement des questions sur les systèmes avec un microcontrôleur (un processeur avec des périphériques), le C ou l'assemblage sont tous deux des choix raisonnables pour le développement de firwmare, et les HDL ne le sont pas.

Un firmware peut vraiment être écrit en HDL ou dans un langage de programmation logicielle, ou est-ce juste une autre façon d'effectuer la même mission?

Cela dépend du type de matériel dont vous disposez. Si vous avez un CPU, utilisez un langage de programmation. Si vous avez un FPGA ou que vous concevez un ASIC, utilisez un HDL. Si vous concevez une très grande quantité de logique numérique, vous pouvez vous tourner vers l'un des langages intermédiaires comme SystemVerilog.

J'ai lu que le firmware était principalement gravé sur ROM ou flash. Comment est-il représenté là-dedans? En bits, comme un logiciel? Si oui, quelle est la profonde différence? Est-ce la disponibilité de circuits adaptés dans le cas de firmware?

Je pense que vous êtes accroché au terme "firmware". Ce mot signifiait à l'origine que le code devait être exécuté sur un système embarqué, qui n'était pas accessible à l'utilisateur final. Si vous vendez un PC à quelqu'un, il y a de fortes chances que l'utilisateur change le logiciel qui y est exécuté. Si vous leur avez vendu un oscilloscope, vous ne voudriez pas qu'ils changent le code exécuté sur le microprocesseur interne, vous l'avez donc appelé firmware.

Les utilisateurs de FPGA se sont approprié le mot "firmware" pour la sortie de leurs conceptions, car il est plus modifiable que le matériel (des trucs soudés ensemble). Mais en réalité, le "firmware" qui configure un FPGA est différent du "firmware" qui fonctionne sur uC. Le micrologiciel uC dirige l'uC à travers une série d'états pour exécuter sa fonction. Le micrologiciel FPGA définit un ensemble d'interconnexions entre les éléments logiques et les valeurs à stocker dans les tables de recherche.

Dans les deux cas, le micrologiciel est généralement stocké sous forme de bits sur une eeprom (ou sur un disque sur une machine hôte qui le télécharge à chaque redémarrage du système intégré). Mais cela ne les rend pas similaires les uns aux autres.

Pour la première partie de votre question, sur les motivations à utiliser l'un ou l'autre: il y a une différence fondamentale entre C et HDL (VHDL / Verilog) . C est un langage de programmation logicielle (tout comme l'assemblage), VHDL / Verilog sont des langages de description matérielle . Ils ne sont pas destinés au même but.

C est traduit en code assembleur (sous sa forme binaire, c'est-à-dire en langage machine) lors de sa compilation . Ce code est une série d'instructions qui indiquent au CPU d'effectuer une série d'opérations de base (modifier une valeur de registre, effectuer un ajout, etc.).

D'un autre côté, un HDL est synthétisé sur du matériel. En VHDL, vous pouvez par exemple écrire quelque chose comme:

output <= input1 + input2;

(voir également un exemple plus complet ici ). Cela serait synthétisé dans un additionneur (matériel). Si le code est synthétisé pour un FPGA , cela signifierait un train de bits qui peut configurer le FPGA spécifique pour implémenter un additionneur (comme logique combinatoire ).

En fait, vous pouvez concevoir un CPU en VHDL (voir Processeurs à noyau dur VS Processeurs à noyau dur ) et écrire le logiciel pour cela en C ...

À propos du firmware: tout dépend en fait de la façon dont vous définissez le mot. Un firmware peut être un programme (logiciel) qui s'exécute dans un microcontrôleur (ainsi écrit par exemple en C ou assembleur), ou il peut être un train de bits pour configurer un dispositif logique (matériel) programmable (CPLD ou FPGA). Parfois, il peut s'agir d'un package contenant les deux: si vous prenez le firmware de certains modèles de FritzBox (un modem ADSL), ils contiennent en fait un système Linux complet (écrit en assembleur, C et de nombreux autres langages de programmation), et un flux binaire vers configurer un FPGA (probablement synthétisé à partir de VHDL ou Verilog).

1. Cela dépend de votre architecture. Si vous avez un CPU (ou, typiquement, un microcontrôleur), vous devez écrire le firmware dans un langage de programmation normal (y compris l'assemblage). Si vous avez quelque chose comme un FPGA, votre firmware doit être écrit dans un HDL. Les HDL ne peuvent pas (à ma connaissance) générer des programmes qui peuvent être exécutés efficacement par un CPU conventionnel, et un FPGA n'exécute pas de programmes conventionnels. Vous pouvez cependant configurer votre FPGA en tant que CPU puis exécuter un programme conventionnel avec cela. Cela nécessiterait deux couches de firmware, la couche inférieure écrite dans un HDL pour construire le CPU, et la couche supérieure écrite dans un langage de programmation conventionnel pour s'exécuter sur ce CPU.
2. Il n'y a pas de distinction nette entre firmware et logiciel. Sur de nombreux appareils, le micrologiciel serait stocké, par exemple, dans la mémoire flash, mais sur un téléphone moderne, presque tout est stocké dans la mémoire flash, et la distinction entre le micrologiciel et le logiciel n'est pas claire (la plupart des gens envisageraient probablement le code pour programmer le micrologiciel du processeur de bande de base). , et la plupart des gens envisageraient des logiciels d'application, mais où est la limite exacte?).
3. Comme je l'ai dit dans 2, il n'y a pas de distinction claire, à part l'idée que le firmware est un peu plus permanent.

La concurrence matérielle est une motivation majeure.

Les électrons peuvent circuler en même temps dans des fils parallèles, nous voulons donc en tenir compte lors de la conception du matériel.

En VHDL, si vous écrivez quelque chose comme:

x <= a or b;
y <= a and b;
z <= x xor y;

(en dehors d'un processou function, qui le marque explicitement comme séquentiel), alors vous avez encodé le fait que:

• x, y, z, aEt bsont des fils
• aet bsont des signaux d'entrée
• xest connecté à la sortie d'un orcircuit, qui prend aet bcomme entrée
• et ainsi de suite pour les autres lignes

Il est facile de voir comment cela sera synthétisé en matériel réel, et cela xet yévalué en même temps.

        +-----+
A--+----+     |  X
   |    | OR  +-----+
B----+--+     |     |  +-----+
   | |  +-----+     +--+     |
   | |                 | XOR +-- Z
   | |  +-----+     +--+     |
   | +--+     |  Y  |  +-----+
   |    | AND +-----+
   +----+     |
        +-----+

Ensuite, quand il est temps de simuler le circuit, le simulateur (qui est généralement un programme séquentiel) a donc simulé la physique du circuit quelque chose comme ceci:

• a aou a bchangé? Oui? Hé, ça xdépend a. Mettons à jour x.
• ydépend également de a. Mettez-le également à jour.
• zdépend x. Mettez-le à jour car il a xété mis à jour.
• quelque chose qui xdépend ( aou b) a-t-il été mis à jour? Non? Pareil pour yet z. OK, nous avons terminé cette étape.

Cela conduit à des résultats possibles "intéressants" qui n'ont pas d'analogue séquentiel, mais qui représentent des situations physiques possibles:

• x <= not xconduirait à une récursion infinie de la simulation. Les simulateurs peuvent simplement couper après une certaine profondeur.
• x <= 0; x <= 1conduit à une erreur (court-circuit). C'est l' une des raisons pour lesquelles std_logicexiste.

Pourtant, même si VHDL modélise le matériel plus étroitement que C, ce n'est pas lui-même une description parfaitement détaillée de celui-ci:

• seulement un sous-ensemble de VHDL en synthétisable
• de nombreuses simplifications physiques sont apportées, en particulier pour que les signaux se propagent à une vitesse infinie, voir https://en.wikipedia.org/wiki/Static_timing_analysis TODO il est peut-être possible de modéliser les retards dans Verilog: http://www.asic-world.com /verilog/gate3.html#Gate_and_Switch_delays

En fin de compte, le VHDL fournit un bel équilibre entre une fonctionnalité de circuit compréhensible par l'homme de niveau supérieur et une synthétisabilité de niveau inférieur.

C d'autre part, est plus concentré sur la conversation séquentielle avec le CPU.

Vous pouvez bien sûr encoder un circuit avec des structures C, des énumérations et des tableaux, puis le simuler comme le fait VHDL (cela ressemble plus ou moins à ce que fait le système C , mais je ne l'ai jamais essayé).

Mais vous seriez essentiellement en train de réimplémenter un simulateur VHDL, et avec un langage plus verbeux. Le bon outil pour le bon travail, je suppose.

Il existe également des outils qui convertissent C en VHDL /programming/8988629/can-you-program-fpgas-in-c-like-languages mais s'attendent à des performances inférieures car ce sont des conversions de niveau supérieur difficiles.

Les HDL sont utilisés pour décrire (synthétiser) du matériel alors que le langage de programmation est utilisé pour programmer le matériel déjà synthétisé, c'est-à-dire cpu.

Vous pouvez obtenir des versions soft core de cpus en VHDL ou bitstream pour synthétiser ce cpu sur un FPGA.

Un processeur utilise une quantité modeste de circuits pour effectuer un grand nombre d'opérations, séquentiellement, en permettant à la plupart des composants d'être utilisés pour effectuer différentes opérations à différents moments.

Un FPGA contient un certain nombre de circuits qui ne peuvent pas - au moins individuellement - effectuer des opérations particulièrement sophistiquées, mais sont tous capables d'agir simultanément et indépendamment.

Supposons que l'on veuille avoir une puce qui effectue un certain nombre de tâches, parmi lesquelles la surveillance de 15 entrées et:

• Régler une sortie à un niveau élevé à tout moment, toutes les entrées sont stables depuis au moins 21 ms et le nombre d'entrées élevées est un multiple de trois
• Régler la sortie à un niveau bas à tout moment, toutes les entrées ont été stables pendant au moins 21 ms et le nombre d'entrées élevées n'est pas un multiple de trois
• Changer la sortie de façon arbitraire entre le moment où une entrée change et le moment où toutes les entrées ont été stables pendant au moins 20 ms.

Si l'on a un microcontrôleur qui fait d'autres choses, mais peut épargner quelques microsecondes toutes les 20 ms pour examiner ces entrées et définir la sortie, alors la plupart des circuits que le microcontrôleur utilise pour effectuer d'autres tâches seront également utilisables pour effectuer la tâche indiquée. ci-dessus, donc très peu de circuits (autres que certains ROM et peut-être RAM) devront être consacrés à cette tâche. D'un autre côté, cela peut prendre un certain temps entre le moment où une entrée change et le moment où la sortie la reflète correctement.

En utilisant Verilog ou VHDL, on pourrait construire un circuit matériel qui pourrait surveiller en continu les 15 entrées et effectuer le calcul indiqué. Un tel appareil serait probablement en mesure de produire une sortie correcte dans un délai de 100 ns - des ordres de grandeur plus rapides que le microcontrôleur - mais la quantité de circuits dédiés à cette tâche et inutilisables à d'autres fins serait beaucoup plus grande.