¿Relación entre el ciclo delta y la programación de eventos en la simulación verilog?

Entiendo que en los estándares de Verilog/SystemVerilog existen diferentes regiones para la programación de eventos, lo que imita el comportamiento del hardware concurrente. Pero, ¿cómo se relaciona esto con los ciclos delta que veo en los simuladores (como expandirse en un momento específico para ver las señales actualizándose en diferentes ciclos)?

Solo puedo encontrar conceptos de ciclo delta definidos en simulaciones VHDL, no Verilog. ¿Alguien puede explicar estos dos conceptos?

No estoy seguro de que encuentre algo tan claro como el concepto del ciclo delta en Verilog. Lo más cercano que se me ocurre es [esta discusión][1] que solo me deja aún más confundido cada vez que lo leo. [1][ sunburst-design.com/papers/…
Gracias Brian, ese documento es un clásico y lo he leído antes de publicar esta pregunta. Pero solo explica las cosas desde el punto de vista estándar de ieee.
Esperaba que escucharas de un experto en Verilog sobre esto, soy estrictamente un tipo de VHDL.

Respuestas (1)

"Los ciclos delta son un concepto HDL utilizado para ordenar eventos que ocurren en tiempo físico cero". sigasi.com

Tomando la definición de Sigasi, lo que VHDL llama ciclos de retraso, Verilog llama a un planificador. La forma en que VHDL y Verilog determinan el orden de los eventos de tiempo cero es muy diferente.

VHDL es un simulador determinado donde ordena eventos de tiempo cero actualizando todo (valores del ciclo anterior) antes de evaluar cualquier cosa en cada paso de tiempo.

Verilog es un simulador indeterminado en el que ordena eventos de tiempo cero mediante el uso de un programador priorizado con cinco regiones (Nota: SystemVerilog tiene 17 regiones). Cada región se ejecuta en un orden de prioridad. Los eventos dentro de cada región se pueden ejecutar en cualquier orden. El evento puede programar (no ejecutar) nuevos eventos en cualquier región. Cuando una región termina de ejecutar sus eventos, el programador pasa a la región de mayor prioridad que tiene eventos programados. La región final no programa eventos en el ciclo actual, programa eventos en pasos de tiempo futuros. Las regiones son:

  1. Región activa (antes de cualquier #0):
  • Evaluar y asignar todas las =asignaciones de bloqueo de procedimiento ( ) ( alwaysbloque)
  • Evaluar y asignar todas las asignaciones continuas ( assigndeclaraciones)
  • Evaluar asignaciones sin bloqueo
  • Evaluar entradas y cambiar salidas de todas las primitivas
  • Evaluar y salida $displayy $writellamadas
  1. Región inactiva:
  • Agregue eventos adicionales al programador desde cada bloque de procedimiento hasta el siguiente#0
  • Procedimientos de devolución de llamada programados con rutinas PLI como tf_synchronize()(en desuso en IEEE 1364-2005) yvpi_register_cb(cbReadWriteSynch)
  1. Región de la NBA:
  • Asigne las asignaciones sin bloqueo( <=)
  1. Supervisar región
  • Evaluar y escribir $monitory $strobellamadas
  • Llame a PLI con reason_rosynchronize(obsoleto en IEEE 1364-2005)
  1. Región futura:
  • Programar eventos para que sucedan #N(dónde N>0) en los pasos de tiempo en el futuro

En Verilog, un "ciclo delta" puede seguir el siguiente orden:

Activo⇒Inactivo⇒Activo⇒NBA⇒Activo⇒NBA⇒Inactivo⇒NBA⇒Activo⇒Monitor⇒Futuro
O
Activo⇒Inactivo⇒NBA⇒Activo⇒Monitor⇒Futuro

Puede parecer muy confuso y es posible entrar en un bucle infinito. Es algo que varios blogs de VHDL ( ejemplo ) y artículos declaran una gran falla en Verilog . En realidad, al seguir el estilo de codificación básico de usar solo asignaciones de bloqueo en bloques combinacionales y solo usar asignaciones de no bloqueo en bloques secuenciales, el "ciclo delta" típico de una simulación Verilog RTL se verá así:

Activo (init & clk) ⇒ NBA (actualización de flop) ⇒ Activo (lógica de peine) ⇒ Futuro (programar clk)

La primera región activa es para inicializar y actualizar el reloj. La mayor parte del diseño es NBA (actualizar) y luego Activo (evaluar), la misma ejecución que VHDL. Las otras regiones (incluidas las regiones adicionales de SystemVerilog) existen para el modelado de comportamiento no sintetizable previsto, la vinculación a lenguajes externos (p. ej., C/C++) y bancos de pruebas de verificación.

Agregaré que históricamente la región Inactiva fue creada por diseño. Fue un intento fallido de determinar a qué valor se debe asignar un flop. NBA se creó después y ha sido la solución recomendada desde entonces. Cualquier diseño que todavía use la región Inactiva ( #0retrasos) está siguiendo una práctica que ha sido obsoleta durante aproximadamente 20 años o más.

Desafortunadamente, a pesar de ser una práctica desactualizada durante 20 años, la región inactiva sigue siendo lo único a lo que el VPI da acceso en muchos simuladores; cbReadWriteSynches la mejor opción cuando cbNBASynchno se admite...
¿Relación entre el ciclo delta y la programación de eventos en la simulación verilog?
RespuestasAquíPolítica de privacidad1y, 1v