universidad de castilla-la mancha escuela superior de...

$: UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE …arco.esi.uclm.es/public/pfc/fracisco.sanchez.pdf · 2010-10-19 · poseen unas restricciones de tiempo, coste, rendimiento$
UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMATICA

INGENIERIA

EN INFORMATICA

PROYECTO FIN DE CARRERA

“Integracion de transporte HW-SW mediante una arquitectura de

comunicaciones basada en un middleware”

Francisco Sanchez Molina

Septiembre, 2007

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMATICA

Arquitectura de Computadores

PROYECTO FIN DE CARRERA“Integracion de transporte HW-SW mediante una

arquitectura de comunicaciones basada en unmiddleware”

Autor: Francisco Sanchez Molina

Director: Fernando Rincon Calle

Septiembre, 2007

FECHA DE DEFENSA:

CALIFICACION:

Vocal Secretario

Fdo.: Fdo.:

Presidente

Fdo.:

Agradecimientos

Uff, como va pasando el tiempo, tan “solo” cinco anos han pasado desde aquel

primer dıa de presentacion, un dıa que recuerdo con especial ilusion “Oh, ¡¡la

universidad!!”. Una etapa que recordare con carino, las fiestas, cervezadas,

jueves, miercoles de cine, martes de... Aunque tambien ha habido algunos

momentos no tan buenos, miles de trabajos que entregar “para ayer”,

examenes... En fin, la vida de estudiante, pero se termino como todo o casi todo

en esta vida, ası que es tiempo de renovar fuerzas y abrir una nueva etapa.

En primer lugar querıa dar las gracias a Fernando, por ofrecerme la beca y poder

trabajar en el laboratorio, ademas muchas gracias por todo los detalles que has

tenido, y que sin ellos no habrıa terminado este proyecto.

A mis amigos, Alberto, que nos conocimos por aquella carpeta tan chula que me

hize (¿te acuerdas? si no... quiza ahora ni nos hablasemos, pero por suerte si la

lleve). Ramon el pequenın del A de las monjas, muchas gracias por estos anos de

companeros de piso... porque si no hubieses estado... mejor no pensarlo :)(ah, y

gracias por tus agradecimientos, que me estoy copiando de ellos, jaja). Erni,

cuantas botellas habremos dejado medio KO, ¡¡si es que el agua es muy sana y

entra muy bien!! Pablo por ser tan... tan.. ¿tan Pablo?, bueno eso y por preparar

esos viajes tan bien! Javi como decıa Ramon “el tipo mas duro a este lado de

Puertollano” y majo, y despistado... jeje , muchas gracias a todos.

Muchas gracias mis companeros del labo, David me alegro un monton de haberte

conocido amigo (el unico que te puede hacer ver que si estas mal... pues puedes

estar todavıa peor, jeje), Tobias, espero no tener que borrarte despues de

compartir piso... seguro que no, que siendo tan majo :), Javi y sus robotillos

(perdon por la encimera :P), Nacho y Peris, a vosotros no, que roncais mucho y

no me dejasteis dormir en ruidera. Cletuno, vaya viajante... a ti por echarte la foto

con la Pataky, te lo mereces. Tambien a Segio, Oscar, David, Gloria... a todos.

A todos los companeros de carrera, en especial a Javi (Zapatero) y Carlos, que

noches con ingenierıa ¿eh?, que gracia con Pedro3D y companıa. A Laurita (a

ver si encuentras tu sitio :)), muchas gracias por todo, tambien me alegro mucho

de haberte conocido amiga.

A mis padres, a los que les debo todo, si no fuese por ellos, por su dedicacion,

por su apoyo, por todo... no serıa ası. A mi hermana, la mas maja y guapa que

tengo (y la unica), jaja, bueno y aunque tuviese un millon. A mi abuela, mis tıos,

primas, a todos, muchas gracias a todos.

A ti, que estas leyendo y no te encuentras en la lista, no, no me he olvidado :),

MUCHAS GRACIAS POR ESTAR AHI.

Paco

Indice general

1. Introduccion 1

2. Objetivos del proyecto 9

3. Modelo de comunicacion 13

3.1. El modelo de invocacion de objetos distribuidos . . . . . . . . . . 14

3.2. El middleware de sistema . . . . . . . . . . . . . . . . . . . . . . 18

3.3. Invocacion HW-SW . . . . . . . . . . . . . . . . . . . . . . . . . 20

4. Arquitectura de la plataforma 23

4.1. La plataforma XUP . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2. MicroBlaze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1. FSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.2. OPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

I

4.3. PowerPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1. PLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4. Plataforma software . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . 32

5. Arquitectura de la solucion 37

5.1. Arquitectura del coprocesador . . . . . . . . . . . . . . . . . . . 41

5.1.1. Casos de uso del coprocesador . . . . . . . . . . . . . . . 41

5.1.2. Casos de uso de la capa software . . . . . . . . . . . . . . 46

5.1.3. Diagrama de bloques del coprocesador . . . . . . . . . . 49

5.2. Coprocesador en la plataforma MicroBlaze . . . . . . . . . . . . 49

5.3. Coprocesador en la plataforma PowerPC . . . . . . . . . . . . . . 51

5.4. Plataforma software . . . . . . . . . . . . . . . . . . . . . . . . . 53

6. Evidencia experimental 57

6.1. Verificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.1. Verificacion en MicroBlaze . . . . . . . . . . . . . . . . . 60

6.1.2. Verificacion en PowerPC . . . . . . . . . . . . . . . . . . 62

6.2. Test del prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.2.1. Caracterizacion del coprocesador para MicroBlaze . . . . 65

6.2.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2.3. Detalles de sıntesis . . . . . . . . . . . . . . . . . . . . . 68

6.2.4. Caracterizacion del coprocesador para PowerPC . . . . . 70

6.2.5. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . 70

6.2.6. Detalles de sıntesis . . . . . . . . . . . . . . . . . . . . . 71

6.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7. Anexo 75

7.1. Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.1. FSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.2. OPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.1.3. PLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.2. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.1. Coprocesador en MicroBlaze . . . . . . . . . . . . . . . . 83

7.2.2. Coprocesador en PowerPC . . . . . . . . . . . . . . . . . 86

7.3. Uso del coprocesador . . . . . . . . . . . . . . . . . . . . . . . . 89

7.3.1. Coprocesador en MicroBlaze . . . . . . . . . . . . . . . . 89

7.3.2. Coprocesador en PowerPC . . . . . . . . . . . . . . . . . 92

7.4. Prototipos desarrollados . . . . . . . . . . . . . . . . . . . . . . . 93

Indice de figuras

1.1. Modelo de coste . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Productividad vs Rendimiento . . . . . . . . . . . . . . . . . . . 2

3.1. Pasos de una llamada RPC . . . . . . . . . . . . . . . . . . . . . 16

3.2. Comunicacion asıncrona vs Comunicacion sıncrona . . . . . . . 18

3.3. Estructura de un mensaje . . . . . . . . . . . . . . . . . . . . . . 19

3.4. Espacio de memoria . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5. Esquema general de invocacion software. . . . . . . . . . . . . . 22

4.1. Arquitectura CoreConnect. . . . . . . . . . . . . . . . . . . . . . 24

4.2. Xilinx XC2VP30. . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3. Arquitectura del microprocesador MicroBlaze. . . . . . . . . . . 27

4.4. Arquitectura del microprocesador PowerPC. . . . . . . . . . . . 29

4.5. Modulos de Xilkernel. . . . . . . . . . . . . . . . . . . . . . . . 32

V

4.6. Xilinx Platform Studio. . . . . . . . . . . . . . . . . . . . . . . . 33

4.7. ChipScope capturado una rafaga PLB. . . . . . . . . . . . . . . . 35

5.1. Diagrama de casos de uso del coprocesador . . . . . . . . . . . . 41

5.2. Diagrama de casos de uso de la capa software . . . . . . . . . . . 46

5.3. Diagrama de bloques del coprocesador . . . . . . . . . . . . . . 49

5.4. Diagrama de bloques del coprocesador en OPB . . . . . . . . . . 51

5.5. Diagrama de bloques del coprocesador en PLB . . . . . . . . . . 52

5.6. Modulos de la capa software. . . . . . . . . . . . . . . . . . . . 55

6.1. Flujo de diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.2. Escenario de prueba. . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3. Tiempo en manejar una peticion en OPB. . . . . . . . . . . . . . 66

6.4. Tiempo envıo de software a hardware con el coprocesador. . . . . 67

6.5. Tiempo envıo de software a hardware sin usar el coprocesador. . . 67

6.6. Tiempo en manejar una peticion en PLB. . . . . . . . . . . . . . . 70

7.1. Lectura en FSL. . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.2. Escritura en FSL. . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.3. Escritura simple. . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.4. Lectura simple. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.5. Escritura con rafaga. . . . . . . . . . . . . . . . . . . . . . . . . 79

7.6. Lectura con rafaga. . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.7. Lectura simple. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.8. Diagrama de la maquina de estados ‘Envio HW→ SW’. . . . . . 84

7.9. Diagrama de la maquina de estados ‘Envio FSL’. . . . . . . . . . 85

7.10. Diagrama de la maquina de estados ‘Envio OPB’. . . . . . . . . . 86

7.11. Diagrama de la maquina de estados ‘Coprocesador’. . . . . . . . 87

7.12. Diagrama de la maquina de estados ‘Envio PLB’. . . . . . . . . . 88

7.13. Sistema basico de MicroBlaze con coprocesador. . . . . . . . . . 91

7.14. Sistema basico de PowerPC con coprocesador. . . . . . . . . . . 94

Indice de cuadros

5.1. CDU Transaccion . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2. CDU Almacenar transaccion . . . . . . . . . . . . . . . . . . . . 43

5.3. CDU Configurar objetos SW . . . . . . . . . . . . . . . . . . . . 44

5.4. CDU Transaccion a HW . . . . . . . . . . . . . . . . . . . . . . 44

5.5. CDU Recoger transaccion de HW . . . . . . . . . . . . . . . . . 45

5.6. CDU Registrar . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.7. CDU Transaccion a HW . . . . . . . . . . . . . . . . . . . . . . 47

5.8. CDU Aviso transaccion . . . . . . . . . . . . . . . . . . . . . . . 48

6.1. Caso de prueba Invocacion software-hardware . . . . . . . . . . . 60

6.2. Caso de prueba Configuracion del coprocesador . . . . . . . . . . 61

6.3. Caso de prueba Invocacion hardware-software . . . . . . . . . . . 61

6.4. Caso de prueba Invocacion software-hardware . . . . . . . . . . . 62

IX

6.5. Caso de prueba Configuracion del coprocesador . . . . . . . . . . 63

6.6. Caso de prueba Invocacion hardware-software . . . . . . . . . . . 63

6.7. Recursos del coprocesador en OPB. . . . . . . . . . . . . . . . . 68

6.8. Temporizacion del coprocesador en OPB. . . . . . . . . . . . . . 69

6.9. Recursos del coprocesador en PLB. . . . . . . . . . . . . . . . . 71

6.10. Temporizacion del coprocesador en PLB. . . . . . . . . . . . . . 72

1Introduccion

Los sistemas empotrados actuales se componen de elementos software y hard-

ware, resuelven tareas complejas como tratamiento multimedia, criptografıa, comu-

nicaciones, etc, para lo que necesitan de un mayor grado de paralelizacion. Ademas

poseen unas restricciones de tiempo, coste, rendimiento y consumo de energıa es-

trictas. Para conseguir recuperar la inversion realizada en el diseno de estos siste-

mas es de suma importancia llegar a tiempo al mercado, por lo que el desarrollo

de nuevas metodologıas y herramientas que permitan aumentar la productividad

del disenador es fundamental.

Tardar un tiempo menor en poner el producto en el mercado puede compensar

un sobregasto en el diseno, prototipado y costes de produccion. Un producto que

se situe mas tarde tendra perdidas, esto lo podemos ver en la figura 1.1, donde se

aprecian las diferencias en las ventas entre llegar o no a tiempo.

Conseguir que un diseno este finalizado a tiempo no es una tarea sencilla, ya

que el desarrollo de estos sistemas es un proceso complejo por distintos motivos.

Por un lado nos encontramos que los chips albergaran mas de un billon de tran-

sistores [1] logicas para 2010, apareciendo el problema conocido como “Desing

Gap”, que consiste en que la disposicion de esta cantidad de recursos utiles (de-

1

1. Introduccion

Figura 1.1: Modelo de coste

bido entre otras mejoras a las de los procesos de fabricacion) crece a un ritmo

mayor del que lo hace la productividad del desarrollador, por lo tanto estas me-

joras no terminan siendo aprovechadas de forma efectiva. Podemos observar esta

tendencia en la figura 1.2.

Figura 1.2: Productividad vs Rendimiento

Ademas de la complejidad en cuanto a numero de componentes, tambien nos

