Investigación sobre herramientas de Codiseño Hardware-Software

Texto completo

(1)

E

SCUELA

S

UPERIOR DE

I

NGENIEROS

D

EPARTAMENTO DE

I

NGENIERÍA

E

LECTRÓNICA

U

NIVERSIDAD DE

S

EVILLA

Investigación sobre herramientas de Codiseño

Hardware-Software

Proyecto Fin de Carrera Hipólito Guzmán Miranda Ingeniero de Telecomunicación Tutor: Jon Tombs Sevilla, Mayo 2006

(2)
(3)

Índice general

1. Introducción 6

1.1. Motivación . . . 6

1.2. Objetivo . . . 7

1.3. Alcance . . . 7

2. Flujo de diseño en codiseño 8 2.1. Generalidades . . . 8

2.2. Tipos de problemas de codiseño . . . 8

2.2.1. System on Board . . . 8

2.2.2. System on Chip . . . 9

2.2.3. Codiseño con Softcore . . . 9

2.3. Flujo de diseño tradicional . . . 9

2.4. Flujo de diseño con herramientas de codiseño . . . 11

2.4.1. Especificación del Sistema . . . 12

2.4.2. Simulación Funcional . . . 13

2.4.3. Exploración del Espacio de Diseño . . . 13

2.4.4. Co-Simulación TLM . . . 13

2.4.5. Co-Verificación HW/SW . . . 13

2.4.6. Co-Simulación RTL . . . 14

2.4.7. Prototipado . . . 14

2.4.8. Síntesis del Sistema . . . 15

3. Trabajo sobre Unshades-2 16 3.1. Descripción de la plataforma Unshades-2 . . . 16

3.2. Herramientas Evaluadas . . . 19

3.3. Problemas Encontrados . . . 21

3.4. Conclusiones . . . 23

3.4.1. Cambio de plataforma . . . 23

3.4.2. Línea de trabajo sobre Unshades-2 . . . 24

(4)

4. Solución propuesta 26

4.1. Descripción de la solución propuesta . . . 26

5. Procesador Leon 2 29 5.1. Descripción . . . 29

5.1.1. Diagrama de bloques . . . 30

5.1.2. Bus Amba . . . 31

5.2. Alternativas al procesador Leon 2 . . . 32

5.3. Configuración del modelo . . . 35

5.4. Añadiendo la parte HW de tu diseño a Leon 2 . . . 37

6. Placa de desarrollo XSV-800 39 6.1. Descripción . . . 39 6.2. Configuración . . . 41 6.2.1. Configuración de jumpers . . . 41 6.2.2. Frecuencia de reloj . . . 41 6.2.3. Reprogramación de la CPLD . . . 41 6.3. Xstools . . . 42 7. Snapgear Linux 44 7.1. Necesidad de un sistema operativo . . . 44

7.2. Descripción . . . 44

7.2.1. Kernels para sistemas con y sin MMU . . . 45

7.3. Configuración . . . 46

7.4. Añadiendo la parte SW de tu diseño a snapgear . . . 47

8. Entorno de codiseño PeaCE 52 8.1. Descripción y características . . . 52

8.2. Ventajas con respecto a otras soluciones . . . 54

8.3. Flujo de diseño en PeaCE . . . 55

9. Aplicación de demostración 59 9.1. Visión general . . . 59

9.2. Parte hardware . . . 60

9.3. Parte software . . . 65

10. Conclusiones 69 10.1. Futuras líneas de trabajo . . . 70

10.1.1. Adaptación de PeaCE a una plataforma propia . . . 71

10.1.2. Desarrollo de una plataforma HW opensource . . . 71

(5)

Índice de figuras

2.1. Flujo de diseño tradicional . . . 10

2.2. Flujo de diseño utilizando herramientas de codiseño . . . 12

3.1. Unshades 2. Fotografía . . . 17

3.2. Diagrama de bloques del sistema Unshades-2 . . . 18

4.1. Diagrama de bloques de la solución propuesta . . . 28

5.1. Diagrama de bloques del procesador Leon 2 . . . 30

5.2. Mapa de memoria AHB del procesador Leon 2 . . . 31

5.3. Herramienta de configuración del procesador Leon 2 . . . 36

5.4. Esquema del cable serie en Y . . . 37

6.1. Xess XSV-800. Fotografía . . . 40

6.2. Configuración de jumpers empleada . . . 41

6.3. Diagrama de bloques de la plataforma Xess XSV-800 . . . 42

7.1. Herramienta de configuración de Snapgear . . . 48

7.2. Captura de pantalla del programa minicom . . . 49

7.3. Herramienta de configuración de Snapgear, modificada . . . 51

8.1. Especificación del sistema en PeaCE . . . 55

8.2. Especificación de algoritmos en PeaCE . . . 56

8.3. Especificación de arquitectura en PeaCE . . . 57

9.1. Esquema de entradas y salidas del módulo HW . . . 60

9.2. Carga de Snapgear en la RAM de la XSV-800 utilizando grmon . 67 9.3. Aplicación de demostración en funcionamiento . . . 67

(6)

Capítulo 1

Introducción

“A good beginning makes a good ending"

– English Proverb

1.1.

Motivación

Desde los principios de la tecnología de semiconductores, los sistemas elec-trónicos han venido experimentando un constante crecimiento en complejidad, debido a que las prestaciones que tiene que ofrecer una aplicación concreta son cada vez mayores y de naturalezas más diversas. Esto ha dado lugar a que se ten-gan a la vez, para un mismo sistema, restricciones aparentemente incompatibles, como pueden ser de trabajo en tiempo real, de tolerancia a fallos o de procesado de grandes flujos de datos. Este incremento de complejidad y diversidad en las restricciones que ha de cumplir un sistema dado ha motivado la aparición de siste-mas híbridos en los que interactúan elementos hardware y software, ya que dichos elementos pueden complementarse para resolver problemas de distinta naturaleza. Actualmente se está tendiendo, cada vez más, en el diseño de dichos siste-mas electrónicos, a estas soluciones en las que se mezclan elementos hardware y software, debido a las duras restricciones que deben cumplir estos sistemas, como son las condiciones de tiempo real y el procesamiento rápido de grandes flujos de datos. Estos sistemas híbridos se han venido diseñando prácticamente ‘a mano’, en el sentido en que, si bien existen desde hace años herramientas para realizar la compilación del software y la síntesis del hardware, las decisiones más im-portantes que han de tener en cuenta la interacción entre ambas partes (como el particionado HW/SW) se han ido tomando basándose en experiencias previas de diseño, por lo que se tiene una necesidad de poder aplicar una forma más global de ingeniería automatizada al problema del codiseño.

(7)

Introducción 1.2 Objetivo

de la heterogeneidad del sistema objetivo, aprovechando los puntos fuertes del software (mayor flexibilidad, facilidad para ejecutar órdenes secuencialmente) y del hardware (mayor velocidad, posibilidad de realizar procesamiento concurren-te), pero también debe procurar que los tiempos de desarrollo y depuración no sean excesivamente elevados. Esto crea la necesidad y conveniencia de trabajar en entornos integrados de desarrollo en el que se encare toda la problemática de este tipo de diseños de una forma global, y en el que se puedan automatizar la mayor parte de tareas a realizar durante el flujo de diseño1.

1.2.

Objetivo

El objetivo de este proyecto es realizar una investigación sobre el estado del arte de las distintas herramientas de codiseño disponibles en el mercado, así como las distintas plataformas y procesadores (tanto ASIC como softcore) sobre los que se puedan implementar soluciones de codiseño, orientando el trabajo a poder realizar codiseño sobre alguna de las plataformas hardware de las que dispone el departamento. Se pretende también conocer y familiarizarse con el flujo de diseño de un sistema híbrido HW/SW, al igual que entender el resto de opciones y compromisos que puedan surgir, de forma que nos introduzcamos poco a poco en la problemática del codiseño.

1.3.

Alcance

El alcance del proyecto consiste en llegar a poder proponer, como resultado de las investigaciones realizadas, una solución viable para poder realizar codiseño en el departamento. Es requisito que esta solución pueda funcionar en alguna de las plataformas hardware de las que dispone el departamento. Como culminación del proyecto sería deseable llegar a realizar una aplicación sencilla que demuestre la viabilidad de dicha solución y del flujo de diseño propuesto. Esto puede acarrear ciertos problemas ya que las aplicaciones y plataformas que se suelen utilizar para resolver problemas de codiseño disponen normalmente de dispositivos muy potentes y cantidades más que suficientes de recursos como memoria RAM o espacio disponible en FPGA, y en este proyecto se ha trabajado con un hardware muy limitado.

1Por ejemplo, sería deseable poder realizar la partición HW/SW de forma automatizada y transparente al programador, dada una descripción a alto nivel del sistema.

