VHDL: dénomination et interprétation de l'architecture

Remarque: J'utilise l'ISE de Xilinx et j'ai une carte FPGA avec laquelle travailler (avec des commutateurs et des lumières, etc.), et j'ai piraté ensemble quelques projets simples jusqu'à présent. En même temps, je lis plusieurs tutoriels pour jeter les bases de ce que je fais.

J'ai vu diverses entités et leurs architectures mentionnées dans les documents de référence que j'ai consultés, mais la dénomination est souvent déroutante. Souvent au lieu de "architecture rtl de .." ou "architecture structurelle de ..." je verrai "architecture foo de ..." ou même "architecture arch of ..."

Je me rends compte (tardivement) que le nom de l'architecture est tout aussi arbitraire que la dénomination d'entité, bien qu'il existe des guides de style qui suggèrent que des conventions de dénomination plus cohérentes peuvent être utilisées pour éviter ce problème. Cela m'amène à quelques questions:

• En regardant une entité, comment peut-on déterminer le modèle architectural réel utilisé sans indication du nom de l'architecture? RTL, comportemental, structurel ... ils semblent être assez similaires à l'œil de mon apprenant (en supposant que les exemples que j'ai vus étaient en fait nommés correctement). Un exemple simple mais évident serait utile ici (ou un pointeur vers l'un).

• Si vous spécifiez plusieurs architectures pour une seule entité (ce qui, je crois, est possible), donnez-vous simplement des noms différents aux architectures dans le même fichier ou ...?

• Les noms d'architecture sont-ils confinés à une entité donnée (autrement dit, y a-t-il un problème avec les "espaces de noms" en utilisant le même nom d'architecture sur plusieurs entités)?

Modifier: et un de plus:

