instituto tecnolÓgico y de estudios - … de energÍa para el protocolo gsm half-rate tesis...

Codiseño de Hardware y Software paraReducción del Consumo de Energía para

el Protocolo GSM Half-Rate-Edición Única

Title Codiseño de Hardware y Software para Reducción del Consumode Energía para el Protocolo GSM Half-Rate-Edición Única

Issue Date 2009-12-01

Publisher Instituto Tecnológico y de Estudios Superiores de Monterrey

Item Type Tesis de maestría

Downloaded 10/06/2018 04:58:27

Link to Item http://hdl.handle.net/11285/569821

http://hdl.handle.net/11285/569821

I N S T I T U T O T E C N O L Ó G I C O Y D E E S T U D I O S

S U P E R I O R E S D E M O N T E R R E Y

C A M P U S M O N T E R R E Y PROGRAMA DE GRADUADOS DE LA DIVISION DE

TECNOLOGIAS DE INFORMACION Y ELECTRONICA

CODISEÑO DE HARDWARE Y SOFTWARE PARA REDUCCIÓN DEL

C O N S U M O DE ENERGÍA P A R A EL P R O T O C O L O G S M H A L F - R A T E

T E S I S

PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADÉMICO DE:

MAESTRO EN CIENCIAS EN INGENIERÍA ELECTRÓNICA CON ESPECIALIDAD EN SISTEMAS ELECTRÓNICOS.

MARCO ANTONIO Q U E Z A D A ROJAS

MONTERREY, N. L . D I C I E M B R E 2009

Instituto Tecnológico y de Estudios Superiores de Monterrey

Campus Monterrey

Programa de graduados de la División de Tecnologías de Información y Electrónica

Codiseño de hardware y software para reducción del consumo de energía para el protocolo GSM Half-Rate

TESIS

Presentada como requisito parcial para obtener el grado académico de

Maestro en Ciencias en ingeniería electrónica

con especialidad en Sistemas Electrónicos

Marco Antonio Quezada Rojas

Monterrey, N.L . Diciembre 2009


División de Tecnologías de Información y Electrónica Programa de Graduados

Los Miembros del Comité de Tesis recomendamos que la presente tesis de Marco Antonio Quezada Rojas sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias en Ingeniería Electrónica con especialidad en Sistemas Electrónicos

Campus Monterrey

Comité de Tesis

Alfonso Ávila Ortega Ph.D. Asesor

José Ramón Rodríguez Cruz Ph.D. Sinodal

Luis R. Molina Hernández M.C, Sinodal

Joaquín Acevedo Mascarúa Ph.D. Director del Programa de Graduados en Tecnologías

de Información y Electrónica

Monterrey N - L . Diciembre de 2008

Codiseño de hardware y software para reducción del consumo de energía para el protocolo GSM Half-Rate

Por

Marco Antonio Quezada Rojas

TESIS

Presentada al Programa de Graduados de la División de Tecnologías de Información y Electrónica

como requisito parcial para obtener el grado académico de

Maestro en Ciencias en ingeniería electrónica

con especialidad en Sistemas Electrónicos


Campus Monterrey

Monterrey, N .L . Diciembre 2009

A Dios.

Porque siempre ha estado conmigo

A mi Familia

Por su amor y apoyo.

Agradecimientos

A mi Familia por su amor y apoyo durante toda mi vida.

A l Dr. Alfonso Ávila por su apoyo en el transcurso de la maestría y el desarrollo de esta tesis.

A l Dr. José Ramón Rodríguez, por sus acertadas observaciones y sus sugerencias en la redacción de este documento.

A l Dr. Luis Molina, por sus comentarios para ayudar a mejorar este trabajo.

A Solio Sarabia por su apoyo en los experimentos iniciales de esta tesis.

A mis compañeros y amigos por sus consejos y apoyo en los momentos duros durante toda la maestría.

. . . Y a todos aquellos que siempre han estado conmigo

Muchas Gracias

Marco Antonio Quezada Rojas.

Resumen

Dentro del ámbito de la telefonía celular la vida útil de la batería se ve disminuida

significativamente cuando esta se somete al proceso de recarga de una forma muy

frecuente. Ciertos usuarios realizan un intensivo uso del celular al efectuar demasiadas

llamadas durante la jornada o bien llamadas de un largo periodo de tiempo lo cual con lleva

a tener que recargar el teléfono diariamente e incluso con mayor frecuencia al día. En el

presente trabajo se pretende dar una solución a usuarios que utilicen equipos celulares GSM

y se encuentren en la situación anteriormente descrita. Utilizando la metodología de

Codiseño de Hardware y Software se pretende diseñar una arquitectura que disminuya el

consumo de energía enfocado al proceso de llamada y recepción.

Índice General

Índice de Figuras IV

Índice de tablas VI

Capítulo 1. Introducción 1

1.1 Justificación 1 1.2 Definición del problema 2 1.2 Objetivo 2 1.3 Contribución y Alcance 3 1.4 Organización de la tesis 3

Capítulo 2. Antecedentes 4 2.1 Global Systems for Mobile Communication 4

2.1.1 Full Rate (FR) Speech Coder 5 2.1.2 G S M G S M Half Rate (HR)Speech Coder 6 2.1.3 G S M Enhanced Full Rate (EFR) Speech Coder 6 2.1.4 G S M Adaptive Multi-Rate 8

2.2 Vector Sum Excited Linear Prediction (VSELP) 8 2.2.1 Estructura Básica Del Codificador / Decodificador 9 2.1.2 Estructura del Codebook de VSELP 10 2.1.3 Selección de Vectores de excitación 11

2.3 Segunda generación en la actualidad 14 2.4 C A D R E (Configurable Asynchronous DSP for Reduced Energy) . . . . 16

Capítulo 3. Simulación de G S M Half-Rate (GSM-HR) en el ambiente Seamless 18

3.1 Seamless 18 3.2 ETSI 21 3.3 Código en Lenguaje C para GSM-HR 22

3.3.1 Adecuación del Software 23 3.3.2 Simulación en Seamless 26

Capítulo 4. Propuesta de arquitectura para el modulo M A C 28 4.1 Descripción de la función L_mac 28 4.2 Descripción de la función L_mult 28

I

4.2 Descripción de la función L_Add 29 4.3 Arquitectura propuesta para operación de multiplicación 30

4.3.1 Multiplicador basado en el algoritmo de booth 30 4.4 Análisis de propuesta para implementación de Suma 34

4.4.1 Sumador Acarreo lockahead 37 4.5 Propuesta para integración del modulo M A C con el microprocesador . . . 38

4.5.1 Envío de datos al modulo M A C en software 41 4.6 Arquitectura interna del modulo M A C 42

Capitulo 5. Resultados 44 5.1 Resultados obtenidos de la simulación del programa

gsm_hr utilizando el modulo M A C 44 5.2 Funcionalidad 44 5.3 Desempeño 45 5.4 Mediciones del consumo de energía del procesador 47 5.5 Mediciones del consumo de energía del modulo M A C 48

Capitulo 6. Conclusiones y trabajo a futuro 54 6.1 Conclusiones 54 6.2 Trabajo futuro 56

Bibliografía 97

II

Índice de Figuras

2.1 Diagrama de bloques del codificador RPE-LTP 5 2.2 Diagrama de bloques del decodificador RPE-LTP 5 2.3 Diagrama de bloques del codificador / decodificador VSELP 6 2.4 Diagrama de bloques del codificador GSM enhanced 7 2.5 Diagrama de bloques del decodificador GSM enhanced 7 2.6 Diagrama de bloques del codificador / decodificador VSELP 9 2.7 Selección de excitación de palabra de código 11 2.8 Evolución de las generaciones de teléfonos celulares 15 3.1 Arquitectura Seamless 20 3.2 Procedimiento de comprobación de código 23 3.3 Resultados obtenidos con el performance profiler de Seamless 27 3.4 Información de la función Lmac 28 4.1 Diagrama de flujo del algoritmo de booth 33 4.2 Arquitectura para implementación del algoritmo de booth 33 4.3 Comparativa de Área entre Sumadores 35 4.4 Comparativa de Delay entre Sumadores 35 4.5 Comparativa de disipación de energía promedio entre sumadores 36 4.6 Diagrama de bloques de un sumador de 4 bits con Acarreo 38

lookahead 4.7 Arquitectura mínima para Seamless 38 4.8 Diagrama de un sub-bloque que conforma la memoria del sistema 39 4.9 Diagrama de un sub-bloque que conforma el modulo MAC 40 4.10 Arquitectura final de implementación del modulo MAC con microprocesador . . . . 41 4.11 Proceso de comunicación con el modulo MAC 42 4.12 Arquitectura interna para el modulo MAC 43 5.1 Resultados obtenidos por el code profile en la simulación del

programa gsmhr utilizando el modulo MAC 45 5.2 Propiedades de la función L_mac obtenidas por el code profile en la

simulación del programa gsmhr utilizando el modulo MAC 46 5.3 Propiedades de la función main sin utilizar el modulo MAC 47 5.4 Propiedades de la función main utilizando el modulo MAC 47 5.5 Particiones de tiempo del programa gsmhr 53 5.6 Particiones de tiempo del programa gsmhr utilizando el modulo M A C . . . 54

III

Índice de tablas

1.1 Duración de la batería en celulares con protocolo GSM 1 3.1 Métricas con las que cuenta el Performance Profiler 20 3.2 Modificaciones de software 24 3.2 Resultados obtenidos en la simulación del programa gsmhr 25 4.1 Recodificación de dígitos según el algoritmo de booth 33 5.1 Resultados de consumo de energía obtenidos por code profile de Seamless . . . 48 5.2 Resultados de consumo de energía obtenidos por XPower de Xilinx 49 5.3 Tiempo de ejecución y ciclos de operación del modulo M A C 51 5.4 Accesos de memoria y tiempo de utilización del bus 52

V

Capítulo 1

1. Justificación

El mercado de Teléfonos celulares se ha incrementado considerablemente en los

últimos años, en el año 2006 se realizo un incremento del 21.6% de celulares vendidos a

nivel mundial con respecto al 2005 [1]. Este incremento de usuarios de un teléfono

celular nos lleva a una lucha por parte de las compañías por hacerse de más cuentas de

usuarios, de modo que se han realizado diversas estratégicas de mercadotecnia como

planes para efectuar llamadas a muy bajo costo e inclusive sin costo en algunos casos.

Sin embargo esto nos lleva a un problema tecnológico, pues dichos celulares

normalmente utilizan baterías de Lit-Ion las cuales tienen entre 400 a 500 ciclos de

recarga aproximadamente, suponiendo una recarga diaria de la batería obtendríamos que

el periodo de vida de esta seria de 400 a 500 días lo cual es un promedio menor a un año

y medio. Sin embargo en la Figura 1 muestra como la duración de la batería de los

teléfonos celulares disminuye dramáticamente en llamada, lo cual nos indica que

siguiendo las tendencias de las compañías telefónicas a fomentar el excesivo uso del

teléfono celular termina por consumir la batería en un tiempo mucho menor y

posteriormente ser obligado a cambiar la batería.

Tabla 1.1 - Duración de la batería en celulares con protocolo GSM

(Estos datos fueron obtenidos de las especificaciones técnicas del fabricante)

Modelo Tiempo en idle state Tiempo en llamada

V237p 14.5 Días 7.5 Horas

C115 12 Días 8 Horas

E398 10 Días 6 Horas

SLVR 15 Días 6.6 Horas

PEBL 10 Días 6 Horas

W580Í 15 Días 9 Horas

W890Í 13 Días 4.5 Horas

1

Los teléfonos celulares regidos por el estándar G S M ejecutan un complicado

control y funciones de procesamiento de señales para realizar el filtrado de la señal,

corrección de errores, manejo del protocolo, algoritmos de compresión y descompresión

de la señal de voz. Típicamente estos procesos son realizados en un circuito integrado

compuesto por un microprocesador encargado del control de tareas del protocolo y un

DSP el cual está encargado de realizar el procesamiento numérico del protocolo.

Buscando en la literatura se ha encontrado que el DSP es responsable del 65% del

consumo de energía total cuando se encuentra en medio de una llamada utilizando un

codee half-rate de voz [2]. Esto ha dado pie al estudio de técnicas para disminuir el

consumo de energía producido por el DSP.

1.2 Definición del problema

El DSP al utilizar un algoritmo Half-Rate de compresión/descompresión de voz en

G S M produce un consumo de energía muy alto, debido al excesivo número de

operaciones necesarias para implementarlo. Este alto consumo de energía ocasiona una

notable disminución del tiempo de vida de la batería del celular.

1.3. Objetivos

Se pretende analizar el algoritmo compresión de voz del estándar G S M Half-Rate

e implementar una arquitectura específica que permita disminuir el consumo de energía

del microprocesador y aumentar el desempeño del algoritmo disminuyendo el tiempo de

ejecución.

2

1.4. Contribución y alcance.

La contribución de este trabajo será proponer una arquitectura específica que

permita disminuir el consumo de energía del microprocesador y aumentar el desempeño

del algoritmo de compresión utilizado en el estándar G S M Half-Rate disminuyendo el

tiempo de ejecución de este. La arquitectura contara con elementos de hardware y

software por lo que se ocuparan técnicas de codiseño de hardware y software para

obtener una mejor implementación.

Para la elaboración de esta tesis se usaron diversas herramientas tales como C y

V H D L para la simulación del algoritmo y descripción de la arquitectura implementada

también se ocuparon herramientas de simulación y síntesis de hardware tales como

ModelSim y Seamless de Mentor Graphics.

1.5. Organización de la tesis

Esta tesis se encuentra distribuida en 6 capítulos y estos se describen a

continuación. En el capítulo 2 se describen los antecedentes referentes a Global System

for Mobile communication (GSM), Vector Sum Excited Linear Prediction (VSELP), la

relación de la segunda generación y porque es aun importante su estudio hoy en día por

último se revisan antecedentes de un trabajo relacionado con el propósito de esta tesis.

En el capítulo 3 se describirá la simulación del programa gsmhr en el ambiente

Seamless y una breve descripción de las herramientas utilizadas en este proceso y el

procedimiento utilizado para realizar la simulación en este ambiente. En el capítulo 4 se

presenta la descripción de la arquitectura propuesta para el coprocesamiento y su

interconexión con el procesador. En el capítulo 5 se presentan los resultados obtenidos

al realizar el coprocesamiento y se realiza una comparación con los resultados obtenidos

previamente. En el capítulo 6 se presentan las conclusiones obtenidas del trabajo

realizado así como algunas propuestas para trabajos posteriores

3

Capitulo 2 Antecedentes

2 . 1 . Global Systems for mobile communication (GSM)

G S M por sus siglas en inglés,"Global Systems for Mobile Communications" o

Sistema Global de Comunicaciones Móviles, es un estándar abierto de tecnología

celular digital desarrollado en el año de 1989 utilizado para la transmisión móvil de voz

y datos. Este estándar es considerado como un protocolo de segunda generación. Debido

a que a diferencia de su antecesores incorpora la tecnología digital y la división de

acceso de transmisión múltiple(TDMA), haciendo de esta, la tecnología de telefonía

celular digital de segunda generación más popular, teniendo más de 2.5 billones de

usuarios en el 2008.

Dos de las grandes ventajas del G S M es que permite la transmisión de datos a

velocidades de hasta de 5.6 kbt/s facilitando el servicio de mensajes cortos (SMS por

sus siglas en Inglés). Su segunda ventaja es el roaming internacional, que permite el uso

de un celular en cualquier país del mundo donde exista la tecnología G S M .

Actualmente G S M cuenta con 4 tipos de codees de voz los cuales son conocidos

con los siguientes nombres: G S M F U L L R A T E , G S M H A L F R A T E , G S M

ENHANCED F U L L RATE, G S M ADAPTIVE MULTI -RATE.

Cada uno de estos codees utiliza una señal de voz de entrada de 13 bits uniformes

P C M muestreada a 8 KHz. La base es muestreada cuadro por cuadro, donde cada

cuadro es de 20 ms (160 muestras).

4

2.1.1. GSM Full Rate (FR) Speech Coder

El codee FR fue estandarizado en 1987. Este codee pertenece a los codees de la

clase "regular pulse excitation - long term prediction" (RPE-LTP). En la parte del

codificador un cuadro de 160 muestras de voz es codificado como un block de 260 bits

alcanzando un bit rate de 13 Kbps. El decodificador convierte los bloques codificados

de 260 bits a bloques de salida de 160 muestras de voz reconstruidos. El canal de GSM

Full Rate suporta hasta 22.8 kbps. Por lo tanto el restante 9.8kbps es utilizado para

protección de errores [3]. A continuación se muestran los diagramas de bloques del

codificador y decodificador RPE-LTP, en las Figuras 1.1 y 1.2 respectivamente.

Figura 2.1 Diagrama de bloques del codificador RPE-LTP.

Figura 2.2 Diagrama de bloques del decodificador RPE-LTP.

5

2.1.2. GSM Half Rate (HR) Speech Coder

El codee HR fue desarrollado a principios de 1990 para el sistema de G S M y

opera bajo el algoritmo "Vector-Sum Excited Linear Prediction" (VSELP), este

algoritmo será explicado ampliamente en el capítulo 2.2. E l codee HR es capaz de

operar a 5.6 Kbps y requiere la mitad del ancho de banda del codee FR visto

anteriormente. La velocidad de muestreo es de 8 khz con una resolución de 13 bits y un

tamaño de frame de 160 muestras (20 ms) y una longitud de subframe de 40 muestras (5

ms) [3]. A continuación se presenta en dibujo esquemático del codificador /

decodificador se muestra en la Figura 2.3.

Figura 2.3 Diagrama de bloques del codificador / decodificador VSELP.

2.1.3. GSM Enhanced Full Rate (EFR) Speech Coder

El codee EFR fue el último en ser desarrollado para el sistema de G S M y opera

bajo el algoritmo "Algebric Code Excited Linear Prediction" (ACELP). Este codee fue

diseñado para la utilización del canal del codee FR y provee una mejora sustancial en

calidad comparado con el codee FR. Este codee utiliza 12.2 kbps para codificación de

