entorno para multitarea hardware en dispositivos reconfigurables … · 2014-02-06 · entorno para...

UNIVERSIDAD COMPLUTENSE DE MADRID

FACULTAD DE INFORMÁTICA

DEPARTAMENTO DE ARQUITECTURA DE COMPUTADORES Y AUTOMÁTICA

TESIS DOCTORAL

Entorno para multitarea hardware en dispositivos reconfigurables

con gestión dinámica de particiones y complejidad constante

MEMORIA PARA OPTAR AL GRADO DE DOCTOR

PRESENTADA POR

Sara Román Navarro

Bajo la dirección de los doctores:

Hortensia Mecha López, Daniel Mozos Muñoz y Julio Septién del Castillo

Madrid, 2010

ISBN: 978-84-693-3227-6

Entorno para multitarea hardwareen dispositivos recon�gurables

con gestión dinámica de particionesy complejidad constante

Universidad Complutense de MadridDepartamento de Arquitectura de Computadores y Automática

Sara Román Navarro2009

Entorno para Multitarea Hardwareen Dispositivos Recon�gurables

con Gestión Dinámica de Particiones

Memoria presentada por Sara Román Navarro pa-ra optar al grado de Doctora por la UniversidadComplutense de Madrid. Trabajo realizado en elDepartamento de Arquitectura de Computadoresy Automática de la Facultad de Informática de laUniversidad Complutense de Madrid bajo la direc-ción de los doctores Hortensia Mecha López, Da-niel Mozos Muñoz y Julio Septién del Castillo.

Madrid Mayo 2009

A Román y CarmenA todos los Budas

Esta tesis ha sido posible gracias a la �nanciación de la Comisión Inter-ministerial de Ciencia y Tecnología, a través de los proyectos TIC2002-00160,TEC2005-04752 y TIN2006-03274

Todas las olas del mar deben la belleza de su per�la las que precedieron y se retiraron

André Gide

Las cosas importantes no son cosasAnónimo

No hay un camino que lleve a la felicidad: la felicidad ES el caminoBuda Sakyamuni

Agradecimientos

Ninguno estaríamos hoy donde estamos si no fuera por los que nos hanprecedido, como expresa André Gide de una forma tan bella. Es por esto quela lista de personas a las que agradecer el que se haya podido realizar estetrabajo es, en realidad, in�nita ...

Los más cercanos y evidentes, sin cuya valiosa existencia y ayuda no ten-dríamos hoy estas páginas en las manos, son mis directores de tesis : Horten,Daniel y Julio, que además fueron compañera y profesores en la carrera, res-pectivamente.

Y otros que, no siendo tan evidentes, son sin embargo importantes, porquehan ayudado con muchos pequeños detalles, engorrosos pero imprescindibles:a Marcos por su insuperable capacidad crítica y a Juan Carlos por su maestríacon el LATEX y su generosidad con el tiempo.

A todos mis compañeros de pasillo por su paciencia y cariño, especialmentea Guadalupe, compañera de despacho y de sincronías.

Y a todos los de los pasillos de más allá, por orden geográ�co: Josele,Inma, Victoria, David, Javi, Jose Luis, Ángel, Miguel. A los compañeros deotros edi�cios: Silvia, Dani, Nacho, Manel. A los que ya no vemos por estospasillos: Jose, Javi, Fredy. A todos ellos por los buenos ratos, los consejos y el

apoyo.También a mi padre y mi hermana María, por compartir conmigo su valiosa

experiencia como doctores.Y a mi madre, por ser mi madre.A la hermana Jotika por ayudarme a ampliar la visión y poner las cosas en

contexto en esos momentos en que la mente se cierne sobre un solo objeto deconcentración y parece que no existiera nada más.

A Ross Freeman, visionario inventor y con un precioso apellido.Y a la in�nita lista de todos lo seres, sin los cuales nos estaríamos ninguno

aquí ahora.

GRACIAS

Índice general

1. Introducción 1

1.1. Demandas actuales en computación . . . . . . . . . . . . . . . . 21.2. Dispositivos HW recon�gurables . . . . . . . . . . . . . . . . . . 4

1.2.1. Grano �no vs. grano grueso . . . . . . . . . . . . . . . . 51.2.2. Evolución de las FPGAs . . . . . . . . . . . . . . . . . . 71.2.3. Diseño con FPGAs . . . . . . . . . . . . . . . . . . . . . 15

1.3. Ventajas e inconvenientes de las FPGAs . . . . . . . . . . . . . 171.3.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . 19

1.4. Extensión del Sistema Operativo . . . . . . . . . . . . . . . . . 211.5. Objetivos de este trabajo . . . . . . . . . . . . . . . . . . . . . . 25

2. Estado del arte 29

2.1. Algoritmos complejos, avariciosos en uso de área . . . . . . . . . 312.1.1. Trabajo de O. Diessel . . . . . . . . . . . . . . . . . . . . 312.1.2. Trabajo de K.Bazargan . . . . . . . . . . . . . . . . . . . 342.1.3. Trabajo de H. Walder (I) . . . . . . . . . . . . . . . . . . 362.1.4. Trabajo de A. Ahmadinia . . . . . . . . . . . . . . . . . 38

i

ÍNDICE GENERAL

2.1.5. Trabajo de J. Tabero . . . . . . . . . . . . . . . . . . . . 422.1.6. Trabajo de H. Kalte . . . . . . . . . . . . . . . . . . . . 442.1.7. Trabajo de M. Handa . . . . . . . . . . . . . . . . . . . 462.1.8. Conclusiones: algoritmos complejos . . . . . . . . . . . . 48

2.2. Algoritmos sencillos . . . . . . . . . . . . . . . . . . . . . . . . . 492.2.1. Trabajo de P. Merino . . . . . . . . . . . . . . . . . . . . 492.2.2. Trabajo de H. Walder (II) . . . . . . . . . . . . . . . . . 502.2.3. Conclusiones: algoritmos sencillos . . . . . . . . . . . . . 53

3. Arquitectura del sistema y algoritmo básico 55

3.1. Arquitectura global del sistema . . . . . . . . . . . . . . . . . . 553.2. Modelo de FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3. Modelo de tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4. Esquema del plani�cador . . . . . . . . . . . . . . . . . . . . . . 623.5. Algoritmo para asignación de espacio . . . . . . . . . . . . . . . 643.6. Ejemplo de funcionamiento . . . . . . . . . . . . . . . . . . . . . 693.7. Fusión de particiones . . . . . . . . . . . . . . . . . . . . . . . . 77

3.7.1. Descripción de la fusión de particiones . . . . . . . . . . 793.7.2. Ejemplo de fusión de particiones . . . . . . . . . . . . . . 793.7.3. Implementación de la fusión de particiones . . . . . . . 81

3.8. Algoritmo con fusión de particiones . . . . . . . . . . . . . . . . 823.9. Comparación de resultados con y sin fusión . . . . . . . . . . . . 85

4. Gestión basada en particiones con adaptación dinámica 87

4.1. Análisis del problema para una FPGA sin particiones . . . . . . 894.1.1. Carga de trabajo ideal . . . . . . . . . . . . . . . . . . . 89

ii

ÍNDICE GENERAL

4.1.2. Frecuencia ideal de llegada de tareas . . . . . . . . . . . 934.1.3. Carga de trabajo real. De�nición del parámetro α . . . . 954.1.4. Ejemplo de variaciones de la carga de trabajo . . . . . . 974.1.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . 98

4.2. Análisis del problema para una FPGA con particiones . . . . . . 994.2.1. Distribución de particiones ideal. Parámetro Dp . . . . . 994.2.2. Distribución de particiones no adecuada . . . . . . . . . 102

4.3. Cambio dinámico del número de particiones . . . . . . . . . . . 1024.4. Estimación del número de particiones adecuado a una carga de

trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064.4.1. Caracterización de la carga de trabajo . . . . . . . . . . 106

4.4.1.1. Campana de Gauss . . . . . . . . . . . . . . . . 1074.4.1.2. Distribución de la carga de trabajo en el espa-

cio: parámetros β, δ y γ . . . . . . . . . . . . . 1104.4.1.3. Número de particiones ideal para cada tipo de

distribución . . . . . . . . . . . . . . . . . . . . 1134.4.1.4. Veri�cación con resultados experimentales . . . 118

4.4.2. Forma y tamaño de las distintas distribuciones en parti-ciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.4.3. Resultados experimentales . . . . . . . . . . . . . . . . . 1244.4.3.1. Ejecución de lotes de tareas medianas y grandes 1244.4.3.2. Ejecución de tareas fundamentalmente pequeñas126

4.5. Observación del sistema en tiempo real . . . . . . . . . . . . . . 1284.5.1. Variación de Dp en tiempo real . . . . . . . . . . . . . . 1284.5.2. Ejemplo de variación de Dp en tiempo real . . . . . . . . 129

iii

ÍNDICE GENERAL

4.5.3. Valores críticos de Dp . . . . . . . . . . . . . . . . . . . . 1344.5.4. Ventana de observación del sistema . . . . . . . . . . . . 139

4.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

5. Implementación de la Adaptación Dinámica 153

5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535.2. De�nición de parámetros . . . . . . . . . . . . . . . . . . . . . . 154

5.2.1. Cambio de particiones . . . . . . . . . . . . . . . . . . . 1565.2.2. Posiciones de las bus macros . . . . . . . . . . . . . . . . 1575.2.3. Implementación del cambio gradual . . . . . . . . . . . . 160

5.3. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645.4. Algoritmo de la UAD . . . . . . . . . . . . . . . . . . . . . . . . 172

6. Resultados experimentales 175

6.1. Experimentos con el algoritmo básico 4P . . . . . . . . . . . . . 1766.1.1. Benchmark arti�ciales . . . . . . . . . . . . . . . . . . . 177

6.1.1.1. Conclusiones del análisis de los resultados parabenchmark arti�ciales . . . . . . . . . . . . . . 181

6.1.2. Benchmark sintéticos . . . . . . . . . . . . . . . . . . . . 1866.1.2.1. Conclusiones del análisis de los resultados para

benchmark sintéticos . . . . . . . . . . . . . . . 1896.2. Experimentos con Adaptación Dinámica . . . . . . . . . . . . . 189

6.2.1. Conclusiones del análisis de los resultados para bench-mark de AD . . . . . . . . . . . . . . . . . . . . . . . . . 194

7. Conclusiones y trabajo futuro 197

iv

ÍNDICE GENERAL

7.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1977.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

A. Modelo de recon�guración parcial 203

A.1. Recon�guración parcial en 2D . . . . . . . . . . . . . . . . . . . 203A.2. Técnicas de diseño modular . . . . . . . . . . . . . . . . . . . . 205A.3. Tareas reubicables . . . . . . . . . . . . . . . . . . . . . . . . . 207A.4. Bus de comunicaciones . . . . . . . . . . . . . . . . . . . . . . . 210

A.4.1. Resumen bus Wishbone . . . . . . . . . . . . . . . . . . 211

B. Descripción de la implementación del prototipo 215

B.1. Descripción del entorno y herramientas . . . . . . . . . . . . . . 216B.1.1. Descripción del hardware utilizado . . . . . . . . . . . . 216B.1.2. Herramientas de desarrollo . . . . . . . . . . . . . . . . . 217B.1.3. Con�guración de la Virtex II Pro . . . . . . . . . . . . . 218B.1.4. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Bibliografía 223

Índice de �guras 235

Índice de tablas 239

v

Capítulo 1

Introducción

Puede decirse del mundo desarrollado actual, esta parte del mundo dondenosotros vivimos ahora, que está caracterizado por dos aspectos fundamentales:

• Es una cultura audio-visual: lo que no puede verse ya no vende. Loslibros están siendo desplazados por toda clase de medios audiovisuales:televisión, videojuegos, internet (videos, fotografías ... todo en imáge-nes). Las mentes de las nuevas generaciones apenas pueden manejarse yacon conceptos abstractos no apoyados sobre imágenes, preferiblementeacompañadas por sonido (música, voz, pero algo que suene; el silenciotambién ha caído en desuso).

• Es una cultura de prisas: Vivimos en un tiempo donde todo va muyrápido, la tecnología avanza muy rápido, los coches circulan a gran velo-cidad, las noticias vuelan, la gente corre de un lado a otro... y las personasya no estamos acostumbradas a esperar.

1

Capítulo 1. Introducción

Es un círculo que se realimenta a sí mismo: la tecnología ofrece mayoresy mejores productos y los usuarios nos acostumbramos y demandamos cadavez más. Si fue antes el huevo o la gallina: la pregunta del millón. Nosotrosnos limitaremos a asumir la realidad y a proponer una solución para unapequeña parte del vasto problema, solución que �a pesar de� su sencillez, ycomo probaremos a lo largo de estas páginas, funciona.

1.1. Demandas actuales en computación

Podemos constatar la gran inversión que la industria tecnológica ha reali-zado en los últimos diez años en el desarrollo de sistemas portátiles y audiovi-suales cada vez más complejos y espectaculares, que atrapan nuestra atención.

Y todo ello siempre bajo la presión de un mercado muy competitivo que semueve también a gran velocidad. Los fabricantes de tecnología necesitan sacaral mercado productos cada vez más pequeños, más ligeros, que consuman pocoy que sean baratos.

Esta marcada tendencia se traduce en que los sistemas deben ofrecer cadavez mayores velocidades de proceso de la información (por ejemplo para lasaplicaciones grá�cas), menores consumos (para los sistemas portátiles) y sinaumentar, o preferiblemente disminuir, su tamaño, peso y precio.

Esta situación plantea un serio reto para los diseñadores de sistemas, quenecesitan soluciones buenas, baratas y que salgan rápido al mercado.

Por esta razón han surgido numerosas líneas de investigación en bajo con-sumo, arquitecturas especializadas, nuevas tecnologías ...

Y es dentro de este contexto donde encontramos también numerosas líneas2

Demandas actuales en computación 1.1

de investigación relacionadas con el uso de Dispositivos de Hardware Re-con�gurable (en adelante DHWR), ya que ofrecen un seguro �camino medio�entre la rigidez de los dispositivos especializados (ASICs) y el limitado rendi-miento de los dispositivos de propósito general (microprocesadores), a un costecada vez menor y ofreciendo cada vez mejores prestaciones en cuanto a con-sumo, disponibilidad de elementos básicos programables y memoria on-chip,gracias al aumento en la densidad de integración conseguida en los últimosaños. Esto se muestra en al �gura 1.1.

rendimiento

flexibilidad

μ-procesadores

ASIC

Hardware reconfigurable

Figura 1.1: DHWR: el camino medio

Esta apuesta por los DHWR está fundamentada en el análisis de la ten-dencia de los sistemas computacionales actuales, como ha re�ejado [Poz06]en su trabajo, en el que expone su convicción de que las FPGAs, cuyas si-glas signi�can Matriz de Puertas Programables (de Field Programmable Gate

Array), terminarán siendo las grandes competidoras de las CPUs. En esta lí-nea, [Und04] hace un análisis del rendimiento pico de FPGAs y CPUs y sostiene

3


que el de las FPGAs puede llegar a ser superior.Otros autores destacan la importancia del uso de FPGAs como piezas fun-

damentales integradas en sistemas tradicionales, como por ejemplo [MTAB07],[SLM00], para poder así aprovechar las ventajas computacionales de estos dis-positivos sin perder las ya de sobra conocidas de las CPUs.

1.2. Dispositivos HW recon�gurables

Los DHWR se caracterizan por disponer de una serie de elementos bási-

cos con�gurables, generalmente dispuestos en �las y columnas, que se puedenprogramar y combinar para realizar funciones especí�cas con más e�cacia queun dispositivo de propósito general.

Estos elementos se con�guran a través de algún tipo de mecanismo físi-co cuya disposición determina la función que realizan. Dicha función puedecambiarse de manera sencilla y rápida, tantas veces como sea necesario.

La recon�guración del dispositivo puede ser total o parcial, afectandoa todos los elementos básicos con�gurables o solamente a una parte de ellos.La recon�guración parcial dinámica supone la posibilidad de recon�gurar unaparte del dispositivo sin afectar al funcionamiento del resto.

Los elementos recon�gurables se conectan entre sí y a los pines de entraday salida del dispositivo a través de una red de conexiones, también recon�-gurables.

Los DHWR se dividen en dos grandes grupos: grano �no y grano grueso.Lo que distingue a unos de otros es la complejidad de los elementos básicosprogramables y la anchura de las rutas de datos disponibles. Si se trata de

4

Dispositivos HW recon�gurables 1.2

elementos con�gurables muy básicos (por ejemplo memorias de 16 palabras de1 bit), hablamos de DHWR de grano �no. Si por el contrario los elementosbásicos programables son relativamente complejos (como por ejemplo ALUs),hablamos de DHWR de grano grueso.

Las arquitecturas de grano �no más populares son las FPGAs, que trabajana nivel de bit, ya que es la unidad de información que procesan las celdas lógicasprogramables (CLBs) y por tanto que se transmite de unas celdas a otras pormedio de la red de conexiones del dispositivo. Las FPGAs se con�guran através de un mapa de bits almacenado en la memoria RAM de con�guración.

Los DHWR han demostrado su e�cacia en muchos campos de aplicación,entre los que destacan el procesamiento de imágenes [KCMO06], [OPF06],[JTR+05], etc., los dispositivos portátiles [MVVL02], [GP02] y el encripta-miento de información [SM06], [CG05].

1.2.1. Grano �no vs. grano grueso

Dentro de las líneas de investigación que trabajan con DHWR hay al-gunos autores que proponen utilizar arquitecturas de grano grueso [Har01],[RSÉHB08], [Mei03]. Otros, en realidad la mayoría de ellos, optan por arqui-tecturas de grano �no, fundamentalmente FPGAs: [BKS00], [HV04], [DP05],[DEM+00], [WP02], [ABF+07]. Ambas opciones tienen ventajas e inconvenien-tes, que comentamos a continuación.

Las arquitecturas de grano grueso trabajan con una anchura de palabraque puede variar entre los 8 bits de MATRIX, [MD96], a los 32 bits de Cha-meleon, [SC01]. Esta anchura de palabra permite diseñar rutas de datos con

5


una estructura regular y hacer un uso de área más e�ciente que las FPGAs, alnecesitar una memoria de con�guración de menor tamaño.

La otra ventaja de las arquitecturas de grano grueso es la menor cantidadde información necesaria para con�gurar las unidades básicas programables,lo que se traduce en un menor tiempo de recon�guración que el necesario pararecon�gurar FPGAs.

Las desventajas de las arquitecturas de grano grueso son su menor �exibi-lidad a la hora de diseñar circuitos con anchos de palabra diferente y el hechode que las arquitecturas existentes no son comerciales y por tanto son menosaccesibles para el investigador que las FPGAs. Otro grave inconveniente, elmayor de todos posiblemente, es la ausencia de herramientas de diseño auto-mático para este tipo de sistemas. Debido a que las arquitecturas de granogrueso se desarrollan en entornos académicos de reducido impacto, no se in-vierten recursos en generar compiladores ni herramientas de síntesis, por loque la compilación de aplicaciones a HW es larga y costosa y no es portable aotras arquitecturas.

Por su parte, las FPGAs proporcionan una gran cantidad de elementosmuy básicos programables junto a otros elementos más complejos (multipli-cadores e incluso en algunos casos, procesadores en el chip) que las dotan deuna gran versatilidad para el diseño de circuitos. Existen diferentes fabricantesque las comercializan a precios asequibles y ofrecen una variedad de tamañosde dispositivo que permite seleccionar la adecuada para cada tipo de aplica-ción. Asimismo, en los últimos años los fabricantes de FPGAs han desarrolladoherramientas de diseño y entornos de trabajo que permiten hacer un uso e�-ciente de sus funcionalidades y que parten de una descripción HW de alto nivel

6


estándar, portable a otras arquitecturas.Estas circunstancias, junto al hecho de que en un principio se utilizaron

extensamente en la industria para prototipado rápido de sistemas, las hanconvertido en los DHWR más populares tanto en el ámbito académico como enel sector industrial, a pesar de los inconvenientes antes mencionados: di�cultadde rutado de señales en el dispositivo y tiempos de recon�guración todavíaaltos.

1.2.2. Evolución de las FPGAs

El concepto de hardware recon�gurable se remonta a los años 60 [EBTB63].Estrin fue pionero en la propuesta de acelerar las computaciones por medio desistemas que pudieran adaptarse a diferentes tipos de cálculos y él y su grupopublicaron numerosos trabajos en esta línea. Reddi y Freustel le siguieron conuna propuesta de arquitectura recon�gurable publicada en [RF78].

Pero el avance real en el campo de la computación recon�gurable no llegóhasta mediados de los años 80, cuando aparecieron las primeras FPGAs. Sonnumerosos los autores que han escrito acerca de la evolución de los DHWR,como el propio Estrin [Est02] y autores como Compton [CH02], Hauck [Hau98],Kuon [KTR08] y Leong [Leo08] y es denominador común el hacer un mayorhincapié en las FPGAs, por su importancia en este ámbito.

Las FPGAs fueron inventadas por Ross Freeman (uno de los fundadores deXilinx), en el año 1984, en el Silicon Valley (CA, EEUU) [Xil09]. Se tratabade una tecnología novedosa que integraba la idea de programabilidad de losPLDs, Dispositivos Lógicos Programables (de Programmable Logic Devices),

7


y la e�ciencia en el rendimiento de los ASICs.Las FPGAS utilizaban una gran cantidad de transistores y en aquella época

muchos pensaron que su invento no tendría éxito. Sin embargo, Ross Freemancon�aba en que el precio de los transistores disminuyera rápidamente, conformea lo postulado por la Ley de Moore. Su acertada intuición convirtió a Xilinx enuna de las empresas más prósperas y populares en la fabricación de FPGAs yen un referente para otras empresas que también las fabrican, como son Alteray Atmel.

Las primeras FPGAs eran similares en capacidad a los PLDs más grandesy fueron utilizados en un principio como alternativa a los costosos ASICs enpartes de los diseños que correspondían a módulos no existentes en el mer-cado. La primera familia de FPGAs, la XC2064, salió al mercado en 1985. Amodo de curiosidad podemos comentar que formaba parte de los componentesrecon�gurables del computador personal Commodore-Amiga.

Las capacidades de las FPGAs siguieron aumentando y empezaron a utili-zarse en prototipado rápido y de bajo coste de circuitos a medida, incluído elprototipado de procesadores. Este popular uso de las FPGAs se ha mantenidohasta nuestros días.

En 1991 salió al mercado la XC4000, que suele citarse como la arquitecturao familia típica de FPGAs de gama media. Están compuestas por una matrizde bloques básicos con�gurables (CLBs), cada uno de los cuales contiene unasección (slice) con tres LUTs, Tablas de Verdad (de Look-up Tables), que sontablas de 16 x 1 bit que permiten implementar funciones lógicas sencillas) y dos�ips-�ops. Además disponen de lógica esencial para propagación de acarreo.Las capacidades de estos dispositivos varían desde la más pequeña con una

8


matriz de 8 x 8 CLBs hasta la mayor de ellas, con 56 x 56.La interconexión de CLBs se realiza por medio de líneas de conexiones

organizadas jerárquicamente y de una matriz de PSMs o Matrices de Con-mutación Programables (de Programmable Switching Matrix ) intercaladas aintervalos regulares en la matriz de CLBs, como muestra la �gura 1.2. Ademásexisten líneas de interconexión especí�cas para la distribución de la señal dereloj y para la propagación de acarreo (local, de alta velocidad).

Figura 1.2: Interconexiones jerárquicas (XilinxTM )

Los bloques de entrada y salida (IOB) se encuentran situados en los bordesdel dispositivo, cada uno de ellos conectado a un pin del chip FPGA. Estosbloques son también con�gurables (por medio de celdas RAM) y puede elegirseel sentido del �ujo de información a través del pin así como característicaseléctricas y de temporización, lo que permite al dispositivo integrarse en unagran variedad de sistemas.

9


Este dispositivo se puede recon�gurar in�nitas veces y la con�guración estotal, lo que signi�ca que no se pueden con�gurar partes del dispositivo deforma independiente. La con�guración se realiza por medio de la escritura deun conjunto de bits, llamado mapa de bits de con�guración, que determinan elestado de una celda de memoria estática. Los valores de estas celdas controlanla función realizada por una LUT, la entrada de control de un multiplexor oun transistor de una celda PSM.

Esta arquitectura inicial de la familia XC4000 ha servido de base para lassucesivas familias de Xilinx, que pasamos a comentar.

En el año 1998 empieza la saga Virtex, que citando a Xilinx supone �ungran paso en la arquitectura de las FPGAs� y cuyas características resumimosen la tabla 1.1 y comentaremos más adelante.

La �gura 1.3 muestra las arquitecturas básicas de las dos primeras familiasVirtex, que fueron lanzadas al mercado en años sucesivos. Su estructura essimilar y muy básica: bloques de memoria RAM intercalados con la matrizde CLBs, un elevado número de CLBs disponibles en relación a la XC4000 ylas PLDs existentes hasta el momento y recon�gurables tantas veces como sequiera pero siempre la totalidad del dispositivo.

El siguiente año sale un nuevo miembro de la familia Virtex al mercado: laVirtex-2, que además de mejorar a sus hermanos mayores en cuanto a capaci-dad de procesamiento, cantidad de RAM disponible en el chip y aumento dela frecuencia de trabajo, dispone de módulos multiplicadores de 18 x 18 bits ycapacidad de recon�guración parcial dinámica.

Como ya se mencionó anteriormente, esta característica de la familia Vir-tex permite recon�gurar partes del chip sin afectar al funcionamiento de otras,

10


Figura 1.3: Arquitectura de la Virtex (izda) y la Virtex-E (dcha) (XilinxTM )

lo cual dota a la FPGA de una versatilidad muy alta y la capacita para rea-lizar multitarea hardware. Esta característica de las FPGAs ha hecho crecersu popularidad notablemente en estos últimos ocho años. La recon�guraciónparcial se realiza por columnas: la mínima parte de la FPGA que se puederecon�gurar de forma independiente al resto es un frame, cuya altura es iguala la del dispositivo y con anchura de 1 bit.

Esta novedosa característica supone una di�cultad mayor a la hora de di-señar con estos dispositivos y las herramientas, documentación y entorno dediseño empiezan a aumentar en volumen y di�cultad.

La �gura 1.4 muestra un esquema de la arquitectura general de esta familia,bastante similar a la de sus predecesoras.

Dos años después Xilinx lanza al mercado la Virtex-2 Pro, una FPGA quesupera a todas las anteriores en cuanto a capacidad de procesamiento ya queincluye dos procesadores Power PC. Se pueden con�gurar hasta dos de estosprocesadores, incrustados en la matriz de CLBs, según indica la �gura 1.5.

11


Figura 1.4: Arquitectura de la Virtex-2 (XilinxTM )

Con otros dos años de diferencia, en 2004, nace la Virtex-4, una gran FPGAque incluye todos los elementos antes citados, supera a sus antecesoras envelocidad, memoria en el chip, módulos aritméticos y que es recon�gurable endos dimensiones.

Para esta FPGA ya no es necesario recon�gurar una columna completa deCLBs, sino que un frame abarca una altura de 16 CLBs. Esto signi�ca que elmínimo bloque recon�gurable es de 1x16 CLBs y permite realizar recon�gura-ción parcial dinámica en 2D.

Con características similares, aparece la Virtex-5 en el mercado otros dosaños después, con una cantidad mucho mayor, tanto de elementos con�gurables

12


Figura 1.5: Arquitectura de la Virtex-2 Pro (XilinxTM )

como de memoria RAM interna.Conforme evoluciona la complejidad de la familia Virtex, Xilinx desarrolla

herramientas de diseño cada vez más completas y complejas, requiriendo deldiseñador una preparación mayor y el manejo de volúmenes de documentaciónmuy considerables.

La tabla 1.1 muestra que los tamaños de los mapas de bits de con�guraciónaumentan notablemente con la capacidad y complejidad del circuito FPGA.Esto redunda en mayores tiempos de recon�guración y la necesidad de utilizarmás cantidad de memoria para almacenarlas.

El proceso de recon�guración se hace más complejo y las necesidades de13


Tabla 1.1: Resumen de la familia Virtex

Familia Año Rec. CLBs CLK Mem. Mapa de bits(MHz)

Virtex 1988 1D 64 x 96 200 122 Kb 6.127.744 bitsVirtex-E 1989 1D 104 x 156 300 832 Kb 16.283.712 bitsVirtex-2 2000 1D 112 x 104 420 3 Mb 26.194.208 bits

Virtex-2 Pro 2002 1D 120 x 94 450 8 Mb 34.292.768 bitsVirtex-4 2004 2D 192 x 116 500 10 Mb 51.325.440 bitsVirtex-5 2006 2D 240 x 108 550 16 Mb 70.848.000 bits

entrada y salida del dispositivo aumentan. Aunque no viene re�ejado en latabla, el número de pines de entrada y salida de las FPGAs ha ido creciendo,así como la velocidad de transmisión de información a través de ellos, con el �nde proporcionar su�cientes pines para las tareas ejecutándose en el dispositivoy para paliar el aumento de tiempo de recon�guración debido al aumento detamaño de los mapas de bits.

Intercalada con la familia Virtex, en el año 2003, aparece la familia Spartande Xilinx, de bajo coste (hoy pueden comprarse por 1$) y menores prestacionesy consumo de potencia que las FPGAs de la familia Virtex, pensada para suutilización en productos de fabricación a gran escala, y cuya existencia es unaprueba de la creciente popularidad y uso comercial de las FPGAs.

Merece la pena mencionar también una familia de FPGAs de la que Xilinxno hace mención en su web, la XC6200, y que sin embargo ha sido muy popu-lar entre los investigadores que han trabajado con DHWR en los años 90. Larazón por la que se ha utilizado tan extensamente esta familia en el campo dela investigación ha sido la posibilidad (exclusiva de esta FPGA en ese momen-to) de recon�gurarla dinámicamente en 2D. Se trata de FPGAs de pequeña

14


capacidad (matrices de CLBs muy sencillos de dimensiones entre 48 x 48 y128 x 128) que se puede recon�gurar a nivel de celda, a través de un interfazparalelo llamado FastMap y que dispone de varios mecanismos para comprimirmapas de bits de con�guraciones y agilizar el proceso de recon�guración.

En resumen, nos encontramos ante una tecnología novedosa en pleno desa-rrollo y rápida evolución (solamente ocho años desde la aparición de la primeraVirtex en el mercado), con un brillante futuro por delante y todavía muchocamino que recorrer en cuanto a desarrollo de herramientas de diseño, dismi-nución de los tiempos de recon�guración y mejora en las comunicaciones entrelos elementos con�gurables.

Y siguiendo la intuición de Ross Freeman, que falleció en el año 1989, tansólo cuatro años después de la comercialización de la primera FPGA de Xilinx,nosotros apostamos también por esta �tecnología del camino medio�.

1.2.3. Diseño con FPGAs

El proceso de diseño con diferentes tecnologías HW es conocido como com-

pilación hardware. El diseño con FPGAs se enmarca dentro de este contexto.Un algoritmo o tarea debe ser descrito en un lenguaje de alto nivel que estédirectamente relacionado con elementos HW para su fácil traducción a un cir-cuito.

En los últimos 15 años se ha popularizado y extendido el uso de los llamadoslenguajes de descripción HW (HDL, Hardware Description Language), entrelos cuales destacan Verilog, [ver08] y VHDL, [vhd06].

El primer paso para compilar una tarea a HW es describir el algoritmo en15


alguno de los HDLs disponibles, típicamente en VHDL.El siguiente paso es determinar qué tipo de bloques HW son necesarios

y cómo están conectados entre sí y después, el tercer paso, que consiste enasignar bloques básicos con�gurables concretos de la FPGA (CLBs) y rutadode señales entre ellos.

En el cuarto paso del proceso se obtiene el mapa de bits de con�guraciónnecesario para que los CLBs utilizados en el diseño del circuito realicen cadauno la funcionalidad necesaria.

Por último, es necesario escribir dicho mapa de bits en la memoria decon�guración del dispositivo.

La �gura 1.6 re�eja el proceso explicado.En la actualidad existen herramientas de compilación HW que traducen de

forma automática (y con bastante e�ciencia) un algoritmo descrito en VHDLa la arquitectura de FPGA que se esté utilizando, lo que da como resultadoun bajo tiempo de compilación HW junto a un aceptable uso de recursos deldispositivo. Además, estas herramientas permiten al diseñador imponer ciertasrestricciones al programa a la hora de asignar CLBs, rutado etc.

La parte más delicada del proceso de compilación HW, y la más difícilde realizar de forma automática es, es el rutado de señales dentro de los dis-positivos. Por este motivo, los diseños con grandes restricciones temporalesgenerados de forma automática con herramientas de diseño HW suelen serrevisados por el diseñador antes de la generación del mapa de bits de con�gu-ración, y el rutado generado de forma automática es frecuentemente retocadode forma manual.

16

Ventajas e inconvenientes de las FPGAs 1.3

Figura 1.6: Etapas de diseño con FPGAs

1.3. Ventajas e inconvenientes de las FPGAs

1.3.1. Ventajas

A pesar de que no carecen de inconvenientes, las características de estosdispositivos los han convertido en la actualidad en una equilibrada soluciónpara las demandas actuales de los sistemas de computación.

A continuación pasamos a enumerar la lista de los bene�cios de utilizarFPGAs como parte de un sistema de computación de propósito general.

17


• Aumento de la velocidad de procesamiento: ya que con las FPGAspodemos obtener mejores tiempos de ejecución gracias a dos factores:

1. Procesamiento hardware: la velocidad de ejecución de un cir-cuito hardware especí�camente diseñado para realizar una tarea essiempre mayor que la de un código software de alto nivel ejecutadoen un procesador de propósito general.

2. Explotación de paralelismo: la posibilidad de descomponer unaaplicación en tareas o subtareas y de explotar el paralelismo es unarealidad en los dispositivos FPGAs, ya que diferentes tareas puedenser ejecutadas simultáneamente en el dispositivo, si se dispone desu�cientes elementos básicos para con�gurar los circuitos simultá-neamente. La multitarea HW también es factible en los dispositivosactuales, gracias a las técnicas de diseño modular.

• Reducción de Consumo: ya que se pueden aplicar técnicas que evitanel consumo de energía innecesario, combinadas con otros factores:

1. Avances en la tecnología: el consumo de las FPGAs ha ido dismi-nuyendo desde su aparición en el mercado, alcanzando unos nivelesmuy aceptables en el presente. Asimismo existen ya propuestas denovedosas tecnologías que podrían fabricarse en un futuro cerca-no y que según los resultados presentados por [BTAS07] consumenhasta 25 veces menos que un circuito recon�gurable fabricado contecnología CMOS.

2. E�ciencia de diseño: debido a la gestión multitarea, solamente18

Ventajas e inconvenientes de las FPGAs 1.3

aquellas partes de una aplicación que se necesiten en cada momentoestarán siendo ejecutadas en el dispositivo, y por tanto se reduce elconsumo al mínimo necesario para la ejecución de una aplicación encada momento.

3. Técnicas: existen numerosas líneas de investigación dedicadas adesarrollar técnicas de trabajo con las FPGAs que permiten ahorrarenergía [NB04], [PRMC07].

• Flexibilidad: la posibilidad de recon�gurar los elementos básicos, porpartes o en su totalidad, dota a los diseños realizados sobre FPGAs dela �exibilidad necesaria para adaptarse a bajo coste a un mercado quecambia con rapidez.

• Coste: el aumento en la popularidad de las FPGAs y los avances en latecnología de fabricación han permitido que los precios de estos disposi-tivos bajen también a una velocidad que empieza a ser competitiva conrespecto a otros dispositivos tradicionales.

A todas estas ventajas podemos sumarle la aparición de herramientas yentornos de desarrollo cada vez más completos y documentados para trabajarcon estos dispositivos.

1.3.2. Inconvenientes

Aunque los puntos a favor de utilizar FPGAs son muchos y están sólida-mente probados por la literatura, existen sin embargo dos aspectos importantesa tener en cuenta a la hora de su utilización:

19


1. Rutado de señales: como se comentó en la sección 1.2.3, el rutado ob-tenido a partir de una compilación automática no es el óptimo y suele sernecesaria una revisión por parte del diseñador y la realización de algunosretoques manuales. No obstante, los fabricantes de FPGAs conocen estadi�cultad y están trabajando para ofrecer al mercado arquitecturas deFPGAs donde se mejoren las posibilidades de conexión entre celdas ló-gicas. Algunos autores han propuesto ya diseños en 3D [DWM+05], queofrecen grandes posibilidades en este aspecto.

2. Tiempo de recon�guración: una de las críticas más usuales al uso deFPGAs dinámicamente recon�gurables para ejecución multitarea HW esel elevado tiempo de recon�guración del dispositivo o partes de él. Estetiempo está en la actualidad en el orden de los ms y es proporcional alárea de dispositivo recon�gurada (tamaño del mapa de bits de con�gu-ración). Puesto que representa el cuello de botella real de los sistemasmultitarea HW, encontramos pruebas de los numerosos esfuerzos dirigi-dos a mejorar este aspecto, que pasamos a comentar:

a) Investigación de nuevas tecnologías: tal es el caso de [WK07],que han implementado una matriz de puertas dinámicamente re-con�gurable con tecnología óptica y tiempos de recon�guración delorden de los nanosegundos.

b) Propuestas de nuevas arquitecturas para FPGAs: las pro-puestas de arquitecturas multicontexto, que permiten cargar unanueva con�guración en el chip mientras todavía se está ejecutandouna tarea en él, permitirían mejorar la velocidad de recon�guración,

20

Extensión del Sistema Operativo 1.4

directamente ligada a la lectura del mapa de bits de memoria y suescritura en la FPGA. En trabajos como [MM06] se ha investigadoen esta línea.

c) Desarrollo de técnicas de recon�guración: especialmente di-señadas para minimizar el tiempo de recon�guración. En [LH01] sepresentan técnicas de compresión del mapa de bits de con�gura-ción y en [LCH00] se ha propuesto utilizar caches para guardarlosy con ello acelerar el proceso de escritura del mapa de bits en laFPGA, así como en [RMC05], donde se han desarrollado técnicas depre-búsqueda de mapas de con�guraciones basadas en una correctaplani�cación de los módulos a recon�gurar.

1.4. Extensión del Sistema Operativo

Como se mencionó anteriormente, muchos autores proponen la inclusiónde dispositivos dinámicamente recon�gurables en sistemas tradicionales conobjeto de mejorar su rendimiento. Esto supone un nuevo reto para el diseño deSistemas Operativos ya que deben ser ampliados con nuevas funcionalidadesrelacionadas con la gestión del DHWR. Algunos autores han estudiado ya losrequisitos de estos nuevos Sistemas Operativos, como es el caso de [DW99] y[WK02].

