μProcesadores ESA. Una visión de los μProcesadores en ...nunez/clases-micros-para-com/...de...

μProcesadores ESA.

Una visión de los μProcesadores en aplicaciones espaciales.

Eduardo José Aguiar Bujalance

ÍNDICE 1

Índice1. Introducción. 2

1.1. Los comienzos de la electrónica en el espacio. . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.1. Las misiones Apollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. El caso europeo, los primeros microprocesadores de la ESA. . . . . . . . . . . . . . . . . . . 3

2. μArquitecturas. 42.1. ERC32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. LEON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1. LEON-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2. LEON-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3. LEON-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4. LEON-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. Radiation Hardened Processors. 113.1. SEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2. TID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3. Fault Tolerant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4. LEON2-FT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5. LEON3-FT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4. Herramientas de desarrollo del ERC32 y del LEON. 134.1. ERC32CCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2. BCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3. TSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.4. GRSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.5. LSVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.6. GRMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Eduardo José Aguiar Bujalance 1

1. Introducción. 2

1. 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 comprenderlos fenómenos relacionados con los cuerpos celestes y su propia naturaleza. De este modo el origen dela ciencia que se ocupa de este tipo de estudios, la Astronomía (del griego αστρoυoµια), acompañó a laevolución del hombre. Los prodigiosos avances de la física y la técnica en los siglos XIX y XX originaron uninterés especial por la exploración del universo provocando así el surgimiento de la carrera espacial, en laque, principalmente, estadounidenses y soviéticos desarrollaron diversos programas dedicados al lanzamientode 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 delos países miembros. Actualmente la ESA está formada por 17 naciones miembros además de varios paísescolaboradores [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 cienciaespacial, abarcando desde el estudio del universo a la mejora de las comunicaciones y los servicios en laTierra o el desarrollo de experimentos de microgravedad y biología espacial. En cualquier caso, el desarrollode la investigación aeroespacial ha requerido de unos considerables avances en la electrónica y en otroscampos 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 sistemaempotrado usado en tiempo real fue el Apollo Guidance Computer (AGC) [3] desarrollado en los laboratoriosdel MIT por Charles Stark (2 de Octubre de 1901 - 25 de Julio de 1987) y Eldon C. Hall (1923) en loscomienzos 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 laluna.

Anteriormente, bajo del programa SCORE [4] ya se habían puesto en órbita numeros satélites con equipa-miento 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 NASAcreó el Electronic Research Centre (ERC) [5] en septiembre de 1964. Éste se localizó en las cercanías del MITy sirvió, no sólo para desarrollar numerosos productos para el programa Apollo, sino que también fue uncentro de entrenamiento para estudiantes interesados en hacer carrera en el sector aeroespacial. La mayoríade los resultados obtenidos en este centro tuvieron carácter confidencial aunque hoy día conocemos granparte de ellos gracias a la desclasificación de documentos [6] y su posterior publicación en libros de historiaque pretenden acercar al público general a la NASA. El centro, rodeado de gran controversia política desdesu misma creación, fue cerrado en 1970 siendo repartidas sus funciones y proyectos entre diversos centrosde 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] conel fin de adoctrinar a los estudiantes en el diseño de los instrumentos necesarios para medir con precisióny estudiar el movimiento. Ya durante la Segunda Guerra Mundial el laboratorio adquirió una notableimportancia en el desarrollo de sistemas de navegación para el Departamento de Defensa, consiguiendo deeste modo numerosos contratos para el desarrollo de sistemas para misiles. Con la creación de la NASA, ellaboratorio 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óduloLunar), 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


1.2 El caso europeo, los primeros microprocesadores de la ESA. 3

dos microprocesadores adicionales: un ordenador de vuelo construido por IBM (Launch Vehicle DigitalComputer) 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, concretamentey en su primera versión, se necesitaron de un total de 4100 circuitos, cada uno de ellos consistente en unapuerta NOR de tres entradas. Las puertas fueron construidas por Fairchild Semiconductor utilizando unesquema basado en resistencias y transistores. El uso de este tipo de esquemas permitió evitar los problemasque habían aparecido en otro diseño que estaba llevando a cabo Texas Instruments, el Minuteman II guidancecomputer que utilizaba una mezcla de lógica basada en diodos y transistores y otra basada únicamente entransistores.