(8)

Capítulo 2

Flujo de diseño en codiseño

“Creativity is inventing, experimenting, growing, taking risks, breaking rules, making mistakes, and having fun"

– Mary Lou Cook

2.1.

Generalidades

Aunque el utilizar soluciones de codiseño para resolver un problema concreto reduce la complejidad individual (y por ello, el coste) de los elementos del siste-ma1, como contrapartida, el proceso de diseño puede complicarse enormemente.

El flujo de diseño de un sistema híbrido debe contemplar el desarrollo de for-ma conjunta de hardware y software e incluye, entre sus pasos, descripción a nivel de sistema, simulación funcional, particionado hardware-software, generación de interfaces, estimación de costes (de área y retrasos para el hardware y de tamaño de código y tiempo de ejecución para el software), co-simulación, síntesis e im-plementación de HW, SW e interfaces. Esta actividad interdisciplinar es lo que se conoce como codiseño.

2.2.

Tipos de problemas de codiseño

2.2.1.

System on Board

Si los elementos hardware y software se encuentran en distintos chips den-tro de una misma placa, la interfaz que transmitirá información entre las partes hardware y software tendrá ciertas limitaciones, puesto que dicha interfaz ha de

1Ya que en estos casos no es necesario que toda la funcionalidad se concentre en un único módulo hardware o software.

(9)

Flujo de diseño en codiseño 2.3 Flujo de diseño tradicional

implementarse necesariamente a través de líneas de conexionado sobre la men-cionada placa: tenemos lo que se conoce como un “System on Board”. Como veremos en el próximo capítulo, este es el caso del sistema UNSHADES-2.

2.2.2.

System on Chip

Cuando los elementos hardware y software forman parte del mismo circuito integrado, la interfaz que los separa puede tener una capacidad mucho mayor para transferir información, dado que esta interfaz está dentro de un circuito integrado: estaríamos, en este caso, ante un “System on Chip”. Ejemplos de estos sistemas son el A7S de Triscend, Excalibur de Altera, Virtex II Pro y Virtex 4 de Xilinx y FIPSOC [FAM+97].

2.2.3.

Codiseño con Softcore

La última opción para atacar la problemática del codiseño es utilizar un único circuito programable sobre el que se programarán tanto el procesador que ejecuta-rá la parte software como el circuito que implementaejecuta-rá la parte hardware. Nótese que, ya que tanto la parte software como la parte hardware del diseño estarán im-plementadas en un circuito programable, estamos nuevamente ante un System on Chip. Pero existen grandes diferencias: por ejemplo en este caso, la interfaz no está limitada a priori: podemos conectar los módulos del procesador al hardware como queramos. Incluso podemos implementar más de un procesador en la misma FPGA. También podemos añadir o eliminar funcionalidades del microprocesador en función de las necesidades de nuestra aplicación. La única limitación la esta-blece la capacidad del circuito programable que utilicemos. Un par de ejemplos de softcores son MicroBlaze de Xilinx y Nios II de Altera.

2.3.

Flujo de diseño tradicional

En los sistemas híbridos de los que hablamos en la introducción, el diseño se ha venido haciendo prácticamente ‘a mano’ en el sentido en que, si bien exis-ten desde hace años herramientas para realizar la compilación del software y la síntesis del hardware, las decisiones más importantes que han de tener en cuen-ta la interacción entre ambas partes (como el particionado HW/SW) se han ido tomando basándose en experiencias previas de diseño.

En general, el flujo de diseño que se puede realizar sin ayuda de ninguna he-rramienta de automatización es el que aparece en la figura 2.1, en la página 10.

(10)

Flujo de diseño en codiseño 2.3 Flujo de diseño tradicional

Figura 2.1: Flujo de diseño tradicional

Posiblemente el subproblema más significativo de todo el problema del codi-seño sea la partición hardware-software (reparto de las tareas que debe realizar el sistema entre los módulos hardware y software). Esta partición puede realizar-se atendiendo a distintos factores, como pueden realizar-ser el tamaño (de área y código fuente), la velocidad de proceso o el consumo de potencia. En la práctica es de-seable establecer un equilibrio entre todos los factores, aunque se otorguen pesos

(11)

Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño

relativos a cada uno de ellos. El particionado suele hacerse manualmente, pro-bando distintas posibilidades y considerando que a priori hay ciertas tareas que deben implementarse en un dispositivo concreto. Para automatizar este paso, se han propuesto varios algoritmos [BGJ+02, NB01, KHM04].

2.4.

Flujo de diseño con herramientas de codiseño

Debido a que se han realizado múltiples investigaciones respecto al tema del codiseño Hardware/Software, existen hoy día múltiples entornos de desarrollo que atacan directamente a la mayor parte de los problemas asociados a la temática del codiseño. Existen tanto proyectos de investigación como POLIS [BGJ+97], orien-tado al diseño de sistemas híbridos para control, y COOL [Nie], orienorien-tado a siste-mas que procesan flujos de datos, como soluciones comerciales, como pueden ser CoWare Codeveloper, Celoxica DK Codesign Suite, Xilinx Embedded Develop-ment Kit o Altera Nios II Integrated DevelopDevelop-ment EnvironDevelop-ment. Estas soluciones comerciales han ido reemplazando a los esfuerzos investigadores anteriormente mencionados, cada uno en su nicho de aplicación (por ejemplo, dispositivos de fabricantes concretos).

De una forma general, utilizando herramientas software específicas para rea-lizar codiseño HW/SW, podemos esperar un diagrama de flujo de diseño como el de la figura 2.2 (página 12). Normalmente cada uno de los pasos se realiza con una herramienta diferente, por lo que la integración de las distintas herramientas en un único flujo de diseño no es una tarea trivial.

(12)

Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño

Figura 2.2: Flujo de diseño utilizando herramientas de codiseño

2.4.1.

Especificación del Sistema

El primer paso para atacar la problemática de diseñar un sistema híbrido Hard-ware/Software es el realizar una descripción del sistema que se pretende imple-mentar en un lenguage de abstracción que esté por encima de los lenguages con-cretos en los que se describirán el software (por ejemplo, C) o el hardware (por ejemplo VHDL o Verilog). Esto es importante de cara a poder estudiar indivi-dualmente los bloques funcionales que compongan el diseño y su interacción abs-trayéndose de si la implementación de estos bloques se hará en hardware o en software. En definitiva, si el diseñador no es capaz de realizar esta descripción a alto nivel, es porque está dando por supuesto que ciertos bloques funcionales de la aplicación se implementarán de cierta forma concreta.

Algunos lenguajes que nos permiten realizar esta descripción a alto nivel del sistema son Matlab, Simulink, SystemC y los grafos de flujos de datos [SOIH97] de PeaCE. Es deseable que, en la medida de lo posible, estas descripciones de alto nivel sean directamente traducibles a descripciones software o hardware, de forma que, una vez decidido el particionado HW/SW, la síntesis de cada una de las partes sea automática.

(13)

Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño

2.4.2.

Simulación Funcional

El siguiente paso consiste en realizar una simulación funcional del sistema descrito, para comprobar si realmente la aplicación descrita coincide con las es-pecificaciones deseadas. Los lenguajes con los que se suelen realizar las descrip-ciones a alto nivel del sistema se distribuyen normalmente con simuladores que permiten realizar simulaciones funcionales de los sistemas descritos, por lo que la disponibilidad de un simulador raramente es un problema. Sólo cuando nuestra descripción a alto nivel es completamente funcional tiene sentido seguir adelante con el flujo de diseño para buscar una arquitectura óptima.

2.4.3.

Exploración del Espacio de Diseño

La exploración del espacio de diseño, se hace manualmente utilizando una herramienta de simulación TLM. El objetivo es evaluar las distintas alternativas de particionado y catalogarlas según rendimiento, para tomar una decisión respecto al particionado HW/SW que cumpla con los requerimientos del sistema.

2.4.4.

Co-Simulación TLM

Se trata de una simulación a nivel transaccional2. En un modelo transaccional, los detalles de la comunicación entre bloques computacionales están separados de las descripciones de dichos bloques. Los bloques computacionales y de comu-nicación se conectan a través de tipos abstractos de datos. La comucomu-nicación se modela a través de canales, de forma que las peticiones de transacción se realizan a través de funciones de interfaz correspondientes a los modelos de los canales de comunicación. Detalles innecesarios de la comunicación y la computación se ocultan en TLM pero pueden ser añadidos más adelante. TLM acelera la simu-lación y permite explorar y validar diferentes alternativas de diseño en un nivel superior de abstracción [CG03].

Algunas herramientas de simulación TLM disponibles en el mercado son Sy-nopsys CoCentric Studio, CoWare ConvergenSC y Axys MaxSim (para ARM).

