Estoy empezando a aprender SystemVerilog y trabajar con FPGA, y hasta ahora no he encontrado una manera satisfactoria de probar mi código. Vengo de un fondo de software, y siempre he estado escribiendo pruebas automatizadas exhaustivas para mi código. He estado usando marcos de estilo JUnit (con un montón de ajustes específicos de dominio en la parte superior, para reducir repetitivo), así como marcos de estilo QuickCheck, y encontré formas de usar estos marcos para escribir código de prueba conciso que, sin embargo, me proporciona un alto nivel. Confianza en el producto que estoy desarrollando. Todavía no he encontrado nada equivalente para los lenguajes de descripción de hardware.
Los textos introductorios de Verilog suelen presentar bancos de pruebas que solo controlan las señales de entrada. Estos bancos de prueba son paredes de código repetitivas ilegibles (asignaciones de señales) sin aserciones; Estas pruebas ni siquiera son automáticas. Algunos textos intentan incorporar aserciones verificables por la máquina en el código del banco de pruebas para que uno no tenga que mirar las formas de onda para determinar si la prueba se aprobó o no. Aún así, el problema del "muro de texto repetitivo" continúa.
Investigué más el problema y encontré que el estándar actual de la industria para la verificación de RTL es UVM. La idea me parece mejor, no la he examinado en detalle, pero para mí la gran desventaja de UVM es que los bancos de pruebas UVM no son sintetizables.
Si no puedo ejecutar mis pruebas en el FPGA real, ¿cómo puedo estar seguro de que mi diseño sintetizado funciona correctamente? Entiendo que existe una alta probabilidad de que funcione después de que hayan pasado las pruebas de simulación, pero hay muchas suposiciones involucradas (que mi código no es vicioso, que mi código cumple con los requisitos de tiempo, que la herramienta de síntesis es correcta, etc. )
Un paralelo en el mundo del software sería desarrollar un programa en C, compilar con gcc y probarlo en x86 en Windows, y luego compilarlo con Clang y ejecutarlo en producción en ARM en Linux. El programa debería funcionar, asumiendo que no tiene un comportamiento indefinido, no tiene suposiciones no portátiles sobre el entorno de ejecución, ambos compiladores no tienen errores que afecten al programa. Esta es una gran cantidad de suposiciones que la mayoría de los ingenieros de software no harían y en su lugar solo realizarían sus pruebas en la configuración de producción.
¿Estoy malinterpretando algo sobre el proceso de diseño de hardware en el mundo real? ¿Cómo se verifican los diseños una vez que se sintetizan en FPGA y silicona real? ¿Cómo ejecutar casos de prueba existentes en diseños en FPGA y silicona?
¿Existen prácticas estándar de la industria para bancos de pruebas sintetizables? ¿Las personas realmente escriben bancos de pruebas sintetizables?
