Herramienta de desarrollo de aplicaciones dinámicamente ...

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

GRADO EN INGENIERÍA INFORMÁTICA

TRABAJO FIN DE GRADO

Herramienta de desarrollo de aplicacionesdinámicamente reconfigurables en FPGA

Javier Sevilla Ballesteros

Enero, 2017

HERRAMIENTA DE DESARROLLO DE APLICACIONES DINÁMICAMENTERECONFIGURABLES EN FPGA

EscuelaSuperiorde Informática

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

Tecnologías y Sistemas de Información

TECNOLOGÍA ESPECÍFICA DE

INGENIERÍA DE COMPUTADORES

TRABAJO FIN DE GRADO

Herramienta de desarrollo de aplicacionesdinámicamente reconfigurables en FPGA

Autor: Javier Sevilla Ballesteros

Director: Julián Caba Jiménez

Director: Dr. Julio Daniel Dondo Gazzano

Enero, 2017

Javier Sevilla Ballesteros

Ciudad Real – Spain

E-mail: [email protected]éfono: 684 054 768

c© 2017 Javier Sevilla Ballesteros

Permission is granted to copy, distribute and/or modify this document under the terms of the GNUFree Documentation License, Version 1.3 or any later version published by the Free SoftwareFoundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copyof the license is included in the section entitled "GNU Free Documentation License".Se permite la copia, distribución y/o modificación de este documento bajo los términos de laLicencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada porla Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida enel apéndice titulado «GNU Free Documentation License».Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios sonreclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, ycuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos enmayúsculas o como nombres propios.

i

TRIBUNAL:

Presidente:

Vocal:

Secretario:

FECHA DE DEFENSA:

CALIFICACIÓN:

PRESIDENTE VOCAL SECRETARIO

Fdo.: Fdo.: Fdo.:

iii

Resumen

Las FPGAS (Field Programmable Gate Arrays), cuyo uso en la industria está en contínuocrecimiento, ofrecen una gran flexibilidad en el proceso de diseño de un sistema debido a sucapacidad de ser reprogramadas. La reconfiguración parcial introduce nuevas oportunidadesen el desarrollo de sistemas basados en estos dispositivos, ya que permite definir regionesde la FPGA cuya lógica puede ser reprogramada en tiempo de ejecución sin comprometer laintegridad de las aplicaciones que se ejecutan en el resto de la FPGA.

En este TFG (Trabajo Fin de Grado) se desarrolla un nuevo flujo de diseño que facilita alos diseñadores la creación de aplicaciones dinámicamente reconfigurables para dispositivosfabricados por Xilinx, buscando reducir la probabilidad de que el diseñador cometa algúnerror a lo largo del flujo y ofreciendo un ahorro de tiempo considerable en comparación conlas herramientas del fabricante. Este nuevo flujo de diseño y otros componentes desarrolladosa lo largo del TFG, como por ejemplo el gestor de la reconfiguración, se incluyen en unaherramienta gráfica ligera e intuitiva.

Esta herramienta que se obtiene como resultado del proyecto proporciona a los diseñado-res todo lo necesario para el desarrollo, implementación y gestión de aplicaciones dinámica-mente reconfigurables.

V

Abstract

FPGAS (Field Programmable Gate Arrays) are more and more attractive in the industry, ad-ding these kind of devices in most industrial solutions. These devices offer a great flexibilityin a system design process due to its capacity of being reprogrammed. Partial reconfigura-tion feature introduces new opportunities in the embedded systems field, this feature allowsto define regions of the FPGA whose logic may be reprogrammed at run-time without com-promising the integrity of other applications deployed into the same FPGA.

This TFG (Bachelor’s Degree Final Project) developes a new design flow, facilitating thebuilding of dynamically reconfigurable applications based on Xilinx devices, searching toreduce the designer errors as well as offering a considerable time saving in contrast to theXilinx tools. This new design flow and other developed components throughout this TFG,e.g. the reconfiguration manager, are included in an intuitive and lightweight graphic tool.This tool is the graphical result of this project, that gives to designers the necessary for deve-lopment, implementation and management of dynamically reconfigurable applications.

VII

Agradecimientos

Al escribir estas líneas es inevitable pensar en cómo he llegado hasta aquí. Aún recuerdola primera vez que utilicé un ordenador siendo pequeño y me resultó increíble la cantidadde funciones que podía realizar una caja de plástico con contenido desconocido. El asombroinicial se convirtió con el tiempo en curiosidad por saber cómo funciona y qué había dentrode esa caja y, más tarde, comencé a descubrir el mundo de la programación. En el momentode elegir qué estudiar todo lo dicho hasta ahora influyó en la elección y finalmente opté porel Grado en Ingeniería Informática. Llegado a este punto solo puedo decir que esa decisiónfue de las mejores que he tomado hasta ahora.

Durante todo ese tiempo y hasta hoy mis padres siempre han estado apoyándome y sonen gran parte responsables de que haya llegado hasta aquí. Me habéis enseñado desde elejemplo que con esfuerzo y trabajo duro se puede conseguir todo lo que uno se proponga yvalores tan importantes como la responsabilidad, el respeto, la humildad y un largo etcétera.A mi hermano Sergio, que termina este año Bachillerato, decirle que escoja el camino queescoja estoy seguro de que tomará la mejor opción. Todos ellos, junto con mis abuelos a losque admiro enormemente, han hecho que hoy sea como soy. Gracias a todos.

A nadie le extrañará que agradezca a Cristina el hecho de haber estado a mi lado duranteestos últimos años y, especialmente, la paciencia que ha demostrado en incontables ocasio-nes. Has sido con quien más he compartido esta etapa y tu comprensión, apoyo y consejoshan sido fundamentales para llegar hasta aquí. Tan solo espero compartir mucho más juntos.Muchas gracias por todo.

Por otra parte, dar las gracias a los compañeros con los que he compartido piso estos años,a todos los amigos y en general a todos aquellos que han formado parte de este importantetrayecto.

Finalmente, agradecer a Julián y a Julio su disponibilidad y toda la ayuda proporcionada enla realización de este trabajo. Vuestra orientación a lo largo del proyecto ha sido fundamentalpara alcanzar los objetivos iniciales y sin vuestras contribuciones el resultado no sería elmismo.

Javier

IX

«As soon as an Analytical Engine exists, it willnecessarily guide the future course of the science»

— Passages from the Life of a Philosopher,Charles Babbage

xi

Índice general

Resumen V

Abstract VII

Agradecimientos IX

Índice general XIII

Índice de cuadros XVII

Índice de figuras XIX

Índice de listados XXIII

Listado de acrónimos XXV

1. Introducción 1

1.1. Cómo funciona la reconfiguración parcial . . . . . . . . . . . . . . . . . . 2

1.2. Beneficios de la reconfiguración parcial . . . . . . . . . . . . . . . . . . . 3

1.3. Tendencias de la reconfiguración parcial en la industria . . . . . . . . . . . 4

1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Objetivos 7

2.1. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4. Aplicación de la herramienta . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5. Método y fases de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Antecedentes 13

3.1. Field Programmable Gate Arrays (FPGAS) . . . . . . . . . . . . . . . . . . 13

3.1.1. Ventajas de utilizar FPGAS . . . . . . . . . . . . . . . . . . . . . . 14

XIII

3.2. Reconfiguración parcial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1. Estilos de reubicación de los módulos reconfigurables . . . . . . . 16

3.2.2. Comunicación entre parte estática y parte dinámica . . . . . . . . . 17

3.2.3. Programación de la FPGA utilizando un bitstream parcial . . . . . . 19

3.3. Flujo de diseño de Vivado para la reconfiguración parcial . . . . . . . . . . 21

3.4. Otras herramientas para aplicar la reconfiguración parcial . . . . . . . . . . 29

3.4.1. OpenPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.2. GoAhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5. Contenido y compresión de un bitstream . . . . . . . . . . . . . . . . . . . 33

3.5.1. Contenido de un bitstream . . . . . . . . . . . . . . . . . . . . . . 34

3.5.2. Estructura de un bitstream . . . . . . . . . . . . . . . . . . . . . . 35

3.5.3. Técnicas de compresión . . . . . . . . . . . . . . . . . . . . . . . 36

3.5.4. zipFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4. Método de trabajo 41

4.1. Metodologías utilizadas en el proyecto . . . . . . . . . . . . . . . . . . . . 41

4.1.1. Metodología de sistemas empotrados basada en FPGA . . . . . . . 41

4.1.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2. Herramientas, lenguajes y medios empleados . . . . . . . . . . . . . . . . 46

4.2.1. Herramientas software . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.2. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.3. Medios hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5. Desarrollo del trabajo 49

5.1. Formación previa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2. Estudio y adaptación del proyecto proporcionado por ARCO . . . . . . . . 50

5.2.1. Automatización del flujo de diseño . . . . . . . . . . . . . . . . . . 50

5.2.2. Componentes incluidos en el proyecto . . . . . . . . . . . . . . . . 56

5.2.3. Adaptación inicial del proyecto . . . . . . . . . . . . . . . . . . . 57

5.3. Desarrollo de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.1. Iteración 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.2. Iteración 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.3. Iteración 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.3.4. Iteración 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.3.5. Iteración 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

xiv

6. Resultados obtenidos 115

6.1. Herramienta HDADR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2. Comparación entre HDADR y Vivado . . . . . . . . . . . . . . . . . . . . . 116

6.2.1. Comparación de los flujos de diseño . . . . . . . . . . . . . . . . . 116

6.2.2. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

7. Conclusiones y trabajo futuro 125

7.1. Consecución de los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . 125

7.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

A. Prototipos de la interfaz gráfica de la herramienta 131

A.1. Prototipos iniciales de la interfaz gráfica principal . . . . . . . . . . . . . . 131

A.2. Prototipo inicial del selector de área (floorplanning) . . . . . . . . . . . . . 135

A.3. Prototipos del gestor de la reconfiguración . . . . . . . . . . . . . . . . . . 136

A.4. Protitipo de la ventana que permite exportar el hardware a Vivado SDK . . 138

A.5. Prototipo de la ventana que permite crear la imagen de arranque . . . . . . 139

B. Compilación y uso de la herramienta 141

B.1. Requisitos para la compilación de la herramienta . . . . . . . . . . . . . . 141

B.1.1. CTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

B.1.2. Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

B.1.3. Google Test [Opcional] . . . . . . . . . . . . . . . . . . . . . . . . 142

B.1.4. Variables de entorno . . . . . . . . . . . . . . . . . . . . . . . . . 142

B.2. Compilación y ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

B.2.1. Ejecución de los test [Opcional] . . . . . . . . . . . . . . . . . . . 143

B.3. Uso de la herramienta HDADR . . . . . . . . . . . . . . . . . . . . . . . . 143

B.3.1. Inicio de la herramienta. Establecer el directorio del proyecto. . . . 143

B.3.2. Flujo de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

B.3.3. Exportar hardware a Vivado SDK . . . . . . . . . . . . . . . . . . 151

B.3.4. Gestor de la reconfiguración . . . . . . . . . . . . . . . . . . . . . 152

B.3.5. Crear imagen de arranque para tarjeta SD . . . . . . . . . . . . . . 154

B.3.6. Ampliar un diseño existente . . . . . . . . . . . . . . . . . . . . . 155

C. Añadir soporte a nuevas placas 157

C.1. Placas soportadas por HDADR . . . . . . . . . . . . . . . . . . . . . . . . 157

C.2. Añadir nuevas placas a la herramienta HDADR . . . . . . . . . . . . . . . . 157

xv

D. Repositorio del proyecto 161

E. GNU Free Documentation License 163

E.0. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

E.1. Applicability and definitions . . . . . . . . . . . . . . . . . . . . . . . . . 163

E.2. Verbatim copying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

E.3. Copying in quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

E.4. Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

E.5. Collections of documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

E.6. Aggregation with independent works . . . . . . . . . . . . . . . . . . . . . 166

E.7. Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

E.8. Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

E.9. Future revisions of this license . . . . . . . . . . . . . . . . . . . . . . . . 167

E.10. Relicensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Referencias 169

xvi

Índice de cuadros

3.1. Ventajas del uso de FPGAS en un sistema. [SZ09] [Xilb] . . . . . . . . . . . 15

3.2. Ventajas del uso de un ASIC en un sistema. [SZ09] [Xilb] . . . . . . . . . . 15

5.1. Product backlog inicial de la herramienta. . . . . . . . . . . . . . . . . . . 62

5.2. Sprint backlog de la iteración 1. . . . . . . . . . . . . . . . . . . . . . . . 63

5.3. Resultado de las pruebas unitarias de la iteración 1. . . . . . . . . . . . . . 68


5.5. Product backlog al finalizar la iteración 2. . . . . . . . . . . . . . . . . . . 81





5.10. Resultado de las pruebas unitarias de la iteración 4 (elemento ID 007). . . . 94

5.11. Resultado de las pruebas unitarias de la iteración 4 (elemento ID 011). . . . 98

5.12. Resultado de las pruebas unitarias de la iteración 4 (elementos ID 013/012). 102




XVII

Índice de figuras

1.1. Relación entre particiones reconfigurables y módulos reconfigurables . . . 2

1.2. Reducción del tamaño necesario para un diseño aplicando reconfiguraciónparcial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1. Estructura genérica de una FPGA. . . . . . . . . . . . . . . . . . . . . . . . 14

3.2. Implementación de una Lookup table (LUT) de dos entradas. . . . . . . . . 14

3.3. Estilos de reubicación de los módulos (C es la interfaz de comunicación). . 16

3.4. Uso de un «bus macro» para la comunicación entre parte estática y partedinámica [Xil04]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5. Implementación de un «bus macro» utilizando buffers triestado [Xil04]. . . 18

3.6. Comunicación entre parte estática y parte dinámica utilizando «pines de par-tición» [Xil13b]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.7. Proceso de configuración de la FPGA utilizando un bitstream completo [Xil13b]. 20

3.8. Proceso de configuración de la FPGA utilizando un bitstream parcial [Xil13b]. 20

3.9. Componente ICAPE2 que permite acceder a las funciones de configuraciónde la FPGA [Xil15b]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.10. Flujo de diseño de OPENPR [SAFW11] . . . . . . . . . . . . . . . . . . . 30

3.11. Interfaz gráfica de la herramienta GOAHEAD [BKT12] . . . . . . . . . . . 31

3.12. Flujo de diseño de GOAHEAD [BKT12] . . . . . . . . . . . . . . . . . . . 33

3.13. Estructura de un paquete de tipo 1 . . . . . . . . . . . . . . . . . . . . . . 34

3.14. Estructura de un paquete de tipo 2 . . . . . . . . . . . . . . . . . . . . . . 35

3.15. Diagrama de bloques del componente zipFactory [Cab] . . . . . . . . . . . 38

4.1. Metodología para FPGA [DSAG10] . . . . . . . . . . . . . . . . . . . . . 42

4.2. Esquema del proceso que define Scrum [Wik] . . . . . . . . . . . . . . . . 43

4.3. Patrón de diseño «Observador». . . . . . . . . . . . . . . . . . . . . . . . 47

5.1. Diagrama de bloques del diseño proporcionado. . . . . . . . . . . . . . . . 61

5.2. Diagrama de clases de la iteración 1. . . . . . . . . . . . . . . . . . . . . . 65

5.3. Flujo de diseño de la herramienta HDADR. . . . . . . . . . . . . . . . . . . 71


XIX

5.5. GUI de la herramienta HDADR en la iteración 2. . . . . . . . . . . . . . . . 74

5.6. GUI de la ventana que permite al diseñador realizar el floorplanning. . . . . 80


5.8. Diagrama de clases de la iteración 4 (primera actualización). . . . . . . . . 93

5.9. Diagrama de clases de la iteración 4 (segunda actualización). . . . . . . . . 97

5.10. Interfaz gráfica principal de la herramienta HDADR tras aplicar varias mejoras. 99

5.11. Diagrama de clases de la iteración 4 (tercera actualización). . . . . . . . . . 101

5.12. Actualización del selector de área (floorplanning). . . . . . . . . . . . . . . 106


5.14. Selector de idioma que se ejecuta al inicio de la herramienta. . . . . . . . . 113

6.1. Comparación entre el flujo de diseño de HDADR y el de Vivado. . . . . . . 117

6.2. Comparación del consumo de memoria física entre HDADR y Vivado. . . . 120

6.3. Comparación del incremento del consumo de memoria física que se produceen el sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6.4. Comparación del uso de CPU global que se produce en el sistema. . . . . . 121

6.5. Comparación del trabajo que tiene que realizar el diseñador para generar elmismo diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.6. Comparación del consumo de memoria física entre HDADR y Vivado (gene-ración parcial). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.7. Comparación del incremento del consumo de memoria física que se produceen el sistema (generación parcial). . . . . . . . . . . . . . . . . . . . . . . 123

6.8. Comparación del uso de CPU global que se produce en el sistema (generaciónparcial). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6.9. Comparación del trabajo que tiene que realizar el diseñador para generar elmismo diseño (generación parcial). . . . . . . . . . . . . . . . . . . . . . . 124

A.1. Información General - Prototipo de la GUI de la herramienta. . . . . . . . . 131

A.2. Parte estática - Prototipo de la GUI de la herramienta. . . . . . . . . . . . . 132

A.3. Particiones reconfigurables - Prototipo de la GUI de la herramienta. . . . . . 132

A.4. Módulos reconfigurables - Prototipo de la GUI de la herramienta. . . . . . . 133

A.5. Configuraciones - Prototipo de la GUI de la herramienta. . . . . . . . . . . 134

A.6. Prototipo de la GUI que permite el floorplanning. . . . . . . . . . . . . . . 135

A.7. Prototipo del gestor de la reconfiguración, incluyendo la interfaz que permiteprogramar la FPGA utilizando un bitstream generado previamente. . . . . . 136

A.8. Prototipo de la ventana que permite cargar en la FPGA una aplicación deusuario que se encargue de la reconfiguración. . . . . . . . . . . . . . . . . 137

A.9. Prototipo de la ventana que permite exportar el hardware a Vivado SDK. . . 138

xx

A.10.Prototipo de la ventana que permite crear la imagen de arranque para una SD. 139

B.1. Selector de idioma. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

B.2. Establecer el directorio del proyecto. . . . . . . . . . . . . . . . . . . . . . 144

B.3. Flujo de diseño - Información general. . . . . . . . . . . . . . . . . . . . . 145

B.4. Flujo de diseño - Parte estática. . . . . . . . . . . . . . . . . . . . . . . . . 146

B.5. Flujo de diseño - Particiones reconfigurables. . . . . . . . . . . . . . . . . 147

B.6. Flujo de diseño - Selector de área. . . . . . . . . . . . . . . . . . . . . . . 148

B.7. Flujo de diseño - Módulos reconfigurables. . . . . . . . . . . . . . . . . . 149

B.8. Flujo de diseño - Configuraciones. . . . . . . . . . . . . . . . . . . . . . . 150

B.9. Flujo de diseño - Bitstreams. . . . . . . . . . . . . . . . . . . . . . . . . . 151

B.10. Exportar hardware a Vivado SDK. . . . . . . . . . . . . . . . . . . . . . . 152

B.11. Gestor de la reconfiguración. . . . . . . . . . . . . . . . . . . . . . . . . . 152

B.12. Gestionar la reconfiguración parcial a través de la herramienta HDADR. . . 153

B.13. Gestionar la reconfiguración parcial a través de una aplicación de usuario. . 154

B.14. Crear imagen de arranque para tarjeta SD. . . . . . . . . . . . . . . . . . . 155

B.15. Mensaje mostrado al usuario en caso de que se detecte un diseño anterior enel directorio introducido. . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

xxi

Índice de listados

3.1. Síntesis de la parte estática en TCL . . . . . . . . . . . . . . . . . . . . . . 22

3.2. Síntesis de un módulo reconfigurable en TCL . . . . . . . . . . . . . . . . 23

3.3. Cargar un diseño en memoria en TCL (Opción 1) . . . . . . . . . . . . . . 23



3.6. Definir una región reconfigurable en TCL . . . . . . . . . . . . . . . . . . 24

3.7. Activar la propiedad HD.RECONFIGURABLE en TCL . . . . . . . . . . . 25

3.8. Implementar la primera configuración en TCL . . . . . . . . . . . . . . . . 26

3.9. Guardar la implementación de la primera configuración en TCL . . . . . . . 26

3.10. Guardar la implementación de la parte estática en TCL . . . . . . . . . . . 27

3.11. Ejemplo en el que se implementa una nueva configuración en TCL . . . . . 27

3.12. Crear la configuración blanking en TCL . . . . . . . . . . . . . . . . . . . 28

3.13. Verificar las configuraciones creadas en TCL . . . . . . . . . . . . . . . . . 28

3.14. Generar un bitstream en TCL . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.15. Herramientas de Xilinx para la compresión del bitstream en TCL . . . . . . 37

5.1. Uso de la estructura de datos fileGroup. . . . . . . . . . . . . . . . . . . . 51

5.2. Ejemplo del archivo design.tcl (versión inicial). . . . . . . . . . . . . . . 52

5.3. Archivo build.tcl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.4. Partición reconfigurable en el módulo top del diseño inicial. . . . . . . . . 57

5.5. Modificación realizada al archivo directives.tcl de zipFactory. . . . . . . 58

5.6. Declaración de la partición wrapperTDDp2 en el módulo top. . . . . . . . . 59

5.7. Mapeado de puertos de la partición wrapperTDD en el módulo top. . . . . . 59

5.8. Módulo reconfigurable dummy1. . . . . . . . . . . . . . . . . . . . . . . . 60

5.9. Formato de la definición de las particiones en la plantilla designTemplate.tpl. 66

5.10. Extracto de la clase GenDesignTCL donde se da formato a los datos de lasparticiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.11. Código que se ejecuta al pulsar el botón «Generar diseño» (iteración 2). . . 75

5.12. Componente sintetizado para poder acceder a los recursos hardware de laFPGA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

XXIII

5.13. Script que extrae los datos de los recursos hardware de la FPGA. . . . . . . 77

5.14. Fragmento del archivo XML generado que contiene los datos de la ZedBoard. 79

5.15. Algoritmo utilizado para buscar un recurso hardware en la representacióngráfica de la FPGA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.16. Plantilla utilizada para generar el archivo program.tcl. . . . . . . . . . . . 84

5.17. Código que se encarga de exportar la definición hardware a Vivado SDK. . 89

5.18. Plantilla utilizada para generar el archivo xmd.tcl. . . . . . . . . . . . . . . 94

5.19. Plantilla utilizada para generar el archivo deploy.mk. . . . . . . . . . . . . . 95

5.20. Línea del archivo que contiene el diseño de bloques donde se establece elrango de direcciones del componente axi_memory_read_driver. . . . . . . 106

5.21. Archivo .bif que se utiliza para generar la imagen de aranque a través de laherramienta bootgen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.22. Plantilla utilizada para generar el archivo bootSD.mk. . . . . . . . . . . . . . 110

C.1. Líneas del script generateBoardsXML.tcl en las que se llama a la función quegenera el archivo XML para una determinada placa. . . . . . . . . . . . . . 158

C.2. Método en el que se ha de introducir el part de la nueva placa que se deseaañadir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

C.3. Método en el que se establece la relación part-board de la nueva placa quese desea añadir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

xxiv

Listado de acrónimos

GNU GNU is Not Unix

HDADR Herramienta de Desarrollo de Aplicaciones Dinámicamente Reconfigurables

TFG Trabajo Fin de Grado

FPGA Field Programmable Gate Array

TCL Tool Command Language

RTL Register Transfer Level

E/S Entrada/Salida

HDL Hardware Description Language

EDIF Electronic Design Interchange Format

DRC Design Rule Checking

LUT Lookup table

ICAP Internal Configuration Access Port

PCAP Processor Configuration Access Port

RISC Reduced Instruction Set Computing

ARM Advanced RISC Machine

AXI Advanced eXtensible Interface

AMBA Advanced Microcontroller Bus Architecture

IP Intellectual Property

FIFO First in, first out

HLS High-level synthesis

VHSIC Very High Speed Integrated Circuit

VHDL VHSIC Hardware Description Language

TCAC Tasa de Crecimiento Anual Compuesta

SQL Structured Query Language

GUI Graphical User Interface

ARCO Arquitectura y Redes de Computadores

XXV

RAM Random Access Memory

BRAM Block RAM

XDL Xilinx Design Language

NCD Native Circuit Description

XML eXtensible Markup Language

UCF User Constraints File

XDC Xilinx Design Constraints

XST Xilinx Synthesis Technology

PLD Programmable Logic Device

CPLD Complex Programmable Logic Device

PLA Programmable Logic Array

PAL Programmable Array Logic

CAD Computer-Aided Design

PROM Programmable Read-Only Memory

ASIC Application Specific Integrated Circuit

ROI Return On Investment

JTAG Joint Test Action Group

SOC System on a Chip

IEEE Institute of Electrical and Electronics Engineers

DDR Double Data Rate

JVM Java Virtual Machine

GIMP GNU Image Manipulation Program

GTK+ GIMP Toolkit

LGPL GNU Lesser General Public License

XMD Xilinx Microprocessor Debugger

GCC GNU Compiler Collection

FSBL First Stage Boot Loader

CPU Central Processing Unit

xxvi

Capítulo 1

Introducción

A CTUALMENTE los sistemas empotrados se encuentran en un gran número de disposi-tivos eléctronicos, desde cámaras digitales o tarjetas inteligentes hasta automóviles,

radares o satélites. En todo sistema empotrado se encuentran dos partes bien diferenciadas:hardware y software, y las restricciones que se le aplican (potencia, tamaño, temperatura,latencia, etc.) varían dependiendo de la funcionalidad de éste y del ámbito en el que opere. Adía de hoy los ingenieros y diseñadores de sistemas empotrados persiguen optimizar el usoy el procesamiento de estos dispositivos. Frente a los ASICS (Application Specific IntegratedCircuits), las FPGAS ofrecen una mayor flexibilidad en el proceso de diseño de un siste-ma debido a su capacidad de ser reprogramadas, permitiendo programar un nuevo diseñosobre éstas sin tener que volver a fabricar el circuito integrado. Durante el proceso de progra-mación la FPGA debe interrumpir su funcionalidad para poder sustituir el anterior diseño porel nuevo [Bob07] [Dye12]. La reconfiguración parcial (o reconfiguración dinámica) va másallá, ya que permite definir regiones de la FPGA cuya lógica puede ser reprogramada sincomprometer la integridad de las aplicaciones que se ejecutan en el resto de la FPGA. Esdecir, se pueden adaptar diseños ya implementados agregando o modificando funcionalida-des a la FPGA en tiempo de ejecución. Además, tal y como se verá a lo largo de este capítulo,esta técnica ofrece otras ventajas como la disminución del área necesaria para implementarun diseño y la correspondiente disminución de consumo energético [Xil13c] [Dye12].

A pesar de las oportunidades que introduce la reconfiguración parcial, explotar esta téc-nica con las herramientas de diseño actuales puede llegar a ser complejo o poco intuitivopara el usuario, dado que fabricantes como Xilinx no disponen de una herramienta que fa-cilite la construcción o el diseño de este tipo de aplicaciones [Xil13b]. De hecho, el flujo dediseño para la reconfiguración parcial establecido por Xilinx (ver Sección 3.3) requiere debastante atención por parte del diseñador ya que un solo fallo es suficiente para tener quevolver a comenzar el proceso de nuevo. Este TFG se centra en la reconfiguración parcial dedispositivos fabricados por Xilinx debido a que este fabricante fue pionero en este campo yademás posee una extensa documentación. Mencionar que otros fabricantes también ofrecensoporte a la reconfiguración parcial en sus productos, como por ejemplo Altera [alt].

1

1.1 Cómo funciona la reconfiguración parcialLa técnica de la reconfiguración parcial parte de la idea de que en la FPGA pueden existir

dos tipos de zonas: aquellas que se pueden reconfigurar en tiempo de ejecución (particionesreconfigurables), y aquellas que no (parte estática). Una partición reconfigurable está for-mada por un conjunto de recursos hardware que podrán ser configurados sin afectar a la parteestática de la FPGA o a otras particiones reconfigurables.

Por otra parte, un módulo reconfigurable es un componente en forma de netlist, descrip-ción en HDL (Hardware Description Language), o escrito en C/C++ que puede ser imple-mentado en una partición reconfigurable, es decir, es el elemento que se va a cargar en unapartición. El estilo de reubicación de módulos que se utilice (ver Subsección 3.2.1) determi-nará si un módulo reconfigurable puede estar asociado a una única partición o a varias y sien una partición solo puede haber implementado un módulo o varios al mismo tiempo.

Figura 1.1: Relación entre particiones reconfigurables y módulos reconfigurables

La Figura 1.1 representa un diseño en el que existe una partición reconfigurable (X) ytres módulos reconfigurables asociados a esa partición (X1, X2 y X3). Haciendo uso de lareconfiguración parcial, la lógica que se encuentra dentro de la partición puede cambiar paraimplementar uno de los tres módulos sin afectar al resto de la lógica de la FPGA.

La configuración de la lógica interna de la FPGA se realiza utilizando un archivo bits-tream, el cual se genera al final del flujo de diseño. En el caso de un diseño que utilicereconfiguración parcial se generan dos tipos de bitstreams: los completos y los parciales. Unbitstream completo es aquel que contiene la información necesaria para configurar toda lalógica interna de la FPGA, mientras que un bitstream parcial solo contiene la informaciónnecesaria para configurar la lógica que se encuentra dentro de una partición reconfigura-ble.

Por lo tanto, para cada módulo reconfigurable se debe generar un bitstream parcialque contenga la implementación de ese módulo. Cuando se quiera cargar un módulo recon-figurable utilizando la técnica de la reconfiguración parcial, basta con programar la FPGA

utilizando el bitstream correspondiente para que la implementación del módulo se configure

2

en la partición asociada a éste. Cabe mencionar que para poder realizar una reconfiguraciónparcial es necesario programar la FPGA con un bitstream completo previamente.

1.2 Beneficios de la reconfiguración parcialEn líneas generales, la reconfiguración parcial introduce los siguientes beneficios a los

diseños basados en FPGA:

Reducción del tamaño y del coste requerido para implementar un diseño. Por ejem-plo, supongamos que una aplicación recibe una secuencia de imágenes y tiene queaplicar un filtro a cada imagen recibida. La aplicación dispone de varios filtros y entodo momento solo se aplica el elegido por el usuario (ver Figura 1.2). Haciendo usode la reconfiguración parcial cada filtro puede ser implementado como un módulo re-configurable, de forma que en todo momento el único filtro implementado en la FPGA

es el que se está aplicando a las imágenes que se reciben. Por el contrario, si no se apli-ca esta técnica todos los filtros tienen que ser implementados de forma fija, ocupandouna parte de los recursos de la FPGA. Por lo tanto, aplicando la reconfiguración parcialse reduce el tamaño de la implementación de un diseño, lo que permite aprovechar elresto de la lógica para otras funciones o utilizar FPGAS más pequeñas, ahorrando asíen coste [Dye12].

Figura 1.2: Reducción del tamaño necesario para un diseño aplicando reconfiguración parcial

Reducción del consumo energético. El poder utilizar una FPGA más pequeña paraimplementar un diseño implica también un menor consumo, ya que utilizar una FPGA

más grande implica, por lo general, un mayor consumo energético. Por otra parte exis-te el caso de que una determinada aplicación pueda variar su rendimiento en funciónde la carga de trabajo, de forma que el diseñador puede implementar dos versionesde una misma función: una con un alto rendimiento y mayor consumo, y otra con unmenor rendimiento que consuma menos recursos (BRAMS, LUTS, etc.) y por tanto con-suma menos energía. De esta forma, cuando la carga de trabajo sea baja la aplicación

3

puede cargar la versión de menor rendimiento y así disminuir el consumo energéticoglobal [Dye12].

Incremento de la flexibilidad. Si se sigue un flujo de diseño normal, añadir cambiosen el diseño conlleva tener que realizar de nuevo el place and route y generar un nuevobitstream completo. Aplicar estos cambios en la FPGA implica detener la aplicaciónque se ejecuta sobre ella, ya que para aplicarlos es necesario realizar una serie de pasos:detener la FPGA en un estado seguro, guardar el contexto una vez que se ha detenido,realizar la reconfiguración, volver a arrancar la FPGA y, finalmente, cargar el contextoanteriormente guardado. En cambio, si se hace uso de la reconfiguración parcial, eldiseñador puede modificar o añadir una nueva función a la FPGA sin necesidad dedetener la aplicación, teniendo solo que realizar el place and route de la función aimplementar, generar el bitstream parcial correspondiente y reconfigurar parcialmentela FPGA [Dye12].

Tiempos de reconfiguración menores. El tiempo necesario para realizar la configura-ción de la FPGA es directamente proporcional al tamaño del bitstream y, por lo tanto,a la cantidad de lógica que se vaya a configurar. En la reconfiguración parcial solose configura la lógica que se encuentra dentro de una partición reconfigurable, por loque esta reconfiguración será más rápida que la configuración de la FPGA completa.Adicionalmente, al ser el tamaño de un bitstream parcial menor que el de un bitstreamcompleto, se reduce también el espacio necesario para el almacenamiento de losbitstreams.

Mejora de la tolerancia a fallos. Aprovechando la reconfiguración parcial se handesarrollado diversas técnicas que permiten mejorar la tolerancia a fallos de los sis-temas basados en FPGA, como por ejemplo [ESSA00]. Mencionar también el estudiorealizado sobre el uso de la reconfiguración parcial en los sistemas de los satélites,los cuales están expuestos a radiaciones ionizantes (partículas alfa, etc.) que puedenmodificar el estado de algunas partes de la lógica de la FPGA. En [SPH13] se ofreceun método para mejorar la tolerancia a fallos de las particiones reconfigurables en estetipo de sistemas.

1.3 Tendencias de la reconfiguración parcial en la industriaActualmente el uso de las FPGA en la industria está en contínuo crecimiento [Ins16]: en

el año 2014 el tamaño de mercado estaba valorado en 5270 millones de USD y se espera queexperimente una TCAC (Tasa de Crecimiento Anual Compuesta) del 8.4 % durante el periodo2015-2022. La mayor parte de este mercado pertenece al sector de las telecomunicaciones(33 %), seguido de otros como la industria del automóvil o el procesamiento de datos. Men-cionar también al sector de la supercomputación, en el cual existen proyectos como «Project

Catapult» de Microsoft Research [Res] que buscan mejorar la eficiencia de los servidores

4

incluyendo una FPGA en cada servidor, creando una arquitectura distribuida de aceleradoresque ayudan con la carga de trabajo.

Los sistemas empotrados basados en FPGA encargados del procesamiento de señales eimágenes están bastante extendidos. En este mercado la introducción de la reconfiguraciónparcial puede llegar a ser muy útil a la hora de implementar diseños que sean capaces deadaptarse al entorno en el que operan, los cuales pueden implementar sus algoritmos deprocesamiento de imágenes (filtros, detección, etc.) como módulos reconfigurables para suposterior ejecución en las partes dinámicas de la FPGA.

En el sector del big data resulta de gran interés la aplicación de las FPGAS en el procesa-miento de los datos. En aquellos casos en los que se tiene un flujo de datos entrante que setiene que procesar en forma de streaming, tanto el ancho de banda del flujo de datos entrantecomo la latencia que supone el procesamiento de este flujo es muy importante. Teniendo encuenta estos dos factores existen diferentes arquitecturas de sistemas que incluyen FPGAS

para conseguir un gran rendimiento en el procesamiento de los datos, apoyándose en queéstas ofrecen un buen ancho de banda de E/S y en que se puede alcanzar un algo grado deparalelismo (por ejemplo, se pueden tener múltiples unidades de punto flotante ejecután-dose al mismo tiempo), entre otros [Dol14]. En este ámbito, una aplicación interesante dela reconfiguracion parcial propuesta por [KTB+12] sobre el procesamiento de sentenciasSQL consiste en mejorar la velocidad de respuesta ante cláusulas WHERE implementandolos operadores aritmético-lógicos y los operadores de comparación en módulos reconfigura-bles. Estos módulos pueden utilizarse para formar un pipeline en tiempo de ejecución con elobjetivo de poder evaluar las restricciones que incluye la cláusula en cuestión.

En resumen, teniendo en cuenta el incremento del uso de las FPGAS en el ámbito industrialy las nuevas posibilidades y beneficios que introduce la reconfiguración parcial, resultaríainteresante disponer de una herramienta que haga el flujo de diseño algo más intuitivopara facilitar el proceso de diseño. Esto es lo que se espera conseguir con este TFG.

1.4 Estructura del documentoEn la siguiente lista se indica la finalidad de cada uno de los capítulos restantes de este

documento:

Capítulo 2: ObjetivosEn este capítulo se ofrece al lector una descripción del problema que se pretende re-solver de forma detallada, exponiendo el objetivo general y los objetivos específicosde este TFG.

Capítulo 3: AntecedentesEste capítulo pretende profundizar en todos los temas involucrados en este TFG, in-cluyendo la técnica de la reconfiguración parcial, el flujo de diseño que ofrece Vivado

5

y realizando un análisis de algunas herramientas ya existentes que también pretendenmejorar el flujo de diseño de Vivado.

Capítulo 4: Método de trabajoSe exponen las metodologías que se utilizan en el desarrollo del TFG, explicando condetalle en qué consisten y cómo se han adaptado para su aplicación en el desarrollo delproyecto.

Capítulo 5: Desarrollo del trabajoA lo largo de este capítulo se explica cómo ha ido avanzando el trabajo realizado por elalumno de forma que el lector pueda observar cómo ha ido transcurriendo el desarrollodel TFG.

Capítulo 6: Resultados obtenidosFinalizado el desarrollo, en este capítulo se analizan los resultados obtenidos destacan-do las ventajas más importantes que ofrece la herramienta desarrollada y comparandoel flujo de diseño de esta herramienta con el que ofrece Vivado.

Capítulo 7: Conclusiones y trabajo futuroPor último, en este capítulo se valora si la herramienta desarrollada cumple con to-dos los objetivos que se establecieron en el Capítulo 2 y, además, se ofrecen algunaspropuestas sobre cómo continuar con el trabajo realizado en este TFG.

6

Capítulo 2

Objetivos

C OMO se ha mencionado en la Introducción (Capítulo 1), el uso de las herramientas pro-porcionadas por el fabricante puede llegar a ser complejo e incluso ineficiente cuando

se trata de aplicar la reconfiguración parcial sobre un diseño. La primera tarea que abordaeste capítulo se basa en detallar exahustivamente el problema que se desea resolver, desem-bocando en la descripción de los objetivos de este TFG que permitirán obtener como productofinal una herramienta que optimice y simplifique el desarrollo de aplicaciones dinámicamen-te reconfigurables.

2.1 Descripción del problemaUna de las carencias más importantes que tiene Vivado 1 es la falta de una interfaz

