pfc_hgm

Vista previa del material en texto

ESCUELA SUPERIOR DEINGENIEROS
DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA
UNIVERSIDAD DE SEVILLA
Investigación sobre herramientas de Codiseño
Hardware-Software
Proyecto Fin de Carrera
Hipólito Guzmán Miranda
Ingeniero de Telecomunicación
Tutor: Jon Tombs
Sevilla, Mayo 2006
A mis padres
Índice general
1. Introducción 6
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Flujo de diseño en codiseño 8
2.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Tipos de problemas de codiseño . . . . . . . . . . . . . . . . . . 8
2.2.1. System on Board . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. System on Chip . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Codiseño con Softcore . . . . . . . . . . . . . . . . . . . 9
2.3. Flujo de diseño tradicional . . . . . . . . . . . . . . . . . . . . . 9
2.4. Flujo de diseño con herramientas de codiseño . . . . . . . . . . . 11
2.4.1. Especificación del Sistema . . . . . . . . . . . . . . . . . 12
2.4.2. Simulación Funcional . . . . . . . . . . . . . . . . . . . 13
2.4.3. Exploración del Espacio de Diseño . . . . . . . . . . . . 13
2.4.4. Co-Simulación TLM . . . . . . . . . . . . . . . . . . . . 13
2.4.5. Co-Verificación HW/SW . . . . . . . . . . . . . . . . . . 13
2.4.6. Co-Simulación RTL . . . . . . . . . . . . . . . . . . . . 14
2.4.7. Prototipado . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.8. Síntesis del Sistema . . . . . . . . . . . . . . . . . . . . 15
3. Trabajo sobre Unshades-2 16
3.1. Descripción de la plataforma Unshades-2 . . . . . . . . . . . . . 16
3.2. Herramientas Evaluadas . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Problemas Encontrados . . . . . . . . . . . . . . . . . . . . . . . 21
3.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1. Cambio de plataforma . . . . . . . . . . . . . . . . . . . 23
3.4.2. Línea de trabajo sobre Unshades-2 . . . . . . . . . . . . . 24
3.4.3. Consideraciones para una posible Unshades-2.1 . . . . . . 24
3
4. Solución propuesta 26
4.1. Descripción de la solución propuesta . . . . . . . . . . . . . . . . 26
5. Procesador Leon 2 29
5.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1. Diagrama de bloques . . . . . . . . . . . . . . . . . . . . 30
5.1.2. Bus Amba . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Alternativas al procesador Leon 2 . . . . . . . . . . . . . . . . . 32
5.3. Configuración del modelo . . . . . . . . . . . . . . . . . . . . . . 35
5.4. Añadiendo la parte HW de tu diseño a Leon 2 . . . . . . . . . . . 37
6. Placa de desarrollo XSV-800 39
6.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.1. Configuración de jumpers . . . . . . . . . . . . . . . . . 41
6.2.2. Frecuencia de reloj . . . . . . . . . . . . . . . . . . . . . 41
6.2.3. Reprogramación de la CPLD . . . . . . . . . . . . . . . . 41
6.3. Xstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7. Snapgear Linux 44
7.1. Necesidad de un sistema operativo . . . . . . . . . . . . . . . . . 44
7.2. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2.1. Kernels para sistemas con y sin MMU . . . . . . . . . . . 45
7.3. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.4. Añadiendo la parte SW de tu diseño a snapgear . . . . . . . . . . 47
8. Entorno de codiseño PeaCE 52
8.1. Descripción y características . . . . . . . . . . . . . . . . . . . . 52
8.2. Ventajas con respecto a otras soluciones . . . . . . . . . . . . . . 54
8.3. Flujo de diseño en PeaCE . . . . . . . . . . . . . . . . . . . . . . 55
9. Aplicación de demostración 59
9.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.2. Parte hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.3. Parte software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10. Conclusiones 69
10.1. Futuras líneas de trabajo . . . . . . . . . . . . . . . . . . . . . . 70
10.1.1. Adaptación de PeaCE a una plataforma propia . . . . . . 71
10.1.2. Desarrollo de una plataforma HW opensource . . . . . . . 71
Bibliografía 73
4
Índice de figuras
2.1. Flujo de diseño tradicional . . . . . . . . . . . . . . . . . . . . . 10
2.2. Flujo de diseño utilizando herramientas de codiseño . . . . . . . . 12
3.1. Unshades 2. Fotografía . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Diagrama de bloques del sistema Unshades-2 . . . . . . . . . . . 18
4.1. Diagrama de bloques de la solución propuesta . . . . . . . . . . . 28
5.1. Diagrama de bloques del procesador Leon 2 . . . . . . . . . . . . 30
5.2. Mapa de memoria AHB del procesador Leon 2 . . . . . . . . . . 31
5.3. Herramienta de configuración del procesador Leon 2 . . . . . . . 36
5.4. Esquema del cable serie en Y . . . . . . . . . . . . . . . . . . . . 37
6.1. Xess XSV-800. Fotografía . . . . . . . . . . . . . . . . . . . . . 40
6.2. Configuración de jumpers empleada . . . . . . . . . . . . . . . . 41
6.3. Diagrama de bloques de la plataforma Xess XSV-800 . . . . . . . 42
7.1. Herramienta de configuración de Snapgear . . . . . . . . . . . . . 48
7.2. Captura de pantalla del programa minicom . . . . . . . . . . . . . 49
7.3. Herramienta de configuración de Snapgear, modificada . . . . . . 51
8.1. Especificación del sistema en PeaCE . . . . . . . . . . . . . . . . 55
8.2. Especificación de algoritmos en PeaCE . . . . . . . . . . . . . . 56
8.3. Especificación de arquitectura en PeaCE . . . . . . . . . . . . . . 57
9.1. Esquema de entradas y salidas del módulo HW . . . . . . . . . . 60
9.2. Carga de Snapgear en la RAM de la XSV-800 utilizando grmon . 67
9.3. Aplicación de demostración en funcionamiento . . . . . . . . . . 67
9.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 son
cada vez mayores y de naturalezas más diversas. Esto ha dado lugar a que se ten-
gan a la vez, para un mismo sistema, restricciones aparentemente incompatibles,
como pueden ser de trabajo en tiempo real, de tolerancia a fallos o de procesado
de grandes flujos de datos. Este incremento de complejidad y diversidad en las
restricciones que ha de cumplir un sistema dado ha motivado la aparición de siste-
mas híbridos en los que interactúan elementos hardware y software, ya que dichos
elementos pueden complementarse para resolver problemas de distinta naturaleza.
Actualmente se está tendiendo, cada vez más, en el diseño de dichos siste-
mas electrónicos, a estas soluciones en las que se mezclan elementos hardware y
software, debido a las duras restricciones que deben cumplir estos sistemas, como
son las condiciones de tiempo real y el procesamiento rápido de grandes flujos de
datos. Estos sistemas híbridos se han venido diseñando prácticamente ‘a mano’,
en el sentido en que, si bien existen desde hace años herramientas para realizar
la compilación del software y la síntesis del hardware, las decisiones más im-
portantes que han de tener en cuenta la interacción entre ambas partes (como el
particionado HW/SW) se han ido tomando basándose en experiencias previas de
diseño, por lo que se tiene una necesidad de poder aplicar una forma más global
de ingeniería automatizada al problema del codiseño.
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 fuertesdel
software (mayor flexibilidad, facilidad para ejecutar órdenes secuencialmente) y
del hardware (mayor velocidad, posibilidad de realizar procesamiento concurren-
te), pero también debe procurar que los tiempos de desarrollo y depuración no
sean excesivamente elevados. Esto crea la necesidad y conveniencia de trabajar en
entornos integrados de desarrollo en el que se encare toda la problemática de este
tipo de diseños de una forma global, y en el que se puedan automatizar la mayor
parte de tareas a realizar durante el flujo de diseño1.
1.2. Objetivo
El objetivo de este proyecto es realizar una investigación sobre el estado del
arte de las distintas herramientas de codiseño disponibles en el mercado, así como
las distintas plataformas y procesadores (tanto ASIC como softcore) sobre los
que se puedan implementar soluciones de codiseño, orientando el trabajo a poder
realizar codiseño sobre alguna de las plataformas hardware de las que dispone
el departamento. Se pretende también conocer y familiarizarse con el flujo de
diseño de un sistema híbrido HW/SW, al igual que entender el resto de opciones
y compromisos que puedan surgir, de forma que nos introduzcamos poco a poco
en la problemática del codiseño.
1.3. Alcance
El alcance del proyecto consiste en llegar a poder proponer, como resultado de
las investigaciones realizadas, una solución viable para poder realizar codiseño en
el departamento. Es requisito que esta solución pueda funcionar en alguna de las
plataformas hardware de las que dispone el departamento. Como culminación del
proyecto sería deseable llegar a realizar una aplicación sencilla que demuestre la
viabilidad de dicha solución y del flujo de diseño propuesto. Esto puede acarrear
ciertos problemas ya que las aplicaciones y plataformas que se suelen utilizar
para resolver problemas de codiseño disponen normalmente de dispositivos muy
potentes y cantidades más que suficientes de recursos como memoria RAM o
espacio disponible en FPGA, y en este proyecto se ha trabajado con un hardware
muy limitado.
1Por ejemplo, sería deseable poder realizar la partición HW/SW de forma automatizada y
transparente al programador, dada una descripción a alto nivel del sistema.
7
Capítulo 2
Flujo de diseño en codiseño
“Creativity is inventing, experimenting, growing, taking risks, breaking rules, making
mistakes, and having fun"
– Mary Lou Cook
2.1. Generalidades
Aunque el utilizar soluciones de codiseño para resolver un problema concreto
reduce la complejidad individual (y por ello, el coste) de los elementos del siste-
ma1, como contrapartida, el proceso de diseño puede complicarse enormemente.
El flujo de diseño de un sistema híbrido debe contemplar el desarrollo de for-
ma conjunta de hardware y software e incluye, entre sus pasos, descripción a nivel
de sistema, simulación funcional, particionado hardware-software, generación de
interfaces, estimación de costes (de área y retrasos para el hardware y de tamaño
de código y tiempo de ejecución para el software), co-simulación, síntesis e im-
plementación de HW, SW e interfaces. Esta actividad interdisciplinar es lo que se
conoce como codiseño.
2.2. Tipos de problemas de codiseño
2.2.1. System on Board
Si los elementos hardware y software se encuentran en distintos chips den-
tro de una misma placa, la interfaz que transmitirá información entre las partes
hardware y software tendrá ciertas limitaciones, puesto que dicha interfaz ha de
1Ya que en estos casos no es necesario que toda la funcionalidad se concentre en un único
módulo hardware o software.
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”. Como
veremos en el próximo capítulo, este es el caso del sistema UNSHADES-2.
2.2.2. System on Chip
Cuando los elementos hardware y software forman parte del mismo circuito
integrado, la interfaz que los separa puede tener una capacidad mucho mayor para
transferir información, dado que esta interfaz está dentro de un circuito integrado:
estaríamos, en este caso, ante un “System on Chip”. Ejemplos de estos sistemas
son el A7S de Triscend, Excalibur de Altera, Virtex II Pro y Virtex 4 de Xilinx y
FIPSOC [FAM+97].
2.2.3. Codiseño con Softcore
La última opción para atacar la problemática del codiseño es utilizar un único
circuito programable sobre el que se programarán tanto el procesador que ejecuta-
rá la parte software como el circuito que implementará la parte hardware. Nótese
que, ya que tanto la parte software como la parte hardware del diseño estarán im-
plementadas en un circuito programable, estamos nuevamente ante un System on
Chip. Pero existen grandes diferencias: por ejemplo en este caso, la interfaz no
está limitada a priori: podemos conectar los módulos del procesador al hardware
como queramos. Incluso podemos implementar más de un procesador en la misma
FPGA. También podemos añadir o eliminar funcionalidades del microprocesador
en función de las necesidades de nuestra aplicación. La única limitación la esta-
blece la capacidad del circuito programable que utilicemos. Un par de ejemplos
de softcores son MicroBlaze de Xilinx y Nios II de Altera.
2.3. Flujo de diseño tradicional
En los sistemas híbridos de los que hablamos en la introducción, el diseño
se ha venido haciendo prácticamente ‘a mano’ en el sentido en que, si bien exis-
ten desde hace años herramientas para realizar la compilación del software y la
síntesis del hardware, las decisiones más importantes que han de tener en cuen-
ta la interacción entre ambas partes (como el particionado HW/SW) se han ido
tomando basándose en experiencias previas de diseño.
En general, el flujo de diseño que se puede realizar sin ayuda de ninguna he-
rramienta de automatización es el que aparece en la figura 2.1, en la página 10.
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 realizar
el 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ódigo
fuente), la velocidad de proceso o el consumo de potencia. En la práctica es de-
seable establecer un equilibrio entre todos los factores, aunque se otorguen pesos
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 que
deben implementarse en un dispositivo concreto. Para automatizar este paso, se
han propuesto varios algoritmos [BGJ+02, NB01, KHM04].
2.4. Flujo de diseño con herramientas de codiseño
Debido a que se han realizado múltiples investigaciones respecto al tema del
codiseño Hardware/Software, existen hoy día múltiples entornos de desarrollo que
atacan directamente a la mayor parte de los problemas asociados a la temática del
codiseño. Existen tanto proyectos de investigación como POLIS [BGJ+97], orien-
tado al diseño de sistemas híbridos para control, y COOL [Nie], orientado a siste-
mas que procesan flujos de datos, como soluciones comerciales, como pueden ser
CoWare Codeveloper, Celoxica DK Codesign Suite, Xilinx Embedded Develop-
ment Kit o Altera Nios II Integrated Development Environment. Estas soluciones
comerciales han ido reemplazando a los esfuerzos investigadores anteriormente
mencionados, cada uno en su nicho de aplicación (por ejemplo, dispositivos de
fabricantes concretos).
De una forma general, utilizando herramientas software específicas para rea-
lizar codiseño HW/SW, podemos esperar un diagrama de flujo de diseño como el
de la figura 2.2 (página 12). Normalmente cada uno de los pasos se realiza con
una herramienta diferente, por lo que la integración de las distintasherramientas
en un único flujo de diseño no es una tarea trivial.
11
Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño
Figura 2.2: Flujo de diseño utilizando herramientas de codiseño
2.4.1. Especificación del Sistema
El primer paso para atacar la problemática de diseñar un sistema híbrido Hard-
ware/Software es el realizar una descripción del sistema que se pretende imple-
mentar en un lenguage de abstracción que esté por encima de los lenguages con-
cretos en los que se describirán el software (por ejemplo, C) o el hardware (por
ejemplo VHDL o Verilog). Esto es importante de cara a poder estudiar indivi-
dualmente los bloques funcionales que compongan el diseño y su interacción abs-
trayéndose de si la implementación de estos bloques se hará en hardware o en
software. En definitiva, si el diseñador no es capaz de realizar esta descripción a
alto nivel, es porque está dando por supuesto que ciertos bloques funcionales de
la aplicación se implementarán de cierta forma concreta.
Algunos lenguajes que nos permiten realizar esta descripción a alto nivel del
sistema son Matlab, Simulink, SystemC y los grafos de flujos de datos [SOIH97]
de PeaCE. Es deseable que, en la medida de lo posible, estas descripciones de
alto nivel sean directamente traducibles a descripciones software o hardware, de
forma que, una vez decidido el particionado HW/SW, la síntesis de cada una de
las partes sea automática.
12
Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño
2.4.2. Simulación Funcional
El siguiente paso consiste en realizar una simulación funcional del sistema
descrito, para comprobar si realmente la aplicación descrita coincide con las es-
pecificaciones deseadas. Los lenguajes con los que se suelen realizar las descrip-
ciones a alto nivel del sistema se distribuyen normalmente con simuladores que
permiten realizar simulaciones funcionales de los sistemas descritos, por lo que
la disponibilidad de un simulador raramente es un problema. Sólo cuando nuestra
descripción a alto nivel es completamente funcional tiene sentido seguir adelante
con el flujo de diseño para buscar una arquitectura óptima.
2.4.3. Exploración del Espacio de Diseño
La exploración del espacio de diseño, se hace manualmente utilizando una
herramienta de simulación TLM. El objetivo es evaluar las distintas alternativas de
particionado y catalogarlas según rendimiento, para tomar una decisión respecto
al particionado HW/SW que cumpla con los requerimientos del sistema.
2.4.4. Co-Simulación TLM
Se trata de una simulación a nivel transaccional2. En un modelo transaccional,
los detalles de la comunicación entre bloques computacionales están separados
de las descripciones de dichos bloques. Los bloques computacionales y de comu-
nicación se conectan a través de tipos abstractos de datos. La comunicación se
modela a través de canales, de forma que las peticiones de transacción se realizan
a través de funciones de interfaz correspondientes a los modelos de los canales
de comunicación. Detalles innecesarios de la comunicación y la computación se
ocultan en TLM pero pueden ser añadidos más adelante. TLM acelera la simu-
lación y permite explorar y validar diferentes alternativas de diseño en un nivel
superior de abstracción [CG03].
Algunas herramientas de simulación TLM disponibles en el mercado son Sy-
nopsys CoCentric Studio, CoWare ConvergenSC y Axys MaxSim (para ARM).
2.4.5. Co-Verificación HW/SW
El objetivo de este paso es comprobar que, tras el particionado, nuestro sis-
tema tiene las mismas funcionalidades que en la descripción funcional y cumple
con los requisitos adicionales que le hayamos impuesto3. Esta co-verificación es
2TLM son las siglas de Transactional Level Modelling
3Por ejemplo, ciertos requisitos de timing.
13
Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño
importante ya que si bien la simulación TLM realizada anteriormente es muy efi-
ciente en tiempo, existen aspectos prácticos de los bloques computacionales del
diseño que no se han considerado aún.
2.4.6. Co-Simulación RTL
La coverificación HW/SW se hace normalmente a través de una cosimulación
a nivel RTL4. Esto es un problema complejo en sí mismo ya que para realizar esta
cosimulación se necesita:
Un programa que simule adecuadamente y de forma precisa el HW, por
ejemplo un simulador de VHDL o Verilog.
Un programa que simule adecuadamente y de forma precisa el comporta-
miento del SW, es decir, un 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 de
generar ficheros de traza con los accesos a memoria para utilizar una técnica
de sincronización virtual basada en la traza de memoria [KYH05], técnica
que ofrece un mejor rendimiento en la simulación.
La herramienta comercial más popular en la actualidad para realizar coverifi-
cación HW/SW es Mentor Seamless CVE, pero existen alternativas como Aldec
HES (Hardware Embedded Simulation)7.
2.4.7. Prototipado
Una vez que se tienen las descripciones de las partes hardware, software, e in-
terfaces, se pueden utilizar herramientas que existen desde hace años para realizar
la síntesis del hardware (herramientas de síntesis, y ‘placement and routing’ si el
hardware se va a sintetizar sobre un circuito programable, como es nuestro caso)
y del código objeto para el microprocesador (compiladores). En este momento
4Register Transfer Level.
5Instruction Set Simulator.
6Lo cual no es posible normalmente, ya que difícilmente se tiene acceso al código fuente de
los simuladores.
7Pero a la hora de escoger las herramientas a utilizar, el aspecto más importante que hay que
evaluar es si el procesador que se va a utilizar está soportado. Como se verá en el siguiente capítulo,
en la plataforma inicialmente escogida para este proyecto se utiliza un procesador de señal (DSP)
de Texas Instruments que carece totalmente de soporte en las herramientas comerciales
14
Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño
es cuando se fabrica un prototipo, sobre el que se demostrará de forma práctica
el sistema híbrido funcionando. De esta experiencia se extraen conclusiones muy
útiles de cara a la síntesis del sistema final.
2.4.8. Síntesis del Sistema
Tras comprobar que el prototipo funciona correctamente y es apropiado para
la aplicación que se quiere resolver, se procede a realizar la síntesis del sistema
final.
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 de
Sevilla [ATBT03]. Unshades-2 es la segunda plataforma de la familia Unshades1,
una familia de tarjetas de desarrollo, basadas en FPGAs de Xilinx, especialmente
diseñadas para realizar depuración hardware en tiempo de ejecución de diseños
reales.
El propósito de la plataforma Unshades-2 es, por un lado, proporcionar in-
formación comprensible sobre el estado interno de sus elementos, tanto software
como hardware, mientras están funcionando (es decir, el sistema está diseñado
para ser observable) y, por el otro, permitir al diseñador realizar cambios sobre
dichos estados (es decir, el sistema es controlable). Esta observación y control
se realizan a través de unos puertos de entrada/salida que se conectan a un PC,
que debe disponer de las herramientas adecuadas para realizar la comunicación
con la placa, y presentar la información al usuario de forma comprensible (véase
la figura 3.1, en la página 17). De esta forma, el sistema se puede utilizar para
depurar los módulos HW y SW de un sistema híbrido.Otro aspecto atractivo de
Unshades-2 es que, al facilitarnos tanta información para la depuración, es conce-
bible un sistema de desarrollo en el que más que realizar simulaciones de distintas
soluciones de particionado y síntesis, podríamos probarlas directamente sobre la
placa y medir sus rendimientos (tiempos de procesado, consumo de potencia).
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 plataforma
interesante sobre la que investigar distintas soluciones a este problema, por la fa-
cilidad para extraer información útil que brinda. El trabajar sobre esta plataforma
tiene en principio un cierto valor añadido, ya que aporta algo más que los elemen-
tos hardware y software: gracias a la controlabilidad y observabilidad que presen-
ta al diseñador, es especialmente útil para proyectos de investigación y desarrollo,
puesto que podemos comprobar fácilmente si las decisiones que se van toman-
do afectan positivamente o no al rendimiento de los módulos sintetizados. En la
figura 3.2, en la página 18, podemos ver una fotografía del sistema de desarrollo.
La plataforma Unshades-2 está construida alrededor de cuatro dispositivos:
S-FPGA2 FPGA Virtex 100E / 1000E, de Xilinx [Xil02], compatible con
el encapsulado PQ240, con 32400 y 331776 puertas lógicas equivalentes
respectivamente.
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. Este
procesador pertenece a la familia C3x [Tex04] y el encapsulado con el que
aparece en Unshades-2 es el PGE150.
Memoria flash de 256 kwords (512 kbytes), modelo Am29LV400B B-70R
de AMD.
La conexión entre estos elementos se puede apreciar en la figura 3.2. Además,
Unshades-2 dispone de otros elementos, como los puertos de expansión, entra-
da/salida y enlace con PC.
3.2. Herramientas Evaluadas
Durante el tiempo que se estuvo trabajando con Unshades-2, se estuvieron
evaluando distintas herramientas de codiseño HW/SW. Desafortunadamente, las
herramientas comerciales soportan sólo un pequeño subconjunto de los micropro-
cesadores disponibles en el mercado, por lo que el primer escollo con el que nos
encontramos al realizar el presente proyecto fue la falta de soporte para los proce-
sadores de la familia C3x. Esto significa que, si queremos hacer codiseño con un
procesador de esta familia, necesitaremos añadir nosotros mismos el soporte para
este tipo de procesador, lo que nos hace descartar inmediatamente los programas
que sean de código cerrado. Pero la mayoría de proyectos de codiseño que son
de código abierto son proyectos de investigación que dejaron de actualizarse hace
años4.
Entre los entornos de codiseño y herramientas que se evaluaron se encuentran:
POLIS. Este trabajo académico ha sido realmente importante, y ha dado co-
mo fruto muchas publicaciones que han servido de punto de partida para el
presente proyecto [BGJ+97]. Incluso se planteó en principio como opción
para el presente proyecto el realizar una adaptación de POLIS para añadirle
la capacidad de realizar cosíntesis para la plataforma Unshades-2. El pro-
blema principal que se ha encontrado con POLIS es que como proyecto dejó
de ser activo y de tener base de usuarios hace varios años. La última versión
3Control FPGA, es una FPGA dedicada a realizar funciones de control como la programa-
ción de la S-FPGA, control de las señales de reloj, control del DSP a través del puerto JTAG y
readback/writeback del estado interno de la S-FPGA a través de las líneas Selectmap.
4Por ejemplo, la página web del proyecto Chinook (Department of Computer Science and En-
gineering, University of Washington) no ha sido actualizada desde 1999, y COSYMA (COSYnthe-
sis for eMbedded Achitectures, de la Technical University of Braunschweig) dejó de desarrollarse
alrededor de 1998.
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 de
correo 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 de
descripción no gráficos, como son HandelC y otras extensiones de C y C++.
La herramienta da soporte para poder trabajar con los PowerPC 405 que se
pueden encontrar en las FPGA Virtex II Pro y con el softcore Microbla-
ze de Xilinx. El principal impedimento para poder utilizar esta herramienta
comercial es que, como tantas otras, carece de soporte para DSPs de Texas
Instruments.
Impulse Codeveloper. Impulse CoDeveloper, al igual que Celoxica DK De-
sigh Suite, es una herramienta de codiseño hardware/software que permite
describir un sistema híbrido utilizando una variante del ANSI C, en este ca-
so Impulse C. Impulse C no es, técnicamente hablando, un subconjunto de
ANSI C, ya que es posible hacer uso de todas las funcionalidades de C a
la hora de programar un test bench o de describir los procesos SW que se
ejecutarán en un microprocesador. Sin embargo, para los procesos que se
traducirán directamente en diseños hardware, se imponen ciertas restriccio-
nes al código Impulse C6. La herramienta soporta únicamente los micropro-
cesadores Altera Nios, Xilinx Microblaze y los PowerPC de Xilinx Virtex
II Pro.
Las herramientas de Xilinx, como Xilinx EDK (Embedded Design Kit),
que tuvieron que ser descartadas para el trabajo con Unshades-2 ya que úni-
camente soportan los procesadores que utilizan los dispositivos de Xilinx,
como Microblaze o PowerPC. Únicamente utilizaremos las herramientas de
Xilinx para hacer la síntesis de la parte HW de los diseños, ya que estamos
trabajando con FPGAs de este fabricante.
PeaCE7 codesign environment. Más adelante, en el capítulo 8, se hará una
descripción más detallada, pero por ahora comentaremos que de todas las
aplicaciones evaluadas, es la única de la que realizar una adaptación a nues-
tra plataforma es factible: es software libre (licencia tipo BSD), por lo que
es posible modificarlo para añadir soporte para Unshades-2, es uno de los
5polis-users@ic.eecs.berkeley.edu
6Básicamente: soporte limitado para punteros, carencia de soporte para funciones recursivas,
y ciertas restricciones sobre las instrucciones de control de flujo. Esto tiene mucho sentido, ya que
si se tradujera directamente un programa C sin restricciones en su código a hardware el resultado
distaría mucho de ser eficiente.
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 dar
soporte a los usuarios del software que deseen utilizarlo con nuevas plata-
formas. En PeaCE, tanto los algoritmos como la arquitectura del sistema
híbrido se especifican a través de un interfaz gráfico desarrollado en Java.
Por todo ello, una vez estudiadas las distintas herramientas de codiseño, se
decidió optar en principio por añadir soporte para la plataforma Unshades-2 al
entorno de codiseño PeaCE.
3.3. Problemas Encontrados
Ya hemos visto en el apartado anterior que los DSP de Texas Instruments,
en particular los de la familia C3x, carecen de soporte en las herramientas de
codiseño disponibles. La experiencia con Unshades-2 nos ha descubierto ciertas
dificultades que la plataforma plantea para su uso como sistema híbrido:
Falta de soporte para el procesador C33 por parte de las herramientas de
codiseño HW/SW (como se ha visto anteriormente).Falta de toolchain GNU para el procesador. En realidad existe una adap-
tación del compilador gcc8 para las familias de DSP C3x y C4x, llamado
c4x-gcc, pero se necesita una versión concreta de una biblioteca runtime
propietaria de Texas Intruments, de la que no disponíamos, para poderlo
compilar. Sin esta biblioteca, el compilador únicamente puede generar fi-
cheros objeto (.o), y no ejecutables. Al no poder utilizar el compilador de
GNU, la única opción posible era utilizar un compilador propietario de Te-
xas Instruments, que originaba otros problemas, entre ellos imposibilidad
de utilizar el simulador libre del que disponíamos para el DSP (c4x-gdb9).
Carencia de ISS para el procesador. Esto ha sido sorprendente ya que se
han evaluado tres simuladores distintos para el C33. La problemática aquí
estriba en que para que un simulador del juego de instrucciones de un proce-
sador pueda ser utilizado para hacer cosimulación HW/SW, debe de poderse
interconectar a un simulador de VHDL o Verilog que simule la parte HW
del diseño. Es decir, que para que un ISS pueda ser utilizado debe de tener
8GCC son las siglas de Gnu Compiler Collection.
9Realmente gdb es un depurador (Gnu Debugger), y c4x-gdb está diseñado para ser conectado
a placas autónomas basadas en procesadores c3x/c4x a través de conexión por puerto serie o por
socket TCP/IP. Pero aparte de esto, c4x-gdb incluye un modo de funcionamiento en el que se
conecta a un simulador de estas familias de DSP desarrolado por Herman Ten Brugge.
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 realizar
las modificaciones necesarias, o en última instancia debe ser capaz de gene-
rar un fichero con la información de los accesos a memoria (un fichero de
traza).
El primer simulador que probamos fue Sim3x, un simulador desarrollado
por Texas Instruments para ms-dos (que ejecutamos sin problemas bajo Li-
nux utilizando Dosbox10), y descubrimos que no se puede integrar con nin-
guna otra herramienta ya que el programa no está preparado para interactuar
con otros programas, ni permite generar ficheros de traza. Por supuesto, la
modificación del programa para añadirle esa funcionalidad era imposible ya
que no disponíamos de su código fuente.
La segunda alternativa estudiada fue la posibilidad de generar la informa-
ción de traza con los accesos a memoria utilizando Code Composer (un
programa para Windows que se ejecutaría en Linux a través de Wine), em-
pleando un lenguage de scripting de Code Composer llamado GEL11. Esta
alternativa era de una complejidad considerable, ya que habría que escribir
un programa que, tras la compilación del software, analizara el código ob-
jeto presente en el fichero .out, localizara en él los accesos a memoria, y
posteriormente generara un script GEL que colocara breakpoints (puntos de
ruptura) en cada uno de dichos accesos. Además, habría que definir funcio-
nes específicas en GEL para intentar recoger la información de los tiempos
y ciclos de acceso. Aunque teóricamente este enfoque podría funcionar, la
viabilidad práctica de esta solución depende de las capacidades reales del
lenguaje GEL y aún no ha sido demostrada. Por otro lado, el trabajo ne-
cesario para implementar esta solución escapa al alcance de este proyecto,
por lo que en su momento se prefirió centrar los esfuerzos en resolver los
problemas que planteaba el simulador c4x-gdb.
El último simulador que fue evaluado fue c4x-gdb, la única de las tres al-
ternativas que es de código abierto. Ya hemos comentado que, al no poder
utilizar el compilador c4x-gcc, por las razones comentadas anteriormente,
era imposible utilizar el simulador c4x-gdb.
Escasez de memoria RAM. Hemos visto en la sección 3.1 que la platafor-
ma no posee ningún dispositivo de RAM on-board. Es posible instanciar
pequeñas memorias RAM dentro de la FPGA, de forma para que el DSP
pueda tener un mínimo espacio sobre el que trabajar con datos, pero como
10Ya que PeaCE se ejecuta bajo Red Hat Linux 8.0, todo programa que queramos integrar con
PeaCE debe funcionar a su vez en Linux, aunque sea tras una capa de emulación.
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). Si
bien puede ser suficiente memoria para manejar ciertas cantidades de datos,
hay que tener en cuenta que en un sistema híbrido HW/SW las tareas que
han sido implementadas en software han de compartir el microprocesador,
lo que significa que necesitamos memoria para guardar la información del
contexto de los procesos y de la pila. Además, no podríamos tener un siste-
ma operativo como Linux ejecutándose en la placa (ya que un sistema Linux
necesita un mínimo de 1MB de RAM para ejecutarse, más RAM adicional
para las aplicaciones), y es muy posible que eCos12, si bien es un sistema
operativo altamente configurable, tenga una huella mínima de uso de RAM
superior a los 48KB. Recordemos que estos 48KB han de compartirse con
los requerimientos de memoria de la parte SW del diseño.
Interfaz FPGA-DSP fija, ya que son pistas en el PCB: es posible que la
S-FPGA tenga que enviar ciertas señales al DSP y no pueda hacerlo por-
que esas pistas no estén conectadas a ella. Si bien este problema no ha sido
estudiado a fondo, si llegara a ocurrir podría eliminar por completo la posi-
bilidad de hacer codiseño con Unshades-2.
Falta de sistemas operativos de tiempo real para el procesador. Actualmente
no existen versiones de Linux o eCos para el procesador C33. Si bien es
teóricamente posible realizar un portado de estos sistemas a nuestro DSP,
ello escapa al alcance del presente proyecto. La única alternativa para poder
conmutar entre las tareas en software es programar un mínimo planificador
de tareas.
Es por todas estas razones por lo que se decide abandonar el desarrollo sobre
Unshades-2. En el siguiente apartado se exponen las conclusiones de la investiga-
ción sobre Unshades-2 y en el capítulo 4 se propone una solución alternativa para
poder realizar codiseño, con otra plataforma hardware.
3.4. Conclusiones
3.4.1. Cambio de plataforma
Teniendo en cuenta los resultados expuestos en los apartados anteriores, rea-
lizar codiseño con Unshades-2 sin modificar la plataforma hardware es una tarea
que roza lo imposible. Además, los esfuerzos necesarios para hacer codiseño en
12embedded Configurable operating system.
23
Trabajo sobre Unshades-2 3.4 Conclusiones
dicha plataforma sobrepasan con creces el alcance de un proyecto de fin de carre-
ra. Es por esto por lo que se propone un cambio de plataforma hardware: sabiendo
tras la evaluación de las herramientas software (sección 3.2) que el soporte pa-
ra ciertos softcores está sobradamente extendido, se plantea el realizar codiseño
sobre una plataforma que únicamente disponga de una FPGA de gran capacidad.
De esta forma se instanciarán un microprocesador y la parte HW del diseño en el
mismo dispositivo. La plataforma propuesta es la placa de desarrollo XSV-800 de
Xess. En el capítulo 6 se hará una descripción más detallada de dicha plataforma.
3.4.2. Línea de trabajo sobre Unshades-2
Otra conclusión del trabajo realizado, además del mencionado cambio de pla-
taforma, es el trabajo concreto que habría que hacer para conseguir hacer codiseño
con Unshades-2 utilizando herramientas de codiseño.
Si se quisiera realizar el esfuerzo, habría que:
Programar un simulador del procesador C33 o adaptar las c4x GNU tools
para que funcionen utilizando Newlib (para esto necesitaríamos primero
realizar el portado de Newlib al C33).
Portar eCos (ya que no podemos utilizar Linux por falta de RAM) al C33.
Nótese que para portar eCos también necesitamos haber portado primero
Newlib. Si no queremos portar eCos, es necesario programar un planifica-
dor de tareas que se encargue de guardar los contextosde las tareas software
y manejar la pila. De todas formas, es poco probable que toda esta funcio-
nalidad se pueda conseguir con tan sólo 48KB de RAM.
Con esto tendríamos las mínimas herramientas que hacen falta para poder em-
pezar a integrar el soporte para Unshades-2 en PeaCE. Aún quedaría por realizar
todo el trabajo de integración con el framework de codiseño.
3.4.3. Consideraciones para una posible Unshades-2.1
En mi opinión el trabajo mencionado en el apartado anterior no compensa
el esfuerzo que es necesario realizar: sería más sencillo modificar Unshades-2
para permitir una adaptación más sencilla y realizable. Por ello se proponen las
siguientes sugerencias y modificaciones, para que sean consideradas para una po-
sible versión 2.1 de Unshades:
Procesador: el primer cambio que se propone consiste en cambiar el DSP
de Texas Instruments por un procesador ampliamente soportado, para el que
24
Trabajo sobre Unshades-2 3.4 Conclusiones
estén disponibles las herramientas anteriormente mencionadas, como podría
ser 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 deben
conectarse a la FPGA. La segunda es que todos los pines del procesador
pasen por la FPGA antes de llegar a los dispositivos de la placa, opción que
añade muchísima flexibilidad a la plataforma y que curiosamente es es lo
que ocurre cuando se utiliza un softcore.
RAM: Es necesario añadir una cantidad suficiente de RAM on-board pa-
ra poder tener un sistema operativo y trabajar de forma cómoda. Con un
mínimo de 4 megas ya podemos tener sistemas Linux con aplicaciones es-
pecíficas (sin soporte para TCP/IP14) sin que la memoria sea una restricción
preocupante. Lo ideal, para aprovechar toda la potencia que ofrece Linux, es
utilizar módulos DIMM, que se pueden encontrar en cualquier tienda de in-
formática y nos permiten tener una capacidad de RAM del orden de cientos
de megabytes.
13Si bien la mayoría de modelos de ARM goza de un buen soporte por parte de las herramientas
de software libre típicas (gcc, eCos, newlib), recomendamos con más énfasis aquellos dos modelos
de ARM que ya disponen de soporte completo en PeaCE: ARM 926EJS y ARM 720T.
14El soporte para TCP/IP y las aplicaciones que lo utilizan consumen una gran cantidad de
memoria.
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 no
action, you haven’t truly decided."
– Anthony Robbins
Tras encarar los problemas encontrados en Unshades-2, se propuso una solu-
ción para hacer codiseño utilizando una plataforma hardware distinta, basada en
una FPGA suficientemente potente como para albergar el softcore y la parte HW
de un diseño híbrido. En principio teníamos dos placas disponibles, FT-Unshades1
y Xess XSV-800. Escogimos la segunda por varias razones: por tener ésta una
disponibilidad mayor (ya que las placas FT-Unshades de las que dispone el de-
partamento están normalmente ocupadas en proyectos de investigación), porque
las herramientas para programar los dispositivos on-board están disponibles pa-
ra Linux2, y porque la distribución del softcore Leon 2 soporta oficialmente la
placa XSV-800, lo que en principio facilita una de las tareas a realizar, que es la
implementación correcta del softcore en la placa de desarrollo.
4.1. Descripción de la solución propuesta
La solución que aquí se propone consiste básicamente en una solución soft-
core en la que todos los elementos del sistema híbrido están implementados en la
FPGA. Esto permite extender el trabajo realizado a otras placas con un poco de
esfuerzo adicional.
1Fault-Tolerant Unshades, la plataforma más moderna (a fecha de 2006) de la familia Unsha-
des, desarrollada por el Área de Ingeniería Electrónica en un proyecto para la Agencia Espacial
Europea, y especialmente preparada para realizar pruebas de tolerancia a fallos sobre circuitos
para aplicaciones espaciales.
2Cuando se comenzó el presente proyecto, las herramientas de FT-Unshades únicamente esta-
ban disponibles para Windows. Actualmente las herramientas de FT-Unshades funcionan perfec-
tamente bajo Linux, ya que fueron portadas en Marzo de 2006.
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). Esta
placa posee suficiente RAM (2MBytes) y demás recursos on board y será descrita
en más profundidad en el capítulo 6. De dicha placa bastará comentar por aho-
ra que dispone de una FPGA Virtex XCV-800 [X E01b, Xil00], que dispone de
aproximadamente 800000 puertas equivalentes (contando RAMs internas), lo cual
es suficiente para implementar un softcore con varios periféricos y algún módulo
hardware específico.
En la FPGA Virtex XCV-800 implementaremos un procesador Leon 2, un
modelo VHDL sintetizable de un procesador de 32 bits que cumple con el estándar
Sparc V8. Las fuentes de este softcore están disponibles libremente bajo licencia
GNU LGPL. Este procesador, junto con las razones por las que se ha escogido
en lugar de alternativas como Microblaze, serán descrito en el capítulo 5 y, entre
sus características, podemos destacar el hecho de que incluye una implementación
del bus AMBA (versión 2.0), lo que permite añadir periféricos y otros módulos
hardware de manera sencilla.
Dado que necesitamos un sistema operativo sobre el que se ejecuten las tareas
software, la parte SW del diseño correrá sobre Snapgear Linux, una distribución
de Linux para sistemas integrados con soporte para el procesador Leon. Snapgear
Linux es una variante 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 a
las ventajas que ofrece, que se han comentado en el capítulo anterior y se verán
en más profundidad en el capítulo 8. Además, otra razón para utilizar este entorno
es que al no existir herramientas comerciales de codiseño HW/SW que tengan
soporte para la familia de procesadores Leon, hemos de escoger una herramienta
de código abierto a la que se pueda añadir soporte para estos procesadores.
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 un
proyecto basado en Linux es el procesador Leon 2, ya que es de código abierto
y viene acompañado de las herramientas necesarias, que también son de código
abierto: compiladores C, versión de Newlib, y versiones de eCos y Linux. En la
sección 5.2 justificaremos en profundidad esta decisión.
5.1. Descripción
El procesador Leon [Gai05] es una implementación en VHDL de un proce-
sador de 32 bits compatible con el juego de instrucciones Sparc V8 [SPA92],
desarrollado para la Agencia Espacial Europea y mantenido en la actualidad por
Gaisler Research. Este procesador no sólo es de código abierto, sino que además
no está ligado a ninguna tecnología de FPGA concreta, a diferencia de soluciones
dependientes de fabricantes como Microblaze de Xilinx o Nios II de Altera.
Entre sus características se pueden destacar:
Cachés de instrucción y datos independientes
Alu para mutiplicación y división hardware
Interfaz para unidades de coma flotante y coprocesadores
Bus AMBA 2.0
Controlador de interrupciones
29
Procesador Leon 2 5.1 Descripción
Controlador de memoria flexible, capaz de trabajar con SDRAM en modo
32 bits y con SRAM y ROM en modos configurables de 8, 16o 32 bits
Puerto de entrada y salida de 16 bits
Dos UARTs
Dos timers de 24 bits
Unidad de Soporte de Depuración (DSU)
5.1.1. Diagrama de bloques
Figura 5.1: Diagrama de bloques del procesador Leon 2
El elemento central del procesador Leon 2 es su Integer Unit de 5 etapas pi-
pelined. Esta Integer Unit está conectada a las cachés de instrucción y datos, y
a la MMU1. Ambas cachés son de tamaño configurable y pueden incluso no ser
sintetizadas. La MMU también es opcional, y en este proyecto no se ha utilizado.
En la figura 5.1 (página 30) se puede observar también la presencia de una unidad
de punto flotante (Floating Point Unit o FPU) y de un co-procesador (CP), aunque
en realidad el procesador Leon 2 no se distribuye con ninguno de estos elementos,
sino que Gaisler Research dispone una unidad de punto flotante que se licencia
de forma separada2, y es el usuario el que puede o no implementar su propio co-
procesador: el procesador Leon 2 implementa únicamente los interfaces a los que
1Memory Management Unit.
2Se trata de la GRFPU (Gaisler Research Floating Point Unit), aunque existen otras alternati-
vas como la Meiko FPU y la LTH FPU.
30
Procesador Leon 2 5.1 Descripción
se conectarían el co-procesador y la FPU. No obstante, una síntesis del procesador
Leon 2 sin ninguno de estos elementos es perfectamente funcional, aunque tenga
menor rendimiento, y es la implementación que se ha realizado en este proyecto.
Otro elemento muy interesante de este procesador es la Unidad de Soporte de
Depuración (Debug Support Unit o DSU), que permite conectar un PC al proce-
sador a través del puerto serie, ethernet o JTAG, para ayudar a la depuración de
software, permitiendo la depuración on-line. Gracias a la DSU se pueden cargar
programas directamente desde el PC, pausar y resetear el procesador, establecer
puntos de ruptura (breakpoints) e incluso realizar ejecución paso a paso.
5.1.2. Bus Amba
El procesador Leon implementa dos buses AMBA: AHB y APB. El bus APB3
se utiliza para acceder a los registros on-chip de los periféricos, mientras que el
bus AHB4 se utiliza para transferencia de datos a alta velocidad. El bus AMBA
hace muy sencillo extender la funcionalidad del procesador añadiendo módulos
hardware. Incluso permite reutilización de código hardware, tanto del propio que
desarrolle el diseñador como de módulos IP de otros desarrolladores [ARM99].
El mercado de propiedad intelectual pone al alcance de cualquier diseñador una
biblioteca enorme de diferentes periféricos y unidades de proceso de datos [Gai04,
Ope]. Debido a la gran aceptación que tiene el bus AMBA en la industria, se
pueden encontrar fácilmente módulos hardware ya preparados para su conexión a
dicho bus.
Rango de direcciones Tamaño Registro Módulo
0x00000000 - 0x1FFFFFFF 512 M Prom Controlador
0x20000000 - 0x3FFFFFFF 512 M Memory bus I/O de memoria
0x40000000 - 0x7FFFFFFF 1G SRAM y/o SDRAM
0x90000000 - 0x9FFFFFFF 256 M DSU DSU
0xB0000000 - 0xB001FFFF 128 K Registros Ethernet
ethernet MAC
Figura 5.2: Mapa de memoria AHB del procesador Leon 2
El mapa de memoria que aparece en la figura 5.2, en la página 31, es el mapa
que se encuentra por defecto en la distribución oficial del procesador Leon 2, pero
3Advanced Peripheral Bus.
4AMBA High-performance Bus.
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 UART
scaler register), por lo que a partir de la dirección 0x800000D05 se pueden añadir
periféricos ‘custom’ (teniendo en cuenta que a partir de la 0x90000000 vuelven a
estar ocupadas, en este caso por la DSU). La tabla con los registros concretos y
las direcciones de memoria en las que están situados es demasiado extensa como
para colocarla en el presente documento pero puede ser encontrada en el manual
del procesador Leon 2 [Gai05].
5.2. Alternativas al procesador Leon 2
El procesador Leon 2 no es el único softcore que se puede implementar en una
FPGA, por lo que en su momento se realizó un estudio de softcores disponibles,
para tomar una decisión informada sobre cuál utilizar:
1. Procesadores basados en ARM: la primera alternativa de softcore que se
consideró fue una implementación de un procesador ARM que se realizó
como proyecto de fin de carrera en el departamento en 2002 [CTAT02]. No
se usó porque, si bien las instrucciones del juego ARM fueron probadas una
por una con éxito, para garantizar el cumplimiento total de las especificacio-
nes ARM de este procesador habría que utilizar vectores de test propietarios
que sólo están disponibles para los desarrolladores que tengan licencia de
ARM, por lo que se desconoce si este softcore funcionará adecuadamente
al ejecutar programas complejos, como los producidos por un compilador C
(en contraposición a los generados manualmente en ensamblador). Además,
si bien el código VHDL del proyecto tiene una licencia de libre distribución,
es posible que la distribución e implementación del core ARM en sí viole
ciertas patentes de ARM. Todas estas dificultades, que surgen a causa de la
proliferación de estándares cerrados, impiden el uso de este interesante core
VHDL para nuevos proyectos. Esta situación es bastante desafortunada, ya
que los procesadores ARM disponen de muchísimas herramientas como si-
muladores (Armulator), bibliotecas runtime (glibc y Newlib), compiladores
e incluso un port de la distribución Debian GNU/Linux6.
5Realmente es a partir de la 800000E0, ya que estudiando detalladamente el código del proce-
sador Leon 2 se ha visto que en la dirección 0x800000D0 hay asignado un registro correspondiente
al ‘PCI target mapping’.
6Véase http://www.debian.org/ports/
32
Procesador Leon 2 5.2 Alternativas al procesador Leon 2
Además, como se ha comentado en el capítulo 3, PeaCE ya trabaja con
dos modelos de ARM (ARM 926EJS y ARM 720T). Dichos modelos están
perfectamente integrados en el entorno, lo que significa que existe mucho
trabajo ya realizado que se podría reutilizar.
2. Microblaze: este procesador, en principio, y ya que nosotros trabajamos con
FPGAs de Xilinx, es una alternativa igual de válida que el procesador Leon
2. Pero hagamos unas consideraciones adicionales, pensando en la posibili-
dad de reutilizar los esfuerzos del presente proyecto en otros proyectos de
investigación, sabiendo que muchos de los que se realizan actualmente en
el Departamento de Ingeniería Electrónica comprenden la depuración hard-
ware y/o la realización de pruebas de tolerancia a fallos: ¿Cómo se hace
depuración de HW/SW sobre Microblaze si es cerrado? ¿Dónde introduces
un SEU7 para hacer pruebas de tolerancia a fallos? ¿Cómo sabes bien qué
estás leyendo o modificando? Será posible hacer ingeniería inversa, pero,
¿merece la pena el esfuerzo? Además, en general para estos softcores de-
pendes de las herramientas (compilador, simulador, c runtime library, S.O.
en tiempo real) que te proporcione el fabricante8. Por otro lado, la reutiliza-
ción de software se complica si se utilizan sistemas operativos propietarios
del fabricante (Nucleus o Xilkernel, en el caso de Microblaze), aunque tam-
bién existe una versión 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ícilmente
la implementación podrá realizarse y, en caso de que se pueda, no será nada
eficiente en una FPGA de Xilinx.
4. Leon 3: este procesador, que es la evolución natural del procesador Leon
2, está escrito en un VHDL más difícil de entender que Leon 2, no posee
compatibilidad binaria con éste, está peor documentado (a fecha de Octubre
de 2005), y el único simulador disponible para él es el propietario TSIM.
No obstante, ofrece mejores prestaciones9 por lo que en el futuro, a medidaque Leon 3 se vaya imponiendo como estándar de facto y Leon 2 vaya
dejando de tener soporte, será inevitable considerar Leon 3 para proyectos
de investigación y aplicación.
7Single Event Upset.
8Aunque en muchos de los casos, las herramientas de diseño de los fabricantes ejecutan en
segundo plano versiones parcheadas de las herramientas GNU, como por ejemplo el mb-gcc, com-
pilador de c para microblaze, lo cual da que pensar.
9A costa de una mayor ocupación en área, por lo que para nuestra tarjeta de desarrollo es
mejor idea utilizar Leon 2.
33
Procesador Leon 2 5.2 Alternativas al procesador Leon 2
5. Leon 2: Leon 2 es un procesador con mayor base de usuarios (a fecha de
Octubre de 2005, cuando se hicieron estas consideraciones), con todas las
herramientas necesarias disponibles, incluso tenemos la opción de simu-
lar tanto con TSIM como con el simulador generado por ArchC [RABA04,
ARB+05], una herramienta de libre distribución que nos permite generar si-
muladores interpretados, simuladores compilados y ensambladores a partir
de una descripción de la arquitectura del procesador10. Como se ha comen-
tado anteriormente, nos hemos fijado en Leon por ser de código abierto, y
por no estar ligado a ninguna tecnología de FPGA concreta. Además de lo
que se ha comentado anteriormente sobre Leon 3, una de las razones por
las que se ha escogido para este proyecto Leon 2 es porque existe un ‘board
support package’ para la placa XSV-800 para Leon 2 que no existe para
Leon 311.
6. Distintos cores del proyecto opencores [Ope]: se estuvieron evaluando al-
gunos diseños del proyecto opencores, y en su momento se encontró que
algunos no están terminados, otros están hechos pero no tienen todas las
herramientas que necesitamos (diseñar el procesador es sólo el primer paso,
el segundo es portar el toolchain GNU, y partir de ahí se pueden portar las
herramientas y bibliotecas necesarias, pero ello requiere un esfuerzo consi-
derable), y un problema mayor que plantean es que se desconoce si violan
patentes, copyrights u otra clase de propiedad intelectual12. De entre los
procesadores evaluados, hay uno muy interesante, OpenRisc, descrito en
Verilog, cuyo desarrollo está completo y tiene su propio port del toolchain
GNU e incluso un ISS. Este procesador se plantea como una buena alterna-
tiva a Leon, pero dado que nosotros vamos a trabajar la parte HW de nuestro
diseño en VHDL (ya que PeaCE trabaja con VHDL), e integrar VHDL con
Verilog, si bien es factible, es poco conveniente y en algún momento podría
causarnos problemas, por lo que finalmente se optó por utilizar el procesa-
dor Leon 2.
10Actualmente, los desarrolladores del proyecto ArchC están trabajando en la descripción
ArchC del procesador Leon 2
11Más adelante comprobamos que dicho ‘board support package’ no producía los resultados
que eran de esperar, resultando en una netlist incorrecta, por lo que se tuvo que realizar la síntesis
manualmente utilizando Xilinx ISE.
12De hecho, entre los disclaimers que acompañan a los diseños de opencores, se pueden en-
contrar mensajes como: "I have no idea if implementing this core will or will not violate patents,
copyrights or cause any other type of lawsuits. I provide this core as is, without any warranties."
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 dichas
herramientas. En Red Hat 8.0 se puede indicar durante el proceso de instalación
del sistema operativo que queremos instalar las herramientas Tk. La figura 5.3 es
una captura de pantalla de la herramienta de configuración que muestra la confi-
guración de las memorias caché on-chip. La versión concreta de Leon 2 que se ha
utilizado es la 1.0.30 xst, y las características fundamentales de la configuración
utilizada son:
Ausencia de unidad de manejo de memoria (MMU), unidad de punto flo-
tante (FPU) y coprocesador (CP).
La unidad de enteros (integer unit) se ha configurado de forma que pueda
responder a las instrucciones MUL/DIV del juego de instrucciones de Sparc
V8, y se ha inferido un multiplicador para que estas instrucciones no tengan
un tiempo de ejecución excesivo.
Tecnología objetivo Virtex.
Cachés de instrucciones y datos, cada una consta de 1 set de 4Kbytes y 32
bytes por línea.
Unidad de Soporte de Depuración (DSU) habilitada.
Controlador de memoria SRAM de 16 bits de ancho del bus de datos.
Además, hemos modificado el wrapper leon_eth_xsv800.vhd, uniendo los pi-
nes RTS13 y CTS14 de la UART 1 (señales PIO(13) y PIO(12) del procesador), que
es la que utilizaremos para establecer una comunicación con Snapgear Linux, a
través del programa minicom15. Es necesario realizar esto ya que, en caso contra-
rio, Snapgear se cuelga al arrancar, durante la inicialización de la UART, ya que
los pines que pretende utilizar para realizar el control de flujo por hardware (RTS
y CTS) no están mapeados al exterior de la FPGA. Esto es así ya que la placa
XSV-800 sólo dispone de un chip MAX232, lo cual significa que sólo tenemos
cuatro señales disponibles: TX, RX, CTS y RTS, de forma que la UART1 de Leon
2 utiliza únicamente TX y RX, y la DSU transmite y recibe utilizando las pistas
CTS y RTS. De hecho, para la realización de este proyecto se ha fabricado un
13Request To Send.
14Clear To Send.
15Unir los pines CTS y RTS de una UART no es ninguna novedad: es lo que muchísimos cable
modem nulos (null modem cables) hacen ya.
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) - TD
RTS (Tx) - RD
GND GND GND
Figura 5.4: Esquema del cable serie en Y
cable en Y que permite realizar dos comunicaciones serie con la placa XSV-800
(ver figura 5.4 en la página 37). Para evitar las optimizaciones agresivas, hemos
mapeado esta señal rts-cts a un pin de la FPGA (concretamente, a uno de los leds
del diagrama de barras).
Tenemos que añadir que en principio se intentó realizar la síntesis del proce-
sador Leon con el módulo ethernet, pero esto no fue posible debido a un problema
con los 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 sus
recursos RAM que aunque implementemos el módulo ethernet no podremos tener
ninguna aplicación de red significativa, ya que este tipo de aplicaciones suelen
demandar bastante RAM durante su ejecución.
5.4. Añadiendo la parte HW de tu diseño a Leon 2
Para añadir la parte hardware de un diseño a Leon 2, tenemos en principio 3
opciones:
1. Utilizar el interfaz genérico para conectar el Leon a un co-procesador: de es-
ta forma, el bloque HW haría las veces de coprocesador. Como ventaja tiene
que tendrá una rapidez considerable, ya que el interfaz conecta de una for-
ma muy directa con el núcleo de la CPU, pero como desventajas tiene que
el interfaz es bastante específico, por lo que no es extensible a otros pro-
cesadores, y además puede ser muy complicado realizar una exploración
del espacio de diseño, y que para utilizar este enfoque se requiere obvia-
mente que no dispongamos ya de un co-procesador que queramos utilizar.
Como nota a considerar, comentaremos que realmente en muchos casos el
codiseño hardware/software se plantea como el sintetizar ciertas tareas en
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 de
Impulse C).
2. Añadir la parte HW del diseño como un periférico AHB, muy útil si que-
remos transferir grandes cantidades de información entre las partes HW y
SW del diseño.
3. Añadir la parte HW del diseño como un periférico APB, con una tasa de
transferencia de informaciónmenor, pero mucho más sencillo de imple-
mentar, es la elección ideal si las operaciones que se realizan en el interfaz
HW/SW son operaciones de control más que de transferencia de grandes
volúmenes de datos.
En la aplicación de demostración realizada en el capítulo 9 utilizamos el bus
APB, para demostrar lo sencillo que es añadir módulos HW, y también porque
se trata de una aplicación de muy poca complejidad que no necesita de interfaces
avanzados.
Para añadir la parte HW de la aplicación de demostración, hay que definir
dos señales en el módulo que correspondan a los buses de entrada y salida APB,
modificar el fichero mcore.vhd para añadir nuestro componente ‘hwpart’ como
un periférico APB esclavo, y modificar apbmst.vhd para que extender la decodi-
ficación de las direcciones, de forma que nuestro periférico sea reconocido en la
dirección de memoria que hemos escogido (concretamente la 800000E0). Ade-
más, ya que la parte HW del diseño actúa directamente sobre leds de la placa, hay
que modificar todos los ficheros de los niveles superiores en la jerarquía hasta lle-
gar al wrapper externo (mcore.vhd, leon_eth.vhd y leon_eth_xsv800), y además
añadir los pines de los leds al ucf.
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 un
sistema mínimo sobre una FPGA Virtex XCV800, de aproximadamente 800000
puertas equivalentes, si en la cuenta de puertas equivalentes incluimos a las RAM
internas. Tanto la FPGA como la placa de desarrollo están ya descatalogadas, y
los recursos en la placa están bastante limitados en relación a lo disponible hoy en
día.
La placa de desarrollo dispone únicamente 2MB de memoria SRAM, que se
han de compartir entre la imagen desde la que se arrancará el sistema operativo y
la memoria disponible para los procesos del sistema, ya que no vamos a utilizar la
Flash. Esta Flash comparte pines del bus de direcciones con los interruptores DIP
presentes en la placa, que utilizamos para activar la DSU del procesador, por lo
que no podemos utilizar la Flash.
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 Efecto
J13 y J14 Abiertos Alimentación utilizando
fuente ATX
J32 Shunt en pines 1-2 La alimentación de 2.5V para la
FPGA se genera en la placa
J22 Shunt en pines 2-3 Oscilador programado
Shunt en pines 1-2 Oscilador en modo programación
J36 Shunt en pines 1-2 CLK interno
(generado por el oscilador)
J23 Abierto La CPLD no puede ser reprogramada
Cerrado La CPLD puede ser reprogramada
J29, J30 y J31 Shunts en pines 2-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 su
disposición concreta no influye en nuestra aplicación ya que no utilizamos dicho
puerto. Igualmente ocurre con los jumpers de otros dispositivos on-board, como
el RAMDAC VGA. Para los jumpers para los que aparecen dos configuraciones,
se utiliza una u otra según el efecto deseado.
6.2.2. Frecuencia de reloj
Se ha programado el reloj de la FPGA a 20MHz. Como el oscilador es de
100MHz, esto significa que hemos programado el divisor de frecuencias a un
valor de 5. Esto se hace utilizando la utilidad xssetclk, siempre que hayamos con-
figurado adecuadamente el jumper J22.
6.2.3. Reprogramación de la CPLD
Ha sido necesario reconfigurar la CPLD presente en la placa para permitir el
acceso por el puerto serie al procesador que implementaremos en la Virtex. Esto
es indispensable para nuestro sistema, ya que el sistema operativo que introduci-
remos en la placa de desarrollo mapeará su entrada y salida de consola a través
del puerto serie.
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 una
acción potencialmente peligrosa, ya que si se programaran los pines del JTAG de
la CPLD como pines de salida1, no podríamos volver a programarla, siendo la
única solución en ese caso el extraer el dispositivo de la placa y sustituirlo por
otro.
6.3. Xstools
El paquete XSTOOLs [X E01a] contiene las siguientes herramientas GUI y
sus alternativas de línea de comandos:
GXSTEST / XSTEST: Esta utilidad permite hacer un test a la placa para
comprobar que su funcionamiento es correcto.
1Realmente, los pines 63, 71, 73 y 78 se podrían programar como salidas, pero en ese caso es
indispensable que entren en un estado de alta impedancia cuando el pin DONE de la Virtex esté
a nivel bajo (de forma que la CPLD se pueda reprogramar al encender la placa, cuando la FPGA
aún no ha sido programada).
42
Placa de desarrollo XSV-800 6.3 Xstools
GXSSETCLK / XSSETCLK: Esta utilidad permite configurar la frecuencia
de reloj del oscilador programable de la placa.
GXSLOAD / XSLOAD: Esta utilidad permite programar la FPGA y la
CPLD y leer y escribir ficheros de datos en la RAM y la Flash de la pla-
ca.
GXSPORT / XSPORT: Esta utilidad permite enviar entradas lógicas a una
placa XS cambiando los pines de datos del puerto paralelo.
Las mismas herramientas sirven para toda la familia de placas XS, ya que su
arquitectura es similar, basada en un dispositivo programable de configuración
no volátil (la CPLD) en el cual se centralizan las acciones de programación y
configuración de los distintos dispositivos on-board.
El código fuente de las herramientas XSTOOLs fue liberado al dominio pú-
blico por Xess, lo que ha posibilitado que exista un port de estas herramientas
para Linux, y es este port el que hemos compilado y utilizado con éxito en este
proyecto.
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 de
tener múltiples tareas ejecutándose en el microprocesador, y esto es de gran im-
portancia para hacer codiseño HW/SW, ya que es de esperar que se tengan varias
tareas ejecutándose en software.
Para nuestro sistema, se ha decidido utilizar Snapgear Linux, una distribución
de Linux específica para sistemas integrados con soporte para la familia de proce-
sadores Leon.
7.2. Descripción
Linux es un sistema operativo muy conocido, maduro y con soporte, multita-
rea, con posibilidad de trabajo en tiempo real, y con muchas aplicaciones estables
que se pueden utilizar sin que sea necesario modificarlas. Con respecto a otros
sistemas operativos para sistemas integrados, Linux para sistemas integrados tie-
ne la ventaja de presentar la misma interfaz a las aplicaciones que su versión para
ordenadores personales, de forma que es posible utilizar, para el desarrollo de las
aplicaciones, una plataforma muy semejante, con un entorno de ejecución y he-
rramientas muy similares (las mismas), a las que luego estarán disponibles en el
sistema integrado. El desarrollo y la posterior depuración de las aplicaciones son
44
Snapgear Linux 7.2 Descripción
mucho más sencillos para el diseñador cuando el sistema operativo y el entorno
de 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 instalarel 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 que
no 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 útil
cuando se tiene una plataforma con muy poca memoria disponible (su huella se
puede reducir hasta los cientos o decenas de KBytes), pero ya que en nuestra pla-
taforma tenemos memoria suficiente como para implementar un sistema Linux
mínimo, sabiendo que Linux tiene mayor base de usuarios y una ingente cantidad
de colaboradores y usuarios y, considerando además la posibilidad de reutilizar
los 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 de
manejo de memoria (MMU), que se encarga de dar a cada proceso un espacio
de memoria protegida, y de proteger al kernel de los procesos. Además, la MMU
se 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 los
procesos una interfaz estándar para el acceso a memoria. Afortunadamente existen
versiones del núcleo de Linux que han sido adaptadas para su uso en procesadores
que carecen de MMU [DL02]. Snapgear Linux ofrece la posibilidad de ejecutar
kernels 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 puede
implementar, 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 incremento
del 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, por
lo que finalmente se ha configurado el sistema Linux con un kernel con soporte
para sistemas non-MMU. Concretamente, en la implementación aquí descrita se
ha 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 las
aplicaciones concretas que se compilarán en el sistema, de forma que se puede
ganar espacio eliminando las funcionalidades que no se necesiten. Snapgear Li-
nux permite añadir de forma sencilla aplicaciones específicas, que se compilarán
junto al resto del sistema. Ya que el entorno utilizado comprende lenguaje C, las
herramientas de desarrollo UNIX normales (gcc, make) y el API de un sistema
POSIX, 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 de
aplicaciones previamente desarrolladas sobre ordenadores personales.
7.3. Configuración
La versión concreta de snapgear que hemos utilizado es la versión p-17. Al
igual 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 de
Snapgear Linux ya que nuestra placa está bastante limitada en lo que a recursos
respecta. Ya que únicamente disponemos de 2MB de RAM, espacio que ha de
compartirse con la imagen RAM, y�Clinux necesita alrededor de 1MB de RAM
para poder ejecutar un sistema mínimo1, hemos reducido la imagen RAM todo lo
posible eliminando funcionalidades no necesarias. La ocupación en RAM de la
imagen de Linux obtenida finalmente ha sido de alrededor de 600KB, por lo que
queda 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 en
lectura (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’, debido
a que Linux no puede reservar la memoria necesaria para los procesos que se quieren ejecutar. En
estos casos no es raro observar que la memoria que requiere un proceso es menor que la memoria
libre total, pero aún así no se puede ejecutar el proceso. Esto se debe a que toda la memoria que se
asigne 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 aplicaciones
de 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 hemos
utilizado 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 para
su funcionamiento.
Para la conexión con Snapgear Linux, configuramos al programa minicom con
los 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 del
margen de la consola): ON
La figura 7.2 es una captura de pantalla del programa minicom, a través del
cual establecemos una comunicación serie con el sistema integrado. En la figura
se 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
Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear
Figura 7.1: Herramienta de configuración de Snapgear
48
Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear
Figura 7.2: Captura de pantalla del programa minicom
49
Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear
interactuará con el HW leyendo y escribiendo en los registros del bus AMBA que
pertenezcan a la parte hardware.
Los pasos que se han seguido para añadir la parte SW de la aplicación de
demostración descrita en el capítulo 9 han sido los siguientes:
Crear la carpeta <snapgear>/user/swpart, siendo <snapgear> el directorio
raíz de las fuentes de la distribución.
Escribir el código fuente del programa, dentro de user/swpart. En nuestro
caso, 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á tres
reglas que son invocadas automáticamente por los Makefiles generales de
Snapgear: ‘all’, que compila el programa y crea los binarios y ejecutables,
‘romfs’, que copia los binarios al directorio romfs (a partir del cual se