encontramos con dificultades en cuanto a la heterogeneidad de modelos de progra-

macion que se utilizaran en el diseno. Poco tiene que ver realizar un componente

que se ejecute sobre un microprocesador, con otro que se desarrolle en hardware

a la medida, aunque realicen la misma funcion.

La creacion de estos sistemas se realiza mediante tecnicas de codiseno [2],

2

1. Introduccion

que consisten en el diseno de la parte hardware y software del sistema de for-

ma concurrente y cooperativa. De forma clasica el codiseno se suele dividir en

distintas tareas, de las que se van pasando de unas a otras mediante la conocida

metodologıa en cascada. Estas tareas son:

1. Captura de requisitos con el cliente. Como cualquier metodologıa en casca-

da los primeros pasos son muy importantes, ya que si se descubre un error

en la captura de un requisito en una fase avanzada, realizar la correccion es

muy costoso.

2. Eleccion de la arquitectura donde se va a implementar el sistema. Esta elec-

cion se encuentra en una fase muy inicial, cuando todavıa no se tiene una

vision completa de la arquitectura de la aplicacion, y su decision marcara el

resto del proyecto.

3. Particionado, donde se decide que partes van a ir a hardware y cuales a

software.

4. Planificacion.

5. Sıntesis de comunicacion, en la que se decidira como se van a comunicar

todos los componentes.

6. Sıntesis de HW/SW, una vez terminados todos los pasos anteriores solo

queda implementar cada una de las partes.

Esta aproximacion de codiseno clasico tiene ciertas limitaciones:

El uso de requerimientos y restricciones escritas, que crea ambiguedad en

su interpretacion y complica la interaccion con el cliente, provocando un

mayor numero de iteraciones en la fase de diseno.

3

1. Introduccion

Falta de entornos colaborativos para poder desarrollar el codiseno.

No se realiza una exploracion en profundidad de toda la arquitectura.

No hay ayudas para realizar sistemas de tiempo real, o distribuidos.

Incapacidad para poder abordar SoC muy complejos.

Los disenos que usan esta metodologıa estan muy basados en la propia expe-

riencia del disenador, puesto que hay que realizar elecciones sin el conocimiento

completo de la arquitectura. Esta aproximacion limita la exploracion del espacio

de diseno para poder mejorar.

Una forma de mejorar la productividad consiste en la reutilizacion. Ası algunas

de las metodologıas de desarrollo actuales se centran en usar bloques conocidos

como IP (intellectual property)[3], convirtiendose el sistema en la interconexion

de bloques IP, que pueden ser suministrados por multitud de fuentes, siendo esta

aproximacion la idea del diseno basado en componentes. Ademas del factor de

reutilizacion, permite encapsular parte de diseno en una caja con una interfaz bien

definida, pudiendo dividir mejor la complejidad del sistema. En esta metodologıa

de diseno del sistema, mediante composicion, juega un papel crıtico la comuni-

cacion entre los diferentes componentes, convirtiendose en algo imprescindible

que esta sea lo mas eficiente posible. A pesar de representar una ventaja, y existir

un gran numero de IPs [4], suele ser difıcil poder encontrar los que se adapten

perfectamente a nuestro proyecto.

Otras tendencias actuales en el codiseno se dirigen al llamado codiseno basado

en plataformas. Esta metodologıa intenta eliminar el diseno del sistema desde el

inicio, mediante el uso de plataformas [2]. Esto limita la posibilidad de eleccion,

acelerando la puesta en el mercado del producto gracias a un reuso extensivo, a

costa de reducir flexibilidad y rendimiento comparado con metodologıas que se

4

1. Introduccion

ajustan completamente al problema. Este codiseno esta dirigido por el analisis,

se ayuda de diagramas UML donde el particionado y busqueda de plataforma se

realizan una vez se tiene una especificacion funcional.

Ademas de las metodologıas, las mejoras pueden venir tambien por parte de

los lenguajes de programacion usados en el desarrollo del sistema. Al igual que la

complejidad de los sistemas es mayor, los lenguajes han de proporcionar un mayor

nivel de abstraccion para poder abordar el desarrollo. Mientras que los lenguajes

tradicionales de descripcion de hardware son de muy bajo nivel, los lenguajes de

programacion estandar conllevan muchas ventajas para los disenadores:

Simplificacion del modelado, gracias a un mayor nivel de abstraccion.

Encapsulacion para facilitar la reutilizacion.

El comportamiento se pude compilar y ejecutar directamente.

Independiza de la arquitectura.

Los lenguajes mas utilizados en la actualidad son VHDL, Verilog y System-

Verilog, SystemC y Handel-C.

VHDL es de los lenguajes de descripcion de hardware mas usados para el diseno

de circuitos. Es un estandar IEEE (1076-1993 [6]) publico, con soporte para

el desarrollo, verificacion, sıntesis y pruebas de disenos hardware. Al ser

estandar independiza de los diferentes dispositivos de cada fabricante.

SystemVerilog es una extension de Verilog, que destaca por ser un lenguaje que

incluye descripcion y verificacion de hardware. Como novedades incluye

nuevos tipos de datos, orientacion a objetos y mejoras en el proceso de

verificacion.

5

1. Introduccion

SystemC esta compuesto por una serie de librerıas en C++, orientado a la des-

cripcion de sistemas.

Handel-C es un subconjunto de Ansi-C, sobre el que anade nueva funcionalidad,

permitiendo pasar algoritmos basados en C a Handel-C de forma rapida y

sencilla.

Por otro lado, en los desarrollos puramente software, la creacion de aplicacio-

nes distribuidas en sistemas heterogeneos es un problema antiguo, al que se le ha

dado solucion mediante el uso de middlewares [5]. Un middleware es un software

encargado de proveer de una serie de servicios que permiten al programador poder

abstraerse de la arquitectura de comunicaciones, de lenguajes de programacion,

sistemas operativos... para ası ofrecer la oportunidad de centrarse unicamente en

la funcionalidad de la aplicacion, en lugar de hacerlo en otros aspectos menos re-

levantes. La tendencia actual de programacion orientada a objetos ha provocado

que una parte de ellos evolucionen hacia esta metodologıa. Ası, estos sistemas

distribuidos estaran formados por objetos, que tendran una serie de metodos y

atributos. Lo que pretende el middleware es que no existe diferencia apreciable en

invocar un metodo de un objeto local a invocarlo de uno remoto. Esta ilusion se

crea usando un objeto con la misma interfaz del objeto al que se quiere invocar, y

este objeto sera el encargado de ponerse en contacto con el objeto real para invo-

carlo y recibir su respuesta. Esta ilusion tambien se crea en el objeto sirviente, que

es “envuelto” por una capa software, que se encarga de recibir las invocaciones

remotas y adaptarlas al objeto final, ası como ofrecer la respuesta.

Los sistemas en chip (SoC) tienen ciertas similitudes con los sistemas hete-

rogeneos distribuidos. Al igual que estos cuentan con un sistema de comunicacion

representado por los distintos buses, y elementos heterogeneos hardware y soft-

ware que deben interaccionar para resolver un problema mayor. Incluso pueden

6

1. Introduccion

llegar a estar conectados con otros SoC a traves de una red. Lo que interesa al

programador es poder separar la funcionalidad del objeto de los detalles de comu-

nicacion de cada bus, simplemente se deberıa apoyar en una capa que proporcione

la abstraccion necesaria.

Esto nos lleva a proponer un middleware de sistema, cuya finalidad principal

es la integracion de cualquier tipo de componente de forma transparente, tanto en

la forma de localizarlo (ubicacion), como en el tipo de implementacion Hw/Sw,

y esto sera posible proporcionando transparencia en la comunicacion entre dichos

componentes que formaran el sistema. Dentro del sistema apareceran tanto objetos

software como objetos hardware, dandose ası distintos tipos de comunicacion.

Una de ellas es la comunicacion entre elementos hardware y software, que sera la

que estudiaremos en profundidad, veremos los problemas que se plantean y las

correspondientes soluciones.

El documento esta estructurado en los siguientes capıtulos:

2. Presentaremos los objetivos que se esperan conseguir en este PFC para re-

solver el problema de la comunicacion entre componentes hardware y soft-

ware.

3. Se especificara el modelo de comunicaciones para todo el SoC, encuadrado

en los proyectos de investigacion SODA y MAR desarrollados en el grupo

de investigacion ArCo.

4. Arquitectura de la plataforma que se ha elegido para el desarrollo del pro-

yecto. Describiremos sus caracterısticas principales.

5. Arquitectura de la solucion desarrollada. Plantearemos los requisitos y de-

sarrollaremos cada una de las funcionalidades a implementar para obtener

los prototipos.

7

1. Introduccion

6. Evidencia experimental. Una vez desarrollado los prototipos, se realizaran

una serie de pruebas para comprobar la funcionalidad. Los resultados que

se obtengan de ellas nos llevaran a plantear las conclusiones de la solucion

aportada y si finalmente se cumplen los objetivos marcados.

7. Anexo, en el que se incluiran ciertos detalles de implementacion, de los

protocolos de comunicacion de los buses, ası de como una guıa de uso de

los prototipos obtenidos.

8

2Objetivos del proyecto

Una vez que hemos introducido el entorno de trabajo en el que se va a desarro-

llar este proyecto, marcaremos los objetivos que se esperan conseguir. Como se

comenta en la introduccion, nos vamos a centrar en la comunicacion entre cores

hardware y programas software, e intentaremos que esta comunicacion cumpla

tres caracterısticas muy importantes:

Transparencia: Implementar un mecanismo de comunicacion HW/SW transpa-

rente, teniendo en cuenta que se tendra que integrar en un modelo de comu-

nicacion de SoC desarrollado como parte del trabajo de investigacion del

grupo ArCo.

Solucion independiente de la plataforma: Entre todas las plataformas existen-

tes apareceran grandes diferencias, debido a los tipos de microprocesadores,

buses, perifericos... Ası, cada una de las plataformas tendra implementacio-

nes diferentes de la solucion, pero todas ellas compartiran un mismo mode-

lo, que se adaptara a las particularidades de cada una.

Rendimiento: No es deseable que la consecucion de los objetivos anteriores con-

lleve a una reduccion en las prestaciones del sistema, no hay que olvidar

9

2. Objetivos del proyecto

los requisitos en cuanto a rendimiento del tipo de aplicaciones a las que

esta destinado y que comentabamos en la introduccion.

Como vemos, los objetivos estan centrados en proporcionar al desarrollador

la mayor abstraccion posible. La transparencia nos permitira un funcionamiento

mas simple, los componentes no tienen por que ser conscientes de si el destino

es software o hardware, sobre todo porque en hardware es complicado realizar

la distincion, sin olvidar que la solucion no debe imponer una penalizacion en

tiempo.

No importa el tipo de plataforma que usemos, el modelo desarrollado podra ser

adaptado a cualquiera de ellas, puesto que en todas siempre encontraremos algun

mecanismo de comunicacion. Esta comunicacion entre cores hardware que dis-

pondra toda plataforma sera adaptada para lograr invocar un metodo software,

algo que consguiremos gracias a que es comun disponer de algun mecanimo para

que los perifericos puedan avisar al microprocesador de que poseen datos para el,

y por tanto poder ejectutar un programa que los trate.

La consecucion de todos los objetivos se lograra con la implementacion del

modelo que partimos, obteniendo ası una arquitectura de comunicaciones HW/-

SW integrada en las comunicaciones SoC. Esta arquitectura debera salvar el impe-

dimento de no poder invocar un metodo software desde hardware usando el mismo

modelo de comunicacion empleado entre dos objetos hardware, encontrandose la

solucion limitada en cuanto a que los procesadores no suelen poder recibir ningu-

na invocacion (cumplen en su mayorıa el rol de maestros del bus y no de esclavos).

Ademas esta arquitectura debera resolver las carencias de los microprocesa-

dores en cuanto a tipos de operaciones que pueden realizarse sobre los buses, con

el objetivo de mejorar el rendimiento con el uso de operaciones como las rafagas.

10


Para no alterar la comunicacion de los objetos hardware, disenaremos y desa-

rrollaremos un prototipo de los elementos necesarios para la arquitectura ideada.

11


12

3Modelo de comunicacion

Indice General3.1. El modelo de invocacion de objetos distribuidos . . . . . . 14

3.2. El middleware de sistema . . . . . . . . . . . . . . . . . . . 18

3.3. Invocacion HW-SW . . . . . . . . . . . . . . . . . . . . . . 20

13

3. Modelo de comunicacion

El modelo que se propone con el middleware de sistema es el resultado de

los proyectos SODA (Diseno de Sistemas Heterogeneos Complejos basados en

una Arquitectura de Objetos Distribuidos) [16] y MAR (Modelado Abstracto y

Reuso en el diseno de sistemas heterogeneos complejos) [17], desarrollados en el

