Estudio de sistemas MPSoC - diseño y emulación de un canal de comunicación MIMO en FPGA

Texto completo

(1)Trabajo para obtener el tı́tulo de Magı́ster en Ingenierı́a Electrónica. Estudio de sistemas MPSoC - Diseño y emulación de un canal de comunicación MIMO en FPGA Oscar David Sánchez González. Antonio Garcı́a, Mauricio Guerrero, Universidad de los Andes Christophe Jego, Matthieu Arzel, Instituto Telecom Bretagne. Enero de 2009. Departamento de Ingenierı́a Electrónica Facultad de Ingenierı́a Universidad de los Andes Bogotá.

(2) 2.

(3) Índice general 1. Introducción. 5. 2. Multiprocessor System-on-Chip (MPSoC) 2.1. Definición . . . . . . . . . . . . . . . . . . 2.2. Retos de diseño . . . . . . . . . . . . . . . 2.3. Estructura general . . . . . . . . . . . . . 2.3.1. Arquitectura y Control . . . . . . . 2.3.2. Software . . . . . . . . . . . . . . . 2.4. Networks on Chip (NoC) . . . . . . . . . .. . . . . . .. 1 1 2 3 3 5 6. . . . . . .. 13 13 13 15 15 16 18. . . . . .. 21 21 21 22 22 24. . . . . . . . .. 27 27 27 28 30 33 33 34 35. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 3. Scheduling 3.1. Descripción del problema . . . . . . . . . . . . . . . . . . 3.1.1. Scheduling en sistemas MPSoCs . . . . . . . . . . 3.2. Representación de algoritmos a través de grafos acı́clicos 3.2.1. Planteamiento del problema . . . . . . . . . . . . 3.2.2. Estudio del problema . . . . . . . . . . . . . . . . 3.3. Algoritmos de scheduling para sistemas embebidos . . . . 4. Herramientas y Lenguajes 4.1. SystemC y TLM . . . . . . . . . . . . . . . 4.1.1. Instalación de SystemC sobre Linux . 4.1.2. Instalación de TLM sobre Linux . . . 4.1.3. Instalación de ArchC sobre Linux . . 4.2. Revision de Ptolemy II [57] y Metropolis [58]. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . .. . . . . . .. . . . . .. 5. Caso de estudio - Sistema MPSoC 5.1. Desarrollo del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. Requerimientos, Restricciones y Definición de las especificaciones 5.1.2. Granularización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3. Definición de la arquitectura . . . . . . . . . . . . . . . . . . . . . 5.1.4. Particionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.5. Descripción Software y Hardware . . . . . . . . . . . . . . . . . . 5.1.6. Sı́ntesis Hardware y Compilación Software . . . . . . . . . . . . . 5.1.7. Integración y co-simulación . . . . . . . . . . . . . . . . . . . . . 3. . . . . . .. . . . . . .. . . . . .. . . . . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . . . .. . . . . . .. . . . . . .. . . . . .. . . . . . . . ..

(4) 4 6. MIMO channel emulator onto FPGA 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1. Problem formulation . . . . . . . . . . . . . . . . . . 6.1.2. MIMO communication channel model . . . . . . . . . 6.2. AWGN generator . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Desired noise characteristics and system specifications 6.2.2. Methods for noise generation . . . . . . . . . . . . . . 6.2.3. System implementation . . . . . . . . . . . . . . . . . 6.3. AWGN generator for multiple variables . . . . . . . . . . . . 6.3.1. System design . . . . . . . . . . . . . . . . . . . . . . 6.3.2. Hardware implementation . . . . . . . . . . . . . . . 6.3.3. Channel Emulation . . . . . . . . . . . . . . . . . . . 6.4. System integration . . . . . . . . . . . . . . . . . . . . . . . 6.5. Conclusions and final remarks . . . . . . . . . . . . . . . . .. ÍNDICE GENERAL. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. 39 39 39 40 40 40 41 44 53 53 56 58 60 63. 7. Conclusiones 65 7.1. Primera parte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.2. Segunda parte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 A. Caracterı́sticas de diferentes algoritmos de scheduling para sistemas embebidos 67 B. ULM diagram for the generation of 1 gaussian variable. 75.

(5) Capı́tulo 1 Introducción Los altos niveles de integración de los circuitos electrónicos actuales han permitido integrar un sistema computacional completo en un solo chip. Los MPSoCs (Multiprocessor systems-onchips) son la muestra más reciente de la capacidad de la tecnologı́a VLSI (Very Largescale Integration). En éstos sistemas se construye en un solo chip una estructura muy compleja compuesta por distintos procesadores, elementos hardware, bloques de memoria y una estructura completa de interconexión. Con la llegada de los MPSoCs se abre un campo enorme de posibilidades de diseño que requiere nuevas metodologı́as de diseño y herramientas de desarrollo, de modo que se aproveche efectivamente el poder computacional que ofrece embeber múltiples procesadores en un solo chip. Si no se desarrollan estas metodologı́as y herramientas, el avance tecnológico sobrepasarı́a la capacidad de los diseñadores, haciendolo irrelevante. Los retos que enfrentan los diseñadores de MPSoCs son en muchos casos diferentes a los presentados en sistemas embebidos con arquitectura monoprocesador, o en sistemas distribuidos compuestos por procesadores relativamente poderosos que operan en conjunto para realizar cierta tarea. Si bien algunas de las técnicas utilizadas en estos sistemas pueden ser aplicables, en el diseño de MPSoCs existen retos adicionales diferentes a los encontrados en la arquitectura de computadores tradicional, como restricciones fuertes de comportamiento en tiempo real y baja discipación de potencia. El objetivo de este trabajo es presentar una panorámica de las caracterı́sticas de los sistemas MPSoCs y las herramientas de diseño disponibles para aplicarlas en el desarrollo de un sistema digital. El trabajo desarrollado en Tesis I consistió en realizar una revisión del estado del arte de los MPSoC. Con base en este estudio se definirı́a la aplicación a realizar en Tesis II. En el transcurso de Tesis II se presentó la oportunidad de realizar una pasantı́a en TELECOM Bretagne, escuela de comunicaciones localizada en Brest, Francia, bajo la dirección de los profesores Christophe Jego y Matthieu Arzel. El trabajo a realizar en ésta pasantı́a consistı́a en optimizar y validar un emulador de canal AWGN, definiendo a partir de éste una versión de canal más compleja para sistemas MIMO (Multiple Input Multiple Output) sobre una FPGA. Se decidió que esta serı́a la aplicación final del trabajo. Este documento se organiza de la siguiente forma: En el capı́tulo 2 se muestran las principales caracterı́sticas de los sistemas MPSoCs, mostrando los retos de diseño y la arquitectura general que se utiliza. Se hace especial énfasis en una parte fundamental del sistema, el NoC (Network on Chip) que realiza las tareas de comunicación entre los diferentes bloques del sistema, y que se abre como un campo extenso de investigación. En el capı́tulo 3 se aborda el problema del scheduling, parte fundamental en las metodologı́as de diseño y que influye significativamente en 5.

(6) 6. CAPÍTULO 1. INTRODUCCIÓN. el desempeño del sistema. Se hace una revisión bibliográfica de diferentes trabajos que estudian el problema de scheduling, buscando los más apropiados para usarse en sistemas de múltiples procesadores. En el capı́tulo 4 se presentan 2 lenguajes de modelamiento de sistemas, que han sido ampliamente utilizados para diseño de MPSoCs. El capı́tulo 5 presenta un caso de estudio en el que se describe en SystemC un sistema que utiliza 4 procesadores para implementar el estándar de criptografı́a AES. Finalmente en le capı́tulo 6 se presenta el trabajo realizado durante la pasantı́a en TELECOM Bretagne..

(7) Capı́tulo 2 Multiprocessor System-on-Chip (MPSoC) - Generalidades 2.1.. Definición. Para definir que es un MPSoC es apropiado definir primero un SoC. Los sistemas en chip (SoC System-on-Chip) son circuitos integrados que implementan la mayor parte de un sistema electrónico. La complejidad es una caraterı́stica fundamental de los SoC, para lo cual es necesario desarrollar un conjunto de metodologı́as de diseño y herramientas de desarrollo apropiadas. Integrar un sistema completo en un chip ha encontrado aplicaciones en diferentes dispositivos comericiales [10]: Teléfonos celulares: para realizar procesamiento de señales e implementar los protocolos requeridos. Las arquitecturas deben estar diseñadas para operar con bajos consumos de potencia. Redes de telecomunicaciones. SoC especializados se utilizan para controlar altas tasas de transmisión. Sistemas de televisión digital: usados para realizar decodificación de audio y video en tiempo real. Video juegos: se requiere una compleja arquitectura paralela para generar las imágenes de los video juegos en tiempo real. Estas aplicaciones, entre algunas otras, no se implementarı́an adecuadamente con el uso de arquitecturas de propósito general, ya que no se alcanzarı́a el desempenño requerido y en algunos casos serı́a difı́cil garantizar un comportamiento en tiempo real. Un MPSoC es una extensión de un SoC, en donde se incluyen múltiples procesadores (CPUs). El uso de los MPSoC se justifica al observar la limitación de arquitecturas compuestas por un procesador conectado a diferentes periféricos hardware. De esta forma se pueden ejecutar aplicaciones similares a las que se ejecutan en un computador personal. Sin embargo, este tipo de arquitectura no es conveniente cuando las aplicaciones exigen operación en tiempo real. En este caso, el uso de múltiples procesadores puede ser una opción apropiada. Una arquitectura de múltiples procesadores simétricos no resuelve en muchos casos los problemas de diseño. Esta arquitectura, aunque disminuye los problemas de programación, 1.

