TUTORIAL - Sistemas Embebidos Avanzados en FPGAs
Sergio Lopez-Buedo
Escuela Politécnica Superior Universidad Autónoma de Madrid
Francisco Tomás y Valiente, 11 28049 Madrid, España [email protected]
Resumen. La rápida evolución de las FPGAs en los últimos años ha permitido que en la actualidad estos dispositivos sean plataformas ideales para la implementación de sistemas embebidos. No sólo el hardware ha mejorado sustancialmente, sino que se han desarrollado potentes herramientas que permiten que en pocos días de trabajo se pueda tener un sistema completo funcionando. Hoy en día estamos en un momento donde el desarrollo de sistemas embebidos basados en FPGAs ya está plenamente asentado, y ahora el reto está en cómo sacar el máximo partido a estos sistemas: codiseño HW/SW, multiprocesamiento a nivel de chip, sistemas autorreconfigurables, etc… En este tutorial se hace un repaso de las alternativas que existen en la actualidad para el desarrollo de sistemas embebidos basados en FPGAs, en especial para los dispositivos de Xilinx, y se ofrece una guía para el diseñador/a que quiera explorar las nuevas tecnologías en esta área:
multiprocesamiento y autorreconfiguración.
1. Introducción
Las FPGAs han sabido aprovechar muy eficientemente el desarrollo exponencial en la tecnología de fabricación de los circuitos integrados. De hecho, su regularidad hace que sean circuitos relativamente fáciles de implementar y por eso estos dispositivos son siempre de los primeros en hacer uso de los nuevos nodos de fabricación [1].
Así, en unos pocos años los dispositivos programables han pasado de ser mera lógica de soporte (glue-logic) a convertirse en medio para construir completos sistemas en un chip, apareciendo así términos como CSoC (configurable system-on-a-chip [2]) o SoPC (
system-on-a-programmable-chip [3]). Hoy en día ya no sorprende encontrar una FPGA donde se haya implementado un sistema embebido con un procesador, varios buses y periféricos, y hasta algún tipo de aceleración hardware. De hecho, no sólo Xilinx y Altera, los dos grandes fabricantes de FPGAs, ofrecen soluciones para el desarrollo de sistemas embebidos. Otras compañías más pequeñas tienen también productos en este campo, como Actel [4] y Quicklogic [5], e incluso existen soluciones libres (open source): LEON y OpenRISC/Wishbone [6].
Existen dos estrategias para implementar la pieza clave del sistema embebido: el procesador.
La más habitual es implementarlo usando los recursos lógicos de propósito general de la FPGA, partiendo de una netlist o de una descripción HDL comportamental que se sintetiza. Este tipo de procesadores se llaman soft, en contraposición con los dispositivos que ofrecen periféricos y procesadores hard, esto es, embebidos en el silicio. Un buen ejemplo de este segundo tipo es la familia Virtex-4 FX de Xilinx, que dispone de cores PowerPC y MACs de Ethernet. Pero en cualquier caso, que una FPGA disponga de un procesador hard no impide que se pueda utilizar la alternativa soft: simplemente es un malgasto de recursos. En la actualidad, mientras que Xilinx sigue apostando tanto por procesadores hard (PowerPC) como soft (MicroBlaze), Altera abandonó su familia Excalibur (con cores hard ARM9) y está en este momento centrada en su procesador soft Nios-II.
Una de las ventajas de las FPGAs en el campo de los sistemas embebidos es que sus recursos lógicos programables son un medio ideal para implementar aceleradores hardware [7][8][9].
Prácticamente desde los comienzos de la tecnología FPGA se han venido publicando trabajos donde uno de estos dispositivos hace de
coprocesador externo para un procesador de propósito general [10]. Más recientemente, según han ido creciendo las capacidades de los circuitos programables, han comenzado a aparecer trabajos donde tanto el procesador como el acelerador HW se implementan en una misma FPGA [11][12][13][14][15].
Por otro lado, la aceleración HW resulta muy atractiva en los sistemas embebidos, pues por diversas limitaciones (coste, consumo, etc…) los procesadores que se emplean en estos sistemas tienen unas prestaciones más bien modestas [7][8][9]. Todo esto explica las facilidades que están apareciendo para el desarrollo de estos aceleradores en FPGAs, desde interfaces para coprocesamiento en los procesadores a herramientas que son capaces de detectar las secciones críticas del código y traducirlas de C a HW.
Sin embargo, la aceleración HW también tiene sus limitaciones. En primer lugar, se pierde la versatilidad del SW, pues la actualización de los algoritmos implica un rediseño y nueva implementación del hardware. Adicionalmente, el área de la FPGA se puede gastar muy rápidamente si se tiene que soportar la ejecución HW de varios algoritmos. Y además esta será un área muy desaprovechada, porque típicamente sólo uno de los coprocesadores HW estará activo, el correspondiente con el algoritmo que se esté ejecutando en ese momento, y el resto permanecerán inactivos, malgastando recursos del dispositivo [13][14].
Pero todos estos problemas de la aceleración HW se pueden resolver en FPGAs usando reconfiguración en tiempo de ejecución, más en concreto con sistemas autorreconfigurables. Si bien esta es una metodología de diseño todavía poco madura, ya existen trabajos que muestran claramente las ventajas de esta técnica, en particular cómo se puede conseguir una versatilidad similar al SW sin incurrir en penalizaciones de área [14][15][16].
Finalmente, uno de los puntos más chocantes para el diseñador que comienza a desarrollar sistemas embebidos basados en FPGAs es lo pequeños que son los cores de los procesadores.
De hecho, incluso en FPGAs muy modestas se pueden incluir dos o más procesadores sin problemas, lo que, como es obvio, abre la puerta al multiprocesamiento a nivel de chip. Junto con la reconfiguración, este es el otro punto que más
interés está suscitando en la investigación en el campo de los sistemas embebidos basados en FPGAs. En este caso, las dificultades vienen principalmente de las herramientas (compiladores, sistemas operativos, etc…) que permitan aprovechar al máximo el paralelismo. Aunque usando las herramientas comerciales de los fabricantes es relativamente fácil crear un sistema embebido con varios procesadores, conseguir que todos ellos trabajen en paralelo para obtener incrementos sustanciales en las prestaciones es todavía un trabajo que exige muchas horas de programación y que tiene un bajo nivel de automatización.
En este tutorial pretende servir de introducción práctica a todos los temas tratados anteriormente. En primer lugar se ofrecerá un resumen de la metodología de desarrollo, para luego presentar un ejemplo concreto: Xilinx EDK.
A continuación se presentarán otras alternativas, tanto comerciales (Altera) como de código abierto (LEON). Más adelante se indicará como usar aceleración HW y cómo se pueden desarrollar hoy en día sistemas autorreconfigurables sobre dispositivos comerciales (en particular, sobre FPGAs de Xilinx). Finalmente se presentará una breve introducción acerca del estado del multiprocesamiento a nivel de chip en la actualidad.
2. Metodología de diseño
La aproximación más empleada en la actualidad en el desarrollo de sistemas en un chip es la llamada diseño basado en plataforma [17], esto es, partir de una plataforma HW/SW de referencia que se va adaptando a los requerimientos del proyecto. De una manera más formal, es una metodología de diseño compuesta por una librería de componentes virtuales y un marco arquitectural, en la que se ofrece un conjunto de componentes HW y SW, modelos, herramientas EDA y software que facilitan el diseño rápido de los sistemas [18].
El diseño basado en plataforma no se puede catalogar ni como metodología bottom-up ni top- down, es de tipo meet-in-the-middle: se comienza a partir de una plataforma de referencia. A partir de aquí se sigue un flujo de diseño descendente cuando la plataforma se adapta a nuestras necesidades, implementando por ejemplo
periféricos a medida, y se sigue un flujo ascendente cuando se desarrolla la aplicación que se ejecutará en la plataforma [19].
La plataforma HW se compone de una librería de periféricos, buses y procesadores, que el diseñador instancia para crear su sistema. Los buses son unos elementos clave, pues de su funcionamiento dependerá en buena parte las prestaciones del sistema. Hay que olvidar el concepto de bus como si fuera un backplane pasivo, en los sistemas en un chip se acomodan más al concepto de bus fabric, esto es, de un circuito activo que realiza la interconexión de todos los elementos del sistema. Así, los buses están compuestos por multiplexores, registros de segmentación y lógica de arbitraje. Lo más habitual es que cada fabricante tenga al menos dos estándares de buses, uno de bajas prestaciones pero más sencillo de usar, y otro más complejo pero que permita mayores velocidades. Ejemplos de esto son OPB y PLB en IBM CoreConnect (descritos en el punto 3.1), APB y AHB en ARM AMBA, etc…
Por otro lado, la plataforma debe contener una librería lo más grande posible de periféricos, que se conectarán a los buses estándares descritos en el párrafo anterior. Y por supuesto, también dispondrá de uno (o varios) cores de procesadores. Pero el lado HW del diseño basado en plataforma no sólo se queda en la existencia de unos componentes estándares que nos permitan construir nuestro SoC, debe haber una herramienta que automatice el proceso de construcción y que abstraiga al diseñador de los detalles de interconexión de los componentes. El resultado final es una netlist o una descripción HDL que se sintetiza e implementa usando las herramientas estándar del fabricante.
En el lado SW, el diseño basado en plataforma lo que proporciona es una serie de librerías y drivers que permitan manejar el HW que se ha desarrollado. El nivel de abstracción es variable, puede ir desde proporcionar sólo los drivers para los periféricos hasta que ofrezca un sistema operativo compilado a medida del diseño que se ha realizado. En cualquier caso, lo que ofrecen las herramientas de diseño basado en plataforma es el punto de partida sobre el que empezar a desarrollar el SW. Hay que remarcar que el diseño basado en plataforma es adecuado sólo para aquellos modelos de negocio donde el valor añadido esté en el SW que corre el sistema. El
HW no es más que una adaptación de la plataforma estándar, como mucho se habrá realizado algún periférico a medida. Pero esto por si sólo no será suficiente para distinguirse de la competencia: el atractivo del producto dependerá del SW que ejecute [20].
3. Xilinx EDK
La herramienta de Xilinx para el desarrollo de sistemas embebidos es el EDK, Embedded Development Kit. Es un completo sistema de desarrollo basado en plataforma, que integra en el mismo IDE tanto el desarrollo HW como SW.
3.1. Buses CoreConnect
El estándar de buses que se emplea en EDK para la interconexión de los componentes del sistema es el CoreConnect de IBM. Este estándar describe varios tipos de buses, aunque los más utilizados son OPB (On-Chip Peripheral Bus) y PLB (Processor Local Bus). OPB es la alternativa más simple, y ofrece soporte para arbitraje entre varios maestros y un sencillo mecanismo para transferencias en ráfaga, aunque no se puede llegar a una transferencia por cada ciclo de reloj.
PLB resuelve las limitaciones de OPB, ofreciendo ráfagas con velocidades reales de 1 transferencia por ciclo de reloj. Además permite escrituras y lecturas concurrentes, y dimensionamiento dinámico de las transferencias. La tasa de transferencia típica en OPB es de 167 MBps, mientras que en PLB se llega a 533 MBps [21].
Sin embargo, el área ocupada por el bus fabric de PLB puede ser 4 veces superior a OPB.
El montaje más estándar es conectar un procesador de altas prestaciones (PowerPC) con los periféricos más exigentes (memoria, Ethernet) a través de PLB, y luego usar un puente PLB-OPB para conectar a través de este segundo bus los periféricos más sencillos (Timer, UART, controlador de interrupciones, etc…).
3.2. MicroBlaze
MicroBlaze es un sencillo procesador RISC de 32 bits, con una arquitectura muy clásica:
• Arquitectura Harvard con 32 registros de propósito general
• Instrucciones de 32 bits con sólo dos formatos: para direccionamiento registro- registro o registro-inmediato
• Acceso a memoria sólo a través de instrucciones Load/Store
• Pipeline de cauce único y tres etapas
• Una línea externa de interrupción, más excepciones HW (opcode ilegal, errores de bus, etc…), puntos de ruptura e interrupciones SW
En la Fig. 1 se muestra el diagrama de bloques de MicroBlaze. La principal característica es que un core altamente configurable, muchas de sus unidades pueden añadirse o no dependiendo del código que se vaya a ejecutar y cuales sean las prestaciones que se necesita alcanzar:
Multiplicador, División, FPU, barrel shifter, etc…
Con respecto al tamaño y prestaciones de MicroBlaze, lo primero que hay que destacar es que es un diseño altamente optimizado por Xilinx
para sus FPGAs, por lo que se puede asegurar que es el procesador soft que mejor relación área/prestaciones tiene en este fabricante [23].
Xilinx anuncia velocidades máximas desde 100 MHz (Spartan-3) hasta 200 MHz (Virtex-4), que se corresponden con prestaciones en el orden de 100-150 dhrystone MIPS (si bien cifras mas reales, con buses cargados, suelen ser un 30-40%
menores). Por otro lado, el área ocupada está entre 900-2600 LUTs, dependiendo de la configuración.
Otra de las posibilidades de adaptación de MicroBlaze viene de los buses. El procesador usa dos tipos: LMB, que hace de interfaz sin estados de espera con la memoria BlockRAM (embebida en la FPGA), y OPB. Mientras que sendos buses LMB de instrucciones y datos son siempre necesarios para que el procesador pueda arrancar, los buses OPB pueden o no añadirse, pudiendo haber sólo un bus de instrucciones, o dos de instrucciones y datos, o uno compartido de instrucciones y datos, etc…
A parte de los buses LMB y OPB para la conexión de memorias y periféricos, MicroBlaze dispone de un tercer tipo llamado FSL que se emplea para mover datos desde/hacia el banco de registros a alta velocidad. El objetivo es servir de interfaz con coprocesadores que aceleren por HW diversas tareas, como se verá en el punto 5.
Figura 1. Diagrama de bloques de MicroBlaze [22]
Los sistemas MicroBlaze normalmente disponen de una pequeña memoria BlockRAM sólo para el arranque, mientras que el código se ejecuta desde SDRAM o DDR. En este caso, las prestaciones se ven muy favorecidas (no es raro encontrar aceleraciones del orden 5-10x) añadiendo una memoria caché. La caché es muy sencilla, de correspondencia directa y de una (conexión OPB) o cuatro palabras por línea (usando el bus dedicado XCL).
Finalmente, MicroBlaze dispone de una interfaz de depuración basada en JTAG que permite establecer un número variable de puntos de ruptura por instrucciones o datos, ejecutar paso a paso, acceder a los registros y a la memoria, etc…
Se gestiona a través del periférico MDM, que instancia el acceso interno de la FPGA al puerto JTAG (celda BSCAN) y además implementa una UART y un acceso de alta velocidad a la memoria de MicroBlaze a través del bus FSL.
3.3. PowerPC-405
Las familias de Xilinx de altas prestaciones Virtex-II Pro y Virtex-4 FX disponen de procesadores PowerPC-405 embebidos en el silicio. No sólo su frecuencia de operación es mayor (450 MHz) que la de MicroBlaze, algo lógico al tratarse de un core hard, sino que dispone de una arquitectura más sofisticada con la que se consiguen mejores rendimientos (700 dhrystone MIPS). Entre sus principales características hay que destacar:
• Arquitectura Harvard de 32 bits con 32 registros de propósito general
• Instrucciones MAC (multiplicar y acumular)
• 3 timers integrados (incluyendo watchdog)
• Memorias caché separadas de instrucciones y datos, de 16 KB y asociativas por 2 vías, con 8 palabras por bloque
• Pipeline de 5 etapas
• Modos privilegiado y de usuario
Otra de las ventajas de PowerPC-405 es que dispone de MMU. Es un diseño muy sencillo, basado en un TLB de 64 entradas gestionado por SW, pero que es suficiente como para que se puedan implementar los mecanismos de protección de memoria que necesitan los sistemas operativos como Linux. MicroBlaze y otros procesadores sin MMU deben recurrir a versiones reducidas como uCLinux.
La interfaz de depuración es similar a la de MicroBlaze, utiliza también JTAG y el periférico MDM, y permite 4 puntos de ruptura de instrucciones y 2 de datos (posiciones o valores).
3.4. Periféricos y librerías
Uno de los puntos fuertes de EDK es el amplio catálogo de cores IP (periféricos), entre los que cabe destacar controladores de memoria Flash/SDRAM/DDR, MACs de Ethernet, timers, UARTs, E/S de propósito general, controladores de interrupciones, etc… tanto para el bus OPB como PLB.
Por el lado del SW se dispone también de un interesante catálogo de librerías que son generadas dinámicamente, a medida del sistema desarrollado. Hay disponibles sockets (lwIP), manejo de sistema de archivos FAT, procesos y threads, profiling, etc… y por supuesto las estándares libc y libm. Todas estas librerías proporcionan un pequeño kernel con las funciones básicas de un sistema operativo, aunque como es obvio no se llega a las prestaciones de Linux o VxWorks.
3.5. Sistema de desarrollo
EDK proporciona un entorno integrado para el desarrollo del HW y SW. La herramienta que ve el usuario es XPS (en la Fig. 2 se puede ver una captura de pantalla), que es un entorno de desarrollo integrado (IDE) que llama a todas las herramientas que integran el EDK. Las principales son platgen y libgen. Platgen genera el código HDL del sistema a partir del archivo MHS, que es el que define la plataforma. Este archivo se puede crear a mano o utilizando los asistentes de XPS, y contiene los elementos que se instancian para crear el sistema, qué parámetros usan y cómo se interconexionan. Una vez generado el código HDL, se implementa en ISE como si de cualquier otro diseño se tratase, sólo que ISE es llamado de una forma transparente de XPS
Por otro lado, libgen genera las librerias para los proyectos SW, usando para ello el toolchain GNU. Libgen necesita dos archivos, el MHS antes mencionado (para saber de qué se compone el sistema) y el nuevo MSS, que contiene que librerías se deben incluir y como se deben configurar, a parte de otros parámetros del SW.
XPS no sólo permite el desarrollo de la plataforma (HW y librerías SW), sino que ofrece la posibilidad de compilar aplicaciones sencillas, para ello ofrece un editor de C, además de proporcionar la posibilidad de generar automáticamente los Makefiles y llamar de una manera transparente a GCC. Una vez implementada la plataforma, generadas las librerías y compilada la aplicación, el último paso es juntarlo todo, embebiendo el código ejecutable de la aplicación en las BlockRAM que se han reservado en el sistema para guardar el código.
Para ello se usa bitinit, que utiliza la herramienta Data2MEM de ISE para modificar los contenidos de las BlockRAM.
Para desarrollos SW más complejos se proporciona un entorno de desarrollo más complejo, el Xilinx Platform Studio SDK, basado en la herramienta abierta Eclipse. Con respecto a la depuración, simgen se encarga de crear modelos de simulación (funcional o post-layout) del sistema. XMD (Xilinx Microprocessor Debugger) implementa la unión entre el puerto JTAG de depuración del procesador y una herramienta de alto nivel como puede ser gdb.
Finalmente, vpgen genera una plataforma virtual (por ahora sólo para sistemas MicroBlaze) con un
modelo de simulación a nivel de ciclo, mucho más rápido que los modelos HDL.
4. Alternativas
Altera ofrece una herramienta para el desarrollo de la plataforma HW, el SOPC Builder, y un entorno de desarrollo SW basado en Eclipse.
Como ya se comentó en la introducción, Altera en la actualidad sólo apuesta por su procesador soft, Nios-II. Es un diseño bastante similar a MicroBlaze, con la salvedad de que hay tres modelos diferentes: economy, standard y fast, lo que permite hacer un ajuste preciso en el compromiso área/velocidad, desde el modelo fast con pipeline de 6 etapas y predicción dinámica de saltos, hasta el modelo economy que no tiene segmentación. Las interconexiones se realizan con el bus Avalon, un producto propietario de Altera que ofrece prestaciones a medio camino entre PLB y OPB.
Por otro lado existen también alternativas de código abierto, entre las cuales se puede destacar LEON3, de Gaisler Research. Es un procesador compatible con SPARC v8, que dispone de probablemente de la arquitectura más sofisticada Figura 2. Captura de pantalla de XPS
de entre todas las alternativas soft-core disponibles en la actualidad:
• Pipeline de 7 etapas, lo que proporciona velocidades de hasta 125 MHz en FPGAs
• Unidades HW para multiplicación, división y MAC, además de una unidad de coma flotante compatible IEEE-754
• Memorias caché separadas para instrucciones y datos, asociativas de 1 a 4 vías y con políticas de sustitución configurables
• Interfaz AMBA 2.0 (AHB, con potencia similar a PLB)
• Unidad avanzada de depuración, que incluye trazas de ejecución tanto de datos como de instrucciones
Las ventajas de LEON3 no terminan aquí, es además el único core soft que permite multiprocesamiento simétrico (SMP). Además, existen versiones tolerantes a fallos (LEON surgió como un proyecto de la ESA). La contrapartida con respecto a los sistemas comerciales es que su entorno de desarrollo no es tan amigable, aunque es igualmente muy potente. Para el desarrollo de la plataforma HW hay disponible una aplicación Tcl/Tk que permite instanciar los componentes de una manera gráfica. El desarrollo SW se hace como es habitual con la toolchain GNU, y se proporciona un sencillo kernel multithread con soporte para la librería Pthreads. Se puede además utilizar el entorno de desarrollo Eclipse y hay muchos sistemas operativos portados a LEON:
desde los de tiempo real eCos o RTEMS hasta opciones más complejas como VxWorks o Linux.
5. Aceleración HW
Como ya se indicó en la introducción, existe en la actualidad mucho interés por incluir aceleración HW en los sistemas embebidos basados en FPGAs. No sólo es que la aceleración HW ayuda muy significativamente a mejorar las modestas prestaciones de estos sistemas, sino también que las FPGAs son plataformas ideales para implementar este tipo de aceleración.
Así, todos los procesadores presentados en los puntos anteriores disponen de algún tipo de interfaz para coprocesamiento. Por ejemplo, Nios- II tiene una interfaz para crear nuevas operaciones en la ALU, de tal manera que se puedan definir nuevas instrucciones como una multiplicación modular, o el coseno, etc… Esta interfaz es
conceptualmente similar a la de LEON3, que permite también definir nuevas operaciones que trabajen sobre datos obtenidos del banco de registros del procesador.
Sin embargo, una reciente herramienta de Altera que permite pasar una función C a hardware, el C2H compiler, funciona de una manera completamente diferente. Lo que hace es implementar la versión hardware de la función como un periférico maestro del bus Avalon, que accede a la memoria para obtener los parámetros, trabajar con las variables y escribir los resultados.
O sea, una aproximación más clásica al problema, que tiene la ventaja de poder acceder a la memoria (especialmente útil cuando la función usa punteros) pero que precisamente por esto, por la sobrecarga del acceso al bus Avalon, puede ser que obtenga unos resultados óptimos.
En el caso de MicroBlaze la estrategia es diferente [24]. Como ya se indicó en la descripción de este procesador, es posible añadirle buses FSL que permiten introducir y extraer datos a/desde el banco de registros a alta velocidad. El ancho de estos buses es parametrizable, y además incluyen un bit de control adicional a los datos, que se puede usar para indicar diferentes operaciones, o señalar los límites de los datos, etc… La comunicación FSL entre el procesador y el acelerador se implementa a través de FIFOs que permiten una cierta flexibilidad en la transferencia de datos. Las instrucciones básicas de MicroBlaze para trabajar con FSL son put y get, existiendo variantes para manejar el bit de control, las esperas en la FIFO, etc… En la Fig. 3 se muestran las conexiones del bus FSL.
Por último, de todos los procesadores vistos hasta ahora el único que posee una interfaz real para coprocesador es PowerPC en Virtex-4. Esto
FSL_M_Clk
FSL_M_Data
FIFO
FSL_M_Control FSL_M_Write FSL_M_Full
FSL_S_CLK FSL_S_Data FSL_S_Control FSL_S_Read FSL_S_Exist
Figura 3. Conexiones del bus FSL
es, una interfaz que no sólo permite definir nuevas instrucciones, sino también que esas instrucciones pueden trabajar sobre un banco de registros propio del coprocesador.
En cualquier caso, el punto más importante en la aceleración HW es que existan herramientas que automaticen el proceso. Traducir un algoritmo de C a HDL es siempre un proceso laborioso, y más si hay que adaptarlo a una interfaz de coprocesamiento en particular. Lo ideal sería que existiese una herramienta que permitiese migrar una cierta función del código a HW de una manera transparente, y eso es lo que tratan de ofrecer diversos fabricantes. Ya se ha comentado antes C2H Compiler de Altera, otras soluciones son Impulse-C, Handel-C, etc… Un resumen del estado del arte para los dispositivos de Xilinx se puede encontrar en [25].
6. Sistemas autorreconfigurables
Sin lugar a dudas, el uso más atractivo de la reconfiguración en los sistemas embebidos basados en FPGAs son los sistemas autorreconfigurables. La idea es que el propio dispositivo pueda cambiar secciones de su bitstream de configuración, con lo que el hardware alcanzaría así una versatilidad y adaptabilidad que sólo se proporcionaba hasta ahora el software puro.
Desde un punto de vista hardware, el único requerimiento que hace falta para implementar un sistema autorreconfigurable es un acceso interno al puerto de configuración de la FPGA. Esto es, que desde la propia lógica del dispositivo se tenga acceso al bitstream de configuración. El componente en cuestión se denomina ICAP, disponible a partir de Virtex-II, y es simplemente un acceso interno al puerto de configuración paralelo de la FPGA.
Sin embargo, la no existencia del puerto interno de configuración no impide que se puedan desarrollar sistemas autorreconfigurables:
simplemente hay que hacer estas conexiones externamente para tener acceso a la configuración desde pines de E/S de propósito general. Así se pueden construir sistemas autorreconfigurables en FPGAs no pensadas por el fabricante para esta tarea, por ejemplo Spartan-3
La Fig. 4 muestra como se puede construir un sistema autorreconfigurable basado en
MicroBlaze sobre Spartan-3. El procedimiento es muy sencillo, simplemente hay que hacer 11 conexiones externas desde un puerto de E/S de propósito general (GPIO) hasta el puerto de configuración de la FPGA. Además, como se puede comprobar en la figura, el procedimiento es compatible con la primera configuración de la FPGA al arrancar el sistema: cuando ha terminado, la señal DONE sube a '1', con lo que la memoria de configuración se deshabilita y no existe por lo tanto riesgo de conflicto en la reconfiguración.
6.1. Herramientas para la
autorreconfiguración
El mayor problema a la hora de usar la autorreconfiguración es el pobre soporte de las herramientas de Xilinx. La documentación es escasa y en el flujo de diseño abundan los bugs.
Recientemente Xilinx ha proporcionado un parche para ISE 8.1i que resuelve los problemas que aparecían en versiones anteriores (por ejemplo, en ISE 6.3i era necesario desarrollar una aplicación a medida porque la de Xilinx fallaba [13]).
Esta nueva herramienta de Xilinx utiliza modular design a través de PlanAhead. Modular design ha sido la alternativa clásica de Xilinx para gestionar la reconfiguración, pues permite dividir
Coprocesador Reconfigurable
IO[0]
IO[1]
IO[2]
IO[3..10]
Figura 4. Sistema autorreconfigurable basado en Spartan-3
el dispositivo en áreas rectangulares que se implementan por separado. De esta manera se puede cambiar una cierta zona de la FPGA mientras que el resto se mantiene igual. Además de modular design, hay que usar la directiva PARTIAL_RECONFIG que asegura que el rutado de un módulo quedará confinado al área rectangular que se ha reservado, y se deben usar unas macros hard especiales para la comunicación con un módulo reconfigurable.
6.2. Autorreconfiguración completa del sistema Por autorreconfiguración normalmente se entiende el mecanismo expuesto en el punto anterior, donde el objetivo es mejorar la versatilidad y adaptabilidad del hardware o reducir los requerimientos de área. Sin embargo, existe una alternativa de autorreconfiguración, que es que la FPGA cambie los contenidos de su propia memoria de configuración.
Un CSoC típico estará constituido por una FPGA y una memoria EPROM de configuración, de donde se obtendrá el bitstream cuando arranque el sistema. El objetivo ahora es que los contenidos de esta EPROM puedan ser alterados por la propia FPGA sin necesidad de componentes externos. De esta manera se puede actualizar todo el hardware, ya no en tiempo de ejecución, sino a través de un reinicio del sistema. Por ejemplo, en un sistema que maneje coprocesadores autorreconfigurables, la autorreconfiguracion completa se emplearía para actualizar el procesador y los periféricos del sistema, una parte de la FPGA que no cambia en tiempo de ejecución pero que como todo sistema digital es susceptible de ser mejorado y corregidos sus errores.
La manera de resolver este problema es también conceptualmente sencilla, y usa una idea similar a la expuesta en el caso de la autorreconfiguración en Spartan-3. En este caso se basa en conectar un puerto de E/S de propósito general (GPIO) del sistema a la cadena JTAG de la placa. Puesto que la memoria de configuración se programa a través de JTAG, lo que se consigue así es que la propia FPGA tenga acceso a la configuración. Al igual que en el caso anterior, la mayor dificultad proviene del manejo de las herramientas de Xilinx, aunque en este caso la generación de archivos XSVF junto con la nota de aplicación 58 resuelve el problema.
7. Sistemas multiprocesador
El tamaño de las FPGAs es desde hace unos años suficientemente grande como para que varios cores de procesadores puedan implementarse si mayores problemas uno de estos dispositivos. Esto convierte a las FPGAs en plataformas ideales para explorar los sistemas multiprocesador en un chip, aunque el inconveniente es que la gran mayoría de los procesadores que se hay disponibles no están pensados para trabajar en modo multiprocesador.
De hecho, sólo LEON3 puede funcionar así. El problema viene de que para conseguir un sistema con multiprocesamiento simétrico (SMP) no sólo vale con conectar varios procesadores a un mismo bus, hay que hacer modificaciones en la arquitectura. En particular, hay que habilitar un mecanismo de bus snooping en las memorias cache para evitar que se produzcan incoherencias cuando varios procesadores trabajan sobre los mismos datos. LEON3 es el único que implementa estos mecanismos, y permite de una manera muy sencilla crear sistemas multiprocesador. A nivel sistema operativo se puede usar eCos que soporta SMP.
Sin embargo, las opciones comerciales de los fabricantes de FPGAs (Nios, MicroBlaze, PowerPC) no soportan SMP. Los fabricantes proponen diversas alternativas para utilizar multiprocesamiento con sus cores. Por ejemplo, Altera ofrece unos cores para su Avalon que implementan por hardware una test and set atómico, que resuelve el problema de la exclusión mutua para así evitar incoherencias [26]. Por otro lado, con MicroBlaze se puede implementar una red de procesadores comunicados a través del bus FSL. Puesto que se soportan hasta 8 buses por procesador, se puede pensar en redes de hasta 8 MicroBlaze con conexión directa 1 a 1, o incluso de más si se usan otra topologías [27]. Pero el problema aquí es el desarrollo del software, puesto que esta es una solución propietaria no soportada por ningún sistema operativo, por lo que hay que programar todo el sistema a mano.
Finalmente, el PowerPC de Virtex-II Pro y Virtex-4 FX tampoco soporta SMP, una lástima puesto que existen muchos dispositivos con 2 cores, incluso los hay hasta con 4 procesadores.
Aunque también se puede pensar en soluciones basadas en comunicación local entre procesadores (bien por bus FSL o usando otra alternativa),
Referencias
[1] Richard Goering, "Just how low can FPGAs go?", EETimes, Mar. 2006
[2] J. Becker, "Configurable Systems-on-Chip (CSoC)", 15th Symposium on Integrated Circuits and System Design (SBCCI2002), pp. 379–384, Sept. 2002
[3] Altera Corp., "Investor Relations – Frequent Questions", disponible en www.altera.com [4] Actel Corp., "Core MP7 Product Brief", Abr.
2006
[5] Quicklogic Corp., "QL90xM QuickMIPS Product Brief", 2003
[6] "OpenRISC 1000: Overview", disponible en www.opencores.org
[7] J. Tuley, "Soft Computing Reconfigures Designer Options", Embedded Systems, Abr.
1997
[8] R. Lysecky y F. Vahid, "A Study of the Speedups and Competitiveness of FPGA Soft Processor Cores using Dynamic Hardware/Software Partitioning", Proc.
Design, Automation and Test in Europe (DATE'05), pp. 18-23, Mar. 2005
[9] M. Oullette y D. Connors, "Analysis of Hardware Acceleration in Reconfigurable Embedded Systems", Proc. 12th Reconfigurable Architectures Workshop (RAW 2005)
[10] K. Compton y S. Hauck, "Reconfigurable Computing: A Survey of Systems and Software", ACM Computing Surveys, Vol.
34, Num. 2, pp. 171–210, Jun. 2002
[11] S. Hauck, T. W. Fry, y M. M. Hosler, “The Chimaera Reconfigurable Functional Unit,”
IEEE Transactions on Very Large Scale Integration (VLSI) Systems, Vol. 12, pp.
206–217, Feb. 2004
[12] A. Hodjat y I. Verbauwhede, "High-
throughput programmable cryptocoprocessor", IEEE Micro, Vol. 24,
Issue 3, pp. 34-45, May.-Jun. 2004
[13] I. González, E. Aguayo y S. Lopez-Buedo,
"Sistemas Embebidos Auto-Reconfigurables sobre Spartan-3", V Jornadas Sobre Computación Reconfigurable Y Aplicaciones (JCRA 2005)
[14] K. Brunham y W. Kinsner, “Run-time reconfiguration: towards reducing the density requirements of FPGAs”, Canadian
Conference on Electrical and Computer Engineering 2001, Vol. 2, pp. 1259–1264, May. 2001
[15] K. Compton and S. Hauck, "Reconfigurable Computing: A Survey of Systems and Software", ACM Computing Surveys, Vol.
34, No. 2, pp. 171–210, June 2002.
[16] M. Dyer, C. Plessl, and M. Platzner,
"Partially Reconfigurable Cores for Xilinx Virtex", Lecture Notes in Computer Science 2438, Berlin: Springer-Verlag, 2002, pp.
292-301.
[17] K. Keutzer, S. Mdik, A. R. Newton, J.
Rahaey y A. Sangiovanni-Vincentelli, System level design: Orthogonalization of concerns and platform-based design. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Dic. 2000 [18] Richard Goering, "Platform-based design: A
choice, not a panacea", EETimes, Nov. 2002 [19] Alberto Sangiovanni-Vincentelli, "Defining
platform-based design", EETimes, May.
2002
[20] G. Martin and H. Chang (Eds.), "Winning the SoC Revolution", Kluwer 2003
[21] Xilinx Inc., "Processor IP Reference Guide", EDK 7.1i Documentation, Feb. 2005
[22] Xilinx Inc., "MicroBlaze Processor Reference Guide", EDK 8.1i Documentation, Feb. 2006
[23] Ivan González, "Coprocesadores Dinámicamente Reconfigurables en Sistemas Embebidos basados en FPGAs", Tesis doctoral, Departamento de Ingeniería Informática, Universidad Autónoma de Madrid, Mar. 2006
[24] Xilinx Inc., "Connecting Customized IP to the MicroBlaze Soft Processor Using the Fast Simplex Link (FSL)", Application Note 529, 2004
[25] Milan Saini, "ESL Tools for FPGAs", Xcell 57, Xilinx Inc., 2006
[26] Altera Corp., "Quartus II Handbook Volume 5: Altera Embedded Peripherals", Section 4, Multiprocessor Coordination Peripherals, May. 2006
[27] P. Huerta, J. Castillo, J.I. Martínez, V.
Lopez, "A MicroBlaze based MultiProcessor SoC”, WSEAS Transactions on Circuits and Systems, pp 423-430, May. 2005