Si vous supprimez tous les avertissements contenus dans votre conception Verilog ou VHDL? Pourquoi ou pourquoi pas?

Question

Dans le logiciel (régulier) J'ai travaillé dans les entreprises où l'option gcc -Wall est utilisé pour montrer tous les avertissements. Ensuite, ils doivent être traités. Avec la conception FPGA / ASIC non trivial dans Verilog ou VHDL il y a souvent beaucoup d'avertissements. Dois-je craindre tous? Avez-vous des techniques spécifiques à suggérer? Mon flux est principalement pour les FPGA (Altera et Xilinx en particulier), mais je suppose que les mêmes règles s'appliqueraient à la conception ASIC, peut-être plus en raison de l'incapacité de changer la conception après sa construction.

Mise à jour 4/29/2010. Je pensais à l'origine de la synthèse et des avertissements P & R (Ville et Route), mais les avertissements de simulation sont valables aussi

Answer 1

Voici mon point de vue du monde ASIC (99% Verilog, VHDL 1%).

Nous faisons un effort pour éliminer tous les avertissements de nos fichiers journaux, car en général, nous interprétons les avertissements comme l'outil qui nous disent que nous ne devrions pas attendre à des résultats prévisibles.

Comme il existe de nombreux types d'outils qui peuvent générer des avertissements (simulation / débogueur / linter / synthèse / équivalence vérification, etc.), je vais me concentrer cette discussion sur simulateur compilateur avertissements.

Nous analysons les avertissements et les classer en deux groupes principaux: ceux que nous considérons comme n'affectera pas les résultats de notre simulation, et d'autres qui peuvent avoir une incidence sur les résultats. Tout d'abord, nous utilisons les options d'un outil pour permettre explicitement le plus grand nombre possible des avertissements. Pour le premier groupe, nous avons ensuite utiliser les options d'un outil pour désactiver de manière sélective les messages d'avertissement. Pour le deuxième groupe, nous fixons le code source Verilog pour éliminer les mises en garde, nous promouvoir les avertissements à des erreurs. Si des avertissements sont ensuite introduits dans ces catégories, nous nous efforçons de les corriger avant que nous sommes autorisés à simuler.

exception Une à la méthode ci-dessus est pour la propriété intellectuelle de tiers, dont le code Verilog, nous ne sommes pas autorisés à modifier.

Cette méthode fonctionne assez bien pour les simulations RTL, mais il est beaucoup plus difficile lorsque nous courons des simulations de porte à l'aide de SDF back-annoté. Il est tout simplement pas assez de temps pour analyser et éliminer les littéralement des millions d'avertissements. Le mieux que nous pouvons faire est d'utiliser des scripts (Perl) pour analyser les fichiers journaux et classer les avertissements.

En résumé, nous faisons de notre mieux pour éliminer les mises en garde, mais il est pas toujours possible de le faire.

Answer 2

Voici ce que je fais, pour référence. J'inspectent tous les fichiers journaux de l'outil (s).

Pour Altera Quartus II qui comprend la carte, en forme et rapports fusion. Je détournerai l'option Règle de contrôle de conception (DRC) et vérifier ce fichier. Pour certains messages qui sont faciles à fixer, par exemple Port absent de la instanciation ou la largeur constante incorrecte, je les corriger. Autres que j'examiner. Pour ceux qui sont dans les noyaux, par exemple une non-concordance largeur parce que je ne suis pas en utilisant la sortie complète de délibérer, je les marque à supprimer dans le fichier .srf. Je ne supprimer que les messages spécifiques, tous les messages « similaires » car il peut y avoir d'autres, que ce soit maintenant ou dans l'avenir, qui sont des problèmes.

Answer 3

J'ai écrit un script qui applique un ensemble de regexps dans le fichier journal de jeter des lignes que je « connais sont OK ». Il aide, mais vous devez être prudent avec les regexps - ce qui a fait dire à leur sujet jwz:)

Answer 4

La raison la plus importante que je peux penser est non-concordance simulation-synthèse. outils de synthèse font beaucoup d'optimisations (comme ils le devraient à juste titre) et si vous laissez des failles dans votre conception que vous demandez des ennuis. Reportez-vous à la norme IEEE pour plus de détails sur 1364,1 à 2002 la norme de synthèse.

Answer 5

Il n'y a pas besoin d'enlever tous les avertissements, mais tout devrait être revu. Pour que cela soit possible pour les grands modèles, certains avertissements peuvent être supprimées par son type ou l'identifiant.

Par exemple, des outils de synthèse donnent un avertissement si un parameter Verilog est définie et aucune valeur attribuée au cours du module instanciation. Pour moi, cet avertissement est juste un conseil à l'utilisation localparam. Il est une bonne idée de le supprimer par son id (par exemple LINT-01).

Dans certains cas, je veux voir les mises en garde et ne les supprime pas. Par exemple, mon outil donne un avertissement à chaque fois que je définis une horloge virtuelle par des contraintes. L'avertissement ne signifie pas qu'il ya un problème, mais je peux attraper un source manquant d'une horloge qui n'a pas été conçu pour être virtuel.

Parfois, la non-existence de points d'avertissements sur un problème. Par exemple, si je change une variable d'application, il devrait y avoir un avertissement.

Il y a trop de cas. Parfois, l'avertissement est inévitable. Parfois, il est agréable d'avoir des avertissements pour pouvoir examiner certaines choses critiques. Si le concepteur sait ce qu'il / elle le fait, il n'y a pas de problème.

Answer 6

Quelques avertissements sont attendus et il y a un problème si vous ne recevez pas un avertissement.

par exemple si vous voulez vraiment vraiment un verrou, mais il n'y a pas d'avertissement au sujet inférant un verrou alors votre synthèse pourrait ne pas avoir fait ce que vous vouliez.

donc pas, vous ne voulez pas toujours « traiter » avec tous les avertissements.