De hecho, el desarrollo de Sistemas Operativos para DHWR es un áreade investigación en auge. Los primeros trabajos teóricos son de �nales de losaños 90 [DW99]. La di�cultad de la tarea reside, entre otros factores, en elrápido avance en la tecnología de FPGAs que, como se revisó en la sección

21


1.2.2, ofrece cada poco tiempo nuevos y más completos modelos de FPGAscon funcionalidades y características en claro y rápido aumento, lo que porotro lado hace aumentar la complejidad y nivel de experiencia requerido paratrabajar con ellas.

En estos casos, el Sistema Operativo (SO) debe decidir en cada momentoqué tareas se ejecutarán en la CPU y cuáles en la FPGA, dependiendo de ladisponibilidad de recursos (uso de la CPU, uso de la FPGA, tiempo límitepara ejecutar una tarea, dependencias entre tareas, disponibilidad del mapade bits, prioridad etc.). Además el SO dispondrá de un gestor especí�co paraHW, parte del cual puede estar implementado en el propio DHWR.

Dicho gestor hardware es la parte novedosa de este tipo de sistemas y portanto se hace necesario analizar en detalle cuáles serán las funcionalidades quedebe desempeñar.

Se puede imaginar un recurso HW con recon�guración parcial dinámicacomo una gran super�cie de procesamiento que puede contener un conjunto detareas, cada una de las cuales ha sido compilada a un mapa de bits reubicablecon las herramientas de compilación disponibles, y puede ser cargada en unazona libre de la FPGA cuando se precise su ejecución. Cada tarea HW puedecargarse o abandonar la FPGA sin afectar a las otras tareas que se estánejecutando, de la misma manera que ocurriría en un sistema SW multitarea.Si la tarea necesita parámetros de entrada o produce resultados entonces hayque proporcionarle un mecanismo que la conecte con los pines de entrada ysalida del circuito.

Veamos a continuación algunas de las funciones que consideramos sería pre-ciso realizar para permitir que el SO gestione unos recursos HW dinámicamente

22

Extensión del Sistema Operativo 1.4

recon�gurables de gran capacidad:

• Compilación de las tareas a código HW reubicable: Las tareasque puedan ser susceptibles de ejecutarse en HW deberán haber sidocompiladas para el HW objetivo, dando como resultado un código HWreubicable que pueda ser luego cargado donde se disponga de espaciolibre.

• Mantenimiento de la información sobre los recursos HW dis-

ponibles en cada momento: El SO debe disponer en todo momentode la información necesaria acerca del estado de los recursos HW, parapoder tomar decisiones relativas a su gestión.

• Control de admisión/plani�cación de tareas HW: En el contextode un SO multitarea, la decisión de admisión o plani�cación de las tareasHW deberá basarse en criterios como secuenciamiento, disponibilidad derecursos, penalización en el rendimiento total en caso de no ejecutar-se, tiempo máximo de ejecución de tareas, etc. Las consideraciones deprioridad podrían hacer incluso que algunas tareas menos prioritariasen ejecución salgan de HW temporalmente para dejar paso a otras másurgentes.

• Asignación de los recursos HW concretos en los que se va a

ubicar cada tarea: Partimos, como ya hemos dicho antes, de que elcódigo HW de la tarea es de naturaleza reubicable, por lo que podemoselegir la ubicación que más nos convenga. Esta función puede conllevaruna defragmentación previa, si se comprueba la existencia de recursos

23


su�cientes, pero distribuidos por el dispositivo.• Carga del código HW reubicable: La carga del código HW, queconlleva la transferencia desde la memoria en la que se almacena hastael HW recon�gurable (incluyendo la traducción de código reubicable acódigo absoluto, a partir de las decisiones de asignación de HW), y laconsiguiente recon�guración dinámica de parte del mismo, es la tareaque supone un mayor retardo.

• Liberación del HW ocupado por tareas que han �nalizado: Ten-dría lugar cuando se detecta la �nalización de una tarea, y conllevaríala actualización de la información disponible por el SO. Este dinamismofrecuentemente da lugar a la fragmentación del espacio libre, haciendonecesario en algunos casos llevar a cabo un proceso de defragmentación.Es posible también tener en cuenta otro tipo de consideraciones, comopor ejemplo, no liberar el HW ocupado por una tarea si se prevé quepuede ser vuelta a cargar y no es preciso reutilizar el espacio de HWrecon�gurable que ocupa. En esta aproximación, la información del sis-tema sobre la ocupación del HW recon�gurable debería distinguir entrerecursos libres, usados, y ocupados pero no usados. Esta distinción, quepuede permitir eliminar la necesidad de la recon�guración en algunos ca-sos, complica notablemente la tarea de defragmentación, que se comentaa continuación.

• Defragmentación de HW: mediante reubicación de las tareas HW yaen ejecución para permitir el reagrupamiento del HW fragmentado a �nde que pueda ser aprovechado de manera más e�ciente.

24

Objetivos de este trabajo 1.5

Como ya se ha mencionado al principio de esta sección, buena parte de lasfunciones y estrategias que se han ido proponiendo podrían ser implementadasen el propio DHWR, posiblemente incorporadas a su arquitectura interna.

1.5. Objetivos de este trabajo

Como se ha explicado en la sección 1.1, estamos trabajando en una líneade investigación con DHWR como solución a las crecientes necesidades en lossistemas de computación de propósito general. Y entre los DHWR existenteshemos optado por las FPGAs, por sus muchas ventajas frente al resto dedispositivos recon�gurables.

Para poder gestionar una FPGA como parte de un sistema de computacióngeneral, es necesario extender las funcionalidades tradicionales del SO. Una delas tareas que debe realizar un SO que gestione DHWR es la de mantenerinformación actualizada del espacio libre en el dispositivo y gestionar dichoespacio, es decir, asignar recursos a las nuevas tareas que se van a ejecutar enél.

El presente trabajo se ha centrado en algunas de las funciones que el gestorde HW necesita realizar, en concreto: el mantenimiento de información sobreel dispositivo hardware, el control de admisión / plani�cación de ejecución detareas y la ubicación de las tareas en la FPGA. La funcionalidad de defrag-mentación de hardware deja de ser necesaria en un modelo de gestión de áreade FPGA como la que proponemos aquí.

Dentro de esta línea de investigación existen numerosos trabajos que tratande resolver este problema y que explicamos en detalle en el capítulo 2. Existen

25


dos tendencias dentro del grupo de investigadores de este campo: una cuyoobjetivo es aprovechar al máximo el área del dispositivo, lo cual obliga a utilizarestructuras de datos complejas y algoritmos de búsqueda de espacio libre lentosy complejos, y otra, dentro de la cual se encuentra el trabajo presente, quebusca sencillez y rapidez de respuesta ante la llegada de una nueva tarea sinpor ello perder e�ciencia en el uso del dispositivo HW.

Los algoritmos de ubicación complejos tienen además el inconveniente deque asumen que una tarea se puede ubicar en cualquier posición dentro de laFPGA y esto en la actualidad resulta del todo alejado de las posibilidades realesde recon�guración parcial dinámica de los dispositivos existentes. Presentantambién el inconveniente de que di�cultan la entrada / salida de datos. Ademáslas nuevas FPGAs que están saliendo al mercado y las herramientas de diseñodisponibles no solamente no lo permiten sino que no dan lugar a pensar queen corto o medio plazo esto pueda ser así.

Nuestro trabajo se ha centrado en desarrollar un plani�cador que asig-ne una ubicación para que una tarea pueda ejecutarse en una FPGA en laque hay otras tareas ejecutando, sin perturbar su funcionamiento (multitareahardware) y nos hemos propuesto que cumpla los siguientes objetivos:

1. Sencillez: estructuras de datos sencillas para mantener la informaciónactualizada respecto al espacio libre en la FPGA, fáciles de implementaren un sistema real.

2. Rapidez de respuesta: el algoritmo de asignación de espacio para unanueva tarea en la FPGA debe ser rápido y fácil de implementar.

3. Realismo: el algoritmo propuesto debe estar basado en las posibilidades26

Objetivos de este trabajo 1.5

reales de la tecnología existente y poder ser implementado en las FPGAsactuales.

4. E�ciencia: el algoritmo no puede sacri�car los costosos recursos HWpor su sencillez de planteamientos.

5. Flexibilidad: el algoritmo debe ser capaz de auto-ajustarse cuando lascircunstancias así lo requieran, para aprovechar al máximo los recursosdisponibles.

El resto del texto que presenta nuestro trabajo se ha estructurado de lasiguiente manera: en el siguiente capítulo presentaremos el trabajo previo re-lacionado con nuestro tema de investigación. En el capítulo 3 describiremosel modelo de sistema utilizado junto con el entorno plani�cador básico. En elcapítulo 4 expondremos el estudio realizado para implementar la adaptacióndinámica del entorno a diferentes circunstancias y a continuación, en el capítulo5 mostraremos en detalle cómo se ha implementado dicha funcionalidad.

A continuación, en el capítulo 6, presentamos los resultados experimentalesque demuestran la e�ciencia del algoritmo con y sin la funcionalidad de adap-tación dinámica, y en el último capítulo las conclusiones obtenidas a partir dela realización de esta investigación y algunas líneas de trabajo futuro que deella se podrían derivar.

27

Capítulo 2

Estado del arte

En este capítulo revisaremos el trabajo previo relacionado con nuestro temade investigación. Presentaremos las principales aportaciones en el campo de losalgoritmos de admisión, plani�cación y ubicación de tareas HW en un DHWR(que en adelante restringiremos a FPGAs).

Las primeras propuestas para este tipo de algoritmos son de los años 90y muchos de ellos están basados en estudios matemáticos relacionados con elproblema de empaquetamiento o bin-packing, aunque es preciso observar queen ninguno de los casos que mencionaremos se conoce a priori el conjuntode tareas que se van a ejecutar en la FPGA ni sus características. Se tratade resolver el problema de empaquetamiento �sobre la marcha� (técnicamente,on-line) y podríamos hacer un símil con el juego de tetris, en que �guras deformas diversas van cayendo y es preciso buscarles el mejor lugar posible enel espacio dejado por el montón de �guras que cayeron anteriormente y cuyoper�l va cambiando a lo largo del juego.

A diferencia de los algoritmos para bin-packing, en el caso de nuestros29

Capítulo 2. Estado del arte

algoritmos únicamente se dispone de información acerca de la tarea que hallegado a la FPGA para su ejecución y se puede calcular el espacio disponible enla FPGA en ese momento y el que quedará libre cuando terminen de ejecutarselas tareas presentes en la FPGA. Cualquier decisión que se tome respecto allugar donde dicha tarea se ubicará se hace sin conocimiento alguno de cuándollegará la siguiente tarea ni cuál será su tamaño ni su tiempo de ejecución.

En la mayoría de los casos los autores trabajan con un modelo de tarearectangular y los únicos cambios de forma permitidos se limitan a la rotación.En muy pocos casos los autores consideran tareas no rectangulares y cambiosde forma.

Las metodologías utilizadas para resolver el problema son diversas peropueden clasi�carse en dos grupos claramente diferenciables: los algoritmos com-plejos y los algoritmos sencillos.

Llamamos algoritmos complejos (y añadimos la coletilla �avariciosos en usode área�) a aquellos algoritmos que dan prioridad al uso intensivo de área deldispositivo y proponen soluciones que tratan de optimizar el uso de área acosta de utilizar estructuras de datos de gran complejidad para representar elespacio libre en la FPGA y que precisan de algoritmos de complejidad altapara localizar un espacio libre que pueda albergar la tarea. El mantenimientode la información del espacio libre en la FPGA (actualización de informacióncuando una tarea termina su ejecución) es también muy costoso en cálculos.

Las propuestas de algoritmos sencillos se centran en la rapidez de respuesta,una e�cacia de uso de área competitiva y el pragmatismo (implementaciónsencilla y realista).

Pasamos ahora a revisar los trabajos publicados en la línea de algoritmos30

Algoritmos complejos, avariciosos en uso de área 2.1

complejos.

2.1. Algoritmos complejos, avariciosos en uso de

área

2.1.1. Trabajo de O. Diessel

El pionero en este tipo de estudios es O. Diessel, de la Universidad de SouthNew Wales (Australia), que escribió su tesis doctoral en el año 1998 [Die98].Es un trabajo muy completo donde se presentan tres técnicas diferentes: dosde ellas para representar el espacio libre en la FPGA (una basada en unaestructura en árbol y la otra en un grafo de visibilidad) y una tercera para 1Ddonde se propone una modi�cación arquitectónica que permite determinar elnúmero de columnas libres contiguas.

Aunque este trabajo se centra en resolver el problema de la correcta re-presentación del espacio libre disponible en la FPGA y la forma de asignarespacio para las nuevas tareas, propone también métodos de defragmentaciónasociados con las heurísticas de plani�cación que permiten agrupar el espaciolibre de la FPGA.

Tanto en su tesis como en su artículo [DE01], el autor presenta dos heu-rísticas de representación del espacio disponible en la FPGA cuyo objetivo esrepresentar con �delidad la situación actual del dispositivo y permitir la aplica-ción de métodos e�caces que determinen si existe la posibilidad de compactarespacio y de aplicar heurísticas que determinen la mejor manera de hacerlo(mover el mínimo de tareas y causar el mínimo retraso en su ejecución).

31


El autor parte de un modelo de FPGA en el que se asume la posibilidadde insertar una tarea para ejecución en cualquier posición del dispositivo.

El primero de los algoritmos propuestos por Diessel utiliza una estructuraen árbol para almacenar la información de área de FPGA disponible y deberecorrerlo para encontrar un hueco adecuado donde situar cada nueva tareaHW que llega al DHWR.

Dicha estructura se muestra en la �gura 2.1: en cada nivel del árbol (siendoel raíz todo el área de la FPGA) cada rectángulo se divide en cuatro rectán-gulos menores, cada uno de los cuales es un nodo que se marca como libre,ocupado o parcialmente libre. Dicho árbol jerárquico se recorre con rapidez,pero esta estructura puede dar lugar a situaciones en las que exista un huecolibre su�cientemente grande y que no se identi�que debido a que esté repartidoentre nodos/ramas diferentes del árbol.

El orden de complejidad del algoritmo que construye el árbol es de O(m ·n)(donde n es el número de tareas y m la dimensión de la FPGA) y hay querepetirlo cada vez que una tarea termina su ejecución para mantener actuali-zada la información acerca del uso de área de la FPGA. Esta heurística, comohemos explicado anteriormente, debe inevitablemente actuar conjuntamentecon otra que permita defragmentar la FPGA, y para ello propone una técnicade reubicación con una complejidad de O(n3), donde n es el número de tareasejecutándose en la FPGA.

El segundo de los algoritmos utiliza un grafo de visibilidad, �gura 2.2, enel que se dispone de la información de la posición de cada tarea en la FPGAy las posibles posiciones que podría desplazarse hacia su derecha. Recorriendoel grafo en orden inverso puede determinarse la máxima compactación que se

32


Figura 2.1: Estructura de árbol propuesta por Diessel

puede conseguir en la FPGA y a partir de ahí determinar si quedaría su�cienteespacio libre en la FPGA tras la defragmentación.

En otro artículo [BD01] Diessel y sus colaboradores presentan una propues-ta de implementación en 1D del último algoritmo mencionado, con HW espe-cí�co para determinar el número de columnas contiguas libres en una FPGAy la posibilidad de aplicar el método de compactación (ligado a la heurísticadel grafo de tareas).

Destacamos el hecho de que en sus publicaciones más recientes, el gru-po de Diessel está trabajando en temas más cercanos a la implementación yponiendo mucho énfasis en solucionar los problemas relacionados con las co-

33


Figura 2.2: Grafo de visibilidad propuesto por Diessel

municaciones entre tareas y de las tareas con los pines de entrada/ salida.En su artículo [KD06] estudian las posibilidades reales de implementación demultitarea hardware en una Virtex-4 y proponen una gestión del espacio de laFPGA en 2D.

2.1.2. Trabajo de K.Bazargan

Otros autores, como K.Bazargan, de la Universidad de Minnesota (EEUU),utilizan heurísticas de bin-packing y aplican algunos de los algoritmos clásicoson-line y o�-line (donde se conoce de antemano el conjunto de tareas a ejecu-tar) que existen para dicho problema teórico, pero todos tienen un orden decomplejidad muy alto y se basan también en la hipótesis de que las tareas sepueden insertar en posiciones arbitrarias de la FPGA. Centraremos el estudiode este autor en las heurísticas on-line que ha presentado.

34


La �gura 2.3 muestra un ejemplo de la técnica utilizada por Kia Bazarganen [BKS00] y [BS99] para representar el área libre de la FPGA, basada en unconjunto de Rectángulos Máximos Disponibles, los MER (Maximum EmptyRectangles), que en la �gura aparecen nombrados por letras. Estos rectángulosrepresentan máximas áreas libres en la FPGA y pueden estar solapadas entresí.

Figura 2.3: Organización en MER propuesta por Bazargan

El sistema dispone de una lista de MER. Cuando una nueva tarea llegaal sistema, se recorre la lista en busca de un MER que sea su�cientementegrande como para albergarla. A diferencia de la propuesta de O. Diessel, si noexiste hueco en la FPGA, la tarea es rechazada, no se aplica ninguna técnicade defragmentación para hacerle hueco.

Si existen varios posibles MER en los que pueda ubicarse la tarea, se aplicauna heurística de selección que puede ser desde la opción más sencilla, el pri-mero encontrado, hasta una opción compleja que analiza cuál de ellos es mejor.Una vez seleccionado el rectángulo donde se ubicará la tarea, ésta se sitúa enla esquina inferior izquierda del rectángulo y se procede a la actualización de la

35


lista de MER. Esta lista también debe ser actualizada cada vez que una tareatermine su ejecución.

Como podemos observar, se trata de nuevo de un algoritmo de elevadacomplejidad. Solamente el mantenimiento de la lista actualizada de MER tienecomplejidad O(n2), donde n es el número de tareas que se están ejecutando enla FPGA.

Para obtener un algoritmo de menor complejidad el autor propone unaheurística en la que no se permite que los rectángulos vacíos se solapen. Elresultado es un algoritmo de complejidad O(n) y que resulta más rápido ensu ejecución pero que pierde e�ciencia en uso de área, ya que a veces existeespacio libre no identi�cado por los rectángulos marcados.

2.1.3. Trabajo de H. Walder (I)

Un autor que también ha trabajado en este problema es H. Walder, delInstituto Federal de Tecnología (Suiza). En un principio, es el único que consi-dera tareas que pueden ser de forma no rectangular y tiene en cuenta posiblescambios de forma [WP02]. Este autor supone que las tareas están formadas porsub-tareas rectangulares (�gura 2.4) y estudia los cambios de forma en funciónde las diferentes combinaciones posibles de subtareas, aunque abandonaronesta interesante idea por su complejidad.

En la publicación [WSP03] presenta una heurística basada en la de Bazar-gan en la que retrasa la decisión de dividir el área libre en rectángulos máximosno solapados y utiliza una tabla que permite un rápido acceso a la lista de rec-tángulos. La �gura 2.5 nos muestra un ejemplo de la gestión del área libre

36


Figura 2.4: Cambios de forma, Walder

propuesta por este autor para 2D. Partiendo de una ocupación de la FPGAcomo la representada en 2.5a compara la técnica de Bazargan, que daría lu-gar a una división del área libre como la mostrada en 2.5b tras la llegada deuna nueva tarea, con su propuesta, mostrada en 2.5c, que permite retardar ladecisión de la división en MER hasta el momento de insertar la tarea.

Figura 2.5: División del área libre en rectángulos: Walder

Esta propuesta está ampliamente desarrollada en otro trabajo, presentadoen [SWP04] en el que presenta dos técnicas de plani�cación, cada una de ellasaplicada a 1D y 2D.

37


La primera técnica, llamada horizonte (del inglés horizon) utiliza tres listasde tareas: una de ellas contiene la información de las tareas actualmente enejecución, otra de tareas en espera de ser ejecutadas y la tercera contieneun "horizonte de plani�cación", que contiene los intervalos (para el caso 1D)o los rectángulos máximos (para el caso 2D) que van a ser liberados en elfuturo, ordenados por tiempo creciente de liberación del espacio. De esta formase mantiene una información completa del espacio libre en la FPGA, que esconsultada en el momento de la llegada de cada nueva tarea para comprobarsi se puede ejecutar o no dentro de sus restricciones temporales.

La segunda técnica, llamada empaquetamiento (del inglés stu�ng) es unatécnica más compleja que la anterior, que utiliza también tres listas: la detareas en ejecución, la de tareas en espera y la lista de espacio libre. En estaúltima se guarda la información de intervalos (para 1D) o rectángulos (para2D) que están libres, ordenados ahora por su localización en la FPGA (demenor a mayor posición en el eje horizontal). Para dividir el área libre enrectángulos se basan en el trabajo presentado en [WSP03] y ya comentado.

2.1.4. Trabajo de A. Ahmadinia

Otro grupo que también ha realizado contribuciones muy interesantes eneste tema es el de A. Ahmadinia, actualmente en la Universidad de Edimburgo(Reino Unido). Sus primeros trabajos publicados sobre algoritmos de ubicaciónde tareas son de 2004.

En uno de ellos trabaja sobre ideas de Bazargan [ABK+04], mientras queen el otro propone algunas ideas diferentes y originales [ABT04].

38


En [ABK+04] Ahmadinia describe la situación de la FPGA a partir delos rectángulos ocupados en lugar de los libres. Se basa en que el número derectángulos libres crece con mayor rapidez que el de rectángulos ocupados ycon ello consigue reducir la complejidad del algoritmo a O(n), donde n es elnúmero de tareas ejecutándose en la FPGA.

La primera parte del algoritmo consiste en de�nir los IPR (Impossible Pla-cement Region), zona rayada de la �gura 2.6, que están formados por las áreasque ocupan las tareas y el área alrededor de ellas que produciría solapamientocon la nueva tarea a ubicar. Los IPR por tanto son dependientes de cada nuevatarea que llega y deben ser calculados cada vez que se quiere ubicar una nuevatarea en la FPGA. Se dispone de una lista de IPRs que se debe recorrer paracomprobar si existe su�ciente espacio libre en la FPGA, �gura 2.6.

La segunda parte del algoritmo busca el mejor punto de ubicación en laFPGA dentro de los posibles, en función de la posición de los pines de E/Sasignados a la tarea y de las posibilidades y necesidades de comunicación conotros módulos, a través de la evaluación de una función de coste de rutado.

Figura 2.6: Ahmadinia: IPRs

39


Como vemos, este algoritmo también requiere de complicados cálculos paramantenimiento de la información del estado de la FPGA y la asignación deespacio a una tarea, y además también presupone que una tarea puede ubicarseen cualquier posición de la FPGA.

En su otro artículo del 2004, [ABT04] Ahmadinia propone agrupar lastareas en función del tiempo en que terminarán su ejecución (para evitar lafragmentación) y propone dividir la FPGA en franjas temporales que alberguentareas que terminen en tiempos parecidos, dejando así todo el espacio libre ala vez, como muestra la �gura 2.7. La FPGA queda entonces dividida en slotstemporales, ya que cada nueva tarea que llega es ubicada en función de laproximidad de su tiempo de �n de ejecución con las que se están ejecutandoen la FPGA.

Estos slots se van rellenando con tareas que terminarán más o menos a lavez y dejarán espacio libre contiguo en la FPGA cuando terminen su ejecución.Así la FPGA se irá ocupando y desocupando por franjas y se reduce el problemade la fragmentación del espacio disponible.

En el ejemplo mostrado en la �gura 2.7 vemos que dos tareas con tiempode �n parecido a tfin1, que de�ne el primer slot, son ubicadas en la parteizquierda de la FPGA. A continuación se han ubicado tres tareas con tiemposde �n parecidos entre sí, mayores a tfin1 y menores o iguales a tfin2, quede�ne el �n del segundo slot. De forma análoga se ubican tareas en el tercerslot.

Cuando las tareas que estaban ejecutándose en el primer slot terminan suejecución, el espacio de la izquierda de la FPGA queda libre para ejecutarnuevas tareas que tengan un tiempo de �n de ejecución parecido y que estará

40


de�nido por un nuevo tiempo tfin4 > tfin3 > tfin1.

Figura 2.7: Ahmadinia: franjas temporales

En otro trabajo más reciente [ABF+07] el autor propone almacenar infor-mación acerca del contorno del espacio libre en la FPGA, aunque el resultadoes también un algoritmo de complejidad alta, O(n · logn).

Por último mencionamos un trabajo en el que el autor y sus colaboradoreshan desarrollado un computador basado en una FPGA dinámicamente recon�-gurable, la Virtex-2 [MTAB07]. Nos interesa destacar que de nuevo los autoresutilizan un modelo de gestión del área similar al propuesto por nosotros cuan-do se trata de implementar un sistema real. En este caso, al tratarse de unaFPGA recon�gurable en 1D, dividen el área que van a dedicar a ejecución detareas en tres particiones de igual tamaño.

41


2.1.5. Trabajo de J. Tabero

Queremos también mencionar el trabajo del grupo de J. Tabero, de laUniversidad Complutense de Madrid (España), publicado en [TSMM08] y[TSMM06], que utiliza una lista de vértices para representar el contorno delespacio libre en la FPGA, que combinada con diferentes heurísticas se utili-za para seleccionar la mejor ubicación dentro de las posibles para cada nuevatarea.

Las heurísticas utilizadas son dos:

1. Basada en la fragmentación producida por una determinada ubica-ción de la tarea en la FPGA, según la fórmula

F = 1−∏

i

[

(4

Vi

)n

· Ai

AFFPGA

]

donde Vi es el número de vértices, Ai es el área de la tarea, AFFPGAes el

área libre de la FPGA y i es el número del hueco.En esta fórmula, el término entre paréntesis representa la adecuación dela forma del hueco i para ubicar tareas rectangulares y el otro términorepresenta el área del hueco normalizado.

2. Basada en el estudio de adyacencia de la tarea con respecto a lastareas que se están ejecutando en la FPGA según la expresión

Ady2D =∑

h

(V Llim

⋂lim TNh

)

donde V Llim es la lista de vértices que limitan con la tarea y limTNhes

42


cada una de las aristas de la tarea. Esta expresión formaliza la idea deque el vértice seleccionado es el que permite mejor área de contacto conlos límites de las tareas que se están ejecutando y con el área libre en laFPGA.

Estas heurísticas se amplían también al estudio 3D, en donde se tiene encuenta el volumen de las tareas en la FPGA, siendo el tiempo la tercera di-mensión considerada.

La �gura 2.8 muestra un esquema del entorno utilizado por este autor.Cuando llega una nueva tarea al sistema, el plani�cador de tareas ejecuta elmódulo selector de vértices para averiguar si existe espacio disponible en laFPGA para ejecutar la tarea de inmediato. Si no hay espacio, la tarea quedaalmacenada en una cola para su posterior ejecución. Las tareas en la cola deespera, Qw, están ordenadas por su tiempo máximo de espera permitido.

Si hay espacio disponible, se utiliza una de las heurísticas mencionadas paraseleccionar la mejor ubicación posible para la tarea. El módulo encargado decargar el mapa de bits en la FPGA es el cargador / extractor.

Otro módulo, el analizador de la lista de vértices, monitoriza la fragmen-tación existente en la FPGA y en los casos en que detecte que se necesitarealizar una defragmentación, ejecuta el módulo defragmentador, que reubicalas tareas en la FPGA con el objetivo de que el espacio libre esté contiguoy pueda ejecutarse alguna de las tareas que están esperando en la cola o laejecución inmediata de una nueva tarea que llegue al sistema.

Como vemos, se trata de una idea muy original pero que también da lugara un algoritmo muy complejo.

43


Figura 2.8: Esquema del entorno propuesto por Tabero

2.1.6. Trabajo de H. Kalte

H. Kalte, de la West University (Australia), ha realizado también algunostrabajos de investigación sobre algoritmos que representan el espacio libre enla FPGA y deciden la ubicación de las nuevas tareas. Se han centrado en elproblema en 1D y los algoritmos propuestos son de complejidad alta.

Este grupo ha insistido fundamentalmente en el problema de la defrag-mentación del espacio de la FPGA y la reubicación de tareas que se estánejecutando.

44


En su artículo [KKK+04] proponen una estrategia que tiene en cuenta la�exibilidad a la hora de utilizar el espacio de la FPGA y el problema de lascomunicaciones. Proponen una infraestructura de comunicaciones basada enla utilización de líneas horizontales que atraviesan la FPGA y que por tantopermiten el intercambio de datos y señales de control entre las tareas ubicadasen 1D, es decir, que ocupan la altura total de la FPGA y varían en anchura.Miden el rendimiento de su propuesta en el uso efectivo de CLBs de la FPGA yla comparan con las heurísticas 2D, consiguiendo mejoras con respecto a estasy sin necesidad de recurrir a la defragmentación.

En otro artículo, [KPK05], proponen dos heurísticas diferentes para 1D,aunque son también aplicables a 2D.

Figura 2.9: Gestión del espacio propuesta por Kalte

45


La primera de ellas examina todas las posibles ubicaciones de una tareay calcula la probabilidad estática de utilización, determina los pesos de lasdiferentes posibles ubicaciones y las ordena de menor a mayor peso. En tiempode ejecución, se examinan las ubicaciones posibles ordenadas por pesos y seselecciona la primera que esté disponible, �gura 2.9. La segunda heurísticautiliza ideas similares a la de la primera y es una versión mejorada en la quelos pesos se re-calculan cada vez que una tarea termina su ejecución o una nuevacomienza a ejecutarse en la FPGA. Las tareas se sintetizan para ocupar unasdeterminadas columnas de la FPGA pero en tiempo de ejecución el algoritmopuede desplazarlas para ajustarlas al espacio disponible.

En su artículo más reciente, [KKP06], este autor y su grupo se centran en elproblema de defragmentación y re-ubicación de tareas en tiempo de ejecución.Hacen hincapié en los aspectos HW a solucionar para poder llevar a cabo lainterrupción y reanudación de la ejecución de tareas sobre DHWR.

2.1.7. Trabajo de M. Handa

M. Handa, de la Universidad de Cincinnati (EEUU), ha trabajado tambiénsobre este mismo problema. En su publicación [HV04] presentan un algoritmoque utiliza una estructura en escalera para representar el espacio libre en laFPGA. Su trabajo también se basa en el realizado por Bazargan, y se tratade una lista de MER representada de forma que resulta más rápido y sencillolocalizarlos.

Una escalera está formada por todos los rectángulos libres que tienen encomún su esquina inferior derecha, que se denomina origen de la escalera, según

46


muestra la �gura 2.10. En esta �gura el espacio libre de la FPGA ha quedadorepresentada por varias escaleras, una de ellas con origen en el punto P, otracon origen en el punto M y otra en O. Estas dos últimas solamente contienenun escalón, mientras que P tiene tres escalones de�nidos por los puntos A, By C.

Figura 2.10: Estructura en escalera propuesta por Handa

Una vez determinadas todas las escaleras, es necesario detectar cuáles con-tienen MER (rectángulos máximos), es decir, las escaleras máximas, lo quereduce el proceso de búsqueda de posibles ubicaciones de las nuevas tareas, yaque solamente se consideran los MER.

La complejidad resultante de este algoritmo es también alta, O(W ∗ H),donde W es el número de �las de CLBs y H es el número de columnas.

No dan detalles acerca de cómo se selecciona uno de los MER para laubicación de una tarea, y tampoco de la complejidad del algoritmo necesariopara cargar una tarea en la FPGA, una vez seleccionada su ubicación.

47


2.1.8. Conclusiones: algoritmos complejos

Una vez presentados los principales autores que han trabajado en este tema,estamos en condiciones de hacer una serie de observaciones generales, aplicablesa todos ellos:

• Alta complejidad: todos los autores mencionados han presentado ideasmuy interesantes y e�cientes pero de complejidad muy alta, y no siem-pre garantizando que el método empleado para localizar área libre en eldispositivo sea e�ciente en el 100% de los casos. Esta complejidad haceque los retardos asociados a la gestión de la ubicación de tareas penalicea las mismas, impidiendo algunas veces que cumplan sus restriccionestemporales.

• Ideas alejadas de las posibilidades actuales: todos los autores pre-suponen que una tarea se puede ubicar en posiciones arbitrarias en unaFPGA. Sin embargo esto, de momento, es una hipótesis alejada de lasposibilidades reales de recon�guración parcial dinámica en los disposi-tivos existentes, como prueban además los mismos autores, que en sustrabajos más recientes y dedicados al estudio de los problemas reales deimplementación de sistemas computacionales basados en DHWR no re-curren a los algoritmos propuestos en sus publicaciones anteriores paragestionar el área de los dispositivos sino a ideas más sencillas como lasque se van a presentar a continuación.

48

Algoritmos sencillos 2.2

2.2. Algoritmos sencillos

2.2.1. Trabajo de P. Merino

Dentro del grupo de algoritmos sencillos encontramos menos cantidad detrabajos. Destacamos la propuesta de P. Merino, de la Universidad de Málaga(España), [MLJ98a] y [MLJ98b], del año 1998 y cuya línea de investigaciónfue abandonada. Proponen una idea muy sencilla para la división del espaciodisponible en la FPGA: cuatro particiones de igual área, según muestra la�gura 2.11.

Figura 2.11: Propuesta de Merino

Tanto la estructura de datos como el algoritmo utilizados en este modeloson muy sencillos y fáciles de implementar. Las tareas que van a ser ejecutadasen la FPGA se almacenan en una tabla, la TUT (tabla para ubicación detareas) y de ahí pasan a ejecutarse en una de las particiones de la FPGA.

Las ventajas y graves inconvenientes de este sistema resultan bastante ob-49


vias: por un lado vemos que se trata de un algoritmo que efectúa la ubicaciónde tareas con mucha rapidez y sencillez, y por otro lado es evidente que eldesperdicio de área del dispositivo resultará excesivo cuando la diferencia detamaño entre la tarea y la partición sea grande. A este tipo de situación se lellama fragmentación interna y es común a todos los algoritmos que propo-nen trabajar con particiones pre-de�nidas en la FPGA.

Otro inconveniente es la limitación de ejecución de tareas a aquéllas de áreaigual o inferior al 25% del tamaño de la FPGA.

Vemos entonces que para un conjunto de tareas de tamaños muy variadoscomo los que se podrían esperar en un sistema de computación de propósitogeneral, las tareas pequeñas desperdiciarían mucho área de la FPGA, y muchastareas grandes no se podrían ejecutar en una partición y se tendrían que recha-zar. En resumen, la ventaja en cuanto a rapidez y sencillez en esta propuestano compensan la falta de e�ciencia y rigidez de gestión que la acompañan. Setrata de una propuesta muy fácil de implementar que hubiera necesitado deun desarrollo posterior, que los autores no realizaron.

2.2.2. Trabajo de H. Walder (II)

En otro trabajo, H. Walder [WP03] ha publicado algunas ideas parecidasa las presentadas en nuestro trabajo, como la de dividir la FPGA en variosbloques con tamaños diferentes y �jos a lo largo de la ejecución de un lotede tareas, pero lo han aplicado exclusivamente a casos en 1D y no a FPGAsen 2D como hemos hecho nosotros. El esquema del funcionamiento de dichoalgoritmo se muestra en la �gura 2.12.

50


Figura 2.12: Propuesta de división en bloques de Walder

Los bloques son de tamaño �jo y diferente entre sí. Están ordenados de ma-yor a menor tamaño, estando los de mayor tamaño a la izquierda. La anchurade los bloques puede variar con cada nuevo lote de tareas a ejecutar, conformea un estudio que se realiza partiendo de que se conoce de antemano el grupode tareas a ejecutar.

El número de colas es también variable. Hay una cola por cada tamaño debloque diferente. Una primera función, fdiv, selecciona la cola que correspondaal menor tamaño de bloque capaz de ubicar a una tarea. Después inserta latarea en la cola según un criterio que se ha seleccionado de antemano (pororden de llegada o por tiempo de ejecución).

Otra parte del algoritmo, fsel, se ejecuta cada vez que una tarea terminasu ejecución en la FPGA, determinando cuál de las tareas en la cabecera decada cola se ejecutará la siguiente y en qué bloque de la FPGA se ubicará.

51


Esta función tiene dos modos de operación: el modo restrictivo y el modopreferente.

En el modo restrictivo, las tareas de una cola solamente pueden ejecutarseen los bloques asociados a dicha cola. En el modo preferente, las tareas deuna cola pueden ejecutarse en cualquiera de los bloques que están libres en esemomento.

Conviene resaltar de este trabajo que además de ser un planteamiento para1D, el algoritmo después de seleccionar una cola para la tarea entrante ordenalas tareas en la cola y es posteriormente cuando selecciona la zona de la FPGAdonde la tarea será ubicada. Esto quiere decir que la cola donde se ubica la tareano determina la partición donde se ejecutará. También tiene el inconvenientede que no permite calcular el tiempo real que dicha tarea tendrá que esperarantes de ser ejecutada y que se retrasa la información de rechazo de tarea porno poder cumplir con sus requisitos de tiempo máximo hasta el momento enque éste haya expirado.

La decisión de cuál será la siguiente tarea a ejecutar y dónde se va a ubicarse toma cuando una tarea abandona la FPGA y deja espacio libre, por lo queeste algoritmo tiene una complejidad alta, por un lado debido al algoritmo deordenamiento de las tareas en las colas y por otro lado porque tiene que buscaren las particiones y contrastar la información con las tareas pendientes en lascolas para decidir dónde ubicarla.

El número y tamaño de las particiones y el número de colas puede variarde una ejecución a otra, por lo cual su implementación no resulta sencilla, másaún si se realiza sobre el propio HW. Los autores hacen un estudio teóricode la e�ciencia esperada para distintas distribuciones de particiones pero ad-

52


vierten de la di�cultad de la implementación y de la necesidad de un estudioexperimental posterior para llegar a conclusiones más determinantes.

2.2.3. Conclusiones: algoritmos sencillos

En resumen, en este grupo contamos con muchos menos trabajos publica-dos, cuyos objetivos son similares a los nuestros, es decir:

Complejidad simple: Son algoritmos que manejan estructuras de datossencillas para representar la situación de la ocupación de la FPGA.

Rapidez de respuesta: Son algoritmos que encuentran rápidamenteuna ubicación para las nuevas tareas.