voz y 10.6 para protección de errores [3]. A continuación se presenta en dibujo

esquemático del codificador / decodificador se muestra en la Figura 2.4

6

Figura 2.4 Diagrama de bloques dei codificador GSM enhanced.

Figura 2.5 Diagrama de bloques del decodificador GSM enhanced

7

2.1.4. GSM Adaptive Multi-Rate

El codee "Adaptive Multi-Rate"(AMR), es un codee de voz que ha sido

estandarizado para ser usado en la tercera generación de telefonía móvil(3G), dado que

es un codee adaptivo soporta 8 tazas de bits: 12.2, 10.2, 7.95, 7.40, 6.7, 5.9, 5.15, 4.75

kbps. El codee A M R utiliza A C E L P como algoritmo de compresión e incluye "Voice

Activity Detection"(VAD) y "Discontinuous Transmission"(DTX) como un método

para ahorrar ancho de banda y enviar menos bits por segundo cuando el usuario no está

hablando. En la Figura 2.4 y la Figura 2.5 se pueden ver los diagramas del codificador y

decodificador respectivamente.

2.2. Vector Sum Excited Linear Prediction (VSELP)

El algoritmo VSELP es una técnica de codificación de análisis por síntesis que

pertenece a los algoritmos de codificación conocidos como CELP (Code Excited Linear

Prediction) y fue diseñado para cumplir los siguientes requisitos [5]:

• Obtener las más alta calidad de voz posible.

• Cumplir una complejidad razonablemente sencilla.

• Ser robusto a errores en el canal.

VSELP consigue alcanzar estas metas haciendo un eficiente uso de codebooks de

excitación estructurados los cuales reducen la complejidad computacional y aumentan la

robustez en los errores en el canal. Para alcanzar la más alta calidad de voz son

utilizados dos codebooks manteniendo una complejidad razonable. Adicionalmente un

cuantizador de ganancia es utilizado para alcanzar una alta eficiencia de codificación.

8

Finalmente un arreglo de filtros adaptivos de pre/post filtrado es agregado para mejorar

la reconstrucción de calidad de voz.

Figura 2.6 Diagrama de bloques del codificador / decodificador VSELP.

2.2.1. Estructura básica del codificador / decodificador

E l codificador / decodificador de VSELP a 8Kbps utiliza 2 o 3 fuentes de

excitación. La primera es para el codebook adaptivo. En el caso de un codificador de

8kbps se utilizan 2 codebooks de excitación de VSELP los cuales contienen 128

vectores cada uno de ellos, en el caso del codificador de 4.8 kbps se utiliza un solo

codebook el cual contiene un equivalente a 2048 vectores [5]. Estas 3 fuentes de

excitación son multiplicadas por sus correspondientes ganancias y sumadas para generar

la secuencia de excitación ex(n).

Posteriormente en cada subcuadro, se utiliza ex(n) para actualizar codebook

adaptivo (estado del filtro de termino largo). El filtro de síntesis es un filtro LPC de

décimo orden. Los coeficientes de LPC son codificados cada cuadro de 20ms y los

parámetros de excitación son actualizados cada subcuadro de 5ms a través de una

9

interpolación para el codificador de 8kbps, para el codificador de 4.8 kbps las

actualizaciones son cada 30ms y 7.5ms respectivamente.

En el codificador a 8 Kbps el número de muestras de cada trama ( N ) es 40 y para

el codificador de 4.8 kbps es de N = 60. Finalmente, el post-filtro espectral sirve para

mejorar la calidad de la señal sintetizada

Los codebooks de excitación utilizados (1 ó 2), cada uno contiene 2 vectores de

código. Cada uno de ellos esta formado por un set de M vectores base, donde M = 7

para un codificador de 8 kbps y M = 11 para un codificador de 4.8 kbps. Definiendo

Vkm(n) como el Mesimovector base y Ukl(ri) como el Iesimo vector de código en el

Kesim0codebook entonces tenemos:

Donde K = 1 ó 2 dependiendo el codificador que se esté utilizando 0 < i < 2 — 1,

y 0<n</V - 1.

En otras palabras cada vector de código en el codebook es estructurado como una

combinación lineal de vectores base M . La combinación lineal está definida como por el

parámetro 0, donde dim esta definido como:

2.2.2. Estructura del codebook de VSELP

(1)

0im = +1 si el bit m del codebook es 1

0,™ = —1 si el bit ra del codebook es 0

10

La excitación de las palabras de código para el codificador de VSELP es más

robusta a errores de bit que la excitación de palabras de código de un codebook

aleatorio. Un error de bit en la palabra de código de V S E L P cambia solamente el signo

de un vector base. E l resultado del vector de código es todavía similar al vector de

código deseado.

2.2.3. Selección de vectores de excitación

La Figura 2.7 es un diagrama de bloques que muestra el proceso de selección

usado para seleccionar los 2 ó 3 índices para el codebook, siendo necesarios los índices

L , I y H necesarios para el codificador de 8 kbps y únicamente L y I son necesarios para

el codificador de 4.8 kbps. Estos parámetros de excitación son calculados cada

subcuadro

Figura 2.7 Selección de excitación de palabra de código.

11

H(z) es el filtro de síntesis de banda ancha expandido, donde H(z) = l/(A(zA)),

donde A es igual factor de peso del ruido, típicamente para un codificador de 8 kbps

A = .8 y para un codificador de 4.8 kbps, A = .9. p(n) es la señal de voz de entrada

perceptualmente ponderada (con el factor de peso del ruido A) para el subframe, esta es

restada con la salida del filtro de síntesis de banda ancha expandido con una entrada de

cero.

Los 3 vectores de excitación son seleccionados secuencialmente, donde será

seleccionado 1 por cada codebook, (3 para el codificador de 8 kbps y 2 para el

codificador de 4.8 kbps). Cada búsqueda en los codebooks intenta minimizar el error

total ponderado.

A pesar de que los vectores de código son escogidos secuencialmente, las

ganancias de los vectores de excitación son parcialmente "flotadas", es decir la

búsqueda del primer codebook se realiza asumiendo que las ganancias Yi y 7 2 s o n c e r o -

Primero es buscado el vector adaptivo, asumiendo que las ganancias Yi Y Yi s o n

cero. Posteriormente se realiza una búsqueda en el primer codebook de V S E L P

realizando una búsqueda conjunta de y1 y B asumiendo que y 2es cero. Finalmente, la

búsqueda en el segundo codebook de VSELP (si se presenta) se realiza haciendo una

búsqueda conjunta con B, yx y Y2- Estas búsquedas en conjunto pueden ser alcanzadas

por la ortogonalizacion de cada vector de código ponderado con cada vector de

excitación previamente seleccionado a la búsqueda del código. Mientas que esta tarea

puede resultar impráctica, para los codebooks de V S E L P se reduce a la ortogonalizacion

únicamente de los vectores base.

La búsqueda en el codebook adaptivo es realizada primero por un índice L , el cual

minimiza:

12

(2)

(4)

13

Donde b'L(ri) es la respuesta de estado cero H(z) a bL(ri) y B es óptima para cada

codebook con índice L .

Para realizar una búsqueda en cada codebook de VSELP, la respuesta de estado

cero de cada vector de código para H(z) debe ser calculado. Dada la definición de

VSELP (1), un vector de código filtrado fki(n)puede ser expresado de la siguiente

manera:

Donde qk,m(ri) es la respuesta de estado cero de H(z) al vector base Vki(n), 0 <

n< N — 1 y 1 < k < 2. La ortogonalización de vectores de código filtrados puede ser

expresado como:

(3)

Para 0 < i < 2 M - 1, y 0 < n < N - l y l < k < 2 . Si k = 1 entonces q'1¡m(ri) es el

componente para q1¡rn(n) el cual es ortogonal ab'L(ri). Si k = 2 entonces q2,m(n) es el

componente de í?2,m(n) e l c u a l e s ortogonal a ambos bL(n) y flt.

E l procedimiento de búsqueda del codebook ahora encuentra la palabra de código

que minimiza:

(5)

Donde k = 1 es para el primer codebook y k = 2 para el segundo y donde y'k es

óptimo para cada vector de código i , una vez que se han filtrado y ortogonalizado los

vectores base los procedimientos de búsqueda en el codebook actual son idénticos.

Por lo tanto el vector de código que maximice la siguiente ecuación será

seleccionado.

2.3. Segunda generación en la actualidad

Para el año 2006 se ha empezado el desarrollo de la tercera generación de

Celulares (3G), y algunos de los clientes comenzaron a migrar de la red de 2G a 3G, por

esta razón tenemos actualmente corriendo en paralelo las redes 2G y 3 G.

14

(6)

(7)

Una vez obtenidas los índices y ganancias se generan los 3 vectores se multiplican

por sus respectivas ganancias para obtener la amplitud adecuada y se suman para

ingresar al filtro de síntesis. E l resultado se utiliza para actualizar al código adaptativo y

generar los parámetros que serán enviados al codificador.

(8)

Los sistemas celulares de segunda generación se encuentran muy bien

establecidos, con más de 2 billones de usuarios a través del mundo, los sistemas que

incluidos en esta generación son G S M , CdmaOne y T D M A . Los principales atributos de

esta generación son la Transmisión digital., capacidades de voz, circuito de

conmutación de datos hasta alrededor de 60 kbits/s y la capacidad de conmutación de

paquetes de datos hasta 60 kbits/s

Sin embargo 2G ha continuado evolucionando, particularmente GSM, que tuvo su

lanzamiento en 1992 y para el año 2006 se han añadido una serie de características de

otros como: GPRS "General Packet Radio Service", M M S "Multi-Media Messaging",

HSCSD "High-Speed Circuit Switched Data", WAP "Wireless Access Protocol",

EDGE "Enhanced Data rates for G S M Evolution". Esta generación es conocida

comúnmente como 2.5G ya que incorpora algunas mejoras a la segunda generación

común pero sin alcanzar aun a la tercera generación.

Con la cada vez más cercana 3G sería muy común pensar en que 2G puede ser

sustituida muy pronto, sin embargo esto no puede suceder de esta manera dado que 3G

fue introducido mas tarde de los esperado. Por lo tanto el cambio total de 2G a 3G

podría tomar al menos 10 años. Además de esto 3G se ha introducido principalmente en

ciudades y corredores de mayor comunicación, sin embargo en zonas rurales 2G

continuara funcionando por un tiempo más. Un punto a tomar en consideración es que

el "roaming standard" de 2G es relativamente lucrativo y no es algo que el proveedor

desee perder. Por lo tanto algunas capacidades de 2G serán retenidas

Figura 2.8 Evolución de las generaciones de teléfonos celulares.

15

2.4. Trabajos relacionados: CADRE (Configurable

Asynchronous DSP for Reduced Energy)

C A D R E es un proyecto de tesis doctoral desarrollado por la universidad de

Manchester, la tesis describe la arquitectura de un DSP asincrono para consumo mínimo

de energía y cumplir los requerimientos de la siguiente generación de teléfonos

celulares [6].

C A D R E tiene una serie de características importantes en su arquitectura, por

ejemplo la explotación del paralelismo para mantener alto un rendimiento a la salida

disminuyendo las fuentes de voltaje utilizando 4 unidades funcionales de multiplicación

acumulación. La ejecución de instrucciones es controlada por memorias de

configuración localizadas dentro de unidades funcionales reduciendo la sobrecarga de

energía de la instrucción fetch. Cuenta con un register file muy grande para soportar el

tipo de datos requeridos por las unidades funcionales y haciendo uso de patrones de

acceso de datos reduce al mínimo el consumo de energía.

Finalmente C A D R E utiliza la representación de magnitud y signo para minimizar

la actividad de potencia dinámica a través del sistema. Esta característica permite

minimizar el sistema de control utilizando el sistema típico de un DSP como un adjunto

a un microprocesador en un sistema de teléfono celular.

Los resultados muestran la efectividad de las características arquitectónicas

aplicadas en C A D R E . E l paralelismo de las 4 unidades funcionales permite que se

mantenga un alto rendimiento de operación con el mínimo de consumo de energía. Sin

embargo, esto no es suficiente, ya que el procesamiento los elementos deben estar

plenamente ocupados para proporcionar un funcionamiento eficiente. Las memorias de

configuración dentro las unidades funcionales permiten a la arquitectura paralela ser

16

usada eficientemente en los complejos algoritmos del DSP, minimizando el consumo de

energía de las instrucciones fetch y decoding. Además de esto el uso de un buffer de

instrucciones permite eliminar grandes cantidades acceso de memoria de programa y

actualización del PC.

E l uso de un gran banco de registros permite que los datos suministrados a las

unidades funcionales sea a un ritmo lo suficientemente alto, y simplifica el diseño del

programa. Los resultados muestran que el diseño del banco de registros permite que el

costo de energía promedio de un acceso a datos en alrededor de 12 veces menos que si

los datos se recupera de la memoria principal. La elección del diseño asincrono para

C A D R E ofrece baja interferencia electromagnética y simplifica enormemente el manejo

de energía debido a que circuitos asincronos se apagan automáticamente cuando un

procesamiento no es requerido y puede reiniciar de forma instantánea. Por último, la

elección de la representación de magnitud y signo de los datos ofrece una actividad de

conmutación reducida. Sin embargo, el ahorro en el consumo de energía no es suficiente

para justificar la complejidad adicional de los elementos aritméticos.

Los resultados muestran que, individualmente, cada uno de los elementos de la

arquitectura tuvo un efecto considerable sobre la energía consumida. Sin embargo, el

rendimiento global de los cuadros en comparación con otros procesadores no era tan

bueno como se esperaba. E l consumo de energía de C A D R E fue dominada por los

elementos de procesamiento aritmético y para poder obtener un mayor beneficio de la

arquitectura C A D R E es necesaria una mayor optimización de estos componentes.

17

Capitulo 3

Simulación del Algoritmo de GSM Half-Rate (GSM-HR) en

el ambiente Seamless

En este capítulo se describe el proceso que se realizo para simular el algoritmo de

gsm Half-Rate (gsm-hr) utilizando la herramienta Seamless. Antes de comenzar a

describir el proceso de simulación es necesario aclarar los siguientes detalles: ¿Qué es

Seamless? y ¿Qué es ETSI? .

3.1. Seamless

Seamless es una herramienta para detección de errores (debugging) interactiva

entre hardware y software desarrollada por Mentor Graphics. Esta herramienta permite

acelerar el proceso de co-verificación permitiendo que cierto software pueda ser

ejecutado o simulado en hardware. Seamless incluye algunas librerías interactivas para

soportar algunos procesadores. Estas librerías se denominan PSPs (Processor support

packages). Estas proveen modelos a procesadores que aceleran la co-verificación. Los 2

principales componentes de un PSP son el modelo del conjunto de instrucciones (ISM)

y el modelo de la interfaz del bus.

E l modelo de la interfaz del bus simula el comportamiento de los pines de entrada

y salida del microprocesador para la sección de hardware de la co-verificación. E l

software ISM ejecuta por separado y mucho más rápido las instrucciones programadas.

Esto lo hace en un simulador de software. Durante la co-verificación la mayoría de las

operaciones del procesador son tareas de rutina tales como la lectura de instrucciones o

el escribir o leer datos del Stack. En Seamless normalmente el simulador lógico ejecuta

18

los ciclos para el acceso del bus. Los principales componentes de la arquitectura de

Seamless para co-verificación se muestran en la Figura 3.1 y se describen a

continuación [11].

Simulador de software. Este programa ejecuta la porción de software de la

sesión de co-verificación. Esta sección se encarga de ejecutar el código de máquina que

el usuario produce cuando se compila un código para un procesador específico. La

interfaz del simulador de software controla la ejecución del ISM y ejecuta operaciones

tales como correr el programa paso a paso, inspección de memoria y funciones típicas

de un simulador de software.

Kernel de co-verificación. Este programa controla la comunicación entre la

porción de software y la lógica durante la co-verificación. Esta sección permite al

usuario configurar varios aspectos de la co-verifcación por medio de la ventana de

sesión de Seamless. Entre estos aspectos están algunas optimizaciones de acceso de

memoria.

El simulador lógico y el kernel de simulación lógica. Estos programas

implementan la porción de hardware de la sesión de co-verificación. Se pueden manejar

uno o más modelos de interfaces de bus de microprocesadores y algunos modelos de

memoria en el diseño de hardware, el cual generalmente es expresado en un lenguaje de

descripción de hardware (HDL). E l simulador lógico controla la ejecución de un diseño.

Entonces el kernel de simulación lógica ejecuta la co-verificación H D L del diseño.

19

Figura3.1 - Arquitectura Seamless

Otra de las ventajas de este programa consiste en una aplicación denominada

Performance Profiler. Esta aplicación permite registrar algunas métricas de desempeño

del diseño. Entre estas métricas se cuenta con las mostradas en la Tabla 3.1.

Tabla 3.1 - Métricas con las que cuenta el Performance Profiler

Code Profile El cual se puede analizar el porcentaje de tiempo total que el

programa permanece en alguna función o procedimiento.

Bus Load El cual se analiza el porcentaje de utilización del bus de los

microprocesadores del diseño

Arbitration Delay El cual permite analizar las esperas para poder ocupar el bus

principal por cada uno de los microprocesadores.

20

SW Gant Chart E l cual muestra el periodo de tiempo en el cual se ejecuta cada

una de las funciones o procedimientos del programa. Eso se

despliega mina gráfica de Gant.

Memory

Transactions

El cual permite ver las operaciones de memoria realizadas en

cada momento por los microprocesadores. Aquí se permite ver el

momento en que se realizó una lectura o escritura de memoria.

Estas métricas ayudan a los diseñadores a decidir nuevas mejoras en el sistema

tales como un nuevo particionamiento, incremento de memoria, optimización de código,

etc. La forma en que puede obtener estas métricas es simplemente que existe un módulo

de hardware denominado bus monitor, el cual se cuelga de la interfaz y monitorea en

cada momento el estado del bus. De esta forma se obtienen las estadísticas

mencionadas.

E l sistema mínimo para poder implementar un diseño de hardware-software

consiste en un microprocesador, una unidad de memoria, una interfaz y una señal de