(8) 2. CAPÍTULO 2. MULTIPROCESSOR SYSTEM-ON-CHIP (MPSOC). puede no ser apropiada para realizar tareas en tiempo real, que deben tener un comportamiento predecible. Por otro lado, los sistemas compuestos de múltiples procesadores heterogéneos son más eficientes en términos de área que los que están compuestos por procesadores homogéneos. Además, con los primeros se puede alcanzar un grado de paralelismo mayor.. 2.2.. Retos de diseño. Los SoCs comparten principalmente las siguientes caracterı́sticas [11]: Alto desempeño Operaciones en tiempo real Bajo consumo de potencia Bajo costo Que representan los principales retos de diseño. El desempeño se refiere a requisitos temporales estrictos. En los sistemas en chip no es solo importante la velocidad de operación, sino también el tiempo máximo (deadline) de ejecución para cada tarea. La mayorı́a de SoCs utilizados en aplicaciones reales tienen algunas tareas con deadlines en tiempo real [10]. Al ser usados en dispositivos portátiles, el bajo consumo de energı́a es un requerimiento fundamental para la mayorı́a de los SoCs. Aun cuando no se utilizaran en dispositivos móviles, es conveniente reducir el consumo de potencia para evitar el uso de empaques de cerámica, que aunque discipan más eficientemente el calor, son más costosos que los empaques plásticos. El diseño de MPSoCs, al representar directamente el uso de procesadores, implica que el diseño software es una parte fundamental [10]. Esto cambia significativamente el flujo de diseño de circuitos integrados, que antes se realizaba a partir de una aporximación puramente hardware. El diseño software para SoCs representa retos adicionales: El software debe ser extremadamente confiable. Se deben cumplir algunas restricciones usualmente asociadas a diseños hardware, como restricciones temporales y bajo consumo de energı́a. Diseño de sistemas heterogéneos. Muchos MPSoCs utilizan procesadores de diferentes caracterı́sticas, lo cual implica dificultades adicionales al programar que las dificultades que aparecerı́an en sistemas con procesadores idénticos. Diversas arquitecturas. Arquitecturas regulares, como un sistema de memoria compartida, son mucho más fáciles de programar que arquitecturas que no siguen un patron regular. El MPSoC diseñado debe permitir el uso de sofware escrito por el usuario, de modo que se pueda abarcar un mercado más grande. Esto implica el diseño de ambientes de desarrollo que es una tarea difı́cil para cada nuevo MPSoC que sale al mercado..

(9) 2.3. ESTRUCTURA GENERAL. 2.3.. 3. Estructura general. La figura 2.1 muestra la estructura general de un MPSoC. Se observa un conjunto de elementos de procesamiento (PE: procesadores, dispositivos hardware), conectados a través de una red (NoCs (Network on chip)) que puede tener una topologı́a arbitraria.. Figura 2.1: Arquitectura tı́pica de un SoC. Tomado de [10]. Debido a la posibilidad de emplear procesadores heterogéneos y diferentes protocolos de comunicación, se deben tener en cuenta los siguientes aspectos [10]: NoCs (Network on chip): Las conexiones entre los diferentes módulos crecen en complejidad, de modo que es necesario desarrollar una red interna. Sincronización: Con la integración de procesadores heterogéneos es posible tener varios maestros. Es necesario entonces utilizar mecanismos de sincronización, de modo que se puedan compartir adecuadamente los canales de comunicación. En una arquitectura con múltiples procesadores se necesitan controladores adicionales para la comunicación, de modo que se permitan el uso de ciertas primitivas de alto nivel como broadcastig. El diseño de SoCs puede ser visto como una microred [12], cuyas capas se muestran en la figura 2.2. El diseño de la microred difiere del de una red de área amplia, ya que la distancia entre los diferentes nodos es pequeña y presenta un comportamiento menos probabilı́stico. Sin embargo, se pueden hacer algunas analogı́as entre las diferentes capas que conforman el modelo de las dos. En la figura 2.2 la capa más baja es la capa fı́sica. Representa las diferentes interconexiones a nivel eléctrico y lógico. Las dos capas superiores presentan un nivel de abstracción mayor. Se describen a continuación:. 2.3.1.. Arquitectura y Control. Networks on chip (NoCs) Existen diferentes topologı́a para conectar las unidades de procesamiento en un MPSoC. La red de interconexión, a diferencia de las redes de comunicaciones de área amplia, no tiene restricciones debido a la estandarización o compatibilidad con otras redes. En el diseño SoCs la red de comunicación puede ser diseñada a la medida para la aplicación en particular. A continuación se describen posibles configuraciones para la red interna [10]:.

(10) 4. CAPÍTULO 2. MULTIPROCESSOR SYSTEM-ON-CHIP (MPSOC). Figura 2.2: Arquitectura de la microred. Tomado de [12].. Medio de comunicación compartido: El medio de transmisión es administrado por un maestro y es accedido por un dispositivo a la vez. A través del medio de comunicación se transmite información que son señales de datos, direcciones o control. Estos tipos de señales pueden ser multiplexadas en el tiempo o transmitidas a través de lı́neas dedicadas. Los buses de comunicación pueden ser sı́ncronos o ası́ncronos. Cuando varios dispositivos intentan acceder al medio a la vez debe haber una control central que es realizado por el dispositivo maestro. La configuración que utiliza un bus común es utilizada cuando el número de procesadores en el SoC es bajo, ya que presenta problemas en la escalabilidad del sistema. La configuración en bus es también ineficiente en el manejo de la energı́a. Cada dato que se transmite llega a todos los posibles receptores, con el consiguiente costo en el manejo de energı́a. Redes directas: Son redes de comunicación punto a punto. Cada nodo, que representa una unidad de procesamiento, es conectado a un conjunto de nodos vecinos. Los nodo tiene una interfaz para comunicarse con la red (router) que se encarga de realizar las tareas de comunicación. Esta configuración permite alta escalabilidad. El manejo de energı́a es también más eficiente que en las redes que utilizan un medio compartido. Redes indirectas: Al igual que las redes directas, las redes indirectas son adecuadas para manejar sistemas que integran un alto número de procesadores. Los nodos se conectan a través de switches. Control El control de la microred se refiere al conjunto de protocolos. Se realiza generalmente de forma distribuida. Se buscan administrar dinámicamente los recursos de la red para proporcionar la calidad del servicio requerida [10]. A continuación se describe brevemente la función de las capas que llevan a cabo el control, de acuerdo a la figura 2.2..

(11) 2.3. ESTRUCTURA GENERAL. 5. Capa de enlace de datos: Se encarga de controlar el acceso al medio y de corregir posibles errores en la capa fı́sica, que crecen con los altos niveles de integración. Además una alta confiabilidad en la capa fı́sica implica altos consumos de energı́a. Capa de red: Implementa el control de transportes de paquetes entre los extremos de la red. Cuando todos los nodos se comunican a través de un canal compartido, esta capa no realiza ninguna función. La capa desarrolla una labor muy importante cuando la red es directa, indirecta o mixta. Capa de transporte: Se encarga de dividir los mensajes en paquetes en la fuente, y reensamblarlos en el receptor. A diferencia de las redes de comunicaciones, el tamaño de los paquetes no está estandarizado, y se ajusta para que sea óptimo en la aplicación especı́fica que se está diseñando.. 2.3.2.. Software. Las capas descritas en las secciones 2.3.1 y 2.3.1 proporcionan una infraestructura adecuada para proveer servicios de comunicación entre nodos. Es necesario ahora brindar en el nivel de aplicación un modelo de programación apropiado, de modo que se puedan ocultar los detalles del Hardware. En computación en paralelo existen 2 modelos comúnmente usados: Memoria Compartida y Paso de Mensajes. En el primero la comunicación entre tareas se realiza cuando éstas acceden a direcciones compartidas de memoria. La comunicación en el segundo modelo se realiza por envı́o explı́cito de mensajes. El modelo de Paso de Mensajes es más apropiado en el diseño de SoCs: permite el diseño de sistemas escalables y de alto desempeño. Además, los sistemas que lo usan son más predecibles [10], caracterı́stica muy deseada en los sistemas embebidos para la implementación de sistemas en tiempo real. Por otra parte, generalmente los SoCs son especificados usando lenguajes que enfatizan en una comunicación explı́cita entre procesos1 , ası́ que usar el modelo de Paso de Mensajes lleva a una implementación más directa. En la figura 2.3 se muestra la arquitectura software por capas. Las capas mas bajas implementan los drivers y los controladores de bajo nivel. En las capas más altas se encuentra el sistema operativo y el software especı́fico. Es necesario usar un sistema operativo a la medida, que debe proveer un API apropiado, debido a las restricciones en el tamaño del código.. Figura 2.3: Capas Software. Adaptado de [10]. La figura 2.4 presenta las capas HW y SW implementadas en un MPSoC. Con ésta arquitectura se intenta aislar tanto los componentes HW como los componentes SW de la red de 1. El uso de grafos por ejemplo, como los que se proponen usar en [29]..

