arquitectura dsp tigersharc

Aspectos fundamentales, ADSP-TS201 TigerSHARC, PG 1

Universidad Tecnológica NacionalFacultad Regional Bahía BlancaDepartamento de Ing. Electrónica

Técnicas Digitales III.

Año 2009.

Aspectos fundamentales de la Arquitectura delADSP-TS201 TigerSHARC

ALUMNO: Galasso Christian L.

[email protected]

Resumen: En el presente informe se realiza un análisis de características particulares del procesador TigerSHARC, y de algunas que difieren de la arquitectura SHARC típica, y que le hacen tener ventajas sobre la misma, además de presentarse ejemplos de código para la implementación de dichas características.


Índice de contenido1.Breve descripción del DSP tigerSHARC........................................5

1.1.Arquitectura del procesador.............................................51.2.Características especiales del TigerSHARC...............................7

2.Arquitectura superescalar Vs VLIW...........................................82.1.Introducción a las arquitecturas de procesadores........................82.2.Arquitectura Superescalar...............................................92.3.Arquitectura VLIW (Superescalar estática)..............................102.4.Planificación en una máquina Superescalar vs. una VLIW.................102.5.Diferencias y semejanzas...............................................11

3.Características que hacen del TigerSHARC un DSP ortogonal..................123.1.Instrucciones Ortogonales..............................................123.2.Registros ortogonales..................................................12

4.Unidad lógica orientada a las comunicaciones (CLU).........................134.1.Descripción de la CLU..................................................134.2.Operaciones de la CLU..................................................14

4.2.1.Función TMAX (Trellis Maximum).....................................144.2.2.Funciones de celosía (Trellis Function)............................154.2.3.Funciones de dispersión (Despread Function)........................16

5.Registros de los bloques de cálculo........................................186.Unidad aritmético-lógica orientada a enteros (IALU)........................21

6.1.Descripción de la IALU.................................................216.2.Direccionamiento directo e indirecto...................................226.3.Acceso a memoria Normal, Broadcast y Fusionado........................236.4.Buffer de alineación de datos(DAB).....................................246.5.Direccionamiento de buffer circular....................................256.6.Direccionamiento Bit Reverse...........................................266.7.Direccionamiento en las operaciones SISD y SIMD........................28

7.Secuenciador de programa...................................................297.1.Introducción al secuenciador de programa...............................297.2.Pipeline...............................................................30

7.2.1.Introducción al pipeline...........................................307.2.2.Operación del pipeline de instrucciones............................317.2.3.Efectos sobre el pipeline de las dependencias y los recursos.......32

7.3.Caché de instrucciones y buffer de destino de saltos(BTB)..............327.3.1.Introducción al BTB y comparación con la caché del SHARC...........327.3.2.¿Como se ahorra ciclos con el BTB?.................................337.3.3.¿Cuando es conveniente el uso del BTB?.............................347.3.4.Sobre colocar más de un salto en una palabra cuádruple.............34

7.4.Buffer de alineación de instrucciones(IAB).............................357.5.Variaciones en el flujo de programa....................................367.6.Interrupciones.........................................................38

8.Soporte para sistemas operativos...........................................438.1.Cambio de contexto.....................................................438.2.Anidamiento de llamadas e interrupciones...............................438.3.Direccionamiento relativo..............................................43

9.Bibliografía y Agradecimientos.............................................449.1.Bibliografía...........................................................449Agradecimientos...........................................................44


1.Breve descripción del DSP tigerSHARC

El TigerSHARC es un procesador de alta performance optimizado para tareas de procesamiento de gran señal y para la infraestructura de las comunicaciones. Provee capacidades de procesamiento de señales digitales, a través de una arquitectura superescalar estática (véase sección 2.3), optimizada para aplicaciones de DSP de alta demanda de recursos, del tipo multiprocesador; la misma le permite ejecutar de 1 a 4 instrucciones por ciclo de reloj; pudiendo ejecutar 24 operaciones de punto fijo (16 bits) o 6 operaciones de punto flotante. Combina una memoria amplia con 2 bloques de cálculo. Puede trabajar en modo SIMD (single instruction multiple data) lo cuál le otorga una performance de 4,8 billones de 40-bits MACS o 1,2 billón de 80-bits MACS por segundo. Cuatro canales independientes de 128 bits de ancho c/u, conectados a los 6 bancos de memoria de 4Mbit c/u; más la palabra cuádruple de instrucción y las I/O proveen en conjunto una velocidad de transferencia de datos interna de 33,6 Gbytes/seg. Soporta transferencias DMA de baja intrusión entre memoria interna, externa, periféricos mapeados en memoria, puertos de enlace (link), procesadores anfitriones (interfase con el usuario o procesadores centrales) y otros DSPs (arquitecturas de varios procesadores). Facilita la programación por medio de un conjunto de instrucciones DSP extremadamente flexible y amigable con los lenguajes de alto nivel. NOTA: Como las hojas de datos (datasheet) y el manual de referencia de Hardware (Hardware reference) se encuentran al alcance del público, se hará solo una muy breve descripción del TigerSHARC y sus componentes principales para luego adentrarse en sus características particulares.

1.1.Arquitectura del procesador

El diagrama en bloques se presenta dividido en dos partes, la primera llamada núcleo del procesador, que es el lugar donde se lleva a cavo la ejecución de las instrucciones:

Figura 1-1: Núcleo del procesador.


La segunda llamada periféricos del procesador, que es la parte donde almacenamos los datos y tomamos o enviamos datos desde el exterior al DSP o desde el DSP al exterior:

Figura 1-2: Diagrama de periféricos del procesador.

Como se puede observar en las figuras 1-1 y 1-2 la arquitectura posee los siguientes componentes:

2 Bloques de cálculo: X e Y, cada uno constituido por un multiplicador, ALU, CLU, unidad de desplazamiento de bits (de ahora en adelante: Shifter), y 32 registros de 32-bits (tamaño palabra) cada uno.

Secuenciador de programa – Controla el flujo de la ejecución y contiene el buffer de alineación de instrucciones “IAB” (Instruction Alignment Buffer) y el buffer de destino de salto “BTB” (Branch Target Buffer).

3 canales (buses) de 128-bits que proveen una conectividad de gran ancho de banda entre la memoria interna y el resto de los elementos del procesador (bloques de cálculo, IALUs, secuenciador de programa, y la interfase SOC).

1 Canal de 128-bits que provee una conectividad de gran ancho de banda entre la memoria interna y los periféricos de I/O (DMA, puertos externos y puertos de linkeo).

Interfase con los puertos externos, incluyendo, interfase maestra, controlador de SDRAM, interfase con el pipeline estático, 14 canales DMA, 4 puertos link LVDS (uno cada dos canales DMA), y soporte para multiprocesamiento.

24 Mbits de memoria interna dividida en 6 bloques de 4 Mbits, cada uno de los cuáles contiene 128 K-palabras de 32-bits; cada bloque se interconecta a través de su propio buffer y de una memoria caché asociativa de 128 K-bits.

Características de depuración (Debug features).

Puerto de testeo y emulación JTAG.


1.2.Características especiales del TigerSHARC

Características especiales para simplificar el desarrollo de sistemas. Las mismas las podemos dividir en tres áreas:

Soporta los formatos punto fijo y flotante IEEE.

Cumple con el estándar 1149.1 del IEEE. JTAG.

La arquitectura soporta lenguaje de alto nivel y sistemas operativos.

Las características que hacen posible utilizar en el mismo lenguaje de alto nivel y sistemas operativos son:

Set de instrucciones ortogonales (véase sección 3) que permite al compilador el uso eficiente de los slots multi-instrucciones.

Registros de datos de propósito general y de IALU.

Soporte para datos de 32-bits (IEEE estándar 754/854) y 40-bits en punto flotante y 8-, 16-, 32-, y 64-bit en punto fijo.

Gran espacio de direcciones.

Modificación de campos de direcciones inmediato.

Fácil reubicación de código y datos.

Está optimizado para guardar y/o recuperar rápidamente, los registros del procesador, dentro de la pila de la memoria interna (o sea que, está optimizado para realizar los cambios de contexto típicos de los sistemas operativos multitarea).

Nota: Que soporte lenguajes de alto nivel no implica que sea eficiente usarlos para programar el TigerSHARC, ya que por ser superescalar estático, aparece un problema de dependencias entre instrucciones, y conflictos de recursos; el compilador hace su mejor esfuerzo por acomodar las instrucciones paralelizables pero la experiencia dice que el resultado del compilador deja mucho que desear, a tal punto que lo más conveniente en la mayoría de los casos, es que el mismo programador escriba el código en lenguaje ensamblador haciendo uso de las tablas de dependencias provistas en la “programing reference”, pudiendo así obtener resultados mucho más satisfactorios que el compilador y por ende algoritmos que se ejecutarán en un número menor de ciclos, que serán mucho mas rápidos y eficientes.


2.Arquitectura superescalar Vs VLIW

2.1.Introducción a las arquitecturas de procesadores

Una de las primeras arquitecturas fue la Von Neumann que utiliza una unidad de procesamiento, una memoria, un bus de datos e instrucciones (compartido) y otro de direcciones y requiere un determinado número de ciclos de máquina para ejecutar una instrucción completa. Esto implica que para traer una instrucción se tengan uno o varios accesos a memoria y si esta instrucción maneja datos de memoria, se debe realizar otro(s) acceso(s) para traer, operar y volver a almacenar los datos. Con lo cual el bus se congestiona con tanto acceso.

Figura 2-1: Arquitectura Von Neumann.

Luego apareció la arquitectura HARVARD la cuál tiene memoria de programa y memoria de datos separadas y se accede a ellas a través de buses separados. La instrucción se trae a la CPU en un solo acceso a la memoria de programa . Mientras tanto el bus de datos está libre y puede accederse a través de él a los datos que se necesitan para ejecutar la instrucción de programa anterior a la que se esta trayendo de memoria de programa en ese momento.

Figura 2-2: Arquitectura Harvard.

Ventaja:

El tiempo de acceso se mejora respecto a la arquitectura von Neumann donde programa y datos se traen a la CPU usando el mismo bus.

Ahora bien, nos falta definir otra característica de la arquitectura, si es escalar o vectorial. Los procesadores escalares son el tipo más sencillo de procesadores. Cada instrucción de un procesador escalar opera sobre un dato cada vez. En contraposición, en un procesador vectorial una sola instrucción opera simultáneamente sobre un conjunto más o menos grande de datos. La diferencia entre ambos es la misma que entre la aritmética escalar y vectorial[3].


2.2.Arquitectura Superescalar

Superescalar (también conocida como vectorial) es el término utilizado para designar un tipo de microarquitectura de procesador capaz de ejecutar más de una instrucción por ciclo de reloj. El término se emplea por oposición a la microarquitectura escalar que sólo es capaz de ejecutar una instrucción por ciclo de reloj. La microarquitectura superescalar utiliza el paralelismo de instrucciones además del paralelismo de flujo, éste último gracias a la estructura en pipeline. La estructura típica de un procesador superescalar consta de un pipeline con las siguientes etapas:

