TESIS DOCTORAL IMPLEMENTACION DE …oa.upm.es/13616/1/MIGUEL_ANGEL_SANCHEZ_MARCOS.pdf · tesis...

UNIVERSIDAD POLITECNICA DE MADRIDESCUELA TECNICA SUPERIOR DE INGENIEROS DE

TELECOMUNICACION

TESIS DOCTORAL

IMPLEMENTACION DE ALGORITMOS DE PROCESADO DESENAL SOBRE FPGA: ESPECIFICACION, REUTILIZACION Y

EXPLORACION DEL ESPACIO DE DISENO

Miguel Angel Sanchez Marcos2012

TESIS DOCTORAL

IMPLEMENTACION DE ALGORITMOS DE PROCESADO DESENAL SOBRE FPGA: ESPECIFICACION, REUTILIZACION Y

EXPLORACION DEL ESPACIO DE DISENO

Autor:

Miguel Angel Sanchez MarcosIngeniero de Telecomunicacion

Director:

Marıa Luisa Lopez VallejoProfesor Titular del Dpto. de Ingenierıa Electronica

Universidad Politecnica de Madrid

DEPARTAMENTO DE INGENIERIA ELECTRONICA

ESCUELA TECNICA SUPERIOR DE INGENIEROS DETELECOMUNICACION

UNIVERSIDAD POLITECNICA DE MADRID

2012

TESIS DOCTORAL: Implementacion de Algoritmos de Procesado deSenal sobre FPGA: Especificacion, Reutilizaciony Exploracion del Espacio de Diseno

AUTOR: Miguel Angel Sanchez Marcos

DIRECTORA: Marıa Luisa Lopez Vallejo

El tribunal nombrado para juzgar la Tesis arriba indicada, compuesto por los siguientesdoctores:

PRESIDENTE: D. Carlos A. Lopez Barrio

VOCALES: D. Eugenio Villar Bonet

D. Fernando Rincon Calle

D. Gabriel Caffarena Fernandez

SECRETARIO: D. Carlos Angel Iglesias Fernandez

acuerdan otorgarle la calificacion de:

....... de ......................... de 2012

El Secretario del Tribunal

A Emma

Agradecimientos

Quiero agraceder a Marisa, quien ha guiado mi investigacion desde que me titule ycon quien he estado trabajando desde entonces. Quiero darle las gracias por darme laoportunidad de trabajar en esta Tesis, por sus sus consejos y contribuciones sin los que estaTesis no hubiera sido posible, y por todos los anos de amistad, colaboracion y paciencia.

Tambien agradecer a otros miembros del grupo LSI, presentes como Angel, CarlosLopez Barrio, Carlos Carreras, Juan Antonio, Roberto, Enrique, pero tambien pasadoscomo Gabriel. En especial a Pedro Echeverrıa, Pablo Ituero y Pablo Royer, con quieneshe colaborado durante estos anos.

A los miembros del Departamento de Senales, Sistemas y Radiocomunicaciones, Jesus,Omar y Victor, con quien tambien he trabajado y colaborado. A Mario, por su colaboraciony ayuda.

A Carlos A. Iglesias del Departamento Ingenierıa de Sistemas Telematicos, por susconsejos y contribuciones que han enriquecido esta Tesis.

A los proyectos CICYT que me han financiado durante la realizacion de esta Tesis:DELTA (TEC2009-08589), OPTIMA (TEC2006-00739) y MARCE (TIC2003-07036).

A mis padres y familia.

A Almudena por el carino y apoyo que me ha dado todo este tiempo.

i

Resumen

Esta Tesis aborda el diseno e implementacion de aplicaciones en el campo de proce-sado de senal, utilizando como plataforma los dispositivos reconfigurables FPGA. Estaplataforma muestra una alta capacidad de logica, e incorpora elementos orientados al pro-cesado de senal, que unido a su relativamente bajo coste, la hacen ideal para el desarrollode aplicaciones de procesado de senal cuando se requiere realizar un procesado intensivoy se buscan unas altas prestaciones.

Sin embargo, el coste asociado al desarrollo en estas plataformas es elevado. Mientrasque el aumento en la capacidad logica de los dispositivos FPGA permite el desarrollo desistemas completos, los requisitos de altas prestaciones obligan a que en muchas ocasionesse deban optimizar operadores a muy bajo nivel. Ademas de las restricciones tempora-les que imponen este tipo de aplicaciones, tambien tienen asociadas restricciones de areaasociadas al dispositivo, lo que obliga a evaluar y verificar entre diferentes alternativasde implementacion. El ciclo de diseno e implementacion para estas aplicaciones se puedeprolongar tanto, que es normal que aparezcan nuevos modelos de FPGA, con mayor ca-pacidad y mayor velocidad, antes de completar el sistema, y que hagan a las restriccionesutilizadas para el diseno del sistema inutiles.

Para mejorar la productividad en el desarrollo de estas aplicaciones, y con ello acor-tar su ciclo de diseno, se pueden encontrar diferentes metodos. Esta Tesis se centra en lareutilizacion de componentes hardware previamente disenados y verificados. Aunque loslenguajes HDL convencionales permiten reutilizar componentes ya definidos, se puedenrealizar mejoras en la especificacion que simplifiquen el proceso de incorporar componen-tes a nuevos disenos. Ası, una primera parte de la Tesis se orientara a la especificacion dedisenos basada en componentes predefinidos. Esta especificacion no solo busca mejorar ysimplificar el proceso de anadir componentes a una descripcion, sino que tambien buscamejorar la calidad del diseno especificado, ofreciendo una mayor posibilidad de configura-cion e incluso la posibilidad de informar de caracterısticas de la propia descripcion.

Reutilizar una componente ya descrito depende en gran medida de la informacion quese ofrezca para su integracion en un sistema. En este sentido los HDLs convencionalesunicamente proporcionan junto con la descripcion del componente la interfaz de entra-da/salida y un conjunto de parametros para su configuracion, mientras que el resto deinformacion requerida normalmente se acompana mediante documentacion externa. En lasegunda parte de la Tesis se propondran un conjunto de encapsulados cuya finalidad esincorporar junto con la propia descripcion del componente, informacion que puede resultarutil para su integracion en otros disenos. Incluyendo informacion de la implementacion,ayuda a la configuracion del componente, e incluso informacion de como configurar yconectar al componente para realizar una funcion.

iii

Finalmente se elegira una aplicacion clasica en el campo de procesado de senal, latransformada rapida de Fourier (FFT), y se utilizara como ejemplo de uso y aplicacion,tanto de las posibilidades de especificacion como de los encapsulados descritos. El objetivodel diseno realizado no solo mostrara ejemplos de la especificacion propuesta, sino quetambien se buscara obtener una implementacion de calidad comparable con resultados dela literatura. Para ello, el diseno realizado se orientara a su implementacion en FPGA,aprovechando tanto los elementos logicos generalistas como elementos especıficos de bajonivel disponibles en estos dispositivos. Finalmente, la especificacion de la FFT obtenidase utilizara para mostrar como incorporar en su interfaz informacion que ayude para suseleccion y configuracion desde fases tempranas del ciclo de diseno.

iv

Abstract

This PhD. thesis addresses the design and implementation of signal processing appli-cations using reconfigurable FPGA platforms. This kind of platform exhibits high logiccapability, incorporates dedicated signal processing elements and provides a low cost so-lution, which makes it ideal for the development of signal processing applications, whereintensive data processing is required in order to obtain high performance.

However, the cost associated to the hardware development on these platforms is high.While the increase in logic capacity of FPGA devices allows the development of completesystems, high-performance constraints require the optimization of operators at very lowlevel. In addition to time constraints imposed by these applications, Area constraintsare also applied related to the particular device, which force to evaluate and verify adesign among different implementation alternatives. The design and implementation cyclefor these applications can be tedious and long, being therefore normal that new FPGAmodels with a greater capacity and higher speed appear before completing the systemimplementation. Thus, the original constraints which guided the design of the systembecome useless.

Different methods can be used to improve the productivity when developing theseapplications, and consequently shorten their design cycle. This PhD. Thesis focuses onthe reuse of hardware components previously designed and verified. Although conventionalHDLs allow the reuse of components already defined, their specification can be improvedin order to simplify the process of incorporating new design components. Thus, a firstpart of the PhD. Thesis will focus on the specification of designs based on predefinedcomponents. This specification improves and simplifies the process of adding componentsto a description, but it also seeks to improve the quality of the design specified with betterconfiguration options and even offering to report on features of the description.

Hardware reuse of a component for its integration into a system largely depends onthe information it offers. In this sense the conventional HDLs only provide together withthe component description, the input/output interface and a set of parameters for its con-figuration, while other information is usually provided by external documentation. In thesecond part of the Thesis we will propose a formal way of encapsulation which aims to in-corporate with the component description information that can be useful for its integrationinto other designs. This information will include features of the own implementation, butit will also support component configuration, and even information on how to configureand connect the component to carry out a function.

Finally, the fast Fourier transform (FFT) will be chosen as a well-known signal pro-cessing application. It will be used as case study to illustrate the possibilities of porposed

v

specification and encapsulation formalisms. The objective of the FFT design is not onlyto show practical examples of the proposed specification, but also to obtain an imple-mentation of a quality comparable to scientific literature results. The design will focus itsimplementation on FPGA platforms, using general logic elements as base of the implemen-tation, but also taking advantage of low-level specific elements available on these devices.Last, the specification of the obtained FFT will be used to show how to incorporate inits interface information to assist in the selection and configuration process early in thedesign cycle.

vi

Indice general

1. Introduccion 1

1.1. FPGAs: Ventajas e inconvenientes . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Procesado de senal sobre FPGAs . . . . . . . . . . . . . . . . . . . . 3

1.2. El problema de la Productividad . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1. Reutilizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3. Objetivos de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.1. Estructura del Documento . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Antecedentes 9

2.1. Lenguajes para la reutilizacion de hardware . . . . . . . . . . . . . . . . . . 9

2.1.1. Alternativas a los HDLs tradicionales . . . . . . . . . . . . . . . . . 12

2.1.1.1. Lenguajes software . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1.2. Lenguajes especıficos de dominio . . . . . . . . . . . . . . . 16

2.1.1.3. Comparativa/Resumen . . . . . . . . . . . . . . . . . . . . 17

2.2. Enfoques de reutilizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3. Procesado de senal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.1. Clasificacion de implementaciones FFT . . . . . . . . . . . . . . . . 20

2.3.1.1. Cores FFT . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3. Fundamentos del enfoque de reutilizacion propuesto 25

3.1. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2. Encapsulado estructural y dHDL . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.1. Encapsulado estructural de cores VHDL . . . . . . . . . . . . . . . . 31

3.2.2. Cores dHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.3. dHDL, generacion y herramientas . . . . . . . . . . . . . . . . . . . 34

3.2.3.1. Generacion de codigo . . . . . . . . . . . . . . . . . . . . . 35

3.3. Encapsulados y empaquetado . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vii

3.3.1. Busqueda de alternativas . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.2. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4. Especificacion para la generacion dinamica de codigo 41

4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2. Ejemplos de codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3.1. Parametros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.2. Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.3. Macropuertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4. Especificacion para la generacion dinamica de hardware . . . . . . . . . . . 48

4.4.1. Estructuras de control . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.2. Declaraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.4.2.1. Variables (variable) . . . . . . . . . . . . . . . . . . . . . 50

4.4.2.2. Senales (signal) . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4.2.3. Puertos (port) . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4.2.4. Entidades (entity) . . . . . . . . . . . . . . . . . . . . . . 54

4.4.2.5. Componentes (component) . . . . . . . . . . . . . . . . . . 57

4.4.3. Inserciones de codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5. Ejemplos de diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.5.1. Filtro FIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.5.1.1. FIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.5.1.2. Multiplicador . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.5.2. Arbol de sumadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.5.2.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.5.2.2. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . 67

4.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5. Definicion de encapsulados para la reutilizacion 71

5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2. Encapsulado Estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.2.1. Definiciones (definitions) . . . . . . . . . . . . . . . . . . . . . . . 73

5.2.2. Parametros (parameters) . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.3. Atributos (attributes) . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2.4. Macropuertos (macroports) . . . . . . . . . . . . . . . . . . . . . . . 79

5.3. Encapsulado Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

viii

5.3.1. Declaracion de la funcion (function) . . . . . . . . . . . . . . . . . 83

5.3.2. Declaracion de caracterısticas (features) . . . . . . . . . . . . . . . 84

5.3.2.1. Refinamiento de la funcion . . . . . . . . . . . . . . . . . . 86

5.3.2.2. Seleccion de implementaciones . . . . . . . . . . . . . . . . 87

5.3.2.3. Configuracion de parametros . . . . . . . . . . . . . . . . . 88

5.3.2.4. Exploracion del espacio de diseno . . . . . . . . . . . . . . 88

5.3.3. Declaracion de entrada y salida (flows) . . . . . . . . . . . . . . . . 89

5.4. Empaquetado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.4.1. Configuracion del encapsulado estructural . . . . . . . . . . . . . . . 92

5.4.2. Verificacion de las caracterısticas implementadas . . . . . . . . . . . 94

5.5. Ejemplos de encapsulados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.5.1. Encapsulado de DSP Slices . . . . . . . . . . . . . . . . . . . . . . . 96

5.5.1.1. Encapsulado estructural: DSP48E . . . . . . . . . . . . . . 98

5.5.1.2. Encapsulado funcional: DSP48E . . . . . . . . . . . . . . . 101

5.5.1.3. Empaquetado . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.5.2. Filtros FIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.5.2.1. Encapsulado funcional: FIR . . . . . . . . . . . . . . . . . . 107

5.5.2.2. Encapsulado estructural: FIR . . . . . . . . . . . . . . . . . 108

5.5.2.3. Empaquetado . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6. Ejemplo de especificacion para procesado de senal: FFT 113

6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2. Fundamentos de la FFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2.1. Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2.2. Arquitecturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.2.2.1. Mariposa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.2.2.2. Rotadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6.2.2.3. Arquitectura Feedback . . . . . . . . . . . . . . . . . . . . 122

6.2.2.4. Arquitectura Feedforward . . . . . . . . . . . . . . . . . . . 125

6.3. Especificacion de arquitecturas con dHDL . . . . . . . . . . . . . . . . . . . 126

6.3.1. Arquitectura Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 127

6.3.1.1. Arquitectura FB: Encapsulado Estructural . . . . . . . . . 128

6.3.1.2. Arquitectura FB: Descripcion de la estructura . . . . . . . 131

6.3.1.3. Modulo de Memoria . . . . . . . . . . . . . . . . . . . . . . 135

6.3.1.4. Modulo Butterfly . . . . . . . . . . . . . . . . . . . . . . . 137

6.3.1.5. Modulo Rotador . . . . . . . . . . . . . . . . . . . . . . . . 140

ix

6.3.2. Arquitectura Feedforward . . . . . . . . . . . . . . . . . . . . . . . . 141

6.3.2.1. Arquitectura FF: Encapsulado Estructural . . . . . . . . . 142

6.3.2.2. Arquitectura FF: Descripcion de la estructura . . . . . . . 143

6.3.2.3. Modulo de Memoria . . . . . . . . . . . . . . . . . . . . . . 144

6.3.2.4. Modulo Butterfly . . . . . . . . . . . . . . . . . . . . . . . 145

6.3.2.5. Modulo Rotador . . . . . . . . . . . . . . . . . . . . . . . . 145

6.4. Resultados de la generacion de las arquitecturas descritas . . . . . . . . . . 146

6.4.1. Verificacion y resultados experimentales . . . . . . . . . . . . . . . . 147

6.4.2. Comparativa con otras alternativas . . . . . . . . . . . . . . . . . . . 150

6.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

7. Soporte a la exploracion del espacio de diseno 153

7.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

7.2. Generacion y estimacion de atributos . . . . . . . . . . . . . . . . . . . . . . 154

7.2.1. Estimacion de area . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

7.2.1.1. Mejora de la estimacion . . . . . . . . . . . . . . . . . . . . 160

7.2.1.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

7.2.2. Estimacion de consumo . . . . . . . . . . . . . . . . . . . . . . . . . 161

7.3. Exploracion de alternativas de implementacion . . . . . . . . . . . . . . . . 163

7.3.1. Receptor canalizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

7.3.2. Encapsulados y Empaquetado . . . . . . . . . . . . . . . . . . . . . . 164

7.3.2.1. Encapsulado funcional: FFT . . . . . . . . . . . . . . . . . 165

7.3.2.2. Empaquetado de la arquitectura FFT-FB . . . . . . . . . . 165

7.3.2.3. Empaquetado de la arquitectura FFT-FF . . . . . . . . . . 168

7.3.2.4. Empaquetado de la mariposa . . . . . . . . . . . . . . . . . 169

7.3.3. Exploracion de alternativas . . . . . . . . . . . . . . . . . . . . . . . 170

7.3.3.1. Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

7.3.3.2. Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

7.3.3.3. Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

7.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

8. Conclusiones 175

8.1. Conclusiones del trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . 175

8.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

8.3. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

x

Indice de Figuras

1.1. Figuras de la Presentacion en [Alf08]. . . . . . . . . . . . . . . . . . . . . . 2

1.2. Xilinx DSP Space, en [Bol06]. . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Mejora de la productividad segun Xilinx, en [Bol06]. . . . . . . . . . . . . . 5

1.4. Brecha diseno-productividad para FPGAs [WNH+08]. . . . . . . . . . . . . 5

2.1. Evolucion temporal de los lenguajes estandar HDL. . . . . . . . . . . . . . . 10

3.1. Instancia VHDL para DSP48E en Virtex-5: Parametros. . . . . . . . . . . . 26

3.2. Instancia VHDL para DSP48E en Virtex-5: Puertos. . . . . . . . . . . . . . 27

3.3. Espacio de diseno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4. Encapsulado estructural de un core VHDL. . . . . . . . . . . . . . . . . . . 31

3.5. Encapsulado estructural de cores VHDL. . . . . . . . . . . . . . . . . . . . . 32

3.6. Core dHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.7. Proceso de generacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.8. Biblioteca de encapsulados: proceso top-down. . . . . . . . . . . . . . . . . . 37

3.9. Biblioteca de encapsulados: proceso bottom-up. . . . . . . . . . . . . . . . . 37

3.10. Core dHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.11. Conjunto de encapsulados y empaquetado para el DSP48E. . . . . . . . . . 40

4.1. Estructura del ejemplo 4.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2. Ejemplo de biblioteca de componentes dHDL. . . . . . . . . . . . . . . . . . 55

4.3. Esquema del filtro FIR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4. Arquitectura generada del filtro FIR. . . . . . . . . . . . . . . . . . . . . . . 64

4.5. Esquema de arbol de sumadores para diferentes n. . . . . . . . . . . . . . . 66

5.1. Estructura del encapsulado estructural. . . . . . . . . . . . . . . . . . . . . 72

5.2. Encapsulado Estrutural. Definiciones. . . . . . . . . . . . . . . . . . . . . . 74

5.3. Encapsulado Estructural. Parametros. . . . . . . . . . . . . . . . . . . . . . 75

5.4. Encapsulado Estructural. Atributos. . . . . . . . . . . . . . . . . . . . . . . 77

5.5. Encapsulado Estructural: Macropuertos. . . . . . . . . . . . . . . . . . . . . 80

5.6. Estructura del encapsulado funcional. . . . . . . . . . . . . . . . . . . . . . 83

5.7. Encapsulado Funcional. Caracterısticas. . . . . . . . . . . . . . . . . . . . . 85

5.8. Encapsulado Funcional. Entrada y salida. . . . . . . . . . . . . . . . . . . . 90

5.9. Esquema de empaquetado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.10. XML Schema: Configuracion. . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.11. Esquema simplificado de un DSP48E. . . . . . . . . . . . . . . . . . . . . . 96

5.12. Conjunto de encapsulados y empaquetado para el DSP48E. . . . . . . . . . 98

xi

5.13. Ejemplos de aplicacion del DSP48E. . . . . . . . . . . . . . . . . . . . . . . 985.14. Esquema tap para FIR direct y transposed. . . . . . . . . . . . . . . . . . . 1055.15. Esquema FIR segundo orden con etapa directa y transpuesta. . . . . . . . . 1055.16. VHDL: Implementacion VHDL de etapa FIR directa. . . . . . . . . . . . . . 1065.17. VHDL: Implementacion FIR segundo orden. . . . . . . . . . . . . . . . . . . 106

6.1. Esquema FFT de 16 puntos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166.2. Arquitecturas para procesado continuo: descomposicion en etapas. . . . . . 1186.3. Estructura de una etapa para procesado continuo. . . . . . . . . . . . . . . 1186.4. Area requerida para implementar diferente radix. . . . . . . . . . . . . . . . 1216.5. Etapa de arquitectura FB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.6. Temporizacion arquitectura FB, N=1024 y R=4. . . . . . . . . . . . . . . . 1246.7. Etapa de arquitectura FF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.8. Temporizacion arquitectura FF, N=1024 y R=4. . . . . . . . . . . . . . . . 1266.9. Biblioteca de componentes para la arquitectura FB. . . . . . . . . . . . . . 1286.10. Generacion del top de la arquitectura FB. . . . . . . . . . . . . . . . . . . . 1326.11. Biblioteca de componentes para la arquitectura FF. . . . . . . . . . . . . . 1416.12. Area prestaciones de las arquitectura FF y FB. . . . . . . . . . . . . . . . . 1506.13. Consumo de las arquitectura FF y FB. . . . . . . . . . . . . . . . . . . . . . 150

7.1. Proceso de generacion y estimacion de area en una FFT. . . . . . . . . . . . 1567.2. Lımites de estimacion y error en la aproximacion para la arquitectura FB. . 1587.3. Lımites de estimacion y error en la aproximacion para la arquitectura FF. . 1597.4. Error en la estimacion de FFs y LUTs para diferentes implementaciones.

Arquitecturas FFT-FB y FFT-FF. . . . . . . . . . . . . . . . . . . . . . . . 1617.5. Esquema receptor canalizado. . . . . . . . . . . . . . . . . . . . . . . . . . . 1637.6. Alternativas del caso 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707.7. Alternativas del caso 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717.8. Alternativas del caso 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

xii

Indice de Tablas

1.1. FPGAs de Xilinx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1. Comparativa lenguajes HDL-RTL. . . . . . . . . . . . . . . . . . . . . . . . 18

6.1. Arquitectura FB. Numero de componentes. . . . . . . . . . . . . . . . . . . 1246.2. Arquitectura FF: Numero de componentes. . . . . . . . . . . . . . . . . . . 1266.3. Arquitectura FF: 8bits, R=2. . . . . . . . . . . . . . . . . . . . . . . . . . . 1486.4. Arquitectura FF: 8bits, R=4. . . . . . . . . . . . . . . . . . . . . . . . . . . 1486.5. Arquitectura FF: 8bits, R=8. . . . . . . . . . . . . . . . . . . . . . . . . . . 1486.6. Arquitectura FF: 8bits, R=4. . . . . . . . . . . . . . . . . . . . . . . . . . . 1496.7. Arquitectura FB y FF: 16 bits, R=4. . . . . . . . . . . . . . . . . . . . . . . 1496.8. Comparacion alternativas FFT de 1024 puntos y 16 bits, Radix-4. . . . . . 151

7.1. Resultados de implementacion y estimacion. Arquitecturas FB y FF. . . . . 162

xiii

Indice de Ejemplos

4.1. Especificacion de memoria ROM con VHDL. . . . . . . . . . . . . . . . . . 43

4.2. Especificacion de memoria ROM con dHDL. . . . . . . . . . . . . . . . . . . 43

4.3. Encapsulado estructural para el Ejemplo 4.2. . . . . . . . . . . . . . . . . . 44

4.4. dHDL: Cadena de operaciones Multiplica y Suma. . . . . . . . . . . . . . . 44

4.5. Codigo VHDL generado de la cadena de operaciones Multiplica y Suma: 1Etapa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.6. Declaracion de un parametro con funcion. . . . . . . . . . . . . . . . . . . . 45

4.7. Declaracion de un atributo e inicializacion a constante. . . . . . . . . . . . . 46

4.8. Declaracion de un macropuerto. . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.9. Agrupacion de senales entre macropuertos. . . . . . . . . . . . . . . . . . . . 47

4.10. Ejemplo de codigo generado sin agrupacion de puertos. . . . . . . . . . . . . 47

4.11. Ejemplo de codigo generado con agrupacion de puertos. . . . . . . . . . . . 47

4.12. Acceso a puerto interno del macropuerto. . . . . . . . . . . . . . . . . . . . 48

4.13. Estructura de control condicional if-else. . . . . . . . . . . . . . . . . . . . . 49

4.14. Estructura de control iterativa while y ejemplo de condiciones. . . . . . . . 49

4.15. Declaracion de variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.16. Declaracion de variables e inicializacion con llamada a funcion. . . . . . . . 51

4.17. Codigo generado por el Ejemplo 4.16. . . . . . . . . . . . . . . . . . . . . . 51

4.18. Declaracion de array de variables. . . . . . . . . . . . . . . . . . . . . . . . 52

4.19. Declaracion de senales dHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.20. Visibilidad de senales dHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.21. Declaracion de puertos dHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.22. Puertos de un macropuerto dHDL. . . . . . . . . . . . . . . . . . . . . . . . 54

4.23. Atributos dentro de un puerto dHDL. . . . . . . . . . . . . . . . . . . . . . 54

4.24. Declaracion de una entidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.25. Configuracion de la entidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.26. Acceso a los atributos de la entidad. . . . . . . . . . . . . . . . . . . . . . . 56

4.27. Configuracion, consulta de atributo y reconfiguracion de la entidad. . . . . . 56

4.28. Instancia de un adaptador dHDL. . . . . . . . . . . . . . . . . . . . . . . . . 57

4.29. Declaracion de un componente. . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.30. Acceso a propiedad del componente. . . . . . . . . . . . . . . . . . . . . . . 57

4.31. Instancia de componentes dHDL. . . . . . . . . . . . . . . . . . . . . . . . . 58

4.32. Instancia de componentes dHDL. . . . . . . . . . . . . . . . . . . . . . . . . 58

4.33. Insercion de codigo para declarar bibliotecas. . . . . . . . . . . . . . . . . . 59

4.34. Insercion de codigo para realizar declaraciones. . . . . . . . . . . . . . . . . 59

4.35. Insercion de codigo durante la descripcion del core. . . . . . . . . . . . . . . 59

4.36. Interfaz FIR: Parametros y atributos. . . . . . . . . . . . . . . . . . . . . . 61

xv

4.37. Interfaz FIR: Puertos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.38. Descripcion de la estructura del filtro. . . . . . . . . . . . . . . . . . . . . . 63

4.39. Descripcion de la estructura del filtro. . . . . . . . . . . . . . . . . . . . . . 63

4.40. Codigo dHDL para multiplicador por constante. . . . . . . . . . . . . . . . . 65

4.41. Arbol de sumadores. Declaracion de parametros y atributos. . . . . . . . . . 67

4.42. Arbol de sumadores. Declaracion de puertos. . . . . . . . . . . . . . . . . . 68

4.43. Multiplicadores. Descripcion de la estructura. . . . . . . . . . . . . . . . . . 69

4.44. Arbol de sumadores. Descripcion de la estructura. . . . . . . . . . . . . . . 69

5.1. Declaracion de un rango. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2. Declaracion de una union. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.3. Declaracion de un parametro. . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.4. Declaracion de un parametro con funcion. . . . . . . . . . . . . . . . . . . . 76

5.5. Declaracion de un atributo e inicializacion mediante una expresion. . . . . . 78

5.6. Declaracion de un atributo e inicializacion a constante. . . . . . . . . . . . . 78

5.7. Declaracion de un macropuerto. . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.8. Agrupacion de senales entre macropuertos. . . . . . . . . . . . . . . . . . . . 81

5.9. Declaracion de la funcion de un contador. . . . . . . . . . . . . . . . . . . . 84

5.10. Declaracion de caracterıstica. . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.11. Declaracion de las caracterısticas de un filtro. . . . . . . . . . . . . . . . . . 86

5.12. Declaracion de caracterıstica para clasificacion de implementaciones. . . . . 87

5.13. Declaracion de caracterıstica para la exploracion del espacio de diseno. . . . 89

5.14. Declaracion de caracterıstica. . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.15. Declaracion de un flujo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.16. Configuracion de un parametro a partir de una caracterıstica. . . . . . . . . 92

5.17. Configuracion de un parametro a partir de una caracterıstica pasada poruna funcion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.18. Configuracion de un parametro. . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.19. Verificacion de caracterıstica mediante funcion. . . . . . . . . . . . . . . . . 94

5.20. Verificacion de caracterıstica. . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.21. Verificacion de un flujo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.22. Encapsulado estructural DSP48E. Macropuertos. . . . . . . . . . . . . . . . 99

5.23. Encapsulado estructural DSP48E. Parametros. . . . . . . . . . . . . . . . . 100

5.24. Encapsulado estructural DSP48E: Atributos. . . . . . . . . . . . . . . . . . 101

5.25. Encapsulado funcional DSP48E. Suma. . . . . . . . . . . . . . . . . . . . . . 102

5.26. Encapsulado funcional DSP48E. Multiplicacion. . . . . . . . . . . . . . . . . 102

5.27. Flujo de datos para las funciones suma y multiplicacion. . . . . . . . . . . . 103

5.28. Empaquetado de la funcion suma mediante DSP48e. . . . . . . . . . . . . . 103

5.29. Empaquetado de la funcion multiplicacion mediante DSP48e. . . . . . . . . 104

5.30. Encapsulado funcional FIR. Suma. . . . . . . . . . . . . . . . . . . . . . . . 107

5.31. Flujo de datos para la funcion FIR. . . . . . . . . . . . . . . . . . . . . . . . 108

5.32. Encapsulado estructural FIR. Parametros. . . . . . . . . . . . . . . . . . . . 109

5.33. Encapsulado estructural FIR. Atributos. . . . . . . . . . . . . . . . . . . . . 109

5.34. Encapsulado estructural FIR. Macropuertos. . . . . . . . . . . . . . . . . . 109

5.35. Emapaquetado de la funcion FIR. . . . . . . . . . . . . . . . . . . . . . . . 110

6.1. FFT FB: Encapsulado estructural. Declaracion de parametros RADIX ySTAGES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

xvi

6.2. FFT FB: Encapsulado estructural. Parametros para el control de la anchurade bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.3. FFT FB: Encapsulado estructural. Declaracion de parametros. . . . . . . . 1306.4. FFT FB: Encapsulado estructural. Declaracion de atributos. . . . . . . . . . 1316.5. FFT FB: Encapsulado estructural. Declaracion de macropuertos. . . . . . . 1316.6. FFT FB: Descripcion de la estructura. . . . . . . . . . . . . . . . . . . . . . 1326.7. FFT FB: Descripcion de componentes de la biblioteca. . . . . . . . . . . . . 1336.8. FFT FB: Interconexionado de las etapas. . . . . . . . . . . . . . . . . . . . 1346.9. Modulo de memoria: Encapsulado estructural. Declaracion de parametros. . 1356.10. Modulo de memoria: Encapsulado estructural. Declaracion de atributos. . . 1366.11. Modulo de memoria: Estructura para la arquitectura FB. . . . . . . . . . . 1366.12. Modulo butterfly : Encapsulado estructural. Declaracion de parametros. . . . 1376.13. Modulo butterfly : Descripcion de la estructura. . . . . . . . . . . . . . . . . 1386.14. Modulo butterfly : Generacion de mariposas radix-2. . . . . . . . . . . . . . . 1386.15. Modulo butterfly : Generacion de multiplicadores. . . . . . . . . . . . . . . . 1396.16. Modulo butterfly : Reordenacion de las salidas. . . . . . . . . . . . . . . . . . 1396.17. Modulo rotador: Encapsulado estructural. Declaracion de parametros. . . . 1406.18. Modulo rotador: Seleccion del rotador. . . . . . . . . . . . . . . . . . . . . . 1406.19. Generacion de coeficientes twiddle. . . . . . . . . . . . . . . . . . . . . . . . 1416.20. FFT FF: Encapsulado estructural. Declaracion de macropuertos. . . . . . . 1426.21. FFT FF: Estructura de la estructura. . . . . . . . . . . . . . . . . . . . . . 1436.22. Modulo de memoria: Estructura para la arquitectura FF. . . . . . . . . . . 1446.23. Modulo rotador: Seleccion del rotador. . . . . . . . . . . . . . . . . . . . . . 1467.1. Declaracion de atributos de area en el encapsulado estructural. . . . . . . . 1577.2. Incorporacion de informacion de estimacion. . . . . . . . . . . . . . . . . . . 1587.3. Implementacion de estimadores de slices para arquitectura FB . . . . . . . 1607.4. Implementacion de estimadores de slices mejorado para arquitectura FB. . 1607.5. Encapsulado funcional FFT: Funcion y caracterısticas. . . . . . . . . . . . . 1667.6. Encapsulado funcional FFT: Flujos. . . . . . . . . . . . . . . . . . . . . . . 1667.7. Implementacion de la funcion FFT con la arquitectura FFT-FB. Empaque-

tado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667.8. Arquitectura FFT-FB. Implementacion de la funcion FFT: configuracion. . 1677.9. Arquitectura FFT-FB. Implementacion de la funcion FFT: verificacion. . . 1677.10. Arquitectura FFT-FF. Implementacion de la funcion FFT con la arquitec-

tura FFT-FF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1687.11. Arquitectura FFT-FF. Implementacion de la funcion FFT: configuracion. . 1687.12. Arquitectura FFT-FF. Implementacion de la funcion FFT: verificacion. . . 1697.13. Modulo butterfly: configuracion. . . . . . . . . . . . . . . . . . . . . . . . 169

xvii

Glosario

FPGA: Fully Programmable Gate Array. Dispositivos semiconductores cuyalogica e interconexionado pueden programarse.

LUT: Lookup Table. Estructura matricial que indexa operaciones o datos.

GPU: Graphics Processing Unit. Procesador grafico.

DSP: Digital Signal Processing. Representacion de senales en tiempo discretocomo una secuencia de numeros y se procesado.

ASIC: Application Specific Integrated Circuit. Circuito integrado disenado amedida para una aplicacion especıfica.

ASSP: Application Specific Standard Product. Circuito integrado disenado pa-ra un mercado amplio.

Core: Diseno hardware verificado, disponible para ser reutilizado.

IP: Core, pero con restricciones de licencia.

DFT: Discrete Fourier Transform. Transformada discreta para el analisis deFourier.

FFT: Fast Fourier Transform. Algoritmo eficiente de calculo de la DFT.

HDL: Hardware Description Language. Lenguajes para la descripcion de hard-ware.

dHDL: dynamic HDL. Lenguaje de generacion dinamina de hardware.

VHDL: VHSIC HDL. Lenguaje de descripcion hardware.

Verilog: Lenguaje de descripcion hardware.

RTL: Register Transfer Level. Nivel de abstraccion en diseno hardware dondese modelan flujos de senales entre registros, y operaciones logicas sobreestas senales.

TLM: Transaction Level Modeling. Modelado de alto nivel para la especifica-cion de sistemas.

SoC: System on Chip. Circuito integrado que integra todos los componentesde un sistema en un unico chip.

xix

VHPI: VHDL Procedural Interface. Interfaz estandar para el acceso a VHDLdesde C.

System Verilog: Lenguaje de descripcion hardware, que combina la descripcion de Ve-rilog y verificacion de alto nivel.

System C: Lenguaje de modelado y verificacion de sistemas.

DSL: Domain Specific Language. Lenguaje de programacion o especificacionde un dominio de aplicacion.

Java: Lenguaje de programacion de proposito general.

XML: Extensible Markup Language . Metalenguaje extensible de etiquetas quedefino por un conjunto de reglas.

XML-Schema: Lenguaje para describir de manera precisa la estructura y las restric-ciones de los contenidos de los documentos XML.

GUI: Graphical User Interface. Programa informatico que actua de interfazamigable de usuario.

FSM: Finite State Machine. Automata con un conjunto de estados y transi-ciones entre dichos estados finito.

FIR: Finite Impulse Response. Filtros digitales cuya respuesta a una senalimpulso de entrada tiene un numero finito de terminos no nulos.

IIR: Infinite Impulse Response. Filtros digitales cuya respuesta a una senalimpulso de entrada tiene un numero infinito de terminos no nulos.

ADC: Analog-to-Digital Converter. Dispositivo que convierte una senal con-tinua en el tiempo en una senal discreta.

xx

Capıtulo 1

Introduccion

1.1. FPGAs: Ventajas e inconvenientes

Durante la pasada decada las FPGAs han seguido fielmente la ley de Moore [Sch97],doblando su capacidad cada dieciocho meses. Este aumento en la capacidad ha permitidoque dejaran de utilizarse como dispositivos de prototipado para convertirse en un sustitutode los ASICs, sobre todo en aplicaciones con un volumen medio o bajo de tirada.

En la Tabla 1.1 se muestra no solo el aumento de la capacidad logica de estos dis-positivos de la marca Xilinx [Xila] con la aparicion de las nuevas familias, sino tambienel aumento de elementos integrados como son memorias y multiplicadores (DSP Slices),ası como la mejora de las prestaciones1. Con las nuevas familias de dispositivos no solose aumentan las capacidades y se mejoran las prestaciones, tambien se produce una me-jora en los elementos logicos, por ejemplo el paso de utilizar LUTs de 4 entradas a LUTsde 6 entradas con la Virtex-5, o la evolucion que han sufrido los DSPs integrados: des-de multiplicadores de 18×18 bits presentes en Virtex-2, hasta bloques que integran unmultiplicador de 25×18 bits, junto con una o mas ALUs.

Frente a los ASICs las FPGAs pueden resultar dispositivos no tan eficientes en termi-nos de velocidad, area o incluso consumo, sin embargo han alcanzado capacidades que

1En la tabla se resalta la mejora con la familia de dispositivos Virtex . En sombreado se han incluidootras familias de dispositivos de menor capacidad y prestaciones, pero tambien de menor coste.

Tabla 1.1: FPGAs de Xilinx.

Familia nm Logic Cells BRAM DSP Slices MHz

Spartan-3 - 74880 4L 4.8Mb 104 18x18 -

Virtex-2 150nm 93000 4L 4.5Mb 168 18x18 420MHz

Virtex-4 90nm 200000 10.0Mb 512 XDSP 500MHz

Virtex-5 65nm 330000 6L 16.4Mb 1056 DSP48E 550MHz

Spartan-6 45nm 150000 4.8Mb 180 DSP48A1 400MHz

Virtex-6 40nm 760000 38.0Mb 2016 DSP48E1 600MHz

Artix-7 - 352000 19.0Mb 1040 650MHz

Kintex-7 - 480000 34.0Mb 1920 650MHz

Virtex-7 28nm 2000000 68.0Mb 3600 DSP48E1 650MHz

2 Introduccion

(a) Capacidad (b) Prestaciones

(c) Consumo (d) Precio

Figura 1.1: Figuras de la Presentacion en [Alf08].

permiten el desarrollo de aplicaciones complejas y sofisticadas. Ademas ofrecen una granflexibilidad, ya que permiten la implementacion y prueba de diferentes versiones de unamisma aplicacion, permitiendo a los disenadores realizar modificaciones hasta el ultimomomento antes del lanzamiento del producto, e incluso el desarrollo de nuevas versionesy correcciones una vez que el producto ha sido lanzado.

En la Figura 1.1 se presentan un conjunto de transparencias extraıdas de la presenta-cion en [Alf08], donde se muestran la evolucion y la tendencia de diversas caracterısticasde estos dispositivos.

La Figura 1.1(a) muestra el progresivo aumento en la capacidad y las expectativasde crecimiento para despues de 2012. La escala del eje de las ordenadas se encuentraen unidades logarıtmicas.

La Figura 1.1(b) muestra la tendencia en la mejora de las prestaciones, de nuevo conuna proyeccion hacia el futuro.

La Figura 1.1(c) muestra como se espera mantener un bajo consumo en parte graciasa la bajada de la tension de alimentacion de los dispositivos, posible en las nuevastecnologıas.

1.1 FPGAs: Ventajas e inconvenientes 3

Figura 1.2: Xilinx DSP Space, en [Bol06].

En la Figura 1.1(d) se observa como el coste por unidad logica se ha reducido drasti-camente durante la pasada decada.

Todas estas caracterısticas convierten a estos dispositivos en un serio competidor frentea dispositivos como ASICs y ASSPs. Esta mejora no solo permite el desarrollo de apli-caciones cada vez mas complejas, sino que va acompanada de un abaratamiento de losdispositivos por lo que ofrecen una plataforma cada vez mas barata y versatil para laimplementacion de los disenos.

Si frente a los ASICs no resultan tan eficientes, sı que son capaces de mejorar lasprestaciones de sistemas basados en procesador, tanto de proposito general como de pro-cesado de senal, y en algunos casos en varios ordenes de magnitud. Sin embargo, pese a lasmejores prestaciones que pueden ofrecer su utilizacion no se ha extendido de manera gene-ralista, e incluso han encontrado un duro competidor: las GPUs. En [Sti11] se analizan lascausas por las que a pesar de las ventajas que ofrecen los dispositivos FPGA frente a losmicroprocesadores, no han sido capaces de extender su uso frente a este tipo de circuitos.

Una razon es el propio coste del dispositivo y las placas de desarrollo. Si bien el costeasociado al desarrollo en una FPGA es menor que el de un ASIC, el coste comparado conel de una GPU es mucho mayor.

Otra razon expuesta en [Sti11] es que no todas las aplicaciones se pueden adaptar parasu implementacion en FPGA. Una de las caracterısticas deseables de las aplicaciones paraFPGA es que pueda extraerse suficiente paralelismo, de modo que compense la menorfrecuencia de trabajo respecto a los sistemas basados en microprocesador. Para obteneraltas prestaciones en estos dispositivos, a pesar de la baja frecuencia de reloj que ofrecencomparada con los sistemas procesadores, las aplicaciones se deben disenar para ejecutarcientos e incluso miles de operaciones simultaneamente en un unico ciclo. Aunque estegrado de paralelismo se puede obtener de diversas maneras, el diseno de pipelines es unade las tecnicas mas extendidas.

1.1.1. Procesado de senal sobre FPGAs

Por lo expuesto anteriormente, a pesar de la mejora gradual en las caracterısticas delos dispositivos FPGA, no es una plataforma optima para la implementacion de cualquier

4 Introduccion

aplicacion. En la Figura 1.2, extraıda del keynote en [Bol06], se realiza una clasificacionde diferentes campos de aplicacion en funcion del numero de ciclos requerido para proce-sar una muestra. En un extremo de la grafica se situan aplicaciones denominadas comocontrol, y que requieren de un elevado numero de ciclos para procesar cada muestra. Enel otro extremo de la grafica se encuentran aplicaciones de procesado de senal como soncomunicaciones y radar, asociadas a calculos intensivos sobre un flujo de datos, y quenormalmente requieren un procesado continuo del orden de una muestra por ciclo.

Mientras que aplicaciones de tipo control pueden implementarse en procesadores deproposito general, a medida que aumentan los requisitos de computo y se le asocian re-quisitos de tiempo real, son necesarias plataformas adaptadas al algoritmo de procesadoen particular. Ası, aplicaciones de procesado de senal del tipo comunicaciones o radar,requieren plataformas especıficas que en la actualidad solo las proporcionan FPGAs oASICs. La utilizacion de ASICs queda restringido a aplicaciones con un elevado volumende produccion por su alto coste de fabricacion. Por contra las FPGAs resultan menos cos-tosas y su flexibilidad les dota de un grado de libertad adicional al poderse reconfiguraren numerosas ocasiones.

Las FPGAs son por lo tanto una plataforma idonea para el desarrollo de sistemasdigitales complejos, y en concreto de aplicaciones de procesado de senal. Muchas de estasaplicaciones se caracterizan por una carga computacional intensiva y que permiten para-lelizar su procesado. En esta Tesis nos centraremos en aquellas aplicaciones de procesadode senal que mejor se adaptan a las caracterısticas de la FPGA: aplicaciones con unaelevada concurrencia, que requieren de un procesado continuo y que presentan requisitosde tiempo real duro, que se corresponden con las aplicaciones de altas prestaciones de laFigura 1.2.

La implementacion de estas aplicaciones impone restricciones temporales de procesado,que a medida que se vuelven mas exigentes requieren del uso eficiente de las caracterısti-cas de los dispositivos FPGA (capacidad, paralelismo, componentes de bajo nivel) paracumplirlos, lo que se traduce en una fase de diseno especialmente compleja. En concretoson necesarios disenadores expertos con conocimientos profundos del algoritmo y de lasarquitecturas sobre las que se implementa el algoritmo, lo que conlleva ciclos de disenoexcesivamente prolongados. Por ello surge la necesidad de buscar tecnicas de mejora la deproductividad, como se vera a continuacion.

1.2. El problema de la Productividad

Una ultima barrera mencionada en [Sti11] la determina la productividad, limitada porla complejidad asociada al propio desarrollo de las aplicaciones, junto con las deficienciasdel conjunto de herramientas disponibles. En la Figura 1.3, tambien del keynote presentadoen [Bol06], representa como para mejorar la productividad en estos dispositivos es necesarioun cambio en las herramientas y flujos de diseno tradicionales. En la presentacion seestablece la reutilizacion como uno de los puntos clave para obtener una mejora de laproductividad. Los disenos ya realizados deben poder adaptarse a nuevas aplicaciones yplataformas. Ademas, las herramientas deben dar soporte a una rapida exploracion delespacio de diseno, ası como simplificar la creacion o composicion de un sistema.

1.2 El problema de la Productividad 5

Figura 1.3: Mejora de la productividad segun Xilinx, en [Bol06].

Figura 1.4: Brecha diseno-productividad para FPGAs [WNH+08].

Las FPGAs, al igual que los ASICs, sufren de la brecha diseno-productividad (designproductivity gap), efecto analizado en profundidad en [NWH+08]. Esta brecha se debea que hasta hoy en dıa las capacidades de integracion se doblan cada dieciocho mesessiguiendo la ley de Moore, mientras que las capacidades de diseno lo hacen mucho maslentamente, como se representa en la Figura 1.4.

La mejora de la productividad se puede abordar desde diferentes perspectivas. Unaprimera perspectiva es mejorar las propias herramientas. Acompanando al aumento delas capacidades de integracion, tambien se ha producido un aumento en el tamano de losdisenos, con lo que su implementacion puede tomar horas e incluso dıas. Dado el caracteriterativo del diseno hardware, una mejora en las herramientas que reduzca el tiempo deimplementacion repercute directamente en la propia productividad.

Otra opcion para mejorar la productividad es incrementar el grado de abstraccion enla descripcion de los disenos. El aumento en el grado de abstraccion permite desarrollarsistemas cada vez mas complejos, aunque a costa de una menor eficiencia en la implemen-tacion. Volviendo a recordar la Figura 1.2, en este trabajo nos centraremos en aplicacionesde muy altas prestaciones, en las que esta perdida de eficiencia puede resultar inaceptable.

1.2.1. Reutilizacion

Finalmente, una ultima y mas eficaz opcion para mejorar la productividad es la reutili-zacion. Por tanto es importante disponer de bibliotecas de disenos reutilizables hardware,habitualmente denominados cores o IP (Intellectual Property), que implementen funcionesespecıficas, perfectamente caracterizados para que puedan ser reutilizados en diferentes

6 Introduccion

aplicaciones [Gaj99]. La utilizacion de estos cores permite agilizar el proceso de cons-truccion de un sistema hardware basandose en disenos anteriores, con unas prestacionesconocidas y que ya han sido verificados, reduciendo considerablemente el tiempo requeridopara lanzar el producto al mercado (time to market) y permitiendo ofrecer soluciones deuna mayor calidad.

La propia implementacion de un diseno hardware es una tarea costosa, pero si puedeser reutilizado en diferentes aplicaciones se amortiza sustancialmente el coste de su desa-rrollo. Por lo tanto es deseable que los disenos reutilizables no solo implementen la funcionpara la que estan disenados, sino que ofrezcan un cierto grado de libertad en su configu-racion, de forma que permitan su adaptacion a diferentes aplicaciones. Para lograr esto,el disenador de cores debe disponer de lenguajes de descripcion hardware y herramientas,que simplifiquen el diseno de cores parametrizables, pero que no sacrifiquen la calidad delresultado final. En este sentido, los lenguajes de descripcion tradicionales, como VHDL[Per93] o Verilog [Bha97], presentan alguna caracterıstica basica para su generalizacion,pero que ofrecen unas capacidades muy limitadas para permitir pequenas variaciones enel diseno. Los lenguajes concebidos para describir hardware deben a su vez potenciar lareutilizacion, mejorando los mecanismos que simplifiquen la propia integracion de cores,pero que a su vez permitan la implementacion de disenos eficientes.

Otro de los problemas de utilizar estos cores es que para la implementacion de unafuncion o algoritmo determinado es posible encontrar diversas alternativas. El disenadordel sistema debe evaluar y seleccionar entre diferentes implementaciones o puntos delespacio de diseno para que el producto final cumpla con las restricciones de la aplicacionpara la que se disena: normalmente las mejores prestaciones al menor coste.

La tarea de busqueda y seleccion de posibles implementaciones no es trivial. Durante labusqueda de alternativas pueden encontrarse versiones implementadas en diversos HDLs,que presenten diferentes arquitecturas (con distintas posibilidades de parametrizacion).Incluso la entrada/salida que ofrecen sera caracterıstica de cada core: para realizar lamisma funcion es comun que presenten diferentes nomenclatura y caracterısticas de tem-porizacion. Ademas, la busqueda de alternativas puede pasar por alto implementacionesque, aunque a priori no se hayan disenado para la funcion buscada, pueden adaptarse pararealizar dicha funcion.

Finalizada la busqueda de alternativas, la seleccion de que implementacion es la optimapara la aplicacion tampoco esta exenta de problemas: para poder seleccionar entre lasalternativas resultara necesario evaluar diferentes caracterısticas como area, prestaciones,consumo, etc., lo que de nuevo es una tarea costosa, ya que hace necesario un estudiomas en profundidad de las propias implementaciones. En este caso, disponer no solo de laspropias implementaciones, sino de herramientas que permitan una rapida exploracion delespacio de diseno pueden ayudar en esta tarea de seleccion, a pesar de que a veces resultacomplicado comparar entre alternativas.

Tras todo el proceso de busqueda y seleccion, puede llegarse a la conclusion de queninguna implementacion es adecuada para el sistema, o, en el caso de que se integre, que elcoste de su integracion pueda ser superior al de una implementacion desde cero. En estassituaciones los inconvenientes de la reutilizacion de cores superan sus ventajas.

1.3 Objetivos de la Tesis 7

En este contexto, este trabajo se ha orientado a:

1. Facilitar la especificacion de disenos hardware eficientes y reutilizables.

2. Dar soporte al desarrollo de herramientas que ayuden a simplificar el diseno desistemas orientados al procesado de senal sobre plataformas reconfigurables.

En concreto, se da soporte a la exploracion del espacio de diseno, de manera que puedarealizarse desde las primeras etapas del ciclo de diseno, permitiendo al disenador evaluarentre el mayor numero posible de alternativas y seleccionar un conjunto limitado sobre elque realizar la comparacion mas exhaustiva. Ademas, es importante que los detalles deimplementacion de bajo nivel queden ocultos, para lo que el disenador hardware del coredebe disponer de recursos y herramientas que no solo le permitan implementarlo, sinoofrecer la informacion necesaria al disenador de sistemas.

1.3. Objetivos de la Tesis

El proposito principal de esta Tesis Doctoral es aumentar la productividad en el disenode aplicaciones de procesado de senal sobre FPGAs. Como se ha mencionado anteriormen-te, uno de los pilares para incrementar esta productividad es la reutilizacion de disenos,aspecto que aborda esta Tesis mediante la ayuda a la especificacion eficiente de estructurasy encapsulados. Para ello, se plantean los siguientes objetivos:

Primero se desarrollara un lenguaje que simplifique la descripcion de un core comocomposicion de disenos reutilizables, facilitando el proceso de integracion e interco-nexion. El lenguaje esta orientado a la generacion de codigo sintetizable, y a mejo-rar las capacidades de parametrizacion del core descrito, permitiendo ası su futuraadaptacion a nuevas aplicaciones. Uno de los objetivos adicionales de este lenguajees proporcionar informacion sobre el hardware descrito en el codigo generado. Es-ta informacion puede ser utilizada como base para una exploracion del espacio dediseno.

En segundo lugar se definiran encapsulados orientados a potenciar la reutilizacionde cores. La definicion de estos encapsulados da soporte a la mejora de la informa-cion que pueden ofrecer los disenos, y por lo tanto ayudan al disenador de sistemasen la tarea de busqueda, evaluacion y seleccion de alternativas. Con el conjunto deencapsulados propuestos se busca dar soporte a la automatizacion de tareas rela-cionadas con la reutilizacion de componentes, como la seleccion y configuracion decomponentes, pero tambien dan soporte a la implementacion de herramientas parala exploracion del espacio de diseno o la exploracion de alternativas.

Esta Tesis se centra en aplicaciones de procesado de senal, que requieren de platafor-mas FPGA cuando la aplicacion demanda altas prestaciones. El enfoque presentadoen los puntos anteriores se validara mediante la especificacion de una aplicacion tra-dicional en el procesado de senal: la FFT. Se utilizaran el lenguaje y encapsuladospropuestos para describir arquitecturas de FFT orientadas a aplicaciones de muyaltas prestaciones y procesado continuo, y que normalmente presentan restriccionesde tiempo real duro.

8 Introduccion

Finalmente se mostrara como apoyandose en el lenguaje y los encapsulados, y hacien-do uso de las arquitecturas FFT especificadas, es posible dar soporte a la exploraciondel espacio de diseno. Por una parte mediante el desarrollo de estimadores junto conla propia especificacion de las arquitecturas FFT realizadas, y por otra parte me-diante el uso de los encapsulados que permiten simplificar el proceso de seleccion dealternativas.

1.3.1. Estructura del Documento

Este documento se ha organizado como sigue. En el siguiente capıtulo se realizara unadescripcion de los trabajos relacionados con la Tesis. Los trabajos relacionados se handividido en dos grandes grupos, el primero cubre trabajos relacionados con los lenguajesde especificacion hardware y reutilizacion de cores. El segundo conjunto de trabajos serelacionan con el campo de procesado de senal, y en concreto con la implementacion de laFFT, que se ha elegido como ejemplo para la especificacion de procesado de senal.

Tras revisar los antecedentes, en el capıtulo 3 se justificara el enfoque de reutilizacionplanteado en esta Tesis y se introduciran los elementos que la componen y como se relacio-nan. El primer elemento que se aborda es el lenguaje dHDL, que se describira en detalleen el capıtulo 4, lenguaje concebido para ayudar y simplificar en la generacion de coreshardware. En el capıtulo 5 se describiran los encapsulados desarrollados con el objetivo demejorar la reutilizacion de cores. Un primer encapsulado, denominado estructural, que im-plementa la interfaz del lenguaje dHDL. Ademas, se propone un segundo encapsulado queproporciona una interfaz funcional, que se encuentra desligada de las implementacionesconcretas.

Una vez establecidas las bases del enfoque de reutilizacion propuesto (lenguaje dHDLy encapsulados), en el capıtulo 6 se presenta un ejemplo avanzado de descripcion paraprocesado de senal, la transformada rapida de Fourier o FFT. En este capıtulo, se reali-zara en primer lugar la especificacion de diferentes arquitecturas de FFT utilizando dHDL.En segundo lugar, se describiran la interfaz de las arquitecturas utilizando el encapsuladoestructural, de forma que se ofrezcan las mejores posibilidades de configuracion. Puestoque el objetivo del diseno dentro del campo de procesado de senal son aplicaciones de altasprestaciones, finalmente se validara la arquitectura descrita con resultados experimentales.

En el capıtulo 7 se mostrara como el uso del lenguaje dHDL y de los encapsuladospropuestos, utilizando el ejemplo de la FFT, permiten potenciar la reutilizacion mediantediferentes aplicaciones. Primero, se muestra como incorporar la informacion obtenida en losresultados experimentales a la propia descripcion dHDL del core, permitiendo construirestimadores sencillos. En segundo lugar se describe como los encapsulados propuestosfacilitan la realizacion de una rapida exploracion de alternativas. Finalmente, se extraeranlas conclusiones del trabajo realizado.

Capıtulo 2

Antecedentes

El trabajo realizado en esta Tesis Doctoral se ha centrado en la especificacion de hard-ware para su reutilizacion en el contexto especıfico de aplicaciones de procesado de senalsobre dispositivos reconfigurables (FPGAs). Debido a que se tratan varias tematicas (FP-GAs, reutilizacion, procesado de senal) para los antecedentes ha sido necesario consultaren campos diferentes. En este capıtulo se realiza una breve revision de los trabajos rela-cionados con las tematicas principales de la Tesis. En concreto, se han estructurado estosantecedentes en los siguientes campos principales:

Lenguajes para la especificacion y reutilizacion de hardware. Una de las contribucio-nes de la Tesis es la definicion de un lenguaje de especificacion para la reutilizacion,por lo que se van a estudiar en profundidad las capacidades de los lenguajes de des-cripcion hardware convencionales (HDLs) y otras propuestas que se hayan realizado,como puede ser la especificacion basada en XML.

Enfoques diversos orientados a la reutilizacion de hardware. Se revisaran trabajos querealizan propuestas metodologicas o contribuciones que van mas alla de la definicionde un lenguaje.

Procesado de senal. Dado que el objetivo es aplicar tecnicas de especificacion hard-ware para el campo de procesado de senal se han estudiado tambien trabajos relacio-nados en este campo. Y se ha dedicado un espacio especial a las implementacionesprevias de FFT, puesto que se busca especificar hardware para procesado de senalde altas prestaciones. En concreto, se revisaran aquellas implementaciones de FFTque permitan obtener las mejores prestaciones en FPGAs y que sean comparables alos resultados que se obtienen en esta Tesis.

A continuacion se desarrollaran cada uno de estos campos de revision de trabajo rela-cionado.

2.1. Lenguajes para la reutilizacion de hardware

La Figura 2.1 muestra la evolucion temporal de los lenguajes que se han convertidoen estandar HDL (Hardware Description Language). En la parte inferir de las flechas seindican las fechas de aparicion de los lenguajes, y en la superior las fechas de publicacion

10 Antecedentes

Figura 2.1: Evolucion temporal de los lenguajes estandar HDL.

de los estandares. En esta seccion se revisaran este conjunto de lenguajes, ası como laaparicion de alternativas orientadas a mejorar la productividad en el diseno hardware.

VHDL fue desarrollado por el Departamento de Defensa de Estados Unidos (1981) conel objetivo de unificar la descripcion del comportamiento que los proveedores de ASICsincluıan en los equipamientos. Este lenguaje permitıa la simulacion del comportamientodescrito, y rapidamente se comenzaron a desarrollar herramientas de sıntesis que a partirde VHDL generaban una implementacion fısica del circuito. El lenguaje se adopta comoun estandar IEEE (1076), con su primera version VHDL’87. Tras su estandarizacion secomienzan a desarrollar herramientas para el desarrollo de hardware con este lenguaje, yaparecen multiples libros y manuales [Edi90], [Bha92], [Per93], [Per02].

En paralelo aparecio Verilog [Bha97] (1984), lenguaje de caracterısticas similares aVHDL, pero desarrollado como lenguaje propietario de una empresa (GAD). En 1990,Cadence compro la empresa y comenzo a trabajar en herramientas para dar soporte aldesarrollo con este lenguaje. Debido a que su uso estaba limitado por su caracter propie-tario, decide abrirlo y en 1995 se convierte en un nuevo estandar IEEE (1364) [IEE05]. Enesas fechas VHDL sufre su primera revision, y se desarrolla la version VHDL’93 (1994),[IEE93].

En esos momentos el diseno hardware mediante HDLs ya comienza a trazar las basespara el diseno modular y jerarquico con el objetivo de mejorar la productividad, y seplantea por primera vez el concepto de reutilizacion. En [GC93] se describe el flujo dediseno hardware como un conjunto de iteraciones, donde en cada iteracion se parte de

2.1 Lenguajes para la reutilizacion de hardware 11

un diseno con un alto grado de abstraccion (core RTL) a partir de la cual se genera unaimplementacion.

La reutilizacion permite que no todo el diseno tenga que generarse de la nada, sino queaprobecha bloques que no solo se encuentran ya disenados sino que han sido probados,reduciendo con ello el numero de iteraciones para alcanzar la implementacion final.

Pero para que un bloque pueda ser reutilizado de una manera efectiva debe cumplircon varias caracterısticas, como por ejemplo que su funcion pueda adaptarse a diferentesaplicaciones, que sea configurable y finalmente que sea de buena calidad. En [PHSMR95] sedescriben las posibilidades de VHDL como lenguaje para la reutilizacion: describir corescon el objetivo de que sean reutilizables. Para ello propone utilizar las caracterısticasdel lenguaje (VHDL) que permiten su parametrizacion, con el objetivo de generar unabiblioteca de componentes verificados.

Sin embargo, parte de las limitaciones que se encuentran en la reutilizacion de coresdescritos en estos lenguajes se deben a sus propias caracterısticas. Por ejemplo, [Zhu01]expone que mientras que los HDLs convencionales proporcionan los mecanismos basicospara la reutilizacion a bajo nivel, a medida que la complejidad del componente aumenta,la falta de informacion de la implementacion obliga a gastar tiempo en consultar lascaracterısticas del core o IP (data sheet), e implementar una interfaz especıfica. Si sedesea cambiar el componente por otro de funcionalidad similar es necesario redisenar todala interfaz.

Los HDLs convencionales, aunque permiten cierta parametrizacion y disponen de es-tructuras muy limitadas que generan hardware dinamico, no disponen de la flexibilidadsuficiente como para que un disenador pueda explotar todo su potencial. Su reutilizacionno solo viene limitada por la propia definicion de tipos y estructuras de generacion, sinotambien por la falta de realimentacion de como el cambio de parametros afecta a la es-tructura descrita. Por ello es necesario acompanar el core con documentacion externa queno solo describa el uso de los parametros, sino que tambien detalle la propia estructurainterna y detalles de temporizacion.

Parte de la limitacion de los HDLs clasicos en la reutilizacion se debe a que no describenuna funcionalidad, sino una implementacion concreta de una funcion. Ası, a finales de los90 comienzan a aparecer propuestas para la descripcion hardware con lenguajes basadosen C, como por ejemplo en [SCV+99]. En esta propuesta la reutilizacion se debe basar enla funcionalidad frente a los HDLs convencionales donde la implementacion suele realizaruna descripcion estructural y su interfaz esta condicionada por la implementacion, que selimita a especificar la interaccion entre la entrada/salida con el comportamiento descritoen el diseno.

Frente a los HDL convencionales, lenguajes como C/C++ no solo permiten realizar unadescripcion de la funcion sino que permiten describir la interaccion entre diferentes bloquesde un sistema. En esta lınea surge SystemC en 2000 [Pan01], que en 2005 se convertira enun nuevo estandar IEEE (1666) [IEE11a], o alternativas como SystemVerilog [Fit04], quetambien se incorporara como estandar IEEE (1800) [IEE11b].

Estos lenguajes proponen mejorar la productividad en el desarrollo de sistemas hard-ware aumentando el grado de abstraccion. Frente al diseno RTL utilizado en los HDLsconvencionales, donde el comportamiento de un circuito es descrito mediante la transfe-rencia de informacion y operaciones logicas entre registros hardware, se define el diseno

12 Antecedentes

TLM como un modelado de alto nivel [Ghe06]. En TLM los detalles de comunicacion entremodulos se encuentran separados de los detalles de implementacion de las unidades funcio-nales. Los mecanismos de comunicacion se encuentran modelados mediante canales, quese centran en describir la funcionalidad, dejando en un segundo plano la implementacion.Aunque estos lenguajes se basan en bibliotecas que permitan el modelado de hardware ysoftware, solo un subconjunto puede ser sintetizado, y el proceso de refinamiento desde elmodelado de sistema (TLM) al implementable (RTL) requiere de un considerable esfuerzopor parte del disenador.

El trabajo con lenguajes como SystemC o SystemVerilog permite simplificar el pro-ceso de especificacion y definicion de sistemas, y la interrelacion entre los bloques que loforman. Gran parte del trabajo se ha orientado a la descripcion de mecanismos para la co-municacion de bloques [KJRN03], frente a las implementaciones con HDLs convencionalesdonde cada core define mecanismos de comunicacion y sincronizacion propios.

Uno de los campos donde mas exito han tenido estos lenguajes ha sido en la especi-ficacion de SoC (System on chip) [CGL04]: sistemas complejos compuestos por multiplesbloques, donde cada bloque implementa una funcion, interconectados por canales estandar.Su descripcion permite una rapida especificacion y definicion, basada en la funcionalidadde los bloques y canales de comunicacion estandar, ademas de una rapida simulacion.

Los HDLs convencionales lejos de desaparecer, continuaron su desarrollo: VHDL-2000y VHDL-2002, o Verilog-2005. Frente a propuestas como SystemC o SystemVerilog, losHDL convencionales siguen siendo los mas utilizados por la industria, ya que por una partedisponen de un flujo de diseno asentado y probado, y por otra parte, aunque se puedenalcanzar implementaciones desde las descripciones con los lenguajes de alto nivel, siguensin resultar tan eficientes como las descripciones con los HDLs convencionales [XSAH10].

Las ultimas versiones de los HDL convencionales buscan unir la especificacion a altonivel con la eficiencia del bajo nivel, como por ejemplo VHDL’06-08 con la introduccion deVHPI (VHDL Procedural Interface) o directamente la union de Verilog con SystemVerilogen un unico estandar (2008).

2.1.1. Alternativas a los HDLs tradicionales

Una de las caracterısticas de los HDLs convencionales es la posibilidad de realizardescripciones con diferentes niveles de abstraccion, permitiendo tanto descripciones com-portamentales como descripciones estructurales. Esta caracterıstica presenta ventajas einconvenientes, por ejemplo, permiten utilizar el mismo lenguaje tanto para especificar undiseno y los ficheros para realizar su verificacion. Sin embargo no todas las descripcionesrealizadas con el lenguaje tienen que ser implementables, lo que requiere de un esfuerzopor parte del disenador en el aprendizaje del lenguaje. La descripcion estructural resultaespecialmente util cuando se realizan disenos basados en otros disenos, y forma la basepara la reutilizacion de componentes.

Otra de las caracterısticas de los HDLs es la posibilidad de parametrizar los disenos.Esta es una tecnica basica para generalizar los disenos descritos con estos lenguajes ypoder adaptarlos a nuevas aplicaciones. Las posibilidades de parametrizacion de estoslenguajes estan orientadas a modificar la anchura de bit de los datos con los que trabaja elcomponente, aunque tambien permiten controlar hasta cierto grado la generacion dinamica


de la estructura descrita.

Los HDLs proporcionan junto con la implementacion una interfaz que define tantolos puertos para la comunicacion con otros modulos como los propios parametros delcomponente. La declaracion de esta interfaz resulta en muchas ocasiones insuficiente ala hora de reutilizar los disenos realizados con estos componentes, por lo que se suelenacompanar de documentacion externa en forma de hojas de caracterısticas.

Finalmente, una de las grandes ventajas de utilizar estos HDLs es el numero de he-rramientas disponibles, capaces de sintetizar hardware de manera eficiente a partir dedescripciones RTL en dichos lenguajes. Ademas, los fabricantes de dispositivos suelenproporcionar herramientas para trabajar con estos lenguajes, proporcionando soporte es-pecıfico para acceder a elementos de bajo nivel disponibles en los dispositivos.

A pesar de lo extendido de su uso en la industria, han aparecido alternativas que bus-can mejorar las caracterısticas de los HDLs tradicionales a la hora de describir hardwarereutilizable. En este apartado primero se revisaran propuestas basadas en el uso de len-guajes tradicionalmente software, para despues pasar a revisar propuestas con lenguajesespecıficos.

2.1.1.1. Lenguajes software

C/C++

C/C++ ha sido utilizado intensivamente como lenguaje hardware. En [Mic99] o en[Edw05] se pueden encontrar estudios donde se analizan y resumen un conjunto de estaspropuestas.

La razon principal por la que se ofrece este lenguaje para la especificacion de hardwarees la familiaridad, ya que permitirıa que un programador software se convierta en undisenador hardware. Otra ventaja se obtiene en el codiseno hardware/software, ya quepermite utilizar un unico lenguaje para especificar un sistema mixto.

Entre las propuestas analizadas se encuentran Handel-C de Celoxica [ASRW96, SWC04],SpecC [GZD+00, FN01], CASH [BG02] o incluso System-C [Pan01].

Una de las principales dificultades que encuentran estas propuestas a la hora de des-cribir hardware es la concurrencia, puesto que C/C++ es un lenguaje optimizado paraexpresar algoritmos secuenciales. Por este motivo los programadores en estos lenguajesdeben utilizar construcciones paralelas, ya sea mediante procesos o mediante bloques.

La temporizacion es otro de los problemas que es necesario solucionar en las pro-puestas anteriores. La mayorıa de las propuestas generan hardware sıncrono, por lo tantodeben incluir mecanismos que dividan el tiempo en ciclos de reloj. Las soluciones incluyenanotaciones y reglas implıcitas.

Junto con el uso del C/C++ como lenguaje hardware, tambien se encuentran propues-tas de herramientas para su desarrollo, por ejemplo [JBP+02] o [CZ02], y tambien masrecientemente [PT05], [Con08] o [XSAH10].

Java

Otras alternativas se basan en utilizar otros lenguajes como por ejemplo Java. JavaCAD[DBB99] propone el uso de bibliotecas en Java para la especificacion y descripcion de

14 Antecedentes

hardware. Los componentes implementados se basan en extender clases e implementarinterfaces predefinidas, con lo que el componente final no es mas que una clase Java,que puede integrarse en un entorno de desarrollado que incluye simulacion y sıntesis. Loscores descritos pueden incluso entregarse a terceros pero manteniendo oculta la propiaimplementacion.

JHDL [HN00] tambien basa la descripcion de cores en Java. Para la descripcion decores se utilizan dos clases basicas Logic y Wire. Los disenos con este lenguaje pueden serestructurales, anadiendo componentes de una biblioteca e interconectandolos, o compor-tamental, aunque en este ultimo caso solo se permite su simulacion.

El entorno de desarrllo que ofrece JHDL permite la generacion de netlists en HDLsconvencionales (VHDL, Verilog) a partir de los disenos JHDL estructurales. En [WM02] losautores del lenguaje muestran como los cores descritos con este lenguaje se pueden ofrecerpara su evaluacion de manera remota (ejecucion en applets), ası como las posibilidades degenerar codigo VHDL o verilog sintetizable, a partir de la especificacion en JHDL.

Java tambien es la base para la generacion de hardware en [CN03]. A diferencia de losanteriores, que utilizan el propio lenguaje como HDL, en esta propuesta se ha desarrolladoun compilador capaz de generar la estructura hardware que implementa la funcionalidadde un programa Java: genera un datapath a partir de un programa en bytecodes Java.

Si se comparan las caracterısticas de los HDLs convencionales enfocadas a la reuti-lizacion de disenos, con las propuestas que utilizan lenguajes software, y que realizandescripciones de componentes a nivel RTL, se observa que las caracterısticas son muy si-milares. Permiten la descripcion estructural de cores, ası como cierto grado de descripcioncomportamental. La interfaz se centra en la declaracion de los puertos para la comunica-cion con otros modulos. En muchos casos se han desarrollado herramientas que generancodigo VHDL/Verilog sintetizable, a partir de las descripciones con estos lenguajes, ypoder ası hacer uso de las herramientas de desarrollo de los HDLs convencionales.

XML para la especificacion de hardware

XML tambien se ha utilizado para la descripcion de hardware. Mientras que la mayorıade propuestas se orientan en generar codigo en los HDLs convencionales para accederası a las herramientas que dan soporte a estos lenguajes, en [RGAN00] desarrollaron untraductor que convierte codigo VHDL en el lenguaje HDML (XML), con el objetivo deutilizar la descripcion en XML como base para intercambiar cores entre desarrolladores.Ademas, una vez que la descripcion se encuentra en este formato de intercambio, losautores indican que es posible utilizar herramientas de dominio publico para modificar losdatos contenidos en el formato XML propuesto, independientemente de lo que representenestos datos.

En [OGR06], y partiendo del trabajo anterior [RGAN00], no solo se utiliza XML parala representacion de hardware, sino que se utiliza como base para realizar transforma-ciones en los disenos. Las transformaciones van desde sencillas modificaciones, como porejemplo anadir redundancia para mejorar la seguridad, hasta complejas transformacionesque buscan reducir el consumo del diseno. Frente a las modificaciones y optimizacionesque puede realizar un disenador, que se pueden clasificar como locales al centrarse en unmodulo o area del diseno, este enfoque ofrece el potencial de realizar optimizaciones queabarcan todo un diseno.


En [OGGN09] proponen la conversion entre diferentes HDLs utilizando la descripcionen XML como paso intermedio para realizar transformaciones y conversiones. Esta pro-puesta ya contempla el caso particular de la expuesta en [OGR06], donde un core VHDL setransforma en una descripcion XML sobre la que se realizan transformaciones para volvera generar codigo VHDL. Tambien permite que el HDL de origen sea diferente del que esfinalmente generado, por ejemplo a partir de un core RTL-VHDL es posible generar uncore RTL-SystemC.

Aunque en las propuestas [RGAN00][OGR06][OGGN09] se utiliza XML para la repre-sentacion de hardware, no se ofrece como lenguaje para ser utilizado por un disenadordirectamente, sino para dar soporte a herramientas. Sin embargo, en [FZX10] sı que sepropone XML como HDL. Cada componente se especifica en un documento XML, con unencabezado y un cuerpo. En el encabezado es donde se especifica un identificador unicodel componente y un listado de puertos de entrada y salida. El cuerpo del documentocontiene la descripcion del componente, especificando su tipo: combinacional, secuencialo jerarquico. Para la implementacion del componente es necesario un traductor, en estecaso a Verilog [CGWT10].

Frente a las caracterısticas de los HDLs convencionales, esta propuesta permite unica-mente descripciones estructurales, con una interfaz limitada donde solo se declaran puer-tos, y sin apenas permitir la parametrizacion de los disenos. A todo lo anterior se une lacomplejidad de la descripcion de un diseno utilizando XML, que no lo hace demasiadoadecuado para que un disenador aborde la descripcion de modulos complejos.

XML para el encapsulado de hardware

Pero XML no solo se ha utilizado para la descripcion de hardware, tambien es unlenguaje adecuado para encapsular cores. En [RAW08] proponen un XML-Schema quepermite encapsular IPs descritos en diferentes lenguajes, ya sean los tradicionales VHDLo Verilog, o los generados a partir de lenguajes de alto nivel. El objetivo es presentar unencapsulado que ofrezca los detalles de las diferentes implementaciones como meta-datos,para que las herramientas de diseno puedan de manera automatica evaluar, manipular einstanciar estos cores.

El encapsulado propuesto en [RAW08] incluye la posibilidad de describir los parametrosdel componente y la especificacion de los puertos de la interfaz. En la especificacion delos parametros se permite evaluarlos mediante funciones. El resto de la interfaz del corese completa con la enumeracion de los puertos de entrada y salida. Ademas los autoresofrecen algunas caracterısticas para flexibilizar la especificacion de la interfaz, como laposibilidad de definir puertos opcionales o la agrupacion de puertos.

En [ARW09] se describen las posibilidades de manipulacion de los cores encapsuladosutilizando el XML-Schema: GUI para la seleccion de cores en una biblioteca de compo-nentes independientemente del lenguaje en el que se describa el core, cambio en la confi-guracion de los parametros, generacion de un wrapper del core seleccionado y configurado,por ejemplo VHDL. El core junto con el wrapper generado estan listos para ser integradosen un sistema.

En [AEG+10] se describe como los cores encapsulados en XML se pueden integrar paracomponer un sistema. A partir de una biblioteca de componentes y de una especificacionde alto nivel del sistema (Simulink), se generan parametros de configuracion de alto nivel.

16 Antecedentes

Estos parametros son propagados y refinados a parametros de configuracion de bajo nivel(cores). Los componentes de bajo nivel son generados a partir de la biblioteca de core y losparametros de configuracion de bajo nivel, mientras que es necesario sintetizar una FSMen VHDL para el control del sistema. Finalmente se genera una entidad de alto nivel enVHDL que instancia e interconecta los diferentes componentes generados.

Frente a las propuestas donde se utiliza XML para la descripcion de hardware, su usopara la especificacion del encapsulado sı que aporta mejoras para la reutilizacion de com-ponentes. Mejorar la cantidad y calidad de la informacion proporcionada desde la interfaz,aunque en las propuestas ofrecen mejoras limitadas en la declaracion de parametros yalgunos aspectos de los puertos de los componentes encapsulados, ayuda al usuario delcore en su configuracion e insercion en un nuevo diseno.

2.1.1.2. Lenguajes especıficos de dominio

Frente a utilizar lenguajes software, otras propuestas desarrollan lenguajes especıficos,para la descripcion de hardware enfocada en la reutilizacion. Estos lenguajes se centranen un dominio especıfico de aplicacion, denominandose DSLs [RL10], y entre sus carac-terısticas destacan que se han disenado para ser sencillos y con vocabulario del domino deaplicacion para resultar comodos de aprender, y obtienen una mejora de la productividadtras el coste asociado a su aprendizaje.

HML [LL95][Lee00] es un ejemplo de DSL. Es un lenguaje sencillo y funcional, y quefrente a VHDL, solo permite la descripcion de hardware sintetizable. Los desarrolladoresdel lenguaje son conscientes de que los lenguajes cuentan con multitud de herramientaspara su implementacion, por lo que los cores descritos con HML generan codigo VHDLsintetizable. El principal inconveniente que presenta es que ofrece unas caracterısticas yflexibilidad similares a la hora de la reutilizacion que los lenguajes convencionales. Cuentacon una interfaz limitada a la declaracion de puertos y no ofrece mejoras que ayuden adescribir estructuras hardware de modo dinamico.

Confluence [Haw] es un lenguaje de especificacion declarativo y funcional que simplificala generacion de codigo RTL. El lenguaje se enfoca en como se genera la descripcion deldiseno y no en la propia descripcion, como hacen los HDL convencionales, lo que permiteuna mayor flexibilidad a la hora de describir cores reutilizables: aumentar el grado deparametrizacion y un mejor control de la estructura generada.

Otra caracterıstica interesante de Confluence es la posibilidad de utilizar los cores des-critos como componentes en otros disenos y como funciones que realizan calculos durante elproceso de generacion. Sin embargo, al igual que los HDLs clasicos no permite obtener in-formacion a partir de los propios componentes, lo que obliga al disenador a conocer detallesde su implementacion antes de poder utilizarlos. Esta es una propuesta comercial de unaempresa con el mismo nombre que el lenguaje, Confluence, y que acabo desapareciendo.

Un ejemplo de DSL se encuentra en [KBS04], donde a partir del lenguaje Click, DSLpara el desarrollo de aplicaciones de networking, se desarrolla la version Cliff para suimplementacion en FPGA. Esta version realiza la correspondencia entre los elementosdefinidos en el lenguaje Click con componentes realizados en Verilog, por lo que a partirde un diseno realizado con el lenguaje, se puede obtener un diseno implementable en FPGAmediante la composicion de los modulos pre-definidos en Verilog.


Las maquinas de estados finitos (FSM) es un mecanismo extendido a la hora de generarel control de un diseno hardware [DMS03]. A medida que aumenta el numero de estadosde la propia maquina o su relacion con otras maquinas de estados aumenta el tiemporequerido para su diseno y su verificacion. Aunque los HDLs convencionales dan soportea su especificacion, suponen un dominio de aplicacion donde se han propuesto numerososDSLs. Por ejemplo [LJ00] permite generar FSMs reduciendo el numero de estados yaumentando la velocidad de verificacion. En [HA00] se presenta una propuesta que permitecoordinar multiples FSMs. En [Agr09] se presenta un lenguaje para la especificacion deFSM de manera que su implementacion puede realizarse de manera eficiente tanto ensoftware como en hardware. Sin embargo, la utilizacion del paradigma FSM no es lo masadecuado para especificar procesado de senal como es nuestro caso.

Realizar un diseno en base a la composicion de disenos anteriores, requiere la sincro-nizacion de los modulos que lo integren. La sincronizacion de estos modulos en ocasionesrequerira de la implementacion de FSMs adaptadas al sistema. En otras ocasiones sepodran utilizar componentes, como por ejemplo FIFOS u otros elementos de memoria,que permitan realizar el intercambio de informacion. En este ultimo caso es necesario di-senar componentes cuya funcion sea el intercambio de informacion entre modulos y cuyaimplementacion pueda reutilizarse.

Reutilizar componentes para aplicaciones de altas prestaciones de procesado de senales una tarea que permite mejorar la productividad en el diseno, pero como se indica en[ZTJ06], es comun que la integracion de estos componentes en un sistema de maneraautomatica de problemas y resulte erronea debido a los retardos requeridos en las restric-ciones de la implementacion.

SPIRAL [PMJ+05] es un DSL, pero cuyo campo de aplicacion no es la descripcionhardware, sino la especificacion de trasformadas dentro del campo de procesado de senal.Este entorno de trabajo busca implementar soluciones de altas prestaciones, y se espe-cializa en generar de manera automatica codigo para algoritmos de un amplio conjuntode transformadas como la de Fourier, transformadas trigonometricas, etc.En la propuestase especifica el algoritmo y se traduce al lenguaje SPL (Signal Processing Language), queutiliza un conjunto reducido de construcciones para representar el algoritmo, a partir delque se generan diferentes implementaciones. La propuesta no se centra en la generacionde hardware, sino que separa la especificacion del algoritmo con el lenguaje SPL, de laplataforma sobre la que se implementa. Un compilador realiza la correspondencia entrecodigo SPL y la plataforma destino. Este es uno de los problemas de las implementacioneshardware de SPIRAL, el disenador no tiene control en la estructura ni en el uso de losrecursos de la plataforma destino.

Mientras que SPIRAL se enfoca sobre todo a la generacion de codigo para sistemasprocesador [dMVP10] o multiprocesador [FPV+09], un conjunto de extensiones del com-pilador SPL permiten implementar las transformadas en hardware [DMS+07] [MFHP10].

2.1.1.3. Comparativa/Resumen

Para poder evaluar y comparar los diferentes lenguajes vistos hasta ahora, hemos iden-tificado como caracterısticas mas importantes que requiere un lenguaje para la reutilizacionde cores RTL:

18 Antecedentes

Tabla 2.1: Comparativa lenguajes HDL-RTL.

Nivel de abstraccion, estructural y/o comportamental.

Nivel de parametrizacion como medida de las posibilidades de configuracion.

Disponibilidad de herramientas. Si los cores descritos se pueden implementar direc-tamente sobre dispositivos fısicos o requieren de su traduccion a VHDL o Verilog.

La informacion ofrecida desde la interfaz.

Posibilidad o no de generacion de codigo RTL sintetizable.

Posibilidad o no de generacion dinamica de estructuras hardware.

En la tabla 2.1 se resumen estas caracterısticas para diferentes propuestas revisadasanteriormente.

En la mayorıa de propuestas se centran en realizar descripciones estructurales, mien-tras que proporcionan un soporte limitado a la descripcion del comportamiento. Esto esdebido a que la especificacion del comportamiento se utiliza para la descripcion de fun-cionalidad basica, como por ejemplo registros, multiplexores, etc. y para la validacion delos componentes, mientras que la descripcion estructural es la base de la reutilizacion decomponentes.

Otra de las caracterısticas es el grado de parametrizacion que permiten los lenguajes. Apesar de resultar un metodo sencillo pero potente que permite la adaptacion de los disenos,en la mayorıa de las propuestas su uso se puede catalogar como bajo, limitado por el tipode parametros que se pueden declarar, y por como utilizar los parametros para modificar

2.2 Enfoques de reutilizacion 19

la estructura que se esta definiendo con el lenguaje. Ası alternativas como Confluencemejoran las posibilidades de parametrizacion al flexibilizar y mejorar la descripcion deestructuras dinamicas.

Tambien es posible mejorar la parametrizacion mejorando la interfaz que describe alcomponente. Propuestas que no describen componentes, pero especifican un encapsulado,mejorando la declaracion de parametros y puertos, consiguen incorporar informacion en lainterfaz que con los HDLs convencionales se debe acompanar en las hojas de caracterısticasdel componente, y simplificar e incluso automatizar el diseno de un componente comocomposicion de otros componentes de biblioteca.

En esta Tesis se presentara dHDL, un lenguaje orientado a la generacion dinamicade codigo VHDL. Este lenguaje permite la descripcion estructural de un diseno, median-te estructuras y tipos sencillos, que no solo permiten describir de una manera flexiblela estructura del componente, sino que simplifican la tarea de instanciar e interconectarotros componentes de biblioteca. La interfaz del lenguaje no solo permite la declaracionde parametros y puertos del componente, sino que incluye la posibilidad de extraer in-formacion del componente generado. Lenguaje e interfaz aumentan las posibilidades deconfiguracion y adaptacion de los componentes descritos con dHDL, y tambien permitenincorporar una mayor informacion en la interfaz con el objetivo de ayudar a la reutilizacionde los disenos descritos con el lenguaje.

2.2. Enfoques de reutilizacion

La reutilizacion de componentes es una de las tecnicas mas extendidas para mejorarla productividad del diseno hardware. Ya en [PD95] se propone una biblioteca de disenosdescritos en VHDL, desde componentes sencillos hasta implementaciones de unidades depunto flotante. Para que un componente sea reutilizable no solo es necesario disponer dela implementacion, sino que debe ofrecer documentacion que simplifique su incorporacionen nuevos disenos. En [GC93, PHSMR95] se vuelven a presentar ejemplos de reutilizacionde bibliotecas de componentes utilizando VHDL.

Los lenguajes HDL convencionales dan soporte a la especificacion de disenos reutiliza-bles y a su agrupacion en bibliotecas de componentes. Sin embargo, a medida que el disenodescrito presenta complejidad, o bien su interfaz de entrada/salida implementa diferentestipos de acceso, o bien incorpora multiples parametros, necesita que el diseno se acompanede documentacion externa, que detalle no solo caracterısticas de la interfaz, sino inclusodetalles de la propia implementacion del componente. Los disenos realizados con HDLsconvencionales para ser reutilizables [JP01], requieren de una especificacion altamente pa-rametrizable, documentados y verificados. Ademas, incorporar informacion o soporte parala exploracion de espacio de diseno puede ayudar al disenador en la tarea de busqueda yseleccion de cores candidatos a implementar componentes de un sistema.

Ası, el diseno basado en componentes [LSV11] es un tecnica que permite reducir lacomplejidad del diseno hardware, mediante la integracion de componentes que poseen unadetallada informacion de interfaz. Entre los problemas que se presentan con este enfoque seencuentran por una parte la especificacion de la propia interfaz, por ejemplo incorporandoinformacion, funcional o no, como parte de la especificacion de la interfaz. Otros problemas

20 Antecedentes

se relacionan con la propia implementacion, por ejemplo el equilibrio en un diseno entre lageneralizacion y las prestaciones. En esta Tesis se aborda parte de la problematica asociadaa esta tecnica de diseno.

Mientras que el diseno basado en componentes se puede considerar una tecnica hori-zontal, frente a propuestas verticales que combinan diferentes niveles de abstraccion y eluso de diferentes lenguajes, como el diseno basado en plataforma [KNRSV00].

Los patrones de diseno, que engloban soluciones comunes a problemas de diseno recu-rrentes, tambien se han utilizado en el diseno hardware. En [DMS03] se definen patronesde diseno hardware que pueden utilizarse para configurar e integrar cores en sistemasempotrados. Los autores indican que durante el diseno hardware se puede encontrar unamplio conjunto de patrones de diseno no formales, por ejemplo las FSM como soluciona aplicaciones basadas en control. En el texto proponen el patron de diseno wrapper paraadaptar un componente a su entorno, y mediante metaprogramacion generar el codigo quelo implementa.

En [DAD+04] se propone identificar e iniciar un catalogo de patrones de diseno paraplataformas de procesado reconfigurables. Como primer paso para formar este catalogolos autores proponen una clasificacion de soluciones en grandes grupos: patrones paraequilibrar area-prestaciones, para expresar paralelismo, para implementar paralelismo, etc.

De nuevo en [RMBL05] se vuelven a proponer los patrones de diseno como metodopara mejorar la reutilizacion. En concreto se centra en el patron iterador (iterator) quepermite recorrer objetos compuestos independientemente de su implementacion. La ver-sion hardware propuesta define la interfaz para acceder y recorrer los elementos. Para laimplementacion de nuevo se recurre a la metaprogramacion, mediante un generador decodigo automatico.

En [ZGH08] se propone un metodo para la generacion de cores parametrizables basadaen patrones de diseno. Los cores se generan a partir de un conjunto de plantillas Verilog,en las que los parametros controlan sustituciones puntuales de codigo tras la llamada a unmetodo de generacion. Para mejorar las caracterısticas de parametrizacion, incorporan laposibilidad de definir paralelismo mediante llamadas a scripts Perl que generan el codigocorrespondiente a multiples instancias en paralelo. Aunque los autores pretenden dar unenfoque extensible, en realidad esta muy condicionado por el ejemplo que se utiliza.

2.3. Procesado de senal

Puesto que el ejemplo elegido en la Tesis para la especificacion de procesado de senales la Transformada Rapida de Fourier (FFT), debido a que es uno de los algoritmos masestudiados e implementados de todos los tiempos por sus numerosas aplicaciones, en elresto del capıtulo se revisaran trabajos centrados en su implementacion en FPGA.

2.3.1. Clasificacion de implementaciones FFT

Una primera clasificacion de las implementaciones basicas de FFT se puede realizaratendiendo al punto del espacio de diseno en el que se encuentre la implementacion: orien-tadas a minimizar el area o a maximizar las prestaciones.

2.3 Procesado de senal 21

Las arquitecturas orientadas a minimizar el area, donde no es crıtico el tiempo requeri-do para realizar la transformacion, suelen tener como objetivo minimizar los componentesutilizados, reutilizandolos a lo largo del tiempo de procesamiento. Una caracterıstica deestos disenos es la implementacion del algoritmo en una unica etapa, en la que se vancalculando iterativamente las sub-transformadas de menor orden.

En [SCIC03] se propone una arquitectura basada en el algoritmo Cooley-Tukey [CLW67],utilizando una mariposa de Radix-4. Esta implementacion permite calcular transformadasde diferente longitud, desde 2k a 8k puntos, con apenas cuatro multiplicadores complejosy ocho sumadores tambien complejos. Las diferentes longitudes de transformada se imple-mentan con una mayor profundidad de la memoria y un mayor tiempo requerido para elcalculo.

En [SD04] se presenta una arquitectura similar, de nuevo capaz de calcular transforma-das de 1k a 16k puntos a costa de una mayor cantidad de memoria y una mayor latencianecesaria para finalizar los calculos. A diferencia de la anterior, requiere una mayor can-tidad de hardware, en concreto ocho multiplicadores complejos, pero con una tasa deutilizacion superior, que permite finalizar los calculos en un menor numero de iteraciones.

En [UAAB03] se propone una arquitectura para diferentes implementaciones del algo-ritmo. La arquitectura esta orientada a trabajar como coprocesador en un sistema empo-trado, y en este caso se presta una especial atencion a la memoria. Los cores disponen de uncontrolador de memoria que permite acceder a memoria externa, con lo que teoricamentepodrıa calcular transformadas de 1M puntos.

En el extremo opuesto se encuentran implementaciones donde el objetivo es maximizarlas prestaciones. En las implementaciones orientadas a minimizar area, aunque adaptadasal calculo, sus prestaciones pueden compararse a las obtenidas por procesadores digita-les de senal, mientras que las orientadas a prestaciones pueden utilizarse en aplicacionesdonde estos procesadores no son capaces de alcanzar tiempo real. Para este tipo de imple-mentaciones se sacrifica area mediante la replicacion de componentes, de manera que sepueda extraer un mayor grado de paralelismo en el calculo. A diferencia de las arquitec-turas eficientes en area, este tipo de implementaciones se caracterizan por implementar elalgoritmo en una serie de etapas, donde en cada etapa se calculan transformadas de cadavez menor orden.

Ejemplos de este tipo de implementaciones podemos encontrarlos en [Rem99], [SYD01],[KHG03]. La implementacion de [SYD01] muestra una arquitectura en radix-4 en pipeline,capaz de procesar un flujo continuo de cuatro muestras por ciclo. En [KHG03] se proponeuna implementacion similar, de nuevo capaz de procesar un flujo de entrada continuo queen este caso puede alcanzar las 800 MMuestras/s, mediante una arquitectura paralela yen pipeline, utilizando un radix-8.

En [GC04] se propone una arquitectura capaz de calcular transformadas de 128 puntos.A diferencia de las anteriores, esta implementacion combina la extraccion de paralelismopara obtener alta velocidad, con una implementacion iterativa que realimenta los datospara procesar las siguientes sub-transformadas en la misma etapa.

En [HMP05] de nuevo se propone una arquitectura para el calculo de transformadasde 128 puntos. Para ello primero implementa una etapa en radix-8, y luego dos etapasque implementan una transformada equivalente de 16 puntos: dos etapas de radix-4 yotra implementacion con radix-4 y luego radix-8. Ambas arquitecturas permiten obtener

22 Antecedentes

prestaciones por encima de 500MMuestas/s.

Entre este ultimo tipo de implementaciones cabe destacar [CP03], basada en la im-plementacion por etapas y en pipeline, esta orientada a maximizar prestaciones y utilizaaritmetica serie que permite maximizar la frecuencia de reloj. Ademas esta implementa-cion puede considerarse mezcla de arquitecturas: etapas que paralelizan el procesado ycostosas en area, con etapas realimentadas que minimizan el area.

Cada vez mas, es tener en cuenta el consumo de los disenos. Por ello aparecen imple-mentaciones del algoritmo, como en [CGJP03], [HA03], [SZH04], [LCHC03], [SCG05], quebuscan minimizar su consumo.

En [CGJP03] se han desarrollado un conjunto de disenos, con modificaciones del algo-ritmo como es diferente paralelismo, radix, etc, y se han aplicado diferentes tecnicas parareducir el consumo.

Tambien resulta interesante [SCG05] que describe como usar tecnicas para el procesadoen paralelo del algoritmo con las distintas fases retardadas de un reloj, permitiendo obtenerunas altas prestaciones a bajas frecuencias de reloj, aunque con un alto coste en area.

2.3.1.1. Cores FFT

El algoritmo FFT es uno de los mas extendidos y usados en el campo de procesadodigital de senal, por ello resulta interesante que su implementacion como core permitareutilizarlo en diferentes aplicaciones. Hay implementaciones que se dan a conocer comode alto nivel. Describen como realizar una rapida implementacion del algoritmo, y nor-malmente estan basadas en un lenguaje de especificacion como es Handel-C [ASRW96].A pesar de la ventaja del rapido desarrollo, los inconvenientes de estas implementacionesderivan del uso de este tipo de lenguajes, como por ejemplo que las prestaciones finales dela implementacion dependen en gran medida del compilador.

En [UAAB03] se utiliza Handel-C para la implementacion rapida de diversas alternati-vas de implementacion del algoritmo: Radix-2, Radix-4, Split-Radix y FHT. Sin embargo,parece que en este trabajo se ha implementado un core diferente para cada transformaday no parece ofrecerse tampoco posibilidades para diferentes configuraciones, es decir pa-rametrizacion. Otro trabajo similar es [Yut99] que tambien utiliza Handel-C para realizaruna rapida implementacion del algoritmo, esta vez utilizando mariposas radix-22.

En [UAB05] se describe un core utilizando Handel-C. En este trabajo se permite se-leccionar la dimension y el algoritmo utilizado en la implementacion mediante el acceso aun conjunto de disenos implementados en una biblioteca. Estos disenos permiten ademasun cierto grado de parametrizacion como es la posibilidad de definir los anchos de bits ola longitud de la transformada.

Algunos cores VHDL/Verilog parametrizables como en [MD03], [GBTG04], se limitana permitir variar el ancho de palabra con la que trabaja el core o incluso la longitud de latransformada, aunque siempre manteniendo caracterısticas fijas como el radix.

Tanto en el caso de las implementaciones con lenguajes como Handel-C como las rea-lizadas con VHDL/Verilog el grado de parametrizacion obtenido es similar.

En esta Tesis vamos a buscar crear cores FFT con un elevado nivel de parametrizacion,que no solo permitan configurar caracterısticas de ancho de bit y numero de puntos, sino

2.4 Conclusiones 23

tambien parametros como el radix, o parametros que permitan configurar modo en el quese van a implementar los operadores.

2.4. Conclusiones

Desde la aparicion de los primeros lenguajes para la descripcion hardware, que se hanadoptado como estandar IEEE y que a dıa de hoy son ampliamente utilizados por laindustria, como son VHDL o Verilog, se ha realizado un esfuerzo continuo en la mejorade sus caracterısticas que permitan un aumento en la productividad de sistemas. Ası,en paralelo con la mejora de estos lenguajes denominados HDLs convencionales, nuevaspropuestas que buscan mejorar la productividad aumentando el grado de abstraccion,como son System-C o SystemVerilog, tambien se han acabado incorporando como estandarIEEE.

Pero hay aspectos importantes relacionados con la reutilizacion que no se cubre conestos HDLs convencionales, por lo que se han desarrollado diferentes propuestas, comoes el uso de lenguajes software generalistas para la especificacion hardware, que aportanfamiliaridad en su uso y permiten abordar el diseno de sistemas software/hardware con ununico lenguaje, pero que desde el punto de vista de reutilizacion presentan caracterısticassimilares a los HDLs convencionales.

Frente a estas propuestas generalistas, parte de las propuestas se centra en mejorarcaracterıticas especificas de los HDLs convencionales. Desde la mejora en el encapsuladoque describe la implementacion con lenguajes como XML, a propuestas de lenguajes quesolo generan codigo sintetizable.

Para mejorar la reutilizacion respecto a estos HDLs convencionales, no solo es necesariomejorar la definicion de la interfaz que acompana a los cores, tambien se pueden realizarmejoras en su especificacion. Para mejorar esta interfaz en esta Tesis se propondran unconjunto de encapsulados orientados a mejorar la reutilizacion de componentes, y se defi-nira el lenguaje dHDL que simplifica la especificacion estructural de cores hardware, y contipos y procedimientos orientados a potenciar la reutilizacion de componentes previamentedefinidos.

24 Antecedentes

Capıtulo 3

Fundamentos del enfoque dereutilizacion propuesto

3.1. Justificacion

HDLs clasicos, como VHDL o Verilog, son ampliamente utilizados para la descripcionde cores hardware. Sin embargo, la interfaz que ofrecen limita las posibilidades de reuti-lizacion de los cores descritos en estos lenguajes. La parte de la interfaz que acompana ala implementacion, que se denominara encapsulado, solo permite declarar los puertos quecomunican el core con otros elementos del sistema, ası como parametros muy limitadosque permitiran configurar caracterısticas del diseno.

Por lo general, el resto de la informacion de la interfaz, necesaria para integrar elcore en otros disenos, normalmente se acompana mediante documentacion externa. Estadocumentacion suele describir la funcion de cada uno de los parametros y puertos del com-ponente, ası como las relaciones que existen entre ellos y que no se han podido incorporaren la implementacion. Por ejemplo, cronogramas para describir la relacion entre senalesy puertos del componente, o funciones que permitan establecer restricciones a los valoresde los parametros, incluso notas de aplicacion que ayuden al usuario del core a entendercomo utilizarlo de manera practica.

La Figura 3.1 muestra un ejemplo de declaracion y configuracion de parametros paraun bloque DSP48E de las FPGAs Virtex-5 de Xilinx. Para la correcta configuracion delos parametros, la instancia VHDL incluye un breve comentario con el uso y el valor quese puede asignar a estos parametros. Si se consulta la guıa para el uso de estos elementosde Xilinx [Xilb], no es posible suministrar una configuracion arbitraria de parametros conlos valores definidos en los comentarios, sino que existen relaciones y restricciones entredichos parametros. Por ejemplo, si el parametro USE SIMD se inicializa a TWO24 o FOUR12

el parametro USE MULT se debe configurar con NONE.

De manera similar, los puertos declarados en el encapsulado del DSP48E, mostradosen la Figura 3.2, tras consultar la documentacion del componente, solo un reducido con-junto de puertos se utiliza para la entrada y salida de datos, mientras que del resto, lamayorıa implementa senales de sincronismo y control sobre los puertos de datos anteriores.Ademas, dependiendo de la configuracion del componente, algunos puertos dejan de uti-lizarse, aunque no se deshabilitan, por lo que el usuario del componente es el responsable

26 Fundamentos del enfoque de reutilizacion propuesto

DSP48E_inst : DSP48E

generic map (

ACASCREG => 1, -- Number of pipeline registers between

-- A/ACIN input and ACOUT output, 0, 1, or 2

ALUMODEREG => 1, -- Number of pipeline registers on ALUMODE input, 0 or 1

AREG => 1, -- Number of pipeline registers on the A input, 0, 1 or 2

AUTORESET_PATTERN_DETECT => FALSE, -- Auto-reset upon pattern detect, TRUE or FALSE

AUTORESET_PATTERN_DETECT_OPTINV => "MATCH", -- Reset if "MATCH" or "NOMATCH"

A_INPUT => "DIRECT", -- Selects A input used, "DIRECT" (A port) or "CASCADE" (ACIN port)

BCASCREG => 1, -- Number of pipeline registers between B/BCIN input and BCOUT output, 0, 1, or 2

BREG => 1, -- Number of pipeline registers on the B input, 0, 1 or 2

B_INPUT => "DIRECT", -- Selects B input used, "DIRECT" (B port) or "CASCADE" (BCIN port)

CARRYINREG => 1, -- Number of pipeline registers for the CARRYIN input, 0 or 1

CARRYINSELREG => 1, -- Number of pipeline registers for the CARRYINSEL input, 0 or 1

CREG => 1, -- Number of pipeline registers on the C input, 0 or 1

MASK => X"3FFFFFFFFFFF", -- 48-bit Mask value for pattern detect

MREG => 1, -- Number of multiplier pipeline registers, 0 or 1

MULTCARRYINREG => 1, -- Number of pipeline registers for multiplier carry in bit, 0 or 1

OPMODEREG => 1, -- Number of pipeline registers on OPMODE input, 0 or 1

PATTERN => X"000000000000", -- 48-bit Pattern match for pattern detect

PREG => 1, -- Number of pipeline registers on the P output, 0 or 1

SIM_MODE => "SAFE", -- Simulation: "SAFE" vs "FAST", see "Synthesis and Simulation

-- Design Guide" for details

SEL_MASK => "MASK", -- Select mask value between the "MASK" value or the value on the "C" port

SEL_PATTERN => "PATTERN", -- Select pattern value between the "PATTERN" value or the value on the "C" port

SEL_ROUNDING_MASK => "SEL_MASK", -- "SEL_MASK", "MODE1", "MODE2"

USE_MULT => "MULT_S", -- Select multiplier usage, "MULT" (MREG => 0),

-- "MULT_S" (MREG => 1), "NONE" (not using multiplier)

USE_PATTERN_DETECT => "NO_PATDET", -- Enable pattern detect, "PATDET", "NO_PATDET"

USE_SIMD => "ONE48" ) -- SIMD selection, "ONE48", "TWO24", "FOUR12"

...

Figura 3.1: Instancia VHDL para DSP48E en Virtex-5: Parametros.

de conectarlos a un valor logico constante.

Cada core suele ofrecer esta informacion de forma diferente, lo que supone un inconve-niente a la hora de automatizar el proceso de exploracion del espacio de diseno. Y no solola informacion de interfaz se puede presentar de manera heterogenea, sino que esta fuer-temente ligada a la implementacion. Incluir un core descrito con estos lenguajes en unsistema obliga en muchas ocasiones a conocer en detalle como esta implementado.

Ası, un primer paso para simplificar la reutilizacion de los cores descritos con HDLclasicos es mejorar el encapsulado que acompana a la implementacion, aumentando lacantidad de informacion que se aporta con este encapsulado de la implementacion. Estenuevo encapsulado esta orientado a mejorar las posibilidades de configuracion de los cores,e incorporar informacion relacionada con la implementacion. Las mejoras que ofrece esteencapsulado sobre la interfaz de los HDLs convencionales son:

Los cores descritos con lenguajes tradicionales suelen utilizar la parametrizacioncomo herramienta para la reutilizacion, ya que permite adaptar una misma imple-mentacion a diferentes aplicaciones. Las parametros de estos lenguajes admiten va-lores literales, como por ejemplo los utilizados para determinar anchuras de palabra,y tambien pueden realizar llamadas a funciones sencillas. El encapsulado propuestomejora estas posibilidades, por ejemplo evaluando funciones complejas o incluso fun-ciones basadas en el valor de otros parametros, lo que permite establecer relacionesentre parametros.

Un valor anadido con el nuevo encapsulado es la posibilidad de declarar tipos conlos que obtener informacion de la implementacion. Esta informacion puede utilizarsepara simplificar tareas como la integracion del core en un nuevo sistema, o inclusoayudar en la exploracion del espacio de diseno. Incorporar esta informacion junto conla implementacion permite que se puedan automatizar tareas que con los lenguajes

3.1 Justificacion 27

...

port map (

ACOUT => ACOUT, -- 30-bit A port cascade output

BCOUT => BCOUT, -- 18-bit B port cascade output

CARRYCASCOUT => CARRYCASCOUT, -- 1-bit cascade carry output

CARRYOUT => CARRYOUT, -- 4-bit carry output

MULTSIGNOUT => MULTSIGNOUT, -- 1-bit multiplier sign cascade output

OVERFLOW => OVERFLOW, -- 1-bit overflow in add/acc output

P => P, -- 48-bit output

PATTERNBDETECT => PATTERNBDETECT, -- 1-bit active high pattern bar detect output

PATTERNDETECT => PATTERNDETECT, -- 1-bit active high pattern detect output

PCOUT => PCOUT, -- 48-bit cascade output

UNDERFLOW => UNDERFLOW, -- 1-bit active high underflow in add/acc output

A => A, -- 30-bit A data input

ACIN => ACIN, -- 30-bit A cascade data input

ALUMODE => ALUMODE, -- 4-bit ALU control input

B => B, -- 18-bit B data input

BCIN => BCIN, -- 18-bit B cascade input

C => C, -- 48-bit C data input

CARRYCASCIN => CARRYCASCIN, -- 1-bit cascade carry input

CARRYIN => CARRYIN, -- 1-bit carry input signal

CARRYINSEL => CARRYINSEL, -- 3-bit carry select input

CEA1 => CEA1, -- 1-bit active high clock enable input for 1st stage A registers

CEA2 => CEA2, -- 1-bit active high clock enable input for 2nd stage A registers

CEALUMODE => CEALUMODE, -- 1-bit active high clock enable input for ALUMODE registers

CEB1 => CEB1, -- 1-bit active high clock enable input for 1st stage B registers

CEB2 => CEB2, -- 1-bit active high clock enable input for 2nd stage B registers

CEC => CEC, -- 1-bit active high clock enable input for C registers

CECARRYIN => CECARRYIN, -- 1-bit active high clock enable input for CARRYIN register

CECTRL => CECTRL, -- 1-bit active high clock enable input for OPMODE and carry registers

CEM => CEM, -- 1-bit active high clock enable input for multiplier registers

CEMULTCARRYIN => CEMULTCARRYIN, -- 1-bit active high clock enable for multiplier carry in register

CEP => CEP, -- 1-bit active high clock enable input for P registers

CLK => CLK, -- Clock input

MULTSIGNIN => MULTSIGNIN, -- 1-bit multiplier sign input

OPMODE => OPMODE, -- 7-bit operation mode input

PCIN => PCIN, -- 48-bit P cascade input

RSTA => RSTA, -- 1-bit reset input for A pipeline registers

RSTALLCARRYIN => RSTALLCARRYIN, -- 1-bit reset input for carry pipeline registers

RSTALUMODE => RSTALUMODE, -- 1-bit reset input for ALUMODE pipeline registers

RSTB => RSTB, -- 1-bit reset input for B pipeline registers

RSTC => RSTC, -- 1-bit reset input for C pipeline registers

RSTCTRL => RSTCTRL, -- 1-bit reset input for OPMODE pipeline registers

RSTM => RSTM, -- 1-bit reset input for multiplier registers

RSTP => RSTP -- 1-bit reset input for P pipeline registers );

Figura 3.2: Instancia VHDL para DSP48E en Virtex-5: Puertos.

convencionales no es posible.

Para facilitar la integracion e interconexion de cores se permite agrupar en una unicadeclaracion todo un grupo de puertos VHDL que implementan de manera conjuntaun procedimiento de entrada/salida.

Para implementar este encapsulado son necesarios dos elementos. En primer lugar, elpropio encapsulado donde se declaran los elementos para la configuracion (parametros)y elementos para informar de las caracterısticas de un core (atributos), ademas de loselementos que definen la entrada/salida (macropuertos). En segundo lugar, junto con elencapsulado es necesario realizar un envoltorio del core HDL, mediante un nuevo lenguaje,que realice entre otras funciones:

Trasladar el valor de los parametros de configuracion del encapsulado a valores deconfiguracion del core HDL. Esto permite por ejemplo que un unico valor de confi-guracion del core se obtenga a partir de varios parametros del encapsulado, o inclusofunciones de estos parametros. Tambien permite controlar y limitar entre los valoresde configuracion evitando configuraciones que no sean implementables.

Declarar e implementar funciones que informen de las caracterısticas de la implemen-tacion. Por ejemplo caracterısticas que ayuden a la integracion del core en un sistema


como la latencia de procesado, aunque tambien es posible implementar estimadoresmediante funciones del valor de los parametros de configuracion.

Adaptar los elementos de entrada/salida definidos en el encapsulado a los puertosdeclarados en el core HDL. Permite la adaptacion mas sencilla donde se realiza unaasignacion directa entre los puertos del encapsulado y del componente, aunque tam-bien permite eliminar puertos de la interfaz y asignarlos a valores logicos constantessi lo requiere la configuracion.

Con el encapsulado y el nuevo lenguaje se puede realizar un envoltorio del componenteDSP48E que mejore su utilizacion. Por ejemplo, con el nuevo encapsulado, se declararanlos mismos parametros, del mismo tipo y limitando sus posibles valores de configuracion.La declaracion de puertos describira los puertos para senales de datos y control del compo-nente, declaracion que incluira las senales de sincronismo que tengan asociadas. Ademas elencapsulado declara atributos que simplifican la integracion del componente en un diseno,como por ejemplo la latencia, que para el DSP48E depende del numero de registros que sehabiliten mediante los parametros de configuracion. Durante su instanciacion, realizada enel envoltorio con el nuevo lenguaje, se verificaran las relaciones entre parametros definidasen las hojas de caracterısticas, y se realizara el interconexionado de puertos, deshabilitandoy eliminando de manera efectiva los puertos del componente que no se utilicen. Finalmentese calcula el valor de la latencia que presenta en funcion del valor de configuracion.

Por lo tanto, para permitir las posibilidades de configuracion e informacion del en-voltorio es necesario definir un lenguaje que implemente las nuevas funcionalidades delencapsulado. Este lenguaje no solo se limita a envolver un unico core, sino que con unmismo encapsulado y definiendo un parametro de seleccion puede utilizarse para selec-cionar, configurar e informar entre diferentes cores. Para ello ademas de implementar losmecanismos basicos para instanciar cores HDL necesita definir estructuras de control queseleccionen la implementacion en base al valor del parametro del encapsulado.

Pero el lenguaje no solo se limita a definir el envoltorio de un conjunto de cores.Extendiendo el conjunto de estructuras de control y definiendo un conjunto sencillo detipos, el lenguaje permite realizar una descripcion estructural en la que se instancian einterconectan diferentes cores.

Ası, este nuevo lenguaje, denominado dHDL (dynamic HDL), sirve para describir comose genera la estructura a partir de la configuracion definida en el encapsulado. El lenguajepasa ası de utilizarse unicamente para definir el envoltorio de cores HDL a describir corescompletos, y por lo tanto no solo se limita a utilizar como componentes cores HDL, sinoque permite instanciar otros cores descritos con el propio lenguaje. El lenguaje no describeen sı un core sino que describe como generar la descripcion VHDL de dicho core, que esimplementable utilizando herramientas de desarrollo comerciales para VHDL.

Dado el caracter estructural de las descripciones dHDL, al encapsulado que definesu interfaz se le denomina encapsulado estructural. En este encapsulado estructural, losparametros actuan de elementos de entrada, que controlan la generacion de la estructura yla configuracion de los componentes utilizados, ya sean componente descritos con VHDL odescritos utilizando el propio dHDL. El encapsulado estructural tambien define atributosque actuan como elementos de salida, y que permiten informar del hardware generado.

dHDL simplifica la descripcion estructural respecto a los HDLs convencionales, y au-

3.1 Justificacion 29

menta el grado de parametrizacion de los cores con el descritos, dando soporte al primerencapsulado propuesto. El encapsulado estructural permite mejorar la informacion de in-terfaz que acompana a la implementacion frente a los HDL clasicos, aunque tambien tienelimitaciones desde el punto de vista de reutilizacion:

Una primera limitacion se encuentra relacionada con la propia parametrizacion. Aun-que es un metodo conveniente para dotar a un core de posibilidades de adaptacion,de manera practica no es posible incorporar un numero ilimitado de parametros.Cada nuevo parametro implica una nueva modificacion en la estructura interna delcore, por lo que es necesario comprobar su funcionalidad frente a todos los demasparametros y sus posibles valores, lo que aumenta la complejidad del core y el tiemporequerido para su verificacion.

En segundo lugar, al igual que los en lenguajes convencionales, este encapsuladoesta ligado a una implementacion, por lo que de nuevo diferentes implementaciones seencontraran definidas con diferentes encapsulados y definiran diferentes parametros,atributos y puertos. Comparar alternativas sigue requiriendo buscar y seleccionarla optima entre aquellas que, aunque implementen la misma funcion, se encuentrandefinidas y descritas de manera diferente.

Describir cores mediante el encapsulado estructural y el lenguaje dHDL facilita incor-porar informacion en la interfaz, que con los HDLs convencionales normalmente se debeacompanar mediante documentacion externa. Por ejemplo, con los HDLs convencionales,aunque en la interfaz se definen los elementos de configuracion, no estan disponibles rela-ciones entre parametros, valores recomendados o validos, etc., que se especifican en su hojade caracterısticas. El encapsulado estructural propuesto permite incorporar esta informa-cion en la propia declaracion de los tipos. Otra informacion, util para la integracion delcore en nuevos disenos, como por ejemplo la latencia, tampoco acompana a la declaracionde la interfaz de los HDLs convencionales mientras que se puede implementar mediantelos elementos de informacion del encapsulado estructural.

El siguiente paso para mejorar la reutilizacion es desarrollar un segundo nivel de espe-cificacion del encapsulado, que para diferenciarlo del anterior se ha denominado funcional,y que se encuentra mas alejado de la implementacion. Para ello se ha definido un segundoencapsulado cuya principal caracterıstica es que no se va a ligar a ninguna implementacion.Este encapsulado se centra en describir la funcionalidad del core frente a los detalles deimplementacion del primer encapsulado (puertos, parametros, atributos, ...). Este encap-sulado no fijara ni limitara como un core implementa dichas caracterısticas, sino que sera eldisenador del core el que decida como configurar el diseno y como el diseno ası configuradocumple dichas caracterısticas.

Junto con el encapsulado funcional es necesario definir un nuevo elemento, denomina-do empaquetado, que permite describir las relaciones entre el encapsulado funcional y elencapsulado estructural. Si el encapsulado funcional permite describir una funcion generi-ca e independiente de posibles implementaciones, el empaquetado establece como se debeutilizar el encapsulado estructural para implementar el encapsulado funcional. El conjuntoformado con el encapsulado funcional y empaquetado cubre un doble objetivo:

El encapsulado funcional permite definir una especificacion uniforme para multiples


Figura 3.3: Espacio de diseno.

implementaciones, y buscar que alternativa de implementacion, mediante la transfor-macion proporcionada en el empaquetado, es la que mas se ajusta a las restriccionesque se impongan en el encapsulado funcional. No solo permite simplificar el procesode exploracion de alternativas, sino que desde el punto de vista de los disenos pro-porciona un mecanismo para ofrecer al core como alternativa en situaciones para lasque no fue directamente disenado.

Definir una extension de la interfaz del core descrito mediante el encapsulado estruc-tural y el lenguaje de generacion, que permite incorporar nueva informacion, en estecaso informacion de uso del componente. Un core se compone de un unico encapsula-do estructural e implementacion, pero puede definir multiples empaquetados, dondecada empaquetado describe como se debe configurar y conectar al componente paraimplementar una funcion. El empaquetado aumenta la cantidad de informacion quese puede suministrar con el diseno, en este caso informacion relacionada con las notasde aplicacion del diseno.

En la Figura 3.3 se muestran los diferentes niveles de jerarquıa en la especificacion dela interfaz propuesta en esta Tesis Doctoral:

En el nivel mas bajo se encuentran los cores descritos con HDLs clasicos, donde partede la interfaz acompana a la implementacion y parte suele acompanarse mediantedocumentacion externa.

El siguiente nivel se corresponde a lo que se ha indicado como cores dHDL: definen unprimer encapsulado estructural cuyo objetivo es mejorar la informacion de interfazque acompana a la implementacion. El encapsulado estructural define la interfazde estos cores, mientras que para su implementacion se utiliza el lenguaje dHDL,orientado a la generacion dinamica de cores parametrizables y que implementa lafuncionalidad requerida por las nuevas caracterısticas del encapsulado estructural.

3.2 Encapsulado estructural y dHDL 31

Figura 3.4: Encapsulado estructural de un core VHDL.

Finalmente, por encima de este nivel se define el encapsulado funcional, que a dife-rencia de los anteriores no dispone de implementacion propia.

Tambien en la Figura 3.3 se puede observar como se relacionan los diferentes encapsu-lados y cores:

Los cores dHDL, aunque orientados a simplificar la descripcion estructural y jerarqui-ca de hardware, pueden a su vez utilizar varios cores convencionales durante suimplementacion.

Dado que un encapsulado funcional no dispone de una implementacion especıfica,puede utilizarse para describir varios cores dHDL, mediante los empaquetados.

El empaquetado acompana al encapsulado estructural del core, y permite al disenadorincorporar informacion de la interfaz de reutilizacion junto con la implementacion, en estecaso informacion relacionada con el uso practico del diseno. Mientras que un core solodefine un encapsulado estructural, el disenador puede incorporar diversos empaquetadosa modo de diferentes notas de aplicacion.

Siguiendo con el ejemplo del componente DSP48E, una vez realizado su encapsuladoestructural, el componente es lo suficientemente versatil como para implementar diferentesfunciones, por ejemplo la suma, multiplicacion, acumulacion, etc., descritas en diferentesencapsulados funcionales. Para implementar cada una de estas funciones es necesario pro-porcionar una configuracion especıfica del componente (por ejemplo para implementarla suma se debe deshabilitar el uso del multiplicador integrado), pero tambien indicarque puertos del componente se requieren y que hacer con los que no se utilizan.

3.2. Encapsulado estructural y dHDL

3.2.1. Encapsulado estructural de cores VHDL

Encapsular uno o varios cores VHDL utilizando el encapsulado estructural y el lenguajedHDL es el mecanismo mas sencillo para comenzar a utilizar los elementos propuestos enesta Tesis, y mejorar la reutilizacion de estos componentes. La Figura 3.4 representa lacorrespondencia entre elementos del conjunto formado por el encapsulado estructural ydHDL para envolver un core VHDL.


Figura 3.5: Encapsulado estructural de cores VHDL.

El disenador responsable de realizar este encapsulado debe estar familiarizado con elcomponente a encapsular, de modo que si no ha desarrollado directamente dicho compo-nente, sı que conoce los detalles de su implementacion o los detalles recogidos en sus hojasde caracterısticas. Encapsular al componente requiere:

Especificar el propio encapsulado estructural.

• Definir y declarar los parametros de configuracion.

• Definir y declarar los atributos relevantes de la implementacion.

• Definir y declarar los macropuertos que ofrecera el componente encapsulado.

Realizar el envoltorio del core VHDL, utilizando dHDL.

• Mediante un conjunto sencillo de tipos que permiten referenciar y utilizar alcore VHDL.

• Definir como transformar los valores de configuracion del encapsulado en valoresde configuracion del core instanciado.

• Definir como se conectan los puertos definidos en el componente VHDL con losdeclarados en el encapsulado estructural.

• Establecer el valor que se devolvera a los atributos del encapsulado estructural.

Como se ha mencionado anteriormente, mediante este metodo un disenador puededesarrollar un unico encapsulado para diferentes cores VHDL. El encapsulado pasa arepresentar un nuevo core dHDL que selecciona entre diferentes alternativas, pero mante-niendo una interfaz uniforme. La Figura 3.5 representa un encapsulado de este tipo dentrodel espacio de diseno area-prestaciones.

El nuevo core dHDL puede ser utilizado por otros usuarios:


Otro disenador que necesita de una configuracion especıfica del componente. Estenuevo disenador especifica una configuracion de los parametros declarados en elencapsulado, y tras generar el componente obtiene un core VHDL.

Otro core dHDL desde el que se instancia al componente dentro de la descripcion deun diseno mayor. En este caso el componente encapsulado se integra dentro de undiseno jerarquico, donde recibe la configuracion desde el componente que lo instancia,al que a su vez devuelve informacion de generacion.

Independientemente del usuario del nuevo core dHDL, para generar la descripcion finaldel componente en VHDL es necesario un conjunto de herramientas que la generen, y quese veran en el apartado 3.2.3.

3.2.2. Cores dHDL

La utilidad del encapsulado estructural y el lenguaje dHDL no solo se limita a actuarcomo envoltorio de uno o varios cores VHDL, sino que el lenguaje de generacion se puedeutilizar para especificar todo un diseno. En este caso, ademas de estructuras condicionalesque permitan la seleccion de componentes, el lenguaje implementara estructuras de controliterativas que, junto con la posibilidad de instanciar cores VHDL, permiten la descripcionestructural de cores.

Dado que dHDL permite describir cores, tambien proporciona mecanismos para ins-taciarlos durante la descripcion con el propio lenguaje, proporcionando la posibilidad derealizar una descripcion estructural basada en la reutilizacion tanto de cores VHDL comode cores dHDL. El lenguaje se enfoca a simplificar este tipo de descripcion con lo queincorpora tipos y mecanismos que ayudan en la instanciacion e interconexionado de coresya descritos.

Las descripciones dHDL tienen un fuerte caracter jerarquico. La configuracion quese suministra desde el encapsulado estructural del componente de la jerarquıa superiorpermite seleccionar y configurar los componentes de jerarquıa inferior que se iran incor-porando durante la generacion de la estructura. Ademas, junto con el propio proceso degeneracion y configuracion, permite implementar un proceso de recogida de informaciondesde los elementos de jerarquıa inferior a los de jerarquıa superior, lo que puede utilizarsepor ejemplo para implementar estimadores dependientes de la estructura que se genera.

Los cores dHDL mejoran las posibilidades de parametrizacion de los lenguajes HDLsconvencionales, por lo que abarcan una mayor zona dentro del espacio de diseno, como serepresenta en la Figura 3.6.

Como sucedıa con el encapsulado de cores VHDL, al desarrollar cores dHDL se di-ferencia entre el disenador que lo implementa, y los posibles usuarios del core. Desde elpunto de vista del disenador que lo implementa, los procedimientos para describir un coredHDL son una extension de los utilizados para encapsular un core VHDL. Debe definir elencapsulado estructural para el nuevo componente, y desarrollar la propia descripcion endHDL. Para realizar esta descripcion en dHDL el disenador debe conocer:

Proceso de instanciacion de cores.


Figura 3.6: Core dHDL.

Mecanismos para el control de la estructura que se genera.

Tipos y procedimientos propios del lenguaje, aunque se trata de un conjunto reducidoy orientado a simplificar la descripcion estructural del core.

Desde el punto de vista de los usuarios no existe diferencia del componente representa-do con el encapsulado estructural, ya sea un componente VHDL o una descripcion dHDL.Como sucedıa con el encapsulado de componentes VHDL, se pueden presentar como usua-rios tanto otros disenadores que quieran utilizar al componente, como otros disenos quelo instancien. En ambos casos es necesario un conjunto de herramientas que generen ladescripcion VHDL a partir de la especificacion en dHDL.

3.2.3. dHDL, generacion y herramientas

Una de las ventajas de trabajar con lenguajes de descripcion hardware convencionales,como VHDL o Verilog, es el numero de herramientas disponibles para su desarrollo. Porello el lenguaje que aquı se propone, dHDL, se apoya en VHDL para realizar la descripcionfinal de los cores. Debido a que dHDL esta orientado a describir como generar cores, esnecesario disponer de herramientas que a partir de la descripcion dHDL generen el codigosintetizable del core en un lenguaje que permita utilizar estas herramientas de desarrollocomerciales. Aunque no es el objetivo de la Tesis la realizacion de estas herramientas, seha desarrollado un conjunto de prototipos para facilitar el manejo y la verificacion dellenguaje dHDL.

Con el lenguaje se ha desarrollado un conjunto de herramientas que permiten generarcodigo VHDL sintetizable a partir de la descripcion en dHDL. Mientras que en los lengua-jes tradicionales el proceso de generacion de un core parametrizable (estructura descritadentro de los generate de VHDL) se realiza durante la sıntesis del propio core, con dHDLesta generacion se realiza por las herramientas que dan soporte al lenguaje.


Figura 3.7: Proceso de generacion.

Que la generacion del core se realice de forma previa a la sıntesis proporciona unconjunto de ventajas respecto a los generate VHDL:

El proceso de generacion de codigo VHDL de un core dHDL, aun con cores complejos,es mucho mas rapido que la sıntesis. Si se implementan “informadores” en los cores,la informacion esta disponible mucho antes y con menos esfuerzo que si hay quesintetizar el componente.

El disenador puede depurar el codigo generado en busca de errores de la estructura,frente a post-sıntesis, donde el despliegue de la estructura lo realiza la herramientade sıntesis, y dependera de los informes que la herramienta le presente. De nuevola generacion de codigo sintetizable es un proceso mucho mas rapido que la propiasıntesis del diseno.

Las herramientas del lenguaje no solo abarcan la propia generacion del core, sino quetambien se han incorporado otras, como por ejemplo las orientadas a la generacion de unainterfaz grafica, que sirven como base para la implementacion de herramientas de cara alusuario de los cores.

Una primera version de las herramientas de generacion y presentacion se presento en[FHSLV03], donde la interfaz grafica permite la seleccion de un core dentro de una biblio-teca, para su posterior configuracion y generacion. En [FHSLV04] se modifica la interfazgrafica para que se ejecute como un applet Java dentro de un navegador, permitiendo denuevo la seleccion y configuracion del core de manera remota, mientras que la generacionse realiza en un servidor.

3.2.3.1. Generacion de codigo

Un core se describe dentro de varios ficheros de texto que en conjunto forman el codigofuente dHDL. Este codigo fuente se divide por una parte en la descripcion del encapsuladoestructural, y por otra parte en el propio codigo de la implementacion dHDL.

El proceso de generacion desde un fichero de codigo fuente dHDL a un core VHDLse divide en dos pasos. El primer paso analiza el codigo fuente del core dHDL para ob-tener codigo dHDL preprocesado, mientras que es en el segundo paso donde se realiza la


generacion a partir del codigo preprocesado.

En el primer paso, de preprocesado, se analizan tanto el encapsulado como la imple-mentacion, se verifica la correccion del codigo (estructuras, declaraciones, etc.), y tambienlas llamadas a elementos externos como pueden ser funciones o incluso otros cores.

A partir del codigo dHDL preprocesado una nueva herramienta se encarga de generar ladescripcion en VHDL sintetizable. Esta herramienta puede utilizarse por otras herramien-tas, como por ejemplo herramientas de generacion de cores (permiten seleccionar entre unconjunto de cores, configurarlos y generarlos), herramientas de estimacion (implementa-ciones orientadas a obtener informacion relacionada con el proceso de generacion), etc.

Los cores dHDL que constan de una interfaz especificada en con el encapsulado es-tructural y la propia implementacion descrita utilizando el lenguaje dHDL. Aunque en losproximos capıtulos se describiran ambos elementos de manera separada, el encapsuladoestructural y el lenguaje siempre van unidos para formar la descripcion de un componente.En la Figura 3.7 se muestra como la configuracion realizada en el encapsulado estructuralsirve para disparar el proceso de generacion ligado a la descripcion dHDL. Tras el procesode generacion se obtiene por una parte el core VHDL, y se devuelve hacia el encapsuladola informacion relacionada con el proceso.

3.3. Encapsulados y empaquetado

Con el encapsulado estructural no solo se permite realizar disenos con un alto gradode parametrizacion, sino que es posible incorporar informacion en la interfaz, que se puedeutilizar para integrar el componente dentro de otro diseno de manera automatica, ya seamediante las posibilidades que ofrece la declaracion de parametros, como limitar sus valoreso definir relaciones entre los mismos, o bien con los atributos del encapsulado.

Ademas de informacion relacionada con la propia implementacion, resulta de interesincorporar junto con la interfaz informacion de como se puede utilizar el diseno. En estesentido en la propuesta de esta Tesis se anaden dos nuevos elementos, por una parte losempaquetados del encapsulado estructural que permiten definir como configurar al com-ponente para implementar una funcion, y por otra parte el encapsulado funcional dondese define esta funcion, definicion que se puede utilizar para multiples implementaciones.

Implementar el empaquetado de un core requiere conocerlo en detalle, por lo que sudescripcion la debe realizar el propio disenador del core. El encapsulado funcional sirvecomo referencia para multiples empaquetados, y su definicion se realiza buscando carac-terısticas relevantes desde el punto de vista de la funcion para diferentes implementaciones,y por lo tanto no es necesario que la desarrolle el mismo disenador que realiza el core.

3.3.1. Busqueda de alternativas

Las Figuras 3.8 y 3.9 muestran como se relacionan los diferentes elementos propues-tos en el apartado anterior. En esta Tesis se definen un conjunto de bibliotecas tanto deencapsulados como de componentes. La correspondencia de los elementos entre el encapsu-lado funcional y el estructural se realizara mediante el empaquetado, que permite indicar

3.3 Encapsulados y empaquetado 37

Figura 3.8: Biblioteca de encapsulados: proceso top-down.

Figura 3.9: Biblioteca de encapsulados: proceso bottom-up.

como configurar el encapsulado estructural a partir de los elementos definidos del encap-sulado funcional, y si la configuracion obtenida cumple con las restricciones del propioencapsulado funcional, es decir, si realmente lo implementa.

Para obtener un core a partir de los elementos de la propuesta no es necesario partir delencapsulado funcional. A partir del encapsulado estructural se puede obtener la implemen-tacion del core, para ello el usuario debe proporcionar una configuracion valida a partirde la definida en este encapsulado estructural y generar el componente. Este proceso tieneasociado un conjunto de herramientas, vistas en el apartado 3.2.3, que permiten generarun core VHDL a partir de la especificacion en dHDL. Una vez generado el core se devuelvea la interfaz el resultado de la generacion, compuesta por el propio codigo generado perotambien el valor de los atributos que se han calculado durante el proceso.

Utilizar los encapsulados funcionales y empaquetados se corresponde con un procesomas amplio, en el que a priori no se conoce cual es la implementacion que mejor se adapta aciertos requisitos. Este proceso se designara como busqueda de alternativas, es mucho mas


amplio que el de obtener una unica implementacion a partir del encapsulado estructural,pero a su vez se encuentran relacionados. El empaquetado se convierte en el usuario delencapsulado estructural que proporciona la configuracion a partir de la cual se realiza laimplementacion y al que se le devuelve el resultado de la generacion.

El proceso de busqueda de alternativas por lo tanto se divide a su vez en dos procesos:

1. El primero busca obtener la implementacion de un core VHDL a partir de la in-formacion suministrada desde el encapsulado funcional, y se representa en la Figu-ra 3.8. En este proceso descendente, un usuario configura los elementos definidosen el encapsulado funcional (caracterısticas), generando un conjunto de restriccio-nes sobre los disenos que lo implementan. Con el conjunto de restricciones se puedeautomatizar el proceso de busqueda de implementaciones dentro de la biblioteca deempaquetados, dando como resultado una lista de empaquetados que son posiblesimplementaciones del encapsulado funcional. Se puede entonces realizar un procesoiterativo, donde a cada uno de los empaquetados seleccionados se le pasa el conjuntode restricciones, y el empaquetado las traduce en una configuracion del core al querepresenta, y que configura mediante su correspondiente encapsulado estructural. Apartir de este punto se puede generar e implementar el core y obtener informacionde la implementacion, que queda recogida en elementos del encapsulado estructural(atributos).

2. El segundo proceso en la busqueda de alternativas se representa en la Figura 3.9, yparte del conjunto de cores VHDL generado junto con la informacion relacionadacon el proceso de generacion, que se ha recogido en el encapsulado estructural. Estainformacion se devolvera al empaquetado que inicio su generacion. El empaquetado,a partir tanto de la informacion devuelta, junto con el propio conocimiento de laimplementacion que hace el core, podra determinar que caracterısticas del empa-quetado funcional cumple la implementacion. El encapsulado funcional obtendra detodos los empaquetados que lo implementan la lista de caracterısticas que cada unode ellos cumplen, pudiendo determinar por ejemplo que implementacion es la masapropiada.

En la Figura 3.10 se representan diferentes implementaciones que se pueden encontrardentro del espacio de diseno. Se pueden encontrar implementaciones con dHDL que encap-sulan diferentes cores VHDL, como las representadas en la Figura 3.5, o cores especificadosen dHDL con un alto grado de parametrizacion como los representados en la Figura 3.6.En ambos casos resulta difıcil que la implementacion cubra todo el espacio de diseno,mientras que el proceso de busqueda de alternativas muestra a un disenador de sistemassi existen implementaciones dentro del espacio de diseno requerido para su aplicacion, o almenos que implementaciones se encuentran mas proximas a los requisitos de la aplicacion.

3.3.2. Ejemplo

Durante el capıtulo se han indicado los diferentes elementos propuestos en esta Tesis.En la Figura 3.11 se muestra un ejemplo de su aplicacion para encapsular un componentepreviamente disenado, como puede ser un core DSP48E.

3.3 Encapsulados y empaquetado 39

Figura 3.10: Core dHDL.

1. Por medio del encapsulado estructural y el lenguaje dHDL se implementa un envol-torio del componente VHDL, con una interfaz de reutilizacion ampliada.

El nuevo encapsulado ofrece el mismo conjunto de parametros y puertos parala comunicacion con el componente que la instancia VHDL.

La declaracion de los parametros permite verificar la correccion de los valo-res introducidos, estableciendo restricciones en los valores y relaciones entreparametros.

Dependiendo de la configuracion seleccionada, se habilitan y deshabilitan lospuertos del componete mediante el envoltorio dHDL.

El encapsulado estructural permite informar de atributos, cuyo valor se calculadurante la instanciacion que se realiza en el envoltorio dHDL.

2. El componente puede implementar multiples funciones, por ejemplo las funcionessuma o multiplicacion. Junto con el encapsulado estructural se pueden definir dife-rentes empaquetados, al menos uno por funcion, que especifican como configurar alcore.

El empaquetado permite indicar al disenador como configurar y como conectaral componente para implementar la funcion.

Este elemento, a partir de la informacion disponible de la implementacion,define si realmente cumple los requisitos que se puedan imponer en la funcion.

Al implementar el empaquetado, el componente se ofrece como solucion paraimplementar la funcion, y es dado a conocer a otros disenadores, potenciandosesu posible reutilizacion.

3. El empaquetado fija la configuracion del encapsulado estructural mediante restric-ciones fijadas por el encapsulado funcional al que implementa.


Figura 3.11: Conjunto de encapsulados y empaquetado para el DSP48E.

4. Desde el punto de vista de los encapsulados funcionales, los empaquetados delDSP48E representan una alternativa de implementacion. Otros componentes tam-bien pueden proponer una implementacion con otro empaquetado diferente. El en-capsulado funcional fijara un conjunto de restricciones que pasara a todos los em-paquetados que lo implementan, obteniendo de cada uno de ellos una lista con lasrestricciones que realmente implementa.

El encapsulado funcional no describe implementaciones concretas, sino carac-terısticas que pueden presentar multiples implementaciones.

Al dar valor a las caracterısticas, estas se vuelven restricciones con las queverificar las posibles implementaciones.

3.4. Conclusiones

En el capıtulo se ha justificado el enfoque de reutilizacion propuesto que ha dado lugara los elementos que se van a desarrollar en los siguientes capıtulos de la Tesis. Los coresdHDL que constan de una interfaz especificada con el encapsulado estructural y la propiaimplementacion descrita utilizando el lenguaje dHDL. Aunque en los proximos capıtulosse describiran ambos elementos de manera separada, el encapsulado estructural y el len-guaje siempre van unidos para formar la descripcion de un componente. Ambos elementospermiten tanto envolver componentes descritos en VHDL, como se pueden utilizar parala especificacion de cores dHDL completos.

En la propuesta se anaden nuevos elementos para mejorar la informacion de interfaz delos cores descritos en dHDL y simplificar el proceso de exploracion de alternativas. Estoselementos se corresponden con la definicion de un nuevo nivel de encapsulado, el funcional,y el empaquetado que se incorpora como una extension del encapsulado estructural.

Capıtulo 4

Especificacion para la generaciondinamica de codigo

4.1. Introduccion

Dado el alto coste asociado al desarrollo de cores hardware, es deseable que se puedanreutilizar en diferentes aplicaciones. Normalmente, un core no puede reutilizarse directa-mente, sino que es necesario realizar ajustes de sus caracterısticas para adaptarlo a la nuevaaplicacion. Luego, cuanto mayor grado de parametrizacion proporcione el core, mayoresposibilidades de reutilizacion ofrece.

Las posibilidades de parametrizacion de un core hardware vienen dadas en gran partepor el lenguaje utilizado para su implementacion. Los lenguajes de descripcion hardwaretradicionales, como VHDL o Verilog, permiten la declaracion de parametros genericos,que posibilitan variar algunas caracterısticas del core. Pero, para la generalizacion de uncore tambien son importantes estructuras de control que permitan modificar la estructuradel core, o como se ha de generar dicha estructura. En VHDL se pueden encontrar lasestructuras generate, que permiten la generacion dinamica de estructuras repetitivas ycondicionales.

El problema con los lenguajes tradicionales es que ofrecen unas capacidades muy li-mitadas para la generacion de cores parametrizables, con lo que solo permiten realizarpequenas variaciones en el diseno. En este capıtulo se presentara el lenguaje dHDL (dy-namic HDL), que ha sido concebido para aumentar las capacidades de generacion de loslenguajes tradicionales, lo que mejora las posibilidades de parametrizacion de los disenos,y con ello las posibilidades de reutilizacion en diferentes aplicaciones. Una primera versiondel lenguaje se encuentra en [SFLV04, SFHLV05], aunque dicha version ha sido revisada yampliada mediante la inclusion de nuevos tipos y funcionalidades que mejoran el procesode especificacion y parametrizacion con el lenguaje, [SEMLV08, ESLVLB09].

Frente a los HDL clasicos, dHDL se centra en describir como se genera una estructura,aportando flexibilidad y simplicidad a los lenguajes convencionales. La descripcion decores con este lenguaje se realiza utilizando ficheros fuente que a su vez se dividen enla declaracion de la interfaz y en implementacion. La interfaz del lenguaje se definira enprofundidad en el apartado 5.2 del siguiente capıtulo, mientras que este capıtulo se centraen la descripcion del lenguaje dHDL y su uso.

42 Especificacion para la generacion dinamica de codigo

Resumiendo, las ventajas del uso de dHDL son:

Simplifica la descripcion jerarquica y estructural.

Tipos y procedimientos del lenguaje sencillos.

• Definen cuando y como se genera el codigo VHDL.

• Posibilitan la evaluacion de componentes de manera previa su instanciacion.

• Adaptacion de la estructura en funcion de componentes ya generados.

Aumenta el grado de parametrizacion.

Permite incorporar informacion de la implementacion en la interfaz.

Dado que los cores del lenguaje no se pueden implementar directamente con las herra-mientas EDA comerciales, es necesario utilizar un conjunto de herramientas para generaruna descripcion de estos core en VHDL sintetizable a partir de la descripcion en dHDL.dHDL no ha sido concebido para especificar directamente la funcionalidad de un diseno,sino para describir como se genera la descripcion VHDL de este diseno. Por lo tanto, esbasico comprender que la descripcion utilizando este lenguaje esta ligada a un proceso degeneracion de codigo que requiere de las herramientas necesarias, visto en el apartado 3.2.3.Antes de comenzar con la descripcion del lenguaje, se mostraran ejemplos sencillos de suuso y el codigo obtenido en VHDL.

4.2. Ejemplos de codigo

Como se indico en el capıtulo 3, los cores dHDL combinan un encapsulado estructuralpara la declaracion de la interfaz con la propia especificacion en dHDL. Su estructura secompone por lo tanto:

Interfaz, que se corresponde con el encapsulado estructural, declara:

• Parametros.

• Atributos.

• Macropuertos.

Descripcion en dHDL:

• Estructuras de control.

• Declaraciones de tipos y procedimientos que implementan los tipos.

◦ Variables.

◦ Senales.

◦ Puertos.

◦ Entidades.

◦ Componentes.

• Inserciones de codigo.

4.2 Ejemplos de codigo 43

Ejemplo 4.1 Especificacion de memoria ROM con VHDL.library ieee;

use ieee.std_logic_1164.all;

use ieee.std_logic_unsigned.all;

entity roms is

port (

CLK : in std_logic;

EN : in std_logic;

ADDR : in std_logic_vector(5 downto 0);

DATA : out std_logic_vector(19 downto 0));

end roms;

architecture arch of rams is

type rom_type is array (63 downto 0)

of std_logic_vector (19 downto 0);

signal ROM : rom_type:= (

X"0200A", X"00300", X"08101", X"04000", X"08601", X"0233A",

X"00300", X"08602", X"02310", X"0203B", X"08300", X"04002",

X"08201", X"00500", X"04001", X"02500", X"00340", X"00241",

X"04002", X"08300", X"08201", X"00500", X"08101", X"00602",

X"04003", X"0241E", X"00301", X"00102", X"02122", X"02021",

X"00301", X"00102", X"02222", X"04001", X"00342", X"0232B",

X"00900", X"00302", X"00102", X"04002", X"00900", X"08201",

X"02023", X"00303", X"02433", X"00301", X"04004", X"00301",

X"00102", X"02137", X"02036", X"00301", X"00102", X"02237",

X"04004", X"00304", X"04040", X"02500", X"02500", X"02500",

X"0030D", X"02341", X"08201", X"0400D");

signal rdata : std_logic_vector(19 downto 0);

begin

rdata <= ROM(conv_integer(ADDR));

process (CLK)

begin

if (CLK’event and CLK = ’1’) then

if (EN = ’1’) then

DATA <= rdata;

end if;

end if;

end process;

end arch;

Ejemplo 4.2 Especificacion de memoria ROM con dHDL.decl {

type rom_type is array ([DEPTH]-1 downto 0)

of std_logic_vector ([WIDTH]-1 downto 0);

signal ROM : rom_type:= ( }

variable index = 0;

while ( index < DEPTH ) {

variable romvar = ex.H_ROM(index, WIDTH, DEPTH);

decl { [romvar] }

if ( index != Dec1(DEPTH) ) { decl { , }

} else { decl { ); } }

index = Inc(index)

}

signal rdrom : WIDTH;

arch {

[rdrom] <= ROM(conv_integer([ADDR.data]));

process ([ADDR.clock])

begin

if ([ADDR.clock]’event and [ADDR.clock]=’1’) then

if ([ADDR.enable] = ’1’) then

[DATA.data] <= [rdata];

end if;

end if;

end process;

}

dHDL implementa mecanismos basicos que permiten particularizar codigo VHDL den-tro de una estructura de generacion. Esta caracterıstica resulta de utilidad, por ejemplo,para la especificacion de memorias ROM. El Ejemplo 4.1 muestra como se implementauna memoria de este tipo con VHDL.

La especificacion en VHDL presenta numerosas desventajas. El numero de coeficientes,que determina el tamano de la ROM, estan fijados con la propia implementacion. Demanera analoga, el numero de bits de cada coeficiente tambien queda fijado. En el casode ser necesario ampliar, tanto el numero de bits de los coeficientes, como el numero decoeficientes, es necesario volver a especificar una nueva memoria.

En el Ejemplo 4.2 se muestra como se implementarıa con dHDL un componente quegenere una ROM similar a la del Ejemplo 4.1 en VHDL. La especificacion con dHDLpermite que los coeficientes de la ROM se calculen durante la generacion del componente,con lo que se pueden definir los parametros WIDTH que precisa la anchura en bits de loscoeficientes y DEPTH que permite especificar la profundidad de la memoria generada. Elvalor de los coeficientes se calcula durante la generacion de la memoria por medio de lallamada a la funcion ex.H ROM. El Ejemplo 4.3 muestra la declaracion del encapsuladoestructural que define la interfaz de este componente.

Para la especificacion de la memoria del Ejemplo 4.2 se ha utilizado uno de los metodosmas basico que proporciona dHDL, las sustituciones de codigo que se veran en el apar-tado 4.4.3. Sin embargo, la especificacion con dHDL esta enfocada a la reutilizacion decomponentes y la especificacion estructural. En el Ejemplo 4.4 se muestra la descripcionen dHDL de una cadena de componentes, que primero multiplican y luego suman, quegenera una estructura como la representada en la Figura 4.1. En cada iteracion del lazo,se seleccionara uno de los componentes, sumador o multiplicador, y se configura con laanchura en bits obtenida a partir de la salida del componente de la iteracion anterior.


Ejemplo 4.3 Encapsulado estructural para el Ejemplo 4.2.<declaration coreid="rom_ex"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="xsdhdl.xsd">

<parameters>

<parameter id="WIDTH">

<type>integer</type>

<value><vall>8</vall></value>

</parameter>

<parameter id="DEPTH">



</parameter>

</parameters>

<macroports>

<macroport id="DATA">

<type>MEM_O</type>

<parameter id="width_data">

<value><vall>WIDTH</vall></value>

</parameter>

<parameter id="width_address">

<value><valf id="log2">

<value><vall>DEPTH</vall></value>

</valf></value>

</parameter>

</macroport>

</macroports>

</declaration>

Ejemplo 4.4 dHDL: Cadena de operaciones Multiplica y Suma.entity dhdl ex_mul = ex.Multiplier;

entity dhdl ex_add = ex.Adder;

variable ptr_v = IDATA;

variable cmp_v;

variable index = 0;

while ( index < Mult(3, STAGES) ) {

if ( Mod(index,2) == 0 ) {

ex_mul.generics(WIDTH = ptr_y.data.width);

component c = ex_reg->generate;

cmp_v = c;

} else {

ex_add.generics(WIDTH = ptr_y.data.width);

component c = ex_add->generate;

cmp_v = c;

}

port p_a : cmp_v->port("A");

port p_b : cmp_v->port("B");

port p_o : cmp_v->port("O");

c_a.adapter(ptr_v);

c_b.adapter(ptr_v);

cmp_v.ports;

ptr_v = p_o;

Inc(index);

}

ODATA.adapter(ptr_v);

El componente es entonces generado e incluido en el core VHDL que se entregara. En elEjemplo 4.5 se muestra el aspecto que tendra el codigo VHDL generado.

En lo que resta de capıtulo, primero se introduciran los tipos que se declaran en lainterfaz y que se veran con mas detalle en el capıtulo 5, para a continuacion se describiren detalle el lenguaje dHDL, y como su enfoque simplifica la descripcion estructural dedisenos hardware. Para terminar se presentara un conjunto sencillo de ejemplos de uso.

4.3. Interfaz

En el siguiente capıtulo, dedicado a encapsulados para la reutilizacion, en el apartado5.2 se presentara la definicion y fundamentos del encapsulado estructural que utiliza comointerfaz para el codigo fuente dHDL. Con este encapsulado se permite declarar elementosque configuran el core (parametros), elementos con los que informar de caracterısticaspropias del componente (atributos), y finalmente la entrada-salida del componente sedefinira mediante el uso de macropuertos. Antes de continuar, se adelantaran aquı loselementos principales de este encapsulado para dHDL.

Figura 4.1: Estructura del ejemplo 4.4.

4.3 Interfaz 45

Ejemplo 4.5 Codigo VHDL generado de la cadena de operaciones Multiplica y Suma: 1Etapa.entity ex_muladd is

port (

clock : in std_logic;

enable : in std_logic;

IDATA_data : in std_logic_vector(3 downto 0);

ODATA_data : out std_logic_vector(8 downto 0));

end ex_muladd;

architecture arch of ex_muladd is

signal ex_adp_i0_o_data : std_logic_vector(3 downto 0);


signal ex_mul_i2_o_data : std_logic_vector(7 downto 0);



signal ex_add_i5_o_data : std_logic_vector(8 downto 0);

begin

ex_adp_i0 : entity work.ex_adp_width4 port map (

clock => clock, enable => enable,

I_data => IDATA_data , O_data => ex_adp_io_o_data);



I_data => IDATA_data , O_data => ex_adp_i1_o_data);

ex_mult_i2 : entity work.ex_mul_width4 port map (


A_data => ex_adp_io_o_data , B_data => ex_adp_i1_o_data,

O => ex_mul_i2_o_data);



I_data => ex_mul_i2_o_data, O_data => ex_adp_i3_o_data);



I_data => ex_mul_i2_o_data, O_data => ex_adp_i4_o_data);

ex_add_i5 : entity work.ex_add_width8 port map (


A_data =>ex_adp_i3_o_data, B_data => ex_adp_i4_o_data,

O => ex_add_i5_o_data);



I_data => ex_add_i5_o_data, O_data => ODATA_data);

end arch;

4.3.1. Parametros

Como se detallara en el apartado 5.2.2 del siguiente capıtulo, en el encapsulado es-tructural se pueden definir y declarar los parametros que van a configurar el core: unparametro se compondra de un identificador unico, un tipo y un valor.

El identificador y el tipo del parametro vienen fijados en el encapsulado estructural,pero su valor puede modificarse respecto del valor de inicializacion, por ejemplo medianteuna herramienta de configuracion de cores o incluso al instanciar el componente como partede otro componente. Los parametros cuyo valor no se modifique tomaran el valor definidopor defecto. En el Ejemplo 4.6, si no se modifica el valor de inicializacion del parametroaddr width, este se fijara evaluando una funcion de otro parametro (depth width).

Ejemplo 4.6 Declaracion de un parametro con funcion....

<parameter id="addr_width">

<description>...</description>

<type>addrwidthtype</type>

<value>

<valf id="log2">

<arg><vall>depth_width</vall></arg>

</valf>

</value>

</parameter>

...

Durante el proceso de generacion de la implementacion dHDL el parametro se com-portara como una constante: se puede consultar el valor fijado a traves de su identificador,pero no puede modificarse.

4.3.2. Atributos

En el apartado 5.2.3 se describira como se definen y declaran los atributos en el en-capsulado estructural: un atributo se compondra de un identificador unico, un tipo y unvalor.

Como sucede con los parametros, tanto el identificador como el tipo se fijan en el


encapsulado. Sin embargo, su valor inicial se fija al comenzar la generacion: a un valorliteral o al resultado de evaluar una funcion del valor fijado en los parametros. En elEjemplo 4.7 se inicializara el atributo latency al valor 0.

Ejemplo 4.7 Declaracion de un atributo e inicializacion a constante....

<attribute id="latency">


<type>int8</type>


</attribute>

...

A diferencia de los parametros, durante la generacion del core los atributos se com-portan como variables globales: su valor puede consultarse y modificarse a traves de suidentificador.

El atributo latency, declarado en el Ejemplo 4.7, podra actualizarse a medida quese introduzcan registros de pipeline durante la generacion de la estructura, y su valorconsultarse externamente tras la generacion del core (vıa herramienta o desde un core queinstancie al componente).

4.3.3. Macropuertos

Una de las dificultades durante la reutilizacion de componentes en otros disenos esla falta de uniformidad en la interfaz fısica, no solo en la propia nomenclatura de lassenales que las forman, sino tambien en otros aspectos, como son los tipos de puertos, suagrupamiento y la relacion entre distintos puertos, la temporizacion, etc.

Por ello, en dHDL la declaracion de los puertos se basa en la utilizacion de tipos depuertos que estan predefinidos: los macropuertos. Cada uno de estos macropuertos agrupaa todo un conjunto de senales, junto con su direccionalidad, que ademas estan obligadas acumplir un protocolo. Desde el punto de vista practico, la declaracion de un macropuertodHDL equivale a varios puertos VHDL. En el apartado 5.2.4 se describira la declaracionde macropuertos en el encapsulado estructural.

Ejemplo 4.8 Declaracion de un macropuerto....

<macroport id="data_i">

<description>Input data ...</description>

<type>lvi</type>

<property id="width">

<value><vall>data_width</vall></value>

</property>

</macroport>

...

Los elementos basicos de un macropuerto son su identificador unico y el tipo de ma-cropuerto que implementa. Opcionalmente durante la declaracion de un macropuerto sepodran configurar parametros que lo configuran. En el Ejemplo 4.8 se declara el macro-puerto data i como el tipo lvi y se configura el parametro width del macropuerto apartir del valor data width (parametro del componente).

Como se ha mencionado, un macropuerto agrupa en una declaracion varios puertos,

4.3 Interfaz 47

y es posible que durante la declaracion de un core un unico puerto se comparta en ladeclaracion de varios macropuertos. En el Ejemplo 4.9 se declaran tres macropuertos:data i y addr p de tipo lvi, y el macropuerto data o de tipo lvo. Los macropuertos detipo lvi y lvo se componen de tres puertos: clock, enable y data, la unica diferencia esque para el tipo lvi todos son de entrada, mientras que con lvo son de salida.

Ejemplo 4.9 Agrupacion de senales entre macropuertos....


...

</macroport>

<macroport id="addr_p">

...

</macroport>

<macroport id="data_o">

...

</macroport>

...

<net id="clock">

<type>sync_clk</type>

<mport id="data_i" signal="clock" />

<mport id="addr_p" signal="clock" />

<mport id="data_o" signal="clock" />

</net>

...

En el Ejemplo 4.9 se muestra como se agrupan bajo una misma red, clock, los dife-rentes puertos de reloj de los tres macropuertos declarados. En el Ejemplo 4.10 se muestraun ejemplo de codigo generado sin agrupar el puerto de reloj: cada macropuerto declarasu propio puerto de reloj. En el Ejemplo 4.11 se muestra el codigo generado en el casode agrupar el puerto de reloj, en este caso solo se realiza una unica declaracion, que secorresponde con la especificacion del Ejemplo 4.8.

Ejemplo 4.10 Ejemplo de codigo generado sin agrupacion de puertos.entity example

port (

data_i_clock : in std_logic;

data_i_enable : in std_logic;

data_i_data : in std_logic_vector(7 downto 0);

addr_p_clock : in std_logic;

addr_p_enable : in std_logic;

addr_p_data : in std_logic_vector(3 downto 0);

data_o_clock : out std_logic;

data_o_enable : out std_logic;

data_o_data : out std_logic_vector(7 downto 0) );

Ejemplo 4.11 Ejemplo de codigo generado con agrupacion de puertos.entity example

port (

clock : in std_logic;

data_i_enable : in std_logic;

data_i_data : in std_logic_vector(7 downto 0);

addr_p_enable : in std_logic;

addr_p_data : in std_logic_vector(3 downto 0);

data_o_enable : out std_logic;

data_o_data : out std_logic_vector(7 downto 0) );

Aunque el uso de los macropuertos se ha pensado para simplificar la interconexionde componentes, a veces puede resultar de utilidad acceder a informacion contenida en elmacropuerto declarado: tipo, puertos internos, parametros de configuracion, caracterısticasgenerales definidas en el macropuerto, caracterısticas particulares de cada puerto que lecompone, etc.

Todos los elementos que se declararan posteriormente en dHDL componen un tipocomplejo que permite acceder a toda esta informacion. En el Ejemplo 4.12 se muestra


como durante la implementacion se asigna a dos variables del lenguaje (se veran masadelante) una referencia al puerto de datos de un macropuerto, y la anchura del dichopuerto.

Ejemplo 4.12 Acceso a puerto interno del macropuerto....

d = data_i.data;

w = data_i.data->attributte("width");

...

4.4. Especificacion para la generacion dinamica dehardware

Este apartado se dedica a la descripcion de la implementacion de la arquitectura, enla que dHDL busca mejorar las capacidades de generalizacion, generacion y reutilizacionde los lenguajes tradicionales.

Durante la descripcion de un core basado en otros cores, prima la descripcion estruc-tural frente a la comportamental: el core es un conjunto de instancias de componentes,de las interconexiones entre estos componentes y los puertos del propio core. dHDL se hadefinido para facilitar y ayudar en este tipo de descripcion, mediante la inclusion tanto detipos como de mecanismos que ayuden al disenador en esta tarea.

Ademas se ha incluido en el lenguaje un mecanismo que permite insertar codigo VHDL,lo que posibilita utilizar la potencia de este lenguaje en la descripcion de comportamiento.

Las construcciones del lenguaje para esta seccion pueden dividirse en los siguientestipos:

Estructuras de control

Declaraciones

Inserciones de codigo

En el codigo fuente dHDL es posible utilizar todos los tipos de datos declarados en elencapsulado: puertos, parametros y atributos. Tambien es necesario declarar nuevos tipospara especificar la estructura y controlar su generacion:

variables

senales

puertos

entidades

componentes

4.4 Especificacion para la generacion dinamica de hardware 49

A diferencia de VHDL, las declaraciones se pueden realizar en cualquier lugar, con launica condicion de que los tipos se declaren antes de ser utilizados. Ademas, las declaracio-nes tienen visibilidad, es decir, unicamente son validas dentro de la estructura de controlen la que fueron declaradas.

En este apartado primero se explicaran las estructuras que controlan la generacion delcore. Posteriormente se detallaran los tipos que se pueden declarar durante la descripciondHDL. Finalmente, se describira como se realizan las inserciones de codigo VHDL en elcodigo dHDL.

4.4.1. Estructuras de control

Una de las claves de dHDL lo constituyen las estructuras de control. Estas estructuraspermiten al disenador controlar el flujo de generacion del core y con ello la estructuraque toma el componente. Las estructuras de control definidas en el lenguaje son masflexibles que las permitidas en VHDL lo que a su vez simplifica al disenador el procesode descripcion. Ademas aportan visibilidad a los tipos definidos y pueden encadenarse yanidarse entre sı.

Las estructuras de control definidas son de dos tipos: condicionales mediante estructu-ras de tipo if-else e iterativas mediante el tipo while.

Ejemplo 4.13 Estructura de control condicional if-else.if ( ... ) {

...

}

if ( ... ) {

...

} else {

...

}

if ( ... ) {

...

} else if ( ... ) {

...

}

Ejemplo 4.14 Estructura de control iterativa while y ejemplo de condiciones.

while ( ... ) {

...

}

while ( index < 10 ) {

if ( index == 1 ) {

...

} else if ( (Mod2(index) == 0)

&& (index < 5) ) {

...

} else {

...

}

}

Las estructuras condicionales estan basadas en estructuras if-else. Como se puedeobservar en el Ejemplo 4.13, no solo se puede evaluar la opcion else, sino que ademasel lenguaje permite encadenar nuevas estructuras condicionales tras el else.

Las estructuras iterativas se basan en construcciones while, con la evaluacion deuna condicion previa a la ejecucion del lazo, como se muestra en el Ejemplo 4.14.


Las condiciones que evaluan en ambas estructuras pueden ser sencillas, realizadas me-diante operadores relacionales (==, ! =, >, >=, <, <=), o compuestas realizadas conoperadores logicos (&& y ||) que permiten encadenar varias condiciones sencillas.

En el Ejemplo 4.14 tambien se muestra como en la evaluacion de las condiciones sepuede utilizar tipos dHDL como por ejemplo parametros, variables, etc., o incluso llamadasa funciones dHDL.

Por el momento solo se han definido las dos estructuras de control descritas ante-riormente. No obstante, en futuras versiones del lenguaje se puedan incorporar nuevasestructuras de control como puede ser case, for, etc.

4.4.2. Declaraciones

En el presente apartado se describe el conjunto de tipos que se pueden declarar durantela implementacion de un core dHDL. Algunas caracterısticas de estos tipos incluyen:

Como se ha mencionado anteriormente, dHDL esta orientado a la generacion de codi-go VHDL. Parte de los tipos, al realizar su declaracion disparan la generacion decodigo, otros tipos permiten realizar una referencia a otros elementos del lenguaje ygeneraran codigo solo si se produce una llamada especıfica a un procedimiento. Final-mente, el lenguaje permite declarar tipos auxiliares para el control de la generacionque no tienen visibilidad en el codigo generado.

Todos los tipos basicos tienen ambito o visibilidad, y se corresponde a la estructurade control donde fueron declarados.

El lenguaje es case sensitive. Un mismo identificador puede utilizarse para referenciarelementos diferentes del lenguaje. En el Ejemplo 4.16 se muestra como dec2bin

identifica a una variable del lenguaje, mientras que Dec2Bin sirve para identificar auna funcion.

4.4.2.1. Variables (variable)

Las variables son un tipo dHDL utilizado para almacenar valores o referencias a otroselementos de este lenguaje. Para su declaracion se utiliza la palabra reservada variable

seguida del identificador. Opcionalmente se puede inicializar con un valor, como se muestraen el Ejemplo 4.15.

Ejemplo 4.15 Declaracion de variable.

variable int_width = WIDTH;

La variable no tiene un tipo definido por defecto, sino que depende de su uso. Puedealmacenar valores enteros, flotantes, etc., y su valor final dependera del uso que el disenadordel core le de.

En el Ejemplo 4.16 se ha declarado una variable index que utiliza como ındice de unbucle, guardando valores enteros. En la evaluacion de la condicion del bucle se comparasu valor almacenado con un literal entero, provocando una comparacion entre enteros.


Ejemplo 4.16 Declaracion de variables e inicializacion con llamada a funcion.variable index = 0;


variable dec2bin = Dec2Bin(index, 8);

decl {

constant ROM[index] :

std_logic_vector(7 downto 0) := "[dec2bin]"; }

index = Inc(index)

}

Ejemplo 4.17 Codigo generado por el Ejemplo 4.16.constant ROM0 := std_logic_vector(7 downto 0) := "00000000";

constant ROM1 := std_logic_vector(7 downto 0) := "00000001";







Dentro del bucle se declara una segunda variable, dec2bin, que se inicializa mediante unallamada a la funcion del lenguaje Dec2Bin, la cual convierte un numero entero, en nuestroejemplo el valor de index, a su representacion en binario con una precision determinadapor el segundo argumento de la funcion, que en el ejemplo es un literal entero de valor 8.En la siguiente lınea se hace una insercion de codigo VHDL en la que se accede al valorcontenido en las variables index y dec2bin. Finalmente se actualiza el valor de la variablede ındice mediante una nueva llamada a una funcion dHDL Inc.

El resultado de la generacion del codigo del Ejemplo 4.16 producira una salida enVHDL similar a la mostrada en el Ejemplo 4.17. Como se puede observar en el ejemplo, lasvariables del lenguaje no tienen un tipo definido, mientras que es el contexto el que asignael tipo a la variable. Por ejemplo, al evaluar la condicion del bucle con un literal entero,el lenguaje espera que el tipo de la variable sea tambien un entero o pueda convertirse enentero, si no se producira un error durante la comparacion por ser tipos incompatibles.Por lo tanto es responsabilidad del disenador del core su correcto uso.

Las variables dHDL se han disenado conscientemente para ser no tipadas y con el obje-tivo de ser lo mas versatiles posible. Por una parte, la falta de tipado permite al disenadoruna mayor flexibilidad en su uso, por ejemplo, una misma variable puede almacenar dife-rentes tipos en una misma generacion. Sin embargo, esta flexibilidad obliga al disenadora cuidar el uso que le esta dando a las variables.

A veces puede resultar de utilidad declarar un array de variables. En los arrays devariables no es posible declarar e inicializar su valor, sino que se ha de acceder a cada unade las posiciones del array, utilizando una estructura de control iterativa, para darles elvalor correcto, como se muestra en el codigo del Ejemplo 4.18.

Las variables, como sucede con los distintos tipos definidos en dHDL durante la des-cripcion de la arquitectura, tienen visibilidad dentro del fichero fuente del lenguaje, que secorresponde con la estructura de control donde fueron declaradas. Si se declara una mismavariable dentro de una estructura de control anidada, en la estructura se podra acceder ymodificar la variable interna, pero sin alterar a la variable externa.


Ejemplo 4.18 Declaracion de array de variables.variable index = 0;

variable data[4];


data[index] = index;

index = Inc(index);

}

Este tipo de enfoque, donde la visibilidad de los tipos esta restringida a la estructurade control en la que fueron declarados, simplifica el proceso de diseno al permitir declararlos tipos unicamente cuando son necesarios. Sin embargo, surge el problema de que puedeser necesario acceder a un tipo fuera de la estructura de control donde se declaro.

Las variables del lenguaje permiten almacenar referencias a otros tipos, como puertoso senales del lenguaje, con lo que es posible transportar dichos tipos fuera de la estructurade control donde se definieron. Cuando una variable almacena una referencia a otro tipo,pasa a comportarse como el tipo al que referencia, hasta que a la variable se le asigne unnuevo valor u otra referencia.

En los ejemplos de diseno del lenguaje, del apartado 4.5, se pueden encontrar ejemplosde uso de variables para almacenar referencias a otros elementos del lenguaje.

4.4.2.2. Senales (signal)

Este tipo se encuentra muy relacionado con su correspondiente tipo en VHDL aunquepresenta algunas diferencias. Una senal dHDL es una referencia a la senal VHDL que sedeclarara y utilizara durante la generacion del core.

Para la declaracion de la senal se utiliza la palabra reservada signal seguida delidentificador de la senal dHDL y finalmente el ancho de bit de la senal. Opcionalmentese puede declarar un array de senales anadiendo el numero de senales a generar entrecorchetes, entre el identificador y el ancho de bit.

Ejemplo 4.19 Declaracion de senales dHDL....

variable width_stage = WIDTH;

...

signal data_stage [RADIX] : width_stage;

...

En el Ejemplo 4.19 se muestra como se ha declarado un array de senales dHDL: ladimension del array depende de un parametro del componente, mientras que el ancho debit se obtiene a partir del valor de una variable width stage, que puede haber modificadosu valor de inicializacion durante el proceso de generacion.

Al igual que las variables, las senales del lenguaje tienen visibilidad, que se correspondecon la estructura de control en la que han sido declaradas. Para mantener la referencia auna senal fuera del ambito donde fueron declaradas se utilizan las variables.

En el Ejemplo 4.20 se ha declarado la variable output signal que se utilizara paraalmacenar referencias a senales. En el bucle existen dos alternativas que, en funcion de laejecucion, generaran estructuras diferentes con senales de salida diferentes: s0 y s1. Sinla posibilidad de utilizar las variables para almacenar referencias, dichas senales dHDL


Ejemplo 4.20 Visibilidad de senales dHDL....

variable output_signal;

...

while ( ... ) {

...

if ( ... ) {

...

signal s0 : WIDTH;

...

output_signal = s0;

} else {

...

signal s1 : WIDTH;

...

output_signal = s1;

}

...

}

...

se perderıan al salir de la estructura condicional donde se declararon. En el ejemplo, lavariable output signal se utiliza para almacenar la referencia a dicha senal antes de salirde la estructura de control condicional. En cada iteracion la variable se utiliza como senalde entrada, almacenando siempre la referencia a la ultima senal declarada en la iteracionanterior.

Al acotar las senales a la estructura de control donde son declaradas, por una partese simplifica el proceso de diseno, ya que no es necesario recordar si se ha declarado lasenal en una zona separada de la propia utilizacion, como sucede en VHDL, a la vez quedichas senales son generadas unicamente si durante el proceso de generacion se ejecutael codigo de la estructura de control en la que esta declarada. Ademas, una misma senaldHDL puede utilizarse para definir multiples senales VHDL, como se puede observar enel Ejemplo 4.20.

4.4.2.3. Puertos (port)

Como ya se menciono en el apartado 4.3.3, los puertos declarados en el encapsuladoestructural que sirve de interfaz de dHDL se forman por un conjunto de senales agrupadassegun un protocolo. Para poder manipularlos dentro de los fichero fuente del lenguaje seha definido el tipo port, cuya declaracion puede verse en el Ejemplo 4.21.

A diferencia del tipo definido en la interfaz del core, los puertos declarados durante ladescripcion de la implementacion no generan pines, sino que es un tipo destinado a facilitarel uso de los macropuertos del lenguaje y a simplificar el proceso de interconexionado entrelos componentes dentro de la descripcion del core, como se vera mas adelante.

Ejemplo 4.21 Declaracion de puertos dHDL....

port data_in : lvi ( WIDTH = 8 );

port data_out : lvo ( WIDTH = 8 );

...

En la declaracion se utiliza la palabra reservada port, seguida del identificador depuerto y finalmente se declara el tipo, en el caso del Ejemplo 4.21 los tipos lvi y lvo.


Como los macropuertos de la interfaz del lenguaje pueden a su vez tener parametros deconfiguracion, tras la declaracion del tipo se inicializaran los parametros del puerto en unlistado contenido entre parentesis.

Ejemplo 4.22 Puertos de un macropuerto dHDL....


...

port data_in : lvi ( WIDTH = 8 );

...

data_in.clock = data_out.clock;

data_in.enable = data_out.enable;

data_in.data = data_out.data;

...

El tipo port permite referenciar a los macropuertos que constituyen la entrada/salidade los cores del lenguaje. En el Ejemplo 4.22 se declaran dos puertos, de los tipos lvo ylvi, que aunque analogos cumplen funciones distintas: el primero maneja un puerto dedatos de salida, mientras que el segundo es un puerto de datos de entrada. Antes de utilizarel segundo puerto es necesario indicar el origen de las senales de dicho macropuerto, queen el ejemplo se conectan directamente con las senales del primer puerto.

El identificador del puerto permite acceder a la informacion de configuracion del propiopuerto. En el Ejemplo 4.23 se ha configurado el parametro WIDTH de un puerto, parame-tro que puede consultarse en un punto posterior de la descripcion. Si una variable seutiliza para almacenar la referencia a un puerto, tambien puede acceder y utilizar estainformacion.

Ejemplo 4.23 Atributos dentro de un puerto dHDL....


...

variable p_width = data_out->attribute("WIDTH");

...

4.4.2.4. Entidades (entity)

El tipo entity permite referenciar a otros cores de biblioteca, configurar sus parame-tros y obtener el valor de los atributos declarados en la interfaz del core. La declaracionde este tipo no genera codigo, sino que solo proporciona el acceso al componente al quereferencia.

El lenguaje permite instanciar diferentes tipos de cores:

Cores descritos con el propio dHDL.

Instanciar y utilizar cores descritos en otros HDL como VHDL o Verilog.

Finalmente, es posible instanciar un tipo especial de cores, cuya funcion es la deadaptar dos o mas macropuertos del lenguaje, que se designaran como adaptadores.

En el Ejemplo 4.24 se muestra un ejemplo de como se declara este tipo: mediante lapalabra reservada entity, el identificador del tipo de core (dhdl, vhdl o adaptor) seguida


lib

arith

add

mult

cordic

iterative

online

logic

dsp

Core

Parámetros

Puertos

Atributos

Figura 4.2: Ejemplo de biblioteca de componentes dHDL.

del identificador de la entidad y la ruta al fichero fuente que implementa el core dentro dela biblioteca. Un ejemplo de la organizacion de la biblioteca de componentes se muestra enla figura 4.2. El identificador de tipo es un campo opcional, si no se indica la declaracionse correspondera con el tipo dhdl.

Ejemplo 4.24 Declaracion de una entidad....

entity dhdl cordic arith.cordic.online.fixrots;

...

Independientemente del tipo de core instanciado, una vez declarada la entity es posi-ble utilizarla para fijar los parametros de diseno declarados en la interfaz del componentedHDL, aunque tambien se pueden dejar sin inicializar los que no se utilicen, en cuyo casotomaran el valor por defecto definido en el componente. En el Ejemplo 4.25 se muestracomo se configuran los parametros del core.

Ejemplo 4.25 Configuracion de la entidad....

cordic.generics( NVBITS=16 );

...

Ademas, como se muestra en el Ejemplo 4.26, con la entity es posible acceder alvalor de los atributos definidos en la interfaz del core. El valor del atributo obtenido es elcalculado con el juego de parametros que previamente se hubiese configurado.

La configuracion de los parametros y la posterior consulta de los atributos puederealizarse tantas veces como sea necesario, ya que la declaracion de entity y su posteriorconfiguracion y consulta de atributos no genera codigo en el core, lo que permite un procesoiterativo de busqueda de los parametros adecuados para la aplicacion. Por ejemplo, el


Ejemplo 4.26 Acceso a los atributos de la entidad....

variable nmax = cordic->attribute("NROTS_MAX");

...

proceso iterativo podrıa ajustar los parametros de entrada del componente y preguntarpor una funcion de precision de la salida, hasta que esta se encontrase dentro del margendeseado.

Los atributos pre-generacion tambien pueden utilizarse para guiar la seleccion del valorde los parametros del core. Por ejemplo, durante la generacion puede conocerse el valorde un conjunto de parametros, mientras que pueden implementarse funciones que ayudenal usuario del core en la seleccion del valor de otros parametros, como en el Ejemplo 4.27.

Ejemplo 4.27 Configuracion, consulta de atributo y reconfiguracion de la entidad....

cordic.generics(NVBITS=16);

variable nmax = cordic->attribute("NROTS_MAX");

cordic.generics(NVBITS=16, NROTS=nmax);

...

Ya se menciono al comienzo del apartado que los cores instanciados son de tres tipos:los del propio lenguaje, cores descritos en otro lenguaje como VHDL, o bien utilizar untipo especial de core, los adaptadores. A continuacion se detallan los dos ultimos casos.

Cores VHDL En el caso de que el core venga descrito en otro HDL, la instancia alentity hace referencia a un envoltorio (wrapper) descrito en el lenguaje. Este en-voltorio interconecta los macropuertos dHDL con los puertos declarados en el HDL.Ademas permite realizar la configuracion de los parametros del core (por ejemploinicializar al valor correcto los generics de un core VHDL), e incluso permite aldisenador del core VHDL incluir los atributos del lenguaje.

Adaptadores Los adaptadores entre puertos del lenguaje tambien estan descritos endHDL. Su funcion es hacer compatibles dos puertos del lenguaje, y realizar la correctaasignacion entre las senales del puerto. Un ejemplo de adaptador podrıa ser el vistoen el Ejemplo 4.22, donde se asocian las senales de un macropuerto lvo con otro deltipo lvi. En realidad la implementacion puede ser algo mas complicada, ya que lospropios puertos tienen parametros, con lo que el adaptador puede definir sus propiosparametros.

El uso mas comun de los adaptadores es permitir conectar de forma rapida los macro-puertos de diferentes componentes. Para ello dHDL proporciona dos mecanismos. Elprimero consiste en utilizar una instancia entity, configurar y generar el componentdel lenguaje (se veran en el apartado 4.4.2.5). Posteriormente, a partir del componentse realiza la conexion con los macropuertos y se genera el codigo correspondiente.

El segundo metodo utiliza un elemento de tipo port del lenguaje para generar eladaptador con otro macropuerto. Este metodo, aunque simplificado, no permite con-figurar todas las posibilidades del adaptador, sino que utiliza la configuracion pordefecto que este componente proporcione. La llamada analiza los tipos de ambosmacropuertos y busca en la biblioteca de componentes un adaptador compatible. ElEjemplo 4.28 muestra el uso de este metodo.


Ejemplo 4.28 Instancia de un adaptador dHDL.port ii_a : lvo (WIDTH=NVBITS);

port oo_b : lvi (WIDTH=NVBITS);

ii_a.adapter(var_o);

c_funct.ports(

A = ii_a,

B = ii_b );

...

4.4.2.5. Componentes (component)

La declaracion del tipo component se realiza a partir de una instancia al tipo entity

que ha sido declarado y configurado. El tipo entity permite probar diferentes configura-ciones del core mediante una llamada especial generate. Mediante esta llamada se generael codigo asociado al modulo referenciado por la entity, y se actualiza el valor de losatributos declarados en la interfaz.

Esta llamada puede realizarse durante la declaracion de un nuevo tipo del lenguaje, eltipo component, en cuyo caso el codigo fuente VHDL generado se incluye como parte dela implementacion del core. Pero esta llamada tambien puede realizarse sin declarar estenuevo tipo, con lo que tras la generacion del modulo y la actualizacion de los atributos, elcodigo generado es descartado.

Un ejemplo de la declaracion de un component, junto con la llamada a la generacionde codigo, puede verse en el Ejemplo 4.29.

Ejemplo 4.29 Declaracion de un componente....

cordic.generics(NVBITS=16, NROTS=nmax);

component icordic = cordic->generate;

...

La generacion de codigo implica generar el componente instanciado con el juego deparametros configurado, si aun no ha sido generado, para posteriormente unirlo comoparte del core generado.

Con cada componente generado tambien es posible acceder a la informacion de lainterfaz del core al que referencia: por ejemplo los atributos que se han calculado duranteel proceso de generacion, como en el Ejemplo 4.29.

Ejemplo 4.30 Acceso a propiedad del componente.

variable latency = icordic->attribute("LATENCY");

El tipo component se utiliza para generar las instancias a los componentes VHDL.De manera similar a la llamada de port map en VHDL, con dHDL se implementa unmecanismo que permite anidar cores. Con la llamada a la generacion de la entity segenera el codigo del componente, mientras que con la llamada a los ports del componente(apartado 4.4.2.3), se genera una instancia a dicho componente dentro de la estructuraque describe el core. De esta manera un component se puede reutilizar tantas veces comose necesite, generando distintas instancias VHDL, con diferente interconexion.

En el Ejemplo 4.31 se ilustra una de estas llamadas. Durante la llamada se utilizan eltipo puerto del lenguaje, aunque tambien se pueden utilizar variables que contengan una


Ejemplo 4.31 Instancia de componentes dHDL....

port rot_xo : LVO (WIDTH=NVBITS);

port rot_yo : LVO (WIDTH=NVBITS);

i_cordic.ports(

XI = var_x,

YI = var_y,

XO = rot_xo,

YO = rot_yo );

var_x = rot_xo;

var_y = rot_yo;

...

referencia a puertos del lenguaje. El uso de las variables permite almacenar referenciasque en el momento del diseno del core quizas no se sepan con certeza.

Por ejemplo, un core puede dar la opcion de registrar la entrada, de modo que utilizandovariables primero se almacenara la referencia al puerto de entrada. Si durante la generacionse registran, se actualizara el valor de las variables a los puertos de salida de los registros(de manera analoga a como se hace en el Ejemplo 4.31 con las senales rot xo y rot yo),mientras que si no se registran mantendran la referencia al puerto de entrada. Desde elsiguiente componente, al utilizar las variables le sera transparente cual es el origen dedicha senal ya que le basta con la referencia que almacenan las variables.

En el Ejemplo 4.31 se ha mostrado una llamada completa a la generacion de la ins-tancia VHDL en el codigo generado: durante la llamada se realiza la asignacion de losmacropuertos del componente con las referencias contenidas en las variables y ports dellenguaje previamente declarado. El lenguaje dHDL permite realizar esta llamada de unamanera alternativa, en la que primero se asignan los macropuertos para luego realizar lallamada que realiza la generacion de codigo. En el Ejemplo 4.32 primero se asignan losmacropuertos del componente provocando la declaracion de diferentes ports del lenguaje.La asignacion de los macropuertos de manera previa a su generacion permite adaptarlosa senales y puertos que se hubieran declarado previamente en el core.

Ejemplo 4.32 Instancia de componentes dHDL....

port rot_xi : i_cordic->port("XI");

port rot_yi : i_cordic->port("YI");

rot_xi.adapter(var_x);

rot_yi.adapter(var_y);

port rot_xo : i_cordic->port("XO");

port rot_yo : i_cordic->port("YO");

i_cordic.ports;

var_x = rot_xo;

var_y = rot_yo;

...

4.4.3. Inserciones de codigo

dHDL permite incluir inserciones de codigo VHDL durante el proceso de generacion.Dado que el lenguaje esta orientado a mejorar las capacidades de descripcion estructu-ral, instanciacion e interconexion de componentes, el permitir las inserciones de codigoVHDL en el lenguaje proporciona toda la potencia descriptiva de este lenguaje para laespecificacion funcional.


Como se ha mencionado, las inserciones de codigo pueden particularizarse mediante eluso de los tipos definidos y funciones propias de dHDL, realizando una sustitucion por elvalor actual del tipo o funcion durante el proceso de generacion. Para la insercion de codigose utilizan un conjunto de palabras reservadas en dHDL, una por cada posible localizacionen el codigo VHDL, contemplandose los siguientes casos:

1. Insertar codigo en la zona de declaracion de las bibliotecas VHDL, como en el Ejem-plo 4.33, mediante la palabra clave lib.

Ejemplo 4.33 Insercion de codigo para declarar bibliotecas.lib {

LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; }

2. Insertar codigo en la zona declarativa de la arquitectura VHDL, como en el Ejemplo4.34, mediante la palabra clave decl.

Ejemplo 4.34 Insercion de codigo para realizar declaraciones.decl {

CONSTANT MEM_[index] : STD_LOGIC_VECTOR ([var_msb] DOWNTO 0) :=

"[Dec2Bin(arith.cordic.ATRCoeff(index), word)]"; }

3. Finalmente para insertar el codigo en la parte de la implementacion de la arquitecturaVHDL, como en el Ejemplo 4.35, mediante la palabra clave code.

Ejemplo 4.35 Insercion de codigo durante la descripcion del core.code {

MEM_[index] WHEN DIR = "[Dec2Bin(index, word_index)]" ELSE

...

}

En las inserciones de codigo, VHDL es interpretado como texto plano, aunque acep-tando la sustitucion de texto en cualquier lugar. Para ello basta con indicarlo mediante lautilizacion de los corchetes junto con expresiones en el lenguaje, como se puede observaren los Ejemplos 4.34 y 4.35.

En los ejemplos anteriores, en las inserciones con decl y code se ilustra el uso dela sustitucion por variables y llamadas a funciones, tanto definidas en el lenguaje comodefinidas por el usuario.

Ası en el ejemplo 4.34 se realiza una llamada a una funcion definida e implementadapor el disenador del core, arith.cordic.ATRCoeff que permite obtener los coeficientesque inicializan una memoria, y a su vez el disenador hace uso de la funcion del lenguajeDec2Bin, para convertir el valor entero a su correspondiente valor binario con una precisionde word bits.

Estas inserciones de codigo permiten utilizar la potencia descriptiva de VHDL, mejo-rada con ciertas capacidades de generalizacion.


T T T

b(0) b(1) b(2) b(N-1)

x(k)

y(k)

x(k-1) x(k-2) x(k-N)

Figura 4.3: Esquema del filtro FIR.

4.5. Ejemplos de diseno

Anteriormente se ha realizado una descripcion de la sintaxis de dHDL: tipos, estructu-ras de control, etc., acompanado de pequenos ejemplos de uso. En esta apartado se ilustrael uso del lenguaje mediante varios disenos completos.

4.5.1. Filtro FIR

Un ejemplo clasico en procesado de senal son los filtros FIR [SP94], que son un tipode filtros digitales cuya salida se basa en su entrada actual y un conjunto de entradasanteriores:

y(n) =

N−1∑k=0

bk × x(n− k)

donde N se corresponde con el orden del filtro, y bk son los coeficientes del filtro. Un posibleesquema para la implementacion de este filtro se puede ver en la figura 4.3 y se basa enla utilizacion de tres elementos: uno que almacene las muestras de entrada, otro elementoque multiplique las muestras de entrada por los coeficientes del filtro, y un elemento quesume los productos.

En el apartado 5.5.2 se mostraran ejemplos de encapsulado para filtros FIR. Esteapartado se centrara en la descripcion de como se puede implementar una estructura deeste tipo con dHDL.

La implementacion mas directa del filtro es la que reproduce la estructura de la figura4.3 (directa), para ello en el lenguaje se va a descomponer el diseno en varias ficherosdHDL: el fichero de codigo fuente principal se definira la estructura del filtro, mientrasque en el resto de ficheros describen la funcionalidad de los componentes requeridos.

4.5 Ejemplos de diseno 61

4.5.1.1. FIR

Comenzaremos por realizar un diseno con un conjunto de parametros y puertos lo massencillo posible. Los parametros de este core son:

WIDTH, valor entero para especificar el ancho de bit de los datos de entrada.

STAGES, valor entero que indicara el numero de etapas en las que se descompondra elfiltro. Este parametro se corresponde directamente con el orden del filtro, N .

Como ejemplo de atributo se especifica O WIDTH, una funcion que calcule el ancho debit de los datos de salida en funcion del ancho de bit de los datos de entrada y del numerode etapas.

El ejemplo solo se declaran dos macropuertos del lenguaje: FIR I de tipo lvi, y FIR O,de tipo lvo. Cada uno de los macropuertos ha de configurar su parametro WIDTH, queen el caso del macropuerto de entrada de tipo lvi se configurara directamente desde elparametro WIDTH, y para el caso del macropuerto de salida de tipo lvo se configurara apartir del atributo O WIDTH. En los Ejemplos 4.36 y 4.37 se muestra la declaracion de estainterfaz simplificada.

Ejemplo 4.36 Interfaz FIR: Parametros y atributos.<declaration coreid="dhdl_fir"



<parameters>




</parameter>

<parameter id="STAGES">



</parameter>

</parameters>

<attributes>

<attribute id="O_WIDTH">

<type>float</type>

<value><vall>0.0</vall></value>

</attribute>

</attributes>

...

</declaration>

Para la descripcion de la estructura, una primera version del filtro se puede implementardirectamente a partir de la estructura clasica para un filtro FIR: un conjunto de etapas,donde se registra N veces la senal de entrada para retrasarla N -ciclos, y multiplicar cadauna de estas muestras retrasadas por una constante, para obtener la salida del filtromediante la suma de estas N -multiplicaciones.

El Ejemplo 4.38 muestra la implementacion con dHDL de esta estructura del filtro.Se utiliza un bucle de control donde se implementan cada una de las etapas del filtro.Dentro de este bucle, una segunda estructura de control, en este caso condicional, permiteque la primera etapa sea ligeramente distinta a las restantes: se registra la muestra pararetrasarla y se multiplica la muestra retrasada por la constante del filtro. En esta etapa


Ejemplo 4.37 Interfaz FIR: Puertos....

<macroports>

<macroport id="FIR_I">


<type>LVI</type>

<parameter id="width">


</parameter>

</macroport>

<macroport id="FIR_O">


<type>LVO</type>


<value><vall>O_WIDTH</vall></value>

</parameter>

</macroport>

<net id="clock">


<mport id="FIR_I" signal="clock" />

<mport id="FIR_O" signal="clock" />

</net>

</macroports>

...

no tiene sentido realizar la suma, ya que no hay productos anteriores. La generacion deesta descripcion generara una estructura como la representada en la Figura 4.4.

Las estructuras anteriores permiten controlar el flujo de generacion del core: el ordenen que se generan los componentes que lo forman y su interconexion. El resto del codigopermite interconectar estos componentes mediante los tipos de dHDL.

Las variables ptr x y ptr xh sirven para almacenar referencias a macropuertos que segeneran al instanciar los distintos componentes a medida que se van instanciando y gene-rando. La variable ptr x se utiliza para almacenar la referencia al macropuerto de salidadel registro generado en cada etapa. La variable ptr xh se utiliza para controlar una refe-rencia al macropuerto de salida de la muestra multiplicada y acumulada, que dependiendode la etapa se podra corresponder con el macropuerto de salida de un multiplicador en laprimera etapa o de un sumador en el resto de etapas.

Al utilizar variables para almacenar referencias, estas pueden ser accedidas y utiliza-das fuera de la estructura de control donde se generaron. Por ejemplo, los puertos que sedeclaran en una iteracion del bucle y que son utilizados en la siguiente iteracion. En elejemplo anterior se pueden consultar los atributos del tipo al que referencian las varia-bles, y utilizarlo para configurar los parametros de los componentes en la etapa que seesta generando, y conectarlos con los puertos obtenidos de dichos componentes.

El uso de las variables permite simplificar el diseno, ya que no es necesario recordardonde se genero la referencia que se va a utilizar. Por ejemplo, en el caso de la variableptr x que se usa para la generacion de la cadena de registros, al utilizarse como entrada aun registro en una etapa, no hace falta saber si la referencia es al macropuerto de entradaFIR I del core, o si se genero en la etapa anterior.

El problema de utilizar referencias para interconectar macropuertos es que han de co-nectarse macropuertos a priori de diferente tipo. En el ejemplo anterior los macropuertosde los registros son tipo lvi. Si la referencia es al puerto de entrada del core, se corres-pondera con un tipo lvi, pero si la referencia es a un macropuerto de un registro de una


Ejemplo 4.38 Descripcion de la estructura del filtro.

lib {

library ieee;


}

entity dhdl fir_register = fir.Register;

entity dhdl fir_multiplier = fir.Multiplier;

entity dhdl fir_adder = fir.Adder;

variable ptr_x = FIR_I;

variable ptr_xh;

variable index = 0;

while ( index < STAGES ) {

if ( index > 0 ) {

fir_register.generics(

WIDTH = ptr_x->attribute("WIDTH") );

component c_register =

fir_register->generate;

port c_register_i : c_register->port("I");

c_register_i.adapter(ptr_x);

port c_register_o : c_register->port("O");

c_register.ports;

ptr_x = c_register_o;

}

fir_multiplier.generics(

A_WIDTH = WIDTH,

A_CTE = fir.h(index, WIDTH),

B_WIDTH = ptr_x->attribute("WIDTH") );

component c_multiplier =

fir_multiplier->generate;

port c_mult_b : c_mult->port("B")

c_mult_b.adapter(ptr_x);

port c_mult_o : c_mult->port("O");

c_multiplier.ports;

if ( index == 0 ) {

ptr_xh = c_multiplier_o;

} else {

fir_adder.generics(

A_WIDTH = c_mult_o->attribute("WIDTH"),

B_WIDTH = ptr_xh->attribute("WIDTH") );

component c_adder = fir_adder->generate;

port c_adder_a : c_adder->port("A");

c_adder_a.adapter(c_multiplier_o);

port c_adder_b : c_adder->port("B");

c_adder_b.adapter(ptr_xh);

port c_adder_o : c_adder->port("O");

c_adder.ports;

ptr_xh = c_adder_o;

}

index = Inc(index);

}

FIR_O.adapter(ptr_xh);

etapa anterior, seguramente se correspondera con un tipo de macropuerto de salida, porejemplo el tipo lvo. Este es uno de los motivos para utilizar con el lenguaje dHDL losadaptadores.

Los adaptadores son cores dHDL. Su funcion de interconectar puertos del lenguajede diferente tipo. Los adaptadores pueden instanciarse como otros componentes dHDL:referencia mediante entity, configuracion de sus parametros, generacion, acceso a los atri-butos que tenga definidos, etc. En el ejemplo 4.39 se muestra un ejemplo de la instanciacionde un adaptador.

Ejemplo 4.39 Descripcion de la estructura del filtro.....

entity adapter o2i = lvi.lvo;

o2i.generics(

O_WIDTH = width,

I_WIDTH = width );

component c_o2i = o2i->generate;

...

port p_o : LVO ( WIDTH = width );

port p_i : LVI ( WIDTH = width );

...

c_o2i.ports(

O = p_o,

I = p_i );

...

En el caso de nuestro diseno descrito en el ejemplo 4.38, hay que declarar uno a uno lospuertos de cada componente. Los puertos de entrada se conectan a traves de la llamada a


fir.Register

fir.Multiplier

fir.Adder

fir.Register

fir.Multiplier

fir.Adder

fir.Multiplier

fir.Register

fir.Multiplier

fir.Adder

x(k)

y(k)

x(k-1)

x(k-2)

x(k-N)

b(0)

b(1)

b(2)

b(N-1)

ptr_x ptr_xh

fir.Register

fir.Multiplier

fir.Adder

I (LVI)

O (LVO)

O (LVO)

B (LVI) A (LVI)

A (LVI) B (LVI)

O (LVI)

index = 0

index = 1

index = 2

index = STAGES-1

Figura 4.4: Arquitectura generada del filtro FIR.

adapter utilizando como parametro el puerto a conectar y que se encuentra almacenado enla variable. Esta llamada no es mas que una manera abreviada de realizar la instanciaciondel componente de manera similar a la del ejemplo 4.39.

Los puertos de salida de los componentes a su vez se almacenaran en una referenciapara poder acceder a ellos en etapas posteriores de la estructura o incluso para conectarlosal puerto de salida del diseno, tambien mediante un adaptador.

Dado que dHDL permite declarar puertos durante la especificacion, es posible iniciali-zarlos a partir de los macropuertos de un componente ya instanciado. Una vez conectadostodos los puertos del componente se produce la llamada a ports del componente. Si todoslos puertos han sido ya asignados, no hace falta indicar durante esta llamada la corres-pondencia entre los puertos del componente y los del lenguaje.

Finalmente, otra de las caracterısticas de esta implementacion es como se fijan loscoeficientes o constantes del filtro para los multiplicadores: se hace una llamada a la funciondel lenguaje fir.h(i, WIDTH). Esta funcion, disenada e implementada por el disenadordel core, permite configurar la constante del multiplicador durante la generacion, utilizandocomo parametros el numero de etapa (mediante la variable index) y el ancho de bit quese definio como parametro para la constante.


La descripcion realizada indica como se genera la estructura del core, mediante la in-terconexion de tres componentes: un registro, un multiplicador y un sumador. otros com-ponentes son configurados y generados a partir de los parametros declarados su interfaz,mediante variables e incluso funciones dHDL, como por ejemplo las llamadas a fir.h()

o a Mult(). Del resto de componentes dHDL utilizados, se describira con un poco mas dedetalle el multiplicador.

4.5.1.2. Multiplicador

dHDL permite el uso de VHDL para la descripcion del comportamiento, mediante lautilizacion de inserciones de codigo. El multiplicador requerido en el filtro anterior es unejemplo de como utilizar estas inserciones.

El multiplicador debe realizar el producto del valor de una constante por el valor delos datos introducidos por uno de sus puertos. Para configurar esta constante se haceuso de dos parametros declarados en su interfaz: el valor de la constante (A CTE) y elnumero de bits necesarios para representarlo (A WIDTH). Un tercer parametro B WIDTH

permitira configurar el ancho de bit de los datos del puerto de entrada.

Ejemplo 4.40 Codigo dHDL para multiplicador por constante.lib {

library ieee;


use ieee.std_logic_arith.all;

use ieee.std_logic_signed.all;

}

decl {

constant cte_int_a :

std_logic_vector([Sub(A_WIDTH, 1)] downto 0)

:= [vhdl.Dec2Bin(A_CTE, A_WIDTH)];

}

variable cte_a = "cte_int_a";

signal mult : Add(A_WIDTH, B_WIDTH);

code {

[mult] <= [cte_a] * [B.data];

}

O.clock = B.clock;

O.enable = B.enable;

O.data = mult;

El codigo dHDL que implementa este componente se muestra en el Ejemplo 4.40,que a diferencia del codigo del FIR, en este caso se hace uso de una descripcion mascomportamental.

Se puede observar como mediante las llamadas lib, decl y code, se puede elegir elpunto donde se haran las inserciones de codigo VHDL: declaracion de bibliotecas, decla-racion de la constante del multiplicador y la insercion en el propio codigo implementadodel multiplicador.

Dentro de las propias inserciones se puede obtener el valor de tipos como variables osenales, o incluso funciones del lenguaje mediante el uso de corchetes.

En el ejemplo se declara una senal dHDL, mult, que permitira almacenar el resultadode la multiplicacion. Puesto que el componente presenta un unico macropuerto para datos,B, de tipo lvi, es necesario acceder a la senal de datos de dicho puerto para realizar la


Figura 4.5: Esquema de arbol de sumadores para diferentes n.

multiplicacion.

El macropuerto de salida O, de tipo lvo, recibe el resultado de la multiplicacion, mult,mediante una conexion directa al macropuerto de datos de salida, O.data. Tambien esnecesario conectar las otras senales que forman el macropuerto y que se obtienen a partirdel puerto de entrada de datos, en concreto las senales de reloj, O.clock, y de enable,O.enable.

4.5.2. Arbol de sumadores

La implementacion del filtro FIR del ejemplo del apartado 4.5.1 puede presentar cier-tos problemas, por ejemplo, el retardo combinacional debido a las sumas de los productospuede ser elevado debido a que una suma solo se puede realizar cuando se ha acabado derealizar la suma de los productos anteriores. Para mejorar este diseno se podrıa implemen-tar las sumas en un nuevo conjunto de etapas de pipeline, donde en cada etapa unicamentese suman dos sumandos. Una estructura similar es el arbol de sumadores, en [SEMLV08]se puede encontrar un ejemplo de aplicacion de esta estructura.

El arbol de sumadores es un ejemplo de como implementar un algoritmo matematicocon una estructura muy regular:

x =

n−1∑i=0

ai × bi

En la Figura 4.5 muestra varios esquemas para la implementacion del arbol de suma-dores, y como cambia la estructura respecto al valor de n.

Aunque se trata de una estructura sencilla basada en tres componentes (sumadores,multiplicadores y delays), su implementacion con un lenguaje tradicional puede ocasionaral disenador algunos problemas:

La estructura depende del valor del parametro n, ya que influira en el numero deentradas a declarar, en el numero de etapas en el que se descompondra el arbol, yen como se realiza la instancia de operadores a lo largo de la estructura.

Un cambio en el valor de n requiere grandes cambios en la estructura, por lo quela parametrizacion de esta estructura, sobre todo si n no es potencia de 2, resulta


complicada.

4.5.2.1. Interfaz

Para comenzar la descripcion del core primero es necesario especificar la interfaz.

Ejemplo 4.41 Arbol de sumadores. Declaracion de parametros y atributos.<parameters>

<parameter id="N">



</parameter>

<parameter id="ARITH">

<type>string</type>

<value><vall>FLOAT</vall></value>

</parameter>




</parameter>

<parameter id="DEEP_OP">



</parameter>

</parameters>

<attributes>

<attribute id="OUT_WIDTH">

<type>float</type>


</attribute>

</attributes>

En el Ejemplo 4.41 se han declarado como parametros, ademas del propio valor de N ,que puede tomar un valor entero cualquiera, otros parametros como por ejemplo el tipode aritmetica a utilizar con los operadores, configurable mediante el parametro ARITH,el ancho de datos de los operadores, con el parametro WIDTH, y el nivel de pipeline conDEEP OP.

Durante la declaracion de los puertos dHDL, se generara un numero variable de puer-tos de entrada, mediante la declaracion de puertos en array. En el ejemplo 4.42 se handeclarado los puertos A y B en un array de N elementos.

4.5.2.2. Implementacion

La estructura se descompone en dos estructuras de control: una primera estructura decontrol, que se encargara de implementar las multiplicaciones del algoritmo, mientras quela segunda estructura de control implementara las sucesivas etapas que formaran el arbolde sumadores.

En el Ejemplo 4.43 se ha implementado la primera estructura de control dedicada alos multiplicadores. En una primera etapa se configurara una instancia a un componentedHDL con los multiplicadores, mediante un entity del lenguaje. Una vez configuradoy generado el component al multiplicador definido en el codigo dHDL, se utilizara paragenerar las n instancias de multiplicadores VHDL mediante un lazo de control while.

En este ejemplo, el codigo dHDL no los implementa directamente a los multiplicadores,


Ejemplo 4.42 Arbol de sumadores. Declaracion de puertos.<macroports>

<macroport id="A">

<type>LVI</type>

<array>N</array>



</parameter>

</macroport>

<macroport id="B">

<type>LVI</type>

<array>N</array>



</parameter>

</macroport>

<macroport id="O">

<type>LVO</type>

<array>N</array>


<value><vall>OUT_WIDTH</vall></value>

</parameter>

</macroport>

<net id="clock">




</net>

</macroports>

sino que en funcion de los parametros de entrada, seleccionara, configurara y generara alos multiplicadores apropiados. Lo mismo sucedera con otros componentes utilizados comoson los sumadores.

Una vez realizada la primera etapa de multiplicaciones, quedara por implementar elpropio arbol de sumadores. Para la implementacion de esta estructura se utilizaran doslazos de control, como puede observarse en el Ejemplo 4.44: el lazo exterior controla elnumero de etapas del arbol, mientras que el lazo interior controlara el numero de sumadoresque se implementaran en cada etapa. En cada etapa se van sumando los datos de dos endos, y si el numero de datos no es par, se introduce un retardo a los ultimos datos, paraque sean sumados en la siguiente etapa.

4.6. Conclusiones

Durante este capıtulo se ha presentado un lenguaje para la generacion dinamica dehardware. El lenguaje, denominado dHDL, se ha definido para mejorar las caracterısticasque describen disenos estructurales y jerarquicos, simplificando el proceso de instanciacionde componentes de biblioteca y su interconexionado.

dHDL simplifica el interconexionado e instanciacion, potenciando de manera signifi-cativa la capacidad de descripcion a nivel estructural respecto a los HDL tradicionales.Ademas, dHDL mejora las posibilidades de configuracion y evaluacion del hardware des-crito, incrementando con ello sus posibilidades de reutilizacion.

Las estructuras de control y tipos del lenguaje permiten al disenador controlar como

4.6 Conclusiones 69

Ejemplo 4.43 Multiplicadores. Descripcion de la estructura.entity mult = arith.multiplier;

mult.generics (

A_WIDTH = WIDTH,

B_WIDTH = WIDTH,

OP_ARITH = ARITH,

PIP = DEEP_OP );

component mult_0 = mult->generate;

variable index_mult = 0;

signal out_mult [n] : WIDTH;

while ( index_mult < n ) {

mult_0.ports (

CLOCK = CLOCK,

A = A[index_mult],

B = B[index_mult],

O = out_mult[index_mult]);

index_mult = Inc(index_mult);

}

Ejemplo 4.44 Arbol de sumadores. Descripcion de la estructura.variable outnum = n;

while ( outnum > 1 ) {

variable in_index = 0;

variable out_index = 0;

variable n_odd = Mod(outnum, 2);

variable outnum2 = Add(Div(outnum, 2), n_odd);

while ( in_index < outnum ) {

if ( out_index < Div(outnum, 2) ){

//assignation of adders

...

} else {

//assignation of delay if necessary

...

}

in_index = Add(in_index, 2);

out_index = Add(out_index, 1);

}

outnum = outnum2;

}

y cuando se genera el codigo del core, dando la flexibilidad de probar diferentes configu-raciones para los componentes a instanciar e incluso evaluar entre alternativas antes deincluirlos como parte del core. El lenguaje dispone de elementos cuya declaracion y visibi-lidad queda limitada a la fichero fuente donde se describe el diseno, y permite al disenadordecidir cuando estos elementos se reflejan en el codigo generado.

El lenguaje, por lo tanto, no esta enfocado a describir componentes sino a describircomo se generan los componentes. Ası la mayor parte de elementos de dHDL se cen-tran en simplificar la descripcion estructural de componentes. Sin embargo, se mantienela posibilidad de utilizar VHDL para la descripcion del comportamiento, bien medianteinserciones de codigo dentro del codigo dHDL o incluso mediante la inclusion de coresVHDL completos como parte del diseno generado.

Uno de los aspectos basicos del lenguaje es su interfaz, que en el presente capıtulose ha introducido brevemente. Parte de las posibilidades de reutilizacion del lenguaje seobtienen a partir de la declaracion de la propia interfaz que extiende las posibilidades de losHDLs clasicos. Esta interfaz se ha denominado encapsulado estructural y se describira enel capıtulo 5, que no solo permite la configuracion del core sino proporcionar al exterior


informacion a partir del codigo generado.

En el capıtulo se han mostrado con dos ejemplos practicos las posibilidades del lengua-je: la especificacion de la estructura de un FIR y la estructura de un arbol de sumadores.El objetivo de los ejemplos no ha sido obtener implementaciones eficientes sino mostrar laflexibilidad del lenguaje en la especificacion. En el capıtulo 6 se dedicara a la descripcionde arquitecturas para el procesado de la FFT, con el objetivo de obtener implementacionesaltamente parametrizables, aunque tambien eficientes.

Capıtulo 5

Definicion de encapsulados para lareutilizacion

5.1. Introduccion

En el capıtulo 3 se indico que en la propuesta que se hace en esta Tesis se han definidodos niveles de encapsulado. El un primer nivel se ha definido el encapsulado estructural.Este encapsulado implementa la interfaz de los cores dHDL, por lo que siempre acompana ala implementacion concreta de una funcion. En el apartado 4.3 se introdujeron brevementelos elementos que se declaran en este encapsulado y que se utilizaran durante la descripciondel core dHDL:

Parametros, que buscan mejorar las posibilidades de configuracion de los lenguajesHDL convencionales.

Atributos, que ofrecen informacion de la implementacion.

Macropuertos, cuyo objetivo es simplificar el proceso de interconexion durante lasdescripciones dHDL.

El encapsulado estructural declara elementos especıficos de la implementacion, por loque diferentes implementaciones de la misma funcion es normal que ofrezcan diferenteencapsulado. Por ello se define un segundo nivel con el encapsulado funcional. El objetivodel encapsulado funcional es la descripcion de la funcionalidad de manera independientede implementaciones. Los elementos declarados en el encapsulado funcional:

Funcion, mediante un identificador dentro de un espacio de nombres.

Caracterısticas, que permiten refinar la descripcion de la funcion.

Flujos, tipo adaptado a describir la entrada/salida de funciones de procesado desenal.

El encapsulado funcional no se encuentra ligado a ninguna implementacion concreta,sino que corresponde al disenador del core dHDL describir como el encapsulado estructural

72 Definicion de encapsulados para la reutilizacion

<?xml version="1.0" encoding="iso-8859-1" ?>

...

<xs:element name="declaration">

<xs:complexType>

<xs:sequence>

<xs:element name="definitions"

type="typedefinitions"

minOccurs="0" maxOccurs="1" />

<xs:element name="parameters"

type="typeparameters"


<xs:element name="attributes"

type="typeattributes"


<xs:element name="macroports"

type="typemacroports"


</xs:sequence>

<xs:attribute name="coreid"

type="xs:string" />

</xs:complexType>

</xs:element>

</xs:schema>

Figura 5.1: Estructura del encapsulado estructural.

implementa al encapsulado funcional mediante un nuevo elemento denominado el empa-quetado. El empaquetado, ofrece al disenador la posibilidad de incorporar informacion queno tiene cabida en el encapsulado estructural, como por ejemplo informacion de uso.

Para la formalizacion de los diferentes encapsulado y del empaquetado se ha utilizadoXML Schema1 [xml] ya que proporciona un metodo sencillo para su especificacion. Durantela descripcion de estos elementos se realizaran extractos del XML Schema que lo definen,pero sin entrar en demasiado detalle, y se realizaran abundantes ejemplos de uso.

Durante los siguientes apartados se van a definir los diferentes encapsulados que for-man la propuesta comenzando por el estructural, para continuar con el funcional. Tras ladefinicion de los encapsulados se describira el empaquetado y como relaciona los diferentesencapsulados. Finalmente se describiran mediante algunos ejemplos el uso de los diferenteselementos definidos en el capıtulo.

5.2. Encapsulado Estructural

El objetivo de la definicion de un encapsulado estructural es mejorar las caracterısticasdescriptivas orientadas a mejorar la reutilizacion, mediante la declaracion de una interfazsimilar a la utilizada con HDL clasicos. En estos lenguajes solo parte de la informacionde la interfaz se declara junto a la implementacion, mientras que el resto de informacionnecesaria para incorporar el core en un nuevo diseno normalmente debe consultarse endocumentacion externa.

Reutilizar un core descrito con los lenguajes tradicionales implica no solo disponer de

1Se ha elegido para la especificacion de los encapsulados propuestos en el capıtulo XML Schema yaque proporciona los mecanismos necesarios para definir la estructura, contenido y semantica. Durante elcapıtulo se proporcionaran tanto una representacion esquematica como extractos de los XML Schemas,que permiten ilustrar las diferentes secciones que los componen.

5.2 Encapsulado Estructural 73

la propia implementacion, sino que normalmente es necesario que el disenador realice unestudio de toda esta documentacion externa. Ademas, la incorporacion del core al propiodiseno requiere adaptarlo, generalmente tanto desde el punto de vista de interconexionadocomo de temporizacion. El coste asociado a dicho proceso suele ser tan alto, que no esposible realizarlo para todas las alternativas de diseno.

Mejorar el encapsulado que acompana a la implementacion simplifica todo el procesode incorporacion de un core en un nuevo sistema, lo que permitira al disenador evaluar demanera mas exhaustiva un mayor numero de posibles implementaciones. En este trabajose propone mejorar esta parte del encapsulado, por una parte, mejorando los tipos quese encuentran disponibles en los HDL clasicos, es decir, parametros y puertos, de modoque el disenador del core tenga un mejor control del uso que se les dara. Por otra parte,tambien se pretende aumentar la cantidad de informacion que el disenador del core puedeincorporar junto con la implementacion, de modo que esta informacion pueda ser accedidade manera automatica a la hora de utilizar el core.

La definicion de un nuevo encapsulado no es posible si el lenguaje utilizado para reali-zar la implementacion no soporta las nuevas caracterısticas que aporte este encapsulado.Por ello, la propuesta que hacemos en este capıtulo basara la descripcion de los cores enel lenguaje dHDL, definido en el capıtulo 4. Este lenguaje se ha orientado a la generaciondinamica de estructuras hardware. Frente a HDLs clasicos, este lenguaje aporta simplicidady flexibilidad para la descripcion estructural de hardware, mientras que mantiene VHDLcomo base para la descripcion funcional. Gracias a sus caracterısticas mejora las posibili-dades de parametrizacion de los cores que con este lenguaje se describen, lo que constituyeuna de las claves para la reutilizacion de componentes a este nivel de descripcion.

Utilizar dHDL como base para la descripcion de la implementacion, no limita la apli-cacion del encapsulado propuesto unicamente a cores descritos con este lenguaje, ya queotra de las caracterısticas de dHDL es poder instanciar y utilizar cores descritos mediantelenguajes convencionales, de modo que se utilice el lenguaje como envoltorio (wrapper)entre la declaracion del encapsulado y la propia implementacion.

El encapsulado estructural define tres elementos basicos: parametros, atributos y ma-cropuertos. Parametros (parameters) y macropuertos (macroports) son similares a lostipos definidos en los HDLs convencionales, aunque incorporan caracterısticas que ex-tienden su funcionalidad, mientras que los atributos (attributes) definen un nuevo tipoa partir del cual extraer informacion del core. Cada tipo se declara en una seccion di-ferente del encapsulado, aunque en realidad este se divide en cuatro secciones como sepuede observar en la Figura 5.1, ya que se anade una seccion previa para definiciones.Cada encapsulado se distinguira con un identificador unico, coreid en la Figura 5.1. Acontinuacion se presenta la sintaxis y objetivo de cada una de las secciones.

5.2.1. Definiciones (definitions)

En el encapsulado estructural se proporcionan un conjunto de tipos de datos basicosque son la base para declarar los diferentes elementos de cada seccion: string, boolean,int8, int16, int32, float, double. En esta primera seccion se permite la declaracionde nuevos tipos basados en los basicos, mediante la definicion de rangos y uniones, cuyasintaxis se muestra en la Figura 5.2.


...

<xs:complexType name="range">

<xs:sequence>

<xs:element name="from" type="xs:string" />

<xs:element name="to" type="xs:string" />

<xs:element name="step" type="xs:string" />

</xs:sequence>

<xs:attribute name="type" type="xs:string" />

</xs:complexType>

<xs:complexType name="union">

<xs:sequence>

<xs:element name="item" type="xs:string"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="type" type="xs:string"/>

</xs:complexType>

<xs:complexType name="typedefinitionsdeftype">

<xs:choice>

<xs:element name="range" type="range" />

<xs:element name="union" type="union" />

</xs:choice>

<xs:attribute name="id" type="xs:string" />

</xs:complexType>

<xs:complexType name="typedefinitions">

<xs:sequence>

<xs:element name="deftype"

type="typedefinitionsdeftype"

minOccurs="1" maxOccurs="unbounded" />

</xs:sequence>

</xs:complexType>

...

Figura 5.2: Encapsulado Estrutural. Definiciones.

En el Ejemplo 5.1 se muestra la definicion de un rango de valores para la declaracion deltipo addrwidthtype. Este tipo permitira definir elementos que aceptaran valores enterosentre 2 y 32.

Ejemplo 5.1 Declaracion de un rango....

<deftype id="addrwidthtype">

<range type="int8">

<from>2</from>

<to>32</to>

<step>1</step>

</range>

</deftype>

...

En el Ejemplo 5.2 se define la union de valores, que permite declarar un tipo como unconjunto de elementos basicos discretos. En el ejemplo se declara la anchura valida paraun tipo de datos como 8, 16, 24 o 32 bits.

5.2.2. Parametros (parameters)

Los parametros son un elemento del encapsulado que permite configurar la implemen-tacion del core. Son similares a los tipos de HDLs tradicionales, como por ejemplo losgenerics de VHDL, pero con el encapsulado estructural propuesto se mejora la definicionde estos elementos. La mejora en su definicion y declaracion permite utilizar funciones


Ejemplo 5.2 Declaracion de una union....

<deftype id="datawidthtype">

<union type="int8">

<item>8</item>

<item>16</item>

<item>24</item>

<item>32</item>

</union>

</deftype>

...

...

<xs:complexType name="typevalueval">

<xs:choice>

<xs:element name="vall"

type="xs:string"/>

<xs:element name="valf"

type="typevaluevalfunction"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="typeparameter">

<xs:sequence>

<xs:element name="parameter"

type="typevalue"


</xs:sequence>

</xs:complexType>

...

Figura 5.3: Encapsulado Estructural. Parametros.

complejas para la evaluacion de los parametros, y ayuda a establecer relaciones y restric-ciones entre diferentes parametros y los valores de configuracion.

Es en la segunda seccion del encapsulado estructural donde se permite la declaracionde estos parametros. En la Figura 5.3 se recoge su definicion en el XML Schema: unparametro se declara mediante un identificador unico (id), el tipo del parametro (entrelos basicos o previamente declarado en la seccion de definiciones) y el valor que toma elparametro por defecto. Opcionalmente durante la declaracion de un parametro se podranincluir otros campos, como puede ser una descripcion textual.

El identificador permite, una vez declarado un parametro, referenciarlo y utilizarsetanto para la definicion de nuevos parametros (base para definir relaciones entreparametros), como para su utilizacion por el resto de secciones del encapsuladoestructural.

El tipo del parametro restringe los valores de configuracion que toma.

El valor por defecto permite definir el valor que tomara el parametro.

El Ejemplo 5.3 muestra una declaracion basica de un parametro, data width. Ademasde los campos basicos se acompana la declaracion de parametro con una breve descripcion.El campo de descripcion del parametro, aunque optativo, permite al disenador documentarde manera breve la funcion del parametro, con que otros parametros se encuentra relacio-nado, valores de configuracion, etc. Esta informacion, al incluirse en la propia declaraciondel parametro podra ser accedida de manera automatica por los usuarios del core, enten-diendose como posibles usuarios a otros disenadores que se encuentren integrando el core


Ejemplo 5.3 Declaracion de un parametro....

<parameter id="data_width">


<type>datawidthtype</type>


</parameter>

...

en un nuevo sistema, o tambien se consideran usuarios las herramientas, como por ejemplouna interfaz grafica (GUI ), que muestra un cuadro para la configuracion del parametro.

El valor por defecto se puede definir utilizando una constante literal, como en el Ejem-plo 5.3, o bien se puede definir utilizando una expresion que sea funcion de otros parametrosde la configuracion previamente definidos. El valor que se le asigne al parametro en es-te ultimo caso sera el resultado de evaluar la funcion con los valores que se encuentrenasignados a los demas parametros. En el Ejemplo 5.4 se declara un nuevo parametro,addr width, cuyo valor por defecto se obtiene al realizar la llamada a la funcion log2 conel valor de otro parametro, depth width, como argumento.

Ejemplo 5.4 Declaracion de un parametro con funcion....

<parameter id="addr_width">


<type>addrwidthtype</type>

<value>

<valf id="log2">

<arg><vall>depth_width</vall></arg>

</valf>

</value>

</parameter>

...

Evaluar parametros en funcion de otros parametros permite que se puedan establecerrelaciones entre los diferentes parametros de configuracion de la interfaz. Por ejemplo,al configurar una memoria el disenador normalmente conoce la anchura de los buses dedatos y la cantidad de posiciones de memoria que necesita implementar, mientras queotros parametros necesarios para configurar el core, como por ejemplo la anchura del busde direcciones, pueden calcularse a partir de los parametros anteriores.

Declarar el valor de un parametro como funcion de otros parametros desempena undoble papel. En unos casos, permite al disenador indicar al usuario del core un valor re-comendado para ese parametro. Otras veces, que el valor indicado en la configuracion delparametro no es una recomendacion sino una restriccion. Por lo tanto, utilizar funcio-nes para definir los parametros no solo permiten establecer relaciones entre parametros,tambien permiten al disenador del core acotar los valores de entrada a ciertos parametros.

Por lo general, es posible que determinados juegos de valores en los parametros nogeneren una implementacion correcta. De nuevo en el ejemplo de la memoria, aunque elparametro del bus de direcciones pudiera tomar valores arbitrarios, si el valor introducidoen este parametro es menor al requerido para direccionar la profundidad de la memoria,parte de la misma no podra ser accedida. Con el encapsulado estructural, durante ladeclaracion del parametro el disenador no solo podra acotar el valor mediante el uso defunciones, sino que ademas puede restringirlo mediante tipos que han sido declarados en


...

<xs:complexType name="typeattributes">

<xs:sequence>

<xs:element name="attribute"

type="typevalue"


</xs:sequence>

</xs:complexType>

...

Figura 5.4: Encapsulado Estructural. Atributos.

la seccion de definiciones.

La cantidad de informacion que puede aportar el encapsulado estructural permite a lasherramientas EDA, tanto un mejor procesado de los cores, como una mejor presentacional usuario. Las relaciones mediante funciones y restricciones de los parametros no solopermiten verificar el juego de valores en los parametros por parte de las herramientas, sinoque tambien permiten presentar diferentes posibilidades de configuracion de un mismocore. Por ejemplo, se puede presentar una interfaz simplificada del componente que permitasolo configurar los parametros que no pueden ser calculados mediante funciones de otrosparametros, o bien se puede presentar la interfaz completa donde se permita al usuario laconfiguracion de todos los parametros (bajo la responsabilidad del usuario).

5.2.3. Atributos (attributes)

Si los parametros pueden considerarse como un elemento de entrada para la configura-cion del diseno, los atributos son un elemento de salida que permite obtener informacionde la propia implementacion.

La definicion de este tipo dota al encapsulado estructural de un mecanismo sencillopara informar de caracterısticas de un core sin que sea necesario conocer detalles de im-plementacion. Se pueden utilizar los atributos para guiar en el proceso de configuracion deparametros, pero tambien pueden utilizarse para fijar caracterısticas de la implementacion,como por ejemplo latencia, throughput, etc.

En la Figura 5.4 se recoge la definicion de los atributos en el XML Schema: la de-claracion de un atributo constara de un identificador unico del atributo, el tipo del valordevuelto en el atributo, y un valor de inicializacion por defecto. Otros campos opcionalesincluyen una descripcion del atributo.

El identificador permite referenciarlo y utilizarlo tanto para la definicion de nuevosatributos, como en posteriores secciones del encapsulado.

El tipo del atributo permite acotar los valores que tomara el atributo. Al igual quelos parametros, puede definirse utilizando los tipos basicos, o bien utilizando tiposdeclarados en la primera seccion de definiciones.

El valor por defecto define la expresion que se evaluara para inicializar el atributo.


Ejemplo 5.5 Declaracion de un atributo e inicializacion mediante una expresion....

<attribute id="data_depth">


<type>int32</type>

<value>

<valf id="pow2">

<arg><vall>addr_width</vall></arg>

</valf>

</value>

</attribute>

...

Al igual que los parametros, los campos opcionales que se pueden especificar durante ladeclaracion de un atributo permiten ampliar la informacion que un usuario puede requerirpara utilizar el atributo. Estos campos incluyen una descripcion similar a la que se puedeencontrar durante la declaracion de un parametro.

Los atributos pueden tomar su valor evaluando una funcion que puede tomar comoentrada otros parametros y atributos. Su declaracion es por lo tanto similar a la de unparametro cuyo valor por defecto se declara mediante una funcion, pero mientras queel parametro configura algun aspecto de la implementacion, el atributo no modifica niconfigura dicha implementacion, sino que informa de sus caracterısticas.

Ejemplo 5.6 Declaracion de un atributo e inicializacion a constante....



<type>int8</type>


</attribute>

...

Una caracterıstica importante de los atributos es el momento en el que se puede reali-zar su evaluacion. Algunos atributos se podran evaluar directamente a partir de los valoresque tomen los parametros de configuracion, mientras que otros atributos necesitaran pro-cesar la implementacion para calcular su valor. De manera general, el primer conjunto deparametros, necesitara de una menor cantidad de procesado para su calculo, mientras queel segundo conjunto permitira informar de caracterısticas mas dependientes de la propiaimplementacion a costa de un mayor coste computacional.

En los Ejemplos 5.5 y 5.6 se han declarado dos atributos distintos. Pero mientras queen el Ejemplo 5.5 el valor del atributo puede calcularse mediante una llamada a funcion,en el Ejemplo 5.6 se ha inicializado a una constante, y el valor que tomara dicho atributoha de calcularse analizando la propia implementacion.

El primer conjunto de atributos, los que pueden calcularse a partir de la evaluacionde funciones, se designaran como atributos de pre-generacion. Permitiran al disenador in-formar de valores recomendados para ciertos parametros, informar de caracterısticas de laimplementacion, e incluso implementar estimaciones rapidas de la implementacion. Paradeterminar el valor de estos atributos, el disenador cuenta unicamente con el valor de con-figuracion de los parametros y el propio conocimiento de la arquitectura que implemente,lo que limita tanto la complejidad como la precision de estos estimadores.

Los atributos permiten al disenador incorporar nuevas funciones que ayuden o guıen la


seleccion de los parametros de configuracion. Por ejemplo, se puede declarar un atributoque recomiende directamente un valor mınimo o un valor maximo de un parametro, ose puede declarar un atributo que indique la calidad de todo un juego de parametros.En este sentido, el disenador puede incorporar la evaluacion de funciones que estimencaracterısticas de la implementacion, como por ejemplo area, prestaciones, etc.

El segundo conjunto de atributos, que se basan en un analisis de la propia estructurade la implementacion, se designara como post-generacion. Son utiles para informar decaracterısticas de la implementacion que son difıciles de calcular o de estimar a partirdel valor de los parametros de configuracion, sobre todo para implementaciones donde losparametros guıan un proceso de generacion de la arquitectura, es decir implementacionesdinamicas.

Estos parametros inicializan su valor a una constante, y permiten actualizar dichovalor durante el analisis de la estructura de la arquitectura. Frente a los atributos delprimer conjunto (pre-generacion), este conjunto es capaz de informar de caracterısticasmas precisas. Pueden utilizarse para informar de caracterısticas dependientes del procesoseguido para la generacion de la arquitectura, o para implementar estimaciones mas pre-cisas que las anteriores. En el 7 se mostrara como utilizar los atributos para implementarestimadores de la arquitectura generada.

5.2.4. Macropuertos (macroports)

Los macropuertos definen el conjunto de senales de entrada y salida del core. A dife-rencia de la declaracion de puertos en los HDLs clasicos, cada macropuerto definido enel encapsulado permite agrupar todo un conjunto de senales en una unica declaracion.Ademas, con la declaracion de un macropuerto no solo se declaran las senales que lo for-man, sino que tambien declara la funcionalidad que cumple el conjunto de senales queforman el macropuerto, ası como caracterısticas de temporizacion.

El uso de los macropuertos obliga al disenador a utilizar el conjunto de senales, ası comoel conjunto de protocolos definidos para el conjunto de senales, si quiere que su diseno seacompatible con otros disenos que utilicen el mismo tipo de macropuerto. Frente a la perdidade flexibilidad que suponen, simplifican el proceso de interconexion y sincronizacion desenales entre diferentes cores, y por lo tanto su reutilizacion.

En la Figura 5.5 se muestra su definicion en el XML Schema: la declaracion de unmacropuerto constara de un identificador unico junto con la referencia al tipo de ma-cropuerto utilizado. Los diferentes tipos de macropuertos se encuentran definidos en unabiblioteca externa al encapsulado. Una caracterıstica de estos macropuertos es que permi-ten cierto grado de parametrizacion, por lo que durante la declaracion de la instancia deun macropuerto se pueden configurar sus parametros a partir del valor de los parametrosy atributos previamente definidos en el encapsulado, y tambien con funciones definidas apartir de estos elementos.

En el Ejemplo 5.7 se muestra la declaracion de un macropuerto. La declaracion masbasica constara del identificador y del tipo de macropuerto utilizado. El resto de camposque puede contener la declaracion son una descripcion textual de la funcion del macropuer-to, ası como un listado de los parametros configurables del macropuerto. No es necesarioasignar un valor de configuracion a todos los parametros de un macropuerto, ya que los


...

<xs:complexType name="typemacroportportproperty">

<xs:sequence>

<xs:element name="value"

type="typevalueval" />

</xs:sequence>

<xs:attribute name="id"

type="xs:string" />

</xs:complexType>

<xs:complexType name="typemacroportport">

<xs:sequence>

<xs:element name="description"

type="xs:string" />

<xs:element name="type"

type="xs:string" />

<xs:element name="property"

type="typemacroportportproperty" />

</xs:sequence>


type="xs:string" />

</xs:complexType>

<xs:complexType name="typemacroportnet">

<xs:sequence>

<xs:element name="type" />

<xs:element name="mport" minOccurs="1"

maxOccurs="unbounded">

<xs:complexType>


type="xs:string" />

<xs:attribute name="signal"

type="xs:string" />

</xs:complexType>

</xs:element>

</xs:sequence>


type="xs:string" />

</xs:complexType>

<xs:complexType name="typemacroports">

<xs:sequence>

<xs:element name="macroport"

type="typemacroportport"


<xs:element name="net"

type="typemacroportnet"


</xs:sequence>

</xs:complexType>

...

Figura 5.5: Encapsulado Estructural: Macropuertos.

que no sean asignados tomaran un valor por defecto.

Cada macropuerto define todas las senales necesarias para cumplir la funcion para laque ha sido disenado. Tal definicion hace posible que la declaracion de varios macropuertoscomparta una o varias de estas senales, de modo que durante la declaracion del macro-puerto en el encapsulado se especificaran de forma explıcita estas relaciones de senales:el elemento net permite agrupar senales que forman parte de diferentes macropuertos yasignarles un tipo. En el Ejemplo 5.8 se han declarado los macropuertos para una memo-ria. En dicho ejemplo se declara una agrupacion de senales de reloj de los macropuertostanto de entrada como de salida del componente.

5.3. Encapsulado Funcional

Describir cores parametrizables permite mejorar sus posibilidades de reutilizacion, peropresenta problemas de escalabilidad. Incluso con el encapsulado estructural, y a pesar delas mejoras que los lenguajes de descripcion, como por ejemplo dHDL puedan aportar, elgrado de parametrizacion que los disenos de manera practica pueden implementar tieneun lımite.

En este contexto, pretender que una misma arquitectura (entendida como una estruc-

5.3 Encapsulado Funcional 81

Ejemplo 5.7 Declaracion de un macropuerto....



<type>lvi</type>


<value><vall>data_width</vall></value>

</property>

</macroport>

...

Ejemplo 5.8 Agrupacion de senales entre macropuertos....


...

</macroport>

<macroport id="addr_p">

...

</macroport>

<macroport id="data_o">

...

</macroport>

...

<net id="clock">


<mport id="data_i" signal="clock" />

<mport id="addr_p" signal="clock" />

<mport id="data_o" signal="clock" />

</net>

...

tura hardware que permite implementar una funcionalidad determinada) abarque todo unespacio de diseno, por ejemplo area-prestaciones, puede resultar ineficiente y costoso desdeel punto de vista de diseno: aunque se implemente un diseno con muchos parametros, estehabrıa sido complejo de desarrollar y sobre todo de verificar. En este caso puede resultarmejor la implementacion de dos arquitecturas diferentes, cada una orientada a cubrir unaparte del espacio de diseno.

Dos arquitecturas diferentes, aunque implementen la misma funcion, es normal quepresenten diferente juego de parametros, puertos y senales de acceso. Incluso el funciona-miento de ambas implementaciones puede resultar totalmente distinto, por ejemplo unaimplementacion orientada a mejorar las prestaciones puede haberse implementado me-diante un pipeline, mientras que la implementacion que minimice el area puede haberseimplementado mediante una arquitectura iterativa.

Aunque el encapsulado estructural y el lenguaje dHDL permiten un mayor grado deparametrizacion en los disenos y aportan una mayor informacion de las caracterısticas dela implementacion (que ayudan en la tarea de reutilizar al core en nuevos disenos) siguesiendo compleja la tarea de evaluar diferentes implementaciones aunque realicen la mismafuncion.

En la propuesta de esta Tesis se incorpora un nuevo encapsulado, en este caso funcional,que a diferencia del declarado con componentes implementados en lenguajes convencionaleso con el propio encapsulado estructural, busca encapsular la implementacion realizada pordiversos cores. Este encapsulado funcional no se encuentra ligado a una implementacionconcreta, sino que permite describir de una manera mas o menos generica la funcionalidadrequerida para su implementacion.


El encapsulado funcional no declara parametros que configuran implementaciones par-ticulares, sino que describe mediante caracterısticas la funcionalidad de los cores que loimplementan. Por lo tanto, el encapsulado funcional no es un sustituto del encapsuladoestructural, sino que se apoya en este: el encapsulado funcional ofrece una descripcionbasada en caracterısticas de la funcionalidad que deben implementar los cores, pero esresponsabilidad del disenador de estos cores transformar estas caracterısticas en los ti-pos definidos en el encapsulado estructural, es decir, generar una configuracion del core apartir de estas caracterısticas.

Dependiendo del numero de caracterısticas que se fijen en el encapsulado funcional, sepodra describir la funcion a implementar a diferentes niveles: puede simplemente especifi-car la funcion, o bien detallar todo un conjunto de caracterısticas tanto funcionales comorelacionadas con la implementacion. La descripcion de este encapsulado no impone ni li-mita la cantidad de caracterısticas ni el uso que se haga de ellas, lo que permite realizardesde encapsulados muy genericos y con alto grado de abstraccion, hasta encapsuladosmucho mas detallados y cercanos a una posible implementacion.

Un ejemplo de encapsulado generico puede ser el que unicamente especifica su funcion,por ejemplo la funcion filtro. Un componente generico ası descrito puede tener innumera-bles implementaciones, y por lo tanto su utilidad resulta bastante limitada si se pretendealcanzar una implementacion concreta.

En el encapsulado funcional se declaran las caracterısticas que permiten detallar lafuncion. En el ejemplo de la funcion filtro se puede anadir una caracterıstica que indiquesu tipo (paso bajo, paso banda, etc). Esta nueva caracterıstica permite a su vez clasificarlas implementaciones, con lo que el disenador del sistema puede acotar aun mas entre lasposibles implementaciones la funcion buscada. Nuevas caracterısticas, como por ejemplo,si implementa una estructura FIR o IIR, su orden, etc., van a permitir reducir entre elespacio de posibles implementaciones.

El encapsulado funcional permite describir todo un conjunto de posibles implemen-taciones, independientemente de las posibilidades de configuracion que ofrezcan. Son loscores (o mejor dicho los disenadores de los cores) los que indican como implementan elencapsulado:

El encapsulado estructural ofrece tanto las posibilidades de configuracion como lospuertos del core. Ademas, una arquitectura puede implementar diferentes funciones,por lo que el disenador definira como se debe configurar y conectar la arquitecturapara implementar cada funcion en lo que se designa como empaquetado.

En el encapsulado funcional se puede asociar a cada caracterıstica un valor, obte-niendose un conjunto de restricciones sobre la funcion descrita. Es este conjuntode caracterısticas con valor (restricciones) lo que se pasa al empaquetado para suevaluacion.

El empaquetado genera una configuracion del core: parte de la configuracion lapuede fijar la propia funcion, mientras que otra parte de su configuracion la puedeobtener a partir de la transformacion de los valores de las caracterısticas en valoresde parametros.

El core se genera y evalua. A partir de la informacion obtenida de la implemen-



...

<xs:element name="declaration">

<xs:complexType>

<xs:sequence>

<xs:element name="function"

type="typefunction" />

<xs:element name="features"

type="typefeatures" />

<xs:element name="flows"

type="typeflows" />

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Figura 5.6: Estructura del encapsulado funcional.

tacion en el empaquetado se verifica que se cumple con las restricciones de las ca-racterısticas. El core solo se considera implementacion valida si cumple todas lascaracterısticas.

El encapsulado funcional, al igual que describe la funcion a implementar mediantecaracterısticas, define un tipo especial, los flujos, cuyo objetivo es proporcionar una des-cripcion generica de las capacidades de entrada y salida que requiere la funcion.

La descripcion del encapsulado funcional se divide en tres secciones, como se muestraen el XML Schema de su definicion en la Figura 5.6. Una primera seccion es declarativa dela propia funcion ası como sus relaciones con otros encapsulados funcionales. Una segundaseccion para la descripcion de las caracterısticas de la funcion. Finalmente, una seccionpara la declaracion de los flujos de entrada y salida.

5.3.1. Declaracion de la funcion (function)

De entre los datos de interes que se pueden definir en el encapsulado funcional, elprincipal es la funcionalidad que implementa. La declaracion de esta funcion no solo esunica entre los diferentes encapsulados, permitiendo ası su identificacion y su clasificacion,sino que sirve como referencia para los cores que la implementan. Ademas, junto con elidentificador de la funcion se incorpora una descripcion textual de la propia funcion.

Otro de los datos relevantes que son declarados en esta seccion es la version actualdel encapsulado. Al igual que las propias implementaciones, el encapsulado puede modifi-carse y mejorarse a lo largo del tiempo, por lo que si al encapsulado se le anaden nuevascaracterısticas, es posible que no todas las implementaciones soporten los nuevos cambios.

En el ejemplo 5.9 se muestra la declaracion de una funcion cuenta. La funcion quedaidentificada de manera unica con el campo library y el identificador de la funcion, demodo que las funciones pueden ordenarse dentro de un espacio de nombres.

Los campos de version permiten introducir cambios en el encapsulado, pero mante-niendo la compatibilidad con cores que anteriormente ya implementasen la funcion.


Ejemplo 5.9 Declaracion de la funcion de un contador....

<function id="count">


<library>logic</library>

<version>

<ver n="2" d="2010-07-08">


</ver>

<ver n="1" d="2010-04-08">


</ver>

</version>

</function>

...

5.3.2. Declaracion de caracterısticas (features)

Si en la primera seccion se define la funcion del diseno encapsulado, en esta segundaseccion, cuya definicion se puede observar en la Figura 5.7, permite refinarla mediante ladeclaracion de caracterısticas.

Uno de los objetivos de la definicion y declaracion del encapsulado funcional es aumen-tar el grado de abstraccion sobre el encapsulado estructural. Para realizar una declaracionde un mayor nivel de abstraccion, las caracterısticas que se definen en el encapsulado pue-den contar con cierta generalidad y estan orientadas a definir opciones relacionadas conla funcion que se describe.

Las caracterısticas definidas en el encapsulado funcional pueden utilizarse de diferen-tes maneras. De manera general, las caracterısticas declaradas en el encapsulado funcionalserviran para detallar aspectos de la propia funcion. Tambien se utilizaran para clasificar yseleccionar entre diferentes implementaciones, para configurar los parametros de las imple-mentaciones, e incluso se pueden utilizar para implementar un cierto grado de exploraciondel espacio de diseno.

Ejemplo 5.10 Declaracion de caracterıstica....

<feature id="precision">


<version ver="2">


<type>int8</type>

</version>

<version ver="4">


<union type="int8">

<item>8</item>

<item>16</item>

<item>32</item>

</union>

</version>

</feature>

...

En el Ejemplo 5.10 se muestra la declaracion de la caracterıstica precision. La decla-racion basica de la caracterıstica cuenta con su identificador, una descripcion generica delpapel de dicha caracterıstica y, finalmente, la declaracion del tipo y valores que toma. Ladeclaracion de este ultimo campo se realiza en un bloque que permite el versionado de la


...

<xs:complexType name="typefeaturesfeatureversionrange">

<xs:sequence>

<xs:element name="from" type="xs:string" />

<xs:element name="to" type="xs:string" />

<xs:element name="step" type="xs:string" />

</xs:sequence>


</xs:complexType>

<xs:complexType name="typefeaturesfeatureversionunion">

<xs:sequence>

<xs:element name="item" type="xs:string"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="type" type="xs:string"/>

</xs:complexType>

<xs:complexType name="typefeaturesfeatureversion">

<xs:sequence>

<xs:element name="description" type="xs:string" />

<xs:choice>

<xs:element name="type" type="xs:string" />

<xs:element name="range"

type="typefeaturesfeatureversionrange" />

<xs:element name="union"

type="typefeaturesfeatureversionunion" />

</xs:choice>

</xs:sequence>

<xs:attribute name="ver" type="xs:positiveInteger" />

<xs:attribute name="rev" type="xs:integer" />

</xs:complexType>

<xs:complexType name="typefeaturesfeature">

<xs:sequence>


<xs:element name="version"

type="typefeaturesfeatureversion"

maxOccurs="unbounded" />

</xs:sequence>


</xs:complexType>

<xs:complexType name="typefeatures">

<xs:sequence>

<xs:element name="feature"

type="typefeaturesfeature"


</xs:sequence>

</xs:complexType>

...

Figura 5.7: Encapsulado Funcional. Caracterısticas.

caracterıstica.

Ası al introducir una nueva caracterıstica en el encapsulado funcional, este bloque reco-gera el numero de version del encapsulado en el que se introdujo, ası como todos los datosque describen la caracterıstica (tipo, valor, descripcion, etc.). Una caracterıstica puedemantener su definicion frente a cambios del encapsulado, como por ejemplo la modifica-cion o introduccion de otras caracterısticas, que incrementaran la version del encapsulado.

Una vez incorporada al encapsulado, la caracterıstica actualizara su version a la delencapsulado cuando sea modificada, en cuyo caso incorporara un nuevo bloque descriptivocorrespondiente a la version del encapsulado.

Este sistema para la declaracion de las caracterısticas permite de un modo sencillo, poruna parte actualizar la descripcion del encapsulado con la incorporacion o modificacionde caracterısticas, y por otra parte permite mantener la compatibilidad con cores que yaimplementasen el encapsulado.

El Ejemplo 5.10 muestra la descripcion basica de la caracterıstica precision, que seincorporo al encapsulado en su version 2, y posteriormente se ha redefinido dicha carac-terıstica en la version 4 del encapsulado. Con esta descripcion del encapsulado es posiblemantener la compatibilidad con cores que lo implementasen en sus diferentes versiones:antes de la version 2 donde no se encuentra definida la caracterıstica precision, entre lasversiones 2 a la 4 donde es valida la primera descripcion (2), y desde la version 4 con la


ultima descripcion de la caracterıstica.

El objetivo principal de las caracterısticas es refinar la descripcion de la funcion, aunquepueden utilizarse para realizar otras tareas: ayudar en la seleccion de implementaciones,permitir la exploracion del espacio de diseno e incluso buscar configurar parametros delencapsulado estructural.

5.3.2.1. Refinamiento de la funcion

La declaracion de la funcion del encapsulado permite unicamente clasificar los cores,entre los que implementan al encapsulado y los que no. La descripcion de la funcion sepuede refinar mediante la declaracion de caracterısticas.

Pero frente a las implementaciones y a los encapsulados estructurales orientados a con-figurar estas implementaciones, las caracterısticas deben dirigirse a describir la funcion.Frente a optimizar los detalles de implementacion de grano fino que pueden conseguir-se a traves de los parametros de bajo nivel, las caracterısticas deben buscar ganar engeneralidad con el fin de abarcar el mayor conjunto de posibles implementaciones.

Tampoco es un objetivo del encapsulado funcional incluir los posibles parametros deconfiguracion que las diferentes implementaciones puedan presentar. Este encapsuladoofrecera un conjunto de caracterısticas que el diseno debe implementar para ser consideradaimplementacion valida de la funcion.

El disenador debe buscar declarar en el encapsulado caracterısticas que permitan des-cribir la funcionalidad a implementar. Por ejemplo, en la descripcion del encapsulado paraun filtro pueden declararse caracterısticas que describan el tipo de filtro (FIR o IIR), laaritmetica (int8, int16, int32), o incluso el objetivo del diseno (altas prestaciones). Fren-te a estas caracterısticas que describen posibles implementaciones, se pueden declarar ca-racterısticas especıficas del campo de aplicacion: nivel de rizado en banda de paso (rizado),frecuencia de corte (frecuencia) y atenuacion en la banda de corte (atenuacion). En elEjemplo 5.11, se muestra la descripcion de algunas de estas caracterısticas.

Ejemplo 5.11 Declaracion de las caracterısticas de un filtro....

<feature id="rizado">


<version ver="1" rev="0">


<type>int8</type>

</version>

</feature>

<feature id="frecuencia">

<description>

...

</description>



<range type="float">

<from>0.0</from>

<to>1.0</to>

<step>0.1</step>

</range>

</version>

</feature>

<feature id="atenuacion">




<type>int8</type>

</version>

</feature>

...

Estas ultimas caracterısticas son las que mejor describen la funcion del encapsulado,pero es posible declarar caracterısticas que clasifiquen diferentes implementaciones, o bienbusquen configurar de una manera mas o menos directa los parametros de las implemen-taciones, e incluso ayuden en la tarea de enmarcar una implementacion en los diferentes


puntos del espacio de diseno. Esta division no es estricta, ya que la decision de comoutilizar las caracterısticas recae en el disenador del core, de modo que por ejemplo unacaracterıstica pensada para clasificar la implementacion en el espacio de diseno puedeutilizarse tambien como parametro de configuracion de la arquitectura.

5.3.2.2. Seleccion de implementaciones

El encapsulado funcional debe ayudar a buscar entre las posibles implementaciones yseleccionar la que se ajuste al juego de caracterısticas. Por lo tanto, otro de los usos de lascaracterısticas es el de permitir clasificar y seleccionar entre sus posibles implementaciones.La declaracion de la propia funcion del encapsulado es el primer paso para realizar estaclasificacion, al separar los cores entre los que la implementan y los que no.

Nuevas caracterısticas permitiran discriminar las implementaciones del encapsulado.Por ejemplo, un encapsulado que define la funcion cuenta, puede declarar caracterısticasque clasifican las implementaciones segun el tipo de contador, como en el Ejemplo 5.12al declarar la caracterıstica count type. En el ejemplo, la caracterıstica permite clasificarlos tipos de contador entre binarios, gray, y finalmente deja la posibilidad de indicar otrotipo de contador.

Ejemplo 5.12 Declaracion de caracterıstica para clasificacion de implementaciones....

<feature id="count_type">




<union type="string">

<item>binary</item>

<item>gray</item>

<item>other</item>

</union>

</version>

</feature>

...

Puesto que no se impone limitacion en la definicion de las caracterısticas, estas puedenutilizarse para describir cualquier aspecto de las propias implementaciones, en el ejemplode la funcion cuenta, si esta es ascendente o descendente, si permite pre-carga del valorde cuenta, si puede comportarse como un temporizador, etc. Todas estas caracterısticaspermiten clasificar las implementaciones, aunque se alejan de otro de los objetivos delencapsulado funcional: ocultar detalles de la implementacion.

Frente a la declaracion de caracterısticas que permiten de una manera directa la clasi-ficacion de implementaciones, cualquier caracterıstica declarada en el encapsulado permiterealizar esta clasificacion aunque sea de manera indirecta. Para que un core sea una imple-mentacion del encapsulado funcional debe cumplir con todas las restricciones impuestaspor los valores de todas las caracterısticas, de modo que dos implementaciones seran dife-rentes con que solo difieran en una caracterıstica: el Ejemplo 5.10 permite diferenciar undiseno que solo implementacion 8 bits, frente a otra implementacion que solo implementa16 bits.


5.3.2.3. Configuracion de parametros

Como se ha mencionado anteriormente, no es en el encapsulado funcional donde seindica la manera en que el core se ha de implementar, sino en el empaquetado, y por lotanto junto con la implementacion, donde se configuran los parametros a partir del valorde las caracterısticas. Cada core dispondra de su propio juego de parametros, que estanorientados a configurar detalles de la implementacion, y que de manera general no tienenpor que corresponderse con las caracterısticas definidas en el encapsulado funcional.

Cuando estos cores implementan un encapsulado funcional, el valor que tomaran losparametros se configura a partir del valor de las caracterısticas declaradas en el encap-sulado funcional, otras veces sera una funcion de una o varias de estas caracterısticas,incluso es posible que las opciones de configuracion que ofrece el encapsulado funcional nopermitan configurar todos los detalles de bajo nivel de las implementaciones.

En el ejemplo 5.10 la caracterıstica declarada precision esta enfocada a configurar losparametros que controlen el ancho de bit de los operadores de diferentes implementaciones.El encapsulado funcional no impone a estas implementaciones la necesidad de declarardirectamente parametros que se configuren a partir de las caracterısticas, sino que tienela libertad de adaptar los parametros ya definidos en el core.

De nuevo, no hay que olvidar el objetivo del encapsulado funcional: describir la funcion.Si bien resulta de utilidad declarar ciertas caracterısticas que ayuden a fijar los parame-tros de las implementaciones, la declaracion de un numero excesivo de estas caracterısticascorre el riesgo de perder las ventajas que el encapsulado funcional presenta frente al es-tructural. A mayor numero de estas caracterısticas es cada vez mas probable que no seande utilidad para todo el conjunto de disenos que se corresponden con el encapsulado, yque el encapsulado funcional se parezca cada vez mas a un encapsulado estructural.

5.3.2.4. Exploracion del espacio de diseno

Durante el diseno del encapsulado funcional se pueden declarar caracterısticas queinformen de atributos de la implementacion como area, prestaciones, o consumo, etc.En el Ejemplo 5.13 se declara una caracterıstica que permite configurar una restriccionde area, un valor de 10 indicara que no existe restriccion y 1 indicara que se buscanimplementaciones de area mınima.

Aunque la declaracion de caracterısticas de este tipo permite clasificar las implemen-taciones dentro del espacio de diseno, la decision de enmarcar la implementacion dentrode este espacio es del propio disenador del core. Si por ejemplo se redefine la caracterısticaanterior, como en el ejemplo 5.14, se permite al disenador enmarcar su implementacion entres zonas del espacio de diseno: implementaciones optimizadas para minimizar el area,implementaciones de altas prestaciones, o implementaciones equilibradas.

La declaracion de este tipo de caracterısticas no solo permite clasificar la implemen-tacion en el espacio de diseno, tambien pueden utilizarse para guiar la configuracion delos parametros del encapsulado estructural. Un core, puede utilizar la caracterıstica delejemplo 5.13 para decidir como implementar su arquitectura: por ejemplo valores por de-bajo de tres generan implementaciones iterativas, mientras que valores por encima de ochogeneran una arquitectura en pipeline; finalmente para valores intermedios se implementa


Ejemplo 5.13 Declaracion de caracterıstica para la exploracion del espacio de diseno....

<feature id="area">

<description>

Requisito de area

de la implementacion:

1 - Area mınima

10 - Sin limitacion

</description>



<range type="int8">

<from>1</from>

<to>10</to>

<step>1</step>

</range>

</version>

</feature>

...

Ejemplo 5.14 Declaracion de caracterıstica....

<feature id="area">

<description>

Requisito de area

de la implementacion:

1 - Area mınima

10 - Sin limitacion

</description>



<range type="int8">

<from>1</from>

<to>10</to>

<step>1</step>

</range>

</version>




<item>low</item>

<item>middle</item>

<item>high</item>

</union>

</version>

</feature>

...

una arquitectura mixta.

5.3.3. Declaracion de entrada y salida (flows)

Las caracterısticas describen de manera generica la funcionalidad de diferentes cores,permitiendo la clasificacion, seleccion y configuracion de diferentes implementaciones. Unavez configurada una implementacion ofrecera un conjunto de puertos o senales a partir delos que intercambiar informacion con el resto del sistema, que por lo general sera distintopara diferentes implementaciones.

El encapsulado estructural utiliza los macropuertos para unificar en una declaraciontodo un conjunto de senales, y que a su vez estan orientados a implementar un mecanismode acceso al core. Pese a que este tipo esta orientado a simplificar el proceso de intercone-xionado de cores a costa de la perdida de flexibilidad, no resulta un tipo conveniente paradeclarar tanto los metodos de comunicacion como de datos en el encapsulado funcional.

La descripcion de la entrada-salida a nivel funcional se realiza mediante flujos, debidoa que el objetivo de esta Tesis es la especificacion centrada en procesado de senal, y losflujos representan un mecanismo conveniente para la descripcion de secuencias de muestras(data streams). La declaracion de los flujos se realiza en la tercera seccion del encapsulado.


...

<xs:complexType name="typeflowsflowversiondt">

<xs:sequence>

<xs:element name="mean" type="xs:float" />

<xs:element name="peak" type="xs:float" />

</xs:sequence>

</xs:complexType>

<xs:complexType name="typeflowsflowversionop">

<xs:sequence>

<xs:element name="opid" maxOccurs="unbounded">

<xs:complexType>



</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="typeflowsflowversion">

<xs:sequence>


<xs:element name="dt" type="typeflowsflowversiondt" />

<xs:element name="op" type="typeflowsflowversionop" />

</xs:sequence>

<xs:attribute name="ver" type="xs:positiveInteger" />

<xs:attribute name="rev" type="xs:integer" />

</xs:complexType>

<xs:complexType name="typeflowsflow">

<xs:sequence>


<xs:element name="version" type="typeflowsflowversion"


</xs:sequence>


</xs:complexType>

<xs:complexType name="typeflows">

<xs:sequence>

<xs:element name="flow" type="typeflowsflow"


</xs:sequence>

</xs:complexType>

...

Figura 5.8: Encapsulado Funcional. Entrada y salida.

Los flujos recogen la informacion basica de entrada-salida: numero y tipo de cada dato,e incluso informacion temporal basica. Su definicion en XML Schema se encuentra en laFigura 5.8.

Ejemplo 5.15 Declaracion de un flujo....

<flow id="input_op" io="in">

<description>Stream de entrada de datos.</description>



<dt>

<mean>1.0</mean>

<peak>0.0</peak>

</dt>

<op>

<opid id="op_a" type="int8"/>

<opid id="op_b" type="int8"/>

</op>

</version>

</flow>

...

En el Ejemplo 5.15 se muestra la declaracion del flujo para los operadores de entradade una funcion. En la declaracion se le asigna un identificador (id=‘‘input op’’) y sudireccion io=‘‘in’’. El resto de la declaracion se divide en dos partes:

Una primera parte, dt, declara las tasas normalizadas del flujo que permiten carac-terizar las prestaciones e informacion temporal asociada al conjunto de datos

5.4 Empaquetado 91

En la segunda parte, op, se enumeran los distintos operadores o datos mediante unidentificador y un tipo.

Los datos declarados en un flujo pueden relacionarse con puertos definidos en el en-capsulado estructural, pero su funcion es la de describir los datos asociados a la funcionque se describe en el encapsulado. Ası, en la declaracion de un flujo no se hace referenciaa senales de sincronizacion ni de protocolo, como por ejemplo senales de clock o enable.Cada dato declarado en el flujo se encuentra a su vez tipado. Ası se diferencia entre el tipode los operandos de entrada a una funcion con la precision que pueda trabajar el modulo(Ejemplo 5.10).

Un flujo permite asociar un conjunto de datos (operadores de funcion), que tienen encomun unas caracterısticas de prestaciones: media (mean) y pico (peak). Estas caracterısti-cas se utilizan para describir el volumen de datos asociado al flujo. Que un core cumplaambas caracterısticas no solo dependera de los macropuertos utilizados, sino tambien dela propia arquitectura implementada. El valor de mean describe el volumen de datos sos-tenido, mientras que el valor peak permite describir volumenes de datos esporadicos sobrela media:

En el ejemplo 5.15 con valores mean=1.0 y peak=0.0, se indica que se requiere un vo-lumen sostenido de una muestra por ciclo, y por lo tanto describe a implementacionesque permitan el procesado de manera continua.

Valores mean=0.01 y peak=0.0 indican que es necesario procesar una muestra ca-da cien ciclos de una manera regular. Estos valores describen implementaciones deprestaciones mas modestas que el caso anterior.

Valores de mean=0.001 y peak=100.0 indican que cada mil ciclos se reciben de formano regular cien muestras.

Los ejemplos descritos ponen de manifiesto que la implementacion de los flujos depen-den de los puertos y de la arquitectura de la implementacion, pero su declaracion es losuficientemente generica como para describir de una manera uniforme diferentes imple-mentaciones. Al igual que las caracterısticas que describen la funcion en el encapsulado,es al empaquetar el core cuando se establecen la relacion entre la arquitectura y puertosutilizados en la implementacion con los flujos declarados.

5.4. Empaquetado

El encapsulado estructural permite describir una implementacion concreta. El encapsu-lado estructural de otra implementacion, aunque realice una funcion similar, puede declarartipos diferentes: desde diferentes parametros de configuracion hasta diferentes puertos decomunicacion.

Por otra parte, el encapsulado funcional describe las caracterısticas que deben imple-mentar los cores para cumplir la funcion. Incluso a nivel de comunicacion, este encapsuladodescribira las caracterısticas de los datos de manera independiente a como se implementena bajo nivel.



...

<xs:element name="encapsulation">

<xs:complexType>

<xs:sequence>

<xs:element name="function"

type="typefunction" />

<xs:element name="configuration"

type="typeconfiguration" />

<xs:element name="verification"

type="typeverification" />

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Figura 5.9: Esquema de empaquetado.

Puesto que el encapsulado funcional evita hacer mencion a detalles de implementacion,es junto con el encapsulado estructural donde se estableceran las relaciones entre ambosencapsulados, mediante lo que se denominara el empaquetado. Es por lo tanto responsa-bilidad del disenador del core establecer como su diseno implementa la funcion medianteel empaquetado del encapsulado estructural.

Ademas, un core puede ser configurado para realizar mas de una funcion, por lo quepuede ofrecer diferentes empaquetados, uno por cada funcion que implemente. Desde elpunto de vista practico, es como si el disenador del core, ademas de la propia implemen-tacion, lo acompana con un conjunto de notas de aplicacion.

En el empaquetado se define como las caracterısticas se transforman en parametros deconfiguracion. Tambien indica que caracterısticas se cumplen con la configuracion obteni-da. Diferentes aplicaciones definiran diferente numero y tipos de datos de entrada-salida,mientras que los macropuertos de bajo nivel se encontraran ligados a la implementacion.De nuevo el empaquetado permite indicar al disenador como se realiza esta corresponden-cia: adaptando, combinando o eliminando los macropuestos definidos en la implementacionpor otros que en principio cumplan las especificaciones de los flujos declarados en el en-capsulado funcional.

5.4.1. Configuracion del encapsulado estructural

La primera parte del empaquetado ha de definir como se configuran los parametrosde la implementacion a partir de las caracterısticas del encapsulado funcional. Puesto quelos parametros toman el valor por defecto declarado (literal o funcion) si no se inicializacon un nuevo valor, es el disenador el que decide que parametros ha de configurar y comorealizar la transformacion de las caracterısticas en valores de configuracion validos.

Ejemplo 5.16 Configuracion de un parametro a partir de una caracterıstica....


<value>

<vall from="features">width_bits<vall/>

<value/>

</parameter>

...

5.4 Empaquetado 93

...

<xs:complexType name="typevalueval">

<xs:choice>

<xs:element name="vall"

type="xs:string"/>

<xs:element name="valf"

type="typevaluevalfunction"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="typeconfigurationpara...">

<xs:sequence>

<xs:element name="value" type="typeval..."/>

</xs:sequence>

<xs:attribute name="from" type="xs:string" />

</xs:complexType>

<xs:complexType name="typeconfigurationpara...">

<xs:choice>

<xs:element name="value"

type="typeconfigurationparametervalue" />

</xs:choice>


</xs:complexType>

<xs:complexType name="typeconfiguration">

<xs:sequence>

<xs:element name="parameter"

type="typeconfigurationparameter"


</xs:sequence>

</xs:complexType>

...

Figura 5.10: XML Schema: Configuracion.

Un core puede tener parametros de configuracion que se correspondan directamentecon el valor de una caracterıstica definida en el encapsulado funcional, por ejemplo siuna caracterıstica indica la precision de una operacion en bits, puede transformarse di-rectamente en un parametro que configure el ancho de bit en la implementacion, como semuestra en el Ejemplo 5.16: el parametro del core data width se configura directamentea partir de la caracterıstica width bits.

Ejemplo 5.17 Configuracion de un parametro a partir de una caracterıstica pasada poruna funcion.

...


<value>

<valf id="dec2bin">

<value>

<vall from="features">precision</vall>

</value>

</valf>

</value>

</parameter>

...

Sin embargo, la caracterıstica puede encontrarse definida con un tipo propio de altonivel (integer, word, byte), por lo que el disenador debera utilizar una funcion que trans-forme el valor y tipo de la caracterıstica en un valor y tipo valido para el core (32, 16, 8).En el Ejemplo 5.17, se muestra como la configuracion del parametro data width se hacea traves de la llamada a la funcion dec2bit utilizando la caracterıstica precision.

Tambien resulta posible que el valor de un parametro se implemente a partir de la


evaluacion de varias caracterısticas. De nuevo, el disenador puede definir funciones quedevuelvan el valor y tipo adecuado para el parametro.

A la hora de configurar el encapsulado estructural el disenador no solo dispone de lascaracterısticas que definen la funcion, sino que tambien puede utilizar los datos definidos enlos flujos del encapsulado funcional. En el ejemplo 5.18, el parametro data width no solopermite configurar el ancho de bit con el que se implementara el core, sino que se utilizapara configurar los macropuertos de entrada de la implementacion. Su valor se configuraa partir de la llamada a la funcion max, que calcula el maximo entre la caracterısticawidth bits y el tipo asociado a los operandos de los flujos de entrada.

Ejemplo 5.18 Configuracion de un parametro....


<value>

<valf id="max">

<value><vall from="features">width_bits</vall></value>

<value><vall from="flows">op_a</vall/></value>

<value><vall from="flows">op_b</vall/></value>

</valf>

</value>

</parameter>

...

5.4.2. Verificacion de las caracterısticas implementadas

Una vez fijados los parametros y obtenida una configuracion del core, en una segundaparte del empaquetado el disenador debe indicar que caracterısticas cumple el core y cualesno, a partir de la configuracion obtenida.

Ejemplo 5.19 Verificacion de caracterıstica mediante funcion....


<value default="false">

<valf id="equal">

<value><vall from="parameters">data_width</vall></value>

<value><vall>-1</vall></value>

</function>

</value>

</feature>

...

La verificacion de una caracterıstica solo tiene dos valores validos: true en el casode que la implemente o false si no. En el Ejemplo 5.19 se muestra la verificacion dela caracterıstica precision, y solo se define la condicion para el caso que no se cumpla(ya que en todos los demas casos se cumplira). Hay que recordar que los parametrosdel encapsulado estructural se encuentran tipados y pueden ser restringidos, por ejemplomediante un rango, por lo que solo se obtendra una configuracion valida si el valor de lacaracterıstica se encuentra dentro de ese rango, y en caso contrario tomara como valor −1.

No todas la caracterısticas definidas en el encapsulado funcional se corresponderancon parametros de configuracion del core, con lo que es posible que ciertas caracterısticasno configuren ningun parametro del encapsulado estructural. Puesto que todas las carac-terısticas deben ser verificadas, se pueden devolver valores constantes. En el ejemplo 5.20

5.5 Ejemplos de encapsulados 95

Ejemplo 5.20 Verificacion de caracterıstica....

<feature id="area">

<value default="true"/>

</feature>

...

se indica que siempre se verifica la caracterıstica area.

Aparte de las caracterısticas que describen la funcion, en el empaquetado tambien severifica que la implementacion es capaz de soportar los flujos de entrada-salida. Ademasse ha de relacionar cada flujo de datos con los macropuertos de la implementacion.

Ejemplo 5.21 Verificacion de un flujo....

<flow id="input_op">

<op id="op_a">

<macroport id="add_a">


<valf id="equal">

<value>

<vall from="parameter">

data_width</vall></value>

<value><vall>-1</vall></value>

</valf>

</value>

<dt>

<mean>

<value>

<valf id="min">

<value>

<vall from="attribute">

throughput</vall></value>

<value>

<vall from="add_a.attribute">

throughput</vall></value>

</valf>

</value>

</mean>

<peak>


</peak>

</dt>

</op>

<op id="op_b">

<macroport id="add_b">

...

</op>

</flow>

...

En el ejemplo 5.21 se muestra la verificacion de un flujo:

Primero cada operando del flujo se ha de relacionar con un macropuerto del core, enel ejemplo op a se implementa mediante el macropuerto add a, mientras que op b

se implementa con el macropuerto add b.

En segundo lugar se evalua si el tipo de datos asociado a cada operando se hapodido configurar, en este caso mediante la llamada a una funcion utilizando comoparametro data width.

Finalmente se evalua el volumen de datos asociado a cada operando: se devuelveun valor para las caracterısticas de datos mean y peak. En el ejemplo peak=0.0

indica que no soporta exceso de datos. Sin embargo, sı soporta un volumen sostenidodefinido por mean. Esta caracterıstica se evalua a partir del atributo throughput

tanto de la implementacion como del macropuerto.

5.5. Ejemplos de encapsulados

A continuacion utilizaremos unos ejemplos para ilustrar el uso de los encapsulados pro-puestos en el capıtulo. Para ello utilizaremos ejemplos relacionados con las aplicaciones


Figura 5.11: Esquema simplificado de un DSP48E.

objetivo de la Tesis: procesado de senal en FPGAs. Un ejemplo se realizara con un com-ponente de FPGA de bajo nivel, DSP Slice, y otro ejemplo con componentes de utilidaddentro del campo de procesado de senal, los filtros FIR.

5.5.1. Encapsulado de DSP Slices

Como se vio en el capıtulo 3, un ejemplo de core de bajo nivel son los DSP Slices deXilinx, que aparecieron con la familia Virtex-4. Estos componentes son la evolucion de losmultiplicadores integrados presentes en dispositivos de familias anteriores. La estructurabasica de estos componentes cuenta con un multiplicador y una unidad aritmetico-logica,junto con un conjunto de registros y multiplexores que los interconectan, y que permiten suadaptacion a diversas aplicaciones. Un esquema simplificado de la estructura del DSP48epuede verse en la Figura 5.11.

Las posibilidades de configuracion y la flexibilidad que otorga la estructura del DSPSlice le hacen idoneo para el desarrollo de aplicaciones en el campo de procesado de senal[RSLVB11]. El problema es que son elementos de bajo nivel dentro de una FPGA, peroa su vez con una gran complejidad. Un disenador debe utilizar la instancia de bajo nivelde dicho componente para poder acceder a las posibilidades de configuracion que ofrece,y adaptarla a las necesidades de su aplicacion.

Para la entrada y salida, de una manera simplificada, estos componentes cuentan contres puertos de entrada: A, B y C, para la entrada de operandos a la unidad, y un puerto desalida P de donde se obtienen los resultados. En la estructura interna del componente lospuertos A y B se conectan al multiplicador integrado, bien directamente desde los propiospuertos de entrada, o bien a traves de una cascada de hasta dos registros. La salida delmultiplicador de nuevo puede ser almacenada en un registro, identificado como M.

Todas las entradas, junto con el resultado de la multiplicacion (con o sin registrar) seconectan a un banco de multiplexores que es controlado por un nuevo puerto de entrada,OPMODE, el cual definira cuales son los operandos que pasan a una segunda etapa del DSPSlice y que contiene la unidad aritmetico-logica.

La unidad aritmetico-logica esta de nuevo gobernada por otro puerto de entrada,


ALUMODE, que configura la operacion que esta realizando: suma, resta o funcion logica.Y el resultado de la operacion puede ser almacenado en un nuevo registro, P, que es el quese conecta a la salida del componente.

Puesto que los anchos de palabra de las unidades son fijos en un DSP Slice, se haprovisto de un metodo para ampliarlos: mediante la posibilidad de encadenarlos en unacascada. Esta posibilidad permite ademas la implementacion eficiente de ciertas operacio-nes y aplicaciones. Para encadenar DSP Slices de manera eficiente, el componente disponede nuevos puertos que le conectan con otro DSP Slice adyacente: ACIN, BCIN y CIN, ACOUT,BCOUT y COUT, PCIN, PCOUT, junto con todo el conjunto de logica necesaria, que permiteseleccionar cual es la entrada activa, e incluso el nivel de pipeline para las mismas.

La instancia de bajo nivel de este componente no solo presenta un numeroso conjuntode puertos de entrada-salida, como se mostro en la Figura 3.2, sino que el conjunto deparametros que lo configuran tambien es extenso y a veces complejo de configurar, como semostro en la Figura 3.1, ya que se encuentran muy relacionados con detalles de la propiaestructura interna del componente.

De modo general, los parametros de este componente se pueden clasificar en grupos:

Los parametros que configuran la entrada al componente permiten seleccionar desdesu origen (logica o DSP adyacente), hasta el nivel de pipeline.

Los parametros que configuran al multiplicador permiten incluso la posibilidad dedesconectarlo si no se utiliza (para ahorrar energıa).

El conjunto de parametros que gobiernan el banco de multiplexores entre la entra-da/multiplicador y la unidad aritmetico-logica/salida.

El conjunto de parametros que configuran la entrada a la unidad aritmetico-logicapermiten configurarla de manera estatica para que siempre realice la misma funcion,o bien poder cambiarla de manera dinamica ciclo a ciclo.

No todos los juegos de parametros son compatibles entre sı, ya que existen depen-dencias y relaciones entre ellos. Interfaz, parametros y estructura permiten configurar alcomponente para numerosas aplicaciones, pero es necesario que el disenador conozca endetalle las caracterısticas de este componente para poder aprovecharlo.

Existen aplicaciones que se pueden realizar con una unica instancia de bajo nivel deeste componente, mientras que otras aplicaciones requieren de cierta cantidad de logicaexterna, e incluso hay aplicaciones cuya implementacion requiere del interconexionado devarios de estos DSP Slices. Cada aplicacion del componente requerira de una configura-cion de parametros de la instancia que configuren la estructura, y ademas el disenadoresta obligado a conocer que puertos del componente utilizar: no todos los puertos del com-ponente se utilizan siempre, pero deben ser correctamente conectados, como por ejemplolos puertos de enable o reset. Incluso existen puertos que internamente se agregan paraformar puertos de mayor anchura dependiendo de que operacion se vaya a realizar.

En este apartado se propondran diferentes encapsulados, tanto estructurales comofuncional, para este componente, que permitan acceder a los detalles de configuracion debajo nivel, pero a su vez permitan incluir la informacion de las distintas funcionalidades quepuede ofrecer. En la Figura 5.12, ya mostrada en el capıtulo 3, se representan los diferentes


Figura 5.12: Conjunto de encapsulados y empaquetado para el DSP48E.

Figura 5.13: Ejemplos de aplicacion del DSP48E.

encapsulados que se describiran en el apartado. Un primer encapsulado estructural, juntocon la implementacion dHDL que envuelve al componente VHDL, sobre la que se definirandiferentes empaquetados que implementan los encapsulados funcionales.

5.5.1.1. Encapsulado estructural: DSP48E

A partir de una unica instancia de un DSP Slice se pueden obtener numerosas apli-caciones, simplemente jugando con los parametros y como conectar los operandos con lospuertos. Las aplicaciones mas sencillas e inmediatas son las que utilizan los componen-tes integrados de manera aislada: multiplicador, multiplexor o sumador/restador. Perotambien es posible obtener otras aplicaciones combinando estos componentes: contadores,acumuladores, suma de productos, etc. La Figura 5.13 muestra la diferente configuracionpara dos aplicaciones inmediatas: suma y multiplicacion.

Para el encapsulado estructural de un core de DSP Slice vamos a comenzar con ladeclaracion de los puertos que van a servir de interfaz. Los puertos que presenta unainstancia de bajo nivel de este componente se pueden dividir en varios grupos:


De datos.

Para la entrada de operandos y salida de resultados.

De control, para las senales de reloj o de enable.

Puesto que solo se utilizara una instancia del componente no se van a declarar lospuertos para encadenar DSPs. Ası se cumple con uno de los objetivos buscados al encap-sular cores, que es el de ocultar los detalles de implementacion que no sean utiles para lasaplicaciones seleccionadas.

El encapsulado estructural no hace referencia a una instancia de bajo nivel de estecomponente, sino que hace referencia a un core dHDL que instancia a dicho componente.Es en este core donde se instancia e interconecta de manera adecuada el DSP de bajo nivelque se corresponde con la instancia en VHDL. Este encapsulado solo utiliza los puertos deentrada y salida de datos: A, B, C y P. Esto de nuevo limita las aplicaciones para nuestrocore, ya que en esta version del encapsulado no se podra variar de manera dinamica lafuncionalidad de la etapa de multiplexado o la de la unidad aritmetico-logica.

Ejemplo 5.22 Encapsulado estructural DSP48E. Macropuertos....

<macroports>

<macroport id="DSP_A">


<type>lvi</type>



</property>

</macroport>

<macroport id="DSP_B">


<type>lvi</type>



</property>

</macroport>

<macroport id="DSP_C">


<type>lvi</type>



</property>

</macroport>

<macroport id="DSP_M">


<type>lvi</type>



</property>

</macroport>

<macroport id="DSP_P">


<type>lvo</type>



</property>

</macroport>

<net id="clock">


<mport id="DSP_A" signal="clock" />

<mport id="DSP_B" signal="clock" />

<mport id="DSP_C" signal="clock" />

<mport id="DSP_M" signal="clock" />

<mport id="DSP_P" signal="clock" />

</net>

</macroports>

...

Para la declaracion de la entrada/salida del encapsulado se han utilizado macropuertos,cuya declaracion puede observarse en el Ejemplo 5.22. Para un encapsulado tan sencillohan bastado dos tipos: LVI y LVO. Con la declaracion de cada macropuerto no solo sedeclara el puerto asociado a los datos, sino tambien todo un conjunto de senales asociadasa cada uno de estos puertos de datos, como son senales de enable y reset sıncronas.

Esta declaracion de macropuertos es ademas totalmente compatible con los puertos queofrece la instancia de bajo nivel del DSP48E. Ası por ejemplo para los puertos de entradade datos A, B y C, y el puerto de salida de resultados P de la instancia de bajo nivel, enel encapsulado se le asocian senales para el control de los registros de entrada y salida,mediante senales de enable y de reset incluidas en la propia declaracion del macropuerto.


Ademas, en el encapsulado se ha anadido un macropuerto DSP M, que permite controlarel registro M tras el multiplicador integrado. Realmente la instancia de bajo nivel no ofreceeste puerto como entrada de datos, pero sı que son utiles las senales de enable y reset quedeclara el macropuerto, para el control de dicho registro.

Los parametros que configuran el DSP48E se fijaran en la implementacion del en-capsulado que lo instancia. Puesto que se ha limitado el acceso al DSP con los puertosdeclarados, un conjunto de estos parametros estara ya fijado. Del conjunto de parametrosque restan por definir, algunos se podran declarar directamente en el encapsulado, o biense obtendran en la implementacion del core a partir de los parametros que declaremos enel encapsulado.

Ejemplo 5.23 Encapsulado estructural DSP48E. Parametros.<declaration coreid="dhdl_dsp48e"



<definitions>

<deftype id="optype">


<item>MULT</item>

<item>ADD</item>

<item>SUB</item>

<item>ADDSUB</item>

<item>CONT</item>

<item>ACC</item>

<item>MULTADD</item>

<item>MULTACC</item>

</union>

</deftype>

</definitions>

<properties>

<property id="AREG">

<type>boolean</type>

<value><vall>true</vall></value>

</property>

<property id="BREG">



</property>

<property id="CREG">



</property>

<property id="MREG">



</property>

<property id="PREG">



</property>

<property id="OPERATION">

<type>optype</type>

<value><vall>MULT</vall></value>

</property>

</properties>

...

</declaration>

La declaracion de los parametros del Ejemplo 5.23 se ha orientado a las aplicacionesdescritas anteriormente. Un parametro, OPERATION, determina la aplicacion, mientras queel resto de parametros permite habilitar o deshabilitar los diferentes registros internos delcomponente.

Durante la descripcion del encapsulado, dependiendo del valor del parametro que se-lecciona la aplicacion se fijan los parametros que controlan el banco de multiplexores yla operacion a realizar en la unidad aritmetico-logica. Ademas el valor de este parametrocontrola el interconexionado con los propios puertos de la instancia: por ejemplo, si se im-plementa la operacion de suma, se deshabilitan todos los puertos que no se utilicen pararealizar dicha aplicacion (el puerto M).

Aunque en el encapsulado se permite configurar que registros habilitar y cuales no, denuevo dependiendo del parametro que selecciona la aplicacion se incluiran solo aquellos querealmente sea necesario: si no se implementa una aplicacion que haga uso del multiplicador,no se habilitara dicho registro, aunque se configure para su uso mediante el parametroMREG.

Finalmente, el encapsulado estructural permite la declaracion de atributos para infor-mar de las caracterısticas del core. En el Ejemplo 5.24 se ha declarado un atributo que


Ejemplo 5.24 Encapsulado estructural DSP48E: Atributos.<attributes>



<type>int8</type>


</attribute>

<attributes>

permite informar de la latencia del componente, que dependera tanto de la aplicacionseleccionada como de que registros sean activados.

La utilidad del encapsulado descrito se limita a ofrecer una interfaz simplificada res-pecto a la que ofrece la instancia de bajo nivel de este componente, a costa de limitar elconjunto de aplicaciones. A pesar de ser una interfaz simplificada, aun es necesario co-nocer detalles de la implementacion del DSP48e para poder utilizarlo: como conectar losoperadores a los puertos, como parametrizarlo, etc.

Por ejemplo, si se configura para utilizarlo como multiplicador se podran activar losregistros en los puertos A, B, y los registros internos del componente M asociado a lasalida del multiplicador y P asociado a la salida del componente, que por defecto enel encapsulado mostrado en el Ejemplo 5.23 se encuentran deshabilitados. Los puertosque se podran utilizar son DSP A y DSP B para la entrada de operandos, DSP M para elcontrol del registro de salida del multiplicador, y el puerto DSP P, salida del componente.El macropuerto DSP C no se utilizara para esta configuracion. El valor del atributo delatencia podra variar entre 0 y 3 ciclos dependiendo de que registros se activen.

Si se configura el componente como sumador, se podran activar los registros de lospuertos A, B y C, y el registro interno asociado a la salida P. Para la entrada de datos, unode los operandos debe conectarse a los puertos DSP A y DSP B, mientras que el segundooperando se conectara al puerto DSP C. La salida se obtiene de nuevo desde el puertoDSP P. En este caso el puerto DSP M no se utiliza. El valor del atributo de latencia paraeste caso puede variar entre 0 y 2 ciclos.

5.5.1.2. Encapsulado funcional: DSP48E

Desde el punto de vista de un disenador que esta buscando diferentes alternativas parala implementacion de una funcion, puede resultar excesivamente costoso que para poderevaluar entre diferentes posibilidades de implementacion tenga que estudiar y conocer losdetalles de diferentes cores. Resulta mas interesante poder definir la funcion que le interesa,y sean los disenadores de cores los que establezcan como su core implementa dicha funcion.

En la propuesta realizada en esta Tesis las funciones se encuentran definidas en losencapsulados funcionales. El ejemplo que ilustra este apartado, elDSP Slice, es un elementoversatil que permite implementar multitud de funciones, como por ejemplo las recogidas enlas notas de aplicacion para este componente [Xilc]. Incluso con las limitaciones impuestascon el encapsulado estructural presentado anteriormente aun es capaz de utilizarse parala implementacion de diferentes funciones.

Mediante el encapsulado funcional se pueden describir funciones como por ejemplo lasuma, la multiplicacion, la cuenta, etc. Tomando como ejemplo la funcion suma se puededesarrollar un encapsulado funcional que describa sus caracterısticas mas basicas.


Ejemplo 5.25 Encapsulado funcional DSP48E. Suma....

<function id="add">



<version>

<ver n="1">

<rev n="0" d="2010-01-08">


</rev>

</ver>

</version>

</function>

<features>






<item>byte</item>

<item>word</item>

<item>int</item>

<item>long</item>

</union>

</version>

</feature>

...

</features>

...

La declaracion del encapsulado funcional de la suma recoge por una parte la informa-cion basica de la funcion a implementar, y por otra parte las caracterısticas. Por ejemplo,en una version basica recogida en el Ejemplo 5.25, unicamente se ha caracterizado la pre-cision con la que ha de operar la funcion: byte (8 bits), word (16 bits), int (32 bits) ylong (64 bits).

Ejemplo 5.26 Encapsulado funcional DSP48E. Multiplicacion....

<function id="mult">



<version>

<ver n="1">

<rev n="0" d="2010-01-08">


</rev>

</ver>

</version>

</function>

<features>






<item>byte</item>

<item>word</item>

<item>int</item>

<item>long</item>

</union>

</version>

</feature>

...

</features>

...

Otra funcion que puede implementar el DSP48e es la multiplicacion. Su declaracion essimilar a la suma, como se muestra en el Ejemplo 5.26, salvo que ahora se esta describiendocomponentes que implementen a multiplicadores. Ambos encapsulados, aunque similares,permiten distinguir entre diferentes funciones. Aparte de la propia declaracion de la funciony de sus caracterısticas, en el encapsulado funcional se declaran los flujos de datos de lafuncion.

En el Ejemplo 5.27 se muestra la declaracion de dos flujos de datos: input op para laentrada de datos, y output res para la salida de resultados. Esta declaracion es compatiblecon las funciones suma y multiplicacion declaradas anteriormente.

5.5.1.3. Empaquetado

En el apartado anterior se han descrito dos encapsulados funcionales muy similares(mismas caracterısticas y flujos) pero que describen diferentes funciones (suma y multi-


Ejemplo 5.27 Flujo de datos para las funciones suma y multiplicacion....

<flows>

<flow id="input_op">




<dt>

<mean>1.0</mean>

<peak>0.0</peak>

</dt>

<op>

<opid id="op_a" type="int8"/>

<opid id="op_b" type="int8"/>

</op>

</version>

</flow>

<flow id="output_res">




<dt>

<mean>1.0</mean>

<peak>0.0</peak>

</dt>

<op>

<opid id="res" type="int8"/>

</op>

</version>

</flow>

</flows>

...

plicacion). Ambas funciones se pueden implementar utilizando el encapsulado estructuraldel DSP48E, pero con diferentes parametros e interconexionado. El empaquetado permiteenlazar ambos encapsulados, generando segun la funcion una configuracion e intercone-xionado diferente y verificando que la implementacion obtenida cumple con los requisitosde la funcion.

Continuando con el ejemplo anterior, antes de definir como el encapsulado estructuralimplementa la funcion suma es necesario saber como el propio DSP se ha de configurarpara implementarla. Para esta aplicacion no se utiliza el multiplicador integrado en elcomponente ni el registro M asociado. Se ha de configurar el banco de multiplexores paraque un operando se tome desde los puertos A:B, mientras que el segundo operando setome desde el puerto C. Se ha de configurar la unidad aritmetico-logica como sumador.El registro de salida, P, se utiliza para guardar el resultado de la suma. Debido a laslimitaciones del componente tanto los operandos como los resultados se limitan a 48 bits.

Ejemplo 5.28 Empaquetado de la funcion suma mediante DSP48e....

<function>

<core id="dhdl_dsp48e" />

<proto library="logic"

id="add" version="1.0" />

</function>

<configuration>

<parameter id="AREG">


</parameter>

<parameter id="BREG">


</parameter>

<parameter id="CREG">


</parameter>

<parameter id="MREG">

<value><vall>false</vall></value>

</parameter>

<parameter id="PREG">


</parameter>

<parameter id="OPERATION">

<value><vall>ADD</vall></value>

</parameter>

</configurtation>

<verification>



<valf id="equal">

<value><vall></vall></value>

</valf>

</value>

</feature>

</verification>

...

En el Ejemplo 5.28 se muestra como se ha empaquetado el core para realizar su funcionsuma (Ejemplo 5.25). En una primera parte de configuracion, con el encapsulado estructu-ral propuesto basta con seleccionar la aplicacion mediante su correspondiente parametro,OPERATION, que permite generar el control del banco de multiplexores y la operacion a


realizar con la unidad aritmetico-logica. Debido a las limitaciones del propio componente,que trabaja con anchos de palabra de 48 bits, permite que se implemente la funcion sumasalvo si se requiere una precision de long.

Ejemplo 5.29 Empaquetado de la funcion multiplicacion mediante DSP48e....

<function>

<core id="dhdl_dsp48e" />

<proto parent="logic"

id="mult" version="1.0" />

</function>

<configuration>

<parameter id="AREG">


</parameter>

<parameter id="BREG">


</parameter>

<parameter id="CREG">


</parameter>

<parameter id="MREG">


</parameter>

<parameter id="PREG">


</parameter>

<parameter id="OPERATION">

<value><vall>MULT</vall></value>

</parameter>

</configurtation>

<verification>



<valf id="equal">

<value><vall></vall></value>

</valf>

</value>

</feature>

</verification>

...

En el Ejemplo 5.29 se muestra como se ha empaquetado el DSP para implementar lafuncion multiplicacion: hace uso del multiplicador integrado, y los operandos se introducenpor los puertos A, en este caso con un ancho de palabra de 24 bits, y B que limita elancho de palabra de este operando a 18 bits. Puesto que en la declaracion de la funcionmultiplicacion (Ejemplo 5.26) no se habla de anchos de palabra de los operandos, sino dela precision de la operacion, este componente se podra comportar como implementacionde la funcion hasta precisiones de word (16 bits).

Durante el ejemplo del apartado se ha mostrado como realizar un encapsulado estruc-tural sencillo y orientado a un conjunto de aplicaciones concretas, para un componente debajo nivel con un elevado numero de parametros y puertos que resultan innecesarios paranumerosas aplicaciones. Tambien se han definido dos encapsulados funcionales sencillos,pero que representan dos funciones distintas: la suma y la multiplicacion. Para implementarcada una de las funciones anteriores el componente no solo requiere de una configuraciondistinta sino tambien requiere de un interconexionado de sus puertos distinto, tarea quese realiza a la hora de definir como se empaqueta al componente.

5.5.2. Filtros FIR

Los filtros son una herramienta basica en el procesado digital de senales. Los tipos defiltros digitales mas conocidos son los FIR (Finite Impulse Response) y los IIR (InfiniteImpulse Response) [SP94]. Mientras que la salida de un filtro FIR unicamente depende dela entrada en instantes anteriores, la de un filtro IIR depende de la entrada en instantesanteriores pero tambien de la salida en instantes anteriores.

Para la implementacion de un filtro FIR existen diversas alternativas y estructuras:implementacion directa, traspuesta, en cascada, ... Una caracterıstica de todas estas alter-nativas son los elementos basicos que son necesarios para su implementacion: sumadores,multiplicadores y registros. Estos elementos se pueden componer e interconectar para for-


Figura 5.14: Esquema tap para FIR direct y transposed.

Figura 5.15: Esquema FIR segundo orden con etapa directa y transpuesta.

mar una etapa basica (orden 1), con la que generar un filtro de orden superior (ordenN). En la Figura 5.14 se pueden observar dos esquemas distintos para la implementacionde una etapa basica del filtro. En la Figura 5.15 se ilustra como utilizar la etapa basicaanterior para construir filtros de orden superior (orden 2).

En la estructura directa el primer elemento en cada etapa basica es el registro, queluego se multiplica por el valor del coeficiente del filtro y se suma con todos los productosde la cadena de etapas basicas que formen el filtro. A simple vista se puede observaruno de los problemas que puede presentar esta implementacion: a medida que aumente elorden del filtro, la cadena de sumas de productos aumenta y dado que forma un caminocombinacional presentara problemas de camino crıtico.

La estructura traspuesta registra el producto de sumas en cada etapa, con lo que desdeel punto de vista hardware resultara mas eficiente a la hora de obtener una implemen-tacion mas eficaz. De hecho, una de las aplicaciones de los DSP48e vistos en 5.5.1 es laimplementacion de filtros FIR mediante una estructura traspuesta.


library ieee;


entity fir_tap_direct is

generic (

IS_LAST : Integer := 0;

WIDTH : Integer := 8;

F_B : Integer := 1 );

port (

Clock : in std_logic;

nReset : in std_logic;

Enable : in std_logic;

ZIn : in std_logic_vector(WIDTH-1 downto 0);

ZOut : out std_logic_vector(WIDTH-1 downto 0);

XHIn : in std_logic_vector(WIDTH-1 downto 0);

XHOut : out std_logic_vector(WIDTH-1 downto 0) );

architecture arch of fir_tap_direct is

begin

if IS_LAST = 1 then generate

signal zh : std_logic_vector(2*WIDTH-1 downto 0);

begin

ZOut <= ( others => ’0’ );

zh <= ZIn * Conv_Std_Logic_Vector(F_B, WIDTH);

XHout <= zh(2*WIDTH-1 downto WIDTH);

end generate;

if IS_LAST = 0 then generate

signal zh : std_logic_vector(2*WIDTH-1 downto 0);

begin

process(nRst, Clock)

begin

if ( nRst=’0’ ) then

ZOut <= ( others => ’0’);

elsif (Clock’event AND Clock=’1’ ) then

if ( Enable=’1’ ) then

ZOut <= ZIn;

end if;

end if;

end process;

zh <= ZIn * Conv_Std_Logic_Vector(F_B, WIDTH);

XHout <= zh(2*WIDTH-1 downto WIDTH) + XHin;

end generate;

end arch;

Figura 5.16: VHDL: Implementacion VHDL de etapa FIR directa.

library ieee;


entity fir_direct_2nd_order is

generic (

WIDTH : Integer := 8;

S1 : Integer := 1;

S2 : Integer := 1;

B1 : Integer := 1;

B2 : Integer := 1;

B3 : Integer := 1 );

port (

Clock : in std_logic;

nReset : in std_logic;

Enable : in std_logic;

X : in std_logic_vector(WIDTH-1 downto 0);

Y : out std_logic_vector(WIDTH-1 downto 0) );

architecture arch of fir_direct_2nd_order is

signal xs, ys : std_logic_vector(2*WIDTH-1 downto 0);

signal xsw, ysw : std_logic_vector((WIDTH-1 downto 0);

signal x1, x2 : std_logic_vector(WIDTH-1 downto 0);

signal y0, y1, y2 : std_logic_vector(WIDTH-1 downto 0);

begin

xs <= X * Conv_Std_Logic_Vector(S1, WIDTH);

ys <= y0 * Conv_Std_Logic_Vector(S2, WIDTH);

xsw <= xs(2*WIDTH-1 downto WIDTH);

ysw <= ys(2*WIDTH-1 downto WIDTH);

Y <= ysw;

fir_tap_0 : entity work.fir_tap_direct

generic map ( WIDTH => WIDTH; F_B => B1; IS_LAST => 0),

port map ( Clock => Clock,

nReset => nReset, Enable => Enable,

Zin => xsw, Zout => x1, XHIn => y1, XHOut => y0 );





Zin => x1, Zout => x2, XHIn => y2, XHOut => y1 );





Zin => x2, Zout => open, XHIn => open, XHOut => y2 );

end arch;

Figura 5.17: VHDL: Implementacion FIR segundo orden.

En la Figura 5.16 se muestra el codigo VHDL para la implementacion de una etapabasica en una estructura directa. El componente permite parametrizar el ancho de bitde las muestras y el valor del coeficiente para la etapa del filtro. Un parametro permiteadaptar el componente en el caso de ser la ultima etapa del filtro.

El componente de la Figura 5.16 puede instanciarse para generar un filtro de ordenmayor, como el que se muestra en el codigo de la Figura 5.17, donde se utiliza para generarun filtro de segundo orden. En este caso se han de declarar mediante genericos de VHDL(parametros) los coeficientes de cada una de las etapas del filtro y de nuevo el ancho debit es uno de los parametros del componente. Para generar el filtro se ha utilizado unacadena, donde se instancia a los componentes de la estructura directa de la Figura 5.15.


5.5.2.1. Encapsulado funcional: FIR

La implementacion de un filtro FIR permite multiples alternativas: parametros dediseno (frecuencias de la banda de paso y banda atenuada, atenuacion, etc.), estructura(directa, traspuesta, etc.), e incluso diferentes arquitecturas. La propia funcion de filtroFIR permite clasificarlos entre filtros paso bajo, paso alto, etc. Implementar un unicocomponente que mediante sus parametros permita describir todas estas alternativas nosolo puede resultar ineficiente, sino incluso imposible.

El encapsulado funcional permite realizar una descripcion generica de la funcion queayude a la seleccion de las implementaciones que mas se acerquen o adapten a los requisitosde la aplicacion. Para la funcion FIR, el Ejemplo 5.30 muestra una primera version deencapsulado funcional. El objetivo de esta primera version es centrarse en los parametrosde diseno de un filtro (banda de paso, banda eliminada, atenuacion y rizado), ademas decaracterısticas que permitan discriminar implementaciones por tipo de aritmetica (puntofijo o flotante).

Ejemplo 5.30 Encapsulado funcional FIR. Suma....

<function id="fir">


<parent>dsp</parent>

<version>

<ver n="1">

<rev n="0" d="2010-01-08">


</rev>

</ver>

</version>

</function>

<features>






<item>byte</item>

<item>word</item>

<item>int</item>

<item>long</item>

<item>float</item>

<item>double</item>

</union>

</version>

</feature>

<feature id="bpass_l">




<type>float</type>

</version>

</feature>

<feature id="bpass_h">




<type>float</type>

</version>

</feature>

<feature id="ripple">




<type>float</type>

</version>

</feature>

<feature id="attenuation">




<type>float</type>

</version>

</feature>

</features>

...

El Ejemplo 5.30 define como caracterısticas del filtro las frecuencias de la banda depaso bpass l y bpass h, lo que permite de manera indirecta clasificar las implementacionescomo paso bajo, alto o pasobanda:

bpass l=0.0 y bpass h>0.0 Definira un filtro paso bajo.

bpass l<0.5 y bpass h=0.5 Definira un filtro paso alto.

bpass l>0.0 y bpass h<0.5 Definira un filtro paso banda.


Otras caracterısticas como la atenuacion o el rizado proporcionan una especificaciondel filtro con la que utilizar metodos de diseno para especificar los coeficientes o constantes(metodo de las ventanas, mınimos cuadrados, ...).

Ejemplo 5.31 Flujo de datos para la funcion FIR....

<flows>

<flow id="idata">




<dt>

<mean>1.0</mean>

<peak>0.0</peak>

</dt>

<op>

<opid id="i_fir" type="int8"/>

</op>

</version>

</flow>

<flow id="odata">




<dt>

<mean>1.0</mean>

<peak>0.0</peak>

</dt>

<op>

<opid id="o_fir" type="int8"/>

</op>

</version>

</flow>

</flows>

...

En el Ejemplo 5.31 se han declarado dos flujos de datos para la funcion filtro, idata quesuministrara los datos de entrada de la funcion, y odata de donde se recogeran los datos desalida. Frente a declaracion de la funcion y caracterısticas, los flujos del ejemplo permitenincorporar nuevas restricciones a la hora de clasificar y seleccionar implementaciones:anchura de bit de operandos y operadores, arquitectura, throughput, . . . Todo un conjuntode detalles de bajo nivel de implementacion quedan ocultos, puesto que desde el puntode vista de la funcion solo interesa si la implementacion tiene la capacidad de procesar(filtrar) en un tiempo acotado.

5.5.2.2. Encapsulado estructural: FIR

La Figura 5.17 muestra el codigo VHDL que describe un FIR de segundo orden me-diante una estructura directa. Los parametros para esta implementacion se dividen en laanchura de datos (WIDTH) y coeficientes del filtro (B1, B2, . . . ). La estructura que describeel filtro se podrıa generalizar para realizar un filtro de orden superior, pero esta generali-zacion requerira de la declaracion de nuevos parametros (por ejemplo el orden del filtro ylos nuevos coeficientes).

El problema de una implementacion como la de la Figura 5.17 es que los parametrosse encuentran muy ligados a la propia estructura: los coeficientes no son mas que lasconstantes de las multiplicaciones y el orden el numero de etapas con las que se implementael filtro. Es necesario informar al usuario del core de como ha de inicializar estos parametrospara obtener la funcion del filtro deseada, por ejemplo mediante un programa o funcionexterna que a partir de parametros de diseno del filtro (como los vistos en el encapsuladofuncional) genere el valor de los coeficientes.

Las posibilidades de generalizacion y de reutilizacion del componente se pueden mejorarsi en lugar de ofrecer parametros de tan bajo nivel, se genera un encapsulado capaz deincluir en la propia implementacion un metodo para el calculo de los coeficientes del filtro.El encapsulado estructural permite la configuracion de un core dHDL, que genera demanera dinamica la estructura del filtro (directa o traspuesta). El calculo de los coeficientesdel filtro se realiza de manera dinamica a partir de los parametros de configuracion del


encapsulado estructural. El Ejemplo 5.32 muestra estos parametros en el encapsuladoestructural.

Ejemplo 5.32 Encapsulado estructural FIR. Parametros.<declaration coreid="dhdl_fir" ...">

<deftype id="archtype">


<item>direct</item>

<item>transposed</item>

</union>

</deftype>

<properties>

<property id="ARCH">

<type>archtype</type>

<value><vall>transposed</vall></value>

</property>

<property id="WIDTH">



</property>

<property id="ORDER">



</property>

<property id="BPASS">

<type>float</type>


</property>

</properties>

...

</declaration>

El Ejemplo 5.32 permite seleccionar con un parametro, ARCH, si se implementara laestructura directa o traspuesta, el parametro WIDTH en ancho de bit de datos, y con losparametros ORDER y BPASS disenar los coeficientes para el filtro (limitado a filtros pasobajo).

Los atributos del encapsulado estructural permiten informar de caracterısticas del filtroimplementado. En el Ejemplo 5.33 se muestra como es posible informar de detalles comola latencia, la frecuencia de la banda atenuada, BSTOP, y la atenuacion, ATT. Estos dosultimos atributos dependeran de los parametros de diseno del filtro.

Ejemplo 5.33 Encapsulado estructural FIR. Atributos.<attributes>

<attribute id="LATENCY">



</attribute>

<attribute id="BSTOP">

<type>float</type>


</attribute>

<attribute id="ATT">

<type>float</type>


</attribute>

</attributes>

...

</declaration>

Finalmente, la declaracion de los macropuertos del FIR se realiza en el Ejemplo 5.34.Un macropuerto, FIR I, define la entrada de datos, y otro macropuerto, FIR O, la salida.

Ejemplo 5.34 Encapsulado estructural FIR. Macropuertos....

<macroports>

<macroport id="FIR_I">


<type>lvi</type>



</property>

</macroport>

<macroport id="FIR_O">


<type>lvo</type>



</property>

</macroport>

<net id="clock">




</net>

</macroports>

...


5.5.2.3. Empaquetado

El encapsulado estructural del FIR descrito en el apartado 5.5.2.2 no pueden cumplircon todos los posibles valores para las caracterısticas descritas en el apartado 5.5.2.1. Elempaquetado permite obtener una configuracion de sus parametros, y a la vez verificarcuales de las caracterısticas se cumplen para ese juego de parametros. En el Ejemplo 5.35se muestra la implementacion de este empaquetado.

Ejemplo 5.35 Emapaquetado de la funcion FIR....

<function>

<core id="dhdl_fir" />

<proto parent="dsp" id="fir" version="1.0" />

</function>

<configuration>

<parameter id="ARCH">

<value><vall>transposed</vall></value>

</parameter>


<value><valf id="dec2bit">

<value>

<vall from="features"/>precision<vall/>

<value/>

</valf>

</value>

</parameter>

<parameter id="ORDER">

<value>

<valf id="calc_order">

<value>

<vall from="features"/>bpass_h<vall/>

<vall from="features"/>ripple<vall/>

<vall from="features"/>attenuation<vall/>

<value/>

</valf>

</value>

</parameter>

<parameter id="BPASS">

<value><valf id="dec2bit"><value>

<vall from="features"/>bpass_h<vall/>

<value/></valf></value>

</parameter>

</configuratation>

<verification>



<valf id="equal">

<value><vall>byte</vall></value>

<value><vall>word</vall></value>

<value><vall>int</vall></value>

<value><vall>long</vall></value>

</valf>

</value>

</feature>

<feature id="bpass_l">


<valf id="equal">


</valf>

</value>

</feature>

<feature id="bpass_h">

<value default="true">

</value>

</feature>

<feature id="ripple">


<vall from="features"/>ATT<vall/>

</value>

</feature>

<feature id="attenuation">


<vall from="features"/>ATT<vall/>

</value>

</feature>

</verification>

...

En una primera parte se configuran los parametros del filtro mediante funciones quetoman como argumento caracterısticas del encapsulado funcional: la anchura de los datosa partir de la caracterıstica de precision. Para el orden del filtro es necesario hacer unallamada a funcion que determine el orden en funcion de las caracterısticas de diseno delfiltro.

La segunda parte permite verificar las caracterısticas que cumple la implementacion: laprecision solo en caso que se utilice aritmetica entera. Puesto que el encapsulado estructuralsolo implementa filtros paso bajo, solo verificara bpass l=0.0. Los valores de la bandaatenuada, el rizado y la atenuacion se obtienen a partir de los atributos definidos en elencapsulado estructural.

Frente a las caracterısticas que un ingeniero de sistema busca a la hora de seleccionarun filtro, implementaciones utilizando los HDL clasicos ofrecen parametros que ayudana describir la estructura e inicializar operadores. El encapsulado estructural, junto con

5.6 Conclusiones 111

lenguajes que mejoren la propia descripcion estructural como dHDL, mejoran la informa-cion de interfaz permitiendo definir parametros orientados al diseno del filtro, ademas deincorporar informacion de la propia implementacion.

5.6. Conclusiones

En este capıtulo se han presentado dos encapsulados para reutilizar cores hardware.En primer lugar se ha definido el encapsulado estructural que implementa la interfaz dellenguaje dHDL descrito en el capıtulo 4. El encapsulado estructural esta ligado a unaimplementacion concreta y se ha pensado para mejorar la informacion ofrecida por la pro-pia implementacion. En segundo lugar se ha definido un encapsulado funcional orientadodefinir caracterısticas que pueden ser implementadas en multiples disenos, y sin que seencuentre ligado a ninguna implementacion concreta.

El encapsulado estructural define los parametros que configuran a un core, similares alos de otros HDLs, y tambien incorpora los atributos con los que obtener informacion dela implementacion. Para la entrada-salida define macropuertos, que agregan en una unicadeclaracion a todo un conjunto de puertos convencionales orientados a implementar unafuncion.

Frente a la interfaz de los lenguajes convencionales, este encapsulado estructural au-menta la cantidad de informacion que el disenador puede incorporar junto con la propiaimplementacion. Esta informacion mejora las posibilidades de reutilizacion del propio com-ponente, ya que puede ofrecerse a otro disenador que quiera utilizar el core, o incorporarsea herramientas que integren el diseno como parte de un sistema.

El encapsulado funcional permite declarar caracterısticas que describen una funcion. Adiferencia de los parametros definidos para configurar un core, las caracterısticas ayudana establecer restricciones a cumplir por el diseno para convertirse en una implementaciondel encapsulado. Las caracterısticas del encapsulado funcional, al no estar ligadas a ningundiseno concreto describen los aspectos mas relevantes para que la implementacion cumplala funcion, de modo que se pueden implementar desde encapsulados funcionales totalmentegenericos que simplemente permitan clasificar entre implementaciones, hasta encapsuladosfuncionales tan detallados que describan una implementacion concreta.

Un core dHDL se define con un unico encapsulado estructural, pero el diseno puedeadaptarse para cumplir varios encapsulados funcionales. Es en el empaquetado del coredonde el disenador establece como configurar los parametros del encapsulado estructurala partir de las caracterısticas del funcional, y a partir del core configurado verificar sirealmente se cumple con todas los requisitos declarados en el encapsulado funcional. Denuevo, el empaquetado permite al disenador describir aspectos de la implementacion quede otra manera pueden quedar ocultos, por ejemplo aplicaciones laterales del diseno.

Capıtulo 6

Ejemplo de especificacion paraprocesado de senal: FFT

6.1. Introduccion

En este capıtulo utilizara el algoritmo de la transformada rapida de Fourier (FFT) comoejemplo para ilustrar la utilidad del lenguaje de generacion presentado en el capıtulo 4,utilizado para realizar la descripcion de la implementacion de los diferentes modulos, y delencapsulado estructural presentado en el capıtulo 5.

Este ejemplo se ha elegido por multiples motivos:

Es un algoritmo tradicional dentro del campo de procesado de senal.

De utilidad en multiples aplicaciones de procesado de senal.

Su implementacion presenta una elevada complejidad.

La aplicacion final guıa la eleccion de la implementacion. Aplicaciones de altas pres-taciones como radar:

• Restricciones de tiempo real duro: procesado continuo sobre un flujo de mues-tras de entrada.

• Requieren procesado del orden de gigamuestras por segundo, que solo disposi-tivos como FPGAs pueden alcanzar.

La FFT es un algoritmo clave dentro del procesado digital de senal, y que permitecalcular de manera eficiente la transformada de Fourier, reduciendo su complejidad deO(n2) a O(n log n). A pesar de esta reduccion de complejidad, este algoritmo sigue re-quiriendo un elevado coste computacional, por lo que se buscan implementaciones lo maseficientes posible, que minimicen el gasto de recursos (memoria, tiempo de computacion,...) y maximicen las prestaciones.

Los algoritmos FFT se basan en la descomposicion de la transformada completa enotras mas sencillas, que a su vez se vuelven a descomponer hasta alcanzar transformadasde mınimo orden (en general dos elementos). Entre estos algoritmos, el mas comun es

114 Ejemplo de especificacion para procesado de senal: FFT

el Cooley-Tukey, que permite realizar transformadas de longitud potencia de 2, aunquepueden encontrarse otras alternativas.

A la hora de realizar una implementacion hardware de la FFT, la eleccion del algoritmoque lo implementa es una primera etapa. A la hora de disenar y elegir una arquitecturaFFT es importante poder evaluar que punto del espacio de diseno, por ejemplo area-prestaciones, va a requerir la aplicacion. Ası, diferentes arquitecturas proporcionan puntosdiferentes en el espacio de diseno, y es la propia aplicacion la que impone sus propiasrestricciones a la hora de elegir entre diferentes arquitecturas.

Por ejemplo, existen aplicaciones que requieren el procesado puntual de secuencias,frente a aplicaciones que deberan realizar el procesado de manera periodica. Dentro deeste ultimo conjunto, podemos encontrar aplicaciones donde la llegada de secuencias demuestras se realiza de manera discontinua, pero tambien podemos encontrar aplicacionesque requieren que el procesado se realice sobre un flujo de muestras de entrada continuo.El primer conjunto de aplicaciones normalmente demandara de implementaciones queminimizan el impacto en area, frente a implementaciones orientadas a cubrir el segundoconjunto de aplicaciones, donde cada vez toma una mayor importancia las prestacionesofrecidas por la implementacion.

En este capıtulo nos centraremos en implementaciones orientadas a este ultimo conjun-to de aplicaciones, que normalmente requieren que el procesado se realice en tiempo real:la arquitectura tiene que ser capaz de encadenar el procesado de secuencias de muestrasde manera consecutiva y ademas realizarlo en un tiempo limitado, de modo que a medidaque los requisitos se hacen cada vez mas estrictos solo implementaciones hardware van aser capaces de cumplirlos.

Fijados el algoritmo y la aplicacion, la implementacion de diferentes alternativas re-quiere de un alto coste tanto en tiempo de diseno como en verificacion. En este capıtulose propondran dos arquitecturas que implementan el algoritmo FFT para aplicaciones conrestricciones de procesado en tiempo real y de altas prestaciones.

Utilizar dHDL en la especificacion de ambas arquitecturas permite simplificar su im-plementacion: ambas arquitecturas pueden descomponerse en un diseno jerarquico, dondelos componentes de mas bajo nivel, como unidades logicas o aritmeticas se encuentranimplementadas dentro de una biblioteca de componentes. Los diferentes modulos de pro-cesado que componen las arquitecturas pueden construirse a partir de estos componentesde biblioteca, y junto con las posibilidades de parametrizacion que ofrece dHDL, incluirlas peculiaridades necesarias para adaptarlos a las arquitecturas a implementar. Los com-ponentes implementados se incorporan a la biblioteca, y por lo tanto son reutilizados porambas arquitecturas.

El objetivo del capıtulo no es solo mostrar como se implementan las arquitecturascon dHDL, sino ademas realizar implementaciones altamente parametrizables. Entre losparametros que se incluirıan los hay que permitiran modificar caracterısticas del algorit-mo, por ejemplo su longitud, y tambien hay parametros que configuran caracterısticasde la propia implementacion e incluso permiten adaptar la arquitectura a los recursosdisponibles en la plataforma de implementacion.

Las posibilidades de configuracion de las arquitecturas permiten generar un conjuntode implementaciones, y realizar un estudio de la influencia de cambios en la estructuray en los componentes de procesado, y valorar su influencia en el espacio de diseno (area-

6.2 Fundamentos de la FFT 115

prestaciones). Ademas, puesto que las arquitecturas elegidas se implementan en base a losmismos componentes de biblioteca, es posible realizar una comparativa entre arquitecturascuando se configuran con el mismo conjunto de parametros.

En el capıtulo, primero se realizara una descripcion del algoritmo FFT indicandoque elementos de procesado se van a necesitar, para posteriormente analizar las arqui-tecturas a implementar. Despues se detallara la descripcion en dHDL de los principalesmodulos de ambas arquitecturas, y finalmente se realizara el estudio de las arquitecturaspropuestas.

6.2. Fundamentos de la FFT

6.2.1. Algoritmo

Antes de pasar a describir las arquitecturas que serviran de ejemplo en el capıtulo,revisaremos las principales ecuaciones que definen la transformada Discreta de Fourier(DFT), y como se corresponden con los diferentes elementos hardware. Una transformadade N-puntos XN (k) se define a partir de una secuencia xN (n) como:

XN (k) =

N−1∑n=0

xN (n) ·W−nkN (6.1)

con n = 0, ..., N − 1 y k = 0, 1, ..., N − 1.

La FFT se basa en la descomposicion de la secuencia DFT en secuencias de menororden, lo que permite una reduccion del numero de operaciones de O(n2) a O(n log n).Existen diferentes algoritmos para el calculo de la FFT, aunque uno de los mas extendidoses el algoritmo Cooley-Tukey [CLW67]. Este algoritmo se basa en la sucesiva descomposi-cion de una DFT de longitud N , en R DFTs de longitud N/R. R, que se designara comoradix, es una potencia de 2, y por lo tanto la longitud de la transformada se encontrara res-tringida a un conjunto discreto de valores, verificandose N = RS , donde S se correspondecon el numero de etapas en que se descompone la transformada. La descomposicion con-tinua hasta que la longitud de la ultima secuencia se corresponde con el radix (sub-DFTde menor orden).

En la Figura 6.1 se muestra el esquema de operaciones para la realizacion de una FFTde 16 puntos. En el esquema se puede observar como son necesarias cuatro etapas deprocesado para alcanzar la salida.

El algoritmo Cooley-Tukey permite realizar la descomposicion de la FFT de dos mane-ras diferentes: diezmado en el tiempo (DIT) y diezmado en frecuencia (DIF). La diferenciaentre ambas descomposiciones es la forma en que el algoritmo ordena la secuencia de ope-raciones. Por ejemplo, para una descomposicion con un radix 2, el algoritmo descomponela secuencia de longitud N , en dos secuencias de longitud de orden N/2, pero mientras queen la implementacion DIT las secuencias se corresponden con muestras pares e impares,la implementacion DIF forma una secuencia con la primera mitad de las muestras y otrasecuencia con la segunda mitad de las muestras.

El analisis es parecido para ambas descomposiciones, por lo que nos centraremos en la


Figura 6.1: Esquema FFT de 16 puntos.

implementacion DIF con radix 2. Partiendo de la Ecuacion 6.1, la secuencia de longitudN se descompone en dos secuencias de longitud N/2:

XN (2k′) =

N/2−1∑n=0

[[xN (n) + xN (n+N/2)] · T 0N (n)] ·W−k′n

N/2

=

N/2−1∑n=0

x0N/2(n) ·W−k′nN/2

(6.2)

XN (2k′ + 1) =

N/2−1∑n=0

[[xN (n)− xN (n+N/2)] · T 1N (n)] ·W−k′n

N/2

=

N/2−1∑n=0

x1N/2(n) ·W−k′nN/2

(6.3)

con k′ = 0, 1, ...N/2 − 1. En las Ecuaciones 6.2 y 6.3, tras la suma/resta de muestras enlos corchetes mas interiores (mezcla de muestras), se multiplican por los terminos Tm

N (n),que se denominan twiddle terms y que se definen como:

TmN (n) = exp

−j2πm

N· n (6.4)

con m = 0, ...(R− 1). De las ecuaciones anteriores se pueden extraer algunas conclusionesrelevantes desde el punto de vista de la implementacion hardware:

Aunque la secuencia de entrada sea de muestras reales, todas las operaciones y lasalida seran numeros del campo complejo.


En las Ecuaciones 6.2 y 6.3, dentro de los corchetes mas internos, se realiza la mezclaentre las muestras de entrada, mediante una suma y una resta compleja, que en elcaso de radix-2 es:

xN (n) + xN (n+N/2)

xN (n)− xN (n+N/2)

Esta funcion se implementa mediante una estructura denominada mariposa y es unode los modulos que vamos a encontrar en las arquitecturas a describir. Cuando seimplemente, al componente se le designara como butterfly.

Tras la mezcla de muestras se realiza la multiplicacion por el conjunto de twiddlescorrespondiente. Como se puede observar en la definicion que se hace de estos termi-nos se corresponde con una rotacion en la circunferencia unidad. Este es otro de losmodulos que vamos a encontrar en la implementacion de la arquitectura.

Tras la mezcla y rotacion de las muestras se obtienen dos secuencias de la mitadde longitud. Sobre cada una de estas secuencias se ha de repetir el proceso hastaalcanzar la transformada de menor orden, en este caso 2.

Las muestras con las que se opera normalmente estan separadas N/2 temporalmente(n y n+N/2). Puesto que las muestras se reciben y se procesan formando un flujo, esnecesario un modulo que permita almacenar las muestras hasta que puedan operarse.

En este apartado se ha descrito la descomposicion de la FFT utilizando el algoritmoCooley-Tukey e identificado desde el punto de vista de implementacion cuales van a serlos principales modulos a implementar: mariposa para la mezcla de muestras, rotadores determinos twiddle y finalmente una estructura de memoria requerida para el almacenamien-to temporal. La implementacion completa del algoritmo requerira de un conjunto variablede los modulos de calculo y almacenamiento, realizando sucesivas descomposiciones hastaalcanzar la transformada de menor orden.

Aunque se ha fijado el algoritmo de descomposicion a implementar, aun es posibleseleccionar entre diferentes arquitecturas que representen diferentes puntos en el espaciode diseno. Dentro del conjunto de posibles arquitecturas nos centraremos en implementardos arquitecturas basicas orientadas a obtener altas prestaciones.

6.2.2. Arquitecturas

La implementacion del algoritmo utilizando tanto la descomposicion DIT como la des-composicion DIF presenta multiples alternativas. En nuestro caso nos centraremos en apli-caciones orientadas a un flujo continuo de muestras, ya que es habitual en estas aplicacio-nes imponer restricciones duras de tiempo real. Estas aplicaciones requieren arquitecturascapaces de ofrecer altas prestaciones aun a costa de un gasto excesivo en area.

Las implementaciones que mejor se adaptan a estos requisitos son arquitecturas queencadenan en diferentes etapas (S ) la descomposicion del algoritmo, y ademas con un altogrado de pipeline. A pesar de ser arquitecturas orientadas a altas prestaciones, podemos


Figura 6.2: Arquitecturas para procesado continuo: descomposicion en etapas.

Figura 6.3: Estructura de una etapa para procesado continuo.

encontrar dos arquitecturas basicas que se encuentran en puntos opuestos del espacio dediseno area-prestaciones: arquitecturas en feedback (FB) y arquitecturas feedforward (FF).

La arquitectura FB es capaz de recibir y presentar el flujo de salida a la frecuenciade reloj, a una muestra por ciclo de reloj. La arquitectura FF permite obtener un mayorthroughput gracias a procesar muestras de manera paralela, en concreto R muestras porciclo de reloj (R se corresponde con el radix de la mariposa).

A pesar de las diferencias entre ambas arquitecturas, se pueden encontrar semejanzasen el diseno del pipeline, en concreto se pueden encontrar tres niveles de pipeline:

Entre las diferentes etapas en las que se descompone la transformada completa.

Entre los diferentes modulos de procesado y almacenamiento que componen cadaetapa.

Dentro de los componentes que forman cada uno de estos modulos.

En la Figura 6.2 se puede observar como se descompone el algoritmo en un conjuntode etapas encadenadas, y que se corresponde con el primer nivel de pipeline. Tanto laarquitectura FB como la arquitectura FF presentan una descomposicion identica.

En cada etapa vamos a encontrar tres modulos, que a su vez forman el segundo nivelde pipeline, mariposa, rotador y memoria para almacenar muestras entre cada etapa. Enla Figura 6.3 se muestra la estructura comun de una etapa tanto para la arquitecturaFB como para la arquitectura FF: las muestras que entran a la etapa se almacenan en elmodulo de memoria, que a su vez se conecta con el modulo butterfly. La salida del modulobutterfly se conecta al modulo rotador, aunque en la arquitectura FB parte de las muestrasse realimentan de nuevo a la memoria. Tras procesarse las muestras en el modulo rotador,estas pueden pasar a la siguiente etapa de la implementacion.

En lo que queda de apartado se describiran los modulos de procesado (butterfly y rota-dor), y los modulos de almacenamiento (memoria) requeridos para implementar cada una


de las etapas en la descomposicion del algoritmo. Mientras que los modulos de procesa-do son muy similares para ambas arquitecturas a implementar, la implementacion de losmodulos de almacenamiento y la interconexion de los modulos realizada dentro de cadaetapa son caracterısticas de cada arquitectura.

Por ello, primero se describiran los modulos de procesado, y posteriormente se des-cribiran las arquitecturas basicas, primero la arquitectura FB y posteriormente la FF,incluyendo los detalles de la estructura de memoria requerida en cada etapa, su intercone-xion con los modulos de procesado y el modo de funcionamiento de la propia arquitectura.

6.2.2.1. Mariposa

La mariposa es el primer modulo de procesado presente en cada etapa de descompo-sicion del algoritmo. Se corresponde con la DFT de orden mınimo a calcular, se obtienesustituyendo en la Ecuacion 6.1 con N = 2:

X2(k) =

1∑n=0

x2(n) ·W−nk2

X2(0) =

1∑n=0

x2(n) ·W−n·02 = x2(0) + x2(1)

X2(1) =

1∑n=0

x2(n) ·W−n·12 = x2(0)− x2(1)

(6.5)

La mariposa de radix-2 requiere unicamente de dos elementos: un sumador y un res-tador complejos, ya que ambos operan muestras complejas.

Para la descomposicion del algoritmo se pueden utilizar DFTs de un orden mayor comoorden mınimo, por ejemplo 4, 8, etc. La estructura a implementar permite la mezcla de unmayor numero de muestras a costa de una mayor complejidad, por ejemplo para radix-4(desarrollando la Ecuacion 6.1 con N = 4):

X4(k) =1∑

n=0

x4(n) ·W−nk4

X4(0) =

1∑n=0

x4(n) ·W−n·04 = x4(0) + x4(1) + x4(2) + x4(3)

X4(1) =1∑

n=0

x4(n) ·W−n·14 = x4(0)− x4(1) + x4(2)− x4(3)

X4(2) =

1∑n=0

x4(n) ·W−n·24 = x4(0) + x4(1)− x4(2) + x4(3)

X4(3) =

1∑n=0

x4(n) ·W−n·34 = x4(0) + jx4(1) + x4(2) + jx4(3)

(6.6)


Desde el punto de vista de implementacion, a partir de la estructura en radix-2 sepueden generar mariposas de un orden mayor, lo que se traduce en un mayor paralelismo enlos calculos. Por ejemplo, la estructura en radix-4 se puede construir con cuatro mariposasde radix-2, en dos etapas. Entre ambas etapas es necesario que una de las ramas se rote−90o (−j), lo que se puede realizar mediante un cambio de las componentes complejas yun cambio de signo.

Una mariposa de radix-8 se puede generar tambien a partir de mariposas en radix-4, eneste caso en tres etapas con cuatro mariposas radix-2 por etapa. Ademas de las rotacionessemi-triviales ya presentes en la estructura en radix-4 (−90o), aparecen nuevos angulosa rotar de −45o y −135o, que se pueden implementar utilizando dos multiplicadores porconstantes reales.

Como se puede observar, la mariposa se puede implementar como un conjunto deetapas de sumadores/restadores complejos y multiplicadores por constante. Un mayorradix (R) permite un mayor paralelismo aunque aumenta el coste en area. Para disponerde un radix R > 8, otros twiddle aparecen en la estructura, lo que obliga a utilizar nuevosmultiplicadores por constante, aunque esta vez complejos.

Hay que recordar que la longitud de la transformada depende del radix y del numerode etapas, N = RS , de modo que aumentar el radix de la mariposa va a permitir reducirel numero de etapas requeridas para implementar la arquitectura completa. Las estructu-ras en radix-2 y radix-4 presentan la ventaja que unicamente requieren de sumadores yrestadores para su implementacion, mientras que las de mayor orden necesitan de multi-plicadores, componentes mucho mas costosos que los anteriores. Este comportamiento sepuede observar en la Figura 6.4, donde se aprecia el crecimiento en area de la mariposa(slices Virtex-II de Xilinx) conforme aumenta el radix. En la grafica se muestra el bajocoste de implementaciones con radix inferiores a 8, ası como el crecimiento exponencialque supone aumentar el radix. Por ello, la estructura radix-4 se convierte en un valor deradix optimo para la mayorıa de las aplicaciones.

Otra caracterıstica a considerar durante la implementacion de la estructura de la ma-riposa es como controlar la anchura de bit de las muestras para evitar el desbordamiento(debido a los sumadores de la estructura, ya que la rotacion implementada con los multi-plicadores es a lo largo de la circunferencia unidad y por lo tanto no generan crecimiento).Se pueden implementar diferentes estrategias, desde truncar los bits menos significativospara evitar el crecimiento, o por el contrario mantenerlos. Mantener el ancho de bit fijosupone un ahorro en area, aunque va a degradar figuras de merito de la propia FFT, comopor ejemplo el margen dinamico.

6.2.2.2. Rotadores

En cada etapa de la descomposicion del algoritmo, tras la mezcla de muestras se deberealizar la multiplicacion por los terminos twiddle cuya definicion vista en el apartado 6.2.1se corresponde con:

TmN (n) = exp

−j2πm

N· n (6.7)

con m = 0..(R − 1). La multiplicacion de las muestras por estos terminos en el plano


Figura 6.4: Area requerida para implementar diferente radix.

complejo se corresponde con una rotacion a lo largo de la circunferencia unidad. Por suimplementacion se convierten en elementos crıticos debido al porcentaje en area que re-presentan estos componentes, dentro de cada etapa, en las diferentes arquitecturas que sevan a implementar. Su implementacion se basa a su vez en dos componentes: un elemen-to que almacena el valor de los twiddles a rotar y un elemento que realiza la rotacion,multiplicando los datos por su correspondiente twiddle.

Para la implementacion de un rotador completo se pueden presentar diferentes alter-nativas, por ejemplo, utilizar multiplicadores para realizar la rotacion:

X ′ = X cos θ − Y sin θ

Y ′ = X sin θ + Y cos θ(6.8)

con θ = 2πmn/N .

Para esta alternativa de implementacion la memoria de coeficientes almacena las cons-tantes twiddle, tanto cos θ como sin θ, con lo que se necesitan cuatro multiplicadores realesy dos sumadores reales.

Otra alternativa de implementacion es utilizar el algoritmo CORDIC, que permiterealizar la rotacion de un vector complejo mediante una serie de desplazamientos y sumas,evitando la necesidad de utilizar multiplicadores. Reordenando las Ecuaciones 6.8:

X ′ = cos θ(X − Y tan θ)

Y ′ = cos θ(Y +X tan θ)(6.9)

Si se limitan los posibles angulos a rotar de manera que tan θ = ±2−i, la rotacion sobreuno de estos angulos (que se designaran como elementales) se expresara:


Xi+1 = Ki · (Xi − Yi · di · 2−i)

Yi+1 = Ki · (Yi +Xi · di · 2−i)(6.10)

donde Ki = cos(arctan(2−i)) = 1/√1 + 2−2i y di = ±1. Una de las caracterısticas del

algoritmo CORDIC es que presenta una ganancia intrınseca (Ki), que aunque dependedel conjunto de angulos sobre los que se rota, tiende a aproximadamente 1,647. Desde elpunto de vista hardware, para mantener el margen dinamico de las muestras de entrada,esta ganancia provocara que se deba incrementar en un bit la anchura de palabra.

Para la implementacion de la FFT el conjunto de angulos a rotar (twiddles) es conocidoantes de la implementacion. Esto permite simplificar la implementacion del rotador, yaque es posible precalcular que rotaciones sobre los angulos elementales se deben realizarpor cada angulo twiddle y almacenar esta informacion en memoria en lugar del propioangulo (un bit que se corresponde con di en las Ecuaciones 6.10).

Durante la operacion del modulo completo, la rama de actualizacion del angulo secalcula como:

θi+1 = θi − di · arctan(2−i) (6.11)

Ademas, esta rama es la encargada de controlar el sentido de la rotacion: di = −1 siθi < 0, si no di = +1.

Con la simplificacion anterior del algoritmo, la implementacion del modulo CORDICya no requiere implementar la rama que actualiza el calculo del angulo rotado, con elconsiguiente ahorro de area, lo que tambien mejora la frecuencia de reloj.

6.2.2.3. Arquitectura Feedback

Como se menciono, los modulos de calculo de la mariposa y los rotadores son muysimilares tanto para la arquitectura FB como para la FF, por lo que se puede realizar unaimplementacion que los comparta y reutilice. Las diferencias entre ambas arquitecturasse va a encontrar en como se interconectan dichos componentes y en como se almacenan,ordenan y procesan las muestras que van llegando a cada una de las etapas de la arquitec-tura. Esta parte de la implementacion es caracterıstica de cada arquitectura y se encuentrafuertemente relacionada con la estructura de almacenamiento (memoria) requerida en cadaetapa.

Por lo tanto, tanto el control, como la estructura de memoria y la interconexion decomponentes van a ser muy diferentes entre ambas arquitecturas. La Figura 6.5 muestracomo se conectan los diferentes modulos para una implementacion en radix-4, de una etapade la arquitectura FB.

La estructura de una etapa de la arquitectura FB incluye un banco de memoria quealmacenara las muestras de entrada. Este banco de memoria se conectara a un modulobutterfly (implementacion de la mariposa) que se encarga de mezclar las muestras. Unade las salidas del modulo butterfly se conecta al modulo rotador, mientras que el resto desalidas se realimentan al banco de memoria.


Figura 6.5: Etapa de arquitectura FB.

Esta arquitectura permite un modo de trabajo continuo, es decir, permite el procesadocontinuo de secuencias de muestras de entrada, a una velocidad de una muestra por ciclode reloj, donde cada secuencia de muestras tiene una longitud que se corresponde con lalongitud implementada en cada etapa. Para realizar esta tarea la arquitectura implementaun control que permite solapar la llegada de muestras de una nueva secuencia a la eta-pa con el procesamiento de muestras de una secuencia anterior, mediante el cambio defuncionamiento de la estructura en dos ciclos:

En un primer ciclo se cargan las muestras de una nueva secuencia de entrada. Duranteeste ciclo, las muestras de una etapa de procesado anterior se van almacenando enlos bancos de memoria (1 muestra/ciclo), mientras que las muestras cargadas en lapropia memoria durante el ciclo de funcionamiento anterior (secuencia anterior) seextraen para ser procesadas en el rotador y pasar a la siguiente etapa de procesadode la FFT.

En el segundo ciclo los bancos de memoria solo contienen muestras de la actualsecuencia ((R − 1)/R muestras en total), aunque aun faltan muestras por recibirdesde la entrada. Durante este ciclo, se extraen de la memoria las muestras paraprocesarlas en paralelo junto con la muestra procedente de la etapa anterior. Lasmuestras son mezcladas en la mariposa, cuya salida en parte se procesara en elrotador, mientras que el resto de salidas son realimentadas a las posiciones que sevan liberando en los bloques de memoria.

En la Figura 6.6 se muestra un esquema de este doble ciclo de trabajo, para la pri-mera etapa de una implementacion en radix-4. Una vez alcanzado el procesado continuo(secuencia xy1), la memoria durante 3/4 de los ciclos almacena las nuevas muestras, ala vez que vuelca hacia los rotadores las muestras realimentadas de la secuencia anterior(xy0,2, xy0,3 y xy0,4). Con el ultimo cuarto de ciclo se cambia el modo de trabajo, serealiza la mezcla de las muestras de la secuencia xy1, aunque solo se puede rotar una delas sub-transformadas generadas (xy1,1), mientras que el resto se realimenta a memoria(xy1,2, xy1,3 y xy1,4), que se acabaran de procesar cuando la arquitectura cambie denuevo de modo.

La arquitectura FB para la implementacion de una FFT de radix-R requiere que cadaetapa implemente R − 1 bloques de memoria. Para la operacion en modo continuo, losbloques de memoria deben implementar una memoria de doble puerto, que permita la


Figura 6.6: Temporizacion arquitectura FB, N=1024 y R=4.

escritura y lectura en posiciones diferentes. Ademas, esta arquitectura requiere que cadaetapa de longitud N la estructura de memoria almacene N(R− 1)/R muestras.

Durante el primer ciclo de operacion, los datos de la etapa anterior se almacenan atraves de uno de los puertos, mientras que los datos almacenados en la memoria duranteel ciclo de operacion anterior se extraen por el otro puerto. Con la llegada de la muestraN(R − 1)/R desde la etapa anterior se cambia el ciclo de operacion, extrayendose enparalelo muestras desde todos los bloques de memoria.

La gestion de memoria de esta arquitectura no solo esta disenada para el almacena-miento temporal de los datos, sino que tambien permite controlar el procesado de la etapa,y la reordenacion de las muestras.

La eleccion del radix de la arquitectura supone uno de los parametros que mas influyenen la implementacion. Un mayor radix (R) reducira el numero de etapas (S) necesariaspara implementar una longitud N . Reducir el numero de etapas permite reducir el coste enarea de determinados recursos, como por ejemplo rotadores. Sin embargo, un mayor radixincrementa la complejidad y el area de determinados modulos, como se menciono al descri-bir el componente butterfly. En la Tabla6.1 se resume el gasto en numero de componentessegun crece el radix.

Tabla 6.1: Arquitectura FB. Numero de componentes.

Radix Rotadores Sumadores Memoria

2 S−2 2×S N4 S−1 8×S N8 S−1 24×S N

En todos los casos es necesario un rotador por etapa, con lo que implementacionescon mayor radix requieren un menor numero de etapas y por lo tanto de rotadores. Lossumadores de la implementacion se concentran en el butterfly, de modo que su nume-ro crece a medida que crece el radix. Finalmente, la cantidad de memoria se mantieneindependientemente del radix.


Figura 6.7: Etapa de arquitectura FF.

6.2.2.4. Arquitectura Feedforward

Al igual que la arquitectura FB, la arquitectura FF esta disenada para el procesadocontinuo de muestras, y presenta los mismos elementos basicos de procesado: memoriapara el almacenamiento temporal de muestras, un componente butterfly (mariposa) parala mezcla de muestras, y finalmente elementos para rotar las muestras.

A diferencia de la arquitectura FB, la arquitectura FF no realimenta ni reutiliza com-ponentes, sino que implementa un procesado en paralelo (hasta R muestras por ciclo),debiendo incluso replicar componentes. La Figura 6.7 muestra como se conectan los dife-rentes modulos para una implementacion en radix-4.

De nuevo, los modulos de procesado tienen una implementacion muy similar a la de laarquitectura FB. Por ejemplo, el modulo que implemente la mariposa resultara identico,mientras que la principal diferencia con el modulo de rotadores es su numero. Las princi-pales diferencias entre ambas arquitecturas se encuentran en la estructura de memoria, elinterconexionado de componentes y la manera en que se realiza la temporizacion y controlde las secuencias.

La memoria esta compuesta de una matriz de bloques de memoria (R × R). Estaestructura permite la escritura (por filas) y lectura (por columnas) de varias muestras enparalelo. Al igual que la estructura FB, esta estructura no solo permite el almacenamientotemporal de muestras, sino que tambien permite la reordenacion de muestras para suprocesado.

La estructura de memoria se conecta directamente con el modulo que implementa lamariposa, y la salida de este modulo se conecta con los rotadores. En la arquitecturaFB solo se requerıa de un rotador que se reutilizaba para con las diferentes DFTs demenor orden (cambiando los coeficientes). En el caso de la arquitectura FF, es necesarioun rotador por cada salida de la mariposa (cada salida se corresponde con una DFT demenor orden).

En la Figura 6.8 se muestra un esquema del modo de funcionamiento de esta arqui-tectura para una implementacion en radix-4. Puesto que el procesado de una secuenciano puede comenzar hasta haber recibido todas las muestras, es necesario que cada etapaimplemente una doble memoria que alterne la carga de muestras desde una etapa ante-rior y el volcado de las muestras a procesar. Las muestras de salida de la mariposa sonprocesadas por cuatro rotadores, descomponiendo la secuencia de entrada en las cuatro


Figura 6.8: Temporizacion arquitectura FF, N=1024 y R=4.

sub-transformadas de salida.

Si en la implementacion de la arquitectura FB un aumento del radix permite obtenerimportantes ahorros en area, con la arquitectura FF pasa todo lo contrario: un mayor radixpor una parte permite aumentar el paralelismo en el procesado, pero por otro lado aumentael gasto de recursos al ser necesario replicar diferentes componentes. Esta diferencia sepuede observar si se comparan la escala temporal de la Figura 6.6 de la arquitectura FBcon la escala temporal de la arquitectura FF en la Figura 6.8: esta ultima requiere 1/4(radix-4) de los ciclos de la FB para la primera etapa de la descomposicion.

Una implementacion radix-2 sera capaz de procesar dos muestras/ciclo, una implemen-tacion radix-4 procesara cuatro muestras/ciclo, etc. Si las diferentes implementaciones soncapaces de mantener la frecuencia de operacion, el aumento del radix va a permitir dispa-rar las prestaciones de la arquitectura. La Tabla 6.2 resume el coste en componentes conel radix y por numero de etapas (S) para una transformada de orden N :

Tabla 6.2: Arquitectura FF: Numero de componentes.

Radix Rotadores Sumadores Memoria

2 S−2 2×S 6×N4 3×(S−1) 8×S 4.6×N8 7×(S−1) 24×S 4.3×N

6.3. Especificacion de arquitecturas con dHDL

En los apartados anteriores se han descrito las arquitecturas FB y FF de la FFT, cuyaimplementacion se basa en una sucesion de etapas, ası como se han descrito los principalesmodulos que componen estas etapas, y su funcionamiento. A partir de la descripcion rea-

6.3 Especificacion de arquitecturas con dHDL 127

lizada de ambas arquitecturas se espera que la arquitectura FF obtenga unas prestacionessuperiores a la arquitectura FB, pero tambien a costa de un mayor coste en recursos.

El objetivo de este apartado es ilustrar las ventajas de la utilizacion de dHDL a lahora de especificar un diseno clasico como es la FFT. Puesto que uno de los objetivoses la reutilizacion, las implementaciones ofreceran un conjunto amplio de parametros quepermitan modificar caracterısticas del algoritmo, por ejemplo longitud de la transformada,el nivel de paralelismo, etc. Con este ejemplo se muestra como las arquitecturas imple-mentadas pueden adaptarse a diferentes aplicaciones al disponer de un amplio conjuntode parametros, y con ello mejoran sus posibilidades de reutilizacion.

Ademas, como se ha visto anteriormente, ambas arquitecturas necesitan de modulos ycomponentes similares, por lo que la propia implementacion de las arquitecturas se realizareutilizando un conjunto de modulos, tambien altamente parametrizables, que se han agru-pado formando una biblioteca. Ademas, componentes previamente implementados con ellenguaje, como por ejemplo operadores aritmeticos o logicos basicos, y que habıan sidoincorporados a la biblioteca forman la base para implementar los modulos de procesado ycontrol de ambas arquitecturas.

Finalmente, no hay que olvidar que el lenguaje dHDL permite al disenador controlardetalles de implementacion de bajo nivel. Ası parte de los parametros de las implementa-ciones serviran para configurar el uso de elementos de bajo nivel, y tambien para utilizarel lenguaje de generacion para seleccionar entre las diferentes alternativas y realizar laadaptacion del diseno.

6.3.1. Arquitectura Feedback

La implementacion de la arquitectura se realizara con dHDL se compone de un en-capsulado estructural para la declaracion de la interfaz y la propia implementacion de laarquitectura en dHDL.

En el apartado 6.2.2 se indico que las arquitecturas a implementar se descomponenen un conjunto de etapas, donde cada etapa se compone a su vez de un conjunto deelementos (memoria, mariposa, rotador). Estos componentes a su vez hacen uso de otroscomponentes de biblioteca para su implementacion. La Figura 6.9 muestra parte de loscomponentes utilizados en la implementacion de esta arquitectura, ası como su ubicaciondentro de la biblioteca.

En la implementacion de la arquitectura, dHDL realiza la descripcion de la arquitecturade nivel superior (top), incluyendo la descripcion del conjunto de etapas, ası como ladescripcion de que contiene cada etapa.

La descripcion estructural de nivel superior utiliza otros cores dHDL que describen asu vez los diferentes modulos que componen cada etapa: memoria, mariposa y rotador.Estos cores, una vez implementados, se incorporan a una biblioteca de componentes demodo que pueden ser reutilizados en otros disenos, en nuestro caso muchos de los modulosimplementados para la arquitectura Feedback se reutilizaran para la implementacion de laarquitectura Feedforward, aunque a diferentes niveles de la jerarquıa.

En este apartado se comenzara describiendo el codigo dHDL (encapsulado e imple-mentacion) de nivel superior de la jerarquıa, y que contiene la descripcion estructural de


Figura 6.9: Biblioteca de componentes para la arquitectura FB.

la arquitectura. Despues se describiran los principales modulos del siguiente nivel de lajerarquıa.

6.3.1.1. Arquitectura FB: Encapsulado Estructural

Como se vio en el apartado 5.2, en el encapsulado de la arquitectura FB se debendeclarar los parametros de configuracion, atributos de la arquitectura generada y puertos(macropuertos) de entrada/salida. Los parametros que configuran la implementacion sedividen en tres grupos:

Parametros relacionados con la transformada: la longitud de la transformada depen-dera de dos parametros, el numero de etapas y el radix de la implementacion.

Parametros relacionados con la anchura de bit de las muestras: por una parte unparametro para definir la anchura de bit a la entrada de la transformada, y tambienparametros que van a controlar su crecimiento a traves de los diferentes componentes,por ejemplo la mariposa y los rotadores.

Finalmente parametros que definan el uso que se hace de los componentes fısicosdisponibles. Dado que la especificacion esta orientada a implementarse en FPGA, sedeclararan parametros que permitan ajustar el uso de elementos empotrados comobloques de memoria o multiplicadores.

En el Ejemplo 6.1 se muestra el detalle de la declaracion de los parametros RADIX

y STAGES que configuran la longitud de la transformada (RADIXSTAGES). Declarar el


Ejemplo 6.1 FFT FB: Encapsulado estructural. Declaracion de parametros RADIX ySTAGES.

<parameter id="RADIX">

<type>radixtype</type>


</parameter>


<type>int8</type>


</parameter>

parametro RADIX restringiendolo con el tipo radixtype (en el Ejemplo 6.3 se muestrasu declaracion) permite controlar que no se le asigne un valor arbitrario, sino entre lospermitidos (2, 4, ...). Como se vio en la definicion del encapsulado estructural, en el apar-tado 5.2.2, una de las ventajas que ofrece la declaracion de parametros es limitar losposibles valores para que la arquitectura pueda ser correctamente generada.

Ejemplo 6.2 FFT FB: Encapsulado estructural. Parametros para el control de la anchurade bits.


<type>int8</type>


</parameter>

<parameter id="BUTTERFLY_GROWTH">



</parameter>

<parameter id="ROTATOR_GROWTH">



</parameter>

En el Ejemplo 6.2 se ha recogido la declaracion de los parametros relacionados con elcontrol de la anchura de bits: el parametro WIDTH configura el ancho de bit de las muestrasde entrada, y con los parametros BUTTERFLY GROWTH y ROTATOR GROWTH se controla elcrecimiento en los diferentes modulos que componen la arquitectura.

En el Ejemplo 6.3 se muestra la declaracion completa de parametros que configuranla arquitectura ası como la declaracion de tipos que permiten restringir el valor de losparametros. Ademas de los parametros declarados en los Ejemplo 6.1 y 6.2, en el encap-sulado se declaran parametros que permiten configurar que elementos de bajo nivel seutilizan en la implementacion. ROTATOR TYPE, que el Ejemplo 6.3 se ha declarado comovalor por defecto cordic, permite seleccionar que los rotadores se implementen utilizandoel algoritmo CORDIC o mediante multiplicadores complejos (posibles implementacionesya vistas en el apartado 6.2.2.2), y en el caso de utilizar multiplicadores complejos elparametro ROTATOR MULT especifica si se utilizan multiplicadores integrados o se imple-mentan utilizando logica. En el caso de los modulos de memoria, el parametro MEM TYPE

permite seleccionar entre implementarlos utilizando logica distribuida o memoria en blo-que, mientras que el parametro MEM BRAM TH permite establecer un umbral, en profundidadde memoria, a partir del cual utilizar memoria distribuida o memoria en bloque.

En el encapsulado estructural tambien se declaran los atributos que informan de lascaracterısticas de la implementacion. En el Ejemplo 6.4 se muestran algunos de los atri-butos declarados para esta implementacion. La longitud de la transformada, FFT POINTS,


Ejemplo 6.3 FFT FB: Encapsulado estructural. Declaracion de parametros.<definitions>

<deftype id="radixtype">

<union type="int8">

<item>2</item>

<item>4</item>

<item>8</item>

<item>16</item>

<item>32</item>

<item>64</item>

</union>

</deftype>

<deftype id="rotatortype">


<item>"codic"</item>

<item>"mult"</item>

</union>

</deftype>

<deftype id="rotatormulttype">


<item>"logic"</item>

<item>"dsp"</item>

</union>

</deftype>

<deftype id="memtype">


<item>"logic"</item>

<item>"bram"</item>

</union>

</deftype>

</definitions>

<parameters>




</parameter>


<type>int8</type>


</parameter>


<type>int8</type>


</parameter>




</parameter>




</parameter>

<parameter id="ROTATOR_TYPE">

<type>rotatortype</type>

<value><vall>"cordic"</vall></value>

</parameter>

<parameter id="ROTATOR_MULT">

<type>rotatormulttype</type>

<value><vall>"logic"</vall></value>

</parameter>

<parameter id="MEMORY_TYPE">

<type>memype</type>

<value><vall>"bram"</vall></value>

</parameter>

<parameter id="MEMORY_BRAM_TH">

<type>int8</type>


</parameter>

</parameters>

se puede resolver con una llamada a funcion con los parametros RADIX y STAGES.

Otro atributo del Ejemplo 6.4, LATENCY, informa de la latencia de la implementaciony se inicializa a cero, permitiendo que se actualice su valor en el momento que se generela implementacion: como se indico en el apartado 6.2.2 la implementacion de las arquitec-turas cuenta con tres niveles de pipeline (por etapa, por componentes y dentro de cadacomponente), cada implementacion contara con un numero distinto de etapas, ademas esposible que no todas la etapas incorporen todos los modulos de procesado, y finalmente laimplementacion de un mismo componente puede presentar una latencia muy diferente enfuncion de sus parametros de configuracion (por ejemplo, un rotador implementado conel CORDIC o con multiplicadores complejos). Aunque es posible obtener una funcion quecalcule este atributo en funcion de los parametros de entrada su implementacion resul-ta costosa, mientras que una de las ventajas de los atributos dHDL es que permiten suactualizacion conforme se genera la arquitectura.

Finalmente, en el Ejemplo 6.5 se muestran los macropuertos de la implementacion. Laimplementacion constara unicamente de dos puertos de entrada (ReI para la parte real yImI para la parte imaginaria) y dos puertos de salida (ReO para la parte real y ImO parala parte imaginaria).


Ejemplo 6.4 FFT FB: Encapsulado estructural. Declaracion de atributos.<attributes>

<attribute id="FFT_POINTS">

<type>int32</type>

<value>

<valf id="pow">

<arg><vall>RADIX</vall></arg>

<arg><vall>STAGES</vall></arg>

</valf>

</value>

</attribute>


<type>int32</type>


</attribute>

...

</attributes>

Ejemplo 6.5 FFT FB: Encapsulado estructural. Declaracion de macropuertos.<macroports>

<macroport id="ReI">

<type>lvi</type>


<value><vall>WITDH</vall></value>

</property>

</macroport>

<macroport id="ImI">

<type>lvi</type>



</property>

</macroport>

<macroport id="ReO">

<type>lvo</type>



</property>

</macroport>

<macroport id="ImO">

<type>lvo</type>



</property>

</macroport>

<net id="clock">

<mport id="ReI" signal="clock" />

<mport id="ImI" signal="clock" />

<mport id="ReO" signal="clock" />

<mport id="ImO" signal="clock" />

</net>

<net id="enable">

<mport id="ReI" signal="enable" />

<mport id="ImI" signal="enable" />

<mport id="ReO" signal="enable" />

<mport id="ImO" signal="enable" />

</net>

</macroports>

6.3.1.2. Arquitectura FB: Descripcion de la estructura

La descripcion de la arquitectura se realizara de una manera jerarquica. Como ya se hamencionado, en la parte superior de la jerarquıa se realizara la descripcion de la estructurade la arquitectura completa, indicando donde y como se utilizaran los principales modulosde la implementacion: memoria, butterfly y rotador. En el Ejemplo 6.6 se muestran losprincipales detalles del codigo dHDL para la descripcion de la estructura: un bucle whilegenerara y conectara las sucesivas etapas, donde en cada etapa se configuran y generanlos modulos basicos de la implementacion: memory, butterfly y twiddle.

Aunque los principales modulos de la implementacion son memory, butterfly y rotador,en el codigo se hace uso de otros elementos, como son multiplexores, buffers e incluso uncontador, todos ellos incluidos dentro de la biblioteca logic. En el Ejemplo 6.7 se muestracomo antes de iniciarse el bucle principal de generacion de la estructura se referencianotros cores dHDL dentro de la biblioteca de componentes.

La Figura 6.10 representa de manera simplificada el proceso de generacion de la es-tructura de la arquitectura FB. Para su generacion se utilizan dos variables, data real

y data imag, que se utilizaran para almacenar una referencia a las componentes real e


Ejemplo 6.6 FFT FB: Descripcion de la estructura....

variable fft_index = STAGES;

while ( fft_index > 0 ) {

...

butterfly.generics (...);

memory.generics (...);

...

memory_stage.ports;

...

butterfly_stage.ports;

...

if ( fft_index > 1 ) {

...

twiddle.generics (...);

twiddle_stage.ports;

...

}

fft_index = Dec(fft_index);

} // end while

...

Figura 6.10: Generacion del top de la arquitectura FB.

imaginaria de salida de los componentes segun se vayan instanciando. La descripcion sebasa en un bucle while donde se generaran las diferentes etapas en las que se descomponela arquitectura, donde en cada etapa se insertan los componentes de procesado, ası comoel interconexionado.

Como se vio en el apartado 4.4.2.4 el uso de referencias dHDL (entity) permite accedera otros cores dHDL, pero sin generar codigo VHDL en la descripcion actual. La referenciaal core puede ser configurada, y generar un componente dHDL (component), que tampocogenera codigo en la descripcion actual. El componente dHDL, visto en el apartado 4.4.2.5,permite acceder a los datos de configuracion, atributos y puertos del componente genera-do. El componente dHDL solo genera codigo tras una llamada a ports. De nuevo en elEjemplo 6.7 se muestra como se referencia a un contador de la biblioteca, se configura yse genera un componente counter que es el encargado de generar la senal de control paratoda la arquitectura.


Ejemplo 6.7 FFT FB: Descripcion de componentes de la biblioteca....

entity counter = logic.counter;

entity buffer = logic.buffer;

entity mux = logic.multiplexor;

entity butterfly = fft.butterfly.dif;

entity memory = fft.fbck.memory.datamem;

entity twiddle = fft.fbck.twiddle.rotator;

...

counter.generics ( WIDTH = Log2(FFT_POINTS) );

component control_counter = counter->generate;

port master_control_count : control_counter->port("O");

control_counter.ports;

...



...

} // end while

...

Por lo tanto, el control de la arquitectura se genera mediante el codigo:

counter.generics ( WIDTH = Log2(FFT_POINTS) );

component control_counter = counter->generate;

port master_control_count : control_counter->port("O");


Otros componentes basicos de la biblioteca, pero relevantes en la implementacion, sonlos buffers que se utilizan para sincronizar la salida de este contador de control en lasdiferentes etapas de la implementacion, debido a la latencia que presenta cada modulo.

Como se vio en el apartado 4.4.2.1, el lenguaje dHDL permite utilizar variables paraalmacenar referencias a otros elementos del lenguaje, mecanismo especialmente util paratransportar estos elementos fuera del bloque de control donde se declaren. Esta funcio-nalidad del lenguaje se aprovecha para realizar el interconexionado entre los diferentesmodulos que forman la etapa dentro de la estructura. En el Ejemplo 6.8 se utilizan lasvariables data real y data imag de este modo. Al inicio de la descripcion se “conectan”a los puertos de entrada. En el bucle while se utilizan estas variables para referenciar losdatos de entrada a los modulos, mientras que al final del bucle contendran la referencia alpuerto de salida del ultimo componente generado:

Durante la primera iteracion del bucle estas variables contendran la referencia alos puertos de entrada (asignados en el punto 1 de la Figura 6.10), mientras que ensucesivas iteraciones contendran la referencia al rotador (asignados antes de la salidade cada etapa en los puntos 3, 5, . . . de la Figura 6.10).

Tras la ultima iteracion, donde no es necesario generar el rotador, contendran lareferencia al puerto de salida del butterfly, y dicha referencia se utilizara paraconectarla con los puertos de salida de la implementacion (en la Figura 6.10 duranteesta ultima iteracion no se genera rotador).

Durante la generacion de la etapa, primero se utilizan para conectar la entradadel modulo de memoria y se actualizan con la referencia al puerto de salida delcomponente butterfly, permitiendo ası transportarla fuera del bloque de controldonde se declara este puerto (en los puntos 2, 4, . . . de la Figura 6.10).


Ejemplo 6.8 FFT FB: Interconexionado de las etapas....

variable data_real = ReI; variable data_imag = ImI;

entity counter = logic.counter;

...


...

butterfly.generics (...); component c_butterfly = butterfly->generate;

memory.generics (...); component c_memory = memory->generate;

...

variable index = 0;

while ( index < RADIX ) {

port p_btf_ir = c_butterfly->port("IR", index); port p_btf_ii = c_butterfly->port("II", index);

port p_btf_or = c_butterfly->port("OR", index); port p_btf_oi = c_butterfly->port("OI", index);

port p_mem_ir = c_memory->port("IR", index); port p_mem_ii = c_memory->port("II", index);

port p_mem_or = c_memory->port("OR", index); port p_mem_oi = c_memory->port("OI", index);

p_btf_ir.adapter(p_mem_or); p_btf_ii.adapter(p_mem_oi);

if ( index == 0 ) {

p_mem_ir.adapter(data_real); p_mem_ii.adapter(data_imag);

data_real = p_btf_or; data_imag = p_btf_oi;

} else {

p_mem_ir.adapter(p_btf_or); p_mem_oi.adapter(p_btf_oi);

}

index = Inc(index);

}

memory_stage.ports;

butterfly_stage.ports;

...


...

twiddle.generics (...); component c_twiddle = twiddle->generate;

port p_twd_ir = c_twiddle->port("IR"); p_twd_ir.adapter(data_real);

port p_twd_ii = c_twiddle->port("II"); p_twd_ii.adapter(data_imag);

port p_twd_or = c_twiddle->port("OR"); data_real = p_twd_or;

port p_twd_oi = c_twiddle->port("OI"); data_imag = p_twd_oi;

c_twiddle.ports;

...

}


} // end while

ReO = data_real;

ImO = data_imag;

...

Tambien en el Ejemplo 6.8, dentro de la descripcion de cada etapa, la configuracion delcomponente butterfly se realiza antes que la del modulo de memoria, aunque tras realizar laconexion entre ambos bloques, se genera primero el modulo de memoria. Esto es debido aque la memoria debe almacenar las muestras realimentadas de salida del butterfly, y estea su vez depende de como se configure el crecimiento en la arquitectura y del propio radixde la implementacion. Esta es otra de las caracterısticas ofrecidas por dHDL: se puederetrasar la generacion de un componente hasta disponer de la configuracion adecuada, yademas obtener esta configuracion a partir de la informacion de otros componentes. Unavez configurados ambos modulos se puede generar y declarar todo el conjunto de senalesque los interconectan.

En este apartado se ha presentado la descripcion dHDL de la estructura de la arquitec-tura seleccionada, y como configurar los modulos a utilizar a partir tanto de parametrosdeclarados en el codigo, como de variables calculadas para cada instancia (configuraciontop-down). Una vez generados los modulos que componen la arquitectura, desde el compo-nente se recoge el valor de los atributos que interese (por ejemplo el valor de la latencia)


Ejemplo 6.9 Modulo de memoria: Encapsulado estructural. Declaracion de parametros.<parameters>

<parameter id="DATA_WIDTH">

<type>int8</type>


</parameter>

<parameter id="FBCK_WIDTH">

<type>int8</type>


</parameter>




</parameter>

<parameter id="STAGE">

<type>10</type>


</parameter>


<type>memype</type>

<value><vall>"bram"</vall></value>

</parameter>


<type>int8</type>


</parameter>

...

</parameters>

para almacenarlos en variables o procesarlo y generar atributos propios (recogida de in-formacion bottom-up).

6.3.1.3. Modulo de Memoria

De manera similar a la descripcion de la estructura general vista en el apartado anterior,el codigo dHDL que describe la estructura de memoria se compondra por una parte de unencapsulado estructural que declare parametros, atributos y puertos, y por otra parte dela propia descripcion de dHDL del componente.

Encapsulado estructural

El encapsulado estructural de este componente, similar al declarado para la arquitectu-ra general, presenta sus propias caracterısticas, como por ejemplo los parametros declara-dos. En el Ejemplo 6.9 se muestran parte de los parametros declarados para configurar estemodulo de memoria. Permite configurar diferentes tamanos para las muestras de entradaa la etapa, DATA WIDTH, o las realimentadas desde la salida de la mariposa, FBCK WIDTH.Otros parametros permiten dimensionar el numero (RADIX) y tamano (STAGE) de los blo-ques de memoria a utilizar. Finalmente, parametros ya declarados en el componente dejerarquıa superior del Ejemplo 6.3 (MEMORY TYPE y MEMORY BRAM TH) permiten configurarel uso de elementos de bajo nivel.

En el Ejemplo 6.10 se muestra la declaracion de parte de los atributos declaradospara informar de caracterısticas del modulo, por ejemplo el numero de datos en la etapa,los bloques de memoria necesarios, datos por bloque de memoria, ... Estos atributos sepueden calcular directamente a partir de los parametros declarados. Otros atributos, comopor ejemplo LATENCY, se calcularan durante la generacion: presentara ligeras variacionesdependiendo de si durante la generacion del modulo se registran entradas, salidas, del tipode memoria utilizada, etc.

Para completar el encapsulado estructural de este componente se declaran los macro-puertos, de manera similar a como ya se realizo en el componente de la jerarquıa superiordel Ejemplo 6.5, aunque por motivos de espacio no se incluyen. Finalizada la declaracionde la interfaz, en el codigo se procede a la descripcion de la estructura de memoria.


Ejemplo 6.10 Modulo de memoria: Encapsulado estructural. Declaracion de atributos.<attributes>

<attribute id="STAGE_DATUM">

<type>int32</type>

<value>

<valf id="pow">


<arg><vall>STAGES</vall></arg>

</valf>

</value>

</attribute>

<attribute id="MEM_BLOCKS">

<type>int32</type>

<value>

<valf id="dec">


</valf>

</value>

</attribute>

<attribute id="MEM_BLOCKS_DATUM">

<type>int32</type>

<value>

<valf id="div">

<arg><vall>STAGE_DATUM</vall></arg>


</valf>

</value>

</attribute>

...


<type>int32</type>


</attribute>

...

</attributes>

Ejemplo 6.11 Modulo de memoria: Estructura para la arquitectura FB.entity datacell = fft.memory.datacell;

datacell.generics (

WIDTH = Mult(FBCK_WIDTH, 2),

DATUM = MEM_BLOCKS_DATUM,

MEM_TYPE = MEMORY_TYPE,

BRAM_TH = MEMORY_BRAM_TH );

component mem_datacell = datacell->generate;

variable dout_mem [Dec(RADIX)];

variable index = 0;

while ( index < Dec(RADIX) ) {

signal control_addr : Log2(MEM_BLOCKS_DATUM);

signal control_mux : Log2(RADIX);

code {

[control_addr] <= [vhdl.Range(ADDR...];

[control_mux] <= [vhdl.Range(ADDR...]; }

signal write_en : 1;

code {

[write_en] <=

’1’ when [ADDR.enable]=’1’ AND

([control_mux]="[Dec2Bin(Dec(...)]" OR

[control_mux]="[Dec2Bin(...)]")

else ’0’; }

...

port p_mem_o : mem_datacell->port("O");

mem_datacell.ports;

dout_mem[index] = p_mem_o;

index = Inc(index);

} // end while

Descripcion

El Ejemplo 6.11 muestra parte de la descripcion del modulo de memoria. En la descrip-cion no se definen los elementos de bajo nivel de memoria, sino que se utiliza otro modulocreado en la biblioteca, datacell, al que se le pasan, entre otros, los parametros que se-leccionan el tipo de memoria a utilizar. Como se menciono anteriormente la estructura delmodulo de memoria es caracterıstico de cada arquitectura a implementar, con lo que eldiseno del modulo de memoria para la arquitectura FB resulta muy diferente a la de laarquitectura FF. A pesar de ello, ambas arquitecturas (como se vera mas adelante) hacenuso de componentes mas basicos dentro de la biblioteca que se adaptan a sus necesidades,como por ejemplo el componente datacell, potenciando ası la reutilizacion de los propioscomponentes de la biblioteca.

Volviendo al Ejemplo 6.11, el bloque datacell una vez que ha sido configurado, seutiliza dentro de un bucle while, insertando uno de estos modulos por iteracion, e inter-conectandolo. Un detalle de la implementacion es como se genera el control a partir delmacropuerto de direcciones de entrada y utilizando una inserciones de codigo vistas en elapartado 4.4.3:

Se genera una senal dHDL, control addr, a partir de los bits menos significativospara direccionar los bloques de bajo nivel de memoria (datacell).


Ejemplo 6.12 Modulo butterfly : Encapsulado estructural. Declaracion de parametros.<parameters>


<type>int8</type>


</parameter>




</parameter>

<parameter id="GROWTH">



</parameter>

...

</parameters>

Tambien se genera la senal dHDL control mux a partir de los bits mas significativosdel macropuerto de direcciones, que controla el modo de trabajo (apartado 6.2.2.3)en el que se encuentra la estructura.

Otra senal dHDL, write en, que habilita la escritura en el bloque de memoria debajo nivel en funcion del modo de trabajo, recogido en la senal dHDL control mux

declarada e inicializada anteriormente.

Tras la declaracion de los puertos del bloque de memoria de bajo nivel y su inter-conexionado, tanto con los puertos de entrada como con las senales dHDL declaradasanteriormente, las salidas de los diferentes bloques de memoria se recogen mediante unarray de variables que posteriormente se utilizara para conectarlos con los puertos desalida.

6.3.1.4. Modulo Butterfly

El segundo modulo de procesado que se encuentra en cada etapa de ambas arquitectu-ras se corresponde con la implementacion de la mariposa. Este modulo tambien se imple-menta mediante un componente dHDL, con su correspondiente encapsulado estructuraly la implementacion dHDL. Para este ejemplo solo se mostrara la parte del encapsuladoestructural correspondiente a la declaracion de los parametros, al igual que la parte masrelevante de la descripcion de la estructura en dHDL.

En el Ejemplo 6.12 se muestran los parametros mas relevantes para la configuracionde este modulo: anchura de bit de entrada (WIDTH), radix de la implementacion (RADIX) ysi se produce o no crecimiento en bits a la salida (GROWTH).

Descripcion

La estructura de este modulo se basa en un conjunto de etapas donde se intercala unaetapa con varias mariposas radix-2, seguida de una etapa donde se realizan las rotacio-nes (multiplicaciones) por las constante twiddle que se incorporan a la estructura. En elEjemplo 6.13 se muestran la estructura general para la generacion de las diferentes etapas.

En el Ejemplo 6.13 muestra como se utilizan dos componentes que tambien se hanincorporado a la biblioteca: una mariposa de radix-2, y un componente kmult encarga-do de generar las multiplicaciones por constante. La estructura genera un conjunto deLog2(RADIX) etapas mediante una estructura de control de tipo while. Dentro de estaestructura de control se anidan hasta cinco bucles para incorporar los diferentes compo-nentes en cadena: un primer bloque genera el conjunto de componentes butterfly, unsegundo bloque verifica las multiplicaciones a realizar, el tercer bloque genera las multi-


Ejemplo 6.13 Modulo butterfly : Descripcion de la estructura.entity radix2 = fft.butterfly.radix2;

entity kmult = fft.butterfly.kmult;

variable index_stage = 0;

while ( index_stage < Log2(RADIX) ) {

radix2.generics( ... );

component r2 = radix2->generate;

index = 0;

// radix-2 butterfly loop

while ( index < Div(RADIX, 2) ) {

...

r2.ports;

}

variable maxlat = 0;

index = 0;

// pre-kmult loop


...

}

index = 0;

// kmult loop


...

kmult.generics( ... );

...

k_mult.ports;

...

}

...

index = 0;

// reordering


...

}

index = 0;

// reassign


...

}

}

Ejemplo 6.14 Modulo butterfly : Generacion de mariposas radix-2.while ( index_stage < Log2(RADIX) ) {

...

// radix-2 butterfly loop


variable first = index;

variable second = Add(index, Div(RADIX, 2));

port real_a : stg_multiplier->port("ReA")

port imag_a : stg_multiplier->port("ImA")

real_a.adapter(data_real[fisrt]);

imag_a.adapter(data_imag[fisrt]);

port real_b : stg_multiplier->port("ReB")

port imag_b : stg_multiplier->port("ImB")

real_b.adapter(data_real[second]);

imag_b.adapter(data_imag[second]);

port real_x : stg_multiplier->port("ReX");

port imag_x : stg_multiplier->port("ImX");

port real_y : stg_multiplier->port("ReY");

port imag_y : stg_multiplier->port("ImY");

r2.ports;

data_real[first] = real_x;

data_imag[first] = imag_x;

data_real[second] = real_x;

data_imag[second] = imag_x;

...

}

}

plicaciones, y el cuarto y quinto bloques permiten reordenar las salidas y prepararlas parala siguiente iteracion.

Dentro de cada iteracion del bucle principal, primero se configuran e instancian lasmariposas radix-2, donde se mezclan las muestras. Para ello, como muestra el Ejemplo 6.14,donde primero se declaran los puertos de la mariposa radix-2: las entradas se conectan alas referencias contenidas en variables (desde los puertos de entrada o desde iteracionesanteriores), para luego actualizar la referencia a los puertos de salida de la mariposa.

Tras la generacion de las etapa de mariposas radix-2, se han de insertar los multi-plicadores por constante. Estas multiplicaciones varıan dependiendo del radix de la im-plementacion. Por ejemplo, para radix-4 aparece una unica rotacion a realizar, que secorresponde con −90o y que puede implementarse como un cambio entre las componentes(parte real e imaginaria) con un cambio de signo. Otras rotaciones necesitaran de ma-nera general realizar una multiplicacion compleja, salvo algunas excepciones, como porejemplo angulos de −45o donde se podran realizar simplificaciones. El modulo kmult seencarga de esta funcion, es decir, implementar estas rotaciones por constante. Ademas,diferentes implementaciones con diferente complejidad presentaran diferente latencia. Es-te modulo informa de la latencia necesaria para realizar cada rotacion. La generacion delos multiplicadores se realiza utilizando los dos siguientes bucles, como se muestra en el


Ejemplo 6.15 Modulo butterfly : Generacion de multiplicadores.while ( index_stage < Log2(RADIX) ) {

...


...

}

variable maxlat = 0;

index = 0;


variable twiddle_term =

fft.Twiddle(RADIX, index_stage, index);


variable lat = kmult->attribute("LATENCY");

if ( lat > maxlat ) maxlat = lat;

...

}

index = 0;


variable twiddle_term =

fft.Twiddle(RADIX, index_stage, index);


...

k_mult.ports;

...

}

...

}

Ejemplo 6.16 Modulo butterfly : Reordenacion de las salidas.variable data_real[RADIX];

variable data_imag[RADIX];

...

while ( index_stage < Log2(RADIX) ) {

...

index = 0;


variable in_1 = index;

variable in_2 = Add(index, Div(RADIX, 2));

variable out_1 = Mult(index, 2);

variable out_2 = Add(Mult(index, 2), 1);

tmp_real [out_1] = data_real [in_1];

tmp_imag [out_1] = data_imag [in_1];

tmp_real [out_2] = data_real [in_2];

tmp_imag [out_2] = data_imag [in_2];

index = Inc(index);

}

index = 0;


data_real [index] = tmp_real [index];

data_imag [index] = tmp_imag [index];

index = Inc(index);

}

}

Ejemplo 6.15.

En el segundo bucle de la iteracion (primer bucle en el Ejemplo 6.15) se realiza unrecorrido donde se calculan los twiddles que se deben implementar, y se configura el com-ponente kmult, para obtener la latencia necesaria para rotar ese twiddle. A la salida deeste segundo bucle se habra calculado la latencia maxima y almacenado en la variabledHDL maxlat. Esta es una de las funcionalidades del lenguaje dHDL, se pueden realizardiferentes configuraciones sobre los componentes y evaluar sus caracterısticas sin que segenere el codigo VHDL asociado (apartado 4.22).

Ası, en el tercer bucle de la iteracion (segundo bucle en el Ejemplo 6.15), ya conocidala latencia maxima necesaria por lo rotadores, se vuelven a calcular los twiddles, pero estavez generando el rotador requerido. En los casos en que no debe realizarse rotacion, elcomponente kmult se encarga de ecualizar su salida con la latencia maxima calculada enel bucle anterior, al igual que en los casos en que sı deba realizar rotacion pero con unalatencia menor al maximo calculado.

Finalmente, los ultimos bucles de la estructura se utilizan para reordenar las salidas yprepararlas para la siguiente iteracion o para conectarlas con los puertos de salida, comose muestra en el Ejemplo 6.16. Para ello se utilizan dos arrays de variables (data real ydata imag) que durante los diferentes bucles se han utilizado para almacenar las referenciasa los puertos con la salida de datos de los diferentes modulos. En un primer bucle delEjemplo se define y utiliza otro par de arrays de variables (tmp real y tmp imag) parareordenar las referencias, mientras que en el ultimo bucle se reasignan a las variablesdata real y data imag.


Ejemplo 6.17 Modulo rotador: Encapsulado estructural. Declaracion de parametros.<parameters>


<type>int8</type>


</parameter>

<parameter id="STAGE">

<type>int8</type>


</parameter>




</parameter>




</parameter>


<type>rotatortype</type>

<value><vall>"cordic"</vall></value>

</parameter>


<type>rotatormulttype</type>

<value><vall>"logic"</vall></value>

</parameter>

...

</parameters>

6.3.1.5. Modulo Rotador

El ultimo modulo que vamos a implementar en la arquitectura FFT es el que generalos componentes necesarios para realizar la rotacion por los twiddle. Al igual que sucedecon los modulos para la implementacion de la memoria o la mariposa, en este modulo serealiza una descripcion estructural que incluira a otros componentes de mas bajo nivelincluidos en la biblioteca.

En el encapsulado estructural del componente se declaran los parametros que confi-guran el rotador, como se puede observar en el Ejemplo 6.17. Desde la anchura de lasmuestras de entrada hasta los parametros que configuran el tipo de rotador. Para calcularlos twiddles correctos son necesarios los parametros STAGE y RADIX. De nuevo, aunqueno se detallan por problemas de extension, durante el encapsulado estructural tambien sedeclaran los atributos y los macropuertos del componente.

Durante la descripcion dHDL del elemento rotador se selecciona entre diferentes tiposde rotadores (CORDIC o multiplicadores complejos), con lo que aunque los elementosgenerados son similares (rotador junto con una memoria ROM que almacena los coefi-cientes twiddle), su implementacion es muy diferente. Por lo tanto la descripcion en estecomponente se limita a seleccionar y configurar los elementos apropiados dependiendo delos parametros de configuracion. En el Ejemplo 6.18 se muestra la estructura de controlcondicional que permite seleccionar el juego de rotador y memoria segun la configuracion.

Ejemplo 6.18 Modulo rotador: Seleccion del rotador.if ( ROTATOR_TYPE="cordic" ) {

entity cordic = arith.cordic.online.fixrots;

entity twiddlemem = fft.fbck.twiddle.cordicmem;

...

} else {

entity mult = arith.complexmult;

entity twiddlemem = fft.fbck.twiddle.multmem;

...

}

La generacion de la memoria de coeficientes se hace de acuerdo con el tipo de rotadorseleccionado. La generacion de las constantes de memoria se realiza mediante insercionesde codigo y utilizando funciones disenadas para cada caso. En el Ejemplo 6.19 se muestraun extracto del codigo necesario para generar los coeficientes en el caso de que se seleccionecomo rotador el CORDIC. En el componente dHDL cordicmen se generan cada una de


Ejemplo 6.19 Generacion de coeficientes twiddle.variable index = 0;

while ( index < NUM_DATUM ) {

decl {CONSTANT cordic_[index] : STD_LOGIC_VECTOR ([Dec(WIDTH)] DOWNTO 0) :=

"[fft.twiddle.CordicRots(index, POINTS, INDEX, WIDTH)]"; }

code { cordic_[index] WHEN [vhdl.Dec2Bin(index, ADDR_WIDTH)], }

index = Inc(index);

}

code { ( OTHERS => ’-’ ) WHEN OTHERS; }

Figura 6.11: Biblioteca de componentes para la arquitectura FF.

las posiciones de memoria, mediante un bucle dHDL while, y realizando una llamada ala funcion CordicRots.

6.3.2. Arquitectura Feedforward

De manera similar a como se ha estructurado la implementacion de la arquitecturaFB, la arquitectura FF tambien se implementa mediante un conjunto de ficheros fuentedHDL, donde en el primer componente dHDL se realiza la descripcion de la arquitecturade nivel superior (top), incluyendo en la descripcion de la descomposicion en el conjuntode etapas, ası como la descripcion estructural de cada etapa. Desde esta descripcion denivel superior se hace uso de otros componentes que describen a su vez los diferentesmodulos que componen cada etapa: memoria, mariposa y rotador. De manera analoga ala implementacion de la arquitectura FB, la implementacion de esta arquitectura se basaen componentes de biblioteca. La Figura 6.11 muestra la disposicion de parte de estosmodulos dentro de la biblioteca.

Durante el apartado 6.2.2 se menciono que tanto la arquitectura FB como la arqui-


Ejemplo 6.20 FFT FF: Encapsulado estructural. Declaracion de macropuertos.<macroports>

<macroport id="ReI">

<type>lvi</type>

<array>RADIX</array>



</property>

</macroport>

<macroport id="ImI">

<type>lvi</type>




</property>

</macroport>

<macroport id="ReO">

<type>lvo</type>




</property>

</macroport>

<macroport id="ImO">

<type>lvo</type>




</property>

</macroport>

<net id="clock">

<mport id="ReI" signal="clock" />

<mport id="ImI" signal="clock" />

<mport id="ReO" signal="clock" />

<mport id="ImO" signal="clock" />

</net>

<net id="enable">

<mport id="ReI" signal="enable" />

<mport id="ImI" signal="enable" />

<mport id="ReO" signal="enable" />

<mport id="ImO" signal="enable" />

</net>

</macroports>

tectura FF se componen de modulos de procesado similares. Estos modulos ya han sidodisenados e implementados para la arquitectura FB a lo largo del apartado anterior, por loque estan disponibles a traves de la biblioteca de componentes, para incorporarlos a estaarquitectura, como se vera mas adelante. Incluso aunque las estructuras a implementarresulten completamente diferentes, como es el caso del modulo que implementa el almace-namiento de muestras, es posible reutilizar disenos ya incluidos en la arquitectura anterior,aunque es este caso se traten de componentes de mas bajo nivel.

En este apartado se realizara una breve descripcion de la arquitectura FF, haciendohincapie en las diferencias que presenta frente a la implementacion de la arquitectura FB.Para ello, durante este apartado se comenzara describiendo el codigo dHDL (encapsuladoe implementacion) de nivel superior de la jerarquıa que contiene la descripcion estructuralde la arquitectura FF. Despues se describiran los principales componentes o modulos segunse va bajando en el nivel de la jerarquıa.

6.3.2.1. Arquitectura FF: Encapsulado Estructural

Desde el punto de vista de configuracion, el encapsulado de la arquitectura FF pre-senta los mismos parametros descritos en la arquitectura FB, con lo que los parametrosdeclarados en el Ejemplo 6.3 son tambien validos para esta arquitectura y ademas con elmismo significado. De manera similar, los atributos descritos en el Ejemplo 6.4 tambienpueden utilizarse para informar de caracterısticas de esta arquitectura.

La gran diferencia entre ambos encapsulados se encuentra a la hora de declarar losmacropuertos de la implementacion. La arquitectura FB unicamente presenta dos macro-puertos para la entrada de muestras (uno para la parte real y otro para la parte ima-ginaria), mientras que la arquitectura FF requiere de RADIX pares de macropuertos. Deigual modo, la arquitectura FB declaraba dos puertos para la salida de datos, mientrasque la arquitectura FF requiere de RADIX pares de puertos para la salida del resultado dela transformacion.


Ejemplo 6.21 FFT FF: Estructura de la estructura....

variable data_real[RADIX];

variable data_imag[RADIX];

...

entity counter =

logic.counter;

entity buffer =

logic.buffer;

entity butterfly =

fft.butterfly.dif;

entity memory =

fft.ffwd.memory.datamem;

entity twiddle =

fft.ffwd.twiddle.rotator;

counter.generics (

WIDTH = Log2(FFT_POINTS) );

component control_counter =

counter->generate;

port master_control_count :

control_counter->port("O");


...



...

memory.generics (...);

...

c_memory.ports;

...

butterfly.generics (...);

...

c_butterfly.ports;

...


...

twiddle.generics (...);

...

c_twiddle.ports;

...

}


} // end while

variable index = 0;


ReO[index] = data_real[index];

ImO[index] = data_imag[index];

index = Inc(index);

}

En el Ejemplo 6.20 se muestra la declaracion de los puertos para la arquitectura FF.La diferencia respecto a la declaracion en la arquitectura FB (Ejemplo 6.5), es que ahoralos puertos se declaran en array. Bajo un mismo identificador de macropuerto se declaranRADIX-puertos con las mismas caracterısticas.

6.3.2.2. Arquitectura FF: Descripcion de la estructura

La descripcion de la arquitectura se realiza de una manera jerarquica, y de formasimilar a la realizada con la arquitectura FB. En la parte superior de la jerarquıa seimplementa la descripcion de la estructura de la arquitectura completa, indicando dondey como se utilizaran los principales modulos de la implementacion: memoria, butterflyy rotador.

La estructura, descrita a este nivel resultara muy similar a la descrita en la arquitecturaFB en el apartado 6.3.1.2, cuya generacion se dirige utilizando las estructuras de controldHDL. Una de las diferencias entre ambas arquitecturas se presenta a la hora de realizar elinterconexionado: ahora no se realimentan las muestras desde la mariposa a los bloques dememoria, sino que se conectan directamente con los rotadores, como ya se aprecio durantela presentacion de ambas arquitecturas y su representacion en las Figuras 6.5 y 6.7.

En el Ejemplo 6.21 se muestra un extracto del codigo dHDL donde se realiza la descrip-cion la estructura: un bucle while genera y conecta las sucesivas etapas, mientras que encada etapa se configuran y generan los modulos basicos de la implementacion. El Ejemploes casi identico a los presentados en el apartado 6.3.1.2 al describir la estructura de laarquitectura FB, salvo por ligeras diferencias:

Aunque parte de los componentes basicos de biblioteca utilizados son identicos(counter, buffer), los componentes memory y twiddle son implementaciones es-pecificas de la arquitectura FF (fft.ffwd). Sin embargo el componente butterfly


Ejemplo 6.22 Modulo de memoria: Estructura para la arquitectura FF.

entity datacell =

fft.memory.datacell;

datacell.generics (

WIDTH = Mult(WIDTH, 2),

DATUM = MEM_BLOCKS_DATUM,

MEM_TYPE = MEMORY_TYPE,

BRAM_TH = MEMORY_BRAM_TH );

component mem_datacell =

datacell->generate;

...

variable index = 0;

while ( index < RADIX ) { // column-while

...

variable jndex = 0;

while ( jndex < RADIX ) { // row-while

...

mem_datacell.ports ( ... );

...

dataint_mem[jndex] = mem_datacell->port("O");

jndex = Inc(jndex);

}

} // end while

es identico en ambas implementaciones (fft.butterfly).

Durante la descripcion de la arquitectura FB se utilizo un par de variables dHDLpara seguir el desarrollo del datapath durante la implementacion. En el caso de laimplementacion FF, al tener que trabajar con RADIX muestras en paralelo, se handeclarado variables similares (data real y data imag), pero esta vez en array.

En esta implementacion, durante la descripcion de los componentes de la etapa, noes necesario conectar la salida del componente butterfly con la memoria, por loque su descripcion resulta mas sencilla: primero se introduce el modulo de memoria,luego el butterfly y finalmente el rotador.

6.3.2.3. Modulo de Memoria

De nuevo, el modulo que describe la estructura de memoria de la arquitectura FF seencuentra definido en un fichero fuente dHDL, y por lo tanto estara compuesto de unencapsulado estructural y de la propia descripcion en dHDL. El encapsulado estructuralde este modulo declara los parametros necesarios para configurar la memoria de la arqui-tectura FF, y que de nuevo son similares a los de la arquitectura FB, salvo que ahora nose necesita la anchura de bit para muestras realimentadas (no existe realimentacion). Delmismo modo, los atributos declarados resultan similares, numero de datos totales, numerode bloques, etc., aunque en esta implementacion al tratarse de una estructura diferente,sus valores de inicializacion seran diferentes.

Como ya se indico en el apartado 6.2.2.4, la estructura de memoria a generar se compo-ne de una matriz de RADIX×RADIX-bloques de memoria. Al igual que en la arquitecturaFB, la implementacion de estos bloques de memoria se realiza en otro componente, ocul-tando los detalles de implementacion de mas bajo nivel, como es el tipo de memoria quese utiliza (en bloque o distribuida).

El Ejemplo 6.22 muestra parte de la descripcion de este modulo de memoria. En ladescripcion no se definen los elementos de bajo nivel de memoria, sino que se utilizaotro componente, datacell, ya incorporado a la biblioteca (fft.memory) de componentesdurante la implementacion de la arquitectura FB. Durante la configuracion de este bloquese le pasan, entre otros, los parametros que seleccionan el tipo de memoria a utilizar.

El bloque datacell ya configurado se utiliza dentro de un doble bucle while (a dife-rencia del bucle sencillo implementado en la arquitectura FB). El primer bucle permitegenerar la estructura de columnas, mientras que el segundo bucle inserta a cada uno de


estos modulos por iteracion, en su correspondiente posicion en la lınea dentro de la matriz.

En este componente, de modo similar a como se implementa el modulo de memoriade la arquitectura FB en el apartado 6.3.1.3, se realiza la interconexion con los puertosde entrada y salida, ademas de la generacion de las senales de control para cada posiciondentro de la matriz: los bits menos significativos del puerto de direcciones se utilizaran paradireccionar los bloques de bajo nivel de memoria, mientras que los bits mas significativosse utilizaran para seleccionar a que bloques de memoria escribir y desde que bloques dememoria leer, para lo que se recurre a llamadas a funciones dHDL y a las inserciones decodigo que proporciona el lenguaje dHDL como las ya vistas en el Ejemplo 6.11.

6.3.2.4. Modulo Butterfly

Los modulos que componen la implementacion se han de adaptar a las caracterısti-cas de la arquitectura, y aunque en ultima instancia se utilizaran los mismo modulos demenor nivel disponibles en la biblioteca de componentes, los modulos de mas alto nivelde la jerarquıa presentan componentes dHDL diferentes. Sin embargo, en el caso de laimplementacion de la mariposa es posible reutilizar el mismo core en ambas arquitecturas,como ya se indico al presentar la descripcion de la estructura superior con el Ejemplo 6.21.

Por lo tanto, el codigo descrita en el apartado 6.3.1.4 es comun para ambas arqui-tecturas. Puesto que los parametros son similares en ambas implementaciones, desde elpunto de vista del componente no existe ninguna restriccion que impida utilizarlo o haganecesario modificarlo para adaptarlo a la presente arquitectura.

6.3.2.5. Modulo Rotador

De nuevo el encapsulado estructural que describe la interfaz del componente es similaral realizado para el componente de la arquitectura FB: mismos parametros y atributos. Laprincipal diferencia se encuentra en la declaracion de los macropuertos: en la arquitecturaFB solo es necesario declarar una pareja de puertos para la entrada de muestras y otrapareja de salida. En el componente de la arquitectura FF se procesan en paralelo RADIX

muestras y es necesario que se declaren RADIX parejas de puertos para la entrada demuestras y la misma cantidad de pares para la salida. La declaracion de macropuertospara este modulo resulta similar a la realizada en el top de la arquitectura del Ejemplo6.20.

Desde el punto de vista de la implementacion, el codigo dHDL que describe la estruc-tura de rotadores se comportara igual que en la arquitectura FB, permitiendo seleccionarentre los diferentes rotadores y generando la memoria de coeficientes adecuada a la etapade la implementacion, pero en este caso generara un array de rotadores para el procesadode muestras en paralelo.

El Ejemplo 6.23 muestra una descripcion muy similar a la de la arquitectura FB en elEjemplo 6.18, para la seleccion del tipo de rotador. En el caso de la arquitectura FF elprimer canal de datos (asociado a index=0) no es necesario rotarlo, con lo que se instanciaun buffer para sincronizar la salida del resto de canales, que sı se rotan y por lo tanto tienenasociada una latencia. Para ello, primero se seleccionan y generan los rotadores asociadosa los demas canales (bucle while interno), ademas de utilizar una variable, latmax, para


Ejemplo 6.23 Modulo rotador: Seleccion del rotador.variable latmax = 0;

if ( ROTATOR_TYPE="cordic" ) {

entity cordic =

arith.cordic.online.fixrots;

entity twiddlemem =

fft.ffwd.twiddle.cordicmem;

...

variable index = 1;


...

cordicrot = cordic->generate;

latmax =

cordicrot->attribute("LATENCY");

...

}

....

} else {

entity mult =

arith.complexmult;

entity twiddlemem =

fft.ffwd.twiddle.multmem;

...

}

...

entity buffer =

logic.buffer;

buffer.generics (

...,

DEPTH=latmax,

... );

...

almacenar la latencia asociada a estos componentes. Una vez generados los rotadores seutiliza esta variable para configurar el valor del buffer que se utilizara para el primer canalde datos.

6.4. Resultados de la generacion de las arquitecturasdescritas

A la hora de realizar la implementacion de las diferentes arquitecturas, el disenadordebe conocer aspectos del algoritmo, detalles de la arquitectura e incluso las caracterısticasde la plataforma sobre la que se implementara el core, para en la medida de lo posibleofrecer una implementacion flexible, pero tambien lo mas optima posible.

Por lo tanto, aunque el disenador del core es la persona que mejor conoce la implemen-tacion, le resultara difıcil, si no imposible, indicar que arquitectura y juego de parametrosson los mas adecuados para una aplicacion especıfica: una vez realizada la descripcion delas arquitecturas necesita verificar las diferentes implementaciones, y en que resultados enel espacio de diseno (area, prestaciones, etc.) se obtienen.

De las arquitecturas descritas en el capıtulo se espera que ofrezcan diferentes puntosdel espacio de diseno, pero es durante la verificacion de la arquitectura donde el disenadorcomprobara si realmente se obtienen los resultados esperados, y cuales son los factores quelimitan o diferencian a las diferentes arquitecturas.

La implementacion en dHDL ha permitido reutilizar, adaptando a las necesidadesde cada arquitectura, componentes de nivel inferior de la jerarquıa, simplificar el proce-so de descripcion estructural de ambas arquitecturas, e incorporar un amplio conjunto deparametros. A partir de la especificacion en dHDL se podran generar diferentes implemen-taciones con diferentes juegos de parametros que permitan determinar el efecto que tienensobre la arquitectura, pero tambien comparar de forma cuantitativa ambas arquitecturas.

Finalmente, para poder reutilizar estos disenos, no solo es importante la implemen-tacion en sı, sino que resultara de interes que toda la informacion obtenida al verificary estudiar ambas arquitecturas se pueda incorporar junto al core, sobre todo si permitecomparar entre diferentes alternativas. Con los lenguajes de descripcion convencionales

6.4 Resultados de la generacion de las arquitecturas descritas 147

toda esta informacion se suele acompanar de manera externa a la implementacion, perocon la descripcion en dHDL se ofrece la posibilidad de que el disenador incorpore partede esta informacion a la implementacion y que pueda ser utilizada para la automatizaciondel proceso de exploracion del espacio de diseno.

En el presente apartado primero se indica como realizar parte del estudio y compara-tiva de las arquitecturas. Posteriormente, con la informacion obtenida se mostrara comoincorporarla junto con la propia implementacion de manera que pueda utilizarse de unamanera rapida.

6.4.1. Verificacion y resultados experimentales

Durante la descripcion del algoritmo y arquitecturas se ha mencionado que se esperaque la arquitectura FF presente mejores prestaciones frente a la arquitectura FB, mientrasque esta ultima arquitectura debe resultar mucho mas eficiente en terminos de area. Laimplementacion con dHDL de ambas arquitecturas permite realizar una comparativa deambas soluciones frente a los cambios que se realicen de un conjunto de parametros, entreellos:

Desde el punto de vista del algoritmo, el parametro mas relevante es la longitud dela transformada. Desde el punto de vista de las arquitecturas diferentes longitudesimplicaran un diferente gasto en recursos. En el caso de los disenos realizados, lalongitud de la transformada se obtiene mediante la combinacion de dos parametros(RADIX y STAGES).

Parametros que configuran la anchura de bit de las muestras de entrada y que con-trolan el crecimiento en bits en los diferentes modulos.

Otros parametros, como la seleccion de los componentes de bajo nivel, permiten rea-lizar configuraciones mas generalistas (solo logica) que pueden utilizarse en diferentesplataformas aunque con un mayor coste, pero tambien adaptar las arquitecturas yobtener mejores caracterısticas.

A la hora de realizar un estudio de las arquitecturas no se pretende cubrir todaslas posibilidades que ofrecen, sino que se realizara un estudio que permita obtener losresultados mas relevantes:

Al estudiar la longitud de la transformada se verificara la influencia del radix y elnumero de etapas en la implementacion.

Al estudiar la influencia de la anchura de bit de la muestra y su escalado. Se hanseleccionado anchuras de 8 y 16 bits para las muestras de entrada, tanto para im-plementaciones sin truncamiento como con truncamiento.

Para comparar ambas arquitecturas se han configurado para utilizar componentesde bajo nivel identicos. Por ejemplo, como elemento rotador se ha seleccionado elalgoritmo CORDIC, cuya implementacion se realiza mediante logica.


Tabla 6.3: Arquitectura FF: 8bits, R=2.

S NFFT-FF : 8 bits - Radix-2 - Con truncamiento

Area Latencia Prestaciones

slices BRAM usec MHz MSPS

4 16 1133 0 0.225 254 507

6 64 1816 0 0.640 236 472

8 256 4533 0 2.031 227 454

9 512 8683 0 4.652 184 368

9 512 4471 8 3.754 228 456

10 1024 15440 0 8,790 186 372

10 1024 3862 12 7,182 228 455

S NFFT-FF : 8 bits - Radix-2 - Sin truncamiento



4 16 1354 0 0.256 246 492

6 64 2475 0 0.704 236 471

8 256 6401 0 2.154 227 454

9 512 12478 0 4.482 199 398

9 512 7418 8 3.894 227 454

10 1024 20873 0 9,032 186 372

10 1024 6627 12 7,380 228 455





2 16 1235 0 0.103 244 975

3 64 2830 0 0.271 244 975

4 256 4586 0 0.810 236 943

5 1024 13031 0 2.929 223 890




2 16 1532 0 0.112 242 967

3 64 3815 0 0.300 240 960

4 256 6703 0 0.861 236 943

5 1024 17751 0 3.030 222 887

Se buscaran resultados que permitan caracterizar a las arquitecturas en diferentesaspectos:

Area, como el numero de slices y BRAM utilizadas.

Latencia, como el tiempo requerido en procesar una secuencia.

Prestaciones, tanto en frecuencia de reloj (MHz) como en throughput (Msamples/s).

Consumo.

Para obtener estos resultados se utilizara una FPGA de la familia Virtex-II de Xi-linx: XC2V4000-FF1152 1. Tras configurar y generar las correspondientes arquitecturas seobtendra un core VHDL que se implementa utilizando las herramientas de desarrollo deXilinx. Aunque se pueden obtener estimaciones de algunos resultados tras la sıntesis (areay prestaciones), otros resultados requieren de la implementacion completa de los disenos(post-place and route). Para la implementacion de las arquitecturas no se han impuesto nirestricciones de reloj ni de area a los disenos.

En las Tablas 6.3, 6.4 y 6.5 se recogen los resultados en area y prestaciones de la arqui-tectura FF, con muestras de entrada de 8 bits (con y sin truncamiento), para diferentesradix: 2, 4 y 8. Algunas de las conclusiones que se pueden extraer:

El area para las implementaciones radix-2 y radix-4 es muy similar para transfor-madas de la misma longitud, mientras que para radix-8 se aprecia un considerableaumento. El aumento de area de cada etapa de la implementacion radix-4 (frente a

1Los resultados se han obtenido para esta FPGA en concreto al utilizarse la placa de prototipado XilinxVirtex-II Development Kit de AVNet.





2 64 4716 0 0.170 230 1840

3 512 10988 0 0.761 230 1840




2 64 5920 0 0.275 153 1224

3 512 15009 0 1.586 116 928

6.4 Resultados de la generacion de las arquitecturas descritas 149


S NFFT-FB : 8 bits - Radix-4 - Con truncamiento



2 16 638 0 0.128 274 274

3 64 1128 0 0.365 274 274

4 256 1903 0 1.128 274 274

5 1024 2589 3 3.996 274 274

S NFFT-FB : 8 bits - Radix-4 - Sin truncamiento



2 16 806 0 0.139 267 267

3 64 1604 0 0.405 262 262

4 256 2914 0 1.254 256 256

5 1024 4328 3 4.442 251 251

Tabla 6.7: Arquitectura FB y FF: 16 bits, R=4.

S NFFT-FB : 16 bits - Radix-4 - Con truncamiento



2 16 1342 0 0.171 251 251

3 64 2452 0 0.462 251 251

4 256 4086 0 1.327 251 251

5 1024 7956 0 4.486 251 251




2 16 3578 0 0.149 235 940

3 64 7591 0 0.362 235 940

4 256 12034 0 0.932 235 940

5 1024 27702 0 3.996 213 852

la radix-2) se compensa con el menor numero de etapas necesarias para realizar latransformada completa. Con radix-8 la complejidad de los modulos que implemen-tan cada etapa (sobre todo la mariposa) no se compensa con un menor numero deetapas.

La frecuencia de reloj es similar entre la implementacion en radix-2 y radix-4, conlo que el mayor paralelismo de la implementacion en radix-4 permite que mejorensus prestaciones (throughput). En radix-8 la complejidad de interconexionado de losdiferentes modulos, sobre todo la estructura de memoria, provoca la bajada de lafrecuencia de reloj respecto a las anteriores (sobre todo en el caso de implementa-ciones sin truncamiento), aunque su mayor paralelismo en el procesado aun permiteque se obtengan mejores prestaciones.

De los resultados anteriores se aprecia que la implementacion en radix-4, de manerageneral, ofrece ventajas respecto a radix-2 y radix-8: minimiza el area y maximiza lasprestaciones. Sin embargo, las restricciones que imponga la aplicacion pueden conducira que se la transformada se implemente con otro radix, por ejemplo, aplicaciones dondepriman las prestaciones frente al gasto en area.

Estas conclusiones son extensibles a la arquitectura en FB. En este caso, la implemen-tacion en radix-8 no presenta una mejora de prestaciones por mayor paralelismo (en laarquitectura FB un mayor radix solo permite una reduccion en el numero de etapas). Losdatos de la implementacion en radix-4 de la arquitectura FB se recogen en la Tabla 6.6.

Estos resultados permiten comparar ambas arquitecturas. Como era de esperar la ar-quitectura FB siempre requiere de menor area para implementar una transformada deigual longitud que la FF. La frecuencia de reloj es ligeramente superior en la arquitecturaFB, pero de nuevo el mayor paralelismo de la arquitectura FF le permite ofrecer unasprestaciones superiores.

En la Tabla 6.7 se ofrecen los resultados de ambas arquitecturas, con radix-4, 16bits para las muestras de entrada y con truncamiento. Los resultados de prestaciones(en frecuencia de reloj y throughput) son similares a los de las implementaciones conentradas de 8 bits (la pequena bajada de prestaciones se debe al ligero aumento del retardocombinacional de los operadores).


Figura 6.12: Area prestaciones de las arquitectura FF y FB.

Figura 6.13: Consumo de las arquitectura FF y FB.

Finalmente, en la Figura 6.12 se representan graficamente los resultados que resumenlas diferentes implementaciones enmarcadas en el espacio de diseno area-prestaciones.

Las herramientas de desarrollo de Xilinx permiten, ademas de caracterizar las imple-mentaciones en area y prestaciones, realizar una estimacion del consumo. Para ello se hanseleccionado dos longitudes de transformada (64 y 1024 puntos) y se han a caracterizadoutilizando diferentes frecuencias de reloj. Un resumen del resultado se ha recogido en laFigura 6.13. El consumo de una implementacion FF de 64 puntos es similar al consumode una implementacion FB de 1024 puntos.

6.4.2. Comparativa con otras alternativas

En este apartado se comparan las implementaciones obtenidas a partir de las arqui-tecturas especificadas en dHDL, con otras implementaciones de FFT generadas a partirde herramientas. La primera alternativa es la obtenida a partir de la herramienta de ge-neracion de IPs de Xilinx [Xild], la segunda alternativa a comparar es la obtenida con laherramienta de generacion SPIRAL [PMJ+05], que se basa en una arquitectura diferen-te, pero permite configurar el grado de paralelismo de manera similar a las arquitecturasespecificadas en este capıtulo.

Para comparar entre las alternativas, se han generado implementaciones de 1024 pun-tos, 16 bits para las muestras de entrada, y realizando truncamiento en las diferentesetapas. En la Tabla 6.8 se muestran los resultados al comparar el core Xilinx, dos imple-


Tabla 6.8: Comparacion alternativas FFT de 1024 puntos y 16 bits, Radix-4.

SlicesBRAM Mult18x18

TSlices MHz MMSec kS/SliceNum EqSlices Num EqSlices

Xilinx 2744 7 5950 24 7680 16374 214 214 13.070

SPIRAL P4 TH2 1509 64 54400 16 5120 61029 167 668 10.946

SPIRAL P4 TH128 3287 16 13600 16 5120 22007 167 668 30.354

FFT-FF 21707 0 0 0 0 27702 213 852 30.756

FFT-FB 7956 0 0 0 0 7956 251 251 31.549

mentaciones de la herramienta de Spiral y la implementacion de las arquitecturas descritasen el capıtulo.

Una caracterıstica al comparar alternativas es la diferente utilizacion que hacen de losrecursos de la FPGA. Todas las implementaciones hacen uso de los slices para implementarfunciones logicas, que puede dar una medida general del area, pero el uso de componentesespecıficos como bloques de memoria o multiplicadores puede conducir a un ahorro en elarea gastada en slices. En cuanto a los resultados en prestaciones, las implementaciones nosolo muestran una diferente frecuencia de reloj, sino que el grado de paralelismo tambieninfluye en los resultados.

Para uniformizar los resultados se han implementado componentes equivalentes a losintegrados en logica distribuida. Ası un multiplicador de 16 × 16, como el requerido porla transformada requiere de unos 350 slices para su implementacion, mientras que cadabloque de memoria requiere de un gasto de 850 slices. Con estos valores se puede obtenerel gasto equivalente y el total de las arquitecturas si solo se implementan utilizando logicadistribuida. Para uniformizar prestaciones se ha definido el cociente entre las prestacionesde la arquitectura y el area requerida.

La implementacion de Xilinx hace un uso intensivo de los componentes integrados en laFPGA, con el consiguiente ahorro en slices, pero si se observa el area equivalente en logicadistribuida, esta crece significativamente. Lo mismo sucede con las implementaciones deSpiral. Si se comparan las alternativas utilizando la metrica prestaciones/area definida,las implementaciones presentadas en el capıtulo son las que mejor provecho sacan deldispositivo.

6.5. Conclusiones

En el capıtulo se han descrito dos arquitecturas para el procesado de altas prestacionesy tiempo real de la FFT, utilizando el lenguaje dHDL para su especificacion. Primerose ha presentado el algoritmo prestando especial atencion a los elementos hardware quecomponen las implementaciones, para despues explicar en detalle las peculiaridades deldiseno de los principales modulos y de las propias arquitecturas a implementar.

Una de las caracterısticas de las arquitecturas seleccionadas es que estan enfocadasa aplicaciones que requieren de un procesado continuo y a la vez requieren de unas al-tas prestaciones. Ademas, aunque son arquitecturas similares, presentan puntos opuestosdentro del espacio de diseno area-prestaciones.

La descripcion en dHDL de cada arquitecturas permite reutilizar muchos de los modu-los que se han implementado para una de ellas, e incluso aprovechar funciones aritmeticas


y logicas disponibles en una biblioteca de componentes. Para ello, durante el diseno de loscomponentes de la biblioteca se ha incorporado de manera sencilla el conjunto suficientede parametros que permita adaptarlos a las diferentes arquitecturas.

Durante el diseno de los componentes de mas alto nivel de la jerarquıa el lenguajedHDL permite de una manera sencilla y flexible realizar una descripcion orientada a lageneracion de la estructura, simplificando el proceso de instanciacion de componentes ysu interconexionado. Ademas, el proceso de generacion no se realiza unicamente desdela parte superior de la jerarquıa a los elementos de mas bajo nivel, sino que permite,ademas de instanciarlos, obtener informacion desde sus atributos para adaptarlos al restode componentes.

Ambas arquitecturas han sido disenadas con un conjunto amplio de parametros, queabarcan desde la modificacion de la propia funcion hasta aspectos de implementacion debajo nivel, que permiten adaptar las arquitecturas a la plataforma sobre la que se imple-mente. La descripcion con dHDL no solo permite un alto grado de parametrizacion de lasarquitecturas, sino tambien permite obtener informacion de la implementacion generadapor medio de los atributos, como se vera en el siguiente capıtulo.

A partir de las descripciones dHDL se ha realizado un estudio experimental, que abarcauna amplia zona del espacio de diseno area-prestaciones, y que ha mostrado que la calidadde las implementaciones obtenidas es equiparable a implementaciones comerciales.

Capıtulo 7

Soporte a la exploracion del espaciode diseno

7.1. Introduccion

El coste de caracterizar un diseno es muy alto, pero ademas si el diseno es ademas muyparametrizable, puede resultar inviable cubrir todo el conjunto de alternativas que puedeofrecer. Sin embargo, que el core vaya acompanado de esta informacion resulta de muchautilidad si el objetivo es que se pueda reutilizar en un futuro.

Una manera de incorporar esta informacion junto con el core es implementar un con-junto de arquitecturas representativas y que proporcionen resultados particulares desde elpunto de vista hardware, por ejemplo area-prestaciones, y acompanar junto con la docu-mentacion del core algunas tablas de resultados, como las vistas en el capıtulo anteriorpara la FFT, de modo que permitan hacerse una idea de caracterısticas como area, pres-taciones o consumo. Este proceso no es mas que la exploracion del espacio de diseno, queno solo describe caracterısticas de la implementacion sino que incluso permite compararentre alternativas.

Otra posibilidad para incorporar esta informacion es implementar estimadores de lascaracterısticas para un nuevo conjunto de parametros. Frente a un conjunto de valores fijos,permiten evaluar como afecta la configuracion del core en sus caracterısticas. Ademas, elcoste de realizar una estimacion es muy inferior al de implementar el diseno, por lo quelos estimadores permiten realizar de una manera mas rapida una exploracion del espaciode diseno.

dHDL ofrece la posibilidad de incorporar el proceso de estimacion junto con el propioproceso de generacion del core. La generacion es un proceso top-down: la descripcion delcore se encuentra en un fichero fuente dHDL que se corresponde con el nivel superior de lajerarquıa, y en la que se configuran e instancian otros componentes dHDL de nivel inferior.Estas nuevas descripciones a su vez configuran e instancian nuevos componentes, hastaalcanzar componentes de mas bajo nivel. Una vez generado e incorporado un componentedHDL un core, el componente dHDL desde donde se genero puede obtener informacion apartir de los atributos que tenga declarados en su encapsulado estructural, descritos en elapartado 5.2.3.

En el capıtulo 6, durante la descripcion de las arquitecturas FFT se han utilizado

154 Soporte a la exploracion del espacio de diseno

elementos del lenguaje dHDL para declarar atributos como latencia, etc., que se utilizanpara configurar otros componentes de la estructura antes de generarlos. Utilizando estacaracterıstica, los core dHDL, pueden recoger informacion desde los componentes de masbajo nivel a los componentes de nivel superior en la jerarquıa.

Al igual que la informacion de configuracion se pasa desde el componente de nivelsuperior de la jerarquıa a los componentes del nivel mas bajo, la informacion recogida enlos atributos de un componente puede devolverse desde los niveles inferiores al componentede jerarquıa superior, como ya se explico en el apartado 4.4.2.5. Mediante este mecanismose pueden incorporar e implementar estimadores durante el proceso de generacion. Loscomponentes dHDL de mas bajo nivel normalmente se corresponden con elementos omodulos sencillos desde el punto de vista hardware, por ejemplo, sumadores, multiplexores,registros, etc. Estos componentes se pueden caracterizar y definir atributos relativos alespacio de diseno mediante una funcion de sus parametros de configuracion. La informacionde estos modulos se recoge en el nivel inmediatamente superior, que a su vez la puedeprocesar y corregir para ofrecerla como una caracterıstica propia.

En el capıtulo 6 la descripcion en dHDL de las arquitecturas FFT permitio realizarun estudio experimental de sus caracterısticas de espacio de diseno, ası como su variacioncon diferentes parametros de configuracion. En este capıtulo se presenta como incorporartoda esta informacion en la propia descripcion, y que se genere con el propio core. Seexplicara como generar estimadores basados en los componentes de mas bajo nivel de labiblioteca, y como generar nuevos estimadores en funcion de los anteriores.

Incluir informacion de espacio de diseno con la propia implementacion ayuda a la horade evaluar la implementacion entre diferentes alternativas de disenos. Pero el proceso deseleccion de un core para incluirlo como parte de un sistema requiere que cumpla con todoun conjunto de criterios: empezando por ser una implementacion de la funcion deseada,aunque normalmente tambien se requieren otros requisitos. Es en este punto donde espreciso comparar y evaluar entre alternativas.

Ahora comenzaremos por ver como el haber utilizado dHDL en la especificacion sirvecomo base para implementar estimadores junto con la descripcion del core. Ademas, duran-te el capıtulo 5 se definio el encapsulado funcional que permite declarar todo un conjuntode caracterısticas relevantes para la implementacion de una funcion. En este capıtulo, con-tinuando con el ejemplo de diseno del capitulo 6, se definira un encapsulado funcional quedescriba la funcion FFT, y se propondran empaquetados para las arquitecturas descritas.Finalmente, se mostrara como estos elementos ayudan a elegir la implementacion masadecuada durante el diseno de un receptor canalizado.

7.2. Generacion y estimacion de atributos

En este apartado se describe como a partir de las especificaciones en dHDL de lasarquitecturas FFT presentadas en el capıtulo 6, se van a desarrollar e integrar estimadoresde sus caracterısticas, en concreto estimadores de area y consumo. Ambas arquitecturasse componen de un conjunto de fuentes dHDL, permitiendo su configuracion a traves delarchivo de jerarquıa superior. Con un juego de parametros se puede implementar el coredescrito, generando una descripcion en VHDL.

7.2 Generacion y estimacion de atributos 155

Otras alternativas, por ejemplo [PMJ+05], tambien implementan estimadores de areade las arquitecturas generadas. Lo hacen a partir de los resultados obtenidos al imple-mentar el diseno con diferentes parametros y calcular la estimacion con una funcion delos parametros que minimice el error obtenido a partir de los resultados. dHDL tambienpermite la implementacion de este tipo de estimadores, mediante el uso de los atributosy funciones del lenguaje, y tambien proporciona un metodo de implementar estimadoresque obtengan informacion del propio proceso de generacion seguido, lo que simplifica suimplementacion. Este ultimo metodo sera el que se describa en el presente apartado.

Con dHDL, los componentes de biblioteca de mas bajo nivel implementan estimadoresmediante este tipo de funciones. Al ser componentes sencillos, la funcion de estimaciontambien resulta sencilla de implementar y de calcular. Para transportar y modificar el valorde estos estimadores a lo largo de la jerarquıa del diseno, se utilizan los atributos de dHDL,que permiten agregar estimadores en el flujo de generacion del core, y que proporciona aldisenador un mecanismo rapido y sencillo de incorporar la informacion obtenida durantela implementacion del componente.

A modo de resumen, las principales ventajas de utilizar este mecanismo para imple-mentar estimadores son:

Por una parte, se aprovecha la informacion obtenida a lo largo de la jerarquıa muydependiente de la estructura que se genera y de los parametros que la configuran.

Tambien se aprovecha el conocimiento del disenador obtenido desde los propios re-sultados experimentales, ademas de reutilizar la estimacion en componentes de bi-blioteca ya caracterizados.

La funcion obtenida resulta sencilla de implementar y calcular, ası como con un bajomargen de error, frente a alternativas convencionales.

El tiempo y recursos requeridos para obtener la estimacion se corresponden con elde la propia generacion del core, que resulta mucho menos costoso que su propiaimplementacion.

En lo que resta de apartado primero se describira con detalle el propio proceso degeneracion y estimacion, descrito en [SGLVLB06], ası como la implementacion de esti-madores basicos de area de las arquitecturas FFT, en funcion de los estimadores de loscomponentes mas basicos de la arquitectura. Posteriormente se describira como se puedengenerar nuevos estimadores utilizando los anteriores o como mejorar la estimacion a partirde resultados experimentales.

7.2.1. Estimacion de area

En la Figura 7.1 se recoge el doble proceso de generacion y de estimacion para laespecificacion de las arquitecturas FB y FF. La descripcion de la estructura general y lade las etapas en particular se realiza en el componente de nivel superior, como se vio en elapartado 6.3.1.2 para la arquitectura FB y en el apartado 6.3.2.2 para la arquitectura FF.El proceso es descrito en la Figura 7.1 con un doble flujo (de arriba a abajo y de abajo aarriba) como sigue:


Figura 7.1: Proceso de generacion y estimacion de area en una FFT.

1. Se comienza con la configuracion de los parametros del componente de nivel superior.

2. Al generar la estructura descrita en el componente superiores, se instancian, confi-guran y generan los componentes de nivel inferior. En el caso de las arquitecturasFFT se corresponden con memoria, mariposa y rotador. Estos componentes a su vezutilizan nuevas componentes de la biblioteca.

3. El proceso de configuracion y generacion continua hasta el nivel mas bajo de lajerarquıa, que se compone de elementos sencillos como sumadores, registros, multi-plexores.

4. Los componentes de nivel inferior no solo proporcionan una descripcion con su funcio-nalidad, tambien proporcionan a los niveles superiores el resultado de los estimadoresbasicos a traves de los atributos del lenguaje.

5. El core se va generando como una coleccion de componentes descritos en VHDL,que se obtiene junto con los resultados de los estimadores implementados en loscomponentes del nivel intermedio.

6. El top de la jerarquıa integra los componentes de la arquitectura, pero tambien


incorpora el valor de las estimaciones que se han realizado en los niveles inferiores.

En las Figuras 6.9 y 6.11 del capıtulo 6 se mostro como los modulos que componen am-bas arquitecturas se han integrado en una biblioteca de componentes. Ambas arquitecturasutilizan tres grandes modulos: memoria, mariposa y rotador. Como se detallo durante ladescripcion de la implementacion de ambas arquitecturas, mientras que el modulo de mari-posa es identico para ambas arquitecturas, la implementacion de los modulos de memoriay rotador sera caracterıstico de cada arquitectura. Sin embargo, pese a las diferencias,ambos modulos utilizan los mismos componentes de nivel inferior: en el caso del modulode memoria los componentes de celda de memoria o los diferentes bloques (memoria detwiddles y multiplicadores) que implementan los rotadores.

La implementacion de la jerarquıa de ambas arquitecturas se realiza hasta alcanzar losmodulos de mas bajo nivel: registros, multiplexores, sumadores, etc. La implementaciondHDL de todos estos componentes se ha agrupado formando una biblioteca, de modo queno solo ofrecen la implementacion de la funcion pedida, sino que incorporan estimadoressencillos: LUTs, FFs, BRAMs, ... En el Ejemplo 7.1 se muestra la declaracion en el encap-sulado estructural de uno de estos modulos de los atributos AREA LUTS y AREA FFS que seutilizan para implementar los estimadores de area. Durante la implementacion del modulose asignara a estos atributos un valor calculado a partir de las opciones de configuraciondel componente.

Ejemplo 7.1 Declaracion de atributos de area en el encapsulado estructural....

<attribute id="AREA_LUTS">

<type>int32</type>


</attribute>

<attribute id="AREA_FFS">

<type>int32</type>


</attribute>

...

Los componentes de bajo nivel de la biblioteca incorporan atributos como los delEjemplo 7.1, AREA FFS y AREA LUTS, que implementan estimadores de area sencillos, apartir de valores calculados con sus propios parametros. Los componentes de nivel superiorque los instancian pueden tomar el valor de estos atributos para agregarlos a su propiaestimacion, a la vez que al tener una vision mas global del diseno decidir si modificarloso corregirlos antes de tenerlos en cuenta. Tambien desde los elementos de bajo nivel sepuede estimar el uso de componentes especiales como bloques de memoria o multiplicadoresintegrados.

Todos estos modulos de la biblioteca son utilizados de manera intensiva durante laimplementacion de ambas arquitecturas FFT, de modo que los componentes de nivel in-mediatamente superior que los utilicen podran acceder, tratar e incorporar la informacionde estos atributos para generar su valor propio. En el Ejemplo 7.2 se muestra, tras in-corporar uno de estos componentes de la biblioteca a la estructura, como acceder a losatributos de area definidos para generar su propia estimacion. En el ejemplo, los atributosson leıdos y almacenados en variables dHDL, para posteriormente agregarlos a los valoresde area del componente en ese momento.


Ejemplo 7.2 Incorporacion de informacion de estimacion....


...

variable aluts = kmult->attribute("AREA_LUTS");

AREA_LUTS = Add(AREA_LUTS, aluts);

variable affs = kmult->attribute("AREA_FFS");

AREA_FFS = Add(AREA_FFS, affs);

...

Esta informacion es recogida desde los componentes de nivel inferior de la jerarquıahasta los de mas alto nivel, siguiendo el sentido ascendente de la Figura 7.1. En la parte altade la jerarquıa del diseno, la informacion de estimacion puede ser corregida o modificadapara formar nuevos estimadores, por ejemplo implementar un estimador de slices a partirde la informacion recogida de AREA FFs y AREA LUTs.

En nuestro ejemplo de la FFT, en el nivel superior de la jerarquıa hemos decididoutilizar como medida de area, no solo el numero de FFs y LUTs de la implementacion,sino el numero de slices (informacion con la que se ha caracterizado el area de las diferentesarquitecturas en el apartado 6.4.1), que para la FPGA destino tiene 2 FFs y 2 LUTs de 4entradas.

A partir de los resultados experimentales obtenidos de ambas arquitecturas se observaque el numero de slices (Rslices) siempre se encuentra entre dos lımites:

El lımite inferior de slices se corresponde con la maxima eficiencia de la herramientade sıntesis, y todos los slices se encuentran totalmente ocupados (dos FFs y dos LUTspor slice). RMIN = max(RFFs, RLUTs)/2, donde RFFs y RLUTs son los valoresexactos del numero de FFs y LUTs obtenidos con la herramienta de sıntesis.

El lımite superior de slices se corresponde con la mınima eficiencia de la herramientade sıntesis, donde en cada slice solo se ha utilizado un unico FF o una unica LUT.RMAX = RFFs +RLUTs

Figura 7.2: Lımites de estimacion y error en la aproximacion para la arquitectura FB.


Figura 7.3: Lımites de estimacion y error en la aproximacion para la arquitectura FF.

En las Figuras 7.2 y 7.3 se representa tanto el valor de slices (Rslices), como los lımitesdefinidos por RMAX y RMIN , obtenidos para un conjunto de diferentes implementacio-nes de las arquitecturas FFT-FB y FFT-FF. A partir de los valores obtenidos con estosresultados, se calcula el cociente entre el valor real obtenido y los lımites para cada imple-mentacion, generando los valores Ki

MAX = RiMAX/Ri

Slices y KiMIN = Ri

MIN/RiSlices.

A pesar de que se trata de distintas implementaciones con diferente conjunto deparametros, el valor de los cocientes Ki permanece casi constante, con lo que podemosutilizar una media de este conjunto de valores, para definir las constantes de correccionglobales KMAX y KMIN .

De nuevo, a partir de los resultados experimentales, para la arquitectura FFT-FB lasconstantes de correccion se definen como KFB

MAX = 0,42 y KFBMIN = 1,83.

Para la arquitectura FFT-FF las constantes se definen como KFFMAX = 0,49 y KFF

MIN =1,79.

Aunque el valor de las constantes es similar para ambas arquitecturas, definirlas demanera separada mejora la precision de la estimacion.

A partir de estas constantes de correccion, se obtienen dos estimadores que podemosaplicar durante el proceso de generacion y obtener los estimadores de area en slices comosigue:

SLICESMAX = (GFFs +GLUTs) ·KMAX (7.1)

SLICESMIN = max(GFFs, GLUTs)/2 ·KMIN (7.2)

donde GFFs y GLUTs es el valor de la estimacion de FFs y LUTs obtenidas tras el procesode generacion.

En el Ejemplo 7.3 se muestra como se implementa para la arquitectura FFT-FB losestimadores de slices en el top de la arquitectura. Utiliza por una parte los datos obtenidosdesde los modulos de jerarquıa inferior (AREA LUTS y AREA FFS), y por otra parte lasconstantes fijadas a partir de los datos experimentales.


Ejemplo 7.3 Implementacion de estimadores de slices para arquitectura FB...

variable K_FB_MAX = 0.42;

variable K_FB_MIN = 1.83;

...

AREA_SLICES_MAX = Mult(Add(AREA_LUTS, AREA_FFS), K_FB_MAX);

AREA_SLICES_MIN = Mult(Div(Max(AREA_LUTS, AREA_FFS), 2), K_FB_MIN);

...

7.2.1.1. Mejora de la estimacion

El procedimiento de estimacion descrito anteriormente proporciona unos buenos resul-tados en la mayor parte de los casos analizados. Sin embargo, en alguno de los casos elerror en la estimacion supera la media, lo que requiere un analisis mas detallado.

Los casos analizados se caracterizan por presentar un numero mucho mayor de FFs quede LUTs, lo que influye en como la herramienta de sıntesis los empaqueta. Para corregireste efecto se ha definido una nueva variable FLR como el cociente entre el numero deFFs y el numero de LUTs. Con esta nueva variable se puede dividir en tramos el valor deaplicacion de la constante de aplicacion.

Para el caso de la arquitectura FB se establecen dos segmentos por constante:

KFBMAX =

{0,42 FLR ≤ 0,8

0,53 FLR > 0,8KFB

MIN =

{1,83 FLR ≤ 1

1,51 FLR > 1

La arquitectura FF requiere de muchos mas recursos que la FB y necesita establecertres segmentos, para el caso de que se generen mas FFs que LUTs, el caso que se generenmas LUTs que FFs, y finalmente el caso que se encuentre equilibrado en el gasto enrecursos.

KFFMAX =

0,63 FLR < 0,9

0,49 0,9 ≤ FLR ≤ 1,5

0,36 FLR > 1,5

KFFMIN =

2,13 FLR < 1

1,79 1 ≤ FLR ≤ 1,5

1,18 FLR > 1,5

En las Figuras 7.2 y 7.3 se observa como ambas estimaciones (SLICES MAX ySLICES MIN), ya con la correccion de las constantes implementadas, se aproximana los valores experimentales de ambas arquitecturas. El Ejemplo 7.4 muestra como seimplementa en codigo dHDL para el caso de la arquitectura FB.

Ejemplo 7.4 Implementacion de estimadores de slices mejorado para arquitectura FB....

variable K_FB_MAX = 0.42;

variable K_FB_MIN = 1.83;

variable FLR = Div(AREA_FFS, AREA_LUTS);

if ( FLR > 0.8 ) {

K_FB_MAX = 0.53;

K_FB_MIN = 1.51;

}

...

AREA_SLICES_MAX = Mult(Add(AREA_LUTS, AREA_FFS), K_FB_MAX);

AREA_SLICES_MIN = Mult(Div(Max(AREA_LUTS, AREA_FFS), 2), K_FB_MIN);

...


0,00%

2,00%

4,00%

6,00%

8,00%

10,00%

12,00%

14,00%

16,00%

18,00%

8_FB_2

_0

8_FB_3

_0

8_FB_4

_0

8_FB_5

_0

8_FB_2

_1

8_FB_3

_1

8_FB_4

_1

8_FB_5

_1

16_F

B_2_0

16_F

B_3_0

16_F

B_4_0

16_F

B_5_0

16_F

B_2_1

16_F

B_3_1

16_F

B_4_1

16_F

B_5_1

8_FF_2

_0

8_FF_3

_0

8_FF_4

_0

8_FF_5

_0

8_FF_2

_1

8_FF_3

_1

8_FF_4

_1

8_FF_5

_1

16_F

F_2_0

16_F

F_3_0

16_F

F_4_0

16_F

F_5_0

16_F

F_2_1

16_F

F_3_1

16_F

F_4_1

16_F

F_5_1

Architecture

%E

rro

r

Error FFs Error LUTs

3,38%

1,94%

Figura 7.4: Error en la estimacion de FFs y LUTs para diferentes implementaciones. ArquitecturasFFT-FB y FFT-FF.

7.2.1.2. Resultados

La Figura 7.4 muestra el error de la estimacion de FFs y LUTs (comparado con elvalor de sıntesis) para diversas implementaciones de ambas arquitecturas, mientras que enla Tabla 7.1 se muestra el detalle de los resultados. Los disenos mostrados se identificanprimero por el numero de bits de las muestra de entrada, segundo por la arquitecturautilizada (FB o FF), en tercer lugar por el numero de etapas y finalmente si se implementael diseno con crecimiento o sin el. Ası por ejemplo, 8 FB 3 0 se corresponderıa con un disenode arquitectura FFT-FB, con 8 bits para las muestras de entrada, con tres etapas y sincrecimiento.

El error la estimacion de FFs se debe principalmente a la eliminacion de registrosinnecesarios durante el analisis que realiza la herramienta durante la sıntesis. Sin embargo,el error en el numero de LUTs depende de cada arquitectura. El error en la arquitectura FBse debe principalmente a la estimacion del area de las memorias (memorias muy grandesimplementadas como memoria distribuida), que conforme mayor es la transformada, mayorimpacto tiene en el area global. En la arquitectura FF, aunque presenta el mismo error deestimacion de area en memorias, su aportacion es menor comparado con el area requeridapor otros componentes.

La estimacion de area toma como punto de partida la estimacion de area en numero deFFs y LUTs, pero pese a ello, como muestran las Figuras 7.2 y 7.3, permiten aproximarde manera realista los resultados experimentales. No hay que olvidar que mientras eltiempo requerido para obtener la estimacion, se corresponde con el tiempo requerido paragenerar el propio core (segundos), el tiempo necesario para obtener el valor experimentalse corresponde con el tiempo tomado en implementar (sintetizar) el core (minutos).

7.2.2. Estimacion de consumo

Los estimadores que se pueden implementar con dHDL no se limitan solo a area, losresultados experimentales recogidos para las arquitecturas FFT cubrıan tambien las carac-terısticas de prestaciones e incluso consumo. Puesto que el consumo, entre otros factores,


Tabla 7.1: Resultados de implementacion y estimacion. Arquitecturas FB y FF.

depende del area de la implementacion, se puede construir un estimador de consumo apartir de los estimadores de area (en slices) ya implementados en el apartado anterior.

De nuevo a partir de los resultados experimentales se puede calcular una nueva cons-tante que indica el consumo por unidad de area (en nuestro caso slices). Para las ar-quitecturas implementadas se obtiene que ambas arquitecturas consumen del orden de5µW/slice/MHz (5,7 para la arquitectura FB y 5,5 para la arquitectura FF). De manerasimilar al estimador de area, podemos calcular esta constante y utilizarla junto con laanterior estimacion de slices para obtener una estimacion del consumo.

El error de la estimacion de consumo es mayor que en el caso de la estimacion de area,debido a que por una parte utiliza la propia estimacion de area y por otra parte obtienelos datos a partir de las herramientas de Xilinx, que aunque se realizan sobre disenosya implementados se corresponden con una estimacion. A pesar del error cometido, laestimacion se obtiene de una manera rapida con la generacion del propio core, y por lotanto necesita muchos menos recursos y tiempo que la obtenida a partir de las herramientasde desarrollo o utilizando medidas experimentales [HASLVE08].

7.3 Exploracion de alternativas de implementacion 163

Figura 7.5: Esquema receptor canalizado.

7.3. Exploracion de alternativas de implementacion

El capıtulo 6 se centro en como utilizar dHDL para especificar dos arquitecturas con-cretas de FFT, la FFT-FB y la FFT-FF, con el objetivo de realizar dos implementacionesaltamente parametrizables. La especificacion de ambas arquitecturas no solo se limito a lapropia descripcion en dHDL de la arquitectura, sino que se caracterizaron y compararonexperimentalmente en el apartado 6.4.

En este capıtulo se ha indicado como es posible incluir en la propia especificacionestimaciones de las caracterısticas del espacio de diseno. Este enfoque, aunque permiteconocer con detalle las posibilidades de cada implementacion, no resulta practico si pa-ra seleccionar una implementacion se ha de realizar un estudio detallado de todas lasalternativas.

El encapsulado funcional visto en el apartado 5.3 permite definir mediante caracterısti-cas los requisitos que debe cumplir un diseno para considerarse implementacion de esteencapsulado. Utilizando este encapsulado se puede realizar de una manera rapida un ba-rrido entre las alternativas de implementacion de una funcion, y seleccionar la que mejorse adapte antes de realizar un estudio mas detallado de su implementacion.

En este apartado se describira la forma de especificar la funcion FFT que ayude aldisenador a elegir que alternativa o conjunto de alternativas de implementacion mejor seadaptan a la aplicacion, que para este caso de estudio se ha elegido el receptor canaliza-do. Primero se realizara una breve descripcion de los receptores canalizados para despuesdesarrollar un encapsulado funcional que permita describir la FFT a integrar en el sis-tema. Posteriormente, se indicara como se empaquetan las arquitecturas descritas en elcapıtulo 6 para cumplir el encapsulado funcional. Finalmente se analizara como la dife-rente configuracion de caracterısticas del encapsulado funcional permite seleccionar entrediferentes implementaciones.

7.3.1. Receptor canalizado

Un receptor canalizado es un buen ejemplo de sistema complejo que comprende todoun conjunto de elementos de adquisicion y de procesado, y ademas con fuertes requisitosdesde el punto de vista de procesado de senal [Tsu95] [TS02]: amplio ancho de banda deanalisis, alta sensibilidad y margen dinamico, resolucion en frecuencia, etc. Otra de lascaracterısticas de estos sistemas son los requisitos de procesado en tiempo real. La FFT,como elemento de procesado, es una de los elementos crıticos debido al procesado intensivoque debe realizar.

En la Figura 7.5 se muestra un esquema de un receptor canalizado, y como el modulode calculo de la FFT debe ser capaz de procesar un flujo continuo de muestras que obtiene


desde un ADC. Por lo tanto, la implementacion de estos sistemas requiere por una parte dedisenos capaces de proporcionar tiempo real: la toma de muestras se realiza desde ADCsque generan un flujo continuo de muestras, por lo que la cadena de procesado debe sercapaz de procesar las secuencias de manera continua. Ademas, las secuencias procedentesdel ADC han de ser pre-procesadas antes de ser filtradas por la FFT. El pre-procesadomınimo requiere del enventanado de las muestras.

Estos receptores se completan con etapas posteriores de procesado, que pueden com-prender procesado coherente o no-coherente, deteccion, y clasificacion automatica de mo-dulacion. El analisis detallado de los elementos del receptor canalizado se puede encontraren [LRnGSO05].

Un ejemplo de la implementacion de los elementos de post-procesado de un receptorcanalizado se encuentra en [GYOS+11], donde se presenta un clasificador automatico demodulaciones. Este sistema no solo debe detectar y separar senales, sino que tambiendebe identificar el tipo de modulacion de las senales, como paso previo a una posibledemodulacion de los datos.

A la hora de realizar la eleccion de la FFT para este tipo de sistemas, se pueden extraercaracterısticas relevantes desde el punto de vista hardware. La primera es una restriccionen prestaciones, de modo que permitan la operacion en tiempo real. Por otra parte, laimplementacion de estos sistemas requiere que integre varios modulos de procesado, porlo que el area del modulo FFT sera otra restriccion de la propia aplicacion.

7.3.2. Encapsulados y Empaquetado

Las arquitecturas descritas en el capıtulo 6 presentan semejanzas, por ejemplo, ambasse basan en la implementacion de la FFT siguiendo el algoritmo Cooley-Tukey [CLW67],ambas estan orientadas a aplicaciones que necesitan un procesado continuo, para lo queademas implementan un alto grado de pipeline a diferentes niveles con el objetivo dealcanzar elevadas frecuencias de trabajo.

Ambas arquitecturas descomponen el procesado en una cascada de etapas, e incluso eldiseno de las etapas utiliza el mismo conjunto de modulos (memoria, mariposa y rotador).Sin embargo, la diferente configuracion e interconexionado de sus modulos, junto con eldistinto modo de trabajo hacen que ambas arquitecturas presenten caracterısticas opuestasdentro del espacio de diseno.

Ademas, a la hora de implementar el algoritmo FFT podemos encontrar otras alter-nativas, como por ejemplo arquitecturas con diferente temporizacion e incluso diferentealgoritmo. Una arquitectura puede estar basada en la reutilizacion de una unica etapa parala implementacion de la transformada completa, de forma que deba trabajar de un modoiterativo, reutilizando los componentes para realizar las diferentes subtransformadas. Sinembargo, dada la aplicacion buscada para las FFT, los receptores canalizados, con fuertesrestricciones de prestaciones, resulta difıcil pensar que una arquitectura de este tipo vayaa ser de utilidad como elemento de procesado.

Durante la descripcion de las arquitecturas FFT se indico que ambas utilizan un modulopara el calculo de las DFTs de orden mınimo: la mariposa 6.2.2.1. La implementacion deeste modulo en el apartado 6.3.1.4 es tan flexible que puede utilizarse para realizar DFTsde orden 2RADIX , por lo que puede considerarse como un caso especial de implementacion


de FFT.

En lo que queda de apartado, primero se realizara una descripcion del encapsuladofuncional para la seleccion de implementaciones FFT que se adapten a los receptorescanalizados, para posteriormente describir como empaquetar las arquitecturas FFT-FB yFFT-FF para cumplir con los requisitos del encapsulado funcional propuesto. Tambiense propondra como empaquetar la implementacion de la mariposa del apartado 6.3.1.4como posible alternativa de implementacion. Finalmente se describira como influyen losrequisitos del sistema para la eleccion de la arquitectura concreta con el conjunto deencapsulados propuestos.

7.3.2.1. Encapsulado funcional: FFT

El encapsulado funcional de la FFT comienza identificando a la propia funcion, ası co-mo un conjunto de caracterısticas que permitan clasificar las diferentes implementaciones.En los Ejemplos 7.5 y 7.6 se muestra la primera version de encapsulado funcional.

Durante la declaracion de los encapsulados estructurales de ambas arquitecturas seutilizaban dos parametros (apartado 6.3.1.1 para la arquitectura FFT-FB y 6.3.2.1 parala FFT-FF), RADIX y STAGES, con la finalidad de configurar la longitud de la transformada.En el encapsulado funcional, la longitud de la transformada es la primera caracterıstica quedefine a la funcion. Esta caracterıstica sera comun no solo para las arquitecturas descritasen el capıtulo, sino que es un parametro de diseno de cualquier implementacion de la FFT.

Durante el estudio de los resultados de las arquitecturas FFT-FB y FFT-FF, en elapartado 6.4.1, tanto los resultados de area como de prestaciones son los que mejor resumenlas propiedades de cada arquitectura y permiten enmarcarlas dentro del espacio de diseno.Por lo tanto seran dos de las caracterısticas que definan la funcion. A diferencia de lalongitud de la transformada, estas caracterısticas requieren que el disenador del core aporteinformacion, bien obtenida a partir de resultados experimentales o bien de como esperaque se comporte el core disenado.

Dado que la plataforma sobre la que se implementan los disenos se correspondera conuna FPGA de Xilinx, la caracterıstica de area se define como un valor entero que represen-ta el numero de slices que ocupa el diseno. La caracterıstica de performance caracterizala capacidad de procesado de la implementacion en MSPS (Mega Samples per Second).

Como parte del encapsulado funcional se declaran los flujos de entrada y salida dela funcion. En el ejemplo se define un flujo de entrada que describe a las secuencias deentrada: cada muestra se compondra de dos valores enteros, parte real y parte imaginaria.De manera similar se declara un flujo de salida para el resultado de la transformada: cadadato se compondra de dos valores enteros, parte real y parte imaginaria.

7.3.2.2. Empaquetado de la arquitectura FFT-FB

Durante el empaquetado de la arquitectura FFT-FB se debe hacer corresponder laconfiguracion ofrecida por el encapsulado funcional descrito en el apartado anterior conel encapsulado estructural que define la implementacion de la arquitectura visto en elapartado 6.3.1.1.

El empaquetado constara de tres partes: correspondencia entre funcion e implementa-


Ejemplo 7.5 Encapsulado funcional FFT: Funcion y caracterısticas.<function id="fft">


<library>dsp</library>

<version>

<ver n="1" d="2010-04-08">


</ver>

</version>

</function>

<features>

<feature id="length">




<type>int8</type>

</version>

</feature>

<feature id="area">



<type>int32</type>

</version>

</feature>

<feature id="performance">



<type>int32</type>

</version>

</feature>

</features>

...

Ejemplo 7.6 Encapsulado funcional FFT: Flujos.<flow id="input_op" io="in">




<dt>

<mean>1.0</mean>

<peak>0.0</peak>

</dt>

<op>

<opid id="op_re" type="int8"/>

<opid id="op_im" type="int8"/>

</op>

</version>

</flow>

<flow id="output_res" io="out">




<dt>

<mean>1.0</mean>

<peak>0.0</peak>

</dt>

<op>

<opid id="res_re" type="int8"/>

<opid id="res_im" type="int8"/>

</op>

</version>

</flow>

</flows>

cion, configuracion de los parametros definidos en el encapsulado estructural a partir de lascaracterısticas del encapsulado funcional, y finalmente la verificacion de que caracterısticasimplementa el core para el conjunto de parametros definidos.

En el Ejemplo 7.7 se muestra la correspondencia entre la funcion declarada en elencapsulado funcional con la implementacion de la arquitectura FFT-FB que se realizo enel apartado 6.3.1.

Ejemplo 7.7 Implementacion de la funcion FFT con la arquitectura FFT-FB. Empaque-tado....

<function>

<core id="fft.fbck.top" />

<proto library="dsp"

id="fft" version="1.0" />

</function>

...

El Ejemplo 7.8 muestra la configuracion de los parametros del encapsulado estructuralde la arquitectura FFT-FB. De las caracterısticas declaradas en el encapsulado funcio-nal solo se utiliza la que define la longitud de la transformada (length). El parametroRADIX se fija a 4 mientras que el numero de etapas (STAGES) se calcula en funcion deeste valor y la longitud requerida para la transformada (STAGES = log4(length)). El


resto de parametros se fijan a valores que permitan obtener una configuracion valida dela implementacion.

Ejemplo 7.8 Arquitectura FFT-FB. Implementacion de la funcion FFT: configuracion....

<configuration>



</parameter>


<value><valf id="log">

<value><vall>4<vall/><value/>

<value>

<vall from="features"/>

length<vall/>

<value/>

</valf>

</value>

</parameter>


<value>16</value>

</parameter>


<value><vall>true<vall/></value>

</parameter>


<value><vall>true<vall/></value>

</parameter>


<value><vall>"cordic"<vall/><value/>

</parameter>


<value><vall>"logic"<vall/><value/>

</parameter>


<value><vall>"bram"<vall/><value/>

</parameter>


<value><vall>64<vall/><value/>

</parameter>

</configuratation>

...

En la ultima parte del empaquetado se verifican las caracterısticas que cumple la imple-mentacion, mostrado en el Ejemplo 7.9. La caracterıstica de longitud de la transformadase verificara contra el numero de puntos obtenido a partir de uno de los atributos definidosen la implementacion.

La caracterıstica de area se verifica a partir de estimadores de slices implementadosen la arquitectura como se indico en el apartado 7.2. La media obtenida a partir delos estimadores SLICES MAX y SLICES MIN debe ser menor que el valor de lacaracterıstica definida.

Durante la verificacion de los resultados experimentales del apartado 6.4.1 se obtuvie-ron valores de prestaciones por encima de los 250-MSPS para esta arquitectura, y estesera el valor que se utilice para verificar esta caracterıstica.

Ejemplo 7.9 Arquitectura FFT-FB. Implementacion de la funcion FFT: verificacion....

<verification>

<feature id="length">


<valf id="higher">

<arg>

<vall from="attributes">

FFT_POINTS</vall></arg>

<arg>

<vall from""features">

length</vall></arg>

</valf>

</value>

</feature>

<feature id="area">


<valf id="lower">

<arg><valf id="div">

<arg><valf id="add">

<arg><vall from="attributes">

AREA_SLICES_MAX</vall></arg>


AREA_SLICES_MIN</vall></arg>

</valf></arg>

<arg><vall>2</vall></arg>

</valf></arg>

<arg>

<vall from="features">

area</vall></arg>

</valf>

</value>

</feature>



<valf id="higher">


performance</vall></arg>


</valf>

</value>

</feature>

</verification>


7.3.2.3. Empaquetado de la arquitectura FFT-FF

El empaquetado de la arquitectura FFT-FF resulta muy similar al de la arquitecturaFFT-FB, ya que ambas arquitecturas se han disenado con el mismo conjunto de parametrosy atributos. En este apartado se mostraran las diferencias entre los empaquetados que sonconsecuencia de trabajar con diferente arquitectura. En el Ejemplo 7.10 se muestra comola correspondencia entre el encapsulado funcional de la FFT ahora se corresponde con laarquitectura FFT-FF.

Ejemplo 7.10 Arquitectura FFT-FF. Implementacion de la funcion FFT con la arqui-tectura FFT-FF....

<function>

<core id="fft.ffwd.top" />

<proto library="dsp"

id="fft" version="1.0" />

</function>

...

En el Ejemplo 7.11 se muestran las principales diferencias al realizar la configuraciondel encapsulado estructural. Si durante la configuracion de la arquitectura FFT-FB, seseleccionaba como radix optimo 4, para la arquitectura FFT-FF el disenador ha incluidouna funcion que evalua la caracterıstica performance para asignar el valor al parametroRADIX. Del mismo modo que con la arquitectura FFT-FB el parametro STAGES se evaluacon la caracterıstica length, tambien es necesario conocer el radix que se ha configuradoen el parametro anterior.

Ejemplo 7.11 Arquitectura FFT-FF. Implementacion de la funcion FFT: configuracion....

<configuration>


<value>

<valf id="fft.ffwd.Perf2Radix">

<arg>



</valf>

</value>

</parameter>


<value><valf id="log">

<value>

<vall from="parameters">

RADIX<vall/><value/>

<value>

<vall from="features"/>

length<vall/>

<value/>

</valf>

</value>

</parameter>

...

</configuratation>

Si la configuracion de ambas arquitecturas resulta similar debido a que ambas declaranlos mismos parametros, las principales diferencias se encontraran a la hora de evaluar suscaracterısticas, sobre todo las de area y performance debido a que ambas arquitecturasse encuentran en puntos opuestos del espacio de diseno. En el Ejemplo 7.12 se muestracomo se verifican ambas caracterısticas para esta arquitectura.

La verificacion de la caracterıstica performance se calcula de manera similar a la arqui-tectura FFT-FB, pero esta vez a partir de los resultados experimentales del apartado 6.4.1obtendra unas prestaciones que se estimaran como RADIX×200-MSPS.


Ejemplo 7.12 Arquitectura FFT-FF. Implementacion de la funcion FFT: verificacion....

<verification>

...

<feature id="area">


<valf id="lower">

<arg><valf id="div">

<arg><valf id="add">


AREA_SLICES_MAX</vall></arg>


AREA_SLICES_MIN</vall></arg>

</valf></arg>


</valf></arg>

<arg><vall from""features">

area</vall></arg>

</valf>

</value>

</feature>



<valf id="higher">

<arg>



<arg><valf id="mult">

<arg>

<vall from="parameters">

RADIX</vall></arg>


</valf></arg>

</value>

</feature>

</verification>

...

7.3.2.4. Empaquetado de la mariposa

En el apartado 6.3.1.4 se describio la implementacion dHDL del modulo encargado dehacer la mariposa definida en el algoritmo. Este modulo implementa la DFT de ordenmınimo en la que se descomponen las implementaciones de las arquitecturas FFT-FB yFFT-FF, por lo que tambien es un modulo que implementa la propia FFT, y se le puedeincorporar un empaquetado para indicar como implementa dicha funcion.

El Ejemplo 7.13 muestra como a partir de la caracterıstica de longitud de transformadase configura el parametro que define el orden mınimo, que en este caso se corresponde conel parametro RADIX.

El codigo que implementa el modulo no presenta ninguna restriccion al valor que sepueda configurar en este parametro (salvo que sea multiplo de 2), por lo que en principiopuede implementar transformadas de la misma longitud que las arquitecturas anteriores,pero como se indico en el apartado 6.2.2.1 a medida que aumenta el valor de este parame-tro el area requerida se dispara. A pesar del coste en area asociado a la longitud de latransformada, este modulo tambien presenta la posibilidad de ofrecer mejores prestaciones:todos los puntos de la transformada se procesan en paralelo.

Ejemplo 7.13 Modulo butterfly: configuracion....

<configuration>


<value><arg><vall from="features">length</vall></arg></valf></value>

</parameter>

...

</configuratation>

Puesto que el modulo butterfly se genera a partir de los componentes de biblio-teca de las arquitecturas anteriores, tambien incorpora su propia estimacion de area decomponentes basicos (FFs y LUTs). A partir de estos estimadores se puede construir losestimadores de area en slices requeridos para la verificacion de la caracterıstica area.

La verificacion de la caracterıstica de prestaciones utiliza la funcion definida para laarquitectura FFT-FF: el paralelismo logrado en esta arquitectura se consigue en gran


Figura 7.6: Alternativas del caso 1.

medida gracias a la propia implementacion del modulo butterfly.

7.3.3. Exploracion de alternativas

Dependiendo de los requisitos del sistema (receptor canalizado), la eleccion de la ar-quitectura a integrar en el sistemaes muy diferente. Uno de los requisitos del sistema esel ancho de banda a analizar, BW , que fijara la frecuencia de toma de datos en el ADC,BW ≤ 2× fs y otro de los requisitos es la resolucion en frecuencia, ∆f , que permite fijarel numero de puntos de la transformada: N = 2× fs/∆f .

En este apartado vamos a estudiar tres casos variando los requisitos del receptor cana-lizado. Se pretende emular la forma de trabajo que debe seguir el disenador del sistema a lahora de buscar y seleccionar que implementacion cumple con las restricciones del sistema.

7.3.3.1. Caso 1

Para el primer caso, se elegira un ADC ADS5485 de TI [TI]. El ADC, aunque dentrodel rango de alta velocidad, puede considerarse de prestaciones moderadas: 16 bits a200-MSPS. Con este ADC se puede implementar un receptor canalizado con un ancho debanda de analisis de BW = 100MHz. La resolucion en frecuencia para este caso se fijara a∆f ≤ 100KHz.

Para cumplir estos requisitos, la transformada sera del orden de 1024 puntos. Con estasrestricciones podemos configurar el encapsulado funcional:

length a 1024 puntos.

area, se establece un lımite de 10000 slices dado que en la FPGA se deben integrarotros elementos de procesado.

performance, se requiere que la arquitectura pueda procesar muestras en modocontinuo, por encima de 200-MSPS.



Los resultados de las diferentes implementaciones dentro del espacio de diseno area-prestaciones de este ejemplo se han representado en la Figura 7.6.

La arquitectura FFT-FB soporta todas las restricciones impuestas. Puede configurarlos 1024 puntos (RADIX = 4 STAGES = 5). La estimacion de area esta por debajode la restriccion impuesta (area = 5000). Finalmente, sus prestaciones (250-MSPS) seencuentran por encima de las restricciones.

La arquitectura FFT-FF no cumple con todas las restricciones: Mientras que cumplecon las de longitud (RADIX = 4 STAGES = 5) y prestaciones (800-MSPS), la estimacionde area supera la restriccion impuesta (area = 12000).

El modulo butterfly puede implementar la longitud pedida (RADIX = 1024) aunquela estimacion de area de la implementacion obtenida se dispara muy por encima de larestriccion de 10000 slices.

7.3.3.2. Caso 2

Para el segundo caso, se elegira un ADC ADS5400 de TI. El ADC tambien dentro delrango de alta velocidad presenta altas prestaciones: 12 bits y 1-GSPS. Con este ADC sepuede implementar un receptor canalizado con un ancho de banda de analisis de BW =500MHz. La resolucion en frecuencia para este caso se fijara a ∆f ≤ 2MHz.


length a 256 puntos.


performance, se requiere que la arquitectura pueda procesar muestras en modocontinuo, por encima de 1-GSPS.




La arquitectura FFT-FF cumple todas las restricciones impuestas. Puede configurar512 puntos (RADIX = 8 STAGES = 3) por encima de los 256 necesarios. La estima-cion de area esta por debajo de la restriccion impuesta (area = 5000). Finalmente, susprestaciones (1.6-GSPS) se encuentran por encima de las restricciones.

La arquitectura FFT-FB no cumple con todas las restricciones. Mientras que cumplecon las de longitud (RADIX = 4 STAGES = 4) y la estimacion de area no supera larestriccion impuesta (area = 3000), las prestaciones no alcanzan para realizar un procesadoen tiempo real (250-MSPS).

El modulo butterfly puede implementar la longitud pedida (RADIX = 256) aunquela estimacion de area de la implementacion obtenida se dispara muy por encima de larestriccion de 10000 slices.

7.3.3.3. Caso 3

Para el tercer caso, se utilizara un ADC ADC12D1000 de TI. El ADC tambien dentrodel rango de alta velocidad presenta muy altas prestaciones: 12 bits y 2-GSPS. Con esteADC se puede implementar un receptor canalizado con un ancho de banda de analisis deBW = 1GHz. La resolucion en frecuencia para este caso se fijara a ∆f ≤ 25− 30MHz.


length a 32 puntos.


performance, se requiere que la arquitectura pueda procesar muestras en modocontinuo, por encima de 2-GSPS.



La arquitectura FFT-FB de nuevo queda descartada al encontrarse limitadas sus pres-taciones.

El modulo butterfly puede implementar la longitud pedida (RADIX = 32) y en estecaso la estimacion de area se encuentra dentro de los margenes requeridos. La arquitecturaFFT-FF tambien es capaz de generar una implementacion que verifique las caracterısticas,aunque para cumplir con la restriccion de prestaciones necesita implementar un radixelevado, y por lo tanto la implementacion es muy similar a la implementacion del modulobutterfly.

7.4. Conclusiones

Este capıtulo se ha centrado en ver como el enfoque de reutilizacion propuesto propor-ciona soporte para la exploracion del espacio de diseno. En primer lugar, se ha descritocomo se realiza el proceso de generacion y de recogida de informacion de un core descritoen dHDL. Dentro del proceso de implementacion de un diseno, el coste requerido paragenerar una descripcion VHDL a partir de su especificacion en dHDL es mınimo compa-rado con el coste de implementacion (segundos respecto a minutos), con lo que de manerarapida se pueden generar un conjunto representativo de implementaciones con diferentesjuegos de parametros que cubran el espacio de diseno. Ademas, las descripciones dHDLpermiten incorporar estimadores de las caracterısticas del espacio de diseno, incorporandoen el propio core no solo informacion proporcionada desde los resultados experimentales,sino tambien ligada a como se ha generado la estructura, con lo que el usuario del corepuede de una manera rapida realizar la exploracion del espacio de diseno sobre el conjuntode implementaciones generadas.

Como continuacion del capıtulo anterior en el que se especificaban diferentes arqui-tecturas FFT con el lenguaje dHDL, en este capıtulo se ha ilustrado el potencial de estelenguaje como instrumento para incorporar junto con el diseno una estimacion rapidadel area requerida para diferentes configuraciones de la FFT en una familia de FPGAsdeterminada.

La especificacion del core con dHDL simplifica la tarea de implementar estimadores conel diseno, y con ello ayuda a mejorar la cantidad de informacion que desde la interfaz ofreceel core. Esta informacion, que se integra en el encapsulado estructural, ayuda en la tareade buscar entre diferentes alternativas de implementacion. Por otro lado, el encapsuladofuncional describe el conjunto de caracterısticas requeridas por la aplicacion. Mediante elempaquetado el disenador decide como el diseno implementa estas caracterısticas estable-ciendo las relaciones necesarias entre el encapsulado funcional y el estructural. El conjuntode empaquetados de diferentes cores se recoge en una biblioteca, lo que permite automa-tizar la exploracion de alternativas de implementacion de un encapsulado funcional.

En este capıtulo se han explorado las alternativas de implementacion para la funcionFFT requerida en una aplicacion concreta, el receptor canalizado. Los requisitos del sistemaguıan la busqueda entre las alternativas, de modo que el sistema permite seleccionar desdeimplementaciones directas, como por ejemplo las arquitecturas FFT-FB y FFT-FB yadescritas, hasta otros disenos que se pueden adaptar para cumplir con la funcion descrita.

Capıtulo 8

Conclusiones

8.1. Conclusiones del trabajo realizado

El objetivo principal de esta Tesis Doctoral ha sido aumentar la productividad en el di-seno de aplicaciones de procesado de senal sobre FPGAs. En concreto nos hemos centradoen mejorar esta productividad mediante la reutilizacion de disenos con una especificaciondel hardware eficiente y la definicion de encapsulados. Por una parte se mejoran las posi-bilidades de configuracion y por otra parte se puede ampliar la informacion que de maneraautomatica se proporciona a traves de estos encapsulados.

A continuacion se recogen las principales contribuciones del trabajo realizado, organi-zadas siguiendo los objetivos que se plantearon en el origen de esta Tesis.

Especificacion de cores hardware orientada a su reutilizacion

Con el objetivo de simplificar y mejorar la descripcion de cores reutilizables se hadefinido y descrito el lenguaje dHDL en el capıtulo 4. Este lenguaje esta orientado ala creacion de cores VHDL sintetizables mediante la generacion dinamica de codigo.Frente a lenguajes como VHDL o Verilog mejora caracterısticas del diseno de coresestructurales y jerarquicos.

dHDL implementa un conjunto reducido de estructuras y elementos del lenguaje,muy similares a elementos ya presentes en los HDLs convencionales, y simplifica elproceso de instanciacion e interconexionado de componentes previamente definidos,bien con el lenguaje o bien con VHDL. Al simplificar el interconexionado e ins-tanciacion, se potencia de manera significativa la capacidad de descripcion a nivelestructural respecto a los HDL tradicionales. Ademas, dHDL mejora las posibilida-des de configuracion y evaluacion del hardware descrito, incrementando con ello susposibilidades de reutilizacion.

Las estructuras de control y tipos del lenguaje permiten al disenador controlar comoy cuando se genera el codigo del core, dando la flexibilidad de probar diferentes con-figuraciones para los componentes a instanciar e incluso evaluar entre alternativasantes de incluirlos como parte del core. El lenguaje dispone de elementos cuya de-claracion y visibilidad queda limitada dentro del codigo fuente donde se describe eldiseno, y permite al disenador decidir cuando estos elementos se reflejan en el codigogenerado.

176 Conclusiones

El lenguaje, por lo tanto, no esta enfocado a describir componentes sino a describircomo se generan los componentes. Ası la mayor parte de elementos de dHDL secentran en simplificar la descripcion estructural de componentes. Sin embargo, semantiene la posibilidad de utilizar VHDL para la descripcion del comportamiento,bien mediante inserciones de codigo dentro de las fuentes dHDL o incluso mediantela inclusion de cores VHDL completos como parte del diseno generado.

Para ilustrar las posibilidades del lenguaje se han utilizado diversos ejemplos. En elcapıtulo 3 se ha indicado como utilizar el lenguaje como envoltorio de un componenteVHDL complejo, el DSP48E. En el capıtulo 4 se han descrito las implementacionesen dHDL de una estructura para un filtro FIR y un arbol de sumadores. El objetivode estos ejemplos es mostrar diversas funcionalidades del lenguaje para la especifica-cion de hardware, mientras que en el capıtulo 6 se desarrolla la FFT como ejemplocomplejo y clasico de procesado de senal. Con la FFT mostramos, por un lado, comocon dHDL se puede realizar una implementacion altamente parametrizable, pero porotro lado se ha demostrado que los multples cores a los que da lugar son de grancalidad.

El lenguaje no solo permite la especificacion de hardware, sino que da soporte a laincorporacion de informacion de la implementacion en su interfaz. En el capıtulo 7 semuestra como a partir de la especificacion de la FFT realizada, se pueden implemen-tar estimadores en la propia especificacion. Este mecanismo dota al disenador de laposibilidad de incorporar informacion dependiente de la arquitectura y componentesutilizados.

Las posibilidades de configuracion y la informacion que se genera junto con el coreVHDL a partir de la descripcion dHDL, se recoge en la interfaz de los cores dHDL.Esta interfaz se corresponde con lo que en el trabajo se ha denominado encapsuladoestructural.

Especificacion del encapsulado estructural

El encapsulado estructural, descrito en el capıtulo 5 se corresponde con la interfaz delos cores descritos con dHDL. Parte de las posibilidades de reutilizacion del lenguajese obtienen a partir de la declaracion de los elementos que se realiza en esta interfaz,que extiende las posibilidades de los HDLs clasicos. Esta interfaz no solo permitela configuracion del core sino que proporciona al exterior informacion del codigogenerado.

El encapsulado estructural esta ligado a una implementacion concreta y se ha pen-sado para mejorar la informacion ofrecida por la propia implementacion. Define losparametros que configuran a un core, similares a los de otros HDLs, pero tambienincorpora los atributos con los que obtener informacion de la implementacion. Parala entrada-salida define macropuertos, que agregan en una unica declaracion a todoun conjunto de puertos convencionales orientados a implementar una funcion.

Frente a la interfaz de los lenguajes convencionales, este encapsulado estructuralaumenta la cantidad de informacion que el disenador puede incorporar junto conla propia implementacion. Esta informacion mejora las posibilidades de reutilizaciondel propio componente, ya que puede ofrecerse a otro disenador que quiera utilizar elcore, o incorporarse a herramientas que integren al diseno como parte de un sistema.

8.1 Conclusiones del trabajo realizado 177

Durante el trabajo se han mostrado diferentes ejemplos de la especificacion de esteencapsulado estructural. Por ejemplo, para simplificar la interfaz del componenteDSP48E o de filtros FIR en el capıtulo 5. La especificacion de la FFT en el capıtulo 6tambien sirve para ofrecer ejemplos del uso de este encapsulado.

Si el lenguaje dHDL permite la implementacion de estimadores junto con el procesode generacion, como se ha mostrado en el capıtulo 7, es en el encapsulado estructuraldonde se ofrecen los resultados de estos estimadores a los usuarios del core. Por ello,este encapsulado esta pensado tambien para servir de soporte a herramientas querealicen la exploracion del espacio de diseno.

Encapsulado funcional y empaquetado

A pesar de las ventajas ofrecidas por el conjunto dHDL y encapsulado estructural,se limitan a ofrecen una implementacion concreta de una funcion. Por ello en elcapıtulo 5 se ha propuesto un nuevo nivel de especificacion de encapsulado con dosnuevos elementos. El primer elemento lo compone el encapsulado funcional, orientadoa definir caracterısticas que pueden ser implementadas en multiples disenos, y sinque se encuentre ligado a ninguna implementacion concreta. El segundo elemento locompone el empaquetado que relaciona el encapsulado estructural con el encapsuladofuncional.

El encapsulado funcional permite declarar caracterısticas que describen una funcion.A diferencia de los parametros definidos para configurar un core, las caracterısticasayudan a establecer restricciones a cumplir por el diseno para convertirse en unaimplementacion del encapsulado. Las caracterısticas del encapsulado funcional, al noestar ligadas a ningun diseno concreto, describen los aspectos mas relevantes paraque la implementacion cumpla la funcion, de modo que se pueden implementar desdeencapsulados funcionales totalmente genericos que simplemente permitan clasificarentre implementaciones, hasta encapsulados funcionales tan detallados que describanuna implementacion concreta.

Un core dHDL se define con un unico encapsulado estructural, pero el diseno puedeadaptarse para cumplir varios encapsulados funcionales. Es en el empaquetado delcore donde el disenador establece como configurar los parametros del encapsuladoestructural a partir de las caracterısticas del funcional, y a partir del core configuradoverificar si realmente se cumple con todas los requisitos declarados en el encapsuladofuncional.

El empaquetado permite al disenador ampliar la interfaz con informacion de uso,como si se tratasen de notas de aplicacion. Ademas aumentan la visibilidad del core,ya que ofrecen al diseno como solucion para implementar funciones, desde las que hasido disenado expresamente a otras funciones que pueden implementarse adaptandolas caracterısticas del componente.

En el capıtulo 7, utilizando la especificacion de la FFT en dHDL, se ha definido suencapsulado funcional y empaquetados para las diferentes arquitecturas realizadas.El conjunto de encapsulado y empaquetados permiten de una forma sencilla indicarque implementacion se aproxima mas a los requisitos de la aplicacion.

178 Conclusiones

Creacion de una biblioteca de componentes para procesado de senal: la FFT

En el capıtulo 6 se han descrito dos arquitecturas para el procesado de altas presta-ciones y tiempo real de la FFT, utilizando el lenguaje dHDL para su especificacion.Primero se ha presentado el algoritmo prestando especial atencion a los elementoshardware que componen las implementaciones, para despues explicar en detalle laspeculiaridades del diseno de los principales modulos y de las propias arquitecturas aimplementar.

La descripcion en dHDL de ambas arquitecturas se basa en la reutilizacion tanto demodulos implementados expresamente para ellas, como de modulos que implementanfunciones aritmeticas y logicas. Todo el conjunto de componentes se ha incorporadoen una biblioteca para su reutilizacion en nuevos disenos. Durante el diseno de estoscomponentes de la biblioteca se ha cuidado, por una parte, que implementen un con-junto suficiente de parametros que permita adaptarlos a las diferentes arquitecturas.Por otro lado, tambien se han realizado de ofrecer informacion en su interfaz quesimplifique su reutilizacion.

Una de las caracterısticas de las arquitecturas seleccionadas es que estan enfocadas aaplicaciones que requieren de un procesado continuo y a la vez exigen altas prestacio-nes. Ademas, aunque son arquitecturas similares, presentan puntos opuestos dentrodel espacio de diseno area-prestaciones.

Durante el diseno de los componentes de mas alto nivel de la jerarquıa el lenguajedHDL permite de una manera sencilla y flexible realizar una descripcion orienta-da a la generacion de la estructura, simplificando el proceso de instanciacion decomponentes y su interconexionado. Ademas, el proceso de generacion no se realizaunicamente desde la parte superior de la jerarquıa a los elementos de mas bajo nivel,sino que permite, ademas de instanciarlos, obtener informacion desde sus atributospara adaptarlos al resto de componentes.

Ambas arquitecturas han sido disenadas con un conjunto amplio de parametros, queabarcan desde la modificacion de la propia funcion hasta aspectos de implementacionde bajo nivel, que permiten adaptar las arquitecturas a la plataforma sobre la que seimplemente. Con todas las posibilidades de configuracion que ambas arquitecturasofrecen, se ha realizado un estudio experimental que por una parte permite verificarlas diferencias entre ambas arquitecturas en terminos de area-prestaciones, y por otraparte facilita conocer como afectan algunos de los parametros a la implementacionfinal.

Las arquitecturas FFT implementadas han servido como base para ilustrar el uso dellenguaje dHDL y el encapsulado estructural para la implementacion de estimadoresdependientes de la estructura generada, y con los que realizar de manera rapida unaexploracion del espacio de diseno. Tambien han servido para mostrar el proceso debusqueda de alternativas, tras especificar un encapsulado funcional e implementarlos empaquetados de las diferentes arquitecturas.

Soporte para la exploracion del espacio de diseno: estimadores

Dentro del proceso de implementacion de un diseno, el coste requerido para generaruna descripcion VHDL a partir de su especificacion en dHDL es mınimo compa-rado con el coste de implementacion (segundos respecto a minutos), con lo que de

8.2 Trabajo futuro 179

manera rapida se pueden generar un conjunto representativo de implementacionescon diferentes juegos de parametros que cubran el espacio de diseno. Ademas, lasdescripciones dHDL permiten incorporar estimadores de las caracterısticas del es-pacio de diseno, incorporando en el propio core no solo informacion proporcionadadesde los resultados experimentales, sino tambien ligada a como se ha generado laestructura, con lo que el usuario del core puede de una manera rapida realizar laexploracion del espacio de diseno sobre el conjunto de implementaciones generadas.

En el capıtulo 7 se ha descrito como se realiza el proceso de generacion y de recogidade informacion de un core descrito en dHDL. Como continuacion del capıtulo ante-rior en el que se especificaban diferentes arquitecturas FFT con el lenguaje dHDL, eneste capıtulo se ha ilustrado el potencial de este lenguaje como instrumento para in-corporar junto con el diseno una estimacion rapida del area requerida para diferentesconfiguraciones de la FFT en una familia de FPGAs determinada.

Soporte para la evaluacion de alternativas

La especificacion de un core con dHDL simplifica la tarea de implementar estimado-res con el diseno, y con ello ayuda a mejorar la cantidad de informacion que desdela interfaz ofrece el core. Esta informacion, que se integra en el encapsulado estruc-tural, ayuda en la tarea de buscar entre diferentes alternativas de implementacion.Por otro lado, el encapsulado funcional describe el conjunto de caracterısticas re-queridas por la aplicacion. Mediante el empaquetado el disenador decide como eldiseno implementa estas caracterısticas estableciendo las relaciones necesarias entreel encapsulado funcional y el estructural. El conjunto de empaquetados de diferen-tes cores se recoge en una biblioteca, lo que permite automatizar la exploracion dealternativas de implementacion de un encapsulado funcional.

De nuevo, en el capıtulo 7 se han explorado las alternativas de implementacionpara la funcion FFT requerida en una aplicacion concreta, el receptor canalizado.Los requisitos del sistema guıan la busqueda entre las alternativas, de modo que elsistema permite seleccionar desde implementaciones directas, como por ejemplo lasarquitecturas FFT-FB y FFT-FF ya descritas, hasta otros disenos que se puedenadaptar para cumplir con la funcion deseada.

8.2. Trabajo futuro

El trabajo realizado ha cubierto un amplio conjunto de tareas, desde la especificaciondel lenguaje a la propia implementacion de herramientas y cores, lo que da lugar a laexistencia de multiples lıneas de continuacion que se plantean como objetivos para untrabajo futuro.

El lenguaje dHDL requiere una revision de la sintaxis y semantica, para uniformizardeclaraciones de tipos, llamadas a procedimientos o llamadas a funciones. Ademas esposible mejorar sus caracterısticas con la incorporacion de nuevas estructuras de controlde generacion, pero sobre todo es necesario la definicion de nuevos tipos y procedimientossobre estos tipos en el lenguaje.

Entre el conjunto de nuevos tipos a definir se encontrarıan por ejemplo el tipo registro,multiplexor, ram, rom, etc. Este conjunto de tipos se corresponde con componentes de bajo

180 Conclusiones

nivel de la biblioteca, normalmente implementados con descripciones comportamentales,y de los que se hace un uso intensivo en las descripciones estructurales.

El objetivo de incorporar estos elementos como tipos dHDL es minimizar el uso delas inserciones de codigo VHDL que permite el lenguaje. Estas inserciones, aunque utilesen determinadas ocasiones, desde el punto de vista del lenguaje se pierde el control delcontenido que se esta generando.

Para eliminar la necesidad de utilizar inserciones de codigo con el lenguaje, ademasde la definicion de los tipos anteriores, es necesario realizar un trabajo adicional en otrosaspectos, como por ejemplo la especificacion del control. En este aspecto se puede incluirla posibilidad de especificar el control mediante soluciones probadas como es la implemen-tacion de FSMs.

Finalmente, para los componentes de biblioteca cuya especificacion es comportamental,ya sea porque se implementen utilizando inserciones de codigo, o directamente porque secorresponden con el encapsulado de un componente VHDL, es necesario que desde ellenguaje se pueda acceder a informacion funcional asociada al componente.

dHDL define un conjunto de funciones aritmeticas y logicas, manejo y control de senalesy rangos de senales, etc. Su uso se limita a calculos durante el proceso de generacion, mien-tras que resulta de interes que tambien puedan utilizarse como componentes durante elproceso de generacion. Las funciones del lenguaje pasarıan a tener un caracter dual, co-mo funciones o como componentes, dependiendo posiblemente del contexto. Es necesarioevaluar si todas las funciones pueden implementar este caracter dual, o si pueden ofrecerdiferentes alternativas de implementacion. Por ejemplo, la implementacion de la suma conaritmetica entera o con punto flotante. Ademas es necesaria la especificacion de carac-terısticas temporales y de interfaz, por ejemplo si la funcion se implementa de maneraiterativa, o en pipeline.

Tambien hay trabajo por realizar entre el conjunto de herramientas que dan soporte allenguaje. Parte de este trabajo se corresponde con el formato de representacion intermediotras procesar el codigo fuente dHDL. Su formalizacion utilizando lenguajes como XMLpuede abrir una lınea de trabajo que mejore el analisis y la verificacion de las estructurasa generar, y que ayude en tareas como la busqueda de errores de especificacion, propuestaspara mejora de la implementacion o incluso la representacion de la estructura.

A partir de esta especificacion intermedia es posible realizar tareas asociadas al procesode sıntesis, como por ejemplo optimizaciones en la propia estructura y su correspondenciacon elementos de bajo nivel, pero tambien es posible ofrecer soporte a herramientas desıntesis de alto nivel, por ejemplo identificando y asociando plantillas de estructuras conconstrucciones de alto nivel.

Otro trabajo que puede ser continuacion de esta Tesis es elevar el nivel de abstraccionde la descripcion de la estructura, permitiendo el uso de modulos mediante un encapsuladofuncional y no componentes a traves de su encapsulado estructural. Para ello es necesariomejorar las relaciones entre encapsulado funcional y estructural para instanciar funciones yno componentes especıficos. La generacion de un core no se guiarıa por parametros sino porrestricciones. Al incorporar o actualizar modulos en la biblioteca se reflejarıa de manerainmediata en descripciones de otros disenos ya descritos y sin necesidad de modificarlos.

Para realizar esta tarea, es preciso tambien especificar y definir que caracterısticas

8.3 Contribuciones 181

son necesarias para realizar de manera efectiva la correspondencia entre ambos niveles deencapsulado. La necesidad de informacion de interfaz mas detallada requiere analizar y es-tudiar nuevas alternativas de especificacion e implementacion tanto para los encapsuladoscomo empaquetados, por ejemplo utilizando RDF [rdf].

En la propuesta de esta Tesis se delega en el disenador la tarea incorporar la informa-cion que debe ofrecer su diseno. Parte de esta informacion se puede incorporar de maneraautomatica, por ejemplo informacion del espacio de diseno. Queda pendiente definir e im-plementar procesos para la caracterizacion automatica de los componentes. A partir dela especificacion dHDL realizar el proceso de sıntesis para generar modelos de bajo nivelde la estructura, y caracterizarlos en terminos de area, prestaciones o consumo, e integraresta informacion como parte de la interfaz de los disenos.

Desde el punto de vista de especificacion y encapsulados, otras lıneas de trabajo quedanabiertas a definir la interfaz con lenguajes de un mayor nivel de abstraccion.

Tambien es necesario un trabajo adicional en la especificacion e implementacion decomponentes de biblioteca de la propuesta. No solo componentes especıficos del campo deprocesado de senal, tambien es necesario ampliar y mejorar elementos como la definicionde nuevos tipos de macropuertos y la implementacion de adaptadores entre estos tipos.

Finalmente, quedarıa tambien pendiente realizar una validacion del trabajo propuesto,en cuanto usabilidad, expresividad o facilidad de aprendizaje. Se debe evaluar si el es-fuerzo inicial de aprendizaje requerido por el lenguaje y encapsulados, tanto por usuarioshabituados a otros HDLs como usuarios inexpertos, logra mejorar la productividad.

8.3. Contribuciones

El trabajo en esta tesis ha dado lugar a las siguientes publicaciones:

A. Fernandez-Herrero, Miguel A. Sanchez, and Marisa Lopez-Vallejo. A Java Toolfor the Automatic Generation of CORDIC Hardware IP Cores. In Design of Circuitsand Integrated Systems, Ciudad Real (Spain), 2003.

Miguel A. Sanchez, A. Fernandez Herrero, and Marisa Lopez-Vallejo. IP Core reusethrough the application of the meta-language xHDL. In Forum on Specification andDesign Languages, Lille (France), 2004.

Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, and Jesus Grajal. Im-plementing the FFT algorithm in FPGA platforms: a comparative study of parallelarchitectures. In Design of Circuits and Integrated Systems, Burdeos (France), 2004.

A. Fernandez-Herrero, Miguel A. Sanchez, and Marisa Lopez-Vallejo. Web-BasedEnvironment for the Evaluation and Generation of Complex IP Cores. In IP BasedSoC Design Conference, Grenoble (France), 2004.

Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, Jesus Grajal, and CarlosLopez-Barrio. Digital channelised receivers on FPGAs platforms. In IEEE Interna-tional Radar Conference, pages 816–821, Washington D.C. (E.E.U.U), 2005. IEEE.

182 Conclusiones

Miguel A. Sanchez, A. Fernandez-Herrero, and Marisa Lopez-Vallejo. xHDL: Exten-ding VHDL to improve core parameterization and reuse. In Pierre Boulet, editor,Advances in Design and Specification Languages for SoCs, pages 217–235. KluwerAcademic Publishers, Boston, 2005.

Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, Jesus Grajal, and CarlosLopez-Barrio. Implementing the Monobit FFT on FPGA Platforms. In Design ofCircuits and Integrated Systems, Lisboa (Portugal), 2005.

Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, and Carlos Lopez-Barrio.Automated design space exploration of FPGA-based FFT architectures based onarea and power estimation. In 2006 IEEE International Conference on Field Pro-grammable Technology, pages 127–134, Bangkok (Thailand), December 2006. IEEE.

I. Herrera-Alzu, Miguel A. Sanchez, Marisa Lopez-Vallejo, and P. Echeverria. Expe-rimental methodology for power characterization of FPGAs. In 2008 15th IEEE In-ternational Conference on Electronics, Circuits and Systems, pages 582–585. IEEE,August 2008.

Miguel A. Sanchez, Pedro Echeverria, Francisco Mansilla, and Marisa Lopez-Vallejo.Designing highly parameterized hardware using xHDL. In 2008 Forum on Specifi-cation, Verification and Design Languages, pages 78–83. IEEE, September 2008.

Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, and Jesus Grajal. Imple-menting FFT-based digital channelized receivers on FPGA platforms. IEEE Tran-sactions on Aerospace and Electronic Systems, 44(4):1567–1585, October 2008.

Pedro Echeverria, Miguel A. Sanchez, Marisa Lopez-Vallejo, and Carlos Lopez-Barrio. Development of a Standard Single Floating-Point Library and its Encapsu-lation for Reuse. In Design of Circuits and Integrated Systems Conference, Zaragoza(Spain), 2009.

Jesus Grajal, Omar Yeste-Ojeda, Miguel A. Sanchez, Mario Garrido, and MarisaLopez-Vallejo. Real Time FPGA Implementation of an Modulation Classifier forElectronic Warfare Applications. In 19th European Signal Processing Conference,number Eusipco, pages 1514–1518, 2011.

Mario Garrido, Jesus Grajal, Miguel A. Sanchez, and Oscar Gustafsson. PipelinedRadix- 2ˆk Feedforward FFT Architectures. IEEE Transactions on Very Large ScaleIntegration Systems, 2011.

Pablo Royer, Miguel Angel Sanchez, Marisa Lopez-Vallejo, and Carlos A. Lopez Ba-rrio. Area-Efficient Linear Regression Architecture for Real-Time Signal Processingon FPGAs. In Design of Circuits and Integrated Systems, 2011.

Bibliografıa

[AEG+10] Adam Arnesen, Kevin Ellsworth, Derrick Gibelyou, Travis Haroldsen, JaredHavican, Marc Padilla, Brent Nelson, Michael Rice, and Michael Wirthlin.Increasing Design Productivity through Core Reuse, Meta-data Encapsula-tion, and Synthesis. In 2010 International Conference on Field Programma-ble Logic and Applications, pages 538–543. IEEE, August 2010.

[Agr09] Jason Agron. Domain-specific language for HW/SW co-design for FPGAs.Domain-Specific Languages, Lecture Notes in Computer Science, 5658:262–284, 2009.

[Alf08] Peter Alfke. FPGAs in 2008 and beyond the future platform for transfor-ming, transporting and computing. In Topical Workshop on Electronics forParticle Physics, 2008.

[ARW09] Adam Arnesen, Nathaniel Rollins, and Michael Wirthlin. A multi-layeredXML schema and design tool for reusing and integrating FPGA IP. In 2009International Conference on Field Programmable Logic and Applications,pages 472–475. IEEE, August 2009.

[ASRW96] Matthew Aubury, Jonathan Saul, Geo Randall, and Robin Watts. Handel-CLanguage Reference, 1996.

[BG02] Mihai Budiu and Seth Copen Goldstein. Compiling Application-SpecificHardware. Field-Programmable Logic and Applications: Reconfigurable Com-puting Is Going Mainstream, pages 853–863, 2002.

[Bha92] J. Bhasker. A VHDL Primer. Prentice Hall, 1992.

[Bha97] J. Bhasker. A Verilog HDL Primer. Star Galaxy Press, 1997.

[Bol06] Ivo Bolsens. Programming Modern FPGAs. In MPSOC, 2006.

[CGJP03] Seonil Choi, G. Govindu, Ju-Wook Jang, and V.K. Prasanna. Energy-efficient and parameterized designs for fast Fourier transform on FPGAs.In 2003 IEEE International Conference on Acoustics, Speech, and SignalProcessing, 2003. Proceedings. (ICASSP ’03)., volume 2, pages II–521–4.IEEE, 2003.

[CGL04] W Cesario, L Gauthier, and D Lyonnard. Object-based hardware/softwarecomponent interconnection model for interface design in system-on-a-chipcircuits. of Systems and Software, 70:229–244, 2004.

184 BIBLIOGRAFIA

[CGWT10] Fulong Chen, Rajat Goyal, Edwin Westbrook, and Walid Taha. ImplicitlyHeterogeneous Multi-Stage Programming for FPGAs. In Proceedings of 11thSymposium on Trends in Functional Programming, pages 217–235, 2010.

[CLW67] J.W. Cooley, P.A.W. Lewis, and P.D. Welch. Historical notes on the fastFourier transform. Proceedings of the IEEE, 55(10):1675–1677, 1967.

[CN03] J.M.P. Cardoso and H.C. Neto. Compilation for FPGA-based reconfigurablehardware. IEEE Design & Test of Computers, 20(2):65–75, March 2003.

[Con08] Jason Cong. A new generation of C-base synthesis tool and domain-specificcomputing. In 2008 IEEE International SOC Conference, pages 386–386.IEEE, September 2008.

[CP03] Yun-Nan Chang and K.K. Parhi. An efficient pipelined fft architecture.IEEE Transactions on Circuits and Systems II: Analog and Digital SignalProcessing, 50(6):322–325, June 2003.

[CZ02] C. Cote and Z. Zilic. Automated SystemC to VHDL translation in hard-ware/software codesign. In 9th International Conference on Electronics,Circuits and Systems, volume 2, pages 717–720. IEEE, 2002.

[DAD+04] D. DeHon, J. Adams, M. DeLorimier, N. Kapre, Y. Matsuda, H. Naeimi,M. Vanier, and M. Wrighton. Design Patterns for Reconfigurable Com-puting. In 12th Annual IEEE Symposium on Field-Programmable CustomComputing Machines, pages 13–23. IEEE, 2004.

[DBB99] M. Dalpasso, A. Bogliolo, and L. Benini. Specification and validation ofdistributed IP-based designs with JavaCAD. In Proceedings of the 1999Design, Automation and Test in Europe Conference and Exhibition., pages684–688. IEEE Comput. Soc, 1999.

[DMS03] Robertas Damasevicius, Giedrius Majauskas, and Vytautas Stuikys. Appli-cation of design patterns for hardware design. In Proceedings of the DesignAutomation Conference., number 370 37, pages 48–53. ACM, 2003.

[DMS+07] Paolo D’Alberto, Peter A. Milder, Aliaksei Sandryhaila, Franz Franchetti,James C. Hoe, Jose M.F. Moura, Markus Puschel, and Jeremy R. John-son. Generating FPGA-Accelerated DFT Libraries. In 15th Annual IEEESymposium on Field-Programmable Custom Computing Machines (FCCM2007), pages 173–184. IEEE, April 2007.

[dMVP10] Frederic de Mesmay, Yevgen Voronenko, and Markus Puschel. Offline libraryadaptation using automatically generated heuristics. In 2010 IEEE Inter-national Symposium on Parallel & Distributed Processing (IPDPS), pages1–10. IEEE, 2010.

[Edi90] First Edition. The VHDL Cookbook. Science, 1990.

[Edw05] S.A. Edwards. The challenges of hardware synthesis from C-like languages.In Proceedings of the conference on Design, Automation and Test in Europe-Volume 1, pages 66–67. IEEE Computer Society, 2005.

BIBLIOGRAFIA 185

[ESLVLB09] Pedro Echeverria, Miguel A. Sanchez, Marisa Lopez-Vallejo, and CarlosLopez-Barrio. Development of a Standard Single Floating-Point Library andits Encapsulation for Reuse. In Design of Circuits and Integrated SystemsConference, Zaragoza (Spain), 2009.

[FHSLV03] A. Fernandez-Herrero, Miguel A. Sanchez, and Marisa Lopez-Vallejo. AJava Tool for the Automatic Generation of CORDIC Hardware IP Cores.In Design of Circuits and Integrated Systems, Ciudad Real (Spain), 2003.

[FHSLV04] A. Fernandez-Herrero, Miguel A. Sanchez, and Marisa Lopez-Vallejo. Web-Based Environment for the Evaluation and Generation of Complex IP Cores.In IP Based SoC Design Conference, Grenoble (France), 2004.

[Fit04] Tom Fitzpatrick. SystemVerilog for VHDL Users. In Proceedings of theconference on Design, automation and test in Europe, pages 21334–. IEEEComputer Society, 2004.

[FN01] Masahiro Fujita and H. Nakamura. The standard SpecC language. In Pro-ceedings of the 14th international symposium on Systems synthesis, pages81–86. ACM, 2001.

[FPV+09] Franz Franchetti, Markus Puschel, Yevgen Voronenko, Srinivas Chellappa,and Jose Moura. Discrete fourier transform on multicore. IEEE SignalProcessing Magazine, 26(6):90–102, November 2009.

[FZX10] Chen Fulong, Zhu Zhaoxia, and Fan Xiaoya. XML component-based mode-ling for digital circuits. In 2010 Second Pacific-Asia Conference on Circuits,Communications and System, pages 148–151. IEEE, August 2010.

[Gaj99] D.D. Gajski. IP-based design methodology. In Proceedings. 36th of theDesign Automation Conference, 1999., page 43. IEEE, 1999.

[GBTG04] M.E. Grandmaison, J. Belzile, C. Thibeault, and F. Gagnon. Reconfigurableand efficient FFT/IFFT architecture. In Canadian Conference on Electricaland Computer Engineering 2004 (IEEE Cat. No.04CH37513), pages 1115–1118. IEEE, 2004.

[GC93] Emil Girczyc and Steve Carlson. Increasing design quality and engineeringproductivity through design reuse. In Proceedings of the 30th internationalDesign Automation Conference, pages 48–53. ACM, 1993.

[GC04] Z. Guoping and F. Chen. Parallel FFT with CORDIC for ultra wide band. In2004 IEEE 15th International Symposium on Personal, Indoor and MobileRadio Communications (IEEE Cat. No.04TH8754), pages 1173–1177. IEEE,2004.

[GGSG11] Mario Garrido, Jesus Grajal, Miguel A. Sanchez, and Oscar Gustafsson.Pipelined Radix- 2ˆk Feedforward FFT Architectures. IEEE Transactionson Very Large Scale Integration Systems, 2011.

186 BIBLIOGRAFIA

[Ghe06] Frank Ghenassia. Transaction-Level Modeling with Systemc: Tlm Conceptsand Applications for Embedded Systems. Springer-Verlag New York, Inc.,January 2006.

[GYOS+11] Jesus Grajal, Omar Yeste-Ojeda, Miguel A. Sanchez, Mario Garrido, andMarisa Lopez-Vallejo. Real Time FPGA Implementation of an ModulationClassifier for Electronic Warfare Applications. In 19th European Signal Pro-cessing Conference, number Eusipco, pages 1514–1518, 2011.

[GZD+00] Daniel D. Gajski, Jianwen Zhu, Rainer Domer, Andreas Gerstlauer, andShuqing Zhao. SpecC: Specification Language and Methodology. KluwerAcademic Publishers, 2000.

[HA00] J.C. Hoe and Arvind. Synthesis of operation-centric hardware descrip-tions. In Proceedings of the 2000 IEEE/ACM international conference onComputer-aided design, pages 511–519. IEEE Press, 2000.

[HA03] M. Hasan and T. Arslan. Implementation of low-power FFT processor coresusing a novel order-based processing scheme. IEE Proceedings - Circuits,Devices and Systems, 150(3):149, 2003.

[HASLVE08] I. Herrera-Alzu, Miguel A. Sanchez, Marisa Lopez-Vallejo, and P. Echeverria.Experimental methodology for power characterization of FPGAs. In 200815th IEEE International Conference on Electronics, Circuits and Systems,pages 582–585. IEEE, August 2008.

[Haw] T. Hawkings. Confluent, http://www.confluent.org.

[HMP05] C. Huggett, K. Maharatna, and K. Paul. On the Implementation of 128-Pt FFT/IFFT for High-Performance WPAN. In 2005 IEEE InternationalSymposium on Circuits and Systems, pages 5513–5516. IEEE, 2005.

[HN00] B.L. Hutchings and B.E. Nelson. Using general-purpose programming lan-guages for FPGA design. In Proceedings 37th Design Automation Conferen-ce, pages 561–566. IEEE, 2000.

[IEE93] IEEE SA - 1076-1993 - IEEE Standard VHDL Language Reference Manual,http://standards.ieee.org/findstds/standard/1076-1993.html, 1993.

[IEE05] IEEE SA - 1364-2005 - IEEE Standard for Verilog HardwareDescription Language, http://standards.ieee.org/findstds/standard/1364-2005.html, 2005.

[IEE11a] IEEE SA - 1666-2011 - IEEE Draft Standard forStandard SystemC(R) Language Reference Manual,http://standards.ieee.org/findstds/standard/1666-2011.html, 2011.

[IEE11b] IEEE SA - 62530-2011 - IEEE SystemVerilog - UnifiedHardware Design, Specification, and Verification Language,http://standards.ieee.org/findstds/standard/62530-2011.html, 2011.

BIBLIOGRAFIA 187

[JBP+02] Alex Jones, Debabrata Bagchi, Satrajit Pal, Xiaoyong Tang, Alok Choud-hary, and Prith Banerjee. PACT HDL: A C compiler targeting asics andfpgas with power and performance optimizations. In Proceedings of the 2002international conference on Compilers, architecture, and synthesis for em-bedded systems, pages 188–197. ACM, 2002.

[JP01] M.F. Jacome and H.P. Peixoto. A survey of digital design reuse. IEEEDesign & Test of Computers, 18(3):98–107, 2001.

[KBS04] Chidamber Kulkarni, Gordon Brebner, and Graham Schelle. Mapping adomain specific language to a platform FPGA. In Proceedings of the 41stannual conference on Design automation - DAC ’04, page 924, New York,New York, USA, June 2004. ACM Press.

[KHG03] Zhong Kai, He Hui, and Zhu Guangxi. An ultra high-speed FFT processor.In SCS 2003. International Symposium on Signals, Circuits and Systems.Proceedings (Cat. No.03EX720), volume 1, pages 37–40. IEEE, 2003.

[KJRN03] S. Kiran, MN Jayram, P. Rao, and SK Nandy. A complexity effective com-munication model for behavioral modeling of signal processing applications.In Proceedings of the 40th annual Design Automation Conference, pages412–415. ACM, 2003.

[KNRSV00] K. Keutzer, A.R. Newton, J.M. Rabaey, and A. Sangiovanni-Vincentelli.System-level design: orthogonalization of concerns and platform-based de-sign. IEEE Transactions on Computer-Aided Design of Integrated Circuitsand Systems, 19(12):1523–1543, 2000.

[LCHC03] Fei Li, Deming Chen, Lei He, and Jason Cong. Architecture evaluation forpower-efficient FPGAs. In Proceedings of the 2003 ACM/SIGDA eleventhinternational symposium on Field programmable gate arrays - FPGA ’03,page 175, New York, New York, USA, February 2003. ACM Press.

[Lee00] M. Leeser. HML, a novel hardware description language and its transla-tion to VHDL. IEEE Transactions on Very Large Scale Integration (VLSI)Systems, 8(1):1–8, February 2000.

[LJ00] Chien-Nan Jimmy Liu and Jing-Yang Jou. An automatic controller extrac-tor for HDL descriptions at the RTL. IEEE Design & Test of Computers,17(3):72–77, 2000.

[LL95] Y. Li and Miriam Leeser. HML: an innovative hardware description lan-guage and its translation to VHDL. In Design Automation Conference,1995. Proceedings of the ASP-DAC’95/CHDL’95/VLSI’95., IFIP Interna-tional Conference on Hardware Description Languages; IFIP InternationalConference on Very Large Scale Integration., Asian and South Pacific, pages691–696. IEEE, 1995.

[LRnGSO05] G. Lopez-Risueno, J. Grajal, and A. Sanz-Osorio. Digital channelized recei-ver based on time-frequency analysis for signal interception. IEEE Transac-tions on Aerospace and Electronic Systems, 41, 2005.

188 BIBLIOGRAFIA

[LSV11] Edward A. Lee and Alberto L. Sangiovanni-Vincentelli. Component-baseddesign for the future. In Design, Automation & Test in Europe Conference& Exhibition (DATE), pages 1–5. IEEE, 2011.

[MD03] A. Melnyk and B. Dunets. FFT Processor IP Cores synthesis on the base ofconfigurable pipeline architecture. In The Experience of Designing and Ap-plication of CAD Systems in Microelectronics, 2003. CADSM 2003. Procee-dings of the 7th International Conference., pages 211–213. Lviv PolytechnicNat. Univ, 2003.

[MFHP10] Peter A. Milder, Franz Franchetti, James C. Hoe, and Markus Puschel.Hardware implementation of the discrete fourier transform with non-power-of-two problem size. In 2010 IEEE International Conference on Acoustics,Speech and Signal Processing, pages 1546–1549. IEEE, 2010.

[Mic99] Giovanni De Micheli. Hardware synthesis from C/C++ models. DATE ’99Proceedings of the conference on Design, automation and test in Europe,1999.

[NWH+08] Brent Nelson, Michael Wirthlin, Brad Hutchings, Peter Athanas, and ShawnBohner. Design Productivity for Configurable Computing. In Proc. Int.Conf. Eng. of Reconfigurable Systems and Algorithms (ERSA 08), pages57–66, 2008.

[OGGN09] Jan-Hendrik Oetjens, Ralph Gorgen, Joachim Gerlach, and Wolfgang Ne-bel. An automated flow for integrating hardware IP into the automotivesystems engineering process. In Proceedings of the Conference on Design,Automation and Test in Europe, pages 1196–1201. European Design andAutomation Association, 2009.

[OGR06] J.H. Oetjens, Joachim Gerlach, and W. Rosenstiel. Flexible specificationand application of rule-based transformations in an automotive design flow.In Proceedings of the Design, Automation and Test in Europe (DATE’06).,volume 2, pages 1–6. IEEE, 2006.

[Pan01] Preeti Ranjan Panda. SystemC - a modeling platform supporting multipledesign abstractions. In Proceedings. The 14th International Symposium onSystem Synthesis, pages 75–80. IEEE, 2001.

[PD95] Preeti R. Panda and Nikil D. Dutt. 1995 high level synthesis design reposi-tory. In Proceedings of the 8th international symposium on System synthesis- ISSS ’95, pages 170–174, New York, New York, USA, 1995. ACM Press.

[Per93] D.L. Perry. VHDL. Mcgraw-Hill Series On Computer Engineering, 1993.

[Per02] Douglas L Perry. VHDL : Programming by Example. New York, page 476,2002.

[PHSMR95] Viktor Preis, Renate Henftling, Markus Schutz, and Sabine Marz-Rossel. Areuse scenario for the VHDL-based hardware design flow. In Proceedings ofthe conference on European design automation, pages 464–469, 1995.

BIBLIOGRAFIA 189

[PMJ+05] M. Puschel, J.M.F. Moura, J.R. Johnson, D. Padua, M.M. Veloso, B.W.Singer, F. Franchetti, A. Gacic, Y. Voronenko, K. Chen, R.W. Johnson, andN. Rizzolo. SPIRAL: Code Generation for DSP Transforms. Proceedings ofthe IEEE, 93(2):232–275, February 2005.

[PT05] David Pellerin and Scott Thibault. Practical fpga programming in c. April2005.

[RAW08] Nathaniel Rollins, Adam Arnesen, and Michael Wirthlin. An XML Schemafor Representing Reusable IP Cores for Reconfigurable Computing. In 2008IEEE National Aerospace and Electronics Conference, pages 190–197. IEEE,July 2008.

[rdf] RDF, http://www.w3.org/RDF/.

[Rem99] J.M. Remondeau. Scalable parallel architecture for ultra fast FFT in anFPGA. Proc. ICSPAT, 1999.

[RGAN00] M.H. Reshadi, B. Goji-Ara, and Z. Navabi. HDML: compiled VHDL inXML. In Proceedings VHDL International Users Forum Fall Workshop,pages 69–74. IEEE Comput. Society, 2000.

[RL10] Aruna Raja and Devika Lakshmanan. Domain Specific Languages. Inter-national Journal of Computer Applications IJCA, 1(21):105–111, 2010.

[RMBL05] Fernando Rincon, Francisco Moya, Jesus Barba, and Juan Carlos Lopez.Model Reuse through Hardware Design Patterns. In Design, Automationand Test in Europe, pages 324–329. Ieee, 2005.

[RSLVB11] Pablo Royer, Miguel Angel Sanchez, Marisa Lopez-Vallejo, and CarlosA. Lopez Barrio. Area-Efficient Linear Regression Architecture for Real-Time Signal Processing on FPGAs. In Design of Circuits and IntegratedSystems, 2011.

[SCG05] R.S. Sherratt, O. Cadenas, and N. Goswami. An efficient low power FFTimplementation for multiband full-rate ultra-wideband (UWB) receivers. InProceedings of the Ninth International Symposium on Consumer Electronics,2005. (ISCE 2005)., pages 209–214. IEEE, 2005.

[Sch97] R.R. Schaller. Moore’s law: past, present and future. IEEE Spectrum,34(6):52–59, June 1997.

[SCIC03] Moon Sang-Chul and Park In-Cheol. Area-efficient memory-based architec-ture for FFT processing. In Proceedings of the 2003 International Symposiumon Circuits and Systems, 2003. ISCAS ’03., volume 5. IEEE, 2003.

[SCV+99] Patrick Schaumont, Radim Cmar, Serge Vernalde, Marc Engels, and IvoBolsens. Hardware Reuse at the Behavioral Level. In Proceedings of the36th annual ACM/IEEE Design Automation Conference, pages 784–789.ACM, 1999.

190 BIBLIOGRAFIA

[SD04] Zhang Shiqun and Yu Dunshan. Design and implementation of a parallelreal-time FFT processor. In Proceedings. 7th International Conference onSolid-State and Integrated Circuits Technology, 2004., volume 3, pages 1665–1668. IEEE, 2004.

[SEMLV08] Miguel A. Sanchez, Pedro Echeverria, Francisco Mansilla, and Marisa Lopez-Vallejo. Designing highly parameterized hardware using xHDL. In 2008Forum on Specification, Verification and Design Languages, pages 78–83.IEEE, September 2008.

[SFHLV05] Miguel A. Sanchez, A. Fernandez-Herrero, and Marisa Lopez-Vallejo. xHDL:Extending VHDL to improve core parameterization and reuse. In PierreBoulet, editor, Advances in Design and Specification Languages for SoCs,pages 217–235. Kluwer Academic Publishers, Boston, 2005.

[SFLV04] Miguel A. Sanchez, A. Fernandez Herrero, and Marisa Lopez-Vallejo. IPCore reuse through the application of the meta-language xHDL. In Forumon Specification and Design Languages, Lille (France), 2004.

[SGLV+05a] Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, Jesus Grajal, andCarlos Lopez-Barrio. Digital channelised receivers on FPGAs platforms.In IEEE International Radar Conference, pages 816–821, Washington D.C.(E.E.U.U), 2005. IEEE.

[SGLV+05b] Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, Jesus Grajal, andCarlos Lopez-Barrio. Implementing the Monobit FFT on FPGA Platforms.In Design of Circuits and Integrated Systems, Lisboa (Portugal), 2005.

[SGLVG04] Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, and Jesus Gra-jal. Implementing the FFT algorithm in FPGA platforms: a comparativestudy of parallel architectures. In Design of Circuits and Integrated Systems,Burdeos (France), 2004.

[SGLVG08] Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, and Jesus Grajal.Implementing FFT-based digital channelized receivers on FPGA platforms.IEEE Transactions on Aerospace and Electronic Systems, 44(4):1567–1585,October 2008.

[SGLVLB06] Miguel A. Sanchez, Mario Garrido, Marisa Lopez-Vallejo, and Carlos Lopez-Barrio. Automated design space exploration of FPGA-based FFT architec-tures based on area and power estimation. In 2006 IEEE International Con-ference on Field Programmable Technology, pages 127–134, Bangkok (Thai-land), December 2006. IEEE.

[SP94] Naresh R. Shanbhag and Keshab K. Parhi. Pipelined Adaptive Digital Fil-ters. Kluwer Academic Publishers Norwell, January 1994.

[SS08] Valery Sklyarov and Iouliia Skliarova. Design and implementation of parallelhierarchical finite state machines. In 2008 Second International Conferenceon Communications and Electronics, pages 33–38. IEEE, June 2008.

BIBLIOGRAFIA 191

[Sti11] Greg Stitt. Are Field-Programmable Gate Arrays Ready for the Mains-tream? Micro, IEEE, 31(6):58–63, 2011.

[SWC04] Chris Sullivan, Alex Wilson, and Stephen Chappell. Using C based logicsynthesis to bridge the productivity gap. In Proceedings of the 2004 Asia andSouth Pacific Design Automation Conference, pages 349–354. IEEE Press,2004.

[SYD01] G. Szedo, V. Yang, and C. Dick. High-performance FFT processing usingreconfigurable logic. In Conference Record of Thirty-Fifth Asilomar Confe-rence on Signals, Systems and Computers (Cat.No.01CH37256), volume 2,pages 1353–1356. IEEE, 2001.

[SZH04] Xin Shi, Tiejun Zhang, and Chaohuan Hou. A high-performance power-efficient structure of FFT (fast fourier transform) processor. In Proceedings7th International Conference on Signal Processing, 2004. Proceedings. ICSP’04. 2004., volume 1, pages 555–558. IEEE, 2004.

[TI] Texas-Instruments. TI High Speed DAC, http://www.ti.com.

[TS02] J.B.Y. Tsui and J.P. Stephens. Digital microwave receiver technology. IEEETransactions on Microwave Theory and Techniques, 50(3):699–705, March2002.

[Tsu95] James Bao-yen Tsui. Digital techniques for wideband receivers. 1995.

[UAAB03] I.S. Uzun, A. Amira, A. AhmedSaid, and F. Bensaali. Towards a generalframework for an FPGA-based FFT coprocessor. In Seventh InternationalSymposium on Signal Processing and Its Applications, 2003. Proceedings.,pages 617–620 vol.1. IEEE, 2003.

[UAB05] I.S. Uzun, A. Amira, and A. Bouridane. FPGA implementations of fast Fou-rier transforms for real-time signal and image processing. IEE Proceedings- Vision, Image, and Signal Processing, 152(3):283, 2005.

[WM02] Michael J. Wirthlin and Brian McMurtrey. IP delivery for FPGAs usingapplets and JHDL. In Proceedings of the 39th annual Design AutomationConference, pages 2–7. ACM, 2002.

[WNH+08] Mike Wirthlin, Brent Nelson, Brad Hutchings, Peter Athanas, and ShawnBohner. FPGA Design Productivity. In FPGA Tool Flow Studies Workshop,2008.

[Xila] Xilinx. Silicon devices, http://www.xilinx.com.

[Xilb] Xilinx. Virtex-5 FPGA XtremeDSP Design Consideration - User Guide,http://www.xilinx.com.

[Xilc] Xilinx. Virtex-5 FPGA XtremeDSP Design Considerations User Guide,http://www.xilinx.com.

[Xild] Xilinx. Xilinx LogiCORE IP, http://www.xilinx.com.

192 BIBLIOGRAFIA

[xml] XML Schema, http://www.w3.org/XML/Schema.

[XSAH10] Jimmy Xu, Nikhil Subramanian, Adam Alessio, and Scott Hauck. Impulse Cvs. VHDL for Accelerating Tomographic Reconstruction. In 2010 18th IEEEAnnual International Symposium on Field-Programmable Custom Compu-ting Machines, pages 171–174. IEEE, May 2010.

[Yut99] Ma Yutai. An effective memory addressing scheme for FFT processors. IEEETransactions on Signal Processing, 47(3):907–911, March 1999.

[ZGH08] Meng Zhou, Minglun Gao, and XiaoSong Huo. Design method for parame-terized IP generator using structural and creational design patterns. In 20082nd International Conference on Anti-counterfeiting, Security and Identifi-cation, pages 378–381. IEEE, 2008.

[Zhu01] Jianwen Zhu. MetaRTL: Raising the abstraction level of RTL design. InDesign, Automation and Test in Europe, pages 71–76. IEEE, 2001.

[ZTJ06] N.E. Zergainoh, Ludovic Tambour, and A.A. Jerraya. Automatic delay co-rrection method for IP block-based design of VLSI dedicated digital sig-nal processing systems: theoretical foundations and implementation. IEEETransactions on Very Large Scale Integration (VLSI) Systems, 14(4):349–360, 2006.

TESIS DOCTORAL IMPLEMENTACION DE …oa.upm.es/13616/1/MIGUEL_ANGEL_SANCHEZ_MARCOS.pdf · tesis...

Documents

Transcript of TESIS DOCTORAL IMPLEMENTACION DE …oa.upm.es/13616/1/MIGUEL_ANGEL_SANCHEZ_MARCOS.pdf · tesis...