Implementación de digital audio broadcasting en un DSP

(1)

Sistemas Informáticos

Curso 2007-2008

Implementación de

Digital Audio BroadCasting en un DSP

Autores:

Miguel Sánchez Pecharromán.

Jesús Mascías Santa María.

Director:

Profesor Luis Piñuel Moreno.

Departamento de Arquitectura de Computadores y Automática.

Facultad de Informática

(2)

(3)

i

Implementación de Digital Audio Broadcasting en un DSP

Índice de contenidos

ÍNDICE DE CONTENIDOS ... I ÍNDICE DE TABLAS... II ÍNDICE DE ILUSTRACIONES ... III PALABRAS CLAVE ... V CESIÓN DE DERECHOS ... VII RESUMEN ... IX ABSTRACT ... X

INTRODUCCIÓN ... 1

CAPÍTULO 1. DIGITAL AUDIO BROADCASTING ... 5

1.1INTRODUCCIÓN ... 5

1.2ESTRUCTURA DE LA TRANSMISION ... 6

1.2.1 Fast Information Channel ... 7

1.2.1.1 FIG tipo 0 ... 9

1.2.1.2 FIG tipo 1 ... 10

1.2.2 Main Service Channel ... 11

1.3MULTIPLEX CONFIGURATION INFORMATION (MCI) ... 14

1.3.1 Organización de los subcanales ... 15

1.3.2 Organización de los servicios ... 16

1.4ESTRUCTURA GENERAL DE DAB ... 17

CAPÍTULO 2. PROCESADOR COOLFLUX DSP ... 19

2.1.INTRODUCCIÓN ... 19 2.2.ARQUITECTURA ... 22 2.2.1 Características generales ... 22 2.2.2 Descripción de la Arquitectura ... 23 2.2.3 Repertorio de Instrucciones ... 27 2.2.4 Pipeline ... 27

2.2.5 Conversión de tipos: Unidades RSS ... 28

2.2.6 Instrucciones multiciclo y delay slots ... 30

2.2.7 Modos de direccionamiento ... 31

2.2.8 Bucles hardware ... 32

2.2.9 Interrupciones ... 33

2.2.10 Soporte para la integración en módulos multicore. ... 34

2.3ENFOQUE SOFTWARE ... 34

2.4.FLUJO DE DESARROLLO DE SOFTWARE... 37

CAPÍTULO 3. DETALLES DE LA IMPLEMENTACIÓN ... 39

3.1ESTUDIO GENERAL ... 42

3.2ESTUDIO MODULAR ... 44

3.2.1 Automatic Gain Control ... 45

3.2.1.1 Introducción ... 45

3.2.1.2 Desarrollo de la implementación ... 46

3.2.1.3 Mejoras realizadas ... 50

3.2.1.4 Rendimiento parcial del módulo y pruebas ... 50

3.2.2 Modulo Demodulador diferencial ... 51

3.2.3 Frecuency de-interleaving ... 53

(4)

ii

3.2.3.3 Correcciones... 54

3.2.4 Quantization ... 57

3.2.5 Time De-Interleaving ... 61

3.2.6 DePuncturing ... 66

3.2.7 Decodificación Convolucional ... 76

3.2.8 Energy Dispersal Unscrambling: Dispersión de Energía ... 81

3.3PRUEBAS REALIZADAS ... 83 CAPÍTULO 4. CONCLUSIONES ... 86 4.1RENDIMIENTO ... 86 4.2DSPS NECESARIOS ... 87 4.3ESTUDIO DE VIABILIDAD ... 88 4.4ASPECTOS FUTUROS ... 88 4.4.1 Fuera de objetivo ... 88 4.4.2 Dentro de objetivo ... 89 4.5DIFICULTADES ENCONTRADAS ... 89 BIBLIOGRAFÍA ... 90

Índice de tablas

Tabla 1: Modos de transmisión. ... 7

Tabla 2: Configuración Packet Length del MSC. ...12

Tabla 3: Rendimiento Power Media ...50

Tabla 4: Rendimiento Demodulador Diferencial. ...52

Tabla 5: Rendimiento Frequency de-Interleaving por módulos. ...55

Tabla 6: Rendimiento de memoria Frequency de-Interleaving. ...56

Tabla 7: Configuración Time de-Interleaving. ...61

Tabla 8: Rendimiento en ciclos Time de-Interleaving. ...65

Tabla 9 Rendimiento en memoria Time de-Interleaving. ...65

Tabla 10: Configuración de-Puncturing. ...68

Tabla 11: Codeword dependiente del modo de transmisión. ...69

Tabla 12: Perfiles de Protección UEP ...70

Tabla 13: Perfiles de protección EEP para tasas de bits múltiplos de 8 ...71

(5)

iii

Tabla 15: Rendimiento De-Puncturing. ... 75

Tabla 16: Rendimiento Unscrambling. ... 83

Tabla 17: Rendimiento total por módulos. ... 86

Índice de ilustraciones

Ilustración 1: Situación del desarrollo del DAB en diferentes países del mundo. [15] ... 2

Ilustración 2: Estructura de la transmisión ... 6

Ilustración 3: Estructura de FIB ... 8

Ilustración 4: Estructura de FIG 0 ... 9

Ilustración 5: Estructura de FIG 1 ... 10

Ilustración 6: Estructura del MSC ... 12

Ilustración 7: Composición del MSC. ... 13

Ilustración 8:Estructura MSC... 13

Ilustración 9: Estructura de los subcanales ... 15

Ilustración 10: Estructura de los servicios ... 17

Ilustración 11: Estructura de Checkmate para CoolFlux DSP ... 22

Ilustración 12: Unidades de direccionamiento, buses Xbus e Ybus, memorias, DMA y unidad de control de programa... 25

Ilustración 13: Ruta de datos, unidades RSS y buses de comunicación Xbus e Ybus ... 26

Ilustración 14: Pipeline de instrucciones no de control. ... 30

Ilustración 15: Pipeline con paradas. ... 30

Ilustración 16: División en módulos del FIC decoding. ... 39

Ilustración 17: División en módulos del MSC decoding. ... 40

Ilustración 18: División en módulos de la demodulación. ... 41

Ilustración 19: Estructura complex12 ... 47

Ilustración 20: Estructura complex28. ... 47

Ilustración 21: Complex28 Shift a la derecha 12. ... 47

Ilustración 22: Energy Acc. ... 48

Ilustración 23: Lfix media... 48

Ilustración 24: MaxMedia ... 48

Ilustración 25: Media. ... 49

Ilustración 26: Frequency de-Interleaving. ... 53

Ilustración 27: Módulo Frequency de-Interleaving. ... 53

Ilustración 28: Modulación QPSK-4 ... 58

Ilustración 29: Time de-Interleaving. ... 62

Ilustración 30: DePuncturing ... 66

Ilustración 31: Módulo Decodificador convolucional. ... 76

Ilustración 32: Diagrama de Trellis. ... 77

(6)

(7)

v

Palabras Clave

DAB

COOLFLUX

MICROPROCESADOR

DSP

BROADCASTING

RADIO

(8)

(9)

vii

Cesión de derechos

Por la presente, los autores de este proyecto, autorizan a la Universidad Complutense de Madrid a difundir y utilizar con fines académicos, no comerciales y mencionando expresamente a sus autores, tanto la propia memoria, como el código implementado y/o la documentación.

Firmado:

(10)

(11)

ix

Resumen

