PDF de programación - Estimación de Consumo de Potencia en FPGA a través de un Servicio Web

Estimación de Consumo de Potencia en FPGA a través de

un Servicio Web

E. Todorovich1, A. Holderbeke2 y E. Boemo1

1 Escuela Politécnica Superior, Universidad Autónoma de Madrid, España

{elias.todorovich, eduardo.boemo}@uam.es

2 KATHO - Departement VHTI, Belgium
[email protected]

Resumen. En este artículo se describe un servicio Web sencillo para una herramienta
de estimación de consumo en circuitos combinacionales implementados en FPGA. El
servicio Web se provee mediante el protocolo SOAP, ampliamente aceptado. Una de
las ventajas de esta tecnología es que los usuarios remotos pueden acceder a la
herramienta en su versión más actualizada sin hacer ningún esfuerzo de instalación o
mantenimiento. Si bien un usuario remoto puede usar este servicio en sus aplicaciones
mediante invocaciones estilo RPC o mensaje a servidor, también se desarrolló una
interfaz Web que sirve para acceder al servicio y como demostración de su uso. En la
versión actual se estima la potencia consumida por el circuito y los nodos individuales
mediante estadísticas. Los dispositivos soportados son los de Xilinx. En esta técnica el
usuario especifica el nivel de confianza para el error tolerado en la estimación.
También se genera información para construir mapas de consumo en el chip.

1 Introducción

Si bien una herramienta de estimación de consumo medio desarrollada se viene mejorando
y probando en el laboratorio [1-3], está claro que para conseguir versiones estables y
depuradas, debe ser evaluada por el mayor número de usuarios que sea posible. Para que
esta herramienta EDA (Electronic Design Automation) esté disponible para los usuarios en
Internet, se desarrolló una API (Application Program Interface) simple que encapsula su
funcionalidad: La API usa SOAP como mecanismo de comunicación debido a su amplia
aceptación en Internet. Prácticamente cualquier lenguaje de programación tiene librerías
para usar SOAP sin dificultad. De esta manera la herramienta se pone a disposición de los
usuarios de todo el mundo como un servicio Web.

Los servicios Web comienzan a difundirse masivamente a partir de cuando compañías
como Google o Amazon los adoptan para poner sus servicios disponibles a programadores
de aplicaciones en Internet. Los servicios Web son aplicaciones accesibles desde Internet
desarrolladas según estándares abiertos. Se puede construir un servicio Web desde
cualquier plataforma y usando el lenguaje de programación preferido. El protocolo SOAP
para el intercambio de mensajes (Simple Object Access Protocol), es un protocolo basado
en XML (eXtended Markup Language) para invocar procedimientos remotos e intercambiar
información de manera descentralizada y distribuida. Los mensajes SOAP se transportan
sobre HTTP y sus capas inferiores por Internet. En la Fig. 1 se da una representación de
esta pila de protocolos.

Fig. 1. Pila de protocolos de los servicios Web



Mientras que las páginas Web son para los humanos, los servicios Web son para los
ordenadores. Las páginas Web contienen cierta información o realizan cierta tarea y se
puede acceder desde un navegador. Los servicios Web en cambio permiten el intercambio
de información y la realización de tareas entre ordenadores mediante SOAP/XML. Del
mismo modo, cuando se navega por un portal, normalmente se cuenta con un índice, o
mapa del sitio. Este índice permite conocer las partes accesibles del portal. Con los
servicios Web, este “índice” es el archivo WSDL (Web Services Description Language).
Este archivo WSDL, también en formato XML, indica al ordenador que lo consulta, qué
servicios puede requerir con una referencia precisa sobre ellos, para poder invocarlos
usando los parámetros adecuados.

Siguiendo con el paralelismo anterior, al igual que en la Web existen buscadores como
Google, el concepto equivalente a nivel de servicios Web es UDDI (Universal Description,
Discovery and Integration). UDDI es, a su vez, un servicio Web que se puede utilizar desde
las aplicaciones cliente para descubrir de forma dinámica otros servicios. Este servicio se
puede considerar las páginas amarillas de los servicios Web.

Un escenario más dinámico donde un servicio Web utiliza estos protocolos se ve en la

Fig. 2.

Fig. 2. Uso de los protocolos WSDI y UDDI

Para proveer y usar un servicio Web en Internet, el proveedor del servicio lo publica
mediante WSDL en un directorio de servicios que usa UDDI. Los clientes buscan el
servicio en el directorio y obtienen la manera de comunicarse con el proveedor de servicio
usando parte de la especificación WSDL. El cliente, finalmente, invoca procedimientos en
el servidor. El servidor devuelve una respuesta en el caso que la comunicación sea del tipo



