s´ıntesis de circuitos digitales basada en la generaci´on

UNIVERSITAT JAUME I

Departamento de Ingeniera y Ciencia de los Computadores

Sıntesis de circuitos digitales

basada en la generacion de

funciones incompletas mediante el

paradigma orientado a objetos con

inferencia de tipos.

Tesis Doctoral

Presentada por D. German Leon Navarro

Dirigida por D. Jose Manuel Claver Iborra

y por D. German Fabregat Llueca

Castellon, Noviembre de 2012

Sıntesis de circuitos digitales basada en la

generacion de funciones incompletas

mediante el paradigma orientado a

objetos con inferencia de tipos.

German Leon Navarro

Trabajo realizado bajo la direccion de

D. Jose Manuel Claver Iborra y D. German Fabregat

Llueca y presentado en la Universitat Jaume I

para optar al grado de Doctor en Informatica

Castellon, Noviembre de 2012

A mi familia,

mi fuente de inspiracion.

I

Resumen

El entorno de desarrollo para Arquitecturas Reconfigurables Madeo,sobre el cual se ha desarrollado esta tesis, propone un sistema que per-mite la interrelacion de la implementacion fısica de la arquitectura y eldesarrollo de las aplicaciones, de forma que el diseno se valida evaluandola ejecucion de las aplicaciones sobre un modelo simulado de la arqui-tectura reconfigurable. La metodologıa de la sıntesis de las aplicacionesesta basada en la transformacion de un algoritmo expresado en un len-guaje orientado a objetos en una red de tablas (LUT) que implementanlas operaciones de dicho algoritmo. Este tipo de sıntesis proporciona aldisenador hardware la posibilidad de implementar eficientemente cual-quier funcion u operacion, sin necesidad de tener previamente disponiblesbibliotecas de componentes basicos sintetizados.

En esta tesis, se han realizado aportaciones en los campos de la sınte-sis de alto nivel y la sıntesis logica. Estas proporcionaran a los disenadoresde sistemas hardware la posibilidad de implementar eficientemente algu-nas aplicaciones que necesiten mas precision que la proporcionada por losmetodos clasicos de aproximaciones sucesivas y para aplicaciones que ne-cesiten operadores no incluidos en las bibliotecas del entorno de desarrollo.

Por otra parte se han realizado aportaciones al entorno de Madeo paraaplicaciones de tratamiento de imagenes y mejoras para la utilizacion delentorno como herramienta de investigacion de tecnicas de sıntesis de altonivel de un alto coste computacional.

Agradecimientos

La escritura de esta tesis no hubiera sido posible sin la colaboracionde bastantes personas, quisiera mostrar aquı mi agradecimiento a algunasde ellas. En primer lugar, me gustarıa darle las gracias a mis directores detesis por su ayuda en mi formacion y por su apoyo en los altibajos sufridosen esta tesis. Por otro lado, tengo que mostrar mi agradecimiento por laayuda prestada a los miembros de mi grupo de investigacion HPCA y algrupo Architectures et Systemes de la Universite de Bretagne Occidentale.

La presente tesis ha sido financiada por los fondos FEDER y porel Ministerio de Educacion y Ciencia mediante los proyectos “CSD2006-00046” y “TIN2009-14475- C04”.

III

Indice general

1. Lenguajes y Compiladores para Computacion Reconfigu-rable 1

1.1. Lenguajes y sistemas de descripcion estructural . . . . . . 5

1.2. Lenguajes estandar de descripcion hardware . . . . . . . 12

1.3. Lenguajes de alto nivel para el diseno hardware . . . . . . 18

1.3.1. Lenguajes basados en C . . . . . . . . . . . . . . . 20

1.3.2. Lenguajes orientados a CSP . . . . . . . . . . . . . 21

1.3.3. Lenguajes funcionales . . . . . . . . . . . . . . . . 22

1.3.4. Lenguajes orientados a objetos . . . . . . . . . . . 23

1.3.5. Lenguajes ANSI . . . . . . . . . . . . . . . . . . . 24

1.4. Compiladores de Plataformas Reconfigurables . . . . . . . 26

1.5. Adecuacion de los lenguajes al diseno hardware . . . . . . 30

1.5.1. Paradigmas de programacion para computacion re-configurable . . . . . . . . . . . . . . . . . . . . . . 31

1.5.2. Modelo de paralelismo . . . . . . . . . . . . . . . . 34

1.5.3. Planificacion temporal . . . . . . . . . . . . . . . . 36

1.5.4. Sistemas de tipos . . . . . . . . . . . . . . . . . . 39

1.5.5. Modelo de comunicaciones . . . . . . . . . . . . . . 42

1.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 44

2. Interfaz de entrada y sıntesis funcional del entorno detrabajo Madeo 47

2.1. Madeo: Un entorno de diseno para arquitecturas reconfi-gurables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.1.1. Diseno de la plataforma reconfigurable . . . . . . . 50

2.1.2. Sıntesis de Madeo . . . . . . . . . . . . . . . . . . 53

V

VI INDICE GENERAL

2.1.3. Aplicaciones y aportaciones realizadas en Madeo . 55

2.2. Sintetizador funcional de Madeo . . . . . . . . . . . . . . 582.2.1. Compilador . . . . . . . . . . . . . . . . . . . . . . 58

2.2.2. Constructores SIMD: Descripcion basada en bucles 60

2.2.3. Descripcion jerarquica . . . . . . . . . . . . . . . . 65

2.3. Verificacion y obtencion de resultados . . . . . . . . . . . 70

2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 77

3. Inferencia de tipos 79

3.1. Tipos Abstractos de Datos, Polimorfismo e Inferencia deTipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.2. Inferencia de tipos en los DSP . . . . . . . . . . . . . . . . 81

3.3. Sistema de tipos en MADEO . . . . . . . . . . . . . . . . 833.3.1. Inferencia de tipos en MADEO . . . . . . . . . . . 83

3.3.2. Tipos de Datos de MADEO . . . . . . . . . . . . . 84

3.4. Aplicacion de la inferencia de tipos a nivel de sıntesis . . . 85

3.5. Notacion y terminologıa . . . . . . . . . . . . . . . . . . . 88

3.6. Propagacion hacia delante . . . . . . . . . . . . . . . . . . 90

3.6.1. Inferencia cıclica . . . . . . . . . . . . . . . . . . . 93

3.7. Propagacion hacia atras . . . . . . . . . . . . . . . . . . . 983.7.1. Operadores unarios finales . . . . . . . . . . . . . . 103

3.7.2. Operadores unarios no finales . . . . . . . . . . . . 106

3.7.3. Operadores n-arios finales . . . . . . . . . . . . . 108

3.7.4. Operadores n-arios no finales . . . . . . . . . . . . 111

3.7.5. Bifurcacion . . . . . . . . . . . . . . . . . . . . . . 114

3.7.6. Reduccion de los dominios . . . . . . . . . . . . . . 119

3.7.7. Transformacion de operadores . . . . . . . . . . . . 1203.7.8. Inferencia hacia atras con agrupamiento de opera-

dores . . . . . . . . . . . . . . . . . . . . . . . . . . 124

3.8. Inferencia cuantificada de tipos . . . . . . . . . . . . . . . 125

3.9. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 128

4. Flujo de diseno de bajo nivel 129

4.1. Sıntesis de alto nivel . . . . . . . . . . . . . . . . . . . . . 129

4.1.1. Simplificacion del grafo . . . . . . . . . . . . . . . 130

4.1.2. Transformacion de los operadores a LUT . . . . . 131

4.2. Sıntesis logica . . . . . . . . . . . . . . . . . . . . . . . . . 133

4.2.1. Descripcion de las tablas de verdad para el sinteti-zador logico . . . . . . . . . . . . . . . . . . . . . . 137

INDICE GENERAL VII

4.3. Implementacion final . . . . . . . . . . . . . . . . . . . . . 1394.3.1. Integracion con entornos EDA/ESL comerciales . . 145

4.4. Entorno del sintetizador de Madeo . . . . . . . . . . . . . 1454.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 152

5. Resultados 1555.1. Caracterısticas del banco de pruebas . . . . . . . . . . . . 1565.2. Estudio de las tecnicas basicas . . . . . . . . . . . . . . . 158

5.2.1. Resıntesis . . . . . . . . . . . . . . . . . . . . . . . 1585.2.2. Estudio del uso de bibliotecas . . . . . . . . . . . . 161

5.3. Estudio de la inferencia de tipos de hacia atras . . . . . . 1645.3.1. Consumo dinamico de potencia . . . . . . . . . . . 1675.3.2. Comparacion con implementaciones de VHDL . . . 1705.3.3. Estudio de la reduccion de variables binarias . . . 173

5.4. Tiempo de ejecucion de la sıntesis funcional . . . . . . . . 1745.5. Aplicacion de procesamiento de imagenes en tiempo real

como ejemplo de integracion con entornos ESL . . . . . . 176

6. Conclusiones y lıneas abiertas de investigacion 1836.1. Conclusion y aportaciones . . . . . . . . . . . . . . . . . . 1836.2. Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . 1866.3. Publicaciones de los resultados de la tesis . . . . . . . . . 186

6.3.1. Publicaciones de aplicaciones utilizando entornos ESL1886.3.2. Congresos Internacionales . . . . . . . . . . . . . . 188

6.4. Lıneas abiertas de investigacion . . . . . . . . . . . . . . . 190

Bibliografıa 191

VIII INDICE GENERAL

Indice de figuras

1.1. Ciclo de codiseno. . . . . . . . . . . . . . . . . . . . . . . 31.2. Evolucion en el diseno de sistemas reconfigurable. . . . . . 51.3. Diseno en Pebble de un sumador segmentado de 4 bits y 4

etapas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4. Ejemplo de un diseno grafico con PixelStream. . . . . . . 111.5. Esquema de una descripcion RTL. . . . . . . . . . . . . . 131.6. Comparacion de tiempos de simulacion entre una descrip-

cion RTL y una descripcion comportamental (TLM) delalgoritmo de la burbuja. . . . . . . . . . . . . . . . . . . . 16

1.7. Comparacion de eficiencia y facilidad de uso entre lengua-jes comportamentales (Impulse C,Mitrion), estructurales(DSPlogic) y RTL (VHDL). . . . . . . . . . . . . . . . . . 18

1.8. Ciclo de diseno del procesador Mitrion. . . . . . . . . . . . 30

2.1. Esquema del conjunto de herramientas de Madeo . . . . . 492.2. Doble metodologıa MDA para modelar e implementar una

arquitectura reconfigurable. . . . . . . . . . . . . . . . . . 522.3. Flujo de procesos de la sıntesis de Madeo. . . . . . . . . . 532.4. AST de una suma de vector. . . . . . . . . . . . . . . . . 602.5. Especificacion y grafo obtenido al aplicar el metodo ex-

pand: al producto escalar de dos vectores. . . . . . . . . . 612.6. Reduccion de profundidad de un grafo de operadores. . . 622.7. Grafo obtenido al aplicar el metodo do: al producto escalar. 642.8. Sumador con propagacion de acarreo expresado en Madeo. 672.9. Esquema de la descomposicion multipartito usada. Adap-

tacion de la tecnica bipartita para numeros enteros. . . . 682.10. Funcion sqrt expresada en Madeo. . . . . . . . . . . . . . 69

IX

X INDICE DE FIGURAS

2.11. Funcion alfa definida para la clase Signed en Smalltalk. . . 70

2.12. Flujo de verificacion y comprobacion de resultados. . . . . 72

2.13. Funciones de interfaz generada para el producto escalaraplicando expand:. . . . . . . . . . . . . . . . . . . . . . . 73

2.14. Codigo Smalltalk generado para el producto escalar apli-cando expand:. . . . . . . . . . . . . . . . . . . . . . . . . 74

3.1. Filtro Prewitt. . . . . . . . . . . . . . . . . . . . . . . . . 84

3.2. Vision simplificada del flujo de diseno. . . . . . . . . . . . 86

3.3. GFD de un multiplicador de dos bits. . . . . . . . . . . . 89

3.4. Esquema basico de un GFD. . . . . . . . . . . . . . . . . . 91

3.5. Descomposicion de la expresion s = ((a%4) + (b%4))%2en un red de LUT. Se describe el conjunto de datos deentrada para cada operador. . . . . . . . . . . . . . . . . . 92

3.6. Programa en Smalltalk y grafo de flujo de datos correspon-diente al ejemplo de la suma de un vector. . . . . . . . . . 95

3.7. Grafo de flujo de Datos de la expresion (((a%4)+(b%4))%2)con anotaciones de la inferencia de tipos hacia delante yhacia atras. . . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.8. Diagrama de Venn donde se representan los particionadospara un operador final. . . . . . . . . . . . . . . . . . . . . 103

3.9. Diagrama conmutativo correspondiente a la descomposi-cion canonica de la funcion f . . . . . . . . . . . . . . . . . 104

3.10. Diagrama conmutativo correspondiente a las descomposi-ciones canonicas de las funciones correspondientes a unoperador no final. . . . . . . . . . . . . . . . . . . . . . . . 107

3.11. Diagramas de Venn donde se visualiza los particionadoscorrespondiente a un operador binario final. . . . . . . . . 112

3.12. Grafo de Flujo de Datos con bifurcacion para las expresio-nes sal1 = (ax%6)/3 y sal2 = (ax%6)/2. . . . . . . . . . 116

3.13. Digrama de Venn de la interesccion de los conjuntos co-cientes para la bifurcacion del GFD de las expresionessal1 = (ax%6)/3 y sal2 = (ax%6)/2. . . . . . . . . . . . 117

3.14. Diagrama conmutativo correspondiente a la descomposi-cion canonica para la obtencion de la LUT. . . . . . . . . 120

3.15. Transformaciones de los conjuntos producidas por el pro-ceso de inferencia hacia atras. . . . . . . . . . . . . . . . . 121

3.16. Red de LUT correspondientes al GFD de la tabla 3.7. . . 124

INDICE DE FIGURAS XI

4.1. Fusion de operadores . . . . . . . . . . . . . . . . . . . . . 1324.2. Efecto de la resıntesis logica para funciones incompletas en

el caso de la multiplicacion de 4 bits . . . . . . . . . . . . 135

4.3. Efecto de la resıntesis logica para funciones incompletas enel caso del resto de la division entera . . . . . . . . . . . . 136

4.4. Ejemplo de un conversion de una LUT en tablas de verdady la correspondiente ejecucion de tareas para realizar lasıntesis logica. . . . . . . . . . . . . . . . . . . . . . . . . . 137

4.5. Flujo completo de diseno de Madeo. . . . . . . . . . . . . 146

4.6. Diagrama de actividad del flujo de diseno de Madeo . . . 148

4.7. Interfaz grafica de Madeo . . . . . . . . . . . . . . . . . . 151

5.1. Comparacion del area (Slices) entre la inferencia de tipode Madeo y la optimizacion de longitud de palabra. . . . . 159

5.2. Comparacion de tiempos (ns) entre la inferencia de tiposde Madeo y la optimizacion de longitud de palabra. . . . . 160

5.3. Area (Slices) de las tres opciones en el uso de bibliotecas. 162

5.4. Tiempo de propagacion (ns) de las opciones SoloLut y Bi-bAltoNivel en el uso de bibliotecas. . . . . . . . . . . . . . 163

5.5. Comparacion de prestaciones del algoritmo “Prewitt” entreinferencia semicompleta y completa. . . . . . . . . . . . . 166

5.6. Comparacion de prestaciones del algoritmo “PrewittBin”entre inferencia semicompleta y completa. . . . . . . . . . 168

5.7. Resultados de area (Slices) sin utilizar ninguna bibliotecade componentes. . . . . . . . . . . . . . . . . . . . . . . . 169

5.8. Resultados de consumo dinamico de potencia (mW). . . . 1705.9. Resultados de la simulacion de la actividad de conmutacion.171

5.10. Comparacion de prestaciones entre las implementacionesde VHDL y de Madeo. . . . . . . . . . . . . . . . . . . . . 172

5.11. Comparacion de area (Slices) sin reduccion de variablesbinarias y con reduccion de variables binarias. . . . . . . . 173

5.12. Porcentaje del tiempo de ejecucion de la sıntesis funcionalde las diferentes etapas. . . . . . . . . . . . . . . . . . . . 175

5.13. Diagrama de bloque de la aplicacion para el agarre de unapieza. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

5.14. Tipo de datos en coma fija de entrada inferidos en funcionde tolerancia de la salida. . . . . . . . . . . . . . . . . . . 178

5.15. Area (Slices) y tiempo (ns) de la implementacion de Madeode la arcotangente en funcion de tipo de datos de la entrada.179

XII INDICE DE FIGURAS

5.16. Area (Slices) y tiempo (ns) para la implementacion seg-mentada de la arcontangente. . . . . . . . . . . . . . . . . 179

5.17. Error de precision de las implementaciones de la arcotan-gente de Madeo y Cordic. . . . . . . . . . . . . . . . . . . 181

Indice de tablas

1.1. Clasificacion de lenguajes y sistemas de diseno hardware. 4

1.2. Comparacion de lenguajes segun diversas propiedades. Ca-da propiedad esta calificada con los siguientes terminos:“Sı ”indica que tiene la propiedad totalmente; “Casi” in-dica que hay alguna limitacion; “Poco ”indica que la pro-piedad esta muy limitada; “No ” indica que no se tiene esapropiedad. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.3. Clasificacion de lenguajes dependiendo del sistema de tem-porizacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

1.4. Ejemplos de Sistema de tipos. . . . . . . . . . . . . . . . . 40

1.5. Clasificacion de lenguajes dependiendo del sistema de tem-porizacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.1. Asociacion de constructores con procedimientos. . . . . . 59

3.1. Proceso de propagacion hacia delante para el ejemplo de la ex-

presion polinomica s = (a%4 + b%4)%2). . . . . . . . . . . . 923.2. Estudio de los posibles valores de las entradas y salidas

para cada iteracion del grafo 3.6(b). . . . . . . . . . . . . 963.3. Producto cartesiano EA+B

iz × EA+Bdr donde se representan

los valores incluidos en la LUT optima y la LUT calculada. 97

3.4. Proceso de propagacion hacia atras para el ejemplo s = (a%4+

b%4)%2). . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.5. Todas las posibles salidas y sus correspondientes clases de

equivalencias del operador AxB. . . . . . . . . . . . . . . 113

3.6. Calculo de particionado basado en una interseccion de dosrelaciones de equivalencia. . . . . . . . . . . . . . . . . . . 118

XIII

XIV INDICE DE TABLAS

3.7. Proceso de propagacion hacia atras para el ejemplo s =(a%4 + b%4)%2). . . . . . . . . . . . . . . . . . . . . . . 123

3.8. LUT correspondiente al GFD de la Figura 3.16. . . . . . . 123

5.1. Error y desviacion tıpica de variante Muller y Simplif. . . 1645.2. Comparacion entre las implementaciones basado en Madeo

y Cordic. . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

CAPITULO 1Lenguajes y Compiladores

para ComputacionReconfigurable

La aparicion del procesador proporciono un recurso de proposito ge-neral que oculta los aspectos arquitectonicos al disenador de sistemasinformatico. El disenador paso a llamarse programador, ya que disenarsistemas informaticos se convirtio en la elaboracion de una secuencia deinstrucciones interpretada por el procesador. Para incrementar la produc-tividad, mejorar el mantenimiento y facilitar la programacion en generalaparecieron los lenguajes de programacion. Comparandolos con el disenoclasico de hardware, estos proporcionan mas abstraccion y una reduccionconsiderable del tiempo de diseno. En cambio, los resultados del disenohardware son mas eficientes en las prestaciones finales del sistema (tiempode ejecucion, area, consumo). No obstante, la gran evolucion tecnologicaha mejorado continuamente los disenos de los procesadores, haciendolosmas pequenos y rapidos, tal como enuncia la conocida Ley de Moore,aunque hace unos anos solo se mejora la escala de integracion. Esto hahecho que la utilizacion de la programacion sea la solucion mas eficienteen muchos dominios de aplicaciones e incluso en muchos de ellos es launica solucion.

1

2 Capıtulo 1 Lenguajes y Compiladores para Computaci on Reconfigurable

La aparicion de los dispositivos reconfigurables en los anos 80 im-pulso el diseno de los circuitos integrados de aplicacion especıfica (ASIC).El prototipado fue la principal aplicacion de los dispositivos reconfigura-bles de esta epoca. Un prototipo permite evaluar, en un corto espaciode tiempo y a un bajo coste el funcionamiento, algunas caracterısticasdel diseno final. Esto permitıa realizar sucesivos refinamientos de los di-senos para depurarlos que anteriormente no se podıan realizar debido alalto coste de produccion. De esta forma se reducıan espectacularmentelos costes no recurrentes de diseno (NRE) en la produccion. A finales delos ochenta, dada la amplia difusion de las FPGA, surgieron las arqui-tecturas de computacion reconfigurable. Estas arquitecturas proponen unsistema hıbrido de procesadores y FPGA. Las funciones de la FPGA sonpoder reconfigurar la parte del sistema que necesita mayor velocidad decalculo, y la funcion del procesador es realizar las tareas menos crıticas yla reconfiguracion de la FPGA.

La primera etapa del ciclo de diseno de aplicaciones de computacionreconfigurables consiste en la division en tareas software y hardware (verfigura 1.1). Las tareas software seran ejecutadas en algun procesador deproposito general y las tareas hardware se realizaran en una unidad deproposito especıfico. Esta division es realizada manualmente por el di-senador, aunque puede estar guiado por herramientas de evaluacion yanalisis del rendimiento. La parte software sigue el ciclo clasico de desa-rrollo de programacion. La parte hardware sigue el ciclo heredado de lasherramientas de fabricacion de ASIC, donde hay dos subciclos. El primersubciclo es la verificacion funcional, que es independiente de donde se vaa implementar el circuito. El segundo subciclo consiste en la implementa-cion concreta del circuito, que en este caso concreto genera la informacionde configuracion de la FPGA, lo que se denomina el bitstream. Este pasotambien se llama sıntesis y consiste en el mapeo, emplazamiento y rutadodel circuito sobre la FPGA.

A lo largo de la historia, todas estas tareas se han simplificado y auto-matizado para mejorar la productividad de estos disenos. Hay que teneren cuenta que detras de estos disenos hay una industria muy competitiva,donde el tiempo de salida al mercado de sus productos (time to market)es crıtico en un mundo tecnologicamente muy cambiante.

3

Figura 1.1: Ciclo de codiseno.

En este capıtulo se realiza un estudio actual de los lenguajes y siste-mas de diseno hardware (ver el resumen de la tabla 1.1) donde se anali-zaran tanto los lenguajes de descripcion hardware como los lenguajes parasistemas hıbridos hardware/software. El desarrollo del capıtulo sigue laevolucion que muestra la figura 1.2. En la seccion 1.1 se veran los en-tornos de desarrollo de los anos ochenta. Estos se basan en descripcionesestructurales cuyos elementos basicos son componentes de pequena (SSI)y gran (LSI) escala de integracion, concretamente desde puertas logicas ybiestables, hasta microprocesadores pequenos. En la seccion 1.2, se veran


los lenguajes de descripcion hardware donde se incorpora la descripcioncomportamental. La descripcion de estos lenguajes es a nivel de transfe-rencia de registro, lo que permite un gran incremento de abstraccion. Alprincipio del siglo, surgieron los “system on chip” (SoC), que permitenconcebir todo el sistema en un unico chip. El planteamiento es unir eldiseno software y hardware en un unico proyecto y utilizar un unico en-torno de desarrollo, dando lugar a la aparicion de las herramientas ESL(Electronic System Level). En la seccion 1.3 se describe los diferenteslenguajes de hardware basados en los lenguajes de programacion de altonivel. En la seccion 1.4, se describen algunas plataformas reconfigurablesy sus lenguajes asociados para analizar el particionado entre tareas soft-ware y hardware, ası como la comunicacion entre las mismas. Tambiense describiran lenguajes y metodologıas para computacion reconfigurableindependientes de la arquitectura reconfigurable.

General ASIC Codiseno HW/SW

Estructural PixelStream EDKDSP Builder SoPC Builder

System Generator RcToolBoxLenguajes Funcionales HML,Gel Independiente Plataforma

de alto nivel Algebra de SCCircal, Mobius Impulse-CProcesos CHIMPSANSI-C Catapult-C, C2Verilog, AutoPilotESL System-C ,Handel-C Plataforma especıficaHDL VHDL,Verilog Napa-C

SuperVerilog Garp-C

Tabla 1.1: Clasificacion de lenguajes y sistemas de diseno hard-ware.

Por ultimo, en la seccion 1.5 se estudia como se tratan los principalesaspectos del diseno de sistemas digitales en los lenguajes de descripcionhardware. Los aspectos estudiados son: el paradigma de programacion,las tecnicas para expresar el paralelismo, la planificacion y temporizacionde los diferentes operadores, y las tecnicas utilizadas para las comunica-ciones.

1.1 Lenguajes y sistemas de descripci on estructural 5

Abstracción

80’s

90’s

XXI

Productividad

RTL

ESL

Netlist

HDL

Lenguajes deAlto Nivel.

Puerta lógica

Figura 1.2: Evolucion en el diseno de sistemas reconfigurable.

1.1. Lenguajes y sistemas de descripcion estructural

Las primeras herramientas de diseno surgen como una extension delos sistemas EDA (Electronic Design Automation) y CAD (ComputerAided Design). Se trata de entornos graficos que permiten interconectardiferentes circuitos simples con la finalidad de realizar un circuito mascomplejo Esto es lo que se denomina descripcion estructural de un circui-to. Los componentes basicos tıpicos van desde las puertas logicas hastalos microprocesadores. Esta forma jerarquica de disenar circuitos se llamanormalmente captura de esquematicos.

La utilizacion de un entorno grafico para describir una estructura tienela ventaja de su facilidad de uso y, por lo tanto, de una curva de apren-dizaje reducida. Las desventajas son: limitacion de la transportabilidad,limitaciones para describir circuitos regulares y una pobre expresividadpara desarrollar nuevos componentes.

Los disenos de estos sistemas estan sujetos a un contexto concreto,es decir, dependen de las bibliotecas, de los formatos y del conjunto deherramientas del fabricante. Normalmente, el proyecto no es accesible to-talmente si no se utiliza la misma herramienta con la que se diseno. Estoacarrea serios problemas para cambiar un diseno de plataforma.


En una herramienta CAD, para implementar la repeticion de subsis-temas propia de un circuito regular se realizan sucesivas operaciones de‘cortar y pegar” o se usa la jerarquıa de componente agrupando sucesiva-mente subsistemas, siendo su mayor inconveniente la escasa posibilidadde indicar con un parametro el numero de replicaciones.

Para utilizar este tipo de descripcion se aplican tecnicas de disenohardware, que a partir de conocer el funcionamiento de un circuito obtie-nen la descripcion estructural del mismo. Estas tecnicas son propias deldisenador que aporta su experiencia y sus conocimientos a la descripciondel circuito. El resto de sistemas que se veran en este capıtulo proporcio-nan facilidades incluidas en las herramientas para automatizar mejor elproceso de sıntesis.

Los esquemas descritos en estos entornos visuales necesitan una repre-sentacion interna para que se puedan utilizar por el resto de herramientasperteneciente al ciclo de diseno (simulador, herramientas de fabricacion,etc.). Esta representacion se realiza mediante los ficheros netlist . El netlistes un lenguaje que permite definir los componentes, las interconexionesentre ellos y las entradas/salidas que posee el sistema. Inicialmente, losnetlist eran especıficos de cada herramienta o fabricante y esto limitabael cambio de plataforma de los disenos. El formato EDIF (Electronic De-sign Interchange Format) surgio como estandar industrial para permitirel intercambio de disenos entre diferentes plataforma. Este formato [79]esta disenado para tener en cuenta cualquier tipo de informacion electrica,incluyendo diseno de esquemas, trazado de pistas (fısicas y simbolicas),conectividad, e informacion de texto (como por ejemplo, las caracterısti-cas de los objetos de un diseno).

La descripcion estructural es relativamente sencilla de expresar en unlenguaje de programacion. Por ello, casi todos los lenguajes que se van aver a continuacion tienen un potencial similar en esta clase de descripcion.Posteriormente, se realizara un analisis mas pormenorizado de la potenciay de la versatilidad de esta descripcion para los diferentes lenguajes. Lasaportaciones de utilizar un lenguaje para descripciones estructurales con-sisten en la facilidad de mantenimiento (es mucho mas comodo y rapidocambiar caracterısticas) y su genericidad, gracias al uso de parametros pa-ra expresar la repeticion de un componente. La utilizacion de un lenguaje


permite mayor transportabilidad. La desventaja es que la descripcion re-sulta mas laboriosa y es menos intuitiva que en las herramientas CAD.

Un ejemplo de este tipo de lenguajes es el lenguaje especıfico Peb-ble [94]. Este permite realizar una descripcion estructural utilizando unlenguaje sencillo y soporta la posibilidad de reconfigurabilidad parcial entiempo de ejecucion. El lenguaje propuesto es sencillo y facilita la repeti-cion parametrizable de elementos dentro de una descripcion estructural,muy adecuada para circuitos regulares. Otra aportacion de este lenguajees la de poder incluir parametros en lenguaje de alto nivel que vayan di-rigidos a la implementacion de bajo nivel. Un ejemplo de esto es indicarla posicion relativa donde debe ir un componente dentro de la FPGA. Laforma de indicar los parametros tiene un mayor nivel de abstraccion y sonmas generales que la sintaxis normal de las herramientas de implemen-tacion de bajo nivel (place & route). Este lenguaje tiene una sentenciaRECONFIGURE-IF que permite reconfigurar parcialmente una FPGAen tiempo de ejecucion cuando se cumple una condicion. La figura 1.3muestra un ejemplo de un sumador segmentado de 4 bits y 4 etapasdisenado mediante el lenguaje Pebble. En la figura 1.3(a) esta el codigofuente y en la figura 1.3(b) esta el circuito correspondiente a este sumadordonde los biestables y puertas logicas se han representado con circuitospor simplicidad.

Actualmente, las herramientas tradicionales de captura de esquemati-cos han perdido interes para describir circuitos basados en elementos sim-ples como puertas logicas, decodificadores, etc., a dıa de hoy, el mayor in-teres radica en el desarrollo de grandes sistemas basados en subsistemasya implementados. Es decir, la evolucion de los sistemas CAD ha consis-tido en incrementar la granularidad de estos componentes, e incrementarsu complejidad y capacidad computacional. En la actualidad, se tiene unaamplia coleccion de componentes propietarios (IP) y publicos de diferen-tes dominios de aplicacion que son utilizables en multiples plataformas.Esto permite reutilizar facilmente los disenos. Un claro ejemplo de estetipo de entornos actuales son los denominados System on a Programma-ble Chip (SoPC), como el EDK de Xilinx y el SOPC Builder de Altera.Estas plataformas permiten describir estructuralmente un sistema empo-trado cuyos componentes son el procesador, una jerarquıa de buses y unacoleccion de componentes (como pueden ser controladores de Ethernet,controladores de memoria, etc.).


ABOVE FORi=0..(n-1) DOBESIDE(

BESIDE FOR j=0..(i-1) DOD [w(i,j)] [w(i+1,j)],XORD [w(i,i),w(i,i+1)] [w(i+1,i)],ANDD [w(i,i),w(i,i+1)] [w(i+1,i+1)],BESIDE FOR j=(i+1)..n DO

D[w(i,j)] [w(i+1,j)];Comentarios:

XORD: Es un or-exclusiva conbiestable D a la salida.ANDD: Es un and conbiestable D a la salida.D: biestable D.

(a) Codigo Pebble

D D DXORD

XORD

XORD

XORD

ANDD

ANDD

ANDD

ANDD

D D D

D D D

D D D

(b) Circuito

Figura 1.3: Diseno en Pebble de un sumador segmentado de 4bits y 4 etapas.

La descripcion estructural permite abstraer el diseno y la implemen-tacion de los componentes. Ası, los diferentes componentes pueden serutilizados en diferentes medios o plataformas. Esto proporciona una grancapacidad de prototipado y la integracion de diferentes modelos compu-tacionales. Es normal que un diseno se plantee como una parte de unsistema heterogeneo, por lo que para verificar un componente es necesa-rio modelar el resto. Incluso es muy util aplicar la metodologıa inversaque consiste en realizar un prototipado completo del sistema, y poste-riormente implementar el comportamiento de cada componente. Con ellose consigue especificar exactamente el funcionamiento de cada de uno delos componentes. De esta forma se reduce el numero de refinamientos delos diferentes componentes en el proceso de depuracion del sistema. Sereducen concretamente aquellos refinamientos que provocan una redistri-bucion de atribuciones funcionales de los componentes. A continuacion se


van a estudiar varios ejemplos academicos y comerciales.

Una de las herramientas clasicas utilizadas en el diseno de sistemasempotrados es Ptolemy. El proyecto Ptolemy estudia el modelado, la si-mulacion y el diseno de sistemas concurrentes empotrados y de tiemporeal. El principal enfoque es ensamblar componentes concurrentes y elprincipio fundamental subyacente en el proyecto es el uso de modelos decomputacion bien definidos que rigen la interaccion entre los componen-tes. Su principal aplicacion es la cosimulacion de sistemas heterogeneos,soportando multiples modelos de computacion y de sincronismo. La cons-truccion de los modelos se realiza mediante un diagrama utilizando unainterfaz de usuario grafica, Polis [66]. Se trata de una herramienta desarro-llada por el mismo grupo, y disenada para integrarse en Ptolemy, aunquese puede utilizar en otros cosimuladores. Polis esta basada en modelode programacion GALS (Globally Asynchronous Locally Synchronous)orientado a sistemas empotrados. En este modelo se definen diferentesautomatas de estados finitos. Las transiciones entre estados son asıncro-nas. Los automatas se definen con el lenguaje sıncrono Esterel y la com-posicion de los automatas se realiza con una interfaz visual dentro delentorno de eventos discretos de Ptolemy integrado en Polis. Otro sistemaque ha heredado esta metodologıa es Cierto VCC [131].

La empresa The Mathworks ha desarrollado diferentes herramientascomerciales para facilitar el calculo matematico y la simulacion hete-rogenea de modelos en diferentes campos de aplicacion. Los productos masconocidos de esta empresa son MATLAB y Simulink. Estas herramientasestan muy difundidas tanto en el mundo industrial como en el mundocientıfico-tecnico, considerandose un estandar [157, 135]. MATLAB es unlenguaje de calculo tecnico de alto nivel con un entorno interactivo. Simu-link es una plataforma para simulacion multidominio y diseno basada enmodelos de sistemas dinamicos y embebidos. Juntos, proporcionan un en-torno visual para flujo de datos con un conjunto de bibliotecas de bloquesparametrizables que permiten disenar, simular, implementar y prototiparuna gran variedad de sistemas. Esta herramienta permite un alto nivel deabstraccion funcional, con diferentes tipos de datos y operadores enteros,punto fijo y coma flotante. Ademas, estos entornos visuales son muy ade-cuados para el diseno de sistemas DSP, ya que la mayorıa de algoritmosde este dominio se especifican de una forma mas natural a traves de losgrafos para flujo de senales.


Existen compiladores comerciales [69] de MATLAB tanto para sinteti-zar los algoritmos en hardware sobre FPGA como para traducirlos a C[154]. Estas traducciones permiten trasladar los prototipos a plataformasde computacion reconfigurables.

Xilinx y Altera son los fabricantes mas importantes de logica recon-figurable y han desarrollado aplicaciones como System Generator y DSPBuilder, respectivamente. Estas herramientas proporcionan una bibliote-ca de bloques para el entorno de Simulink que facilita la interaccion consus diferentes parametros, permitiendo la incorporacion de expresionesmatematicas de MATLAB. RcToolBox (www.dsplogic.com) es otra apli-cacion integrada tambien con MATLAB/Simulink. Su mayor aportaciones la amplia interaccion de componentes en el flujo de datos. Tiene unconjunto de bloques que permiten realizar un control de flujo mas ex-haustivo y general. Este control permite especificar la temporizacion delos bloques, dependiendo de si la ejecucion es secuencial, concurrente osegmentada. Tambien permite el acceso concurrente a memoria, y tieneuna capa de abstraccion de la plataforma de computacion reconfigurableque permite la portabilidad del proyecto.

Para finalizar, se describe una herramienta que tiene los dos tiposde descripcion estructural: el basado en un lenguaje de alto nivel y elbasado en un entorno visual. Esta herramienta se llama PixelStream [13],y consiste en una biblioteca de procesamiento de imagenes integrada enel entorno de desarrollo del lenguaje de descripcion de hardware Handel-C, de la empresa AgilityDS/MentorGraphics. Estas bibliotecas se puedenconfigurar e interconectar con un sistema grafico como se puede ver enla figura 1.4. Este entorno permite traducir la estructura de componentesa un programa en Handel-C (ver listado 1.1). De esta forma, se puederealizar una rapida descripcion general del sistema utilizando un entornovisual. Posteriormente, se pueden realizar sucesivos refinamientos en elproyecto generado en el lenguaje Handel-C si es necesario. Para incorporarnuevos componentes con una descripcion comportamental e incluso pararealizar el mantenimiento del proyecto, puede ser mas eficaz utilizar laversion basada en el lenguaje hardware. La idea fundamental es unir lasaportaciones de los dos estilos, tomar la facilidad de expresar algoritmosDSP como un flujo de datos y tener las ventajas de productividad de unlenguaje de alto nivel.


Figura 1.4: Ejemplo de un diseno grafico con PixelStream.

Listado 1.1: Fragmento de codigo HandelC correspondiente aun diseno de PixelStream.

✞1 par{2 PxsTVIn (&TVin , 0 , 0 , ClockRate ) ;3 PxsConvert (&TVin , &RGBIn ) ;4 PxsCl ipRectangle (&RGBIn , &Clip , 0 , 0 , Width − 1 , Height − 1 ) ;5 PxsFIFO (&Clip , &FIFO, 256) ;6 PxsConvert (&FIFO, &MONO) ;7 PxsSpl i t2 (&MONO,&MONO1,&MONO2) ;8 PxsMoment (&MONO2, &Analy s i s ) ;9 PxsTVSyncGen (&TVSync , IsPAL ) ;

10 PxsSpl i t2 (&TVSync,&VGAin,&VGASync ) ;11 PxsEmphatize (&MONO1, &Stream14 ) ;12 PxsCursor (&Stream14 ,&Imagen , ( signed ) (0@CursorX ) , ( signed ) (0@CursorY )13 ,PXS CURSOR POINTER) ;14 PxsPalPLnRAMFrameBuffer (&Imagen , &TVSync , &Out3 , Width , PXS WEAVE, 1 ,15 ClockRate ) ;16 PxsFIFO (&ClipOut , &FIFO 1 , 32 ) ;17 #i f d e f MULTICLK18 PxsSend (&FIFO 1 , &CrossDomain ) ;19 #else20 #i f de f i n ed (USE RC300E ) | | de f i n ed (USE RC340E ) | | de f i n ed (USE RC250E )21 PxsVGAOut (&FIFO 1 , 1 , 0 , ClockRate ) ;22 #else23 PxsVGAOut (&FIFO 1 , 0 , 0 , ClockRate ) ;24 #end i f25 #end i f26 while (1){27 PxsAnalyseAwaitUpdate (&Analy s i s ) ;28 c a l cu l o s (&CursorX ,&CursorY , PxsAnalyseGetSumValues (&Analy s i s ) ) ;

✡✝ ✆


1.2. Lenguajes estandar de descripcion hardware

En la decada de los ochenta aparecieron los lenguajes de descripcionde hardware (HDL) fruto de la experiencia adquirida por los disenadoresen la decada anterior. Estos incluıan sustanciales mejoras en la descrip-cion estructural, como se comento en la seccion anterior. Un inconvenientede la descripcion estructural es la dependencia de la plataforma donde seva a implementar el sistema con las bibliotecas de componentes especıfi-cas. Existen propuestas para que los componentes de estas bibliotecassean genericos [99, 98], pero la propuesta de los HDL fue incluir otrostipos de descripciones. Estas descripciones se dirigen a especificar el com-portamiento, de esta forma el sintetizador del lenguaje es el encargadode obtener el circuito con ese funcionamiento. Existen dos descripcionesde este tipo: la descripcion como transferencia de registro (RTL) o flujode datos, y la descripcion algorıtmica. La descripcion de flujo de datosesta orientada al hardware, es decir, intenta expresar el funcionamientode los circuitos con expresiones de lenguajes de programacion. Estas ex-presiones tienen operadores clasicos pero no hacen referencia a funcioneso componentes definidos por el usuario o definidos en una biblioteca. Ladescripcion algorıtmica tiene mayor nivel de abstraccion; se olvida total-mente que se esta especificando hardware y se utiliza para expresar elfuncionamiento del circuito. La sıntesis en un RTL es practicamente di-recta y la sıntesis de una descripcion algorıtmica requiere mas esfuerzocomputacional por parte del sintetizador.La descripcion Register Transfer Level (RTL) es una descripcion de cir-cuitos secuenciales sıncronos, donde el nuevo valor de una senal o variablese expresa como una funcion logica de algunas de sus variables, como se veen la figura 1.5. Este tipo de descripcion es muy potente y suficientementecompleta.

El listado 1.2 es un ejemplo de un sumador completo de un bit expre-sado en el lenguaje de descripcion de hardware VHDL. En este ejemplose utilizan los tres tipos de descripciones: estructural, transferencia entreregistros y algorıtmica. Las lıneas de la 1 a la 11 son de descripcion es-tructural, donde las cuatro primeras lıneas son para especificar la interfazde este diseno (para poder ser utilizado en otro circuito). Las lıneas 6, 7 y8 indican que se va a utilizar el componente externo XOR2, normalmenteperteneciente a una biblioteca. La lınea 11 es la utilizacion del compo-nente XOR2 en nuestra implementacion. La lınea 19 corresponde a unadescripcion RTL de una funcion or-exclusiva. La descripcion algorıtmica

1.2 Lenguajes est andar de descripci on hardware 13

R e g i s t r o s

C i r c u i t o C o m b i n a c i o n a l

v a r i a b l e se x p r e s i ó n

Figura 1.5: Esquema de una descripcion RTL.

de la funcion de acarreo de un sumador completo de un bit correspondea las lıneas de la 12 a la 18.

Listado 1.2: Semisumador expresado en VHDL.✞1 entity FULL ADDER i s

2 Port ( A,B,CIN : in BIT ; SUM,COUT: out BIT ) ;3 end FULL ADDER;4 architecture FA MIXED of FULL ADDER i s

5 component XOR2 port (P1 , P2 : in BIT ; PZ: out b i t ) ;6 end component ;7 signal S1 :BIT ;8 begin

9 X1 : XOR2 port map (A,B, S1 ) ; −−e s t r u c t u r a l

10 process (A,B,CIN) −− a l g o r i tm i co

11 variable T1 ,T2 ,T3 :BIT ;12 begin

13 T1:=A and B;T2:= B and CIN ; T3:= A and CIN ;14 COUT <= T1 or T2 or T3 ;15 end process ;16 SUM <= S1 xor CIN ; −−data f low

17 end FA MIXED;✡✝ ✆

Un objetivo de estos lenguajes es tener toda la informacion necesa-ria para disenar, implementar y validar un proyecto hardware. Dicho conotras palabras, tener un lenguaje completo y unico para el diseno de sis-temas hardware. Por ello, existiran sentencias de lenguajes para definirun banco de prueba y para modelar el funcionamiento de un subsistema.


No obstante, la realizacion de los bancos de prueba es laboriosa dedescribir directamente en algunos de estos HDL. Por este motivo apare-cieron los lenguajes de verificacion de hardware (HVL) tales como el e yVera, que facilitaban la generacion automatica de los bancos de prueba.

Los HDL estandarizados por el IEEE son el VHDL, Verilog y SystemVerilog. Hay tres versiones estandar importantes de VHDL, el VHDL-87,VHDL-93 y VHDL-2008[3, 153], tambien hay dos versiones estandares deVerilog, el Verilog-95 y su revision Verilog-2001[4]. En 2005 se publico elestandar de System Verilog que pretende unificar los HDL estandar hastael momento en un unico lenguaje. System Verilog mantiene la sintaxisde Verilog, pero adapta conceptos exclusivos de VHDL. Ademas, incluyeel HVL Vera, incorporando la generacion aleatoria guiada de testbench,ası como la inclusion del modelo de programacion orientado a objetos.

La utilizacion de los HDL estandar es actualmente muy alta. Estossistemas se adaptan perfectamente a las formas de describir hardware ytienen una eficiencia muy alta en cuanto al resultado final del circuito.Otro motivo es la alta implantacion existente actualmente de herramien-tas basada en estos estandares, lo que genera una inercia al cambio a lautilizacion de otros lenguajes alternativos, que sin embargo se va incre-mentando cada vez mas.

A continuacion, se va a realizar una comparacion entre la descripcionRTL y la descripcion comportamental. La desventaja principal de la des-cripcion RTL es su baja productividad y el alto coste del mantenimientodel sistema. Esto es debido a que la descripcion tiene muchos detallesdel hardware y las decisiones arquitecturales han sido tomadas en tiem-po de diseno. Despues de tomar estas decisiones es difıcil realizar algunamodificacion arquitectural sin tener que volver a realizar el diseno practi-camente desde cero. Otra desventaja, comparandolas con una descripcioncomportamental, es el tiempo que cuestan sus simulaciones. La gran ven-taja es su simplicidad a la hora de la sıntesis del hardware, obteniendounos circuitos muy eficientes en area, tiempo y consumo de potencia.

El termino “descripcion comportamental” es muy amplio, de hechola descripcion de transferencia de registro se puede interpretar como unadescripcion de este tipo. El concepto “comportamental” expresa de forma


relativa la abstraccion de la descripcion del hardware. Ası, la descripcionde transferencia entre registros se considera una descripcion comporta-mental de nivel bajo, ya que solo sustituye y generaliza el uso de bibliote-cas de operadores clasicos, utilizando expresiones propias de un lenguajede programacion. Hecha esta aclaracion se van a analizar las ventajas deesta descripcion comportamental de “alto nivel” en relacion a la descrip-cion RTL.

Las aportaciones de la descripcion comportamental se pueden resumiren los siguientes puntos:

Abstraccion de la descripcion. Un sistema expresado en RTL definecompletamente la estructura e interconexion de los subsistemas ylas correspondientes fases de ejecucion de las operaciones a realizar,lo que normalmente se llama ruta de datos y unidad de control. Ladescripcion comportamental omite algunos de estos detalles arqui-tectonicos, abstrayendo aspectos que puede automatizar el sinteti-zador. Ası pues, los sistemas expresados de forma comportamentalconsistiran en conjuntos de rutinas interconectadas y sincronizadascon los recursos propios de cada lenguaje.

Reduccion de la formacion del disenador. Esta descripcion propor-ciona la vision propia del proyecto software al desarrollo hardware.Permitiendo, con una corta curva de aprendizaje, reciclar a un in-geniero de software para que pueda desarrollar sistemas reconfigu-rables.

Reduccion del tiempo de verificacion. La relacion entre tiempo si-mulado y tiempo transcurrido crece exponencialmente en los HDLestandares utilizando un estilo RTL. Se puede observar en la grafi-ca la comparativa publicada en [28] . El experimento de la graficacompara la implementacion utilizando un modelo RTL en VHDL yuna implementacion utilizando un modelo TLM (Transaction LevelModel) en System C de un algoritmo de ordenacion de la burbujapara vectores de 32, 64, 128, 256, 512, 1024 componentes. SystemC, como se vera proximamente, es uno de los lenguajes comercialesque mejor puede representar la descripcion comportamental. Unaconsecuencia de la utilizacion de la descripcion comportamental es


el incremento de velocidad en la simulacion, como se puede obser-var en la Figura 1.6. Este incremento de velocidad es debido a laeliminacion de detalles que no afectan al funcionamiento final delcircuito.

0

200

400

600

800

1000

1200

1400

1600

32 64 128 256 512 1024

Tie

mpo

(s)

Tamaño del vector

VHDLSystem C

Figura 1.6: Comparacion de tiempos de simulacion entre unadescripcion RTL y una descripcion comportamental (TLM) delalgoritmo de la burbuja.

Las limitaciones de esta descripcion comportamental se pueden resu-mir en los siguientes puntos:

Limitacion de especificacion de puntos en el espacio de diseno.La descripcion comportamental con sus posibles restricciones puedesolo guiar al diseno a un numero limitado de puntos en el espaciode diseno. Por lo tanto, es posible que el circuito generado no seael adecuado, dependiendo de las especificaciones concretas del di-seno. Esto quiere decir que si se utiliza la expresion comportamentala := b × c, esta inferira como resultado un multiplicador. La cues-tion es como esta implementado un multiplicador: como un circuitocombinacional (rapido y extenso en area), como un circuito segmen-tado con una alta productividad, o como un circuito secuencial queen cada ciclo se realiza una suma de la multiplicacion resultando


un circuito de gran latencia pero con un area muy reducida. Todosestos puntos en el espacio de diseno son alcanzables utilizando ladescripcion RTL, pero no lo son en la descripcion comportamental.

Dificultad en refinamiento del diseno. Un metodo de trabajo puedeconsistir en la validacion funcional con una descripcion comporta-mental y luego, con sucesivos refinamientos, conseguir el punto enespacio diseno determinado por las especificaciones. Este plantea-miento suele ser poco viable en la mayorıa de lenguajes comporta-mentales, ya que poco puede hacer el disenador, excepto jugar conlas restricciones del comportamiento o vagar en los entresijos deldiseno.

Dificultad de evaluar las sentencias de alto nivel. Es complejo en-tender como afecta la transformacion de alto nivel en el uso derecursos y en el tiempo de propagacion del circuito resultante.

Los disenadores hardware han conseguido reducir su esfuerzo de disenoal 50% y seguir manteniendo la calidad de los resultados [123, 54, 109]gracias lenguajes de alto nivel basado en descripciones comportamentales.Aunque otras fuentes estiman que la perdida en la calidad de resultado essignificativa, como en el trabajo de Essam El-Araby [53] donde se com-paran los resultados de eficiencia y facilidad de uso. Los resultados deeste trabajo se muestran en la figura 1.7. Se ha utilizado el VHDL co-mo lenguaje de descripcion hardware y representante de los lenguajesRTL, siendo este el referente de la maxima eficiencia (100%) y referenciamınima de la facilidad de aprendizaje (0%). El RC ToolBox descrito enla seccion anterior es el representante de los sistemas CAD basado enla descripcion estructural. El Impulse C es el representante del lenguajecomercial imperativo, que posteriormente se describira con detalle, y elMitrion como lenguaje funcional, por lo tanto con mayor capacidad deabstraccion, que tambien se describira posteriormente.

La conclusion es que los lenguajes comportamentales reducen el tiem-po de salida al mercado por su facilidad de uso, a costa de una perdida enla calidad del circuito final. Esta es la causa del auge de estos lenguajesen detrimento de los lenguajes estandar de descripcion de hardware.


Facilidad de uso0 50 100

Efic

ienc

ia

0

50

100

Mitrion

VHDL

ImpulseC

DSPLogic

Difícil Fácil

Baja

Alta

VHDL Impulse C Mitrion DSPlogic

Eficiencia 100 5,72 7,94 46,625

Facilidad 0 53,6 7,6 52,83

Figura 1.7: Comparacion de eficiencia y facilidad de uso entrelenguajes comportamentales (Impulse C,Mitrion), estructurales(DSPlogic) y RTL (VHDL).

1.3. Lenguajes de alto nivel para el diseno hardware

En la seccion anterior se comento que un sistema descrito en RTL sedisena definiendo una ruta de datos y una unidad de control. Obviamentela ruta de datos se puede expresar facilmente con una descripcion RTL oestructuralmente. En cambio la descripcion de la unidad de control no esdirecta para ello se debe definir un automata de estados finitos y luegoconvertirlo en un circuito. Ademas, esta es la parte del sistema que sesomete a mas modificaciones en tiempo de diseno y por lo tanto necesitalas mejores tecnicas para facilitar su mantenimiento. Por esto no sorpren-

1.3 Lenguajes de alto nivel para el dise no hardware 19

de que los primeros lenguajes comportamentales fuesen especıficos parael diseno de unidades de control son los denominados lenguajes sıncronos.

Lustre, Signal, Argos y Esterel son ejemplos de lenguajes sıncronos[20]. Por su difusion el mas importante es Esterel [57][156]. Es un lenguajeque permite especificar facilmente automatas de estados finitos. Tambienadmite una descripcion jerarquica, de tal forma que se puede definir unautomata con un estilo estructurado, como en los lenguajes de progra-macion. El modelo basado en automata finito proporciona la seguridadde predecir todas las posibles situaciones con total ausencia de proble-mas de concurrencia o de sincronismo. Esterel tiene sentencias basadasen eventos para describir hardware en sistemas reactivos. Concretamente,se diseno como una entrada al sistema Polis [66] para describir de formaestructural el control del resto de componentes definidos utilizando unentorno grafico. Un lenguaje contemporaneo, pero con un modelo de sin-cronismo diferente, fue Alphahard [87]. Esta basado en el lenguaje Alpha,que es un lenguaje funcional para paralelizar el procesamiento de datosen una arquitectura sistolica. El Alphahard produce el sistolico completoen VHDL a partir de este tipo de especificacion.

Se pueden considerar los lenguajes especıficos para sistemas distribui-dos como una evolucion de los lenguajes sıncronos, ya que su enfoque esel mismo: comunicar procesos concurrentes. LOTOS [155] y SDL [46] sonlenguajes para definir sistemas distribuidos y existen versiones para im-plementar tanto hardware como sistemas hıbridos software/hardware. Lagran aportacion de estos es su gran capacidad para especificar y validarcomunicaciones entre procesos.

A parte de los lenguajes propios para generar hardware, siempre haestado latente la idea de utilizar un lenguaje de programacion tradicionalen el desarrollo de hardware. Sirvan de ejemplo los HDL estandar: VHDLes un subconjunto de lenguaje ADA y Verilog tiene una sintaxis similaral lenguaje de programacion C.

Los motivos para elegir un lenguaje de alto nivel son las ventajas de ladescripcion comportamental vistas en la seccion anterior y la facilidad depoder realizar disenos que combinen software y hardware. Estos disenosson muy comunes en computacion reconfigurable y sistemas empotrados.


Un unico lenguaje facilita la codificacion y permite mayor versatilidadpara asignar las tareas al procesador o a la unidad hardware.

A continuacion se describen una serie de lenguajes de alto nivel carac-terısticos bien por su alta utilizacion o bien por su nivel de abstraccion afin de proporcionar las caracterısticas actuales y futuras de los lenguajeshardware.

1.3.1. Lenguajes basados en C

En esta categorıa se incluyen los lenguajes que mantienen la sintaxis yun subconjunto de sentencias del lenguaje de programacion C, incluyendonormalmente sentencias y directivas especıficas para el diseno hardware.

Posiblemente, Cones [139] fue uno de los lenguajes mas antiguos quese inspiro en el lenguaje de programacion C. Es un reducido subconjun-to de sentencias del lenguaje C. Cada funcion se sintetiza en un circuitocombinacional. Puede sintetizar sentencias condicionales, bucles que sondesenrolladlos y cada variable de cualquier tipo escalar lo puede tratarcomo un vector de bits.

El Hardware C fue disenado como una entrada al sistema de sıntesisOlympus [47]. Es un lenguaje de descripcion de hardware comportamen-tal que tiene una sintaxis parecida al lenguaje C. Posee extensiones quepermiten las jerarquıas y sentencias orientadas al hardware. Estas sen-tencias permiten definir el paralelismo entre ellas.

Transmogrifier es un pequeno subconjunto de C, que soporta aritmeti-ca entera, sentencias condicionales y bucles [58]. Los circuitos generadosson secuenciales sıncronos. Los estados del circuito son establecidos encada llamada a una funcion y al principio de cada bucle “while”.

EL SA-C [23] [113] es un lenguaje sencillo basado en C de asignaciondirecta, normalmente llamada SSA (Static Single Assignement) [67], yoptimizado para operaciones de procesamiento de imagenes. El lenguajeSA-C introduce el concepto de ventana de convolucion. El compiladorimplementa esta ventana con un banco de registros de desplazamiento,suministrando eficientemente los pıxeles adyacentes pertenecientes a la


convolucion local. Este lenguaje esta integrado en el entorno visual Kho-ros, especifico para tratamiento de imagenes [127, 70].

1.3.2. Lenguajes orientados a CSP

La necesidad de describir el paralelismo de grano fino inherente alhardware origino la inclusion de sentencias del estilo CSP [74] en los len-guajes de descripcion de hardware. Estas sentencias se habıan incorporadoen algunos lenguajes paralelos de programacion como el OCCAM [77].

Handel-C de AgilityDS/MentorGraphics [154] es una variante de Cque extiende el lenguaje con constructores de sentencia para expresarparalelismo (par y seq ) y comunicaciones bloqueantes basandose en elmetodo de sincronismo de proceso “rendez-vous”, inspirando en lenguajede programacion OCCAM. El modelo temporal esta basado en el trabajode Page y Luk [116] donde cada sentencia de asignacion a una variablese ejecuta en un ciclo de reloj, por lo cual, el periodo de reloj lo determi-nara la asignacion mas compleja. Este es un producto comercial y dentrode su sistema de desarrollo se ha incorporado diferentes herramientas quese referencian a lo largo del capıtulo.

Hadyn-C [44] tiene una filosofıa similar al Handel-C, pero adicional-mente permite una temporizacion mas flexible donde se puede indicarcaracterısticas arquitectonicas como por ejemplo la segmentacion.

Mobius [142] es parecida a los anteriores, pero su sintaxis es pareci-da al lenguaje de programacion Pascal. La implementacion de este sis-tema traduce el codigo fuente a un grafo de flujo de datos construidocon primitivas de sincronismo asıncrono (handshaking). Estas primitivasinterconectan mediante canales bloqueantes los diferentes nodos del grafo.

El compilador SCCircal [49] utiliza un paradigma basado en algebrade procesos. Los lenguajes mas conocidos dentro de este paradigma sonel CCS [104], CSP [74]y Circal [102]. Estos lenguajes basados en espe-cificaciones de algebra de procesos, en la mayorıa de ocasiones, estanempotrados en algun lenguaje de programacion. En este caso concreto,se utiliza el XTC como lenguaje anfitrion y como lenguaje huesped elCircal. A esta combinacion se llama XCircal [103]. El XTC es un len-guaje interpretado con una sintaxis similar al C, con la caracterıstica de


ser extensible, es decir, tener facilidad para incorporar nuevas sentencias.Este paradigma se basa en describir la estructura, la interaccion y lasfunciones del sistema usando un formalismo riguroso.

La idea del algebra de proceso es que un sistema computacional sepuede describir en un proceso algebraico como un conjunto de automatasinteractuando entre ellos. Por lo que, esta descripcion basada en Circal,consiste en la definicion de varios procesos. Los procesos interactuan vıaacciones que representan los eventos del mundo real. Estos inciden en elmodelo como senales de sincronismo internas al modelo, tales como unreloj en un sistema digital.

Uno de los puntos fuertes del algebra de procesos consiste en la ma-nipulacion automatica de descripciones de sistemas, validando facilmentelas descripciones, comprobando si dos especificaciones son equivalentes osi una especificacion esta incluida en otras.

1.3.3. Lenguajes funcionales

Lava [38][22] es una coleccion de modulos de Haskell que permitedescribir, verificar e implementar hardware. Fue uno de los primeros len-guajes empotrados con un unico lenguaje para todas las fases de disenode un circuito.

Este lenguaje explota todas las propiedades de Haskell, como poli-morfismo y funciones de orden superior. Estas funciones permiten que laentrada y salida de una funcion sea tambien otra una funcion. Esas propie-dades permiten mayor capacidad de abstraccion que los HDL tradiciona-les. Este lenguaje usa tambien la descripcion estructural y jerarquica paradefinir los circuitos. Ella [108] y Ruby [76, 136] son lenguajes funcionalesde caracterısticas similares. HML [93] y Gel [14] se pueden considerar loslenguajes funcionales mas evolucionados.

HML esta basado en el lenguaje funcional SML. Sus caracterısticasincluyen tipos polimorficos, verificacion avanzada de tipos e inferenciade tipos. El compilador de este lenguaje genera VHDL, infiriendo au-tomaticamente los tipos y sus interfaces correspondientes. Este lenguajecombina las ventajas de un lenguaje fuertemente tipado, heredado del


lenguaje SML, y la concision y legibilidad de los lenguajes debilmentetipados.

Gel usa el Scheme como lenguaje huesped. El lenguaje Scheme es unlenguaje funcional dialecto de Lisp. El compilador soporta evaluacion par-cial y eliminacion de subexpresiones comunes. Aunque lo aportacion masimportante es la inferencia automatica de tipos, obteniendo la longituden bits de cada variable.

1.3.4. Lenguajes orientados a objetos

Los lenguajes orientados a objetos se pueden dividir en dos categorıas.La primera esta compuesta por los mas antiguos Lola y JHDL. Estos ex-ploran la descripcion estructural y RTL con los recursos del paradigmaorientado a objetos. En la segunda categorıa estan los lenguajes que uti-lizan la descripcion comportamental.

Lola [150, 149] es un HDL basado en Oberon, un lenguaje orientadoa objetos que se puede considerar como una evolucion de los lenguajesModula, Modula-2 y Pascal. Lola forma parte de Trianus, un sistema com-pleto de desarrollo de circuitos para FPGA. Trianus tiene la posibilidadde captura de esquematicos y de utilizar Lola para introducir circuitosal sistema. Este sistema implementa los circuitos en la FPGA XC6200.Esta FPGA es una de las pocas que es abierta, es decir, cuyo formato deconfiguracion (bitstream) es de dominio publico.

JHDL [17, 143] es un lenguaje HDL basado en Java que utiliza el po-limorfismo para la reconfiguracion parcial de la FPGA XC6200 (una delas primeras con esta caracterıstica) e incorpora un sistema de validacionmuy potente. Para ello, primero se valida el circuito ejecutando el pro-grama en un procesador y posteriormente algunos objetos o metodos sontransferidos a una plataforma reconfigurable. El sistema se ocupa de queel resto del programa acceda al circuito reconfigurado en la plataforma deforma transparente, permitiendo la depuracion del sistema en la propiaplataforma.

El sistema OCAPI [132] esta basado en clases de C++. Permite mo-delar, sintetizar y simular para describir correctamente el diseno Propor-


ciona clases para poder especificar la ruta de datos, la maquina de estadosfinitos y constructores similares.

System C es actualmente uno de los lenguajes mas difundido comer-cialmente. El primer proposito de este lenguaje fue ser un estandar paramodelar sistemas, en contraposicion con todos los anteriores que eranlenguajes orientados a la sıntesis. Posteriormente, aparecieron paulatina-mente sintetizadores de System C cada vez mas potentes. De esta forma,los componentes para modelar y sintetizar proporcionan una gran facili-dad a la hora de verificar el sistema, como ya se vio en System Verilogy VHDL. System C usa el mecanismo de las clases C++ para describircomponentes estructural y jerarquicamente. Una de sus mayores ventajases el extenso repertorio de recursos que tiene para el sincronismo e in-tercomunicacion entre procesos. Tiene muchos puntos en comun con losHDL estandar, considerandose el HDL del futuro.

Hay varios compiladores basados en Java, por ejemplo Xilinx comer-cializo un sintetizador llamado Forge. La plataforma Galadriel/Nenya[32, 33] puede explotar multiples flujos de control y diferentes gradosde paralelismo a nivel de instruccion. Esta plataforma sintetiza a partirdel codigo de la maquina virtual Java. De una forma similar trabaja elcompilador Sea Cucumber [141], cuya mayor aportacion es que el siste-ma de comunicacion y sincronismo entre procesos software y hardwareesta basado en canales FIFO.

1.3.5. Lenguajes ANSI

Esta tendencia surgio con la aparicion de los SoC. La uniformidad deun lenguaje para desarrollar estos sistemas simplifica el mantenimiento yfacilita la planificacion de tareas hardware y software.

El compilador C2Verilog [118] desarrollado en CompiLogic, mas tardellamado C Level Design, es uno de los pocos lenguajes que puede realizarla traduccion practicamente sin limitaciones de ANSI-C a Verilog.

El lenguaje SpecC [55] es un superconjunto de ANSI-C, por lo queincluye todos los constructores del ANSI-C y ademas posee constructoresorientados al diseno hardware. El ultimo manual de referencia incorpo-


ra 33 nuevas palabras reservadas. Por ejemplo, tiene constructores paraestablecer concurrencia, definir los automatas de estados finitos de las uni-dades de control y disenar circuitos segmentados. El lenguaje completono es directamente sintetizable, pero se aplican una serie de conversionestanto manuales como automaticas para refinar las discrepancias del len-guaje completo a su version sintetizable.

Trident [140] es un compilador de codigo abierto cuyo lenguaje es unsubconjunto de ANSI-C. El codigo tiene la limitacion de no soportar sen-tencias “printf”, recursividad, memoria dinamica, argumento funcionalesy funciones con lista de argumentos de tamano variable, y limita el usode punteros. Acepta operaciones en coma flotante y tiene una planifica-cion automatica de operaciones para extraer el maximo paralelismo. Seutiliza un compilador de GNU C para obtener el codigo maquina LLVM(Low Level Virtual Machine). El sistema trabaja a partir de esta repre-sentacion interna. Puede realizar un analisis de la ejecucion del programa(profiling) para guiar al particionado hardware y software, ası como unaplanificacion automatica de operaciones y, por supuesto, la sıntesis de loscomponentes correspondientes.

Kiwi [65] transforma programas paralelos de C# en circuitos para con-figurar FPGA. El objetivo de este sistema es utilizar los diversos modelosde comunicacion entre procesos e hilos que posee el C# de la plataforma.NET para el diseno hardware. Estos modelos de comunicacion estan defi-nidos en una biblioteca estandar de programacion paralela. Basicamente,el sistema transformara el codigo maquina o byte-code de la plataforma.NET en Verilog.

El compilador CASH es el unico que genera circuitos secuencialesasıncronos. Acepta ANSI C, e identifica automaticamente paralelismo anivel de instruccion.

Los lenguajes ANSI C, ANSI C++ junto a System-C son los mayori-tariamente utilizados en los sintetizadores comerciales actuales, incluso esnormal que una herramienta compile los tres lenguajes. Estas herramien-tas comerciales incluyen los ultimos algoritmos de sıntesis de alto nivel(HLS) [40] e integrar herramientas eficientes para facilitar la verificacionde los disenos. Ejemplo de estos sintetizadores HLS son: AutoPilot dela empresa AutoESL/Xilinx,Catapult-C de la Mentor Graphics, Blues-


pec, Cyntesizer de Forte Design System, C-to-Silicon de Cadence DesignSystem, Synphony C de Synopsys y CyberWorkBench from NEC [40, 42].

1.4. Compiladores de Plataformas Reconfigurables

En esta seccion se estudian los lenguajes y sistemas para programary configurar plataformas reconfigurables. Primero se describiran los len-guajes disenados especıficamente para una arquitectura reconfigurableconcreta. Despues se describiran lenguajes mas generales para SoC quese pueden adaptar a diferentes plataformas reconfigurables.

Las arquitecturas reconfigurables tienen una organizacion basada enprocesadores de proposito general y coprocesadores especıficos. El funcio-namiento de estos coprocesadores se configura definiendo el circuito co-rrespondiente. Las partes de calculo intensivo de un programa secuenciallas realizan los coprocesadores, mientras que los procesadores de propositogeneral realizan el resto. Los programas ejecutados por los procesadorescontrolan todo el sistema, suministrando la informacion a los coprocesa-dores y permite configurar las funciones de los coprocesadores.

El compilador PRISM [11, 146] fue el primero en traducir codigo Cpara una arquitectura reconfigurable. El NAPA-C [97] propuso una so-lucion basada en directivas del compilador (#pragma). Estas se utilizanpara identificar las partes de computo intensivo, y automaticamente soncompiladas a logica reconfigurable. Este compilador es especıfico paraun dispositivo concreto, NAPA 1000 (National semiconductor’s Adapti-ve Processing Architecture) que combina un procesador RISC con logicareconfigurable. El compilador tiene directivas para indicar que variablesson utilizadas por el procesador y cuales por la logica reconfigurable. Lacompilacion hardware de los bucles tiene importantes aportaciones, comopor ejemplo la planificacion temporal propuesta en el algoritmo de Lam[86], para realizar un circuito segmentado con las sentencias internas albucle.

El GARP es un sistema que consta de un procesador MIPS, caches yuna matriz de bloques de logica. El procesador tiene acceso independiente-mente a cada columna de la matriz y la matriz de bloques es reconfigurableparcial y dinamicamente. El compilador distribuye automaticamente las

1.4 Compiladores de Plataformas Reconfigurables 27

tareas entre el procesador y la logica reconfigurable a partir de un progra-ma en C. Normalmente, el interior de los bucles se implementa en la logicareconfigurable, y el procesador realizara el control de datos suministrandola informacion necesaria en el instante correspondiente. Una aportacionmuy interesante es el acceso a la memoria del procesador por parte de lalogica reconfigurable. El hardware reconfigurable tiene cuatro buses: unapara acceso aleatorio, y tres para acceso secuencial y todos comparten unbus de direcciones. Estos buses tienen acceso a la memoria principal delprocesador a traves de las caches, aunque esta limitado a una unica pe-ticion aleatoria por ciclo. Este sistema proporciona una forma sencilla decompartir las direcciones de variables entre la parte software y hardware.

Piperench [62] es una arquitectura orientada a sacar el mayor pro-vecho al paralelismo temporal. El sistema se compone de un conjuntode etapas reconfigurables, que estan interconectadas formando un siste-ma computacional segmentado. Cada una de estas etapas esta compuestapor una red de interconexion y varios elementos de proceso (EP). CadaEP tiene una unidad aritmetica logica y los registros de segmentacion co-rrespondientes, donde se almacenara la informacion de salida concernientea la ejecucion de la etapa. El tiempo de ejecucion y de reconfiguracionde cada etapa fısica es el mismo. De esta forma, cada etapa fısica puedereconfigurarse facilmente en diferentes etapas de calculo, lo que permiteimplementar un proceso segmentado con un numero inferior de etapasfısicas que de etapas de calculo. El lenguaje utilizado es DIL (DataflowIndependente Language), un lenguaje simple con operadores de C. Lassentencias tienen la forma SSA (Static Single Assignment). Esta formaconsiste en que cada variable es asignada una unica vez. Tiene una infe-rencia de tipos para calcular la longitud de palabra de cada variable.

Actualmente, XPP-PACT [16] es una version comercial de arquitectu-ra reconfigurable de grano grueso. Esta basada en una matriz jerarquicade grano grueso con elementos de computacion adaptativa y una redde interconexion orientada a paquetes. Tiene reconfiguracion dinamica ypermite la autoconfiguracion. Ademas, tiene un lenguaje de descripcionestructural llamado NML (Native Mapping Language), que permite des-cribir hardware y manejar configuraciones de logica configurable. Para ladescripcion del sistema se utiliza el lenguaje C. El traductor para descrip-cion del hardware de funciones C a NML se llama XPP-VC. Este lenguaje


es un subconjunto de C, permite utilizar bibliotecas de componentes es-pecıficos de la arquitectura XPP y utiliza tecnicas de vectorizacion [147]para ejecutar bucles de programas de forma segmentada.

Un hito importante en la historia de los sistemas reconfigurables sedio cuando la escala de integracion permitio la inclusion de un procesadoren la FPGA. NIOS, MicroBlaze y ARM7 son ejemplos de procesadores”software“ (softcore) de los fabricantes mas importantes de FPGA, queson respectivamente Altera, Xilinx y Actel. Estos procesadores son es-pecificaciones propietarias que pueden incluirse en los proyectos de lasherramientas del fabricante, que se describieron en la seccion 1.1. Otraopcion es incluir fısicamente el procesador (hardcore). La FPGA VirtexII Pro de Xilinx incluye el procesador PowerPC y la FPGA Excalibur deAltera contiene un procesador ARM. Con esta plataforma se extendieronlos disenos de los SoC.

Una de las primeras herramientas para este tipo de plataforma fueel entorno Defacto [25] (Design Environment For Adaptive ComputingTechnology). Este entorno de desarrollo facilita el particionado hardwa-re/software utilizando C o Fortran. El codigo hardware admite parame-tros para determinar la forma de la implementacion. Estos parametrosindican al sintetizador como debe realizar el circuito final.

En el trabajo de Vanmeerbeeck y otros [144] se propone el sistemaOCAPI-XL. Esta herramienta propone una metodologıa para tomar ladecision del particionado hardware/software en las primeras fases del di-seno, incluso puede generar codigo tanto para el software como para elhardware. Esto es posible gracias a una descripcion uniforme del sistemaindependiente de la arquitectura. Esto posibilita balancear, a traves derefinamientos sucesivos, la parte software y hardware de un sistema. Lasclases de OCAPI permiten esta unificacion tanto para la sıntesis comopara la validacion del sistema completo.

El compilador Stream-C [61] se caracteriza por su sistema de comu-nicacion entre los procesos. Este sistema utiliza memorias FIFO donde sealmacenan los diferentes flujos de informacion e incluye directivas clasicasCSP. Stream-C incluye directivas para indicar la utilizacion de multiplesbancos de memoria y poder asociar un vector a un banco concreto de me-moria. Actualmente, existe una version comercial con bastante difusion

1.4 Compiladores de Plataformas Reconfigurables 29

llamada Impulse C de la empresa Impulse Accelerated Technology, queen la proxima seccion se detallara.

Mitrion-C y el procesador virtual de Mitrionics representa una nuevaaproximacion a la ingenierıa hardware/software para FPGA. El procesa-dor virtual es un procesador de alto rendimiento masivamente paralelo queejecuta software escrito en lenguaje de programacion Mitrion-C. Como sepuede observar en la figura 1.8, el diseno es totalmente independientede la arquitectura de la plataforma reconfigurable. Incluso la validacioncompleta del sistema se puede realizar con estos procesadores virtuales yposteriormente implantar el sistema en una FPGA.

El compilador traduce el programa a un sistema con nodos de proce-samiento y una red de interconexion disenada ”ad-hoc” para cada apli-cacion, guiado con una especificacion concreta de la arquitectura destinodel procesador virtual. El resultado es un cluster paralelo con elementosde grano fino [151].

El entorno de programacion Carte de SRC Computers soporta la me-todologıa de programacion tradicional: escribir el codigo en un lenguajede alto nivel (C y Fortran), compilar, depurar con programas estandar,editar codigo, recompilar, etcetera, hasta una correcta implementacion.En una segunda fase, la herramienta realiza un analisis exhaustivo de laaplicacion. Con esta informacion se configura un procesador, definiendolas unidades funcionales y su paralelismo, proporcionando un procesadoreficiente para ejecutar el codigo particular resultante de la primera fase.Este procesador se configura en el dispositivo MAP.

Esto quiere decir que la configuracion del procesador es ajustada es-pecıficamente a la aplicacion en tiempo de diseno, en lugar de realizar unaplanificacion en tiempo de ejecucion por parte de un procesador general.

El compilador MAP genera un fichero ejecutable Linux que incorporalos modulos objeto del microprocesador, el bitstream de la configuracionMAP y todas las bibliotecas runtime necesarias. El entorno CARTE tie-ne un emulador de MAP, permitiendo una validacion funcional bastanterapida y utilizando depuradores estandar.


Figura 1.8: Ciclo de diseno del procesador Mitrion.

1.5. Adecuacion de los lenguajes al diseno hardware

En esta seccion, se analizan y comparan los diferentes lenguajes vistoen las secciones anteriores. El analisis intenta profundizar en los conceptosque afectan a la capacidad de abstraccion y la expresividad del lengua-je. El primer aspecto es la forma de expresar en general un algoritmo.Por consiguiente, se analizan los paradigmas clasicos de programacionpara el diseno hardware. Los siguientes puntos consisten en analizar lasdiferencias entre las aplicaciones hardware y las aplicaciones software.Concretamente: el modelo de paralelismo, la planificacion temporal, el

1.5 Adecuaci on de los lenguajes al dise no hardware 31

sistema de tipos y el modelo de comunicaciones.

1.5.1. Paradigmas de programacion para computacion reconfi-gurable

En la historia de la programacion se han planteado diferentes para-digmas o enfoques particulares para el desarrollo de software. La cuestiones como afecta la aplicacion de estos paradigmas a la computacion recon-figurable. El analisis crıtico de los diferentes paradigmas va a mostrar suspuntos fuertes y debiles.

El primer paradigma es el propio de los lenguajes de descripcion hard-ware estandar, cuyo representante para este estudio es el VHDL. Estoslenguajes tienen un alto nivel de utilizacion y estan totalmente orienta-dos al diseno hardware, por lo que serviran como referencia al resto deparadigmas heredados de los lenguajes de programacion. El objetivo esexplorar al maximo las caracterısticas de cada paradigma y abstraer de-talles de implementacion. Ası pues, lo que se analizara basicamente esun lenguaje de programacion, no el lenguaje hardware derivado de este.Otros motivos para este criterio de seleccion de acuerdo con la tendenciaactual que los mismos lenguajes de programacion estandar sirvan paradescribir hardware sin anadir nuevos constructores. Los paradigmas bajoestudio son los lenguajes orientados a objetos, los lenguajes funcionales ylos lenguajes basados en algebra de procesos.

Los lenguajes orientados a objetos mas utilizados en el desarrollo deaplicacion en hardware son el C++ y el Java. Se ha elegido el Java por-que es mas simple conceptualmente, y sintetiza mas las propiedades delparadigma. El lenguaje representante del paradigma funcional es el Stan-dard ML (SML) y el representante para el paradigma basado en algebrade procesos es el Circal. Su seleccion es debida a que existen versionesde compiladores especıficos hardware para estos dos lenguajes, que sonHML y SCCircal respectivamente.

Se ha confeccionado una lista de capacidades intrınsecas al diseno desistemas hardware que serviran para comparar los paradigmas. GarethLee y de George Milne [89] realizaron un trabajo comparativo de pa-radigmas basado en una aplicacion interesante donde se podıan utilizarmuchas tecnicas para describir el sistema. Los parametros de este trabajohan sido la base para la lista propuesta en la Tabla 1.2 que a continuacion


se enuncia:

La descripcion estructural es la capacidad de combinar subsis-temas mas simples para construir un sistema mas complejo. Estapropiedad, que permite reutilizar componentes, incentiva el uso desubsistemas versatiles y genericos.

La descripcion funcional es la capacidad de expresar algorıtmica-mente un sistema hardware con las sentencias del propio lenguaje.

La inferencia de estado es la capacidad de describir un compo-nente con memoria, es decir que pueda definir biestables o estadosfinitos de un automata.

El termino interfaces se refiere a que esten bien definidas las formasde interaccion de un subsistema con el resto. Las interfaces permitenla abstraccion y la encapsulacion del subsistema.

El termino repeticion es la posibilidad de replicar componentessimilares para definir circuitos regulares, muy utilizados en las des-cripciones estructurales de los circuitos.

El paralelismo es la capacidad de expresar y ejecutar sentenciasconcurrentes o rutinas en paralelo.

La inferencia de tipos es la capacidad de realizar un analisisestatico del programa y a partir del tipo de las entradas de unafuncion deducir el tipo de cada variable [59].

La parametrizacion es un caso concreto de la genericidad. Con-siste en definir un componente de forma generica dependiendo deuna serie de parametros. En el momento de instanciar un compo-nente en tiempo de compilacion, se proporcionan valores a estosparametros, generando un componente especıfico que reutiliza ladescripcion generica. Por ejemplo, se describe un sumador con unparametro que indica el tamano de los operandos, de esta forma ca-da vez que se necesite cualquier sumador se utiliza esta descripcionindicando el tamano.


Java VHDL SML Circal

Descripcion estructural Sı Sı Sı SıDescripcion funcional Sı Sı Sı PocoParalelismo Sı Sı Poco SıInferencias de estados Sı Sı Casi SıParametrizacion Sı Sı Casi CasiInterfaces Casi Sı Casi CasiRepeticion Sı Sı Sı CasiHerencia Sı No Poco NoPolimorfismo Sı Sı Sı NoInferencia de tipos No No Sı No

Tabla 1.2: Comparacion de lenguajes segun diversas propieda-des. Cada propiedad esta calificada con los siguientes terminos:“Sı ”indica que tiene la propiedad totalmente; “Casi” indica quehay alguna limitacion; “Poco ”indica que la propiedad esta muylimitada; “No ” indica que no se tiene esa propiedad.

En la Tabla 1.2 se realiza una comparacion de los lenguajes basadosen las propiedades descritas. A continuacion se describen las limitacionesde cada lenguaje.

Java cumple todas las propiedades, excepto la inferencia de tipos yalguna limitacion en las interfaces. Las clases de Java no separan explıci-tamente sus interfaces de sus implementaciones como ocurre en algunoslenguajes orientados a objetos. Sin embargo, permite definir una o variasinterfaces, incluso ninguna. Las multiples interfaces permiten herenciamultiple. En cuanto a la inferencia de tipos, existe algun lenguaje orien-tado a objetos como el Self que sı tiene algun mecanismo de inferencia detipos para algunas cuestiones concretas, pero no tiene un uso tan difun-dido como en el paradigma funcional.

El lenguaje VHDL no tiene las propiedades de herencia e inferencia detipo. Son las propiedades mas cercanas a los lenguajes de programacion.El resto son propiedades que permiten facilitar el diseno hardware, porlo que es normal que las posea. La herencia ha sido incluida en otroslenguajes de descripcion hardware como el System Verilog, y tambienhay propuestas para adaptar el VHDL al paradigma orientado a objetos


[51, 10].

Standard ML no tiene mecanismo explıcito para describir el parale-lismo y funciona con unico flujo de ejecucion. Sin embargo, no todos loslenguajes funcionales tienen esa limitacion, pudiendo ejecutar varios hilosde ejecucion (threads), cada uno con su propia pila de llamadas. Por ejem-plo, el lenguaje Erlang es un lenguaje funcional y permite el paralelismo.

En los lenguajes funcionales, no existen variables, esto es una limita-cion para inferir estados. No obstante, existen algunos mecanismos pararepresentar el estado en lenguajes funcionales. Uno es utilizar la pila dellamada para representar el estado. Las funciones solo pueden devolverun unico valor, lo que limita mucho las interfaces. La herencia se puedeobtener por composicion de funciones, con la limitacion de que no se pue-den remplazar o eliminar capacidades.

La inferencia de tipos es una tecnica de los lenguajes funcionales paraobtener el polimorfismo. El Circal no tiene un mecanismo explıcito pa-ra describir el comportamiento funcional. De hecho es habitual que estoslenguajes esten empotrados en otros lenguajes de un paradigma diferente.Solo funciones muy basicas como una tabla de verdad se podrıan describircon Circal. Es el mismo caso que la parametrizacion, que solo es utilizadaen el generador de procesos de XCircal.

Los estados se pueden describir como una evolucion de procesos. Cir-cal no tiene mecanismo descripcion para replicar sistemas. Sin embargo,cuando se combina con lenguajes imperativos, como es el caso de XCir-cal, se utilizan las sentencias iterativas propias del paradigma imperativo.

La definicion de interfaz en el lenguaje Circal no tiene la misma po-tencia que en otros lenguajes, ya que no tiene posibilidad de descripcionde funcion. La forma de definicion de la interfaz esta basada en que cadaproceso de Circal tiene una clase asociada. Estas clases se definen comoun conjunto de acciones a las que el proceso esta subscrito.

1.5.2. Modelo de paralelismo

La programacion de un procesador y la descripcion del hardware tie-ne como diferencia fundamental el modelo de ejecucion. El modelo de


los procesadores, derivado de la maquina de Turing, consiste en la ejecu-cion secuencial de instrucciones comunicadas con una memoria, mientrasque el hardware es una composicion de componentes concurrentes. Porello, los algoritmos secuenciales que son eficientes en software, rara vezson la mejor opcion para la descripcion del hardware. Esto tiene gravesconsecuencias para los programadores de software cuando van a disenarhardware, y es que sus criterios y metodologıas no son tan utiles en estetipo de disenos.

La programacion paralela es en general mas eficiente y permite adap-tarse facilmente a otros modelos computacionales, ya sean sistemas mul-tiprocesador, sistemas hardware o arquitecturas reconfigurables. En cam-bio, la productividad es muy alta si se utiliza el modelo de ejecucionsecuencial, por su facilidad para describir sistemas, y su facilidad paraverificar los programas. Por ello, la metodologıa general es partir de unaversion secuencial y adaptarla al paralelismo de la plataforma que se quie-re ejecutar.

Hay tres formas de explotar el paralelismo de un codigo secuencial enfuncion de su granularidad. La primera consiste en buscar el paralelismoa nivel de instruccion u operacion. Consiste en agrupar instrucciones queno tengan dependencias entre ellos, por lo que se pondran ejecutar con-currentemente si se proporciona la circuiterıa necesaria.

La segunda es la segmentacion o paralelismo temporal que requieremenos hardware y puede ser menos efectiva. Consiste en dividir una ope-racion en varias etapas. Varias ejecuciones de esta operacion se solapanen el tiempo, de tal forma que las etapas se ejecutan concurrentementepero trabajando con diferentes operaciones.

La tercera constituye la granularidad mas gruesa y es el paralelismoa nivel de procesos. Consiste en distribuir las tareas en varios procesossimultaneos. Esta opcion puede ser mas efectiva que el paralelismo degrano mas fino, dependiendo del algoritmo. No obstante este paralelismoes difıcil de identificar automaticamente. La descripcion a nivel de siste-ma tiene inherentemente esta clase de paralelismo.


Forma de expresar el paralelismo

La primera forma consiste en poder expresar el paralelismo directa-mente por parte del disenador. El disenador especifica de forma impera-tiva el codigo que se ejecuta en secuencial y el codigo que se ejecuta enparalelo, y como se sincronizan los diferentes procesos. Esta propuestabusca el paralelismo a nivel de instruccion, muy adecuado para los sis-temas hardware. La implementacion de una instruccion con uno o variosoperadores hardware tiene una gran flexibilidad, utilizando tantos opera-dores concurrentes como sean necesarios, siendo su lımite el area globaldel circuito. Claros ejemplos son los lenguajes Handel-C, Haydn-C, Mo-bius y XCircal que tomaron las primitivas del Occam, un lenguaje deprogramacion paralelo a nivel de instruccion.

La segunda forma consiste en trasladar la responsabilidad de paraleli-zar al compilador. Dado un programa secuencial, el compilador identificalas instrucciones que se pueden ejecutar simultaneamente. Esto implicael analisis de las dependencias entre las instrucciones y la planificacionde las instrucciones para obtener el maximo paralelismo. Existen en al-gunos lenguajes, como por ejemplo Forge y Galabriel, constructores quepermiten determinan la estructura concreta de circuito para un bloquede sentencias.

1.5.3. Planificacion temporal

La tarea de definicion arquitectonica de un sistema, donde basicamen-te se realiza una planificacion temporal con los operadores disponibles, esla mas costosa en tiempo de los disenos de descripcion no comportamen-tales. En contraposicion es la tarea que proporciona mas eficiencia en elcircuito final, o mejor dicho, es la tarea que permite ajustarse mejor alpunto del espacio de diseno dependiendo de los requerimientos del siste-ma.

La descripcion estructural que ofrecen algunos lenguajes permite te-ner un gran control sobre la temporizacion, ya que el diseno de un circuitosecuencial sıncrono se define como un camino de datos y una unidad decontrol. El camino de datos esta constituido por todos los componen-tes interconectados necesarios para realizar las funciones del sistema. Launidad de control es el componente que gobierna el resto. Esta unidad


de control se define como un automata de estados finitos, permitiendoasignar el numero de ciclos necesario a cada operacion. Por ejemplo, elentorno Polis utiliza el lenguaje Esterel para definir este automata y elOCAPI permite definir facilmente este tipo de sistemas.

Los lenguajes que explotan la descripcion comportamental o algorit-mo, tienen que incorporar restricciones para que un conjunto de instruc-ciones se ejecute en un numero de ciclos y el programador debe conocercomo determinar el numero de ciclos. Esto implica que la metodologıapara el desarrollo del sistema consista en definir primero el algoritmo yluego refinar el programa anadiendo restricciones para adaptarlo a las ne-cesidades temporales del diseno. Normalmente, las herramientas permitenanalizar el diseno y detectar cuellos de botella (el bloque de sentencia quetiene mas coste temporal).

Los lenguajes Cones y CASH no tienen ningun o poco control sobreel aspecto temporal, es decir, el sintetizador utiliza un algoritmo voraz yfijo para definir la planificacion temporal del circuito. El primero generaun circuito combinacional lo mas rapido posible. El segundo genera uncircuito secuencial asıncrono.

Transmogrifier C y Handel-C usan reglas fijas para insertar ciclos dereloj. Las reglas de Handel C consisten en que cada una de las asignacio-nes y la sentencia “delay” se ejecutan en un ciclo de reloj. Las reglas deTransmogrifer C son bastante simples: cada iteracion y cada llamada auna funcion se ejecutan en un ciclo de reloj.

Hadyn-C [44] propone dos tipos de descripciones con modelos tempo-rales diferentes: una descripcion RTL y una comportamental. La descrip-cion RTL es la misma que en Handel-C, donde cada sentencia se ejecutaen un ciclo. La herramienta solo sintetiza este tipo de descripcion. Elcodigo de la descripcion comportamental es igual a la descripcion RTLmas unas sentencias especıficas que indican como se debe implementar elresto del codigo. Los aspectos arquitectonicos definidos en estas senten-cias se utilizan para generar una estructura de operadores que mejora elarea y/o la respuesta temporal. Estos aspectos pueden ser, por ejemplo,el numero de operadores de un tipo disponible o si se utilizan tecnicasde segmentacion o no. La generacion de una estructura de operadores es


Listado 1.3: Codigo sin optimizar.✞

12 @resource . set ( p ipe mult :UNITS : 2 ;LAT: 6 ;OP∗ ) ;3 component quad r a t i c s o l u t i on s {4 in int 32 a ;5 in int 32 b ;6 in int 32 c ;7 out int 2 num sol ;8 code {9 int 32 de l t a :

10 { // code t i e n e l a s i g u i e n t e o r g an i z a c i o n11 @scheduler . run ( I I : 1 } ;12 de l ta=b∗b−((a∗c ) <<2);13 i f ( de l ta > 0) num sol :=2;14 else i f ( de l t a==0) {num sol=1;}15 else { num sol=0}16 }17 }18 }

✡✝ ✆

realizada por un traductor de descripcion comportamental a descripcionRTL. Las sentencias especıficas para la descripcion comportamental soninterpretadas como comentarios por parte del simulador.

Se va a ilustrar con un ejemplo el calculo del numero de solucionesde un ecuacion cuadratica (ax2 + bx+ c = 0). El listado 1.3 correspondeal codigo Haydn-C de una descripcion comportamental. Las sentenciasque indican los aspectos arquitectonicos de la descripcion comportamen-tal son las lıneas 1 y 10. La lınea 1 indica al traductor que utilice elcomponente pipe mult para las operaciones de multiplicacion (*), que esuna unidad segmentada con una latencia de 6 ciclos y se limita su usoa dos unidades. La lınea 10 indica que se organiza el codigo de la lınea7 a la 17 con los recursos que se han definido previamente, en este casoen la lınea 1. El parametro introducido (II) indica el numero de estadosiniciales. El resultado de la traduccion es el listado 1.4.

El primer listado 1.3 es un codigo sencillo facil de simular, lo que im-plica que la productividad del desarrollo sera alta. El inconveniente esque este codigo no tendra un circuito final eficiente. La sentencia de lalınea 11 tiene dos multiplicaciones y una resta, es el cuello de botella, yforzara a una frecuencia de reloj muy baja.

En contraposicion se tiene el segundo listado 1.4 mas complejo y masdifıcil de depurar por lo tanto mas difıcil de mantener. En cambio, es muyeficiente y el rendimiento del circuito es mucho mas alto, permitiendo te-


Listado 1.4: Codigo optimizado.✞

1 @resource . set ( p ipe mult :UNITS : 2 ;LAT: 6 ;OP∗ ) ;2 component quad r a t i c s o l u t i o n s {3 in int 32 a ;4 in int 32 b ;5 in int 32 c ;6 out int 2 num sol ;7 code {8 int 32 de l ta :9 { // code t i e n e l a s i g u i e n t e o r gan i za c i o n

10 par{11 @scheduler . run ( I I : 1 } ;12 unsigned 32 tmp [ 3 ]13 //====================== Etapa 014 pipe . mult [ 0 ] . in (b , b ) ;15 p ipe . mult [ 1 ] . in (a , c ) ;16 //====================== Etapa 717 tmp[0]= pipe . mult [ 0 ] . q ;18 tmp[1]= pipe . mult [ 1 ] . q << 2 ;19 //======================= Etapa 820 tmp [2 ] := tmp[0]−tmp [ 1 ] ;21 //======================= Etapa 922 i f (tmp [ 2 ] > 0) num sol=2;23 else i f (tmp[2]==0) num sol=1;24 else num sol=0;25 delay = tmp [ 2 ] ;26 }27 }28 }

✡✝ ✆

ner mucho mas control sobre el hardware generado.

En el sistema de desarrollo de Haydn-C [43] se han incorporado tra-ductores de Comportamental a RTL y de RTL a Comportamental, conla finalidad de poder utilizar indistintamente las dos descripciones paraobtener las ventajas de ambas. Ası, se intentara buscar el control del hard-ware generado por la descripcion RTL y obtener la productividad y el facilmantenimiento gracias a la flexibilidad de la descripcion comportamental.

En la tabla resumen 1.3 estan los diferentes sistemas de temporiza-cion, vistos en esta seccion, con ejemplos para cada caso.

1.5.4. Sistemas de tipos

El concepto de tipos de datos es muy diferente entre los lenguajes desoftware y hardware. La informacion en un programa esta almacenadaen la memoria principal y el tamano de los tipos simples de datos es lalongitud de palabra del procesador. Ası, un entero tiene el tamano de lalongitud de palabra del procesador, que actualmente es de 32 o 64 bits. El


Temporizacion Lenguajes

Implıcito Asıncrono Cones, CASHReglas fijas Handel-C, Transmogrifier-C

Parametrizable Haydn-C, Forge, Galadriel/Nenya

Explıcito HDL, Ocapi

Tabla 1.3: Clasificacion de lenguajes dependiendo del sistemade temporizacion.

tamano de las variables en un programa no es muy significativo ya que sucoste es estrictamente el mismo, costarıa lo mismo el acceso a un enterode 12 bits que a un entero de 32 bits. En cambio en los disenos hardware,

Sistema de tipos Ejemplos

Inferencia Tipos HML, Gel y DIL

Empotrado System-C, SeaCumber y OCAPI

Longitud explıcita de bits Pebble, VHDL/Verilog y Hardware-C

Declaracion externa C2Verilog y Transformiger-C

Tabla 1.4: Ejemplos de Sistema de tipos.

la longitud de los operandos influye significativamente y directamente enel area y en la respuesta temporal del circuito resultante. En los lenguajesde descripcion de hardware los tipos que se manejan son escalables porsu longitud, es decir existe un atributo obligatorio del tipo, que especificaconcretamente el numero de bits. Se pueden encontrar cuatro formas deespecificar este atributo del tipo de datos para disenos hardware, comose puede ver en la tabla 1.4. Estas son:

1. De forma externa al lenguaje, se concreta la longitud de cada variableusando los tipos de datos del lenguaje de programacion correspon-diente. Esta es la opcion utilizada por C2Verilog. Existe un asistentegrafico que presenta todas las variables del programa y permite esta-blecer la longitud de palabra de cada una de ellas. Una variante a estesistema es utilizada por el Transmogrifier C que utiliza la directiva delpreprocesador #pragma para especificar la longitud del tipo de dato


concreto. Si se quiere que los enteros sean de 8 bits, se incluye la sen-tencia #pragma intbits 8 y a partir de esa lınea las variables enterasseran de 8 bits para el sintetizador.

De esta forma, el mismo programa fuente se puede utilizar para di-ferentes propositos como puede ser la simulacion o la sıntesis. En elmomento de la simulacion, se asume que los tipos de datos tienen lalongitud por defecto y en el momento de la sıntesis se tiene en cuentala informacion proporcionada por las directivas o por el asistente.

2. Se modifica el lenguaje para incluir tipos de datos concretos especi-ficando la longitud. Por ejemplo, Hardware C incorpora un tipo devector logico, Haydn-C y Trindent tienen enteros con un atributo indi-cando la longitud de estos. Por ejemplo Haydn-C declara una variableentera “ejemplo” de 6 bits utilizando la sentencia “int 6 ejemplo”,la misma declaracion en Trident es i6 ejemplo y en HardwareC esboolean ejemplo[6]. Esto permite al disenador adaptar la longitudde los operandos de forma explicita segun las necesidades, de forma si-milar a como se realiza en VHDL o Verilog. El inconveniente es que estesistema crea una dependencia con el compilador. Si el codigo se quierereutilizar para otro fin, como por ejemplo la simulacion, se tendra quereescribir o adaptar el traductor o simulador para estos tipos de datosno estandar.

3. El lenguaje incluye un tipo de datos concreto que especifica la longitudde palabra. Esta inclusion no afecta al compilador, sino que el propiolenguaje permite incluir nuevos tipos de datos definidos por el usuario.Esto es posible en los lenguajes orientados a objetos, como el System-C, Ocapi y Sea Cucumber [141] . Los cuales incluyen clases que defineneste tipo de datos orientados al diseno hardware.

Estas clases definen tipos como booleano o bit, entero de diferentestamanos e incluso clases para tratar numeros en coma fija. La mayoraportacion respecto al anterior es que el codigo se puede reutilizar paraotro proposito, como para modelar o simular.

4. No se especifica la longitud del tipo, se obtiene de forma automatica enun proceso llamado inferencia de tipos. Las variables intermedias deloperando se ajustan al tamano inferido despues de la compilacion, enlas representaciones internas del ciclo de desarrollo. El unico lenguaje


imperativo que utiliza la inferencia de tipos es el lenguaje DIL utilizadoen Piperench. Normalmente, se utiliza dentro del paradigma funcionalcomo a los lenguajes Gel y HML. La inferencia de tipos en el paradigmafuncional se utiliza para implementar el polimorfismo. Los lenguajesGel y HML heredan de sus respectivos lenguajes anfitriones SML yScheme estas caracterısticas, permitiendo describir sistemas con unnumero muy reducido de declaraciones de tipo proporcionando un nivelde abstraccion comportamental muy alto.

1.5.5. Modelo de comunicaciones

Los lenguajes de programacion imperativos tienen un modelo de co-municacion basado en un sistema de memoria RAM. La conversion ahardware tiene que convertir una posicion de memoria a un cable o un re-gistro, o trasladar parte de la memoria a porciones pequenas de memorias.

Por ejemplo, Cones tiene el modelo de comunicaciones mas simple,todas las variables, incluidos los vectores, son interpretados como cables.El compilador CASH aplica la solucion de fuerza bruta. Sintetiza una me-moria donde almacena todas las variables y los vectores. Los compiladoresHandel-C y C2Verilog pueden partir la memoria en multiples regiones yasignar cada una a un elemento de memoria. Handel-C tiene constructoresadiciones para este fin. System-C tambien tiene declaraciones explıcitaspara regiones de memoria separadas.

Problematica con los punteros de memoria

En los disenos orientados al hardware no es normal el uso de pun-teros, ya que no se utiliza una memoria donde estan almacenadas todaslas variables. Pero sı es interesante que los compiladores hardware per-mitan traducir completamente lenguajes de programacion estandar parareutilizar el mismo codigo en el diseno hardware. De esta forma, un codi-go puede ser utilizado tanto para programar un microprocesador comopara describir hardware o modelar un componente, y solo se realiza elmantenimiento de un unico codigo. En esta lınea estan los sintetizadoresC2Verilog, C2H de Altera y CatapultC[24].

El primer problema basico es que la direccion de memoria almacenada


en el puntero se obtiene en tiempo de ejecucion, y esta no siempre puedeconocerse en un analisis estatico en tiempo de compilacion.

El mayor problema en el manejo de punteros para el diseno hardwa-re es el denominado ‘aliasing”. Esta situacion se produce cuando existenvarias sentencias que leen y escriben sobre el mismo puntero. Si un punte-ro puede ser escrito por varias sentencias, esto implica que el compiladorhardware tiene que poner un circuito (multiplexor) para seleccionar el va-lor correspondiente al puntero. Por lo tanto es necesario saber los posiblesvalores en tiempo de compilacion. Este analisis en tiempo de compilacionde puntero tiene un gran coste computacional [133], por lo que se utilizanaproximaciones.

Adicionalmente, existen dos metodos para incorporar informacion alcodigo para acelerar el algoritmo de analisis de punteros. El primero es eluso del atributo de tipo “restrict”, introducido en las especificaciones delestandar ISO C99, para que el compilador ignore las posible implicacionesdel aliasing del puntero correspondiente. El segundo es la utilizacion de laextension definida en ISO TR180137 para procesadores empotrados [78].

Comunicacion entre procesos

Las comunicaciones de grano fino vienen determinadas, como se hadescrito anteriormente, por el acceso a una variable o por la conexion deuna senal o un registro, segun el caso. En cuanto al sincronismo de estascomunicaciones, la forma mas conocida es la utilizacion de directivas desincronismo heredada del algebra de procesos (CCP,CSP) que establececanales de comunicacion bloqueantes.

Las comunicaciones de grano grueso impulsadas por los co-disenoshardware/software necesitan extender su repertorio de sistemas de comu-nicaciones. Estas son similares a las utilizadas en los lenguajes de pro-gramacion con la finalidad de tener un sistema uniforme que sirva paracomunicar procesos tanto hardware como software. Los lenguajes Spec-C, System-C y Kiwi [65] estan en esta lınea. Aunque hay otras opcionesque intentan abstraer el sistema de comunicacion y proponen un unicosistema fijo y potente de comunicacion. Este es el caso de Impulse-C. Losprocesos tanto hardware como software se comunican con streams o flujo


de datos. Estos flujos de datos son variantes de los canales del mode-lo de programacion CSP. Su funcionamiento consiste en que un procesoemisor almacena la informacion en un buffer de datos que recogera en elmomento que considere oportuno el proceso receptor y se bloqueara elproceso emisor cuando este lleno el buffer y el receptor cuando este vacıo.La implementacion del buffer de datos se realiza con una memoria FI-FO con relojes independientes para lectura y escritura, de esta forma losprocesos emisor y receptor no comparte el mismo reloj. Otro sistema decomunicacion es el proporcionado por el compilador CHIMPS [124]. Estecompilador esta orientado a arquitectura hıbrida CPU-FPGA . El comu-nicacion se basa en tener muchas caches pequenas y se evita que unadireccion de memoria sea compartida con varias memorias cache por lotanto no es necesario un sistema hardware para resolver la coherencia decaches.

En la tabla 1.5 se resume los diferentes sistemas de comunicacion vis-tos en esta seccion, con ejemplos para cada caso.

Abstraccion Modelo Lenguajes

Implıcito Cables ConesRAM CASH

Cable/RAM HDL,Handel-C,System-C

Explıcito Canales bloqueantes Lenguajes basado en CSPFIFO Impulse-CCaches CHIMPS

Varios modelos Kiwi

Tabla 1.5: Clasificacion de lenguajes dependiendo del sistemade temporizacion.

1.6. Conclusiones

Este capıtulo proporciona una vision amplia de los lenguajes y entor-nos para desarrollar aplicaciones hardware. Se ha estudiado con especialinteres la capacidad de abstraccion de los lenguajes de descripcion dehardware como formula para incrementar la productividad, ası como las

1.6 Conclusiones 45

diferencias de expresividad de los lenguajes para aplicaciones hardware ypara aplicaciones software.

El objetivo de este estudio es contrastar la capacidad de abstracciondel lenguaje utilizado en esta tesis y las aportaciones realizadas con loslenguajes de descripcion hardware mas actuales. El lenguaje utilizado esun lenguaje empotrado que permite obtener las ventajas de los lenguajeshardware ANSI y a la vez permitir orientar el circuito resultante utilizan-do constructores arquitectonicos, de forma similar al lenguaje Haydn-C.El paradigma de este lenguaje es el orientado a objetos que permite te-ner una gran capacidad de abstraccion y se ha incluido un mecanismode inferencia de tipos que permite omitir la especificacion de la longitudde palabra de las variables intermedias. Este lenguaje se estudiara condetalle en el proximo capitulo, y el mecanismo de inferencia de tipos sedescribira en el capıtulo 3.

CAPITULO 2Interfaz de entrada y sıntesis

funcional del entorno detrabajo Madeo

En este capıtulo, se va a presentar el lenguaje utilizado para la des-cripcion de aplicaciones hardware, ası como su entorno de trabajo Madeo[88]. Se hara hincapie en como se realiza la sıntesis funcional de los cons-tructores especıficos disenados para las aplicaciones DSP.

En la siguiente seccion se describe el entorno Madeo, basado en Small-talk, y las aportaciones realizadas dentro de este en esta tesis. En lasegunda seccion, se describe basicamente como se realiza la sıntesis fun-cional, es decir, como se transforma una especificacion algorıtmica en unarepresentacion interna [34][60]; en nuestro caso se trata de un grafo deoperadores. Finalmente, en la tercera seccion se describe un sistema devalidacion de los resultados obtenidos por el sintetizador.

47

48 Capıtulo 2 Interfaz de entrada y sıntesis funcional del entorno de trabajo Madeo

2.1. Madeo: Un entorno de diseno para arquitecturasreconfigurables

El entorno de diseno Madeo esta desarrollandose desde principios dela decada de los 90 en el grupo de Architectures et Systemes de la Uni-versite de Bretagne Occidentale, del que soy colaborador. Previamente,este grupo de investigacion trabajo en el proyecto Armen, que consistıaen la fabricacion de una plataforma de computacion reconfigurable cons-tituida por una maquina MIMD, donde cada nodo estaba formado porun Transputer (procesador de proposito general con una arquitectura depila y 4 enlaces de comunicaciones serie, de alta velocidad para la epoca)interconectado con una FPGA.

Las conclusiones del proyecto Armen para mejorar la productividaddel desarrollo de aplicaciones para las plataformas de computacion recon-figurable se pueden resumir en las tres siguientes:

La programacion de un sistema complejo, compuesto de varios mo-delos de computacion, requiere de una especificacion uniforme y unageneracion de codigo especıfico para cada modelo computacional.

En general, las aplicaciones no explotan todas las posibilidades delas arquitecturas reconfigurables. Esto es debido al dominio de laherencia de las herramientas de VLSI CAD sobre las herramien-tas utilizadas. Los operadores utilizados por estas herramientas soncomponentes de bibliotecas pre-sintetizadas, y por lo tanto exclu-yen la posibilidad de implementar operadores especıficos con mayorrendimiento.

El diseno de una plataforma de computacion reconfigurable necesi-ta realimentarse de los resultados precisos del rendimiento. Ası, seanaliza el diseno para diferentes tipos de aplicaciones, permitien-do sucesivas mejoras. Actualmente, esto no es posible hasta que nose realiza completamente la implementacion fısica de la platafor-ma, ya que los fabricantes de dispositivos reconfigurables imponenla utilizacion de sus herramientas para la produccion de sus co-rrespondientes configuraciones. Esto impide evaluar el rendimientoglobal de las aplicaciones en una plataforma, dada la escasa posibi-lidad de integrar los dos tipos de herramientas (la de desarrollo delas aplicaciones y la de implementacion fısica).

2.1 Madeo: Un entorno de dise no para arquitecturas reconfigurables 49

Estas conclusiones motivaron el proyecto Madeo, que consistıa en eldesarrollo de una herramienta EDA abierta para el diseno completo dearquitecturas reconfigurables. A continuacion se describe el esquema ge-neral de la herramienta, que se puede resumir en la figura 2.1, y que poseeuna estructura en la que se pueden distinguir tres niveles en el procesode diseno:

Figura 2.1: Esquema del conjunto de herramientas de Madeo

Nivel de aplicacion. En este nivel se proporciona al disenador desistemas hardware la posibilidad de especificar sus aplicaciones deforma independiente de la plataforma final donde se ejecutaran.La codificacion de la aplicacion se realizara en un lenguaje basa-do en Smalltalk[48], lo que proporcionara un lenguaje y entorno dedesarrollo unificado para describir tanto subsistemas hardware co-


mo software. En la seccion 2.1.2 se explicara detalladamente estelenguaje.

En la parte de la derecha de la figura 2.1 se presentan los pasosconcretos pertenecientes a este nivel.

Nivel de Arquitectura Reconfigurable Virtual. En este nivel se definela arquitectura reconfigurable utilizando un lenguaje de descripcionhardware propio. Con esta descripcion se realiza un modelo de la ar-quitectura reconfigurable virtual para poder evaluar el rendimientoy el funcionamiento preciso de las aplicaciones definidas en el nivelanterior. Posteriormente, pasado el proceso de desarrollo, esta mis-ma descripcion se puede utilizar para la fabricacion del dispositivo.En la parte de la izquierda de la figura 2.1 se presentan los pasosconcretos pertenecientes a este nivel que se veran con mas detalleen la siguiente seccion.

Nivel de Soporte de Ejecucion. En este nivel se dispone de un con-junto de programas que permiten la configuracion, ejecucion y anali-sis del rendimiento de las aplicaciones definidas en el primer nivelsobre la arquitectura reconfigurable virtual del segundo nivel. En laparte inferior de la figura 2.1 se presentan varios programas para elsoporte de ejecucion.

A continuacion se describen con mas detalle las herramientas perte-necientes a Madeo. Primero se presentaran las concernientes al nivel dearquitectura y de ejecucion, y posteriormente las del nivel de aplicacion.

2.1.1. Diseno de la plataforma reconfigurable

La forma clasica de disenar una plataforma reconfigurable consisteen el desarrollo simultaneo de dos procesos independientes: la implemen-tacion fısica de la arquitectura y el desarrollo de las aplicaciones. Conesta metodologıa se corre el riesgo de que el desarrollo de aplicacionesdetecte de forma tardıa problemas de diseno de la arquitectura reconfi-gurable. Madeo propone un sistema que permite la interrelacion de losdos procesos, de forma que el diseno se valida evaluando la ejecucion delas aplicaciones sobre un modelo simulado de la arquitectura reconfigu-rable. Ası, se permite realizar sucesivos refinamientos de la arquitectura,ya que se evaluan las prestaciones y funcionamiento de esta antes de sufabricacion.


No obstante, es imprescindible obtener rapidamente el modelo simu-lado de la arquitectura y que sea fiel a las caracterısticas de la imple-mentacion fısica. Tambien debe permitir automatizar la sıntesis fısica deldispositivo a partir del modelo desarrollado.

Madeo sigue una metodologıa MDA (Model Driven Architecture), de-finida en el campo de la ingenierıa del software y propuesta por el ObjectManagment Group [2], que propone separar el conocimiento experto delcontexto de utilizacion. La metodologıa consiste en definir un modeloindependiente de la plataforma (PIM) o maquina virtual, donde se ejecu-taran las aplicaciones. Este modelo se transformara en el modelo especıficode la plataforma (PSM) utilizando a su vez un modelo de descripcion deplataforma (PDM).

La idea basica es que el conocimiento experto se exprese de una for-ma abstracta e independiente de una plataforma concreta. Esto permiteutilizar este conocimiento en cualquier plataforma; solo es necesario paraello tener definida la maquina virtual para esa plataforma que permiteinterpretar la forma abstracta utilizada del conocimiento experto.

Como se comento anteriormente, el objetivo de Madeo es definir unmodelo software que permita evaluar las prestaciones y funcionalidadessin necesidad de realizar una implementacion fısica completa. Se ha defi-nido un conjunto de clases de Smalltalk para modelar los elementos masbasicos, como los cables, los transistores y los recursos de interconexion,tales como las matrices de conmutacion. Estas clases las llamaremos apartir de ahora PIMmadeo (ver la figura 2.2). El modelo de la plataforma(PSMmadeo) se especificara con un lenguaje estructural, como los vistosen la seccion 1.1, utilizando los elementos de PIMmadeo. A esta descrip-cion estructural la llamaremos PDMmadeo [84].

Para completar el flujo de diseno son necesarias herramientas de so-porte de ejecucion que son el nexo de union con el nivel de aplicacion,de forma que se pueden realizar y evaluar las correspondientes configu-raciones obtenidas en el nivel de aplicacion sobre la plataforma definitivaen el nivel de arquitectura reconfigurable virtual. Este tipo de herramien-tas son bastante complejas y normalmente se desarrollan especıficamentepara cada arquitectura reconfigurable o para una familia de ellas. El desa-rrollo software de estas reutiliza poco o nada partes de otras herramientassimilares. La utilizacion de la metodologıa MDA y el paradigma orientado


a objetos permite la reutilizacion de partes de las herramientas implemen-tadas para otras arquitecturas.

Madeo se ha utilizado para programar dispositivos reconfigurables co-merciales. La informacion de configuracion de los dispositivos reconfigu-rables no es normalmente publica, excepto para las FPGA parcialmentereconfigurables [72]. Concretamente, se han desarrollado aplicaciones pa-ra la FPGA XC6200 de Xilinx [83], para la AT40K de Atmel [63] y parala familia FPGA Virtex de Xilinx [63].

En el caso de la familia Virtex, la informacion no es publica completa-mente sino que el fabricante suministra un interfaz de programacion paraJava, llamada JBits [137], para configurar en detalle los correspondienteselementos de la FPGA.

Soporte de Ejecución

Floorplanning ... Place & routeEstimadores

PIMmadeo

Transformación al modelo software

PDMmadeo

PDMhdl PSMmadeo

Transformación a una descripción hardware

PIMhdl Aplicación

PSMhdl

Figura 2.2: Doble metodologıa MDA para modelar e implemen-tar una arquitectura reconfigurable.

No obstante, donde esta metodologıa tiene mas interes es en el di-seno completo de la plataforma reconfigurable. En esta categorıa se en-cuentra el trabajo realizado para la arquitectura preliminar LPPGA deST-Microlectronics [29] y el aplicado a nano-tecnologıa utilizando la ar-quitectura NASIC [84]. Para este tipo de diseno es necesario pasar del


modelo software (PSMmadeo) a una descripcion hardware para la fabri-cacion del ASIC correspondiente (PSMhdl) como muestra la figura 2.2.Hay que tener en cuenta que PSMmadeo es una descripcion estructu-ral de elementos basicos definido en PIMmadeo. Por tanto, si se obtienela definicion de estos elementos en un lenguaje de descripcion hardware(PIMhdl), se puede utilizar el mismo modelo software PSMmadeo con unlenguaje de especificacion (PSMhdl). La transformacion es bastante senci-lla, y consistira en traducir la descripcion estructural del modelo softwarea la propia del lenguaje de descripcion hardware, concretamente a VHDL.

2.1.2. Sıntesis de Madeo

Codigo

Asignacion

de tipo

compilar−−→ Grafo de

operaciones

Inferencia−−→de tipos

Red deLUT yregistros

Sıntesis−→ Netlist

Figura 2.3: Flujo de procesos de la sıntesis de Madeo.

El proceso de sıntesis que se va a describir es la transformacion deun algoritmo de alto nivel en un netlist que sirva de entrada a las herra-mientas de soporte de ejecucion de Madeo o del fabricante del dispositivoconfigurable para generar el bitstream.

El proceso de sıntesis tiene tres fases, como se puede ver en la figura2.3. La primera fase es la sıntesis funcional, y consiste en obtener un grafode operaciones desde un codigo en un lenguaje similar a Smalltalk, dondelos nodos de este grafo son las operaciones y los arcos representan lasdependencias entre ellos.

La segunda fase es la sıntesis de alto nivel, y consiste en aplicar la in-ferencia de tipos. La informacion obtenida en el proceso de inferencia detipos se utiliza para simplificar el grafo, utilizando optimizaciones clasicas,similares a las utilizadas en el sistema de evaluacion parcial [37], como porejemplo, la eliminacion de subgrafos esteriles. Otra utilidad del procesode inferencia es obtener el circuito de forma generica, basado en una red


de LUT y registros, y sin utilizar bibliotecas de componentes presinteti-zados [85]. Esta fase se estudiara con detalle en los proximos dos capıtulos.

La ultima fase de este proceso es la sıntesis logica, y consiste en trans-formar la red de LUT (que es un netlist generico) en un netlist especificodel dispositivo reconfigurable para que la implementacion sea mas sencillay eficaz. Las LUT obtenidas en la sıntesis de alto nivel son muy grandes(existe un gran numero de variables y por lo tanto un gran numero decombinaciones definidas), por lo que se han de descomponer en tablas maspequenas, ya que normalmente los dispositivos reconfigurables trabajancon LUT de 4 a 8 variables de entrada. Para esta reduccion se utilizanprogramas estandar de simplificacion logica [134, 106, 112]. Por ultimo,se traduce el resultado de la simplificacion logica a un netlist en formatoEDIF o VHDL para su posterior implementacion final. Esta fase se estu-diara en detalle en el capıtulo 4.

A continuacion se describen las caracterısticas del lenguaje que utilizaMadeo para describir sus aplicaciones.

En el capıtulo anterior se vio que la ultima tendencia para ESL esutilizar un lenguaje de programacion que sea un estandar ANSI. Con ellose consigue la flexibilidad de poder ejecutar una funcion tanto en un pro-cesador de proposito general como en una unidad funcional de propositoespecifico. Otra opcion muy interesante en esta lınea es utilizar un lengua-je empotrado. Un lenguaje de descripcion empotrado se implementa pormedio de una biblioteca en un lenguaje de programacion ya existente (ellenguaje huesped ). Por ejemplo, Lava [39] es un lenguaje empotrado dedescripcion hardware cuyo huesped es el lenguaje funcional Haskell. Deesta forma, estos lenguajes obtienen las mismas ventajas de los estandaresANSI y ademas pueden definir constructores especıficos para incluir ca-racterısticas arquitectonicas a la descripcion. Esta es la opcion elegida enMadeo, cuyo lenguaje huesped es Smalltalk, un lenguaje de programacionorientado a objetos con una sintaxis muy simple, lo que facilita la imple-mentacion del lenguaje empotrado. Este lenguaje empotrado esta basadoen el tipo abstracto de datos en el que se implementa la tecnica de infe-rencia de tipos tıpica del paradigma funcional. El uso de esta tecnica sedescribira en el siguiente capıtulo.


2.1.3. Aplicaciones y aportaciones realizadas en Madeo

Las aplicaciones desarrolladas en Madeo se dividen en tres lıneas detrabajo principales. Las dos primeras, que se describen a continuacion,fueron llevadas a cabo por el grupo de Architectures et Systeme de laUniversite de Bretagne Occidentale y la tercera es la desarrollada en estatesis.

La primera lınea trabajo consiste en el modelado y sıntesis de cir-cuitos correctores de errores, con tecnicas de turbo decodificadores porbloques [50, 9]. La metodologıa propuesta se basa en utilizar un modeloabstracto funcional independiente del hardware y de la aritmetica. Esemodelo abstracto se aproxima a la descripcion de la teorıa matematica deturbo decodificadores [125, 5]. Madeo obtiene muy buenos resultados conla utilizacion de aritmetica de campos finitos, muy utilizada en el ambitode los circuitos correctores de errores. Este sistema permite la validacionde las aplicaciones y la exploracion de algunos de sus parametros, comopueden ser la codificacion aritmetica o la eleccion de bloque. Esta des-cripcion algebraica expresada en Smalltalk es convertida por Madeo en unlenguaje sintetizable. Incluye tambien un sistema de monitorizacion parala obtencion de trazas, que serviran para obtener diferentes parametrospara dirigir el circuito en el espacio de diseno.

La segunda lınea ha consistido en el desarrollo de arquitecturas hete-rogeneas reconfigurables y la especificacion de sus aplicaciones. Se puedendistinguir tres tipos de aplicaciones:

Modelo de diseno de nuevas arquitecturas reconfigurables [84]

Diseno de aplicaciones para estructuras reconfigurables de granogrueso [29].

Diseno de aplicaciones para arquitecturas heterogeneas reconfigura-bles [145][56].

El estado actual es la integracion de MADEO en el proyecto MORP-HEUS (Multi-purpose dynamically Reconfigurable Platform for intensiveHeterogeneus processing) [145][122][1]. El objetivo principal de este pro-yecto es proporcionar un conjunto de herramientas que define un unico einnovador flujo de diseno y permite programar arquitecturas heterogeneascomplejas desde las metodologıas de alto nivel (MOLEN, CoSy, CASCA-DE, MADEO, SPEAR, SpecEdit). Las plataformas reconfigurables utili-


zadas en MORPHEUS son de ultima generacion en sus correspondientesdominios (PiCoGA, PACT XPP, eFPGA FlexEOS, eFPGA M2000). Lasextensiones realizadas a Madeo han estado relacionadas con la generacionde los mecanismos de sincronizacion a partir de la organizacion espacial(asociacion de procesos a las unidades de ejecucion de la arquitectura he-terogenea) obtenida de las especificaciones de alto nivel [122].

La ultima lınea, desarrollada por el autor de esta tesis, se ha centradoen las aplicaciones de procesamiento digital de la senal. A continuacion,se expondran de forma resumida las aportaciones especıficas de esta lınea.Estas aportaciones se han organizado dependiendo de su ambito de apli-cacion y seran detalladas mas adelante en diferentes capıtulos de estedocumento.

Aportaciones en la especificacion de aplicaciones

Estas aportaciones consisten en adaptar el lenguaje utilizado a lasnecesidades concretas del ambito de las aplicaciones DSP para que loscircuitos resultantes sean correctos y eficaces.

Constructores SIMD. Se han implementado constructores vectorialestıpicos de los DSP que permiten especificar la estructura del circuitopara explorar el espacio de diseno. Las estructuras implementadasestan constituidas por la replicacion de los operadores, proporcio-nando ası paralelismo espacial. La comparticion de los operadoresentre diferentes iteraciones del constructor proporciona una reduc-cion del area utilizada y la segmentacion de operadores proporcionaparalelismo temporal.

Tipo de datos para DSP. Se han incorporado los tipos de datos ente-ros y de coma fija, predominantes en las aplicaciones DSP. Los tiposde datos utilizados en las otras lıneas son modulares, donde el masusado es de campos finitos o de Galois. Estos tienen la propiedadde que sus operaciones son internas y por lo tanto todos los valorescalculados tendran la misma longitud de palabra. En el caso de lostipos incorporados no es ası y la longitud de palabra de cada valorcalculado es variable. Esto conlleva que se incorporen en el procesotareas para el calculo de la mınima longitud de palabra de los tiposinferidos.


Descripcion jerarquica. El sintetizador produce una LUT por cadaoperador. Para el caso de operadores complejos este sistema no dabuenos resultados. La descripcion jerarquica impide que un opera-dor complejo se sintetice en una unica tabla, permitiendo describirla descomposicion de este operador en tablas mas simples.

Validacion automatica. Se ha implementado un sistema de generacionde bancos de prueba para validar la aplicacion en desarrollo y el pro-pio sintetizador, comparando los resultados obtenidos por la ejecu-cion de la rutina software correspondiente con los obtenidos por lasimulacion del circuito en diferentes fases de diseno.

Aportaciones en la sıntesis de alto nivel

Estas aportaciones consisten en mejoras del sistema de inferencia detipos y en codificaciones de los valores para mejorar algun aspecto delresultado final.

Inferencia de tipos cıclica. Existe un constructor SIMD que produceun grafo de operaciones cıclico, por lo que se ha definido un sistemaespecıfico para realizar la inferencia cıclica.

Inferencia de tipos hacia atras. Es una tecnica de optimizacion de lainferencia de tipos. Esta tecnica permite obtener informacion de as-pectos globales del circuito para la simplificacion de los operadores.

Inferencia cuantificada de tipos Es una tecnica cuyo objetivo es ob-tener caracterısticas tales como rango y precision de los tipos deentrada a partir de los tipos de datos de las salidas. Se trata de unproceso iterativo de la inferencia de tipos hacia atras.

Aportaciones en la sıntesis logica

Estas aportaciones tienen como objetivo, por una parte proporcionarun sistema que pueda acometer las necesidades computacionales de lasıntesis logica y por otra parte incrementar la integracion con herramien-tas CAD comerciales.

Entorno computacional de altas prestaciones. El sintetizador se haintegrado en un entorno computacional de altas prestaciones paraobtener los requisitos de memoria y reducir el tiempo total de eje-cucion de la sıntesis logica.


Integracion con CAD comerciales. Inicialmente el resultado de la sın-tesis se proporciona en formato EDIF. Con este formato se puedenintegrar las aplicaciones desarrolladas con otras herramientas de ter-ceros. No obstante se han constatado algunas limitaciones cuando sequiere utilizar algun simulador comercial o biblioteca de componen-tes. Por ese motivo se ha decidido utilizar un lenguaje de descripcionhardware muy difundido como el VHDL.

2.2. Sintetizador funcional de Madeo

Esta seccion trata la descripcion hardware y su transformacion en ungrafo de operadores, que es la representacion interna del circuito utilizadaen MADEO. Actualmente, esta representacion no sigue ningun formatoestandar, aunque en el proyecto MORPHEUS esta previsto que MADEOutilice el lenguaje estandar Express procedente del proyecto STEP ISO[145]. Primeramente se describe la tecnica de compilacion utilizada enel sintetizador desarrollado y luego se estudian las aportaciones en lasıntesis funcional: los constructores SIMD y la descripcion jerarquica parala generacion de bibliotecas genericas de operadores.

2.2.1. Compilador

Madeo se ha desarrollado en el entorno de programacion de Smalltalkmultiplataforma VisualWorks de la compania Cincom. Este entorno tieneclases especıficas para el diseno de compiladores y estas mismas clasesson utilizadas para el propio interprete de Salta del sistema. Las partesde un compilador son: el analizador lexico, el analizador sintactico y elgenerador de codigo. El desarrollo de un nuevo analizador lexico resultasencillo, ya que consiste en reutilizar y adaptar el analizador lexico delinterprete del sistema, utilizando el polimorfismo y la herencia . El anali-zador sintactico se implementa especificando las reglas de produccion desu gramatica. La sintaxis para expresar estas reglas es muy intuitiva. Lageneracion de codigo esta dirigida por sintaxis [8], lo que implica incluiren las reglas de la gramatica invocaciones a otros metodos para producirla salida correspondiente.

En el entorno de Madeo se han desarrollado cuatro compiladores, dosde los cuales tienen lenguaje propio y los otros dos son una variante de

2.2 Sintetizador funcional de Madeo 59

ProcedimientoConstructor Sintaxis de Smalltalk Sintaxis Algorıtmica (clasica)

MetodoNode doMethod:selector: primitive: block: doMethod(selector,primitive,block)BlockNode doBlock: arguments:body: doBlock (arguments,body)

SequenceNode doSequence: temporaries: statements: doSequence( temporaries, statements)AssigmentNode doAssignment: variable: value: doAssignment (variable, value)MessageNode doMessage:receiver:selector: arguments: doMessage(receiver,selector,arguments)ReturnNode doReturn: value: doReturn(value)VariableNode doVariable: name: doVariable(name)LiteralNode doLiteral: value: doLiteral (value)

ParameterNode doParameter: variable: type: doParameter (variable, type)

Tabla 2.1: Asociacion de constructores con procedimientos.

Smalltalk. El primero, con lenguaje propio, ya fue comentado al principiodel capitulo. Se trata de un lenguaje estructural para definir la arquitec-tura del dispositivo reconfiguable. El segundo compilador se vera poste-riormente y consiste en un traductor de la informacion obtenida de lossintetizadores logicos [134] a un netlist que utilizaran las herramientas deproduccion de bitstreams. En estos dos casos el compilador se ha desa-rrollado siguiendo completamente los pasos antes mencionados.

El tercer compilador es el mas importante y al que dedicaremos elresto de este capıtulo. El analizador sintactico de este compilador es massimple que los anteriores, ya que la entrada al sintetizador es una variantedel Smalltalk, por lo que se puede utilizar gran parte del interprete delsistema, como se vera posteriormente. El cuarto compilador se diferenciadel tercero en la generacion de codigo: mientras el tercero generara ungrafo de operadores, el cuarto genera un programa Smalltalk equivalente.

El tercer compilador esta dividido en solo dos fases. La primera consis-te en obtener el arbol sintactico (AST) a partir del programa de entraday la segunda consiste en especificar la generacion de codigo a partir delAST de la primera fase.

La figura 2.4 representa la estructura concreta del arbol sintactico pa-ra el ejemplo de la suma de los elementos de un vector. La simplicidaddel lenguaje se puede observar en la figura, ya que practicamente estantodos los constructores del lenguaje: metodo, bloque, secuencia, asigna-cion, mensaje, devolucion, variable y constante. En cada nodo del arbol,se representa el tipo de constructor y la informacion asociada.


MethodNode #prodescalar

{[s := 0.(1 to: 9) do: [:i | s := s + (A at: i)].^s]}

BlockNode

{s := 0.(1 to: 9) do: [:i | s := s + (A at: i)].^s}

SequenceNode {s := 0} {(1 to: 9) do: [:i | s := s + (A at: i)]} {^s}

AssignmentNode {s} {0} MessageNode {1 to: 9} #do: {[:i | s := s + (A at: i)]} ReturnNode {s}

VariableNode ’s’ LiteralNode 0 MessageNode {1} #to: {9} BlockNode {s := s + (A at: i)} {i}

LiteralNode 1 LiteralNode 9 ParameterNode {i} SequenceNode {s := s + (A at: i)}

VariableNode ’i’AssignmentNode {s} {s + (A at: i)}

VariableNode ’s’ MessageNode {s} #+ {A at: i}

VariableNode ’s’ MessageNode {A} #at: {i}

VariableNode ’A’ VariableNode ’i’

VariableNode ’s’

Figura 2.4: AST de una suma de vector.

Se dispone de una clase para poder generar codigo partiendo del an-terior arbol sintactico. Cada constructor del lenguaje tiene asociado unprocedimiento (ver tabla 2.1), de forma que programando el procedimien-to se particulariza el codigo objeto de salida.

El resultado de este compilador es un grafo de operaciones y el al-goritmo para su generacion es similar al utilizado en la obtencion de laforma SSA (Static Statement Assigment) de un programa [111, 45].

2.2.2. Constructores SIMD: Descripcion basada en bucles

Estos constructores SIMD implementan varias estructuras algorıtmi-cas iterativas para el manejo de vectores. El constructor mas frecuentepara el diseno de un sistema hardware, como vimos en el capıtulo anterior,es el desenrollamiento del bucle que producira una repeticion del circuitocorrespondiente al interior del bucle, para encontrar un compromiso entretiempo de respuesta y area se ha propuesto otro constructor que permitecompartir para todas las iteraciones un conjunto de operadores. Con la


✓✒

✏✑

nuevo:=0.(1 to: 3) expand:[:i|nuevo:=nuevo+((A at:i)∗(B at:i))]

A[1] B[1]

A[2] B[2]

A[3] B[3]

A*B A*B A*B

[0+B]

A+B

A+B

nuevo

Figura 2.5: Especificacion y grafo obtenido al aplicar el metodoexpand: al producto escalar de dos vectores.

combinacion de ambos constructores se podra buscar con mas exactitudel punto deseado en el espacio de diseno del circuito implementado.

Especificacion de un circuito paralelo: expand

El mensaje expand: tiene dos argumentos: el rango y el bloque (o se-cuencia de instrucciones), como se muestra el ejemplo en la figura 2.5. Elrango del ejemplo es ”(1 to: 3)” y representa todos los valores desde el 1al 3 y el bloque correspondiente es la secuencia de instrucciones descritasen Smalltak como ′′[: i | nuevo := nuevo+ . . . ]”.

Este constructor realiza en tiempo de compilacion el desenrollado totaldel bucle para todo el rango definido. Este constructor esta incluido enla mayorıa de los lenguajes de descripcion hardware. Obtiene un gran


paralelismo entre operaciones con un coste elevado de area de silicio.Se ha incluido una variante para explotar el paralelismo temporal, es elconstructor latency:pipeline:. Realiza el mismo grafo que el expand:,pero en el momento de la sıntesis de bajo nivel se segmenta el circuito delbucle con el numero de etapas indicadas en un parametro adicional.

El circuito segmentado se obtiene insertando tantos registros de seg-mentacion como etapas se hayan indicado. Estos registros se insertan enlas entradas primarias formando una cola FIFO, de forma que el circuitocombinacional completo esta en la ultima etapa. El circuito resultanteesta segmentado pero es muy ineficiente. Para mejorar el rendimiento sedebe redistribuir homogeneamente la circuiterıa combinacional entre to-das las etapas. Para ello se ejecuta un algoritmo de planificacion temporal(retiming) del sintetizador logico [134].

Para explotar al maximo el paralelismo del grafo generado por el men-saje expand se reducira la profundidad del arbol. La figura 2.5 muestrael grafo obtenido al aplicar el constructor expand al producto escalar, sepuede observar que el grafo tiene una forma de arbol asimetrico producidopor su construccion secuencial e iterativa.

a[0]

1

a[1]

a[2]

2 a[3]

3 a[4]

4

(a) arbol inicial

a[0]

1

a[1]

a[2]

2

3

a[3]

a[4]

4

(b) Proceso

a[0]

1

a[1] a[2]

3

a[3]

a[4]

4

2

(c) arbol con profundidadreducida

Figura 2.6: Reduccion de profundidad de un grafo de operado-res.

Cada nodo de estos arboles tiene una dependencia de datos con elanterior, por lo cual no hay practicamente paralelismo, es totalmentesecuencial, exceptuando las multiplicaciones iniciales que se realizan si-


multaneamente. Para incrementar el numero de operadores simultaneos,este arbol se tiene que transformar a un arbol mas simetrico y por lo tan-to se reducira su profundidad. Esta transformacion solo se puede realizarsi todas las operaciones que corresponde al grafo son asociativas. Estatransformacion se visualiza en la figura 2.6. El primer grafo de la figura2.6(a) ilustra la situacion inicial que se acaba de explicar con el ejemplodel producto escalar. El segundo grafo de la figura 2.6(b) representa losdetalles de la transformacion. Los arcos representados con flechas discon-tinuas son las salidas del grafo 2.6(a) y los arcos representadas con flechascontinuas son las salidas del grafo 2.6(c). Esta transformacion consiste ensustituir los arcos discontinuos por los arcos continuos. En el caso mostra-do solo hay una transformacion, la generalizacion del proceso consiste enrealizar un recorrido en profundidad, detectando los subarboles asimetri-cos y transformando el grafo 2.6(b). El tercer grafo de la figura 2.6(c)representa el resultado de la transformacion, que es un grafo equivalen-te al primero 2.6(a) pero con un profundidad menor y por lo tanto masrapido.

Especificacion de un circuito secuencial: do:

El mensaje do: tiene la misma sintaxis que el mensaje expand: descri-to en el apartado anterior. Este constructor genera la ejecucion iterativa,tantas veces como indique el rango, de las operaciones contenidas en elbloque, generando un circuito secuencial sıncrono. La evaluacion del ran-go se realiza en tiempo de compilacion. La utilizacion de este mensajegenerara un circuito con poca area y mas lento que en el caso anteriorpor no explotar el paralelismo entre las operaciones. Por lo tanto, paraun correcto funcionamiento del circuito, en cada ciclo de reloj se debenproporcionar los nuevos datos correspondientes.

El circuito resultante tiene tres partes: el circuito correspondiente albloque, el automata para el control y los multiplexores para seleccionarlas entradas.

La figura 2.7 muestra al grafo obtenido al aplicar el constructor do: alproducto escalar de dos vectores. Los nodos de color gris de la figura 2.7son los componentes del circuito implıcito generado por el mensaje do: ycorresponden al automata de control. Este automata esta compuesto delos siguientes elementos:


A[i] B[i] Control 0

A contar: BA*B

#Cuenta

elegir: A

A Mux:(B,C)

A+B

nuevo

nuevo

Figura 2.7: Grafo obtenido al aplicar el metodo do: al productoescalar.

Contador El contador corresponde a la funcion de transicion del automa-ta (es el circuito etiquetado como ”A contar: B”). Se trata de uncircuito combinacional que proporciona el siguiente valor definidoen el rango del constructor. Tiene una entrada de control para in-dicar que el siguiente valor es el cero (resetear) o para indicar queel siguiente valor no cambia, es decir que es actual (parar). Tieneotra entrada donde se debe proporcionar el valor actual que tieneel ındice de la iteracion.

Memoria La memoria del automata es el circuito etiquetado como ”#Cuen-ta”. Es un registro donde se almacena el valor que tiene el ındice dela iteracion.

Selector El selector, que corresponde a la funcion de salida del automata,esta etiquetado como ”elegir:A”. Este circuito combinacional pro-porciona la entrada de control al multiplexor a partir del valor alma-cenado en la memoria del automata. Para obtener la informacion amultiplexar, se evaluan las variables modificadas y consultadas para


cada iteracion. De este modo, se detectan las realimentaciones y lasvariables o constantes externas al bloque del constructor. Las re-alimentaciones son las variables modificadas y consultadas por unaiteracion posterior. En el ejemplo, la salida del multiplexor corres-ponde a la variable nuevo. Ası, en la primera iteracion vale cero,valor de la variable ante de ejecutar el do:, y en el resto de itera-ciones es la realimentacion, ya que en bloque del do: se modifica lavariable nuevo.

2.2.3. Descripcion jerarquica

Existe una gran disponibilidad de bibliotecas de circuitos aritmeticosconvencionales optimizados. Estas bibliotecas estan basadas en organiza-ciones propuestas en la literatura clasica de arquitectura de computadores[119][73][110]. Para aprovechar estas propuestas, se ha incluido en Madeola posibilidad de la descripcion jerarquica, que permite describir estruc-turalmente un operador.Para ello, es necesario definir una biblioteca donde esten almacenadas lasdescripciones detalladas de los operadores. Esta biblioteca esta integradaen el sistema de clases de Smalltalk y sus componentes estan descritos enel lenguaje de sıntesis asociado con Madeo.

De este modo, cada vez que se encuentra un mensaje que produce unoperador en la compilacion, este se buscara en esta biblioteca. Si fallala busqueda, el operador se agregara en el grafo como un operador mas,mientras que si la busqueda tiene exito, se agregara el grafo resultante desintetizar la descripcion almacenada en esta biblioteca.

Hay que tener en cuenta que los operadores vienen caracterizados porsu funcion y el tipo de datos de sus operandos. Por ello, para que lasdescripciones sean genericas, es necesario conocer las caracterısticas delsistema de representacion. Por lo tanto, se deben generar algunas fun-ciones especiales para obtener estas caracterısticas, que seran conocidasen la inferencia de tipos. En las aplicaciones realizadas solo se ha defi-nido una funcion especial que proporciona la longitud de palabra del dato.

El compilador incluira un operador especial cuando encuentre estafuncion. Este operador proporcionara la longitud de palabra al resto deoperadores del grafo. En el momento de la construccion del grafo esta


funcion devolvera un valor maximo por defecto. Posteriormente, cuandoel proceso de inferencia de tipos se aplique al grafo, el valor que propor-cione el operador se optimizara.

A continuacion se veran dos ejemplos de aplicacion de la descrip-cion jerarquica. Concretamente, las funciones en las que se ha utilizadoesta tecnica para las aplicaciones DSP de los experimentos realizados: lasuma y la raız cuadrada.

Sumador

La figura 2.8 ilustra la descripcion jerarquica de un sumador. La orga-nizacion de esta descomposicion consiste en un sumador con propagacionde acarreo utilizando sumadores completos de 2 bits. Hay tres sentenciasexpand:. La primera describe basicamente un sumador completo de 64bits cuyo resultado es un vector de 32 componentes (res). La segundasentencia adapta la suma a la longitud de palabra obtenida en la inferen-cia de tipos. Esta longitud se almacena en la variable k. Esta sentenciaelimina del vector de resultado final (res s) los componentes del vectorresultado mayores que k ( o sea, de k + 1 a 32), correspondientes a lassalidas de los sumadores completos. Posteriormente, en la fase de simpli-ficacion del grafo, se eliminan los sumadores completos superiores a k porser codigo esteril. Finalmente, la ultima sentencia expand: transforma elvector (res s) en un entero (resglobal).

Raız cuadrada

En este caso se utilizan varios metodos basados en tablas para imple-mentar en hardware las funciones complejas de numeros en coma flotantey concretamente para el calculo de las mantisas. Para el ejemplo de la raızcuadrada la tecnica elegida se denomina descomposicion bipartita [110] yesta basada en la descomposicion de Taylor.

Esta tecnica consiste en la construccion de un circuito basado en dostablas o LUT y un sumador. El tamano de las entradas de cada una de lastablas es de dos terceras partes del numero de bits de la entrada principal.Ası, si la entrada principal I se divide en tres partes I = [A,B,C], unade las tablas construidas tendra como entrada [A,B] mientras que la otratendra como entrada [A,C] (ver Figura 2.9).


✬

✫

✩

✪

add: op2| carry opa opb res resglobal res s k ov |carry at: 0 put:0.ov := (self >= 0 and: op2 >= 0) or: (self < 0 and: op2 < 0).(0 to: −30 by: −2) expand:

[:tb |opa at: −1 ∗ tb put: ((self bitShift: tb) bitAnd: 3).opb at: −1 ∗ tb put: ((op2 bitShift: tb) bitAnd: 3).res at: −1 ∗ tb put:(opa at: −1 ∗ tb) + (opb at: −1 ∗ tb) +( carry at: ( −1 ∗ tb) ).carry at:((−1 ∗ tb )+2) put: ((res at:−1∗tb) bitShift: −2).

].k:= (((self tiwordlenght) max: (op2 tiwordlenght))).(0 to: 30 by:2) expand:[:tb| res s at: tb put:(( tb >=k) ifTrue:[0] ifFalse:[res at:tb]).].resglobal:=(res s at: 30) bitAnd: 1.(28 to: 0 by: −2)expand: [:tb | resglobal:=resglobal∗4.resglobal :=( (((res s at: tb) bitAnd:3)) bitOr: resglobal)].

resglobal := resglobal repre: k with: ov.ˆresglobal.

Figura 2.8: Sumador con propagacion de acarreo expresado enMadeo.

Para ver el contenido exacto de las tablas, describimos la tecnica dedescomposicion bipartita planteada para una mantisa normalizada (0 ≤m < 1). Ası, si el tamano de la entrada es n y n = 3k, se tiene que elvalor del operando m es igual a

m = m0 + 2−km1 + 2−2km2, (2.1)

donde

m0 = 2−kA m1 = 2−kB m2 = 2−kC,

0 ≤ mi < 1− 2−k.

(2.2)

La funcion f(m) segun este metodo es igual a:

f(m) = α(m0,m1) + β(m0,m2) + ǫ, (2.3)

donde las funciones α y β corresponde a las dos tablas y ǫ es el errorcometido. Estas funciones se obtienen aplicando la descomposicion deTaylor del siguiente modo:


A=0

C

alfa beta

+

Muxtruefalse

A B

f

Figura 2.9: Esquema de la descomposicion multipartito usada.Adaptacion de la tecnica bipartita para numeros enteros.

α(m0,m1) = f(m0 + 2−km1),

β(m0,m2) = 2−2km2f′(m0),

ǫ ≤ max(f”, (2−4k−1 + 2−3k)).

(2.4)

El error ǫ indica la calidad de la aproximacion, que en el caso concreto dela raız cuadrada es pequeno y acotado, por lo que se obtiene una solucionsuficientemente precisa y mas simple que la obtenida sin la descomposi-cion.

Las funciones α y β para la raız cuadrada son:

α(m0,m1) =√

m0 + 2−km1,

β(m0,m2) = 2−2k m2

2√m0

. (2.5)

(2.6)


La figura 2.9 muestra la implementacion de esta tecnica para nume-ros enteros. Los componentes de color gris adaptan el esquema clasico deesta tecnica para poder operar con numeros enteros. Estos nuevos compo-nentes son necesarios porque el resultado del esquema clasico es correctosiempre y cuando A 6= 0. Esta condicion la satisface la mantisa porqueesta normalizada. La solucion consiste en incluir una nueva tabla (f),que proporcione el valor de la funcion cuando A = 0. El valor de estafuncion es f(m) = f(2−km1 + 2−2km2)), ya que m0 = 0 y supondrıa laconstruccion de una tabla para la parte significativa del operando. Estatabla tiene el mismo numero de variables booleanas que las otras dos, porlo que el multiplexor de la figura 2.9 puede elegir entre la solucion general(A 6= 0) y la solucion particular cuando A = 0.

Las expresiones anteriores son para una entrada m correspondiente aun numero real positivo y menor que la unidad. Para el caso de que laentrada sea un valor entero x se tiene que:

√x =√23km = 23k/2

√m (2.7)

Por lo tanto, el resultado final de la suma de las funciones 2.5 se debemultiplicar por 23k/2.

✬

✫

✩

✪

sqrt

| x1 x2 x23 x3 final x12 x13 k |k:=(self tiwordlenght) quo: 3.x1 := self quo: (2∗∗(2∗k)).x2 := (x23 := self rem: (2∗∗(2∗k))) quo: (2∗∗k).x3 := x23 rem: (2∗∗k).final:= (x23 ∗∗ 0.5). ”No es necesareo rounded.”x12:= (x1 alfax1x2:x2 with:k).

x13:= (x1 betax1x3:x3 with:k).sal:= x13 addalfabeta: x12 with:k.

sal:=(x1=0) ifTrue:[final] ifFalse:[ sal].ˆsal.

Figura 2.10: Funcion sqrt expresada en Madeo.

La figura 2.10 ilustra el codigo para Madeo de esta funcion raız cuadra-da. La tablas correspondiente a las funciones α (alfax1x2) y β (betax1x3)


se describen en Smalltalk para los tipos con los que se desea trabajar. Lafigura 2.11 muestra la funcion α definida para numeros enteros.

✬

✫

✩

✪

alfax1x2: x2arg with: k| x1 x2 x12 kcp |

kcp:=k value.x1 := integerValue asFloat / (2∗∗kcp).x2 := x2arg integerValue asFloat / (2∗∗(2∗kcp)) .x12 := (x1 + x2 ) ∗∗0.5.

ˆSigned on: ((x12 ∗ (2∗∗(3∗kcp)) )rounded).

Figura 2.11: Funcion alfa definida para la clase Signed en Small-talk.

2.3. Verificacion y obtencion de resultados

Como se vio al principio de este capıtulo, la utilizacion de un unicolenguaje para diferentes sistemas computacionales y diferentes etapas dediseno es uno de los objetivos del sintetizador propuesto y una tendenciade los lenguajes para computacion reconfigurable actuales. Un ejemplo deello es el uso del lenguaje ANSI-C para describir sistemas hardware (verla seccion 1.3.5).Utilizando esta filosofıa se ha desarrollado una herramienta de verificacioncuyos objetivos son los siguientes:

Depurar las tecnicas y modulos incorporados en el desarrollo delsintetizador.

Validar la ejecucion de todo el proceso del flujo de diseno. Esteproceso es complejo, ya que comprende diferentes maquinas y pro-gramas, como se vera en proximos capıtulos. En la practica se hanconstatado problemas de fiabilidad ya que un fallo hardware o soft-ware de cualquier elemento perteneciente al flujo puede acarrear unresultado incorrecto.

Obtener indicadores de rendimiento por medio del analisis del cir-cuito final.

2.3 Verificaci on y obtenci on de resultados 71

Depurar las aplicaciones desarrolladas en Madeo.

La verificacion es el proceso de comprobar si lo que se ha implementa-do era lo que originalmente se diseno [26]. De esta forma, se comparan losresultados proporcionados por las diferentes representaciones intermediasdel flujo de diseno con el resultado de la ejecucion del codigo fuente. En lafigura 2.12 se puede observar la estructura y diferentes puntos intermediosdel flujo de diseno a verificar.

Para poder evaluar estos resultados de un diseno es necesario definirun conjunto de datos de entrada, lo que se llama un banco de prueba otestbench. En esta herramienta, el banco de prueba se generara de maneraautomatica.

Como acabo de decir, el primer paso para realizar una verificacion,como se puede apreciar en la figura 2.12, consiste en la generacion deun banco de pruebas. Para ello se deben proporcionar los tipos inicialesde las correspondientes entradas. El tamano del banco de pruebas se de-termina mediante el numero de pruebas o combinaciones de las entradasy la distribucion aleatoria de los datos a utilizar. Actualmente, solo haydos distribuciones disponibles: la distribucion uniforme y la distribucionnormal.

Posteriormente, se traduce el codigo de Madeo a un codigo interpre-table directamente por la maquina virtual. Madeo define sus aplicacionescomo funciones o metodos independientes, sin incluirlos en ninguna clase.Por esto para integrar las aplicaciones en el sistema, se debe crear unanueva clase de Smalltalk en la que las aplicaciones son mensajes y lasvariables globales de la aplicacion se definen como variables de instancia.

En esta clase, se define tambien una interfaz generica para introdu-cir el banco de prueba y obtener resultados. El sistema genera de formaautomatica dos metodos para esta interfaz. Uno para introducir informa-cion (inputs:) y otro para obtener informacion (outputs:). Al metodo deentrada inputs: se le proporciona una coleccion de valores que se asignana las correspondientes variables de entrada de la aplicacion, y el metodode salida devuelve una coleccion de valores de las variables de salida. Enla figura 2.13 se muestra el codigo generado para la interfaz del ejemplodel producto escalar visto anteriormente aplicando el metodo expand: .


Código fuente

Traducción a código nativo

Síntesis

Generación testbench

ejecutar evaluar

Implementación

Simulador funcional

Simulador temporal

= estimador

Consumo

=

Error

No No

Área Tiempo

Figura 2.12: Flujo de verificacion y comprobacion de resultados.

La aplicacion descrita en el lenguaje de Madeo se debe traducir aSmalltalk. Las diferencias entre los dos lenguajes son solo dos: la pri-mera es la interpretacion de las constantes pues, mientras en Smalltalkcada constante tiene asociado un tipo o clase, en Madeo a las constan-tes se les asigna un tipo especıfico. De este modo, en la traduccion lasconstantes son sustituidas por la creacion de un objeto de ese tipo aso-ciado, e inicializadas con el valor de la constante correspondiente. En lafigura 2.14 se puede ver un programa ejemplo. En este, la sentencia ”nue-vo:=SignedPositivo on: 0” es la traduccion de la sentencia ”nuevo:=0’.


✬

✫

✩

✪

inputs: inst entradas|cp entradas|cp entradas:=inst entradas asOrderedCollection.A:= Array new:3.B:= Array new:3.A at: 1 put: cp entradas removeFirst.B at: 1 put: cp entradas removeFirst.A at: 2 put: cp entradas removeFirst.B at: 2 put: cp entradas removeFirst.A at: 3 put: cp entradas removeFirst.B at: 3 put: cp entradas removeFirst.✛

✚

✘

✙

outputs|cp salidas|cp salidas:=OrderedCollection new.cp salidas add: nuevo.ˆcp salidas

Figura 2.13: Funciones de interfaz generada para el productoescalar aplicando expand:.

De esta forma cuando se ejecute en Smalltalk esta sentencia la variablenuevo sera un objeto de la clase SignedPositivo perteneciente a los tiposdefinidos en Madeo y de esta forma las dos ejecuciones seran equivalentes(los tipos de Madeo se veran con mas detalle en la seccion 3.3.2).

La segunda diferencia es que Madeo tiene constructores y funcio-nes propios que tienen que ser sustituidos por mensajes funcionalmen-te equivalentes en Smalltalk. Por ejemplo, los constructores expand: ylatency:pipeline son sustituidos en Smalltalk por una sentencia de unbucle con el contador correspondiente. La figura 2.14 muestra como que-dara el producto escalar al que se le ha aplicado expand:despues de latraduccion.

Como se ilustra en la figura 2.12, la primera comprobacion se reali-za para validar automaticamente el grafo de operadores obtenido en lasıntesis funcional. Ası, se puede validar y depurar tanto el sintetizadorfuncional como el traductor de Madeo a Smalltalk.


★

✧

✥

✦

tmp unonuevo := SignedPositivo on: 0.(1 to: 3)do: [:i |

nuevo := nuevo + ((A at: i)∗ (B at: i))].ˆnuevo

Figura 2.14: Codigo Smalltalk generado para el producto esca-lar aplicando expand:.

Se ha desarrollado un simulador que propaga los valores del bancode pruebas por el grafo de operaciones para obtener los resultados de lasıntesis funcional. Estos resultados se comparan con lo que se obtiene deejecutar el codigo Smalltalk resultado de la traduccion de Madeo con elbanco de prueba generado. El resultado principal

La segunda y ultima comparacion se ha implementado para utilizarlacon herramientas de implementacion externas. La solucion adoptada pararealizar esta comprobacion es traducir el banco de pruebas a un formatoestandar para poder simular la representacion del circuito a configurar. Elformato elegido es un lenguaje de descripcion hardware, concretamenteel VHDL. Las herramientas de los fabricantes de FPGA proporcionan laopcion de obtener sus representaciones intermedias en VHDL.

El banco de pruebas generado (ver un ejemplo en la figura 2.1) escri-be los resultados del circuito en un archivo, para compararlos posterior-mente con los resultados obtenidos inicialmente. Esta comparacion no esautomatica. La utilidad de esta comprobacion es validar el correcto fun-cionamiento de los scripts que llaman a los programas externos, tanto lossimplificadores logicos como los programas de implementacion, ası comovalidar la generacion correcta de las LUT en formato BLIF.

Listado 2.1: Ejemplo de un banco de prueba generado au-tomaticamente.

✞12 l ibrary IEEE ;3 use IEEE . STD LOGIC 1164 .ALL;4 use IEEE .STD LOGIC ARITH .ALL;5 use IEEE .STD LOGIC UNSIGNED.ALL;6 USE IEEE .STD LOGIC TEXTIO.ALL;


7 USE STD.TEXTIO.ALL;89 ENTITY testbench IS

10 END testbench ;1112 ARCHITECTURE t e s tbench arch OF testbench IS13 SHARED VARIABLE TX ERROR : INTEGER := 0 ;14 SHARED VARIABLE TX OUT : LINE ;15 FILE RESULTS: TEXT OPEN WRITEMODE IS ” t e s t . ano” ;16 component s q r t t e s t port (17 a1 : in s t d l o g i c v e c t o r (18 downto 0 ) ;18 s i gn a l t 23 : out s t d l o g i c v e c t o r (10 downto 0 ) ) ; end component ;19 signal a1 : s t d l o g i c v e c t o r (18 downto 0 ) ;20 signal s i g na l t 2 3 : s t d l o g i c v e c t o r (10 downto 0 ) ;21 begin22 UUT: s q r t t e s t port map ( a1=>a1 , s i gn a l t 23=>s i gn a l t 23 ) ;23 PROCESS −− Annotat ion pr oc e s s24 VARIABLE TX TIME : INTEGER := 0 ;25 PROCEDURE ANNOTATE signalt23 (TX TIME : INTEGER) IS26 VARIABLE TX STR : S t r i ng (1 to 4096) ;27 VARIABLE TX LOC : LINE ;28 BEGIN29 STD.TEXTIO. wr i t e (TX LOC, s t r i ng ’ ( ”Annotate [ ” ) ) ;30 STD.TEXTIO. wr i t e (TX LOC, TX TIME ) ;31 STD.TEXTIO. wr i t e (TX LOC, s t r i ng ’ ( ” , s i gna l t23 , ” ) ) ;32 IEEE .STD LOGIC TEXTIO. wr i t e (TX LOC, s i gn a l t 2 3 ) ;33 STD.TEXTIO. wr i t e (TX LOC, s t r i ng ’ ( ” ] ” ) ) ;34 TX STR(TX LOC. al l ’ range ) := TX LOC. a l l ;35 STD.TEXTIO. w r i t e l i n e (RESULTS, TX LOC) ;36 STD.TEXTIO. Dea l l ocat e (TX LOC) ;37 END;38 BEGIN39 WAIT for 1 f s ;40 ANNOTATE signalt23 ( 0 ) ;41 ANNO LOOP : LOOP42 WAIT for 50 ns ;43 TX TIME := TX TIME + 50;44 ANNOTATE signalt23 (TX TIME) ;45 WAIT for 50 ns ;46 TX TIME := TX TIME + 50;47 END LOOP ANNO LOOP;48 END PROCESS;49 PROCESS50 BEGIN51 −− −−−−−−−−−−−−− Current Time : 200 ns52 WAIT FOR 100 ns ;53 a1<=”0101100100010100011 ” ;54 WAIT FOR 100 ns ;

✡✝ ✆

El banco de pruebas generado tambien se puede utilizar para la esti-macion de consumo del circuito. Los experimentos de analisis de consumose han realizado para dispositivos reconfigurables del fabricante Xilinx.Este fabricante proporciona un programa de estimacion de consumo lla-mado xpower. La informacion necesaria es la descripcion estructural delcircuito final basado en los componentes basicos de la FPGA y la actividadde conmutacion de las senales del circuito. La descripcion la proporcionael programa de place and route, y la actividad de conmutacion se consi-gue realizando una simulacion temporal del circuito final. Por lo tanto, elsimulador necesita un modelo temporal del circuito final, que es similara la descripcion estructural pero incorporando anotaciones de la respues-ta temporal de los componentes y senales. El simulador se ejecutara conesta descripcion y el banco de pruebas preparado para el, devolviendo la


evolucion de todas las senales del circuito en el formato estandar VCD(Value Change Dump) para las herramientas EDA, que sera una entradaal estimador de consumo.

Listado 2.2: Ejemplo de un banco de prueba generado au-tomaticamente.

✞12 l ibrary IEEE ;3 use IEEE . STD LOGIC 1164 .ALL;4 use IEEE .STD LOGIC ARITH .ALL;5 use IEEE .STD LOGIC UNSIGNED.ALL;6 USE IEEE .STD LOGIC TEXTIO.ALL;7 USE STD.TEXTIO.ALL;89 ENTITY testbench IS

10 END testbench ;1112 ARCHITECTURE t e s tbench arch OF testbench IS13 SHARED VARIABLE TX ERROR : INTEGER := 0 ;14 SHARED VARIABLE TX OUT : LINE ;15 FILE RESULTS: TEXT OPEN WRITEMODE IS ” t e s t . ano” ;16 component s q r t t e s t port (17 a1 : in s t d l o g i c v e c t o r (18 downto 0 ) ;18 s i g na l t 2 3 : out s t d l o g i c v e c t o r (10 downto 0 ) ) ; end component ;19 signal a1 : s t d l o g i c v e c t o r (18 downto 0 ) ;20 signal s i gn a l t 23 : s t d l o g i c v e c t o r (10 downto 0 ) ;21 begin22 UUT: s q r t t e s t port map ( a1=>a1 , s i g n a l t 2 3=>s i g na l t 2 3 ) ;23 PROCESS −− Annotat ion p ro ce s s24 VARIABLE TX TIME : INTEGER := 0 ;25 PROCEDURE ANNOTATE signalt23 (TX TIME : INTEGER) IS26 VARIABLE TX STR : S t r i ng (1 to 4096) ;27 VARIABLE TX LOC : LINE ;28 BEGIN29 STD.TEXTIO. wr i t e (TX LOC, s t r i ng ’ ( ”Annotate [ ” ) ) ;30 STD.TEXTIO. wr i t e (TX LOC, TX TIME ) ;31 STD.TEXTIO. wr i t e (TX LOC, s t r i ng ’ ( ” , s i gna l t23 , ” ) ) ;32 IEEE .STD LOGIC TEXTIO. wr i t e (TX LOC, s i gn a l t 23 ) ;33 STD.TEXTIO. wr i t e (TX LOC, s t r i ng ’ ( ” ] ” ) ) ;34 TX STR(TX LOC. al l ’ range ) := TX LOC. a l l ;35 STD.TEXTIO. w r i t e l i n e (RESULTS, TX LOC) ;36 STD.TEXTIO. Dea l l ocat e (TX LOC) ;37 END;38 BEGIN39 WAIT for 1 f s ;40 ANNOTATE signalt23 ( 0 ) ;41 ANNO LOOP : LOOP42 WAIT for 50 ns ;43 TX TIME := TX TIME + 50;44 ANNOTATE signalt23 (TX TIME ) ;45 WAIT for 50 ns ;46 TX TIME := TX TIME + 50;47 END LOOP ANNO LOOP;48 END PROCESS;49 PROCESS50 BEGIN51 −− −−−−−−−−−−−−− Current Time : 200 ns52 WAIT FOR 100 ns ;53 a1<=”0101100100010100011 ” ;54 WAIT FOR 100 ns ;

✡✝ ✆

2.4 Conclusiones 77

2.4. Conclusiones

En este capıtulo se ha presentado una metodologıa para trabajar conaplicaciones DSP en el entorno de Madeo. Inicialmente se ha introducidola filosofıa y el flujo completo de diseno de este entorno para arquitectu-ras reconfigurables. A continuacion, se han descrito brevemente todas lasaportaciones que ha realizado el autor de esta tesis. Finalmente, se handetallado las aportaciones concretas en la sıntesis funcional para descri-bir los algoritmos en las aplicaciones DSP, ası como la verificacion de losresultados obtenidos.

En definitiva, se ha presentado una vision global del entorno y deltrabajo realizado en esta tesis como base para la comprension de lossucesivos capıtulos.

CAPITULO 3Inferencia de tipos

El sistema de tipos en MADEO esta basado en la inferencia de tipos,como ya se comento en capıtulos anteriores. La deduccion automaticade tipos de datos en MADEO presenta dos caracterısticas interesantes.La primera caracterıstica es permitir describir los sistemas de forma masabstracta y sencilla para incrementar la productividad. La segunda esobtener una descripcion estructural basada en LUT que define el circuitoa partir del lenguaje de alto nivel. Esta segunda aportacion va a ser eltema principal de este capıtulo.

En la primera seccion de este capıtulo se describen los antecedentesde la inferencia de tipos de datos en los lenguajes de programacion. Con-cretamente, se estudian los orıgenes y la capacidad de abstraccion quetiene la inferencia de tipos en los diferentes paradigmas de programacion.

A continuacion se analizaran los antecedentes de la utilizacion de lainferencia de tipos en aplicaciones DSP, cuya finalidad es la simplifica-cion y mejora en la precision de sus programas o circuitos. Algunos deestos trabajos han servido de base para la implementacion del sistema desıntesis de MADEO.

Analizando las diferentes aplicaciones de la inferencia de tipos, se ex-pondran las tecnicas particulares de MADEO y se describira como seaplicaran dentro del flujo de diseno. A partir de la seccion 3.5 se descri-

79

80 Capıtulo 3 Inferencia de tipos

ben de manera formal los diferentes procedimientos propuestos basadosen la inferencia de tipos para generar la estructura de LUT (Look UpTable) que define el circuito.

3.1. Tipos Abstractos de Datos, Polimorfismo e Infe-rencia de Tipos

El libro “Algoritmos + Estructuras de Datos=Programas” de NiklausWirth establece como regla basica que se debe seleccionar y especificarcorrectamente la estructura de datos con la finalidad de encontrar unalgoritmo que nos produzca un programa estructurado, es decir, biendocumentado, con claridad para mejorar el tiempo de desarrollo y demantenimiento del programa.

La experiencia con los lenguajes de programacion estructurada hizoque se reescribieran muchos subprogramas similares o equivalentes paradiferentes tipos de datos. Si se escriben subprogramas mas genericos, masindependientes del tipo de datos, estos se podrıan reutilizar sin tenernecesidad de reescribir subprogramas para cada tipo de datos. Al mismotiempo se reducira el numero total de lıneas de programas, facilitando sumantenimiento.

Este fue uno de los aspectos mas importantes que motivaron la apa-ricion de la tecnica basada en tipos abstractos de datos (TAD) [120]. UnTAD es una estructura algebraica, es decir, un conjunto de objetos conun conjunto de operaciones definidas, que define un nivel intermedio don-de se especifica lo esencial de la realidad sin comprometerse con detallesde implementacion. Aunque esta serıa su definicion mas formal, la ideabasica es la de abstraer del algoritmo la parte independiente del tipo dedatos usado. Utilizando el estilo de frase acunado por Wirth esto serıa“Algoritmo = Algoritmo de Datos + Algoritmo de Control”. Se entiendecomo Algoritmo de Datos a la parte del algoritmo encargada de la gestionde la estructura de datos, y como Algoritmo de Control a la parte del al-goritmo que representa la parte restante, es decir, lo esencial del metodopara resolver el problema. De esta forma, se puede implementar un TADpara diferentes estructuras de datos con solo programar las operacionesconcernientes al algoritmo de datos para cada estructura, y sin modificarel algoritmo de control. Concluyendo, este nuevo enfoque nos proporcionauna nueva metodologıa para poder obtener mayor reutilizacion del codi-

3.2 Inferencia de tipos en los DSP 81

go. Esta metodologıa fue el origen de las tecnicas de genericidad, herenciay polimorfismo, origen del paradigma orientado a objetos.

Los lenguajes orientados a objetos han evolucionado siempre paraque la implementacion de los TAD sea lo mas simple posible, buscandotecnicas para reducir al maximo el algoritmo de datos y reutilizando elalgoritmo de control [6].

En este contexto, el compilador o interprete debe averiguar el tipode datos cuando se hace una invocacion a una operacion del algoritmode control. Se puede averiguar el tipo en tiempo de compilacion, en cuyocaso se utiliza la inferencia de tipos. Esta tecnica es la mas empleada enlos lenguajes funcionales, como ML y Haskell [89, 121, 105]. Este procedi-miento asigna automaticamente un tipo de datos a una variable o funcionsin necesidad de que el programador lo especifique. El tipo de cada varia-ble se deduce a partir de un analisis estatico del programa realizado porel compilador del lenguaje, a partir de las definiciones previas de tipo yrecorriendo el algoritmo, e infiriendo los tipos de las variables intermedias.

La inferencia de tipos en los entornos orientados a objetos se puedeutilizar en algunos casos para optimizar esta busqueda en tiempo de eje-cucion [12, 64], o para resolver herencias dinamicas utilizadas por ejemploen el lenguaje Self [36, 115].

3.2. Inferencia de tipos en los DSP

Las aplicaciones de tratamiento digital de la senal (DSP) son clarasimpulsoras del desarrollo de sistemas digitales de proposito especıfico. Elcompromiso entre area y velocidad de estos sistemas ha desestimado lautilizacion de operadores en coma flotante [59].

Como es sabido, la mayor ventaja de la representacion en coma fija esla mayor simplicidad de sus operadores que proporcionan mejores presta-ciones de velocidad, area y consumo que los operadores de coma flotante.Pero es especialmente atractivo en las aplicaciones DSP porque el rangoy el error de precision estan bastante acotados. La inferencia de tipos seusa para optimizar el tamano de la representacion de la coma fija, porlo que el analisis estatico realizado calcula la precision y rango necesariopara una buena solucion del algoritmo.En estos procesos se realiza la propagacion, que consiste en deducir lostipos de las variables intermedias partiendo del tipo de las entradas. Esta


deduccion se puede realizar por simulacion o por analisis. Los metodosbasados en simulacion [31] consisten en un sistema de aproximaciones su-cesivas, donde cada aproximacion se obtiene simulando la propagacion detipos a traves de todas las variables intermedias.

Los metodos basados en el analisis [41][138] consisten en modelarmatematicamente el comportamiento y, a traves de modelos generalesanalıticos realizados ad hoc, encontrar una solucion aproximada al pro-blema. Esto supone una simplificacion considerable del proceso.

Otro aspecto importante es la informacion que se propaga por lasvariables para realizar la inferencia. En la literatura se pueden encontrarestos tres casos:

Longitud de palabras [41][31]. La longitud de palabra de cada varia-ble se propaga a traves de las operaciones correspondientes. Se debeconocer para cada operacion, la maxima longitud posible del resul-tado en funcion de la longitud de palabra de sus argumentos. Ası,por ejemplo, en el caso de una suma de dos variables enteras de 8bits el resultado es de 9 bits, ya que en una suma la maxima lon-gitud es un bit mas que la longitud del operando mas grande. Estemetodo es simple pero impreciso.

Vector de bits [138]. Este metodo propaga un vector de bits, de formaque se analiza cada una de las variables y se determina que bits sonvariables, constantes o valores indefinidos. Ası, despues del proceso,se pueden eliminar los bits innecesarios. Por ejemplo, un operadorque multiplica por 2 un valor de 2 bits tendrıa en la entrada unvector de bits donde en principio todos los bits son variables ( {xy}).El resultado logicamente es el siguiente vector de tres bits {xy0}, loque implica que el bit de menor peso es innecesario. Comparandolocon el caso anterior, este metodo es mas complejo, pero mas preciso.

Rango de datos [114]. Se propaga el maximo y mınimo del tipo de da-tos de la variable (por ejemplo [10 . . . 0]). Este sistema es parecidoal de longitud de palabras pero con mayor precision.

3.3 Sistema de tipos en MADEO 83

3.3. Sistema de tipos en MADEO

3.3.1. Inferencia de tipos en MADEO

Como se comento al principio del capıtulo, uno de los objetivos de MA-DEO es proporcionar la capacidad de trabajar con TAD en la descripcionde sistemas digitales. La aportacion mas importante de este sistema esdarle al programador la posibilidad de implementar eficientemente cual-quier funcion u operacion con cualquier tipo de datos, sin necesidad detener previamente disponibles bibliotecas de componentes basicos sinte-tizados.En la Figura 3.1 se pueden observar dos programas diferentes de un filtroPrewitt. El programa de la izquierda corresponde a un algoritmo clasicopara un lenguaje de programacion imperativo (C, ADA, etc.) y el progra-ma de la derecha corresponde a un programa de MADEO con inferenciade tipos. Basicamente, se puede observar que hay tres diferencias. La pri-mera es que no hay declaracion de tipos en el fragmento de MADEO.La segunda, de menor importancia, es el mensaje expand:, como se vioen una seccion anterior es una estructura parecida a un bucle PARA enparalelo, y por ultimo el mensaje saturation:.

La funcion de saturacion se utiliza habitualmente en los DSP ya quese cumple que la salida de estas funciones tiene el mismo tipo que laentrada. Los valores intermedios tienen mayor rango de representacion yal final de los calculos se convierten en el mismo tipo que la entrada.

Las funciones tıpicas de conversion son la saturacion o el modulo. Laprimera consiste en convertir los valores que exceden del rango de re-presentacion del tipo de la funcion a uno de los maximos del sistema derepresentacion. La funcion modulo simplemente suprime los bits de mayorpeso del valor calculado representado en complemento a 2 o como enterosin signo. En un lenguaje de programacion convencional, la saturacion serealizarıa como se puede ver en el algoritmo de la izquierda de la Figura3.1. Este calculo de saturacion, que en el algoritmo corresponde a la ulti-ma sentencia si, esta en funcion de dos constantes: -128 y 127, que sonlos lımites del rango de representacion del tipo entero de 8 bits. El algo-ritmo de la derecha utiliza el mensaje saturation: con los parametros deentradas (A at:1) y z devuelve el resultado de la funcion de saturacion, esdecir, el valor de z si el valor esta dentro rango de representacion del tipoinferido de la variable (A at:1) o en caso contrario devuelve el valor mascercano del rango de representacion del tipo inferido, es decir, el maximo


✬

✫

✩

✪

v,h,z:enterosvertmask,hortmask:vector de en-terosvertmask ← #(−1 0 1)hortmask ← #(−1−1−1000111)h← 0v ← 0Para i← 1 hasta 9 hacer

v ← v + A[i] ∗ vertmask[(i +2)/3]h← h+A[i] ∗ hortmask[i]

fin Parav ← v2

h← h2

z ←√v + h

si z > 127 entoncesz ← 127

si nosi z < −128 entonces

z ← −128fin si

fin si(a) Algoritmo imperativo

✬

✫

✩

✪

| v h vertmask hortmask|vertmask:=#(-1 0 1).hortmask:=#(-1 -1 -1 0 0 0

1 1 1).v:=0.h:=0.(1 to: 9) expand: [:i |

v:=v + (A at: i) *vertmask at: (i + 2) // 3.

h:=h + (A at: i) *hortmask at: i. ].

v:=v ** 2.h:=h ** 2.z:=v + h.z:=z ** 0.5.z:=z saturation: A at: 1.

(b) Madeo

Figura 3.1: Filtro Prewitt.

o mınimo. De esta forma, se especifica la operacion generica sin detallarcaracterısticas del tipo explicitamente.

3.3.2. Tipos de Datos de MADEO

Los tipos de datos no pueden ser los mismos del lenguaje anfitrion,Smalltalk, ya que estos son muy abstractos. Ademas son necesarias variascaracterısticas para la sıntesis, como por ejemplo el tamano. Por ello, sehan definido unas clases basicas que incorporan los metodos necesariospara manejar tipos en MADEO. Si el tipo de datos utilizado es similara uno de los convencionales, entonces pueden heredar tanto los metodosespecıficos de MADEO como los de la clase convencional. Por ejemplo,el tipo S igned9 son los numeros enteros con signo de 9 bits y hereda losmetodos propios de MADEO de representacion, de calculo del tamano,

3.4 Aplicaci on de la inferencia de tipos a nivel de sıntesis 85

funcion saturacion, etc., y a su vez hereda todos los metodos de aritmeti-cos de los enteros del sistema de clases de Smalltalk (arcotangente, seno,suma, multiplicacion, etc.).

El objetivo es beneficiarse de las operaciones implementados por lostipos convencionales y, por otra parte, tener la posibilidad de especiali-zarlos para los aspectos de sıntesis e implementacion hardware utilizadosen la herramienta, ası como la facilidad de construir nuevos tipos. La uti-lizacion de herencia multiple es lo mas consecuente para este caso, peroSmalltalk no la soporta. Es posible sin embargo sustituir funcionalmenteesta tecnica utilizando otros recursos de Smalltalk como la genericidad yel tipado variable [48].

3.4. Aplicacion de la inferencia de tipos a nivel desıntesis

El uso de bibliotecas es la tecnica en la que se basan los sintetizadoreshardware convencionales. Esto proporciona un resultado muy bueno porla reutilizacion de componentes, que ahorra tiempo de sıntesis y porquese pueden dedicar muchos esfuerzos a la optimizacion de cada componen-te incluido en la biblioteca. El punto debil de la biblioteca es su escasagenericidad y que los componentes, para que sean optimos, tienen que serrealizados con caracterısticas muy particulares. Por ello, las bibliotecasestan desarrolladas para sistemas de representacion y aritmetica clasica.Por esto la tecnica de inferencia de tipos puede ser eficiente para los casosespecıficos donde normalmente no se dispone de bibliotecas.

En esta seccion, se describe conceptualmente como se aplica la in-ferencia de tipos para generar circuitos en MADEO. Como se ve en laFigura 3.2, el punto de partida del nivel de sıntesis es el grafo de flujo dedatos (GFD). En la estructura asociada al GFD no hay inicialmente tiposasignados a ninguna variable. De hecho, el proceso de inferencia de tiposconsiste en deducir el tipo correcto para cada una de estas variables.

El funcionamiento basico es recorrer el GFD, e ir calculando los valoresposibles de las variables internas y de las salidas para todas las combi-naciones de las entradas. En definitiva, despues de aplicar este proceso,


Tipos Algoritmo

Asignacion de tipo Unsigned |sum cte|

a← Signed Signedoo sum:=a.

. . . cte:=#(3, 2, 1).

GF (1 to : 3) do : [: i|

sum:=sum + (cte at : i)]

�

--❭❭❭❭❭❭❭❭❭❭❭❭❭❭❭❭

Compilar

��

Nivel deProgramacion

OO

Grafo de flujo de datos

��Sintetizar

��

�� LUT

��

Nivel deSıntesis

OO

Figura 3.2: Vision simplificada del flujo de diseno.

en cada interconexion del grafo se tendra el conjunto de valores posibles.Este proceso utiliza una tecnica de simulacion similar a la descrita en laseccion de inferencia de tipos en los DSP [31]. La simulacion consiste, eneste caso, en evaluar cada operador para todos sus posibles valores.

La aplicacion de la inferencia de tipos va a permitir:

a) Obtener informacion para la simplificacion del grafo de dependencia.Su mayor aplicacion es detectar constantes, es decir, variables quetienen un unico valor. De esta forma, si una de las entradas de unoperador binario es constante, se simplifica en un operador unario.Se pueden suprimir los subgrafos en los que todas sus salidas sonconstantes. Otra aplicacion es la eliminacion de subgrafos esteriles, esdecir, aquellos subgrafos cuyas salidas no afectan al resultado final.Estas simplificaciones se veran con mas detalle en la seccion 4.1.1.

b) Independizar el sistema de representacion de las variables. Los sistemasde inferencia de tipos vistos en la seccion 3.2 dependen directamentedel sistema de representacion usado, de hecho se aplica directamentesobre la representacion de las variables. El sistema de inferencia de

3.4 Aplicaci on de la inferencia de tipos a nivel de sıntesis 87

tipos de MADEO trata con colecciones de valores, independientementede su codificacion. La codificacion se aplaza a las ultimas fases del flujode sıntesis.

c) Obtener una descripcion tabular del circuito. La inferencia de tiposobtiene una coleccion de valores de entradas y de salidas por cadaoperador perteneciente al GFD. Cada operador se transforma en uncircuito, que es descrito con una tabla de valores. El proceso de ob-tencion de esta tabla consiste en la conversion de la descripcion porcomprension del operador en una descripcion particular por extensionpara todos los posibles valores de entrada del mismo. El resultado deeste procesamiento es un conjunto de pares que asocian cada entradaposible con su salida correspondiente. Este conjunto se llama tabla debusqueda o LUT y define de forma tabular el circuito de un operador.Este procedimiento implementa de una forma homogenea y uniformecualquier operador, independientemente del tipo de datos, y sin la ne-cesidad de tener una biblioteca de operadores (proporcionando unagenericidad pura).

La utilizacion de la inferencia de tipos en la sıntesis permite reducirel tamano de los tipos de las correspondientes variables, es decir, reducirel conjunto de valores de las variables de cada operador. De esta forma,se reduce el numero de pares que definen las LUT, ya que el numero decombinaciones es menor. Como parece logico, el decremento de combina-ciones de una tabla da lugar a un circuito mas simple cuando se completala sintetizacion.

La reduccion de posibles valores en la LUT conlleva la aparicion defunciones logicas incompletas, es decir, hay combinaciones en las cualesno estan definidas las funciones. Existen sintetizadores logicos [134] quepuede utilizar esta informacion de combinaciones no definidas, que noafecta al resultado final, con el fin de obtener un circuito mas simple.

A continuacion se describen los convenios de formulacion empleadosen el resto del capıtulo y posteriormente se describira la propagacion haciadelante. En esta seccion se detallara el sistema base de la inferencia detipos, como se realiza la propagacion en varios casos y como se detallaranla LUT de cada operador. En la ultima seccion se describira la propagacionhacia atras, que consiste en una tecnica para reducir combinaciones de


los operadores intermedios y que no afecta al resultado global del circuitogenerado.

3.5. Notacion y terminologıa

Como ya se ha comentado, nuestro sistema para generar un circuitotraduce un programa en un grafo de operadores. Este grafo es un conjuntode operadores interconectados segun sus dependencias de datos. Las ex-presiones o terminos se referiran normalmente a un mismo operador, porlo que se omitira detallarlo. Para referenciar un termino de otro operadorse utilizara un superındice donde se indique el nombre de la funcion uoperador. Se considera que todos los operadores solo tienen una salida.

Ası, dado un operador, op, con n operandos, se denominara Eopi al

conjunto de todos los posibles valores del operando i-esimo. Como se hacomentando, para simplificar la escritura generalmente se omitira el ope-rador, es decir, se escribira Ei. Para referirse a cada uno de los valoresposibles de Ei se utilizara el termino eij , donde Ei = {ei1 , ei2 , . . . , eik}. Sila E no tiene subındices representara el conjunto global de todas las com-binaciones posibles de los valores de los operandos, es decir, el productocartesiano de todos los valores posibles de cada operando. Ası, el terminoei sera una combinacion concreta de E. Por lo tanto se tiene que:

E = Eop = E0 × E1 × · · · × En−1 =

n−1∏

i=0

Ei. (3.1)

En general, las mayusculas se emplearan para especificar conjuntos ylas minusculas para valores concretos. Por ello, S representa el conjuntode salidas posibles de un operador y si un valor de salida concreto.

Otro termino que tendra asociado cualquier operador sera la funcionf que lo define, y que establecera la relacion de las si con alguna combi-nacion de las entradas ej , concretamente ∃j : si = f(ej). A lo largo delcapıtulo se incorporaran nuevos terminos a esta nomenclatura.

Dado un operador multiplicador de dos operandos de dos bits, la Fi-gura 3.3 corresponde al grafo de dependencia de datos. Las entradas delos operandos son:

3.5 Notaci on y terminologıa 89

Figura 3.3: GFD de un multiplicador de dos bits.

EA∗B0 = E0 = E1 = EA∗B

1 = {3 . . . 0},e0k ∈ E0 ∧ e1k ∈ E1. (3.2)

y el conjunto de todas las entradas

E = EA∗B = E0 × E1 = {3 . . . 0} × {3 . . . 0}= {(3, 3), (3, 2), (3, 1) . . . (0, 0)}, ei ∈ E. (3.3)

Sea f la funcion del operador multiplicador anterior, tal que f(x, y) =x ∗ y, entonces se tiene que:

sk = f(ek) ∈ S = {0, 1, 2, 3, 4, 6, 9}. (3.4)

Ası, ∀ek se tendra la siguiente definicion tabular por extension de lafuncion f :

f(0,0)= 0 f(1,0)= 0 f(2,0)= 0 f(3,0)= 0f(0,1)= 0 f(1,1)= 1 f(2,1)= 2 f(3,1)= 3f(0,2)= 0 f(1,2)= 2 f(2,2)= 4 f(3,2)= 6f(0,3)= 0 f(1,3)= 3 f(2,3)= 6 f(3,3)= 9


Con la intencion de que el texto sea autocontenido, se enumeran a conti-nuacion varias definiciones de terminos clasicos de relaciones [100],[21].

Dominio. El dominio de una funcion f es el conjunto de existencia de lamisma. Es decir, los valores para los cuales la funcion esta definida.Es el conjunto de todos los objetos que puede transformar y sedenota como Dom f, o bien D f.

Imagen. La imagen, recorrido o rango de una funcion f esta formadapor los valores que alcanza la misma. Es el conjunto de todos losobjetos transformados y se denota como Im f, o bien I f.

Clase de equivalencia. Sea ℜ una relacion de equivalencia sobre unconjunto A. El conjunto de todos los elementos relacionados cona ∈ A, recibe el nombre de clase de equivalencia de a. Esta clase seindica por [a].

Particion. La coleccion de los Ai, i ∈ I, siendo I un conjunto de ındices,constituye una particion de un conjunto S, si y solo si:

Ai 6= ∅, ∀i ∈ I, Ai

⋂

Aj = ∅ ∀i 6= j,⋃

∀i∈I

Ai = S.

Conjunto Cociente. Sea ℜ una relacion de equivalencia sobre un con-junto A. Entonces, el conjunto de todas las clases de equivalenciadeterminada en A por ℜ, recibe el nombre de conjunto cociente deA por ℜ, y se designa como A/ℜ. Siendo A/ℜ = [a] | a ∈ A.

3.6. Propagacion hacia delante

El modelo de ejecucion seguido por el compilador de MADEO esta di-senado para transformar las operaciones e implementarlas en LUT. Ası,despues de un analisis del flujo de datos de las expresiones, se genera unGFD, donde los nodos son las operaciones implementadas en LUT, y losarcos establecen la dependencia de los datos. El grafo esta definido porniveles de operadores (vease la Figura 3.4). En la parte superior de la fi-gura estan las entradas, luego el primer nivel compuesto solo por aquellosoperadores cuyos operandos son entradas primarias, y ası sucesivamentehasta llegar al nivel inferior donde se encuentran las salidas. Los grafostienen la organizacion ASAP (As Soon As Possible) [101]. Esta establece

3.6 Propagaci on hacia delante 91

el nivel que le corresponde a cada uno de los operadores, siendo su criterioasociar a cada operador de menor nivel posible (ver figura 3.4).

La propagacion hacia delante recorre el grafo desde las entradas hastalas salidas. Cuando se hayan inferido los valores de todos los operandosde un operador se evalua este, infiriendo los valores de la correspondientesalida. La evaluacion de cada operador se realiza para el producto carte-siano de todas las entradas y calculando el valor de salida para cada unade esta combinaciones. La evaluacion va descendiendo por los niveles degrafo.

Entradas

Nivel 1

Nivel 2

Nivel 3

Salidas

Figura 3.4: Esquema basico de un GFD.

El calculo de los valores de los operadores se realiza por simulacion.A continuacion se ilustra con un ejemplo esta tecnica. Sea la simple ex-presion polinomica

s = ((a%4) + (b%4))%2, (3.5)

donde% representa la funcion modulo o resto de la division entera.Los operadores del conjunto producido por nuestro compilador estan co-nectados segun la dependencia de datos. La Figura 3.5 muestra una po-


sible representacion de la red de operadores, donde los nodos superioresdel grafo corresponden a los datos de entrada.

a b

A % 4 A % 4

A+B

A % 2

s

{3..0}{3..0}

{6..0}

{0,1}

Figura 3.5: Descomposicion de la expresion s = ((a%4) +(b%4))%2 en un red de LUT. Se describe el conjunto de datosde entrada para cada operador.

La Figura 3.5 tambien muestra el conjunto de valores de entrada paracada operador en la descomposicion de LUT de este circuito. En este caso,se considera que los datos del conjunto inicial (a, b) son numeros binariospositivos de 3-bits.

Half= AdelanteNivel OP In Out S N1 A%4 {7..0} {3..0} 3 2

A%4 {7..0} {3..0} 3 22 A+B {3..0}2 {6..0} 4 33 A%2 {6..0} {0, 1} 3 1

Tabla 3.1: Proceso de propagacion hacia delante para el ejemplo dela expresion polinomica s = (a%4 + b%4)%2).


La Tabla 3.1 muestra el conjunto de datos de entrada (In) y salida(Out) de cada operador para la expresion (3.5). Los operadores se hanagrupado segun su nivel de profundidad en el GFD. Tambien se muestranel tamano (S), en bits de entrada, y la cantidad (N) de LUT utilizadaspara la implementacion de cada operador.

En resumen, el calculo de cada operador consiste en obtener los valoresde la funcion asociada por cada una de las combinaciones pertenecientesal producto cartesiano de todos los valores de los operandos. De esta for-ma, el conjunto de todas las salidas (Sop) de un operador corresponde ala siguiente expresion:

S = Sop =⋃

∀ei∈E

f(ei). (3.6)

Dado un operador, su tabla de valores se puede especificar con la re-lacion:

LUT (E, f) = {(ei, sj) | ei ∈ E, sj ∈ S ∧ sj = f(ei)}. (3.7)

La tabla de valores LUT (E, f) es una relacion (LUT (E, f) ⊆ E × S)entre las combinaciones de valores de entrada y su correspondiente salida.Verdaderamente, el calculo de la LUT corresponde a una etapa posterior,pero la informacion necesaria para realizar este calculo se proporciona enla inferencia de tipos. Por esta razon, en los diferentes casos, se especificacomo es el calculo de la LUT.

3.6.1. Inferencia cıclica

Hasta el momento se ha supuesto que los GFD son acıclicos. En estaseccion se trata el caso especial de grafos cıclicos producidos por sentenciasrepetitivas de alto nivel. Solo se ha implementado la inferencia cıclicapara el caso particular en el que se conoce el numero de iteraciones entiempo de compilacion. El calculo de la inferencia de tipos cıclica consistebasicamente en repetir el proceso de inferencia tanta veces como se indica


en la sentencia repetitiva con contador. Concretamente, en Smalltalk yMADEO se implementa con el mensaje do:.

En los GFD cıclicos, los datos de entrada de los operadores son engeneral diferentes en cada iteracion del bucle. Por este motivo, se defineE(k) como el conjunto de entradas para la iteracion k-esima de un opera-dor interno del bucle y S(k) para sus salidas respectivas. Ası los calculosde E(k) y S(k) son similares a las ecuaciones 3.1 y 3.6, respectivamente.El conjunto final S es la union de los anteriores conjuntos (S(k)), comose puede observar en las siguientes ecuaciones.

S(k) =⋃

∀ei∈E(k)

f(ei),

S =⋃

∀k∈[1...n]

S(k). (3.8)

(3.9)

Se va a utilizar un ejemplo para analizar los datos inferidos en ungrafo cıclico y la obtencion de las LUT correspondientes a los operadoresde este grafo. El ejemplo consiste en la suma de las componentes deun vector. Su codigo Smalltalk se muestra en la Figura 3.6(a), junto alGFD correspondiente (3.6(b)). Para los lectores sin nociones de Smalltalkse ilustra su funcionamiento en el Algoritmo 1. Este ejemplo solo tieneun operador en el interior del bucle y sera el centro de este analisis.Concretamente, es un sumador procedente de la sentencia sum← sum+cte[i]. El operador suma representa un registro que se actualizara en cadaciclo de reloj. La duracion de este ciclo es como mınimo el tiempo depropagacion de una iteracion.

Algoritmo 1 Suma de un vector.

1: sum← a {Asignacion inicial}2: cte[1]← 3 {Inicializacion del vector cte}3: cte[2]← 24: cte[3]← 1{ La siguiente sentencia (Para) es iteractiva }

5: Para i← 1 hasta 3 hacer6: sum← sum+ cte[i] {Acumulacion}7: fin Para


exdo| sum cte|

sum:=acte at: 1 put: 3.cte at: 2 put: 2.cte at: 3 put: 1.(1 to: 3) do: [:i |

sum:=sum + (cte at: i).].

(a) Codigo

a enable ' 3' ' 2' ' 1'

A counter: B

#Count

choose: A choose: A

A Mux:(B,C) A Mux:(B,C,D)

A+B

'sum'

(b) Grafo de flujo de Datos

Figura 3.6: Programa en Smalltalk y grafo de flujo de datoscorrespondiente al ejemplo de la suma de un vector.

En la Tabla 3.2 se muestran los valores posibles de cada ciclo (k =1, 2, 3) y en la ultima fila la union de todos los valores posibles de las en-tradas y las salidas. El sumador tiene dos entradas con comportamientostotalmente diferentes. La entrada de la izquierda es una entrada princi-pal del circuito para la primera iteracion del bucle (k = 1). Para el restode las instancias (k = 2, 3) es una realimentacion. Se considera que losvalores posibles de la entrada principal son {2 . . . 0} para este ejemplo.La realimentacion conectada a este operador (EA+B

iz ) es la salida de estemismo operador, pero de una iteracion anterior (∀k > 0 : EA+B

iz (k) =SA+B(k − 1) ) como se ve en la Figura 3.6(b). La entrada de la dere-cha del operador es un vector de constantes. Esta entrada tiene un valorconstante diferente en cada iteracion del bucle.

No obstante, existe un problema al calcular la LUT, ya que el productocartesiano de las entradas puede tener combinaciones que no hayan sidocalculadas en la inferencia cıclica. Ası, si se calcula la salida segun laexpresion 3.6, es decir, se calcula la funcion para todos los valores del


k EA+Biz (k) EA+B

dr (k) SA+B(k)

0 [2 . . . 0] 3 [5 . . . 3]

1 [5 . . . 3] 2 [7 . . . 5]

2 [7 . . . 5] 1 [8 . . . 6]⋃

∀k∈[2...0] [7 . . . 0] [3 . . . 1] [8 . . . 3]

Tabla 3.2: Estudio de los posibles valores de las entradas ysalidas para cada iteracion del grafo 3.6(b).

producto cartesiano de las dos entradas (eiz y edr) se obtiene la expresion.

⋃

∀eiz∈EA+Biz

∀edr∈EA+Bdr

eiz + edr = [10 . . . 1]. (3.10)

El resultado de la expresion 3.10 es un conjunto de valores de salida ([10. . . 1]) mas extenso que el calculado anteriormente ([8 . . . 3]). La diferen-cia consiste en que el producto cartesiano de la expresion 3.10 contienecombinaciones que el calculado en la Tabla 3.2 no tiene. Por ejemplo,esto ocurre en los casos en que el operando de la izquierda vale 7 y eloperador de la derecha vale 2 o 3, o el caso en el operador izquierdo vale6 y el operador de la derecha vale 3. Estos casos no se dan en una mismaiteracion del bucle y se puede expresar en la desigualdad

[7 . . . 0]× [3 . . . 1] 6= ({2 . . . 0}× {3})∪ ({5 . . . 3}× {2})∪ ({7 . . . 5} × {1}),(3.11)

donde en la parte izquierda esta el calculo de la LUT para el caso generalaplicando la expresion 3.7, y en la derecha el calculo para el sistema deinferencia cıclico. De una forma mas general se tiene la siguiente desigua-lad

(⋃

∀k

Eiz)× (⋃

∀k

Edr) 6=⋃

∀k

(Eiz(k)× Edr(k)) = E. (3.12)

Ası, queda demostrado que las expresiones 3.6 y 3.7 no son ciertas enel caso de la inferencia cıclica. La causa, como se ha visto antes, es que elconjunto de combinaciones de las entradas no corresponde a la expresion3.1. Este conjunto para el caso de la inferencia cıclica, corresponde a lasiguiente expresion


E =⋃

∀k∈[0...times−1]

n−1∏

i=0

Ei(k). (3.13)

Entonces, la obtencion de este conjunto consiste en calcular el pro-ducto cartesiano de las entradas por cada iteracion y luego realizar launion de todas las iteraciones. Para este calculo se tienen que almace-nar los diferentes productos cartesianos de cada iteracion del bucle. Elalmacenamiento de esta informacion tiene un alto coste de memoria.

Por ello, se ha optado por una solucion de menor coste, pero peoresresultados, pues las LUT tendran mas combinaciones y se generan cir-cuitos mas grandes. La propuesta es modificar la forma de calcular lasLUT sin modificar los conjuntos de entrada. El calculo de la LUT noincluira combinaciones cuya salida no pertenezca al conjunto de salidasposibles. La nueva forma de calcular se expresa en la ecuacion 3.14

LUT = {(e, b) | e ∈ E = Eiz × Edr : b = f(e) ∧ b ∈ S). (3.14)

De esta forma se consigue que para futuros procedimientos siempre setiene el mismo conjunto de salidas posibles y se reducen las combinaciones.Aunque estas LUT no tienen el numero optimo de combinaciones.

La Tabla 3.3 ilustra la diferencia entre la LUT optima y la LUT calcu-lada con este metodo para el ejemplo bajo estudio. Se ha representado enesta tabla el producto cartesiano EA+B

dr ×EA+Biz . Ası, en este caso parti-

cular, la LUT optima es el subconjunto de este producto cartesiano repre-sentado en la tabla con las celdas con el valor “Opt”. La LUT propuestaes la representada en las celdas de la tabla con el valor “Opt” y “Cal”. Lascasillas en blanco representan aquellas combinaciones cuyo resultado noesta en el conjunto de salidas validas (p.e., 7 + 3 = 10 6∈ {3, 4, 5, 6, 7, 8})

EA+Biz

0 1 2 3 4 5 6 71 Cal Cal Cal Cal Cal Opt Opt Opt

EA+Bdr 2 Cal Cal Cal Opt Opt Opt

3 Opt Opt Opt Cal Cal

Tabla 3.3: Producto cartesiano EA+Biz × EA+B

dr donde se repre-sentan los valores incluidos en la LUT optima y la LUT calculada.


3.7. Propagacion hacia atras

La propagacion hacia atras es una tecnica de simplificacion de los re-sultados de la propagacion hacia delante. Esta tecnica permite obtenerinformacion de aspectos globales del circuito para la simplificacion delos operadores. Basicamente, se buscan los valores de las entradas de unoperador que generen la misma salida final del circuito. Ası, para los ope-radores cuya salida sea una salida del circuito final se buscan inicialmentelos valores de las entradas que generen la misma salida.

Supongamos que el ultimo operador es una division entera por unaconstante potencia exacta de 2 (m = 2n). Se puede observar que los ulti-mos n bits de la unica entrada de este operador no intervienen en el re-sultado final, por lo que se puede reducir la tabla de verdad (supongamosque antes tenia 2p combinaciones, ahora tendra 2p−n). Esta informaciontambien se utiliza para simplificar el operador predecesor. Esta simplifi-cacion consiste en eliminar las n funciones asociadas a los bits de menorpeso de la salida, ya que no influyen en el resultado final.

La idea consiste en definir una funcion biyectiva del operador, talque la funcion solo estara definida por los elementos que generen unasalida final diferente. Esta funcion se obtiene aplicando la descomposicioncanonica de la funcion [21]. Esta descomposicion permite sustituir lasdiferentes funciones de los operadores por funciones equivalentes con undominio mas reducido, es decir, que las nuevas funciones se aplican sobreun conjunto de valores mas pequeno. Esta reduccion del dominio consisteen buscar valores equivalentes y sustituir todos los valores equivalentespor un representante. La reduccion de dominios descrita conlleva obtenerlas tablas de valores o LUT de los operadores con menos combinaciones.La descomposicion canonica depende de una relacion de equivalencia (ℜ).Para este caso, la relacion de equivalencia es ”tener las mismas salidas delcircuito global”. Esta relacion define un particionado en el conjunto delas entradas, donde cada clase de equivalencia es sustituida por un valorrepresentativo.

El calculo de esta relacion de equivalencia para los operadores cuyasalida es una salida global (a partir de ahora se llamaran operadoresfinales) consiste en buscar combinaciones de las entradas que den el mismoresultado para ese operador.

Las relaciones de los operadores finales son totalmente independientes,por ello son las primeras relaciones en ser calculadas. El calculo de ℜ paralos operadores no finales no depende de si generan la misma salida, sino de

3.7 Propagaci on hacia atr as 99

si generan salidas equivalentes. El termino “salidas equivalentes” se refierea la relacion de equivalencia definida a las entradas de los operadoressucesores. Por este motivo, despues de calcular los operadores finales, sepodra obtener la de sus predecesores, y ası sucesivamente, hasta alcanzarlas entradas primarias que no se ven afectadas por esta tecnica. En unaseccion posterior se estudiara la posibilidad de modificar el tipo de lasentradas primarias.

Este proceso se divide en dos fases:

1. Particionado de los tipos inferidos de datos (Ver Algoritmo 2).

2. Reduccion de los dominios de los operadores (Ver Algoritmo 3).

La primera fase consiste en obtener un particionado para cada una delas interconexiones correspondientes a las variables internas, donde unainterconexion es una conexion entre una salida de un operador y unaentrada de otro operador. Para definir este particionado hay que definirla correspondiente relacion de equivalencia que se vera en las proximassecciones. La segunda fase de este metodo consiste en obtener un valorrepresentativo por cada clase de equivalencia perteneciente al particiona-do y realizar las sustituciones correspondientes en las tablas de verdad.En definitiva, se reduciran las combinaciones de entrada, ya que el repre-sentante sustituira al resto de los elementos de su clase de equivalencia.

En detalle, en la primera fase se obtiene el particionado en ordenascendente, como se ha comentado anteriormente. El calculo del parti-cionado es diferente para uno o varios operandos, por lo que el calculode la relacion de equivalencia se distinguira para operadores de un unicooperando, que es el caso mas simple, y los operadores de varios operan-dos (n-arios), que seran algo mas complejos. En las siguientes seccionesse detallaran cuatros posibles particionados dependiendo del operador:operador final unario, operador no final unario, operador final n-ario yoperador no final n-ario. En la implementacion de esta tecnica en Madeosolo se ha considerado el caso de uno o dos operandos.

El siguiente paso, correspondiente a la ultima sentencia del Algorit-mo 2, resuelve las bifurcaciones de una salida. El problema surge cuandola salida de un operador esta conectada a varias entradas de diferentesoperadores. Esta interconexion tiene que satisfacer todas las relaciones deequivalencia de las diferentes entradas, por lo que la obtencion del parti-cionado se realiza obteniendo la intersecciones de todas las relaciones de


Algoritmo 2 Particionado de los tipos inferidos de datos.

Entrada: GFD con tipos inferidos de datosSalida: GFD con particionado de los tipos inferidos de datos1: Para nivel ← n hasta 1 hacer2: Para todo operador ∈ GFD[nivel] hacer3: numoper← Calcular el numero de entradas variables.4: si nivel = n entonces5: si numoper = 1 entonces6: ⇒ Calculo del particionado de un operador

unario final. Ver seccion 3.7.17: si no8: ⇒Calculo del particionado de un operador n-ario

final. Ver seccion 3.7.39: fin si

10: si no11: si numoper = 1 entonces12: ⇒Calculo de particionado de un operador unario

no final. Ver seccion 3.7.213: si no14: ⇒Calculo de particionado de un operador n-ario

no final. Ver seccion 3.7.415: fin si16: fin si17: fin Para18: ⇒Calculo de intersecciones de particionado para todas

las entradas que pertenezca a una bifurcacion .Ver seccion3.7.5

19: fin Para


Algoritmo 3 Reduccion de los dominios de los operadores.

Entrada: GFD con particionado de los tipos inferidos de datosSalida: GFD con tipos inferidos de datos y tablas de sustitucion1: Para todo operadores hacer2: ⇒Calculo de la tabla de sustitucion. Esta tabla asocia

cada elemento con el representante de su clase de

equivalencia. Esta tabla se utilizara posteriormente

para el calculo de la LUT.

3: ⇒Calculo de la reduccion de dominio. Sustituir cada

clase de equivalencia por su representante

4: fin Para

equivalencia. Este aspecto se detallara posteriormente.

Despues de la primera fase, se tiene un particionado por cada variableinterna, que se puede ver como un conjunto de conjuntos. En la ultimaetapa se tienen que transformar estos particionados en un conjunto devalores. Para realizar esta transformacion hay que realizar una sustitucionde una clase de equivalencia por un elemento representativo de la mismaclase. No obstante, antes de realizar esta sustitucion hay que almacenarla informacion de esta transformacion. Esta informacion es necesaria parael calculo posterior de la LUT.

Se va a describir el funcionamiento de la tecnica con el mismo ejemplode la seccion 3.6 . Sea la siguiente expresion:

s = (((a%4) + (b%4))%2). (3.15)

El grafo de dependencia obtenido es el mostrado en la Figura 3.7, don-de el particionado obtenido en la propagacion hacia atras esta represen-tado en las entradas de cada operador y en la Tabla 3.4. Evidentemente,para aplicar la propagacion hacia atras hay que calcular el conjunto devalores posibles en la propagacion hacia delante.

La Tabla 3.4 muestra el conjunto de datos de entrada (In) y salida(Out) para cada uno de los operadores de la expresion (3.15) donde semuestra el tamano y numero de LUT (T/N) utilizados para la implemen-tacion de cada operador despues de la propagacion hacia atras.


a b

A % 4 A % 4

A+B

A % 2

s

{{0,2}{1,3}} {{0,2}{1,3}}

{{0,2,4,6}{1,3,5}}

{{0},{1}}

Figura 3.7: Grafo de flujo de Datos de la expresion (((a%4) +(b%4))%2) con anotaciones de la inferencia de tipos hacia de-lante y hacia atras.

Full=Adelante+AtrasOP In Out T NA%4 {0 . . .7} {{0, 2}{1, 3}} 3 1A%4 {0 . . .7} {{0, 2}{1, 3}} 3 1A+B ({{0, 2}, {1, 3}})2 {{0, 2, 4, 6}, 2 1

{1, 3, 5}}A%2 {{0, 2, 4, 6}, {0, 1} 1 1

{1, 3, 5}}

Tabla 3.4: Proceso de propagacion hacia atras para el ejemplo s =(a%4 + b%4)%2).


En la Tabla 3.4 se puede ver la reduccion de tablas para la implemen-tacion de la expresion 3.15. No obstante, la obtencion de la tabla puede noresultar evidente, por lo que vamos a detallar en las siguientes seccionesel proceso de la inferencia de tipos hacia atras dependiendo del tipo deoperadores.

3.7.1. Operadores unarios finales

Este caso particular se va a ilustrar con un ejemplo. Concretamenteel operador unario final (A%2) del circuito de la Figura 3.7 que se estu-dio con detalle en la seccion anterior. Este es el caso mas sencillo porquesolo tiene una entrada y su salida es una de las principales del circuito.En este ejemplo, los posibles valores de salidas de este operador final de-ducidos en la propagacion hacia delante son 0 y 1. Al existir dos unicosvalores, la propagacion hacia atras infiere logicamente la division de losvalores de entrada del operador en dos subconjuntos. Cada uno de estosconjuntos esta compuesto por los valores que producen la misma salida.Concretamente, el conjunto de los pares {0, 2, 4, 6}, valores cuyo resto dela division entera entre dos es cero, y de los impares {1, 3, 5}, valores cuyoresto de la division entera entre dos es uno. En el diagrama de Venn dela Figura 3.8 se ilustra el particionado, donde se representan todos losvalores calculados y las clases de equivalencia obtenidas.

0

1

0

4

2

6

1

5

3

EA % 2

SA % 2

Figura 3.8: Diagrama de Venn donde se representan los parti-cionados para un operador final.

En general, para un operador final unario f con un conjunto de valo-res de entrada E, se define una relacion binaria ℜ donde dos elementos


E

π��

f // S

E/ℜf∗

///o/o/o f(E)

i

OO

Figura 3.9: Diagrama conmutativo correspondiente a la des-composicion canonica de la funcion f .

(ei, ej) del conjunto E estan relacionados solamente cuando tienen la mis-ma salida (f(ei)). En otras palabras:

ℜ = {(ei, ej) | (ei, ej) ∈ E2 ∧ f(ei) = f(ej)}. (3.16)

Se puede demostrar que ℜ es un relacion de equivalencia, por lo quedefine un particionado del conjunto E. La relacion ℜ se va a utilizar parasimplificar la funcion f propia del operador. En el caso de un operadorunario final, la forma de usar esta relacion de equivalencia es una apli-cacion directa de la descomposicion canonica [21] de la funcion f deloperador.

La descomposicion canonica de una aplicacion f : E → S, determinaque existe una unica aplicacion biyectiva (∃!f∗), de tal forma que f =i◦f∗ ◦π, tal como se representa en el diagrama conmutativo de la Figura(3.9).

Donde π es la proyeccion canonica de f e i es la inclusion o inyeccioncanonica de f . La proyeccion canonica es una aplicacion sobreyectiva y noinyectiva, que relaciona cada elemento del conjunto origen con su corres-pondiente clase de equivalencia definida por la relacion ℜ. Formalmenteπ : E → E/ℜ | π(ei) = [ei]. La inclusion canonica es la aplicacioninyectiva y sobreyectiva i : f(E)→ S | i(f(ei)) = f(ei)

A continuacion se explicara como se ha implementado el calculo delconjunto cociente (E/ℜ) en el Algoritmo 4, que corresponde al dominiode la funcion simplificada (f∗). Una de las caracterısticas de una clase deequivalencia respecto a ℜ es que todos sus elementos tienen la misma sa-lida (si = f(ek). ∀ek ∈ [ei]∧ [ei] ∈ E/ℜ). Por lo tanto, este valor de salidaidentifica a cada una de las clases. El algoritmo utiliza una estructura dedatos indexada cuya informacion almacenada corresponde a las clases deequivalencia y el ındice o clave es el valor de la funcion (f(ek)), es decir,


la salida para los elementos de cada clase. En la implementacion de laherramienta, la estructura indexada es un diccionario definido como unade las clases de Smalltalk. A esta estructura de datos se denominara D yse expresa mediante la siguiente relacion.

D = {(si, [ei]) | [ei] ∈ E/ℜ,∃si ∈ S : ∀ej ∈ [ei].si = f(ei)}, (3.17)

En conclusion, se conocen “a priori” cuales son las clases de equiva-lencia y hay una por cada valor de salida. Se inicializa la estructura D deforma que asocia cada valor de la salida con el conjunto vacıo.

En un segundo paso, para cada elemento del conjunto de entrada secalcula su salida (sal), que es la clave para acceder a su correspondienteclase de equivalencia (D[sal]), y se incorpora al conjunto de elementos desu clase ya calculados (D[sal]← D[sal] ∪ ei).

Despues del segundo paso, la estructura D ya podrıa caracterizar elparticionado. Pero las claves no son necesarias, lo importante son lasclases. Por ello, la parte final del Algoritmo 4 construye una estructurade datos para almacenar el particionado (E/ℜ) a partir del diccionario D,sin las claves. Para interpretar correctamente el Algoritmo 4, la operacion“⋃

”se ha sobrecargado para la clase o tipo particionado. De esta forma, laexpresion “E/ℜ ← E/ℜ ∪D(si)” no incluye en E/ℜ todos los elementosdel conjunto de D(si) de forma independiente, sino el conjunto como unaunica entidad u objeto.

Algoritmo 4 Establece el conjunto cociente a la entrada de un operadorunario final.

Para todo si ∈ S hacerD[si]← ∅

fin ParaPara todo ei ∈ E hacersal = f(ei)D[sal]← D[sal] ∪ ei

fin ParaE/ℜ ← ∅Para todo si ∈ S hacerE/ℜ ← E/ℜ ∪D[si]

fin Para


3.7.2. Operadores unarios no finales

El particionado de las entradas de un operador no final no dependesolo del propio operador, sino que esta en funcion de los operadores suce-sores del grafo de dependencia, o dicho de otra forma, de los operadorespredecesores en el calculo de la inferencia de tipos hacia atras. La relacionde equivalencia que define este particionado es tener la misma salida delcircuito global. La salida de un operador no final es una variable interme-dia, que es a su vez la entrada a los operadores sucesores que producenlas salidas del circuito global. La informacion de como afecta la salidadel operador a la salida final esta resumida en el particionado de la sali-da del operador, como se vera a continuacion. Los terminos asociados aun operador sucesor se distinguiran con el superındice “s” (p.e. ℜs, f s, πs).

A todos los efectos, y sin perder generalidad, se considera que solohay una salida sin bifurcaciones. El caso de las salidas bifurcadas (lamisma salida esta conectada a varias entradas) se describe en una seccionposterior.

El conjunto cociente de un operador no final tiene en general un car-dinal menor que los operandos finales. Esto es debido al hecho de quedos combinaciones de las entradas de un operador no final pertenecen ala misma clase de equivalencia si sus salidas pertenecen a la misma clasede equivalencia del operador sucesor. Por ello, un operador no final tieneen general un menor numero de clases de equivalencia, pero un numeromayor de elementos en cada clase.

Despues de describir los principios basicos del particionado para estetipo de operador, se describe la relacion de equivalencia (ℜ) que lo define.Como se ha comentado, esta relacion depende de su operador sucesor.Se denominara ℜs a la relacion de equivalencia que define el conjuntocociente de la salida (S/ℜs) que representa la acumulacion del efecto dela propagacion hacia atras de los operadores sucesores.

Ası, la relacion de equivalencia para los operadores unarios no finalesse define como:

ℜ = {(ei, ej) | (ei, ej) ∈ E2,∃(si, sj) ∈ S2 :

si = f(ei) ∧ sj = f(ej) ∧ (si, sj) ∈ ℜs}. (3.18)

Para obtener una expresion mas simple y mas facil de implementar,se utilizara el diagrama conmutativo de la composicion de las funciones


E

π{{✇✇✇✇✇✇✇✇✇

f

""❊❊❊

❊❊❊❊

❊❊

,,

S

E/ℜ

f∗ ##❋❋❋

❋❋❋❋

❋ Es

**

fs

;;✇✇✇✇✇✇✇✇✇

πs

""❋❋❋

❋❋❋❋

❋❋ f(Es)

is

dd❏❏❏❏❏❏❏❏❏❏

nn

f(E)

i

==③③③③③③③③③Es/ℜs

FFfs∗

::✉✉✉✉✉✉✉✉✉

Figura 3.10: Diagrama conmutativo correspondiente a las des-composiciones canonicas de las funciones correspondientes a unoperador no final.

f sy f correspondientes al operador sucesor y al operador unario no final,respectivamente (ver la Figura 3.10).

Se puede observar en el diagrama conmutativo de la Figura 3.10 quela salida final generada por una entrada del operador en cuestion es lacomposicion de las dos funciones f y f s. Por lo que, la relacion ℜ entredos entradas ei y ej se puede definir como:

eiℜej ⇔ f s ◦ f(ei) = f s ◦ f(ej). (3.19)

Sustituyendo f s por su descomposicion canonica (f s = is ◦ f s∗ ◦ πs) seobtiene la siguiente expresion;

eiℜej ⇔ is ◦ f s∗ ◦ πs ◦ f(ei) = is ◦ f s∗ ◦ πs ◦ f(ej). (3.20)

En el diagrama de la Figura 3.10 se indica con lıneas punteadas comoes la descomposicion canonica de la funcion f s◦f . La funcion de inclusioncanonica es inyectiva y la funcion f s∗ es biyectiva. Esto implica que lafuncion composicion is ◦f s∗ es inyectiva, es decir, dos valores (x, y) tienenla misma imagen si y solo si x e y son identicos (is ◦f s∗(x) = is ◦f s∗(y)⇔x = y), por lo que la expresion anterior se puede expresar de la siguienteforma:

eiℜej ⇔ is ◦ f s∗ ◦ πs ◦ f(ei) = is ◦ f s∗ ◦ πs ◦ f(ej)⇔ πs ◦ f(ei) = πs ◦ f(ej). (3.21)

La proyeccion canonica πs se utiliza para saber si dos salidas son equi-valentes. Ademas, define una aplicacion de Es en el conjunto Es/ℜs que


determina que valores de salida del operador no final producen la mismasalida global del circuito. Por lo tanto, la funcion πs se define como:

πs = {si.[sj ]) | si ∈ Es,∃[si] ∈ Es/ℜs : si ∈ [sj]}, (3.22)

donde [sj] es una clase de equivalencia, de tal forma que:

[sj ] = {∀x ∈ E ∧ xℜssj}. (3.23)

Ası, la expresion de la relacion de equivalencia ℜ en funcion de laproyeccion canonica del operador sucesor πs es la siguiente:

ℜ = {(ei, ej) | (ei, ej) ∈ E2 ∧ πs ◦ f(ei) = πs ◦ f(ej)}. (3.24)

El Algoritmo 5 calcula el conjunto cociente para la entrada de un conjuntounario no final f . El algoritmo utiliza el mismo diccionario D definidoen el caso anterior de operadores finales unarios. Dada una salida, eldiccionario D proporciona el conjunto de todos los valores de entradasque el operador asocia a esta salida.

Ası, si un operador unario final es el operador sucesor de f , los valoresde salidas ya estan agrupados en funcion de la relacion de equivalenciaℜs. Con esta informacion, la forma mas sencilla para obtener las clasesequivalentes es unificar los conjuntos de valores de entradas proporciona-dos por el diccionario que tienen salidas equivalentes. De esta forma, lasdiferentes clases de equivalencia se definen con la siguiente expresion:

[ei] =⋃

∀sj∈πs◦f(ei)

D(sj) , ∀[ei] ∈ E/ℜ. (3.25)

teniendo en cuenta que la proyeccion canonica de πs indica cuando lassalidas son equivalentes.

En el Algoritmo 5, la variable [res] es de tipo conjunto y la variableE/ℜ es de tipo particionado, como se comento en la seccion anterior,por lo que la sentencia E/ℜ ← E/ℜ ∪ [res] anade un nuevo conjunto alparticionado.

3.7.3. Operadores n-arios finales

En el caso de los operadores unarios, el alfabeto de entrada(E) es unconjunto de valores y esta asociado directamente a una unica variableinterna. En el caso de los operadores de multiples operandos (n-arios),


Algoritmo 5 Establecer el conjunto cociente a la entrada de un operadorunario no final.

Para todo si ∈ S hacerD[si]← ∅

fin ParaPara todo ei ∈ E hacersal = f(ei)D[sal]← D[sal] ∪ ei

fin ParaE/ℜ ← ∅Para todo [i] ∈ S/ℜs hacerres← ∅Para todo j ∈ [i] hacer

res← [res] ∪D(j)fin ParaE/ℜ ← E/ℜ ∪ [res]

fin Para

la entrada es un producto cartesiano de todas las entradas (E = E1 ×E2 × · · · ×EN ) y tienen asociadas N variables intermedias, una por cadaoperando. Si se aplicase una relacion similar a los operadores unarios setendrıa un particionado sobre E que no tiene asociada ninguna variableintermedia o interconexion.

En aras de simplificar, y sin perder generalidad, se considera que eloperador es binario y sus operandos son: A y B. Por lo tanto, se definendos relaciones de equivalencia (ℜA y ℜB), una por cada operando sobreel conjunto E = EA × EB . Estas relaciones solo afectan a uno de losoperandos, por lo que dos valores de entrada de un operando son equi-valentes, cuando las salidas son iguales para todas las combinaciones delotro operando (f(ek, ei) = f(ek, ej) ∀ek ∈ EA). Por tanto, se definen lasdos relaciones de equivalencia para operadores binarios finales como:

ℜA = {(ei, ej) | (ei, ej) ∈ E2A : f(ei, ek) = f(ej , ek) ∀ek ∈ EB},

ℜB = {(ei, ej) | (ei, ej) ∈ E2B : f(ek, ei) = f(ek, ej) ∀ek ∈ EA}. (3.26)

El Algoritmo 6 calcula el conjunto cociente de la entrada A de unoperador binario final. Este algoritmo es similar al utilizado en los ope-radores unarios finales y solo cambia la clave del diccionario, que en este


caso es una lista de valores. Esta lista contiene todas las salidas para losdiferentes valores de la entrada B (f(ei, ej) ∀ej ∈ EB). Cada clase deequivalencia de la entrada A esta identificada por una lista de estos va-lores. Ası, dos valores son equivalentes si generan siempre salidas iguales,independientemente del valor de la entrada B. Se ha elegido la mismanotacion de los diccionarios en el acceso a la lista para no sobrecargarla sintaxis del algoritmo. La lista no es necesariamente un diccionario,pues podrıa ser tambien cualquier tipo o clase de coleccion de objetosordenados, por ejemplo una lista o un vector.

Otro cambio menos importante es la creacion de la estructura D. Eneste caso, no se puede iniciar previamente porque no se conocen inicial-mente todas las clases. La inicializacion se llevara a cabo cuando se accedapor primera vez a la clave. En los Algoritmos 4 y 5 existe una correspon-dencia entre el conjunto de salida y el conjunto cociente de las entradas.La correspondencia es directa en los operadores unarios finales, mien-tras que en el caso de operadores no finales unarios esta definida por elconjunto cociente del conjunto salida.

Algoritmo 6 Establece el conjunto cociente de la entrada A de un ope-rador binario final.

Para todo ei ∈ EA hacerPara todo ej ∈ EB hacer

clave[ej ]← f(ei, ej)fin Parasi ∄D[clave] entonces

D[clave]← eisi no

D[clave]← D[clave] ∪ eifin si

fin ParaE/ℜA ← ∅Para todo ix ∈ {claves de D } hacer

E/ℜA ← E/ℜA ∪D[ix]fin Para


3.7.4. Operadores n-arios no finales

Estos tipos de operadores heredan las propiedades de los operado-res n-arios finales y los operadores unarios no finales. Por lo tanto, lasrelaciones definidas para estos operadores son una consecuencia logicade las expresiones 3.24 y 3.26. Por lo tanto, se definen las relaciones deequivalencias para los operadores binarios no finales como:

ℜA = {(ei, ej) | (ei, ej) ∈ E2A ∧ ∀ek ∈ EB : πs ◦ f(ei, ek) = πs ◦ f(ej , ek)},

ℜB = {(ei, ej) | (ei, ej) ∈ E2B ∧ ∀ek ∈ EA : πs ◦ f(ek, ei) = πs ◦ f(ek, ej)}.

(3.27)

El operador correspondiente al segundo nivel del ejemplo 3.4, queesta compuesto exclusivamente por un operador binario no final A + Bconectado al operador unario final A%2, se va a utilizar para detallar eilustrar el particionado de los conjuntos de entradas EA y EB . La Figura3.11 representa los diagramas de Venn correspondientes a las entradasde los operadores implicados del citado ejemplo. El diagrama de la iz-quierda correspondiente al conjunto EA+B , que es el producto cartesiano(EA × EB) del operador suma, muestra todos los posibles resultados deeste operador, indicados con flechas hacia el conjunto EA%2, que es elconjunto de salida del operador suma y tambien el conjunto de entradadel operador A%2. El diagrama de la derecha es el mismo de la Figura3.8. En el momento del calculo, el conjunto EA%2 ya esta particionado,como se describio anteriormente, en dos clases de equivalencia: la de losnumeros pares y la de los numeros impares.El particionado del conjunto EA+B consta de dos conjuntos. La clasede equivalencia representada en la parte superior de este conjunto corres-ponde a todas las combinaciones cuya suma es un numero par, es decir,las combinaciones cuyos dos elementos son pares o los dos son impares.La otra clase de equivalencia corresponde a todas las combinaciones cuyasuma es un numero impar (ver Tabla 3.5).

A partir del particionado de EA+B se obtienen los particionados deEA y EB . Para realizar el particionado de EA se tienen que analizar lassalidas para todos los elementos de EB , de tal forma que dos elementosson equivalentes si las salidas de estos son iguales. Ası, los elementos 1y 3 de EA son equivalentes si f(1, ej) = f(3, ej) ∀ej ∈ EB . Con lo que,se debe analizar con mas detalle el producto cartesiano EA × EB para


Figura 3.11: Diagramas de Venn donde se visualiza los parti-cionados correspondiente a un operador binario final.

detectar estas relaciones.

En la Tabla 3.5 esta el resultado de todas las sumas posibles para lasentradas A y B. Ademas, en cada componente del producto cartesianose indica a que clase de equivalencia pertenece la salida. Como se puedeobservar en la Tabla 3.5, hay dos filas identicas en negrita. Esto indica quela salida es igual para todos los valores del operando B. Estos elementosconcretamente son 0 y 2. Esta coincidencia se repite para los elementosimpares de A y para los elementos pares e impares de B. Por lo tanto,se puede decir que se hereda el mismo particionado de pares e impares,para los dos operandos de este sumador, lo que se puede expresar de lasiguiente forma

EA/ℜ = EB/ℜ = {{0, 2}{1, 3}}. (3.28)

A continuacion, se describe el Algoritmo 7 para obtener el conjuntocociente de la entrada A. Se trata de una variante del Algoritmo 6, peroen este caso se incorpora la creacion de la funcion πs y se utiliza undiccionario para definir esta funcion. La clave del nuevo diccionario Dson las clases de equivalencia de salida para todos los valores de EB. Ası,para la obtencion de la clave se realiza la composicion de las funciones πs

y f como se puede ver en el Algoritmo 7.


A×B 0 1 2 3

0 0 ∈[par] 1 ∈ [impar] 2 ∈ [par] 3 ∈ [impar]

1 1 ∈ [impares] 2 ∈ [par] 3 ∈ [impar] 4 ∈ [par]

2 2 ∈ [par] 3 ∈ [impar] 4 ∈ [par] 5 ∈ [impar]

3 3 ∈ [impar] 4 ∈ [par] 5 ∈ [impar] 6 ∈ [par]

Tabla 3.5: Todas las posibles salidas y sus correspondientes cla-ses de equivalencias del operador AxB.

Algoritmo 7 Establecer el conjunto cociente de la entrada A de unoperador binario no final.

Para todo [i] ∈ S/ℜs hacerPara todo j ∈ [i] hacer

πs[j]← [i]fin Para

fin ParaPara todo ei ∈ EA hacerPara todo ej ∈ EB hacer

sal← f(ei, ej)clave[ej ]← πs[sal]

fin Parasi ∄D[clave] entonces

D[clave]← eisi no

D[clave]← D[clave] ∪ eifin si

fin ParaE/ℜ ← ∅Para todo ix ∈ {claves de D } hacerE/ℜ ← E/ℜ ∪D[ix]

fin Para


3.7.5. Bifurcacion

La bifurcacion es la situacion en que una salida de un operador esta co-nectada a mas de una entrada. En el momento de evaluar esta salida, ca-da entrada conectada a ella tiene su propio particionado, como se puedeobservar en el Algoritmo 2. En las secciones anteriores solo hay un parti-cionado a la salida, por lo que hay que dar una solucion a esta situacion,antes de procesar el operador con esta salida bifurcada.Una posible solucion es replicar el operador tantas veces como conexio-nes tenga la salida, de forma que se eliminen todas las bifurcaciones. Ası,cada operador tendrıa una salida conectada a una sola entrada. El granproblema de esta solucion es el incremento de area que supone la replica-cion de los operadores.

Otra solucion consiste en unificar el particionado, es decir, calcularun nuevo particionado para todas las interconexiones pertenecientes a labifurcacion. Este nuevo particionado satisface todos los particionados delas interconexiones con la finalidad de sustituir cada uno de estos par-ticionados por el nuevo. Concretamente, dos elementos son equivalentesen el nuevo particionado, si y solo si, pertenecen a la misma clase deequivalencia en todos y cada uno de los particionados implicados en labifurcacion. Esto significa que la relacion de equivalencia que define elnuevo particionado es la interseccion de las relaciones de equivalencia delas diferentes interconexiones.

Esta interseccion implica que el orden o cardinal del nuevo conjuntocociente es mayor o igual que el correspondiente a las bifurcaciones antesde unificarlas. En otras palabras, existen mas clases de equivalencia demenor tamano en el nuevo particionado. Por ello, el proceso de la infe-rencia hacia atras no tiene tantas posibilidades de reduccion de las LUT,ya que en general las clases de equivalencia son mas pequenas que antesde unificarlas. Por este motivo puede ser que en algun caso la primerasolucion de replicar operadores pueda obtener mejores resultados.

Sea fanout el conjunto de entradas conectada a la misma salida. Elconjunto fanout indica el operador y su entrada u operando correspon-diente {operador, operando} para cada una de las interconexiones im-

plicadas y por lo tanto la relacion asociada sera ℜoperandooperador . Teniendo en

cuenta todos estos aspectos, la nueva relacion de equivalencia se define


como

ℜ =⋂

∀{op,x}∈fanout

ℜopx . (3.29)

Para simplificar la notacion se utilizara solo una bifurcacion de dos ele-mentos (E/(ℜa ∩ℜb)). No se pierde generalidad ya que al ser la intersec-cion una operacion asociativa, una interseccion de n elementos se puedecalcular de dos en dos, es decir, se calcula la interseccion de la primeracon la segunda, el resultado con la tercera, ası sucesivamente:

(⋂

i∈[1...n]

ℜi = ((. . . (ℜ1 ∩ ℜ2) ∩ ℜ3) . . . )ℜn). (3.30)

De esta forma, la interseccion de dos relaciones para dos operadores a yb que comparten la misma entrada (Exy = Ea

x = Eby) es la siguiente:

(ℜa ∩ ℜb) = {(ei, ej) | ei, ej ∈ E2xy : (ei ℜaei) ∧ (eiℜbei)}

= {(ei, ej) | ei, ej ∈ E2xy : (πs ◦ fa(ei) = πs ◦ fa(ej)) ∧ (πs ◦ f b(ei)

= πs◦f b(ej))}.(3.31)

En el momento de resolver la bifurcacion, como se puede ver en elAlgoritmo 2, se tienen ya calculados los conjuntos cocientes E/ℜa y E/ℜb.Por lo tanto resulta mas sencillo calcular E/(ℜa ∩ ℜb) partiendo de esosconjuntos. Los detalles de este calculo se describen a continuacion.

Dada una clase de equivalencia del particionado E/ℜa, solo hay queencontrar los elementos de este conjunto que tambien esten en la mismaclase de equivalencia del otro particionado E/ℜb.

ei(ℜa ∩ ℜa)ej⇔ (eiℜaei) ∧ (eiℜbei)⇔(ei, ej) ∈ [ei] ∈ E/ℜa ∧ (ei, ej) ∈ [ej ] ∈ E/ℜb. (3.32)

En consecuencia, se hace un particionado de cada clase de equivalen-cia del conjunto cociente E/ℜa. La relacion de equivalencia que defineeste nuevo particionado esta formada por los elementos que pertenezcan


a la misma clase de equivalencia de ℜb. A esta relacion se le llamara Q

Ası, ∀[ek] ∈ E/ℜa se define Q como:

Q = {(ei, ej) | (ei, ej) ∈ [ek]2,∃[el] ∈ E/ℜb : ei ∈ [el] ∧ ej ∈ [el]}, (3.33)

por lo cual se puede deducir que:

E/(ℜa ∩ ℜb) =⋃

[ek]∈E/ℜa

[ek]/Q. (3.34)

Se va a ilustrar esta solucion en el ejemplo de la Figura 3.12, dondela salida de un operador esta conectada a las entradas de dos operadores.Esta figura corresponde a la expresion:

sal1 = (ax%6)/3,

sal2 = (ax%6)/2.

(3.35)

ax

A%6

A/3 A/2

sal1 sal2

{{0,1},2,3,{4,5}

{{0,1}{2,3}{4,5}{{0,1,2}{3,4,5} {0..5}

{0,1,2}{0,1}

Figura 3.12: Grafo de Flujo de Datos con bifurcacion para lasexpresiones sal1 = (ax%6)/3 y sal2 = (ax%6)/2.

La operacion / en esta expresion es la division entera y % es el restoo modulo de la division entera. La solucion de la interseccion de los dos


particionados se puede observar en el diagrama de Venn de la Figura 3.13,donde solo la lınea discontinua describe el particionado de la relacion deequivalencia RA/2 y solo las lıneas continuas describen el particionadode la relacion de equivalencia RA/3. El particionado de la interseccion deestas dos relaciones es el descrito por ambas lıneas.El calculo de la expresion 3.35 esta resumido en la Tabla 3.6. En la

Figura 3.13: Digrama de Venn de la interesccion de los con-juntos cocientes para la bifurcacion del GFD de las expresionessal1 = (ax%6)/3 y sal2 = (ax%6)/2.

tabla se exponen las dos posibles soluciones, partiendo de cada uno delos dos particionados obtenidos de las entradas conectadas a la salidabifurcada. La primera columna es una solucion partiendo del conjuntocociente E/RA/2 para luego aplicar el otro particionado. En esta columna,hay tres particionados correspondientes a las tres clases de equivalencia{0,1}, {2,3} y {4,5} pertenecientes al conjunto cociente E/RA/2. En lasegunda columna hay dos particionados correspondientes a las dos clasesde equivalencia {0,1,2} y {3,4,5}. Los conjuntos cocientes de la primeracolumna son:

{0, 1}/Q = {0, 1}. No se particiona, porque todos los elementostambien pertenecen a la unica clase de equivalencia de E/ℜA/3,concretamente {0, 1, 2}.

{2, 3}/Q = {{2}, {3}}. Se particiona en dos conjuntos con los va-lores 2 y 3 respectivamente. Estos dos elementos estan separadosporque pertenecen a clases de equivalencias de E/ℜA/3 diferentes,2 ∈ {0, 1, 2} ∧ 3 ∈ {3, 4, 5}.

{4, 5}/Q = {4, 5}. No se particiona, porque todos los elementos


E/ℜA/2 E/ℜA/3

{0, 1}/Q={0, 1} {0, 1, 2}/Q′={{0, 1}, {2}}

{2, 3}/Q = {{2}, {3}} {3, 4, 5}/Q′ = {{4, 5}, {3}}{4, 5}/Q = {4, 5}

⋃ {{0, 1}, {2}, {3}, {4, 5}} {{0, 1}, {2}, {3}, {4, 5}}

Tabla 3.6: Calculo de particionado basado en una interseccionde dos relaciones de equivalencia.

tambien pertenecen a la unica clase de equivalencia de E/ℜA/3,concretamente {3, 4, 5}.

La segunda columna se calcula de forma analoga.

{0, 1, 2}/Q′ = {{0, 1}, {2}}. Se particiona en dos conjuntos, {0, 1}y {2}. El primer conjunto esta incluido ({0, 1} ⊂ {0, 1, 2}) en unaclase de equivalencia de E/ℜA/2, en cambio el valor 2 pertenece aotra clase de equivalencia (2 ∈ {2, 3}).

{3, 4, 5}/Q′ = {{4, 5}, {3}}. Se particiona en dos conjuntos {4, 5} y{3}. El primer conjunto coincide con una clase de equivalencia deE/ℜA/2, en cambio el valor 2 pertenece a otra clase de equivalenciadiferente (3 ∈ {2, 3}).

En ambos casos, el resultado del particionado para la bifurcacion esel mismo {{0, 1}, {2}, {3}, {4, 5}}.

Para finalizar, se describe el Algoritmo 8 para resolver la bifurcacionde una salida que esta conectada al operador a y b. Los datos inicialespara el algoritmo son los dos conjuntos cocientes y la funcion πb, que enel algoritmo esta representada con una estructura indexada. Para cadaclase del conjunto se realiza un nuevo particionado. Este particionado serealiza de forma similar a como se ha hecho en secciones anteriores, usandoestructuras indexadas. El primer bucle interno inicializa el diccionario D.El segundo bucle clasifica utilizando como clave el resultado πs, que indicaa que clase de equivalencia del conjunto cociente pertenece E/ℜb. Ası, enel diccionario D se obtiene el particionado por cada clase de equivalenciaque se ha descrito antes.


Algoritmo 8 Calculo de la interseccion de dos relaciones de equivalentespara resolver la bifurcacion.

E/(ℜa ∩ ℜb)← ∅Para todo [ei] ∈ E/ℜa hacerPara todo [ek] ∈ E/ℜb hacer

clave← [ek]D[clave]← ∅

fin ParaPara todo ej ∈ [ei] hacer

clave← πb[ej ]si ∄D[clave] entonces

D[clave]← ejsi no

D[clave]← D[clave] ∪ ejfin si

fin ParaPara todo ix ∈ E/ℜb hacer

E/(ℜa ∩ ℜb)← E/(ℜa ∩ ℜb) ∪D[ix]fin Para

fin Para

3.7.6. Reduccion de los dominios

El objetivo del proceso de la inferencia de tipos hacia atras es redu-cir los dominios de las funciones asociadas a los operadores implicados.La descomposicion canonica se ha utilizado para conseguir este fin, comose ha visto en secciones anteriores (ver el Algoritmo 2). Concretamente,en estas secciones se han descrito los calculos para conseguir el conjuntocociente propio de la descomposicion canonica para los diferentes opera-dores.

Los conjuntos cocientes o particionados obtenidos son conjuntos deconjuntos. El conjunto como unidad tiene que tener una representacionpara facilitar la descripcion de la funcion de la tabla. Por lo tanto, cadaconjunto mencionado se representa mediante un valor perteneciente a esteconjunto, o sea, por el representante de la clase de equivalencia.


E

π

{{✇✇✇✇✇✇✇✇✇✇✇✇✇✇✇✇✇✇

f

!!❈❈❈

❈❈❈❈

❈❈❈❈

❈❈❈❈

❈ Ss

E/ℜ

ϕ

�� O�O�O�O�O�O�O

f∗

��

Es

mini

((

fs

==④④④④④④④④④④④④④④④④

πs

!!❈❈❈

❈❈❈❈

❈❈❈❈

❈❈❈❈

❈ f(Es)

is

dd■■■■■■■■■■■■■■■■■■

ϕ ◦ π(E)

f�

///o/o/o/o/o/o

mini55 f(E)

i

==⑤⑤⑤⑤⑤⑤⑤⑤⑤⑤⑤⑤⑤⑤⑤⑤

mini

HH

Es/ℜ

fs∗

55

ϕ ///o/o/o/o/o/o

mini33ϕ ◦ πs(Es)

f�∗

OOO�O�O�O�O�O�O�

Figura 3.14: Diagrama conmutativo correspondiente a la des-composicion canonica para la obtencion de la LUT.

Existe una funcion ϕ para elegir el representante de un conjunto o clasede equivalencia. La funcion ϕ se define como la aplicacion de E/ℜ → Etal que ei = ϕ([ej ]), donde [ej ] es un clase de equivalencia ([ej ] ∈ E/ℜ)y el valor de la funcion ei es un elemento perteneciente a la clase deequivalencia.

Esta definicion es abstracta y no se especifica cual es el metodo deeleccion. La definicion concreta de la funcion puede ser determinante paralos resultados de la tecnica. Se ha utilizado la funcion que calcula elmınimo de los valores absolutos de todos los elementos de la clase. Estafuncion tiene la finalidad de que la salida tenga el menor numero debits para una codificacion binaria natural. De esta forma, habra menosvariables booleanas y funciones logicas implicadas en el operador. Este esun aspecto abierto que no se ha tratado en esta tesis y se propone comoun trabajo futuro.

3.7.7. Transformacion de operadores

La reduccion de dominios implica un cambio en los operadores. La fun-cion de cada operador se transforma adaptandose a los nuevos conjuntosde las entradas. A continuacion, se describiran estas nuevas funciones y seutilizaran los diagramas conmutativos de un caso simple pero sin perdergeneralidad.


E //❴❴ Sa = Eb //Sb = Ec // . . . //Sn−1 //❴❴❴ S.

��

E //❴❴ ϕ ◦ π(Eb) //ϕ ◦ π(Ec) // . . . //ϕ ◦ π(En) //❴❴ S.

Figura 3.15: Transformaciones de los conjuntos producidas porel proceso de inferencia hacia atras.

Los diagramas conmutativos de la Figura 3.14 corresponden a un ope-rador no final sin entradas principales y su operador sucesor. Es decir, elprimer operador no tiene salidas ni entradas que coincidan con las entra-das y salidas principales del circuito. La reduccion de dominios se realizaaplicando la composicion de dos funciones: la proyeccion canonica (π) y lafuncion de eleccion de representante (ϕ). El conjunto imagen de la funcion(ϕ) se llama ϕ◦π(E) y es un subconjunto del conjunto E (ϕ◦π(E) ⊆ E).En este conjunto estan todos los elementos representantes de cada unade las clases de equivalencia. La nueva funcion mini, resultado de estatransformacion, es un aplicacion del conjunto ϕ ◦ π(E) en ϕ ◦ πs(Es).

La Figura 3.15 es una vision global de un circuito completo. Por sim-plicidad se ha considerado un circuito global con una entrada, una saliday compuesto unicamente de operadores unarios. En la parte superior dela figura, esta la concatenacion de las funciones de los operadores y losconjuntos afectados despues de la inferencia de tipos hacia delante. En laparte inferior esta la misma concatenacion, pero sustituyendo los conjun-tos intermedios. Como se puede observar, para cada operador intermediose sustituye su conjunto de entrada por el conjunto ϕ ◦ π.La funcion mini se puede deducir del diagrama conmutativo de la Figu-ra 3.14 como la composicion de las funciones f�, i, πs y ϕ. La inclusioncanonica i es como la funcion identica por lo tanto:

mini = ϕ ◦ πs ◦ i ◦ f� = ϕ ◦ πs ◦ f�. (3.36)

Las funciones f�, f∗, f son similares y su diferencia es el conjunto do-minio donde se aplica cada una de ellas. Se ha calculado la funcion minipara los operadores no finales y sin entradas principales del circuito. Enel caso de operadores finales, el conjunto imagen es el conjunto de salidaprincipal del circuito. Ası, la funcion mini es una aplicacion del conjuntoϕ ◦ π en el conjunto S. Con lo cual, la funcion mini para este caso es


mini = i ◦ f� = f�. Para el caso en que las entradas de un operador seanprimarias, la aplicacion es del conjunto E al conjunto ϕ◦πs(Es). Concre-tamente mini = ϕ ◦ πs ◦ f es practicamente igual al caso general, aunqueel conjunto E no esta particionado, con lo cual se puede aplicar directa-mente a la funcion f . No obstante, esto ocurre cuando todas las entradasson principales para un operador binario, no donde solo uno de los dosoperandos es una entrada principal. Entonces la funcion mini se calculade forma general, pero teniendo en cuenta que E = EA × ϕ ◦ πs(EB),siendo EA la entrada primaria.

La tabla de busqueda de la funcion tiene que cambiar para que soloproduzca valores incluidos en el conjunto reducido. Es decir, primero segenera la tabla con la funcion original, y luego se debe aplicar un funcionque adapte las salidas (ϕ ◦ πs). Esta adaptacion convierte cada salida enla salida representante de su clase de equivalencia.

Otra cuestion es como modificar los operadores del GFD para que enlas sucesivas fases de simulacion o generacion de LUT se represente fiel-mente el circuito. Como se puede ver en la expresion 3.36, la funcion minies una composicion de la funcion f y de la funcion de adaptacion ϕ ◦ πs,por lo que se tiene que almacenar esta ultima funcion con una estructu-ra indexada o diccionario. De esta forma, esta estructura se utiliza comouna tabla de busqueda para facilitar las tareas de sıntesis y de simulacion.

Para finalizar, se retoma el ejemplo de la expresion 3.5. En la Tabla3.7 se resume la inferencia hacia atras y se puede observar en la columnade “Reduccion” como se ha reducido cada clase de equivalencia por surepresentante. Todas las clases de equivalencia de este ejemplo coincidencon el conjunto de los pares o el conjunto de los impares. En el caso delos pares, el numero en valor absoluto mas pequeno es el 0 y en el casode los impares es el 1. Entonces, los valores representantes son el 0 y el 1.

Ahora se detalla la descripcion de las diferentes LUT de esta expresion.La Figura 3.16 es la red de LUT correspondiente al grafo de flujo de datosde la Figura 3.7 que viene de la expresion 3.5, donde los operadores sontransformados en LUT. En este caso, cada operador se ha transformadoen dos: la LUT propia del operador y la correspondiente a la funcionde adaptacion. En esta figura (3.16) se nombra Trad a la funcion deadaptacion.


Full=Adelante+Atras ReduccionOP In Out Out

A%4 {0.,7} {{0, 2}{1, 3}} {0,1}A%4 {0.,7} {{0, 2}{1, 3}} {0,1}A+B {{0, 2}, {{0, 2, 4, 6}, {0,1}

{1, 3}}2 {1, 3, 5}}A%2 {{0, 2, 4, 6}, {0, 1} {0,1}

{1, 3, 5}}

Tabla 3.7: Proceso de propagacion hacia atras para el ejemplos = (a%4+ b%4)%2).

LUT4 LUT5 LUT6 LUT7

In Out In Out In Out In Out

0 0 (0,0) 0 0 0 0 01 1 (0,1) 1 1 1 1 12 0 (1,0) 1 2 03 1 (1,1) 2

Tabla 3.8: LUT correspondiente al GFD de la Figura 3.16.

En la Tabla 3.8 se detallan las tablas de los operadores del ejemplomostrado. Se han omitido las tablas LUT1 y LUT3, que son equivalentesy cuyo contenido no esta afectado por la inferencia de tipos hacia atras,ya que sus entradas son las entradas principales del circuito, y en estesupuesto no se puede cambiar o reducir. Las tablas LUT2 y LUT4 sonequivalentes. La LUT4 corresponde a la funcion de adaptacion (ϕ ◦ πs).La entrada de este operador se ha originado por la inferencia hacia delan-te, concretamente {0, 1, 2, 3}. La salida es 0 si es par y 1 si es impar, yaque estos son los valores representantes de las clases de equivalencia de lasalida. Esta reduccion se refleja en la Tabla 3.7.6 donde el particionado{{0,2} {1,3}} se ha reducido al conjunto {0,1}. La clase de equivalenciade los pares se ha sustituido por el 0 y la clase de equivalencia de losimpares se ha sustituido por el 1, tal como refleja la Tabla 3.8.

La tabla LUT5 corresponde a la suma de dos operandos cuyos valorespueden ser 0 o 1, y cuyas salidas pueden ser {0, 1, 2}. En cuanto a la tablaLUT6, es la que ajusta los valores posibles a los inferidos por el proceso,


a b

LUT_1[A rem: 4]LUT_3[A rem: 4]

LUT_4Trad LUT_2Trad

LUT_5A+B

LUT_6Trad

LUT_7[A rem: 2]

sal1

Figura 3.16: Red de LUT correspondientes al GFD de la tabla3.7.

concretamente {0,1}. La sustitucion de las clases de equivalencia coincidecon las del caso anterior.

3.7.8. Inferencia hacia atras con agrupamiento de operadores

En esta seccion se propone que la inferencia hacia atras no se apliqueindividualmente por cada uno de los operadores, sino que se aplique aun agrupamiento de operadores que conforman un grafo. Basicamente,consiste en buscar directamente las clases de equivalencia sobre las en-

3.8 Inferencia cuantificada de tipos 125

tradas principales del grafo, omitiendo esta busqueda en los operadoresintermedios.

En los grafos obtenidos en las descripciones jerarquicas de la seccion2.2.3 aparecen un gran numero de bifurcaciones, lo que reduce las posibi-lidades de simplificacion. Por tanto, es interesante aplicar esta tecnica deinferencia en dichos grafos.

Esta tecnica de inferencia calcula el particionado de las entradas cuan-do el proceso de propagacion hacia atras del circuito completo alcance lasalida del grafo. En este caso, y sin perder generalidad, la funcion f de laexpresion 3.37 que define la relacion de equivalencia de este particionado,correspondera al comportamiento del grafo y su calculo se obtendra porsimulacion.

ℜ = {(ei, ej) | (ei, ej) ∈ E2 ∧ πs ◦ f(ei) = πs ◦ f(ej)}. (3.37)

Despues de la reduccion de dominios, es necesario realizar una propa-gacion hacia delante en el grafo implicado para actualizarlo de formacoherente y conlleva una posible simplificacion de los operadores internosdel grafo.

3.8. Inferencia cuantificada de tipos

La cuantificacion es la traduccion de la descripcion de un algoritmoutilizando precision infinita a una con precision finita [27]. En esta sec-cion, se describira el proceso de inferencia de tipos desarrollado aplicadoa tipos de datos con precision finita.

En la practica, el tipo de dato en coma flotante es el que permite alprogramador de aplicaciones DSP no preocuparse por los errores de pre-cision. En cambio, las implementaciones de aplicaciones DSP en FPGAse realizan utilizando coma fija, por una parte por la simplicidad de susoperadores en area, tiempo y consumo; y por otra porque el error de pre-cision es totalmente asumible con una buena cuantificacion.

La cuantificacion es una de las tareas en las que el disenador inviertemas tiempo de desarrollo [152], por lo que ha habido muchos esfuerzospara automatizar este proceso. Esta automatizacion consiste en incluir


metodos para minimizar la longitud de palabra de las variables utilizadaspor el algoritmo. Existen dos clases de metodos para dicha automatiza-cion: los analıticos y los basados en simulacion.

A su vez, los metodos analıticos proponen dos tipos de solucion: unaoptima y otra heurıstica. La solucion optima esta basada en la resolucionde un problema MILP (Mixed-Integer Linear Programming). Sin embar-go, no es una solucion practica por su alto coste computacional al ser unproblema NP-duro. La solucion heurıstica es una solucion mas practicaya que tiene un tiempo de ejecucion polinomico [59, 41, 27].

La cuantificacion automatica basada en simulacion [128, 31, 82] esutilizada en herramientas para aplicaciones DSP, escritas en Matlab oC++ y consta de los siguientes pasos:

1. Generacion de un banco de pruebas.

2. Simulacion con datos en coma flotante.

3. Calculo de la longitud de palabra (parte entera y parte fraccionaria)

4. Simulacion con datos en coma fija.

5. Estimacion del error.

6. Minimizacion la longitud de palabra.

Esta cuantificacion automatica consiste en un proceso de aproxima-ciones sucesivas, donde se repetiran los pasos del 4 al 6 hasta converger aun error objetivo. El sistema de inferencia cuantificada de tipos propuestoesta enmarcado en los metodos de simulacion. El banco de pruebas con-siste en evaluar todas las combinaciones posibles de las entradas, ya que,como se describio en este capıtulo, se evalua cada operador para todaslas combinaciones y obteniendo ası la LUT correspondiente.

En todos los metodos, el error de la salida de una operacion dependetanto del error de precision de la entrada como del error inherente a lapropia operacion. La descripcion tabular con la inferencia de datos haciaatras va a permitir afinar con mayor precision la salida de cada uno delos operadores.

3.8 Inferencia cuantificada de tipos 127

La inferencia cuantificada de tipos no esta totalmente desarrollada ypor lo tanto no se han explotado todas sus posibilidades. El sistema seha probado en la sıntesis de un operador con una unica entrada, espe-cificando el tipo de datos en coma fija a la salida e infiriendo el tipo dedatos de la entrada con la menor longitud de palabra. Concretamente,este proceso se define en el Algoritmo 9.

Esta inferencia es un proceso iterativo y termina cuando las dos ulti-mas iteraciones proporcionan el mismo tipo de datos a la entrada. De estaforma, se asigna inicialmente un tipo de datos a las entradas, se realiza lainferencia de tipos y se modifican los tipos de datos de entrada segun uncriterio que depende de como se han satisfecho las limitaciones impuestasen la salida.

Algoritmo 9 Inferencia de tipo de las entradas primarias.

1: ent.representacion.bitsenteros← 22: ent.representacion.bitsfraccionarios← 03: repetir4: Inferencia Completa de Tipo5: si maximo(S) < limite(S) entonces6: ent.representacion.bitsenteros++7: fin si8: si △ maximo({∀x ∈ Eent/ℜ : minimaprecision(x)}) > 0 entonces9: ent.representacion.bitsfraccionarios++

10: fin si11: hasta (△ent.representacion> 0)

El primer fragmento del algoritmo (sentencias 1 y 2) asigna a la en-trada un tipo de datos inicial. El tipo inicial es el tipo en coma fija demınima longitud en complemento a 2, 2 bits para la parte entera y cerobits para la parte fraccionaria. Por lo que el conjunto de entradas es {0.0,1.0, -1.0, -2.0}.

Despues, se inicia el proceso de aproximaciones sucesivas. Primerose realiza la inferencia completa de tipos y con los resultados de esta,se pasa a evaluar si los nuevos tipos de la entrada no sobrepasan laslimitaciones de la salida. Las limitaciones de la salida vienen definidas porun valor lımite y por el numero de bits de precision, por lo que el procesose define en dos partes: calcular el rango de representacion y obtener la


precision. La primera parte consiste en ir incrementando la parte entera dela entrada hasta alcanzar los lımites de la salida. La segunda incrementa elnumero de bits de precision hasta que la reduccion de dominios obtenidaen la entrada por la inferencia hacia atras no obtenga numeros con mayorprecision a la entrada. Para calcular esta condicion se ha cambiado lafuncion de eleccion de representante de una clase de equivalencia (ϕ) paraque elija como representante aquel elemento que necesite menor numerode bits de precision.

3.9. Conclusiones

El mecanismo de la inferencia de tipos de Madeo es un cambio sig-nificativo en el flujo de diseno hardware clasico, afectando a la forma dedescribir las aplicaciones, a la sıntesis de alto nivel y a la sıntesis logica.

La descripcion con inferencia de tipos proporciona al programador laposibilidad de implementar eficientemente cualquier funcion u operacion,sin necesidad de tener previamente disponibles bibliotecas de componen-tes basicos sintetizados. Otro aspecto importante es la gran expresividady abstraccion de esta descripcion.

En este capıtulo, el punto que se trata mas a fondo es la sıntesis dealto nivel basada en la inferencia de tipos que genera un circuito de LUT.Se describe formalmente y detalladamente el mecanismo basico (propaga-cion hacia delante e inferencia cıclica) y una tecnica de simplificacion quees la inferencia hacia atras. El analisis de los resultados experimentales ysus conclusiones se realizan en el capıtulo 5.

La sıntesis logica de las LUT generadas por la inferencia de tipos serealizara utilizando funciones incompletas. El proceso de la sıntesis logicase describira detalladamente en el proximo capıtulo y los beneficios deutilizar funciones incompletas se veran en el capıtulo 5.

CAPITULO 4Flujo de diseno de bajo nivel

En este capıtulo se describe el tramo final del flujo de diseno propuestoen esta tesis. Concretamente, la programacion de la arquitectura reconfi-gurable a partir de la representacion interna obtenida al final del procesode inferencia de tipos. La estructura de este capıtulo seguira la secuenciade fases de este tramo del flujo de diseno. Estas fases son: la sıntesis dealto nivel, la simplificacion logica y la implementacion final. Se incluyeuna cuarta seccion que describe el entorno computacional detallando lasdiferentes plataformas usadas, la correspondiente distribucion de tareasy su sincronizacion.

4.1. Sıntesis de alto nivel

En general, la sıntesis de alto nivel [148] consiste en la transformacionde una representacion abstracta del comportamiento del circuito a travesde un proceso de reducciones sucesivas de nivel de abstraccion. En el casoconcreto del flujo que se va a describir, la sıntesis de alto nivel consiste enla transformacion del grafo de operadores con los tipos de datos inferidosen una red de LUT. Este grafo es la representacion obtenida en el flujode diseno de alto nivel descrito en los capıtulos 2 y 3: la sıntesis funcionalobtiene el grafo de operadores y la inferencia de tipos incorpora los tiposde datos de cada variable en el grafo.

129

130 Capıtulo 4 Flujo de dise no de bajo nivel

La sıntesis de alto nivel de este flujo concreto consta de dos tareas: lasimplificacion del grafo de operadores y la transformacion de los operado-res en LUT. La red de LUT es una descripcion del circuito independientede la arquitectura reconfigurable, y es la entrada del proceso de sıntesisde bajo nivel que particularizara la implementacion a una arquitecturaconcreta. La sıntesis de bajo nivel esta compuesta por las dos ultimasfases de este flujo: la sıntesis logica y la implementacion final.

4.1.1. Simplificacion del grafo

En la literatura sobre compiladores [8][34] se pueden encontrar variastecnicas de simplificacion de grafos tales como la eliminacion de subgra-fos esteriles o eliminacion de codigo muerto (subgrafos que no afectan alresultado final), factorizacion, etcetera. Estas tecnicas son comunmenteutilizadas en todos los compiladores y sintetizadores, y en este caso seaplicaran en varios niveles en este flujo, tambien en esta fase. En estaseccion solo se describiran las tecnicas de simplificacion derivadas del usode la inferencia de tipos. Estas tecnicas no son tan comunes y solo seaplicaran en esta fase de diseno.

La inferencia de tipos permite detectar constantes en las variablesintermedias y de esta forma se pueden aplicar las dos siguientes tecnicaspara simplificar el grafo de operadores:

Eliminacion de los subgrafos cuya salida es una constante.

Reduccion del numero de entradas de los operadores. Elimina losoperandos que son constantes. Para aquellos operadores que tienenentradas constantes, estas entradas se eliminan. Por ejemplo en la fi-gura 4.1(b) aparece el operador unario [A+2] resultante de eliminarla entrada constante al operador binario inicial A+2.

Despues de aplicar estas tecnicas, el numero de operadores unarios seincrementa y se podra aplicar la tecnica de fusion de operadores.

Hay dos situaciones donde se puede compactar o fusionar operadores.La primera situacion se da cuando una entrada de un operador esta co-nectada a una salida de un operador unario. La segunda se da cuando

4.1 Sıntesis de alto nivel 131

una salida de un operador esta conectada a una entrada de un operadorunario. En ambos casos desaparece el operador unario. Por ejemplo en losoperadores [A+2] y A*B que aparecen en la figura 4.1(a) se aplica la fu-sion de operadores y el resultado es el operador [A+2|A*B] que aparece enla figura 4.1(b). De forma similar, se obtiene el operador [A/16|3*B|A*B].Este operador es el resultado de fusionar primeros los operadores [3*B]y [A*B], y luego el operador [A/16].

No obstante, en las implementaciones realizadas se ha podido obser-var que esta reduccion de operadores no siempre produce una reduccionde area o mejora del circuito final. Las situaciones detectadas que noproducen buenos resultados son las siguientes:

1. Cuando el operador resultante de la fusion tiene mas variables logicasen la entrada.

2. Cuando la salida del operador resultante de la fusion tiene mayor lon-gitud de palabra.

3. Cuando un operador binario tiene una funcion logica simple y el opera-dor unario no. El resultado es un operador binario cuya funcion logicaes compleja. Por ejemplo una suma y luego una raız cuadrada.

4.1.2. Transformacion de los operadores a LUT

Como se ha ido describiendo a lo largo de esta tesis, una de sus prin-cipales aportaciones es obtener un circuito independiente de bibliotecasde operadores presintetizados, proporcionando una forma generica y ho-mogenea de sintetizar los operadores. Esta forma consiste en transformarcada operador en una tabla de consulta o LUT, por lo que el circuito finales una red de LUT. La transformacion se describio en el capıtulo anteriory se realiza gracias al sistema de inferencia de tipos.

En resumen, esta consiste en que el proceso de inferencia de tiposobtiene el conjunto de valores posibles por cada variable o interconexion.Ası, cada operador es una funcion incompleta definida solamente por elproducto cartesiano de los conjuntos de valores inferidos por cada unade las variables de entrada. La LUT del operador asocia cada elemento


x y z

[A+2][3*B]

A*B

A*B

[A/16]

sal

(a) Antes

x y z

[A+2|A*B]

[A/16|3*B|A*B]

sal

(b) Despues

Figura 4.1: Fusion de operadores

de producto cartesiano con el correspondiente valor del operador. Por lotanto, la LUT se define mediante la siguiente expresion:

LUT (E, f) = {(ei, sj) | ei ∈ E ∧ sj = f(ei)}. (4.1)

El calculo de la LUT lo realiza el simulador del grafo de operadorespresentando en la seccion 2.3.

Hasta el momento, todo el proceso de sıntesis se ha desarrollado deforma independiente de los sistemas de representacion de los tipos de da-tos usados. Para poder realizar la sıntesis logica se tienen que convertir lasLUT a tablas de verdad y para esta conversion es necesario concretar yaplicar el sistema de representacion a utilizar en cada variable intermedia.Actualmente, los sistemas de representacion utilizados son las codificacio-nes binarias clasicas y estan definidas en los tipos de las clases de Madeo(ver seccion 3.3.2). Ası, los enteros (Signed) se representan en comple-mento a dos. Otra posibilidad es buscar una codificacion especıfica porcada variable intermedia con el criterio de dirigir el resultado de la sınte-sis en el espacio de diseno. En la literatura se pueden encontrar algunascodificaciones especıficas para mejorar las prestaciones de los circuitos

4.2 Sıntesis l ogica 133

secuenciales sıncronos[68], o para reducir su consumo [19][95][18].

El metodo de transformacion de los operadores en LUT tiene unosresultados significativamente malos para determinados operadores (p.e.sumadores). Por lo tanto, se flexibiliza uno de los principios de diseno delentorno de Madeo para proporcionar al disenador de hardware la posibi-lidad de utilizar componentes muy eficientes incluidos en las bibliotecasde cualquier entorno EDA. Esta posibilidad se habilita configurando elsintetizador de forma que, cuando encuentre uno de estos operadores, norealice su transformacion en LUT, sino que posponga su descripcion parauna fase posterior (como se vera en la seccion 4.3).

4.2. Sıntesis logica

La sıntesis logica es un proceso incluido en los flujos de diseno de bajonivel que consiste en la simplificacion del conjunto de expresiones boolea-nas que describe el circuito [60].

La sıntesis logica consta de dos procesos de optimizacion. El prime-ro consiste en aplicar optimizaciones independientes de la arquitecturareconfigurable y el segundo en aplicar optimizaciones especıficas para laarquitectura a utilizar.

En el caso concreto de la sıntesis logica de Madeo, la primera optimi-zacion es una resıntesis logica para funciones incompletas. Una operacionde resıntesis sobre la funcion f consiste en rescribir la representacion dela formula sintactica de f, manteniendo su funcionalidad semantica [75].

La inferencia de tipos es una resıntesis de alto nivel ya que reduce elnumero de asociaciones de las LUT. Las tablas de verdad obtenidas de latraduccion de estas LUT son por lo tanto funciones logicas incompletas,ya que solo estan definidas para las combinaciones de las entradas obteni-das en la inferencia de tipos. Las combinaciones no definidas en la funcionlogica son utilizadas para la resıntesis logica buscando una funcion logicaequivalente que simplifique el circuito final.

Los metodos de resıntesis logica de funciones incompletas utilizan mo-


tores de satisfacibilidad booleana. La satisfacibilidad booleana es un pro-blema NP-completo y por lo tanto tiene un alto coste computacional [52].Estos metodos utilizan paquetes de simplificacion logica tradicionales con-sistentes en la obtencion de redes logicas multinivel (un ejemplo de estoses Espresso[101]). Estos paquetes permiten trabajar con diferentes siste-mas de representacion de redes logicas, tales como SOP, BDD y AIG [107].

Se han realizado dos experimentos para analizar los beneficios deluso de la resıntesis logica en funciones incompletas. Para este analisis, seconstruye una funcion incompleta tomando un numero de combinacionesaleatorias de una funcion completa. El analisis se realiza comparando elarea del circuito generado usando la resıntesis logica y sin usarla. Si no seutiliza la resıntesis logica, la funcion es 0 para las combinaciones no defi-nidas. En caso de utilizar resıntesis logica se le proporciona este conjuntode combinaciones al sintetizador.

En el primer experimento, la funcion original es un multiplicador deoperandos de 4 bits. En la figura 4.2, se puede observar los beneficios dela resıntesis, ya que independientemente del numero combinaciones inde-finidas, se consigue una area del circuito mucho mas reducida utilizandoresıntesis. Aunque lo mas interesante del resultado de la resıntesis es quea mas combinaciones indefinidas menor es el area del circuito.

Para el segundo experimento, se utiliza el resto de la division enterade un entero de 10 bits entre 256. El resultado optimo de esta funcion esuna area de 0 slices, porque la salida corresponden a los bits de menorpeso de la entrada, por lo tanto son simples conexiones. No obstante, elresultado de la resıntesis es sorprendente ya que en el peor caso el areaesta cerca de 500 slices y siempre muy superior al resultado optimo comose puede observar en la figura 4.3. Ademas no hay apenas diferencia entrelos resultados “Con resıntesis” y “Sin Resıntesis”.

La conclusion es que el sintetizador, sin utilizar la resıntesis, reduce elnumero total de variables de la funcion, pero cuando se usa la resıntesisno lo reduce en los casos en que la funcion tiene muchas variables. Se haincluido un proceso en Madeo que reduce el numero de variables de lafuncion suprimiendo las variables que no influyen en el comportamientode la funcion.


0

50

100

150

200

250

0 10 20 30 40 50 60 70 80 90 100

Sli

ces

%Combinaciones indefinidas

Con resintesisSin resintesis

Figura 4.2: Efecto de la resıntesis logica para funciones incom-pletas en el caso de la multiplicacion de 4 bits

En cuanto a la optimizacion especifica de la FPGA, se considera quesu arquitectura corresponde a una matriz de LUT de k−entradas, dondek se encuentra actualmente en el rango de 4 a 8. A esta optimizacion sellama mapeado tecnologico y consiste en transformar la red logica mul-tinivel en una descripcion estructural formada por componentes propiosde la FPGA, en este caso por LUT de k-entradas.

El software utilizado para la sıntesis logica ha sido desarrollado por elgrupo de ”Logic Synthesis and Verification”de la Universidad de Berkeley,de reconocido prestigio en este campo. Este software ha evolucionado deuna forma vertiginosa [106]. Su tiempo de ejecucion ha mejorado en tresordenes de magnitud desde su primer programa llamado SIS (de 1992)[134]. Ademas, esta reduccion del tiempo de ejecucion ha llevado consigouna mejora en la escalabilidad de las aplicaciones a abordar, el area y eltiempo de respuesta de los circuitos resultantes. Es logico pensar que dadaesta evolucion, se sigan obteniendo mejoras en este sintetizador y, por lo


0

100

200

300

400

500

600

0 20 40 60 80 100

Sli

ces

%Combinaciones indefinidas

Con resintesisSin resintesis

Figura 4.3: Efecto de la resıntesis logica para funciones incom-pletas en el caso del resto de la division entera

tanto, puedan mejorarse los circuitos generados por Madeo. No obstante,las necesidades computacionales de la sıntesis logica de Madeo son altas,por este motivo es necesario usar una plataforma de altas prestacionesque se describira con mas detalle en la seccion 4.4 de este capıtulo.

En la practica, los mayores problemas de la resıntesis logica aplicada alas tablas de verdad obtenidas por Madeo son la escasa escalabilidad y elgran coste de memoria. Para reducir el coste de memoria, se ha descom-puesto el proceso de simplificacion del circuito completo. Ası, lo primeroque se simplifica es cada salida binaria de un operador. Luego se sim-plifica y se realiza el mapeado tecnologico de todo el operador completo(ver figura 4.4). De esta forma se reduce considerablemente el tiempo deejecucion y la memoria consumida por estos procesos, incrementandoseel tamano maximo de los circuitos que se pueden procesar.


En la siguiente seccion se describira en detalle la conversion de lasLUT al formato concreto del paquete de sıntesis logica utilizado.

LUT

e7 e6 ... e3 e2 e1 e0 s2

1 0 ... 0 0 1 1 1

1 0 ... 0 1 0 0 0

resto de combinaciones X

e7 e6 ... e3 e2 e1 e0 s1

1 0 ... 0 0 1 1 0

1 0 ... 0 1 0 0 1


e7 e6 ... e3 e2 e1 e0 s0

1 0 ... 0 0 1 1 1

1 0 ... 0 1 0 0 0


mapeadotecnológico

Figura 4.4: Ejemplo de un conversion de una LUT en tablas deverdad y la correspondiente ejecucion de tareas para realizar lasıntesis logica.

4.2.1. Descripcion de las tablas de verdad para el sintetizadorlogico

Las tablas de verdad generadas para el sintetizador logico tienen unnumero variable de entradas y salidas. El formato utilizado es el BLIF.En este formato se define una tabla de verdad por cada una de las salidas.El listado 4.1 es un ejemplo de este formato.


La definicion de la interfaz del circuito se realiza usando las directi-vas: .model, .inputs y .outputs, que definen el nombre, las entradas ysalidas, respectivamente. A continuacion, se definen las sucesivas tablasde verdad. La directiva .names define las entradas y salidas de cada ta-bla. La salida es la ultima variable de la lista, y el resto son las entradas.Las combinaciones de las tablas se definen indicando solo las combina-ciones que hacen que la funcion valga uno (miniterminos) o solo las quehacen que la funcion valga cero (maxiterminos). En el ejemplo del lista-do 4.1, se describe especificando los miniterminos. La nomenclatura es lasiguiente (00001 1), donde la primera cadena especifica la combinaciony el siguiente valor indica que la funcion vale 1. Por lo tanto, la descrip-cion basada en maxiterminos se diferencia en que el segundo valor es un 0.

De esta forma, se describen las tablas de verdad de funciones comple-tas. En el caso de funciones incompletas, se describen primero las tablas deverdad para las combinaciones definidas de la funcion, despues se describeuna tabla de verdad adicional que vale un 1 para todas las combinacionesno definidas en la funcion original y 0 para el resto de las combinaciones.Esta tabla se distingue por la directiva .exdc (external don’t cares) que sesitua delante. En las ultimas versiones del sintetizador se ha modificado elformato y los valores no definidos se describen como una tabla de verdadindependiente y se indica con un comando especıfico del sintetizador quese incluyan en la red logica como valores externos indefinidos.

El listado 4.1 corresponde a un operador (A+B/4) y los valores inferidosson {0,3} para la variable A y {1,2,5,6} para la variable B. Por lo tantoel conjunto E de las combinaciones de las entradas de este operador es elproducto cartesiano de estos valores inferidos; concretamente:

E = {{0, 1}, {0, 2}, {0, 5}, {0, 6}, {3, 1}, {3, 2}, {3, 5}, {3, 6}}.

La salida del operador es 0 para las siguiente tres combinaciones: {0, 1},{0, 2} y {3, 1} y es 1 para las cinco restantes. Por lo tanto, se describela tabla de verdad a partir de los maxiterminos, al haber menos com-binaciones que hacen cero la funcion. El ultimo paso para obtener lastablas de verdad es expresar estos valores en binario. Ası, para la variableA se utilizan 2 bits y para la variable B se utilizan 3 bits, resultandoque el conjunto de combinaciones indefinidas del operador es el siguien-te: φ = {0 . . . 3} × {0, 3, 4, 7} ∪ {1, 2} × {0 . . . 7}. La funcion asociada ala directiva .exdc es uno cuando en las entradas hay una combinacion

4.3 Implementaci on final 139

incluida en el conjunto φ. El cardinal de φ es 24 por lo que la funciontendra 24 unos y 8 ceros, y la forma mas simple de describirlo es usandolos ceros.

Listado 4.1: Tabla de verdad en formato BLIF correspondientea un operador.

✞.model LUT 1141d.inputs A 1 A 0 B 2 B 1 B 0.outputs signalt24 0

.names A 1 A3 0 B 2 B 1 B 0 signalt24 0

00001 000010 011001 0

.exdc

.inputs A 1 A 0 B 2 B 1 B 0

.outputs signalt24 0

.names A 1 A 0 B 2 B 1 B 0 salida noimporta

00001 000010 000101 000110 011001 011010 011101 011110 0

.names salida noimporta signalt24 01 1.end

✡✝ ✆

4.3. Implementacion final

Madeo se concibio como un entorno completo y autonomo para di-senar aplicaciones para cualquier arquitectura reconfigurable por lo quetiene herramientas de soporte de ejecucion para realizar la implementa-cion final y generar la correspondiente configuracion del dispositivo. Noobstante los experimentos y las aplicaciones desarrolladas en esta tesis sehan realizado sobre FPGA comerciales y se ha integrado estos entornosEDA comerciales en el flujo de diseno de bajo nivel debido a la produc-tividad de estas herramientas, a las buenas prestaciones obtenidas de losproyectos desarrollas y por tener disponibles sistemas de desarrollo coneste tipo de FPGA. Concretamente, se ha utilizado para los experimentosde esta tesis la Virtex-4 de Xilinx.


Para realizar la integracion con estos entornos EDA/ESL, es necesa-rio expresar la informacion obtenida en las fases anteriores en un formatoestandar para las herramientas EDA. Los formatos tıpicos para compartircomponentes entre entornos EDA son el EDIF y los lenguajes de descrip-cion hardware de amplia difusion como Verilog y VHDL. Estos formatos ylenguajes se describieron en el capıtulo 1. Madeo puede generar el circuitofinal tanto en formato EDIF como en VHDL. Una aportacion a Madeoen esta tesis es el modulo de generacion de VHDL.

Las ventajas de la generacion de VHDL en comparacion con el forma-to EDIF son las siguientes:

Mayor independencia de la FPGA a programar. La descripcionEDIF depende de la biblioteca de recursos de la FPGA a progra-mar, ya que el circuito es una descripcion estructural de estos com-ponentes. En cambio la descripcion VHDL es independendiente deesta biblioteca y el proceso de mapeado tecnologico pertenecienteal sintetizador es el encargado de convertirla en una descripcionestructural de los componentes basicos de la FPGA.

Mayor disponibilidad de simuladores. La inmensa mayorıa de si-muladores funcionan directamente con VHDL mientras que parasimular un archivo EDIF es necesario la conversion a otro lenguaje.

Mayor facilidad de utilizacion de bibliotecas convencionales de com-ponentes. La descripcion VHDL abstrae muchos detalles en la uti-lizacion de muchos de estos componentes. Ası por el ejemplo, unsumador en VHDL se expresa a<=b+c, en cambio la descripcionEDIF se describe instanciando el componente de una biblioteca ypor lo tanto se tienen que detallar las interconexiones de la interfazdel componente con el resto del circuito.

La desventaja de utilizar VHDL es el coste computacional de la sınte-sis, que en el caso que nos atane es especialmente alto. A continuacionse describen las diferentes soluciones que se fueron tomando para reducireste alto coste.

Las primeras pruebas transformaban las LUT de los operadores di-rectamente a VHDL sin realizar la sıntesis logica descrita en la seccionanterior. Las sıntesis de estas prueba no resultaron viables computacional-mente (tiempo de ejecucion desproporcionado, altısimo coste de memoria)


y ademas el area del circuito resultante era inmanejable. El motivo de es-tos malos resultados es que los sintetizadores EDA no estan optimizadospara las descripciones tabulares propias del entorno de Madeo. Estos sin-tetizadores se basan en sustituir los operadores de las expresiones RTLpor componentes pre-sintetizados. Estos componentes tienen una sıntesislogica y arquitectural muy elaborada fruto de un trabajo especializado yrealizado “a priori” fuera del entorno.

La primera opcion fue introducir la etapa de sıntesis logica especıfi-ca para descripciones tabulares. Esta sıntesis, como ya se describio en laseccion anterior, utiliza la resıntesis de funciones incompletas. Proporcio-nara buenos resultados en las descripciones tabulares de los operadores.Permitira utilizar sistemas de calculo de altas prestaciones como se des-cribira en la proxima seccion.

Listado 4.2: Una tabla de verdad expresada en VHDL utili-zando sentencias RTL

✞todas entradas <= A8 4&A8 2&A8 0;with todas entradas select

signalt41 4<=”1” when ”010”,”1” when ”001”,”0” when ”101”,”0” when ”100”,”0” when ”110”,”0” when ”111”,”0” when ”000”,”0” when ”011”,(others=>’X’) when others;

end germanin luts;

✡✝ ✆

Despues se busco la forma mas eficiente de describir las LUT de pe-queno tamano resultante de la sıntesis logica. Concretamente LUT de 4entradas que son las mas pequenas de una Virtex-4. En los experimentosrealizados a menor tamano de las LUT se han obtenido mejores resulta-dos y tiempos de sıntesis menores. La forma de describir las LUT afectasorprendemente a los tiempos de ejecucion y a la memoria utilizada porel sintetizador. A continuacion se describen las diferentes descripcionesestudiadas.

La primera descripcion utilizada (ver el listado 4.2) para estas LUTfue una descripcion RTL basada en la sentencia de VHDL de seleccion


multiple (with . . . when). El tiempo de ejecucion de la sıntesis utilizandoeste tipo de descripcion es desproporcionado y el resultado desastroso.

Para la segunda descripcion se utilizo memoria ROM (ver el listado4.3). Este componente pertenece a las bibliotecas de recursos especıfi-cos de las FPGA y estan disponibles para tamanos pequenos de 16x1a 128x1. Estas memorias se mapean en una o varias LUT fısicas de laFPGA. Concretamente, una ROM 16x1 es mapeada en una LUT de 4entradas, y una ROM 128x1 es mapeada en ocho LUT. Como se puedeapreciar en el listado, la clausula generic map (INIT => X"FFFF07FE")

especifica los valores almacenados en la ROM y por lo tanto define lafuncion logica generada por la ROM. El objetivo es evitar esfuerzos alsintetizador y dar una descripcion similar al EDIF.

Los resultados son buenos para circuitos pequenos pero consumen unagran cantidad de memoria en los sintetizadores de VHDL utilizados (XST,Synplify y LeonardoSpectrum) siendo inviable para circuitos grandes.

Listado 4.3: Una tabla de verdad utilizado un ROM✞component ROM32X1 generic(INIT:bit vector); port(O:out std logic;

A0,A1,A2,A3,A4: in std logic);

end component;begin

inst mLUT 358 10 :ROM32X1generic map (INIT => X”FFFF07FE”)port map (

O=>signalt41 1(0),A4=>A8 4(0),A3=>A8 3(0),A2=>A8 2(0),A1=>A8 1(0),A0=>A8 0(0));

✡✝ ✆

La tercera descripcion consistio en describir cada tabla de verdad enuna funcion booleana equivalente (ver el listado 4.4). Con esta descripcionlos resultados son buenos y desaparecen los problemas de memoria aunquelos tiempos de sıntesis son grandes.

La cuarta descripcion utiliza las memorias empotradas tıpicas (BRAM)de las FPGA. De esta forma, el mapeado tecnologico se realiza para LUT


Listado 4.4: Una funcion booleana de 4 variables expresadaen VHDL equivalente a una LUT.

✞

n26(0)<=(A9 3(0) or signalt70 3(0) or not n29(0)) and (A9 3(0) ornot n27(0)) and (signalt70 3(0) or not n27(0)) and ( not n27(0) ornot n29(0));

✡✝ ✆

de mayor numero de entradas y por lo tanto el tiempo de sıntesis sereduce. La descripcion consiste en generar un ROM con una memoriaempotrada deshabilitando la senal de escritura como muestra el listado4.5. Las memorias empotradas de la FPGA utilizada tienen de 9 a 14bits de direcciones y por lo tanto puede generar LUT de ese numero deentradas.

El resultado no fue el esperado ya que los tiempos de ejecucion de lasıntesis logica eran inasumibles. La idea estaba concebida para un parti-cionado descendente desde tamanos mayores a menores sin embargo losalgoritmos de mapeo [80][7][101] funcionan al reves, es decir, agrupandocircuitos simples en circuitos mas grandes hasta alcanzar el tamano ob-jetivo. Concretamente, el mapeador utilizado lo primero que realiza esuna transformacion del circuito a una representacion AIG (And-InverterGraph). Esta representacion consiste en una descripcion estructural utili-zando puertas AND e inversores, por lo tanto el siguiente paso es agruparlas puertas logicas para conseguir una estructura de LUT de 3 entradas,luego de 4 entradas y ası sucesivamente. Por tanto, el tiempo de ejecucioncrece en funcion del tamano de la LUT.

Las pruebas han demostrado que la mejor descripcion es la tercera uti-lizando expresiones booleanas. El planteamiento inicial era que el circuitofuese descrito totalmente en VHDL ya que su correspondiente sintetiza-dor podıa mejorar la calidad del circuito generado, puesto que permitıaaplicar tecnicas de simplificacion logica al circuito completo ( la sıntesislogica de Madeo se aplica a cada uno de los operadores) y porque podrıatener tecnicas mas avanzadas de simplificacion. Los resultados experimen-tales determinaron que el sintetizador VHDL no aportaba beneficios enla calidad de los circuitos y el tiempo de sıntesis era mucho mayor.


Listado 4.5: Una tabla de verdad expresada en VHDL utili-zando memoria empotrada (BRAM)

✞library IEEE;use ieee.std logic 1164.all;use ieee.std logic arith.all;use ieee.std logic signed.all;library UNISIM;use UNISIM.vcomponents.all;entity bram isport (

signalt19 5: in std logic vector (0 downto 0);signalt19 4: in std logic vector (0 downto 0);signalt19 3: in std logic vector (0 downto 0);signalt19 2: in std logic vector (0 downto 0);signalt19 1: in std logic vector (0 downto 0);signalt19 0: in std logic vector (0 downto 0);signalt8 4: in std logic vector (0 downto 0);signalt8 3: in std logic vector (0 downto 0);signalt8 2: in std logic vector (0 downto 0);signalt8 1: in std logic vector (0 downto 0);signalt8 0: in std logic vector (0 downto 0);signalt28 0: out std logic vector (0 downto 0);

clk,reset:in std logic);end bram;architecture in luts of bram iscomponent RAMB16 s9generic(INIT:bit vector:=X”000”;SRVAL:bit vector:=X”000”; WRITE MODE:string:=”READ FIRST”;INIT 00

,INIT 01,INIT 02,INIT 03,INIT 04,INIT 05,INIT 06,INIT 07,INIT 08,INIT 09,INIT 0A,INIT 0B,INIT 0C,INIT 0D,INIT 0E,INIT 0F,INIT 10,INIT 11,INIT 12,INIT 13,INIT 14,INIT 15,INIT 16,INIT 17,INIT 18,INIT 19,INIT 1A,INIT 1B,INIT 1C,INIT 1D,INIT 1E,INIT 1F,INIT 20,INIT 21,INIT 22,INIT 23,INIT 24,INIT 25,INIT 26,INIT 27,INIT 28,INIT 29,INIT 2A,INIT 2B,INIT 2C,INIT 2D,INIT 2E,INIT 2F,INIT 30,INIT 31,INIT 32,INIT 33,INIT 34,INIT 35,INIT 36,INIT 37,INIT 38,INIT 39,INIT 3A,INIT 3B,INIT 3C,INIT 3D,INIT 3E,INIT 3F:bit vector);

port( DI: in std logic vector (7 downto 0);DIP: in std logic;ADDR: in std logic vector (10 downto 0);EN: in std logic;WE: in std logic;SSR: in std logic;CLK: in std logic;DO: out std logic vector (7 downto 0);DOP: out std logic);

end component;signal cero : std logic;signal uno : std logic;signal ceros : std logic vector (7 downto 0);signal ceros1 : std logic;signal todas salidas : std logic vector (7 downto 0);signal todas entradas : std logic vector (10 downto 0);begin

todas entradas <= signalt19 5&signalt19 4&signalt19 3&signalt19 2&signalt19 1&signalt19 0&signalt8 4&signalt8 3&signalt8 2&signalt8 1&signalt8 0;signalt28 0(0) <= todas salidas(0);cero<=’0’;uno<=’1’;ceros<=(others=>’0’);ceros1<=’0’;inst bram :RAMB16 s9generic map (INIT 00=>X”0100010001000100010001000100010001000100010001000100010001000100”

,INIT 01=>X”0001000100010001000100010001000000010001000100010001000100010001”...,INIT 3F=>X”0001000100010001000100010001000000010001000100010001000100010001”) port map (CLK=>CLK,ADDR=>todas entradas,DI=>ceros,DOP=>open,

EN=>uno,DO=>todas salidas,DIP=>ceros1,SSR=>cero,WE=>cero);end germanin luts;

✡✝ ✆

4.4 Entorno del sintetizador de Madeo 145

Por lo tanto, la descripcion VHDL es utilizada para la simulacion delcircuito y para utilizar componentes incluidos en las bibliotecas pertene-cientes al sintetizador. En el caso de la simulacion es necesario que en ladescripcion solo se utilice VHDL pero en el caso de utilizar componentesde la biblioteca se describiran utilizando ambos lenguajes: EDIF para losoperadores descritos de forma tabular y el VHDL para invocar a estoscomponentes.

4.3.1. Integracion con entornos EDA/ESL comerciales

Despues de obtener la descripcion del circuito, solo resta generar laconfiguracion de la FPGA utilizando herramientas EDA/ESL. Hay dosformas diferentes de realizar este proceso. La primera consiste en quese utilicen las herramientas del entorno para describir un sistema dondeunos o varios componentes han sido desarrollados en Madeo. En este casoel propio entorno realizara la integracion y la implementacion final deldiseno. La integracion se realiza utilizado alguno de los metodos propiosde la herramienta para incorporar componentes externos. Madeo solo de-be proporcionar el componente en el formato correspondiente (EDIF oVHDL).

La segunda forma consiste en que Madeo describe el sistema completoy por tanto solo utiliza el software del fabricante de la FPGA para ge-nerar su configuracion. El flujo completo con las diferentes opciones paraobtener la configuracion final se muestra en la figura 4.5. En esta segundaforma, el entorno Madeo tiene que invocar la ejecucion de los diferentesprogramas EDA. Esta invocacion consiste en una secuencia de comandosen lınea, que se almacenaran en un archivo, lo que normalmente se llama“script”. Dentro del entorno de Madeo, se especifica el dispositivo FP-GA destino, que tipo de resultados se quiere obtener (por ejemplo si sequiere obtener resultados de consumo de potencia, si se quiere hacer unaestimacion de los resultados finales, o si se quiere realizara la implemen-tacion completa), y que sintetizador de VHDL se quiere utilizar. Con estainformacion, se generaran los correspondientes “scripts”.

4.4. Entorno del sintetizador de Madeo

El objetivo principal de esta tesis ha sido la sıntesis eficiente de aplica-ciones de tratamiento de la senal utilizando Madeo. La ejecucion del flujo


Sistema MADEO

Aplicación

Arquitectura Reconfigurable

Modelo de ejecución de la plataforma

Sistemas ESL/EDA externos

Aplicación

Soporte de ejecución de dispositivos reconfigurables

Síntesis de Alto Nivel

Síntesis de lógica

Place & route

Sintetizador

Place & route

Código de la Aplicación

compilar

Asignación de tipos

Grafo de Operaciones

Descripción de la plataforma

Especializar

Modelo Abstracto

Modelo Concreto

Floorplanning Estimadores...

Descripción del sistema

Floorplanning ...Estimadores

Figura 4.5: Flujo completo de diseno de Madeo.

de diseno de Madeo para estas aplicaciones tiene un alto coste compu-tacional, mayor que el resto de aplicaciones desarrolladas en otras lıneasde trabajo de Madeo. Esta complejidad ha propiciado la incorporacionde nuevas tecnicas de optimizacion en el flujo, y el uso de un entorno dealtas prestaciones que posibilita reducir el tiempo total de ejecucion.

El entorno que se va a describir se ha utilizado para realizar experi-mentos y evaluar las tecnicas vistas a lo largo de esta tesis. La carga tıpi-ca de este entorno son lotes de experimentos para implementar diferentesaplicaciones utilizando varias tecnicas. La ejecucion de cada experimentotiene tres procesos secuenciales: la sıntesis funcional, la sıntesis logica yla implementacion final.

El flujo de ejecucion propuesto esta compuesto por dos etapas. En laprimera etapa, se ejecuta concurrentemente la sıntesis funcional de unosexperimentos con la sıntesis logica de otros. Cuando ha terminado la sınte-sis funcional de todos los experimentos pertenecientes al lote entonces


empieza la segunda etapa. En la segunda etapa se ejecutan concurrente-mente la sıntesis logica de unos experimentos con la implementacion finalde otros.

El flujo de los diferentes hilos de ejecucion y su sincronismo se repre-senta en el diagrama de actividad 4.6 y se detallara al final de esta seccion.

Ahora se van a analizar los recursos computacionales necesarios parala ejecucion de este diagrama de actividades estudiando las necesidadesde cada uno de los procesos. La sıntesis funcional se realiza en la maqui-na virtual de Smalltalk del entorno de desarrollo y necesita un ordenadorconvencional con gran capacidad de memoria principal. La implementa-cion final utiliza programas de entornos EDA comerciales, concretamenteel sistema de desarrollo de Xilinx (ISE), y sus necesidades son similares ala sıntesis funcional. Estos dos procesos no se ejecutan simultaneamente,por lo cual pueden compartir sin perder rendimiento un equipo que se lellamara a partir de este momento front-end.

La sıntesis logica concreta de este flujo comprende una tarea de ma-peado tecnologico por cada uno de los operadores y una tarea de resıntesisde cada una de las salidas de cada operador. Se tienen que ejecutar muchastareas por cada circuito, debilmente acopladas y cada tarea correspondea un proceso del sintetizador logico. Este es un programa secuencial y notiene varios hilos de ejecucion. La comunicacion entre las diferentes ta-reas o procesos se realizara usando los archivos BLIF que describiran loscircuitos intermedios. Por consiguiente, esta sıntesis logica sigue una filo-sofıa SPMD (Single Program Multiple Data) y se puede enmarcar comouna aplicacion MTC (Many-Task Computing) [126]. MTC son aplicacio-nes de alto coste computacional que comprenden multiples actividades,con pocas necesidades de comunicacion que se satisfacen utilizando pasode mensajes e intercambio de informacion a traves del sistema de archivos.

Una alternativa a esta sıntesis logica basada en el modelo MTC es uti-lizar un sintetizador logico paralelo, como es el caso del PPart [92][91][90].PPar es una aplicacion distribuida de simplificacion mediante el particio-nado la red logica que utiliza el algoritmo HMetis [81]. Esta herramientaesta desarrollada utilizando la biblioteca PVM (Parallel Virtual Machine)de computo paralelo para sistemas distribuidos e integrada en el sinteti-zador logico SIS. Este sintetizador paralelo consigue reducir el tiempo derespuesta a costa de reducir la calidad de los resultados. Se ha preferido


Figura 4.6: Diagrama de actividad del flujo de diseno de Madeo

no utilizar este metodo y su estudio se ha pospuesto para trabajo futuropor dos razones. La primera es la falta de mantenimiento de este softwareque es practicamente nula. No existen actualizaciones que se beneficiende las mejoras considerables de los nuevos sintetizadores logicos sucesoresdel programa SIS (MVSIS,ABC).

La segunda es que la ocupacion de los procesadores es alta cuandose utilizan sintetizadores secuenciales, por el gran numero de tareas con-currentes que estan en ejecucion, y por lo tanto no resulta evidente elbeneficio en la explotacion del paralelismo por el uso de este sintetizadorparalelo.


El sistema elegido para ejecutar la aplicacion MTC descrita es uncluster gestionado con Portable Batch System (PBS). PBS es un sistemade planificacion de tareas que mediante una cola va asignando los procesosa los correspondientes nodos del cluster. El motivo de esta eleccion es ladisponibilidad de estos clusteres en mi entorno academico. No obstante,MOSIX [15] podrıa ser un sistema mas idoneo para ejecutar este tipo deaplicacion. Este sistema permite ejecutar de forma eficiente varios pro-gramas secuenciales en este tipo de cluster. MOSIX puede ser visto comoun sistema operativo multi-cluster que incorpora deteccion automaticade recursos y la distribucion de la carga de trabajo dinamica. Sus opera-ciones son transparentes para las aplicaciones. Los usuarios no necesitansaber donde se estan ejecutando los procesos, tampoco necesitan preocu-parse de lo que estan haciendo otros usuarios. Por lo tanto en general,este sistema simplificarıa el trabajo de gestionar las colas del PBS.

Despues de presentados los recursos computacionales de los que ademasse ha realizado un breve analisis y las tareas a realizar, se va a describirel flujo de procesos para realizar la implementacion completa de los expe-rimentos (ver figura 4.6). La herramienta tiene dos modos para ejecutareste flujo de diseno: el modo interactivo y el modo por lote de experimen-tos.

El modo interactivo permite depurar las aplicaciones de los experi-mentos. Dispone una interfaz grafica, mostrada en la figura 4.7, que per-mite visualizar el grafo de operadores y la red de LUT y navegar porsus estructuras internas. El planteamiento es que primero se depuran lasnuevas aplicaciones en el modo interactivo y luego se lanza un lote deexperimentos para explorar diferentes parametros de funcionamiento envista a obtener el resultado mas eficiente.

El funcionamiento del flujo de diseno expresado en el diagrama de ac-tividades se va a explicar describiendo como se ejecutan y se sincronizanlas tres tareas que comprenden el proceso completo.

Ejecucion y sincronismo de la sıntesis funcional

Inicialmente, se describe la ejecucion del lote de experimentos en unprograma Smalltalk donde se detallan todos los parametros de configura-


cion de cada uno de los experimentos: la aplicacion a sintetizar, el tamanode la LUT, las tecnicas de simplificacion a utilizar, los tipos de datos delos valores iniciales, etc..

Para cada experimento se crea un directorio donde se almacenara to-da la informacion obtenida en el flujo de diseno. Ası, esta estructura dedirectorios constituira la base de datos de los experimentos.

El flujo de trabajo empieza con la sıntesis funcional que obtiene la redde LUT. Despues obtenida se crea un nuevo hilo de ejecucion concurrentepara realizar la sıntesis funcional de otros experimentos. De esta formase solapa la ejecucion de la sıntesis logica de unos experimentos con lasıntesis funcional de otros.

Ejecucion y sincronismos de la sıntesis logica

En el front-end, se generaran los scripts para la sıntesis logica. Hay dostipos: uno para gestionar la cola PBS de trabajos y otro para invocar laejecucion de los simplificadores. El primer tipo permite particularizar laejecucion de los trabajos segun las caracterısticas del cluster, por ejemploel directorio de trabajo, el numero de procesadores por nodo y el nombrede cola PBS donde se enviaran los trabajos. La sıntesis logica consiste enuna secuencia de tareas, como se describio en la seccion 4.2, y el orden deejecucion se establece con este tipo de scripts. Concretamente, la tarea demapeado se debe ejecutar despues de finalizar todas las resıntesis de cadauna de las salidas del operador. Este sincronismo se realiza indicando alsistema de colas que un trabajo no se ejecute hasta que haya terminadouna lista concreta de trabajos encolados.

El segundo tipo de scripts invocaran los simplificadores con los datoscorrespondientes dentro de la estructura de directorio definida. Se realizapreviamente una copia de los archivos involucrados en el disco local delnodo donde se ejecuta el trabajo. Esto se hace para reducir la congestiondel sistema de archivos compartido por todos los nodos del clusteres. Enla practica, esta copia elimina bloqueos permanentes y momentaneos queprovocaba esta congestion.


Los scripts y los datos a procesar se copian en el cluster donde serealiza la sıntesis logica, y el front-end invocara su ejecucion remota deestos scripts en el cluster. Esta comunicacion del front-end con el clusterse realiza con los programas scp y ssh que utilizan un protocolo seguro decomunicaciones. Estos programas estan instalados en todos los clusteresutilizados siendo el unico protocolo de acceso permitido. Ademas, per-mite autenticarse de forma segura y automatica sin introducir claves deseguridad utilizando certificados RSA.

Figura 4.7: Interfaz grafica de Madeo

Para evitar posibles problemas de carrera en el encolamiento de tra-bajos simultaneamente y evitar la perdida rendimiento por congestion, lacomunicacion se realiza en exclusion mutua. De esta forma solo se trans-fiere un experimento en un momento dado. Entonces, en el caso de quefinalice la sıntesis funcional de un experimento y el experimento anteriorno haya terminado la transferencia, el primero se bloqueara hasta que latransferencia finalice.


Ejecucion y sincronismos de la implementacion final

Volviendo a la lınea principal del diagrama de actividad, cuando setermina la emision de nuevos experimentos se pasa a la fase de recepcion,donde se ejecuta de forma concurrente la implementacion final de algunosexperimentos y la sıntesis logica de otros. La recepcion consiste en quecada cierto periodo de tiempo se examina que operadores han finalizadosu sıntesis logica durante este periodo y se transfieren los resultados. Des-pues de la transferencia, se examina que experimentos han terminado lasıntesis logica de todos sus operadores y se realizara su implementacionfinal. Para finalizar, se obtienen los resultados, analizando los informescorrespondientes a la implementacion final y a la sıntesis logica y funcio-nal.

4.5. Conclusiones

En este capıtulo, se describen las ultimas fases del flujo de diseno parala obtencion del circuito final. Estas fases constan de algunas tecnicas desıntesis de alto nivel, de la sıntesis logica y de la implementacion final.

Las tecnicas de sıntesis de alto nivel utilizadas en esta fase tienen elobjetivo de simplificar el grafo de operadores. Se basan en la deteccionde constantes, de esta forma se pueden eliminar subgrafos cuya salida esuna constante y suprimir las entradas constantes de los operadores. Otratecnica propuesta ha sido la fusion de operadores que no siempre es efi-caz y se han detectado experimentalmente situaciones donde no se debeaplicar esta tecnica.

La sıntesis logica propuesta esta basada en la generacion de funcionesincompletas a partir de las LUT generadas por la inferencia de tipos. Seha utilizado un software especıfico que utiliza un motor de satisfacibili-dad booleana para simplificar las funciones incompletas. Se han detectadocasos en los que no se han obtenido los resultados esperados y se ha pro-puesto un sistema de reduccion de variables booleanas para mejorarlos.

La implementacion final propuesta en esta tesis ha aportado la posi-bilidad desde Madeo de poder utilizar otras herramientas para generar elcircuito final y poder simularlo para la verificacion y estimacion de pres-taciones.

4.5 Conclusiones 153

El objetivo principal de esta tesis ha sido la sıntesis eficiente de aplica-ciones de tratamiento de la senal utilizando Madeo. La ejecucion del flujode diseno de Madeo para estas aplicaciones tiene un alto coste compu-tacional, mayor que el resto de aplicaciones desarrolladas en otras lıneasde trabajo de Madeo. Esta complejidad ha propiciado la incorporacionde nuevas tecnicas de optimizacion en el flujo, y el uso de un entorno dealtas prestaciones que posibilita reducir el tiempo total de ejecucion.

CAPITULO 5Resultados

Los experimentos realizados han perseguido evaluar la calidad de lasprestaciones de los circuitos generados por el sintetizador propuesto enesta tesis contrastandola con otros sintetizadores y evaluando cada unade las tecnicas propuestas.

La organizacion de este capıtulo esta compuesta por cinco secciones.En la primera seccion se describen los algoritmos pertenecientes al bancode pruebas utilizado, ası como la informacion concerniente a la implemen-tacion. En la segunda seccion se analizan todas las tecnicas propuestasexceptuando la inferencia de tipos hacia atras: la resıntesis logica, la utili-zacion de biblioteca y la reduccion de variables binarias de los operadores.En la tercera se estudia el efecto de la inferencia hacia atras analizandoel area, el tiempo de respuesta y el consumo dinamico de potencia. Enla cuarta se estudia el tiempo de procesado consumido para cada una delas etapas de la sıntesis funcional. Con ello se valorara el correspondien-te esfuerzo computacional que conlleva cada una de estas etapas. En laultima seccion se estudia la aportacion del sintetizador propuesto en eldesarrollo de una aplicacion practica desarrollada.

155

156 Capıtulo 5 Resultados

5.1. Caracterısticas del banco de pruebas

A continuacion, se van a presentar todos los algoritmos que consti-tuyen el banco de prueba. En proximas secciones se justificara el uso decada algoritmo. Los algoritmos utilizados son los siguientes:

S+P: La transformada wavelet de enteros de Said and Pearlman [130]utilizada en el algoritmo de compresion de senales, imagenes y vıdeoSPIHT. Seguidamente, mostramos esta transformacion en el esque-ma lifting, donde x es el vector de entrada entero, y d y s son losvectores de salida pasa alta y pasa baja, respectivamente.

d(1)[n] = x[2n+ 1]− x[2n]

s[n] = x[2n] + ⌊d(1)[n]2 ⌋d[n] = d(1)[n] + ⌊28(s[n− 1]− s[n])+38(s[n]− s[n+ 1]) + 2

8d(1)[n+ 1] + 1

2⌋

Prewitt: Un detector de bordes de imagenes que utiliza dos mascarasde convolucion de Prewitt (3x3) [30][35].

δy =

−1 −1 −10 0 01 1 1

,

δx =

−1 0 1−1 0 1−1 0 1

El modulo gradiente se calcula como sigue: |g |=√

δx2 + δy

2.

PrewittBin: Un detector de bordes Prewitt seguido de un binarizacionde la imagen [35] [71].

PrewittSimp: Deteccion de bordes simplificada [35], donde el caculodel modulo gradiente se ha remplazado por la suma de los valoresabsolutos de sus componentes (|g |=| δx | + | δx |).

GradienteDir: Direccion del gradiente [30] usando la mascara Prewittde convolucion δy and δx. La direccion se calcula como sigue: |g |=

5.1 Caracterısticas del banco de pruebas 157

arctan(δyδx) y luego es redondeada a uno de los cuatro angulos que

representan las direcciones vertical, horizontal, y la dos diagonales( concretamente a los angulos 0, 45, 90 y 135 grados).

Gaussiano: Un ejemplo de filtro Gaussian [35] de tamano 3x3,

G =1

16

1 2 12 4 21 2 1

.

Sharpness: Un ejemplo de filtro Sharpness [35] de tamano 3x3,

S =

−3 −3 −3−3 24 −3−3 −3 −3

.

Una caracterıstica de todos estos algoritmos es que trabajan con en-teros. Ası, en las figuras los resultados se muestran para varios tamanosde enteros, que pueden variar de 3 a 8 bits, para poder valorar su escala-bilidad.

Otra caracterıstica es la organizacion que va a tener el circuito final.Se van a utilizar tres organizaciones correspondientes a los constructoresdescritos en la seccion 2.2.2:

Monociclo: Correspondiente al circuito paralelo asociado al constructorexpand:. El circuito resultante en este caso es combinacional.

Multiciclo: Correspondiente al circuito secuencial asociado al construc-tor do:. El circuito generado, como se describio, necesita varios ciclosde reloj para ejecutarse.

Segmentado: Correspondiente al circuito secuencial asociado al cons-tructor latency:pipeline. Es el resultado de segmentar el circuito dela version Monocilo para incrementar la productividad del mismo.

Aunque el constructor expand: genera un circuito combinacional, se hanincluido registros a las entradas y salidas primarias. Los tiempos que pro-porciona la herramienta de sıntesis de los fabricantes para un circuitocombinacional incluye los tiempos desde el bloque de entrada/salida de


la FPGA a las entradas y las salidas primarias del circuito. Al poner losregistros, no se computan estos tiempos en el tiempo de ciclo, y por lotanto es mas facil y coherente la comparacion con las otras organizacionessecuenciales.

Otra de las caracterısticas de los experimentos realizados es la arqui-tectura reconfigurable utilizada. En la aplicacion de la ultima seccion, seha utilizado una plataforma con una FPGA de la companıa Xilinx, con-cretamente una Virtex 4 (XC4VLX160FF1148-10). Se ha decidido utilizaresta FPGA para todos los resultados. La medida de area siempre se re-fiere a Slices, que corresponde en esta FPGA a dos LUT de 4 entradas(una funcion logica de cuatro entradas).

5.2. Estudio de las tecnicas basicas

En esta seccion, se van a realizar experimentos para evaluar todas lastecnicas estudiadas salvo la inferencia de tipos hacia atras. Se ha bus-cado una aplicacion donde la inferencia de tipos pueda tener un efectomoderado. En el caso elegido hay muchas operaciones con potencias exac-tas de dos por lo tanto es previsible su optimizacion. Concretamente, laaplicacion es la transformada wavelet de enteros “S+P”.

5.2.1. Estudio de la resıntesis

La primera tecnica que se va a estudiar es la resıntesis, o generacion defunciones incompletas. En la seccion 4.2, se estudio un caso sencillo y sedescribio el funcionamiento basico de esta tecnica. La inferencia de tiposmas utilizada en el ambito de las aplicaciones DSP es la optimizacion dela longitud de palabra (ver secciones 3.2 y 3.8). La diferencia fundamentales que en el sistema propuesto se infiriere un conjunto de valores posibles.

Se ha incluido la optimizacion de longitud de palabra como una op-cion en Madeo. El funcionamiento de esta opcion consiste en tomar lainformacion obtenida en la inferencia de tipos y calcular la longitud mıni-ma de palabra (n) de cada variable. Se modifica el conjunto de valoresinferidos por el conjunto de valores que se puede representar en binariocon la longitud calculada (2n) y despues se generara la funcion completaasociada a cada operador.

5.2 Estudio de las t ecnicas b asicas 159

200

400

600

800

1000

1200

1400

1600

1800

2000

2200

4 5 6 7 4 5 6 7

Slic

es

Bits

Multiciclo-InfLongPalabraMulticiclo-InfValores

Monociclo-InfLongPalabraMonociclo-InfValores

(a) Con Fusion

150

200

250

300

350

400

450

500

550

600

650

4 5 6 7 4 5 6 7

Slic

es

Bits



(b) Sin Fusion

S+P monociclo y multiciclo con fusion de operadoresMulticiclo Monociclo

InfLongPalabra InfValores InfLongPalabra InfValores7 1224 612(-50%) 2152 1033(-52%)6 972 445(-54%) 1684 728(-57%)5 698 364(-48%) 1165 393(-66%)4 476 225(-53%) 759 309(-59%)

S+P monociclo y multiciclo sin fusion de operadoresMulticiclo Monociclo

InfLongPalabra InfValores InfLongPalabra InfValores7 439 371(-15%) 637 611(-4%)6 385 285(-26%) 539 470(-13%)5 309 225(-27%) 449 342(-24%)4 235 164(-30%) 336 245(-27%)

Figura 5.1: Comparacion del area (Slices) entre la inferencia detipo de Madeo y la optimizacion de longitud de palabra.


18

20

22

24

26

28

30

32

34

36

4 5 6 7 4 5 6 7

ns

Bits



(a) Con fusion

24

26

28

30

32

34

36

38

4 5 6 7 4 5 6 7

ns

Bits



(b) Sin fusion

S+P monociclo y multiciclo con fusion de operadoresMulticiclo Monociclo

InfLongPalabra InfValores InfLongPalabra InfValores7 31.31 29.25(-7%) 36.43 29.67(-19%)6 29.39 28.87(-2%) 34.43 27.17(-21%)5 28.14 25.13(-11%) 33.14 19.71(-41%)4 23.96 22.48(-6%) 29.04 22.38(-23%)

S+P monociclo y multiciclo sin fusion de operadoresMulticiclo Monociclo

InfLongPalabra InfValores InfLongPalabra InfValores7 32.07 32.7(2%) 37.15 32.54(-12%)6 32.45 31.62(-3%) 37.48 30.89(-18%)5 29.63 27.97(-6%) 34.65 27.68(-20%)4 27.63 25.15(-9%) 32.59 26.28(-19%)

Figura 5.2: Comparacion de tiempos (ns) entre la inferencia detipos de Madeo y la optimizacion de longitud de palabra.


En las figuras 5.1 y 5.2, el nombre de InfValores se refiere a la tecnicade inferencia de tipos de Madeo y el nombre InfLongPalabra se refiere ala tecnica de optimizacion de la longitud palabra.

La tecnica de fusion de operadores descrita en la seccion 4.1.1 tam-bien se va a tener en cuenta. En las figuras 5.1 y 5.2, se puede observarclaramente que en todos los casos el sistema de inferencia de tipos pro-puesto en esta tesis obtiene beneficios. La fusion de operadores en estecaso no obtiene ninguna mejora en los resultados. Esta tecnica dependemucho del algoritmo y no son suficientes las reglas heurısticas descritasen la seccion 4.1.1. Los resultados de estas figuras se han obtenido paraenteros desde 4 a 7 bits. Con enteros de 8 bits en la opcion de optimiza-cion de la longitud de palabra, el sistema aborta por exceso de tamanode las LUT. Aplicando la inferencia de tipos propuesta en esta tesis si seobtiene resultados validos con 8 bits.

5.2.2. Estudio del uso de bibliotecas

En este apartado se muestran los resultados obtenidos por la trans-formada wavelet descrita en la seccion anterior. Esta aplicacion se hasintetizado de tres formas diferentes:

BibBajoNivel Todos los sumadores se sintetizan invocando la bibliotecade componentes de VHDL. En este caso el sintetizador funcionalrealiza todos los pasos, excepto la transformacion del operador a laLUT que calcula la longitud de palabra del sumador a partir delconjunto de valores inferidos.

SoloLut No se utiliza ninguna biblioteca.

BibAltoNivel Utiliza la descripcion jerarquica del sumador descrita enla seccion 2.2.3 que define el sumador en Smalltalk como un com-ponente de la biblioteca del sintetizador de Madeo.

En la figura 5.3 se muestran los resultados de area de las tres opcio-nes. Estos resultados se han obtenido sin aplicar la tecnica de fusion deoperadores. La organizacion elegida es la monociclo.

Los sumadores con propagacion de acarreo son utilizados normalmen-te en bibliotecas de componentes, y son unos circuitos muy simples con


0

100

200

300

400

500

600

700

800

900

2 3 4 5 6 7 8 9

Are

a(sl

ices

)

Bits

BibBajoNivelSoloLut

BibAltoNivel

BibBajoNivel SoloLut BibAltoNivel8 228 832 6067 210 611 2236 179 470 2125 153 342 1554 126 245 137

Figura 5.3: Area (Slices) de las tres opciones en el uso de bi-bliotecas.

una area muy reducida. En cambio, el sistema de Madeo describe los su-madores con una LUT de muchas variables, y por lo tanto de muchasasociaciones, resultando un circuito muy complejo para el simplificadorlogico que no alcanza las prestaciones de los sumadores con propagacionde acarreo. Esto se constata en los resultados de la figura 5.3, con unareduccion de dos tercios cuando se utiliza las opciones basadas en biblio-tecas, exceptuando la basada en bibliotecas de alto nivel para 8 bits enla que cambia la tendencia y solo reduce un 27%.

La biblioteca de alto nivel se descarto por su alto tiempo de sıntesisfuncional y ademas por un problema de estabilidad como muestra la fi-gura 5.3. Por este motivo, se han utilizado las bibliotecas de bajo nivelen el resto de secciones. No obstante, los experimentos con bibliotecas dealto nivel no han utilizado la tecnica de reduccion de variables binarias.Realizando un analisis de estos experimentos, se ha visto que el operador“A/8” es el que consume mas area y esto se podrıa resolver con la reduc-cion de variables. De esta forma, el empleo de las bibliotecas de alto nivel


es muy interesante y se propone como trabajo futuro.

En los resultados del area se ha decido no incluir la organizacion seg-mentada porque no aporta ninguna informacion relevante, pero en el casode la respuesta temporal es diferente y por ese motivo se van a mostrarexperimentos con segmentacion. Se busca que tenga la mayor frecuenciade reloj, y el resultado es una latencia de 9 ciclos. La forma de generarel circuito segmentado no esta disponible para la biblioteca de bajo ni-vel, y por tanto solo se mostrara para el caso de la biblioteca de alto nivel.

En todo los casos, la respuesta temporal es mucho mejor, resultandouna reduccion entre el 31% y el 54%, como muestra la figura 5.4.

0

5

10

15

20

25

30

35

3 4 5 6 7 8 3 4 5 6 7 8

Tie

mpo

(ns)

Bits

Monociclo-SoloLutMonociclo-BibBajoNivel

Segmentado-SoloLutSegmentado-BibAltoNivel

Monociclo SegmentadoSoloLut BibBajoNivel SoloLut BibAltoNivel

8 34.01 20.72(-39%) 7.48 5.01(-33%)7 32.54 19.03(-42%) 6.3 4.28(-32%)6 30.89 18.55(-40%) 5.74 3.54(-38%)5 27.68 18.22(-34%) 5.9 2.81(-52%)4 26.28 18.11(-31%) 4.62 2.25(-51%)

Figura 5.4: Tiempo de propagacion (ns) de las opciones SoloLuty BibAltoNivel en el uso de bibliotecas.


Prewitt Prewitt+BinarizacionMuller Simplif Muller Simplif

Error 0,294 19.338 0 0.068

Desviacion tıpica 0,45 21,055 0 0.25

Tabla 5.1: Error y desviacion tıpica de variante Muller y Simplif.

5.3. Estudio de la inferencia de tipos de hacia atras

En esta seccion, se va a estudiar como afecta la tecnica de la inferenciahacia atras a las prestaciones del circuito final. Se han buscado aplica-ciones favorables a la tecnica, con operadores complejos (cuadrados, raızcuadrada, ....) y que se puedan reducir sus dominios. Concretamente, sehan utilizado los algoritmos ”Prewitt” y ”PrewittBin” con tres variantes:

Original La version original de las aplicaciones ”Prewitt” y ”Prewitt-Bin”.

Muller Aplicando la descomposicion multipartita descrita en la seccion2.2.3 a la raız cuadrada de las versiones originales ”Prewitt” y ”Pre-wittBin”.

Simplif Remplazando el calculo del modulo gradiente de las versionesoriginales por la suma de los valores absolutos de sus componentes(|g |=| δx | + | δx |).

Estas tres variantes proporcionan una precision diferente de los resul-tados. Para poder valorar esta diferencia se ha realizado una simulacionpara calcular el error medio en valor absoluto de las versiones de Muller ySimplif respecto a la version original. Estos datos se muestran en la tabla5.1.

A partir de ahora, si en las tablas aparece la abreviatura (“Desb”)indica que el sintetizador logico no ha proporcionado una solucion validaa causa de que alguna LUT es muy grande y la ejecucion del simplifi-cador logico se ha abortado al desbordarse la capacidad de memoria dela maquina. Los experimentos se han realizado con la opcion de fusionde operadores y utilizando la biblioteca de bajo nivel. Estas opciones engeneral son las que obtienen mejores resultados. Los experimentos de estaseccion comparan los resultados aplicando la inferencia de tipos semicom-pleta (Semi), que consiste en solo utilizar la inferencia hacia delante, y

5.3 Estudio de la inferencia de tipos de hacia atr as 165

aplicando la inferencia de tipos completa (Completa), que consiste en uti-lizar adicionalmente la inferencia hacia atras.

La figura 5.5 muestra el area y el tiempo de propagacion para el filtro”Prewitt”. Para la variante Original, la inferencia hacia atras proporcionauna mejora muy reducida de area y tiempo, aunque el punto mas desfa-vorable es que los resultados son desproporcionados en comparacion a lasotras dos versiones. Incluso para el caso de 8 bits no se proporciona uncircuito correcto.

Para la variante Muller, la inferencia semicompleta obtiene mejoresresultados de area que la variante Original y sorprendentemente la res-puesta temporal es similar. En cambio, la inferencia hacia atras en la raızcuadrada para esta variante tiene resultados muy malos. El proceso deinferencia hacia atras, en el caso de utilizar la biblioteca de bajo nivel,inserta una LUT correspondiente a la funcion de adaptacion a la salidade los sumadores (ver seccion 3.7.7). El operador predecesor de la raızcuadrada es un sumador, por lo tanto se inserta una LUT. Esta nuevaLUT es la que provoca esta gran diferencia en la variante Muller. En elresto de versiones, el proceso de fusion de operadores la suprime, anulan-do el efecto de la inferencia hacia atras en la raız cuadrada. En el casode la variante Muller no se puede realizar esta fusion, ya que la raız cua-drada se descompone en un circuito de dos tablas con su correspondientebifurcacion (ver seccion 2.2.3). No obstante, el sintetizador se puede mo-dificar para que, en estas circunstancias especıficas se suprima la funcionde adaptacion y de esta forma la inferencia hacia atras obtenga una me-jorıa identica al caso de la variante Original. Ya que los beneficios de lainferencia hacia atras de la version Original no estan en la raız cuadra-da, y la unica diferencia entre las dos versiones es la implementacion raızcuadrada, los beneficios seran iguales en ambas versiones si se suprimenlos efectos de la inferencia hacia atras en la raız cuadrada.

La variante Simplif obtiene mejores prestaciones a costa de resultadosmas imprecisos. La inferencia hacia atras genera un incremento en areay tiempo. Este incremento es debido a la funcion “valor absoluto” queesta entre sumadores. Esta funcion es facil de simplificar, pero en la infe-rencia hacia atras se fusiona con las funciones de adaptacion, resultandouna funcion mas compleja.


100

1000

10000

100000

5 6 7 5 6 7 8 5 6 7 8

Slic

es

Bits

Original-SemiOriginal-Completa

Muller-SemiMuller-Completa

Simplif-SemiSimplif-Completa

(a) Area

10

100

5 6 7 5 6 7 8 5 6 7 8

Tie

mpo

(ns)

Bits




(b) Tiempo

Comparacion de area (Slices) del algoritmo PrewittOriginal Muller Simplif

Semi Completa Semi Completa Semi Completa8 Desb Desb 4614 Desb 177 201(14%)7 30131 29765(-1%) 2386 34465(1344 %) 154 168(9%)6 7919 7733(-2%) 1134 15012(1224 %) 130 138(6%)5 1870 1768(-5%) 589 3811(547%) 117 123(5%)

Comparacion de tiempos (ns) del algoritmo PrewittOriginal Muller Simplif

Semi Completa Semi Completa Semi Completa8 Desb Desb 34.0 Desb 11.95 12.59(5%)7 31.45 30.3(-4%) 30.64 50.57(65%) 11.67 11.95(2%)6 28.61 27.62(-3%) 28.57 42.7(49%) 11.6 11.71(1%)5 24.34 23.37(-4%) 24.24 37.28(54%) 10.67 10.96(3%)

Figura 5.5: Comparacion de prestaciones del algoritmo “Pre-witt” entre inferencia semicompleta y completa.


La figura 5.6 muestra el area y el tiempo de propagacion para la apli-cacion ”PrewittBin”. Para la version Original ha obtenido una mejoraconsiderable con la inferencia hacia atras, unas seis o sietes veces mejorque la version de Muller. En cuanto a la version Muller, en el caso deinferencia semicompleta se han obtenido resultados similares al caso del“Prewitt”. En cuanto a la inferencia completa se mantiene el mismo pro-blema que en el caso anterior.

En el caso Simplif, los resultado son similares y la inferencia haciaatras mejora levemente las prestaciones.

Para el resto de algoritmos (Gaussiano, Sharpness, GradienteDir) conutilizacion de biblioteca de bajo nivel y fusion de operadores los resultadosson identicos cuando se utiliza la inferencia semicompleta y completa.

En la figura se muestran los resultados de area utilizando inferenciade tipos completa (Completa) y sin propagacion hacia atras (Semi). Estosexperimentos se han hecho utilizando fusion de operadores, y sin utilizarninguna biblioteca ni reduccion de variables binarias.

Como se puede observar, para los algoritmos “S+P” y “Gaussiano”no se obtienen beneficios al aplicar la propagacion de datos hacia atras.Estas funciones son biyectivas y no tiene una reduccion significativa enel numero de clases de equivalencia. Sin embargo, hay importantes re-ducciones de area, en algunos casos de un orden de magnitud, para losalgoritmos “Prewitt”, “PrewittSimp” y ”Sharpness” cuando aplicamos lainferencia de tipos completa. En los algoritmos “Prewitt” , “PrewittSimp”y “Sharpness”, la salida esta afectada por una funcion de saturacion, quees una funcion sobreyectiva y permite una reduccion del numero de clasesde equivalencia.

El caso de “Sharpness” cambia de forma significativa por la utilizacionde bibliotecas de bajo nivel, ya que la inferencia hacia atras solo afecta alos operadores que multiplican por una constante.

5.3.1. Consumo dinamico de potencia

La inferencia hacia atras trata de reducir el dominio de las funciones.Por ello, si hay menos combinaciones en las entradas de las funciones lasposibilidades de cambios a las salidas de estas son menores, como conse-


100

1000

10000

100000

5 6 7 5 6 7 8 5 6 7 8

Slic

es

Bits




(a) Area

10

100

5 6 7 5 6 7 8 5 6 7 8

Tie

mpo

(ns)

Bits




(b) Tiempo

Comparacion de area (Slices) del algoritmo Prewitt y BinarizacionOriginal Muller Simplif

Semi Completa Semi Completa Semi Completa8 Desb 630(- %) 4585 Desb 174 174(0%)7 750 327(-56%) 2339 14155(505%) 151 149(-1%)6 419 192(-54%) 1066 4223(296%) 128 122(-5%)

Comparacion de tiempos (ns) del algoritmo Prewitt y BinarizacionOriginal Muller Simplif

Semi Completa Semi Completa Semi Completa8 Desb 15.16 (-%) 32.0 Desb 11.86 11.82(0%)7 14.55 13.67(-6%) 27.9 39.25(41%) 11.62 11.63(0%)6 14.1 12.53(-11%) 26.44 35.88(36%) 11.57 10.93(-6%)

Figura 5.6: Comparacion de prestaciones del algoritmo “Pre-wittBin” entre inferencia semicompleta y completa.


Gaussiano S+P PrewittSemi Completa Semi Completa Semi Completa

7 1173 1171 3329 3330 35820 4984(-86%)6 129 126 461 465 16103 832(-95%)5 101 99 272 272 4250 719(-83%)4 63 55 139 139 550 190(-65%)

PrewittSimp SharpnessSemi Completa Semi Completa

7 5279 2244(-57%) 49472 7750(-84%)6 3361 480(-86%) 18666 5217(-72%)5 1549 293(-81%) 2511 2960(18%)4 202 149(-26%) 488 611(25%)

Figura 5.7: Resultados de area (Slices) sin utilizar ninguna bi-blioteca de componentes.

cuencia la actividad de conmutacion de los circuitos generados es menory el consumo dinamico se reduce (Consumo dinamico = carga capacitivax voltaje2 x actividad de conmutacion).

Para evaluar la actividad de conmutacion de los circuitos generadosse ha utilizado el simulador de grafos de operadores descrito en la seccion2.3. A este simulador se le ha anadido la contabilidad de los cambios detodas las variables binarias del grafo de operadores. Las simulaciones sehan realizado con un banco de prueba de mil valores aleatorios con unadistribucion uniforme y el resultado es el numero total de cambios delas salidas de todos los operadores. Los resultados de estas simulacionesse muestran en la figura 5.9. Los grafos de operadores simulados se hanobtenidos con fusion de operadores y sin utilizar ninguna biblioteca. Lareduccion de la actividad de conmutacion al aplicar esta tecnica esta entreel 10% y el 20%.

Para calcular el consumo dinamico de potencia, se ha utilizado lasıntesis de los circuitos mostrados en la tabla 5.7 de la seccion anterior.

La estimacion del consumo se realiza por simulacion y utilizando he-rramientas Xpower del fabricante de la FPGA (como se describio condetalle en la seccion 2.3). En la tabla 5.8 se muestran los resultados ex-perimentales de la estimacion en el consumo de potencia dinamico (enmW) Estos experimentos comparan los resultados aplicando la inferenciade tipos semicompleta (Semi), que consiste en solo utilizar la inferenciahacia delante, y aplicando la inferencia de tipos completa (Completa), que


Gaussiano S+P PrewittSemi Completa Semi Completa Semi Completa

7 2333 2320 3948 3948 214419 696(-97%)6 1596 1588 2420 2446 126163 2134(-98%)5 1472 1468 2035 2016 5644 1996(-65%)4 1358 1348 1620 1628 1569 1418 (-10%)

PrewittSimp SharpnessSemi Completa Semi Completa

7 8124 2538(-69%) 15027 3724 (-75%)6 4164 1621(-61%) 5322 2531(-53%)5 3001 1479(-51%) 1703 1556(-9 %)4 1451 1360(-6%) 1383 1353(-3 %)

Figura 5.8: Resultados de consumo dinamico de potencia (mW).

consiste en utilizar adicionalmente la inferencia hacia atras. La inferen-cia hacia atras no tiene beneficios en el consumo de potencia dinamicospara los algoritmos “S+P” y “Gaussiano”. Sin embargo para el resto dealgoritmos, hay grandes reducciones de consumo de potencia dinamico,alcanzado el 98% en el caso de ”Prewitt”.

5.3.2. Comparacion con implementaciones de VHDL

Para tener una referencia sobre la calidad de los resultados obtenidascon Madeo, se ha realizado una comparacion con otro lenguaje de des-cripcion de hardware. Para ello, se ha elegido VHDL, un lenguaje muyeficiente y con expresividad de bajo nivel como se comento en el capıtulo1. El estilo de descripcion VHDL esta basado en expresiones RTL y tie-ne como objetivo obtener el circuito mas eficiente posible. Los algoritmosutilizados en esta comparacion utilizan la raız cuadrada y el arcotangente.Estas operaciones se implementan utilizando componentes presintetizadospertenecientes a la biblioteca del entorno de desarrollo. Los componentesconcretos utilizados para estas operaciones estan basados en el algoritmode Cordic.El algoritmo de ”Prewitt” es la version Muller, pues tiene mejores presta-ciones que la version original. Estos resultados se muestran en la figuras5.10 y se aprecia que Madeo obtiene un tiempo respuesta mejor a costade una area mayor. En resumen, se consigue un relacion de tiempo derespuesta y area satisfactorio para el sintetizador de Madeo. Solo hay queresaltar la excepcion del “Prewitt” que tiene una area muy grande, diezveces mayor que la implementacion en VHDL.


10000

100000

4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7

Act

ivid

ad d

e co

nmut

acio

n

Bits

S+P-SemiS+P-Completa

Prewitt-SemiPrewitt-Completa

PrewittBin-SemiPrewittBin-Completa

PrewittSimp-SemiPrewittSimp-Completa

Sharpeness-SemiSharpeness-Completa

Gaussiano-SemiGaussiano-Completa

S+P Prewitt PrewittBinSemi Completa Semi Completa Semi Completa

7 46700 46626(0%) 75204 67840(-10%) 64234 56213(-12%)6 39912 39402(-1%) 64076 58532(-9%) 64508 56006(-13%)5 33108 32606(-2%) 53148 47334(-11%) 53236 45896(-14%)4 24666 24122(-2%) 42434 37574(-11%) 42446 36370(-14%)

PrewittSimp Sharpness GaussianoSemi Completa Semi Completa Semi Completa

7 74648 66940(-10%) 76552 62358(-19%) 32630 32630(0%)6 63622 57262(-10%) 68502 56862(-17%) 28364 28364(0%)5 52702 47420(-10%) 60368 49028(-19%) 23754 23754(0%)4 41870 36752(-12%) 52698 41506(-21%) 18538 18132(-2 %)

Figura 5.9: Resultados de la simulacion de la actividad de con-mutacion.


10

100

7 8 7 8 7 8

ns

Bits

PrewittBin-MadeoPrewittBin-Vhdl

Prewitt-MadeoPrewitt-Vhdl

GradienteDir-MadeoGradienteDir-VHDL

(a) Tiempo

100

1000

10000

7 8 7 8 7 8

Slic

es

Bits

PrewittBin-MadeoPrewittBin-Vhdl

Prewitt-MadeoPrewitt-Vhdl

GradienteDir-MadeoGradienteDir-VHDL

(b) Area

Tiempos (ns)PrewittBin Prewitt GradienteDir

Madeo VHDL Madeo VHDL Madeo VHDL8 15.16 52.22(244%) 34.0 52.51(54%) 12.27 26.28(114%)7 13.67 48.7(256%) 30.64 48.96(60%) 12.26 27.75(126%)

Area (Slices)PrewittBin Prewitt GradienteDir

Madeo VHDL Madeo VHDL Madeo VHDL8 630 308(-51%) 4614 312(-93%) 279 180(-35%)7 327 263(-20%) 2386 266(-89%) 225 168(-25%)

Figura 5.10: Comparacion de prestaciones entre las implemen-taciones de VHDL y de Madeo.


10

100

1000

10000

100000

6 7 8 6 7 8 6 7 8 6 7 8 6 7 8

Slic

es

Bits

S+P-SinS+P-Con

Sharpness-SinSharpness-Con

Gaussiano-SinGaussiano-Con

GradienteDir-SinGradienteDir-Con

PrewittBin-SinPrewittBin-Con

S+P Sharpness Gaussiano GradienteDir PrewittBinSin Con Sin Con Sin Con Sin Con Sin Con

8 215 193(-10%) 380 380(0%) 134 134(0%) 279 279(0%) Desb 630(–%)7 187 174(-7%) 281 281(0%) 114 114(0%) 225 225(0%) 12657 327(-97%)6 146 143(-2%) 218 218(0%) 97 97(0%) 200 200(0%) 3614 192(-95%)

Figura 5.11: Comparacion de area (Slices) sin reduccion de va-riables binarias y con reduccion de variables binarias.

5.3.3. Estudio de la reduccion de variables binarias

En la seccion 4.2 se estudio la resıntesis logica correspondiente a unadivision entera de un numero de 10 bits entre una potencia exacta de dos,y la conclusion fue incluir un proceso que reduzca el numero de variablesbinarias suprimiendo aquellas que no influyen en el comportamiento dela funcion. Esta division se corresponde con operadores, que transfierenun conjunto de entradas binarias a las salidas, muy utilizado en las des-cripciones jerarquicas descritas en la seccion 2.2.3. Las pruebas realizadaspara estos casos obtuvieron que esta reduccion mejorara mucho los resul-tados.

En la figura 5.11 muestra la comparacion de aplicar la reduccion devariables binarias (Con) y sin aplicarla (Sin). Los algoritmos “Gaussiano”,”GradienteDir” y “Sharpness” no obtienen ninguna mejora de area por-que no tienen la posibilidad de reducir variables logicas. El algoritmo“S+P” tiene una moderada mejora al tener multiplicaciones y divisiones


con potencias exactas de dos. El “PrewittBin“ es el que obtiene mejoresresultados porque los dominios de las funciones se han reducido muchogracias al proceso de inferencia hacia atras y se han suprimido variablesbinarias. Hay que tener tambien en cuenta que el algoritmo de reduccionde variables binarias obtiene mejores resultados cuando mas variablestienen la funcion, que es el caso de este algoritmo.

5.4. Tiempo de ejecucion de la sıntesis funcional

En esta seccion se presentan los tiempos de ejecucion necesarios pa-ra llevar a cabo las diferentes fases de la sıntesis funcional. Con ello sepretende establecer el esfuerzo de cada etapa del sintetizador (relacionentre las prestaciones del circuito y el tiempo de procesador) y detectarel cuello de botella para tenerlo en cuenta en futuras mejoras.

La sıntesis funcional se divide en tres etapas: inferencia de tipos haciadelante, inferencia de tipos hacia atras y transformacion de operadores enLUT. En la figura 5.12 se muestra el porcentaje del tiempo de procesadorconsumido por cada una de las etapas para diferentes algoritmos. Lasabreviaturas de las etapas son las siguientes: Inferencia para inferenciade tipos hacia delante, Inf-Atras para inferencia de tipos hacia atras yLUT para la transformacion de operadores en LUT. La transformacionde operadores en LUT es la etapa que consume mas tiempo de CPU. Elproceso dentro de esta tarea que consume mas tiempo es la reduccion devariables binarias de entrada.

A continuacion se va a evaluar el tiempo de procesador invertido enla tecnica de la inferencia de tipos hacia atras. Este porcentaje de tiempode la sıntesis funcional es pequeno (ver figura 5.12) y oscila entre el 2%y el 10.5%.

La reduccion de variables binarias supone un cuello de botella, y enmuchos casos no se obtienen mejoras, como se vio en la seccion 5.3.3. Porello este algoritmo debe centrar las futuras mejoras. La inferencia haciaatras no consume mucho tiempo de procesador y puede conseguir muybuenos resultados siendo interesante su aplicacion.

5.4 Tiempo de ejecuci on de la sıntesis funcional 175

0

10

20

30

40

50

60

70

80

90

100

7 8 7 8 7 8 7 8 7 8 7 8

Por

cent

aje

de C

PU

Bits

S+P-InferenciaS+P-Inf-AtrasS+P-LUT

Sharpness-InferenciaSharpness-Inf-AtrasSharpness-LUT

Gaussiano-InferenciaGaussiano-Inf-AtrasGaussiano-LUT

Prewitt-InferenciaPrewitt-Inf-AtrasPrewitt-LUT

PrewittBin-InferenciaPrewittBin-Inf-AtrasPrewittBin-LUT

GradienteDir-InferenciaGradienteDir-Inf-AtrasGradienteDir-LUT

S+P Sharpness GaussianoInferencia Inf-Atras LUT Inferencia Inf-Atras LUT Inferencia Inf-Atras LUT

8 22.0 10.5 67.5 27.35 2.04 70.61 20.69 4.22 75.09)7 12.17 10.43 77.39 22.75 8.62 68.63 26.47 10.29 63.24

Prewitt PrewittBin GradienteDirInferencia Inf-Atras LUT Inferencia Inf-Atras LUT Inferencia Inf-Atras LUT

8 9.6 4.41 85.98 8.0 3.76 88.24 3.24) 1.03 95.737 8.97 6.84 84.19 8.49 6.18 85.33 2.48 1.6 95.92

Figura 5.12: Porcentaje del tiempo de ejecucion de la sıntesisfuncional de las diferentes etapas.


5.5. Aplicacion de procesamiento de imagenes en tiem-po real como ejemplo de integracion con entor-nos ESL

Se ha desarrollado un aplicacion para FPGA en un sistema de progra-macion remota de una red de robots industriales para el funcionamientode un TeleLaboratorio. Los alumnos pueden programar sus experimentosvıa pagina Web, la aplicacion de la FPGA realiza un procesamiento deimagenes en tiempo real, suministrando descriptores del objeto al progra-ma del alumno.Se han utilizado las plataformas RC203E/RC340 de la companıa Agi-lityDS para esta aplicacion. Estas plataformas tienen una conexion Et-hernet, entrada/salida de video, una camara de color de alta definicion,una pantalla TFT y una FPGA de la companıa Xilinx, una Virtex II(XC2V3000-4) para el caso de la plataforma RC203E y una Virtex 4(XC4VLX160FF1148-10) para el caso de la plataforma RC340.

Figura 5.13: Diagrama de bloque de la aplicacion para el agarrede una pieza.

La plataforma esta provista de un entorno de desarrollo (DK) basadoen el lenguaje de descripcion de hardware Handel-C, descrito en el primercapitulo. Este entorno incluye una biblioteca para el diseno de sistemasde vision, llamada PixelStream, descrita tambien en el primer capıtulo.

La tarea de tratamiento de imagenes realizada en la FPGA se divideen dos ramas como se muestra en el diagrama de bloques de la figura5.13. En la rama superior, el sistema realiza la binarizacion de las image-nes recogidas de la camara que esta en la garra del robot. Despues, seobtienen los descriptores del objeto (centro de masas, angulo de agarre).Finalmente, los descriptores de los objetos son enviados a la red usando

5.5 Aplicaci on de procesamiento de im agenes en tiempo real como ejemplo deintegraci on con entornos ESL 177

un protocolo especifico para redes de robots (SNRP [96]). En la ramainferior, se realizan los pasos necesarios para mostrar en la pantalla TFTde la plataforma el tratamiento de imagenes realizado.

El calculo del angulo de agarre correspondiente a la expresion 5.1 tieneincluida la operacion arcotangente. El entorno DK no tiene esta opera-cion en ninguna de sus bibliotecas. Normalmente, para implementar estetipo de operaciones se emplean bibliotecas de terceros como pueden serlas incluidas en el entorno del fabricante de la FPGA, que estan muy op-timizadas. Otra opcion es buscar implementaciones de terceros realizadasen lenguajes de descripcion de hardware propios del entorno ESL, lo quepermite un mejor mantenimiento del proyecto, ası como mayor facilidaden el cambio de plataforma. No existiendo tal implementacion, la opcionelegida es realizarla en Madeo.

φ =1

2arctan

2IxyIxIy

(5.1)

En la seccion 4.3, se describieron las posibilidades que tiene Madeode integrarse con un entorno EDA/ESL. El entorno utilizado (sistema dedesarrollo DK de AgilityDS) admite especificar un componente externotanto en formato EDIF como VHDL. Se utilizara la descripcion VHDLpara la depuracion de todo el sistema ya que permite la cosimulacion, esdecir, simular el sistema completo cooperando con los dos simuladores:el simulador VHDL de un tercero (ModelSim) y el simulador del entornoDK. La descripcion EDIF se utilizara para la sıntesis del sistema.

A continuacion, se describe el diseno realizado con Madeo. El disenoes una operacion de arcotangente en coma fija con un error maximo deun grado sexagesimal. Este error viene definido por la sensibilidad delmotor de la garra del robot. El primer paso es obtener el tipo de datosde la entrada. Se busca que tenga el menor numero de bits tanto en laparte entera como en la parte fraccionaria. Para este calculo se utilizala inferencia cuantificada de tipos descrita en la seccion 3.8. En la figura5.14 se muestran los tipos de datos de entrada inferidos correspondientesa diferentes precisiones a la salida para la arcontangente. Se muestra quepara este diseno (error maximo de salida un grado) la entrada es de ochobits para la parte entera y 6 bits para la parte fraccionaria.

Se han realizado dos versiones: la monociclo y la segmentada. En lafigura 5.15 se muestran el area y el tiempo de ciclo de la version monociclopara los diferentes tipos de datos de entrada obtenidos previamente. Se


puede apreciar que el area crece exponencialmente en relacion al tamanode bits de la entrada, y el tiempo de propagacion crece cuadraticamente.

dgbdgpdpb�

��4��

��4�4��

u

0

du

d0

pu

��o��oo��

Figura 5.14: Tipo de datos en coma fija de entrada inferidos enfuncion de tolerancia de la salida.

Se ha implementado la version segmentada con varias latencias parapoder elegir la mejor, Los resultados de area y periodo de reloj se muestraen la figura 5.16. El mejor periodo de reloj se obtiene con latencia 5 eta-pas, siendo esta la opcion optima para una alimentacion ininterrumpidade operaciones. Hay que resaltar las buenas prestaciones del circuito conlatencia 2, que tiene la menor area y la menor latencia global del circuitoen nanosegundos (tiempo que consume el primer trabajo de una secuen-cia). Este ultimo circuito serıa util en los casos en los que no hubiese unaalimentacion ininterrumpida de operaciones.

En este punto, para evaluar la calidad de los resultados se va a realizarla implementacion del arcotangente utilizando la biblioteca de componen-tes del fabricante de la FPGA. El uso es de esta biblioteca esta gestionado


10

100

1000

10000

5.3 5.4 7.5 8.6 9.7 10.8

Sli

ces

Entrada en coma fija (bits enteros).(bits fraccionarios)

33

77

180

423

1059

4730

(a) Area

4

6

8

10

12

14

16

18

20

5.3 5.4 7.5 8.6 9.7 10.8

ns

Entrada en coma fija (bits enteros).(bits fraccionarios)

5,495 5,986

7,3238,386

10,419

15,786

(b) Tiempo

Figura 5.15: Area (Slices) y tiempo (ns) de la implementacionde Madeo de la arcotangente en funcion de tipo de datos de laentrada.

420

425

430

435

440

445

450

1 2 3 4 5 6

Sli

ces

Latencia (ciclos)

Area

(a) Area

0

1

2

3

4

5

6

7

1 2 3 4 5 6

ns

Latencia (ciclos)

Periodo

5.344

3.962

4.6955.150

3.205

4.695

(b) Periodo de reloj

Figura 5.16: Area (Slices) y tiempo (ns) para la implementacionsegmentada de la arcontangente.


Monociclo SegmentadoMadeo Cordic Madeo Cordic

Area (slices) 423 285 421 225

Latencia(ciclos x periodo) 1 x 8.4 ns 1 x 43 ns 5 x 3.2 ns 14 x 4ns

Error medio de precision 0,39 1,03Desviacion tıpica 0,27 0,93

Tabla 5.2: Comparacion entre las implementaciones basado enMadeo y Cordic.

por un asistente grafico, que permite seleccionar un componente, propor-cionar la documentacion correspondiente y configurarlo. Al final, se ge-nera un netlist que la herramienta integra en el diseno automaticamente,lo que protege la propiedad intelectual (IP) del diseno del componente.Concretamente, para la implementacion del arcontangente se utiliza elalgoritmo Cordic. En esta implementacion se ha configurado la mismalongitud de palabra para la entrada (14 bits, 8 parte entera y 6 partefraccionaria) y la salida (un entero de 8 bits) que en el caso anterior, y seha optado por obtener la mayor precision en los resultados.

En el primer analisis se ha evaluado la precision de ambas implemen-taciones. En la seccion 2.3 se describe como Madeo genera un testbenchautomaticamente. Se ha modificado este testbench descrito en VHDL pa-ra invocar simultaneamente el componente basado en Cordic y el disenode Madeo. Con esta informacion se ha calculado el error absoluto respectoal valor real (sin limitaciones de precision) para cada muestra obtenida enel testbench, como muestra la figura 5.17. Como se puede apreciar el errorde la implementacion de Madeo nunca supera el lımite definido (1 grado),y su valor medio y desviacion tıpica son inferiores a la implementacioncon Cordic (ver tabla 5.2). En esta misma tabla se muestran los tiem-pos y areas de las dos implementaciones, para dos versiones diferentes deMadeo: Monociclo y Segmentado.

Se puede apreciar que las implementaciones de Madeo son mucho masrapidas en todos los casos, a costa de tener una area mayor (un 48% masen la version monociclo y un 87% mas en la version segmentada). Noobstante hay que aclarar que el componente de biblioteca implementala operacion arctan(xy ); la inclusion de la division es debida a que es-


0

1

2

3

4

5

6

-100 -50 0 50 100

Err

or

abso

luto

en

gra

do

s ce

nti

gra

do

s

Entrada del arcotangente

MadeoCordic

Figura 5.17: Error de precision de las implementaciones de laarcotangente de Madeo y Cordic.

te calculo es muy frecuente. En el caso de la ecuacion 5.1 que se quiereimplementar, la version de Cordic posiblemente obtendrıa un resultadomejor si se incluyera la division.

En conclusion, el sistema propuesto en esta tesis ha obtenido un circui-to mas rapido aunque con mas area que un componente disenado especıfi-camente, como es el caso Cordic, obteniendo un resultado mas preciso.Por otra parte, la descripcion es mas flexible y facil que la de esta biblio-teca, proporcionado una mayor productividad en el diseno.

CAPITULO 6Conclusiones y lıneas abiertas

de investigacion

6.1. Conclusion y aportaciones

El entorno de desarrollo para Arquitecturas Reconfigurables MADEO,sobre el cual se ha desarrollado esta tesis, propone un sistema que per-mite la interrelacion de la implementacion fısica de la arquitectura y eldesarrollo de las aplicaciones, de forma que el diseno se valida evaluandola ejecucion de las aplicaciones sobre un modelo simulado de la arqui-tectura reconfigurable. La metodologıa de la sıntesis de las aplicacionesesta basada en la transformacion de un algoritmo expresado en un len-guaje orientado a objetos en una red de tablas (LUT) que implementanlas operaciones de dicho algoritmo. La calidad de la circuiterıa resultantese garantiza utilizando tecnicas basadas en la inferencia de tipos depen-diendo del contexto de la aplicacion.

La motivacion de este trabajo desarrollado ha sido la sıntesis de lasaplicaciones DSP de la forma mas eficiente posible. A continuacion, seofrecen las conclusiones generales de este trabajo, destacando cuales hansido las aportaciones originales de la tesis. Estas aportaciones se clasifi-can en dos tipos: las aportaciones novedosas en el ambito de la sıntesis de

183

184 Capıtulo 6 Conclusiones y lıneas abiertas de investig aci on

alto nivel y de la sıntesis logica, y las aportaciones al entorno de desarrollo.

Aportaciones cientıficas en el ambito de la sıntesis de circuitos

1. Se ha desarrollado la tecnica de inferencia hacia atras como un procesode optimizacion, que ha obtenido buenos resultados en aquellos opera-dores cuyo dominio se ha podido reducir.Los experimentos realizados han concluido que este proceso de optimi-zacion mejora las prestaciones (area, tiempo y consumo dinamico) delcircuito generado para este tipo de aplicaciones. Por otra parte, tam-bien los experimentos han revelado que la calidad de las prestaciones esbuena comparandola con otros sintetizadores comerciales. El circuitogenerado es mas rapido aunque en algunos casos ocupe mayor area.

2. Se ha propuesto la inferencia cuantificada de tipos para establecer eltipo de datos a la entrada de un circuito sintetizado dado un margende precision a la salida. El experimento ha proporcionado mejoras encomparacion a la solucion basada en el algoritmo de aproximacionessucesivas de Cordic. Concretamente, las mejoras obtenidas son: mayorprecision en los resultados, circuitos mas rapidos aunque ocupen mayorarea y mayor productividad en el diseno.

3. El sintetizador logico para funciones completas es capaz de reducir elnumero total de variables de la funcion, pero en el caso de funcionesincompletas de muchas variables no lo reduce. Para mejorar la simpli-ficacion en este caso, se ha incluido una tarea en Madeo que reduce elnumero de variables binarias de la funcion suprimiendo aquellas queno influyen en el comportamiento de esta. Los experimentos realizadoshan mostrado una mejora de prestaciones muy significativa en algunoscasos a costa de un tiempo muy alto de sıntesis.

4. La inferencia cıclica ha permitido aplicar la inferencia de tipos a sen-tencias repetitivas que generan un grafo cıclico y un circuito multiciclo.

Aportaciones al entorno de Madeo

1. Se ha dotado al lenguaje de Madeo de constructores vectoriales tıpicosde los algoritmos DSP que permiten especificar la estructura del circui-to para explorar el espacio de diseno. Las estructuras implementadas

6.1 Conclusi on y aportaciones 185

estan constituidas por la replicacion de los operadores, proporcionandoası paralelismo espacial. La comparticion de los operadores entre dife-rentes iteraciones del constructor proporciona una reduccion del areautilizada y la segmentacion de operadores proporciona paralelismo tem-poral.

2. El sintetizador produce una LUT por cada operador. Para el caso deoperadores complejos este sistema no da buenos resultados. La des-cripcion jerarquica ha sido la aportacion para mejorar estos resultados.Esta descripcion impide que un operador complejo se sintetice en unaunica tabla, permitiendo describir la descomposicion de este operadoren tablas mas simples. En los experimentos realizados ha dado buen re-sultado la raız cuadrada del algoritmo de “Prewitt” y en los sumadorespara los experimentos realizados con enteros de menos de 8 bits.

3. Se ha implementado un sistema de generacion de bancos de prueba paravalidar la aplicacion en desarrollo y el propio sintetizador, comparandolos resultados obtenidos por la ejecucion de la rutina software corres-pondiente con los obtenidos por la simulacion del circuito en diferentesfases de diseno. Este sistema de verificacion automatica ha facilitadoel uso de este entorno, como una herramienta para la investigacion detecnicas de sıntesis de alto nivel.

4. Al abordar las aplicaciones DSP se han incrementado las necesidadescomputacionales y el sintetizador se ha integrado en un entorno compu-tacional de altas prestaciones para reducir el tiempo total de ejecucionde la sıntesis logica y tener mayor capacidad de memoria principal.

En resumen, se han disenado e implementado tecnicas y procesos en elentorno de Madeo para las aplicaciones para abordar problemas de ma-yor tamano y para obtener buenas prestaciones, comparables con otrosentornos, y utilizando una especificacion mas productiva.

Llegados a este punto, se hace una reflexion sobre que colectivos yque tipos de aplicaciones pueden beneficiarse de los resultados de estatesis:

Disenadores de sistemas hardware para aplicaciones que necesiten masprecision que la proporcionada por los metodos clasicos de aproximacio-nes sucesivas y para aplicaciones que necesiten operadores no incluidos


en las bibliotecas del entorno de desarrollo.

Investigadores en el campo de sıntesis de alto nivel, que puede utili-zar esta herramienta para desarrollar y verificar sus nuevas tecnicas deforma mas productiva que las herramientas clasicas (Trident [140] ySUIF[129]) al utilizar un lenguaje orientado a objetos y un entorno tanflexible como MADEO.

6.2. Publicaciones

En esta seccion, se van a distinguir en dos categorıas las publicacio-nes relacionadas con esta tesis: las que son resultado directo del trabajode la tesis y las publicaciones que han sido soporte para conocer otrosentornos ESL. El trabajo realizado en las publicaciones acerca del disenoe implementacion de aplicaciones hardware ha sido fundamental para eldesarrollo de esta tesis al permitir enfocar el trabajo desde un punto devista mas practico y aplicado.

6.3. Publicaciones de los resultados de la tesis

Revistas

Raul Marın Prades, German Leon Navarro, Raul Wirz Gonzalez, JorgeSales Gil, Jose M. Claver, Pedro Jose Sanz Valero, Josep Fernandez.IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS . Remo-te Programming of Network Robots Within the UJI Industrial Robo-tics Telelaboratory: FPGA Vision and SNRP Network Protocol. Num.12(56). pp. 4806-4816. 2009.

Congresos Internacionales

German Leon Navarro, German Fabregat Llueca, Jose M. Claver. Au-tomatic Type Inference for Resynthesis on Hardware Description Lan-guages. ReConFig’11: 2011 Internatinal Conference on ReConFigurableComputing and FPGAs. Cancun, Quintana Roo, Mexico: 30-11-2011.Editores: PeterAthanas, Juergen Becker y Rene Cumplido. ISBN: 978-0-7695-4551-6.

6.3 Publicaciones de los resultados de la tesis 187

Jorge Sales Gil, Beltran R., Pedro Jose Sanz Valero, Raul Marın Pra-des, Raul Wirz Gonzalez, German Leon Navarro, Jose M. Claver , Jai-me Alemany Julia. The UJI Industrial Robotics Telelaboratory: Real-time Vision and Networking. IROS 2008 (2008 IEEE/RSJ InternationalConference on Intelligent Robots and Systems). Niza (Francia): 22-09-2008. 2008 IEEE Computer Society. ISBN: 978-1-4244-2058-2.

Jose.M. Claver, German Leon Navarro. High Level Power Optimizationby Type Inference on the Generation of Application Specific Circuitson FPGA. International Conference on Field Programmable Logic andApplications. Amsterdam, The Netherlands: 27-08-2007. 2007 IEEE.ISBN: 1-4244-1060-6.

German Leon Navarro, Jose M. Claver Iborra, German Fabregat Llue-ca. Full type inference on the generation of specific circuits. IX Inter-national Workshop on Symbolic Methods and Applications to CircuitDesign. Firenze (Italy): 12-10-2006. 2006 Stefano Manetti. ISBN: 88-8453-509-3.

German Leon Navarro, Jose M. Claver Iborra, German Fabregat Llue-ca. Optimizing area on the generation of specific circuits in FPGAsfor SIMD Applications International Workshop on Applied Reconfi-gurable computing 2005. Algarve (Portugal): 22-02-2005. 2005 IADISPress. ISBN: 972-99353-8-6.

Congresos Nacionales

Jose M. Claver, German Leon Navarro. Utilizacion de inferencia detipos en la generacion de circuitos especıficos para FPGAs. II Con-greso espanol de Informatica. Zaragoza: 12-09-2007. 2007 InternacionalThomson Editores Spain, S.A.. ISBN: 978-84-9732-593-6.

German Leon Navarro, Jose M. Claver Iborra, German Fabregat Llue-ca. Optimizing Area on the Automatic Generation of Circuits in FP-GAs for SIMD Applications. XV Jornadas de Paralelismo. Almerıa (Es-pana): 15-09-2004. 2004 Universidad de Almerıa. ISBN: 84-8240-714-7.

German Leon Navarro, Jose M. Claver Iborra, German Fabregat Llue-ca. Generacion Automatica de Circuitos en FPGAs para Aplicaciones


SIMD. Proc. of II Jornadas de Computacion Reconfigurable y Aplica-ciones. Granada. 2002 Dpto de Arquitectura y Tecnologıa de Compu-tadores de la Universidad de Granada. ISBN: 84-699-9448-4.

German Leon Navarro, Jose M. Claver Iborra, German Fabregat Llue-ca. Programacion Automatica de FPGAs en Aplicaciones SIMD: Es-tudio de la DWT 1-D. Proc. of XIII Jornadas de Paralelismo. Lleida.2002 Universidad de Lleida. ISBN: 84-8409-159-7.

6.3.1. Publicaciones de aplicaciones utilizando entornos ESL

Revistas

Jose M. Claver, Pau Agustı Ballester, M. Arevalillo-Herraez, GermanLeon Navarro, M. Canseco. JOURNAL OF SYSTEMS ARCHITEC-TURE . A reconfigurable platform for evaluating the performance ofQoS networks. Num. 56. pp. 191-207. 2010.

6.3.2. Congresos Internacionales

Jorge Sales Gil, Reinel Beltran, Pedro Jose Sanz Valero, Raul MarınPrades, Raul Wirz Gonzalez, German Leon Navarro, Jose M. Claver.The UJI Robotics Manufacturing Cell: Web-based architecture andReal-time computer vision. 5th International Conference on Telecom-munications, Electronics and Control (TELEC). Santiago de Cuba (Cu-ba): 14-07-2008. 2008 Cigre. ISBN: 978-84-00-08680-0.

Raul Marın Prades, German Leon Navarro, Raul Wirz Gonzalez, Jor-ge Sales Gil, Jose M. Claver, Pedro Jose Sanz Valero. Remote Con-trol within the UJI Robotics Manufacturing Cell using FPGA-basedvision. European Control Conference 2007. Kos, Grecia: 02-07-2007.2007 IEEE. ISBN: 978-960-89028-5-5.

Jose M. Claver Iborra, Manel Canseco Suarez, P. Agustı, German LeonNavarro., A Hardware NIC Scheduler to Guarantee QoS on High Per-formance Servers , Lecture Notes in Computer Science, No. 4330, Para-llel and Distributed Processing and Applications (ISPA’06), pp. 86-97,2006.

Jose M. Claver Iborra, Pau Agustı Ballester, German Leon Navarro,Manel Canseco Suarez, German Fabregat Llueca. A reprogrammable

6.3 Publicaciones de los resultados de la tesis 189

and Scalable QoS Traffic Generator/Monitor on FPGA. 10th Interna-tional conference on Communication Technology. Guilin (China): 27-11-2006. Internacional . 2006 IEEE Press. ISBN: 1-4244-0801-6.

Congreso Nacionales

Jose M. Claver, Pau Agustı Ballester, Manel Canseco Suarez, GermanLeon Navarro. A Reprogrammable CBR and VBR Traffic Generato-r/Monitor on FPGA. II Congreso espanol de Informatica. Zaragoza:12-09-2007. 2007 Internacional Thomson Editores Spain, S.A.. ISBN:978-84-9732-593-6.

Jose M. Claver Iborra, Manel Canseco Suarez, Pau Agustı Ballester,German Leon Navarro. Arquitectura e Implementacion de un Servi-dor que garantice QoS en Redes de Altas Prestaciones. ComputacionReconfigurable y Aplicaciones. Caceres (Espana): 12-09-2006. Nacio-nal . 2006 Grupo de Arquitectura de Computadores y Diseno Logico(ARCO). ISBN: 84-611-1315-2.

Jose M.Claver Iborra, Manel Canseco Suarez, Pau Agustı Ballester,German Leon Navarro. Arquitectura e Implementacion de un Genera-dor/Monitor de Trafico sobre una FPGA. XVII Jornadas de Paralelis-mo. Albacete: 18-09-2006. Nacional . 2006 Universidad de Castilla laMancha. ISBN: 84-690-0551-0.

Manel Canseco, Jose M. Claver Iborra, German Leon Navarro, IvanVilata. Prototipado de un MMR Simple en una FPGA. XV Jornadasde Paralelismo. Almerıa (Espana): 15-09-2004. Nacional . 2004 Univer-sidad de Almerıa. ISBN: 84-8240-714-7.

German Leon Navarro, Jose M. Claver Iborra, German Fabregat Llue-ca. Optimizing Area on the Automatic Generation of Circuits in FP-GAs for SIMD Applications. XV Jornadas de Paralelismo. Almerıa(Espana): 15-09-2004. Nacional . 2004 Universidad de Almerıa. ISBN:84-8240-714-7.

Manel Canseco, Jose M. Claver Iborra, German Leon Navarro, Ivan Vi-lata. Primeras Experiencias en la implementacion de un encaminadorQoS sobre una FPGA. IV Jornadas de computacion Reconfigurable yAplicaciones. Bellaterra (Espana): 13-09-2004. Nacional . 2004 Univer-sidad Autonoma de Barcelona. ISBN: 84-688-7667-4.


6.4. Lıneas abiertas de investigacion

La presente tesis cubre los objetivos iniciales de proporcionar nue-vas tecnicas de sıntesis de alto nivel para mejorar la expresividad de loslenguajes de descripcion de hardware ası como de obtener buenos resulta-dos para aplicaciones concretas. En esta misma lınea de trabajo, puedenenumerarse tecnicas que no han sido desarrolladas en profundidad y queconstituyen lıneas abiertas de investigacion.

1. Queda abierto el desarrollo mas profundo de la inferencia cuantifica-da de tipos: explotar sus posibilidades en aplicaciones mas complejas,estudiar la reduccion de su coste computacional en el actual marco yestudiar la utilizacion de otras metodologıas de cuantificacion.

2. La estrategia de buscar reglas en la fusion de operadores ha conseguidobuenos resultados para algunos casos concretos. Queda abierto el es-tudio de generalizar la busqueda de que operadores se deben fusionarpara obtener las mejores prestaciones del circuito final.

3. Tanto las tecnicas de inferencia hacia atras como la reduccion de varia-bles binarias obtienen buenos resultados solo en algunos casos y tienenun gran consumo de tiempo de procesador. El estudio para identificarlos casos con menor coste de procesado tendra un alto beneficio.

4. El algoritmo de la reduccion de variables binaras surgio de la necesi-dad de realizar un paso previo en la simplificacion logica, para obtenermejores resultados con el simplificador logico utilizado. Un campo deestudio abierto es mejorar el simplificador logico para resolver este pro-blema directamente. Otra lınea consiste en analizar las posibilidadesde esta tecnica en circuitos que utilicen estos simplificadores.

5. Gran parte del proceso de sıntesis se desarrolla de forma independientede los sistemas de representacion de los tipos de datos y haciendo alfinal la codificacion binaria. Una lınea abierta es buscar una codifica-cion especıfica para cada variable intermedia con el criterio de dirigirel resultado de la sıntesis en el espacio de diseno (consumo de potencia,area y respuesta temporal).

Bibliografıa

[1] Morpheus (multi-purpose dynamically reconfigurable platformfor intensive heterogeneus processing). Technical report,http://www.morpheus-ist.org/.

[2] OMG home page http://www.omg.orglut. Technical report.

[3] IEEE standard VHDL language reference manual. ANSI/IEEE Std1076-1993, Jun 1994.

[4] IEEE standard Verilog hardware description language. IEEE Std1364-2001, pages 0 1–856, 2001.

[5] P. Adde, R. Pyndiah, and O. Raoul. Performance and complexityof block turbo decoder circuits. In Proc. Third IEEE Internatio-nal Conference on Electronics, Circuits, and Systems ICECS ’96,volume 1, pages 172–175, 13–16 Oct. 1996.

[6] Luis Joyanes Agular and Ignacio Zahonero Martinez. Estructura dedatos. Algoritmo, abstraccion y objectos. Mc Graw-Hill, 1998.

[7] E. Ahmed and J. Rose. The effect of LUT and cluster size on deep-submicron FPGA performance and density. 12(3):288–298, 2004.

[8] Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman. Compiladores.Principios,tecnicas y herramientas. Addison-Wesley Iberoamerica-na, 1990.

[9] Caaliph Andriamisaina, Catherine Dezan, Christophe Jego, andBernard Pottier. Synthese abstraite d’elements de turbo-decodeursen bloc pour circuits reconfigurables. In Sympa’2005. GDR ARP,apr 2005.

191

192 BIBLIOGRAF IA

[10] P.J. Ashenden, P.A. Wilsey, and D.E. Martin. SUAVE: painlessextension for an object-oriented vhdl. In Proc. VHDL InternationalUsers’ Forum, pages 60–67, 19–22 Oct. 1997.

[11] P.M. Athanas and H.F. Silverman. Processor reconfigurationthrough instruction-set metamorphosis. Computer, 26(3):11–18,March 1993.

[12] Robert G. Atkinson. Hurricane: an optimizing compiler for Small-talk. OOPSLA’86 proc,21(11) Nov 1986, 1986.

[13] M. Aubury. Bringing Imaging to the System Level with PixelS-treams. Xcell, 2006.

[14] J. Bachrach, D.Qumsiyeh, and M.Tobenkin. Hardware Scripting inGel. In Field-Programmable Custom Computing Machines, 2008.

[15] Amnon Barak. The MOSIX multicomputer operating system forhigh performance cluster computing. Journal of Future GenerationComputer Systems, 13:4–5, 1998.

[16] V. Baumgarte, G. Ehlers, F. May, A. Nuckel, M. Vorbach, andM. Weinhardt. PACT XPP—A Self-Reconfigurable Data Proces-sing Architecture. J. Supercomput., 26(2):167–184, 2003.

[17] Peter Bellows and Bran Hutchings. JHDL-An HDL for Reconfi-gurable Systems. Fiel-Programmable Custom Computing Machnes,1998.

[18] L. Benini, G. De Micheli, E. Macii, M. Poncino, and S. Quer. Poweroptimization of core-based systems by address bus encoding. VeryLarge Scale Integration (VLSI) Systems, IEEE Transactions on,6(4):554 –562, dec 1998.

[19] L. Benini, A. Macii, M. Poncino, and R. Scarsi. Architectures andsynthesis algorithms for power-efficient bus interfaces. volume 19,pages 969 –980, sep 2000.

[20] A. Benveniste, P. Caspi, S.A. Edwards, N. Halbwachs, P. Le Guer-nic, and R. de Simone. The synchronous languages 12 years later.Proceedings of the IEEE, 91(1):64 – 83, jan 2003.

BIBLIOGRAF IA 193

[21] Josep M. Bernat. Fonaments matematcs de la informatica. Teoriai problemes(ETIG). UJI, 2006.

[22] Per Bjesse, Koen Claessen, Mary Sheeran, and Satnam Singh. Lava:Hardware design in Haskell. In In International Conference onFunctional Programming, pages 174–184. ACM Press, 1998.

[23] W. Bohm, J. Hammes, B. Draper, M. Chawathe, C. Ross, R. Rinker,andW. Najjar. Mapping a single assignment programming languageto reconfigurable systems. J. Supercomput., 21(2):117–130, 2002.

[24] Thomas Bollaert. Catapult Synthesis: A Practical Introduction toInteractive C Synthesis High-Level Synthesis. In Philippe Coussyand AdamMorawiec, editors, High-Level Synthesis, chapter 3, pages29–52. Springer Netherlands, Dordrecht, 2008.

[25] Kiran Bondalapati, Pedro Diniz, Phillip Duncan, John Granacki,Rajeev Jain, and Heidi Ziegler. DEFACTO: A design environmentfor adaptive computing technology. In In Reconfigurable Architec-tures Workshop, RAW’99, pages 570–578. Springer-Verlag, 1999.

[26] Robert K. Brayton, Gary D. Hachtel, Alberto L. Sangiovanni-Vincentelli, Fabio Somenzi, Adnan Aziz, Szu-Tsung Cheng, Step-hen A. Edwards, Sunil P. Khatri, Yuji Kukimoto, Abelardo Pardo,Shaz Qadeer, Rajeev K. Ranjan, Shaker Sarwary, Thomas R. Shiple,Gitanjali Swamy, and Tiziano Villa. VIS: A system for verificationand synthesis. pages 428–432, 1996.

[27] G. Caffarena. Combined Word-length allocation and High-LevelSynthesis of Digital Signal Processing Circuits. PhD thesis, EscuelaTecnica Superior de Ingenieros de Telecomunicacion. UniversidadPolitecnica de Madrid, 2008.

[28] N. Calazans, E. Moreno, F. Hessel, V. Rosa, F. Moraes, and E. Ca-rara. From VHDL register transfer level to SystemC transactionlevel modeling: a comparative case study. In Proc. 16th Symposiumon Integrated Circuits and Systems Design SBCCI 2003, pages 355–360, 8–11 Sept. 2003.

[29] Joel Cambonie, Sylvain Guerin, Ronan Keryell, Loıc Lagadec, Ber-nard Pottier, Olivier Sentieys, Bernt Weber, and Samar Yazdani.

194 BIBLIOGRAF IA

Compiler and system techniques for SOC distributed reconfigurableaccelerators. In Synthesis, Architectures and Modeling of Systems(SAMOS’04), volume 3133, pages 293–302. Springer-Verlag, 2004.

[30] John Canny. A computational approach to edge detection. PatternAnalysis and Machine Intelligence, IEEE Transactions on, PAMI-8(6):679 –698, nov. 1986.

[31] M. A. Cantin, Y. Savaria, and P. Lavoie. A comparison of automaticword length optimization procedures. In Proc. IEEE InternationalSymposium on Circuits and Systems ISCAS 2002, volume 2, pagesII–612–II–615, 26–29 May 2002.

[32] J.M.P. Cardoso and H.C. Neto. Compilation for FPGA-basedreconfigurable hardware. IEEE Design & Test of Computers,20(2):65–75, March–April 2003.

[33] Joao Manuel Paiva Cardoso. Compilacao de algoritmos em Javapara Sistemas Computacionais Reconfiguraveis com exploracao doparalelismo ao Nivel das operacoes. PhD thesis, Electronica e Tele-comunicacoes, Universidade de Aveiro, Octubre 2000.

[34] Joao M.P. Cardoso and Pedro C. Diniz. Compilation Techniquesfor Reconfigurable Architectures. Springer Publishing Company, In-corporated, 2008.

[35] Rafael C.Gonzalez and Richard E.Woods. Digital Image Process.Addison-Wesley, 93.

[36] Craig Chambers, John Hennessy, and Mark Linton. The design andimplementation of the SELF compiler, an optimizing compiler forobject-oriented programming languages. Technical report, 1992.

[37] M. Chu, N. Weaver, K. Sulimma, A. Dehon, and J. Wawrzynek.Object oriented circuit-generators in Java. In Proc. IEEE Sympo-sium on FPGAs for Custom Computing Machines, pages 158–166,April 15–17, 1998.

[38] Koen Claess and Gordon Pace. An Embedded Language Frameworkfor Hardware Compilation. 4Th International Workshop on DesignCorrect Circuits, 2002.

BIBLIOGRAF IA 195

[39] K. Claessen and G. Pace. An embedded language framework forhardware compilation. In 4th International Workshop on DesignConnect Circuit (DCC’02), 2000. Grenoble, France.

[40] J. Cong, Bin Liu, S. Neuendorffer, J. Noguera, K. Vissers, and Zhi-ru Zhang. High-level synthesis for FPGAs: From prototyping todeployment. 30(4):473–491, 2011.

[41] G. A. Constantinides, P. Cheung, and W. Luk. Word-length opti-mization for linear digital signal processing. IEEE Transactions onCAD of Integrated Circuits and Systems, pages 1432–1442, 2003.Vol. 22, No. 10.

[42] Philippe Coussy and Adam Morawiec, editors. High-Level Synthesisfrom Algoritm to Digital Circuit. Springer Netherlands, Dordrecht,2008.

[43] J.G.F. Coutinho, J. Jiang, and W. Luk. Interleaving behavioraland cycle-accurate descriptions for reconfigurable hardware compi-lation. In Field-Programmable Custom Computing Machines, 2005.FCCM 2005. 13th Annual IEEE Symposium on, pages 245–254,18-20 April 2005.

[44] J.G.F. Coutinho and W. Luk. Source-directed transformations forhardware compilation. In Field-Programmable Technology (FPT),2003. Proceedings. 2003 IEEE International Conference on, pages278–285, 15-17 Dec. 2003.

[45] Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman,and F. Kenneth Zadeck. Efficiently computing static single assign-ment form and the control dependence graph, 1991.

[46] Jean-Marc Daveau, Gilberto Fernandes Marchioro, Carlos Alber-to Valderrama, and Ahmed Amine Jerraya. VHDL generation fromSDL specifications. In Proceedings of the IFIP Conference on Hard-ware Description Languages and their Application, pages 182–201,1997.

[47] G. De Micheli, D. Ku, F. Mailhot, and T. Truong. The Olympussynthesis system. IEEE Design & Test of Computers, 7(5):37–53,Oct. 1990.

196 BIBLIOGRAF IA

[48] Diego Gomez Deck. Programando con Smalltalk.Un ambiente deobjetos vivos. 2006.

[49] Jeremie Detrey and Oliver Diessel. SCCircal: a static compiler map-ping XCircal to Virtex FPGAs. Technical report 0213, School ofComputer Science and Engineering, University of New South Wales,Sydney, NSW, Australia, August 2002.

[50] C. Dezan, C. Jego, B. Pottier, C. Gouyen, and L. Lagadec. The casestudy of block turbo decoders on a framework for portable synthesison FPGA. In System Sciences, 2006. HICSS ’06. Proceedings of the39th Annual Hawaii International Conference on, volume 10, pages250b–250b, 04-07 Jan. 2006.

[51] B. Djafri and J. Benzakki. OOVHDL: object oriented VHDL. InProc. VHDL International Users’ Forum, pages 54–59, 19–22 Oct.1997.

[52] Niklas Een and Niklas Sorensson. An Extensible SAT-solver. InEnrico Giunchiglia and Armando Tacchella, editors, Theory andApplications of Satisfiability Testing, volume 2919 of Lecture Notesin Computer Science, chapter 37, pages 333–336. Springer Berlin /Heidelberg, Berlin, Heidelberg, 2004.

[53] E. El-Araby, M. Taher, M. Abouellail, T. El-Ghazawi, and G.B.Newby. Comparative analysis of high level programming for recon-figurable computers: Methodology and empirical study. In Proc.3rd Southern Conference on Programmable Logic SPL ’07, pages99–106, 28–26 Feb. 2007.

[54] D. Johnson et al. Design automation of a receiver:breaking the RTlcycle time barrier using Behavioral Compiler. In DesignCon, 1998.

[55] D.D. Gajski et al. SpecC: Specification Language and Methodology.Kluwer Academic Publishers, 2000.

[56] G. Fabregat, G. Leon, B. Pottier, and O. Le Berre. Embeddedsystem modeling and synthesis in OO environments: A smart-sensorcase study. In Compiler and Architecture Support for EmbeddedSystems (CASES’99), 1999. Washington D.C., USA.

BIBLIOGRAF IA 197

[57] E. Sentovich G. Berry. An Implementation of Constructive Syn-chronous in POLIS. ftp://ftp-sop.inria.fr/meije/esterel, 1998.

[58] D. Galloway. The Transmogrifier C hardware description languageand compiler for FPGAs. In Proc. IEEE Symposium on FPGAs forCustom Computing Machines, pages 136–144, 19–21 April 1995.

[59] Peter Y.K. Cheung George A. Constantinides and Wayne Luk.Synthesis and optimization of DSP algorithms. Boston : KluwerAcademic Publishers, cop., 2004.

[60] M Gokhale and P Graham. Reconfigurable Computing.AcceleratingComputation with Field-Programmable Gate Arrays. 2005.

[61] M. Gokhale, J. Stone, J. Arnold, and M. Kalinowski. Stream-oriented FPGA computing in the Streams-C high level language.In Field-Programmable Custom Computing Machines, 2000 IEEESymposium on, pages 49 –56, 2000.

[62] S.C. Goldstein, H. Schmit, M. Budiu, S. Cadambi, M. Moe, andR.R. Taylor. Piperench: a reconfigurable architecture and compiler.Computer, 33(4):70–77, April 2000.

[63] Christophe Gouyen and Loıc Lagadec. Outils generiques pour lereconfigurable: Applications aux architectures commerciales. InAuguin and Baude and Lavenier and Riveill, editor, Renpar/CF-SE/SYMPAAA 2003, (INRIA, GDR ARP), La Colle sur Loup,Oct 2003.

[64] Justin Owens Graver. Type-Checking and Type-Inference for Object-Oriented Programming Languages. PhD thesis, University of Illinoisat Urbana Champaign, 1989.

[65] D Greaves and S. Satnam. Kiwi: Synthesis of FPGA circuits fromparallel programs. In Field-Programmable Custom Computing Ma-chines, 2008.

[66] Hardware/Software Group. POLIS.A Framework forHardware-Software Co-Design Design of Embedded Systems.http://embedded.eecs.berkeley.edu/research/hsc/, 1997.

[67] D. Grune, H.E. Bal, C.J.H. Jacobs, and K.G. Langendoen. ModernComputer Design. Wiley, 2000.

198 BIBLIOGRAF IA

[68] B.N.V.M. Gupta, H. Narayanan, and M.P. Desai. A state assign-ment scheme targeting performance and area. In VLSI Design,1999. Proceedings. Twelfth International Conference On, pages 378–383, January 1999.

[69] Malay Haldar, Anshuman Nayak, Alok Choudhary, and Prith Ba-nerjee. A System for synthesizing optimized FPGA hardware fromMATLAB(R). Computer-Aided Design, International Conferenceon, 0:314, 2001.

[70] J. Hammes, B. Rinker, W. Bohm, W. Najjar, B. Draper, and R. Be-veridge. Cameron: high level language compilation for reconfigura-ble systems. In Proc. International Conference on Parallel Archi-tectures and Compilation Techniques, pages 236–244, 12–16 Oct.1999.

[71] J.P. Hammes, R. Rinker, and W. Najjarand B. Draper. A High-level, Algorithmic Programming Language and Compiler for Re-configurable Systems. In 2nd International Workshop on the Engi-neering of Reconfigurable Hardware/Software Objects (ENREGLE),part of the 2000 International Conference on Parallel and Distribu-ted Processing Techniques and Applications (PDPTA), Las Vegas,NV, 2000.

[72] S. Hauck and A. DeHon. Reconfigurable Computing: The Theoryand Practice of FPGA-Based Computing,. 2008.

[73] John Hennessy and David Patterson. Computer Architecture - AQuantitative Approach. Morgan Kaufmann, 2003.

[74] C. A. R. Hoare. Communicating sequential processes. Commun.ACM, 21(8):666–677, August 1978.

[75] J-H.R. Jiang and R.K. Brayton. Retiming and resynthesis: A com-plexity perspective. 25(12):2674–2686, Dec. 2006.

[76] G. Jones and M. Sheeran. Circuits design in Ruby. In J Stauns-trup, editor, Formal Methods for VLSI Design. Ed.Amsterdam.TheNetherlands North-Holland, 1990.

[77] Geraint Jones and Michael Goldsmith. Programming In Occam 2.Prentice Hall, 1988.

BIBLIOGRAF IA 199

[78] JTC1/SC22/WG14. Programming languages C - extensions to sup-port embedded processor. Technical reportn 18037, ISO/IEC, 2004.

[79] H. J. Kahn and R. F. Goldman. The electronic design interchangeformat edif: present and future. In DAC ’92: Proceedings of the29th ACM/IEEE conference on Design automation, pages 666–671,Los Alamitos, CA, USA, 1992. IEEE Computer Society Press.

[80] Sinan Kaptanoglu, Greg Bakker, Arun Kundu, Ivan Corneillet, andBen Ting. A new high density and very low cost reprogrammableFPGA architecture. In Proceedings of the 1999 ACM/SIGDA se-venth international symposium on Field programmable gate arrays,FPGA ’99, pages 3–12, New York, NY, USA, 1999. ACM.

[81] G. Karypis, R. Aggarwal, V. Kumar, and S. Shekhar. MultilevelHypergraph Partitioning: Application in VLSI domain. In Proc.34th Design Automation Conf, pages 526–529, 1997.

[82] Seehyun Kim, Ki-Il Kum, and Wonyong Sung. Fixed-point op-timization utility for C and C++ based digital signal processingprograms. 45(11):1455–1464, 1998.

[83] L. Lagadec. Abstraction, Modelisation et Outils ce CAO Pour LesCircuits Integres Reconfigurables. PhD thesis, Univ. de Rennes 1,2000.

[84] Loıc Lagadec, Bernard Pottier, and Damien Picard. Toolset fornano-reconfigurable computing. Microelectron. J., 40(4-5):665–672,2009.

[85] Loıc Lagadec, Bernard Pottier, and Oscar Villellas-Guillen. An lut-based high level synthesis framework for reconfigurable architec-tures. In S.S. Batttacharyya, E. Deprettere, and J. Teich, editors,Domain-Specific Processors : Systems, Architectures, Modeling, andSimulation, pages 19–39. Marcel Dekker, nov 2003.

[86] Monica Lam. An effective scheduling technique for VLIW machine.SIGPALN’88, 1988.

[87] Patricia le Moenner. Contribution a la realisation d’une chaınecomplete pour la synthese de circuits reguliers. Tesis.Universite deRennes 1, 1997.

200 BIBLIOGRAF IA

[88] Sebastien Lebeux and Loic Lagadec. Madeo, une approche MDApour la programmation et la synthese d’architectures reconfigura-bles. In Sympa’2005. GDR ARP, apr 2005.

[89] Gareth Lee and George Milne. Programming paradigms for reconfi-gurable computing. Microprocessors and Microsystems, 29(10):435–450, December 2005.

[90] L. Lemarchand. Parallel synthesis of large combinational circuitsfor FPGAs. In Proceedings of HPCN Europe’97, Vienne, Austria.Springer-Verlag, LNCS 1225, 1997.

[91] L. Lemarchand. Parallel performance directed technology mappingfor FPGAmv. In Proceedings of IEEE Southwest Symposium onMixed-Signal Design, Tucson, USA, pages 189–194, 1999.

[92] Laurent Lemarchand. Parallelisation par partitionnement pour lasynthese logique combinatoire sur FPGA a base de LUT. PhD the-sis, Universite de Rennes I, 35065 Rennes cedex, France, Jan 1999.

[93] Yanbing Li and M. Leeser. HML, a novel hardware descriptionlanguage and its translation to VHDL. 8(1):1–8, Feb. 2000.

[94] Wayne Luk and Steve McKeever. Pebble: A Language For Parame-trised and Reconfigurable Hardware Design. FPL 02, 2002.

[95] T. Lv, J. Henkel, H. Lekatsas, and W. Wolf. An adaptive dictionaryencoding scheme for soc data buses. In Design, Automation andTest in Europe Conference and Exhibition, 2002. Proceedings, pages1059 –1064, 2002.

[96] R. Marin, G. Leon, R. Wirz, J. Sales, J.M. Claver, P.J. Sanz, andJ. Fernandez. Remote programming of network robots within theUJI industrial robotics telelaboratory: FPGA vision and SNRPnetwork protocol. Industrial Electronics, IEEE Transactions on,56(12):4806–4816, dec. 2009.

[97] Janice M.Stone (Sarnoff Corporation) Maya B. Gokhale. NAPA C:Compiling for a Hybrid RISC/FPGA Architecture. IEEE Sympo-sium on FPGAs for Custom Computing Machinnes,Abril 98, NapaValley, 1998.

BIBLIOGRAF IA 201

[98] O. Mencer and O. Mencer. PAM-Blox II: design and evaluation ofC++ module generation for computing with FPGAs. In Proc. 10thAnnual IEEE Symposium on Field-Programmable Custom Compu-ting Machines, pages 67–76, 2002.

[99] O. Mencer, O. Mencer, M. Morf, and M.J. Flynn. PAM-Blox: highperformance FPGA design for adaptive computing. In M. Morf,editor, Proc. IEEE Symposium on FPGAs for Custom ComputingMachines, pages 167–174, 1998.

[100] Felix Garcıa Merayo. Matematica discreta. Madrid Paraninfo, 2001.

[101] Giovanni De Micheli. Synthesis and Optimization of Digital Cir-cuits. McGrawHill Electrical and Computer Engineering Series,1994.

[102] George J. Milne. CIRCAL and the representation of communica-tion, concurrency, and time. ACM Trans. Program. Lang. Syst.,7(2):270–298, April 1985.

[103] G.J Milne. Formal Specification and Verification of Digital Systems.McGrawHill, Miadenland,England 1994.

[104] R. Milner. A Calculus of Communicating Systems. Springer-VerlagNew York, Inc., Secaucus, NJ, USA, 1982.

[105] Robin Milner. A theory of type polymorphism in programming.Journal of Computer and System Sciences, 1978.

[106] A. Mishchenko, S. Chatterjee, and R. Brayton. DAG-aware AIGrewriting: a fresh look at combinational logic synthesis. In DesignAutomation Conference, 2006 43rd ACM/IEEE, pages 532–535, 24-28 July 2006.

[107] Alan Mishchenko, Robert Brayton, Jie-Hong Roland Jiang, andStephen Jang. Scalable don’t-care-based logic optimization andresynthesis. In Proceeding of the ACM/SIGDA international sympo-sium on Field programmable gate arrays, FPGA ’09, pages 151–160,New York, NY, USA, 2009. ACM.

[108] J. D. Morison, N. E. Peeling, T. L. Thorp, and E. jV. Whiting.EASE: a design support environment for the HDDL ELLA. In

202 BIBLIOGRAF IA

DAC ’87: Proceedings of the 24th ACM/IEEE conference on Designautomation, pages 741–749, New York, NY, USA, 1987. ACM.

[109] I. Moussa, Z. Sugar, R. Suescun, M. Diaz-Nava, M. Pavesi, S. Crudo,L. Gazi, and A.A. Jerraya. Comparing RTL and behavioral designmethodologies in the case of a 2M-transistor ATM shaper. In Proc.36th Design Automation Conference, pages 598–603, 21–25 June1999.

[110] Jean-Michel Muller. Elementary Functions. Algoritms and Imple-mentation. Birkauser, 2006.

[111] S.S. Munick and N.D. Jones. Program Flow Analysis: Theory andApplications. Prentice, 1981.

[112] Hardware/Software MVSIS Group. MVSIS: Multi-ValuedLogic Synthesis System. Technical report, UC Berkeley.http://embedded.eecs.berkeley.edu/mvsis/.

[113] W.A. Najjar, W. Bohm, B.A. Draper, J. Hammes, R. Rinker, J.R.Beveridge, M. Chawathe, and C. Ross. High-level language abstrac-tion for reconfigurable computing. Computer, 36(8):63–69, Aug.2003.

[114] A Nayak, M Haldar, A. Choudhary, and P. Benerjee. Precision anderror analysis of MATLAB applications during automated hardwaresynthesis for FPGAs. Proc Design Automation Test Eur. Munich,pages 722–728, 2001.

[115] Michael I. Schwartzbach Ole Agesen, Jens Palsberg. Type inferenceof SELF. Analysis of Objects with Dynamic and Multiple Inheri-tance. In ECOOP’03 Proceedings, Springer Verlag Lecture Notes,2003.

[116] I. Page and W. Luk. Compiling Occam Into Field-programmableGate Arrays. EE&CS books, 1991. W. Luk and W. Moore, editors.FPGAs, Abingdon.

[117] I. Page, W. Luk, and H. Lau. Hardware compilation for fpgas:imperative and declarative approaches for a robotics interface. InField Programmable Gate Arrays - Technology and Applications,IEE Colloquium on, pages 9/1–9/4, 15 Feb 1993.

BIBLIOGRAF IA 203

[118] Y.V Panchul and D.R Soderman, D.A. and. Coleman. System forConverting Hardware Designs in High-Level System for ConvertingHardware Designs in High-Level,US patent 6,226,776. 2001.

[119] David A. Patterson and John L. Hennessy. Organizacion y diseno decomputadores: la interfaz hardware/software. Amsterdam, Holanda: Elsevier, 2009.

[120] Ricardo Pena Mari. Diseno de programas formalismo y abstraccion.Prentice Hall, 98.

[121] Benjamin C. Pierce. Types and Programming Languages. MITPress, 2002.

[122] Bernard Pottier. An integrated platform for heterogeneous reconfi-gurable computing. In ERSA, pages 25–36, 2007.

[123] D Pursley and Forte Design Systems. Metrics-based behavioral de-sign: A methodology for quickly realizing high quality hardware forsignal processing applications. In Global Signal Processing Confe-rences & Expo for the industry, 2005.

[124] A. Putnam, D. Bennett, E. Dellinger, J. Mason, P. Sundararajan,and S. Eggers. CHiMPS: A C-level compilation flow for hybridCPU-FPGA architectures. In Proc. International Conference onField Programmable Logic and Applications FPL 2008, pages 173–178, September 8–10, 2008.

[125] R. Pyndiah, A. Glavieux, A. Picart, and S. Jacq. Near optimumdecoding of product codes. In Proc. IEEE Global Telecommunica-tions Conference GLOBECOM ’94. ’Communications: The GlobalBridge’, pages 339–343, 28 Nov.–2 Dec. 1994.

[126] I. Raicu, I. T. Foster, and Yong Zhao. Many-task computing forgrids and supercomputers. In Proc. Workshop Many-Task Compu-ting Grids and Supercomputers MTAGS 2008, pages 1–11, 2008.

[127] J Rasure and S Kubica. The KHOROS application developmentenvionment. Experimental Environment for Computer Vision andImage Processing, World Scientific American, 1994.

204 BIBLIOGRAF IA

[128] Sanghamitra Roy and Prith Banerjee. An algorithm for tradingoff quantization error with hardware resources for MATLAB-basedFPGA design. 54(7):886–896, 2005.

[129] R. Wilson R. French C. Wilson S.Amarasinghe J.Anderson S.TjiangS.W.Liao. SUIF: An Infrastructure for Research on Parallelizingand Optimizing Compilers. ACM SIGPLAN Notices 29(12), 1994.

[130] A. Said and W. Pearlman. An image multiresolution representationfor lossless and lossy compression. IEEE Tran. on Image Processing,pages 1303–1310, 1996. Vol. 5,.

[131] Michael Santarini. Cadence adds system-level design tool to edaflow. Technical report, EETimes, January 10 2000.

[132] P. Schaumont, S. Vernalde, L. Rijnders, M. Engels, and I. Bolsens.A programming environment for the design of complex high speedASICs. In Proc. Design Automation Conference, pages 315–320,1998.

[133] L. Semeria, K. Sato, and G. De Micheli. Synthesis of hardwaremodels in C with pointers and complex data structures. 9(6):743–756, Dec. 2001.

[134] E. Sentovich. SIS: a system for sequential circuit synthesis. EECS,Berkeley, TR UCB/ERL M92/41., 1992.

[135] M Serra, 0 Navas, J Escrig, M Bonamusa, P Mari, and J Carrabi-na. Metodlogıa de prototipado rapido desde matlab: herramientasvisuales para flujo de datos. JCRA, 2004.

[136] R. Sharp and O. Rasmussen. The T-Ruby design system. In Proc.ASP-DAC ’95/CHDL ’95/VLSI ’95., IFIP International Conferen-ce on Hardware Description Languages; IFIP International Confe-rence on Very Large Scale Integration. Asian and South Pacific De-sign Automation Conference, pages 587–596, 29 Aug.–1 Sept. 1995.

[137] S. Singh and P. James-Roxby. Lava and JBits: From HDL to bits-tream in seconds. In Field-Programmable Custom Computing Ma-chines, 2001. FCCM ’01. The 9th Annual IEEE Symposium on,pages 91–100, 2001.

BIBLIOGRAF IA 205

[138] M. Stephenson, J. Babb, and S. Amarasinghe. Bitwidth analysiswith application to silicon compilation. In Proceedings of the ACM,SIGPLAN PLSI, pages 108–120, 2000. Vancouver, Australia.

[139] C.E. Stroud, R.R. Munoz, and D.A. Pierce. Behavioral model synt-hesis with Cones. IEEE Design & Test of Computers, 5(3):22–30,June 1988.

[140] J.L. Tripp, M.B. Gokhale, and K.D. Peterson. Trident: From high-level language to hardware circuitry. Computer, 40(3):28–37, March2007.

[141] Justin L. Tripp, Preston A. Jackson, and Brad Hutchings. Sea Cu-cumber: A synthesizing compiler for FPGAs. In FPL ’02: Procee-dings of the Reconfigurable Computing Is Going Mainstream, 12thInternational Conference on Field-Programmable Logic and Appli-cations, pages 875–885, London, UK, 2002. Springer-Verlag.

[142] Zain ul Abdin and B. Svensson. A study of design efficiency with ahigh-level language for FPGAs. In Proc. IEEE International Para-llel and Distributed Processing Symposium IPDPS 2007, pages 1–7,26–30 March 2007.

[143] Brigham Young University. www.jhdl.org.

[144] G. Vanmeerbeeck, P. Schaumont, S. Vernalde, M. Engels, andI. Bolsens. Hardware/software partitioning of embedded system inOCAPI-xl. In Hardware/Software Codesign, 2001. CODES 2001.Proceedings of the Ninth International Symposium on, pages 30–35,25-27 April 2001.

[145] Nikolaos Voros, Albert Rosti, and Michael (Eds.) Hubner, editors.Dynamic System Reconfiguration in Heterogeneous Platforms TheMORPHEUS Approach. Springer, 2009. ISBN: 978-90-481-2426-8.

[146] M. Wazlowski, L. Agarwal, T. Lee, A. Smith, E. Lam, P. Athanas,H. Silverman, and S. Ghosh. PRISM-II compiler and architectu-re. In Proc. IEEE Workshop on FPGAs for Custom ComputingMachines, pages 9–16, 5–7 April 1993.

[147] M. Weinhardt, M. Weinhardt, and W. Luk. Pipeline vectorization.20(2):234–248, 2001.

206 BIBLIOGRAF IA

[148] G. S. Whitcomb and A. R. Newton. Abstract data types and high-level synthesis. In Proc. th ACM/IEEE Design Automation Confe-rence, pages 680–685, June 24–28, 1990.

[149] N Wirth. Hardware compilation: Translating programs into circuits.IEEE Computer, 1998. (June 1998).

[150] Niklaus Wirth. Digital Circuit Design for Computer Science Stu-dents: An Introductory Textbook. 1995.

[151] www.mitrion.com. Mitrion web site. Technical report.

[152] Xilinx. AccelDSP synthesis tool floating-point to fixed-point con-version of Matlab algorithms targeting FPGAs”. Technical report,White Paper, Xilinx Inc, 2006.

[153] Fernando Pardo Carpio y Jose Antonio Boluda Grau. VHDL. Len-guaje para sintesis y modelado de circuitos. RaMa, 2011.

[154] AgilityDS y Mentor Graphics. http://www.mentor.com/products/fpga/handel-c/. Technical report.

[155] Carlos Delgado y otros. Hardware / software codesig based on lotos.IV Jornadas de Concurrencia, 1995.

[156] Felice Balarin y otros. Hardware-Software Co-Design of EmbeddedSystems. Kluwer Academic Publisher, 1997.

[157] Jordi Carabina y otros. Descripcion de la computacion y su imple-mentacion reconfigurable. II Jornadas sobre Computacion Reconfi-gurable y Aplicaciones, 2002.

s´ıntesis de circuitos digitales basada en la generaci´on

Documents