grupo de investigacion ArCo perteneciente a las Escuela Superior de Informatica

de Ciudad Real.

Este middleware se basa en las ideas utilizadas en sistemas de objetos distri-

buidos software, ideas que extenderemos para cubrir el modelo de comunicacion

SoC.

3.1. El modelo de invocacion de objetos distribuidos

Antes de entrar en detalle del middleware de sistema, comenzaremos por defi-

nir los conceptos de middlewares software, para entender ası las decisiones toma-

das.

Comenzaremos con RPC, las siglas de Remote Procure Call. Consiste en si-

mular la llamada a metodos locales, produciendo la ejecucion del metodo de forma

remota. En este modelo existen dos procesos, cliente y servidor, el primero sera el

que realizara la llamada y se quedara esperando a que el segundo, el servidor, de-

vuelva la respuesta. Esta simulacion se realizara de forma transparente mediante

los adaptadores, creando la ilusion de estar programando un sistema centralizado.

Hay que tener en cuenta que este sistema es unas ordenes de magnitud mas lento

que una llamada local.

Para que el modelo RPC funcione, es necesario tener:

1. Una forma de llamar a un metodo concreto.

14


2. Una forma de relacionar una respuesta con un mensaje de peticion.

3. Sistema de autenticacion tanto para que cliente como servidor se conozcan

entre ellos.

4. Sistema de control de posibles errores.

Tıpicamente, cada llamada RPC se relaciona con un unico cliente y servidor,

pero tambien puede usarse para realizar un broadcast de llamadas, paso de men-

sajes o streaming.

RPC puede ser implementado en muchos protocolos de transporte, tıpicamente

en TCP/IP o incluso en buses de SoC como sera el caso de nuestro proyecto. Por

esto es importante que la aplicacion no trate de implementar nada relacionado con

el transporte, si no que se apoyara en una capa dependiente del tipo protocolo.

Como hemos visto, los clientes y servidores no deben implementar detalles del

protocolo de comunicaciones, si no que lo estara en una capa que denominaremos

adaptador. Por lo tanto, los adaptadores, no son mas que un programa software

que se encargara de la comunicacion entre el cliente y el servidor, para ofrecer

ası una abstraccion del sistema distribuido, como vemos en la figura 3.1. Nos

referiremos al adaptador en el cliente como proxy, e incluira todos los metodos

que ofrece el objeto servidor al que representa. Cuando uno de ellos se invoque,

el proxy se encargara de generar el mensaje de red y enviarlo al servidor. Por otro

lado, al adaptador nos referiremos como skeleton, y se encargara de recibir las

invocaciones de parte de los proxys, lanzar el metodo real, y devolver la respuesta.

Una vez visto los conceptos principales, enumeraremos los pasos tıpicos que

se producen en una llamada RPC y que podemos ver representados en la figura

3.1:

15


1. El programa cliente invoca un metodo del proxy.

2. El proxy agrupa todos los parametros en un mensaje (marshalling) y lo pone

en red.

3. El skeleton recibe el mensaje, desempaqueta los parametros (unmarsha-

lling) e invoca al metodo del servidor.

4. El skeleton recibe la respuesta del metodo y la empaqueta.

5. El skeleton envıa la respuesta por red.

6. El mensaje llega al proxy, lo desempaqueta y devuelve la respuesta a la

invocacion inicial.

Figura 3.1: Pasos de una llamada RPC

Una vez visto algunos conceptos basicos del middleware, pasaremos a exponer

una descripcion de los dos modelos de comunicacion posibles, el sıncrono y el

asıncrono:

Sıncrono: Este modelo destaca por su sencillez. En el el cliente realiza una invo-

cacion sobre el servidor y queda bloqueado en espera de que se produzca la

respuesta. Si el canal donde se produce la comunicacion solo permite una

16


conexion al mismo tiempo, como es nuestro caso con los buses de los SoC,

esto se convierte en un problema de ineficiencia por un lado e incluso puede

llegar a una situacion de interbloqueo. Es ineficaz porque una operacion de

larga duracion bloquearıa el sistema hasta que se completase, tiempo muer-

to que podrıa ser aprovechado para lanzar mas invocaciones.

Llegar a una situacion de interbloqueo cuando una operacion necesita de

otra intermedia para completarse, siendo imposible invocarla por estar el

bus bloqueado en espera de la primera.

Asıncrono: En esta ocasion, cuando el cliente realiza una invocacion sobre el

servidor, la conexion finalizara antes de que se produzca la respuesta, siendo

el servidor quien tome la iniciativa de responder al cliente cuando haya

finalizado. Como consecuencia inmediata vemos que el bus quedara libre en

el tiempo que transcurre la operacion, pudiendo realizar mas invocaciones.

El modelo asıncrono no implica realizar grandes cambios con respecto al

sıncrono cuando no sea necesaria una respuesta. Pero en aquellas que sı lo

sea, apareceran variaciones destinadas a ofrecer un mecanismo al rol de

servidor para que pueda responder al cliente.

Para ver de forma mas detallada las diferencias entre los dos modelos, plan-

teamos el escenario de la figura 3.2, donde disponemos de dos cores A y B.

A invocara una operacion de B, y este, despues de un tiempo, devolvera la

respuesta. A realizara la invocacion a B pasandole todos los parametros ne-

cesarios, y en ese momento el bus quedara libre. Cuando B termine la ope-

racion, entonces respondera a A con el resultado apropiado. El problema es

que una vez terminada la primera transaccion, la comunicacion quedara ce-

rrada, siendo B quien tomara la iniciativa de abrir una nueva comunicacion,

siendo necesario que conozca que A es el destinatario. Para ello, el propio

17


cliente, es el que le proporciona la direccion junto con los parametros que se

enviaron al inicio de la comunicacion. Este mecanismo es conocido como

callback.

Otra ventaja del modelo asıncrono es que permite simular el sıncrono. Esta

simulacion la realizaremos en los adaptadores, mas concretamente en el

proxy, en el que el objeto quedara bloqueado en espera de la respuesta.

Es decir, a nivel de cliente parecera que se ha realizado una invocacion

sıncrona, pero el proceso de comunicacion en realidad sera asıncrono.

Figura 3.2: Comunicacion asıncrona vs Comunicacion sıncrona

3.2. El middleware de sistema

Teniendo todo lo anterior en cuenta, nuestro middleware de sistema usara el

modelo asıncrono, que a pesar de anadir algo mas de complejidad, nos permite

mejorar en rendimiento y no nos limitara en ningun tipo de diseno. Ademas de

que el adaptador puede ofrecer al programador la ilusion de un modelo sıncrono.

18


En nuestro sistema, un objeto hardware sera un core que contara con un estado

definido por los atributos que contenga, y una interfaz sobre la que se realizaran

las invocaciones.

Ya conocemos algunos detalles del modelo de comunicacion, quedando por

definir como se invocara un metodo de la interfaz de un objeto. Para ello, todo

objeto contara con su propia direccion de memoria, o dicho de otra forma, un

espacio de direcciones asignado para el. Mediante este espacio, podremos selec-

cionar que metodo deseamos invocar entre todos los que cuente.

Estas invocaciones se traducen en mensajes enviados por los buses, y cuentan

con una estructura como la que podemos observar en la figura 3.3. En la zona de

la cabecera contaremos con una identificacion del objeto al que va destinado, una

identificacion del mensaje para poder hacer corresponder cual es la repuesta, un

contexto y una identificacion para elegir un metodo concreto. A continuacion de

la cabecera aparecen los datos, donde estaran empaquetados los parametros del

metodo que se invoque.

Figura 3.3: Estructura de un mensaje

El sistema completo lo podemos ver en la figura 3.4, donde mostramos el es-

pacio de memoria disponible, en el que encontramos un objeto con una cierta

direccion, en este caso 0x64000000, el cual cuenta con 12 bits para ser direc-

cionado. Se han decidido usar 4 bits de identificacion de mensaje, 8 bits para la

seleccion del metodo y otros 8 para indicar el callback. Es importante resaltar que

esta parte es de la que se debe encargar el middleware de sistema. El tamano de

los campos puede llegar a ser ajustado dependiendo de la aplicacion, sin que ello

19


Figura 3.4: Espacio de memoria

requiera ningun cambio en los objetos desarrollados, siendo los adaptadores, tanto

proxys como skeletons los que se encargaran de estos detalles.

3.3. Invocacion HW-SW

En nuestro sistema, invocar un objeto hardware y uno software son procesos

completamente distintos, entre otras diferencias, los objetos software no cuen-

tan con un espacio de memoria. Esto representa un problema para los objetos

hardware, que cuentan con una comunicacion bastante estricta y bien definida.

Por ello, tener objetos software que invocar, no tiene que implicar cambios en

el modelo de comunicacion de los objetos hardware. La solucion es que un core

hardware, preparado para entender esta comunicacion, sea capaz de atender las

llamadas dirigidas a software, formando un esquema como el que podemos ver en

la figura 3.5. Las tareas que tendra que realizar este core son:

Distinguir las invocaciones que tienen como destino un objeto software,

20


puesto que el es el unico que conocera los objetos software que existan y

que sea capaz de responder por ellos.

Responder por el objeto software que se invoque, es el unico que enten-

dera la comunicacion entre objetos hardware y que sea capaz de realizar la

adaptacion a objetos software.

Almacenar los datos de la peticion.

Avisar a la parte software que hay una invocacion esperando, las invoca-

ciones software tienen que terminar siendo ejecuciones de metodos, y por

ahora solo se encuentra almacenada, ası que avisaremos al microprocesador

para que ejecute el metodo apropiado.

Otro aspecto a considerar es el de la eficiencia de la comunicacion. En ese

sentido es necesario poder sacar partido de las posibilidades del sistema de comu-

nicacion, tales comolas rafagas, lo que nos proporciona invocaciones atomicas

cuando no todos los argumentos caben en una unica transferencia, o escrituras

de 64 bits si el bus lo permite. Pero no siempre disponemos de estas caracterısti-

cas mas avanzadas en los microprocesadores, convirtiendose en un problema de

comunicacion cuando queramos realizar invocaciones a objetos hardware desde

software. Por todo esto, se hace necesario que un dispositivo hardware adapte la

comunicacion, para que el microprocesador pueda interoperar con todos los obje-

tos y ademas lo haga sin perdida de rendimiento.

21


Figura 3.5: Esquema general de invocacion software.

22

4Arquitectura de la plataforma

Indice General4.1. La plataforma XUP . . . . . . . . . . . . . . . . . . . . . . 24

4.2. MicroBlaze . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1. FSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.2. OPB . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3. PowerPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1. PLB . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4. Plataforma software . . . . . . . . . . . . . . . . . . . . . . 30

4.5. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . 32

23

4. Arquitectura de la plataforma

4.1. La plataforma XUP

Para el desarrollo del proyecto, es necesario elegir una plataforma para realizar

el prototipado y verificacion de nuestro modelo. Finalmente nos hemos decantado

por la plataforma XUP, una solucion basada en un SoC de Xilinx, mas concre-

tamente el modelo Virtex-II Pro XC2VP30 que ofrece todas las caracterısticas

necesarias para abordar nuestro proyecto. Este SoC esta compuesto por una FP-

GA y dos microprocesadores PowerPC. Opcionalmente cuenta con la posibilidad

de usar softcores (microprocesadores programados sobre la FPGA) denominados

MicroBlaze. La plataforma XUP esta compuesta por una gran variedad de pe-

rifericos de entrada y salida que podemos ver en la figura 4.2. La solucion que

aportemos estara conectada a los buses, junto con el resto de objetos. Estos buses

con los que contamos pertenecen al estandar CoreConnect [18] de IBM, que faci-

lita la integracion y reuso del procesador y perifericos del SoC. En dicho estandar

se define la arquitectura que podemos ver en la imagen 4.1.

Figura 4.1: Arquitectura CoreConnect.

En el caso de PowerPC contamos con el bus PLB, que a diferencia de los

que encontramos en MicroBlaze, es de 64 bits. A pesar de ello, la version del

procesador PowerPC de la que disponemos, esta limitada a transferencias de un

24


Figura 4.2: Xilinx XC2VP30.

maximo de 32 bits. Mientras que en la plataforma MicroBlaze, los buses mas

apropiados que podemos utilizar debido a sus caracterısticas son FSL y OPB.

Las principales caracterısticas del modelo con el que trabajamos son:

Celdas logicas: Cuenta con un total de 30,816 celdas, cada celda se compone de

una tabla de memoria de 4 entradas, logica de acarreo y un flip-flop.

Slices: Posee 13,696 slices, donde cada 4 slices forman un CLB. Para tener una

idea de que se puede hacer con esta cantidad de slices, diremos que la can-

tidad necesaria para implementar el procesador MicroBlaze completo es de

1240 slice, lo que representa un 9 %.

