Chequeo en el ordenador

Para poder hacer la comprobación funcional de la xIT en el ordenador, es necesario hacer un proyecto en RVC-CAL que tenga una red de actores con el banco de pruebas descrito en el apartado 5.2.2.1.

Cuando ya se ha creado la red de actores con el banco de pruebas, para poder ejecutarla en el ordenador se tiene que hacer click derecho con el ratón sobre el archivo ‘.xdf’ que contenga la red de actores y seleccionar la opción Run As → Run Configurations.... Se abrirá una nueva ventana en la que se podrá seleccionar el lenguaje que se quiere compilar el diseño en RVC- CAL. Esto se hace en la pestaña Compilation settings y es el mismo proceso que si se fuera a compilar con Exelixi, pero en este caso se selecciona el lenguaje C. La pestaña compilación tendrá que quedar como se muestra en la figura Fig. 82.

Una vez modificada la pestaña de Compilation settings, ahora hay que ir a la pestaña de

Compilation Options para modificar el tamaño de las FIFOs que se usarán para la comunicación entre actores. En el caso de esta red, el tamaño mínimo recomendado de FIFO es de 1024 porque el grupo de coeficientes más grande que puede haber es de 1024, para una TU de 32x32. Si se eligiera un tamaño de FIFO más pequeño, el programa se quedaría bloqueado. En la figura Fig. 83 se observa la configuración del tamaño de FIFO.

Fig. 83: Configuración del tamaño de las FIFOs

Con la configuración de las dos pestañas descritas ya es suficiente para generar el código en C que se ejecutará en el ordenador. Haciendo click en el botón Run, se genera todo el código en C dentro de la carpeta seleccionada para guardarlo. Para saber que el código ha sido generado correctamente tiene que aparecer unos mensajes parecidos a los mostrados en la figura Fig. 84 en la consola de Eclipse.

Con el código C ya generado, antes de realizar la compilación se deben realizar unas pequeñas modificaciones al código que implementan las funciones nativas para la escritura en ficheros. Estas funciones se encuentran codificadas dentro del archivo writer.c, localizado en la dirección /libs/orcc-native/src dentro de la carpeta donde se ha guardado el código generado por ORCC.

Las funciones a modificar son las dos utilizas en el actor SimpleWriter, Writer_init() y

Writer_close().

En Writer_init() se tiene que modificar la forma de abrir el archivo, cambiando los parámetros de apertura de “wb” a “ab”. Como la función Writer_init() va a ser utilizada muchas veces por el actor SimpleWriter, con la modificación indicada todo lo que se quiera escribir en el fichero del disco duro será añadido al final de éste, conservando la información escrita con anterioridad. En la figura Fig. 85 se puede ver la función

Writer_init() con el código ya modificado.

Hay que tener cuidado con la modificación de Writer_init() y la ejecución del programa en repetidas ocasiones. Si cada vez que se ejecuta el programa y al archivo de salida se le da el mismo nombre que en la anterior ejecución, los datos obtenidos por la nueva ejecución del programa se agregarán al final de los datos de la anterior ejecución. Para evitar esta situación, se ha borrado el archivo anterior con los datos de salida.

La segunda modificación a aplicar en el código de writer.c es en la función

Writer_close(). Dentro de esta función existe una llamada a la función exit() que si se ejecuta, el programa finalizará. Como la función Writer_close() se va a usar muchas veces durante la ejecución del programa, la función exit() debe ser eliminada o comentada para evitar que el programa termine en la primera llamada a la función Writer_close(). En la figura Fig. 86 se puede observar la función Writer_close() con la modificación realizada.

Realizadas las dos modificaciones indicadas, ya se puede compilar el código C generado por ORCC. Para realizar la compilación se necesita abrir la consola de linux e ir al directorio /build dentro de la carpeta donde se han guardado los archivos generados. Cuando se esté en el directorio indicado se debe ejecutar el comando “cmake ..”. Con este comando se generan dentro de la carpeta /build todos los ficheros necesarios para la compilación y

Fig. 86: Función Writer_close()

modificada

linkado del programa.