(12) 6. CAPÍTULO 2. MULTIPROCESSOR SYSTEM-ON-CHIP (MPSOC). comunicación. De esta forma se busca aumentar la portabilidad de los diseños, desarrollar un marco de trabajo adecuado para que se puedan diseñar los módulos HW y SW en paralelo y facilitar el uso de IPs2 .. Figura 2.4: Interfaz HW y SW en un MPSoC. Tomado de [10].. 2.4.. Networks on Chip (NoC). A continuación se trata más a fondo los NoCs, que representan una estructura fundamental en el diseño de MPSoCs. La investigación en NoCs ha adquirido un interés particular en los últimos años, como se puede ver en la figura 2.5, en donde se observa un mayor número de trabajos publicados con relación a este tema en los últimos años. En un SoC la red que interconecta los diferentes componentes del sistema representa una importancia significativa, ya que este componente podrı́a afectar en gran medida el desempeño del sistema. El diseño de un NoC consiste en hacer intereractuar una serie de componentes, muchos de los cuales han sido diseñados con anterioridad, de forma confiable. En la figura 2.6 se muestran diferentes posibles estructuras para un NoC de un teléfono móvil. La arquitectura de bus es un modelo muy utilizado debido a que se puede modelar fácilmente. Sin embargo, en un sistema altamente interconectado, esta estructura de comunicación se convierte en un cuello de botella debido a las múltiples colisiones que se puedan presentar. Una red que punto a punto que conecta los diferentes elementos de procesamiento (PE) entre si es una estructura óptima en cuanto al ancho de banda de los links de comunicación, ya que cada uno de ellos se diseña para cada par de PE. Sin embargo, a medida que aumentan los elementos que conectan a la red, el número de links crece exponencialmente, lo cual requerirı́a un área muy grande en el dispositivo. Este tipo de red serı́a viable en sistemas que tienen menos de 20 PE [14]. 2. La integración de un IP se realiza diseñando la interfaz de éste con la red de comunicación (HW wrapper en la figura 2.4)..

(13) 2.4. NETWORKS ON CHIP (NOC). 7. Figura 2.5: Número de trabajos encontrados en IEEE Xplore bajo la búsqueda “network-onchip”. Tomado de [13].. Figura 2.6: Diferentes arquitecturas para un NoC. Tomado de [14].. Una estructura de comunicación apropiada cuando el número de PE es alto es una red como la mostrada en la figura 2.6-C. Esta red consiste en usa serie de links de comunicación y una serie de nodos de ruteo. La principal ventaja de este tipo de red es la escalabilidad y el paralelismo que ofrece. La tabla en 2.1 resume las ventajas y desventajas de las estructuras de comunicación en bus y en red. La figura 2.7 muestra la estructura general de un NoC en red. Está compuesto por un arreglo de 4x4 PE (cores) que se comunican entre si a través de una red compuesta por canales de comunicación y enrutadores. En general, podemod decir que un NoC está compuesto por los siguientes elementos: Nodos enrutadores: Elementos encargados de enviar la información a los diferentes elementos de procesamiento (PE) de acuerdo al protocolo utilizado. Adaptadores de red: Bloques encargados de realizar la interfaz entre los PEs y los enrutadores. Se utilizan para separar las tareas de computación y las tareas de comunicación. Links de comunicación: Canales de comunicación que conectan los diferentes enrutadores..

(14) 8. CAPÍTULO 2. MULTIPROCESSOR SYSTEM-ON-CHIP (MPSOC) Cuadro 2.1: Pros y contras de las estructuras en bus y en red. Adaptado de [14] y [15]. Bus Pros y Contras Cada nuevo elemento añade una capacitancia parácita, que degrada el desempeño cuando crece el sistema El control del bus es cada vez más complicado a medida que crece el sistema, especialmente cuado existen varios maestros El sistema de control del bus es especı́fico para cada sistema Ancho de banda limitado y compartido Facil integración con IPs ya diseñados El concepto es simple y ya ha sido estudiado con anterioridad. -. +. -. +. -. +. -. +. +. -. +. -. Redes Pros y Contras Se utilizan canales punto a punto, de modo que el desempeño no se degrada haciendolo escalable Si el control de la red se hace no centralizado, las decisiones de ruteo son distribuidas, lo cual es apropiado para la escalabilidad del sistema. Un mismo router puede ser usado en diferentes redes El ancho de banda crece con el tamaño de la red Generalmente se necesita diseñar interfaces para añadir IPs a la red Presenta nuevos conceptos que se deben estudiar. Figura 2.7: Esquema general para un NoC. Tomado de [14].. Los NoCs se puden clasificar como redes directas e indirectas. En las primeras existe conectado, a cada nodo, un PE. En las segundas redes existen nodos que cumplen tareas de comunicación únicamente. El modelo OSI de redes puede ser adaptado al concepto de NoC, como se ha hecho por ejemplo en [16]. En la figura 2.8 se presentan los diferentes elementos de una red adaptados a la estructura general de un NoC como la mostrada en la figura 2.7. De acuerdo a este esquema, en [14] se proponen 4 temas de investigación: A nivel de sistema, adaptadores de red, red y canales de comuncación. La figura 2.9 muestra la clasificación de los temas de investigación propuestos..

(15) 2.4. NETWORKS ON CHIP (NOC). 9. Figura 2.8: Flujo de datos en el NoC mostrando las diferentes capas del modelo OSI. Tomado de [14].. Figura 2.9: Clasificación de los temas de investigación en NoCs como se propone en [14].. Al estudiar el NoC como un sistema se busca abordar el problema de diseño de modo que los detalles de implementación no se tengan en cuenta. Como se dijo anteriormente, los adaptadores de red pretenden separar las tareas de computación de las tareas de comunicación. De esta forma se pueden aumentar la reutilización de IPs. Al estudiar el NoC a nivel de red se pretende proponer arquitecturas y topologı́as que permitan ajustarse a aplicaciones particulares. En el nivel más bajo de la red están los links, que deben garantizar una comunicación confiable enfrentando en algunos casos problemas de la capa fı́sica. El diseño de adaptadores de red pretenden 3 objetivos principalmente: Separar tareas de computación (hechas en los PE) de las tareas de comunicación (hechas en la red)..

(16) 10. CAPÍTULO 2. MULTIPROCESSOR SYSTEM-ON-CHIP (MPSOC) Permitir compatibilidad con IP que implementen protocolos anteriores. Diseñarlos con bajo costo.. El adaptador de red debe implementar dos interfaces. Una con el PE y la otra con la red. Para estas dos interfaces existen 2 protocolos que se han venido convirtiendo en estándar: Open Core Protocole (OCP) [17] y Virtual Component Interface (VCI) [18]. Otras dos especificaciones son Advanced eXtensible Interface (AXI) y Device Transaction Level (DTL), de ARM y Philips Semiconductors respectivamente. La red debe proveer el soporte hardware necesario para llevar a cabo ciertas primitivas de comunicación. La topologı́a de la red indica la forma en la que se conectan entre si los diferentes elementos de procesamiento. En la figura 2.10 se muestran diferentes posibles topologias para NoCs.. Figura 2.10: Diferentes topologias para un NoC. a) Grid 2D b) Anillo c) Spidergon y d) Crossbar. Adaptado de [19]. En [20] se presenta un NoC que sigue un patrón regular formado por un anillo de 8 nodos. A partir de esta configuración básica se pueden formar redes más grandes, haciendo el diseño escalable. En [21] se presenta el desarrollo de un NoC que tiene la topologı́a mostrada en la figura 2.10-a, en donde se muestra también la implementación de los adaptadores de red. En [23] y [22] se desarrollan redes con topologı́a de arbol, que han demostrado ser eficientes en termino de los recursos hardware utilizados. Además de definir la topologı́a de la red es importante seleccionar un protocolo adecuado de ruteo, que depende en muchos casos de la aplicación a implementar. A continuación se muestran los aspectos que son objeto de estudio en la investigación de NoCs [14]: Redes orientadas a circuitos o a paquetes. En las primeras redes se reservan los recursos de antemano, y no son compartidos mientras ocurre la transferencia de datos desde la fuente hasta el destino. En las redes orientadas a paquetes, cada paquete de información contiene tanto información de ruteo como datos. En este caso los recursos son compartidos entre diversas fuentes y diversos destinatarios. Ruteo deterministico y adaptativo. En una estrategia de ruteo deterministica la ruta del paquete que se envia depende solamente de la fuente y el receptor. Por el contrario, al utilizar algoritmos de ruteo adaptativo, la ruta del paquete depende por ejemplo de la congestion de los difeentes links. Control central y distribuido. En el control centralizado las decisiones de enrutamiento se hacen globalmente, como cuando se tiene una arquitectura de bus. En el control distribuido las decisiones de ruteo se hacen localmente..

(17) 2.4. NETWORKS ON CHIP (NOC). 11. A continuación se presentan algonos ejemplos de NoCs, que según [14] son un conjunto representativo de los trabajos hechos en esta área. AETHEREAL [24] es un NoC desarrollado por Philips diseñado para garantizar ciertos niveles de servicio. La red es orientada a la conexión. La red garantiza un determinado throughput, y un servicio del mejor esfuerzo (best-effort (BE)), en donde se optimizan los recursos disponibles para obtener el mejor desempeño posible. NOSTRUM [21] es una red que sigue una topologı́a en malla. El diseño de la red se realizó de modo que se garantizara ciertos servicios. La red ha demostrado optimizar la potencia consumida. SPIN [22] es una red que implementa una topologı́a en arbol. Esta topologı́a ha demostrado ser óptima en cuanto a los recursos hardware que utiliza para realizar las tareas de ruteo. Se ha demostrado que, para ciertos recursos hardware, la topologı́a utilizada en SPIN puede simular otra red que utiliza los mismos recursos, con solo un aumento en la latencia del sistema [22]. Se implementa una red orientada a paquetes. CHAIN [25] es una red implementada únicamente con circuitos ası́ncronos. La red está diseñada para sistemas heterogéneos que han sido descritos a nivel de sistema. Al ser diseñada como un circuito ası́ncrono, la red se adapta a sistemas de bajo consumo de potencia, aprovechando las caracterı́sticas de los circuitos ası́ncronos. MANGO [26], como CHAIN, es una red ası́ncrona. Se utiliza un esquema de scheduling llamado ALG (Asynchronous Latency Guarantees). La red utiliza paso de mensajes garantizando diversos servicios..

