Expériences de développement piloté par des essais (TDD) pour la conception logique (chip) dans Verilog ou VHDL
j'ai regardé sur le web et les discussions/exemples semblent être traditionnelle de développement de logiciels. Étant donné que Verilog et VHDL (utilisés pour la conception de puces, par exemple FPGAs et ASICs) sont similaires au développement de logiciels C et C++, cela semble logique. Cependant, ils ont certaines différences étant fondamentalement parallèles et nécessitant du matériel pour effectuer des tests complets.
Quelles expériences, bonnes et mauvaises, avez-vous eu? Les liens que vous pouvez suggérer sur ce application?
Modifications/précisions: 10/28/09: je suis particulièrement en demandant au sujet de TDD. Je suis habitué à faire des bancs d'essai, y compris des bancs d'auto-vérification. Je suis également conscient que SystemVerilog a certaines caractéristiques particulières pour les bancs d'essai.
10/28/09: les questions implicites comprennent 1) l'écriture d'un test pour n'importe quelle fonctionnalité, Ne jamais utiliser les formes d'onde pour la simulation et 2) l'écriture test/test benches premier.
11/29/09: Les Études Empiriques Montrent Que Les Développement Améliore La Qualité De L' ils font rapport pour (logiciel) TDD "la densité de défauts avant la publication des quatre produits, mesurée en tant que défauts par millier de lignes de code, a diminué entre 40% et 90% par rapport aux projets qui n'ont pas utilisé TDD. La direction des équipes a fait état d'une augmentation subjective de 15 à 35% du temps de développement initial des équipes utilisant TDD, bien que les équipes aient convenu que cette augmentation était compensée par une réduction des coûts de maintenance."La réduction des bugs réduit le risque de sortie de bande, aux frais d'une incidence modérée sur le calendrier. a aussi quelques données.
11/29/09: je fais principalement du contrôle et du code datapath, pas du code DSP. Pour DSP,la solution typique implique une simulation MATLAB bit-accurate.
03/02/10: L'avantage de TDD est que vous vous assurez que le test échoue en premier. Je suppose que cela pourrait aussi être fait avec des affirmations.
8 réponses
j'écris le code pour FPGAs, pas ASICS... mais TDD est mon approche préférée. J'aime avoir une suite complète de tests pour tous le code fonctionnel j'écris, et j'essaie (pas toujours avec succès) pour écrire testcode premier. Regarder les formes d'onde se produit toujours à un moment donné quand vous débuggez, mais ce n'est pas une bonne façon de valider votre code (IMHO).
compte tenu de la difficulté d'effectuer les essais adaptés dans le matériel réel (stimulant cas de coin est particulièrement dur) et le étant donné qu'une compilation VHDL prend quelques secondes (par rapport à une compilation "to hardware" qui prend de nombreuses minutes (ou même des heures)), Je ne vois pas comment quelqu'un peut opérer autrement!
j'ajoute aussi des assertions dans le RTL que je l'écris pour attraper des choses que je sais ne devrait jamais se produire. Apparemment, cela est considéré comme un peu "bizarre", car il y a une perception que les ingénieurs de vérification écrivent des assertions et les concepteurs de RTL ne le font pas. Mais la plupart du temps, je suis mon propre ingénieur de vérification, donc peut-être que c'est pour ça!
j'utilise VUnit pour le développement piloté par essai avec VHDL.
VUnit est une bibliothèque Python qui invoque le compilateur VHDL et le simulateur et lit les résultats de la simulation. Il offre également plusieurs belles bibliothèques VHDL qui rendent beaucoup plus facile d'écrire de meilleurs bancs de test, comme un bibliothèque de communication,bibliothèque de journalisation et vérification de la bibliothèque.
il y a beaucoup de possibilités depuis il est invoqué depuis Python. Il est possible de générer des données de test, ainsi que de vérifier les données de sortie de l'épreuve en Python. J'ai vu cet exemple, l'autre jour où ils ont utilisé Octave - Matlab - copie pour tracer les résultats de test.
VUnit semble très actif et j'ai pu plusieurs fois poser des questions directement aux développeurs et obtenir de l'aide assez rapidement.
un inconvénient est qu'il est plus difficile de déboguer les erreurs de compilation puisqu'il y a tellement de variations de fonction / procédure avec le même nom dans les bibliothèques. En outre, certaines choses sont faites derrière la scène par prétraitement du code, ce qui signifie que certaines erreurs peuvent apparaître dans des endroits inattendus.
les extensions SystemVerilog à la norme IEEE Verilog incluent une variété de constructions qui facilitent la création de suites de test approfondies pour vérifier des conceptions complexes de logique numérique. SystemVerilog est l'un des les langages de vérification du matériel (HVL) utilisés pour vérifier la puce ASIC conception par simulation (par opposition à l'émulation ou à L'utilisation de FPGA).
les avantages significatifs par rapport au langage traditionnel de conception matérielle (Verilog) sont:
- contrainte la randomisation
- assertions
- collecte automatique des données de couverture fonctionnelle et d'assertion
la clé est d'avoir accès à un logiciel de simulation cette norme récente (2005). Tous les simulateurs ne sont pas entièrement compatibles les fonctions les plus avancées.
en plus de la norme IEEE, il existe une bibliothèque SystemVerilog en libre accès des composants de vérification disponibles auprès de VMM Central ( http://www.vmmcentral.com). Il fournit un cadre raisonnable pour la création d'un environnement d'essai.
vous pouvez également faire plus de recherche sur le sujet en Forum De La Guilde verification.
SystemVerilog n'est pas la seule HVL,et VMM n'est pas la seule bibliothèque. Mais, je vous recommande les deux, si vous avez accès à la appropriée outils. J'ai trouvé que c'était une méthode efficace pour trouver la conception bugs avant la voie de silicium.
Je ne connais pas grand-chose à la conception du matériel/des puces, mais je suis profondément à fond dans le TDD, donc je peux au moins discuter de la pertinence du processus avec vous.
la question que je qualifierais la plus pertinente est: à quelle vitesse vos tests peuvent-ils vous donner des commentaires sur un design? Connexes: Comment rapidement pouvez-vous ajouter de nouveaux tests? Et dans quelle mesure vos outils prennent-ils en charge le remaniement (modification de la structure sans modification du comportement) de votre conception?
le processus de DTT dépend beaucoup de la "douceur"" de logiciels-bon unités automatisées essais courir en secondes (minutes à l'extérieur), et de guider de courtes rafales de la construction ciblée et le remaniement. Vos outils prennent - ils en charge ce type de flux de travail-oscillant rapidement entre l'écriture et l'exécution de tests et la construction du système testé en courtes itérations?
en ce qui concerne le remaniement des outils pour les langages matériels, j'aimerais vous indiquer notre outil Sigasi HDT. Sigasi fournit un IDE avec un analyseur VHDL intégré et des raffinements VHDL.
Philippe Faes, Sigasi
ANVIL - une autre couche D'Interaction Verilog en parle. Je n'ai pas essayé.
Je n'ai jamais essayé activement TDD sur un design RTL, mais j'ai eu mes pensées là-dessus.
ce qui, à mon avis, serait intéressant, c'est d'essayer cette approche en relation avec les assertions. Vous écririez d'abord sous forme d'assertions ce que vous supposez/attendez de votre module, écrivez votre RTL et plus tard vous pouvez vérifier ces assertions en utilisant des outils formels et/ou simulation. Contrairement aux cas de test "normaux" (où vous devrez probablement écrire des cas dirigés), vous devriez avoir une meilleure couverture et les assertions/hypothèses peuvent également être utiles ultérieurement (par exemple au niveau du système).
cependant je ne me fierais pas entièrement aux assertions, cela peut devenir très délicat.
peut-être Pouvez-vous exprimer vos pensées à ce sujet aussi bien que vous le demandez je suppose que vous portez quelques idées dans votre tête?
Qu'est-ce que TDD pour vous? Voulez-vous dire que tout votre code est soumis à des tests automatiques à tout moment, ou allez-vous jusqu'à dire que les tests sont écrits avant le code et qu'aucun nouveau code n'est écrit à moins que les tests échouent?
quelle que soit l'approche que vous préférez, le test de code HDL n'est pas très différent du test logiciel. Elle a ses avantages (couverture et profondeur des tests bien meilleures) et ses inconvénients (difficiles à mettre en place et encombrants par rapport aux logiciels).
j'ai eu de très bonne expérience avec L'utilisation de transacteurs Python et HDL génériques pour mettre en œuvre des tests complets et automatiques pour les modules HDL synthétisables. L'idée est quelque peu similaire à ce que Janick Bergeron présente dans ses livres, mais au lieu de SystemVerilog, Python est utilisé pour (1) générer du code VHDL à partir de scénarios de test écrits en Python et (2) Vérification des résultats écrits par les transformateurs de surveillance qui acceptent les formes d'onde de la conception pendant simulation.
il y a beaucoup plus à écrire sur cette technique, mais je ne sais pas sur quoi vous voulez vous concentrer.