Validación y Verificación (1) - IUMA -...

1

Diseño de sistemas en chip (SoC), 4º - Roberto Sarmiento ETSIT

Validación y Verificación(1)

Definir conceptos de verificación y validación

Importancia de la verificaciónConceptos básicos en verificación

Diseño de Sistemas en Chip (SoC), 5º - Roberto Sarmiento

BibliografíaJanick Bergeron, Writing Tesbenches: FunctionalVerification 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

E.T.S. de Ingenieros de Telecomunicación Diseño de Sistemas en Chip (SoC)

®«Roberto Sarmiento Rodríguez»

2


Conceptos de Verificación y ValidaciónValidació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ónEl 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 HardwareValidación SoftwareValidación de la operación del sistema combinadoFuncional & temporal



3


VerificaciónEl 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)

RTL GDSIIGateDesign

ImplementationPhysical

ImplementationRTL GDSIIGateDesign

Creation

Design Flow

FunctionalSpecification



4


¿Dónde están los errores?Especificación funcional

– Lenguaje natural (español-ingés)/AlgoritmosDiagramas 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?

RTL GDSIIGateDesign

ImplementationPhysical

ImplementationRTL GDSIIGateDesign

Creation

Design Flow

FunctionalSpecification

Para asegurar que el diseño sea correcto(Encontrar tantos errores como sea posible)



5


¿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.



6


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



7


Principales problemas en el diseño


¿Dónde están los errores?

47

32

16

10

4

82

0 10 20 30 40 50 60 70 80 90

Errores de diseño

Espec.Incorrectas/incompletas

Cambios en las espec.

Mal uso de IP anteriores

IPincorrecto/incompleto

Otros



8


¿Dónde están los errores?

60% de los diseños no funcionan la primera vez: necesitan uno o

más rediseños

Costes de las máscarasCausas concretas para rediseño


Complejidad de la verificaciónPara un circuito con 100 registros (un diseño pequeño)

Número total de estados = 2100 = 1030 = 1024M

Requiere (en peor de los casos) al menos 1024M 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



9


Complejidad de la verificaciónComplejidad 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)

1996

1990

2002

100K 1M 10M

10B

100M

1M

Ciclos de verificación

Número de puertas efectivo


Importancia de la verificaciónLa verificación constituye el 70% del esfuerzo de diseño

Nº de ingenieros de verificación = 2 x Nº de ingenieros de diseñoCódigo de los bancos de prueba = 80% de todo el código generado

DesignComplexity

Time to Market



10


Coste de encontrar errores (bugs)

Time to fix a bug

Block

Module

System

Design integration stage

•Chip NREs increasing making respins an unaffordable proposition•Average ASIC NRE ~$122,000•SOC NREs range from $300,000 to $1,000,000

RESPIN


Experiencia típica de verificación

Functionaltesting

Weeks

Bug

s pe

r wee

k

TapeoutPurgatory



11


¿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



12


Verificación: modelo de reconvergencia

Specification

Verification

HW Design

Netlist

Representación conceptual del proceso de verificaciónEl proceso de verificación consiste en asegurar que el resultado de una transformación es como se pretende o se espera


Verificación: el factor humano

La intervención humana genera incertidumbrePara reducir los errores hay que usar

AutomatizaciónDefinir los procesos con transformaciones estándarIntroducir redundancia.

SpecificationDocument

Verification

RTL Coding

NetlistInterpre-tación



13


Verificación: el factor humanoIntroducir redundancia conlleva más recursos humanos y por tanto más NRE

Specification

Verification

RTL Coding

NetlistInterpre-

taciónInterpre-tación


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



14


Verificación formalVerificació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 (equivalencechecking)

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

Ejemplos: proceso de síntesis, introducción de scan, síntesis del árbol de reloj, etc.

RTL o netlistEquivalence

Checking

Síntesis

RTL o netlist



15


Verificación formal: model checkingModel checking. Busca violaciones de las reglas introducidas por el usuario sobre el comportamiento del sistema.

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

EspecificacionesModelChecking

RTL coding

RTLInterp.

Assertions


Verificación funcionalLa verificación funcional compara la implementación de un diseño con sus especificaciones

Se realiza a través de la generación de bancos de pruebaCuestiones importantes (para toda verificación):

– Code coverage– Metrics

Especificaciones

Verificación funcional

RTL coding

RTL



16


Verificación funcional: enfoquesblackbox– Se realiza sin conocimiento de

la implementación a través de un modelo de alto nivel. Es independiente del diseño

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

Referencemodel

= Yes/No

DUT

Referencemodel

= Yes/No

DUT


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

Verificación funcional: enfoques



17


Verificación vs. Test

Specification

Manufacturing

TestingVerification

HW Design

SiliconNetlist


Verificación vs. Test

DesignSpecification

DesignCreation

DesignImplementation

High-level spec RTL design Synthesis/P&R

Chip Manufacture

ICs

Verification Testing

• Object design• Methodologies

SimulationEmulationFormal techniques

• Object chip• Methodologies

ATPGFault SimulationScan / BIST



Validación y Verificación (1) - IUMA -...

Documents

Transcript of Validación y Verificación (1) - IUMA -...