(18) 12. CAPÍTULO 2. MULTIPROCESSOR SYSTEM-ON-CHIP (MPSOC).

(19) Capı́tulo 3 Scheduling 3.1.. Descripción del problema. Al aplicar técnicas de scheduling a diferentes problemas se pretende realizar un conjunto de tareas en el menor tiempo posible. Cada tarea consume un conjunto de recursos. Los recursos son limitados y deben ser utilizados apropiadamente de modo que se pueda minimizar el makespan (tiempo de ejecución). Las técnicas de Scheduling encuentran aplicación en distintos campos: sistemas de comunicaciones, procesamiento de señales, sistemas de control, computación en malla, investigación de operaciones, gerencia de proyectos, sistemas operativos, entre otros. El tema de interés en este documento es la aplicación de técnicas de Scheduling a sistemas de múltiples procesadores. En este caso particular se tiene un conjunto de tareas software, las cuales tienen restricciones de precedencia y comparten entre si un conjunto de datos. Para la ejecución de estas tareas se dispone de un conjunto de procesadores conectados a través de una red. Se quiere entonces determinar el orden de ejcución de las tareas, y el procesador asignado a cada una de ellas. Los sistemas de múltiples procesadores pueden ser distribuidos o no distribuidos. En los primeros cada procesador puede ejecutar tareas de una complejidad computacional relativamente alta, y se encuentran fı́sicamente distantes entre si. En los sistemas no distribuidos los procesadores no son muy poderosos y se encuentran en un mismo sistema. Un caso particular de sistemas no distribuidos son los MPSoCs (Multiprocessor system on a chip), en los cuales, dada la alta capacidad de integración de los dispositivos electrónicos actuales, se puede tener un conjunto de procesadores, de un poder computacional relativamente bajo, y una red de interconexión (NoC (network on a chip)) en un mismo chip. En estos sistemas se pueden asumir tiempos despreciables de comunicación entre procesadores en comparación con los tiempos de ejecución de las diferentes tareas, contrario a lo que ocurre en los sistemas distribuidos.. 3.1.1.. Scheduling en sistemas MPSoCs. Los MPSoCs son SoCs (System on a Chip) que integran varios procesadores, módulos Hardware y canales apropiados de comunicación. Pueden ser homogéneos o heterogéneos. Los sistemas homogéneos están compuestos por las mismas unidades de procesamiento, de modo que las diferentes tareas se ejecutarán de la misma forma en cualquier procesador. Por otro lado, los sistemas heterogéneos poseen unidades de procesamiento que pueden ejecutar ciertas tareas más eficientemente que otras. 13.

(20) 14. CAPÍTULO 3. SCHEDULING. Los diseñadores suelen expresar el algoritmo a implementar a través de un grafo acı́clio como el mostrado en la figura 3.1. En éste grafo cada nodo representa una tarea, de la cual existen estimativos del tiempo de ejecución en las diferentes unidades de procesamiento. Existe un conjunto de arcos que conectan los nodos, e indican la precedencia entre tareas. A cada arco se le asocia un número, que indica el costo de pasar de una tarea a otra. En el caso de sistemas de múltiples procesadores este peso puede ser asociado al número de bytes que se deben transferir entre tareas, o al tiempo que tomarı́a pasar de la ejecución de una tarea a la siguiente. En la sección 3.2 se muestran algunas herramientas matemáticas para el estudio de grafos, de modo que se pueda analizar su aplicación en sistemas de múltiples procesadores.. Figura 3.1: Grafo utilizado para describir el algoritmo a implementar. Además de las restricciones en la precedencia entre tareas, existen restricciones temporales que indican el tiempo máximo en el que se debe realizar cada tarea. Esto se muestra, en la figura 3.1, a través de la barra de tiempo en el costado izquierdo. Las tareas descritas por el grafo se pueden asignar a los procesadores de forma dinámica o estática. La asignación dinámica ocurre en sistemas en los que no se conoce de antemano todas las tareas a ejecutar, y se deben tomar decisiones de scheduling mientras el sistema está en funcionamiento. Esto ocurre por ejemplo en un sistema que interactúe con un usuario. Por otro lado, en la asignación estática de tareas el scheduling se realiza off-line. Este tipo de scheduling se aplica por ejemplo a sistemas de streaming. RCMPSP (resource-constrained multiprocessor scheduling problems) son problemas NPcomplete. Por esta razón se han aplicado heurı́sticas para resolverlos. Técnicas estocósticas como algoritmos genéticos o simulated annealing toman mucho tiempo para llegar a la solución. El uso de ACO (Ant Colony Optimization) ha demostrado tener una tasa de convergencia rápida, con un uso de recursos computacionales relativamente bajo (se encuentran soluciones cercanas al óptimo con un número de hormigas que se puede considerar como bajo). Los puntos más importantes a tener en cuenta en el análisis de un algoritmo de scheduling para ser aplicado en sistemas de múltiples procesadores, en particular en MPSoCs, son: Tipo de scheduling, dinámico o estático. Forma en la que se pueden incluir los tiempos de comunicación entre tareas. Forma en la que se modelan los recursos disponibles..

(21) 3.2. REPRESENTACIÓN DE ALGORITMOS A TRAVÉS DE GRAFOS ACÍCLICOS. 15. Orientado a sistemas homogéneos o heterogéneos. Forma en la que se pueden incluir restricciones de memoria. Escalabilidad del algoritmo. Tiempo promedio necesario para encontrar la solución.. 3.2.. Representación de algoritmos a través de grafos acı́clicos. Como se dijo anteriormente la especificación de un algoritmo que va a ser implementado en un sistema de múltiples procesadores se puede representar convenientemente a través de un grafo acı́clico. En esta sección se presentan una definición precisa de grafo, ası́ como también algunos resultados matemáticos que permiten analizarlo, de modo que se pueda encontrar una arquitectura cercana a la óptima para la implementación del algoritmo. Las siguientes definiciones y resultados están basados principalmente en [35].. 3.2.1.. Planteamiento del problema. Un grafo directo acı́clico (Directed Acyclic Graph (DAG)) es un grafo directo que no tiene ciclos positivos, es decir, no existen arcos de retorno. Se define de la siguiente forma: Sea G = (N, A) un DAG en donde N = 1, 2, . . . |N | es el conjunto de nodos y A es el conjunto de arcos. Cada nodo representa una operación (tarea) realizada por el algoritmo. Los arcos representan las dependencias entre tareas. Sea el arco (i, j) ∈ A. Entonces, existe una relación de precedencia entre las dos tareas, de modo que se debe realizar primero la tarea i para poder realizar la tarea j. Decimos en este caso que el nodo i es predecesor del nodo j. El out-degree del nodo i ∈ N es el número de nodos del que i es predecesor. Un camino positivo es la secuencia de nodos i0 , . . . , ik tal que (ik , ik+1 ) ∈ A para k = 0, 1 . . . k − 1. K es la longitud del camino. La longitud de un DAG se denota por D, y es la longitud del camino más largo. Si xi es el resultado de la operación correspondiente al nodo i, entonces un DAG puede ser visto como una función de la forma: xi = fi ({xj |j predecesor de i}), donde fi es la función que implementa el nodo i. Los primeros nodos realizan la tarea de leer las entradas del sistema. Se asume que estas tareas se desarrollan en un tiempo muy pequeño, que se puede considerar como despreciable. Además de especificar el algoritmo a través de un grafo, es necesario determinar los procesadores que ejecutarán las diferentes tareas. Se asume que se dispone de p procesadores, y que cada uno es capaz de ejecutar cualquier tarea (nodo en el grafo). Para cada nodo sea Pi el procesador asignado a su ejecución. Para cada nodo i que no es un nodo de entrada (i ∈ N0 ), sea ti el tiempo en el que la operación desarrollada en el nodo i se termina. Se deben imponer las siguientes restricciones: Cada procesador puede realizar solo una tarea a la vez. Esto es, si i ∈ N0 , j ∈ N0 , i 6= j, y ti = tj , entonces Pi 6= Pj ..