Tomándolos como punto de partida, podemos hacerles la siguientes críti-cas a los autores de estos grupos, que serán los aspectos que incorporaremosa nuestro trabajo de investigación, cuyos objetivos se han presentado en elcapítulo anterior:

E�ciencia en plani�cación en 2D: ya que no todos los algoritmosestán orientados a la gestión del área de la FPGA en dos dimensiones.

Flexibilidad: ya que algunas de las soluciones propuestas por estos auto-res carecen de la �exibilidad necesaria para la gestión del área de laFPGA.

53

Capítulo 3

Arquitectura del sistema y

algoritmo básico

Este capítulo presenta la arquitectura global del sistema donde se realizarála implementación de un algoritmo que gestione los recursos HW disponibles,así como los modelos de tarea y FPGA que se han utilizado en esta tesis.Además, presentaremos el funcionamiento básico de nuestro plani�cador e in-dicaremos cómo se pueden ejecutar tareas de mayor tamaño que las particionesmediante la funcionalidad de fusión de particiones.

3.1. Arquitectura global del sistema

Este trabajo se basa en el uso de un recurso hardware dinámicamente re-con�gurable como parte de un sistema de computación de propósito general.Esto quiere decir que el sistema dispone de una FPGA (además de la CPUtradicional) para ejecutar las aplicaciones, tanto las demandadas por el usuario

55

Capítulo 3. Arquitectura del sistema y algoritmo básico

como las del propio SO.La �gura 3.1 muestra el esquema global de un sistema con estas caracterís-

ticas. Cualquier aplicación se descompone en tareas que pueden ser ejecutadasen la CPU (tareas tradicionales de software) o en la FPGA (tareas hardware).

Figura 3.1: Arquitectura global del sistema

El SO decide en cada momento qué tareas se ejecutarán en la CPU y cuálesen la FPGA, dependiendo de la disponibilidad de recursos (uso de la CPU, usode la FPGA, tiempo límite para ejecutar una tarea, dependencias entre tareas,disponibilidad del mapa de bits, prioridad etc.). Por ello es necesario extenderlas funcionalidades de un SO tradicional con las requeridas para gestionar elrecurso hardware [DW99], [WK02]. Este aspecto fundamental viene re�ejado

56

Modelo de FPGA 3.2

en la �gura con la mención explícita de un gestor hardware y un gestor software.

3.2. Modelo de FPGA

Trabajamos con un modelo de FPGA en el que el dispositivo consiste en unamatriz de WT * HT celdas básicas recon�gurables (cada una de ellas formadapor un conjunto de CLBs correspondientes al tamaño mínimo de tarea), queson todas idénticas. WT es el número total de columnas y HT es el númerototal de �las, �gura 3.2.

Figura 3.2: Modelo de FPGA

Según se muestra en la �gura 3.3, en nuestro entorno hemos dividido elárea de la FPGA de la siguiente manera:

• Área para ejecución de tareas (AET): Matriz de W ∗H celdas bá-sicas recon�gurables (CBRs), dividida en cuatro particiones de diferentetamaño, con W < WT y H < HT .En nuestro trabajo gestionamos las celdas de la AET de la FPGA comosi ésta estuviera dividida en cuatro particiones de diferente tamaño. De-�nimos las particiones como aquéllas que resultan de dividir la super�cie

57


con dos líneas x = wp e y = hp. Las particiones resultantes P0, P1, P2 yP3 tienen las siguientes características respectivamente:

• Origen: (0, 0), (wp, 0), (0, hp) y (wp, hp)

• Tamaños: wp∗hp, (W−wp)∗hp, wp∗(H−hp) y (W−wp)∗(H−hp)

Bus para comunicaciones

T2

T5

T4

P2

P0 P1

P3

wp

W

h p

H

Acceso al bus

Eje X

Eje Y

Figura 3.3: División de la FPGA

Los parámetros wp y hp determinan el tamaño de las particiones y puedenser modi�cados a lo largo del funcionamiento del algoritmo para adap-tarlas de la mejor manera posible a las necesidades del per�l de tareasen ejecución.Se pueden rotar las tareas que se considere necesario para una mejorubicación. Los cambios de forma de tarea aún no se están considerando,pero serían un aspecto a tener en cuenta en futuras versiones del algorit-mo aunque supondrían una carga extra en la memoria y de computación

58

Modelo de tarea 3.3

para el SO, puesto que sería necesario disponer de diferentes versionesde compilaciones de la misma tarea con diferentes geometrías.

• Área para bus periférico: área alrededor del AET, que garantiza elacceso de cada tarea a los pines de E/S de la FPGA y la comunica-ción entre tareas. El modelo de bus utilizado se explica en detalle en elapéndice A.El acceso al bus de comunicaciones se realiza a través de las conexiones�jas situadas en cada partición. Se ha elegido esta ubicación para evitarla recon�guración del bus de comunicaciones en la mayor parte de loscasos de funcionamiento del algoritmo.

• Área para el Sistema Operativo: el SO necesario para gestionar elDHWR su puede implementar en forma de módulos software, que seejecutarán en una CPU tradicional (en versiones recientes de FPGA,en el propio procesador en el chip) y algunos módulos hardware que secon�gurarán en áreas de la FPGA reservadas para el SO.

3.3. Modelo de tarea

Las tareas HW están de�nidas por el mapa de bits que se cargará en laFPGA para su ejecución. Se representan como rectángulos en cuyas áreas estánincluidos todos los recursos de procesamiento y rutado necesarios. El gestorde hardware incluye la posibilidad de establecer límites de tiempo para laejecución de una tarea.

59


Cada tarea está de�nida por una tupla:

Ti = {wi, hi, teji, tlli, tmaxi} (3.1)

en la que wi es el ancho de la tarea, hi su altura, teji el tiempo de ejecución dela tarea (que incluye el tiempo de recon�guración), tlli es el momento en quellega la tarea al gestor, y tmaxi el tiempo máximo para ejecución de la tarea,indicando el tiempo máximo desde la llegada de la tarea al gestor hasta elmomento en que la tarea debe haber sido ejecutada, y limitando así el máximotiempo de espera de cada tarea, tesperai, según muestra la �gura 3.4. Paracada tarea se debe cumplir:

tmaxi ≥ teji + tesperai (3.2)

Figura 3.4: Máximo tiempo permitido para la terminación de la ejecución de una tarea

Las tareas se pueden rotar, para que el algoritmo disponga de mayor �exi-bilidad a la hora de asignarles una partición en que ejecutarse. Esto supone elcoste adicional de disponer de dos compilaciones distintas para cada tarea ensus dos posibles versiones de wi ∗ hi o hi ∗ wi, según muestra la �gura 3.5, loque supone un incremento de la memoria necesaria para almacenar los mapas

60

Modelo de tarea 3.3

de bits de las tareas a ejecutar en el sistema.

T6

acceso al bus

h i

wi

T6'

acceso al bus

hi

wi

Figura 3.5: Rotación de la tarea

Los mapas de bits de las tareas se obtienen de manera que las tareas seanreubicables, es decir, que cuando se les asigna una partición en la que se eje-cutarán, un sencillo cálculo permite generar el nuevo mapa de bits para laejecución de la tarea, a partir del mapa de bits inicial.

Sin embargo, debido a la división de las FPGAs actuales en parte superiore inferior, en la actualidad, según se explica en detalle en el apéndice A, esnecesario disponer de dos mapas de bits diferentes para cada tarea, segúnla mitad de la FPGA en que se vayan a ejecutar, de forma que se opte porla versión de compilación inferior para las particiones P0 y P1 y la versiónsuperior para las particiones P2 y P3, según se muestra en la �gura 3.6.

Por lo tanto, para la implementación de este modelo de gestión son nece-sarias cuatro compilaciones diferentes para cada tarea.

El modelo de recon�guración parcial en que se basa el entorno propuestoen este trabajo está explicado en detalle en el apéndice A.

61


Figura 3.6: Dos compilaciones de la misma tarea

3.4. Esquema del plani�cador

La �gura 3.7 muestra el esquema del plani�cador completo, compuesto porlos siguientes elementos, que funcionan en paralelo:

• Unidad de Plani�cación de Tareas (UPT): Esta unidad examinalas características de cada nueva tarea que llega al gestor HW para serejecutada en la FPGA y le asigna una cola, que determina la particiónen la que la tarea se ejecutará. La selección de la partición se realizamediante un algoritmo sencillo de complejidad constante que se describeen detalle en la siguiente sección de este capítulo.

• Unidad de Lanzamiento de Tareas (ULT): Esta unidad es la en-cargada de lanzar la ejecución de una nueva tarea a la FPGA cada vezque otra termina su ejecución y libera una partición. En ese momentola ULT lee la cola asociada y si hay alguna tarea esperando para serejecutada, pone en marcha el proceso de recon�guración, encargándosede leer el mapa de bits de la tarea desde memoria y mandárselo al inter-faz de recon�guración. Asimismo, informa al SO de la terminación de la

62

Esquema del plani�cador 3.4

Figura 3.7: Esquema del plani�cador

ejecución de una tarea y el comienzo de la ejecución de una nueva.

• Unidad de Adaptación Dinámica (UAD): Esta unidad mantieneuna estadística de las características de las tareas que están llegandoal plani�cador HW y determina la necesidad de realizar cambios en lasparticiones (número y/o tamaño) y envía los comandos necesarios paraello a la ULT (recon�guración del bus y de la FPGA si se cambia elnúmero o tamaño de las particiones) y a la UPT (nuevos tamaños ynúmero de particiones) para que se hagan efectivos. El funcionamientodetallado de esta unidad se describe en el capítulo 4.

• Colas de tareas (Q0, Q1, Q2, Q3): Hay una cola de tareas asociadaa cada partición, de forma que todas las tareas esperando en la cola Qi

se ejecutarán en la partición Pi. El tiempo de espera de las tareas en63


las colas puede aprovecharse para generar el mapa de bits absoluto, yaque una vez una tarea está escrita en una cola, la ubicación de la tareaen la FPGA queda determinada. Cada cola tiene un parámetro asociadollamado tiempo de espera, que indica el tiempo que una tarea tendrá queesperar a ser ejecutada si se asigna a dicha cola. Este parámetro es elque permite a la UPT calcular si una tarea asociada a una determina-da partición cumplirá con el requisito de tiempo máximo de espera. Eltiempo de espera se calcula de la siguiente forma:

tek =∑p∈Qk

tejp + trk (3.3)

donde tek es el tiempo de espera de la cola k, tejp son los tiempos deejecución de las tareas asignadas a la partición Pk y esperando en di-cha cola, y trk es el tiempo restante de la tarea que se está ejecutandoactualmente en la partición.

Se ha implementado este algoritmo con un código C++ donde para repre-sentar el estado de la FPGA basta con un sencillo array de 4x1 en el que cadaposición está asociada con una partición, re�ejando el estado de la particiónpor un entero que representa el instante de tiempo en el que la tarea que ocupala partición termina su ejecución.

3.5. Algoritmo para asignación de espacio

La UPT examina las características de cada nueva tarea que llega y leasigna una cola/partición atendiendo a los siguientes criterios:

64

Algoritmo para asignación de espacio 3.5

• Mejor ajuste en área: la tarea se ejecutará en la partición que másse ajuste a su tamaño, permitiendo así que particiones mayores quedenlibres para tareas de mayor tamaño y que el área del dispositivo se puedaaprovechar adecuadamente.

• Tiempo de espera limitado: la tarea se ejecutará dentro de la limi-tación de tiempo marcada por tmaxi.

El algoritmo que plani�ca la ubicación de la tarea en la FPGA es sencilloy de complejidad constante y consiste en un bucle en el cual se examina sila tarea cabe en las particiones, examinándolas en orden creciente de tamaño.La tarea se asignará a la primera partición que se encuentre donde quepa portamaño y se cumpla el requisito de máximo tiempo de espera.

Si la UPT no encuentra ninguna partición en la que ejecutar la tarea debidoa que los tiempos de espera son demasiado largos para las restricciones tem-porales de la tarea, dicha tarea se rechaza, es decir, no se escribe en ningunacola y se informa inmediatamente al SO de que dicha tarea no será ejecutadaen el plazo dado.

En nuestro modelo estamos utilizando una matriz de N x 4 variables Xij

que indican si la tarea Ti se ejecutará en la partición Pj o no. Las variables sede�nen de la siguiente manera:

Xij =

1 si Ti se ejecuta en Pj

0 en caso contrario

Cuando una tarea se ejecuta en la FPGA, una de las variables Xij valdrá 1y las restantes 0. Si todas las Xij son 0 para una determinada tarea Ti signi�ca

65


que no se pueden cumplir las restricciones de tiempo para dicha tarea y quese ha rechazado.

Como cada tarea únicamente se puede ejecutar en una partición, solamenteuna de las cuatro variables Xij tomará el valor 1. Las otras tres restantesvaldrán 0:

0 ≤3∑

i=1

Xij ≤ 1 (3.4)

El objetivo de nuestro algoritmo es ejecutar el máximo trabajo asignadopara ejecución a la FPGA. Con el propósito de cuanti�car la cantidad detrabajo ejecutada frente a la asignada hemos de�nido el volumen de una

tarea de la siguiente manera:

voli = wi · hi · teji (3.5)

que representa el volumen de FPGA que está ocupando, utilizando el tiem-po como tercera dimensión.

Hemos de�nido el volumen ejecutado como la suma de los volúmenes delas tareas ejecutadas y el volumen asignado como la suma de los volúmenesde todas las tareas del lote. El resultado óptimo de nuestro algoritmo consisteen ejecutar el 100% de la carga de trabajo asignada o volumen asignado. Portanto se trata de maximizar la función volumen total ejecutado, que dependede la plani�cación que el algoritmo haga de las tareas que van llegando. Lafunción se de�ne así:

66

Algoritmo para asignación de espacio 3.5

Vej =3∑

j=0

N∑i=1

Xij · voli (3.6)

Esto nos permite evaluar el rendimiento del algoritmo a partir de la relaciónentre el volumen ejecutado Vej y el volumen del lote de tareas o volumenasignado Vas, en términos percentiles. Cuanto mayor sea su valor mejor será elrendimiento del algoritmo:

Rej =Vej

Vas

· 100 (3.7)

A continuación presentamos el algoritmo completo de la UPT.

Algoritmo 1 Algoritmo de selección de particiónfor (i=1; i ≤ N ; i++) dofor (j=1; i ≤ 3; j++) do

Xij = 0;end for

end forsel=false;k=0;while ((k < 4) and (sel == false)) doif (Cabe(Ti, Pk) == true) and (Cumplet(Ti, Qk) == true) thenEscribe(Ti,Qk);Xik=1;sel=true;

end ifk++;

end whileif (sel == false) thenRechaza(Ti);

end ifSalida();

67


Algoritmo 2 Subrutina Cabe(Ti,Pk)if ((wi ≤ Wk) and (hi ≤ Hk)) or ((wi ≤ Hk) and (hi ≤ Wk)) thenreturn true;elsereturn false;

end if

Algoritmo 3 Subrutina Cumplet(Ti,Qk)if (teji + tek ≤ tmaxi) thenreturn true;elsereturn false;

end if

Algoritmo 4 Subrutina Salida()Vej=0;Vas=0;for (i=1; i ≤ N ; i++) do

Vas = +wi · hi · teji;for (k=0; k ≤ 3; k++) do

Vej = +Xik · wi · hi · teji;end for

end forRej = (Vej/Vas) · 100;

68

Ejemplo de funcionamiento 3.6

3.6. Ejemplo de funcionamiento

En esta sección mostraremos un ejemplo detallado del funcionamiento delalgoritmo y de su e�cacia para gestionar el área de la FPGA. Para ello utiliza-remos un lote de tareas pequeño y sencillo que pone de relieve las ventajas denuestro algoritmo sencillo frente a otros complejos. Hemos utilizado una matrizde 20*20 CBRs para simular la FPGA con la distribución en 4 particiones quese muestra en la �gura 3.8.

Figura 3.8: FPGA de 20 * 20 dividida en 4 particiones

El algoritmo que proponemos se basa en equilibrar la carga de trabajo en eldispositivo, clasi�cando las tareas por tamaños y reservando áreas especí�casde la FPGA para tareas de determinados tamaños. Esto supone una granventaja cuando las tareas que pueden llegar al sistema para ser ejecutadas sonde tamaños variados y especialmente en el caso en que pueden aparecer tareasde tamaño bastante grande con una frecuencia relativamente alta.

Para demostrar su e�cacia, compararemos la gestión de nuestro algoritmo69


basado en particiones (ABP) con un algoritmo comúnmente utilizado comoreferencia, el algoritmo de First Fit (FF), o Primer Ajuste.

FF es frecuentemente utilizado por los autores que trabajan en esta líneade investigación para comparar la e�ciencia de sus propuestas. Este algoritmopuede ser bottom left (BL) o top right (TR), dependiendo de que se empiecela búsqueda de huecos para una nueva tarea por la esquina inferior izquierdade la FPGA (BL) o por la esquina superior derecha de la FPGA (TR). El FFBL examina las posibles posiciones de la FPGA para ubicar una nueva tareaentrante, de dimensiones wi*hi, empezando por la primera que encuentra libreen la esquina inferior izquierda y comprobando si la tarea entra en el huecodisponible. Para ello tiene que comprobar en cada posición libre si las wi*hi

celdas contadas a partir de dicha celda están libres. FF ubica una tarea en elprimer hueco libre que encuentra, según muestra la �gura 3.9.

Figura 3.9: Algoritmo First Fit BL

Este algoritmo indudablemente puede llegar a hacer un uso razonable del70


área de la FPGA en algunos momentos de su ejecución, pero también produceun nivel de fragmentación nada desdeñable debido a que en ocasiones unatarea puede estar ocupando una posición que impida la ejecución de otras,como podremos observar en nuestro ejemplo.

Además resulta de un orden de complejidad alto, O(N4) (donde N*N sonlas dimensiones de una FPGA cuadrada) para recon�guración parcial en 2Dy resulta lento en su ejecución y por tanto en su respuesta, y aunque puederesultar e�ciente en algunos momentos de su ejecución, en otros lo es muy po-co. FF resulta bastante e�caz cuando los tamaños de las tareas son pequeñosen relación al área de la FPGA, pero en la ubicación de tareas relativamentegrandes resulta poco e�ciente. Esto es debido a que si llegan tareas pequeñaso medianas intercaladas con las grandes, quedarán ubicadas en posiciones cen-trales de la FPGA e impedirán la ejecución de las tareas grandes ya que elespacio libre de la FPGA quedará muy fragmentado.

Para ilustrar lo comentado anteriormente, pasamos a explicar en detalle laejecución del lote de tareas descrito en la tabla 3.1.

Tabla 3.1: Lote de tareas sencillo

Tarea wi hi tlli teji tmaxi

T1 5 5 1 6 13T2 14 5 1 9 19T3 15 13 1 8 17T4 5 15 2 5 12T5 4 4 8 12 32T6 12 4 9 6 21T7 13 13 11 5 21T8 3 13 12 7 26

71


Para este ejemplo el área media de las tareas es de aproximadamente 80CBRs, lo que supone un 20 % del tamaño de la FPGA. Observamos que se tratade un conjunto de 8 tareas de tamaños variados y que 2 de ellas son bastantegrandes. Los tiempos máximos de las tareas son el doble de su tiempo deejecución, lo que da poco margen para retrasarlas. Esto se ha hecho a propósito,ya que si no hubiera una limitación que fuera bastante restrictiva en cuanto almáximo tiempo que pueden esperar las tareas para su ejecución, el problema deplani�cación resultaría trivial y no tendría sentido la comparación de diferentesheurísticas.

Las �guras 3.10 a 3.15 nos muestran la plani�cación realizada por ABP,(a), columna de la izquierda, y la realizada por FF, (b), columna de la derecha.El número que aparece en cada tarea indica su tiempo de �nalización.

Figura 3.10: Ejemplo detallado t=2

En t = 2 han llegado cuatro tareas de diferentes tamaños (una de ellas esmuy grande) que son ubicadas en la FPGA de diferentes maneras por ABP (a)y FF (b), según muestra la �gura 3.10. Las tareas ocupan prácticamente todoel área de la FPGA y la fragmentación resultante de una y otra plani�caciónson equivalentes.

72


En t = 8 llega una tarea de 4*4, que pasa a sustituir a la tarea de 5*5 queacaba de terminar su ejecución. Como el algoritmo FF busca el primer huecolibre, su posición coincidirá para los dos algoritmos, �gura 3.11.


En t = 9 llega una tarea de 12*4. Aquí empezamos a ver la diferencia enla política de uno y otro algoritmo. Como estamos simulando las versión másbásica del algoritmo, suponemos que la tarea no se puede rotar y ejecutar en P2.En el caso de FF, la ejecuta de inmediato situándola en el primer hueco libreque encuentra, justamente por encima de las otras dos que se están ejecutando.El algoritmo de particiones sin embargo decide esperar a que termine la tareaque se está ejecutando en P1 (ya que la espera necesaria está dentro de losmárgenes permitidos para esta tarea) y la escribe en Q1. Aparentemente elalgoritmo FF está aventajando al nuestro en este momento de la ejecución.

En t = 10 termina la tarea que estaba ocupando P1 y pasa a ejecutarse laque espera en la cola. Nuestro algoritmo ha retrasado el �n de su ejecución enuna unidad de tiempo debido a la espera.

Sin embargo podemos observar que el esperar para ejecutar la tarea de12*4 permite al algoritmo de particiones mantener el espacio de la FPGA sin

73


fragmentar y dejar su�ciente espacio libre para la ejecución tanto de tareas pe-queñas o medianas que pudieran llegar como de tareas grandes y muy grandes,como muestra la �gura 3.12a.


En t = 11 llega la segunda tarea grande del lote y ABP la ejecuta deinmediato, �gura 3.13a, mientras que FF debe ponerla en la cola de espera yaque el espacio libre disponible no es contiguo debido a la presencia de la tareacuya ejecución adelantó con respecto al nuestro, �gura 3.13b.


La �gura 3.14 muestra que la situación se agrava cuando en t = 12 llegauna tarea de 3*13 que pasa a ser ejecutada en P2 con ABP (a) y en el primerhueco disponible con FF (b), quedando ubicada en una posición central de la

74


FPGA y retrasando aún más el tiempo de espera de la tarea grande que estáen la cola de FF.


Debido a la aparición de esta otra tarea de tamaño medio entre la tareaque espera en la cola y las tareas que se ejecutaban en la FPGA, en t = 15

ya no será posible para FF enviar a ejecutar la tarea que espera en la cola,teniendo esta tarea que esperar hasta t = 19 (y también debido a que ya nollegan más tareas para ejecutarse, si no la espera podría aumentar aún más),como muestra la �gura 3.15b.


En t = 19 la tarea se tiene que desechar puesto que se ha sobrepasado sutiempo máximo: 19 + 7 = 26 > 21.

75


La primera �la de la tabla 3.2 muestra los resultados de la ejecución deeste pequeño pero signi�cativo lote de tareas para uno y otro algoritmo. Semuestra el rendimiento medido como la relación entre el volumen ejecutado yel volumen asignado (en porcentaje), el número de unidades tiempo (#u.t.) quese ha tardado en ejecutar el lote completo y el volumen de trabajo ejecutado.El volumen de trabajo de este lote es Vas = 4,313 CBRs*#u.t.

Tabla 3.2: Resultados del lote sencillo

R ( %) Vej #u.t.Lote FF Part FF Part FF Part

L1 80 100 3486 4313 20 20L2 100 100 4313 4313 20 20L3 80 80 3486 3468 20 20L4 100 100 4313 4313 21 20L5 64 100 2753 4313 18 19

Podemos observar que el rendimiento del algoritmo FF es más bajo que elde ABP precisamente debido a la tarea que ha tenido que desechar. Queremosresaltar la di�cultad de este algoritmo para plani�car la ejecución de tareasgrandes, como se verá re�ejado en los resultados experimentales presentadosen el capítulo 6 y esta diferencia de rendimiento entre ABP y FF se mantieneo incluso aumenta a nuestro favor siempre que la presencia de tareas grandesen un lote de tareas sea signi�cativa.

El resto de resultados de la tabla corresponden al mismo conjunto de tareasordenado de diferentes formas.

En el lote L2 se ha retrasado la llegada de T7 a t = 12 y T8 se ha adelantadoa t = 11. Vemos que en este caso el algoritmo FF sí puede plani�car su ejecución

76

Fusión de particiones 3.7

y el rendimiento se iguala para ambos.En el lote L3 la llegada de T7 se ha adelantado a t = 2, es decir, a continua-

ción de T3. El resto de las tareas mantiene el orden de llegada y se retrasan.La FPGA no es su�cientemente grande como para ejecutar ambas simultánea-mente y el tiempo entre las tareas con respecto al tiempo de ejecución de T3es demasiado pequeño y la tarea no puede ejecutarse en ningún caso, ya queno depende de la plani�cación realizada. El rendimiento de ambos algoritmostambién es igual para este caso.

En el lote L4 las tareas T2 y T3 llegan con su�ciente separación en eltiempo, de ahí que cualquiera de los dos algoritmos ejecuta el total de tareas.

El lote L5 representa otra forma de ordenación de las tareas en el cual lasde tamaño mediano y pequeño que llegan entre T2 y T3 inter�eren, en el casode FF, con la ejecución y dan lugar al rechazo de una de tamaño medianoademás de una de las grandes.

Una clara ventaja de nuestro algoritmo basado en particiones frente a FFes que tarda mucho menos tiempo en plani�car las tareas, dando además lugara una plani�cación mejor.

3.7. Fusión de particiones

Es un hecho evidente que pueden llegar tareas al sistema que sean mayoresque cualquiera de las particiones de�nidas. En estos casos, que asumimos comopoco frecuentes, el algoritmo no puede permitirse rechazar una tarea debido auna excesiva rigidez en su de�nición.

Por esta razón se ha añadido una funcionalidad al algoritmo para el caso77


en que una tarea tenga unas dimensiones tales que no quepa en ninguna de lasparticiones establecidas, pero sí en la FPGA: el algoritmo ofrece la posibilidadde unir dos o incluso las cuatro particiones para ubicar dicha tarea. Las posiblesuniones de particiones son: P0+P1, P0+P2, P1+P3, P2+P3 y P0+P1+P2+P3,en orden creciente de tamaño.

Para incluir esta funcionalidad hemos añadido cinco particiones virtualesen el modelo: P4 = P0 + P1, P5 = P0 + P2, P6 = P1 + P3, P7 = P2 + P3 yP8 = P0 + P1 + P2 + P3. De esta forma el algoritmo se mantiene en su formaoriginal y solamente hay que aumentar el número de iteraciones del mismo, lafunción que calcula el tiempo de espera de las colas virtuales y la que escribeen las colas, que se muestran el sección 3.8.

La �gura 3.16 muestra las particiones reales y las virtuales de�nidas en laFPGA.

Figura 3.16: Particiones reales y virtuales en la FPGA

78


3.7.1. Descripción de la fusión de particiones

La UPT busca las dos particiones más pequeñas que pueden alojar a latarea y comprueba que el tiempo que tendrá que esperar a que ambas quedenlibres simultáneamente no excede los límites del tmax de la tarea. Si los cumple,escribe la tarea en la cola con mayor tiempo de espera y reserva dicho intervalode tiempo en la cola asociada a través de unos parámetros sencillos de calculary de comprobar posteriormente. Si no los cumple, busca otra combinación departiciones que tengan menor tiempo de espera, con el coste de desperdiciaruna mayor área de dispositivo. En el caso de que ninguna combinación departiciones cumpla los requisitos de tiempo máximo de la tarea, ésta serárechazada.

Los parámetros utilizados para reservar tiempo de ejecución en una parti-ción en cuya cola no se ha escrito la tarea pero que se va a utilizar para la fusión,se denominan tiempo de fusión (tfi) y tiempo de reanudación (treanudi). Eltiempo de fusión indica el instante de tiempo a partir de la cual una particiónestará ocupada por una tarea no presente en la cola, y el tiempo de reanudaciónindica el momento en que dicha tarea abandonará la partición. Se muestranen la �gura 3.17.

3.7.2. Ejemplo de fusión de particiones

La �gura 3.17 muestra un ejemplo de tarea que necesita de la fusión de lasparticiones P0 + P1. La tarea en cuestión es la T12. El algoritmo examina eltiempo de espera de la cola 0 y de la cola 1. El tiempo de espera de la cola 1 esmayor y por tanto T12 se escribe en 0 apuntando a 1. El tiempo de espera de

79


Q1tr1tej7tej12 tej9

Q0huecoReservado T12 tr0tej8

te0

tf0

treanud0

te1

Figura 3.17: Parámetros utilizados para la fusión de particiones

la cola 1 se actualiza sumándole el tiempo de ejecución de T12 y en la cola 0no se vuelve a copiar la tarea sino que se deja marcado el intervalo de tiempoque ocupará la parte de T12 que no cabe en la partición 1, a través de losparámetros tf0 (tiempo de fusión en la cola 0) y treanud0. Como observamosen la �gura, ha quedado un hueco temporal de valor tf0 − te0 en la cola Q0.

Este método permite mantener la complejidad constante del algoritmo ydejar el hueco correspondiente en la cola de menor tiempo de espera paraun posible utilización posterior, en el caso de que llegara una tarea con untiempo de ejecución menor al del hueco, como muestra la �gura 3.18a. Sila siguiente tarea que llega a dicha cola no cabe en el hueco, se escribirá acontinuación de la última tarea pero con un tiempo de lanzamiento igual altiempo de reanudación, como muestra la �gura 3.18b y manteniendo el huecopor si pudiera ser aprovechado posteriormente.

El coste de mantener la complejidad constante es el de dejar un solo huecopor cola, evitando así tener una lista de huecos que habría que recorrer cada

80


Figura 3.18: (a) aprovechamiento del hueco (b) imposibilidad de aprovechar el hueco

vez que llegara una tarea candidata a dicha cola (�gura 3.19). Esto no suponeun problema porque estamos asumiendo, de forma realista, que estos casos vana ser excepcionales y no habituales.

Figura 3.19: Mantenimiento de un solo hueco por cola

3.7.3. Implementación de la fusión de particiones

La fusión de particiones es una posibilidad real en arquitecturas actualescomo la Virtex 4. El trabajo de Sedcole [SBB+06] muestra que con una ade-cuada técnica de recon�guración es posible de�nir particiones contiguas en laFPGA. La unión de particiones se realiza a través de la escritura de un mapade bits que abarca las particiones seleccionadas. La recon�guración del busperiférico no es necesaria puesto que dichas tareas tienen garantizado el acceso

81


al bus exactamente de la misma manera que cualquier otra tarea, a través de laconexión �ja en la esquina exterior de la partición resultante, como se muestraen la �gura 3.20.


T12

T5

T4

P1

P3

Acceso al bus

Eje XP0+P2

Eje Y

Figura 3.20: Acceso al bus en particiones unidas

3.8. Algoritmo con fusión de particiones

Como ya hemos comentado, se utilizan cinco particiones virtuales que re-presentan la particiones unidas y así el algoritmo mantiene su forma original.Solamente hay que aumentar el número de iteraciones del mismo, la funciónque calcula el tiempo de espera de las colas virtuales y la función que escribeen las colas. La matriz M que pasa a ser una matriz de N*8.

En esta versión mejorada del algoritmo, la función que comprueba si cumpletiempos necesita calcular el tiempo de espera de la cola virtual k, que será el

82

Algoritmo con fusión de particiones 3.8

máximo tiempo de espera de las colas asociadas con las particiones que seunen, l y m. La tarea se escribirá en la cola con mayor tiempo de espera y sereservará dicho hueco en la cola asociada, a través del parámetro tiempo defusión.

Algoritmo 5 Algoritmo de selección de particiónfor (i=1; i ≤ N ; i++) dofor (j=1; i ≤ P ; j++) do

Xij = 0;end for

end forsel=false;k=0;while ((k < 9) and (sel == false)) doif (Cabe(Ti, Pk) == true) and (Cumplet(Ti, Qk) == true) thenEscribe(Ti,Qk);Xik=1;sel=true;

end ifk++;

end whileif (sel == false) thenRechaza(Ti);

end ifSalida();

Algoritmo 6 Subrutina Cabe(Ti,Pk)if ((wi ≤ Wk) and (hi ≤ Hk)) or ((wi ≤ Hk) and (hi ≤ Wk)) thenreturn true;elsereturn false;

end if

83


Algoritmo 7 Subrutina Cumplet(Ti,Qk)if ((k ≤ 3) and (teji + tek ≤ tmaxi)) thenreturn true;elseif ((teji + max(tel, tem)) ≤ tmaxi) thenreturn true;elsereturn false;

end ifend if

Algoritmo 8 Subrutina Salida()Vej=0;Vas=0;for (i=1; i ≤ N ; i++) do

Vas = +wi · hi · teji;for (k=0; k ≤ 8; k++) do

Vej = +Xik · wi · hi · teji;end for

end forRej = (Vej/Vas) · 100;

84

Comparación de resultados con y sin fusión 3.9

3.9. Comparación de resultados con y sin fusión

En la tabla 3.3 presentamos los resultados de comparar la ejecución de doslotes de tareas con la versión básica del algoritmo y la versión que implementala fusión de particiones. En ambos hay un pequeño número de tareas que nocaben en ninguna de las particiones de�nidas y que por lo tanto necesitan lafusión de particiones para su ejecución.

Tabla 3.3: Comparación de la versión básica y con fusión de particiones

R ( %) #u.t. A ( %)Lote Básica Fusión Básica Fusión Básica Fusión

L1 95 100 168 168 81,00 85,20L2 77,79 100 138 154 76,40 88,00

Los resultados muestran que la versión con fusión de particiones obtieneun mejor rendimiento que la versión básica ya que no rechaza las tareas queno caben en ninguna de las particiones.

El algoritmo resultante de incluir esta funcionalidad no aumenta la com-plejidad del algoritmo ni supone una carga computacional excesiva, por lo queconcluimos que la funcionalidad de fusión de particiones debe ser incorporadaal plani�cador de tareas basado en particiones.

85

Capítulo 4

Gestión basada en particiones con

adaptación dinámica

Este capítulo está dedicado a explicar el funcionamiento de la Unidad deAdaptación Dinámica (UAD). La UAD aparece como una mejora inevitable denuestro algoritmo ya que proporciona la �exibilidad de la que carece la versiónbásica original. Como demostraremos a través de los experimentos realizados,nuestro algoritmo de complejidad constante ofrece un buen rendimiento frentea algoritmos complejos y resulta por tanto una propuesta que puede competircon las existentes debido a la excelente relación sencillez / e�cacia que ofrece.Esto queda demostrado por una gama de experimentos, presentados en el capí-tulo 6, en los que podemos observar su buen comportamiento y e�ciencia paradistribuir las tareas entrantes entre las diferentes particiones de la FPGA.

Sin embargo es también evidente que se pueden dar situaciones en las que elalgoritmo presente un rendimiento bajo y por ello se ha diseñado una unidadque funciona en paralelo con las otras y cuya labor consiste en observar la

87

Capítulo 4. Gestión basada en particiones con adaptación dinámica

naturaleza de las tareas entrantes (o lo que más adelante de�niremos comodistribución de tareas) y decidir si es necesario realizar cambios en la formade gestionar el espacio disponible en la FPGA (es decir, en el tamaño/númerode particiones). La hemos llamado Unidad de Adaptación Dinámica (UAD),y pasaremos a describir su funcionamiento después de realizar un análisis delproblema de la plani�cación de una carga de trabajo en entornos on-line quenos permitirá sentar las bases para formalizar el problema y su solución.

La �gura 4.1 nos recuerda la estructura de nuestro plani�cador y la relaciónde la UAD con el resto de unidades del sistema.

Figura 4.1: Esquema del plani�cador

88

Análisis del problema para una FPGA sin particiones 4.1

4.1. Análisis del problema para una FPGA sin

particiones

4.1.1. Carga de trabajo ideal

El punto de partida de nuestro análisis será la adecuación de la carga detrabajo asignada a la FPGA en función de su tamaño o capacidad.

La carga de trabajo se modela por medio de un conjunto o lote de tareas,L, compuesto por N tareas, según se ha explicado. Para estudiar la adecuaciónde una carga de trabajo a la capacidad de la FPGA tendremos que utilizar unvalor tL igual al intervalo de tiempo durante el cual llegan y se ejecutan lastareas del lote L.

Se de�nen las condiciones ideales de utilización de la FPGA como lasituación en que es posible aprovechar su capacidad al 100%: uso del 100%del área de la FPGA el 100% del tiempo en el que están llegando y ejecutándoselas tareas que componen la carga.

Teniendo en cuenta que la carga de trabajo no se asigna de golpe sino que lallegada de tareas se reparte a lo largo de un intervalo de tiempo tllN − tll1, losvolúmenes de las tareas entrantes tendrían que encajar de forma perfecta en elvolumen libre de la FPGA sin dejar huecos (lo que no solamente depende delvolumen de cada tarea sino también de sus tiempos de llegada y de ejecución).La primera llegada de tareas tendría que ser en tll1 y estaría compuesta porun subconjunto de tareas cuyas áreas ocupasen el 100% de la FPGA. Si todasterminan de ejecutarse a la vez, la siguiente llegada de tareas tendría quecumplir los mismos requisitos y llegar en un tiempo no superior al tiempo de

89


ejecución del primer subconjunto o sub-lote, L1.Si los tiempos de ejecución de las tareas del primer sub-lote no tienen

tiempos de ejecución iguales, las siguientes tareas tendrían que encajar deforma perfecta en los volúmenes que van quedando libres en el volumen dela FPGA y deben llegar en tiempos iguales o anteriores al tiempo de �n deejecución de las tareas que están en la FPGA y cuyo hueco ocuparán. Además,las últimas tareas tendrían que terminar todas a la vez.

La �gura 4.2 nos muestra un ejemplo sencillo de condiciones ideales. Losnúmeros que aparecen sobre cada tarea indican su tiempo de ejecución.

Figura 4.2: Condiciones ideales de ocupación de una FPGA

Este ejemplo corresponde a un grupo de 9 tareas, de las cuales las primeras4 llegan a la vez, con diferentes tiempos de ejecución y todas las demás lleganrepartidas en el tiempo, cumpliendo las condiciones ideales.

En la �gura hemos resaltado con línea discontinua los tres grupos o sub-90


lotes de tareas que se ejecutan en la FPGA: las primeras que llegan, las otras3 que se ejecutan a continuación, y las últimas que llegan y se ejecutan, queterminan a la vez.

Podemos por tanto hacer una buena estimación del tiempo que tardaráen ejecutarse un lote de tareas que cumple las condiciones ideales a partirdel número de grupos de tareas que se ejecutarán en la FPGA (o capas detareas que cubren por completo el área del dispositivo) y su tiempo medio deejecución.

El número medio de tareas que se pueden ejecutar simultáneamente en laFPGA depende del tamaño medio de las tareas en relación al tamaño de laFPGA:

n =A

a=

A · n∑ni=1 ai

(4.1)

donde n es el número de tareas y ai el área de la tarea ti.Si ejecutamos las tareas una a una, el tiempo que se tardará en ejecutarlas

todas esttot =

n∑i=1

teji (4.2)

Por lo tanto, si las ejecutamos de n en n, el tiempo que se tardará será:

tideal =

∑ni=1 teji

n(4.3)

Sustituyendo nos queda que:

tideal =

∑ni=1 teji ·

∑ni=1 ai

A · n(4.4)

91


El número de capas de tareas en la FPGA en condiciones ideales es:

g =

∑ni=1 ai

A(4.5)

El tiempo que se tarda en ejecutar el lote ideal de n tareas es:

tideal = g · tej (4.6)

Resulta bastante obvio que las condiciones ideales son difíciles de cumpliry en la realidad se darán muchos tipos de situaciones que se alejarán de ellas.

El objetivo de esta parte del trabajo es analizar diferentes circunstanciasque pueden darse a lo largo del funcionamiento de un sistema de computaciónde propósito general para poder adaptar el número y tamaño de las particionesde la forma más adecuada.

Hemos empezado planteando el caso ideal ya que nos permite analizarlos factores relacionados con una adecuada gestión del dispositivo. A travésde la ecuación obtenida para el tiempo de ejecución de un lote que cumplelas condiciones ideales podemos observar que hay dos aspectos fundamentalesque in�uyen de manera conjunta en las posibilidades reales que existen paraejecutar de forma óptima un conjunto de tareas en una FPGA:

1. Distribución de la carga de trabajo en el espacio: tamaños de las tareas

2. Distribución de la carga de trabajo en el tiempo: tiempos de ejecuciónde las tareas e intervalos de llegada de las tareas

A partir de la ecuación obtenida anteriormente se puede llegar a otra ecua-ción que nos permite realizar un análisis transversal de la distribución de la

92


carga en el espacio-tiempo (es decir, relacionar los tamaños de las tareas conlos dos aspectos temporales: tiempo de ejecución e intervalos de llegada de lastareas) y que nos dará pautas para determinar la relación entre la carga detrabajo asignada a la FPGA y su capacidad, lo que ayudará a evaluar si eluso que se está haciendo del área de la FPGA es adecuado o no. Todo esto seexplica en detalle en la siguiente sección.

4.1.2. Frecuencia ideal de llegada de tareas

El problema de de�nir qué es una adecuada distribución de la carga detrabajo en el tiempo y en el espacio es complejo ya que ambos aspectos estánrelacionados entre sí. Por ejemplo, si casi todas las tareas que llegan son muygrandes y ocupan casi todo el área de la FPGA, su llegada debe ser espaciadaen el tiempo para que se pueda garantizar su ejecución y en intervalos detiempo parecidos a sus tiempos de ejecución para que los tiempos de espera nose acumulen (esto daría como resultado el rechazo de tareas, como podremoscomprobar también a partir de los resultados experimentales realizados). Sinembargo, si las tareas que llegan son en su mayoría pequeñas, entonces se puedegarantizar su ejecución aunque lleguen muy cercanas en el tiempo, siempre quela relación entre los tiempos de ejecución de las tareas y la frecuencia con laque llegan esté en equilibrio.

Por lo tanto debemos encontrar una manera de relacionar estos tres pará-metros: la frecuencia con la que llegan las tareas al sistema y sus característi-cas, es decir el área de FPGA que van a ocupar, ai= wi*hi, y el tiempo quepermanecerán ocupándola, teji.

93


La frecuencia de llegada de tareas al sistema es:

FLLT =n

tL(4.7)

donde tL es el tiempo que transcurre desde que llega la primera tarea dellote L al sistema hasta que termina de ejecutarse la última.

Considerando que en condiciones ideales estas tareas tardarán un tideal enejecutarse, podemos unir estas dos ecuaciones y de�nir la frecuencia ideal

de llegada de tareas de la siguiente manera:

FLLTideal =n

tideal

=n

g · tej=

A

a · tej(4.8)

Esta relación entre los tiempos de llegada de las tareas, sus tiempos deejecución y sus áreas indica las condiciones que nos permitirían utilizar el100% del dispositivo el 100% del tiempo.

La ecuación obtenida es muy importante ya que incluye simultáneamentela condición de una adecuada distribución de la carga de trabajo en el espacio,a través del término A/a y la condición de una adecuada distribución de lacarga de trabajo en el tiempo, a través de 1/tej.

Analizaremos en profundidad el signi�cado de esta ecuación:1. Si los tamaños medios de las tareas aumentan y sus tiempos de ejecución

no lo hacen, lo que tendremos es un aumento de la carga de trabajo asig-nada. Para que el conjunto de tareas pueda ejecutarse completamente,la FLLTreal deberá disminuir de forma proporcional. Si esto no sucede,el sistema habrá pasado a una situación de sobrecarga y es un problemano achacable a una incorrecta gestión del área de la FPGA.

94


2. Si los tiempos de ejecución de las tareas aumentan sin que lo hagan sustamaños, estaremos en una situación parecida a la anterior.

3. Si ambos parámetros aumentan, entonces tendremos exactamente la mis-ma situación que antes, aunque la disminución de la FLLTreal tendrá queser aún mayor.

4. Si lo que sucede es que las áreas o los tiempos de ejecución o ambosdisminuyen, lo que tendría que ocurrir para no llegar a una situaciónen que el sistema esté siendo infrautilizado es que la FLLTreal aumente.Si esto no sucede, la gestión del área de la FPGA se convierte en unproblema trivial ya que sobra espacio y ningún algoritmo tendrá querechazar tareas por no encontrar un lugar adecuado donde ejecutarlas.

4.1.3. Carga de trabajo real. De�nición del parámetro α

Podemos por tanto decir que para analizar la adecuación de la gestión delárea de la FPGA con respecto a las características de la carga de trabajo, esnecesario que FLLTreal ≈ FLLTideal. La relación entre la carga de trabajoasignada a la FPGA y su capacidad queda entonces de�nida por parámetrosque se pueden medir en tiempo real.

Esta relación entre la frecuencia real de llegada de tareas al sistema y laque sería ideal para las caracterísitcas de la carga de trabajo en relación a lacapacidad de la FPGA es un aspecto importante a tener en cuenta y lo hemosllamado parámetro α de�nido por la siguiente ecuación:

α =FLLTreal

FLLTideal

(4.9)

95


Hemos de�nido la relación entre la carga de trabajo real y la capacidad delsistema en función de este parámetro del modo siguiente:

Sistema sobrecargado: Decimos que un sistema está sobrecargado cuandose está asignando más carga de trabajo al sistema (la FPGA) del que puedeasumir, y que por tanto no existe ningún algoritmo capaz de garantizar laejecución del 100% de las tareas del lote:

α > 1

Sistema infrautilizado: Decimos que un sistema está infrautilizado cuandola carga de trabajo asignada es muy pequeña con relación a la capacidad dela FPGA y por lo tanto no es necesaria una gestión complicada del espaciodisponible:

α � 1

Sistema equilibrado: Esto quiere decir que la carga de trabajo es propor-cional a la capacidad del dispositivo:

α ≈ 1

Resumiendo, los valores de α indican la adecuación de la carga de trabajoa la capacidad de la FPGA. Hemos tomado una carga de trabajo que ocu-pa el 50% del volumen ideal de la FPGA como el límite entre un sistemainfrautilizado y uno equilibrado:

Sistema ideal: α = 1

96


Sistema sobrecargado: α > 1

Sistema infrautilizado: 0 ≤ α < 0,5

Sistema equilibrado: 0,5 ≤ α < 1

4.1.4. Ejemplo de variaciones de la carga de trabajo

Hemos realizado unas pruebas con cuatro lotes de 65 tareas cuyo volumenasignado es Vas = 285, 000 CBRs ∗ #u.t. Se ha partido de un lote ideal, L1,sobre el que se han realizado variaciones en la frecuencia de llegada con elobjetivo de conseguir simular cuatro tipos de situaciones: sistema ideal (L1),sistema sobrecargado (L2), sistema equilibrado (L3) y sistema infrautilizado(L4). Hemos simulado su ejecución en una FPGA de 50*50 CBRs. Para estecaso A = 2500, a = 625, tej = 7, 02 y tmaxi = tlli + 2 · teji para todas lastareas. El área está dividida en 4 particiones según muestra la �gura 4.3 y seha preparado el lote de tareas para que sus tamaños sean exactamente igualesa los de las particiones de�nidas. Para este caso FLLTideal = 0, 57(tareas/u.t).

Figura 4.3: Distribución en 4 particiones para una FPGA de 50*50

97


La tabla 4.1 nos muestra las características de los lotes junto a los resul-tados obtenidos de la simulación. Hemos representado las unidades de tiempo(u.t.) que tarda la ejecución completa del lote, el porcentaje medio de área deFPGA utilizada en la ejecución completa del lote (%A) y el rendimiento de laplani�cación, de�nido como la relación entre el volumen de la carga de trabajoasignada y el volumen de carga de trabajo ejecutado (R). Los 4 lotes tienenlas mismas tareas.

Tabla 4.1: Resultados para comprobar la validez del parámetro α

Lote α #u.t. %A RL1 (ideal) 1,00 114 100 100

L2 (sobrecargado) 1,07 114 96,75 96,34L3 (equilibrado) 0,86 133 85,71 100L4 (infrautilizado) 0,43 262 43,51 100

A partir de la tabla comprobamos que en condiciones ideales (L1) se haceun uso del 100% de la FPGA durante el 100% del tiempo, mientras queen situaciones de sobrecarga (L2) se tienen que desechar algunas tareas (R <

100 % y uso del área de la FPGA cercano al 100%) y en situaciones de equilibriode la carga respecto a la capacidad de la FPGA (L3) o infrautilización (L4) seejecuta el 100% del volumen asignado aunque el uso del dispositivo es inferioral 100%, tanto menor cuanto menor sea el valor de α).