Dentro del contexto del apagón analógico, previsto en Europa para los primeros años de la segunda década del siglo XXI, los sistemas de transmisión de información digital por radiofrecuencia están en claro proceso de implantación y consolidación. Uno de los sistemas de radio digital más importantes es el Digital Audio Broadcasting (DAB). Las redes de emisión de DAB están operativas en la mayor parte de territorio europeo, y existe una oferta lo suficientemente amplia de sistemas de recepción de DAB para estaciones de radio domésticas y automovilísticas. Sin embargo, el mercado de receptores sufre una ausencia de dispositivos portátiles. Este gap tecnológico ha abierto una carrera entre los fabricantes de silicio para lograr un sistema de recepción de DAB que permita la portabilidad del equipo huésped, y con bajo requerimiento energético.

Los principales sistemas de radio digital han sido diseñados siguiendo un enfoque software, lo que permite tener hardware muy similar para diferentes estándares y ofrece la posibilidad de hacer frente a actualizaciones o adaptaciones sucesivas de los estándares de comunicación mediante demodulación/decodificación por software.

En este documento se presentará el desarrollo del software de un sistema de recepción de DAB para CoolFlux, un DSP de consumo ultraligero específico para dispositivos móviles de carga limitada. Para realizar dicho desarrollo se han utilizado diferentes técnicas de optimización combinadas siguiendo un enfoque holístico, adaptadas a las características del procesador. Algunas de estas técnicas serán descritas en este documento, así como las características fundamentales del sistema de comunicación y el procesador utilizados para su implementación.

El primer estudio de viabilidad ha ofrecido unos resultados satisfactorios en lo referente a los requerimientos de procesador que serían necesarios para la implementación, siendo posible realizar la recepción de DAB utilizando un único DSP.

(12)

x

Abstract

Within the context of the analogue switch-off expected to be completed for the first years of the second decade of XXI century in Europe, the RF digital data transmission systems are in process of introduction and consolidation. One of the most important digital radio systems is Digital Audio Broadcasting (DAB). The DAB broadcasting networks are already operational in most European territory, and there is a sufficiently broad range of systems for receiving DAB in domestic and automobile radio stations. However, the receivers market suffers a lack of portable devices. This technological gap has started a challenge between the silicon companies which goal is to achieve a DAB reception system that allows the portability of the host device with ultra-low power consumption.

The main digital radio systems have been designed following a software approach, which allows having very similar hardware for different standards and managing standard updates/adaptations efficiently through software demodulation/decoding.

This document will present the software developement of a DAB receiver for CoolFlux, an ultra-low power DSP core which targets mobile devices of limited charge. To make this development, different processor-adapted optimization techniques have been merged following an holistic approach. Some of these techniques will be outlined in this document, as well as the main features of the communication system and processor used for its implementation.

The first feasibility study has offered a satisfactory outcome regarding the processor requirements that would be necessary for the implementation, showing that is possible to develop DAB reception using one DSP.

(13)

(14)

(15)

1 Introducción

Este proyecto de sistemas informáticos ha consistido en el desarrollo de una aplicación de recepción de señal de radio digital, DAB (Digital Audio Broadcasting), para su inclusión a modo de funcionalidad software en la oferta de aplicaciones del procesador CoolFlux DSP.

CoolFlux DSP es una arquitectura especializada en el proceso de señales de audio. Este procesador forma parte de la oferta tecnológica de la compañía NXP Semiconductors, compañía holandesa que dispone de unas instalaciones de desarrollo de tecnología en el DSP valley de Leuven, lugar en el cual se ha desarrollado el proyecto

El interés de la compañía en la realización de este proyecto de sistemas informáticos responde a dos cuestiones principales:

En primer lugar, la metodología de desarrollo del procesador CoolFlux DSP por parte de la empresa. Esta metodología está basada en sucesivas iteraciones que se sirven del desarrollo de aplicaciones software de sistemas de comunicación reales para evaluar las prestaciones de dicho procesador y decidir así los objetivos y características a implementar y/o modificar en las siguientes generaciones del mismo. En este sentido, el sistema DAB es un sistema de telecomunicación real de audio y datos que podría servir perfectamente para testear la robustez y versatilidad de CoolFlux en el tratamiento de la señal. Otras aproximaciones similares siguiendo la misma política de desarrollo han sido la implementación de decodificadores de mp3 y la realización de una librería matemática que pudiera servir como soporte a futuros programadores de sistemas complejos.

En segundo lugar, el motivo principal del desarrollo: la aparición del sistema DAB (Digital Audio Broadcasting) en 1987, con el proyecto impulsado por la Unión Europea de Radiodifusión (UER) denominado Eureka 147, la cual derivó en un creciente interés por parte de compañías del rubro tecnológico en las posibilidades de esta tecnología y por tanto en la necesidad de abordar el diseño de nuevos equipos que permitieran la explotación de los servicios que este sistema de comunicación pudiera proporcionar. En 1995 se dio el siguiente paso para la explotación del sistema, cuando el European Telecommunication Standard Institute (ETSI) adoptó el sistema DAB como estándar único europeo [2]. A nivel mundial, las recomendaciones BS 11 14 y BS 11 30 de la International Telecommunications Union (ITU) sugieren la utilización de DAB como sistema para la difusión terrestre y por satélite, respectivamente.

Actualmente, DAB está entrando en la fase de implantación en varios países europeos, algunos de los cuales ya han programado la desconexión analógica para mediados de la segúnda década del siglo XXI. Existen multitud de proyectos en marcha, tanto en Europa como en otras partes del mundo, como puede apreciarse en la Ilustración 1.

(16)

2

Ilustración 1: Situación del desarrollo del DAB en diferentes países del mundo. [15]

Debido al alto grado de desarrollo de infraestructuras de emisión de este tipo de señal de radio digital y a su madurez tecnológica, se han abierto nuevos horizontes en el mercado de los dispositivos digitales. Países como Francia (TDF), Reino Unido (BBC), Alemania (Deutsche Telekom) y la propia España tienen compañías dedicadas al establecimiento de una red de transmisión fiable, por lo que se prevee que en la mayoría de los países Europeos el sistema de comunicación DAB se imponga de aquí a unos años. No en vano, en la actualidad existen más de 400 servicios DAB en emisión en todo el mundo, los cuales alcanzan a una población de aproximadamente 230 millones de personas. [15] [16]

La definitiva aceptación e incipiente operatividad del sistema a nivel nacional e internacional motivará, más pronto que tarde, una estabilización definitiva de la demanda en el sector por parte de los usuarios, que desearán adquirir tanto equipos móviles de recepción de DAB (automóvil, radios de bolsillo) como equipos destinados a la recepción fija.

El mercado de los receptores ha sido hasta ahora ocupado por receptores estáticos o receptores destinados a su integración como accesorios de automóviles. Los receptores portátiles son los que presentan un mayor problema de diseño debido a la limitación que han de presentar tanto de tamaño como de consumo eléctrico (lo que repercute de forma drástica a su vez, también en el tamaño, debido a las baterías eléctricas); es en esto en lo que su implantación encuentra un problema a día de hoy no atendido; puesto que tienen un muy alto consumo en comparación con otras tecnologías portátiles, lo que hay que añadir ya a la de por sí alta diferencia en el precio del receptor. La ausencia de receptores a bajo coste se percibe como un factor crítico para la digitalización de la radio, por lo que la empresa que consiga integrar DAB en productos que ya gozan de cierto grado de competitividad en el mercado de los receptores móviles destinados al usuario, obtendrá una posición ventajosa en el momento en el que DAB se convierta en hegemónico.