2.4.5.

Co-Verificación HW/SW

El objetivo de este paso es comprobar que, tras el particionado, nuestro sis-tema tiene las mismas funcionalidades que en la descripción funcional y cumple con los requisitos adicionales que le hayamos impuesto3. Esta co-verificación es

2TLM son las siglas de Transactional Level Modelling 3Por ejemplo, ciertos requisitos de timing.

(14)

Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño

importante ya que si bien la simulación TLM realizada anteriormente es muy efi-ciente en tiempo, existen aspectos prácticos de los bloques computacionales del diseño que no se han considerado aún.

2.4.6.

Co-Simulación RTL

La coverificación HW/SW se hace normalmente a través de una cosimulación a nivel RTL4. Esto es un problema complejo en sí mismo ya que para realizar esta

cosimulación se necesita:

Un programa que simule adecuadamente y de forma precisa el HW, por ejemplo un simulador de VHDL o Verilog.

Un programa que simule adecuadamente y de forma precisa el comporta-miento del SW, es decir, un ISS5del procesador utilizado.

Integración fluida entre ambos programas. Esto se puede conseguir de dis-tintas maneras, por ejemplo modificando los simuladores para añadirles in-terfaces a medida6, consiguiendo una sincronización en tiempo de los

si-muladores, o aprovechando la capacidad que tienen algunos simuladores de generar ficheros de traza con los accesos a memoria para utilizar una técnica de sincronización virtual basada en la traza de memoria [KYH05], técnica que ofrece un mejor rendimiento en la simulación.

La herramienta comercial más popular en la actualidad para realizar coverifi-cación HW/SW es Mentor Seamless CVE, pero existen alternativas como Aldec HES (Hardware Embedded Simulation)7.

2.4.7.

Prototipado

Una vez que se tienen las descripciones de las partes hardware, software, e in-terfaces, se pueden utilizar herramientas que existen desde hace años para realizar la síntesis del hardware (herramientas de síntesis, y ‘placement and routing’ si el hardware se va a sintetizar sobre un circuito programable, como es nuestro caso) y del código objeto para el microprocesador (compiladores). En este momento

4Register Transfer Level. 5Instruction Set Simulator.

6Lo cual no es posible normalmente, ya que difícilmente se tiene acceso al código fuente de los simuladores.

7Pero a la hora de escoger las herramientas a utilizar, el aspecto más importante que hay que evaluar es si el procesador que se va a utilizar está soportado. Como se verá en el siguiente capítulo, en la plataforma inicialmente escogida para este proyecto se utiliza un procesador de señal (DSP) de Texas Instruments que carece totalmente de soporte en las herramientas comerciales

(15)

Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño

es cuando se fabrica un prototipo, sobre el que se demostrará de forma práctica el sistema híbrido funcionando. De esta experiencia se extraen conclusiones muy útiles de cara a la síntesis del sistema final.

2.4.8.

Síntesis del Sistema

Tras comprobar que el prototipo funciona correctamente y es apropiado para la aplicación que se quiere resolver, se procede a realizar la síntesis del sistema final.

(16)

Capítulo 3

Trabajo sobre Unshades-2

“We used to dream about this stuff. Now, we get to build it. It’s pretty neat"

– Steve Jobs

3.1.

Descripción de la plataforma Unshades-2

Unshades-2 es una plataforma híbrida FPGA-DSP para codiseño y co- depura-ción diseñada en el Departamento de Ingeniería Electrónica de la Universidad de Sevilla [ATBT03]. Unshades-2 es la segunda plataforma de la familia Unshades1,

una familia de tarjetas de desarrollo, basadas en FPGAs de Xilinx, especialmente diseñadas para realizar depuración hardware en tiempo de ejecución de diseños reales.

El propósito de la plataforma Unshades-2 es, por un lado, proporcionar in-formación comprensible sobre el estado interno de sus elementos, tanto software como hardware, mientras están funcionando (es decir, el sistema está diseñado para ser observable) y, por el otro, permitir al diseñador realizar cambios sobre dichos estados (es decir, el sistema es controlable). Esta observación y control se realizan a través de unos puertos de entrada/salida que se conectan a un PC, que debe disponer de las herramientas adecuadas para realizar la comunicación con la placa, y presentar la información al usuario de forma comprensible (véase la figura 3.1, en la página 17). De esta forma, el sistema se puede utilizar para depurar los módulos HW y SW de un sistema híbrido. Otro aspecto atractivo de Unshades-2 es que, al facilitarnos tanta información para la depuración, es conce-bible un sistema de desarrollo en el que más que realizar simulaciones de distintas soluciones de particionado y síntesis, podríamos probarlas directamente sobre la placa y medir sus rendimientos (tiempos de procesado, consumo de potencia).

(17)

Trabajo sobre Unshades-2 3.1 Descripción de la plataforma Unshades-2

Figura 3.1: Unshades 2. Fotografía

Unshades-2, al ser un sistema diseñado para la depuración simultánea de ele-mentos hardware y software, se planteó en un principio como una plataforma interesante sobre la que investigar distintas soluciones a este problema, por la fa-cilidad para extraer información útil que brinda. El trabajar sobre esta plataforma tiene en principio un cierto valor añadido, ya que aporta algo más que los elemen-tos hardware y software: gracias a la controlabilidad y observabilidad que presen-ta al diseñador, es especialmente útil para proyectos de investigación y desarrollo, puesto que podemos comprobar fácilmente si las decisiones que se van toman-do afectan positivamente o no al rendimiento de los módulos sintetizatoman-dos. En la figura 3.2, en la página 18, podemos ver una fotografía del sistema de desarrollo.

La plataforma Unshades-2 está construida alrededor de cuatro dispositivos: S-FPGA2 FPGA Virtex 100E / 1000E, de Xilinx [Xil02], compatible con el encapsulado PQ240, con 32400 y 331776 puertas lógicas equivalentes respectivamente.

(18)

Trabajo sobre Unshades-2 3.1 Descripción de la plataforma Unshades-2

(19)

Trabajo sobre Unshades-2 3.2 Herramientas Evaluadas

C-FPGA3de la familia Spartan II, compatible con el encapsulado QFP 144. DSP TMS320VC33, de Texas Instruments, de 16 bits y coma flotante. Este procesador pertenece a la familia C3x [Tex04] y el encapsulado con el que aparece en Unshades-2 es el PGE150.

Memoria flash de 256 kwords (512 kbytes), modelo Am29LV400B B-70R de AMD.

La conexión entre estos elementos se puede apreciar en la figura 3.2. Además, Unshades-2 dispone de otros elementos, como los puertos de expansión, entra-da/salida y enlace con PC.

3.2.

Herramientas Evaluadas

Durante el tiempo que se estuvo trabajando con Unshades-2, se estuvieron evaluando distintas herramientas de codiseño HW/SW. Desafortunadamente, las herramientas comerciales soportan sólo un pequeño subconjunto de los micropro-cesadores disponibles en el mercado, por lo que el primer escollo con el que nos encontramos al realizar el presente proyecto fue la falta de soporte para los proce-sadores de la familia C3x. Esto significa que, si queremos hacer codiseño con un procesador de esta familia, necesitaremos añadir nosotros mismos el soporte para este tipo de procesador, lo que nos hace descartar inmediatamente los programas que sean de código cerrado. Pero la mayoría de proyectos de codiseño que son de código abierto son proyectos de investigación que dejaron de actualizarse hace años4.

Entre los entornos de codiseño y herramientas que se evaluaron se encuentran: POLIS. Este trabajo académico ha sido realmente importante, y ha dado co-mo fruto muchas publicaciones que han servido de punto de partida para el presente proyecto [BGJ+97]. Incluso se planteó en principio como opción para el presente proyecto el realizar una adaptación de POLIS para añadirle la capacidad de realizar cosíntesis para la plataforma Unshades-2. El pro-blema principal que se ha encontrado con POLIS es que como proyecto dejó de ser activo y de tener base de usuarios hace varios años. La última versión

3Control FPGA, es una FPGA dedicada a realizar funciones de control como la programa-ción de la S-FPGA, control de las señales de reloj, control del DSP a través del puerto JTAG y readback/writeback del estado interno de la S-FPGA a través de las líneas Selectmap.

4Por ejemplo, la página web del proyecto Chinook (Department of Computer Science and En-gineering, University of Washington) no ha sido actualizada desde 1999, y COSYMA (COSYnthe-sis for eMbedded Achitectures, de la Technical University of Braunschweig) dejó de desarrollarse alrededor de 1998.

(20)

Trabajo sobre Unshades-2 3.2 Herramientas Evaluadas

de POLIS (0.4), es del año 2000, y los recursos adicionales como la lista de correo para los usuarios5ya no están disponibles.

