Expériences avec TDD (Test Driven Development) pour la conception de logique (puce) en Verilog ou VHDL

Question

J'ai consulté le Web et les discussions / exemples semblent concerner le développement de logiciels traditionnels. Etant donné que Verilog et VHDL (utilisés pour la conception de puces, par exemple les FPGA et les ASIC) sont similaires aux développements logiciels C et C ++, il semblerait logique. Cependant, leurs différences sont fondamentalement parallèles et nécessitent du matériel pour effectuer des tests complets.

Quelles expériences, bonnes et mauvaises, avez-vous eu? Des liens que vous pouvez suggérer sur cette application spécifique?

Modifications / clarifications: 28/10/09: Je m'interroge particulièrement sur le TDD. Je connais bien les bancs d’essai, y compris les autocontrôles. Je suis également conscient que SystemVerilog possède des fonctionnalités particulières pour les bancs d’essai.

10/28/09: Les questions impliquées comprennent 1) l'écriture d'un test pour une fonctionnalité quelconque, en n'utilisant jamais de formes d'onde pour la simulation et 2) l'écriture d'un test / banc d'essai d'abord.

29/11/09: Dans des études empiriques montrent que le développement piloté par les tests s'améliore Qualité indique-t-il pour le logiciel (TDD) "La densité de défauts avant publication des quatre produits, mesurée en défauts par millier de lignes de code, a diminué entre 40% et 90% par rapport aux projets qui n’utilisaient pas le TDD . La direction des équipes a rapporté de manière subjective une augmentation de 15 à 35% du temps de développement initial des équipes utilisant le TDD, bien que les équipes aient convenu que cela était compensé par une réduction des coûts de maintenance. La réduction du nombre de bogues réduit le risque d’enregistrement, aux dépens d’un impact modéré sur le calendrier. Cette contient également des données.

29/11/09: Je fais principalement du code de contrôle et de transmission de données, pas du code DSP. Pour DSP, la solution typique consiste en une simulation Matlab à précision binaire.

03/02/10: L’avantage du TDD est de vous assurer que le test échoue d’abord. Je suppose que cela pourrait aussi être fait avec des affirmations.

Answer 1

J'écris du code pour les FPGA, pas pour ASICS ... mais TDD reste mon approche préférée. J'aime avoir une suite complète de tests pour tout le code fonctionnel que j'écris et j'essaie (pas toujours avec succès) d'écrire le testcode en premier. Observer les formes d’ondes se produit toujours à un moment donné lors du débogage, mais ce n’est pas un bon moyen de valider votre code (IMHO).

Etant donné la difficulté d'effectuer des tests corrects dans le matériel réel (la stimulation de coins est particulièrement difficile) et le fait qu'une compilation VHDL prend quelques secondes (par rapport à une compilation "au matériel" prenant plusieurs minutes (voire plusieurs heures) ), Je ne vois pas comment quiconque pourrait fonctionner autrement!

Je construis également des assertions dans RTL au fur et à mesure que je l'écris pour comprendre des choses qui, à mon avis, ne devraient jamais se produire. Apparemment, cela est perçu comme un peu "étrange", car il existe une perception selon laquelle les ingénieurs en vérification écrivent des assertions, contrairement aux concepteurs de RTL. Mais surtout je suis mon propre ingénieur de vérification, alors peut-être que c'est pour ça!

Answer 2

J'utilise VUnit pour le développement piloté par les tests avec VHDL.

VUnit est une bibliothèque Python qui appelle le compilateur et le simulateur VHDL et lit les résultats de la simulation. Il fournit également plusieurs bibliothèques VHDL qui facilitent l’écriture de meilleurs bancs d’essai, comme une communication. bibliothèque , bibliothèque de journalisation et un vérification de la bibliothèque .

Il existe de nombreuses possibilités car il est appelé depuis Python. Il est possible à la fois de générer des données de test et de vérifier les données de sortie du test en Python. J'ai vu cet exemple l'autre jour où ils ont utilisé Octave - une copie Matlab - pour tracer les résultats des tests .

VUnit semble très actif et j’ai plusieurs fois pu 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 car il existe de nombreuses variantes de fonctions / procédures portant le même nom dans les bibliothèques. De plus, certaines tâches sont effectuées en arrière-plan en prétraitant le code, ce qui signifie que certaines erreurs peuvent apparaître dans des endroits inattendus.

Answer 3

