VHDL: ¿enteros para la síntesis?

Los enteros son buenos en síntesis, los uso todo el tiempo.

  

Uso std_logic en los puertos de nivel superior, pero internamente estaba usando enteros de rango en todo el lugar

Eso está bien!

Ten en cuenta:

• Usted está simulando primero, ¿verdad? :) - Los tipos de enteros no se "reinician" automáticamente en la simulación: es un error salir del rango que ha especificado para ellos. Si desea un comportamiento de renovación, debe codificarlo explícitamente.
• Solo están especificados para ir de \ $ - (2 ^ {31} -1) \ $ a \ $ + 2 ^ {31} -1 \ $ (es decir, no es el rango completo de un entero de 32 bits , no puede usar \ $ - 2 ^ {31} \ $ y permanecer portátil), lo que a veces es un poco molesto. Si necesita usar números "grandes", tendrá que usar unsigned y signed .
• Si no los restringe, puede a veces terminar con contadores de 32 bits donde menos podrían hacerlo (si el sintetizador y las herramientas subsiguientes no pueden "ver" que pueden optimizar los bits). lejos).

Al alza:

• Son mucho más rápidos de simular que los vectores sin firmar / firmados
• No se reinician automáticamente en la simulación (sí, está en ambas listas :). Esto es útil: por ejemplo, obtiene una advertencia temprana de que su contador es demasiado pequeño.

Cuando usas tipos de vectores, estás usando ieee.numeric_std , no ieee.std_logic_arith , ¿verdad?

Utilizo integer s donde puedo, pero si quiero explícitamente "contadores de n bit-roll-over", tiendo a usar unsigned .

Jan Decaluwe escribió un informe completo sobre los problemas de los enteros frente a los vectores de bits. Espero que sus respuestas sean utilizar números enteros siempre que sea posible . enlace

No hay nada de malo en usar enteros para RTL per se , pero hay razones por las que algunos lo evitan. Esta es realmente una pregunta acerca de las "mejores prácticas" subjetivas y, eventualmente, tendrá que descubrir qué prefiere. Como ayuda para eso, compartiré mi experiencia y pensamientos sobre esto.

Principalmente , estoy a favor de usar enteros (restringidos), también al escribir para la síntesis. A veces lo hago, pero en la práctica , por lo general me atengo a signed y unsigned . Voy a explicar por qué.

De todos modos, se verá obligado a utilizar tipos de datos vectorizados en parte de su diseño:

• Casi ningún IP de proveedor o IP de terceros usará el tipo integer para puertos

• Por ejemplo, al enviar datos a través de BlockRam, incluso si lo deduce y, por lo tanto, nunca necesita interactuar con ninguna IP / macro / primitiva, lo más probable es que tenga que convertir a un tipo vectorizado de todos modos

• Incluso si no se aplica ninguna de las opciones anteriores, en su mayoría necesitarás establecer una interfaz con otra cosa en algún punto (un puerto de nivel superior, si no más)

Como no puede usar integer para el diseño completo, es posible que desee omitirlo todo junto, porque:

• En algunos puntos, necesitarás hacer las conversiones de todos modos, y esto elimina parte del punto de usar integer en primer lugar

• Además, para la simulación, estas conversiones normalmente se llamarán con vectores de 'U' o 'X' , ya sea antes del restablecimiento, o en otras ocasiones, y cada una de estas llamadas de función generará un mensaje de advertencia desde Función de paquete, que contiene sus advertencias de simulación / indicaciones

Inconvenientes de usar integer :

• Al contrario de los tipos vectorizados, los enteros no tienen 'U' y 'X' ; Los encuentro muy útiles en las simulaciones. Verá cómo se propagan las señales sin inicializar a través del diseño, y probablemente reaccionará si ve muchas señales sin inicializar después del reinicio. Este no será el caso si se usan números enteros.

• Con los enteros, existe un mayor riesgo de que la simulación / síntesis no coincida correctamente al sumar o restar, lo que resulta en subdesbordamiento / desbordamiento. (Como ya lo señaló otra persona).

Los casos típicos donde encuentro que integer es realmente una buena opción:

• Para señales / contadores de depuración que monitoreas a través de chipScope / signalTap etc.

• Representación totalmente interna de contadores, que nunca entran o salen de su propio código. Sí, hay tales casos, por ejemplo. si está escribiendo un FIFO y está escribiendo / leyendo con recuento muerto para formar las señales full , empty , almostFull etc. ...)

Mis propias conclusiones: a veces uso los números enteros, pero con moderación, y en su mayoría en los casos descritos anteriormente. No veo mucha sobrecarga en el uso de unsigned y signed en lugar de entero, y por lo tanto, usualmente se adhieren a ellos.