reloj. Con lo anterior, es posible ejecutar algún software en el microprocesador. A partir

de esta estructura básica es posible agregar módulos adicionales de hardware e

incorporarlos al diseño.

3.2. ETSI

European Telecommunications Standards Institute o mejor conocido como ETSI

es una organización de estandarización de la industria de las telecomunicaciones

(fabricantes de equipos y operadores de redes) de Europa. Esta organización posee una

proyección mundial creada en 1988 por el CEPT (conferencia europea de correos y

telecomunicaciones).

21

ETSI produce estándares globalmente-aplicables para tecnologías de información

y telecomunicaciones, incluyendo fijas, móviles, cobertura de radio, tecnologías de

broadcast e internet. E l ETSI ha tenido gran éxito al estandarizar el sistema de telefonía

móvil GSM.

3.3. Código en lenguaje C para GSM-HR

El código en C para el algoritmo de GSM-HR fue extraído de la pagina del ETSI

[4], bajo el siguiente nombre "ETSI EN 300 967 ¥8.0.1(2000-11)", en el cual se

obtienen los siguientes 2 archivos:

• Un archivo .pdf cuyo contenido explica la estructura y jerarquías del código

desarrollado en C.

• Un archivo .zip el cual contiene una carpeta llamada DISK, la cual a su vez

contiene lo siguiente:

o Carpeta C: Contiene todos los códigos .c y .h necesarios para

implementar el algoritmo GSM-HR

o Carpeta D: Contiene archivos de prueba para comprobar el

funcionamiento del programa,

o Carpeta E X E C : Contiene los makefiles utilizados para compilar el

código y generar un ejecutable,

o Carpeta Utils: la cual contiene herramientas útiles para probar el

programa.

o Archivo readme.text_ el cual tiene una breve explicación de lo que

realiza el código, como se compila y como probarlo

Es muy importante destacar que este código está diseñado para compilarlo en las

siguientes plataformas Sun, Vax y PC (utilizando el compilador acc). E l primer paso fue

modificar el makefile para que este sea compilado por un compilador gcc y genere un

archivo ejecutable. E l makefile utilizado se encuentra en el Apéndice A . l .

22

Una vez compilado el archivo fue necesario comprobar su funcionamiento. Para

realizar esto, se siguieron los pasos descritos en el diagrama de flujo presentado en la

Figura 3.1. Estos pasos fueron extraídos del archivo readme.text proporcionado por el

ETSI y son explicados a continuación.

Figura3.2 - Procedimiento de comprobación de código

E l primer paso es realizar la codificación del archivo de datos de entrada con el

programa gsm_hr. Posteriormente en el segundo paso se utiliza el programa reid para

convertir el archivo de resultado del paso anterior para generar el archivo a codificar,

este programa únicamente realiza una validación de que el archivo de entrada sea

correcto y pueda ser decodificado. En el paso tres se utiliza nuevamente el programa

gsm_hr para realizar una decodificación en esta ocasión, finalmente en el último paso se

comparan los archivos generados en cada una de las etapas anteriores con los archivos

proporcionados por el ETSI, esta comparación debe dar como resultado, que no existe

ninguna diferencia entre estos archivos. Las instrucciones para realizar este

procedimiento se pueden ubicar en el Apéndice A.2.

3.3.1 Adecuación del Software

Seamless es una plataforma para integración de hardware y software para sistemas

embebidos por lo cual no cuenta con un sistema operativo que permita la lectura y

23

generación de archivos. Por esta razón es necesario adecuar el software para que

funcione sin tener que abrir ningún archivo y sin generar un archivo de salida. Esto se

realizo abriendo el archivo Short.inp para leer los datos de entrada y posteriormente

guardarlos en memoria dentro de un arreglo de datos. Los datos de salida son

almacenados en un arreglo en memoria y de esta forma evitamos generar el archivo de

salida Shorttst.cod. Para poder leer una entrada de datos desde memoria y poder escribir

los parámetros de salida en una sección de memoria, fue necesario realizar

modificaciones extras en algunas secciones de código. Estas modificaciones son

presentadas en la tabla 3.2.

Tabla 3.2 - Modificaciones de software.

Archivo Función Descripción Modificación

Host.c HostEncoderlnt

erface

Abre un archivo de datos de voz

y apaga los 3 primeros bits de

cada muestra

Se cambio la función fread para lectura

de archivos por un ciclo for y una

variable estática que donde se leen las

muestras de una trama de datos desde

memoria. Código en Apéndice A.3

host.c WhiteEncFile Escribe los parámetros

codificados en un archivo de

salida

Se cambio la función fwrite para

escritura de archivos por un ciclo for y

una variable estática que permite escribir

los datos de salida en memoria de forma

ordenada. Código en Apéndice A.4

Main encodeMem Codifica los datos recibidos Manda a llamar a la modificación de

hostEncoderlnterface y WriteEncFile.

Código en Apéndice A.5 Host.c SpeechDecoder

Hostlnterface

Escribe los datos truncados pcm

en un archivo de salida

Se elimino del programa debido a que el

experimento solo incluye la etapa de

codificación

Host.c ReadDecfile Lee los parámetros de entrada

para el decodificador desde un

archivo de datos

Se elimino del programa debido a que el

experimento solo incluye la etapa de

codificación

gsm_hr.c Main Función principal del código, de

acuerdo a los parámetros de

entrada, decide si debe hacerse

una codificación o

Se elimino completamente la parte de

decodificación y se agrego la función

para generar los archivos de entrada en

memoria. Código en Apéndice A.6

24

decodificación del archivo de

entrada y posteriormente

generar un archivo de salida

gsm_hr.c Fillmem Inicializa el arreglo de datos de

entrada

Se agrego esta función con la finalidad

de inicializar el arreglo de datos de

entrada al programa. Código en

Apéndice A.7

Por simplicidad se seleccionaron únicamente 2 tramas (320 datos) para realizar el

experimento, las tramas seleccionadas fueron las tramas 10 y 11 del archivo Short.inp.

Por cada trama de 160 datos se generan 20 datos de salida, por lo tanto se generaran los

datos 200 al 240 del archivo Shorttst.cod.

Para comprobar el funcionamiento del programa se corrieron ambos programas y

se compararon uno a uno los datos de entrada y resultados de salida de las tramas en

cuestión. Los resultados generados de la simulación se presentan en la Tabla 3.3.

Tabla 3.3 - Resultados obtenidos en la simulación del programa gsmhr

Muestra Dato Muestra Dato Muestra Dato Muestra Dato

1 17 11 222 21 17 31 478

2 1790 12 1 22 1846 32 20

3 157 13 13 23 155 33 8

4 36 14 189 24 155 34 205

5 0 15 8 25 1 35 20

6 2 16 8 26 3 36 8

7 107 17 489 27 117 37 487

8 501 18 11 28 354 38 25

9 0 19 1 29 20 39 1

10 13 20 1 30 6 40 1

25

3.3.2 Simulación en Seamless

Para poder correr el código principal en Seamless o cualquier microprocesador es

necesario un código de arranque para configurar el microprocesador y arrancar el

programa principal (gsm_hr). E l código de arranque utilizado se puede encontrar en el

Apéndice 4.

A l realizar la simulación del algoritmo en Seamless obtuvimos información muy

importante. Como se menciono anteriormente en este capítulo Seamless cuenta con una

herramienta llamada Code Profile la cual permite obtener el tiempo total que emplea el

procesador en ejecutar las subrutinas del programa implementado. En la Figura 3.2

podemos ver los resultados obtenidos al simular el código de gsm_hr.

Figura 3.3 - Resultados obtenidos con el performance profiler de Seamless

En la Figura anterior se observan las funciones o etiquetas del programa que

consumen más ciclos de reloj por parte del procesador. Como se puede observar, el

procesador se encuentra realizando la operación de multiplicación acumulación

(L_mac) el 23.8% del tiempo total del programa. Esto quiere decir, que si el tiempo de

26

duración de esta operación en particular fuera menor, afectaríamos al 23.8 % del tiempo

de todo el programa. Por esta razón, se selecciono esta operación para ser optimizada

Observando más a detalle en la Figura 3.3, tenemos la información

correspondiente a la función L_mac (multiplicación acumulación). En esta Figura

podemos observar que dicha operación fue invocada 152,503 ocasiones y tiene un

promedio de duración desde 320 ns a 3, 040 ns dando un promedio de 1,786 ns en

ejecutarse. Tomando en cuenta que el ciclo de ejecución del microprocesador es de 40ns

tenemos que esta operación puede llegar a tardar hasta 76 ciclos de reloj y un mínimo de

8 ciclos en ejecutarla. Este tiempo de ejecución es muy elevado y podría ser aplicada en

menos instrucciones si fuera implementada en hardware. Por lo tanto, en el siguiente

capítulo, se desarrollara una arquitectura que realice esta operación en un modulo

externo utilizando un lenguaje de descripción de hardware (HDL).

Figura 3.4 - Información de la función L_mac

27

Capitulo 4

Propuesta de arquitectura para el modulo L_mac

En este capítulo el funcionamiento en software de la función L_mac y se propone

una arquitectura para un modulo externo que implemente esta función en hardware y de

la misma forma se explicara la arquitectura para la interconexión de este modulo con el

microprocesador.

4.1 Descripción de la función L_mac

La función L m a c se encuentra compuesta por dos partes la operación de

multiplicación y la operación de suma. Cada una de estas partes se describirá a detalle a

continuación.

4.1.1 Descripción de la función multiplicación (L_mult).

La función L m u l t visto de manera general realiza una multiplicación de dos

números de 16 bits y regresa el resultado en un número de 32 bits. Además de esta

acción L m u l t realiza un par de comparaciones para identificar si ocurre o no un

overflow., si esto llega a ocurrir se regresa un valor predefinido sin realizar ninguna

multiplicación. En caso de no existir un overflow se realiza la operación de

multiplicación y posteriormente se realiza un corrimiento a la izquierda sobre el

resultado antes de regresar dicho número como resultado final.

28

Implementar esta función en software tiene una serie de desventajas. Requiere una

serie de operaciones consecutivas lo cual se puede traducir como más ciclos de reloj y

más energía consumida. E l número de mnemónicos utilizados no es un número fijo, esto

se debe a las condicionales realizadas para verificar el overflow ya que si alguna de

estas condiciones se cumple puede o no ejecutar un conjunto de mnemónicos

adicionales para obtener el resultado. E l código de esta operación se presenta en el

Apéndice B. 1.

Por otro lado al tratarse de operaciones muy simples. Estas pueden ser

implementadas en un modulo de hardware de forma más eficiente y en mucho menor

tiempo. Obteniendo como resultado menor número de operaciones y un número exacto

de operaciones a realizar durante todo el programa.

4.2 Descripción de la función suma (L_add).

La función L_add visto de manera general realiza una suma de dos números de 32

bits y regresa el resultado en un número de 32 bits. Además de esta acción la función

L_add implementa una lógica para determinar si existe o no un underflow u overflow,

Si llegara a ocurrir alguno de estos dos casos se regresa un valor predefinido para cada

situación.

La Implementación en software de esta función tiene una serie de desventajas.

Requiere una serie de operaciones consecutivas para determinar si existe o no un

underflow u overflow lo cual se puede traducir como más ciclos de reloj y más energía

consumida. E l número de mnemónicos utilizados no es un número fijo, esto se debe a

las condicionales realizadas para verificar la existencia de un underflow u overflow ya

que si alguna de estas condiciones se cumple puede o no ejecutar un conjunto de

mnemónicos adicionales para obtener el resultado. E l código de esta operación se

presenta en el Apéndice B.2

29

La implementación de la lógica de verificación y suma puede ser fácilmente

implementada en hardware. Un modulo en hardware puede obtener resultados en un

solo ciclo de reloj proporcionando más velocidad y eficiencia.

4.3 Arquitectura propuesta para operación de

multiplicación.

Las operaciones de multiplicación son más complejas que las operaciones de

adición o sustracción. Inicialmente en algunos procesadores, la multiplicación era

llevada a cabo como una rutina de software, en la cual básicamente, realizan la

multiplicación como una secuencia de sumas y desplazamientos. Sin embargo, los

microprocesadores de alto desempeño, disponen de multiplicadores implementados en

hardware para incrementar la velocidad de las operaciones aritméticas. En este caso, el

bloque funcional que realiza la multiplicación es siempre un bloque esencial en

cualquier sistema de procesamiento digital de señales. Sin embargo para aplicaciones

como smart-cards y telefonía celular, los principales criterios de diseño son relacionados

con el área y la potencia disipada.

4.3.1 Multiplicador basado en el algoritmo de booth

Este algoritmo fue propuesto por Booth en 1951, con el que se consigue reducir el

número de productos parciales generados, gracias a un sistema de codificación en donde

se analizan series de unos o ceros consecutivos [7]. Este algoritmo es recomendado para

sistemas de bajo consumo de energía y mínimo espacio de área de hardware. E l

Algoritmo de Booth presenta dos ventajas importantes: Primero unifica los

multiplicadores tanto para números binarios positivos como negativos de n bits,

transformándolos en versiones adecuadas de multiplicandos de n bits que se suman para

30

generar productos de 2n bits de signo correcto, en el sistema de representación numérica

de complemento a dos. Segundo, logra cierta eficiencia respecto al número de productos

parciales generados, cuando el multiplicador tiene algunos bloques grandes de unos [6].

Como sabemos, la operación de multiplicación se realiza con dos operaciones

básicas: la suma y el desplazamiento lógico. De estas dos operaciones la que consume

más tiempo es la suma. Con este conocimiento el algoritmo de booth pretende

minimizar el número de sumas que se realiza durante el proceso de multiplicación para

ello se toma en cuenta la igualdad presentada en la ecuación 4.1 para sustituir cadenas

de unos o ceros consecutivos:

2 n - i + 2 n - 2 + . . . + 2 1 + 2 o = 2 n - 1 (4.1)

Primer paso necesario en el algoritmo de booth es representar el multiplicador en

un número re-codificado bajo la forma de dígitos con signo. Para realizar esto es

necesario analizar los bits Bt y B^x y sustituir el bit de posición i según se muestra en

eltablal.

Tabla 4 .1- Recodificación de dígitos según el algoritmo de booth

Bits del Digito multiplicador Recodificado Operación Bi Bi-\ 0 0 0 Ox multiplicando 0 1 1 l x multiplicando 1 0 -1 — l x multiplicando 1 1 0 Ox multiplicando

E l procedimiento del algoritmo de booth puede ser explicado con el diagrama de

flujo de la Figura 4.1. Siguiendo este algoritmo se consigue que una cadena de "n" unos,

que en un algoritmo clásico se requieren "n" sumas y "n" corrimientos, pueda disminuir

31

su complejidad a que únicamente sean requeridas 2 sumas y n corrimientos. Esto puede

ser claramente visualizado en el siguiente ejemplo:

A = 0011

B = 0110

Reg_salida = "OOOO" & B = 00001110

Primera iteración:

Regsalida = 00000110 Bit_ant(0) = 0 ; no hay suma ni resta

Regsalida = 00000011 Bit_ant(0) = 0 ; corrimiento a la derecha

Segunda iteración:

Reg_salida = 11010011 Bit_ant(0) = 0 ; realiza resta

Regsalida = 11101001 Bit_ant(0) = 1 ; corrimiento a la derecha

Tercera iteración:

Regsalida = 11101001 Bit_ant(0) = 0 ; no hay suma ni resta

Reg_salida = 11110100 Bit_ant(0)=l ; corrimiento a la derecha

Cuarta iteración:

Reg_salida = 00100100 Bit_ant(0) = 1 ; Realiza Suma

Reg_salida = 00010010 Bit_ant(0) = 0 ; corrimiento a la derecha

32

Ahora una vez explicado el funcionamiento del algoritmo se describirá la

arquitectura necesaria para implementarlo. En la Figura 4.2 se presenta un diagrama de

bloques de la arquitectura necesaria para la implementación del algoritmo de booth.

Figura 4.2 - Arquitectura para implementación del algoritmo de booth

33

Figura 4.1 - Diagrama de flujo del algoritmo de booth.

Para realizar nuestra operación de multiplicación necesaria para la instrucción

M A C que deseamos implementar, tenemos que los datos de entrada son números de 16

bits expresados en complementos a dos y nuestro resultado se encuentra en 32 bits en

complementos a dos. La arquitectura necesaria se compone de una unidad A L U capaz

de realizar sumas y restas en complementos a dos, un registro de corrimientos a la

derecha de 32 bits una unidad de control capaz de identificar por medio de la tabla 4.1 si

se debe realizar una suma, una resta o simplemente un corrimiento. Se cuenta con un

registro T para guardar el valor de signo en el momento de realizar los corrimientos y

finalmente se necesita un registro de 32 bits como salida del multiplicador. E l código en

V H D L para la implementación de este modulo se tiene encuentra en el apéndice B.3.

4.4 Análisis de Propuesta para implementación suma.

Sin importar si se trata de un sistema de propósito general o un procesador de

aplicación especifica la suma es la operación más frecuentemente usada. Por lo tanto es

muy importante seleccionar cuidadosamente que arquitectura es ideal para nuestra

aplicación. En [8] se realiza un análisis de diferentes arquitecturas para realizar la

operación de suma en forma paralela. Las arquitecturas propuestas analizadas son las

siguientes: sumador de acarreo propagado, sumador con esquivo de acarreo, sumador

con selector de acarreo, sumador con acarreo con vista hacia adelante, sumador con

digito con signo y sumador con acarreo salvado

A continuación se presentan algunos de los resultados presentados en [8]. Todos

los resultados presentados son para operaciones de 32 bits debido a que son los bits

necesarios para nuestra aplicación.

34

Figura 4.3 - Comparativa de Área entre sumadores

En la gráfica de barras presentada anteriormente podemos observar como la

arquitectura de sumador de digito con signo presenta la arquitectura con mayor área. Lo

cual para nuestra aplicación es poco recomendable. Por otro lado las arquitecturas del

sumador con acarreo propagado y el sumador con selector de acarreo poseen la menor

área de circuito y siendo muy recomendadas para esta aplicación.

Figura 4.4 - Comparativa de retraso entre sumadores

