VHDL: ¿enteros para síntesis?

Estoy un poco confundido sobre si debería usar enteros en VHDL para señales de síntesis y puertos, etc.

Uso std_logic en los puertos de nivel superior, pero internamente estaba usando enteros a distancia en todo el lugar. Sin embargo, me topé con algunas referencias a personas que dicen que solo debe usar firmado / no firmado para el código de síntesis.

He ido y reelaborado mi proyecto actual para usar sin firmar ... y, bueno, es notablemente más feo.

¿Es una mala práctica usar enteros? ¿Cuál es el problema? ¿Hay alguna incertidumbre sobre el ancho con el que la herramienta asignará enteros?

Los enteros están bien en síntesis, los uso todo el tiempo.

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

¡Esta bien!

Se consciente:

• Primero está simulando, ¿no es cierto ?: los tipos enteros no se "vuelcan" automáticamente en la simulación; es un error salir del rango que especificó para ellos. Si desea un comportamiento de transferencia, debe codificarlo explícitamente.
• $-(2^{31}-1)$$+2^{31}-1$$-2^{31}$unsignedsigned
• Si no los restringe, a veces puede terminar con contadores de 32 bits donde lo haría menos (si el sintetizador y las herramientas posteriores no pueden "ver" que podrían optimizar los bits).

En la parte de arriba:

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

Cuando usa tipos de vectores, está usando ieee.numeric_std, ¿ noieee.std_logic_arith es así?

Utilizo integers donde puedo, pero si quiero explícitamente "contadores de n bits de transferencia", tiendo a usarlos unsigned.

Jan Decaluwe escribió un libro blanco completo sobre los problemas de los enteros frente a los vectores de bits. Espero que sus respuestas sean usar números enteros siempre que sea posible . http://www.jandecaluwe.com/hdldesign/counting.html

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 la "mejor práctica" subjetiva y eventualmente tendrás que descubrir por ti mismo lo que prefieres. Como ayuda para eso, compartiré mi experiencia y pensamientos sobre esto.

Principalmente , estoy a favor de usar enteros (restringidos), también cuando escribo para síntesis. A veces lo hago, pero en la práctica , generalmente me quedo con signedy unsigned. Explicaré por qué.

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

• Casi ninguna IP de proveedor o IP de terceros utilizará el integertipo para puertos

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

• Incluso si ninguno de los anteriores se aplica, en su mayoría necesitará interactuar con algo más en algún momento (un puerto de nivel superior, si nada más)

Dado que no puede utilizar integerel diseño completo, es posible que desee omitirlo todo, porque:

• En algunos puntos, tendrá que hacer las conversiones de todos modos, y esto elimina parte del punto de uso integeren primer lugar

• Además, para la simulación, estas conversiones generalmente se llamarán con vectores de 'U'o 'X', antes del reinicio, o en otros momentos, y cada llamada de función generará un mensaje de advertencia de la función del paquete, abarrotando las advertencias / indicaciones de la simulación

Inconvenientes del usointeger :

• 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 no inicializadas a través del diseño, y probablemente reaccionará si ve muchas señales no inicializadas después del reinicio. Este no será el caso si se usan números enteros.

• Con los números enteros, existe un mayor riesgo de simulación / síntesis de errores de coincidencia al sumar o restar, lo que resulta en un exceso o un desbordamiento. (Como ya lo señaló otra persona).

Casos típicos donde encuentro integerque realmente es una buena opción:

• Para señales / contadores de depuración que supervisa 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 usted está escribiendo una FIFO y que son las escrituras-navegación a estima / lee para formar las señales full, empty, almostFulletc (sin embargo, la aritmética de los punteros es una manera mejor que a estima en este caso. ..)

Mis propias conclusiones: a veces uso enteros, pero con moderación, y principalmente en los casos descritos anteriormente. No veo mucha sobrecarga en el uso unsignedy en signedlugar del número entero, y por lo tanto, generalmente me quedo con ellos.