investigación sobre herramientas de codiseño...

ESCUELA SUPERIOR DEINGENIEROS

DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA

UNIVERSIDAD DE SEVILLA

Investigación sobre herramientas de CodiseñoHardware-Software

Proyecto Fin de CarreraHipólito Guzmán Miranda

Ingeniero de TelecomunicaciónTutor: Jon Tombs

Sevilla, Mayo 2006

A mis padres

Índice general

1. Introducción 61.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Flujo de diseño en codiseño 82.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. Tipos de problemas de codiseño . . . . . . . . . . . . . . . . . . 8

2.2.1. System on Board . . . . . . . . . . . . . . . . . . . . . . 82.2.2. System on Chip . . . . . . . . . . . . . . . . . . . . . . . 92.2.3. Codiseño con Softcore . . . . . . . . . . . . . . . . . . . 9

2.3. Flujo de diseño tradicional . . . . . . . . . . . . . . . . . . . . . 92.4. Flujo de diseño con herramientas de codiseño . . . . . . . . . . . 11

2.4.1. Especificación del Sistema . . . . . . . . . . . . . . . . . 122.4.2. Simulación Funcional . . . . . . . . . . . . . . . . . . . 132.4.3. Exploración del Espacio de Diseño . . . . . . . . . . . . 132.4.4. Co-Simulación TLM . . . . . . . . . . . . . . . . . . . . 132.4.5. Co-Verificación HW/SW . . . . . . . . . . . . . . . . . . 132.4.6. Co-Simulación RTL . . . . . . . . . . . . . . . . . . . . 142.4.7. Prototipado . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.8. Síntesis del Sistema . . . . . . . . . . . . . . . . . . . . 15

3. Trabajo sobre Unshades-2 163.1. Descripción de la plataforma Unshades-2 . . . . . . . . . . . . . 163.2. Herramientas Evaluadas . . . . . . . . . . . . . . . . . . . . . . 193.3. Problemas Encontrados . . . . . . . . . . . . . . . . . . . . . . . 213.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.1. Cambio de plataforma . . . . . . . . . . . . . . . . . . . 233.4.2. Línea de trabajo sobre Unshades-2 . . . . . . . . . . . . . 243.4.3. Consideraciones para una posible Unshades-2.1 . . . . . . 24

3

4. Solución propuesta 264.1. Descripción de la solución propuesta . . . . . . . . . . . . . . . . 26

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

5.1.1. Diagrama de bloques . . . . . . . . . . . . . . . . . . . . 305.1.2. Bus Amba . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2. Alternativas al procesador Leon 2 . . . . . . . . . . . . . . . . . 325.3. Configuración del modelo . . . . . . . . . . . . . . . . . . . . . . 355.4. Añadiendo la parte HW de tu diseño a Leon 2 . . . . . . . . . . . 37

6. Placa de desarrollo XSV-800 396.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2.1. Configuración de jumpers . . . . . . . . . . . . . . . . . 416.2.2. Frecuencia de reloj . . . . . . . . . . . . . . . . . . . . . 416.2.3. Reprogramación de la CPLD . . . . . . . . . . . . . . . . 41

6.3. Xstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7. Snapgear Linux 447.1. Necesidad de un sistema operativo . . . . . . . . . . . . . . . . . 447.2. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.2.1. Kernels para sistemas con y sin MMU . . . . . . . . . . . 457.3. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.4. Añadiendo la parte SW de tu diseño a snapgear . . . . . . . . . . 47

8. Entorno de codiseño PeaCE 528.1. Descripción y características . . . . . . . . . . . . . . . . . . . . 528.2. Ventajas con respecto a otras soluciones . . . . . . . . . . . . . . 548.3. Flujo de diseño en PeaCE . . . . . . . . . . . . . . . . . . . . . . 55

9. Aplicación de demostración 599.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599.2. Parte hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.3. Parte software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

10. Conclusiones 6910.1. Futuras líneas de trabajo . . . . . . . . . . . . . . . . . . . . . . 70

10.1.1. Adaptación de PeaCE a una plataforma propia . . . . . . 7110.1.2. Desarrollo de una plataforma HW opensource . . . . . . . 71

Bibliografía 73

4

Índice de figuras

2.1. Flujo de diseño tradicional . . . . . . . . . . . . . . . . . . . . . 102.2. Flujo de diseño utilizando herramientas de codiseño . . . . . . . . 12

3.1. Unshades 2. Fotografía . . . . . . . . . . . . . . . . . . . . . . . 173.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 . . . . . . . . . . . . 305.2. Mapa de memoria AHB del procesador Leon 2 . . . . . . . . . . 315.3. Herramienta de configuración del procesador Leon 2 . . . . . . . 365.4. Esquema del cable serie en Y . . . . . . . . . . . . . . . . . . . . 37

6.1. Xess XSV-800. Fotografía . . . . . . . . . . . . . . . . . . . . . 406.2. Configuración de jumpers empleada . . . . . . . . . . . . . . . . 416.3. Diagrama de bloques de la plataforma Xess XSV-800 . . . . . . . 42

7.1. Herramienta de configuración de Snapgear . . . . . . . . . . . . . 487.2. Captura de pantalla del programa minicom . . . . . . . . . . . . . 497.3. Herramienta de configuración de Snapgear, modificada . . . . . . 51

8.1. Especificación del sistema en PeaCE . . . . . . . . . . . . . . . . 558.2. Especificación de algoritmos en PeaCE . . . . . . . . . . . . . . 568.3. Especificación de arquitectura en PeaCE . . . . . . . . . . . . . . 57

9.1. Esquema de entradas y salidas del módulo HW . . . . . . . . . . 609.2. Carga de Snapgear en la RAM de la XSV-800 utilizando grmon . 679.3. Aplicación de demostración en funcionamiento . . . . . . . . . . 679.4. Prototipo en funcionamiento. Fotografía . . . . . . . . . . . . . . 68

5

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 soncada 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 procesadode grandes flujos de datos. Este incremento de complejidad y diversidad en lasrestricciones 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 dichoselementos 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 ysoftware, debido a las duras restricciones que deben cumplir estos sistemas, comoson las condiciones de tiempo real y el procesamiento rápido de grandes flujos dedatos. 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 realizarla 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 elparticionado HW/SW) se han ido tomando basándose en experiencias previas dediseño, por lo que se tiene una necesidad de poder aplicar una forma más globalde ingeniería automatizada al problema del codiseño.

Al encarar un problema de codiseño, el diseñador ha de explotar las ventajas

6

Introducción 1.2 Objetivo

de la heterogeneidad del sistema objetivo, aprovechando los puntos fuertes delsoftware (mayor flexibilidad, facilidad para ejecutar órdenes secuencialmente) ydel hardware (mayor velocidad, posibilidad de realizar procesamiento concurren-te), pero también debe procurar que los tiempos de desarrollo y depuración nosean excesivamente elevados. Esto crea la necesidad y conveniencia de trabajar enentornos integrados de desarrollo en el que se encare toda la problemática de estetipo de diseños de una forma global, y en el que se puedan automatizar la mayorparte 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 delarte de las distintas herramientas de codiseño disponibles en el mercado, así comolas distintas plataformas y procesadores (tanto ASIC como softcore) sobre losque se puedan implementar soluciones de codiseño, orientando el trabajo a poderrealizar codiseño sobre alguna de las plataformas hardware de las que disponeel departamento. Se pretende también conocer y familiarizarse con el flujo dediseño de un sistema híbrido HW/SW, al igual que entender el resto de opcionesy compromisos que puedan surgir, de forma que nos introduzcamos poco a pocoen la problemática del codiseño.

1.3. Alcance

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

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

7

Capítulo 2

Flujo de diseño en codiseño

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

– Mary Lou Cook

2.1. Generalidades

Aunque el utilizar soluciones de codiseño para resolver un problema concretoreduce 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 nivelde sistema, simulación funcional, particionado hardware-software, generación deinterfaces, estimación de costes (de área y retrasos para el hardware y de tamañode 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 seconoce 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 parteshardware 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 únicomódulo hardware o software.

8

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”. Comoveremos 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 circuitointegrado, la interfaz que los separa puede tener una capacidad mucho mayor paratransferir 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 sistemasson el A7S de Triscend, Excalibur de Altera, Virtex II Pro y Virtex 4 de Xilinx yFIPSOC [FAM+97].

2.2.3. Codiseño con Softcore

La última opción para atacar la problemática del codiseño es utilizar un únicocircuito programable sobre el que se programarán tanto el procesador que ejecuta-rá la parte software como el circuito que implementará la parte hardware. Nóteseque, 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 onChip. Pero existen grandes diferencias: por ejemplo en este caso, la interfaz noestá limitada a priori: podemos conectar los módulos del procesador al hardwarecomo queramos. Incluso podemos implementar más de un procesador en la mismaFPGA. También podemos añadir o eliminar funcionalidades del microprocesadoren 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 ejemplosde 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ñose 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 lasí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 idotomando 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.

9

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 realizarel sistema entre los módulos hardware y software). Esta partición puede realizar-se atendiendo a distintos factores, como pueden ser el tamaño (de área y códigofuente), 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

