Automatización de casos de prueba de C para la verificación del sistema integrado

A medida que los diseños de sistema en chip (SoC) avanzan hacia una mayor complejidad, los conjuntos de pruebas que contienen miles de líneas de código para la verificación a nivel del sistema continúan escribiéndose a mano, una práctica curiosamente vieja e ineficaz que desafía el adagio "automatizar cuando sea posible." Esto es especialmente cierto para las pruebas C que se ejecutan en los procesadores integrados de un SoC para verificar todo el dispositivo antes de la fabricación.

Se ha demostrado que la automatización de la composición de la prueba de verificación siempre que sea posible aumenta la productividad en muchas fases del desarrollo de SoC. Las técnicas aleatorias restringidas, por ejemplo, en un banco de pruebas de la Metodología de verificación universal (UVM), utilizan vectores de prueba aleatorizados dirigidos a escenarios específicos para aumentar la cobertura. Si bien estos han aumentado la eficiencia de verificación a nivel de bloque de hardware, el diseño aún se percibe como una caja negra con estímulos, verificaciones y código de cobertura escritos por separado, lo que sigue siendo una tarea onerosa y propensa a errores para bloques grandes.

Es difícil extender esta metodología al nivel del sistema, dada la necesidad de combinar el código de prueba del procesador con transacciones de E / S, a menudo ejecutadas en un emulador o sistema de creación de prototipos. Para verificar correctamente un SoC, se deben ejercitar los propios procesadores. UVM y otros enfoques aleatorios restringidos no tienen en cuenta el código que se ejecuta en los procesadores. De hecho, para usar UVM en un SoC, los procesadores a menudo se eliminan y reemplazan por entradas y salidas virtuales en el bus SoC, lo que permite verificar el subsistema menos el procesador.

Los ingenieros de verificación de SoC reconocen las limitaciones de los bancos de pruebas aleatorios restringidos, lo que los lleva a escribir a mano pruebas C para ejecutarlas en los procesadores tanto para la simulación como para la emulación de hardware, a pesar de que están limitados en el ejercicio completo del diseño de SoC. El rendimiento de estas plataformas de verificación no es lo suficientemente bueno para ejecutar un sistema operativo (SO) completo, por lo que estas pruebas se ejecutan de forma “completa”, lo que agrega una sobrecarga significativa al esfuerzo de composición. Es inusual que las pruebas escritas a mano, especialmente sin la ayuda de los servicios del sistema operativo, se ejecuten de manera coordinada en procesadores de múltiples núcleos que aprovechan múltiples subprocesos. El resultado es que los aspectos del comportamiento de SoC, como las operaciones concurrentes y la coherencia, se verifican mínimamente.

Generación automática de pruebas C

Por supuesto, las pruebas C generadas automáticamente harán un uso más eficiente de los recursos de ingeniería. También aumentan la cobertura. Los casos de prueba generados en C pueden ejercitar más la funcionalidad del SoC que las pruebas escritas a mano y buscarán casos de esquina complejos difíciles de imaginar. Los casos de prueba multiproceso y multiprocesador pueden ejercitar todas las rutas paralelas dentro del diseño para verificar la concurrencia. Pueden mover datos entre segmentos de memoria para enfatizar los algoritmos de coherencia y coordinar con las transacciones de E / S cuando los datos deben enviarse a las entradas del chip o leerse desde sus salidas. El efecto general de esto es aumentar la cobertura funcional del sistema, generalmente más del 90% de números que son característicamente mucho más bajos.

El software de generación de pruebas, conocido como Test Suite Synthesis, utiliza un modelo de escenario basado en gráficos fácil de entender que captura el comportamiento de diseño previsto. Estos modelos pueden escribirse utilizando Accellera Portable Stimulus Standard utilizando C ++ nativo o describirse visualmente. Los modelos de escenarios son creados por ingenieros de diseño o verificación como una parte natural del desarrollo de SoC, ya que se asemejan a los diagramas de flujo de datos de chip tradicionales que se pueden dibujar en una pizarra para explicar parte de la especificación de diseño.

Estos modelos incluyen de forma inherente estímulos, comprobaciones, detalles de cobertura e información de depuración, lo que proporciona al generador todo lo que necesita para producir casos de prueba C de autoverificación de alta calidad que enfatizan todos los aspectos del diseño. Debido a que son jerárquicas y modulares, cualquier prueba desarrollada a nivel de bloque se puede reutilizar por completo como parte del modelo de SoC completo y se puede compartir fácilmente con diferentes equipos y entre proyectos. Por último, la herramienta de síntesis puede descomponer el modelo único de intención para proporcionar las pruebas simultáneas a través de subprocesos y puertos de E / S, todos sincronizados juntos.

Ventajas de la síntesis de conjuntos de pruebas

Una ventaja significativa de la síntesis del conjunto de pruebas es la capacidad de definir objetivos de cobertura por adelantado en el modelo de intención. Una vez que se ha especificado la intención, la herramienta puede analizarla para comprender la cantidad de pruebas que podrían producirse y la cobertura de la intención funcional que se lograría.