La memoria del AGC se dividía en 2K palabras de RAM y 36K palabras de ROM, ambas con un ciclode 11.72 microsegundos y un ancho de palabra de 16 bits. El formato de palabra de la CPU era de 14 bitsde 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 decuatro fases. Además la señal volvía a dividirse por dos a fin de obtener una señal de 512 KHz denominadaMASTER FREQUENCY que se utilizaba para sincronizar con los sistemas externos.

En cuanto al juego de instrucciones, se diferenciaron dos bloques fundamentales: el de instruccionesbásicas, compuesto de un total de ocho instrucciones y otro de instrucciones adicionales compuesto porotras tres instrucciones. Finalmente el AGC disponía de cuatro registros llamados “registros centrales” yhasta 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óncon la NASA y el gobierno británico, desarrolló un satélite-observatorio. Tras el éxito de las primerasmisiones, en 1986, la agencia puso en marcha su primer proyecto de exploración en solitario, la misiónGiotto [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 bajosubcontratas. Sin embargo sí es cierto que a la hora de escoger una tecnología concreta, ésta es evaluadaconcienzudamente y tiene que pasar unos estrictos controles de calidad y pruebas de fallos. Desde finalesde los años ochenta se decidió buscar una cierta identidad en los productos ESA y se optó por probarcon diferentes microprocesadores hasta llegar a una decisión sobre la arquitectura que se utilizaría en loslanzadores y satélites en el futuro de la agencia.

Los primeros desarrollos se hicieron basados en un juego de instrucciones desarrollado a comienzos delos ochenta por el Departamento de Defensa de Estados Unidos, la MIL-STD-1750A [10]. Ejemplos de losprimeros microprocesadores que implementaban este ISA y que fueron desarrollados para la ESA son elMDC281 y el MA31750 [11]. Actualmente la empresa XGC continúa dando soporte para estos micros yelaborando compiladores basados en GCC para los mismos.

Mientras los primeros desarrollos iban dando sus frutos, los ingenieros de la Agencia Espacial Europeaintentaban buscar una arquitectura base, suficientemente madura y con una perspectiva de futuro sólidapara construir sus microprocesadores. Entre las opciones se encontraban competidores tan potentes comoMIPS o AMD, sin embargo, la arquitectura de tipo RISC, SPARC, desarrollada por Sun Microsystems apartir de los diseños de la Universidad de Berkeley, acabó siendo la seleccionada. El cambio suponia, entreotros, el pasar de arquitecturas de 16 a 32 bits, además de una apuesta de futuro, dejando atrás unosdiseños rígidos y cerrados como eran los que provenían del departamento de defensa de Estados Unidos. Ala larga este cambio permitió la liberación de la descripción hardware dando acceso a una gran cantidad dedesarrolladores y creando una numerosa comunidad de investigadores.


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 eldesarrollo de los nuevos microprocesadores, así como de todo el conjunto de herramientas de desarrollo yverificación necesarios para poder trabajar con la nueva gama de procesadores. El primer modelo que vio laluz 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 ala empresa Gaisler Research cuando su fundador, Jiri Gaisler, abandonó la agencia, surge a partir de laevolución de la arquitectura SPARC al pasar de su versión siete a la ocho. Los modelos VHDL de LEONse distribuyen actualmente bajo licencia GNU GPL/LGPL y su versión actual es la tercera, aunque unacuarta 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]. Éstaversión se incorporó en hasta diez misiones y, el ordenador de control de la estación espacial internacionalfue construido con uno de estos micros funcionando a 14MHz acompañado de un microprocesador INMOST400 para tareas de paralelización. La computadora fue diseñada para utilizar buses VME y, sobre ella, se


2.1 ERC32. 5

ejecutaba el Sistema Operativo VxWorks en su versión 5.3. Como era de esperar el sistema era tolerante afallos.

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 softwarecon especificaciones de hard real-time. Este software era escrito en Ada y la aplicación permitía realizar conella 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.6micras, que opera hasta 15 MIPS. Este microprocesador sigue siendo, hoy día, el procesador stándard entodas las misiones de la ESA, además de haber sido usado por la NASA, China e Israel entre otros. Laversió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 conuna memoria y unos periféricos de aplicación específica, forman un dispositivo on-board completo. El restode funciones del sistema están proporcionadas por el core como se desprende de la arquitectura presentadaen la figura 3.