10

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 quedeben implementarse en un dispositivo concreto. Para automatizar este paso, sehan 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 delcodiseño Hardware/Software, existen hoy día múltiples entornos de desarrollo queatacan directamente a la mayor parte de los problemas asociados a la temática delcodiseñ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], orientado a siste-mas que procesan flujos de datos, como soluciones comerciales, como pueden serCoWare Codeveloper, Celoxica DK Codesign Suite, Xilinx Embedded Develop-ment Kit o Altera Nios II Integrated Development Environment. Estas solucionescomerciales han ido reemplazando a los esfuerzos investigadores anteriormentemencionados, cada uno en su nicho de aplicación (por ejemplo, dispositivos defabricantes 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 elde la figura 2.2 (página 12). Normalmente cada uno de los pasos se realiza conuna herramienta diferente, por lo que la integración de las distintas herramientasen un único flujo de diseño no es una tarea trivial.

11


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 (porejemplo 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 ensoftware. En definitiva, si el diseñador no es capaz de realizar esta descripción aalto nivel, es porque está dando por supuesto que ciertos bloques funcionales dela aplicación se implementarán de cierta forma concreta.

Algunos lenguajes que nos permiten realizar esta descripción a alto nivel delsistema 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 dealto nivel sean directamente traducibles a descripciones software o hardware, deforma que, una vez decidido el particionado HW/SW, la síntesis de cada una delas partes sea automática.

12


2.4.2. Simulación Funcional

El siguiente paso consiste en realizar una simulación funcional del sistemadescrito, 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 quepermiten realizar simulaciones funcionales de los sistemas descritos, por lo quela disponibilidad de un simulador raramente es un problema. Sólo cuando nuestradescripción a alto nivel es completamente funcional tiene sentido seguir adelantecon 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 unaherramienta de simulación TLM. El objetivo es evaluar las distintas alternativas departicionado y catalogarlas según rendimiento, para tomar una decisión respectoal 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 separadosde las descripciones de dichos bloques. Los bloques computacionales y de comu-nicación se conectan a través de tipos abstractos de datos. La comunicación semodela a través de canales, de forma que las peticiones de transacción se realizana través de funciones de interfaz correspondientes a los modelos de los canalesde comunicación. Detalles innecesarios de la comunicación y la computación seocultan 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 nivelsuperior 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 cumplecon los requisitos adicionales que le hayamos impuesto3. Esta co-verificación es

2TLM son las siglas de Transactional Level Modelling3Por ejemplo, ciertos requisitos de timing.

13


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 deldiseñ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óna nivel RTL4. Esto es un problema complejo en sí mismo ya que para realizar estacosimulación se necesita:

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

Un programa que simule adecuadamente y de forma precisa el comporta-miento del SW, es decir, un ISS5 del 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 degenerar ficheros de traza con los accesos a memoria para utilizar una técnicade sincronización virtual basada en la traza de memoria [KYH05], técnicaque 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 AldecHES (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 realizarla síntesis del hardware (herramientas de síntesis, y ‘placement and routing’ si elhardware 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

14


es cuando se fabrica un prototipo, sobre el que se demostrará de forma prácticael 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 parala aplicación que se quiere resolver, se procede a realizar la síntesis del sistemafinal.

15

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 deSevilla [ATBT03]. Unshades-2 es la segunda plataforma de la familia Unshades1,una familia de tarjetas de desarrollo, basadas en FPGAs de Xilinx, especialmentediseñadas para realizar depuración hardware en tiempo de ejecución de diseñosreales.

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 softwarecomo hardware, mientras están funcionando (es decir, el sistema está diseñadopara ser observable) y, por el otro, permitir al diseñador realizar cambios sobredichos estados (es decir, el sistema es controlable). Esta observación y controlse 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óncon la placa, y presentar la información al usuario de forma comprensible (véasela figura 3.1, en la página 17). De esta forma, el sistema se puede utilizar paradepurar los módulos HW y SW de un sistema híbrido. Otro aspecto atractivo deUnshades-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 distintassoluciones de particionado y síntesis, podríamos probarlas directamente sobre laplaca y medir sus rendimientos (tiempos de procesado, consumo de potencia).

1UNiversity of Seville HArdware DEbugging System.

16

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 plataformainteresante sobre la que investigar distintas soluciones a este problema, por la fa-cilidad para extraer información útil que brinda. El trabajar sobre esta plataformatiene 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 sintetizados. En lafigura 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 conel encapsulado PQ240, con 32400 y 331776 puertas lógicas equivalentesrespectivamente.

2System FPGA, es la FPGA en la que se programan los diseños hardware.

17

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

Figura 3.2: Diagrama de bloques del sistema Unshades-2

18

Trabajo sobre Unshades-2 3.2 Herramientas Evaluadas

C-FPGA3 de la familia Spartan II, compatible con el encapsulado QFP 144.

DSP TMS320VC33, de Texas Instruments, de 16 bits y coma flotante. Esteprocesador pertenece a la familia C3x [Tex04] y el encapsulado con el queaparece en Unshades-2 es el PGE150.

Memoria flash de 256 kwords (512 kbytes), modelo Am29LV400B B-70Rde 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 estuvieronevaluando distintas herramientas de codiseño HW/SW. Desafortunadamente, lasherramientas 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 nosencontramos 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 unprocesador de esta familia, necesitaremos añadir nosotros mismos el soporte paraeste tipo de procesador, lo que nos hace descartar inmediatamente los programasque sean de código cerrado. Pero la mayoría de proyectos de codiseño que sonde código abierto son proyectos de investigación que dejaron de actualizarse haceañ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 elpresente proyecto [BGJ+97]. Incluso se planteó en principio como opciónpara el presente proyecto el realizar una adaptación de POLIS para añadirlela 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 yreadback/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 desarrollarsealrededor de 1998.

19

Trabajo sobre Unshades-2 3.2 Herramientas Evaluadas

de POLIS (0.4), es del año 2000, y los recursos adicionales como la lista decorreo para los usuarios5 ya 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 dedescripció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 sepueden encontrar en las FPGA Virtex II Pro y con el softcore Microbla-ze de Xilinx. El principal impedimento para poder utilizar esta herramientacomercial es que, como tantas otras, carece de soporte para DSPs de TexasInstruments.

Impulse Codeveloper. Impulse CoDeveloper, al igual que Celoxica DK De-sigh Suite, es una herramienta de codiseño hardware/software que permitedescribir 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 deANSI C, ya que es posible hacer uso de todas las funcionalidades de C ala hora de programar un test bench o de describir los procesos SW que seejecutarán en un microprocesador. Sin embargo, para los procesos que setraducirá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 VirtexII 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 deXilinx para hacer la síntesis de la parte HW de los diseños, ya que estamostrabajando con FPGAs de este fabricante.

PeaCE7 codesign environment. Más adelante, en el capítulo 8, se hará unadescripción más detallada, pero por ahora comentaremos que de todas lasaplicaciones 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 quees posible modificarlo para añadir soporte para Unshades-2, es uno de los

[email protected]á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 quesi se tradujera directamente un programa C sin restricciones en su código a hardware el resultadodistaría mucho de ser eficiente.

7Ptolemy extension as Codesign Environment.

20

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 demostrado interés en darsoporte a los usuarios del software que deseen utilizarlo con nuevas plata-formas. En PeaCE, tanto los algoritmos como la arquitectura del sistemahí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, sedecidió optar en principio por añadir soporte para la plataforma Unshades-2 alentorno 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 decodiseño disponibles. La experiencia con Unshades-2 nos ha descubierto ciertasdificultades que la plataforma plantea para su uso como sistema híbrido:

Falta de soporte para el procesador C33 por parte de las herramientas decodiseñ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, llamadoc4x-gcc, pero se necesita una versión concreta de una biblioteca runtimepropietaria de Texas Intruments, de la que no disponíamos, para poderlocompilar. Sin esta biblioteca, el compilador únicamente puede generar fi-cheros objeto (.o), y no ejecutables. Al no poder utilizar el compilador deGNU, la única opción posible era utilizar un compilador propietario de Te-xas Instruments, que originaba otros problemas, entre ellos imposibilidadde 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 sehan 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 poderseinterconectar a un simulador de VHDL o Verilog que simule la parte HWdel 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 porsocket TCP/IP. Pero aparte de esto, c4x-gdb incluye un modo de funcionamiento en el que seconecta a un simulador de estas familias de DSP desarrolado por Herman Ten Brugge.

21

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 realizarlas 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 detraza).

El primer simulador que probamos fue Sim3x, un simulador desarrolladopor 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 interactuarcon otros programas, ni permite generar ficheros de traza. Por supuesto, lamodificación del programa para añadirle esa funcionalidad era imposible yaque 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 (unprograma para Windows que se ejecutaría en Linux a través de Wine), em-pleando un lenguage de scripting de Code Composer llamado GEL11. Estaalternativa era de una complejidad considerable, ya que habría que escribirun 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, yposteriormente generara un script GEL que colocara breakpoints (puntos deruptura) 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 tiemposy ciclos de acceso. Aunque teóricamente este enfoque podría funcionar, laviabilidad práctica de esta solución depende de las capacidades reales dellenguaje 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 losproblemas 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 poderutilizar 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 instanciarpequeñas memorias RAM dentro de la FPGA, de forma para que el DSPpueda 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 conPeaCE debe funcionar a su vez en Linux, aunque sea tras una capa de emulación.

11General Extension Language.

22

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 Virtex 100E son únicamente 10KBytes). Sibien 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 quehan sido implementadas en software han de compartir el microprocesador,lo que significa que necesitamos memoria para guardar la información delcontexto 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 sistema Linuxnecesita un mínimo de 1MB de RAM para ejecutarse, más RAM adicionalpara las aplicaciones), y es muy posible que eCos12, si bien es un sistemaoperativo altamente configurable, tenga una huella mínima de uso de RAMsuperior a los 48KB. Recordemos que estos 48KB han de compartirse conlos requerimientos de memoria de la parte SW del diseño.

Interfaz FPGA-DSP fija, ya que son pistas en el PCB: es posible que laS-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 sidoestudiado 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. Actualmenteno existen versiones de Linux o eCos para el procesador C33. Si bien esteóricamente posible realizar un portado de estos sistemas a nuestro DSP,ello escapa al alcance del presente proyecto. La única alternativa para poderconmutar entre las tareas en software es programar un mínimo planificadorde tareas.

Es por todas estas razones por lo que se decide abandonar el desarrollo sobreUnshades-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 solución alternativa parapoder 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 tareaque roza lo imposible. Además, los esfuerzos necesarios para hacer codiseño en

12embedded Configurable operating system.

23


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: sabiendotras la evaluación de las herramientas software (sección 3.2) que el soporte pa-ra ciertos softcores está sobradamente extendido, se plantea el realizar codiseñosobre 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 elmismo dispositivo. La plataforma propuesta es la placa de desarrollo XSV-800 deXess. 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ñocon 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 toolspara que funcionen utilizando Newlib (para esto necesitaríamos primerorealizar 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 primeroNewlib. Si no queremos portar eCos, es necesario programar un planifica-dor de tareas que se encargue de guardar los contextos de las tareas softwarey 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 realizartodo 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 compensael esfuerzo que es necesario realizar: sería más sencillo modificar Unshades-2para permitir una adaptación más sencilla y realizable. Por ello se proponen lassiguientes 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 DSPde Texas Instruments por un procesador ampliamente soportado, para el que

24


estén disponibles las herramientas anteriormente mencionadas, como podríaser un ARM13 o un ASIC Leon.

Interfaces FPGA-�P : para evitar que el interfaz fijo FPGA-�P sea una fuen-te de problemas, 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 del�P debenconectarse a la FPGA. La segunda es que todos los pines del procesadorpasen por la FPGA antes de llegar a los dispositivos de la placa, opción queañade muchísima flexibilidad a la plataforma y que curiosamente es es loque ocurre cuando se utiliza un softcore.

RAM: Es necesario añadir una cantidad suficiente de RAM on-board pa-ra poder tener un sistema operativo y trabajar de forma cómoda. Con unmí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ónpreocupante. Lo ideal, para aprovechar toda la potencia que ofrece Linux, esutilizar 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 cientosde megabytes.

13Si bien la mayoría de modelos de ARM goza de un buen soporte por parte de las herramientasde software libre típicas (gcc, eCos, newlib), recomendamos con más énfasis aquellos dos modelosde 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 dememoria.

25

Capítulo 4

Solución propuesta

“A real decision is measured by the fact that you’ve taken a new action. If there’s noaction, 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 enuna FPGA suficientemente potente como para albergar el softcore y la parte HWde 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 unadisponibilidad mayor (ya que las placas FT-Unshades de las que dispone el de-partamento están normalmente ocupadas en proyectos de investigación), porquelas herramientas para programar los dispositivos on-board están disponibles pa-ra Linux2, y porque la distribución del softcore Leon 2 soporta oficialmente laplaca XSV-800, lo que en principio facilita una de las tareas a realizar, que es laimplementació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 laFPGA. Esto permite extender el trabajo realizado a otras placas con un poco deesfuerzo 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 EspacialEuropea, y especialmente preparada para realizar pruebas de tolerancia a fallos sobre circuitospara 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.

26

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). Estaplaca posee suficiente RAM (2MBytes) y demás recursos on board y será descritaen 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 deaproximadamente 800000 puertas equivalentes (contando RAMs internas), lo cuales suficiente para implementar un softcore con varios periféricos y algún módulohardware específico.

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

Dado que necesitamos un sistema operativo sobre el que se ejecuten las tareassoftware, la parte SW del diseño correrá sobre Snapgear Linux, una distribuciónde Linux para sistemas integrados con soporte para el procesador Leon. SnapgearLinux es una variante de�Clinux 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 alas ventajas que ofrece, que se han comentado en el capítulo anterior y se veránen más profundidad en el capítulo 8. Además, otra razón para utilizar este entornoes que al no existir herramientas comerciales de codiseño HW/SW que tengansoporte para la familia de procesadores Leon, hemos de escoger una herramientade código abierto a la que se pueda añadir soporte para estos procesadores.

27

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

Figura 4.1: Diagrama de bloques de la solución propuesta

28

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 unproyecto basado en Linux es el procesador Leon 2, ya que es de código abiertoy viene acompañado de las herramientas necesarias, que también son de códigoabierto: compiladores C, versión de Newlib, y versiones de eCos y Linux. En lasecció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 porGaisler Research. Este procesador no sólo es de código abierto, sino que ademásno está ligado a ninguna tecnología de FPGA concreta, a diferencia de solucionesdependientes 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

Controlador de interrupciones

29

Procesador Leon 2 5.1 Descripción

Controlador de memoria flexible, capaz de trabajar con SDRAM en modo32 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, ya la MMU1. Ambas cachés son de tamaño configurable y pueden incluso no sersintetizadas. 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 unidadde punto flotante (Floating Point Unit o FPU) y de un co-procesador (CP), aunqueen 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 licenciade 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.

30

Procesador Leon 2 5.1 Descripción

se conectarían el co-procesador y la FPU. No obstante, una síntesis del procesadorLeon 2 sin ninguno de estos elementos es perfectamente funcional, aunque tengamenor 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 deDepuració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 desoftware, permitiendo la depuración on-line. Gracias a la DSU se pueden cargarprogramas directamente desde el PC, pausar y resetear el procesador, establecerpuntos 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 elbus AHB4 se utiliza para transferencia de datos a alta velocidad. El bus AMBAhace muy sencillo extender la funcionalidad del procesador añadiendo móduloshardware. Incluso permite reutilización de código hardware, tanto del propio quedesarrolle el diseñador como de módulos IP de otros desarrolladores [ARM99].El mercado de propiedad intelectual pone al alcance de cualquier diseñador unabiblioteca 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, sepueden encontrar fácilmente módulos hardware ya preparados para su conexión adicho bus.

Rango de direcciones Tamaño Registro Módulo0x00000000 - 0x1FFFFFFF 512 M Prom Controlador0x20000000 - 0x3FFFFFFF 512 M Memory bus I/O de memoria0x40000000 - 0x7FFFFFFF 1G SRAM y/o SDRAM0x90000000 - 0x9FFFFFFF 256 M DSU DSU

0xB0000000 - 0xB001FFFF 128 K Registros Ethernetethernet 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 mapaque se encuentra por defecto en la distribución oficial del procesador Leon 2, pero

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

31

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 procesador 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 UARTscaler register), por lo que a partir de la dirección 0x800000D05 se pueden añadirperiféricos ‘custom’ (teniendo en cuenta que a partir de la 0x90000000 vuelven aestar ocupadas, en este caso por la DSU). La tabla con los registros concretos ylas direcciones de memoria en las que están situados es demasiado extensa comopara colocarla en el presente documento pero puede ser encontrada en el manualdel 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 unaFPGA, 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 seconsideró fue una implementación de un procesador ARM que se realizócomo proyecto de fin de carrera en el departamento en 2002 [CTAT02]. Nose usó porque, si bien las instrucciones del juego ARM fueron probadas unapor una con éxito, para garantizar el cumplimiento total de las especificacio-nes ARM de este procesador habría que utilizar vectores de test propietariosque sólo están disponibles para los desarrolladores que tengan licencia deARM, por lo que se desconoce si este softcore funcionará adecuadamenteal 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í violeciertas patentes de ARM. Todas estas dificultades, que surgen a causa de laproliferación de estándares cerrados, impiden el uso de este interesante coreVHDL para nuevos proyectos. Esta situación es bastante desafortunada, yaque los procesadores ARM disponen de muchísimas herramientas como si-muladores (Armulator), bibliotecas runtime (glibc y Newlib), compiladorese 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 correspondienteal ‘PCI target mapping’.

