Tout comme un langage de programmation procédural passe par plusieurs étapes (compiler, assembler, lier) pour produire un exécutable, les HDL doivent passer par plusieurs processus avant qu'un fichier de configuration utilisable pour le FPGA ne soit généré. Ceux-ci incluent

• Synthèse --- convertit le code HDL en une netlist décrivant les connexions entre les éléments logiques.

• Mapping --- Convertissez la netlist en une netlist plus raffinée qui utilise les ressources réellement disponibles sur votre appareil FPGA.

• Place et route --- sélectionnez les ressources réelles de l'appareil qui seront utilisées pour chacun des éléments requis dans la sortie du mappeur, et choisissez les ressources de routage qui seront utilisées pour les interconnecter.

• Génération de bitfile --- convertit la sortie du lieu et de l'itinéraire au format réellement utilisé pour programmer l'appareil.

Donc si, quand vous demandez quelle est la sortie de la synthèse, vous voulez dire quelle est la sortie de la première étape de ce processus, alors c'est un fichier intermédiaire utilisé comme entrée du mappeur. Si vous voulez dire quelle est la sortie de l'ensemble du processus, c'est un fichier binaire que le FPGA peut utiliser pour configurer toutes ses ressources logiques et de routage.

Register Transfer Logic (RTL) est le résultat de la première phase de traduction, avant qu'il ne soit mappé aux ressources spécifiques au fournisseur, qui ne sont pas portables entre les fournisseurs ou même entre différents FPGA du même fournisseur. Essentiellement, RTL montre à la fois la logique combinatoire et les registres synchrones (bascules D), de sorte que les machines à états sont reconnaissables. RTL est assez cohérent entre Altera et Xilinx, et est probablement la phase la plus intéressante et la plus utile à inspecter. Les problèmes de synthèse deviennent d'abord visibles lors de la phase RTL, et la conception est toujours reconnaissable. Une fois qu'il passe à la cartographie spécifique au fournisseur, il est découpé et brouillé. Essayer de décoder un flux binaire spécifique à une puce est coûteux, peu avantageux et sera inutile lorsque vous passez à un autre fournisseur ou même à un FPGA de taille différente dans la même famille. Vous pouvez voir ce que vous avez besoin de voir au niveau RTL.

Il est toujours bon de tester votre code Verilog ou VHDL nouvellement développé en l'instanciant dans un banc de test ou dans un simple module de niveau supérieur, et en inspectant le code RTL. Xilinx ISE est très agréable pour inspecter RTL sous forme de schéma (bien qu'il manque parfois des choses.) Les problèmes les plus courants sont:

• Réseaux 1 bit où un bus était destiné
• morceaux de logique supprimés de manière inattendue par l'optimiseur ... semblable à la façon dont une simple boucle de délai de verrouillage de rotation est supprimée silencieusement par l'optimisation du code.
• les sorties ne sont pas complètement spécifiées, en raison d'une approche procédurale au lieu d'une approche de table de vérité. Si l'outil pense que la sortie finit toujours par 0 ou toujours 1, il supprimera toute la logique qui génère ce résultat.
La logique du module
• est supprimée car l'un des sous-modules a été optimisé pour toujours 0 ou toujours 1; cela peut monter en cascade jusqu'au niveau supérieur

Cette inspection RTL devient très lourde à moins que vous ne gardiez vos modules petits et simples. L'utilisation d'un banc de test est un outil important.

Je viens moi aussi de la programmation de systèmes embarqués d'abord et de verilog ensuite, et le plus grand danger pour les gens comme nous lors de l'apprentissage du codage HDL est qu'il ressemble à un langage de programmation procédural, et cela se sent comme un langage de programmation procédural (pendant la simulation), mais ensuite tout explose lorsque vous essayez de synthétiser du code de travail. Vous devez vraiment réfléchir à ce à quoi le matériel doit ressembler et vous assurer que le code RTL inclut tout le matériel que vous attendez.

Hormis le fait que Verilog / VHDL implique de taper du code source dans un fichier informatique, il n'y a pas vraiment de ressemblance avec le C / C ++ / etc traditionnel. Très peu de votre expérience en programmation sera transférée. Concentrez-vous sur la division des gros problèmes en petits problèmes, la documentation détaillée de tout et la rédaction de bancs de test. Investissez également dans un bon oscilloscope d'échantillonnage numérique si vous n'en avez pas déjà un. Jetez un œil à certains des exemples de code publiés sur opencores.org, car avec C / C ++, vous pouvez apprendre beaucoup de techniques (bonnes et mauvaises) en lisant le code d'autres personnes.

