Esta página fue traducida automáticamente.
Complete una encuesta de 1 minuto sobre la calidad de esta traducción.
Verificación basada en modelos en el desarrollo de ASIC para automoción
Por Aswini Tata, Sanjay Chatterjee y Kamel Belhous, Allegro MicroSystems y Surekha Kollepara, Cyient
A medida que los requisitos de clientes y los plazos de entrega se vuelven más exigentes, el enfoque de verificación basado en modelos que hemos adoptado ayuda a ofrecer algoritmos y sistemas más sofisticados con un plazo de comercialización reducido.
Las empresas de semiconductores que prestan servicios a la industria automotriz exigen que sus equipos de ingeniería entreguen sistemas cada vez más complejos en plazos más ajustados. Cumplir con estos plazos conlleva dificultades relacionadas con las pruebas en últimas etapas. Por ejemplo, esperar hasta que RTL esté disponible para iniciar la verificación funcional conlleva el riesgo de generar sobrecostos y demoras en la entrega. Los defectos de diseño y los problemas de requisitos que se detectan en esta etapa son mucho más costosos y difíciles de solucionar, y se pierde tiempo valioso cuando se depuran escenarios poco realistas. En este entorno, las pruebas shift-left, en el que las actividades de verificación se realizan lo más temprano posible en el ciclo de desarrollo, aborda esos desafíos de las pruebas en etapas tardías.
Algunos miembros de nuestro equipo en Allegro MicroSystems han adoptado un nuevo enfoque shift-left que utiliza un diseño basado en modelos para bloques DSP que incorpora la generación de código HDL para ASIC de señal mixta, así como la generación de bancos de pruebas de Metodología de Verificación Universal (UVM) para la verificación de nivel RTL. Con este enfoque de verificación basado en modelos, nos beneficiamos de la verificación funcional temprana en Simulink® y una vista en nivel de sistema del diseño que facilita la colaboración entre los ingenieros de sistemas y los equipos de verificación (Figura 1). La verificación temprana del modelo conduce a un HDL de mejor calidad porque los problemas de diseño y requisitos de alto nivel se detectan y eliminan antes de la generación del código. Estimamos que esta detección temprana de errores ahorrará dos meses de esfuerzo de verificación. También nos beneficiamos de las pruebas rigurosas de la implementación de HDL en nuestro entorno UVM y de la reutilización de modelos y activos de prueba en todos los proyectos.
De los requisitos a la especificación ejecutable y la implementación
En un flujo de trabajo de desarrollo tradicional, el ingeniero de sistemas crea requisitos basados en texto que son utilizados por el equipo de diseño digital (arquitectos de sistemas e ingenieros RTL) para producir la especificación y, a partir de ahí, el diseño RTL. Nuestro equipo de verificación digital es responsable de crear un plan de pruebas basado en la especificación y la verificación funcional para garantizar que el diseño RTL cumple con la especificación. En este flujo de trabajo, cuando se detecta un defecto (normalmente al final del ciclo de desarrollo), puede llevar mucho tiempo determinar si la causa raíz se encuentra en la implementación, la especificación o los requisitos originales.
Con nuestro enfoque actual, el flujo de trabajo está diseñado para permitir la verificación de la arquitectura y los requisitos mucho antes. Una vez que el ingeniero de sistemas ha definido los requisitos en Jama Connect®, el equipo de diseño digital crea un modelo de especificación de arquitectura en Simulink. Este modelo actúa como una especificación ejecutable del sistema. Al ejecutar simulaciones con este modelo, el equipo realiza pruebas unitarias y de integración del modelo-in-the-loop para validar los requisitos y verificar la arquitectura (Figura 2). En nuestro primer proyecto con este enfoque, estas simulaciones nos ayudaron a identificar varios problemas, incluido un escenario en el que las instrucciones condicionales se contradecían entre sí, lo que generaba resultados no válidos para algunas combinaciones de estímulos de entrada.
En la siguiente etapa de desarrollo, el equipo traduce el modelo de arquitectura a un modelo de implementación más “compatible con el hardware” en preparación para la generación de código con HDL Coder™. Esto puede incluir, por ejemplo, convertir algoritmos de punto flotante a punto fijo, o cambiar del procesamiento basado en cuadros a la transmisión.
Modelos de banco de pruebas y verificación en Simulink
A medida que el equipo de diseño digital construye componentes en el modelo de implementación, los modelos de banco de pruebas de Simulink para esos componentes se desarrollan en paralelo. Cada modelo de banco de pruebas de Simulink contiene los siguientes subsistemas correspondientes a los componentes UVM: secuencia, controlador, DUT, predictor, monitor y tablero (Figura 3). Solo se requieren los subsistemas de secuencia, DUT y tablero para la generación del banco de pruebas con HDL Verifier™.
El subsistema secuencia genera estímulos para el dispositivo sometido a prueba, o subsistema DUT, que en este flujo de trabajo es el modelo de implementación creado en Simulink. Este subsistema crea y genera estímulos aleatoriamente utilizando código de MATLAB® y bloques de Simulink, que incluye el bloque Test Sequence. Su entrada inicial se utiliza para inicializar el generador de números aleatorios de MATLAB . El subsistema tablero recopila la salida de DUT y la compara con la salida esperada con los bloques Assertion for DPI-C que se utilizan para generar componentes DPI-C que contienen afirmaciones de SystemVerilog (Figura 4). La interfaz de programación directa (DPI) de SystemVerilog es una interfaz entre SystemVerilog y un lenguaje de programación extranjero como C. HDL Verifier puede generar componentes DPI-C que consisten en código C con código contenedor de SystemVerilog; los componentes DPI-C resultantes pueden luego ser ejecutados por simuladores HDL que admiten SystemVerilog.
La ejecución de simulaciones en Simulink con el modelo del banco de pruebas junto con varias herramientas de verificación y validación de modelos, como Simulink Test™, valida aún más el modelo de implementación en base a los requisitos. Los resultados de estas simulaciones pasan de Simulink a Jama para facilitar las pruebas basadas en requisitos. Además, Simulink Design Verifier™ se puede utilizar para identificar la lógica de código no utilizado en el modo.
Generación de código, generación de banco de pruebas y simulación y prueba de HDL
Una vez que se han construido el modelo de implementación y los modelos de banco de pruebas y se han utilizado para completar la fase de verificación del diseño del flujo de trabajo en Simulink, comenzamos la siguiente fase: generación y verificación de código HDL. En esta fase, utilizamos HDL Coder para generar código HDL sintetizable a partir de los componentes del modelo de implementación. También utilizamos HDL Verifier, específicamente la función uvmbuild
del complemento ASIC Testbench para generar bancos de pruebas UVM completos a partir de los modelos de banco de pruebas de Simulink (Figura 5). (Otra función incluida en ASIC Testbench, dpigen
, genera componentes DPI-C a partir de código de MATLAB o modelos de Simulink para equipos de diseño que no utilizan entornos UVM).
Utilizando el banco de pruebas generado, ejecutamos pruebas en nuestro entorno UVM en base al código generado a partir del modelo de implementación utilizando un simulador digital, como simuladores Xcelium™ de Cadence® (Figura 6). Ampliamos el banco de pruebas UVM generado según sea necesario para agregar valores aleatorios restringidos más complejos, verificadores de afirmaciones y grupos de cobertura SystemVerilog para el análisis de cobertura funcional. Cuando una prueba falla en el entorno UVM, utilizamos el valor inicial y la configuración de memoria de la prueba con error para reproducir las condiciones de falla en una simulación de Simulink, lo que hace más fácil para el ingeniero de diseño depurar y remediar la falla, en comparación con la depuración directa en el nivel HDL.
Próximos pasos
A medida que los requisitos de clientes y los plazos de entrega se vuelven más exigentes, el enfoque de verificación basado en modelos que hemos adoptado ayuda a ofrecer algoritmos y sistemas más sofisticados con un plazo de comercialización reducido. Estamos planeando extender el concepto shift-left a otros proyectos, donde esperamos que la reutilización de modelos y entornos de prueba de Simulink asociados por parte del equipo de verificación ahorre dos meses adicionales de esfuerzo invertido en desarrollo en proyectos de complejidad media en Allegro. También estamos explorando oportunidades para que nuestros equipos de ingeniería de sistemas y nuestros clientes reutilicen modelos.
Publicado en 2024