Multiplicadores: 136 multiplicadores de 18x18 bits

25


IOB: Cuenta con un total de 556 conexiones configurables con el exterior.

Block SelectRAM+: 136 bloques de 18Kb.

Conexiones: Cuenta con una salida VGA, 3 conexiones SATA, una entrada et-

hernet, entradas y salidas de audio, puerto compact flash, conexion JTag,

entrada para raton y teclado, puerto serie, botones, leds, interruptores y por

utimo tres puertos de expansion.

4.2. MicroBlaze

Como hemos comentado anteriormente, este procesador no se encuentra fısi-

camente implementado en la placa, si no que es un desarrollo de Xilinx para FP-

GAs. MicroBlaze, por tanto, es un core de los que podemos instanciar hasta un

total de 8.

Posee un juego reducido de instrucciones (RISC), optimizado para su imple-

mentacion en FPGAs de Xilinx. Como podemos observar en la figura 4.3, cuenta

con un unidad aritmeticologica, 32 registros de 32 bits, y entre los buses mas

importantes cuenta con OPB y FSL.

Es muy configurable, en la figura 4.3 podemos ver como hay diferentes partes

opcionales sombreadas, que ofreceran un mayor rendimiento en ciertas operacio-

nes, a cambio de un mayor uso de recursos de la FPGA, o si se prescinden de ellas

quedara mayor espacio disponible para nuestros cores.

Este microprocesador no cuenta con una unidad MMU (Memory Management

Unit), lo que limita el sistema operativo que puede usar.

26


Figura 4.3: Arquitectura del microprocesador MicroBlaze.

4.2.1. FSL

FSL o Fast Simplex Link es un bus unidireccional punto a punto, es decir, un

enlace que comunica solo a dos dispositivos y en los que cada uno solo puede

tener un rol no intercambiable de maestro o esclavo. [10]

Algunas de sus caracterısticas mas importantes son:

Comunicacion unidireccional punto a punto.

Permite intercambios rapidos de informacion, sin espera, gracias a que no

es necesario el arbitraje al no existir recursos compartidos.

Cuenta con bits extra de control, que pueden ser usados con multiples proposi-

tos, como por ejemplo marcar comienzo y finalizacion de trama.

Contiene una FIFO configurable con una profundidad que va de 1K a 8K.

27


Y puede ser tanto sıncrona como asıncrona, permitiendo que los relojes de

maestro y esclavo puedan diferir.

4.2.2. OPB

On-Chip Peripheral Bus esta destinado a la interconexion de perifericos para

las FPGA Xilinx basadas en sistemas de procesadores embebidos. Esta construido

mediante un multiplexador distribuido y funciones AND en maestro y esclavo, y

funciones OR para combinar en un unico bus. [11]


Cuenta con un arbitro que se encarga de dar acceso al bus.

Soporte de hasta 16 maestros y cualquier numero de esclavos, aunque es

recomendable un maximo de 16.

Soporta todas las senales definidas en OPB V2.0 [11], a excepcion de aque-

llas necesarias para el soporte de DMA.

Soporte de entrada para reset por Watchdog.

4.3. PowerPC

La placa de desarrollo cuenta con dos PowerPC de 32 bits, de la version

PPC405. [8]

28


Figura 4.4: Arquitectura del microprocesador PowerPC.

29


4.3.1. PLB

PLB o Processor Local Bus es un bus avanzado de alto rendimiento tambien

perteneciente a la arquitectura CoreConnect. Se asocia a un bus llamado DCR

para acceso a registros de estado. [12]


Bus con acceso arbitrado de tres ciclos.

Soporte de hasta 16 maestros y mas de 16 esclavos.

Buses de datos para escrituras y lecturas separadas.

Soporte para cores de 32/64 bits proporcionando un ancho de banda de unos

800 MB/s.

Soporte de hasta 4 niveles de prioridad dinamica

Temporizador watchdog.

4.4. Plataforma software

Como complemento a la arquitectura descrita previamente, la plataforma soft-

ware que vamos a usar es un micro-kernel provisto por Xilinx, denominado Xil-

Kernel [9]. La motivacion principal de usar dicho kernel, ademas de proveer un

manejo de interrupciones mas sencillo, es porque ofrece soporte para el uso de hi-

los, que es un requisito practicamente indispensable en cuanto en nuestro sistema

aparezca mas de un objeto software, o incluso con un unico objeto, si este tiene

que ejecutar constantemente codigo, y ademas recibir interrupciones.

30


Ası, tenemos un planificador de tareas sencillo, encargado de la creacion o

destruccion de estas, ademas de una serie de servicios utiles como pueden ser el

sistema de ficheros, manejo del tiempo, peticiones de memoria...

Este microkernel cuenta con una serie de modulos, que forman la arquitectura

que podemos ver en la figura 4.5. A continuacion aparece la descripcion de cada

uno:

Planificador: Soporta dos tipos de esquemas, dirigido por prioridad o round-

robin. Se configura de forma estatica en la generacion del kernel y es global,

es decir, todos los hilos usaran el mismo planificador.

Temporizadores software.

Interrupciones y manejadores de excepciones: Xilkernel maneja de forma au-

tomatica las interrupciones de reloj, necesario para el funcionamiento de

los planificadores y control de tiempo. Ademas soporta multiples interrup-

ciones conectadas a traves de un controlador de interrupciones, pudiendo

funcionar con el core opb intc.

Manejadores de hilos: Ofrece el API de POSIX para hilos.

Semaforos: Posee soporte POSIX para semaforos, que pueden ser usados para la

sincronizacion. Tienen la capacidad de contar por debajo de cero, y ası saber

el numero de procesos bloqueados.

Colas de mensajes: Soporta colas de mensajes XSI (X/Open System Interface).

Pueden tener un tamano arbitrario de mensajes, y el numero de mensajes

y tamano total puede ser configurado durante la inicializacion del sistema.

Depende del modulo de semaforos.

31


Memoria compartida: Tambien soportado mediante XSI, los bloques de memo-

ria que se pidan en tiempo de ejecucion tienen que ser identificados y espe-

cificados durante la configuracion del sistema.

Gestion dinamica de buffers: Proporciona una interfaz alternativa a las estandar

de C (bufmalloc y buffree), optimizadas para ocupar menos y ser mas rapi-

das.

Figura 4.5: Modulos de Xilkernel.

4.5. Herramientas de desarrollo

Xilinx proporciona una serie de programas software para facilitar el diseno,

implementacion, generacion y analisis para sus placas FPGA’s. Estos programas

estan disponibles tanto para plataformas Windows como para GNU/Linux y SUN

Solaris. De todas las herramientas usadas, las principales han sido las siguientes:

EDK: Embedded Development Kit es un conjuto de herramientas y librerıas, des-

tinados al desarrollo de sistemas empotrados. Los componentes mas impor-

tantes que forman parte de EDK son XPS (Xilinx Platform Studio), con el

32


que se disena el sistema empotrado completo, catalogo de drivers, librerıas

y compiladores para los microprocesadores soportados. XPS nos facilita

la creacion de proyectos, posee una serie de asistentes para la creacion de

sistema, pudiendo elegir las distintas plataformas de las que disponemos y

seleccionando los componentes base iniciales. Despues otra serie de asis-

tentes tambien nos permiten desarrollar nuevos cores, agregarlos al diseno,

conectarlos a los buses y asignarles una direccion. Por ultimo XPS es ca-

paz de lanzar todos los procesos para generar el bitstream del proyecto y

descargarlo en la placa de desarrollo.

Figura 4.6: Xilinx Platform Studio.

ChipScope: Analizador logico integrado que permite obtener muestras de los

buses cuando la FPGA esta en funcionamiento.

33


Time Analyzer: Realiza un analisis de tiempo de nuestro diseno, una vez que

se haya completado la sıntesis. Nos resulta de gran utilidad para encontrar

ası los cuellos de botella del diseno, identificando los caminos crıticos para

intentar acortarlos. Cuanto mejor sea nuestro diseno (en cuanto a caminos

crıticos) menor sera el tiempo de rutado de conexiones, ya que se utiliza un

algoritmo de enfriamiento que intenta conseguir cumplir los requisitos de

tiempo.

Simulador VHDL/Verilog: Utilizado para la simulacion de los disenos. En siste-

mas con MicroBlaze tiene la capacidad de realizar una simulacion completa,

incluida la parte software, para PowerPC no se puede simular esta ultima. Al

igual que decıamos que mediante ChipScope no podemos inspeccionar “el

interior” de un componente, la simulacion si nos permite conocer el estado

de cualquier variable o senal en cualquier momento y de forma sencilla.

Core Generator: Herramienta para la generacion de cores configurables, y es-

pecialmente optimizados para la arquitectura concreta de la FPGA. Permite

generar, entre otros, bloques de memoria estatica, multiplicadores, transfor-

madores FFT, etc.

34


Figura 4.7: ChipScope capturado una rafaga PLB.

35


36

5Arquitectura de la solucion

Indice General5.1. Arquitectura del coprocesador . . . . . . . . . . . . . . . . 41

5.1.1. Casos de uso del coprocesador . . . . . . . . . . . . . 41

5.1.2. Casos de uso de la capa software . . . . . . . . . . . . 46

5.1.3. Diagrama de bloques del coprocesador . . . . . . . . 49

5.2. Coprocesador en la plataforma MicroBlaze . . . . . . . . . 49

5.3. Coprocesador en la plataforma PowerPC . . . . . . . . . . 51

5.4. Plataforma software . . . . . . . . . . . . . . . . . . . . . . 53

37

5. Arquitectura de la solucion

Para dar solucion al problema de la intercomunicacion entre objetos hardware

y software ofreciendo transparencia, independencia de la plataforma y mantenien-

do un rendimiento aceptable, se desarrollara por un lado una parte hardware que

denominaremos coprocesador y por otro un modelo de capa software que sera el

encargado de comunicarse con el coprocesador.

El coprocesador es un componente hecho a medida y especıfico para adaptarse

a las particularidades de cada una de las plataformas vistas anteriormente. Por ello

se hara un analisis de alto nivel sin entrar en detalle y despues trataremos cada una

de las implementaciones por separado.

Una de sus principales funcionalidades es atender todas las peticiones que se

produzcan en el bus al que este conectado, que tengan como destino un objeto soft-

ware. Todos los objetos hardware estan mapeados en un area de memoria, es decir,

una direccion de memoria representa un objeto. Utilizando un desplazamiento a

partir de esa direccion podremos elegir que metodo del objeto deseamos invo-

car. Si deseamos que los objetos hardware puedan comunicarse indistintamente

con otros objetos hardware o software, estos ultimos tendran que estar tambien

mapeados en memoria.

La dificultad viene dada por no poder hacer corresponder directamente a direc-

ciones de memoria los objetos software, los microprocesadores de los que dispo-

nemos solo pueden realizar el rol de maestro del bus y nunca de esclavos, ası que

no pueden atender ninguna invocacion de otro maestro. No queda otra solucion

que crear un dispositivo esclavo del bus que escuche las peticiones que se realicen

y capture las dirigidas a objetos software. Una vez capturada una peticion, segui-

mos sin poder enviarla directamente al microprocesador, siendo el quien tiene que

tomar la iniciativa a partir de alguna senal que le proporcionemos, y es aquı donde

entraran las interrupciones.

38


Concretando un poco mas el sistema, el coprocesador sera configurado pre-

viamente indicandole cuales son los objetos software disponibles, es decir, en

que direcciones se encuentran. Cada direccion que se le indique quedara alma-

cenada en un una memoria especial, direccionable por contenido. Esta memoria

esta directamente conectada al bus de direcciones, para que en cuanto se produzca

una coincidencia, la propia memoria, dispare una senal. Este disparo avisara al

coprocesador de que se tiene que hacer pasar por esclavo del objeto software al

que se esta invocando, y almacenar, en otra memoria, la peticion para poder ser-

virla finalmente. Esta memoria cuenta con una serie de senales para controlar su

estado. Nos sera especialmente util aquella que nos indica que deja de estar vacıa,

que sera la encargada de disparar una interrupcion hacia el microprocesador, in-

dicandole que debe tomar la iniciativa para recuperar los datos de una invocacion

a un objeto software.

El microprocesador disparara el manejador de interrupciones en respuesta al

aviso del coprocesador, y este realizara una lectura para obtener ası la informacion

necesaria, y lanzar el metodo software correspondiente. Entre la informacion que

se captura de la invocacion, permanece la direccion del objeto. Con ella podremos

saber a que objeto y metodo se esta invocando. Mientras se configura el coproce-

sador con las direcciones por las que tiene que responder, tambien crearemos una

tabla en software donde las direcciones de memoria nos devolveran punteros a las

funciones que se dispararan para tratar cada invocacion.

Otra funcionalidad que ofrece el coprocesador es la invocacion de software a

hardware. Realmente el microprocesador tiene la capacidad de realizar este tipo