(22) 16. CAPÍTULO 3. SCHEDULING Si (i, j) ∈ A, entonces tj ≥ ti + 1. De esta forma se garantiza que se cumplan las restricciones de precedencia.. El resutado del Scheduling es encontrar un conjuto: {(i, Pi , ti )|i ∈ N0 }, es decir, los procesadores que ejecutaran cada una de las tareas, y el tiempo en el que cada uno se ocupa de cada tarea. El Scheduling depende en gran medida de la arquitectura del sistema. La comunicación entre procesadores puede realizarse a través de un esquema de memoria compartida, o a través de paso de mensajes. Al implementar el sistema, el acceso a memoria o la transmisión de mensajes requiere de cierto tiempo que en algunos casos no puede ser despreciado. Si la transmisión de la información desde el procesador Pi hasta el procesador Pj es τ , donde (i, j) ∈ A, entonces: tj ≥ ti + 1, Si Pi = Pj. (3.1). tj ≥ ti + τ + 1, Si Pi 6= Pj. (3.2). De esta forma se tiene en cuenta los retardos en la comunicación en el problema de Scheduling. En la desigualdad (3.1) no se tiene en cuenta τ ya que el mismo procesador ejecuta las dos tareas que son precedentes.. 3.2.2.. Estudio del problema. Es importante definir la complejidad del problema de scheduling a resolver. Se pueden establecer algunos estimativos de complejidad: Número de procesadores Tiempo de ejecución del algoritmo. Número de datos transferidos entre tareas A continuación se presentan algunas definiciones que ayudan a establecer formalmente la complejidad de un problema de scheduling que ha sido representado a través de un DAG. Se tiene un DAG G = (N, A), que va a ser implementado en un sistema que tiene p procesadores a través del schedule {(i, Pi , ti )|i ∈ N0 }. El tiempo de ejecución del algoritmo en el sistema está dado por: máxi∈N ti . Se define la complejidad de tiempo para el DAG G como: Tp = mı́n{máx ti } i∈N. (3.3). Tp es entonces el tiempo mı́nimo en el que se puede ejecutar el algoritmo con p procesadores Se define: T∞ = mı́n Tp p≥1. (3.4). T∞ es el tiempo mı́nimo de ejecución del algoritmo si se tiene un número de procesadores ilimitado. Existe sin embargo un número óptimo de procesadores (muchas veces dificil de encontrar) para ejecutar las tareas en el DAG. Sea p∗ un entero tal que Tp = T∞ para todo p ≥ p∗ , entonces p∗ es el número óptimo de procesadores para implementar el algoritmo lo más rápido posible..

(23) 3.2. REPRESENTACIÓN DE ALGORITMOS A TRAVÉS DE GRAFOS ACÍCLICOS. 17. Se puede demostrar (ver [35]) que T∞ = D. Sea A un subconjunto de R y f : A 7→ R y g : A 7→ R 2 funciones. La notación f (x) = O(g(x)) [respectivamente, f (x) = Ω(g(x))] significa que existe una constante positiva c y un x0 tal que para todo x ∈ A, con x ≥ x0 , tenemos |f (x) ≤ cg(x)| [respectivamente, f (x) ≥ cg(x)]. La notación f (x) = Θ(g(x)) significa que f (x) = O(g(x)) y f (x) = Ω(g(x)). A continuación se muestran ciertas propiedades para Tp , que son muy útiles para establecer el número óptimo de procesadores a utilizar: Propiedad 1 Si para cada nodo de salida i existe un camino desde cada nodo de entrada y cada nodo tiene como precedente al menos 2 nodos, se puede establecer la relación: T∞ ≥ log n. (3.5). con n igual al número de nodos de entrada. Este resultado relaciona la forma en la que cambia el tiempo de ejecución si hay un cambio en el número de procesadores utilizados: Propiedad 2 Si c > 0 es un entero y q = cp, entonces Tp ≤ cTq . Es decir, si el número de procesadores se reduce por cierto factor, el tiempo de ejecución se incrementa por máximo ese factor. Propiedad 3 Si p ≥ T1 /T∞ , entonces Tp < 2T∞ . Más generalmente, si p = Ω(T1 /T∞ ) entonces Tp = O(T∞ ). Propiedad 4 Si p ≤ T1 /T ∞, entonces: T1 T1 ≤ Tp < 2 p p. (3.6). Más generalmente: si p = O(T1 /T∞ ) entonces Tp = Θ(T1 /p). Las dos últimas propiedades son muy importantes, ya que ayudan a estimar el número adecuado de procesadores. En la propiedad 3 se establece que un número Ω(T1 /T∞ ) de procesadores es suficiente para tener un tiempo de ejecución que es un factor constante de T ∞. Esto puede sujerir una metodologı́a de diseño [35] en donde se realiza el scheduling suponiendo un número ilimitado de procesadores, y después se adapta el algoritmo al número disponible. Esta aproximación es mucho mejor que intentar resolver un problema de scheduling óptimamente desde el comienzo. La propiedad 4 establece que con un número p = O(T1 /T∞ ) se puede aumentar la velocidad de ejecución por un factor proporcional a p. Podemos entonces concluir que [35]: Con un número de procesadores igual a T1 /T∞ , se obtiene un tiempo óptimo de ejecución, y un aumento óptimo en la velocidad de ejecución (con respecto a si se ejecutara con un solo procesador)..

(24) 18. CAPÍTULO 3. SCHEDULING. 3.3.. Algoritmos de scheduling para sistemas embebidos. Se hizo una extensa revisión bibliográfica de las técnicas de scheduling para sistemas embebidos en general, buscando la forma en la que se podrı́an adaptar a sistemas de múltiples procesadores. Los trabajos analizados se estudiaron teniendo en cuenta los siguientes tópicos: Caracterı́sticas del algoritmo. Forma en la que se especifica el sistema, granuladidad de las tareas y tipo de grafos utilizados (cı́clicos o acı́clicos). Caracterı́sticas de los sistemas en los que se puede utilizar. Diseñado para sistemas homogéneos o heterogéneos y arquitectura del sistema. Caracterı́sticas deseables. Escalabilidad del algoritmo, costo computacinal, optimización de recursos hardware. Herramientas utilizadas. Software, lenguajes de programación, y disponibilidad de los mismos. Las técnicas de scheduling se pueden clasificar en dos grandes grupos: scheduling estático y no estático. El primero se realiza off-line, es decir en el momento de diseñar el sistema, antes que éste empiece a funcionar. Este scheduling es aplicable a sistemas DSP, en donde existen fuertes restricciones de tiempo y un funcionamiento periodico. En el segundo tipo de scheduling el planeamiento de tareas se realiza cuando el sistema se encuentra funcionando, dependiendo de las entradas del mismo. Esto ocurre en sistemas reactivos en los que existe una interacción con un usuario o con el entorno. Un algoritmo de scheduling puede ser preemptive o nonpreemptive, lo cual se refiere a la capacidad de interrumpir temporalmente una tarea para ser reanudada más tarde. Este tipo de planeamiento requiere un conjunto de servicios proporcionados generalmente por un sistema operativo, de modo que se pueda guardar y realizar el cambio de contexto de las tareas interrupidas y reanudadas. El scheduling dinámico se realiza en la mayorı́a de los casos a través de tablas de prioridad, es decir, se va creadondo en tiempo de ejecución una tabla en la que se establece el orden de las tareas. La prioridad de cada tarea puede ser constante, o puede variar en cada instante en función del estado del sistema. El scheduling estático puede basarse en técnicas heurı́sticas o no heurı́sticas, las cuales no serı́an aplicables a sistemas reactivos. Entre las técnicas no heurı́sticas se destacan métodos de optimización como programación lineal y programación lineal entera. Entre los métodos no rigurosos se encuentran métodos probabilisticos como algoritmos genéticos, Simulated Annealing y Ant colony optimization (ACO). Se han propuesto también heurı́sticas para establecer tablas de planeamiento estáticas. Las referencias [36] hasta [55] fueron los documentos base para el estudio de los diferentes algoritmos de scheduling. En la tabla A.1 se muestran las caracterı́sticas más relevantes de los diferentes trabajos, teniendo en cuenta los aspectos mencionados anteriormente. Los que presentan mejores caracterı́sticas son: [36], [37], [42], [43], [47], [48], [52], [53] y [54]. En la figura 3.2 se clasifican los trabajos más relevantes de acuerdo a los diferentes tipos de scheduling estático. Se indica también si las técnicas de scheduling propuestas tienen en cuenta la distribución de memoria y los retardos de comunicación entre las diferentes unidades de procesamiento. Además se indica si el algoritmo fue diseñado para realizar el scheduling de tareas con una granularidad fina o gruesa..

(25) 3.3. ALGORITMOS DE SCHEDULING PARA SISTEMAS EMBEBIDOS. 19. Figura 3.2: Clasificación de los algoritmos de scheduling. Se muestran los algoritmos que presentan caracterı́sticas más relevantes.. Es deseable que el algoritmo haya sido diseñado para sistemas heterogéneos, de modo que sea aplicable a un conjunto más amplio de arquitecturas. Si se tienen en cuenta los retardos de comunicación entre los diferentes elementos de procesamiento se está modelando de forma más precisa el sistema, pudiendo ası́ considerar diferentes tipos de NoCs para seleccionar el más apropiado. DLS (Dynamic Level Scheduling) [47] fue uno de los mejores algoritmos encontrados, debido a su sencilles (se realiza a través de una heurı́stica fácil de implementar) y a que considera sistemas heterogéneos y retardos de comunicación entre procesos. El resultado del algoritmo de scheduling puede ser representado a través de un diagrama de Gantt, en donde se especifica las tareas que debe ejecutar cada elemento de procesamiento y el momento en el que lo debe hacer. TORSCHE [56] es un toolbox desarrollado en Matlab para facilitar el estudio de algoritmos de scheduling. Existen diferentes algoritmos ya implementados. El toolbox provee un conjunto de herramientas para facilitar la representación del resultado del planeamiento de tareas. En la figura 3.3 se muestra la especificación de un algoritmo y el resultado del scheduling mostrado a través de un diagrama de Gantt..