Une chose qui me rend fou à propos du développement FPGA est que le contrôle de code source n'est pas quelque chose que les fournisseurs de chaînes d'outils semblent considérer comme une fonctionnalité importante. Xilinx Vivado est particulièrement mauvais à cet égard, leur conseil semble être de régénérer les fichiers du projet à partir de zéro lors d'une nouvelle extraction. Essayer de faire un transfert de projet avec plus de 100 Mo de fichiers zip est décourageant.

L'autre chose qui me rend dingue à propos du développement FPGA est que les outils Quartus / ISE / Vivado n'ont pas vraiment de moyen satisfaisant de réprimer le flot de messages d'avertissement. Lorsque j'écris des programmes C / C ++, je m'attends à être en mesure d'adresser chaque message d'avertissement individuellement et de le corriger ou de le sanctionner, de sorte que je puisse éventuellement obtenir une compilation propre sans aucun avertissement. Jamais vraiment vu quiconque réaliser cela dans le développement FPGA; d'autres développeurs FPGA (qui sont plus intelligents que moi) semblent simplement accepter qu'un projet normal a beaucoup de messages de diagnostic, qu'ils ignorent souvent simplement, en se contentant de faire des travaux pratiques et de vérifier sur du matériel réel.

Si jamais vous développez votre propre carte FPGA (ce que je ne recommande pas), assurez-vous de faire ressortir toutes les broches d'E / S inutilisées vers un en-tête quelque part - autant que vous pouvez en gérer - car cela va être votre bouée de sauvetage lorsque vous devez déboguer le code FPGA ou implémenter un correctif de onzième heure.

Vous avez mentionné la programmation en langage assembleur comme un moyen d'exercer un contrôle précis sur ce que fait l'ordinateur, et il est possible d'exercer un contrôle aussi précis sur le code FPGA en utilisant des primitives non portables et spécifiques au fournisseur. Ce sera différent pour chaque fournisseur et chaque FPGA, tout comme le langage d'assemblage est différent pour différents processeurs. Pour Xilinx, vous écririez un fichier de contraintes (différent pour la chaîne d'outils ISE ou la chaîne d'outils Vivado). Le fichier de contraintes appelle des instances spécifiques ou des réseaux spécifiques et spécifie les exigences de synchronisation. En règle générale, les CLB / LUT / anyUnits de bas niveau sont disposés dans une grille, vous pouvez donc épingler une primitive de bas niveau spécifique pour vivre à un emplacement de grille X, Y spécifique. Recherchez l'ancien "FPGA Editor" de Xilinx pour la série Spartan 3, ils encourageaient les gens à l'utiliser de cette façon. Je pense que la nouvelle série 7 et les puces Zynq ne sont pas prises en charge. Tout comme l'assemblage, il est très spécifique à la technologie et constitue donc une sorte de compétence volatile.

Semblable à l'assemblage, pour autre chose qu'un simple exercice de «devoirs», vous voulez vraiment minimiser la quantité d'assemblage que vous écrivez;utilisez C / C ++ pour 98% -99% et n'écrivez l'assembly que pour le 1% qui est sensible aux performances.Si, par exemple, vous avez une conception FPGA qui nécessite un sous-processus pour s'exécuter à 200 MHz, cela vaut la peine de plonger dans le mappage de bas niveau pour voir ce que font les outils.Le meilleur avantage pour l'optimisation est d'éliminer les étapes de travail inutiles.Ce n'est qu'après avoir réduit au strict minimum les éléments chauds, alors seulement il vaut la peine de commencer à router manuellement quels IOB appartiennent à quels emplacements de grille.Laissez la machine faire le gros du travail pour que vous puissiez concentrer vos efforts.

La primitive physique d'un FPGA est un bloc logique configurable (CLB).

Chaque bloc logique reçoit un emplacement dédié en mémoire, appelé mémoire de configuration, qui détermine comment il est configuré et où il se connecte.

Le HDL se termine finalement par un tas de uns et de zéros, un soi-disant train de bits qui est placé dans cette mémoire de configuration.

La plupart des FPGA n'ont pas de mémoire de configuration non volatile intégrée. Au lieu de cela, le train de bits de configuration est stocké sur une ROM FLASH de configuration externe et à la mise sous tension, le FPGA charge ce train de bits de la mémoire non volatile externe dans sa configuration interne SRAM qui est directement connectée et contrôle les CLB.

Contrairement aux logiciels, ce bitstream n'est pas "exécuté". Il est juste chargé et ensuite il "est" simplement. Cela ressemble moins à des instructions en cours d'exécution qu'à des registres contenant des paramètres.