gráfica intuitiva para la reconfiguración parcial, lo que provoca que en algunas partes delproceso de diseño se tenga que hacer uso de la línea de comandos a través de la terminalproporcionada. Esto requiere que el diseñador tenga conocimientos sobre el uso de Vivadoa través de comandos TCL (Tool Command Language). Por otra parte, el flujo de diseñopara aplicaciones dinámicamente reconfigurables varía respecto al flujo de diseño para unaaplicación totalmente estática. Este flujo se verá detalladamente en la Sección 3.3, pero sepuede adelantar que a lo largo de todo el proceso es el diseñador el que se hace cargo desintetizar una a una todas las partes del diseño, de generar y comprobar la compatibilidadentre diferentes configuraciones, y de guardar el estado del diseño en varios puntos concretosdel flujo para después poder recuperarlo, entre otras muchas más responsabilidades.

En este flujo de diseño, en el cual un solo fallo es suficiente para tener que volver haciaatrás en el proceso de diseño y volver a empezar, el diseñador tiene que prestar bastanteatención y dedicar una cantidad importante de tiempo para lograr finalizarlo con éxito.Por lo tanto, si ya de por sí el proceso requiere de bastante tiempo para los diseñadoresexperimentados en él, en el caso de los nuevos diseñadores hay que añadirle el aprendizajedel complejo flujo de diseño, lo que hace que la curva de aprendizaje en estos casos puedallegar a ser demasiado alta.

1Software proporcionado por Xilinx para la creación de proyectos hardware y su posterior síntesis, análisise implementación. Ofrece las herramientas necesarias para el desarrollo de SOC (System on a Chip) y para lasíntesis de alto nivel.

7

Como anotación mencionar también que el uso de la interfaz gráfica de Vivado para, porejemplo, realizar las tareas de floorplanning supone un coste en memoria elevado (más de1GB). Si al coste en memoria de la interfaz le añadimos el de un proceso de síntesis o similaral mismo tiempo el consumo de memoria del sistema puede llegar a dispararse, por lo quesería positiva cualquier reducción del consumo de memoria en este aspecto.

2.2 Objetivo generalEl objetivo principal de este proyecto es desarrollar un flujo de diseño que facilite a los

diseñadores la creación de aplicaciones dinámicamente reconfigurables apoyándose deuna herramienta gráfica ligera, sencilla e intuitiva. El conjunto formado por el flujo de diseñoy la herramienta gráfica buscará reducir la probabilidad de que el diseñador cometa algúnerror a lo largo del flujo de diseño y ofrecerá al diseñador un ahorro de tiempo considerable.Para hacer esto posible se hará uso de proyectos desarrollados por el grupo ARCO, comoel sistema de soporte de reconfiguración de la FPGA y el generador de adaptadores para lacomunicación de los módulos reconfigurables con la parte estática del diseño.

La herramienta incluirá todo lo necesario para el desarrollo de una aplicación reconfi-gurable, desde la importación de los archivos que definen las partes estáticas y dinámicas ala generación de los bitstreams finales. También se incluirá un gestor de la reconfiguraciónque permitirá al usuario programar la FPGA con uno de los bitstreams generados y añadirsoftware (aplicaciones) creado por él para que se ejecute sobre el procesador de la FPGA.

2.3 Objetivos específicosUna vez expuesto el objetivo principal se muestra a continuación una lista de objetivos más

específicos, de forma que la realización de todos ellos permita alcanzar el objetivo principalde este TFG:

1. Implementación en la herramienta de un flujo de diseño que facilite al usuarioel diseño de sistemas dinámicamente reconfigurables. Para ello es necesario incluiry adaptar las librerías desarrolladas por el grupo ARCO, entre las que se incluyen losmódulos hardware de gestión de la reconfiguración desarrollados, las herramientaspara la creación de adaptadores para la comunicación entre las zonas reconfigurables yla parte estática de la FPGA, y los modelos de comunicación internos y externos de laFPGA. Mencionar que el flujo de diseño tiene que ser compatible con Vivado, es decir,todos los scripts para la automatización del flujo que se incluyan en la herramientapodrán ser ejecutados desde Vivado.

2. Desarrollar una herramienta que permita al diseñador definir las áreas reconfi-gurables de la FPGA mostrando de forma gráfica la disposición de los recursos de laplaca de tal modo que el diseñador pueda definir un área solo con seleccionar el con-junto de recursos que la conforman. En la representación, para cada recurso hardware

8

de la FPGA se mostrarán todas sus propiedades (nombre, tipo, zona de reloj) para queel diseñador pueda consultarlas. De esta forma, posteriormente para cada módulo quese defina será el diseñador el que decida en qué área de la FPGA (partición) se tieneque implementar.

3. Conseguir que la herramienta de soporte a los distintos modelos de FPGA que se vana utilizar (ZedBoard y Kintex 7). Además, desarrollar la herramienta de una formagenérica para que después sea fácil y rápido añadir soporte a nuevas placas porparte del diseñador.

4. Ofrecer al usuario la posibilidad de exportar el diseño generado a Xilinx SDK paraque pueda desarrollar software para ese diseño.

5. Dar soporte al usuario para la gestión de la reconfiguración, de forma que una vezque el diseño haya sido generado la reconfiguración se podrá realizar de varias formas:

Desde la propia herramienta a desarrollar en este TFG. Se le permitirá alusuario programar la FPGA haciendo uso de los bitstreams generados. Para elloel diseñador tendrá la opción de decidir qué bitstream cargar y la herramienta seencargará de todo el proceso de programación.

Desde una aplicación creada por el usuario, indicando al módulo de recon-figuración cuándo hay que realizarla. La herramienta incluirá una opción quepermitirá cargar una aplicación creada por el diseñador en el procesador de laFPGA. Esta aplicación, que es siempre responsabilidad del diseñador, puede in-dicar al módulo de reconfiguración que se incluye en este TFG cuándo realizar lareconfiguración (por ejemplo, cuando se pulse un botón). Para facilitar esta tareala herramienta también dará la opción de cargar los bitstreams que se elijan en lamemoria DDR de la FPGA.

6. Proporcionar al diseñador la opción de generar una Zynq Boot Image a partir de undiseño generado para poder exportarlo a una tarjeta SD, de forma que para cargar eldiseño en la FPGA no sea necesario programarla utilizando la herramienta a desarrollaren este TFG.

7. Permitir al diseñador incluir nuevos módulos reconfigurables y la posibilidad de crearnuevas configuraciones tras generar el diseño inicial sin necesidad de volver a gene-rar todo el diseño de nuevo. En el caso de que se cierre la herramienta, si al abrir laherramienta de nuevo se encuentra un diseño generado anteriormente se debe ofreceral diseñador la posiblidad de volver a recuperarlo para añadirle nuevos módulos yconfiguraciones.

8. Conseguir que el consumo de memoria de la GUI de la herramienta a desarrollarsea significativamente menor que el de la GUI de Vivado con el único objetivo dedejar más memoria libre para los procesos propios de las herramientas del fabricante

9

(síntesis, place and route, etc.). De esta forma se reduce en parte la posibilidad deque un sistema utilice la memoria virtual por falta de memoria física, lo que ralentizael proceso de generación del diseño (aunque esto siempre dependerá de los recursosdisponiles del sistema en cuestión).

2.4 Aplicación de la herramientaLa herramienta a desarrollar está destinada en primer lugar a los diseñadores que ya

conocen el flujo de la reconfiguración parcial en Vivado, ya que se les ofrece un flujo dediseño más rápido, con menor probabilidad de errores, y con la posibilidad de consultar entodo momento la información introducida en cada uno de los pasos del flujo.

No obstante, también está pensada para aquellos diseñadores que comiencen en elmundo de la reconfiguración parcial, aunque en este caso sí que sería deseable que elusuario tuviese algunos conceptos básicos sobre el flujo de diseño genérico para una FPGA.En este caso la herramienta, que indica paso a paso la información que hay que introducir ymuestra en todo momento en qué punto del flujo se encuentra el usuario, puede resultar degran ayuda para que un diseñador nuevo en la reconfiguración parcial entienda el proceso aseguir, de forma que la curva de aprendizaje sea menos costosa.

El hecho de que la herramienta incluya un gestor de la reconfiguración y la posibilidadde exportar el diseño generado a Xilinx SDK hace que, si se dispone de la especificaciónde las partes estática y dinámicas de la FPGA, todo lo necesario para desarrollar y poner enmarcha una aplicación dinámicamente reconfigurable se encuentre dentro de la herramienta(exceptuando el desarrollo de software que se realiza en Xilinx SDK).

2.5 Método y fases de trabajoPara el desarrollo de todo lo concerniente a la FPGA se seguirá una metodología de siste-

mas empotrados basada en FPGA [DSAG10]. Este tipo de metodologías se basan en unametodología top-down para el nivel de sistema y de procesador. El diseño comienza ma-peando una aplicación sobre una determinada plataforma para después realizar la síntesís y,finalmente, realizar el place and route. Esta metodología se explica con más detalle en laSubsección 4.1.1.

Por otra parte, para el desarrollo de la parte software se seguirá la metodología ágilScrum. Esta metodología ágil centrada en el usuario define un ciclo de vida iterativo eincremental, mejora la gestión de los riesgos y aumenta la comunicación entre las par-tes [SS16]. Dado que el proyecto puede dividirse en pequeñas iteraciones, y a que una co-municación contínua es fundamental para alguien que emprende un proyecto de este tipopor primera vez, la elección de Scrum queda justificada. En la Subsección 4.1.2 se explicacon más detalle en qué consiste esta metodología y cómo se ha adaptado para su uso en esteproyecto.

10

De acuerdo con el anteproyecto presentado, las fases a seguir en el TFG son:

1. Estudio del arte de las herramientas de soporte de diseño de herramientas diná-micamente reconfigurables, con el objetivo de adquirir los conceptos sobre en quéconsiste y cómo se realiza la reconfiguración parcial, las consideraciones de diseñoque hay que tener en cuenta, el flujo para llevarla a cabo en Vivado, etc.

2. Estudio de las herramientas desarrolladas por el grupo ARCO que se vayan a uti-lizar en este TFG.

3. Estudio de las herramientas de back-end proporcionadas por Xilinx: Vivado a tra-vés de línea de comandos (para realizar la síntesis, el place and route, la optimización,la reconfiguración parcial, etc.), XMD, bootgen, y el resto de herramientas de Xilinxnecesarias para que la herramienta a desarrollar pueda llevar a cabo su funcionalidad.

4. Generación y adaptación de todas las librerías y componentes que vayan a serutilizados por la herramienta final.

5. Generación de la herramienta final con la interfaz de usuario, la cual guiará al usua-rio por el flujo de diseño y permitirá realizar el resto de funcionalidades comentadasen apartados anteriores.

11

Capítulo 3

Antecedentes

C ON este capítulo se pretende elaborar un estudio previo de aquellos trabajos cuya te-mática se encuentre relacionada con la de este TFG. Asimismo se contextualizará el

TFG, aportando cierta terminología y conceptos básicos utilizados. En primer lugar se pro-fundiza en la técnica de la reconfiguración parcial, explicando desde los distintos estilos dereubicación que existen hasta cómo se realiza la programación de la FPGA cuando se utili-za un bitstream parcial. Posteriormente se detalla el flujo de diseño para la reconfiguraciónparcial que ofrece Vivado y, además, se analizan algunas herramientas anteriores a este TFG

que también pretenden mejorar este flujo de diseño. Finalmente se estudia el contenido deun bitstream y las diferentes técnicas de compresión que se le pueden aplicar.

3.1 Field Programmable Gate Arrays (FPGAS)Las Field Programmable Gate Arrays (FPGAS) son un tipo de PLD (Programmable Logic

Device), es decir, son dispositivos programables de propósito general compuestos por unconjunto de elementos lógicos sobre los que el usuario puede implementar su circuito. Sediferencian de otros dispositivos programables como los PAL o los PLA en que no hacenuso de planos de puertas AND u OR para implementar los circuitos, sino que en su lugarproporcionan bloques lógicos para esta tarea; y además, a diferencia del resto, permitenimplementar circuitos que contienen un gran número de puertas lógicas.

A grandes rasgos, la arquitectura de una FPGA está compuesta por bloques lógicos,bloques de E/S y elementos de interconexión para la conexión entre bloques. Los bloqueslógicos son organizados en forma de matriz bidimensional y los elementos de interconexión,compuestos de «cables» y switches, se organizan vertical y horizontalmente.

Cada bloque lógico que se encuentra en el interior de una FPGA cuenta con un númeroreducido de entradas y salidas. Por lo general, el bloque lógico que se utiliza es una LUT

(ver Figura 3.2), la cual contiene en su interior pequeñas celdas de almacenamiento que sonutilizadas para implementar funciones lógicas.

Las herramientas CAD proporcionadas por los fabricantes se encargan de adaptar los cir-cuitos creados por el usuario para que puedan ser implementados en una FPGA. Para imple-mentar un determinado circuito sobre una FPGA se realiza la programación de los bloques

13

Figura 3.1: Estructura genérica de una FPGA.

Figura 3.2: Implementación de una Lookup table (LUT) de dos entradas.

lógicos para que realicen las funciones lógicas necesarias y se establecen las rutas de interco-nexión entre los bloques. Algo importante a destacar es que las celdas de almacenamientode los bloques lógicos son volátiles, es decir, se borrará su contenido en caso de que se de-tenga la FPGA. Esto conlleva que la FPGA necesita ser programada cada vez que se pone enmarcha. Como solución a ésto, algunas FPGAS incluyen una PROM que puede ser utilizadapara cargar los valores de las celdas de almacenamiento cuando se inicia la FPGA.

3.1.1 Ventajas de utilizar FPGAS

En las fases iniciales del desarrollo de un sistema el diseñador debe elegir sobre qué dis-positivo final se implementará el sistema, pudiendo elegir entre utilizar un circuito integradoespecífico (ASIC) o un dispositivo programable. Cada una de las dos opciones tiene susventajas, por lo que dependiendo de los requisitos y de las características del sistema adesarrollar será más conveniente utilizar una opción u otra. Las ventajas de utilizar unaFPGA se encuentran en el Cuadro 3.1 y las de utilizar un ASIC en el Cuadro 3.2.

14

Ventaja DescripciónMenor time-to-market Se reduce el tiempo desde que se inicia el desarro-

llo del sistema hasta que se empieza a comerciali-zar debido a que no es necesario fabricar el circuitointegrado.

Flujo más simple El flujo de diseño se simplifica bastante ya que lasherramientas de los fabricantes de las FPGAS se en-cargan en gran parte del rutado, el placement, etc.

Coste del sistema Si se van a producir pocas unidades del sistema uti-lizar FPGAS es mucho más barato ya que el proce-so de diseñar el circuito integrado y de fabricarlose elimina.

Es reprogramable Se pueden hacer cambios en el diseño inicial y apli-carlos reprogramando la FPGA.

Cuadro 3.1: Ventajas del uso de FPGAS en un sistema. [SZ09] [Xilb]

Ventaja DescripciónMayor personalización El circuito integrado se fabrica atendiendo a

los requisitos del sistema.Coste del sistema Si se va a producir un número importante de

unidades del sistema es mejor utilizar un ASICya que su producción en grandes cantidades esmás barata que la de las FPGAS.

Menor tamaño El circuito integrado se ajusta a la especifi-cación del sistema, eliminando respecto a lasFPGAS todo el mecanismo de rutado entre blo-ques lógicos.

Mayor rapidez Al estar diseñado para una aplicación especí-fica y no para propósito general, la rapidez deun ASIC es mayor que la que ofrece una FPGA.

Cuadro 3.2: Ventajas del uso de un ASIC en un sistema. [SZ09] [Xilb]

15

Comparando el uso de FPGAS frente a otro tipo de PLD como por ejemplo un CPLD, unacaracterística importante de este último es que una vez programado retiene el estado aunquese les corte la alimentación eléctrica, es decir, son no volátiles. A pesar de esto, las FPGAS

contienen una cantidad de lógica mucho mayor a la que se puede encontrar en un CPLD,lo que permite implementar circuitos de mayor tamaño.

3.2 Reconfiguración parcialLa reconfiguración parcial consiste en la modificación de una parte de la lógica de la

FPGA cuando ésta se encuentra en estado operativo, lo cual se consigue cargando un bits-tream parcial en la FPGA. A lo largo de todo este TFG se hará uso de la reconfiguraciónparcial basada en módulos, cuyo funcionamiento, ventajas y su tendencia en la industria semuestran en las Secciones 1.1, 1.2 y 1.3 respectivamente.

3.2.1 Estilos de reubicación de los módulos reconfigurablesEn la reconfiguración parcial basada en módulos existen varios estilos de reubicación que

definen cómo se implementan los módulos en las particiones reconfigurables. El diseñadorque quiera aplicar este tipo de reconfiguración parcial deberá escoger qué estilo de reubica-ción se adapta mejor a su diseño. En esta sección se estudian dos estilos: island style y slot

style.

Parte estática

Partición reconfigurable

Parte estática


Parte estática


Parte estática


Island style

M1

Slot style

M1

CM2C

M2C

M3C

Grid style

M1

C

Figura 3.3: Estilos de reubicación de los módulos (C es la interfaz de comunicación).

Island style

Este tipo de reubicación define que en cada partición reconfigurable solo puede haberun módulo implementado, es decir, no puede haber dos o más módulos implementadosen una partición al mismo tiempo. Dentro de este esquema, si un módulo solo puede serimplementado en una partición determinada se habla de single island, mientras que si unmódulo puede ubicarse en diferentes particiones reconfigurables se denomina multi island.Vivado solo soporta el estilo single island, ya que para cada módulo se genera el bitstreamparcial correspondiente a su implementación en una partición reconfigurable determinada.Si un módulo va a ser utilizado en diferentes particiones (multi island) haciendo uso de las

16

herramientas de bajo nivel de Xilinx, se deberá generar un bitstream parcial para cada unade las particiones donde se pueda ubicar el módulo.

El problema principal que presenta este método es la fragmentación interna que ocurrecuando se carga un módulo pequeño en una partición grande, ya que los recursos de lapartición que no son ocupados por el módulo quedan libres pero no pueden ser utilizados.

Slot style

En este estilo de reubicación la partición se divide en zonas de igual tamaño (slots), ypara cada módulo que pueda implementarse en esa partición se define el número de slots

que ocupa dependiendo de los recursos que necesite [KTB+12]. De esta forma, si un móduloocupa dos slots y otro módulo ocupa un slot, y si existe una partición con una capacidadtotal de tres slots, ambos módulos pueden estar implementados en la partición al mismotiempo. En el caso de que la partición se divida en forma de matriz este tipo de reubicaciónse define como grid style.

A pesar de que en este estilo los recursos de la partición reconfigurable se pueden aprove-char mejor, se puede dar el caso de que todos los slots que queden libres no estén contiguosy que por ello no se puedan implementar nuevos módulos (fragmentación externa). El pro-blema de cómo ubicar los módulos reconfigurables en este estilo de reubicación se trata enestudios como [CDG+13], donde se propone el uso de un planificador que resuelve las peti-ciones de reconfiguración parcial que recibe de una aplicación, indicando cómo y dónde sedebe reconfigurar un módulo teniendo en cuenta la reutilización de recursos hardware y laposibilidad de escalar el diseño.

También hay que tener en cuenta que cada módulo reconfigurable deberá incluir una in-terfaz para que sea posible la comunicación entre la parte estática y el módulo en cuestión.Esto se abordará a continuación (Subsección 3.2.2).

3.2.2 Comunicación entre parte estática y parte dinámica

En la reconfiguración parcial la implementación de la comunicación entre la parte estáticay la parte dinámica adquiere especial relevancia ya que se tiene que garantizar que la lógi-ca que se encarga de la comunicación no se ve afectada en el proceso de reconfiguración.Además, todos los módulos que se implementen en una partición tienen que ser capaces deutilizar esta lógica para establecer un canal de comunicación con la parte estática del dise-ño.

En esta sección se estudia en primer lugar cómo implementa Xilinx esta comunicaciónentre las dos partes ya que es la opción que se utiliza en este TFG y, después, qué técnicas decomunicación utilizan otras herramientas que aceptan el estilo de reubicación slot style.

17

Implementación de Xilinx

En los primeros flujos de diseño para la reconfiguración parcial de Xilinx la comunica-ción entre parte estática y parte dinámica se implementaba haciendo uso de «bus macros»,los cuales son puertos físicos utilizados para comunicar entre sí ambas partes. Estoselementos de conexión se instancian como cajas negras a nivel de RTL y después son im-plementados a partir de un bus macro ya rutado que sirve como plantilla, ya que si cada busmacro es rutado de forma distinta la interoperabilidad entre ellos se rompe. Como se puedeobservar en la Figura 3.5, estos elementos de conexión se implementan utilizando bufferstriestado. Al actuar como interfaz deben situarse en los bordes de las partes que se quierencomunicar y su implementación física debe ser fijada para que no varíe cuando se realiceuna reconfiguración parcial [Xil04].

ReconfigurableModule

Reconfigurableor

FixedModule

BusMacro

x290_03_032702

Figura 3.4: Uso de un «bus macro» para la comunicación entre parte estática y parte dinámi-ca [Xil04].

CENTER(Boundary) between B and C

X290_05_032502

RI [3:0]

RO [3:0]

RT [3:0]

LI [3:0]

LO [3:0]

LT [3:0]

Figura 3.5: Implementación de un «bus macro» utilizando buffers triestado [Xil04].

Actualmente Xilinx utiliza otros componentes para la comunicación entre parte es-tática y parte dinámica: los llamados «pines de partición» (partition pins). Estos pines secolocan como interfaz entre los puertos de ambas partes y, al igual que los bus macros, sonnecesarios para asegurar que las conexiones entre la parte estática y todos los posibles módu-los de una partición son iguales. En un principio los pines de partición eran implementados

18

utilizando proxy logic (una LUT) [Xil13b], pero desde la llegada de Vivado estos pinesson «virtuales», es decir, no se introduce ninguna lógica especial en estos puntos de inter-conexión entre la parte estática y la parte dinámica [Xil13c]. De esta forma se eliminan losretardos asociados a las LUTS que sí que se introducían anteriormente. Vale la pena mencio-nar también que los pines de partición son insertados automáticamente por Vivado cuandose ejecuta la implementación de un diseño reconfigurable.

Top (static)RP_A

RM_A1

A B

C D

1

2

Figura 3.6: Comunicación entre parte estática y parte dinámica utilizando «pines de parti-ción» [Xil13b].

Otras herramientas

Existen herramientas como OPENPR y GOAHEAD (Sección 3.4) que aceptan el estilode reubicación slot style y que abordan el problema de la comunicación entre parte estáti-ca y dinámica utilizando blocker macros. Estas macros, que hacen creer a la tecnología derutado que una parte de la lógica está ocupada, se colocan de forma estratégica para que latecnología de rutado solo tenga una opción posible a la hora de establecer un flujo de comuni-cación entre parte estática y módulo reconfigurable. Por otra parte mencionar la herramientaDREAMS [OdlTR12], que introduce el concepto de virtual borders para comprobar si es po-sible la conexión entre dos partes (ya sea entre parte estática y parte dinámica o entre partesdinámicas). Un virtual border es una estructura de datos que guarda información sobre lasconexiones de entrada o salida que tiene un componente para comunicarse con otros. A lahora de implementar un módulo en una posición determinada de una región reconfigurablese comprueba si en esa posición los virtual borders de las partes son compatibles entre sío no. En el caso de que sean compatibles la conexión entre las partes la realiza un rutadorpropio que incluye DREAMS, quedando asegurada la comunicación.

3.2.3 Programación de la FPGA utilizando un bitstream parcialLa reconfiguración parcial se lleva a cabo programando la FPGA con un bitstream par-

cial, el cual contiene toda la información necesaria para implementar un módulo reconfi-

19

gurable en la lógica de la FPGA. El usuario no tiene que indicar la zona en la que se debeaplicar la reconfiguración ya que en el propio bitstream parcial se especifica qué zona dela FPGA es la que se tiene que reconfigurar, haciendo imposible por tanto que se realice lareprogramación en una zona equivocada.

El proceso de configuración de la FPGA cuando se aplica reconfiguración parcial difieredel proceso que tiene lugar cuando se programa un bitstream completo. Cuando se utiliza unbitstream completo (ver Figura 3.7) la lógica de la FPGA comienza a configurarse despuésdel power-on reset 1. Todo el proceso de programación de la FPGA se realiza en modo con-figuración, pasando a modo usuario una vez que éste ha finalizado. En cambio, cuando seutiliza un bitstream parcial (ver Figura 3.8) la configuración de la lógica de la FPGA ocurreen modo usuario para que la parte estática no se vea interrumpida durante la reprogramaciónparcial de la FPGA.

X-Ref Target - Figure 6-1

X12031

Full Configuration Bit File

Config. Data HeaderCheck Sum

Configuration Mode User Mode

FPGA

StartVcc Rise

VccStable

Power-onReset

Download FullBit File

DONEAsserted

Figura 3.7: Proceso de configuración de la FPGA utilizando un bitstream completo [Xil13b].

X-Ref Target - Figure 6-2

X12032

Partial Configuration Bit File

Config. Data

Configuration Mode User Mode

FPGA

StartVcc Rise

Initial Configuration DoneAsserted

DownloadPartial Bit File

Figura 3.8: Proceso de configuración de la FPGA utilizando un bitstream parcial [Xil13b].

1Señal de reset generada por el hardware cuando se inicia para asegurar que el dispositivo comienza en unestado conocido.

20

La configuración de la FPGA se lleva a cabo a través de la lógica encargada de interpretar elcontenido de los bitstreams. Xilinx ofrece a los diseñadores varios métodos para accedera esta lógica y poder así realizar la reconfiguración parcial [Xil13b]:

ICAP (Internal Configuration Access Port). Componente hardware interno que re-quiere instanciar en el diseño un controlador ICAP (ver Figura 3.9) para poder usarlo.Este es el método que se utilizará en este TFG. Mencionar que los dispositivos de lafamilia Zynq incluyen en su hardware dos componentes ICAP.

PCAP (Processor Configuration Access Port). Método de reconfiguración recomen-dado para aquellos diseños basados en Zynq-7000.

JTAG (Joint Test Action Group). Este método, establecido en la norma IEEE 1149.1,se utiliza para la depuración o testing de un diseño.

Slave SelectMAP o Slave Serial. Método que permite realizar tanto la reconfiguraciónparcial como la configuración completa de la FPGA utilizando la misma interfaz.

Figura 3.9: Componente ICAPE2 que permite acceder a las funciones de configuración de laFPGA [Xil15b].

3.3 Flujo de diseño de Vivado para la reconfiguración parcialEn la actualidad, diseñar una aplicación reconfigurable requiere utilizar las herramientas

proporcionadas por el fabricante de la FPGA. En el caso de este TFG se trabajará con el en-torno de desarrollo Vivado y el conjunto de herramientas de Xilinx que se proporcionan conéste. Como se podrá observar a lo largo de esta sección, el flujo de desarrollo de estas herra-mientas puede resultar complejo cuando se trata de diseñar un sistema reconfigurable.

La reconfiguración parcial en Vivado sólo se soporta a través de comandos TCL (ToolCommand Language), por lo que todo el flujo de desarrollo que se muestra a continuaciónhace uso de este lenguaje de scripting.

Mencionar que durante todo el flujo de desarrollo se hace uso de los design checkpoints.Un design checkpoint (.dcp) es una base de datos donde se guarda el estado de un diseño enun punto determinado del flujo de diseño. Por ejemplo, una vez ejecutada la síntesis de unmódulo reconfigurable se puede guardar el resultado obtenido en un checkpoint, de forma

21

que después se pueda recuperar ese resultado sin necesidad de volver a ejecutar el procesode síntesis.

Paso 1: Síntesis del diseño

La síntesis de un diseño reconfigurable se lleva a cabo siguiendo una metodología bottom-

up: cada componente se sintetiza de forma independiente (out-of-context). Al establecer uncomponente como out-of-context se separa del resto del diseño, lo que nos permite sinteti-zarlo de forma separada y nos evita tener que volver a sintetizarlo cuando otras partes deldiseño sean modificadas [Xil15d]. Actualmente, Vivado soporta las siguientes herramientasde síntesis: XST, Synplify, y Vivado Synthesis. Esta última, proporcionada por Xilinx, es laque se utiliza en este TFG.

En primer lugar se debe realizar la síntesis de la parte estática del diseño, generando unRTL (Register Transfer Level) de alto nivel en el que dentro de cada región reconfigurableexiste una «caja negra». Una caja negra no contiene ningún tipo de lógica definida por elusuario, lo cual no implica que la región física que ocupa esté vacía ya que las rutas está-ticas y las interfaces de los pines de la partición sí que se encuentran dentro de esta regiónfísica. [Xil13c]

synth_design -flatten_hierarchy rebuilt -top <top_module_name> -part <part>

Listado 3.1: Síntesis de la parte estática en TCL

Una vez que se realiza la síntesis de la parte estática lo siguiente es sintetizar los mó-dulos reconfigurables. Todos los módulos reconfigurables que se vayan a implementar enuna determinada partición serán instanciados en la misma caja negra, por lo que todos losmódulos deben tener el mismo nombre y además sus interfaces deben ser iguales.

A la hora de sintetizar un módulo para una determinada partición se debe deshabilitar lainserción automática de buffers de E/S. Esto se indica a través de la opción -mode

out_of_context.

Los pasos a seguir para sintetizar un módulo reconfigurable son:

1. Leer el archivo HDL (Hardware Description Language) donde se encuentra descrito elmódulo.

2. Realizar la síntesis del módulo.

3. Guardar el resultado de la síntesis en un checkpoint.

4. Cerrar el diseño (recomendado).

22

read_vhdl <reconfig_module_HDL>

# read_verilog <reconfig_module_HDL>

synth_design -mode out_of_context -flatten_hierarchy rebuilt -top <reconfig_mod_name> -part <part>

write_checkpoint <file_name>.dcp

close_design

Listado 3.2: Síntesis de un módulo reconfigurable en TCL

Paso 2: Cargar el diseño en memoria

Una vez realizada la síntesis de todas las partes, el siguiente paso es cargar en memoriael diseño de la parte estática y el de un módulo reconfigurable para cada partición. Esto sepuede realizar de tres formas:

Opción 1 (Read EDIF / Link design). Si las distintas partes del diseño han sido sinte-tizadas utilizando una herramienta distinta a Vivado Synthesis, se carga la parte estáticay los módulos reconfigurables a través del comando read_edif y se enlazan todas laspartes abiertas con el comando link_design (ver Listado 3.3).

Opción 2 (Open checkpoint / Update design). Se utiliza esta opción en el caso deque la parte estática se encuentre implementada en un checkpoint y los módulos seencuentren sintetizados en forma de netlist (ver Listado 3.4).

Opción 3 (Open / Read checkpoint). Si tanto la síntesis de la parte estática comola de los módulos se guardaron en un checkpoint, en primer lugar se carga la parteestática a través del comando open_checkpoint para después cargar la síntesis de losmódulos utilizando el comando read_checkpoint (ver Listado 3.5). Esta es la opciónque se utiliza en este TFG.

# Cargar parte estatica (archivos .edf, .edn, .ngc)

read_edif <top>.edf

# Cargar un modulo reconfigurable para una particion (archivos .edf, .edn, .ngc)

read_edif <rp1_a>.edf

link_design -top <top_module_name> -part <part>

Listado 3.3: Cargar un diseño en memoria en TCL (Opción 1)

# Cargar la parte estatica y fijar el diseno a nivel de routing

open_checkpoint <top>.dcp

lock_design -level routing

# Actualizar una particion reconfigurable con el contenido de un modulo

update_design -cells <rp1> -from_file <rp1_b>.{edf/edn/ngc}


23

# Cargar la parte estatica

open_checkpoint <top_file>.dcp

# Cargar un modulo reconfigurable en la particion <cellname>

read_checkpoint -cell <cellname> <reconfig_mod_file>.dcp [-strict]


Paso 3: Definir las regiones reconfigurables

Un Pblock (partition block) determina la zona que ocupa una partición reconfigurabledentro de la FPGA, de forma que todos los recursos que estén dentro de esa zona puedan serutilizados por los módulos que se carguen en dicha partición. Por lo tanto, para cada particiónreconfigurable es necesario definir un Pblock.

Los pasos a realizar son los siguientes:

1. Crear un nuevo Pblock.

2. Añadir un componente al Pblock (en este caso se añade una partición reconfigurable).

3. Definir el tamaño y recursos hardware que se quieren añadir al Pblock.

create_pblock pblock_instance

# <cell_name> es el nombre de la celda que representa la particion reconfigurable

add_cells_to_pblock [get_pblocks pblock_instance] [get_cells [list <cell_name>]]

# En este caso se anaden los recursos SLICE_X34Y109:SLICE_X39Y123, DSP48_X2Y44:DSP48_X2Y47

resize_pblock [get_pblocks pblock_instance] -add {SLICE_X34Y109:SLICE_X39Y123}

resize_pblock [get_pblocks pblock_instance] -add {DSP48_X2Y44:DSP48_X2Y47}

Listado 3.6: Definir una región reconfigurable en TCL

Paso 4: Establecer la propiedad HD.RECONFIGURABLE

Para que la herramienta de desarrollo reconozca un componente de la jerarquía (una celda)como una partición reconfigurable es necesario activar la propiedad HD.RECONFIGURABLEde dicho componente. Al activar esta propiedad se llevan a cabo una serie de tareas y cam-bios en otras propiedades que permitirán posteriormente la reconfiguración, como por ejem-plo:

Se activa la propiedad DONT_TOUCH en el componente especificado y en su interfaz.

Se activa EXCLUDE_PLACEMENT en el componente para evitar que la parte estáticapueda cargarse en la zona reconfigurable.

Se activa CONTAIN_ROUTING en el componente.

Se habilita código especial para DRC (Design Rule Checking), etc.

24

# Cambiar el valor de la propiedad para el componente (celda) <cell_name>

set_property HD.RECONFIGURABLE TRUE [get_cells <cell_name>]

Listado 3.7: Activar la propiedad HD.RECONFIGURABLE en TCL

Paso 5: Implementar la primera configuración completa

Al poder cargar distintos módulos en una partición reconfigurable tenemos varias com-binaciones posibles entre parte estática y módulo que se encuentra cargado en la partición.El número de combinaciones aumenta si tenemos varias particiones reconfigurables en eldiseño. A cada una de estas combinaciones le llamamos configuración.

Una vez que hemos realizado los pasos anteriores el proyecto tiene cargada la parte estáticadel diseño y un módulo reconfigurable para cada partición, es decir, el proyecto tiene cargadauna configuración completa. A continuación se indican los pasos necesarios para realizar laimplementación de dicha configuración:

(a) Ejecutar la optimización a nivel lógico antes de mapear la lógica en la FPGA. Losprocesos de optimización que permite realizar Vivado son los siguientes [Xil15e]:

Retargeting (por defecto): reemplazar una celda por otra con el objetivo de faci-litar la optimización.

Constant propagation (por defecto): propaga los valores constantes a través de lalógica, lo que permite eliminar lógica innecesaria (por ejemplo una puerta ANDcon una entrada constante a 0), reducir la lógica, o detectar lógica redundante.

Remap: combina múltiples LUTS en una única LUT para reducir los niveles de lalógica.

Sweep (por defecto): elimina aquellas celdas que no tengan carga.

Block RAM Power Optimization (por defecto para los dispositivos de la serie 7):cambia el modo de los puertos que no son leídos de WRITE_MODE aNO_CHANGE.

Resynth area: reduce el número de LUTS.

Resynth sequential area: reduce tanto la lógica combinacional como la secuen-cial. Es más completa que la opción Resynth area.

(b) Mapear la lógica en la FPGA (placement). La tecnología proporcionada por Vivadomapea la lógica atentiendo a una serie de criterios [Xil15e]:

Minimizar la longitud de las conexiones, evitando problemas de tiempos (tim-

ming).

Intentar reducir la densidad de pines y de la lógica con el fin de evitar futurosproblemas de congestión de rutado. Vivado equilibra la lógica a rutar por toda la

25

FPGA, dividiéndola en cuatro partes e intentando que todas ellas mantengan unequilibrio (contengan más o menos la misma cantidad de lógica). De esta formase busca evitar congestionar la FPGA.

El mapeo de las celdas que se encuentren en los caminos críticos temporales deldiseño se realiza buscando minimizar la holgura negativa.

(c) Ejecutar la tecnología de rutado de Vivado, la cual se encarga de rutar la lógicamapeada en la FPGA y lleva a cabo tareas de optimización con el objetivo de resolverposibles incumplimientos de la holgura temporal requerida. [Xil15e]

#opt_design [-retarget] [-propconst] [-sweep] [-bram_power_opt] [-remap] [-resynth_area] [

-resynth_seq_area] [-directive <arg>] [-quiet] [-verbose]

opt_design

#place_design [-directive <arg>] [-no_timing_driven] [-timing_summary] [-unplace] [-post_place_opt]

[-quiet] [-verbose]

place_design

#route_design [-unroute] [-release_memory] [-nets <args>] [-physical_nets] [-pin <arg>] [-directive

<arg>] [-tns_cleanup] [-no_timing_driven] [-preserve] [-delay] [-auto_delay] -max_delay <arg>

-min_delay <arg> [-timing_summary] [-finalize] [-quiet] [-verbose]

route_design

Listado 3.8: Implementar la primera configuración en TCL

Paso 6: Guardar la implementación de la primera configuración

El siguiente paso es guardar la implementación de la configuración anterior (parte está-tica más los módulos reconfigurables en cuestión) y la implementación de cada uno de losmódulos reconfigurables de forma independiente.

# Guardar la configuracion completa

write_checkpoint <config1_routed>.dcp

# Guardar un modulo reconfigurable (<cellname> = particion donde se encuentra el modulo)

write_checkpoint -cell <cellname> <filename>.dcp

Listado 3.9: Guardar la implementación de la primera configuración en TCL

Paso 7: Eliminar los módulos y guardar solo la parte estática

A continuación se deben eliminar los módulos reconfigurables del diseño para poder guar-dar la implementación de la parte estática. Para ello, en primer lugar se sustituyen los módu-los reconfigurables de las particiones por cajas negras, después se fija el mapeo y el rutado

26

de la parte estática para asegurar que sea idéntica entre las distintas configuraciones que sevan a implementar, y finalmente se guarda el resultado en un checkpoint.

# Establecer una particion como caja negra

update_design -cell <cellname> -black_box

# Fijar el mapeo y el rutado de la parte estatica

lock_design -level routing

# Guardar la implementacion de la parte estatica

write_checkpoint <static_routed>.dcp

close_design

Listado 3.10: Guardar la implementación de la parte estática en TCL

Paso 8: Añadir nuevos módulos e implementar la nueva configuración

Una vez implementada la primera configuración completa y guardada la implementaciónde los primeros módulos reconfigurables y de la parte estática, se crea una nueva configura-ción añadiendo nuevos módulos reconfigurables a las particiones. Después se implementa lanueva configuración y se guardan tanto las implementaciones de los nuevos módulos recon-figurables como la nueva configuración completa.

Se debe repetir este paso hasta que todos los módulos reconfigurables de nuestrodiseño hayan sido implementados.

# Abrir la parte estatica con el mapeo y el rutado fijado

open_checkpoint <static_routed>.dcp

# Anadir un nuevo modulo (<reconfig_mod_file>) a una particion reconfigurable (<cellname>)

read_checkpoint -cell <cellname> <reconfig_mod_file>.dcp