6Véase http://www.debian.org/ports/

32


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

2. Microblaze: este procesador, en principio, y ya que nosotros trabajamos conFPGAs de Xilinx, es una alternativa igual de válida que el procesador Leon2. Pero hagamos unas consideraciones adicionales, pensando en la posibili-dad de reutilizar los esfuerzos del presente proyecto en otros proyectos deinvestigación, sabiendo que muchos de los que se realizan actualmente enel 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 hacedepuración de HW/SW sobre Microblaze si es cerrado? ¿Dónde introducesun 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 propietariosdel fabricante (Nucleus o Xilkernel, en el caso de Microblaze), aunque tam-bién existe una versión de�Clinux 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ícilmentela implementación podrá realizarse y, en caso de que se pueda, no será nadaeficiente en una FPGA de Xilinx.

4. Leon 3: este procesador, que es la evolución natural del procesador Leon2, está escrito en un VHDL más difícil de entender que Leon 2, no poseecompatibilidad binaria con éste, está peor documentado (a fecha de Octubrede 2005), y el único simulador disponible para él es el propietario TSIM.No obstante, ofrece mejores prestaciones9 por lo que en el futuro, a medidaque Leon 3 se vaya imponiendo como estándar de facto y Leon 2 vayadejando de tener soporte, será inevitable considerar Leon 3 para proyectosde 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 esmejor idea utilizar Leon 2.

33


5. Leon 2: Leon 2 es un procesador con mayor base de usuarios (a fecha deOctubre de 2005, cuando se hicieron estas consideraciones), con todas lasherramientas 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, simuladores compilados y ensambladores a partirde 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, ypor no estar ligado a ninguna tecnología de FPGA concreta. Además de loque se ha comentado anteriormente sobre Leon 3, una de las razones porlas que se ha escogido para este proyecto Leon 2 es porque existe un ‘boardsupport package’ para la placa XSV-800 para Leon 2 que no existe paraLeon 311.

6. Distintos cores del proyecto opencores [Ope]: se estuvieron evaluando al-gunos diseños del proyecto opencores, y en su momento se encontró quealgunos no están terminados, otros están hechos pero no tienen todas lasherramientas 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 lasherramientas y bibliotecas necesarias, pero ello requiere un esfuerzo consi-derable), y un problema mayor que plantean es que se desconoce si violanpatentes, copyrights u otra clase de propiedad intelectual12. De entre losprocesadores evaluados, hay uno muy interesante, OpenRisc, descrito enVerilog, cuyo desarrollo está completo y tiene su propio port del toolchainGNU 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 nuestrodiseño en VHDL (ya que PeaCE trabaja con VHDL), e integrar VHDL conVerilog, si bien es factible, es poco conveniente y en algún momento podríacausarnos 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ónArchC del procesador Leon 2

11Más adelante comprobamos que dicho ‘board support package’ no producía los resultadosque eran de esperar, resultando en una netlist incorrecta, por lo que se tuvo que realizar la síntesismanualmente 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."

34

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 dichasherramientas. En Red Hat 8.0 se puede indicar durante el proceso de instalacióndel sistema operativo que queremos instalar las herramientas Tk. La figura 5.3 esuna 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 hautilizado es la 1.0.30 xst, y las características fundamentales de la configuraciónutilizada 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 puedaresponder a las instrucciones MUL/DIV del juego de instrucciones de SparcV8, y se ha inferido un multiplicador para que estas instrucciones no tenganun tiempo de ejecución excesivo.

Tecnología objetivo Virtex.

Cachés de instrucciones y datos, cada una consta de 1 set de 4Kbytes y 32bytes 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 RTS13 y CTS14 de la UART 1 (señales PIO(13) y PIO(12) del procesador), quees la que utilizaremos para establecer una comunicación con Snapgear Linux, atravé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 quelos pines que pretende utilizar para realizar el control de flujo por hardware (RTSy CTS) no están mapeados al exterior de la FPGA. Esto es así ya que la placaXSV-800 sólo dispone de un chip MAX232, lo cual significa que sólo tenemoscuatro señales disponibles: TX, RX, CTS y RTS, de forma que la UART1 de Leon2 utiliza únicamente TX y RX, y la DSU transmite y recibe utilizando las pistasCTS 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.

35

Procesador Leon 2 5.3 Configuración del modelo

Figura 5.3: Herramienta de configuración del procesador Leon 2

