por Richard Swan, Anthony Wyatt, Richard Cant, Caroline Langensiepen
Traducción de Fernando Berzal
¿Cansado de tener que actualizar su hardware constantemente para satisfacer las demandas del software más reciente? Pues bien, esto podría ser innecesario en un futuro cercano. La solución de este costoso problema podría ser el hardware reconfigurable. Utilizando una estrategia software, todas las aplicaciones pueden escribirse de forma que reconfiguren el hardware para satisfacer sus necesidades específicas, asegurando así su funcionamiento óptimo.
La computación reconfigurable es un campo de investigación y desarrollo relativamente nuevo: las primeras investigaciones comenzaron a finales de los 80. Se trata de un intento de superar la tradicional desfase entre hardware y software en el campo de la Informática. Existen determinados procesadores diseñados específicamente para una única aplicación (p.ej. un acelerador gráfico 3D) que realizan sus tareas específicas mucho más rápido que un procesador tradicional (de propósito general). Sin embargo, el ordenador de aplicación específica sólo puede realizar esa tarea especializada con velocidad, y otras aplicaciones se ejecutarán deficientemente o ni siquiera eso.
En el pasado se han realizado intentos de mejorar el rendimiento de un ordenador de propósito general añadiéndole algunas capacidades de aplicación específica. La más popular es la adición de instrucciones para realizar operaciones en coma flotante y numéricas. En los últimos años, Intel ha añadido instrucciones para llamadas a procedimientos, matemáticas en coma flotante y gráficos más rápidos. El ordenador reconfigurable intenta convertir el ordenador de propósito general en un sistema de aplicación específica configurando o modificando una parte añadida del hardware para ajustarse a la aplicación actual. Este hardware extra se denomina dispositivo reconfigurable.
Los dispositivos reconfigurables permiten a los diseñadores construir parte o todo su diseño en hardware en vez de software. Exportando funcionalidad al hardware se pueden conseguir significativas mejoras de velocidad porque esa funcionalidad no tiene que dividirse en instrucciones individuales que la C/U. traiga, decodifique, etc.. Esa funcionalidad se convierte en hardware. La capacidad de implementar una aplicación en hardware proporciona la oportunidad de explotar la concurrencia inherente de los circuitos digitales. Es decir, el dispositivo puede configurarse o dividirse en múltiples subsistemas, todos los cuales podrían funcionar concurrentemente con los demás.
En el pasado, los diseñadores de hardware han empleado diagramas y lenguajes de descripción (p.ej. VHDL, que se abordará después) para describir sus diseños, mientras que los diseñadores de software han usado lenguajes de alto nivel y herramientas de diseño. Esto viene originado por el hecho de que las metodologías de diseño de sistemas concurrentes de software tienden a formarse principalmente con construcciones secuenciales, con construcciones concurrentes/paralelas añadidas a posteriori.
Un sistema de cómputo reconfigurable práctico requiere un ordenador principal. El ordenador principal es el sistema de cómputo que utiliza el sistema reconfigurable, controla el acceso a él y lo programa. Existen diversos métodos de conectar el ordenador principal al dispositivo reconfigurable. Al nivel más bajo, el dispositivo se incrusta en el núcleo del microprocesador; al nivel más alto, el dispositivo podría conectarse a través de un cable de conexión [1]. El propio dispositivo es un microchip conocido como Field Programmable Gate Array (FPGA), cuyo tamaño medio actual es de unas 2.5 pulgadas cuadradas. Es este microchip el pilar del campo de la computación reconfigurable.
Las FPGA son el resultado de la convergencia de dos tecnologías diferentes, los dispositivos lógicos programables (PLDs [Programmable Logic Devices]) y los circuitos integrados de aplicación específica (ASIC). La historia de los PLDs comenzó con los primeros dispositivos PROM (Programmable Read-Only Memory) y se les añadió versatilidad con los PAL (Programmable Array Logic) que permitieron un mayor número de entradas y la inclusión de registros. Esos dispositivos han continuado creciendo en tamaño y potencia. Mientras, los ASIC siempre han sido potentes dispositivos, pero su uso ha requerido tradicionalmente una considerable inversión tanto de tiempo como de dinero. Intentos de reducir esta carga han provenido de la modularización de los elementos de los circuitos, como el los ASIC basados en celdas, y de la estandarización de las máscaras, tal como Ferranti fue pionero con la ULA (Uncommitted Logic Array). El paso final era combinar las dos estrategias con un mecanismo de interconexión que pudiese programarse utilizando fusibles, antifusibles o celdas RAM, como los innovadores dispositivos Xilinx de mediados de los 80. Los circuitos resultantes son similares en capacidad y aplicaciones a los PLDs más grandes, aunque hay diferencias puntuales que delatan antepasados diferentes. Además de en computación reconfigurable, las FPGAs se utilizan en controladores, codificadores/decodificadores y en el prototipado de circuitos VLSI y microprocesadores a medida.
El primer fabricante de estos dispositivos fue Xilinx [2] y los dispositivos de Xilinx se mantienen como uno de los más populares en compañías y grupos de investigación. Otros vendedores en este mercado son Atmel, Altera, AMD y Motorola.
Las primeras FPGAs se usaron principalmente para hacer partes de diseños hardware que no correspondían a ningún componente existente en el mercado. Las principales ventajas de su uso eran el reducido número de chips comparado con una implementación con circuitos SSI y la reducida inversión de capital cuando un ASIC a medida era la alternativa. Con el paso del tiempo, los dispositivos disponibles han aumentado en tamaño y de ese modo más aplicaciones han sido posibles. Un uso interesante de esta tecnología es el prototipado de circuitos a medida completos que tienen una compleja estructura interna, como los procesadores. La mayor parte de los fabricantes de procesadores ahora construyen prototipos con FPGAs en algún punto del proceso de diseño. Una de las compañías que utilizan esta tecnología es Argonaut, que emplea FPGAs para prototipar un procesador RISC con instrucciones definidas por el usuario antes de fabricar realmente el diseño final en un ASIC. Para muchas aplicaciones de poco volumen el coste de un ASIC no puede justificarse y por eso existe una tendencia creciente para usar una versión FPGA no sólo como prototipo.
Una vez que la FPGA no es sólo un prototipo surge una interesante posibilidad. Ya que el dispositivo es reprogramable en campo, el diseño no tiene que soportar más la carga de la flexibilidad para tratar con diferentes aplicaciones. En lugar de eso, un diseño óptimo puede crearse para cada aplicación y cargarse en la FPGA siempre que se requiera. Por ejemplo, considere un sistema de procesamiento de señales. Tal sistema puede que tenga requerimientos para determinado número de algoritmos, incluyendo la transformada rápida de Fourier, transformadas Z y diversas operaciones de filtrado. Cada uno de los algoritmos puede que se tengan que ejecutar sobre diferentes longitudes de palabra. Un chip de propósito general diseñado para hacerlo todo se encontraría con muchos compromisos en su estructura. Por el contrario, el layout de una FPGA podría crearse individualmente para cada combinación algoritmo - longitud de palabra. El hecho de que cada uno de esos layouts sería una implementación sin compromisos del algoritmo en cuestión reduciría el número de puertas e incrementaría la velocidad respecto al diseño de propósito general. Esas ventajas ayudarían a compensar el overhead que el uso de FPGAs ocasiona en comparación con los ASIC a medida.
Llevado al extremo, este uso de las FPGAs coloca al software directamente sobre el layout del chip. Para ver cómo podría funcionar esto a continuación examinaremos la arquitectura típica de una FPGA.
Una familia típica de FPGAs de gama media es la serie XC4000 de Xilinx. Estos dispositivos se ofrecen en tamaños que varían entre 3000 y 85000 puertas equivalentes [1], aunque en aplicaciones prácticas es imposible utilizarlas todas. La arquitectura XC4000 se basa entorno a un tipo de celda universal denominada Bloque Lógico Configurable (CLB, Configurable Logic Block). Cada CLB contiene una sección lógica consistente de tres generadores de funciones y una sección de almacenamiento con dos flip-flops. Las funciones que han de implementarse en la sección lógica junto al enrutamiento de las salidas y la configuración de los flip-flops (disparados por flanco o sensibles a nivel, por ejemplo) se encuentran todas definidas en celdas de memoria dentro del CLB. Un modo alternativo permite que algunas de esas células de memoria se empleen directamente como RAM. Un refinamiento más es la provisión de lógica especial para facilitar acarreo adelantado y propagación para funciones aritméticas. Los CLBs en la familia XC4000 están colocados en una matriz rectangular de 10x10 el dispositivo más pequeño, mientras el más grande tiene 3126 CLBs (56x56).
Las conexiones entre CLBs se realizan utilizando una jerarquía de trayectos. Al nivel más bajo están las conexiones directas. Éstas proporcionan un enlace entre cada CLB y sus vecinos inmediatos. La dirección de estos enlaces es fija de forma que los datos fluirán de izquierda a derecha o de arriba abajo solamente. La siguiente capa en la jerarquía la proporcionan líneas de longitud unitaria. Éstas están destinadas principalmente a la conexión de CLBs vecinos, aunque pueden emplearse para distancias mayores a costa de algún retardo extra.
Intercaladas a intervalos regulares en la matriz de CLBs se hallan las Matrices de Conmutación Programables (PSM, Programmable Switch Matrices). Cada línea de longitud unitaria va de una PSM a la siguiente con una conexión opcional a los CLBs que atraviesa en su recorrido. En la PSM cada línea puede conectarse opcionalmente a su continuación y/o a las líneas perpendiculares a ella. Estas conexiones son las que causan el retardo cuando varias líneas de longitud unitaria se emplean sobre distancias mayores. Para evitar ese retardo existen otras líneas que no se paran en cada PSM. Las líneas de longitud doble hacen escala en PSMs alternos y están dispuestas escalonadamente de forma que cada CLB puede acceder al mismo número de ellas. Las líneas de longitud cuádruple son similares y, como su nombre indica, son cuatro veces más largas que las líneas de longitud unitaria. Sin embargo, la longitud extra incrementa sus requerimientos de forma que estas líneas más largas tienes sus propias matrices de conmutación con buffers adicionales. Los buses globales son posibles por las llamadas "líneas largas", que recorren la longitud completa del array y se conectan a las salidas de los CLBs mediante buffers triestado. Las interconexiones de propósito especial incluyen las líneas de distribución del reloj global y las de propagación de acarreo local de alta velocidad.
En los bordes del dispositivo, se proporciona un Bloque de Entrada/Salida (IOB, Input/Output Block) dedicado para cada pin. Al igual que con los CLBs y la jerarquía de interconexiones, una amplia gama de opciones pueden programarse usando celdas de memoria RAM, incluyendo no sólo propiedades lógicas como el sentido del pin sino también características eléctricas y de temporización para permitir que el dispositivo pueda usarse en una gran variedad de entornos.
La complejidad de este dispositivo está más allá del ámbito del diseño manual, especialmente si grandes dispositivos y complicadas aplicaciones se hallan involucradas, así que el soporte software se hace manifiestamente necesario. Las primeras FPGAs se diseñaron usando herramientas tradicionales de captura de diagramas para el diseño de hardware y este método aún está en uso. Sin embargo, para que la reconfiguración se explotase por completo había de ser accesible a los diseñadores de software y de esa forma se necesitaba una nueva generación de herramientas.
Esta tecnología ofrece una oportunidad única para una computación paralela flexible, y debería emplearse para construir sistemas tan eficientes como sea posible. Cuando la tecnología reconfigurable sea ampliamente adoptada, los programadores desearán programar de forma que se explote la posibilidad de paralelismo. Se podría esperar que los lenguajes de programación existentes pudiesen proporcionar una base para el soporte software de sistemas basados en FPGAs. Desgraciadamente, la mayoría de los lenguajes de programación actualmente usados no poseen construcciones que permitan al usuario programar sistemas multiprocesador. Por ejemplo, uno de los lenguajes más populares, C++, no tiene incorporado soporte para el paralelismo. Esto limita al usuario a únicamente poder escribir programas (y, hasta cierto punto, pensar) de una forma secuencial, con cada línea de código ejecutada después de la anterior. Los lenguajes funcionales permiten expresar el paralelismo de una forma natural, pero a menudo son conceptualmente muy diferentes a los lenguajes de programación secuenciales con los cuales la mayor parte de los usuarios están familiarizados, haciéndolos difíciles de aprender y de adaptarse a ellos. Dadas estas desventajas, la programación funcional ha sido utilizada principalmente por unos pocos expertos.
Más que crear un nuevo lenguaje similar a los descritos arriba, algunos desarrolladores han seguido la opción de extender las capacidades de los lenguajes secuenciales existentes, como C++, haciéndoles modificaciones o añadiéndoles módulos. El paralelismo a menudo entra en conflicto con componentes existentes en el lenguaje, forzando la eliminación de algo de funcionalidad y limitando el ámbito de las mejoras concebidas.
Una estrategia para aportar paralelismo a los lenguajes (siendo Ada y Java los principales ejemplos) es el uso de hebras (threads). Una hebra es una especie de sendero que se recorre en el programa. Un lenguaje puramente secuencial tendría una hebra; es decir, sólo se recorre un camino a través del código a la vez. Los programas paralelos se denominan multihebra ya que pueden tener varios caminos de esos activos a la vez. En un sistema monoprocesador, esto se implementaría mediante multitarea, con el control del procesador pasando de una hebra a otra en diferentes intervalos de tiempo para ofrecer la ilusión de que se están ejecutando simultáneamente. En un sistema multiprocesador, tal como es posible con computación reconfigurable, las hebras pueden realmente ejecutarse paralelamente en diferentes procesadores del sistema, permitiendo tantas hebras activas como procesadores (y si no hay suficientes es posible que se pueda confeccionar uno nuevo sobre la marcha usando un sistema con FPGAs). Al ejecutarse en un único procesador, un sistema multitarea tiene la ventaja de poder compartir la mayor parte de los datos del sistema entre todas las hebras. Sin embargo, con múltiples procesadores, tal memoria compartida resulta difícil de realizar cuando el número de procesadores supera la decena. Como consecuencia de esto, los sistema altamente paralelos tienden a utilizar memoria distribuida y un modelo software de comunicación de procesos secuenciales (CSP, Communicating Sequential Processes). Varios procesadores se han diseñado con este tipo de arquitectura en mente, en particular el Inmos Transputer y el Texas Instruments 320C40.
Occam, que se diseñó para el Transputer, es un buen ejemplo de cómo CSP puede implementarse directamente en un lenguaje. Sin embargo es más bien de bajo nivel en cuanto carece de capacidad para estructuras de datos sofisticadas. En consecuencia, la mayor parte de los sistemas Transputer y 320C40 emplean variantes de C/C++ con soporte añadido para el procesamiento paralelo. Desgraciadamente, los mecanismos específicos añadidos para permitir paralelismo tienden a ser de un nivel más bajo que el resto del lenguaje y como tales requieren mucho más trabajo para crear sistemas comparables con todos los beneficios de ser concurrentes.
Un proyecto de particular interés, ya que ha sido creado con las FPGAs en mente, es Handel-C, del grupo Oxford Hardware Compilation [3]. Se trata de un lenguaje basado en el álgebra de CSP y desarrollado a partir de Occam [4] que ha sido compilado con éxito en hardware. Handel-C funciona añadiéndole construcciones de Occam a C, creando de esa forma un lenguaje nuevo en el cual el paralelismo es posible. Aunque la idea detrás de Händel-C se mantenido desde su concepción, se ha encontrado numerosas dificultades. Algunas partes del lenguaje C original tuvieron que eliminarse ya que eran simplemente incompatibles con el nuevo sistema. Este lenguaje también se ha convertido en un lenguaje de más bajo nivel que la versión original para permitir que los programadores utilicen la nueva semántica de sincronización para definir la temporización de los programas además de su comportamiento.
Ninguno de estos lenguajes tiene en cuenta una característica arquitectónica muy destacada del diseño de FPGAs; a saber, el sistema de interconexión. El sistema de interconexión, como se describió anteriormente, se adapta muy bien a una gran cantidad de comunicaciones locales pero sólo permite una cantidad bastante limitada de comunicaciones de larga distancia sin penalización. Una característica deseable de un sistema software de soporte sería fomentar las comunicaciones locales utilizando una notación gráfica que proporcione una metáfora evidente.
De la información anterior se aprecia que ninguna de las estrategias consideradas anteriormente por separado constituye una solución apropiada, ya que cada una tiene sus limitaciones e imperfecciones. La estrategia empleada en el prototipo [5] desarrollado en la Nottingham Trent University por nosotros mismos consistía en considerar la utilización de un lenguaje gráfico al que hemos bautizado como "Graphite" [6, 7]. Éste se derivó de metodologías de diseño software existentes como las de Yourdon o Ward-Mellor, las cuales permiten el desarrollo de software más fácil y menos costoso, porque resultan familiares a muchos usuarios potenciales. El lenguaje también utiliza "burbujas" de procesos que pueden implementarse utilizando un lenguaje secuencial existente.
En lenguaje secuencial que se utilice no ha sido decidido aún, ya que hay varios posibles candidatos. C/C++ es la elección lógica, dada su popularidad y versatilidad. Sin embargo, en este punto el lenguaje secuencial empleado no es importante porque no será paralelo por derecho propio. En lugar de eso, el lenguaje se utilizará para describir el comportamiento de subprogramas o entidades de un sistema mayor.
Este método les permite a los usuarios percibir el sistema de una forma mejor y utilizar subcomponentes enlazados, los cuales son intrínsecamente paralelos, sin tener que pensar en ello hasta cierto punto. También les permite utilizar tan poca o tanta concurrencia como deseen: si quieren programar de una forma secuencial simplemente tendrían que definir una única entidad y su código. No obstante, los beneficios comenzarían a aparecer cuando lograsen la confianza necesaria para empezar a dividir sus programas en varios componentes conectados a través de líneas de datos dibujadas de distintos tipos (como pasando parámetros a una función que se ejecutaría concurrentemente con el programa principal). Entonces la información comienza a procesarse en paralelo y las ganancias en eficiencia empiezan a mostrarse.
El objetivo de crear este lenguaje/herramienta de programación y diseño concurrente es, por supuesto, permitir a los programadores especificar un sistema, y que después se implemente en hardware. Para conseguirlo ha de considerarse otro asunto: ¿cómo de indicamos al hardware qué construir?. Aun con el diseño creado y el código programado para cada sección requerida, todo es inútil a no ser que pueda transformarse en algo que pueda crearse en una placa hardware. El programa completado (y el prototipo puede hacerlo ya hasta cierto punto) debe por tanto poder compilar el diagrama y el código en una descripción de hardware.
En el pasado esto habría sido imposible dado que los ordenadores no podían comprender los diagramas y dibujos habitualmente utilizados para especificar hardware. Afortunadamente, existe un lenguaje llamado VHDL que está diseñado para describir casi cualquier tipo de hardware. VHDL es un lenguaje grande y complejo diseñado para representar circuitos. Es ideal para especificar sistemas electrónicos digitales y, a partir ahí, el hardware puede simularse para calibrar su rendimiento o sintetizarse de hecho. Desgraciadamente, VHDL emplea construcciones de temporización de bastante bajo nivel, las cuales, aunque convenientes para la descripción de hardware, suelen ser un escollo para la gente que sólo ha programado en lenguajes para software. Sin embargo, VHDL proporciona una representación intermedia conveniente entre Graphite y la realización hardware final de un sistema. Cuando nuestra herramienta esté finalizada, los diseños y el código introducido por el usuario serán compiladas finalmente en VHDL de forma que el diseño pueda implementarse en hardware sobre una placa lógica programable y reconfigurable.
VHDL comparte muchas de las propiedades de cualquier otro lenguaje de programación, a pesar de estar optimizado para detallar circuitos. También incluye muchas características para describir hardware, desde el nivel de puertas lógicas hasta procesadores completos e incluso más. Una vez que los circuitos han sido diseñados, pueden importarse para formar parte de un sistema mayor, de forma similar a como los objetos pueden usarse como componentes de objetos más grandes en C++ mediante agregación. El lenguaje VHDL es un estándar reconocido en la industria, lo que significa que existen herramientas de todos los fabricantes principales de FIGAS para convertir descripciones VHDL de circuitos al formato adecuado para sus dispositivos.
Cuando se ha definido un sistema en VHDL se puede crear un banco de pruebas para simular al circuito en funcionamiento. Esto se hace escribiendo un proceso que envía entradas a los circuitos virtuales y comprobando que la salida es correcta se obtiene a tiempo. Esto quiere decir que los sistemas pueden probarse para ver si se comportan como se espera y alcanzan un estándar aceptable sin necesidad de circuitos reales con FIGAS. Además, una simulación software es probable que permita una depuración más detallada con un mejor acceso a lo que sucede en el circuito y un menor riesgo de perder información cuando un fallo ocurre.
Nuestro prototipo es una herramienta de diseño y programación que usa una interfaz gráfica para permitirle al usuario introducir diseños y código que después pueden compilarse en hardware, pasándolos al lenguaje VHDL. Utiliza diferentes símbolos para representar distintos tipos de entidades (p.ej. funciones o estados) y dibuja líneas entre ellos para representar las líneas de datos entre esas entidades. En un entorno WIMP dirigido por eventos. El aspecto de la herramienta en su forma actual se ilustra en las figuras 1 y 2. Existe la facilidad para el usuario de introducir el código de las funciones para todos los símbolos colocados en el diseño. Como sucede con todo prototipo, no es completamente funcional pero da una idea del programa completo.
El primer prototipo de este sistema se implementó como proyecto de clase y se sabía desde el principio que no habría tiempo de implementar una versión completamente funcional. Así que se decidió que un prototipo parcialmente funcional se debía crear como "demostración del concepto". El prototipo resultó ser más funcional de lo que se esperaba, con gran parte de la interfaz operacional. Sin embargo, necesita más ampliaciones para estar completo y su salida está muy limitada actualmente, generando sólo las descripciones de entidades en VHDL (el lenguaje objetivo) mientras que se necesitaría implementar más en hardware.
Examinando de lo que el prototipo es capaz y de lo que no, hemos identificado las futuras mejoras que deberían implementarse para perfeccionar el producto. En el futuro se producirá una implementación completa del compilador, la cual requerirá características y correcciones adicionales. En una versión completa, la entrada de código del usuario debe compilarse en sentencias de la arquitectura, el diseño del diagrama representarse por sentencias de componentes, etc. Como el diseño tiene que implementarse en hardware, también se necesita algún tipo de herramienta de comprobación para asegurar que se respetan todas sus reglas y requerimientos.. Puede que se necesite la existencia de opciones para elegir qué plataforma FPGA se ha de usar, de forma que la salida en VHDL pueda ajustarse para ser más eficiente sobre ella.
En algún momento, puede que sea ventajoso poder hacer ingeniería inversa sobre el código VHDL para obtener código y diagramas. Esto permitiría hacer cambios a alto nivel sin las complejidades asociadas al trabajo con VHDL. El diagrama también necesita poder cambiar a distintos niveles de abstracción para funciones, que podrían consistir de funciones más pequeñas (de forma similar a los diagramas de flujo jerárquicos). También se necesitarían comprobaciones de consistencia si se utilizan diagramas jerárquicos para asegurar que todas las líneas de datos están conectadas a algún sitio, etc..
Desde la implementación de este prototipo, se han reconocido nuevas construcciones necesarias, que de nuevo tendrían que ser añadidas a las clases que se dibujan (y puede que requieran más funciones para ajustar su configuración). Además de su faceta hardware, esta metodología funciona bien para diseñar cualquier sistema paralelo, así que puede que se requieran opciones para inhabilitar la compilación hardware y simplemente producir diseños y código.
Para usar completamente la herramienta de la forma propuesta se requieren:
La herramienta actualmente está escribiéndose en C++ de forma que casi cualquier estación de trabajo u ordenador personal actual satisfaría el primer requisito. Existen varias fabricantes que suministran actualmente hardware que satisfaga el segundo requerimiento. Los autores actualmente utilizan una placa desarrollada en el programa "ASPIRE" [8], que contiene una versión del procesador ARM junto con dos FIGAS de la serie XC4000 de Xilinx. Otro suministrador de hardware adecuado es Giga Operations Corporation [9]. El software necesario para satisfacer el tercer requisito normalmente está disponible del fabricante de FIGAS.
El uso de la herramienta es como sigue. Primero ha de crearse un programa Graphite. El programa Graphite consiste en una jerarquía de diagramas junto con el texto de apoyo para las entidades para el nivel más bajo de los diagramas. La herramienta gráfica permite editar los diagramas manteniendo las relaciones correctas entre diagramas y entre diagramas y texto de apoyo. Así mismo, el texto de apoyo puede editarse directamente usando un editor de texto.
Cuando se piensa que el programa está completo normalmente se compilaría primero en un fichero de simulación. El simulador permite examinar el comportamiento del sistema y su depuración en un entorno amigable con acceso completo al funcionamiento interno del sistema. También permite realizar la depuración sin pasar por la costosa en tiempo etapa de síntesis de hardware.
Cuando el programa se ejecuta satisfactoriamente en el simulador, comienza la etapa de compilación hardware. En este punto la herramienta separará cualquier sección substancial de código secuencial del resto. Un compilador adecuado procesará entonces esos fragmentos de código secuencial. En el hardware usado actualmente por los autores, esas secciones de código se ejecutarán en el microprocesador ARM, aunque en el fututo probablemente se ejecutarán en procesadores sintetizados en el hardware FPGA. Las restantes partes del sistema serán compiladas por la herramienta en VHDL y pasadas al software de síntesis del fabricante. En la actualidad este software no es normalmente capaz e crear una configuración óptima a partir de VHDL sin ayuda humana. Se espera que la herramienta sea capaz de generar información extra a partir de la estructura del programa Graphite que pueda guiar el proceso de síntesis para producir un buen resultado automáticamente. A la larga, el ideal sería prescindir de la etapa VHDL e integrar la herramienta Graphite directamente en el paquete software para FIGAS del fabricante. Sin embargo, mientras tanto, la etapa VHDL permite flexibilidad.
Cuando se completa la etapa de síntesis, la combinación de código secuencial compilado y datos de configuración se carga en el hardware destino y el sistema puede funcionar de verdad.
Cuando se implemente con éxito, esperamos que el producto final sea un paso adelante en la programación de ordenadores. Como se mencionó antes, las mejoras de rendimiento podrían obtenerse mediante un sistema de éxito, conforme el ordenador llegase a ser más adecuado para las tareas requeridas por una aplicación particular. Con esta flexibilidad añadida para acelerar la ejecución de los programas, las actualizaciones sin fin de hardware y software actualmente requeridas para que un usuario se mantenga a la par de la tecnología quizá podrían reducirse. Es una meta de los autores impulsar el desarrollo del prototipo mencionado aquí en el último año de sus carreras universitarias y después.
La investigación en el área de la computación reconfigurable continúa a lo largo y ancho del mundo académico, así que parece inevitable que una solución con éxito sea implementada en algún lugar. Con esto en mente y todos los cambios que el hardware reconfigurable puede traer, creemos que no está lejos el día en que todas las aplicaciones se diseñen e implementen usando lenguajes que reconfigurarán el hardware.
Richard Swan y Anthony Wyatt son estudiantes de Informática en la Nottingham Trent University que emprendieron un estudio en computación reconfigurable como proyecto común de segundo año. Actualmente trabajan en la industria en su año de colocación laboral y volverán en 1999 para completar sus titulaciones.
Richard Cant y Caroline Langensiepen son profesores en el Departamento de Informática de la Nottingham Trent University.
¿Desea más artículos de Crossroads acerca de Arquitectura de Computadores? Vaya al índice, al siguiente o al anterior.
Copyright 1999 Richard Swan, Anthony Wyatt, Richard Cant, & Caroline Langensiepen