lectura (fetch). decodificación (decode). lanzamiento (dispatch). ejecución (execute). escritura (writeback). finalización (retirement).

En un procesador superescalar, el procesador maneja más de una instrucción en cada etapa. El número máximo de instrucciones en una etapa concreta del pipeline se denomina grado, así un procesador superescalar de grado 4 en lectura (fetch) es capaz de leer como máximo cuatro instrucciones por ciclo. El grado de la etapa de ejecución depende del número y del tipo de las unidades funcionales. Un procesador superescalar suele tener unidades funcionales independientes de los tipos siguientes:

unidad aritmético lógica (ALU) unidad de lectura / escritura en memoria (Load/Store Unit) unidad de coma flotante (Floating Point Unit) unidad de salto (Branch unit)

Un procesador superescalar es capaz de ejecutar más de una instrucción simultáneamente únicamente si las instrucciones no presentan algún tipo de dependencia (hazard). Los tipos de dependencia entre instrucciones son:

dependencia estructural, esta ocurre cuando dos instrucciones requieren el mismo tipo unidad funcional y su número no es suficiente.

dependencia de datos, esta ocurre cuando una instrucción necesita del resultado de otra instrucción para ejecutarse, por ejemplo R1<=R2+R3 y R4<=R1+5.

dependencia de escritura o falsa dependencia , esta ocurre cuando dos instrucciones necesitan escribir en la misma memoria, por ejemplo R1<=R2+R3 y R1<=R1+5.

La detección y resolución de las dependencias entre instrucciones puede ser estática (durante la compilación), para el caso de las arquitecturas VLIW (superescalares estáticas), o dinámica, es decir, a medida que se ejecuta un programa, generalmente durante las etapas de codificación y lanzamiento de las instrucciones. La detección y resolución dinámica de las dependencias entre instrucciones suele realizarse mediante alguna variante del algoritmo de Tomasulo que permite la ejecución de instrucciones en un orden distinto al del programa también llamada ejecución en desorden . La eficacia de un procesador superescalar viene limitada por un lado por la dificultad en suministrar al procesador suficientes instrucciones que puedan ser ejecutadas en paralelo y por otro lado por las prestaciones de la jerarquía de memorias. Si las instrucciones de salto son un problema para los procesadores con pipeline en general, en el caso de los procesadores superescalares, el problema se multiplica ya que un parón en el pipeline tiene consecuencias en un número mayor de instrucciones.Por esta razón, los fabricantes de procesadores recurren a técnicas de ejecución especulativa y diseñan algoritmos de predicción de saltos cada vez más sofisticados así como sistemas de almacenamiento de instrucciones por trazas (trace caches).

Ventajas:

Aumento de la velocidad de procesamiento al poder ejecutar más de una sola instrucción por ciclo de reloj.


Inconvenientes:

Las arquitecturas superescalares adolecen de una estructura compleja y de un mal aprovechamiento de sus recursos debido en parte a la dificultad en encontrar suficientes instrucciones paralelizables.

Una forma de obtener un mayor número de instrucciones paralelizables es aumentar la ventana de instrucciones, es decir el conjunto de instrucciones que la unidad de lanzamiento considera como candidatas a ser lanzadas en un momento dado. Desafortunadamente la complejidad del procesador superescalar aumenta desproporcionadamente con respecto al tamaño de dicha ventana lo que se traduce por un ralentizamiento general del circuito.

Otra forma de obtener más instrucciones paralelizables es manipulando instrucciones de más de un programa a la vez, lo que se conoce bajo el nombre de multitarea simultánea o multithreading simultáneo.

2.3.Arquitectura VLIW (Superescalar estática)

Esta arquitectura de CPU implementa una forma de paralelismo a nivel de instrucción. Es similar a las arquitecturas superescalares, ambas usan varias unidades funcionales (por ejemplo varias ALUs, varios multiplicadores, etc.) para lograr ese paralelismo. Los procesadores con arquitecturas VLIW se caracterizan, como su nombre indica, por tener juegos de instrucciones muy simples en cuanto a número de instrucciones diferentes, pero muy grandes en cuanto al tamaño de cada instrucción. Esto es así porque en cada instrucción se especifica el estado de todas y cada una de las unidades funcionales del sistema, con el objetivo de simplificar el diseño del hardware al dejar todo el trabajo de planificar el código en manos del programador/compilador, en oposición a un procesador superescalar, en el que es el hardware en tiempo de ejecución el que planifica las instrucciones.

Ventajas:

• Simplificación de la arquitectura hardware al no tener que planificar el código • Reducción del número de instrucciones de los programas

Inconvenientes:

• Requiere compiladores mucho más complejos • Cualquier mejora en la arquitectura hardware implica un cambio en el juego de instrucciones

(compatibilidad hacia atrás nula) A día de hoy, las máquinas VLIW prácticamente han desaparecido, ya que los inconvenientes pesan bastante más que las ventajas. La imposibilidad de tener compatibilidad hacia atrás, los excesivos cambios requeridos en los compiladores, y el hecho de que la simplificación del hardware respecto a las máquinas superescalares convencionales no sea tampoco excesiva han hecho que se abandonen este tipo de diseños. Aunque existen conversores de código binario, que traducen los programas compilados para un procesador al lenguaje binario de los modelos posteriores, sin necesidad de reescritura o recompilado mediante el nuevo compilador.

2.4.Planificación en una máquina Superescalar vs. una VLIW

Por ejemplo, supongamos el siguiente programa para una máquina superescalar "normal":

1 Multiplicar R1 por R2 y guardarlo en R32 Sumar R3 con R4 y guardarlo en R53 Restar R1 de R4 y guardarlo en R6

En este programa, el planificador de código vería que la segunda instrucción depende de la primera (hasta que no esté calculado R3 no se puede ejecutar la suma), y que en cambio la tercera instrucción es independiente de las otras dos. Por tanto, probablemente iniciaría simultáneamente la multiplicación y la resta en unidades diferentes y, una vez acabada la multiplicación, ejecutaría la suma. Todo este trabajo de planificación lo llevaría a cabo la circuitería interna del microprocesador.


En una máquina VLIW, toda la planificación anterior la haría el compilador (o el propio programador si programa en ensamblador), y el código resultante sería algo así:

1 MULT(R1,R2,R3) - REST(R1,R4,R6)2 - SUM(R3,R4,R5)

Se puede ver como en cada instrucción se especifica el estado de cada unidad funcional, de modo que en la primera instrucción se activan el multiplicador y el restador, dejando el sumador ocioso al no poder calcular aún la suma, y en la siguiente instrucción se hace la suma que faltaba.

2.5.Diferencias y semejanzas

Diferencias:

El momento en el cuál se hace el chequeo de las dependencias entre las instrucciones. El tipo de instrucciones.

Semejanzas:

Misma estructura básica compuesta por múltiples unidades de procesamiento, operando en paralelo, y un único banco de registros compartido, o uno por cada unidad de procesamiento.


3.Características que hacen del TigerSHARC un DSP ortogonal

3.1.Instrucciones Ortogonales

La ortogonalidad es una propiedad de las CPU. Se dice que un conjunto de instrucciones es ortogonal cuando se puede utilizar cualquier modo de direccionamiento en cualquier instrucción. Dicho en otras palabras, deben poder combinarse, en le medida de lo posible, todas las operaciones con todos los tipos de datos y modos de direccionamiento. La búsqueda de la ortogonalidad hace que el diseño de la CPU sea más complejo pero aporta una mayor facilidad de programación. Cuando el juego de instrucciones está bien diseñado y tiene características de ortogonalidad, el conjunto de instrucciones requerido para realizar todas las tareas es reducido y se aprende rápidamente.

3.2.Registros ortogonales

Cada uno de los bloque de procesamiento posee un registro ortogonal multipuerto de 32 palabras de 32-bits, el cuál se puede utilizar para transferencias de datos entre los bloques y los canales de datos y para almacenar resultados intermedios. Todos estos registros pueden ser accedidos de 3 formas distintas:

Individualmente (word-aligned).

En sets de 2 ( dual-aligned).

En sets de 4 (quad-aligned).


4.Unidad lógica orientada a las comunicaciones (CLU)

4.1.Descripción de la CLU

El núcleo del procesador TigerSHARC contiene dos unidades de cálculo conocidas como unidades lógicas orientadas a las comunicaciones (CLU del inglés: Communications Logic Unit). Las CLUs pueden ya sea tomar sus datos de entrada como almacenar sus resultados en los registros internos de los bloques o en los registros TR/THR (registros específicos de las CLUs, no-mapeados en memoria; ver sección 5). La mayoría de las instrucciones de las CLUs operan sobre los registros “Trellis Registers” (TR) y “Trellis History Registers” (THR). Si bien estas unidades soportan múltiples usos, fueron diseñadas para realizan funciones específicas de los siguientes algoritmos de comunicación:

Decodificación Viterbi[5]. Decodificación de Turbo códigos[4]. Dispersión para sistemas de Acceso múltiple por división de código (CDMA)[3]. Correlaciones cruzadas usadas para búsqueda de camino (CDMA)[3].

El hecho de incluir las instrucciones específicas de las CLUs simplifica la programación de dichos algoritmos, manteniendo la flexibilidad de un enfoque de software. De ésta manera, es sencillo ajustar el algoritmo a los requisitos específicos del usuario. Además, las instrucciones se pueden utilizar para una variedad de propósitos, por ejemplo la instrucción “TMAX”, incluida para soportar la decodificación de turbo-códigos, es también muy utilizada en la decodificación de códigos de paridad de baja densidad.

Figura 4-1: bloques de cálculo donde se distinguen las CLUs.


4.2.Operaciones de la CLU

Las instrucciones de la CLU se aplican a datos de punto fijo los cuales pueden ser reales o complejos. Las mismas están orientadas a los siguientes usos:

Logaritmo Jacobiano para turbo códigos (TMAX). Dispersión para CDMA (DESPREAD). Correlaciones cruzadas para CDMA (XCORRS). Reordenamiento polinomial (PERMUTE). Suma/comparación/selección de celosías (Trellis).

Las instrucciones de la CLU están referidas a tres tipos de registros:

Rm,n,s – 32 (Datos) Registros de los bloque de procesamiento. TRm,n,s – 32 (Trellis) Registros dedicados a las instrucciones de la CLU. THR – 4 (Trellis History) Registros usados por las instrucciones ACS, DESPREAD, y XCORRS por

datos desplazados. CMCTL – Registros de control de comunicaciones usados por la instrucción XCORRS los cuales

son una entrada opcional para el valor CUT.

Nota: Aunque se ven cuatro puntos pero los tipos de registro son 3: Datos, Trellis (celosía), Trellis History(histórico de la celosía).

Las funciones de la CLU podemos clasificarlas en:

“Función TMAX”. “Función de celosía” (Trellis Function). “Funciones de dispersión” (Despread Function). “Funciones de correlaciones cruzadas”.

4.2.1.Función TMAX (Trellis Maximum)

Un único código de protección de errores no siempre proporciona la protección necesaria con una complejidad aceptable, la solución es concatenar dos (o más) códigos, con lo que obtenemos un código mucho más potente que los tradicionales, también conocido como turbocódigo[4]. La concatenación se puede hacer en serie o en paralelo. Uno de los algoritmos utilizados es el “log-MAP”, cuyo diagrama se puede ver en la Figura 4-2:

Figura 4-2: Algoritmo de Turbo codificación, log-MAP.

Trabaja con aritmética en el dominio logarítmico; con lo que los productos se transforman en sumas, las sumas se pueden calcular mediante el Logaritmo Jacobiano:

ln exe y = max x , y ln 1e−∣y−x∣

Dicho logaritmo se encuentra implementado como una instrucción de la CLU en el TigerSHARC:

TMAX a ,b = max a ,bln 1e−∣b−a∣


El segundo término se calcula por tabla:

ln 1e−∣b−a∣

Ejemplos de uso la función TMAX (celosía máxima): Sintaxis:

{X|Y|XY}{S}TRsd = TMAX(TRmd + Rmq_h, TRnd + Rmq_l) {(NF)} ;{X|Y|XY}{S}TRsd = TMAX(TRmd - Rmq_h, TRnd - Rmq_l) {(NF)} ;{X|Y|XY}{S}Rs = TMAX(TRm, TRn) {(NF)} ;

Código:

XYTR1:0 = TMAX(TR3:2 + R3:2, TR5:4 + R1:0) ;XYTR1:0 = TMAX(TR3:2 - R7:6, TR5:4 - R5:4) ;XYR8 = TMAX(TR4, TR0) ;

En la figura 4-3, podemos ver el diagrama de flujo del primer ejemplo:

Figura 4-3: STRsd = TMAX(TRmd + Rmq_h, TRnd + Rmq_l)

4.2.2.Funciones de celosía (Trellis Function)

Las funciones celosía son utilizadas en los turbocodigos[4] y en los códigos Viterbi[5].Una forma de la función celosía puede ser: STRsd = MAX(TRmd + Rmq_h, TRnd + Rmq_l);.La parte alta de Rmq se suma a TRmd, la parte baja se suma a TRnd, y la función MAX, elige el valor máximo entre los dos resultados. Todo este proceso se ilustra en las figuras 4-5 y 4-6, la sintaxis y el código fuente se ve a continuación.

Sintaxis:

{X|Y|XY}{S}TRsd = MAX(TRmd + Rmq_h, TRnd + Rmq_l) {(NF)} ;{X|Y|XY}{S}TRsd = MAX(TRmd - Rmq_h, TRnd - Rmq_l) {(NF)} ;

Código:

XYTR1:0 = MAX(TR3:2 + R3:2, TR5:4 + R1:0) ;;XYTR1:0 = MAX(TR3:2 - R7:6, TR5:4 - R5:4) ;;


Figura 4-4: STRsd = MAX(TRmd + Rmq_h, TRnd + Rmq_l).

4.2.3.Funciones de dispersión (Despread Function)

Las funciones de dispersión se aplican al acceso múltiple por división de código[3] o CDMA (del inglés Code Division Multiple Access) es un término genérico para varios métodos de multiplexación o control de acceso al medio basados en la tecnología de espectro expandido.Una forma de la función dispersión puede ser: TRs += DESPREAD (Rmq, THRd);.El diagrama de flujo de la misma se puede apreciar en la figura 4-5:

Figura 4-5: TRs += DESPREAD (Rmq, THRd)

Sintaxis:

{X|Y|XY}TRs += DESPREAD (Rmq, THRd) ;{X|Y|XY}Rs = TRs, TRs = DESPREAD (Rmq, THRd) {(NF)} ; (dual op.){X|Y|XY}Rsd = TRsd, TRsd = DESPREAD (Rmq, THRd) {(NF)} ; (dual op.)


Código:

XYTR8 += DESPREAD (R7:4, THR1:0) ;;XYR8 = TR8, TR8 = DESPREAD (R7:4, THR1:0) ;;XYR1:0 = TR1:0, TR1:0 = DESPREAD (R7:4, THR1:0) ;;

Estas son solo algunas de las instrucciones que ésta particular unidad puede ejecutar; para un análisis más detallado de la misma se recomienda dirigirse al ADSP-TS201 TigerSHARC® Processor Programming Reference.Es importante mencionar que no todos lo procesadores TigerSHARC poseen ésta unidad dentro de sus bloques de cálculo.


5.Registros de los bloques de cálculo

Debido a que la ejecución de todas las instrucciones de cálculo del TigerSHARC depende de los formatos de los datos de entrada y salida, y dependen de si la instrucción se ejecuta en un bloque de procesamiento en ambos, es importante entender como utilizar los registros internos de los bloques. El TigerSHARC posee en cada uno de sus bloques de cálculo un conjunto de 32 registros de 32-bits (tamaño palabra) de propósito general para realizar transferencias de datos entre: bloques de cálculo, canales de datos y almacenamiento inmediato de los resultados. La figura 5-1 muestra la comunicación de datos entre unidades que proveen los registros.

Figura 5-1: conjuntos de registros de los bloques de cálculo X e Y.

Nota: En la figura 5-1, “H” se refiere a los 64-bits más significativos (127-64) y “L” a los 64-bits menos significativos (63-0).

En la figura 5-1 se muestra que los datos entrantes al conjunto de registros puede o no pasar por el buffer de alineación de datos (DAB). El DAB es una FIFO formada por 2 registros de palabra cuádruple (128-bits), el cuál alinea los datos que se reciben en forma desordenada desde la memoria. En los bloques de cálculo existen 2 tipos de registros:

Registros mapeados en memoria, XR31-0 y YR31-0. Registros No-mapeados en memoria.

Los primeros pueden ser accedidos por los dispositivos externos a través de los canales de datos por lo que son denominados: registros universales (Ureg). Los segundos son internos del bloque y no accesibles desde el exterior del bloque al que pertenecen; nos referiremos a ellos como registros de datos (Dreg). En sistemas de multiprocesamientos es particularmente beneficioso tener los registros internos mapeados en un lugar definido de memoria y accesibles a través del canal de datos.

Para poder desarrollar ejemplos fue necesario plantear un esquema de mapeo de registros comparativo entre un DSP SHARC y un procesador TigerSHARC, el cuál se presenta en la tabla 5-1, el mismo no es fijo, es solo un ejemplo de como podría hacerse:


Tabla 5-1: Esquema de mapeo de registros del DSP SHARC y procesador TigerSHARC.

Aclaración de la tabla: 5-1: P/R: Primary Registers, S/R: Secondary Registers, N/A: Not Applicable. La comilla simple (´) es utilizada para denotar el set de registros secundarios o alternativos[10].

El código escrito a continuación muestra como el DSP SHARC y el procesador TigerSHARC utilizan los registros primarios y secundarios, basados en el mapeo previamente visto:

// SHARC (ADSP-21xxx) // TigerSHARC (ADSP-TSxxx)

//PEx (Primary Regs.) // CBx r0 = 0x1234; xr0 = 0x1234;;r1 = 0x5678; xr1 = 0x5678;;

//PEx (Secondary Regs.) // No secondary registers Bit set MODE1 SRRFL; // xr31-16 are used instead nop; // No need to enable mode r0 = 0x1234; xr16 = 0x1234;;r1 = 0x5678; xr17 = 0x5678;;


6.Unidad aritmético-lógica orientada a enteros (IALU)

6.1.Descripción de la IALU

El TigerSHARC posee 2 unidades aritmético-lógica que trabajan únicamente con datos enteros, estas unidades reciben el nombre de IALUs. En general las IALUs tienen la misma funcionalidad que los DAGs (Data Addres Generators) en la arquitectura SHARC, pero además poseen otras funciones extra como operaciones lógico-matemáticas (suma, resta, desplazamiento aritmético y lógico, valor absoluto, valor mínimo o máximo, etc.). Cada IALU posee un juego de registros (32 registro de 32-bits) internos similares a los que tienen los bloques de cálculo y registros dedicados a la función de direccionamiento de buffers circulares.Las IALUs, poseen además, el control de los buffers de alineación de datos (DABs) para operaciones de acceso a memoria no-alineados. Para diferenciarlas nos referiremos de aquí en adelante como J-IALU y K-IALU.

Figura 6-1: IALUs, DABs.

Las operaciones con enteros son:

Suma y resta, con y sin carry/borrow. Desplazamiento aritmético a la derecha, desplazamiento lógico a la derecha y rotación. Operaciones lógicas: AND, AND NOT, NOT, OR, and XOR. Funciones: Valor absoluto, mínimo, máximo y comparación.

Asimismo las IALUs son las encargadas de realizar el direccionamiento de la memoria cuando se realiza alguna transferencia de datos entre la memoria y los registros del procesado. Las mismas trabajando en simultáneo direccionan 2 accesos a memoria (escritura/lectura). Las operaciones de carga, almacenado y transferencia de datos incluyen:

Direccionamiento directo e indirecto. Direccionamiento de buffers circulares. Direccionamientos de Bit reverse.

A diferencia de los DAGs, las IALUs están conectadas a todos los bloques de memoria interna (es decir que no hay limitaciones del tipo DM/PM) lo que les permite direccionar cualquier bloque. Los DAGs de la arquitectura SHARC tienen al igual que los elementos de procesamiento un set de registros secundarios


(a parte de los registros primarios), no así las IALUs que solo poseen un set de 32 registros de 32-bits (solo los primarios) por unidad (J y K), de los cuales 3 (y no 8 como en el caso de SHARC) cumplen las mismas funciones que los registros secundarios de los DAGs. Esto, sin embargo, no debería influir en la mayoría (si no en todas) de las solicitudes, porque no todos los demás registros disponibles(J/K19-12, J/K30-28) se utilizarán al mismo tiempo. A diferencia de los demás registros de las IALUs, J31 y K31 no pueden utilizarse como registros de propósito general.Los DAGs soportan carga y almacenaje de datos usando los canales PM y DM en la misma instrucción (por ejemplo: dm(i0,m0)=r0, f8=pm(i8,m8);). Asimismo las IALUs soportan el uso de ambas en paralelo; sin embargo, debido a que en el esquema de mapeo de registros utilizado en los ejemplos del presente informe hemos dedicando los registros CBx a Pex (CBy a Pey; recordemos que CBx e y son los registros internos de los bloques de cálculo), KALU y JALU, no pueden utilizarse en la misma instrucción para almacenar datos en CBx. Esto lo veremos más claro con un ejemplo:

//Parallel LOAD from memory-ALLOWED xr0 = [j4+j12]; xr1 = [k4+=k12];;

//Parallel STORE to memory-NOT ALLOWED [j4+=j12] = xr2; [k4+=k12] = xr3;;//Parallel STORE to memory-ALLOWED [j4+=j12] = xr2; [k4+=k12] = yr3;;

La segunda instrucción se traduce como una violación de recursos, ya que el número de puertos de salida requeridos de CBx (2 datos requieren de 2 puertos para salir al mismo tiempo), superan el máximo permitido (el conjunto de registros internos de cada bloque de procesamiento solo tiene 1 puerto de salida). En la tercera línea de código vemos el uso correcto de JALU y KALU en la misma instrucción. Esto no tiene por que ser siempre así!