36

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) - TDRTS (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, hemosmapeado esta señal rts-cts a un pin de la FPGA (concretamente, a uno de los ledsdel 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 problemacon los IOB16 de 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 susrecursos RAM que aunque implementemos el módulo ethernet no podremos tenerninguna aplicación de red significativa, ya que este tipo de aplicaciones suelendemandar 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 3opciones:

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 ventaja tieneque 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 queel 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óndel 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 elcodiseño hardware/software se plantea como el sintetizar ciertas tareas en

16In/Out Blocks.

37

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 deImpulse 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 ySW del diseño.

3. Añadir la parte HW del diseño como un periférico APB, con una tasa detransferencia 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 interfazHW/SW son operaciones de control más que de transferencia de grandesvolúmenes de datos.

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

Para añadir la parte HW de la aplicación de demostración, hay que definirdos 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’ comoun 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 ladirecció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, hayque 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ásañadir los pines de los leds al ucf.

38

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 unsistema mínimo sobre una FPGA Virtex XCV800, de aproximadamente 800000puertas equivalentes, si en la cuenta de puertas equivalentes incluimos a las RAMinternas. Tanto la FPGA como la placa de desarrollo están ya descatalogadas, ylos recursos en la placa están bastante limitados en relación a lo disponible hoy endía.

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

39

Placa de desarrollo XSV-800 6.1 Descripción

Figura 6.1: Xess XSV-800. Fotografía

40

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 EfectoJ13 y J14 Abiertos Alimentación utilizando

fuente ATXJ32 Shunt en pines 1-2 La alimentación de 2.5V para la

FPGA se genera en la placaJ22 Shunt en pines 2-3 Oscilador programado

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

(generado por el oscilador)J23 Abierto La CPLD no puede ser reprogramada

Cerrado La CPLD puede ser reprogramadaJ29, J30 y J31 Shunts en pines 2-3Permiten 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 sudisposición concreta no influye en nuestra aplicación ya que no utilizamos dichopuerto. Igualmente ocurre con los jumpers de otros dispositivos on-board, comoel 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 de100MHz, esto significa que hemos programado el divisor de frecuencias a unvalor 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 elacceso por el puerto serie al procesador que implementaremos en la Virtex. Estoes 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ésdel puerto serie.

41

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 unaacción potencialmente peligrosa, ya que si se programaran los pines del JTAG dela 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 porotro.

6.3. Xstools

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

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

1Realmente, los pines 63, 71, 73 y 78 se podrían programar como salidas, pero en ese caso esindispensable 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 FPGAaún no ha sido programada).

42

Placa de desarrollo XSV-800 6.3 Xstools

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

GXSLOAD / XSLOAD: Esta utilidad permite programar la FPGA y laCPLD 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 unaplaca XS cambiando los pines de datos del puerto paralelo.

Las mismas herramientas sirven para toda la familia de placas XS, ya que suarquitectura es similar, basada en un dispositivo programable de configuraciónno volátil (la CPLD) en el cual se centralizan las acciones de programación yconfiguració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 herramientaspara Linux, y es este port el que hemos compilado y utilizado con éxito en esteproyecto.

43

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 detener 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 variastareas ejecutándose en software.

Para nuestro sistema, se ha decidido utilizar Snapgear Linux, una distribuciónde 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 establesque se pueden utilizar sin que sea necesario modificarlas. Con respecto a otrossistemas operativos para sistemas integrados, Linux para sistemas integrados tie-ne la ventaja de presentar la misma interfaz a las aplicaciones que su versión paraordenadores personales, de forma que es posible utilizar, para el desarrollo de lasaplicaciones, 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 elsistema integrado. El desarrollo y la posterior depuración de las aplicaciones son

44

Snapgear Linux 7.2 Descripción

mucho más sencillos para el diseñador cuando el sistema operativo y el entornode ejecución son los mismos en el PC de desarrollo y en el sistema final.

Además, Linux, al ser un sistema UNIX, es un sistema tan interactivo que ofre-ce la posibilidad de realizar actualizaciones del software desde dentro del mismo,es decir, si el sistema dispone de suficiente memoria, es posible instalar el compi-lador de c (gcc) y, con este compilador recompilar las aplicaciones que necesite-mos modificar, sin necesidad de parar el sistema completo ni las aplicaciones queno se modifiquen.

En lugar de Linux, podíamos habernos decantado por eCos, un sistema ope-rativo en tiempo real desarrollado inicialmente por Cygnus Solutions y en la ac-tualidad mantenido por eCosCentric. Este sistema operativo es especialmente útilcuando se tiene una plataforma con muy poca memoria disponible (su huella sepuede reducir hasta los cientos o decenas de KBytes), pero ya que en nuestra pla-taforma tenemos memoria suficiente como para implementar un sistema Linuxmínimo, sabiendo que Linux tiene mayor base de usuarios y una ingente cantidadde colaboradores y usuarios y, considerando además la posibilidad de reutilizarlos conocimientos aprendidos de este proyecto en plataformas con mayores pres-taciones, hemos decidido finalmente utilizar Linux en lugar de eCos.

7.2.1. Kernels para sistemas con y sin MMU

Para que un sistema operativo como Linux pueda funcionar en un procesa-dor, normalmente es necesario que dicho procesador disponga de una unidad demanejo de memoria (MMU), que se encarga de dar a cada proceso un espaciode memoria protegida, y de proteger al kernel de los procesos. Además, la MMUse encarga de realizar la traducción de las direcciones de memoria virtuales a di-recciones físicas antes de cada acceso a memoria, presentando al núcleo y a losprocesos una interfaz estándar para el acceso a memoria. Afortunadamente existenversiones del núcleo de Linux que han sido adaptadas para su uso en procesadoresque carecen de MMU [DL02]. Snapgear Linux ofrece la posibilidad de ejecutarkernels tanto para sistemas con unidades de manejo de memoria tanto para siste-mas que carecen de ella.

El procesador leon 2 incluye una unidad de manejo de memoria que se puedeimplementar, como se ha comentado en el capítulo 5, si le da la opción correspon-diente en el menú de configuración del procesador, con el consecuente incrementodel tamaño del diseño. Dado que la plataforma utilizada tiene ciertas limitaciones,ha sido necesario sintetizar el procesador sin unidad de manejo de memoria, porlo que finalmente se ha configurado el sistema Linux con un kernel con soportepara sistemas non-MMU. Concretamente, en la implementación aquí descrita seha utilizado un kernel 2.0.39 con este soporte.

La herramienta de configuración (ver figura 7.1) ofrece la posibilidad de ajus-

45

Snapgear Linux 7.3 Configuración

tar las opciones concretas del núcleo Linux que se implementarán, así como lasaplicaciones concretas que se compilarán en el sistema, de forma que se puedeganar espacio eliminando las funcionalidades que no se necesiten. Snapgear Li-nux permite añadir de forma sencilla aplicaciones específicas, que se compilaránjunto al resto del sistema. Ya que el entorno utilizado comprende lenguaje C, lasherramientas de desarrollo UNIX normales (gcc, make) y el API de un sistemaPOSIX, existen muchas facilidades para la reutilización del código. Esto, unido a,como se ha comentado anteriormente, que el entorno de ejecución final es el mis-mo que el de desarrollo de la aplicación, permite construir versiones integradas deaplicaciones previamente desarrolladas sobre ordenadores personales.

7.3. Configuración

La versión concreta de snapgear que hemos utilizado es la versión p-17. Aligual que el procesador Leon 2, Snapgear Linux se configura utilizando una he-rramienta basada en Tk. Se ha tenido especial cuidado en la configuración deSnapgear Linux ya que nuestra placa está bastante limitada en lo que a recursosrespecta. Ya que únicamente disponemos de 2MB de RAM, espacio que ha decompartirse con la imagen RAM, y�Clinux necesita alrededor de 1MB de RAMpara poder ejecutar un sistema mínimo1, hemos reducido la imagen RAM todo loposible eliminando funcionalidades no necesarias. La ocupación en RAM de laimagen de Linux obtenida finalmente ha sido de alrededor de 600KB, por lo quequeda más de 1MB de memoria para uso de las aplicaciones.

Las características fundamentales de la configuración utilizada son:

Parámetros del procesador: Fabricante Gaisler y Modelo Leon 2

Versión del núcleo: linux-2.0.39 nommu

Biblioteca estándar C: uClibc

Tipo de ram: SRAM. 2 bancos de 8 MBytes cada uno. Estados de espera enlectura (rws), escritura (wws) y modificación (rms): 1.

Configuración del núcleo:

� Sin soporte para aplicaciones de red

1En el caso de tener menos memoria, tendremos errores de tipo ‘failed to free page’, debidoa que Linux no puede reservar la memoria necesaria para los procesos que se quieren ejecutar. Enestos casos no es raro observar que la memoria que requiere un proceso es menor que la memorialibre total, pero aún así no se puede ejecutar el proceso. Esto se debe a que toda la memoria que seasigne inicialmente a un proceso debe ser contigua.

46

Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear

� Huella reducida

� Soporte para el sistema de archivos /proc2

� Soporte para comunicaciones serie

� Versiones de kmalloc.c/page_alloc.c que hacen un mejor aprovecha-miento de la memoria.

Configuración de las aplicaciones: se han eliminado todas las aplicacionesde red, lo cual ha ayudado mucho a reducir el tamaño de la imagen RAM.Además, utilizamos un programa muy compacto llamado BusyBox que ha-ce las veces de init y se puede configurar para que proporcione las funcio-nalidades de múltiples comandos de shell, como ls o ps. El shell que hemosutilizado es sash (stand-alone shell), un shell frecuentemente usado en sis-temas integrados y en operaciones de recuperación de sistemas ya que estáenlazado estáticamente, por lo que no necesita de librerías dinámicas parasu funcionamiento.

Para la conexión con Snapgear Linux, configuramos al programa minicom conlos siguientes parámetros:

1. Parámetros de comunicación:

a) Velocidad: 38500 baudios

b) Datos: Palabras de 8 bits

c) Paridad: Ninguna

d) Bits de parada: 1

2. Carácter que envía la tecla Backspace: DEL

3. Line wrapping (evita que aparezcan en pantalla líneas que se salgan delmargen de la consola): ON

La figura 7.2 es una captura de pantalla del programa minicom, a través delcual establecemos una comunicación serie con el sistema integrado. En la figurase puede apreciar el shell del sistema tras un arranque satisfactorio.

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

Añadir la parte software de un diseño híbrido es bastante sencillo, y básica-mente consiste en añadir un programa a la distribución Snapgear. Dicho programa

2/proc es un sistema de archivos virtual que proporciona información útil del sistema.

47


Figura 7.1: Herramienta de configuración de Snapgear

48


Figura 7.2: Captura de pantalla del programa minicom

49


interactuará con el HW leyendo y escribiendo en los registros del bus AMBA quepertenezcan a la parte hardware.

Los pasos que se han seguido para añadir la parte SW de la aplicación dedemostración descrita en el capítulo 9 han sido los siguientes:

Crear la carpeta <snapgear>/user/swpart, siendo <snapgear> el directorioraíz de las fuentes de la distribución.

Escribir el código fuente del programa, dentro de user/swpart. En nuestrocaso, ya que se trata de una aplicación sencilla, el código fuente consisteúnicamente de un fichero: swpart.c

Escribir un Makefile, dentro de user/swpart, para automatizar la compila-ción del SW y para integrarlo en snapgear, de forma que se compile auto-máticamente junto con el resto de la distribución. El makefile tendrá tresreglas que son invocadas automáticamente por los Makefiles generales deSnapgear: ‘all’, que compila el programa y crea los binarios y ejecutables,‘romfs’, que copia los binarios al directorio romfs (a partir del cual se crearála imagen RAM), y ‘clean’, que elimina los archivos temporales y productosde la compilación.

#Makefile para la parte SW de la aplicación de demostración

EXEC1 = swpartOBJS1 = swpart.o

%o : %cxx$(CXX) -v -I /opt/sparc-linux/include/c++/3.2.2

-I /opt/sparc-linux/include/c++/3.2.2/backward-I /opt/sparc-linux/include/c++/3.2.2/sparc-linux$(CFLAGS) -c -o $@ $<

#Los makefiles de snapgear llamaran a este haciendo ’make all’all: $(EXEC1)

$(EXEC1): $(OBJS1)echo "LDFLAGS: $(LDFLAGS)"$(CC) $(LDFLAGS) -o $@ $(OBJS1)

$(LDLIBS$(LDLIBS_$@))-lm -lgcc -lm -lgcc

romfs:$(ROMFSINST) /bin/$(EXEC1)

clean:-rm -f $(EXEC1) *.elf *.gdb *.o

50


Para que en el menú de configuración de Snapgear aparezca nuestra apli-cación, añadir una entrada al fichero <snapgear>/config/config.in, concreta-mente en nuestro caso:

bool ’SW part of codesign application’ CONFIG_USER_SWPART

Para que la configuración anterior se traduzca efectivamente en una compi-lación de nuestra aplicación, hay que añadir una entrada al fichero <snap-gear>/user/Makefile:

dir_$(CONFIG_USER_SWPART) += swpart

El último paso, opcional, consiste en escribir unas líneas de informaciónpara el fichero de ayuda <snapgear>/config/Configure.help:

Prompt to include or not the SW part of the designCONFIG_USER_SWPART

Compile and include the SW part of the sample hybrid design.The executable name will be ’swpart’.

Tras esto sólo queda arrancar la herramienta de configuración (haciendo ‘makexconfig’ en el directorio raíz de snapgear) y seleccionar ‘swpart’ como aplicacióna añadir.

Figura 7.3: Herramienta de configuración de Snapgear, modificada

51

Capítulo 8

Entorno de codiseño PeaCE

“I think the best way to overcome this hurdle is that you visit our lab. during the summerseason for one month with your board for PeaCE customization. We are also very

interested in supporting you and your system."– Soonhoi Ha, director del proyecto PeaCE

8.1. Descripción y características

El proyecto PeaCE (Ptolemy extension as Codesign Environment) nace a par-tir de los esfuerzos de investigación de Ptolemy, un proyecto desarrollado en elCenter for Hybrid and Embedded Software Systems (CHESS) del Department ofElectrical Engineering and Computer Sciences de la Universidad de California,en Berkeley [BHLM92, Pto]. El proyecto estudiaba el modelado, la simulación yel diseño de sistemas integrados concurrentes en tiempo real, y su enfoque prin-cipal es la yuxtaposición de componentes concurrentes. El principio clave y granacierto de Ptolemy es el uso de modelos formales1 de computación, que gobier-nan la interacción entre componentes, de forma que se pueden utilizar mezclasheterogéneas de modelos de computación.

PeaCE, un proyecto del Codesign And Parallel Processing Laboratory (CAPLab.), de la Universidad Nacional de Seoul, hereda estas características con laintención de abarcar una metodología completa para co-especificar, co-simular yco-sintetizar módulos de diferentes características en el mismo entorno de trabajo[CAP04, CAP05]. El objetivo del proyecto PeaCE es cubrir las múltiples facetasde las tareas de codiseño: codiseño de módulos hardware y software, y codiseñode módulos de control y función.

1La idea esencial de la ‘formalidad’ de estos modelos es que están perfectamente definidos, deforma que no puedan existir ambiguedades sobre el comportamiento de un sistema especificadoen base a estos modelos, por muy complejo o heterogéneo que sea.

52

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

Las características clave de PeaCE son las siguientes:

Framework opensource, que incentiva la colaboración entre desarrolladores.

Entorno altamente reconfigurable, de forma que se pueden integrar en élherramientas de otros desarrolladores en el entorno. Para este propósito, losdistintos pasos del flujo de diseño están todo lo desacoplados que se puededesde un punto de vista práctico, y se utiliza un interfaz basado en ficheros(concretamente en ficheros XML) entre los pasos del flujo de diseño. Lautilidad de estos interfaces se ha demostrado ya, al haberse conseguido laintegración de la herramienta de cosimulación Seamless CVE en el flujo dediseño de PeaCE.

GUI Java (Hae) independiente del núcleo. De esta forma se tiene un interfazde usuario gráfico y sencillo, que además es independiente de la plataforma.

Núcleo C++ orientado a objetos heredado de Ptolemy. El núcleo, desaco-plado del interfaz de usuario, está diseñado para tener altas prestaciones.Esta arquitectura cliente-servidor permite tener un servidor dedicado al quese conecten clientes desde distintos sistemas operativos.

Diseño de sistema multilingüe. La decisión de qué lenguaje utilizar para rea-lizar la descripción del sistema en un entorno de codiseño siempre ha sidomotivo de discusión. Por ello PeaCE permite el uso de múltiples lenguajes,definiendo cuidadosamente cómo se integran en el diseño de un único siste-ma. PeaCE utiliza distintos modelos de computación para representacionesfuncionales y de control, y estos modelos residen en otro modelo de com-putación que se encarga de la integración de los distintos bloques a nivel desistema2.

Síntesis automática de hardware y software: a partir de las especificacionesiniciales, se genera el código C y/o VHDL necesario.

Particionado HW/SW automático: la exploración del espacio de diseño seefectúa en un bucle jerárquico para reducir el tiempo de exploración sinsacrificar la calidad de la solución encontrada. Nótese que muy pocas he-rramientas de codiseño ofrecen la posibilidad de realizar el particionadoHW/SW de forma automatizada.

2Concretamente: SPDF (Synchronous Piggybacked DataFlow Model) para modelado y espe-cificación de elementos Dataflow (función), DE (Discrete Event) Model para modelado y espe-cificación de Eventos Discretos, fFSM (flexible Finite State Machine) Model para modelado yespecificación de máquinas de estados finitas (control), y por último BP (BackPlane) para modela-do de tareas, es decir, para modelar a un nivel superior (nivel de sistema) las interconexiones entrelos bloques, que internamente pueden ser fFSM o SPDF.

53

Entorno de codiseño PeaCE 8.2 Ventajas con respecto a otras soluciones

8.2. Ventajas con respecto a otras soluciones

Todas las características de este entorno de codiseño se traducen en una seriede ventajas que ofrece PeaCE a un grupo de investigación como los del Departa-mento de Ingeniería Electrónica y que se pueden resumir de la siguiente manera:

Entorno de código abierto, lo que permite extenderlo, añadiéndole soportepara nuevas plataformas y procesadores. Además, el hecho de que el códigosea abierto permite entender mejor los pasos del flujo de diseño e inclusopermite ampliar las líneas de investigación del departamento, por ejemplo,es posible implementar un nuevo algoritmo de particionado HW/SW, inte-grarlo en PeaCE, y realizar una comparativa con el que ya ofrece el entorno.

Es un proyecto de codiseño que está vivo y sus desarrolladores están siem-pre dispuestos dar soporte. De hecho, es el único entorno de codiseño decódigo abierto que es un proyecto vivo a fecha de 2006.

Como añadido, si se cambia de fabricante de hardware no se tiene por quécambiar de entorno de codiseño, lo que permite reutilizar las descripcionesa alto nivel que ya se tengan, ya que seguirían siendo válidas.

La peculiar arquitectura cliente-servidor nos permite tener un único servidorLinux y clientes accediendo desde cualquier sistema operativo.

54

Entorno de codiseño PeaCE 8.3 Flujo de diseño en PeaCE

8.3. Flujo de diseño en PeaCE

El flujo de diseño en PeaCE consta de 8 pasos [CAP05]. En la figura 8.1 sepuede apreciar que a través de las pestañas de la ventana de proyecto se puedeaccerder a los distintos pasos del flujo de diseño.

Figura 8.1: Especificación del sistema en PeaCE

1. Especificación de algoritmos y simulación funcional. Esta especificación serealiza utilizando el interfaz gráfico proporcionado por Hae, el cliente Java.La especificación es jerárquica y haciendo doble click sobre un bloque seabre una ventana con la descripción interna del bloque, hasta que se llegaal nivel mínimo de detalle. En este nivel mínimo lo que se ve es una des-cripción, en modo texto, del funcionamiento de este bloque en PeaCE (verfigura 8.2).

55


Figura 8.2: Especificación de algoritmos en PeaCE

2. Descripción de la arquitectura. En este paso se describe la arquitectura delsistema de una forma abstracta (CPUs, ASICs, buses). Esta descripción dearquitectura proporciona al algoritmo de particionado HW/SW informaciónsobre los elementos de procesado disponibles (figura 8.3).

56


Figura 8.3: Especificación de arquitectura en PeaCE

3. Estimación de rendimiento. La estimación de rendimiento de los bloquesHW debe ser realizada a priori por el diseñador del bloque, y la estimacióndel rendimiento del SW se realiza utilizando un ISS3. Esta estimación esnecesaria para poder realizar el particionado automático HW/SW.

4. Generación de ficheros XML de interfaz, que sirven para poder integrarotras herramientas en el flujo de codiseño de PeaCE. En este paso se ge-neran 3 ficheros: <proj-name>.xml con la topología del sistema, <proj-name>_TimeCost.xml, con los resultados de la estimación de rendimiento,y <proj-name>_mode.xml, con las restricciones de timing de cada tarea.

5. Particionado HW/SW. PeaCE permite realizar un particionado HW/SW au-tomático, utilizando los resultados de los pasos anteriores, o bien realizarun particionado manual. En el caso de no disponer de una estimación derendimiento, la única opción es el particionado manual.

6. Exploración del espacio de diseño (DSE o Design Space Exploration). Trasel particionado, el siguiente paso consiste en explorar la arquitectura de co-municaciones, basándonos en la traza de memoria de cada elemento del

3Aunque también se podría realizar sobre una placa prototipo de la que podamos extraer in-formación.

57


sistema y en el orden en el que deben ejecutarse las tareas. Este paso tam-bién necesita de un simulador para cada recurso computacional del sistema(CPUs y hardware programable).

7. Cosimulación HW/SW para co-verificación. En el penúltimo paso se realizauna simulación del sistema completo, para verificar que su funcionamientoes correcto. PeaCE da la posibilidad de realizar la cosimulación utilizandoun ISS y un simulador de VHDL, gracias a la sincronización virtual basadaen la traza de memoria, aunque también permite utilizar Seamless CVE pararealizar la cosimulación. Dado que Seamless CVE no tiene soporte para lafamilia de procesadores Leon, nuestra única opción sería utilizar un ISS.

8. Cosíntesis: En este paso, PeaCE genera automáticamente código VHDL yC para el hardware y software respectivamente, además de los drivers paraLinux necesarios para que las tareas que se implementan en software puedancomunicarse con el hardware.

Aunque es factible, desafortunadamente no sea ha realizado aún la adaptaciónde PeaCE para la plataforma XSV-800 y el procesador Leon 2, ya que la tareaescapa del alcance del proyecto. No obstante, se propone como posibilidad deampliación.

58

Capítulo 9

Aplicación de demostración

“Now we’ll play salsa. The way we know it."– Tito Puente

9.1. Visión general

Se ha realizado una mínima aplicación de codiseño, de forma manual, comoconclusión del presente proyecto y demostración de las capacidades de la solu-ción propuesta. El objetivo de esta aplicación es demostrar el co-funcionamientoHW/SW, la interfaz HW/SW (basada en bus AMBA, concretamente en el busAPB), y los interfaces con el exterior: tanto a través de pines específicos de laFPGA (en este caso, los pines que encienden los displays LED de siete segmentosde la placa XSV-800) como a través de línea de comandos (interfaz con un opera-dor), todo ello utilizando un sistema mínimo con recursos limitados. Un beneficioañadido de esta aplicación realizada de forma manual es que sirve de punto departida para añadir soporte para Leon 2 a PeaCE1.

La aplicación hibrída, como no puede ser de otra forma, consta de una partehardware, que se añade y sintetiza junto al resto del modelo del procesador Leon2, y de una parte software que se añade y compila junto a Snapgear Linux. Lageneración del interfaz HW/SW, una tarea muy significativa y vital para toda apli-cación de codiseño, ha sido facilitada enormemente gracias a la implementacióndel bus AMBA de la que dispone Leon 2.

