¿Qué significa que el hardware sintetizado a partir del código Verilog sea correcto?

Todos -

Es hora de que intervenga con información de fondo útil y mis propias opiniones.

Primero: el estándar de síntesis RTL Verilog IEEE-1364.1-2002 nunca fue implementado completamente por ningún proveedor, por lo que ninguno de nosotros tenía prisa por actualizar el estándar o proporcionar una versión SystemVerilog del estándar de síntesis. Que yo sepa, el estándar no fue "reemplazado" y acaba de expirar. Que yo sepa, los atributos descritos en el Estándar nunca fueron completamente implementados por ningún proveedor. La única característica útil en el estándar que creo que fue implementada por todos los proveedores fue que se supone que un proveedor debe configurar la macro `define SYNTHESIS antes de leer cualquier código de usuario, de modo que ahora puede usar `ifndef SYNTHESIS - `endif como un reemplazo genérico para los comentarios // synopsys translate_on específicos del proveedor - // synopsys translate_off pragma-comments.

Verilog se inventó como un lenguaje de simulación y nunca tuvo la intención de ser un lenguaje de síntesis. A fines de la década de 1980, Synopsys reconoció que a los ingenieros les gustaba mucho este lenguaje de simulación de Verilog y comenzó a definir un subconjunto del lenguaje que ellos (Synopsys) reconocerían y convertirían mediante síntesis en hardware. Ahora nos referimos a esto como el subconjunto de síntesis RTL, y ese subconjunto puede crecer con el tiempo a medida que los proveedores de herramientas de síntesis descubren formas únicas y creativas de convertir un nuevo tipo de descripción en hardware.

Realmente no hay una "corrección de la síntesis de Verilog definida". Don Mills y yo escribimos un artículo en 1999 titulado "Estilos de codificación RTL que generan discrepancias en la simulación y la síntesis", para advertir a los ingenieros sobre los estilos de codificación legales de Verilog que podrían inferir hardware sintetizado con un comportamiento diferente. http://www.sunburst-design.com/papers/CummingsSNUG1999SJ_SynthMismatch.pdf

Considere esto, si los resultados sintetizados siempre coincidieran con el comportamiento de las simulaciones de Verilog, no habría necesidad de ejecutar simulaciones de puerta. El diseño, como RTL-simulado, sería correcto. Debido a que no hay coincidencia garantizada, los ingenieros ejecutan gate-sims para demostrar que el comportamiento de la puerta coincide con el comportamiento RTL, o intentan ejecutar herramientas de verificación de equivalencia para probar matemáticamente que el código RTL previo a la síntesis es equivalente a los modelos de puerta posteriores a la síntesis. , por lo que no se requieren gate-sims.

En cuanto a la pregunta de bonificación, esto es realmente difícil, porque la semántica de Verilog está bastante bien definida, incluso si la definición es que es una condición de carrera legal.

En cuanto a código bien definido en simulación y síntesis con diferentes resultados, considere:

module code1c (output reg o, input a, b);

  always
    o = a & b;
endmodule

En la simulación, nunca se pasa del tiempo 0. La simulación se repetirá para siempre debido a la falta de la lista de sensibilidad. Las herramientas de síntesis ni siquiera tienen en cuenta la lista de sensibilidad al inferir la lógica combinacional, por lo que obtendrá una puerta and de 2 entradas y una advertencia sobre los elementos faltantes de la lista de sensibilidad que podrían causar una falta de coincidencia entre las simulaciones previas y posteriores a la síntesis. En Verilog-2001 agregamos always @* para evitar este problema común, y en SystemVerilog agregamos always_comb para eliminar la lista de sensibilidad e informar a la herramienta de síntesis de la lógica prevista por el diseñador.

En cuanto a si el documento debería ofrecer garantías sobre el comportamiento de síntesis correcto, probablemente no debería, pero las garantías descritas en mi documento definen lo que un ingeniero puede esperar de una herramienta de síntesis basada en la experiencia con múltiples herramientas de síntesis.

"Como nota final, la sección a la que se hace referencia en el párrafo anterior dice que las asignaciones de bloqueo se pueden usar para calcular el RHS de la asignación que no es de bloqueo. Esto parece violar la recomendación n.º 5 de Cummings".

Tiene razón, esto viola la pauta de codificación n.º 5 y, en mi opinión, no debe usarse.

La directriz de codificación n.º 5 se infringe con frecuencia en los diseños de VHDL porque las variables de VHDL no pueden desencadenar otro proceso. Encuentro que el campo VHDL está dividido uniformemente sobre este tema. La mitad dice que no debe usar asignaciones de variables y la otra mitad usa variables para mejorar el rendimiento de la simulación, pero luego se requiere que mezcle las asignaciones de variables con una asignación de señal final para activar otros procesos.

Si viola la pauta de codificación n.º 5 y su código es correcto, la simulación funcionará y la síntesis también funcionará, pero si tiene algún error en su código, es muy difícil depurar diseños que violen la pauta de codificación n.º 5 porque el la visualización de forma de onda para la pieza combinacional no tiene sentido. La salida de la lógica combinacional en una pantalla de forma de onda solo se actualiza cuando no se afirma el restablecimiento y en un borde de reloj, que no es cómo se comporta el hardware combinacional real, y esto ha demostrado ser un problema difícil al depurar estos diseños usando pantallas de forma de onda (I no incluyó esta información en el documento).

Saludos - Cliff Cummings - Verilog y SystemVerilog Guru

Creo que la razón por la que se sintetizará correctamente es porque en el silicio real no hay diferencia entre 'bloquear' y 'no bloquear'.

Synthesis leerá eso y creará tres chanclas encadenadas espalda con espalda, como lo describiste.

Esto no será un problema en síntesis (asumiendo que no estás violando el tiempo de espera del flop), porque las puertas reales exhiben retrasos. En el flanco ascendente de clk, tomará varios ns para el valor d para propagar a q1. Para el momento d se propaga a q1, q1 ya habrá sido muestreado por el segundo flop, de manera similar con q2 e q3.

La razón por la que esto no funciona en la simulación es porque no hay retrasos en la puerta. En el borde positivo del reloj, q1 será reemplazado instantáneamente por d, posiblemente antes q1 fue muestreado por el segundo fracaso. En un circuito real (con la configuración adecuada y el tiempo de espera), q1 se garantiza que se muestreará en el borde positivo del reloj antes de que el primer flop pueda cambiar su valor de salida.

Sé que tiene 3 años, pero tu publicación se marcó cuando alguien intentó editarla. La respuesta de Cliff es, por supuesto, completa, pero en realidad no responde a su pregunta. La otra respuesta también es simplemente incorrecta.

Mi pregunta: ¿Cómo se define la corrección de la síntesis de Verilog si no es por referencia a la semántica de simulación?

Tienes razón, por supuesto. La síntesis solo es 'correcta' si (a) el resultado (salida) se simula de la misma manera que el original (entrada), posiblemente después de tener en cuenta algunos problemas de tiempo/etc., y/o (b) la salida del sintetizador puede ser formalmente resultó ser equivalente a la entrada del sintetizador.

dar el programa Verilog más simple posible que tiene una semántica de síntesis bien definida y no tiene una semántica de simulación bien definida

En principio, esto no debería ser posible. Los proveedores de sintetizadores intentaron definir plantillas que se basaban en un código que tenía una semántica de simulación bien definida. Sin embargo, Verilog estaba (y está) mal definido, y los NBA inicialmente no existían en el idioma, por lo que tiene rarezas como el ejemplo de canalización. Lo mejor es olvidarse de ellos.

De hecho, ¿alguien puede darme una parte de Verilog que esté bien definida cuando se simula y se sintetiza, pero los dos producen resultados diferentes?

La única definición de 'bien definido' (en contraposición a 'correcto') en síntesis es que varios proveedores producirán exactamente el mismo resultado incorrecto. Esto es bastante improbable. Supongo que el restablecimiento asíncrono clásico e async set clocked F/F estaría cerca.