Para un SoC, esto puede sumar muchos miles de pruebas. Luego, se pueden establecer metas de cobertura limitando la intención de ser probada y enfocando la herramienta en áreas clave. Esta capacidad evita el doloroso ciclo iterativo que ocurre en los enfoques tradicionales, que consiste en configurar las pruebas, ejecutar la herramienta de verificación, comprender la cobertura lograda y luego restablecer las pruebas una y otra vez.

En un proyecto típico en un SoC grande desarrollado por una conocida empresa de semiconductores, los ingenieros de verificación redujeron el tiempo de composición de la prueba al 20% de lo que antes requería pruebas escritas a mano. La tecnología de automatización produjo casos de prueba más rigurosos, aumentando la cobertura del 84% al 97%. Además, los modelos son portátiles.

Un solo modelo puede generar casos de prueba para plataformas virtuales, simulación de nivel de transferencia de registro (RTL), emulación, prototipos de matriz de puerta programable en campo (FPGA) o un chip real en el laboratorio sometido a validación posterior al silicio.

La depuración es otro sumidero de tiempo para los ingenieros, especialmente a nivel de SoC. Si un caso de prueba descubre un error de diseño al acecho, el ingeniero de verificación debe comprender qué prueba desencadenó el error para rastrear su origen. La falla de un caso de prueba puede deberse a un error en el modelo de escenario, por lo que debe ser posible correlacionar el caso de prueba con el gráfico donde se capturó la intención del diseño. Este proceso crea pruebas altamente modulares e independientes que se descomponen fácilmente, de modo que la prueba ejecutada para detectar el error es fácil de ver.

Escenarios de aplicación

Los casos de prueba sintetizados pueden ejercitar casos de uso realistas, llamados escenarios de aplicación, para el diseño. Por ejemplo, considere el SoC de cámara digital que se muestra en la figura 1.

haz clic para ampliar la imagen

Figura 1:Ejemplo de SoC de procesamiento de imágenes. (Fuente:Breker Verification Systems)

Los componentes de nivel de bloque de SoC incluyen dos procesadores, los dispositivos periféricos y la memoria. Un gráfico simple para el SoC se muestra debajo del diagrama de bloques. El gráfico incluye las posibles rutas de alto nivel que pueden ejercitarse en el proceso de verificación de SoC. Por ejemplo, un escenario posible, expresado en la ruta superior del gráfico, lee una imagen JPEG de la tarjeta SD y la pasa al fotoprocesador a través de una región asignada en la memoria. La imagen se procesa en una forma que se puede mostrar y cargar en un segundo bloque en la memoria. Desde allí, se pasa al controlador de pantalla. Por supuesto, cada uno de estos bloques de alto nivel es de naturaleza jerárquica con muchas acciones y decisiones que se ejecutan como parte del proceso.

La herramienta de síntesis tomará la prueba aleatoria y la programará adecuadamente. En la forma más simple, como se muestra en la figura, la prueba podría estar programada en un solo hilo, seguida de la siguiente prueba y así sucesivamente. Sin embargo, la capacidad de los casos de prueba para hacer hincapié en el SoC proviene de la intercalación de aplicaciones en múltiples subprocesos y múltiples procesadores. La herramienta ejecutará tantas aplicaciones en paralelo como sea compatible con la concurrencia inherente del diseño, asignando memoria a medida que avanza de la manera más tortuosa posible. Esto también se muestra como una alternativa en la figura donde las pruebas se distribuyen en tres subprocesos, haciendo uso de varias regiones asignadas en las memorias de SoC.

Por supuesto, este ejemplo se presenta a un alto nivel para aclarar el proceso. En realidad, la herramienta de síntesis aplanará el gráfico jerárquico, creando una gran cantidad de acciones y conexiones. Estos también incluirán decisiones aleatorias, que deben ejecutarse a través de un algoritmo de resolución. A medida que se recorre el gráfico, se emplean algoritmos de planificación de IA que inspeccionan las salidas deseadas y optimizan las pruebas de entrada para que coincidan. La herramienta de síntesis incluye servicios similares a los de un sistema operativo que asignan memoria, brindan acceso al mapa de direcciones, interrupciones de procesos y otras tareas necesarias para completar las estructuras de prueba. Luego, las pruebas se programan de forma aleatoria con el almacenamiento y otros recursos asignados de manera adecuada.

Conclusión

Al igual que los bancos de pruebas aleatorios restringidos eliminaron el trabajo manual para la verificación de bloques, se ha demostrado que el contenido de prueba sintetizado para los SoC basados ​​en procesadores integrados reduce el esfuerzo de verificación del nivel del sistema. Además, esta solución ahora se está aplicando a nivel de bloque y para la validación posterior al silicio. En este ejemplo, los casos de prueba C automatizados aplican el adagio de "automatizar siempre que sea posible", mejorando drásticamente la cobertura al tiempo que acorta los programas de verificación.