plantilla - Experiencias con Test Driven Development(TDD) para el diseño lógico(chip) en Verilog o VHDL
metodologia tdd (8)
He mirado 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 pruebas, incluidos los de autocontrol. También soy consciente de que SystemVerilog tiene algunas características particulares para bancos de pruebas.
28/10/09: Las preguntas implicadas incluyen 1) escribiendo una prueba para cualquier funcionalidad, nunca usando formas de onda para la simulación y 2) escribiendo pruebas / bancos de prueba primero.
29/11/09: En Empirical Studies, el desarrollo guiado por pruebas mejora la calidad que reportan para (software) TDD "La densidad de defectos de prelanzamiento de los cuatro productos, medida como defectos por mil líneas de código, disminuyó entre un 40% y un 90% "En relación con los proyectos que no usaron TDD. La administración de los equipos reportó subjetivamente un aumento de 15 a 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 agotamiento, a expensas de un impacto moderado en la programación. This también tiene algunos datos.
29/11/09: Estoy haciendo principalmente un código control y datapath, no código DSP. Para DSP, la solución típica consiste en una simulación precisa de bits de Matlab.
02/02/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.
¿Qué es TDD para ti? ¿Quiere decir que todo el código se ejerce mediante pruebas automáticas en todo momento, o va más allá para indicar que las pruebas se escriben antes que el 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 prueba) y menos (difícil de configurar y engorroso en relación con el software).
He tenido muy buena experiencia con el uso de transactores HDL genéricos y de Python 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 se usa para (1) generar código VHDL a partir de escenarios de prueba escritos en Python y (2) verificación de resultados escritos por los transactores de monitoreo que aceptan formas de onda Desde el diseño durante la simulación.
Hay mucho más que escribir sobre esta técnica, pero no estoy seguro de en qué quieres centrarte.
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
Escribo código para FPGA, no ASICS ... pero TDD es mi enfoque preferido. Me gusta tener un conjunto completo de pruebas para todo el código funcional que escribo e intento (no siempre con éxito) escribir primero el código de prueba. Mirar a las formas de onda siempre sucede en algún momento cuando estás depurando, pero no es una buena manera de validar tu código (IMHO).
Dada la dificultad de realizar pruebas adecuadas en el hardware real (es especialmente difícil estimular casos de esquinas) y el hecho de que una compilación VHDL demore unos segundos (frente a una compilación "a hardware" que demore muchos minutos (o incluso horas)), no ¡No veo cómo alguien puede operar de otra manera!
También construyo afirmaciones en la RTL a medida que las escribo para captar 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, ¡entonces tal vez por eso!
Las extensiones SystemVerilog para el 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 usa para verificar los diseños de chips ASIC a través de la simulación (a diferencia de la emulación o el uso de FPGA).
Los beneficios significativos sobre un lenguaje tradicional de diseño de hardware (Verilog) son:
- aleatorización restringida
- afirmaciones
- Recopilación automática de datos de cobertura funcional y de aserción.
La clave es tener acceso a un software de simulación que admita este estándar reciente (2005). No todos los simuladores son totalmente compatibles con las funciones más avanzadas.
Además del estándar IEEE, hay una biblioteca de fuente abierta SystemVerilog de componentes de verificación disponible en VMM Central ( http://www.vmmcentral.com ). Proporciona un marco razonable para crear un entorno de prueba.
También puede hacer más investigación sobre el tema buscando en el foro de Verfication Guild.
SystemVerilog no es la única HVL, y VMM no es la única biblioteca. Pero, recomendaría ambos, si tiene acceso a las herramientas apropiadas. He descubierto que esta es una metodología eficaz para encontrar errores de diseño antes de convertirse en silicio.
No sé mucho sobre el diseño de hardware / chip, pero estoy muy interesado en TDD, por lo que al menos puedo discutir la idoneidad del proceso con usted.
La pregunta que yo llamaría más pertinente es: ¿Qué tan rápido pueden tus pruebas darte feedback sobre un diseño? Relacionado con eso: ¿Qué tan rápido puedes agregar nuevas pruebas? ¿Y qué tan bien admiten sus herramientas la refactorización (cambiar la estructura sin cambiar el comportamiento) de su diseño?
El proceso de 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 las ráfagas cortas de construcción enfocada y refactorización. ¿Sus herramientas admiten este tipo de flujo de trabajo: alternar rápidamente entre las pruebas de escritura y ejecución y construir el sistema bajo prueba en breves iteraciones?
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 debe escribir en forma de aserciones lo que asume / espera de su módulo, escribir su RTL y luego puede verificar estas afirmaciones 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 una cobertura mucho mejor y las aseveraciones / suposiciones también pueden ser útiles más adelante (por ejemplo, en el nivel del sistema).
Sin embargo, no confiaría completamente en las afirmaciones, esto puede volverse muy velludo.
Tal vez usted también pueda expresar sus pensamientos sobre esto, ya que lo está pidiendo, ¿supongo que tiene algunas ideas en su cabeza?
Uso VUnit para el desarrollo guiado por pruebas con VHDL.
VUnit es una biblioteca de Python que invoca al compilador y simulador 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 biblioteca de comunicación , una biblioteca de registro y una biblioteca de comprobación .
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. El otro día vi este ejemplo en el que usaron Octave, una copia de Matlab, para trazar los resultados de las pruebas .
VUnit parece muy activo y varias veces he podido hacer preguntas directamente a los desarrolladores y he recibido ayuda con bastante rapidez.
Un inconveniente es que es más difícil depurar errores de compilación, ya que hay tantas variaciones de funciones / procedimientos con el mismo nombre en las bibliotecas. Además, algunas cosas se realizan detrás de la escena al preprocesar el código, lo que significa que algunos errores pueden aparecer en lugares inesperados.
ANVIL - otra capa de interacción Verilog habla de esto un poco. No lo he probado.