4.1.5. Conclusiones

Podemos por lo tanto concluir que el parámetro α, que se obtiene a partirde medidas del sistema en tiempo real, nos dará pautas acerca de cuándo puede

98

Análisis del problema para una FPGA con particiones 4.2

ser conveniente la realización de cambios en el número y tamaño de particionesde�nidas en la FPGA.

Sin embargo, este parámetro por sí solo no es indicador de los cambiosconcretos que son necesarios en cada caso, y debemos por tanto de�nir algúnparámetro más que nos indique el cambio en el número de particiones másadecuado en cada caso.

4.2. Análisis del problema para una FPGA con

particiones

Pasamos ahora a ampliar el análisis a nuestro caso particular en que el áreade la FPGA está dividida en P particiones, sin que P esté restringido al valorde 4 del algoritmo básico expuesto en el capítulo 3. Cuantas más particioneshaya, más tareas se podrán ejecutar simultáneamente, pero más pequeño seráel tamaño de las particiones. Por el contrario, disponer de particiones grandessigni�ca reducir el número de tareas que se pueden ejecutar simultáneamente.Encontrar el equilibrio entre el número y tamaño de las particiones adecuadopara las características de las tareas que llegan al sistema es el objetivo de estaparte del trabajo, que se concreta en el diseño del algoritmo para la Unidadde Adaptación Dinámica.

4.2.1. Distribución de particiones ideal. Parámetro Dp

Decimos que la distribución de particiones DP es adecuada para el conjuntode tareas que están llegando a ejecutarse en la FPGA cuando se cumple la

99


siguiente condición:

P ≈ A

a(4.10)

que quiere decir que el número y tamaño de particiones coincide con el númeromedio de tareas que se pueden ejecutar simultáneamente en la FPGA.

Si el sistema no está sobrecargado ni infrautilizado se cumplirá

FLLTreal ≈ FLLTideal

y combinando la ecuación 4.8 con la 4.10, nos dará:

FLLTreal ≈ P

tej(4.11)

que quiere decir que en cada intervalo de tiempo tej llegan P tareas al sistema,que se pueden ejecutar simultáneamente, y formula la condición de que ladistribución de la carga de trabajo en el tiempo sea adecuada para la capacidaddel sistema.

Un buen sistema de gestión del área debería conseguir que se cumpla lasiguiente ecuación: ∑

Ti∈Pj

teji ≈∑N

h=1 tejh

P∀Pj (4.12)

Esta ecuación re�eja el hecho de que la carga de trabajo que llega la sistemaserá distribuida de forma equitativa entre las particiones de la FPGA y porlo tanto las tareas no se acumularán en las colas y será raro el caso de que setenga que rechazar una tarea por no poder cumplir con su máximo tiempo de

100

Análisis del problema para una FPGA con particiones 4.2

espera.

Podemos entonces de�nir el parámetro Dp, que mide la adecuación de ladistribución en particiones como:

Dp =A

a · P(4.13)

Para un sistema con un número de particiones adecuado, Dp ≈ 1, que sededuce de la ecuación 4.10 y formaliza la idea de que el número y tamaño delas particiones debe ser proporcional a la relación entre el tamaño de las tareasy el tamaño de la FPGA.

Esta ecuación asimismo re�eja el hecho de que cuanto más pequeñas sonlas tareas, más se pueden ejecutar simultáneamente y por tanto el número departiciones adecuado tiene que ser mayor que en el caso de que los tamañosde las tareas sea grande, en que necesitaremos particiones más grandes y portanto también disminuirán en número, lo que es acorde con el hecho de que silas tareas son grandes no se podrán ejecutar muchas de ellas simultáneamente.

Para el caso particular de P = 4 la ecuación 4.11 re�eja que, en promedio,no están llegando más de cuatro tareas por cada intervalo tej y cada tarea sepuede ejecutar en una partición diferente.

Pasamos ahora a analizar los casos en que el algoritmo no esté realizandouna gestión correcta del área de la FPGA, que serán los casos que la UADdebe detectar y corregir.

101


4.2.2. Distribución de particiones no adecuada

Podemos decir que si se cumple la condición

FLLTreal ≈ A

a · tej(4.14)

o lo que es lo mismoα ≈ 1

el sistema está recibiendo una carga de trabajo muy ajustada a su capacidady si el algoritmo no está realizando una gestión adecuada del área de la FPGAse empezarán a rechazar tareas.

Tendremos dos posibilidades:

1. Dp > 1 Esto signi�ca que los tamaños de las tareas son pequeños enrelación al tamaño de la FPGA (a · P < A) y que el número de tareasque se están ejecutando simultáneamente, P , es insu�ciente y por lo tantose está desperdiciando mucha área de la FPGA

2. Dp < 1 Esto signi�ca que los tamaños de las tareas son grandes enrelación al tamaño de la FPGA (a · P > A) y que no se pueden ejecutarP tareas simultáneamente

4.3. Cambio dinámico del número de particiones

Disponemos de dos parámetros medibles en tiempo real que nos dan infor-mación acerca de la adecuación de la distribución de la carga de trabajo en elespacio y el tiempo con respecto a la capacidad del dispositivo y del uso que

102

Cambio dinámico del número de particiones 4.3

se está haciendo de los recursos de la FPGA con un determinado número departiciones.

Si α ≈ 1 pero Dp > 1 resulta evidente que habrá que dividir el espacio dela FPGA en un número mayor de particiones de menor tamaño para que sepueda ejecutar un mayor número de tareas simultáneamente. Análogamente,si α ≈ 1 pero Dp < 1 es un claro indicativo de que el tamaño de las particioneses excesivamente pequeño para el tamaño de las tareas y una posible soluciónes reducir el número de particiones para que estas sean de tamaño mayor y nohaya que recurrir a la unión de particiones constantemente, ya que esto podríaperjudicar el rendimiento del algoritmo.

Sin embargo, la condición α ≈ 1 se re�ere a unas condiciones de la cargade trabajo muy parecidas a las ideales y no es realista suponer que la carga detrabajo las cumplirá. Por lo tanto es preciso analizar el signi�cado del resto decondiciones de la carga de trabajo y decidir qué se debe hacer con respecto alnúmero/tamaño de las particiones en cada una de ellas.

Si α es muy bajo tendremos una carga de trabajo excesivamente pequeñacon respecto a la capacidad del dispositivo, lo que signi�ca que el dispositivoestá siendo infrautilizado. Desde el punto de vista de su gestión, el problemade asignación de espacio resulta trivial ya que la frecuencia de llegada de lastareas es muy baja y encontrarán a su llegada numerosas opciones de ejecución.Pongamos por ejemplo el caso de una carga de trabajo donde las tareas sontodas de un tamaño muy grande, por ejemplo del 50% del tamaño de la FPGA,con tiempos de llegada entre las tareas iguales a sus tiempos de ejecución.Tendremos una ocupación teórica de la FPGA del 50% (un α ≈ 0, 5) y laversión básica de 4 particiones podrá ir ejecutando las tareas secuencialmente

103


sin problemas de no poder cumplir con su tiempo máximo (tendrá siempre lapartición más grande disponible para cualquier tarea de tamaño 50% que llegueal sistema). Lo mismo sucederá con tareas que sean de tamaño muy pequeño:el algoritmo les asignará particiones de mayor tamaño del que necesitan y sedesperdiciará mucha área pero esto será debido a la baja a�uencia de tareasal sistema y no a una mala gestión.

Por el contrario, si α es alto, tendremos una situación en la que se estádemandando al dispositivo que ejecute una carga de trabajo que literalmenteno cabe en él. En estas condiciones no puede achacarse el volumen de trabajorechazado exclusivamente a la gestión que se está haciendo del área del dis-positivo. Esto no quiere decir, sin embargo, que no se deba revisar el valorde Dp, ya que precisamente en este tipo de situaciones es muy importantehacer el mejor uso posible del área del dispositivo, con el objetivo de paliarla descompensación existente entre la carga de trabajo y la capacidad de laFPGA.

Si α > 1, la adecuación del tamaño/número de particiones a las caracte-rísticas de las tareas es vital para conseguir el mejor rendimiento posible enla situación de sobrecarga, aunque no se podrá garantizar en ningún caso laejecución del 100% de la carga de trabajo asignada.

En resumen, si α es muy bajo, no merece la pena hacer ningún cambio, y siα es equilibrado, ideal o excesivo, deberemos calcular Dp y realizar los cambiospertinentes para mejorar la e�ciencia del algoritmo.

Estamos por lo tanto en condiciones de presentar el esqueleto de lo queserá el algoritmo de la UAD, basándonos en el cálculo en tiempo real de losparámetros α y Dp, como se muestra en el algoritmo 9.

104

Cambio dinámico del número de particiones 4.3Algoritmo 9 Base para el algoritmo de la UAD

α = FLLTreal/FLLTideal;Dp = A/a · P ;if (0, 5 ≤ α) thenif (DP > 1) thenAumentar-numero-de-particiones();

end ifif (Dp < 1) thenDisminuir-numero-de-particiones();

end ifend if

Como se ha mencionado, esto no es más que un esqueleto al que le faltanmuchos detalles para estar completo, y que se listan a continuación:

1. Formalizar los diferentes tipos de situaciones que pueden darse y deter-minar el número y tamaño de particiones adecuado para cada una deellas.

2. Determinar qué datos son necesarios para identi�car correctamente estassituaciones, es decir, determinar los valores reales de Dp medidos entiempo real y los valores concretos que representan las situaciones teóricascorrespondientes a Dp > 1 y Dp < 1. También es necesario determinarel tamaño de la muestra que vamos a considerar durante la ejecución delalgoritmo para obtener información realista de lo que está sucediendoen el sistema en tiempo real. Esta muestra debe permitir detectar lassituaciones a tiempo y no tomar decisiones precipitadas.

3. Decidir la forma concreta en que se llevará a cabo el cambio en las parti-ciones: qué parámetros es necesario cambiar, qué valores nuevos tomaránen cada situación y cómo se efectuará el cambio de particiones con el mí-

105


nimo coste posible.

Examinaremos cada uno de estos puntos en detalle en las secciones quesiguen, presentando el estudio teórico y su comprobación experimental.

4.4. Estimación del número de particiones ade-

cuado a una carga de trabajo

En esta sección plantearemos la solución al problema de decidir los nuevostamaños y número de particiones adecuadas a cada carga de trabajo.

El buen rendimiento de nuestro algoritmo está basado en el reparto equi-tativo de la carga de trabajo entre las particiones. En la sección 4.2.1 hemosvisto que si se cumplen las condiciones de carga de trabajo adecuada para elsistema, ecuación 4.10, y distribución adecuada de particiones, ecuación 4.11,obtendremos como consecuencia un reparto equilibrado de la carga de trabajoentre las particiones, ecuación 4.12.

Es necesario por tanto de�nir los parámetros que ayudarán a caracterizarla carga de trabajo y a identi�car las distribución en particiones que es másconveniente en diferentes situaciones.

4.4.1. Caracterización de la carga de trabajo

El problema de representar la carga de trabajo es bastante complejo debidoa que en la actualidad carecemos de datos experimentales de sistemas realescomo el de nuestro modelo. Existe poca información acerca de los resultadosde la síntesis de aplicaciones reales sobre hardware recon�gurable y los autores

106

Estimación del número de particiones adecuado a una carga de trabajo 4.4

que están trabajando en este campo realizan sus pruebas con lotes de tareasarti�ciales, generados aleatoriamente.

De los datos recopilados a partir de publicaciones donde aparecen datosde síntesis de aplicaciones reales, [KCMO06], [OPF06], [JTR+05], [NHCB02],[RMVC05], podemos concluir que las aplicaciones reales sintetizadas a hardwa-re recon�gurable tienen tamaños muy variados y tiempos de ejecución tambiénvariados, y que hay muchas maneras de sintetizar una tarea para su ejecuciónen hardware recon�gurable y por lo tanto las aplicaciones se pueden dividiren sub-tareas de varias formas diferentes, dando lugar a conjuntos de tareasdistintos con grafos de ejecución diferentes, como se muestra en [BdNSSL06].

4.4.1.1. Campana de Gauss

Tomando como ejemplo la realidad cotidiana, vemos que el éxito de la dis-tribución en forma de campana de Gauss se debe precisamente a que re�ejade una forma muy exacta lo que sucede en poblaciones estadísticas normales,es decir, donde no existen unas circunstancias especí�cas (que se consideraríancomo anómalas y de hecho la medicina occidental actual se basa en este princi-pio) que hagan que predomine una cierta tendencia sobre otras. En estos casoslo que la distribución normalizada de Gauss está re�ejando es que la mayoríade casos corresponden a una media (aunque esta media puede variar con eltiempo, la localización espacial, el factor racial etc., como son por ejemplo laestatura de las personas, la edad media en que las mujeres llegan a la menopau-sia, la prevalencia de determinadas enfermedades, etc.) y que solamente hayuna minoría de casos que se alejan de esta media, tanto más minoría cuantomayor es la desviación con respecto a lo normal.

107


Aplicando estos mismos principios a la carga de trabajo hipotética que po-dremos encontrar en este tipo de sistemas cuando empiecen a implementarse,podemos esperar un comportamiento bastante similar. Es decir, que podremosesperar una mayoría de tareas que no sean ni excesivamente pequeñas ni ex-cesivamente grandes y que las tareas con tamaño muy pequeño o muy grandeserán menos frecuentes que las de tamaño intermedio. Por supuesto que a lolargo de una ejecución de un sistema de propósito general puede haber perío-dos de tiempo en que el tipo de aplicaciones a ejecutar sea muy especí�co ydé lugar a conjuntos de tareas que tienen características muy parecidas entresí y que por tanto o no corresponden a una distribución de tipo gaussiano, ocorresponden a una campana desplazada.

Entendemos por tanto que una aproximación válida para plantear el aná-lisis de las características de la carga de trabajo es la de tomar como casobase la situación en que las tareas de tamaños intermedios serían mayoría ylas de tamaños grandes o pequeños serían minoría. La distribución de particio-nes propuesta y expuesta hasta ahora como punto de partida del plani�cadorresponde de forma intuitiva a esta hipótesis y sería la más acertada, al menoscomo media de la ejecución de un sistema de computación de propósito gene-ral. Esta forma de distribuir el área de la FPGA proporciona dos particionespara tareas de tamaño mediano (P1 y P2), una para tareas pequeñas (P0) yotra para tareas grandes (P3).

Y sin embargo, aunque este modelo de gestión del área de una FPGAfunciona su�cientemente bien en un amplio rango de casos, no podemos con-tentarnos con estos resultados ya que en muchos momentos de la ejecución lacarga de trabajo de este hipotético sistema seguramente no se ajustará a las

108


condiciones descritas como normales.Por ejemplo, para implementar el algoritmo JPEG, todas las tareas son

de tamaño pequeño y no hay ninguna tarea de tamaños medianos o grandes(con respecto al área de la Virtex-2), lo que signi�ca que si se ejecuta variasveces seguidas, y sin que haya otras aplicaciones ejecutándose simultáneamenteen el sistema, la distribución de tamaños de tareas resultante no será la delcaso base sino que corresponderá a otro tipo de distribución muy diferente. Alser las tareas de tamaño pequeño, la frecuencia con la que podrían llegar alsistema puede ser excesivamente alta para una distribución en 4 particiones yel rendimiento del sistema puede llegar a ser bastante malo. Intuitivamente,sabemos que la solución consiste en aumentar el número de particiones, queserán de tamaños inferiores a las del caso base, pero su�cientes para el tipo detareas que están llegando al sistema.

La �gura 4.4 nos muestra una representación del caso básico y dos posiblesdesviaciones de dicho caso. Empezaremos analizando este tipo de distribucionesy después pasaremos a comprobar la validez del estudio para otros tipos dedistribuciones posibles.

Figura 4.4: Distribuciones espaciales de la carga de trabajo

109


Aunque intuitivamente podamos describir el problema y sus soluciones, esimprescindible recurrir a la formalización, tanto para describir las posibles dis-tribuciones de la carga en el espacio como la de las acciones que es adecuadotomar en cada caso y justi�carlas. Es evidente que las posibles variaciones enla distribución de la carga de trabajo son prácticamente in�nitas y que es im-posible describirlas todas de manera exhaustiva. Nuestro objetivo por lo tantoes partir de una caso fácil de formalizar y analizar, y a partir de este caso baseplantear posibles desviaciones y asegurarnos de que las conclusiones a las quellegamos y los cambios que proponemos implementar cubren un rango su�cien-temente amplio de posibles casuísticas como para poder garantizar la e�caciadel algoritmo basado en particiones en prácticamente todas la situaciones.

4.4.1.2. Distribución de la carga de trabajo en el espacio: paráme-

tros β, δ y γ

Hemos estado mencionando los conceptos de tarea pequeña, mediana ygrande y manejándolos de una forma intuitiva. Para poder describir los as-pectos de una carga de trabajo de forma objetiva necesitamos concretar estosconceptos.

La de�nición de tamaño de una tarea es relativa y el adjetivo pequeñadebe ser utilizado siempre en comparación con otro tamaño. En nuestro casola comparación del tamaño de las tareas se hace respecto al tamaño de laFPGA, A, medido en CBRs.

Teniendo en cuenta el considerable aumento en el número de CLBs de lasFPGAs actuales, como se ha explicado en el capítulo 1, de�niremos los tamañosde las tareas de la siguiente manera:

110


• Tareas pequeñas: son aquéllas que como máximo ocupan un 10% delárea de la FPGA. El área de las tareas pequeñas, ap, cumple la condiciónap ≤ 0, 1 · A

• Tareas medianas: son aquéllas que como máximo ocupan un 20% delárea de la FPGA: 0, 1 · A < am ≤ 0, 2 · A

• Tareas grandes: son aquéllas que como máximo ocupan un 50% delárea de la FPGA: 0, 2 · A < ag ≤ 0, 5 · A

Una Virtex-5 tiene casi 26.000 CLBs, así que para esta FPGA una tareapequeña sería cualquiera que ocupara menos de 2.600 CLBs, una tarea medianaocupa entre 2.600 y 5.200 CLBs y una tarea que llegue a ocupar la mitad dela FPGA sería una tarea realmente grande, que ocuparía 13.000 CLBs.

Como el trabajo está desarrollado para gestionar la multi-tarea hardware,no tiene mucho sentido pensar que puede ser habitual que las tareas que sevan a ejecutar ocupen más de la mitad del dispositivo. Si esto sucede, el al-goritmo pondrá en marcha el mecanismo de unión de particiones y las podráejecutar igualmente, pero consideramos que estos casos son excepcionales y norepresentativos del tipo de sistema que estamos analizando.

Asimismo, el hecho de de�nir el tamaño de una tarea en función del tamañode la FPGA dota a estos conceptos de la �exibilidad imprescindible en uncontexto tecnológico altamente dinámico donde las FPGAs crecen casi de añoen año y nos ha permitido obtener un método aplicable a cualquier FPGA.

Pasamos entonces a de�nir algunos tipos de distribuciones de la carga detrabajo, que expresaremos en función de los tiempos de ejecución de las tareasy no del número de tareas, ya que se trata de analizar la carga de trabajo por

111


particiones, y lo que nos interesa es saber el tiempo que una partición de undeterminado tamaño estará ocupada. N es el número de tareas en el lote querepresenta la carga de trabajo del sistema.

Utilizaremos los parámetros β, δ y γ para caracterizar las cargas de trabajoen función de la proporción de tareas de un determinado tamaño:

1. Distribución de tareas pequeñas: es una carga de trabajo represen-tada por un lote de tareas Lp donde la mayoría de tareas son de tamañopequeño y el resto de tamaños se reparte en partes iguales. Cumple lascondiciones:

a) ∑ai≤ap

teji = β ·∑N

h=1 tejh

b) ∑ap<ai<ag

teji = δ ·∑N

h=1 tejh

c) ∑ai≥ag

teji = γ ·∑N

h=1 tejh

d) β + δ + γ = 1

Los valores β = 0, 5, δ = 0, 25 y γ = 0, 25 caracterizan a este tipo dedistribución y por lo tanto de ahora en adelante utilizaremos la notaciónLp = (0, 5; 0, 25; 0, 25) para referirnos a ella ya que representa la ideaexpresada de forma intuitiva en la �gura 4.4c.

2. Distribución de tareas medianas: es una carga de trabajo represen-tada por un lote de tareas Lm donde la mayoría de tareas son de tamañomediano y el resto de tamaños se reparte en partes iguales. Cumple lascondiciones a), b), c) y d) con valores β = 0, 25, δ = 0, 5 y γ = 0, 25.De ahora en adelante nos referiremos a este tipo de distribución con la

112


notación Lm = (0, 25; 0, 5; 0, 25) ya que representa la idea expresada deforma intuitiva en la �gura 4.4a.

3. Distribución de tareas grandes: es una carga de trabajo representadapor un lote de tareas Lg donde la mayoría de tareas son de tamañogrande. Cumple las condiciones a), b), c) y d) con valores β = 0, 25,δ = 0, 25 y γ = 0, 5. De ahora en adelante nos referiremos a este tipo dedistribución con la notación Lg = (0, 25; 0, 25; 0, 5) ya que representa laidea expresada de forma intuitiva en la �gura 4.4b.

4. Distribución de tareas casi total de pequeñas: es una carga detrabajo representada por un lote de tareas Lpp donde prácticamentetodas las tareas son de tamaño pequeño. Cumple las condiciones a),b), c) y d) con valores β = 0, 80, δ = 0, 10 y γ = 0, 10. De ahoraen adelante nos referiremos a este tipo de distribución con la notaciónLpp = (0, 80; 0, 10; 0, 10).

Vamos ahora a de�nir un método para relacionar las características de ladistribución de tareas con el número de particiones adecuado para cada unade ellas.

4.4.1.3. Número de particiones ideal para cada tipo de distribución

Para realizar este cálculo debemos retomar la ecuación 4.13 que indicabauna correcta adecuación de la distribución de particiones para un determinadoconjunto de tareas caracterizado por su área media a:

Dp =A

a · P

113


Y recordando que la condición para que una distribución sea adecuada es:

Dp ≈ 1

De�nimos el área media que caracteriza a un tipo de distribución

como la media ponderada de las áreas representativas de cada tipo de tareas.Una de�nición general válida para cualquier distribución será:

aLt = β · ap + δ · am + γ · ag (4.15)

donde ap es el área que representa a las tareas de tipo pequeño, am es el áreaque representa a las tareas de tipo mediano y ag es el área que representa alas tareas de tipo grande y los valores de β, δ y γ son los que caracterizan a ladistribución Lt.

Si queremos saber cual es el número idóneo de particiones para distribuirel espacio de la FPGA conforme a la distribución de tamaños de la tareas, ten-dremos que tomar como valor representativo de cada tipo de tareas el máximode cada tamaño, para asegurarnos de que todas las tareas de un tipo cabenen las particiones asignadas a dicho tipo. De otra forma, la distribución departiciones obtenida no podrá asegurar que las tareas de mayor tamaño de untipo quepan en las particiones diseñadas a tal �n.

Por lo tanto, hemos utilizado el máximo tamaño de tareas de cada tipo paracalcular el valor de P adecuado para cada tipo de distribución y obtenemoslos siguientes resultados:

1. aLp = 0, 225 · A ⇒ P = 4, 44

114


2. aLm = 0, 250 · A ⇒ P = 4

3. aLg = 0, 325 · A ⇒ P = 3, 07

4. aLpp = 0, 150 · A ⇒ P = 6, 6

Para el caso que hemos utilizado como caso base, Lm, obtenemos un valorde P = 4, lo que coincide con la distribución básica presentada hasta estemomento.

Para el caso de tareas grandes, obtenemos un valor de P cercano a lo quela intuición nos diría: si llegan menos tareas porque son muy grandes, es mejortener menos particiones y que cada partición sea grande, para evitar tener queestar uniendo particiones con frecuencia y dado que con tamaños comprendidosentre el 20% y el 50% del área de la FPGA va a ser prácticamente imposibleejecutar más de 3 tareas simultáneamente.

El resultado que puede parecernos sorprendente, porque contradice lo queen un principio tenderíamos a pensar, que hay que aumentar el número departiciones para ejecutar más tareas de las pequeñas, es el del número departiciones obtenido para la distribución de tareas de tamaño pequeño.

Un resultado P = 4, 4 signi�ca que no está claro que en un caso así lo másconveniente sea aumentar el número de particiones. Y también signi�ca queuna distribución del área en 4 particiones puede resultar su�ciente aunque lamayoría de tareas sean pequeñas.

En primer lugar y como ya se ha comentado anteriormente, el caso de quelas tareas que llegan sean pequeñas no es el más crítico ya que se puedenejecutar en cualquiera de las 4 particiones y por tanto es muy difícil que lapartición más pequeña, P0, llegue a saturarse.

115


En segundo lugar, si en la distribución sigue habiendo una cantidad altade tareas grandes (una de cada 4 es de tamaño grande) parece que tiene sen-tido mantener una partición grande para ellas y evitar recurrir a la unión departiciones con una frecuencia que resultaría excesivamente alta.

Lo que realmente signi�ca una mayoría de tareas pequeñas es que de cadacuatro tareas que llegan, dos van a ser pequeñas, una mediana y otra grande. Yesto en relación a la distribución de medianas, supone que una de las medianasse ha sustituido por una de las pequeñas, de cada grupo de 4, en media. Locual no puede tener un gran impacto ni en la FLLTideal para este tipo dedistribución ni en el área media que la representa, como puede verse en losresultados obtenidos (pasa de 0,25 para medianas a 0,225 para las pequeñas,debido a que el tamaño de las grandes tiene mucho más peso en el cálculo queel tamaño de las pequeñas).

Una vez hecha esta re�exión, deja de resultarnos tan sorprendente el re-sultado y encontramos que tiene sentido. Más adelante presentaremos variaspruebas realizadas que con�rman estos resultados teóricos.

Para una carga de trabajo donde prácticamente todas las tareas son pe-queñas resulta más e�ciente aumentar el número de particiones. Para este casoobtenemos un aLpp = 0, 15 · A, que se acerca mucho al tamaño medio de lastareas pequeñas.

El mismo resultado se obtendría también para una distribución del tipoLp donde las tareas grandes fueran del mínimo tamaño posible. En este casotendríamos un a medida en tiempo real más parecida a la de Lpp que a lade Lp y el parámetro Dp lo indicaría subiendo por encima del valor ≈ 1 y sedeterminaría un cambio a 6 particiones, lo que como veremos en los resultados

116


presentados, resulta más conveniente que mantener 4 particiones. Hacemosesta aclaración porque el valor teórico obtenido para Lp es de P = 4, 4, lo que,como decíamos, signi�ca que no está completamente claro que dividir el áreaen 4 particiones sea lo más adecuado siempre para este tipo de distribuciones.

Podríamos también de�nir un per�l donde casi todas las tareas sean gran-des. Si aplicamos la de�nición anterior al tamaño de tareas grandes, obtendre-mos un resultado de P = 2, nada sorprendente pues si prácticamente todaslas tareas que llegan pueden alcanzar un tamaño del 50% de la FPGA lo queintuitivamente haríamos es dividir la FPGA en dos mitades y ejecutar unatarea en cada una de ellas. Sin embargo, este tipo de distribución correspon-dería a una carga de trabajo muy elevada y la FLLTideal será mucho más bajaque en cualquiera de los otros casos, incluido el de tareas grandes. Si ademásobservamos que no todas las tareas que lleguen ocuparán media FPGA y quemuchas tareas de las grandes pueden ser de tamaño inferior o igual al 25% dela FPGA, nos damos cuenta de que no merece la pena añadir más casuísticasal algoritmo que ejecuta la UAD ya que la solución de 3 particiones propuestapara un tipo de distribución de mayoría de tareas grandes (siempre que lostamaños de las 3 particiones resultantes sean los adecuados) es más que su-�ciente para estos raros casos. De hecho, si tenemos 3 particiones y una deellas es de tamaño el 50% del área de la FPGA, si alguna de las dos tareas esde tamaño mayor al 25% de la FPGA puede ejecutarse en dicha partición yla otra en alguna de las dos que quedan libres. Si no cabe en ninguna de lasotras dos, se unirán, lo que no supondrá un sobrecoste al sistema ya que nuncaestarán ocupadas por tareas pequeñas cuyo �n de ejecución haga esperar a lasmás grandes.

117


4.4.1.4. Veri�cación con resultados experimentales

A continuación presentamos el resultado de ejecutar diferentes tipos de dis-tribuciones con el caso base, es decir, con una FPGA dividida en 4 particionesde diferente tamaño. Las pruebas se han realizado simulando una FPGA de50*50 CBRs. La tabla 4.2 muestra las características de los lotes de tareasutilizados y los resultados obtenidos de su ejecución con 4 particiones.