El objetivo fundamental del ERC32 era proporcionar un alto rendimiento para aplicaciones de tiemporeal, a partir de una complejidad circuital baja y con un consumo de potencia lo más bajo posible. Elhecho de que se optara por una arquitectura de tipo RISC hacía que se pudiera aproximar la ejecuciónde instrucciones a una por ciclo. en el caso del SPARC7 en el que se basa el ERC32, el pipeline constade cuatro etapas: Fetch, Decode, Execute y Write. Otra de las características que merece la pena reseñarde la arquitectura SPARC es el concepto de las ventanas de registros. Fundamentalmente éste consiste enuna visibilidad de registros cambiante según una ventana que varía al cambiar de modo o al realizar unallamada a una función. En cualquier caso, al ejecutarse un programa éste tiene acceso a 32 registros, 8 deellos 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, estabadiseñada especificamente para aplicaciones espaciales y militares con una alta fiabilidad e incluía soporte


2.2 LEON. 6

para detección de errores y test. Al igual que la unidad de enteros, la FPU utiliza un pipeline de cuatroetapas.

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 enel ERC32. Las dificultades en la portabilidad, la alta complejidad del interfaz y las limitaciones de velo-cidad debidas al interfaz de memoria junto a la problemática que suponía el tener un diseño propietarioencabezaban 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 desarrollarun procesador resistente a radiaciones, modular, fácilmente portable, con interfaces estándar y que ejecutarahasta 100 MIPS. Además, el nuevo diseño, escrito en VHDL, se licenciaría bajo GPL, lo que permitiríaintegrarlo en un System-on-Chip (SoC). Como base del Leon se decidió dar el paso a la versión 8 deSPARC, 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 sedemostrara su funcionalidad implementando un mínimo de interfaces y funciones. A este primer prototipose 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 procesode 0.35 micras alcanzando un rendimiento de 100 MIPS y con un consumo de 0.5 Watios. En el diseño seincluí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. Allicenciarse bajo GPL, se distribuyó libremente el modelo VHDL que podía ser sintetizado fácilmente concualquier herramienta de síntesis.

La unidad de enteros (IU) del LEON-1 implementaba el juego de instrucciones definido por el estándarde SPARC V8 aunque su implementación era completamente novedosa y no se basaba en ningún diseñoprevio. La implementación intentó centrarse en conseguir una alta portabilidad y una baja complejidad. Lascaracterísticas principales de la unidad de enteros son las siguientes:

Pipeline de 5 etapas: Fetch, Decode, Execute, Memory, Write.


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 seriede mejoras y características adicionales de forma que se logró un chip funcional y preparado para misionesespaciales. El núcleo fundamental, que es la unidad de enteros, se mantuvo igual que en el LEON-1. Tambiénpermanecieron en el diseño el multiplicador, el divisor y la unidad MAC además del interfaz para la FPUMeiko. 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.


2.2 LEON. 8

Modo Power-down.


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 Área TimingAtmel 0.18 CMOS std-cell 35K puertas + RAM 165 MHz (pre-layout)Atmel 0.25 CMOS std-cell 35K puertas + RAM 140 MHz (pre-layout)UMC 0.25 CMOS std-cell 35K puertas + RAM 130 MHz (pre-layout)Atmel 0.35 CMOS std-cell 2 mm2 + RAM 65 MHz (pre-layout)

Xilinx XC2V3000-6 5000 LUT + block RAM 80 MHz (post-layout)Altera 20K200C-7 5700 LCELLs + EAB RAM 49 MHz (post-layout)Actel AX1000-3 7600 cells + RAM 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 elcontrolador de memoria. El área del core, es decir, la unidad de enteros y el controlador de cachés, ocupaaproximadamente la mitad del área. En cuanto a las medidas de velocidad, se han obtenido considerandoel peor caso y un rango de temperaturas industrial.

