Quelles sont les meilleures pratiques pour les langages de description du matériel (Verilog, VHDL, etc.) [fermé]

Question

Quelles sont les meilleures pratiques à respecter lors de l’implémentation du code HDL?

Quels sont les points communs et les différences par rapport aux domaines de développement logiciel les plus courants?

Answer 1

Le meilleur livre sur ce sujet est Manuel de méthodologie de la réutilisation . Il couvre à la fois le VHDL et le Verilog.

Et en particulier certains problèmes qui ne correspondent pas exactement au logiciel:

• Aucun verrou
• Faites attention avec les réinitialisations
• Vérifiez votre minuterie interne et externe
• N'utilisez que du code synthétisable
• Enregistrez vos sorties de tous les modules
• Faites attention aux assignations bloquantes et non bloquantes
• Faites attention aux listes sensibles pour la logique combinatoire (ou utilisez @ (*) dans Verilog)

Certains qui sont les mêmes incluent

• Utiliser CM
• avoir des critiques de code
• Testez (simulez) votre code
• Réutilisez le code si nécessaire
• Avoir un horaire à jour
• Avoir une spécification ou des cas d'utilisation ou un client Agile

Answer 2

Sorte d’un vieux fil, mais je voulais mettre mon 0,02 $. Ce n’est pas vraiment spécifique à Verilog / VHDL .. plus sur la conception matérielle en général ... conception spécifiquement synthétisable pour ASIC personnalisés.

C’est mon opinion basée sur des années d’expérience de l’industrie (par opposition aux universitaires) en design. Ils ne sont dans aucun ordre particulier

Mon instruction parapluie est de concevoir pour l'exécution de validation. Dans la conception du matériel, la validation est primordiale. Les bugs sont beaucoup plus coûteux lorsqu'ils sont trouvés dans le silicium réel. Vous ne pouvez pas simplement recompiler. Par conséquent, on met beaucoup plus l'accent sur le pré-silicium.

• Connaissez la différence entre les chemins de contrôle et les chemins de données. Cela vous permet de créer un code beaucoup plus élégant et maintenable. Vous permet également de sauvegarder des portes et de minimiser la propagation X. Par exemple, les chemins de données ne devraient jamais avoir besoin de flops réinitialisables, les chemins de contrôle en ont toujours besoin.

