Cómo crear un banco de pruebas de autocomprobación

Las últimas dos líneas de código dentro del proceso son para finalizar la prueba correctamente. El texto "Test:OK" se imprime en la consola y luego la simulación se detiene usando la palabra clave VHDL-2008 "finish".

Tenga en cuenta que si ejecuta ModelSim con el botón Ejecutar predeterminado, ModelSim le indicará el cuadro de diálogo de salida después de que el banco de pruebas se complete con éxito. Este comportamiento se puede cambiar al iniciar Vsim desde un script o desde la línea de comandos. Agregue el interruptor "-onfinish stop" al comando Vsim, como se describe en la referencia del comando ModelSim.

Comprobando la salida

Ahora estamos suministrando entradas al DUT, pero no hay verificación de la salida en absoluto. El banco de pruebas imprimirá "Test:OK", independientemente de si la salida es correcta o no. Hagamos algo al respecto.

Al crear un algoritmo de verificación, siempre debe intentar implementar la prueba de manera diferente que en el DUT. De lo contrario, una falla fundamental en la lógica puede pasar desapercibida porque está presente tanto en el DUT como en el algoritmo del banco de pruebas.

Siguiendo este principio, vamos a probar la salida del DUT no comprobando que el código Gray sea correcto, sino que solo cambia un bit de un número al siguiente. Después de todo, esa es la razón principal para usar el código Gray en primer lugar. El siguiente código muestra un proceso que realiza este tipo de verificación.

PROC_CHECKER : process
    variable prev : std_logic_vector(gray'range);
    variable count : integer;
begin
  wait on bin;

  prev := gray;

  -- Wait for all delta cycles to propagate
  wait for 1 ns;
  
  -- Count the number of changed bits
  count := 0;
  for i in gray'range loop
    if gray(i) /= prev(i) then
      count := count + 1;
    end if;
  end loop;

  assert count = 1
    report integer'image(count) & " bits changed, should have been 1"
    severity failure;
  
end process;

El proceso es sensible al bin señal, la entrada al dispositivo bajo prueba. Podríamos haber usado una lista de sensibilidad con el mismo resultado, pero prefiero usar solo declaraciones de espera en el código del banco de pruebas. Es una convención que facilita saber si se trata de un banco de pruebas o de un módulo RTL con solo mirar cómo está escrito el código.

En la línea de segundos, copiamos la salida DUT anterior. Recuerde, este es el primer ciclo delta después del bin la señal ha cambiado y el DUT no puede reaccionar todavía. Por lo tanto, es seguro copiar la salida del dispositivo bajo prueba suponiendo que este es el valor anterior.

Luego, esperamos 1 nanosegundo para permitir que se complete toda la lógica combinacional en el DUT. Ahora, la salida del dispositivo bajo prueba debería ser estable y podemos examinar su valor con seguridad.

En el siguiente fragmento de código, usamos un bucle For para contar el número de bits modificados en la salida del dispositivo bajo prueba.

Finalmente, viene la declaración Assert que verifica que el número de bits modificados sea exactamente 1. Las declaraciones Assert funcionan al verificar la condición, que en este caso es count = 1 . Si la condición se evalúa como false , se generará una afirmación y el simulador se detendrá antes de que se imprima el mensaje "Test:OK".

Es aconsejable incluir la declaración de informe opcional con la declaración de afirmación. Este texto se imprimirá si la aserción falla. En nuestro ejemplo, brindo una breve explicación del evento que causó que el banco de pruebas fallara.

Ejecutar el banco de pruebas

Es hora de ejecutar nuestro banco de pruebas para verificar que el DUT funciona correctamente. Después de iniciar la simulación en ModelSim y presionar el botón "ejecutar todo", vemos que el mensaje "Prueba:OK" se imprime en la consola.

VSIM 1> run -all
# ** Note: Test: OK
#    Time: 170 ns  Iteration: 0  Instance: /gray_converter_tb

Probando el banco de pruebas

Siempre me gusta crear una condición de falla en el DUT solo para ver que el banco de pruebas funciona. A veces, esto surge naturalmente debido a errores reales en el DUT mientras lo desarrolla. Pero si no es así, simplemente cree un error brevemente para probar el banco de pruebas.

Para lograr esto, editaré el código del dispositivo bajo prueba para crear un error atascado en 0 en el bit número 3. Después de esta prueba, eliminaré el error sabiendo que el banco de pruebas puede detectar tales errores. El siguiente código muestra el proceso DUT con la línea de código adicional.

process(bin) is
begin
  gray(gray'high) <= bin(bin'high);

  for i in bin'high - 1 downto bin'low loop
    gray(i) <= bin(i + 1) xor bin(i);
  end loop;

  -- Emulate a stuck at zero error
  gray(3) <= '0';

end process;

Cuando ejecutamos el banco de pruebas ahora, podemos ver que el banco de pruebas se detiene y el error se imprime antes de que se alcance la línea "Prueba:OK". La transcripción de la consola de ModelSim se muestra a continuación.

VSIM 2> run -all
# ** Failure: 0 bits changed, should have been 1
#    Time: 81 ns  Iteration: 0
Process: /gray_converter_tb/PROC_CHECKER File: gray_converter_tb.vhd
# Break in Process PROC_CHECKER at ray_converter_tb.vhd line 61

Primeros pasos con los bancos de pruebas de autocomprobación

Debería poder crear un banco de pruebas de autocomprobación utilizando lo que ha aprendido en este artículo. Acostúmbrese a crear siempre bancos de pruebas de autocomprobación para todos sus módulos VHDL. Le ahorrará tiempo a largo plazo.

Está bien ser creativo al escribir bancos de pruebas. Más que cuando se escriben módulos RTL porque no todas las construcciones VHDL se pueden sintetizar, pero el banco de pruebas no necesita ser sintetizable. Espere pasar al menos tanto tiempo escribiendo pruebas como el que dedica a escribir el DUT.

Si quiere tomarse en serio las pruebas, puede estar interesado en mi * próximo curso de VHDL y FPGA. En el curso, lo guiaré a través del proceso de diseño completo, desde la idea hasta el prototipo de FPGA que funciona físicamente. Crearemos múltiples bancos de pruebas de autoverificación.

Actualizado el 12 de octubre de 2020: He completado el curso. Haga clic en la imagen a continuación para obtener más información.

Le enseñaré las mejores prácticas para crear con éxito diseños VHDL y FPGA de la manera correcta. Los conocimientos que he adquirido a lo largo de muchos años en el mundo académico y después de trabajar como ingeniero de hardware en la industria de la defensa se transmitirán a usted.

¡Lea más sobre el curso Dot Matrix VHDL y FPGA aquí!

Abre:

Por decidir .