de escrituras, puesto que como ya comentabamos anteriormente es maestro de

los buses, pero tanto por motivos de eficiencia, como de interoperabilidad en la

comunicacion, es necesaria la figura del coprocesador. Puesto que el rendimiento

es uno de los aspectos fundamentales a considerar, las invocaciones generalmente

39


se transmiten mediante rafagas, cosa que no es posible realizar desde el software

que se ejecuta en el microprocesador. Ademas, como sucede en el PPC405, puede

ser que el procesador y el bus del sistema utilicen anchos de palabra distintos, o

incluso no coincidan en los endianess con otros cores.

En la plataforma elegida contamos, como ya hemos visto, con dos tipos de mi-

croprocesadores que tendran cada uno de ellos una implementacion de coprocesa-

dor especıfica. En principio desarrollaremos una arquitectura generica teniendo en

cuenta la funcionalidad a requerida, y esta sera adaptada a las particularidades de

cada caso. De esta forma, la solucion es facilmente portable a otras plataformas.

En cuanto a la capa software, esta tendra que dar soporte para que los objetos

software se puedan registrar de forma comoda con sus metodos en el coprocesa-

dor, ademas de encargarse de lanzar dichos metodos una vez que se haya produ-

cido una invocacion desde hardware. Por otro lado, ofrecera soporte para invocar

los metodos hardware como si se tratasen de objetos software. Para esto serıa

conveniente que un generador automatico crease esta capa software de forma au-

tomatica, a partir de los ficheros de descripcion de los objetos hardware, ası como

de la definicion de los objetos software.

40


5.1. Arquitectura del coprocesador

Para describir con mayor detalle toda la funcionalidad y los pasos a desarrollar

para cada uno de los requisitos, usaremos los diagramas de casos de uso.

5.1.1. Casos de uso del coprocesador

En el diagrama de casos de uso de la figura 5.1 representamos la funcionalidad

que ofrece el coprocesador, despues pasaremos a describirla en detalle.

Figura 5.1: Diagrama de casos de uso del coprocesador

41


Nombre: Transaccion

Abstracto: No

Precondiciones: El coprocesador se encontrara ya configurado con los

objetos software que existan.

Flujo normal: 1. Un maestro conectado al bus realiza una invocacion

a un esclavo.

2. El coprocesador comprueba si la direccion se

corresponde con algun esclavo software.

3. La invocacion se realiza a un objeto software, y se

lanza el caso de uso almacenar transaccion.

Flujo alternativo: 1. Un maestro conectado al bus realiza una invocacion

a un esclavo.

2. El coprocesador comprueba si la direccion se

corresponde con algun esclavo software.

3. La invocacion se realiza a un objeto hardware, no

se realiza ninguna accion.

Descripcion: El coprocesador examina el destino de todas las

transacciones, si estan destinadas a software, se lan-

za el caso de uso de almacenar transaccion.

Cuadro 5.1: CDU Transaccion

42


Nombre: Almacenar transaccion

Abstracto: No

Precondiciones: Se ha realizado una transaccion con destino a un ob-

jeto software

Flujo normal: 1. El coprocesador responde e indica que el se va a

encargar de la transaccion.

2. El coprocesador almacena los datos de la transac-

cion en una memoria temporal.

3. El coprocesador avisa al procesador que hay una

nueva invocacion software pendiente.

Descripcion: El coprocesador se hace pasar por el objeto software

en cuestion, almacenando toda la informacion de la

transaccion sin procesar ningun dato, para que mas

tarde puedan ser tratados por el objeto correspondien-

te.

Cuadro 5.2: CDU Almacenar transaccion

43


Nombre: Configurar objetos SW

Abstracto: No

Precondiciones:

Flujo normal: 1. Un maestro del bus realiza una invocacion de con-

figuracion sobre el coprocesador.

2. El coprocesador lo reconoce y se dispone a obtener

los datos.

3. El maestro indica una direccion que correspon-

dera a un objeto software.

Descripcion: El coprocesador almacenara en una memoria la direc-

cion del objeto software por el que tiene que respon-

der.

Cuadro 5.3: CDU Configurar objetos SW

Nombre: Transaccion a HW

Abstracto: No

Precondiciones:

Flujo normal: 1. Un objeto software pedira al coprocesador que rea-

lice una invocacion

2. El objeto ira pasando los datos al coprocesador

3. El coprocesador ira almacenando los datos

4. El coprocesador realizara la transaccion al destino

Descripcion: El coprocesador almacenara en una memoria la invo-

cacion de un objeto software, para reenviarla por el

bus.

Cuadro 5.4: CDU Transaccion a HW

44


Nombre: Recoger transaccion de HW

Abstracto: No

Precondiciones: Se ha realizado una invocacion previa a un objeto

software, quedando almacenada en el coprocesador.

Flujo normal: 1. El procesador realizara una invocacion al coproce-

sador para obtener la transaccion.

2. El coprocesador respondera la peticion

3. El coprocesador descargara la memoria donde tenıa

almacenada la transaccion

Descripcion: El procesador obtiene del coprocesador la informa-

cion de la transaccion a un objeto software que se ha

realizado previamente.

Cuadro 5.5: CDU Recoger transaccion de HW

45


5.1.2. Casos de uso de la capa software

Una vez descritos los casos de uso que debe desarrollar el coprocesador, pa-

saremos a ver los necesarios para la capa software, mostrados en la figura 5.2 y

descritos a continuacion.

Figura 5.2: Diagrama de casos de uso de la capa software

46


Nombre: Registrar

Abstracto: No

Precondiciones:

Flujo normal: 1. El objeto software registra sus metodos mediante la

capa software

2. La capa software los almacena

3. La capa software se los comunica al coprocesador

Descripcion: La capa de software tendra que registrar los metodos

de los objetos software, para lanzarlos cuando se pro-

duzca una transaccion.

Cuadro 5.6: CDU Registrar

Nombre: Transaccion a HW

Abstracto: No

Precondiciones:

Flujo normal: 1. El objeto software lanzara un metodo

2. La transaccion se pasa al coprocesador mediante

una invocacion

Descripcion: La capa de software tendra que enviar la invocacion a

un objeto hardware a traves del coprocesador.

Cuadro 5.7: CDU Transaccion a HW

47


Nombre: Aviso transaccion

Abstracto: No

Precondiciones:

Flujo normal: 1. El coprocesador avisara de que existe una nueva

transaccion.

2. Se realiza una invocacion al coprocesador para re-

cuperar los datos.

Descripcion: La capa de software tendra que recuperar la invoca-

cion software a traves del coprocesador.

Cuadro 5.8: CDU Aviso transaccion

48


5.1.3. Diagrama de bloques del coprocesador

El diagrama de bloques teniendo en cuenta la funcionalidad que debe ofre-

cer el coprocesador, es el de la figura 5.3, donde vemos que hay cuatro bloques

principales unidos dos a dos mediante el uso de unas colas. La parte superior

esta destinada a las invocaciones de software a hardware mientras que la inferior

se encarga de la operacion contraria.

Figura 5.3: Diagrama de bloques del coprocesador

Este diseno modular y el uso de colas para desacoplar los tipos de buses facilita

posibles modificaciones.

5.2. Coprocesador en la plataforma MicroBlaze

En esta plataforma, en cuanto a los problemas de interoperabilidad que men-

cionabamos anteriormente, sufrimos la imposibilidad de producir rafagas desde

49


MicroBlaze, con la consiguiente degradacion de prestaciones debido al tiempo

perdido en el arbitraje del bus OPB (dos ciclos perdidos en el mejor de los casos

por cada transferencia). Ademas de que el objeto esclavo estara esperando una

rafaga en lugar de numerosas invocaciones hasta completar los datos.

Para tener una opcion mas eficiente, el coprocesador se conecta mediante el

bus FSL dedicado, con el fin de que el coprocesador pueda enviar todos los da-

tos por el bus OPB mediante rafagas. Para cuantificar el beneficio del uso del

bus FSL, describiremos un ejemplo de una invocacion en la que hay que trans-

ferir 1600 bits, el equivalente a 50 transacciones (el bus OPB es de 32 bits). Por

cada cada transaccion perderıamos 2 ciclos, sumando un total de 100 ciclos perdi-

dos, comparados con los 50 utiles empleado en la transferencia. Nuestra solucion

perderıa un ciclo que tarda FSL en realizar el envıo, mas otros dos de un unico

arbitraje, en total serıan 3 ciclos perdidos, por los 100 del metodo directo.

El coprocesador, como podemos ver en la figura 5.4, se compone de distintos

modulos interconectados, donde podemos ver claramente que aparecen dos partes

completamente independientes, ajustandose perfectamente al modelo general.

El envıo desde el microprocesador a los cores se realiza por el bus FSL, don-

de un modulo de recepcion se encargara de recibir los datos e inyectarlos en una

FIFO. Dicha FIFO esta conectada al modulo envioOPB, el cual comienza la trans-

mision cuando existan suficientes datos en la FIFO como para realizar la rafaga

sin perder ciclos.

La invocacion a objetos software, aunque es parecida, tiene algo mas de com-

plejidad debido a la aparicion del modulo CAM. Este modulo es una memoria

direccionable por contenido, y en la que permaneceran las direcciones de los ob-

jetos software por los que hay que responder. Esta conectado tanto al bus, para

saber en todo momento cual es la direccion de las invocaciones y ası poder avisar

50


Figura 5.4: Diagrama de bloques del coprocesador en OPB

si estan destinadas a objetos software, como al modulo HW2SW, para poder con-

figurar la propia memoria. Una vez que la CAM ha detectado que se ha realizado

una invocacion a un objeto software, la transaccion se recogera y pasara a la FIFO,

que a su vez, al no estar vacıa, disparara una interrupcion en el microprocesador,

que leera el contenido de la interrupcion mediante el bus FSL.

5.3. Coprocesador en la plataforma PowerPC

Las ventajas de la transferencia software a hardware con el uso del copro-

cesador estan orientadas a la interoperabilidad, ya que no contamos con un bus

dedicado al uso de coprocesadores como lo era FSL, y las escrituras realizadas

son de 32 bits. Ası, la funcionalidad que nos ofrece el coprocesador, es agrupar

los datos para convertirlo posteriormente en transacciones de 64 bits, y con la po-

51


sibilidad de rafagas, pero sin poder conseguir una mejora de rendimiento, pues los

datos llegan por el mismo bus, produciendo el efecto contrario, un mayor trafico.

Como podemos ver en la figura 5.5, el coprocesador para la plataforma PowerPC

es bastante diferente al de la plataforma de MicroBlaze, sobre todo debido a que

solo usamos un unico bus. En esta ocasion no aparece una clara distincion entre

el proceso de envio de software a hardware y el proceso de invocacion de objetos

software.

Una mejora al uso de este unico bus serıa realizar una segmentacion, usan-

do ası 2 buses PLB, manteniendo uno en uso casi exclusivo entre procesador y

coprocesador y otro entre el coprocesador y el resto del sistema. Esta solucion

requerirıa de un puente entre PLB, que no disponemos en la herramienta.

Figura 5.5: Diagrama de bloques del coprocesador en PLB

Los dos modulos principales de los que se compone este coprocesador son

el Proxy y Skeleton, encargados de la comunicacion con el bus. Dicho Proxy

52


se encarga unicamente del envıo de las transacciones de software a hardware,

esta conectado a una FIFO asimetrica, en el sentido de que sobre ella se realizan

escrituras de 32 bits (que es el ancho soportado por el PowerPc) y sus datos son

recogidos en transacciones de 64 bits formados por la composicion de dos datos.

El Skeleton en este caso tiene una complejidad mayor, ya que se encarga de

almacenar tanto las transacciones que recibe desde software con destino a hard-

ware, como las invocaciones a objetos software y por ultimo la configuracion de

los objetos software que hay en el sistema.

5.4. Plataforma software

Las llamadas a metodos en la parte software tampoco diferiran si el destino

esta situado en software o si lo esta en hardware. Ası tendremos los metodos

de los objetos hardware, que en realidad seran unos envoltorios preparados para

realizar la transferencia hardware requerida.

Ademas, los objetos que tengamos en software se deben registrar en el copro-

cesador para ası poder recibir las peticiones que provengan de hardware, es nece-

sario salvar en software que funcion se encargara de tratar la invocacion.

Toda esta capa se apoya sobre Xilkernel, de la que ya hablabamos en el capıtu-

lo de arquitectura de la plataforma. Gracias a ella podremos crear los hilos nece-

sarios ademas de contar con un tratamiento de interrupciones mas comodo.

Esta plataforma no es fija, es decir, el codigo depende de los objetos que for-

man el sistema, tanto software como hardware. Por esta razon, se hace necesaria

la figura del generador automatico, que permita al desarrollador abstraerse com-

pletamente de objetos hardware o software.

