¿Qué son las aserciones?
Su propósito es asegurar la consistencia entre lo que el diseñador intenta diseñar y lo que la implementación realmente hace.
“Assertion” es un estamento que describe el comportamiento deseado del diseño. Esa pieza de código está en todo momento inspeccionando nuestras señales y la interrelación entre ellas (autochequeo) y mientras ese comportamiento deseado se cumpla la aserción no dice nada. Pero si ese comportamiento deseado no se cumple entonces se dice que la aserción Falla y empieza a emitir información importante para el ingeniero que está diseñando y verificando un bloque funcional.
Las claves de las “assertions” :
1. Detección del Error detection : Si la aserción se viola (falla), el simulador lo detecta.
2. Aislamiento del Error : Las señales involucradas en esa violación son identificadas por el simulador.
3. Notificación del Error : La fuente del error es notificada al usuario.
Tipos de notificaciones
Las notificaciones consisten en un mensaje y un grado de severidad del fallo de comportamiento detectado. Las notificaciones se realizan después de la palabra reservada else mediante las siguientes funciones predefinidas:
- $fatal(“…”); Se cierra la simulación, no tiene ningún sentido continuar
- $error(“…”); Se suele para la simulación – se puede continuar si el usuario lo desea
- $warning(“…”); Parecido al error; pero se puede inhabilitar
- $info(“…”); Se muestra un mensaje por consola sin parar la simulación. Cómo bien dice la palabra, puede ser una información que necesitamos conocer sin que sea realmente un fallo
¿Quién hace las aserciones?
Para contestar esa pregunta debemos centrarnos en las aserciones concurrentes, que son sin duda el elemento fundamental en el que se basa la metodología ABV( Assertion Based Verification).
Las aserciones deberían ser escritas por los mismos ingenieros que se han dedicado a escribir el RTL del diseño. De hecho el lugar natural para esas aserciones concurrentes es en el interior del módulo que yo quiero autochequear. Por supuesto esto hace que dicho código sea analizado tanto por las herramientas de síntesis (por ejemplo el sintetizador incluido en el flujo de Quartus) como por las herramientas de verificación (un simulador HDL como Questasim).
Afortunadamente todo lo que escribamos en systemVerilog perteneciente al mundo de las aserciones (SVA) es ignorado por los compiladores de los sintetizadores y no intenta implementarlo con lo cual no generará errores.
Sin embargo los simuladores HDL no solo analizan este código (para detectar errores sintácticos) sino que cuando se ejecutan recopilan la actividad de estas monitorizaciones continuas ejercidas por estas aserciones y las representan con detalle en diferentes ventanas e informes específicamente desarrollados para este tipo de verificación.
¿Qué tengo que monitorizar?
Cuando tengo un diseño tengo unas especificaciones de cómo debe de comportarse un circuito en sus salidas cuando recibe unas entradas determinadas. Por supuesto en la mayoría de los sistemas que tenemos que diseñar ese comportamiento de las salidas no solo depende de las entradas sino de un histórico del sistema que viene representado por el estado del control path.
Supongamos un pequeño sistema con su control-path y su data path formado por diferentes subsistemas como contadores, registros, circuitos aritméticos , registros de desplazamiento , memorias, etc.
Voy a listar que se podría chequear:
- Los modos de funcionamiento de los subsistemas: por ejemplo se que en un estado debe de incrementarse un contador y compruebo que el contador realmente se incrementa en ese estado. Digamos que autochequeo que los mandatos del control path efectivamente surten efecto en ese elemento del data path en concreto.
- El modo de funcionamiento general: por ejemplo sé que en un estado de un microprocesador voy a sumar una variable que se va a direccionar dependiendo de un valor almacenado en memoria RAM y le voy a sumar un valor inmediato expresado en la propia instrucción y lo voy a almacenar en el banco de registros. Pues al final de esa instrucción compruebo si efectivamente se ha realizado ese comportamiento.
- Puedo comprobar las salidas de control si son congruentes con el estado del sistema.Por ejemplo tengo una fifo que he llenado y sé que el flag de fifo llena debe de ponerse a cero. Pues compruebo si hace realmente eso.
- También puedo comprobar que los estímulos recibidos por el sistema (Entradas) son acordes a las especificaciones y que no someto el DUV a entradas no legales o incluso prohibidas. Un ejemplo sería en el caso de la FIFO comprobar que nunca escribo de la FIFO llena (sin lectura simultánea) o nunca leo de una FIFO vacía (sin escritura simultánea)