Celoxica DK Design Suite. Este entorno de desarrollo de Celoxica está orientado a descripciones en alto nivel de sistemas híbridos en lenguajes de descripción no gráficos, como son HandelC y otras extensiones de C y C++. La herramienta da soporte para poder trabajar con los PowerPC 405 que se pueden encontrar en las FPGA Virtex II Pro y con el softcore Microbla-ze de Xilinx. El principal impedimento para poder utilizar esta herramienta comercial es que, como tantas otras, carece de soporte para DSPs de Texas Instruments.

Impulse Codeveloper. Impulse CoDeveloper, al igual que Celoxica DK De-sigh Suite, es una herramienta de codiseño hardware/software que permite describir un sistema híbrido utilizando una variante del ANSI C, en este ca-so Impulse C. Impulse C no es, técnicamente hablando, un subconjunto de ANSI C, ya que es posible hacer uso de todas las funcionalidades de C a la hora de programar un test bench o de describir los procesos SW que se ejecutarán en un microprocesador. Sin embargo, para los procesos que se traducirán directamente en diseños hardware, se imponen ciertas restriccio-nes al código Impulse C6. La herramienta soporta únicamente los micropro-cesadores Altera Nios, Xilinx Microblaze y los PowerPC de Xilinx Virtex II Pro.

Las herramientas de Xilinx, como Xilinx EDK (Embedded Design Kit), que tuvieron que ser descartadas para el trabajo con Unshades-2 ya que úni-camente soportan los procesadores que utilizan los dispositivos de Xilinx, como Microblaze o PowerPC. Únicamente utilizaremos las herramientas de Xilinx para hacer la síntesis de la parte HW de los diseños, ya que estamos trabajando con FPGAs de este fabricante.

PeaCE7 codesign environment. Más adelante, en el capítulo 8, se hará una descripción más detallada, pero por ahora comentaremos que de todas las aplicaciones evaluadas, es la única de la que realizar una adaptación a nues-tra plataforma es factible: es software libre (licencia tipo BSD), por lo que es posible modificarlo para añadir soporte para Unshades-2, es uno de los

5polis-users@ic.eecs.berkeley.edu

6Básicamente: soporte limitado para punteros, carencia de soporte para funciones recursivas, y ciertas restricciones sobre las instrucciones de control de flujo. Esto tiene mucho sentido, ya que si se tradujera directamente un programa C sin restricciones en su código a hardware el resultado distaría mucho de ser eficiente.

(21)

Trabajo sobre Unshades-2 3.3 Problemas Encontrados

pocos proyectos de investigación sobre codiseño que sigue activo y, co-mo añadido, los desarrolladores del proyecto han deco-mostrado interés en dar soporte a los usuarios del software que deseen utilizarlo con nuevas plata-formas. En PeaCE, tanto los algoritmos como la arquitectura del sistema híbrido se especifican a través de un interfaz gráfico desarrollado en Java. Por todo ello, una vez estudiadas las distintas herramientas de codiseño, se decidió optar en principio por añadir soporte para la plataforma Unshades-2 al entorno de codiseño PeaCE.

3.3.

Problemas Encontrados

Ya hemos visto en el apartado anterior que los DSP de Texas Instruments, en particular los de la familia C3x, carecen de soporte en las herramientas de codiseño disponibles. La experiencia con Unshades-2 nos ha descubierto ciertas dificultades que la plataforma plantea para su uso como sistema híbrido:

Falta de soporte para el procesador C33 por parte de las herramientas de codiseño HW/SW (como se ha visto anteriormente).

Falta de toolchain GNU para el procesador. En realidad existe una adap-tación del compilador gcc8 para las familias de DSP C3x y C4x, llamado c4x-gcc, pero se necesita una versión concreta de una biblioteca runtime propietaria de Texas Intruments, de la que no disponíamos, para poderlo compilar. Sin esta biblioteca, el compilador únicamente puede generar fi-cheros objeto (.o), y no ejecutables. Al no poder utilizar el compilador de GNU, la única opción posible era utilizar un compilador propietario de Te-xas Instruments, que originaba otros problemas, entre ellos imposibilidad de utilizar el simulador libre del que disponíamos para el DSP (c4x-gdb9).

Carencia de ISS para el procesador. Esto ha sido sorprendente ya que se han evaluado tres simuladores distintos para el C33. La problemática aquí estriba en que para que un simulador del juego de instrucciones de un proce-sador pueda ser utilizado para hacer cosimulación HW/SW, debe de poderse interconectar a un simulador de VHDL o Verilog que simule la parte HW del diseño. Es decir, que para que un ISS pueda ser utilizado debe de tener

8GCC son las siglas de Gnu Compiler Collection.

9Realmente gdb es un depurador (Gnu Debugger), y c4x-gdb está diseñado para ser conectado a placas autónomas basadas en procesadores c3x/c4x a través de conexión por puerto serie o por socket TCP/IP. Pero aparte de esto, c4x-gdb incluye un modo de funcionamiento en el que se conecta a un simulador de estas familias de DSP desarrolado por Herman Ten Brugge.

(22)

Trabajo sobre Unshades-2 3.3 Problemas Encontrados

un modelo de memoria flexible que se pueda adaptar para conectarlo al si-mulador de la parte HW, o bien ser de código abierto para poder realizar las modificaciones necesarias, o en última instancia debe ser capaz de gene-rar un fichero con la información de los accesos a memoria (un fichero de traza).

El primer simulador que probamos fue Sim3x, un simulador desarrollado por Texas Instruments para ms-dos (que ejecutamos sin problemas bajo Li-nux utilizando Dosbox10), y descubrimos que no se puede integrar con

nin-guna otra herramienta ya que el programa no está preparado para interactuar con otros programas, ni permite generar ficheros de traza. Por supuesto, la modificación del programa para añadirle esa funcionalidad era imposible ya que no disponíamos de su código fuente.

La segunda alternativa estudiada fue la posibilidad de generar la informa-ción de traza con los accesos a memoria utilizando Code Composer (un programa para Windows que se ejecutaría en Linux a través de Wine), em-pleando un lenguage de scripting de Code Composer llamado GEL11. Esta alternativa era de una complejidad considerable, ya que habría que escribir un programa que, tras la compilación del software, analizara el código ob-jeto presente en el fichero .out, localizara en él los accesos a memoria, y posteriormente generara un script GEL que colocara breakpoints (puntos de ruptura) en cada uno de dichos accesos. Además, habría que definir funcio-nes específicas en GEL para intentar recoger la información de los tiempos y ciclos de acceso. Aunque teóricamente este enfoque podría funcionar, la viabilidad práctica de esta solución depende de las capacidades reales del lenguaje GEL y aún no ha sido demostrada. Por otro lado, el trabajo ne-cesario para implementar esta solución escapa al alcance de este proyecto, por lo que en su momento se prefirió centrar los esfuerzos en resolver los problemas que planteaba el simulador c4x-gdb.

El último simulador que fue evaluado fue c4x-gdb, la única de las tres al-ternativas que es de código abierto. Ya hemos comentado que, al no poder utilizar el compilador c4x-gcc, por las razones comentadas anteriormente, era imposible utilizar el simulador c4x-gdb.

Escasez de memoria RAM. Hemos visto en la sección 3.1 que la platafor-ma no posee ningún dispositivo de RAM on-board. Es posible instanciar pequeñas memorias RAM dentro de la FPGA, de forma para que el DSP pueda tener un mínimo espacio sobre el que trabajar con datos, pero como

10Ya que PeaCE se ejecuta bajo Red Hat Linux 8.0, todo programa que queramos integrar con PeaCE debe funcionar a su vez en Linux, aunque sea tras una capa de emulación.

(23)

Trabajo sobre Unshades-2 3.4 Conclusiones

máximo disponemos de 393,216 bits (48KBytes) de block RAM en la Vir-tex 1000E [Xil02] (en el caso de VirVir-tex 100E son únicamente 10KBytes). Si bien puede ser suficiente memoria para manejar ciertas cantidades de datos, hay que tener en cuenta que en un sistema híbrido HW/SW las tareas que han sido implementadas en software han de compartir el microprocesador, lo que significa que necesitamos memoria para guardar la información del contexto de los procesos y de la pila. Además, no podríamos tener un siste-ma operativo como Linux ejecutándose en la placa (ya que un sistesiste-ma Linux necesita un mínimo de 1MB de RAM para ejecutarse, más RAM adicional para las aplicaciones), y es muy posible que eCos12, si bien es un sistema operativo altamente configurable, tenga una huella mínima de uso de RAM superior a los 48KB. Recordemos que estos 48KB han de compartirse con los requerimientos de memoria de la parte SW del diseño.