C'est un fichier tel qu'un * .bit. Il n'y a pas de format standard. Je ne sais pas pourquoi vous voudriez écrire vous-même un simulateur alors que les outils de développement FPGA sont livrés avec un simulateur. Beaucoup d'efforts sont consacrés à cela et ils connaissent leurs appareils mieux que quiconque, car contrairement aux logiciels, chaque primitive spécifiée dans le train de bits doit être physiquement située quelque part sur la puce FPGA et le plan d'étage peut faire ou défaire certaines conceptions.

Quels octets passent en écriture lors de la programmation d'un FPGA?

Cette question est moins généralement responsable, car elle est 100% spécifique au fabricant et à l’appareil. Certains fabricants publient des fiches techniques à cet effet; d'autres fabricants considèrent cela comme un "secret commercial" et vous devrez signer un NDA pour le savoir.

Avec un compilateur C (ou tout autre langage) de toute façon, les octets bruts ne sont pas la partie la plus élémentaire. La partie la plus élémentaire est la série d'instructions du processeur qui implémentent votre programme, et les octets bruts sont simplement la façon dont vous indiquez au processeur quelles sont ces instructions. Ces instructions amènent le processeur à effectuer des opérations en utilisant ses diverses installations matérielles telles que des additionneurs, des multiplicateurs et autres, et à stocker ou à récupérer des données dans des registres et des mémoires.

C'est très similaire dans un FPGA, sauf que vous commencez à un niveau inférieur. Au lieu d'avoir une liste d'instructions à exécuter, vous avez une liste de la manière dont chaque porte du FPGA doit être interconnectée. La plupart des FPGA contiennent également des sections spécialisées pour la RAM et d'autres fonctionnalités, et votre programme inclura également la manière dont elles sont connectées.

Vous obtenez alors une netlist , comme si vous conceviez un PCB avec un million de puces logiques. C'est conceptuellement la sortie la plus basique de votre compilateur FPGA pour vous dire ce qu'il fait, de la même manière qu'une liste d'assembleur est conceptuellement la sortie la plus basique de votre compilateur C pour vous dire ce que fait le processeur.

Bien sûr, le compilateur continue alors à produire un fichier binaire qui programmera le FPGA avec cette netlist, de la même manière qu'un compilateur C continue de produire un fichier binaire qui programme votre micro avec cet assembleur.

"Quels octets passent en écriture lors de la programmation d'un FPGA?"

De manière simpliste, ces octets contiennent les informations pour:

1) Configuration des blocs d'E / S & logiques FPGA (voulez-vous que ce bloc soit un registre, un multiplexeur, une table de recherche à usage général), et

2) Configurer l'interconnexion sur le FPGA pour relier les blocs logiques les uns aux autres et se connecter ensuite au monde extérieur.

Tellement de réponses que je ne les ai pas toutes lues, étant quelqu'un qui est assis des deux côtés de la clôture, du matériel et des logiciels ....

Donc, alors qu'il s'agit à tous égards d'un langage de programmation qui est compilé dans d'autres langages, idéalement de niveau inférieur (C vers asm ou code machine, JAVA vers bytecode ou autre langage ou code assembleur ou machine, etc.). Il y a beaucoup plus d'étapes et les cibles sont beaucoup plus variées que isa qui sont aussi courantes que différentes: add, mov, jne, push, pop, etc.

Le code machine des fpgas ou asics n'est pas seulement des transistors discrets, mais une bibliothèque de choses. Pour les asics pour une fonderie et un processus particuliers, il existe une ou plusieurs bibliothèques de cellules disponibles et elles auront des portes simples et et ou mais aussi des choses plus grandes et plus compliquées, pourquoi construire un loquet à partir de composants discrets lorsque les auteurs de la bibliothèque peuvent créer une taille commune et emballez-le de manière efficace (immobilière). Ainsi, comme pour tout compilateur ou auteur de haut niveau, vous parcourez la liste des options et en choisissez quelques-unes. y compris une longue liste de srams de différentes largeurs et profondeurs. Pour un FPGA, ce sont des LUT ou des modules génériques fixes qui peuvent agir comme divers modules qui sont plus compliqués qu'une simple porte et, ou, xor.

Le monde FPGA aime garder les choses près de sa poitrine, aussi ils essaient d'être beaucoup plus abordables que les outils asic, des dizaines de milliers de dollars par an plutôt que des millions. Et comme tout autre environnement intégré, vous avez parfois divers fournisseurs qui ont été achetés ou licenciés et les outils collés ensemble (souvent pas très jolis).

