Il n'y a rien de mal à utiliser des entiers pour RTL soi , mais il y a des raisons pour lesquelles certains l'évitent. C'est vraiment une question sur les "meilleures pratiques" subjectives et vous devrez éventuellement découvrir vous-même ce que vous préférez. Pour vous aider, je partagerai mon expérience et mes réflexions à ce sujet.
Principalement , je suis en faveur de l'utilisation d'entiers (contraints), également lors de l'écriture pour la synthèse. Je le fais parfois, mais en pratique , je m'en tiens généralement à signed
et unsigned
. Je vais expliquer pourquoi.
Vous serez de toute façon obligé d'utiliser des types de données vectorisés dans une partie de votre conception:
Pratiquement aucun IP fournisseur ou IP tiers n'utilisera de integer
type pour les ports
Par exemple, lors de l'envoi de données via BlockRam, même si vous en déduisez et que vous n'avez donc jamais besoin de vous connecter à une IP / macro / primitive, vous devrez de toute façon probablement convertir en type vectorisé
Même si aucun des éléments ci-dessus ne s'applique, vous devrez principalement vous connecter à autre chose à un moment donné (un port de niveau supérieur, si rien d'autre)
Puisque vous ne pouvez pas utiliser integer
pour la conception complète, vous voudrez peut-être tout ignorer ensemble, car:
À certains moments, vous devrez quand même effectuer les conversions, ce qui enlève une partie du point d'utilisation integer
en premier lieu
De plus, pour la simulation, ces conversions seront généralement appelées avec des vecteurs de 'U'
ou 'X'
, soit avant la réinitialisation, soit à d'autres moments, et chaque appel de fonction générera un message d'avertissement à partir de la fonction de package, encombrant vos avertissements / invite de simulation
Inconvénients de l'utilisation integer
:
Contrairement aux types vectorisés, les entiers n'ont pas 'U'
et'X'
; Je les trouve très utiles dans les simulations. Vous voyez comment les signaux non initialisés se propagent à travers la conception, et vous réagirez probablement si vous voyez beaucoup de signaux non initialisés après la réinitialisation. Ce ne sera pas le cas si vous utilisez des entiers.
Avec les entiers, il y a un plus grand risque de mauvaise correspondance de simulation / synthèse lors de l'ajout ou de la soustraction entraînant un sous-dépassement / dépassement. (Comme l'a déjà souligné quelqu'un d'autre.)
Cas typiques où je trouve integer
vraiment une bonne option:
Pour les signaux / compteurs de débogage que vous surveillez via chipScope / signalTap, etc.
Représentation totalement interne des compteurs, qui n'entrent ni ne sortent jamais de votre propre code. Oui, il y a de tels cas, par exemple , si vous écrivez un FIFO et vous êtes écrit / lit à l' estime pour former les signaux full
, empty
, almostFull
etc. (cependant sur les pointeurs Arithmétique est une meilleure façon que mort à l' estime dans ce cas. ..)
Mes propres conclusions: j'utilise des entiers parfois, mais avec parcimonie, et surtout dans les cas décrits ci-dessus. Je ne vois pas beaucoup de frais généraux en utilisant unsigned
et signed
au lieu d'entier, et par conséquent, je m'en tiens généralement à eux.