• Prouvez la fonctionnalité avant la validation. Soit par une approche formelle ou par des formes d'onde. Cela présente de nombreux avantages, d’expliquer 2. Tout d’abord, cela vous évitera du temps perdu à éplucher les problèmes. Contrairement à beaucoup de conception au niveau de l'application (particulièrement pendant l'apprentissage) et à la plupart des travaux de cours, le délai de traitement des modifications de code est très long (de 10 minutes à plusieurs jours, selon la complexité). Chaque fois que vous changez de code, vous devez procéder à l'élaboration, à la vérification de la charpie, à la compilation, à la génération de la forme d'onde et enfin à la simulation réelle… qui peut prendre des heures. Deuxièmement, vous avez beaucoup moins de chances d’avoir des difficultés à vous défendre. Notez que ceci concerne la validation préalable au silicium. Celles-ci vont sûrement frapper au post-silicium, ce qui vous coûtera beaucoup de $$$. Croyez-moi, le coût initial de la démonstration de la fonctionnalité minimise considérablement les risques et en vaut la peine. Il est parfois difficile de convaincre les récents diplômés des universités.

• Avez "des morceaux de poulet". Les morceaux de poulet sont des bits dans MMIO définis via le pilote pour désactiver une fonctionnalité dans le silicium. Il est destiné à inverser les modifications apportées dans lesquelles la confiance est faible (la confiance est directement proportionnelle aux efforts de validation). Il est presque impossible d'atteindre tous les états possibles dans le pré-silicium. La confiance dans votre conception ne peut vraiment être satisfaite tant que cela n’a pas été prouvé dans le post-silicium. Même s'il n'y a qu'un seul état touché qui survient dans le temps, 0,000005% du temps est exposé, il SERAIT HIT en post-silicium, mais pas nécessairement en pré-silicium.

• Évitez les exceptions dans le chemin de contrôle à tout prix. Chaque nouvelle exception que vous avez double vos efforts de validation. Celui-ci est difficile à expliquer. Disons qu'un bloc DMA sauvegarde les données en mémoire qu'un autre bloc utilisera. Disons que la structure de données sauvegardée dépend de l'exécution de certaines fonctions. Si vous avez décidé de concevoir de manière à ce que la structure de données sauvegardée soit différente entre les différentes fonctions, il vous suffit de multiplier vos efforts de validation par le nombre de fonctions DMA. Si cette règle est suivie, la structure de données sauvegardée serait un super-ensemble de toutes les données disponibles pour chaque fonction où les emplacements de contenu sont codés en dur. Une fois que la logique de sauvegarde DMA est validée pour une fonction, elle est validée pour toutes les fonctions.

• Minimiser les interfaces (lire minimiser les chemins de contrôle). Ceci est lié à la minimisation des exceptions. Tout d'abord, chaque nouvelle interface nécessite une validation. Cela inclut les nouveaux vérificateurs / suiveurs, assertions, points de couverture et modèles fonctionnels de bus dans votre banc d'essai. Deuxièmement, vos efforts de validation peuvent augmenter de manière exponentielle! Disons que vous avez 1 interface pour lire des données dans des caches. Maintenant, disons (pour une raison étrange) que vous décidez que vous voulez une autre interface pour lire la mémoire principale. Vous venez de quadrupler vos efforts de validation. Vous devez maintenant valider ces combinaisons à tout moment n :

  • pas de lecture en cache, pas de lecture en mémoire
  • pas de lecture en cache, lecture en mémoire
  • lecture en cache, pas de mémo

Answer 3

Les HDL comme Verilog et VHDL semblent vraiment encourager le code spaghetti. La plupart des modules sont constitués de plusieurs blocs "toujours" (Verilog) ou "processus" (VHDL) pouvant être placés dans n'importe quel ordre. L'algorithme global ou la fonction du module est souvent totalement obscurci. Comprendre le fonctionnement du code (si vous ne l'écrivez pas) est un processus difficile.

Il y a quelques années, j'ai découvert ce document qui décrit une méthode plus structurée pour Conception VHDL. L'idée de base est que chaque module ne comporte que 2 blocs de processus. Un pour le code combinatoire et un autre pour le synchrone (les registres). C'est excellent pour produire du code lisible et maintenable.

Answer 4

• en HDL, certaines parties du code peuvent fonctionner en même temps, par exemple deux lignes de code "peut fonctionner". en même temps, c'est un avantage, à utiliser judicieusement. c’est quelque chose qu’un programmeur habitué aux langages ligne par ligne peut avoir du mal à comprendre au début:

  • Des pipelines longs et spécifiques à vos besoins peuvent être créés.
  • Vous pouvez faire fonctionner vos gros modules en même temps.
  • au lieu d’une unité pour effectuer une action répétée sur différentes données, vous pouvez créer plusieurs unités et effectuer le travail en parallèle.

• Une attention particulière doit être accordée au processus de démarrage - une fois que votre puce est fonctionnelle, vous avez créé un énorme chemin.

Le débogage sur du matériel est généralement beaucoup plus difficile que le logiciel de débogage, par conséquent:

• Le code simple est préférable. Parfois, il existe d'autres moyens d'accélérer votre code, après il est déjà en cours d'exécution, par exemple en utilisant une puce à vitesse supérieure, etc.

• Évitez "intelligent". protocoles entre composants.

• Un code de travail dans le format HDL est plus précieux que sur d'autres logiciels, car le matériel est si difficile à déboguer, donc réutilisez-le et envisagez également d'utiliser "bibliothèques". des modules dont certains sont gratuits et d'autres vendus.

• La conception doit prendre en compte non seulement les bogues du code HDL, mais également les défaillances de la puce que vous programmez et des autres périphériques matériels qui s'interfacent avec la puce. Il faut donc vraiment penser à une conception facile vérifier.

Quelques conseils de débogage:

• Si une conception comprend plusieurs blocs de construction, vous voudrez probablement créer des lignes à partir des interfaces entre ces blocs et des points de test situés en dehors de la puce.

• Vous souhaiterez enregistrer suffisamment de lignes dans votre conception pour transférer les données intéressantes à inspecter avec des périphériques externes. vous pouvez également utiliser ces lignes et votre code pour vous indiquer l’état actuel de l’exécution - par exemple, si vous recevez des données à un moment donné. vous écrivez une valeur sur les lignes, vous écrivez une autre valeur à une étape ultérieure, etc. '

  Si votre puce est reconfigurable, cela deviendra encore plus pratique, car vous pourrez personnaliser des tests et reprogrammer les sorties pour chaque test au fur et à mesure (cela s’apparaît très bien avec les leds :). )

Modifier:

Par protocoles intelligents, je veux dire que si deux de vos unités physiques se connectent, elles doivent communiquer avec le protocole de communication le plus simple disponible. c'est-à-dire, n'utilisez aucun protocole sophistiqué fait maison, entre eux.

La raison, est-ce - Fiducie bugs " inside " Un FPGA / ASIC est relativement facile avec des simulateurs. Donc, si vous êtes sûr que les données viennent comme vous le souhaitez et sortent au fur et à mesure que votre programme les envoie, vous avez atteint l'utopie matérielle - être capable de travailler au niveau logiciel :) (avec le simulateur). Mais si vos données ne vous parviennent pas, comme vous le souhaitez, et que vous devez comprendre pourquoi ... vous devrez vous connecter aux lignes, et ce n’est pas si facile.

Il est difficile de trouver un bogue sur les lignes, car vous devez vous connecter aux lignes avec un équipement spécial, qui enregistre les états des lignes, à des moments différents, et vous devrez vous assurer que vos lignes agissent conformément au protocole.

Si vous devez connecter deux de vos unités physiques, définissez le "protocole". aussi simple que possible, jusqu'à ce que cela ne s'appelle pas un protocole :) Par exemple, si les unités partagent une horloge, ajoutez x lignes de données entre elles et faites en sorte qu'une unité les écrive et que l'autre unité soit lue, transmettant ainsi un "mot". qui a x bits entre eux à chaque chute d'horloge, par exemple. Si vous avez des FPGA, si la fréquence d'horloge d'origine est trop rapide pour les données parallèles, vous pouvez en contrôler la vitesse en fonction de vos expériences, par exemple en faisant en sorte que les données restent sur des lignes d'au moins 't' cycles d'horloge, etc. Je suppose que les données parallèles t

