μ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