Aceleración de la verificación de circuitos integrados de procesamiento de señales con HDL Verifier

La verificación de diseños de circuitos integrados (CI) de procesamiento de señales plantea varios desafíos únicos que pueden superar los métodos de prueba convencionales. La complejidad algorítmica de los filtros, mezcladores y otras funciones avanzadas de procesamiento de señales requiere una validación rigurosa para garantizar que el CI implementado se comporte como se espera con precisión de bits. Además, debido a que los circuitos integrados suelen operar en una amplia gama de entradas y configuraciones posibles, es esencial evaluar casos límite y escenarios inusuales pero críticos que pueden pasar inadvertidos en los planes de prueba centrados en secuencias predefinidas y predecibles.

Mi equipo en NXP ha adoptado un nuevo flujo de trabajo para verificar circuitos integrados y abordar estos desafíos. Basado en MATLAB^®, Simulink^® y HDL Verifier™, este flujo de trabajo incorpora verificación aleatoria restringida y técnicas de Metodología de Verificación Universal (UVM) para validar casos extremos y explorar el espacio de estados con entradas aleatorias mientras se mantiene el control a través de restricciones (Figura 1). En este flujo de trabajo, que utilizamos recientemente para verificar un CI de sintonizador de radio para la industria de la automoción, se exportan modelos de Simulink y MATLAB como componentes SystemVerilog DPI-C utilizando HDL Verifier, y se integran como modelos de referencia en el banco de pruebas de verificación en un entorno de verificación basado en el simulador de Cadence.^® Xcelium™. Este enfoque permitió reducir el tiempo de verificación entre 20 y 30 por ciento, aumentar la cobertura de pruebas y encontrar más defectos de implementación en una etapa más temprana del desarrollo.

Comparación de flujos de trabajo antiguos y nuevos

En el pasado, cuando probábamos diseños de circuitos integrados similares, normalmente utilizábamos MATLAB para generar estímulos de entrada para el sistema completo. Luego ejecutábamos simulaciones en MATLAB o Simulink y capturábamos los resultados como un patrón de referencia de alto nivel. Una vez completada la implementación de RTL, aplicábamos los mismos estímulos al DUT y comparábamos los resultados con la referencia de alto nivel. Si bien este enfoque funcionaba bien, tenía ciertas desventajas. En primer lugar, la verificación se realizó, en su mayor parte, de extremo a extremo, lo que dificultó identificar la causa raíz de los defectos ya que todos los componentes se probaban juntos. En segundo lugar, no fue fácil realizar una verificación aleatoria restringida. Si bien se verificaron escenarios y casos prácticos comunes, muchos casos extremos no lo fueron. En tercer lugar, no se adhirió al UVM, que desde entonces se ha convertido en el marco estándar en nuestra forma de implementar bancos de pruebas.

Por el contrario, el nuevo flujo de trabajo permite la reutilización directa de nuestros modelos de referencia de MATLAB y Simulink existentes en nuestro entorno de simulación HDL (Cadence Xcelium). Cada componente del modelo de referencia se corresponde con su equivalente en el DUT. La cadena de procesamiento de señales de ejemplo que se muestra en la Figura 2, por ejemplo, incluye un filtro modelado en Simulink, seguido de un mezclador y un segundo filtro modelado en MATLAB. Usamos HDL Verifier para generar código C para el modelo con el contenedor SystemVerilog DPI-C, lo que permite integrar cada componente en el banco de pruebas.

Los componentes del modelo de referencia y los componentes DUT se ejecutan en paralelo en el entorno de simulación HDL y sus salidas se evalúan de forma dinámica mediante un verificador que actúa como un scoreboard UVM, realizando comparaciones con precisión de bits de la salida de cada par de componentes asociados (por ejemplo, el mezclador del modelo de referencia y el mezclador DUT) y de la cadena completa de extremo a extremo.

Aleatorización de entradas y visualización de resultados

Después de ejecutar pruebas preliminares, en este caso con un conjunto de transmisiones de radio AM, FM y DAB (transmisión de audio digital) predefinidas, en el banco de pruebas para verificar la funcionalidad básica de los algoritmos de procesamiento de señales, el siguiente paso en el flujo de trabajo es la verificación aleatoria restringida. Esta etapa implica simulaciones extensas en las que a todos los parámetros de configuración del diseño se asignan valores aleatorios dentro de un rango restringido. Por ejemplo, variamos la configuración del mezclador, la configuración del filtro, los retrasos, las ganancias y otros parámetros de configuración clave y ejecutamos simulaciones para evaluar el rendimiento del diseño para cada conjunto de opciones de configuración aleatorias.

Para cada prueba, podemos revisar resultados detallados, incluidas las configuraciones específicas que se utilizaron, las entradas utilizadas como estímulos para el IP, los resultados de la implementación del modelo de referencia, los resultados de la implementación de RTL y el resultado de la comparación del verificador (Figura 3).

También revisamos informes que muestran resultados agregados para una serie completa de componentes (Figura 4). Estos informes muestran la cantidad de comprobaciones realizadas para cada componente de la cadena y la cantidad de errores, es decir, la cantidad de discrepancias identificadas entre las salidas del modelo RTL y del modelo de referencia.

Cuando se identifica un error, verificamos la implementación del modelo de referencia en MATLAB o Simulink, y verificamos la implementación RTL. En algunos casos, hemos rastreado el origen de la discrepancia hasta el diseño de referencia original, pero el problema más a menudo surge de un error de implementación de RTL. En cualquier caso, una vez que se diagnostica y se soluciona el defecto, volvemos a ejecutar las simulaciones de prueba para verificar que la solución haya resuelto por completo cualquier diferencia entre el modelo de referencia y la implementación RTL.

Principales mejoras y próximos pasos

Una clara ventaja de nuestro nuevo flujo de trabajo basado en HDL Verifier es la capacidad de identificar rápidamente el origen de los defectos. En comparación con un enfoque que se basa en pruebas de extremo a extremo, un enfoque orientado a UVM que permite pruebas en nivel de componente y nivel de sistema (como el que hemos aplicado) hace que sea mucho más fácil identificar el subsistema con defecto, así como los estímulos específicos para ese componente que se pueden usar para replicar el defecto.

Además, debido a que las configuraciones aleatorias a menudo prueban el sistema de manera que los ingenieros de diseño pueden no haber previsto, el nuevo flujo de trabajo facilita el descubrimiento de defectos de implementación mucho antes en el proceso de desarrollo en comparación con los planes de prueba convencionales centrados en casos prácticos bien establecidos. En resumen, podemos encontrar defectos sin realizar comprobaciones manuales y sin perder tiempo pensando en escenarios inusuales y casos extremos para probar.

Podemos reutilizar nuestros modelos de Simulink y MATLAB existentes en simulaciones HDL, y los beneficios de esta reutilización continúan incrementándose con cada nueva iteración o revisión posterior del CI. En conjunto, estas ventajas contribuyeron a la reducción significativa del tiempo de verificación (hasta un 30 %) que logramos en el circuito integrado de procesamiento de señales de radio. Basándonos en esta métrica y otras ventajas que hemos obtenido, otros equipos de NXP están buscando adoptar el mismo flujo de trabajo para el desarrollo de un extremo frontal de radio para un IC de radar y otros diseños de IC.