Answer 5

Telle est la question qui nécessite les 10 commandements de JBDAVID pour la conception matérielle.

1. Utilisez Revision / Version Control, comme dans Software. SVN et Hg sont gratuits.
2. Requiert le code pour passer la vérification de la syntaxe avant l’enregistrement. Un outil LINT est mieux.
3. Utilisez un langage de vérification matérielle complet pour la vérification de la conception. System-Verilog est un choix presque sûr.
4. Suivre les bugs. Bugzilla et GNATS sont des outils gratuits. FogBugz nécessite un peu de $.
5. Utilisez des assertions pour détecter les problèmes d'utilisation incorrecte.
6. La triade de couverture permet une conception stable: couverture du code de mesure, couverture fonctionnelle et couverture d’assertion dans les outils de simulation et les outils formels.
7. Power is King: utilisez CPF ou UPF pour capturer, appliquer et vérifier votre Power-Intent.
8. la conception réelle est souvent un signal mixte. Utilisez un langage à signaux mixtes pour vérifier l’analogique avec le numérique. Verilog-AMS est l'une de ces solutions. Mais n'allez pas trop loin. La modélisation par nombres réels peut accomplir la plupart des aspects fonctionnels du comportement de signaux mixtes.
9. Utilisez l’accélération matérielle pour valider le logiciel devant fonctionner avec le silicium!
10. Les éditeurs de texte dépendant de la syntaxe pour votre HDL / HVL sont une exigence minimale pour l'EDI du développeur.

Answer 6

Pour les FPGA, Xilinx a cette page . Presque tous s’appliqueraient à d’autres fournisseurs de FPGA ou auraient des règles équivalentes. Beaucoup de choses s’appliquent aux conceptions ASIC.

Intel recommande les styles et codes de conception HDL recommandés (PDF) sous cette page .