53


Por ultimo, la plataforma software se encuentra dividida en una serie de modu-

los que podemos ver en la figura 5.6. A continuacion detallaremos la funcionalidad

de cada modulo:

Gestion de comunicacion especıfico de la plataforma: Dependera de la cone-

xion que exista entre el procesador y el coprocesador, ofreciendo a las capas

de mayor nivel una serie de primitivas que siempre se mantendran, propor-

cionando independencia de la plataforma a los modulos superiores.

ISR: La rutina de tratamiento de interrupciones extraera el mensaje del coproce-

sador, preparando la invocacion a un modulo superior, que se encargara de

invocar el objeto final.

Gestion de invocaciones a software: Revisara las invocaciones extraıdas por ISR,

y procedera a lanzar los metodos finales.

Registro de objetos software: Configurara el coprocesador para que conozca los

objetos software que existen en el sistema.

Gestion de invocaciones a objetos hardware: Presenta una interfaz software de

los objetos hardware existentes en el sistema, para poder realizar invocacio-

nes.

54


Figura 5.6: Modulos de la capa software.

55


56

6Evidencia experimental

Indice General6.1. Verificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1.1. Verificacion en MicroBlaze . . . . . . . . . . . . . . . 60

6.1.2. Verificacion en PowerPC . . . . . . . . . . . . . . . . 62

6.2. Test del prototipo . . . . . . . . . . . . . . . . . . . . . . . 64

6.2.1. Caracterizacion del coprocesador para MicroBlaze . . 65

6.2.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . 65

6.2.3. Detalles de sıntesis . . . . . . . . . . . . . . . . . . . 68

6.2.4. Caracterizacion del coprocesador para PowerPC . . . 70

6.2.5. Rendimiento . . . . . . . . . . . . . . . . . . . . . . 70

6.2.6. Detalles de sıntesis . . . . . . . . . . . . . . . . . . . 71

6.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . 73

57

6. Evidencia experimental

En esta seccion desarrollaremos las pruebas que se han realizado sobre los

prototipos obtenidos. El diseno de estos sistemas sigue un flujo de trabajo como el

que podemos ver en la figura 6.1, en el que se realiza una verificacion del diseno

inicial, una prueba despues de realizar la sıntesis del modelo estructural y por

ultimo un test completo despues del rutado y disposicion de los componentes. La

prueba post-sıntesis no nos ofrecıa una mejora en tiempo con el test completo,

por lo que se opto por suprimir estas pruebas intermedias, ya que las ultimas son

las mas reales y la existencia de herramientas para la monitorizacion de buses nos

permitıan un analisis completo.

Figura 6.1: Flujo de diseno

Las pruebas de verificacion inicial se realizan mediante la construccion de un

banco de pruebas apropiado, y el test completo, orientado a la prueba real en la

placa de desarrollo, mediante la construccion de un escenario.

Ambas pruebas nos seran utiles, aunque hay que destacar que el correcto fun-

cionamiento de la simulacion no tiene por que asegurarlo tambien una vez puesto

el modelo en la placa de desarrollo. Esto puede ser debido a multitud de factores,

como pueden ser los problemas de restricciones fısicas, e incluso un comporta-

miento diferente de librerıas de simulacion con respecto a la realidad.

58


6.1. Verificacion

La verificacion sera llevada a cabo mediante la construccion de un banco de

pruebas, en el cual se generaran las senales apropiadas y se programaran cuales

deben ser las respuestas para que el funcionamiento sea el correcto. El programa

que se usara para esta simulacion de codigo VHDL sera Modelsim [13].

La ventaja de usar estas tecnicas son que ante cualquier cambio del codigo

fuente, podemos realizar una prueba automatizada para comprobar que las mejo-

ras no han afectado al correcto comportamiento.

Modelsim ofrece dos alternativas para realizar el banco de pruebas, uno es me-

diante el propio lenguaje VHDL y otro mediante FLI (Foreign Language Interface

[14]). FLI es una opcion que aporta ModelSim, para poder controlar el proceso

de simulacion mediante el lenguaje de programacion C, lo cual puede simplificar

la realizacion de las pruebas. Como inconveniente nos encontramos que es una

solucion ligada a la plataforma ModelSim, mientras que un banco de pruebas de-

sarrollado en VHDL permitira realizarlas en otros simuladores. Finalmente nos

decantaremos por la solucion de FLI.

Los casos de prueba a desarrollar se guiaran por los requisitos del coprocesa-

dor, ası que desarrollaremos casos de uso para probar:

Lanzar escritura desde software y comprobar que se transmite tal cual hacia

hardware.

Configurar coprocesador.

Lanzar invocacion hacia software, comprobar que lanza la interrupcion y

que se pueden recuperar sus datos.

59


Los casos de uso implementados para el coprocesador en la plataforma Micro-

Blaze y PowerPC estaran destinados a probar la misma funcionalidad, pero seran

distintos, ya que estas plataformas guardan grandes diferencias entre sı, como

por ejemplo los tipos de buses que utilizan, que son la principal entrada para los

estımulos.

6.1.1. Verificacion en MicroBlaze

A continuacion aparecen los casos de prueba que se han desarrollado, con los

pasos de lo que se ha probado y el resultado obtenido:

Caso de prueba: Invocacion software-hardware

Descripcion: Se realizara una invocacion que llegara como si se

hubiese realizado en software, y despues se compro-

bara que llega de forma correcta a hardware.

Pasos:

1. Escribir en FSL direccion de destino

2. Escribir en FSL datos

3. Esperar en OPB la invocacion a la direccion in-

dicada

4. Recuperar los datos que se escribieron por FSL

Resultado: El test se ha completado correctamente.

Cuadro 6.1: Caso de prueba Invocacion software-hardware

60


Caso de prueba: Configuracion del coprocesador

Descripcion: Se programara en el coprocesador varias direcciones

de objetos software registrados en el sistema.

Pasos:

1. Escribir en OPB en la direccion coprocesador

2. Escribir en OPB la direccion del objeto soft-

ware como dato


Cuadro 6.2: Caso de prueba Configuracion del coprocesador

Caso de prueba: Invocacion hardware-software



Pasos:

1. Escribir en OPB en la direccion de un objeto

software registrado

2. Comprobar que el coprocesador se hace pasar

por el objeto

3. Escribir en OPB los datos

4. Comprobar que el coprocesador lanza una inte-

rrupcion marcando que hay datos

5. Recuperar por FSL los datos de la invocacion


Cuadro 6.3: Caso de prueba Invocacion hardware-software

61


6.1.2. Verificacion en PowerPC

Una vez descritos las pruebas para la plataforma MicroBlaze, seguiremos el

mismo esquema para las pruebas en PowerPC:

Caso de prueba: Invocacion software-hardware

Descripcion: Se realizara una invocacion que llegara como si se

hubiese realizado en software, y despues se compro-

bara que llega de forma correcta a hardware.

Pasos:

1. Escribir en PLB direccion de destino, y datos

de la transferencia

2. Escribir en PLB datos

3. Esperar en PLB que el coprocesador lance la

invocacion grabada

4. Comprobar que la invocacion es correcta


Cuadro 6.4: Caso de prueba Invocacion software-hardware

62


Caso de prueba: Configuracion del coprocesador



Pasos:

1. Escribir en PLB en la direccion coprocesador

2. Escribir en PLB la direccion del objeto software

como dato


Cuadro 6.5: Caso de prueba Configuracion del coprocesador

Caso de prueba: Invocacion hardware-software



Pasos:

1. Escribir en PLB en la direccion de un objeto

software registrado

2. Comprobar que el coprocesador se hace pasar

por el objeto

3. Escribir en PLB los datos de la invocacion

4. Comprobar que el coprocesador lanza una inte-

rrupcion marcando que hay datos

5. Recuperar por PLB los datos de la invocacion


Cuadro 6.6: Caso de prueba Invocacion hardware-software

63


6.2. Test del prototipo

Como hemos indicado anteriormente, se construira un escenario para realizar

todas las pruebas, y mediante la programacion software comprobaremos el fun-

cionamiento correcto del escenario en la realidad, teniendo ya en cuenta todas las

restricciones.

El escenario de ejemplo, representado en la figura 6.2, consistira en un core

hardware que realizara calculos matematicos en notacion RPN. Ademas, se con-

tara con otro core que controlara los botones, siendo su funcion la de avisar a un

objeto software, que lanzara calculos matematicos segun el boton pulsado.

Este escenario aplicado a las 2 implementaciones del coprocesador desarrolla-

das, verificandose el correcto funcionamiento de ambos.

Ademas como resultado de la implementacion puede extraerse datos concretos

acerca del rendimiento de la comunicacion Hw-Sw y sobre el coste en recursos

del coprocesador, que se se describen a continuacion por separado.

Figura 6.2: Escenario de prueba.

64


6.2.1. Caracterizacion del coprocesador para MicroBlaze

6.2.2. Rendimiento

Comenzaremos realizando una prueba del tiempo que se tarda en hacer llegar

a software una invcacion de hardware, para ello se realiza una prueba consistente

en una pulsacion de un boton del “Controlador botones”, que inmediatamente

procede a realizar una invocacion a un objeto software, que trabaja sobre xilkernel,

para mostrar por pantalla que tecla se habıa pulsado. Dicha prueba ha arrojado

como resultado los de la figura 6.3, se comprueba que pasan 158 ciclos desde

que se realiza la peticion software hasta que se lanza la primera instruccion del

manejador de interrupciones, donde se ha colocado una marca para que se escriba

en el bus, pudiendose ası trazar facilmente. El sistema esta funcionando con un

reloj de 100 MHz, siendo cada ciclo de 10 ns y por tanto un tiempo de respuesta

de 1580 ns.

Si el sistema no cuenta con microkernel, el tiempo de respuesta baja, pudiendo

llegar a obtener respuesta a los 60 ciclos de haberse producido la interrupcion. Su

eleccion dependera del tipo de aplicacion, si es necesario tener mas de un hilo se

hace obligatorio el uso de dicho microkernel para que se encargue de manejarlos.

Para tener una idea de esta magnitud de tiempo, la compararemos con lo que

necesitan algunos tipos de aplicaciones:

LAN: Una LAN de 100 Mbps trabajando a pleno rendimiento generarıa una in-

terrupcion cada 320 ns, siendo un tiempo inferior al que tarda en empezar a

procesar la rafaga. Trabajando a 10 Mbps tendrıamos 3200 ns, representan-

do una carga bastante alta para el sistema, no pudiendo realizar demasiado

procesamiento (162 ciclos de CPU libres).

65


UART: Tıpicamente trabaja a 9600 bps, produciendose la interrupcion cada 3.000.000

ns, representando una carga mınima.

Vıdeo: Un vıdeo de 640x480 generarıa 307.200 pixels, con 16 bits por pixel ten-

dremos un total de 2.457.600 transacciones, si quisieramos mantener una

tasa de 25 fps estarıamos en transaccion por 16 ns, lo que representa una

carga muy grande para el sistema.

Sonido: Un sonido muestreado a 44.100 Hz y con 16 bits por muestra genera una

transaccion cada 45.351 ns, pudiendo ser soportado sin problemas.

Figura 6.3: Tiempo en manejar una peticion en OPB.

Con estos datos podemos ver que por ejemplo es factible realizar aplicaciones

software que interactuen con la UART, con sonido y todo tipo de aplicaciones que

requieran un ancho de banda parecido. Sin embargo, aplicaciones con requeri-

mientos como los necesarios para LAN o vıdeo requeriran tratamiento hardware.

Para la prueba de invocacion desde software hacia hardware se ha realizado

una rafaga hacıa la “Calculadora RPN”. El uso del coprocesador representa una

gran mejora respecto a la escritura estandar del microprocesador en cuanto hay

que enviar un numero elevado de datos. En total haremos llegar a la calculadora

3232 bits (101 transacciones), como podemos ver en la figura 6.4, la transmision

se realiza en el mismo numero de ciclos que transacciones hay. Por el contrario,

en la figura 6.5, podemos ver la diferencia sin el uso del coprocesador. Chipscope

no ha sido capaz de almacenar la transaccion completamente debido a su tamano,

66


pero entre escritura y escritura siempre se mantienen 11 ciclos, ası que el tiempo

total es de 1101 ciclos. Esto representa una mejora en tiempo del 90,82 %.

Figura 6.4: Tiempo envıo de software a hardware con el coprocesador.

Figura 6.5: Tiempo envıo de software a hardware sin usar el coprocesador.

67


6.2.3. Detalles de sıntesis

En la tabla 6.7 podemos observar los detalles de la sıntesis del coprocesador

para MicroBlaze, vemos que ocupa en torno a un 3 % del area total del que se

dispone, por lo que podemos decir que el componente es pequeno y no resulta una

carga importante que limite el resto del diseno.

Numero de Slices: 454 de 13696 3 %