Nota: Para los DSPs SHARC, las instrucciones paralelas están separadas por una coma “,” y el final de una línea de instrucción se denota por un punto y coma “;”. Para los procesadores TigerSHARC, un punto y coma “;” separa instrucciones paralelas y un doble punto y coma “;;” termina una línea de instrucción.

6.2.Direccionamiento directo e indirecto

El direccionamiento directo utiliza el índice en 0 y un valor inmediato para el modificador. La siguiente es una instrucción que carga un valor de la memoria (ubicado en la dirección: 0x00015F00) en el registro YR1 del bloque “Y” de procesamiento:

YR1 = [J31 + 0x00015F00] ;;/* Nota: J31 siempre que se use como uno de los operandos debe contener el valor “0”*/

El direccionamiento indirecto utiliza cualquiera de los registros de la IALU como índice y otro registro o un valor inmediato como modificador. En la figura 6-x podemos apreciar los 2 tipos de direccionamiento indirecto, el pre-modificado y el pos-modificado.

Figura 6-2: Direccionamiento indirecto pre-modificado y pos-modificado.


A modo comparativo se presenta un ejemplo de código de éste direccionamiento en dos tipos de arquitectura de DSP:

// SHARC (ADSP-21xxx) // TigerSHARC (ADSP-TSxxx) //Setting up registers // Setting up registers r0 = 0x1234; xr0 = 0x1234;;r1 = 0x5678; xr1 = 0x5678;;i0 = source_buffer1; j4 = source_buffer1;;m0 = 1; j12 = 1;;i8 = source_buffer2; k4 = source_buffer2;;m8 = 1; k12 = 1;;

// Post-modify DAG1 operation //Post-modify JALU operation dm(i0, m0)= r0; [j4 +=j12]=xr0;;// Pre-modify DAG2 operation //Pre-modify KALU operation pm(m8, i8)= r1; [k4 + k12]=xr1;;// Parallel DAG1 & DAG2 LOAD // Parallel JALU & KALU LOAD r0=dm(i0, m0), r1=pm(i8, m8); xr0=[j4 +=j12]; xr1=[k4 += k12];;// Parallel DAG1 & DAG2 STORE // Parallel JALU & KALU STORE dm(i0, m0)= r0, pm(i8, m8)= r1; [j4 +=j12]=xr0;; [k4 +=k12]=xr1;;

6.3.Acceso a memoria Normal, Broadcast y Fusionado

La IALU utiliza el direccionamiento directo o indirecto para realizar lecturas y escrituras a memoria o a los registros. Hay 3 tipos de accesos a memoria: lectura/escritura normal, lectura/escritura fusionada y carga por broadcast. Estos 3 tipos de accesos difieren en lo siguiente:

Lectura/escritura Normal, lee o escribe datos en registro universales (Ureg). Este tipo de acceso lee o escribe 1, 2 o 4 palabras de 32-bits necesarios para la lectura/escritura del registro fuente/destino indicado en la instrucción. Dichos accesos se producen solo cuando los tamaños de los registros fuente y destino coinciden.

El acceso Broadcast, lee datos de memoria y los carga en los registros de los bloques de cálculo. En este modo de acceso se leen datos de 1, 2 o 4 palabras (32-bits) y se cargan en el registro destino de ambos bloques. El acceso Broadcast ocurre cuando el tamaño del registro fuente coincide con el tamaño del operador de acceso de la IALU y el nombre del registro destino es XY (o ningún prefijo), para indicar ambos bloques de cálculo.

El acceso Fusión de lectura/escritura, lee o escribe datos en los registros de datos de los bloques de cálculo. Las transferencias de datos de éste tipo son de tamaño de dobles (64-bits) o cuádruples (128-bits) palabras. La transferencia se realiza entre la memoria y los registros de datos de ambos bloques, donde los datos son divididos entre X e Y. Si una palabra larga (64-bits) es leída de la memoria, una palabra (32-bits) es cargada en el bloque X y la otra en el Y. Si una palabra cuádruple (128-bits) es leída de la memoria, 2 palabras son cargadas en el bloque X y las otras 2 en el Y. Este acceso puede trabajar en ambas direcciones (lectura o escritura) y el orden entre X e Y se puede cambiar utilizando los prefijos XY o YX. En el caso de XY la parte alta del dato transferido (palabra alta para el caso de palabra larga o las 2 palabras más significativas para el caso de la palabra cuádruple) se carga en registros X y la parte baja en registros Y, y al revés para el caso YX.

Figura 6-3: Datos contenidos en la memoria para los ejemplos de accesos normal, fusión y broadcast.


Ejemplos de accesos a memoria:

/*Acceso a memoria Normal, de datos de 32-bits*/

XRs = [Jm += Jn] ;; /* Jm = dirección de word 0.*//*word 0 es almacenada en XRs*/

/*Acceso a memoria Broadcast, de datos de 32-bits*/

XYRs = [Jm += Jn] ;; /* Jm = dirección de word 0.*//*word 0 es almacenada en XRs y en YRs*/

/*Acceso a memoria Fusión, de datos de 32-bits*/

XYRs = L [Jm += Jn] ;; /* Jm = address of word 0.*//*word 0 es almacenada en YRs y word 1 en XRs*/

YXRs = L [Jm += Jn] ;; /* Jm = address of word 0.*//*word 0 es almacenada en XRs y word 1 en YRs*/

Comparación entre los códigos de un DSP SHARC y un procesador TigerSHARC para el acceso Broadcast:

//SHARC (ADSP-21xxx) //TigerSHARC (ADSP-TSxxx)

//Broadcast Loading Mode //Broadcast Load Bit Set MODE1 BDCST1; //Broadcast not a mode ->no need to enable nop; //Specified by register names r2=dm(i1,m1); /*Load r2 with 0xC*/ r2=[j5+=j13];; //Load xr2 with 0xC //Load s2 with 0xC //Load yr2 with 0xC

6.4.Buffer de alineación de datos(DAB)

Cada bloque de procesamiento tiene asociado un DAB (X-DAB y Y-DAB), para acceder a datos no alineados en la memoria. Usando estos buffers, los programas pueden realizar un acceso de lectura de memoria de una palabra cuádruple (128-bits) no-alineada para cargarla en los registros de datos cuádruples(RSQ). Sin no se utilizara el DAB o SDAB, las instrucciones de carga de registros dobles o cuádruples requerirían una alineación previa. Una forma de entender como operan los DABs es comparar los accesos a datos alineados con los accesos a datos no-alineados; la figura 6-4 muestra un ejemplo de ambos.

Figura 6-4: ejemplo de instrucción con los datos alineados (Izq.) y no-alineados (Der.).


Los accesos utilizando los DABs deben entenderse como repetidas series de accesos a memoria, por medio de direccionamiento para buffer circular o direccionamiento lineal. Esto requiere una primera lectura para clarear el DAB de los datos anteriores y cargar los primeros datos correctos de la serie antes de que el DAB esté listo para repetidos accesos. El DAB determina automáticamente la palabra cuádruple más cercana del índice de direcciones y lee de memoria, la palabra cuádruple correcta a cargar en el DAB. Como los DAB establecen automáticamente un direccionamiento del tipo buffer circular es necesario establecer los valores correctos de los registro implementados por dicho direccionamiento (índice, base, longitud y modificador) antes de comenzar el acceso a través de los DABs. Por ello, las instrucciones del DAB solo deben utilizar los registros de la IALU que están destinados al direccionamiento de buffers circulares.

6.5.Direccionamiento de buffer circular

Como ya se mencionó las IALUs soportan direccionamiento de buffers circulares. Este direccionamiento se utiliza cuando se tiene un sector (un rango de direcciones) de memoria solicitado continuamente (Nota: La “Programming Reference” llama a ese rango de direcciones “Modulo fashion”). Las instrucciones de lectura y escritura utilizan el operador “CB” para seleccionar éste direccionamiento. Las instrucciones de la IALU de lectura/escritura de buffer circular difieren de las instrucciones estándar de lectura/escritura en el método que utilizan para calcular el direccionamiento pos-modificado. Las instrucciones estándar simplemente suman el incremento a la dirección actual para generar la próxima dirección; en las de buffer circular el incremento es igual al rango de direcciones del sector de memoria accedido. La fórmula de cálculo de las direcciones es la misma para el direccionamiento de buffer circular que para el direccionamiento lineal, suponiendo que, el valor LONGITUD es igual a 0 y el valor BASE es igual a la dirección de la base del buffer. Cada buffer circular tiene asociados 4 valores: BASE, LONGITUD, INDICE, y MODIFICADOR.

El siguiente pseudo-código muestra el cálculo de la dirección:

INDEX = INDEX + MODIFYif ( INDEX >= (BASE + LENGTH) )

INDEX = INDEX - LENGTHif ( INDEX < BASE)

INDEX = INDEX + LENGTH

Ejemplo de direccionamiento de búfer circular en el procesador TigerSHARC:

JB0 = 0x100000 ;; /* Set base address */JL0 = 11 ;; /* Set length of buffer */J0 = 0x100000 ;; /* Set location of first address */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100000 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100004 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100008 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100001 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100005 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100009 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100002 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100006 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x10000A */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100003 */XR0 = CB [J0 += 4] ;; /* Loads from address 0x100007 */XR0 = CB [J0 += 4] ;; /* wrap to load from 0x100000 again */


Figura 6-5: Diagrama del ejemplo de direccionamiento de búfer circular.

Comparación entre los códigos de un DSP SHARC y un procesador TigerSHARC para realizar un direccionamiento de buffer circular:

//SHARC (ADSP-21xxx) //TigerSHARC (ADSP-TSxxx)

bit set mode1 CBUFEN; // Enabled in TigerSHARC by // Enable circular mode (2116x only) // using “CB”

r1 = 0x1234; xr1 = 0x1234;;r2 = 0x5678; xr2 = 0x5678;;B0 = output; /*Base for buffer*/ jB0 = output;; //Base for buffer I0 = b0; /*initialize index*/ j0 = jB0;; //initialize index L0 = 3; /*length circular*/ jL0 = 3;; //Length of buffer M0 = 1; /*Modifier*/ j12 = 1;; //Modifier

dm(i0,m0)=r1; /*i0=buffer(top)*/ CB[j0+=j12] = xr1;; //j0=buffer(top) dm(i0,m0)=r1; /*i0=buffer+1*/ CB[j0+=j12] = xr1;; //j0=buffer+1 dm(i0,m0)=r1; /*i0=buffer+2*/ CB[j0+=j12] = xr1;; //j0=buffer+2 dm(i0,m0)=r2; /*i0=buffer(top)*/ CB[j0+=j12] = xr2;; //j0=buffer(top)

6.6.Direccionamiento Bit Reverse

Las IALUs soportan el direccionamiento bit reverse a través del operador (BR). Cuando este operador se utiliza en un, acceso indirecto pos-modificado de lectura/escritura, el bit de carry se acarrea a la derecha (en ves de a la izquierda como es en las operaciones aritméticas normales) en el cálculo de la pos-modificación.

Figura 6-6: acarreo del bit de carry en la operación Bit Reverse (opción BR).


