An´ alsis mediante componentes de verificaci´ on

Dentro de la cadena de an´alisis presentada anteriormente existen etapas que ne- cesitan alg´un tipo de soporte por parte del entorno de verificaci´on. Por ejemplo, para indicar que se han producido errores, es necesario contar con un modelo de referencia que indique cual es el resultado esperado. Adem´as debe de proveerse una estructura que permita ir registrando las secuencias de entradas que se han producido. Fuera del ´ambito de los frameworks, ambos componentes pueden ser vistos como una ´uni- ca unidad conocida como monitor de verificaci´on. Desde un entorno de verificaci´on

Cap´ıtulo 5. Verificaci´on automatizada 92

Análisis de Cobertura de código

Análisis de Cobertura Funcional

Análisis de frecuencia máxima Análisis de área Análisis de consumo Otros análisis bertu is de á ecuen de co s anál

Figura 5.1: Etapas propuestas para el an´alisis

basado en framework hay dos componentes involucrados en esta tarea, el monitor de se˜nales y el Scoreboard. Dado que este trabajo est´a fuertemente sustentado con el uso de frameworks, el tratamiento se realizar´a por separado.

Monitor de se˜nales

Este componente interact´ua directamente con la interfaz del DUV. Su funci´on es generalmente conocida como Anti - Driver, ya que realiza la tarea inversa a este. En general, el monitor realiza las siguientes tareas:

Recolecci´on de se˜nales del DUV: El Monitor decodifica las se˜nales provenientes del DUV y crea una transacci´on de salida de mayor nivel de abstracci´on. Por ejemeplo, a partir de una secuencia de bits, se interpretan, teniendo en cuenta cierto protocolo, y se presenta en formato (Comando, Operaci´on, Dato). Esta transacci´on es enviada posteriormente al Scoreboard.

Verificaci´on de protocolos: Dado que el monitor debe conocer estrictamente el protocolo de comunicaciones que posee el DUV, las violaciones de protocolo y su cobertura funcional son analizadas dentro del monitor.

Cap´ıtulo 5. Verificaci´on automatizada 93

Logging de se˜nales: Las se˜nales deben ser almacenadas para su posterior an´ali- sis y visualizaci´on. En general, los simuladores actuales proveen rutinas para manejo eficiente de archivos.

Scoreboard

Este componente trabaja con transacciones en alto nivel que recibe desde el Monitor. La principal raz´on por la cual el Scoreboard trabaja a este nivel es la inde- pendencia de detalles de implementaci´on del DUV y del modelo de referencia. Esto permite al equipo de verificaci´on utilizar la misma estructura para verificar diferen- tes implementaciones, reutilizando completamente el entorno o bien implementando una acotada y peque˜na porci´on de c´odigo del monitor. Las tareas del monitor son las siguientes:

Analizar cobertura funcional: Utilizando un modelo de cobertura acorde al plan de verificaci´on, se registra la ocurrencia de los atributos de la transacci´on de salida.

Contrastar resultados: La comparaci´on de las se˜nales de salida se realiza uti- lizando un modelo de referencia. El resultado de esta comparaci´on no es so- lamente binaria. Este trabajo propone que los resultados de la comparac´on puedan ser valores num´ericos, como por ejemplo, porcentaje de desviaci´on. Confecci´on de reportes: El scoreboard debe llevar estad´ısticas de fallas y acier- tos. El formato de reporte puede ser un simple archivo de texto separado por comas.

Recopilaci´on de resultados para herramientas externas: Dado que en algunos casos puede ser necesario realizar an´alisis con herramientas externas, debe pro- veerse de m´etodos de comunicaci´on con estas, por ejemplo, archivos de texto o mediante libre´ıas.

Modelos de referencia Software

Resulta valioso poseer de antemano un modelo del dise˜no escrito en alg´un lenguaje de programaci´on de alto nivel. Este tipo de modelos es particularmente ´util cuando

Cap´ıtulo 5. Verificaci´on automatizada 94

el dise˜no est´a orientado a acelerar alguna una rutina software. La mayor´ıa de los entornos de verificaci´on soportan alg´un tipo de integraci´on de rutinas en lenguaje de alto nivel. Por ejemplo, la interfaz DPI (Direct Program Interface) permite incluir dentro de un entorno SystemVerilog rutinas escritas en C++ de forma transparente e invocarlas como si se tratase de una simple funci´on en SystemVerilog.

Modelos de referencia Hardware

En muchas ocaciones, un proyecto de dise˜no de hardware consiste en la optimi- zaci´on de alguna caracter´ıstica de un dise˜n´o existente, por ejemplo, consumo o ´area. En tales casos, el dise˜no existente puede ser utilizado como modelo de referencia ya que este debe ser funcionalmente equivalente al DUV. Desde el Scoreboard, los datos considerados como correctos deben ser vistos a id´entico nivel de abstracci´on.

Modelos de referencia externos

En algunos casos, el DUV realiza cierto tipo de tarea que resultar´ıa costosa computacionalmente la simulaci´on de un modelo de referencia. En otros casos, ya existen herramientas comerciales que realizan esa tarea o bien, ya existe hardware que emula ese comportamiento. En este trabajo, se propone la comunicaci´on desde el entorno simulado (en particular, desde el scoreborard) hacia el exterior utilizando puertos de comunicaci´on. Un ejemplo t´ıpico es la verificaci´on de dise˜nos de filtros en im´agenes. En ese caso, puede utilizarse la herramienta MatLab para realizar el filtrado en paralelo e independiente con la simulaci´on del DUV. La conexi´on en- tre ambas herramientas puede realizarse utilizando sockets TCP o bien mediante librer´ıas compartidas (dll).