Básicamente nuestra aplicación es un contador de segundos, implementado enhardware, con sentidos de cuenta tanto creciente como decreciente, y con máximo

1Normalmente, para añadir soporte para nuevos procesadores y plataformas a PeaCE, primerose porta o diseña una aplicación híbrida manualmente y luego, una vez que se ha demostrado elfuncionamiento de la aplicación en la plataforma objetivo, se automatiza el proceso de co-síntesisde PeaCE para dicha plataforma.

59

Aplicación de demostración 9.2 Parte hardware

y mínimo configurables que se programan desde la parte software del diseño.El funcionamiento de la aplicación realizada se puede observar en las imáge-

nes 9.2, 9.3 y 9.4.

9.2. Parte hardware

La parte hardware del diseño se ha definido en un fichero vhdl, hwpart.vhd.Este módulo HW recibe, además de las señales globales de reset y clk, la señal deentrada del bus APB (apbi) y sus salidas son la señal de salida del bus APB (apbo)y las señales que encenderán los leds del display de siete segmentos. Las señalesapbi y apbo son las entradas y salidas APB, y son de tipo APB_Slv_In_Type yAPB_Slv_Out_Type, que son ‘records’, o conjunto de señales2: cada uno contie-ne todas las señales que se utilizan para la entrada (o salida) de señales APB almódulo.

Figura 9.1: Esquema de entradas y salidas del módulo HW

Los records APB_Slv_In_Type y APB_Slv_Out_Type se definen en el fichero

2Unir las señales por grupos funcionales es una muy buena idea y simplifica enormemente elconexionado de los elementos de la jerarquía de un diseño.

60


amba.vhd del modelo de Leon 2:

------------------------------------------------------------------------------- Constant definitions for AMBA(TM) APB-----------------------------------------------------------------------------constant PDMAX: Positive range 8 to 32 := 32; -- data widthconstant PAMAX: Positive range 8 to 32 := 32; -- address width

------------------------------------------------------------------------------- Definitions for AMBA(TM) APB Slaves------------------------------------------------------------------------------- APB slave inputs (PCLK and PRESETn routed separately)type APB_Slv_In_Type is

recordPSEL: Std_ULogic; -- slave selectPENABLE: Std_ULogic; -- strobePADDR: Std_Logic_Vector(PAMAX-1 downto 0); -- address bus (byte)PWRITE: Std_ULogic; -- writePWDATA: Std_Logic_Vector(PDMAX-1 downto 0); -- write data bus

end record;

-- APB slave outputstype APB_Slv_Out_Type is

recordPRDATA: Std_Logic_Vector(PDMAX-1 downto 0); -- read data bus

end record;

El comportamiento del módulo ‘hwpart’ está definido básicamente por cuatroprocesos concurrentes:

1. El proceso calc_p_value implementa el comportamiento del contador: cadasegundo, si el valor del contador llega al máximo, se cambia el comporta-miento a decrecer (going_up = ’0’) y reduce su valor, y si llega al mínimo,cambia el comportamiento (going_up = ’1’ ). Además, si los valores míni-mo y máximo son el mismo, el contador toma ese valor, lo que nos permiteprecargar el contador a un valor concreto.

2. Los procesos calc_left_led y calc_right_led calculan las señales que irán alos displays de 7 segmentos a partir del valor del contador. Para aprovechartodo el rango entre 0 y 255, cada uno de los dígitos led representará undígito en hexadecimal (es decir, tomará valores entre 0 y F).

3. Por último, el proceso sinc se encarga de capturar los valores de las señalessíncronas.

El módulo hwpart interpreta la información que recibe por el bus APB de lasiguiente forma: los 8 bits menos significativos del dato recibido serán el valormínimo del contador, y los siguientes 8 bits serán el valor máximo. El resto debits recibidos se descarta.

Por lo que a la salida respecta, el módulo hardware siempre está comunicandoel valor del contador por el bus APB, pero sólo se podrá leer dicho valor cuandola dirección en el bus AMBA sea la del módulo hardware.

61


--------------------------------------------------------------------------------- This file is a heavily modified version of ioport.vhd-- as a derived work of the file and also of the Leon 2 processor,-- the license which applies is-- the GNU Lesser General Public License.-- See below for details.----------------------------------------------------------------------------------- The original file is a part of the LEON VHDL model-- and has Copyright (C) 1999 European Space Agency (ESA)---- This library is free software; you can redistribute it and/or-- modify it under the terms of the GNU Lesser General Public-- License as published by the Free Software Foundation; either-- version 2 of the License, or (at your option) any later version.---- See the file COPYING.LGPL for the full details of the license.------------------------------------------------------------------------------------- Entity: hwpart-- File: hwpart.vhd-- Author: Hipólito Guzmán Miranda (based on J. Gaisler’s ioport.vhd)-- Description: HW part of a sample codesign application.-------------------------------------------------------------------------------

library IEEE;use IEEE.std_logic_1164.all;--use IEEE.std_logic_signed."-";use IEEE.std_logic_arith.all;use IEEE.std_logic_unsigned.all;use work.config.all;use work.iface.all;use work.macro.genmux;use work.amba.all;

entity hwpart isport (

rst : in std_logic;clk : in clk_type;apbi : in apb_slv_in_type;apbo : out apb_slv_out_type;left_led : out std_logic_vector (6 downto 0);right_led : out std_logic_vector (6 downto 0)

);end;

architecture rtl of hwpart is

constant CYCLESPERSECOND : integer := 20000000;signal value, p_value : integer range 0 to 255; -- 8 bitssignal value_max, value_min : integer range 0 to 255; -- 8 bitssignal value_bits : std_logic_vector (7 downto 0);signal left_digit, right_digit : std_logic_vector (3 downto 0); --digitssignal cyclecount, p_cyclecount : integer range 0 to 33554432; -- 25 bits

-- this is not optimal and could be split into a cycle counter-- and a msec counter

62


signal filler : std_logic_vector(PDMAX-1 downto 8);signal received_APB_data, p_received_APB_data :

std_logic_vector(PDMAX-1 downto 0);signal going_up, p_going_up : std_logic; -- direction of the count

beginfiller <= (others => ’0’);p_cyclecount <= 0 when cyclecount = CYCLESPERSECOND else cyclecount + 1;

value_bits <= conv_std_logic_vector(value,8);left_digit(3 downto 0) <= value_bits(7 downto 4);right_digit(3 downto 0) <= value_bits(3 downto 0);

-- The APB input:p_received_APB_data <= apbi.pwdata when

(apbi.psel and apbi.penable and apbi.pwrite) = ’1’ else received_APB_data;value_max <= conv_integer(received_APB_data (15 downto 8));value_min <= conv_integer(received_APB_data (7 downto 0));

sinc: process (rst, clk)begin

if (rst=’0’) thenvalue <= 0;cyclecount <= 0;received_APB_data <= (others => ’0’);going_up <= ’1’;

elsif (clk=’1’ AND clk’event) thenvalue <= p_value;cyclecount <= p_cyclecount;received_APB_data <= p_received_APB_data;going_up <= p_going_up;

end if;end process sinc;

calc_p_value: process (cyclecount, value, value_max, value_min)beginif (cyclecount = CYCLESPERSECOND) thenif (value_max = value_min) thenp_value <= value_max; -- this allows us to preload the counterp_going_up <= going_up;elsif (value = value_max) thenp_going_up <= ’0’;

p_value <= value - 1;elsif (value = value_min) then

p_going_up <= ’1’;p_value <= value + 1;

elseif (going_up = ’1’) thenp_value <= value + 1;elsep_value <= value - 1;end if;p_going_up <= going_up;

end if;elsep_value <= value;end if;end process calc_p_value;

-- Here we convert HEX to BCDcalc_left_led: process (left_digit)

63


begincase left_digit is

when "0000" =>left_led <= "1110111"; -- 0

when "0001" =>left_led <= "0010010"; -- 1

when "0010" =>left_led <= "1011101"; -- 2

when "0011" =>left_led <= "1011011"; -- 3

when "0100" =>left_led <= "0111010"; -- 4

when "0101" =>left_led <= "1101011"; -- 5

when "0110" =>left_led <= "1101111"; -- 6

when "0111" =>left_led <= "1010010"; -- 7

when "1000" =>left_led <= "1111111"; -- 8

when "1001" =>left_led <= "1111010"; -- 9

when "1010" =>left_led <= "1111110"; -- A

when "1011" =>left_led <= "0101111"; -- b

when "1100" =>left_led <= "1100101"; -- C

when "1101" =>left_led <= "0011111"; -- d

when "1110" =>left_led <= "1101101"; -- E

when "1111" =>left_led <= "1101100"; -- F

when others =>left_led <= "0000000"; -- default

end case;end process calc_left_led;

calc_right_led: process (right_digit)begincase right_digit is

when "0000" =>right_led <= "1110111"; -- 0

when "0001" =>right_led <= "0010010"; -- 1

when "0010" =>right_led <= "1011101"; -- 2

when "0011" =>right_led <= "1011011"; -- 3

when "0100" =>right_led <= "0111010"; -- 4

when "0101" =>right_led <= "1101011"; -- 5

when "0110" =>right_led <= "1101111"; -- 6

when "0111" =>right_led <= "1010010"; -- 7

when "1000" =>right_led <= "1111111"; -- 8

when "1001" =>

64

Aplicación de demostración 9.3 Parte software

right_led <= "1111010"; -- 9when "1010" =>

right_led <= "1111110"; -- Awhen "1011" =>

right_led <= "0101111"; -- bwhen "1100" =>

right_led <= "1100101"; -- Cwhen "1101" =>

right_led <= "0011111"; -- dwhen "1110" =>

right_led <= "1101101"; -- Ewhen "1111" =>

right_led <= "1101100"; -- Fwhen others =>

right_led <= "0000000"; -- defaultend case;end process calc_right_led;

-- The APB output:

apbo.prdata(PDMAX-1 downto 8) <= filler;apbo.prdata(7 downto 0) <= value_bits;

end;

9.3. Parte software

La parte software del diseño es también muy sencilla, y sirve para demostrar,además de la sinergia entre el hardware y el software, la interfaz con el usuarioa través de la línea de comandos. El usuario invoca al programa con el comandoswpart <value1> <value2>, donde<value1> y <value2> son dos números en-tre 0 y 255. El programa se encarga de determinar cuál de los dos números es elmayor, tras lo cual genera el valor que ha de enviar por el bus APB a la direccióndel módulo hwpart (0x800000E0), y escribe el valor adecuado en dicha dirección.Tras esta operación, el programa espera 3 segundos, para permitir al usuario com-probar el valor que se ha enviado a la parte hardware, y entra en un bucle infinitoen el que realiza una lectura del valor del contador cada segundo y saca su valor(en decimal y en hexadecimal) por pantalla.

