máster en electrónica, tratamiento de la señal y...

Máster en Electrónica, Tratamiento de la Señal y Comunicaciones 2012/2013

5 Pruebas del sistema.

Miguel Cordero Limón 79


5.1 Introducción.

La depuración y verificación de la implementación del algoritmo de conformado en la FPGA se ha

realizado empleando dos técnicas.

Por un lado se ha hecho uso de la herramienta ChipScope Pro de Xilinx la cual incluye una lógica

adicional en la FPGA (denominada Integrated Logic Analizer o ILA) que permite registrar señales

internas de la FPGA en tiempo de ejecución para su posterior visualización y realizar la depuración

de bloques concretos de la implementación. En el presente trabajo se ha empleado ChipScope

para la validación del bloque DDS.

Por otro lado se han realizado pruebas de co-simulación hardware las cuales permiten interactuar

con la implementación corriendo en la FPGA desde Simulink enviando estímulos al algoritmo

corriendo en la FPGA y recogiendo las señales de respuesta del mismo. En el presente trabajo la

prueba realizada ha consistido en establecer una dirección de apuntamiento deseada y comprobar

los valores de los pesos del conformador obtenidos. Posteriormente se han simulado con ArrayCalc

los patrones de radiación que se hubieran obtenido con esos pesos. La diferencia con respecto a la

comparación realizada en la sección 4.3 es que en este caso el algoritmo está corriendo realmente

en la FPGA mientras que en la sección 4.3 la ejecución del algoritmo está siendo simulada en el

entorno de Simulink.

5.2 Depuración de bloques con ChipScope.

Como se ha comentado anteriormente, la herramienta ChipScope Pro de Xilinx permite registrar en

tiempo de ejecución las señales internas del diseño que se ha cargado en la FPGA. En el flujo de

diseño basado en modelos que se ha seguido, la lógica correspondiente al ILA de ChipScope se

introduce empleando el bloque homónimo en System Generator el cual se muestra en la figura 44.

Las entradas de este bloque son las señales que se van a monitorizar y las señales que van a actuar

como señal de disparo que va a determinar cuándo se va a empezar el registro de las señales. Solo

es posible instanciar un bloque de ChipScope en un modelo de System Generator de forma que

todas las señales a registrar deben conectarse a ese bloque.



El bloque ILA implica el consumo de recursos adicionales de la FPGA por lo que para poder

emplearlo es necesario que la FPGA disponga de recursos suficiente para el bloque ILA y recursos

adicionales para que no afecte a la operación del diseño propiamente dicha.

Una vez ubicado el bloque y compilado el modelo, se genera un fichero con extensión .cdc en el

directorio en el que se ha generado el bitstream. Dicho fichero contiene la información de las

señales que la herramienta capturará en tiempo de ejecución. Una vez programada la FPGA se

carga el fichero .cdc y se configura el disparo que controlará el registro de la señal como se

muestra en la figura 41.

Las señales presentes en las entradas del ILA pueden ser capturadas en tiempo real durante la

ejecución del sistema generado en la FPGA cuando se cumpla la condición de disparo especificada.

En el presente trabajo se ha empleado la herramienta ChipScope para comprobar el correcto


Figura 40. Bloque de ChipScope en System Generator.

Figura 41. Ventana de configuración de la condición de disparo.


funcionamiento del bloque DDS basado en LUT desarrollado para la generación de seno y coseno.

En la figura 42 se ha representado el valor del argumento de entrada a la LUT y la señal resultante.

Otra representación que puede ser útil para la depuración de algunas señales es la representación

de cada una de las líneas binarias que componen la señal como se muestra en la figura 43. En las

anteriores figuras se muestra el resultado cuando el bloque se emplea en modo coseno. Como

puede observarse la señal resultante para los distintos valores de entrada del bloque DDS es

efectivamente la señal coseno.

Figura 43. Representación waveform de las líneas digitales que conforman la señal.

En resumen, ChipScope proporciona una herramienta ligera y versátil que hace las veces de

analizador lógico integrado, lo cual evita la necesidad de trabajar con excesiva instrumentación


Figura 42. Representación bus plot de la señal coseno generada por el bloque DDS (azul) ante los distintos valores de entrada (rojo).


durante el proceso de depuración y verificación de un diseño microelectrónico digital generado

mediante System Generator.

5.3 Co-simulación hardware.

La co-simulación hardware es uno de los procesos de depuración que System Generator for DSP

ofrece como valor añadido respecto a las herramientas de simulación tradicionales. En este modo

de funcionamiento, el diseño realizado en System Generator puede ser ejecutado directamente en

la FPGA de forma que las entradas a la misma pueden ser proporcionadas por otros bloques del

modelo de Simulink y las salidas de la FPGA ser empleadas como entradas a otros bloques del