(26) 20. CAPÍTULO 3. SCHEDULING. Figura 3.3: Diagrama de Gantt utilizado para representar el resultado del scheduling en un sistema compuesto por dos procesadores. Las tareas se especifican a través del grafo mostrado. Adaptado de [56].

(27) Capı́tulo 4 Herramientas y Lenguajes 4.1.. SystemC y TLM. SystemC (estandar IEEE 1666T M − 2005) es un leguaje para diseño de sistemas basado en C++. Inicialmente se consideró como un lenguaje de descripción de HW similar a VHDL. Sin embargo, en las últimas versiones ha evolucionado para hacer descripciones a nivel de sistema, modelando bloques HW y SW. SystemC está constituido por el lenguaje en si, y una serie de librerı́as. La librerı́a de verificación (SystemC Verification library (SCV)) provee soporte para realizar verificación a alto nivel. Fue dise´ nada originalmente por Cadence.. 4.1.1.. Instalación de SystemC sobre Linux. Se pretende desarrollar una descripción a nivel de sistema de la plataforma, partiendo en principio de una descripción en SystemC [30]. A continuación se hace una descripción del proceso de instalación de SystemC sobre Linux. Descargar las fuentes. La última versión es la 2.2.0 y está disponible en:. http://www.systemc.org/members/download_files/check_file?agreement=systemc_2-2-0_07-03-1. Descomprimir las fuentes: • tar xf systemc-2.2.0.tgz Fijar la variable de entorno CXX: • export CXX=g++ Crear un directorio temporal en donde se compilaron los archivos: • cd systemc-2.2.0 • mkdir objdir • cd objdir. 21.

(28) 22. CAPÍTULO 4. HERRAMIENTAS Y LENGUAJES En este ejemplo la instalación se realizará en /usr/local/systemc-2.2.0, de modo que primero se crea el directorio: • sudo mkdir /usr/local/systemc-2.2.0 Y después se ejecuta el script de configuración: • ../configure –prefix=/usr/local/systemc-2.2.0 Finalmente se realiza la compilación e instalación: • make • sudo make install. 4.1.2.. Instalación de TLM sobre Linux. TLM (Transaction-Level Modeling) es un nuevo concepto sin una definición precisa [31]. TLM se refiere en general a una metodologı́a de diseño, que puede partir de una descripción en SystemC. La metodologı́a de diseño pretende modelar solo el nivel de detalle necesario por que varios grupos de ingenieros puedan desarrollar los componentes y subsistemas en el proceso de desarrollo. Teniendo en cuenta solo los detalles necesarios, se pueden hacer modelos rápidamente, realizando cambios sin mayores problemas, y generando simulaciones más eficientes. TLM no es un concepto que se restrinja a un lenguaje en particualar. Sin embargo, SystemC es apropiado para usarlo, ya que soporta refinamiento independiente de la funcionalidad y la comunicación, caracterı́stica fundamenteal para desarrollar sistemas usando TLM [31]. Para la instalación de TLM se debe descargar el archivo disponible en: http://www.systemc.org/members/download_files/check_file?agreement=tlm-1_0 Y se descomprime: tar xf TLM-1.0.tar.gz Actualmente está disponible la versión 1.0. La versión 2 se encuentra en revisión pública.. 4.1.3.. Instalación de ArchC sobre Linux. ArchC [32] es un lenguaje de descripción de arquitecturas (ADL) cuyo principal objetivo es proveer suficiente información al nivel correcto de abstracción para que los usuarios pueda explorar y verificar nuevas arquitecturas, a través de la generación automática herramientas de software como assemblers, simuladores, y co-verificación de interfaces [33]. El proceso de instalación de ArchC es el siguiente: Descargar las fuentes disponibles en: http://downloads.sourceforge.net/archc/archc-2.0.tar.gz Descomprimir el archivo descargado.

(29) 4.1. SYSTEMC Y TLM. 23. • tar xvfz archc-2.0.tar.gz Ejecutar el script de configuración: • cd archc-2.0 • ./configure –prefix=INSTALL PATH después se realiza la compilación e instalación • make • make install En donde INSTALL PATH es la ruta donde se realizará la instalación. El script de configuración acepta además las siguientes opciones: --with-systemc=<systemc-path> -> NEEDED if simulators are to be generated --with-binutils=<binutils-path> -> if you plan to generate binary utilities --with-gdb=<gdb-path> -> if you plan to generate debugger (gdb) --with-tlm=<tlm-path> -> if you want the new ArchC TLM communication capabilities <binutils-path> es la ruta en la que se ha descomprimido binutils. Estas herramientas son necesarias si se quieren generar assemblers. Para esto se debe descargar la herramienta disponible en (versión 2.15 o superior): http://ftp.gnu.org/gnu/binutils Luego se descomprime el archivo: tar xzf binutils-2.16.tar.gz. En el proyecto ArchC se ha desarrollado un conjunto de scripts y herramientas que se agrupan bajo el nombre de ArchC Reference Platform (ARP). ARP fue creado inicialmente como una guı́a de referencia para los usuarios, de modo que pudieran explorar las capacidades de comunicación de ArchC 2.0 TLM para crear modelos de plataformas [34]. El ARP se ha convertido en un marco de trabajo para desarrollar plataformas de forma relativamente rápida. La principal idea de ARP es organizar los IPs y los modelos de las plataforas de modo que la compilación y la ejecución de la plataforma se pueda automatizar a través de scripts y makefiles. En la figura 4.1 se muestra la arquitectura del ARP. Los usuarios almacenarán los componentes de la siguiente forma: bin: Conjunto de scripts. doc: Archivos de documentación. IP: IPs hardware. IS: IPs para las estructuras de comunicación. lib: Librerı́as extras para añadir funcionalidades..

(30) 24. CAPÍTULO 4. HERRAMIENTAS Y LENGUAJES Platforms: Plataformas diseñadas. Processors: Modelos de procesadores escritos en ArchC. SW: Software a ejecutarse en los procesadores. Wrappers: Conjunto de adaptadores e intefaces para conectar IS e IPs.. Figura 4.1: Estructura del ARP. Tomado de [34].. Para instalar ARP se deben descargar las fuentes disponibles, dependiendo de la versión, en: http://143.106.24.201/%7Earchc/files/arp/arp_minimal.tgz http://143.106.24.201/%7Earchc/files/arp/arp_minimal-beta2.tgz Se crea un directorio en donde se va a descomprimir el archivo descargado: • mkdir arp minimal-beta2 • cd arp minimal-beta2 • tar xvfz ../arp minimal-beta2.tgz. 4.2.. Revision de Ptolemy II [57] y Metropolis [58]. Ptolemy II y Metropolis son dos proyectos desarrollados en la universidad de Berkeley para hacer modelamiento de sistemas heterogeneos, partiendo de modelos de computación bien definidos. Los dos proyectos tienen cosas en común1 . El estudio hecho se enfocó en Ptolemy, ya que provee una interfaz gráfica que facilita su uso. Metropolis por su parte requiere un mayor tiempo para entenderlo y aprender la sintaxis para describir modelos usando su meta model2 . Además, la forma de describir sistemas en Metropolis no es estándard, y no permitirı́a la integración con diferentes herramientas. En Ptolemy existen varios dominios en los cuales se pueden simular sistemas usando diferentes modelos de computación. El dominio se debe escoger de acuerdo a la aplicación que se desee implementar. A continuación se describen los más relevantes para aplicaciones DSP: 1. Ver por ejemplo http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIfaq.htm#metropolis. El meta model de Metropolis permite describir un sistema en varios niveles de abstracción, representando la arquitectura, permitiendo el mapeo entre diferentes plataformas para generar ejecutables para realizar simulaciones. Es también la entrada para los métodos formales de Metropolis para realizar sı́ntesis y verificación 2.

(31) 4.2. REVISION DE PTOLEMY II [?] Y METROPOLIS [?]. 25. Process Networks (PN): Este dominio modela concurrencia usando las redes de procesos de kahn (KPN) [59] como modelo de computación. Las KPN modelan apropiadamente aplicaciones de streaming, y han sido usadas en la herramienta descrita en [60]. En las redes de procesos de Kahn existe un conjunto de procesos autónomos (especificados como programas secuenciales) que se ejecutan concurrentemente y se comunican a través de canales FIFO usando una primitiva de lectura que bloquea el sistema3 . Las KPN tienen las siguientes caracterı́sticas [60]: • Es un modelo determinı́stico, haciendo que, independientemente del orden de ejecución de los procesos, se obtenga la misma salida para la misma entrada. • La comunicación entre procesos es ası́ncrona. • La sincronización entre procesos se realiza a través de la primitiva de lectura, fácilmente implementable en SW o HW. Al mapear los procesos en HW usando por ejemplo una FPGA, se obtienen bloques autónomos, solo sincronizados a través de la primitiva de lectura. • El control es completamente distribuido, no existe un Scheduler global. Como consecuencia, partir la red en un número de componentes reconfigurables o microprocesadores es una tarea sencilla. • Ya que el intercambio de datos se raliza utilizando los canales FIFO, no es necesario el uso de memorias globales que deban ser accedidas por múltiples procesadores. El trabajo presentado en [61] es un buen ejemplo del uso de las KPN. En éste trabajo se implementa, utilizando como tecnologı́a FPGAs, un sistema descrito a través de un grafo de flujo de datos. Se explora la arquitectura mostrada en la figura 4.2, optimizando los recursos disponibles en la FPGA.. Figura 4.2: Arquitectura utilizada para implementar una KPN. Tomado de [61]. Las redes de procesos de flujo de datos (dataflow process networks (DPN)) [62] son un caso especial de las KPN. El uso de DPN es conveniente ya que permite describir un programa gráficamente [62]. Ptolemy y su dominio PN son muy apropiados para este fin. 3. Un proceso, cuando lee un dato en una FIFO, se queda esperando hasta que el dato está disponible sin poder realizar otra operación..

