Múltiples asignaciones al mismo registro en un bloque RTL con Kansas Lava

Question

Múltiples asignaciones al mismo registro en un bloque RTL con Kansas Lava

Tengo problemas para entender el comportamiento de Kansas Lava cuando un bloque RTL contiene varias asignaciones al mismo registro. Aquí está la versión número 1:

foo :: (Clock c) => Signal clk Bool
foo = runRTL $ do
    r <- newReg True
    r := low    
    return $ var r

Esto se comporta como lo esperaba:{[14]]}

*Main> takeS 10 foo :: Seq Bool
low | low | low | low | low | low | low | low | low | low | ? .

El generado VHDL es:

architecture str of assignments is
  signal sig_2_o0 : std_logic;
begin
  sig_2_o0 <= '0';
  OUTPUT <= sig_2_o0;
end architecture str;

Sin embargo, esperaba que esta otra versión también funcionara:

foo = runRTL $ do
    r <- newReg True

    r := low
    r := high
    return $ var r

Pero no lo hace, y la segunda asignación no se tiene en cuenta:{[14]]}

*Main> takeS 10 foo :: Seq Bool
low | low | low | low | low | low | low | low | low | low | ? .

La razón por la que estoy confundido es porque reg y var son definido en términos de un ciclo de reloj completo, por lo que no es como si pudiera hacer cosas imposibles de sintetizar como branch basado en r y luego reasignarle un nuevo valor. Entonces, ¿por qué no funciona esta segunda forma?

Tampoco es solo un problema de simulación: el generado VHDL para la segunda versión muestra claramente que la segunda asignación se descarta en tiempo de generación:

architecture str of assignments2 is
  signal sig_2_o0 : std_logic;
begin
  sig_2_o0 <= '0';
  OUTPUT <= sig_2_o0;
end architecture str;

Así que básicamente, habría esperado que la salida fuera más como{[14]]}

architecture str of assignments2 is
  signal sig_2_o0 : std_logic;
begin
  sig_2_o0 <= '0';
  sig_2_o0 <= '1';
  OUTPUT <= sig_2_o0;
end architecture str;

Pero no estoy seguro lo que eso significaría en VHDL.

39

haskell vhdl lava

Author: Cactus, 2012-12-22

Source

1 answers

score 3 · Accepted Answer

El problema es que está utilizando múltiples instrucciones no bloqueantes para asignar la señal.

  sig_2_o0 <= '0';
  sig_2_o0 <= '1';

Esto se traduce como:

at next event assign '0' to sig_2_o0.
at next event assign '1' to sig_2_o0.

Esto es diferente a usar bloquear asignaciones:

  sig_2_o0 := '0';
  sig_2_o0 := '1';

Que se traduciría a:

assign '0' to sig_2_o0.
assign '1' to sig_2_o0.

Bloquear asignaciones

Cuando se utilizan asignaciones de bloqueo, el valor está claramente definido. Primero se establecerá en '0', luego lo reemplazará con'1'. En este ejemplo no debe haber ningún efecto de la primera asignación de bloqueo para simulación o hardware sintetizado. Usted puede pensar en ello como hay 0 retraso entre la primera asignación y la segunda. Esto significa que tienes un pulso de ancho 0, que en realidad no es nada. Es equivalente a tener solo la última asignación, con la primera omitida por completo. Una advertencia es que si pone un retraso en las asignaciones, por ejemplo, "después de 1 ns", entonces notará la primera asignación seguida por la segunda en la simulación. En hardware, los retrasos se ignoran y así no habría ningún cambio de añadir retrasos. De hecho, la inserción de retrasos en RTL que se pretende sintetizar está fuertemente desaconsejada por esta razón. Es muy deseable que el hardware coincida con la simulación, y agregar retrasos puede introducir desajustes.

Asignaciones sin bloqueo

Pero cuando se utilizan asignaciones sin bloqueo, el simulador tiene dos asignaciones programadas para el próximo evento. Establezca la señal en ' 1 ' y al mismo tiempo, establézcala en '0'. Entonces, ¿qué asignación programada tomará la señal? No hay forma de saberlo. Puede ser cualquier valor ya que está asignado incorrectamente. Cada comprobador de pelusa y herramienta de síntesis en el planeta debe lanzar un error al encontrar múltiples asignaciones no bloqueantes como esta. Puede ser posible simularlo, pero hay claramente un problema con el RTL.