Síntesis de los actores en el hardware

Para sintetizar los actores asignados al hardware de la plataforma heterogénea se necesita Vivado HLS. Todo este proceso de síntesis de actores sobre el hardware está automatizado por el script terminado en “_pl_hls.tcl”, como ya se explico anteriormente, evitando tener que realizar todo este proceso de forma manual.

Para entender mejor el funcionamiento de este script, en los siguientes párrafos se va a realizar un análisis del contenido del script, enumerando y explicando cada uno de los comandos o grupos de comandos.

En el ANEXO 2.1 se muestran los primeros comandos que hay en el script. Son tres asignaciones para tres directorios donde se encuentran guardados los archivos fuente de los actores a sintetizar, las cabeceras para dichos códigos fuente y los testbench para cada uno de los actores. Esta asignación es por simplificación, para que cada vez que se tenga que acceder a esos directorios, no se tenga que poner la dirección completa.

Acto seguido se encuentra el comando para abrir el proyecto de Vivado HLS (ANEXO 2.2). Si no existe el proyecto que se quiere abrir, se creará un proyecto nuevo cuyo nombre será el especificado en el comando. Esto pasará cuando se ejecute el script por primera vez.

Una vez creado/abierto el proyecto, se procede a añadir los archivos que incluyen los códigos fuente de cada uno de los actores que se van a sintetizar en el hardware. En el ANEXO 2.3 se observa que primero se añade el código fuente que incluye la función de más alto nivel, que engloba a todos los actores destinados al hardware, y después se añade cada código para cada actor. El orden de añadir los archivos al proyecto no es determinante, se pueden añadir en el orden que se quiera.

En estos comandos se observa que se utilizan las asignaciones de directorios que se hicieron al principio del script. En la primera parte del comando se especifica el archivo a añadir y en la segunda parte, precedido por el parámetro “­cflags”, se añaden las opciones de compilación, donde se indica la localización de los ficheros de cabecera del código fuente. Teniendo ya los ficheros de los códigos fuente añadidos al proyecto de Vivado HLS, se procede a agregar el código del testbench, que servirá para comprobar que la síntesis del código se ha realizado correctamente.

Como se puede observar en el ANEXO 2.4, el proceso de añadir el archivo del testbench es casi el mismo que el de añadir código para sintetizar, pero añadiendo el parámetro “­tb”. Con este párametro se indica a Vivado HLS que el archivo que se añade es un testbench y no se tiene que sintetizar.

El backend Exelixi genera testbenchs para cada actor que se asigna al hardware (Fig. 9), pero no genera un testbench para la función que engloba a todos ellos y la que se va a sintetizar al final. Esto es así para cualquier aplicación que se desarrolle en RVC-CAL, nunca generará el

testbench de la función de más alto nivel porque, al englobar todos los actores del asignados al hardware, la complejidad del mismo es muy elevada al tener que poner a prueba todas las funcionalidades. Precisamente, el testbench que se intenta agregar al proyecto de Vivado HLS, es el testbench que no ha sido generado por el backend. El diseñador de la aplicación en RVC-CAL es libre de diseñar un testbench de calidad para probar la función de más alto nivel, agregándolo al proyecto de Vivado HLS. Puntualizar que este testbench, si se decide realizar, se estaría probando los actores asignados al hardware, quedando fuera de la prueba los actores en el software y, por consiguiente, la aplicación completa que se ejecutará sobre la plataforma heterogénea.

El intentar agregar un archivo que no existe al proyecto no supone mayor problema. Si no existe, no se agrega nada y se continúa con la ejecución de los comandos del script.

El problema surgiría si el archivo que falta fuera una parte del código que se va a sintetizar, pero al ser el testbench, la síntesis se va a realizar sin problema. Únicamente, la síntesis realizada no se podrá testear al faltar el testbench necesario para hacerlo.

Ya con todos los archivos agregados, es hora de indicar cúal es la función de más alto nivel, que engloba todos los actores destinados al hardware, y la que va a ser sintetizada. Esta operación se realiza con el comando mostrado en el ANEXO 2.5.

Habiendo agregado los archivos necesarios y seleccionado la función de más nivel, ahora se procede a la creación de la solución. Se pueden generan diferentes soluciones en un mismo proyecto de Vivado HLS. A cada una de las soluciones se le pueden dar diferentes directrices y restricciones a la síntesis para obtener diferentes resultados. En el siguiente apartado (3.3.1.3) se explicará con mas detenimiento el uso de las directrices y restricciones a la síntesis. El comando usado crear la solución es el mostrado en el ANEXO 2.6.

Al usar este comando, si la solución con el nombre que se indica no existe, se crea. Añadiendo el parámetro “­reset”, si la solución ya existe previamente, se borran todos los datos anteriores de la solución, como librerías, directivas y restricciones para la síntesis. También se borra la síntesis previa, con la verificación e implementación incluidas.

En el siguiente comando del script, se selecciona la plataforma heterogénea sobre la que se quiere implementar el código sintetizado (ANEXO 2.7), para saber cuales son las características y limitaciones que tiene.

Acto seguido, se selecciona el periodo de reloj a la que va a funcionar la parte hardware del

integrado y el nombre que va a recibir éste dentro del diseño (ANEXO 2.8). En el periodo del reloj, si no se indica ninguna unidad, el programa entiende que se está expresando en nanosegundos, aunque también se puede expresar en MHz siempre que se le indique.

Una vez agregados los archivos (código a sintetizar y testbench), seleccionada la función de más alto nivel, creado la solución, seleccionado el tipo de integrado y su frecuencia de funcionamiento, ya se puede proceder a la síntesis del código y esto se hace con el sencillo comando que se muestra en el ANEXO 2.9.

Este comando, a pesar de ser el más sencillo de todo el script, es el más importante y el que más tiempo tarda en ejecutarse, porque con él se inicia todo el proceso de síntesis del código, aplicando todas las directrices y limitaciones que se le han indicado al sintetizador.

Con la síntesis ya ejecutada y como último comando del script, se exporta todo el diseño al catálogo IP de Vivado para que esté disponible para su inclusión en el diagrama de bloques y realizar la conexión del mismo al procesador (ANEXO 2.10).