¿Cuál es el propósito de la simulación previa a la síntesis?

El propósito principal de la simulación de síntesis previa es verificar la funcionalidad lógica de su diseño, sin preocuparse por los detalles de tiempo específicos de una implementación en particular.

Esto ahorra mucho tiempo en el ciclo de depuración funcional, ya que no es necesario esperar a que se complete el proceso de síntesis antes de simular nuevamente después de realizar un cambio.

Una vez que el diseño funciona correctamente con los retrasos "nominales" o "unitarios", puede ejecutar las herramientas de síntesis y verificar que continúe funcionando con los retrasos de tiempo reales. Solucionar los problemas en esta etapa y tratar con rutas críticas largas generalmente requiere menos iteraciones, lo cual es bueno ya que cada iteración lleva más tiempo.

Pero, de hecho, muchos diseños nunca se toman a través de la simulación posterior a la síntesis. A menudo, es suficiente usar la simulación de síntesis previa para verificar la funcionalidad y las herramientas de análisis de tiempo estático para verificar el tiempo de síntesis posterior.

Con respecto a su edición posterior, si el orden de las instrucciones de bloqueo alguna vez importa, entonces probablemente no esté haciendo algo bien.

Una de las diferencias clave entre la simulación y la realidad con la que frecuentemente tropiezo es la especificación de listas de sensibilidad para procesos. El simulador siempre tomará la lista de sensibilidad literalmente, porque esto es importante para hacer que el simulador funcione de manera eficiente. Sin embargo, a las herramientas de síntesis y al hardware real no les importan las listas de sensibilidad (aunque algunas herramientas de síntesis le darán una advertencia si parece haber un problema): si cambia una señal, esos cambios se propagarán a través de la lógica, independientemente de la lógica. Lo que podría decir la lista de sensibilidad.

El significado del lenguaje es el mismo, la diferencia es, de hecho, si el diseño debe ser sintetizable.

La simulación previa a la síntesis supone un hardware ideal, con retrasos de propagación constantes, por lo que no reflejará con precisión un componente que se divide en dos partes con una interconexión larga entre ellas. Por otro lado, esa simulación es bastante barata y no es necesario realizar una compilación completa de antemano.

Esto se puede usar para pruebas funcionales de unidades individuales que deberían ser sintetizables en muchos dispositivos diferentes (es decir, la mayoría de los componentes reutilizables).

La simulación posterior a la síntesis utiliza el modelo de hardware para la temperatura, el voltaje del núcleo, el grado de velocidad, etc., y para proporcionar un resultado significativo, debe conocer la ubicación. Esta es una gran ayuda para la depuración, especialmente cuando se escriben restricciones de tiempo.

No estoy seguro de lo que quieres decir al ejecutar Verilog en diferentes modos. Supongo que te refieres a simular la RTL y el código sintetizado y que estás hablando de simulación funcional (es decir, se ignora la sincronización distinta del nivel de ciclo).

El propósito de ejecutar simulaciones de nivel RTL es que es más rápido de simular, más fácil de depurar y más fácil de modificar. Del mismo modo que trabajar con un lenguaje de programación de alto nivel se compara con trabajar con un ensamblador.

Además, puede usar código no sintetizable para que algo funcione con fines de prueba o evaluación, incluso cuando el diseño completo no está listo o las bibliotecas no están disponibles.

Idealmente, por supuesto, tanto RTL como el nivel de puerta darían los mismos resultados.

Puedes usar las herramientas de pelusa para descubrir muchos escenarios de discrepancia. Muchos simuladores modernos también le avisarán (aunque puede que se ahogue en las advertencias).

Los desajustes de RTL / puerta combinados con una simulación de nivel de puerta lenta dieron lugar a herramientas de verificación de equivalencia.

Hay muchos problemas de estilo de codificación (consulte el artículo de Cliff), pero muchos pueden evitarse mediante el uso de comprobadores de pelusa.

El uso de 'x' puede ser útil en RTL, por ejemplo, para descubrir problemas de reinicio. Sin embargo, se debe tener cuidado para asegurarse de que este tipo de cosas no formen parte del diseño real. El uso de cualquier código de diseño que se base o enmascara las x es definitivamente peligroso.

El uso de directivas (caso completo, paralelo, traducción on / off) merece un examen adicional.

Dejando a un lado la diversión vagamente relacionada (que no era tan divertida en ese momento), hace muchos años trabajé en un verificador de equivalencia comercial de prelanzamiento que un cliente estaba usando para reducir la dependencia en la simulación de nivel de puerta. Alrededor de su primera cinta, descubrí un error en la herramienta que vinculaba algunas "x" a cero por error y, para mi disgusto, descubrí que el comportamiento correcto del bloque dependía de que el valor fuera cero, aunque la síntesis era libre de elegir (ya que los diseños supuestamente eran equivalentes). Hice una llamada frenética a nuestro EA que notó el cable flotante en la colocación y lo ató a suelo, 'solo porque estaba cerca'! Cerrar llamada.

He hecho algunos diseños verilog para FPGA utilizando Xilinx ISE 14.7 con muchas capas de módulos anidadas jerárquicas, y encuentro que la depuración es mucho más difícil en la post-síntesis.

La simulación previa a la síntesis (también llamada simulación de comportamiento) conserva los nombres de red jerárquicos, por lo que es relativamente fácil profundizar en un módulo de nivel inferior específico para inspeccionar su comportamiento.

Sin embargo, después de la síntesis, todo el diseño se convierte en una gran masa plana de registros y lógica combinacional. Suponiendo que las redes interesantes no se hayan optimizado, pueden haber sido invertidas o renombradas de otra manera.

La simulación previa a la síntesis (comportamiento) proporciona una representación idealizada que sigue de cerca la estructura descrita por el código. Si el diseño no funciona correctamente en esta etapa, tampoco funcionará después de la simulación.

La simulación posterior a la síntesis brinda la mejor representación de lo que realmente hará el hardware, pero es relativamente más tiempo y esfuerzo obtener resultados útiles.

En muchos casos (para diseños basados en FPGA) es más barato y más sencillo pasar directamente de la síntesis exitosa a las pruebas en hardware FPGA. Si el diseño se verifica en el FPGA, ya está hecho. La simulación posterior a la síntesis solo es necesaria como un diagnóstico si hay problemas que no se pueden entender al observar las señales externas.