Les extensions SystemVerilog de la norme IEEE Verilog Standard incluent une variété de constructions qui facilitent la création de suites de tests approfondies pour la vérification de conceptions logiques numériques complexes. SystemVerilog est l’un des les langages de vérification du matériel (HVL) utilisés pour vérifier la puce ASIC conceptions via la simulation (par opposition à l’émulation ou à l’utilisation de FPGA).

Les avantages significatifs par rapport à un langage de conception de matériel traditionnel (Verilog) sont les suivants:

• randomisation contrainte
• assertions
• collecte automatique des données de couverture fonctionnelle et d'assertion

La clé est d’avoir accès à un logiciel de simulation qui prend en charge cette norme récente (2005). Tous les simulateurs ne supportent pas totalement les fonctionnalités les plus avancées.

En plus du standard IEEE, il existe une bibliothèque open source SystemVerilog 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 de test.

Vous pouvez également effectuer davantage de recherches sur le sujet en effectuant une recherche dans Verfication Guild forum.

SystemVerilog n'est pas le seul HVL, et VMM n'est pas la seule bibliothèque. Mais, je recommanderais les deux, si vous avez accès aux ressources appropriées. outils. J'ai trouvé que c'était une méthodologie efficace pour trouver le design bugs avant de devenir silicium.

Answer 4

Je ne connais pas grand-chose à la conception du matériel et des puces, mais je suis un féru de TDD pour pouvoir au moins discuter de l'adéquation du processus avec vous.

La question que j’appellerais la plus pertinente est la suivante: à quelle vitesse vos tests peuvent-ils vous donner des informations sur un modèle? En rapport avec cela: à quelle vitesse pouvez-vous ajouter de nouveaux tests? Et dans quelle mesure vos outils prennent-ils en charge le refactoring (changement de structure sans changement de comportement) de votre conception?

Le processus TDD dépend en grande partie de la "douceur". de logiciels - de bons tests unitaires automatisés exécutés en quelques secondes (quelques minutes à l’extérieur) et guident de courtes rafales de travaux de construction et de refactorisation ciblés Vos outils prennent-ils en charge ce type de flux de travail: alternance rapide entre l'écriture et l'exécution de tests et la construction du système testé en petites itérations?

Answer 5

En ce qui concerne les outils de refactoring pour les langages matériels, j'aimerais vous indiquer notre outil Sigasi HDT . . Sigasi fournit un environnement de développement intégré avec analyseur VHDL intégré et refactorisations VHDL.

Philippe Faes, Sigasi

Answer 6

ANVIL - Une autre couche d'interaction Verilog en parle. Je n'ai pas essayé.

Answer 7

Je n'ai jamais activement essayé TDD sur un design RTL, mais je pensais à ce sujet.

Ce qui, à mon avis, serait intéressant, c’est d’essayer cette approche en liaison avec des assertions. En gros, vous écrivez d'abord sous forme d'assertions ce que vous supposez / attendez de votre module, écrivez votre RTL, puis vous pouvez vérifier ces assertions à l'aide d'outils formels et / ou de simulations. Contrairement à " normal " cas de test (où vous auriez probablement besoin d’écrire des textes dirigés), votre couverture devrait être bien meilleure et les assertions / hypothèses pourraient être utiles ultérieurement (par exemple au niveau du système).

Cependant, je ne me fierais pas pleinement aux affirmations, cela peut devenir très poilu.

Peut-être pourriez-vous aussi exprimer votre opinion à ce sujet, car vous le demandez, je suppose que vous avez des idées en tête?

Answer 8

Qu'est-ce que le TDD pour vous? Voulez-vous dire que tout votre code est soumis à des tests automatiques à tout moment, ou voulez-vous dire que les tests sont écrits avant le code et qu'aucun nouveau code n'est écrit à moins que les tests n'é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 de logiciel. Il présente des avantages (une couverture et une profondeur de tests bien meilleures) et des inconvénients (difficile à configurer et relativement fastidieux par rapport aux logiciels).

J'ai eu une très bonne expérience de l'utilisation de transacteurs Python et HDL génériques pour la mise en œuvre de tests complets et automatiques pour les modules HDL synthétisables. L’idée est un peu similaire à ce que Janick Bergeron présente dans ses livres, mais au lieu de SystemVerilog, Python est habitué à (1) générer du code VHDL à partir de scénarios de test écrits en Python et (2) vérifier les résultats écrits par les transacteurs de surveillance qui acceptent les signaux de la conception pendant la simulation.

Il y a encore beaucoup à écrire sur cette technique, mais je ne sais pas trop sur quoi vous voulez vous concentrer.