(32) 26. CAPÍTULO 4. HERRAMIENTAS Y LENGUAJES La implementación de un sistema descrito con este modelo de computación debe tener en cuenta el tamañ de los canales FIFO. En [?] se estudia este problema, y se establecen algunos criterios para determinar cuando estos canales son limitados. Communicating Sequential Processes (CSP): En este dominio se modelan procesos concurrentes que se comunican entre si a través de mensajes enviado por canales unidireccionales. La escritura bloquea un proceso, que espera hasta que el receptor está listo para recibir los datos que se van a enviar. De la misma forma, cuando un proceso va a recibir un menaje, se bloquea hasta que éste sea enviado. A diferencia de las KPN, este modelo de computación no es determinı́stico. Synchronous dataflow (SDF): Los sistemas descritos por este modelo de computación tienen un flujo de control que puede ser determinado en el momento de la compilación. Ya que el flujo de control es simple, el modelo es apropiado para modelar sistemas de procesamiento de señal [63]. El modelo garantiza, dado que el control se conoce de antemano, que se ejecutará con memoria limitada y que nunca se bloqueará. El dominio SDF no tiene en cuenta el tiempo. Finite State Machine (FSM): Es una forma de implementar la lógica de control de un sistema. Heterochronous Dataflow (HDF): Es una extensión del dominio SDF. En el dominio HDF las tasas a las cuales se transfieren los datos entre los procesos cambian, contrario a lo que ocurre e el dominio SDF. HDF es apropiado para modelar sistemas con restricciones en el control.. De los anteriores modelos de computación se pueden considerar como maduros FSM, PN y SDF. HDF y CPS se encuentran aun en desarrollo. La versión 6.0 de Ptolemy incluye un generador automático de código en C para modelos escritos en los dominios SDF, FSM y HDF. Este generador está en una etapa de desarrollo, y posee muchas limitaciones todavia4 . El generador de código C de Ptolemy es apropiado para automatizar el proceso de sı́ntesis de sistemas digitales, ya que se puede sintetizar el código que se ejecutarı́a en los diferentes procesadores que integran el sistema. Sin embargo, el diseño de la estructura de interconexión no se ve automatizado.. 4. Ver http://ptolemy.eecs.berkeley.edu/ptolemyII/..

(33) Capı́tulo 5 Caso de estudio - Implementación del algoritmo AES en una plataforma con múltiples procesadores Se presenta la implementación del algoritmo de encripción AES (Advanced Encryption Standard) en una plataforma de múltiples procesadores. Se siguió la metodologı́a de co-diseño presentada en [29], con los ajustes necesarios para adaptarla al diseño de MPSoCs.. 5.1.. Desarrollo del sistema. 5.1.1.. Requerimientos, Restricciones y Definición de las especificaciones. La figura 5.1 muestra la metodologı́a de diseño. Las restricciones y los requerimientos, a partir de las cuales se busca plantear el problema a solucionar, son los siguientes: Implementar el estándar de criptografı́a AES, para un tamaño de clave de 128 bits. Disminuir el tiempo necesario para encriptar cada bloque de 16 Bytes1 . La figura 5.2 muestra el diagrama de caja negra. Los datos ingresan y son leidos en bloques de 8 bits. El proceso de encripción empieza después que hallan sido ingresados mı́nimo 16 bytes. Las señales que componen la interfaz son: Data in: Datos a encriptar. Los 16 primeros bytes son la llave. wr: Indica que hay un nuevo dato en Data in. rd: Leer un byte ya encriptado. rst: Señal de Reset. Data out: Datos encriptados. done: Indica que un nuevo bloque de 16 bytes ha sido encriptado. 1. No se impone una fuerte restricción en el tiempo de encripción, ya que no se llega a una implementación final.. 27.

(34) 28. CAPÍTULO 5. CASO DE ESTUDIO - SISTEMA MPSOC. Figura 5.1: Metodologı́a de co-diseño planteada en [29].. Figura 5.2: Diagrama de caja negra del sistema a diseñar.. 5.1.2.. Granularización. El algoritmo para realizar la encripción es el siguiente: 1. Expandir la llave. 2. Ejecutar AddRoundKey; Count = 0. 3. Ejecutar SubBytes. 4. Ejecutar ShiftRows. 5. Ejecutar MixCol. 6. Ejecutar AddRoundKey; Count = Count + 1..

(35) 5.1. DESARROLLO DEL SISTEMA. 29. 7. Si Count < 9 volver al paso 3, de lo contrario segur con el paso 8 8. Ejecutar SubBytes. 9. Ejecutar ShiftRows. 10. Ejecutar AddRoundKey. La primera operación a realizar es la expansión de la llave, en la cual, a partir de 16 bytes (llave inicial), se generan 160 bytes que serán usados en la rutina AddRoundKey de cada ronda del algoritmo. Las otras rutinas (SubBytes, ShiftRows y MixCol) consisten en operaciones lógicas sobre bloques de 16 bytes. Inicialmente se identifican 2 grandes tareas, que pueden llevarse a cabo de forma paralela: Expansión de la llave Encripción de bloques de 16 bytes. La primera tarea se encarga de, dada una llave de 16 Bytes, generar 10 bloques de 16 bytes que serán usados en las 10 iteraciones necesarias para encriptar cada bloque de datos. Las 10 iteraciones son desarrolladas por la segunda tarea. De esta forma tenemos el grafo mostrado en la figura 5.3, que usa tareas de complejidad relativamente alta.. Figura 5.3: Grafo de tareas inicial. Se tiene como entrada el bloque de 16 byte a encirptar y la llave, del mismo número de bytes. Cada ronda requiere, para realizar AddRoundKey, un bloque de 16 bytes proveniente de cada etapa de la expansiı̈¿ 12 n de la llave. Realizando una granularización más fina tenemos el grafo mostrado en la figura 5.4. En éste grafo se logra un mayor paralelismo, partiendo tareas como SubBytes y MixCol, en tareas más sencillas. Aunque posee un mayor paralelismo, el grafo mostrado en la figura 5.4 puede ser inconveniente debio al tiempo que se necesitarı́a para trasferir los datos entre las diferentes unidades de procesamiento. El grafo a usar dependerá de la plataforma que se tenga, que impone los mecanı́smos de comunicación a usar..

(36) 30. CAPÍTULO 5. CASO DE ESTUDIO - SISTEMA MPSOC. Figura 5.4: Grafo de tareas con una granularización más fina.. 5.1.3.. Definición de la arquitectura. MiniNoC: mMIPS based Network-On-Chip MPSoC El proyecto MiniNoC [28] es un proyecto que se realiza en la Technische Universiteit Eindhoven, y tiene por objetivo desarrollar un System-on-Chip (SoC) basado en multiprocesadores. Se utilizan procesadores mini MIPS conectados a través de un Network-on-Chip (NoC). El proyecto provee las descripciones en SystemC tanto para los procesadores mini MIPS como para el NoC. El procesador utilizado mini MIPS (mMIPS), es una versión simplificada del procesador MIPS. Tiene un set de instrucciones muy reducido, pero soporta 2 compiladores para C: GCC (con algunas opciones de configuración) y lcc. Las instrucciones soportadas por el procesador.

(37) 5.1. DESARROLLO DEL SISTEMA. 31. son las siguientes: addiu addu subu (aritméticas) and andi or ori xor xori (lógicas) beq bne (decisión) jal jalr jr j (saltos condicionales) lb lw sb sw (transferencia de datos) slti sltiu slt sltu (condicionales) sll sra srl (1, 2, 8 bits) (desplazamientos) El mMips puede sintetizarse para diferentes tamaños de memoria de programa y memoria RAM. Se puede además incluir memoria cache. Network-on-Chip Se pueden incluir 4 o 6 procesadores en el diseño, conectados a través un E-cube routing. Un número mayor de procesadores se pueden incluir realizando cambios mı́nimos al código SystemC de los enrutadores. En la figura 5.5 se muestra el diagrama de la red.. Figura 5.5: Red en chip formada por 4 enrutadores (xYyY) y 4 procesadores (dp xXyY).. Cada nodo está conectado a sus inmediatos vecinos en ambas dimensiones a través de canales unidireccionales. En la figura 5.5, dp xXyX representan los procesadores mini MIPS, y xXyY los enrutadores de la red. En la figura 5.6 se muestra un diagrama detallado de la implementación del enrutador. Cada paquete es primero enrutado en la dimensión X, hasta que alcanza un enrutador con la dirección X igual a dirección destino. Después se enruta el paquete en la dimensión Y hasta que alcanza el router destino. Como se dijo anteriormente, los nodo se comunican por canales unidireccionales..

