VHDL: ¿cuándo se activa la lista de sensibilidad del proceso?

En la simulación VHDL, existe un concepto de "tiempo delta", que se interpreta libremente como "grupo de eventos desencadenados por el tiempo delta anterior". Después de un cambio, una vez que se han asentado todos los cambios en cascada y no se generan más eventos de tiempo delta, el tiempo de simulación avanza. (Además, el tiempo de simulación puede avanzar después de N eventos de tiempo delta, ya que existe un límite superior para la longitud de una cascada).

En un proceso dado, ¿cuándo se activa un cambio en la lista de sensibilidad del proceso? ¿Solo se activa cuando el estado de una señal es diferente en un tiempo de simulación en comparación con el tiempo de simulación anterior, o puede activarse como resultado de cualquier evento de tiempo delta? Si se dispara en cualquier tiempo delta, ¿un proceso puede dispararse más de una vez si hay lógica combinatoria efímera?

Considere este ejemplo:

esquemático

simular este circuito : esquema creado con CircuitLab

Digamos que comenzamos con el estado estacionario A=1, B=0, C=1. Además, supongamos que no hay una entidad externa que inspeccione la señal B, es puramente interna.

Ahora, introduce un evento de simulación: A=0.

Esto generará un evento de salida para B=1 y un evento de salida para C=0, para el siguiente tiempo delta. En el siguiente tiempo delta, se generará un nuevo evento de salida para C=1 y no se generarán más eventos, por lo que el tiempo de simulación puede avanzar.

Ahora, digamos que tengo un proceso con C en la lista de sensibilidad. Digamos que este proceso incrementa un contador cada vez que se invoca.

¿Se incrementará ese contador dos veces como resultado de un cambio? Ese sería el caso si los cambios de tiempo delta provocan/disparan/invocan procesos.

¿O ese contador se incrementará cero veces? Ese sería el caso si solo los cambios en el tiempo de simulación provocan/disparan/invocan procesos.

¿O la relación entre el cambio en A y el contador de procesos no está definida? Por ejemplo, si el simulador (o sintetizador, para hardware) optimiza la tabla de verdad NOT-and-XOR, dirá que C siempre es 1, pero si no lo optimiza, puede generar dos cambios para C y por lo tanto desencadenar el proceso dos veces?

Segunda pregunta: ¿Cuál es la palabra correcta que se debe usar para "provocar/activar/invocar" un proceso al cambiar alguna señal en su lista de sensibilidad?

Dos veces. Tal contador funcionaría en simulación pero, por supuesto, sería físicamente irrealizable. No se permite que el simulador optimice la lógica: el hecho de que exponga un error potencial aquí es una característica, ¡no un error!
El uso de un evento de señal como reloj requiere calificación (por ejemplo, si C'event y C = '1' entonces...) que tiene las propiedades místicas de a) solo atrapar un borde, b) ser elegible para síntesis yc) hardware reflectante. La palabra que está buscando es evento, además de comprender la distinción de transacción. Consulte las entradas en el glosario IEEE Std 1076, así como la subcláusula sobre la ejecución de un modelo y su subsección sobre el ciclo de simulación. Además del LRM, pruebe la 3.ª edición de 'The VHDL Designer's Guide' de Peter Ashenden como referencia autorizada.
@Brian Creo que sería apropiado algún tipo de mensaje de pelusa o advertencia, en lugar de llamarlo una característica. Además, ¿por qué ese comportamiento no sería sintetizable? (Estoy tratando de construir un modelo mental robusto aquí).
Usted incrementa los contadores de hardware con bordes de reloj, ya sea 0-> 1 o 1-> 0 pero no ambos, mientras describió operar el contador en ambos que no sintetizan. Un contador impulsado por C contaría pares de transiciones contando los flancos de reloj ascendentes o descendentes. En cuanto a una advertencia, ¿necesitaría una al conectar puertas combinatorias a la salida de, digamos, un contador asíncrono de 4 bits? Piense en la descripción del hardware, no en el software. El ancho de pulso C es el retraso del inversor más cualquier diferencia en el tiempo de subida y bajada. Sin modelar esos retrasos, el ancho del pulso es un ciclo delta. (Una falla).
David respondió muy bien. Este Q/A también puede ayudar. stackoverflow.com/questions/13954193/…
En lugar de preguntar qué haría un simulador, ¿por qué no escribirlo y ejecutarlo en un simulador? ¡Eso te ayudará a construir tu modelo mental robusto!
Investigar los detalles del simulador particular al que tengo acceso solo me dice qué hace ese simulador. No me dirá si la mayoría de los simuladores harán lo mismo, ni por qué.

Respuestas (1)

El tiempo solo avanza cuando ningún evento puede despertar más procesos. Si el proceso "P" es activado por su lista de sensibilidad, se ejecutará en tiempo cero y programará asignaciones de señales, y estas asignaciones pueden activar otros procesos. Si en el siguiente delta (que no avanza en el tiempo) cualquier proceso (incluido él mismo) afecta la lista de sensibilidad de P, entonces P volverá a despertar. Esto sucede tantas veces como sea necesario (o hasta que el simulador se rinda o se haya alcanzado el número máximo de deltas establecido).

En el ejemplo particular de su pregunta con ABC = 101, si tuviera:

process(A,B) begin 
    B <= not A; 
    C <= A xor B;
end process;

process(C) begin
end process;

Cuando Alos cambios a 0, BCse programan con asignaciones de 10. Un delta pasa, Bse convierte 1y vuelve a despertar el proceso, que se programa Cde nuevo a 1. Al final de este segundo delta los valores son 011, y no hay más eventos que puedan despertar el proceso, y cuando no se puede despertar ningún otro proceso, el tiempo avanza.

En consecuencia, process(A,B)se despierta una vez cuando Acambia, y una segunda vez cuando Bcambia. Como resultado, el "contador de activación del proceso" cuenta dos veces.

En el caso de process(C), también se despertará dos veces, porque Cse producirá un "fallo delta" debido a process(A,B).

Sin embargo, si Bestaba implícito:

process(A) begin 
    C <= A xor (not A);
end process;

process(C) begin
end process;

O si Bfuera una variable local:

process(A) 
    variable B : std_logic_vector;
begin 
    B := not A;
    C <= A xor (not B);
end process;

process(C) begin
end process;

Entonces, el proceso (A) solo se despertaría una vez, pero el proceso (C) permanecería suspendido.

Pero mi pregunta era si el proceso de contador se activaría el doble de nuestros lazos cero, o si en realidad no estaba bien definido. Ya describí lo que sucedería con A, B y C.
Técnicamente no se despertará cuando A o B cambien. Se despertará siempre que C cambie; es decir, dos veces, en los ciclos delta DESPUÉS de que A y B cambien, ya que A activa el proceso XOR, que programa un evento en C (y B lo mismo).
@Brian Me refería al proceso (A, B), edité la pregunta para aclarar esto y mencionar explícitamente el proceso (C) también.