Resultados

En esta experiencia, no s´olo son considerados los resultados de la verificaci´on, sino tambi´en se considera el esfuerzo humano invertido en aprender las tecnolog´ıas aplica- das asi como el tiempo invertido en la instanciaci´on del framework. La siguiente sub- secci´on describe en primer lugar los errores detectados en el m´odulo IEEE-ADDSUB y luego se analizan los resultados de la aplicaci´on de ambos frameworks.

3.7.1.

Resultados de la verificaci´on funcional

Estas nuevas metodolog´ıas son aplicadas luego de que el DUV ha sido probando utilizando m´etodos cl´asicos como tests dirigidos e inspecci´on de c´odigo.

Ambos entornos evaluados llevan al DUV a producir los mismos errores. En par- ticular, los errores evidencian diferencias en los signos de algunos resultados y errores al indicar flags en casos no extremos. Los mismos errores se producen independien- temente del formato. A continuaci´on se muestran alg´unos de los errores detectados:

a. Caso de prueba 3: Caso de ejemplo:∞ + 1.454E20 Error detectado: El dise˜no dispara el flag de Inexacto

b. Caso de prueba 8: Caso de ejemplo: 0E-71 + -3.920689E-26 Error detectado: El dise˜no dispara los flag de Inexacto e Infinito.

c. Caso de prueba 11: Caso de ejemplo:∞ + (−∞) Error detectado: El resutado del dise˜no (sNaN ) difiere en signo con el modelo de referencia.

La verificaci´on basada en frameworks propuesta dirige al DUV a los mismos errores que no fueron detectados previamente con los m´etodos tradicionales. Esta experiencia demuestra el potencial de las tecnolog´ıas aplicadas as´ı como una forma m´as estructurada que los m´etodos tradicionales para evaluar dise˜nos.

Cap´ıtulo 3. Experiencias aplicando Frameworks para Verificaci´on Funcional en

unidades de punto flotante 59

3.7.2.

Evaluaci´on de la experiencia

En esta experiencia, adem´as del esfuerzo humano, se analiza alg´unos criterios de calidad y caracter´ısticas expuestas sobre los frameworks aplicados.

i. Usabilidad: T&T fue inicialmente escrito en C++ con el objetivo de proveer soporte para la POO. Luego, los autores decidieron reescribirlo usando Sys- temVerilog de modo tal de proveer una interfaz con un lenguaje orientado a la verificaci´on funcional. Puede suceder que los ingenieros electr´onicos posean mayor experiencia en la programaci´on con C++ por lo tanto el tiempo de pues- ta en marcha de T&T sea menor al tiempo de instaciaci´on de OVM. Por otro lado, OVM fue concebido como un framework en SystemVerilog puramente orientado a objetos, por lo cual puede resultar m´as accesible para ingenieros de la comunidad inform´atica.

ii. Portabilidad: T&T provee una amplia lista de posibles simuladores donde ser ejecutado. La migraci´on del c´odigo T&T a otro simulador implica simplemente en editar el script de compilaci´on. A diferencia de T&T, la lista de simuladores soportados por OVM es m´as corta y s´olo se provee documentaci´on para el uso en simuladores de Cadence y de Mentor Graphics.

iii. Reusabilidad: Dado que varios de los componentes de OVM heredan de una superclase (ovm component ), los ingenieros pueden modificar o reusar varios componentes seg´un su necesidad. Por otro lado, y a pesar de que T&T provee un entorno de verificaci´on completo, resulta necesario implementar todas las capas del framework para verificar un dise˜no. Esta actividad puede insumir demasiado tiempo para un proyecto simple. Para este proyecto en particular, aplicar OVM insume el 50 % menos de l´ıneas de c´odigo que T&T.