# Implementar la configuracion

opt_design

place_design

route_design

# Guardar la implementacion de la nueva configuracion y de los nuevos modulos

write_checkpoint <config2_routed>.dcp

write_checkpoint -cell <cellname> <file>.dcp

close_design

Listado 3.11: Ejemplo en el que se implementa una nueva configuración en TCL

Paso 9: Crear la configuracíon blanking (Opcional)

En esta configuración se carga sólo la parte estática del diseño y se insertan LUTS en lassalidas de las particiones reconfigurables, de forma que la partición no incluye ninguna lógicade usuario pero sí que se establecen sus salidas de forma fija. Para crear esta configuración esnecesario: abrir el checkpoint que contiene la parte estática rutada, actualizar las particiones

27

reconfigurables para insertar las LUTS, realizar el place and route de la configuración, yguardar el resultado en un checkpoint.

open_checkpoint <static_routed>.dcp

# Insertar las LUT en las particion reconfigurable <cellname> (opcion -buffer_ports)

update_design -buffer_ports -cell <cellname>

# Realizar el place and route

place_design

route_design

# Almacenar el resultado

write_checkpoint <blanking>.dcp

close_design

Listado 3.12: Crear la configuración blanking en TCL

Paso 10: Realizar la verificación de todas las configuraciones posibles

Una vez que han sido implementadas todas las configuraciones necesitamos validar laconsistencia entre éstas utilizando la herramienta pr_verify. Esta herramienta toma comoentrada dos configuraciones que ya están rutadas y las compara. Su salida es una lista con lasdiferencias que se han encontrado entre las partes lógicas y los pines de partición de las dosconfiguraciones. Lógicamente, la herramienta no tiene en cuenta el mapeo y el rutado de losmódulos reconfigurables.

Destacar que si nuestro diseño no pasa la verificación de las configuraciones no se debegenerar el bitstream.

# Para verificar dos configuraciones:

pr_verify <file1> <file2>

# Para verificar mas de dos configuraciones:

pr_verify -initial <file1> -additional {<file2> <file3> ... <fileN>}

Listado 3.13: Verificar las configuraciones creadas en TCL

Paso 11: Generar el bitstream de cada configuración

El último paso es generar el bitstream de cada configuración haciendo uso de la herramien-ta write_bitstream. Por defecto, cuando esta herramienta recibe como entrada un checkpointque contiene particiones reconfigurables, se genera el bitstream de la configuración completay un bitstream parcial para cada módulo reconfigurable existente en dicha configuración.

Mencionar que se recomienda cerrar el proyecto cargado en memoria después de generarlos bitstreams para una determinada configuración, sobre todo si después se van a generarotros bitstreams.

28

# Abrir una configuracion

open_checkpoint <config1_routed>.dcp

# Generar el bistream completo y los bitstream parciales

write_bitstream -file <file_name>.bit

# Cerrar el proyecto (recomendado si despues se van a generar otros bitstreams)

close_project

Listado 3.14: Generar un bitstream en TCL

El contenido y la estructura de los bitstreams, así como las diferentes técnicas de compre-sión que se pueden aplicar sobre éstos, se verán en la Sección 3.5.

3.4 Otras herramientas para aplicar la reconfiguración parcialEn esta sección se estudian dos aplicaciones que intentan mejorar el flujo de la reconfigu-

ración parcial para que al diseñador le sea más fácil aplicar esta técnica. Las dos aplicacionesque se muestran (OPENPR y GOAHEAD) intentan reducir el número de tareas que tiene querealizar el diseñador mediante la automatización de algunos procesos. Como se verá de for-ma más específica, el inconveniente que presentan ambas es que hacen uso de herramientasy tecnologías a las que Xilinx dejó de dar soporte en Vivado.

3.4.1 OpenPROPENPR [SAFW11] es una herramienta con una funcionalidad similiar a la que ofre-

cía Xilinx cuando añadió el soporte a la reconfiguración parcial en ISE Design Suite 9.2i.La principal diferencia que presenta respecto a las herramientas de Xilinx es que está libe-rada como código abierto, de forma que se permite a los investigadores poder extender yadaptar este software atendiendo a las necesidades específicas de cada proyecto. Toda la in-formación que utiliza de Xilinx se puede encontrar de forma pública (por ejemplo el lenguajeXDL, documentación, manuales, etc.).

El proceso de diseño que establece esta herramienta consiste en los siguientes pasos:

1. Creación/Apertura de un proyecto. Los datos de un proyecto en OPENPR (nombredel diseño, ruta de la parte estática, etc.) se guardan en un fichero XML, el cual puedeser generado si se crea un nuevo proyecto o cargado al programa si se desea recuperarun proyecto anterior. En este paso es necesario cargar todos los archivos HDL quedefinan la parte estática de la FPGA y realizar la síntesis utilizando la herramienta XST

proporcionada por Xilinx, la cual almacenará el resultado de la síntesis en un archivoNGC (archivo que contiene la netlist y las restricciones).

2. Floorplanning. Una vez que se ha creado el UCF (User Constraints File) para la parteestática, el usuario puede realizar el floorplanning del diseño utilizando las herramien-tas proporcionadas por Xilinx. Después el diseñador deberá sintetizar los módulos y

29

Figura 3.10: Flujo de diseño de OPENPR [SAFW11]

comprobar que los módulos son compatibles con la partición en la que se pretendenintroducir. Una vez que realiza esto último, el usuario puede exportar el archivo UCF

de todo lo realizado y continuar con la generación del diseño reconfigurable.

3. Generación de la parte estática. El siguiente paso es ejecutar la orden make static,la cual se encargará de generar el bitstream asociado a la parte estática llamando aherramientas tanto propias de OPENPR como de Xilinx.

4. Generación de las partes dinámicas. El diseñador tiene que cargar los archivos quedefinen a los módulos reconfigurables y sintetizarlos de la misma forma que se hizocon la parte estática (es decir, utilizando la herramienta XST de Xilinx). Una vez que seobtienen los archivos NGC, el diseñador solo tiene que ejecutar la orden make partial

para que OPENPR genere los bitstreams parciales de cada módulo.

30

El problema que presenta la herramienta OPENPR es que hace uso de lenguajes, herra-mientas y formatos de archivo que ya no se incluyen ni se soportan desde la publicación deVivado. Por ejemplo, los archivos UCF son sustituidos actualmente por los archivos XDC (Xi-linx Design Constraints), los archivos NGC donde se almacena el resultado de la síntesis sesustituyen por los design checkpoints, etc. Por lo tanto, para poder usar OPENPR tendríamosque utilizar software de Xilinx más antiguo (ISE Design Suite).

3.4.2 GoAheadGOAHEAD [BKT12] es un framework para la reconfiguración parcial que nace con el

objetivo de ocultar al diseñador los aspectos de bajo nivel necesarios durante el procesode diseño de un sistema reconfigurable. Esto se consigue permitiendo al diseñador abstraersede la arquitectura de la FPGA, de forma que pueda prestar más atención en los temas relacio-nados con la reconfiguración parcial (módulos y su geometría, interfaces y planificación) enlugar de centrarse en la lógica de la FPGA (wires, switches, etc.).

La herramienta soporta la posibilidad de que dos o más módulos reconfigurables estén im-plementados en la misma partición al mismo tiempo, y además incluye soporte a la reconfi-guración jerárquica, lo que permite definir regiones reconfigurables dentro de los módulosde la misma forma que se definen estas regiones dentro de la parte estática de la FPGA.

Figura 3.11: Interfaz gráfica de la herramienta GOAHEAD [BKT12]

A continuación se muestra sin entrar mucho en detalle el flujo de diseño que ofrece laherramienta, el cual pretende aumentar la productividad del diseñador y disminuir la proba-bilidad de cometer errores:

31

1. Planificación inicial. En esta fase el diseñador tiene que especificar las partes estáticasy dinámicas (módulos) del sistema. Los módulos y sus interfaces con la parte estáticase pueden definir siguiendo una metodología bottom-up, en la cual se define primero lainterfaz y después se adaptan los módulos a esa interfaz. Dado que GOAHEAD permiteque haya dos o más módulos cargados en una partición al mismo tiempo, también sepuede seguir una metodología top-down en la que cada módulo contenga su propiainterfaz con la parte estática, de forma que la unión de todas las interfaces definanla interfaz completa con la parte estática del sistema. Mencionar que en esta fase lasinterfaces se definen a nivel de HDL.

2. Floorplanning. Una vez que se han definido las partes estáticas y los módulos, elsiguiente paso es decidir la zona de la FPGA en la que implementar una partición re-configurable. En el caso de que en una partición solo pueda haber al mismo tiempoun módulo cargado, se calcula el número de recursos a utilizar atendiendo al móduloque ocupe más recursos. Si por el contrario pueden existir varios módulos al mismotiempo en una partición, el número de recursos a ocupar por la partición reconfigura-ble deberá ser introducido manualmente. Respecto a las interfaces de comunicaciónentre parte estática y la parte dinámica, GOAHEAD dispone de una funcionalidad quepermite generar automáticamente la interfaz de una partición reconfigurable a partir delas descripciones HDL de los módulos.

3. Implementación de la parte estática. Al realizar el floorplanning GOAHEAD gene-ra las plantillas VHDL necesarias para la comunicación entre la parte estática y losmódulos reconfigurables (desde un punto de vista a nivel de sistema). Estas planti-llas generadas deberán agregarse a la parte estática de forma manual. La definición dela parte estática, incluyendo las plantillas generadas por GOAHEAD, se tendrán quesintetizar utilizando una herramienta de síntesis de terceros (por ejemplo, las propor-cionadas por Xilinx). Después, el resultado de la síntesis será mapeado en la lógica dela FPGA atendiendo al archivo de restricciones generado también por GOAHEAD. Elresto de pasos necesarios para finalizar la implementación estática son realizados porel script gen_static que debe ser ejecutado por el usuario.

4. Implementación de los módulos. Para cada módulo se generan en primer lugar lasplantillas VHDL de su interfaz con la parte estática y las restricciones que se le apli-carán. Estos ficheros, junto con la definición del propio módulo, se implementarán deforma similar a la implementación de la parte estática. Mencionar que la única depen-dencia de los módulos con la parte estática son las interfaces de comunicación, por loque GOAHEAD implementa cada módulo de forma separada. Al igual que para la parteestática, los pasos restantes para la implementación de los módulos son realizados porel script gen_partial.

En la actualidad, uno de los inconvenientes más importantes que presenta GOAHEAD es

32

Figura 3.12: Flujo de diseño de GOAHEAD [BKT12]

que hace uso de XDL y de formatos de archivo como NCD (Native Circuit Description). Estelenguaje y estos formatos se siguen incluyendo en ISE Design Suite 14, pero Xilinx dejó deincluir y de dar soporte a estos elementos con la llegada de Vivado.

3.5 Contenido y compresión de un bitstream

Un bitstream es una secuencia de bits que contiene los datos y las instrucciones necesariaspara poder configurar una FPGA. Los datos se utilizan para configurar la arquitectura de laFPGA (los elementos lógicos y sus interconexiones, los pines, etc.), y las instrucciones soninterpretadas por el controlador que se encarga de la configuración. [CB11]

La reducción del tamaño de un bitstream es de gran valor cuando se utiliza un dispositivocon una capacidad de almacenamiento limitada. Además, dado que al realizar la configura-ción de la FPGA es necesario leer el bitstream de memoria, las operaciones de E/S se veríanreducidas. En el caso de que esta configuración se realice a través de una red se reduciríael número de paquetes necesarios para llevarla a cabo. Por tanto, podemos concluir que eltiempo necesario para llevar a cabo la reconfiguración depende en cierto modo del tamañodel bitstream en cuestión.

En un diseño reconfigurable el número de bitstreams existentes aumenta, distinguiendotres tipos: bitstreams de configuraciones completas, bitstreams parciales, y blanking bits-

treams. Debido a este hecho y a todas las razones mostradas anteriormente, resulta bastanteinteresante reducir el tamaño de los bitstreams lo máximo posible.

33

3.5.1 Contenido de un bitstreamEl contenido de un bitstream se divide en unidades de 32 bits, de forma que cada una

de estas unidades puede ser un paquete o una palabra de configuración. En el caso de lospaquetes estos pueden ser de dos tipos, llamados «tipo 1» y «tipo 2» a lo largo de estasección. El tipo de paquete lo indica la cabecera, formada por los tres primeros bits (los mássignificativos) del paquete. Por otra parte, una palabra de configuración es una secuencia debits que será interpretada por la lógica interna de la FPGA.

En este TFG se utilizará la interfaz ICAP para acceder a la lógica interna de la FPGA

que interpreta el contenido de los bitstreams [Cab].

Paquete de tipo 1

Este tipo de paquete actúa como una cabecera que especifica qué registro tiene que serleído o escrito, y el número de palabras de 32 bits que se deben leer o escribir. De los 32 bitsdel paquete sólo se utilizan 21, dejando el resto para futuros usos. El código de la cabeceracorrespondiente a este tipo de paquete es 001. Después de la cabecera se indica la operaciónque se realizará sobre el registro en cuestión: 10 (escribir), 01 (leer), 00 (no operation).A continuación se indica la dirección del registro utilizando los últimos 5 bits del camporegister address. Finalmente, los últimos 11 bits indican el número de paquetes de tipo 2 quele siguen al paquete de tipo 1. [Cab]

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16

Type OP Register Address

0 0 1 X X 0 0 0 0 0 0 0 0 0 X X

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Register Address

Reserved Word Count

X X X 0 0 X X X X X X X X X X X

= reserved

Figura 3.13: Estructura de un paquete de tipo 1

Paquete de tipo 2

El paquete de tipo 2, que se suele utilizar para configurar registros internos del ICAP,permiten escribir un bloque de datos más largo que el que permite un paquete de tipo 1,siendo el campo de palabra (de datos) de 27 bits. En este paquete no existe el campo de

34

dirección de registro ya que ésta se especifica en el paquete de tipo 1 que se envía antes, esdecir, un paquete de tipo 2 está asociado a un paquete de tipo 1 previo. Se utilizan 30 de los32 bits que conforman el paquete, dejando 2 bits reservados para futuros usos. El código dela cabecera correspondiente a este tipo de paquete es 010. [Cab]

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16

Type OP Word

0 1 0 0 0 X X X X X X X X X X X

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Word

X X X X X X X X X X X X X X X X

= reserved

Figura 3.14: Estructura de un paquete de tipo 2

Palabras de configuración

Como se ha mencionado anteriormente, una palabra de configuración es una secuenciade 32 bits que será interpretada por la lógica interna de la FPGA. Por ejemplo, la palabrade sincronización (sync word, 0xAA995566) se utiliza para que la lógica de la FPGA puedadelimitar correctamente las unidades de 32 bits que va a recibir. El número de palabras deeste tipo contenidas en un bitstream dependerá del tamaño de la partición reconfigurable yde los recursos que se encuentren dentro de la partición. [Cab]

3.5.2 Estructura de un bitstreamPor lo general, un bitstream de Xilinx se encuentra dividido en cuatro secciones: detección

automática del tamaño del bus, palabra de sincronización, datos de configuración (paquetes),y palabra de desincronización. [Cab]

La primera sección de un bitstream se encarga de la detección automática del tamaño delbus, la cual se lleva a cabo utilizando dos palabras: 0x000000BB, 0x11220044. La lógica dela FPGA solo tiene en cuenta los 8 bits menos significativos de estas dos palabras, de formaque si el ancho de bus es de 8 bits la lógica recibirá el valor 0xBB seguido de 0x11, mientrasque si el ancho de bus es de 32 bits, la lógica recibirá el valor 0xBB seguido de 0x44.

Después, la segunda sección se encarga del envío de la palabra de sincronización (sync

word, 0xAA995566). Esta palabra se envía para que la lógica de la FPGA pueda delimitar co-

35

rrectamente los paquetes que se enviarán después. Todos los datos recibidos con anterioridada esta palabra serán ignorados por la FPGA.

La tercera sección del bitstream incluye todos los datos necesarios para la configuracióndel dispositivo. Tras la palabra de sincronización, todas las palabras de 32 bits del bitstreamse interpretarán como paquetes (tipo 1 o tipo 2) por la FPGA.

Finalmente, la cuarta sección realiza la desincronización con la FPGA. Esta acción se rea-liza enviando dos paquetes especiales: 0x30008001 como paquete de tipo 1 y 0x0000000Dcomo paquete de tipo 2.

3.5.3 Técnicas de compresiónEn un diseño reconfigurable el tamaño de un área reconfigurable dependerá del tamaño de

los módulos que se quieran cargar en ésta. Supongamos que se crea un área reconfigurableen la que se pueden cargar dos módulos: módulo 1 y módulo 2. El módulo 1 es el de mayortamaño, y el módulo 2 tiene un tamaño muy pequeño en comparación con el módulo 1. Dadoque el tamaño del área reconfigurable tiene que dar cabida a los dos módulos, el módulo 2no utilizará gran parte de los recursos de los que dispone el área y, como consecuencia, elbitstream de este módulo contendrá una gran cantidad de ceros.

En estos casos en los que el bitstream contiene una cantidad importante de ceros se puedenaplicar técnicas de compresión para reducir el tamaño del bitstream final.

Herramientas de Xilinx

La herramienta write_bitstream proporcionada por Xilinx para la generación de los bits-treams dispone de dos opciones de compresión:

1. BITSTREAM.GENERAL.COMPRESS. Esta opción quita del bitstream las partescorrespondientes a la lógica de la FPGA que no se utiliza, escribiendo en su lugar ungran número de palabras que contienen solo ceros. [Xil15f]

2. reference_bitfile. Esta opción crea un nuevo bitstream partiendo de otro bitstreamcomo referencia, de forma que en el nuevo solo se almacenan las diferencias que hayarespecto al bitstream de referencia.

Una vez aplicada esta opción, para cargar un bitstream en una partición reconfigurablees necesario que su bitstream de referencia se encuentre cargado en esa partición antesde realizar la reconfiguración parcial de la FPGA. [Xil15f]

Herramienta write_factory_bitstream (ARCO)

La herramienta write_factory_bitstream desarrollada por el grupo ARCO recibe comoentrada un bitstream generado por la herramienta del fabricante (write_bitstream en este

36

# Opcion 1: activar la propiedad BITSTREAM.GENERAL.COMPRESS

set_property BITSTREAM.GENERAL.COMPRESS True [current_design]

# Opcion 2: crea el bitstream output.bit a partir del bitstream reference.bit

write_bitstream -reference_bitfile reference.bit -file output.bit

Listado 3.15: Herramientas de Xilinx para la compresión del bitstream en TCL

caso) y lo comprime aplicando las siguientes técnicas [Cab]:

Dado que son descartadas por la lógica interna de la FPGA, las palabras del bitstreamque se encuentren antes de la detección del ancho de bus y después de la sección dedesincronización se eliminan.

Si se detectan más de tres paquetes llenos de ceros, éstos se sustituyen por dos paque-tes: el paquete de tipo 1 es un nuevo tipo de paquete (0x30036001), y el paquete detipo 2 que le sigue indica el número de paquetes llenos de ceros que se sustituyen.

Mencionar que esta herramienta también organiza el orden de las palabras en el bitstreamcomprimido para facilitar su posterior procesamiento.

3.5.4 zipFactoryEl motor de despliegue zipFactory, desarrollado por el grupo ARCO y utilizado en este

TFG, se encarga de transferir un bitstream comprimido a la lógica de la FPGA. Ofreceun conjunto de servicios para la reconfiguración hardware a través de una interfaz simplifi-cada conectada a un bus AXI (Advanced eXtensible Interface), siendo capaz de desplegar unbitstream que se encuentre almacenado en un dispositivo externo.

AXI es parte de ARM AMBA, un conjunto de especificaciones abiertas para la comuni-cación on-chip (es decir, para las comunicaciones que tienen lugar dentro de un chip). Ac-tualmente la versión más reciente es AXI4, que forma parte de AMBA 4.0. Las ventajas quepresenta AXI4 respecto a otras opciones son [Xil15a]:

Productividad. Gracias a la estandarización de la interfaz AXI los desarrolladores solonecesitan aprender un único protocolo para las IPS.

Flexibilidad. El desarrollador puede elegir el protocolo que mejor se ajuste a su nece-sidad:

• AXI4 está orientado a interfaces mapeadas en memoria y permite ráfagas de datosde hasta 256 ciclos.

• AXI4-Lite es una versión más ligera (utiliza menos lógica) también orientada ainterfaces mapeadas en memoria.

• AXI4-Stream permite ráfagas de datos ilimitadas. Las interfaces que lo utilizanno tienen fase de direcciones antes de realizar la ráfaga de datos, y por lo tantoestas interfaces no son consideradas como mapeadas en memoria.

37

Disponibilidad. Una gran cantidad de proveedores de IPS utilizan este protocolo (in-cluyendo Xilinx), existiendo un gran número de herramientas de terceros para la veri-ficación, medida del rendimiento, etc.

Interfaces [Cab]

En concreto, el componente zipFactory cuenta con tres interfaces de comunicación: unainterfaz FIFO, una interfaz HLS-Stream, y una interfaz AXI-Stream.

Interfaz FIFO. Se encarga de recibir solicitudes de despliegue e informa sobre el esta-do del proceso. Puede utilizarse un adaptador que traduzca las señales de esta interfaza un bus estándar y viceversa.

HLS-Stream. A través de esta interfaz se envía la orden de leer un bitstream a uncontrolador de memoria externo. Conecta con un bus diseñado a medida que cuentacon las siguientes señales: dirección de memoria, tamaño, y palabra de parada.

AXI-Stream. Esta interfaz se utiliza para recibir el bitstream leído por el controladorde memoria, siendo el ancho de bus de 32 bits. Los datos recibidos por esta interfazserán interpretados por zipFactory.

Funcionamiento [Cab]

El funcionamiento de la herramienta consta de una serie de pasos, cada uno de los cuales esrealizado por un módulo de los que aparecen en la Figura 3.15. La parte que se encarga de laadministración de zipFactory coincide con el módulo wrapperAdmin, desarrollado utilizandola herramienta de síntesis de alto nivel Vivado HLS. El resto de módulos están desarrolladosen VHDL.

FIF

O in

terf

ace

HLS Stream

wra

pp

erA

dm

in

AdminPR

zipFactory

DATAbuffer

PR 32bits

HLS

Str

eam addr

sizeendWord

addr

done

ICAPE2

axis2fifobridge

AX

I Stre

am

32bits

pr_done

pr_init

unzip32bits

To memory controller

Fro

m m

em

ory

con

trolle

r

Fro

m/T

o u

ser

or

com

pon

en

t

HLS

Str

eam

Figura 3.15: Diagrama de bloques del componente zipFactory [Cab]

38

Los pasos que sigue la herramienta para llevar a cabo su funcionalidad son:

1. La petición para realizar un nuevo despliegue (enviada desde un componente externo)es recibida a través de la interfaz FIFO. Las peticiones serán gestionadas por el módulowrapperAdmin.

2. Cada petición tiene como único parámetro la dirección de memoria (32 bits) del bits-tream que se quiere leer. El módulo adminPR envía a un controlador de memoria esadirección y una etiqueta que indica en qué palabra parar la lectura (endWord). Concre-tamente, la palabra endWord que se le envía es la palabra de desincronización, puestoque es la última palabra que contiene un bitstream.

Después, el controlador traduce los datos que se le han enviado en una petición AXI

para realizar la lectura. Los datos se envían al controlador a través de la interfaz HLS-

Stream.

3. El controlador de memoria proporciona el bitstream leído a zipFactory a través de lainterfaz AXI-Stream. Este controlador finalizará la lectura cuando encuentre la palabrade desincronización dentro del bitstream (0x30008001, 0x0000000D). Todos los datosrecibidos en zipFactory son almacenados en una interfaz FIFO por el módulo axis2fifo.

4. Una vez que existen datos en el buffer, el módulo adminPR notifica al módulo pr elcomienzo del despliegue. Mientras tanto el componente unzip descomprime los datosrecibidos en el buffer en tiempo de ejecución y envía los datos ya descomprimidos almódulo pr.

5. El módulo pr recibe el bitstream descomprimido y lo pasa al componente ICAP, elcual se encarga de programar la FPGA. El módulo pr comprueba de qué tipo son laspalabras en cada momento, por lo que cuando reciba la palabra de desincronizaciónavisará al módulo adminPR de que la configuración ha finalizado.

6. Por último, el módulo adminPR avisa al usuario de que el despliegue se ha realizadocorrectamente.

Controlador de memoria externo [Cab]

zipFactory utiliza un controlador de memoria externo para leer los bitstreams de memoria.La función de este controlador, diseñado también por el grupo ARCO, es extraer datos de lamemoria DDR y llevarlos a una interfaz AXI-Stream. El controlador permite leer a partir deuna dirección de memoria y ofrece dos métodos de parada: cuando se alcance un número de-terminado de palabras leídas o hasta que se lea una palabra determinada (endWord). Disponede tres interfaces para llevar a cabo su función:

HLS-Stream. Esta interfaz se conecta a la interfaz HLS-Stream de zipFactory. Cuentacon tres señales:

39

• addr (32 bits): dirección de memoria que indica al controlador dónde comenzarla lectura.

• size (32 bits): número de palabras que tienen que ser leídas

• endWord (32 bits): indica en qué palabra se debe detener la lectura.

AXI High Performance Bus. El controlador utiliza esta interfaz para leer de memoriade forma eficiente. Para poder leer a través de esta interfaz, las señales recibidas en lainterfaz HLS-Stream (enviadas por zipFactory) se traducen en varias peticiones AXI.Los datos que se leen de memoria se reciben en ráfagas y son almacenados en un bufferinterno.

AXI-Stream. A través de esta interfaz el controlador de memoria proporciona los datosleídos a otros componentes (en este caso a zipFactory). Se habilita únicamente cuandose llena el buffer interno donde se almacenan los datos recibidos a través de la interfazAXI High Performance Bus.

40

Capítulo 4

Método de trabajo

T ODO el desarrollo de este TFG seguirá el marco de trabajo establecido por las metodo-logías que se exponen en este capítulo, donde se explica con detalle en qué consisten y

cómo se han adaptado para su aplicación en el desarrollo del TFG. Por otra parte también semuestran las herramientas software, lenguajes y medios hardware que se emplean a lo largode este desarrollo.

4.1 Metodologías utilizadas en el proyecto

En la Sección 2.5 se determinaron las metodologías que se van a utilizar en este TFG yse justificó la elección de cada una de ellas. Una de estas metodologías es para el desarrollode todo lo relacionado con la FPGA y la otra es para el desarrollo software (Scrum). Enesta sección se pretende explicar detalladamente en qué consisten ambas metodologías ymostrar cómo se han adaptado a este proyecto.

4.1.1 Metodología de sistemas empotrados basada en FPGA

El desarrollo de todo lo relacionado con la FPGA se llevará a cabo siguiendo una meto-dología de sistemas empotrados basada en FPGA como la descrita en [DSAG10]. Estametodología se basa en una metodología top-down para el nivel de sistema y de procesa-dor (ver Figura 4.1). El diseño comienza mapeando una aplicación sobre una determinadaplataforma para después realizar la síntesis, obteniendo componentes RTL (Register TransferLevel). Una vez que se han obtenido todos los componentes se aplana el diseño en términosde LUT y BRAM para después realizar el place and route.

Adaptación de la metodología para FPGA al proyecto

A lo largo de este proyecto se hará uso de esta metodología cuando sea necesario desarro-llar algo para la FPGA, bien durante el proceso de adaptación de las herramientas desarrolla-das por ARCO o bien dentro de alguna iteración del proceso de desarrollo software (Scrum).Destacar que se utilizarán las herramientas proporcionadas por el fabricante de la FPGA

para aplicar esta metodología.

41

Behavior(Function)

Structure(Netlist)

Physical(Layout)

System

F(...)

F(...)

F(...)

Processorcomponents

RTLcomponents

Logiccomponents

Start

Figura 4.1: Metodología para FPGA [DSAG10]

4.1.2 ScrumScrum es una metodología ágil que tiene como objetivo obtener resultados de forma

rápida, adaptándose a los cambios de las necesidades de los clientes. En Scrum los requi-sitos son capturados en una lista priorizada llamada product backlog, de forma que en todomomento el trabajo se centra en los elementos más prioritarios de esta lista. El product owner

(cuyo rol se verá más adelante) es el último responsable de decidir el contenido de esta listay la prioridad de los elementos. Otra característica del product backlog es que su contenidopuede variar a lo largo del proceso de desarrollo.

Todo el trabajo a realizar se lleva a cabo en varios sprints (iteraciones), cada uno deellos con una duración determinada que varía típicamente entre una semana y un mes. Alinicio de cada sprint el equipo selecciona qué elementos de los más prioritarios del product

backlog se van a desarrollar a lo largo de ese sprint, formando el sprint backlog. En cadaiteración el equipo realizará las tareas necesarias (diseño, implementación, pruebas, etc.)para completar el sprint backlog, obteniendo un producto potencialmente entregable.

Roles en Scrum [SS16] [SR12]

Un equipo Scrum está formado por tres roles: el product owner es la persona que decidequé se va a desarrollar y en qué orden, el Scrum master se encarga de guiar al equipo dedesarrollo a lo largo del proceso de desarrollo, y el equipo de desarrollo es el encargado dededicir cómo llegar a lo que el product owner pide. En el siguiente listado se especifica deforma más concreta cuáles son las responsabilidades y las actividades de cada uno de estosroles:

Product owner. Es el responsable de decidir qué características y funcionalidades sehan de desarrollar y el orden en el que deben ser desarrolladas. Debe mantener una

42

Figura 4.2: Esquema del proceso que define Scrum [Wik]

visión clara de lo que se quiere conseguir y transmitirla al resto de participantes delequipo Scrum. Además, colabora con el Scrum master y con el equipo de desarrollopara asegurarse de que se construye el producto deseado de forma rápida y correcta.Mencionar también que debe estar dispuesto a responder las posibles dudas que lepuedan surgir al resto del equipo Scrum.

Scrum master. Ayuda a todo el equipo a comprender los principios y las actividades deScrum para que puedan llevarse a cabo. Actúa como un facilitador, ya que se encargade resolver los problemas que surgen a lo largo del desarrollo y es responsable deeliminar los impedimientos que puedan afectar a la productividad del equipo. Su papeldentro del equipo es actuar como líder, asegurando que el equipo permanece totalmentefuncional y productivo.

Equipo de desarrollo. Scrum define la existencia de un equipo de desarrollo multi-funcional formado por arquitectos, programadores, diseñadores de GUI, etc. que sonresponsables de diseñar, implementar y probar el producto deseado por el product ow-

ner. Destacar que en Scrum es el propio equipo de desarrollo el que se encarga dedeterminar cuál es la mejor forma de alcanzar los objetivos.

Reuniones en Scrum [SS16] [SR12]

Una vez vistos los roles que define Scrum es importante conocer los tipos de reunionesque se dan a lo largo del proceso de desarrollo. Antes del inicio de cada sprint tiene lugar lareunión de planificación del sprint, en la que el product owner y el equipo de desarrollodeciden cuál es el objetivo del sprint seleccionando los elementos del product backlog que

43

se realizarán. Cada elemento del product backlog se divide en una serie de tareas que seránllevadas a cabo por el equipo de desarrollo.

Durante la ejecución del sprint se realiza de forma diaria una reunión (daily scrum) deunos 15 minutos de duración en la que usualmente el Scrum master realiza tres preguntas acada uno de los miembros del equipo de desarrollo:

¿Qué has hecho desde el último daily scrum?

¿Qué tienes planeado hacer hasta el próximo daily scrum?

¿Existe algún problema que te impida avanzar en la tarea?

Contestando a estas tres preguntas se ofrece una imagen de qué está ocurriendo a todoslos miembros del equipo Scrum. Estas reuniones sirven únicamente para ofrecer una visiónglobal a todo el equipo y para evitar otras reuniones innecesarias. En el caso de que existaalgún problema en el desarrollo se convocará una reunión aparte entre los afectados de eseproblema para intentar resolverlo.

Cuando se finaliza un sprint se realizan dos tipos de reuniones. Una de ellas es la reuniónde revisión del sprint, en la cual puede participar todo el mundo con interés en el proyec-to (equipo Scrum, stakeholders, etc.). En esta reunión el equipo presenta lo desarrollado alo largo del sprint, de forma que todos los presentes adquieran una imagen de lo que es-tá ocurriendo y puedan formular preguntas. Esta revisión del sprint es, en definitiva, unaoportunidad para inspeccionar y adaptar el producto. Por otra parte está la reunión de re-trospectiva, en la cual el product owner, el Scrum master y el equipo de desarrollo discutensobre qué funciona y qué no funciona de las técnicas de Scrum, es decir, es una oportunidadpara inspeccionar y adaptar el proceso.

Beneficios que aporta el uso de Scrum [SR12]

A continuación se muestran los principales beneficios que se pueden obtener aplicando lametodología Scrum a un proyecto:

1. Mejora la interacción con los clientes gracias a la entrega temprana y contínua desoftware, permitiendo al cliente observar la evolución del proyecto y dándole la posi-bilidad de realizar cambios durante el proceso de desarrollo.

2. Obtención de resultados de forma rápida, ya que al final de la primera iteración sedebe tener un producto con las primeras características implementadas y a lo largo delas iteraciones sucesivas se irán añadiendo nuevas características al producto.

3. Mejora de la calidad del producto y de su valor para el cliente, ya que el hecho deque pueda introducir cambios a lo largo del desarrollo le permite obtener un productoque cumple con lo que de verdad necesita y no solo con lo que había especificado alinicio del proyecto.

44

4. Mejor ROI (Return On Investment) para el cliente al poder hacer uso de las versio-nes preliminares del producto que se entregan al final de cada iteración. Estas versionespreliminares no tendrán implementadas todas las funcionalidades del producto final,pero todas aquellas que se hayan implementado hasta el momento de la entrega seránlas más prioritarias del product backlog.

5. Mayor flexibilidad para aceptar cambios en los requisitos a lo largo del proceso dedesarrollo. Estos cambios pueden provenir del cliente o de otros agentes externos, co-mo por ejemplo que se produzca algún cambio en la legislación que afecte al productoen desarrollo.

6. Mejora la gestión de riesgos debido a que los riesgos que ocurren en las primerasiteraciones pueden repetirse en iteraciones posteriores y, en el caso de que se repitan,ya tendrán asociados un plan de contingencia. Además, como el trabajo se divide enpequeñas iteraciones, los riesgos que pueden suceder en una determinada iteraciónquedan limitados a los elementos del product backlog que se van a desarrollar.

7. Mejora del rendimiento del equipo. Al tratarse generalmente de equipos pequeñosse mejora la interacción y la organización entre los miembros del equipo, y además elavanzar de forma incremental permite observar cómo se van consiguiendo los objetivosdel proyecto, lo que incrementa la motivación del equipo. Estos factores mejoran elrendimiento del equipo e incluso pueden ayudar a reducir los costes del desarrollo.

Adaptación de Scrum al proyecto

En primer lugar se muestra el listado de los roles que asumen los implicados en esteTFG:

Product owner. A pesar de que en [SS16] se especifica que este rol lo deberá asumiruna única persona, en el caso de este TFG ambos directores definirán las característicasdel producto y aceptarán o rechazarán los resultados, por lo que este rol lo asumiránlos dos directores del proyecto (Julián Caba y Julio Daniel Dondo).

Scrum master. Este rol lo asume el director del proyecto Julián Caba.

Equipo de desarrollo. En el caso de este TFG, este rol lo asume el alumno (JavierSevilla).

Respecto a las reuniones, éstas se realizarán a lo largo de todo el proyecto cuando seanecesario. La planificación de estas reuniones dependerá de la disponibilidad del alumno yde los directores del proyecto y estarán compuestas de tres partes:

Revisión del sprint. El alumno (equipo de desarrollo) presentará lo que se ha desarro-llado a lo largo del sprint, y el resto del equipo Scrum aceptará o propondrá cambios.

Retrospectiva. Se debatirá sobre el proceso seguido hasta el momento, exponiendo

45

cualquier problema que haya podido surgir y cualquier sugerencia que permita mejorarel trabajo conjunto del equipo Scrum en futuros sprints.

Planificación del sprint siguiente. Finalmente, el product owner y el equipo de desa-rrollo deciden cuál es el objetivo del siguiente sprint.

Como se puede observar, no se realizarán reuniones daily scrum para hacer el trabajo detodas las partes más flexible ya que no se consideran necesarias en este TFG.

Sobre los sprints, mencionar que se realizarán de forma más flexible a lo indicado por[SS16] ya que éstos no tendrán una duración predeterminada. Esto se debe principalmentea dos factores: en primer lugar que la cantidad de trabajo que el equipo de desarrollo po-drá realizar dependerá de la disponibilidad del alumno, y en segundo lugar la formación delequipo de desarrollo, ya que habrá sprint backlogs en los que aparecerán tareas que requeri-rán formación previa por parte del alumno antes de poder llevarlas a cabo. Estos dos factoresdificultan la estimación de la duración de un sprint, pero aún así se intentará siempre que laduración no supere el máximo recomendado (un mes).

Finalmente, mencionar que el equipo de desarrollo subirá el trabajo que vaya realizando aun repositorio Bitbucket de forma contínua para que los product owners y el Scrum master

puedan llevar un seguimiento del estado del proyecto. Además, todo el equipo Scrum haceuso de la herramienta Trello para la gestión y el seguimiento de las tareas del proyecto.

4.2 Herramientas, lenguajes y medios empleados4.2.1 Herramientas software

Para el desarrollo de este TFG se ha hecho uso de las siguientes herramientas software:

Vivado 2015.4 [viv]. Herramienta creada por Xilinx que permite realizar todo el flu-jo de diseño necesario para la creación de diseños sobre FPGA (simulación, síntesis,implementación, programación, etc.). Junto a esta herramienta se proporcionan otrascomo por ejemplo Vivado HLS para la síntesis de alto nivel.

Xilinx SDK 2015.4 [xila]. Kit de desarrollo para la creación de aplicaciones embebi-das que se ejecutarán en el microprocesador de la FPGA.

GCC (GNU Compiler Collection) [gcc]. Compilador principal utilizado a lo largo deldesarrollo de este TFG. Además incluye otras herramientas como gcov, utilizada en esteproyecto para calcular la cobertura de código de las pruebas software que se realizan.

Qt 5 [qt]. Framework multiplataforma orientado principalmente al desarrollo de inter-faces gráficas. Utiliza el estándar C++ y le añade varias extensiones, como por ejem-plo el modelo signals and slots que facilita la implementación del patrón de diseño«Observador», en el cual un objeto sujeto guarda una lista de objetos observadoresde forma que cuando ocurre un cambio en el estado del objeto sujeto éste se notifica alos observadores (ver Figura 4.3).

46

Figura 4.3: Patrón de diseño «Observador».

Qt Creator [qtc]. Entorno de desarrollo destinado a la creación de aplicaciones quehacen uso de las librerías Qt, aunque puede utilizarse para desarrollar cualquier apli-cación en C/C++.

Qt Linguist [qtl]. Herramienta que facilita la traducción a otros idiomas de aplicacio-nes escritas en Qt.