Numero de Slice Flip Flops: 414 de 27392 1 %

Numero de 4 input LUTs: 652 de 27392 2 %

Numero usado como logica: 524

Numero usado como registros de desplazamiento: 128

Numero de IOs: 254

Numero de IOBs: 0 de 556 0 %

Numero de BRAMs: 2 de 136 1 %

Cuadro 6.7: Recursos del coprocesador en OPB.

En cuanto a temporizacion lo podemos ver en la tabla 6.8, donde se observa

que el modelo esta al lımite del ciclo de reloj del sistema, que es de 10 ns, que es el

del sistema funcionando a 100Mhz. El camino crıtico esta ubicado en la CAM, la

memoria que usamos para almacenar las direcciones de los objetos software, por

lo que una posible solucion podrıa ser sustituirla por una solucion ad-hoc basada

en registros y comparadores, o incluso en el uso de tablas hash, para reducir el

tamano de la memoria (a mayor tamano mayor retardo).

68


Minimum period: 10.666ns (Maximum Frequency: 93.759MHz)

Minimum input arrival

time before clock: 3.900ns

Maximum output required

time after clock: 2.240ns

Maximum combinational

path delay: 1.344ns

Delay: 10.666ns (Levels of Logic = 24)

Source: coprocesador 0/cam1/...

Destination: coprocesador 0/cam1/...

Source Clock: OPB Clk rising

Destination Clock: OPB Clk rising

Cuadro 6.8: Temporizacion del coprocesador en OPB.

69


6.2.4. Caracterizacion del coprocesador para PowerPC

6.2.5. Rendimiento

Los resultados para PLB los podemos ver en la figura 6.6, donde observamos

que la respuesta por parte del manejador llega 222 ciclos mas tarde. Se ha usado

la misma tecnica que la prueba con OPB para detectar cuando ha ocurrido. Esta

vez el tiempo es de 2220 ns. Usando el PowerPC a 300 Mhz en lugar de a 100, se

consigue mejorar a 194 ciclos.

Figura 6.6: Tiempo en manejar una peticion en PLB.

En el caso de la transmision de hardware a software en la plataforma PowerPC,

el coprocesador no es capaz de hacer ninguna mejora en cuanto a rendimiento,

ofreciendo unicamente la capacidad de poder interoperar sin problemas con los

cores hardware. El uso del propio PLB para transmitir las transacciones hacia el

coprocesador provoca que tardemos el mismo tiempo en pasar los datos, ademas

de que una vez terminada, el coprocesador lo tendra que reenviar a su destino

final. Lo que provoca que el rendimiento final sea inferior.

Como se apunta en el capıtulo anterior este no serıa el caso si se utilizasen

2 buses PLB, uno punto a punto con el coprocesador, y otro del coprocesador al

sistema, cosa que no ha sido posible verificar en el ambito de este proyecto puesto

que ello requiere el diseno de un core que realice las labores de puente entre ambos

buses, ya que este no se encuentra entre los proporcionados por las herramientas.

70


6.2.6. Detalles de sıntesis

En esta ocasion la tabla 6.9 detalla la sıntesis del coprocesador para la plata-

forma PowerPC, que al igual que en el caso anterior vemos que tambien esta en

torno a un 3 % del area total del que se dispone, aunque comparativamente es algo

mayor (55 slices).

Numero de Slices: 509 de 13696 3 %

Numero de Slice Flip Flops: 503 de 27392 1 %

Numero de 4 input LUTs: 798 de 27392 2 %

Numero usado como logica: 734

Numero usado como RAMs: 64

Numero de IOs: 426

Numero de IOBs: 0 de 556 0 %

Numero de BRAMs: 8 de 136 5 %

Cuadro 6.9: Recursos del coprocesador en PLB.

El resumen del tiempo lo encontramos en la tabla 6.10, en el que en esta oca-

sion el tiempo es optimo, 6,42 ns es bastante inferior a los 10 ns necesarios, dando

margen para las conexiones con los demas dispositivos con los que se interconec-

ta. El camino crıtico de nuevo se encuentra ubicado en la CAM.

71


Minimum period: 6.424ns (Maximum Frequency: 155.660MHz)

Minimum input arrival

time before clock: 3.555ns

Maximum output required

time after clock: 4.619ns

Maximum combinational

path delay: 2.791ns

Delay: 6.424ns (Levels of Logic = 14)

Source: coprocesador 0/cam1/...

Destination: coprocesador 0/cam1/...

Source Clock: PLB Clk rising

Destination Clock: PLB Clk rising

Cuadro 6.10: Temporizacion del coprocesador en PLB.

72


6.3. Conclusiones

Como conclusiones tras la finalizacion del proyecto, podemos extraer las si-

guientes relativas a la implementacion de los prototipos.

Mejora de rendimiento frente a no usarlo.

Bajo coste en recursos.

El coprocesador para la plataforma MicroBlaze se encuentra mejor integra-

do gracias a los buses FSL, con lo que obtiene un mejor rendimiento y no

supone ninguna sobrecarga en el sistema de comunicacion.

El coprocesador para la plataforma PowerPC necesitarıa una busqueda de

alternativas a un unico bus, ya que la interaccion con este se hace lenta, y

aporta ventajas solo en cuanto a interoperabilidad.

Para la capa software es necesario crear un generador automatico, que a

partir de las definiciones de los objetos del sistema la genere.

El desarrollo inicial de cada prototipo no conlleva un tiempo excesivo. Pero

una vez generada dicha version inicial, hay que realizar las pruebas para

comprobar su funcionamiento correcto, siendo esta etapa la mas costosa.

Los buses no siempre respetan el estandar original, encontrandose las mo-

dificaciones en documentos separados, y no siempre estan acompanados de

los cronogramas. Las senales del bus son muy estrictas en cuanto a tempo-

rizacion, es decir, en cuanto hay un error el sistema se queda bloqueado,

complicando algunos metodos de depuracion, como el uso de la UART.

En cuanto a los objetivos globales del proyecto:

73


El objetivo de la transparencia se ha cumplido, los prototipos desarrollados

cumplen su funcion sin ninguna modificacion de los objetos que lo rodean,

es decir, un objeto al que se invoca puede ser trasladado de hardware a

software o viceversa sin que el objeto que lo invoque deba realizar ningun

cambio.

La independencia de la plataforma ha quedado demostrada en parte con la

implementacion del modelo en dos plataformas diferentes como lo son la

plataforma PowerPC y la plataforma MicroBlaze, en las que existen dife-

rencias notables, puesto que disponen de procesadores y buses con carac-

terısticas distintas.

En cuanto al rendimiento, ha quedado solamente demostrado en el caso de

la plataforma MicroBlaze, y no en la de PowerPC por los motivos men-

cionados anteriormente. Esto nos lleva a la conclusion de que el objetivo

de rendimiento depende de si la plataforma ofrece mecanismos extra para

acelerar la comunicacion entre el microprocesador y el coprocesador.

74

7Anexo

Indice General7.1. Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.1. FSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1.2. OPB . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.1.3. PLB . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.2. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.1. Coprocesador en MicroBlaze . . . . . . . . . . . . . . 83

7.2.2. Coprocesador en PowerPC . . . . . . . . . . . . . . . 86

7.3. Uso del coprocesador . . . . . . . . . . . . . . . . . . . . . 89

7.3.1. Coprocesador en MicroBlaze . . . . . . . . . . . . . . 89

7.3.2. Coprocesador en PowerPC . . . . . . . . . . . . . . . 92

7.4. Prototipos desarrollados . . . . . . . . . . . . . . . . . . . . 93

75

7. Anexo

7.1. Buses

A continuacion describiremos con mayor detalle las operaciones que se pue-

den realizar en los distintos tipos de buses usados en el proyecto, mostrando sus

senales principales y para que se utilizan.

7.1.1. FSL

Comenzaremos con el bus FSL utilizado en la plataforma MicroBlaze, recor-

dar que este bus no necesita arbitro, puesto que es punto a punto y no comparte

recursos.

El ejemplo de lectura para este bus lo podemos ver en la figura 7.1. Cuando el

maestro haya realizado una escritura, la senal FSL S EXISTS se encontrara acti-

va, indicando que el contenido de FSL S DATA y FSL S CONTROL es correcto.

Una vez leıdo, mantendremos durante un ciclo levantada la senal FSL S READ,

dando ası la lectura por finalizada. Como vemos esta operacion se puede realizar

en un unico ciclo, pudiendo recuperar ası una rafaga sin esperas.

Figura 7.1: Lectura en FSL.

La escritura, figura 7.2, se puede realizar en cualquier momento sin necesidad

76

7. Anexo

de realizar ninguna peticion al ser un bus sin arbitraje, con la unica precaucion

de no escribir si los buffers estan llenos, que se marcara mediante la activacion

de la senal FSL M FULL. Si no se encuentra activa, podemos realizar la escri-

tura manteniendo durante un ciclo FSL M WRITE activo, al mismo tiempo que

mantenemos el dato que deseemos y marquemos si es de control con las senales

FSL M DATA y FSL M CONTROL respectivamente.

Figura 7.2: Escritura en FSL.

77

7. Anexo

7.1.2. OPB

Para mostrar el funcionamiento del bus, se han realizado una serie de ejemplos

de escrituras y lecturas, incluyendo el uso de rafagas. Se han programado en la

FPGA y mediante el uso de ChipScope, la herramienta para la monitorizacion de

los buses, se han obtenido las capturas.

En la figura 7.3 podemos observar las senales para realizar una lectura simple.

Comenzamos pidiendo el bus, y para ello mantendremos activa la senal Request,

hasta que el arbitro nos conceda el acceso mediante la senalizacion apropiada con

Grant. A partir de aquı activaremos la senal Select y pondremos en ABus la direc-

cion del esclavo para realizar la invocacion. La invocacion quedara configurada

con las senales RNW (ReadNotWrite) que se mantendra a 0 para indicar al escla-

vo que vamos a escribir, no bloqueamos el bus mediante BusLock y por ultimo

situamos el dato en WrDBus, manteniendolo hasta que el esclavo lo reconoce

mediante xferAck, evento que se produce en el mismo ciclo.

Figura 7.3: Escritura simple.

En la figura 7.4 podemos observar las senales para realizar una lectura simple.

El comportamiento es igual que en el caso de la escritura, la unica diferencia es

78

7. Anexo

que cuando el arbitro nos de acceso al bus activaremos la senal RNW, y el dato,

esta vez sera escrito por el esclavo en RdDBus, utilizadose xferAck para marcar

cuando se encuentra el dato valido.

Figura 7.4: Lectura simple.

En las figuras 7.5 y 7.6 se realizan escrituras y lecturas, esta vez con rafa-

gas. Donde la unica diferencia es que la senal BusLock queda activada desde que

se concede el bus hasta que finaliza la rafaga, aunque es aconsejable desactivar

BusLock un ciclo antes de que esta termine.

Figura 7.5: Escritura con rafaga.

79

7. Anexo

Figura 7.6: Lectura con rafaga.

80

7. Anexo

7.1.3. PLB

Como vemos en la figura 7.7, el protocolo de comunicaciones que tiene PLB

es algo mas complejo en cuanto a numero de senales, aunque mantiene parecidos

con el bus OPB. En este caso la imagen corresponde a una lectura, que el master

la iniciara con la senal M REQUEST activa, ademas de poner la direccion, y con-

figuracion de la invocacion activando M RNW. Cuando el esclavo se de cuenta de

que es para el dara un reconocimiento de la direccion con Sl AddrACK, en este

momento el master puede retirar los valores. El esclavo a continuacion dara un

ack de lectura completada (SL RDCOMP), y en el ciclo siguiente pondra el dato

en SL RDDBUS y confirmara con SL RDDACK.

La escritura es muy parecida a la lectura, la comunicacion se iniciara igual,

pero en esta ocasion el maestro no activara la senal M RNW, y si pondra el dato

en M WRDBUS. Solo queda que el esclavo active la senal de ack de direccion y

confirme con SL WRCOMP y SL WRDACK.

81

7. Anexo

Figura 7.7: Lectura simple.

82

7. Anexo

7.2. Implementacion

El desarrollo del proyecto se ha llevado a cabo mediante el entorno de desa-

rrollo XPS (Xilinx Platform Studio), con el cual se han creado las plataformas y

desarrollado los cores.

7.2.1. Coprocesador en MicroBlaze

En esta parte veremos mas detalles de su implementacion, recuperaremos el

diagrama de bloques en la figura 5.4 y veremos que maquinas de estado se han

usado para cada modulo, que estados tiene y cuando se producen las transiciones.

Envio HW→ SW: Esta maquina es la que se encarga de procesar las transaccio-

nes que llegan de hardware y que tienen destino software, ası como de la

configuracion del coprocesador para indicar cuales son las direcciones de

componentes software. Esta es la funcionalidad del modulo HW2SW. Se