Después de la finalización del comando anterior y dentro de la misma carpeta, se debe ejecutar el comando “make”. Con este comando se compilará y linkará el programa. Cuando finaliza su ejecución, si todo ha salido bien, debe aparecer un mensaje de que se ha generado el ejecutable, como se muestra en la figura Fig. 87.

El ejecutable ha sido guardado en la carpeta /bin dentro de la misma carpeta donde se guardó el código compilado. Ahora, antes de ejecutarlo, se necesitan los archivos binarios con los datos extraídos de la instrumentación del software de referencia HM. Para mayor comodidad, se copian estos archivos dentro de la carpeta donde está el ejecutable, como se ve en la figura Fig. 88.

Para ejecutar el programa generado, se debe ir a la carpeta /bin en la consola de linux. Con el parámetro ­i se indica al programa cual es el fichero de entrada y con el parámetro ­w cual es el nombre del archivo de salida. En la figura Fig. 89 se muestra el comando escrito en la consola de linux antes de ejecutarlo.

Fig. 88: Carpeta /bin con el ejecutable y los archivos del HM Fig. 87: Consola de linux después de la compilación del código

Cuando se ejecuta, el programa tardará un tiempo en terminar, proporcional al tamaño del archivo de coeficientes a convertir. Cuando la consola muestre el mensaje “Bytes left to sent:0 ” significará que se ha terminado de leer el archivo de coeficientes y por lo tanto el programa ha terminado de ejecutarse.

Después de la ejecución del programa, se habrá creado un nuevo fichero binario en la carpeta /bin llamado ResOutput. Ese fichero es el que se tiene que comparar con el fichero de residuos resultante de la instrumentación del software de referencia HM. Un primer paso para comprobar si ambos ficheros pueden ser iguales es ver si sus tamaños son iguales, de esta forma se chequea que hay el mismo número de residuos en ambos archivos. En la figura Fig. 90 se muestra esa comparación de tamaños de ficheros.

Con la comprobación de tamaños se asegura que el programa del banco de pruebas ha terminado correctamente su ejecución porque ha generado la misma cantidad de residuos que en el HM, pero ahora se tiene que comprobar si los residuos obtenidos son los correctos. Esto

Fig. 89: Comando para ejecutar el banco de pruebas de la transformada inversa

se hace con el comando diff en la consola de linux, indicando como parámetros los dos ficheros a comparar.

Con este comando se comparan byte a byte ambos ficheros binarios. Si existiera alguna diferencia en un byte o en el tamaño de ambos ficheros el comando devolverá por pantalla un mensaje diciendo que no son iguales. En la figura Fig. 91 se puede ver un ejemplo de dos ficheros binarios diferentes, comparando el fichero de metadatos y coeficientes y el fichero de residuos, ambos del HM.

Si, por el contrario, ambos ficheros son iguales en todo, el comando diff no retornará ningún resultado, como se puede ver en la figura Fig. 92, donde se están comparando el fichero de residuos obtenidos del HM y el fichero de residuos obtenidos del RVC-CAL.

Si se quiere comprobar de manera de manera visual ambos archivos, existe otro comando llamado vbindiff. Con este comando se mostrararán ambos archivos binarios por la consola, uno encima del otro. Cada byte se representará en formato hexadecimal y se mostrará su correspondencia en carácter ASCII en una columna situada en la parte derecha de la consola. Se puede mover a lo largo de los ficheros para observar si hay alguna diferencia entre ellos. Si existieran diferencias, estas serían resaltadas en ambos ficheros. Pulsando la tecla Intro, se empezaría a buscar la primera diferencia que hubiera entre los ficheros comparados. Si después de pulsar Intro, se muestra el final de ambos ficheros, significa que son iguales en todos sus datos. En la figura Fig. 93 se muestra la interfaz gráfica de

vbindiff.

Fig. 92: Comparación de los ficheros de residuos con el comando diff

De esta forma, ha quedado comprobado que el diseño de la transformada inversa en RVC- CAL se ha realizado correctamente. El siguiente paso es ejecutarlo todo sobre la Zedboard y comprobar de nuevo si el resultado es satisfactorio.