CTemplate [cte]. Librería que proporciona un sistema de plantillas ligero y rápidopara su uso en aplicaciones C++. En este TFG se utiliza para generar los archivos quenecesita la herramienta a partir de plantillas.

Google Test [goo]. Framework utilizado para la creación de las pruebas software.

Valgrind [val]. Herramienta de análisis utilizada para analizar el consumo de memoriade la herramienta en busca de posibles fallos en la gestión de la memoria.

Editor de texto plano para el desarrollo de scripts y descripciones de componenteshardware.

StarUML [sta] para los diagramas software, Evolus Pencil [evo] para el prototipadode interfaces gráficas, e Inkscape [ink] para la creación de esquemas, imágenes, etc.

4.2.2 LenguajesLos lenguajes que se han empleado a lo largo del desarrollo de este proyecto se listan a

continuación:

C++. Lenguaje de programación de propósito general y orientado a objetos diseñadoinicialmente por Bjarne Stroustrup. En este proyecto se ha utilizado para el desarrollode la herramienta principal.

VHDL (VHSIC Hardware Description Language). Lenguaje de descripción de hard-ware utilizado para describir circuitos digitales. En el caso de este TFG se emplea

47

cuando es necesario describir un componente o similar que posteriormente será inter-pretado por las herramientas del fabricante de la FPGA.

TCL (Tool Command Language). Lenguaje script creado por John Ousterhout queen este caso se utiliza para la automatización del flujo de diseño, para la extracción dedatos de las placas y, en general, para su uso dentro del entorno de desarrollo Vivadoya que éste lleva integrada una consola TCL.

Shell script. Lenguaje que se ejecuta en un intérprete de comandos Unix. Utilizado pa-ra la automatización de procesos necesarios para el funcionamiento de la herramienta.

XML (eXtensible Markup Language). Se trata de un lenguaje de marcado que defineun conjunto de normas a seguir para codificar documentos en un formato legible tantopara máquinas como para humanos. En el proyecto se utiliza para guardar el estado dela aplicación y en los archivos que contienen la información de los recursos hardwarede las FPGAS.

4.2.3 Medios hardwareLas FPGAS que se han utilizado finalmente en este proyecto han sido una ZedBoard y

una Kintex-7 KC705 Evaluation Platform. Ésta última reemplaza a la Virtex-7, que deacuerdo al anteproyecto se iba a utilizar en este TFG, debido a que no está disponible en ellaboratorio. A pesar de ésto, a lo largo del desarrollo se ha tenido en cuenta la importancia depoder extender la herramienta para dar soporte a nuevas placas de forma rápida y sencilla.En el Apéndice C se explican las pequeñas modificaciones que hay que realizar para extenderla herramienta a una nueva placa.

48

Capítulo 5

Desarrollo del trabajo

E N este capítulo se explica cómo ha avanzado el trabajo realizado por el alumno, desa-rrollando dicho trabajo de forma progresiva. En primer lugar se muestra la formación

previa que necesita realizar el alumno antes de comenzar con el desarrollo del proyectoy, a continuación, el estudio y adaptación del proyecto proporcionado por el grupo ARCO.Después se muestra con detalle cómo se ha realizado el desarrollo del proyecto iteración aiteración.

5.1 Formación previa

Cuando se comienza este TFG el alumno tiene conocimientos sobre metodologías parael desarrollo de sistemas empotrados y sobre el diseño de sistemas empotrados basados enFPGA, pero antes de comenzar con el desarrollo del proyecto es necesario adquirir unaserie de conocimientos que no se imparten en las asignaturas del Grado.

En primer lugar se requiere conocer de forma teórica en qué consiste la reconfiguraciónparcial de una FPGA, para lo cual se estudia el documento [Xil13c] de Xilinx. En este docu-mento se explica el concepto y el funcionamiento de la reconfiguración parcial, se introduceal lector en el flujo de diseño necesario para aplicar esta técnica, se muestran las considera-ciones de diseño que hay que tener en cuenta a la hora de realizar un diseño dinámicamentereconfigurable, cómo configurar la FPGA utilizando un bitstream parcial, etc.

Una vez que se tienen conceptos teóricos sobre la reconfiguración parcial se pasa al usode la herramienta Vivado. A pesar de que en otras asignaturas del Grado se ha estudiadoel flujo de diseño de herramientas similares (Libero [lib] o Quartus [qua]) la herramienta deXilinx no se ha estudiado de forma práctica. Por esta razón, en primer lugar se realizarán unaserie de tutoriales sobre el uso de la herramienta y el flujo de diseño para un sistema basadoen FPGA paso a paso, sin hacer uso de la reconfiguración parcial. Con estos tutoriales, quecontienen tanto parte práctica como parte teórica, se crean varios sistemas empotrados utili-zando la tecnología Zynq, diseñando sistemas basados en un procesador ARM Cortex-A9 yorientados a una placa ZedBoard. El completar todos los tutoriales permite aprender no soloel flujo de diseño de Vivado, sino también conocer la arquitectura Zynq y su funcionamiento,la creación de interfaces de memoria entre el sistema de procesamiento y la lógica progra-

49

mable, manejo de interrupciones, las distintas formas de configurar la FPGA que existen,etc.

Finalizados estos primeros tutoriales, y habiendo ya estudiado la reconfiguración parcialde forma teórica, el siguiente paso es aprender a realizar un diseño dinámicamente re-configurable utilizando Vivado. Para ello se volverán a seguir una serie de tutoriales quemuestran el flujo de diseño de Vivado para la reconfiguración parcial de forma práctica pasoa paso.

Una vez que se terminan todos los tutoriales, el alumno ya dispone de los conocimientosnecesarios para poder comenzar con el desarrollo del TFG.

5.2 Estudio y adaptación del proyecto proporcionado por ARCO

Como se ha visto a lo largo de este documento en este TFG se utilizan componentes desa-rrollados por el grupo ARCO. Estos componentes se incluyen en un proyecto que se encargade automatizar el flujo de diseño de Vivado para el diseño de aplicaciones dinámicamentereconfigurables. Al alumno se le proporciona este proyecto con la intención de que la he-rramienta a desarrollar (a partir de ahora llamada HDADR) se apoye en él para realizarsu función. En esta sección se estudia el contenido y el funcionamiento de este proyecto,teniendo en cuenta que a lo largo de este TFG se irá adaptando a las necesidades de laherramienta HDADR.

5.2.1 Automatización del flujo de diseño

La automatización del flujo de diseño de Vivado se lleva a cabo a través de scripts escritosen TCL que, como ya se dijo anteriormente, pueden ser interpretados por Vivado ya queéste incorpora un intérprete TCL. Toda la información relativa al diseño reconfigurable seencuentra almacenada en un archivo que después será leído por los scripts para generar eldiseño utilizando las herramientas proporcionadas por el fabricante.

Descripción del diseño (design.tcl)

La descripción del diseño se realiza en el archivo design.tcl, donde se especifican todaslas propiedades y los componentes del diseño que se quiere generar. Antes de ver un ejemplode su contenido es importante mostrar las tres estructuras de datos que se utilizan en estearchivo:

fileGroup (Listado 5.1). Esta estructura de datos permite crear y almacenar gruposde archivos. Al crear un grupo de archivos se devuelve su identificador para despuéspoder acceder a él, y para añadir un archivo es necesario indicar el grupo al que sedesea añadir, la ruta y el nombre. De forma especial, cuando esta estructura se utilicepara definir la parte estática del diseño y el archivo que se añada corresponda con el

50

módulo top 1, se permite indicar ésto poniendo el parámetro «top» a TRUE.

rmGroup. Se utiliza para indicar cuales son las particiones reconfigurables del diseño.Dentro de esta estructura, cada partición tiene asociada un listado con los identificado-res de los módulos reconfigurables que se pueden implementar en ella.

cfgGroup. Estructura que permite especificar las configuraciones del diseño que sequieren generar.

source TCL/fileGroup.tcl

package require fileGroup 1.0

# Creacion de un grupo de archivos

set fileGroupID [fileGroup::create]

# Anadir un archivo al grupo

fileGroup::add $fileGroupID ejemplo texto.txt

# Anadir el archivo que define el modulo TOP (para el grupo de la parte estatica)

fileGroup::add $fileGroupID ejemplo top.vhd "TRUE"

Listado 5.1: Uso de la estructura de datos fileGroup.

El Listado 5.2 muestra un ejemplo del contenido del archivo design.tcl. Dentro deeste archivo se definen:

La FPGA donde se implementará el diseño reconfigurable (líneas 13-15).

Las propiedades del proyecto de Vivado que se creará para poder generar el diseño(líneas 21-24): nombre del proyecto, nombre del diseño, el directorio de IPS del usuarioy el archivo TCL que contiene el diseño de bloques.

Listado de archivos que conforman la parte estática del diseño (líneas 26-27). Paraello se crea un grupo de archivos utilizando la estructura de datos fileGroup, indicandoqué archivo de los añadidos representa el módulo top en el diseño.

Listado de los archivos de restricciones (líneas 29-30).

Las particiones reconfigurables (líneas 36-39), que se definen utilizando la estructurarmGroup. Para cada partición se indica: nombre de la partición, ruta del código en lajerarquía de diseño, nombre de la instancia del netlist donde se encuentra la particióny los recursos hardware que ocupa.

Los módulos reconfigurables (líneas 43-45). Un módulo reconfigurable se definecreando una estructura fileGroup que incluya todos los ficheros que componen el mó-dulo. Para añadir un módulo reconfigurable a una partición simplemente se añade el

1El módulo top es la raíz de la jerarquía de diseño desde el punto de vista de la implementación. Tododiseño debe tener un único módulo top.

51

1 source TCL/fileGroup.tcl

2 package require fileGroup 1.0

34 source TCL/rmGroup.tcl

5 package require rmGroup 1.0

67 source TCL/cfgGroup.tcl

8 package require cfgGroup 1.0

910 ###############################################################

11 ### Define Part, Package, Speedgrade

12 ###############################################################

13 set originDir [file dirname [info script]]

14 set part xc7z020clg484-1

15 set board "em.avnet.com:zed:part0:1.2"

16 ###############################################################

1718 ###############################################################

19 ### VIVADO Project

20 ###############################################################

21 set blockDesign src/design/design_zipFactory_outDPR_2015_4.tcl

22 set designName "ps_system"

23 set prjName tmp

24 set userIPDir ip_repo

2526 set staticFiles [fileGroup::create]

27 fileGroup::add $staticFiles src/top/ top.vhd "TRUE"

2829 set constraintFiles [fileGroup::create]

30 fileGroup::add $constraintFiles src/xdc/ topZedboard.xdc

31 ###############################################################

3233 ###############################################################

34 ### Reconfig Modules

35 ###############################################################

36 set rm_core [rmGroup::create "wrapperTDD"]

37 rmGroup::setSrcLocation $rm_core ""

38 rmGroup::setInstanceName $rm_core "wrapperTDD_1"

39 rmGroup::setHwResources $rm_core [list SLICE_X28Y3:SLICE_X47Y47 DSP48_X2Y2:DSP48_X2Y17

RAMB18_X2Y2:RAMB18_X2Y17 RAMB36_X2Y1:RAMB36_X2Y8]

4041 # Add Modules (Dynamic Parts)

42 ###############################

43 set fixed1Files [fileGroup::create]

44 fileGroup::add $fixed1Files src/dynModules/chrono/ wrapperTDD.vhd

45 rmGroup::addNewModule $rm_core "fixed1" $fixed1Files

46 ###############################################################

4748 ###############################################################

49 ### Configurations

50 ###############################################################

51 set cfg0 [cfgGroup::create "cfg0"]

52 cfgGroup::addNewModule $cfg0 $rm_core "fixed1" "implement"

53 ###############################################################

Listado 5.2: Ejemplo del archivo design.tcl (versión inicial).

52

identificador de esta estructura fileGroup a la estructura rmGroup de la partición encuestión.

Las configuraciones que se desean implementar (líneas 51-52). Para cada configu-ración se crea una estructura cfgGroup y se añade a ésta un módulo por cada particiónreconfigurable que tenga el diseño.

Scripts

El script build.tcl se ejecuta en el entorno de Vivado para generar el diseño descritoen el archivo design.tcl. Como se puede observar en el Listado 5.3 este script se encargade realizar el flujo de diseño llamando a otros scripts. En el siguiente listado se detalla lafunción de cada uno de los scripts a los que se llama desde build.tcl en el orden en que sonllamados:

1. fileSystem.tcl. Se encarga de crear la jerarquía de directorios que se utilizará a lolargo de la generación del proyecto:

Bitstreams/: almacenará todos los bitstremas completos y parciales que se obten-gan como resultado.

Checkpoints/: en este directorio se guardarán todos los checkpoints necesariosdurante el flujo de diseño.

Implementations/: contiene las implementaciones ya rutadas de todas las confi-guraciones.

Reports/: almacenará los informes que se generen a lo largo del flujo.

sdk/: directorio utilizado para almacenar todo lo relativo a Vivado SDK una vezque se ha generado el resultado.

Synth/: almacenará la síntesis de la parte estática y de los módulos reconfigura-bles.

2. vivado_create.tcl. Crea el proyecto de Vivado y establece sus propiedades (board,part, repositorio de IPS del usuario, etc.). Después se crea el diseño de bloques a partirde un diagrama de bloques previamente diseñado y se genera el wrapper del módulotop.

3. rest_create_and_synth.tcl. Carga la parte estática del diseño, realiza la síntesis deésta y copia el checkpoint resultante en el directorio correspondiente.

4. synth_rms.tcl. Se cargan uno a uno todos los módulos reconfigurables del diseño, sesintetizan y se copia el checkpoint resultante en el directorio correspondiente.

5. reconfig_system_create.tcl. Este script se encarga de crear el sistema reconfigurable.En primer lugar, a partir de la síntesis de la parte estática se carga un módulo reconfi-gurable para cada partición, se establecen las celdas que representan a las particiones

53

en el diseño como reconfigurables y se guarda el resultado en un checkpoint (referen-

ce). Después, para cada partición reconfigurable se crea un pblock que ocupa todoslos recursos que tiene que ocupar la partición en cuestión (definidos por el usuario endesign.tcl), y se añade la celda de la partición al pblock. Finalmente se ejecuta elDRC (Design Rule Checking) para comprobar algún posible error y si no ocurre nin-guno se guarda el floorplanning (las propiedades de los pblocks) en un archivo XDC.

6. reference_configuration_create.tcl. En este script se parte con el diseño reference

en memoria ya que en el script anterior no se cierra el diseño. En primer lugar se leenlas restricciones del diseño definidas por el usuario, se optimiza el diseño y se realizael place and route. Después se guardan los checkpoints ya rutados de la configuraciónreference completa y de cada una de las particiones reconfigurables. A continuaciónse elimina el contenido de las particiones reconfigurables (quedando solo la parte es-tática), se fija el rutado y se almacena el resultado en el checkpoint static_route_de-sign.dcp. Este checkpoint de la parte estática con el rutado fijo servirá para asegurarla consistencia de la parte estática independientemente de los módulos que se carguenen las particiones.

7. par_configurations.tcl. Este script se encarga de generar el resto de configuraciones(las definidas por el usuario en el fichero design.tcl). Para cada configuración se sigueel siguiente proceso:

Se carga el checkpoint static_route_design.dcp que contiene la parte estáticacon el rutado fijo.

Se cargan todos los módulos de la configuración en sus particiones correspon-dientes.

Se optimiza el diseño y se realiza el place and route.

Se guarda el checkpoint ya rutado de la configuración completa.

Se guardan los checkpoints ya rutados de cada una de las particiones reconfigu-rables del diseño (que contienen los módulos cargados en éstas).

Se cierra el diseño en memoria.

8. blanking_create.tcl. Se utiliza para la creación de la configuración blanking, en lacual el contenido de las particiones reconfigurables se deja vacío (es decir, no se carganingún módulo en ellas). Para ello se carga en memoria el ckeckpoint static_rou-

te_design.dcp que contiene únicamente la parte estática rutada y en cada particiónreconfigurable se añaden LUTS para asegurar que las salidas de las particiones recon-figurables no se dejan «sueltas». Finalmente se realiza el place and route y se guardala configuración completa en un checkpoint.

9. impl_verify.tcl. Antes de generar los bitstreams es importante comprobar que la im-plementacíon de la parte estática (incluyendo las interfaces de las particiones recon-

54

figurables) es consistente en todas las configuraciones que se han generado. Para elloeste script realiza la comprobación utilizando la herramienta pr_verify.

10. bit_gen.tcl. Finalmente, el último script se encarga de generar los bitstreams comple-tos y parciales para cada configuración implementada, incluyendo las configuracionesreference y blanking.

1 source design.tcl

23 ###############################################################

4 ### Flow

5 ###############################################################

6 set topName [fileGroup::getTopName $staticFiles]

7 if {$topName eq ""} {

8 set topName $designName

9 }

1011 ### Create fileSystem

12 source TCL/fileSystem.tcl

1314 ### Create Vivado prj

15 source TCL/vivado_create.tcl

1617 ### Create and Synth Static Part

18 source TCL/rest_create_and_synth.tcl

1920 ### Synth Reconfig Modules

21 source TCL/synth_rms.tcl

2223 ### Create Reconfig System and Reference design

24 source TCL/reconfig_system_create.tcl

25 source TCL/reference_configuration_create.tcl

2627 ### Create Other Configurations

28 source TCL/par_configurations.tcl

2930 ### Create Blanking Configuration

31 source TCL/blanking_create.tcl

3233 ### Verify Configurations

34 source TCL/impl_verify.tcl

3536 ### Generate Bit Files

37 source TCL/bit_gen.tcl

38 ##############################################################

Listado 5.3: Archivo build.tcl.

Por otra parte cabe la posibilidad de que el diseñador quiera añadir nuevos módulos re-configurables y/o nuevas configuraciones al diseño. En este caso, si se utiliza el archivobuild.tcl se volvería a generar todo el proceso de nuevo cuando esto en realidad no es nece-sario. Para ello se proporciona el script buildPartial.tcl, el cual solo ejecuta las siguientesfases (en este orden):

55

1. fileSystem.tcl. Ejecutado para comprobar que la jerarquía de directorios es correcta.

2. synth_rms.tcl. Utilizado para sintetizar los módulos reconfigurables, incluyendo losnuevos.

3. par_configurations.tcl. Para generar todas las configuraciones, incluyendo las nuevasañadidas.

4. impl_verify.tcl. Ejecutado para comprobar que la parte estática se mantiene consis-tente en todas las configuraciones creadas (incluyendo las nuevas).

5. bit_gen.tcl. Genera todos los bitstreams del diseño.

Este script encargado de generar el diseño de forma parcial presenta un problema: en lafase de síntesis se sintetizan todos los módulos (incluidos los que ya se habían generadoantes), y lo mismo pasa con la creación de configuraciones y la generación de bitstreams.Este flujo de diseño para añadir nuevos módulos y/o configuraciones a un diseño ya creadose mejorará a lo largo del desarrollo del TFG para evitar esto y así ahorrar aún mástiempo.

5.2.2 Componentes incluidos en el proyectoAdemás de los scripts que se encargan de la automatización del diseño, en el proyecto se

proporcionan varios componentes desarrollados por ARCO. En esta sección se muestran loscomponentes que se utilizan en este TFG.

Componentes hardware

zipFactory. Este componente se encarga de gestionar las peticiones de reconfiguraciónque recibe, transfiriendo un bitstream comprimido a la lógica interna de la FPGA. Seexplica detalladamente en la Subsección 3.5.4.

axi_memory_read_driver. Su función es extraer datos de la memoria DDR y llevarlosa una interfaz AXI-Stream (su funcionamiento se explica en la Subsección 3.5.4). Eneste caso, es utilizado por zipFactory para leer un bitstream de memoria.

axi_manager. Este componente se encarga de resetear una partición reconfigurableuna vez que se le ha terminado de añadir un nuevo módulo. Además también permiteobtener el tiempo que tardan los módulos reconfigurables en realizar su función [CC].

dpr_bridge. Componente que actúa como puente entre la parte estática y la parte diná-mica de la FPGA, rutando los mensajes desde un bus AXI (parte estática) a una interfazFIFO (parte dinámica). Esta interfaz FIFO coincide con una interfaz HLS Stream cuyotamaño de datos es de 32 bits. Cuando se detecta un mensaje en el bus AXI dirigido a ladirección de memoria de un módulo reconfigurable, el componente ruta este mensajeal módulo en cuestión [CC].

56

Herramientas

write_factory_bitstreams. Herramienta utilizada para comprimir los bitstreams ge-nerados (ver Subsección 3.5.3). Estos bitstreams después serán interpretados por elcomponente zipFactory.

Diseño dinámicamente reconfigurable

Con el proyecto también se incluye un ejemplo de un diseño dinámicamente reconfigura-ble, cuyo diseño de bloques puede verse en la Figura 5.1. El diseño hace uso de todos loscomponentes hardware mostrados en esta sección y cuenta con una partición reconfigurable(wrapperTDD), la cual se instancia en el módulo top. La interfaz de esta partición puede ver-se en el Listado 5.4. Junto al diseño también se proporcionan varios módulos reconfigurablespara poder implementarlos en esta partición.

component wrapperTDD

port (

din_V_dout : IN STD_LOGIC_VECTOR (31 downto 0);

din_V_empty_n : IN STD_LOGIC;

din_V_read : OUT STD_LOGIC;

dout_V_din : OUT STD_LOGIC_VECTOR (31 downto 0);

dout_V_full_n : IN STD_LOGIC;

dout_V_write : OUT STD_LOGIC;

ap_clk : IN STD_LOGIC;

ap_rst : IN STD_LOGIC);

end component;

Listado 5.4: Partición reconfigurable en el módulo top del diseño inicial.

5.2.3 Adaptación inicial del proyectoA lo largo de este TFG se realizarán algunos cambios sobre el proyecto proporcionado pa-

ra solucionar algunas deficiencias, aportando una mayor eficiencia a la hora de generar unaaplicación dinámicamente reconfigurable e incluyendo la posibilidad de ampliar dicha apli-cación sin necesidad de generar lógica extra. En un principio se realiza la adaptación inicialdel proyecto que se muestra a continuación, donde se adapta el proyecto a la versión 2015.4de Vivado y se modifica el diseño del proyecto añadiendo una partición reconfigurable adi-cional.

Solución de deficiencias

La primera vez que se intenta generar todo el proyecto surgen algunos errores cuando serealiza la síntesis de alto nivel necesaria para generar la IP del componente zipFactory. Estoserrores, que son habituales cuando se cambia de versión en Vivado, ocurren debido a queparte del código de zipFactory no está adaptado a la versión 2015.4 de Vivado HLS (que esla que se utiliza en este TFG).

57

El primer error ocurre porque al realizar la síntesis de alto nivel no se genera el archivowrapperAdmin_forward.vhd que corresponde con la función forward() del archivo wrappe-

rAdmin.cc. La razón de que no se genere es porque en la versión 2015.4 de Vivado HLS

las funciones que contienen poca cantidad de lógica se interpretan automáticamente comofunciones inline 2, por lo que la solución consiste en modificar el archivo directives.tcl

indicando de forma explícita que no se tome como inline la función.

## Functions directives

## Directives of admin function

set_directive_inline -off "forward"

set_directive_inline "newObject"

set_directive_inline "wrapper_newObject"

set_directive_inline "readParameters_newObject"

set_directive_inline "writeReturn_newObject"

Listado 5.5: Modificación realizada al archivo directives.tcl de zipFactory.

El segundo error que aparece también está relacionado con este mismo asunto. En estecaso, el fallo se encuentra en que en directives.tcl se indica de forma explícita que lafunción newObject() se tome como inline y después se requiere el archivo wrapperAdmin_-

newObject.vhd en el script create_axi.tcl. Al establecer la función como inline su contenidose incluye en el archivo wrapperAdmin.vhd, por lo que se elimina de create_axi.tcl la parteque requiere el archivo de la función newObject().

Agregar otra partición reconfigurable al diseño

Antes de comenzar con el desarrollo de la herramienta HDADR se decide añadir una nuevapartición reconfigurable al diseño proporcionado. Para realizar esto es necesario declarar unanueva partición en el módulo top del diseño y además crear un módulo reconfigurable quepueda implementarse en esta partición.

La nueva partición, llamada wrapperTDDp2, tendrá los mismos puertos de entrada que lapartición que ya existe en el diseño y contará únicamente con una salida. Con la creación deesta partición se pretende extender el diseño proporcionado para así poder luego comprobarel funcionamiento de la herramienta HDADR con un diseño que contenga más de una regiónreconfigurable. La funcionalidad de los módulos que se implementen en esta partición noimporta en un principio, ya que lo único que se busca es tener otra partición en la que poderañadir módulos. Por esta razón, la salida de la partición se deja abierta.

La declaración del componente que representa a la partición en el módulo top del diseñopuede verse en el Listado 5.6, y el mapeado de puertos en el Listado 5.7.

2Al establecer una función como inline su contenido se introducirá en aquellas partes donde sea llamada,de forma que deja de ser una función independiente como tal y, en este caso, Vivado HLS no genera el archivocorrespondiente a la función.

58

Siguiendo con lo expuesto anteriormente, la funcionalidad de los módulos que se imple-menten en esta partición no será de importancia para este TFG. Por ello se crea el módu-lo reconfigurable dummy1, cuya única función es la de poner su salida a cero (ver Lista-do 5.8).

component wrapperTDDp2

port (

din_V_dout : IN STD_LOGIC_VECTOR (31 downto 0);

din_V_empty_n : IN STD_LOGIC;

dout_V_full_n : IN STD_LOGIC;

ap_clk : IN STD_LOGIC;

ap_rst : IN STD_LOGIC;

salida : OUT STD_LOGIC);

end component;

Listado 5.6: Declaración de la partición wrapperTDDp2 en el módulo top.

wrapperTDD_2: wrapperTDDp2

port map (

din_V_dout => din_V_dout,

din_V_empty_n => din_V_empty_n,

dout_V_full_n => dout_V_full_n,

ap_clk => FCLK_CLK0,

ap_rst => rst_i,

salida => open);

Listado 5.7: Mapeado de puertos de la partición wrapperTDD en el módulo top.

59

1 -- dummy1 for partition2

2 -- Javier Sevilla

34 library ieee;

5 use ieee.std_logic_1164.all;

67 entity wrapperTDDp2 is

8 port (

9 din_V_dout : IN STD_LOGIC_VECTOR (31 downto 0);

10 din_V_empty_n : IN STD_LOGIC;

11 dout_V_full_n : IN STD_LOGIC;

12 ap_clk : IN STD_LOGIC;

13 ap_rst : IN STD_LOGIC;

14 salida : OUT STD_LOGIC);

15 end;

1617 architecture structural_dummy1 of wrapperTDDp2 is

18 begin

19 dummyPrcss: PROCESS (ap_clk, ap_rst)

20 BEGIN

21 IF ap_clk’EVENT AND ap_clk = ’1’ THEN

22 salida <= ’0’;

23 END IF;

24 END PROCESS dummyPrcss;

25 end structural_dummy1;

Listado 5.8: Módulo reconfigurable dummy1.

60

DD

R

FCLK

_CLK

0

FCLK

_RES

ET0_

N[0

:0]

FIXE

D_I

O

axi_

inte

rcon

nect

_0

AXI I

nter

conn

ect

S00_

AXI

M00

_AXI

ACLK

ARES

ETN

[0:0

]

S00_

ACLK

S00_

ARES

ETN

[0:0

]

M00

_AC

LK

M00

_AR

ESET

N[0

:0]

axi_

man

ager

_0

axi_

man

ager

_v1

S_AX

I

S_AX

I_AC

LK

S_AX

I_AR

ESET

N

flagR

D

flagW

R

rstM

anag

er

axi_

mem

_int

erco

n

AXI I

nter

conn

ect

S00_

AXI

M00

_AXI

M01

_AXI

M02

_AXI

ACLK

ARES

ETN

[0:0

]

S00_

ACLK

S00_

ARES

ETN

[0:0

]

M00

_AC

LK

M00

_AR

ESET

N[0

:0]

M01

_AC

LK

M01

_AR

ESET

N[0

:0]

M02

_AC

LK

M02

_AR

ESET

N[0

:0]

axi_

read

_mem

ory_

driv

er_0

axi_

mem

ory_

read

_driv

er_v

1

s_m

drv

m_a

xi

m_a

xis

M_A

XI_A

CLK

M_A

XIS_

ACLK

M_A

XI_A

RES

ETN

axi_

zipF

acto

ry_0

axi_

zipF

acto

ry_v

1

S_AX

I

m_m

drv

s_ax

is

S_AX

I_AC

LK

S_AX

I_AR

ESET

N

din_

V_do

ut[3

1:0]

din_

V_em

pty_

ndi

n_V_

read

dout

_V_d

in[3

1:0]

dout

_V_f

ull_

ndo

ut_V

_writ

e

dpr_

brid

ge_0

dpr_

brid

ge_v

1

S_AX

I

S_AX

I_AC

LK

S_AX

I_AR

ESET

N

flagR

D

flagW

R

din_

V_do

ut[3

1:0]

din_

V_em

pty_

ndi

n_V_

read

dout

_V_d

in[3

1:0]

dout

_V_f

ull_

ndo

ut_V

_writ

eproc

essi

ng_s

yste

m7_

0

ZYN

Q7

Proc

essi

ng S

yste

m

DD

R

FIXE

D_I

OS_

AXI_

HP0

_FIF

O_C

TRL

M_A

XI_G

P0S_

AXI_

HP0

M_A

XI_G

P0_A

CLK

S_AX

I_H

P0_A

CLK

FCLK

_CLK

0

FCLK

_RES

ET0_

N

rst_

proc

essi

ng_s

yste

m7_

0_10

0M

Proc

esso

r Sys

tem

Res

et

slow

est_

sync

_clk

ext_

rese

t_in

aux_

rese

t_in

mb_

debu

g_sy

s_rs

t

dcm

_loc

ked

mb_

rese

t

bus_

stru

ct_r

eset

[0:0

]

perip

hera

l_re

set[0

:0]

inte

rcon

nect

_are

setn

[0:0

]

perip

hera

l_ar

eset

n[0:

0]

util_

vect

or_l

ogic

_0

Util

ity V

ecto

r Log

ic

Op1

[0:0

]

Op2

[0:0

]R

es[0

:0]

util_

vect

or_l

ogic

_1

Util

ity V

ecto

r Log

ic

Op1

[0:0

]R

es[0

:0]

Figura 5.1: Diagrama de bloques del diseño proporcionado.

61

5.3 Desarrollo de Scrum

En esta sección se muestra cómo ha transcurrido el desarrollo software de la herramientaHDADR siguiendo la metodología Scrum, detallando todo lo realizado en cada una de lascinco iteraciones que se llevan a cabo.

Antes de comenzar con el desarrollo software se establece el product backlog de la he-rramienta (ver Cuadro 5.1), cuyos ítems describen las características que debe cumplir laherramienta y están de acuerdo a los objetivos que se pretenden alcanzar en este TFG. A lolargo del desarrollo se le irán añadiendo los ítems propuestos por el product owner. Tambiénse le pueden añadir ítems propuestos por el equipo de desarrollo siempre y cuando éstos seanaprobados por el product owner.

ID Descripción Prioridad001 Generación del archivo design.tcl a partir de la especifica-

ción de un diseño reconfigurable (parte estática, particiones,módulos, etc.) introducida por el usuario.

Alta

002 Permitir al usuario realizar una generación parcial del diseñodesde la herramienta.

Alta

003 Permitir al usuario la especificación y la generación de undiseño rconfigurable a través de una GUI ligera. Establecerun nuevo flujo de diseño para aplicaciones dinámicamen-te reconfigurables, de forma que la GUI a desarrollar guíe alusuario a lo largo de este nuevo flujo. Una vez que el usuarioha terminado de introducir todos los datos del diseño recon-figurable, realizar el proceso de generación del diseño hastala obtención de los bitstreams.

Alta

004 Ofrecer al usuario la posibilidad de seleccionar gráficamen-te las áreas reconfigurables de la FPGA (floorplanning). Larepresentación gráfica deberá mostrar la disposición de losrecursos en la FPGA e información sobre estos recursos.

Alta

005 Permitir al usuario gestionar la programación de la FPGAdesde la herramienta HDADR utilizando un bitstream de undiseño generado previamente.

Alta

006 Implementar la posibilidad de exportar el hardware de undiseño ya generado a Vivado SDK.

Alta

007 Permitir que el usuario pueda desarrollar una aplicación pro-pia que se encargue de la gestión de la reconfiguración de laFPGA.

Alta

008 Proporcionar al diseñador la opción de generar una imagende arranque para una tarjeta SD (Zynq Boot Image) a partirde un diseño generado.

Media

Cuadro 5.1: Product backlog inicial de la herramienta.

62

5.3.1 Iteración 1La primera iteración del proceso de desarrollo software comienza con una reunión de

planificación en la que se encuentran representados todos los roles del equipo Scrum paradecidir cuál es el objetivo de esta iteración, escogiendo los ítems del product backlog que sehan de llevar a cabo en esta iteración. Después, el equipo de desarrollo establece las tareas arealizar para cada uno de estos ítems. En el Cuadro 5.2 se muestra el sprint backlog de estaiteración, incluyendo las tareas a realizar para cada ítem.

ID Descripción breve Tareas

001 Generación de design.tcl.Análisis de requisitos y diseño del software.Elegir la tecnología de implementación e im-plementar el software.

002Permitir la generaciónparcial del diseño.

Estudio e implementación del cambio.Pruebas de la iteración.

Cuadro 5.2: Sprint backlog de la iteración 1.

Generación de design.tcl (ID 001)

En la herramienta HDADR el diseñador introducirá todos los datos del diseño a través dela interfaz gráfica, por lo que será necesario pasar todos estos datos al archivo design.tcl

para que después los scripts de automatización puedan generar el diseño. Por lo tanto, eldesarrollo de este TFG comienza implementando la generación automática de este ficheroa partir de los datos proporcionados por el diseñador.

A. Análisis de requisitos y diseño del software.

Lo primero que se realiza es un análisis de los requisitos que tiene que cumplir el softwarea desarrollar en esta iteración, identificando los siguientes requisitos:

1. Se deberá hacer uso de la orientación a objetos, organizando el proyecto en tres capas:presentación, dominio y persistencia.

En la capa de presentación se incluirán todas aquellas clases relacionadas con laGUI u otro tipo de interacción con el usuario.

La capa de dominio estará formda por todas aquellas clases que pertenezcan almodelo conceptual (modelo de dominio).

Las clases que pertenezcan a la capa de persistencia serán todas aquellas que seencarguen del almacenamiento y la lectura de la información.

2. El diseñador introducirá todos los datos necesarios para generar el fichero design.tcl.El software no comprobará de momento que los datos introducidos sean correctos,siendo ésto responsabilidad del diseñador.

3. El diseñador podrá definir cuantas particiones, módulos y configuraciones desee, te-niendo en cuenta que un módulo reconfigurable solo puede estar asociado a una única

63

partición.

4. Dado que aún no se ha desarrollado la GUI de la herramienta, se debe crear algunaforma temporal con la que el usuario pueda definir un diseño reconfigurable.

Respecto a la tarea de diseño, en la Figura 5.2 se puede encontrar el diagrama de cla-ses realizado a partir de los requisitos de esta iteración. En este diagrama se observa cómola clase «Design» cuenta con todos los datos necesarios para la generación del archivo de-

sign.tcl.

B. Elegir la tecnología de implementación e implementar el software.

Una vez realizado el análisis y el diseño del software que hay que realizar en este ele-mento del sprint backlog, la siguiente tarea es elegir la tecnología de implementación eimplementar el software. En primer lugar se ha de escoger el lenguaje en el que se imple-mentará la herramienta HDADR, la cual se ejecutará inicialmente en sistemas GNU/Linux conla posibilidad de ser portable a otras plataformas (Windows en concreto). Partiendo de losconocimientos que tiene el alumno, se plantean tres opciones:

Java. Las aplicaciones escritas en este lenguaje se compilan en un bytecode que seejecuta en cualquier JVM (Java Virtual Machine) sin necesidad de volver a compilar elcódigo. Esto, que por una parte es una gran ventaja para la portabilidad de la aplicación,en este caso puede ser un incoveniente ya que se busca que la herramienta sea rápiday tenga un bajo consumo de memoria.

Python. Lenguaje que destaca principalmente por su código fácil de leer y por la rapi-dez con la que se pueden desarrollar aplicaciones. Se trata de un lenguaje interpretado,lo que hace en un principio que la ejecución sea más lenta en comparación con unlenguaje compilado.

C++. A pesar de que en un principio su uso pueda parecer más complejo que el de losdos lenguajes anteriores, este lenguaje compilado destaca por su rendimiento, eficien-cia y flexibilidad.

La fluidez y sobre todo el consumo de memoria son dos aspectos importantes a tener encuenta en este TFG. Por estos dos motivos se decide emplear el lenguaje de programa-ción C++ para el desarrollo de la herramienta HDADR. También es necesario decidir quétecnología se utilizará para para generar un archivo a partir de una plantilla. En C++ existenvarios sistemas de plantillas a tener en cuenta: Amber, dbPager, Obyx, CTemplate, etc. Te-niendo en cuenta la facilidad de uso y la rapidez con la que se generan los archivos se decidefinalmente utilizar la librería CTemplate [cte].

Decididas las tecnologías de implementación que se van a utilizar se realiza la implemen-tación del diseño mostrado previamente. A la hora de implementar la capa de persistenciaes necesario disponer de la plantilla que permitirá crear el archivo design.tcl. El funciona-

64

Persistencia

Dominio

ReconfigPartition

-partitionID-name-instanceName-srcDir-hwResources

+ReconfigPartition()+addHwResource()+getPartition()+getName()+getInstanceName()+getSrcDir()+getHwResources()+setPartitionID()+setName()+setInstanceName()+setSrcDir()

ReconfigModule

-moduleID-name-files-partitionID

+ReconfigModule()+addFile()+getModuleID()+getName()+getPartition()+getFiles()+setModuleID()+setName()+setPartition()

Configuration

-configID-name-modulesIDs

+Configuration()+addModule()+getConfigID()+getName()+getModules()+setConfigID()+setName()

GenDesignTCL

+generate()-addStaticFiles()-addConstraintFiles()-addPartitions()-addModules()-addConfigurations()

Design

-part-board-projectName-designName-ipDir-blockDesignTCL-staticFiles-constraintFiles

+Design()+setPart()+setBoard()+setProjectName()+setDesignName()+setIPDir()+setBlockDesignTCL()+addStaticFile()+addConstraintFile()+addPartition()+addModule()+addConfiguration()+getPart()+getBoard()+getProjectName()+getDesignName()+getIPDir()+getBlockDesignTCL()+getStaticFiles()+getConstraintFiles()+getPartitions()+getModules()+getConfigurations()+generateTCL()

-partitions

0..*

-modules

0..*

-configurations

0..*

Presentación

Figura 5.2: Diagrama de clases de la iteración 1.

miento de CTemplate es bastante simple: por una parte se encuentra la plantilla en la quese especifica el formato del archivo a generar, y por otra parte los diccionarios creados enel programa que se encargan de mapear las marcas que se encuentran en la plantilla con

65