Interfaz FPGA-DSP fija, ya que son pistas en el PCB: es posible que la S-FPGA tenga que enviar ciertas señales al DSP y no pueda hacerlo por-que esas pistas no estén conectadas a ella. Si bien este problema no ha sido estudiado a fondo, si llegara a ocurrir podría eliminar por completo la posi-bilidad de hacer codiseño con Unshades-2.

Falta de sistemas operativos de tiempo real para el procesador. Actualmente no existen versiones de Linux o eCos para el procesador C33. Si bien es teóricamente posible realizar un portado de estos sistemas a nuestro DSP, ello escapa al alcance del presente proyecto. La única alternativa para poder conmutar entre las tareas en software es programar un mínimo planificador de tareas.

Es por todas estas razones por lo que se decide abandonar el desarrollo sobre Unshades-2. En el siguiente apartado se exponen las conclusiones de la investiga-ción sobre Unshades-2 y en el capítulo 4 se propone una soluinvestiga-ción alternativa para poder realizar codiseño, con otra plataforma hardware.

3.4.

Conclusiones

3.4.1.

Cambio de plataforma

Teniendo en cuenta los resultados expuestos en los apartados anteriores, rea-lizar codiseño con Unshades-2 sin modificar la plataforma hardware es una tarea que roza lo imposible. Además, los esfuerzos necesarios para hacer codiseño en

(24)

Trabajo sobre Unshades-2 3.4 Conclusiones

dicha plataforma sobrepasan con creces el alcance de un proyecto de fin de carre-ra. Es por esto por lo que se propone un cambio de plataforma hardware: sabiendo tras la evaluación de las herramientas software (sección 3.2) que el soporte pa-ra ciertos softcores está sobpa-radamente extendido, se plantea el realizar codiseño sobre una plataforma que únicamente disponga de una FPGA de gran capacidad. De esta forma se instanciarán un microprocesador y la parte HW del diseño en el mismo dispositivo. La plataforma propuesta es la placa de desarrollo XSV-800 de Xess. En el capítulo 6 se hará una descripción más detallada de dicha plataforma.

3.4.2.

Línea de trabajo sobre Unshades-2

Otra conclusión del trabajo realizado, además del mencionado cambio de pla-taforma, es el trabajo concreto que habría que hacer para conseguir hacer codiseño con Unshades-2 utilizando herramientas de codiseño.

Si se quisiera realizar el esfuerzo, habría que:

Programar un simulador del procesador C33 o adaptar las c4x GNU tools para que funcionen utilizando Newlib (para esto necesitaríamos primero realizar el portado de Newlib al C33).

Portar eCos (ya que no podemos utilizar Linux por falta de RAM) al C33. Nótese que para portar eCos también necesitamos haber portado primero Newlib. Si no queremos portar eCos, es necesario programar un planifica-dor de tareas que se encargue de guardar los contextos de las tareas software y manejar la pila. De todas formas, es poco probable que toda esta funcio-nalidad se pueda conseguir con tan sólo 48KB de RAM.

Con esto tendríamos las mínimas herramientas que hacen falta para poder em-pezar a integrar el soporte para Unshades-2 en PeaCE. Aún quedaría por realizar todo el trabajo de integración con el framework de codiseño.

3.4.3.

Consideraciones para una posible Unshades-2.1

En mi opinión el trabajo mencionado en el apartado anterior no compensa el esfuerzo que es necesario realizar: sería más sencillo modificar Unshades-2 para permitir una adaptación más sencilla y realizable. Por ello se proponen las siguientes sugerencias y modificaciones, para que sean consideradas para una po-sible versión 2.1 de Unshades:

Procesador: el primer cambio que se propone consiste en cambiar el DSP de Texas Instruments por un procesador ampliamente soportado, para el que

(25)

Trabajo sobre Unshades-2 3.4 Conclusiones

estén disponibles las herramientas anteriormente mencionadas, como podría ser un ARM13o un ASIC Leon.

Interfaces FPGA-P : para evitar que el interfaz fijo FPGA-P sea una fuen-te de problemas, fuen-tenemos dos opciones: la primera es estudiar cuidadosa-mente alguna placa ya existente para codiseño HW/SW que utilice el proce-sador escogido, para que quede perfectamente claro qué pines delP deben conectarse a la FPGA. La segunda es que todos los pines del procesador pasen por la FPGA antes de llegar a los dispositivos de la placa, opción que añade muchísima flexibilidad a la plataforma y que curiosamente es es lo que ocurre cuando se utiliza un softcore.

RAM: Es necesario añadir una cantidad suficiente de RAM on-board pa-ra poder tener un sistema opepa-rativo y tpa-rabajar de forma cómoda. Con un mínimo de 4 megas ya podemos tener sistemas Linux con aplicaciones es-pecíficas (sin soporte para TCP/IP14) sin que la memoria sea una restricción

preocupante. Lo ideal, para aprovechar toda la potencia que ofrece Linux, es utilizar módulos DIMM, que se pueden encontrar en cualquier tienda de in-formática y nos permiten tener una capacidad de RAM del orden de cientos de megabytes.

13Si bien la mayoría de modelos de ARM goza de un buen soporte por parte de las herramientas de software libre típicas (gcc, eCos, newlib), recomendamos con más énfasis aquellos dos modelos de ARM que ya disponen de soporte completo en PeaCE: ARM 926EJS y ARM 720T.

14El soporte para TCP/IP y las aplicaciones que lo utilizan consumen una gran cantidad de memoria.

(26)

Capítulo 4

Solución propuesta

“A real decision is measured by the fact that you’ve taken a new action. If there’s no action, you haven’t truly decided."

– Anthony Robbins

Tras encarar los problemas encontrados en Unshades-2, se propuso una solu-ción para hacer codiseño utilizando una plataforma hardware distinta, basada en una FPGA suficientemente potente como para albergar el softcore y la parte HW de un diseño híbrido. En principio teníamos dos placas disponibles, FT-Unshades1 y Xess XSV-800. Escogimos la segunda por varias razones: por tener ésta una disponibilidad mayor (ya que las placas FT-Unshades de las que dispone el de-partamento están normalmente ocupadas en proyectos de investigación), porque las herramientas para programar los dispositivos on-board están disponibles pa-ra Linux2, y porque la distribución del softcore Leon 2 soporta oficialmente la

placa XSV-800, lo que en principio facilita una de las tareas a realizar, que es la implementación correcta del softcore en la placa de desarrollo.

4.1.

Descripción de la solución propuesta

La solución que aquí se propone consiste básicamente en una solución soft-core en la que todos los elementos del sistema híbrido están implementados en la FPGA. Esto permite extender el trabajo realizado a otras placas con un poco de esfuerzo adicional.

1Fault-Tolerant Unshades, la plataforma más moderna (a fecha de 2006) de la familia Unsha-des, desarrollada por el Área de Ingeniería Electrónica en un proyecto para la Agencia Espacial Europea, y especialmente preparada para realizar pruebas de tolerancia a fallos sobre circuitos para aplicaciones espaciales.

2Cuando se comenzó el presente proyecto, las herramientas de FT-Unshades únicamente esta-ban disponibles para Windows. Actualmente las herramientas de FT-Unshades funcionan perfec-tamente bajo Linux, ya que fueron portadas en Marzo de 2006.

(27)

Solución propuesta 4.1 Descripción de la solución propuesta

La plataforma sobre la que implementaremos el sistema es la placa de desa-rrollo XSV-800, de la X Engineering Software Systems Corporation (Xess). Esta placa posee suficiente RAM (2MBytes) y demás recursos on board y será descrita en más profundidad en el capítulo 6. De dicha placa bastará comentar por aho-ra que dispone de una FPGA Virtex XCV-800 [X E01b, Xil00], que dispone de aproximadamente 800000 puertas equivalentes (contando RAMs internas), lo cual es suficiente para implementar un softcore con varios periféricos y algún módulo hardware específico.

En la FPGA Virtex XCV-800 implementaremos un procesador Leon 2, un modelo VHDL sintetizable de un procesador de 32 bits que cumple con el estándar Sparc V8. Las fuentes de este softcore están disponibles libremente bajo licencia GNU LGPL. Este procesador, junto con las razones por las que se ha escogido en lugar de alternativas como Microblaze, serán descrito en el capítulo 5 y, entre sus características, podemos destacar el hecho de que incluye una implementación del bus AMBA (versión 2.0), lo que permite añadir periféricos y otros módulos hardware de manera sencilla.

Dado que necesitamos un sistema operativo sobre el que se ejecuten las tareas software, la parte SW del diseño correrá sobre Snapgear Linux, una distribución de Linux para sistemas integrados con soporte para el procesador Leon. Snapgear Linux es una variante deClinux y en el capítulo 7 la describiremos y comenta-remos las ventajas que nos ofrece.