Algunos ejemplos de implementaciones comerciales [18] en un SoC del LEON2-FT (Fault Tolerant) sonlas 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 alque denominó MDPA (Multi-DSP/microProcessor Architecture) basado en un LEON2-FT con las siguientescaracterísticas:


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 delprocesador para su inclusión en este tipo de plataformas, en cuestiones de trabajo de diseño. De este modonació la tercera versión del LEON [19], con una arquitectura basada en el juego de instrucciones SPARC v8y con las extensiones de la v8e. Los puntos de partida para el diseño era la portabilidad del mismo, la inde-pendencia de la herramienta CAD utilizada, una funcionalidad amplia, un sistema de debug que permitieradepurar 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 deforma que las células específicas de la tecnología son instanciadas mediante declaraciones VHDL. El diseñose hizo de forma modular con lo que añadir nuevos componentes y aprovechar los construidos para otrosdispositivos se convierte en una tarea muy sencilla. Por último, y al igual que en los casos anteriores, se diosoporte tanto para ASIC como para FPGA y en la distribución del código se incluyen numerosos scriptspara 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 cuali-tativo importante respecto a su predecesora. En primer lugar se mantuvo la arquitectura de tipo Harvardcon ambas cachés incluyendo snooping y siendo completamente configurables. También se mantuvo el in-terfaz para el bus AMBA-2.0 AHB y el modo Power-down. Las principales novedades del LEON-3 frente alLEON-2 son las siguientes:

Incorpora las extensiones de SPARC v8e


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 elestándar IEE-754.

Soporte para Multiprocesador.


Uno de los primeros prototipos del LEON-3 fue fabricado con un proceso de 0.13 micras, ocupando el corey las cachés 1.5 mm2. Con éstas dimensiones se facilita enormemente la incorporación de varios cores en untamaño de chip razonable. El soporte para multiprocesador del LEON-3 permite tanto configuraciones SMPcomo AMP. Para la primera se recomienda la utilización de Linux 2.6 SMP, mientras que para la segundason 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. Ejemplosde implementaciones multinucleo [12] son las pruebas hechas en una FPGA XC2V3000 de Xilinx en la quese incorporó un sistema de cuatro procesadores a 80MHz, o el procesador GINA desarrollado por la ESA ybasado en LEON3-FT.


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ón4 del LEON [12] con propósitos aeroespaciales y comerciales. Aún hoy sólo se conocen las especificacionesdel diseño inicial aunque, en un principio, se había propuesto 2008 como el año del lanzamiento del nuevoprocesador. Hasta el momento se sabe que se mantendrá una arquitectura de 32 bits compatible con SPARCV8, aunque se planea que el interface del bus AMBA sea compatible con 64 bits. La unidad de coma flotantedispondrá de un pipeline diferente de la unidad de enteros y se la dotará de un controlador con instruccionesFIFO. Asimismo se están implementando técnicas de clock gating con el fin de ahorrar consumo. Con todoesto 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 subiendoen altura y superando capas de la atmósfera, aparecen efectos debidos a las radiaciones [18] que puedenprovocar fallos e incluso la destrucción de nuestros dispositivos. En el caso de un satélite, los tipos deradiació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.


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 únicoevento (SEE) y los efectos debidos a una dosis completa de ionización (TID). El primer caso se debe alimpacto de una única partícula sobre el material, de forma que se deposita suficiente energía como paracausar algún efecto en el dispositivo. El segundo caso es el resultado de la acumulación de los efectos debidoa una larga exposición a las radiaciones.

Para garantizar la seguridad de las misiones, los microprocesadores desarrollados para aplicaciones espa-ciales, 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 transisto-res adicionales que requieren de una mayor cantidad de energía para conmutar, de forma que la energíatransmitida 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 microprocesadoresde uso comercial y como solucionarlos con el fin de desarrollar computadoras más potentes para las misio-nes 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 lanecesidad de incorporar numerosos micros que realicen las mismas operaciones al mismo tiempo y, entre losresultados proporcionados por todos ellos, elegir el correcto por “mayoría”. Ésto supone un gran desperdiciode potencia de cálculo por lo que, el EAFTC, a partir de esta idea intenta optimizar el proceso analizando laimportancia del cálculo realizado. De este modo, si tuvieramos tres procesadores ante un cálculo importantecomo el de una órbita a seguir, utilizaríamos los tres micros, mientras que si el cálculo a realizar es demenor importancia como puede ser el cálculo de la masa de una roca en marte, se utiliza tan sólo uno delos 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í puedenservir de ayuda y aumentar la capacidad de cómputo. La primera prueba de éste sistema tendrá lugar en2009 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. SEEEn 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 unaclasificación de dos tipos: errores soft, y errores hard [22]. Los errores tipo soft son, normalmente, erroresque no destruyen el dispositivo sino que causan un fallo en principio inofensivo como puede ser un cambio deun 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 determinadostipos de fallos, independientemente de si es tipo soft o tipo hard.