Tabla 4.2: Ejecución de diferentes tipos de distribuciones con 4 particiones

Lote α β δ γ a ( %A) Dp 4P R ( %Vej)L1 1 0,25 0,5 0,25 25,00 1 100L2 0,90 0,25 0,5 0,25 23,23 1,11 100L3 0,79 0,5 0,25 0,25 19,77 1,26 100L4 0,75 0,5 0,25 0,25 13,00 1,92 60L5 0,69 0,8 0,1 0,1 12,01 2,07 56L6 0,70 0,25 0,25 0,5 30,02 0,78 85

El lote L1 es un lote ideal, para el cual se obtiene un Dp exactamente iguala 1. El siguiente lote, L2, es un lote que corresponde a una distribución demedianas, con una frecuencia de llegada de tareas alta y cercana a la ideal ycon un área media ligeramente superior a la de las tareas medianas (por efectodel peso del área de las tareas grandes en el cálculo de la media) y que seejecuta sin problemas y en su totalidad con una distribución en 4 particiones.Para este caso el valor de Dp es ligeramente superior al valor teórico de 1.

El lote L3 es un lote del tipo de mayoría pequeñas en el que muchas de lastareas grandes tienen tamaños cercanos al 50 % del área de la FPGA, por loque el área media resultante está más cercana al tamaño de las grandes (dehecho es el máximo de las medianas) y su ejecución en 4 particiones resulta

118


también muy e�ciente. El valor de Dp está también por encima de 1.En el caso del lote L4, donde el tamaño de las tareas grandes es bastante

menor que el 50 % del área de la FPGA, vemos que el área media resultante(13%) está en el margen inferior del tamaño de las medianas y por debajo delárea teórica del 15 % obtenida para Lpp. En este caso la frecuencia de llegadade tareas es relativamente alta y Dp es cercano al doble del teórico 1 que indicauna buena distribución del área de la FPGA en particiones. Algo similar sucedecon el lote L5 donde prácticamente no hay tareas grandes (y estas no llegan aocupar la mitad de la FPGA en ningún caso).

Por último el lote L6 representa una distribución de tareas grandes. El áreamedia es muy grande, la tercera parte de la FPGA, y el valor de Dp para estetipo de distribución es inferior a 1.

Con estos resultados podemos con�rmar que para las distribuciones presen-tadas solamente serían necesarios los cambios en las particiones para los lotesL4, L5 y L6, que pertenecen a las situaciones en que Dp se aleja mucho de suvalor de 1 teórico. Observamos también que la variación de Dp por debajo desu valor teórico y el real es asimétrico y que es más importante examinar elárea media del conjunto de tareas a la hora de tomar decisiones que los valoresde β, δ y γ.

Presentamos también la tabla 4.3 que resume el estudio teórico del nú-mero de particiones adecuado para diferentes tipos de distribuciones de tipogaussiano y no gaussiano.

Podemos observar que con un modelo de adaptación dinámica que manejedistribuciones del área de la FPGA en 3, 4 y 6 particiones se pueden cubrirla mayoría de casos. No así casos extremos, como la situación en que todas

119


Tabla 4.3: Cálculo del número de particiones necesario para diferentes distribuciones

β δ γ a ( %A) P0,25 0,5 0,25 25,00 4,000,5 0,25 0,25 22,50 4,400,25 0,25 0,5 32,50 3,070,2 0,4 0,4 30,00 3,330,4 0,2 0,4 28,00 3,570,2 0,4 0,2 22,00 4,540,8 0,1 0,1 15,00 6,661 0 0 10,00 10,000 1 0 20,00 5,000 0 1 50,00 2,00

0,33 0,33 0,33 26,66 3,75

las tareas son pequeñas, aunque sí incluye (gracias a la unión de particiones)situaciones en que la totalidad de las tareas sean grandes (usando 3 particionesy uniendo las dos más pequeñas cuando sea necesario). También podemosobservar que el paso a 6 particiones solamente merece la pena cuando el númerode tareas realmente grandes (que ocupen más del 25 % de la FPGA) sea muypequeño (o nulo) en relación al resto de tareas.

A continuación presentamos la tabla 4.4 con los resultados de ejecutar loslotes anteriores con el número de particiones adecuado para sus características.

Los resultados presentados en esta tabla nos muestran que una distribuciónen particiones adecuada a las características de la carga de trabajo permiteejecutar el total de la carga asignada, es decir, obtener un buen rendimientodel algoritmo en prácticamente cualquier situación posible.

En la siguiente sección presentamos detalladamente la forma en que se haráel reparto del área de la FPGA para cada uno de estos tres casos: P = 3, P = 4

120


Tabla 4.4: Ejecución de diferentes tipos de distribuciones con 4 particiones

Lote Tipo No particiones R ( %Vej)L1 Lm (ideal) 4 100L2 Lm 4 100L3 Lp 4 100L4 Lpp 6 100L5 Lpp 6 100L6 Lg 3 100

y P = 6.

4.4.2. Forma y tamaño de las distintas distribuciones en

particiones

Distribución de tareas pequeñas: Para un Lp que contenga una cuar-ta parte de tareas que ocupan hasta media FPGA se ha obtenido unP = 4, 4 que daría como resultado una distribución en particiones delárea de la FPGA en 4 particiones de diferente tamaño, correspondientesa las del caso base representadas en la �gura 4.5. En este caso la parti-ción más grande P3 ocupa la mitad de la FPGA, las particiones P2 y P1

ocupan el 20% y la partición pequeña, P0 ocupa el 10% del área de laFPGA.

Distribución de tareas medianas: Para Lm se ha obtenido tambiénun P = 4 que daría como resultado una distribución del área de la FPGAen 4 particiones de diferente tamaño, correspondientes a las del caso baserepresentadas en la �gura 4.5.

121


Figura 4.5: Particiones adecuadas para una distribución de tareas pequeñas y medianas

Distribución de tareas grandes: Para Lg se ha obtenido un P = 3

que daría como resultado una distribución en particiones del área dela FPGA en 3 particiones de diferente tamaño, correspondientes a lasrepresentadas en la �gura 4.6. En este caso la partición más grande, P2,ocupa la mitad de la FPGA y la otra mitad está dividida en dos partesde igual tamaño. Esta distribución en particiones permite ejecutar unatarea de tamaño 50% del área de la FPGA (y hasta 2 si unimos lasotras dos particiones) y hasta 3 tareas grandes, siempre que las otras dosno superen el 25% del tamaño de la FPGA, sin por ello perjudicar laplani�cación de tareas más pequeñas que pueden llegar intercaladas conlas grandes.

Distribución casi total de tareas pequeñas: Para Lpp (y Lp con el122


Figura 4.6: Particiones adecuadas para una distribución de tareas grandes

100 % de tareas grandes del mínimo tamaño) se ha obtenido un P = 6, 6

que daría como resultado una distribución del área de la FPGA en 6particiones. Los tamaños de estas particiones podrían ser todos igualesentre sí (16,66% del tamaño de la FPGA), es decir, que obtendríamosuna división en particiones que resultarían demasiado pequeñas paracualquier tarea grande y muchas medianas que llegaran. Otra opción, quenos parece más acertada, es dividir el área de la FPGA en 6 particiones dediferente tamaño, según muestra la �gura 4.7, donde 4 de las particionespueden ser muy pequeñas (12,5% del área de la FPGA) mientras quelas otras dos pueden ser algo mayores (25% del área de la FPGA), loque evita tener que realizar unión de particiones en muchos casos y nodisminuye el número de particiones disponibles para las tareas pequeñas.

123


Figura 4.7: Particiones adecuadas para una distribución con casi todas las tareas pequeñas

4.4.3. Resultados experimentales

Mostramos aquí un conjunto de pruebas cuyo objetivo es comprobar lavalidez de estos tres tipos de distribuciones propuestas, realizadas con unaserie de lotes de tareas que se ajustan a los modelos teóricos de distribucionesexpuestos anteriormente. Primero presentaremos los resultados obtenidos conlotes de tareas medianas y grandes y después los resultados obtenidos paralotes con tareas fundamentalmente pequeñas.

4.4.3.1. Ejecución de lotes de tareas medianas y grandes

La tabla 4.5 presenta las comparativas entre la ejecución en 4P y 3P delotes de tareas medianas y grandes con diferentes cargas de trabajo.

Los lotes L1, L2 y L3 corresponden a distribuciones de tareas medianas. Suárea media es más cercana al tamaño máximo de las medianas que a cualquierade los otros dos. El valor de Dp teórico calculado para estos lotes de tareas

124


Tabla 4.5: Comparativa 4P - 3P

Lote α a ( %A) Dp 4P Dp 3P R 4P ( %) R 3P ( %)L1 0,92 22,54 1,11 1,48 100 76,91L2 0,90 23,23 1,11 1,50 100 76,00L3 0,77 21,03 1,19 1,58 100 87,96L4 0,76 26,93 0,93 1,24 100 92L5 0,75 28,56 0,87 1,16 83,88 100L6 0,69 28,75 0,86 1,15 89,62 100L7 0,70 29,73 0,84 1,12 85 100L8 0,55 29,73 0,84 1,12 91 100L9 0,44 29,73 0,84 1,12 100 100

indica que su ejecución será mejor con una distribución en 4 particiones queen 3 particiones, lo que viene con�rmado por los resultados obtenidos.

El lote L4 corresponde a una distribución particular, que hemos denomi-nado lote plano, ya que el porcentaje de tareas de cada tipo es exactamenteigual. Corresponde a la distribución re�ejada en la última línea de la tabla 4.3,para la cual se obtenía un valor de P = 3, 75. Vemos que el valor de Dp esmás cercano al teórico cuando se calcula para una distribución en 4 particionesque para una de 3 particiones y los resultados experimentales con�rman quesu ejecución efectivamente es mejor con 4 particiones, aunque la diferencia enrendimiento no es excesiva.

Cuando la distribución se aleja del per�l de tareas medianas, como es el casodel resto de los lotes de tareas, vemos que al aumentar el área media (por efectode una mayor presencia de tareas grandes en el lote) los valores calculados deDp se acercan más al valor ideal cuando se calcula para 3 particiones que para 4particiones. La ejecución de todos los lotes excepto uno de ellos demuestran quela distribución del área de la FPGA en 3 particiones es mucho más adecuada

125


para este tipo de distribuciones.Examinaremos ahora en detalle lo que sucede con los lotes L7, L8 y L9.

De hecho se trata exactamente del mismo lote de tareas (mismo área mediay mismo volumen asignado) y lo único que los distingue es la frecuencia dellegada de tareas. Cuanto más se acerca α al valor ideal que corresponde a lasituación de carga de trabajo que llena el espacio de la FPGA prácticamentela totalidad del tiempo, más diferencia encontramos en el rendimiento entre laejecución en 4 particiones y la ejecución en 3 particiones.

Estos resultados con�rman que para un sistema infrautilizado, como el L9,con un valor de α = 0, 44 < 0, 5, la frecuencia de llegada de tareas es tan bajaque cualquiera de las dos distribuciones en particiones daría buenos resultados.Esto ya se comentó en la sección 4.1.2 y quedó re�ejado en el esqueleto dealgoritmo para la UAD presentado, en el cual solamente se calcula el valor deDp para sistemas que tangan un α ≥ 0, 5.

4.4.3.2. Ejecución de tareas fundamentalmente pequeñas

A continuación presentamos la tabla 4.6, que muestra la comparativa de laejecución de lotes de tareas de tipo casi todas pequeñas en 4P y 6P.

En esta tabla todos los lotes de tareas, excepto el L6, son de tareas muypequeñas, donde ninguna supera el 25 % del tamaño de la FPGA. Vemos queel área media de los lotes L1, L2, L3, L4 y L5 están ligeramente por debajo del15 % teórico obtenido para Lpp. En todos estos casos se observa que los valoresde Dp mas cercanos a 1 corresponden a una distribución en 6 particionesy que la ejecución de estos lotes de tareas con 4 particiones es claramentepeor que para 6 particiones, a excepción del lote L5 donde es exactamente

126


Tabla 4.6: Comparativa 4P - 6P

Lote α a ( %A) Dp 4P Dp 6P R 4P( %) R 6P( %)L1 0,69 13,88 1,80 1,20 80,57 100L2 0,58 14,16 1,76 1,17 84,82 100L3 0,62 14,00 1,78 1,19 83,12 100L4 0,55 14,00 1,78 1,19 96 100L5 0,46 14,00 1,78 1,19 100 100L6 0,79 19,77 1,26 0,84 100 85,27L7 0,13 3,65 27,39 18,26 100 100

igual para ambas distribuciones en particiones. Los lotes L3, L4 y L5 sonexactamente el mismo conjunto de tareas pero con frecuencias de llegada detareas decrecientes. Se pone de nuevo de mani�esto que para una frecuencia dellegada correspondiente a un sistema infrautilizado no merece la pena realizarcambios en las particiones.

El lote L6 corresponde a una distribución de tipo Lp, donde la mitad delas tareas son de tamaño pequeño. Sin embargo hay un 25 % de tareas detamaño cercano al 50 % de la FPGA. El área media de las tareas de estelote es prácticamente el máximo de las tareas medianas. En el estudio teóricohabíamos obtenido un valor de P = 4, 4 para este tipo de distribuciones. Losresultados muestran que la ejecución con 6 particiones es peor que con 4 ya queestas tareas tan grandes aparecen con bastante frecuencia (una de cada cuatroes grande) y necesitan 4 de las particiones pequeñas para ejecutarse. La uniónde estas cuatro particiones del esquema en 6 particiones hace que solamentequeden 2 particiones libres para ejecutar el resto de tareas, mientras que en elesquema de 4 particiones aún quedarían 3 libres, y de ahí el bajo rendimientoen la ejecución en 6 particiones para este lote.

127


El lote L7 corresponde a la simulación de 12 ejecuciones de JPEG en unaversión de síntesis donde algunas tareas se desdoblan (JPEG paralelo). Lasíntesis se realizó para una Virtex-2 XCV2P30, de tamaño mucho menor queuna Virtex-5, y aún así el resultado es un conjunto donde el 100 % de tareasson pequeñas. Estas 12 ejecuciones solapadas de JPEG paralelo dan un buenresultado tanto con un esquema de 4 particiones como con uno de 6 particionesya que su frecuencia de llegada es muy baja. El tamaño medio de las tareas,3,65%, es menos de la mitad del tamaño máximo de las tareas pequeñas, 10%,y de ahí los exageradamente altos valores obtenidos para Dp que indican queen caso de aumentar la frecuencia de llegada de tareas sería imprescindibleaumentar el número de particiones a un número mayor incluso que 6.

Por tanto, hemos comprobado de forma experimental que las distribucionesen particiones obtenidas son adecuadas para una mayoría de distribuciones detareas.

4.5. Observación del sistema en tiempo real

4.5.1. Variación de Dp en tiempo real

Los resultados obtenidos hasta el momento han sido realizados a partirde cálculos teóricos sobre un conjunto de tareas que se conoce de antemano.Cuando el valor de Dp se calcule en tiempo real, mostrará variaciones respectoa este cálculo teórico debido a que estaremos tomando subconjuntos del lotesobre el que se realiza el cálculo. En las tablas 4.5 y 4.6 podemos tambiénobservar que cuando las tareas de un lote no se ajustan a las condiciones

128

Observación del sistema en tiempo real 4.5

ideales (los tamaños de las tareas tendrían que ser exactamente iguales a lostamaños de las particiones para que no se desaprovechara área de FPGA) losvalores de Dp para el lote completo se desvían de los teóricos.

Mostraremos un ejemplo de la variación de Dp cuando se calcula en tiemporeal y pasaremos después a analizar resultados empíricos con diferentes tiposde distribuciones que nos indicarán la variación en tiempo real de Dp y de ellosobtendremos las pautas para determinar las condiciones en que el algoritmode la UAD deberá decidir los cambios de particiones.

4.5.2. Ejemplo de variación de Dp en tiempo real

Tomaremos el fragmento del lote de tareas que componen el lote ideal L1

mostrado en la tabla 4.1. Este lote, examinado en su totalidad, correspondeal caso en que Dp = 1. Sin embargo al analizar los valores calculados para Dp

en tiempo real, observamos que oscilan entre 0, 91 y 1, 11, es decir aproxima-damente un 10 % del valor teórico para el lote. La �gura 4.8 nos muestra unagrá�ca con los valores calculados a lo largo de la ejecución de este lote, parauna distribución en 4 particiones y con una ventana de 16 tareas (por ello elprimer valor de Dp se obtiene en u.t = 24).

La tabla 4.7 nos muestra las 10 primeras tareas de L1. El valor de Dp paraeste subconjunto de tareas es Dp = 1, 09. Veremos sin embargo que en tiemporeal este valor varía por encima y por debajo de su valor teórico, dependiendodel subconjunto de tareas presentes en la ventana de tareas en el momento derealizar el cálculo.

Vamos a ir calculando el valor de Dp como lo haría la UAD, tomando las m

129


Figura 4.8: Oscilaciones del valor de Dp en tiempo real I

últimas tareas que han llegado al sistema. Como se trata de un ejemplo sencillo,cogeremos un número de tareas igual al número de particiones, es decir, cuatro.En la �gura 4.9 se ve que estas 4 primeras tareas son exactamente una grande,dos medianas y una pequeña de tamaños iguales a las particiones existentes,y que por tanto la primera vez que se calcula Dp se obtiene el valor 1.

Figura 4.9: Dp para la primera ventana de tareas

Al desplazar la ventana de tareas, sale del cálculo la tarea T1 y entra la T5,dando de nuevo como resultado un Dp = 1. Para la tercera ventana volvemosa obtener un valor Dp = 1 ya que de nuevo tenemos un subconjunto de tareas

130


Tabla 4.7: Parte de un lote de tareas ideal

Tarea wi hi tlli teji tmaxi

T1 35 35 1 5 11T2 15 35 1 6 13T3 35 15 1 8 17T4 15 15 1 7 15T5 35 35 6 10 26T6 15 35 7 5 17T7 15 15 8 5 18T8 35 15 9 9 27T9 15 35 12 6 24T10 15 15 13 12 37

que representa la distribución Lm de forma perfecta.Puesto que el orden de llegada de tareas no tiene por qué ser grande-

mediana-mediana-pequeña, lo que sucede es que llega un momento en que aldesplazar la ventana de tareas, el grupo con el que se realiza el cálculo puedeno corresponder exactamente a la distribución Lm. Esto sucede al tomar lacuarta ventana de tareas, como muestra la �gura 4.10.

Figura 4.10: Dp para la cuarta ventana de tareas

Al salir la tarea T4 de la ventana y entrar la T8 volvemos a tener una131


distribución perfecta de Lm y de nuevo obtenemos un Dp = 1. En la siguienteventana volvemos sin embargo a obtener un valor de Dp = 1, 39. Al realizarel último cálculo de Dp para este fragmento del lote ideal L1 obtenemos denuevo un valor de Dp alejado del valor 1, como muestra la �gura 4.11.

Figura 4.11: Dp para la última ventana de tareas

Este sencillo ejemplo nos muestra dos aspectos importantes que hay quetener en cuenta a la hora de determinar cambios en las particiones a partir delvalor obtenido para el cálculo de Dp:

1. Oscilación del valor de Dp: el parámetro Dp obtenido en tiempo realoscila por encima y por debajo del valor real de Dp para un conjunto detareas. Es necesario determinar empíricamente, a partir de distribucionesde tareas conocidas, cuál es el margen de variación de Dp por encima de1 que hace necesario un aumento en el número de particiones. De formaanáloga, aunque no simétrica, es necesario también determinar de maneraempírica el valor real de Dp por debajo de 1 que indica la necesidad dedisminuir el número de particiones.

2. Cambio en la distribución: para determinar un cambio en las parti-132


ciones no es su�ciente con que se dé la condición Dp > 1 o Dp < 1 unaúnica vez, ya que esto podría deberse al orden en que llegan las tareas quese están considerando. Podríamos decir, a una casualidad. Experimental-mente hemos comprobado que al menos debemos esperar tres veces a queel valor de Dp calculado en tiempo real muestre la misma tendencia dedesviación para realizar el cambio en las particiones, ya que si no fueraasí, las oscilaciones en el valor de Dp calculado en tiempo real llevaríana un frecuente cambio de particiones innecesario.

Si al examinar un conjunto de tareas se observa un desequilibrio y al saliruna tarea del cálculo y entrar otra nueva observamos que esta tendenciano se repite, y que no se vuelve a repetir en las siguientes dos veces quelo realicemos, no parece que la tendencia observada corresponda a unverdadero cambio en la distribución sino a una desviación del mismo (losconjuntos de tareas que llegan al sistema no tienen por qué ajustarse aninguna de las distribuciones de forma exacta).

El hecho de que en un subconjunto pequeño de tareas se observe que nose está aprovechando adecuadamente el área de dispositivo (o que hay unexceso de área solicitada) no tiene mayor importancia si la situación no serepite dando lugar a retrasos en la ejecución de las siguientes tareas. Deahí la importancia de incluir un criterio acumulativo para la condiciónde desequilibrio, que se pondrá de mani�esto si las situaciones se reiteranen ventanas de tiempo contiguas.

133


4.5.3. Valores críticos de Dp

A continuación presentamos las pruebas realizadas para determinar los va-lores empíricos de Dp que obligan al cambio en las particiones. Ya hemos vistoque en caso del lote ideal Dp oscila entre los valores 0, 9 y 1, 11. Es de esperarque para una distribución de medianas no ideal, Dp presente mayores osci-laciones aún. En la tabla 4.8 los lotes L1, L2 y L3 deberían ejecutarse en 4particiones (ideal, Lm y Lp con tareas de tamaño cercano al 50 % de la FPGA).Se ha calculado Dp con una ventana de 16 tareas. Los lotes están compuestospor conjuntos de 65 tareas.

Tabla 4.8: Distribuciones y variación de Dp en tiempo real I

Lote α a ( %A) Dp teor. Max Dp t real Min Dp t realL1 1 25,00 1 1,11 0,91L2 0,90 23,23 1,11 1,31 0,93L3 0,79 19,77 1,26 1,77 1,09L4 0,76 26,93 0,93 1,39 0,85L5 0,87 22,00 1,13 1,52 0,87

Podemos observar que ningún valor de Dp rebasa el 1,8 ni es inferior a 0,8.Se pone de mani�esto también la ya mencionada falta de simetría en cuanto alimpacto de la presencia de tareas pequeñas y grandes tanto en el rendimientodel algoritmo como de los cálculos en tiempo real.

Hemos incluido el lote L4 que corresponde a una distribución tipo plana,donde la tercera parte de las tareas son de cada uno de los tamaños. Obser-vamos que este lote es el que presenta una mayor desviación entre el máximovalor de Dp y el mínimo, ya que la presencia de tareas grandes es más elevadaque en una distribución de medianas, como también lo es la de pequeñas y

134


esto hace que el cálculo de Dp en tiempo real oscile más que en distribucionesdonde hay una clara predominancia de alguno de los tipos de tareas.

Ahora mostraremos los resultados obtenidos al ejecutar lotes de tareas quecorresponden a distribuciones cuya ejecución con una distribución en 4 parti-ciones es peor que si se ejecutan con 3 o con 6 particiones. Mostraremos losresultados de los valores máximos y mínimos de Dp a lo largo de su ejecucióntanto con 4 particiones (4P) como con 6 (6P) o con 3 (3P) y una grá�ca dondese muestre la evolución temporal de este parámetro. Empezaremos analizandolos resultados para lotes de tareas donde es necesario pasar a 3 particiones,tabla 4.9. Las primeras columnas nos muestran las características de los lotesy después el valor teórico de Dp para 4 particiones y a continuación los valoresmáximo y mínimo obtenidos en tiempo real. Las últimas tres columnas mues-tran el valor teórico de Dp para cada lote con 3 particiones y su variaciones entiempo real.

Tabla 4.9: Distribuciones y variación de Dp en tiempo real II

Lote α a ( %A) 4P Máx Min 3P Máx MinL1 0,70 29,73 0,84 0,89 0,63 1,12 1,34 0,89L2 0,69 28,75 0,87 1,16 0,59 1,16 1,55 0,90L3 0,87 22,00 1,13 1,52 0,87 1,51 1,99 1,27

En estos ejemplos podemos observar que para 4P tenemos un valor teóri-co bastante bajo e inferior a 0, 9, lo que se traduce en tiempo real en valoresmínimos muy bajos. Sin embargo los valores de Dp obtenidos para estos mis-mos lotes de tareas con una distribución en 3P se ajustan a los márgenes devariación que hemos obtenido para lotes de tareas medianas cuando se están

135


ejecutando en 4P (inferiores a 1, 8 y por encima de 0, 8).La �gura 4.12 muestra las variaciones del valor de Dp en tiempo real para

L2. Hemos tomado este lote para mostrar la grá�ca porque es el que mayorirregularidad presenta en los valores máximo y mínimo.

Figura 4.12: Oscilaciones del valor de Dp en tiempo real II

Observamos que con la ejecución en 3P, el valor de Dp oscila en torno alvalor de 1, excepto en un momento dado en que hay una secuencia de tareas demenor tamaño que llegan cercanas en el tiempo y sube hasta el valor 1, 55. Elvalor calculado en tiempo real para la ejecución en 3P corresponde a la líneasuperior de la grá�ca 4.12.

La grá�ca de Dp para 4P, la línea inferior de la grá�ca 4.12, se mantieneclaramente por debajo de 1 y en numerosas ocasiones baja por debajo de0, 8. Uniendo estas observaciones a las realizadas con los lotes de tareas detipo Lm examinadas anteriormente, podemos deducir que el límite Dp < 1

medido en tiempo real se traducirá en Dp ≤ 0, 8 tres veces seguidas, para evitar136


que el impacto de las oscilaciones del valor de Dp lleven a tomar decisionesprecipitadas y asegurar que se trata de una tendencia real del conjunto detareas y no de un momento particular de la ejecución en que varias tareasgrandes han llegado bastante cercanas en el tiempo. En la grá�ca podemosobservar también que Dp para el caso 4P empieza tomando valores bajos y vadisminuyendo progresivamente, llegando a estar por debajo del valor 0, 8 enalguna ocasión y mostrando una tendencia a la baja hasta que realmente sepuede con�rmar que se trata de una distribución que no es adecuada para 4P.

Los valores de Dp en tiempo real para una distribución en particiones ade-cuada nunca son inferiores a 0, 8. Su valor máximo es 1, 52, mostrando la mismatendencia que habíamos visto para lotes de tareas de tipo Lm donde en ningúncaso el valor de Dp superaba el valor de 1, 8.

Sin embargo, para una distribución en particiones no adecuada, los valoresde Dp claramente oscilan por encima del valor 1 llegando a superar el valor1, 8 en numerosas ocasiones y dando un máximo valor de Dp muy alto, 1, 99,como se puede ver en la tabla 4.9.

Con los resultados obtenidos hasta el momento podríamos concluir que:

1. La situación Dp > 1 se alcanza en tiempo real cuando la distribucióngenera tres veces seguidas un valor de Dp ≥ 1, 8, condición que indica lanecesidad de aumentar el número de particiones, ya sea de 3 a 4 o de 4

a 6.

2. La situación Dp < 1 se alcanza en tiempo real cuando la distribucióngenera tres veces seguidas un valor de Dp ≤ 0, 8, indicando la necesidadde disminuir el número de particiones, ya sea de 4 a 3 o de 6 a 4.

137


Para la con�rmación de�nitiva de estas conclusiones es necesario realizarpruebas comparativas de la oscilación de los valores de Dp en 4P y en 6P. Acontinuación presentamos una tabla con resultados de ejecutar lotes de tareasde tipo Lpp (L1 y L2) y de tipo Lm (L3) en 4 y 6 particiones y los resultadosen tiempo real obtenidos para ellas. La tabla 4.10 muestra las característicasde los lotes junto a los valores teóricos obtenidos para 4P y sus variaciones entiempo real y a continuación el valor teórico de Dp para 6P y sus variacionesen tiempo real.

Tabla 4.10: Distribuciones y variación de Dp en tiempo real IV

Lote α a ( %A) 4P Máx Min 6P Máx MinL1 0,62 14,00 1,78 2,22 1,56 1,19 1,45 1,06L2 0,53 14,50 1,72 2,00 1,55 1,15 1,27 1,03L3 0,90 23,23 1,11 1,31 0,93 0,74 0,86 0,61

Los dos primeros lotes corresponden a distribuciones donde las tareas sonbastante pequeñas y su ejecución es más adecuada en 6P. Vemos que si seejecutan en 4P la UAD determinaría un cambio a 6P. Asimismo, vemos quecuando este tipo de distribuciones se estuviera ejecutando en 6P la UAD nuncadeterminaría un cambio en las particiones.

El último lote, L3 corresponde a una distribución tipo Lm. Si se estuvieraejecutando en 4P y con los criterios obtenidos para el cambio en las particio-nes, nunca cambiaría, lo cual es correcto. Si una distribución de este tipo seestuviera ejecutando en 6P la UAD determinaría el cambio de 6P a 4P.

La �gura 4.13 muestra los valores de Dp obtenidos para 4P con un lote Lg,un lote Lm y un lote Lpp en tiempo real y los valores de Dp en relación a los

138


límites propuestos para los cambios en las particiones.

Figura 4.13: Límites del valor de Dp en tiempo real para determinar cambios

La tabla 4.11 resume el conjunto de cambios a realizar en función de losvalores calculados para Dp en tiempo real.

Tabla 4.11: Distribuciones y variación de Dp en tiempo real

Dp 3P 4P 6P≤ 0, 8 - 3P 4P≥ 1, 8 4P 6P -

4.5.4. Ventana de observación del sistema

Todas las pruebas experimentales mostradas hasta ahora y los resultadospresentados en el capítulo 6 se han realizado con una ventana de 16 tareas. Enesta sección explicaremos por qué se utiliza una ventana de tareas en lugar deuna temporal y por qué se ha utilizado ese número de tareas.

139


Al tratarse de un sistema donde no se sabe cuándo llegará la siguientetarea ni cómo será ésta, es muy difícil de�nir el intervalo de tiempo durante elcual debe observarse el sistema para sacar conclusiones acertadas acerca de lascaracterísticas de la distribución de tareas. Si la frecuencia de llegada de tareases baja, tendremos un conjunto muy pequeño de tareas para tomar decisionesy en un caso así una sola tarea tiene mucho peso en el valor de Dp calculado.Por el contrario, si la frecuencia de llegada de tareas es alta es posible queestemos tardando excesivo tiempo en detectar la necesidad de un cambio.

Por estas razones hemos optado por observar el sistema en tiempo real através de una ventana de tareas deslizante de manera que la muestra obtenidapara analizar las características de la carga de trabajo contenga siempre elmismo número de tareas y sea igualmente signi�cativa en todas las posiblescircunstancias. Una FIFO de cierto tamaño almacenará los datos de cada nuevatarea que llega al sistema y su contenido se utilizará para calcular α, a y tej.

Si lo que queremos es observar si un grupo de tareas se parece a alguna delas distribuciones de�nidas, con el propósito de cambiar las particiones si éstasno se ajustan a la carga de trabajo, parece lógico que el número de tareas aobservar sea múltiplo del número de particiones.

Esto nos lleva a que m, el número de tareas almacenadas en la FIFO serámúltiplo del número de particiones:

m = k · P (4.16)

Si lo que queremos es que el sistema actúe de forma dinámica pero noprecipitada, tendremos que elegir un valor de k que no sea excesivamente

140


pequeño ni grande. Descartamos k = 1 y k = 2 ya que darían un númeromuy bajo de tareas a observar (obtendríamos valores entre 3 y 12 tareas).

Así que podemos ver qué sucede si tomamos un valor k = 3. Para el caso deP = 4 estaríamos observando 12 tareas. Para P = 3 solamente 9 tareas. ParaP = 6 ya serían 18. Con k = 4 estaremos examinando las últimas 12, 16 o 24tareas que han llegado al sistema. Este número empieza a parecer razonable ypuede servirnos como consideración inicial.

Un k = 5 daría números de 15, 20 y 30, lo que en algunos casos puederesultar excesivo, especialmente si estamos trabajando con 6 particiones, delas cuales 4 son muy pequeñas, y empiezan a llegar un número signi�cativo detareas grandes, que podrían ocasionar serios problemas de rendimiento en elsistema.

De momento nos quedaremos con k = 4 como un número razonable parade�nir el tamaño de la ventana de tareas utilizada para observar el sistema enfunción del número de particiones que se estén utilizando.

A continuación vamos a presentar una serie de pruebas experimentalesrealizadas para con�rmar la intuición de que utilizar un valor de k = 4 esacertada. Para ello recurriremos a varios lotes de tareas que corresponden adiferentes tipos de distribuciones y examinaremos los valores de Dp obtenidosen tiempo real con diferentes valores de k en relación al valor teórico de Dp parael lote completo y a partir de ahí comentaremos y justi�caremos las decisionestomadas para la implementación de la FIFO en la UAD.

La �gura 4.14 nos muestra los valores de Dp obtenidos para k = 3, k = 4

y k = 5 para un lote de tareas tipo Lm. Para este lote completo obtenemos unDp = 1, 11. Debido al diferente número de tareas almacenadas en la FIFO para

141


realizar los cálculos, la UAD empieza a obtener valores para Dp en distintasunidades de tiempo. Hemos representado los valores obtenidos a partir de launidad en tiempo en la que Dp empieza a calcularse para todos los valores dek.

Figura 4.14: Variación de Dp en función de k I

Esta �gura nos muestra que cuanto más alto es el valor de k menor es laoscilación de los valores de Dp medidos en tiempo real con respecto al valorteórico del lote completo. Para el valor de k = 3 la desviación en algunosmomentos es excesiva y dará un valor de Dp muy distorsionado. Los valoresde Dp obtenidos para k = 5 son los que más se ajustan al valor teórico (y siaumentáramos el valor de k se ajustarían aún más). También podemos observarque para k = 4 los valores obtenidos no son mucho peores que los obtenidospara k = 5 y sí bastante mejores que los obtenidos para k = 3. Además, ladesviación del valor ideal no es simétrica y es mayor cuando la oscilación deDp esté por encima del valor teórico que cuando esté por debajo.

La tabla 4.12 muestra los resultados obtenidos para el lote tipo Lm del quehemos presentado el grá�co. Para este lote se han realizado las ejecuciones con

142


una distribución en 4 particiones, por lo que los tamaños de las ventanas sonde 12, 16 y 20 tareas respectivamente. La última �la de la tabla nos muestra lamáxima desviación del valor de Dp obtenido en tiempo real del valor teórico,en porcentaje. Vemos que la diferencia entre k = 4 y k = 5 es muy pequeña,mientras que la diferencia de pasar de un k = 3 a k = 4 sí que es considerable.

Tabla 4.12: Variación de Dp con k, Lm

Lm k = 3 k = 4 k = 5Máx Dp 1,44 1,31 1,30Dp téor. 1,11 1,11 1,11Min Dp 0,90 0,93 0,97

Desv ( %) 29,73 18,01 17,11

La tabla 4.13 muestra los resultados obtenidos para el lote tipo Lg, dondepodemos apreciar la misma tendencia respecto al valor de Dp obtenido entiempo real con diferentes valores de k. Como es un lote de tareas de tipogrande, los tamaños de las ventanas para estos mismos valores de k son ahora de9, 12 y 15 tareas, ya que se han ejecutado en una distribución en 3 particiones.

Tabla 4.13: Variación de Dp con k, Lg

Lg k = 3 k = 4 k = 5Máx Dp 1,68 1,54 1,36Dp téor. 1,12 1,12 1,12Min Dp 0,75 0,83 0,86

Desv ( %) 50,00 37,50 21,43

En este caso la desviación máxima es muy alta ya que el número de tareasen la ventana de tareas es bastante menor que en los casos estudiados para ellote de tipo Lm, llegando a ser de 15 tareas el máximo.

143


Por último realizamos el mismo experimento con un lote de tareas tipoLpp ejecutado en una distribución en 6 particiones. La tabla 4.14 muestra losresultados obtenidos para el lote tipo Lpp, donde podemos apreciar la mismatendencia respecto al valor de Dp obtenido en tiempo real con diferentes valoresde k. Como es un lote de tareas tipo pequeño, los tamaños de las ventanas paraestos mismos valores de k son ahora de 18, 24 y 30 tareas. Vemos que hay unagran diferencia entre el número de tareas que se está utilizando para tomardecisiones con cada tipo de distribución diferente.

Tabla 4.14: Variación de Dp con k, Lpp

Lpp k = 3 k = 4 k = 5Máx Dp 1,38 1,37 1,34Dp téor. 1,19 1,19 1,19Min Dp 1,08 1,09 1,12

Desv ( %) 15,96 15,13 12,60

El paso de k = 3 a k = 4 en este ejemplo no da una mejora signi�cativa encuanto a disminución del error y sin embargo el aumento de k = 4 a k = 5 síque lo hace.

Estos experimentos ponen también de mani�esto que utilizar el mismo valorde k para todas las distribuciones en particiones no parece una buena ideaya que supone una clara desventaja a la hora de tomar decisiones acertadasa las distribuciones que trabajan con un menor número de particiones. Unadi�cultad añadida es el hecho de que el tamaño de la FIFO debería variartambién cuando se haga un cambio en la distribución en particiones.

Por todo ello consideramos acertada la realización de estas pruebas ya queponen de mani�esto lo adecuado de utilizar una ventana de tareas de tamaño

144


�jo y que considere un número de tareas su�ciente para no cometer un errorexcesivo y su�cientemente pequeño para que la toma de decisiones no se aplacedemasiado.

Para poder decidir el número adecuado de tareas que deben formar parte dela ventana de tareas presentamos a continuación la tabla 4.15 que resume losresultados anteriores y que presenta el error cometido en función del númerode tareas en la ventana.

Tabla 4.15: Desviación de Dp para diferentes tamaños de ventana de tareas

9 12 12 15 16 18 20 24 30Desv(%) 50,00 37,50 29,73 21,43 18,01 17,11 15,96 15,13 12,60

En esta tabla podemos observar que si el objetivo es cometer el menor errorposible obviamente tendríamos que coger un número de tareas lo mayor posible.Sin embargo hay que tener en cuenta que son datos tomados en tiempo realy que no es conveniente tampoco esperar demasiado a detectar una situaciónde no adecuación de la distribución de particiones ya que podría empezara rechazarse un número elevado de tareas por el simple motivo de no estarrealizando una buena gestión del área del dispositivo.