(17)

3

Por tanto, el interés de la compañía en la implementación de DAB es doble. Por un lado encontramos la necesidad de hacer una primera aproximación al sistema para comprobar la viabilidad de su realización y un cálculo preliminar de los requerimientos tecnológicos que presenta la recepción. Interesa sobre todo su coste aproximado en términos de consumo de ciclos de procesador con el fin de su implementación y desarrollo como aplicación comercial. En segunda instancia, como test de de un sistema real útil para comprobar, depurar e incrementar el rendimiento y las prestaciones del DSP CoolFlux, descubrir errores y estudiar la posibilidad de incluir nuevas estructuras hardware para optimizar tanto el consumo de potencia del procesador como el rendimiento en ejecución de operaciones comunes a varios sistemas de comunicación que requieren tratamiento de audio, como lo es por ejemplo FFT (Fast Fourier Transform).

Este proyecto ha sido realizado íntegramente en las instalaciones de NXP en Leuven por parte de dos alumnos a los que se les asignó el mismo grupo de desarrollo. Para la realización del proyecto ha sido necesaria una alta dosis de trabajo en equipo de modo que, como podremos ver más adelante, las tareas a realizar una vez planificado el diseño eran semi-independientes, por lo que se repartieron entre los dos componentes del proyecto. A pesar de la independencia de las tareas comentadas, durante todo el proceso fue necesaria una comunicación continua entre los dos miembros del equipo de trabajo y el supervisor, el cual tuvo que tener conocimiento del proceso, avances y problemas que se iban encontrando. Este tercer y último participante del grupo de desarrollo en el proceso tenía la función de supervisar el camino que iba llevando el proyecto, pero además, tuvo dos roles muy importantes:

- el primero, el de resolver dudas y cuestiones. Como se ha explicado, era un proyecto innovador y con conceptos nuevos para los alumnos, por lo que la ayuda del tutor del proyecto en la empresa fue necesaria en varias ocasiones.

- además, ejercía de intercomunicador, pues sirvió de eslabón en la comunicación con otros grupos de trabajo cuando demandamos ciertos cambios o documentos. Durante todo el tiempo de desarrollo del proyecto, siempre se tuvo en mente la necesidad de generar una buena documentación sobre el producto que se estaba creando. No era una documentación totalmente orientada al consumidor final, pues como ya se ha dicho, se trataba de un estudio de viabilidad para un futuro desarrollo. Por lo tanto esta documentación fue orientada a que un posible futuro programador entendiese el por qué de una función o atributo y supiese continuar o adaptar nuestra implementación.

El proyecto realizado consta de los siguientes cuatro capítulos.

El primer capítulo contiene una presentación de las características generales del sistema de radio digital DAB, así como una descripción de la trama de transmisión de datos y de la forma en que dichos datos son transmitidos en este estándar de comunicación.

El segundo capítulo consta de la presentación y descripción del procesador CoolFlux DSP. Se presentan sus características principales, su importancia en el panorama del Silicio y sus objetivos de diseño. A continuación se proporciona información detallada sobre su arquitectura y características técnicas, así como también una breve descripción de las herramientas de desarrollo existentes para dicho procesador.

(18)

4

En el tercer capítulo viene presentada la implementación realizada, partiendo del alcance del proyecto y las decisiones generales de diseño, para finalizar con un análisis exhaustivo de cada módulo desarrollado en sus vertientes de diseño, implementación y medidas de rendimiento.

En el cuarto capítulo se presenta el análisis de los resultados obtenidos en la implementación, centrándose en las medidas de rendimiento más importantes para el procesador CoolFlux, el número de ciclos de procesador y la memoria necesaria. También son presentadas las conclusiones derivadas de la realización del proyecto, y se comentan las dificultades encontradas.

(19)

5 Capítulo 1. Digital Audio Broadcasting

1.1 Introducción

La función elegida para ser implementada en el DSP es un sistema en desarrollo de radiodifusión de audio digital. Está orientado a la recepción móvil aunque también existen receptores domésticos para un uso estático. La difusión puede ser tanto terrestre como a través de satélites y además como se irá explicando, es un sistema capaz de incluir tanto audio como datos en su transmisión.

El sistema lleva funcionando en pruebas desde 1995, siendo los países pioneros Inglaterra y Suecia, más adelante se unió Alemania, y en 1996 comenzó España mediante Radio Nacional de España [16]. El proyecto se conoce mundialmente como EUREKA-147 donde se pretende que las diferentes partes involucradas en el proyecto (proveedores, administraciones públicas, empresas privadas, etc.) establezcan bases para conseguir una radiodifusión con calidad de CD.

El sistema DAB se basa en dos tecnologías fundamentales:

- MUSICAM: es un tipo de compresión de datos utilizado para establecer las

capas del MPEG, el cual elimina partes del sonido que no sean necesarias, pues son solapadas por otras frecuencias, o serían obviadas por el oído humano.

- COFDM: La modulación por multiplexado por división de frecuencia

ortogonal codificada es una ampliación de la tecnología OFDM, la cual utiliza varias portadoras simultáneamente siempre ortogonales pero modulada cada una de ellas en amplitud y fase. LA única diferencia entre la modulación utilizada en el DAB y la OFDM, es que la COFDM está diseñada añadiéndole una codificación del canal que permite la detección y corrección de errores. Estas técnicas aportan varios beneficios al nuevo sistema de radio como por ejemplo ayudar a evitar interferencias debidas a efectos multicamino, es decir, cuando una portadora llega al receptor por dos caminos distintos y con un retraso, esto, se puede proteger estableciendo un intervalo de guarda entre símbolos consecutivos.

A continuación se va a explicar la estructura utilizada para la transmisión de datos. Para realizar esta transmisión es necesario, utilizar datos para sincronizar cada portadora, para rellenar la información del sistema (tipo de codificación utilizada, protección, etc.). Además, es necesario, como es obvio, enviar tanto los datos como el audio que se desean enviar al receptor. Para cualquier ampliación de la información de este capítulo se recomienda la lectura del estándar de DAB cuyo enlace se puede encontrar en el punto [2] de la bibliografía.

(20)

6 1.2 Estructura de la transmisión

Ilustración 2: Estructura de la transmisión

Cada portadora usada en la transmisión, se divide en tres partes fundamentales: - Sychronization Channel (SC): Es la parte usada para poder realizar la

sincronización del canal. Esta sección está compuesta por los dos primeros símbolos OFDM recibidos en la transmisión. El primero se corresponde con el

Null Symbol el cual es utilizado para conocer donde comienza la transmisión,

dicho símbolo se detecta gracias a que su energía es cero (en ciertos casos podría contener cierta información, pero no será tratado en este documento). El segundo símbolo es el Phase Referente Symbol, donde se encuentra la información necesaria para la modulación diferencial del siguiente símbolo, pues éstos pueden llegar desfasados al receptor, y como explicaremos más adelante, el receptor se encarga de alinear para su futura descodificación. - Fast Information Channel (FIC): Está compuesto por bloques del mismo

tamaño, llamados Fast Information Blocas (FIB). En esta sección del sistema se encuentra la información correspondiente a la información del sistema, como por ejemplo, hora y fecha, configuración de multiplexación, información para una reconfiguración, número de subcanales, etc. Como veremos en un estudio en profundidad de esta parte de la estructura realizado más adelante, dependiendo del tipo de boques que contengan los FIB, variará la clase de información aportada por el FIC.

