Download Métodos de depuración HW-SW para sistemas on chip

Métodos de depuración HW-SW para sistemas on chip
reconfigurables.
Guillermo Talavera1, Vincent Nollet2, Jean-Yves Mignolet2, Diederick Verkest2, Serge
Vernalde2, Rudy Lauwereins2 and Jordi Carrabina1
1
Universidad Autónoma de Barcelona,
[email protected]
http://www.uab.es
2 IMEC vzw, Kapeldreef 75, B-3001 Leuven, Belgium
[email protected]
http://www.imec.be
Abstract. El dinamismo de las aplicaciones en sistemas on chip reconfigurables requiere un eficiente uso de los recursos disponibles. Para permitir la asignación en
tiempo real de los recursos, el sistema operativo y la plataforma SoC reconfigurable
han de estar diseñadas en paralelo. En este contexto, el desarrollo del hardware y
software encastado presenta los inconvenientes individuales de cada uno, más la dificultad añadida de la interacción entre los dos y la plataforma. En este artículo presentamos un módulo de depuración software y un sniffer de hardware que ayudan al desarrollo de aplicaciones decrementando el tiempo empleado en determinar el origen
del problema.
1 Introducción
Actualmente están apareciendo multitud de aplicaciones multimedia en dispositivos portátiles como teléfonos móviles. Este tipo de aplicaciones, como lectores de mp3 y decodificadores mpeg, requieren hardware acelerador dedicado para satisfacer sus necesidades computacionales y la flexibilidad del software. El uso encastado de un procesador y de una
FPGA proporciona un buen punto medio entre flexibilidad y potencia de cálculo [1].
En este contexto, en el que el desarrollo del hardware y el software coexisten, la depuración y test del sistema es un proceso que requiere un tiempo, recursos y coste significativos
del proceso de desarrollo [6]. El éxito en la depuración de errores depende mayormente en
la experiencia del ingeniero y a menudo el proceso conlleva pasos iterativos de ensayo y
error. En el caso del desarrollo en paralelo de hardware y software, la dificultad se incrementa considerablemente dado que hay que añadir a la dificultad inherente de cada tipo de
desarrollo, la interacción entre hardware y software y la de ambos con el resto de la plataforma. Ejecutar el código en la plataforma final ayuda considerablemente a detectar errores
debidos a la ejecución en condiciones reales del sistema y a la interacción entre hardware y
software. La detección de estos errores bajo simulación puede ser muy difícil o imposible
de detectar. Tener potentes herramientas de depuración en la plataforma final suele ser
imposible debido a la falta de recursos.
En este artículo presentamos dos herramientas de depuración que ayudarán a los ingenieros de desarrollo a determinar y establecer el origen del error, ya sea este un error del
hardware o del software.
2 Plataforma y escenario
La plataforma de nuestra arquitectura esta compuesta por uno o varios microprocesadores,
ASICs y hardware reconfigurable. El objetivo que buscamos es conseguir en nuestro hardware reconfigurable la ejecución simultánea de diferentes tareas independientes y que sea
posible añadir o quitar tareas sin afectar al resto de ellas.
2.1 Hardware reconfigurable
Actualmente, algunas FPGAs permiten reconfiguración parcial y dinámica, como es caso
de la familia Xilinx Virtex II. En este tipo de FPGAs, diferentes partes de una aplicación, o
diferentes aplicaciones pueden ser mapeadas en el mismo hardware. Estas FPGAs reconfigurables dinámicamente permiten reconfigurar una parte de la FPGA mientras que el resto
prosigue con su ejecución normal.
2.2 Plataforma
Nuestra plataforma de trabajo esta compuesta por una PDA iPaqTM con un sistema operativo de tiempo real, linux RTAI, que se ejecuta en su procesador Strong Arm SA1110 (206
MHz) y una placa de desarrollo que contiene una FPGA Virtex IITM XC2V6000 de Xilinx.
La placa y la PDA están conectadas mediante el puerto de expansión de la iPaq y el sistema
completo está conectado a un PC a través del puerto serie de la PDA. La figura 1 muestra
nuestra plataforma de trabajo.
Figura 1: La plataforma
2.3 Arquitectura de red
En una FPGA, realizar un completo place and route para cada reconfiguración puede requerir un tiempo considerable. Para evitar este overhead, hemos creado una capa intermedia con una topología fija (figura 2). En esta arquitectura establecida cada uno de las áreas,
llamadas tile, puede ser reconfigurada independientemente. Entre cada una de estas áreas,
existe una red que permite la comunicación entre ellas y con el resto de procesadores[4].
Esta separación entre comunicación y computación permite la inserción de nuevos bloques
de funcionalidad en el sistema. Esta partición nos permite tener más flexibilidad y control
de nuestra área reconfigurable y permite que en cada tile se ejecute una tarea hardware.
Figura 2: Topología de la arquitectura
2.4 Sistema operativo
En esta plataforma, hay un sistema operativo de tiempo real para gestionar la multitarea
hardware y software. Cada aplicación contiene una combinación de tareas que pueden
ejecutarse en los recursos disponibles. Cuando una nueva tarea comienza o acaba, el resto
de las tareas pueden reubicarse para proporcionar una mayor potencia de cálculo o bajar el
consumo.
Aplicado a nuestra arquitectura, la creación o destrucción de una tarea consiste en el
habitual manejo de tareas en software y en reconfigurar la FPGA en caso de una tarea
hardware. Migrar una tarea entre hardware y software, es considerablemente más complejo.
El problema principal es el de encontrar un estado de equivalencia entre la tarea hardware y
software en el que poder realizar el cambio sin que se altere el comportamiento del sistema.
En sistema operativo tiene que ser capaz de controlar los recursos disponibles, la situación
de cada tarea y la comunicación entre tareas.
Como se muestra en la figura 3, la comunicación (por paso de mensajes) puede existir
comunicación entre:
- dos tareas en hardware
- dos tareas en software
- una tarea hardware y una software
La red de comunicaciones existente en la FPGA permite la comunicación entre tareas
hardware. El sistema operativo ha de mantener actualizada en tiempo de ejecución la información sobre la situación de cada tarea, y la red ha de conducir el mensaje hasta el destino correspondiente.
Cuando una tarea hardware quiere comunicarse con una tarea software, o viceversa, el
mensaje se envía a una tile interfaz que se encargara, mediante buffers, del paso de mensajes a la FPGA o al microprocesador.
Figura 3: Comunicación hardware-software
3 Técnicas de depuración software
Típicamente, un sistema operativo de tiempo real (RTOS) linux es una extensión del sistema operativo situada entre el sistema operativo y el hardware que crea una máquina virtual y permite que Linux continúe ejecutándose como si de otra tarea de tiempo real se
tratara. El RTOS de nuestra plataforma es una extensión pública de linux llamada RTAI,
más otra extensión de tiempo real para adaptarse a las necesidades de nuestro sistema [2].
El módulo de depuración es un módulo de tiempo real que se encuentra situado entre el
RTAI y nuestra extensión como muestra la figura 4.
El módulo de depuración se puede cargar en tiempo de ejecución y proporciona la mayor parte de las funcionalidades requeridas para la depuración de software. La funcionalidad principal del módulo está basada en la función estándar printk pero proporciona información extra de forma automática acerca del thread, linea y función ejecutada y un nivel de
depuración ajustable.
Durante el desarrollo del código tanto sea de las aplicaciones como del RTOS, los ingenieros deben añadir en su código sentencias de depuración con un parámetro de nivel, como por ejemplo: dbg(3,"Sending a message on port %d\n", port_id);
T1
RT1
RT2
T2
T3
Linux kernel
RT3
“
“RT
extension”
I/O
Debug
Direct
HW
access
RT extension
I/O
HW
Figura 4: Sistema operativo de tiempo real:
Añadiendo el parámetro de depuración, 3 en el ejemplo, cuando estemos depurando
nuestro código, si el valor de depuración deseado por el usuario es superior al nivel de
depuración de la sentencia, la sentencia de depuración se mostrará por pantalla. Además de
poder elegir el nivel de profundidad de la información, podremos elegir las funciones,
threads o archivos que sean depurados, y veremos solo la información correspondiente a
nuestros objetivos. Toda esta información se puede elegir de forma independiente.
Para tener un criterio común, hemos propuesto una serie de niveles de depuración en la
tabla siguiente:
Level
0
1
2
3
4
5
6
7
8
9
TABLA I: NIVELES DE DEPURACIÓN
Action
Es el nivel por defecto, nada ningún tipo de información
se muestra por pantalla.
Muestra cuando los módulos de tiempo real son añadidos o quitados del sistema.
Libre para el uso del ingeniero.
Muestra las entradas y salidas de las funciones.
Libre para el uso del ingeniero.
Muestra las entradas y salidas de las funciones con los
parámetros correspondientes.
Libre para el uso del ingeniero.
Libre para el uso del ingeniero.
Libre para el uso del ingeniero.
Muestra todo, paso a paso.
Esta forma de depuración, basada en la función básica de impresión por pantalla es muy
útil y suele ser el primer impulso de todos los ingenieros, pero a menudo más funcionalidades son requeridas. Suele ser útil cambiar en tiempo de ejecución una o más funciones para
darles una determinada funcionalidad durante un cierto lapso de tiempo. Supongamos que
la comunicación entre procesos (IPC) entre dos tareas en software esta fallando. En este
caso, el módulo de depuración permitiría cambiar en tiempo de ejecución las funciones
send_message() y receive_message() que son las encargadas de enviar y recibir mensajes
respectivamente. Substituyendo estas funciones por otras que permitan almacenar los mensajes enviados y recibidos, podríamos efectuar un análisis posterior a la ejecución del
código.
El módulo de depuración contiene los punteros a las funciones originales y de depuración, y permite en caso requerido el cambio entre unas y otras. La ventaja principal de esta
forma, más elaborada que la explicada anteriormente, es que reduce el exceso de código
innecesario durante la mayor parte del tiempo y permite disponer de una información mucho más detallada.
4 Técnicas de depuración hardware
Las aplicaciones multimedia intercambian un gran número de mensajes y son no determinísticas por naturaleza. Como consecuencia, simular una aplicación completamente no es
posible en un tiempo razonable. Ya que la aplicación no puede ser simulada, un analizador
lógico encastado podría proporcionar la información necesaria para depurar la aplicación.
Sin embargo un analizador lógico trabaja a nivel físico y proporciona una enorme cantidad
de información, ciertamente innecesaria.
La solución ideal está en un nivel superior de abstracción y muestra el comportamiento
de la aplicación sin mostrar la infraestructura subyacente [7]. El siguiente sniffer fue la
solución adoptada para proporcionar una herramienta de depuración de las aplicaciones en
hardware.
Un sniffer es un monitorizador de red que captura los paquetes de datos y los decodifica
teniendo conocimiento de los protocolos presentes en la red. Este sniffer nos ayudará a
visualizar los mensajes enviados a través de la red presente en la FPGA. Esta opción, combinada con las herramientas de desarrollo y depuración convencionales es suficiente para
detectar si las tareas hardware están enviando y recibiendo los paquetes esperados.
Cada tarea, hardware o software, ejecutada en el sistema tiene asociada una dirección
lógica. Al asignar una tarea a un recurso físico, el sistema operativo actualiza la dirección
física y ha de mantiene la coherencia entre las direcciones lógicas y físicas para poder traducir de las unas a las otras y viceversa [3],[5].
Cuando una tarea envía un mensaje a otra, lo hace a través de un puerto lógico que esta
conectado al receptor, y es el sistema operativo que hace la traducción entre estos puertos
lógicos y los físicos reales. En la FPGA, cada tile dispone de un router que tiene una tabla
de destinos donde se encuentran las direcciones físicas de cada dirección lógica. Cada vez
que una tarea aparece, desaparece o cambia de ubicación el sistema operativo manda una
señal de actualización a las tablas de conexionado y se mantiene la coherencia de la comunicación.
Nuestro sniffer hardware permite elegir una tile y un puerto. Cuando una comunicación
se quiere capturar, el sniffer crea un backup de la tabla de conexionado y la modifica de
manera que la comunicación seleccionada se envía al sistema operativo donde se almacena
como se muestra en la figura 5.
SW
C
SW
A
Interface
C
A
Interface message copied!!
B
HW
D
B
D
HW
Figura 5: La comunicación: a) normal, b) usando el sniffer.
La comunicación entre dos tareas en software se puede realizar mediante el método de
substitución de funciones explicado en el apartado anterior. En el caso de una comunicación entre hardware y software, se puede usar cualquiera de los dos métodos explicados, ya
sea el cambio dinámico de funciones o el sniffer hardware o los dos para asegurar que lo
que envía uno es realmente lo que recibe el otro.
5 Interacción con el usuario
En linux existe un mecanismo de comunicación entre el kernel y sus módulos y los procesos: el “/proc file system” [8], [9]. Creando apropiadamente entradas en este sistema de
ficheros virtual, se puede pasar o recibir información del usuario los módulos de sistema
operativo y viceversa. Después escribiendo en los ficheros propios de cada módulo, se
puede interactuar con ellos ya sea para pasar una orden o para leer los datos de depuración
pertinentes. Para facilitar la interacción entre el usuario y los ficheros, hemos desarrollado un par de scripts.
6 Resultados y conclusiones
La depuración de errores es un proceso largo y tedioso que se hace especialmente arduo
si en el desarrollo intervienen diferentes personas en la misma plataforma. Las herramientas creadas ayudan en el desarrollo conjunto de software y hardware simplificando considerablemente la tarea de buscar fallos.
La implementación del módulo de depuración hardware tiene 782 líneas de código en
lenguaje C y ocupa 12kb después de la compilación. El sniffer en hardware ocupa 237
(sobre 1085) líneas de código en C y 5 kb (sobre 22 kb del módulo de control del hardware) después de la compilación. El sniffer no usa recursos hardware pero aumenta la comunicación en la red ya que los mensajes se envían a la tile interfaz donde se envia al sistema
operativo y se copia en el /proc file system antes de ser enviada al destino final. Con métodos apropiados de control [10], se puede reducir este overhead llegando a ser casi nulo.
La utilización conjunta de estas dos herramientas, junto con las convencionales de desarollo de hardware y software, aseguran un rápido de desarrollo.
References
[1]
- V. Nollet, J-Y. Mignolet, T. A. Bartic, D. Verkest, S. Vernalde, R. Lauwereins: ”Hierarchical Run-Time
Reconfiguration Managed by a Operating System for Reconfigurable Systems”. Proceedings of the International Conference on Engineering Reconfigurable Systems and Algorithms 2003, Las Vegas, June 2003
[2] - V. Nollet, P. Coene, D.Verkest, S. Vernalde, R. Lauwereins: “Designing an Operating System for a Heterogeneous Reconfigurable SoC”. Proceedings of the RAW'03 workshop, Nice, April 2003
[3] - J-Y. Mignolet, V. Nollet, P. Coene, D.Verkest, S. Vernalde, R. Lauwereins: “Infrastructure for Design and
Management of Relocatable Tasks in a Heterogeneous Reconfigurable System-on-Chip”. Proceedings of the
DATE'03 conference, Munich, March 2003
[4] - T. Marescaux, A. Bartic, D. Verkest, S. Vernalde, R. Lauwereins: “Interconnection Networks Enable FineGrain Dynamic Multi-Tasking on FPGAs”. Proceedings of the 12th International Conference on FieldProgrammable Logic and Applications, pages 795-805, Montpellier, September 2002
[5] - J-Y. Mignolet, S. Vernalde, D. Verkest, R. Lauwereins: “Enabling hardware-software multitasking on a
reconfigurable computing platform for networked portable multimedia appliances”.
Proceedings of the
International Conference on Engineering Reconfigurable Systems and Algorithms 2002, pages 116-122, Las
Vegas, June 2002.
[6] T. Akgul et al: “A Debugger RTOS for Embedded Systems”. 27th Euromicro Conference 2001: A Net
Odyssey (euromicro'01) September 04 - 06, 2001. Warsaw, Poland
[7] - Paul S. Graham: ”Logical Hardware Debuggers for FPGA-based Systems”. (Thesis). A dissertation submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of
Doctor of Philosophy. December 2001.
[8] - Alessandro Rubini:”Linux Device Drivers”. Ed: O’Reilly, 1998
[9] -Ori Pomerantz: “ Linux Kernel Module Programming Guide”. 1999 (Free distribution)
[10] J. Duato, S. Yalamanchili, L. Ni: “Interconnection networks, an engineering approach”. September 1997.
ISBN 0-8186-7800-3.