Para un número de tareas razonable, de 16, vemos que el error cometidoestá en torno al 20 %. Vemos también que para reducir sensiblemente el errorhabría que pasar a examinar prácticamente el doble de tareas. Con 30 tareasen la ventana podríamos reducirlo a aproximadamente el 12 %. También vemosque el mismo número de tareas puede dar un error en la apreciación de Dp

bastante diferente dependiento del lote y tipo de tareas que lo forman (casode 12 tareas que se ha repetido con P = 4 y k = 3 y con P = 3 y k = 4).

145


Lo que sí queda claro es que tomar menos de 16 tareas no parece muyacertado porque el error cometido será grande. Por encima de 16 tareas lasmejoras que podrían resultar signi�cativas serían pasar a 20 tareas o a 30 oalgún número intermedio entre 16 y 30.

Si estuviéramos trabajando con 3 particiones y manejamos una ventana de20 tareas la situación podría ser muy mala. Por un lado, el algoritmo disponede menos opciones para ubicar tareas cuantas menos particiones haya, por loque si está trabajando con una distribución en 3P y empiezan a llegar tareaspequeñas y a mayor frecuencia tiene pocas opciones de gestionarlas y prontoempezará a rechazarlas. Además si la ventana de tareas es grande, como elpeso del área de las tareas grandes es mucho mayor que el de las pequeñasen la media, Dp tardará mucho en subir su valor y el retraso en la toma dedecisiones será muy perjudicial para el algoritmo.

En el estudio teórico de las distribuciones vimos que para que el área mediade una distribución se acerque al tamaño de las tareas pequeñas es necesarioque haya un 80 % de tareas pequeñas en el conjunto de tareas. Es decir, queen la ventana de tareas no se apreciaría la presencia de las tareas pequeñashasta que no hubiera cerca de 16. Si hay 3 particiones solamente se podránejecutar 3 tareas simultáneamente. Esto quiere decir que de estas 16 tareasque hay en la ventana probablemente se habrán rechazado casi la mitad deellas (supongamos que 3 se están ejecutando y hay 2 tareas esperando en cadacola porque sus tiempos máximos se lo permiten; esto signi�caría que de estas16 ya se han rechazado 7 para cuando Dp supere el valor de 1, 8 por primeravez). Si además consideramos que la diferencia en el error cometido es pocosigni�cativa (en nuestros ejemplos sería poco más de 1 %), no merece la pena

146


utilizar un número tan elevado de tareas en la ventana.Si la ventana es de 16 tareas, tendrá que haber cerca de 12 para que Dp

supere el valor que decide un aumento en las particiones por primera vez.Realizando los mismos cálculos anteriores, probablemente se habrán rechazadola cuarta parte de las tareas pequeñas, que en este caso son 3 tareas.

Existe una ventaja adicional para utilizar una ventana de 16 tareas, que estárelacionada con la implementación de la UAD. Para determinar Dp tenemosque calcular el área media de las tareas que están en la ventana. Este cálculo sesimpli�ca enormemente si utilizamos un número de tareas que sea una potenciade 2 ya que la división por 16 se puede realizar en hardware con un sencillodesplazamiento de bits. Lo mismo sucederá con el cálculo del tiempo medio deejecución y de cualquier otro valor medio que se quisiera calcular (por ejemploel de los tiempos máximos de las tareas).

Por todos los motivos expuestos, consideramos que una ventana de tareasde tamaño �jo que contenga los datos de las últimas 16 tareas que han llegadoal sistema proporciona una información su�cientemente �able como para tomardecisiones acertadas con la agilidad necesaria, además de resultar una opciónque puede facilitar mucho la implementación de la UAD (o parte de ella) enhardware.

Por último presentamos la tabla 4.16 con las desviaciones obtenidas para elparámetro α en tiempo real, a partir de los mismos casos para los que hemospresentado las variaciones de Dp.

Podemos observar que el valor del parámetro α presenta unas variacionesen tiempo real mucho mayores que Dp respecto a su valor teórico para el lotecompleto. Esto es debido a que la llegada de tareas no se realiza de forma

147


Tabla 4.16: Desviación de α para diferentes tamaños de la venta de tareas

9 12 12 15 16 18 20 24 30Máx. 1,23 1,17 1,25 1,08 1,19 0,91 1,18 0,91 0,93Teórico 0,70 0,70 0,90 0,70 0,90 0,62 0,90 0,62 0,62Mín. 0,62 0,63 0,62 0,63 0,70 0,58 0,76 0,58 0,57

Desv(%) 75,71 67,14 38,88 54,28 32,22 46,77 32,22 46,77 50,00

uniforme y hay intervalos de tiempo en que las tareas llegan muy seguidas(incluso en grupos de 3 o 4 tareas) y otros en que se distancian más. Estohace que el valor �uctúe mucho más que el Dp con el tamaño de la ventana detareas.

Vemos que la máxima desviación es por exceso, es decir, en valores porencima del teórico, y que el límite inferior para estos lotes nunca está por debajodel α = 0, 5 que tomamos como referencia para un sistema infrautilizado (locual es correcto para todos ellos).

Lo que sucedería si en algún momento α tomara un valor inferior a 0, 5

es que Dp no se calcularía en ese momento. Si α se mantuviera por debajode 0, 5, Dp seguiría sin calcularse, pero esto no sería un problema ya que alestar llegando pocas tareas al sistema, la distribución en particiones que seesté utilizando no es crucial para el rendimiento del algoritmo, ya que disponede la habilidad de unir particiones cuando sea necesario y podría plani�carel total del conjunto incluso con una distribución en particiones no adecuada,como se vió en los resultados de la sección 4.4.3.

Por el contrario, si α vuelve a subir, el valor de Dp se volverá a calculary el sistema no pierde información acerca de las características del conjuntode tareas que han llegado recientemente (cada nueva tarea entrante se guarda

148


en la FIFO, independientemente del valor de α). Si esto sucediera, podríaretrasarse la toma de una decisión, pero como vemos no sería en situacionesdonde la carga de trabajo es alta y prácticamente no daría lugar a pérdidas enel rendimiento.

En la �gura 4.15 mostramos la ejecución correspondiente a un lote de ta-reas con un valor global de α = 0, 52. Se trata de un lote de tipo Lg que seestá ejecutando en 4P. La UAD no tendría ningún problema con este tipo deconjuntos de tareas de baja frecuencia de llegada para detectar la necesidadde un cambio en las particiones ya que como vemos en la �gura, el valor deα (línea inferior de la grá�ca) solamente se encuentra por debajo de 0,5 dosveces a lo largo de toda la ejecución. Se dejaría de calcular Dp en t = 41 yt = 42 pero esto no impide detectar un poco más adelante que Dp está rozandoel valor límite de 0,8, ni realizar el cambio de particiones cuando Dp baja pordebajo de 0,8 tres veces seguidas en t = 105.

De hecho, el valor teórico α < 0, 5 se convierte en α < 0, 35 en tiempo real,si suponemos una desviación por exceso del cálculo de su valor del 30 % (de latabla 4.16, para una ventana de 16 tareas). Es decir, que la UAD solamenteignorará la no adecuación de la distribución en particiones en situaciones donderealmente la carga de trabajo sea muy inferior a la capacidad de la FPGA.

Por todas las razones expuestas, hemos realizado todas las pruebas experi-mentales de la UAD con una ventana de 16 tareas y los resultados obtenidosson buenos.

149


Figura 4.15: Variación de α y Dp, en un sistema en el límite de infrautilización

4.6. Conclusiones

Resumimos aquí las conclusiones a las que hemos llegado con el estudioanterior y que determinan la manera en que se implementará la UAD:

1. Tipos de distribuciones básicas: con 4 distribuciones básicas (prác-ticamente todas las tareas pequeñas, tareas pequeñas, tareas medianasy tareas grandes) es su�ciente para describir un amplio rango de situa-ciones posibles en el sistema.

2. Distribuciones en particiones: utilizando 3 tipos de distribucionesen particiones con 3, 4 y 6 particiones podemos asegurar la correctaejecución de prácticamente la totalidad de posibles cargas de trabajo.

3. Parámetros de medida: con dos parámetros fácilmente medibles entiempo real, α y Dp, podemos detectar las situaciones en que será nece-sario cambiar el número de particiones. El parámetro Dp solamente secalculará cuando α ≥ 0, 5 y el cambio de particiones se realizará conformea la tabla 4.17.

150

Conclusiones 4.6

Tabla 4.17: Cambios de particiones en función de Dp

Dp 3P 4P 6P≤ 0, 8 - 3P 4P≥ 1, 8 4P 6P -

4. Ventana de tareas: se utilizará una ventana de 16 tareas para realizarla observación del sistema.

En el siguiente capítulo proporcionaremos detalles acerca del procedimientopara llevar a cabo el cambio en las particiones con el mejor rendimiento posible,seguido de un ejemplo detallado del funcionamiento del algoritmo de la UAD.

151

Capítulo 5

Implementación de la Adaptación

Dinámica

5.1. Introducción

Para completar la descripción del funcionamiento de la UAD nos quedaexplicar en detalle cómo se hace efectivo un cambio en las particiones. Elcambio en las particiones se realiza en un momento dado en que hay unaserie de tareas ejecutándose y otras tareas esperando en las colas, asignadasa particiones que tienen un determinado tamaño y se detecta la necesidad decambiar el tamaño y número de las particiones. Tenemos que analizar cuáles la mejor manera de realizar este cambio en las particiones afectando en lamenor medida posible al conjunto de tareas ya plani�cadas.

Asimismo analizaremos en detalle cuáles son los valores de los parámetrosque manejarán la UAD, la UPT y la ULT cuando se determine un cambio enlas particiones.

153

Capítulo 5. Implementación de la Adaptación Dinámica

Lo que físicamente determina las particiones de la FPGA son los accesosal bus, es decir, los lugares donde se con�guran las bus macros, que deberáncoincidir con los lugares donde se ubican las conexiones al bus en las tareas enel momento de sintetizarlas. Esto quiere decir que el cambio en las particionesimplicaría una reubicación de las bus macros en la FPGA, acción que conlleva-ría la recon�guración del bus en la FPGA. Es necesario también el aumento odisminución del número de colas que maneja la UPT, así como la actualizaciónde las variables que almacenen los tamaños de las particiones.

En primer lugar examinaremos las ubicaciones de las bus macros para cadadistribución de particiones y la posibilidad de con�gurarlas todas desde unprincipio para evitar la recon�guración del bus cada vez que haya un cambiode particiones. Después analizaremos cómo se puede realizar un cambio en ladistribución de las particiones sin afectar a las tareas que ya se están ejecu-tando y retrasando en la menor medida posible la ejecución de las tareas yaplani�cadas en las colas correspondientes a la anterior distribución.

5.2. De�nición de parámetros

La �gura 5.1 muestra los valores de los parámetros para cada una de lasdistribuciones en particiones.

1. Cuando el cambio de particiones sea de P a P ′ = 4, w′p = 0, 30 · W y

h′p = 0, 30 ·H.

2. Para el cambio a P ′ = 3 particiones, w′p = 0, 5 ·W y h′p = 0, 5 ·H.

3. Para el cambio a 6 particiones, P ′ = 6 junto con w′p = 0, 25 · W , h′p =

154

De�nición de parámetros 5.2

Figura 5.1: Distribuciones en particiones utilizadas

0, 5 · H y w′pp = 0, 5 ·W para que se realice la división en 6 particiones

de forma correcta.

Respecto a la ubicación de las macros de acceso al bus de comunicacionesde cada partición, mPi

, tendremos un número de accesos al bus igual a P ycon localizaciones que dependen de los valores que toman wp, hp y wpp paracada tipo de distribución.

Si el número de particiones es P , solamente se utilizarán los accesos al busmP0 a mPP−1

. La partición menor siempre es la P0 en todas las distribucionesposibles y la mayor la que tenga mayor índice. La numeración de las particionesse ha elegido de manera que coincida el mayor número posible de bus macros.En el caso de utilizar 3 particiones hay un bus macro que no se usa, mientrasque en la caso de 6 particiones deben aparecer dos bus macros más y un soloparámetro que indique la localización de las nuevas bus macros (estarán a lamisma distancia del origen de coordenadas pero una de ellas en la parte inferiorde la FPGA y la otra en la superior) a la que hemos llamado wpp.

155


5.2.1. Cambio de particiones

Examinaremos ahora la manera en que se puede ejecutar el cambio en lasparticiones. Hemos tenido en cuenta dos aspectos:

1. El coste en tiempo de esperar a que terminen de ejecutarse

todas las tareas que están en la FPGA en el momento de decidirel cambio puede llegar a ser muy alto y variable, ya que depende delos tiempos de ejecución de las tareas que se están ejecutando. Ya quesolamente se plantean los cambios en las particiones cuando tenemos unaa�uencia alta de tareas al sistema, podría dar lugar al rechazo de unagran cantidad de tareas.

2. El coste en tiempo de recon�gurar el bus de comunicaciones

también es alto y por las mismas razones expuestas podría dar lugar alrechazo de una gran número de tareas.

Por ello hemos buscado una manera de realizar el cambio en las particionesque evite estas dos situaciones, lo cual no es complicado ya que disponemos deinformación acerca de cómo se solapan las particiones de la antigua distribucióncon la nueva y en el momento de decidir el cambio podríamos mover las tareasque estén esperando en las colas a las nuevas colas y conforme las tareas queestán ejecutándose en la FPGA vayan terminando su ejecución, ir enviandotareas de las colas a ejecutar en las partes de la FPGA que han quedado libresconforme al nuevo mapa de particiones de la FPGA.

Asimismo, evitar la recon�guración del bus de comunicaciones cada vezque se hace un cambio en las particiones es fácil: se pueden con�gurar todas

156


las bus macros necesarias para todos los casos simultáneamente en la FPGAdesde el principio. De esta forma todas las bus macros estarán disponibles ysolamente se utilizarán las que en cada momento se necesiten.

5.2.2. Posiciones de las bus macros

A continuación mostramos la �gura 5.2 con las bus macros necesarias paralas particiones en cada una de las distribuciones: 4P, 3P y 6P. Están numeradasde izquierda a derecha empezando por la esquina inferior izquierda.

Figura 5.2: Ubicación de las bus macros para las distintas distribuciones

Observamos que algunas bus macros son compartidas en las tres distri-buciones posibles (bm1 y bm5) y las otras son especí�cas para alguna de lasdistribuciones. Las líneas discontinuas rojas indican la división de la FPGApara 4 particiones. Las líneas lila discontinuas nos muestran la división para 3

particiones, y como son comunes a 3P y 6P, son del mismo color que las líneasque indican al división en 6P (las lila tanto continuas como discontinuas).

La �gura 5.3 une la información desglosada en la �gura 5.2 y nos muestra lacon�guración del bus que se puede realizar una vez al principio de la ejecución

157


y que sirve para cualquiera de las tres posibles distribuciones en particionesque gestiona nuestro algoritmo. Se trata de con�gurar cuatro bus macros enla parte inferior de la FPGA y otras cuatro situadas en las mismas posicioneshorizontales pero en la parte superior de la FPGA.

Observamos que las particiones P1 para 3P y P4 para 6P coinciden y com-parten la bus macro bm4. La partición P0 de la distribución 3P es la unión delas particiones P0 y P1 de la distribución 6P, por lo que comparten una de lasbus macros, la bm1. En la parte superior de la FPGA la partición P2 compar-te bus macro en todos los tipos de distribuciones, la bm5. Las particiones P3

de 4P y 6P utilizan diferentes bus macros (bm7 y bm6) y la partición P5 nocomparte su bus macro (bm8) con ninguna otra ya que la partición P2 de 3Pocupa la mitad superior de la FPGA y utiliza la misma bus macro que la P2

de las otras dos distribuciones.Se trata en total de 8 bus macros que se sitúan en las siguientes posiciones:1. bm1 = (0, 0) se utiliza para la partición P0 en cualquiera de las distribu-

ciones en particiones.2. bm2 = (0, 25 ·W, 0) se utiliza para la partición P1 en la distribución 6P.3. bm3 = (0, 30 ·W, 0) se utiliza para la partición P1 en la distribución 4P.4. bm4 = (0, 50 ·W, 0) se utiliza para la partición P1 en la distribución 3P

y para la P4 en la distribución 6P.5. bm5 = (0, H) se utiliza para la partición P2 en cualquiera de las distri-

buciones en particiones.6. bm6 = (0, 25 ·W, H) se utiliza para la partición P3 en la distribución 6P.

158


Figura 5.3: Ubicación de las bus macros válidas para todas las distribuciones

7. bm7 = (0, 30 ·W, H) se utiliza para la partición P3 en la distribución 4P.

8. bm8 = (0, 50 ·W, H) se utiliza para la partición P5 en la distribución 6P.

Con este procedimiento podemos realizar el cambio de forma gradual, ha-ciendo que se solapen las distintas distribuciones en particiones durante lafase del cambio y reduciendo de forma muy signi�cativa la penalización enrendimiento que conlleva realizar el cambio.

Por ejemplo, si se cambia de 3 particiones a 4 particiones y la tarea de P0 con3P termina su ejecución la primera, podrá pasar a ejecutarse una de las tareasque están esperando en las colas en la partición P0 de 4P utilizando la mismabus macro, la bm0, para acceder al bus de comunicaciones y sin interferir en laejecución de las otras dos tareas que continúan ejecutándose con la distribución

159


3P. Si a continuación termina la tarea que se estaba ejecutando en la particiónP2 de la distribución 3P, podrá empezar a ejecutarse una tarea de las colas quequepa en la partición P2 de la distribución 4P utilizando la bm5 y sin interferiren la ejecución de la tarea que queda en la partición P1 de la distribución3P. Por último, cuando la última tarea que se está ejecutando en P1 de 3Ptermine su ejecución, pasarán a estar disponibles las particiones P1 y P3 dela distribución 4P y las tareas que se ejecuten en ellas podrán utilizar las busmacros bm3 y bm7 respectivamente. En resumen, el cambio en las particionesse puede realizar de forma gradual y sin necesidad ni de recon�gurar el bus decomunicaciones ni de retrasar la ejecución de muchas de las tareas que esperanen la colas.

En la siguiente subsección presentamos la forma en que se ha implementa-do la gestión de las particiones para el cambio gradual en la distribución departiciones de la FPGA.

5.2.3. Implementación del cambio gradual

La �gura 5.3 nos muestra cómo algunas particiones de distinto tipo coinci-den y otras se solapan. Para poder determinar qué tareas asignadas al nuevotipo de distribución pueden lanzarse a ejecutar conforme van terminando lastareas que ocupaban particiones de la antigua distribución, la ULT dispone detres tablas de correspondencias que le indican, para cada tipo de distribucióncuáles son las particiones que se solapan con las de las otras distribuciones.Las tablas 5.1, 5.2 y 5.3 nos muestran las correspondencias entre particionesque solapan con los distintos modelos de particiones utilizados.

160


Tabla 5.1: Tabla de correspondencias para 4P

4P 3P 6PP0 P0 P0, P1

P1 P0, P1 P1, P4P2 P0, P2 P0, P1, P2, P3

P3 P0, P1, P2 P1, P3, P4, P5


3P 4P 6PP0 P0, P1, P2 P0, P1

P1 P2, P3 P1, P4

P2 P2, P3 P2, P3, P5

Para llevar a cabo el cambio gradual, la ULT dispone de otras tres tablas deocupación en las que registra los tiempos en que las particiones de cualquierdistribución quedarán libres. Cada vez que envía una tarea a ejecutar a laFPGA, consulta la tabla de correspondencias de la distribución que se estáutilizando en ese momento y marca los tiempos de �n de ejecución para todaslas demás distribuciones, escribiendo en ellas la cantidad t+teji (si correspondea un tiempo posterior al ya escrito). De esta manera, cuando un cambio en lasparticiones es noti�cado por la UAD, la ULT consulta la tabla correspondientea la nueva distribución y a través de un sencillo cálculo comprueba si unapartición de la nueva distribución de particiones está libre para ejecutar unatarea de las colas.

A continuación mostramos un ejemplo sencillo de funcionamiento de lastablas de correspondencias. Partiremos de un ejemplo en que la FPGA estávacía y estamos en la unidad de tiempo 0, funcionando con una distribución en

161



6P 4P 3PP0 P0, P2 P0

P1 P0, P1, P2, P3 P0

P2 P2 P2

P3 P2, P3 P2

P4 P2, P3 P1

P5 P3 P2

4 particiones. Llega una tarea que tiene un tiempo de ejecución de 10 unidadesde tiempo y que se asigna a la partición P3. La tabla de ocupación para 4P seactualiza conforme muestra la tabla 5.4.

Tabla 5.4: Tabla de ocupación para 4P I

4P P0 P1 P2 P3

t�n 0 0 0 10

La tabla de ocupación equivalente para 3 particiones se actualizará segúnmuestra la tabla 5.5.


3P P0 P1 P2

t�n 10 10 10

Y la tabla de ocupación equivalente para 6 particiones quedaría según semuestra en la tabla 5.6.

Con esta información, si en t = 4 se noti�cara un cambio a 6 particiones yal mismo tiempo hubiera llegado una tarea pequeña para ejecutar, con tiempo

162



6P P0 P1 P2 P3 P4 P5

t�n 0 10 0 10 10 10

de ejecución de 8 unidades de tiempo, la ULT dispondría de las particiones quecumplan la condición t − tfin ≥ 0 para ejecutarla mientras termina la tareaanterior. Así, podría ejecutarla en la partición P0 de la nueva distribución sinperturbar la ejecución de la otra tarea. Actualizaría las tablas de ocupacióncon la información de la nueva tarea según muestran las tablas 5.7, 5.8 y 5.9.

Tabla 5.7: Tabla de ocupación para 4P II

4P P0 P1 P2 P3

t�n 12 0 0 10


3P P0 P1 P2

t�n 12 10 10

Este sencillo procedimiento permite a la ULT disponer de información ac-tualizada de la ocupación de particiones para cualquiera de las distribucionesen todo momento y realizar el cambio en las particiones de forma gradual ycon la menor penalización posible.

163



6P P0 P1 P2 P3 P4 P5

t�n 12 10 0 10 10 10

5.3. Ejemplo

En esta sección mostraremos de forma detallada cómo funciona la Adapta-ción Dinámica. Utilizaremos un lote de 161 tareas, cuya composición se muestraen la �gura 5.4.

Figura 5.4: Composición del lote utilizado para el ejemplo

Las primeras 96 tareas corresponden a una distribución tipo Lpp, que seestán ejecutando con 4P (tramo azul a la izquierda). La UAD detecta que ladistribución en particiones no es adecuada y decide el cambio a 6P (tramorosa). Las últimas 65 tareas del lote corresponden a una distribución tipo Lm.Tras el cambio en el tipo de distribución (paso de Lpp a Lm en t = 101), laUAD detecta que es más adecuado volver a una distribución en 4P y decidehacer un nuevo cambio (tramo azul a la derecha). La tabla 5.10 muestra elper�l de este lote de tareas.

En la tabla podemos ver que el conjunto del lote de tareas se parece más a164

Ejemplo 5.3

Tabla 5.10: Per�l del lote de tareas con dos cambios de particiones

α β δ γ a tej Vas0,83 0,39 0,36 0,25 17,40 6,34 456004

una distribución plana que a ninguna de las otras de�nidas, si solamente nos�jamos en los parámetros β, δ y γ. Sin embargo el área media de las tareasdel lote es la de una distribución Lpp. Esto signi�ca que con esta carga detrabajo ninguna de las distribuciones en particiones conseguiría un máximoaprovechamiento de la FPGA y hemos elegido un ejemplo así para poner demani�esto la necesidad de completar el algoritmo básico con la funcionalidadde Adaptación Dinámica, o lo que es lo mismo, con las posibilidad de utilizardiferentes distribuciones en particiones a lo largo de una ejecución para lograrel máximo rendimiento de nuestro algoritmo.

Si la versión básica del algoritmo ya supera en rendimiento a un algoritmocomplejo como el FF, con la posibilidad de realizar la adaptación dinámicanuestro algoritmo consigue aumentar aún más esta diferencia en el rendimiento,como veremos en el capítulo 6 de Resultados Experimentales.

Pasamos ahora a analizar en detalle la ejecución de este lote de tareasy después presentaremos un resumen de la mejora en rendimiento obtenidagracias a la implementación de la Adaptación Dinámica.

La ejecución empieza con una distribución 4P. Sin embargo el conjunto de96 primeras tareas que llegan al sistema corresponde a una distribución Lpp,por lo que sería más adecuado utilizar 6P para esta carga de trabajo. La �gura5.5 re�eja la situación en este primer tramo de ejecución del lote-ejemplo.

La UAD detecta con bastante rapidez la desviación existente en Dp. La165


Figura 5.5: Primer tramo de la ejecución: Lpp en 4P

�gura 5.6 nos muestra la variación de Dp en las 20 primeras unidades detiempo de ejecución de este lote. En t = 9 han llegado las primeras 16 tareasal sistema y el primer valor de Dp calculado ya supera el valor umbral de 1,8.

Figura 5.6: Valores de Dp antes del primer cambio

Como el valor de Dp se mantiene por encima del umbral, la UAD deciderealizar un cambio a 6P en t = 13. En este momento la FPGA está llena yhay una tarea esperando en las colas, que había llegado en t = 9. Es unatarea pequeña con tiempo de ejecución 7 u.t. y que tiene que ejecutarse antesde t = 23 (el tiempo máximo utilizado para todas las pruebas realizadas es

166

Ejemplo 5.3

el doble del tiempo de ejecución de las tareas, contado a partir del momentode su llegada). En t = 13 los contenidos de las tablas de ocupación son losmostrados en las tablas 5.11 y 5.12.

Tabla 5.11: Tabla de ocupación para 4P, primer cambio

4P P0 P1 P2 P3

t�n 20 16 20 19

Tabla 5.12: Tabla de ocupación para 6P, primer cambio

6P P0 P1 P2 P3 P4 P5

t�n 20 16 20 19 20 19

Puesto que la tarea que espera en las colas es de tamaño pequeño, podríaejecutarse en cualquiera de las particiones de 6P. La ULT le asigna P1, quees la de menor tiempo de espera, al comprobar que 16 + 7 ≤ 23 y por tantocumple el tiempo máximo de espera permitido para esta tarea. Cambia estatarea a la cola Q1 de 6P.

A partir de t = 13 la ejecución prosigue con una distribución en 6P, segúnmuestra la �gura 5.7.

La siguiente tarea no llega al sistema hasta t = 14, momento en el que se leasignará una cola conforme a la nueva distribución en 6P. La tupla que de�nea esta tarea es (15, 15, 14, 5, 24). La UPT comprueba el estado de las colaspara 6P. Comprueba que en Q3 cumple la condición 19 + 5 = 24 ≤ 24, y laescribe en Q3 de la nueva distribución.

Las tres siguientes tareas llegan juntas en t = 17. Dos de ellas son detamaño mediano y una de ellas es grande (de 25 · 25 CBRs). Han transcurrido

167


Figura 5.7: Segundo tramo de la ejecución: Lpp en 6P

4 unidades de tiempo desde que se realizó el cambio y todas ellas son asignadasa diferentes colas de la nueva distribución de particiones, ya que cumplen consu tiempos máximos.

Este es un ejemplo en el que se ha podido realizar el cambio gradual en lasparticiones sin penalización alguna.

La ejecución prosigue con una distribución 6P, con Dp por encima del valor0, 8 y por debajo de 1, 8.

Sin embargo, en t = 101, la distribución de tareas cambia de Lpp a Lm. Esel momento en que llega una tarea de tamaño grande, del 42 % del área de laFPGA y se tiene que recurrir a la unión de las 4 particiones más pequeñas,por lo que empiezan a acumularse retrasos en el sistema.

La �gura 5.8 nos muestra la parte de la ejecución en que nos encontramosahora.

Si no se repitiera esta situación, el sistema volvería a equilibrarse y nohabría pérdidas en el rendimiento. Sin embargo, siguen llegando tareas de untamaño mayor al de las particiones 6P y en t = 106 una tarea grande debe serrechazada. El algoritmo empieza a perder e�cacia.

La �gura 5.9 nos muestra la evolución de Dp en un tiempo anterior y168

Ejemplo 5.3

Figura 5.8: Tercer tramo de la ejecución: Lpp cambia a Lm y se está utilizando una dis-tribución en 6P

posterior al segundo cambio en la distribución de tareas.

Figura 5.9: Valores de Dp en el segundo cambio

Observamos que en t = 101, momento en que llega la tarea grande, Dp

baja su valor. Después llegan una tarea de tamaño mediano y otra pequeñay Dp vuelve a subir, pero cuando llega la siguiente tarea grande, en t = 106,su valor baja otra vez (ya que ahora hay dos tareas grandes en la ventana de16 tareas y su peso en el área media es grande) y sigue bajando hasta que ent = 112 (en este momento llega otra tarea grande) toca el límite de 0, 8 por

169


primera vez. A partir de aquí sigue bajando y la UAD determina un cambio a4P en t = 118.

En este momento hay tres tareas ejecutándose en la FPGA: una que ocupaP1 + P3 + P4 + P5 y otras dos en las dos particiones restantes. Las tablas deocupación se muestran en las tablas 5.13 y 5.14.

Tabla 5.13: Tabla de ocupación para 6P, segundo cambio

6P P0 P1 P2 P3 P4 P5

t�n 122 123 120 123 123 123

Tabla 5.14: Tabla de ocupación para 4P, segundo cambio

4P P0 P1 P2 P3

t�n 123 123 123 123

En ese momento hay una tarea de tamaño mediano esperando en las colas,cuyo tiempo máximo de ejecución permite asignarle la partición P2 en la nuevadistribución 4P. Las siguientes tareas que llegan tienen también tiempos má-ximos que les permiten esperar en las colas hasta t = 123, así que ninguna esdesechada. De nuevo se ha podido realizar el cambio gradual en las particionessin tener que rechazar ninguna tarea.

El resto de la ejecución se termina con la distribución en 4P y sin que serechacen tareas, con un buen aprovechamiento del área de la FPGA, segúnmuestra la �gura 5.10.

La tabla 5.15 compara el rendimiento que se habría obtenido con el algo-ritmo básico con el rendimiento obtenido con el algoritmo que implementa la

170

Ejemplo 5.3

Figura 5.10: Último tramo de la ejecución: Lm en 4P

adaptación dinámica (AD) y ejecuta este lote con 4P-6P-4P. El volumen de lacarga de trabajo de este lote de tareas es de 456,004 CBRs ·#u.t.

Tabla 5.15: Comparativa de rendimientos

Básico AD# u.t. 218 218a( %A) 70,15 77,73

Vej 382.269 423.636R( %) 83,83 92,90

Esta tabla nos muestra que aunque el rendimiento del algoritmo básico esbastante bueno, el rendimiento con la adaptación dinámica es mucho mejor.Se ha desechado un mínimo de volumen de trabajo asignado (recordemos queantes de realizar el cambio se descartaron unas pocas tareas, que suponen unporcentaje bastante bajo de la carga de trabajo) y que el algoritmo, gracias alos cambios en las particiones realizados, ha logrado plani�car la ejecución deprácticamente toda la carga de trabajo asignada. Para este caso, la mejora enel rendimiento con la adaptación dinámica es del 9, 1 %.

Este ejemplo nos muestra dos cambios de particiones en los que no ha sidonecesario rechazar tareas al cambiar el número y tamaño de las particiones.

171


Esta situación no siempre se da. A partir de las pruebas realizadas, encontra-mos también ejemplos donde una de las tareas (y no siempre la última quellegó antes de decidir el cambio) tiene que ser rechazada. En general serán unao dos tareas las que se tienen que rechazar debido al cambio en las particiones,y en todos los casos estudiados y que se presentarán en el capitulo 6 de Resul-tados Experimentales, observamos que se puede alcanzar un buen aumento enel rendimiento del algoritmo al permitir el cambio en el número y tamaño delas particiones a lo largo de su ejecución.

5.4. Algoritmo de la UAD

A continuación mostramos el algoritmo que se utliza en la Unidad de Adap-tación Dinámica. Este algoritmo, que se ejecuta en paralelo con el algoritmode la Unidad de Plani�cación de Tareas, es también de complejidad constante.

172

Algoritmo de la UAD 5.4

Algoritmo 10 Algoritmo para la UADEscribir-tarea-en-FIFO(Ti);FLLTreal = 16/(tllm − tll1);a=Calcula-area-media();tej = Calcula-tej-medio();FLLTideal = A/a · tej;α = FLLTreal/FLLTideal;if (0, 5 ≤ α) then

Dp = A/a · P ;if (DP ≥ 1, 8) then

contmasP = contmasP + 1;if (contmenosP ≥ 1) then

contmenosP = contmenosP − 1;end if

end ifif (DP ≤ 0, 8) then

contmenosP = contPmenos + 1;if (contmasp ≥ 1) then

contmasP = contmasP − 1;end if

end ifif (0, 8 < DP < 1, 8) thenif (contmasp ≥ 1) then

contmasP = contmasP − 1;end ifif (contmenosP ≥ 1) then

contmenosP = contmenosP − 1;end if

end ifend ifif (contmasP = 3) thenAumentar-numero-de-particiones(a);

end ifif (contmenosP = 3) thenDisminuir-numero-de-particiones(a);

end if

173


Algoritmo 11 Subrutina Aumentar-numero-de-particiones(a)D′

p = 0;if (P = 3) then

P ′ = 4;D′

p = A/a · P ′;if (D′

p ≤ 1, 8) thencambio = true;w′

p = 0, 3,h′p = 0, 3, P = P ′;end if

end ifif (P = 4) or (D′

p > 1, 8) thencambio = true;P ′ = 6,w′

p = 0, 25,h′p = 0, 5,w′pp = 0, 5,P = P ′;

end if

Algoritmo 12 Subrutina Disminuir-numero-de-particiones(a)D′

p = 0if (P = 6) then

P ′ = 4D′

p = A/a · P ′;if (D′

p ≥ 0, 8) thencambio = true;w′

p = 0, 3,h′p = 0, 3, P = P ′;end if

end ifif (P = 4)or (D′

p < 0, 8) thencambio = true;P ′ = 3,w′

p = 0, 5,h′p = 0, 5, P = P ′;end if

174

Capítulo 6

Resultados experimentales

En este capítulo presentamos los resultados de los diferentes experimentosrealizados, tanto con la versión básica del algoritmo como de la versión con lafuncionalidad de Adaptación Dinámica.

Todas las pruebas se han realizado con un simulador del entorno de pla-ni�cación, que incluye la UPT, la ULT, la UAD, un vector de P elementosque representa la FPGA y un archivo con la entrada de datos que contiene lastuplas que de�nen a cada tarea.

Se han utilizado dos tamaños de FPGA diferentes: una de 20*20 CBRs yotra de 50*50 CBRs. Los tamaños de las particiones utilizadas (expresados enCBRs) se detallan en la tabla 6.1.

Tabla 6.1: Tamaños de particiones

FPGA P0 P1 P2 P3

20x20 25 75 75 22550x50 225 525 525 1225

175

Capítulo 6. Resultados experimentales

Aunque el rendimiento del algoritmo, según hemos explicado en el capítulo3, se mide como la relación entre el volumen ejecutado y el volumen asignado,presentaremos los resultados experimentales especi�cando tres parámetros, re-lacionados entre sí, para una mayor claridad. Los parámetros presentados enlos resultados son:

1. Rendimiento: relación entre el volumen ejecutado y el volumen asigna-do, expresado en porcentaje según la fórmula R =

Vej

Vas· 100.

2. % Área media utilizada: representa el porcentaje de área de FPGAutilizada en media durante la ejecución completa del lote de tareas.

3. Unidades de Tiempo: número total de unidades de tiempo, medidodesde el momento en que llega la primera tarea del lote a ejecutarse enla FPGA hasta que termina la ejecución de la última tarea en la FPGA.Para un mismo volumen de trabajo ejecutado, a menor valor de unidadesde tiempo, el valor del área media utilizada será mayor.

6.1. Experimentos con el algoritmo básico 4P

En esta sección presentaremos los resultados obtenidos para la simulaciónde una FPGA de 20*20 CBRs. Hemos creado lotes de tareas que representandistribuciones arti�ciales de tareas. Se han realizado estas pruebas con el ob-jetivo de comprobar la e�ciencia de nuestro algoritmo básico de 4 particiones(ABP) en comparación con otros algoritmos complejos, como First Fit, cuyofuncionamiento se ha descrito en detalle en el capítulo 3. Por esta razón todas

176

Experimentos con el algoritmo básico 4P 6.1

las pruebas presentadas en esta sección se re�eren a una distribución del áreade la FPGA en 4 particiones.

6.1.1. Benchmark arti�ciales

En primer lugar presentamos la tabla 6.2 con los detalles de las caracte-rísticas de lotes de tareas arti�ciales que hemos construido para comaprar elrendimiento de FF con nuestro algoritmo. Todos ellos están compuestos por52 tareas.

Tabla 6.2: Características de los benchmark arti�ciales

Lote α a (%A) tej Vas β δ γ

L1 0,96 25,00 5,00 26.000 0,25 0,50 0,25L2 1,03 25,00 5,00 26.000 0,25 0,50 0,25L3 1,16 25,00 5,00 26.000 0,25 0,50 0,25L4 0,94 24,52 5,00 25.500 0,29 0,46 0,25L5 0,96 25,00 5,00 26.000 0,25 0,50 0,25L6 0,96 25,00 5,00 26.000 0,25 0,50 0,25L7 1,10 29,08 5,00 30.250 0,15 0,52 0,33L8 1,22 32,21 5,00 33.500 0,13 0,46 0,41

A continuación pasaremos a comentar en detalle la información contenidaen la tabla. Lo haremos lote por lote, explicando las diferencias entre algunosde ellos, que no se ven re�ejadas en la tabla ya que dan lugar - aparentemente -a idénticos conjuntos de tareas y sin embargo contienen diferencias que, comoveremos, generan resultados distintos.

Una característica común a todos estos benchmark arti�ciales es que tienenuna frecuencia de llegada de tareas muy alta, por encima del 90% de la ideal,y los primeros están muy cercanos a casos ideales. A partir de estos primeros

177


lotes prácticamente ideales hemos introducido variaciones en parámetros comoel orden de llegada de tareas y desviaciones del caso ideal.

L1: Se trata de un lote de tareas de tipo Lm casi ideal (el parámetro α

vale prácticamente 1).L2: Es igual que el lote L1 (el mismo conjunto de tareas) pero con unafrecuencia de llegada de tareas más alta (se han cambiado los tiemposde llegada de las tareas para que estén más cercanos).L3: También es igual al lote L1 pero se ha aumentado la frecuencia dellegada de tareas aún más.L4: Este lote muestra una ligera desviación respecto al ideal y contieneuna proporción ligeramente mayor de tareas de tipo pequeño. Por elloel área media es algo menor a la de los anteriores y los valores de Dp