- Main Service Channel (MSC): La última parte de la estructura, se

corresponde con la propia información que se desea transmitir. Ésta puede ser tanto de datos como de audio, pues como hemos comentado anteriormente, una de las ventajas del DAB, es la posibilidad de transmitir tanto audio como datos, además se puede transmitir esta información y hacerla corresponder con

(21)

7

diferentes subcanales. El MSC está construido a partir de Common Interleaved

Frames (CIFs), y cada CIF ocupa 55296 bits. El número de CISS y de

subcanales incluidos en el MSC variará dependiendo de ciertas circunstancias que se valorarán, como ya hemos comentado, en un estudio en profundidad realizado sobre el FIC y el MSC, que podemos encontrar a continuación.

1.2.1 Fast Information Channel

La razón de dedicar un apartado específico para el FIC y otro para el MSC, es la cantidad de información relevante que transmiten y, aunque la información del SC también es vital para la transmisión, su función se ha podido resumir brevemente. Sin embargo, el FIC, dependiendo del tipo de datos que contengan, así será su información.

En la siguiente tabla se puede observar que dependiendo de la duración de la transmisión, variará el número de FIBs y CIFs contenidos en la estructura, y por tanto, el tamaño del FIC y el MSC.

Tabla 1: Modos de transmisión. Modo de

transmisión

Duración de la transmisión Número de FIBs Número de CIFs

I 96 ms 12 4

II 24 ms 3 1

III 24 ms 4 1

IV 48 ms 6 2

Como ya hemos comentado, el FIC está compuesto por FIBs, bloques del mismo tamaño, 30 bytes más 16 bits de CRC. A su vez, estos FIBs están construidos a partir de FIGs y otras etiquetas.

(22)

8

Ilustración 3: Estructura de FIB

En la ilustración 3, se puede observar como cada FIB está compuesto de varios FIGs, un campo de señalización del final de los campos FIG (End Maker, ocho 1’s, que en realidad son un tipo especial de cabecera del FIG), y un campo llamado Padding utilizado para completar con ceros aquellos bits que no hayan sido utilizados por los FIG en caso de que no se utilicen tantos FIG como sean necesarios para completar el FIB.

Antes de empezar a estudiar la composición de un FIG, es importante resaltar la importancia del campo CRC, el cual es utilizado para confirmar, mediante redundancia, la correcta recepción de los datos del FIB.

Ahora sí, podemos explicar que el FIG tiene varios campos:

- Tipo de FIG (FIG type): 3 bits que sirven para identificar el tipo de datos que

están contenidos en el FIG. Existen codificaciones específicas para referirse a cada tipo de FIG definidas en el Standard Europeo de DAB.

- Tamaño (Length): Los cinco bits que componen este campo representan la

longitud en bytes del campo de datos del FIG. Está expresado en números binarios sin signo y los valores 0,30, y 31 están reservados. El campo anterior y este componen la cabecera del FIG, es decir, cuando estos dos campos son todo 1’s, el sistema entiende que se trata del End Maker del FIB.

- Campo de datos del FIG (FIG data field): Este campo se puede resumir

como el campo dónde se transmiten los datos de configuración del sistema. Aunque si sólo nos fijamos en este breve resumen, estaríamos obviando numerosos detalles importantes, por eso, a continuación se hace una

(23)

9

exposición detallada de algunos de los más relevantes tipos de datos que puede contener este campo dependiendo del tipo de FIG.

1.2.1.1 FIG tipo 0

Ilustración 4: Estructura de FIG 0

Este tipo de FIG es utilizado para señalizar una inminente o futura reconfiguración de la multiplexación, hora y fecha, y otra información básica del sistema. En la figura se puede ver como la configuración de este tipo de FIG se corresponde con “000”.

Veamos el significado de los campos que componen los datos del FIG:

- C/N (Current / Next): Mediante un cero, este campo especifica que la

información enviada, se refiere a la actual configuración. Si el campo contiene el valor “1”, toda la información contenida se corresponde con una futura reconfiguración. También puede extenderse esta información a conceptos relativos a una base de datos, pero estos son casos específicos no tratados en este proyecto.

- OE (Other Ensemble): Un bit que indica si la información contenida se refiere

al sistema actual (“0”), o a otro (FM o AM). El significado de este campo, así como el de los demás del FIG data field puede tomar otros significados dependiendo del campo de la extensión, del cual hablaremos a continuación. De todos modos, es importante resaltar que toda esta información se puede ampliar con otros documentos, pues aquí sólo estamos tratando los casos específicos utilizados en nuestros proyectos.

- P/D: Si el valor de este campo es un “0”, el significado que tomará es que el

identificador del servicio se codificará mediante 16 bits, en caso contrario la codificación ocupará 32 bits.

(24)

10

- Extensión: Sirve para mediante 5 bits poder ampliar el significado de los datos

del tipo del FIG, es decir, crear nuevos subtipos dentro de este FIG.

- Type 0 field: Campo concreto donde se encapsulará la información que se

desea transmitir al sistema.

1.2.1.2 FIG tipo 1

Ilustración 5: Estructura de FIG 1

Debido al parecido entre las estructuras de los diferentes tipos de FIG, sólo se van a mostrar en este documento el tipo 0 y 1. Sí es importante comentar que otros tipos como el 5 y el 6 sirven para transmitir información relativa al Acceso Condicional del sistema (opción a incorporar en la implementación del DAB), o al Fast Information Data Channel (FIDC, utilizado cuando se desea transmitir información, que debería ir incluida en el MSC, a través del FIC).

Se puede observar que la configuración utilizada para definir este tipo de FIG es “001”. Este tipo define las etiquetas para mostrar y otra información relativa a ellas. Como se puede ver en la imagen, sus campos son:

- Charset: Se trata de 4 bits utilizados para identificar el grupo de caracteres

utilizados para clasificar los caracteres contenidos dentro de los datos de este FIG.

- OE: Este bit tiene el mismo significado que en el FIG de tipo 0, es decir,

indicar si la información contenida hace referencia a este o a otro sistema. - Extension: Esta extensión de tres bits es usada para identificar el significado

del FIG tipo 1 en casos concretos. Estas extensiones de momento no han sido definidas por lo que su significado queda reservado.

(25)

11

1.2.2 Main Service Channel

El Main Service Channel es la parte de datos que contiene, generalmente, el audio y los datos que llegarán finalmente al usuario. Como ya hemos dicho, está compuesto por unidades llamadas Common Interleaved Frames (CIFs), y cada una tiene un tamaño de 55296 bits. La unidad mínima direccionable dentro de un CIF se llama Capacity Unit (CU), y tiene un tamaño de 64 bits. Por lo tanto, con los datos anteriores, podemos decir, que cada CIF contiene 864 CUs, identificados por direcciones de la 0 a la 863.

En otro nivel de abstracción del MSC, éste está dividido en subcanales. Cada subcanal contiene un número entero de CUs, y al ser un número entero, cada CU ha de ser exclusivo para cada subcanal, es decir, dos subcanales no pueden compartir el mismo CU. Los datos transportados en el MSC son divididos en ráfagas de 24 ms correspondiéndose con el tamaño de datos del subcanal de cada CIF. Cada ráfaga de datos constituye un periodo lógico, y cada uno de éstos se corresponde con un CIF. Los sucesivos CIFs son identificados por un contador de CIFs.