Toutes les étapes mentionnées par les autres personnes ont donc eu lieu. ce qui est plus que le logiciel et les formats de fichiers sont très propriétaires et ne devraient pas être documentés ni pris en charge, chaque version pourrait changer. Encore une fois, ces gens semblent être compétitifs et secrets (s'ils s'ouvraient, nous pourrions avoir des outils nettement meilleurs et ils pourraient vendre plus de produits IMO, mais pourraient réduire l'argent de soutien, ce dont ils vivent peut-être avec leurs outils merdiques) .

Quand les gens disent netlist, le verilog est compilé dans une netlist, ceux que j'ai vus sont également en verilog ou vhdl comme ces langages le couvrent. Finalement, vous ciblerez le type spécifique, fpga, cpld, asic, etc. Le fpga étant une cible déjà câblée / fixe, vous vous retrouverez finalement avec une liste de fusibles ou de commutateurs si vous voulez, prenez un lut générique et connectez cette entrée à cela et cette entrée à cela en ouvrant et en fermant des connexions dans le maillage massif de choses. Ce qui finit par être une sorte de simple liste de marche et arrêt. Et je pense qu'il y a peut-être un standard jedec à ce sujet, mais souvent appelé bitstream et au moins nous utilisons un lecteur bitstream pour charger.

Les CPLD en général, vous programmez ces informations dans la partie elle-même, que ce soit un flash intégré qui ouvre / ferme les choses à la mise sous tension et / ou le stockage non volatile à l'intérieur s'allume avec les éléments câblés.

Les FPGA ont généralement un flash externe et à la mise sous tension, les informations pour connecter les éléments sont chargées à partir de cela, puis le reste de la partie est généré en utilisant cette configuration. Ceux que je connais à votre sujet peuvent également charger ces informations dans la pièce et effectuer toutes les connexions, mais ces informations sont perdues lorsque la pièce est mise hors tension. donc selon votre conception, vous pourriez avoir une autre solution et ne pas utiliser le flash. Le format flash est probablement propriétaire, je n'ai pas regardé personnellement, lorsque vous entrez par l'interface de programmation qui passe par le fpga au flash pour qu'il puisse aller tel quel ou il pourrait être converti en quelque chose d'autre.

Avec les logiciels, en particulier à cette époque et à cet endroit, nous sommes principalement habitués à ouvrir des trucs, de bons outils gratuits que beaucoup de gens utilisent. Ce qui signifie également que les formats de fichiers sont documentés et quelque peu courants, certains avaient un historique avant cette heure .com et .exes et d'autres pour d'autres systèmes d'exploitation de l'époque. Mais encore une fois, le monde du logiciel est plus commun que différent, vous visez idéalement le code machine ou le bytecode. Avec la logique, vous passez d'un niveau élevé à un niveau inférieur mais en utilisant le même langage jusqu'à un certain point. Ensuite, vous ciblez peut-être un simulateur qui a sa propre bibliothèque de modules ou fpga n avec sa bibliothèque ou fpga m avec sa bibliothèque et ainsi de suite. Et ces gens sont très protecteurs des informations.

Clifford et le projet IceStorm IMO est la bonne voie à suivre, c'est jusqu'à présent la seule fois où j'ai construit quelque chose pour un fpga qui soit simple, cela fonctionne, pas d'avertissements ni d'erreurs que les gens aiment souvent.J'ai passé d'innombrables nuits à essayer d'obtenir la chose la plus simple à construire pour un fpga de tous les principaux fournisseurs sans avertissement ... et j'abandonnerais toujours.Du verilog à la partie programmée, il y a au moins trois projets séparés, ce qui implique qu'il existe des fichiers intermédiaires que les deux côtés doivent prendre en charge pour que les formats de fichiers soient là.mais on s'attend à ce qu'il soit spécifique au projet et pas nécessairement comme un fichier elf qui est largement utilisé pour plus d'un cas d'utilisation.

Comprenez que le monde des puces, y compris les fpgas, est extrêmement coûteux, donc il est axé sur l'argent, ce qui signifie souvent vendre des outils et surtout des contrats de support annuels.Ce qui signifie des sources fermées, des informations fermées, et non des formats de fichiers documentés publiquement.

Avant d'arriver à la synthèse, vous pouvez vérifier la conception en simulation.Dans ce cas, votre conception est traitée comme un logiciel - et pour au moins un simulateur (open source GHDL, sans surprise pour VHDL), le compilateur peut utiliser des backends gcc ou LLVM pour générer un exécutable ordinaire.

En général, vous intégrez votre conception réelle dans un "banc de test" (également écrit en VHDL) qui génère des signaux d'entrée et des rapports sur l'exactitude des sorties - soit à la console (via des instructions Assert / Report) ou à l'aide d'outils de vérification et de journalisationcomme OSVVM, dans un cadre de test unitaire (VUnit).

Si tout le reste échoue, vous pouvez vider et inspecter les formes d'onde dans une interface graphique.

Une fois que tout fonctionne, procédez à la synthèse comme décrit dans les autres réponses.