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:
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?
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 A
los cambios a 0
, BC
se programan con asignaciones de 10
. Un delta pasa, B
se convierte 1
y vuelve a despertar el proceso, que se programa C
de 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 A
cambia, y una segunda vez cuando B
cambia. 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 C
se producirá un "fallo delta" debido a process(A,B)
.
Sin embargo, si B
estaba implícito:
process(A) begin
C <= A xor (not A);
end process;
process(C) begin
end process;
O si B
fuera 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.
usuario_1818839
usuario8352
Jon Watte
usuario8352
usuario_1818839
Felipe
Jon Watte