La lectura y escritura en la dirección de memoria en la que está ubicada la partehardware se puede realizar directamente definiendo un puntero con el valor dedicha dirección, ya que el sistema carece de unidad de manejo de memoria, por loque no existen las direcciones virtuales, de forma que las direcciones que aparecenen el código C son direcciones físicas reales. En el caso de que el procesador Leon2 hubiera sido implementado con una MMU, habría que utilizar la llamada alsistemammap, que nos devolvería un puntero a una dirección de memoria virtualque, a ser traducida a dirección física por la MMU, daría la dirección del módulohardware. Es este puntero el que se utilizaría para acceder al módulo hardware en

65


lectura y escritura.Es muy importante el uso adecuado del modificadorvolatile, que avisa al com-

pilador de que el objeto concreto (variable o contenido del puntero) está sujeto acambios por razones que no pueden ser predeterminadas por un estudio del pro-grama en sí mismo, y fuerza a que todas las referencias al objeto sean referenciasgenuinas. Esto básicamente significa que el compilador C no realizará optimiza-ciones sobre el código que puedan afectar a la interacción con los periféricos HW,cuyos registros le indicamos al compilador que sonvolatile: por ejemplo, ciertoregistro de un periférico puede necesitar ser leído o escriton veces seguidas paraser inicializado, y una optimización del compilador puede convertir esosn accesosen uno sólo.

/* SW part of custom codesign applicatio *//* Hipólito Guzmán Miranda *//* Licensed under GNU LGPL */

#include <math.h>#include <stdlib.h>#define HW_REGISTER_ADDR 0x800000E0

int main(int argc,char **argv) {volatile unsigned int* addr_timer0 = (volatile unsigned int*) HW_REGISTER_ADDR;int max_value, min_value;int value_to_APB_register = 0;if (argc != 3){printf("\nUsage: %s <value1> <value2>\n", argv[0]);

printf("Values must be between 0 and 255\n");}else{

if ( atoi(argv[1]) > atoi(argv[2])){max_value = atoi(argv[1]);min_value = atoi(argv[2]);}else{max_value = atoi(argv[2]);

min_value = atoi(argv[1]);}value_to_APB_register += min_value;value_to_APB_register += (max_value << 8);printf("initializing HW register with the value %i\n", value_to_APB_register);*addr_timer0 = value_to_APB_register;usleep(3000000);while (1){usleep(1000000);printf("reading the value of the HW register\n");printf("The HW register value is %i DEC, %X HEX\n",*addr_timer0, *addr_timer0);};}return 0;}

66


Figura 9.2: Carga de Snapgear en la RAM de la XSV-800 utilizando grmon

Figura 9.3: Aplicación de demostración en funcionamiento

67


Figura 9.4: Prototipo en funcionamiento. Fotografía

68

Capítulo 10

Conclusiones

“Until next time, live consciously"– Steve Pavlina

Se ha realizado una investigación exhaustiva sobre el estado del arte de lasherramientas de codiseño HW/SW disponibles tanto de forma comercial (softwa-re propietario) como de forma gratuita (trabajos de investigación publicados bajolicencias opensource). Se ha estudiado el problema del codiseño HW/SW tantode un punto de vista teórico como práctico, siempre teniendo en mente la aplica-ción práctica de los conocimientos adquiridos y las herramientas evaluadas parapoder empezar a realizar diseños prácticos de sistemas híbridos sobre plataformasreales. Se han considerado tres plataformas distintas (Unshades-2, FT-Unshades yXSV-800), todas disponibles para el Departamento de Ingeniería Electrónica, co-mo plataformas sobre las que trabajar e investigar la metodología del co-diseño.

Se ha propuesto una solución basada en herramientas de código abierto comoson Leon 2 y Linux, lo que permite interacción entre desarrolladores, mejor enten-dimiento de los mecanismos internos de las herramientas e IP hardware usados ymayores posibilidades de investigación a largo plazo. La solución propuesta pue-de implementarse sin más coste que el coste de la plataforma HW, ya que Linux,Leon 2 y PeaCE son de código abierto y gratuitos, y hoy en día las FPGAs sopor-tadas por la versión gratuita de Xilinx Webpack (o, si se quiere utilizar hardwarede otro fabricante, Altera Quartus II Web Edition) son suficientemente potentescomo para soportar el procesador Leon 2 y módulos hardware adicionales. Porotro lado, el coste de la plataforma HW es inevitable, aunque el coste de una pla-taforma hardware con recursos parecidos a los de la XSV-800 no debe ser muyelevado hoy día.

Se ha realizado una aplicación HW/SW para demostrar la viabilidad de lasolución propuesta. Esta aplicación demuestra la adición de módulos SW a Leon2, la adición de programas a Snapgear Linux, la interfaz entre HW y SW a través

69

Conclusiones 10.1 Futuras líneas de trabajo

del bus AMBA, y los interfaces con el exterior utilizando tanto pines de la FPGA(para los leds) como utilizando la línea de comandos. La aplicación híbrida seha implementado sobre una placa de desarrollo que lleva, en el momento de laimplementación, cinco años en el mercado1. Además, la aplicación de prueba quese ha desarrollado se puede utilizar como plantilla y servir para otros proyectosque se quieran resolver utilizando un sistema híbrido2.

Se han establecido relaciones con grupos de investigación de otros países: seha contactado con el equipo de desarrolladores de PeaCE y con los desarrolladoresde ArchC, y se han llegado a intercambiar varios correos con éstos, y multitud decorreos con aquellos. Huelga decir que ambos equipos están muy interesados enver surgir aplicaciones prácticas de sus esfuerzos, por lo que se puede contar consu soporte si se van a utilizar sus herramientas, y este proyecto es testigo de ello.

Se ha comprobado que el hacer codiseño es una meta alcanzable, siempre quese evalúe correctamente el esfuerzo necesario para tu plataforma concreta: si no,podrías comprometerte a una fecha límite con un cliente para luego darte cuenta deque tu proyecto es prácticamente imposible de realizar en la plataforma elegida.Por ello, también es importante disponer de las herramientas necesarias (en sumayor parte, las que son dependientes del microprocesador, ya que son las másespecíficas y por ello las que presentan más problemas), y no tener problemas conel hardware, antes de empezar a pensar en codiseño.

Estamos ante un campo que avanza rápida y constantemente. Lo que es válidohoy puede no ser válido dentro de un año. Hay que estar siempre al tanto de lasnuevas tendencias y desarrollos. Una forma de minimizar la incomodidad que re-sulta de esto es a través de herramientas y cores de código abierto, que en caso decambio, pueden modificarse para cumplir nuevas funciones (por ejemplo Linux,PeaCE y Leon). Pero para que este enfoque sea del todo válido hay que alcan-zar una masa crítica de desarrolladores/colaboradores. Por ello se presenta comouna idea interesante el dirigir los esfuerzos futuros a sinergizar a todos los desa-rrolladores que se puedan, ya que realmente hay muchísimos desarrolladores desistemas integrados en el mundo, aunque por ahora cada uno utilice un conjuntode herramientas distinto.

10.1. Futuras líneas de trabajo

Según lo comentado anteriormente, y ya que es posible que, en un futuro, serealizen en el Departamento de Ingeniería Electrónica proyectos de investigaciónsobre el tema del codiseño HW/SW, se va a proceder a comentar las líneas de

1De hecho, tanto la placa XSV-800 como la FPGA Virtex XCV800 están ya descatalogadas.2Tanto la parte HW como la parte SW de la aplicación tienen licencia LGPL.

70


trabajo principales que han surgido de la realización de este proyecto. Estas lí-neas de investigación y desarrollo que se proponen aquí presentan, en mi opinión,grandes posibilidades de reutilización, establecimiento de una base de usuarios yrealización de publicaciones.

10.1.1. Adaptación de PeaCE a una plataforma propia

La primera línea de investigación que se sugiere es la adaptación de PeaCE auna plataforma propia3. El primer y más importante paso para conseguir esto esañadir soporte para el procesador Leon 2 a PeaCE4. Disponemos de al menos dossimuladores para el procesador Leon 2, uno de ellos es el simulador generado porArchC, que es de distribución libre y código abierto5. Esta sería una aportaciónmuy interesante a un proyecto de codiseño que puede beneficiar a muchos desa-rrolladores. Como añadido, al implementarse todo el diseño híbrido en una FPGA,todo es independiente de la plataforma, salvo parámetros como los tiempos de es-pera en los accesos a memoria, que se probablemente se puedan implementar enfunción de parámetros configurables.

Se puede empezar esta tarea automatizando el proceso de co-síntesis de la apli-cación de demostración del capítulo 9. Para realizar esta adaptación tendríamostodo el apoyo y la ayuda de los desarrolladores de PeaCE, y más si la plataformaes del tipo que se sugiere en la próxima sección.

10.1.2. Desarrollo de una plataforma HW opensource

Una manera de contribuir de una forma global al estudio, investigación y de-sarrollo de sistemas integrados en general y aplicaciones de co-diseño HW/SW enparticular es la creación de una placa de desarrollo cuyo diseño sea libre. Al estarsu diseño abierto a uso, inspección y mejora por parte de otros desarrolladores, amedio o largo plazo se tendrá una plataforma útil con los recursos y funcionali-dades más demandadas para el diseño de sistemas integrados. Al poder cualquierequipo o empresa fabricar su propia placa, se reducen gastos de hardware, bienporque un equipo de desarrollo reduzca gastos en concepto de transporte e inter-mediarios, o porque una empresa decida fabricar un cierto volumen de placas y/oinvertir recursos en reducir su coste.

3No recomiendo realizar el esfuerzo para XSV-800 ya que sus recursos limitados son un granlastre a largo plazo.

4De hecho, PeaCE no soporta aún descripción de plataformas, sino que para cada diseño sedefine la arquitectura utilizando el entorno gráfico.

5Si bien la descripción en ArchC de Leon 2 es en sí un trabajo en desarrollo y necesita unpoco más de tiempo para madurar y ser totalmente precisa.

71


Ya que uno de los problemas recurrentes en el diseño de plataformas hardwarepor parte de equipos pequeños es la carencia de herramientas para programar ymanejar la placa una vez que dicha placa ha sido diseñada y fabricada, y sabiendoque en ocasiones el desarrollo, portado, mantenimiento de las herramientas soft-ware se convierte en una carga igual o mayor a la que supone el desarrollo delhardware, voy a proponer un enfoque distinto del usual. La solución que propon-go es diseñar desde el principio la placa para que sea compatible con las herra-mientas XSTOOLs de Xess que, recordemos, son de dominio público y, aunqueson nativas de Windows, ya han sido portadas a Linux. La idea es que añadiendounas líneas dependientes de la plataforma a los ficheros de configuración de estasherramientas, funcionen las XSTOOLs con la placa diseñada.

El diseño de la plataforma hardware por supuesto que no debe ser una copiade las placas de Xess, ya que se estaría infringiendo la propiedad intelectual de di-cho fabricante. Simplemente se diseñaría una placa basada en la FPGA de mayorcapacidad soportada por Xilinx Webpack (aunque se podría hacer el PCB com-patible con alguna FPGA más potente aún no soportada), teniendo en cuenta lassugerencias que se han realizado en otros capítulos (como el utilizar módulos dememoria DIMM6), y añadiéndole los recursos que se utilizan mayoritariamenteen las aplicaciones de codiseño, que suelen ser de procesado multimedia en tiem-po real: entradas y salidas para audio y video, conectores para ethernet, PS/2, yUSB (con los RAMDAC, codecs y chips específicos que se necesiten para contro-lar estos puertos7). Seguramente será necesario añadir una CPLD para que realicefunciones de control.

