Validación y Verificación (1) Definir conceptos de verificación y validación Importancia de la verificación Conceptos básicos en verificación Diseño de sistemas en chip (SoC), 4º - Roberto Sarmiento ETSIT Bibliografía Janick Bergeron, Writing Tesbenches: Functional Verification of HDL Models. Kluwer Academic Publishers, segunda edición, 2003. ISBN: 1-4020-7401-8 Capítulo 1: Qué es verificación? Capítulo 3: El plan de verificación Rochit Rajsuman, System-on-a-Chip: Design and Test. Artech House, Boston (2000). ISBN:1580531075 Capitulo 4: Validación del diseño Otros libros Paul Wilcox, Professional Verification: A Guide to Advanced Functional Verification. Kluwer Academic Publisher, 2004. ISBN: 1-4020-7875-7 Prakash Rashinhar, Peter Paterson y Leena Singh, System-on-a-chip Verification. Methodology and Techniques. Kluwer Academic Publisher, 2001. ISBN: 1-7923-7279-4 1
Conceptos de Verificación y Validación Validación: Compara un producto o un subproducto con sus propiedades extrínsecas (ejemplos, Se cubren las necesidades de los clientes? El producto hace lo que se pretende que haga?). Verificación: compara las propiedades intrínsecas de un producto con una especificación de alto nivel, un estándar, un proceso, un procedimiento, un requerimiento, etc. Como recordatorio de la diferencia V&V: Validación: estoy haciendo el producto correcto? Verificación: estoy haciendo el producto correctamente? Validación El propósito de la validación es demostrar que un producto o un componente del producto satisfacen todos los requisitos necesarios para su aplicación cuando se utiliza en el entorno previsto. operación, entrenamiento, fabricación, mantenimiento, y servicios de soporte. Validación: Validación Hardware Validación Software Validación de la operación del sistema combinado Funcional & temporal 2
Verificación El propósito de la Verificación es asegurar que el producto seleccionado para una tarea cumple todos los requisitos que se han especificado para esa tarea La verificación es un proceso incremental porque tiene lugar en todo el proceso de desarrollo de un producto, empezando por la verificación de los requisitos, siguiendo a través de la verificación de las fases del diseño del producto y culminando con la verificación del producto terminado La verificación puede ser de dos tipos: Verificación de las especificaciones Verificación de la implementación Qué es verificación del diseño? Para asegurar que el diseño sea correcto (Encontrar tantos errores como sea posible) Design Flow Functional Specification Design Creation RTL Design Implementation Gate Physical Implementation GDSII 3
Dónde están los errores? Especificación funcional Lenguaje natural (español-ingés)/algoritmos Diagramas de tiempos, descripciones a nivel de sistema o comportamiento Realización del diseño Diseño inconsistente con las especificaciones Errores en la codificación RTL (error tipográfico, error lógico) Asumir el entorno de trabajo Implementación del diseño físico Herramientas de síntesis Optimizaciones manuales What is Design Verification? Para asegurar que el diseño sea correcto (Encontrar tantos errores como sea posible) Design Flow Functional Specification Design Creation RTL Design Implementation Gate Physical Implementation GDSII 4
Qué tipo de verificación se usa a cada nivel? Verificación de la arquitectura Custom performance modeling, Algorithm models (MatLab), Formal Model Checking Verificación de la implementación Circuit-level Spice, Fast Spice, Symbolic simulation, Formal Equivalency Gate/Structure Logic Simulation, Formal Equivalency, HW Emulation Timing Static Timing Analysis RTL Logic Simulation, Formal Model Checking, HW Emulation Verificación del proceso de fabricación At-speed Logic Simulation Manufacturing defects ATPG, BIST Verificación de la implementación Verificación del sistema: El sistema funciona? Run application: comprobar resultado final Verificación de módulos: Funciona la comunicación entre bloques? Comprobar la sincronización, latencia Verificación de bloques: Comprobar que unos estímulos de entrada generan los resultados correctos? Comprobar la funcionalidad de los bloques y corner cases. 5
Verificación: bancos de prueba Se realiza a través de los bancos de prueba (tesbench) : Código creado para determinar la entrada (secuencia) a un diseño y comprobar su salida Se puede realizar en VHDL, Verilog, C, C++, etc. Testbench DUV Verificación: bancos de prueba Los bancos de prueba se pueden realizar para verificar: 1. Transacciones. Para comprobar buses y circuitos de interfaz. Incluye un generador de transiciones válidas (control y datos) y un analizador de resultados 2. Instrucciones. Para arquitecturas tipo ISA. Requiere modelos ISA y verificar todas las instrucciones 3. Random testing. Para encontrar errores muy atípicos. 4. Regression testbenches. Para encontrar errores específicos. Es incremental y debe ejecutarse en cada cambio del diseño. 5. Code coverage. Para comprobar funciones omitidas, el retorno en un salto, etc. Lo hacen automáticamente las herramientas. 6. Comportamiento funcional. Verifica la función para una aplicación concreta. Debido a tiempo de computo está limitado en el número de ciclos 6
Principales problemas en el diseño Dónde están los errores? Errores de diseño 82 Espec. Incorrectas/incompletas 47 Cambios en las espec. 32 Mal uso de IP anteriores 16 IP incorrecto/incompleto 10 Otros 4 0 10 20 30 40 50 60 70 80 90 7
Dónde están los errores? Causas concretas para rediseño Costes de las máscaras 60% de los diseños no funcionan la primera vez: necesitan uno o más rediseños Complejidad de la verificación Para un circuito con 100 registros (un diseño pequeño) Número total de estados = 2 100 = 10 30 = 10 24 M Requiere (en peor de los casos) al menos 10 24 M ciclos para probar todas las posibles situaciones Por tanto las simulaciones pueden únicamente cubrir una parte pequeña de todos los casos La complejidad de la verificación crece en función de múltiplos de la Ley de Moore 10X para los ASICs 100X para los sistemas basados en ASIC y para los SOCs que incluyen software empotrado 8
Complejidad de la verificación Complejidad de la verificación ƒ( complejidad de la arquitectura, cantidad de reutilización, frecuencia de reloj, tiempo de peor caso de ejecución del software, experiencia de los ingenieros) Ciclos de verificación 10B 100M 1M 1996 1990 2002 100K 1M 10M Número de puertas efectivo Importancia de la verificación La verificación constituye el 70% del esfuerzo de diseño Design Complexity Time to Market Nº de ingenieros de verificación = 2 x Nº de ingenieros de diseño Código de los bancos de prueba = 80% de todo el código generado 9
Coste de encontrar errores (bugs) Time to fix a bug System Module Block Design integration stage RESPIN Chip NREs increasing making respins an unaffordable proposition Average ASIC NRE ~$122,000 SOC NREs range from $300,000 to $1,000,000 Experiencia típica de verificación Functional testing Purgatory Tapeout Bugs per week Weeks 10
Hay problemas? Qué problemas? My biggest problem about design verification is that the time is never enough. I can only do my best to run more simulation, but I don t know whether it is sufficient. --- Broadcom designer (similar comments from many others) It is very hard to write the testbenches and assertions for the design, since I am not a designer. Ask the designer to do it more? No way!! --- Sun Microsystems verification engineer (similar comments from many others) Cuál es realmente el problema? Gap entre diseñadores e ingenieros de verificación (para diseñadores) Pensé que había corregido todos los errores (para ingeniero de verificación) Busco formas de entender el diseño mejor Las metodologías de verificación no son óptimas Siempre se necesita aprender más sobre nuevas alternativas 11
Verificación: modelo de reconvergencia Representación conceptual del proceso de verificación El proceso de verificación consiste en asegurar que el resultado de una transformación es como se pretende o se espera HW Design Specification Netlist Verification Verificación: el factor humano RTL Coding Specification Document Interpretación Netlist La intervención humana genera incertidumbre Para reducir los errores hay que usar Automatización Definir los procesos con transformaciones estándar Introducir redundancia. Verification 12
Verificación: el factor humano Introducir redundancia conlleva más recursos humanos y por tanto más NRE RTL Coding Specification Interpretación Interpretación Verification Netlist Verificación: Qué se verifica? Dependiendo del origen y el punto de reconvergencia se estarán verificando diferentes cosas. Con frecuencia esto viene determinado por la herramienta usada: Verificación funcional. Tiene como propósito fundamental asegurar que el diseño implementa correctamente la funcionalidad Verificación formal. Forma analítica de determinar que las transformaciones realizadas son correctas 13
Verificación formal Verificación formal. Forma analítica de determinar que las transformaciones realizadas son correctas No elimina la necesidad de testbench La verificación formal puede dividirse en dos categorías: Comprobación de equivalencia (equivalence checking) Comprobación de modelo (model checking) Verificación formal: equivalence checking La equivalence checking prueba que la entrada y la salida de un proceso es lógicamente equivalente y que la transformación realizada preserva su funcionalidad Síntesis RTL o netlist Equivalence Checking RTL o netlist Ejemplos: proceso de síntesis, introducción de scan, síntesis del árbol de reloj, etc. 14
Verificación formal: model checking Model checking. Busca violaciones de las reglas introducidas por el usuario sobre el comportamiento del sistema. RTL coding Especificaciones Interp. Assertions Model Checking RTL Es necesario determinar que assertions deben ser introducidas para comprobar cierta parte de la funcionalidad del sistema Útil para encontrar patologías que no se tuvieron en cuenta en las especificaciones Verificación funcional La verificación funcional compara la implementación de un diseño con sus especificaciones RTL coding Especificaciones RTL Verificación funcional Se realiza a través de la generación de bancos de prueba Cuestiones importantes (para toda verificación): Code coverage Metrics 15
Verificación funcional: enfoques blackbox DUT Se realiza sin conocimiento de la implementación a través de un modelo de alto nivel. Es independiente del diseño Reference model = Yes/No whitebox Total visibilidad y observabilidad (monitors/assertions) graybox Es un blacbox testcase escrito con total conocimiento de los detalles internos. Se ejecutan casos particulares a la implemntación específica DUT DUT Reference model = Yes/No Verificación funcional: enfoques Blackbox: propiedades Sobre-esfuerzo de verificación reducido Tiempo de debugging largo Whitebox: propiedades early debugging Difícil de reutilizar y de manejar whitebox o blackbox por si solos son inadecuados Whitebox puro no sirve para encontrar errores en el sistema Blackbox puro no sirve para encontrar errores de estado Ninguno resuelve el problema de forma separada Graybox es el modelo más adecuado 16
Verificación vs. Test HW Design Manufacturing Specification Netlist Silicon Verification Testing Verificación vs. Test Design Specification Design Creation Design Implementation Chip Manufacture High-level spec RTL design Synthesis/P&R Verification Object design Methodologies Simulation Emulation Formal techniques ICs Testing Object chip Methodologies ATPG Fault Simulation Scan / BIST 17