VHDL: nombre e interpretación de la arquitectura

  

Mirando una entidad, ¿cómo se puede determinar la arquitectura real?   ¿Modelo utilizado sin sugerencias del nombre de la arquitectura?

No se puede - cuando está instanciado o configurado se puede especificar la arquitectura (si hay más de una para elegir) o se elegirá un valor predeterminado para ti.

  

Si se especifican múltiples arquitecturas para una sola entidad (que   Entender es posible) simplemente le das a las arquitecturas diferentes   nombres en el mismo archivo o ...?

Les das diferentes nombres. No tiene que estar dentro del mismo archivo (de hecho, a VHDL le importa mucho menos de lo que podría pensar sobre qué hay en qué archivo)

  

¿Están los nombres de arquitectura limitados a una entidad dada (es decir, es   hay algún problema con los "espacios de nombres" usando la misma arquitectura   nombre sobre múltiples entidades)?

Están "adjuntos" a una entidad, por lo que pueden reutilizarse.

A menudo utilizo a1 como mi arquitectura para todo lo que se pueda sintetizar como

• rtl implica un nivel más bajo (para muchos lectores) del que escribo.
• behavioural a menudo implica no sintetizable (para algunos lectores)
• synth es utilizado por el sintetizador para su modelo (de lo contrario, lo habría usado)

a1 no ha tenido conflictos hasta el momento y no causa confusión;)

Si en realidad tengo más de una arquitectura, tiendo a nombrarlas verbalmente (por ejemplo, hard_multipliers y lut_multipliers para un filtro que crea instancias, o no, bloques MUL18).

Muy a menudo solo tienes una arquitectura, así que no importa. Los buenos nombres de entidades son mucho más importantes.

  

Parece que hay una distinción entre RTL y comportamiento, pero como   mencionado anteriormente No lo estoy viendo realmente en los ejemplos que he visto   (a menudo solo veo una arquitectura definida). Es una arquitectura   ¿Más común que los demás?

Es histórico: no solías poder sintetizar código "de comportamiento" (que en un momento incluía cosas como agregar!), por lo que creaste una versión RTL que creaba instancias de agregados y similares. (Así es como lo entiendo: ¡he estado escribiendo código de comportamiento (y aún así sintetizable) desde que empecé con VHDL en aproximadamente 1999!)

Aquí están los tipos de arquitectura:

Behavioural:

Notas generales:

• Tradicionalmente no hay jerarquía (solo un archivo, no se han creado instancias de componentes) aunque esto varía entre las herramientas.
• Muy rápido para simular.
• Se definen los comportamientos de las señales.
• Cuando el comportamiento se usa solo para simulación, puede contener código no sintetizable. El comportamiento destinado a la síntesis debe naturalmente ser sintetizable.

Notas específicas de Xilinx

• En general, los modelos de generadores de núcleo son archivos .vhd de síntesis previa

Structural:

Definición general

• Solo crea una instancia de los componentes y los conecta (jerárquicos).
• Más lento para simular que el comportamiento.
• No hay definición de comportamiento de señal real en el nivel superior.
• Sólo código sintetizable.

Notas específicas de Xilinx

• Los modelos de generadores principales no tienen en cuenta el tiempo.
• En general, los modelos de generadores de núcleo instancian las listas de redes de síntesis posterior

Los anteriores son básicamente los dos principales animales tradicionales de la arquitectura. Muy comúnmente se usa una definición "mixta", que contiene propiedades de ambos.

RTL:

RTL lo que realmente se pone en el FPGA al final del día. Entonces, este es un código sintetizable que define el comportamiento del sistema y se compone de una jerarquía de código:
Las capas inferiores serán de comportamiento sintetizable, donde se definirá el meollo del comportamiento de la señal, y los niveles superiores serán estructurales, donde los componentes de comportamiento se unirán para crear un gran "diagrama de bloques" de nivel superior, si así lo desea.

En múltiples arquitecturas:

Las arquitecturas pueden estar todas en un archivo o en varios archivos. Lo único importante es que la entidad se compila primero y que se especifica la arquitectura que se usará.

Este libro es muy útil y detalla bastante bien este tipo de cosas.

No existe una regla estricta y rápida acerca de cómo deben hacerse las cosas en términos de tener distintos modelos de comportamiento y estructurales o simplemente mezclarlos. Por lo general, en los grandes diseños de firmware (o en las grandes corporaciones donde el código se comparte y se reutiliza) es útil distinguir entre los dos para simplificar las cosas, sin embargo, al final del día, todo depende de lo que funcione para usted.

En primer lugar, los diseños de arquitectura del mundo real no pueden ser estrictamente categorizados de esa manera. ¿Por qué limitarte? Es posible que desee crear una instancia de otras entidades y conectarlas "estructuralmente", pero agregue un proceso o asignación concurrente aquí y allá para agregar algo de lógica "rtl", y quizás utilice algunos patrones de codificación "de comportamiento" para que el sintetizador descubra algunos de los detalles que no le interesan (como agregar sin crear una instancia específica de un sumador con parámetros de área / canalización / rendimiento), todos en la misma arquitectura.

Y, lo que es más importante, debe comprender qué es sintetizable en las tecnologías asic / fpga actuales y qué no, y esto es independiente del modelo de arquitectura.

Una entidad puede implementarse de varias maneras, incluso permitiendo comportamientos ligeramente diferentes, por lo que puede tener varias arquitecturas para la misma entidad. Además, es posible que tenga una arquitectura solo para simulación (generalmente no sintetizable) que puede simular más rápido que la versión "real", lo que puede ser útil para probar grandes diseños como un todo. Daría a estas arquitecturas nombres que lo ayuden a recordar lo que las hace diferentes de las otras, y simplemente bhv / str / rtl generalmente no es suficiente ni precisa, dada la naturaleza híbrida de los diseños del mundo real.

Con respecto a sus preguntas específicas, la declaración de arquitectura está vinculada a un nombre de entidad, por lo que no hay problemas de espacio de nombres con arquitecturas del mismo nombre para diferentes entidades. Solo use nombres diferentes para arquitecturas para la misma entidad.

Las arquitecturas pueden residir en archivos diferentes, solo debes asegurarte de que la declaración de la entidad se compila primero.

Puede seleccionar qué arquitectura usar al crear una instancia de la entidad o al usar declaraciones de configuración. Si no lo hace, el valor predeterminado es usualmente la última arquitectura que el compilador vio para una declaración de entidad dada.