Visualizadores de ondas
Ni que decir tiene que la forma más básica de visualización de resultados es mediante un visualizador de ondas.
- Todos los entornos comerciales de simulación basados en HDL tienen asociada una herramienta de visualización de resultados mediante un visualizador de ondas
- Los entornos libres de simulación no lo suelen incorporar, si bien es verdad que eso no suele constituir un problema gracias a los visualizadores gratuitos de formatos de forma de onda estándares como el Valeu Change Dump VCD.
Es una buena opción para la observación con detalle, de un comportamiento del diseño ante los estímulos recibidos; pero no es una opción adecuada cuando se deben comprobar centenares o miles de situaciones diferentes repartidas en el tiempo de simulación. Solo si existe un fallo detectado en nuestro sistema de comprobación de resultados, es factible verlo en detalle con un visualizador de ondas; pero evidentemente debería haber un chequeo de resultados previo que debe de hacerse lo más automático posible y mediante el propio banco de pruebas realizado en HDL
Comprobación de resultados con HDL
Vamos a establecer unos condicionantes de partida bastante usuales en diseños sencillos
- Supongamos (lo cual suele ser una buena suposición) que conocemos el comportamiento que tiene que tener nuestro diseño antes los estímulos que nos hemos encargado previamente de generar con nuestro banco de pruebas. Normalmente ese comportamiento deseado lo podemos tener representado mediante unos vectores (“golden vectors”). Fijémosnos que esto es bastante habitual y es factible en diseños en los cuales los modos de funcionamiento que debo de comprobar no suelen superar unas decenas de situaciones establecidas en las especificaciones.
- Al igual que estabeciamos en la generación de estímulos, la comprobación de resultados debe de ser robusta en su utilización tanto en disñeos de tipo RTL (sin retardos) como en diseños a nivel “gate level” (con retardos muy aproximados a los reales).
Ante estos condicionantes, vamos a ver una solución de comprobación de resultados muy sencilla, en la cual vamos a manejar “tasks” básicos que tengan como argumento de entrada el valor esperado y que el momento de comprobación lo estableceremos en el tiempo mediante un “initial” general que llamará a dichos procedimientos previamente definidos. Veámoslo en el siguiente vídeo trabajando con un modelo RTL (“Cero delay”)
Cuando el diseño a comprobar tiene retardos, debemos ser más cuidadosos porque puede ser que el dato obtenido lo estemos comprobando con el esperado cuando aun no se ha estabilizado el mismo. Vamos a ver dicha problemática en el siguiente vídeo , en el cual hemos emulado con un diseño RTL con retardos, algunas de las situaciones posibles en diseños a nivel “Gate Level”.