Aunque no se va a entrar en detalle en este estudio del DAB debido a que no fue demasiado relevante a la hora de desarrollar el proyecto, es importante comentar y explicar brevemente que existen dos modos de transporte en el MSC:

- Stream mode (modo de flujo): Este modo permite a la aplicación recibir y

repartir los datos de manera transparente desde el transmisor al receptor. Estos beneficios serán posibles siempre y cuando la tasa de datos esté fijada a un múltiplo de 8 Kbit/s. En este método, la aplicación también está capacitada para proveer información bajo demanda, o incluir un método de tratamiento asíncrono de datos para tasas más bajas. Otra particularidad de este modo es que sólo un componente de servicio puede ser transportado en cada subcanal. - Packet mode (modo de paquetes): Como diferencia principal entre este modo

y el anterior, podríamos resaltar que aquí si se permite que diferentes componentes de servicio sean transportados en el mismo subcanal. Por otra parte, como parecidos, en ambos modos la tasa de datos ha de ser múltiplo de 8 Kbit/s. Como particularidades de este método, cabe destacar que los datos pueden transportarse bien en grupos o bien en paquetes individuales. Existe un campo en la trama que indica cual de las dos opciones anteriores es la elegida para la transmisión. Cada paquete es identificado por una dirección. Esto permite que el envío de paquetes no sea ordenado, pues al recibir todos los paquetes se vuelve a construir la secuencia. Todos los paquetes tienen una longitud fija y existen cuatro longitudes diferentes permitidas que veremos más adelante. También existe la posibilidad de que paquetes con distintas longitudes sean enviados en el mismo subcanal, el cual está compuesto por varios paquetes. Aquí entra la labor de los paquetes de “padding” o relleno, son paquetes que se utilizan para completar la trama en caso de que no se quieran enviar suficientes paquetes, o las longitudes de éstos no sean suficientemente grandes. En la ilustración 6 se puede observar como todos los paquetes están compuestos por una cabecera, un campo de datos y un campo de CRC para comprobación de errores de transmisión.

(26)

12

Ilustración 6: Estructura del MSC

Como ya se ha comentado (y se puede observar en el primer campo de la ilustración 6), la longitud de cada paquete es fija, y viene dada por el campo “Packet Length”, que fija las posibles longitudes mediante 2 bits con la siguiente configuración.

Tabla 2: Configuración Packet Length del MSC.

Packet Length Longitud del paquete (bytes)

Longitud del campo de datos (bytes)

0 0 24 19

0 1 48 43

1 0 72 67

1 1 96 91

Ya que la longitud de las cabeceras de los paquetes es siempre la misma, las diferentes longitudes de cada paquete sólo afectan al campo de datos del paquete.

El grupo de datos del MSC es transmitido en uno o varios paquetes que comparten la misma dirección (estos paquetes si deben ser recibidos en orden). En la ilustración 7 se muestra como el grupo de datos del MSC es transmitido en varios paquetes con la misma dirección j. Además, si recordamos la figura anterior, podemos ver el valor de la etiqueta “First/Last” en cada paquete (“First”=1 en el primero, “Last”=1 en el segundo).

(27)

13

Ilustración 7: Composición del MSC.

Cada paquete individual tiene su propio CRC y aparte, el campo CRC del MSC está compuesto por paquetes que también contienen un CRC propio del paquete. Este CRC particular no comprueba la recepción general del MSC, sino la recepción particular del paquete.

Anteriormente se comentó que en ciertos casos es posible transportar información del FIC en el MSC, este particular caso es debido a un direccionamiento al Canal Auxiliar de Información (AIC), el cual utiliza el subcanal 63 y la dirección de paquete 1023. Para ello el grupo de datos del MSC particular debe cumplir ciertas características:

- Debe estar compuesto por FIG’s.

- Debe poder transportar diferentes tipos de FIG.

- El grupo de datos debe estar definido como “Datos generales” (“General Data”).

- Su tamaño máximo será de 512 bytes.

A continuación se puede observar un ejemplo de su estructura:

(28)

14 1.3 Multiplex Configuration Information (MCI)

La manera más común de acceso de un usuario a los servicios que puede proporcionar DAB es mediante la selección de un servicio. Estos servicios pueden contener también componentes de otros servicios y se dividen en dos: servicios primarios y secundarios. Los servicios primarios, suelen ser los que transportan el audio, aunque se puede dar el caso de que sean datos. Los servicios secundarios son opcionales por lo que no siempre se presenta en una transmisión.

Los servicios están compuestos por componentes de servicio, que a su vez, están relacionados con subcanales. Estas relaciones son organizadas por el MCI cuyas principales funciones son:

- Organizar los subcanales en cuanto a su posición y tamaño en los CIF y a su protección de errores.

- Listar los servicios disponibles en el sistema.

- Establecer las conexiones entre componente de servicio y servicio. - Establecer relaciones entre subcanales y componentes de servicio. - Señalizar una reconfiguración de la multiplexación.

(29)

15

1.3.1 Organización de los subcanales

Esta es una de las principales funciones del MCI, y es codificada mediante un FIG tipo 0 con extensión 1. Para cada subcanal existe información específica como la dirección de comienzo (de 0 a 863 CU’s), el tamaño o la protección de errores utilizada. Pueden ser direccionados hasta 64 subcanales usando valores de 0 a 64 para el identificador de subcanal. Existen dos maneras de señalizar el tamaño y la protección de errores utilizada para un subcanal que se explicarán en profundidad más adelante. De momento diremos que una manera es más larga (Long form) que la otra (Short form).

En la ilustración 9, se puede observar una trama del FIG utilizado para la organización de los subcanales y las dos opciones existentes para señalizar el tamaño y la protección de errores.

(30)

16

Veamos el significado de cada campo para poder entender mejor la trama y su codificación:

- SubChId: Este campo se corresponde con el identificador utilizado para hacer

referencia al subcanal.

- Start Address: Escrito como un número binario sin signo, utiliza 10 bits para

hacer referencia a un CU (de 0 a 863), el cual será el CU de inicio del subcanal.

- Short/ Long form: Este flag indica el modo utilizado para señalizar el tamaño

y el modo de protección de errores del subcanal. Cero se refiere a Short form y uno a Long form. Llegados a este punto, es necesario comenzar a explicar los dos modos de señalización.

Short form: Esta forma se corresponde con el llamado Unequal Error

Protection (UEP), orientado más a audio que a datos, aunque no se excluyen

los segundos. Mediante este modo en la trama se indica la tabla a observar (mediante Table Index =0, el 1 está reservado para codificaciones futuras), y en dicha tabla se encuentra el tamaño del subcanal (en CU’s), el nivel de protección, y el Bit Rate, tasa de bits (en Kbit/s). El campo encargado de indicar la fila a observar de la tabla es el Table Index.

Long form: Si hablamos de esta opción, nos estamos refiriendo al Equal

Error Protection (EEP). Este modo está orientado tanto a audio como a datos,

de hecho existen ciertas tasas de bits para audio no definidas para el modo anterior que este modo complementa. Esta forma de señalización incluye ocho niveles de protección de datos separados en dos grupos (A y B). Para conocer cuál de los dos grupos es el utilizado en el subcanal se usa el campo Option (3 bits, ‘000’ y ‘001’). Una vez elegido el modo de protección, el campo

Protection level, especifica el nivel de protección dentro el grupo escogido;

este campo está compuesto por dos bits que codifican los cuatro niveles posibles. Por último, se encuentra el campo Sub-channel size donde se puede conocer el tamaño del subcanal indicado en CU’s (de 1 a 864). Existen tablas que relacionan la tasa de bits con el tamaño del subcanal [2].