El entorno de codiseño propuesto para realizar codiseño es PeaCE, debido a las ventajas que ofrece, que se han comentado en el capítulo anterior y se verán en más profundidad en el capítulo 8. Además, otra razón para utilizar este entorno es que al no existir herramientas comerciales de codiseño HW/SW que tengan soporte para la familia de procesadores Leon, hemos de escoger una herramienta de código abierto a la que se pueda añadir soporte para estos procesadores.

(28)

Solución propuesta 4.1 Descripción de la solución propuesta

(29)

Capítulo 5

Procesador Leon 2

“You should probably read the manual"

– Jiri Gaisler, almost daily, on the leon-sparc mailing list

Tras considerar las alternativas como Microblaze o softcores basados en ARM, se llegó a la conclusión de que el softcore más apropiado para ser utilizado en un proyecto basado en Linux es el procesador Leon 2, ya que es de código abierto y viene acompañado de las herramientas necesarias, que también son de código abierto: compiladores C, versión de Newlib, y versiones de eCos y Linux. En la sección 5.2 justificaremos en profundidad esta decisión.

5.1.

Descripción

El procesador Leon [Gai05] es una implementación en VHDL de un proce-sador de 32 bits compatible con el juego de instrucciones Sparc V8 [SPA92], desarrollado para la Agencia Espacial Europea y mantenido en la actualidad por Gaisler Research. Este procesador no sólo es de código abierto, sino que además no está ligado a ninguna tecnología de FPGA concreta, a diferencia de soluciones dependientes de fabricantes como Microblaze de Xilinx o Nios II de Altera.

Entre sus características se pueden destacar: Cachés de instrucción y datos independientes Alu para mutiplicación y división hardware

Interfaz para unidades de coma flotante y coprocesadores Bus AMBA 2.0

(30)

Procesador Leon 2 5.1 Descripción

Controlador de memoria flexible, capaz de trabajar con SDRAM en modo 32 bits y con SRAM y ROM en modos configurables de 8, 16 o 32 bits Puerto de entrada y salida de 16 bits

Dos UARTs

Dos timers de 24 bits

Unidad de Soporte de Depuración (DSU)

5.1.1.

Diagrama de bloques

Figura 5.1: Diagrama de bloques del procesador Leon 2

El elemento central del procesador Leon 2 es su Integer Unit de 5 etapas pi-pelined. Esta Integer Unit está conectada a las cachés de instrucción y datos, y a la MMU1. Ambas cachés son de tamaño configurable y pueden incluso no ser

sintetizadas. La MMU también es opcional, y en este proyecto no se ha utilizado. En la figura 5.1 (página 30) se puede observar también la presencia de una unidad de punto flotante (Floating Point Unit o FPU) y de un co-procesador (CP), aunque en realidad el procesador Leon 2 no se distribuye con ninguno de estos elementos, sino que Gaisler Research dispone una unidad de punto flotante que se licencia de forma separada2, y es el usuario el que puede o no implementar su propio

co-procesador: el procesador Leon 2 implementa únicamente los interfaces a los que

1Memory Management Unit.

2Se trata de la GRFPU (Gaisler Research Floating Point Unit), aunque existen otras alternati-vas como la Meiko FPU y la LTH FPU.

(31)

Procesador Leon 2 5.1 Descripción

se conectarían el co-procesador y la FPU. No obstante, una síntesis del procesador Leon 2 sin ninguno de estos elementos es perfectamente funcional, aunque tenga menor rendimiento, y es la implementación que se ha realizado en este proyecto.

Otro elemento muy interesante de este procesador es la Unidad de Soporte de Depuración (Debug Support Unit o DSU), que permite conectar un PC al proce-sador a través del puerto serie, ethernet o JTAG, para ayudar a la depuración de software, permitiendo la depuración on-line. Gracias a la DSU se pueden cargar programas directamente desde el PC, pausar y resetear el procesador, establecer puntos de ruptura (breakpoints) e incluso realizar ejecución paso a paso.

5.1.2.

Bus Amba

El procesador Leon implementa dos buses AMBA: AHB y APB. El bus APB3 se utiliza para acceder a los registros on-chip de los periféricos, mientras que el bus AHB4 se utiliza para transferencia de datos a alta velocidad. El bus AMBA

hace muy sencillo extender la funcionalidad del procesador añadiendo módulos hardware. Incluso permite reutilización de código hardware, tanto del propio que desarrolle el diseñador como de módulos IP de otros desarrolladores [ARM99]. El mercado de propiedad intelectual pone al alcance de cualquier diseñador una biblioteca enorme de diferentes periféricos y unidades de proceso de datos [Gai04, Ope]. Debido a la gran aceptación que tiene el bus AMBA en la industria, se pueden encontrar fácilmente módulos hardware ya preparados para su conexión a dicho bus.

Rango de direcciones Tamaño Registro Módulo

0x00000000 - 0x1FFFFFFF 512 M Prom Controlador

0x20000000 - 0x3FFFFFFF 512 M Memory bus I/O de memoria

0x40000000 - 0x7FFFFFFF 1G SRAM y/o SDRAM

0x90000000 - 0x9FFFFFFF 256 M DSU DSU

0xB0000000 - 0xB001FFFF 128 K Registros Ethernet

ethernet MAC

Figura 5.2: Mapa de memoria AHB del procesador Leon 2

El mapa de memoria que aparece en la figura 5.2, en la página 31, es el mapa que se encuentra por defecto en la distribución oficial del procesador Leon 2, pero

3Advanced Peripheral Bus. 4AMBA High-performance Bus.

(32)

Procesador Leon 2 5.2 Alternativas al procesador Leon 2

si fuera necesario podría modificarse. Además, el mapa de memoria del procesa-dor no acaba aquí: los periféricos del procesaprocesa-dor están conectados al bus APB, cuyo mapeo en memoria empieza en la dirección 0x80000000 (Memory configu-ration register 1), y la última dirección ocupada es la 0x800000CC (DSU UART scaler register), por lo que a partir de la dirección 0x800000D05 se pueden añadir periféricos ‘custom’ (teniendo en cuenta que a partir de la 0x90000000 vuelven a estar ocupadas, en este caso por la DSU). La tabla con los registros concretos y las direcciones de memoria en las que están situados es demasiado extensa como para colocarla en el presente documento pero puede ser encontrada en el manual del procesador Leon 2 [Gai05].

5.2.

Alternativas al procesador Leon 2

El procesador Leon 2 no es el único softcore que se puede implementar en una FPGA, por lo que en su momento se realizó un estudio de softcores disponibles, para tomar una decisión informada sobre cuál utilizar:

1. Procesadores basados en ARM: la primera alternativa de softcore que se consideró fue una implementación de un procesador ARM que se realizó como proyecto de fin de carrera en el departamento en 2002 [CTAT02]. No se usó porque, si bien las instrucciones del juego ARM fueron probadas una por una con éxito, para garantizar el cumplimiento total de las especificacio-nes ARM de este procesador habría que utilizar vectores de test propietarios que sólo están disponibles para los desarrolladores que tengan licencia de ARM, por lo que se desconoce si este softcore funcionará adecuadamente al ejecutar programas complejos, como los producidos por un compilador C (en contraposición a los generados manualmente en ensamblador). Además, si bien el código VHDL del proyecto tiene una licencia de libre distribución, es posible que la distribución e implementación del core ARM en sí viole ciertas patentes de ARM. Todas estas dificultades, que surgen a causa de la proliferación de estándares cerrados, impiden el uso de este interesante core VHDL para nuevos proyectos. Esta situación es bastante desafortunada, ya que los procesadores ARM disponen de muchísimas herramientas como si-muladores (Armulator), bibliotecas runtime (glibc y Newlib), compiladores e incluso un port de la distribución Debian GNU/Linux6.

5Realmente es a partir de la 800000E0, ya que estudiando detalladamente el código del proce-sador Leon 2 se ha visto que en la dirección 0x800000D0 hay asignado un registro correspondiente al ‘PCI target mapping’.

(33)

Procesador Leon 2 5.2 Alternativas al procesador Leon 2

Además, como se ha comentado en el capítulo 3, PeaCE ya trabaja con dos modelos de ARM (ARM 926EJS y ARM 720T). Dichos modelos están perfectamente integrados en el entorno, lo que significa que existe mucho trabajo ya realizado que se podría reutilizar.

