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
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)
x
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 1: Digital Signal Processing & IP Cores
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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/
Capítulo 1: Digital Signal Processing & IP Cores
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 1: Digital Signal Processing & IP Cores
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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-
Capítulo 1: Digital Signal Processing & IP Cores
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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].
Capítulo 1: Digital Signal Processing & IP Cores
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 1: Digital Signal Processing & IP Cores
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 1: Digital Signal Processing & IP Cores
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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:
Capítulo 1: Digital Signal Processing & IP Cores
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 1: Digital Signal Processing & IP Cores
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 1: Digital Signal Processing & IP Cores
22
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 1: Digital Signal Processing & IP Cores
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 1: Digital Signal Processing & IP Cores
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).
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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]; } }
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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)
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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;
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
35
} 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.
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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/
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
39
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
45
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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)
[email protected], [email protected], [email protected]
(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].
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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-
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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-
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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).
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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,
fff, 0, BORDER_DEFAULT);
...
boxFilter(Dx2, Dxx, Dx2.depth(), Size(2, 2),
Point(-1,-1), false, BORDER_DEFAULT );
boxFilter(Dy2, Dyy, Dx2.depth(), Size(2, 2),
Point(-1,-1), false, BORDER_DEFAULT );
boxFilter(Dxy, Dxy1, Dx2.depth(), Size(2, 2),
Point(-1,-1), false, BORDER_DEFAULT );
...
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,
fff, 0, BORDER_DEFAULT);
Sobel(src_gray, Dy, CV_32F, 0, 1, 3,
fff, 0, BORDER_DEFAULT);
...
boxFilter(Dx2, Dxx, Dx2.depth(), Size(2, 2),
Point(-1,-1), false, BORDER_DEFAULT );
boxFilter(Dy2, Dyy, Dx2.depth(), Size(2, 2),
Point(-1,-1), false, BORDER_DEFAULT );
boxFilter(Dxy, Dxy1, Dx2.depth(), Size(2, 2),
Point(-1,-1), false, BORDER_DEFAULT );
...
calcHarris(cov, dst, k );
#pragma amazynq_end: //Pragma Salida
...
Figura 5: Codigo con Pragmas
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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].
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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-
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 2: Lenguajes de Alto Nivel y Comparativas
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
[email protected], [email protected], [email protected]
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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):
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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).
Capítulo 3: Architecture and Designs of Systems-On-Chip
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 3: Architecture and Designs of Systems-On-Chip
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 3: Architecture and Designs of Systems-On-Chip
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
81
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
Capítulo 3: Architecture and Designs of Systems-On-Chip
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 3: Architecture and Designs of Systems-On-Chip
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 3: Architecture and Designs of Systems-On-Chip
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 3: Architecture and Designs of Systems-On-Chip
88
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 3: Architecture and Designs of Systems-On-Chip
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 3: Architecture and Designs of Systems-On-Chip
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 3: Architecture and Designs of Systems-On-Chip
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 4: Cryptography & Fault Tolerance
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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ó
Capítulo 4: Cryptography & Fault Tolerance
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 4: Cryptography & Fault Tolerance
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 4: Cryptography & Fault Tolerance
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,
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 4: Cryptography & Fault Tolerance
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
109
Capítulo 4: Cryptography & Fault Tolerance
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 4: Cryptography & Fault Tolerance
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 4: Cryptography & Fault Tolerance
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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).
Capítulo 4: Cryptography & Fault Tolerance
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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.
Capítulo 4: Cryptography & Fault Tolerance
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-
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 4: Cryptography & Fault Tolerance
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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
Capítulo 4: Cryptography & Fault Tolerance
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
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
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-
Capítulo 4: Cryptography & Fault Tolerance
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.
XIII Jornadas de Computación Reconfigurable y Aplicaciones (JCRA 2013)
125