modelo en Simulink. Este procedimiento permite comprobar el correcto funcionamiento del

diseño realizado.

El hecho de que se pueda incluir el diseño de la FPGA en un modelo de Simulink más complejo

permite comprobar las prestaciones del diseño de la FPGA en el sistema completo a través de un

modelo Simulink del mismo. El proceso de rodear al diseño de la FPGA de un modelo que simula el

comportamiento del resto del sistema en el que va a ser englobado y de correr el diseño en el

sistema real alimentando sus entradas con señales procedentes del modelo y recogiendo esas

señales en otros bloques del modelo se suele denominar depuración HWIL o HIL (Hardware in the

Loop).

Para poder realizar la co-simulación hardware es necesario conectar la placa al PC de desarrollo

mediante una interfaz JTAG (estándar IEEE 1149.1). Este estándar proporciona un mecanismo para

comprobar las interconexiones de un circuito integrado una vez que ha sido soldado en una PCB.

También permite testear el propio circuito integrado y observar y modificar el comportamiento del

circuito durante su funcionamiento normal siendo esta última la característica que permite la co-

simulación hardware. Además, para poder realizar la co-simulación hardware de un sistema

basado en una FPGA (normalmente se realiza en una placa de desarrollo) es necesario que

disponer de un BSP (Board Support Package) de System Generator para esa placa. El BSP no es más

que un conjunto de archivos que indican la FPGA concreta de la placa, las asignaciones de pines de

la FPGA con los dispositivos de la placa (LEDs, interruptores DIP, pines GPIO,...) así como la

frecuencia del reloj empleada y el pin por el que se inyecta a la FPGA. La instalación por defecto de



System Generator proporciona BSPs para algunas placas de desarrollo de Xilinx. Para poder realizar

co-simulación HW con otras placas, System Generator dispone de una utilidad denominada

SDBuilder (System Generator Board Description Builder).

Además de la FPGA y la frecuencia y el pin del reloj a emplear, destacan la posición del dispositivo

FPGA en la cadena JTAG (boundary scan), la cual puede determinarse inicializando la cadena JTAG

mediante la herramienta iMPACT o el ChipScope Analyzer, y la longitud del registro de instrucción,

el cual puede consultarse en el manual de usuario de la placa o autodetectarlo si está la placa

conectada al PC por el JTAG en ese momento. Los puertos no mapeados en memoria son todas

aquellas asignaciones de pines en la placa que se deseen incluir en el BSP.

Para realizar la co-simulación hardware es necesario realizar la compilación del diseño de System

Generator desde el bloque token en modo co-simulación hardware. El resultado de la compilación

es un nuevo bloque de System Generator que incorpora la lógica necesaria para realizar la co-

simulación hardware además de todo el diseño del sistema. En la figura 44 se muestra en la parte

superior un diseño en System Generator (en este ejemplo consiste simplemente en un bloque de

retardo) y en la parte inferior el modelo con el bloque resultante de la compilación en modo co-

simulación hardware. La ejecución de este ultimo con la placa de desarrollo FPGA conectada

permite realizar la co-simulación hardware.

En la figura 45 se muestra el modelo de co-simulación hardware correspondiente al diseño del

conformador implementado en System Generator. En este caso la excitación correspondiente al

ángulo de apuntamiento en elevación y acimut se han incluido en el modelo con sendas


Figura 44. Bloque de co-simulación hardware empleado para el proceso de depuración en Simulink


constantes fijas por lo que no hay entradas al bloque de co-simulación hardware. Las señales de

salida del bloque se corresponden con las partes real e imaginaria de los pesos del conformador.

En la figura 46 se muestra el montaje realizado para la ejecución de la co-simulación hardware.


Figura 45. Modelo de Simulink para co-simulación hardware.


Finalmente, en la figura 47 se muestra el patrón de radiación obtenido tras realizar la co-

simulación hardware. Como puede observarse, no se aprecia diferencia con respecto al patrón

obtenido en la simulación realizada en la sección 4.3.


Figura 47. Patrón de radiación obtenido con la implementación en punto fijo en co-simulación hardware.

Figura 46. Montaje para la realización de la co-simulación hardware.


5.4 Resumen.

En el presente capítulo se han presentado los resultados de las pruebas de validación del sistema

realizadas con el algoritmo corriendo en el hardware de la FGPA. Se han realizado dos pruebas

distintas. En la primera prueba, se ha validado la implementación del bloque DDS empleando la

herramienta ChipScope la cual permite visualizar señales internas de la FPGA. A continuación se ha

realizado una co-simulación hardware y se ha comprobado que los resultados son idénticos a los

obtenidos mediante la simulación de la implementación en Simulink.


máster en electrónica, tratamiento de la señal y...

Documents