compone de los siguientes estados:

stIDLE: Estado de reposo, espera una invocacion de las que esta pendiente

o una invocacion de configuracion para las nuevas direcciones.

stConf: Se utiliza para grabar una direccion en la CAM, simplemente rea-

liza la confirmacion del dato y vuelve al estado inicial, para realizar

una escritura hay que hacer una primera transaccion con la posicion

en la CAM donde se quiere escribir y una segunda con la direccion del

objeto software.

stDATOSPRE: Llegamos cuando se ha detectado una invocacion a soft-

ware, es decir, una direccion contenida en la CAM ha sido reconocida

83

7. Anexo

en el bus. Escribimos en la FIFO la direccion de a quien va dirigida la

peticion y pasamos a stDATOS.

stDATOS: Conforme llegan los datos de la invocacion, los vamos almace-

nando en la FIFO destinada a tal efecto, hasta completar la transaccion.

Figura 7.8: Diagrama de la maquina de estados ‘Envio HW→ SW’.

Envio FSL: Esta maquina de estados se encarga de enviar las invocaciones alma-

cenadas en la FIFO hacia el bus FSL, correspondiendose esta funcionalidad

con el modulo que lleva el mismo nombre. Sus estados son:

stIDLE: Se encuentra a la espera mientras que la FIFO que se encarga

de llenar el modulo HW2SW este vacıa o si no lo estuviese, que en

el bus FSL se pueda seguir escribiendo, una vez que se cumplan las

condiciones pasamos al estado de envıo.

stENVIO: Mientras queden datos en la FIFO y no llenemos los buffers de

FSL, continuaremos descargando los datos, que posteriormente, y me-

84

7. Anexo

diante la interrupcion que genera el controlador FSL se procesara en

software.

Figura 7.9: Diagrama de la maquina de estados ‘Envio FSL’.

Envio OPB: Esta maquina tambien tiene el mismo nombre que el modulo al que

pertenece, esta destinada a hacer transferencias de software a hardware. Re-

cibe los datos de la FIFO que almacena el modulo RecepFSL.

stIDLE: Se encuentra a la espera mientras que la FIFO siga vacıa. Cuando

llegue alguna peticion, nos vamos al estado stREQUEST, para pedir

acceso al bus.

stREQUEST: Pedimos acceso y esperamos hasta conseguirlo, para pasar

a stGRANTED.

stGRANTED: Se realiza la escritura en el componente de destino.

El modulo de RecepFSL realmente es muy simple y no es necesario una

maquina de estados para el, gracias a la simplicidad del bus FSL.

85

7. Anexo

Figura 7.10: Diagrama de la maquina de estados ‘Envio OPB’.

7.2.2. Coprocesador en PowerPC

Al igual que la plataforma de MicroBlaze, vamos a detallar la implementa-

cion para la plataforma PowerPC, a continuacion describiremos las maquinas de

estados que se han usado para implementar los modulos que veıamos en la figura

5.5.

El funcionamiento de este core esta compuesto por dos maquinas de estado:

Coprocesador: Esta maquina se encarga practicamente de toda la funcionalidad

del coprocesador para PowerPC, se registran los objetos que hay en soft-

ware por los cuales hay que responder, se registran las peticiones a objetos

software, se da soporte para la lectura de las invocaciones almacenadas, y

por ultimo, soporte de escritura a objetos hardware con transferencias de 64

bits, realizando la funcion del modulo skeleton. Se compone de los siguien-

tes estados:

86

7. Anexo

stIDLE: Se encuentra a la espera de que se dispare una de las acciones que

se han comentado en la descripcion. Ademas se realiza el reconoci-

miento de direccion.

stDataAck: Se realizan los ACK de datos, en el caso de que sea una lectura

tendremos que ir al estado stDataAck2, si no, volvemos al inicial.

stDataAck2: Se realiza el ACK de lectura y se devuelve el dato. Volvemos

al estado inicial.

stPrim: Llegamos a el si se esta realizando una transaccion secundaria en la

que tendremos que esperar a ciertos Flags para seguir el curso normal.

Figura 7.11: Diagrama de la maquina de estados ‘Coprocesador’.

Envio PLB: Todas las peticiones que se carguen de la anterior maquina de es-

tados con destino a hardware pasaran a una fifo. Esta maquina de estados

sera la encargada de ir procesado las peticiones almacenadas. Siendo esta la

funcion del modulo proxy.

87

7. Anexo

stIDLE: Se encuentra a la espera mientras que la fifo siga vacıa. Cuando

llegue alguna peticion, nos vamos al estado stREQUEST, para pedir

acceso al bus.

stREQUEST: Pedimos acceso y esperamos hasta conseguirlo, para pasar

a stGRANTED.

stGRANTED: Se realiza la escritura en el componente de destino.

Figura 7.12: Diagrama de la maquina de estados ‘Envio PLB’.

88

7. Anexo

7.3. Uso del coprocesador

A continuacion vamos a detallar los pasos para incluir en un proyecto nuevo

cada uno de los coprocesadores.

7.3.1. Coprocesador en MicroBlaze

Partiremos de un sistema base ya creado, a partir de el realizaremos los si-

guientes pasos:

1. Anadiremos el coprocesador al repositorio de cores, para ello copiaremos

el directorio “Coprocesador v1 00 a” al directorio “pcores” de nuestro pro-

yecto. Ademas crearemos en la raız del proyecto el directorio “implemen-

tation”, sobre el que copiaremos los ficheros contenidos en “Coprocesa-

dor v1 00 a/gencores”, que contiene las implementaciones de componentes

que usa el coprocesador.

2. En el programa XPS refrescaremos los cores que tenemos en el repositorio

local, para ello pulsaremos sobre “Project / Rescan User Repositories”. Y

en el catalogo de IP procederemos a anadir el coprocesador al sistema.

3. A continuacion procedemos a conectarlo, para ello activaremos la conexion

maestro/esclavo de OPB, y lo mismo para FSL, en el que asignaremos “New

Connection” tanto en “MFSL1” como en “SFSL1”.

4. Configuraremos Microblaze, y en la pestana de “Buses” le asignaremos un

enlace de FSL. Y enlazaremos la lınea “SFSL0” con “MFSL1” y “MFSL0”

con “SFSL1”, quedando conectado Microblaze con el coprocesador.

89

7. Anexo

5. Anadiremos el controlador de interrupciones “OPB Interrupt Controller”

y lo conectaremos al bus OPB. El controlador FSL que va del maestro

FSL del coprocesador al esclavo de Microblaze, tiene una senal llamada

“FSL Has Data”, que la conectaremos a “intr” del controlador de interrup-

ciones. A su vez, la senal “irq” la conectaremos a Microblaze en la entrada

“Interrupt”.

6. Anadiremos el controlador de tiempo, que lo conectaremos al bus, ademas

de su salida de interrupciones al controlador.

7. Por ultimo regeneraremos las direcciones de todos los dispositivos, para

completar todos los cambios necesarios en hardware. Quedando un esque-

ma del sistema como el que podemos ver en la figura 7.13, generado por el

propio XPS.

8. Para la parte software, elegiremos XilKernel como sistema operativo en la

pantalla “Software Platform Settings”, y configuraremos sysintc spec con

opb intc, stdout y stdin con la conexion RS232, systmr spec con el contro-

lador de tiempo y por ultimo en config pthread support anadiremos el hilo

principal de nuestro programa. Solo queda en la opciones de compilacion

anadir xilkernel en “Libraries to Link against”.

90

7. Anexo

Figura 7.13: Sistema basico de MicroBlaze con coprocesador.

91

7. Anexo

7.3.2. Coprocesador en PowerPC

Ahora realizaremos los pasos necesarios para la plataforma PowerPC, siendo

algunos de ellos muy parecido a los de la plataforma MicroBlaze:

1. Anadiremos el coprocesador al repositorio de cores, para ello copiaremos

el directorio “Coprocesador v1 00 a” al directorio “pcores” de nuestro pro-

yecto. Ademas crearemos en la raız del proyecto el directorio “implemen-

tation”, sobre el que copiaremos los ficheros contenidos en “Coprocesa-

dor v1 00 a/gencores”, que contiene las implementaciones de componentes

que usa el coprocesador.

2. En el programa XPS refrescaremos los cores que tenemos en el repositorio

local, para ello pulsaremos sobre “Project / Rescan User Repositories”. Y

en el catalogo de IP procederemos a anadir el coprocesador al sistema.

3. A continuacion procedemos a conectarlo, para ello activaremos la conexion

maestro/esclavo de PLB.

4. Anadiremos el controlador de interrupciones “OPB Interrupt Controller” y

lo conectaremos al bus OPB. Conectaremos la senal “IP2INTC Irpt” del

coprocesador a “intr” del controlador de interrupciones. A su vez, la senal

“irq” la conectaremos a PowerPC en la entrada “EICC405EXTINPUTIRQ”.

5. Por ultimo regeneraremos las direcciones de todos los dispositivos, para

completar todos los cambios necesarios en hardware. Quedando esta vez un

esquema de sistema como el que podemos ver en la figura 7.14.

6. Para la parte software, elegiremos XilKernel como sistema operativo en

la pantalla “Software Platform Settings”, y configuraremos sysintc spec

92

7. Anexo

con opb intc, stdout y stdin con la conexion RS232 y por ultimo en con-

fig pthread support anadiremos el hilo principal de nuestro programa. Solo

queda en la opciones de compilacion anadir xilkernel en “Libraries to Link

against”.

7.4. Prototipos desarrollados

En el cdrom que se adjunta encontraremos el codigo fuente de los dos cores

desarrollados, ademas de los ejemplos desarrollados para cada una de las platafor-

mas en las respectivas carpertas “ejemploMB” para MicroBlaze y “ejmploPPC”

para PowerPC. Para todo el desarrollo se ha usado las herramientas de Xilinx en

la version 9.1.

93

7. Anexo

Figura 7.14: Sistema basico de PowerPC con coprocesador.

94

Bibliografıa

[1] BURGER, Doug; GOODMAN,James R.. Billion-Transistor Architectures

September Computer, vol. 30, no. 9, pp. 46-49, Sept., 1997

[2] RINCON, F.; MOYA, F.; BARBA, J., LOPEZ, J. C.. Model Reuse through

Hardware Design Patterns July 2005.

[3] Margarida F. Jacome, Helvio P. Peixoto, A Survey of Digital Design Reuse

IEEE Design and Test of Computers, vol. 18, no. 3, pp. 98-107, May/Jun,

2001

[4] http://www.soccentral.com

[5] COULOURIS, George F.; DOLLIMORE, Jean; KINDBERG, Tim. Distri-

buted System Concepts and Design 2005

[6] http://standards.ieee.org/reading/ieee/std_public/

description/dasc/1076-1993_desc.html

[7] MicroBlaze Processor Reference Guide Embedded Development Kit EDK

9.1i UG081 (v7.0)

95

http://www.soccentral.com

http://standards.ieee.org/reading/ieee/std_public/description/dasc/1076-1993_desc.html

http://standards.ieee.org/reading/ieee/std_public/description/dasc/1076-1993_desc.html

[8] PowerPC 405 Processor Block Reference Guide Embedded Development

Kit UG018 (v2.1) July 20, 2005

[9] Xilkernel EDK 8.2i, June 23, 2006

[10] http://www.xilinx.com/bvdocs/ipcenter/data_sheet/

FSL_V20.pdf Fast Simplex Link (FSL) Bus (v2.00a)

[11] http://www-01.ibm.com/chips/techlib/techlib.nsf/

pages/main?OpenDocument On-Chip Peripheral Bus Architecture

Specifications Version 2.1

[12] http://www-01.ibm.com/chips/techlib/techlib.nsf/

pages/main?OpenDocument 64-Bit Processor Local Bus Architecture

Specifications Version 3.5

[13] http://www.model.com

[14] http://www.model.com/resources/resources_manuals.

asp

[15] http://www.faqs.org/rfcs/rfc1057.html

[16] http://arco.inf-cr.uclm.es/soda.html

[17] http://arco.inf-cr.uclm.es/mar.html

[18] http://www-03.ibm.com/chips/products/coreconnect/

http://www.xilinx.com/bvdocs/ipcenter/data_sheet/FSL_V20.pdf

http://www.xilinx.com/bvdocs/ipcenter/data_sheet/FSL_V20.pdf

http://www-01.ibm.com/chips/techlib/techlib.nsf/pages/main?OpenDocument




http://www.model.com

http://www.model.com/resources/resources_manuals.asp

http://www.model.com/resources/resources_manuals.asp

http://www.faqs.org/rfcs/rfc1057.html

http://arco.inf-cr.uclm.es/soda.html

http://arco.inf-cr.uclm.es/mar.html

http://www-03.ibm.com/chips/products/coreconnect/

universidad de castilla-la mancha escuela superior de...

Documents