Si bien el área es un factor muy importante para nosotros debemos tomar en

cuenta otros factores muy importantes como lo es el tiempo de respuesta del sumador.

En la gráfica de barras presentada en la Figura 4.4, Podemos observar como las dos

arquitecturas que nos brindaban menor área de circuito presentan un retraso mucho

35

mayor a las demás arquitecturas lo cual hace que estas opciones no sean recomendadas

como una propuesta para nuestro modulo.

Finalmente dado que nuestra aplicación tiene como propósito disminuir el

consumo de energía disipada una comparativa entre estos sumadores con respecto al

consumo de energía disipado al realizar operaciones de 32 bits es por demás obligatoria.

Figura 4.5 - Comparativa de disipación de energía promedio entre sumadores

En la Figura 4.5 podemos observar como la potencia disipada en los sumadores de

dígitos con signo y el sumador con selector de acarreo es mayor a los otros sumadores.

Con esta información presentada obtenemos que la arquitectura del sumador con

acarreo con vista hacia adelante es la arquitectura idónea para nuestra aplicación pues

posee un balance entre tamaño, velocidad y promedio de energía disipada.

36

4.4.1 Sumador con acarreo con viste hacia adelante

La base del funcionamiento de este sumador es la descomposición del Acarreo en

dos partes, el Acarreo propagado y el Acarreo generado.

E l Acarreo Generado (G) se obtiene si los dos sumandos son 1 (ai y bi = 1).

E l Acarreo Propagado (P) se obtiene si alguno de los dos es 1 entonces se propaga

el Acarreo de la suma anterior (Ci + 1 = afii + a¡c¿ 4- 6iC¿).

P y G no dependen del Acarreo anterior:

P ¿ = a¿ xor bi

Gi = a¿ and b¿

Con estas ecuaciones reescribimos la suma y el Acarreo usando P y G de la

siguiente forma:

Si = c¡ xor Pi

Ci+i = Gi or Pi and C¿

Con esto obtenemos que no existe ninguna dependencia de los valores anteriores y

los Acarreo de cada bit pueden ser calculados independientemente. Lo cual permite

acelerar el proceso de suma en paralelo.

La arquitectura para un sumador con acarreo con vista hacia adelante de 4 bits se

puede observar en la Figura 4.6

37

Figura 4.6 - Diagrama de bloques de un sumador de 4 bits con acarreo con vista hacia

adelante

4.5 Propuesta para integración del modulo MAC con el

microprocesador.

La integración del modulo M A C a la arquitectura básica de operación de

Seamless es un punto muy importante para el proceso pues limita y define como debe

de operar el modulo M A C que se planea implementar. La arquitectura mínima de

funcionamiento para Seamless cuenta con un microprocesador, una memoria y un bus

para interconectar ambos componentes. La Figura 4.7 presenta la arquitectura mínima

para Seamless [11].

Figura 4.7 - Arquitectura mínima para Seamless

38

Basándonos en esta arquitectura usaremos la interfaz de bus (AMBA) para

interconectar nuestro modulo con el microprocesador. De esta manera para proporcionar

los operandos será necesario únicamente realizar escrituras de memoria (Store) y para

obtener el resultado únicamente se realizara una lectura de memoria (Load). Para ello es

necesario explicar el funcionamiento de las unidades de memoria con las que trabaja

Seamless.

La Unidad de memoria en Seamless (SRAM) define una unidad de de 8 x 255

bits, contiene las entradas y salidas típicas de una memoria. Estas se describen a

continuación y se muestran en la Figura 4.8.

• A D D R . Bus de direcciones de 16 bits. Es una entrada.

• DQ. Bus de datos de la memoria. Es una puerto bidireccional.

• CE. Señal de habilitación y deshabilitación de la memoria. Es una entrada y es

activa en bajo.

• WE. Señal de control de lectura y escritura. Es una entrada y se realiza una

escritura cuando se encuentra esta señal en bajo.

• OE. Señal de habilitación de puerto de salida para lectura. Es entrada y es activa

en bajo

ADDR(16) B

WE

£9 SRAM • DQ(16) OE 3 i l n - ° u t

Figura 4.8 - Diagrama de un sub-bloque que conforma la memoria del sistema

Con esta información obtenemos que nuestro modulo M A C solo puede tener una

entrada de datos y será necesario utilizar el bus de direcciones A D D R para direccionar

el dato vamos a ingresar. Utilizaremos un CE para habilitar en qué momento debe de

39

Figura 4.8 - Diagrama de un sub-bloque que conforma la memoria del sistema

Con esta información obtenemos que nuestro modulo M A C solo puede tener una

entrada de datos y será necesario utilizar el bus de direcciones A D D R para direccionar

el dato vamos a ingresar. Utilizaremos un CE para habilitar en qué momento debe de

operar el modulo y un RE para saber identificar una lectura de información. En la

Figura 4.9 observamos una representación del modulo M A C .

Figura 4.9 - Diagrama de un sub-bloque que conforma el modulo MAC

En la Figura 4.10 se observa la arquitectura para interconectar el modulo M A C

junto con la arquitectura básica de Seamless. E l microprocesador se conecta mediante la

interfaz de bus A M B A con el controlador A H B el cual tiene la función de identificar si

se realiza una escritura o lectura de información. E l decodificador de direcciones

obtiene del controlador A H B la dirección de memoria sobre la cual se realizara una

escritura o lectura y generara un Habilitador (Div_en) para el dispositivo designado. E l

modulo M A C se comunica utilizando el de 32 bits de datos para recibir los operandos y

devolver el resultado de la operación, es importante resaltar que los operandos

necesarios para el modulo M A C son: 2 números de 16 bits para realizar la

multiplicación y un número de 32 bits para realizar la suma. Para utilizar el total de bits

de datos los operandos de multiplicación serán enviados juntos en una sola dirección

como se muestra en la Figura 4.11. Debido a que solo se requieren escribir 2 datos de

entrada y leer un resultado de salida únicamente se utilizaran los dos bits menos

significativos del bus de direcciones. La entrada de CE de nuestro modulo únicamente

se activara cuando se requiera realizar una escritura por lo tanto se utiliza una

compuerta or para con las señales Div_en(7) y la señal WE(0), esto se debe a que

Div_en(7) es la señal que activa el controlador de direcciones cuando se refiere al

modulo M A C y WE(0) es el habilitador del bloque de memoria al que se encuentra

mapeado el modulo M A C .

40

Figura 4.10 - Arquitectura final de Implementación del modulo MAC con

microprocesador

Figura 4.11 - Formato de envió de operandos para multiplicación

4.5.1 Envió de datos al modulo MAC en software.

Como se mostró anteriormente el envió de datos al modulo M A C se realizara

mediante escrituras y lecturas de memoria por lo tanto será necesario modificar el

funcionamiento de la función M A C anterior. La escritura y lectura de datos de memoria

en lenguaje C se realizo mediante el uso de apuntadores y se creó una función "Sort" la

cual realiza la operación de acomodar los operandos de multiplicación (16 bits) en un

solo número (32 bits). E l proceso realizado para el enviar y recibir datos del modulo

M A C se puede ver en la Figura 4.12.

41

Figura 4.12 - Proceso de comunicación con el modulo MAC

Como se puede observar en la Figura 4.12 se envía primero el operando de suma,

esto se debe a que la función para ordenar los operandos del multiplicador requiere una

serie de pasos y el compilador al trabajar con optimización de código ejecuta el envío

del operando de suma antes de los operandos de multiplicación, por esta razón el

modulo M A C debe recibir los datos en este orden.

4.6. Arquitectura interna del modulo MAC.

Con los datos descritos en los puntos anteriores podemos resaltar las restricciones

de operación del modulo M A C .

• Debe generar el mismo resultado de la operación M A C descrita en software

• Debe ser capaz de recibir los 3 operandos por un solo bus de datos.

• Debe generar una salida 3 estados para mantener la operación con las memorias

S R A M conectadas al mismo bus de datos.

• Debe tener la lógica para asignar los operandos de acuerdo a las direcciones con

las que fue recibido.

• Debe recibir primero el operando de suma antes de los operandos de

multiplicación.

42

Tomando en consideración estas restricciones se diseño una arquitectura interna

para el modulo M A C capaz de cumplir cada una de ellas. Esta arquitectura se presenta

en la Figura 4.13 y se describe a continuación:

E l bloque de selección lógica direcciona los datos recibidos por el bus

bidireccional DQ hacia los registros 1, 2 ó 3 dependiendo de la dirección recibida y si el

CE este activado. Además de esta función el bloque de selección lógica se encarga del

control del bus de salida manteniéndolo en alta impedancia mientras no se desee leer un

dato de él.

Figura 4.12 - Arquitectura interna para el modulo MAC.

La inserción de registros dentro del modulo nos permite mantener el valor de los

datos en las entradas de los módulos de suma y multiplicación respectivamente aun

cuando el valor en el bus DQ haya cambiado. Es necesario retrasar el operando de suma

utilizando dos registros en la entrada de datos del sumador. Esto se debe a que esté

operando es recibido primero y los operandos de multiplicación no han sido recibidos

previamente y esta operación debe realizarse antes de la suma.

43

Los bloques de multiplicación y suma realizan la operación exacta de las

funciones de L_mult y L_add respectivamente, incluyendo las verificaciones de

overflow y underflow necesarias en estas operaciones. E l código en vhdl para la

implementación de esta arquitectura puede ser encontrado en el Apéndice B.4.

Capitulo 5 Resultados

En el capítulo 3 se presento el procedimiento para simular el programa gsm_hr

usando la herramienta Seamless y se comentaron algunos resultados obtenidos de esta

simulación. Posteriormente en el capitulo anterior se presento la arquitectura e

interconexión del modulo M A C propuesta en esta tesis. En este capítulo se pretende

mostrar los resultados obtenidos después de agregar el modulo M A C a la arquitectura

mínima ARJVI de Seamless y posteriormente realizar una comparación de los resultados

obtenidos.

5.1. Resultados obtenidos de la simulación del programa

gsm_hr utilizando el modulo MAC.

5.1.1 Funcionalidad.

Recordando lo que se menciono en el capítulo 3 se realizo la simulación de

únicamente 2 frames (160 muestras), esto genera 40 resultados de datos a transmitir.

Para comprobar la funcionalidad del modulo M A C se repitió la anterior simulación

utilizando el modulo M A C para realizar las operaciones de la función L_mac. La prueba

44

de funcionalidad arrojo resultados que fueron exactamente iguales a los resultados

presentados en la Tabla 3.2 en el capítulo 3.

5.1.2 Desempeño

Utilizando nuevamente la herramienta Code Profiler de Seamless obtenemos el

tiempo total que emplea el procesador en ejecutar las subrutinas del programa gsmhr.

Los resultados obtenidos se presentan en la Figura 5.1.

Figura 5.1 - Resultados obtenidos por el code profíle en la simulación del

programa gsmhr utilizando el modulo M A C .

Comparando estas gráficas con los resultados obtenidos por el programa sin

utilizar el modulo M A C (Figura 3.3). Podemos ver como hay una reducción de 2.2 en

el porcentaje de tiempo utilizado por el procesador para realizar la operación de

multiplicación y acumulación (L_mac). En la Figura 5.1 observamos a detalle las

propiedades de esta función. Realizando una comparación de esta Figura con la Figura

3.5 podemos ver como el número de llamadas es en ambos programas igual a 152, 503

llamadas, sin embargo el tiempo de ejecución es muy diferente, en la Figura 3.2

podemos ver que el tiempo mínimo de ejecución es de 320ns y el tiempo máximo de

45

ejecución es de 3, 040ns dando un tiempo promedio de l,786ns. De forma contraria, en

la Figura 5.2 observamos como el tiempo promedio y el tiempo mínimo es el mismo,

esto se encuentra justificado debido a que las operaciones ejecutadas son realizadas en

hardware y el propósito de esta función es únicamente enviar y recibir datos y

resultados respectivamente. Aun cuando el tiempo mínimo de ejecución en software es

menor (320ns), el tiempo promedio de ejecución en hardware es ligeramente menor, es

por esta razón la pequeña diferencia en el porcentaje de tiempo ocupado por el

procesador en realizar la función.

Figura 5.2 - Propiedades de la función Lmac obtenidas por el code profile en la

simulación del programa gsm_hr utilizando el modulo MAC.

Hasta este punto únicamente se ha revisado el desempeño individual de la función

L m a c . Sin embargo siendo esta la función más utilizada en el programa gsm_hr, una

modificación de los tiempos de operación en esta producirá un cambio en el programa

principal. En la Figura 5.2 se presentan las características de la función principal "main"

de el programa gsm_hr sin utilizar el modulo M A C y en la Figura 5.3 tenemos las

características de esta misma función utilizando el modulo M A C .

46

Figura 5.3 - Propiedades de la función

main sin utilizar el modulo M A C

Figura 5.4 - Propiedades de la función

main utilizando el modulo M A C

Comparando el tiempo de ejecución de estas dos funciones observamos que este

tiempo es menor por casi 40 ms para la función main utilizando el modulo M A C . Con

esto comprobamos que el modulo M A C produce una mejora en el desempeño del

programa sin embargo esta mejora no es del todo significativa para justificar la

incrustación de nuevo hardware.

5.1.3 Mediciones del Consumo de energía del procesador

Utilizando el code profile es posible realizar mediciones del consumo de energía

del programa gsm_hr. En la Tabla 5.1 se presentan los resultados obtenidos por este

simulador. Es importante resaltar que estos resultados muestran la energía consumida

por el procesador sumando las siguientes categorías: CPU, System, I Cache y D Cache.

Los resultados obtenidos para el modulo M A C muestran la energía consumida por el

procesador al realizar operaciones con las direcciones de memoria en las cuales se

encuentra mapeado el modulo M A C (FFFF8000-FFFF8002).

47

Tabla 5.1 - Resultados de consumo de energía obtenidos por code profile de

Seamless

Etiqueta

Min

(mW)

Max

(mW)

Avg

(mW)

Total

(mW)

Consumo de energía

(Sin Modulo M A C )

84.43 123.72 114.12 166854.79

Consumo de energía

(Con Modulo M A C )

79.79 122.35 102.35 156394.32

Consumo de energía

(Modulo M A C )

25 26.7 25.7 39279.55

En la Tabla 5.1 se observa cómo se obtiene una disminución de 11.77mW en la

potencia promedio consumida por el procesador utilizando el modulo M A C con

respecto al programa original. Esta reducción es completamente justificada debido a que

se han reducido el número de instrucciones procesadas por la función L_mac. Respecto

a la potencia total consumida por el procesador hay una disminución de 10460.47mW,

debido a que además de reducir el consumo de energía promedio se ha reducido el

tiempo de operación del procesador y por lo tanto la energía total consumida.

5.1.4 Mediciones del Consumo de energía del modulo MAC

Las mediciones del consumo de energía producido por el modulo M A C al realizar

sus operaciones fueron realizas utilizando la herramienta XPower de Xilinx. Xpower es

una herramienta que permite analizar el consumo total de energía de un dispositivo

utilizando el código HDL, en este caso por V H D L y un set de estímulos para producir

análisis de consumo de potencia estática y dinámica [12].

Debido a que la herramienta XPower de xilinx es una herramienta de análisis para

dispositivos implementados sobre un FPGA, se realizo una síntesis del modulo M A C

48

sobre una Spartan3E para realizar este análisis. Es muy importante considerar que el

propósito de la implementación del modulo M A C es planeado para ser implementado

sobre un ASIC, sin embargo un análisis del consumo de energía sobre un FPGA puede

ser utilizado como un punto de comparación, tomando en cuenta que el consumo de

energía sobre un ASIC debe ser menor.

Con el propósito de obtener un análisis del consumo de potencia dinámica

producido por el modulo M A C se genero un set de estímulos para las entradas del

modulo de 10 muestras. E l set de estímulos se encuentra en formato V C D y fue

generado utilizando la herramienta ModelSim de Mentor Graphics. La serie de

comandos utilizados para generar el set se encuentra en el apéndice 12.

Tabla 5.2 - Resultados de consumo de energía obtenidos por XPower de Xilinx

Voltaje Corriente (raA) Potencia (mW)

Vcclnt 1.2

Dinámica 2.65 3.81

Estática 66.58 79.90

Consumo Total 83.08

Como se puede observar en la Tabla 5.2 se obtiene un consumo total de energía de

82.85mW al realizar 10 operaciones de lectura y escritura, sin embargo para poder

obtener el consumo de energía total consumido al ejecutar todas las operaciones

realizadas en el programa gsm_hr es necesario seguir el siguiente procedimiento.

Suponiendo que el consumo de energía estático permanece constante durante la

ejecución de las operaciones, se multiplica el consumo de energía dinámico por el

número de operaciones realizadas durante la ejecución de todo el programa. Debido a

que las mediciones fueron realizadas para un Set de 10 operaciones se divide el número

49

de operaciones totales entre 10 para obtener el número por el que se debe multiplicar la

potencia dinámica obtenida.

152504/10 = 15250

15250x3.81 = 58102

Posteriormente sumamos la potencia dinámica y estática para obtener el consumo

total de energía consumida por el modulo al realizar las operaciones.

Potencia total del modulo = 58102 + 79.90 = 58191.90

La potencia total consumida es la suma de la potencia consumida por el

procesador (ver Tabla 5.2) y la potencia consumida por el modulo M A C al realizar

todas las operaciones necesarias en el programa gsm_hr.

Potencia total consumida = 58191.90 + 156394 = 214585.90

Finalmente observamos que el consumo de energía consumida es mayor a la

energía ahorrada por el procesador. Se obtiene una perdida en el ahorro de energía al

ejecutar el programa gsm_hr utilizando el modulo M A C .

Potencia total ahorrada por el procesador = 166854- 156394 = 10460

Diferencia de Potencia total Consumida = 166854— 214586 = —47732

Es importante mencionar que estas mediciones son realizadas en un FPGA y no

sobre un ASIC, en [15] se menciona que el consumo de energía en un FPGA es 20

veces mayor al de un ASIC, partiendo de esta relación el consumo de energía se obtiene

con la siguiente ecuación:

50