La ventaja de este enfoque es que, en cuanto tienes la placa terminada, yatienes las herramientas para utilizarla, tanto para windows como para Linux.

Esta plataforma hardware se liberaría, por ejemplo bajo licencia GPL8. Y sele daría soporte bajo PeaCE para codiseño con el procesador Leon 2. Siendo unaplataforma libre, casi seguramente a los desarrolladores de PeaCE les pareceráuna buena idea incluir el soporte para ella en la distribución oficial de PeaCE, loque tendría el efecto de aumentar la base de usuarios.

Además, se podrían crear recursos adicionales como una lista de correo paralos usuarios de la plataforma o una página web con información y diseños básicos.

6Recordemos que Leon 2 no dispone de controlador DDR, así que hay tener cuidado de uti-lizar memoria SRAM o SDRAM si no queremos vernos obligados a implementar un controladorde DDR. La idea aquí es reutilizar el máximo código posible para acelerar el desarrollo de laplataforma hardware.

7A la hora de elegir esos chips, un estudio sobre los drivers para embedded Linux disponiblesnos puede ahorrar mucho trabajo a largo plazo. Ante la duda, hay que aprender de las placas quedisponen de drivers de audio, video, etc. para Linux.

8En mi opinión es mejor una licencia tipo GPL que LGPL, para que las modificaciones quepudieran hacer otros desarrolladores beneficien a la comunidad.

72

Bibliografía

“A room without books is like a body without a soul"– Cicero

[Agu] Miguel A. Aguirre. Página web del proyecto Unshades. http://www.gte.us.es/˜aguirre/Web_unshades/index.

[ARB+05] Rodolfo Azevedo, Sandro Rigo, Marcus Bartholomeu, Guido Arau-jo, Cristiano C. de Araujo, and Edna Barros. The ArchC architecturedescription language and tools.International Journal of Parallel Pro-gramming, 33(5):453–484, 2005.

[ARM99] ARM Limited. AMBA Specification, Rev 2.0. ARM IHI 0011A, May1999.

[ATBT03] M.A. Aguirre, J.N. Tombs, V. Baena, and A. Torralba. Unshades-2:Una plataforma hibrida FPGA-DSP para codiseño y co-depuración. InIII Jornadas sobre Computación Reconfigurable y Aplicaciones (JCRA),Madrid, España, September 2003. IEEE Press.

[BGJ+97] F. Balarin, P. Giusto, A. Jurecska, C. Passerone, E. Sentovich, B. Tab-bara, M. Chiodo, H. Hsieh, L. Lavagno, A. Sangiovanni-Vincentelli, andK. Suzuki. Hardware-Software Co-Design of Embedded Systems, ThePOLIS Approach. Kluwer Academic Publishers, April 1997.

[BGJ+02] Massimo Baleani, Frank Gennari, Yunjian Jiang, Yatish Patel, Ro-bert K. Brayton, and Alberto Sangiovanni-Vincentelli. HW/SW par-titioning and code generation of embedded control applications on areconfigurable architecture platform. InProceedings of the Tenth In-ternational Symposium on Hardware/Software Codesign (CODES-02),pages 151–156, New York, May 6–8 2002. ACM Press.

73

[BHLM92] Joseph Buck, Soonhoi Ha, Edward A. Lee, and David G. Messersch-mitt. Ptolemy: A framework for simulating and prototyping heteroge-neous systems, January 07 1992.

[CAP04] The CAP laboratory of Seoul National University.PeaCE user’s ma-nual version 1.0.b (beta), November 2004.

[CAP05] The CAP laboratory of Seoul National University.PeaCE user’s ma-nual version 1.0.1, July 2005.

[CG03] Lukai Cai and Daniel Gajski. Transaction level modeling: an overview.In CODES+ISSS ’03: Proceedings of the 1st IEEE/ACM/IFIP interna-tional conference on Hardware/software codesign and system synthesis,pages 19–24, New York, NY, USA, 2003. ACM Press.

[CTAT02] F.J. Jurado Carmona, J.N. Tombs, M.A. Aguirre, and A. Torralba. Im-plementation of a fully pipelined ARM compatible microprocessor co-re. In XVII Conference on Design of Circuits and Integrated SystemsDCIS’2002, November 2002.

[DL02] M. Durrant and M. Leslie. How uclinux provides mmu-less processorswith an alternative.Embedded.com, December 2002.

[FAM+97] J. Faura, M. Aguirre, J. Moreno, P. van Duong, and J. Insenser. Fip-soc: A field programmable system on a chip, 1997.

[Gai04] Jiri Gaisler. An open-source VHDL IP library with plug&play configu-ration. In René Jacquart, editor,Building the Information Society, IFIP18th World Computer Congress, Topical Sessions, 22-27 August 2004,Toulouse, France, pages 711–718. Kluwer, 2004.

[Gai05] Gaisler Resarch.Leon2 Processor User’s Manual, Version 1.0.30, XSTEdition, July 2005.

[KHM04] B. Knerr, M. Holzer, and M.Rupp. HW/SW Partitioning Using HighLevel Metrics. InInternational Conference on Computing, Communi-cations and Control Technologies 2004, volume 7, pages 33–39, 2004.

[KYH05] Dohyung Kim, Youngmin Yi, and Soonhoi Ha. Trace-driven HW/SWcosimulation using virtual synchronization technique. In WilliamH. Joyner Jr., Grant Martin, and Andrew B. Kahng, editors,Proceedingsof the 42nd Design Automation Conference, DAC 2005, San Diego, CA,USA, June 13-17, 2005, pages 345–348. ACM, 2005.

74

[NB01] Juanjo Noguera and Rosa M. Badia. A HW/SW partitioning algorithmfor dynamically reconfigurable architectures. InDATE, page 729, 2001.

[Nie] Ralph Niemann. Cool codesign tool.

[Ope] The Opencores Project: creating a set of open source IP cores. Availableonline: http://www.opencores.org.

[Pto] The Ptolemy project web page. http://ptolemy.eecs.berkeley.edu/.

[RABA04] Sandro Rigo, Guido Araujo, Marcus Bartholomeu, and Rodolfo Aze-vedo. ArchC: A SystemC-based architecture description language. InSBAC-PAD, pages 66–73. IEEE Computer Society, 2004.

[RB95] Jerzy Rozenblit and Klaus Buchenriede.Codesign, Computer-AidedSoftware/Hardware Engineering. IEEE Computer Society Press, NewYork, USA, 1995.

[SOIH97] Wonyong Sung, Moonwook Oh, Chaeseok Im, and Soonhoi Ha. De-monstration of codesign workflow in PeaCE, May 19 1997.

[SPA92] SPARC International Inc.The SPARC Architecture Manual: Version 8.Prentice Hall, Englewood Cliffs, New Jersey 07632, 1992.

[Tex04] Texas Instruments Incorporated.TMS320C3x User’s Guide, 2558539-9761 Revision L. Literature number: SPRU031F, March 2004.

[Wik] Wikipedia, the Free Enciclopedia. www.wikipedia.org.

[X E00] X Engineering Software Systems Corporation.XSV Parallel Port Inter-face Application Note by D. Vanden Bout, Version 1.0, April 2000.

[X E01a] X Engineering Software Systems Corporation.XSTOOLs V4.0 UserManual. GUI-Based and Command Line-Based XS Board Utilities, Oc-tober 2001.

[X E01b] X Engineering Software Systems Corporation.XSV Board v1.1 Ma-nual, September 2001.

[Xil00] Xilinx Incorporated. VirtexTM 2.5 V Field Programmable Gate ArraysFinal Product Specification, September 2000.

[Xil02] Xilinx Incorporated. VirtexTM-E 1.8 V Field Programmable GateArrays Production Product Specification, July 2002.

75

Agradecimientos:A todos los que han hecho esto posible: a Soonhoi Ha,Seongnam Kwon, Youngmin Yi y el resto del equipo de PeaCE, por su inestimable

ayuda y paciencia respondiendo a mis preguntas y por su sorprendenteinvitación, a Jiri Gaisler por el procesador Leon, y por hacerlo opensource, aLinus Torvalds, por Linux y por el modelo de trabajo estilo ‘bazar’, a RichardStallman, por GNU, la FSF y las licencias, pero sobre todo por el IdealismoPragmático, a Jon Tombs, Miguel Ángel Aguirre, Ramón González, Manolo

Perales y el resto de profesores ‘enrollaos’ del departamento, también aFrancisco García Bernal, por su inestimable ayuda para hacer funcionar Code

Composer bajo Wine, y a Luis Javier Sanz “Yin Nadie”, por su ayuda yexplicaciones con la instalación del entorno Java, a Alejo Acevedo Civantos“Ionicboy”, Gabriel Pérez Curiel “El Vieri”, Javier Cala “Mono”, Carlos

Calderón “Kalitro”, y el resto de los Jevivoladores Chiflados, por tantos y tantosratos de melenas al viento y amistad incondicional, a los compañeros de escuelamás bravos, entre ellos: Víctor Cañada Calero, María Gil Cabrera “MaGiCa”,Alejandro Barriga, José Miguel Moreno (futuro CEO de Mordor Microsystems),Carlos Borrego, David Alejo “Churr”, y Roberto Conde “Mamuso”, porque el

camino puede ser duro pero con vosotros ha sido, sobre todo, memorable, aFrancisco Montero Chacón “Paco”, por aquellos momentos inolvidables con losG.A.S. y por recordarme la existencia de tan magno programa llamado LATEX (losiento tío, caí en la cuenta de que estuve usando LyX hace varios años), sin elcual este proyecto no habría quedado tan vistoso, a Francisco Javier Romero

López “Javi Gatto”, por ser el mejor compañero de aventuras que se puede tenera este lado del charco, a Daniel Pastor Romero “The Marlboro Man” porque hayque sacarlo aquí, a Miguel Guzmán Miranda “Doctor Uija”, por ser ‘o melhorhermano do mondo’, a Isabel María Guzmán Miranda, por ser una hermana de

las que no hay, a ilogic games, porque es un placer trabajar con vosotros yporque tenemos futuro, a Richard Feynman y Eric Drexler, por ser los tipos más

grandes de lo más pequeño, y por último a mis queridos músicos: a la CasioBongo Band, a Dr. Perales and the Jazz Students, a Tito Puente, Joey DiMaio,

Freddie Mercury, Kai Hansen, Eric Adams, Steve Harris, Bruce Dickinson,Michel Camilo, Hiromi Uehara, The Beatles, Yes, Virgin Steele, Les Luthiers,

Soda Stereo, Yu Miyake, Asuka Sakai y Hideki Tobeta (si, si, los del Katamari). . .

investigación sobre herramientas de codiseño...

Documents