En caso de que retire todas las advertencias en el diseño de Verilog o VHDL? ¿Por qué o por qué no?

Question

En el software (regular) He trabajado en empresas donde la opción de gcc -Wall se utiliza para mostrar todas las advertencias. Entonces tienen que ser tratados. Con un diseño no trivial FPGA / ASIC en Verilog o VHDL a menudo hay muchas muchas advertencias. Debería preocuparse de todos ellos? ¿Tiene alguna técnicas específicas para sugerir? Mi flujo es principalmente para FPGAs (Altera y Xilinx en particular), pero supongo que las mismas reglas se aplicarían a diseño ASIC, posiblemente, más aún debido a la incapacidad de cambiar el diseño después de que se construya.

Actualización 4/29/2010:. Estaba pensando en un principio de síntesis y de P & R advertencias (Lugar y Ruta), pero las advertencias de simulación son válidas también

Answer 1

Aquí está mi perspectiva del mundo ASIC (99% Verilog, VHDL 1%).

Hacemos un esfuerzo para eliminar todas las advertencias de nuestros archivos de registro, porque, en general, interpretamos advertencias como la herramienta que nos dicen que no debemos esperar resultados predecibles.

Puesto que hay muchos tipos de herramientas que pueden generar advertencias (simulación / depurador / desfibradora / síntesis / equivalencia de comprobación, etc.), que se centrará la discusión en simulador de compilador advertencias.

Analizamos las advertencias y clasificarlas en dos grandes grupos: los que consideramos no afectará a los resultados de nuestra simulación, y otros que pueden afectar los resultados. En primer lugar, utilizar las opciones de una herramienta para permitir explícitamente como muchas advertencias como sea posible. Para el primer grupo, que a continuación, utilizar las opciones de una herramienta para desactivar selectivamente los mensajes de advertencia. Para el segundo grupo, fijamos el código fuente Verilog para eliminar las advertencias, entonces la promoción de las advertencias de errores. Si las advertencias se introducen después en esas categorías, nos obligamos a solucionarlos antes de que se nos permite simular.

Una excepción a la metodología anterior es para IP de terceros, cuyo código Verilog no se nos permite modificar.

Este método funciona bastante bien para simulaciones RTL, pero se hace mucho más difícil cuando corremos simulaciones utilizando puerta posterior SDF-anotada. Simplemente no hay suficiente tiempo para analizar y eliminar los literalmente millones de advertencias. Lo mejor que podemos hacer es usar scripts de Perl () para analizar los archivos de registro y categorizar las advertencias.

En resumen, hacemos todo lo posible para eliminar las advertencias, pero no siempre es práctico hacerlo.

Answer 2

Esto es lo que hago, para referencia. Inspecciono todo los archivos de registro de la herramienta (s).

Para Quartus II II que incluye los informes de mapa, en forma y combinación. También activa la opción Design Rule Check (RDC) y comprobar que el archivo. Para algunos mensajes que son fáciles de fijar, por ejemplo, puerto que falta de la creación de instancias o anchura constante incorrecto, puedo solucionarlos. Otros me miran a. Para los que están en los núcleos, por ejemplo un desajuste ancho porque no estoy usando la salida completa deliberar, los marco a ser suprimida en el archivo .srf. Sólo suprimirán los mensajes específicos, no todos los "mensajes similares" ya que puede haber otros, ya sea ahora o en el futuro, que son problemas.

Answer 3

Me escribió un script que se aplica un conjunto de expresiones regulares al archivo de registro de tirar líneas que yo "sé que están bien". Es útil, pero hay que ser un poco cuidadoso con las expresiones regulares - lo que hizo JWZ decir de ellos:)

Answer 4

La razón más importante que se me ocurre es desajuste de simulación-síntesis. herramientas de síntesis hacen un montón de optimizaciones (ya que justamente debería) y si se deja lagunas en su diseño que está buscando problemas. Consulte IEEE 1364,1-2.002 para los detalles sobre el estándar de síntesis.

Answer 5

No hay necesidad de eliminar todas las advertencias, pero todo debe ser revisado. Para hacer esto posible para los diseños grandes, algunas advertencias pueden ser suprimidas por su tipo o valor de id.

Por ejemplo, algunas herramientas de síntesis dar una advertencia si se define una parameter Verilog y ningún valor asignado durante la creación de instancias módulo. Para mí, esta advertencia es sólo un consejo para el uso localparam. Es una idea buena para suprimirla por su id (por ejemplo PELUSAS-01).

En algunos casos, quiero ver las advertencias y no suprimirlos. Por ejemplo, mi herramienta da un aviso cada vez que definen un reloj virtual por las restricciones. La advertencia no significa que hay un problema, pero puede coger un source falta de un reloj que no estaba destinado a ser virtual.

A veces no existencia de advertencias puntos fuera un problema. Por ejemplo, si cambio de una variable de aplicación, debe haber una advertencia.

Hay demasiados casos. A veces, la advertencia es inevitable. A veces es bueno tener advertencias para poder revisar algunas cosas crítico. Si el diseñador sabe lo que él / ella lo hace, no hay ningún problema.

Answer 6

Se espera que unos advertencias y no es un problema si usted no recibe una advertencia.

Por ejemplo, si realmente quiere un pestillo pero no hay ninguna advertencia sobre inferir un pestillo entonces su síntesis no podría haber hecho lo que pretende.

Así que no, que no siempre quieren 'acuerdo' con todas las advertencias.