Potencia total consumida = 2909.6 + 156394 = 159303.6

Diferencia de Potencia total Consumida =

166854- 159303.6 = 7550.4

Tomando en cuenta esta relación se obtiene un ahorro de energía de 7550.4mw en

la energía total utilizada entre el procesador y el modulo M A C .

Utilizando el simulador ModelSim integrado en Seamless se analizaron los

diagramas de tiempo de la comunicación entre el procesador y el modulo M A C . Los

resultados obtenidos de este experimento se muestran en la Tabla 5.4.

En la Tabla 5.4 observamos que el tiempo mayor se encuentra en la escritura del

primer dato. Sin embargo durante este tiempo, el procesador realiza las operaciones para

acomodar los operandos de multiplicación para ser enviados al modulo, operaciones

secundarias del procesador y el envió del primer dato. Observando la escritura del

segundo dato y el resultado final podemos deducir que los ciclos de reloj utilizados por

el procesador para realizar las operaciones extras es de 10.5 ciclos ya que durante el

tiempo de escritura del segundo dato y lectura del resultado del modulo M A C no se

realiza ninguna operación extra. En la etapa final de la función, el procesador realiza la

lectura del modulo M A C y regresa el resultado de la función, observamos cómo este

tiempo es el menor con respecto a los anteriores.

51

Consumo de energía del Modulo MAC enASIC = = 2909.56

Tabla 5.3 - Tiempo de ejecución y ciclos de operación del modulo M A C

Operación Tiempo (ns)

Tiempo entre

operaciones

Ciclos de C P U

de operación

Inicio de función 5480

Primer Dato 6220 740 18.5

Segundo Dato 6540 320 8

Resultado 6860 320 8

Final de función 7040 180 4.5

Con esto obtenemos que se requieren 8 ciclos de reloj para realizar las

operaciones de escritura y lectura del modulo M A C . Este tiempo se debe a que estas

operaciones se están realizando mediante escrituras y lecturas de memoria. Sin embargo

el modulo M A C es capaz de responder a frecuencias más altas y entregar resultados más

satisfactorios en desempeño y energía consumida por el procesador.

Realizando la siguiente operación es posible saber el tiempo total utilizado por el

bus para realizar las operaciones de lectura y escritura al modulo M A C .

Tiempo total de comunicación del modulo MAC =

(((8 + 8 + 8) * 40ns) x 152504) = 146403840ns

Con esta información sabemos que 146403 840ns es el factor de tiempo que es

posible optimizar utilizando un bus de alta velocidad como medio de comunicación

entre el modulo M A C y el procesador. Optimizando este factor de tiempo es posible

realizar una mayor optimización en el tiempo de ejecución del programa gsmhr

52

utilizando el modulo M A C e incrementar el consumo de energía ahorrado por el

procesador.

Realizando un análisis de los accesos a memoria del programa gsmhr y el tiempo

utilizado en el bus, se obtuvieron los siguientes resultados:

Tabla 5.4 - Accesos de memoria y tiempo de utilización del bus

accesos de memoria Tiempo utilizado en el bus

Sin modulo 900417 216100080ns

Modulo M A C 457512 146403840ns

Accesos procesador 900436 216104640ns

Con modulo 1357948 362508480ns

Para obtener los accesos de memoria durante todo el programa se utilizo la

herramienta performance profiler de Seamless, y utilizando el Modelsim integrado con

Seamless se analizo los ciclos utilizados para hacer escrituras y lecturas en memoria, y

se obtuvo como resultado que los ciclos utilizados para escribir y leer datos de memoria

(Load y Store) es de 6 ciclos, sin embargo para escribir datos al modulo M A C son

necesarios 8 ciclos de reloj. Con esta información se realizo el siguiente cálculo para

obtener los tiempos de utilización de bus mostrados en la Tabla anterior.

Tiempo de bus = Numero de accesos x ciclos de reloj x tiempo de ciclo

Con esta información obtenemos que el porcentaje utilización del bus a lo largo de

el programa gsm_hr es de 18.95 % cuando no es utilizado el modulo M A C y de un

32.93 % cuando se utiliza el modulo M A C . Con esto obtenemos que una optimización

utilizando un bus más rápido es decir que requiera menos ciclos de reloj para realizar

una escritura y una lectura de memoria lograra una mejora en estos porcentajes

obteniendo una mayor velocidad de procesamiento y un menor consumo de energía en

53

la Figuras 5.5 se observa la partición de tiempo utilizado en el procesamiento del

procesador y tiempo en el bus en el programa gsm_hr sin utilizar el modulo M A C y en

la figura 5.6 se observa las particiones de tiempo utilizado en procesamiento, bus y

Procesamiento del modulo M A C en el programa gsm_hr.

Figura 5.5 - Particiones de tiempo del programa gsm_hr

Figura 5.6 - Particiones de tiempo del programa gsm_hr utilizando el modulo M A C

54

Como se puede observar en Figura 5.6 el tiempo utilizado para el procesamiento

del modulo M A C es mucho menor comparado al tiempo utilizado en el bus por lo que sí

es posible disminuir el tiempo de utilización de este, será posible alcanzar una mejora

considerable en el tiempo de ejecución.

Conclusiones 6.1 Conclusiones

Este trabajo de investigación entregó como resultados una arquitectura funcional

para la implementación en hardware de la función L_mac utilizada en el programa

gsmhr desarrollado por el ETSI [4] en el cual se implementa en software el algoritmo

de codificación de G S M half-rate. Esta arquitectura fue desarrollada mediante técnicas

de codiseño y el análisis de diversas arquitecturas y métodos para la implementación de

las funciones en hardware. La evaluación de estas arquitecturas se realizo en base a

algunas métricas importantes tales como el consumo de energía, frecuencias de

operación y área ocupada para su implementación. De igual forma en el presente trabajo

se propuso una arquitectura para la interconexión de este modulo con el

microprocesador utilizando el bus A M B A . Utilizando estas arquitecturas es posible

obtener ahorro en el consumo de energía del procesador de un 6.27% y una mejora en el

desempeño reduciendo el tiempo de ejecución en un 3.45%. Sin embargo este ahorro es

muy pobre debido a que el módulo implementado tiene un consumo del 34.87 % de la

energía del procesador. Con esto se demuestra que se obtuvo una mejora en el tiempo de

ejecución pero una pérdida del 28.6% en el consumo de energía.

Sin embargo como se menciono en el capítulo 5 las mediciones del consumo de

energía fueron realizadas sobre la implementación de este módulo en un FPGA por lo

cual al ser implementadas sobre un ASIC éste consumo deberá ser menor.

55

6.2 trabajo a futuro

La arquitectura propuesta del modulo M A C presenta resultados funcionales y

una pequeña mejora de desempeño en la velocidad de ejecución sin embargo presenta

una fuerte perdida en el consumo de energía del modulo M A C . Sin embargo

observamos que el tiempo de consumido por la lectura y escritura al bus A M B A es muy

alto (320ns / 8 ciclos de reloj), y el tiempo consumido por este representa el 13.3% del

tiempo total del programa. Por lo tanto si se realiza una optimización utilizando un bus

de alta velocidad se podrían obtener mejores resultados. Por lo tanto propongo como

trabajo a futuro una implementación del modulo M A C utilizando un bus de alta

velocidad con la finalidad de aumentar la velocidad de ejecución y aumentar la energía

ahorrada por el procesador.

Las mediciones de energía consumida por el modulo M A C fueron

implementando la arquitectura del modulo sobre un FPGA, por lo tanto propongo como

trabajo a futuro la implementación de esta arquitectura en un ASIC con la finalidad de

realizar una medición más exacta del consumo de energía de este modulo y obtener un

mayor beneficio en el consumo de energía.

El algoritmo implementado en el modulo M A C para realizar la función de

multiplicación es el algoritmo de booth, este algoritmo funciona correctamente sin

embargo, en un estudio realizado en [13] se presento un análisis del algoritmo Baugh-

Wooley para realizar la operación de multiplicación. Este algoritmo presenta un mejor

rendimiento y una menor consumo de energía por lo tanto como trabajo a futuro se

propone la implementación de este algoritmo para hacer nuevas pruebas de desempeño.

Finalmente, como la utilización de del modulo M A C significo una pequeña

mejora en el desempeño del programa gsmhr desarrollado por el ETSI y se obtuvo

igualmente un pequeño ahorro de la energía consumida en el programa. Durante la el

estudio del algoritmo VSELP se observo que la etapa de mayor procesamiento es "open

56

lag loop search", sin embargo debido a que VSELP es una variación del CELP estos

algortimos también poseen una etapa simular a esta, dentro de estos se encuentra el

algoritmo de A C E L P el cual es utilizado como algoritmo de compresión y

descompresión de voz en G S M A M R el cual se utiliza en las nuevas generaciones de

teléfonos celulares. Por esta razón propongo como trabajo a futuro implementar el

modulo M A C en estos algoritmos para realizar nuevas pruebas de desempeño.

57

Apéndice A

Código modificados para simulación del programa gsm_

extraído del ETSI

A.l Makefile

#project output f i l e #PROJECT=memtest3_p2 PROJECT=gsm_hr

# GNU-ARM t o o l s d i r e c t o r y GNU_ARM = /home/shared/CodeSourcery/SourceryARM/bin

CC=$(GNU_ARM)/arm-none-eabi-gcc ASM=$(GNU_ARM)/arm-none-eabi-as OBJCOPY=$(GNU_ARM)/arm-none-eabi-objcopy LDSCRIPT=standalone.Id

# should use --gc-sections but the debugger does not seem to be able to cope with the opt i o n . LINKER_FLAGS=-nostartfiles - X l i n k e r -o$(PROJECT).elf - X l i n k e r -M -X l i n k e r -Map=$(PROJECT).map DEBUG=#-g 0PTIM=-03

#CFLAGS=$(DEBUG) - I . -D i n l i n e = -mcpu=arm926ej-s $(OPTIM) -T$(LDSCRIPT) CFLAGS=$(DEBUG) - I . -mcpu=arm9tdmi $(OPTIM) -T$(LDSCRIPT)

#C and Asm sources SRC= mathdp31.c mathhalf.c vad.c globdefs.c sp_rom.c err_conc.c dtx. homing.c sp_dec.c sp_enc.c sp_frm.c sp_sfrm.c host.c gsm_hr.c ASRC=startup.s LIBS= #typedefs.h mathdp31.h mathhalf.h err_conc.h homing.h sp_dec.h sp_enc.h sp_frm.h sp_rom.h sp_sfrm.h vad.h host.h gsm_hr.h dtx.h ##LIBS= #/home/Shared/toolchains/arm-2007q3/lib/gcc/arm-none-linux-gnueabi/4.2.1/include/stdio. h #LIBS= $(LUMINARY_DRIVER_DIR)/arm-none-eabi-gcc/libdriver.a $(LUMINARY_DRIVER_DIR)/arm-none-eabi-gcc/libgr.a

OBJS = $(ASRC:.s=.o) $(SRC:.c=.o)

a l l : $(OBJS) $(PROJECT).elf

%o : %c Ma k e f i l e $(CC) -c $(CFLAGS) -gdwarf-2 $< -o $@

%o : %s Ma k e f i l e $(ASM) -g -gdwarf2 $< -o $@

58

% e l f : $(OBJS) M a k e f i l e $(CC) $(CFLAGS) $(OBJS) $(LIBS) $(LINKER_FLAGS)

clea n : touch M a k e f i l e rm - f $(OBJS) rm - f $(PROJECT).elf rm - f $(PROJECT).map

A.2 Pasos para comprobar el funcionamiento del programa

gsm_hr

Se introduce el archivo SHORT.INP al programa gsmhr para hacer la

codificación:

gsm_hr ene ..\d\shortinp ..\d\shorttst.cod nodtx

La salida generada es introducida al programa REID:

reid..\d\shorttstcod..\d\shorttst.dec EPO La salida generada es introducida nuevamente al programa gsmhr para hacer la

decodificación:

gsm_hr dec.. \d\shorttstdec..\d\shorttst.out nodtx

Una vez realizada la decodificación se realiza una comprobación para ver

si los datos de salida son correctos

comp shortísteod shortcod

comp shorttstdec shortdec

comp shorttst.out short.out Esta comprobación debe arrojar como resultado que no existe ninguna diferencia

entre estos archivos.

59

A.3 Modificación de la sección de código HostEncoderlnterface

;********************************************************************̂ ^

* FUNCTION ÑAME: hostEncoderlnterfaceMem

* PURPOSE:

* Read in speech data from a file. Zero the least significant 3 bits.

* INPUTS:

* pfilelnSpeech * FILE pointer to the binary input file

* iNumToRead * Number of samples to read from the file, typically * 160 (20 msof speech).

* OUTPUTS:

* pswSamplesRead[] * The speech samples read in from the file.

* RETURN VALUE:

* iNumRead

* The number of samples actually read.

* IMPLEMENTATION:

* The input speech file should be in "native" format. This means that * the file is to be read (by this program) and written (by another * program) as short ints (not chars). * If not enough samples are available in the file, the number actually * read is returned. If the read fails to fill the requested iNumToRead * samples, then the rest are zeroed.

* In all cases the least significant 3 bits of all speech samples are

* zeroed.

* REFERENCES: Sub-clause 4.1 of GSM Recomendation 06.20

* KEYWORDS: read, read speech, get speech data ************************************************** int hostEncoderInterfaceMem(Shortword pmemInSpeech[], int iNumToRead,

Shortword pswSamplesReadf]) {

60

61

/* I I | Automatic Variables | I I

*/ int iNumRead,

i; static int j = 1;

/* I I | Executable Code | I I */

// iNumRead = fread((char *) pswSamplesRead, sizeof (Shortword), // iNumToRead, pfdelnSpeech);

for (i = 0; i < iNumToRead; i++) { pswSamplesRead[i] = pmemInSpeech[i];

}

for (i = 0; i < iNumToRead; i++) { pswSamplesRead[i] = pmemlnSpeechfi + (j-l)*iNumToRead];

}

//memcpy(&pswSamplesRead[0], &pmemInSpeech[0]+(j*iNumToRead), iNumToRead*2); j + + ; iNumRead = iNumToRead;

/* Delete the 3 LSB's - 13 bit speech input */ /* */

for (i = 0; i < iNumRead; i++) { pswSamplesRead[i] &= OxfffB;

}

/* Fill out the iNumToRead buffer with zeroes */ /* */

if (iNumRead != iNumToRead) { for (i = iNumRead; i < iNumToRead; i++) { pswSamplesRead[i] = 0;

} } return (iNumRead);

}

A.4 Modificación de la sección de código WriteEncfile

* * FUNCTION ÑAME: writeEncfileMem * * PURPOSE: * Writes encoded parameters to ouput fde * * INPUT: * pswSpeechPara array of encoded parameter words. * * OUTPUT: * fpfileEnc 16-bit encoded valúes. * * RETURN: * i number ofbytes written * * REFERENCES: Sub-clause 4.1 of GSM Recomendation 06.20

* KE Y WORDS: pswSpeechPara, fpfileEnc

*/

//int writeEncfile(Shortword pswSpeechPara[], FILE *fpfileEnc) int writeEncfileMem(Shortword pswSpeechPara[], Shortword pmemEnc[]) { //int i; static int 1 = 1; int i = 20; int k = 0; Shortword Prueba;

//i = fwrite((char *) pswSpeechPara, sizeof (Shortword), 20, fpfileEnc); for (k=0; k<20 ;k++) {

pmemEncfk + (1-1)*20] = pswSpeechParafk]; Prueba = pmemEncfk];

}

// memcpy(&pmemEnc[0], &pswSpeechPara[0] + 1*20, 20*2);

1++;

return (k); }

62

A.5 Modificación de la sección de código de la función encode y * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* FUNCTION ÑAME: encodeMem MODIFICACION PARA LEER Y ESCRIBIR DE MEMORIA

* PURPOSE: * Reads in one frame of speech samples and outputs one frame of * speech parameters. Resets the encoder to the home state if the * Encoder Homing Frame partera is detected.

* INPUT: * pfileSpeechln speech file * * OUTPUT: * pfíleEnc speech, encoded paramater data * * RETURN: * 0 successfully wrote a complete frame of data * 1 failed to write a complete frame of data * * REFERENCES: Sub-clause 4.1 of GSM Recomendation 06.20

* KEYWORDS: * pfileSpeechln, pfíleEnc ********************************************

int encodeMem(Shortword pmemSpeechIn[], Shortword pmemEnc[]) {

/* I I | Static Variables | I I */ static Shortword pswSpeechPara[20]; static Shortword pswSpeechBufíIFLEN];

/* | Automatic Variables | I I */ int iNumRead,

resetflag;

/* | Executable Code | I I

*/

//iNumRead = hostEncoderInterface(pfileSpeechIn, FLEN, &pswSpeechBuffT0]); iNumRead = hostEncoderInterfaceMem(&pmemSpeechIn[0], FLEN, &pswSpeechBufflO]);

if (iNumRead < FLEN) return (1);

63

resetflag = encoderHomingFrameTest(&pswSpeechBuffIO]);

speechEncoder(&pswSpeechBuff[0], pswSpeechPara);

if (writeEncfileMem(pswSpeechPara, pmemEnc) != 20) return (1);

if (reset_flag) resetEnc(); /* Bring the encoder, VAD, and DTX to

* the home state */ return (0);

}

A.6 Modificación de la sección de código de la función Main

int main() { /* I I | Local Constants | I I

*/ #define DEFAULTNUMFRAMES 32766 /* I I | Automatic Variables | I I

*/ int iDoneFrm,

iDoneFrmTest, iMaxNumFrms, option, i;

static Shortword pmemInMem[1600]; static Shortword pmemOutMem[1600];

//definir variables de prueba 1: static Shortword pswPrueba[1600]; static Shortword pswPrueba2[1600];

int iNumRead; int s;

/* I I | Executable Code | I I

*/

64

Shortword x = 0x00000D02; Shortword z = OxOOOOFEDE; Longword m = 0x00010D02; Longword *y = 0xFFFF8000; Longword *c = 0xFFFF8004; Longword *a = 0xFFFF8008; Longword d =0xFFFF8008; Longword e =0xEEEE8008;

d = L_mac(m,x,z);

/* check command line arguments */ /* */

iMaxNumFrms = DEFAULT_NUMFRAMES; s = Fill_Mem(&pswPrueba2[0]);

giDTXon = 0; option = 0;

/* start the encoder, VAD, and transmit DTX in the home state */ I* •/

for (giFrmCnt = 1, iDoneFrm = 0; üDoneFrm && giFrmCnt <= iMaxNumFrms; giFrmCnt++)

//aqui empieza el for 2 { if (encodeMem(&pswPrueba2[0], &pmemOutMem[0]))

iDoneFrm = 1; if(giFrmCnt==2)

iDoneFrm = 1; }