también varían ligeramente. Esto es debido a que se ha representado unasituación en la que llega un pequeño pico de tareas pequeñas, es decir, ungrupo de 6 tareas pequeñas que llegan prácticamente seguidas, en mediode un lote de tareas de tipo mediano cercano al ideal.L5: Se ha construido con las mismas tareas que L1 y se han mantenidolos tiempos de llegada de las tareas. Lo que se ha cambiado es el ordenen que llegan al sistema. Podríamos decir que es como el conjunto L1pero después de barajarlo y manteniendo los mismos tiempos de llegadapara que la frecuencia de llegada de tareas no cambie.L6: Los tamaños de las tareas y sus tiempos de llegada son los mismospero mientras que en L1 y los anteriores lotes los tiempos de ejecución

178


son uniformes, aquí el tiempo de ejecución medio es igual al de los otroslotes pero se ha obtenido asignando tiempos de ejecución dispares en lastareas (con una relación 1:10 entre ellos).

L7: En este lote de tareas se ha aumentado la proporción de tareasgrandes hasta sobrepasar ligeramente el 30%, siendo la proporción detareas pequeñas menor que en los lotes anteriores.

L8: Toma como base el lote anterior y se incrementa la proporción detareas grandes a costa de las pequeñas.

Los lotes de tareas cuyas características hemos mostrado y comentado sehan diseñado a propósito para poder estudiar el impacto de determinadosfactores en el rendimiento de nuestro algoritmo. Estos factores y los lotes detareas a partir de los cuales se pueden realizar las observaciones son:

1. Frecuencia de llegada: Los resultados correspondientes a los lotes L1,L2 y L3 nos mostrarán la efectividad de nuestro algoritmo en compara-ción con FF respecto al incremento de la frecuencia de llegada de tareaspor encima de su valor ideal (es decir, cuando la carga de trabajo asig-nada sea superior al límite teórico de la capacidad de la FPGA).

2. Pico de tareas pequeñas: Los resultados correspondientes a los lotesL1 y L4 (con casi la misma frecuencia de llegada de tareas) nos mostraránla efectividad de nuestro algoritmo para resolver situaciones puntualesde variación de la carga de trabajo con respecto a la distribución ideal.Hemos probado el caso de un pico de tareas pequeñas porque es el que

179


más perjudica al rendimiento de nuestro algoritmo frente al de FF, comose explicó en detalle en el capítulo 3.

3. Orden de llegada de las tareas: La comparación en la ejecución delos lotes L1 y L5 nos mostrará la sensibilidad de nuestro algoritmo frentea FF respecto al orden de llegada de las tareas. Este aspecto también secomentó con detalle en el ejemplo del capítulo 3.

4. Uniformidad en los tiempos de ejecución: La comparación entre loslotes L1 y L6 nos dará una idea de la sensibilidad de nuestro algoritmofrente a la dispersión en los valores de los tiempos de ejecución de lastareas.

5. Sistema sobrecargado: La comparación entre los lotes L3, L7 y L8nos dará una idea de la e�ciencia de nuestro algoritmo para resolversituaciones de sobrecarga de trabajo. Observamos que en los dos últimoslotes, L7 y L8, el volumen de trabajo asignado es un 20% mayor que enlos demás lotes y la frecuencia de llegada de tareas es también bastantesuperior a la ideal. Este efecto se ha conseguido disminuyendo los tiemposentre la llegada de tareas y aumentando considerablemente el tamaño deéstas.

La tabla 6.3 nos muestra los resultados de la ejecución de nuestro algoritmoy del algoritmo FF para estos benchmark.

En la �gura 6.1 vemos que el rendimiento de nuestro algoritmo básico esclaramente superior al de FF en todos los casos que hemos simulado.

180


Tabla 6.3: Resultados para los benchmark arti�ciales

R ( %) # u.t. Área ( %)Lote ABP FF ABP FF ABP FF

L1 100,0 78,8 69 69 94,2 74,2L2 100,0 58,2 69 64 94,2 59,0L3 75,5 45,2 61 57 80,4 51,5L4 100,0 75,4 69 70 91,1 68,8L5 100,0 53,8 69 69 94,2 50,7L6 98,7 78,4 69 70 91,7 73,8L7 85,1 60,3 72 69 85,1 60,3L8 76,5 57,5 71 69 90,7 69,7

6.1.1.1. Conclusiones del análisis de los resultados para benchmark

arti�ciales

En primer lugar vamos a resumir unas conclusiones generales, aplicablesa todos los lotes de tareas y después comentaremos en detalle los aspectosmencionados anteriormente, relacionados con grupos especí�cos de lotes detareas.

1. Rendimiento: Como ya se indicó en el ejemplo de funcionamiento ex-plicado en detalle en el capítulo 3, el algoritmo FF presenta una claradesventaja frente al nuestro siempre que haya una presencia de tareasde tamaño relativamente grande y solamente obtendrá resultados igua-les o mejores que el nuestro en casos bastante extremos donde tengamosprácticamente la totalidad de tareas de tamaño pequeño (se mostraráneste tipo de resultados más adelante en este capítulo). De la primeracolumna podemos deducir que para una gran cantidad de situaciones ysiempre que aparezcan tareas de tamaño superior al 25% del tamaño de

181


Figura 6.1: Comparación del Rendimiento de ABP con FF

la FPGA, nuestro algoritmo básico de complejidad constante que divideel área de la FPGA en 4 particiones de diferentes tamaños presenta unrendimiento superior al algoritmo FF, lo que también se ve re�ejado conclaridad en la �gura 6.1.

2. Tiempo de ejecución del lote: Si observamos las unidades de tiemponecesarias para ejecutar los lotes completos observamos que nuestro algo-ritmo está ligeramente por encima de FF en la mitad de los casos. Esto noes debido a una mala gestión por parte de nuestro algoritmo sino al hechode que ejecuta una mayor cantidad de trabajo, como puede observarseen la columna del Rendimiento. Por ello podemos decir que realmenteesta columna analizada en conjunto con la tercera nos indica que nues-tro algoritmo puede ejecutar una cantidad de trabajo mayor que FF enel mismo tiempo o un tiempo ligeramente superior. El caso con mayor

182


diferencia es el del lote L2 en que la diferencia de tiempos es del 7, 8 % afavor de FF mientras que la diferencia de volumen de trabajo ejecutadoes de 41, 8 % a nuestro favor. En algunos casos, como el representado porel lote L5, la cantidad de trabajo ejecutada por nuestro algoritmo es casiel doble que la ejecutada por FF mientras que el tiempo empleado es elmismo. El hecho de poder ejecutar la misma o superior carga de trabajoen tiempos parecidos se ve re�ejada en la tercera columna, que muestrael área media de FPGA utilizada en cada ejecución.

3. Área media utilizada: A pesar de la sencillez de planteamiento de nues-tro algoritmo y de no ser un algoritmo avaricioso en uso de área, vemosque la idea de equilibrar y organizar la carga de trabajo adecuadamenteen el espacio a través de la clasi�cación por tamaños (particiones) y en eltiempo a través de los tiempos máximos de ejecución (tiempos de esperaen cada cola) resulta ser más e�caz en el uso de área que el planteamien-to del algoritmo de FF, dando en todos los experimentos realizados unporcentaje superior en uso de la FPGA.

Pasamos ahora a analizar los aspectos concretos que determinan las dife-rencias entre los lotes de tareas:

1. Frecuencia de llegada: Los resultados correspondientes a los lotes L1,L2 y L3 prueban una mayor efectividad de nuestro algoritmo en compara-ción con FF respecto al incremento en la frecuencia de llegada de tareas.En el lote L1 el valor de α es cercano al ideal y representa una situaciónde carga de trabajo de la FPGA al borde de la saturación. Vemos que eneste caso FF no es capaz de ejecutar la totalidad del trabajo asignado,

183


debido, como ya hemos dicho, a que en dicho lote hay un 25% de tareasde tamaño grande. Observamos también que la pérdida de rendimientodel algoritmo FF con el aumento en la frecuencia de llegada de tareases mucho más rápido que para nuestro algoritmo, que permite un ligeromargen por encima de α = 1. Para L3, donde la sobrecarga del sistemaes evidente (α es un 16% superior al límite teórico establecido para tenerla FPGA llena el 100% del tiempo) nuestro algoritmo tampoco es capazde ejecutar la totalidad de la carga de trabajo asignada, pero aún asímuestra un rendimiento muy superior al de FF.

2. Pico de tareas pequeñas: Comparando los resultados correspondien-tes a los lotes L1 y L4, observamos que nuestro algoritmo básico es e�cazresolviendo situaciones puntuales, como un breve aumento de tareas pe-queñas, que hemos llamado pico de tareas.

3. Orden de llegada de las tareas: La comparación en la ejecución delos lotes L1 y L5 prueba que nuestro algoritmo es menos sensible al ordende llegada de tareas que FF, ya que clasi�ca las tareas y las mantieneesperando en la cola que les corresponde siempre que su tiempo de esperacumpla con los límites de tiempo establecidos para la tarea. Esto haceque el orden de llegada de tareas afecte en menor medida a los resultadosde la ejecución que en el caso de FF en el que el orden de llegada de lastareas tiene un gran impacto en la fragmentación del área libre de laFPGA.

4. Uniformidad en los tiempos de ejecución: La comparación entre loslotes L1 y L6 nos indica la importancia de este aspecto en el rendimiento

184


del algoritmo. Si los tiempos de ejecución de las tareas son parecidos,nuestro algoritmo hará una mejor gestión del área de la FPGA que sison muy dispares. Aunque el rendimiento de nuestro algoritmo aun enel caso de mayor disparidad entre los tiempos de ejecución de las tareases superior al de FF, en este ejemplo observamos que el rendimiento denuestro algoritmo se ve más afectado por este hecho que el algoritmo FF.Esto puede explicarse por el hecho de que si una de las tareas tiene untiempo de ejecución mucho más alto que las otras la cola asociada a lapartición que le corresponda mostrará un tiempo de espera mucho másalto, obligando entonces a que otras tareas que deberían asignarse a dichacola se envíen a otras colas correspondientes a un tamaño mayor, por loque el uso del área de la FPGA es peor y el rendimiento del algoritmodisminuye (esto se ve claramente re�ejado en la segunda columna para loslotes L1 y L6 donde el uso medio de área de nuestro algoritmo es menorcuando los tiempos de ejecución son más dispares). Aún así convienedestacar que nuestro algoritmo ejecuta una mayor cantidad de trabajoque el algoritmo FF y en el mismo tiempo.

5. Sistema sobrecargado: La comparación entre los lotes L3, L7 y L8nos indica que la e�ciencia de nuestro algoritmo para resolver situacio-nes de sobrecarga de trabajo es mejor que la del algoritmo FF. En losdos últimos lotes, L7 y L8, el parámetro γ que indica la proporción detareas grandes en el lote, está por encima del 30%, causando un dete-rioro en el rendimiento del algoritmo FF mucho más acusado que en elnuestro. Estos dos últimos lotes de tareas con�rman además la necesidad

185


de mejorar el rendimiento de nuestro algoritmo añadiendo la capacidadde ajustar el tamaño y número de particiones a diferentes situaciones.Estos dos ejemplos de conjuntos de tareas nos han servido también paradarnos cuenta que una proporción de tareas grandes superior al 40% enun conjunto de tareas era un indicativo claro de la necesidad de cambiarel esquema básico de particiones, ya que el rendimiento obtenido con laversión básica empieza a estar por debajo de límites aceptables (un ren-dimiento ligeramente superior al 75% indica que aproximadamente unade cada cuatro tareas es rechazada).

6.1.2. Benchmark sintéticos

Puesto que los lotes presentados en la sección anterior corresponden a si-tuaciones creadas arti�cialmente, hemos creído conveniente construir un lotede tareas a partir de datos de la síntesis de tareas reales. Una explicación deta-llada de las aplicaciones utilizadas y cómo se han sintetizado se puede obteneren [NHCB02]. Nos hemos basado en esta única publicación dada la di�cul-tad de encontrar información detallada y completa (es decir, número de CLBsutilizados y tiempos de ejecución) acerca de la síntesis de aplicaciones reales.

La composición del benchmark sintético se muestra en la tabla 6.4, dandoun total de 106 tareas. Hemos incluido también la aplicación JPEG sintetizadaen una Virtex-2 XCV2P30, en una versión en que algunas subtareas se hadividido en otras más pequeñas e idénticas (JPEG paralelo), dando lugar a unconjunto de 16 tareas de tamaño pequeño.

Las aplicaciones utilizadas son de tamaños muy diversos y tiempos de eje-186


Tabla 6.4: Composición del benchmark sintético

Aplicación No ejecucionesparallel JPEG 2 (16 sub-tareas)

Sobel 14Multiplicación de matrices 3

Closure 2Homogeneous 12

Image thresholding 59

cución muy dispares, variando del tamaño 15*15 y tiempo de ejecución 1ms

hasta tamaños de 11x15 y tiempo de ejecución 13 ms o tamaños de 4*2 ytiempo de ejecución 22 ms. La tabla 6.5 nos muestra las características deeste conjunto de tareas, donde se especi�ca el número de ejecuciones de cadaaplicación en el benchmark.

Tabla 6.5: Características del benchmark sintético

α a (%A) tej Vas β δ γ Dp3P Dp4P Dp6P0,63 20,51 6,56 24.694 0,49 0,23 0,28 1,62 1,22 0,81

Podemos observar que no se corresponde exactamente con ninguna de lasdistribuciones teóricas estudiadas. Del estudio de los parámetros α, β y γ seríauna distribución de tipo pequeñas con una proporción de grandes ligeramentesuperior al 25 % de�nido para este tipo de distribución. Por ello el área mediade las tareas es del máximo del tamaño de tareas medianas aunque no seanlas que predominen en el lote. Esto nos da una distribución muy interesanteya que nos permitirá comprobar el grado de �abilidad del modelo teórico a lahora de ser puesto en práctica en un entorno real de trabajo.

187


Analizando los valores obtenidos para el parámetro Dp, indicador de laadecuación del tipo de distribución de particiones a la carga de trabajo, obser-vamos que aunque la mayoría de tareas son de tamaño pequeño, al haber unaproporción bastante alta de tareas grandes (cercana al 30%), una distribuciónen 6 particiones no sería adecuada (recordemos que un Dp teórico de 0, 8 su-pone que en tiempo real se alcanzarán valores muy bajos, del orden de 0, 6 yque indican que hay una clara infra-utilización del área de la FPGA). Ademásse tendría que recurrir a la unión de particiones con excesiva frecuencia.

Una distribución en 3 particiones tampoco lo sería, debido a la gran pro-porción de tareas pequeñas en el conjunto, que obliga a tener un mayor númerode particiones disponible para poder ejecutar un mayor número de ellas simul-táneamente.

El valor obtenido para 4 particiones está también lejos del ideal pero es elmás cercano de todos. La tabla 6.6 nos muestra los resultados obtenidos parala ejecución de este benchmark sintético con nuestro algoritmo básico, es decircon 4 particiones. Para este caso u.t = 1 ms.

Tabla 6.6: Resultados de la ejecución en 4P

FF ABP% área media usada 45,00 55,10Unidades de tiempo 104 112

Rendimiento 75,8 100

188

Experimentos con Adaptación Dinámica 6.2

6.1.2.1. Conclusiones del análisis de los resultados para benchmark

sintéticos

Los resultados presentados en la tabla 6.6 nos muestran la misma tenden-cia en cuanto a la comparación de rendimiento entre nuestro algoritmo y elalgoritmo FF que hemos observado en la sección anterior con los benchmarkarti�ciales. Aun a pesar de la alta presencia de tareas de tamaño pequeño (si-tuación ventajosa para FF frente a nuestro algoritmo). La inevitable presencia(puesto que se trata de aplicaciones del mundo real), de tareas grandes en elconjunto tiene una in�uencia negativa mucho mayor en el rendimiento de FF.La carga de trabajo ejecutada es claramente inferior a la ejecutada por nuestroalgoritmo, dando un peor uso del área, aunque en cualquiera de los dos casosel área de la FPGA no es utilizada de forma intensiva. Además el algoritmoFF utiliza más tiempo para ejecutar una menor carga de trabajo.

Este ejemplo, por supuesto, podría ser ampliado con más experimentos,pero no deja de ser un indicativo de la tendencia que podemos esperar en elcomportamiento de sistemas de computación de propósito general que incluyanuna FPGA como elemento procesador, donde se ejecuten tareas diversas detamaños muy diferentes y tiempos de ejecución dispares. Aun en casos que nose parecen en absoluto a los arti�ciales, nuestro algoritmo sigue mostrando unamayor e�ciencia a la hora de gestionar el DHWR.

6.2. Experimentos con Adaptación Dinámica

En esta sección presentaremos los resultados obtenidos de la ejecución dela versión del algoritmo que realiza la Adaptación Dinámica.

189


Hemos simulado una FPGA de 50*50 CBRs. En algunos casos hay unsolo cambio en las particiones y en otras hay dos y se han probado todaslas combinaciones de cambios en las particiones relevantes (hemos omitido 3P->6P y 6P ->3P por considerar que son situaciones bastante excepcionalesaunque el algoritmo las realizaría si fuera necesario de una vez y sin tener quepasar por la distribución en 4P).

En primer lugar presentamos la tabla 6.7 que resume las características delos benchmark que hemos utilizado para probar la funcionalidad de AdaptaciónDinámica y comparar la e�ciencia de las dos versiones del algoritmo y con elalgoritmo FF.

Tabla 6.7: Características de los benchmark para Adaptación Dinámica

Lote α a (%A) β δ γ Tipo No tareas CambiosAD1 0,69 13,88 0,49 0,32 0,19 Lp 104 4P ->6PAD2 0,58 14,16 0,49 0,30 0,21 Lp 103 4P ->6PAD3 0,62 12,36 0,50 0,25 0,25 Lp 96 4P ->6PAD4 0,69 28,75 0,25 0,25 0,50 Lg 98 4P ->3PAD5 0,75 28,56 0,25 0,25 0,50 Lg 102 4P ->3PAD6 0,92 22,54 0,25 0,50 0,25 Lm 103 3P->4PAD7 0,77 21,03 0,25 0,50 0,25 Lm 94 3P->4PAD8 0,87 22,00 0,25 0,25 0,50 Lm 100 3P ->4PAD9 0,83 17,40 0,39 0,36 0,25 Lp->Lm 161 4P->6P->4P

Los tres primeros lotes de tareas, AD1, AD2 y AD3 corresponden a dife-rentes representaciones de distribuciones de pequeñas, Lp, con distintas cargasde trabajo correspondientes a sistemas equilibrados y frecuencias de llegadade tareas también diferentes. El caso del lote AD3 es el único que muestrauna distribución igual a la teórica mientras que los otros dos muestran ligeras

190


variaciones respecto al mismo. Todas ellas corresponden a distribuciones paralas cuales una distribución en 6 particiones es mucho más adecuada que el casobase. Para probar la e�cacia de la Adaptación Dinámica, hemos supuesto queinicialmente se están ejecutando en un modelo 4P y que el sistema detecta lanecesidad de cambiar a 6P, lo que sucede en algún punto de la ejecución, deahí la información mostrada en la última columna de la tabla.

Los siguientes, AD4 y AD5, corresponden a lotes de tareas grandes, tambiéncon cargas de trabajo equilibradas aunque superiores a los lotes anteriores,cuya ejecución en un modelo 3P es más efectiva que en 4P. Se ha simulado laejecución inicial de estos lotes con 4P y el módulo de Adaptación Dinámicadetecta esta situación y la corrije pasando a un modelo en 6P.

Los tres siguientes lotes, AD6, AD7 y AD8, corresponden a situacionesinversas a la anterior, en que un lote de tareas de tipo mediano (y cuya ejecuciónes más efectiva en 4P que en 3P) se está ejecutando con una distribución 3Py el algoritmo detecta la situación y la corrije pasando a 4P.

Por último el lote de tareas AD9 contiene un mayor número de tareas(y una mayor carga de trabajo que todos los anteriores) porque simula unadistribución de pequeñas que se está ejecutando inicialmente en 4P. El sistemadetecta y corrije la situación pasando a 6P, pero más adelante la distribucióncambia de per�l y pasa a ser de tipo medianas, con lo cual la distribución 6Pno es la adecuada. El sistema detecta este cambio en la distribución y vuelveal modelo de ejecución en 4 particiones.

A continuación presentamos la tabla 6.8 con los resultados obtenidos de eje-cutar estos lotes de tareas. Para estas pruebas hemos realizado tres ejecucionesde cada lote:

191


1. Versión básica del algoritmo (ABP): en la que el lote completo seejecuta con la distribución en 4 particiones para los lotes AD1 a AD4 yAD9 y con la distribución en 3 particiones para AD6 a AD8.

2. Versión con Adaptación Dinámica (AD): en la que se habilita lafuncionalidad de AD y se produce un cambio en la distribución de par-ticiones (dos en el caso de AD9) a lo largo de la ejecución del lote (loscambios que se producen para cada caso están re�ejados en la tabla 6.7).

3. Algoritmo FF: además de comparar la e�ciencia de nuestras dos ver-siones del algoritmo basado en particiones, hemos obtenido también losresultados de la ejecución del algoritmo FF para estos lotes de tareas.

Tabla 6.8: Resultados para los benchmark de AD

R ( %) #u.t. área(%)Lote ABP AD FF ABP AD FF ABP AD FF

AD1 80,57 94,57 73,24 134 133 132 51,85 60,65 50,63AD2 84,82 99,48 76,42 154 152 153 48,00 57,03 47,27AD3 83,89 94,03 75,59 126 125 127 52,20 58,97 49,67AD4 89,62 97,46 64,67 236 234 232 55,24 60,59 45,41AD5 83,88 97,53 62,42 220 223 218 57,21 65,62 46,20AD6 76,91 97,82 65,59 186 185 182 67,49 86,30 59,34AD7 83,96 97,53 69,25 195 193 190 61,79 72,51 54,80AD8 75,93 97,68 55,43 179 178 177 64,90 83,95 55,43AD9 83,83 92,90 59,83 218 218 218 70,15 77,73 52,57

En todos los casos la versión del algoritmo con Adaptación Dinámica consi-gue un rendimiento mayor que el algoritmo sin esta funcionalidad. Además esdestacable que con la Adaptación Dinámica se consigue ejecutar más del 90%

192


de la carga de trabajo asignada al sistema. La �gura 6.2 nos muestra la com-parativa de rendimiento de la versión básica (ABP), la versión con adaptacióndinámica (AD) y FF.

Figura 6.2: Comparativa de rendimientos

La mejora de rendimiento de la versión con AD frente al algoritmo sin ellaes bastante variable, como se explicó en detalle en el capítulo 4, ya que dependede las tareas que se están ejecutando en el momento de tomar la decisión decambiar la distribución en las particiones, así como de los tiempos máximosde ejecución de las tareas que están esperando en las colas en ese momento, delas siguientes tareas que vayan llegando y de la duración de los cambios en lasdistribuciones (cuanto más tiempo permanezca estable un tipo de distribucióndespués de realizar el cambio mayor será la mejora en el rendimiento que seobtiene).

La mejora de rendimiento con la funcionalidad de AD varía desde el 8%en el peor de los casos para el lote AD4, porque la versión básica sin AD ya

193


presenta un rendimiento bastante alto, cercano al 90%, o superior al 20% paralos lotes AD6 y AD8 que son los que menor rendimiento obtienen con la versiónbásica. La �gura 6.3 nos muestra el incremento en el rendimiento de nuestroalgoritmo cuando se utiliza la Adaptación Dinámica para los lotes de tareaspresentados.

Figura 6.3: Mejora del Rendimiento con Adaptación Dinámica

6.2.1. Conclusiones del análisis de los resultados para

benchmark de AD

De las pruebas realizadas y cuyos resultados se muestran en la tabla 6.8podemos sacar las siguientes conclusiones respecto a la funcionalidad de Adap-tación Dinámica:

1. Incluso sin la funcionalidad de Adaptación Dinámica y utilizando unadistribución en particiones que no es la más adecuada para las caracte-rísticas de un conjunto de tareas, nuestro algoritmo presenta un mejorrendimiento que el algoritmo FF, aunque la diferencia en el rendimiento

194


es algo menor que para los otros benchmark con los que se han realizadolas pruebas de las secciones anteriores.

2. La funcionalidad de Adaptación Dinámica supera en rendimiento a laversión básica del algoritmo y garantiza la ejecución de prácticamente latotalidad de la carga de trabajo (rendimiento superior al 90%). Podemosdecir por tanto que nuestro algoritmo en su versión completa, es decir,con la capacidad de adaptarse dinámicamente es claramente mejor que elalgoritmo FF para cualquier situación que pueda presentarse a lo largode la ejecución.

3. La funcionalidad de Adaptación Dinámica dota a nuestro algoritmo deuna estabilidad de rendimiento de la que carece la versión básica, ya queproporciona la �exibilidad necesaria para ajustar la distribución en par-ticiones a cualquier situación y garantiza la ejecución de prácticamentecualquier carga de trabajo, sea cual sea su comportamiento.

195

Capítulo 7

Conclusiones y trabajo futuro

7.1. Conclusiones

De todo lo expuesto en este trabajo de investigación podemos obtener al-gunas conclusiones acerca de los objetivos alcanzados a través del diseño denuestro entorno dinámico para la gestión de DHWR basado en la división deuna FPGA en particiones de diferente tamaño.

La primera de ellas es que con algoritmos sencillos y fáciles de im-

plementar como los presentados en el capítulo 3, ambos de complejidad

constante se puede igualar e incluso mejorar sustancialmente la e�-

ciencia a la hora de gestionar el dispositivo respecto a algoritmos complejosavariciosos en uso de área como por ejemplo FF. Estos algoritmos utilizanuna estructura de datos muy sencilla para representar el área libre en laFPGA y realizan unos sencillos y rápidos cálculos tanto para asignar unaubicación a cada nueva tarea como para examinar la adecuación de la divisiónen particiones y decidir si es necesario realizar un cambio y cuál debe ser dicho

197

Capítulo 7. Conclusiones y trabajo futuro

cambio.Un aspecto muy importante de nuestros algoritmos de complejidad cons-

tante es que están basados en las posibilidades reales de la tecnología

existente, como se explica en detalle en el apéndice A y que ha sido imple-mentado sobre una Virtex-2 XCV2P30, como se detalla en el apéndice B.

Además nuestro algoritmo de selección de una ubicación presenta una ven-taja importante frente a los otros algoritmos complejos y es el hecho de queen el momento de llegada de cada nueva tarea se puede calcular con ra-

pidez y exactitud el tiempo de espera para dicha tarea. En el caso de

que tenga que ser rechazada, esta información se comunica de forma

inmediata al resto del SO y no es necesario esperar a la expiración de sutiempo máximo como ocurre con el uso de algoritmos complejos, retrasandoasí la comunicación de rechazo de tarea, lo que limita las posibilidades para sure-plani�cación.

El rendimiento de la versión básica del algoritmo es superior al de

FF para cualquier conjunto de tareas donde existan tareas de tamaño grande,y la limitación de uso de área debido a la división en particiones solamente

resulta menos e�ciente en casos extremos en que todas las tareas seande tamaño pequeño y con una frecuencia de llegada alta. En los resultadospresentados se observa también que el algoritmo básico es menos sensible alorden de llegada de tareas y presenta un mejor rendimiento en situaciones desobrecarga del sistema (responde mucho mejor a los aumentos en la frecuenciade llegada de tareas). Además puede absorber sin perjuicio de su rendimientopicos de tareas de tamaño pequeño que puedan presentarse a lo largo de laejecución.

198

Conclusiones 7.1

La funcionalidad de Adaptación Dinámica añade una considerable

mejora al rendimiento del algoritmo básico, hasta el punto de que permi-te garantizar la ejecución de más del 90% de la carga de trabajo paraun amplio rango de tipos de distribuciones de tareas y siempre que el sistemano esté sobrecargado. Como ya se ha comentado, existe una excepción, que esel caso en que todas las tareas a ejecutar sean de tamaño pequeño y con unafrecuencia de llegada alta. El rendimiento del algoritmo aumenta una

media del 15% con respecto a la versión básica, como se demostró en laspruebas presentadas en el capítulo 6.

Este dato es muy signi�cativo si tenemos en cuenta que la complejidad delalgoritmo que examina la adecuación de la distribución de las particiones ala carga de trabajo y toma las decisiones acerca de los cambios a realizar estambién de complejidad constante.

Además, y gracias a una estratégica situación de los accesos al bus

de comunicaciones, se evita su recon�guración al realizar un cambio enlas particiones, lo que elimina la penalización temporal de realizar el

cambio.Otro aspecto también muy importante es la utilización de las tablas de

correspondencias de particiones, que permiten realizar el cambio de par-ticiones de forma gradual yminimizar el coste en volumen de trabajo

rechazado asociado a dichos cambios.Resumiendo todo lo expuesto podemos concluir que una división del

área de la FPGA en particiones, siempre que se realice de forma

dinámica, permite encontrar de manera rápida y e�ciente una ubi-

cación para la ejecución de tareas y garantiza la ejecución de prácti-

199

Capítulo 7. Conclusiones y trabajo futuro

camente la totalidad de cualquier carga de trabajo asignada para su

ejecución HW, implementando de forma sencilla, realista y e�caz la

multitarea HW sobre DHWR.

7.2. Trabajo futuro

Como líneas de investigación que se derivan del presente trabajo mencio-naremos tres:

1. Incluir distribuciones con mayor número de particiones: puestoque las capacidades de las FPGAs van en aumento, parece evidente queuna división del área en 6 particiones puede resultar insu�ciente en al-gunos casos y que sería conveniente incluir en el entorno el estudio de ladivisión de la FPGA en un número mayor de particiones. Esto permiti-ría ejecutar un mayor número de tareas simultáneamente aunque planteanuevos problemas a la hora de gestionar las comunicaciones entre tareasy la entrada / salida de datos.

2. Re�nar el estudio en tiempo real incluyendo los parámetros β, δ y γ

en la observación del sistema, para que la decisión de realizar un cambiono se re�eje únicamente en el número de particiones sino también en lostamaños de dichas particiones. Se podrían así manejar distribuciones enparticiones con el mismo número de particiones pero diferentes tamaños.Por ejemplo, si todas las tareas de una carga de trabajo tienen tamañosinferiores al 25% pero superiores al 10%, lo más conveniente sería dividirel área de la FPGA en 4 particiones de igual tamaño.

200

Trabajo futuro 7.2

3. Implementación de un prototipo 2D: aunque ya se implementó ensu momento un prototipo en una FPGA de la familia Virtex-2, se tratabade una adaptación del entorno propuesto a 1D. Puesto que recientementehan aparecido en el mercado FPGAs que se pueden recon�gurar en 2D,sería interesante implementar el algoritmo en una de ellas: posiblementela Virtex-5.

201

Apéndice A

Modelo de recon�guración parcial

A.1. Recon�guración parcial en 2D

Las FPGAs más recientes de Xilinx, desde la Virtex-4, tienen un modelode recon�guración parcial dinámica muy similar. Ambas son recon�gurablesparcialmente en 2D.

Las FPGAs se con�guran a través de un conjunto de bits o mapa de bits decon�guración. Este mapa de bits contiene comandos y datos de con�guración.Los bits se agrupan en frames. Un frame es la mínima cantidad de informaciónque se puede leer o escribir en la FPGA y cada uno de ellos con�gura una partede la FPGA. Su tamaño determina por tanto la mínima porción de FPGArecon�gurable dinámicamente.

La unidad mínima básica recon�gurable en las Virtex 4 es un frame de 16CLBs de altura y una columna de ancho. De esta forma se pueden recon�guraráreas de la FPGA de un número múltiplo de 16 CLBs de alto y varias columnasde ancho. Esto quiere decir que nuestro modelo de gestión del área de la FPGA

203

Capítulo A. Modelo de recon�guración parcial

es idóneo para la tecnología actual.Cada frame está compuesto por 41 palabras y lleva asociada una dirección

de 32 bits que lo identi�ca dentro de la FPGA. De estos bits, hay uno queindica si la zona a con�gurar está en la parte superior (top) o inferior (bottom)de la FPGA. Las columnas se numeran de izquierda a derecha, mientras quelas �las se numeran a partir de la �la central de la FPGA, en imagen especularcomo muestra la �gura A.1. Además la dirección del frame contiene informaciónacerca del tipo de bloque, y la �la y la columna donde empieza el frame.

T o p

16CLB

16CLB16C

LB

B o tto m

R o w 0

R o w 0

R o w N

R o w N

F ra m e s

C o l 0 … . C o l N

16 CLB

Figura A.1: Numeración de �las y columnas en la Virtex-4

Existen dos registros de con�guración, uno donde se escribe la direccióndel frame (FAR = frame address register) y otro donde se escribe el contenidodel frame (FDRI = frame data register input).

La recon�guración parcial dinámica se realiza a través de un único interfaz,el ICAP (Internal Con�guration Access Port) que en la actualidad supone el

204

Técnicas de diseño modular A.2

cuello de botella de estos sistemas.

A.2. Técnicas de diseño modular

Inicialmente Xilinx propuso dos técnicas para la recon�guración parcialdinámica [Xil03], una basada en módulos (generalmente llamado diseño mo-dular) y otra basada en diferencias. El método que ha sido utilizado por lamayoría de los investigadores es el diseño modular, y es el que vamos a expli-car a continuación porque es el modelo de recon�guración parcial dinámica enel que se apoya nuestro trabajo.

El método basado en diferencias requiere del diseñador una minuciosa tareade revisión manual y no es por tanto ni popular ni adecuado para aplicacionesde cierta complejidad.

La recon�guración modular divide el área de la FGPA en zonas o áreasque pueden ser estáticas o dinámicas. Las áreas estáticas se recon�guran unasola vez para realizar una determinada tarea (en nuestro caso, partes del S.O)y las áreas dinámicas son las que van a ser recon�guradas con frecuencia (ennuestro caso las particiones para ejecución de tareas).

Los recursos de las tareas que se van a ejecutar en un área no pueden utilizarrecursos de otras áreas, por ejemplo para rutado de señales. Esto permite quese pueda realizar la multitarea hardware ya que asegura que el área destinadaa ejecutar una tarea (partición) estará libre por completo para dicha tarea (locual a su vez garantiza la reubicabilidad de tareas) y además al recon�guraresa parte de la FPGA no inter�ere con el funcionamiento del resto.

La reserva de un área de la FPGA para uso dinámico es fácil de realizar y205


basta con asignar un determinado valor a una variable:

Routing − in−Dynamic− area = 0

La comunicación entre las diferentes áreas se realiza a través de bus macros,situadas en los bordes de las áreas de�nidas. Algunos autores han hecho intere-santes propuestas para implementar buses en el chip capaces de interconectarlas áreas entre sí y con los pines de entrada / salida [BA05], [BMG06].

Las técnicas iniciales propuestas por Xilinx se basaban en la recon�guraciónpor columnas y esto únicamente permitía la recon�guración en 1D.

Algunos autores han publicado ingeniosos trabajos en los cuales presenta-ban la posibilidad de realizar recon�guración parcial dinámica en 2D con lasVirtex-2, como es el caso de [HSKB06] y otros han incluido ya en sus publi-caciones la extensión de la técnica de recon�guración modular para FPGAsrecon�gurables en 2D como la Virtex-4 [SBB+06].

Xilinx �tomó nota� de las ideas propuestas por los autores mencionados enel párrafo anterior y las integró en su primera propuesta de modelo de recon-�guración parcial dinámica, dando nacimiento en marzo de 2006 a su reciente�ujo de diseño EAPR (Early Access Partial Recon�guration), [EAP06], y quepresentaron en una ponencia invitada en el FPL'06, [LBM+06]. Liberado ya delas rígidas restricciones de recon�guración de columnas completas, el EAPRpermite la recon�guración de módulos rectangulares de tamaños arbitrarios.Asimismo Xilinx ha introducido cores de bus macros pre-rutados, gracias alos cuales es posible permitir el paso de señales de rutado de áreas estáticas através de las áreas dinámicas.

206

Tareas reubicables A.3

A.3. Tareas reubicables

Explicaremos ahora cómo se pueden generar tareas reubicables para lasFPGAs de Xilinx de última generación: Virtex-4 y Virtex-5.

La herramienta de desarrollo ISE de Xilinx permite generar un mapa debits parcial, es decir, la asignación de slices y rutado necesarios para realizaruna determinada tarea, constreñidos a un área rectangular (por medio de losarchivos *.ucf) y de ubicación concreta dentro del dispositivo. La ubicaciónen el dispositivo viene determinada por una dirección de frame, que marca laposición del primer frame a recon�gurar dentro del dispositivo.

Una vez se conoce la ubicación de�nitiva de la tarea, tenemos que calcularla nueva dirección de frame. Esto supone calcular la nueva columna donde seubicará la tarea. En de�nitiva, la realización de una suma del frame inicial conuna cantidad �ja, que será el número de columnas que separan los accesos albus entre dos particiones contiguas, como se muestra en la �gura A.2.

Si la tarea fue inicialmente compilada para ejecutarse en la partición P0 yse asigna la partición P1, será necesario sumarle la cantidad offset:

nueva = base + offset (A.1)

Sin embargo, si la tarea ha sido compilada inicialmente para ejecutarse enP0 pero se le asigna la partición P2 nos encontramos con dos problemas:

• No basta con sumar un o�set de �la: ya que las particiones P2 yP3 se encuentran en la mitad superior de la FPGA y la numeración de�las es simétrica a partir de la línea central que separa las dos mitades

207


T2

P2

P0 P1

P3

offset

offset

T2

Figura A.2: Reubicación de tarea

de la FPGA.

• La posición de los accesos al bus ya no es correcta: puesto que notendrá acceso a las bus macros tal como están situadas en las particionesP2 y P3.

La solución para este problema consiste en la generación de dos mapas debits diferentes para cada tarea, según la mitad de la FPGA en que se vayan aejecutar, de forma que se opte por la versión de compilación inferior para lasparticiones P0 y P1 y la versión superior para las particiones P2 y P3, segúnse muestra en la �gura A.3.

El coste de esta opción supone un aumento en la memoria necesaria paraalmacenar los mapas de bits de las tareas.

Como es frecuente en los sistemas de computación, nos encontramos anteel dilema tiempo vs. memoria. En este caso consideramos que los perjuicios

208

Tareas reubicables A.3

Figura A.3: Dos compilaciones de la misma tarea

