Tanto las soluciones de UVM como las de PSS implementan solucionadores de restricciones para crear casos de prueba, pero las similitudes terminan ahí. Afortunadamente, pueden trabajar juntos para hacer la vida de todos un poco más fácil.
Nota de Leigh Brady: Hasta ahora, la serie de columnas “Inside Portable Stimulus” (consulte “Rellenar los espacios en blanco”, “Simultaneidad y cronogramas” y “El bloque ejecutivo”) ha cubierto los conceptos básicos relacionados con el nuevo lenguaje Portable Stimulus Standard (PSS). sobre el concepto de Aunque hay algunas tareas de verificación que solo usan PSS, la mayoría de los ingenieros de verificación tienen experiencia en SystemVerilog y UVM. Me gustaría presentarles a una de mis colegas, Aileen Honess. FAE de Breker. Aileen tiene 20 años de experiencia enseñando, asesorando y liderando proyectos de verificación de hardware en diferentes disciplinas, empresas y continentes. Ella es experta en UVM y no conozco a nadie mejor para explicar algunas de las diferencias entre UVM y PSS. Volveremos en un artículo futuro para explicar exactamente cómo conectar estos dos entornos.
Esta columna analiza las diferencias y similitudes entre la generación anterior de soluciones que impulsaron a la industria de la verificación hacia la generación de patrones de prueba aleatorios restringidos y la nueva generación de soluciones impulsadas por PSS. Ambas soluciones implementan solucionadores de restricciones y crean casos de prueba, pero las similitudes terminan ahí. Afortunadamente, pueden trabajar juntos para hacer la vida de todos un poco más fácil.
Para evitar confusiones, la solución anterior basada en SystemVerilog y UVM se denomina solución UVM, y la solución basada en Portable Stimulus se denomina solución PSS. El solucionador de restricciones de UVM solo trata con restricciones combinatorias. Si el valor de este cable o registro en el tiempo T es X, entonces el valor de este otro cable o registro debe ser Y. En el tiempo T+1, todo se resuelve de nuevo, pero con nuevos valores aleatorios. Las soluciones de PSS añaden limitaciones de tiempo. Es decir, si una característica llamada A ocurre en el tiempo T, solo las características B o C pueden ocurrir en el tiempo T+1. Esto se suma a la restricción combinatoria.
Lo que esto significa es básico. PSS comprende el control y el flujo de datos de su diseño. Por ejemplo, si necesita una prueba para mostrar una imagen en la pantalla, ese es un caso de prueba que debe generar la herramienta PSS. Es posible que desee una prueba que recorra todas las rutas posibles para hacerlo, como imágenes de una cámara, imágenes de una tarjeta de memoria o transmisión a través de una conexión inalámbrica. Estos son casos de prueba bastante simples para PSS. Superpuesto a eso, puede ejecutar cualquiera de estas pruebas mientras recibe el texto. Esto crea una superposición gráfica o provoca otra actividad simultánea que puede interferir con el propósito principal.
Estas pruebas simultáneas generalmente se realizan en el nivel SoC. A nivel de SoC suele haber uno o más procesadores embebidos. La diferencia fundamental entre las pruebas de UVM y PSS es que UVM requiere que se elimine el procesador, mientras que PSS permite que la generación de software se ejecute en el procesador. Esto permite que la herramienta PSS ejecute las pruebas al revés. Parte de este software producido por las herramientas PSS está disponible para su uso según sea necesario, pero no es un software operativo. Las pruebas de SoC no prueban que los protocolos de bus se implementen correctamente, sino más bien si se realizan las conexiones adecuadas, si las rutas de datos funcionan correctamente y si las funciones interfieren entre sí.
Es mucho mejor verificar la funcionalidad del protocolo de bus y los bloques primitivos de forma aislada, por lo que quitar el procesador y exponer la interfaz de bus tiene mucho sentido en este caso. Una simulación minuciosa requiere un control total sobre todo. La validación de estos bloques es el objetivo de UVM y, a menudo, sigue siendo la mejor opción para abordar estas tareas.
Con la definición de UVM vino un paradigma de modelado para crear modelos transaccionales. Su función es elevar el nivel de abstracción de las señales de hardware al nivel de transacción. Este es el nivel en el que funciona el solucionador de restricciones UVM. También admite la abstracción de la mayoría de las entradas y salidas clave del SoC, que también son necesarias para las soluciones de PSS. Incluso si su prueba principal se ejecuta en un procesador integrado, aún debe proporcionar datos a sus entradas principales y recopilar datos de sus salidas principales.
Un puente entre las dos soluciones es importante. La solución PSS reemplaza en gran medida al solucionador de restricciones UVM y mejora la calidad de las pruebas producidas. También aumenta la complejidad de las pruebas que se pueden generar. Además, el modelo PSS es independiente de las transacciones, lo que facilita mucho la generación de pruebas que requieren coordinación entre múltiples transacciones. Todo esto reduce el tiempo de ejecución. Esto es especialmente importante cuando se consumen valiosos recursos de emulación.
Hay otro efecto menos notable. En la Parte 2 de esta serie, discutimos la programación. Un programa de ejemplo se muestra en la Figura 1. La depuración representa aproximadamente el 50% del tiempo total invertido por todo el equipo de desarrollo. Una de las razones es que si una prueba falla, primero debemos entender qué estaba haciendo la prueba. Esto no fue evidente en las pruebas producidas por el solucionador UVM y fue la razón de la necesidad de producir una cobertura funcional.
Figura 1: Una prueba de ejemplo que se ejecuta en TrekSoC de Breker (Fuente: Breker Verification Systems)
UVM restringe ciegamente la entrada, reduciendo las restricciones para que sean útiles. Se requiere una métrica de cobertura funcional para mostrar si las pruebas pudieron alcanzar sus objetivos previstos. Sin embargo, solo conocer la cobertura no nos dice mucho sobre lo que estaban haciendo las pruebas, por qué sucedieron esas cosas o cuáles deberían haber sido los resultados. Todos estos son proporcionados por las herramientas de PSS.
PSS comienza en la meta y trabaja hacia atrás. Cada paso en el camino es más procedimental, por lo que se necesitan muchas pequeñas aleatorizaciones. La resolución de restricciones es rápida en PSS y garantiza alcanzar la meta. Y lo más importante, conoce la cobertura de su intención antes de ejecutar sus pruebas.
Como se explicó anteriormente, los casos de prueba de PSS conocen la ruta completa a través del diseño y lo que está programado para ejecutarse simultáneamente. Las pruebas de PSS se autoverifican, por lo que puede ver de inmediato dónde comienza a fallar la prueba. Como resultado, el esfuerzo de depuración sabe exactamente por dónde empezar en lugar de comenzar con el verificador.
Este artículo no es tan técnico como los artículos anteriores de esta serie, pero ayudó a establecer los conceptos detrás de la integración de UVM y PSS. La siguiente columna detallará cómo hacer esto.
Como siempre, comuníquese conmigo (Aileen Honess) o Leigh Brady. Tiene un comentario, pregunta o solicitud de aclaración.