1.3.2 Organización de los servicios

Este apartado define los servicios y componentes de servicios transportados en el sistema. Al igual que la organización de los subcanales, se trata de un FIG de tipo 0, pero con la diferencia de que en este caso las extensiones utilizadas son las 2, 3,4 y 7.

Cada servicio se corresponde con un Identificador de Servicio, el cual es único en el mundo al aplicarle un campo llamado Código de Extensión de País. Cada componente de servicio tiene un identificador único en el sistema.

(31)

17

La ilustración 10 muestra un esquema de la trama de definición de un servicio básico con sus componentes de servicio. Se trata de un FIG tipo 0 con extensión 2. La trama representa como cada servicio se divide en una cabecera y la definición de sus componentes de servicio. La cabecera incluye los identificadores necesarios del servicio y el número de componentes de servicio asociados. La siguiente parte de la definición, se corresponde con el particular componente el cual tendrá un identificador, una relación con el subcanal, tipo de datos, etc.

Ilustración 10: Estructura de los servicios

Puesto que este apartado de estudio de Digital Audio Broadcasting trata de una orientación necesaria para entender las funciones implementadas en el proyecto, no se va a entrar en más detalle sobre otras funciones del DAB. De nuevo, cualquier ampliación de información acerca de estas funciones se puede encontrar en el documento estándar de DAB [2] cuya referencia se incluye en la bibliografía.

1.4 Estructura general de DAB

Como último apartado de este estudio, es importante conocer también la estructura o esqueleto del DAB, es decir, como se divide su comportamiento. Hasta ahora, la visión que hemos tenido del DAB ha sido orientada a sus tramas de datos, sus posibles configuraciones y tipos de datos. Una vez conocemos sus funcionalidades, veamos cómo las lleva a cabo de una manera general para poder entender su posterior implementación, siempre desde el punto de vista del receptor, por lo que la parte del transmisor la vamos a obviar, ya que está fuera del objetivo, aunque a grandes rasgos, es el inverso del receptor.

Existe un esquema de diferenciación de módulos dentro del DAB que estudiaremos en profundidad al hablar del flujo de diseño, pero de momento vamos a intentar diferenciar a grandes rasgos las partes que pueden componer un receptor DAB.

(32)

18

Tratando de orientar esta diferenciación para explicar la parte del receptor en la que se centra el proyecto, podemos decir que existen tres partes:

- Recepción de la señal: Esta parte incluiría el llamado Front End de la

aplicación donde se trataría la señal para luego procesarla en los sucesivos módulos. Esta primera parte no se diseñó durante el proyecto ya que en la empresa NXP tienen gran experiencia en tratamiento de señales y, por lo tanto, software óptimo para llevarlo a cabo.

- Demodulación y demultiplexación: Esta es la parte en la que se centró el

proyecto. Una vez la señal está lista para ser tratada se le aplica la transformada de Fourier, se demodula, se le aplican métodos de recolocación de datos, se realiza una cuantificación de la señal y, se demultiplexa según sea información perteneciente al FIC o a un subcanal. Una vez se ha hecho la demultiplexación, el flujo de ejecución es particular para cada subcanal o para el FIC pero, a grandes rasgos, se puede decir que se le aplican diferentes métodos para la recolocación de datos utilizada para evitar posibles errores durante la transmisión.

- Decodificación: Este último apartado está fuera del objetivo del proyecto, es

la parte donde se procede a decodificar los datos dependiendo de su codificación original (mp2, mp3, etc.). Estos módulos sólo se le aplican a los subcanales y no al FIC.

Una vez visto a grandes rasgos el sistema, podemos empezar a estudiar y entender y la división en diferentes módulos de la parte del receptor que se implementó y además también veremos como aunque la división de trabajo se hiciese casi siempre en módulos independientes, era necesaria una comunicación constante dentro del equipo de trabajo debido a la fuerte interrelación de dichos módulos.

(33)

19 Capítulo 2. Procesador CoolFlux DSP

2.1. Introducción

El imparable avance en el campo de la electrónica, particularmente en las técnicas de fabricación de circuitos integrados, ha tenido un gran impacto en la industria de las comunicaciones. El rápido desarrollo de la tecnología de integración a gran escala (VLSI, Very Large Scale Integration) de circuitos electrónicos ha estimulado el desarrollo de computadores digitales más potentes, pequeños, rápidos y baratos, cuyo hardware responde a propósitos específicos. Esta tecnología ha hecho posible construir sistemas digitales altamente sofisticados, capaces de realizar funciones y tareas del procesado de señal digital que normalmente eran demasiado difíciles y/o caras con circuitería o sistemas de procesado de señales analógicas.

Los DSP's modernos son apropiados para su implementación bajo el criterio VLSI. Las grandes inversiones necesarias para diseñar un nuevo circuito integrado sólo pueden ser justificadas cuando el número de circuitos a fabricar es grande, o cuando los niveles necesarios de desempeño son tan altos que no pueden ser alcanzados con la tecnología existente. A menudo, ambos argumentos se unen la misma tendencia, particularmente en comunicaciones y aplicaciones dirigidas a los consumidores. Los avances en la tecnología de fabricación de circuitos integrados también abren nuevas áreas de desarrollo basadas en DSP, tales como sensores inteligentes, visión de robots y automatización, mientras pone las bases para continuar con el desarrollo tecnológico en áreas tradicionales del procesamiento de señal digital, tales como música, voz, radar, sonar, video, audio y comunicaciones.

Dentro del procesamiento de señal digital, en los últimos años se ha experimentado un direccionamiento de las tendencias del mercado tecnológico hacia las telecomunicaciones móviles de altas prestaciones, lo que ha provocado un creciente interés por arquitecturas empotradas de bajo consumo. La proliferación y popularidad de dispositivos portátiles hace que el bajo consumo unido a la alta productividad se haya vuelto imprescindible. Además, como consecuencia de la complejidad creciente de los protocolos de comunicación y del advenimiento de la era multimedia, se ha producido un espectacular aumento de los requerimientos computacionales para abordar funcionalidades cada día más demandadas. Por otro lado, cabe comentar que el ciclo de vida de los dispositivos móviles y multimedia se está reduciendo considerablemente debido a la presión del mercado, lo que provoca a su vez una reducción del tiempo de desarrollo de los procesadores. Esto significa que lograr la máxima eficiencia computacional con el mínimo consumo de energía y en el menor tiempo posible se ha convertido en la meta de varias compañías de desarrollo de DSPs.

Con la intención de dar respuesta a estas necesidades nace el proyecto CoolFlux, un DSP desarrollado en primera instancia por Philips PDSL (Philips Digital Systems Labs) en el año 2002, pasando a ser parte de las competencias del grupo Emerging Semiconductor Business Healthcare de NXP tras la escisión de esta última de su compañía nodriza, Philips.

(34)

20

En etapas iniciales de diseño el objetivo principal fue lograr un consumo energético reducido y hacerlo minimizando el tamaño del procesador e incluyendo todas las funcionalidades básicas de un DSP, cuyas aplicaciones objetivo se refieren principalmente al proceso de audio. Una combinación de técnicas a todos los niveles puede dar lugar a una solución óptima: esto se conoce como enfoque holístico, en el cual se aborda cada aspecto independientemente, no solo como una parte del todo ([6], [7]). Siguiendo este enfoque holístico, encontramos las siguientes decisiones de diseño:

- Optimización para un determinado dominio de aplicación. El procesador está diseñado específicamente para obtener el mejor rendimiento posible en aplicaciones objetivo, en este caso el proceso de señal de audio. Para ello, las anchuras de instrucciones y ruta de datos fueron elegidas para adaptarse mejor este tipo de procesamiento.

- Minimización del tamaño del procesador. Área reducida y menos puertas de tipo toggle (on/off), así como una distribución compacta, contribuyen a reducir el consumo de energía.

- Minimización del tamaño de la memoria y los accesos a ella. La memoria contribuye significativamente al área total del procesador y a su consumo de energía.

- Introducción de paralelismo. El procesador está dotado de unidades funcionales y buses de comunicación replicados para obtener paralelismo en ejecución, adquiriendo un compromiso entre tamaño del procesador y ciclos de ejecución. - Optimización del ratio entre la máxima frecuencia de reloj y el número de ciclos requeridos para las aplicaciones objetivo. De manera que se aplican técnicas de escalado dinámico de voltaje.

- Programación en C. Siguiendo las tendencias actuales en el desarrollo de DSPs, el procesador no se programa en ensamblador como se solía hacer, sino que se hace en ANSI-C. Mejora la productividad siempre y cuando la acción combinada del compilador y de las librerías de subrutinas haga que el rendimiento sea equiparable al obtenido con programación en lenguaje ensamblador.

La reducción del ciclo de desarrollo de los procesadores comentada anteriormente hace que se planteen nuevos sistemas de diseño de software que sean altamente reutilizables en futuras generaciones del procesador. Por este motivo el diseño del procesador se abordó desde una perspectiva redireccionable, es decir, adaptable a nuevas especificaciones para el sistema. Para ello se utilizó el entorno de desarrollo de Target Compiler Technologies (TCT), el cual permite definir una arquitectura específica y genera un compilador C para la misma, el cual es utilizado para transformar los programas en C a código máquina, que puede entonces ser simulado y evaluado.

(35)

21

Para tener una noción clara de lo que la programación en C y el enfoque re-direccionable suponen en el desarrollo de CoolFlux, reproduciremos las palabras de Johan Van Ginderdeuren, manager del proyecto en Philips y posteriormente en NXP:

“We wanted our new DSP to outperform other solutions, not only in terms of power consumption and cost, but by offering very efficient C programmability at the same time. For audio applications, assembly programming has often been deemed mandatory to meet the ultra-low power requirements. However, the CoolFlux DSP product has shown us the key to compiler friendly low-power design, which is the use of retargetable compilation technology” [18]

El entorno de desarrollo de software proporcionado por TCT, llamado “Checkmate for CoolFlux DSP, es una instancia específica de Chess/Checkers, el conjunto de herramientas re-direccionables de TCT para el diseño, la programación y verificación de procesadores. Las herramientas de Chess/Checkers soportan múltiples arquitecturas, desde pequeños microprocesadores a DSPs, procesadores VLIW, vectoriales e incluso ASICs programables.

Checkmate for CoolFlux contiene herramientas de programación y de verificación:

El entorno de programación incluye el compilador C optimizado, un ensamblador/desensamblador y las herramientas de linkado, todo ello controlado desde un mismo IDE. El compilador C, llamado Chess, ofrece soporte para ANSI-C y de punto fijo para el procesador ANSI-CoolFlux, y genera código máquina altamente eficiente que elimina la necesidad de programar en ensamblador para obtener el mejor rendimiento (aunque esta forma de programación también es posible en la herramienta). Chess es diferente de los compiladores de C convencionales como gcc: usa modelado basado en grafos y técnicas de optimización para proporcionar código altamente optimizado para arquitecturas especializadas que exhiben peculiaridades tales como pipelines complejos, estructuras de registro heterogéneas, unidades funcionales específicas y paralelismo a nivel de instrucción.

El entorno de verificación consiste en un debugger gráfico, que puede ser conectado tanto a un simulador llamado Instruction Set Simulator (ISS) como al propio procesador vía interfaz JTAG.

(36)

22

Ilustración 11: Estructura de Checkmate para CoolFlux DSP

El equipo de desarrollo de CoolFlux ha utilizado intensivamente este conjunto de herramientas para modelar el procesador, debido a la comodidad que supone a la hora de explorar y optimizar la arquitectura la posibilidad de contar con la información del compilador y del ISS. Con estas herramientas, la arquitectura del repertorio de instrucciones podía ser evaluada y ajustada a los requerimientos de aplicaciones que típicamente tendría que abordar el procesador, al mismo tiempo que el compilador podía ser evaluado y mejorado igualmente. Para obtener más información acerca de las herramientas de Target Compiler Technologies, ver [13].

2.2. Arquitectura

La última generación del CoolFlux es la llamada CoolFlux BSP, bajo la cual este proyecto fue finalizado, y de la cual pasamos a detallar las principales características. Para profundizar en el tema, ver [8].

2.2.1 Características generales

Para una arquitectura de bajo consumo energético los aspectos más importantes a tener en cuenta son la estructura del pipeline, la implementación de los decodificadores, la estructura del campo de registros y el paralelismo.

Como veremos con más detalle a lo largo de esta sección, CoolFlux reúne varias características que hacen de él un sistema de muy bajo consumo energético. He aquí algunos ejemplos preliminares:

(37)

23

- Dispone de un pipeline sencillo y bien balanceado en lo que a tiempo de ciclo de procesador se refiere, por lo que da libertad para aplicar técnicas de escalado de voltaje, las cuales redundan en una reducción cuadrática del consumo.

- Usa un decodificador de instrucciones segmentado, es decir, utiliza varios decodificadores para las diferentes secciones, en lugar de un único decodificador para toda la instrucción: estos decodificadores de sección se activan solamente cuando se necesitan, lo que supone un ahorro de energía a considerar.

- Los registros están situados siguiendo una política de localidad espacial con respecto a los recursos computacionales que los utilizan, complicando la gestión de los registros pero favoreciendo el menor consumo energético.

La mayor parte de las operaciones que se pueden llevar a cabo sobre la arquitectura pueden ser realizadas en modo sencillo o en modo empaquetado. El modo empaquetado comprende dos tipos de datos diferentes: complex y SIMD.

2.2.2 Descripción de la Arquitectura

La arquitectura hardware de CoolFlux BSP comprende una arquitectura Harvard, cuya memoria de programa tiene 32 bits de anchura (Memoria P) y dos memorias de datos de 24 bits (Memoria X y Memoria Y) de 16M palabras cada una. La ruta de datos de 24/56 bits dispone de dos multiplicadores de 24x24 bits (precedidos ambos por sumadores/restadores) y tres ALUs, además de dos unidades de redondeo, saturación y selección (unidades RSS).

Hay dos registros de 24 bits y dos acumuladores de 56 bits a ambos lados de la ruta de datos (Lado X y Lado Y). Dado que los dos MACs pueden operar en paralelo, ambos registros acumuladores pueden actuar como registros de destino simultáneamente. Hay dos buses de sistema, para mover datos, uno a cada lado del datapath, los cuales soportan movimientos sencillos y también movimientos paralelos. Un movimiento sencillo consiste en el transporte de un dato de 24 bits y se hace en un ciclo de reloj, mientras que un movimiento paralelo consiste en mover dos elementos de 24 bits usando los dos buses simultáneamente y, por tanto, en un mismo ciclo de reloj.