derivados de recon�gurar el bus de comunicaciones superan a los de un mayoruso de memoria, elemento que en la actualidad no representa un sobre-costeexcesivo en ningún sistema.

El problema del acceso al bus se podría resolver también cambiando laubicación de la línea de bus a la que acceden P2 y P3 según la �gura A.4.El bus dejaría de ser periférico y se convertiría en dos líneas paralelas unidasentre sí.

Esta opción deja dos bloques de particiones separadas, lo que limita en granmedida la capacidad de adaptación a diferentes circunstancias, que requierenla unión de particiones o la redistribución del área de ejecución en particionesde diferente tamaño y/o número, obligando en estos casos a recon�gurar elbus.

Consideramos que dado que uno de los cuellos de botella de este tipo desistemas en la actualidad es el tiempo de recon�guración, esta opción por elmomento debe descartarse.

209



P0 P1

P2 P3

Figura A.4: Posible modi�cación de la ubicación del bus

A.4. Bus de comunicaciones

Explicaremos ahora el modelo de bus de comunicaciones en el que se basanuestro trabajo.

Es evidente que resulta imprescindible algún tipo de bus que permita lacomunicación entre tareas y de las tareas con los pines de entrada/ salida dela FPGA.

El bus de comunicaciones consta de los siguientes elementos:

• Líneas de datos: se pueden utilizar las líneas largas de la FPGA

• Bus macros: con�guradas en posiciones �jas, adyacentes a las particio-nes, según muestra la �gura A.5

• Conexión a los pines de e/s: la asignación de pines de e/s se hace deacuerdo con el tamaño de las particiones y su ubicación en la FPGA.

210

Bus de comunicaciones A.4

Para la implementación de un bus de comunicaciones efectivo se ha utili-zado ya en [GMR+08] un bus tipo Wishbone, en un sistema de característicasparecidas al propuesto en esta tesis, por su popularidad y frecuente uso pa-ra conectar cores IP en un chip, independientemente de la tecnología utilizada(FPGA, ASIC etc.). Una descripción detallada de dicho bus se puede encontraren [Her02].

La �gura A.5 muestra el modelo de FPGA utilizado hasta ahora junto almodelo de bus propuesto.

Figura A.5: Modelo de bus Wishbone para nuestro sistema

A.4.1. Resumen bus Wishbone

El bus Wishbone tiene una arquitectura maestro / esclavo y soporta cone-xiones punto a punto, bus compartido, crossabr switch y conexión orientada a�ujo de datos.

211


Cada tarea está identi�cada por una etiqueta. Existe una tabla en un es-pacio de memoria compartida que contiene la relación entre direcciones de lastareas (la dirección de memoria donde está almacenado su mapa de bits), lospuertos de e/s que están asignados a dicha tarea y su etiqueta identi�cativa.

Las tareas y módulos de SO disponen de un interfaz maestro / esclavo,mientras que los periféricos pueden disponer de maestro, esclavo o ambos,según sean sus necesidades. El esquema del bus, adaptado a nuestro entorno,puede verse en la �gura A.6.

maestroesclavoárbitro

Sistema Operativo

maestroesclavo

P0

Bus Whishbone

. . . . . . .

esclavo maestro

maestroesclavo

P1

maestroesclavo

P2

maestroesclavo

P3

PCI VGA TECLADO

esclavo maestro

Figura A.6: Esquema del bus Wishbone

Los interfaces tipo master son los únicos que pueden iniciar una transacciónmientras que los tipo slave sirven para recibir datos. El hecho de que cadatarea disponga de ambos interfaces supone que pueden comunicarse entre sísin necesidad de que intervenga el S.O, lo cual resulta muy e�ciente.

Cada mapa de bits de las tareas debe, por tanto, disponer de un área dedi-cada al Wishbone slave y otra al Wishbone master, en la zona que corresponda

212

Bus de comunicaciones A.4

a las bus macros de�nidas en la FPGA. Estos módulos son idénticos para cadatarea y solamente hay que mezclar el mapa de bits de la tarea en sí con estosmódulos �jos para generar los mapas de bits de las tareas con acceso al bus.

213

Apéndice B

Descripción de la implementación

del prototipo

Figura B.1: Fotografía de la placa XUP (Xilinx)

215

Capítulo B. Descripción de la implementación del prototipo

B.1. Descripción del entorno y herramientas

B.1.1. Descripción del hardware utilizado

El prototipo se ha implementado sobre una placa de Xilinx XUPV2P (Xi-linx University Virtex-II Pro), de la que mencionamos los siguientes elementosutilizados en el prototipo:

• FPGA XCV2P30: La Virtex-II Pro es una FPGA que además de losbloques lógicos e interconexiones programables que caracterizan a todaFPGA, dispone también de dos procesadores PowerPC 405 empotradosjunto a la lógica de la FPGA, multiplicadores de 18x18 bits y variosmódulos de memoria RAM distribuidos por columnas, además de unDCM (digital clock manager).Soporta recon�guración parcial dinámica. Aunque su organización inter-na es 2D, la recon�guración parcial dinámica se realiza en 1D, lo quesigni�ca que la mínima unidad programable dinámicamente es una co-lumna de CLBs. No obstante, existen trabajos de investigación como[SBB+06] donde se permite la recon�guración parcial en 2D.Cada CLB se compone de cuatro slices, cada uno de los cuales a su vezdispone de dos LUTs de cuatro entradas y dos elementos de memoria(�ip-�ops) y elementos de lógica y acarreo.

• Slot para DDR SDRAM: permite conectar hasta 2GB de memoria.

• Conectores RS232 DB9 y VGA: el primero es un puerto serie uti-lizado para conectar la FPGA con el terminal de vídeo. De esta manera

216

Descripción del entorno y herramientas B.1

se puede monitorizar la ejecución del software. El segundo se utiliza pararepresentar la situación de las particiones de la FPGA.

• Reloj de sistema de 100 MHZ

• Controlador System ACE y conector de Compact Flash: uti-lizado para cargar la con�guración de la FPGA y los bitstreams de lastareas a ejecutar en la DDR RAM.

• 4 LEDs: conectados a los pines de entrada/salida de la Virtex-II Pro yutilizados para monitorizar la ejecución de la aplicación.

• 5 pulsadores: conectados también a los pines de e/s de la FPGA, quese utilizan para reiniciar la ejecución de la aplicación.

B.1.2. Herramientas de desarrollo

• Embedded Development Kit de Xilinx (EDK 8.1): Herramientaque incorpora cores de Xilinx necesarios para utilizar algunos dispositivosdel sistema (como los procesadores Power Pc, el controlador de memoriaDDR RAM, etc.) al código C que implementa el algoritmo plani�cadory que se ejecuta en uno de los procesadores del chip. Esta herramientagenera un mapa de bits que será escrito en la memoria Flash y desde ella(a través del chip system ACE) se con�gurará la FPGA y se cargarán losmapas de bits de las tareas a ejecutar en la memoria DDR RAM, de lacual serán leídas durante la ejecución del algoritmo para su con�guracióny ejecución en la FPGA.

• Xilinx Platform Studio (XPS): Interfaz grá�ca del EDK.217


• Impact: es una herramienta de Xilinx Platform Studio que permite des-cargar el bitstream generado con el EDK en la FPGA. Este bitstreamcontiene la con�guración de la FPGA, que incluye todos los dispositivosperiféricos necesarios para el correcto funcionamiento del sistema dise-ñado.

• Xilinx Microprocessor Debugger (XMD): herramienta del EDKque se utiliza para introducir el código del algoritmo en la DDR y permiteinsertar puntos de ruptura en el código para su depuración.

B.1.3. Con�guración de la Virtex II Pro

La FPGA Virtex-II Pro se ha con�gurado con el EDK para disponer de lossiguientes elementos:

• Procesadores: Un procesador Power Pc empotrado en el dispositivo. Elprocesador se sitúa en un área �ja y determinada por los cores de Xilinx.Este dispositivo será el que ejecute el código de la aplicación, cargado enla memoria DDR RAM.

• Área de ejecución de tareas: Para poder implementar la recon�-guración parcial dinámica en una Virtex-II Pro es necesario de�nir deantemano las áreas del dispositivo que serán recon�guradas dinámica-mente, de forma que el resto del hardware pueda ser utilizado para losdemás elementos que componen el sistema. En este caso se de�nen cuatroparticiones en el área de la FPGA para ejecución de las tareas. Se tra-ta de particiones no contiguas debido a la restricción de área disponible

218


(por la presencia del Power Pc) y que se extienden a toda la altura deldispositivo debido a la restricción de recon�guración por columnas. Losanchos de las columnas son 4, 8, 16 y 24, como muestra la �gura B.2.

Figura B.2: Esquema del prototipo

• UART: dispositivo que se implementa en el propio hardware de la FPGAy se utiliza para comunicaciones asíncronas serie de datos entre la FPGAy el terminal.

• LEDS: se incorporan dispositivos que controlan el encendido de losLEDs de la placa, para monitorizar el funcionamiento del sistema.

• Pulsadores: controlan los botones de que dispone la placa, para reini-ciar la ejecución de la aplicación.

219


• Controlador de DDR RAM: se incluye también un controlador dememoria DDR RAM para que el procesador pueda acceder al código dela aplicación y ejecutarlo y para que la aplicación pueda acceder a dichamemoria y leer los bitstreams de las tareas a ejecutar y los cargue en laFPGA.

La Virtex-II Pro dispone de un único interfaz para recon�guración llamadoICAP.

B.1.4. Diseño

El algoritmo se ha implementado en lenguaje de programación C y constade los siguientes archivos, que se corresponden con las unidades funcionales delalgoritmo básico, a excepción de xhwicap-cf.c y de xhwicap-parse.c que sonproporcionados por Xilinx para el adecuado manejo de los bitstreams. Omi-timos los archivos *.h por no considerarlos relevantes a la exposición de laimplementación del algoritmo.

• main.c: Este archivo contiene el cuerpo principal del programa y lasinicializaciones de las variables.

• plani�cador.c: Este módulo examina las tareas que llegan al sistema yles busca una partición en la que quepan (en este caso solamente tieneque comparar el ancho de la tarea con el ancho de las particiones, ya quetodas ocuparán el espacio correspondiente a columnas completas en laFPGA). Les asigna un tiempo de recon�guración, ya que solamente unatarea puede ser recon�gurada a la vez y además es necesario asegurarse

220


de que la partición está vacía y de que la tarea anterior ha terminadode recon�gurarse. Una vez hechas las comprobaciones, les asigna unapartición o bien las rechaza.

• lanzador.c: Este módulo examina las colas para ver si hay tareas plani-�cadas que aún no han sido recon�guradas. En caso de haberlas, buscala siguiente plani�cada para recon�gurar y lee el bitstream de la memoriaDDR RAM y a través de una rutina cuyos parámetros son el puntero ala posición de memoria donde está almacenado el bitstream y el tamañodel bitstream, da la orden al ICAP para recon�gurarla. En este módu-lo se utilizan otras rutinas proporcionadas por Xilinx e incluidas en los�cheros antes mencionados.En el momento en que la ubicación de una tarea se ha seleccionado, segenera su mapa de bits absoluto a partir del código reubicable de la tareay se carga en la FPGA, según el procedimiento explicado en [GMR+08].

• xhwicap-cf.c y xhwicap-parse.c: Contienen la rutina que carga unbitstream parcial desde la Compact Flash a DDR RAM y devuelve el ta-maño del bitstream en palabras de 32 bits: intXHwIcapCF2Mem(Xuint8∗

filename,Xuint32∗baseaddr) y otras funciones proporcionadas por Xi-linx para manejo del ICAP.

221

Bibliografía

[ABF+07] A. Ahmadinia, C. Bobda, S. Fekete, J. Teich, and J. Van derVeen. Optimal Free-Space Management and Routing-ConsciousDynamic Placement for Recon�gurable Devices. IEEE Trans.Comput., 56(5):673�680, 2007.

[ABK+04] A. Ahmadinia, C. Bobda, D. Koch, M. Majer, and J. Teich. TaskScheduling for Heterogeneous Recon�gurable Computers. In Pro-ceedings of the 17th symposium on Integrated circuits and systemdesign, pages 22�27, 2004.

[ABT04] A. Ahmadinia, C. Bobda, and J. Teich. A Dynamic Schedulingand Placement Algorithm for Recon�gurable Hardware. In Pro-ceedings of ARCS'04, pages 125�139, 2004.

[BA05] C. Bobda and A. Ahmadinia. Dynamic Interconnection of Re-con�gurable Modules on Recon�gurable Devices. IEEE Designand Test, 22(5):443�451, 2005.

[BD01] G. Brebner and O. Diessel. Chip-Based Recon�gurable Task Ma-nagement. In Proceedings of the 11th International Conference

223

BIBLIOGRAFÍA

on Field-Programmable Logic and Applications, pages 182�191,London, UK, 2001. Springer-Verlag.

[BdNSSL06] P. S. Brandao do Nascimiento, M. Stelita, J. L. Seixas, and M. E.Lima. Mapping of Image Processing Systems to FPGA Compu-ters Based on Temporal Partitioning and Design Space Explora-tion. In Proceedings of SBCCI'06, pages 50�55, 2006.

[BKS00] K. Bazargan, R. Kastner, and M. Sarrafzadeh. Fast TemplatePlacement for Recon�gurable Computing Systems. IEEE Designand Test - Special Issue on Recon�gurable Computing, January-March 2000, 17(1):68�83, 2000.

[BMG06] C. Bieser and K. D. Müller-Glaser. Rapid Prototyping Design Ac-celeration Using a Novel Merging Methodology for Partial Con-�guration Streams of Xilinx Virtex-II FPGAs. In Proceedingsof IEEE International Workshop on Rapid System Prototyping,pages 193�199, 2006.

[BS99] K. Barzagan and M. Sarrafzadeh. Fast Online Placement forRecon�gurable Computing. In Proceedings of the Seventh An-nual IEEE Symposium on Field-Programmable Custom Compu-ting Machines, page 300, Washington, DC, USA, 1999. IEEEComputer Society.

[BTAS07] S. Bhunia, M. Tabib-Azar, and D. Saab. Ultralow-Power Recon�gurable Computing with Complementary Nano-

224

BIBLIOGRAFÍA

Electromechanical Carbon Nanotube Switches. In Proceedingsof ASP-DAC, pages 86�91, 2007.

[CG05] C. Chit and M. Glesner. An FPGA Implementation of the AES-Rijndael in Previous OCB/ECB Modes of Operation. Microelec-tronics Journal, 36(2):139�146, 2005.

[CH02] K. Compton and S. Hauck. Recon�gurable Computing: a Surveyof Systems and Software. ACM Comput. Surv., 34(2):171�210,2002.

[DE01] O. Diessel and H. ElGindy. On Dynamic Task Scheduling forFPGA-based Systems. International Journal of Foundations ofComputer Science, 12(5):645�669, 2001.

[DEM+00] O. Diessel, H. ElGindy, M. Middendorf, H. Schmeck, and B. Sch-midt. Dynamic Scheduling of Tasks on Partially Recon�gu-rable FPGAs. IEE Computer and Digital Techniques, 2000.,147(3):181�188, 2000.

[Die98] O. Diessel. On Scheduling Dynamic FPGA Recon�gurations - aPartial Rearrangement Approach. PhD thesis, Dpt. of Compu-ter Science and Software Engineering, University of Newcastle,Australia, 1998.

[DP05] K. Danne and M. Platzner. A Heuristic Approach to SchedulePeriodic Real-Time Tasks on Recon�gurable Hardware. In Pro-ceedings of the International Conference on Field Programmable

225

BIBLIOGRAFÍA

Logic and Applications (FPL05), pages 568�573, 24- 26 August2005.

[DW99] O. Diessel and G. Wigley. Opportunities for Operating Sys-tems Research in Recon�gurable Computing. In Technical reportACRC-99-018, Advanced Computing Research Centre, School ofComputer and Information Science, University of South Austra-lia, 1999.

[DWM+05] W. R. Davis, J. Wilson, S. Mick, J. Xu, H. Hua, C. Mineo, A. M.Sule, M. Steer, and P. D. Franzon. Demystifying 3D ICs: thePros and Cons of Going Vertical. Design and Test of Computers,IEEE, 22(6):498�510, Nov.-Dec. 2005.

[EAP06] Xilinx: Early Access Partial Recon�guration User Guide for ISE8.1.01 i, 2006.

[EBTB63] G. Estrin, B. Bussell, R. Turn, and J. Bibb. Parallel Processingin a Restructurable Computer System. IEEE Transactions onElectronic Computers, EC-12(6):747�755, 1963.

[Est02] G. Estrin. Recon�gurable Computer Origins: the UCLA Fixed-plus-variable F+V Structure Computer. IEEE Ann. Hist. Com-put., 24(4):3�9, 2002.

[GMR+08] A. González, H. Mecha, S. Román, D. Mozos, and J. Septién.Synthesis of Relocatable Tasks and Implementation of a TaskCommunication Bus in a General Purpose HW System. In Pro-ceedings of ERSA, pages 307�308, 2008.

226

BIBLIOGRAFÍA

[GP02] J. Geo�rey and C. Pretty. Software De�ned QCIF Simple Pro�leMPEG-4 for Portable Devices using Dynamically Recon�gurableDSP. Comput. Stand. Interfaces, 24(5):453�472, 2002.

[Har01] R. Hartenstein. Coarse Grain Recon�gurable Architecture (Em-bedded Tutorial). In Proceedings of ASP-DAC '01, pages 564�570, New York, NY, USA, 2001. ACM.

[Hau98] S. Hauck. The Roles of FPGAs in Reprogrammable Systems.Proceedings of the IEEE, 86(4):615�638, Apr 1998.

[Her02] R. Herveille. Whishbone B.3 Revision Speci�cation;http://www.opencores.org/projects.cgi/web/wishbone/wishbone,2002.

[HSKB06] M. Hubner, C. Schuck, M. Kuhnle, and J. Becker. New 2-Dimensional Partial Dynamic Recon�guration Techniques forReal-time Adaptive Microelectronic Circuits. In Proceedings ofthe IEEE ISVLSI, page 97, 2006.

[HV04] M. Handa and R. Vemuri. An E�cient Algorithm for FindingEmpty Space for Online FPGA Placement. In Proceedings ofDAC'04, pages 960�965, June 2004.

[JTR+05] M. Janiaut, C. Tanougast, H. Rabah, Y. Berviller, C. Manni-no, and S. Weber. Con�gurable Hardware Implementation of aConceptual Decoder for a Real-time MPEG-2 Analysis. In Pro-ceedings of FPL, pages 386�390, 2005.

227

BIBLIOGRAFÍA

[KCMO06] A. Kinane, A. Casey, V. Muresan, and N. O'Connor. FPGA-based Conformance Testing and System Prototyping of anMPEG-4 SA-DCT Hardware Accelerator. Proceedings of FPL,pages 317�318, 2006.

[KD06] S. Koh and O. Diessel. CommA: A Communications Methodologyfor Dynamic Module Recon�guration in FPGAs. In Proceedingsof the 14th Annual IEEE Symposium on Field-ProgrammableCustom Computing Machines, pages 273�274. IEEE ComputerSociety, 2006.

[KKK+04] H. Kalte, M. Koester, B. Kettelhoit, M. Porrmann, and U. Rüc-kert. A Comparative Study on System Approaches for PartiallyRecon�gurable Architectures. In Proceedings of ERSA'04, pages70�76, 2004.

[KKP06] M. Koester, H. Kalte, and M. Porrmann. Relocation and Defrag-mentation for Heterogeneous Recon�gurable Systems. In Procee-dings of ERSA'06, pages 70�76, 2006.

[KPK05] M. Koester, M. Porrmann, and H. Kalte. Task Placement forHeterogeneous Recon�gurable Architectures. In Proceedings ofFPT'05, pages 43�50, 2005.

[KTR08] I. Kuon, R. Tessier, and J. Rose. FPGA Architecture: Surveyand Challenges. Foundations and Trends in Electronic DesignAutomation, 2(2):135�253, 2008.

228

BIBLIOGRAFÍA

[LBM+06] P. Lysaght, B. Blodget, J. Mason, J. Young, and B. Bridgford.Invited paper: Enhanced architectures, design methodologies andcad tools for dynamic recon�guration of Xilinx FPGAs. In Pro-ceedings of FPL, pages 1�6, Aug. 2006.

[LCH00] Z. Li, K. Compton, and S. Hauck. Con�guration Caching Mana-gement Techniques for Recon�gurable Computing. In Proceedingsof IEEE Symposium on Field-Programmable Custom ComputingMachines, pages 22�36, 2000.

[Leo08] P. H. W. Leong. Recent Trends in FPGA Architectures andApplications. In Proceedings of DELTA 2008, pages 137�141,Jan. 2008.

[LH01] Z. Li and S. Hauck. Con�guration Compression for Virtex FP-GAs. In Proceedings of IEEE Symposium on FCCM '01, pages147�159, 2001.

[MD96] E. Mirsky and A. Dehon. Matrix: A Recon�gurable ComputingArchitecture with Con�gurable Instruction Distribution and De-ployable Resources. In IEEE Symposium on FPGAs for CustomComputing Machines, pages 157�166, 1996.

[Mei03] B. Mei. Exploiting Loop-Level Parallelism on Coarse GrainedRecon�gurable Architectures using Modulo Scheduling. In Pro-ceedings of DATE '03, page 10296, 2003.

229

BIBLIOGRAFÍA

[MLJ98a] P. Merino, J. C. López, and M. Jacome. Designing DynamicallyRecon�gurable Systems: a High Level Approach. In Proceedingsof DCIS '98, pages 458�463, 1998.

[MLJ98b] P. Merino, J. C. López, and M. Jacome. A Hardware OperatingSystem for Dynamic Recon�guration of FPGAs. In Proceedingsof FPL, pages 431�435, 1998.

[MM06] H. Masanori and K. Michitaka. A Multi-Context FPGA Using aFloating-Gate-MOS Functional Pass-Gate and its CAD Environ-ment. In Proceedings of APCCAS, pages 1803�1806, Dec. 2006.

[MTAB07] M. Majer, J. Teich, A. Ahmadinia, and C. Bobda. The Erlan-gen Slot Machine: A Dynamically Recon�gurable FPGA-basedComputer. VLSI Signal Processing Systems, 47(1):15�31, 2007.

[MVVL02] J. Mignolet, S. Vernalde, D. Verkest, and R. Lauwereins. Ena-bling Hardware-software Multitasking on a Recon�gurable Com-puting Platform for Networked Portable Multimedia Appliances.In Proceedings of the International Conference on EngineeringRecon�gurable Systems and Architecture, 2002.

[NB04] J.Ñoguera and R. M. Badía. Power-Performance Trade-O�s forRecon�gurable Computing. In Proceedings of CODES+ISSS '04,pages 116�121, 2004.

[NHCB02] A.Ñayak, M. Haldar, A.Ñ. Choudhary, and P. Banerjee. AccurateArea and Delay Estimators for FPGAs. In Proceedings of DATE,pages 862�869, 2002.

230

BIBLIOGRAFÍA

[OPF06] J. Oliveira, A. Printes, and R.C.S Freire. FPGA Architecture forStatic Background Subtraction in Real-time. In Proceedings ofSBCCI, pages 26�31, 2006.

[Poz06] D. S. Poznanovic. The Emergence of Non-von Neumann Pro-cessors. In Recon�gurable Computing: Architectures and Appli-cations, pages 243�254. SpringerLink, 2006.

[PRMC07] E. Pérez, J. Resano, D. Mozos, and F. Catthoor. Memory Hierar-chy for High-performance and Energyaware Recon�gurable Sys-tems. Computers and Digital Techniques, IET, 1(5):565�571,Sept. 2007.

[RF78] S. S Reddi and E. A. Feustel. A Restructurable Computer Sys-tem. IEEE Trans. Comput., 27(1):1�20, 1978.

[RMC05] J. Resano, D. Mozos, and F. Catthoor. A Hybrid Prefetch Sche-duling Heuristic to Minimize at Run-Time the Recon�gurationOverhead of Dynamically Recon�gurable Hardware. In Procee-dings of DATE '05, pages 106�111, Washington, DC, USA, 2005.IEEE Computer Society.

[RMVC05] J. Resano, D. Mozos, D. Verkest, and F. Catthoor. A Recon�gu-ration Manager for Dynamically Recon�gurable Hardware. IEEEComputers Design and Test, 22(5):452�460, 2005.

[RSÉHB08] F. Rivera, M. Sánchez-Élez, R. Hermida, and N. Bagherzadeh.Scheduling Methodology for Conditional Execution of Kernels

231

BIBLIOGRAFÍA

onto Multicontext Recon�gurable Architectures. Computers andDigital Techniques IET, 2(3):199�213, May 2008.

[SBB+06] P. Sedcole, B. Blodget, T. Becker, J. Anderson, and P. Lysaght.Modular Dynamic Recon�guration in Virtex FPGAs. IEE Com-puters and Digital Techniques, 153(3):157�164, 2006.

[SC01] B. Salefski and L. Caglar. Re-Con�gurable Computing in Wire-less. In Proceedings of DAC'01, pages 178�183, 2001.

[SLM00] H. Simmler, L. Levinson, and R. Manner. Multitasking on FPGACoprocessors. In Proceedings of FPL'00, pages 121�130, 2000.

[SM06] K. Stevens and O. A. Mohamed. Single-chip FPGA Implemen-tation of a Pipelined, Memory-based AES Rijndael EncryptionDesign. In Proceedings from Canadian conference on Electricaland Computer Engineering, pages 1296�1299, 2006.

[SWP04] C. Steiger, H. Walder, and M. Plaztner. Operating Systems forRecon�gurable Embedded Platforms: Online Scheduling of Real-Time Tasks. IEEE Trans. Comput., 53(11):1393�1407, 2004.

[TSMM06] J. Tabero, J. Septién, H. Mecha, and D. Mozos. Task PlacementHeuristic Based on 3D-adjacency and Look-ahead in Recon�gu-rable Systems. In Proceedings of ASP-DAC, pages 396�401, 2006.

[TSMM08] J. Tabero, J. Septién, H. Mecha, and D. Mozos. Allocation Heu-ristics and Defragmentation Measures for Recon�gurable SystemsManagement. Integration, 41(2):281�296, 2008.

232

BIBLIOGRAFÍA

[Und04] K. Underwood. FPGAs vs CPUs: Trends and Peak FloatingPerformance. In Proc. of the Twelfth ACM/SIGDA InternationalSymposium on Field-Programmable Gate Arrays, pages 171�180,2004.

[ver08] IEEE Standard Verilog Hardware Description Language, 2008.http://www.verilog.com/IEEEVerilog.html.

[vhd06] IEEE VHDL Analysis and Standarization Group, 2006.http://www.vhdl.org/vasg.

[WK02] G. Wigley and D. Kearney. The Management of Applicationsfor Recon�gurable Computing using an Operating System. InProceedings of CRPIT '02, pages 73�81, 2002.

[WK07] M. Watanabe and F. Kobayashi. A 0.35 um CMOS 1,632-Gate-Count Zero-Overhead Dynamic Optically Recon�gurable GateArray VLSI. In Proceedings of ASP-DAC '07, pages 124�125,Washington, DC, USA, 2007. IEEE Computer Society.

[WP02] H. Walder and M. Platzner. Non-Preemptive Multitasking onFPGAs: Task Placement and Footprint Transform. In Procee-dings of ERSA'02, pages 24�30, 2002.

[WP03] H. Walder and M. Platzner. Online Scheduling for Block-Partitioned Recon�gurable Devices. In Proceedings of DATE '03,pages 10290�10295, 2003.

233

BIBLIOGRAFÍA

[WSP03] H. Walder, C. Steiger, and M. Platzner. Fast Online Task Pla-cement on FPGAs: Free Space Partitioning and 2D-Hashing. InProceedings of IPDPS '03, page 178.2, 2003.

[Xil03] Xilinx Corp. Two Flows for Partial Recon�guration: ModuleBased or Di�erence Based; Application Note XAPP290, Ver-sion 1.1, 2003. http://www.xilinx.com/support/documentation/-application_notes/xapp290.pdf.

[Xil09] Xilinx: our history http://www.xilinx.com/company/history.htm,2009.

234

Índice de �guras

1.1. DHWR: el camino medio . . . . . . . . . . . . . . . . . . . . . . 31.2. Interconexiones jerárquicas (XilinxTM) . . . . . . . . . . . . . . 91.3. Arquitectura de la Virtex (izda) y la Virtex-E (dcha) (XilinxTM) 111.4. Arquitectura de la Virtex-2 (XilinxTM) . . . . . . . . . . . . . 121.5. Arquitectura de la Virtex-2 Pro (XilinxTM) . . . . . . . . . . . 131.6. Etapas de diseño con FPGAs . . . . . . . . . . . . . . . . . . . 17

2.1. Estructura de árbol propuesta por Diessel . . . . . . . . . . . . 332.2. Grafo de visibilidad propuesto por Diessel . . . . . . . . . . . . 342.3. Organización en MER propuesta por Bazargan . . . . . . . . . . 352.4. Cambios de forma, Walder . . . . . . . . . . . . . . . . . . . . . 372.5. División del área libre en rectángulos: Walder . . . . . . . . . . 372.6. Ahmadinia: IPRs . . . . . . . . . . . . . . . . . . . . . . . . . . 392.7. Ahmadinia: franjas temporales . . . . . . . . . . . . . . . . . . . 412.8. Esquema del entorno propuesto por Tabero . . . . . . . . . . . . 442.9. Gestión del espacio propuesta por Kalte . . . . . . . . . . . . . 452.10. Estructura en escalera propuesta por Handa . . . . . . . . . . . 472.11. Propuesta de Merino . . . . . . . . . . . . . . . . . . . . . . . . 49

235

ÍNDICE DE FIGURAS

2.12. Propuesta de división en bloques de Walder . . . . . . . . . . . 51

3.1. Arquitectura global del sistema . . . . . . . . . . . . . . . . . . 563.2. Modelo de FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3. División de la FPGA . . . . . . . . . . . . . . . . . . . . . . . . 583.4. Máximo tiempo permitido para la terminación de la ejecución

de una tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.5. Rotación de la tarea . . . . . . . . . . . . . . . . . . . . . . . . 613.6. Dos compilaciones de la misma tarea . . . . . . . . . . . . . . . 623.7. Esquema del plani�cador . . . . . . . . . . . . . . . . . . . . . . 633.8. FPGA de 20 * 20 dividida en 4 particiones . . . . . . . . . . . . 693.9. Algoritmo First Fit BL . . . . . . . . . . . . . . . . . . . . . . . 703.10. Ejemplo detallado t=2 . . . . . . . . . . . . . . . . . . . . . . . 723.11. Ejemplo detallado t=8 . . . . . . . . . . . . . . . . . . . . . . . 733.12. Ejemplo detallado t=10 . . . . . . . . . . . . . . . . . . . . . . 743.13. Ejemplo detallado t=11 . . . . . . . . . . . . . . . . . . . . . . 743.14. Ejemplo detallado t=12 . . . . . . . . . . . . . . . . . . . . . . 753.15. Ejemplo detallado t=15 . . . . . . . . . . . . . . . . . . . . . . 753.16. Particiones reales y virtuales en la FPGA . . . . . . . . . . . . . 783.17. Parámetros utilizados para la fusión de particiones . . . . . . . 803.18. Posibilidad de aprovechamiento del hueco . . . . . . . . . . . . . 813.19. Mantenimiento de un solo hueco por cola . . . . . . . . . . . . . 813.20. Acceso al bus en particiones unidas . . . . . . . . . . . . . . . . 82

4.1. Esquema del plani�cador . . . . . . . . . . . . . . . . . . . . . . 884.2. Condiciones ideales de ocupación de una FPGA . . . . . . . . . 90

236

ÍNDICE DE FIGURAS

4.3. Distribución en 4 particiones para una FPGA de 50*50 . . . . . 974.4. Distribuciones espaciales de la carga de trabajo . . . . . . . . . 1094.5. Particiones adecuadas para una distribución de tareas pequeñas

y medianas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224.6. Particiones adecuadas para una distribución de tareas grandes . 1234.7. Particiones adecuadas para una distribución con casi todas las

tareas pequeñas . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244.8. Oscilaciones del valor de Dp en tiempo real I . . . . . . . . . . . 1304.9. Dp para la primera ventana de tareas . . . . . . . . . . . . . . . 1304.10. Dp para la cuarta ventana de tareas . . . . . . . . . . . . . . . . 1314.11. Dp para la última ventana de tareas . . . . . . . . . . . . . . . . 1324.12. Oscilaciones del valor de Dp en tiempo real II . . . . . . . . . . 1364.13. Límites del valor de Dp en tiempo real para determinar cambios 1394.14. Variación de Dp en función de k I . . . . . . . . . . . . . . . . . 1424.15. Variación de α y Dp . . . . . . . . . . . . . . . . . . . . . . . . 150

5.1. Distribuciones en particiones utilizadas . . . . . . . . . . . . . . 1555.2. Ubicación de las bus macros para las distintas distribuciones . . 1575.3. Bus macros válidas para todas las distribuciones . . . . . . . . . 1595.4. Composición del lote utilizado para el ejemplo . . . . . . . . . . 1645.5. Primer tramo de la ejecución: Lpp en 4P . . . . . . . . . . . . . 1665.6. Valores de Dp antes del primer cambio . . . . . . . . . . . . . . 1665.7. Segundo tramo de la ejecución: Lpp en 6P . . . . . . . . . . . . . 1685.8. Tercer tramo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695.9. Valores de Dp en el segundo cambio . . . . . . . . . . . . . . . . 169

237

ÍNDICE DE FIGURAS

5.10. Último tramo de la ejecución: Lm en 4P . . . . . . . . . . . . . 171

6.1. Comparación del Rendimiento de ABP con FF . . . . . . . . . . 1826.2. Comparativa de rendimientos . . . . . . . . . . . . . . . . . . . 1936.3. Mejora del Rendimiento con Adaptación Dinámica . . . . . . . . 194

A.1. Numeración de �las y columnas en la Virtex-4 . . . . . . . . . . 204A.2. Reubicación de tarea . . . . . . . . . . . . . . . . . . . . . . . . 208A.3. Dos compilaciones de la misma tarea . . . . . . . . . . . . . . . 209A.4. Posible modi�cación de la ubicación del bus . . . . . . . . . . . 210A.5. Modelo de bus Wishbone para nuestro sistema . . . . . . . . . . 211A.6. Esquema del bus Wishbone . . . . . . . . . . . . . . . . . . . . 212

B.1. Fotografía de la placa XUP (Xilinx) . . . . . . . . . . . . . . . . 215B.2. Esquema del prototipo . . . . . . . . . . . . . . . . . . . . . . . 219

238

Índice de tablas

1.1. Resumen de la familia Virtex . . . . . . . . . . . . . . . . . . . 14

3.1. Lote de tareas sencillo . . . . . . . . . . . . . . . . . . . . . . . 713.2. Resultados del lote sencillo . . . . . . . . . . . . . . . . . . . . . 763.3. Comparación de la versión básica y con fusión de particiones . . 85

4.1. Resultados para comprobar la validez del parámetro α . . . . . 984.2. Ejecución de diferentes tipos de distribuciones con 4 particiones 1184.3. Cálculo del número de particiones necesario para diferentes dis-

tribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204.4. Ejecución de diferentes tipos de distribuciones con 4 particiones 1214.5. Comparativa 4P - 3P . . . . . . . . . . . . . . . . . . . . . . . . 1254.6. Comparativa 4P - 6P . . . . . . . . . . . . . . . . . . . . . . . . 1274.7. Parte de un lote de tareas ideal . . . . . . . . . . . . . . . . . . 1314.8. Distribuciones y variación de Dp en tiempo real I . . . . . . . . 1344.9. Distribuciones y variación de Dp en tiempo real II . . . . . . . . 1354.10. Distribuciones y variación de Dp en tiempo real IV . . . . . . . 1384.11. Distribuciones y variación de Dp en tiempo real . . . . . . . . . 1394.12. Variación de Dp con k, Lm . . . . . . . . . . . . . . . . . . . . . 143

239

ÍNDICE DE TABLAS

4.13. Variación de Dp con k, Lg . . . . . . . . . . . . . . . . . . . . . 1434.14. Variación de Dp con k, Lpp . . . . . . . . . . . . . . . . . . . . . 1444.15. Desviación de Dp para diferentes tamaños de ventana de tareas 1454.16. Desviación de α para diferentes tamaños de la venta de tareas . 1484.17. Cambios de particiones en función de Dp . . . . . . . . . . . . . 151

5.1. Tabla de correspondencias para 4P . . . . . . . . . . . . . . . . 1615.2. Tabla de correspondencias para 3P . . . . . . . . . . . . . . . . 1615.3. Tabla de correspondencias para 6P . . . . . . . . . . . . . . . . 1625.4. Tabla de ocupación para 4P I . . . . . . . . . . . . . . . . . . . 1625.5. Tabla de ocupación para 3P I . . . . . . . . . . . . . . . . . . . 1625.6. Tabla de ocupación para 6P I . . . . . . . . . . . . . . . . . . . 1635.7. Tabla de ocupación para 4P II . . . . . . . . . . . . . . . . . . . 1635.8. Tabla de ocupación para 3P II . . . . . . . . . . . . . . . . . . . 1635.9. Tabla de ocupación para 6P II . . . . . . . . . . . . . . . . . . . 1645.10. Per�l del lote de tareas con dos cambios de particiones . . . . . 1655.11. Tabla de ocupación para 4P, primer cambio . . . . . . . . . . . 1675.12. Tabla de ocupación para 6P, primer cambio . . . . . . . . . . . 1675.13. Tabla de ocupación para 6P, segundo cambio . . . . . . . . . . . 1705.14. Tabla de ocupación para 4P, segundo cambio . . . . . . . . . . . 1705.15. Comparativa de rendimientos . . . . . . . . . . . . . . . . . . . 171

6.1. Tamaños de particiones . . . . . . . . . . . . . . . . . . . . . . . 1756.2. Características de los benchmark arti�ciales . . . . . . . . . . . 1776.3. Resultados para los benchmark arti�ciales . . . . . . . . . . . . 1816.4. Composición del benchmark sintético . . . . . . . . . . . . . . . 187

240

ÍNDICE DE TABLAS

6.5. Características del benchmark sintético . . . . . . . . . . . . . . 1876.6. Resultados de la ejecución en 4P . . . . . . . . . . . . . . . . . 1886.7. Características de los benchmark para Adaptación Dinámica . . 1906.8. Resultados para los benchmark de AD . . . . . . . . . . . . . . 192

241

entorno para multitarea hardware en dispositivos reconfigurables … · 2014-02-06 · entorno para...

Documents