Revisamos cada una de las reseñas en nuestro sitio web con la meta de enseñarte en todo momento la información con la mayor veracidad y actual.
Estos son los tipos de arquitectura:
Comportamiento:
Notas generales:
- Tradicionalmente, no hay jerarquía (solo un archivo, ningún componente instanciado), aunque esto varía entre las herramientas.
- Muy rápido de simular.
- Se definen los comportamientos de las señales.
- Cuando se usa el comportamiento solo para simulación, puede contener código no sintetizable. El comportamiento destinado a la síntesis debe ser sintetizable de forma natural.
Notas específicas de Xilinx
- Generalmente, los modelos de generador de núcleo son archivos .vhd de pre-síntesis
Estructural:
Definición general
- Solo crea instancias de componentes y los conecta (jerárquicamente).
- Más lento de simular que conductual.
- No hay una definición real del comportamiento de la señal en el nivel superior.
- Solo código sintetizable.
Notas específicas de Xilinx x
- Los modelos de generador central no tienen en cuenta el tiempo.
- Generalmente, los modelos de generador central crean instancias de listas de red posteriores a la síntesis
Los anteriores son básicamente los dos animales principales tradicionales de la arquitectura. Muy comúnmente un “mixed”Se utiliza la definición, que contiene propiedades de ambos.
RTL:
RTL lo que realmente se pone en la FPGA al final del día. Entonces, este es un código sintetizable que define el comportamiento del sistema y está compuesto por una jerarquía de código:
Las capas inferiores serán conductuales sintetizables, donde se define el meollo del comportamiento de la señal, y los niveles superiores serán estructurales, donde los componentes conductuales se unirán para crear un gran “diagrama de bloques” de nivel superior, si se quiere.
Sobre múltiples arquitecturas:
Las arquitecturas pueden estar todas en un archivo o en varios archivos. Lo único importante es que primero se compila la entidad y se especifica la arquitectura a utilizar.
Este libro es muy útil y detalla bastante bien este tipo de cosas.
No existe una regla estricta sobre cómo se deben hacer las cosas en términos de tener distintos modelos de comportamiento y estructurales o simplemente mezclarlos. Por lo general, en grandes diseños de firmware (o en 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 se reduce a lo que funcione para usted.
Al observar una entidad, ¿cómo se puede determinar el modelo arquitectónico real que se está utilizando sin pistas del nombre de la arquitectura?
No puedes – cuando es instanciado o configurado se puede especificar la arquitectura (si hay más de una para elegir) o se elegirá una por defecto.
Si especifica varias arquitecturas para una sola entidad (que entiendo que es posible), ¿simplemente le da a las arquitecturas nombres diferentes 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 piensas sobre lo que hay en cada archivo)
¿Los nombres de la arquitectura se limitan a una entidad determinada (es decir, hay algún problema con los “espacios de nombres” al utilizar el mismo nombre de arquitectura en varias entidades)?
Están “adjuntos” a una entidad, por lo que se pueden reutilizar.
Yo uso a menudo a1 como mi arquitectura para todo lo que se puede sintetizar como
rtlimplica un nivel más bajo (para muchos lectores) del que escribo.behaviourala menudo implica no sintetizable (para algunos lectores)synthes usado por el sintetizador para su modelo (de lo contrario lo habría usado)
a1 no ha tenido conflictos hasta ahora y no causa confusión;)
Si en realidad tengo más de una arquitectura, tiendo a nombrarlas de manera prolija (por ejemplo hard_multipliers y lut_multipliers para un filtro que instancia, o no, bloques MUL18).
Muy a menudo, solo tiene una arquitectura, por lo que no importa. Los buenos nombres de entidades son mucho más importantes.
Parece que hay una distinción entre RTL y conductual, pero como se mencionó anteriormente, realmente no lo veo en los ejemplos que he visto (a menudo solo veo una arquitectura definida). ¿Es una arquitectura más común que las demás?
Es histórico, no solía poder sintetizar código “conductual” (que en un momento incluía cosas como agregar), por lo que creó una versión RTL que instanciaba sumadores y similares. (Eso es lo que tengo entendido: he estado escribiendo código conductual (y aún sintetizable) desde que comencé con VHDLing aproximadamente en 1999).
En primer lugar, los diseños de arquitectura del mundo real no se pueden categorizar estrictamente así. ¿Por qué limitarse? Es posible que desee crear una instancia de otras entidades y conectarlas “estructuralmente”, pero agregue un proceso o una asignación simultánea aquí y allá para agregar algo de lógica “rtl”, y tal vez use algunos patrones de codificación “conductuales” para que el sintetizador descubra algunos de los detalles que no le interesan (como agregar sin instanciar específicamente un sumador con parámetros de área / canalización / rendimiento), todos en la misma arquitectura.
Más importante aún, debe comprender qué se puede sintetizar en las tecnologías asic / fpga actuales y qué no, y esto es independiente del modelo de arquitectura.
Una entidad se puede implementar de varias formas, 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 resultar útil cuando se realizan pruebas en bancos de pruebas de diseños grandes en su conjunto. Le daría nombres a estas arquitecturas que lo ayuden a recordar qué las hace diferentes a las demás, y simplemente bhv / str / rtl generalmente no es suficiente o preciso, 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. Simplemente use diferentes nombres para arquitecturas para la misma entidad.
Las arquitecturas pueden residir en diferentes archivos, solo necesita asegurarse de que la declaración de entidad se compile primero.
Puede seleccionar qué arquitectura usar al crear una instancia de la entidad o usar declaraciones de configuración. Si no lo hace, el valor predeterminado es “generalmente” la última arquitectura que el compilador vio para una declaración de entidad determinada.
Reseñas y calificaciones del artículo
Recuerda que puedes permitirte decir si te fue de ayuda.