los datos que se formatearán. En el Listado 5.9 se puede observar la parte de la plantillacorrespondiente con la definición de las particiones y en el Listado 5.10 el código C++ quese encarga de formatear los datos de las particiones atendiendo al formato establecido en laplantilla.

###############################################################

### Reconfig Partitions

###############################################################

{{#RECONFIG_PARTITION}}# Create reconfig partition (RP)

set {{PARTITION_ID}} [rmGroup::create "{{PARTITION_NAME}}"]

# Configure RP

rmGroup::setSrcLocation ${{PARTITION_ID}} "{{PARTITION_SRC_DIR}}"

rmGroup::setInstanceName ${{PARTITION_ID}} "{{PARTITION_INSTANCE_NAME}}"

rmGroup::setHwResources ${{PARTITION_ID}} [list {{#PARTITION_HW_RESOURCE}}{{HW_RESOURCE}} {{/

PARTITION_HW_RESOURCE}}]

{{/RECONFIG_PARTITION}}

###############################################################

Listado 5.9: Formato de la definición de las particiones en la plantilla designTemplate.tpl.

void GenDesignTCL::addPartitionsToDict(ctemplate::TemplateDictionary &dict, Design &des) {

ctemplate::TemplateDictionary *subdict, *subsubdict;

vector<ReconfigPartition> partitions;

partitions = des.getPartitions();

for (size_t i = 0; i < partitions.size(); i++) {

vector<string> hwRes = partitions[i].getHwResources();

subdict = dict.AddSectionDictionary("RECONFIG_PARTITION");

subdict->SetValue("PARTITION_ID", partitions[i].getPartitionID());

subdict->SetValue("PARTITION_NAME", partitions[i].getName());

subdict->SetValue("PARTITION_SRC_DIR", partitions[i].getSrcDir());

subdict->SetValue("PARTITION_INSTANCE_NAME", partitions[i].getInstanceName());

for (size_t j = 0; j < hwRes.size(); j++) {

subsubdict = subdict->AddSectionDictionary("PARTITION_HW_RESOURCE");

subsubdict->SetValue("HW_RESOURCE", hwRes[j]);

}

}

}

Listado 5.10: Extracto de la clase GenDesignTCL donde se da formato a los datos de lasparticiones.

También se implementa de forma temporal un archivo C++ (main.cpp) donde se crea undiseño completo. Este archivo puede ser modificado por el usuario para definir un diseño

66

reconfigurable y, además, se utilizará para realizar las pruebas del software desarrollado a lolargo de esta iteración.

Permitir la generación parcial del diseño (ID 002)

Los scripts proporcionados incluyen la posibilidad de generar un diseño parcialmente. Elusuario puede hacer uso de esta opción cuando ya generó un diseño por completo previamen-te y solo quiere añadir nuevos módulos y/o particiones. Como se comentó anteriormente enla Sección 5.2, el problema que presenta esta solución es que todos los módulos se volveríana sintetizar, incluyendo los que ya se sintetizaron en su momento. Lo mismo ocurre con lasconfiguraciones y con los bitstreams. El objetivo de este ítem del sprint backlog es modificarlos scripts para evitar que esto ocurra y así ahorrar tiempo en la generación parcial de undiseño.

A. Estudio e implementación del cambio.

A continuación se listan los scripts que son llamados por el script buildPartial.tcl, mos-trando las modificaciones realizadas:

1. fileSystem.tcl. No es necesario aplicar ninguna modificación.

2. synth_rms.tcl. Para cada módulo reconfigurable se comprobará si existe ya el check-point de su síntesis o no. En el caso de que exista no se ejecutará el proceso de síntesis.Los cambios realizados se guardan en el script synth_rms_partial.tcl.

3. par_configurations.tcl. Para cada configuración se comprueba si existe ya el check-point que contiene el place and route de ésta, evitando así generar de nuevo las con-figuraciones que ya fueron generadas. Los cambios realizados se guardan en el scriptpar_configurations_partial.tcl.

4. impl_verify.tcl. No es necesario aplicar ninguna modificación debido a que es nece-sario comprobar la consistencia de la parte estática entre todas las configuraciones deldiseño (incluyendo las nuevas).

5. bit_gen.tcl. Antes de generar el bitstream de cada configuración se comprueba si yaexiste el bitstream, de forma que se puede evitar generarlo de nuevo (con el ahorrode tiempo que eso implica). Los cambios realizados se guardan en el script bit_gen_-partial.tcl.

B. Pruebas y resultados de la iteración.

En primer lugar se elaboran varias pruebas unitarias utilizando el framework GoogleTest para comprobar el funcionamiento de las clases desarrolladas en las capas de dominioy persistencia. Para cada clase se elabora un test unitario y, una vez que se ejecuta, se com-prueba la cobertura del código alcanzada mediante la herramienta gcov. El resultado dela ejecución de estos test y la cobertura se muestran en el Cuadro 5.3.

67

Prueba Descripción de las pruebas Clases afectadas Coberturadel código

ReconfigPartition Comprobado el funcionamiento detodos los constructores, incluyendoel copy constructor.Comprobado el acceso y modifica-ción de todos los atributos.

ReconfigPartition 100 %

ReconfigModule Comprobado el funcionamiento detodos los constructores, incluyendoel copy constructor.Comprobado el acceso y modifica-ción de todos los atributos, así comoel funcionamiento del método quepermite añadir los ficheros que con-forman el módulo.

ReconfigModule 100 %

Configuration Comprobado el funcionamiento detodos los constructores, incluyendoel copy constructor.Comprobado el acceso y modifica-ción de los atributos y el método quepermite añadir los módulos que seimplementan en la configuración.

Configuration 100 %

DesignComprobados todos losconstructores y el funcionamiento delos métodos que permiten acceder alos atributos y modificarlos.Comprobado el funcionamiento deañadir nuevas particiones, módulosy configuraciones. Por último, secomprueba también la generacióndel archivo design.tcl a partir de undiseño (en este caso se veinvolucrada la claseGenDesignTCL).

Design 85.05 %GenDesignTCL 100 %

Cuadro 5.3: Resultado de las pruebas unitarias de la iteración 1.

68

Una vez realizadas las pruebas unitarias se ejecuta la herramienta utilizando como en-trada varias definiciones de diseños reconfigurables para generar los archivos TCL co-rrespondiente. Tras analizar estos ficheros se comprueba que se generan con el formatocorrecto, superando esta prueba con éxito.

Finalmente se analizan los posibles memory leaks 3 que pueden ocurrir en la ejecuciónde la aplicación. Para ello se analiza la gestión de la herramienta utilizando Valgrind [val],buscando los posibles memory leaks causados por un error en la programación por parte delalumno, obteniendo los siguientes resultados:

$ valgrind ./bin/hdadr_tfg

==12342== Memcheck, a memory error detector

==12342== Copyright (C) 2002-2013, and GNU GPL’d, by Julian Seward et al.

==12342== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info

==12342== Command: ./bin/hdadr_tfg

==12342==

==12342== HEAP SUMMARY:

==12342== in use at exit: 15,605 bytes in 229 blocks

==12342== total heap usage: 1,496 allocs, 1,267 frees, 252,504 bytes allocated

==12342==

==12342== LEAK SUMMARY:

==12342== definitely lost: 0 bytes in 0 blocks

==12342== indirectly lost: 0 bytes in 0 blocks

==12342== possibly lost: 52 bytes in 1 blocks

==12342== still reachable: 15,553 bytes in 228 blocks

==12342== suppressed: 0 bytes in 0 blocks

==12342== Rerun with --leak-check=full to see details of leaked memory

==12342==

==12342== For counts of detected and suppressed errors, rerun with: -v

==12342== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Se detecta un memory leak de un bloque de 52 bytes que ocurre al llamar método Ex-

pandTemplate desde la herramienta pero que no es causado por el alumno, ya que esta fugaes causada por la implementación interna de CTemplate y del uso que esta implementaciónhace de las librerías estándar del sistema. Por otra parte se observan 228 bloques de memo-ria de los que aún se tiene algún puntero que permite acceder a ellos pero no se han liberadoaún. Por lo general, este tipo de memory leaks no se consideran perjudiciales para el ren-dimiento de la aplicación y del sistema. De hecho existen librerías estándar como GTK+ quereservan al inicio una gran cantidad de memoria que no debe ser liberada hasta que no finaliceel proceso y, ante esto, en ocasiones se deja que el kernel libere automáticamente la memoria

3Un memory leak (o fuga de memoria) es un error de software que ocurre cuando se reserva un bloque dememoria y no se libera antes de que el software finalice su ejecución.

69

en lugar de liberarla de forma explícita por motivos de sencillez y rapidez [Mor10].

Aun así, mencionar que ninguno de los memory leaks que se producen son provocadosexplícitamente por el código desarrollado en esta iteración, por lo que esta prueba se datambién por superada.

Reunión de revisión del sprint y retrospectiva

Una vez finalizada la iteración se reune el equipo Scrum para valorar los resultados. Elproducto entregable consiste en la primera versión de la herramienta funcional. Esta versiónpermite al usuario gestionar todos los elementos necesarios para el desarrollo de una aplica-ción dinámicamente reconfigurable (parte estática, particiones, módulos y configuraciones).El usuario puede definir estos elementos en el archivo main.cpp proporcionado y, a partir deestos datos, generar el archivo design.tcl que permite al proyecto desarrollado por ARCO

generar los bitstreams del diseño.

En la reunión se aprueba todo el trabajo realizado hasta el momento y se decide continuarcon el proyecto sin añadir ningún elemento más al product backlog.

5.3.2 Iteración 2En la misma reunión donde se analizaron los resultados de la anterior iteración se selec-

cionan los elementos del product backlog que marcan el objetivo de esta iteración. Después,el equipo de desarrollo divide cada uno de estos elementos en tareas, formando el sprint

backlog final que se muestra en el Cuadro 5.4.


003Desarrollo de la GUI de laherramienta y establecer unnuevo flujo de diseño.

Establecer el nuevo flujo de diseño de la he-rramienta.Prototipado de la GUI. Actualización del dise-ño del software.Elegir la tecnología de implementación e im-plementar la GUI.Conectar la GUI con los scripts.

004 Floorplanning.

Extraer los datos de los recursos hardware dela FPGA.Prototipado de la GUI.Implementación.Pruebas de la iteración.


Desarrollo de la GUI de la herramienta y establecer un nuevo flujo de diseño (ID 003)

Lo primero a realizar en esta iteración es establecer el flujo de diseño de la herramientaHDADR. Una vez establecido se realizará el prototipado de la GUI de la herramienta y se

70

decidirá qué tecnología emplear para la implementación de esta interfaz gráfica. Finalmentese realizará la conexión entre la interfaz gráfica de la herramienta y los scripts, de forma queel diseñador pueda generar el archivo design.tcl y ejecutar la generación del diseño desdela herramienta HDADR.

A. Establecer el nuevo flujo de diseño de la herramienta.

3. Particiones reconfigurables

2. Parte estática

1. Información general

4. Módulos reconfigurables

5. Configuraciones

GENERAR EL DISEÑO

Añadir nuevos módulos yconfiguraciones al diseño generado(Generación parcial)

Figura 5.3: Flujo de diseño de la herramienta HDADR.

Teniendo en cuenta los datos que se han de proporcionar para generar el archivo de-

sign.tcl, y con el objetivo de facilitar a los diseñadores la creación de aplicaciones dinámi-camente reconfigurables, se define el nuevo flujo de diseño que se utilizará en la herramientaHDADR. A continuación se muestran ordenados los pasos de este nuevo flujo de diseño:

1. Información general. En este paso el diseñador indicará los datos de la FPGA que seva a utilizar y los datos del proyecto de Vivado que se creará, incluyendo el directoriode IPS del usuario y el archivo TCL que contiene el block design del diseño.

2. Parte estática. Aquí el diseñador indica qué archivos definen la parte estática del di-seño, seleccionando entre todos ellos cuál es el que representa al módulo top. Tambiénse añaden todos los archivos que contienen las restricciones que se han de aplicar aldiseño.

3. Particiones reconfigurables. Una vez que se define la parte estática del diseño seintroducen los datos de cada una de las particiones del diseño: identificador, nombre,recursos hardware que ocupa, etc.

71

4. Módulos reconfigurables. El diseñador podrá añadir los módulos que desee al diseñoindicando los archivos que lo componen y otros datos. Para cada módulo añadido eldiseñador debe indicar a qué partición reconfigurable está asociado.

5. Configuraciones. El último paso del flujo de diseño es indicar qué configuraciones sedesean generar. A la hora de crear una configuración, el diseñador indica qué móduloquiere cargar en cada una de las particiones del diseño reconfigurable.

Una vez generado el diseño, el diseñador podrá añadir nuevos módulos reconfigurablesy/o nuevas configuraciones sin necesidad de volver a comenzar desde el principio, lo quesupondrá un ahorro de tiempo bastante importante. Lógicamente, una vez que se genera undiseño la parte estática y los datos de las particiones reconfigurables no podrán cambiarse,ya que ésto implicaría tener que volver a generar la síntesis y la implementación de la parteestática y, por tanto, generar un nuevo diseño desde el principio.

B. Prototipado de la GUI. Actualización del diseño del software.

En esta tarea se realizan los prototipos para la interfaz gráfica de la herramienta HDADR.Una vez realizados, se actualiza el diseño software de la anterior iteración. La GUI de cadapaso del flujo de diseño será implementada de forma separada, es decir, existirá una clase quecontenga la GUI encargada de recibir la información general del diseño, otra clase con la GUI

encargada de recibir los datos de la parte estática, etc. Todas estas interfaces «parciales» seañadirán a la GUI principal de la herramienta HDADR (clase MainWindow). Los prototiposrealizados en esta tarea se encuentran en el Apéndice A.

Una vez que se han realizado los prototipos se analizan las clases que son necesarias parala representación de éstos, obteniendo como resultado el diagrama de clases que se muestraen la Figura 5.4.

72

Persistencia

Dominio

GenDesignTCL

-partitions

0..*-modules 0..*

-configurations

0..*

PresentaciónMainWindow

PartitionsGUI

-addPartitionToDesign()

GeneralInfoGUI

+addToDesign()

StaticPartGUI

+addToDesign()

ModulesGUI

-addModuleToDesign()

Design

ReconfigModuleReconfigPartitionConfiguration

ConfigurationsGUI

-addConfigToDesign()

-mainDesign1


C. Elegir la tecnología de implementación e implementar la GUI.

Actualmente, las principales tecnologías que existen para el desarrollo de interfaces grá-ficas en C++ para un sistema GNU/Linux son dos: gtkmm [gtk] y Qt [qt]. En primer lugar,gtkmm es una interfaz C++ para la librería gráfica GTK+ escrita en C. Destacar que GTK+ sepublica bajo licencia LGPL y es multiplataforma, siendo compatible con GNU/Linux, Win-dows y MacOS entre otros.

Por otra parte, Qt es un framework orientado principalmente al desarrollo de GUIS escritodesde cero en C++, al que le añaden varias extensiones como por ejemplo el modelo de sig-

nals and slots (patrón «Observador»). También permite al programador abstraerse en granparte de la gestión de memoria ya que parte de esta gestión se realiza de forma automáti-ca. Además de las librerías gráficas, Qt contiene una gran cantidad de módulos para otrasfunciones: Qt XML, Qt Network, Qt SQL, etc. Mencionar que este framework se publica ba-jo licencia comercial y bajo licencia LGPL, de forma que el programador puede escoger laque mejor le conviene. Al igual que GTK+ es multiplaforma, siendo compatible con los tres

73

principales sistemas de escritorio.

Teniendo en cuenta la gestión de memoria y la facilidad de uso, se escoge el frame-work Qt bajo licencia LGPL para la implementación de la interfaz gráfica de la herramientaHDADR.

Decidida la tecnología de implementación se procede a implementar la interfaz gráficacorrespondiente a esta tarea. Todo el código que se desarrolle se subirá al repositorio enBitbucket.

Figura 5.5: GUI de la herramienta HDADR en la iteración 2.

D. Conectar la GUI con los scripts.

Una vez que el diseñador termina de introducir todos los datos del flujo de diseño, alpulsar el botón «Generar diseño» se genera el archivo design.tcl y se crea un proceso queejecuta los scripts de automatización del flujo. En caso de que se realice una generaciónparcial, se vuelve a generar el archivo design.tcl incluyendo toda la información del diseño(los componentes que ya se generaron previamente y los nuevos que se han añadido), ya queserán los scripts que se crearon para la generación parcial los que se encarguen de comprobarqué componentes se han generado ya y cuales no. El código que se ejecuta al pulsar el botón«Generar diseño» se encuentra en el Listado 5.11.

74

void MainWindow::generate() {

std::string res, outFileName;

outFileName = projectDirLineEdit->text().toStdString() + "design.tcl";

generateButton->setEnabled(false);

//Show progress bar

makeProjectProgressBar->setMinimum(0);

makeProjectProgressBar->setMaximum(0);

makeProjectProgressBar->setFixedHeight(15);

makeProjectProgressBar->setVisible(true);

//Generate design.tcl

makeProjectLabel->setText("Generando design.tcl...");

makeProjectLabel->setVisible(true);

std::ofstream file(outFileName.c_str());

res = GenDesignTCL::generate(TEMPLATE_FILE, mainDesign);

file << res;

file.close();

//Launch make project process

makeProjectLabel->setText("Generando...");

makeProcess = new QProcess();

makeProcess->setWorkingDirectory(projectDirLineEdit->text());

connect(makeProcess, SIGNAL(finished(int,QProcess::ExitStatus)), this, SLOT(makeProjectFinished(

int,QProcess::ExitStatus)));

if (partialDesign) {

makeProcess->start("make buildPartial");

}

else {

makeProcess->start("make build");

}

}

Listado 5.11: Código que se ejecuta al pulsar el botón «Generar diseño» (iteración 2).

Floorplanning (ID 004)

En la interfaz gráfica principal desarrollada el diseñador tiene que introducir los recursoshardware que ocupa una partición en forma de texto. Por tanto, el siguiente paso del trabajoconsiste en ofrecer al diseñador la posibilidad de seleccionar de forma gráfica el área de laFPGA que ocupa una partición reconfigurable. Para ello se proporcionará una representacióngráfica de la FPGA donde se muestren sus recursos hardware e información sobre cada unode éstos (nombre, tipo de recurso y zona de reloj), permitiendo al diseñador desplazarse porestos recursos y seleccionar los que conformarán una partición reconfigurable.

75

A. Extraer los datos de los recursos hardware de la FPGA.

Para poder representar los recursos de una FPGA y los datos de cada uno de estos recursoses necesario extraer toda esta información a través del intérprete TCL que incluye Vivado, yaque ésta es la única herramienta que puede proporcionar esta información. En este intérpretede Vivado cada recurso hardware se representa con un objeto SITE, del cual nos interesanlas siguientes propiedades:

NAME: nombre del recurso.

SITE_TYPE: tipo hardware del recurso (SLICEL, SLICEM, RAMB18E1, RAMFIFO36E1,etc.).

CLOCK_REGION: zona de reloj de la FPGA a la que pertecene el recurso.

RPM_X, RPM_Y: indica la posición del recurso hardware en la FPGA.

Estudiando el documento [Xil15c] se encuentran los siguientes comandos que permiti-rán extraer todos la información necesaria a través de un script TCL:

get_sites: devuelve una lista con todos los sites cuyo nombre encaje con un patrónque se le pasa como argumento. En caso de que no se le pase ningún patrón, devuelveuna lista con todos los sites que tiene la FPGA, que es lo que se busca en esta ocasión.

get_property: sirve para obtener el valor actual de una propiedad de un determinadoobjeto. Se utilizará para obtener las propiedades de los sites que se encuentran en ellistado devuelto por get_sites.

Hay que tener en cuenta que Vivado cargará los datos de la FPGA cuando se haya abiertoun proyecto y exista un diseño sintetizado o implementado en memoria. Por esta razónse crea un proyecto en memoria y se sintetiza un componente que no hace nada (ver Lista-do 5.12) antes de comenzar con la extracción de los datos.

Mencionar además que los datos extraídos se almacenarán en un archivo XML quedespués será leído por la herramienta HDADR para representar de forma gráfica la FPGA. Seescoge este formato para que los datos sean fáciles de leer, tanto para la herramienta HDADR

como para otras futuras aplicaciones que quieran hacer uso de estos archivos.

El código del script que se encaga de obtener los datos de los recursos (generateBoardsXML.tcl)se encuentra en el Listado 5.13, y por último el Listado 5.14 muestra un fragmento del ar-chivo XML que se obtiene para la ZedBoard al ejecutar el script.

76

-- Dummy component for creating a temporal design

-- Javier Sevilla

library ieee;

use ieee.std_logic_1164.all;

entity dummy is

port (

clk : IN STD_LOGIC;

output : OUT STD_LOGIC);

end;

architecture structural_dummy of dummy is

begin

dummyPrcss: PROCESS (clk)

BEGIN

IF clk’EVENT AND clk = ’1’ THEN

output <= ’0’;

END IF;

END PROCESS dummyPrcss;

end structural_dummy;

Listado 5.12: Componente sintetizado para poder acceder a los recursos hardware de laFPGA.

1 ### HDADR - Javier Sevilla Ballesteros

2

3 # Generate an XML file with the properties of the specified board

4 proc generateBoardXML {part board} {

5 # Create and open a temporal project / design

6 create_project -in_memory -part $part

7 set_property board_part $board [current_project]

8 read_vhdl ./dummy.vhd

9 synth_design -mode out_of_context -flatten_hierarchy rebuilt -top dummy -part $part

10

11 # Generate XML

12 set outputFile $board

13 append outputFile ".xml"

14 set outputFileID [open $outputFile "w"]

15 set listOfSites [get_sites]

16 set listOfSites_Size [llength $listOfSites]

17

18 # Write the header of the XML file

19 puts -nonewline $outputFileID "<?xml version=’1.0’ encoding=’UTF-8’?>\n\n"

20 puts -nonewline $outputFileID "\n\n"

21

22 # Write the number of rows and columns of the board

23 set rows 0

24 set columns 0

25 foreach site $listOfSites {

77

26 set site_RPM_X [get_property RPM_X $site]

27 set site_RPM_Y [get_property RPM_Y $site]

28

29 if {$rows < $site_RPM_Y} {

30 set rows $site_RPM_Y

31 }

32 if {$columns < $site_RPM_X} {

33 set columns $site_RPM_X

34 }

35 }

36

37 set rows [expr $rows + 1]

38 set columns [expr $columns + 1]

39

40 puts -nonewline $outputFileID "<Board name=\"$board\" rows=\"$rows\" columns=\"$columns\">\n"

41

42 # Write the needed information for each site of the board

43 foreach site $listOfSites {

44 set site_NAME [get_property NAME $site]

45 set site_TYPE [get_property SITE_TYPE $site]

46 set site_CLOCKREGION [get_property CLOCK_REGION $site]

47 set site_RPM_X [get_property RPM_X $site]

48 set site_RPM_Y [get_property RPM_Y $site]

49

50 if {![string equal $site_TYPE "TIEOFF"]} {

51 puts -nonewline $outputFileID "\t<Site name=\"$site_NAME\" type=\"$site_TYPE\" clkreg=\"

$site_CLOCKREGION\" rpmx=\"$site_RPM_X\" rpmy=\"$site_RPM_Y\"/>\n"

52 }

53 }

54

55 puts -nonewline $outputFileID "</Board>\n"

56

57 #Close the output file

58 close $outputFileID

59 #Close the temporal design and project

60 close_design

61 close_project

62 }

63

64 # ZedBoard

65 generateBoardXML "xc7z020clg484-1" "em.avnet.com:zed:part0:1.2"

66 # Kintex-7 KC705 Evaluation Platform (XC7K325T-2FFG900C)

67 generateBoardXML "xc7k325tffg900-2" "xilinx.com:kc705:part0:1.2"

Listado 5.13: Script que extrae los datos de los recursos hardware de la FPGA.

78

<?xml version=’1.0’ encoding=’UTF-8’?>



<Board name="em.avnet.com:zed:part0:1.2" rows="299" columns="308">

<Site name="SLICE_X26Y149" type="SLICEM" clkreg="X0Y2" rpmx="85" rpmy="298"/>

<Site name="SLICE_X27Y149" type="SLICEL" clkreg="X0Y2" rpmx="87" rpmy="298"/>



</Board>

Listado 5.14: Fragmento del archivo XML generado que contiene los datos de la ZedBoard.

B. Prototipado de la GUI.

En esta tarea se realiza el prototipado de la ventana que permite al diseñador seleccionarel área que debe ocupar una partición reconfigurable. El prototipo resultante se muestra enel Apéndice A. Respecto al diseño del software, en esta tarea se añade una clase más a lacapa de presentación del diagrama de clases: FloorplanGUI, encargada de crear la ventana ytodos los componentes del prototipo mostrado.

C. Implementación.

Una vez realizado el prototipo y actualizado el diagrama de clases de la herramienta seprocede a implementar la ventana que permite el floorplanning. Mencionar que la represen-tación de los recursos hardware de la FPGA se implementa utilizando una tabla en la que secambia el color de fondo de las celdas en función del tipo de recurso hardware. Al situar elratón encima de una celda se muestran todos los datos de ese recurso en un tooltip.

En la Figura 5.6 se puede ver el resultado de la implementación, teniendo en cuenta quesu aspecto cambiará a lo largo del desarrollo del TFG.

D. Pruebas de la iteración.

En esta iteración, al no desarrollarse ninguna nueva clase en las capas de dominio y per-sistencia, no se realizan pruebas unitarias al software. En su lugar se llevan a cabo pruebasde caja negra que consisten en comprobar el funcionamiento de la herramienta HDADR

creando varios diseños reconfigurables a través de su interfaz gráfica. En el momen-to de definir las particiones reconfigurables se hace uso del selector de área implementado,comprobando que los recursos se muestran correctamente y que cumple con éxito todas lasfuncionalidades requeridas. Una vez definido todo el diseño se generan correctamente todoslos bitstreams y se permite añadir nuevos módulos y configuraciones, concluyendo que elsoftware desarrollado en esta iteración funciona correctamente.

Después se analizan los posibles memory leaks que pueden ocurrir a lo largo de la ejecu-ción de la herramienta utilizando la herramienta Valgrind. El informe final obtenido muestrala existencia de varias fugas de memoria, pero analizándolo se concluye que ninguna estácausada explícitamente por el software desarrollado en esta iteración, por lo que esta prue-

79

Figura 5.6: GUI de la ventana que permite al diseñador realizar el floorplanning.

ba también se supera con éxito. El resumen del informe de Valgrind que se obtiene semuestra a continuación:

==7090== HEAP SUMMARY:

==7090== in use at exit: 2,747,171 bytes in 32,417 blocks

==7090== total heap usage: 2,923,291 allocs, 2,890,874 frees, 1,291,510,423 bytes

allocated

==7090==

==7090== LEAK SUMMARY:

==7090== definitely lost: 15,834 bytes in 163 blocks

==7090== indirectly lost: 85,254 bytes in 1,449 blocks

==7090== possibly lost: 64,758 bytes in 935 blocks

==7090== still reachable: 2,382,269 bytes in 28,856 blocks

==7090== suppressed: 0 bytes in 0 blocks


Finalizado todo el trabajo de esta iteración se vuelve a reunir el equipo Scrum para valorarlos resultados. En esta ocasión el producto entregable es la herramienta con la interfaz gráficaque guía al diseñador a lo largo de todo el flujo de diseño, permitiéndole la generación dediseños reconfigurables. Además, el usuario podrá seleccionar el área de la FPGA que debe

80

ocupar una partición de forma gráfica.

En la reunión se propone realizar varios cambios en la herramienta desarrollada: pre-guntar al usuario si quiere generar la configuración blanking o no, y añadir un buscador enla ventana de selección de área que permita encontrar un recurso hardware atendiendo alnombre de éste. El Cuadro 5.5 muestra cómo queda el product backlog después de añadirleestas modificaciones.

ID Descripción Prioridad005 Permitir al usuario gestionar la programación de la FPGA

desde la herramienta HDADR utilizando un bitstream de undiseño generado previamente.

Alta

006 Implementar la posibilidad de exportar el hardware de undiseño ya generado a Vivado SDK.

Alta

007 Permitir que el usuario pueda desarrollar una aplicación pro-pia que se encargue de la gestión de la reconfiguración de laFPGA.

Alta


Media

009 Dar la posibilidad al usuario de decidir si quiere generar laconfiguración blanking o no.

Alta

010 Añadir un buscador en la ventana que permite seleccionar elárea de una partición reconfigurable para buscar un recursopor nombre.

Alta

Cuadro 5.5: Product backlog al finalizar la iteración 2.

5.3.3 Iteración 3Al igual que en anteriores iteraciones, en la planificación de la iteración se reune el equipo

Scrum para seleccionar los elementos del product backlog que se han de realizar a lo largode esta iteración. Una vez seleccionados, el equipo de desarrollo desglosa cada uno de estoselementos en varias tareas que se han de realizar para finalizar cada elemento. De esta formase obtiene el sprint backlog que se muestra en el Cuadro 5.6.

Dar la opción de generar la configuración blanking (ID 009)

Tal y como se describió en la Sección 3.3, en la configuración blanking no se añadenmódulos a las particiones, dejándolas «vacías». Generar esta configuración requiere cargar laparte estática sintetizada, realizar la implementación de ésta y generar los bitstreams. Todoeste proceso requiere de un tiempo considerable para su finalización, tiempo que sepuede ahorrar el usuario si en realidad no va a hacer uso de esta configuración opcional.Por lo tanto, lo que se busca en este elemento del sprint backlog es darle al usuario laposibilidad de decidir si quiere generar la configuración blanking o no.

81

A. Estudio e implementación del cambio.

En primer lugar se estudian los cambios que hay que realizar a los scripts para implementaresta funcionalidad en la herramienta. La decisión que tome el usuario sobre si generar o no laconfiguración aparecerá reflejada en una variable booleana dentro del archivo design.tcl, deforma que después esta variable sea interpretada por los scripts que se encargan de generarel diseño.

Los cambios que se realizan a los scripts son los siguientes:

El contenido del script blanking_create.tcl se modifica para que la implementaciónde la configuración blanking se realice solo cuando el usuario lo haya indicado.

El script impl_verify.tcl también se modifica, añadiendo la configuración blanking

al listado de las configuraciones que se tienen que validar solo en el caso de que elusuario decida generarla.

Finalmente, se modifican los scripts encargados de generar los bitstreams (bit_gen.tcly bit_gen_partial.tcl) para ejecutar el comando write_bitstream sobre la configura-ción blanking solo cuando sea necesario.

Una vez que los scripts se han modificado se añade a la herramienta HDADR una opciónque permite al usuario decidir si generar esta configuración o no, de forma que luego estadecisión se incluya en el archivo design.tcl.

Añadir buscador de recursos hardware (ID 010)

Dado que el número de recursos hardware que contiene una FPGA es bastante elevado(15116 en el caso de la ZedBoard, 55911 en el caso de la Kintex-7), una funcionalidadinteresante sería ofrecer un buscador que permita al diseñador localizar en la representacióngráfica un recurso hardware atendiendo a su nombre.

A. Implementación del cambio.

En esta tarea se implementa en primer lugar la parte de la interfaz gráfica correspondienteal buscador y, después, se implementa el algoritmo que se encarga de buscar un recursohardware a partir de un nombre. En el caso de que se encuentre un recurso que tenga elmismo nombre que el proporcionado por el diseñador, se actualizará la representación dela FPGA para que la celda que representa al recurso quede dentro del rango visible para eldiseñador y, además, se marcará con una X esta celda. El resultado de este algoritmo yaimplementado se encuentra en el Listado 5.15.

Gestionar la reconfiguración de la FPGA utilizando un bitstream (ID 005)

Para seguir cumpliendo con los objetivos marcados en este TFG es necesario ofrecer aldiseñador la posibilidad de gestionar la reconfiguración desde la herramienta HDADR. La

82

void FloorplanWidget::searchSite() {

bool found = false;

QTableWidgetItem *item;

QString siteName, hwResourceName, tooltip;

siteName = searchSiteLineEdit->text();

//Search the site

for (int i = 0; i < boardTable->rowCount() && !found; i++) {

for (int j = 0; j < boardTable->columnCount() && !found; j++) {

item = boardTable->item(i, j);

if (item != 0) {

tooltip = item->toolTip();

if (!tooltip.isEmpty()) {

hwResourceName = tooltip.left(tooltip.indexOf("\n"));

if (hwResourceName == siteName) {

found = true;

}

}

}

}

}

//If it was found, mark the site with an X. If not, show an error.

if (found) {

searchSiteResultLabel->setVisible(false);

item->setText("X");

boardTable->scrollToItem(item, QAbstractItemView::PositionAtCenter);

}

else {

searchSiteResultLabel->setText("No encontrado");

searchSiteResultLabel->setStyleSheet("color : red");

searchSiteResultLabel->setVisible(true);

}

}

Listado 5.15: Algoritmo utilizado para buscar un recurso hardware en la representacióngráfica de la FPGA.

primera forma de gestionar la reconfiguración que se implementará será permitir al dise-ñador cargar un bitstream en la FPGA utilizando la herramienta HDADR, de forma que eldiseñador pueda cargar cualquier bitstream de los obtenidos tras la generación de un diseñoreconfigurable (completos y parciales). Así, el diseñador podrá hacer uso de la herra-mienta para cargar los módulos reconfigurables que desee en cada momento. Recordarque antes de poder programar la FPGA con un bitstream parcial es necesario haberla progra-mado anteriormente con un bitstream completo.

A. Estudiar cómo realizar la programación de la FPGA utilizando un bitstream en laherramienta HDADR.

La programación de la FPGA utilizando un bitstream también se puede realizar a través delintérprete TCL que incorpora Vivado. El proyecto del grupo ARCO proporcionado incluye unscript (program.tcl) que permite cargar un determinado bitstream en una FPGA. Este script

83

realiza lo siguiente:

1. En primer lugar se carga el Hardware Manager de Xilinx que permite la interacciónentre el equipo y la FPGA a través del comando open_hw.

2. Se realiza la conexión con el servidor hardware de Vivado y se conecta con el disposi-tivo que se desea programar (comandos connect_hw_server y open_hw_target).

3. Después se cambia el valor de la propiedad PROGRAM.FILE del dispositivo que se deseaprogramar utilizando el comando set_property. Esta propiedad define la ruta donde seencuentra el bitstream con el que se desea programar la FPGA.

4. Finalmente se programa el dispositivo utilizando el comando program_hw_devices.

Por tanto, para permitir al diseñador programar la FPGA desde la herramienta HDADR

se deberá generar el script program.tcl a partir del bitstream indicado por el diseñador. Laplantilla a partir de la cual se generará este script se muestra en el Listado 5.16.

# File generated by hdadr_tfg

###############################################################

### Define Output and top name

###############################################################

set bitDir {{BIT_DIR}}

set bitName {{BIT_NAME}}

###############################################################

### Download

###############################################################

open_hw

connect_hw_server

open_hw_target

set_property PROGRAM.FILE $bitDir$bitName [get_hw_devices xc*]

program_hw_devices [get_hw_devices xc*]

return 0

Listado 5.16: Plantilla utilizada para generar el archivo program.tcl.

B. Prototipado de la GUI y actualización del diseño software.

A la hora de realizar el prototipado de la interfaz gráfica hay que tener en cuenta quelos objetivos de este TFG contemplan dos tipos de gestión de la reconfiguración: desde lapropia herramienta HDADR (este caso), o desde una aplicación creada por el usuario. Estasdos opciones se incluyen en el gestor de la reconfiguración de la herramienta HDADR,preguntando al diseñador qué opción desea escoger.

El Apéndice A contiene el boceto del gestor de reconfiguración de la herramienta HDADR

y el prototipo de la interfaz que permite programar la FPGA utilizando un bitstream determi-nado de los obtenidos previamente en la generación de un diseño reconfigurable.

84

Respecto al diseño software, se actualiza el diagrama de clases de la siguiente forma: enla capa de presentación se añaden las nuevas clases que se encargarán de la representacióngráfica del gestor de la reconfiguración, en la capa de dominio se añade una nueva clase(ProgramFPGA) que servirá para almacenar toda la información necesaria para la programa-ción del dispositivo, y finalmente en la capa de persistencia se añade la clase que generará elarchivo program.tcl. El estado del diagrama de clases tras añadir todo lo anterior se muestraen la Figura 5.7.

Persistencia

Dominio

GenDesignTCL

-partitions

0..*

-modules0..* -configurations

0..*

Presentación

MainWindow

PartitionsGUI


GeneralInfoGUI

+addToDesign()

StaticPartGUI

+addToDesign()

ModulesGUI


Design


ConfigurationsGUI


-mainDesign1

GenProgram TCL

+generate()

ReconfigurationManagement

ReconfigurationManagementOptionInterface

+getProgrammingNow()

ProgramGUI

+program()

ProgramFPGA

-bitstreamsDir-bitstream

+ProgramFPGA()+generateProgramTCL()+setBitstream()+getBitstreamsDir()+getBitstream()

-selectedOption1

FloorplanGUI


85

C. Implementación de la funcionalidad.

Una vez realizados los prototipos de la interfaz gráfica y actualizado el diseño softwa-re, se procede a la implementanción de la funcionalidad en la herramienta HDADR. Parapoder abrir el gestor de la reconfiguración y las futuras funcionalidades que se implemen-tarán posteriormente se crea una barra de menús en la ventana principal de la herramienta.Además, destacar que en la clase ReconfigurationManagement se sobreescriben los métodoscloseEvent() y keyPressEvent() para evitar el cierre de la interfaz gráfica mientras se realizala programación de la FPGA. Como en el resto de las iteraciones, el resultado de esta tarease sube al repositorio del proyecto en Bitbucket.

D. Pruebas.

En primer lugar se realiza una prueba unitaria al software desarrollado en las clases dedominio y persistencia, obteniendo después de su ejecución la cantidad de código que se haejecutado en esta prueba. Los resultados obtenidos se muestran en el Cuadro 5.7.

Después se aplica una prueba de caja negra a la herramienta, utilizando el gestor dela reconfiguración desarrollado para introducir las entradas que necesita la herramienta paragenerar el archivo program.tcl. La conclusión tras la ejecución de estas pruebas es que tantoel funcionamiento de la herramienta como el archivo generado son correctos.

Por último, al igual que en anteriores iteraciones, se aplica un análisis del uso de me-moria utilizando la herramienta Valgrind, detectando tres memory leaks provocados por laherramienta HDADR: uno a la hora de crear la barra de menús, y dos detectados a la hora deiniciar los procesos encargados de la generación del diseño y de la programación de la FPGA

(no se establecía el padre de los objetos QProcess para su posterior destrucción). Una vezsolucionados se puede continuar con el siguiente elemento del sprint backlog.

86

ID Descripción breve Tareas009 Dar la opción de generar la

configuración blanking.Estudio e implementación del cambio.

010 Añadir buscador de recur-sos hardware.

Implementación del cambio.

005Gestionar lareconfiguración de la FPGAutilizando un bitstream.

Estudiar cómo realizar la programación de laFPGA utilizando un bitstream en la herramien-ta HDADR.Prototipado de la GUI y actualización del di-seño software.Implementación de la funcionalidad.Pruebas.

006Exportar el hardware aVivado SDK.

Prototipado de la GUI y actualización del di-seño software.Implementación de la funcionalidad y prue-bas.



ProgramFPGAComprobados todos losconstructores y el acceso ymodificación de todos los atributos.Comprobado el correctofuncionamiento de la generación delarchivo program.tcl, caso en el quese ve involucrada la claseGenProgramTCL.

ProgramFPGA 94.12 %GenProgramTCL 100 %


87

Exportar el hardware a Vivado SDK (ID 006)

El último elemento a desarrollar en esta iteración es implementar la posibilidad de queel diseñador pueda exportar la descripción del hardware del diseño generado a Vivado SDKpara que pueda crear aplicaciones sobre este hardware. Con el objetivo de ofrecer la mismafuncionalidad que Vivado en este aspecto, se ofrecerá al usuario la posibilidad de añadir elbitstream de referencia a esta descripción hardware y además la posibilidad de abrir VivadoSDK una vez que finalice el proceso de exportación.

A. Prototipado de la GUI y actualización del diseño software.

El prototipo de la interfaz gráfica creado para la ventana que permite exportar el hardwarese encuentra en el Apéndice A. Respecto al diseño software, se actualiza el diagrama declases mostrado en la Figura 5.7 añadiendo la nueva clase ExportToVivadoSDK a la capa depresentación. Esta clase se encargará de la representación gráfica de esta ventana.

B. Implementación de la funcionalidad y pruebas.

El proyecto proporcionado cuenta con tres scripts TCL que ayudan a la hora de realizar laimplementación de esta tarea:

sdk_export.tcl. Abre el proyecto de Vivado creado cuando se generó el diseño y ex-porta la descripción del hardware a través del comando write_hwdef.

addBitstream.tcl. Añade el bitstream de referencia a la descripción hardware expor-tada.

sdk_launch.tcl. Se encarga de abrir la herramienta Vivado SDK cargando la descrip-ción hardware que se ha exportado.

Estos scripts se ejecutarán en función de lo que el usuario indique en la ventana a desa-rrollar. La parte del código que se encarga de iniciar el proceso de exportación del hardwarea Vivado SDK se muestra en el Listado 5.17. Mencionar que el diseñador podrá acceder aesta funcionalidad a través de la barra de menús de la interfaz principal.

Finalizada la implementación del software se realizan varias pruebas para comprobar sufuncionamiento. Dado que en este caso solo se ha desarrollado software en la capa de pre-sentación, no se realizarán pruebas unitarias. En su lugar, para comprobar el funcionamientode la interfaz gráfica, se realizan varias pruebas de caja negra en la que se ejecuta la herra-mienta variando el valor de las entradas que recibe (incluir o no el bitstream en la definiciónhardware, etc.) y observando las salidas que se producen.


Una vez que se han desarrollado todos los elementos del sprint backlog se reune el equipoScrum para valorar los resultados. Al producto entregable de la anterior iteración se le añaden

88

void ExportToVivadoSDK::exportToSDK() {

QString command;

addBitstreamOption->setEnabled(false);

launchSDKOption->setEnabled(false);

exportButton->setEnabled(false);

//Check options

command = "make runSDKExportTCL";

if (addBitstreamOption->isChecked()) {

command += " runAddBitstreamTCL";

}

if (launchSDKOption->isChecked()) {

command += " runSDKLaunchTCL";

}

//Show progress bar

exportProgressBar->setMinimum(0);

exportProgressBar->setMaximum(0);

exportProgressBar->setFixedHeight(15);

exportProgressBar->setVisible(true);

//Launch the export process

exportingNow = true;

exportProcess = new QProcess(this);

exportProcess->setWorkingDirectory(mainDir);

connect(exportProcess, SIGNAL(finished(int,QProcess::ExitStatus)), this, SLOT(

exportProcessFinished(int,QProcess::ExitStatus)));

exportProcess->start(command);

}

Listado 5.17: Código que se encarga de exportar la definición hardware a Vivado SDK.

las siguientes funcionalidades: decidir si se tiene que generar la configuración blanking o no,un buscador en la ventana de floorplanning para buscar un recurso hardware por su nombre,la posibilidad de programar la FPGA utilizando un bitstream completo o parcial, y el poderexportar la definición hardware del diseño generado a Vivado SDK.

En esta reunión se acepta todo el trabajo realizado y el product manager propone dosnuevos elementos que agregar al product backlog: añadir persistencia a la herramientaHDADR y añadir nuevas funcionalidades al flujo de diseño. Además, el equipo de desarrollopropone realizar algunas mejoras en la herramienta. En el Cuadro 5.8 se explica con detalleen qué consiste cada uno de estos nuevos elementos.

89

ID Descripción Prioridad007 Permitir que el usuario pueda desarrollar una aplicación pro-

pia que se encargue de la gestión de la reconfiguración de laFPGA.

Alta


Media

011 Añadir persistencia a la herramienta HDADR, es decir, queel diseñador pueda recuperar un diseño generado anterior-mente tras cerrar la herramienta.

Media

012 Añadir nuevas funcionalidades al flujo de diseño. Permitiral diseñador seleccionar el valor de las propiedades RESET_-

AFTER_RECONFIG y SNAPPING_MODE para cada partición recon-figurable que se cree. Además, para cada bitstream que sevaya a generar, permitirle seleccionar si quiere aplicarle lacompresión de Xilinx o no.

Media

013 Mejorar la representación gráfica del flujo de diseño para ha-cerlo más intuitivo. Mejorar la lectura de los archivos XMLque contienen la información de los recursos hardware delas FPGAS.

Media


90

5.3.4 Iteración 4En el Cuadro 5.9 se muestran los elementos del product backlog seleccionados por el

equipo Scrum que se realizarán a lo largo de esta iteración, incluyendo las tareas identificadaspor el equipo de desarrollo para cada uno de estos elementos.


007Permitir que el usuariopueda desarrollar unaaplicación propia para lagestión de lareconfiguración.

Estudiar cómo desarrollar la funcionalidad re-querida.Prototipado de la GUI y actualización del di-seño software.Implementación y pruebas.

011Añadir persistencia a laherramienta HDADR.

Actualizar el diseño software de la herramien-ta.Implementación y pruebas.

013Implementar variasmejoras.

Mejorar la representación gráfica del flujo dediseño.Mejorar la lectura de los archivos XML quecontienen la información de los recursos hard-ware de las FPGAS.

012Añadir nuevasfuncionalidades al flujo dediseño.

Implementar la selección del valor de las pro-piedades RESET_AFTER_RECONFIG y SNAPPING_-

MODE a la hora de crear una partición.Implementar la posibilidad de comprimir cadauno de los bitstreams que se vayan a generaraplicando la compresión de Xilinx.Pruebas.


Permitir que el usuario pueda desarrollar una aplicación propia para la gestión de lareconfiguración (ID 007)

Además de permitir al diseñador programar la FPGA utilizando un bitstream de los gene-rados, se le debe dar la posibilidad de utilizar una aplicación creada por él para gestionarla reconfiguración de la FPGA, reconfigurando parcialmente el diseño haciendo uso de losbitstreams que se encuentren en la memoria de la FPGA. Esta aplicación podrá hacer usodel componente zipFactory para llevar a cabo esta reconfiguración, lo que permite ahorrarespacio de memoria en la FPGA gracias a la técnica de compresión que ofrece este compo-nente. Por lo tanto, el objetivo de este elemento del sprint backlog es ofrecer al diseñadortodo lo necesario para que pueda cargar fácilmente su aplicación en la FPGA, incluyendo lacompresión de los bitstreams que se vayan a cargar en la memoria de la FPGA si así lo deseael diseñador.

91

A. Estudiar cómo desarrollar la funcionalidad requerida.

Permitir que el diseñador utilice su aplicación para gestionar la reconfiguración parcial dela FPGA requiere realizar el siguiente proceso:

En primer lugar se debe programar la FPGA con un bitstream completo, lo cual sepuede llevar a cabo generando el archivo program.tcl que se desarrolló en la iteraciónanterior.

Después se comprimirán los bitstreams parciales que se vayan a utilizar empleandola herramienta write_factory_bitstream mostrada en la Subsección 3.5.3.

Finalmente se carga la aplicación de usuario y los bitstreams parciales comprimi-dos en la memoria del dispositivo. Para ello se generará el script xmd.tcl que seráinterpretado por la herramienta XMD (Xilinx Microprocessor Debugger). Esta herra-mienta ofrece una interfaz TCL que puede ser utilizada para controlar el dispositivo ydepurar aplicaciones que se ejecuten en él [Xil13a].

La generación del script program.tcl ya se implementó en la anterior iteración. Por otraparte, la plantilla que se utilizará para generar el script xmd.tcl se muestra en el Lista-do 5.18. Dentro de este script se establece la conexión con el procesador Cortex, se confi-gura el sistema de procesamiento a partir del script de la plataforma hardware (generada enVivado SDK), y finalmente se carga la aplicación y los bitstreams parciales en memoria através de la orden dow. Es importante mencionar que al cargar un bitstream en memoria esnecesario indicar la dirección donde ubicarlo, mientras que en el caso de la aplicación estono es necesario ya que la dirección se obtendrá del propio ejecutable.

También se generará el archivo deploy.mk, encargado de ejecutar los anteriores scriptscon sus respectivas herramientas y de comprimir los bitstreams parciales utilizando la herra-mienta write_factory_bitstream. Como se puede observar en el Listado 5.19, los bitstreamsque se tienen que comprimir se especifican dentro de este Makefile.


Una vez que se conoce el proceso necesario para llevar a cabo esta funcionalidad, se iniciael prototipado de la interfaz gráfica teniendo en cuenta todos los datos que el diseñador tieneque introducir para poder cargar su aplicación en la FPGA. El prototipo resultante se adjuntaen el Apéndice A.

Por su parte, el diagrama de clases de la herramienta HDADR se actualiza añadiendolas clases que se encargan de la generación de los nuevos scripts, la clase que se encargade la interfaz gráfica, y ampliando la clase ProgramFPGA de la capa de dominio para quesoporte esta nueva forma de realizar la reconfiguración. Este diagrama se muestra en la Fi-gura 5.8.

92

Persistencia

Dominio

GenDesignTCL

-partitions

0..*

-modules0..* -configurations

0..*

Presentación

MainWindow

PartitionsGUI


GeneralInfoGUI

+addToDesign()

StaticPartGUI

+addToDesign()

ModulesGUI


Design


ConfigurationsGUI


-mainDesign1

GenProgram TCL



+getProgrammingNow()

ProgramGUI

+program()

-selectedOption1

FloorplanGUI

ProgramUserAppGUI

+program()

ProgramFPGA

-bitstreamsDir-bitstream-partialBitstreams-wrapperHWPlatfform-applications

+ProgramFPGA()+generateProgramTCL()+generateXMDTCL()+setBitstream()+getBitstreamsDir()+getBitstream()+generateDeployMK()+addPartialBitstream()+addApplication()+setWrapperHWPlatform()+getPartialBitstreams()+getWrapperHWPlatform()+getApplications()

GenXMDTCL

+generate()

GenDeployMK

+generate()

ExportTovivadoSDK

Figura 5.8: Diagrama de clases de la iteración 4 (primera actualización).

93


### Connect to Cortex processor

connect arm hw

source {{WRAPPER_HW_PLATFORM_SOURCE}}

ps7_init

ps7_post_config

### Download factory bitstreams

{{#DOW_FACTORY_BITSTREAM}}dow -data {{BITSTREAMS_DIR}}{{FACTORY_BITSTREAM}} {{MEM_ADDR}}

{{/DOW_FACTORY_BITSTREAM}}

### Download apps

{{#DOW_APP}}dow {{APP}}

{{/DOW_APP}}

run

Listado 5.18: Plantilla utilizada para generar el archivo xmd.tcl.


ProgramFPGA

Prueba de la clase ProgramFPGAactualizada para comprobar elfuncionamiento de la generación delos archivos xmd.tcl y deploy.mk. Algenerar estos archivos se utilizan deforma implícita las clases de la capade persistencia encargadas de ello.

ProgramFPGA 94.23 %GenProgramTCL 100 %GenXMDTCL 100 %GenDeployMK 100 %

Cuadro 5.10: Resultado de las pruebas unitarias de la iteración 4 (elemento ID 007).

C. Implementación y pruebas.

Realizados los prototipos y actualizado el diagrama de clases se procede a implementarel software de este elemento del sprint backlog, agregando la interfaz desarrollada dentrodel gestor de la reconfiguración ya implementado en la anterior iteración. Una vez imple-mentado se actualizan las pruebas unitarias de la clase ProgramFPGA (capa de dominio)para comprobar el funcionamiento del nuevo software implementado. La descripción de laspruebas que se realizan y la cobertura obtenida se muestran en el Cuadro 5.10.

Al igual que en anteriores iteraciones, después se realizan varias pruebas de caja negrapara comprobar el funcionamiento de la interfaz gráfica. Finalmente se realiza un análi-sis del uso de memoria utilizando la herramienta Valgrind, análisis que se supera sin quese produzca ningún memory leak causado explícitamente por el código desarrollado por elalumno.

94


PARTIAL_BITSTREAMS={{#PARTIAL_BITSTREAM}}{{PARTIAL_BITSTREAM_NAME}} {{/PARTIAL_BITSTREAM}}

BITSTREAMS_DIR={{BITSTREAMS_DIR}}

WRITE_TOOL_DIR=../../tools/write_factory_bitstreams

WRITE_TOOL=$(WRITE_TOOL_DIR)/write_factory_bitstreams

all: build-partial-bitstreams program deploy

$(WRITE_TOOL):

@cd $(WRITE_TOOL_DIR) ;\

make; cd -

build-partial-bitstreams: $(WRITE_TOOL)

@for i in $(PARTIAL_BITSTREAMS) ; do \

$(WRITE_TOOL) -z $(BITSTREAMS_DIR)$$i $(BITSTREAMS_DIR)/factory_$$i ;\

done

read_mem: program

xmd -tcl xmd_read.tcl

program: program.tcl

vivado -mode batch -source $^

deploy: xmd.tcl

xmd -tcl $^

clean:

$(RM) -rf $(BITSTREAMS_DIR)/factory_*

cleanall: clean

@cd $(WRITE_TOOL_DIR) ;\

make clean; cd -

Listado 5.19: Plantilla utilizada para generar el archivo deploy.mk.

Añadir persistencia a la herramienta HDADR (ID 011)

Supongamos que un diseñador utiliza la herramienta HDADR y genera por primera vezun diseño reconfigurable. Después, como ya se especificó en el flujo de diseño de esta he-rramienta, puede añadir nuevos módulos y/o nuevas configuraciones a éste sin necesidad devolver a generar todo el diseño de nuevo. El problema que tiene la herramienta en este puntoes que si se cierra la aplicación después no hay posibilidad de recuperar la informaciónde un diseño generado previamente, lo que implica que al abrir de nuevo la herramienta senecesitaría introducir toda la información de nuevo y volver a generar el diseño completo.Para dar solución a ésto, cada vez que se genere un diseño se guardará toda su informa-ción en un archivo para que después se puedan recuperar todos estos datos.

Es decir, al mismo tiempo que se genera el archivo design.tcl a partir de la informaciónde que ha introducido el diseñador en la herramienta, también se almacenará toda esta in-formación en un archivo que pueda ser leído por la herramienta para recuperar este diseño

95

posteriormente en caso de ser necesario. Se decide elegir el formato XML para guardarla información del diseño, ya que de esta forma el archivo podrá ser leído fácilmente tantopor la herramienta HDADR como por otras posibles herramientas que se desarrollen en unfuturo.

A. Actualizar el diseño software de la herramienta.

Dado que toda la información sobre el diseño reconfigurable se almacena en la clase De-sign, se añade una clase a la capa de persistencia encargada de generar y leer el archivo XML

que contiene esta información. Además, también será necesario modificar las clases de lacapa de presentación para que puedan actualizar el contenido de sus elementos a partir de unobjeto de la clase Design cuando se decida recuperar un diseño generado previamente por laherramienta. La actualización del diagrama de clases se muestra en la Figura 5.9.

Por otra parte, se realiza el diseño de la estructura que tendrá el archivo XML quese generará. El elemento principal de este archivo será un diseño, el cual tendrá comoatributos el part y board de la FPGA, el nombre del proyecto, nombre del diseño, el directoriode IPS de usuario, y el archivo que contiene el diseño de bloques. Dentro de un diseño seintroducirán los siguientes elementos:

Un elemento para cada archivo de la parte estática con los siguientes atributos:directorio, nombre del archivo, y si es el archivo top o no.

Un elemento para cada archivo de restricciones que contenga el diseño, incluyendoel directorio y el nombre del archivo como atributos de este elemento.

Para cada partición que tenga el diseño se creará un elemento con los siguientesatributos: ID, nombre, ruta del código en Vivado y el nombre de la instancia que repre-senta a la partición. Además, para cada uno de los recursos ocupados por la particiónse añadirá un nuevo elemento dentro del elemento que representa a la partición en estearchivo XML.

Para cada módulo reconfigurable del diseño se crea también un elemento que con-tiene los siguientes atributos: ID, nombre, y el ID de la partición a la que está asociado.Además, para cada uno de los archivos que conforman el módulo reconfigurable se in-cluye un elemento con el directorio y el nombre del archivo dentro del elemento querepresenta al módulo.

Finalmente, para cada configuración también se crea un elemento que contiene elID y el nombre de la configuración. Dentro de este elemento de la configuración, paracada módulo que se implemente en la configuración se añade un nuevo elemento conel nombre del módulo dentro del elemento que representa a la configuración.

B. Implementación y pruebas.

En esta tarea se realiza la implementación de la persistencia de la herramienta HDADR

96

PersistenciaDominio

GenDesignTCL

-partitions 0..* -modules 0..*-configurations

0..*

Presentación

MainWindow

PartitionsGUI

+loadFromDesign()

GeneralInfoGUI

+loadFromDesign()

StaticPartGUI

+loadFromDesign()

ModulesGUI

+loadFromDesign()

Design

+generateXML()+loadFromXML()


ConfigurationsGUI

+loadFromDesign()

-mainDesign1



ProgramGUI

-selectedOption1

FloorplanGUI

ProgramUserAppGUI

ProgramFPGA

ExportTovivadoSDK

DesignXML

+saveDesign()+readDesign()-addStaticFilesToXML()-addConstraintFilesToXML()-addPartitionsToXML()-addModulesToXML()-addConfigurationsToXML()-readDesignAttributes()-readStaticFileAttributes()-readConstraintFileAttributes()-readPartition()-readModule()-readConfiguration()

GenProgram TCL

GenXMDTCL

GenDeployMK

En las clases Design, GeneralInfoGUI, StaticPartGUI, PartitionsGUI, ModulesGUI y ConfigurationsGUI solo se muestranlos metodos que se añaden en esta ocasión.

Figura 5.9: Diagrama de clases de la iteración 4 (segunda actualización).

atendiendo al diagrama de clases actualizado y al diseño de la estructura que debe seguir elarchivo XML que se genere. Este archivo, cuyo nombre será design.xml, se generará cuandoel diseñador pulse el botón «Generar diseño» (ya sea para generar un diseño por primera vezo para realizar una generación parcial del diseño).

Cuando el diseñador abre la herramienta HDADR, lo primero que tiene que introducir esel directorio raíz donde se ubicará el proyecto y donde se encuentra Makefile que permitea la herramienta ejecutar los scripts. Si dentro de este directorio se encuentra un archivo

97


DesignSe actualiza la prueba de la claseDesign para comprobar lageneración del archivo XML quecontiene la definición de un diseñogenerado con la herramientaHDADR. Después, ese archivogenerado se lee y se carga en unnuevo diseño, analizando que todoslos atributos se cargancorrectamente.

Design 84.62 %GenDesignTCL 100 %DesignXML 99.53 %

Cuadro 5.11: Resultado de las pruebas unitarias de la iteración 4 (elemento ID 011).

design.xml, se le preguntará al usuario si desea cargar este diseño anterior en la herra-mienta. Si se decide cargar el diseño, se podrán añadir nuevos módulos y/o configuracionesal diseño pero, lógicamente, no se podrá modificar la parte estática de éste.

Respecto a las pruebas, en primer lugar se actualiza el contenido de la prueba unitariade la clase Design para comprobar que la persistencia de la herramienta se ha implementa-do correctamente. El resumen de esta prueba y los resultados obtenidos se muestran en elCuadro 5.11. Después se ejecuta la herramienta para comprobar que la integración de estafuncionalidad con la interfaz gráfica es correcta. Finalmente se analiza la gestión de memoriadel software desarrollado, concluyendo que no se produce ninguna fuga de memoria causadapor el código implementado.

Implementar varias mejoras (ID 013)

A. Mejorar la representación gráfica del flujo de diseño.

Con el objetivo de que la interfaz gráfica principal sea más intuitiva para el diseñador seproponen los siguientes cambios:

Mostrar en todo momento los pasos que conforman el flujo de diseño en una lis-ta, indicando siempre en qué paso del flujo de diseño se encuentra el diseñador encada momento. De esta forma se sustituye el contenedor hasta ahora utilizado (QTool-

Box) por el contenedor QStackedWidget, incluyendo una lista en la parte izquierda quemuestre los pasos del flujo de diseño.

Añadir iconos a algunos botones del flujo de diseño, en concreto a todos aquellosque permitan abrir el explorador para seleccionar un archivo y aquellos que permitanañadir o eliminar un elemento de una lista.

Añadir un menú contextual que permita eliminar los elementos seleccionados enaquellas listas o tablas que lo necesiten.

98

Permitir al diseñador seleccionar los valores de los datos part y board entre aquellosque sean compatibles con esta herramienta, de forma que no los tenga que introducirél manualmente.

El resultado tras la implementación de estas mejoras se muestra en la Figura 5.10. Comose puede observar, el flujo de diseño queda más limpio e intuitivo, dejando mayor espaciopara las interfaces propias de cada uno de los pasos del flujo de diseño.

Figura 5.10: Interfaz gráfica principal de la herramienta HDADR tras aplicar varias mejoras.

B. Mejorar la lectura de los archivos XML que contienen la información de los recursoshardware de las FPGAS.

Hasta ahora la lectura del fichero XML la realiza la clase FloorplanGUI de la capa depresentación, por lo que se pretende adaptar este aspecto al modelo presentación-dominio-persistencia. Para ello se añaden en primer lugar las siguientes clases a la capa de domi-nio:

Site. Esta clase contiene toda la información que se necesita sobre un determinadorecurso hardware (nombre, tipo, etc.).

Board. Contiene el nombre de la placa, el número de filas y columnas de recursoshardware que contiene la FPGA, y un vector con todos los recursos hardware de la

99

FPGA (es decir, un vector de objetos Site).

En la capa de presentación se añade la clase BoardXML, encargada de leer el ficheroXML generado que contiene información sobre la placa y sobre los recursos hardware de laFPGA y de añadir toda esta información a un objeto Board. Este mismo objeto de tipo Boardserá después interpretado por la capa de presentación para representar los recursos de formagráfica. Los cambios realizados en esta necesaria actualización de la arquitectura software semuestra en la Figura 5.11.

Por último, mencionar que se cambia el color del fondo en la representación de losrecursos hardware a negro para facilitar la visibilidad de éstos y hacer así el floorplanning

más cómodo al diseñador.

Añadir nuevas funcionalidades al flujo de diseño (ID 012)

El último elemento de este sprint backlog consiste en incluir varias opciones al flujo dediseño para que el diseñador tenga más control sobre lo que se está haciendo.

A. Implementar la selección del valor de las propiedades RESET_AFTER_RECONFIG y SNAP-

PING_MODE a la hora de crear una partición.

En primer lugar se añade la posibilidad de que el diseñador decida el valor de las siguientespropiedades para cada nueva partición que se cree:

RESET_AFTER_RECONFIG. Después de reconfigurar una partición, el módulo reconfigura-ble que se ha implementado necesita comenzar en un estado inicial que sea predecible.Al activar esta opción se realizará un reset local al módulo de forma automática unavez finalizada la reconfiguración. En caso de no activar esta opción, el diseñador sehace responsable de programar este reset él mismo.

SNAPPING_MODE. Al activar esta opción se ajustará automáticamente la zona de la FPGA

asignada a una partición reconfigurable para que cumpla con los requisitos estableci-dos por Xilinx (si fuese necesario).

Las decisiones que tome el usuario serán trasladadas al archivo design.tcl para que losscripts puedan interpretarlas a la hora de crear las particiones reconfigurables. Para podertrasladar esta decisión será necesario modificar la estructura de datos rmGroup, añadiendoesta nueva propiedad a cada una de las particiones que se creen.

Ambas opciones aparecerán activadas por defecto en el flujo de diseño.

B. Implementar la posibilidad de comprimir cada uno de los bitstreams que se vayan agenerar aplicando la compresión de Xilinx.

Para hacer posible que el diseñador pueda decidir si aplicar la compresión de Xilinx o no acada uno de los bitstreams que se vayan a generar es necesario añadir un nuevo paso al flujode diseño de la herramienta HDADR. En este último paso del flujo (llamado «Bitstreams»)

100

PersistenciaDominio

GenDesignTCL

-partitions 0..* -modules0..*

-configurations

0..*

Presentación

MainWindow

PartitionsGUI

GeneralInfoGUI

StaticPartGUI

ModulesGUI

Design


ConfigurationsGUI

-mainDesign

1



ProgramGUI

-selectedOption1

ProgramUserAppGUI

ProgramFPGA

ExportTovivadoSDK

DesignXML

GenProgram TCL

GenXMDTCL

GenDeployMK

BoardXML

+readBoard()-readBoardAttrs()-readSiteAttrs()

Board

-name-rows-cols

+Board()+loadFromXML()+addSite()+getName()+getRows()+getCols()+getNumOfSites()+getSiteAt()+getSites()+setName()+setRows()+setCols()

Site

-name-type-clockRegion-rpmX-rpmY

+Site()+getName()+getType()+getClockRegion()+getRPMX()+getRPMY()+setName()+setType()+setClockRegion()+setRPMX()+setRPMY()

-sites

0..*

-board 1

FloorplanGUI

Figura 5.11: Diagrama de clases de la iteración 4 (tercera actualización).

se le mostrará al diseñador el listado de configuraciones que se van a generar y éste podráelegir a qué bitstreams quiere aplicar la compresión. El listado de configuraciones incluiráaquellas definidas por el usuario y la configuración reference y blanking si proceden.

Al igual que en el caso anterior, la decisión que tome el usuario sobre cada una de las con-figuraciones se traslada al archivo design.tcl para ser posteriormente interpretada por losscripts. Destacar que es necesario modificar la estructura cfgGroup, añadiendo esta nueva

101


ReconfigPartition Se actualiza la prueba añadiendolas opciones RESET_AFTER_RECONFIG ySNAPPING_MODE.

ReconfigPartition 100 %

DesignSe actualiza la prueba de la claseDesign para comprobar elfuncionamiento de la opción quepermite aplicar la compresión deXilinx a las configuracionesreference y blanking.

Design 95.51 %GenDesignTCL 100 %DesignXML 99.53 %

Configuration Se actualiza la prueba de esta cla-se para comprobar el funcionamien-to de la opción que permite aplicar lacompresión de Xilinx.

Configuration 100 %

Site Se crea la prueba para esta clase,comprobando el funcionamiento detodos los constructores y el acceso ymodificación de los atributos.

Site 100 %

BoardSe crea la prueba que comprueba elfuncionamiento de todos losconstructores y el acceso ymodificación de los atributos.Además, se verifica que la carga deuna placa a partir de un fichero XMLse realiza de forma correcta (paraesto se hace uso de la claseBoardXML de la capa depersistencia).

Board 100 %BoardXML 100 %

Cuadro 5.12: Resultado de las pruebas unitarias de la iteración 4 (elementos ID 013/012).

propiedad a cada una de las configuraciones que se creen. Esta opción aparecerá deshabili-tada por defecto.

C. Pruebas.

Una vez que se han implementado las dos funcionalidades se actualizan las pruebasunitarias de las clases de la capa de dominio y de persistencia que se han creado o se hanvisto modificadas hasta ahora. El detalle de las pruebas junto con la cobertura obtenida semuestran en el Cuadro 5.12.

Después se realizan varias pruebas de caja negra a la herramienta implementando va-rios diseños con distintos valores en las tres propiedades que se han añadido al flujo. Todosestos diseños se generan correctamente, aplicando en cada momento las decisiones del dise-ñador.

102


Finalizado todo el trabajo relativo a esta iteración se reúne el equipo Scrum para valorarlos resultados. Al producto entregable de la anterior iteración se le añade la posibilidad deque el diseñador utilice una aplicación creada por él para gestionar la reconfiguración dela FPGA, la posibilidad de recuperar la información de un diseño generado anteriormente alabrir de nuevo la herramienta HDADR, una interfaz gráfica principal mejorada, y la capacidadde determinar el valor de propiedades importantes a la hora de crear nuevas particiones yconfiguraciones.

En esta reunión se acepta todo el trabajo realizado hasta el momento y el product ma-

nager propone una serie de nuevas funcionalidades que realizar en la siguiente iteración.Tras añadir estas nuevas funcionalidades, el product backlog resultante se muestra en la Ta-bla 5.13.

ID Descripción Prioridad008 Proporcionar al diseñador la opción de generar una imagen

de arranque para una tarjeta SD (Zynq Boot Image) a partirde un diseño generado.

Media

014 Mostrar al diseñador como ocupadas aquellas zonas de laFPGA que ya fueron seleccionadas para implementar otrasparticiones anteriores, impidiendo que pueda seleccionar re-cursos hardware que ya fueron seleccionados antes comoparte de una partición anterior. Además, al seleccionar unárea de la FPGA, mostrar el listado de recursos selecciona-dos agrupados por tipo para que el diseñador pueda conocerla cantidad de recursos de cada tipo que ha seleccionado deforma rápida.

Media

015 En el gestor de la reconfiguración, comprobar que las di-recciones de memoria donde cargar los bitstreams parcialesintroducidas por el usuario están dentro del rango permitidopara evitar errores.

Media

016 Permitir al usuario poder volver hacia atrás en el flujo dediseño para modificar la información introducida.

Media

017 Ofrecer una versión en inglés de la herramienta (internacio-nalización de la herramienta).

Media


5.3.5 Iteración 5

En el Cuadro 5.14 se muestran los elementos del product backlog seleccionados por elequipo Scrum que se realizarán en esta iteración, incluyendo las tareas que se han identifica-do por el equipo de desarrollo para cada uno de estos elementos.

103


014Representar las particionesanteriores en el selector deárea y mejorar lavisualización del listado delos recursos hardwareseleccionados.

Estudiar cómo desarrollar las funcionalidadesrequeridas.Implementación y pruebas.

015Comprobar que lasdirecciones de memoriaintroducias por el usuarioson válidas.

Estudiar cómo desarrollar la funcionalidad.Implementación y pruebas.

008Permitir generar la imagende arranque para la tarjetaSD.

Estudiar cómo desarrollar la funcionalidad.Prototipado de la GUI y actualización del di-seño software.Implementación y pruebas.

016Permitir al usuario podervolver hacia atrás en elflujo de diseño.

Estudiar cómo desarrollar la funcionalidad re-querida.Implementación y pruebas.

017Ofrecer una versión eninglés de la herramienta.

Estudiar cómo desarrollar la funcionalidad.Implementación y pruebas.


Representar las particiones anteriores en el selector de área y mejorar la visualizacióndel listado de los recursos hardware seleccionados (ID 014)

Cuando el diseñador selecciona la zona de la FPGA donde se ubicará una partición recon-figurable, los recursos de esta zona no pueden ser seleccionados posteriormente para formarparte de otra partición reconfigurable. Para evitar los posibles errores que se puedan come-ter en este aspecto, el selector de área de la herramienta HDADR mostrará como ocupadosaquellos recursos hardware que ya fueron seleccionados previamente para formar parte deotras particiones, impidiendo además que el diseñador pueda seleccionar estos recursos.

Por otra parte, cuando el diseñador selecciona los recursos hardware que ocupará unapartición determinada se muestra una lista con el nombre de cada uno de los recursos quese han seleccionado. Esto en la realidad no es práctico, ya que para una partición de tamañonormal se pueden seleccionar alrededor de unos 1000 recursos. Por lo tanto, en segundo lugarse propone mejorar la visualización de esta lista agrupando los recursos seleccionadospor tipo, de forma que el diseñador pueda ver de forma inmediata el número de recursos decada tipo que ha seleccionado antes de aceptar y continuar con la definición de la particiónreconfigurable.

A. Estudiar cómo desarrollar las funcionalidades requeridas.

Cuando el usuario selecciona el área de la FPGA para una partición reconfigurable utilizan-

104

do el selector de área y acepta esta selección, el selector de área debe mantener un listadocon todos los recursos hardware que se acaban de seleccionar para deshabilitarlos en ca-so de que la partición se añada finalmente al diseño. Si el diseñador agrega la partición aldiseño desde la interfaz gráfica principal de la herramienta HDADR, esta interfaz avisará alselector de área de que la partición ha sido añadida y, por tanto, el selector deshabilitarálos recursos para que no puedan volver a ser seleccionados. Además, si posteriormente eldiseñador decide añadir una nueva partición, al abrir el selector de área de nuevo se le mos-trarán los recursos deshabilitados con una transparencia roja para avisarle de que esosrecursos ya han sido seleccionados previamente.

Respecto a la mejora de la visualización del listado de los recursos hardware selecciona-dos, se sustituirá la estructura de lista por una vista de árbol. En lugar de añadir uno auno los recursos hardware a la lista, se procesarán agrupándolos por tipo y calculandoel número de recursos de cada tipo que se han seleccionado. Toda esta información seañadirá a la vista de árbol, haciendo así más útil este visor de los recursos seleccionados.


Una vez que se ha estudiado cómo desarrollar las nuevas funcionalidades se procede a laimplementación de las mismas. En este caso no es necesario actualizar el diagrama de clasesya que no se añade ninguna clase nueva en la herramienta, únicamente se añade a la claseFloorplanGUI un nuevo atributo que permite recordar la última selección de recursos querealizó el diseñador y un método que permite avisar a esta clase desde fuera para que desha-bilite los recursos de la última selección. Por último, y como ya se comentó anteriormente,se utiliza una vista de árbol en el listado de los recursos hardware y se modifica el algoritmoque permite añadir los recursos seleccionados a esta vista. En la Figura 5.12 se muestra elresultado de la implementación.

Como no se han añadido nuevas clases a la capa de dominio y persistencia, en este casosolo se realizan varias pruebas de caja negra para comprobar el correcto funcionamientode la interfaz gráfica.

Comprobar que las direcciones de memoria introducidas por el usuario son válidas (ID015)

Cuando se utiliza el gestor de la reconfiguración para cargar en la memoria de la FPGA

una aplicación que se encargue de la reconfiguración, el diseñador tiene la opción de cargaren memoria también los bitstreams que esta aplicación vaya a utilizar. En este caso, paracada bitstream el diseñador tiene que especificar la dirección de memoria donde se cargará.Comprobar que la dirección introducida es correcta es muy importante, ya que si la direcciónno se encuentra dentro del rango de direcciones correcto no se cargará el bitstream en lamemoria del dispositivo. Por tanto, para evitar estos posibles errores, la herramienta debecomprobar que las direcciones introducidas por el diseñador son válidas.

105

Figura 5.12: Actualización del selector de área (floorplanning).

A. Estudiar cómo desarrollar la funcionalidad.

En primer lugar es importante establecer de dónde se obtendrá el rango de direcciones de lamemoria del dispositivo donde se podrán cargar los bitstreams. Dado que zipFactory utilizael componente axi_memory_read_driver para leer los bitstreams parciales de memoria, elrango de direcciones que se le asocia a este componente dentro del diseño de bloques seráel que el diseñador pueda utilizar para cargar los bitstreams en la memoria del dispositivo.En el Listado 5.20 se puede observar la línea del archivo que contiene el diseño de bloquesdonde se asocia el rango de direcciones [0x00000000, 0x1FFFFFFF] al componente axi_-memory_read_driver.

create_bd_addr_seg -range 0x20000000 -offset 0x0 [get_bd_addr_spaces axi_read_memory_driver_0/m_axi]

[get_bd_addr_segs processing_system7_0/S_AXI_HP0/HP0_DDR_LOWOCM]

SEG_processing_system7_0_HP0_DDR_LOWOCM

Listado 5.20: Línea del archivo que contiene el diseño de bloques donde se establece el rangode direcciones del componente axi_memory_read_driver.

Por lo tanto, la herramienta HDADR deberá leer el archivo que contiene el diseño debloques para obtener el rango de direcciones válido, teniendo en cuenta que el diseñadorespecifica cuál es este archivo en el primer paso del flujo de diseño. En el caso de que se

106

abra el gestor de la reconfiguración y no se haya especificado este archivo o se produzca unerror al leerlo, se le mostrará un mensaje al diseñador avisándole de que la validez de lasdirecciones de memoria que introduzca no será comprobada.


En este elemento del sprint backlog tampoco se creará ninguna clase nueva en ningunade las tres capas del software. Solo es necesario modificar la clase ProgramUserAppGUIpara leer el archivo con el diseño de bloques al iniciarse, obteniendo el rango de direccionesde memoria donde se podrán cargar los bitstreams parciales elegidos por el diseñador. Unavez realizada la implementación de la funcionalidad se realizan una serie de pruebas, com-probando que si se introduce una dirección fuera del rango válido la herramienta muestra unerror y no deja añadir el bitstream a la lista de los bitstreams parciales que serán cargados enla memoria de la FPGA.

Permitir generar la imagen de arranque para la tarjeta SD (ID 008)

Una funcionalidad importante que debe tener la herramienta HDADR es generar una ima-gen de arranque que permita iniciar la FPGA desde una tarjeta SD. Esta imagen dearranque programará la FPGA con uno de los bitstreams generados previamente con la herra-mienta y permitirá al diseñador cargar una aplicación creada con Vivado SDK en la memoriadel dispositivo para que se ejecute en el procesador de la FPGA.


Para generar la imagen de arranque es necesario que el diseñador especifique la aplicacióny el bitstream completo que se han de añadir a esta imagen. Adicionalmente, el diseñadordebe indicar el directorio de salida donde se copiará la imagen de arranque (normalmente seseleccionará la raíz de la tarjeta SD que se utilizará en la FPGA). El proceso que se ha deseguir dentro de la herramienta para crear la imagen es el siguiente:

1. En primer lugar se debe crear el FSBL (First Stage Boot Loader), responsable decargar el bitstream completo en la FPGA y de configurar el sistema de procesamientode Zynq. La creación del FSBL, que se realiza desde Vivado SDK, requiere en primerlugar cargar la definición hardware del diseño generado previamente con la herramien-ta HDADR. Una vez cargada esta definición, la herramienta del fabricante se encargaráde crear el FSBL para el hardware en cuestión.

2. Después se utiliza la herramienta bootgen para la creación de la imagen de arranque,ya que se encarga de construir la cabecera de arranque y de procesar todos los datosde entrada (FSBL, aplicaciones y bitstreams) para añadirlos a la imagen de arranque.La herramienta bootgen toma como entrada un archivo .bif en el que se indica laestructura y los datos a incluir en la imagen de arranque. Un ejemplo de estearchivo se muestra en el Listado 5.21.

107

3. Creado el archivo .bif, el siguiente paso es ejecutar la herramienta bootgen pasán-dole este archivo y el part de la FPGA a la que va destinada la imagen de arranque,generando así la imagen de arranque (boot.bin). Finalmente se moverá esta imagencreada al directorio de salida que el diseñador especificó en su momento.

image:

{

[bootloader]fsbl.elf

bitstream.bit

app.elf

}

Listado 5.21: Archivo .bif que se utiliza para generar la imagen de aranque a través de laherramienta bootgen.


Al igual que en el resto de iteraciones, una vez que se conoce cómo desarrollar la funcio-nalidad se realiza el prototipado de la interfaz gráfica de la ventana que permitirá al diseñadorgenerar la imagen de arranque. El prototipo resultante se encuentra en el Apéndice A.

Respecto al diseño software, se actualiza el diagrama de clases para dar cabida a la nuevafuncionalidad. Todo el proceso de generación de la imagen de arranque se llevará a caboa través de un archivo Makefile (bootSD.mk), por lo que será necesario añadir una nuevaclase a la capa de persistencia que se encargue de la generación de este archivo. En concreto,los cambios que se realizan son los siguientes:

1. Se añade la clase GenBootSDMK a la capa de persistencia. Esta clase se encargará degenerar el archivo bootSD.mk a partir de una plantilla y de los datos introducidos porel diseñador.

2. La clase ProgramFPGA de la capa de dominio se modifica, añadiendo el atributo part

y el método generateBootSDMK().

3. Se añade la clase CreateBootImageSD a la capa de presentación, clase encargada dela representación gráfica de la ventana que permitirá al usuario crear la imagen dearranque.

La Figura 5.13 muestra cómo queda el diagrama de clases tras aplicar esta actualiación.

C. Implementación y pruebas.

La siguiente tarea de este ítem del sprint backlog consiste en realizar la implementacióndel diseño software descrito anteriormente. Una vez que el usuario haya especificado la apli-cación, el bitstream y el directorio de salida, al pulsar el botón «Crear imagen» se generaráel archivo Makefile que permitirá la ejecución de todo el proceso descrito anteriormente. Laplantilla a partir de la cual se genera este archivo se muestra en el Listado 5.22.

108

PersistenciaDominio

GenDesignTCL

-partitions 0..* -modules0..*

-configurations

0..*

Presentación

MainWindow

PartitionsGUI

GeneralInfoGUI

StaticPartGUI

ModulesGUI

Design


ConfigurationsGUI

-mainDesign 1



ProgramGUI

-selectedOption1

ProgramUserAppGUI

ProgramFPGA

-part-bitstreamsDir-bitstream-partialBitstreams-wrapperHWPlatfform-applications

+ProgramFPGA()+generateProgramTCL()+generateXMDTCL()+generateDeployMK()+generateBootSDMK()+setBitstream()+getBitstreamsDir()+getBitstream()+addPartialBitstream()+addApplication()+setWrapperHWPlatform()+getPartialBitstreams()+getWrapperHWPlatform()+getApplications()+setPart()+getPart()

ExportTovivadoSDK

DesignXML

GenProgram TCL

GenXMDTCL

GenDeployMK

BoardXML

BoardSite

-sites

0..*

-board 1

FloorplanGUI

GenBootSDMK

+generate()

BitstreamsGUI

CreateBootImageSD


Respecto a las pruebas, se ejecutan una serie de pruebas unitarias para comprobarel funcionamiento de las clases ProgramFPGA y GenBootSDMK. En el Cuadro 5.15 se

109


#XILINX_HOME=/opt/Xilinx

#XILINX_VERSION=2015.4

#BOOTGEN=$(XILINX_HOME)/SDK/$(XILINX_VERSION)/bin/bootgen

BOOTGEN=bootgen

BOARD_PART={{PART}}

BIT_PATH={{FULL_BITSTREAM}}

APP_PATH={{USER_APP}}

all: boot.bin

%.bin: %.bif bitstream.bit app.elf

$(BOOTGEN) -p $(BOARD_PART) -image $< -o i $@

bitstream.bit:

cp $(BIT_PATH) bitstream.bit

app.elf:

cp $(APP_PATH) app.elf

clean:

$(RM) *~ *.bit *.bin app.elf

Listado 5.22: Plantilla utilizada para generar el archivo bootSD.mk.

muestra más información sobre las pruebas realizadas, así como la cobertura del códigoalcanzada.

Después se realizan varias pruebas de caja negra sobre la interfaz gráfica desarrolladaen este caso, variando el valor de las entradas que se introducen en la herramienta HDADR através de esta interfaz gráfica y observando que las salidas (el archivo boot.mk y la imagende arranque) son correctas. Finalmente se realiza un análisis de memoria, buscando losposibles memory leaks que se puedan producir en el nuevo software desarrollado. El informeobtenido con Valgrind no muestra ninguna fuga de memoria causada explícitamente por elcódigo desarrollado en este ítem del sprint backlog.


ProgramFPGA

Se actualiza la prueba de la claseProgramFPGA para comprobar lacorrecta generación del archivoboot.mk. Al generar este archivo seutiliza de forma implícita la claseGenBootSDMK.

ProgramFPGA 95.08 %GenProgramTCL 100 %GenXMDTCL 100 %GenDeployMK 100 %GenBootSDMK 100 %


110

Permitir al usuario poder volver hacia atrás en el flujo de diseño (ID 016)

Hasta ahora al diseñador no se le permitía modificar la información que ya había introdu-cido en pasos del flujo de diseño anteriores, e incluso tampoco podía modificar o eliminaruna partición, módulo o configuración una vez que ya había sido añadida al diseño. El obje-tivo que se persigue en esta ocasión es modificar la herramienta para que toda la informaciónpueda ser editada hasta el momento en el que el usuario inicie el proceso de generación deldiseño, de forma que el diseñador pueda volver hacia atrás en el flujo de diseño y corregir lainformación ya introducida en caso de ser necesario.

A. Estudiar cómo desarrollar la funcionalidad requerida.

Habilitar la posibilidad de que el diseñador pueda volver hacia atrás en el flujo implicarealizar cambios en todas las clases encargadas de la representación gráfica del flujo de dise-ño, si bien no será necesario modificar aquellas clases de la capa de dominio y persistencia.La idea que se propone es que todos los datos de un diseño se puedan modificar a lo largodel flujo excepto dos: el part y el board de la FPGA. Estos datos se deshabilitarán una vezintroducidos para evitar su modificación ya que la herramienta necesita conocer qué FPGA seva a utilizar para, entre otras cosas, saber qué placa cargar en el selector de área. El resto dedatos sí que serán modificables, y en el caso de las particiones, módulos o configuraciones sepermitirá eliminar las ya añadidas y añadir nuevas en cualquier punto del flujo de diseño.

Para hacer todo esto la idea reside en no añadir todos los datos introducidos por el diseña-dor al objeto que representa el diseño en la herramienta (mainDesign) hasta que no se quieragenerar el diseño. En el caso de que se produzca algún error durante la generación deldiseño, se ofrecerá la posibilidad de modificar todos los datos introducidos para corregir po-sibles errores y, al generar el diseño de nuevo, se sustituirá el diseño anterior en memoria poruno nuevo que contenga todos los datos actualizados.


Una vez que se conoce cómo desarrollar la función de este ítem del sprint backlog seprocede a la implementación de los cambios necesarios. Mencionar el caso especial queocurre cuando se elimina una partición y existen módulos y configuraciones que dependende ésta, caso que requiere analizar la tabla de módulos y la de configuraciones buscandoaquellos elementos que dependan de la partición en cuestión y que también tendrán queser eliminados. En caso de que se produzca esta situación se informará al diseñador de losmódulos y configuraciones que se eliminarán, ejecutando la operación únicamente cuandoel diseñador confirme el borrado de éstos. Lo mismo ocurre en el caso de eliminar unmódulo reconfigurable, ya que pueden existir configuraciones que dependan de él.

Respecto a las pruebas, al no modificarse ninguna clase en las capas de dominio y depersistencia, se procede directamente a la ejecución de la interfaz gráfica para comprobarel correcto funcionamiento del flujo. En estas pruebas se modifican todos los elementos de

111

un diseño antes de proceder a generarlo, se introducen datos erróneos para que la generaciónfalle y comprobar que se permite modificar los datos de nuevo y volver a generar el diseño,etc.

Ofrecer una versión en inglés de la herramienta (ID 017)

En este último elemento de esta iteración se pretende internacionalizar la herramientapara que soporte otros idiomas. La idea es ofrecer la herramienta HDADR en castellano einglés utilizando un sistema de internacionalización que se pueda extender a otros idiomasfácilmente.


El framework Qt ofrece un sistema de traducción sencillo para aplicaciones basadas enQt que consta de los siguientes pasos:

1. En primer lugar es necesario indicar las cadenas de texto que se desean traducirdentro del código del programa utilizando la función tr(). Esta función toma comoentrada una cadena de texto y devuelve el resultado de la traducción basándose en elobjeto QTranslator que tenga asociado el programa en ejecución. Esta traducción seobtiene de un archivo binario que se verá más adelante.

2. Una vez que se ha utilizado la función tr() dentro del código para todas aquellas cade-nas de texto que se desean traducir, se ejecuta el comando lupdate. Este comando leetodas las llamadas a la función tr() dentro del código y genera un fichero que contieneuna entrada para cada cadena de texto y su traducción a otro idioma (inicialmente va-cía). En el caso de que se quiera traducir la aplicación a varios idiomas, será necesariogenerar tantos ficheros como idiomas se vayan a utilizar.

3. Después se utiliza la herramienta Qt Linguist para trabajar con este fichero generadopor el comando lupdate. En esta herramienta se muestra de forma gráfica un listadode todas las cadenas de texto que se quieren traducir y se permite añadir la traduccióna cada una de éstas de forma rápida y sencilla.

4. Traducidas todas las cadenas de texto, el siguiente paso es convertir el archivo gene-rado por lupdate en un archivo binario que pueda ser leído en tiempo de ejecuciónpor la aplicación. Esto se realiza utilizando el comando lrelease, el cual lee el archivoque contiene las traducciones y lo convierte a un archivo binario (*.qm).

5. Finalmente es necesario crear un objeto QTranslator dentro de la aplicación, car-gando el archivo binario que contiene las traducciones (*.qm). Este objeto después seasociará al programa mediante el método installTranslator(). A partir de ese momento,toda llamada a la función tr() dentro del programa devolverá la traducción de la cadenade texto que se le pase como argumento (si es que se encuentra dentro del archivo).

112


Estudiada cómo se realiza la traducción de una aplicación en Qt se implementa esta fun-cionalidad en la herramienta HDADR, realizando la traducción de todas aquellas cadenas detexto que se representan en la interfaz gráfica. Una vez realizada la traducción, se crea un pe-queño diálogo que permite seleccionar al usuario el idioma de la aplicación al principiode ésta (Figura 5.14). En el caso de que el usuario cierre el diálogo y no seleccione ningúnidioma la aplicación se cargará en el idioma predeterminado (castellano).

Figura 5.14: Selector de idioma que se ejecuta al inicio de la herramienta.

Respecto a las pruebas, al no crearse ninguna nueva clase en la capas de dominio y depersistencia, se ejecuta la herramienta para comprobar que la traducción de la inter-faz gráfica se realiza de forma correcta. También se realiza un análisis de los posiblesmemory leaks que pueda causar la herramienta HDADR utilizando Valgrind. El informe deValgrind que se obtiene tras analizar la ejecución de la herramienta no observa ninguna fugade memoria causada explícitamente por el código de la herramienta.


Una vez finalizado todo el trabajo de esta iteración se vuelve a reunir el equipo Scrumpara valorar los resultados conseguidos. Como producto entregable se obtiene la herramientaHDADR con las nuevas funcionalidades implementadas a lo largo de esta iteración: mejorasen el selector de área y en el gestor de reconfiguración, capacidad de generar una imagen dearranque para tarjeta SD, posibilidad de volver hacia atrás en el flujo de diseño y, finalmente,internacionalización de la herramienta.

En esta reunión se acepta todo el trabajo realizado y no se proponen nuevas funciona-lidades que añadir a la herramienta. Dado que todos los elementos del product backlog hansido realizados, el desarrollo se da por finalizado.

113

Capítulo 6

Resultados obtenidos

U NA vez finalizado el desarrollo del trabajo se muestran los resultados obtenidos, des-tacando las ventajas más importantes que ofrece la herramienta HDADR y realizando

una comparación entre esta herramienta y Vivado. En esta comparación se contrastan en pri-mer lugar los flujos de diseño de ambas herramientas y después se realiza un caso de estudioen el que se comparan los tiempos de generación de un diseño, los consumos de memoria yla interacción que necesita hacer el diseñador con cada una de las dos herramientas.

6.1 Herramienta HDADR

Como resultado del desarollo de este TFG se obtiene la herramienta HDADR, cuya prin-cipal ventaja es el nuevo flujo de diseño para sistemas dinámicamente reconfigurables queofrece. Esta herramienta permite realizar las siguientes tareas:

Definir y generar un diseño dinámicamente reconfigurable de forma fácil y cómodagracias a su flujo de diseño.

Exportar la descripción del hardware a Vivado SDK para poder desarrollar softwaresobre un diseño generado con la herramienta HDADR.

Gestionar la reconfiguración de la FPGA, tanto desde la propia herramienta como desdeuna aplicación específica creada por el diseñador.

Ofrecer la posibilidad de crear una imagen de arranque para una tarjeta SD, de formaque el diseñador pueda utilizar uno de los bitstreams generados y una aplicación creadapor él para iniciar la FPGA desde la tarjeta SD.

Destacar que todas estas tareas están unificadas en la misma herramienta, al contrarioque en el caso de las herramientas de Xilinx donde estas tareas se reparten entre Vivado yVivado SDK.

Otra ventaja importante que ofrece HDADR es la posibilidad de cargar un diseño gene-rado anteriormente con la herramienta. Al cargar un diseño anterior se puede ampliar estediseño añadiéndole nuevos módulos y configuraciones o, por otra parte, utilizar este diseñocon el resto de funciones que ofrece la herramienta (exportar el hardware del diseño a VivadoSDK, gestionar la reconfiguración de la FPGA, etc.).

115

6.2 Comparación entre HDADR y Vivado6.2.1 Comparación de los flujos de diseño

En la Figura 6.1 se muestra una comparativa entre el flujo de diseño de HDADR y el flujo deVivado donde se pueden observar las tareas que han de ser realizadas por el diseñador en cadacaso. En ambos casos el flujo de diseño para la generación de un sistema reconfigurablecomienza una vez que ya se tienen definidos todos los componentes que forman partedel sistema, en concreto:

El archivo que contiene el diseño de bloques del sistema.

El resto de componentes que, junto con el diseño de bloques, componen la parte está-tica del diseño.

Los módulos que se implementarán dentro de las particiones reconfigurables del dise-ño.

Una vez que el diseñador dispone de todos estos componentes puede comenzar el flujo dediseño en cualquiera de las dos herramientas. Como se puede observar en la figura mencio-nada anteriormente, el flujo de diseño que ofrece HDADR es mucho más liviano que el deVivado, ya que en el primer caso el diseñador solo tiene que establecer todas las propiedadesdel diseño a través de la interfaz gráfica de HDADR y la herramienta se encarga de generarautomáticamente el diseño. En caso de utilizar Vivado, el diseñador tiene que seguir los tre-ce pasos que se enumeran en la figura ejecutando uno a uno los comandos que aparecen, locual requiere de bastante más dedicación y atención por parte del diseñador y conlleva a unincremento de los puntos de error.

A la hora de extender un diseño existente también resulta más cómodo el flujo de la he-rramienta HDADR, ya que bastaría con añadir la información de los nuevos módulos y con-figuraciones que se quieren obtener y generar parcialmente el diseño. Realizar esta mismafunción con Vivado supone para el diseñador tener que ejecutar manualmente todos los co-mandos de las tareas que aparecen etiquetadas en la figura, por lo que en este caso el flujode diseño de HDADR vuelve a ser más simple que el que ofrece Vivado.

116

Figura 6.1: Comparación entre el flujo de diseño de HDADR y el de Vivado.117

6.2.2 Caso de estudio

A continuación se estudian las diferencias que existen entre HDADR y Vivado en cuantoal consumo de recursos y a la interacción del usuario con la herramienta. Para ello serealiza un caso de estudio en el que se genera uno de los diseños proporcionados por Xilinxen los tutoriales sobre reconfiguración parcial.

Los datos de la máquina sobre la que se realiza este caso de estudio son:

Procesador Intel Core i5-430M. 4 núcleos a 2.26GHz, 3MB de caché de tercel nivel.

8GB de memoria RAM.

Disco duro a 5400rpm.

Detalles sobre el diseño reconfigurable utilizado

El diseño que se utiliza en este caso de estudio está compuesto por parte estática y dosparticiones reconfigurables llamadas reconfig_addsub y reconfig_leds. Las propiedades decada una de estas particiones son las siguientes:

Partición reconfig_addsub.

• Recursos hardware: SLICE_X24Y36:SLICE_X27Y39.

• Propiedades RESET_AFTER_RECONFIG y SNAPPING_MODE desactivadas.

Partición reconfig_leds.

• Recursos hardware: SLICE_X16Y20:SLICE_X19Y24.

• Propiedades RESET_AFTER_RECONFIG y SNAPPING_MODE activadas.

Para la partición reconfig_addsub se proporcionan dos módulos reconfigurables: unsumador y un restador. Para la partición reconfig_leds también se proporcionan dos mó-dulos reconfigurables: uno que desplaza los leds de la placa de prototipado hacia la derechay otro que los desplaza hacia la izquierda.

Con el objetivo de generar los bitstreams parciales de todos estos módulos se implemen-tan dos configuraciones: una con el módulo sumador y el módulo que desplaza los ledshacia la izquierda, y otra con el módulo restador y el módulo que desplaza los leds hacia laderecha. Adicionalmente también se implementa la configuración blanking.

Por último, para analizar la escalabilidad de ambas herramientas, una vez generado eldiseño anterior se crean dos nuevos módulos: un multiplicador para la partición reconfig_-

addsub y un módulo que mantiene encendidos todos los leds para la partición reconfig_leds.Estos módulos se añaden al diseño que se acaba de generar y se crea una nueva configuracióncon ellos. Después se procede a la generación de los nuevos componentes del diseño.

118

Parámetros a medir en el caso de estudio

En este caso de estudio se monitorizan varios parámetros sobre el consumo de memo-ria y de CPU de las herramientas y del sistema durante la generación del diseño para despuéscomparar los resultados obtenidos. En concreto, estos parámetros son los siguientes:

Cantidad de memoria física que ocupa el proceso correspondiente a la herramienta.

Consumo global de memoria física. De esta forma se podrá obtener posteriormente elincremento del uso de memoria física que se produce en el sistema durante la ejecuciónde la herramienta.

Cantidad de CPU consumida por el proceso correspondiente a la herramienta.

Consumo global de CPU.

Además, también se monitorizan los eventos del ratón y del teclado que se producencon el objetivo de medir la interacción que tiene que realizar el diseñador con la herramien-ta para poder generar un diseño reconfigurable. En concreto se monitorizan los siguienteseventos de Xlib:

ButtonPress. Evento que se produce en el sistema de ventanas X cuando el usuariopresiona un botón del ratón.

KeyPress. Evento que se produce en el sistema de ventanas X cuando el usuario pre-siona una tecla del teclado.

Análisis de los resultados

1. Generación completa del diseño

En primer lugar se analiza el tiempo que transcurre desde que se inicia la herramientahasta que se obtienen los bitstreams completos y parciales del diseño en cuestión. En estecaso de estudio se obtienen los siguientes tiempos:

HDADR. El tiempo total que lleva generar el diseño es de 18 minutos y 46 segundos,de los cuales solo los primeros 3 minutos y 55 segundos requieren la atención deldiseñador ya que es en este tiempo donde se definen las propiedades del diseño agenerar (el resto de tiempo corresponde a la generación automática del diseño).

Vivado. El tiempo total que lleva generar el diseño es de 41 minutos y 49 segundos.En el caso de esta herramienta todo este tiempo necesita la atención del diseñador yaque la generación del diseño se realiza paso a paso por él. También hay que tener encuenta que en esta prueba todos los pasos y comandos a ejecutar se tienen listadosantes de comenzar con la generación del diseño, por lo que este tiempo puede llegar aser mucho mayor cuando se trate de un diseño completamente nuevo.

119

De estos datos se puede concluir que el tiempo que se emplea en generar un diseñose ve reducido un 53 % aproximadamente. Destacar que esta reducción de tiempo no soloconlleva que los bitstreams del diseño se obtengan antes, sino que también implica que lacantidad de memoria física necesaria para la generación del diseño se libera antes y quela CPU se utiliza durante menos tiempo (con el correspondiente ahorro energético que estosupone).

Por otra parte, la Figura 6.2 muestra el consumo de memoria física de las herramientasdurante su ejecución. Tal y como se indica en la gráfica, es importante destacar que en elcaso de HDADR solo se recoge el consumo de memoria de la propia herramienta y no delas tareas de Vivado que se ejecutan para la generación del diseño. En cambio, en el casode Vivado sí que se refleja el consumo de memoria de todas estas tareas. Aun así se puedeobservar la gran diferencia de consumo de memoria que existe entre las herramientas desdeel momento en que son abiertas.

0

500000

1000000

1500000

2000000

2500000

Consumo de memoria física (KiB)

RES (HDADR: GUI) RES (Vivado: GUI + generación del diseño)

Figura 6.2: Comparación del consumo de memoria física entre HDADR y Vivado.

Dado que los valores de la herramienta HDADR no incluyen el consumo de memoria delas tareas de Vivado que se encargan de generar el diseño, es más correcto monitorizarel incremento del consumo de memoria física que se produce en el sistema desde quese inician las herramientas hasta que se tiene el diseño generado. Los resultados de estamonitorización se muestran en la Figura 6.3, donde se puede observar que en el caso deHDADR se consume menos memoria física y además se tarda menos tiempo en liberar lamemoria utilizada (ya que se tarda menos en generar un diseño).

Respecto al consumo de CPU, en la Figura 6.4 se muestra el consumo global de CPU

del sistema durante la generación del diseño para las dos herramientas, de forma quese pueda valorar el impacto que tiene cada herramienta sobre la CPU en el equipo. Como

120

0

500000

1000000

1500000

2000000

2500000

Incremento del consumo de memoria física durante lageneración de un diseño (KiB)

Incremento con HDADR Incremento con Vivado

Figura 6.3: Comparación del incremento del consumo de memoria física que se produce enel sistema.

se puede observar, el impacto de la herramienta HDADR es muy bajo mientras el diseñadorindica los datos del diseño y aumenta cuando comienza la generación del diseño. Aun así, elconsumo de CPU durante la generación del diseño es más bajo utilizando la herramien-ta HDADR que utilizando Vivado. Además, el proceso de generación termina antes, lo quehace que la CPU esté menos tiempo ocupada con esta tarea.

0

10

20

30

40

50

60

70

80

90

100

HDADR - Uso de CPU global (%)

%CPU (usuario + sistema)

0

10

20

30

40

50

60

70

80

90

100

Vivado - Uso de CPU global (%)

%CPU (usuario + sistema) Media = 57.164% Media = 68.653%

Figura 6.4: Comparación del uso de CPU global que se produce en el sistema.

Por último, en la Figura 6.5 se muestra la interacción que tiene que realizar el diseñadorpara generar el diseño con HDADR y con Vivado. Esta interacción se mide en función de laspulsaciones de ratón y de teclado que el diseñador realiza desde que se inician las herramien-tas hasta que se obtienen los bitstreams del diseño. A pesar de que el diseño que se generaes el mismo, el uso del teclado es muy superior en Vivado debido a que el diseñador tieneque introducir manualmente una gran cantidad de comandos para generar el diseño. Por lo

121

tanto, se concluye que la herramienta HDADR requiere de menor trabajo por parte deldiseñador.

HDADR Vivado0

500

1000

1500

2000

2500

3000

3500

Interacción del usuario con las herramientas

ButtonPress

KeyPress

Figura 6.5: Comparación del trabajo que tiene que realizar el diseñador para generar el mis-mo diseño.

2. Generación parcial del diseño

Tal y como se comentó anteriormente, una vez que finaliza la generación completa del di-seño se añaden dos nuevos módulos y una nueva configuración para analizar las herramientasen el caso de ampliar un diseño ya existente. Los tiempos obtenidos desde que se inicia laherramienta hasta que se obtienen los bitstreams de los nuevos componentes son:

HDADR. El tiempo total que lleva generar parcialmente el diseño es de 5 minutos y46 segundos, de los cuales solo los primeros 52 segundos requieren la atención deldiseñador ya que es en este tiempo cuando se indican los nuevos módulos y configu-raciones.

Vivado. El tiempo que lleva generar parcialmente el diseño es de 12 minutos y 10segundos. Al igual que ocurre cuando se genera el diseño completo, durante todo estetiempo se necesita la atención del diseñador ya que la generación parcial se realizapaso a paso por él.

Como se puede observar se produce una reducción de más del 52 % en el tiempo em-pleado en generar parcialmente el diseño.

La Figura 6.6 muestra el consumo de memoria física de las herramientas durante la gene-ración parcial. Tal y como ocurre en el caso anterior, los datos de HDADR no tienen en cuentael consumo de memoria de las tareas que se ejecutan para generar el diseño. Para poder de-terminar mejor el consumo de memoria total de cada herramienta, la Figura 6.7 muestra el

122

incremento del consumo de memoria física que se produce en el sistema desde que seinician las herramientas hasta que finaliza la generación parcial del diseño. Observando am-bas gráficas se concluye que utilizando HDADR el consumo de memoria física es menor(además de que se tarda menos tiempo en liberar la memoria física necesaria).

0

400000

800000

1200000

1600000

2000000

Consumo de memoria física (KiB) - Generación parcial

RES (HDADR: GUI) RES (Vivado: GUI + generación del diseño)

Figura 6.6: Comparación del consumo de memoria física entre HDADR y Vivado (generaciónparcial).

0

400000

800000

1200000

1600000

Incremento del consumo de memoria física durante lageneración de un diseño (KiB) - Generación parcial

Incremento con HDADR Incremento con Vivado

Figura 6.7: Comparación del incremento del consumo de memoria física que se produce enel sistema (generación parcial).

123

Por otra parte, la Figura 6.8 muestra el consumo global de CPU que ocurre en el sistemadurante la generación parcial del diseño para las dos herramientas, de forma que se puedavalorar el impacto que tiene cada herramienta sobre la CPU. Como se puede observar, elconsumo de CPU durante la generación parcial del diseño es menor en el caso de utilizar laherramienta HDADR.

0

10

20

30

40

50

60

70

80

90

100

HDADR - Uso de CPU global (%) - Generación parcial

%CPU (usuario + sistema)

0

10

20

30

40

50

60

70

80

90

100

Vivado - Uso de CPU global (%) - Generación parcial

%CPU (usuario + sistema) Media = 59.669% Media = 67.653%

Figura 6.8: Comparación del uso de CPU global que se produce en el sistema (generaciónparcial).

Finalmente, la Figura 6.9 muestra la interacción que tiene que realizar el diseñador conlas herramientas para generar parcialmente el diseño. De esta gráfica se concluye que laherramienta HDADR requiere de menor trabajo por parte del diseñador a la hora deañadir nuevos componentes a un diseño ya existente.

HDADR Vivado0

200

400

600

800

1000

1200

1400

1600

Interacción del usuario con las herramientas(generación parcial)

ButtonPress

KeyPress

Figura 6.9: Comparación del trabajo que tiene que realizar el diseñador para generar el mis-mo diseño (generación parcial).

124

Capítulo 7

Conclusiones y trabajo futuro

E N este capítulo se valora si la herramienta desarrollada cumple tanto con el objetivoprincipal como con los objetivos específicos que se establecieron al inicio de este TFG

(Capítulo 2). Además, también se muestra cómo se puede continuar con el trabajo realizadoen este TFG proponiendo nuevas funcionalidades que pueden ser de interés para la herra-mienta HDADR.

7.1 Consecución de los objetivosEn primer lugar, el flujo de diseño creado para la herramienta HDADR es más simple y

liviano que el ofrecido por Vivado, ya que el diseñador solo tiene que introducir los datos deldiseño que desea generar y el diseño se generará automáticamente. La herramienta HDADR

ofrece una interfaz gráfica ligera, sencilla e intuitiva que guía al diseñador a través detodos los pasos de este flujo de diseño. En cada paso del flujo se reunen todos los datosa introducir en distintos grupos con el objetivo de intentar reducir la probabilidad de queel diseñador cometa algún error. Aún así, la herramienta permite volver atrás en el flujode diseño para corregir cualquier dato que se haya introducido erróneamente. Además, elconjunto formado por la herramienta HDADR y el nuevo flujo de diseño ofrece un ahorro detiempo considerable en la generación de un diseño reconfigurable tal y como se muestra enSubsección 6.2.2.

Con todo lo dicho hasta ahora se puede concluir que se cumple con el objetivo generalde este TFG. Para detallar más sobre lo conseguido, a continuación se analiza la consecuciónde cada uno de los objetivos específicos de este TFG:

1. Implementación en la herramienta de un flujo de diseño que facilite al usuario eldiseño de sistemas dinámicamente reconfigurables.

Tal y como se establecía, para implementar el nuevo flujo de diseño era necesarioincluir y adaptar las librerías proporcionadas por el grupo ARCO (módulos hardwarede gestión de la reconfiguración, etc.). Este nuevo flujo de diseño se implementa conéxito en la herramienta HDADR y, además, se cumple con la condición de que losscripts para la automatización del flujo puedan ser ejecutados desde Vivado.

125

2. Desarrollar una herramienta que permita al diseñador definir las áreas reconfi-gurables de la FPGA.

El diseñador puede abrir el «Selector de área» cuando se encuentra definiendo laspropiedades de una partición reconfigurable en la herramienta HDADR. Este selectormuestra al diseñador una representación gráfica de la disposición de los recursos dela FPGA, permitiéndole seleccionar el área que ocupará la partición reconfigurable encuestión. Dentro de esta representación gráfica, si el diseñador mantiene el cursor so-bre un recurso hardware se muestra la información relativa a dicho recurso (nombre,tipo y zona de reloj). Además, se indicarán las áreas de la FPGA que ya estén ocu-padas por otras particiones definidas previamente, impidiendo que el diseñador puedaseleccionar los recursos de estas áreas.

3. Conseguir que la herramienta de soporte a los distintos modelos de FPGA que sevan a utilizar (ZedBoard y Kintex 7).

La herramienta HDADR permite generar diseños para las placas ZedBoard y Kintex-7KC705, cumpliendo así con este objetivo. Por otra parte, tal y como se muestra enApéndice C, añadir soporte a nuevas placas es muy sencillo.

4. Ofrecer al usuario la posibilidad de exportar el diseño generado a Xilinx SDK.

HDADR contiene una pequeña herramienta que permite exportar el diseño que se tieneabierto en ese momento a Vivado SDK. Se puede acceder a esta funcionalidad a travésde la barra de menús de HDADR.

5. Dar soporte al usuario para la gestión de la reconfiguración, de forma que una vezque el diseño haya sido generado la reconfiguración se podrá realizar de variasformas:

Desde la propia herramienta a desarrollar en este TFG.

La herramienta HDADR incluye un «Gestor de la reconfiguración». Dentro deeste gestor, la primera opción permite al diseñador seleccionar qué bitstream delos generados quiere utilizar para programar la FPGA. Una vez seleccionado elbitstream, HDADR se encarga de todo el proceso de programación.

Desde una aplicación creada por el usuario, indicando al módulo de reconfi-guración cuándo hay que realizarla.

La segunda opción que ofrece el gestor permite cargar en la memoria de la FPGA

una aplicación que se encargue de la reconfiguración. Una vez que el diseñadorhaya especificado toda la información necesaria, la herramienta HDADR progra-mará la FPGA con el bitstream completo seleccionado y cargará en la memoriade la FPGA la aplicación y los bitstreams parciales indicados por el diseñador.

126

6. Proporcionar al diseñador la opción de generar una Zynq Boot Image.

El diseñador puede generar una imagen de arranque utilizando la herramienta HDADR.Para ello solo tiene que indicar la aplicación que desea ejecutar sobre el procesador dela FPGA, el bitstream que se utilizará para programar la FPGA y el directorio de salidadonde se generará la imagen de arranque.

7. Permitir al diseñador incluir nuevos módulos reconfigurables y la posibilidad decrear nuevas configuraciones tras generar el diseño inicial sin necesidad de volvera generar todo el diseño de nuevo.

En HDADR el diseñador puede añadir nuevos módulos y configuraciones a un diseñogenerado previamente con esta herramienta. Este diseño puede ser uno que se acabade crear y generar o uno que fue generado anteriormente y que ha sido recuperado alabrir HDADR. Cuando se da este caso, los scripts que se encargan de automatizar elproceso de generación del diseño están preparados para generar únicamente los nuevosmódulos y configuraciones, lo que supone un ahorro de tiempo importante al no tenerque generar todo el diseño de nuevo.

8. Conseguir que el consumo de memoria de la GUI de la herramienta a desarrollarsea significativamente menor que el de la GUI de Vivado.

Como se puede extraer del caso de estudio realizado en la Subsección 6.2.2, el consu-mo de memoria de HDADR es menor que el de la GUI de Vivado y, además, el incre-mento del uso de memoria física que se produce en el sistema durante la generaciónde un diseño es menor cuando se utiliza HDADR que cuando se utiliza Vivado.

7.2 Trabajo futuroUna vez analizado el resultado de este TFG en función de los objetivos establecidos al

inicio del proyecto, a continuación se muestran algunas propuestas de trabajo futuro queparten de la herramienta desarrollada:

Hacer que la generación del diseño reconfigurable se realice en una máquina ex-terna más potente. Dado que la generación de un diseño requiere un consumo dememoria y de CPU importante, una mejora interesante consiste en ofrecer al diseña-dor la posibilidad de llevar la generación del diseño reconfigurable a una máquina quedisponga de mayor cantidad de memoria y mayor capacidad de procesamiento. Aun-que habría que estudiar con detalle cómo implementar esta funcionalidad, la idea es lasiguiente:

• El diseñador proporciona toda la información del diseño que se quiere generar enla herramienta HDADR cliente. Al pulsar «Generar diseño», la herramienta crealos ficheros necesarios para la generación y los transfiere a la máquina remota.

• Se inicia el proceso de generación en la máquina remota.

127

• Finalizada la generación del diseño reconfigurable, los bitstreams generados setransfieren de la máquina remota al equipo del diseñador.

Paralelizar algunas tareas si el sistema tiene recursos suficientes. En los scriptsque la herramienta HDADR ejecuta para generar el diseño existen algunas tareas quese pueden paralelizar: la síntesis de los módulos reconfigurables, la implementación delas configuraciones del diseño (excepto la primera), y la generación de los bitstreamsde cada configuración. Un posible trabajo futuro consistiría en evaluar si la paraleliza-ción de estas tareas se puede llevar a cabo y, si es así, estudiar en qué casos se debeparalelizar el flujo e implementar la mejora.

Ubicar las particiones reconfigurables de forma automática. Esta idea, que ne-cesitaría de un estudio previo en el que se analice si es posible su implementación,permitiría que el diseñador dejase en manos de la herramienta la decisión de definirlas áreas de la FPGA donde se situarán las particiones reconfigurables del diseño. Pa-ra calcular el área que necesita una determinada partición es necesario conocer anteslos módulos reconfigurables que se implementarán en esta partición, de forma que sepueda decidir automáticamente la zona de la FPGA donde implementar la particiónpartiendo del número de recursos que necesiten estos módulos reconfigurables.

128

ANEXOS

129

Anexo A

Prototipos de la interfaz gráfica de la herramienta

A.1 Prototipos iniciales de la interfaz gráfica principalA continuación se muestran los prototipos realizados en la iteración 2 de la interfaz gráfica

principal, la cual se encarga de guiar al diseñador a lo largo del flujo de diseño de laherramienta HDADR. Cada uno de estos pasos se implementa de forma separada y se incluyedentro de un contenedor, de forma que sea más fácil editar la representación gráfica de esteflujo de diseño en función de lo requerido por el product owner.

HDADR


2. Parte estática



5. Configuraciones

Crear diseño

Datos de la FPGA

Part:

Board:

Datos del proyecto (Vivado)

Nombre del proyecto:

Nombre del diseño:

Directorio de IPs del usuario:

Block design:

Seleccionar

Seleccionar

Figura A.1: Información General - Prototipo de la GUI de la herramienta.

131

HDADR


2. Parte estática

Crear diseño



5. Configuraciones

Archivos de la parte estática Archivos de restricciones (constraint files)

src/xdc/topZedboard.xdc

Añadir Eliminar

Top Ruta

src/top/top.vhd

src/top/example.vhd

Añadir Eliminar

Figura A.2: Parte estática - Prototipo de la GUI de la herramienta.

HDADR


2. Parte estática

Crear diseño



5. Configuraciones

ID:

Nombre de la partición:

Nombre de la instancia:

Ruta del código fuente:

Añadir partición

Particiones existentes

Eliminar partición

ID Nombre Instancia Source Recursos HW

rm_core exampleName exampleInstance sourceExample hwResourceExample32:21

rm_core2 example2 example2 example2 example2:3

Recursos hardware:

Figura A.3: Particiones reconfigurables - Prototipo de la GUI de la herramienta.

132

HDADR


2. Parte estática

Crear diseño



5. Configuraciones

Módulos existentes

Eliminar módulo

ID Nombre Partición reconfigurable Sources

fixed1files fixed1 rm_core sourceExample

fixed2files fixed2 rm_core2 sourceExample2

ID:

Nombre del módulo:

Partición reconfigurable:

Añadir módulo

rm_core

src/ejemplo.vhd

Archivos: Añadir

Figura A.4: Módulos reconfigurables - Prototipo de la GUI de la herramienta.

133

HDADR


2. Parte estática

Crear diseño



5. Configuraciones

ID:

Nombre de la configuración:

Configuraciones existentes

Eliminar configuración

ID Nombre Módulos a implementar

cfg0 cfg0 fixed1 (rm_core), fixed2 (rm_core2)

cfg1 cfg1 fixed1 (rm_core), fixed3 (rm_core2)

Añadir configuración

Módulos a implementar: Partición Módulo

rm_core <seleccionar>

rm_core2 <seleccionar>

... ...

Figura A.5: Configuraciones - Prototipo de la GUI de la herramienta.

134

A.2 Prototipo inicial del selector de área (floorplanning)El prototipo inicial de la ventana que permite al diseñador seleccionar el área de la FPGA

que ocupará una partición reconfigurable determinada se muestra en la Figura A.6.

Selector de área - HDADR

Selector de área

Board Herramientas

Zoom - Zoom +

Mostrar cuadrícula

Recursos hardware añadidos

SLICE_X0Y0

SLICE_X0Y1

SLICE_X0Y2

Eliminar todoAñadir los recursos seleccionados

Aceptar

Figura A.6: Prototipo de la GUI que permite el floorplanning.

135

A.3 Prototipos del gestor de la reconfiguraciónEn esta sección se muestran los prototipos realizados a lo largo de las iteraciones 3 y 4

sobre el gestor de la reconfiguración de la herramienta HDADR, el cual permite gestionar lareconfiguración de la FPGA desde la propia herramienta o a través de una aplicación creadapor el diseñador.

Gestión de la reconfiguración - HDADR

¿Cómo desea realizar la reconfiguración de la FPGA?

Utilizando esta herramienta

Utilizando una app creada por el usuario

Siguiente


Bitstreams:

Programar

reference.bit

Barra de progreso. Visible solo durante laprogramación de la FPGA.

Figura A.7: Prototipo del gestor de la reconfiguración, incluyendo la interfaz que permiteprogramar la FPGA utilizando un bitstream generado previamente.

136


Seleccione la plataforma hardware:

Abrir Vivado SDK

Plataforma hardware

ps_system_wrapper_hw_platform_0

Bitstream: Dirección de memoria (hex):partial1.bit 0x0001

Añadir bitstream

Bitstreams parciales (cargar a memoria DDR)

Bitstream Dirección

partial2.bit 0x0002

partial3.bit 0x0003

Seleccione la aplicación que desea cargar en la memoria del dispositivo:

Seleccione el bitstream completo con el que desea programar el dispositivo:

reference.bit

Programar

Aplicación

Bitstream completo

Barra de progreso. Visible solo durante laprogramación de la FPGA.

Figura A.8: Prototipo de la ventana que permite cargar en la FPGA una aplicación de usuarioque se encargue de la reconfiguración.

137

A.4 Protitipo de la ventana que permite exportar el hardware a Vi-vado SDK

La Figura A.9 muestra el prototipo realizado para la ventana que permite al diseñadorexportar la definición del hardware generado en la herramienta HDADR para su uso en VivadoSDK.

Exportar hardware a Vivado SDK - HDADR

Exportar

Añadir el bitstream de referencia (reference.bit)

Abrir Vivado SDK al finalizar

Barra de progreso. Visible solo durante elproceso de exportación.

Figura A.9: Prototipo de la ventana que permite exportar el hardware a Vivado SDK.

138

A.5 Prototipo de la ventana que permite crear la imagen de arran-que

La Figura A.10 muestra el protitipo de la ventana que permitirá al diseñador crear unaimagen de arranque que pueda ser utilizada para iniciar la FPGA desde una tarjeta SD.

Crear imagen de arranque para SD - HDADR

Abrir Vivado SDK

Seleccione la aplicación que desea añadir a la imagen de arranque:

Seleccione el bitstream completo que desea añadir a la imagen de arranque:

reference.bit

Crear imagen

Aplicación

Bitstream completo

Indique el directorio donde se guardará la imagen de arranque:

...

Directorio de salida

Barra de progreso. Visible solo durante lageneración de la imagen de arranque.

Figura A.10: Prototipo de la ventana que permite crear la imagen de arranque para una SD.

139

Anexo B

Compilación y uso de la herramienta

B.1 Requisitos para la compilación de la herramientaAntes de compilar y ejecutar la herramienta HDADR es necesario disponer en el sistema de

una serie de librerías y de variables de entorno. En esta sección se muestran las instruccionesde instalación de cada una de las librerías necesarias y, además, el listado de las variables deentorno que tienen que estar establecidas antes de ejecutar HDADR.

B.1.1 CTemplateEsta librería, que ofrece un sistema de plantillas ligero y rápido para aplicaciones escri-

tas en C++, se utiliza para generar archivos a partir de una plantilla previa. El proyectoCTemplate se puede clonar o descargar desde el repositorio [cte]. Los pasos a seguir para suinstalación en el equipo son los siguientes:

Configurar y compilar las librerías.

$ ./autogen.sh && ./configure && make

Instalación de las librerías.

# make install

A lo largo de la configuración y compilación de CTemplate se pueden producir algunoserrores dado que este proceso depende de una serie de paquetes que deben estar instaladosen el sistema (automake, autoconf, make, etc.). Para más información sobre la instalación deCTemplate consulte el archivo INSTALL que se encuentra en la raíz del repositorio.

B.1.2 QtLa herramienta HDADR utiliza el framework Qt para el desarrollo de la interfaz gráfica.

La instalación de Qt se puede llevar a cabo instalando los paquetes correspondientes que sepueden encontrar en los repositorios oficiales de las principales distribuciones.

Debian 8 / Ubuntu 16.04.

# apt-get install qt5-default

141

Fedora 23.

# dnf install qt5-qtbase qt5-qtbase-devel

B.1.3 Google Test [Opcional]Librería utilizada para la creación de las pruebas unitarias que se le aplican a las clases

de la capa de dominio y persistencia. La instalación de esta librería es solo necesaria en elcaso de que se deseen ejecutar y/o modificar las pruebas unitarias que se incluyen con laherramienta HDADR.

Debian 8 / Ubuntu 16.04.

# apt-get install libgtest-dev

# cd /usr/src/gtest

# cmake CMakeLists.txt

# make

# cp *.a /usr/lib

Fedora 23.

# dnf install gtest-devel

B.1.4 Variables de entornoPara que la herramienta HDADR pueda hacer uso de las herramientas proporcionadas por

Xilinx es necesario modificar y crear algunas variables de entorno, en concreto:

1. $PATH. A esta variable se le añaden los directorios donde se encuentran los ejecuta-bles de Vivado, Vivado SDK y Vivado HLS. Estos directorios dependerán de dónde seinstaló el software de Xilinx en el equipo en cuestión.

2. $LM_LICENSE_FILE, $XILINX_LICENSE_FILE. En estas variables de entorno se especificael servidor de licencias con el que se comunicarán las herramientas de Xilinx paraobtener una licencia durante su ejecución.

B.2 Compilación y ejecuciónLa compilación y ejecución de la herramienta HDADR se realiza a través del archivo Ma-

kefile que se encuentra en la raíz del proyecto. El valor de las variables $MOC y $INCDIRS quese encuentran dentro de este archivo será distinto en función del sistema operativo que seutilice. El archivo Makefile está preparado por defecto para ejecutarse en una máquinaDebian. En caso de utilizar Ubuntu o Fedora se deben comentar las líneas correspondien-tes al apartado «Debian 8» dentro del Makefile y eliminar los comentarios del apartado del

142

sistema operativo que se esté utilizando.

La compilación de la herramienta y la generación de los archivos XML que contienenla información sobre los recursos hardware de las placas se realiza mediante el siguientecomando:

$ make all

Finalizado el proceso anterior, la ejecución de la herramienta se realiza a través delcomando:

$ make run

B.2.1 Ejecución de los test [Opcional]La compilación y la ejecución de los test proporcionados se realiza a través del archivo

test.mk. Al igual que ocurre con el Makefile principal, el archivo test.mk está preparadopara su ejecución en Debian. En el caso de ejecutarlos en Ubuntu o en Fedora se debencomentar las líneas correspondientes a «Debian 8» y eliminar los comentarios del apartadodel sistema operativo que se esté utilizando. También es importante mencionar que unode los test requiere la existencia del directorio con los archivos XML que contienen lainformación hardware de las placas, por lo que es necesario compilar en primer lugar laherramienta HDADR.

Para compilar y ejecutar los test es necesario ejecutar el siguiente comando:

$ make -f test.mk all run_test

B.3 Uso de la herramienta HDADR

Esta sección pretende guíar al diseñador a lo largo del flujo de diseño de la herramientaHDADR, además de mostrar y explicar el funcionamiento de las distintas opciones que seincluyen dentro del menú «Herramientas» (gestor de reconfiguración, exportar hardware aVivado SDK, etc.).

B.3.1 Inicio de la herramienta. Establecer el directorio del proyecto.Al ejecutar la herramienta lo primero que aparece es un diálogo que permite seleccionar

el idioma de la aplicación.

Una vez que se selecciona el idioma se abre la interfaz gráfica principal de HDADR. Alinicio todas las opciones y menús están deshabilitados hasta que no se seleccione en la partesuperior de la interfaz el directorio donde se generará el diseño. Este directorio debe contenerlos scripts y el Makefile que utiliza HDADR para la generación del diseño haciendo uso delsoftware del fabricante (o, al menos, un enlace simbólico hacia éstos).

143

Figura B.1: Selector de idioma.

Figura B.2: Establecer el directorio del proyecto.

Cuando el diseñador introduzca y acepte este directorio, el flujo de la herramienta HDADR

se habilitará para que el diseñador pueda comenzar a establecer las propiedades del diseñoque se ha de generar.

B.3.2 Flujo de diseño

A continuación se muestran los pasos del flujo de diseño de HDADR, indicando los datosque se han de introducir en cada momento y las opciones disponibles en cada uno de estos

144

pasos. En el caso de que no se haya introducido toda la información necesaria o ésta seaincorrecta en un paso del flujo de diseño, se le indicará al diseñador qué parte debe modificarantes de continuar. Destacar que conforme se va avanzando en el flujo de diseño se puedevolver a pasos anteriores para consultar o modificar los datos introducidos.

Información general

En este paso del flujo de diseño se introducen los datos de la FPGA y los datos del proyectode Vivado que se creará para poder generar el diseño. Las FPGAS soportadas por HDADR sonla ZedBoard y la Kintex-7 (para añadir soporte a nuevas placas consultar el Apéndice C).Es importante asegurarse de que los datos de la FPGA son correctos antes de pasar alsiguiente paso del flujo ya que, una vez que se pulse el botón «Continuar», no se podránmodificar estos datos.

Figura B.3: Flujo de diseño - Información general.

Parte estática

Este paso del flujo permite al diseñador añadir los archivos que componen la parte estáticadel diseño y los archivos de restricciones que se aplicarán al diseño. En el caso de los archivosque definen la parte estática se debe seleccionar cuál de los archivos añadidos representa el

145

top de la parte estática mediante el check box correspondiente.

Figura B.4: Flujo de diseño - Parte estática.

Particiones reconfigurables

En este paso se introducen todas las particiones reconfigurables con las que cuenta eldiseño que se pretende generar. En el momento de definir los recursos hardware de unapartición se recomienda abrir el selector de área. Este selector de área muestra de formagráfica la disposición de los recursos de la FPGA que se va a utilizar y permite seleccionarel área de ésta que ocupará la partición en cuestión. Una vez seleccionados y añadidos, semuestra un resumen del área seleccionada mostrando el número de recursos de cada tipo quese han seleccionado. Si se da el caso, el diseñador puede eliminar de este listado los recursosque no le interesen.

Las particiones que se añadan al diseño aparacerán en la tabla inferior («Particiones exis-tentes»). El diseñador puede eliminar del diseño una partición añadida anteriormente a travésdel menú contextual.

146

Figura B.5: Flujo de diseño - Particiones reconfigurables.

147

Figura B.6: Flujo de diseño - Selector de área.

148

Módulos reconfigurables

Una vez añadidas las particiones del diseño reconfigurable, el siguiente paso es añadir losmódulos que se podrán implementar dentro de estas particiones. Para cada módulo recon-figurable el diseñador tendrá que especificar el identificador, nombre y los archivos que locomponen. Además se le ofrece un selector donde podrá elegir la partición a la que estaráasociado el módulo.

Al igual que en el caso anterior, los módulos que se añadan al diseño aparecerán en la tablainferior. El diseñador podrá eliminar del diseño un módulo a través del menú contextual.

Figura B.7: Flujo de diseño - Módulos reconfigurables.

Configuraciones

En este paso se pueden añadir las configuraciones del diseño que serán implementadasy generadas. Para cada configuración el diseñador tendrá que especificar el identificador, elnombre, y qué módulo se desea cargar en cada una de las particiones que tiene el diseño. Paraesto último se ofrece una tabla donde para cada partición se listan únicamente los módulosque están asociados a ésta, evitando así posibles errores. En la tabla inferior aparecen todaslas configuraciones que se vayan añadiendo al diseño y, al igual que con las particiones y

149

los módulos, el diseñador podrá eliminar una configuración del diseño a través del menúcontextual de la tabla.

Finalmente aparece la opción que permite al diseñador decidir si quiere generar la confi-guración blanking o no.

Figura B.8: Flujo de diseño - Configuraciones.

Bitstreams

El último paso del flujo de diseño muestra los bitstreams que se generarán. En un principiose generará el bitstream reference, uno para cada configuración creada, y el bitstream de laconfiguración blanking si así lo indicó el diseñador. En este paso el diseñador puede decidirsi quiere aplicar la compresión de Xilinx a cada uno de estos bitstreams o no (por defecto seencuentra deshabilitada esta opción para todas las configuraciones).

150

Figura B.9: Flujo de diseño - Bitstreams.

Generar el diseño

Una vez que se han completado todos los pasos del flujo de diseño éste se deshabilita. Eldiseñador puede comenzar con la generación del diseño en cualquier momento pulsando elbotón «Generar diseño». En el caso de que se produzca un error durante la generación deldiseño, el flujo se volverá a activar para que el diseñador pueda modificar la informaciónintroducida.

Por otra parte, si el proceso finaliza correctamente, se informa al diseñador de que a partirde ese momento puede añadir nuevos módulos y configuraciones sin necesidad de volvera generar todo el diseño de nuevo (generación parcial).

B.3.3 Exportar hardware a Vivado SDKEsta pequeña herramienta de HDADR permite exportar la definición hardware de un diseño

ya generado para su uso en Vivado SDK. De esta forma se podrá utilizar Vivado SDK paradesarrollar aplicaciones sobre el hardware que se ha generado utilizando HDADR. A la horade exportar el hardware el diseñador puede decidir si añadir el bitstream de referencia a estadefinición y si quiere abrir Vivado SDK cuando finalice la exportación.

151

Figura B.10: Exportar hardware a Vivado SDK.

B.3.4 Gestor de la reconfiguración

Este gestor permite gestionar la reconfiguración de la herramienta HDADR de dos for-mas:

A través de la herramienta HDADR, utilizando un bitstream completo o parcial de losobtenidos tras la generación del diseño.

Utilizando una aplicación desarrollada por el usuario. En este caso, la aplicación secarga en la memoria del dispositivo para su ejecución en el procesador.

Figura B.11: Gestor de la reconfiguración.

152

A través de la herramienta HDADR

En esta opción el diseñador puede escoger cuál de los bitstreams generados desea utilizarpara programar la FPGA, incluyendo los bitstreams parciales. Es importante tener en cuentaque si se intenta programar la FPGA con un bitstream parcial sin haberla programado antescon un bitstream completo, el proceso de programación fallará.

Figura B.12: Gestionar la reconfiguración parcial a través de la herramienta HDADR.

Utilizando una aplicación creada por el usuario

Esta opción se debe seleccionar si el diseñador quiere gestionar la reconfiguración a travésde una aplicación creada por él. Esta aplicación estará creada con Vivado SDK a partir de ladefinición hardware de un diseño generado previamente. La ventana que permite este tipo dereconfiguración se divide en cuatro bloques:

Plataforma hardware. En esta parte se selecciona la plataforma hardware sobre laque se desarrolló la aplicación. Esta plataforma se genera en Vivado SDK al crear unaaplicación sobre la definición hardware del diseño generado.

Bitstreams parciales. En esta sección se establecen los bitstreams parciales que seránutilizados por la aplicación que gestionará la reconfiguración y, por tanto, los que de-berán cargarse en la memoria del dispositivo. Para cada bitstream que se quiera cargarse deberá especificar la dirección de memoria donde se almacenará. La validez de estasdirecciones de memoria serán comprobadas por HDADR antes de que un bitstream seaañadido a la tabla atendiendo a lo especificado en el archivo que contiene el diseño debloques.

Aplicación. El usuario deberá seleccionar la aplicación en cuestión dentro de la jerar-quía de directorios que se le muestra.

Bitstream completo. Antes de cargar la aplicación y los bitstreams en memoria esnecesario programar la FPGA con un bitstream completo. Esta sección da la posibili-dad al diseñador de elegir el bitstream completo que quiere utilizar para programar laFPGA.

153

Figura B.13: Gestionar la reconfiguración parcial a través de una aplicación de usuario.

B.3.5 Crear imagen de arranque para tarjeta SDEsta herramienta integrada en HDADR permite generar una imagen de arranque (boot ima-

ge) que puede ser utilizada para iniciar la FPGA desde una tarjeta SD. El diseñador tendráque elegir la aplicación que quiere que se cargue en la memoria y procesador del dispostivo,el bitstream completo con el que se programará la FPGA durante su inicio, y el directorio desalida donde se generará la imagen de arranque (generalmente en la raíz de la tarjeta SD).

Se puede dar el caso de que la aplicación que se cargue necesite leer de la tarjeta SD uno omás bitstreams parciales para, por ejemplo, encargarse de la reconfiguración de la FPGA. Eneste caso el diseñador deberá copiar los bitstreams parciales manualmente en la tarjeta SD, yaque tanto el directorio como el nombre de estos bitstreams dependerá de la implementacióninterna de la aplicación creada por el diseñador.

154

Figura B.14: Crear imagen de arranque para tarjeta SD.

B.3.6 Ampliar un diseño existenteLa herramienta HDADR permite añadir nuevos módulos y configuraciones a un diseño ya

existente una vez que éste se ha generado correctamente. Tal y como se comentó anterior-mente, al finalizar la generación completa del diseño se informa al usuario de que puedeampliar el diseño y el flujo de diseño de la herramienta se vuelve a habilitar permitiendoañadir nuevos módulos y configuraciones. De esta forma, al generar el diseño de nuevo, so-lo se generarán los nuevos módulos y configuraciones (lo que supone un ahorro de tiempoconsiderable en comparación con volver a generarlo todo de nuevo).

Una vez generado el diseño se puede cerrar la herramienta HDADR ya que se podrárecuperar este diseño después al abrir de nuevo la herramienta. Cuando el diseñadorindica el directorio del proyecto (es decir, el directorio donde se genera el diseño) la herra-mienta HDADR buscará si existe algún diseño generado previamente en ese directorio. En elcaso de que exista alguno se le preguntará al usuario si quiere recuperar la informaciónde este diseño para ampliarlo añadiendo nuevos módulos y configuraciones.

Teniendo en cuenta estas dos opciones se concluye que el diseñador podrá añadir nuevosmódulos y configuraciones a un diseño ya existente en cualquier momento.

155

Figura B.15: Mensaje mostrado al usuario en caso de que se detecte un diseño anterior en eldirectorio introducido.

156

Anexo C

Añadir soporte a nuevas placas

C.1 Placas soportadas por HDADR

En Vivado, y por tanto también en la herramienta HDADR, una placa se identifica mediantedos datos: el part, que identifica el modelo concreto de FPGA que se utiliza, y el board, queidentifica el modelo de placa que se utiliza y su fabricante (Avnet para ZedBoard, Xilinxpara el resto).

La herramienta HDADR ofrece en un principio soporte para la ZedBoard y la Kintex-7,cuyos datos son los siguientes:

ZedBoard.

• part: xc7z020clg484-1

• board: em.avnet.com:zed:part0:1.2

Kintex-7 KC705 Evaluation Platform.

• part: xc7k325tffg900-2

• board: xilinx.com:kc705:part0:1.2

C.2 Añadir nuevas placas a la herramienta HDADR

La herramienta HDADR se ha desarrollado con la idea de que añadir soporte a nuevasplacas sea fácil y rápido. En esta herramienta los datos de las FPGAS se utilizan para lageneración de los archivos XML que contienen la información de los recursos hardware ypara mostrarlos dentro de los selectores que permiten definir la FPGA que se utiliza en undiseño. Por tanto, cuando se quiera añadir una nueva FPGA se deberán modificar dos partesde la herramienta: el script que se encarga de generar los archivos XML y la interfaz gráficadel primer paso del flujo de diseño.

Mencionar que una vez añadidas todas las modificaciones necesarias es necesario volvera ejecutar el script para que se generen los archivos XML de las nuevas placas y volver acompilar la herramienta para que se apliquen los cambios realizados en la interfaz gráfica.

157

Añadir una nueva placa al script que genera los archivos XML

Dentro del script generateBoardsXML.tcl se crea la función generateBoardXML que tomacomo entradas el part y el board de una placa y genera el archivo XML que contiene lainformación de todos los recursos hardware de la FPGA en cuestión. Por lo tanto, para añadiruna nueva placa a este script solo es necesario llamar a esta función con los datos de la placaque se quiera añadir. En el Listado C.1 se muestran las últimas líneas de este script donde sellama a la función generateBoardXML para generar los archivos XML de la ZedBoard y dela Kintex-7.

# ZedBoard

generateBoardXML "xc7z020clg484-1" "em.avnet.com:zed:part0:1.2"

# Kintex-7 KC705 Evaluation Platform (XC7K325T-2FFG900C)

generateBoardXML "xc7k325tffg900-2" "xilinx.com:kc705:part0:1.2"

Listado C.1: Líneas del script generateBoardsXML.tcl en las que se llama a la función quegenera el archivo XML para una determinada placa.

Añadir una nueva placa a la interfaz gráfica

Los datos de la nueva placa también se han de añadir a los selectores de part y board que seencuentran en el primer paso del flujo de diseño para que el diseñador pueda seleccionarlos.Es decir, es necesario modificar la clase GeneralInfoWidget de la capa de presentación de lasiguiente forma:

En primer lugar se modifica el método createFPGADataGroup(), añadiendo el part dela nueva placa al objeto partComboBox.

En segundo lugar se modifica el método listCompatibleBoards(), añadiendo la relaciónpart-board de la forma que se muestra en el Listado C.3.

158

void GeneralInfoWidget::createFPGADataGroup() {

fpgaDataGroup = new QGroupBox(tr("Datos de la FPGA"));

partLabel = new QLabel(tr("Part:"));

boardLabel = new QLabel(tr("Board:"));

partComboBox = new QComboBox();

partComboBox->setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Preferred);

connect(partComboBox, SIGNAL(currentTextChanged(QString)), this, SLOT(listCompatibleBoards(

QString)));

boardComboBox = new QComboBox();

boardComboBox->setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Preferred);

//Add compatible parts

//ZedBoard

partComboBox->addItem("xc7z020clg484-1");

//Kintex-7 KC705 (XC7K325T-2FFG900C)

partComboBox->addItem("xc7k325tffg900-2");

//Create the layout

fpgaDataGroupLayout = new QGridLayout();

fpgaDataGroupLayout->addWidget(partLabel, 0, 0);

fpgaDataGroupLayout->addWidget(partComboBox, 0, 1);

fpgaDataGroupLayout->addWidget(boardLabel, 1, 0);

fpgaDataGroupLayout->addWidget(boardComboBox, 1, 1);

fpgaDataGroup->setLayout(fpgaDataGroupLayout);

}

Listado C.2: Método en el que se ha de introducir el part de la nueva placa que se deseaañadir.

void GeneralInfoWidget::listCompatibleBoards(const QString &part) {

boardComboBox->clear();

//Add boards to comboBox according to the part introduced

if (part == "xc7z020clg484-1") {

boardComboBox->addItem("em.avnet.com:zed:part0:1.2");

}

if (part == "xc7k325tffg900-2") {

boardComboBox->addItem("xilinx.com:kc705:part0:1.2");

}

}

Listado C.3: Método en el que se establece la relación part-board de la nueva placa que sedesea añadir.

159

Anexo D

Repositorio del proyecto

La cantidad de código desarrollado para la herramienta HDADR, así como la de los com-ponentes del grupo ARCO utilizados en este proyecto, hace que incluir el código del proyectoen este documento sea, como mínimo, poco práctico. En su lugar el lector puede consultartodo el código y documentación de este TFG en el siguiente repositorio:

https://bitbucket.org/javiersevilla/hdadr.tfg.javiersevilla

Dado que este proyecto contiene componentes que no han sido desarrollados por el alumno,este repositorio es privado. Para solicitar acceso al repositorio póngase en contacto con el au-tor de este documento.

161

https://bitbucket.org/javiersevilla/hdadr.tfg.javiersevilla

Anexo E

GNU Free Documentation License

Version 1.3, 3 November 2008

Copyright c© 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. <http://fsf.org/>

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PreambleThe purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to

assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially.Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsiblefor modifications made by others.

This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. Itcomplements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: afree program should come with manuals providing the same freedoms that the software does. But this License is not limited to softwaremanuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend thisLicense principally for works whose purpose is instruction or reference.

1. Applicability and definitionsThis License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be

distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that workunder the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee,and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyrightlaw.

A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or withmodifications and/or translated into another language.

A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship ofthe publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could falldirectly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain anymathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial,philosophical, ethical or political position regarding them.

The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the noticethat says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowedto be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sectionsthen there are none.

The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that saysthat the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25words.

163

http://fsf.org/

A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to thegeneral public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels)generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or forautomatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file formatwhose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent.An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format,SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modifi-cation. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be readand edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available,and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the materialthis License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the textnear the most prominent appearance of the work’s title, preceding the beginning of the body of the text.

The “publisher” means any person or entity that distributes copies of the Document to the public.

A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parenthesesfollowing text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknow-ledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Documentmeans that it remains a section “Entitled XYZ” according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. TheseWarranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any otherimplication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. Verbatim copying

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, thecopyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no otherconditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying ofthe copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough numberof copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. Copying in quantity

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, andthe Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these CoverTexts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identifyyou as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible.You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of theDocument and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) onthe actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readableTransparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the generalnetwork-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, freeof added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies inquantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time youdistribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, togive them a chance to provide you with an updated version of the Document.

164

4. ModificationsYou may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you

release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensingdistribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in theModified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions(which should, if there were any, be listed in the History section of the Document). You may use the same title as a previousversion if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the ModifiedVersion, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five),unless they release you from this requirement.

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Versionunder the terms of this License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s licensenotice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, andpublisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create onestating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the ModifiedVersion as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, andlikewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History”section. You may omit a network location for a work that was published at least four years before the Document itself, or if theoriginal publisher of the version it refers to gives permission.

K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the sectionall the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalentare not considered part of the section titles.

M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.

N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.

O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no materialcopied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to thelist of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by variousparties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of astandard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the endof the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by(or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added byyou or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, onexplicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assertor imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above formodified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified,and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

165

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a singlecopy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique byadding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Makethe same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled“History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete allsections Entitled “Endorsements”.

5. Collections of documentsYou may make a collection consisting of the Document and other documents released under this License, and replace the individual

copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules ofthis License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copyof this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

6. Aggregation with independent worksA compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a

storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rightsof the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License doesnot apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one halfof the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or theelectronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the wholeaggregate.

7. TranslationTranslation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4.

Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translationsof some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of thisLicense, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original Englishversion of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and theoriginal version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve itsTitle (section 1) will typically require changing the actual title.

8. TerminationYou may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt

otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally,unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails tonotify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violationby some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyrightholder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from youunder this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same materialdoes not give you any rights to use it.

166

9. Future revisions of this licenseThe Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time.

Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Seehttp://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version ofthis License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified versionor of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a versionnumber of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Documentspecifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a versionpermanently authorizes you to choose that version for the Document.

10. Relicensing“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and

also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A“Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMCsite.

“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that licensepublished by that same organization.

“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.

An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this Licensesomewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariantsections, and (2) were thus incorporated prior to November 1, 2008.

The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before

August 1, 2009, provided the MMC is eligible for relicensing.

167

Referencias

[alt] Partial Reconfiguration IP Core. https://www.altera.com/content/dam/

altera-www/global/en US/pdfs/literature/ug/ug partrecon.pdf.

[BKT12] C. Beckhoff, D. Koch, y J. Torresen. Go Ahead: A Partial Reconfiguration Fra-mework. En Field-Programmable Custom Computing Machines (FCCM), 2012

IEEE 20th Annual International Symposium on, páginas 37–44, April 2012.

[Bob07] C. Bobda. Introduction to Reconfigurable Computing. University of Kaiserslau-tern, 2007.

[Cab] J. Caba. Improving Dynamic Partial Reconfiguration tasks for Xilinx Zynq de-vices.

[CB11] J.A. Clemente Barreira. Scheduling techniques in reconfigurable environments

for multimedia applications. PhD thesis, Universidad Complutense de Madrid(UCM), 2011.

[CC] J. Caba y J. M.P. Cardoso. A hardware platform for component characterization.

[CDG+13] T. Cervero, J. Dondo, A. Gómez, X. Peña, S. Lopez, F. Rincon, R. Sarmiento,y J. C. Lopez. A Resource Manager for Dynamically Reconfigurable FPGA-Based Embedded Systems. En Digital System Design (DSD), 2013 Euromicro

Conference on, páginas 633–640, Sept 2013.

[cte] C++ CTemplate system. https://github.com/OlafvdSpek/ctemplate.

[Dol14] A. Dollas. Big Data Processing with FPGA Supercomputers: Opportunities andChallenges. En 2014 IEEE Computer Society Annual Symposium on VLSI, pá-ginas 474–479, July 2014.

[DSAG10] Gajski D.D., Abdi S., Gerstlauer A., y Schirner G. Embedded System Design:

Modeling, Synthesis and Verification, capítulo System design methodologies,página 43. Springer, New York, NY, USA., 2010.

[Dye12] D. Dye. Partial Reconfiguration of Xilinx FPGAs Using ISE De-sign Suite. http://www.xilinx.com/support/documentation/white papers/

wp374 Partial Reconfig Xilinx FPGAs.pdf, May 2012. Xilinx.

169

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf

https://github.com/OlafvdSpek/ctemplate

http://www.xilinx.com/support/documentation/white_papers/wp374_Partial_Reconfig_Xilinx_FPGAs.pdf

http://www.xilinx.com/support/documentation/white_papers/wp374_Partial_Reconfig_Xilinx_FPGAs.pdf

[ESSA00] J. Emmert, C. Stroud, B. Skaggs, y M. Abramovici. Dynamic fault tolerancein FPGAs via partial reconfiguration. Field-Programmable Custom Computing

Machines, 2000 IEEE Symposium on, 2000.

[evo] Pencil Project. http://pencil.evolus.vn/.

[gcc] GCC, the GNU Compiler Collection. https://gcc.gnu.org/.

[goo] Google Test. https://github.com/google/googletest.

[gtk] gtkmm - Interfaces C++ para GTK+ y GNOME. http://www.gtkmm.org/es/.

[ink] Inkscape. https://inkscape.org/es/.

[Ins16] Global Market Insights. Field Programmable Gate Array (FPGA) Mar-ket Size By Application (Data Processing, Industrial, Automotive, Consu-mer Electronics, Telecom, Military & Aerospace), Industry Analysis Re-port, Regional Outlook, Application Potential, Competitive Market Share& Forecast, 2015 – 2022. https://www.gminsights.com/industry-analysis/

field-programmable-gate-array-fpga-market-size, February 2016.

[KTB+12] D. Koch, J. Torresen, C. Beckhoff, D. Ziener, C. Dennl, V. Breuer, J. Teich,M. Feilen, y W. Stechele. Partial reconfiguration on FPGAs in practice — Toolsand applications. En ARCS Workshops (ARCS), 2012, páginas 1–12, Feb 2012.

[lib] Libero SoC Design Suite. http://www.microsemi.com/products/fpga-soc/

design-resources/design-software/libero-soc.

[Mor10] Aleksander Morgado. Understanding Valgrind memory leak reports. https://

aleksander.es/data/valgrind-memcheck.pdf, 2010.

[OdlTR12] A. Otero, E. de la Torre, y T. Riesgo. Dreams: A tool for the design of dyna-mically reconfigurable embedded and modular systems. En 2012 International

Conference on Reconfigurable Computing and FPGAs, páginas 1–8, Dec 2012.

[qt] Qt | Cross-platform software development for embedded & desktop. https://

www.qt.io/.

[qtc] Qt - Product | The IDE. https://www.qt.io/ide/.

[qtl] Qt Linguist Manual: Translators. http://doc.qt.io/qt-5/linguist-translators.html.

[qua] Quartus Prime - Overview. https://www.altera.com/products/design-software/fpga-design/quartus-prime/overview.html.

170

http://pencil.evolus.vn/

https://gcc.gnu.org/

https://github.com/google/googletest

http://www.gtkmm.org/es/

https://inkscape.org/es/

https://www.gminsights.com/industry-analysis/field-programmable-gate-array-fpga-market-size

https://www.gminsights.com/industry-analysis/field-programmable-gate-array-fpga-market-size

http://www.microsemi.com/products/fpga-soc/design-resources/design-software/libero-soc

http://www.microsemi.com/products/fpga-soc/design-resources/design-software/libero-soc

https://aleksander.es/data/valgrind-memcheck.pdf

https://aleksander.es/data/valgrind-memcheck.pdf

https://www.qt.io/

https://www.qt.io/

https://www.qt.io/ide/

http://doc.qt.io/qt-5/linguist-translators.html

http://doc.qt.io/qt-5/linguist-translators.html

https://www.altera.com/products/design-software/fpga-design/quartus-prime/overview.html

https://www.altera.com/products/design-software/fpga-design/quartus-prime/overview.html

[Res] Microsoft Research. Project Catapult. https://www.microsoft.com/en-us/

research/project/project-catapult/.

[SAFW11] A. A. Sohanghpurwala, P. Athanas, T. Frangieh, y A. Wood. OpenPR: An Open-Source Partial-Reconfiguration Toolkit for Xilinx FPGAs. En Parallel and Dis-

tributed Processing Workshops and Phd Forum (IPDPSW), 2011 IEEE Interna-

tional Symposium on, páginas 228–235, May 2011.

[SPH13] L. Sterpone, M. Porrmann, y J. Hagemeyer. A Novel Fault Tolerant and RuntimeReconfigurable Platform for Satellite Payload Processing. IEEE Transactions on

Computers, 62(8):1508–1525, Aug 2013.

[SR12] Kenneth S. Rubin. Essential Scrum - A Practical Guide to the Most Popular

Agile Process, capítulo Scrum Framework, páginas 13–28. Addison-Wesley,2012.

[SS16] K. Schwaber y J. Sutherland. The Scrum Guide TM— The Definitive Guide toScrum: The Rules of the Game. http://www.scrumguides.org/docs/scrumguide/

v2016/2016-Scrum-Guide-US.pdf, July 2016.

[sta] StarUML. http://staruml.io/.

[SZ09] Brown S. y Vranesic Z. Fundamentals of Digital Logic with VHDL Design,capítulo Implementation technology, páginas 98–118. Mc Graw Hill, 2009.

[val] Valgrind. http://valgrind.org/.

[viv] Vivado Design Suite. https://www.xilinx.com/products/design-tools/vivado.

html.

[Wik] Wikimedia Commons. Scrum Framework. https://upload.wikimedia.org/

wikipedia/commons/d/df/Scrum Framework.png.

[xila] Xilinx Software Development Kit (XSDK). https://www.xilinx.com/products/

design-tools/embedded-software/sdk.html.

[Xilb] Xilinx. FPGA vs. ASIC - What is the Difference Between a FPGA and an ASIC?http://www.xilinx.com/fpga/asic.htm.

[Xil04] Xilinx. Two Flows for Partial Reconfiguration: Module Based or DifferenceBased, September 2004.

[Xil13a] Xilinx. Embedded System Tools Reference Manual (UG111). https://www.

xilinx.com/support/documentation/sw manuals/xilinx12 3/est rm.pdf, 2013.

171

https://www.microsoft.com/en-us/research/project/project-catapult/

https://www.microsoft.com/en-us/research/project/project-catapult/

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf

http://staruml.io/

http://valgrind.org/

https://www.xilinx.com/products/design-tools/vivado.html

https://www.xilinx.com/products/design-tools/vivado.html

https://upload.wikimedia.org/wikipedia/commons/d/df/Scrum_Framework.png

https://upload.wikimedia.org/wikipedia/commons/d/df/Scrum_Framework.png

https://www.xilinx.com/products/design-tools/embedded-software/sdk.html

https://www.xilinx.com/products/design-tools/embedded-software/sdk.html

http://www.xilinx.com/fpga/asic.htm

https://www.xilinx.com/support/documentation/sw_manuals/xilinx12_3/est_rm.pdf

https://www.xilinx.com/support/documentation/sw_manuals/xilinx12_3/est_rm.pdf

[Xil13b] Xilinx. Partial Reconfiguration User Guide (UG702). http://www.xilinx.com/

support/documentation/sw manuals/xilinx14 7/ug702.pdf, April 2013.

[Xil13c] Xilinx. Vivado Design Suite User Guide: Partial Reconfiguration (UG909).http://www.xilinx.com/support/documentation/sw manuals/xilinx2013 3/

ug909-vivado-partial-reconfiguration.pdf, October 2013.

[Xil15a] Xilinx. AXI Reference Guide (UG761). http://www.xilinx.

com/support/documentation/ip documentation/axi ref guide/latest/

ug761 axi reference guide.pdf, November 2015.

[Xil15b] Xilinx. Vivado Design Suite 7 Series FPGA and Zynq-7000 All ProgrammableSoC Libraries Guide (UG953). http://www.xilinx.com/support/documentation/

sw manuals/xilinx2015 4/ug953-vivado-7series-libraries.pdf, November2015.

[Xil15c] Xilinx. Vivado Design Suite Tcl Command Reference Guide (UG835).http://www.xilinx.com/support/documentation/sw manuals/xilinx2015 4/

ug835-vivado-tcl-commands.pdf, 2015.

[Xil15d] Xilinx. Vivado Design Suite User Guide: Hierarchical Design (UG905).http://www.xilinx.com/support/documentation/sw manuals/xilinx2015 4/

ug905-vivado-hierarchical-design.pdf, November 2015.

[Xil15e] Xilinx. Vivado Design Suite User Guide: Implementation (UG904).http://www.xilinx.com/support/documentation/sw manuals/xilinx2015 4/

ug904-vivado-implementation.pdf, November 2015.

[Xil15f] Xilinx. Vivado Design Suite User Guide: Programming and Debug-ging (UG908). http://www.xilinx.com/support/documentation/sw manuals/

xilinx2015 2/ug908-vivado-programming-debugging.pdf, 2015.

172

http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/ug702.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/ug702.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/ug909-vivado-partial-reconfiguration.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/ug909-vivado-partial-reconfiguration.pdf

http://www.xilinx.com/support/documentation/ip_documentation/axi_ref_guide/latest/ug761_axi_reference_guide.pdf



http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug953-vivado-7series-libraries.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug953-vivado-7series-libraries.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug835-vivado-tcl-commands.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug835-vivado-tcl-commands.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug905-vivado-hierarchical-design.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug905-vivado-hierarchical-design.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug904-vivado-implementation.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug904-vivado-implementation.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_2/ug908-vivado-programming-debugging.pdf

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_2/ug908-vivado-programming-debugging.pdf

Este documento fue editado y tipografiado con LATEX empleandola clase esi-tfg (versión 0.20170118) que se puede encontrar en:

https://bitbucket.org/arco group/esi-tfg

[respeta esta atribución al autor]

173

https://bitbucket.org/arco_group/esi-tfg

Herramienta de desarrollo de aplicaciones dinámicamente ...

Documents

Transcript of Herramienta de desarrollo de aplicaciones dinámicamente ...