//aqui acaba el for if (iDoneFrm) giFrmCnt-; return (0);

}

65

A.7 Sección de código de la función Fill_Mem z*********************************************************************̂ ^ * * FUNCTION ÑAME: Fill_Mem MODIFICACION PARA LEER Y ESCRIBIR DE MEMORIA * * PURPOSE: * llenar la memoria con los datos a leer *

* * INPUT: * pswPrueba2 speech fue * * OUTPUT: * pswPrueba2 speech, encoded paramater data

* RETURN: * 0 successfully wrote a complete frame of data * 1 failed to write a complete frame of data * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * int Fill_Mem(Shortword Prueba2[]) {

/* I I | Executable Code | I I

*/ Prueba2[0] = 52; Prueba2[l] =-104; Prueba2[2] = -280; Prueba2[3] = -502; Prueba2[4] = -782; Prueba2[5] = -1039; Prueba2[6] = -1205; Prueba2[7] = -1052; Prueba2[8] = -644; Prueba2[9] = -370; Prueba2[10] = -309; Prueba2[ll] = -317; Prueba2[12] = -277;1

Prueba2[13] = -52; Prueba2[14] = 303; Prueba2[15] = 71I; Prueba2[16] = 1044; Prueba2[17] = 1191; Prueba2[18]= 1298; Prueba2[19] = 1294; Prueba2[20] = 1184; Prueba2[21]= 1032; Prueba2[22] = 727; Prueba2[23] = 372;

66

Prueba2[24] = 20; Prueba2[25] = -254; Prueba2[26] = -388; Prueba2[27] = -473; Prueba2[28] = -512; Prueba2t29] = -617; Prueba2[30] = -81l; Prueba2[31] = -926; Prueba2[32] = -934; Prueba2[33] = -852; Prueba2[34] = -692; Prueba2[35] = -511; Prueba2[36] = -303; Prueba2[37] = -6; Prueba2[38] = 268; Prueba2[39] = 403; Prueba2[40] = 479; Prueba2[41] = 525; Prueba2[42] = 574; Prueba2[43] = 596; Prueba2[44] = 569; Prueba2[45] = 592; Prueba2[46] = 571; Prueba2[47] = 417; Prueba2[48] = 265; Prueba2[49]= 137; Prueba2[50] = -88; Prueba2[51] = -345; Prueba2[52] = -599; Prueba2[53] = -840; Prueba2[54] = -1081; Prueba2[55] = -1359; Prueba2[56] = -1278; Prueba2[57] = -782; Prueba2[58] = -503; Prueba2[59] = -537; Prueba2[60] = -450; Prueba2[61] = -301; Prueba2t62]=-80; Prueba2[63] = 451; Prueba2t64] = 958; Prueba2[65] = 1250; Prueba2[66] = 1518; Prueba2[67] = 1665; Prueba2I68] = 1579; Prueba2[69]= 1332; Prueba2[70] = 1016; Prueba2[71] = 688; Prueba2t72] = 322; Prueba2[73J = -14; Prueba2[74] = -249; Prueba2[75] = -463; Prueba2[76] = -625; Prueba2[77] = -674; Prueba2[78] = -751; Prueba2[79] = -884;

67

Prueba2[80] = -976; Prueba2[81] = -985; Prueba2[82] = -900; Prueba2[83]=-759; Prueba2[84] = -546; Prueba2[85] = -307; Prueba2[86] = -66; Prueba2[87] = 219; Prueba2[88] = 432; Prueba2[89] = 536; Prueba2[90] = 638; Prueba2[91] = 652; Prueba2[92] = 604; Prueba2[93] = 680; Prueba2[94] = 748; Prueba2[95] = 687; Prueba2[96] = 522; Prueba2[97] = 275; Prueba2[98] = 12; Prueba2[99] = -315; Prueba2[100] = -646; Prueba2[101] = -873; Prueba2[102] = -1140 Prueba2[103] = -1416 Prueba2[104] = -1443 Prueba2[105] = -1078: Prueba2[106] =-557; Prueba2[107] =-361; Prueba2[108] = -364; Prueba2[109] = -346; Prueba2[110] = -273; Prueba2[lll]= 162; Prueba2[112] = 849; Prueba2[113] = 1397; Prueba2[114] = 1739; Prueba2[115] = 1812; Prueba2[116]= 1614; Prueba2[117] = 1362; Prueba2[118] = 1078; Prueba2[119] = 761; Prueba2[120] = 450; Prueba2[121] = 70; Prueba2[122] = -298; Prueba2[123] = -539; Prueba2[124] = -673; Prueba2[125] = -719; Prueba2[126] = -761; Prueba2[127] = -897; Prueba2[128] = -964; Prueba2[129] =-929; Prueba2[130] = -879; Prueba2[131] = -689; Prueba2[132] = -501; Prueba2[133] = -359; Prueba2[134] = -99; Prueba2[135] = 145;

68

Prueba2[136] = 368; Prueba2[137] = 555; Prueba2[138] = 608; Prueba2[139] = 602; Prueba2[140] = 584; Prueba2[141] = 666; Prueba2[142] = 820; Prueba2[143] = 741; Prueba2[144] = 462; Prueba2[145] = 238; Prueba2[146] = -39; Prueba2[147] = -355; Prueba2[148] = -618; Prueba2[149] = -906; Prueba2[150] = -1237: Prueba2[151] = -1557; Prueba2[152] = -1495: Prueba2[153] = -944; Prueba2[154] = -453; Prueba2[155] = -318; Prueba2[156] = -364; Prueba2[157] = -404; Prueba2[158] = -259; Prueba2[159] = 260; Prueba2[160] = 973; Prueba2[161] = 1496; Prueba2[162] = 1787; Prueba2[163] = 1854; Prueba2[164] = 1631; Prueba2[165] = 1316; Prueba2[166] = 999; Prueba2[167] = 675; Prueba2[168] = 401; Prueba2[169] = 91; Prueba2[170] = -225; Prueba2[171] = -465; Prueba2[172] = -651; Prueba2[173] = -742; Prueba2[174] = -809; Prueba2[175] = -925; Prueba2[176] = -971; Prueba2[177] = -954; Prueba2[178] = -883; Prueba2[179] = -719; Prueba2[180] = -535; Prueba2[181] = -312; Prueba2[182] = -62; Prueba2[183] = 171; Prueba2[184] = 369; Prueba2[185] = 519; Prueba2[186] = 594; Prueba2[187] = 566; Prueba2[188] = 574; Prueba2[189] = 702; Prueba2[190] = 769; Prueba2[191] = 625;

69

Prueba2[192] = 422; Prueba2[193] = 196; Prueba2[194] =-125; Prueba2[195] = -399; Prueba2[196] = -656; Prueba2[197] = -953; Prueba2[198] = -1263; Prueba2[199] = -1525; Prueba2[200] = -1388; Prueba2[201] = -776; Prueba2[202] = -271; Prueba2[203] = -228; Prueba2[204] = -356; Prueba2[205] = -414; Prueba2[206] = -204; Prueba2[207] = 400; Prueba2[208] = 1109; Prueba2[209] = 1646; Prueba2[210] = 1914; Prueba2[211]= 1849; Prueba2[212] = 1510; Prueba2[213] = 1106; Prueba2[214] = 786; Prueba2[215] = 546; Prueba2[216] = 298; Prueba2[217] = -22; Prueba2[218] = -317; Prueba2[219] = -551; Prueba2[220] = -695; Prueba2[221] =-723; Prueba2[222] = -820; Prueba2[223] = -947; Prueba2[224] = -987; Prueba2[225] = -995; Prueba2[226] = -872; Prueba2[227] = -597; Prueba2[228] = -333; Prueba2[229] = -122; Prueba2[230] = 88; Prueba2[231] = 267; Prueba2[232] = 416; Prueba2[233] = 551; Prueba2[234] = 601; Prueba2[235] = 604; Prueba2[236] = 653; Prueba2[237] =719; Prueba2[238] = 664; Prueba2[239] = 465; Prueba2[240] = 251; Prueba2[241] =41; Prueba2[242] = -228; Prueba2[243] = -560; Prueba2[244] = -860; Prueba2[245] = -1092; Prueba2[246] =-1352; Prueba2[247] = -1498;

70

Prueba2[248] = -1243; Prueba2[249] = -698; Prueba2[250] = -261; Prueba2[251] = -98; Prueba2[252] = -168; Prueba2[253] = -252; Prueba2[254] = 41; Prueba2[255] = 671; Prueba2[256]= 1312; Prueba2[257] = 1822; Prueba2[258] = 1979; Prueba2[259] = 1737; Prueba2[260] = 1357; Prueba2[261] = 903; Prueba2[262] = 518; Prueba2[263] = 337; Prueba2[264] = 150; Prueba2[265] = -119; Prueba2[266] = -384; Prueba2[267] = -605; Prueba2[268] = -731; Prueba2[269] = -787; Prueba2[270] = -861; Prueba2[271] = -928; Prueba2[272] = -964; Prueba2[273] = -923; Prueba2[274] = -719; Prueba2[275] = -464; Prueba2[276] = -214; Prueba2[277] = 28; Prueba2[278] = 199; Prueba2[279] = 316; Prueba2[280] = 433; Prueba2[281] = 564; Prueba2[282] = 634; Prueba2[283] = 637; Prueba2[284] = 674; Prueba2[285] = 696; Prueba2[286] = 540; Prueba2[287] = 320; Prueba2[288] = 145; Prueba2[289] = -136; Prueba2[290] = -441; Prueba2[291] = -681; Prueba2[292] = -917; Prueba2[293] = -1162; Prueba2[294] = -1479; Prueba2[295] = -1600; Prueba2[296] = -1116; Prueba2[297] = -369; Prueba2[298] = 37; Prueba2[299] = 98; Prueba2[300] = -98; Prueba2[301] = -248; Prueba2[302] = 107; Prueba2[303] = 772;

71

Apéndice B

Códigos en VHDL para implementación del modulo MAC e

interconeccion del modulo MAC con el microprocesador

B.3 Código en VHDL para la implementación del Modulo MAC

~ Company: ~ Engineer:

-- Créate Date: 16:12:22 09/23/2009 -- Design Ñame: ~ Module Ñame: mac - Behavioral ~ Project Ñame: ~ Target Devices: -- Tool versions: ~ Description:

~ Dependencies:

~ Revisión: ~ Revisión 0.01 - File Created — Additional Comments:

72

Prueba2[304] = 1449; Prueba2[305] = 1948; Prueba2[306] =2001; Prueba2[307] = 1709; Prueba2[308] = 1258; Prueba2[309] = 707; Prueba2[310] = 345; Prueba2[311] = 216; Prueba2[312] = 63; Prueba2[313] = -130; Prueba2[314] = -384; Prueba2[315] = -665; Prueba2[316] = -800; Prueba2[317] = -854; Prueba2[318] = -916; Prueba2[319] = -944;

return (0); }

73

—package

library work; use work.all;

library IEEE; use IEEE.STDLOGICJ 164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

— Uncomment the following library declaration if instantiating — any Xilinx primitives in this code. «library UNISIM; -use UNISIM.VComponents.au;

package mac_pkg is

component mac is Port(

data: inout std_logic_vector(31 downto 0); address: in std_logic_vector(l downto 0); Registro 1: out std_logic_vector(15 downto 0); Registro2: out std_logic_vector(15 downto 0); Registro3: out std_logic_vector(31 downto 0); Registro4: out std_logic_vector(31 downto 0); Mul32: out std_logic_vector(31 downto 0); Sum32: out std_logic_vector(31 downto 0); clk: in stdlogic; CE: in stdlogic; RE: in stdlogic); WE: in stdlogic);

end component;

end mac_pkg;

library work; use work.all;

library IEEE; use IEEE.STD_LOGIC_l 164.ALL; use ieee.numeric_std.all; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

use work.mac_pkg.all; —use work.functions_pkg.all;

— Uncomment the following library declaration if instantiating

http://IEEE.STD_LOGIC_UNSIGNED.ALL

http://UNISIM.VComponents.au

http://ieee.numeric_std.all

http://IEEE.STD_LOGIC_ARITH.ALL

http://IEEE.STD_LOGIC_UNSIGNED.ALL

http://work.mac_pkg.all

http://work.functions_pkg.all

— any Xilinx primitives in this code. -library UNISIM; -use UNISIM.VComponents.all;

entity mac is Port( data: inout std_logic_vector(31 downto 0); address: in stdlogic_vector(l downto 0); Registro 1: out std_logic_vector(15 downto 0); Registro2: out std_logic_vector(15 downto 0); Registro3: out std_logic_vector(31 downto 0); Registro4: out std_logic_vector(31 downto 0); Mul32: out std_logic_vector(31 downto 0); Sum32: out std_logic_vector(31 downto 0); clk: in stdlogic; CE: in std_logic; RE: in stdlogic);

end mac;

architecture Behavioral of mac is

signal Enable : stdjogic; -- seÁ±ales primera etapa — pre pipeline signal vari : std_logic_vector(15 downto 0); signal var2 : std_logic_vector(15 downto 0); signal var3 : std_logic_vector(31 downto 0); -- seÁ±ales segunda etapa — post pipiline 1 signal in_varl : std_logic_vector(15 downto 0); signal in_var2 : std_logic_vector(15 downto 0); signal in_var3 : std_logic_vector(31 downto 0); signal in_var4 : std_logic_vector(31 downto 0);

signal inresult: std_logic_vector(31 downto 0); signal in2_result: std_logic_vector(31 downto 0); signal in3_result: std_logic_vector(31 downto 0); signal in4_result: std_logic_vector(31 downto 0);

-- sumaaaaa aaaahhhhh signal overflow : stdlogic; signal carry_out: std_logic; signal result: std_logic_vector(31 downto 0):=x"00000000"; signal sum : std_logic_vector(31 downto 0);

74

SIGNAL h_sum : STD_LOGIC_VECTOR(31 DOWNTO 0); SIGNAL carry_generate : STD_LOGIC_VECTOR(31 DOWNTO 0); SIGNAL carry_propagate : STD_LOGIC_VECTOR(31 DOWNTO 0); SIGNAL carry_in_internal : STD_LOGIC_VECTOR(31 DOWNTO 1); signal carry_in : STD_LOGIC;

multiplicacionnnnn aaaahhhh

signal resuIt_Mult: std_Iogic_vector(31 downto 0):=x" 10000000"; signal result_Mult2 : std_logic_vector(31 downto 0):=x" 10000000";

signal sum32_mod : std_logic_vector(32 downto 0):= "000000000000000000000000000000000" ; signal sum32_fínal: std_logic_vector(31 downto 0):=x"00000000";

begin

Enable <= C E ; - W E or C E ;

-- L O G I C A D E H A B I L I T A C I O N DE DIRECCIONES

vari <= data(31 downto 16) when address = "00" and Enable = '0' else x"0000";

Registro 1 <= i n v a r l ;

var2 <= data(15 downto 0) when address = "00" and Enable = '0' else x"0000";

Registro2 <= in_var2;

var3 <= data(31 downto 0) when address = "01" and Enable = '0' else x"00000000";


data <= in3_result when address = "10" and RE = '0' else (others => 'Z');

F F 1 6 1 : process(clk) begin