• Il semble qu'il y ait une distinction entre RTL et comportemental, mais comme mentionné ci-dessus, je ne le vois pas vraiment dans les exemples que j'ai vus (souvent je ne vois qu'une seule architecture définie). Une architecture est-elle plus courante que les autres?

Ce que je cherchais est un projet multi-composants complet mais simple (petits composants), écrit en utilisant les meilleures pratiques (dénomination correcte, pas tous entassés dans un seul fichier, etc.) mais je n'ai pas encore trouvé un. Je trouve que les exemples de projets correctement conçus sont très utiles pour éclairer les principes de base et les meilleures pratiques. Si vous connaissez un tel exemple de projet, je vous serais reconnaissant de bien vouloir également pointer ce point. (Si rien d'autre, peut-être qu'une fois que j'aurai compris cela, je pourrai partager l'un des miens ...)

En regardant une entité, comment peut-on déterminer le modèle architectural réel utilisé sans indication du nom de l'architecture?

Vous ne pouvez pas - lorsqu'elle est instanciée ou configurée, l'architecture peut être spécifiée (s'il y en a plusieurs parmi lesquelles choisir) ou une valeur par défaut sera choisie pour vous.

Si vous spécifiez plusieurs architectures pour une seule entité (ce qui, je crois, est possible), donnez-vous simplement des noms différents aux architectures dans le même fichier ou ...?

Vous leur donnez des noms différents. Il ne doit pas nécessairement se trouver dans le même fichier (en fait, VHDL se soucie beaucoup moins que vous ne le pensez de ce qui se trouve dans quel fichier)

Les noms d'architecture sont-ils confinés à une entité donnée (autrement dit, y a-t-il un problème avec les "espaces de noms" en utilisant le même nom d'architecture sur plusieurs entités)?

Ils sont "attachés" à une entité et peuvent donc être réutilisés.

J'utilise souvent a1comme architecture pour tout ce qui peut être synthétisé

• rtl implique un niveau inférieur (pour de nombreux lecteurs) à celui auquel j'écris.
• behavioural implique souvent non synthétisable (pour certains lecteurs)
• synth est utilisé par le synthétiseur pour son modèle (sinon j'aurais utilisé ça)

a1 n'a pas été en conflit jusqu'à présent et ne cause pas de confusion;)

Si j'ai en fait plus d'une architecture, j'ai tendance à les nommer verbalement (par exemple hard_multiplierset lut_multiplierspour un filtre qui instancie - ou non - des blocs MUL18).

Très souvent, vous n'avez qu'une seule architecture, donc cela n'a pas d'importance. Les bons noms d'entités sont beaucoup plus importants.

Il semble qu'il y ait une distinction entre RTL et comportemental, mais comme mentionné ci-dessus, je ne le vois pas vraiment dans les exemples que j'ai vus (souvent je ne vois qu'une seule architecture définie). Une architecture est-elle plus courante que les autres?

C'est historique - vous n'aviez pas l'habitude de pouvoir synthétiser du code "comportemental" (qui à un moment donné comprenait des choses comme l'ajout!) - vous avez donc créé une version RTL qui instanciait des additionneurs et autres. (C'est ce que je comprends - j'écris du code comportemental (et pourtant toujours synthétisable) depuis que j'ai commencé VHDLing vers 1999!)

Voici les types d'architecture:

Comportemental:

Notes générales:

• Traditionnellement, aucune hiérarchie (un seul fichier, aucun composant instancié), bien que cela varie selon les outils.
• Très rapide à simuler.
• Les comportements des signaux sont définis.
• Lorsque le comportemental est utilisé uniquement pour la simulation, il peut contenir du code non synthétisable. Les comportements destinés à la synthèse doivent naturellement être synthétisables.

Notes spécifiques à Xilinx

• Généralement, les modèles de générateur de base sont des fichiers .vhd de pré-synthèse

De construction:

Définition générale

• Instancie uniquement les composants et les relie (hiérarchique).
• Plus lent à simuler que comportemental.
• Aucune définition réelle du comportement du signal au niveau supérieur.
• Uniquement code synthétisable.

Notes spécifiques à Xilinx

• Les modèles de générateurs de base ne prennent pas en compte le timing.
• Généralement, les modèles de générateurs de base instancient les listes de diffusion post-synthèse

Les éléments ci-dessus sont essentiellement les deux principaux animaux traditionnels de l'architecture. Très souvent, une définition "mixte" est utilisée, qui contient les propriétés des deux.

RTL:

RTL ce qui est réellement mis sur le FPGA à la fin de la journée. Il s'agit donc d'un code synthétisable qui définit le comportement du système et se compose d'une hiérarchie de code:
les couches inférieures seront synthétisables comportementales, où le détail du comportement du signal est défini, et les niveaux supérieurs seront structurels, où le les composants comportementaux sont liés entre eux pour créer un "diagramme" de haut niveau si vous voulez.

Sur plusieurs architectures:

Les architectures peuvent être toutes dans un seul fichier ou dans plusieurs fichiers. La seule chose importante est que l'entité soit compilée en premier et que l'architecture à utiliser soit spécifiée.

Ce livre est très pratique et détaille assez bien ce genre de chose.

Il n'y a pas de règle stricte sur la façon dont les choses devraient être faites en termes de modèles comportementaux et structurels distincts ou simplement de les mélanger. Habituellement, dans les énormes conceptions de micrologiciels (ou dans les grandes entreprises où le code est partagé et réutilisé), il est utile de faire la distinction entre les deux pour simplifier les choses, mais en fin de compte, cela revient à ce qui fonctionne pour vous.

Tout d'abord, les conceptions d'architecture du monde réel ne peuvent pas être strictement catégorisées de cette façon. Pourquoi vous limiter? Vous voudrez peut-être instancier d'autres entités et les connecter "structurellement", mais ajoutez un processus ou une affectation simultanée ici et là pour ajouter une logique "rtl", et peut-être utiliser des modèles de codage "comportementaux" afin que le synthétiseur comprenne certaines des des détails qui ne vous intéressent pas (comme ajouter sans instancier spécifiquement un additionneur avec des paramètres de zone / pipelining / performance), le tout dans la même architecture.

Plus important encore, vous devez comprendre ce qui est synthétisable dans les technologies asic / fpga actuelles et ce qui ne l'est pas, et cela indépendamment du modèle d'architecture.

Une entité peut être implémentée de plusieurs manières, même en autorisant des comportements légèrement différents, vous pouvez donc avoir plusieurs architectures pour la même entité. De plus, vous pouvez avoir une architecture de simulation uniquement (généralement non synthétisable) qui peut simuler plus rapidement que la "vraie" version, ce qui peut être utile lors du test de bancs de grands modèles dans leur ensemble. Vous donneriez à ces architectures des noms qui vous aideront à vous souvenir de ce qui les rend différentes des autres, et simplement bhv / str / rtl n'est généralement pas suffisant ou précis, étant donné la nature hybride des conceptions du monde réel.

Concernant vos questions spécifiques, la déclaration d'architecture est liée à un nom d'entité, il n'y a donc aucun problème d'espace de nom avec les architectures du même nom pour différentes entités. Utilisez simplement des noms différents pour les architectures de la même entité.

Les architectures peuvent résider dans différents fichiers, il vous suffit de vous assurer que la déclaration d'entité est d'abord compilée.

Vous pouvez sélectionner l'architecture à utiliser lors de l'instanciation de l'entité ou à l'aide d'instructions de configuration. Si vous ne le faites pas, la valeur par défaut est «généralement» la dernière architecture que le compilateur a vue pour une déclaration d'entité donnée.