2. Microblaze: este procesador, en principio, y ya que nosotros trabajamos con FPGAs de Xilinx, es una alternativa igual de válida que el procesador Leon 2. Pero hagamos unas consideraciones adicionales, pensando en la posibili-dad de reutilizar los esfuerzos del presente proyecto en otros proyectos de investigación, sabiendo que muchos de los que se realizan actualmente en el Departamento de Ingeniería Electrónica comprenden la depuración hard-ware y/o la realización de pruebas de tolerancia a fallos: ¿Cómo se hace depuración de HW/SW sobre Microblaze si es cerrado? ¿Dónde introduces un SEU7 para hacer pruebas de tolerancia a fallos? ¿Cómo sabes bien qué estás leyendo o modificando? Será posible hacer ingeniería inversa, pero, ¿merece la pena el esfuerzo? Además, en general para estos softcores de-pendes de las herramientas (compilador, simulador, c runtime library, S.O. en tiempo real) que te proporcione el fabricante8. Por otro lado, la

reutiliza-ción de software se complica si se utilizan sistemas operativos propietarios del fabricante (Nucleus o Xilkernel, en el caso de Microblaze), aunque tam-bién existe una versión deClinux para Microblaze.

3. Nios II: para este procesador de Altera son válidas las consideraciones rea-lizadas para Microblaze, pero con el agravante adicional de que difícilmente la implementación podrá realizarse y, en caso de que se pueda, no será nada eficiente en una FPGA de Xilinx.

4. Leon 3: este procesador, que es la evolución natural del procesador Leon 2, está escrito en un VHDL más difícil de entender que Leon 2, no posee compatibilidad binaria con éste, está peor documentado (a fecha de Octubre de 2005), y el único simulador disponible para él es el propietario TSIM. No obstante, ofrece mejores prestaciones9por lo que en el futuro, a medida

que Leon 3 se vaya imponiendo como estándar de facto y Leon 2 vaya dejando de tener soporte, será inevitable considerar Leon 3 para proyectos de investigación y aplicación.

7Single Event Upset.

8Aunque en muchos de los casos, las herramientas de diseño de los fabricantes ejecutan en segundo plano versiones parcheadas de las herramientas GNU, como por ejemplo el mb-gcc, com-pilador de c para microblaze, lo cual da que pensar.

9A costa de una mayor ocupación en área, por lo que para nuestra tarjeta de desarrollo es mejor idea utilizar Leon 2.

(34)

Procesador Leon 2 5.2 Alternativas al procesador Leon 2

5. Leon 2: Leon 2 es un procesador con mayor base de usuarios (a fecha de Octubre de 2005, cuando se hicieron estas consideraciones), con todas las herramientas necesarias disponibles, incluso tenemos la opción de simu-lar tanto con TSIM como con el simulador generado por ArchC [RABA04, ARB+05], una herramienta de libre distribución que nos permite generar si-muladores interpretados, sisi-muladores compilados y ensambladores a partir de una descripción de la arquitectura del procesador10. Como se ha comen-tado anteriormente, nos hemos fijado en Leon por ser de código abierto, y por no estar ligado a ninguna tecnología de FPGA concreta. Además de lo que se ha comentado anteriormente sobre Leon 3, una de las razones por las que se ha escogido para este proyecto Leon 2 es porque existe un ‘board support package’ para la placa XSV-800 para Leon 2 que no existe para Leon 311.

6. Distintos cores del proyecto opencores [Ope]: se estuvieron evaluando al-gunos diseños del proyecto opencores, y en su momento se encontró que algunos no están terminados, otros están hechos pero no tienen todas las herramientas que necesitamos (diseñar el procesador es sólo el primer paso, el segundo es portar el toolchain GNU, y partir de ahí se pueden portar las herramientas y bibliotecas necesarias, pero ello requiere un esfuerzo consi-derable), y un problema mayor que plantean es que se desconoce si violan patentes, copyrights u otra clase de propiedad intelectual12. De entre los

procesadores evaluados, hay uno muy interesante, OpenRisc, descrito en Verilog, cuyo desarrollo está completo y tiene su propio port del toolchain GNU e incluso un ISS. Este procesador se plantea como una buena alterna-tiva a Leon, pero dado que nosotros vamos a trabajar la parte HW de nuestro diseño en VHDL (ya que PeaCE trabaja con VHDL), e integrar VHDL con Verilog, si bien es factible, es poco conveniente y en algún momento podría causarnos problemas, por lo que finalmente se optó por utilizar el procesa-dor Leon 2.

10Actualmente, los desarrolladores del proyecto ArchC están trabajando en la descripción ArchC del procesador Leon 2

11Más adelante comprobamos que dicho ‘board support package’ no producía los resultados que eran de esperar, resultando en una netlist incorrecta, por lo que se tuvo que realizar la síntesis manualmente utilizando Xilinx ISE.

12De hecho, entre los disclaimers que acompañan a los diseños de opencores, se pueden en-contrar mensajes como: "I have no idea if implementing this core will or will not violate patents, copyrights or cause any other type of lawsuits. I provide this core as is, without any warranties."

(35)

Procesador Leon 2 5.3 Configuración del modelo

5.3.

Configuración del modelo

El modelo se configura utilizando una herramienta basada en Tk que se dis-tribuye con el mismo, por lo que hay que asegurarse de tener instaladas dichas herramientas. En Red Hat 8.0 se puede indicar durante el proceso de instalación del sistema operativo que queremos instalar las herramientas Tk. La figura 5.3 es una captura de pantalla de la herramienta de configuración que muestra la confi-guración de las memorias caché on-chip. La versión concreta de Leon 2 que se ha utilizado es la 1.0.30 xst, y las características fundamentales de la configuración utilizada son:

Ausencia de unidad de manejo de memoria (MMU), unidad de punto flo-tante (FPU) y coprocesador (CP).

La unidad de enteros (integer unit) se ha configurado de forma que pueda responder a las instrucciones MUL/DIV del juego de instrucciones de Sparc V8, y se ha inferido un multiplicador para que estas instrucciones no tengan un tiempo de ejecución excesivo.

Tecnología objetivo Virtex.

Cachés de instrucciones y datos, cada una consta de 1 set de 4Kbytes y 32 bytes por línea.

Unidad de Soporte de Depuración (DSU) habilitada.

Controlador de memoria SRAM de 16 bits de ancho del bus de datos. Además, hemos modificado el wrapper leon_eth_xsv800.vhd, uniendo los pi-nes RTS13y CTS14de la UART 1 (señales PIO(13) y PIO(12) del procesador), que es la que utilizaremos para establecer una comunicación con Snapgear Linux, a través del programa minicom15. Es necesario realizar esto ya que, en caso

contra-rio, Snapgear se cuelga al arrancar, durante la inicialización de la UART, ya que los pines que pretende utilizar para realizar el control de flujo por hardware (RTS y CTS) no están mapeados al exterior de la FPGA. Esto es así ya que la placa XSV-800 sólo dispone de un chip MAX232, lo cual significa que sólo tenemos cuatro señales disponibles: TX, RX, CTS y RTS, de forma que la UART1 de Leon 2 utiliza únicamente TX y RX, y la DSU transmite y recibe utilizando las pistas CTS y RTS. De hecho, para la realización de este proyecto se ha fabricado un

13Request To Send. 14Clear To Send.

15Unir los pines CTS y RTS de una UART no es ninguna novedad: es lo que muchísimos cable modem nulos (null modem cables) hacen ya.

(36)

Procesador Leon 2 5.3 Configuración del modelo

(37)

Procesador Leon 2 5.4 Añadiendo la parte HW de tu diseño a Leon 2