RPC o nada si se le envió un mensaje. Para conocer mejor esta tecnología se puede buscar
información en Internet o en revistas especializadas [4]. Aquí se va a mostrar como se usa
para poner una herramienta EDA a disposición de todo usuario con conexión a Internet.

2 Implementación

En este trabajo solamente se implementó una primera capa del esquema anterior, que
provee invocación de procedimientos en el servidor mediante mensajes SOAP como se ve
en la Fig. 3. Esto quiere decir que cualquier cliente tiene que conocer la dirección IP o URL
(Uniform Resource Locator) donde está el servidor, los nombres de las funciones que
provee la API implementada y los parámetros de estos métodos. En esta etapa del
desarrollo, el servicio propuesto no está en las “páginas amarillas”. Por ahora sólo puede
usarse si un “amigo” nos da la dirección del servidor.

Fig. 3. Servicio web de estimación de consumo en tiempo de ejecución



En la Fig. 3 se tiene, en el centro, el servicio Web principal que usan los clientes
externos. Provee estimación de consumo de potencia de diseños en FPGA, para usuarios
registrados que deben autenticarse. Esto es necesario para tener una mínima privacidad
sobre los trabajos que cada usuario requiere. El servicio también administra las tareas de los
diferentes usuarios. Como el proceso de estimación de consumo demora como mínimo
unos cuantos minutos, las tareas requeridas por los usuarios se encolan por orden de
llegada. Si la estimación se pide con un alto nivel de confianza que el error sea muy
pequeño, el software puede necesitar incluso horas para completar la tarea.

A la izquierda, en la Fig. 3, está el servicio Web de Estimación de Consumo básico. Este
servicio solamente encapsula la funcionalidad de la herramienta EDA de Estimación de
Consumo. Cada vez que termina una tarea de estimación, el servicio básico coordina con el
servicio principal para procesar la siguiente tarea en espera.

En la parte derecha de la figura están los clientes del servicio de Estimación de
Consumo. En particular, se desarrolló una interfaz Web que sirve de demostración en vivo
de cómo se usa el servicio Web de Estimación de Consumo. Los usuarios, una vez
autenticados, pueden requerir una nueva tarea de estimación de consumo para uno de sus
diseños implementados en FPGAs de Xilinx. También pueden ver cuales de las tareas
previamente requeridas están terminadas o pendientes, y bajar los resultados de la
estimación de sus tareas terminadas a su ordenador remoto.

En cada una de las sub secciones siguientes se presentan los detalles de implementación
del servicio principal, el servicio básico de Estimación de Consumo y el cliente basado en
la interfaz Web.

3.1 Servidor Básico de Estimación de Consumo

La herramienta EDA de estimación de consumo medio, se basa en la técnica estadística.
Permite obtener estimaciones tanto del circuito completo como de los nodos individuales.
Además, al acceder a archivos del fabricante con información luego de haber hecho el
emplazamiento y el rutado, se puede hacer la correspondencia entre las posiciones físicas
de las pistas y sus consumos individuales de potencia. Con esta información se pueden
hacer mapas de consumo en la FPGA.

Fig. 4. Capas de software sobre la herramienta EDA de Estimación de Consumo



El servicio web básico que encapsula esta funcionalidad (Ver Fig. 4) provee 5 métodos

públicos:

exec_task_a_dyp (task, subtask, ncd, pcf, ini)

exec_suk_task_a_dyp (task, subtask, ini)

is_busy_a_dyp ()

get_powrep_a_dyp (task, subtask)

get_powmap_a_dyp (task, subtask, resolution)
exec_task_a_dyp inicia la ejecución de una tarea de estimación de potencia, dados el
archivo NCD post emplazamiento y rutado, el archivo PCF de restricciones físicas (por
ejemplo, posiciones de los pines de entrada y salida) y el archivo INI con los parámetros
definidos por el usuario. En el archivo INI se especifican tanto los parámetros de la técnica
estadística (error admisible en la estimación, nivel de confianza, etc.), como otros propios
de esta herramienta (nivel en la cantidad de información que se debe almacenar, tiempo
mínimo de un glitch, etc.).

La estimación de consumo se realiza mediante la estimación de actividad de los nodos
según los parámetros definidos en el archivo INI y la obtención de las capacidades de los
nodos individuales según los archivos NCD y PCF. Pero por ejemplo, si se quiere estimar
la potencia de un diseño para diferentes especificaciones de actividad a las entradas del
circuito, se tendrán nuevos archivos INI siendo la obtención de capacidades idéntica. La
tarea de obtención de capacidades tiene un tiempo de ejecución que no es para nada

despreciable. Por lo tanto, se tiene el m