3.2. TIDAl 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 TIDson las radiaciones solares. Una larga exposición a éste tipo de radiaciones suele causar aumentos en elconsumo de potencia, pérdida de funcionalidad de los dispositivos, pérdidas de sincronismo, etc.

3.3. Fault TolerantUn 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” sonaquellas que se incorporan para que, utilizando información adicional en el sistema, el microprocesador


3.4 LEON2-FT 13

detecte una disfunción y la corrija. Esta redundancia sirve para verificar el correcto estado del sistema o, ensu caso, un error debido a cualquier discrepancia entre informaciones. A partir de una cantidad considerablede información redundante, además de detectar un estado erroneo, el micro será capaz de reconstruir losdatos corruptos.

Los sistemas de redundancia espacial se basan, fundamentalmente, en la idea base del EAFTC paracálculos importantes, es decir, la utilización de varios elementos iguales realizando la misma función. Elmás típico de estos sistemas es la TMR (Triple Modular Redundancy) que consiste en triplicar la lógica deforma 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-FTUn ejemplo de microprocesador tolerante a fallos es el desarrollado por Atmel para la ESA, el LEON2-

FT. Éste se fabricó con un proceso de 0.18 micras con tecnología CMOS y se comercializa con el nombrede AT697. La primera versión de este componente, la AT697E, fue testeada por ATMEL y asegura sufucionamiento 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-FTEl 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 estaversió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 LEON3estándar pero que no son soportadas en la versión LEON3-FT como puede ser el algoritmo de reemplazoLRR 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 casodel LEON, Gaisler Research preparó todo un conjunto de herramientas para la compilación, el depurado y lasimulación de los programas desarrollados para el LEON. A éstas se le unen una amplia gama de alternativascomerciales presentadas por varias empresas en busca de un sitio en un nicho de mercado copado por unospocos muy poderosos.

En primer lugar cabe destacar que los lenguajes de programación más utilizados para trabajar con elERC32 y el LEON son C y ADA. JAVA, por su parte, ha sido propuesto en numerosas ocasiones comoalternativa para la programación de sistemas empotrados en la ESA a pesar de las recomendaciones de lapropia licencia de SUN de no utilizar este lenguaje y su intérprete en aplicaciones industriales. En más dediez años de pruebas con JAVA no se han logrado unos resultados satisfactorios ni una conclusión claraacerca de la conveniencia (o no) de utilizar este lenguaje para programar en los microprocesadores ERC32y LEON.


4.1 ERC32CCS 14

4.1. ERC32CCSEl 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 lassiguientes:

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. BCCBare-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 laplataforma LEON. Permite la compilación de aplicaciones de un solo hilo o multihilo e incluye las siguientesherramientas:

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. TSIMEs 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 antiguasy comenzar a comercializar las nuevas. Como simulador proporciona una gran precisión y una emulación detiempo 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 adicio-nales al core. La cantidad de memoria simulada puede ser configurada en tiempo de ejecución, aunque éstaestá limitada por la naturaleza de la propia arquitectura (de 256K a 32M de RAM y de 128K a 4M deROM).


4.4 GRSIM 15

En modo LEON, TSIM emula la funcionalidad completa del microprocesador, incluyendo las memoriascaché, los periféricos On-chip y el controlador de memoria. Al igual que para ERC32, la cantidad de memoriasimulada 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. GRSIMGRSIM es un simulador de SoCs [27] basados en el sistema de buses AMBA y microprocesadores LEON-

2 y LEON-3. Entre otras características, tiene la capacidad de de emular sistemas multiprocesador y puedefuncionar con una conexión a GDB. Asimismo permite el acceso a los registros internos del LEON y a lamemoria además de permitir introducir y ejecutar programas en el micro. Comercialmente, es el herederode TSIM y, al igual que éste, es un software de pago.

4.5. LSVEEl 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 suscaracterí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 productopara integrar en otros entornos de simulación.

4.6. GRMONGRMON 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 quepodemos:

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 plataformasLinux, Solaris y Windows.


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, RTAX2000are ITAR items

2 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


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, Jo-ná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, KristofferGlembo, 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.


μProcesadores ESA. Una visión de los μProcesadores en ...nunez/clases-micros-para-com/...de...

Documents

Transcript of μProcesadores ESA. Una visión de los μProcesadores en ...nunez/clases-micros-para-com/...de...