La figura 6-6 es un ejemplo de la forma de acarreo en la operación bit reverse. Para una suma normal el resultado de 0xA5A5 + 0x2121, es 0xB6B6, pero para una operación de acarreo bit reverse el resultado es 0x9494. Al igual que con el direccionamiento de buffer circular, el bit reverse se realiza utilizando solo los registros J3–J0 o K3–K0; no así con los registros base y longitud, ya que éstos no necesitan ser seteados para el bit reverse. En las operaciones bit reverse no hay overflow.

Figura 6-7: Direccionamiento Bit Reverse del código ejemplo - Orden de las palabras del acceso.

Ejemplo de direccionamiento bit reverse, en el procesador TigerSHARC:

#define N 8 /* N = 8; number of bit reverse locations; N must be a power of 2 */.section data1;.align N;/* align the input buffer’s start to an address that is a multiple of N; assume * for this example that the address is 0x1000 0000 0000 0000 */.var input[N]={0,1,2,3,4,5,6,7};.var output[N];

.section program;

_main:j0 = j31 + ADDRESS(input) ;; /* Input pointer */j4 = j31 + ADDRESS(output) ;; /* Output pointer */LC0 = N ;; /* Set up loop counter */_my_loop:xr0 = BR [J0 += N/2] ;; /* Data read with bit reverse; modifier must be equal to N/2 */if NLC0E, jump _my_loop ; [j4+=1] = xr0 ;; /* Write linear */


6.7.Direccionamiento en las operaciones SISD y SIMD

Se verá en la presente sección en que se diferencia el DSP SHARC del procesador TigerSHARC en el direccionamiento de las operaciones SISD y SIMD. Ya sea en SISD como en SIMD el DSP SHARC coloca, a través de los DAGs, la misma dirección en los canales. En el modo SIMD, la memoria y los elementos de procesamiento obtienen los datos de la ubicación dada en forma explícita en la sintaxis de la función y ubicaciones complementarias dadas en forma implícita. Esto es diferente en los procesadores TigerSHARC, ya que en los mismos, SIMD ya no es un modo del procesador sino que la operación SIMD es controlada a nivel instrucción; especificando “x” a la parte de la instrucción que será realizada por CBx, e “y” la parte que será realizada por Cby. Usando "xy" o "yx" realizamos una operación en ambos bloques. El orden en que “x” e “Y” se especifican indica el camino que los datos seguirán cuando sean movidos entre la memoria y los bloques; por ejemplo, especificando “xy” ( puede ser: xyR0 ) se mueve la parte baja de los datos a o desde CBy y la parte alta a o desde CBx. Especificando “yx” ( puede ser: yxR0 ) se invierten el destino/fuente de las partes alta y baja. Cuando ni “x” ni “y” preceden al nombre del registro (ej.: R0) la transferencia de datos se llevará a cabo de alguna de las 2 formas siguientes: de la misma manera que cuando se especifica “xy”; o el mismo dato se lee/escribe desde/en ambos bloques, CBx y CBy. Esto depende del número de registros especificados como origen/destino, así como de la longitud de los datos que se transfieren. Mover el mismo dato desde/hacia ambos bloque de procesamiento es el equivalente al modo Broadcast de los DSPs SHARC ADSP-2116x.

Comparación entre los códigos de un DSP SHARC y un procesador TigerSHARC:

// SHARC (ADSP-2116x) //TigerSHARC (ADSP-TSxxx)

I1=buffer; /*Buffer={0xA,0xB,0xC,0xD}*/ j5=buffer;; //Buffer={0xA,0xB,0xC,0xD} M1=2; j13=2;;

//SISD //SISD r0=dm(i1,0); /*r0 loaded with 0xA*/ xr0=[j5+j31];; //xr0 loaded with 0xA //SIMD //SIMD Bit Set MODE1 PEYEN; //SIMD not a mode ->no need to enable nop; // Enable SIMD mode //Specified by register names r1=dm(i1,m1); /*Load r1 with 0xA*/ yxr1=L[j5+=j13];; //Load xr1 with 0xA //Load s1 with 0xB //Load yr1 with 0xB

Nota: Estos ejemplos están basados en el esquema de mapeo de registros visto en la sección 5 (registros de los bloques de cálculo), tabla 5-1.

Como puede verse en el ejemplo anterior, el código “r0=dm(i1,0);” en SHARC es lo mismo que “xr0=[j5+j31];;” en TigerSHARC, donde J31 es siempre igual a “0” cuando se lo utiliza como operando. Otra cosa para notar es que el SHARC siempre realiza movimientos con datos de 64-bits (r0 = dm (i1, m1);modo SIMD habilitado), en cambio en el TigerSHARC la longitud del dato deberá ser especificada con la letra “L” cuando se trate de palabras de 64-bits. Esto se traduce en tener una palabra de 64-bits cargada dentro de los registros “x” (32-bits, parte baja) e “y” (32-bit, parte alta), según lo especificado por la instrucción (yxr1 = L [j5 + J13];;). Si el prefijo “L” no se agrega en la instrucción, la misma palabra de 32-bits (palabra normal de 32-bits es el modo por defecto) es cargada en los registros “x” e “y”; y esto como ya es sabido es el modo Broadcast del TigerSHARC.


7.Secuenciador de programa

7.1.Introducción al secuenciador de programa

El núcleo del procesador TigerSHARC posee un secuenciador de programa el cuál es el encargado de administrar la ejecución de los programas. El mismo cuenta con un buffer de alineación de instrucciones (IAB), un contador de programa (PC), un buffer de destino de saltos (BTB), un administrador de interrupciones, y un mecanismo de búsqueda de direcciones (Addres Fetch). El secuenciador busca las instrucciones en la memoria, y extrae una línea de instrucción (128-bits) por ciclo; identifica en que unidad/es debe ejecutarse cada una de las instrucciones contenidas en la línea (recordemos que es un VLIW, con lo que tenemos varias instrucciones paralelizables en una misma línea de código), y luego las envía a su correspondiente unidad/es. El secuenciador es también el encargado de controlar el flujo de las instrucciones y monitorea los requerimientos de parada de los programas. Las operaciones que soporta el secuenciador incluyen:

Suministrar la dirección de la próxima palabra cuádruple de instrucción para cargar el buffer de alineación de instrucciones (IAB).

Extraer la próxima línea de instrucción a ser ejecutada del “IAB”. Controlar de flujo de las instrucciones, lo cuál incluye:

Evaluar las condiciones. Mantener el buffer de destino de salto(BTB). Decrementar contadores de lazos.

Vaciar el pipeline cuando se requiere. Responder a las interrupciones.

Figura 7-1: Diagrama en bloques donde se identifica el secuenciador de programa y sus elementos internos.


El “addres fetch” y el “PC”, son elementos típicos y conocidos, los que se verán en más detalle son:

Buffer de destino de saltos (BTB). Realiza una caché de las direcciones de saltos para reducir el costo de pipeline que tiene los saltos predichos.

Buffer de alineación de instrucciones (IAB). Recibe la línea de instrucción de 128-bits (palabra cuádruple), la alinea de ser necesario y envía las instrucciones que contiene a los bloques de cálculo, IALUs y secuenciador de programa.

Pipeline de 8 o 10 etapas dependiendo el modelo de TigerSHARC.

Figura 7-2: Diagrama en bloques detallado del secuenciador.

7.2.Pipeline

7.2.1.Introducción al pipeline

Para realizar una ejecución más rápida el TigerSHARC utiliza un pipeline de instrucciones de 8 o 10 etapas (El SHARC solo tenía 3 etapas). El procesador busca una palabra cuádruple de memoria (que consiste en 1 a 4 instrucciones), las analiza, decodifica y ejecuta. La figura 7-3 muestra el pipeline y como éste interactúa con el BTB, el IAB y el pipeline de memoria.

Figura 7-3: Pipeline de instrucciones, IAB, BTB Vs. pipeline de memoria.

Una línea de instrucción requiere 8 o 10 ciclos para recorrer de principio a fin el pipeline. El rendimiento es de una ejecución de una línea de instrucción por cada ciclo de reloj (CCLK) del procesador. Como se


puede ver el pipeline de memoria trabaja paralelamente al pipeline de instrucciones, a tal punto que paradas en los ciclos de dirección o de registro (address cycle y register cycle) provocan paradas en los correspondientes ciclos del pipeline de instrucciones (más información en: Efectos sobre el pipeline de las dependencias y los recursos, sección 7.2.2).

7.2.2.Operación del pipeline de instrucciones

Para entender mejor el flujo de las instrucciones a través del pipeline y el tiempo que requiere cada etapa se presenta la figura 7-4.

Figura 7-4: Temporizado del pipeline de instrucciones.

Nótese en la figura, el orden en que los resultados de una operación están disponibles. Puede verse que las operaciones con la IALU se ejecutan en la fase (pipe) “Integer ALU”, mientras que las operaciones con los bloque de procesamiento se ejecutan en la “compute block”, con lo que los resultados de la IALU pueden estar disponibles antes que los de los bloques de cálculo, dependiendo del orden y tipo de funciones. Las primeras cuatro etapas del pipeline (F1, F2, F3 y F4) son llamadas fase “fetch unit” (llamaremos Fase a lo que en la figura llaman Pipe). Los ciclos de búsqueda son los primeros del pipeline y están vinculados a los accesos a memoria. Los progresos en esta etapa son manejados por la memoria y no por la instrucción. La unidad de búsqueda llena el “IAB” mientras este tenga menos de 4 palabras palabras cuádruples. Dado que las unidades de ejecución pueden leer instrucciones a una velocidad igual o inferior a la capacidad de búsqueda de 4 palabras por ciclo, es poco probable que el IAB se vacíe. El IAB se puede llenar con un máximo de 6 palabras cuádruples. Cuando la búsqueda es en la memoria externa, el flujo es similar pero mucho más lento. El máximo rendimiento de la búsqueda es una línea de instrucción cada 2 ciclos SCLK y la latencia es de acuerdo con el diseño del sistema (profundidad del pipeline de memoria externa, ciclos de espera, etc.).Las siguientes 4 etapas del pipeline (predecode, decode, integer y access) se denominan fase “Integer ALU”. En el ciclo “PreDecode”, la siguiente línea completa de instrucción es extraída de la IALU y las diferentes instrucciones son distribuidas a las unidades de ejecución durante el ciclo “Decode”. Las unidades incluyen:

J-IALU or K-IALU - instrucciones con enteros, lectura/escritura y transferencias de registros. bloques de cálculo X o Y o ambos - 2 instrucciones (el cambio entre bloques es realizado por el

conjunto de registros. Secuenciador de programa – saltos e instrucciones condicionales, y otros.


El IAB también calcula el PC de las líneas de instrucción secuenciales y de algunas no secuenciales. El IAB no realiza ninguna decodificación. Luego de la etapa “Decode”, las instrucciones entran en la etapa “Integer” donde son ejecutadas las instrucciones que trabajan con las IALUs las cuales incluyen, cálculo de datos o direccionamientos y, opcionalmente, acceso a memoria. Si una instrucción de éste tipo incluye un acceso a memoria, es el bloque de memoria el que lo solicita en la etapa “Integer”, lo cual retrasa la operación hasta que el bloque está disponible para la IALU. El resultado de cálculo de direcciones se obtiene en la etapa “Integer”. Dado que la ejecución en la IALU puede ser abortada (ya sea a causa de un salto condicional o predicho), el operando es retornado al registro destino solo al final de EX2. El resultado pasa a través del pipeline en la que puede extraerse por una nueva instrucción en caso de que se requiera como fuente para un operando. La dependencia entre los cálculos de la IALU, normalmente no causa ningún retraso, pero existen excepciones. Los datos que están cargados son leídos recién en la etapa EX2. La última fase del pipeline se denomina fase “compute block”. En la etapa “Decode”, el bloque de procesamiento toma la instrucción y la transfiere a la unidad de ejecución que le corresponde. En la etapa “Integer”, la instrucción es decodificada en la unidad de ejecución y se chequean las dependencias. En la etapa “Access”, los registros fuente son seleccionados en el archivo de registros interno del bloque. En las etapas “EX1” y “EX2”, los resultados son calculados y las banderas son actualizadas en el bloque correspondiente. La ejecución toma siempre 2 ciclos y el resultado se escribe en el registro destino en el flanco de subida del CCLK luego de la etapa “EX2”. Todos los resultados se escriben en el registro destino y todas las banderas se actualizan en la etapa “EX2”. Esta regla tiene solo 2 excepciones:

accesos a memoria externa, donde la demora la determina el sistema. Instrucción Multiplicar-Sumar, que escribe los registros MR y las “sticky flags” un ciclo después

de “EX2” (Esta forma de escritura es útil para mantener la coherencia en caso de que se quiebre del pipeline).

7.2.3.Efectos sobre el pipeline de las dependencias y los recursos

El TigerSHARC puede ejecutar cualquier secuencia de instrucciones siempre y cuando entre las mismas no ocurran:

Dependencias. Conflictos de recursos.

Una condición de dependencia es causada cuando una instrucción requiere del resultado de una instrucción anterior. Por lo cuál ambas instrucciones deben ejecutarse en tiempos distintos.Un conflicto de recursos puede darse cuando dos instrucciones intentan usar el mismo bus interno u otro recurso (DMA, etc.), cuyo número es limitado, al mismo tiempo. El secuenciador de programa al encontrarse con un problema de éste tipo responde colocando ciclos de espera “stall” en el pipeline. En la “Programming Reference” del TigerSHARC se encuentra una tabla de dependencias útil para el programador.

7.3.Caché de instrucciones y buffer de destino de saltos(BTB)

7.3.1.Introducción al BTB y comparación con la caché del SHARC

La arquitectura SHARC posee una caché de instrucciones que permite que se pueda buscar una instrucción y acceder a un dato de la memoria de programa de manera simultánea. Esto ya no es necesario en la arquitectura TigerSHARC debido a que posee el número suficiente de bloques de memoria y canales para poder realizar una búsqueda de instrucción y 2 accesos a datos de manera simultánea. Ahora bien, el TigerSHARC sigue poseyendo una caché pero su uso es distinto. Es sabido que el TigerSHARC puede lograr una alta velocidad de ejecución debido a su pipeline de 8 a 10 etapas (dependiendo el modelo). Sin embargo cuando una instrucción de salto se ejecuta el mismo debe vaciarse, con lo que la nueva instrucción debe recorrer todo el pipeline antes de poder ser ejecutada. Esto provoca una espera de entre 3 y 6 ciclos. El uso del BTB puede reducir ésta espera a 0. El BTB es una caché asociativa de 4-vías para instrucciones de salto; éstas incluyen: retorno de interrupciones, retorno de llamadas, e instrucciones de saltos computados (computed jump instructions). Básicamente es una FIFO de 128 entradas; cada entrada en el BTB tiene un campo para la etiqueta y uno para el


destino (TARGET). En el campo de la etiqueta se almacena la dirección cuádruple (recordemos que de la memoria se traen 4 palabras de instrucción simultáneamente, y una o mas de ellas puede ser un salto) de la línea de instrucción que contiene el salto. En el campo de destino se almacena la dirección a la que el secuenciador de programa deberá ir, si se realiza el salto.

Figura 7-5: Estructura del BTB.

Como puede apreciarse en la figura 7-5, el BTB tiene, a parte de los 2 campos ya vistos, otros que también describiremos a continuación:

Index: El “Índice” determina la entrada del BTB seleccionada. El mismo se encuentra en los bits 6-2 de la dirección de la instrucción de salto.

Tag: La “Etiqueta” determina si la instrucción recientemente buscada es un salto ya almacenado o no en el BTB. Esto es resuelto luego de una comparación entre ambas. La entrada Tag del BTB grava los bits 20-7 y 1-0 de la dirección de la última instrucción de salto, de la última línea de instrucción.

Target: El “Destino”, es la dirección destino del salto. Cuando se lee una instrucción de salto y el mismo está almacenado en el BTB, el PC busca la dirección a la cuál saltar en la entrada Target del BTB.

Valid: El bit de “Validez” indica cuando una entrada es válida (1) o inválida (0). CJMP: Indica cuando el salto es un CJMP (salto computado[2.Pág. 8-19]) (1) o no (0). RTI: Indica cuando el salto es un RTI (retorno de interrupción) (1) o no (0). ABS: Indica cuando el salto usa dirección absoluta (1) o relativa (0). Lock: Bloquea (1) o desbloquea (0) una entrada. LRU: Campo menos utilizado; indica que campo puede sobrescribirse en caso de tener todas las

entradas llenas y se necesite agregar un nueva entrada.

7.3.2.¿Como se ahorra ciclos con el BTB?

La primera ves que se da la condición y el salto ocurre, el BTB no tendrá ninguna entrada para el mismo, por lo tanto una nueva entrada se coloca, con el valor del PC en el campo de la etiqueta. Esto tendrá un costo de 2 ciclos; sin embargo, cada vez que el mismo salto ocurra, el valor del PC va a coincidir con el de la etiqueta. Al ver la coincidencia, el secuenciador, en vez de tomar la siguiente instrucción de la secuencia que venía realizando, tomará la instrucción correspondiente a la dirección que tiene almacenada en el campo destino, comenzando a partir de allí una nueva secuencia. Con lo que el pipeline comenzará a cargarse con las instrucciones correctas para continuar luego de realizado el salto, entonces la pérdida de ciclos se reduce a 0.


7.3.3.¿Cuando es conveniente el uso del BTB?

El BTB tiene la capacidad de identificar anticipadamente cuando hay un salto en el código a ejecutar, lo que no puede, es saber si la condición va a ser verdadera o no, eso se determina recién cuando la instrucción es decodificada; por lo que debemos aplicar predicción de flujo de programa. La predicción de flujo es un método predeterminado de la instrucción de salto. Sin embargo uno puede especificar un salto que se preve que no ocurra. Esto es especialmente útil para saltos condicionales en que la condición es más probable que sea falsa a que sea verdadera (Saltos no-predecidos, no actualizan el BTB). Ejemplos de código de saltos predichos y no-predichos:

/* Salto condicional basado en el resultado del bloque de procesamiento X el resultado debe ser igual a 0 */If xaeq, jump label;;

/* Salto condicional con predicción basado en el resultado del bloque X el resultado debe ser igual a 0 */If xaeq, jump label (P);;

/* Salto condicional con no-predicción basado en el resultado del bloque X el resultado debe ser igual a 0 */If xaeq, jump label (NP);;

En el primer ejemplo no se colocó la opción al final de la instrucción. Por defecto será predecido (se tomará como que la condición es verdadera). El segundo también será predecido. El último se tratará como no-predicho (se toma como que la condición para el salto es falsa por defecto). Por ejemplo si el programa entra en un lazo cuya condición de salto es siempre verdadera, tendremos una pérdida de 2 ciclos en la primer pasada del lazo y no tendremos pérdida de ciclos en las restantes. Sin la implementación del BTB tendríamos 3 a 6 ciclos por pasada. Ahora si en cambio tenemos un laso cuya condición se da que la primera vez es cierta pero las restantes es falsa, el salto será predicho siempre, con lo que tendremos que cada ves que el salto no sea realizado (condición falsa) tendremos una pérdida de 3 a 6 ciclos por ves. Es por ello que cuando se sabe que un salto no se tomará de manera continua, se puede escribir en el código como no predicho “(NP)” (como se ve en el tercer ejemplo de código visto). Los saltos no predichos no actualizan el BTB.

7.3.4.Sobre colocar más de un salto en una palabra cuádruple

Uno de los recaudos que se deben tener en cuenta en la utilización del BTB, es no poner 2 instrucciones de salto en la misma palabra cuádruple en memoria. El compilador emitirá una advertencia: -“Detected two instruction lines with predicted jumps ending within 4 words”-. Si piensa que esto puede estar ocurriendo. Para entender como evitar ésta situación debemos comprender como las instrucciones pasan de la memoria interna al núcleo. En cada ciclo el DSP haciendo uso de su bus de 128-bits toma 4 instrucciones de su memoria interna. La primera de estas 4 instrucciones siempre tiene una dirección una dirección múltiplo de 4.

Figura 7-6: Memoria de programa.


El TigerSHARC puede ejecutar 1 a 4 instrucciones de 1 línea de instrucción. Así mientras que 4 son las instrucciones que se cargan en el núcleo, en cada ciclo, no necesariamente, se ejecutan en la misma línea de instrucción. Para manejar esta situación, las instrucciones se guardan en una FIFO de 5 palabras, llamada, buffer de alineación de instrucciones (IAB). Es allí donde se alinean, en la línea de instrucción correspondiente como está definido en el código fuente. Por ejemplo, considere la estructura de código que se presenta a continuación:

Instr1;; Instr2; Instr3; Instr4; Instr5;; Instr6; Instr7;; Instr8;;

En el primer ciclo se obtiene de memoria las instrucciones 1, 2, 3 y 4. La primera línea de instrucción se puede ejecutar debido a que solo contienen la instrucción 1. La segunda línea de instrucción debe esperar la próxima carga desde memoria, ya que necesita la instrucción 5. Las instrucciones 2,3,4 y 5 están alineadas en una línea de instrucción en el IAB. En la carga de la instrucción 5 se cargaron también la 6, 7 y 8, con lo que las próximas líneas de instrucción pueden ejecutarse sin problema. Una ves entendido esto se puede ver como es que el funcionamiento del BTB se ve afectado si se colocan más de un salto en la misma línea de instrucción. La dirección que se almacena en el campo “TAG” solo pede ser de 1 línea de instrucción (un múltiplo de 4como: 0x0, 0x4, 0x8 ...). Por lo tanto si un salto ocurre en la instrucción 1, 2, 3 o 4; en “TAG” se almacena el valor 0x0, y si ocurre en la instrucción 5, 6, 7 u 8; en “TAG” se almacena el valor 0x4. Si la instrucción 1 y la 4 son salto el BTB no tiene la capacidad de discernir entre una y otra. El campo “TAG” almacena la dirección de la última palabra cuádruple (línea de instrucción) que contiene el salto. Por ejemplo:

Instr1;; Instr2; Instr3; Branch(Instr4); Instr5;; Instr6;;

Aquí el salto está en la instrucción 4, la misma está ubicada en la segunda línea de código; con lo que en el “TAG” se almacenará 0x4, aunque la dirección de dicha línea de instrucción sea 0x0. Esto es así, porque el secuenciador de programa debe cargar todas las instrucciones que se ejecutan en paralelo en la misma línea de instrucción (interna del secuenciador); entonces, como en el ejemplo las instrucciones 2, 3, 4 y 5 se ejecutan en paralelo, se debe traer de memoria la línea de instrucción 0x4 que contiene la instrucción 5, con lo que es ésta última dirección la que se carga en el campo “TAG” del BTB.Se verá a continuación otro ejemplo de conflicto con el BTB:

Branch(Instr2); Instr3; Instr4; Instr5;; Instr6; Branch(Instr7);

En éste caso el compilador nos dirá: warning “detected two instruction lines with predicted jumps within 4 words”. Esto es así porque la última instrucción de la primera línea tiene dirección 0x4 que es la misma dirección de la instrucción 7 (5,6,7 y 8 están en memoria en la misma línea). Esto se puede resolver sin agregar código extra, que retrase la operación, de la siguiente manera:

Branch(Instr2); Instr3; Instr4; Instr5;; Instr6; Branch(Instr7); Instr8; Instr9;;

Ahora el campo “TAG” tendrá cargado una salto en la dirección 0x4 y otro en la dirección 0x8 (que es la dirección de la línea de instrucción que contiene la instrucción 9).

7.4.Buffer de alineación de instrucciones(IAB)

El IAB es una FIFO de 6 palabras cuádruples. Cuando el secuenciador obtiene una línea de instrucción desde la memoria, la misma es escrita en el IAB inmediatamente después de la que se cargó en la búsqueda anterior. Si en el IAB hay una línea de de instrucción completa el secuenciador puede tomarla para su ejecución.


El IAB provee los siguientes servicios:

Hace las veces de buffer de entrada de la fase de búsqueda del pipeline. Mantiene la unidad de búsqueda independiente del resto del pipeline de instrucciones. Esta independencia le permite a la unidad de búsqueda continuar trabajando aún cuando otras etapas del pipeline están paradas.

Alinea las entradas (palabras cuádruples desalineadas) para preparar líneas completas de instrucción para su ejecución. Esta alineación garantiza que líneas completas de instrucción de 1 a 4 cuatro instrucciones se puedan ejecutar en paralelo. Las instrucciones son palabras de 32-bits, que se almacenan en memoria sin tener en cuenta la alineación de palabras cuádruples (128-bits) o la longitud de la línea de instrucción (1 a 4 instrucciones). Con lo que no hay desperdicio de espacio de memoria. Las instrucciones que se ejecutan en paralelo se determinan por el MSB del opcode de cada instrucción, el cuál indica si termina o no, una línea de instrucción.

Distribuye las instrucciones de la línea de instrucciones para su ejecución en las distintas unidades – IALUs, bloques de cálculo, y secuenciador.

Figura 7-7: Buffer de alineación de instrucciones.

A través de estos servicios, el IAB asegura la ejecución de toda una línea de instrucción sin tener que insertar ciclos de espera o tener que almacenar en memoria las líneas de instrucción alineadas.

7.5.Variaciones en el flujo de programa

El flujo de programa tanto en los DSP SHARC, como en los procesadores TigerSHARC es casi lineal. Sin embargo cuando el flujo deja de ser lineal cuando en el programa aparecen estructuras tales como:

Saltos. Bucles. Subrutinas. Interrupciones Ciclos de espera u ociosos.


Existe una clara diferencia en la manera en que una llamada es manejada por el secuenciador de programa de un SHARC y por el de un TigerSHARC; y a causa de que los TigerSHARC no poseen pila (stack). La dirección de retorno de la llamada (CALL),en cambio, se guarda en el registro CJMP. Por lo tanto, antes de realizar otra llamada (anidamiento), el registro deberá guardarse en memoria para que la dirección de retorno de la llamada anterior no se pierda. Asimismo, el retorno de una llamada, se realiza usando la instrucción “CJMP”; dicha instrucción es para el TigerSHARC lo que la instrucción “RTS” para el SHARC.

Una diferencia fundamental en los saltos, entre SHARC y TigerSHARC, es que el secuenciador de programa del TigerSHARC no admite los saltos demorados. Por lo tanto, para convertir un salto demorado (es decir, el CALL que tiene la etiqueta (db)), se mueven las 2 instrucciones que están inmediatamente después y se las coloca antes del salto. Sin embargo cuando se quiere convertir un salto condicional demorado (por ejemplo: IF EQ JUMP(PC, etiqueta) (db);), se copian las 2 instrucciones que están inmediatamente después del salto, y se coloca una copia de las mismas (sin borrar las mismas de su ubicación original) al comienzo de la dirección de destino del salto. Esto puede verse claramente en el siguiente ejemplo.

Ejemplo de salto demorado en SHARK y TigerSHARC:

// SHARC (ADSP-21xxx) // TigerSHARC (ADSP-TSxxx) IF LT jump (PC, 0x15) (DB); IF XALT, jump 0x15 (NP);;r0 = dm(i1,m1); xr0=[j5+=j13];;r1 = dm(i1,m1); xr1=[j5+=j13];;.... .... xr0=[j5+=j13];; //Jump destination xr1=[j5+=j13];;r3 = r0+r1; //Jump destination xr3 = r0+r1;;

// TigerSHARC preferred method IF XALT, jump label (NP);; xr0=[j5+=j13];; xr1=[j5+=j13];; .... label: xr0=[j5+=j13];; //Jump destination xr1=[j5+=j13];; xr3 = r0+r1;;

En el ejemplo anterior puede observarse el reordenamiento de instrucciones. En este ejemplo se tomó la decisión de no prever el salto. Nótese que la instrucción se reescribió de manera de seguir usando el salto relativo del PC (PC relative jump). Esto es muy probable que no funcione como se espera debido a las diferentes longitudes de línea de instrucción que el TigerSHARC requiere. Por ésta causa, se recomienda el uso de etiquetas para las direcciones relativas o absolutas en lugar del valor de PC, en toda instrucción que modifique el flujo del programa.

Tanto los SHARC como los TigerSHARC soportan la ejecución del bucle zero-overhead. El SHARC soporta el anidamiento de hasta 6 bucles usando los registros de soporte de bucle del secuenciador de programa. La configuración de un bucle requiere un registro contador de bucles, una instrucción para disminuir el contador y una instrucción condicional para terminar el bucle en el tiempo requerido. La diferencia fundamental en la configuración de un bucle, entre SHARC y TigerSHARC, es que los SHARC requieren el uso de una instrucción DO/UNTIL como la instrucción condicional. La instrucción que va inmediatamente después del DO/UNTIL es la primera del bucle, y la última está indicada por la etiqueta.

Ejemplo de bucle simple en SHARK y TigerSHARC:

// SHARC (ADSP-21xxx) // TigerSHARC (ADSP-TSxxx) LCNTR=N, DO loop UNTIL LCE; LC0=N;;F8=PASS F15, M8=I10; loop: xfr8=PASS r15; k12=k6;;F9=PASS F15, F0=DM(I0,M1); xfr9=PASS r15; xr0=[j4+=j13];;loop: F12=F0*F5, F4=PM(I8,M8); IF NLC0E,jump loop; xfr12=r0*r5; xr4=[k4+=k12];;


Ejemplo de bucles anidados en SHARK y TigerSHARC:

// SHARC (ADSP-21xxx) // TigerSHARC (ADSP-TSxxx) /******************************** Outerloop ***********************************/lcntr=N, do outerloop until lce; k4 = k31 + N;;i4=r2; outerloop: j8 = xr2;;i3=r12; j7 = xr12;;r8=dm(m5,i4); xr8 = [j17+j8];;r4=dm(m5,i3); xr4 = [j17+j7];;r8=r8*r4, i4=r2; xr8 = r8*r4; j8 = xr2;;dm(m5,i1)=r8; [j17+j5] = xr8;;i3=dm(-4,i6); j7 = [j10 + -4];;/******************************** innerloop1 ***********************************/lcntr=N, do innerloop1 until lce; LC0 = N;;r8=dm(m5,i1); innerloop1: xr8 = [j17+j5];;r4=dm(m5,i4); xr4 = [j17+j8];;r8=r8*r4, i5=i2; xr8 = r8*r4; j9 = xr2;;dm(m5,i3)=r8; [j17+j7] = xr8;/******************************** innerloop2 ***********************************/lcntr=N, do innerloop2 until lce; LC1 = N;;r8=dm(m5,i0); innerloop2: xr8 = [j17+j4];;r4=dm(m5,i1); xr4 = [j17+j5];;r8=r8*r4; xr8 = r8*r4;;innerloop2: dm(i5,m6)=r8; if NLC1E,jump innerloop2;[j9+=j18] = xr8;;/******************************* end innerloop2 **********************************/innerloop1: modify(i3,m6); if NLC0E, jump innerloop1; j7 = j7+j18;;/******************************* end innerloop1 **********************************/r12=r12+1, xr12 = r12+0x1;;modify(i1,m6); j5 = j5+j18; k4 = k4-1;;outerloop: r2=r2+1; if NKEQ, jump outerloop; xr2 = r2+1;;/******************************* end outerloop **********************************/

7.6.Interrupciones

Existen diferencias significativas entre la forma en que se realizan las interrupciones en el SHARC y en el TigerSHARC. El primer punto a señalar es el lugar donde se ubica el vector de interrupciones; en el TigerSHARC no se ubica en la memoria interna o externa como en el SHARC. El TigerSHARC tiene en el controlador de interrupciones unos registros dedicados al almacenamiento del vector de direcciones de interrupción. Este set de registros, conocido como tabla de vector de interrupciones ( IVT, del inglés), contiene 30 registros. En el SHARC sigue una secuencia de 5 pasos para procesar efectivamente una interrupción suponiendo que las mismas estén habilitadas:

1. Salida de la dirección del vector de interrupciones.2. Guardado del valor del PC actual en la pila de PC.3. Dependiendo de la interrupción que se halla producido, se guardan los registros ASTAT y MODE1

dentro de la pila de estado.4. Seteo del bit correspondiente en IRPTL.5. Modificación de IMASKP para que refleje el estado de anidamiento de interrupción actual.

El TigerSHARC maneja las interrupciones de manera distinta, esto depende de que si la interrupción es por hardware o una excepción de software. Para las interrupciones por hardware, suponiendo que estén habilitadas:

1. Seteo del bit correspondiente en ILATL/ILATH.2. Salida de la dirección de salto de la interrupción de IVT.3. Guardado del PC para el retorno de interrupción (RETI).4. A partir de la entrada en la rutina de servicio de interrupción (ISR), seteará los bit

correspondientes de PMASKL / PMASKH y el bit 29 de PMASKH para bloquear todas las interrupciones por hardware del ADSP-TS101. Para el ADSP-TS20x en lugar del bit 29 de PMASKH, seteo del bit 21 de SQSTAT para bloquear todas las interrupciones por hardware.


Para las excepciones de software, asumiendo que estén habilitadas:

1. Para el ADSP-TS101, seteo del bit correspondiente en ILATH. Para el ADSP-TS20x, seteo del bit correspondiente en SQSTAT.

2. Salida de la dirección de salto del vector de interrupciones.3. Guardado del PC actual para retornar (RETS).

Figura 7-8: Conexionado de las interrupciones y el Bus SOC.

Otra diferencia significativa entre las 2 arquitecturas es la forma en que se manejan las interrupciones anidadas. Como el TigerSHARC no tiene pila de PC y no salva los registros (no tiene pila de estado, status stack), éstas acciones necesarias para poder llevar a cabo interrupciones anidadas, se deben realizar en la misma ISR. No hay un bit de activación de anidamiento en el registro de control; por ésta causa, todas las interrupciones son desactivadas cuando se entra en la ISR, para poder así, salvar todos los registros en memoria (o en la “C run-time stack”). Esto incluye guardar los registros de retorno (RETI register). El hecho de no guardar el registro de retorno (RETI register) antes de permitir la anidación o reutilización de interrupciones se traducirá en una pérdida de la dirección de retorno. Las interrupciones en el TigerSHARC son anidadas o reutilizadas por la ejecución de instrucciones especiales. Para interrupciones anidadas se debe guardar el registro RETIB en memoria. Esta última acción trae aparejado lo siguiente:

1. Se salva el contenido de RETI en memoria. El actual contenido de RETI es la dirección de retorno de la interrupción.

2. En el ADSP-TS101, el bit 29 de PMASKH es clareado para permitir que una interrupción de mayor prioridad sea aceptada si ocurre. En el caso del ADSP-TS20x, es el bit 21 del registro SQSTAT el que es clareado.

Si la rutina de servicio de interrupción es para una interrupción no-anidada, los registros que se salvan en la pila al comienzo de la ISR son restaurados cuando se ejecuta la instrucción “RTI”, lo cuál vuelve el programa a su flujo normal. Si la interrupción es anidada, se debe, antes de restaurar los registros, desactivar nuevamente todas las interrupciones a fin de que no se corrompa ningún dato por alguna inclusión inoportuna de una interrupción de mayor prioridad en ese instante, y por consiguiente, que no se pierda la dirección de retorno. Esto se realiza trayendo el valor del registro RETIB del lugar de


memoria donde se halla guardado. Una vez que este registro es restaurado, no pueden ocurrir futuras interrupciones; esto permite la restauración segura de los valores de todos los registros. Para salir de la ISR se utiliza la instrucción “RTI”.

Las interrupciones reutilizables se habilitan en el TigerSHARC, usando la instrucción conversión a subrutina “RDS” [2] [10] (del inglés: reduce to subroutine). RDS no equivale a la instrucción RTS del SHARC. De manera similar a las interrupciones anidadas, se debe salvar el estado y cualquier registro que se requiera a la pila, incluyendo el registro “RETI”, antes de ejecutar la instrucción “RDS”. Para tener la seguridad de que al final de la ISR (que se ha reducido a una subrutina) se podrán restaurar todos los registros, incluyendo la dirección de retorno, todas las interrupciones deben deshabilitarse. Esto puede lograrse mediante un método similar al de las interrupciones anidadas, restaurando la dirección de retorno en el registro RETIB. Los registros de estado del procesador y cualquier otro registro guardado en la pila, puede ser recuperado de manera segura, antes del retorno de la ISR. Para retornar de una ISR que se ha reducido a nivel de subrutina, se debe ejecutar la instrucción RETI.

Para más detalles se recomienda ver la referencia de programa [2]; a continuación se presentaran algunas comparaciones de código entre el SHARK y el TigerSHARC, para distintos casos de interrupciones.

Ejemplo de interrupción por timer en SHARK y TigerSHARC; para mejorar la legibilidad del mismo se ha eliminado, para el caso del SHARC, gran parte de la tabla de vectores de interrupción. Junto con la conversión del código debe también recalcularse el TPERIOD para el TigerSHARC:

//SHARC (ADSP-21160) //TigerSHARC (ADSP-TS201) ....// Vector for status stack/loop // stack overflow or PC stack full: ___lib_SOVFI: NOP; NOP; RTI; RTI;

// Vector for high priority timer interrupt: ___lib_TMZHI: jump timerhi_isr; NOP; RTI; RTI;

// Vectors for external interrupts: ___lib_VIRPTI: NOP; NOP; RTI; RTI;

#include "def21160.h" #include "defTS201.h"

.GLOBAL start; .GLOBAL start;

.GLOBAL timerhi_isr; .GLOBAL timerhi_isr;

.SECTION/PM seg_pmco; .SECTION program;start: start: /* Set up interrupt vector table */ j0 = timerhi_isr;; IVTIMER0HP = j0;;

/*set TPERIOD to 0x1000 CCLK cycles*/ /*set to 0x1000 SOCCLK cycles*/

TPERIOD=0x1000; xr0 = 0x1000;; xr1 = 0x0;; TMRIN0L = xr0;; TMRIN0H = xr1;;

/******************** Enable high priority timer interrupt ***********************/BIT SET IMASK 0x10; xr0 = IMASKH;; xr0 = bset r0 by INT_TIMER0H_P;; IMASKH = xr0;;


/************************* Set global interrupt enable ***************************/BIT SET MODE1 0x1000; SQCTLST = SQCTL_GIE;;

/********************************* Enable TIMER **********************************/BIT SET MODE2 0x20; xr0 = INTCTL;; xr0 = bset r0 by INTCTL_TMR0RN_P;; INTCTL = xr0;;

/********************************* Endless loop **********************************/do_nothing: do_nothing:NOP; NOP;;NOP; NOP;;JUMP do_nothing; JUMP do_nothing;;

start.END: start.END:

/**************************** Interrupt Service Routine **************************/timerhi_isr: timerhi_isr:nop; nop;;nop; nop;;nop; nop;;nop; nop;;rti; rti(ABS)(NP);;

Ejemplo de comparación de código entre SHARK y TigerSHARC; en el mismo se muestra como se reutiliza una interrupción, el hecho de que la ISR ha sido reducida a una subrutina permite que puedan tenerse interrupciones de mayor y menor prioridad:

// SHARC (ADSP-21160) // TigerSHARC (ADSP-TS201) ....___lib_IRQ1I: NOP; NOP; RTI; RTI;

// The CI option allows for the interrupt to occur again while being serviced ___lib_IRQ0I: jump irq0_isr(CI); NOP; RTI; RTI;#include "def21160.h" #include "defTS201.h"

.GLOBAL start; .GLOBAL start;

.GLOBAL irq0_isr; .GLOBAL irq0_isr;

.SECTION/PM seg_pmco; .SECTION program;start: start:

/* Set up interrupt vector table */ j0 = irq0_isr;; IVIRQ0 = j0;;

/************************* Set IRQ0 to edge sensitive ****************************/BIT SET MODE2 0x1; xr0 = INTCTL;; xr0 = bclr r0 by INTCTL_IRQ0_EDGE_P;; IMASKH = xr0;;

/**************************** Enable IRQ0 interrupt ******************************/BIT SET IMASK 0x100; xr0 = IMASKH;; xr0 = bset r0 by INT_IRQ0_P;; IMASKH = xr0;;

/************************* Set global interrupt enable ***************************/BIT SET MODE1 0x1000; SQCTLST = SQCTL_GIE;;

/********************************* Endless loop **********************************/


do_nothing: do_nothing:NOP; NOP;;NOP; NOP;;JUMP do_nothing; JUMP do_nothing;;

start.END: start.END:

/**************************** Interrupt Service Routine **************************/irq0_isr: irq0_isr:// Save any registers to stack // Perform any register saves to // stack first

//Save return address to stack [j27+=-4] = RETI;;

// Reduce to subroutine RDS;;

// Perform required operation here // Perform required operation here

// Disables all further interrupts and // restore return address from stack RETIB = [j27+0x4];; j27 = j27 + 4;; // Modify stack pointer

// Restore any registers from stack // Restore any other registers that // were saved to the stack here

// Return from interrupt and allow for // interrupts to occur again RTS(LR) RETI (ABS)(NP); [j27+=j31] = RETIB;;


8.Soporte para sistemas operativos

Como ya se mencionó el TigerSHARC soporta sistemas operativos; las características que se mencionan a continuación hacen esto posible.

8.1.Cambio de contexto

El ADSP-TS201 tiene la habilidad de salvar y/o recuperar de una pila en 2 bloques de memoria interna, más de 8 registros por ciclo de reloj. Esta capacidad de guardar/recuperar rápidamente, le permite al TigerSHARC atender de manera eficiente las interrupciones y realizar rápidos cambios de contexto (capacidad que habilita al TigerSHARC para soportar sistemas operativos multitarea)

8.2.Anidamiento de llamadas e interrupciones

Las direcciones de retorno de llamadas e interrupciones anidadas (junto con otros registros que son también necesarios), son guardadas por instrucciones específicas en la pila ubicada en la memoria interna del chip, permitiendo una mayor generalidad cuando se usan lenguajes de alto nivel. Interrupciones y llamadas no-anidadas, no necesitan salvar sus direcciones de retorno en la memoria interna, haciendo esto más eficiente para rutinas cortas no-anidadas.

8.3.Direccionamiento relativo

La mayoría de las instrucciones del procesador TigerSHARC, soportan saltos relativos de PC con lo que el código puede ser fácilmente reubicado. Además, la mayoría de las referencias de ubicación de datos son relativas, lo que significa que cualquier programa puede acceder a un bloque de datos ubicado en una dirección relativa a un registro base.


9.Bibliografía y Agradecimientos

9.1.Bibliografía

1. ADSP-TS201 TigerSHARC Processor Hardware Reference. Analog Devices, Inc.

2. ADSP-TS201 TigerSHARC Processor Programming Reference. Analog Devices, Inc.

3. De Wikipedia, la enciclopedia libre.

4. Codificación de Canal. Turbocodificación. Matilde Sánchez, Javier Ramos; Universidad Carlos III de Madrid.

5. Decodificador de Viterbi. Alberto Rodríguez García, Oscar Maroto Hernando. 5 de abril de 2003.

6. ADSP-TS20x TigerSHARC Processor Boot Loader Kernels Operation (EE-200), Analog Devices, Inc.

7. Considerations for porting code from the ADSP-TS101S TigerSHARC processor to the ADSP-TS201S TigerSHARC processor (EE-205), Analog Devices, Inc.

8. ADSP-TS201S TigerSHARC Embedded Processor Data Sheet. Analog Devices, Inc.

9. Explaining the Branch Target Buffer on the ADSP-TS101. Analog Devices, Inc.

10. SHARC DSPs to TigerSHARC Processors Code Porting Guide (EE-241). Analog Devices, Inc.

9.2.Agradecimientos

Al Altísimo Dios, Creador del cielo y de la tierra, fuente de toda sabiduría y conocimento, y mi inspiración. A mi profe de Técnicas Digitales III, Guillermo Friedrich, por su gran paciencia y por su colaboración para que este informe sea algo más que un mero traducir hojas de datos y referencias de hardware y software. A todos muchas pero muchas GRACIAS!!!

Dios les re bendiga!!!

arquitectura dsp tigersharc

Documents