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

Question

He buscado en la web y las discusiones / ejemplos parecen ser para el desarrollo de software tradicional. Dado que Verilog y VHDL (utilizados para el diseño de chips, por ejemplo, FPGA y ASIC) son similares al desarrollo de software C y C ++, parece tener sentido. Sin embargo, tienen algunas diferencias que son fundamentalmente paralelas y requieren hardware para realizar pruebas completas.

¿Qué experiencias, buenas y malas, has tenido? ¿Algún enlace que pueda sugerir sobre esta aplicación específica?

Ediciones / aclaraciones: 28/10/09: Estoy preguntando particularmente sobre TDD. Estoy familiarizado con hacer bancos de prueba, incluidos los de autocomprobación. También soy consciente de que SystemVerilog tiene algunas características particulares para bancos de pruebas.

28/10/09: Las preguntas implicadas incluyen 1) escribir una prueba para cualquier funcionalidad, nunca usar formas de onda para la simulación y 2) escribir pruebas / bancos de pruebas primero.

29/11/09: En Los estudios empíricos muestran que el desarrollo impulsado por pruebas mejora Calidad informan para TDD (software) " La densidad de defectos previos al lanzamiento de los cuatro productos, medida como defectos por mil líneas de código, disminuyó entre 40% y 90% en relación con los proyectos que no utilizaron TDD . La administración de los equipos informó subjetivamente un aumento del 15–35% en el tiempo de desarrollo inicial para los equipos que usan TDD, aunque los equipos acordaron que esto se compensó con la reducción de los costos de mantenimiento. Los errores reducidos reducen el riesgo de pérdida de cinta, a expensas del impacto moderado de la programación. Esto también tiene algunos datos.

29/11/09: Principalmente estoy haciendo código de control y ruta de datos, no código DSP. Para DSP, la solución típica implica una simulación de precisión de bits de Matlab.

02/03/10: La ventaja de TDD es que se asegura de que la prueba falle primero. Supongo que esto también podría hacerse con afirmaciones.

Answer 1

Escribo código para FPGAs, no ASICS ... pero TDD sigue siendo mi enfoque preferido. Me gusta tener un conjunto completo de pruebas para todo el código funcional que escribo, y trato (no siempre con éxito) de escribir primero el código de prueba. Mirar fijamente las formas de onda siempre ocurre en algún momento cuando estás depurando, pero no es una buena forma de validar tu código (IMHO).

Dada la dificultad de realizar pruebas adecuadas en el hardware real (estimular casos de esquina es particularmente difícil) y el hecho de que una compilación de VHDL lleva segundos (frente a una compilación de hardware que lleva muchos minutos (o incluso horas) ), ¡No veo cómo alguien puede operar de otra manera!

También construyo aserciones en el RTL mientras lo escribo para detectar cosas que sé que nunca deberían suceder. Aparentemente, esto se ve como un poco "extraño", ya que existe la percepción de que los ingenieros de verificación escriben afirmaciones y los diseñadores de RTL no. Pero sobre todo soy mi propio ingeniero de verificación, ¡así que tal vez por eso!

Answer 2

Utilizo VUnit para el desarrollo basado en pruebas con VHDL.

VUnit es una biblioteca de Python que invoca el compilador y simulador de VHDL 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 comunicación biblioteca , biblioteca de registro y una revisando la biblioteca .

Hay muchas posibilidades ya que se invoca desde Python. Es posible generar datos de prueba, así como verificar 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 pude hacer preguntas directamente a los desarrolladores y obtuve ayuda con bastante rapidez.

Una desventaja es que es más difícil depurar errores de compilación ya que hay muchas variaciones de función / procedimiento con el mismo nombre en las bibliotecas. Además, algunas cosas se realizan detrás de escena al preprocesar el código, lo que significa que algunos errores pueden aparecer en lugares inesperados.

Answer 3

Las extensiones de SystemVerilog al 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 oposición a la emulación o el uso de FPGA).

Los beneficios significativos sobre un lenguaje de diseño de hardware tradicional (Verilog) son:

• aleatorización restringida
• afirmaciones
• recopilación automática de datos de cobertura funcional y de afirmación

La clave es tener acceso al software de simulación que admite esta norma reciente (2005). No todos los simuladores son totalmente compatibles las funciones más avanzadas.

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

También podría investigar más sobre el tema buscando en Verfication Guild forum.

SystemVerilog no es el único HVL, y VMM no es la única biblioteca. Pero, recomendaría ambos, si tiene acceso al herramientas. He encontrado que esta es una metodología efectiva para encontrar diseño errores antes de convertirse en silicio.

Answer 4

No sé mucho sobre el diseño de hardware / chip, pero estoy profundamente interesado en TDD, por lo que al menos puedo discutir la idoneidad del proceso con usted.

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

El proceso TDD depende en gran medida de la "suavidad" de software: buenas pruebas unitarias automatizadas que se ejecutan en segundos (minutos en el exterior) y guían pequeñas explosiones de construcción enfocada y refactorización. ¿Sus herramientas son compatibles con este tipo de flujo de trabajo: ciclando rápidamente entre escribir y ejecutar pruebas y construir el sistema bajo prueba en iteraciones cortas?

Answer 5

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

Philippe Faes, Sigasi

Answer 6

ANVIL & # 8211; Otra capa de interacción de Verilog habla sobre esto. No lo he probado.

Answer 7

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

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

Sin embargo, no confiaría totalmente en las afirmaciones, esto puede volverse muy difícil.

Quizás también puedas expresar tus pensamientos sobre esto, ya que lo estás pidiendo, ¿supongo que tienes algunas ideas en tu cabeza?

Answer 8

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

Cualquiera que 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 las pruebas) y desventajas (difícil de configurar y engorroso en comparación con el software).

He tenido muy buena experiencia con el empleo de Python y transactores HDL genéricos para implementar 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 está acostumbrado a (1) generar código VHDL a partir de escenarios de prueba escritos en Python y (2) verificación de resultados escritos por los operadores 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é te quieres enfocar.