XSV-800 Conector serie 1 (UART) Conector serie 2 (DSU) (conectará con minicom) (conectará con grmon

TD RD

-RD TD

-CTS (Rx) - TD

RTS (Tx) - RD

GND GND GND

Figura 5.4: Esquema del cable serie en Y

cable en Y que permite realizar dos comunicaciones serie con la placa XSV-800 (ver figura 5.4 en la página 37). Para evitar las optimizaciones agresivas, hemos mapeado esta señal rts-cts a un pin de la FPGA (concretamente, a uno de los leds del diagrama de barras).

Tenemos que añadir que en principio se intentó realizar la síntesis del proce-sador Leon con el módulo ethernet, pero esto no fue posible debido a un problema con los IOB16de la FPGA. Si bien este problema es solucionable, no se le prestó demasiada atención ya que nuestra placa de desarrollo está tan limitada en sus recursos RAM que aunque implementemos el módulo ethernet no podremos tener ninguna aplicación de red significativa, ya que este tipo de aplicaciones suelen demandar bastante RAM durante su ejecución.

5.4.

Añadiendo la parte HW de tu diseño a Leon 2

Para añadir la parte hardware de un diseño a Leon 2, tenemos en principio 3 opciones:

1. Utilizar el interfaz genérico para conectar el Leon a un co-procesador: de es-ta forma, el bloque HW haría las veces de coprocesador. Como venes-taja tiene que tendrá una rapidez considerable, ya que el interfaz conecta de una for-ma muy directa con el núcleo de la CPU, pero como desventajas tiene que el interfaz es bastante específico, por lo que no es extensible a otros pro-cesadores, y además puede ser muy complicado realizar una exploración del espacio de diseño, y que para utilizar este enfoque se requiere obvia-mente que no dispongamos ya de un co-procesador que queramos utilizar. Como nota a considerar, comentaremos que realmente en muchos casos el codiseño hardware/software se plantea como el sintetizar ciertas tareas en

(38)

Procesador Leon 2 5.4 Añadiendo la parte HW de tu diseño a Leon 2

un módulo hardware que actúa de co-procesador (recordemos el caso de Impulse C).

2. Añadir la parte HW del diseño como un periférico AHB, muy útil si que-remos transferir grandes cantidades de información entre las partes HW y SW del diseño.

3. Añadir la parte HW del diseño como un periférico APB, con una tasa de transferencia de información menor, pero mucho más sencillo de imple-mentar, es la elección ideal si las operaciones que se realizan en el interfaz HW/SW son operaciones de control más que de transferencia de grandes volúmenes de datos.

En la aplicación de demostración realizada en el capítulo 9 utilizamos el bus APB, para demostrar lo sencillo que es añadir módulos HW, y también porque se trata de una aplicación de muy poca complejidad que no necesita de interfaces avanzados.

Para añadir la parte HW de la aplicación de demostración, hay que definir dos señales en el módulo que correspondan a los buses de entrada y salida APB, modificar el fichero mcore.vhd para añadir nuestro componente ‘hwpart’ como un periférico APB esclavo, y modificar apbmst.vhd para que extender la decodi-ficación de las direcciones, de forma que nuestro periférico sea reconocido en la dirección de memoria que hemos escogido (concretamente la 800000E0). Ade-más, ya que la parte HW del diseño actúa directamente sobre leds de la placa, hay que modificar todos los ficheros de los niveles superiores en la jerarquía hasta lle-gar al wrapper externo (mcore.vhd, leon_eth.vhd y leon_eth_xsv800), y además añadir los pines de los leds al ucf.

(39)

Capítulo 6

Placa de desarrollo XSV-800

“Playfully doing something difficult, whether useful or not, that is hacking"

– Richard Stallman, attributed

6.1.

Descripción

La plataforma sobre la que se ha implementado el sistema es la placa de de-sarrollo XSV-800 de Xess [X E01b]. Esta plataforma nos permite demostrar un sistema mínimo sobre una FPGA Virtex XCV800, de aproximadamente 800000 puertas equivalentes, si en la cuenta de puertas equivalentes incluimos a las RAM internas. Tanto la FPGA como la placa de desarrollo están ya descatalogadas, y los recursos en la placa están bastante limitados en relación a lo disponible hoy en día.

La placa de desarrollo dispone únicamente 2MB de memoria SRAM, que se han de compartir entre la imagen desde la que se arrancará el sistema operativo y la memoria disponible para los procesos del sistema, ya que no vamos a utilizar la Flash. Esta Flash comparte pines del bus de direcciones con los interruptores DIP presentes en la placa, que utilizamos para activar la DSU del procesador, por lo que no podemos utilizar la Flash.

(40)

Placa de desarrollo XSV-800 6.1 Descripción

(41)

Placa de desarrollo XSV-800 6.2 Configuración

6.2.

Configuración

6.2.1.

Configuración de jumpers

La figura 6.2 muestra la configuración de jumpers utilizada.

Jumper Configuración Efecto

J13 y J14 Abiertos Alimentación utilizando

fuente ATX

J32 Shunt en pines 1-2 La alimentación de 2.5V para la FPGA se genera en la placa J22 Shunt en pines 2-3 Oscilador programado

Shunt en pines 1-2 Oscilador en modo programación J36 Shunt en pines 1-2 CLK interno

(generado por el oscilador)

J23 Abierto La CPLD no puede ser reprogramada

Cerrado La CPLD puede ser reprogramada J29, J30 y J31 Shunts en pines 2-3 Permiten el uso de xsload

Figura 6.2: Configuración de jumpers empleada

Los jumpers J37, J18, J34, J33, J16 sirven para configurar el puerto USB, y su disposición concreta no influye en nuestra aplicación ya que no utilizamos dicho puerto. Igualmente ocurre con los jumpers de otros dispositivos on-board, como el RAMDAC VGA. Para los jumpers para los que aparecen dos configuraciones, se utiliza una u otra según el efecto deseado.

6.2.2.

Frecuencia de reloj

Se ha programado el reloj de la FPGA a 20MHz. Como el oscilador es de 100MHz, esto significa que hemos programado el divisor de frecuencias a un valor de 5. Esto se hace utilizando la utilidad xssetclk, siempre que hayamos con-figurado adecuadamente el jumper J22.

6.2.3.

Reprogramación de la CPLD

Ha sido necesario reconfigurar la CPLD presente en la placa para permitir el acceso por el puerto serie al procesador que implementaremos en la Virtex. Esto es indispensable para nuestro sistema, ya que el sistema operativo que introduci-remos en la placa de desarrollo mapeará su entrada y salida de consola a través del puerto serie.

(42)

Placa de desarrollo XSV-800 6.3 Xstools

Figura 6.3: Diagrama de bloques de la plataforma Xess XSV-800

Para ello, se ha modificado el fichero de programación de la CPLD, dwnld-par.vhd, siguiendo las notas de [X E00]. Reprogramar la CPLD de la placa es una acción potencialmente peligrosa, ya que si se programaran los pines del JTAG de la CPLD como pines de salida1, no podríamos volver a programarla, siendo la

única solución en ese caso el extraer el dispositivo de la placa y sustituirlo por otro.

6.3.

Xstools

El paquete XSTOOLs [X E01a] contiene las siguientes herramientas GUI y sus alternativas de línea de comandos:

GXSTEST / XSTEST: Esta utilidad permite hacer un test a la placa para comprobar que su funcionamiento es correcto.

1Realmente, los pines 63, 71, 73 y 78 se podrían programar como salidas, pero en ese caso es indispensable que entren en un estado de alta impedancia cuando el pin DONE de la Virtex esté a nivel bajo (de forma que la CPLD se pueda reprogramar al encender la placa, cuando la FPGA aún no ha sido programada).

(43)

Placa de desarrollo XSV-800 6.3 Xstools

GXSSETCLK / XSSETCLK: Esta utilidad permite configurar la frecuencia de reloj del oscilador programable de la placa.

GXSLOAD / XSLOAD: Esta utilidad permite programar la FPGA y la CPLD y leer y escribir ficheros de datos en la RAM y la Flash de la pla-ca.

GXSPORT / XSPORT: Esta utilidad permite enviar entradas lógicas a una placa XS cambiando los pines de datos del puerto paralelo.

Las mismas herramientas sirven para toda la familia de placas XS, ya que su arquitectura es similar, basada en un dispositivo programable de configuración no volátil (la CPLD) en el cual se centralizan las acciones de programación y configuración de los distintos dispositivos on-board.

El código fuente de las herramientas XSTOOLs fue liberado al dominio pú-blico por Xess, lo que ha posibilitado que exista un port de estas herramientas para Linux, y es este port el que hemos compilado y utilizado con éxito en este proyecto.

(44)

Capítulo 7

Snapgear Linux

“All the best people in life seem to like Linux"

– Stephen Wozniak

7.1.

Necesidad de un sistema operativo

Utilizar un sistema operativo en nuestro sistema integrado, en lugar de pro-gramar directamente las rutinas específicas de nuestra aplicación en código en-samblador, ofrece una serie de ventajas, siendo la más importante la capacidad de tener múltiples tareas ejecutándose en el microprocesador, y esto es de gran im-portancia para hacer codiseño HW/SW, ya que es de esperar que se tengan varias tareas ejecutándose en software.

Para nuestro sistema, se ha decidido utilizar Snapgear Linux, una distribución de Linux específica para sistemas integrados con soporte para la familia de proce-sadores Leon.

7.2.

Descripción

Linux es un sistema operativo muy conocido, maduro y con soporte, multita-rea, con posibilidad de trabajo en tiempo real, y con muchas aplicaciones estables que se pueden utilizar sin que sea necesario modificarlas. Con respecto a otros sistemas operativos para sistemas integrados, Linux para sistemas integrados tie-ne la ventaja de presentar la misma interfaz a las aplicaciotie-nes que su versión para ordenadores personales, de forma que es posible utilizar, para el desarrollo de las aplicaciones, una plataforma muy semejante, con un entorno de ejecución y he-rramientas muy similares (las mismas), a las que luego estarán disponibles en el sistema integrado. El desarrollo y la posterior depuración de las aplicaciones son

Figure

Actualización...

Referencias

Actualización...

Related subjects :
Outline : Parte hardware