Facultad de Matemática, Astronom´ıa y F´ısica

Facultad de Matemática, Astronomı́a y Fı́sica TRAFIC Un mecanismo no intrusivo de inyección de fallas en memoria de un System On a Chip Volarik, Néstor Mariano Director: Marques, Carlos 14 de Diciembre de 2012 Twenty years from now, you will be more disappointed by the things that you didn’t do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover. Mark Twain(1835-1910) i ii Agradecimientos En especial, quiero agradecer a mis padres, quienes realizaron mucho esfuerzo a lo largo de mi carrera con el fin de brindarme la posibilidad de estudiar. Su apoyo en cada momento de mi vida es invaluable. Este trabajo está dedicado a ellos. A mi novia Cecilia, quien me acompañó con mucho amor a lo largo de los últimos 3 años de la carrera. Al Ing. Carlos Marques por la dirección en este trabajo. Al Dr. Pablo Ferreyra y al Lic. Eduardo Sanchez por su apoyo, consejos, ideas y opiniones. A mis compañeros de trabajo que desinteresadamente me enseñaron y me aportaron su experiencia, principalmente al Ing. Lucas Gabutti y al Ing. Renzo Bechler. Al tribunal evaluador, compuesto por el Dr. Nicolás Wolovick, Dr. Pablo Ferreyra e Ing. Walter Zaninetti. A cada uno de los profesores que hacen que FaMAF sea una de las facultades más prestigiosas. iii iv Resumen En los últimos años, el avance en la tecnologı́a y arquitectura de los semiconductores han permitido desarrollar nuevos dispositivos programables (FPGA, ASIC, CPLD, entre otros) caracterizados por un mayor nivel de integración, incremento en la velocidad de procesamiento, menor consumo y la capacidad de implementar un sistema completo. Estos sistemas, denominados System On a Chip (SoC), integran la mayorı́a de los componentes de un sistema: procesador, memoria, controladores de periféricos, entre otros, en una sola pastilla. Por sus interesantes caracterı́sticas de (re)programación, flexibilidad y rendimiento, los SoC’s están siendo utilizados en campos donde la confiabilidad es un requisito fundamental, por ejemplo, en aviónica, medicina, espacio y automóviles. Debido a la complejidad, comprobar la confiabilidad de un SoC es un desafı́o. Una forma viable de evaluación es mediante mecanismos de inyección de fallas. El objetivo es generar fallas de manera controlada a distintas zonas de un sistema bajo ensayo y observar como reacciona. Este trabajo presenta un novedoso mecanismo de inyección de fallas no intrusivo denominado TRAFIC (TRansparent And non-intrusive Fault InjeCtoR), basado en la caracterı́stica de depuración OCD (On-Chip Debug) de los procesadores modernos. Como caso de estudio, se implementó el SoC basado en la biblioteca GRLIB y el procesador 32-bits LEON3, ambos de la empresa Aeroflex Gaisler (www. gaisler.com), en el kit de desarrollo XUPV5 de Xilinx con FPGA LX110T (http://www.xilinx.com/univ/xupv5-lx110t.htm). Clasificación: B.8.1 [PERFORMANCE AND RELIABILITY] Reliability, Testing, and Fault-Tolerance. Palabras claves: Sistemas embebidos, procesador LEON3, biblioteca GRLIB, inyección de fallas, sistemas tolerantes a fallos, confiabilidad. v vi Índice general Agradecimientos III Resumen V 1. Introducción 1.1. Motivación . . . . . . . . . . . . . . . . 1.2. Dispositivos Lógicos Programables . . . 1.3. Acerca de VHDL . . . . . . . . . . . . . 1.4. IP Cores . . . . . . . . . . . . . . . . . . 1.4.1. Softcore . . . . . . . . . . . . . . 1.5. Procesador LEON3 y biblioteca GRLIB 1.6. Inyector de fallas . . . . . . . . . . . . . 1.7. Objetivos . . . . . . . . . . . . . . . . . 1.8. Organización del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 5 7 7 7 8 8 9 9 2. Procesador LEON3 2.1. Sobre la arquitectura . . . . 2.1.1. Registros . . . . . . 2.1.2. Ventana de registros 2.1.3. Instrucciones . . . . 2.2. Programación en LEON3 . 2.2.1. Compilación . . . . 2.3. Simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 12 13 13 16 17 17 3. Biblioteca GRLIB 3.1. Plantillas de diseño . . . . 3.2. Configuración . . . . . . . 3.3. Bus AMBA . . . . . . . . 3.4. Sı́ntesis e implementación 3.5. GRMON . . . . . . . . . . 3.6. Bootloader . . . . . . . . 3.7. Sistemas Operativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 22 22 24 25 25 28 31 4. Inyección de fallas 4.1. Tolerancia a fallos y confiabilidad . . . . . . . . . . . . 4.2. Falla, error y defecto . . . . . . . . . . . . . . . . . . . 4.2.1. Tipos de fallas . . . . . . . . . . . . . . . . . . 4.3. Efectos de la radiación cósmica en la microelectrónica . . . . . . . . . . . . . . . . . . . . . . . . 33 33 34 34 35 . . . . . . . vii ÍNDICE GENERAL 1 4.3.1. Fuentes de radiación . . . . . . . . . . . . . . . . . . . . . 4.4. Mecanismos de inyección de fallas . . . . . . . . . . . . . . . . . . 4.5. Trabajos anteriores . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Diseño e implementación de TRAFIC 5.1. Debug Support Unit . . . . . . . . . . . 5.1.1. Operación . . . . . . . . . . . . . 5.2. Memoria . . . . . . . . . . . . . . . . . . 5.2.1. Implementación de AHBDPRAM 5.3. Diseño de TRAFIC . . . . . . . . . . . . 5.4. Receptor de fallas . . . . . . . . . . . . . 5.4.1. Tramas tipo fdframe . . . . . . . 5.4.2. Tramas tipo eotframe . . . . . . 5.5. Buffer . . . . . . . . . . . . . . . . . . . 5.6. Inyector de fallas . . . . . . . . . . . . . 5.7. Conexión de TRAFIC al SoC . . . . . . 5.7.1. Memoria . . . . . . . . . . . . . . 5.7.2. DSU . . . . . . . . . . . . . . . . 5.7.3. Reloj principal . . . . . . . . . . 5.8. Compilación . . . . . . . . . . . . . . . . 5.9. Cliente computadora host . . . . . . . . 5.9.1. TRAFIC Fault Transmitter . . . 5.9.2. Transmisión . . . . . . . . . . . . 5.9.3. Formato del fichero . . . . . . . . . . . . . . . . . en el . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 36 37 41 41 42 43 44 46 47 47 48 48 48 50 50 51 51 52 55 55 55 56 6. Conclusión 57 6.1. Primera etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2. Segunda etapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.3. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7. Bibliografı́a 61 2 ÍNDICE GENERAL Capı́tulo 1 Introducción En los últimos años, el avance en la tecnologı́a y arquitectura de los semiconductores, han permitido desarrollar nuevos dispositivos programables (FPGA, ASIC, CPLD, entre otros) caracterizados por un mayor nivel de integración, incremento en la velocidad de procesamiento, menor consumo y la capacidad de implementar un sistema completo [FIRESoPC][VHDL2004, Appx A]. Estos sistemas, denominados System On a Chip (SoC), integran la mayorı́a de los componentes de un sistema tı́pico: procesador, memoria, controladores de periféricos, entre otros, en una sola pastilla. Por ésta razón, los SoC’s son interesantes desde varios puntos de vista; Primero, dado que se basan en dispositivos estándar, su costo es significativamente menor en comparación a dispositivos ad-hoc. Segundo, siendo programables, son prácticamente adaptables a cualquier aplicación y permiten ser optimizados para un uso especı́fico. Tercero, siendo reprogramables, soportan actualizaciones y además, los defectos pueden ser reparados en cualquier etapa, incluso luego de haber sido distribuidos. Gracias a éstas caracterı́sticas, los SoC’s están siendo utilizados en campos donde la confiabilidad es un requisito fundamental. Por ejemplo, en aviónica, medicina, espacio y automóviles [FIRESoPC]. A medida que el nivel de integración aumenta, el nivel de tensión de operación disminuye y sumado a las altas velocidades que alcanzan los últimos dispositivos programables desarrollados, la sensibilidad a fuentes de ruidos aumenta considerablemente. Esto significa que la cantidad de energı́a necesaria de una partı́cula incidente para afectar la electrónica es muy baja [G-MAT2008]. Un estudio publicado en [SEUGL] demuestra que la radiación residual encontrada en la Tierra a nivel del mar, tiene la energı́a suficiente para alterar el valor de un bit de memoria, que puede llevar a un funcionamiento erróneo del sistema, con posibles resultados dramáticos. Estos incidentes, denominados Single Event Upset (SEU), tienen la caracterı́stica de alterar el estado lógico de un dispositivo programable sin dañarlo. Debido a su complejidad, comprobar la confiabilidad de un SoC es un desafı́o. Una forma viable de hacerlo, es mediante mecanismos de inyección de fallas. El objetivo es generar fallas de manera controlada en distintas zonas de un sistema bajo prueba, a veces denominados Device Under Testing (DUT), y observar como reacciona. 3 4 CAPÍTULO 1. INTRODUCCIÓN Distintos métodos han sido desarrollados hasta el momento, cada uno se diferencia del área de cobertura, por ejemplo: memoria, registros, código del programa, procesador y cuan intrusivo es implementarlo en el sistema. Prácticamente, la totalidad de los métodos estudiados son intrusivos (en distinto niveles), es decir, que para generar una falla, se requiere quitar, modificar o agregar código, (re)compilar el software, utilizar interrupciones o eventos disparados por distintas fuentes. Este trabajo presenta un novedoso mecanismo de inyección de fallas no intrusivo denominado TRAFIC (TRansparent And non-intrusive Fault InjeCtoR), basado en una caracterı́stica de depuración de los procesadores modernos, denominada On Chip Debug (OCD) [OCD2003], que permite controlar el progreso de la ejecución del sistema. Logrando ası́ un mecanismo no intrusivo -la inyección de falla no altera el flujo original de ejecución del programa-, independiente -el tamaño del software siendo ejecutado no incide en la inyección de fallas- y transparente -para el sistema, el mecanismo de inyección de fallas es invisible-. Como caso de estudio, se implementó TRAFIC en el SoC basado en la biblioteca GRLIB y el procesador 32-bits LEON3 [LEON3GRLIB], ambos productos de la empresa Aeroflex Gaisler (www.gaisler.com), en el kit de desarrollo XUPV5 de Xilinx con FPGA LX110T (http://www.xilinx.com/univ/ xupv5-lx110t.htm). 1.1. Motivación Los efectos de la radiación ionizante sobre dispositivos semiconductores se ponen de manifiesto por primera vez al detectarse anomalı́as en vuelo en la electrónica a bordo de las primeras misiones espaciales. El primer satélite artificial de los Estados Unidos, el Explorer I [ExplorerI], lanzado el 31 de Enero de 1958, portaba un contador Geiger1 de partı́culas ionizantes en un experimento propuesto por J. A. Van Allen. Luego del lanzamiento, el contador dejó de funcionar cuando el satélite alcanzó una determinada altura. Posteriormente, se supo que el contador habı́a saturado. Ese dı́a se descubrieron los Cinturones de Van Allen [Mongollon2008]. Unos años después del lanzamiento del satélite Explorer I, el 10 de Julio de 1962 se lanzó el satélite de telecomunicaciones americano Telstar [Telstar], diseñado y construido en los laboratorios Bell. Fue el satélite que abrió la era de las telecomunicaciones. En plena Guerra Frı́a, el dı́a anterior al lanzamiento del Telstar, el gobierno de los Estados Unidos realizó un experimento denominado Starfish Prime2 , haciendo detonar una bomba nuclear a gran altura. El aumento de la cantidad de electrones en el escudo magnético de la Tierra, provocaron un mal funcionamiento en la electrónica de a bordo del Telstar, degradando su funcionalidades gradualmente, hasta alcanzar la pérdida total del satélite el 21 de Febrero de 1963 [SSFAIL2005]. Fue el primer caso de pérdida de un satélite debido a los efectos de la radiación sobre la electrónica. Tal como lo demostró la suerte del satélite Telstar, la electrónica y más aún los circuitos VLSI (Very Large Scale Integration) son susceptibles de sufrir fallos 1 http://en.wikipedia.org/wiki/Geiger_counter 2 http://en.wikipedia.org/wiki/Starfish_Prime 1.2. DISPOSITIVOS LÓGICOS PROGRAMABLES 5 debidos a causas naturales, principalmente provocados por la radiación cósmica y la interferencia electromagnética. Estos fallos, denominados Single Event Effects (SEE), han preocupado a los diseñadores de aplicaciones de alta confiabilidad, tales como aplicaciones médicas, aeroespaciales, aviónica o automóviles [Portela2007]. A medida que la tecnologı́a avanza, los componentes electrónicos son cada vez de menor tamaño, trabajan a menor tensión, a mayor velocidad y son más complejos [SoCDesign]. Como consecuencia, la energı́a necesaria de una partı́cula incidente para causar un SEE es menor [G-MAT2008]. Los SEE más frecuentes, son aquellos que no dañan al circuito fı́sicamente, denominados Single Event Upset (SEU), pero si pueden inducir al sistema a un estado erróneo. La evaluación de la tolerancia a fallos es un problema ampliamente estudiado por la comunidad cientı́fica. Existen dos formas de evaluar un circuito electrónico: de manera analı́tica o de manera experimental [FITT97][FIRESoPC][SFIT2004]. Los métodos analı́ticos se aplican al modelar el sistema, pero debido a la complejidad de los circuitos electrónicos actuales, hacen que éstos métodos sean prácticamente no aplicables. Por otro lado, dentro de los métodos experimentales, la inyección de fallas es una solución ampliamente aceptada y utilizada. Esta técnica se basa en inyectar fallas en distintas regiones de un sistema prototipo DUT (Device Under Testing) y observar la reacción. La contribución exacta de los elementos de un circuito a la tasa de errores (Soft Error Rate) depende de cada diseño, pero se puede asumir que aproximadamente, el 90% se debe a los elementos de memoria [Portela2007][Mitr05], tal como lo muestra la Figura 1.1 Figura 1.1: Contribución a la tasa de errores de los distintos elementos que componen un circuito tı́pico. Por lo tanto, este trabajo está enfocado en los SEU’s que afectan a la memoria RAM de un sistema, inviertiendo el valor lógico de un bit de memoria. 1.2. Dispositivos Lógicos Programables Un dispositivo lógico programable o PLD (Programmable Logic Device), es un componente electrónico utilizado para construir circuitos digitales reconfigu- 6 CAPÍTULO 1. INTRODUCCIÓN rables. Es decir, a diferencia de una compuerta lógica, la cual tiene una función definida, un PLD tiene una función indefinida al momento de su fabricación. Antes de su utilización en un circuito digital, el PLD debe ser programado, o para ser más especı́fico, reconfigurado. Distintas tecnologı́as de fabricación dan lugar a distintos tipos de PLD, por ejemplo: ASIC (Application Specific Integrated Circuit), son dispositivos configurables por única vez, pero logran mayor velocidad que las FPGA’s y su costo económico es menor. FPGA (Field Programmable Gate Array) son dispositivos (re)programables lo que brinda mayor flexibilidad que una ASIC a cambio de una menor velocidad de reloj y mayor costo económico. CPLD (Complex Programmable Logic Device) son similares a las FPGA pero de menor tamaño lógico. Este trabajo utiliza una FPGA de la empresa Xilinx para la implementación del inyector de fallas junto al SoC. El modelo del kit de desarrollo es XUPV5LX110T (http://www.xilinx.com/univ/xupv5-lx110t.htm) y lo muestra la Figura 1.2. Una FPGA es un circuito integrado diseñado para ser configurado por un el cliente o diseñador luego de su fabricación. Generalmente, la configuración se especifı́ca utilizando un lenguaje de descripción de hardware (Hardware Description Language, HDL), como por ejemplo VHDL o Verilog [VHDL2004]. Figura 1.2: Kit de desarrollo XUPV5 de Xilinx con FPGA LX110T. 1.3. ACERCA DE VHDL 1.3. 7 Acerca de VHDL VHDL es un lenguaje de descripción de hardware (Hardware Description Language). Describe el comportamiento de un circuito electrónico o sistema que luego puede ser implementado en un PLD. VHDL significa VHSIC Hardware Description Language y a su vez, VHSIC es una abreviación de Very High Speed Integrated Circuits, una iniciativa fundada por el Departamento de Defensa de los Estados Unidos (US DoD) en 1980, que luego llevó a la creación de VHDL. La primera versión de VHDL es del año 1987 que luego fue actualizada en el año 1993. VHDL fue el primer lenguaje de descripción de hardware en ser estandarizado por el Institute of Electrical and Electronics Engineers a través del estándar IEEE 1076 y posteriormente se agregó el estándar IEEE 1164 para introducir lógica multi-valores [VHDL2004]. Fue diseñado para la sı́ntesis y simulación de circuitos digitales. Es completamente simulable, aunque existen sentencias no sintetizables. Una vez que el código está escrito, puede ser sintetizado e implementado en un dispositivo programable. Es un lenguaje estándar, independiente de la tecnologı́a de implementación subyacente y es por lo tanto, reusable y portable. A diferencia de la programación de software donde la instrucciones se ejecutan secuencialmente, los instrucciones de VHDL se ejecutan inherentemente en forma paralela. Un buen libro para consultar sobre diseño de circuitos digitales utilizando VHDL, es [VHDL2004]. 1.4. IP Cores Un IP core (Intellectual Property Core) es un bloque de código reutilizable que es usado en los diseños de circuitos digitales sintetizable en PLD. Es consecuencia de la tendencia de reutilizar componentes previamente implementados. Idealmente, un IP core deberı́a ser portable, es decir, capaz de ser implementado en un PLD independientemente de la tecnologı́a subyacente. Algunos ejemplos de IP cores son: Universal Asynchronous Receiver Transmitter (UART), controlador Ethernet, Peripheral Component Interconnect (PCI), Central Processing Unit (CPU). 1.4.1. Softcore Un caso particular de IP core son aquellos que describen un procesador. Un procesador Softcore, es un procesador que puede ser completamente implementado en un dispositivo de lógica programable. La lista de softcores desarrollados hasta el momento es extensa, para nombrar algunos ejemplos, se encuentran: LEON2, LEON3, MicroBlaze, Nios, OpenSparc T1, Intel 8086. Una detallada lista de las caracterı́sticas de los softcores más populares de la actualidad se encuentra en [SoftCores]. Este trabajo utiliza como caso de estudio el procesador LEON3 [LEONGRLIB] de Gaisler (www.gaisler.com). 8 1.5. CAPÍTULO 1. INTRODUCCIÓN Procesador LEON3 y biblioteca GRLIB El procesador LEON3 es un modelo VHDL sintetizable de un procesador 32-bits basado en la arquitectura SPARC V8 [Sparc92]. El softcore LEON3 es altamente configurable y particularmente apropiado para el diseño de un System On a Chip. La configurabilidad del procesador permite a los diseñadores optimizar el procesador para mayor rendimiento, menor consumo, mayor respuesta de entrada/salida y tamaño de implementación. El procesador cuenta con una interfaz de bus AMBA AHB 2.0 [AMBA99] para la conexión de distintos módulos IP cores incluı́dos en la biblioteca GRLIB (Gaisler Research IP Library) [GRLIB2012]. La Fig. 1.3 muestra un sistema tı́pico basado en el procesador LEON3 y la biblioteca GRLIB. Figura 1.3: Ejemplo de un SoC basado en GRLIB y en el procesador LEON3. 1.6. Inyector de fallas Este trabajo presenta TRAFIC (TRansparent And non-intrusive Fault InjeCtoR ), un inyector de fallas de tipo SEU en memoria RAM. Utiliza un mecanismo basado en las caracterı́sticas de depuración de los procesadores modernos, logrando ası́ un mecanismo no intrusivo, transparente e independiente. Esto es, no altera el flujo de ejecución del sistema al momento de inyección de una falla, a diferencias de otros métodos (no intrusivo). Además, al desconectar el inyector de fallas, el sistema sigue funcionando de manera usual (transparente). La complejidad del software corriendo en el sistema no influye en el inyector de fallas (independiente). 1.7. OBJETIVOS 1.7. 9 Objetivos Este trabajo tiene dos objetivos principales: Primer objetivo Cada vez son más las aplicaciones utilizan un sistema embebido en sus diseños como una opción para dar solución a sus requerimientos. En la actualidad, el procesador LEON3 es activamente utilizado en aplicaciones que van, desde reproductores MP3 [LEONGRLIB] hasta la computadora a bordo de los dos exploradores ExoMars que viajarán a Marte según lo planificado en 2016 y 2018 [ExoMars]. Por lo tanto, adquirir las aptitudes para el diseño e implementación del System On Chip basado en la biblioteca GRLIB y el procesador LEON3, abre el panorama a nuevas posibilidades de aplicación al egresado en la etapa laboral. Segundo objetivo En el mercado, los componentes electrónicos, en particular, los dispositivos lógicos programables, se comercializan con distintos grados de calificación. Según la aplicación donde van a ser utilizados, los componentes se califican (a grandes rasgos) en: comerciales, militares y espaciales. El precio entre los distintos tipos de componentes aumenta considerablemente. Basta con pedir cotizaciones a grandes empresas tales como Actel, ahora llamada Microsemi (http://www.actel.com/) ó a Xilinx (http://www.xilinx. com/) para tener una noción de la pendiente de la curva de los precios entre categorı́as. En algunos casos, sucede, que los componentes entre las distintas categorı́as, fueron construido de la misma forma y materia prima. La diferencia (y el precio) recae sobre la etapa de calificación, los componentes militares y espaciales son ensayados estrictamente. Contar con un mecanismo de inyección de fallas, permite realizar nuestra propia califación de un sistema, y también probar la efectividad de algunos métodos de tolerancia a fallos (por ejemplo, memoria redundada, TMR3 ), disminuyendo el costo económico. 1.8. Organización del trabajo Este trabajo está dividido en 2 partes. La primera parte, presenta al SoC utilizado como caso de prueba. El Cap. 2 presenta al procesador LEON3 de manera detallada a nivel arquitectura y a nivel programación, junto a las herramientas de compilación, depuración y simulación. El Cap. 3 introduce la biblioteca GRLIB, una colección de IP cores para conectar al bus AMBA del sistema. También presenta GRMON, una herramienta de depuración en tiempo real en hardware que es utilizada por TRAFIC. En la segunda parte, en el Cap. 4, se define confiabilidad y sistemas tolerantes a fallos. Se presenta el concepto de mecanismo de inyección de fallas, como una 3 Triple Modular redundancy. Redundancy: http://en.wikipedia.org/wiki/Triple_modular_ 10 CAPÍTULO 1. INTRODUCCIÓN herramienta para medir la confiabilidad de un sistema, junto a ejemplos de trabajos desarrollados. En el Cap. 5 se diseña e implementa TRAFIC. Finalmente, en el Cap. 6 se presenta la conclusión obtenida al finalizar éste trabajo y en el Cap. 7, la bibliografı́a. Capı́tulo 2 Procesador LEON3 LEON3 es un procesador 32-bits sintetizable desarrollado por la empresa Aeroflex Gaisler (www.gaisler.com) y distribuido junto a la biblioteca GRLIB [GRLIB2012], una colección de IP cores diseñada especialmente para el desarrollo de un system on a chip (SoC). Posee un conjunto reducido de instrucciones y está basado en la arquitectura SPARC v8 [Sparc92]. Es altamente configurable, permitiendo optimizar el procesador para aplicaciones especı́ficas. La Figura 2.1 muestra los bloques que conforman al procesador LEON3, algunos de éstos son opcionales. El procesador LEON3, la biblioteca GRLIB, el toolchain y demás herramientas, se distribuyen con licencia GNU GPL, permitiendo acceder de manera gratuita a una versión académica de cada producto y también a su código fuente. Algunas caracterı́sticas principales del procesador son: Pipeline1 de 7 etapas. Cache configurable. Cache de datos y cache de instrucciones separados (modelo Harvard). Instrucciones triádicas. Unidades hardware dedicado para operaciones de multiplicación, división y MAC. 2 Unidad de Punto Flotante IEEE-754 (Opcional). 2.1. Sobre la arquitectura SPARC (de Scalable Processor ARChitecture) es una arquitectura RISC bigendian diseñada por Sun Microsystem en el año 1985. Presenta algunas caracterı́sticas propias e innovadoras, tales como la ventana de registros, que permite 1 http://en.wikipedia.org/wiki/Classic_RISC_pipeline 2 La operación MAC se define como: a := a + b x c. 11 12 CAPÍTULO 2. PROCESADOR LEON3 Figura 2.1: Procesador LEON3. Bloques constituyentes del procesador. desarrollar compiladores más sencillos y reducir el tiempo entre cambios de contexto. LEON3 está basado en la versión 8 de la arquitectura SPARC. Esta Sección describe brevemente la arquitectura, la especificación original se encuentra en [Sparc92]. 2.1.1. Registros Un procesador SPARC incluye 2 tipos de registros: registros de propósitos generales y registros de control y estado. Los registros de propósitos generales de la Integer Unit (IU) son llamados registros tipo r para diferenciarlos de los registros de la FPU, llamados de tipo f. Todos los registros son de 32 bits. Registros de control y estado Entre los registros de control y estado se encuentran: Processor State Register (PSR): Controla la operación del procesador y mantiene información de estado. El PSR habilita/deshabilita el coprocesador (si está presente), la FPU (si está presente), indica si está en modo usuario o en modo supervisor, establece el nivel de interrupciones a la que el procesador atenderá, indica el estado de la ALU luego de una operación aritmética (cero, negativo, desbordamiento, acarreo), entre otras funciones. 2.1. SOBRE LA ARQUITECTURA 13 Trap Base Register (TBR): Indica la dirección de memoria donde se transfiere el control luego de que ocurra una trap. Multiply/Divide Register (Y): Contiene los 32 bits más significativos del resultado de una operación de multiplicación o división de doble precisión. Program Counters (PC, nPC): El registro PC indica la dirección de memoria de la instrucción siendo ejecutada actualmente. La dirección de la próxima instrucción a ejecutar (asumiendo que no ocurre una trap) está contenida en el registro nPC. Registros de propósitos generales Un procesador SPARC v8 puede implementar desde 40 hasta 520 registros de tipo r. Están organizados en 8 registros globales y en conjuntos de 16 registros cada uno. Dependiendo de la implementación, la cantidad de conjuntos mı́nima es 2 y la cantidad máxima es 32, dando un mı́nimo de 40 registros (2 conjuntos de 16 más 8 globales) y un máximo de 520 (32 conjuntos de 16 cada uno más 8 globales). Los registros de tipo r están dispuestos en forma de cola circular y son accedidos mediante una ventana de registros. 2.1.2. Ventana de registros En un instante dado, los registros de tipo r a los que puede acceder una instrucción (además de los registros globales) son los que están contenidos en la ventana actual. Una ventana está compuesta por 24 registros: 8 registros denominados ins: i0, .. , i7, 8 registros locals: l0, .. ,l7 y 8 registros outs: o0, .. ,o7. Los registros ins y locals son propios de la ventana actual, en cambio, los registros outs son una referencia a los registros ins de la ventana adyacente. La Fig. 2.2 muestra la superposición de registros. El número de la ventana actual se indica en el campo CWP (bits [5..0] del registro PSR). El campo CWP se incrementa en la ejecución de una instrucción RESTORE ó RETT y decrementa con la instrucción SAVE (Fig. 2.3). 2.1.3. Instrucciones El conjunto reducido de instrucciones que define SPARC v8 puede agruparse en 6 categorı́as básicas: Carga y almacenamiento. Aritméticas, lógicas y desplazamiento. Transferencia de control. Escritura y lectura de los registros de control. Instrucciones de la unidad de punto flotante. Instrucciones de coprocesador. 14 CAPÍTULO 2. PROCESADOR LEON3 Figura 2.2: Superposición de ventanas. Se puede apreciar la referencia de los registros ins de la ventana CWP - 1 a través de los registros outs de la ventana CWP. Las instrucciones de carga y almacenamiento son las únicas que acceden a memoria. Utilizan 2 registros de tipo r o un registro más una constante para calcular la dirección de acceso. Soportan lecturas/escrituras de longitud de un byte, halfword, word y double word (8, 16, 32 y 64 bits resp.). Los datos deben estar alineados en memoria de acuerdo a su longitud. Un acceso desalineado genera una trap mem_address_not_aligned. SPARC es big-endian, es decir, la dirección a la que apunta un dato, es la dirección de su byte más significativo, incrementar la dirección, significa disminuir la significancia de la unidad siendo accedida (Fig. 2.4). Las instrucciones aritméticas, lógicas y desplazamiento son triádicas (a excepción de SETHI). El formato es el siguiente: instr op1 op2 res, donde res es el resultado de la operación ejecutada por instr como función de op1 y op2. Las instrucciones de transferencia de control (CTI, control transfer instructions) incluyen llamadas a subrutinas, saltos relativos al contador de programa, saltos registro-indirecto y traps condicional. 2.1. SOBRE LA ARQUITECTURA 15 Figura 2.3: Ventana de registros. La imagen muestra un sistema con 8 ventanas. La instrucción SAVE decrementa el valor de CWP, mientras que la instrucciones RESTORE y RETT lo incrementa. Figura extraı́da de [Sparc92]. Dentro de las instrucciones CTI están las denominadas DCTI (delayed CTI), donde la instrucción siguiente a una DCTI se ejecuta antes de que la transferencia de control se lleve a cabo. Ejemplo de ejecución de código real con DCTI. El código corresponde a la aplicación Hello World! y se utiliza TSIM (Sección 2.3): tsim> dis 400011ec 400011f0 400011f4 400011f8 400011fc 40001200 4000001f 90100019 82100008 84006001 c227bfe8 03100015 call mov mov add st sethi 0x40001268 %i1, %o0 %o0, %g1 %g1, 1, %g2 %g1, [%fp - 0x18] %hi(0x40005400), %g1 La primera columna corresponde a la dirección de memoria, la segunda columna al contenido, la tercera a la instrucción y parámetros. 16 CAPÍTULO 2. PROCESADOR LEON3 Figura 2.4: Arquitectura big-endian. (Gráfico Wikipedia: http://en. wikipedia.org/wiki/Endianness). El orden de ejecución de las 2 primeras lı́neas es el siguiente: PC: 400011ec nPC:400011f0 PC: 400011f0 nPC:40001268 Como podemos observar, luego de la ejecución de la instrucción call 0x40001268, la próxima instrucción a ejecutar no es la ubicada en la dirección 0x40001268, sino, antes de que la transferencia de control se lleve a cabo, se ejecuta la instrucción siguiente a la llamada call y luego recién el valor 0x40001268 se escribe en el PC. La transferencia de control se toman con el retardo de una instrucción debido a la cantidad de etapas del pipeline. Las instrucciones de la categorı́a escritura y lectura de los registros de control pueden alterar el estado visible del procesador accediendo a los registros de control y estado. Dependiendo de la implementación, el procesador puede añadir una FPU y un coprocesador. Si está presente la FPU, se accede mediante las instrucciones definidas por SPARC conforme a ANSI/IEEE estándar 754/1985. Las instrucciones de coprocesador no son definidas por SPARC y son dependientes de la implementación. 2.2. Programación en LEON3 Gaisler proporciona todas las herramientas necesarias para el desarrollo de aplicaciones en LEON3. Incluye el compilador, depurador, simulador, entre otros. El conjunto de éstas herramientas conforman el toolchain del procesador. 2.3. SIMULACIÓN 2.2.1. 17 Compilación Para la compilación de aplicaciones escritas en C y C++ para LEON3 se utiliza BCC Bare-C Cross-Compiler, un compilador de plataforma cruzada3 basado en GNU GCC, provisto por Gaisler (http://www.gaisler.com/anonftp/ bcc/bin/) y distribuido junto al toolchain del LEON3. Por ejemplo, el código del tı́pico programa Hello World! se compila para una plataforma LEON3 de la siguiente forma: $ sparc-elf-gcc -o hello_world hello_world.c Donde hello_world.c es: #include <stdio.h> int main(){ printf("Hello World!\n"); return 0; } Las opciones más importante, a nuestro criterio, soportadas por BCC son: -g: Habilita soporte para depuración con GDB. -msoft-float: Emula una unidad FPU para sistemas que no la implementen. -mv8: Genera instrucciones mul/div. El procesador debe implementar el hardware necesario. -O2, -O3: Optimización de código en cuanto a rendimiento y tamaño. El manual de BCC se encuentra en [BCC2011]. 2.3. Simulación El ejecutable hello_world generado arriba, puede ejecutarse en TSIM [TSIM2011], una máquina virtual basada en LEON3 y obtenida también desde el sitio de Gaisler (http://gaisler.com/index.php/downloads/simulators). Para correr el ejecutable hello_world en TSIM, se inicia desde una consola: $ tsim-leon3.exe This TSIM evaluation version will expire January 1, 2013 3 Un compilador de plataforma cruzada ó cross compiler, es un compilador que se ejecuta sobre una arquitectura de tipo A y genera ejecutables para una arquitectura de tipo B. Más información en http://en.wikipedia.org/wiki/Cross_compiler 18 CAPÍTULO 2. PROCESADOR LEON3 TSIM/LEON3 SPARC simulator, version 2.0.21 (evaluation version) Copyright (C) 2001, Gaisler Research - all rights reserved. This software may only be used with a valid license. For latest updates, go to http://www.gaisler.com/ Comments or bug-reports to [email protected] serial port A on stdin/stdout allocated 4096 K RAM memory, in 1 bank(s) allocated 32 M SDRAM memory, in 1 bank allocated 2048 K ROM memory icache: 1 * 4 kbytes, 16 bytes/line (4 kbytes total) dcache: 1 * 4 kbytes, 16 bytes/line (4 kbytes total) tsim> Con el comando load se carga en memoria el programa hello_world: tsim> load hello_world section: .text, addr: 0x40000000, size 21728 bytes section: .data, addr: 0x400054e0, size 2912 bytes read 162 symbols Y finalmente, con el comando run se ejecuta: tsim> run starting at 0x40000000 Hello World Program exited normally. TSIM soporta, entre otras, las siguientes funciones: Setear breakpoints con el comando break [dirección o subrutina]: tsim> break main breakpoint 1 at 0x400011a4: tsim> run starting at 0x40000000 breakpoint 1 main main Examinar los registros internos con el comando reg: tsim> reg 2.3. SIMULACIÓN 0: 1: 2: 3: 4: 5: 6: 7: INS 00000000 400054CC 00000000 00000000 00000000 00000000 403FFE00 40001064 psr: F34010E6 pc: 400011a4 npc: 400011a8 19 LOCALS 40006000 400054F8 00000000 00000000 00000000 00000000 00000000 00000000 OUTS 00000000 00000000 00000000 00000000 00000000 00000000 403FFDA0 400054BC wim: 00000002 03100015 90106090 GLOBALS 00000000 FFFFFFFF 00000000 FFFFFFF8 40004400 40006014 400046AC 00000000 tbr: 40000000 y: 00000000 sethi %hi(0x40005400), %g1 or %g1, 0x90, %o0 Desensamblar código con dis [dirección] [cantidad], donde el primer parámetro indica la dirección y el segundo la cantidad de lı́neas a mostrar (parámetro opcional): tsim> dis 0x400011a4 400011a4 400011a8 400011ac 400011b0 400011b4 400011b8 400011bc 400011c0 400011c4 400011c8 400011cc 400011d0 400011d4 400011d8 400011dc 400011e0 03100015 90106090 40000028 01000000 82102000 b0100001 81e80000 81c3e008 01000000 92100008 94102000 90102000 96102000 8213c000 40000048 9e104000 sethi or call nop mov mov restore retl nop mov mov mov mov or call or %hi(0x40005400), %g1 %g1, 0x90, %o0 0x4000124c 0, %g1 %g1, %i0 %o0, %o1 0, %o2 0, %o0 0, %o3 %o7, %g1 0x400012fc %g1, %o7 Examinar la memoria con mem [dirección]: tsim> mem 0x40000000 40000000 40000010 40000020 40000030 88100000 a1480000 91d02000 91d02000 09100011 a7500000 01000000 01000000 81c123b4 108011e1 01000000 01000000 01000000 ac102001 01000000 01000000 ..........#..... .H...P........ . .. ............. .. ............. 20 CAPÍTULO 2. PROCESADOR LEON3 Capı́tulo 3 Biblioteca GRLIB El procesador LEON3 se entrega junto a la biblioteca GRLIB, una colección de IP cores que pueden añadirse al sistema a través del bus AMBA, incluyendo una amplia variedad de módulos que permiten dar soporte a la mayorı́a de las aplicaciones. Algunos de los módulos que contiene son: controlador SVGA, controlador USB, PS/2, interfaz 1553, controlador ATA, timers, Ethernet, PCI, SPI, I2C. El diseño del sistema, como ası́ también el procesador y cada componente, son altamente configurables. Para la implementación rápida en la mayorı́a de los kits de desarrollo, la biblioteca GRLIB incluye plantillas de diseño (template designs). Este Cap. presenta primero el concepto de plantillas de diseño. Luego, presenta una herramienta gráfica para la configuración del sistema, y finalmente, el proceso de sı́ntesis e implementación y la depuración en hardware del sistema, utilizando GRMON. Figura 3.1: Biblioteca GRLIB. Ejemplo de un SoC basado en GRLIB. 21 22 CAPÍTULO 3. BIBLIOTECA GRLIB 3.1. Plantillas de diseño La implementación de un circuito digital en un dispositivo lógico programable requiere de parámetros especı́ficos del hardware, tales como: encapsulado del PLD, velocidad, asignación de señales del circuito a pines del PLD, entre otros. Para agilizar y facilitar la implementación del sistema, la biblioteca GRLIB incluye plantillas de diseño, dentro del directorio grlib-gpl-1.1.0-b4113/designs/, que contienen todos los archivos especı́ficos para la implementación del sistema en la mayorı́a de los kits de desarrollos comerciales. En éste trabajo se utiliza el kit de desarrollo XUPV5-LX110T de Xilinx también conocida como Xilinx ML509. Por lo tanto, todos los comandos en éste Capı́tulo se ejecutan dentro de la plantilla de diseño: grlib-gpl-1.1.0-b4113/designs/leon3-xilinx-ml509. 3.2. Configuración El procesador LEON3 y la biblioteca GRLIB son altamente configurables. La biblioteca incluye una aplicación gráfica (Fig. 3.2) para simplificar el proceso de configuración. Se ejecuta con el comando make xconfig: /grlib-gpl-1.1.0-b4113/designs/leon3-xilinx-ml509/$ make xconfig Figura 3.2: Interfaz gráfica para la configuración del procesador LEON3 y la biblioteca GRLIB. Algunas de las opciones de configuración son: Processor Number of processor: Cantidad de procesadores en el sistema. El procesador LEON3 puede ser utilizado en sistemas multiprocesadores con configuración SMP (Synchronous Multiprocessing) o AMP (Asymmetric Multiprocessing). Hasta 16 procesadores pueden ser implementado en un sistema. 3.2. CONFIGURACIÓN 23 Integer Unit SPARC register windows: Longitud de la cola circular de conjuntos de registros de tipo r (Valores: [2..32]). SPARC V8 MUL/DIV instructions: El hardware implementa las instrucciones de multiplicación y división, incrementando el rendimiento en código que ejecutan operaciones aritméticas. El código debe ser compilado con el flag -mv8. Branch prediction: Dependiendo de la aplicación, habilitando branch prediction se pueden obtener incrementos de rendimiento de hasta un 20 %. El propósito del branch prediction es mejorar el flujo en el pipeline, prediciendo que rama tomar en una bifurcación if-then-else o en un ciclo, antes de ejecutar el condicional. Single-vector trapping: Habilitando esta opción, todas las traps transfieren el control a la dirección de la trap 0. No se requiere más una trap table. El tratamiento de una trap la realiza el sistema operativo leyendo el tipo de la trap tt del registro PSR (Sección: 2.1.1). Ahorra recursos disponibles de FPGA a cambio de incremento de overhead cuando se genera una trap. Floating-Point Unit Enable FPU: Añade una unidad FPU al procesador. Cache System Enable instruction cache: Habilitar cache de instrucciones. Associativity (sets): Establece el número de entradas posibles en cache para el almacenamiento de un valor de memoria, es decir, si el valor de asociatividad es N, un valor en la memoria principal, tiene N lugares posibles en cache donde almacenarse. Cuando N = 1, se denomina direct-mapped (Fig. 3.3). Replacement algorithm: Define el algoritmo de reemplazo de datos en cache1 . Soporta: random, direct, LRU y LRR. MMU Enable MMU: Implementar el procesador con o sin MMU. 1 Más información en http://en.wikipedia.org/wiki/Cache_algorithms 24 CAPÍTULO 3. BIBLIOTECA GRLIB Figura 3.3: Polı́tica de ubicación de datos en cache. (Gráfico Wikipedia: http://en.wikipedia.org/wiki/CPU_cache). Peripherals Memory controller: Habilitar y configurar el controlador de memoria. El controlador puede acceder a ROM, I/O, SRAM y SDRAM. On-chip RAM/ROM: Añadir memorias on-chip RAM y ROM al sistema. Ethernet: Habilitar y configurar el controlador Gaisler Research 10/100/1000 Mbit Ethernet MAC. UART, timer, I2C, I/O port and interrupt controller: Añadir y configurar éstos elementos. 3.3. Bus AMBA La biblioteca GRLIB está diseñada centrada en un bus principal, los módulos están conectado a un bus común on-chip. El bus elegido por GRLIB es el AMBA2.0 AHB / APB [AMBA99] debido a su amplio uso en procesadores ARM y porque está bien documentado y puede ser usado libremente sin restricciones de licencia [GRLIB2012]. La especificación AMBA (Advanced Microcontroller Bus Architecture) define un estándar de comunicaciones on-chip para el diseño de microcontroladores embebidos de alto performance. La especificación AMBA define 3 buses: Advanced High-performance Bus (AHB). Advanced System Bus (ASB). Advanced Peripheral Bus (APB). Advanced High-performance Bus (AHB) El bus AMBA AHB está diseñado para módulos de alta performance y frecuencia de reloj. 3.4. SÍNTESIS E IMPLEMENTACIÓN 25 Soporta la conexión eficiente de procesadores, memorias on-chip y periféricos de alta velocidad. En un bus AHB pueden distinguirse dos tipos de dispositivos: maestros y esclavos. Un dispositivo maestro AHB es capaz de iniciar una operación de lectura y escritura, proveyendo una dirección e información de control. Solamente un maestro puede estar activo en un instante dado. Un dispositivo esclavo AHB responde a operaciones de lectura o escritura dentro de un espacio o dirección especificado. Advanced System Bus (ASB) El bus AMBA ASB es una alternativa al bus AHB, también de alta performance pero de menor caracterı́sticas. No es utilizado por la biblioteca GRLIB. Advanced Peripheral Bus (APB) El bus AMBA APB está diseñado para la conexión de periféricos de bajo consumo y de baja velocidad. Posee una interfaz de conexión menos compleja. 3.4. Sı́ntesis e implementación Sı́ntesis es el proceso que transforma el código VHDL del SoC a un bitstream a nivel de compuertas lógicas y flip-flops entendido por la FPGA. Se inicia con el comando: /grlib-gpl-1.1.0-b4113/designs/leon3-xilinx-ml509/$ make ise Este comando utiliza el sintetizador Xilinx XST, pero pueden usarse otras herramientas disponibles, tales como synplify (ejecutar $ make help para más detalles). El proceso puede tomar varios minutos y termina generando un archivo leon3mp.bit, que es descargado en la placa durante el proceso de implementación. La implementación del archivo leon3mp.bit en el kit de desarrollo, es sencilla y rápida, pero es dependiente del hardware del kit. En el proyecto se utilizó la herramienta iMPACT de Xilinx. Una vez que el LEON3 ha sido implementado en la placa de desarrollo, puede utilizarse GRMON [GRMON2011] para verificar el funcionamiento del sistema. 3.5. GRMON GRMON [GRMON2011] es una aplicación que corre en la computadora host y se conecta con el SoC implementado en el kit, mediante el puerto JTAG u otra interfaz (UART, USB, PCI, Ethernet). Se comunica con el módulo Debug Support Unit (DSU) conectado al bus AMBA AHB [GRLIBIP2012, Chp. 27]. Al iniciar GRMON, el procesador entra en modo depuración. En este modo, se detiene la ejecución de instrucciones (pero no el reloj) y el procesador es controlado mediante el DSU y GRMON, permitiendo acceder a los registros del procesador y de cada componente del sistema, examinar la memoria, cargar 26 CAPÍTULO 3. BIBLIOTECA GRLIB aplicaciones en memoria RAM y ejecutarlas, escribir la memoria ROM, colocar breakpoints entre otras funciones. Al correr una aplicación, el procesador retorna a modo normal reanudando la ejecución de instrucciones desde donde se detuvo. GRMON se inicia desde una consola: $ grmon-eval.exe -freq 80 -xilusb -u GRMON LEON debug monitor v1.1.52 evaluation version Copyright (C) 2004-2011 Aeroflex Gaisler - all rights reserved. For latest updates, go to http://www.gaisler.com/ Comments or bug-reports to [email protected] This evaluation version will expire on 20/6/2013 Try to open libusb filter driver Xilinx cable: Cable type/rev : 0x3 JTAG chain: xc5vlx110t xccace xc95144xl xcf32p xcf32p Device ID: : 0x509 GRLIB build version: 4113 initialising ................... SRAM waitstates: 2 Component LEON3 SPARC V8 Processor AHB Debug UART AHB Debug JTAG TAP SVGA Controller GR Ethernet MAC DDR2 Controller AHB/APB Bridge LEON3 Debug Support Unit LEON2 Memory Controller System ACE I/F Controller Generic APB UART Multi-processor Interrupt Ctrl Modular Timer Unit PS/2 interface PS/2 interface General purpose I/O port AMBA Wrapper for OC I2C-master AMBA Wrapper for OC I2C-master AHB status register Vendor Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research European Space Agency Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Gaisler Research Use command ’info sys’ to print a detailed report of attached cores grlib> 3.5. GRMON 27 Los parámetros de entradas son los siguientes: -freq: Establece la frecuencia del sistema, anulando la frecuencia detectada. El valor establecido se encuentra en MHz. -xilusb: Indica que la interfaz de comunicación será USB. -u: loopback on: Por defecto, la entrada y salida estándar de las aplicaciones que corren sobre el LEON3, está direccionada al puerto UART del kit de desarrollo. Con la opción -u, se redirecciona la entrada y salida estándar al teclado y a la pantalla respectivamente. Para correr la aplicación Hello World!, compilado en apartados anteriores, debe cargarse en memoria primero con el comando load: grlib> load hello_world section: .text at 0x40000000, size 21728 bytes section: .data at 0x400054e0, size 2912 bytes total size: 24640 bytes (916.8 kbit/s) read 162 symbols entry point: 0x40000000 Y con el comando run se inicia la ejecución: grlib> run Hello World Program exited normally. Soporta básicamente, los mismo comandos que TSIM. Por ejemplo, en la siguiente ejecución, se setea un breakpoint en main, se inicia la ejecución, se visualiza el estado de los registros, y de la memoria: grlib> break main grlib> run CPU 0 Breakpoint 1 grlib> reg 0: 1: 2: 3: 4: 5: 6: 7: INS 00000000 400054CC 00000000 00000000 00000000 00000000 4FFFFF70 40001064 psr: F34000E6 main (0x400011a4) LOCALS 40006000 400054F8 00000000 00000000 00000000 00000000 00000000 00000000 OUTS 00000000 00000000 00000000 00000000 00000000 00000000 4FFFFF10 400054BC wim: 00000002 GLOBALS 00000000 FFFFFFFF 00000000 FFFFFFF8 40004400 40006014 400046AC 00000000 tbr: 40000000 y: 00000000 28 CAPÍTULO 3. BIBLIOTECA GRLIB pc: 400011a4 npc: 400011a8 sethi %hi(0x40005400), %g1 or %g1, 0x90, %o0 grlib> mem 0x400011a4 400011A4 400011B4 400011C4 400011D4 03100015 82102000 01000000 96102000 90106090 b0100001 92100008 8213c000 40000028 81e80000 94102000 40000048 01000000 81c3e008 90102000 9e104000 ......‘.@..(.... .. ............. .......... ... . .. [email protected]..@. grlib> cont Hello World Program exited normally. grlib> 3.6. Bootloader En la Sección anterior, la aplicación Hello World! fue cargada directamente en la memoria RAM del kit de desarrollo, utilizando GRMON. Con el comando run, la ejecución comenzó directamente desde la dirección de memoria 0x40000000 (dirección de comienzo de la memoria RAM). Cuando el procesador arranca, lo hace a partir de la dirección 0x0, por lo que, si reiniciamos el procesador no volveremos a tener un Hello World!, además que no estarı́a más en memoria. Para crear un sistema autónomo, es decir, que cada vez que el procesador arranque, comience la ejecución de una aplicación necesitamos un bootloader. MKPROM [MKPROM2010] es una herramienta provista por Gaisler, para crear bootloaders de programa compilados con BCC. Las imágenes creadas con MKPROM son escrita en memoria ROM a partir de la dirección 0x0 y cuando el sistema es iniciado, se realizan los siguientes tareas: Se inicializan todos los registros de la IU y FPU (si está presente). El controlador de memoria, UART y timers son iniciados de acuerdo a opciones especı́ficas. La aplicación se descomprime en RAM. Finalmente, se inicia la ejecución de la aplicación. MKPROM2 también se obtiene desde el sitio de Gaisler (http://gaisler. com/index.php/downloads/debug-tools?task=view&id=190). Una imagen de ROM del Hello World! compilado secciones anteriores, para un sistema tı́pico se genera de la siguiente forma: $ mkprom2.exe -v -rmw -ramsize 1024 hello_world 3.6. BOOTLOADER 29 El archivo generado, por defecto llamado prom.out también puede simularse en TSIM: $ tsim-leon3.exe prom.out This TSIM evaluation version will expire January 1, 2013 TSIM/LEON3 SPARC simulator, version 2.0.21 (evaluation version) Copyright (C) 2001, Gaisler Research - all rights reserved. This software may only be used with a valid license. For latest updates, go to http://www.gaisler.com/ Comments or bug-reports to [email protected] serial port A on stdin/stdout allocated 4096 K RAM memory, in 1 bank(s) allocated 32 M SDRAM memory, in 1 bank allocated 2048 K ROM memory icache: 1 * 4 kbytes, 16 bytes/line (4 kbytes total) dcache: 1 * 4 kbytes, 16 bytes/line (4 kbytes total) section: .text, addr: 0x0, size 18432 bytes read 136 symbols tsim> Se inicia la ejecución con el comando run tsim> run MkProm2 boot loader v2.0 Copyright Gaisler Research - all rights reserved system clock baud rate prom sram : : : : 50.0 MHz 19171 baud 512 K, (2/2) ws (r/w) 1024 K, 1 bank(s), 0/0 ws (r/w) decompressing .text to 0x40000000 decompressing .data to 0x400054e0 starting hello_world Hello World Program exited normally. Utilizando GRMON, se puede escribir la imagen prom.out en memoria ROM del kit de desarrollo, para que la aplicación sea ejecutada cada vez que el sistema es iniciado, prescindiendo de GRMON y creando un sistema autónomo. 30 CAPÍTULO 3. BIBLIOTECA GRLIB La generación de la imagen para la placa XUPV5-LX110T ML-509 necesita parámetros de configuración especı́ficos dependiente del hardware: $ mkprom2.exe hello_world -freq 80 -baud 38400 -ddrram 256 -nosram -ddrfreq 190 -ddrcol 1024 -romws 15 -romwidth 64 -msoft-float Para escribir la memoria ROM, se inicia GRMON: $ grmon-eval.exe -xilusb -freq 80 -u Se desbloquea la escritura a la memoria Flash (memoria PROM) y se borra todo el contenido: grlib> flash unlock all grlib> flash erase all Erase in progress Block @ 0x00000000 : code Block @ 0x00020000 : code Block @ 0x00040000 : code ... Block @ 0x01fe8000 : code Block @ 0x01ff0000 : code Block @ 0x01ff8000 : code Erase complete = 0x80 = 0x80 = 0x80 OK OK OK = 0x80 = 0x80 = 0x80 OK OK OK Se carga la imagen de ROM y se verifica que esté correcto: grlib> flash load prom.out section: .text at 0x0, size 18336 bytes total size: 18336 bytes (294.5 kbit/s) read 136 symbols entry point: 0x00000000 grlib> verify prom.out section: .text at 0x0, size 18336 bytes total size: 18336 bytes (83.8 kbit/s) entry point: 0x00000000 grlib> Finalmente se bloquea nuevamente la memoria Flash: grlib> flash lock all Para verificar que la aplicación funciona de manera correcta, se puede conectar un cable NULL MODEM entre el UART del kit de desarrollo y una PC. Usando una terminal, al iniciar la placa (sin GRMON) obtenemos: 3.7. SISTEMAS OPERATIVOS 3.7. 31 Sistemas Operativos Un amplio rango de los sistemas operativos más populares, traen soporte para el procesador LEON3. Desde un simple administrador de tareas hasta sistemas operativos de tiempo real (RTOS Real-Time Operating System) pueden ser instalado en un sistema embebido basado en el procesador LEON. Las lista completa se encuentra en [LEONOS], pero podemos nombrar a los siguientes SO: VxWORKS (http://www.windriver.com/products/vxworks/). RTEMS (http://www.rtems.org/). eCos (http://ecos.sourceware.org/). Linux SnapGear (http://www.gaisler.com/index.php/products/operating-systems/ linux?task=view&id=63). 32 CAPÍTULO 3. BIBLIOTECA GRLIB Capı́tulo 4 Inyección de fallas Tal como lo vimos en la historia del Telstar (Sección 1.1), en diseños digitales para aplicaciones crı́ticas, el cambio de estado de un dispositivo microelectrónico tales como un microprocesador, memoria o transitor, provocado por radiación o interferencia electromagnética puede producir un efecto adverso. De modo que es deseable la capacidad de comparar la inmunidad de distintas soluciones propuesta a éstos tipos de fallos. Muchas de las aproximaciones para medir la confiabilidad de un sistema tolerante a fallos están basadas en el modelo evaluación bit flip [G-MAT2008], que implica invertir el valor de distintos bits de memoria de manera controlada, es decir, eligiendo la localidad y el instante. Además, y en complemento a otras aproximaciones, tales como los métodos analı́ticos, donde la aplicación y la precisión están significantemente restringido en el caso de sistemas complejos, la inyección de fallas ha sido particularmente atractiva y valiosa. La inyección de fallas proporciona un método para evaluar la confiabilidad de un sistema [SFIT2004]. Consiste en generar fallas en distintas zonas de un sistema y observar su reacción. Muchos métodos han sido desarrollados hasta el momento, cada uno se diferencia del mecanismo utilizado, el área de cobertura y cuan intrusivo es implementarlo en el sistema. Este Capı́tulo, presenta primero el concepto de confiabilidad y sistemas tolerantes a fallos. Luego, define inyección de fallas y muestra algunos trabajos previos. 4.1. Tolerancia a fallos y confiabilidad Un circuito es tolerante a fallos, si puede continuar realizando sus funciones en presencia de errores [Jhon89]. Es decir, la calidad del servicio prestado por el circuito, no disminuye cuando el sistema se ve afectado por algún fallo. Esta propiedad, denominada confiabilidad, es el objetivo principal que debe cumplir un sistema tolerante a fallos para aplicaciones crı́ticas. La confiabilidad de un sistema se mide de acuerdo a los siguientes parámetros [Portela2007]: Fiabilidad: Cuantifica la continuidad del servicio prestado. Es decir, mide la duración de los periodos donde el sistema funciona correctamente. 33 34 CAPÍTULO 4. INYECCIÓN DE FALLAS Disponibilidad: Es la capacidad del sistema de estar preparado para ejecutar una función en un instante dado. Está relacionada con la velocidad de recuperación ante una falla. Seguridad: Un sistema es seguro si ante una falla no existe la posibilidad de dañar a otro sistema o componente. Capacidad de ejecución: Mide la cantidad de funciones de un sistema que están activas en un periodo de tiempo. Se utiliza cuando un fallo no interrumpe el funcionamiento total del sistema, sino que disminuye su capacidad. Mantenibilidad: Indica cuan fácil es reparar un sistema dañado. Testeabilidad: Indica la capacidad del sistema para comprobar el estado de sus componentes y la calidad de sus funciones. 4.2. Falla, error y defecto Un sistema no siempre realiza la función para el cual fue diseñado. Las causas y consecuencias de la desviación de la ejecución esperada de un sistema se llaman factores de confiabilidad [SFIT2004]. Un fallo en un circuito indica un defecto fı́sico o imperfección en algún componente hardware o software del circuito, como por ejemplo lo puede ser un cortocuito o un defecto en un dispositivo semiconductor. La manifestación de un fallo se denomina error. Ası́, en el caso del cortocicuito puede ocurrir que una lı́nea del circuito quede fijada a un valor de tensión. A su vez, un error puede provocar un funcionamiento deficiente del circuito denominado defecto. 4.2.1. Tipos de fallas Las fallas de hardware que ocurren durante la operación de un sistema pueden ser clasificadas según su duración, en: permanentes, transitorias e intermitentes [SFIT2004]: Falla permanente: Falla provocada por un daño irreversible de un componente. Por ejemplo, juntura PNPN de un semiconductor causado por envejecimiento, temperatura o defecto de fabricación. Falla transitoria: Generada por una condición ambiental tal como una fluctuación en una lı́nea de tensión, interferencia electromagnética o radiación. Este tipo de falla raramente daña al componente afectado, aunque si puede inducir el sistema a un estado erróneo. Más conocida en la literatura como Single Event Upset (SEU). Falla intermitente: Es causada por hardware inestable que provoca la transición de estados del sistema de manera no deseada. Las fallas del tipo permanentes y del tipo transitorias, pueden ser fácilmente inyectadas en un dispositivo hardware. Existen herramientas de hardware dedicado, para invertir el valor lógico de un integrado, variar la tensión de los conductores, o incluso bombardear el sistema con iones pesados (por ejemplo 4.3. EFECTOS DE LA RADIACIÓN CÓSMICA EN LA MICROELECTRÓNICA35 [LEON3FT]), con el fin de generar fallas lo mas cercano a la falla real en un sistema en operación. Una herramienta que está ganando popularidad es el injector de fallas de tipo transitorias implementado en software. Cuyo objetivo, es alterar el valor lógico de un conjunto de bits de memoria o registros del procesador, produciendo de ésta manera, el mismo efecto que una falla de hardware transitoria. Todas estas técnicas, requieren que se implemente un sistema, o al menos un prototipo, con el fin de realizar el ensayo. 4.3. Efectos de la radiación cósmica en la microelectrónica Los factores ambientales, tales como la variación en la temperatura, fluctuaciones en la tensión de las lı́neas de alimentación, interferencias electromagnéticas, y en especial la radiación cósmica, pueden afectar al comportamiento normal de un circuito de un sistema en operación [Portela2007]. El fuerte desarrollo de la tecnologı́a de los semiconductores, ha provocado un aumento significativo de la sensibilidad a dichos factores. Se han reducido las dimensiones de los transistores hasta escalas nanométricas, las tensiones de alimentación han disminuido y las frecuencias de funcionamiento se han incrementado. Estos avances implican una reducción de los niveles de ruidos aceptables, que producen un aumento en la sensibilidad del sistema a fuentes de ruidos y disminuye su confiabilidad. Un caso especial de ruido, es la radiación cósmica, conformado por partı́culas cargadas y ondas altamente energéticas que provienen del espacio. Es una radiación ionizante, lo que significa que interacciona con la materia a la que llega, con suficiente energı́a como para provocar la pérdida de electrones en los átomos, ionizando las moléculas. 4.3.1. Fuentes de radiación En el espacio existen gran cantidad de partı́culas, entre ellas electrones, protones e iones pesados, que son las principales responsables de la presencia de radiación. Podemos agrupar las fuentes de radiación en 4 grupos [Rod2007]: Cinturones de Van Allen. Erupciones solares. Vientos solares. Rayos cósmicos. Cinturones de Van Allen Los cinturones de Van Allen, son ciertas zonas de la magnetósfera terrestre donde se concentran las partı́culas cargadas. Fueron descubiertas por el Fı́sico estadounidense James Alfred Van Allen (1914-2006), a través del satélite Explorer 1 (Sección 1.1). 36 CAPÍTULO 4. INYECCIÓN DE FALLAS Hay dos cinturones de Van Allen: Cinturón Inferior: Se extiende desde los 1.000 km por encima de la superficie terrestre, hasta más allá de los 5.000 km. Los satélites de órbita baja LEO1 , deben elegir cuidadosamente sus órbitas para no estár demasiado expuesto a la radiación. Cinturón Superior: Se extiende desde los 15.000 km por encima de la superficie terrestre hasta los 20.000 km. Erupciones solares Las erupciones solares son grandes explosiones que se producen en la atmósfera del Sol. Debido a éstas explosiones, se aceleran los protones, electrones e iones pesados a velocidades cercanas a la velocidad de la luz. Esta radiación que genera podrı́a llegar a la Tierra, afectando a cualquier satélite artificial o nave espacial. También es dañina para la salud humana. Toda la información actualizada sobre la actividad solar puede encontrarse en la página web de la NASA http://www.nasa.gov/mission_pages/sdo/ news/solar-activity.html, en particular, la erupción solar del 22 de Octubre del 2012 que afectó a los dispositivos electrónicos (http://www.nasa.gov/ mission_pages/sunearth/news/News102312-xflare.html). Vientos solares El viento solar es una corriente de partı́culas cargadas expulsada de la atmósfera superior del Sol. Este viento consiste principalmente de electrones y protones. La temperatura y velocidad del flujo de partı́culas varı́a con el tiempo. Estas partı́culas pueden escapar de la gravedad del Sol debido a su alta energı́a cinética y alta temperatura de la corona. Alcanzan una velocidad entre 300 y 900 km/s. Rayos cósmicos Consisten en partı́culas subatómicas aceleradas como protones, electrones e iones pesados. Podrı́an ser, por ejemplo, generadas gracias a la explosión de una supernova por erupciones solares. Los rayos cósmicos están compuesto en su mayor parte por protones (83%). Cuando un rayo cósmico llega a la atmósfera se lo denomina rayo primario. A la superficie terrestre llegará la radiación de una forma más atenuada, producto del paso por la atmósfera. Al llegar a la superficie terrestre, se lo llaman rayos secundarios. 4.4. Mecanismos de inyección de fallas La inyección de fallas es definido por Arlat [ARLAT] como la técnica de validación de la confiabilidad de un sistema tolerante a fallas, que consiste en 1 http://en.wikipedia.org/wiki/Low_Earth_orbit 4.5. TRABAJOS ANTERIORES 37 el cumplimiento de experimentos controlados donde la observación del comportamiento del sistema en presencia de fallas es inducida explı́citamente por la inyección de fallas en el sistema. Las técnicas de inyección de fallas han sido reconocidas por mucho tiempo como necesarias para validar la confiabilidad de un sistema, analizando el comportamiento de los dispositivos cuando una falla ocurre. A lo largo de los últimos años, se han implementado distintas técnicas para la inyección de fallas en un prototipo de sistema o modelo [Portela2007][SFIT2004]. Muchas de esas técnicas pueden agruparse en una de las siguientes categorı́as: Basadas en hardware: Es realizado a nivel fı́sico, perturbando el hardware con parámetros ambientales (radiación de iones pesados, interferencia electromagnética), alteración de la tensión en las lı́neas o modificación de los valores de la entradas y salidas del circuito. Basadas en software: El objetivo de éste técnica consiste en reproducir a nivel de software, fallas que podrı́an ser generados por fallas en el hardware, por ejemplo, alteración de valores de memoria, de registro del procesador, etc. Basadas en simulación: Consiste en la inyección de fallas en modelos de alto nivel (a menudo, modelos VHDL). Permite evaluar de manera temprana la confiabilidad de un sistema, únicamente cuando un modelo del sistema está disponible. Basadas en emulación: Esta técnica ha sido presentada como una solución alternativa para reducir el tiempo durante etapas de inyección de fallas en simulaciones. Consiste en la implementación del circuito lógico bajo ensayo en FPGA, para conseguir ası́ mayor velocidad en fases de depuración. Modelos hı́bridos: Esta aproximación utiliza un método de inyección basado en software y la monitorización se realiza mediante hardware. 4.5. Trabajos anteriores Este trabajo presenta un mecanismo de inyección de fallas del tipo de software, es decir, el objetivo es generar fallas en el sistema que se asemeje a la naturaleza de las fallas producidas por causas de hardware. Por lo tanto, la recopilación de métodos y herramientas presentadas en esta Sección, pertenecen a ésta categorı́a. Debido a la diversidad de trabajos diseñados a lo largo de las últimas décadas, los cientı́ficos han categorizado los métodos utilizados, en dos grupos, dependiendo del instante en el que la falla es inyectada: tiempo de compilación o tiempo de ejecución. Inyección en tiempo de compilación El código fuente del programa es alterado en tiempo de compilación, generando una imagen de programa errónea. De esta manera, el programa causa (o no) una falla en tiempo de ejecución. Este método inyecta fallas en código fuente 38 CAPÍTULO 4. INYECCIÓN DE FALLAS del programa, a diferencia de otros métodos que inyectan fallas en el sistema (memoria, registros de CPU, bus). Un método es el mutation testing2 , que reemplaza lı́neas de códigos por otras que contienen errores. Por ejemplo: La lı́nea a = a + 1; cambia a a = a - 1; Es una técnica simple, pero poco práctica, ya que en cada ensayo distinto, se requiere compilar nuevamente el código. Inyección en tiempo de ejecución La falla es inyectada dinámicamente durante la ejecución del sistema. Se requiere un mecanismo de disparo de la falla. Los mecanismos usados más comunes incluyen: Time-out: Es la técnica más simple. Cuando un temporizador expira a un tiempo predeterminado, dispara la falla. Generalmente, la expiración de un temporizador genera una interrupción, que es aprovechada para ejecutar el mecanismo de inyección de fallas. Excepción: En este caso, una excepción de hardware o de software (trap) transfiere el control al inyector de fallas. A diferencia de time-out, se pueden utilizar eventos para disparar la falla, por ejemplo, al intentar escribir una posición de memoria, o al ejecutar una instrucción en particular. Inserción de código: En ésta técnica, se agregan instrucciones al programa, que permiten generar fallas bajo ciertas condiciones. A diferencia de los métodos de tiempo de compilación, la inserción de código agrega instrucciones en vez de modificarlas. Algunos trabajos previos Los siguientes trabajos han sido desarrollados por distintas Universidades utilizando los métdos descriptos en la Sección anterior. Se describe principalmente los métodos utilizados y el área de acción sobre el sistema. FERRARI (Fault and Error Automatic Real-Time Injection) Desarrollado en la Universidad de Texas. Utiliza traps para inyectar fallas en CPU, memoria y fallas en el bus. Ferrari consiste de 4 módulos: un inicializador y activador, información al usuario, inyector/colector de datos y analizador [FERRARI]. 2 http://en.wikipedia.org/wiki/Mutation_testing 4.5. TRABAJOS ANTERIORES 39 FTaPE (Fault Tolerance and Perfomance Evaluator) Desarrollado en la Universidad de Illinois. Inyecta fallas en registros de CPU, memoria y disco. La fallas son generadas desde los controladores de dispositivos del sistema operativo, por lo tanto, no es necesario la modificación de código de las aplicaciones, pero si el del sistema operativo [FTaPE]. DOCTOR (integrateD sOftware fault injeCTiOn enviRonment) Desarrollado en la Universidad de Michigan, permite inyección de fallas en CPU, memoria y comunicaciones de red. Combina los métodos de time-out, trap y modificación de código [DOCTOR]. 40 CAPÍTULO 4. INYECCIÓN DE FALLAS Capı́tulo 5 Diseño e implementación de TRAFIC La mayorı́a de los procesadores actuales implementan una caracterı́stica denominada On-Chip Debug (OCD) [OCD2003], que hace posible depurar en tiempo real el sistema implementado en el hardware. Este mecanismo, consta básicamente de un módulo conectado al bus principal del sistema, con una interfaz externa que se comunica con un cliente remoto y que permite tomar control del procesador desde una computadora host. El procesador LEON3 también tiene soporte OCD brindado por el módulo Debug Support Unit (DSU) y el cliente GRMON (Sección 3.5). El procesador implementa un modo depuración, en el cual, se detiene la ejecución de instrucciones y el sistema es controlado a través de GRMON. Al regresar al modo normal la ejecución se reanuda a partir de la instrucción desde donde se detuvo. TRAFIC (TRansparent And non-intrusive Fault InjeCtor), aprovecha ésta caracterı́stica del procesador y lo induce a modo depuración al momento de inyectar la falla y lo regresa al modo normal cuando ya ha sido inyectada para no alterar el flujo de ejecución del programa, logrando ası́ un mecanismo no intrusivo. 5.1. Debug Support Unit Para simplificar la tarea de depuración en tiempo real del SoC ya implementado en el hardware, el procesador LEON3 implementa un modo depuración, durante el cual, el pipeline1 detiene la ejecución de instrucciones y el procesador es controlado por el DSU y el cliente remoto GRMON (Sección 3.5), permitiendo: Leer y escribir la memoria, los registros del procesador y de cada componente conectado al bus. Desensamblar código. 1 Wikipedia: http://en.wikipedia.org/wiki/Classic_RISC_pipeline 41 42 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DE TRAFIC Cargar y ejecutar aplicaciones. Colocar breakpoints. Trazar la ejecución de un programa. Crear un perfil (profiling) de la aplicación. Cuando el procesador sale del modo depuración y entra al modo normal, se reanuda la ejecución de instrucciones desde donde se detuvo. El DSU está conectado al bus AMBA AHB y comunica con el cliente remoto GRMON mediante una interfaz externa, entre las que se encuentran: UART, JTAG, PCI, USB o Ethernet. Figura 5.1: Debug Support Unit. El módulo DSU está conectado al bus AMBA AHB y también se comunica con la interfaz de depuración del procesador. El recuadro con lı́nea punteada de la imagen señala las distintas interfaces externas con la que el DSU se comunica con el cliente remoto GRMON. 5.1.1. Operación A través del DSU, cualquier módulo AHB Maestro (Sección 3.3) puede acceder a los registros del procesador y a los de cada módulo conectado al bus. Los registros del DSU pueden accederse en cualquier momento, mientras que los registros del procesador sólo pueden ser accedidos cuando el procesador está en modo depuración. El procesador entra en modo depuración cuando sucede algunos de los siguientes eventos: La ejecución de un breakpoint ó watchpoint. Flanco ascendente de la señal externa break del DSU. 5.2. MEMORIA 43 Escribiendo un 1 en el bit BN (break now) del registro de control del DSU. La ejecución de una trap que causa al procesador entrar en modo de error. Ocurrencia de alguna trap definida en el registro de control del DSU. El DSU debe estar activado (señal externa dsuen = 1) cuando el procesador entra en modo depuración. Cuando cambia de modo, se realizan las siguientes acciones: Los registros PC y nPC son almacenado en registros temporales. La lı́nea externa active pasa a nivel alto para indicar el nuevo modo. Opcionalmente, se detienen los timers y el watchdog. La instrucción que causa al procesador entrar en modo depuración no es ejecutada y el estado del procesador se mantiene sin modificaciones. El modo normal se reanuda escribiendo un 0 en el bit BN (break now) del registro de control del DSU o deshabilitando el DSU (lı́nea dsuen = 0). El manual del módulo DSU se encuentra en [GRLIBIP2012, Chp. 27]. 5.2. Memoria Por defecto, el SoC implementa un controlador para acceder a la memoria RAM fı́sica del kit de desarrollo, una DDR2 de 256 Mbyte2 . La interfaz del controlador [GRLIBIP2012, Chp. 24] es compleja, y no aporta mucha significancia en éste trabajo utilizar éste tipo de memoria, por lo que se decidió reemplazarla por una con interfaz más simple: una memoria RAM de dos puertos. Estas memorias son especialmente útiles como buffer entre la comunicación del procesador con un dispositivo externo. Se utilizó la AHBDPRAM (Dual-port RAM with AHB interface) de 32 bits de Gaisler, incluı́da en la biblioteca GRLIB [GRLIBIP2012, Chp. 8]. La memoria tiene un puerto con interfaz AMBA AHB, que se comunica con el procesador y un puerto denominado backend para aplicaciones de usuarios. El tamaño de la memoria es configurable a través de parámetros de VHDL (es decir, generics). Dependiendo de la tecnologı́a de la FPGA, el tamaño mı́nimo es 1KB y el máximo es 2048KB. Los accesos de lectura requieren 0-waitstate3 , mientras que los de escritura 1-waitstate. El puerto backend consiste de las siguientes señales: Señal CLKDP ADDRESS[abits-1:0] DATAIN[31:0] DATAOUT ENABLE WRITE[0:3] E/S Entrada Entrada Entrada Salida Entrada Entrada Función Entrada de reloj del puerto backend Bus de direcciones. Bus de escritura Bus de lectura Habilitar puerto backend Seleccionar el byte de escritura cuando bytewrite = 1 (Activo por alto) 2 http://www.xilinx.com/univ/xupv5-lx110t.htm 3 Wikipedia: http://en.wikipedia.org/wiki/Wait_state 44 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DE TRAFIC Todas éstas señales son muestradas en el flanco ascendente del pulso de reloj (lı́nea CLKDP), implementando ası́ una RAM sincrónica. La memoria no implementa ningún tipo de mecanismo de protección contra inconsistencia de datos en el caso de una lectura y escritura simultánea realizada por ambos puertos a la vez. El usuario debe controlar la sincronización de los accesos. La hoja de datos de AHBDPRAM se encuentra en [GRLIBIP2012, Chp. 8]. Figura 5.2: Memoria AHBDPRAM. La figura muestra las interfaces de los dos puntos de accesos. 5.2.1. Implementación de AHBDPRAM en el SoC La memoria actúa como un dispositivo esclavo (Sección 3.3) del bus AMBA AHB y se conecta tal como lo muestra la Fig. 5.3. Se instancia en el archivo leon3mp.vhd dentro del directorio grlib-gpl-1.1.0b4113/designs/leon3-xilinx-ml509. Para conectar la AHBDPRAM es necesario agregar las siguientes librerı́as: library grlib; use grlib.amba.all; library gaisler; use gaisler.misc.all; En el archivo leon3mp.vhd agregamos el siguiente código: ahbdpram : ahbdpram generic map ( hindex => AHBDPRAM_INDEX, haddr => 16#400#, tech => CFG_MEMTECH, 5.2. MEMORIA 45 Figura 5.3: Conexión de la memoria AHBDPRAM. La memoria se conecta al bus AMBA AHB como un dispositivo esclavo. abits => AHBDPRAM_ABITS, bytewrite => 0) port map ( rst => rstn, clk => clkm, ahbsi => ahbsi, ahbso => ahbso(AHBDPRAM_INDEX), clkdp => clkm, address => dpram_address, datain => dpram_datain, dataout => dpram_dataout, enable => dpram_enable, write => dpram_write ); donde: hindex es el ı́ndice del dispositivo dentro del bus AMBA. haddr son los bits más significativo de la dirección de hardware de la memoria (corresponde a la dirección 0x40000000 donde se asigna la sección .text (código de programa) del ejecutable). tech indica que tipo de tecnologı́a tiene la FPGA para implementar la memoria. abits es el ancho del bus de direcciones. bytewrite es una opción que permite escrituras de un byte dentro del bus de datos de 32 bits. 46 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DE TRAFIC 5.3. Diseño de TRAFIC TRAFIC es un inyector de fallas en memoria RAM basado en el modelo bit-flip. Consideraremos que la acción de una falla es la corrupción de un dato en memoria. Por lo tanto, el objetivo de TRAFIC es invertir el valor de una selección de bits de una posición de memoria en un instante dado. Una falla f se define como una 3-upla (a, m, t) donde a es una dirección de memoria, m una máscara (indica con un 1 que bits de la dirección a invertirán su valor al momento de la falla) y t es el en instante que debe generarse la falla. Tal como lo muestra la Fig. 5.4, TRAFIC está implementado en los recursos disponibles de la FPGA aunque no forma parte del SoC y se comunica con una computadora host a través del puerto serie para recibir la lista de fallas. Figura 5.4: Implementación de TRAFIC en la FPGA. El funcionamiento básico de TRAFIC es el siguiente: TRAFIC recibe una lista de fallas f desde la computadora host y las almacena en un buffer interno. Sea n (n > 0) la longitud de la lista. Para i = 0 a i = n − 1 sea fi = (ai , mi , ti ) la i-ésima falla de la lista f : • Tomar la falla fi y contar ti flancos ascendentes de reloj desde que arrancó el procesador o desde que se reanudó la ejecución. • Al alcanzar la cuenta inducir al procesador a modo depuración. • Con la ejecución de instrucciones detenida leer la posición de memoria ai . Sea d el valor leı́do. 5.4. RECEPTOR DE FALLAS 47 • Aplicar la máscara mi y calcular el nuevo valor d0 = d XOR mi . • Escribir el valor d0 en la posición ai . • Restaurar el procesador a modo normal. Fin. TRAFIC internamente está compuesto por un receptor de fallas, un buffer y el mecanismo de inyección de fallas propiamente dicho. Figura 5.5: Interfaz TRAFIC y componentes. TRAFIC está compuesto por un receptor de comandos, un buffer para el almacenamiento de entradas de la forma (dirección, máscara y tiempo) y el mecanismo de inyección de fallas. 5.4. Receptor de fallas FaultReceiver es el módulo interno de TRAFIC encargado de recibir las fallas transmitidas desde la computadora host. Internamente está compuesto por un receptor UART (extraı́do de [FPGAEX]), implementando un canal simplex (solo lı́nea RX). Los parámetros baudrate y clock son configurables a través de generics. Las fallas se envı́an en tramas con orden big endian, es decir, los valores están en orden natural dentro de los campos. Existen dos tipos de tramas, las que contiene los datos de las fallas, denominadas fdframe y las que indican el fin de la transmisión, eotframe. 5.4.1. Tramas tipo fdframe Contienen los datos de las fallas. Tienen una longitud de 13 bytes y están compuestas por un encabezado (1 byte) y los campos: address, mask y time (4 48 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DE TRAFIC bytes cada uno). El encabezado identifica el tipo de la trama, está definido en la constante FDHEADER de la entidad FaultReceiver. El campo address indica la posición de memoria donde insertar falla. El campo mask indica que bits de la posición de memoria apuntada por address intercambiarán su valor al momento de la falla. Un 1 en el n-ésimo bit de la palabra mask, indica que el n-ésimo bit de la palabra de memoria de la dirección address, intercambiará su valor al momento de la falla, mientras que un 0 mantendrá el valor. El campo time indica cuantos flancos ascendentes de reloj deben pasar desde que el procesador arrancó o desde que se reanudó desde la última falla, para insertar la nueva. La Fig. 5.6 muestra el formato de un trama de tipo fdframe. Figura 5.6: Formato de una trama de tipo fdframe. 5.4.2. Tramas tipo eotframe Las tramas de tipo EOT (End Of Transmission) tienen una longitud de 1 byte y están compuestas únicamente por el encabezado. Sirven para indicar el fin de la transmisión de tramas del tipo fdframe. El encabezado está definido en la constante EOTHEADER. Figura 5.7: Formato de una trama de tipo eotframe. Por defecto, el valor de la constante FHEADER tiene el valor 0x55 y la constante EOTHEADER el valor 0xff. 5.5. Buffer Las fallas se almacenan en un buffer interno con entradas del tipo (address, mask, time). La longitud del buffer es configurable y depende de la tecnologı́a y capacidad de la FPGA. En este trabajo, el tamaño del buffer es de 500 entradas. 5.6. Inyector de fallas Una vez explicado el concepto de modo depuración del procesador LEON3, el funcionamiento de las memorias dos puertos y los componentes internos de 5.6. INYECTOR DE FALLAS 49 TRAFIC: FaultReceiver y Buffer, podemos pasar a explicar el mecanismo de inyección de fallas. FaultInjector es el componente de TRAFIC de más alto nivel, encargado de la inyección de falla. Está implementado como una máquina de estados finitos, por lo tanto, vamos a explicar el funcionamiento en base a sus estados internos. Figura 5.8: Máquina de estados interna de TRAFIC. Recibir lista de fallas Es el estado inicial de TRAFIC. FaultReceiver recibe la lista de fallas desde la computadora host y la almacena en el buffer interno. Cuando se recibe la trama de fin de transmisión, se pasa al siguiente estado. En espera Una vez recibidas las fallas y almacenadas en el buffer, el inyector espera a que el procesador comience la ejecución. 50 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DE TRAFIC La lı́nea de entrada START está conectada a la lı́nea active del DSU e indica con un 0, que el procesador sale del modo depuración y entra en el modo normal, e indica con un 1 cuando realiza la transición inversa. Contando TRAFIC está conectado a la misma fuente de reloj del procesador. Al comenzar la ejecución (transición de 1 a 0 de la lı́nea START), el inyector de fallas, cuenta flancos ascendentes de pulsos de reloj. Cuando alcanza la cantidad de pulsos definidos por la falla, el inyector induce al procesador a modo depuración. Modo depuración Uno de los eventos que induce al procesador a modo depuración, es un flanco ascendente en la lı́nea external break del DSU (Sección 5.1.1). TRAFIC escribe un 1 en la lı́nea external break del DSU a través de la lı́nea STOP e induce al procesador a modo depuración para leer la memoria en el próximo estado. Leer memoria Con la ejecución de instrucciones detenida, TRAFIC accede a la memoria RAM a través del puerto backend, para leer el contenido. Aplicar máscara Se aplica la máscara definida en la falla, sobre el valor de memoria leı́do, para intercambiar el valor de los bits. Escribir memoria Se escribe en memoria el nuevo valor. Si quedan más fallas para inyectar, el siguiente estado es en espera, sino, el TRAFIC pasa al estado final. Fin Es el estado final, luego de inyectar todas las fallas. 5.7. 5.7.1. Conexión de TRAFIC al SoC Memoria Tal como vimos más arriba, la interfaz backend de la memoria dos puertos, consta de los siguientes buses y lı́neas: clkdp address(31:0) dataout(31:0) datain(31:0) 5.7. CONEXIÓN DE TRAFIC AL SOC 51 enable write(3:0) Reloj La memoria AHBDPRAM es una memoria sincrónica. Los señales son muestradas en el flanco ascendente del pulso de reloj clkdp. Por lo tanto, a ésta señal está conectado a la fuente de reloj maestro del sistema, clkmst. Buses address, dataout y datain El bus de direcciones address de la memoria se conecta con el bus de salida address de TRAFIC. Para escribir un valor en memoria, se conecta el bus de salida dataout de TRAFIC al bus de escritura datain de la memoria. Para leer un valor de la memoria, el bus de datos de lectura dataout, se conecta con el bus de entrada datain, de TRAFIC. Linea enable La lı́nea enable habilita la memoria. Funciona como lı́nea chip select4 cuando se utilizan múltiples pastillas de memoria. En este trabajo se utiliza solamente una pastilla, por lo tanto, ésta lı́nea está cableada al valor 1. Bus write La memoria tiene la opción bytewrite que cuando es habilitada (bytewrite = 1), el bus datain se particiona en 4 canales de un byte cada uno, que pueden ser escritos de manera independiente. write(0) controla la escritura del byte datain[31:24], write(1) el byte datain[23:16] y ası́ siguiendo. En este trabajo, se realizan únicamente escrituras de palabras de 32 bits, por lo tanto, la opción bytewrite está deshabilitada. La linea write(0) controla la escritura de la palabra de 32 bits y es conectada a la lı́nea active de TRAFIC que indica que el valor del bus dataout está preparada para ser escrito en la dirección apuntada por el valor del bus address. 5.7.2. DSU La interfaz del DSU posee la lı́nea de salida active que indica si el procesador está en modo normal o en modo depuración, y la lı́nea de entrada break que al escribir un 1, el procesador entra en modo depuración. Estas lı́neas se conectan respectivamente a las lı́neas START y STOP de TRAFIC. A través de ellas, el inyector de fallas, conoce cuando el procesador comenzó la ejecución y también puede inducirlo en modo depuración. 5.7.3. Reloj principal El SoC incluye un generador de reloj (CLKGEN [GRLIBIP2012, Chp. 21]) que se encarga de distribuir el reloj maestro al procesador, al bus AMBA y a cada dispositivo. TRAFIC aprovecha ésta fuente, para contar los pulsos de reloj para inyectar la falla. 4 http://en.wikipedia.org/wiki/Chip_select 52 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DE TRAFIC Figura 5.9: Conexión TRAFIC con la memoria AHBDPRAM. Figura 5.10: Conexión TRAFIC con el DSU. 5.8. Compilación El proceso de sı́ntesis (Sección 3.4) comienza examinando qué librerı́as y qué componentes de cada una, deben ser compilados y sintetizados junto al SoC: ~/grlib-gpl-1.1.0-b4113/designs/leon3-xilinx-ml509/$ make ise Scanning libraries grlib: stdlib util sparc modgen amba unisim: ise dware: simprims synplify: sim techmap: gencomp inferred dware unisim maps eth: comp core wrapper opencores: occomp i2c spi ac97 gaisler: arith memctrl leon3 misc net uart sim jtag greth ddr i2c spi esa: memoryctrl cypress: ssram hynix: ddr2 micron: sdram ddr 5.8. COMPILACIÓN 53 Figura 5.11: Conexión TRAFIC con la fuente de reloj del sistema. work: debug Por lo tanto, debemos indicarle a la herramienta de compilación, que agregue a TRAFIC en el proceso. La biblioteca GRLIB incluye una colección de IP cores agrupados por fabricante dentro del subdirectorio grlib-gpl-1.1.0-b4113/lib. Por ejemplo, la versión b4113 contiene módulos de los siguientes fabricantes: ~/grlib-gpl-1.1.0-b4113/lib$ ls -1 contrib cypress esa eth fmf gaisler gleichmann grlib gsi hynix micron openchip opencores praesum spansion spw synplify tech techmap work libs.txt 54 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DE TRAFIC Cada fabricante incluye sus propios IP cores, por ejemplo los siguientes componentes fueron creados por Gaisler: ~/grlib-gpl-1.1.0-b4113/lib/gaisler$ ls -1 ambatest arith ata can ddr gr1553b greth i2c jtag leon3 leon3ft memctrl misc net pci sim spacewire spi uart usb dirs.txt Por ejemplo, el IP core Serial Peripheral Interface (SPI) contiene los siguientes archivos: ~/grlib-gpl-1.1.0-b4113/lib/gaisler/spi$ ls -1 spi.vhd spi2ahb.in spi2ahb.in.h spi2ahb.in.help spi2ahb.in.vhd spi2ahb.vhd spi2ahb_apb.vhd spi2ahbx.vhd spi_flash.vhd spictrl.in spictrl.in.h spictrl.in.help spictrl.in.vhd spictrl.vhd spictrlx.vhd spimctrl.in spimctrl.in.h spimctrl.in.help spimctrl.in.vhd spimctrl.vhd vhdlsim.txt 5.9. CLIENTE COMPUTADORA HOST 55 vhdlsyn.txt Las librerı́as que van a formar parte del proceso de compilación y sı́ntesis, están declaradas en el archivo /lib/libs.txt. Cada librerı́a contiene un subdirectorio por cada componente y un archivo llamado dirs.txt que indica cuales de éstos deben ser incluı́dos en la compilación. Como un mismo componente puede constar de distintos archivos (por ej: código fuente, casos de pruebas, archivos de simulación), dentro de cada componente, el archivo vhdlsyn.txt que archivos debe compilarse. Por lo tanto, se creó una nueva librerı́a llamada faultinjector y se la declaró en el archivo /lib/libs.txt. Dentro del directorio /lib/faultinjector se agregó el componente TRAFIC y se lo declaró en el archivo /lib/faultinjector/dirs.txt. Finalmente, dentro del directorio /lib/faultinjector/trafic/ se agregó el código fuente de TRAFIC y se los declaró en el archivo vhdlsyn.txt 5.9. Cliente computadora host Para la transmisión de fallas desde la computadora host a TRAFIC, se desarrolló un cliente denominado TRAFIC Fault Transmitter (TFT). TFT toma una lista de fallas definida en un archivo de texto plano y la transmite por el puerto serie de la computadora host. 5.9.1. TRAFIC Fault Transmitter El software de transmisión de fallas TFT fue desarrollado en Python. Tiene una lógica simple, ya que su función es básicamente leer un fichero de texto plano y transmitirlo por UART. Se decidió utilizar Python por la flexibilidad que brinda en el manejo de lista y cadenas. TFT toma los siguientes argumentos: $./TFT <filename> [<port>] [<baudrate>] filename: Nombre del archivo que contiene la lista de fallas. port: (Opcional) Establece puerto de comunicación (Por defecto: COM1). baudrate: (Opcional) Establece el baudrate de la comunicación (Por defecto: 9600). 5.9.2. Transmisión Para transmitir datos a través del puerto serie, se utilizó la librerı́a pySerial [pySerial]. Esta librerı́a encapsula el acceso al puerto serie. Proporciona soporte para Python corriendo en Windows y en Linux. El uso de pySerial es muy sencillo. Por ejemplo, para abrir el puerto 0 a 9600 bps y enviar la cadena "hello" y luego recibir 10 bytes, se necesitan las siguientes lı́neas: 56 CAPÍTULO 5. DISEÑO E IMPLEMENTACIÓN DE TRAFIC user@pc $python >>> ser = serial.Serial(’/dev/ttyS1’, 19200, timeout=1) >>> ser.write("hello") # Enviar ’hello’ >>> s = ser.read(10) # Recibir hasta 10 bytes con timeoout = 10 >>> ser.close() # Cerrar el puerto 5.9.3. Formato del fichero La lista de fallas está definida en un fichero de texto plano. El fichero contiene una lı́nea por cada falla. Cada lı́nea está compuesta por 3 columnas de 8 caracteres cada una, separadas por un espacio en blanco, y corresponden, en base hexadecimal a los valores de dirección, máscara e instante de la falla. Por ejemplo, un archivo con 2 fallas contiene las siguientes lı́neas: 40000000 00001000 00000002 40000004 00000100 00000003 La primera falla va a invertir el bit 13-ésimo (0x00001000) de la dirección de memoria 0x40000000 luego de 2 ciclos de reloj de comenzar la ejecución. La segunda falla, corresponde al 9-ésimo bit (0x00000100) de la dirección 0x40000004 y va a suceder 3 pulsos de reloj luego de suceder la primera, es decir, 5 pulsos luego de arrancar el procesador. Capı́tulo 6 Conclusión Este trabajo puede dividirse en dos etapas, una por cada objetivo planteado al comienzo (Sección 1.7). La primera etapa consta desde el inicio del trabajo hasta la implementación del procesador LEON3 en el kit de desarrollo. Esto abarca: el estudio preliminar de la biblioteca GRLIB, el estudio de la arquitectura SPARC v8, preparación del entorno de desarrollo, instalación del toolchain, pruebas en simuladores, preparación del entorno de implementación en FPGA y finalmente la implementación y test en FPGA. La segunda etapa corresponde a un estudio de bajo nivel del código del procesador LEON3, estructura de archivos de compilación, implementación de la memoria de dos puertos, extracción de módulos no utilizados, estudios referentes a los mecanismo de inyección de fallas y por último el diseño, desarrollo e implementación del inyector de fallas. 6.1. Primera etapa El procesador LEON3 es quizás unos de los procesadores más populares que existe hoy en dı́a en el mundo de los IP cores. Posee ciertas caracterı́sticas que permiten ser el elegido entre otras opciones, para distintas aplicaciones, que van desde reproductores MP3 hasta aplicaciones espaciales [LEONGRLIB] [ExoMars]. Algunas de las cualidades del procesador son las siguientes: Se distribuye con código abierto y licencia GNU/GPL (aunque también por un bajo costo económico se puede obtener una licencia Comercial). Se entrega junto a la biblioteca GRLIB incluyendo más de 45 componentes bien documentados listo para conectar al bus AMBA, que permiten dar soluciones a prácticamente cualquier aplicación. Incluye las herramientas de depuración y simulación (TSIM), el compilador de plataforma cruzada (sparc-elf-gcc), un monitor en tiempo real para depuración del SoC implementado en el hardware (GRMON), un sistema operativo Linux (Snapgear 2.6), soporte para los sistemas operativos más utilizados (Sección 3.7), entre otras aplicaciones. Existe también un grupo soporte oficial libre1 mantenido por Jiri Gaisler, para que la comunidad que trabaja con los productos de su empresa puedan 1 http://tech.groups.yahoo.com/group/leon_sparc/ 57 58 CAPÍTULO 6. CONCLUSIÓN consultar sus dudas, realizar sugerencias y compartir información. Además, en comparación de las caracterı́stica técnicas con procesadores similares (Nios II, MicroBlaze, Xtensa XL, OpenRISC 1200), LEON3 posee ciertas ventajas: mayor velocidad de reloj del sistema (llegando hasta los 400 MHz en ASIC y a los 125 MHz en FPGA), cache configurable de tamaño hasta 256 kb (mientras que los demás procesadores 64 kb como máximo), FPU incluı́da, pipeline de 7 etapas y cantidad de registros de usuarios configurables. Una publicación que compara los procesadores sintetizable de la actualidad se puede encontrar en [SCPES2006]. La primera parte de este trabajo comenzó con el estudio y manejo del procesador y el tool-chain (compilador, simulador, depurador, etc). Luego continuó con el agregado de un IP core al sistema (memoria RAM de dos puertos), lo que requirió un estudio del bus AMBA AHB para conocer como es el manejo de señales de comunicación interna del sistema. Finalizando con la extracción de módulos tales como el controlador de VGA, PS/2, USB, Ethernet, etc para minimizar el diseño del DUT (Device under Test) y poder enfocar en el núcleo del problema: la inyección de fallas. Al finalizar la primera etapa, contaba con las aptitudes necesarias para el diseño e implementación de un SoC basado en GRLIB para diversas aplicaciones. Como fruto del desarrollo de este trabajo y quizás el más importante, puedo agregar que fui contratado en una empresa local contratista de CONAE para unirme al equipo de desarrollo de computadoras de alta confiabilidad basadas en LEON3 para ser utilizada en la actividad aeroespacial. 6.2. Segunda etapa En la industria espacial, en la tecnologı́a militar, en equipamiento médicos y en los demás sistemas crı́ticos, el principal requerimiento en el diseño de un producto, es la confiabilidad. Estos productos, están construidos con componentes de distintos grados de calificación, por ejemplo: comercial, militar y espacial, y son sometidos a mayores controles de calidad y test según su calificación, y por supuesto, el costo económico de estos componentes es notablemente superior a los componentes comerciales. En algunos casos, la calidad de los componentes entre los distintos grados de calificación es la misma, la diferencia recae sobre el proceso del control de calidad de dichos productos. Contar con un mecanismo de inyección de fallas, permite realizar una calificación propia de algunos componentes, tales como la FPGA, y de ésta manera abaratar costos utilizando componentes comerciales severamente testeados mediante el inyector de fallas. Esta es la filosofı́a de los desarrolladores de CubeSats [CubeSats]. El diseño del mecanismo de inyección de fallas demandó una aproximación de más bajo nivel del procesador y más precisamente del bus AMBA. La implementación VHDL del inyector de falla no fué tarea fácil. Si bien, durante la carrera en Lic. en Cs. de la Computación, en la materia Arquitectura de Computadoras, se introduce el tema de programación VHDL e implementación en FPGA, desarrollar un módulo que lea y escriba la memoria RAM de un sistema ya implementado y que interecepte lı́neas del procesador para inducirlo en 6.3. TRABAJOS FUTUROS 59 modo depuración o en modo normal, requirı́o un estudio más avanzado sobre el tema. 6.3. Trabajos Futuros TRAFIC es el primer método de inyección de fallas basado en las caracterı́sticas de depuración del procesador. Esto, lo convierte en un trabajo original y en una primera versión que puede ser continuada con el fin de agregarle más caracterı́sticas. Además, si el procesador está ganando popularidad y está siendo utilizado en aplicaciones donde se requiere alta confiabilidad, la inyección de fallas tiene un buen futuro. Durante el desarrollo de este trabajo, encontré algunos puntos que podrı́an agregarse a versiones futuras, que no fueron agregadas en esta versión porque requiere de mucha investigación, tiempo y para no exceder los limites fijados para ésta investigación y convertirlo en un ambicioso proyecto. Uno de los puntos, es el área de cobertura del inyector de fallas. Como vimos, TRAFIC inyecta fallas solamente en memoria RAM. Cuando el procesador entra en modo depuración, es posible leer y escribir los registros internos del procesador, de hecho, GRMON lo hace. Una próxima versión de TRAFIC podrı́a agregar un nueva localidad para la falla: los registros internos del procesador, logrando ası́ una cobertura más amplia de ataque. Otra mejora propuesta, es el tipo de memoria. En éste trabajo se implementó una memoria de dos puertos. Por un puerto lee y escribe el procesador, mientras que el otro puerto es aprovechado por el inyector de fallas para alterar el valor de los bits de memoria. Quizás, es posible realizar de manera similar el mismo enfoque pero sin utilizar éste tipo de memoria, interceptando los buses de comunicación del procesador con la memoria y desde allı́ insertar la falla, obteniendo de ésta manera un inyector más flexible. Cabe aclarar, que éstas 2 mejoras son un agregado a las caracterı́sticas de TRAFIC, se requiere estudiar y entender el funcionamiento interno de éste inyector para proceder a realizarle éstas mejoras. 60 CAPÍTULO 6. CONCLUSIÓN Capı́tulo 7 Bibliografı́a [LEONGRLIB ] LEON3/GRLIB SOC IP Library. Aeroflex Gaisler. [GRLIB2012 ] GRLIB IP Library User’s Manual. Version 1.1.0 B4113. Aeroflex Gaisler. 2012 [GRLIBIP2012 ] GRLIB IP Core User’s Manual. Version 1.1.0 B4113. Aeroflex Gaisler. 2012 [LEONOS ] Operating Systems. Compilers and real-time operating systems for LEON and ERC32. Aeroflex Gaisler. [Sparc92 ] The SPARC Architecture Manual Version 8. Sparc International Inc, 1992. [AMBA99 ] AMBA Specification (Rev 2.0). ARM. 1999 [BCC2011 ] BCC - Bare-C Cross-Compiler Users Manual.Version 1.0.36. Jiri Gaisler. Aeroflex Gaisler. 2011. [TSIM2011 ] TSIM2 Simulator User’s Manual.Version 2.0.21. Aeroflex Gaisler. 2011. [GRMON2011 ] GRMON User’s Manual. Version 1.1.51. Aeroflex Gaisler. 2011. [MKPROM2010 ] MKPROM2 User’s Manual. Version 2.0.25. Aeroflex Gaisler. 2010. [SparcARM1995 ] SPARC Assembly Language Reference Manual. SunSoft. 1995. [pySerial ] http://pyserial.sf.net/ [FITT97 ] Fault Injection Techniques and Tools. Mei-Chen Hsueh, Timothy K. Tsai, Ravishankar K. Iyer. University of Illinois at Urbana Champaign. IEEE. April 1997. [FIRESoPC ] Fault Injection-based Reliabity Evaluation of SoPCs. M. Sonza Reorda, L. Sterpone, M. Violante, M. Portela-Garcia, C. Lopez-Ongil, L. Entrena. IEEE European Test Symposium 2006. [SFIT2004 ] A Survey on Fault Injection Techniques. Haissam Ziade, Rafic Ayoubi, Raoul Velazco. The International Arab Journal of Information Technology, Vol. 1, No. 2. July 2004 61 62 CAPÍTULO 7. BIBLIOGRAFÍA [LEON3FT ] LEON3-FT-RTAX SEU test results. Jiri Gaisler. Gaisler Research. December 2005. [ARLAT ] Validation de la sûreté de Fonctionnement Par Injection de Fautes. Arlat Jean. December 1990 [Portela2007 ] Técnicas de inyección de fallas basadas en FPGAs para la evaluación de la tolerancia de fallos de tipo SEU en circuitos digitales. Marta Portela Garcia. Tesis doctoral. Universidad Carlos III de Madrid. Leganés 2007. [Rod2007 ] Diseño de un entorno de hardware para el testeo de chips sometidos a un entorno de radiación nuclear. José Antonio Rodrı́guez. Septiembre 2007. [SEUGL ] Single Event Upset at Ground Level. Eugene Normand. Boeing Defense & Space Group. [SCPES2006 ] Soft-Core Processor for Embedded Systems. Jason G. Tong, Ian D. L. Anderson and Mohammed A. S. Khalid. The 18th International Confernece on Microelectronics (ICM) 2006. [CubeSats ] Wikipedia: http://en.wikipedia.org/wiki/CubeSat [SoftCores ] Soft CPU Cores for FPGA. Core Technologies. [G-MAT2008 ] A Non-Invasive System for the Measurement of the Robustness of Microprocessortype Architectures Against Radiation-induced Soft Errors. H. GuzmánMiranda, M.A Aguirre, J. Tombs. Universidad de Sevilla. 2008. [DOCTOR ] DOCTOR: An Integrated Software Fault Injection Environment. Han S., Rosenberg H., Shin K. Technical Report CSE-TR-192-93, University of Michigan. 1993. [FERRARI ] FERRARI: A Tool for the Validation of System Dependability Properties. Kanawati G. A., Kanawati N. A. Abraham J.A. Proceedings of 22th Annual International Symposium Fault-Tolerant Computing. 1992. [FTape ] An Approach to Benchmarking of Fault-Tolerant Commercial Systems. Tsai T.K., Iyer R.K. Proceedings of 26th Annual International Symposium Fault-Tolerant Computing. 1996. [Mitr05 ] Robust System Design with Built-In Soft Error Resilience. S. Mitra, N. Seifert, M. Zhang, Q. Shi, K. S. Kim. IEEE Computer, pp. 43-52. 2005. [Mongollon2008 ] Técnicas para la simulación de los efectos de la radiación cósmica en un dispositivo CMOS. Juan M. Mongollón Garcı́a. Trabajo Fin de Máster. Noviembre 2008. [SSFAIL2005 ] Space Systems Failures. Disasters and Rescues of Satellites, Rockets and Space Probes. David M. Hardland. Ralph D. Lorenz. Springer. 2005. [ExplorerI ] Explorer I. Jet Propulsion Laboratory. 2007. [Telstar ] SatMagazine. Pages 43-45. http://www.satmagazine.com. May 2008. [ExoMars ] ExoMars Vehicle. M. Roe. http://www.stfc.ac.uk/resources/pdf/ astriumpresentation.pdf. EADS astrium. Feb 2008. 63 [SoCDesign ] Core Based SOC Design. Prof. Anish Goel. [FPGAEX ] FPGA Prototyping By VHDL Examples. PONG P. CHU. John Wiley and Sons, Inc. 2008. [VHDL2004 ] Circuit Design with VHDL. Volnei A. Pedroni. Massachusetts Institute of Technology. 2004. [Jhon89 ] Design and analysis of Fault-Tolerant Digital System. B. Johnson. AddisonWesley. 1989. [OCD2003 ] Introduction to On-Chip Debug. Arnold Berger, Michael Barr. February 2003.

Facultad de Matemática, Astronom´ıa y F´ısica

Documentos relacionados

Productos

Apoyo

Facultad de Matemática, Astronom´ıa y F´ısica

Documentos relacionados

Añadir este documento a la recogida (s)

Añadir a este documento guardado

Sugiéranos cómo mejorar StudyLib