(38) 32. CAPÍTULO 5. CASO DE ESTUDIO - SISTEMA MPSOC. Figura 5.6: Enrutador usado en la red.. Cada mMIPS tiene una interfaz de red para comunicarse con los enrutadores. Se muestra en la figura 5.7. La interfaz de red es controlada por el procesador a través de un módulo (MEMDEV) que realiza operaciones de lectura/escritura en la memoria RAM, y genera las señales adecuadas para enviar y recibir los mensajes hacia y desde el router. Existe una librerı́a C de comunicación, stdcomm, que facilita el envı́o y recepción de paquetes a través de la red.. Figura 5.7: Interfaz de red de cada procesador.. Esta arquitectura ya ha sido validada a través de simulaciones. Se han verificado los mecanismos de comunicación y formas de ejecución del código en cada procesador. El código original fue escrito en SystemC 1.0 . Se realizaron las modificaciones necesarias para actualizarlo a la última versión (2.2)..

(39) 5.1. DESARROLLO DEL SISTEMA. 5.1.4.. 33. Particionamiento. La plataforma utilizada está compuesta por 4 procesadores mMIPS, cada uno con 16KB de memoria de programa, y 16KB de memoria RAM. No se incluyó memoria caché. Para realizar la coordinación dentro de la red, uno de los procesadores actúa como maestro. En la figura 5.8 se describe el algoritmo que éste implementa. El digrama de flujo de la figura 5.9 muestra el algoritmo que realizan los 3 procesadores restantes, que actúan como esclavos.. Figura 5.8: Diagrama de flujo que describe el algoritmo que realiza el maestro. Tanto la llave como los datos a encriptar se almacenan en la memoria del procesador maestro. Éste se encarga de realizar la expansión de la llave y de envı́arla a los procesadores esclavos cada vez que éstos la soliciten. Mientras el procesador maestro realiza la expansión de la llave, se está realizando la encripción de 3 bloques de 16 Bytes a la vez. Cuando se hayan terminado de encriptar estos 3 bloques, los procesadores esclavos solicitan el siguiente bloque de 16 Bytes a encriptar al procesador maestro. Ya que la llave no cambia en el proceso de encripción, el procesador maestro entra en un estado ocioso, esperando las peticiones de los procesadores esclavos por nuevos datos para encriptar.. 5.1.5.. Descripción Software y Hardware. Para la implementación del algoritmo de encripción se adaptaron los códigos desarrollados en [27]. En éste trabajo se hizo una implementación software de las rutinas que componen el algoritmo AES en lenguaje C. La adaptación se llevó a cabo con unos cambios menores en el código. No se utilizó sistema operativo, dada la simplicidad del ejemplo. La plataforma Hardware estaba descrita en SystemC. Fue necesario sin embargo realizar algunos cambios de modo que la descripción fuera compatible con la versión 2.2..

(40) 34. CAPÍTULO 5. CASO DE ESTUDIO - SISTEMA MPSOC. Figura 5.9: Diagrama de flujo que describe el algoritmo que realiza los esclavos.. 5.1.6.. Sı́ntesis Hardware y Compilación Software. El código SystemC que describe la plataforma Hardware se compiló utilizando gcc versión 4.0.3. Ésta compilación arroja como resultado un ejecutable que es el simulador de la plataforma. Se hicieron algunas pruebas básicas de comunicación de modo que se pudiera validar la plataforma. Para la compilación del código C, que ejecuta cada procesador, se utilizó lcc. El proceso de compilación genera un archivo binario, que es después leı́do por el ejecutable que resulta de compliar el código SystemC. Dado que no se poseen herramientas que permitan sintetizar la plataforma a partir de un código SystemC, en este ejemplo se llega hasta la etapa de cosimulación. La simulación Software ser realizó compilando el código C y ejecutandolo en el computador. Para simular el comportamiento del sistema se utilizó la libreróa de C mtools, desarrollada en el proyecto [28]. Esta librerı́a implementa la funcion mprintf(), similar a printf(), pero que tiene como salida un rango de memoria del procesador. De esta forma, al final de la simulación, los mensajes que muestran el comportamiento del sistema se podrán observar verificando el contenido de la memoria de cada procesador. A continuación se muestran los resultados de la simulación que validan el correcto funcionamiento tanto de los procesadores como del NoC: NODE x0y0: ========= Node 0 up and running! Enviada tarea 1 al esclavo 1....

(41) 5.1. DESARROLLO DEL SISTEMA. 35. Enviada tarea 2 al esclavo 2... Enviada tarea 3 al esclavo 3... I received:"7" del esclavo 1 I received:"3" del esclavo 2 I received:"10" del esclavo 3 NODE x1y0: ========= Node 2 up and running! Datos recibidos: 2, 5, 2. Datos enviados al Maestro: 2, 3 NODE x0y1: ========= Node 1 up and running! Datos recibidos: 1, 5, 2. Datos enviados al Maestro: 1, 7 NODE x1y1: ========= Node 3 up and running! Datos recibidos: 3, 5, 2. Datos enviados al Maestro: 3, 10. En esta simulación el maestro (Nodo x0y0), le envı́a a cada procesador 3 bytes: El primero indica una operación a realizar (suma, resta o multiplicación), y los 2 últimos son los operandos (5 y 2). Los esclavos realizan la operación, y envı́an el resultado de vuelta al maestro.. 5.1.7.. Integración y co-simulación. A continuación se muestran los bloques que debe encripta cada procesador esclavo y la llave del sistema: Llave del sistema: EstaeslaLLAVE... Datos para el esclavo 1: MensajemMIPS1... Datos para el esclavo 2: MensajemMIPS2... Datos para el esclavo 3: MensajemMIPS3... Cada uno está compuesto por 16 bytes. La simulación arroja el siguiente resultado: NODE x0y0: ========= procesadores... XQXada expansion 7 al esclavo 2 Enviada expansion 7 al esclavo 3 Enviada expansion 8 al esclavo 1 Enviada expansion 8 al esclavo 2 Enviada expansion 8 al esclavo 3.

(42) 36 Enviada expansion Enviada expansion Enviada expansion Enviada expansion Enviada expansion Enviada expansion Enviada expansion Enviada expansion Enviada expansion Claves enviadas a. CAPÍTULO 5. CASO DE ESTUDIO - SISTEMA MPSOC 9 al esclavo 1 9 al esclavo 2 9 al esclavo 3 10 al esclavo 1 10 al esclavo 2 10 al esclavo 3 11 al esclavo 1 11 al esclavo 2 11 al esclavo 3 todos los 0. NODE x1y0: ========= Node 2 up and running! Llave Recibida... Bloque a encriptar recibido... Clave 1 recibida Clave 2 recibida Clave 3 recibida Clave 4 recibida Clave 5 recibida Clave 6 recibida Clave 7 recibida Clave 8 recibida Clave 9 recibida Empezando ultima ronda... Clave 10 recibida Bytes encriptados: 166 88 59 76 36 233 26 20 172 224 58 54 240 225 146 106 NODE x0y1: ========= Node 1 up and running! Llave Recibida... Bloque a encriptar recibido... Clave 2 recibida Clave 3 recibida Clave 4 recibida Clave 5 recibida Clave 6 recibida Clave 7 recibida Clave 8 recibida Clave 9 recibida Clave 10 recibida Empezando ultima ronda... Clave 11 recibida Bytes encriptados:.

(43) 5.1. DESARROLLO DEL SISTEMA. 37. 107 158 69 171 69 109 27 106 171 36 75 34 144 238 86 29 NODE x1y1: ========= Node 3 up and running! Llave Recibida... Bloque a encriptar recibido... Clave 1 recibida Clave 2 recibida Clave 3 recibida Clave 4 recibida Clave 5 recibida Clave 6 recibida Clave 7 recibida Clave 8 recibida Clave 9 recibida Empezando ultima ronda... Clave 10 recibida Bytes encriptados: 153 99 130 124 252 156 89 156 15 80 84 168 192 129 46 154. Para la simulacion se utilizó una frecuencia de reloj de 100MHz. Con este valor, la encripción de los 3 primeros bloques se raliza en 14.02 ms. La tasa de encripción es entonces de 27.38KB/s..

(44) 38. CAPÍTULO 5. CASO DE ESTUDIO - SISTEMA MPSOC.

(45) Capı́tulo 6 Design and implementation of a MIMO channel emulator onto FPGA device 6.1.. Introduction. 6.1.1.. Problem formulation. The design of a communication system requires the estimation of different parameters. When the system’s complexity increases, the difficulty for the parameters estimation increases as well, and it is usually impossible to achieve an exact expression for knowing the parameters values. In this case Monte-Carlo simulations are used to estimate, for example, the Bit Error Rate (BER). Monte-Carlo simulations are done generally using software models. In this case the BER estimation is very time consuming, specially at low values. In order to reduce the simulation time, it is proposed to emulate the communication system using a hardware device. Doing so, it can be constructed optimized hardware models that can operate one or more orders of magnitude faster than optimized software model [2]. Hardware emulation is however less flexible because for every system modification it is necessary to synthesize all the system, that is in many cases time consuming. But, once it is done, the simulation runs faster [3]. The main interest of this work is the architecture design for the emulation of a communication channel, done in a way that let an easy integration with a transmitter and a receiver hardware models. In this way, it could be built a whole communication system onto a FPGA device, reducing the simulation time as mentioned above. The channel is modeled as a Additive White Gaussian Noise channel (AWGN). In order to achieve a high throughput, it is imperative to implement a White Gaussian Noise Generator (WGNG) in hardware. Otherwise, the time that would be necessary to transfer the noise data, generated for example in software, could degraded considerably the system performance [1]. The system that is going to be emulated is a Multiple-Input Multiple-Output (MIMO) communication System. To this end, it should be designed a WGNG for multiples variables, reducing as much as possible the correlation between them, at the same time that the hardware resources are optimized. For the communication channel, the mathematical model is shown below. 39.