XIII Jornadas de Computación Reconfigurable y Aplicaciones JCRA ...

Actas de las

XIII Jornadas de Computación Reconfigurable y Aplicaciones

JCRA 2013

Gustavo Sutter Jose Ignacio Martinez Torres

Sergio Cuenca Asensi (Editores)

ISBN: 978-84-695-8318-0

Madrid, España 18-20 de septiembre 2013

iii

PRÓLOGO

Las Jornadas de Computación Reconfigurable y Aplicaciones (JCRA) es el punto de encuentro anual de los grupos de investigación españoles e iberoamericanos en el que se exponen y debaten los últimos avances, investigaciones y experiencias académicas en el campo de la computación reconfigurable, tecnologías y aplicaciones de los dispositivos lógicos programables

Los dispositivos tipo FPGA son hoy día la alternativa más importante para construir sistemas digitales de gran velocidad y altas prestaciones Las nuevos dispositivos de millones de puertas permiten construir sistemas completos de altísima complejidad y convierte a esta tecnología en un elemento de computación transversal a múltiples disciplinas. Los alcances propios de esta tecnología como el procesamiento embebido, el procesado digital de la señal o la supercomputación permiten abordar y dar soluciones problemas de las más diversas ramas de la ciencia, siendo cada vez más común trabajos multidisciplinares donde la tecnología reprogramables está presente.

Los antecedentes de las jornadas se remontan al año 2001, habiendo sido organizado por los principales grupos de investigación del tema dentro de España. Este congreso se ha llevado a cabo previamente en Alicante (2001), Almuñécar (2002), Madrid (2003), Barcelona (2004), Granada (2005), Cáceres (2006), Zaragoza (2007), Móstoles (2008), Alcalá de Henares (2009), Valencia (2010), La Laguna, Tenerife (2011) y Elche, Alicante (2012) permitiendo a los investigadores locales y latinoamericanos conocerse, intercambiar ideas, colaborar y estar al tanto del trabajo de sus colegas en los diversos temas del área de las FPGAs.

Este libro condensa una selección de artículos de la decimotercera edición del JCRA, llevada a cabo en la ciudad de Madrid del 18 al 20 de septiembre del 2013. El comité de programa ha seleccionado un total de 15 artículos clasificados en los siguientes temas: procesamiento digital de la señal, diseños de cores IP, lenguajes de alto nivel y comparativas, arquitecturas y diseños de sistemas en un chip, criptografía y diseños tolerantes a fallos. Confiamos que los lectores encontrarán en este libro una importante fuente de documentación e inspiración sobre temas contemporáneos de FPGAs.

Los Editores

iv

COMITÉ DE ORGANIZACIÓN

Coordinador General

Sergio Cuenca Asensi Universidad de Alicante

Coordinadores Programa Técnico

José Ignacio Martínez Torre Universidad Rey Juan Carlos

Gustavo Sutter Universidad Autónoma de Madrid

Comité de Dirección:

Miguel Ángel Aguirre Echánove Universidad de Sevilla Eduardo Boemo Scalvinoni Universidad Autónoma de Madrid Ignacio Bravo Universidad de Alcalá de Henares Joan Cabestany Universidad Politécnica de Cataluña Jordi Carrabina Bordoll Universidad Autónoma de Barcelona Sergio Cuenca Asensi Universidad de Alicante José Ignacio Martínez Torre Universidad Rey Juan Carlos Denis Navarro Universidad de Zaragoza Francisco Pelayo Valle Universidad de Granada Juan Suardíaz Muro Universidad Politécnica de Cartagena Gustavo Sutter Universidad Autónoma de Madrid José Torres Universidad de Valencia Miguel Ángel Vega Rodriguez Universidad de Extremadura

v

COMITÉ DE PROGRAMA JCRA 2013

Gustavo Sutter, U. Autónoma de Madrid, Coordinador del Comité de programa

José Ignacio Martínez Torre, Universidad Rey Juan Carlos

Miguel Ángel Aguirre Echánove, Universidad de Sevilla

Carlos Amuchástegui, Universidad del País Vasco

Antonio Martínez-Álvarez, Universidad de Alicante

Javier Castillo Villar, Universidad Rey Juan Carlos

Eduardo Boemo Scalvinoni, Universidad Autónoma de Madrid

Joan Cabestany, Universidad Politécnica de Cataluña

João M. P. Cardoso, University of Algarve (Portugal)

Jordi Carrabina Bordoll, Universidad Autónoma de Barcelona

Sergio Cuenca Asensi, Universidad de Alicante

Eduardo de la Torre, Universidad Politécnica de Madrid

Jean Pierre Deschamps, Universidad Rovira i Virgill

Luis Entrena Arrontes, Universidad Carlos III de Madrid

Joan Figueras, Universidad Autónoma de Madrid

Antonio García Ríos, Universidad de Granada

Francisco Gómez Arribas, Universidad Autónoma de Madrid

Juan Antonio Gómez Pulido, Universidad de Extremadura

Diego Gómez, Vela Universidad de Cádiz

Jose María Granado Criado, Universidad de Extremadura

Román Hermida, Universidad Complutense de Madrid

Francisco Ibarra Picó Universidad de Alicante

Andrés Iborra Universidad Politécnica de Cartagena

Sergio López-Buedo Universidad Autónoma de Madrid

Enrique Mandado Pérez Universidad de Vigo

Francisco Javier Marín Martín Universidad de Málaga

José Luis Martín González, Universidad del País Vasco

Manuel Mazo Quintas, Universidad de Alcalá de Henares

Manuel Moreno Aróstegui, Universidad Politécnica de Cataluña

vi

COMITÉ DE PROGRAMA JCRA 2013 (continuación)

Fernando Pardo, Universidad de Valencia

Francisco Pelayo Valle, Universidad de Granada

Antoni Portero, Universidad Autónoma de Barcelona

Alberto Prieto, Espinosa Universidad de Granada

Lluis Ribas, Universidad Autónoma de Barcelona

Fernando Rincón, Universidad de Castilla la Mancha

Eduardo Ros, Universidad de Granada

Eduardo Sánchez, Escuela Politécnica Federal de Laussane, Suiza

César Sanz Álvaro, Universidad Politécnica de Madrid

Moisés Serra Universidad de Vic

Juan José Serrano Martín, Universidad Politécnica de Valencia

Jose T. de Sousa, INESC-ID Lisboa (Portugal)

Lluis Terés, Centro Nacional de Microelectrónica, CSIC, Barcelona

Antonio Torralba, Universidad de Sevilla

Javier Valls Coquillat, Universidad Politécnica de Valencia

Miguel Ángel Vega Rodríguez, Universidad Extremadura

Juan Suardíaz Muro, Universidad Politécnica de Cartagena

vii

TABLA DE CONTENIDOS Capítulo 1- Digital Signal Processing & IP Cores Sistema empotrado reconfigurable para aplicaciones de identificación de caras ....................................................................................................................... 3 Laurentiu Acasandrei (Instituto de Microelectrónica de Sevilla, IMSE-CNM-CSIC), Manuel Quintero (Universidad de Sevilla), Alejandro Ruiz (Universidad de Sevilla), Angel Barriga (Instituto de Microelectrónica de Sevilla, IMSE-CNM-CSIC/Univ. Sevilla). Arquitectura eficiente para la eliminación simultánea del wandering y el ruido en señales ECG ............................................................................................ 9 Luis Parrilla (Universidad de Granada, Spain), Diego P. Morales, (Universidad de Granada), Encarnación Castillo (Universidad de Granada), Víctor Unai (Universidad de Granada), Fca. Sonia Molina (Univ. de Granada), Jesús Florido (Universidad de Granada), Antonio García (Universidad de Granada) Diseño e implementación de un controlador de un motor de corriente continua sobre un dispositivo FPGA ................................................................... 17 Samuel Vázquez Hidalgo (Universidad Politécnica de Madrid), Basil Mohammed Al-Hadithi (Universidad Politécnica de Madrid), Juan Suardíaz Muro (Universidad Politécnica de Cartagena, Spain) Implementación de un Core TDC multicanal de alta resolución para sistemas PET ....................................................................................................... 25 Jose Torres (Universidad de Valencia, Spain), Albert Aguilar (Universidad de Valencia), Adrian Suarez (Universidad de Valencia), Raimundo Garcia-Olcina (Universidad de Valencia), Jesus Soret (Universidad de Valencia), Julio Martos (Universidad de Valencia), Pedro A. Martinez (Universidad de Valencia), Ivan Leiva (Universidad de Valencia)

viii

Capítulo 2- Lenguajes de Alto Nivel y Comparativas A Study of Sorting Algorithm in FPGA using High Level Languages ............... 31 Marta Cuaresma (Universidad Autónoma de Madrid), Gustavo Sutter (Universidad Autónoma de Madrid), Francisco Gomez-Arribas (Universidad Autónoma de Madrid) Clasificación de paquetes IP a 10 Gbps descripto desde lenguajes de alto nivel ..................................................................................................................... 41 Marco Forconesi (Universidad Autónoma de Madrid), Gustavo Sutter (Universidad Autónoma de Madrid), Sergio Lopez-Buedo (Universidad Autónoma de Madrid), Francisco Gomez-Arribas (Universidad Autónoma de Madrid) Mapeo automático de sistemas basados en OpenCV en los nuevos SoCs heterogéneos ........................................................................................................ 47 Francisco José Sanchis-Cases (University of Alicante, Spain), Antonio Martínez-Álvarez (University of Alicante), Sergio Cuenca-Asensi (University of Alicante) Reducción de los tiempos de cómputo de la Migración Sísmica usando FPGAs y GPGPUs: Un artículo de revisión ........................................................ 57 Carlos Fajardo (Universidad Industrial de Santander, Colombia), Javier Castillo Villar (Universidad Rey Juan Carlos, Spain), Cesar Pedraza (Universidad Santo Tomas, Colombia), José Ignacio Martínez (Universidad Rey Juan Carlos) Capítulo 3-Architecture and Designs of Systems-On-Chip Implementación de un sistema de reconocimiento de señales de tráfico en tiempo real mediante visión artificial basado en FPGA ...................................... 73 Nicolás Aguirre Dobernack (Universidad de Sevilla, Spain), Hipólito Guzmán Mirand (Universidad de Sevilla), Miguel Ángel Aguirre Echánove (Universidad de Sevilla) FPGA Acceleration of Semantic Tree Reasoning Algorithms ............................ 81 Jesus Barba (Universidad de Castilla-La Mancha, Spain), Maria José Santofimia (Universidad de Castilla-La Mancha), David de la Fuente (Universidad de Castilla-La Mancha), Julio Dondo (University of

ix

Castilla-La Mancha), Fernando Rincon (University of Castilla-La Mancha), Julian Caba (Universidad de Castilla-La Mancha) Trabajo de desarrollo de un Sensor Multivista basado en microcámaras de bajo coste ............................................................................................................. 89 David Hernández Expósito (La Laguna University, Spain), Manuel Rodríguez Valido (Universidad de La Laguna), Eduardo Magdaleno Castelló (Universidad de La Laguna), Fernando Pérez Nava (Universidad de La Laguna) Capítulo 4 - Cryptography & Fault Tolerance Mecanismos ligeros para mejorar la fiabilidad de las respuestas PUF en la generación de llaves criptografícas ..................................................................... 97 Brisbane Ovilla-Martinez (Cinvestav, Tamaulipas, Mexico), Arturo Diaz-Perez (Cinvestav, Tamaulipas) Ataques por canal lateral sobre el algoritmo de encriptación AES implementado en MicroBlaze ........................................................................... 105 Mariano Rubén Lumbiarres López (Universitat Politècnica de Catalunya, Spain), Mariano López García (Universitat Politècnica de Catalunya), Enrique Cantó Navarro (Universitat Rovira i Virgili, Spain) Protección efectiva de circuitos implementados en FPGAs utilizando técnicas de triplicación sobre la plataforma NESSY ......................................... 113 Silvia Alcázar (Universidad Complutense de Madrid), Almudena Alonso (Universidad Complutense de Madrid), Beatriz Álvarez-Buylla (Universidad Complutense de Madrid), Felipe Serrano (Universidad Complutense de Madrid), Juan Antonio Clemente (Universidad Complutense de Madrid) Un estudio de la robustez frente a SEUsde circuitos digitales implementados con los DSPs de las FPGAs ............................................................................... 119 Felipe Serrano (Universidad Complutense de Madrid), Juan Antonio Clemente (Universidad Complutense de Madrid), Hortensia Mecha (Universidad Complutense de Madrid Spain)

Capítulo 1

Digital Signal Processing & IP Cores

Capítulo 1- Digital Signal Processing & IP Cores Sistema empotrado reconfigurable para aplicaciones de identificación de caras Laurentiu Acasandrei (Instituto de Microelectrónica de Sevilla, IMSE-CNM-CSIC), Manuel Quintero (Universidad de Sevilla), Alejandro Ruiz (Universidad de Sevilla), Angel Barriga (Instituto de Microelectrónica de Sevilla, IMSE-CNM-CSIC/Univ. Sevilla). Arquitectura eficiente para la eliminación simultánea del wandering y el ruido en señales ECG Luis Parrilla (Universidad de Granada, Spain), Diego P. Morales, (Universidad de Granada), Encarnación Castillo (Universidad de Granada), Víctor Unai (Universidad de Granada), Fca. Sonia Molina (Universidad de Granada), Jesús Florido (Universidad de Granada), Antonio García (Universidad de Granada) Diseño e implementación de un controlador de un motor de corriente continua sobre un dispositivo FPGA Samuel Vázquez Hidalgo (Universidad Politécnica de Madrid), Basil Mohammed Al-Hadithi (Universidad Politécnica de Madrid), Juan Suardíaz Muro (Universidad Politécnica de Cartagena , Spain) Implementación de un Core TDC multicanal de alta resolución para sistemas PET Jose Torres (Universidad de Valencia, Spain), Albert Aguilar (Universidad de Valencia), Adrian Suarez (Universidad de Valencia), Raimundo Garcia-Olcina (Universidad de Valencia), Jesus Soret (Universidad de Valencia), Julio Martos (Universidad de Valencia), Pedro A. Martinez (Universidad de Valencia), Ivan Leiva (Universidad de Valencia)

Sistema empotrado reconfigurable para aplicaciones de identificación de caras

Laurentiu Acasandrei(1), Manuel Quintero Rodríguez(2), Alejandro Ruiz Ribes(2), Angel Barriga Barros(1,2),

[email protected], [email protected], [email protected], [email protected] (1) Instituto de Microelectrónica de Sevilla, IMSE-CNM-CSIC.

(2) Escuela Técnica Superior de Ingeniería Informática, Universidad de Sevilla.

Resumen Se presenta un sistema empotrado sobre FPGA para detección/reconocimiento de caras basado en el procesador LEON3. El sistema está constituido por varios módulos IP (Intelectual Property) diseñados como periféricos del bus AMBA. El módulo de detección de caras es reconfigurable pudiendo operar en un modo de detección de caras o bien en un modo en el que sus recursos (memoria y operadores aritméticos) son utilizados por el procesador como componentes genéricos. El sistema ha sido diseñado aplicando criterios de optimización de consumo de potencia y velocidad de operación.

1. Introducción

El reconocimiento de caras constituye una tarea importante en aplicaciones biométricas y de interacción hombre-máquina. El proceso de reconocimiento requiere la secuencia de dos tareas: la detección de caras en imágenes y el reconocimiento e identificación de dichas caras. Debido a la complejidad de los algoritmos de detección y reconocimiento de caras se requiere una gran cantidad de recursos de computación y memoria. Por lo tanto las implementaciones software de los algoritmos de detección/reconocimiento resultan poco eficientes cuando deben ejecutarse sobre sistemas SoC (System on Chip) que requieran alta velocidad de procesado, pocos recursos y bajo consumo de potencia. En estos casos el uso de técnicas de codiseño hardware-software pueden aplicarse para el desarrollo de aceleradores hardware para las partes que requieren de mayor consumo computacional en los algoritmos de detección.

En esta comunicación se describe la arquitectura de un sistema empotrado sobre FPGA para identificación de caras. El sistema está constituido por componentes hardware y software. Los componentes hardware corresponden a las interfaces de entrada (captura de imágenes desde una cámara) y el procesado para la detección de caras en la imagen. Los componentes software corresponden a las funciones de inicialización y control del hardware y la implementación de los algoritmos de reconocimiento.

La sección siguiente describe brevemente los algoritmos de detección y reconocimiento de caras que se han implementado. A continuación se describirá la arquitectura del sistema. Finalmente en la sección 4 se discutirá sobre la operación del sistema.

2. Algoritmos de detección y reconocimiento de caras

2.1. Detección de caras: Viola-Jones

Uno de los algoritmos implementados para la detección de caras es el algoritmo de Viola-Jones [1] que permite procesar imágenes de manera muy rápida y consigue una razón de detección alta. La velocidad en el procesado se debe a tres elementos claves de dicho algoritmo. En primer lugar la imagen se transforma en una imagen integral lo que permite calcular el área de los rectángulos en un tiempo constante como se muestra en la figura 1. Dicha imagen integral consiste en acumular para cada píxel el valor de los píxeles previos:

yyxx

yxiyxii','

)','(),(

(1)

XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)

1

En segundo lugar se usa un clasificador

simple y eficiente construido mediante el algoritmo de aprendizaje AdaBoost [2]. Esto permite seleccionar un número reducido de características visuales de un conjunto muy alto de características potenciales. Ejemplos de las características tipo Haar usadas por el clasificador se ilustran en la figura 2. Consisten en áreas rectangulares cuyo procesado requiere operaciones aritméticas simples. En el cálculo se aplica un umbral a las sumas y diferencias de las regiones rectangulares de la imagen (las regiones oscuras se restan de la regiones blancas).

Figura 1. La suma de píxeles del rectangulo D se calcula mediante la siguiente operación en la imagen integral: ii4+ii1-(ii2+ii3).

En tercer lugar el clasificador está constituido combinando clasificadores sencillos en cascada (figura 3). La técnica Viola-Jones se basa en explorar la imagen mediante una ventana en busca de características. Dicha ventana se escala con objeto de localizar caras de diferentes tamaños. Las primeras etapas consisten en detectores simples, muy rápidos y de bajo coste. Esto permite eliminar aquellas ventanas que no contienen caras y deja pasar las que son candidatas a tener caras. Los siguientes detectores aumentan en complejidad con objeto de realizar un análisis más detallado en un conjunto menor de las zonas de interés. Las caras son detectadas en el final de la cascada.

Figura 2. Ejemplos de características de tipo Haar.

Figura 3. Arquitectura de detectores en cascada.

2.2. Detección de caras: LBP

El operador LBP (Local Binary Pattern) fue introducido por [3] para describir la textura en imágenes. Ha sido aplicado a detección de caras dando lugar a clasificadores rápidos ya que tan sólo se realizan sencillas operaciones aritméticas [4]. El operador etiqueta los píxeles de una imagen comparando los vecinos que lo rodean de acuerdo con la figura 4. Si el píxel central es menor se codifica con 0 y en caso contrario con 1. El radio del operador no tiene que ser 1 sino que puede tener diferentes tamaños.

Figura 4. Bloque 3x3 píxeles de una imagen. b) Aplicación del operador LBP.

El píxel se codifica con los valores obtenido (11011001 en el ejemplo de la figura 4). A continuación se obtiene el histograma de etiquetas LBP. La detección se realiza calculando la distancia entre la imagen con el histograma entrenado.

2.3. Reconocimiento de caras: Eigenfaces

El método Eigenfaces se basa en el análisis de componentes principales (PCA). La técnica PCA es una técnica estadística utilizada para reducir las dimensiones de un conjunto de datos. Principalmente identifica patrones en los datos y los expresa de un modo que destaca sus semejanzas y diferencias. La idea en la que se basa es que un conjunto de datos de alta dimensionalidad es descrito a menudo por variables correlacionadas. Por tanto sólo algunas dimensiones aportan la mayor parte de la información. PCA encuentra las direcciones con mayor varianza de los datos, llamadas componentes principales.

Una vez concluido el análisis realizado mediante PCA, el método Eigenfaces es capaz de

145 63 33

98 45 45

10 20 205

1 1 0

1 1

0 0 1

a) b)

A B

D C ii1 ii2

ii3 ii4

D1 D2 DN

Capítulo 1: Digital Signal Processing & IP Cores

2

interpretar el subespacio obtenido de modo que, una nueva cara será proyectada en dicho subespacio y se clasificará como perteneciente al individuo más cercano.

Para ello se calcula la matriz de covarianza mediante la siguiente expresión [5]:

Tix

c

iix

cS )(

1)(

1

1

(1)

siendo c el número de caras a entrenar, xi representa la variable i (cara i) y es la media aritmética de las variables. La ecuación (1) permite reducir las operaciones a realizar si bien los vectores propios han de obtenerse sobre la matriz (x – μ)T*S.

Para cada imagen del conjunto de entrenamiento se calcula su proyección en el espacio de caras. El espacio de caras está formado por los vectores propios más significativos de la matriz (x – μ)T*S. De esta manera al proyectar en el espacio de caras una nueva imagen se identifica con el individuo del conjunto de entrenamiento al que corresponde la distancia menor.

2.4. Reconocimiento de caras: Fisherfaces

La técnica Fisherfaces es la aplicación del análisis discriminante lineal (LDA) al problema de reconocimiento de caras. El método LDA (también conocido como discriminante lineal de Fisher) es una técnica estadística utilizada para reducir las dimensiones de un conjunto de datos [6]. Sin embargo, mientras PCA se realiza sobre variables cuantitativas, LDA hace lo propio con variables que pueden categorizarse. La principal diferencia entre LDA y PCA es que PCA realiza un análisis no supervisado y, por tanto, no toma en consideración la categoría a la que pertenecen los datos mientras que LDA aprovecha esa información útil para conseguir que datos de distintas categorías sean linealmente separables. Mientras PCA busca la mejor descripción de los datos tras la proyección, LDA busca la mejor discriminación entre clases. Por tanto LDA es una técnica estadística utilizada para reducir las dimensiones de un conjunto de datos preservando toda la información discriminante de categoría como sea posible. Para ello maximiza la varianza entre categorías mientras minimiza la varianza entre variables pertenecientes a una misma categoría.

El método Fisherfaces es más propicio para clasificación supervisada. Este método consigue proyectar las imágenes de caras de un espacio con alta dimensionalidad a un subespacio de menor dimensión que es menos sensible a variaciones de luz y de expresiones faciales mientras mantiene la discriminalidad. Esto es una clara ventaja frente a Eigenfaces que sí es influenciable por dichas variaciones.

El propósito del método es acorde con el propósito de una clasificación, es decir, los mismos individuos deberían mantenerse cercanos mientras que los individuos distintos han de mantenerse lo más alejados posible entre sí.

Al estar basado en LDA existe un detalle técnico que complica la aplicación del método. Normalmente el número de píxeles de cada cara es mayor que el número de caras que componen el entrenamiento. Este hecho conlleva que la matriz de covarianza de cada individuo Sw resulte ser singular, es decir, que no tiene inversa. Por tanto el subespacio formado por los vectores propios más significativos de la matriz Sw

-1SB no puede ser calculado. SB es la matriz de covarianza entre individuos. Una de las posibles soluciones consiste en aplicar PCA sobre el conjunto de entrenamiento y mantener un máximo de c-k vectores propios para formar el subespacio, donde c es el número de caras a entrenar y k es el número de individuos. A continuación se calculan las proyecciones del conjunto de datos sobre el subespacio calculado y se aplica LDA a la matriz resultante de concatenar las proyecciones por filas. Finalmente, el subespacio resultante sobre el que deben proyectarse el conjunto de entrenamiento y la nueva cara a clasificar se calcula mediante W=WPCAWLDA.

3. Descripción de la arquitectura

La arquitectura del sistema se basa en el procesador LEON3. LEON3 es un procesador sintetizable descrito en VHDL con un núcleo de 32 bits conforme a la arquitectura IEEE-1754 (Sparc V8). Está diseñado para aplicaciones integradas y combina un alto rendimiento con una baja complejidad y bajo consumo de energía. El núcleo de LEON3 tiene las siguientes características principales: pipeline de 7 etapas en una arquitectura Harvard, cachés de instrucción y datos independientes, multiplicador y divisor


3

hardware, soporte de depuración on-chip y extensiones multiprocesador. El procesador LEON3 se distribuye como parte de la biblioteca GRLIB IP [7], lo que permite una integración sencilla en diseños SoC complejos. La biblioteca GRLIB IP está constituida por un conjunto de módulos IP reutilizables, diseñados para el desarrollo de sistemas SoC. Los módulos de propiedad intelectual se basan en el bus AMBA y el uso de un mecanismo de simulación y síntesis. La biblioteca es independiente de la tecnología de implementación y dispone de diferentes herramientas CAD. El sistema de desarrollo se basa en un método plug&play para configurar y conectar los módulos sin la necesidad de modificar los recursos globales del sistema.

La figura 5 muestra el diagrama de bloques del sistema de detección/reconocimiento de caras. El sistema recibe como entrada las imágenes procedentes de un cámara. El módulo Framebuffer almacena la imagen en la memoria DDR2. Dicha imagen es procesada por el módulo IP encargado de la detección de caras. Una vez detectada la cara en la imagen se procesa por los algoritmos de reconocimiento para verificar la identificación del individuo. El resultado se muestra en un monitor y es enviado mediante comunicación inalámbrica.

Con objeto de realizar el test de los circuitos y algoritmos de detección/reconocimiento también se ha desarrollado un aplicación que permite controlar el sistema desde un ordenador (vía serie), enviar datos (imágenes) de test y recibir los resultados para su posterior procesado.

El sistema ha sido implementado en una placa de desarrollo ML505 que contiene un FPGA de Xilinx XC5VLX50.

3.1. Framebuffer de la cámara

El sistema recibe datos de entrada (imágenes) de una cámara conectada al FPGA. Es una cámara CMOS 21C405W de Videology [8]. Dicha cámara permite capturar imágenes de 758 x 540 píxeles. Tiene una tasa de captura de 30fps progresivo y 60fps entrelazado. Posee una interfaz de comunicación RS-485 para el control y una interfaz paralela para enviar los píxeles de cada frame.

El módulo Camera Framebuffer es el encargado de recibir los datos procedentes de la

cámara y almacenarlos en memoria. Dicho módulo dispone de memoria interna para almacenar 2 frames (uno lee la imagen actual de la cámara y el otro escribe en memoria el frame previo). Dispone de una interfaz al bus AHB y tiene capacidad de acceso directo a memoria así como a una operación por ráfagas. Para aplicaciones de detección de caras realiza el cálculo de la imagen integral. Esto permite acelerar los mecanismos de detección.

Figura 5. Diagrama de bloques del sistema.

3.2. Interfaz para comunicación inalámbrica

La comunicación entre el sistema y el exterior se realiza de manera inalámbrica mediante la placa JN5148 de Jennic [9]. Dicha placa contiene un controlador de 32 bits para implementar los siguientes protocolos de comunicación inalámbricos: IEEE 802.15.4, JenNet y ZigBee

Camera Framebuffer

Camera

DDR2 memory

DDR2 Controller

AHB

FPGA

Face Detection

IP

LEON3 processor

SVGA controller

APB

uart gpio uart

Wireless comm.


4

PRO. La interfaz entre el sistema basado en LEON3 implementado sobre el FPGA con dicha placa se realiza en serie mediante el uso de una UART.

Figura 6. Sistema de comunicación inalámbrico.

3.3. Módulo para detección de caras

El módulo de detección de caras es un componente reconfigurable que implementa dos mecanismos de detección de caras: algoritmo de Viola-Jones y algoritmo LBP. El módulo tiene 2 modos de operación: el modo libre en el cual los recursos del IP (memoria, multiplicador, unidad raíz cuadrada entera, etc) pueden ser usados por LEON3 para implementar otra funcionalidad y el modo de detección de caras [10].

Figura 7. Sistema de detección de caras.

El módulo tiene acceso directo a memoria. En el caso de ejecutar el algoritmo LBP para detección de caras accede a los datos en memoria mediante el mecanismo de ráfagas para acelerar las transferencias de datos.

4. Aplicación a la identificación de caras

La aplicación software empotrada es la encargada de inicializar las memorias del módulo IP de detección de caras (por ejemplo en el caso de aplicar el algoritmo de Viola-Jones se encarga de almacenar las características de tipo Haar en la memoria del módulo). También se encarga de establecer los valores de los registros de configuración de dicho componente. Cuando la aplicación software realiza el comando de inicio el procedimiento de detección de caras es controlado por el módulo IP de detección de caras. El módulo IP implementa el algoritmo de ventanas de búsqueda. Al finalizar el proceso de detección el componente indica si hay caras actualizando el registro de estado con el resultado obtenido y se genera una interrupción. La unidad contiene varias unidades de control con objeto de soportar las diferentes latencias en los accesos a la memoria del sistema (externa al módulo IP). Junto a las diferentes máquinas de estado que constituyen las unidades de control este componente también contiene módulos especializados: el módulo que calcula el área de los rectángulos en la imagen integral usando solo los datos de las esquinas, un módulo pipeline para el escalado y cálculo de la dirección de las características de tipo Haar, un circuito que realiza la raíz cuadrada entera de números de 64 bits (tiene una latencia de 16 ciclos de reloj) y un multiplicador de números con signo de 41x33 bits.

El resultado del sistema de detección de caras consiste en las coordenadas de la cara en la imagen así como su tamaño. Esta información es leída por la aplicación software de reconocimiento de caras. Una vez finalizado el reconocimiento se obtiene como resultado la identificación o no del individuo en la base de datos.

El sistema de identificación de caras está basado en la implementación de la librería OpenCV (Open Source Computer Vision) [11]. Esta librería contiene funciones para visión artificial en tiempo real. Teniendo en cuenta que la librería contiene aplicaciones para reconocimiento de caras, se decidió utilizar los archivos fuente de la aplicación como punto de partida en el desarrollo del sistema de identificación de caras para sistemas empotrados basados en LEON3.

Face Detection IP

DDR2 memory

DDR2 Controller

AMBA AHB

AMBA APB

FPGA

uart

AMBA APB

FPGA

2.4GHz Radio

32-bit RISC CPU

uart JN5148-EK010


5

Las aplicaciones de OpenCV de

reconocimiento de caras han sido adaptadas para su operación en un sistema empotrado. Para ello se ha trasladado el código en C++ a un código C y se han adaptado las estructuras de datos para la operación en el sistema empotrado.

El sistema de identificación aplica dos modos de reconocimiento: Eigenfaces y Fisherfaces. La técnica Fisherfaces es una mejora de Eigenfaces no sólo computacional y en eficacia sino en el tamaño necesario para almacenar el entrenamiento. Las operaciones de clasificación son las mismas y lo único que distingue un método de otro es el entrenamiento. Por tanto la aplicación es compatible con ambos métodos con tan sólo variar el entrenamiento. Como ya se ha comentado anteriormente la técnica Fisherfaces es menos sensible a variaciones de luz y de expresiones faciales mientras mantiene la discriminalidad por lo que es más propicio para clasificación supervisada.

El sistema recibe como entrada las coordenadas de la cara en un imagen. Dichas coordenadas son suministradas por el módulo IP de detección de caras. A continuación se aplica uno de los algoritmos de reconocimiento y se obtiene como resultado las características de la cara. Dichas características se comparan con una base de datos almacenada en memoria. En función de un umbral de similitud (seleccionado previamente por el usuario) se identifica al individuo.

La base de datos de individuos ha sido previamente creada aplicando un algoritmo de aprendizaje off-line. Las características de los individuos se almacenan en memoria externa del FPGA. El número de individuos identificables (tamaño de la base de datos) dependerá del tamaño de la memoria del sistema.

5. Conclusión

En esta comunicación se ha presentado un sistema de detección de caras empotrado sobre FPGA. El sistema se basa en una implementación hardware&software sobre el procesador LEON3. Los componentes hardware del sistema se basan en un módulo que acelera el proceso de detección de caras en imágenes y una interfaz para adquirir los datos procedentes de una cámara. Los componentes software están formados por las

funciones de inicialización y control del hardware así como por una implementación empotrada de los algoritmos de reconocimiento de caras.

Agradecimientos

Este trabajo ha sido soportado parcialmente por los proyectos P08-TIC-03674 financiado por la Junta de Andalucía, TEC2011-24319 financiado por el Ministerio de Ciencia y Tecnología, IPT-2012-0695-390000 financiado por el Ministerio de Economía y Competitividad, todos ellos con cofinanciación FEDER por la Unión Europea.

Referencias

[1] P. Viola, M.J. Jones: Robust Real-Time Face Detection, International Journal of Computer Vision, v.57 n.2, pp.137-154, May 2004.

[2] R.E. Schapire, Y. Freund, P. Bartlett, W.S. Lee: Boosting the Margin: A New Explanation for the Effectiveness of Voting Methods, The Annals of Statistics, pp. 1651-1686, 1998.

[3] T. Ojala, M. Pietikainen, D. Harwood: A comparative study of texture measures with classification based on feature distributions. Pattern Recognition 29 (1996), 51–59

[4] T. Ahonen, A. Hadid, M. Pietikainen: Face Recognition with Local Binary Patterns, LNCS, Springer-Verlag, 2004.

[5] R. O. Duda, P. E. Hart y D. G. Stork: Pattern Classification, Segunda ed., 2000.

[6] R. A. Fisher: The use of multiple measurements in taxonomic problems, Annals of Eugenics, vol. 7, pp. 179-188, 1936.

[7] J. Gaisler, S. Habinc, E. Catovic: GRLIB IP Library User’s Manual, Gaisler Research, 2009.

[8] Videology Imaging Solutions, Inc.: http://www.videology.nl/

[9] JN5148-EK010 Evaluation Kit User Guide. 2011.

[10] L. Acasandrei, A. Barriga: FPGA implementation of an embedded face detection system based on LEON3, Int. Conf. on Image Processing, Computer Vision, and Pattern Recognition, Jul. 2012.

[11] OpenCV: http://sourceforge.net/projects/opencvlibrary/


6

Arquitectura e�ciente para la eliminación simultánea delwandering y el ruido en señales ECG

Luis Parrilla(1), Diego P. Morales(1), Encarnación Castillo(1),Víctor Unai(1),

Francisca S. Molina(2) , Jesús Florido(3) y Antonio García(1)

[email protected], [email protected], [email protected], [email protected]

[email protected], j�[email protected], [email protected]

(1)Dpto. de Electrónica y Tecnología de Computadores, Universidad de Granada

(2)Hospital Universitario San Cecilio, Granada

(3)Dpto. de Obstetricia y Ginecología, Universidad de Granada

Resumen

En el presente artículo se presenta un sistemapara la eliminación simultánea del wander-

ing y el ruido en señales electrocardiográ�cas(ECG). El procesamiento se basa en la uti-lización de la Transformada Wavelet Discreta,buscando reducir la complejidad de los cálcu-los para conseguir una implementación hard-ware en punto �jo de alta velocidad que per-mita el procesamiento en tiempo real. Los re-sultados obtenidos a partir de señales ECGsintéticas y reales muestran la validez de losalgoritmos y el sistema desarrollados.

1. Introducción

La adquisición de señales electrocardiográ�cas(ECG) a través de la piel en humanos pre-senta varias di�cultades relacionadas con lasdistintas fuentes de ruido que producen unacontaminación de las señales ECG. Estos rui-dos pueden tener un origen instrumental y �si-ológico [1], y se ven agravados por la necesidadde ampli�cadores de instrumentación de ele-vada ganancia, especialmente en el caso de lamedida de ECGs fetales adquiridas a través delabdomen materno [2]. De estos ruidos, los mássigni�cativos son los producidos por la fuentede alimentación y el wandering de la línea base(BW). El resto de ruidos pueden presentar unancho de banda apreciable y provenir de proce-

sos estocásticos complejos, generando una dis-torsión de la señal ECG. El BW y el restode ruidos con gran ancho de banda presen-tan di�cultades para su supresión utilizandohardware analógico, siendo mucho más e�cacesesquemas de procesamiento software. Sin em-bargo, las plataformas hardware deben de serel objetivo para conseguir sistemas portátilesde adquisición y procesamiento de ECGs. Así,en este artículo se estudian los procedimien-tos para la implementación de sistemas digi-tales que permitan una supresión sencilla delos ruidos de gran ancho de banda menciona-dos. La Transformada Wavelet (WT) [3] seha revelado como una herramienta útil parauna gran variedad de aplicaciones de proce-samiento [4] y compresión [5] de señales. Es-ta transformada produce una descomposicióntiempo-frecuencia de la señal analizada, sep-arando las componentes individuales de ca-da señal de forma más efectiva que el análisisde Fourier tradicional. Estas propiedades hanhecho que la WT sea una de las herramien-tas matemáticas más utilizadas para el proce-samiento de bioseñales, siendo el ECG uno delos candidatos para este tipo de análisis. Enlas siguientes secciones se propone una seriede estructuras para el cálculo de la Transfor-mada Wavelet Discreta (DWT), orientadas alprocesamiento de señales ECG, concretamentea la supresión de los distintos tipos de ruido,incluyendo niveles de continua y wandering.


7

2. Supresión simultánea de BW y

ruido mediante DWT

La Transformada Wavelet [3] ha demostra-do su utilidad en la eliminación del ruido debaja frecuencia [6]. Teniendo en cuenta que elBW presenta frecuencias entre 0.15 y 0.3Hz,un procedimiento para la supresión del BWconsiste en la aplicación de la descomposiciónwavelet hasta un nivel de resolución en el quela secuencia de aproximación puede capturarel BW, restar esta parte de la señal ECG sinprocesar, y calcular la reconstrucción wavelet.En estas bandas de frecuencia, el nivel de res-olución debe ser tal que la secuencia de aproxi-mación capture las componentes del ECG parafrecuencias menores que 1Hz. Por otra parte,la supresión de ruido mediante wavelets estámostrando una gran efectividad sin que seapreciso realizar una tratamiento complejo dela señal con ruido [7], al localizar las princi-pales propiedades espaciales y de frecuenciade la señal en un número limitado de coe�-cientes wavelet. Además, debido a la ortogo-nalidad de la transformada, el ruido blanco sedistribuye uniformemente entre todos los coe�-cientes de detalle, garantizando que la contrac-ción wavelet produce una reducción del ruido,a la vez que se conservan las característicasmás pronunciadas (picos del complejo QRS).Debido a la similitud de las estructuras

wavelet para la eliminación del BW y del rui-do, en este trabajo se propone la aplicación si-multánea de las dos técnicas, realizando todoel procesamiento en un solo paso. Con este es-quema de procesamiento se consigue un ahor-ro importante en los recursos y el tiempo deprocesamiento, facilitando la posterior imple-mentación hardware. Los pasos a seguir parala aplicación de esta propuesta son los sigu-ientes:

1. Descomposición: Se aplica la la descom-posición wavelet hasta un cierto nivel L,con el �n de generar los coe�cientes deaproximación a

(L)n para la captura del

BW.

2. Puesta a cero de las aproximaciones: Lasecuencia de aproximación a

(L)n se reem-

plaza por un vector con todas sus compo-nentes a cero [6].

3. De�nición de los umbrales en los detalles:Se selecciona el nivel M (con M < L)que permita distinguir apropiadamente lapresencia de descargas parciales en los de-talles con ruido. Además, se aplica un um-bral según unas terminadas reglas en cadanivel desde i = 1 hasta M , a los coe�-cientes de detalle d

(i)n para conseguir una

supresión óptima del ruido [7].

4. Reconstrucción: Se calcula la reconstruc-ción wavelet basada en la puesta a cero delas aproximaciones en el nivel L, los de-talles modi�cados en los niveles 1 a M , ylos detalles originales de los niveles M +1a L, obteniendo la señal con el BW cor-regido y limpia de ruido.

Así, mediante una selección adecuada de losparámetros, es posible obtener una supresiónsimultánea del BW y del ruido, utilizando latécnica wavelet presentada. La selección de lafamilia wavelet debe basarse en la similitudesentre la estructura básica de un ECG y las fun-ciones wavelet empleadas, y el tipo de proce-samiento a realizar. Según se comentó ante-riormente, para eliminar el BW es necesarioelegir un nivel de resolución tal que la aprox-imación correspondiente capture las compo-nentes del ECG menores que 1 Hz. Tenien-do en cuenta que en cada nivel de de descom-posición, la banda de frecuencia de la aprox-imación se divide por 2, el nivel de descom-posición para la eliminación del BW se puedecalcular como:

L = dlog2(F0)e (1)

donde F0 es la máxima componente en fre-cuencia de la señal. Por otra parte, el máximonivel para el umbral de detalle, M , dependevarios factores como el SNR de la señal orig-inal, o la frecuencia de muestreo. El nivel deruido es signi�cativo en las subbandas de altafrecuencia del detalle, mientras que la mayoríadel espectro de energía se encuentra en las sub-bandas de baja frecuencia [7]. Por tanto, si se


8

desea evitar la pérdida de componentes clíni-camente relevantes de la señal, tales como mor-fologías del PQRST, sólo deben tratarse lassubbandas de alta frecuencia del detalle parala supresión del ruido.Existen varios métodos para determinar el

umbral límite [7], [11], pero aquí se consider-arán aquellos que sean más apropiados para suimplementación hardware por su complejidadde cálculo, recursos necesarios, retardo, etc.Concretamente, algunos umbrales que puedenresultar aplicables son los siguientes:

• Umbral universal

Thun =√

2 · logN (2)

• Umbral exponencial

Thexp = 2(i−M

2 )√

2 · logN (3)

• Umbral minimax [8]

Thminimax = 0,3936+0,1829 ·(log(ni)

log(2)

)(4)

donde N es la longitud de la señal, y ni repre-senta el número de coe�cientes en cada niveli = 1, ...,M . En principio, el cálculo de estosumbrales requiere de operaciones como la raízcuadrada o el logaritmo, que pueden necesitarde algoritmos especí�cos en punto �jo para suimplementación hardware. Sin embargo, parauna longitud pre�jada de la señal, N , es posi-ble precalcular el número de coe�cientes en ca-da nivel, ni. Así, en nuestro modelo se utilizanumbrales precalculados desde N y M , sin queexista ninguna otra dependencia de la señal alimpiar. La siguiente expresión para estimar lavarianza del ruido:

σi = media(∣∣d(i)n

∣∣) /0,6745 (5)

permite elegir entre reescalado simple o multi-ple [10]. El reescalado no se puede precalcularporque depende de los detalles, pero las opera-ciones a realizar presentan mucha menor com-plejidad que otras aproximaciones de la vari-anza.

3. Modelado en punto �jo para im-

plementación harware

Utilizando las técnicas presentadas en lasección anterior, se han desarrollado modelossoftware para los procedimientos de supresiónde BW y ruido en señales ECG basados en laDWT. Los modelos software permiten realizarun análisis y ajuste rápido de los parámetros,así como una evaluación de las técnicas de-sarrolladas, mientras que la traslación de es-tos modelos a aritmética de punto �jo per-mite replicar el funcionamiento de las imple-mentaciones hardware y analizar parámetrostales como el truncado, numero de muestras dela ventana de datos, frecuencias de muestreo,etc. Para el modelado en punto �jo, la tareamás importante a realizar es la determinaciónde las longitudes de palabra a utilizar en lasdistintas variables involucradas en el sistemade procesamiento. Por otra parte, se necesi-tan dos módulos especí�cos para el cálculo dela DWT y la transformada inversa (IDWT),que deben diseñarse para obtener las mejoresprestaciones con la wavelet concreta que sevaya a utilizar. Los recursos que se precisanpara el modelado hardware, son básicamenteuna lógica de control y una serie de registros.Los �ltros paso-baja y paso-alta necesariosse modelan utilizando bancos de �ltros FIRy estructura directa, mientras que el númerode etapas queda determinado por la funciónwavelet.

4. Parámetros de entrada

A continuación se detallan brevemente losparámetros de entrada para el modelo desupresión simultánea de BW y ruido:

• Función Wavelet : El modelo de pun-to �jo propuesto permite la utilizaciónde diversas familias wavelet como son:Daubechies, Coi�ets, Symlets, Biorthog-onal y Reverse Biorthogonal.

• Niveles de descomposición L y M : Nues-tro modelo calcula automáticamente losniveles de descomposición para la elimi-nación del BW según la ecuación (1). Sin


9

embargo, debido a la di�cultad de estable-cer a priori el nivel máximo óptimo Mpara aplicar los umbrales de detalle, elmodelo permite elegir este parámetro.

• Umbrales y reescalado: Sólo se han consi-derado los umbrales con bajo costo com-putacional. El modelo propuesto incluyela posibilidad de elegir uno de los tres um-brales de�nidos anteriormente: universal,exponencial o minimax.

• Reglas de aplicación de los umbrales: Elmodelo permite seleccionar si se utilizanumbrales soft o hard. Las operacionesnecesarias de pueden implementar fácil-mente en aritmética de punto �jo.

5. Implementación hardware

El modelo de punto �jo propuesto se ha im-plementado usando VHDL sobre FPGAs deXilinx. El diagrama de bloques general dela arquitectura propuesta puede verse en laFig. 1. La arquitectura se ha diseñado parala realización de aplicaciones en tiempo realbasadas en la adquisición y procesamiento deventanas de datos ECG de n-muestras. La im-plementación consta de los siguientes bloques:

• Bu�er de entrada-RAM de descomposi-

ción. Este bloque se utiliza para laadquisición y procesamiento de cada unade las ventanas de datos ECG. Consta dedos memorias, llamadas bu�er de entra-

da y RAM de descomposición. El bu�erde entrada almacena la ventana de datosmuestreados en una pila. Esta ventana dedatos se copia en la RAM de descomposi-ción, que se va refrescando con los coe-�cientes obtenidos a partir del bloque dedescomposición wavelet. Se evitan así con-�ictos en los instantes de tiempo en losque la ventana de datos se está procesan-do y a la vez se produce la adquisición delos datos de una nueva ventana de datos.

• Procesador wavelet. Este módulo consti-tuye un bloque IP que implementa las op-eraciones de descomposición y reconstruc-ción para la DWT. El bloque consiste en

tres unidades de control, dos bloques deprocesamiento y una FIFO. Las primerasdos unidades de control permiten con�gu-rar los bloques de descomposición y recon-strucción, mientras que la tercera unidadde control permite la sincronización de losdos bloques de procesamiento y el controlde los accesos a memoria.

• RAM de detalle. Cada una de estasmemorias se utiliza para almacenar loscoe�cientes de detalle de cada uno delos niveles de descomposición. Puesto quese necesitan L niveles de descomposiciónwavelet, se precisan de L RAMs de de-talle. El acceso a estas memorias se pro-ducirá durante el proceso de reconstruc-ción para acceder a las L secuencias dedetalle.

• Memoria de reconstrucción. La señal re-construida en cada nivel se almacena enesta memoria para ir siendo procesada porel bloque de reconstrucción. Cuando elproceso de reconstrucción termina, se al-macena la señal procesada en esta memo-ria.

• Bloque procesador. El procesador permiteimplementar las operaciones de controlnecesarias, seleccionar los parámetros in-volucrados en la supresión del BW yel ruido, calcular los detalles modi�ca-dos, aplicar el procesamiento propuestopara la eliminación del BW y el ruidoy gestionar la visualización de la señalprocesada. Este bloque integra un sistemacompuesto por un microcontrolador, unamemoria ROM, una memoria RAM, uncontrolador LCD para la representaciónen tiempo real, puertos de entrada/salida,interfaz para los accesos de descomposi-ción y reconstrucción y la lógica requeridapara la conexión entre estos módulos.

6. Resultados

Se han utilizado diferentes tipos de señalesECG para la evaluación de los modelos en pun-


10

Figura 1: Diagrama de bloques de la arquitecturapropuesta

to �jo propuestos y la implementación hard-ware:

• DaISy Database [9]: contiene monitori-zaciones con 8 canales de mujeres em-barazadas, 3 torácicos y cinco abdomi-nales muestreados a 250 mps y 10 segun-dos de duración.

• AECGs sintéticas: Se han generado trestipos de señales sintéticas utilizando lafunción ecg.m de MATLAB, con una du-ración de 21.6 segundos y conteniendo5400, 10800 y 21600 muestras (muestreosde 250, 500 y 100 mps), respectivamente.

• PhysioNet Database [11]: contiene moni-torizaciones de 4 canales, 2 torácicas y 4abdominales, muestreadas a 1 kmps y conuna duración de 60 segundos. El ancho debanda es de 0.01Hz�100Hz.

6.1. Evaluación del modelo en punto �jo

Para modelar y evaluar las prestaciones delos modelos propuestos basados en la DWTse ha utilizado MATLAB procesando señalesde la base de datos DaIsy [9]. Para evaluar laDWT e IDWT en su versión en coma �otante,se utilizó el parámetro SNR de�nido como:

SNRx/x = 10 · log

∑i

(xi)2∑

i

(xi − xi)2

(6)

La Tabla 1 muestra los resultados parael parámetro SNRMAT/dp correspondiente alSNR entre las secuencias de aproximación ydetalles a1, d1, a7, d7 obtenido utilizando lasfunciones dwt.m y idwt.m disponibles en latoolbox wavelet de MATLAB y el obtenidoutilizando nuestros modelos en coma �otante.Los valores del SNR son muy elevados, del or-den de los 300 dB, indicando que nuestro mod-elo en coma �otante proporciona resultadosequivalentes a los obtenidos por las funcionesde la toolbox wavelet.

Por otra parte, el parámetro SNRori/MAT

se utiliza para comparar la señal original conlas señales reconstruidas (sin ningún proce-samiento de los datos) desde el nivel 1, sr1,y desde el 7, sr7 utilizando las funciones deltoolbox wavelet, mientras SNRori/flp com-para la señal original con la reconstruida uti-lizando nuestros modelos en coma �otante. Co-mo muestra la Tabla 1, se obtienen los mismosvalores SNR para estos dos comparaciones,con�rmando la validez de los modelos prop-uestos.

Para seleccionar el ancho de palabra a uti-lizar en los modelos de punto �jo de la DWTe IDWT, se han efectuado varios estudios var-iando los anchos de palabra desde 34 hasta 12bits, para el electrodo-2 de la base de datosDaISy. Para la representación en punto �jo de16-bit, el SNR entre las señales original y re-construida para J=1 es 67.98 dB, que es unvalor aceptable para sistemas de procesamien-to de señales reales. Además, los resultados deotro estudio re�ejan que si se aplica el pre-procesado wavelet para la supresión del BWno existen diferencias apreciables en términosdel SNR entre el uso de las funciones pre-de�nidas de MATLAB, los modelos en coma�otante propuestos, y los modelos de punto �jode 16 bits, tal y como muestras los resultadosSBW de la Tabla 1 (SNRori/fixp compara laseñal original con la procesada utilizando nues-tro modelo de punto �jo de 16 bits). Además,la representación en punto �jo usando 16 bitsofrece un buen balance entre los errores deredondeo y los recursos hardware necesariospara su implementación. En consecuencia, seha seleccionado una representación de 16 bits


11

Cuadro 1: Evaluación de los módulos wavelet propuestos en coma �otante

ECG reales abdominales (DaISy)

Parameter L1 L2 L3 L4 L5 L6 L7 L8

a1 SNRMAT/dp 315.6 315.4 313.5 315.6 316.4 316.1 313.6 315.7

d1 SNRMAT/dp 309.0 304.0 306.7 310.3 302.7 307.1 305.5 307.8

a7 SNRMAT/dp 307.8 296.5 306.6 313.6 303.0 300.1 302.2 305.5

d7 SNRMAT/dp 305.4 301.4 306.1 299.6 305.4 301.8 301.5 302.9

sr1SNRori/MAT 237.6 239.9 239.2 239.3 239.5 238.2 239.0 238.0

SNRori/dp 237.6 239.9 239.2 239.3 239.5 238.2 239.0 238.0

sr7SNRori/MAT 230.2 230.0 230.2 230.7 230.1 230.3 230.0 230.1

SNRori/dp 230.2 230.0 230.2 230.7 230.1 230.3 230.0 230.1

SNRori/MAT 17.35 24.57 16.75 4.84 22.97 26.99 29.42 29.84

sBWSNRori/dp 17.31 24.26 17.02 4.91 23.64 27.70 28.57 28.52

SNRori/fixp 17.22 24.28 17.01 4.91 22.07 27.62 28.65 28.60

en punto �jo para los datos de entrada y elredondeo tras cada nivel de descomposición yreconstrucción.

Para estudiar la supresión BW junto conla eliminación del ruido de forma simultánea,el mejor procedimiento es la inspección vi-sual ante la di�cultad de de�nir parámet-ros cuantitativos. Se utilizaron las bases dedatos DaIsy Dataset y Physionet Dataset [11]para evaluar el procedimiento de supresión si-multánea de BW y ruido. Las monitorizacio-nes de Physionet Dataset son de la base dedatos Non-Invasive Fetal ECG Database in-cluyendo dos canales torácicos y cuatro ab-dominales muestreados a 1 kmps y una lon-gitud total de 60 segundos. Para estas señales,los parámetros seleccionados fueron: funciónwavelet db6, M = 3, umbral universal, reglasoft, reescalamiento simple para la DaIsy

dataset, y reescalado múltiple para la Phys-

ionet Dataset. La Fig. 2 incluye los resultadosobtenidos para el canal 4, donde se muestra laseñal original el BW estimado, y la señal cor-regida en BW y ruido. En la Fig. 3 se incluyenresultados para el canal 1 (a) y el canal 2 (b).Finalmente, la Fig. 4 se muestra un ejemp-

Figura 2: Canal 4 de la base de datos DaIsy, BWestimado y señal con BW y ruido corregidos

lo de resultados para la señal ecgca 746 de labase de datos Physionet Dataset incluyendoel detalle de uno de los complejos QRS fetalesantes y después de su procesamiento. Estas �g-uras muestran que en todas estas señales se hacorregido el BW y se ha eliminado el ruido,reteniendo las principales características de laseñal ECG abdominal, así como los comple-jos QRS fetales, de gran importancia para fu-turas extracciones de parámetros de utilidaddiagnóstica [4].


12

(a)

(b)

Figura 3: Señales de los canales 1 y 2 de la base dedatos DaIsy y señal con BW y ruido corregidos

6.2. Resultados de la implementación

hardware

La arquitectura propuesta para la supresiónsimultánea del BW y el ruido se ha sintetizadoen una FPGA Spartan-6 xc6slx45t-3fgg484, deXilinx, utilizando la herramienta ISE 13.4. Losresultados de síntesis se muestran en la Tabla2, en la que se detallan los recursos de imple-mentación y las prestaciones para el microcon-trolador y el diseño completo. La arquitecturahardware se ha comprobado utilizando señalesECG reales provenientes de las bases de datosdescritas. Los resultados. La comparación delos resultados obtenidos de la FPGA a travésde un analizador lógico con los de los modelosde punto �jo de MATLAB validan la arquitec-tura hardware propuesta.

(a)

(b)

Figura 4: Canal 1 abdominal, señal ecgca 746 dela Physionet Dataset, BW y ruido corregidos (a)y detalle de la señal (b)

Cuadro 2: Resultados experimentales para lasupresión simultánea de BW y ruido en dis-positivos Spartan 6

Micro. Total

Slices 429 3513Slices LUTs 1083 4445LUTs Flip-Flops 1166 4564RAM Blocks 9 25DSP48A1s 3 46Frec (MHz) 54.19 53.34

7. Conclusión

En este artículo se ha presentado un mod-elo en aritmética de punto �jo para la elimi-nación del ruido en señales ECG que introduce


13

la novedad de realizar de forma simultánea me-diante procesamiento wavelet, la eliminacióndel BW y del ruido, con una considerable re-ducción de los recursos hardware a utilizar.El modelo permite su ajuste utilizando difer-entes parámetros permiten adaptarlo a las car-acterísticas especí�cas de la señal ECG a es-tudiar, tales como frecuencias de muestreo yniveles de ruido. Los resultados presentadospara señales ECG sintéticas validan el proced-imiento. Asimismo, la arquitectura hardwaredesarrollada permite el desarrollo de aplica-ciones ECG portátiles.

Agradecimientos

Este trabajo ha sido �nanciado parcial-mente por el CEI BIOTIC Granada a travésdel proyecto 2013/81.

Referencias

[1] J.G. Webster (Ed.), Medical Instrumenta-

tion, Application and Design, John Wiley& Sons,Inc., 1995

[2] D.P. Morales, A. García, et al., "FlexibleECG acquisition system based on analogand digital recon�gurable devices,"Sensors& Actuators: A. Physical, Vol. 165, No. 2,pp. 261�270, 2011.

[3] S.G. Mallat, �A theory for multiresolutionsignal decomposition: the wavelet repre-sentation�, IEEE Trans. On Pattern Re-congition and Machine Intelligence, Vol.11, No. 7, pp. 674�693, 1989.

[4] R. Sameni and D.C. Gari, .A Review ofFetal ECG Signal Processing; Issues andPromising Directions,"The Open Pacing,Electrophysiology & Therapy Journal, Vol.3, No. 1, pp. 4�20, 2010.

[5] C.T. Ku, K.C. Hung, H.S. Wang, Y.S.Hung, �High e�cient ECG compression

based on reversible round-o� non-recursive1-D discrete periodized wavelet trans-form,� Medical Engineering & Physics,Vol. 29, No. 10, pp. 1149�1166, 2008.

[6] E.C. Karvounis, C. Papaloukas, D.I. Fo-tiadis et al.: .An automated methodologyfor fetal heart rate extraction from the ab-dominal electrocardiogram", IEEE Trans.Information Technology in Biomedicine,Vol. 11, No. 6, pp. 628�638, 2006.

[7] L.N. Sharma, S. Dandapat, A. Mahanta:.ECG signal denoising using higher orderstatistics in Wavelet subbands", Biomed-ical Signal Processing and Control, Vol. 5,No. 3, pp. 14�22, 2010.

[8] S. Sardy: "Minimax threshold for denois-ing complex signals with waveshrink, IEEETrans. Signal Processing", Vol. 48, No.4,pp. 1023�1028, 2000.

[9] B. De Moor: "Database for the iden-ti�cation of systems (DaISy)". [On-line]. http://homes.esat.kuleuven.be/

~smc/daisy/, 2010.

[10] H.G.R. Tan, A.C. Tan, P.Y. Khong, andV.H. Mok: "Best Wavelet Function Identi-�cation System for ECG signal denoise ap-plications", Inter. Conf. on Intelligent andAdvanced Systems, pp. 631�634, 2007.

[11] A.L. Goldberger, L.A.N. Amaral, L.Glass, J.M. Hausdor�, PCh Ivanov,R.G.Mark, J.E.Mietus, G.B. Moody,C-K Peng,H.E. Stanley: "PhysioBank PhysioToolkit,and PhysioNet: Components of a NewResearch Resource for Complex Physi-ologic Signals.,Çirculation, Vol. 12, No.101, e215-e220, [Circulation Electron-ic Pages; http://circ.ahajournals.

org/cgi/content/full/101/23/e215;http://physionet.org/physiobank/

database/nifecgdb/. 2000


14

Diseño e implementación de un controlador de un motor de

corriente continua sobre un dispositivo FPGA

Samuel Vázquez Hidalgo(1)

, Basil Mohammed Al-Hadithi (1)

, Juan Suardiaz Muro (2)

[email protected], [email protected], [email protected]

(1) Escuela de Ingeniería Técnica Industrial, Universidad Politécnica de Madrid.

(2) División de Innovación en Telemática y Tecnología Electrónica, Universidad Politécnica de Cartagena.

Resumen

En este artículo se presenta una metodología de implementación de reguladores discretos para el control de sistemas analógicos utilizando un dispositivo FPGA. La particularidad del diseño es la capacidad de realizar los cálculos de forma

cuasi instantánea. Como ejemplo de diseño se implementará un regulador PID para controlar un motor DC.

1. Estado del arte e introducción.

Cada día se está fomentando más el uso de la tecnología FPGA. Y es que multitud de estudios comparativos han demostrado cómo la versatilidad y las prestaciones que ofrecen las FPGAs en algunos campos se encuentra por

encima de las que ofrecen los microprocesadores e incluso algunos DSP (Digital Signal Processor). Así, [1] se presenta una comparación entre las características de los DSP y de las FPGAs y cómo estas últimas son buenas candidatas para el diseño de controladores quasi-analógicos en los diseños de control de potencia. También se estudian las limitaciones que existen (ancho de banda, tiempo

de computación (delays), cuantificación…) y algunas soluciones a dichas limitaciones. Son muchos los autores que han realizado implementaciones de reguladores en FPGA. Por ejemplo, en [2] se analiza una metodología para construir controladores PID mejorando la velocidad, la precisión, la potencia, la densidad y el coste de efectividad. También en [3] se plantea

un método de implementación donde se usa la representación numérica del punto fijo en la realización de controladores PID en FPGAs. En la mayoría de estos proyectos se utiliza el entorno de Matlab Simulink, que es usado para modelar,

simular y comprobar las características para los distintos diseños. Otros autores han planteado metodología de optimización para el diseño de sistemas en lenguajes de programación hardware ([4] y [5]).

Pero este trabajo tomará como partida una idea sugerida por Castro en su tesis [6], donde presenta el diseño de varios convertidores de potencia conmutados. El punto de partida del diseño de implementación de reguladores está en sustituir las operaciones matemáticas de multiplicar y dividir por elementos basados en desplazamientos,

ajustando los datos de origen mediante coeficientes de potencias de orden 2.

2. Planteamiento del problema de cálculo

y solución basada en desplazamientos.

Una operación de división en un microprocesador es relativamente trivial, ya que suele estar incluida en la mayoría de las librerías de los compiladores e incluso en los juegos de instrucciones ensamblador. Sin embargo cuando se está programando hardware es distinto. Una división es una operación compleja. Por eso se han generado una serie de bloques IP para realizar este

cálculo. El núcleo IP de Xilinx “generador de divisores v3.0” [7] ofrece una solución para números de hasta 32 bits, devolviendo el cociente y el resto o la fracción restante de la operación. En cuanto a prestaciones, estos módulos IP dan soluciones generales, presentando un gasto de recursos que podría limitar el diseño si se usan en exceso. Por ejemplo, para un ancho de palabra de

16 bits (ancho usado en este diseño), el gasto de LUTs es de 561 y 832 de Flip-Flops, presentado un tiempo de cálculo de 36 ciclos de reloj. Castro [6] propone un método para el cálculo de multiplicaciones y divisiones basado en


15

desplazamientos. Puesto que desplazar un número

binario un bit a la izquierda es lo mismo que

multiplicar por dos, y desplazar a la derecha

equivalente a dividir entre dos, una combinación

de desplazamientos puede resolver las operaciones

de multiplicación y división de forma rápida

(basta un solo ciclo de reloj, véase figura 1, donde

xk1/27=xb (en el cálculo PID, figura 2)) y con un

consumo mínimo de recursos. Por ejemplo,

multiplicar por 5 puede ser tan fácil como

desplazar un número dos posiciones a la izquierda

(multiplicar por 4) y sumarlo al mismo número:

n*4+n=n*5.

Figura 1. Retardo del divisor mediante

desplazadores.

Para el caso de la división es igual, salvo que

presenta una dificultad extra. Se pueden conseguir

todos los números multiplicando y sumando,

como el caso anterior, pero en la división no se

pueden conseguir todos. Cuando se divide entre

dos se está multiplicando por 0.5 o lo que es lo

mismo 2-1, cuando se divide entre 4 se multiplica

por 0.25 o por 2-2, y así sucesivamente para los

valores 2-n, desplazando n veces el número a la

derecha. Aunque posteriormente se sumen los

distintos resultados existe el inconveniente de que

para conseguir ciertos números exactos, sería

necesario hacer infinitas sumas de términos 2-n.

En consecuencia, en el caso de la división el

número de bits es un factor clave, ya que

repercute mucho en la calidad de la aproximación.

Si se disponen del suficiente número de bits de

cálculo, se pueden conseguir aproximaciones con

errores despreciables para prácticamente cualquier

número fraccionario. Así pues, este método

mejora mucho la rapidez y el consumo de recursos

para divisiones sin resto. El inconveniente que

presenta es el cálculo del divisor, que no es un

número entero tal cual, sino una serie de factores

de exponentes negativos. La calidad de la

aproximación radica, aparte del número de bits, en

lo bien ajustado que esté dicho factor. El ajuste

sigue un algoritmo de búsqueda en el que se

minimiza la diferencia entre el número

fraccionario buscado y el factor de exponentes

negativos calculado.

Puesto que realizar el ajuste del factor de

exponentes negativos para el divisor no es trivial,

se desarrollaron para este trabajo una serie de

hojas de cálculo en EXCEL y un programa en C

que permitían conocer los factores de exponentes

negativos en binario más óptimos dados el número

de bits de cálculo y número fraccionario buscado.

Dicho programa también aportaba información

acerca de la precisión y el error máximo del

cálculo con el fin de asegurarse de la fidelidad de

la aproximación. Mediante estas herramientas, el

uso del divisor por desplazamiento se ha hecho

muy accesible y preciso para dividir entre

constantes.

Pero es muy distinto cuando la variable es el

divisor, ya que se habría de calcular de nuevo el

factor de exponentes negativos para cada divisor.

Integrar ese cálculo dentro de la configuración de

la FPGA supondría un problema arduo, ya que

requiere de numerosas iteraciones y múltiples

cálculos. Por eso, se modificó el programa de

cálculo de coeficientes anterior para que generase

un archivo en VHDL con una tabla con la

correspondencia de los coeficientes para todos los

divisores posibles.

Los resultados de implementación muestran

que, aunque es efectiva la última solución, no es

práctica. La tabla que se ha de generar contiene

unas 2500 soluciones para que el error sea

mínimo, contando con una resolución de unos 20

bits. La compilación de dicha solución es bastante

complicada, ya que usa alrededor del 20% de los

recursos de la FPGA (en una solución que incluía

dicha tabla con 2500 referencias, un divisor IP y

otros módulos se consumían 5890 LUTs y 5918

Flip-Flops) y, por tanto, no es viable. Usar un

módulo IP puede retrasar ciertos ciclos de reloj la

salida de datos, pero esto en la actualidad no

presenta ningún problema debido a las altas

frecuencias con las que se puede trabajar, y tan


16

solo llega a ocupar (incluido el resto de la

programación) el 4% de las LUT y el 5% de los

Flip-Flops (este porcentaje corresponde a una

configuración básica donde se incluye el divisor

únicamente y otros módulos básicos. La solución

usa 884 LUTs y 940 Flip-Flops) facilitando la

síntesis y reduciendo la ocupación de recursos.

Por dicha razón se desaconseja el uso de este

método para el cálculo de divisiones en las que la

variable esté en el denominador.

En lo referente al diseño de los reguladores

implementados en este trabajo, se han utilizado las

bases de la regulación presentadas en autores

como K. Ogata, [8]. Aplicando las técnicas de

Ziegler - Nichols se han deducido los reguladores

que se presentan a continuación. También se han

utilizado las herramientas que ofrece Simulink

para el cálculo de los reguladores a partir del

sistema y la salida deseada.

3. Descripción del sistema y análisis de la

propuesta de regulador.

En este trabajo se plantea la regulación de un

motor de corriente continua (CC) con escobillas

de carbón de la marca Mabuchi Motors (RS-

455PA) [9]. Desarrolla una potencia de 3 a 65 W

alimentándolo con una tensión de hasta 42 voltios.

Las características dinámicas del motor se

muestran en la figura 2.

Figura 2. Características dinámicas del motor.

El motor mostrado es un motor de CC diseñado

específicamente para aplicarse en un sistema de

control. El funcionamiento del sistema está basado

en la tensión de entrada que se aplica a la bobina y

a la resistencia del circuito. Esta tensión produce

una corriente por estos componentes que generan

un par motor que, a su vez, produce la rotación del

motor. La propia rotación genera una tensión en

sentido inverso a la de entrada, llamada tensión

contraelectromotriz, que se opone a la tensión de

entrada, esta tensión contraelectromotriz actúa

como realimentación del sistema, y que se resta a

la tensión de entrada. La figura 3 muestra un

diagrama explicativo del mismo.

Figura 3. Motor controlado por inducido.

Las ecuaciones que definen el funcionamiento del

sistema son cuatro, todas ellas lineales, por lo que

se le podrán aplicar directamente la transformada

de Laplace:

La ecuación de entrada es la ley de Kirchoff, que

toma la tensión de entrada menos la tensión

contraelectromotriz y relaciona la intensidad que

pasa por los componentes eléctricos pasivos del

sistema (resistencia y bobina).

dt

diL)t(RI)t(V)t(V CEMIN

(1)

La segunda ecuación es la que toma la intensidad

que pasa por el circuito y la relaciona con el par

motor, existe una constante que la relaciona Kp,

siendo esta relación directamente proporcional.

)t(IK)t(P P (2)

La relación que existe entre el par motor y el

ángulo girado por el motor es el definido en la

siguiente ecuación

dt

dB

dt

)t(dJ)t(P

2 (3)

Siendo J la inercia de la combinación del motor,

carga y tren de engranaje referido al aje del motor

y B es el coeficiente de fricción viscosa de la

combinación del motor, carga y tren de engranaje

referido al eje del motor.


17

Esta ecuación se puede simplificar porque la

velocidad angular ω (t) es la derivada del ángulo

girado θ.

dt

d)t( (4)

La ecuación definitiva del sistema queda de la

siguiente forma:

)t(Bdt

dJ)t(P (5)

La última ecuación que define a este sistema es la

que actúa como realimentación, que relaciona la

velocidad de giro del motor con la tensión

contraelectromotriz generado por este, que es

directamente proporcional entre ambos y con una

constante de proporcionalidad Ke.

Aplicando la transformada de Laplace, nos queda

la siguiente función de transferencia para el

sistema:

eP

P

KKBJsRLs

K)s(G (6)

El sistema, con función de transferencia G(s) y

representado en la figura 4, es un sistema de

segundo grado. Su entrada es la tensión aplicada

al motor, y su salida la velocidad de giro en

radianes.

Figura 4. Diagrama de bloques del sistema de segundo

orden asociado al modelo del motor CC.

Para obtener los parámetros asociados al modelo

real, se recurrió al modelado mediante el tiempo

de subida del sistema ante la respuesta escalón.

Según este método se calculan dos de los tiempos

en la respuesta del sistema y a partir de ellos se

obtiene la función característica. En la figura 5 se

muestra la respuesta del sistema. Sustituyendo los

valores en la ecuación 7 se obtiene la respuesta del

sistema.

La función de transferencia obtenida a partir de la

ecuación 1 es la siguiente:

Figura 5. Respuesta del sistema ante la entrada escalón.

En ella se encuentran dos polos situados en los

puntos -999.996 y -58.823 del semiplano

negativo. Para poder trabajar con sistemas

discretos se discretiza mediante el método

trapezoidal. Se ha escogido este método por ser

uno de los que mejor respuesta ofrecen [6]. Tras

su aplicación se obtiene la siguiente función:

Actualmente existen multitud de metodologías

para el diseño de reguladores PID. Una de ellas es

el método de Ziegler Nichols. Este método parte

de la respuesta del sistema ante la entrada escalón

y obtiene las ganancias de las distintas acciones

(Kp, Ti y Td). La tabla 1 muestra las acciones y

como se obtienen las ganancias para este tipo de

regulador.

Kp Ti Td

PID 1.2*T/L 2L 0.5L

Tabla 1. Modelo PID según Ziegler-Nichols

En comparación con la figura 5, los

parámetros L y T corresponden a las variables T1

y T2. El modelo que ofrece Ziegler Nichols es un

punto de partida para posteriores ajustes hasta

alcanzar la respuesta deseada. De forma que se

han escogido los parámetros para que el tiempo

respuesta a la entrada escalón sea de 18 ms. El

regulador resultante discretizado es el siguiente:


18

Tal y como se indica en la figura 6, la

implementación del regulador se ha realizado

sumando las tres acciones en paralelo.

Figura 6. Módulos PID detalle.

Las acciones integral y derivativa incluyen una

función de transferencia que se implementa, al

igual que en el caso del regulador PI, a partir de

ecuaciones en diferencias. La ecuación 11

corresponde a la acción integral, y la 12 a la

acción derivativa.

4. Implementación hardware

La implementación hardware consta de los

siguientes elementos para implementar dicha

ecuación: sumadores, multiplicadores y retardos

(aquellos factores desplazados en el tiempo (xk-1)).

Para los multiplicadores se ha seguido el diseño

basado en desplazamientos expuesto en el

apartado 2. De esta manera los retardos son

mínimos y se facilita la tarea de sincronización de

señales. Los retardos se han diseñado usando

biestables tipo D. Con estos biestables la señal se

propaga hacia la salida en el momento que detecta

una subida de la señal de reloj. En este caso la

señal de reloj está conectada al bloque

frecuencímetro, que genera un pulso cuando hay

una nueva muestra. De forma que se genera un

nuevo valor del regulador cada vez que se obtiene

un nuevo valor de frecuencia. Puesto que solo se

usan valores enteros, las constantes de escalado se

han aproximado.

La puesta en marcha del regulador mediante la

FPGA ha requerido el soporte y una serie de

etapas de adaptación de señales y potencia que se

describen a continuación (Figura 7).

Figura 7. Sistema completo.

Para realizar la realimentación del sistema se ha

acoplado un encoder incremental MICRONOR

AG modelo Eni38L.1362.0200 al eje del motor.

La salida del encoder se ha conectado a una puerta

‘Schmitt trigger’ para evitar falsos valores. El tren

de pulsos que entra a la FPGA es procesado para

obtener la frecuencia de los pulsos. El cálculo de

la inversa se realiza mediante un módulo IP

divisor.

Los valores de salida del cálculo del regulador se

programan en la FPGA para generar una salida

PWM doble (conducción positiva y negativa).

Dicha salida es filtrada y posteriormente

modelada mediante dos etapas de adaptación

basadas en reguladores operacionales. Estas

señales ponen en marcha la conducción de los

transistores que ponen en marcha el motor que se

encuentra en el centro de un puente en H. Este

tipo de etapa de potencia permite poner en marcha

el sistema ante salidas tanto de valores positivos

como negativos.

Figura 8. Etapa de potencia.


19

Por tanto. el montaje resultante se representa en

la figura siguiente.

Figura 9. Montaje completo.

Los resultados de ocupación, limitaciones

temporales y uso de memoria del sistema

completo, incluyendo a lo antes expuesto un

módulo para visualizar la velocidad en el display

de 7 segmentos doble son los reflejados en la tabla

2.

Dispositivo

xc6slx45

Slice Registers 1.531 (2%)

Slice LUTs 2.225 (8%)

Slice Logic

Distribution 711 (10%)

IO Utilization: 31 (14%)

Minimum period 8.332ns

Maximum

frequency 121.242MHz

Tabla 2. Resultados de la ocupación

Gráficamente, el uso de la FPGA se refleja en la

figura 10a y 10b. La figura 10a se ha generado

mostrando líneas de datos creadas por el

compilador. La figura 10b muestra la ocupación

de los bloques lógicos dentro de la FPGA.

5. Resultados.

Para verificar la efectividad del sistema se ha

sometido al mismo a distintas entradas para

comprobar la efectividad de la regulación. Todas

las respuestas se han comparado con los

resultados obtenidos mediante simulación

utilizando la herramienta Matlab. La frecuencia

a)

b)

Figura 10. (a) Plano de ocupación de las líneas de datos.

(b) Plano de ocupación de los bloques lógicos.


20

de muestreo del sistema real no es constate,

depende de la frecuencia de pulsos de entrada del

encoder incremental: a cada flanco de subida de la

señal del sensor, se lanza un nuevo cálculo y se

genera un nuevo valor a la salida del regulador.

El rizado que aparece en la salida del sistema

real tiene origen en el sistema de lectura. La

precisión del cálculo de la frecuencia es la

principal causa de que los valores oscilen. La

figura 11 muestra la salida del sistema ante la

entrada escalón con un valor inicial cero y final de

47Hz. El gráfico teórico y el real tienen por escala

temporal 10 ms/ div.

La figura 12 muestra la respuesta del sistema ante

un valor transitorio, partiendo de un valor inicial

de 8 Hz y alcanzando n valor final de 40. La

escala temporal de los dos gráficos es la misma

que la anterior.

En esta ocasión se observa que el sistema real es

un poco más lento, pero que sigue la respuesta

teórica. La bajada de un valor de 47 rpm a cero se

muestra en la figura 13. El gráfico se ha ajustado

para que las escalas temporales sigan

coincidiendo.

Figura 11. Respuesta ante el escalón, simulada (a) y real

(b).

Figura 12. Respuesta ante el escalón transitorio. (a)

simulada y (b) real.

Figura 13. Bajada escalón. (a) simulada, (b) real


21

6. Conclusiones

Los resultados prácticos muestran la potencialidad

de este método y cómo se puede conseguir de

forma práctica la regulación de un motor CC.

El siguiente paso propuesto es aprovechar las

ventajas que presenta el actual método de

implementación y aplicarlo a otros sistemas de

regulación como son el VSC y otros métodos de

regulación moderna. Algunos autores ya han

realizado algunas implementaciones con este

método utilizando herramientas como Maltab-

Xilinx System Generator [10] obteniendo

respuestas satisfactorias. Los satisfactorios

resultados presentados demuestran como con

métodos convencionales y de bajo coste se pueden

conseguir resultados aceptables y concluyentes.

7. Referencias

[1] E. Monmasson, L. Idkhajine, M.W. Naouar,

“FPGA-based Controllers, Different

Perspectives of Power Electronics and Drive

Applications”, Industrial Electronics

Magazine, IEEE, vol. 5, no. 1, pp. 14 - 26,

March 2011.

[2] A. Trimeche, A. Sakly, A. Mtibaa, “PID

Control Implementation using FPGA

Technology”, 3rd International Design and

Test Workshop, pp. 341-344, IDT 2008.

[3] J. Lima, R. Menotti, J.M.P. Cardoso, E.

Marques , “A Methodology to Design FPGA-

based PID Controllers”, IEEE International

Conference on Systems, Man, and

Cybernetics, Taipei, Taiwan, vol. 3, pp. 2577

– 2583, October 8-11, 2006.

[4] Z. Fang, J.E. Carletta, R.J. Veillette, “A

Methodology for FPGA-Based Control

Implementation”, IEEE Trans. Contr. Syst.

Tech., vol. 13, no. 6, pp. 977-987, november

2005.

[5] M. Petko, G. Karpiel, “Semi-Automatic

Implementation of Control Algorithms in

ASICIFPGA”, IEEE Conference Emergign

Technologies and Factory Automation,

ETFA'03, vol. 1, pp. 427-433, 2003.

[6] Á. De Castro Martín, “Aplicación del control

digital basado en hardware específico para

convertidores de potencia conmutados.”, tesis

doctoral, Universidad Politécnica de Madrid,

2003.

[7] Xilinx website: http://www.xilinx.com/

[8] K. Ogata, “Ingeniería de control moderna”, ed.

Prentice-Hall , 3ª ed., México, 1998.

[9] Mabuchi Motors Documentation. RS-455PA

[10] En blanco para el proceso de revisión.


22

http://www.xilinx.com/

Resumen—Esta contribución describe la implementación de un Core Time-to-Digital Converter (TDC) de alta resolución temporal integrado en un dispositivo Field-Programmable Gate Array (FPGA) capaz de obtener diferencias temporales inferiores a 100 ps para 4 canales simultáneos. Para ello, se ha usado la estructura interna de las últimas familias de FPGAs basadas en lógica de acarreo y un estricto proceso de calibrado. Asimismo, se demuestra la idoneidad del uso del TDC en sistemas Positron Emission Tomography (PET), ofreciendo la posibilidad de determinar el Time of Flight (TOF). Una técnica que incorporan pocos PET en el mercado debido a su complejidad, y que conlleva múltiples ventajas que se detallarán en este texto.

Palabras clave — PET, TOF, TDC, Medicina Nuclear, Resolución.

I. INTRODUCCIÓN

A medicina nuclear ha avanzado significativamente en los últimos años debido al

aporte que la tecnología ha proporcionado en términos de mejora de resolución y precisión en los sistemas empleados. Una de las técnicas que más ha avanzado en este ámbito ha sido la Tomografía por Emisión de Positrones (PET), basada en un método no invasivo y muy útil para la evaluación de diversas anomalías. Este sistema está basado en una técnica médica mediante la cual se obtienen imágenes de la distribución espacial y temporal de los procesos metabólicos que se generan en el interior del organismo [1].

Los sistemas PET están formados por un conjunto de detectores, colocados habitualmente en anillo, de forma que cada uno de ellos proporciona información acerca de los eventos que se han producido en su interior. Uno de los motivos por el que han evolucionado de forma tan significativa los sistemas PET ha sido el surgimiento de técnicas que permiten determinar el Tiempo de Vuelo (TOF) [2] debido a las ventajas que ofrece, tales comomenores tiempos de exposición del paciente al tener que emplear una dosis menor de radiofármaco o la obtención de mejor calidad de imagen para un mismo número de detectores. Este parámetro permite determinar con mayor precisión dentro de la Línea Espacial de Eventos Deseados (LOR) la posición en la que se ha producido la aniquilación [3] y, por tanto, se pueden localizar con más exactitud los tumores que presenta el paciente. En la figura 1 se muestra un anillo en el que se produce una aniquilación y las posibles formas de localizarla, en A se emplea un detección convencional y en B mediante el cálculo del TOF.

Todos los autores pertenecen al Grupo de Diseño de Sistemas Digitales y de Comunicaciones (DSDC) del Departamento de Ingeniería Electrónica de la Universidad de Valencia. Escuela Técnica Superior de Ingeniería, Avda. de la Universidad, s/n. 46100 – Burjassot. e-mail: [email protected]

Fig. 1. Detección de aniquilaciones en un sistema PET.

Entre las diversas alternativas que existen para la implementación del cálculo del TOF, en esta contribución se ha empleado una solución digital basada en un dispositivo FPGA de bajo coste. Las principales características que se han valorado de este tipo de dispositivos han sido, tanto la excelente relación precio-prestaciones como la versatilidad que proporcionan las FPGAs al ser reconfigurables, comparado con otras alternativas clásicas y mucho más caras basadas en ASICs. Otras ventajas de las FPGAs que se han aprovechado en este trabajo son la elevada tasa de transferencia que presentan, la gran velocidad de procesado y la posibilidad de trabajar simultáneamente con un número elevado de señales.

Además de estas características, las FPGAs poseen una estructura interna mediante la que es posible medir tiempos con elevada precisión, lo que favorece el cálculo del TOF [4]. Sus estructuras internas repetitivas, facilitan la implementación de cadenas de retardo, las cuales se configurarán de manera que puedan medir tiempos del orden de centenares de pico segundos. Para poder obtener resoluciones temporales de tal magnitud, generar las etiquetas temporales para cada señal de entrada y realizar la medida del TOF con una resolución muy inferior a la frecuencia del reloj del sistema, se ha integrado en la FPGA un Core Time-to-Digital Converter (TDC) que ha sido programado en VHDL.

Después de realizar diferentes pruebas de simulación del Core TDC [5], para verificar que su resolución temporal es inferior a 100 ps, se han llevado a cabo una serie de modificaciones en la arquitectura con el objetivo de que pueda realizar la adquisición de varios detectores al mismo tiempo sin que la resolución temporal se vea afectada. En síntesis, se ha implementado un Core TDC multicanal adaptado para obtener las etiquetas temporales y determinar el TOF en un sistema PET. De este modo, el TDC formará parte del sistema de Trigger que necesita el sistema de adquisición del PET para determinar el TOF, indicando

L

Implementación de un Core TDC multicanal de alta resolución para sistemas PET

Albert Aguilar, Raimundo García-Olcina, Iván Leiva, Pedro A. Martínez, Julio Martos, Jesús Soret, Adrián Suárez y José Torres


23

que se ha producido una coincidencia. Para ello, se envía una señal de Start/Stop al sistema de adquisición del PET empleando una ventana temporal mediante la cual se espera a que se produzca una aniquilación. Se considera que una coincidencia es verdadera cuando los detectores reciben dos partículas gamma de la misma aniquilación en sentidos opuestos. No obstante, en esta ventana también es posible detectar coincidencias no verdaderas, como pueden ser las aleatorias, en las que se producen dos aniquilaciones seguidas y únicamente se detecta una; o las coincidencias dispersas en las que la LOR se asigna incorrectamente. El TOF toma gran importancia en este sentido ya que permite disminuir la ventana temporal para reducir el número de coincidencias no verdaderas. En la figura 2 se muestran los tipos de coincidencias mencionados.

Fig. 2. Tipos de eventos de coincidencias para PET.

Gracias al empleo del TOF es posible reducir dicha ventana en gran medida con los correspondientes beneficios que esto ofrece: menor tiempo de adquisición para un determinado detector, menor tasa de datos necesaria y mayor precisión a la hora de detectar un tumor de pequeño tamaño que con otros sistemas no se podría observar. Esta parte es clave, puesto que los falsos negativos (al paciente se le realiza la prueba y no se observa el tumor) son una de las principales causas de tumores no tratados correctamente en la actualidad.

En esta contribución se expone cómo se realiza la obtención de las etiquetas temporales a partir de los registros internos de acarreo de la FPGA para múltiples canales. Asimismo, se muestran las ventajas que ofrece el cálculo del TOF en sistemas PET y la arquitectura del sistema que se ha implementado. A continuación, se muestra la implementación del TDC adaptado para la adquisición de 4 canales y los resultados que se han obtenido a partir del entorno desarrollado con la plataforma LabVIEW, que permite la visualización de los resultados en tiempo real.

II. ARQUITECTURA DEL SISTEMA

Llegados a este punto, se puede realizar una visión global del sistema y ubicar el TDC presentado en esta contribución. De este modo, el TDC se integrará como Core o periférico en la FPGA realizando las funciones ya comentadas y, del mismo modo, el dispositivo FPGA pasará a formar parte de la tarjeta de Trigger dentro del sistema electrónico del PET. Por ende, el TDC se encargará de generar etiquetas temporales y de enviarlas a MicroBlaze (Microprocesador Software de 32 bits de Xilinx) que recuperará la etiqueta temporal y el número de canal, aplicará un algoritmo con el fin de determinar si se ha producido una coincidencia. En ese caso se activa la señal de disparo y también se proporciona información adicional sobre la coincidencia. En la figura

3 se muestra la estructura general del sistema PET en el que se integra el TDC.

Fig. 3. Arquitectura del sistema PET.

Las funciones principales que realiza el TDC son la detección de eventos o coincidencias y proporcionar la medida del TOF de los mismos para los diferentes canales de entrada. Para ello, se ha integrado el Core TDC en una FPGA de la familia Spartan-6 de Xilinx que cuenta con los bloques de acarreo necesarios para poder implementar las líneas de retardo (delay line) de cada canal que, mediante la conformación de determinados elementos, permiten obtener resoluciones del orden de centenares de picosegundos. Igualmente, se integrará dentro de la FPGA MicroBlaze dado que será el encargado de realizar la gestión de los datos procedentes del Core TDC y el control del resto de periféricos del sistema. En la figura 4 se muestra un esquema conceptual de la estructura interna del TDC implementado.

Fig. 4. Esquema básico de la implementación del TDC.

La etiqueta temporal que el TDC generará posee una longitud de 12 bits por lo que el LSB se corresponde con tiempos del orden de 1,2 ps debido a que el sistema emplea un reloj de 200MHz, es decir, de 5ns de periodo.

Cabe prestar especial atención a la estructura interna de la línea de retardo empleada puesto que es la encargada de proporcionar una resolución temporal tan precisa. Cada etapa de la línea de retardo corresponde a un elemento MUXCY de los bloques CARRY4 de acarreo que la FPGA posee internamente. En la figura 5 se puede observar la estructura de la línea de retardo que se emplea en el TDC basada en la línea de Vernier [6] para medir tiempos inferiores a la frecuencia del reloj del sistema.


24

Fig. 5. Esquema interno de una línea de retardo en la FPGA.

La comunicación de MicroBlaze con los periféricos y Cores se establece mediante el bus PLB (ProcessorLocal Bus) que sigue el estándar de arquitectura de bus CoreConnect de IBM y está formado por maestros, esclavos, árbitro de bus encargado de gestionar las peticiones y prioridades del bus e interconexiones realizadas mediantes bridges.

Como se muestra en la figura 3, el Core TDC se encuentra integrado como periférico de MicroBlaze en la FPGA, se comunica a través del bus PLB, pero para poder realizarlo correctamente emplea el protocolo simplificado IPIC (IP Interconnect) que permite acceder al bus PLB de formo más sencilla empleando el interfaz IPIF (Intellectual Property Interface). Es importante mencionar que el desarrollador dispone de dos interfaces para comunicar MicroBlaze con un periférico: mediante la lectura/escritura de registros y/o mediante el empleo de una FIFO.

III. IMPLEMENTACIÓN

En este trabajo se ha implementado un TDC de 4 canales en el kit de desarrollo Atlys de la empresa Digilent que incluye una FPGA xc6slx45 de la familia Spartan-6 y que cuenta con las primitivas CARRY4 [7].

En la figura 6 se muestra una captura de los 4 canales distribuidos dentro de la FPGA. Cabe destacar que las 4 trazas rojas representan las 4 líneas de retardo necesarias (una para cada canal) y cada una de ellas está formada por 124 bloques CARRY4 conectados entre sí en cascada.

Fig. 6. Distribución de los canales dentro de la Spartan-6 empleada.

Debido a que el retardo de los elementos de la línea no es homogéneo, es necesario realizar un proceso de calibrado inicial. Este proceso consiste en determinar el retardo de cada uno de los elementos de la línea a través de inyectar pulsos aleatorios generados internamente por un oscilador, que hará que las etapas con mayor retardo registren más muestras. Una vez determinados los tiempos, cada valor es almacenando en una LUT.

Para describir el uso del nuevo TDC de hasta 4 canales se ha empleado un generador de funciones para simular la llegada de eventos a los diferentes canales. En la figura 7 se muestra la configuración que se ha implementado para simular el comportamiento de un sistema PET de 4 canales.

Fig. 7. Esquema de configuración para 4 canales.

Dentro de la FPGA, esta señal se distribuye progresivamente en cada una de las 4 líneas de retardo. Esta configuración permite medir los diferentes retardos con respecto al canal 1 teniendo en cuenta que, conforme aumenta el número de canal, el rutado interno es mayor y, por tanto, los canales superiores tendrán mayor retardo que los más cercanos al canal 1. En la figura 8 se muestra cómo se obtiene la señal de entrada desde el pin de la FPGA, se bifurca para obtener la señal de entrada del canal 1 y la señal que se conectará a las 3 líneas de retardo restantes (línea amarilla). A su vez, se observa la interconexión de la señal de entrada con el primer bloque de acarreo CARRY4 de la línea de retardo (bloques rojos) correspondiente al canal 1.

Fig. 8. Histograma de retardos de una línea de retardo caracterizada.

Como ya se ha comentado, las líneas de retardo están formadas por bloques CARRY4. Para que no haya grandes retardos entre bloques, se han emplazado de forma ordenada y lo más cercanos los unos de los otros mediante restricciones hardware. Para fijar dichas restricciones se ha generado un proyecto en el entorno Project Navigator de la suite Xilinx ISE Design y se ha


25

añadido como “Embeded Processor” el proyecto de MicroBlaze programado con la herramienta Xilinx Platform Studio (XPS). Una vez sintetizado el proyecto en Project Navigator, se ejecuta desde el mismo el entorno PlanAhead ya que será el software empleado para obtener las Slices en las que se desea fijar las líneas de retardo. Una vez analizada la estructura interna de la FPGA y decidido las posiciones en las que se desean ubicar las líneas, se incluyen las restricciones en XPS para que, al generar el hardware, el sintetizador las considere.

IV. RESULTADOS.

La visualización de los resultados se realiza mediante un entorno de usuario programado con la herramienta gráfica LabVIEW. MicroBlaze realiza continuamente la lectura de los registros del Core TDC y los carga en el periférico UART para que sean enviados mediante comunicación serie al entorno de usuario. Desde el panel frontal del entorno es posible visualizar en tiempo real las representaciones de las diferencias temporales entre el primer canal y los tres restantes. Para determinar la resolución temporal del sistema se analiza el valor FWHM (Full Width at Half Maximum) del ajuste gaussiano del histograma de cada canal.

Fig. 10. Visualización de las diferencias de tiempo entre los canales 1 y del 2 al 4 en el entorno de LabVIEW.

Estas representaciones se distribuyen de forma Gaussiana mediante la cual es posible determinar la resolución del sistema. Cabe destacar que la separación que existe entre cada histograma se debe al retardo del rutado interno que se ha realizado en la FPGA, como se ha mencionado en el apartado anterior. Estudiando este valor para todos los canales, se obtiene una resolución inferior a 100 ps, valores muy inferiores a los que se pretendía mantener ya que tras realizar diferentes pruebas empleando 100.000 muestras se ha obtenido una media de 50-75 ps de resolución temporal.

En la figura 10 se muestran los 3 histogramas correspondientes a la diferencia temporal entre el primer canal y los otros tres dentro del entorno mencionado. En la figura 9 se ilustra un histograma obtenido con el programa de cálculo estadístico y análisis de datos Origin mediante el que se ha determinado el valor de FWMH entre el canal 1 y 4 con el objetivo de verificar que los datos obtenidos en el entorno de usuario son coherentes.

Fig. 9. Histograma de diferencias temporales entre canal 1 y 4.

V. CONCLUSIONES

En este trabajo han sido testeadas las capacidades que poseen las FPGAs para realizar medidas precisas de diferencias temporales. Se ha mostrado la posibilidad de medir intervalos de tiempo inferiores a 100 ps, permitiendo obtener, en última instancia, imágenes de mayor calidad en los sistemas PET. El encargado de proporcionar las etiquetas temporales es el Core TDC basado en líneas de retardo de Vernier e integrado dentro de la FPGA.

Para conseguir la precisión deseada se ha detallado el proceso de calibración que realiza el TDC para las medidas temporales realizadas, empleando para ello un oscilador interno. Finalmente, se han expuesto los resultados obtenidos al implementar 4 canales en el TDC y se ha verificado que se mantiene la resolución temporal inicial presentada para 2 canales a partir del entorno de visualización desarrollado en LabVIEW que proporciona información de las medidas que realiza el sistema en tiempo real.

Otro aspecto en el que se está trabajando es en la implementación de un web server para realizar la representación de los datos empleando para ello una conexión Ethernet dado que permite una transmisión de datos muy superior a la comunicación serie. Además, ofrece la posibilidad de realizar la configuración del sistema a distancia a través de cualquier dispositivo que posea acceso a internet.

REFERENCIAS

[1] J. López Herráiz, “Técnicas avanzadas de reconstrucción de imagen PET, X-CT y SPECT”, Memoria de Trabajo De Master de Física Biomédica, Universidad Complutense de Madrid, pp. 17-19 (2008).

[2] J. Torres et al., “High resolution Time of Flight determination based on reconfigurable logic devices for future PET/MR systems”, Nuclear Instruments & Methods In Physics Research A, http://dx.doi.org/10.1016/ j.nima.2012.08.034, (2012).

[3] P. Guerra, “Physics and Design of Detectors for SPECT and PET: Fully digital acquisition systems for PET/SPECT”, IEEE Nuclear Science Symposium and Medical Imaging Conference (2011).

[4] M. D. Haselman, et al., “Digital pulse timing in FPGAs for Positron Emission Tomography”, CiteSeerX - Scientific Literature Digital Library, doi 10.1.1.152.3344, (2010).

[5] J. Torres et al., “Determinación del tiempo de vuelo en sistemas PET basados en FPGAs”, Actas de las XII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA2012), ISBN: 978-84-695-4470-9, pp. 53-55 (2012).

[6] W. Gao et al., “Integrated High-Resolution Multi-Channel Time-to-Digital Converters (TDCs) for PET Imaging”. N. Laskovski (Ed.), ISBN: 978-953-307-475-7, pp. 306-307.

[7] www.xilinx.com/support/documentation/data_sheets/ds162.pdf


26

Capítulo 2

Lenguajes de Alto Nivel y Comparativas

Capítulo 2- Lenguajes de Alto Nivel y Comparativas A Study of Sorting Algorithm in FPGA using High Level Languages Marta Cuaresma (Universidad Autónoma de Madrid), Gustavo Sutter (Universidad Autónoma de Madrid), Francisco Gomez-Arribas (Universidad Autónoma de Madrid) Clasificación de paquetes IP a 10 Gbps descripto desde lenguajes de alto nivel Marco Forconesi (Universidad Autónoma de Madrid), Gustavo Sutter (Universidad Autónoma de Madrid), Sergio Lopez-Buedo (Universidad Autónoma de Madrid), Francisco Gomez-Arribas (Universidad Autónoma de Madrid) Mapeo automático de sistemas basados en OpenCV en los nuevos SoCs heterogéneos Francisco José Sanchis-Cases (University of Alicante, Spain), Antonio Martínez-Álvarez (University of Alicante), Sergio Cuenca-Asensi (University of Alicante) Reducción de los tiempos de cómputo de la Migración Sísmica usando FPGAs y GPGPUs: Un artículo de revisión. Carlos Fajardo (Universidad Industrial de Santander, Colombia), Javier Castillo Villar (Universidad Rey Juan Carlos, Spain), Cesar Pedraza (Universidad Santo Tomas, Colombia), José Ignacio Martínez (Universidad Rey Juan Carlos)

A Study of Sorting Algorithm in FPGA using High Level Languages

Marta Cuaresma, Gustavo Sutter, Francisco Gómez Arribas [email protected], [email protected], [email protected].

Escuela Politécnica Superior, Universidad Autónoma de Madrid.

Summary Data sorting is a central operation in many high performance computing and embedded applications. This work studies how some sorting algorithms perform in FPGA. We optimize these algorithms looking for compact and fast algorithm. The results shows that the classical recursive algorithm with worst computation time O(N.log N) carefully transformed in iterative can be efficiently implemented in FPGA. Additionally the Radix Sort, a non-comparing sort for natural number gives good results.

1. Introduction

The sorting algorithms have been investigated since the beginning of computing [1][2][3]. There are a lot of well-known and systematically analyzed and optimized algorithms for different problem sets, with different average runtimes and memory needs. Nevertheless, in FPGA the studies are scare. Using reconfigurable logic, there are works that deals with sorting networks [4][5][6], but this circuits are practical restricted to few elements to be ordered. Other works concentrate in accelerate the sorting problem of big amount of data, there are using mainly the FPGA as coprocessor [7][8][9]. Finally there are others works that study sorting for specific domains problem [10][11].

The study of sorting algorithm depends on many operation conditions and needs. For our study we have restricted to the following conditions: - Sort 32 bit natural numbers (unsigned

integers)

- The data are in internal FPGA memory (BRAMs) and after the sorting will be stored at the same memory.

- The number of unsorted integers are in the range [25, 212] = [32, 4096], i.e. up to 8 BRAMs.

- The optimization criteria is speed (reduce cycles of computation) but maintaining a reduced amount of resource usage.

- The internal BRAMs are true dual port RAMs. For big arrays array reordering can be study in order to improve throughput.

In order to explore faster the design space, the circuits were described C, and synthetized using Vivado-HLS [12] targeting a Xilinx Virtex 7 device [13].

The rest of the article is organized in five sections. In section II the studied algorithm are introduced. Section III depicts the modifications and improvement of the seven select sorting algorithm. Section IV analyses the implementation results. Section V presents conclusion and future work.

2. Sorting algorithm

For this work we have selected three O(N2) algorithm (Bubble Sort, Selection Sort and Insertion), three O(N.log N) algorithm (Heap Sort, Quick Sort, and Merge Sort) and a non-comparison sort algorithm: Radix Sort. Many books deals and explain the different approaches [1][2]. There also in many online surveys and explanation available at [3][14].

Table 1 resumes the expected execution time using big-O notation and the extra memory necessary, being N the number of element to be sorted, and K stand for number of keys (in case of Radix Sort).


31

Table1. Average and work case execution time and the extra memory necessary for the studied sorting algorithm.

Sorting Algorithm

Average case

Worst case

Extra Mem

Bubble sort N2 N2 - Insertion sort N2 N2 - Selection sort N2 N2 - Quick sort N.log N N2 N Merge sort N.log N N.log N N Heap sort N.log N N.log N - Radix sort K.N K.N K+N

For an efficient hardware implementation, it is

important not only the amount of memory accesses (reads and writes), but also the pattern of these access. This determines the the pipeline initiation interval (II) and the possibility of parallelism.

3. Details of algorithm implementation

In what follow we describe the implemented algorithm, highlighting the modifications and improvements done.

3.1. Bubble Sort

The algorithm starts at the beginning of the data set. It compares the first two elements, and if the first is greater than the second, it swaps them. It continues doing this for each pair of adjacent elements to the end of the data set.

Algorithm 1. Näive Bubble Sort. void bubble_sort(v_type A[N]){ long c, d; v_type t; L_ext: for (c=0; c<(N-1);c++){ L_int: for (d=0;d<N-c-1;d++){ if (A[d] > A[d+1]) {//Swap t = A[d]; A[d] = A[d+1]; A[d+1] = A; } } } } The code was optimized in order to read and write only one element per iteration. Then the code can be pipelined (directive PIPELINE in L_int). Since the access is sequential we can add inter dependence to false (directive DEPENDENCE inter false to L_int).

Algorithm 2. Optimized Bubble Sort. void bubble_sort(v_type A[N]){ long c, d; v_type v1, v2, v3; L_ext: for (c=0; c<(N-1);c++){ v1 = A[0]; L_int: for (d=0;d<N-c-1;d++){ v2 = A[d]; if (v1 > v2){//Swapping A[d-1] = v2; /*v1=v1*/ } else { A[d-1] = v1; v1 = v2;} } A[N-c-1] = v1; } }

3.2. Insertion Sort

It works by taking elements from the list one by one and inserting them in their correct position. That implies to move the rest of elements.

Algorithm 3. Näive Selection Sort. void insertion_sort(v_type A[N]){ int i, j; v_type ind; L_ext: for (i=1; i < N; i++){ ind = A[i]; L_int: for (j=i-1;j >= 0 && A[j] > ind; j--){ A[j+1] = A[j]; } A[j+1] = ind; } } The natural optimization is to pipeline the inner loop. The pipeline of this algorithm does not allow obtaining II (Initiation Interval) of 1 because the dependence between the read of the memory and the break condition of the loop.

3.3. Selection Sort

The algorithm finds the minimum value, swaps it with the value in the first position, and repeats these steps for the remainder of the list.

Algorithm 4. Naïve Selection Sort void selection_sort(v_type A[N]){ int i,j; vector_t iMin, aux; for (j = 0; j < N-1; j++) { iMin = j; /* find the min */ for (i = j+1; i < N; i++) { if (A[i] < A[iMin]) iMin=i;

Capítulo 2: Lenguajes de Alto Nivel y Comparativas

32

} if ( iMin != j ) {//swapping aux = A[j]; A[j] = A[iMin]; A[iMin] = aux; } } } The first optimization reduces the memory access and pipeline the inner loop (Inn_L). We can obtain II=1.

Algorithm 5. Selection Sort. Optimized V1 void selection_sort(v_type A[N]){ int i,j,iMin; v_type Min; out_L: for (j=0; j<N-1; j+=1) { iMin = j; Min = A[j]; Inn_L: for(i=j+1; i<N;i+=1) { if (A[i] < Min_1) { Min = A[i]; iMin = i; } } if ( iMin_1 != j ) {//swap A[iMin]= A[j]; A[j]= Min;} } } A second optimization comes to use the dual port characteristic of the BRAM reading two values per cycle (algorithm 6). It is possible also pipeline the inner loop with II=1.

Algorithm 6. Selection Sort. Optimized V2 void selection_sort(v_type A[N]){ int i, j, jj, iMin_1, iMin_2; v_type Min_1, Min_2,V_1,V_2; out_L: for (j=0; j<N-1; j+=1) { iMin_1 = j; Min_1 = Arr[j]; Inn_L: for (i=j; i<N-1; i+=2) { V_1 = A[i]; V_2 = A[i+1]; if ((V_1<=V_2)&&(V_1<Min_1)){ Min_1 = V_1; iMin_1 = i; } else if((V_2<V_1)&&(V_2<Min_1)){ Min_1 = Val_2; iMin_1 = i+1; } } if (iMin_1 != j ) {// swap A[iMin_1] = A[j]; A[j] = Min_1; } } } A third optimization extends this idea, not only reading two values per clock cycle, but also recording the two minimum values during the

inner loop (Inn_L). At the end of the loop, two values are stored, and then the outer loop (out_L) executes half times.

3.4. Merge Sort

Merge sort is a recursive algorithm. For a HW implementation it is necessary to transform in a sequential implementation. The sequential code starts by comparing every two elements (i.e., 1 with 2, then 3 with 4...) and swapping them if the first should come after the second. It then merges each of the resulting lists of two into lists of four, then merges those lists of four, and so on; until at last two lists are merged into the final sorted list. Algorithm 7 presents a Näive version of Merge Sort. Observe that uses an additional array (B) to store intermediate values.

Algorithm 7. Naïve Merge Sort. void merge_sort(v_type A[N]){ v_type B[N]; v_type V0, V1; int w, i, j, i0, iLeft, i1, iRight, iEnd; /* Each 1-element in A is already ‘sorted’. Make in turn longer runs of length 2,4,8,16... until whole array is sorted. */ L_ext: for (w=1; w<N; w=2*w) { L_int: for (i=0; i<N; i=i+2*w){ i0 = iLeft = i; i1 = iRight = i+w; iEnd = i+2*w; V0 = A[i0]; V1 = A[i1]; L_inn: for(j=i; j<i+2*w;j++){ /* If left list head exists and is <= existing right list head */ if (i0 < iRight && (i1>=iEnd || V0<=V1)) { B[j] = V0; i0 = i0 + 1; V0 = A[i0]; } else { B[j] = V1; i1 = i1 + 1; V1 = A[i1];} } } /* Now array B is full of runs of length 2*w, Copy array B to A for next iteration. */ L_cp:for(i=0;i<N;i++)A[i]=B[i]; } }


33

A first optimized version pipelines the L_inn loop and obtain II=2 and the copy loop (L_cp) with II=1. A second optimization (Merge_v2) avoids the copy using a swap of Array A and B. That’s imply to execute an even times the L_ext loop in order to have the result in A. Otherwise the result is in B and should be copied to A. The third optimization (Merge_v3) makes the two first iteration of L_ext separately. That´s allow the first iteration L_2Elem to be executed with II=1 and N/2 times, and the second iteration L_4Elem with II=2, but N/4 times. The rest of the algorithm is similar to Merge_v2.

Algorithm 8. Merge Sort. Optimized V3 void merge_sort(v_type A[N]){ //type declaration… L_2Elem: for(i=0; i < N;i+=2) { V0 = A[i]; V1 = A[i+1]; if (V0 > V1) { B[i]= V1; B[i+1] = V0; } else{ B[i]= V0; B[i+1] = V1;}; } L_4Elem: for (i=0; i < N; i+=4) { V0 = B[i]; V1 = B[i+1]; V2 = B[i+2]; V3 = B[i+3]; // detect the correct order // and save. For example // A[i]= V0; A[i+1]= V1; // A[i+2]= V2; A[i+3]= V3; } L_ext: for (w=4; w < N; w = 2*w){ L_int: for (i = 0; i < N; i++){ if (i_mod_2w++ == 0) { i0 = i; iLeft= i; i1= i+w; iRight = i+w; iEnd =i+2*w; } V0 = A[i0]; V1 = A[i1]; if (i_mod_2w==2*w) i_mod_2w=0; if (i0 < iRight && (i1>=iEnd || V0<=V1)) { B[i] = V0; i0 = i0 + 1; } else { B[i] = V1; i1 = i1 + 1} /*swap array for next iteration*/ aux = A; A = B; B = aux; } }

3.5. Quick Sort

This algorithm makes a partition of an array, and the element, called a pivot is selected. All elements smaller than the pivot, are moved before it and all greater elements are moved after it. The lesser and greater sublists are then recursively sorted. In order to implement in HW a stack structure should be created to emulate the recursion. A simple but optimized implementation is depicted in Algorithm 9

Algorithm 9. Simple Quick sort void quick_sort (v_type A[N]){ int i, j, p, R = 0; L = N-1; int stack[N]; //auxiliary stack int top = 0; // top of stack //initial values to stack stack[++top]= R; stack[++top]= L; //Popping from stack while (!end) ext_loop: while ( top >= 0 ) { // Pop L and R L=stack[top]; R=stack[top-1]; top = top - 2; // Set pivot element piv = arr[L]; i = (R - 1); in_L: for (j = R; j<= L-1;j++){ A_j = A[j]; if (arr_j <= x) { //swap i++; A[j]=A[i]; A[i]=A_j; } } A[L]= A[i+1]; A[i+1]= x; //swap p = i+1; //If there are elements on left //of pivot, then push left side if (p-1 > R) {stack[++top] = R; stack[++top]=p-1;} // Same for right side of pivot if (p+1 < L) {stack[++top]=p+1; stack[++top] = L;} } } A first optimized code (Quick_V1) separate the stack in two (stack_beg and stack_end) additionally inner loop (in_L) is further optimized. The second optimization additional modify the inner loop to implement pipeline with II=2. The PIPELINE and DEPENDENCE false restriction are used. Algorithm 10 depicts the optimized version 2. (Quick_V2)


34

Algorithm 10. Quick Sort. Optimized V2. void quick_sort (v_type A[N]){ int stack_beg[M], stack_end[M]; stack_beg[0]=0; stack_end[0]=N; out_loop: while (top>=0) { L = stack_beg[top]; R = stack_end[top]-1; int pos_piv = L; if (L<R) { piv = Arr[L]; in_L: while (L<R) { A_R = A[R]; A_L = A[L]; if ((A_R<piv)&&(A_L>piv)) { A[L++] = A_R; A[R--] = A_L; }else{ if (A_R >= piv) R--; if (A_L <= piv) L++; } } if (A[L] > piv) L--; A[pos_piv] = Arr[L]; A[L]=piv; stack_beg[top+1]=L+1; stack_end[top+1] = stack_end[top]; stack_end[top++]=L; //Optionally change the top elements in stack in order to reduce the depth in execution. } else { top--; } } }

3.6. Heap Sort

It uses a data structure called a heap (a special type of binary tree). Once the data has been made into a heap, the root node is guaranteed to be the largest element. Then it is removed and placed at the end of the list, the heap is rearranged in such a way the largest element remaining moves to the root. The iteration of this orders the array. The main advantage of this O(N.log N) algorithm is that not need extra memory.

Algorithm 11. Heap Sort. Naïve version void heap_sort (v_type A[N]){ int st, end; /* heapify */ for (st=(N-2)/2; st>=0; st--) { siftDown( A, st, N);}

for (end=N-1; end > 0; end--) { SWAP(A[end],A[0]); siftDown(A, 0, end); } } void siftDown(v_type A[N], int st, int end){ int root = st; //st = start while ( root*2+1 < end ) { int ch = 2*root + 1; if((ch+1<end)&&(A[ch]<A[ch+1])) ch += 1; if (A[root] < A[ch]) { SWAP( A[child], A[root] ); root = child;} else return; } } The first optimization comes from embed the siftdown function into the main function (used two times) and avoid some reads in the swapping procedure. The second optimizations modify the inner loop of siftdown in order to obtain an II of 2. Algorithm 12 shows this second optimization. The loops L_hfy_sd and loop_order_sd uses PIPELINE directive.

Algorithm 12. Heap Sort. Optimized Version 2 void heap_sort (v_type A[N]){ int start, end; v_type V0, V1, Ch0, Ch1; int root, ch, ch_wr, ch_wr_pr; /* heapify */ L_hfy_out: for (start = (N-2)/2; start >=0; start--) { root = start; V0 = A[root]; child_wr_pr = root; child = root*2+1; L_hfy_sd: while (child < N) { Ch0 = A[child]; Ch1 = A[child+1]; if ((ch+1 < N)&&(Ch0 < Ch1)){ ch_wr = ch+1; V1 = Ch1; } else {ch_wr=ch; V1=Ch0; }; if (V0 < V1) { A[root]=V1; ch_wr_pr=ch_wr; root = ch_wr; ch=2*root+1; } else {child = N;}; //break; } A[ch_wr_pr] = V0;


35

https://en.wikipedia.org/wiki/Heap_(data_structure)

https://en.wikipedia.org/wiki/Binary_tree

} L_order_o:for(end=N-1; end>0; end--) { V0=A[end]; V1=A[root]; root=0; A[end] = V1; A[root] = V0; ch_wr_pr = root; ch = root*2+1; loop_order_sd: while (ch<end) { Ch0=A[child];Ch1=A[child+1]; if ((ch+1<end)&&(Ch0<Ch1)) { ch_wr = ch+ 1; V1=Ch1;} else{ch_wr = ch; V1 = Ch0;}; if (V0 < V1) { //Swap A[root]=V1; ch_wr_pr=ch_wr; root=ch_wr; ch=2*root + 1; } else {child = N;};// break } A[ch_wr_pr] = V0; } }

3.7. Radix Sort

The Radix Sort is non-comparative integer sorting algorithm that sorts data with integer keys by grouping keys by the individual digits which share the same significant position and value. For sorting in HW, the amount of buckets used (RADIX) should be power of 2.

This algorithm cannot be used easy and efficient with Floating Points numbers. For integers (signed numbers) some modifications should be also introduced. This algorithm uses also additional storage (B and buckets).

Algorithm 13. Radix Sort. Naïve version void Radix_sort (v_type A[N]){ int i, m = A[0], exp = 1; v_type B[N]; int bucket[RADIX]; for (i = 0; i < N; i++) if (A[i] > m) m = a[i]; // m <= max element of array m_L: while (m / exp > 0) { inic: for (i=0; i < RADIX; i++) bucket[i] = 0; L_size: for (i = 0; i < N; i++) bucket[A[i]/exp % RADIX]++; L_bucket:for (i=1;i<RADIX; i++) bucket[i] += bucket[i-1]; L_save: for (i=N-1; i>= 0; i--) B[--bucket[A[i]/exp % RADIX]] = A[i]; L_copy: for (i = 0; i < N; i++)

A[i] = B[i]; //Copy B to A exp *= RADIX; } As previously mentioned, for a HW execution RADIX should be 2n in order to implement efficient modulus operation. A second modification consists in change the main loop (m_L) in order to execute a fixed time of cycles and simplify the exit condition of loop. To classify 32 bits integers useful RADIX values are 16, 64 and 256 (24, 26, 28). Algorithm 14 depicts a RADIX 16 using pipeline in loops L_size, L_bckt, L_save and L_copy. The buckets array is implemented using registers and the L_ini is fully unrolled.

Algorithm 14. Radix Sort. Optimized V1 void Radix_sort (A[N]){ v_type B[N];int bucket[RADIX]; //more variable declarations L_out: for(k=0; k<32/LOG_R; k++){ L_ini: for(i=0; i<RADIX; i++){ bucket[i] = 0; } L_size: for (i=0; i<N; i++){ index=(A[i]>>(4*k))&0x0F ; bucket[index]++; } L_bckt:for(i=1; i<RADIX; i++) bucket[i] += bucket[i - 1]; L_save:for(i=N-1; i>=0; i--){ index=(A[i]>>(4*k))&0x0F ; B[--bucket[index] = A[i]; } L_copy: for (i=0; i<N; i++) A[i] = B[i]; } } The second version uses two read and two writes in each loop, taking advantage of the dual port of BRAMs. The third optimization uses two reads in L_size and removes the L_copy using a swap between A and B. The results in terms of execution time of these approaches are almost identical.

Other version uses different radixes. The radix 64 and radix 256 uses BRAM to implement the “bucket” array because using register will use too many resources. Radix 256 gives superior results than 64. Version 4 is an optimized Radix 256 radix sort.


36

4. Implementation Results

The C code was synthetized using Vivado-HLS 2013.1 [Vivado] using a Xilinx Virtex 7xc7vx485tffg1761-2 device targeting a clock frequency of 200 MHz. The methodology to quantity the execution time measured in clock cycle is the following. When the amount of cycles can be inferred by Vivado-HLS tools, we use this value. When is not possible to obtain this value RTL cosimulation is used. For the non-constant time algorithm (the ones that depends on input value) 100 hundred cosimulation are executed and the average value is presented. The area information (FF, LUTs, BRAMs) and minimum period are the date reported by the synthesis tool. The area-period reports are

4.1. Results for O(N2) algorithm

Table 2 present the cycles necessary to sort N elements for N=32, 64, 1024 and 4096 respectively. Meanwhile table 3 shows the area (FF, LUTs and BRAMs) and minimum period in ns for N=1024. Table 2. Number of cycles to sort different array sizes using O(N2) (Bubble; Insert and Select Sort).

Algorithm N=32 N=64 N=1024 N=4096 Bubble_Naive 1316 5162 1313727 20985234 Bubble_V1 652 2332 528892 8407036 Insert_Naive 910 3262 796479 12628150 Insert_V1 679 2322 533373 8428322 Select_Naive 1086 4222 1050622 16785406 Select_V1 652 2332 528892 8407036 Select_V2 435 1387 268027 4217851 Select_V3 320 905 135926 2122730

Table 3. Area and min delay for the O(N2) algorithm using N=1024.

Algorithm FF LUTs BRAMs T (ns) Bubble_naive 137 157 0 3.80 Bubble_v1 133 310 0 3.80 Insert_Naive 152 220 0 3.72 Insert_V1 211 339 0 3.72 Select_Naive 146 168 0 3.80 Select_V1 229 336 0 3.72 Select_V2 406 625 0 4.25 Select_V3 426 1888 0 4.26

Notes 1: The O(N2) algorithm shows similar figures. Select Sort allows to two read and writes in parallel, then the cycles could be reduced to 1/4 but using more area.

4.2. Results for O(N. Log N) algorithm

For N > 32 the O(N.Log N) needs less time to sort the arrays. Table 4 present the cycles necessary to sort N elements. Table 3 shows the area and minimum period in ns for N=1024.

Table 4. Number of cycles to sort different array sizes using the O(N.Log N) algorithms.

Algorithm N=32 N=64 N=1024 N=4096 Quick_Naïve 661 1669 46274 225014 Quick_V1 579 1450 40039 194180 Quick_V2 619 1397 32110 143404 Merge_Naive 1136 2707 71711 344101 Merge_V1 511 1189 30781 147529 Merge_V2 299 772 20484 98308 Merge_V3 295 585 17417 86025 Heap_Naive 823 1955 51437 246781 Heap_V1 646 1539 40725 195748 Heap_V2 498 1119 26030 120499

Table 5. Area and min delay for the O(N. Log N) algorithm using N=1024.

Algorithm FF LUTs BRAMs T(ns) Quick_Naïve 472 601 2 4.02 Quick_V1 441 555 2 3.93 Quick_V2 414 502 2 3.91 Merge_Naive 726 1013 2 4.11 Merge_V1 464 697 2 4.51 Merge_V2 619 1280 2 5.41 Merge_V3 899 1690 2 5.41 Heap_Naive 288 374 0 3.81 Heap_V1 358 493 0 3.81 Heap_V2 410 814 0 7.61

Notes 2: All the O(N.Log N) algorithm clearly outperform the previous O(N2) algorithm. The transformation of recursive algorithm in iterative ones for HW implementation gives outstanding results in terms of execution time.

Regarding the implemented circuits, the literature highlights the good results of Quick Sort, nevertheless due to the interdependences between loops and the stack overhead gives the worst result of the three evaluated algorithm. The


37

best results were obtained using the Merge Sort, but uses additional storage (BRAMs). The Heap Sort is a good option when no additional want to be used.

4.3. Results for Radix Sort algorithm

The final algorithm studied, the non-comparison sorting algorithm, Radix Sort gave the fastest results to classify natural numbers. Table 6 and table 7 gives the cycles to sort and area-delay respectively. Table 6. Number of cycles to sort different array sizes using the Radix-Sort algorithms.

Algorithm N=32 N=64 N=1024 N=4096 Radix_Naive 11422 22398 351678 1405374 Radix_V1 993 1761 24801 98530 Radix_V2 617 1001 12521 49385 Radix_V3 601 993 12513 49377 Radix_V4 2033 2486 15925 58933

Table 7. Area and min delay for Radix-Sort algorithm using N=1024.

Algorithm FF LUTs BRAMs T(ns) Radix_Naive 3848 4122 3 4.02 Radix_V1 2210 4424 2 3.98 Radix_V2 2990 9136 2 6.81 Radix_V3 2907 6684 2 6.81 Radix_V4 501 1583 3 6.17

Notes 3: Radix-Sort needs lees cycles than O(N.Log N) algorithms. As Merge Sort and Quick Sort needs additional store (another Array). The Radix 16 (Radix_V2, Radix_V3) do not use and additional BRAM because implements in slice FF the “bucket” arrays. In the other hand Radix 256 (Radix_V3) save slice FF but used an additional BRAM.

4.4. Comparing the circuits

Table 8 shows some selected implementations and results for sorting N=1024 elements. In it, the average cycles needed, the amount of LookUp Tables (LUTs) and number of BRAMs (BR) are shown. T expresses the minimum delay in ns and AxD is the area by delay (LUTs * cycles * T) expressed in LUTs x miliseconds (less is better), but not taking into account the used BRAMS.

Table 8. Main parameters for selected circuits sorting N=1024 elements. Algorithm #Cycl LUTs BR T AxD

Bubble_v1 528892 310 0 3.80 623.0 Insert_V1 533373 339 0 3.72 672.6 Select_V3 135926 1888 0 4.26 1093.2 Quick_V2 32110 502 2 3.91 63.0 Merge_V3 17417 1690 2 5.41 159.2 Heap_V2 26030 814 0 7.61 161.2 Radix_V3 12513 6684 2 6.81 569.6 Radix_V4 15925 1583 3 6.17 155.5 Comparing the best implementations of the different algorithm, all circuits use less than 1% of modern Virtex 7 devices. Nevertheless the three O(N.Log N) algorithm (Quick Sort, Merge Sort and Heap Sort) and Radix Sort clearly are better. If the objective is to reduce BlockRam usage the best choice is Merge Sort, if the only parameter is minimum latency Radix Sort is the best option. For a good compromise area-delay Merge Sort and Quick Sort are the selection.

5. Conclusion and Future Work

This works has compared seven sorting algorithm implemented in FPGA to sort natural number for sets between 32 and 4096 elements. A carefully putting into practice of O(N.Log N) algorithm give good results. The Radix-Sort algorithm, a non-comparative integer sorting algorithm, gave the minimum cycles necessary to sort more than 128 elements. Merge Sort has good results without the need of additional storage (BRAMs), meanwhile Merge Sort and Quick sort offer a good compromise between area and delay.

Regarding the methodology used, High Level Synthesis (HLS) allows a very quick design space exploration. This work reusing well known C code for data sorting and HLS tools achieve a complete analysis in weeks of work. The same work starting from HDL will needs month of coding and testing effort. Future works includes, (i) analyze how to improve the parallelism reading more than one memory per clock cycle when the array to be sorted occupies more than one. (ii) Study the problem for small numbers to be sorted (N < 32) looking for very low latency. (iii) Consider the problem for big array stored in external memory.


38

References

[1] Donald Knuth. The Art of Computer Programming, Volume 3: Sorting and Searching, 3rd Ed. Addison-Wesley, 1997. ISBN 0-201-89685-0.

[2] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. Introduction to Algorithms, 2nd Ed. MIT Press and McGraw-Hill, 2001. ISBN 0-262-03293-7.

[3] Sorting algorithm, online: https:// en.wikipedia.org/ wiki/ Sorting_algorithm

[4] Rene Mueller, Jens Teubner, and Gustavo Alonso, Sorting networks on FPGAs, The VLDB Journal, Springer-Verlag. pp 1-23, February 2012.

[6] Devi Prasad, Mohamad Yusof, Mohamad Yusri, Smruti Santosh Palai, and Ahmad Hafez Nawi, Sorting networks on FPGA, Proc. 10th WSEAS Int Conf. on Telecomm. and informatics and microelectronics, nanoelectronics, optoelectronics, pp 29-31, Canary Islands, Spain, 2011.

[5] Rene Mueller, Jens Teubner, and Gustavo Alonso, Data processing on FPGAs, Proc. VLDB Endow. Pp 910-921, August 2009.

[7] John Harkins, Tarek El-Ghazawi, Esam El-

Araby, and Miaoqing Huang, "Performance of sorting algorithms on the SRC 6 reconfigurable computer," in Proc. of IEEE

2005 Intern. Conf. on Field-Programmable Technology (ICFPT'05), pp. 295-296, December 11-14, 2005.

[8] Dirk Koch and Jim Torresen, FPGASort: a high performance sorting architecture exploiting run-time reconfiguration on fpgas for large problem sorting. Proc. of the 19th ACM/SIGDA international symposium on Field programmable gate arrays (FPGA '11)

[9] Stephen Bique, Wendell Anderson, Marco Lanzagorta, and Robert Rosenberg, Sorting Using the Xilinx Virtex-4 Field Programmable Gate Arrays on the Cray XD1, In CRAY user group Conference Proceeding, Helsinky, 2008.

[10] Rui Marcelino, Horácio C. Neto, João M. P. Cardoso,Sorting Units for FPGA-Based Embedded Systems, DIPES. Pp.11-22, 2008.

[11] Dmitri Mihhailov, Valery Sklyarov, Iouliia Skliarova, Alexander Sudnitson: Parallel FPGA-Based Implementation of Recursive Sorting Algorithms. ReConFig 2010, pp 121-126, 2010

[12] Xilinx Inc. Vivado Design Suite User Guide. High-Level Synthesis (Vivado-HLS) UG902 (v2013.1) March 20, 2013.

[13] Xilinx Inc. 7 Series FPGAs Overview DS180 (v1.13) Nov, 2012 Available at: http:// www.xilinx.com/support/

[14] Sorting Algorithm Animations. Online: http:// www.sorting- algorithms.com/


39

https://en.wikipedia.org/wiki/Donald_Knuth

https://en.wikipedia.org/wiki/Special:BookSources/0201896850

https://en.wikipedia.org/wiki/Thomas_H._Cormen

https://en.wikipedia.org/wiki/Charles_E._Leiserson

https://en.wikipedia.org/wiki/Ronald_L._Rivest

https://en.wikipedia.org/wiki/Clifford_Stein

https://en.wikipedia.org/wiki/Introduction_to_Algorithms



http://www.csce.uark.edu/~mqhuang/papers/2005_Sorting_FPT.pdf




40

Clasificación de paquetes IP a 10 Gbps descripto desde lenguajes

de alto nivel

Marco Forconesi, Gustavo Sutter, Sergio Lopez-Buedo, Francisco Gomez-Arribas {marco.forconesi, gustavo.sutter, sergio.lopez-buedo, francisco.gomez}@uam.es

Escuela Politécnica Superior, Universidad Autónoma de Madrid.

Resumen

En este artículo se presenta un prototipo Hardware que clasifica paquetes IP sobre Ethernet para redes de 10 Gbps implementado en FPGA. Tanto el diseño como la validación del mismo han sido realizados con lenguajes C y C++.

La ventaja principal que se destaca con este enfoque frente a descripciones HDL son: (i) el rápido prototipado y descripción del dispositivo

Hardware; (ii) la depuración de errores semánticos en una etapa muy temprana de diseño con el uso de testbench descritos en leguaje C/C++; (iii) la posibilidad de rediseñar el Hardware de una forma rápida y eficaz, con pocos cambios en líneas de código.

1. Motivación

Las implementaciones Hardware de dispositivos para redes de alta velocidad han sido elementos de vanguardia en lo que respecta el

funcionamiento, gestión y monitorización de las mismas. Con la necesidad de analizar el tráfico de paquetes de datos a fin de: encaminar dichos paquetes, clasificar/cuantificar las comunicaciones concurrentes y detectar ataques de seguridad, frente a las limitaciones de velocidad de sistemas Software, la industria se ha decantado por alternativas Hardware para cubrir los

requerimientos para redes actuales y futuras (10, 40 y 100 Gbps). El alto desempeño y bajo consumo de estos dispositivos Hardware se ha visto ofuscado y su utilización desestimada por el alto tiempo de desarrollo e inflexibilidad en el diseño RTL.

Para mitigar las barreras que ralentizan y osifican los diseños Hardware con leguajes de

descripción HDL, se ha producido un intensivo trabajo de investigación en la inserción de lenguajes de alto nivel (C, C++ y SystemC) en el

flujo de diseño y validación frente a los tradicionales lenguajes HDLs (VHDL, Verilog y SystemVerilog). Como resultado de este esfuerzo se disponen actualmente de herramientas que generan y validan Hardware a partir de descripciones de alto nivel, abstrayendo al diseñador, del Hardware que subyace en una cuantía muy superior a la provista por los

lenguajes HDL. En este trabajo se hace uso de la herramienta de Xilinx® Vivado HLS [1].

2. Técnicas de clasificación e inspección

de paquetes IP

En la industria de las redes de comunicaciones a gran escala, lo que se conoce como enlaces troncales de red, existe un especial interés en conocer más acerca del tráfico que atraviesa los distintos nodos a fin de:

Controlar y encaminar de forma óptima los

paquetes que constituyen dicho tráfico. Los dispositivos tales como routers y switches analizan los primeros bytes recibidos de cada

paquete a fin de determinar hacia dónde debe conducir dicho paquete, de acuerdo a unas tablas de ruta.

Detectar disfuncionalidades, ataques de

seguridad y sobrecarga de enlaces. Existe una línea de investigación encargada del desarrollo de instrumentos de medición que analizan y clasifican los paquetes IP, agrupándolos conceptualmente en elementos que tienen un significado más adecuado para un analista de red.

Implementar técnicas avanzadas de control para mitigar los problemas de calidad de

servicio (QoS) encontrados en redes tradicionales best-effort. Las redes convencionales funcionan en base a tratar todo


41

el tráfico de la misma manera bajo el paradigma: primero en llegar, primero en ser atendido. Con el advenimiento de servicios sensibles al ancho de banda y variaciones del retardo entre paquetes, tales como video y voz sobre IP, las compañías proveedoras de

servicios de internet (ISP) han encontrado ineludible la necesidad de discriminar el tráfico en pos de garantizar un tratamiento especial para cada tipo. Dado los tres escenarios anteriormente

citados, es inapelable la necesidad de realizar procesamiento de paquetes a tasa de línea con el

afán de dotar a las redes de los mecanismos necesarios para alcanzar las características planteadas. La utilización de sistemas Hardware en lugar de soluciones Software se justifica, en el caso de redes de alta velocidad, por la imposibilidad de este último en alcanzar las velocidades requeridas.

3. Arquitectura del diseño propuesto

Con el fin sentar las bases de la infraestructura de desarrollo para la generación de aplicaciones de

filtrado específicas, se generó un prototipo que discrimina los paquetes IP de acuerdo al protocolo de la capa de transporte (por ejemplo: TCP o UDP) que se reciben por una interfaz Ethernet de 10 Gbps. Una vez que se dispone de la información necesaria para clasificar un paquete, este es enviado, con latencia mínima, a una de dos interfaces Ethernet de salida.

La Figura 1 muestra un diagrama de interconexión de los cores desarrollados (10 Gbps Filter; Communication to Processor) integrados en el sistema microprocesador. El primer core realiza el proceso de filtrado. Este se interconecta a las interfaces Ethernet de entrada y salida mediante los cores de acceso al medio (10GMAC) utilizando el protocolo AXI4-Stream del estándar

AMBA®-AXI4 [2]. La selección del protocolo de la capa de transporte de interés, se lleva a cabo en tiempo de ejecución mediante el microprocesador empotrado MicroBlaze® [3].

El usuario interactúa con el microprocesador y este a su vez escribe un registro de configuración en el core de filtrado a fin de seleccionar el protocolo de la capa de transporte de interés. De forma similar, la lectura de un registro informa al

usuario la cuantía de los paquetes totales que han

sido procesados y filtrados en el momento que

este solicite dicha información. La directiva de filtrado por la cual se rige el

core 10 Gbps Filter consiste en: todos los paquetes recibidos cuyo protocolo de la capa de transporte coincida con el protocolo de interés seleccionado por el usuario, son enviados a la interfaz cero, mientras que el resto de los paquetes son enviados a la interfaz uno.

La interfaz entre el MicroBlaze® y el core 10 Gbps Filter está implementado mediante un segundo core: Communication to Processor. Este posee: (i) una interfaz AXI4-Lite a través de la cual el microprocesador realiza las operaciones de lectura y escrituras a registros por petición del usuario y (ii) un conjunto de interfaces de registros sin protocolo con el core de filtrado a fin de modificar la funcionalidad y recolectar

información del mismo. El motivo de la separación conceptual del

diseño en los dos cores descritos es debido a que las interfaces a los módulos 10GMAC pertenecen a un domino de reloj distinto al del MicroBlaze®. La herramienta de diseño Vivado HLS no posee la capacidad de generar Hardware para más de un dominio de reloj en un mismo core con diseños

C/C++. Por lo tanto la solución a dicha limitación es la generación de dos cores independientes y su posterior interconexión a nivel sistema. De esta manera se evita tener que manipular los ficheros HDL generados.

4. Implementación Hardware y

plataforma de desarrollo

Una vez descrita la funcionalidad de cada uno de los cores por separado desde la herramienta Vivado HLS, se procede a la integración de los mismos con el EDK [4] de Xilinx®.

Figura 1: Diagrama de bloques clasificador


42

La plataforma Hardware donde el prototipo

fue implementado es la NetFPGA-10G [5] la cual posee una FPGA Virtex®-5 TX240T [6]. El proyecto NetFPGA, iniciado por Xilinx® y la Universidad de Stanford, es un proyecto de código Software y Hardware abierto del cual participan

una comunidad de desarrolladores e investigadores. Los diseños de referencia pueden ser modificados para lograr la funcionalidad buscada de una forma rápida, construyendo sobre el trabajo de la comunidad.

A continuación se describirán las interfaces y el Hardware resultante tanto del core que realiza el filtrado como también del core utilizado para

realizar la interfaz de comunicación al MicroBlaze®. Todo el proyecto se encuentra públicamente disponible para su implementación y modificación [7].

4.1. Descripción de las interfaces

En el flujo de diseño C/C++ de Vivado HLS el core que se está describiendo es una función y las interfaces del core son argumentos de dicha

función. El tipo de protocolo que cada interfaz posee a nivel Hardware es indicado al sintetizador mediante directivas pragma.

Las interfaces AXI4-Stream que conectan el core que filtra con los 10GMAC, son tratadas como arreglos. Lecturas secuenciales sobre el arreglo asociado a la interfaz de entrada son interpretadas por el sintetizador como accesos a

una FIFO. Las señales de comunicación a dicha FIFO son transparentes al programador. De forma análoga, escrituras secuenciales a los arreglos de salida son generadas como escrituras a una FIFO de salida.

Los argumentos de la función a los cuales no se les especifica ningún protocolo de comunicación y que son únicamente leídos, son sintetizados como interfaces de entrada. En el core

que filtra, la selección del protocolo es un argumento de 32 bits de ancho que es solamente leído dentro de la función. Por el contrario, la cantidad de paquetes procesados es un argumento de 32 bits que se incrementa cada vez que la función se ejecuta. Esto último es sintetizado por Vivado HLS como una interfaz de salida del módulo Hardware.

El tercer tipo de interfaz es el AXI4-Lite, presente en el core de comunicación al

MicroBlaze®. En este caso, múltiples argumentos de la función son agrupados bajo el mismo recurso de comunicación de manera que el procesador es capaz de direccionar de forma aleatoria dichos elementos para su escritura/lectura. Adicionalmente a los archivos

HDL que describen el core, la síntesis de Vivado HLS genera los drivers para la comunicación al módulo desde el programa C que ejecuta el MicroBlaze® o el sistema operativo Linux si existiera en el diseño.

Haciendo uso de las funciones que el driver generado provee, es posible acceder a los registros de configuración y estadística del core de filtrado

desde el procesador.

4.2. Arquitectura interna del core de filtrado

La Figura 2 muestra el Hardware resultante de la codificación realizada desde C/C++. Un buffer interno almacena el contenido del paquete bajo proceso mientras una decisión es tomada sobre dónde se va a destinar su retransmisión. La lógica de filtrado compara el campo de protocolo

extraído del paquete con el código de interés configurado desde el MicroBlaze®. Si ha ocurrido una correspondencia entre el protocolo de la capa de transporte buscado y el perteneciente al paquete, este es enviado a la interfaz cero. Si por el contrario estos códigos no han coincidido, el paquete se envía a la interfaz uno.

Figura 2: Arquitectura interna core de filtrado

La función que sintetiza el Hardware del módulo que filtra, comienza con una lectura de los primeros cinco elementos del arreglo que representa la interfaz de entrada. En este conjunto de bytes se encuentra el byte que indica el

protocolo de la capa de transporte. Los datos leídos de la FIFO de entrada son almacenados secuencialmente en un arreglo interno de la


43

función. Desde el punto de vista del programa C/C++, si no se hubiese recibido un paquete, la función se estancaría en este punto de ejecución a la espera de datos en el arreglo de entrada. Con esta premisa, las líneas de código posteriores a estas lecturas, serán ejecutadas en Hardware

cuando un paquete se esté recibiendo. La selección de la interfaz de salida donde se

destinará la retransmisión del paquete es realizada por una comparación del tipo if-else entre el protocolo de la capa de transporte recibido y el establecido por el usuario. El contenido del arreglo interno es leído secuencialmente hasta el fin de paquete y asignado al arreglo de salida que

corresponde, dependiendo de la interfaz que fue seleccionada previamente.

4.3. Generación de Pcore de EDK

Para cada core descrito en C/C++ con Vivado HLS se genera además de la descripción HDL, los archivos necesarios para constituir un Pcore de EDK. Para el core de comunicación al MicroBlaze®, Vivado HLS genera además el

driver a ser utilizado para el acceso a los registros. Ambos Pcores son instanciados desde el

proyecto de referencia de NetFPGA-10G y la consiguiente interconexión de los mismos como muestra la Figura 1. Nótese que no existe una interacción directa del programador con los archivos HDL en ningún punto del flujo de diseño.

5. Resultados de implementación

Ambos cores fueron codificados en lenguaje

C/C++ y sintetizados con la herramienta Vivado HLS v2013.1. La integración con el proyecto NetFPGA-10G fue realizada con el EDK v13.4.

El análisis de los resultados de implementación de este trabajo se presentan desde una perspectiva comparativa de los flujos de diseño C/C++ y RTL. Esta sección también presenta los resultados cuantitativos de la

implementación en términos de recursos insumidos de la FPGA.

5.1. Esfuerzo y eficiencia en el diseño

En comparación con el flujo RTL clásico, estas nuevas herramientas de diseño con lenguajes de

alto nivel, dan la posibilidad de generar proyectos nuevos con tiempos de desarrollo y validación mucho menores. La Tabla 1 muestra la cantidad de líneas de código fuente (C/C++) asociado a cada módulo y la cantidad de líneas Verilog que el sintetizador

Vivado HLS genera. Solo se cuentan las líneas de código validas, sin comentarios ni líneas en blanco.

Tabla 1: Líneas de código fuente y generado

Líneas C/C++

Líneas Verilog (1)

Líneas Verilog (2)

filter core 78 551 1522

test_filter 79 x x

c2ub 11 123 420

test_c2ub 14 x x

(1) Líneas de código con la funcionalidad descrita.

(2) Líneas de código total incluyendo interfaces

(AXI4-Stream, AXI4-Lite, etc.).

5.2. Recursos utilizados de la FPGA

La Tabla 2 muestra la cantidad de recursos Hardware de la FPGA que el diseño consume así como también el sistema total incluido el MicroBlaze®.

Tabla 2: Resultados de implementación

#Luts #Flip Flops #BRAMs

Filter core 867 741 2

Comm. core 76 106 0

Total system 20304 22980 38

La implementación final cumple con todas las

restricciones temporales para los dominios de reloj de 200 MHz de la interfaces a los 10GMAC y de 50 MHz para las interfaces al MicroBlaze®.

6. Flujo de validación del diseño

A fin de verificar el correcto funcionamiento del prototipo propuesto, varias instancias de verificación de la funcionalidad son llevadas a cabo en el flujo de diseño.

C/C++ Simulation: un programa de testbench escrito en C/C++ invoca a la función que

finalmente será sintetizada proveyéndola de las entradas adecuadas, recolectando y mostrando por pantalla los resultados generados. Este programa es compilado junto con la función sintetizable con


44

los compiladores convencionales gcc/g++. Gran parte de los errores semánticos son detectados en esta fase en donde no ha intervenido ningún elemento de generación de Hardware. En este trabajo, el programa de testbench consiste en un lazo de N iteraciones que escribe un arreglo con el

contenido de un paquete, llama a la función sintetizable y luego lee de los dos arreglos de salida de la función. La función sintetizable escribe en el arreglo de salida que corresponde, según sea el protocolo del paquete y el protocolo de interés seleccionado. Cada una de las N iteraciones repite el proceso con un nuevo paquete que se presenta al Hardware.

Co-Simulation: una vez generado los ficheros HDL que describen el diseño inferido, es posible simular el mismo con un testbench convencional HDL que provee estímulos al Hardware sintetizado y recoge las salidas del mismo. Este fichero es generado por la herramienta de diseño Vivado HLS de forma automática y sin intervención alguna del programador a partir del

fichero testbench codificado en lenguaje C, C++ o SystemC utilizado en la etapa anterior. La herramienta de diseño compara las salidas obtenidas con ambas simulaciones en un proceso que se denomina co-simulación.

Verificación en arreglo experimental: la fase final en donde se prueba empíricamente el diseño generado es con la FPGA configurada y las

interfaces conectadas a tarjetas de red externas. El banco de pruebas consiste en: (i) un generador de tráfico de 10 Gbps que inyecta paquetes a la interfaz de entrada del diseño y (ii) dos tarjetas de red conectadas a las interfaces de salida. Mediante la captura de tráfico en estas dos tarjetas, se verifica el filtrado realizado sobre el tráfico de entrada por el diseño bajo prueba.

7. Conclusión

Se ha desarrollado un prototipo Hardware

funcional para el análisis y clasificación de paquetes de redes IP de alta velocidad implementado en FPGA y codificado en lenguaje

de alto nivel C/C++. La principal contribución de este trabajo es la puesta en funcionamiento de la infraestructura necesaria para aprovechar las ventajas de desempeño de implementaciones Hardware a la vez que se obtiene el beneficio del desarrollo Software con un reducido tiempo de

prototipado y depuración. Como ventaja adicional a describir Hardware desde lenguajes de alto nivel, se obtienen diseños: (i) más mantenibles, por poseer menor cantidad de líneas de código; (ii) más versátiles y menos propenso a errores a la hora de realizar modificaciones y (iii) más accesibles, ya que se aproxima más al mundo de programadores Software que a la comunidad más

reducida de diseñadores RTL. Dado que todo el trabajo se encuentra

públicamente disponible para ser modificado, se espera que este sirva como base a futuros desarrollos de análisis de tráfico de red.

Referencias

[1] Xilinx Inc., Vivado Design Suite User Guide, High-Level Synthesis v2013.1 UG902, March 2013. [Online]. Available: http://www.xilinx. com/support/

[2] ARM Inc., Amba axi protocol v2.0. 2010. [Online]. Available: http://www.arm.com/

[3] Xilinx Inc., MicroBlaze Processor Reference Guide v11.2. UG081, Sep. 2010. [Online]. Available:http://www.xilinx.com/support/

[4] Xilinx Inc., Embedded System Tools Reference Manual, EDK v13.2. UG111, July. 2011. Available: http://www.xilinx.com/support/

[5] “NetFPGA-10G board description,” 2012. [Online]. Available: http://netfpga.org/10G_ specs.html

[6] Xilinx Inc., Virtex-5 FPGA Data Sheets, March 2010. [Online]. Available: http://www.xilinx.com/support/

[7] M. Forconesi, G. Sutter, S. Lopez-Buedo and F. Gomez-Arribas, “Open Source Code of

HLS Packet Classificator,” 2013. [Online]. Available: https://github.com/hpcn-uam/Viv

ado-HLS-Pkt-Classif


45


46

Mapeo automatico de sistemas basados en OpenCV enlos nuevos SoCs heterogeneos

Francisco Jose Sanchis-Cases(1), Antonio Martınez-Alvarez(1),Sergio Cuenca-Asensi(1)


(1)Departamento de Tecnologıa Informatica y Computacion, Universidad de Alicante

Resumen

Los requisitos actuales de procesamiento devıdeo o imagen definen una tarea complejaligada a una alta carga computacional. Esteprocesamiento, que tiene cada vez mas apli-cabilidad, ubicuidad e interes, destaca porllevarse a cabo en arquitecturas muy het-erogeneas. De este modo, y dependiendo delos requisitos del sistema (velocidad de calculo,potencia de consumo o precision) se encuentrauna amplia horquilla de implementaciones deun cierto modelo de procesamiento. Por otrolado, la aparicion de nuevas FPGA que com-binan nucleos fısicos de CPU (hard-core) conuna gran cantidad de espacio de logica recon-figurable, ofrece una gran ventaja al disenadorpara escoger entre diferentes particiones delsistema y diferentes niveles de paralelismo.

A parte de esto, OpenCV es una bibliote-ca bien conocida de procesamiento de visionque esta cobrando cada vez mas importan-cia en el diseno de sistemas empotrados. Eneste contexto, la aportacion principal de estetrabajo es la presentacion de un entorno dediseno para los nuevos SoCs, como la platafor-ma Zynq de Xilinx, que combinan FPGAs ynucleos ARM con comunicacion AXI4. Esteentorno esta basado en un compilador (Clang)para la aceleracion automatica de un modelode procesamiento de vision descrito en C++y OpenCV. De esta forma, el modelo softwarese transporta a uno equivalente en hardwarereconfigurable que usa las mismas primitivasde OpenCV y puede ser sintetizado e imple-mentado por las herramientas de Xilinx.

1. Introduccion

Los ultimos anos han contemplado muchasinnovaciones tecnologicas y estructurales enlos sistemas reconfigurables que han permitidodisenar nuevas FPGAs cada vez mas potentesy heterogeneas. Tal es el caso de la familiaZynq de Xilinx [1], con una gran capacidadde logica reconfigurable y, al mismo tiempo,con algunos nucleos CPU (ARM) incorpora-dos de forma fısica (hard-cores). En contra-posicion a estos avances tecnologicos, cuantomayor es la complejidad del sistema, mayor esla dificultad de aplicar un flujo de diseno y deintegrar la parte logica (generalmente un sis-tema de procesamiento de tipo flujo de datos)con la CPU incorporada (que generalmente seencarga de procesos de control). Esto impideal disenador plantear un sistema de una for-ma sencilla, agil y rapida. No en vano, cadavez toma mas importancia la tarea de par-alelizar correctamente una aplicacion y ade-cuar el procesamiento a los distintos gradosde granularidad de paralelismo subyacentes auna FPGA moderna.

Tradicionalmente en el diseno de sistemasreconfigurables se han empleado lenguajes dedescripcion de hardware tales como VHDL oVerilog [2, 3]. Estos lenguajes definen una de-scripcion del sistema de muy bajo nivel, loque hace bastante tedioso y laborioso disenarsistemas complejos. A causa de esto y cen-trandonos en la aplicacion de procesamientode vıdeo e imagen, el disenador percibe una di-ficultad anadida al disenar sistemas de visiona ese nivel de abstraccion [4, 5].


47

Motivados por la necesidad de ofrecer unasolucion a la complejidad de disenar sistemasde procesamiento de vision en arquitecturasheterogeneas, y al mismo tiempo reducir eltiempo en el diseno, este trabajo plantea unaestrategia para la generacion, sıntesis e imple-mentacion automatica [6, 7, 8] de dichos sis-temas. Proponemos la especificacion del mod-elo en un codigo software sencillo a alto nivelHLS (High Level Synthesis) [9, 10, 11], com-probable y de caracterısticas conocidas (usan-do bibliotecas verificadas de procesamiento devıdeo e imagen).

Este planteamiento otorga al programadoruna sencillez en la definicion y comprobacioninicial del modelo, y la ventaja adicionalde poder transportar automaticamente dichomodelo a las nuevas SoCs heterogeneas.

Para definir el modelo de vision, se ha op-tado por la biblioteca OpenCV [12, 13]. Estabiblioteca, cada vez mas utilizada en ambitosacademicos e industriales, es multiplataforma,de codigo abierto, y de verdadera inspiracionubicua, al estar portada a microprocesadorestipo x86, x86-64, ARM (haciendo uso de surepertorio extendido de instrucciones SIMD)y recientemente CUDA [14, 15], entre otros.

En relacion al proposito que acomete estetrabajo, frente a la complejidad en el diseno desistemas de vision para las nuevas SoCs het-erogeneas, se presenta un entorno de disenofacil, claro y transparente para el disenador,otorgando a este una herramienta completadonde se realizan sıntesis, implementaciones ysimulaciones del diseno, posibilitando la vali-dacion experimental.

2. Entorno y Flujo de Diseno

Nuestro tragajo se ha centrado en el de-sarrollo de un entorno, que denominamosAMAZynq, que facilita el diseno de sistemasheterogeneos de vision. AMAZynq permite alusuario inexperto la facilidad de disenar y sin-tetizar sistemas hardware/software de visiony al usuario experto una reduccion consider-able en el tiempo de trabajo. Los resultadosespacio-temporales son similares o iguales alos obtenidos mediante el diseno clasico de sis-

temas digitales. Este entorno esta enfocado ala nuevas SoCs de Xilinx, la familia Zynq.

El flujo de diseno con AMAZynq puede versea grandes rasgos en la figura 1. La entrada deldiseno es un codigo OpenCV funcionalmentecorrecto y que ha sido previamente verificadoen algun tipo de plataforma compatible conarquitectura x86 (una estacion de trabajo tipoPC suele ser lo mas habitual). Sobre este codi-go, el usuario debe especificar explıcitamentecuales de las funciones OpenCV deben sermigradas al Hw. Este proceso se realiza inser-tando ciertas directivas de compilacion (p.ej:pragmas). Una vez tomadas las decisiones departicionado Hw/Sw, el compilador del en-torno AMAZynq genera automaticamente tan-to las infraestructuras Sw como la arquitec-tura Hw que posteriormente se implementaransobre los dispositivos Zynq. El resultado esun SoC funcionalmente equivalente al original,pero acelerado mediante un coprocesador Hwy soportado por un sistema operativo tipo Lin-ux.

AMAZynq tiene las siguientes dependenciassoftware con otras herramientas:

• Xilinx Vivado HLS 2013.1

• Xilinx EDK 14.5

El entorno de diseno esta dividido envarias bloques fundamentales (ver figura 1)que son independientes entre sı, pueden serdesarrolladas de forma paralela y admitenfuturas ampliaciones. Este planteamiento sedebe a la continua actualizacion de la bibliote-ca OpenCV con nuevos metodos que exigenadaptaciones periodicas. Como se puede ob-servar, el entorno de diseno se divide en:

La biblioteca Hw encargada de proporcionarlos disenos de cores Hw, los cuales estan basa-dos en la herramienta y bibliotecas del entornoXilinx Vivado HLS.

El Compilador AMAZynq tiene la funcionde procesar el codigo de entrada y obtener,dependiendo de las directivas y parametros decompilacion, el modelo equivalente Hw. Estebloque genera tres salidas, las cuales son:

• Proyecto Hw generado a partir de laBiblioteca HW. Este proyecto se sinteti-


48

Compilación Cruzada

EDK

Vivado HLSAMAZynq

Compilador AMAZynq

Proyecto HW

Proyecto Embebido Hardware (.mhs)

Proyecto SW

Código Fuente

Directivas

Implementación .bit / .bin

Biblioteca HW

Plantillas Arquitecturas

API LinuxAXI4 Drivers

Compilador ARM

.elf

Vivado HLS

Figura 1: Diagrama de bloques y flujo de diseno de AMAZynq.

zara posteriormente con la herramientaVivado HLS.

• Proyecto EDK (especificado mediante elfichero .mhs). Este fichero define la arqui-tectura hw de todo el sistema, incluyen-do el/los procesadores, buses, perifericos,controladores, etc. y la instancia de loscores de procesado de imagen. La imple-mentacion de este proyecto generara elarchivo de configuracion de la FPGA obitstream (fichero .bit).

• Proyecto Sw, donde se definen las in-fraestructuras que permiten el manejo detodo el sistema. Este Sw es ARM com-patible y esta preparado para ejecutarseen un sistema operativo Linux.

Las plantillas de referencia son los archivosque contienen los codigos y definiciones invari-antes que permiten al compilador construir elproyecto Sw.

Las Arquitecturas de referencia son las ar-quitecturas que se soportan en el entorno dediseno. El compilador utiliza estas arquitec-turas para generar el proyecto EDK.

La figura 1 tambien ilustra el flujo de disenocon AMAZynq. El resultado es la generacionde un SoC tipo Zynq funcionalmente equiva-lente al original, pero acelerado mediante uncoprocesador hw y soportado por un sistemaoperativo tipo Linux.

En los siguientes apartados se detallan lasfuncionalidades de cada herramienta del en-torno.

2.1. Biblioteca HW

El bloque con mas peso en el desarrollo quepermanece en continua ampliacion y actual-izacion es la biblioteca de filtros Hw. Estabiblioteca posee todas las definiciones de fil-tros, operadores, definiciones, etc. para la re-alizacion de sistemas de vision.

Uno de los aspectos principales con losque se lidio son los adaptadores de entraday salida, ya que en OpenCV las estructurasbasicas son IplImage y cvMat, y no son com-patibles con la sınstesis hardware. Al mismotiempo, hay que tener en cuenta que las en-tradas y salidas del filtro Hw son del tipo AxiStream, que invalida la posibilidad de tenercomo parametro de entrada-salida una estruc-


49

tura basica de OpenCV. Estos adaptadores sonusados tanto en la generacion del Core Hw co-mo en el programa Sw (programa ejecutableen el entorno Linux en ARM).

Otro aspecto que nos enfrentamos en lageneracion de los filtros fue el uso de C++templates, constantes, etc. de la bibliotecaOpenCV y, al mismo tiempo, el tipo de rep-resentacion de sus datos. Para Hw reconfig-urable la forma correcta (o mejor) de repre-sentacion y de procesado de datos es optar porel tipo entero, por contra, OpenCV admite in-finidad de tipos de representacion, con lo cual,debemos convertir la entrada de un tipo a otro(casting). En consecuencia, la mejor forma dedisenar es usando el tipo entero en Sw y Hw,dejando el casting a un uso aislado y siempreen el diseno Sw.

Una vez que tenemos los adaptadores y losconvertidores, se disenaron los filtros mante-niendo el orden de la jerarquıa de OpenCV,para ası poder estructurar los filtros mas com-plejos haciendo llamadas a esos metodos masbasicos.

Al principio se empezo a disenar desdecero con concordancia con la biblioteca Sw deOpenCV 1, en la actualidad se sigue esa mismalınea y, ademas se ha anadido una nueva que seapoya en las nuevas bibliotecas que aparecenen la version de Vivado HLS (2013.1).

2.2. Compilador para HLS

Para disenar la herramienta de alto nivel quetransporte definiciones software tipo Data-Flow de procesamiento de vision a su equiva-lente en Hw reconfigurable, se ha optado por lamodificacion de Clang, el conocido compiladorde C/C++ integrado en la infraestructura decompilacion LLVM. Esta modificacion, que lla-maremos Compilador AMAZynq extiende elfront-end de compilacion de C++ de Clangpara, dado un proyecto software que haga usode OpenCV :

• Reconocer filtros nativos OpenCV.

• Reconocer nuevos filtros definidos medi-ante la concatenacion de filtros OpenCV.

1Usando las biblioteca de Bit Accurate y Streamde Vivado como mas importantes.

• Recopilar informacion de alto nivel parala futura optimizacion de los filtros(linealidad, separabilidad, tipo y repre-sentacion de los datos, dimensiones de loskernels de convolucion,. . . ).

• Reconocer nuevos pragmas y directivas decompilacion para controlar el proceso desıntesis de alto nivel.

• Soportar el acceso a una base de datos ex-terna con informacion sobre la bibliotecapredefinida de filtros Hw.

• Generar el elenco de ficheros descrito enla seccion 2, que definen el proyecto departida usando una plataforma de Hw re-configurable (por el momento, Zynq).

La base de datos externa que se cita acometeun objetivo doble. Por un lado, en ella se listalos filtros OpenCV que son soportados por elcompilador, y se permite al usuario decidir deforma controlada como se realizara la trans-formacion a Hw reconfigurable. Por otro la-do, permite la extension del compilador connuevos filtros definidos por el usuario. Por tan-to, este archivo, define las reglas de transfor-macion software → hardware.

2.3. Plantillas de referencia

Al entorno de diseno se anaden unas plantil-las con parte de las estructuras basicas paralos disenos del sistema de vision debido a quealgunos aspectos siempre son iguales y no cam-bian aunque tengamos un filtro mas complejo.Las plantillas se distribuyen en dos tipos, lasdel diseno del core Hw y las del Sw.

Entre las estructuras constantes de los coresHw destacan tres partes de codigo:

• Las directivas o pragmas para las inter-faces de entrada y salida. Las interfacesson siempre del mismo tipo First In FirstOut (FIFO) debido a que las comunica-ciones por bus son del tipo AXI-Stream.Como se observa en las declaraciones, elbus posee cinco senales, una de datos ycuatro de control (ver figura 2).


50

#pragma HLS RESOURCE variable=inter_pix

core=AXI4Stream metadata="-bus_bundle

INPUT_STREAM"

#pragma HLS RESOURCE variable=inter_pix

core=AXIS port_map={{inter_pix_data_V TDATA}

{inter_pix_user_V TUSER}

{inter_pix_last_V TLAST}

{inter_pix_tdest_V TDEST}

{inter_pix_strb_V TSTRB}}

#pragma HLS INTERFACE ap_fifo port=inter_pix

Figura 2: Interfaz de entrada

#ifndef __SYNTHESIS__

VS_S32 (*in_vs)[MAX_HEIGHT][MAX_WIDTH] =

(VS_S32(*)[MAX_HEIGHT][ MAX_WIDTH])

malloc (((MAX_HEIGHT)*( MAX_WIDTH))*

sizeof (VS_S32));

#else

VS_S32 _in_vs [MAX_HEIGHT][MAX_WIDTH];

VS_S32 (*in_vs)[MAX_HEIGHT][MAX_WIDTH] =

&_in_vs;

#endif

Figura 3: Conexiones auxiliares

• Las declaraciones de conectores entre lasuniones entre los distintos filtros. Paraconectar una salida de un filtro con otrose debe instanciar una variable auxiliarde tipo FIFO, distinguiendo la parte desıntesis y la de simulacion (ver figura 3).

• La estructura de test. El codigo de testes siempre el mismo: lectura, procesadoy escritura de una imagen. Para ello lounico que se debe modificar es la conexioncon Hw que como mucho es un par delıneas.

Por otra parte las plantillas del codigo Sw(ejecutadas en un entorno Linux) tienen partede codigo que siempre sera el mismo, como esel caso de la comunicacion con el bus AXI4.Estas estructuras son:

• Drivers, y funciones de comunicacion conVDMA y Hw. Estas funciones son losmetodos de configuracion, lectura y es-critura.

• Funciones de conversion AXI4 a tipoOpenCV. Metodos de conversion de tipode dato de AXI4 a OpenCV y viceversa.

• Funcion principal (main). Igual que en eltest, la funcion principal o main sera casitoda igual (tiene lectura, procesado y es-critura). El compilador solo debe mod-ificar o anadir el apartado de configu-racion, arranque y parada del Hw.

Con estos archivos, el compilador solo tieneque rellenar parte del codigo para tener el sis-tema completo.

2.4. Arquitecturas de Referencia

Este bloque constituye las arquitecturasdefinidas de diseno que soporta el compilador.Por ahora se soportan dos:

• La primera se define por una comuni-cacion directa del Hw con el VDMA porel bus AXI4 Stream.

• La segunda define una comunicacion eleg-ible. El sistema Hw permite conexion conotros cores Hw o con el VDMA.

Este bloque admite nuevas arquitecturas quese iran anadiendo en futuras actualizaciones.

2.5. Sistema base

Para una comprobacion del sistema se debeejecutar todo en una placa de pruebas (pla-cas con chips Zynq2). Para ello se decide usarel arranque desde SD y, montar todo en di-cho soporte. La tarjeta tiene las particionesy los archivos necesarios para el correcto fun-cionamiento del sistema. La forma de uso, en elcaso que planteamos, es diferente a la que Xil-inx menciona en sus especificaciones, y constade dos particiones:

• La primera particion FAT32 consta delos archivos necesarios para el arranquey configuracion de la FPGA.

2Estas tarjetas en el momento del artıculo son:Zynq-7000 AP SoC ZedBoard, Xilinx Zynq-7000 APSoC ZC702 Evaluation Kit Xilinx, Zynq-7000 AP SoCVideo and Imaging Kit, Xilinx Zynq-7000 AP SoCZC706 Evaluation Kit y OZ745 Zynq Z7045 AP SoCVideo Development Kit.


51

• La segunda particion consta de todo elsistema de archivos de Linux, y es unadistribucion Linaro.

La primera particion contiene tres archivos,uno de los cuales (BOOT.bin) se genera por elcompilador y los otros dos (devicetree.dtby zImage) se obtienen siguiendo los pasos queXilinx menciona en sus especificaciones. El de-vicetree es el archivo de descripcion de Hwy, en el, hay que anadir las descripciones delos nuevos Hw y habitualmente sera el mismoaunque el filtro haya cambiado porque man-tendra el nombre de la instancia, la direccionen el mapa de memoria, descripciones y losrecursos. Este archivo se genera siguiendo lasespecificaciones que menciona Xilinx. Por ulti-mo el zImage es el kernel de Linux que propor-ciona Xilinx, aunque dependiendo las necesi-dades de Hw que conectan al dispositivo setendra que generar otro con distinta config-uracion. Los kernels soportados hasta el mo-mento son el 3.3, 3.5 y 3.6.

La segunda particion contiene todo el sis-tema de archivos de la distribucion Linaropara ası poder arrancar en un entorno graficocompleto. La distribucion utilizada es la LT12.04.

3. Caso de Estudio

Como caso de estudio se ha realizado el disenode un sistema de deteccion de esquinas (Har-ris Corners) [16]. Se eligio este filtro porquepresenta complejidad media y tiene varias lla-madas a metodos de la biblioteca de OpenCV.Este filtro es conocido en el entorno de visiony ha sido empleado tanto en sistemas Sw [17]como en Hw [4, 18]. En la figura 4 se puedeobservar el codigo OpenCV original.

Partiendo del codigo mencionado anterior-mente, tan solo falta anadir unas sencillas di-rectivas o pragmas (ver figura 5) para que elcompilador AMAZynq sea capaz de procesary obtener todo lo necesario para que el filtra-do funcione por Hw. La figura 6 muestra partedel codigo generado automaticamente.

El compilador nos devuelve tres proyectos.El primero es un proyecto de sıntesis del core

...

cvtColor (src, src_gray, CV_BGR2GRAY);

Sobel(src_gray, Dx, CV_32F, 1, 0, 3,

fff, 0, BORDER_DEFAULT);

Sobel(src_gray, Dy, CV_32F, 0, 1, 3,


...

boxFilter(Dx2, Dxx, Dx2.depth(), Size(2, 2),

Point(-1,-1), false, BORDER_DEFAULT );

boxFilter(Dy2, Dyy, Dx2.depth(), Size(2, 2),


boxFilter(Dxy, Dxy1, Dx2.depth(), Size(2, 2),


...

calcHarris(cov, dst, k );

normalize(dst, dst_norm, 0, 255,

NORM_MINMAX, CV_32SC1, Mat());

convertScaleAbs (dst_norm, dst_norm_scaled);

...

Figura 4: Codigo Original

...

#pragma amazynq_start: //Pragma entrada

cvtColor (src, src_gray, CV_BGR2GRAY);

Sobel(src_gray, Dx, CV_32F, 1, 0, 3,


Sobel(src_gray, Dy, CV_32F, 0, 1, 3,


...

boxFilter(Dx2, Dxx, Dx2.depth(), Size(2, 2),


boxFilter(Dy2, Dyy, Dx2.depth(), Size(2, 2),


boxFilter(Dxy, Dxy1, Dx2.depth(), Size(2, 2),


...

calcHarris(cov, dst, k );

#pragma amazynq_end: //Pragma Salida

...

Figura 5: Codigo con Pragmas


52

...

AMA_HW_CONF(); //Conf

#pragma amazynq_start:

AMA_HW_START(src, dst); //Ini

#pragma amazynq_end:

normalize(dst, dst_norm, 0, 255,

NORM_MINMAX, CV_32SC1, Mat());

convertScaleAbs(dst_norm, dst_norm_scaled);

...

Figura 6: Parte del codigo de salida

Harris Lib1 Harris Lib2

BRAM 18K 18 7

DSP48E 40 52

FF 6259 8200

LUT 4168 6516

SLICE 4843 4638

Cuadro 1: Sıntesis Hw (Informe EDK)

para las herramientas Vivado HlS llamadoama filter hw harris el cual es utilizado paraimplementar el Hw. El segundo proyecto es ladescripcion de Hw (proyecto embebido) parala herramienta EDK, en la que con el nue-vo core generado, se implementa el archivo deconfiguracion de Hw (.bit). Y el tercero es unproyecto Sw que se procesa con un compiladorcruzadado para ARM para obtener el archi-vo ejecutable para el entorno Linux (.elf).Este ejecutable contiene la configuracion de loscores y el software necesario para su puesta apunto y ejecucion.

En la creacion del core, el compilador gen-era un codigo (ver figura 7) para las her-ramientas de Xilinx Vivado HLS y, con ellas,se genera el core desde el compilador o des-de la herramienta Xilinx. A causa de esto, sepuede coger el codigo generado y comprobarsu funcionamiento mediante un archivo de test(Testbench) con la herramientas Xilinx.

Ya sintetizado el core para los dos tiposde librerıas Hw (AMAZynq original (Lib1 )y AMAZyng con soporte Vivado (Lib2 )), sepuede observar la logica utilizada en la sıntesisen este caso de estudio (ver cuadro 1), noteseel uso bastante elevado de DSPs.

Probando el diseno resultante en un test Sw

...

//INPUT INTERFACE

input_adapter_var(inter_pix, *in_axi,

filas, colum);

//HARRIS

vs_rgbtoy_filter_var(*in_axi, *in_vs,

filas, colum);

vs_harris_module_sobel_core_var(*in_vs,

*out_vs1, *out_vs2, filas, colum);

vs_harris_module_conv_core_var_3l(*out_vs1,

*out_vs2, *out_vs11, *out_vs22,

*out_vs12, filas, colum);

c1m_var(*out_vs11, *out_vs22, *out_vs12,

*out_vs, filas, colum);

//OUTPUT INTERFACE

output_adapter_s32_var(*out_vs, out_pix,

filas, colum);

...

Figura 7: Harris HW con adaptadores

(prueba realizada con un ordenador conven-cional) y cogiendo como entrada la imagencapturada por una camera o desde un archi-vo se puede observar y comparar el resultadode la entrada con el filtrado SW y lo esperadopor el Hw (ver figura 8). Tal y como se espera,Se puede observar un comportamiento similaro casi identico entre el SW y el HW.

Ya teniendo todos los archivos generados ytodo lo necesario para la placa, podemos eje-cutar el programa en la propia Zynq y obser-var el funcionamiento de nuestro sistema devision (ver figura 9). En este caso, las diferen-cias son mas apreciables pero, aun ası, el com-portamiento es similar a diferencia de algunadeteccion incorrecta.

En todas las imagenes resultantes se ob-servan cırculos negros que representan las es-quinas detectadas. Para el caso del test Sw seha optado por imagenes procedentes de unawebcam, y en el caso del test por Hw (placa)se generan las imagenes a partir de un Patronde Test generado por un core Hw y conectadopor VDMA por AXIStream.

Por ultimo, mencionamos una diferenciabastante considerable entre el test por Sw y elHw, que es la comunicacion o envıo y recepcionde los datos. En el Hw la comunicacion entrela parte logica con la CPU se realiza a partir


53

(a) Original (b) SW (c) HW

Figura 9: Test Hw

(a) Original

(b) SW

(c) HW

Figura 8: Test SW

de un BUS de comunicaciones del tipo AXI4,y para ello, el compilador instancia un disposi-tivo VDMA en el archivo de configuracion Hw(.mhs). Por contra, en el Sw se ejecuta tododesde la CPU, debido a eso, en el test Sw nose puede probar la comunicacion por el BUSpero si el funcionamiento del core.

4. Conclusiones y Trabajo Futuro

Este trabajo presenta un entorno de disenoprofesional y sencillo para la sıntesis e im-plementacion hardware en nuevos SoCs het-erogeneos, de sistemas de vision definidos me-diante OpenCV. Se ha comprobado el fun-cionamiento de algunos filtros, conectores yadaptadores de tipo de datos, ası como la co-herencia entre Sw y Hw, observandose la simil-itud entre implementaciones de distinta natu-raleza.

El trabajo futuro consiste en aumentar labiblioteca Hw dandole un enfoque mas gener-al, permitiendo por ejemplo que el compiladorpueda manejar algunas variables interesantescomo el tipo o tamano de los datos de los dis-tintos flujos que entran en juego. Tambien sepretende extender el compilador para que seacapaz de realizar pruebas y calcular el errorcometido en simulacion, y optimizar la sınte-sis en el espacio o en el tiempo. La herramientasera por tanto capaz de lanzar una baterıa desıntesis y escoger la implementacion mas ade-cuada dependiendo del caso de uso.


54

Agradecimientos

Este trabajo ha sido financiado gracias al PlanNacional de Investigacion 2010 del Ministe-rio de Ciencia e Innovacion con el proyec-to TEC2010-22095-C03-01. Tambien, agrade-cemos a Xilinx University Program y a JuangoNoguera de Xilinx Research Labs Ireland porsu apoyo y animos.

Referencias

[1] Preliminary Product Specification. Zynq-7000 All Programmable SoC OverviewZynq-7000 All Programmable SoC FirstGeneration Architecture Processing Sys-tem ( PS ) I / O Peripherals and Inter-faces Zynq-7000 All Programmable SoCOverview Programmable I / O Blocks,2013.

[2] Z. Hocenski, I. Aleksi, and R. Mijakovic.Ceramic tiles failure detection based onFPGA image processing. In IndustrialElectronics, 2009. ISIE 2009. IEEE In-ternational Symposium on, pages 2169–2174, 2009.

[3] Ye Li, Qingming Yao, Bin Tian, andWencong Xu. Fast double-parallel imageprocessing based on FPGA. In Vehicu-lar Electronics and Safety (ICVES), 2011IEEE International Conference on, pages97–102, 2011.

[4] Pei-Yung Hsiao, Chieh-Lun Lu, and Li-Chen Fu. Multilayered image processingfor multiscale harris corner detection indigital realization. Industrial Electronics,IEEE Transactions on, 57(5):1799–1805,2010.

[5] C. Claus, R. Huitl, J. Rausch, andW. Stechele. Optimizing the susan cor-ner detection algorithm for a high speedFPGA implementation. In Field Pro-grammable Logic and Applications, 2009.FPL 2009. International Conference on,pages 138–145, 2009.

[6] Qingxu Deng, Hai Xu, Shuisheng Wei,Yu Han, and Ge Yu. An embedded

sopc system using automation design.In Proceedings of the 2005 InternationalConference on Parallel Processing Work-shops, ICPPW ’05, pages 232–239, Wash-ington, DC, USA, 2005. IEEE ComputerSociety.

[7] Jason Cong, Bin Liu, Raghu Prabhakar,and Peng Zhang. A study on the impactof compiler optimizations on high-levelsynthesis. In Hironori Kasahara and KeijiKimura, editors, Languages and Compil-ers for Parallel Computing, volume 7760of Lecture Notes in Computer Science,pages 143–157. Springer Berlin Heidel-berg, 2013.

[8] Joachim Keinert, Martin Streubuhr,Thomas Schlichter, Joachin Falk, JensGladigau, Christian Haubelt, Jurgen Te-ich, and Michael Meredith. SystemCoDe-signer - An automatic ESL synthesis Ap-proach by Design Space Exploration andBehavioral Synthesis for Streaming Ap-plications. ACM Trans. Des. Autom.Electron. Syst., 14(1):1:1–1:23, January2009.

[9] Wim Meeus, Kristof Van Beeck,Toon Goedeme, Jan Meel, and DirkStroobandt. An overview of today’s high-level synthesis tools. Design Automationfor Embedded Systems, pages 1–21, 2012.

[10] G. Martin and G. Smith. High-level syn-thesis: Past, present, and future. DesignTest of Computers, IEEE, 26(4):18–25,2009.

[11] J. Cong, Bin Liu, S. Neuendorffer,J. Noguera, K. Vissers, and Zhiru Zhang.High-level synthesis for fpgas: From pro-totyping to deployment. Computer-AidedDesign of Integrated Circuits and Sys-tems, IEEE Transactions on, 30(4):473–491, 2011.

[12] M. Dragusu, A.N. Mihalache, andR. Solea. Practical applications forrobotic arms using image processing. InSystem Theory, Control and Computing


55

(ICSTCC), 2012 16th InternationalConference on, pages 1–6, 2012.

[13] S. Sankaraiah and R.S. Deepthi. High-ly optimized opencv based cell phone. InSustainable Utilization and Developmentin Engineering and Technology (STU-DENT), 2011 IEEE Conference on, pages47–52, 2011.

[14] M. Marengoni and D. Stringhini. Highlevel computer vision using opencv. InGraphics, Patterns and Images Tutorials(SIBGRAPI-T), 2011 24th SIBGRAPIConference on, pages 11–24, 2011.

[15] Yannick Allusse, Patrick Horain, AnkitAgarwal, and Cindula Saipriyadarshan.Gpucv: A gpu-accelerated framework forimage processing and computer vision.In George Bebis, Richard Boyle, BahramParvin, Darko Koracin, Paolo Remagni-no, Fatih Porikli, Jorg Peters, James

Klosowski, Laura Arns, YuKa Chun,Theresa-Marie Rhyne, and Laura Mon-roe, editors, Advances in Visual Com-puting, volume 5359 of Lecture Notesin Computer Science, pages 430–439.Springer Berlin Heidelberg, 2008.

[16] Chris Harris and Mike Stephens. A com-bined corner and edge detector. In Alveyvision conference, volume 15, page 50.Manchester, UK, 1988.

[17] J.-B. Ryu, C.-G. Lee, and H.-H. Park.Formula for harris corner detector. Elec-tronics Letters, 47(3):180–181, 2011.

[18] M. Birem and F. Berry. Fpga-based realtime extraction of visual features. In Cir-cuits and Systems (ISCAS), 2012 IEEEInternational Symposium on, pages 3053–3056, 2012.


56

Reducción de los tiempos de cómputo de la MigraciónSísmica usando FPGAs y GPGPUs: Un artículo de

revisión.

Carlos Fajardo(1), Javier Castillo(2), Cesar Pedraza(3),José Ignacio Martínez(2)[email protected], [email protected], [email protected],[email protected]

(1)Universidad Industrial de Santander, Bucaramanga(2)Universidad Rey Juan Carlos, Madrid (3)Universidad Santo Tomás, Bogotá

Resumen

El proceso de búsqueda de hidrocarburos seinicia con la construcción de una imagen delsubsuelo del área a explorar, la calidad de es-tas imágenes es fundamental para realizar unabuena predicción antes de proceder a realizaruna costosa perforación. La construcción deuna imagen del subsuelo requiere de decenasde procesos computacionales, siendo la Migra-ción Sísmica (MS) el último de ellos y el demayor costo computacional. Este artículo haceuna revisión entorno a los esfuerzos que actual-mente se están realizando con el propósito dereducir el tiempo de cómputo de la MS. Noso-tros introducimos los métodos más utilizadospara realizar el proceso de Migración, así co-mo también las dos arquitecturas computacio-nales que están ofreciendo mejores tiempos deprocesamiento. Revisamos las implementacio-nes más representativas de este proceso sobreestas dos tecnologías y resumimos los aportesde cada una de estas investigaciones. El artícu-lo finaliza con nuestras creencias acerca de ladirección que deben tomar futuras investiga-ciones en esta área.

1. Introducción

El costo de una exploración del subsuelo es-tá en el orden de las decenas de millones dedólares y la probabilidad de encontrar petró-leo es relativamente baja, por lo cual, la in-dustria petrolera debe realizar estudios que lepermitan reducir la incertidumbre en las áreas

a explorar. La principal técnica utilizada porla industria del petróleo para identificar posi-bles reservas de hidrocarburos es construir unaimagen del subsuelo por medio de la técnica dela Reflexión Sísmica, esta técnica está basadaen las propiedades de reflexión de las ondassonoras.

1.1. Adquisición de las trazas sísmicas

Para la construcción de una imagen del sub-suelo, se requiere adquirir gran cantidad de da-tos sísmicos, esta adquisición se inicia con laubicación de una serie de sensores, llamadosgeófonos, sobre el área a explorar; si los sen-sores se ubican en línea recta se dice que laadquisición es 2D o si ocupan una área se di-ce que la adquisición es 3D. Una vez ubicadoslos geófonos, se activa una fuente artificial desonido en el área a explorar (un camión vibra-dor, una carga explosiva o bombas de aire enel océano). El registro de un geófono duranteun disparo recibe el nombre de traza sísmica.

1.2. La migración sísmica

Con el propósito de construir una imagendel subsuelo, las señales sísmicas detectadaspor los geófonos (las trazas) deben ser pro-cesadas en varios módulos de procesamiento,el último de ellos se denomina MigraciónSísmica y es el de mayor costo computacional.Este módulo busca reubicar los reflectores(las uniones de los diferentes geológicos) deuna posición virtual a su posición correcta;la importancia de la migración de los datos


57

sísmicos fue reconocida desde 1921 [6] yaque sin este último módulo la imagen que seobtendría sería incorrecta, especialmente enzonas geológicamente complejas [7].

En el experimento sísmico se asume que latierra está compuesta por una serie de capaszi, como se ilustra en la figura 1; las fuentesy los receptores se ubican en la superficie delárea a explorar; la velocidad de la propagaciónde la onda en la tierra v(x, y, z), varía en todaslas direcciones, pero para simplificar el modeloalgunas veces se asume que la velocidad sólovaría verticalmente y que es constante durantetoda la capa zi. La migración permite reubi-car el reflector AB’ supuesto en el punto medioentre el emisor y el receptor (ver figura 1), asu posición correcta AB; esto se logra por me-dio de la solución de la ecuación de onda (verecuación (1)). La solución de esta ecuación uti-liza un modelo de velocidad (v) del terreno aexplorar y la información recolectada por losgeófonos [8].

Fuente Receptor

Figura 1: Problema que resuelve la migración sís-mica. (Adaptado de [8])

Matemáticamente la migración sísmica tra-ta de encontrar una solución P (x, y, z, t) a laecuación (1), usando la condición de fronteraP (x, y, 0, t), que fue recolectada en la superfi-cie del terreno [7].

∂2P

∂x2+

∂2P

∂y2+

∂2P

∂z2=

1

v2∂2P

∂t2, (1)

La imagen del subsuelo I(x, y, z) puede serextraída de P (x, y, z, t), evaluando esta últi-

ma en t = 0 (Ver ecuación (2)), basado en elconcepto del reflector que explota [9]:

I(x, y, z) = P (x, y, z, t)|t=0 , (2)

1.3. Algoritmos utilizados para realizar lamigración sísmica

Como se mencionó anteriormente, la impor-tancia de la migración fue reconocida desdehace varios años y a partir de ahí han apareci-do una serie de algoritmos que permiten reali-zar este procedimiento, la industria del petró-leo usa paquetes comerciales de software parahacer el procesamiento de sus datos sísmicos(ver por ejemplo [10, 11]), estas herramientasprocesan los datos sísmicos por medio de va-rios módulos de procesamiento y el último deellos es el módulo de migración.

Los algoritmos son diferentes estrategias desolución a la ecuación (1) y utilizan algunaaproximación escalar a dicha ecuación [12]. Acontinuación se hace una descripción de algu-nos de estos algoritmos desde el punto de vistacomputacional:

1.3.1. Migración de Kirchhoff

Este es el método de migración más popularen la industria del petróleo y fue el primero enser implementado en un equipo de cómputo yuno de los de menor costo computacional. Elprincipio matemático que utiliza este algorit-mo es bastante sencillo: se parte de un emisory un receptor en la superficie a explorar, se mi-de el tiempo que se tarda el frente de onda enhacer la trayectoria emisor-reflector-receptor;con este valor se pueden calcular todos los po-sibles reflectores. Con velocidad constante, ellugar geométrico que ocupan estos posibles re-flectores, es la mitad inferior de una elipse pa-ra el caso 2D o un elipsoide para el caso 3D(de acuerdo a la definición geométrica de unaelipse) como se muestra figura 2. Esta informa-ción (la traza no migrada) no es suficiente paradecidir cuál de todos los infinitos puntos queconforman este lugar geométrico es el receptorverdadero, con otra traza sísmica, la migraciónpuede calcular otros posibles reflectores, la mi-gración de Kirchhoff repite este procedimiento


58

sobre todas las trazas y finalmente suma todaslas contribuciones de las elipses (o los elipsoi-des) y de esta manera se forma la imagen delsubsuelo [12].

Fuente Receptor

Figura 2: Lugar geométrico de los posibles reflec-tores (Adaptado de [13])

Matemáticamente la migración de Kirchhoffimplica operaciones de suma, resta, multiplica-ción, división y radicación las cuales general-mente se realizan en formato de coma flotanteprecisión sencilla pues el formato de precisióndoble no es requerido para esta aplicación.

1.3.2. Cambio de Fase

El cambio de fase es un método que hace usodel concepto del reflector que explota [9]. Separte de P (x, y, 0, t) hasta llegar a P (x, y, z, 0);en este método la extrapolación se hace en eldominio de la frecuencia y por medio de unoperador de cambio de fase. Este método co-mienza con una transformada de Fourier de losdatos, que puede ser en 2D o 3D (dependiendodel tipo de adquisición), luego se aplica el ope-rador de cambio de fase y finalmente se utilizauna transformada inversa de Fourier [7].

1.3.3. Método por Diferencias Finitas

Consiste en la discretización de la ecuación(1) (o una aproximación de ella), reemplazan-do las derivadas parciales por una aproxima-ción en diferencias centrales (esto se logra pormedio de la aproximación de la serie de Tay-lor). Para mejorar la precisión en este métodose requiere aumentar el número de puntos quese toman en la aproximación, pero obviamenteesto requiere una mayor cantidad de operacio-nes computacionales. De igual manera en este

método se hace necesario tener en cuenta pro-blemas relacionados con los errores de trunca-miento y criterios de estabilidad con el fin deasegurar la convergencia del método [14].

1.3.4. Migración Reversa en el Tiempo

Este es el método que en la actualidad ofreceuna mejor calidad en la imágenes y aunque fueintroducido en 1983 [15] su alto costo compu-tacional impidió que se usara en el pasado [5].Este consiste en resolver una aproximación dela ecuación (1) dos veces, estas dos solucio-nes reciben el nombre de propagaciones haciaadelante y hacia atrás, luego los dos resulta-dos son correlacionados para obtener la ima-gen [4]. Matemáticamente este método implicael operador Laplaciano, diferencias finitas y unmétodo explícito para realizar integración enel tiempo [16].

1.4. Clases de Migración

La migración puede ser aplicada de diferen-tes formas, estas formas son llamadas clases:pos-apilado, pre-apilado, 2D o 3D, en tiempo oen profundidad. Estas clases forman ocho po-sibles combinaciones [17].

1.4.1. Migración Pos-apilada y Migra-ción Pre-apilada

Un proceso usado para mejorar la relaciónseñal a ruido de la trazas sísmicas y reducir elcosto de procesamiento es el apilamiento. Esteproceso consiste en sumar las trazas obtenidasen varios disparos que se reflejan en un mis-mo punto [18]. Si la migración se aplica des-pués del apilamiento se denomina migraciónpos-apilada y su principal ventaja es la reduc-ción del tiempo de cómputo, debido a que elnúmero de trazas a ser procesadas se decre-menta significativamente; su desventaja es queeste procedimiento disminuye la precisión, es-pecialmente en terrenos geológicamente com-plejos. Cuando la migración se aplica antes delapilamiento (migración pre-apilada) se mejorala precisión, pero se requiere más tiempo decómputo (entre 60 y 120 veces más) que en lamigración pos-apilada [18, 17].


59

1.4.2. Migración 2D o Migración 3D

Dependiendo de como las trazas sísmicasson grabadas, la migración puede ser clasifica-da en 2D o 3D. En la migración 2D, la energíaes reflejada en un plano, luego los geófonos sonlocalizados en linea recta. En la migración 3Dlos geófonos ocupan un área sobre la superfi-cie a explorar. De manera general la migración3D puede proveer una mayor resolución en laimágenes pero requiere un mayor tiempo decómputo, lo que puede durar días en el proce-samiento en sísmica 2D puede tardar semanascon adquisiciones 3D [17].

1.4.3. Migración en tiempo o Migra-ción en profundidad

Existen dos enfoques para la migración sís-mica: el tiempo y la profundidad. En térmi-nos simples la migración en tiempo localizalos reflectores midiendo el tiempo de viaje delfrente de onda, mientras que la migración enprofundidad lo hace en función de la profun-didad. La migración en tiempo ha sido la másempleada durante los últimos años, pero algu-nos estudios [18] muestran que la migraciónen profundidad ofrecen mejores resultados pe-ro se requiere un mejor modelo de velocidad ymayor capacidad de cómputo.

1.5. Criterios para la selección de la clasemigración

Como se mencionó anteriormente si se com-binan las diferentes posibilidades que se tienenactualmente para aplicar la migración, se tie-nen ocho diferentes posibilidades. En la figura3 se resumen los criterios de selección descritospor Farmer en [17] (aqui no se tiene en cuentael tipo de adquisión 2D o 3D):

1.6. Costo computacional de la migraciónsísmica

Una ventaja del proceso de la MS es quegracias a que los disparos se hacen en tiemposdiferentes, cada una de las trazas sísmicaspuede ser procesada de manera independiente,lo cual facilita la paralelización del procesoal ser implementado [16, 19]. Sin embargo, la

(a) (b)

(c) (d)

Aum

enta

la V

elo

cid

ad

Figura 3: Esquema para la selección de la clase demigración [17]:(a) Velocidades simples + estruc-tura simple = Migración pos-apilada en tiempo;(b) Velocidades simples + estructura compleja =Migración pre-apilada en tiempo; (c) Velocidadescomplejas + estructura simple = Migración pos-apilada en profundidad; (d) Velocidades complejas+ estructura compleja = Migración pre-apilada enprofundidad

implementación de la MS sobre un sistema decómputo tiene tres retos principales:

1.6.1. Transferencia de Datos

La cantidad de datos que requieren sertransferidos desde la memoria principal a losdispositivos de cómputo es elevada, una adqui-sición típica puede requerir 30000 geófonos ycada sensor muestrea datos a más de 2kbps,con una nueva detonación cada 10 segundos,de tal forma que la cantidad de datos que seobtienen cada día puede estar en el orden delos terabytes [20].

1.6.2. Memoria

La cantidad de memoria requerida para rea-lizar la MS fácilmente supera la capacidadde memoria disponible en el dispositivo decómputo [16].

1.6.3. Cómputo

La migración sísmica es una aplicación querequiere gran cantidad de cómputo, actual-mente el tiempo requerido para migrar losdatos obtenidos durante un estudio sísmico


60

está en el orden de las semanas y más del 90%de este tiempo se emplea en la realización deoperaciones matemáticas.

2. Implementación de la MigraciónSísmica sobre FPGAs y GPG-PUs

En esta sección se revisan las diferentes im-plementaciones de la migración sísmica tantosobre FPGAs como sobre GPGPUs. De igualmanera se revisan cómo estas investigacioneshan abordado los problemas computacionalesque presenta esta aplicación.

2.1. Migración de Kirchhoff, implementa-da sobre una Virtex II Pro (2004)

En el año 2004 en la Universidad de TexasA&M se realizó la primera implementacióndel proceso de migración sobre una FPGA[13], en este trabajo se implementó la Migra-ción de Kirchhoff Pre-apilada en Tiempo enla plataforma Xilinx Virtex II Pro. La FPGAfue conectado a una estación de trabajo através del bus PCIe, esta plataforma (llamadaSPACE) contiene dos tipos de memoria: DosRAM static dual-port que hacen las vecesde memoria caché de rápido acceso y cuatromódulos DDR-RAM (Double Data RateRamdom Access Memory).

2.1.1. Aportes del trabajo

En este trabajo se busca mejorar el tiempoque tarda la FPGA en realizar una raiz cua-drada utilizando un módulo CORDIC [88].En la migración de Kirchhoff se requierenrealizar tres operaciones matemáticas: sumas,multiplicaciones y raices cuadradas. De lastres operaciones requeridas, la raíz cuadradaes el módulo más lento en hardware con unalatencia de al menos diez veces más que unmultiplicador full pipeline. Gracias a que al-gunos datos utilizados en la migración sísmicaestán acotados (por ejemplo los valores detiempo no superan los 16 segundos) en estetrabajo se implementó un módulo CORDIC

full pipeline para realizar la raíz cuadrada.Este módulo primero convierte los datosde punto flotante a punto flotante alineado(los exponentes son iguales), los exponentesse mantienen constantes y las dos mantisasalimentan una unidad CORDIC para realizarla raiz cuadrada.

2.1.2. Resultados

• Con una frecuencia de trabajo de 50MHzse logró una aceleración de 15,6x compa-rada con un 2.4GHz Pentium 4.

• En este trabajo se realizó una compara-ción de los errores cometidos al usar elmódulo CORDIC y un programa en C(precisión doble) y los errores no tienenmayores repercusiones en los patrones delas imágenes generadas.

2.2. Diferencias finitas en el dominio deltiempo, implementada sobre una Xi-linx ML401 (2005)

La migración sísmica consiste en la soluciónde una ecuación de onda y las diferencias fi-nitas es uno de los métodos más utilizados eneste proceso. Esta implementación [89] es unaversión mejorada de [13] y fue realizada por elmismo grupo de investigación.

2.2.1. Aportes del trabajo

En este trabajo se aborda el problema re-lacionado con el ancho de banda entre la me-moria y la FPGA, el cual impide que se puedesacar todo el potencial de las FPGAs. En estetrabajo se proponen dos soluciones para mejo-rar el ancho de banda: reescribir la aplicacióncon el propósito de disminuir la cantidad dedatos que requieren ser leídos y el diseño deuna nueva arquitectura para el manejo de lamemoria. Las ecuaciones de onda se puedenrepresentar como un sistema de primer ordenen forma de derivada, pero también se puedenpresentar de segundo orden sin perder genera-lidad. La representación de las ecuaciones deonda como ecuaciones de segundo orden traeun beneficio en una implementación basada en


61

FPGAs pues ofrece un mejor rendimiento enel acceso a la memoria. En este trabajo se des-cribe la ecuación de onda usando ecuacionesde segundo orden con el propósito de mejo-rar el uso de ancho de banda de la memo-ria. Otra propuesta es el uso de las memoriasDDR-SDRAM (las cuales se pueden encontraren las plataformas reconfigurables), éstas tie-nen la posibilidad de ofrecer un alto through-put a un relativo bajo precio. Basados en ladependencia de datos que tiene la solución dela ecuación de onda, en este trabajo se intro-duce una interfaz entre los módulos de compu-to y la memoria onboard usando los módulosonchip de memoria de la FPGA. Este módulopermite utilizar el ancho de banda de la memo-ria onboard más eficientemente que los traba-jos anteriores y puede ser implementado en lamayoría de sistemas de desarrollo basados enFPGAs. Básicamente en este trabajo se pro-pone una nueva manera de acceder a los datosde la grid, almacenando algunos valores den-tro de la FPGA con el fin de evitar el accesoa la memoria onboard. Los datos en la FPGAse almacenan en dos FIFOs en cascada, estosbuffers se implementan en los módulos de me-moria onchip. Los datos del grid van entrandopor un puerto de entrada al fondo del primerFIFO y se va descartando el ultimo del segun-do FIFO, de tal forma que en el FIFO se tienendisponibles todos los datos necesarios para ca-da computo dentro de la FPGA.

2.2.2. Resultados

En este trabajo se obtienen aceleraciones dehasta 8,26x comparado con un Intel P4 3.0GHz.

2.3. Downward continued migration,implementada sobre la plataformaMAX1 (2007)

En [90] buscan mejorar el rendimiento dela FPGA y optimizar el uso del puerto PCIereduciendo la cantidad de bits con la cual serepresentan los datos, para tal fin, se imple-menta una parte de la Downward ContinuedMigration utilizando un número menor de bitsa los empleados anteriormente. La implemen-

tación se realizó en una plataforma MAX1 [91]la cual contiene una FPGA Virtex-4 FX100.

2.3.1. Aportes del Trabajo

Se simuló todo el proceso de migración sís-mica y se seleccionaron aquellas partes quese encuentran acotadas, estas partes se imple-mentaron en punto fijo con 10, 6 y 5 bits en laparte decimal en lugar de utilizar números decoma flotante.

2.3.2. Resultados

Cómo se observa en la figura 4, las gráfi-cas del subsuelo (para los diferentes númerosde bits en la parte decimal) son visualmenteidénticas.

(a) CPU (b) 10 Bits

(c) 6 Bits (d) 5 Bits

Figura 4: Implementación sobre la FPGA con di-ferente cantidad de bits en la parte decimal [90]

En este trabajo se alcanzaron aceleracionesde hasta 42x comparados con una implemen-tación software (precisión doble) en un 2.8GHzAMD Opteron-based PC con 12 GB de RAM.

2.4. Downward continued migration,implementada sobre la plataformaMAX1 (2008)

En [92] nuevamente se aborda el problemadel computo desde la perspectiva de la repre-sentación de los datos. El objetivo de esta in-vestigación es encontrar las partes de la mi-gración que pueden ser desarrolladas en pun-


62

to fijo y determinar cuál es el número menorde bits requeridos para conseguir imagenes delsubsuelo de aceptable calidad. En este trabajose utiliza como caso de estudio la ecuación 3,esta ecuación exponencial compleja es comúna todas las clases de Downward continued mi-gration.

U(w, ks, kg, z +4z) =

exp

−iwk

√√√√

1−vkgw

+

√√√√1−

vksw

U(w, ks, kg, z)(3)

2.4.1. Aportes del Trabajo

• En este trabajo se usan los resultados delas aproximaciones matemáticas de Lee2005 [93] que permiten mapear eficiente-mente sobre FPGAs, raíces cuadradas yfunciones trigonométricas.

• Se desarrollo una herramienta que permi-te calcular el número menor de bits reque-rido para el caso propuesto.

• Se realizaron pruebas con coma flotantede menos de 32 bits.

2.4.2. Resultados

• Se establecieron como cantidad mínimade bits 12 y 16 para la raiz cuadrada ylas funciones trigonométricas respectiva-mente.

• Con puntos fijos de hasta 12 bits se cons-truyen imágenes con los mismos patronesque las generadas en software (precisióndoble).

• Se estableció que se pueden realizar lasoperaciones en coma flotante de 22 bits, 6para el exponente y 16 para la mantiza.

• Las imagenes generadas fueron compara-das por medio de filtros de error con ima-genes generadas en precisión doble y seobtuvieron los mismos patrones.

• Con dos cores implementados en la FPGAse logró una aceleración de 13,7x compa-rado con un Intel Xeon 1.86GHz.

• Con este nuevo formato de números se re-duce considerablemente el área empleadadentro de la FPGA.

• Se estableció que con el suficiente anchode banda se pueden poner 6 cores dentrode la FPGA y lograr una aceleración dehasta 48x.

2.5. Compresión de Datos Sísmicos: Tesisde Maestría (2009)

En la tesis de maestria [94] se aborda el pro-blema de mejorar el ancho de banda entre lamemoria y el dispositivo de computo utilizan-do compresión de datos. En esta investigación,se utiliza el algoritmo de compresión propues-to por T. Røsten [95] para comprimir los datossísmicos antes de ser enviados a la GPGPUs.

2.5.1. Aportes

El objetivo de esta investigación es revisarsi la transmisión de datos comprimidos desdeuna memoria principal hasta la memoria de laGPU y su posterior descompresión resulta enun tiempo más corto que el envío de la mis-ma cantidad de datos sin comprimir. Para talfin se implementa dicho algoritmo sobre unaGPGPU Quadro FX 5800 de NVIDIA.

2.5.2. Resultados

Los resultados no fueron positivos, el en-vío de datos comprimidos a la memoria de laGPU y su posterior descompresión consumemás tiempo que un envío de datos sin compri-mir.

2.6. Migración Reversa en el Tiempo(RTM) sobre un cluster Maxeler quecontiene cuatro Virtex 6 (2011)

En [1] se detalla el procedimiento para im-plementar la RTM dentro de una FPGA. Elcluster utilizado es de la empresa Maxeler, elcual contiene 8 CPUs y cuatro Virtex 6.

2.6.1. Aportes

La comunicación entre FPGAs es realizadapor medio del puerto MaxRing y por medio


63

de éste, se obtuvo un ancho de banda que noafectó el computo.

En esta investigación se utilizan las herra-mientas CAD ofrecidas por Maxeler, las cualespermiten introducir la aplicación descrita enJava. El procedimiento utilizado para la im-plementación sobre la FPGA es:

1. Modificar el kernel: simplificar, aplanar,convertir los lazos dinámicos en lazos es-táticos.

2. El kernel modificado se compila en unDiagrama de flujo de Datos (data-flowgraph). Gracias a que estos diagramas sonestáticos es posible determinar los cami-nos críticos y la cantidad de operaciones.

3. Se convierte el Diagrama de Flujo de da-tos en una synchronous data-flow machi-ne. Cada nodo en esta máquina es unaoperación (punto fijo o flotante) un multi-plexor o un buffer. Idealmente cada opera-ción debe durar un ciclo de reloj y las ope-raciones complejas se les aplica pipeline auna rata de un ciclo por sub-operación.

4. Repetir los pasos anteriores para optimi-zar.

2.6.2. Resultados

• Este trabajo logró una aceleración 70xcomparado contra un dual-processorquad-core 2.9-GHz Intel Nehalem.

• Adicionalmente en este trabajo se calcu-lan los consumos de potencia: 500W parala FPGA y 700W para para el servidorNehalem. La CPU consumiría 14000W sise acelera su proceso 40x.

• En este trabajo también se implementa laRTM sobre una GPU, la cual obtuvo unaaceleración de 5x comparada con la CPU.

2.7. Migración en Tiempo inverso sobretres arquitecturas diferentes: Cell/Be,GPGPUs y FPGAs (2011)

En [16] se compara la implementación dela RTM sobre tres arquitecturas diferentes:Cell/Be, GPGPUs y FPGAs.

2.7.1. Aportes

En la implementación sobre la GPGPU secomprimen los datos antes de ser enviados aldisco con el propósito de ahorrar espacio. Elvolumen de datos es almacenado en un buf-fer mientras se están enviando al disco. Tenerel volumen de datos almacenados en un buf-fer permite desarrollar de manera concurrenteel envío de datos con el computo del siguientedato. La cantidad de memoria necesaria paraun disparo supera fácilmente la capacidad dememoria disponible en una GPGPU (4 GiB eneste caso), la aplicación es particionada en tan-tos subdominios como GPGPUs existen. En laimplementación sobre la FPGA, este trabajose enfoca en el reuso de los datos, para tal finse utilizan los tres niveles de memoria con losque cuenta la plataforma empleada. Adicional-mente se usa la compresión y descompresión dedatos y se sugiere el uso de punto fijo en lugarde punto flotante.

2.7.2. Resultados

Todas las implementaciones estuvieron cer-ca de acelerar el proceso por un factor 10x. Sinembargo los resultados de la GPU estuvieronpor encima del desempeño de la implementa-ción sobre la FPGA.

2.8. Resumen de resultados

En la Tabla I se resumen los aportes y resul-tados de las implementaciones de la MigraciónSísmica sobre FPGAs y GPGPUs encontradasdurante la presente búsqueda.

3. Conclusiones

A continuación listamos algunas lineas deinvestigación que consideramos importantes,con el fin de continuar optimizando el uso delas FPGA y las GPGPU en el área del proce-samiento de datos sísmicos:

• El uso de la compresión de datos sísmicoscomo estrategia para aumentar la veloci-dad de transferencia de las trazas sísmi-cas: En este momento la velocidad a la


64

Cuadro 1: Tabla de ResultadosAño Aplicación Dispositivo Aportes Resultados2004 Migración de Kirchhoff

Pre-apilada en TiempoVirtex 2 Pro Uso del Módulo CORDIC para

implementar la raiz cuadrada15,6x vs2.4GHz Pen-tium 4

2005 Diferencias finitas en eldominio del tiempo

Xilinx ML401 Reescribir la ecuación de ondausando ecuaciones de segundoorden. Interfaz de FIFOs im-plementados en la memoria on-chip con el fin de disminuir lasveces que se tiene que leer lamemoria

8,26x vs IntelP4 3.0 GHz

2007 Downward continuedmigration

MAX1 (Virtex-4)

Uso de punto fijo 42x vs 2.8GHzAMD Opteron

2008 Downward continuedmigration

MAX1 (Virtex-4)

Uso de punto fijo. Aproxima-ciones LEE. Herramienta paracalcular el número de menor debits en la parte decimal cuandose usa punto fijo

13,7x vs IntelXeon 1.86GHz

2009 Algoritmo de compre-sión Røsten

GPGPUs Compresión de datos sísmicos Negativos

2011 Migración Reversa enel Tiempo

Virtex 6 (Cua-tro)

Herramientas CAD de Maxe-ler. Puerto MaxRing para lacomunicación entre FPGAs

70x vs In-tel Nehalem2.9-GHz

2011 Migración Reversa enel Tiempo

GPU y FPGAs Compresión de datos y uso dePunto fijo.

10x vs XeonE5460 2.5 GHz

cual se ingresan los datos sísmicos al dis-positivo no permite mantener aprovecharel 100% del potencial de cómputo de estasdos arquitecturas. El uso de la compresiónpara aumentar la velocidad de transferen-cia requiere que el tiempo de envío de losdatos comprimidos más el tiempo de des-compresión sea menor que el tiempo deenvío de los datos sin comprimir. Al res-pecto, creemos que esta estrategia puedellegar a ser más viable en las FPGA, puesen estos dispositivos las operaciones adi-cionales de descompresión pueden llegar aconvertirse en más hardware y no en mástiempo, gracias a la flexibilidad que ofre-cen las FPGA para aplicar la técnica desegmentación.

• El uso de compiladores CtoHDL: El usode las FPGA en este contexto se ha vistofrenado por la dificultad que representaimplementar a nivel RTL el todo algorit-

mo de migración (las investigaciones hanimplementado sólo partes de él), una es-trategia que podria promover el uso de lasFPGA, sería el uso de los compiladoresCtoVHDL, sin embargo, se hace necesarioevaluar este tipo de herramientas, a fin dedeterminar la eficiencia de las implemen-taciones en términos de área, throughputy throughput/área.

• La optimización de la implementaciónde operaciones matemáticas sobre estasdos tecnologías seguirán siendo clavespara mejorar los tiempos de computode la MS. En este sentido, se requiereninvestigaciones que giren en torno a laoptimización de las operaciones matemá-ticas requeridas por la RTM, por ser eltipo de migración que ofrece una mayorresolución en la imágenes generadas. Deigual manera las investigaciones debencontemplar la posibilidad de utilizar


65

diferentes formatos para representar losdatos sísmicos (como por ejemplo puntofijo y coma flotante menor a 32 bits).

Referencias

[1] Olav Lindtjorn, Robert G Clapp, OliverPell, and Michael J Flynn. Beyond tradi-tional microprocessors for Geoscience High-Performance computing a pplications andGeoscience. Ieee Micro, pages 41–49, 2011.

[2] André Rigland Brodtkrorb. Scientific Com-puting on Heterogeneous Architectures. Phdthesis, University of Oslo, 2010.

[3] Robert G. Clapp, Haohuan Fu, and OlavLindtjorn. Selecting the right hardware for re-verse time migration. The Leading Edge, 29(1):48, 2010.

[4] J Cabezas, M Araya-Polo, I Gelado, N Na-varro, E Morancho, and J M Cela. High-Performance Reverse Time Migration on GPU.2009 International Conference of the ChileanComputer Science Society, pages 77–86, No-vember 2009.

[5] Rached Abdelkhalek, Henri Calandra, OlivierCoulaud, Jean Roman, and Guillaume Latu.Fast seismic modeling and Reverse Time Mi-gration on a GPU cluster. 2009 InternationalConference on High Performance Computing& Simulation, pages 36–43, June 2009.

[6] V.K. Madisetti and D.G. Messerschmitt. Seis-mic migration algorithms using the FFTapproach on the NCUBE multiprocessor.ICASSP-88., International Conference onAcoustics, Speech, and Signal Processing, pa-ges 894–897, 1988.

[7] Sudhakar Yerneni, Suhas Phadke, DheerajBhardwaj, Subrata Chakraborty, and RichaRastogi. Imaging subsurface geology with seis-mic migration on a computing cluster. CurrentScience, 88(3):468 – 478, 2005.

[8] V.K. Madisetti and D.G. Messerschmitt. Seis-mic migration algorithms on parallel compu-ters. IEEE Transactions on Signal Processing,39(7):1642–1654, July 1991.

[9] Jon F. Claerbout. BASIC EARTH IMAGING.http://sepwww.stanford.edu, 2010.

[10] Promax family seismic data processing soft-ware. http://www.halliburton.com/. Revisa-do Julio de 2011.

[11] Seisup production seismic processing system.http://www.geocenter.com/. Revisado Juliode 2011.

[12] Samuel H. Gray, John Etgen, Joe Dellinger,and Dan Whitmore. Seismic migration pro-blems and solutions. Geophysics, 66(5):1622,2001.

[13] Chuan He, Mi Lu, and Chuanwen Sun. Acce-lerating Seismic Migration Using FPGA-BasedCoprocessor Platform. 12th Annual IEEESymposium on Field-Programmable CustomComputing Machines, pages 207–216, 2004.

[14] Diego Brandao, Marcelo Zamith, EstebanClua, Anselmo Montenegro, Andre Bulcao,Daniel Madeira, Mauricio Kischinhevsky, andRegina C.P. Leal-Toledo. Performance Evalua-tion of Optimized Implementations of FiniteDifference Method for Wave Propagation Pro-blems on GPU Architecture. 2010 22nd Inter-national Symposium on Computer Architectu-re and High Performance Computing Works-hops, pages 7–12, October 2010.

[15] Edip Baysal. Reverse time migration.Geophysics, 48:1514–1524, 1983.

[16] Mauricio Araya-polo, Javier Cabezas, Mau-ricio Hanzich, Miquel Pericas, Isaac Gelado,Muhammad Shafiq, Enric Morancho, NachoNavarro, Mateo Valero, and Eduard Ayguade.Assessing Accelerator-Based HPC Reverse Ti-me Migration. Electronic Design, 22(1):147–162, 2011.

[17] Paul Farmer, Sam Gray, Graham Hodgkiss,Andy Pieprzak, and Davis Ratcliff. StructuralImaging : Toward a Sharper Subsurface View.Oilfield Review, 1(1):28–41, 1993.

[18] Albertin Albertin, Jerry Kapoor, RichardRandall, and Mart Smith. La era de las imáge-nes en escala de profundidad. Oilfield Review,pages 2–17, 2002.

[19] Sergio Abreo and Ana Ramirez. Viabilidadde acelerar la migración sísmica 2D usando unprocesador específico implementado sobre unFPGA The feasibility of speeding up 2D seis-mic migration using a specific processor on anFPGA. Ingeniería e investigación, 30(1):64–70, 2010.

[20] Michael Flynn, R. Dimond, O. Mencer, andO. Pell. Finding Speedup in Parallel Proces-sors. 2008 International Symposium on Pa-rallel and Distributed Computing, pages 3–7,2008.

[21] Xilinx. http://www.xilinx.com/. Revisado:Agosto de 2011.


66

[22] Altera. http://www.altera.com/. Revisado:Agosto de 2011.

[23] Atmel. http://www2.atmel.com/. Revisado:Agosto de 2011.

[24] Lattice Semiconductor Corporation. http://www.latticesemi.com/. Revisado: Agosto de2011.

[25] Achronix Semiconductor Corporation. http://www.achronix.com/. Revisado: Agosto de2011.

[26] Xilinx Intellectual Property. www.xilinx.com/products/intellectual-property/. Re-visado: Agosto de 2011.

[27] Altera: Intellectual Property & Reference De-signs. www.altera.com/products/ip/. Revisa-do: Agosto de 2011.

[28] Cray: The Supercomputing company. http://www.cray.com/. Revisado: Noviembre de2011.

[29] sgi: A Trusted Leader in Technical Compu-ting. http://www.sgi.com/. Revisado: No-viembre de 2011.

[30] Annapolis Micro Systems, Inc. http://www.annapmicro.com/. Revisado: Noviembre de2011.

[31] John L. Hennessy and David A. Patterson.Computer Architecture A Quantitative Ap-proach. Morgan Kaufmann, 4th edition, 2006.

[32] Nallatech. http://www.nallatech.com/. Re-visado: Noviembre de 2011.

[33] Maxeler Technologies. http://www.maxeler.com. Revisado: Noviembre de 2011.

[34] DRC. http://www.drccomputer.com/. Revi-sado: Noviembre de 2011.

[35] Mercury Computer Systems. http://www.mc.com/. Revisado: Noviembre de 2011.

[36] Katherine Compton and Scott Hauck. Re-configurable computing: a survey of systemsand software. ACM Computing Surveys, 34(2):171–210, June 2002.

[37] Iouliia Skliarova and Valery Sklyrov. Re-cursion in reconfigurable computing : A sur-vey of implementation approaches. Field Pro-grammable Logic and Applications, 2009. FPL2009. International Conference on, pages 224–229, 2009.

[38] A. Gomperts, A. Ukil, and F. Zurfluh. De-velopment and implementation of paramete-rized fpga-based general purpose neural net-works for online applications. Industrial In-formatics, IEEE Transactions on, 7(1):78 –89,feb. 2011.

[39] Yongsoon Lee and Seok-Bum Ko. Fpga im-plementation of a face detector using neuralnetworks. In Electrical and Computer Engi-neering, 2006. CCECE ’06. Canadian Confe-rence on, pages 1914 –1917, may 2006.

[40] E.A. Zuraiqi, M. Joler, and C.G. Christodou-lou. Neural networks fpga controller for recon-figurable antennas. In Antennas and Propa-gation Society International Symposium (AP-SURSI), 2010 IEEE, pages 1 –4, july 2010.

[41] V. Gupta, K. Khare, and R.P. Singh. Fp-ga design and implementation issues of artifi-cial neural network based pid controllers. InAdvances in Recent Technologies in Commu-nication and Computing, 2009. ARTCom ’09.International Conference on, pages 860 –862,oct. 2009.

[42] K. Puttegowda, W. Worek, N. Pappas,A. Dandapani, P. Athanas, and A. Dicker-man. A run-time reconfigurable system forgene-sequence searching. In VLSI Design,2003. Proceedings. 16th International Confe-rence on, pages 561 – 566, jan. 2003.

[43] István a Bogdán, Jenny Rivers, Robert J Bey-non, and Daniel Coca. High-performance hard-ware implementation of a parallel databasesearch engine for real-time peptide mass finger-printing. Bioinformatics (Oxford, England),24(13):1498–502, July 2008.

[44] S. Baghel and R. Shaik. Fpga implementationof fast block lms adaptive filter using distribu-ted arithmetic for high throughput. In Com-munications and Signal Processing (ICCSP),2011 International Conference on, pages 443–447, feb. 2011.

[45] M. Rawski, P. Tomaszewicz, H. Selvaraj, andT. Luba. Efficient implementation of digitalfilters with use of advanced synthesis methodstargeted fpga architectures. In Digital Sys-tem Design, 2005. Proceedings. 8th EuromicroConference on, pages 460 – 466, aug.-3 sept.2005.

[46] Yuxi Wang and Yebing Shen. Optimized fp-ga realization of digital matched filter in spreadspectrum communication systems. Computerand Information Technology, IEEE 8th Inter-national Conference on, pages 173–176, 2008.

[47] Russel Tessier and Wayne Burleson. Reconfi-gurable Computing for Digital Signal Proces-sing A Survey. Journal of VLSI Signal Proces-sing, 28:7–27, 2001.

[48] Raymond Sinnappan and Scott Hazelhurst.A reconfigurable approach to packet filtering.


67

In Gordon Brebner and Roger Woods, edi-tors, Field-Programmable Logic and Applica-tions, volume 2147 of Lecture Notes in Com-puter Science, pages 638–642. Springer Berlin/ Heidelberg, 2001.

[49] Young H. Cho and William H. Mangione-Smith. Deep network packet filter design forreconfigurable devices. ACM Trans. Embed.Comput. Syst., 7:21:1–21:26, January 2008.

[50] Xiang Tian and K. Benkrid. Design and im-plementation of a high performance financialmonte-carlo simulation engine on an fpga su-percomputer. In ICECE Technology, 2008.FPT 2008. International Conference on, pa-ges 81 –88, dec. 2008.

[51] N.A. Woods and T. VanCourt. Fpga accele-ration of quasi-monte carlo in finance. In FieldProgrammable Logic and Applications, 2008.FPL 2008. International Conference on, pa-ges 335 –340, sept. 2008.

[52] Dehon André Hauck Scott. Reconfigurablecomputing. The theory and practice of FPGA-BASED computing. ELSEVIER - MorganKaufmann, 2008.

[53] Haohuan Fu, William Osborne, Robert G.Clapp, Oskar Mencer, and Wayne Luk. Accele-rating seismic computations using customizednumber representations on fpgas. EURASIP J.Embedded Syst., 2009:3:1–3:13, January 2009.

[54] EDA Industry Working Groups . http://www.vhdl.org/. Revisado: Octubre de 2011.

[55] Verilog Resources. http://www.verilog.com/. Revisado: Octubre de 2011.

[56] Xilinx. Vivado Design Suite.http://www.xilinx.com/products/design-tools/vivado/index.htm. Revi-sado: Octubre de 2012.

[57] Calypto. Catapult. http://calypto.com/products/catapult/overview. Revisado: Oc-tubre de 2012.

[58] C to Verilog: automating circuit design. http://www.c-to-verilog.com/. Revisado: Juniode 2011.

[59] Riverside Optimizing Compiler for Configu-rable Computing: Roccc 2.0. http://www.jacquardcomputing.com/roccc/. Revisado:Junio de 2011.

[60] Nios II C-to-Hardware Acceleration Compi-lern. http://www.altera.com/. Revisado: Ju-nio de 2011.

[61] Impulse Accelerate Technologies. Impul-se codeveloper c-to-fpga tools. http://www.jacquardcomputing.com/roccc/. Revisado:Agosto de 2011.

[62] Arcilio J Virginia, Yana D Yankova, and KoenL M Bertels. An empirical comparison ofANSI-C to VHDL compilers : Spark, Rocccand DWARV. In Anual Workshop on Circuits,Systems and Signal Processing (ProRISC),,pages 388–394, Veldhoven, Netherlands, 2007.

[63] Mitrionics. Languaje Mitrion-C. http://www.mitrionics.com/. Revisado: Agosto de 2011.

[64] Corporation Altera. Implementing FPGADesign with the OpenCL Standard. White Pa-per, (November):1–8, 2011. URL www.altera.com.

[65] Nirav Dave. A Unified Model for Hard-ware/Software Codesign. PhD thesis, MAS-SACHUSETTS INSTITUTE OF TECHNO-LOGY, 2011.

[66] Raúl Sánchez Fernández. Compilación C aVHDL de códigos de bucles con reuso de da-tos. Tesis, Universidad Politécnica de Catalu-ña, 2010.

[67] Yana Yankova, Koen Bertels, Stamatis Vassi-liadis, Roel Meeuws, and Arcilio Virginia. Au-tomated HDL Generation: Comparative Eva-luation. 2007 IEEE International Symposiumon Circuits and Systems, pages 2750–2753,May 2007.

[68] Philip Ioan Necsulescu. Automatic Gene-ration of Hardware for Custom Instructions.PhD thesis, Ottawa, Canada, 2011.

[69] Philip I Necsulescu and Voicu Groza. Au-tomatic Generation of VHDL Hardware Codefrom Data Flow Graphs. 6th IEEE Interna-tional Symposium on Applied ComputationalIntelligence and Informatics, pages 523–528,2011.

[70] Jeff Bier and Jennifer Eyre. BDTI StudyCertifies High-Level Synthesis Flows for DSP-Centric FPGA Designs. Xcell Journal Second,pages 12–17, Second Quarter 2010.

[71] General-purpose computation on graphicshardware. http://gpgpu.org/. Revisado Ma-yo de 2011.

[72] NVIDIA TESLA. GPU Computing revolutio-nizing High Performance Computing. http://sepwww.stanford.edu/. Revisado: Julio de2011.


68

[73] Andre R Brodtkorb, Christopher Dyken,Trond R Hagen, and Jon M Hjelmervik. State-of-the-art in heterogeneous computing. Scien-tific Programming, 18:1–33, 2010.

[74] John D. Owens, David Luebke, Naga Govin-daraju, Mark Harris, Jens Krüger, Aaron E.Lefohn, and Timothy J. Purcell. A Surveyof General-Purpose Computation on GraphicsHardware. Computer Graphics Forum, 26(1):80–113, March 2007.

[75] Jim Nilsson. An In-Depth Look at ComputerPerformance Growth Magnus Ekman FredrikWarg. Computer Performance, 2004.

[76] Wang Lei, Zhang Yunquan, Zhang Xianyi,and Liu Fangfang. Accelerating linpack per-formance with mixed precision algorithm oncpu+gpgpu heterogeneous cluster. In Pro-ceedings of the 2010 10th IEEE Internatio-nal Conference on Computer and InformationTechnology, CIT ’10, pages 1169–1174, Wa-shington, DC, USA, 2010. IEEE Computer So-ciety.

[77] Sergio Romero, Maria A. Trenas, Eladio Gu-tierrez, and Emilio L. Zapata. Locality-improved fft implementation on a graphics pro-cessor. In Proceedings of the 7th WSEAS In-ternational Conference on Signal Processing,Computational Geometry & Artificial Vision,ISCGAV’07, pages 58–63, Stevens Point, Wis-consin, USA, 2007. World Scientific and Engi-neering Academy and Society (WSEAS).

[78] Yang Su and Zhijie Xu. Parallel implementa-tion of wavelet-based image denoising on pro-grammable pc-grade graphics hardware. SignalProcess., 90:2396–2411, August 2010.

[79] J. Lobeiras, M. Amor, and R. Doallo. Fftimplementation on a streaming architecture.In Proceedings of the 2011 19th InternationalEuromicro Conference on Parallel, Distribu-ted and Network-Based Processing, PDP ’11,pages 119–126, Washington, DC, USA, 2011.IEEE Computer Society.

[80] Paulius Micikevicius. 3D Finite DifferenceComputation on GPUs using CUDA 2701 SanTomas Expressway. Cell, pages 0–5, 2009.

[81] Ludovic Jacquin, Vincent Roca, Jean-LouisRoch, and Mohamed Al Ali. Parallel arithme-tic encryption for high-bandwidth communica-tions on multicore/gpgpu platforms. In Pro-ceedings of the 4th International Workshop onParallel and Symbolic Computation, PASCO’10, pages 73–79, New York, NY, USA, 2010.ACM.

[82] Shrinidhi Hudli, Shrihari Hudli, Raghu Hud-li, Yashonath Subramanian, and T. S. Mohan.Gpgpu-based parallel computation: applica-tion to molecular dynamics problems. In Pro-ceedings of the Fourth Annual ACM BangaloreConference, COMPUTE ’11, pages 10:1–10:8,New York, NY, USA, 2011. ACM.

[83] The Industry’s Foundation for High Perfor-mance Graphics. http://www.opengl.org/.Revisado: Octubre de 2011.

[84] AMD. http://www.amd.com/. Revisado:Agosto de 2011.

[85] What is CUDA. http://developer.nvidia.com/. Revisado: Julio de 2011.

[86] OpenCL - The open standard for parallel pro-gramming of heterogeneous systems. http://www.khronos.org/opencl/. Revisado: Agos-to de 2011.

[87] DirectCompute para NVIDIA. http://developer.nvidia.com/directcompute. Revi-sado: Agosto de 2011.

[88] Ray Andraka. A survey of cordic algorithmsfor fpga based computers. In Proceedings of the1998 ACM/SIGDA sixth international sympo-sium on Field programmable gate arrays, FP-GA ’98, pages 191–200, New York, NY, USA,1998. ACM.

[89] Chuan He, Wei Zhao, and Mi Lu. Time do-main numerical simulation for transient wa-ves on reconfigurable coprocessor platform. InProceedings of the 13th Annual IEEE Sympo-sium on Field-Programmable Custom Compu-ting Machines, pages 127–136. IEEE Compu-ter Society, 2005.

[90] Oliver Pell and Robert G. Clapp. Accelera-ting subsurface offset gathers for 3d seismic ap-plications using fpgas. SEG Technical ProgramExpanded Abstracts, 26(1):2383–2387, 2007.

[91] Maxeler: Complete Acceleration Solutions.http://www.maxeler.com/content/solutions/. Revisado: Noviembre de 2011.

[92] Haohuan Fu, William Osborne, Robert GClapp, and Oliver Pell. Accelerating SeismicComputations on FPGAs From the Perspec-tive of Number Representations. 70th EAGEConference & Exhibition, (June 2008):9 – 12,2008.

[93] Dong-U Lee, Altaf Abdul Gaffar, Oskar Men-cer, andWayne Luk. Optimizing hardware fun-ction evaluation. IEEE Trans. Comput., 54:1520–1531, December 2005.


69

[94] Daniel Haugen. Seismic Data Compressionand GPU Memory Latency. Master thesis,Norwegian University of Science and Techno-logy, 2009.

[95] Tage Rosten, Tor A. Ramstad, and Lasse

Amundsen. Optimization of sub-band codingmethod for seismic data compression. Geophy-sical Prospecting, 52(5):359–378, 2004.


70

Capítulo 3 Architecture and Designs of Systems-On-Chip

Capítulo 3-Architecture and Designs of Systems-On-Chip Implementación de un sistema de reconocimiento de señales de tráfico en tiempo real mediante visión artificial basado en FPGA Nicolás Aguirre Dobernack (Universidad de Sevilla, Spain), Hipólito Guzmán Mirand (Universidad de Sevilla), Miguel Ángel Aguirre Echánove (Universidad de Sevilla) FPGA Acceleration of Semantic Tree Reasoning Algorithms Jesus Barba (Universidad de Castilla-La Mancha, Spain), Maria José Santofimia (Universidad de Castilla-La Mancha), David de la Fuente (Universidad de Castilla-La Mancha), Julio Dondo (University of Castilla-La Mancha), Fernando Rincon (University of Castilla-La Mancha), Julian Caba (Universidad de Castilla-La Mancha) Trabajo de desarrollo de un Sensor Multivista basado en microcámaras de bajo coste David Hernández Expósito (La Laguna University, Spain), Manuel Rodríguez Valido (Universidad de La Laguna), Eduardo Magdaleno Castelló (Universidad de La Laguna), Fernando Pérez Nava (Universidad de La Laguna)

Implementación de un sistema de reconocimiento de señales de tráfico en tiempo real mediante visión artificial basado en FPGA

Nicolás Aguirre Dobernack, Hipólito Guzmán Miranda, Miguel A. Aguirre Echánove


Departamento de Ingeniería Electrónica. Universidad Sevilla.

Resumen

El reconocimiento de señales de tráfico en tiempo

real ha sido objeto de estudio durante los últimos

años, debido a su importancia en los sistemas de

asistencia al conductor (DSS, Driver Support

Systems). El objetivo de este trabajo es presentar

la implementación de un sistema completo de

reconocimiento de señales de tráfico en FPGA. El

sistema final trabaja a 60 fotogramas por segundo

con una resolución de 1280x720 píxeles, siendo

capaz de identificar hasta 8 señales simultáneas en

un mismo fotograma.

1. Introducción

Los sistemas de reconocimiento de señales de

tráfico (TSR, Traffic Sign Recognition) han

demostrado ser un avance importante en el campo

de la seguridad vial. Así mismo, sus usos también

se extienden a otros ámbitos como los vehículos

no tripulados o con fines de inventariado.

A pesar de sus múltiples aplicaciones, el

reconocimiento de señales de tráfico es una tarea

que presenta múltiples dificultades debido a las

condiciones externas incontrolables, como el

tiempo, dirección e intensidad de la luz, sombras,

oclusiones parciales o la presencia de otros

objetos similares en la escena [3]. Existen también

otras dificultades inherentes a las propias señales,

como la gran cantidad de señales viales existentes,

muchas de ellas muy similares unas a otras, la

perspectiva de aparición de la señal, que puede

estar rotada, escalada o con distorsión de

perspectiva, o la señalización por paneles LED,

que requieren un tratamiento totalmente diferente.

Superar estos obstáculos y ofrecer una solución

robusta, efectiva y en tiempo real es uno de los

retos más desafiantes en la actualidad.

A pesar de que la mayoría de trabajos

propuestos con respecto al TSR están basados en

software, recientemente ha habido un incremento

de interés en las soluciones hardware. La

complejidad de la cadena de procesado obliga a

los sistemas basados en software a trabajar en

procesadores de gran capacidad de computación y

muy altas frecuencias, resultando en sistemas

caros, de alto consumo y difíciles de implementar

en dispositivos portátiles. Por ello se hacen

presentes los beneficios de las soluciones basadas

en FPGA: procesamiento masivamente paralelo,

descripción de arquitecturas específicas para

optimizar algún algoritmo, capacidad para

resolver tareas complejas en pocos ciclos de reloj,

y la posibilidad de ofrecer una solución integrada

en un chip (SoC, System on a Chip), reduciendo la

complejidad y el tamaño de la PCB [2].

El sistema propuesto, que hace gala de las

características anteriormente mencionadas, ha sido

implementado en una FPGA de la familia Spartan-

6. Un flujo de vídeo de alta resolución es

adquirido desde una cámara. Seguidamente, se

utiliza un método de segmentación por color con

umbrales configurables por el usuario, para

obtener una imagen binaria con los píxeles de

interés. Posteriormente, se aplica sobre la imagen

una etapa de filtrado y operaciones morfológicas

para eliminar el ruido de segmentación, antes de

ser procesado por una etapa de etiquetado de

componentes conectados, que identificará las

regiones de interés (ROI, Regions of interest).

Finalmente, cada una de las ROIs es analizada en

paralelo, utilizando un método de clasificación

basado en el color, la forma y el pictograma de la

señal vial. También se han implementado otros

módulos para mostrar información en pantalla o


73

para proporcionar coherencia de identificación

entre fotogramas consecutivos.

2. Trabajos relacionados

Generalmente el proceso de reconocimiento se

divide en dos etapas: detección y clasificación. En

la primera de ellas, la imagen es analizada para

identificar las ROIs, usando o bien la información

de color [1], o un análisis de formas [8], seguido

de un algoritmo de etiquetado de componentes

conectados para identificar las zonas de interés. El

espacio de color RGB, que es conocido por ser

ineficiente debido a su alto grado de dependencia

con las condiciones de luz, es también utilizado

por ser sencillo en su tratamiento [1]. Otros

espacios de color como el HSI son más eficientes

en la etapa de segmentación, aunque resulta

computacionalmente más costoso. Para la etapa de

clasificación, existen numerosos métodos

descritos a lo largo de los años, como la

comparación con plantillas [11], máquinas de

vectores de soporte [5], lógica difusa [10] o redes

neuronales [6].

Finalmente, a pesar de que actualmente

existen pocos trabajos sobre sistemas TSR en

FPGA, la mayoría de ellos concuerdan en su

flexibilidad, eficiencia y bajo coste. [7] utiliza un

sistema integrado, con una parte hardware para

acelerar las partes críticas y una parte software

corriendo en un sistema multi-core con RTOS. [8]

implementa en una FPGA un sistema para

reconocer señales circulares basándose en las

propiedades de color y forma. Por último [9]

implementa un sistema para identificar la señal de

Stop de una manera eficiente y robusta.

3. Enfoque propuesto

La Fig. 1 muestra el módulo principal del sistema

implementado. El objetivo de esta arquitectura es

proporcionar flexibilidad en la implementación

final, siendo posible la integración en un sistema

mayor (como periférico controlado por un

procesador soft-core), o como módulo stand-

alone. Todos los parámetros del sistema, como los

umbrales, modos de operación y depuración, etc,

pueden ser leídos y configurados usando un

sistema embebido o a través de acceso remoto.

Figura 1. Sistema TSR propuesto

Además, el sistema implementado dispone de una

salida auxiliar de vídeo que puede ser configurada

para observar en tiempo real el proceso de

segmentación y la extracción de las ROIs.

Una de las características más destacadas de

los sistemas basados en hardware es que, aunque

puede existir un microprocesador en el sistema,

éste se utiliza para fines de lectura y escritura de

los registros de control, dejando toda la carga de

procesamiento a los módulos hardware, evitando

cuellos de botella en el microprocesador [2].

4. Modelo de trabajo

Para facilitar la implementación de los

diferentes módulos que componen el sistema TSR,

se ha adoptado un flujo de trabajo orientado al

diseño y prototipado rápido (Fig. 2). Cada módulo

es previamente modelado en Matlab utilizando

una base de datos de imágenes de prueba,

optimizando las tareas de testeado y verificación.

El diseñador debe tener en cuenta que la entrada al

sistema es un flujo de vídeo y por tanto no es

posible el acceso aleatorio a cualquier píxel,

aunque gracias a elementos como los buffers de

línea, se puede crear un contexto de vecindades

para la aplicación de máscaras de filtrado. Una

vez conforme con el modelo en Matlab, el

diseñador utiliza bloques predefinidos para

implementar el módulo en hardware, a partir de

una librería de primitivas que contiene elementos

como buffers de línea, retrasos, filtros,

operaciones con matrices, RAMs y ROMs de uno

o dos puertos, etc.. De esta forma se simplifica la

implementación en hardware, conectando bloques

y reutilizando primitivas. Como ejemplo, la Fig. 4

muestra cómo se pueden implementar diferentes

tipos de filtros de convolución reutilizando las

mismas primitivas.

Las primitivas de la librería han sido descritas

utilizando VHDL, usando inferencia para que la

Capítulo 3: Architecture and Designs of Systems-On-Chip

74

herramienta de síntesis utilice recursos específicos

de la FPGA, como las memorias BRAM.

Figura 2. Flujo de diseño para prototipado rápido.

Este método permite tener un mayor control a

bajo nivel de la implementación, así como una

mayor portabilidad del sistema entre familias y

dispositivos FPGA. Otra ventaja es la simplicidad

del flujo de diseño, que evita el uso de otras

herramientas de generación de código, con el

consiguiente problema de integración, o

migración a FPGAs de otras compañías.

5. Arquitectura detallada

5.1. Diagrama general

La Fig. 3 muestra la arquitectura interna del

sistema TSR. En un primer paso, el vídeo de

entrada es divido y llevado al generador de

coordenadas, así como a los módulos de

segmentación, clasificación y el generador de

capas de información en pantalla. Los bloques de

segmentación, filtrado, etiquetado y clasificación

conforman la cadena de procesamiento principal.

El módulo que genera la información de salida

puede ser configurado para mostrar el vídeo

original (modo bypass) o el vídeo procesado

donde se superponen varias capas de información

con los bounding boxes, carteles, etc. Todos los

caracteres mostrados por pantalla están

almacenados en una ROM utilizando un bit por

píxel. Finalmente, el bloque de coherencia realiza

un seguimiento de la identificación en fotogramas

previos, y detecta errores que pueden darse en

fotogramas específicos.

Los bloques que conforman la Fig. 3 serán

explicados en detalle en los sucesivos apartados.

5.2. Segmentación basada en color

La segmentación por umbral de color es la

primera etapa de la cadena de procesado, e

implica identificar los píxeles rojos y azules en el

fotograma. Esta tarea es la más problemática de

todo el sistema debido a su dependencia con los

factores externos de la escena. Las condiciones de

iluminación, posición del sol o las sombras

parciales afectan de manera incontrolada a los

colores de la imagen. Adicionalmente, el espacio

de color RGB es conocido por ser

extremadamente dependiente de estos factores

mencionados anteriormente. Otros espacios de

color como el HSI resultan más robustos, debido a

su capacidad para separar las componentes de luz,

saturación y tono. Sin embargo, su complejidad

computacional, sobre todo con el uso de

operaciones trigonométricas para convertir de

RGB a HSI, hace que muchos estudios estén

basados en el espacio RGB debido a su sencillez

en el tratamiento.

Figura 3. Arquitectura interna del sistema TSR.

En este estudio se ha utilizado el espacio de color

RGB por estos motivos. Para mayor robustez ante

los cambios de luz, se ha implementado un umbral

configurable en tiempo real, que proporciona un

mayor control sobre esta etapa.

Después de un exhaustivo estudio de los

métodos publicados a lo largo de los años, se han

propuesto las siguientes expresiones para la

segmentación del color rojo (1), (2):


75

El color azul es segmentado según (3) y (4).

Los valores k1 y k2 proporcionan un control

preciso de la ganancia de rojo y azul en la escena.

Nótese que, aunque k2 es utilizado para reducir la

componente de rojo del píxel, el objetivo de este

valor es proporcionar un incremento efectivo de la

ganancia de azul y verde. Esto se debe a que en el

mundo real, los objetos azules suelen venir

acompañados de una cantidad no despreciable de

la componente verde, que debe tomarse en

consideración. El sistema también tiene control

sobre el mínimo valor de rojo (2) para evitar que

los píxeles cercanos al negro sean interpretados

como rojos, así como un offset (4) que controla la

dependencia entre las componentes azul y verde.

La salida del módulo de segmentación es un

flujo de vídeo binario cuyos píxeles de interés son

"1" si satisfacen (2) o (4), y "0" en caso contrario.

5.3. Filtrado y operaciones morfológicas

Antes de llevar el vídeo binario a la siguiente

etapa, se acondiciona a través de los módulos de

filtrado y operaciones morfológicas, con el

objetivo de limpiar la imagen de ruido y

proporcionar una mayor calidad de los objetos de

interés. Primeramente, se aplica un filtrado de

Mediana 3x3, para eliminar el ruido de

segmentación del fotograma. Seguidamente se

aplican en cascada sendos filtros de erosión y

dilatación que eliminan las agrupaciones de

píxeles demasiado pequeñas como para resultar de

interés. Estos tres módulos han sido

implementados utilizando diagramas de bloques

similares (Fig. 4).

En la lógica decisora del filtro mediana, el

píxel de salida valdrá "1" si al menos la mitad de

los píxeles vecinos valen "1". En caso contrario la

salida será "0". Los filtros de erosión y dilatación

eliminan y añaden píxeles de los bordes de cada

objeto, dejando los objetos grandes intactos y

eliminando de esta forma los objetos pequeños en

el fotograma.

Figura 4. Estructura de las operaciones de filtrado.

Figura 5. Segmentación, mediana, erosión y dilatación.

5.4. Etiquetado de componentes conectados

Después del filtrado, el sistema realiza un

etiquetado de componentes conectados (CCL,

Connected Components Labeling), para extraer

los diferentes objetos y regiones de interés de la

escena. El algoritmo asigna identificadores únicos

a cada objeto aislado, al mismo tiempo que

obtiene sus características de interés, como las

coordenadas superior izquierda e inferior derecha.

Este método ha sido implementado basándose en

el trabajo de Johnston C. T. y Bailey D. G. [4].

El método clásico para ejecutar este algoritmo

requiere realizar dos pasadas por el fotograma

para etiquetar los objetos. Generalmente el

segundo pase recorre la imagen completa en orden

inverso. Este método no es adecuado cuando se

trabaja con un flujo de vídeo sobre FPGA, ya que

se haría necesario tener un frame buffer. Por lo

tanto se ha optado por un algoritmo de un solo

pase [4], el cual almacena las características de

interés de los objetos al tiempo que asigna

etiquetas provisionales.

En primer lugar, el píxel de entrada es

analizado junto a sus vecinos, los cuales han sido

previamente procesados (Fig. 6).


76

Figura 6. Máscara de asignación de etiquetas.

Para proporcionar el contexto de vecindades se

han utilizado 5 flip-flops y un buffer de línea. El

funcionamiento básico del algoritmo puede ser

expresado como sigue:

• Si el píxel de entrada es "0", se aplica la

etiqueta de fondo.

• Si el píxel de entrada es "1" y todos los

vecinos son de fondo, se asigna una nueva

etiqueta.

• Si el píxel de entrada es "1" y todos los

vecinos distintos de fondo tienen la misma

etiqueta, ésta etiqueta es asignada.

• Si el píxel de entrada es "1" y existen

diferentes etiquetas en los vecinos, se produce

una equivalencia que se almacena en

memoria, y la etiqueta menor es asignada.

Mientras se ejecutan estas tareas, el algoritmo

accede a una memoria RAM de doble puerto

almacenando en tiempo real las coordenadas de

los objetos que serán utilizadas como ROIs. La

RAM refleja el estado actual de cada objeto a

medida que el fotograma es analizado. Nótese que

es posible tener asignadas varias etiquetas

diferentes para un único objeto, debido a cómo se

transmite el flujo de vídeo. Por ello, al final del

primer pase la información almacenada en la

RAM de cada etiqueta reflejará una información

incompleta acerca del objeto que identifica, y será

necesario recorrer la tabla para fusionar todas las

características de las etiquetas equivalentes. Esta

fusión vuelca la información de interés en

etiquetas equivalentes, consiguiendo obtener la

ROI completa del objeto (Fig. 7). Este volcado de

información se realiza antes de la llegada del

siguiente fotograma, en el espacio de blanking

vertical, donde se inicia una máquina de estados

finitos, que recorre la tabla en orden inverso,

debido a que las etiquetas mayores apuntarán a

sus equivalentes menores.

Finalmente, se analizan las ROIs detectadas,

descartando aquellas que tengan un tamaño

inferior a 30x30 píxeles, o cuya proporción

alto/ancho sea mayor que 2 o menor que 0.5.

Figura 7. Múltiples etiquetas en un mismo objeto.

5.5. Clasificación de la señal vial

La última etapa encargada de la clasificación de la

señal vial se realiza en tres pasos. En primer lugar,

tras recibir las ROIs de la etapa previa, se realiza

un análisis de color en cada una de ellas con el

objetivo de detectar el color de la señal. Para ello,

es necesario implementar un sistema que elimine

los píxeles de fondo y sólo tenga en cuenta

aquellos que son interiores a la señal vial. Esto

evita que los píxeles de fondo puedan influir en el

análisis de color. En segundo lugar, se realiza un

análisis de la forma de la señal. Este método es

capaz de detectar formas triangulares,

rectangulares, circulares u octogonales, incluso si

aparecen rotadas, escaladas o con distorsión de

perspectiva. Por ello, no es necesario implementar

un método de alineamiento de los ejes de la señal

con respecto a los de la ROI. Finalmente, se

analiza el pictograma de la señal dividiendo la

zona central de la ROI en cuatro partes y

analizando el porcentaje de píxeles informativos

de cada zona (IPP, Informative Pixel Percentage).

Estos valores son comparados con una base de

datos numéricos almacenada en una ROM,

utilizando la suma de la diferencia absoluta (SAD,

Sum of Absolute Difference). Aquel valor que

minimice el SAD será el candidato más probable.

Estos pasos se ilustran en la Fig. 8.

Para la clasificación por color se han utilizado

señales rojas y azules, siendo posible la detección

de otras señales modificando el bloque de

segmentación. El color blanco o el negro también

pueden formar parte de la señal, así como una

combinación de cualquiera de ellos. En esta etapa

se realiza una segunda segmentación local,

aplicada a cada ROI.


77

Figura 8. La clasificación es realizada en tres pasos.

Para ello, un análisis previo de cada línea

informará qué píxeles son interiores a la señal y

cuales pertenecen al fondo. Este análisis previo se

realiza línea por línea usando una máscara de

vecinos, y operando bajo la suposición de que una

señal comienza con un número de píxeles rojos (o

azules) seguido de cualquiera de los colores

permitidos, ya mencionados. El resultado de este

análisis previo servirá para una posterior

segmentación de dicha línea, que sólo se realizará

en los píxeles interiores a la señal. Cabe destacar

que, una vez identificado el interior de una señal,

las expresiones para la segmentación pueden

relajarse, sobre todo para el color blanco y el

negro, ya que no es posible encontrar otros colores

dentro de la misma. El análisis previo y la

segmentación se realizan al mismo tiempo gracias

al uso de un buffer de línea. Finalmente, gracias a

varios contadores de color, el sistema identifica

las proporciones de color de la señal.

El segundo paso en este módulo es el análisis

de la forma de la señal. El método implementado

en este paso fue originalmente diseñado para

realizar un análisis de forma previo que descarte

ROIs sin interés, antes de un análisis de formas

más robusto. Sin embargo se ha comprobado que

el método funciona bien como stand-alone, ya que

las formas de las señales viales son simples. Para

realizar este análisis, se utilizan 12 descriptores de

borde, cada uno de los cuales contiene la distancia

existente entre el borde de la ROI y el comienzo

de la señal (Fig. 9). Dichos descriptores están

colocados de tal forma que dividen la ROI en 16

partes iguales, y son implementados utilizando

contadores síncronos. Para determinar la relación

entre estos descriptores y la forma de la señal,

incluso cuando ésta aparece rotada, escalada o con

distorsión de perspectiva, se ha realizado un

estudio heurístico, que ha sido puesto a prueba

utilizando modelos de Matlab. Este estudio dio

como resultado expresiones útiles que relacionan

los descriptores Li, Ri, Ti, Bi, así como el área

ocupada por la señal con respecto a su ROI.

Figura 9. Los descriptores almacenan la distancia entre

el borde de la ROI y la señal.

Finalmente, gracias a la evaluación de estas

expresiones, el sistema es capaz de determinar si

la señal es rectangular, triangular, circular,

octogonal, o no existe una señal dentro de la ROI.

Finalmente, el sistema analiza el pictograma

de la señal, utilizando las cuatro zonas centrales

calculadas en el paso previo para hallar las IPPs

de cada una de ellas (Fig. 8). En primer lugar, se

decide si la información útil la dan los píxeles

negros (e.g. señales de límite de velocidad) o los

píxeles blancos (e.g. señal de dirección

obligatoria). Seguidamente se calcula la

proporción de estos píxeles con respecto al total

de cada zona. Finalmente, se comparan estos

resultados con una base de datos modelada en

Matlab, utilizando el método SAD para hallar la

coincidencia más probable. Para que el sistema

sea flexible ante la rotación y el escalado de la

señal, la base de datos contiene 8 grupos de IPPs

por cada una de las señales a reconocer. Estos

valores corresponden con rotaciones de la señal

desde -60º a 45º en incrementos de 15º. De esta

forma, el pictograma puede ser identificado

correctamente aunque la señal esté rotada.

Finalmente, es necesario destacar dos cosas en

la etapa de clasificación. En primer lugar, la base

de datos del sistema sólo almacena valores

numéricos, y no plantillas de imágenes de ningún

tipo. En segundo lugar, modificar el sistema para

que reconozca otros tipos de señales es tan

sencillo como guardar su información de color,

forma y sus IPPs. Esto proporciona al sistema

flexibilidad ante nuevas señales de tráfico.


78

5.6. Otros módulos

El sistema TSR contiene otros módulos que

forman parte de la solución completa e integral.

En particular, el módulo generador de vídeo será

capaz de añadir capas de información en pantalla

con los bounding boxes y texto. Adicionalmente,

el módulo de coherencia entre fotogramas prevé

cambios bruscos en el tiempo. Este último módulo

basa su funcionamiento en la filosofía "Si el

nuevo fotograma proporciona más información

sobre la señal, el cambio se refleja

inmediatamente. En otro caso, el cambio debe

permanecer en el tiempo para ser aceptado".

Finalmente, se ha implementado un generador de

patrones binarios para tareas de depuración.

6. Resultados y conclusiones

El sistema TSR ha sido implementado en una

FPGA de la familia Spartan-6, utilizando un

proyecto embebido con un procesador Microblaze

para controlar y configurar los registros del

sistema TSR. Se ha comprobado su

funcionamiento a 60 fotogramas por segundo con

una resolución de video de 1280x720 píxeles. El

esfuerzo total de desarrollo de este sistema de

visión se ha calculado en 6 personas-mes

aproximadamente.

Para evaluar el sistema, se han utilizado 16

tipos de señales de diferentes colores, formas y

pictogramas, con buenos resultados en muchos

tipos de situaciones, incluyendo cambios de

distancia, rotación y perspectiva. A pesar de que

el sistema ha sido capaz de reconocer todas las

señales, en algunos casos se han detectado

problemas que dificultan la identificación en

ciertos ángulos de perspectiva debido a las

componentes inconexas de algunas señales (Fig.

10). Así mismo, existen restricciones conocidas

con respecto a las condiciones de luz, dadas por el

espacio de color utilizado. Finalmente, aunque el

análisis de formas funciona correctamente, se

prevén dificultades en entornos urbanos o

situaciones donde existan objetos de similares

características a las señales viales.

La frecuencia de operación del sistema

impuesta por la lógica es de 77.64 MHz, que

resulta más que suficiente para trabajar con la

resolución de vídeo mencionada antes (cuya

frecuencia de píxel es de 74.25 MHz).

MODELO SPARTAN-6 XC6SLX150T

Flip-

Flops LUTs

Elementos

de memoria Slices

22049

11%

37110

40%

4909

22%

13177

57%

Tabla 1. Recursos utilizados en la FPGA

Figura 10. Algunas señales de tráfico han resultado

problemáticas debido a sus partes

inconexas.

7. Trabajos futuros

Entre otras líneas de trabajo futuro, están las de

implementar un sistema de control automático

para el ajuste de los umbrales en la segmentación

por color. Esto mejoraría considerablemente la

eficiencia del sistema bajo diferentes condiciones

de luz.

Otra mejora podría implementar un módulo

para pasar del espacio de color RGB al HSI,

debido a su robustez frente a las condiciones de

luz. A pesar de que la transformación del espacio

RGB al HSI requiere de cierta complejidad

computacional, es posible crear bloques que

trabajen bajo ciertas aproximaciones en el

tratamiento matemático de esta transformación,

haciendo más sencilla su implementación e

incorporación al sistema total, haciendo más

robusta la segmentación por color al dejar de

depender de las condiciones de luz de la escena.

Así mismo, el sistema mejoraría su

funcionamiento con una etapa de análisis de

formas más robusta, basada en la transformada de

Hough, o en el histograma de gradientes

orientados (HoG, Histogram of oriented

Gradients).

Finalmente, para permitir al sistema detectar

un número alto de señales de tráfico, el método de

reconocimiento del pictograma basado en IPPs

debería extenderse, para conseguir una mejor

discriminación entre pictogramas.


79

Figura 11. El sistema puesto a prueba con maquetas de

señales reales.

8. Agradecimientos

Los autores desean agradecer al Ministerio de

Educación español y el Fondo Europeo de

Desarrollo Regional por financiar el Proyecto

RENASER ("Efectos de Radiación en Sistemas

Aeroespaciales, Investigación Sobre emulación",

código ESP2007-65914-C03-03), que ha

facilitado el Kit de desarrollo y la FPGA que se ha

usado en el prototipado del sistema de

reconocimiento de señales de tráfico.

Referencias

[1] Buluswar, S.D.; Draper, B.A., "Color

recognition in outdoor images," Computer

Vision, 1998. Sixth International Conference

on , vol., no., pp.171,177, 4-7 Jan 1998

[2] Guzman-Miranda, H. ; Napoles, J. ; Patio, A. ;

Mateos, R. ; Matias, M. ; Amador, J. ; Tombs,

J. ; Aguirre, M.A. ; Perez-Cordoba, J.,

“Realization of a flexible platform for fruit

inspection and classification applications with

emphasis in rapid prototyping and

development”, Industrial Electronics, 2009.

IECON '09. 35th Annual Conference of IEEE

, vol., no., pp.2874,2879, 3-5 Nov. 2009

[3] H.-M. Yang, C.-L. Liu, K.-H. Liu, and S.-M.

Huang, "Traffic sign recognition in disturbing

environments", Proceedings of the 14th

International Symposium on Methodologies

for Intelligent Systems (ISMIS '03), vol. 2871

of Lecture Notes in Computer Science, pp.

252–261, Maebashi City, Japan, October 2003

[4] Johnston, C.T.; Bailey, D.G., "FPGA

implementation of a Single Pass Connected

Components Algorithm," Electronic Design,

Test and Applications, 2008. DELTA 2008.

4th IEEE International Symposium on , vol.,

no., pp.228,231, 23-25 Jan. 2008.

[5] Junyoung Park; Joonsoo Kwon; Jinwook Oh;

Seungjin Lee; Joo-Young Kim; Hoi-Jun Yoo,

"A 92-mW Real-Time Traffic Sign

Recognition System With Robust Illumination

Adaptation and Support Vector

Machine," Solid-State Circuits, IEEE Journal

of , vol.47, no.11, pp.2711,2723, Nov. 2012

[6] Luo, R.C.; Potlapalli, H.; Hislop, D., "Traffic

sign recognition in outdoor environments

using reconfigurable neural networks," Neural

Networks, 1993. IJCNN '93-Nagoya.

Proceedings of 1993 International Joint

Conference on , vol.2, no., pp.1306,1309

vol.2, 25-29 Oct. 1993

[7] Müller, M.; Braun, A.; Gerlach, J.; Rosenstiel,

W.; Nienhuser, D.; Zollner, J.M.; Bringmann,

O., "Design of an automotive traffic sign

recognition system targeting a multi-core SoC

implementation," Design, Automation & Test

in Europe Conference & Exhibition (DATE),

2010 , vol., no., pp.532,537, 8-12 March 2010

[8] Souki, M.A.; Boussaid, L.; Abid, M., "An

embedded system for real-time traffic sign

recognizing," Design and Test Workshop,

2008. IDT 2008. 3rd International , vol., no.,

pp.273,276, 20-22 Dec. 2008

[9] Tam Phuong Cao; Guang Deng, "Real-Time

Vision-Based Stop Sign Detection System on

FPGA," Digital Image Computing:

Techniques and Applications (DICTA), 2008 ,

vol., no., pp.465,471, 1-3 Dec. 2008

[10] Wanitchai, P.; Phiphobmongkol, S., "Traffic

Warning Signs Detection and Recognition

Based on Fuzzy Logic and Chain Code

Analysis," Intelligent Information Technology

Application, 2008. IITA '08. Second

International Symposium on , vol.3, no.,

pp.508,512, 20-22 Dec. 2008

[11] Xu, S., "Robust traffic sign shape recognition

using geometric matching," Intelligent

Transport Systems, IET , vol.3, no.1,

pp.10,18, March 2009


80

FPGA Acceleration of Semantic Tree

Reasoning Algorithms

Jesús Barba(1)

, Maria José Santofimia(1)

, David de la Fuente(1)

, Julio Dondo(1)

, Fernando

Rincon(1)

, Julián Caba(1)

, [email protected], [email protected], [email protected], [email protected],

[email protected], [email protected] (1) Escuela Superior de Informática. Universidad de Castilla-La Mancha, Ciudad Real.

Abstract—Data structures, and the algorithms

to handle them, represent the foundation of many

software applications. Normally, its

implementation involves the use of dynamic

references (pointers) to memory regions in which

part of the information is stored. Such dynamic

artifacts, present in the software domain, do not

suit quite straight in the hardware domain if a

silicon realization of these dynamic data

structures is planned. Therefore, many

application domains cannot benefit from the use

of specialized hardware implementing data

structures such as lists, graphs or trees. In this

paper, the design of a hardware unit to accelerate

semantic tree operations for common-sense

reasoning applications is presented. The

optimized micro-architecture together with a

smart data mapping strategy allows our solution

to achieve a significant reduction in execution

times of marker-parser algorithms. The design

has been prototyped on a Xilinx ML507 board

and compared to an equivalent software

implementation.

Index Terms—Tree data structures,

accelerator architectures, reconfigurable logic,

artificial intelligence.

1. Introduction

The use of complex data structures is almost

unavoidable when implementing computer

compatible algorithms to face real world

problems. These artifacts support software

developers in modeling the key concepts of the

domain problem. In this sense, the mental

process of abstracting real world into data

structures is determinant in the success and

efficiency achieved by the developed software

algorithms. Software domain already counts on

consolidated ways of implementing an important

number of data type structures: maps, lists, trees,

arrays, etc. These structures implement a

predefined strategy to organize data in memory.

Routines running in the processor can therefore

easily retrieve and interpret the data. In general,

the manipulation of these data structures is costly

in terms of latency due to many factors. For

example, pointers are usually present as special

variables storing references to memory. On the

one hand, pointers enable the implementation of

indexed and indirect addressing modes which are

of great utility in complex data structures.

Moreover, pointers support dynamic growth of

program variables, for example adding new node

elements to a list structure. On the other hand,

pointers generate irregular data access patterns

which spoil cache locality benefits.

Speeding up the manipulation of complex

data structure is one of the challenging issues

facing the pursuit of more efficient mechanisms.

Despite the simplicity of their data structure,

designs of the stack and FIFO components with

an execution speed of one cycle per operation has


81

mailto:[email protected],%[email protected]

mailto:[email protected]




succeeded in this endeavor. However, the design

of circuits for dynamic data types is not

straightforward due to the static nature of the

silicon.

In this sense, representative example of

complex data structure is that of trees. A tree is a

collection of nodes hierarchically arranged, in

which each node points to the next level nodes.

An extension of this basic approach is the

semantic tree, widely used in the representation

and modeling of knowledge in the Artificial

Intelligence field. Inference or reasoning

processes use algorithms that basically go through

the semantic tree in order to select the node or

nodes that match the search premises.

In this paper, we present the design of a

hardware component to accelerate reasoning

operations on semantic trees. The algorithm under

consideration is the marker-parser strategy

proposed for the Scone Knowledge-Based system

[1] which shows excellent results in minimizing

the time employed in search and inference tasks.

The implementation has been performed using a

Xilinx ML507 prototyping board, with a Virtex-5

LX110T FPGA (Field Programmable Gate

Array) chip. The process does not only imply the

design of the microarchitecture but also the study

of the memory technology available in the FPGA

in order to optimize the memory organization.

Also, a keen representation in memory of the

semantic network is provided contributing to

achieving the efficiency goal.

The remainder of this paper is organized as

follows. Section 2 contains previous work

regarding hardware implementations of

algorithms related to complex data structures.

Section 3 describes the marker-passer algorithm

and the reasoning process based on the use of

semantic trees. A description of our architecture

and the design decisions taken to accelerate the

marker-parser computation are given in Section

4. Section 5 contains implementation results,

finishing the article with a summary of the

benefits and future work in Section 6.

2. Related Work

In the first place, this section presents a selection

of works for performing ad-hoc implementation

of complex data structure.

Please, notice that the use of decision trees is

broadly used as a way of supporting a variety of

tasks such as classification, decision taking

processes, optimization and many others.

In [2], Decision Tree (DT) classification for

data mining support is improved my means of a

hardware computation kernel that speeds up the

most demanded operations of the algorithms.

Single oblique or nonlinear decision trees are the

subject of a more generic approach developed by

Struharik in [2]. Robotics and image processing

are some of the embedded applications that

benefits from the reduction in time of the

adaptive learning process. Both, [2] and [2] use

FPGA-based reconfigurable computing for their

designs. The main strength of FPGA devices

consists in their ability to support flexible and

scalable designs, even performed at run time.

However, such interesting feature is not exploited

in these proposals.

Although FPGAs also offer close to ad-hoc

hardware acceleration times, without incurring

the expenses of tailored architectures, some other

proposals combine silicon and highly optimized

VLSI circuits [4][5]. The reader can find in [4]

an interesting job regarding a VLSI design for

hardware friendly gas identification using binary

DTs. The architecture of the solution is

optimized for power consumption reduction by

means of the elimination of costly computations

in the decision process. The work in [5]

describes a parameterizable, fault tolerant

hardware implementation of trees classifiers

based on a custom VLSI chip and a CPLD chip.

Graph representation in hardware and the

implementation of the corresponding algorithms

is also recurrent in the literature. Since, in many

application domains, the problem is represented

using complex networks of vertices and edges, a

considerable number of researches have been

attracted to this field of interest. Regarding graph

data structures in hardware, [6] elaborates a

framework for large graph manipulation in

hardware. Graph data, which cannot be

partitioned and locally processed, is stored

lineally in off-chip memories. The processing

units (called Graph Processing Elements) access

the shared memory architecture through a low

latency crossbar. The architecture is

accompanied by a design flow that enables the

automatic extraction of the processing elements


82

and customization of the memory access

infrastructure.

Ahmed et al. propose in [7] a static approach

for a hardware implementation of a graph. In the

static approach vertices are gates and the edges

are the wires that connect the gates. The graph is

first represented with an adjacency matrix and

later on mapped to the logic network. Several

implementations of core algorithms such as

graph reachability and shortest path computation

are also presented in this work.

Huelsbergen, on the contrary, presents a

dynamic approach for graph representation and

manipulation in hardware which admits

modifications on the topology since vertices and

edges might be inserted or deleted [8].

Before finishing this section, it is worth

mentioning some of the most relevant projects

for accelerating reasoning mechanisms based on

the analysis of semantic trees, the application

field of the solution proposed here. Previous

approaches for Artificial Intelligence (AI)

reasoning support mainly use massively parallel

architectures with specialized processing units

and fixed (or not scalable) communication

networks. This is the case of NETL [9], the

Conection Machine [10], Semantic Network

Array Processor [11] and PNWM [12].

Little work has devised the use of FPGA and

reconfigurable devices for AI reasoning

techniques. Only GraphStep [13] proposal by

deLomirier et al. prospects the development of

specialized processing engines in Xilinx Virtex-2

FPGAs for ConceptNet spreading activation

mechanism. A Network-on-a-Chip connects all

the graph-processing engines together.

GraphStep uses regular BRAMs to store the

graph data and is able to perform one operation

per node and cycle thanks to the pipelining

structure of the processing engines.

3. Semantic trees and the Marker-

Passing Algorithm

The basic form of a semantic tree (also called

semantic network) is a graph in which each node

represents a concept and the vertices depict the

relations between concepts. This abstraction is

widely used in knowledge representation because

of its simplicity and the opportunities it brings

into light for automatic manipulation in

knowledge-oriented systems.

Knowledge in semantic trees adopts a

hierarchical shape with the more general

concepts in higher levels and the more precise

ones (even individuals) at the leaves. In this

sense, a semantic tree basically allows

knowledge categorization. Fig. 1 illustrates an

example of a semantic tree.

The real potential of knowledge-based

systems is in their capability to extract what is

called implicit knowledge from a semantic

network. For example, it can be easily inferred

that “if Dumbo is an elephant and elephants are

of grey color, then Dumbo must be of color

grey!”. Recalling Fig. 1, it can be noticed that

there is nothing like Dumbo being of a grey

color. However the implicit knowledge found in

categorization give us that information.

Such inference process, which is natural to

humans, is frequently implemented in

knowledge-based systems as the intersection of

sets of concepts in the semantic tree. Each

concept set is obtained through computation of

closures of various transitive relations. To the

question, “what color Dumbo is?” the process

would follow these steps:

First, all the concepts related to Dumbo

upwards (through the is-a relation) need to be selected.

Second, for each concept in the set

computed above, select all the nodes

(upwards) related to them through a color-of relation.

Third, all the colors in the semantic tree

have to be selected, downwards from the

color concept.

Fig. 1. Example of semantic tree.


83

The answer to the question would be the

intersection of the sets computed in steps

two and three.

This strategy is implemented in the Scone

knowledge-base system [1] by means of the

marker-passing algorithm. Concept sets are

logically built by means of the propagation of a

mark through the transitive relations between

nodes. Each node owns a mask in which

individual bits are activated if requested.

Thus, the extraction of the implicit

knowledge, hidden behind the declarative

knowledge which represents the semantic tree, is

based on three operations: upscan, downscan and

select. Algorithm 1 shows an adaptation of the

original algorithm for the upscan operation. The

goal is to provide the reader with the

understanding about the complexity and general procedure of these primitives.

Given a starting node, the semantic tree is

traversed towards upper levels, visiting the

current node parents. This process is repeated

until all nodes from the nodes to visit set have

been visited. The line 5 condition prevents the

algorithm from propagating the marker through

nodes that have already been visited. The

pseudocode for the downscan operation is almost

identical to the one shown in Algorithm 1 but the

function in line 7 is replaced with ParentOf.

Such function, given a node N and a relation R,

computes the node set that are child of N for that

relationship R. The role of the upscan and

downscan operations is mainly the construction of

the node set used in subsequent analysis.

Selection and intersection of node sets can be

implemented almost straightforwardly by only

analyzing the values of the bit mask for a certain

node. For example, to assert the membership of a

node N to a set S it is only necessary to check

whether the corresponding bit is activated in the

node mask. Set intersections are computed just by

calculating the logic and operation of the bit masks related to the sets under consideration.

4. Hardware Architecture

This section focuses on the explanation of the

micro-architecture for the hardware core designed

to accelerate the three basic operations of the

marker-passing algorithm. Later on, section 5

describes the overall platform in which this core is to be integrated.

Fig. 2 shows a high level block diagram of the

main elements conforming the architecture named

Reasoning Hardware Core (RHC). Three main

subsystems are identified in a RHC which are briefly introduced underneath:

System integration logic. It is the bus

wrapper in charge of isolating the core

logic of the kernel of the RHC from the

implementation details of the physical

protocol. This wrapper not only

interprets bus transactions and fires the

specific requests to the Central Control,

but it is also responsible for loading and

updating the content of the different RHC1 memories.

1 For the sake of simplicity, the relationships and

main connections between elements have been omitted from the diagram supporting this feature.

Upscanning(nodeN,markM,relationR)

1: Nodes2Visit = EmptySet

2: Insert(Nodes2Visit,nodeN)

3: Do

4: ActualNode = First(Node2Visit)

5: If isNotMarked(ActualNode, relationR) Then

6: Mark(ActualNode, markM) 7: ParentsOf = ChildOf(ActualNode,relationR)

8: Node2Visit = Union(Nodes2Visit,ParentsOf)

9: End If

10:While Nodes2Visit != EmptySet

Algorithm 1.Upscan operation pseudocode.

Fig. 2. Reasoning Hardware Core internal block

diagram.


84

Computation of the node set and links to

visit. This subsystem includes the CAM

Control Logic, the Semantic Tree CAM

and the logic intended to filter and

compute the actual node set to visit in

the next iteration of the upscan or

downscan operation.

Marker Propagation. It is a pipelined

datapath that, given a node set and links

to visit, it updates the marker bits and

gets the identifiers of the nodes to visit in

the next iteration of the upscan and

downscan operations. For a select

operation, it iterates through the marker

data stored in internal memories and

retrieves those node identifiers whose mask bits have been activated.

A. Representation of the Semantic Tree: the

ChildOf and ParentOf functions.

This subsection is devoted to providing an

insight of the implementation of the ChildOf and

ParentOf functions referenced in the upscan and downscan algorithms (recall Algorithm 1).

The semantic tree network of nodes and links

is represented in a tabular format which is more

suitable for hardware processing. Each semantic

tree node has a unique value identifying it.

Relationships between nodes are translated into

table entries, qualified by the relationship type

and the direction of such relation (i.e. A-node or

B-node using Scone terminology). Fig. 3

graphically represents the method [14] that

computes the parents or children of a given node,

as explained below.

In the RHC, the Semantic Tree CAM (STC)

stores the flat representation as described above.

STC is implemented using a Ternary CAM which

allows the specification of don´t care bits in the

search patterns. Therefore, to retrieved all the

relations in which a node N is-father (play the role

of B-node), it is only necessary to place don´t care

bits in the A-node field and N in the B-node field

of the search pattern (and, of course, the right

code for the relation we are looking for). The

reader can guess a similar approach works for the

case of an is-child primitive (swapping the search pattern fields).

Configuring the STC output not to be

encoded, the match output of the CAM is a

bitmask with one bit representing a memory

position. If the bit B is set to 1, it means that entry

B satisfies the primary condition (is-father or is-

child). Hence, the match register is used to index

a Block Ram (BRAM) that contains a copy of the STC content plus the marker bits.

B. CAM Control

The CAM Control logic is in charge of

generating STC search patterns and node sets to

be visited in the next iteration of the current

operation. The former operation is carried out by

the technique described before whereas the latter needs to be more detailed explained.

As it has been previously mentioned, STC

output is used to index a BRAM containing the

marker data. The basic approach to solve this

problem in hardware (a shift register and a

counter implementing an address generator)

would be non-optimal in time. Thus, an improved

indexation mechanism is developed based on: (1)

a reduction of the range of addresses to be

generated (see 4.C) and; (2) a reduction of the

number of iterations needed to complete the

algorithm.

To accomplish (2), the CAM Control uses a

network of registers and logic grouping several

STC outputs. This strategy reduces the number of

iterations and, therefore, the number of times the

BRAM needs to be indexed. Also, the number of

actual accesses to BRAM per iteration will be

higher, rising the productivity of the indexation process.

The outputs of consecutive queries to the STC

are ‘ored’ in a temporary register. When a batch

of STC accesses is completed, the value of the

temporary register is filtered using the history of

previous accesses to BRAM (match prev register).

So, for the next iteration, the set of memory

Fig. 3. Mapping a semantic tree to a flat memory

structure.


85

positions already visited is removed from the match register.

The CAM Control does not take part in the execution of the select operation.

C. Marker Propagation Datapath

The marker propagation stage updates the

marker bits for all the memory entries computed

by the CAM Control logic. It is also responsible

for inserting into the Nodes2Visit FIFO the

identifiers of the child or parent nodes (depending

on the operation under execution). The CAM

Control retrieves from the Nodes2Visit FIFO the

information needed to generate the batch of STC queries for the current iteration.

The input parameters for marker propagation

are: the marker mask (bits to activate), the

command under execution (upscan, downscan or

select), the match register (set of addresses to

access) and the historical log of previous accesses

(previous match register). Fig. 4 shows the

diagram of the segmented datapath developed for

the marker propagation process. Three stages can

be identified (from left to right): indexation or

memory access generator, propagation and

marker updating. In the picture, the second and

third stages somehow meld since they share the

same dual port BRAM memory; propagation to

read and marker updating to write.

Before starting the marker propagation, it is

necessary to load the match and previous match

values into the first BRAM memory. This BRAM

is used in the indexation or memory access

generator stage. The Index BRAM (IBRAM)

geometry will have a depth equal to the width of

the match register (one bit per memory address)

and a width of two bits. When a read access is

performed on the IBRAM, the two bit word

contains one bit from the match input and one bit

from the previous match input (i.e ibram[j] =

match[j] & prev[j]). Thus, when the IBRAM

is written, the bits of both input registers are

interleaved. In Fig. 4 the reader can notice that

there is an asymmetry in the data port width for

read and write operations. This feature is

supported by some memory technologies as the

one used in the implementation of the prototype.

In this case, a wider data port for write operations

allows completing the initialization of the IBRAM in fewer cycles.

Once the IBRAM has been initialized, the

normal operation of the datapath can proceed. The

indexation mechanism uses two address registers

(the Front Index and the Rear Index) to access the

IBRAM. The RIndex is initialized to start from

the highest memory address and every cycle it is

decremented until a value of 1 is found for the

match bit (i.e. ibram[RIndex][0] == 1).

Therefore, the RIndex value indicates the last

address to access accordingly to the match

register value for this iteration. This optimization

avoids unnecessary cycles to check match bits for more memory accesses.

Another optimization implemented in the

proposed indexation mechanism uses the Start

Index register recording the position of the first bit

with a value of 0 in the history of match values.

For each iteration, FIndex is loaded with the value

of Start Index, avoiding unnecessary memory checks.

When ibram[FIndex][0] == 1, an

access to the Sematic Tree BRAM (STBRAM)

Fig. 4. Marker Propagation Pipeline.


86

takes place at the next execution cycle. The

Propagation Unit analyzes semantic tree entry

retrieved from memory and determines, based on

the current operation and the marker mask,

whether the memory entry needs to be updated (if

it has not been already activated the marker bit –

line 5 of Algorithm 1). The Propagation Unit

generates the write commands to the Nodes2Visit

FIFO and the STBRAM that will take place in the next execution cycle.

Finally, it is worth sketching out how the

select operation works. In this case, there is no

need of IBRAM initialization since all the

memory map needs to be explored. Thus, the

indexing stage generates all the possible address values to read the STBRAM.

The Propagation Unit only generates write

commands for the Nodes2Visit FIFO when the

following condition evaluates to true marker == (marker && stbram[i].bitmask).

5. Implementation results

The XUPV5 board from Xilinx has been the

device chosen for the implementation of a

prototype of the Reasoning Hardware Core

presented here.. It is based on a Virtex5 LX110T

chip, equivalent to four million logic gates with run-time partial reconfiguration capability.

The RHC core is connected to the Processor

Local Bus (PLB) and a Microblaze soft processor

which runs a small program which communicates

with the RHC peripheral to launch commands, load semantic tree data, read results, etc.

In this prototype, the RHC is able to store a

semantic tree with a maximum of 1K relations

and 512 concepts. Therefore, all the memories in

the design have a depth of 1K words and 20 bits

(2 bits to codify the relation code and 9 bits x 2 to

codify the node identifier) width for the STCAM.

The IBRAM is 2 bit width as mentioned in the

previous section and the STBRAM is 30 bit width

(20 bits + 8 bits for the marker mask + 2 control

bits). All the RAM memories in the design are

true dual-port memories and configured in READ

FIRST operating mode. The STCAM memory is

the most demanding component from the

resources point of view and conditions the

maximum clock frequency the RHC is able to

achieve. The STCAM is a SRL16E-based CAM

with a 16 clock cycle write latency and one cycle

latency for search operations. STCAM

implements a basic ternary mode for search

operations and the match address output is multi-match unencoded (many-hot).

The whole design has been synthetized using

the 12.1 ISE Design Suit Embedded Edition with

the following results:

TABLE I. RHC SYNTHESIS RESULTS

Freq SRL16 Flip Flops LUTs Slices

107

Mhz

10240

(57%)

1259 (2%) 14935

(22%)

4049 (23%)

TABLE II. EXECUTION TIME PERFORMANCE

Test SW Time* HW Time*

Downscan the semantic

network tree (1K elements)

43 ms 92 us

Mark & intersect 2 sets with 10

members, one winner

2 ms 423416 ns

Mark & intersect 3 sets with 10

members, one winner

3,6 ms 475903 ns

* Mean execution time of relevant scone reasoning

operations in the HRP and dell workstation. 500

executions of each test were carried out.

The evaluation of the HRP presented here

needs to be compared to the software

implementation of the Scone system. The set of

tests has been design with the following strategy

in mind: reproducing similar scenarios than the ones undertaken in [1].

The computer in which the software runs is a

Dell XPS 8300 workstation with 8GB of DDR3

memory, an Intel i7-2600 processor at 3.4 Ghz

and a 64-bit GNU/Linux (kernel version 2.6.16)

operating system. Due to space constrains, Table

II only shows the results for the most relevant

tests executed on both the workstation and the FPGA based prototype of the HRP.

6. Conclusions

In this paper, the design of a hardware unit to

accelerate semantic tree operations for common-

sense reasoning applications was presented. The

algorithm utilized was the marker-parser strategy

proposed for the Scone Knowledge-Based

system. The implementation has been performed

using a Xilinx ML507 prototyping board, with a

Virtex-5 LX110T FPGA (Field Programmable

Gate Array) chip and compared to an equivalent


87

software implementation.. The optimized micro-

architecture together with a smart data mapping

strategy allows our solution to achieve a

significant reduction in execution times of

marker-parser algorithms.

Acknowledgment

This research was supported by the Spanish

Ministry of Science and Innovation under the

project DREAMS (TEC2011-28666-C04-03), and

by the Spanish Ministry of Industry and the

Centre for the Development of Industrial

Technology under the project ENERGOS (CEN-

20091048).

References

[1] Fahlman, S., “Marker-passing inference in

the scone knowledge-base system,” in First

International Conference on Knowledge

Science, Engineering and Management

(KSEM’06). Springer-Verlag (Lecture

Notes in AI), 2006.

[2] Narayanan, R., Honbo, D., Memik, G.,

Choudhary, A. and Zambreno, J., “An

FPGA implementation of decision tree

classification,” In Proceedings of the

conference on Design, automation and test

in Europe (DATE '07), 2007, pp. 189-194.

[3] Struharik, R.J. R. and Novak, L.A.,

“Evolving Decision Trees in Hardware”,

Journal of Circuits, Systems and Computers,

vol 18 (6), pp. 1033-1060. 2009.

[4] By Li, Q., Bermak, A., “A Low-Power

Hardware-Friendly Binary Decision Tree

Classifier for Gas Identification,” Journal of

Low Power Electronics and Applications,

vol. 1, pp. 45-58. 2011.

[5] Bermak, A., Martinez, D., “A

Reconfigurable hardware implementation of

tree classifier based on a custom chip and

CPLD for gas sensors applications,” In

Proceedings of the IEEE TENCON, Chiang

Mai, Thailand, vol 1, pp. 32–35, 2004.

[6] Betkaoui, B., Thomas, D.B.T., Luk, W. and

Przulj, N., “A framework for FPGA

acceleration of large graph problems:

Graphlet counting case study ,” In

Proceedings of the IEEE International

Conference on Field-Programmable

Technology (FPT 2011), New Delhi, India,

December 12-14, 2011.

[7] Ahmed, I., Rahman, M.A.U., Alam, S.

and Islam, N., “Implementation of Graph

Algorithms in Reconfigurable Hardware

(FPGAs) to Speeding Up the Execution,” In

Proceedings of the 4th International

Conference on Computer Sciences and

Convergence Information Technology

(ICCIT’09), Novemeber 24-29, 2009.

[8] Lorenz Huelsbergen, “A representation for

dynamic graphs in reconfigurable hardware

and its application to fundamental graph

algorithms,” In Proceedings of the 2000

ACM/SIGDA 8th international symposium

on Field programmable gate arrays (FPGA

'00). ACM, New York, NY, USA, 105-115.

[9] Fahlman, S.E., “NETL: A System for

Representing and Using Real-World

Knowledge,” MIT Press: Cambridge, MA,

1979.

[10] Chung, S.H., Moldovan, D.I., “Modeling

semantic networks on the Connection

Machine,” Journal on Parallel and

Distributed Computing, vol 17, 152–163,

1993.

[11] Kitano, H., Moldovan, D., “Semantic

Network Array Processor as a massively

parallel computing platform for high

performance and large-scale natural

language processing,” Proceedings of the

14th Conference on Computational

Linguistics (COLING’92), Stroudsburg, PA,

USA, 1992.

[12] Sapaty, P., Kocis, I., “A parallel network

wave machine,” In Proceedings of the Third

International Workshop on Parallel

processing by cellular automata and arrays,

1987, pp. 267–273

[13] T.F.J., DeHon, A., “GraphStep: A System

Architecture for Sparse-Graph Algorithms,”

Annual IEEE Symposium on Field-

Programmable Custom Computing

Machines, 2006, pp. 143–151.

[14] N.H. Minsky, "Representation of Binary

Trees on Associative Memories", presented

at Inf. Process. Lett., 1973, pp.1-5.


88

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Ahmed,%20I..QT.&newsearch=partialPref

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Rahman,%20M.A.U..QT.&newsearch=partialPref

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Islam,%20N..QT.&newsearch=partialPref





Trabajo de desarrollo de un Sensor Multivista basado en

microcámaras de bajo coste

David Hernández Expósito(1)

, Manuel Rodríguez Valido(1)

,Eduardo Magdaleno

Castelló(1)

, Fernando Pérez Nava(2)

[email protected], [email protected], [email protected], [email protected]

(1) Dpto. Física Fundamental Experimental Electrónica y Sistemas, Universidad de La Laguna. (2) Dpto. Estadística Investigación Operativa y Computación, Universidad de La Laguna.

Resumen

La captura de escenas tridimensionales permite un

amplio e innovador conjunto de aplicaciones.

Actualmente existen prototipos experimentales de

sensores multivista para capturar la escena

tridimensional, sin embargo éstos no son

productos comerciales debido principalmente a su

alto coste. El objetivo de este trabajo es diseñar un

prototipo de sensor multivista que permita sacar

conclusiones que contribuyan a reducir los

problemas de los actuales sensores desde el punto

de vista tecnológico y comercial. Durante el

desarrollo de este prototipo, actualmente en curso,

se han llevado a cabo dos tareas: por un lado la

integración de múltiples cámaras CMOS de bajo

coste en una PCB y, por otro lado, el diseño en

FPGA de un driver de adquisición y envío a un

PC de la escena capturada.

1. Introducción

La utilización de múltiples vistas para estudiar una

escena es una idea que ha aparecido de forma

periódica en la historia de la fotografía. Su mayor

impulso se ha producido con el desarrollo de las

cámaras digitales y la capacidad de procesamiento

que tienen los ordenadores actuales. El objetivo de

los sistemas que obtienen múltiples vistas es la

captura del campo de luz de la escena [2]. El

campo de luz de la escena se representa mediante

la función plenóptica 7 dimensional que describe

la intensidad de la luz para cualquier posición y

dirección del espacio 3D a lo largo del tiempo [1].

La utilización de múltiples vistas permite la

obtención de la función plenóptica en toda su

extensión, lo que permite todo un nuevo conjunto

de aplicaciones: reconstrucción 3D, reducción del

ruido, súper-resolución, aplicaciones de alta

velocidad, etc.

Existen dos tipos principales de sensores

capaces de capturar la escena tridimensional: las

cámaras plenópticas y los sistemas basados en

multicámara. En este trabajo nos centraremos en

estos últimos.

La forma más sencilla de obtener múltiples

vistas se basa en una cámara fotográfica móvil [3].

El inconveniente de este sistema es que sólo

puede capturar objetos estáticos. Para solucionar

este problema, en lugar de utilizar una cámara

fotográfica móvil es posible utilizar un gran

número de cámaras fotográficas (sistemas “Bullet-

time”) que se disparan de forma secuencial. Tras

la aparición de estos sistemas, la optimización de

los sensores multivista ha apuntado hacia sistemas

compuestos por múltiples cámaras sincronizadas

entre sí. Entre ellos, el sistema Virtualized Reality

[5], fue pionero en capturar datos desde un gran

número de cámaras de video profesionales

sincronizadas. En adelante, surgieron numerosas

investigaciones sobre sistemas basados en

múltiples cámaras sincronizadas, como por

ejemplo: “Visor dinámico de campos de luz” [8],

“Sistema de cámaras autoconfigurable” [9],

“Sistema de cámaras de Stanford” [6], y “Sistema

multicámara para 3DTV” [7]. Actualmente, los

sistemas multicámara siguen despertando gran

interés. Prueba de ello es el proyecto Pelican

Imaging respaldado por inversores de la talla de

Qualcomm y Nokia, que pretende sacar al

mercado un array de sensores orientado a su

integración en smartphones [4].

En general, la problemática de este tipo de

sistemas multicámara es extensa. Podemos


89


resaltar el coste del producto final, el peso, las

dimensiones del mismo y el procesamiento del

gran volumen de datos que se generan en un

instante de tiempo. Así, el objetivo de este trabajo

en desarrollo es diseñar un prototipo de sensor

multivista de bajo coste y pequeñas dimensiones

que ayude a mejorar los problemas de este tipo de

sistemas.

El diseño de este prototipo ha contado con dos

tareas bien diferenciadas. Por un lado, la

integración de múltiples cámaras de bajo coste en

una PCB y, por otro lado, el diseño e

implementación de un driver Hardware-Software

en FPGA con el que adquirir los datos de dicho

sensor y transmitirlos a un entorno manejable

basado en PC (Figura 1).

Este artículo se estructura como sigue. En el

apartado 2 se hace una descripción de la línea

seguida en cuanto a la integración y

sincronización de múltiples cámaras. A

continuación, en el apartado 3 se muestra la

arquitectura propuesta como driver Hardware-

Software implementado en FPGA encargado de

las tareas de adquisición de datos del sensor y

conexión con un PC. Por último, en los apartados

4 y 5 se enumeran los resultados y las

conclusiones alcanzadas hasta el momento.

2. Integración y sincronización de

múltiples sensores

Atendiendo a los objetivos de este trabajo, se

eligieron sensores CMOS de bajo coste (menos de

9€) y reducidas dimensiones para la

implementación del sensor multivista.

Inicialmente, buscando la máxima miniaturización

del sistema se usó el dispositivo OVM7690

Camera Cube, un sensor de imagen con

resolución VGA empaquetado en un circuito

integrado BGA de muy pequeñas dimensiones

(2.5 x 3 x 3 mm) por lo que se les denomina

microcámaras. Basado en estos dispositivos, se

diseñó y fabricó una PCB que alberga 9

microcámaras dispuestas de forma lineal, con una

separación entre sensores de aproximadamente

8mm de centro a centro, con lo que la separación

de las microcámaras de los extremos es de

aproximadamente 80mm (ver Figura 1). En esta

PCB, las microcámaras tienen la alimentación y el

reloj común a todos ellas así como un bus de

control I2C por medio del cual se configura cada

sensor. Cada microcámara cuenta con un bus de

datos de 8 bits además de las señales de

sincronismo y el reloj de píxel. Esto hace un total

de 11 señales por microcámara lo que supone un

interfaz global de 11x9=99 señales que deben ser

manejadas por el driver.

Por motivos aún inciertos (error de diseño,

fabricación de la PCB, etc.), sólo una

microcámara funciona correctamente de las nueve

instaladas en la PCB. Esto ha impedido trabajar en

las tareas de sincronización en este prototipo. Por

ello, actualmente se está trabajando con otros

sensores pre-soldados en PCBs de muestra,

evitando el coste del diseño y fabricación de PCBs

con BGA (Figura 2). El sensor elegido ha sido el

OV2640 de resolución UXGA, cuyas señales de

video son similares a las descritas para el

OVM7690. Con este sensor sí se ha podido

experimentar en la conexión de varios de ellos,

como se describe en la siguiente subsección.

Figura 2. OV2640 soldado en PCB de muestra y

OVM7690

1 2 3 N00 11 22 88

POWER

I2C

VIDEO BUS 0

VIDEO BUS 1

VIDEO BUS 8

80 mm

GigaBee XC6SLX

FPGAXC6SLX150

SDRAMDDR3

ETHERNETPHY

DRIVER PC

11 x 9video signals

SENSOR MULTIVISTA

Figura 1. Representación esquemática del sistema


90

2.1. Sincronización entre sensores

La sincronización entre las cámaras del sensor

multivista es una tarea relevante. Tener las

cámaras en perfecto sincronismo permite entre

otras cosas, controlar la resolución temporal de las

capturas y disminuir el número de señales que

componen el interfaz, pues las señales de

sincronismo y el reloj de píxel serían comunes a

todas las cámaras del sensor. Existen cámaras,

como la OVM7690, que cuentan con la

característica nativa de poder ser configuradas

como esclavas, lo que permite una completa

sincronización entre varias cámaras a las que se

les suministren señales de sincronismo maestras.

Haciendo uso de esta prestación, se han

sincronizado las salidas de dos de estas cámaras.

Para ello, se han generado señales de sincronismo

maestras en una FPGA.

Sin embargo, también se ha conseguido

sincronizar varios de estos sensores por un método

que no requiere hacer uso de la sincronización

externa. Este método se basa simplemente en la

configuración de todos los sensores mediante el

bus I2C con señales broadcast. El hecho de enviar

las mismas señales a dispositivos técnicamente

iguales hace que su respuesta sea muy similar,

consiguiendo sincronismo en la salida con errores

inferiores a 10 píxeles de desfase. Estos desfases

pueden ser corregidos haciendo uso de pequeñas

memorias FIFO, que almacenen de forma

temporal los píxeles correspondientes al desfase,

para luego ser leídos de manera síncrona. Este

método puede ser extrapolado a las microcámaras

OVM7690 u otras que no tengan la característica

nativa de poder ser sincronizadas.

3. Driver Hardware-software

La ingente cantidad de datos producidos por un

sensor multivista, así como el gran número de

señales de su interfaz, debe ser preprocesado para

poder tratar los datos con comodidad, por ejemplo

en un PC. Para realizar este enlace entre el sensor

multivista y un PC se ha implementado un driver

Hardware-software en la FPGA de Xilinx

Spartan-6 LX150 de la tarjeta de desarrollo

Gigabee XC6SLX de Trenz Electronics. Ésta se

adecúa a los requerimientos del sistema, pues

cuenta con 109 pines de entrada/salida

configurables así como dos bloques de memoria

externa DDR3 e interfaces estándar como Gigabit

Ethernet.

En esta FPGA se ha implementado un driver que

realiza las tareas de adquisición de imágenes

multivista, almacenamiento temporal en buffers

alojados en memoria externa DDR3, y envío de

las mismas a un PC a través de un interfaz Gigabit

Ethernet bajo los protocolos UDP/IP. La

arquitectura del driver está basada en el bus AXI4

y el microprocesador Microblaze bajo las librerías

Standalone. La arquitectura se complementa con

periféricos AXI compatibles de las librerías de

cores de Xilinx.

En la Figura 3 se muestra la arquitectura

implementada. El sistema de buses AXI4 está

gobernado por dos controladores de bus

AXI_Interconnect, uno para AXI4-Lite y el otro

para AXI4. El acceso a memoria externa DDR3 lo

proporciona el core axi_s6_ddrx el cual usa el

Memory Controller Blcok (MCB) primitivo de la

Spartan 6 y adapta el interfaz nativo de este

controlador a un interfaz AXI4 esclavo. De esta

forma, la memoria SDRAM-DDR3 queda

accesible por todo el sistema como una memoria

multipuerto, gestionada por el controlador de bus

AXI_Interconnect.

El sistema de adquisición y almacenamiento

de datos procedentes de las microcámaras está

formado por los cores video_2_AXIS y axi_vdma

(Video Direct Memory Acces). El video_2_AXIS

se encarga de convertir las 99 señales del interfaz

del sensor multivista en formato AXI4-Stream.

Esto lo puede hacer de dos modos: seleccionando

por medio de un multiplexor las señales de video

de una sola cámara, o bien, cuando las cámaras

están sincronizadas, concatenado los buses de

datos de todas las cámaras en un solo bus de datos

del AXI4-Stream. Este bus está conectado al

axi_vdma, el cual se encarga de asociar

direcciones de memoria a los datos recibidos,

organizándolos en frames buffers alojados en la

memoria externa DDR3.

El interfaz Gigabit Ethernet está formado por

los cores axi_dma y axi_ethernet. El axi_dma,

gestionado por el Microblaze, realiza lecturas en

los frames buffers y las transfiere al core

axi_ethernet a través de bus AXI4-Stream. El

potencial de este sistema se centra en que el

axi_ethernet tiene la capacidad de calcular los

campos de comprobación (checksum) de las

tramas Ethernet con protocolos UDP/IP. Así, el

axi_dma limita su función a leer de memoria las


91

cabeceras de las tramas Ethernet y los datos a

enviar, y el axi_ethernet calcula y añade los

campos de checksum. De esta manera, las lecturas

son puramente hardware. El software solo

configura dónde y cuándo tiene que leer el

axi_dma.

La configuración de las cámaras se hace

mediante el microblaze, el cual utiliza el core

axi_iic como interfaz físico con el bus I2C. Por

medio de este bus se pueden configurar todos los

parámetros de la cámara, como resolución, frame

rate, etc.

El interfaz de usuario se implementa por

medio de una UART conectada al PC. Desde una

consola se envían comandos para configurar las

cámaras o ejecutar una captura de foto o video.

3.1. Flujo de datos

El flujo de datos se controla de forma asíncrona

por medio de interrupciones manejadas por el

Microblaze. Al iniciar la aplicación se inicializa el

sistema y permanece a la espera de recibir

comandos por UART. Cuando se envía una orden

de captura de foto o video el axi_vdma comienza

la escritura de los frames en los buffers de

memoria (hasta 16 posibles). Éste genera una

interrupción por cada frame almacenado. Una vez

haya un número determinado de frames

almacenados en memoria, el axi_dma comienza a

leer dichos frames fragmentados en paquetes de

datos que se corresponderán con la carga útil de

los datagramas UDP. Así, el axi_ethernet envía

estos paquetes al PC por medio de Ethernet.

El Microblaze se encarga de manejar

adecuadamente las rutinas de interrupción,

evitando conflictos de lectura/escritura del buffer

compartido por el axi_vdma y axi_dma.

4. Resultados

Durante el desarrollo de este trabajo se ha

experimentado en dos tareas diferenciadas: el

diseño e integración de un conjunto de sensores

microblazebram(ilmb)

bram(ilmb)

DLMB

ILMB

axi_uartlite

axi_intcInterrupts in from ip cores

intr

irq

RS232

AX

I Int

erco

nnec

t(a

xi_l

ite)

AX

I Int

erco

nnec

t(a

xi4)

axi_s6_ddrx

axi_vdma

axi_dma axi_ethernet

SDRAMDDR3

video_2_AXIS

axi_iicIIC BUS

DC

IC

DP

S2MM

SG

MM2S

MM2SSTREAM

S2MMSTREAM

SENSORMULTIVISTA

AXI4-LITE

AXI4-STREAM

AXI4

S2MM

MM2S

SGMM2S

STREAM

S2MMSTREAM

STATUSSTREAM

CONTROLSTREAM

VIDEOBUS

AXISTREAM

S2MMFSYNC

FSYNC

to Interrupt controller

to Interrupt controller

CONTROLIF

SLAVESTREAM

MASTERSTREAM

STATUSIF

ETHERNET PHY

OTROS

AXI-Lite XILINX CORE

CUSTOM CORE

Figura 3. Arquitectura del Driver


92

CMOS de bajo coste y el diseño e implementación

de un driver con arquitectura Hardware-Software

que realiza las funciones de adquisición y envío

de imágenes multivista a un PC.

En el intento de maximizar la miniaturización

del sensor multivista, se integraron 9

microcámaras OVM7690 dispuestas linealmente

en una PCB de reducidas dimensiones. El coste

material de este prototipo se situó en torno a los

100 €, una vez superados los costes fijos de

fabricación de la PCB de unos 700€. Sin embargo,

debido a algún error de diseño o fabricación, no

fue posible experimentar con este prototipo. Esto

motivó el uso de los sensores OV2640 con los que

se ha experimentado en el campo de la

sincronización entre cámaras. Por un lado se

sincronizaron completamente dos cámaras en

modo esclavo, mediante la generación de señales

de sincronismo desde la FPGA. Y por otro lado,

se sincronizaron parcialmente, con desfases

inferiores a 10 píxeles, dos cámaras mediante

comandos broadcast a través del bus I2C,

pudiendo ser este último método aplicable a las

microcámaras OVM7690.

En cuanto al driver Hardware-Software, se ha

diseñado e implementado en la FPGA

XCS6LX150 una arquitectura tipo de Xilinx,

basada en bus AXI4 y gobernada por un

Microblaze con librerías Standalone. La

ocupación de recursos de la FPGA se encuentra en

torno a un 30%. Este driver captura las imágenes

del sensor multivista y las envía a un PC a través

de UDP/IP Gigabit Ethernet. Las velocidades de

transmisión alcanzadas se acercan mucho al

máximo teórico, en torno a 95 Mbps para enlaces

de 100 Mbps y 950 Mbps para enlaces Gigabit

(medidas con Wireshark). Con esta conectividad,

el sistema es capaz de enviar video VGA de las

nueve cámaras de forma simultánea y sin

comprimir en torno a 20 frames por segundo.

5. Conclusiones

En este artículo se presenta un trabajo en

desarrollo. El diseño del array de sensores basado

en las microcámaras OVM7690 se ha visto

comprometido posiblemente con la tecnología

disponible para el proceso de fabricación, la cual

se encontraba en los límites requeridos por el

grado de miniaturización de estos sensores (BGA

separación entre pines de 500µm). Por tanto, el

uso de los sensores OV2640 ha permitido avanzar

en las tareas de sincronización entre cámaras así

como la verificación del driver implementado. Se

espera próximamente, a expensas de financiación,

implementar una PCB que integre nueve sensores

OV2640 que permita continuar el desarrollo del

sensor multivista.

Por otro lado, el driver desarrollado es

plenamente funcional en la captura y envío a un

PC de imágenes y video provenientes de hasta

nueve sensores de forma simultánea o

multiplexada. Además, la elección de una FPGA

como soporte tecnológico aporta la versatilidad

necesaria para desarrollar on a chip algoritmos

novedosos y de alto coste computacional como

por ejemplo: medida de distancias, detección de

objetos ocultos, visión omnidireccional, vídeo de

alta velocidad (fps), etc.

El coste de este prototipo de sensor multivista,

así como el peso y las dimensiones del mismo, se

ha limitado usando sensores CMOS de bajo coste

con óptica integrada. Esto reduce la calidad de las

imágenes capturadas respecto a sistemas basados

en cámaras profesionales como los mencionados

anteriormente. No obstante, este prototipo es

válido para adquisición de campo de luz, estudios

del sincronismo entre cámaras, desarrollo de

algoritmos, y otros aspectos que contribuyan al

desarrollo de sensores multivista.

Agradecimientos

Los autores quedan especialmente agradecidos al

Instituto Universitario de Microelectrónica

Figura 4. Prototipo de sensor multivista basado en cámaras un array de cámaras OVM7690 acoplado a la

tarjeta de desarrollo Gigabee XC6SLX.


93

Aplicada (IUMA) de la Universidad de Las

Palmas de Gran Canaria por poner

desinteresadamente a nuestra disposición sus

instalaciones y su tiempo durante el proceso de

fabricación de la PCB de las microcámaras.

Este proyecto ha sido financiado por la

Universidad de La Laguna, dentro del programa

2013 de Apoyo a la Investigación (Modalidad I)

Referencias

[1] Adelson, E.H., Bergen, J.R. "The plenoptic

function and the elements of early vision", In

Computation Models of Visual Processing, M.

Landy and J.A. Movshon, eds., MIT Press,

Cambridge, 1991, pp. 3–20, 1991.

[2] Gershun, A.. "The Light Field", Moscow,

1936. Translated by P. Moon and G. Timoshenko

in Journal of Mathematics and Physics, Vol.

XVIII, MIT, 1939, pp. 51–151.

[3] M. Levoy and P. Hanrahan. Light field

rendering. In Proc. ACM Conference on

Computer Graphics (SIGGRAPH’96), pages 31–

42, New Orleans, USA, August 1996.

[4] Pelican Imaging. www.pelicanimaging.com

[5] P. Rander, P. Narayanan, and T. Kanade.

Virtualized reality: Constructing time varying

virtual worlds from real events. In Proceedings of

IEEE Visualization, pages 277–283, Phoenix,

Arizona, October 1997.

[5] B. Wilburn, N. Joshi, V. Vaish, E. Talvala, E.

Antunez, A. Barth, A. Adams, M. Horo-witz, and

M. Levoy, High Performance Imaging Using

Large Camera Arrays, in ACM Transac-tions on

Graphics, vol. 24, no. 3, pp. 765-776, July 2005

[7] Xun Cao, Yebin Liu, Qionghai Dai, "A

flexible client-driven 3DTV system for real-time

acquisition, transmission, and display of dynamic

scenes," Eurasip Journal On Advances In Signal

Processing, Volume 2009, 15 pages, 2009

[8] J.-C.Yang, M. Everett, C. Buehler, and L.

McMillan. A real-time distributed light field

camera. In Eurographics Workshop on Rendering,

pages 1–10, 2002.

[9] C. Zhang and T. Chen. A self-reconfigurable

camera array. In Eurographics Symposium on

Rendering, 2004.


94

Capítulo 4

Cryptography & Fault Tolerance

Capítulo 4 - Cryptography & Fault Tolerance Mecanismos ligeros para mejorar la fiabilidad de las respuestas PUF en la generación de llaves criptografícas Brisbane Ovilla-Martinez (Cinvestav, Tamaulipas, Mexico), Arturo Diaz-Perez (Cinvestav, Tamaulipas) Ataques por canal lateral sobre el algoritmo de encriptación AES implementado en MicroBlaze Mariano Rubén Lumbiarres López (Universitat Politècnica de Catalunya, Spain), Mariano López García (Universitat Politècnica de Catalunya), Enrique Cantó Navarro (Universitat Rovira i Virgili, Spain) Protección efectiva de circuitos implementados en FPGAs utilizando técnicas de triplicación sobre la plataforma NESSY Silvia Alcázar (Universidad Complutense de Madrid), Almudena Alonso (Universidad Complutense de Madrid), Beatriz Álvarez-Buylla (Universidad Complutense de Madrid), Felipe Serrano (Universidad Complutense de Madrid), Juan Antonio Clemente (Universidad Complutense de Madrid) Un estudio de la robustez frente a SEUsde circuitos digitales implementados con los DSPs de las FPGAs Felipe Serrano (Universidad Complutense de Madrid), Juan Antonio Clemente (Universidad Complutense de Madrid), Hortensia Mecha (Universidad Complutense de Madrid Spain)

Mecanismos ligeros para mejorar la fiabilidad de lasrespuestas PUF en la generación de llaves criptográficas

Brisbane Ovilla-Martínez (1), Arturo Díaz-Pérez (1)

{brisbane,adiaz}@tamps.cinvestav.mx(1)Laboratorios de Tecnologías de la Información, Cinvestav-Tamaulipas

Parque Científico y Tecnológico TECNOTAM

Km. 5.5 carretera Cd. Victoria-Soto La Marina

Cd. Victoria, Tamaulipas 87130, MEXICO

Resumen

La generación de llaves criptográficas PUF(Funciones Físicamente no Clonables) requiereel uso de mecanismos para garantizar la rege-neración de la llave, lo cual resulta ser bas-tante costoso para dispositivos con hardwarelimitado. En este trabajo se presenta una me-todología para mejorar la fiabilidad de las res-puestas PUF. Seleccionamos el código Hsiaopara corregir errores que se presentan durantela regeneración de la llave. Además se presen-ta un análisis para determinar que tamaño delbloque decodificador es eficiente en términosde éxito de regeneración de llaves y el áreade hardware. Por último se muestra el análi-sis de los requerimientos para generar llavescon al menos 128 bits de seguridad. Las prue-bas fueron realizadas en un FPGA Spartan-6XC6SLX45, para un bloque de 16 bits se ob-tuvo una implementación del decodificador de416 slices (1%) y una fiabilidad del 98.36%.

1. Introducción

En los últimos años las PUF han sido propues-tas por la comunidad de seguridad en hard-ware y criptografía como una nueva primitivacriptográfica que ayuda a identificar un dispo-sitivo físico de manera única. Una PUF puedeser evaluada en tiempo de ejecución y no re-quiere almacenar las respuestas en ningún tipode memoria no volátil. Las respuestas depen-

den de la aleatoriedad intrínseca presente enel dispositivo físico. Las dos últimas ideas con-ducen a pensar que las PUF pueden ser utili-zadas para generar llaves criptográficas dentrode dispositivos con capacidades limitadas dememoria [12].

En la literatura se han propuesto varios ar-tículos relacionados con el mejoramiento dela fiabilidad de las respuestas PUF. Los ex-tractores difusos han sido utilizados por va-rios autores [4] [2], éstos han dado buenos re-sultados para extraer identificadores únicos delos dispositivos. Otros autores han trabajadocon los códigos de corrección de errores (ECC)por bloque, por ejemplo, en [7] usaron códigosGassed 2D Hamming, Suh et al. [12] propo-nen el uso de BCH (255, 63 USD, t = 30) de-bido a la cantidad de ruido en las respuestas.También la combinación de dos técnicas hansido propuestas por Bosch et al. [2], ellos utili-zan extractores difusos con una concatenaciónde un código por bloque. Maes et al. [10] quepropone utilizar un descodificador de decisiónflexible.

Un generador funcional de llaves criptográ-ficas fue propuesto por [9], proponen el usode mecanismos de corrección de error bási-camente mediante la concatenación dos códi-gos: el de repetición Crep(7, 1, 3) y luego unBCH ( 318,174,17). El tamaño de la llave esde 128 bits y reportaron una tasa de falló depno ≤ 10−9.

En este trabajo se propone una metodología


97

para mejorar la fiabilidad de respuestas PUFy poder utilizarla en la generación de llavescriptográficas. El generador de llaves PUF espropuesto para que sea implementado en dis-positivos con hardware limitado.

Este artículo está organizado de la siguien-te manera: los antecedentes se presentan en lasección 2. La sección 3 muestra la metodolo-gía que se siguió para realizar el generador dellaves. Los detalles sobre el proceso de caracte-rización propuesto se encuentran en la sección4. La selección de módulo de ECC y su apli-cación a las respuesta PUF se muestra en lasección 5. La implementación y los resultadosse presentan en la sección 6. En la sección 7, seencontrarán las conclusiones de este artículo.

2. Funciones Físicamente no Clona-bles (PUF)

Hasta el momento varias son las construccio-nes PUF que han sido propuestas y éstas sebasan en diferentes principios. Las PUFs ba-sadas en retardos toman ventajas de las di-ferencias que hay dentro de un mismo dispo-sitivo para generar retardos aleatorios y con-vertirlo en una firma PUF, algunas propues-tas son: Arbiter-PUF [8], Ring Oscillator [12].Las PUF basadas en memoria explotan lasvulnerabilidades que existen en el balance deuna celda de memoria, para procesar intrín-secamente variaciones, por ejemplo, acopla-miento cruzado de transistores o inversores.Otras construcciones como SRAM-PUF [4] yButterfly-PUF [6], están basadas en elemen-tos de acoplamiento cruzado de inversores ylatches, respectivamente. Otro tipo de PUF esel generado por fallos, tratando de provocarun comportamiento no ideal de algún elemen-to físico, por ejemplo la LUT-PUF [1].

La LUT-PUF fue propuesta en 2010 por An-derson [1] y utiliza los componentes internosdel CLB de un FPGA, tomando ventaja delas variaciones aleatorias que hay en cada LUTdel CLB. LUT-PUF fue de descrito completa-mente en HDL. Un diagrama general del cir-cuito que describe la construcción LUT-PUFse muestra es la Figura 1 el cual se compone dedos LUT (A y B) y un registro en modo de des-

plazamiento. La LUT(A) se pre-inicializa con0x5555 mientras que la LUT(B) con el com-plemento 0xAAAA. La configuración de estecircuito se ajusta para mantener la señal N2siempre con valor de 0-lógico, pero la presen-cia de un flanco positivo en N2, es decir, quecambio abruptamente de 0-lógico a 1-lógico,el valor del flip-flop se ponen a 1-lógico. Elcircuito mostrado en la Figura 1 sólo presen-ta como se genera un bit PUF, para obtenerrespuestas de mayor longitud es necesario re-plicar este circuito hasta tener la respuesta deltamaño deseado.

FF-D

preset

D Q LUT bit

clk

LUT A

Init: 0x5555

D Qclk

WE

LUT B

Init: 0xAAAA

D Qclk

WE

1 0

1 0

‘1'

‘1'

‘0’

‘1'‘0’

N2

N1

Figura 1: Diagrama de LUT-PUF para la genera-ción de un bit PUF.

3. Generador de llaves criptográfi-cas a partir de PUF

Idealmente, para generar una llave bastaríaaplicar un desafío a un arreglo de PUFs paraobtener un arreglo de bits como respuesta, loscuales pueden ser usados como llave. Sin em-bargo, las respuestas de las PUF pueden variarpor lo que en este artículo se usa el esquemapropuesto originalmente en [12].

Para poder implementar el esquema de [12]en dispositivos restringidos, se propone seguirla metodología que está basada en: Eliminarlas posiciones más inestables, obtener la res-puesta más probable del arreglo de PUFs, re-ducir la complejidad del decodificador de erro-res y generar una llave que pueda ser usadapara comunicaciones seguras con el dispositi-vo. La metodología consiste de los siguientes

Capítulo 4: Cryptography & Fault Tolerance

98

subprocesos: 1) Caracterización de la PUF y2) Iniciación de llave.

Con el propósito de mejorar la fiabilidad delas respuestas PUF en el subproceso de inicia-ción de llave es necesario usar un módulo dedetección y corrección de errores (ECC por sussiglas en inglés), éste es necesario ya que aúneliminando posiciones inestables pueden per-sistir algunas posiciones adicionales que varíensu respuesta. El módulo ECC debe mejorar lafiabilidad de las respuestas pero su implemen-tación no debe ser costosa para ser colocadaen dispositivos restringidos.

4. Caracterización de la PUF

En el proceso de caracterización se parte deun arreglo de y bits generados por PUF delos cuales se eliminarán r bits redundantes. Alfinal se obtendrán x = y− r bits de respuesta.

Para la toma de muestras se realiza la ex-citación de la PUF aplicándole un desafío c yasí conocer el par desafío-respuesta, tomandom muestras por cada uno de los retos c. Lasrespuestas son almacenadas dentro de un arre-glo bidimensional que denominamos matriz derespuesta (RM), con y columnas y m filas.

Se realiza a continuación un análisis de lacantidad de ruido que posee cada bit de la res-puesta. El análisis consiste básicamente en co-nocer cuál es el valor (0 ó 1) más frecuenteen cada posición y sobre eso detectar cuantasveces se presentó un valor distinto, es decir,ruido.

Si l es el número de veces que PUF respon-dió con 1 de una serie de m pruebas, entonces,la función smod(l,m) definida en la Ecuacióncalcula qué tanta variación existe en las res-puestas de un valor esperado.

smod(l,m) =

{l if l ≤ m

2

m− l otherwise

(1)

La función smod alcanza su valor máximoen m

2cuando la PUF entrega igual número de

0’s que de 1’s. Conforme las respuestas de laPUF tiendan a un valor estable, ya sea 0 o 1, el

valor de smod decrece. Se construye un vectorZ de la siguiente forma:

Z[j] =

m∑i=1

RMij ∀ j, 1 ≤ j ≤ y (2)

Después se calcula el vector Zp[j] =smod(Z[j],m). Cada posición en Zp mayor acero significa que contiene ruido y dependien-do de su valor es la cantidad de ruido que sepresentó en esa posición. El valor de Zp en ca-da posición cuantifica el ruido observado en lamisma. Para seleccionar las r posiciones a sereliminadas se aplican los criterios siguientes:

• Se determinan como posiciones ruidosasaquellas con un valor Zp > t, donde t esun umbral preestablecido.

• Si en Zp hay menos que r bits con ruido,entonces, se selecciona aleatoriamente losbits que hagan falta para completar los rbits.

• Si existen más de r bits con ruido, enton-ces se eliminan los bits con mayor ruidoy el resto de bits son intercalados entrelas posiciones estables. Lo anterior es útilpara ayudar a la corrección de errores porbloques como se explica más adelante.

No obstante que desde la primera caracteri-zación se puede saber si la respuesta en cadaposición tiende a 0 ó 1, se puede repetir nueva-mente el proceso de muestreo pero se sugieretomar en cuenta solo los x bits seleccionados.Se crea de nueva cuenta un matriz de respues-ta RM pero con x columnas y m filas. SeaZp′[j] =

∑m

i=1RMij ∀ j, donde 1 < j < x .

Construimos ECV como:

ECV [j] =

{1 if Zp′[j] > m

2

0 otherwise

(3)

5. Mejoramiento de la Fiabilidad

A pesar que varios de los trabajos presentanbuenos resultados (con tasas de éxito de hasta


99

el 99% [9] [11]) los decodificadores que uti-lizan resultan ser bastantes costosos para serimplementados en dispositivos restringidos enhardware.

Los códigos Hsiao [5] resultan ser más ade-cuados para ser usados en la regeneración dellaves, ya que las respuestas PUF pueden va-riar su valor en cualquier posición y no haygarantía que no exista un doble error. Utili-zar los códigos Hsiao nos ayudaría a indicar alusuario final que la llave no pudo ser regene-rada y poder tomar una decisión al respecto.

Para un código de Hsiao (n, k), donde n esla longitud de la palabra código y k es nú-mero de bits de datos, el número de bits decontrol s es igual a n− k. Además se debe desatisfacer la condición 2s > k + s + 1. Todoel proceso de codificación y decodificación sebasa en la Hmatriz la cual debe ser construidasegún el tamaño del bloque a corregir y debecumplir las siguientes restricciones: 1) No de-be contener columnas con peso cero. 2) Todaslas columnas deben ser diferentes. 3) Y cadacolumna debe tener un peso impar. Ademásdebe ser construida como lo explicando en [5]:

Hsiao mostró en [5] que construyendo las co-lumnas con el mínimo peso impar (columnascon un número impar de 1’s), el número de 1’sen la Hmatrix puede ser minimizado, es decir,tiene menor cantidad de 1’s en comparacióncon la Hmatrix de un código de Hamming. Es-to se traduce en menos área para el circuitode ECC. Además si se seleccionan estas co-lumnas de manera que exista un balance de1’s entre cada uno de las filas de la Hmatrix,el retardo del circuito decodificador puede serminimizando.

La codificación consiste en calcular los bitsse control s para la longitud de datos k me-diante la siguiente ecuación:

s′i = si

k−1⊕j=0

(k′i ↔ Hmatrix[i][j] = 1) ∀ i (4)

.

En la decodificación las ecuaciones son : ve-rificación (Ecu. 5), Esimple (Ecu. 6), Edoble

(Ecu. 7) y máscara (Ecu. 8).

s′i = si

n−1⊕j=0

(k′i ↔ Hmatrix[i][j] = 1) ∀ i (5)

Esimple =

s−1∨i=0

s′n (6)

Edoble = Esimple + ¬n−1⊕i=0

(s′i) (7)

mascarai =

∧s−1

j=0(s′j ↔ Hmatrix[i][j] = 1

| s′3 ↔ Hmatrix[i][j] = 0).

(8)

5.1. Código Hsiao aplicado a las respues-tas PUF

El problema de utilizar el código Hsiao es quesólo un error puede ser corregido por bloque,y en caso de que existan más de un error nose podría recuperar la respuesta PUF con laque se generó la llave. Las respuestas PUF sonpreferentemente de longitudes en el orden decientos de bits. Si se diseñara un circuito conun tamaño de bloque k muy grande para co-rregir el error, se disminuiría el porcentaje deéxito de regeneración de llave. La solución quese propone es la siguiente:

• Aplicar el proceso de caracterización queplanteamos en la sección 4, el cual, ayu-da a reducir la cantidad de errores que sepueden generar y además en caso de exis-tir más posiciones ruidosas en la respues-ta, éstas son distribuidas uniformementeen el arreglo de PUF.

• Dividir la respuesta PUF en varios blo-ques b y de acuerdo a la distribución delerror que se presente determinar cuál esel tamaño l de bloque adecuado para eltipo de PUF que estamos utilizando.


100

6. Implementación y Resultados

La experimentación fue realizada con diez dis-positivos FPGA Spartan-6 XC6SLX45 (con27488 slices LUTs disponibles) con una tec-nología de 45nm. La plataforma de pruebasconsiste en un arreglo de LUT-PUF dispuestocomo periférico local a un soft-proccesor Mi-croblaze.

El arreglo PUF que fue implementado en laplataforma de pruebas es eficiente en área, yaque para generar un bit de respuesta sólo senecesitan utilizar 2 slices. Para una respuestaPUF de 128 bits aproximadamente se necesi-tan utilizar sólo 256 slices, lo cual, significaque el área total para implementar la PUF esde alrededor de 4% de total del recursos quetiene el FPGA XC6SLX45.

6.1. Proceso de caracterización PUF

Las pruebas realizadas al proceso de caracteri-zación consistieron en obtener como respuestafinal una de tamaño x = 128 bits. Inicialmentecada dispositivo FPGA fue configurado con unarreglo de PUF de 140 bits, es decir, 12 bitsadicionales.

A cada dispositivo se le aplicó m = 200veces el desafío c, las respuestas resultantesfueron almacenadas para el análisis posterior.Con estos datos se genera la matriz RM con140 columnas y 200 filas, la cual, es analizadacomo se describe en la sección 4.

El arreglo de PUFs con un proceso de ca-racterización convencional da una fiabilidaddel 94.21%, mientras que aplicando el procesodescrito en este artículo, la fiabilidad mejorahasta el 98.23%.

Con los resultados obtenidos es fácil ver queen una respuesta de 128 bits hay en promedio3 bits que podrían presentar algún error. Porlo que esto justifica la utilización del móduloECC con el cual se alcanza una fiabilidad de99,4% como se explica más adelante.

6.1.1. Calidad de las respuestas PUF.

No obstante la mejora en la fiabilidad, es con-veniente que las respuestas de la PUF manten-gan otras propiedades relativas a su calidad.

Por lo tanto, se aplicaron las métricas de cali-dad a las respuestas PUF antes y después dela caracterización del dispositivo. En el Cua-dro 3 se presentan los resultados a las métricasevaluadas.

Cuadro 1: Análisis de la calidad de las res-puestas PUF, antes y después de aplicar delproceso de caracterización.(Datos mostradosen porcentaje)

Métrica Antes Después Valorideal

Fiabilidad 94.21 98.23 100Uniformidad 48.43 48.96 50Unicidad 46.32 44.76 50Bit-aliasing 46.96 45.04 50

En el caso de la medida de uniformidad nose encontró alguna variación significativa. Enlos casos de unicidad y bit-aliasing se presentauna pequeña reducción en la métrica la cualse explica ya que se eliminan los bits más ines-tables que favorecen a éstas. Por lo anterior,podemos afirmar después de aplicar el procesode caracterización propuesto que no existe unavariación significativa en la métricas de calidadde las respuestas PUF pero si incremento enla fiabilidad en un 4%.

6.2. Resultados del código Hsiao Codifica-ción/Decodificación

Se realizaron las implementaciones en softwarey en hardware del codificador y decodificadordel código Hsiao para diferentes tamaños debloque k = 8, 16, 32. El objetivo de las imple-mentaciones de software fue conocer la tasa deéxito de correcciones que tiene el decodificadorsegún el tamaño de su bloque. Las implemen-taciones en hardware nos sirvieron para cono-cer los recursos totales requeridos de acuerdocon la longitud del bloque.

De manera analítica se sabe que dependien-do la cantidad de 1’s que tenga cada fila en laHmatriz, se puede conocer el número de nive-les lógicos (Lci) necesarios para garantizar unabuena codificación/decodificación, mediante lafórmula Lci = dlog2(t − 1)e, donde t es justa-mente el número de 1’s en la fila [5]. El número


101

promedio de unos en cada fila de la Hmatriz

fue: 5, 8, 16 para los bloques de tamaño 8, 16,32 respectivamente.

Para el bloque del decodificador se necesi-tan implementar en hardware las ecuaciones:verificación (Ecu. 5), Esimple (Ecu. 6), Edoble

(Ecu. 7) y máscara (Ecu. 8). El número deentradas para calcular las ecuaciones de veri-ficación es igual al número de unos en cadafila en la Hmatriz más un bit que correspon-de al síndrome. Para calcular las ecuacionesEsimple, Edoble y máscara; el número de entra-das depende directamente del número de bitsdel síndrome.

Dado que el FPGA que seleccionamos tieneLUTs de seis entradas, en el Cuadro 2 presen-tamos el análisis del número de slices LUTsnecesarias para poder implementar el módu-lo ECC dependiendo del tamaño del bloque.Todas las ecuaciones en donde el número deentradas sean hasta seis se pueden sintetizaren una sola LUT. Si la ecuación excede de seisentradas entonces se necesita una LUT extra.Una respuesta de 128 bits se divide en 16, 8 y4 bloques de acuerdo con la longitud del blo-que. Los datos anteriores mantienen la mismaproporción con respecto al tamaño del bloquey el número de bloques utilizados. La canti-dad de recursos para decodificar la respuestade 128 bits es de: 240 LUTs para k = 8, 240LUTs para k = 16 y 356 LUTs para k = 32.

Cuadro 2: Análisis de consumo de área paraun bloque ECC. a) Verificación, b) Esimple, c)Edoble, d) Máscara, e) Bloque ECC

Slices LUTs

Tamaño del bloque a b c d e

8 5 1 1 8 1516 12 1 1 16 3032 21 2 2 64 89

Otro aspecto importante a evaluar es la efi-ciencia del ECC para recuperar correctamen-te los 128 bits. Denominamos regeneración co-rrecta, al hecho que no importando el númerode bloques de ECC en que se divide la res-puesta, el módulo ECC es capaz de corregir

los errores detectados en cada bloque. Bastasólo un bloque con doble error para marcar laregeneración como fallida. El Cuadro 3 presen-ta el porcentaje de generaciones de respuestacompletamente correctas, siendo el bloque detamaño k = 8 el que mejor resultados presentay el de k = 32 el peor. Esto indica que entremás pequeño sea el tamaño del bloque la pro-babilidad de obtener siempre una regeneraciónde respuesta exitosa es mayor.

Cuadro 3: Resultados de la implementación enhardware del módulo ECC. Se presentan datospara un arreglo PUF de 128 bits.

Slices LUTs

Tamaño Bloque Arreglo %del bloque ECC ECC Éxito

8 15 250 99.416 32 256 98.3632 62 244 95.17

El Cuadro 3 también muestra los resultadosobtenidos con la herramienta de síntesis parala implementación del cada tamaño de bloquey para corregir un arreglo de 128 bits. Conrespeto al área, los bloque de tamaño 8 y 16consumen 250 y 256 LUTs, respectivamente.Los bloques de 32 bits utilizan menos área pe-ro presentan una reducción significativa en laregeneración de llaves. Se nota que hay unadiferencia entre el área estimada de maneraanalítica (en el Cuadro 2) y la obtenida ex-perimentalmente (presentada en el Cuadro 3),esto se debe a que la herramienta de síntesishace optimizaciones para reducir el hardware,en el caso particular del decodificador de 32bits, en las ecuaciones hay varios términos encomún, los cuales son reutilizados en lugar deinstanciar más hardware.

6.3. Generación de llaves criptográficas

Para generar de llaves criptográficas PUF se-guras se debe tomar en cuenta la fuga de infor-mación que se presenta al conocer el síndromede la respuesta, toda vez que éste proporcionainformación acerca ésta. En [3] [9] se analizó


102

Cuadro 4: Resumen de resultados de la genera-ción de llaves criptográficas con al menos 128bits de seguridad.

Tamañode bloque

8 16 32

PUFs bits 344 208 192Bits de síndrome 215 78 42Bits de seguridad 129 130 150Área PUF (Slices) 688 416 384Área ECC (Slices) 675 430 366Área Total (Slices) 1363 846 750% Éxito 99.4 98.3 95.2

de manera formal la fuga de información delas respuestas PUF cuando se conoce a prioriel síndrome s. De cada longitud de bloque k,se pueden inferir hasta s bits los cuáles corres-ponden al síndrome.

Los datos del Cuadro 4 muestran un resu-men de los resultados obtenidos en este traba-jo para generar llaves criptográficas con un ni-vel de seguridad de al menos 128 bits. Se puedeobservar que entre más pequeño es el tamañodel bloque más es la cantidad de hardware quese necesita ya que el compromiso entre el nú-mero de bits del síndrome s y la cantidad dedatos k codificados es mayor, lo cual provo-ca que exista una gran cantidad de fuga deinformación y se tenga que generar más blo-ques para satisfacer la condición mínima debits de seguridad. Si bien el uso de un bloquede 32 bits resultó en un arreglo más compactotambién resultó detener menor fiabilidad. Enpromedio, cinco de cada cien regeneracionesde llave será fallida. Por otra parte, solamenteseis de cada mil regeneraciones de llave falla-rán en promedio mediante un bloque de 8 bitsa costa de un arreglo que consume 81% másárea que el uso de un bloque de 32 bits.El esquema final de regeneración de llave crip-tografía es el mostrado en la Figura 2, utili-zamos un arreglo de 208 bits de LUT-PUF, elcual junto con 78 bits de síndrome, son las en-tradas al decodificador Hsiao que se encargade detectar si hay algún error y corregirlo y su

salida es introducida a la función hash Quarkque reduce la cantidad de bits a 136 bits.

LUT PUF

Key

Syndrome

Challenge

Decodificador

Hsiao

Response

Quark

208 bits

78 bits 208 bits 136 bits

Figura 2: Esquema final de regeneración de llavescriptográficas basado en PUF con al menos 130bits de seguridad.

7. Conclusiones

En este trabajo se buscó formas de reducir lacomplejidad (en el uso de recursos de hardwa-re) que implica la implementación de mecanis-mos para mejorar la fiabilidad de las respues-tas PUF. El análisis de las respuestas duranteel proceso de caracterización PUF propuestoen este artículo muestra que es posible redu-cir el número de errores que se generan en lasrespuestas de PUF y aplicar los algoritmos decorrección de errores de bajo costo.

Los datos del porcentaje de éxito muestranque los bloques de tamaño menor tienen me-jores resultados. En realidad la selección deltamaño del bloque depende directamente delas restricciones que se tengan. En nuestro ca-so seleccionamos un tamaño bloque de 16 bits,ya que es el que presenta un mejor compro-miso entre área de hardware y porcentaje deéxito de generación de llave. Nuestro esquemade generación de llaves criptográficas tiene unatasa de éxito muy buena (desde 95,17% hasta99,4%).

Referencias

[1] Jason H. Anderson. A PUF design forsecure FPGA-based embedded systems.In ASPDAC ’10: Proceedings of the 2010Asia and South Pacific Design Automa-tion Conference, pages 1–6, Piscataway,NJ, USA, 2010. IEEE Press.

[2] Christoph Bösch, Jorge Guajardo,Ahmad-Reza Sadeghi, Jamshid Shokro-llahi, and Pim Tuyls. Efficient Helper


103

Data Key Extractor on FPGAs. In CHES’08: Proceeding sof the 10th internationalworkshop on Cryptographic Hardwareand Embedded Systems, pages 181–197,Berlin, Heidelberg, 2008. Springer-Verlag.

[3] Yevgeniy Dodis, Rafail Ostrovsky, LeonidReyzin, and Adam Smith. Fuzzy Extrac-tors: How to Generate Strong Keys fromBiometrics and Other Noisy Data. SIAMJ. Comput., 38(1):97–139, March 2008.

[4] Jorge Guajardo, Sandeep S. Kumar,Geert-Jan Schrijen, and Pim Tuyls. FP-GA Intrinsic PUFs and Their Use forIP Protection. In CHES ’07: Procee-dings of the 9th international workshopon Cryptographic Hardware and Embed-ded Systems, pages 63–80, Berlin, Heidel-berg, 2007. Springer-Verlag.

[5] M. Y. Hsiao. A class of optimal mini-mum odd-weight-column SEC-DED co-des. IBM J. Res. Dev., 14(4):395–401,July 1970.

[6] S.S. Kumar, Jorge Guajardo, Roel. Maes,G.-J. Schrijen, and Pim. Tuyls. Exten-ded abstract: The butterfly PUF protec-ting IP on every FPGA. In Hardware-Oriented Security and Trust, 2008. HOST2008. IEEE International Workshop on,pages 67 –70, 9-9 2008.

[7] Jae W. Lee, Daihyun Lim, Blaise Gas-send, G. Edward Suh, Marten Van Dijk,and Srini Devadas. A technique to builda secret key in integrated circuits withidentification and authentication applica-tions. In In Proceedings of the IEEE

VLSI Circuits Symposium, pages 176–179, 2004.

[8] Daihyun Lim. Extracting Secret Keysfrom Integrated Circuits. Master’s thesis,MIT, USA, 2004.

[9] Roel Maes, Anthony Herrewege, and In-grid Verbauwhede. PUFKY: A Fully Fun-ctional PUF-Based Cryptographic KeyGenerator. In Emmanuel Prouff and Pa-trick Schaumont, editors, CHES 2012:Proceedings of the 14th internationalworkshop on Cryptographic Hardware andEmbedded Systems, volume 7428 of Lectu-re Notes in Computer Science, pages 302–319. Springer Berlin Heidelberg, 2012.

[10] Roel. Maes, P. Tuyls, and I. Verbauw-hede. A soft decision helper data al-gorithm for sram pufs. In InformationTheory, 2009. ISIT 2009. IEEE Interna-tional Symposium on, pages 2101–2105,July 2009.

[11] S. Pappala, M. Niamat, and WeiqingSun. FPGA based trustworthy authenti-cation technique using Physically Unclo-nable Functions and artificial intelligence.In Hardware-Oriented Security and Trust(HOST), 2012 IEEE International Sym-posium on, pages 59 –62, june 2012.

[12] G. Edward Suh and Srinivas Devadas.Physical unclonable functions for deviceauthentication and secret key generation.In DAC ’07: Proceedings of the 44th an-nual Design Automation Conference, pa-ges 9–14, New York, NY, USA, 2007.ACM.


104

Ataques por canal lateral sobre el algoritmo de encriptación AES implementado en MicroBlaze

Rubén Lumbiarres-López(1), Mariano López-García (1), Enrique F. Cantó-Navarro(2) [email protected], [email protected], [email protected]

(1) Universidad Politécnica de Cataluña, Vilanova i la Geltrú. (2) Universidad Rovira i Virgili, Tarragona.

Resumen Este artículo presenta un procedimiento simple para la obtención de la clave criptográfica del algoritmo AES ejecutado sobre MicroBlaze. La clave se obtiene analizando la correlación estadística que existe entre ésta y el consumo del dispositivo hardware que ejecuta el propio algoritmo. El trabajo también muestra como las contramedidas clásicas de enmascarado del texto plano son únicamente eficientes frente ataques de primer orden. Los resultados experimentales muestran diferentes ataques realizados sobre varios bloques del algoritmo, y concluyen que es posible obtener la clave criptográfica tomando un número de trazas de corriente inferior a 40.

1. Introducción

A finales de la década de los 90, Kocher et al. [1] publican un artículo que describe cómo obtener la clave de un algoritmo criptográfico analizando el consumo de corriente del dispositivo hardware que lo implementa. La información de la clave, que se filtra a través de este consumo, se utiliza para realizar los denominados ataques por canal lateral (Side Channel Attacks). Estos ataques, además de ser conceptualmente muy sencillos, necesitan de equipos de captura y procesado relativamente baratos. Si bien los autores demostraron su teoría aplicándola sobre el algoritmo de encriptado DES (Data Encryption Standard), en la actualidad el mismo procedimiento se ha aplicado con éxito sobre otros algoritmos criptográficos de clave privada [2]. Sin embargo, y probablemente debido a su elevada seguridad, la mayoría de artículos se han centrado en el algoritmo de cifrado por bloques AES (Advanced Encryption Standard). Desde su

adopción como estándar por parte del NIST, este algoritmo ha experimentado una creciente popularidad, siendo utilizado como base para el encriptado de documentos oficiales tanto por parte de la National Security Agency (NSA) como por el propio gobierno de los EUA [3]. La implementación del algoritmo AES se ha realizado básicamente sobre dos plataformas: ejecución software sobre microprocesador; o bien implementación hardware sobre ASICs o FPGA [4][5]. Las implementaciones hardware han tratado de diseñar sistemas cuya arquitectura interna disminuya o elimine la correlación entre el consumo energético del dispositivo y la propia clave. Sin embargo, son las implementaciones software las más utilizadas, debido a su sencillez y al uso extendido que han supuesto las tarjetas inteligentes basadas en microprocesador. Ello justifica el uso, en muchas publicaciones, de la familia 8051 de Intel o arquitecturas basadas en procesadores ARM. Por otra parte, las implementaciones sobre FPGA son generalmente adaptaciones de las estructuras a medida propuestas para sistemas ASIC, acordes con los recursos particulares de la FPGA. No obstante, la utilización de procesadores soft-core que implementen sobre este dispositivo el mismo algoritmo es más bien escasa [6]. Este artículo presenta un estudio sobre el comportamiento del microprocesador MicroBlaze frente a ataques por canal lateral aplicados sobre el algoritmo de encriptado AES. El estudio muestra la vulnerabilidad de MicroBlaze frente a ataques de primer y segundo orden utilizando diferentes modelos de consumo y contramedidas. El artículo se ha organizado en cinco secciones. La sección 2 describe las bases teóricas de los ataques por canal lateral. La sección 3 muestra una de las contramedidas más eficaces frente a este tipo de ataques. La sección 4 presenta


105

los resultados experimentales que validan las hipótesis realizadas en las secciones anteriores y finalmente se muestran las conclusiones del trabajo.

2. Ataques por canal lateral

2.1. Algoritmo AES

La figura 1 muestra el esquema clásico de un sistema criptoprocesador. El texto codificado de la salida se obtiene aplicando un algoritmo de encriptado sobre el texto plano de entrada.

Figura 1. Esquema de un criptoprocesador.

La fortaleza del sistema reside en que a nivel teórico es imposible obtener el texto original a partir de la versión codificada sin conocer previamente la clave criptográfica. AES es un algoritmo simétrico, es decir, utiliza la misma clave para el encriptado del texto plano y el desencriptado del texto codificado. Otra particularidad es que realiza un cifrado por bloques de longitud fija, igual a la longitud de la clave, que puede ser de 128, 192 ó 256 bits. La figura 2 muestra el diagrama de bloques para la versión de 128 bits utilizada en este artículo. El algoritmo se caracteriza por aplicar varias funciones de sustitución y permutación sobre un bloque de 128 bits, denominado estado, que inicialmente es fruto de la combinación del texto plano con la clave. Dichas funciones se aplican sobre el estado de forma repetitiva durante varias iteraciones llamadas rondas. En cada ronda, el estado resultante se vuelve a combinar con una nueva clave obtenida a partir de la original (expansión de la clave). Una descripción detallada de la función que realiza cada uno de los bloques, o sobre el algoritmo de expansión de la clave, puede encontrarse en [3].

Desde una perspectiva de ataques por canal lateral los bloques más importantes son AddRoundKey y SubBytes. El primero es simplemente el operador lógico XOR a nivel de bit. El segundo es una función no lineal que opera

sobre cada uno de los 16 bytes que componen el estado. La forma más sencilla de implementar la función SubBytes es mediante una tabla de consulta de 256 elementos, que se invoca 16 veces en cada una de las rondas que componen el algoritmo.

Figura 2. Diagrama de bloques para AES 128 bits.

En el caso de una implementación software, es interesante observar que en primera ronda la primera llamada a la función SubBytes opera solamente sobre los 8 bits menos significativos (LSB) del estado. Dicho bits dependen a su vez de los 8 bits LSB del texto plano y de los 8 bits LSB asociados con la clave criptográfica.

2.2. Modelo de consumo

El ataque por canal lateral presupone que el atacante dispone de un modelo teórico que describe el consumo de corriente del dispositivo electrónico. Dicho modelo suele obtenerse a partir de una generalización del modelo de consumo simple asociado a un inversor CMOS (figura 3). La capacidad Co representa la capacidad parásita conjunta generada por los transistores y la impedancia de entrada asociada a otras puertas lógicas conectadas a Vo. Cuando la salida transita de nivel bajo a nivel alto (0→1), la fuente Vdd suministra una corriente idd que carga el condensador parásito. Cuando se produce una transición de nivel alto a nivel bajo (1→0), el condensador se descarga a través del transistor de canal N. Asimismo, en ambas transiciones se produce la conducción simultánea de ambos transistores, lo que genera una corriente de cortocircuito que también es suministrada por la fuente Vdd.


106

Figura 3. Modelo de consumo de un inversor CMOS.

Este modelo tiene en cuenta sólo el consumo dinámico de potencia, y considera despreciable el consumo estático debido a las corrientes de fugas. Aún así, el modelo suele considerarse bastante adecuado, de modo que suele extrapolarse a otras celdas lógicas implementadas con tecnología CMOS. Por otro lado, dado que un circuito CMOS genérico estará constituido por varias celdas lógicas, el consumo total podrá aproximarse como la suma de los consumos individuales de cada una de estas celdas. Con estas premisas, en la literatura específica suelen considerarse dos modelos de consumo diferentes:

Modelo de pesos de Hamming (HW). Considera el consumo total como la suma de 1’s (ó 0’s) presentes en la salida de las celdas lógicas. Es un modelo muy simple, que es adecuado en microprocesadores que precargan el bus de datos a un valor conocido. En estos sistemas, antes de leer o escribir un dato sobre el bus, éste se coloca a 0 (ó 1) lógico.

Modelo basado en la distancia de Hamming (HD). Este modelo asigna el mismo consumo tanto a las transiciones de 0→1 como de 1→0. Obsérvese que si u1 y u2 son el valor previo y posterior asociado a un conjunto de celdas lógicas, respectivamente, entonces HD=HW(u1 XOR u2). Este modelo refleja con bastante acierto el consumo energético descrito anteriormente para la tecnología CMOS. Sin embargo, el modelo sólo es aplicable en aquellos casos donde sea posible conocer el valor de u2. Por otro lado, nótese que cuando u1 es igual a 0 los modelos HD y HW son coincidentes.

El funcionamiento interno de MicroBlaze fuerza un cero en el bus de datos cuando el dato de lectura desde memoria interna BRAM no se encuentra disponible (precarga del bus a valor 0 lógico). Está característica hace que el modelo de consumo basado en los pesos de Hamming sea el

más adecuado para describir el consumo de potencia del microprocesador.

2.3. Fundamentos del ataque estadístico

El ataque por canal lateral explota la correlación que existe entre el consumo de potencia del dispositivo y los datos y operaciones que se realizan durante la ejecución del algoritmo AES. Por ejemplo, la figura 4 muestra el consumo de potencia real asociado con un microprocesador PIC de Microchip. Nótese como claramente el consumo es diferente en función del dato que se escribe (lee) sobre el bus.

Figura 4. Consumo de potencia en microprocesador.

El proceso de ataque para descubrir la clave se realiza siguiendo los pasos que se detallan a continuación:

1. Se elige un punto de ataque centrado en uno de los bloques descritos en la figura 2. Uno de los puntos más vulnerables es la salida del bloque SubBytes en primera ronda, dado que éste procesa únicamente un byte del texto plano y de la clave criptográfica.

2. Se captura un número L de trazas de corriente asociadas con el consumo de potencia generado durante la ejecución de SubBytes. Cada una de las trazas Tj (j=1..L) se corresponde con un texto plano conocido por el atacante.

3. Las trazas se comprimen para simplificar el proceso de cálculo. En nuestro caso, cada uno de los M ciclos de reloj que contiene la traza se representa por un único punto, que corresponde al valor medio asociado con el consumo en dicho ciclo. Se escoge un punto tc asociado con el ciclo que desea atacarse. Se genera un nuevo vector Ttc,


107

de longitud L, formado por los puntos tc de todas las trazas de corriente capturadas.

4. Dado que la función SubBytes se aplica sobre un sólo byte de la clave, existen 256 posibilidades. Para cada una de estas 256 posibilidades, y dado que el atacante conoce el texto plano, se calcula el modelo de consumo teórico (pesos de Hamming) Hk (k=1..256) para cada uno de los L puntos del vector Ttc.

5. Para cada modelo Hk se calcula la correlación ρ existente entre éste y el vector Ttc..

6. El byte correcto de la clave será aquel cuyo coeficiente de correlación ρ sea el mayor.

7. El proceso se repite para cada uno de los 15 bytes restantes de la clave.

3. Contramedidas frente a ataques por canal lateral

3.1. Enmascaramiento del texto plano

El éxito del proceso de análisis por canal lateral se debe, en parte, a que se ataca un sólo byte de la clave. De esta forma el número de posibilidades se reduce a 28 frente a las 2128 que supondría un ataque por fuerza bruta. Sin embargo, la seguridad del sistema se rompe, principalmente, por la correlación que existe entre el consumo de corriente y el procesado del texto plano junto con la clave criptográfica. La idea que subyace detrás de una contramedida es precisamente disminuir o incluso eliminar dicha correlación.

Una contramedida muy utilizada consiste en combinar cada byte del texto plano con una máscara utilizando una XOR a nivel de bit.

Figura 5. Enmascaramiento lógico con operador XOR a nivel de bit.

Como muestra la figura 5, el algoritmo AES procesa el texto enmascarado. Posteriormente, cada byte de salida se combina nuevamente con la

misma máscara y el operador XOR, obteniéndose el texto codificado. Nótese que, dado que AES procesa un texto enmascarado, no existe correlación entre el texto plano real y el consumo de potencia que se origina durante la ejecución del algoritmo [2]. Este planteamiento funciona correctamente si se cumple:

m )(m) ( TAESTAES outout (1)

La ecuación (1) se cumple si todas las operaciones llevadas a cabo por todos los bloques F (véase figura 2) que forman el algoritmo AES satisfacen la siguiente expresión:

m )(m) ( InputFInputF outout (2)

La ecuación (2) se cumple en las funciones lineales AddRoundKey, ShiftRows y MixColumns. Sin embargo, y debido a su no linealidad, la función SubBytes no satisface esta condición. El problema se resuelve modificando dicha función de modo que satisfaga la siguiente igualdad:

m )(m) ( InSubBytesIndSubBytesMo (3)

siendo In el dato de entrada. Substituyendo ahora SubBytes por SubBytesMod en la figura 2, la ecuación (1) se satisface y permite ejecutar el algoritmo de forma segura. Por otra parte, la máscara se cambia aleatoriamente cada vez que se ejecuta un proceso de encriptado, lo que garantiza la independencia estadística entre la clave y el consumo de corriente del dispositivo.

No obstante, tal y como veremos en el punto 3.2, pueden llevarse a cabo ataques más complejos que exploten la probabilidad conjunta de dos o más puntos de la traza de corriente. En la literatura se conocen como ataques de orden N, siendo N el número de puntos que se toman (procesan) en la traza (comprimida). Los sistemas que utilizan una sóla máscara son seguros frente a ataques de primer orden. Chari et al. [7] generalizan esta conclusión y demuestran teóricamente que los esquemas que utilizan N máscaras diferentes están protegidos frente a ataques de orden N. Obviamente, a medida que el orden aumenta la complejidad del ataque también lo hace, dado que es necesario escoger no sólo qué puntos de la traza son los más adecuados, sino también cómo procesarlos para deshacer el efecto del enmascaramiento. En general, se consideran


108

únicamente factibles a nivel práctico los ataques de primer y segundo orden [8].

3.2. Ataque estadístico de segundo orden

Los ataques por canal lateral de segundo orden consisten en tomar dos puntos de la traza de corriente y procesarlos, de tal forma, que al resultado de dicho procesado pueda aplicársele el procedimiento descrito en la sección 2.3 (ataque de primer orden). Por tanto, antes de aplicar este procedimiento es necesario determinar el tipo de procesado a aplicar, los puntos a procesar y el modelo de consumo a utilizar.

Sean um y vm los valores enmascarados asociados a los dos puntos intermedios que desean procesarse. Sus respectivos valores sin enmascarar se denotan por u y v, de modo que um=u m y vm=v m. Considerando válido el modelo de consumo basado en los pesos de Hamming (HW), y dado que los datos han sido enmascarados con el operador lógico XOR a nivel de bit, se tiene que:

v)() v( m uHWuHW m (4)

es decir, el consumo teórico para la combinación mediante el operador XOR de los datos enmascarados y sin enmascarar es coincidente. La expresión (4) se toma como modelo de consumo y se utiliza para el cálculo del coeficiente de correlación. Nótese que es necesario disponer de un modelo de consumo basado en el texto plano original (sin enmascarar), dado que ésta es la única información conocida por parte del atacante.

Los puntos a atacar suelen ser la entrada y la salida de la función SubBytes (modificada) en primera ronda. Una de las razones que justifica esta elección se debe a que el código asociado con ambos puntos se ejecuta prácticamente de forma consecutiva, lo que simplifica el proceso de captura del tramo de interés de la traza de corriente.

A continuación debe tomarse una función que procese los puntos ti y tk seleccionados en la traza Tj (j=1..L). Esta función debe poseer un grado de correlación significativo con respecto al modelo de consumo descrito en (4). En este artículo se ha tomado la función propuesta por Messerges et al. en [9], cuyo procesado se basa en calcular el

valor absoluto de la diferencia entre los consumos en ambos puntos:

))(t-)(t(_ ki jj TTabsprocesadoF (5)

El resultado de la expresión (5), aplicado sobre cada una de las L trazas, se utiliza para determinar el vector Ttc. Finalmente, se aplican los pasos 4 al 8 del proceso descrito en la sección 2.3 para averiguar la clave correcta. El éxito de este proceso requiere del conocimiento ajustado de los puntos ti y tk. Cuando estos puntos son desconocidos, el proceso de atacado se aplica sobre todos los pares de puntos que surgen de realizar todas las combinaciones posibles entre los puntos que componen la traza. Cada una de estas combinaciones se denomina segmento.

4. Resultados experimentales

Los resultados experimentales se han obtenido utilizando la placa de desarrollo Sasebo G-II. Esta placa está especialmente diseñada para llevar a cabo ataques por canal lateral. Contiene una Virtex 5 que se ha utilizado para implementar el sistema. Dispone de reguladores lineales y masa aislada que permite la captura de trazas de corriente con bajos niveles de ruido. La frecuencia de trabajo es de 24 MHz. Las medidas de corriente del núcleo lógico se han realizado mediante una sonda Tektronic CT-1, que ofrece un ancho de banda comprendido entre 25 kHz a 1 GHz. El osciloscopio empleado, que a la vez realiza la función de captura, es un Agilent DSO1024A con una velocidad de muestreo en tiempo real de 2 GSa/s por canal. La figura 6 muestra una imagen real del sistema completo.

Figura 6. Imagen del banco de pruebas utilizado en la experimentación.


109


110

256 posibilidades del primer byte asociado con la clave. Las figuras se corresponden con sendos ataques realizados sobre las salidas de la función SubBytes y AddRoundKey, respectivamente, sin utilizar ningún tipo de contramedida. Las figuras muestran los coeficientes de correlación en función del número de trazas capturadas para efectuar el proceso de atacado. Se observa que la salida de la función SubBytes permite diferenciar perfectamente la clave correcta del resto, obteniéndose un coeficiente de correlación cercano a la unidad (ρ=0.9). La salida de la función AddRoundKey también ofrece un coeficiente bastante alto, siendo sin embargo menos distinguible respecto al resto de claves. Este comportamiento tan diferente entre ambas funciones se debe a la no linealidad asociada a la función SubBytes. Esta función se comporta de modo que datos muy similares a su entrada generan salidas muy diferentes, lo que permite distinguir claves muy parecidas. Sin embargo, la función AddroundKey no genera estos cambios tan significativos. Por ejemplo, una variación de un bit en su entrada provocaría la variación de 1 sólo bit en su salida. Por otro lado, obsérvese, que para el primer caso es suficiente con tomar 40 trazas de corriente para averiguar la clave correcta.

4.2. Sistema con enmascaramiento de datos

Las figuras 7.b y 8.b muestran el coeficiente de correlación correspondiente a ataques realizados sobre la salida de las mismas funciones, pero utilizando un texto plano previamente enmascarado. Tal y como era de esperar, en ambos casos un ataque estadístico de primer orden falla. Como puede observarse el coeficiente de correlación mayor se corresponde en ambos casos con una clave incorrecta.

4.3. Ataque por canal lateral de orden 2

Este apartado muestra cómo efectivamente el ataque por canal lateral de orden 2 es capaz de romper la seguridad del sistema enmascarado. La traza de corriente capturada contiene el procesado de la entrada y salida de la función SubBytes. Esta traza contiene 67 ciclos de reloj, que dan lugar a 2211 posibles combinaciones (segmentos) entre los puntos ti y tk. La figura 9.a

muestra la correlación obtenida para cada uno de estos segmentos. Se observa que el segmento que ofrece la máxima correlación es el 799. La figura 9.b representa la evolución del coeficiente de correlación en función del número de trazas para el segmento 799. Nótese que el coeficiente de correlación relacionado con la clave correcta tiene un valor aproximado de ρ=0.22, suficiente como para poder distinguirlo del resto de claves. También se observa que el número mínimo de trazas de corriente para obtener la clave correcta es de 300. En comparación con el sistema sin enmascarar, el número mínimo de trazas se incrementa en 7.5 veces mientras que el coeficiente de correlación se reduce un 75%.

4.4. Tiempos de ejecución y procesado

El tiempo de ejecución del algoritmo AES sin enmascarar es de 1.116 ms, mientras que la versión con máscara se ejecuta en 1.480 ms. Es decir, el cálculo de la función SubBytes modificada, junto con la aplicación del operador XOR en la entrada y salida de AES, tarda 364 µs. Una versión software más elaborada debería incluir también el tiempo necesario para el cálculo aleatorio de la máscara. Por otro lado, una vez adquiridas todas las trazas, el tiempo total necesario para procesarlas es de 0.91 s/traza (ataque de 2do. orden y considerando únicamente el primer byte de la clave). Este tiempo se ha obtenido programando el algoritmo descrito en la sección 2.3 en MATLAB, y ejecutándolo sobre un ordenador a 2.66 GHz y una memoria RAM de 3 GB. La tabla I describe con detalle los tiempos de captura y procesado relacionado con las funciones principales.

Función Tiempo (1er. byte de la clave)

Captura 512 trazas 454,17 s Compresión 512 trazas 0,857 s DPA 1er. orden 0,650 s DPA 2do. orden 10,67 s

Tabla I. Tiempos de captura y procesado.

5. Conclusiones

Este artículo ha mostrado un procedimiento para la realización de ataques por canal lateral sobre


111

MicroBlaze. Se han descrito los principios teóricos que fundamentan el proceso de ataque estadístico, basado en la medida de la correlación, aplicado sobre el algoritmo AES. Los resultados experimentales muestran como el posible obtener la clave criptográfica tomando un número de trazas igual a 40. Cuando el sistema se protege utilizando una contramedida basada en el enmascaramiento del texto plano el sistema es inmune a ataques de primer orden. No obstante, se ha demostrado que el sistema con enmascaramiento es vulnerable a ataques de segundo orden tomando un número de trazas de corriente igual a 300.

Referencias

[1] Paul C. Kocher, Joshua Jaffe, and Benjamin Jun. Differential Power Analysis. Advances in Cryptology – Proceedings of Crypto 1999, Lecture Notes in Computer Sicence, vo. 1666, Springer – Verlag, 1999, pp. 338-397.

[2] Stefan Mangard, Elisabeth Oswald and Thomas Popp. Power analysis attacks: Revealing the secreets of smart cards. Springer, 2007.

[3] Joan Daemen and Vincent Rijmen. The Design of Rijndael: AES - The Advanced Encryption Standard. Springer-Verlag, 2002.

[4] Kris Tiri and Ingrid Verbauwhede. A Logic Level Design Methodology for a Secure DPA Resistant ASIC or FPGA Implementation. Design, Automation and Test in Europe Conference and Exposition, 2004, vol. 1, pp. 246-251.

[5] Kris Tiri and Ingrid Verbauwhede. Secure Logic Sysntesis. Field Programmable Logic and Application, 14th International conference, FPL 2004, pp. 1052-1056.

[6] A. Klimm, O. Sander and J. Becker. A MicroBlaze specific co-processor for real-time hyperelliptic curve cryptography on Xilinx FPGAs. Parallel & Distributed Processing IPDPS 2009. IEEE International Symposium. 2009, pp. 1-8.

[7] Suresh Chari, Charanjit S. Jutla, Josyula R. Rao, and Pankaj Rohatgi. Towards Sound Approaches to Counteract Power-Analysis Attacks. 19th Annual International Cryptology conference CRYPTO’99. 1999. pp. 398-412.

[8] Jiquiang Lu, jing Pan, and Jerry den Hartog. Security of AES Against First and Second-Order Differential Power Analysis. ACNS'10 Proceedings of the 8th international conference on Applied cryptography and network security. Springer-Verlag 2010, pp. 168-185.

[9] Thomas S. Messerges. Using Second-Order Power Analysis to Attack DPA Resistant Software. Cryptographic Hardware and Embedded Systems — CHES 2000 Lecture Notes in Computer Science Volume 1965, 2000, pp 238-251.


112

Silvia Alcázar, Almudena Alonso, Beatriz Álvarez-Buylla, Felipe Serrano y Juan Antonio Clemente

Resumen—Las FPGAs basadas en memoria SRAM presentan una combinación atractiva entre alto rendimiento y flexibilidad, lo cual les ha hecho muy interesantes para su uso en algunos sectores como el aeronáutico y aeroespacial, en los cuales la tolerancia ante los fallos resulta primordial. Sin embargo, en estos entornos, los dispositivos están expuestos a altas dosis de radiación, que se encuentra presente de manera natural. Esta radiación puede inducir la aparición de Single Event Upsets (SEUs), los cuales consisten en modificaciones del contenido de la memoria de configuración de los dispositivos. Por ello, es necesario estudiar técnicas para proteger los diseños de alteraciones producidas por la radiación y sus consecuencias.

En este artículo comparamos distintas técnicas para protección de circuitos basadas en Triple Modular Redundancy (TMR), que permiten enmascarar y corregir los fallos de los circuitos. Para comparar los resultados hemos hecho modificaciones sobre NESSY, una plataforma de inyección de SEUs previamente desarrollada por nuestro grupo de investigación, que permite emular el efecto producido por un SEU sobre circuitos implementados en FPGAs de tipo Xilinx™ Virtex 5. Las técnicas de triplicación propuestas reducen la probabilidad de incidencia de un SEU en dos órdenes de magnitud.

Palabras clave—FPGA, protección, SEU, TMR.

I. INTRODUCCIÓN

AS FPGAs (Field Programmable Gate Arrays)surgen en 1984 como una evolución de los CPLDs

(Complex Programmable Logic Devices). En ellas aumenta el número de puertas lógicas equivalentes respecto a los CPLDs, así como su flexibilidad. Otra diferencia importante es que en las FPGAs se pueden encontrar componentes empotrados que realizan operaciones de gran complejidad, como multiplicadores o DSPs (Digital Signal Processors), así como bloques de memoria.

Este tipo de dispositivos tiene las siguientes ventajas: diseño sencillo, alto rendimiento, tiempo de desarrollo menor que en otros dispositivos, fiabilidad, ahorro en coste (tanto de desarrollo como de adquisición), reprogramación (lo que añade flexibilidad), y seguridad. Todas estas características han hecho que las FPGAs, y en especial las FPGAs basadas en memoria SRAM (SRAM-FPGAs) hayan adquirido especial relevancia en los sectores aeronáutico y aeroespacial. El principal motivo es que los dispositivos utilizados en satélites y aviones tienen que procesar mucha información a bordo antes de mandarla a la Tierra, debido al reducido ancho de banda en el canal de comunicación que conecta ambos. También han tenido un importante auge para su uso en las aplicaciones nucleares, cuyas restricciones son de tiempo real.

Sin embargo, con el aumento de su uso, también se ha producido un incremento de la preocupación por los efectos que la radiación puede causar sobre las mismas [1], [2]. En particular, los errores que más comúnmente se suelen encontrar son los Single Event Upsets (SEUs), que habitualmente se producen por el impacto de una partícula cósmica al colisionar con el dispositivo. Un SEU consiste en la alteración de, al menos, una celda de memoria de la FPGA. Así, un SEU que incida en la memoria SRAM de configuración del dispositivo puede alterar por completo la funcionalidad del dispositivo y así provocar fallos en su ejecución.

Por este motivo, se han desarrollado multitud de técnicas de protección de circuitos. Entre ellas, una técnica muy utilizada es la TMR [3], [4], (Triple Modular Redundancy), que consiste en replicar el circuito tres veces y procesar las tres salidas, introduciéndolas en un votador para generar una sola salida que será la entrada que más veces se repita. Esto permite enmascarar un gran número de fallos.

En este artículo presentamos dos técnicas de protección de circuitos implementados en FPGAs frente a SEUs, basadas en TMR. La primera técnica que hemos desarrollado ha sido una aproximación simple consistente en sintetizar e implementar las tres instancias del circuito junto con el votador en la misma Región Parcialmente Reconfigurable (RPR) de la FPGA. Esta técnica nos ha permitido reducir de forma considerable el porcentaje de errores encontrados en el circuito triplicado respecto al circuito sin triplicar.

Sin embargo, la tasa de SEUs que provocan error en el circuito así triplicado aún es demasiado alta con respecto a los resultados obtenidos mediante esta técnica en trabajos anteriores para otros tipos de circuitos, como ASICs [3], [4]. El motivo es que en nuestro caso, un solo SEU puede afectar a varias instancias del circuito, al estar implementadas éstas físicamente en la misma RPR.

Por ello, hemos diseñado una segunda técnica de protección de circuitos consistente en implementar las tres instancias del circuito en RPRs diferentes. De esta manera, los errores producidos por SEUs inyectados en una RPR no tienen consecuencias en las instancias del circuito restantes, así como en el votador. Esto ha permitido reducir la probabilidad de incidencia de un SEU en los circuitos en dos órdenes de magnitud frente a implementaciones equivalentes de los circuitos que no presentan ningún tipo de redundancia.

Hemos evaluado la eficiencia de estas dos técnicas utilizando una herramienta de inyección de SEUs desarrollada por nuestro grupo de investigación a la que hemos llamado NESSY [5], [6]. Esta herramienta es capaz de evaluar el impacto de un bitflip (cambio de un

Protección efectiva de circuitos implementados en FPGAs utilizando técnicas de triplicación

sobre la plataforma NESSY

L


113

bit de 0 a 1 o viceversa) en la memoria de configuración de la FPGA. Así, hemos utilizado NESSY para inyectar SEUs en todos y cada uno de los bits de configuración que implementan el circuito a testear, para así evaluar cuán eficientes son las técnicas basadas en triplicación que se han desarrollado frente a errores inducidos por estos SEUs.

Hemos validado nuestras técnicas mediante un conjunto de benchmarks realistas extraídos del conjunto de benchmarks ITC’99 [7]. Para realizar nuestros experimentos, hemos utilizado una placa de desarrollo XUPV5-LX110T, que contiene una FPGA de tipo Xilinx™ Virtex 5. Por último proponemos una mejora arquitectónica, el diseño de votadores blindados, que permitiría reducir aún más la incidencia de los SEUs. Aunque este trabajo haya sido desarrollado en una FPGA de tipo Xilinx™ Virtex 5, es fácilmente portable a cualquier otra FPGA de tipo Xilinx™ Virtex.

El resto del artículo está organizado como sigue: La siguiente sección presenta otros trabajos significativos existentes en la literatura sobre la inyección de SEUs y protección de circuitos en FPGAs. A continuación, la sección III da más detalles sobre NESSY, la herramienta de inyección de SEUs utilizada en este artículo. La sección IV presenta la técnica de TMR a la que hemos llamado TMR simple y la sección V, las mejoras conseguidas mediante el aislamiento de las instancias del circuito. En la sección VI proponemos una mejora arquitectónica de las FPGAs para reducir aún más las incidencias de los SEUs y en la sección VII, los resultados experimentales. Finalmente, la sección VIII concluye este artículo y propone algunas líneas de trabajo futuro.

II. TRABAJO RELACIONADO

Dada la importancia que han adquirido las FPGAs en campos como el aeronáutico y el espacial, durante los últimos años varios grupos de investigación han desarrollado diferentes técnicas de diagnóstico y recuperación de SEUs.

Como ya se ha mencionado anteriormente, una de las técnicas más populares usadas para mitigar el efecto de los SEUs es el TMR [3], [4]. Se trata de una técnica que ofrece una gran mejora en la fiabilidad del sistema, pero incrementa considerablemente el coste en términos de recursos de la FPGA y consumo de potencia, ya que el circuito está replicado 3 veces. Por tanto, algunos investigadores han presentado técnicas con un coste menor pero igualmente basadas en la replicación, triplicando selectivamente sólo una parte del circuito o combinando la replicación del circuito con reconfiguración parcial por medio de un procesador que controla el proceso [8], [9].

Aunque se ha demostrado que replicando un circuito se mitigan drásticamente los efectos de los SEUs, no se trata de un método suficiente para garantizar el correcto funcionamiento de tales circuitos en entornos peligrosos. Un ejemplo de dicha insuficiencia es la ocurrencia de un CMF (fallo de modo común), o lo que es lo mismo, fallo múltiple inducido por un solo SEU. En los sistemas TMR, esto puede significar un fallo que afecta simultáneamente a dos de las tres réplicas del circuito, lo que generaría una salida incorrecta. Por esta razón, la

replicación de circuito normalmente se combina con scrubbing de la memoria de configuración, que consiste en reconfigurar la FPGA periódicamente, de forma que se evita la acumulación de SEUs que provocarían CMF, lo que reduciría la eficacia del TMR. Aunque la técnica de TMR surgió hace años y había resultados de su aplicación sobre ASICs, queríamos ver los efectos que tendría sobre dispositivos reconfigurables como las FPGAs, donde la interacción de un bit de configuración sobre varias instancias del circuito puede disminuir dramáticamente la eficiencia del método. Para evitar este tipo de problemas proponemos una mejora del TMR que presentamos en la sección V.

Con el objetivo de verificar el comportamiento de un circuito en particular en presencia de un SEU, en la literatura diversos grupos de investigación han propuesto numerosas herramientas de inyección de SEUs en FPGAs. Todas estas herramientas comparten la metodología de inyección de SEUs: a través de modificación del bit correspondiente de la memoria de configuración del dispositivo mediante su reconfiguración parcial. Algunas de estas herramientas son:

FLIPPER [10], [11], desarrollada por el Instituto Nacional de Astrofísica (INAF-ISAF) de Milán. Esta plataforma ha sido concebida para inyectar SEUs escribiendo en la memoria de configuración de una SRAM-FPGA. Sin embargo, se trata de una plataforma intrusiva, ya que para realizar los experimentos se realizan modificaciones en el circuito que se va a testear. En otras palabras, esta herramienta no testea exactamente el mismo circuito que se utilizará finalmente en una misión real.

FT-UNSHADES [12], desarrollada por el Departamento de Ingeniería Electrónica de la Universidad de Sevilla. Esta herramienta se desarrolló en primer lugar como un emulador hardware para inyectar y analizar el efecto de SEUs en diseños VLSI y, posteriormente, se extendió el desarrollo para operar también sobre una FPGA Xilinx™ Virtex-II. Su principal punto fuerte es su rapidez en realizar experimentos con circuitos de gran tamaño. Sin embargo, su ámbito de aplicación es muy limitado, ya que sólo es capaz de inyectar SEUs en el contenido de los elementos secuenciales de los circuitos que se van a testear, y no en todos los bits de configuración del bitstream. Además, también es una plataforma intrusiva.

Finalmente, los dos sistemas presentados por el grupo de investigación Electronic CAD & Reliability Group en la Universidad Politécnica de Turín, [13], [14]. Estas referencias proponen dos plataformas de inyección de SEUs para FPGAs de tipo XilinxTM Virtex-II. Por un lado, la plataforma presentada en [13] es un sistema basado en microprocesador que consigue unas prestaciones a la altura de las obtenidas por FT-UNSHADES. Sin embargo, y al igual que las otras dos plataformas presentadas anteriormente, es intrusiva. Por otro lado, en [14] los autores proponen una segunda versión de esta plataforma que garantiza su no intrusividad, pero a cambio de una pérdida de prestaciones considerable.

En resumen, estas plataformas tienen como principal inconvenientes su alto grado de intrusismo y/o sus bajas


114

prestaciones. Por ello, hemos decidimos utilizar la plataforma NESSY [5], [6], la cual se presenta en detalle en la siguiente sección.

III. PLATAFORMA MULTITAREA NESSY

NESSY es una plataforma multitarea hardware que permite realizar inyección de errores, cuyo esquema se presenta en la figura 1. El control del sistema se realiza mediante un softcore de un procesador MicroBlaze [15], cuyo programa se encuentra guardado en una BRAM. Este programa es el encargado de comunicarse con el usuario y de pasar los datos de entrada/salida al circuito que se está testeando. El programa también permite inyectar errores en el circuito bajo test.

El sistema utiliza una memoria DDR donde se almacenan los mapas de bits parciales, los testbench de los circuitos que se van a probar; y los resultados de la ejecución, a los que hemos denominado golden. Para la inyección de errores se utiliza reconfiguración parcial a través de un controlador ICAP. La comunicación con el PC se realiza a través del protocolo RS232. El adaptador circuito permite comunicar el circuito bajo test con el resto del sistema, mediante el bus PLB, bus de datos mediante el cual se comunican todos los componentes.

Figura 1. Arquitectura original de NESSY [5], [6]

Por otra parte, en un PC no mostrado en la figura 1 por simplicidad, se ejecuta un programa cuyo interfaz gráfico se presenta en la figura 2. Su función es aceptar cualquier diseño introducido por el usuario descrito en vhdl, y generar de forma automática una única instancia del mismo, conectarla al resto del sistema mediante el adaptador circuito, y generar el mapa de bits del sistema total, así como el mapa de bits parcial del circuito bajo test. Para ello, se utilizan las herramientas Xilinx™ EDK y PlanAhead. Dicho programa también permite cargar el mapa de bits total en la FPGA, y enviar a través del puerto serie el mapa de bits parcial, el testbench y el golden.

El programa de NESSY que se ejecuta en el MicroBlaze realiza la inyección de errores sobre un circuito alterando un bit de su memoria de configuración. Para esto utiliza el mapa de bits parcial asociado al circuito a testear, es decir, el bitstreamparcial creado mediante PlanAhead y enviado a la FPGA para almacenarse en la memoria DDR. Usando reconfiguración parcial sólo es necesario cargar una frame (unidad mínima de reconfiguración) para insertar

cada bitflip, permitiendo que el sistema realice la inyección en el menor tiempo posible.

Figura 2. Interfaz gráfica de NESSY

IV. AMPLIACIÓN DE LA FUNCIONALIDAD DE NESSY

El objetivo de este trabajo de investigación es ampliar la funcionalidad de NESSY para proteger los circuitos que se van a testear y, mediante la inyección de errores, comprobar su vulnerabilidad frente a SEUs. Para ello vamos a utilizar la técnica de Triple Modular Redundancia (TMR)[16]; es decir, ejecutar tres copias de un mismo circuito (figura 3) de forma que el sistema haga individualmente los cálculos en cada uno de los circuitos produciendo cada uno de éstos sus propias salidas. Esas salidas individuales se pasan por un votador, el cual produce un único resultado (la salida coincidirá con la entrada del votador que más se repita).

De esta manera, si cualquiera de las tres instancias del circuito falla, el error se puede enmascarar mediante las salidas correctas de las instancias restantes. Con esto, el circuito es tolerante a un solo fallo.

Figura 3. TMR

Por ello, hemos desarrollado una primera técnica de triplicación, a la que hemos llamado Redundancia Triple Modular Simple, cuyo resultado puede verse en la figura 4. Consiste en realizar la triplicación del circuito a testear y la posterior selección de sus salidas mediante el votador. Tanto las tres instancias del circuito a testear como el votador se encuentran en la misma RPR de la FPGA, como ya se ha comentado.

Hemos modificado NESSY para generar automáticamente las tres instancias idénticas del circuito a testear y el votador. El votador compara las salidas de las tres instancias y selecciona la más repetida, que será considerada como correcta. El adaptador circuito recibe una entrada de datos que administrará a las tres instancias del circuito. La salida de cada circuito está conectada a la entrada del votador el cual conecta su salida de nuevo al adaptador circuito. Dicha salida será considerada como la salida del sistema. En todo momento, el adaptador está comunicado con el bus de


115

datos PLB y en consecuencia, con todos los elementos del sistema hardware.

Figura 4. Arquitectura de NESSY, con técnicas de triplicación

El problema de esta técnica es que al situar los tres circuitos y el votador en una única región de la FPGA seleccionada por el usuario, los tres circuitos comparten los recursos. En consecuencia, es probable que un SEU inyectado en un solo bit de configuración de la RPR donde se encuentran mapeadas las tres instancias afecte a varias instancias simultáneamente. Estos errores no pueden ser enmascarados con la triple redundancia. Por esta razón los resultados, no son todo lo buenos que eran para otro tipo de tecnologías basadas en ASIC, como mostraremos en la sección de resultados experimentales.

V. REDUNDANCIA TRIPLE MODULAR + AISLAMIENTO

Debido a que el TMR simple tenía el inconveniente de la compartición de recursos entre las tres instancias del circuito, hemos ideado una mejora de la técnica anterior a la que llamaremos redundancia triple modular + asilamiento.

Esta técnica consiste en triplicar los circuitos igual que en el caso anterior, pero aislando cada una de las instancias en RPRs diferentes. De esta manera se impide que compartan recursos y que un error pueda estar afectando a más de una instancia del circuito a la vez. Todo el proceso de triplicación y ubicación de instancias se realiza de forma automática en el PC.

El votador también ha sido situado aislado de los circuitos por el mismo motivo. Además, el votador es capaz de detectar qué instancia del circuito falla en cada momento, y de esta manera decidir cuál es la que se debe reconfigurar para corregir el error producido.

Este aislamiento nos ha permitido reducir el porcentaje de errores significativamente, como posteriormente veremos en la sección de resultados experimentales.

NESSY acepta cualquier diseño introducido por el usuario; realiza la triplicación automática del mismo situando las tres instancias del circuito en las RPRs independientes de la FPGA que decida el usuario. Esto permite a NESSY saber en qué regiones de la FPGA debe realizar las inyecciones de bitflips. Acto seguido y mediante EDK y PlanAhead 12.1, comienza el proceso de creación de los bitstreams: tres bitstreams originales para las instancias del diseño introducido, un bitstreamparcial original para el votador y finalmente, un

bitstream global que reconfigura el resto de elementos del sistema hardware de NESSY. A continuación, el proceso de inyección se realiza en los mapas de bits correspondientes a las tres instancias del circuito y el votador.

Durante el proceso de inyección, en primer lugar se produce el envío de los cuatro bitstreams parciales originales desde el PC hasta la FPGA, donde son almacenados, para después inyectar sobre ellos de forma ordenada: cuando acaba la inyección sobre uno de ellos comienza la inyección sobre el siguiente. A pesar de que durante la inserción de un bitflip en uno de los bitstreams del circuito se obtenga un error, esto no implica el error total del diseño, ya que puede ser enmascarado por el votador. En su lugar, el votador informa cuál es la instancia del circuito que ha fallado, NESSY restaura ese bitstream defectuoso y se continúa con el proceso de inyección.

VI. VOTADOR BLINDADO

Como ya se ha mencionado, las dos técnicas de TMR que hemos desarrollado en este trabajo no proporcionan absoluta fiabilidad a nuestros diseños. Por esta razón, nos vemos en la necesidad de buscar alternativas que sigan haciendo disminuir el porcentaje de posibles errores.

Una posibilidad que mejora de manera considerable los resultados es la utilización de un votador que no sea reconfigurable, de forma que no sea vulnerable a los efectos de los SEUs, lo que denominamos votador blindado. La idea es proponer la inclusión de módulos votadores en la FPGA cuyo diseño sea full-custom, y no se reconfiguren.

Dicho votador formaría parte de la FPGA como elemento no reconfigurable y de esta manera las partículas que impactaran contra el mismo no producirían error alguno. En nuestro experimento se ha barajado esa posibilidad, simulando que las partículas que colisionan con el votador no producen efecto por el blindaje de éste. Mediante el uso de un votador blindado sólo es imposible enmascarar los SEUs que afectan a la entrada común de las tres instancias del circuito.

VII. RESULTADOS EXPERIMENTALES

Para comprobar la eficiencia de los tres métodos propuestos, hemos utilizado un conjunto de benchmarksrealistas, incluidos en el conjunto de benchmarksITC’99 [7]. En estos experimentos, hemos seleccionado todos aquéllos benchmarks cuya implementación en FPGA no utiliza ninguno de los bloques de memoria BRAM que se encuentran embebidos en la FPGA. El motivo es que la actual versión de NESSY aún no es capaz de inyectar SEUs en los bits de configuración que configuran este tipo de bloques de memoria.

En la figura 5 se presentan los resultados obtenidos al realizar inyecciones exhaustivas en los circuitos considerados, para los siguientes cuatro casos:

1. Sin ningún tipo de redundancia. 2. Con Redundancia Triple Modular Simple

(Triplicación en la figura por simplicidad). 3. Con Redundancia Triple Modular + Aislamiento

(Triplicación + Aislamiento en la figura).


116

4. Con Redundancia Triple Modular + Aislamientoy utilizando un votador blindado (Triplicación + Aislamiento + Votador blindado en la figura).

En la figura se puede observar que la triplicación simple consigue disminuir notablemente el porcentaje de SEUs no enmascarables (que producen un error en la salida del sistema), a menos de 1% en todos los casos. Es decir, el 99% de los SEUs que se simulan mediante la inyección de un bitflip no producen error en la salida.

Figura 5. Porcentaje de SEUs que han provocado error, en comparación con un sistema equivalente sin redundancia

Para comprobar la mejora introducida por las otras dos técnicas, en la figura 6 se presentan las mismas gráficas exceptuando la opción sin redundancia, lo cual permite aumentar la precisión de los datos. Podemos observar que usando aislamiento de las instancias, el porcentaje de errores no enmascarables cae por debajo del 0,13%, siendo un 0,05% de media; es decir, se ha reducido su incidencia en un 10% frente al caso sin aislar. Por último, usando el votador blindado los errores no enmascarables quedan por debajo del 0,03%, siendo un 0,016% de media.

Por tanto, sin necesidad de invertir un alto presupuesto somos capaces de conseguir resultados fiables que hacen que la técnica de triplicación con aislamiento de las instancias del circuito o el blindaje del votador sean interesantes para su utilización en misiones aeroespaciales reales.

VIII. CONCLUSIONES Y TRABAJO FUTURO

En este artículo se ha realizado un estudio comparativo de dos técnicas basadas en TMR para la protección de circuitos implementados en FPGAs. Se ha demostrado que, a diferencia de otras tecnologías, en las FPGAs utilizar TMR sólo no es suficiente, ya que hasta un 1% de los SEUs sigue produciendo error. Para reducir este porcentaje es preciso garantizar el aislamiento físico de las distintas instancias del circuito mediante su implementación en diferentes regiones parcialmente reconfigurables de la FPGA. Esto reduce la media de errores encontrados a la salida del circuito al 0,05%. Finalmente, también se presenta una posible mejora arquitectónica que consiste en proteger el votador, causante de la mayor parte de los errores no enmascarables. Esta última mejora arquitectónica

permite reducir SEUs que producen error al 0,016% de media (0,03% máximo).

Nuestro trabajo futuro se centrará en depurar estas técnicas usando un TMR selectivo, de forma que sólo se tripliquen aquellos recursos más vulnerables. De esta forma, sin incrementar el número de errores no enmascarables, conseguiremos soluciones menos costosas.

Figura 6. Comparativa de la eficiencia frente a SEUs de las tres técnicas de protección de circuitos presentadas en este artículo

AGRADECIMIENTOS

El presente trabajo ha sido financiado mediante los proyectos de investigación AYA2009-13300-C03-02 y TIN2009-09806.

REFERENCIAS

[1] Anderson, K., Low-Cost, Radiation-Tolerant, On-Board Processing Solution, in Proceedings of the IEEE Aerospace Conference, pp. 1-8, 2005.

[2] Ziegler, J. F. and Lanford, W. A., The E ect of Sea-Level Cosmic Rays on Electronic Devices, Journal of Applied Physics, Vol. 52, No. 6, pp. 4305-4312, 1981.

[3] E. A. Stott, N. P. Sedcole, and P. Y. K. Cheung, Fault Tolerance and Reliability in Feld-Programmable Gate Arrays, IET Computers & Digital Techniques, vol. 4, no. 3, pp. 196–210, 2010.

[4] Y. Ichinomiya, S. Tanoue, M. Amagasaki, M. Iida, M. Kuga, and T. Sueyoshi, Improving the Robustness of a Softcore Processor against SEUs by Using TMR and Partial Recon guration, in Proceedings of the IEEE Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM), May 2010, pp. 47 –54.

[5] F. Serrano, V. Alaminos, J. A. Clemente and H. Mecha, NESSY: An Implementation of a Low-Cost Fault-Injection Platform on a Virtex-5 FPGA, in Proceedings of the Conference on Radiation and its Effects on Components and Systems (RADECS), 2012.

[6] F. Serrano V. Alaminos, J. A. Clemente, H. Mecha y S.F. Liu, NESSY: Una plataforma de inyecci_on de errores para una FPGA Virtex-5, en Jornadas de Computaci_on Reconfigurable y Aplicaciones (JCRA), pp. 22-27, Sept. 2012.,

[7] F. Corno, M. Reorda, and G. Squillero, RT-Level ITC’99 Benchmarks and First ATPG Results, Design Test of Computers, IEEE, vol. 17, no. 3, pp. 44 –53, July/Sept. 2000.

[8] P. Samudrala, J. Ramos, and S. Katkoori, Selective Triple Modular Redundancy (STMR) Based Single-Event Upset (SEU) Tolerant Synthesis for FPGAs, IEEE Transactions on Nuclear Science, vol. 51, no. 5, pp. 2957– 2969, Oct. 2004.

[9] B. Pratt, M. Caffrey, P. Graham, K. Morgan, and M. Wirthlin, Improving FPGA Design Robustness with Partial TMR, in Proceedings of the IEEE International Reliability Physics Symposium, March 2006, pp. 226–232.

[10] M. Alderighi, F. Casini, S. D’Angelo, M. Mancini, S. Pastore, and G. Sechi, Evaluation of Single Event Upset Mitigation Schemes for SRAM Based FPGAs Using the FLIPPER Fault


117

Injection Platform, in Proceedings of the IEEE International Symposium on Defect and Fault-Tolerance in VLSI Systems (DFT), Sept. 2007, pp. 105–113.

[11] M. Alderighi, F. Casini, S. D’Angelo, M. Mancini, D. Codinachs, S. Pastore, C. Poivey, G. Sechi, G. Sorrenti, and R. Weigand, Experimental Validation of Fault Injection Analyses by the FLIPPER Tool, IEEE Transactions on Nuclear Science, vol. 57, no. 4, pp. 2129–2134, Aug. 2010.

[12] C. Lopez-Ongil, L. Entrena, M. Garcia-Valderas, M. Portela, M. Aguirre, J. Tombs, V. Baena, and F. Munoz, A Uni ed Environment for Fault Injection at any Design Level Based on Emulation, IEEE Transactions on Nuclear Science, vol. 54, no. 4, pp. 946–950, Aug. 2007.

[13] L. Sterpone and M. Violante, A new Partial Recon guration-Based Fault-Injection System to Evaluate SEU Effects in SRAM-Based FPGAs, IEEE Transactions on Nuclear Science, vol. 54, no. 4, pp. 965–970, Aug. 2007.

[14] N. Battezzati, L. Sterpone, and M. Violante, A New Low-Cost non Intrusive Platform for Injecting Soft Errors in SRAM-Based FPGAs, in Proceedings of the IEEE International Symposium on Industrial Electronics (ISIE), July 2008, pp. 2282–2287.

[15] Xilinx Corporation, MicroBlaze Processor Reference Guide, UG081 (v13.4), 2012.

[16] B. W. Johnson. Design and Analysis of Fault Tolerant Digital Systems, 1989.


118

Un estudio de la robustez frente a SEUs decircuitos digitales implementados con los DSPs

de las FPGAsFelipe Serrano1 Juan Antonio Clemente2 y Hortensia Mecha 3

Resumen— En este artıculo presentamos una vali-dacion experimental del aumento de la fiabilidad decircuitos empotrados implementados en FPGAs detipo XilinxTMcuando estos se implementan utilizandolos DSPs (Digital Signal Processors) que se encuen-tran disponibles en el dispositivo reconfigurable. Paraello hemos utilizado una herramienta de inyeccionde SEUs desarrollada por nuestro grupo de investi-gacion, NESSY [1], [2], la cual simula la aparicionde un SEU cambiando el valor de un bit de config-uracion del circuito a testear. En nuestros exper-imentos demostramos que la probabilidad de ocur-rencia de un error como consecuencia de un SEUpor cada bit de configuracion en un circuito imple-mentado sin DSPs es similar respecto al equivalenteutilizando DSPs. Sin embargo, el area de FPGAutilizada por este ultimo circuito es mucho menor,por lo tanto la probabilidad de aparicion de un SEUen este es mucho menor tambien. Hemos validadonuestros experimentos con varias versiones de un fil-tro FFE (Feed Forward Equalizer), circuito usado enaplicaciones reales. La FPGA utilizada ha sido unaXilinxTMVirtex 5, aunque los experimentos presenta-dos en este artıculo son extensibles a cualquier FPGAde tipo XilinxTMVirtex.

I. Introduccion

LO s dispositivos reconfigurables, y en concretolas FPGAs, presentan una combinacion muy in-

teresante entre prestaciones y flexibilidad, lo cual leshace muy utiles para su uso en aviacion, aplicacionesnucleares o misiones espaciales.

Sin embargo, en estos entornos los dispositivos seencuentran normalmente expuestos a una gran can-tidad de radiacion [3], [4]. Esta puede inducir laaparicion de Single Event Upsets (SEUs) en el sis-tema, los cuales consisten en un cambio en el con-tenido de una celda de memoria. En las FPGAsbasadas en memoria SRAM (SRAM-FPGAs), losSEUs afectan especialmente a la memoria de con-figuracion. De hecho, estos errores pueden provocarerrores graves en el funcionamiento normal de unaFPGA que ha sido enviada, por ejemplo, al espacio,y esta expuesta a altas dosis de radiacion.

Por este motivo, resulta de vital importancia eldesarrollo y la adopcion de tecnicas para reducir oneutralizar el efecto de los SEUs en sistemas empo-trados. Una tecnica muy extendida es la triple re-dundancia [5]. Consiste en triplicar el diseno del cir-cuito y seleccionar (o “votar”) la salida que mas vecesse repita. Ası, si una de las instancias circuito se ha

1Departamento de Arquitectura de Computadores y Au-tomatica (DACyA), Universidad Complutense de Madrid(UCM), e-mail: [email protected]

2DACyA, UCM, e-mail: [email protected], UCM, e-mail: [email protected]

visto afectada por un SEU, la salida seleccionada porel votador es correcta, y al mismo tiempo la instan-cia del circuito afectada se puede corregir mediantereconfiguracion parcial. Esta solucion es muy efec-tiva, pero tiene un coste altısimo en area, ya quehay que replicar el circuito original 3 veces. Otraalternativa muy utilizada es el “scrubbing”, que con-siste en reconfigurar el circuito cada cierto tiempo[6]. Sin embargo, esta solucion tiene un cierto costeen prestaciones debido a que la reconfiguracion par-cial lleva del orden de milisegundos en completarse,el cual puede ser inasumible.

En este artıculo presentamos una solucion dife-rente para aumentar la robustez de circuitos digi-tales implementados en FPGAs: su implementacionusando DSPs empotrados en la FPGA destino, siem-pre que estos esten disponibles en dicha plataforma.De este modo, en este artıculo proponemos un estu-dio experimental comparativo de la robustez de va-rios circuitos digitales reales (utilizando y sin utilizarDSPs) frente a SEUs implementados en una FPGAde tipo XilinxTMVirtex. Para cada uno de los cir-cuitos testeados, en este estudio comparamos su ro-bustez frente a SEUs cuando se implementan uti-lizando DSPs, frente a cuando se implementan sinutilizarlos. Los resultados experimentales presenta-dos demuestran que las versiones que utilizan DSPsresultan mas seguras frente a SEUs que las versionesequivalentes que no los utilizan.

A fin de poder obtener estos resultados, hemos uti-lizado una opcion de sıntesis e implementacion de laherramienta XilinxTMISE 12.1 que activa/desactivala utilizacion de DSPs en la implementacion final decada circuito. Los circuitos utilizados para realizarlos experimentos han sido varias versiones de un cir-cuito complejo consistente en un filtro Feed ForwardEqualizer (FFE).

Para realizar este estudio experimental, hemosutilizado una herramienta de inyeccion de SEUs,NESSY, desarrollada por nuestro grupo de investi-gacion. Para inyectar un SEU, esta herramienta mo-difica el contenido de un bit en la region de la memo-ria de configuracion de la FPGA que implementa elcircuito bajo prueba. Con respecto a anteriores im-plementaciones de NESSY, ya presentadas en [1], [2],para este artıculo la hemos dotado la capacidad deinyectar SEUs en las regiones de los bitstreams quecontienen informacion de configuracion de DSPs.

En este trabajo hemos utilizado una placa de de-sarrollo XilinxTMXUPV5-LX110T, la cual contieneuna FPGA Virtex-5. Sin embargo, los resulta-


119

dos presentados en este artıculo son extrapolables acualquier otra arquitectura de tipo XilinxTMVirtex.

Otros trabajos existentes en la literatura [7], [8],[9], [10], [11], [12] proponen diversas herramientas deinyeccion de SEUs sobre circuitos en FPGAs y pro-porcionan resultados de inyeccion sobre diversos cir-cuitos. Sin embargo, ninguno de estos trabajos ofreceun estudio comparativo como el que presentamos eneste artıculo.

El resto del artıculo esta organizado como sigue:La seccion II presenta otros trabajos significativosexistentes en la literatura sobre la inyeccion de SEUsen FPGAs. A continuacion, la seccion III describe elfuncionamiento de nuestra herramienta de inyeccionde SEUs. La seccion IV expone los resultados expe-rimentales obtenidos y finalmente, la seccion V con-cluye este artıculo.

II. Trabajo Relacionado

A lo largo de los ultimos anos, se han realizadoimportantes esfuerzos para conocer en profundidadel efecto de los SEUs en SRAM-FPGAs. Para ello,la tecnica tıpicamente mas comun consiste en ex-poner la memoria de configuracion de la FPGA aprotones, neutrones [13], [14] o partıculas ionizadas,como carbono o argon [15]. Sin embargo, estos testsson normalmente muy caros (de hecho, pueden llegara costar miles de dolares), llevan mucho tiempo enrealizarse, y en muchas ocasiones no permiten con-trolar con total precision la localizacion y/o cantidadexactas de errores encontrados, lo cual resulta cru-cial en este tipo de experimentos [16]. Por ello, unatecnica alternativa que resulta muy interesante es laemulacion de SEUs en la FPGA a nivel de hardwareinsertando bitflips (es decir, cambios de 0 a 1 o de 1a 0) en la memoria de configuracion. Estas tecnicasconsisten en modificar el bit correspondiente de lamemoria de configuracion del dispositivo mediantesu reconfiguracion parcial.

Existen actualmente multitud de plataformas deinyeccion de SEUs en circuitos implementados enFPGAs. Las que mas se asemejan a nuestraplataforma son FLIPPER [7], [8], desarrollada porel Instituto Nacional de Astrofısica (INAF-ISAF ) deMilan; FT-UNSHADES [9], [10], desarrollada por elDepartamento de Ingenierıa Electronica de la Uni-versidad de Sevilla; y dos sistemas presentados porel grupo de investigacion Electronic CAD & Relia-bility Group en la Universidad Politecnica de Turın[11], [12]. El resto de la seccion presenta un resumende las caracterısticas principales de cada una de estossistemas.

En primer lugar, FLIPPER [7], [8] es unaplataforma disenada para inyectar SEUs modificandoel contenido de la memoria de configuracion de unaSRAM-FPGA de tipo XilinxTMVirtex-II Pro. Uti-liza 2 FPGAs: una para mapear el circuito bajoprueba, y otra para controlar el experimento y parainyectar SEUs en la memoria de configuracion de laprimera FPGA. FLIPPER ha sido validada experi-mentalmente exponiendola alta radiacion utilizando

un acelerador de protones [8]. Sin embargo, lasprincipales limitaciones de esta herramienta son: 1)No es facilmente portable a otras FPGAs y 2) mo-difica ciertas regiones del circuito bajo prueba, locual impide poder inyectar SEUs en exactamente elmismo circuito que se implementara finalmente en laFPGA y que trabajara en el mundo real. Si unaplataforma de inyeccion de SEUs adolece de esteultimo defecto, tıpicamente se le conoce como in-trusiva [11].

En segundo lugar, FT-UNSHADES [9] fue ini-cialmente desarrollada para analizar el efecto de losSEUs en disenos VLSI. En [10] los autores presen-tan una extension de esta plataforma, la cual per-mite emular SEUs en la memoria de configuracionde una FPGA de tipo Virtex-II Pro. Esta herra-mienta mapea 2 instancias del circuito bajo pruebaen la FPGA: la primera es una copia del circuito sinerrores, mientras que la segunda es la instancia so-bre la cual se inyectaran SEUs para ası evaluar su im-pacto en el circuito. El principal punto fuerte de estaplataforma es que alcanza altas prestaciones, permi-tiendo realizar grandes experimentos de inyeccion deSEUs en pocas horas. Sin embargo, tiene una granlimitacion y es su reducido ambito de aplicacion, yaque solo inyecta SEUs en los bits de configuracionque modifican el contenido de los elementos secuen-ciales del circuito bajo prueba (flip-flops, registros,memorias BRAM...), y no en todos los bits de con-figuracion del bitstream. Ademas, esta plataformaes intrusiva.

Finalmente, los sistemas presentados por el grupoCAD del Politecnico de Turın [11], [12] presentanotras dos plataformas de inyeccion de SEUs paraFPGAs de tipo XilinxTMVirtex-II Pro. Por un lado,y al igual que FT-UNSHADES, la plataforma presen-tada en [11] alcanza altas prestaciones, pero al mismotiempo es intrusiva. Ası, en [12] estos mismos autorespresentan una version mejorada de [11] que garan-tiza su no intrusividad. Sin embargo, la inclusionde esta propiedad implico una enorme perdida enprestaciones. Ası, el tiempo medio de inyeccion ytesteo de un DUT aumenta en [12] en aproximada-mente en 3 ordenes de magnitud con respecto a [11].

A pesar de que todas estas herramientas com-parten los mismos objetivos y en ocasiones la mismametodologıa que NESSY, es muy importante subra-yar que, hasta donde tenemos conocimiento, ni enninguno estos trabajos ni en el estado del arte se hapropuesto estudio comparativo alguno de la robustezde circuitos implementados en FPGAs como el quepresentamos en este artıculo.

III. NESSY: Nuestra Herramienta de

Inyeccion de SEUs

NESSY es una plataforma de inyeccion deSEUs cuyas principales aportaciones son su altorendimiento y su no intrusividad. Este doble ob-jetivo se consigue considerando que las aplicacionesse van a ejecutar en un entorno multitarea siguiendoel esquema de la figura 1. Ası, la FPGA destino


120

Fig. 1. Sistema harware multitarea en el cual las tareastesteadas con NESSY seran finalmente implementadas

se divide en un conjunto de Regiones ParcialmenteReconfigurables (RPRs). Estas RPRs se conectana una infraestructura de comunicaciones que puedeimplementarse como un bus o una Network-on-Chip(NoC) [17]. Cada tarea que se ejecuta se coloca enuna de estas RPRs, y se comunica con el resto delsistema a traves de dicha infraestructura de comu-nicaciones. El control de las distintas tareas (con-figuracion, E/S, etc) se lleva a cabo mediante unsistema operativo o Middleware, que puede ejecu-tarse en un procesador situado dentro o fuera de lapropia FPGA, y que tambien esta conectado a la in-fraestructura de comunicaciones. La E/S de tareas serealiza mediante reconfiguracion parcial de las RPRsa traves de los puertos de reconfiguracion externo(JTAG, BPI, etc) o interno (ICAP). La generacion delos mapas de bits parciales y globales de este sistemase realiza mediante las herramientas proporcionadaspor XilinxTMpara la reconfiguracion parcial de susFPGAs: EDK y PlanAhead.

A. NESSY: Detalles de su Arquitectura

La plataforma NESSY (figura 2) se ha disenadosiguiendo este esquema general de multitarea hard-ware, utilizando como procesador para el control detareas un soft core de tipo MicroBlaze [18], que secoloca en la misma FPGA. En este caso, la estruc-tura de comunicaciones es un bus PLB (ProcessorLocal Bus). Los circuitos a testear se ubican exacta-mente en la misma RPR que ira en el sistema finalembarcado y, durante la ejecucion de la misma, elsoftware cargado en el MicroBlaze se comunica conellos como se hara en el sistema final.

Este esquema permite utilizar el propio ICAP pararealizar la inyeccion de SEUs, utilizando reconfigu-racion parcial. En la emulacion de un SEU, el soft-ware cargado en el MicroBlaze realiza, ademas de lastareas habituales de comunicacion, la modificacionun bit de la memoria de configuracion de la tarea(lo cual se conoce habitualmente como bitflip). Paraello solo es necesario cargar una frame (que es launidad mınima de reconfiguracion) con el bit corres-pondiente invertido, con lo cual la inyeccion de SEUsse realiza en el mınimo tiempo posible, consiguiendoası un alto rendimiento.

Con este metodo, la inyeccion de SEUs se realizasin alterar en ningun momento la colocacion y rutado

Fig. 2. Arquitectura de NESSY

de los distintos elementos configurables que consti-tuyen el circuito, salvo por los bitflips inyectados.Por eso se trata de un sistema no intrusivo.Ademas, este esquema proporciona dos ventajas

adicionales: por un lado, tiene un coste mınimo, yaque no es necesaria una plataforma ad-hoc, solo laplataforma con la FPGA que se va a utilizar en eldiseno final y un PC que se comunica con el Micro-Blaze. Por otro lado, es facilmente portable a otrasFPGAs de tipo XilinxTMVirtex.La comunicacion entre el host PC y el MicroBlaze

se realiza a traves de un protocolo RS232, y se limitaa tareas de sincronizacion y envıo de datos (bitstreamde un circuito, testbench, etc).

B. Interpretacion de la Arquitectura de la Virtex 5en NESSY

NESSY emula SEUs mediante la modificaciondel bitstream del circuito testeado recorriendo einyectando bitflips en todos los bits asociados ala configuracion de los distintos recursos logicos.En las versiones anteriores de NESSY [1], [2] soloemulabamos SEUs en los CLBs (Configurable LogicBlocks) de la FPGA y por lo tanto, ignorabamos losbits asociados a otro tipo de recurso. Sin embargo,para realizar el estudio comparativo que presenta-mos en este artıculo, hemos ampliado NESSY paraque emule SEUs tambien en DSPs.Para explicar como hemos hecho esto, hay que en-

tender como es la arquitectura de la FPGA Virtex 5,ası como su informacion de configuracion asociada.Los recursos de esta FPGA se pueden ver como unamatriz bidimensional de unidades a las que hemosllamado bloques de recursos. Cada bloque de recur-sos contiene un conjunto de recursos del mismo tipo(CLBs, DSPs, ...), mas una o varias matrices de in-terconexionado asociadas a dichos recursos. En estetrabajo hemos distinguido 2 tipos de bloques:

• Un bloque-CLB (figura 3) esta compuesto porun CLB y 2 matrices de conexionado asociada.

• Un bloque-DSP (figura 4) esta compuesto por 2DSPs y 6 matrices de interconexionado asocia-das.

Una minor frame es la unidad mınima de configu-racion. Esto implica que para inyectar un SEU sobreun unico bloque-CLB o bloque-DSP, se debe cargar lainformacion correspondiente a unaminor frame com-pleta, la cual contiene informacion de configuracionde todos los recursos logicos del bloque de recursosasociado al bit que se quiere modificar.


121

Fig. 3. Estructura interna de un bloque-CLB visto desde elXilinxTMFPGA Editor. Los rectangulos azules represen-tan los 2 slices que comprenden un CLB, mientras que losrectangulos de color negro con contorno gris representanlas matrices de interconexionado

Fig. 4. Estructura interna de un bloque-DSP visto desdeel XilinxTMFPGA Editor. En este caso, los rectangulosrojos representan los DSPs

La informacion de configuracion asociada a los blo-ques de recursos adyacentes situados en la mismacolumna esta contenida en un conjunto de minorframes de 40 palabras de 32 bits cada una (en to-tal, 40 ∗ 32 = 1.280 bits de configuracion por minorframe). Ası, una minor frame abarca un total de 20bloques-CLB, o bien un total de 4 bloques-DSP. Lafigura 5 muestra la organizacion de estos dos tiposde bloques de recursos y la equivalencia entre estosy su informacion de configuracion asociada.

Haciendo un estudio mas en profundidad, hemos

Fig. 5. Relacion entre los bloques de recursos en unaXilinxTMVirtex 5 y su informacion de configuracion aso-ciada

descubierto que la matriz de bloques de recursosno es regular; es decir, cada bloque de recursos notiene el mismo numero de minor frames. De hecho,el numero de minor frames que corresponden a 4bloques-DSP adyacentes es de 28 y para 20 bloques-CLB adyacentes es de 36. Por tanto, cada conjuntode 4 bloques-DSP se reconfigura a traves de la infor-macion contenida en un total de 28 ∗ 1.280 = 35.840bits de configuracion, mientras que cada conjunto de20 bloques-CLB, serıa con un total de 36 ∗ 1.280 =48.060 bits. Ademas:

• De las 40 palabras de configuracion comprendi-das en una minor frame asociada a un conjuntode 20 bloques-CLB, 2 palabras van asociadas almismo bloque-CLB. Por tanto, hay un total de36 ∗ 2 = 72 palabras de configuracion asociadasa un CLB y sus 2 matrices de interconexionadoadyacentes (lo cual equivale a 2304 bits de con-figuracion por cada bloque-CLB).

• En el caso de los DSPs, de las 40 palabras deconfiguracion comprendidas en una minor frameasociada a un conjunto de 4 bloques-DSP, 10 pa-labras van asociadas al mismo bloque-DSP. Portanto, hay un total de 28 ∗ 10 = 280 palabras deconfiguracion asociadas a 2 DSPs y sus 6 ma-trices de interconexionado adyacentes (lo cualequivale a 8.960 bits de configuracion por cadabloque-DSP).

Conociendo esta informacion, NESSY recorre elbitstream de manera controlada inyectando SEUs endichos recursos.

IV. Resultados experimentales

En esta seccion analizamos y comparamos los re-sultados experimentales obtenidos para un mismocircuito cuando este es sintetizado usando solo CLBsy cuando se utilizan tanto CLBs como DSPs. Ennuestros experimentos hemos utilizado dos circuitos:

• Un filtro FFE, que es un circuito complejo muy


122

TABLA I

Resultados de Inyeccion de SEUs

Circuito# Inyecciones

Bloques-CLB Bloques-DSP% Errores

Totales# Inyecciones

Efectivas# Errores

# InyeccionesEfectivas

# Errores Totales

FFE (2) sin DSPs 276.480 258.048 7.892 N/A N/A 3,06%

FFE (2) con DSPs 128.000 43.776 1.763 17.920 838 4,22%

FFE (4) sin DSPs 555.520 516.096 15.954 N/A N/A 3,09%

FFE (4) con DSPs 128.000 82.944 2.659 35.840 1.560 3,55%

FFE (8) sin DSPs 1.013.760 963.072 52.209 N/A N/A 5,42%

FFE (8) con DSPs 256.000 154.368 7.529 71.680 4.634 5,38%

utilizado en aplicaciones espaciales. Consta devarias etapas consecutivas de filtrado. En nues-tros experimentos, hemos inyectado SEUs endiferentes versiones de este circuito: con 2, 4y 8 etapas de filtrado, respectivamente.

• Un filtro de tipo FIR de una unica etapa, elcual es un circuito patron a medida que uti-liza al maximo un unico DSP. Para ello, estecircuito implementa una funcion de la formay(n) = a(n) · b(n) + c(n). Hemos utilizado estecircuito para obtener un upper bound de la re-duccion del tamano de los circuitos al imple-mentarlos utilizando DSPs, en terminos de in-formacion de configuracion utilizada.

A. Comparacion de Resultados

La tabla I presenta y compara los resultados deinyeccion de los circuitos analizados. Las filas 1, 3 y5 presentan la version sin DSPs para los filtros FFEcon 2, 4 y 8 etapas, respectivamente. Las filas 2, 4 y6 hacen lo propio con las versiones con DSPs corres-pondientes. La columna 2 muestra el numero de in-yecciones realizadas en toda la region reconfigurablereservada para el circuito, mientras que las columnas3 y 5 solo contabilizan las inyecciones que afectana recursos realmente utilizados por el circuito bajotest. Para conocer esta informacion, hemos utilizadola herramienta XilinxTMFPGA Editor para ası verexactamente que recursos han sido utilizados para laimplementacion de los circuitos. A continuacion, lascolumnas 4 y 6 distinguen los errores detectados enfuncion de los bloques de recursos a los que afectan.Por ultimo, la columna 7 muestra el porcentaje deerrores en los distintos circuitos. En el caso de lasversiones con DSPs, se ha obtenido una media pon-derada de los porcentajes correspondientes a los erro-res en CLBs y DSPs segun su peso en el total de loserrores. Los porcentajes han sido calculados con res-pecto al numero de inyecciones efectivas realizadas,para ası no desvirtuar los resultados debido a ma-pear el circuito en una PRR de mayor tamano queel circuito a testear.Con estos datos podemos comparar la distintas im-

plementaciones del FFE y vemos que los porcentajesson ligeramente superiores o iguales entre las ver-siones con y sin DSPs. Esto indica que los circuitosimplementados con DSPs no son mas resistentes a laradiacion cosmica que los CLBs a nivel estructural.

Por otro lado, las implementaciones equivalentescon DSPs tienen la ventaja adicional de ser mas efi-cientes al implementar logica. De hecho, la imple-mentacion del circuito patron de tipo FIR nos hapermitido averiguar que, para las versiones imple-mentadas sin utilizar DSPs, cada bloque-DSP se sin-tetiza utilizando 106 bloques-CLB. Como son nece-sarios 8.960 bits de configuracion para configurar unbloque-DSP, y 106 ∗ 2.304 = 244.224 bits para confi-gurar 106 bloques-CLB, el tamano de la memoria deconfiguracion necesaria para configurar estos recur-sos logicos se reduce en un 96,33%. En el caso de loscircuitos testeados en este artıculo, la reduccion en lainformacion de configuracion ha sido de un 76,53%de media al tener parte del circuito implementadacon CLBs.

Por tanto, podemos concluir que un circuito es masresistente a los SEUs si usa DSPs debido a su mayoreficiencia en terminos de area y por lo tanto unamenor probabilidad de que una partıcula de alta en-ergıa incida sobre este.

B. Distribucion de los Errores

Las tablas II y III clasifican los errores encontradosen los circuitos evaluados en funcion de si estos hanocurrido en 3 categorıas de recursos:

• Instancia Circuito: SEUs que afectan a bloquesde recursos logicos utilizados para implementarla instancia del circuito propiamente dicha.

• E/S : Por el hecho de usar la arquitectura mul-titarea NESSY, al circuito bajo test se le debeanadir un conexionado mınimo que haga de in-terfaz entre nuestra plataforma y las entradasy salidas del circuito. Un error de E/S se dacuando un SEU afecta a dichas senales. Hemosdecidido incluir estos ultimos porque cualquiercircuito real va a tener una interfaz de E/S y porlo tanto este problema va a aparecer en cualquierescenario.

• Interconexionado: Bloques de recursos logicosno incluidos en ninguna de las dos categorıasanteriores. Estos bloques de recursos no imple-mentan ninguna logica del circuito, pero sı seutiliza alguna de sus matrices de interconexio-nado para rutar senales. Al igual que los erro-res de E/S, esta categorıa de errores es inevi-table debido a que el algoritmo de rutado de


123

TABLA II

Clasificacion de Resultados para los Bloques-CLB

Instancia Circuito E/S Interconexionado TOTAL

Circuito # CLBs # Errores # CLBs # Errores # CLBs # Errores # CLBs # Errores

FFE (2) con DSPs 17 1583 2 76 18 104 37 1.763

FFE (2) sin DSPs 110 7824 2 57 2 11 114 7.892

FFE (4) con DSPs 29 2497 7 137 2 25 38 2.659

FFE (4) sin DSPs 220 14825 4 180 14 949 238 15.954

FFE (8) con DSPs 58 6.246 9 790 13 493 80 7.529

FFE (8) sin DSPs 413 50.187 5 309 22 1.713 440 52.209

TABLA III

Clasificacion de Resultados para los Bloques-DSP

Instancia Circuito E/S Interconexionado TOTAL

Circuito # DSPs # Errores # DSPs # Errores # DSPs # Errores # DSPs # Errores

FFE (2) con DSPs 4 838 0 0 0 0 4 838

FFE (4) con DSPs 8 1560 0 0 0 0 8 1560

FFE (8) con DSPs 16 4.634 0 0 0 0 16 4.634

XilinxTMdecide utilizar ciertas matrices de in-terconexionado asociadas a un bloque de recur-sos para rutar las senales utilizadas por bloquesde recursos vecinos. Ademas pueden ocurrir enrecursos que estan fuera de la region definidapara el circuito.

V. Conclusiones y Trabajo Futuro

En este artıculo hemos presentado un estudioexperimental comparativo del aumento de la ro-bustez frente a Single Event Upsets (SEUs) de cir-cuitos digitales implementados en FPGAs de tipoXilinxTMVirtex cuando estos se implementan usandoDSPs de la FPGA. Para ello, hemos utilizado unaherramienta de inyeccion de SEUs de elaboracionpropia, NESSY [1], [2]. En los experimentos reali-zados (varias versiones de un filtro FFE), la proba-bilidad de incidencia de un error en un bit de configu-racion como consecuencia de la aparicion de un SEUes similar a cuando estos circuitos se implementanutilizando DSPs. Sin embargo, el numero de bitsde configuracion de estas versiones de los circuitosdisminuye en un 76,53%, lo cual disminuye la proba-bilidad de ocurrencia de un SEU en estos.Como trabajo futuro, queremos realizar un estudio

similar, pero esta vez aplicado a la inyeccion de SEUsen las Block RAMs embebidas en la FPGA.

Agradecimientos

El presente trabajo ha sido financiado mediante losproyectos de investigacion AYA2009-13300-C03-02 yTIN2009-09806.

Referencias

[1] F. Serrano, V. Alaminos, J. A. Clemente, H. Mecha y S.-F. Liu, NESSY: Una plataforma de inyeccion de errorespara una FPGA Virtex-5, en Jornadas de ComputacionReconfigurable y Aplicaciones (JCRA), pp. 22-27, Sept.2012.

[2] V. Alaminos, F. Serrano, J. A. Clemente y H. Mecha,NESSY: An Implementation of a Low-Cost Fault-

Injection Platform on a Virtex-5 FPGA, in Proceedingsof the Conference on Radiation and its Effects on Compo-nents and Systems (RADECS), 2012.

[3] J. F. Ziegler and W. A. Lanford, The Effect of Sea-LevelCosmic Rays on Electronic Devices, Journal of AppliedPhysics, vol. 52, no. 6, pp. 4305-4312, 1981.

[4] K. Anderson, Low-cost, Radiation-Tolerant, On-BoardProcessing Solution, in Proceedings of the IEEEAerospace Conference, March 2005, pp. 1-8.

[5] E. A. Stott, N. P. Sedcole, and P. Y. K. Cheung, FaultTolerance and Reliability in Field-Programmable GateArrays, IET Computers & Digital Techniques, vol. 4, no.3, pp. 196-210, 2010.

[6] A. Tiwari and K. Tomko, Enhanced Reliability of Finite-State Machines in FPGA Through Efficient Fault Detec-tion and Correction, IEEE Transactions on Reliability,vol. 54, no. 3, pp. 459-467, Sept. 2005.

[7] M. Alderighi et al., Evaluation of Single Event UpsetMitigation Schemes for SRAM Based FPGAs Using theFLIPPER Fault Injection Platform, in Proceedings ofthe IEEE International Symposium on Defect and Fault-Tolerance in VLSI Systems (DFT), Sept. 2007, pp. 105-113.

[8] M. Alderighi, et al., Experimental Validation of Fault In-jection Analyses by the FLIPPER Tool, IEEE Transac-tions on Nuclear Science, vol. 57, no. 4, pp. 2129-2134,Aug. 2010.

[9] C. Lopez-Ongil et al., A Unified Environment for FaultInjection at any Design Level Based on Emulation, IEEETransactions on Nuclear Science, vol. 54, no. 4, pp. 946-950, Aug. 2007.

[10] L. Sterpone, M. Aguirre, J. Tombs, and H. Guzman-Miranda, On the Design of Tunable Fault Tolerant Cir-cuits on SRAM-Based FPGAs for Safety Critical Appli-cations, in Proceedings of the Design, Automation andTest in Europe (DATE), March 2008, pp. 336-341.

[11] L. Sterpone and M. Violante, A New PartialReconfiguration-Based Fault-Injection System to EvaluateSEU Effects in SRAM-Based FPGAs, IEEE Transactionson Nuclear Science, vol. 54, no. 4, pp. 965-970, Aug. 2007.

[12] N. Battezzati, L. Sterpone, and M. Violante, A New Low-Cost non Intrusive Platform for Injecting Soft Errors inSRAM-Based FPGAs, in Proceedings of the IEEE Inter-national Symposium on Industrial Electronics (ISIE), July2008, pp. 2282-2287.

[13] P. N. Sanda et al., Soft-Error Resilience of the IBMPOWER6 Processor, IBM Journal of Research and De-velopment, vol. 52, no. 3, pp. 275-284, May 2008.

[14] K. Morgan, et al., SEU-Induced Persistent Error Propa-gation in FPGAs, IEEE Transactions on Nuclear Science,vol. 52, no. 6, pp. 2438-2445, Dec. 2005.

[15] R. Velazco, G. Foucard, and P. Peronnard, CombiningResults of Accelerated Radiation Tests and Fault Injec-


124

tions to Predict the Error Rate of an Application Imple-mented in SRAM-Based FPGAs, IEEE Transactions onNuclear Science, vol. 57, no. 6, pp. 3500-3505, Dec. 2010.

[16] H. Ziade, R. A. Ayoubi, R. Velazco, and T. Idriss, A NewFault Injection Approach to Study the Impact of Bitflips inthe Configuration of SRAM-based FPGAs, InternationalArab Journal of Information Technology, vol. 8, no. 2, pp.155-162, 2011.

[17] L. Benini and G. De Micheli, Networks on Chip: a NewParadigm for Systems on Chip Design, in Proceedings ofthe Design, Automation and Test in Europe Conferenceand Exhibition (DATE), 2002, pp. 418-419.

[18] Xilinx Corporation, Microblaze Processor ReferenceGuide, UG081 (v13.4), 2012.


125

XIII Jornadas de Computación Reconfigurable y Aplicaciones JCRA ...

Documents

Transcript of XIII Jornadas de Computación Reconfigurable y Aplicaciones JCRA ...