Además de la ruta de datos, hay unidades de generación de direcciones (AGUs), una para manejar los accesos a la memoria X y la memoria Y. En el lado X hay 8 registros de generación de dirección, mientras que en el lado Y tan solo hay 4. También hay 2 bloques de conversión de datos, puesto que hay varias anchuras de datos presentes en la arquitectura (24 bits, 56 bits).

CoolFlux BSP es una arquitectura de carga/almacenamiento, lo que supone que todos los operandos de memoria deben ser previamente cargados en registro antes de operar con ellos, así como todos los resultados almacenados en registros han de ser movidos explícitamente a memoria. Los registros están organizados en campos de registro cuyo nombre sirve para designar a cada registro individualmente mediante la adición de un índice. Todos los registros de un mismo campo de registros tienen la misma

(38)

24

anchura. Puesto que hay diferentes anchuras de datos para los diferentes tipos de registro, es necesario, como ya se ha comentado brevemente y como veremos a continuación en profundidad, que haya módulos específicos de conversión de datos de anchuras diferentes. Como ejemplo de esto cabe mencionar el caso de los acumuladores presentes en ambos lados del datapath: tienen una anchura de 56 bits lo que implica que no pueden ser transportados a través de los buses Xbus e Ybus en un solo ciclo de procesador. Estos registros son divididos en tres subregistros, cada uno de los cuales puede ser, por separado, origen y destino en operaciones de movimiento de datos. Sin embargo, no pueden ser utilizados en operaciones aritméticas.

Existen registros que no están organizados en campos de registros, como pueden ser los registros relacionados con el tratamiento de interrupciones (Ver sección Interrupciones), el registro de estado y el puntero de pila.

Por otro lado, algunos de los registros pueden ser utilizados en modo empaquetado, y su anchura se divide en dos partes para alojar dos datos distintos (por ejemplo, real e imaginario en el caso del tipo complex). Estos registros son siempre considerados ‘con signo’ cuando trabajan en modo empaquetado.

Los accesos a las memorias se realizan en un ciclo de reloj. De hecho, en un solo ciclo de procesador cada memoria puede ser accedida independientemente de manera que hasta 2 datos pueden ser leídos/cargados. También hay un modo de memoria especial en el que las dos memorias son combinadas para formar un único espacio de direcciones de datos de 48 bits: la memoria XY. Además, CoolFlux dispone de un sistema de E/S mapeado en memoria de 16Mword de 24 bits. Esto significa que, desde un punto de vista software, la E/S puede ser considerada como una memoria al uso.

La replicación de hardware supone que la arquitectura es capaz de ejecutar simultáneamente dos operaciones tipo MAC, dos transacciones de memoria y dos actualizaciones de puntero por ciclo, y por tanto es muy eficiente en ciclos de ejecución para aplicaciones computacionalmente intensivas. Puede observarse que la arquitectura CoolFlux muestra una simetría muy marcada. Sin embargo, las operaciones sobre la parte X de la misma están más elaboradas, relegando a la parte Y a una función de apoyo en operaciones aritméticas paralelas, y cargando la parte X con la mayor parte de los requerimientos computacionales.

(39)

25

Ilustración 12: Unidades de direccionamiento, buses Xbus e Ybus, memorias, DMA y unidad de control de programa

(40)

26

(41)

27

2.2.3 Repertorio de Instrucciones

En el desarrollo del repertorio de instrucciones se observa un compromiso entre el tamaño del código, tamaño del decodificador de instrucciones y la eficiencia del compilador para gestionar paralelismo a nivel de instrucción y las instrucciones de control.

Se trata de una arquitectura de 32 bits de instrucción con un conjunto de instrucciones tipo RISC combinado con un conjunto de instrucciones destinado a soportar el máximo paralelismo posible.

Los cuatro grupos principales de instrucciones son:

- el grupo de instrucciones long: utilizan los 32 bits de instrucción para gestionar operaciones de control y operaciones de aritmética de punteros sobre el puntero de pila. - las instrucciones aritméticas/de movimiento: Combinan dos operaciones separadas. La primera parte es aritmética y puede consistir en una operación MAC, una operación ALU o ambas en paralelo. La segunda parte es completamente independiente a la primera y puede realizar transporte de datos sencillo o en paralelo (utilizando los dos buses). Pueden ser en modo escalar (AM) o en modo empaquetado (AMC).

- instrucciones de movimiento: optimización especial que combina 2 instrucciones AM escalares, para las cuales la parte aritmética es nop, en una instrucción de 2 movimientos escalares. Esta instrucción se ejecuta en 2 ciclos de procesador.

Asimismo, hay operaciones aritméticas condicionales que evitan usar el salto condicional con frecuencia, ahorrando ciclos de procesador.

Dado que el tamaño de instrucción es ligeramente superior a la media de tamaño de las instrucciones usadas en aplicaciones objetivo (experimentalmente, en torno a 25 bits de media), el compilador dispone de bastante libertad para organizar la ejecución de instrucciones de manera paralela y comprimir así el tamaño de código necesario para el mismo número de instrucciones.

Es importante resaltar que para disponer de un decodificador segmentado es necesario que la arquitectura del repertorio de instrucciones sea altamente ortogonal y modular.

2.2.4 Pipeline

CoolFlux tiene una estructura de pipeline sencilla y balanceada, contando con 3 etapas: - Fetch (1 ciclo)

- Decode (1 ciclo) - Execute (1 o 2 ciclos)

(42)

28

Este esquema básico se mantiene por varios motivos, entre los cuales subyace la reducción de consumo de energía que supone tener un pipeline de pocas etapas (aunque perdamos el rendimiento que nos ofrecería un pipeline más profundo). Además, un pipeline sencillo facilita la labor del compilador a la hora de encontrar la configuración de operaciones óptima.

2.2.5 Conversión de tipos: Unidades RSS

Como ya hemos comentado, las diferentes anchuras presentes en la arquitectura hacen que sea necesario tener módulos que se encarguen de convertir los datos y ajustarlos al formato de su destino.

Las operaciones de conversión de tipos se pueden clasificar en extensivas (de menos a más anchura) y limitantes (de más a menos anchura). Obviamente, las que presentarán más dificultad serán las que deban prescindir de ciertos bits (limitantes). Además, también se pueden clasificar en escalares y empaquetadas.

La conversión de tipos puede tener lugar en los siguientes sitios de la arquitectura: - Desde y hacia los buses

Los buses tienen una anchura de 24 bits, por lo que los datos fuente son convertidos a 24 bits para su transporte y después son convertidos a la anchura de su destino, el cual puede ser en este apartado de 3, 8, 16 y 24 bits de anchura. Las operaciones extensivas son, por tanto, realizadas hacia el bus:

- sobre datos con signo se realizan mediante una extensión de signo añadiendo el número de bits necesario para completar la anchura de destino.

-sobre datos sin signo se añaden cero por el lado más significativo.

Las operaciones limitantes se llevan a cabo desde los buses hacia los registros de destino, y consisten en descartar los bits más significativos sobrantes.

Esto funciona así tanto para operaciones escalares como para empaquetadas. - Desde y hacia sitios de 56 bits de anchura:

Este tipo de conversión puede llevarse a cabo en tres formas diferentes: 1. en los puertos de entrada y salida de las ALUs;

2. desde los buses al acumulador; 3. desde el acumulador a los buses.

Describiremos las políticas de conversión sin entrar en detalle, aunque éstas difieren en el número de bits extendidos y en el padding aplicado.