Experiencias con Test Driven Development (TDD) para el diseño lógico (chip) en Verilog o VHDL

Uso VUnit para el desarrollo basado en pruebas con VHDL.

VUnit es una biblioteca Python que invoca el compilador VHDL y el simulador y lee los resultados de la simulación. También proporciona varias bibliotecas VHDL agradables que hacen que sea mucho más fácil escribir mejores bancos de pruebas, como una biblioteca de comunicación , logging library y checking library.

Hay muchas posibilidades ya que se invoca desde Python. Es posible ambos generan datos de prueba, así como comprobar los datos de salida de la prueba en Python. Vi este ejemplo el otro día donde usaron Octave - una copia de Matlab - para trazar los resultados de la prueba .

VUnit parece muy activo y varias veces he podido hacer preguntas directamente a los desarrolladores y obtener ayuda bastante rápido.

Un inconveniente es que es más difícil depurar errores de compilación, ya que hay muchas variaciones de funciones / procedimientos con el mismo nombre en biblioteca. Además, algunas cosas se hacen detrás de la escena mediante el preprocesamiento del código, lo que significa que algunos errores pueden aparecer en lugares inesperados.

Las extensiones SystemVerilog del estándar IEEE Verilog incluyen una variedad de construcciones que facilitan la creación de conjuntos de pruebas exhaustivos para verificar diseños lógicos digitales complejos. SystemVerilog es uno de los Lenguajes de Verificación de Hardware (HVL) que se utilizan para verificar el chip ASIC diseños a través de simulación (en lugar de emulación o uso de FPGA).

Los beneficios significativos sobre un Lenguaje de Diseño de Hardware tradicional (Verilog) son:

• restringido aleatorización
• aserciones
• recopilación automática de datos de cobertura funcionales y de aserción

La clave es tener acceso al software de simulación que soporta this recent (2005) standard. No todos los simuladores son totalmente compatibles las características más avanzadas.

Además del estándar IEEE, hay una biblioteca SystemVerilog de código abierto de los componentes de verificación disponibles en VMM Central ( http://www.vmmcentral.com ). Proporciona una razonable marco para crear un entorno de prueba.

También podría hacer más investigación sobre el tema mediante la búsqueda de la Verfication Guild forum (en inglés).

SystemVerilog no es el único HVL,y VMM no es la única biblioteca. Pero, yo recomendaría ambos, si usted tiene acceso al apropiado herramienta. He encontrado que esta es una metodología eficaz en la búsqueda de diseño bugs antes de que se convierta en silicio.

No se mucho sobre diseño de hardware/chip, pero estoy profundamente en TDD, así que al menos puedo discutir la idoneidad del proceso con usted.

La pregunta que yo llamaría más pertinente es: ¿Con qué rapidez pueden sus pruebas darle retroalimentación sobre un diseño? Relacionado con eso: ¿Con qué rapidez puede agregar nuevas pruebas? ¿Y qué tan bien soportan sus herramientas la refactorización (cambiar la estructura sin cambiar el comportamiento) de su diseño?

El proceso TDD depende en gran medida de la "suavidad" del software - las buenas pruebas unitarias automatizadas se ejecutan en segundos (minutos en el exterior) y guían ráfagas cortas de construcción enfocada y refactorización. ¿Sus herramientas soportan este tipo de flujo de trabajo - alternando rápidamente entre escribir y ejecutar pruebas y construyendo el sistema bajo prueba en iteraciones cortas?

Con respecto a las herramientas de refactorización para lenguajes de hardware, me gustaría señalar nuestra herramienta Sigasi HDT. Sigasi proporciona un IDE con analizador VHDL incorporado y refactorizaciones VHDL.

Philippe Faes, Sigasi

ANVIL– Otra capa de interacción Verilog habla de esto algunos. No lo he probado.

Nunca probé activamente TDD en un diseño RTL, pero tenía mis pensamientos sobre esto.

Lo que creo que sería interesante es probar este enfoque en relación con las afirmaciones. Básicamente, primero escribiría en forma de aserciones lo que asume/espera de su módulo, escribiría su RTL y más tarde puede verificar estas aserciones utilizando herramientas formales y/o simulación. En contraste con los casos de prueba "normales" (donde probablemente necesitaría escribir los dirigidos) debería tener mucho una mejor cobertura y las aseveraciones/suposiciones pueden ser útiles más adelante (por ejemplo, a nivel del sistema) también.

Sin embargo, no confiaría completamente en las afirmaciones, esto puede volverse muy peludo.

Tal vez usted puede expresar sus pensamientos sobre esto, así, como usted está pidiendo que supongo que usted lleva algunas ideas en su cabeza?

¿Qué es TDD para usted? ¿Quiere decir tener todo su código ejercido por pruebas automáticas en todo momento, o va más allá para significar que las pruebas se escriben antes del código y no se escribe ningún código nuevo a menos que las pruebas fallen?

Sea cual sea el enfoque que prefiera, las pruebas de código HDL no son muy diferentes de las pruebas de software. Tiene sus ventajas (mucho mejor cobertura y profundidad de pruebas) y desventajas (difícil de configurar y engorroso en relación con el software).

He tenido muy buena experiencia con el empleo de Python y transactores HDL genéricos para la implementación de pruebas completas y automáticas para módulos HDL sintetizables. La idea es algo similar a lo que Janick Bergeron presenta en sus libros, pero en lugar de SystemVerilog, Python se usa para (1) generar código VHDL a partir de escenarios de prueba escritos en Python y (2) verificar los resultados escritos por los transactores de monitoreo que aceptan formas de onda del diseño durante la simulación.

Hay mucho más por escribir sobre esta técnica, pero no estoy seguro de en qué quieres centrarte.