mProcesadores ESA

μProcesadores ESA.
Una visión de los μProcesadores en
aplicaciones espaciales.
Eduardo José Aguiar Bujalance
ÍNDICE
1
Índice
1. Introducción.
1.1. Los comienzos de la electrónica en el espacio. . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1. Las misiones Apollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. El caso europeo, los primeros microprocesadores de la ESA. . . . . . . . . . . . . . . . . . .
2. μArquitecturas.
2.1. ERC32. . . . .
2.2. LEON. . . . . .
2.2.1. LEON-1
2.2.2. LEON-2
2.2.3. LEON-3
2.2.4. LEON-4
2
2
2
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
6
6
7
9
11
3. Radiation Hardened Processors.
3.1. SEE . . . . . . . . . . . . . . .
3.2. TID . . . . . . . . . . . . . . .
3.3. Fault Tolerant . . . . . . . . . .
3.4. LEON2-FT . . . . . . . . . . .
3.5. LEON3-FT . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
12
12
13
13
LEON.
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
14
14
15
15
15
4. Herramientas de
4.1. ERC32CCS .
4.2. BCC . . . . .
4.3. TSIM . . . .
4.4. GRSIM . . .
4.5. LSVE . . . .
4.6. GRMON . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
desarrollo del
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Eduardo José Aguiar Bujalance
ERC32 y del
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
1
1. Introducción.
1.
2
Introducción.
El ser humano, desde los orígenes de su historia, ha sentido una especial fascinación por el universo que le
rodea, adoptando diversas posturas y desarrollando numerosas teorías para intentar conocer y comprender
los fenómenos relacionados con los cuerpos celestes y su propia naturaleza. De este modo el origen de
la ciencia que se ocupa de este tipo de estudios, la Astronomía (del griego αστ ρoυoµια), acompañó a la
evolución del hombre. Los prodigiosos avances de la física y la técnica en los siglos XIX y XX originaron un
interés especial por la exploración del universo provocando así el surgimiento de la carrera espacial, en la
que, principalmente, estadounidenses y soviéticos desarrollaron diversos programas dedicados al lanzamiento
de satélites, naves e incluso misiones tripuladas al espacio.
En 1962, en Europa, se crea la Organización Europea para la Investigación Espacial que, años más tarde,
daría lugar a la Agencia Espacial Europea (ESA en sus siglas inglesas). Esta nueva organización se dedicaba,
principalmente, a la exploración espacial para lo que creó toda una infraestructura de centros a lo largo de
los países miembros. Actualmente la ESA está formada por 17 naciones miembros además de varios países
colaboradores [1]. Otra agencia de considerable importancia en el sector espacial es la NASDA japonesa.
Tanto la NASA como la ESA y la NASDA tienen un amplio programa de investigaciones en la ciencia
espacial, abarcando desde el estudio del universo a la mejora de las comunicaciones y los servicios en la
Tierra o el desarrollo de experimentos de microgravedad y biología espacial. En cualquier caso, el desarrollo
de la investigación aeroespacial ha requerido de unos considerables avances en la electrónica y en otros
campos de la ingeniería auspiciados por los diversos programas de las diferentes agencias.
1.1.
Los comienzos de la electrónica en el espacio.
Aunque el primer satélite artificial que orbitó la tierra fue lanzado por la Unión Soviética el 4 de Octubre
de 1957 dentro del programa Sputnik y con el nombre de Sputnik 1 [2], se considera que el primer sistema
empotrado usado en tiempo real fue el Apollo Guidance Computer (AGC) [3] desarrollado en los laboratorios
del MIT por Charles Stark (2 de Octubre de 1901 - 25 de Julio de 1987) y Eldon C. Hall (1923) en los
comienzos de la década de los sesenta. El desarrollo de estos sistemas se produjo dentro del programa Apollo,
puesto en marcha por el gobierno de John F. Kennedy con la intención de mandar misiones tripuladas a la
luna.
Anteriormente, bajo del programa SCORE [4] ya se habían puesto en órbita numeros satélites con equipamiento para comunicaciones que había sido desarrollado a partir de la modificación de equipos comerciales.
Con el fin de realizar desarrollos válidos con altos requerimientos para las misiones aeroespaciales la NASA
creó el Electronic Research Centre (ERC) [5] en septiembre de 1964. Éste se localizó en las cercanías del MIT
y sirvió, no sólo para desarrollar numerosos productos para el programa Apollo, sino que también fue un
centro de entrenamiento para estudiantes interesados en hacer carrera en el sector aeroespacial. La mayoría
de los resultados obtenidos en este centro tuvieron carácter confidencial aunque hoy día conocemos gran
parte de ellos gracias a la desclasificación de documentos [6] y su posterior publicación en libros de historia
que pretenden acercar al público general a la NASA. El centro, rodeado de gran controversia política desde
su misma creación, fue cerrado en 1970 siendo repartidas sus funciones y proyectos entre diversos centros
de investigación dependientes de la NASA, universidades y otras agencias del gobierno.
1.1.1.
Las misiones Apollo
Charles Stark Draper fundó al final de los años 30 el Laboratorio de Instrumentación del MIT [7] con
el fin de adoctrinar a los estudiantes en el diseño de los instrumentos necesarios para medir con precisión
y estudiar el movimiento. Ya durante la Segunda Guerra Mundial el laboratorio adquirió una notable
importancia en el desarrollo de sistemas de navegación para el Departamento de Defensa, consiguiendo de
este modo numerosos contratos para el desarrollo de sistemas para misiles. Con la creación de la NASA, el
laboratorio continuó obteniendo contratos de colaboración siendo el AGC el fruto de los mismos.
El AGC se utilizó en todas las misiones a la luna (con excepción de la Apollo 8 que no tenía módulo
Lunar), incluyéndose dos procesadores de este tipo, uno en el módulo lunar y otro en el módulo de comando.
En ambos casos servía de dispositivo de guía y de navegación. Además, en cada misión, se incluía otros
Eduardo José Aguiar Bujalance
2
1.2
El caso europeo, los primeros microprocesadores de la ESA.
3
dos microprocesadores adicionales: un ordenador de vuelo construido por IBM (Launch Vehicle Digital
Computer) y un sistema de guía auxiliar construido por TRW.
Características del AGC
Se considera al AGC como uno de los primeros sistemas que usaron circuitos integrados, concretamente
y en su primera versión, se necesitaron de un total de 4100 circuitos, cada uno de ellos consistente en una
puerta NOR de tres entradas. Las puertas fueron construidas por Fairchild Semiconductor utilizando un
esquema basado en resistencias y transistores. El uso de este tipo de esquemas permitió evitar los problemas
que habían aparecido en otro diseño que estaba llevando a cabo Texas Instruments, el Minuteman II guidance
computer que utilizaba una mezcla de lógica basada en diodos y transistores y otra basada únicamente en
transistores.
La memoria del AGC se dividía en 2K palabras de RAM y 36K palabras de ROM, ambas con un ciclo
de 11.72 microsegundos y un ancho de palabra de 16 bits. El formato de palabra de la CPU era de 14 bits
de datos, un bit de overflow y un bit de signo y utilizaba una representación en complemento a uno.
El sistema se controlaba mediante un reloj de 2048 KHz que se dividía en dos a fin de generar un reloj de
cuatro fases. Además la señal volvía a dividirse por dos a fin de obtener una señal de 512 KHz denominada
MASTER FREQUENCY que se utilizaba para sincronizar con los sistemas externos.
En cuanto al juego de instrucciones, se diferenciaron dos bloques fundamentales: el de instrucciones
básicas, compuesto de un total de ocho instrucciones y otro de instrucciones adicionales compuesto por
otras tres instrucciones. Finalmente el AGC disponía de cuatro registros llamados “registros centrales” y
hasta trece registros adicionales.
1.2.
El caso europeo, los primeros microprocesadores de la ESA.
En sus orígenes, la Agencia Espacial Europea realizaba sus proyectos en colaboración con otras agencias
como en el caso del proyecto IUE (International Ultraviolet Explorer) [8] en el que la ESA, en colaboración
con la NASA y el gobierno británico, desarrolló un satélite-observatorio. Tras el éxito de las primeras
misiones, en 1986, la agencia puso en marcha su primer proyecto de exploración en solitario, la misión
Giotto [9], que pretendía aproximarse y estudiar el cometa Halley.
La ESA no se había prodigado especialmente en el desarrollo de nuevos paradigmas de computación,
de hecho, la mayoría de la tecnología utilizada en sus misiones ha sido comprada o desarrollada bajo
subcontratas. Sin embargo sí es cierto que a la hora de escoger una tecnología concreta, ésta es evaluada
concienzudamente y tiene que pasar unos estrictos controles de calidad y pruebas de fallos. Desde finales
de los años ochenta se decidió buscar una cierta identidad en los productos ESA y se optó por probar
con diferentes microprocesadores hasta llegar a una decisión sobre la arquitectura que se utilizaría en los
lanzadores y satélites en el futuro de la agencia.
Los primeros desarrollos se hicieron basados en un juego de instrucciones desarrollado a comienzos de
los ochenta por el Departamento de Defensa de Estados Unidos, la MIL-STD-1750A [10]. Ejemplos de los
primeros microprocesadores que implementaban este ISA y que fueron desarrollados para la ESA son el
MDC281 y el MA31750 [11]. Actualmente la empresa XGC continúa dando soporte para estos micros y
elaborando compiladores basados en GCC para los mismos.
Mientras los primeros desarrollos iban dando sus frutos, los ingenieros de la Agencia Espacial Europea
intentaban buscar una arquitectura base, suficientemente madura y con una perspectiva de futuro sólida
para construir sus microprocesadores. Entre las opciones se encontraban competidores tan potentes como
MIPS o AMD, sin embargo, la arquitectura de tipo RISC, SPARC, desarrollada por Sun Microsystems a
partir de los diseños de la Universidad de Berkeley, acabó siendo la seleccionada. El cambio suponia, entre
otros, el pasar de arquitecturas de 16 a 32 bits, además de una apuesta de futuro, dejando atrás unos
diseños rígidos y cerrados como eran los que provenían del departamento de defensa de Estados Unidos. A
la larga este cambio permitió la liberación de la descripción hardware dando acceso a una gran cantidad de
desarrolladores y creando una numerosa comunidad de investigadores.
Eduardo José Aguiar Bujalance
3
2. μArquitecturas.
4
Figura 1: Arquitectura del MA31750
2.
μArquitecturas.
Con la adopción de SPARC por parte de la ESA, surgió todo un nuevo protocolo de generación de
sistemas, tando software como hardware. En un comienzo los ingenieros de la Agencia se centraron en el
desarrollo de los nuevos microprocesadores, así como de todo el conjunto de herramientas de desarrollo y
verificación necesarios para poder trabajar con la nueva gama de procesadores. El primer modelo que vio la
luz y que, hoy día, sigue volando en los cohetes de la ESA, fue el ERC32, un diseño propietario que convivió
con los antiguos chips basados en 1750 y cuyo desarrollo fue dado por finalizado con la llegada de los LEON.
La arquitectura LEON, creada como sustituto de la ERC32 y cuyo soporte fue cedido por la ESA a
la empresa Gaisler Research cuando su fundador, Jiri Gaisler, abandonó la agencia, surge a partir de la
evolución de la arquitectura SPARC al pasar de su versión siete a la ocho. Los modelos VHDL de LEON
se distribuyen actualmente bajo licencia GNU GPL/LGPL y su versión actual es la tercera, aunque una
cuarta ha sido encargada a Gaisler Research y se encuentra en sus primeros estadios del desarrollo.
2.1.
ERC32.
El primer ERC32 [12] estaba formado por tres chips (una unidad de enteros, una unidad de coma flotante
y un controlador de memoria) que lograban operar a 10 MIPS con una tecnología de 0.8 micras [13]. Ésta
versión se incorporó en hasta diez misiones y, el ordenador de control de la estación espacial internacional
fue construido con uno de estos micros funcionando a 14MHz acompañado de un microprocesador INMOS
T400 para tareas de paralelización. La computadora fue diseñada para utilizar buses VME y, sobre ella, se
Eduardo José Aguiar Bujalance
4
2.1
ERC32.
5
ejecutaba el Sistema Operativo VxWorks en su versión 5.3. Como era de esperar el sistema era tolerante a
fallos.
Figura 2: Core del ERC32 con Buffers
Para trabajar con el ERC32 el European Space Research and Technology Centre (ESTEC) de la ESA,
desarrolló el “32-bit toolset”, un conjunto de herramientas para el desarrollo y la verificación de software
con especificaciones de hard real-time. Este software era escrito en Ada y la aplicación permitía realizar con
ella el proceso completo de diseño, desde el protipado hasta la verificación final.
En 1998 el ERC32 fue unificado en una única pastilla, el TSC695, fabricado con un proceso de 0.6
micras, que opera hasta 15 MIPS. Este microprocesador sigue siendo, hoy día, el procesador stándard en
todas las misiones de la ESA, además de haber sido usado por la NASA, China e Israel entre otros. La
versión TSC695F [14], fabricada por Atmel con un proceso de 0.5 micras tolerante a radiaciones incorporó
funciones de watchdog y soporte para On-Chip Debugger entre otras mejoras. El chip, conjuntamente con
una memoria y unos periféricos de aplicación específica, forman un dispositivo on-board completo. El resto
de funciones del sistema están proporcionadas por el core como se desprende de la arquitectura presentada
en la figura 3.
El objetivo fundamental del ERC32 era proporcionar un alto rendimiento para aplicaciones de tiempo
real, a partir de una complejidad circuital baja y con un consumo de potencia lo más bajo posible. El
hecho de que se optara por una arquitectura de tipo RISC hacía que se pudiera aproximar la ejecución
de instrucciones a una por ciclo. en el caso del SPARC7 en el que se basa el ERC32, el pipeline consta
de cuatro etapas: Fetch, Decode, Execute y Write. Otra de las características que merece la pena reseñar
de la arquitectura SPARC es el concepto de las ventanas de registros. Fundamentalmente éste consiste en
una visibilidad de registros cambiante según una ventana que varía al cambiar de modo o al realizar una
llamada a una función. En cualquier caso, al ejecutarse un programa éste tiene acceso a 32 registros, 8 de
ellos globales y 24 que pertenecen a la ventana actual.
La unidad de coma flotante (FPU) incorporada se basa en el estándar ANSI/IEEE-754 de 1985, estaba
diseñada especificamente para aplicaciones espaciales y militares con una alta fiabilidad e incluía soporte
Eduardo José Aguiar Bujalance
5
2.2
LEON.
6
para detección de errores y test. Al igual que la unidad de enteros, la FPU utiliza un pipeline de cuatro
etapas.
Figura 3: Diagrama de Bloques del TSC695F
2.2.
LEON.
Antes incluso de desarrollarse la versión TSC695 del ERC32, ya se había manifestado cierta necesidad
de un cambio de arquitectura en los microprocesadores de la ESA ante ciertos problemas detectados en
el ERC32. Las dificultades en la portabilidad, la alta complejidad del interfaz y las limitaciones de velocidad debidas al interfaz de memoria junto a la problemática que suponía el tener un diseño propietario
encabezaban la lista de argumentos en contra del que fuera el primer micro “made in ESA”.
Ante esta eventualidad surgió el proyecto LEON [15], encabezado por Jiri Gaisler, que buscaba desarrollar
un procesador resistente a radiaciones, modular, fácilmente portable, con interfaces estándar y que ejecutara
hasta 100 MIPS. Además, el nuevo diseño, escrito en VHDL, se licenciaría bajo GPL, lo que permitiría
integrarlo en un System-on-Chip (SoC). Como base del Leon se decidió dar el paso a la versión 8 de
SPARC, que está definida en un estándar IEEE, y se utilizó una filosofía Harvard. Además, se decidió
utilizar el sistema de buses AMBA para la conexión de módulos adicionales.
El camino hasta un LEON usable en un dispositivo espacial pasaba por un desarrollo previo en el que se
demostrara su funcionalidad implementando un mínimo de interfaces y funciones. A este primer prototipo
se le llamó LEON-1. Una vez éste fue verificado se comenzó el desarrollo de un procesador más completo,
con unidad de coma flotante y nuevos interfaces, estas fueron las versiones LEON-2 y LEON-3. Finalmente,
la ESA encargó a Gaisler Research (hoy integrada en el grupo AEROFLEX) el desarrollo de un LEON-4.
2.2.1.
LEON-1
La primera versión del LEON [16] vio la luz en el año 2000 y su prototipo fue fabricado con un proceso
de 0.35 micras alcanzando un rendimiento de 100 MIPS y con un consumo de 0.5 Watios. En el diseño se
incluían: un multiplicador y divisor por hardware, un controlador de interrupciones, dos relojes de 24-bits,
dos UARTs, watchdog, un puerto de entrada/salida de 16 bits y un controlador de memoria flexible. Al
licenciarse bajo GPL, se distribuyó libremente el modelo VHDL que podía ser sintetizado fácilmente con
cualquier herramienta de síntesis.
La unidad de enteros (IU) del LEON-1 implementaba el juego de instrucciones definido por el estándar
de SPARC V8 aunque su implementación era completamente novedosa y no se basaba en ningún diseño
previo. La implementación intentó centrarse en conseguir una alta portabilidad y una baja complejidad. Las
características principales de la unidad de enteros son las siguientes:
Pipeline de 5 etapas: Fetch, Decode, Execute, Memory, Write.
Eduardo José Aguiar Bujalance
6
2.2
LEON.
7
Arquitectura Hardvard.
Soporte para ventanas de 2 a 32 registros.
Multiplicador configurable.
Unidad MAC de 16x16 bits con acumulación de 40 bits.
Divisor binario.
Figura 4: Arquitectura del LEON-1
Esta primera versión del LEON no incorporaba una unidad de coma flotante pero sí se le implementó
una interfaz para conectarlo con una FPU Meiko.
2.2.2.
LEON-2
En el año 2002, la segunda versión del LEON, partió de la estructura del LEON-1 y le incorporó una serie
de mejoras y características adicionales de forma que se logró un chip funcional y preparado para misiones
espaciales. El núcleo fundamental, que es la unidad de enteros, se mantuvo igual que en el LEON-1. También
permanecieron en el diseño el multiplicador, el divisor y la unidad MAC además del interfaz para la FPU
Meiko. Las principales mejoras introducidas son las siguientes:
Cachés Multi-way con reemplazo aleatorio, LRU ó LRR.
Controlador de memoria para PROM y SRAM externa.
Controlador de 32-bits para SDRAM PC133.
Sistema de Buses on-chip AMBA-2.0, AHB y APB.
Sistema avanzado de Debugging on-chip.
Eduardo José Aguiar Bujalance
7
2.2
LEON.
8
Modo Power-down.
Figura 5: Arquitectura del LEON-2
El modelo VHDL distribuido contiene scripts para sintetizarlo con diferentes herramientas (Synopsis,
Quartus, ISE...). A continuación se muestran los resultados de diferentes sintetizados del modelo VHDL [17]
Tecnología
Atmel 0.18 CMOS std-cell
Atmel 0.25 CMOS std-cell
UMC 0.25 CMOS std-cell
Atmel 0.35 CMOS std-cell
Xilinx XC2V3000-6
Altera 20K200C-7
Actel AX1000-3
Área
35K puertas + RAM
35K puertas + RAM
35K puertas + RAM
2 mm2 + RAM
5000 LUT + block RAM
5700 LCELLs + EAB RAM
7600 cells + RAM
Timing
165 MHz (pre-layout)
140 MHz (pre-layout)
130 MHz (pre-layout)
65 MHz (pre-layout)
80 MHz (post-layout)
49 MHz (post-layout)
48 MHz (post-layout)
Cuadro 1: Resultados de la síntesis del LEON-2
El área especificada en la tabla comprende el procesador completo, con los periféricos on-chip y el
controlador de memoria. El área del core, es decir, la unidad de enteros y el controlador de cachés, ocupa
aproximadamente la mitad del área. En cuanto a las medidas de velocidad, se han obtenido considerando
el peor caso y un rango de temperaturas industrial.
Algunos ejemplos de implementaciones comerciales [18] en un SoC del LEON2-FT (Fault Tolerant) son
las desarrolladas por Alcatel o EADS Astrium. En el caso de Alcatel, su sección espacial en Italia, desarrolló
un SoC al que llamaron OMNIA. Astrium, por su parte, trabajó en la creación de un procesador de control al
que denominó MDPA (Multi-DSP/microProcessor Architecture) basado en un LEON2-FT con las siguientes
características:
Eduardo José Aguiar Bujalance
8
2.2
LEON.
9
Alto Rendimiento en el control de procesos. (70 MIPS y 4W).
Interfaz para naves espaciales mediante Milbus o SpaceWire.
Escalable a sistemas multiprocesador.
Unidad autónoma.
Figura 6: Arquitectura del MDPA
2.2.3.
LEON-3
Tras el éxito del LEON-2 como procesador incorporado a un SoC, la ESA decidió optimizar el diseño del
procesador para su inclusión en este tipo de plataformas, en cuestiones de trabajo de diseño. De este modo
nació la tercera versión del LEON [19], con una arquitectura basada en el juego de instrucciones SPARC v8
y con las extensiones de la v8e. Los puntos de partida para el diseño era la portabilidad del mismo, la independencia de la herramienta CAD utilizada, una funcionalidad amplia, un sistema de debug que permitiera
depurar tanto el hardware como el software y un microprocesador que soportara multiprocesamiento.
Con el fin de cumplir la primera especificación, se diseñó todo un sistema de wrappers que permitiera
“enganchar” con diferentes tecnologías. Además la especificación VHDL partió de elementos genéricos de
forma que las células específicas de la tecnología son instanciadas mediante declaraciones VHDL. El diseño
se hizo de forma modular con lo que añadir nuevos componentes y aprovechar los construidos para otros
dispositivos se convierte en una tarea muy sencilla. Por último, y al igual que en los casos anteriores, se dio
soporte tanto para ASIC como para FPGA y en la distribución del código se incluyen numerosos scripts
para las principales plataformas de desarrollo además de plantillas para las FPGA más comunes.
Finalmente, la arquitectura diseñada incorporó numerosas características que suponían un salto cualitativo importante respecto a su predecesora. En primer lugar se mantuvo la arquitectura de tipo Harvard
con ambas cachés incluyendo snooping y siendo completamente configurables. También se mantuvo el interfaz para el bus AMBA-2.0 AHB y el modo Power-down. Las principales novedades del LEON-3 frente al
LEON-2 son las siguientes:
Incorpora las extensiones de SPARC v8e
Eduardo José Aguiar Bujalance
9
2.2
LEON.
10
Utiliza un pipeline de siete etapas [20]: Fetch, Decode, Register Access, Execute, Memory, Exception,
Write.
Incorpora, de forma opcional, una unidad de coma flotante de alto rendimiento y compatible con el
estándar IEE-754.
Soporte para Multiprocesador.
Figura 7: Arquitectura del LEON-3
Uno de los primeros prototipos del LEON-3 fue fabricado con un proceso de 0.13 micras, ocupando el core
y las cachés 1.5 mm2. Con éstas dimensiones se facilita enormemente la incorporación de varios cores en un
tamaño de chip razonable. El soporte para multiprocesador del LEON-3 permite tanto configuraciones SMP
como AMP. Para la primera se recomienda la utilización de Linux 2.6 SMP, mientras que para la segunda
son más convenientes los S.O RTEMS o uCLinux. Además la utilización del sistema de buses AMBA con un
árbitro utilizando una filosofía Round-Robin, posilita el trabajo de varios procesadores en paralelo. Ejemplos
de implementaciones multinucleo [12] son las pruebas hechas en una FPGA XC2V3000 de Xilinx en la que
se incorporó un sistema de cuatro procesadores a 80MHz, o el procesador GINA desarrollado por la ESA y
basado en LEON3-FT.
Eduardo José Aguiar Bujalance
10
3. Radiation Hardened Processors.
11
Figura 8: Arquitectura de GINA.
En el apéndice A se incluye una comparativa de los diversos cores fabricados del LEON 2 y 3.
2.2.4.
LEON-4
En Diciembre de 2006, Gaisler Research recibió financiación para comenzar el desarrollo de la versión
4 del LEON [12] con propósitos aeroespaciales y comerciales. Aún hoy sólo se conocen las especificaciones
del diseño inicial aunque, en un principio, se había propuesto 2008 como el año del lanzamiento del nuevo
procesador. Hasta el momento se sabe que se mantendrá una arquitectura de 32 bits compatible con SPARC
V8, aunque se planea que el interface del bus AMBA sea compatible con 64 bits. La unidad de coma flotante
dispondrá de un pipeline diferente de la unidad de enteros y se la dotará de un controlador con instrucciones
FIFO. Asimismo se están implementando técnicas de clock gating con el fin de ahorrar consumo. Con todo
esto Gaisler anuncia una mejora del rendimiento en torno al 50 % respecto a su predecesor.
3.
Radiation Hardened Processors.
Cuando se diseña y fabrica un elemento hardware que será enviado al espacio, se deben tener en cuenta
numerosos factores que hacen que estos diseños sean muy particulares. Por ejemplo, según vamos subiendo
en altura y superando capas de la atmósfera, aparecen efectos debidos a las radiaciones [18] que pueden
provocar fallos e incluso la destrucción de nuestros dispositivos. En el caso de un satélite, los tipos de
radiación que tiene que soportar son los siguientes:
Radiación alfa.
Radiación Beta.
Radiación Gamma.
Radiación de Protones.
Radiación de Neutrones.
Radiación cósmica.
Eduardo José Aguiar Bujalance
11
3.1
SEE
12
Vientos solares.
Destellos solares.
Anillos de Van Allen
Los posibles daños debidos a las radiaciones se pueden separar en dos categorías: Los efectos de un único
evento (SEE) y los efectos debidos a una dosis completa de ionización (TID). El primer caso se debe al
impacto de una única partícula sobre el material, de forma que se deposita suficiente energía como para
causar algún efecto en el dispositivo. El segundo caso es el resultado de la acumulación de los efectos debido
a una larga exposición a las radiaciones.
Para garantizar la seguridad de las misiones, los microprocesadores desarrollados para aplicaciones espaciales, son reforzados para evitar los efectos de las radiaciones, son lo que se conocen como chips “Hard-Rad”.
Un ejemplo de las medidas de seguridad que incorporan este tipo de procesadores es el uso de transistores adicionales que requieren de una mayor cantidad de energía para conmutar, de forma que la energía
transmitida por una radiación sea insuficiente para variar el estado del transistor.
Actualmente existen diversos proyectos que estudian los efectos de la radiación en microprocesadores
de uso comercial y como solucionarlos con el fin de desarrollar computadoras más potentes para las misiones espaciales. Un ejemplo de estos programas es el Environmentally Adaptive Fault-Tolerant Computing
(EAFTC) [21] de la NASA, que se centra en cómo solventar los errores de tipo SEE. Otra teoría defiende la
necesidad de incorporar numerosos micros que realicen las mismas operaciones al mismo tiempo y, entre los
resultados proporcionados por todos ellos, elegir el correcto por “mayoría”. Ésto supone un gran desperdicio
de potencia de cálculo por lo que, el EAFTC, a partir de esta idea intenta optimizar el proceso analizando la
importancia del cálculo realizado. De este modo, si tuvieramos tres procesadores ante un cálculo importante
como el de una órbita a seguir, utilizaríamos los tres micros, mientras que si el cálculo a realizar es de
menor importancia como puede ser el cálculo de la masa de una roca en marte, se utiliza tan sólo uno de
los procesadores.
En cualquier caso, desde la NASA se ha advertido que el programa EAFTC en ningún caso podrá
sustituir a los microprocesadores Hard-Rad en las tareas vitales de las naves espaciales, pero sí pueden
servir de ayuda y aumentar la capacidad de cómputo. La primera prueba de éste sistema tendrá lugar en
2009 con la misión ST-8 que probará numerosas tecnologías espaciales experimentales, entre ellas el EAFTC,
para lo cuál rozará los anillos de radiación de Van Allen.
3.1.
SEE
En general existe una multitud de posibles fallos debido a un SEE, dependiendo del tipo de partícula que
haya incidido sobre el dispositivo o el lugar de incidencia. Sin embargo, distinguiremos los errores en una
clasificación de dos tipos: errores soft, y errores hard [22]. Los errores tipo soft son, normalmente, errores
que no destruyen el dispositivo sino que causan un fallo en principio inofensivo como puede ser un cambio de
un bit en un registro o la ejecución de forma incorrecta de una operación. Los errores tipo Hard, en cambio,
son potencialmente destructivos. En cualquier caso, un dispositivo puede no ser tolerante a determinados
tipos de fallos, independientemente de si es tipo soft o tipo hard.
3.2.
TID
Al igual que en el caso del SEE, los fallos debidos a la exposición continua a radiaciones puede tener
múltiples y muy variados efectos negativos sobre los dispositivos electrónicos. La causa principal de los TID
son las radiaciones solares. Una larga exposición a éste tipo de radiaciones suele causar aumentos en el
consumo de potencia, pérdida de funcionalidad de los dispositivos, pérdidas de sincronismo, etc.
3.3.
Fault Tolerant
Un dispositivo de aplicación espacial debe estar preparado para que, si una radiación le afecta y produce
un error, ser capaz de detectarlo evitando que se propague. Las técnicas llamadas “Fault Tolerant” son
aquellas que se incorporan para que, utilizando información adicional en el sistema, el microprocesador
Eduardo José Aguiar Bujalance
12
3.4
LEON2-FT
13
detecte una disfunción y la corrija. Esta redundancia sirve para verificar el correcto estado del sistema o, en
su caso, un error debido a cualquier discrepancia entre informaciones. A partir de una cantidad considerable
de información redundante, además de detectar un estado erroneo, el micro será capaz de reconstruir los
datos corruptos.
Los sistemas de redundancia espacial se basan, fundamentalmente, en la idea base del EAFTC para
cálculos importantes, es decir, la utilización de varios elementos iguales realizando la misma función. El
más típico de estos sistemas es la TMR (Triple Modular Redundancy) que consiste en triplicar la lógica de
forma que tenemos tres copias equivalentes que “votan” por la solución correcta, siendo esta la mayoritaria.
El nivel de granularidad dependerá de la frecuencia a la que sea necesaria verificar las señales.
3.4.
LEON2-FT
Un ejemplo de microprocesador tolerante a fallos es el desarrollado por Atmel para la ESA, el LEON2FT. Éste se fabricó con un proceso de 0.18 micras con tecnología CMOS y se comercializa con el nombre
de AT697. La primera versión de este componente, la AT697E, fue testeada por ATMEL y asegura su
fucionamiento para los siguientes casos:
TID de hasta un total de 60Krads.
Inmunidad de los latch por encima de 80 MeV/mg/cm2.
3.5.
LEON3-FT
El LEON3 [23] también tiene su versión tolerante a fallos, diseñada para aplicaciones espaciales con
funciones para detectar y corregir errores en todas las memorias del chip. Algunas caraterísticas de esta
versión son las que se enumeran a continuación:
Corrección en registro de hasta cuatro errores en palabras de 32 bits.
Corrección en caché de hasta cuatro errores por etiquetas o palabra de 3 bits.
Manejo de errores por software.
La detección y corrección de errores no supone un incremento en el tiempo de ejecución.
Sin embargo, la introducción de éstas características supone la pérdida de otras que sí aparecen en el LEON3
estándar pero que no son soportadas en la versión LEON3-FT como puede ser el algoritmo de reemplazo
LRR en las memorias caché.
4.
Herramientas de desarrollo del ERC32 y del LEON.
El desarrollo y mantenimiento de una arquitectura requiere de un respaldo en forma de herramientas que
faciliten al usuario final así como al desarrollador, la tarea de testear y verificar sus aplicaciones. En el caso
del LEON, Gaisler Research preparó todo un conjunto de herramientas para la compilación, el depurado y la
simulación de los programas desarrollados para el LEON. A éstas se le unen una amplia gama de alternativas
comerciales presentadas por varias empresas en busca de un sitio en un nicho de mercado copado por unos
pocos muy poderosos.
En primer lugar cabe destacar que los lenguajes de programación más utilizados para trabajar con el
ERC32 y el LEON son C y ADA. JAVA, por su parte, ha sido propuesto en numerosas ocasiones como
alternativa para la programación de sistemas empotrados en la ESA a pesar de las recomendaciones de la
propia licencia de SUN de no utilizar este lenguaje y su intérprete en aplicaciones industriales. En más de
diez años de pruebas con JAVA no se han logrado unos resultados satisfactorios ni una conclusión clara
acerca de la conveniencia (o no) de utilizar este lenguaje para programar en los microprocesadores ERC32
y LEON.
Eduardo José Aguiar Bujalance
13
4.1
4.1.
ERC32CCS
14
ERC32CCS
El ERC32 Cross Compiler System, es un conjunto de herramientas de GNU [24] que, utilizadas de forma
conjunta, proveen de un entorno de desarrollo para el procesador ERC32. Las aplicaciones incluidas son las
siguientes:
Compilador experimental de GNU para C y C++ (EGCS).
Compilador de GNAT para Ada95.
Herramientas proporcionadas por binutils de GNU (Linker, ensamblador, listado de símbolos, etc).
Librería de C para sistemas empotrados.
Simulador de instrucciones SPARC (SIS).
Depurador de GNU (GDB), con soporte para GNAT e integrado con SIS.
Interfaz gráfica para el depurado (Data Display Debugger)
RTEMS, sistema operativo en tiempo real
Mkprom, a partir de un programa compilado para el ERC32, crea la estructura de memoria, pila,
secuencia de boot etc.
4.2.
BCC
Bare-C Cross-Compiler es un compilador cruzado para LEON-2 y LEON-3 que incluye una amplia gama
de herramientas basadas en las de GNU [25]. Podría considerarse como el equivalente al ERC32CCS para la
plataforma LEON. Permite la compilación de aplicaciones de un solo hilo o multihilo e incluye las siguientes
herramientas:
Compilador cruzado de GNU para C y C++
Herramientas proporcionadas por binutils de GNU (Linker, ensamblador, listado de símbolos, etc).
Librería de C para sistemas empotrados.
Sistema Bare-C con soporte para interrupciones y tareas.
Generador de Boot.
Librería Pthreads
Depurador de GNU (GDB)
Interfaz gráfica para el depurado (Data Display Debugger)
Plugin para integración con Eclipse.
4.3.
TSIM
Es un simulador a nivel de instrucciones capaz de emular tanto ERC32 como sistemas basados en LEON.
La herramienta [26] comenzó siendo libre pero, con el tiempo, Gaisler decidió retirar las versiones antiguas
y comenzar a comercializar las nuevas. Como simulador proporciona una gran precisión y una emulación de
tiempo de ciclo dando unas prestaciones de hasta 45 MIPS en un PC relativamente moderno.
En modo ERC32 el TSIM emula los chips TSC691/2/3/5 de Atmel, incluyendo los dispositivos adicionales al core. La cantidad de memoria simulada puede ser configurada en tiempo de ejecución, aunque ésta
está limitada por la naturaleza de la propia arquitectura (de 256K a 32M de RAM y de 128K a 4M de
ROM).
Eduardo José Aguiar Bujalance
14
4.4
GRSIM
15
En modo LEON, TSIM emula la funcionalidad completa del microprocesador, incluyendo las memorias
caché, los periféricos On-chip y el controlador de memoria. Al igual que para ERC32, la cantidad de memoria
simulada puede ser configurada en tiempo de ejecución aunque ahora no existen límites arquitecturales para
ésta. Las cachés son completamente configurables y la latencia del multiplicador puede ser preprogramada.
Actualmente TSIM se distribuye para plataformas Linux, Solaris y Windows.
4.4.
GRSIM
GRSIM es un simulador de SoCs [27] basados en el sistema de buses AMBA y microprocesadores LEON2 y LEON-3. Entre otras características, tiene la capacidad de de emular sistemas multiprocesador y puede
funcionar con una conexión a GDB. Asimismo permite el acceso a los registros internos del LEON y a la
memoria además de permitir introducir y ejecutar programas en el micro. Comercialmente, es el heredero
de TSIM y, al igual que éste, es un software de pago.
4.5.
LSVE
El LEON Software Verification Environment desarrollado por Spacebel [18] es una de las alternativas
al TSIM y al GRSIM de Gaisler Research aunque principalmente como simulador del LEON2. Entre sus
características destacan:
Integra un depurador simbólico no intrusivo.
Mecanismo para breakpoints, watchpoints y trazas.
Visibilidad completa del hardware y del software.
Línea de comandos basada en TCL/TK.
El LSVE se distribuye de forma comercial tanto como un producto con interfaz de usuario como un producto
para integrar en otros entornos de simulación.
4.6.
GRMON
GRMON es un monitor para el depurador para los procesadores LEON [28]. Una vez volcado el sistema
a una FPGA o con un ASIC conectado al PC, GRMON nos proporciona un entorno gráfico en el que
podemos:
Ver los accesos tanto de lectura como de escritura a todos los registros y la memoria
Establecer breakpoints y watchpoints.
Conectarnos con GDB
Realizar profiling de las aplicaciones
Descargar y ejecutar aplicaciones en el microprocesador.
GRMON, al igual que TSIM es una herramienta propietaria desarrollada por Gaisler para plataformas
Linux, Solaris y Windows.
Eduardo José Aguiar Bujalance
15
4.6
GRMON
16
Apéndice A
Cuadro 2: Comparativa de Cores de LEON
1
FPGA based, FPGA manufacturer is ACTEL, IP cores provider is GAISLER Research, RTAX2000
are ITAR items
2
ESA Multi Project Wafer (MPW) for Atmel ATC18RHA
3
ESA Multi Project Wafer (MPW) for Atmel ATC18RHA
4
ESA Multi Project Wafer (MPW) for Atmel ATC18RHA
5
ESA Multi Project Wafer (MPW) for Atmel ATC18RHA
6
Commercialization still not announced
7
Prototype, but flying on PROBA2 mission
8
Only available as a mounted single or multiple board computer
9
Commercialization details still not announced
10
Commercialization details still not announced
Eduardo José Aguiar Bujalance
16
REFERENCIAS
17
Referencias
[1] http://www.esa.int/SPECIALS/About_ESA/SEMW16ARR1F_0.html.
[2] http://www.russianspaceweb.com/sputnik_design.html.
[3] http://en.wikipedia.org/wiki/Apollo_guidance_computer.
[4] http://www.globalsecurity.org/space/systems/score.htm.
[5] http://history.nasa.gov/erc.html.
[6] A report of the closing of The NASA Electronics Research Center. Mr Boyd C, Myers. Cambridge,
Massachusetts, 1970/10/01.
[7] Draper at 25. Cristhoper Morgan, Joseph O’Connor y David Hoag. Cambridge, Massachusets, 1998.
[8] http://sci.esa.int/science-e/www/area/index.cfm?fareaid=22.
[9] http://sci.esa.int/science-e/www/area/index.cfm?fareaid=15.
[10] Military Standar Sixteen-Bit Computer Instruction Set Architecture. USAF, 1980/07/02.
[11] http://www.dynexsemi.com/assets/SOS/Datasheets/DNX_MA31750M_N_Feb06_2.pdf.
[12] LEON SPARC Procesor The Past, present and Future. Jiri Gaisler, 2007.
[13] 32-Bit Microprocessor and Computer Development Programme: Final Report. Mikael Ramström, Jonás Höglund, Björn Enoksson y Ritva Svenningsson. Saab Ericsson Space AB, Göteborg, Suecia,
1997/05/27.
[14] TSF695F Sparc 32-bit Space Processor: User Manual. ATMEL, 2003/12.
[15] http://www.eetimes.com/story/OEG20000306S0096.
[16] The LEON Processor User’s Manual. Versión 2.3.5. Jiri Gaisler, Gaisler Research, 2001/07.
[17] http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=12&Itemid=52.
[18] Leon Development Environment Technical Note. EDISOFT, 2007/11/22.
[19] GRLIB IP Library User’s manual. Versión 1.0.19. Jiri Gaisler, Sandi Habinc, Edvin Catovic, 2008/09.
[20] GRLIB IP CORE User’s manual. Versión 1.0.19. Jiri Gaisler, Edvin Catovic, Marko Isomäki, Kristoffer
Glembo, Sandi Habinc, 2008/09.
[21] http://ciencia.nasa.gov/headlines/y2005/18nov_eaftc.htm.
[22] Single Event Effect Criticality Analysis. Kenneth A. LaBel. NASA headquarter. 1996/02/15.
[23] http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=194&Itemid=139.
[24] The ERC32 GNU Cross-Compiler System. Versión 2.0.1. Jiri Gaisler, 1999/03.
[25] BCC - Bare-C Cross-Compiler User’s Manual. Versión 1.0.29. Jiri Gaisler, 2007/02.
[26] TSIM Simulator User’s Manual. Versión 1.2.7. Gaisler Research, 2003/12.
[27] GRSIM User’s Manual. Version 1.1.23. John Alexandersson, Jiri Gaisler, 2007/11/12.
[28] GRMON User’s Manual. Versión 1.1.32, Gaisler Research, 2008/10.
Eduardo José Aguiar Bujalance
17