iv. Disponibilidad: T&T es una alternativa de c´odigo abierto propuesta y admi- nistrada por dos ingenieros. La informaci´on sobre bugs y documentaci´on es publicada a traves de foros y listas de difusi´on. Por otro lado, si bien el c´odigo de OVM es abierto, es soportado y mantenido por dos compan´ıas l´ıderes en he- rramientas para dise˜no electr´onico (Mentor Graphics and Cadence). El soporte

Cap´ıtulo 3. Experiencias aplicando Frameworks para Verificaci´on Funcional en

unidades de punto flotante 60

t´ecnico as´ı como su documentaci´on y versiones son actualizadas frecuentemen- te.

v. Alternativa de c´odigo abierto: En algunos proyectos, el costo de las herra-

mientas de simulaci´n profesionales pueden incrementar considerablemente el presupuesto. A pesar de que SystemVerilog es un est´andar libre y de que OVM sea framework de verificaci´on libre y de c´odigo abierto en SystemVerilog, no existen simuladores gratuitos que soporten este lenguaje. Por otro lado, la ver- si´on de C++ de T&T con un simulador de c´odigo abierto, tal como GHDL [24] o IcarusVerilog [59], es una combinaci´on atractiva para empresas en desarrollo.

3.8.

Conclusiones del cap´ıtulo

En este cap´ıtulo se describen experiencias al aplicar los Frameworks T&T y OVM en la verificaci´on funcional del dise˜no un m´odulo Sumador / Restador. Dos entornos de verificaci´on gen´ericos son construidos y luego se especializan las clases corres- pondientes al estandar IEEE754-2008. Aunque ambos entornos han descubierto los mismos errores del DUV, se han observado diferentes experiencias considerando ap- titudes del equipo de verificaci´on, aprendizaje de la tecnolog´ıa, costo de la soluci´on, etc. Con respecto al esfuerzo humano, se comprob´o que para el entorno basado en T&T se necesitan mayor cantidad de l´ıneas de c´odigo que para instaciar un entorno en OVM. Por otro lado, T&T resulta de m´as facil comprensi´on con menos cono- cimiento de OOP que OVM. A pesar de que SystemVerilog es un estandar de un lenguaje libre, no existen simuladores libres que lo soporten. En cambio es posible ejecutar la versi´on C++ de T&T en diversos simuladores libres y de c´odigo abier- to (por ejemplo, IcarusVerilog). Finalmente puede destacarse mayor soporte t´ecnico para OVM que para T&T teniendo en cuenta frecuentes actualizaciones tanto del c´odigo fuente como de su documentaci´on.

Cap´ıtulo 4

Dise˜no metodol´ogico de monitores

de verificaci´on para unidades de

punto flotante

Gracias a la capacidad de reprogramaci´on que proveen las FPGAs, un enfoque simple de verificaci´on funcional puede ser realizado mediante la s´ıntesis del dise˜no para un chip espec´ıfico y observando el comportamiento de las salidas en una placa de prototipos. Sin embargo, realizar peque˜nas modificaciones sobre el dise˜no para corregir errores pueden incurrir en largos tiempo de compilaci´on y s´ıntesis hasta po- der probar el dise˜no nuevamente. Este enfoque adem´as de ser lento, no garantiza cobertura funcional, lo que es particularmente serio en un sistema cr´ıtico donde la presencia de un error encubierto es inadmisible. La verificaci´on funcional no suele ser una tarea trivial y en algunos casos resulta en un cuello de botella sobre proyectos de sistemas digitales. Por ejemplo, la verificaci´on de unidades de punto flotante (FPU) ha sido reconocida como una tarea compleja [30]. En particular esa dificultad aparece por tres diferentes aspectos. Primero, el espacio de b´usqueda crece exponencialmen- te cuando el dominio de entrada aumenta. Segundo e independientemente del ancho de los operandos, cada operaci´on puede contener combinaciones de operandos que implican un an´alisis m´as complejo del resultado, por ejemplo, not a number (NaN). Tercero, el est´andar introduce la noci´on de cohorte para el formato de punto flotante decimal. Esto significa que, para un operando dado existen diversas formas de repre-