if(clk'event and clk = '0')then if(Enable = '0')then

i n v a r l <= vari; end if;

end if; end process;

FF16_2: process(clk) begin

if(clk'event and clk = '0')then if (Enable = '0')then

in_var2 <= var2; end if;


FF32_1: process(clk) begin


in_var3 <= var3; end if;

end if;

75

end process;

-- OPERACION 1 - MULTIPLICACION

process(in_varl, in_var2)

variable C: std_logic_vector(16 downto 0):=(others=>'0'); variable CF: std_logic_vector(2*16 downto 0); variable x,T: std_logic;

variable DataA: std_logic_vector(16 downto 0);

begin

ifin_varl(16-l)=Tthen DataA:-l'&invarl;

else DataA:='0'&in_varl;

end if; x:='0'; T:='0'; CF:=C&in_var2;

for i in 1 to 16 loop if (CF(0)='0' and x='l') then

CF(2*16 downto 16):= CF(2*16 downto 16)+ DataA;

elsif (CF(0)='l' and x='0') then CF(2*16 downto 16):= CF(2*16 downto 16)-DataA;

end if; T:=CF(2*16); x:=CF(0); CF(2*16 downto 0):=T&CF(2*16 downto 1);

end loop;

resultMult <= CF(2*16-1 downto 0);

end process;

--MULTIPLICACION POR 2 result_Mult2 <= result_Mult(30 downto 0) & '0';

—overfiow inresult <= x"7FFFFFFF" when (invarl = x"8000") and (invarl = x"8000") else

result_Mult2;

- segunda parte de pipeline

Mul32 <= in_result;

76

FF32 3: process(clk) begin


in_var4 <= in_var3; end if;



-- O P E R A C I O N 2 - S U M A

carryin <= '0'; h s u m <= inresult X O R in_var4; carry_generate <= inresult A N D in_var4; carry_propagate <= inresult OR in_var4;

— generar carry

PROCESS (carry_generate,carry_propagate,carry_in_internal)

B E G I N carryininternal(l) <= carrygenerate(O) OR (carry_propagate(0) A N D carryin);

inst: FOR i IN 1 TO 30 LOOP carry_in_internal(i+l) <= carry generate(i) OR

(carry_propagate(i) A N D carry_in_internal(i)); END LOOP;

carry_out <= carrygenerate(31) OR (carry_propagate(31) A N D carry_in_internal(31));

E N D PROCESS;

sum(0) <= hsum(O) X O R carry_in; sum(31 D O W N T O 1) <= h_sum(31 DOWNTO 1) X O R carry_in_internal(31 DOWNTO 1);

—overflow overflow <= not(in_result(31) xor in_var4(31)) and (in_result(31) xor sum(31)); -resultado in3_result <= x"80000000" when (carryout = T ) and ( sum(31) = '0') and (inresult < 0 ) and

(in_var4 < 0 ) else x"7fffffff' when overflow = '1' and (inresult > 0 ) and (in_var4 > 0 ) else

sum;

Sum32 <= in3_result;

sum32_mod <= ('0' & in3_result) + ('0' & x"00008000");

sum32_fínal <= x"0000" & sum32_mod(31 downto 16);

end Behavioral;

77

B.4 Código en VHDL para Interconexión del modulo MAC con

microprocesador

Copyright Mentor Graphics Corporation 2002 All Rights Reserved.

THIS WORK CONTAINS TRADE SECRET AND PROPRIETARY INFORMATION WHICH IS THE

PROPERTY OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS AND IS

SUBJECT TO LICENSE TERMS.

- ARM946E-Srevl Testing

-- Owner: Ahmed S. Badran - SoC VBU - Mentor Graphics Egypt — - Questions/Suggestions: Email me at [email protected] -- Start date: 03-26-2002 --Enddate: - -2002 -- . ~ Filename: testbench.vhd ~ Description: This fue includes the top level design of the —

test bench used for testing the arm926ejs_rev0. ~

library work; use work.arm926ejs_lib.all; use work.sram_pkg.all; use work.screen_pkg.all; use work.ahb_controller_pkg.all; use work.ahb_arbiter_pkg.all; use work.address_decoder_pkg.all; use work.reset_controller_pkg.all; use work.conf_controller_pkg.all; use work.tcm_controller_pkg.all; use work.dma_controller_pkg.all; -use work.io_controller_pkg.all; use work.int_generator_pkg.all; use work.clk_generator_pkg.all; use work.mac_pkg.all;

library ieee; use ieee.std_logic_l 164.all; use ieee.numeric_std.all;

entity ARM926EJS_rev0_tb is generic ( - Timing parameters CLKCYCLETIME : time := 40 ns; INITIALSTARTUPTIME : time := 160 ns;

78

mailto:[email protected]

http://work.sram_pkg.all

http://work.screen_pkg.all

http://work.ahb_controller_pkg.all

http://work.ahb_arbiter_pkg.all

http://work.address_decoder_pkg.all

http://work.reset_controller_pkg.all

http://work.conf_controller_pkg.all

http://work.tcm_controller_pkg.all

http://work.dma_controller_pkg.all

http://work.io_controller_pkg.all

http://work.int_generator_pkg.all

http://work.clk_generator_pkg.all

http://work.mac_pkg.all

http://ieee.numeric_std.all

— Processor setup parameters ENDIANNESS : bit := '0'; - 0 => low, 1 => big

- Memory map parameters MEMORYBASEADDRESS : unsigned (31 downto 0) := X"00000000"; MEMORY_ADDRESS_WIDTH : integer := 16; RESETCONTBASEADDRESS : unsigned (31 downto 0) := X'TFFFFFDO"; RESET CONT_ADDRESS_WIDTH : integer := 4; CONF CONTBASEADDRESS : unsigned (31 downto 0) := X'TFFFFFEO"; CONFCONTADDRESS WIDTH : integer := 4; SCREENBASEADDRESS : unsigned (31 downto 0) := X"FFFF8000"; SCREENADDRESS WIDTH : integer := 4; INTGENBASEADDRESS : unsigned (31 downto 0) := X'TFFFFFFO"; INTGENADDRESSWIDTH : integer := 4

);

end ARM926EJS_revO_tb;

architecture ARM926EJS_revO_tb of ARM926EJS_revO_tb is

- Binding indícation - None is needed, the default is to bind components and entities that have - the same ñames

- Data Bus Signáis.

signal DHADDR : std_logic_vector ( 31 downto 0 ) := (others => 'Z'); signal DHBL : stdlogicvector ( 3 downto 0 ) := (others => 'Z'); signal DHBURST : std_logic_vector (2 downto 0 ) := (others => 'Z'); signal DHBUSREQ : stdjogic := 'Z'; signal DHCLKEN : stdjogic := T; signal DHGRANT : stdjogic; signal DHLOCK : stdjogic := 'Z'; signal DHPROT : stdJogic_vector (3 downto 0 ) := (others => 'Z'); signal DHRDATA : stdlogicvector ( 31 downto 0 ); signal DHREADY : stdjogic; signal DHRESP : stdlogicvector ( 1 downto 0 ); signal DHSIZE : stdJogic_vector (2 downto 0 ) := (others => 'Z'); signal DHTRANS : stdJogic_vector ( 1 downto 0 ) := (others => 'Z'); signal DHWDATA : std logicvector ( 31 downto 0 ) := (others => 'Z'); signal DHWRITE : stdjogic := 'Z'; signal HRESETn : stdlogic;

- Instruction Bus Signáis.

signal IHADDR : stdlogicvector ( 31 downto 0 ) := (others => 'Z'); signal IHBURST : stdjogicvector (2 downto 0 ) := (others => 'Z'); signal IHBUSREQ : stdjogic := 'Z'; signal IHCLKEN : stdjogic := T; signal IHGRANT : stdjogic; signal IHLOCK : stdjogic := 'Z*; signal IHPROT : stdJogic_vector ( 3 downto 0) := (others => 'Z');

79

signal IHREADY : stdjogic; signal IHRDATA : stdJogic_vector ( 31 downto 0 ); signal IHRESP : stdlogicvector ( 1 downto 0 ); signal IHSIZE : stdlogic_vector (2 downto 0 ) := (others => 'Z'); signal IHTRANS : std logic_vector ( 1 downto 0 ) := (others => 'Z'); signal IHWRITE : stdjogic := 'Z';

- AHB Arbiter to AHB memory controller signáis.

signal HADDR : stdJogic_vector (31 downto 0) := (others => 'Z'); signal HBL : std logicvector (3 downto 0) := (others => 'Z'); signal HBUSREQ : stdjogic := 'Z'; signal HBURST : stdJogic_vector (2 downto 0) := (others => 'Z'); signal HLOCK : stdjogic := '0'; signal HPROT : stdlogicvector (3 downto 0) := (others => 'Z'); signal HRDATA : stdJogic_vector (31 downto 0) := (others => 'Z'); signal HREADY : stdjogic := '1'; signal HRESP : std logicvector (1 downto 0) := "ZZ"; signal HSIZE : stdlogicvector (2 downto 0) := "ZZZ"; signal HTRANS : stdlogicvector (1 downto 0) := "ZZ"; signal HWRITE : stdjogic := 'Z'; signal HWDATA : stdJogic_vector (31 downto 0) := (others => 'Z');

-- Coprocessor Signáis - Not Supported

signal CPABORT : stdjogic := 'Z'; signal CPBURST : stdlogicvector (3 downto 0); signal CPCLKEN : stdjogic := 'Z'; signal CPDIN : stdlogicvector ( 31 downto 0 ); signal CPDOUT : stdlogicvector (31 downto 0 ) := (others => 'Z'); signal CPEN : stdjogic; signal CPINSTR : stdJogicvector (31 downto 0 ) := (others => 'Z'); signal CPPASS : stdjogic := 'Z'; signal CPLATECANCEL : stdjogic := 'Z'; signal CHSDE : stdJogic_vector (1 downto 0 ); signal CHSEX : stdJogic_vector ( 1 downto 0 ); signal nCPINSTRVALID : stdjogic := 'Z'; signal nCPMREQ : stdjogic := 'Z'; signal nCPTRANS : stdjogic := 'Z';

— Debug Signáis - Not Supported.

signal COMMRX : stdlogic := 'Z'; signal COMMTX : stdjogic := 'Z'; signal DBGACK : stdjogic := 'Z'; signal DBGDEWPT : stdjogic; signal DBGEN : stdjogic; signal DBGEXT : stdlogic_vector ( 1 downto 0 ); signal DBGIEBKPT : stdjogic; signal DBGINSTREXEC : stdjogic := 'Z'; signal DBGRNG : std logic_vector ( 1 downto 0 ) := (others => 'Z');

80

signal DBGRQI : stdlogic := 'Z'; signal EDBGRQ : stdlogic;

- JTAG Signáis - Not Supported.

signal DBGIR : std_logic_vector ( 3 downto 0 ) := (others => 'Z'); signal DBGnTRST : stdlogic; signal DBGnTDOEN : stdlogic := 'Z'; signal DBGSCREG : std_logic_vector (4 downto 0 ) := (others => 'Z'); signal DBGSDIN : stdjogic := 'Z'; signal DBGSDOUT : stdjogic; signal DBGTAPSM : stdJogic_vector ( 3 downto 0 ) := (others => 'Z'); signal DBGTCKEN : stdjogic; signal DBGTDI : stdjogic; signal DBGTDO : stdjogic := 'Z'; signal DBGTMS : stdjogic;

- Miscellaneous Signáis.

- Supported. signal CLK : std logic; signal CFGBIGEND : stdjogic := 'Z'; signal nFIQ : stdjogic := '1'; signal nIRQ : std logic := '1'; - Not Supported. signal BIGENDINIT : stdjogic; signal EXTEST : std logic; signal INTEST : stdjogic; signal SCANENABLE : stdjogic; signal STANDBYWFI : stdjogic := 'Z'; signal TAPID : stdlogicvector ( 31 downto 0 ); signal TESTMODE : stdjogic;

- ETM Interface Signáis - Not Supported.

signal ETMBIGEND : stdjogic := 'Z'; signal ETMCHSD : stdjogic_vector ( 1 downto 0) := (others => 'Z'); signal ETMCHSE : stdlogicvector ( 1 downto 0 ) := (others => 'Z'); signal ETMDA : stdlogicvector (31 downto 0 ) := (others => 'Z'); signal ETMDABORT : std logic := 'Z'; signal ETMDBGACK : stdjogic := 'Z'; signal ETMDMAS : stdlogicvector ( 1 downto 0 ) := (others => 'Z'); signal ETMDMORE : std logic := 'Z'; signal ETMDnMREQ : std logic := 'Z'; signal ETMDnRW : std logic := 'Z'; signal ETMDSEQ : stdjogic := 'Z'; signal ETMEN : std logic; signal ETMHIVECS : stdjogic := 'Z'; signal ETMIA : std logicvector (31 downto 0 ) := (others => 'Z'); signal ETMIABORT : stdjogic := 'Z'; signal ETMID15Tol 1 : stdjogicvector ( 15 downto 11):= (others => 'Z'); signal ETMID3 lTo25 : stdlogic_vector (31 downto 25 ) := (others => 'Z'); signal ETMInMREQ : std logic := 'Z';

81

signal ETMINSTREXEC : stdjogic := 'Z'; signal ETMINSTRVALID : stdjogic := 'Z'; signal ETMISEQ : stdjogic := 'Z'; signal ETMITBIT : stdjogic := 'Z'; signal ETMLATECANCEL : stdjogic := 'Z'; signal ETMnWAIT : std logic := 'Z'; signal ETMPASS : stdjogic := 'Z'; signal ETMPROCID : std logicvector ( 31 downto 0 ) := (others => 'Z'); signal ETMPROCIDWR : stdjogic := 'Z*; signal ETMRDATA : stdJogic_vector (31 downto 0 ) := (others => 'Z'); signal ETMZIFIRST : stdjogic := 'Z'; signal ETMZILAST : stdjogic := 'Z'; signal ETMIJBIT : stdjogic := 'Z'; signal ETMRNGOUT : stdJogic_vector (1 downto 0 ) := (others => 'Z'); signal ETMWDATA : stdlogicvector (31 downto 0 ) := (others => 'Z'); signal FIFOFULL : stdjogic;

-- TCM Interface Signáis.

— Suponed. signal DRADDR : stdlogicvector ( 17 downto 0 ) := (others => 'Z'); signal DRCS : stdjogic := 'Z'; signal DRnRW : std logic := 'Z'; signal DRRD : std logic_vector (31 downto 0); signal DRSEQ : std logic := 'Z'; signal DRSIZE : stdjogicvector (3 downto 0 ); signal DRWAIT : stdjogic; signal DRWBL : stdlogicvector (3 downto 0 ) := (others => 'Z'); signal DRWD : std logicvector (31 downto 0 ) := (others => 'Z'); signal IRADDR : stdlogicvector ( 17 downto 0) := (others => 'Z'); signal IRCS : stdjogic := 'Z'; signal IRnRW : stdjogic := 'Z'; signal IRRD : std logicvector (31 downto 0); signal IRSEQ : std logic := 'Z'; signal IRSIZE : stdjogicvector ( 3 downto 0 ); signal IRWAIT : stdjogic; signal IRWBL : stdJogic_vector ( 3 downto 0 ) := (others => 'Z'); signal IRWD : std logic_vector (31 downto 0 ) := (others => 'Z');

-- Instruction DMA signáis. signal IRDMAADDR : stdJogic_vector ( 17 downto 0 ); signal IRDMAEN : std logic := '0'; signal IRDMACS : stdjogic; signal IRIDLE : std logic := 'Z';

— Data DMA signáis. signal DRDMAADDR : stdJogic_vector ( 17 downto 0 ); signal DRDMAEN : std logic := '0'; signal DRDMACS : stdjogic; signal DRIDLE : stdjogic := 'Z';

— Memory-side Interface. -- Instruction memory. signal IADDR : stdJogic_vector (17 downto 0); - Addr.

82

signal ICE : stdlogicvector (3 downto 0); - Chip enable. signal IOE : stdlogicvector (3 downto 0); -- Output enable. signal IWE : stdlogicvector (3 downto 0); - Write enable. signal ID ATA : stdlogicvector (31 downto 0); - Write enable.

- Data memory. signal DADDR : stdlogicjvector (17 downto 0); -- Addr. signal DCE : stdlogicvector (3 downto 0); -- Chip enable. signal DOE : stdlogicvector (3 downto 0); - Output enable. signal DWE : stdlogicvector (3 downto 0); - Write enable. signal DDATA : stdlogicvector (31 downto 0); - Write enable.

signal ITCMOE : stdlogicjvector (3 downto 0); signal ITCMWE : std_logic_vector (3 downto 0); signal IDMAOE : stdlogicvector (3 downto 0); signal IDMAWE : stdlogic_vector (3 downto 0);

signal DTCMOE : std_logic_vector (3 downto 0); signal DTCMWE : std_logic_vector (3 downto 0); signal DDMAOE : stdjogicvector (3 downto 0); signal DDMAWE : stdlogicvector (3 downto 0);

- Processor confíguration signáis at startup - Location of the reset vectors either 0x00000000 or OxFFFFOOOO

signal VINITHI: stdjogic := '0'; - Start execution from the ITCM/Memory

signal INITRAM : stdjogic := '0';

- Instruction AHB signáis signal DEVICEADDRESS : stdJogic_vector (31 downto 0 ); signal DEVICEDATA : stdJogic_vector (31 downto 0 ); signal DEVICECE : stdlogicvector (3 downto 0 ); signal DEVICEOE : stdlogicvector (3 downto 0 ); signal DEVICEJWE : stdJogic_vector (3 downto 0 );

- Instruction AHB signáis signal DAHBMADDR : stdJogic_vector (MEMORYADDRESSWIDTH - 1 downto 0 ); signal DAHBMDATA : stdJogic_vector (31 downto 0 ); signal DAHBMCE : stdlogicvector (3 downto 0 ); signal DAHBMOE : stdjogicvector (3 downto 0 ); signal DAHBMWE : stdlogicvector (3 downto 0 );

- UNUSED, ONLY FOR COMPLETENESS. —signal HCLK : stdlogic; signal HCLKEN : stdjogic; signal PERIPHERALCE: stdjogic; signal PERIPHERALOE : stdjogic; signal PERIPHERALWE : stdjogic;

- Device signáis

signal DE VICEENAB LE : stdlogicvector (7 downto 0);

83

— Configuration controller signáis

signal MRESPLATENCY : stdlogic_vector (7 downto 0); signal IGRANTLATENCY : std_logic_vector (7 downto 0); signal DGRANTLATENCY : std_logic_vector (7 downto 0); signal PROCCONF : stdlogicvector (7 downto 0);

-- Configuration controller signáis

signal DEVICE OEMOD : stdjogic; signal DEVICE WEMOD : stdjogic; signal PruebaRegl : stdlogicvector (15 downto 0); signal PruebaReg2 : stdlogicvector (15 downto 0); signal PruebaReg3 : std logicvector (31 downto 0); signal PruebaMul : stdlogicvector (31 downto 0); signal PruebaSum : std logicvector (31 downto 0);

signal scrJVE : std logic := i ' ;

begin

-- Clock generator instance

clkgenerator instance : clkgenerator generic map ( CLK_CYCLE_TIME => CLK_CYCLE_TIME ) port map ( CLK => CLK );

- AHB Arbiter

Arbiter: ahbarbiter port map (

CLK => CLK, IGRANTLATENCY => IGRANTLATENCY, DGRANTLATENCY => DGRANTLATENCY, --HCLK => HCLK,

- Instruction AHB master signáis. IHADDR => IHADDR, IHBURST => IHBURST, IHBUSREQ => IHBUSREQ, IHGRANT => IHGRANT, IHLOCK => IHLOCK, IHPROT => IHPROT, IHREADY => IHREADY, IHRDATA => IHRDATA, IHRESP => IHRESP,

84

IHSIZE => IHSIZE, IHTRANS => IHTRANS, IHWRITE => IHWRITE,

— Data AHB master signáis. DHADDR => DHADDR, DHBL => DHBL, DHBURST => DHBURST, DHBUSREQ => DHBUSREQ, DHGRANT => DHGRANT, DHLOCK => DHLOCK, DHPROT => DHPROT, DHRDATA => DHRDATA, DHREADY => DHREADY, DHRESP => DHRESP, DHSIZE => DHSIZE, DHTRANS => DHTRANS, DHWDATA => DHWDATA, DHWRITE => DHWRITE,

— AHB signáis to the arbiter. HADDR => HADDR, HBL => HBL, HBURST => HBURST, HLOCK => HLOCK, HPROT => HPROT, HRDATA => HRDATA, HREADY => HREADY, HRESP => HRESP, HSIZE => HSIZE, HTRANS => HTRANS, HBUSREQ => HBUSREQ, HWDATA => HWDATA, H WRITE => H WRITE

);

- Memory controller instances

- Contol the Instruction AHB memory. PeripheralController: ahbcontroller generic map ( — The number of address lines for the memory. MEMORYADDRESSWIDTH => MEMORYADDRESSWIDTH ) port map ( — Synchronization signáis CLK => CLK,

EN =>T, -EN => DEVICEENABLE (0),

— Processor interface signáis

85

HBL => HBL, HADDR => HADDR, HBURST => HBURST, HLOCK => HLOCK, HPROT => HPROT, HREADY => HREADY, HRDATA => HRDATA, HRESP => HRESP, HSIZE => HSIZE, HTRANS => HTRANS, HWDATA => HWDATA, H WRITE => HWRITE,

— Combined control signáis ADDR => DEVICEADDRESS, DATA => DEVICEDATA, CE => DEVICE_CE, WE => DEVICE_WE, OE => DEVICE_OE );

— Memory chip instances

IAHBMem_0: sram generic map ( NUMADDRBITS => 16, CVENAME => "CHIP 0" ) port map ( ADDR => DEVICEADDRESS (MEMORYADDRESSWIDTH + 1 downto 2), DQ => DEVICE_DATA(7 downto 0), CE => DEVICEENABLE(O), OE => DEVICE_OE(0), WE => DEVICE_WE(0) );

IAHBMem_l: sram generic map ( NUMADDRJBITS => 16, CVENAME => "CHIP 1"

) port map ( ADDR => DEVICE ADDRESS (MEMORYADDRES SWIDTH + 1 downto 2), DQ => DEVICE_DATA(15 downto 8), CE => DEVICEJENABLE(l), OE=>DEVICE_OE(l), WE=>DEVICE_WE(1) );

IAHBMem_2: sram generic map ( NUMADDRBITS => 16, CVENAME => "CHIP 2" )

86

port map ( ADDR => DEVICEADDRESS (MEMORYADDRESSWIDTH + 1 downto 2), DQ => DEVICE_DATA(23 downto 16), CE => DEVICE_ENABLE(2), OE => DEVICE_OE(2), WE => DEVICE_WE(2)

);

IAHBMem_3: sram generic map ( NUMADDRBITS => 16, CVENAME => "CHIP 3" ) port map ( ADDR => DEVICEADDRESS (MEMORYADDRESSWIDTH + 1 downto 2), DQ => DEVICE_DATA(31 downto 24), CE => DEVICE_ENABLE(3), OE => DEVICE_OE(3), WE => DEVICE_WE(3) );

— Address Decoder

Decoder: addressdecoder generic map (

MEMORYBASEADDRESS => MEMORYBASEADDRESS, MEMORYADDRESSWIDTH => MEMORYADDRESSWIDTH,

INTGENBASEADDRESS => INTGENBASEADDRESS, INTGENADDRESSWIDTH => INT_GEN_ADDRESS_WIDTH,

RESETCONTBASEADDRESS => RESET_CONT_BASE_ADDRESS, RESETCONTADDRESSWIDTH => RESET_CONT_ADDRESS_WIDTH,

CONFCONTBASEADDRESS => CONFCONTBASEADDRESS, CONFCONTADDRESSWIDTH => CONFCONTADDRESSWIDTH,

SCREENBASEADDRESS => SCREENBASEADDRESS, SCREENADDRESSWIDTH => SCREENADDRESSWIDTH

) port map (

CE => DEVICE_CE, HADDR => DEVICEADDRESS, EN => DEVICEENABLE

);

— Reset contoller instance

PERIPHERAL_OE<=DEVICE_OE(0) and DEVICE_OE(l) and DEVICE_OE(2) and DEVICE_OE(3); PERIPHERAL_CE<=DEVICE_CE(0) and DEVICE_CE(1) and DEVICE_CE(2) and DEVICE_CE(3); PERIPHERAL_WE<=DEVICE_WE(0) and DEVICE_WE(1) and DEVICE_WE(2) and

DEVICE_WE(3);

87

reset_controller_instance : resét_controller generic map ( CLKCYCLETIME => CLKCYCLETIME, INITIALSTARTUPTIME => INITIALSTARTUPTIME

) port map ( CLK => CLK, ADDR => DEVICE_ADDRESS(3 downto 0), DQ => HWDATA, EN => DEVTCE_ENABLE(4), OE => PERIPHERALOE, WE => PERIPHERALWE, CE => PERIPHERALCE, HRESETn => HRESETn, HCLKEN => HCLKEN, DBGnTRST => DBGnTRST );

- Interrupt generator instance

int_generator_instance : int_generator generic map (

CLKCYCLETIME => CLKCYCLETIME )

port map ( CLK => CLK, ADDR => DEVICE_ADDRESS(3 downto 0), DQ => HWDATA, EN => DEVICE_ENABLE(5), CE => PERIPHERALCE, OE => PERIPHERALOE, WE => PERIPHERALWE, INT_LINES (0) => nIRQ, INT_LINES(l)=>nFIQ );

— Configuration controller

ConfigurationController: con fcontroller port map ( EN => DEVICE_ENABLE(6), ADDR => DEVICE_ADDRESS(3 downto 0), DQ => HWDATA, CE => DEVICE_CE, OE => DEVICE_OE, WE => DEVICE_WE, MRESPLATENCY => MRESPLATENCY, IGRANTLATENCY => IGRANTLATENCY, DGRANTLATENCY => DGRANTLATENCY, PROCCONF => PROCCONF

);

88

Screenifc: screen port map (

D => HWDATA( 7 downto 0 ), OE => T, - Q RESET => HRESETn, SET =>T, WE => scr_we

);

scr_we <= DEVICE_WE(0) or DEVICE_ENABLE(7); DEVICE_OE_MOD <= DEVICE_OE(0) and DEVICE_OE(l) and DEVICE_OE(2) and

DEVICE_OE(3); DEVICE_WE_MOD <= DEVICE_WE(0) and DEVICE_WE(0) and DEVICE_WE(0) and

DEVICE_WE(0);

mimodulo: mac Port map(

data => DEVICEDATA, address => DEVICE_ADDRESS(3 downto 2), Registro 1 => PruebaRegl, Registro2 => PruebaReg2, Registro3 => PruebaReg3, Mul32 => PruebaMul, Sum32=> PruebaSum, clk => CLK, CE => scrwe, RE => DEVICE_ENABLE(7) -WE=> DEVICE_WE(0) );

- TCM controller

TCMController: tcmcontroller port map (

CLK => CLK ,

-- Processor-side signáis - DTCM signáis. DRDMAEN => DRDMAEN , DRADDR => DRADDR , DRCS => DRCS , DRnRW => DRnRW , DRRD => DRRD , DRSEQ => DRSEQ , DRSIZE =>DRSIZE , DRWAIT =>DRWAIT , DRWBL => DRWBL , DRWD => DRWD , DRIDLE => DRIDLE ,

89

— ITCM signáis. IRDMAEN => IRDMAEN , IRADDR => IRADDR , IRCS =>IRCS , IRnRW =>IRnRW , IRRD => IRRD , IRSEQ =>IRSEQ , 1RSIZE =>IRSIZE , IRWAIT =>IRWAIT , IRWBL =>IRWBL , IRWD => IRWD , IRIDLE =>IRIDLE ,

-- Memory-side Interface. — Instruction memory. IADDR => IADDR, ICE =>ICE, IOE => IOE, IWE => IWE, IDATA => IDATA,

— Data memory. DADDR => DADDR, DCE => DCE, DOE => DOE, D WE => DWE , DDATA => DDATA

);

-- TCM memories.

ITCMemO: sram generic map (

NUMADDRBITS => 12, CVENAME => "ITCM 0"

) port map (

ADDR => IADDR (11 downto 0), DQ => IDATA(7 downto 0), CE =>ICE(0), OE =>ITCMOE(0), WE =>ITCMWE(0)

);

ITCMem_l: sram generic map (

NUMADDRBITS => 12, CVE_NAME => "ITCM 1"

) port map (

ADDR => IADDR (11 downto 0), DQ => IDATA(15 downto 8), CE =>ICE(1),

90

OE => ITCMOE(l), WE => ITCMWE(l)

);

ITCMem_2: sram generic map (


) port map (


);

ITCMem_3: sram generic map (


) port map (


);

DTCMemO: sram generic map (

NUMADDRBITS => 10, CVENAME => "DTCM 0"

) port map (

ADDR => DADDR (9 downto 0), DQ => DDATA(7 downto 0), CE =>DCE(0), OE =>DTCMOE(0), WE =>DTCMWE(0)

);

DTCMeml: sram generic map (


) port map (

ADDR => DADDR (9 downto 0), DQ =>DDATA(15 downto 8), CE =>DCE(1), OE =>DTCMOE(l), WE =>DTCMWE(1)

);

91

DTCMem_2: sram generic map.(


) port map (


);

DTCMem_3: sram generic map (

NUMADDRBITS => 10, CVE_NAME => "DTCM 3"

) port map (


);

DMAController: dmacontroller port map(

CLK => CLK, - Instruction DMA signáis. -- Processor-side signáis. IRDMAADDR => IRDMAADDR, IRDMAEN => IRDMAEN, IRDMACS => IRDMACS, - Memory-side signáis. IOE => IDMAOE, IWE => IDMAWE, -IDATA => IDMADATA, IDATA => IDATA,

- Data DMA signáis. - Processor-side signáis. DRDMAADDR => DRDMAADDR, DRDMAEN => DRDMAEN, DRDMACS => DRDMACS, - Memory-side signáis. DOE => DDMAOE, DWE => DDMAWE, DDATA => DDATA );

ITCMOE <= IOE when (IRDMAEN = '0') else IDMAOE; ITCMWE <= IWE when (IRDMAEN = '0') else IDMAWE;

DTCMOE <= DOE when (DRDMAEN = '0') else DDMAOE; DTCMWE <= DWE when (DRDMAEN = '0') else DDMAWE;

92

- ARM926E-Srevl processor instance

ARM926EJS_revO : arm926ejs port map (

- Data Bus Signáis - Supported. DHADDR => DHADDR DHBL => DHBL DHBURST => DHBURST DHBUSREQ => DHBUSREQ , DHCLKEN => HCLKEN DHGRANT => DHGRANT DHLOCK => DHLOCK DHPROT => DHPROT DHRDATA => DHRDATA DHREADY => DHREADY DHRESP => DHRESP DHSIZE => DHSIZE DHTRANS => DHTRANS DHWDATA => DHWDATA DHWRITE => DHWRITE HRESETn => HRESETn

- Instruction Bus Signáis - Supported. IHADDR => IHADDR IHBURST => IHBURST IHBUSREQ => IHBUSREQ , IHCLKEN => HCLKEN IHGRANT => IHGRANT , IHLOCK => IHLOCK IHPROT => IHPROT IHREADY => IHREADY IHRDATA => IHRDATA IHRESP => IHRESP IHSIZE => IHSIZE IHTRANS => IHTRANS IHWRITE => IHWRITE

- Coprocessor Signáis - Not Supported. CPABORT => CPABORT CPBURST => CPBURST CPCLKEN => CPCLKEN CPDIN => CPDIN CPDOUT => CPDOUT CPEN => CPEN CPINSTR => CPINSTR CPPASS => CPPASS CPLATECANCEL => CPLATECANCEL , CHSDE => CHSDE CHSEX => CHSEX nCPINSTRVALID => nCPINSTRVALID, nCPMREQ => nCPMREQ

93

nCPTRANS =>nCPTRANS ,

- Debug Signáis - Not Supported. COMMRX => COMMRX COMMTX => COMMTX DBGACK => DBGACK DBGDEWPT => DBGDEWPT , DBGEN => DBGEN DBGEXT => DBGEXT DBGIEBKPT => DBGIEBKPT , DBGINSTREXEC => DBGINSTREXEC , DBGRNG => DBGRNG DBGRQI => DBGRQI EDBGRQ => EDBGRQ

-- JTAG Signáis - Not Supported. DBGIR => DBGIR DBGnTRST => DBGnTRST , DBGnTDOEN => DBGnTDOEN , DBGSCREG => DBGSCREG , DBGSD1N => DBGSDIN DBGSDOUT => DBGSDOUT , DBGTAPSM => DBGTAPSM , DBGTCKEN => DBGTCKEN , DBGTDI => DBGTDI DBGTDO => DBGTDO DBGTMS => DBGTMS

-- Miscellaneous Signáis. - Supported. CLK => CLK CFGBIGEND => CFGBIGEND , nFIQ => nFIQ nIRQ => nIRQ VINITHI => VINITHI - Not Supported. BIGENDINIT => BIGENDINIT , EXTEST => EXTEST INTEST => INTEST SCANENABLE => SCANENABLE , STANDBYWFI => STANDBYWFI , TAPID =>TAPID TESTMODE => TESTMODE ,

-- ETM Interface Signáis - Not Supported. ETMBIGEND => ETMBIGEND , ETMCHSD => ETMCHSD ETMCHSE => ETMCHSE ETMDA => ETMDA ETMDABORT => ETMDABORT , ETMDBGACK => ETMDBGACK , ETMDMAS => ETMDMAS ETMDMORE => ETMDMORE , ETMDnMREQ => ETMDnMREQ , ETMDnRW => ETMDnRW ETMDSEQ => ETMDSEQ

94

ETMEN => ETMEN ETMHIVECS =>ETMHIVECS , ETMIA => ETMIA ETMIABORT => ETMIABORT , ETMZIFIRST => ETMZIFIRST , ETMZILAST => ETMZILAST , ETMIJBIT => ETMIJBIT , ETMID15Toll =>ETMID15Toll , ETMID31To25 => ETMID31To25 , ETMInMREQ => ETMInMREQ , ETMINSTREXEC => ETMINSTREXEC , ETMINSTRVALID => ETMINSTRVALID, ETMISEQ => ETMISEQ ETMITBIT => ETMITBIT , ETMLATECANCEL => ETMLATECANCEL, ETMnWAIT => ETMnWAIT , ETMPASS => ETMPASS ETMPROCID => ETMPROCID , ETMPROCIDWR => ETMPROCIDWR , ETMRDATA => ETMRDATA , ETMRNGOUT => ETMRNGOUT , ETMWDATA => ETMWDATA , FIFOFULL => FIFOFULL ,

- TCM Interface Signáis. -- Supported. INITRAM => INITRAM DRADDR => DRADDR DRCS => DRCS DRnRW => DRnRW DRRD => DRRD DRSEQ => DRSEQ DRSIZE => DRSIZE DRWAIT => DRWAIT DRWBL => DRWBL DRWD => DRWD IRADDR => IRADDR IRCS =>IRCS IRnRW => IRnRW IRRD => IRRD IRSEQ => IRSEQ IRSIZE => IRSIZE IRWAIT => IRWAIT IRWBL => IRWBL IRWD => IRWD

- ITCM DMA Interface Signáis. IRDMAADDR => IRDMAADDR , IRDMAEN => IRDMAEN IRDMACS => IRDMACS

- DTCM DMA Interface Signáis. DRDMAADDR => DRDMAADDR , DRDMAEN => DRDMAEN DRDMACS => DRDMACS

95

- Not Supported. DRIDLE => DRIDLE IRIDLE => IRIDLE

);

end arm926ejs_rev0_tb;

96

Bibliografía

[I] Mitel. Cifras relevantes de la industria marzo 2007. Pagina. 2, Marzo 2007.

[2] Linda Brackenbury Mike Lewis. A low-power asynchronos dsp architecture for digital

mobile phono chipsets. Proceedings PREP 2000 Pages 120-124, Abril 2000.

[3] L.Besacier, S. Grassi, A. Dufaux, M . Ansorge, F. Pellandini. GSM speech coding and

speaker recognition. University of Neuchatel, A.L. Breguet, University Joseph Fourier, 2000

[4] http://www.etsi.org

[5] Ira A. Gerson and Mark A, Jasiuk, VECTOR SUM EXCITED LINEAR PREDICTION

(VSELP) SPEECH CODING AT 8 KBPS, Chicago Corporate Research and Development

Center, pp 461-464, abril 1990.

[6] Approach", IEEE Computer Society, 1999.

[7] A. Booth. "Asigned Multiplication Technique". QuartellyJ. ofMech. Appl Math. Vol.4, Part2. 1951.

[8] Chetana Nagendra,, Mary Jane Irwin, Robert Michael Owens. Area-Time-Power Tradeoffs in Parallel Adders, ANALOG AND DIGITAL SIGNAL PROCESSING, VOL. 43, NO. 10, OCTOBER 1996.

[9] GSM 6.20 versión 8.0.1, "GSM half rate speech transcoding", ETSI, 1999.

[10] A. Sánchez, E. Baz, I. Gutiérrez, R. Nava, S. García Implementación en VHDL de un módulo de multiplicación basado en algoritmos de Booth Instituto Tecnológico de Orizaba

[II] Mentor Graphics, Seamless user and reference manual, softrare versión 5.6.1 February 2009

[121http://www.xilinx.com/products/design_tools/logic_design/verification/xpower.htm

[13] Gustavo E. Ordóñez-Fernández, Lewin A. López-López, Jaime Velasco-Medina, DISEÑO DE MULTIPLICADORES PARALELOS DE 16 BITS EN FPGAS, Universidad del Valle, A.A. 25360, Cali, Colombia

[14] William Webb Wireless Communications The future, Wiley, 2007

[15] Amara Amara, Frédéric Amiel and Thomas Ea, FPGA vs. ASIC for low power applications, Electronics Department, Instituí Supérieur d'Electronique de Paris-ISEP, 21 rué d'Assas, 75006 Paris, France

97

instituto tecnolÓgico y de estudios - … de energÍa para el protocolo gsm half-rate tesis...

Documents