SystemVerilog a ajouté des paquets pour fournir des espaces de noms pour les pièces de code communes (fonctions, types, constantes, etc.). Mais comme les packages ne sont pas instanciés, ils ne peuvent pas être paramétrés, il est donc problématique des membres paramétrés. Dans la pratique, j'ai trouvé cette assez limite depuis que, très souvent, mes types personnalisés ont des paramètres dictant des largeurs de champ, etc.
i Généralement je traite généralement en utilisant des paramètres avec des valeurs par défaut et simplement comprendre que je devrai recommencer à changer la source de paquet. code pour certaines applications, ce qui me semble très mal. Mais je n'ai pas encore trouvé un moyen de gérer cela plus proprement. Par exemple: P>
package my_pkg;
parameter ADDR_MSB = 7;
parameter DATA_MSB = 31;
typedef struct {
logic [ADDR_MSB:0] address;
logic [DATA_MSB:0] data;
} simple_struct_t;
endpackage
7 Réponses :
Ouais, je suis d'accord. C'est une caractéristique manquante des paquets.
Juste Spitballin 'Ici, mais vous pouvez abstraire vos paramètres dans un package de seconde et utilisez-en la bonne au moment de la compilation pour modifier votre colis. Je sais que ce n'est pas ce que vous voulez vraiment, mais cela pourrait vous rapprocher.
Je pense que je me retrouverais avec plusieurs packages représentant chaque configuration si je suis confronté à cela dans mon projet.
J'ai quelques pensées. Premièrement, je me pencherais vers la modélisation de mes données à l'aide de classes au lieu des structures. Les classes peuvent être paramétrées, allouées de manière dynamique, randomisée, contiennent des groupes de couvertures, etc. Je n'utilise que des structures lorsque je veux une structure emballée. Les structures emballées sont merveilleuses car vous pouvez leur affecter comme un vecteur régulier, puis accéder aux données à l'aide des champs nommés. Très agréable. :)
second, même s'il était possible de redéfinir les paramètres de l'emballage, il n'y a qu'une seule "instance" d'un package dans une simulation; Il peut y avoir plusieurs spécialisations avec différentes valeurs de paramètres tels que des modules ou des classes. Donc, il me semble que tout faire avec le paramètre et utiliser une macro est plutôt une solution réalisable. Bien que je n'aime pas utiliser les macros, cela vous permettrait de recompiler avec de nouvelles valeurs sans modifier le code source.
Assez juste, mais j'étais plus intéressé par le code de conception plutôt que le code TestBench, et les classes de date ne sont pas synthétisables.
Également lié au commentaire macro, je ne vois pas comment cela change vraiment quoi que ce soit. En utilisant des macros ou des paramètres, vous pouvez modifier le code pour redéfinir ou modifier la valeur à l'heure de la compilation. En fait, pour les paramètres, cette variation de valeur peut être différée à l'heure d'élaboration qui est un peu plus flexible. Dans les deux cas, il est possible que le code déroutant puisque la valeur utilisée serait non évidente pour un critique.
Je ne dirais pas que c'est une fonctionnalité manquante. Ce que vous essayez de faire a été fait avec des macros à Verilog depuis des décennies. Le problème est que vous devez être plutôt unique dans la façon dont vous nommez des choses pour éviter les affrontements entre les colis. Ce n'est pas bien, mais ça marche.
Les paramètres sont un peu différents. Ils sont destinés à la personnalisation d'une instance par exemple (comme les génériques VHDL). Soit sur des modules pour la logique ou les classes pour les bancs d'essai. Ma seule critique d'eux est une fois que vous avez commencé à les utiliser, ils ont tendance à se propager tout au long de votre hiérarchie et que la syntaxe n'est pas exactement compacte. Très puissant cependant, et idéal pour la réutilisation du code.
Le problème ici est lié aux types paramétrés utilisés dans différentes zones du même design. Vous pouvez les faire comme je l'ai montré ci-dessus, ou vous pouvez utiliser définit, mais ne fonctionne pas non plus lorsque différentes zones de la conception nécessitent différentes valeurs de paramètres pour le même type (par exemple une largeur d'adresse différente). En théorie, vous pouvez utiliser définir et rappelez-vous de réinitialiser ou de négocier après l'unité de compilation, mais qui s'appuie sur cela, vous demandez des problèmes dans mon expérience.
Cela est définitivement une fonctionnalité manquante! Ajout de capacités dans la langue utilisée uniquement avec un assez horrible abus de macro (par exemple les paramètres de type) permet de faire progressivement des HDLS utilisables ... maintenant si seuls les fournisseurs d'outils ont effectivement soutenu certaines de ces fonctionnalités;)
Ceci peut ou non s'appliquer, selon exactement ce que vous avez à l'esprit à placer dans l'emballage, mais les interfaces peuvent être paramétrées et sont synthétisables si votre outil le supporte.
Il y a un exemple sur http://www.doulos.com/khowwow/ Sysverilog / Tutorial / Interfaces /
Cela devrait être une bonne solution de contournement, mais la spécification a des incohérences. Dans la section Interface, il existe un échantillon indiquant l'accès aux types dans une interface par nom hiérarchique comme My_IFC.INNER_TYPE. Cependant, la syntaxe ne prend pas en charge ceci - regardez le def de data_type et type_identifier dans la syntaxe; Type_Identifier est un nom simple (piloté par la manière dont la résolution de type est traitée). Je pense que Synopsys a peut-être permis de cela, mais la cadence n'a pas été aussi importante il y a environ un an sur ce dernier. Alors utilisez attentivement.
J'ai eu la même question et un collègue a suggéré ce qui suit:
// définit.sv: // mod_sub.sv: < PRE> XXX // mod_top.sv:
Vous pouvez utiliser des macros paramétrées pour nommer un type avec des largeurs particulières: puis, dans votre code, vous pouvez définir la structure dont vous avez besoin: P > `SIMPLE_STRUCT(narrow) narrow1, narrow2;
narrow1.data = 0;
narrow2 = narrow1;
...
Je sais que c'est un post très ancien, mais j'ai eu du mal avec cette question depuis un certain temps. Je crois avoir trouvé une solution appropriée mais je n'ai pas actuellement l'outil d'outils pour vérifier si cela peut synthétiser avec succès.
Voir la section 5.6.7 in: http: // www .sutherland-hdl.com / papiers / 2013-svug-sv_synthesizable-systemverilog_paper.pdf
En utilisant une classe paramétrée statique avec des fonctions statiques, vous pouvez appeler différentes paramétrisations de chaque type de données à la volée et les garder uniques pour chaque instanciation.
Quelqu'un peut-il vérifier qu'il s'agit d'une solution viable? Merci!
Cela fonctionne à Synopsys DC. J'ai déposé une demande d'assistance pour avoir ceci ajouté à la synchronisation.
Je peux voir comment vous pouvez paramétrer des arguments de fonction, mais comment pouvez-vous utiliser cette solution pour paramétrer une structure?