Universidad de Costa Rica Facultad de Ingeniería Escuela de Ingeniería Eléctrica. Arbitraje en el bus del sistema multiprocesador, GPU Theia

Transcripción

1 Universidad de Costa Rica Facultad de Ingeniería Escuela de Ingeniería Eléctrica IE 0502 Proyecto Eléctrico Arbitraje en el bus del sistema multiprocesador, GPU Theia Por: Hernán Bustos Torres Ciudad Universitaria Rodrigo Facio Noviembre del 2011 i

2 Arbitraje en el bus del sistema multiprocesador, GPU Theia Por: Hernán Bustos Torres Sometido a la Escuela de Ingeniería Eléctrica de la Facultad de Ingeniería de la Universidad de Costa Rica como requisito parcial para optar por el grado de: BACHILLER EN INGENIERÍA ELÉCTRICA Aprobado por el Tribunal: Ing. Diego Valverde Profesor Guía Dr. Lochi Yu Profesor lector Ing. Monry Porras Lector ii

3 DEDICATORIA A Shiao por brindarme su apoyo incondicional y una motivación especial para salir adelante con dedicación y esfuerzo durante mis años de estudio. A mis papas por la oportunidad de estudiar. iii

4 RECONOCIMIENTOS A todos los profesores que estuvieron en mi carrera por su valiosa enseñanza, a los profesores que introdujeron en mi la pasión, curiosidad y deseo de investigación en el área de las computadoras y redes y especialmente a los profesores Lochi Yu, Diego Valverde y en Enrique Coen. A todos los compañeros que durante la carrera compartieron conmigo y especialmente aquellos que con el tiempo se volvieron cercanos y brindaron su apoyo dejando de lado el compañerismo y volviéndose amigos A los tutores del presente trabajo por sus recomaciones y consejos Al personal administrativo por ater siempre con disposición, dedicación y buen ánimo mis asuntos estudiantiles durante la carrera. iv

5 ÍNDICE GENERAL 1.CAPÍTULO 1: INTRODUCCIÓN...XVII 1.1Objetivos...xvii Objetivo general...xvii Objetivos específicos...xvii 1.2Justificación...xviii 1.3Planteamiento del Problema...xx 1.4Metodología...xxii 2.CAPÍTULO 2: DESARROLLO TEÓRICO Herramientas, Verilog, Icarus verilog y GTKWave Sistemas Multiprocesadores, conceptos generales Buses de conexión en sistemas computacionales Clasificación de INs Topologías de INs Controladores en esquemas de INs, arbitraje Desempeño de los INs...34 v

6 2.4 Funcionamiento general del μp multi-núcleo Theia Memoria interleaved CAPÍTULO 3: ARQUITECTURA DE INTERCOMUNICACIÓN DEL CROSSBAR EN EL GPU THEIA Bloques y señales de intercomunicación en el crossbar Bloque TMemInterface (Module_TMeminterface.v), señales y registros Bloque de arbitraje (Module_BusArbitrer.v), señales y registros Protocolo de comunicación inicial de los bloques en el crossbar CAPÍTULO 4: DEFICIENCIAS Y MEJORAS EN EL CROSSBAR Medición del rimiento del crossbar Aumento en la cantidad de bloques de memoria Deficiencia del árbitro inicial en la concesión del recurso a los núcleos Concesión inmediata a una única solicitud Mejora de aumento de bloques y única solicitud juntas Mejora con prioridad lógica CAPÍTULO 5: CONCLUSIONES Y RECOMENDACIONES...86 vi

7 3.1 Conclusiones Arquitectura del sistema y su desempeño Medición del desempeño del sistema Desempeño y ancho banda del crossbar Sistema más susceptible a mejoras en la latencia Recomaciones Aumento de los bloques y tamaño del crossbar Mantener la versatilidad del sistema Bloque de codificación...90 BIBLIOGRAFÍA...92 APÉNDICES...96 A.1 Código fuente de las mejoras implementadas...96 A.1.1 Archivo de adefinitions...96 A.1.2 Módulo medidor del desempeño (Module_BusArbitrerCheker.v) A.1.3 Testbench donde se aplica el medidor (TestBench_Verilog.v) A.1.4 Módulos de interfaz entre el núcleo y los bloques (Module_TMemInterface.v) A.1.5 Árbitro del sistema sin mejora (Module_BusArbitrer.v) A.1.6 Módulos básicos, utilizados en la segunda mejora (Collaterals.v) A.1.7 Árbitro con mejora de concesión inmediata de una solicitud (Collaterals.v) vii

8 A.1.7 Módulos básicos, utilizados en la mejora del modulo de prioridad segunda mejora (Collaterals.v) A.1.8 Árbitro del sistema con la mejora del modulo de prioridad segunda mejora (Collaterals.v) A.1.8 Código en C++ utilizado para la medición de concesiones (Porcentaje.cpp) A.2 Probabilidades obtenidas por cada núcleo individual para las mejoras distintas mejoras A.2.1 Probabilidades sistema sin mejora A.2.2 Probabilidades de cada núcleo aumento de bloques de memoria A.2.3 Probabilidades de cada núcleo mejora de concesión inmediata A.2.4 Probabilidades de cada núcleo mejora de bloque de prioridad viii

9 ÍNDICE DE FIGURAS Figura 2.1: Arquitectura de multiprocesadores conectadas por un bus...13 Figura 2.2: Arquitectura de multiprocesador conectada por una red...13 Figura 2.3: Topología de Bus compartido...19 Figura 2.4: Topología de múltiple bus...20 Figura 2.5: Interconexión no bloqueante (a) y bloqueante (b)...21 Figura 2.6: Full-crossbar, solo un elemento de conmutación entre líneas...23 Figura 2.7: Topología de una MINs tipo Benes, (a) Topología completa (b) construcción del dispositivo de conmutación...23 Figura 2.8: Dispositivo de conmutación de un MIN de 4x Figura 2.9: Topología de una HCIN...24 Figura 2.10: Conexión uno a uno...25 Figura 2.11: Conexión multicasting...25 Figura 2.12: Cross-bar parcialmente conectado...26 Figura 2.13: Circuito lógico básico del bus arbitration (BA) con el cual se implementa el switch arbitration (SA)...29 Figura 2.14: (a) 2x2 SA (b) 4x4 SA (c)raíz 2x2 SA (d) raíz 4x4 SA...30 Figura 2.15: Arbitraje de un conmutador jerárquico para un conmutador de 32x Figura 2.16: Área estimada par el árbitro de bus diseñado por E.S. Shin et ál...33 Figura 2.17: Estimación de área para los árbitros PPA, PPE y el diseñado por E.S. Shin et ál, SA...33 Figura 2.18: Estimación del retardo par el árbitro de bus diseñado por E.S. Shin et ál...34 Figura 2.19: Estimación de retardo para los árbitros PPA, PPE y el diseñado por E.S. Shin et ál, SA...34 Figura 2.20: Topología de una red interconexión tipo delta...39 Figura 2.21: Probabilidad de aceptación para las topologías crossbar y MIN's...41 ix

10 Figura 2.22: Ancho de banda para un bus de 16x16, y las distintas topologías...42 Figura 2.23: Cantidad de transistores requeridos para 3 diferentes topologías IN...44 Figura 2.24: Área requerida por las 3 topologías distintas de IN...44 Figura 2.25: Arquitectura del GPU Theia...46 Figura 3.1: Diagrama de Bloques de la arquitectura de cada núcleo...51 Figura 3.2: Diagrama de bloques de la arquitectura descentralizada de arbitraje...55 Figura3.3: Diagrama de ondas con el protocolo del sistema, arbitraje resolvio colisiones forzadas...60 Figura 3.4: Diagrama de ondas de protocolo de comunicación en operación normal entre los núcleos y los bloques de memoria...62 Figura 4.1: Diagrama de bloques con el módulo que realiza la métrica del sistema...64 Figura 4.2: Probabilidad de aceptación vs. Cantidad de núcleos para el sistema inicial...66 Figura 4.3: Porcentaje de aceptación para varios núcleos con distintos bloques de memoria...69 Figura 4.4: Diagrama de ondas peor caso caso en la concesión del recurso...71 Figura 4.5: Diagrama de ondas para una concesión inmediata a una única solicitud...74 Figura 4.6: Sistema con mejora de concesión inmediata a una única solicitud y sistema inicial sin mejora...75 Figura 4.7: Probabilidad de aceptación con mejoras en el sistema de única solicitud y aumento de bloques...77 Figura 4.8: Circuito lógico básico del bus arbitration (BA) con el cual se implementa el switch arbitration (SA)...79 Figura 4.9: Diagrama de ondas del sistema empleando la mejora con los módulos de prioridad...81 Figura 4.10: Sistema con mejora de módulo de prioridad, sistema única solicitud y sistema inicial sin mejora...83 x

11 Figura 4.11: Sistema con mejora de módulo de prioridad y aumentando los bloques del sistema...84 Figura 4.12: Imagen obtenida sin defecto e imagen obtenida con defecto...85 xi

12 ÍNDICE DE TABLAS Tabla 2.1: Cantidad de procesadores depio de la categoría y estilo...14 Tabla 2.2: Tabla de verdad de los bloques de prioridad del circuito lógico de BA...29 Tabla 4.1: Tabla de para la determinación de colisiones en crossbar...64 Tabla 4.2: Porcentaje de aceptación por cantidad de núcleos en el crossbar...65 Tabla 4.3: Porcentaje de aceptación para los núcleos con distintos Bloques de memoria...68 Tabla 4.4: Porcentajes de aceptación del sistema, inicial, con única solicitud y diferencia en el porcentaje...76 Tabla 4.5: Valores de los porcentajes de aceptación con mejor de aumento de bloques y de única solicitud...78 Tabla 4.6: Porcentaje de mejora que se obtiene en con el aumento de bloques única solicitud...78 Tabla 4.7: Tabla de verdad de los bloques de prioridad del circuito lógico de BA...80 Tabla 4.8: Probabilidades de aceptación de las mejoras de módulo de prioridad y única solicitud...82 Tabla 4.9: Probabilidades de aceptación de las mejoras de módulo de prioridad junto con aumento de los bloques de memoria...83 Tabla 4.10: Porcentaje de mejora que se obtiene en con el aumento de bloques y modulo de prioridad...84 xii

13 NOMENCLATURA IC Circuito integrado ( integred circuit ) μp Microprocesador HDL Lenguaje de descripción de hardware ( hardware description language ) RTL Nivel de transferencia de registros ( register transfer level ) FPGA Arreglo de compuertas configurable en campo ( Field Programmable Gate Array ) ASICs Circuitos de aplicación específica ( Application-specific integrated circuit ) VLSI Integracion a muy gran escala ( very large scale og integration ) GPU Unidad de procesamiento gráfica( graphical processor unit ) ALU Unidad aritmetológica ( Arithmetic logic unit ) ROM Memoria de solo lectura ( read only memory ) CROW Lectura concurrente, escritura propia ( concurrent read owned write ) MINs Redes de interconexión de múltiples estapas ( multiplestage interconecction network ) xiii

14 HCINs Redes de interconexión crossbar de jerárquica ( hierarchical crossbar interconecction network ) INs Redes de interconexión ( interconecction network ) BW Ancho de banda ( band width ) URM Modelo de referencia uniforme ( uniform reference model ) RGA Generación de arbitraje Round-Robin ( round robin arbiter generator ) PPA Arbitraje de Ping-Pong ( Ping-Pong Arbiter") PPE Codificador de prioridad programable ( programmable priority encoder") SA Arbitraje de conmutación ("switches arbitration") SoC Sistemas en chip ( system on chip ) NoC Redes en chip ( networks on chip ) UMA Acceso uniforme a memoria ( uniform memory acces ) SMP acceso simétrico a memoria ( symmetric memory acces ) NUMA Acceso no uniforme a memoria ( no uniform memory access ) Rerizada Generar una imágen bidimencional a partir de un modelo tridimensional xiv

15 Shaders Set de instrucciones para generar efectos en una imagen rerizada Testbench Ambiente virtual utilizado para la verificación de un diseño Token Ficha, es la unidad que tiene derecho al acceso de un recurso xv

16 RESUMEN GPU Theia, es una unidad de procesamiento gráfico realizada por el profeso Diego Valverde. En el presente trabajo se realizó un estudio de la arquitectura de dicho sistema especialmente en la interconexión tipo crossbar que lo conecta. El estudio se realizó con el fin de implementar tanto una medición del desempeño del sistema así como distintas mejoras que aumentaran su desempeño. Dentro de la arquitectura de este sistema se enfocó el estudio en el arbitraje del sistema debido a que era la unidad que afectaba mas su desempeño. Para realizar los objetivos, fue necesario realizar un estudio teórico de los conceptos básicos de sistemas multiprocesadores, mediciones y desempeños de interconexiones para estos sistemas y las unidades de memorias y árbitros utilizadas en estos sistemas. Finalmente se obtuvieron y analizaron resultados experimentales con las distintas mejoras aplicadas al código fuente, con la medición implementada para el desempeño del sistema y para implementaciones del sistema variando diversos parámetros, como el número de núcleo o bancos de memoria. xvi

17 1. CAPÍTULO 1: Introducción 1.1 Objetivos Objetivo general Mejorar el bus de datos tipo cross-bar del proyecto GPU Theia Objetivos específicos Investigar y proponer mejoras al esquema de contención del bus para los ciclos de lectura de una arquitectura simple tipo Cross-Bar. Implementar un código en el lenguaje de descripción de hardware Verilog y realizar pruebas con las mejoras propuestas al árbitro del bus. xvii

18 1.2 Justificación En las últimas décadas, el mundo ha experimentado una revolución que ha afectado de manera directa a la mayoría de sociedades en los campos económicos, culturales y tecnológicos. Esta es la revolución tecnológica y su principal componente que la ha impulsado es el transistor. Se dice que dicho componente ha sido lo que la máquina de vapor fue para la revolución industrial. Debido a esta revolución, es muy común ver toda clase de sistemas electrónicos y computacionales para todo tipo de aplicaciones, de la vida moderna[16]. Grandes cantidades de aplicaciones, exigen gran diversidad de sistemas, y de diseños de IC (circuitos integrados), estables eficientes y de bajo costo. Los sistemas paralelos y distribuidos, han sido ampliamente defidos como un enfoque prometedor para la construcción de sistemas computacionales de alto desempeño y rimiento[3]. Para explotar este paralelismo estos sistemas deben ser diseñados de forma eficiente, prestando especial atención en reducir la sobrecarga de comunicación entre sus componentes, por lo que el diseño de intercomunicación de estos sistemas debe realizarse de forma eficiente, confiable y rentable[3]. Este es uno de los problema con el que nos enfrentamos en la actualidad en los sistemas multiprocesador, el problema de como comunicar entre si las unidades que se encuentran integradas, de forma eficiente, confiable y rentable. Se observa que en el diseño no siempre se logran alcanzar los tres aspectos mencionados xviii

19 anteriormente, pero se procura explotar estas tres características al máximo, para obtener las mejores ventajas de cada uno, para las distintas aplicaciones. El subsistema del bus, ha evolucionado así como lo han hecho en los últimos años los IC. Puesto que inicialmente los IC contaban con solo un procesador, conectar varios dispositivos, tales como memorias y periféricos, era una tarea que no requería del trabajo y cuidado en el diseño con que se debe contar hoy en día. Debido a la gran cantidad de unidades funcionales con que en un mismo chip cuenta en la actualidad, y a que la tecnología continuamente se encuentra escalando, en cantidad de procesadores y núcleos de memoria integrados[17] las arquitecturas tradicionales de comunicación como el bus compartido no son capaces de soportar el alto grado de tráfico en las comunicaciones[18]. En la actualidad los buses se caracterizan por que estos tienen conexiones punto a punto entre las diferentes unidades que realizarán las transacciones de información. Estas conexiones pueden hacerse estática o de forma dinámica utilizando los protocolos de comunicación entre los dispositivos para enviar información. Actualmente los buses tien a ser como las redes de comunicación, tenio esquemas en común con pequeñas diferencias, e inclusive muchas veces no se realiza diferenciación y se les llama por igual INs (interconecction networks) [3]. El esquema de bus estudiado es ampliamente encontrado en los sistemas de comunicación y redes de computadoras. xix

20 Una típica comunicación de un sistema multiprocesador, consiste en puertos de entrada, puertos de salida y algún tipo de memoria. Inclusive pueden haber unidades para las distintas aplicaciones. Depio de la congestión de tráfico pueden haber conflictos por las demandas simultaneas de los recursos, por lo que las unidades de control que regulan estos conflictos críticas para alcanzar el rimiento máximo posible de una red[10]. A dicha unidad de control se le conoce como árbitro, y utiliza algoritmos y métodos para la justa repartición de los recursos. Cada día la investigación y desarrollo de estas unidades de arbitraje, y de los subsistemas de buses y redes de interconexión se vuelven más críticos para el máximo desempeño de los sistemas multiprocesadores. 1.3 Planteamiento del Problema El GPU ( graphical processor unit ) Theia, es un μp multi-núcleo, de aplicación gráfica de código abierto. La cantidad de núcleos de ejecución de este sistema puede variar, actualmente se han realizado pruebas con 2, 4, 8 y 16 núcleos, pero inclusive puede expandirse a más núcleos, que trabajan de forma indepiente para generar una imagen rerizada por medio del método de Ray-Cast. GPU Theia es un μp gráfico que genera imágenes rerizadas, la cantidad de cálculos que debe manejar el μp para generar las imágenes, son muchos. De la misma manera la lectura y escritura de datos que debe manejar el μp desde y hacia la memoria, genera una gran cantidad de tráfico en el bus de interconexión. xx

21 La arquitectura de este procesador soporta un gran número de núcleos, y se necesita que cada núcleo sea capaz de leer información de manera concurrente, el esquema que se utiliza para comunicar estos núcleos con los bloques de memoria es un bus de tipo crossbar, conocido también como un bus matricial. Este tipo de bus permite que los núcleos tengan comunicación concurrente con los bloques de memoria, esto si todos los núcleo se comunican con bloques de memoria indepientes en un momento del tiempo. El problema con el crossbar existente, radica en el momento en que dos o más núcleos intentan comunicarse con un mismo bloque de memoria. En ese momento, el cross-bar existente es incapaz de realizar conexiones en paralelo, y los núcleos deben esperar su turno para acceder al bloque de memoria. El algoritmo con el que se implementaba la concesión del bus es un algoritmo de Round-Robin simple sin prioridades. Este esquema en particular es muy ineficiente para el acceso de datos, sobre todo cuando se trata de muchos núcleos. Si el núcleo de menos prioridad solicita la concesión del bus, el árbitro del sistema, preguntan uno a uno a todos los núcleos, quién solicitó la concesión, por lo que la eficiencia, y velocidad del sistema se ven afectados al aumentar el número de solicitantes a un mismo recurso. Para un GPU, esto limita la velocidad en la generación de las imágenes. Resumio, los principales problemas presentes en el esquema de bus son: Las altas probabilidades de colisiones, de las solicitudes de lectura a bloques iguales de memoria, por parte de los diferentes núcleos. La ineficiencia del algoritmo del árbitro para la concesión del bus. xxi

22 Las solicitudes de lectura a un mismo bloque por dos, o más núcleos del interrumpen la lectura concurrente de los datos y disminuyen el GPU que desempeño de este. 1.4 Metodología Para cumplir con los objetivos propuestos para el proyecto, se realizó una investigación, enfocándose especialmente en la topología tipo cross-bar del bus del GPU Theia. Esta investigación se basa en la teoría de funcionamiento de un bus del tipo crossbar, así como cuales son sus principales ventajas y desventajas en comparación con otros esquemas existentes. También se realizaron investigaciones en varios puntos necesarios que juegan un papel importante en la arquitectura del sistema, tales como el actual árbitro y el algoritmo de Round-Robin con el que opera dicho árbitro, el funcionamiento de este y por que este algoritmo es ineficiente para el esquema actual del bus tipo cross-bar que tiene el μp Theia. Otro punto importante que se estudió es una de las memorias del GPU, la cuál es una memoria del tipo interleaved, que tiene relación directa con el esquema de crossbar. Lo estudiado con respecto a esta memoria ayuda a determinar como su uso afecta al sistema y que se puede hacer con ella para ayudar a hacer todo el sistema aún más eficiente. Para las investigaciones fue necesario contar con conocimientos en lenguajes de descripción de hardware, especialmente en el lenguaje Verilog. También fue necesario el xxii

23 conocimiento de la arquitectura de computadoras para identificar los diferentes bloques funcionales del sistema. Para la solución de los problemas planteados anteriormente, se desarrolló código fuente en el lenguajes de descripción de hardware Verilog. Cada uno de los bloques y módulos desarrollados contó con tres etapas principales para su desarrollo. Investigación, y estudio del respectivo bloque, para observar la eficiencia del sistema. Diseño de un bloque funcional que mejorara el desempeño actual del bus. Simulación del bloque, para comprobar su correcto funcionamiento y el incremento que aporta al desempeño del sistema. Los tres principales bloques donde se desarrolló código fuente, mencionados en el punto anterior fueron: La memoria interleaved, el árbitro del corssbar, y el bus tipo crossbar. Para la compilación del código fuente se utilizó el software Icarus Verilog, junto con GTKWave para la visualización de las formas de ondas. Se llevaron a cabo simulaciones que debían generar una imagen de forma correcta para verificar el funcionamiento del sistema con los cambios propuestos. Finalmente, se implementó un modulo dentro del testbench del sistema para la obtención del desempeño del sistemas inicial y las mejoras. xxiii

24 2. CAPÍTULO 2: Desarrollo Teórico 2.1 Herramientas, Verilog, Icarus verilog y GTKWave Para el desarrollo de la investigación práctica, fue necesaria la utilización de estas dos herramientas, para el diseño y simulación del subsistema del bus, el cual se deseaba probar en el ya existente sistema del procesador multi-núcleo Theia. Una parte importante durante el proyecto fue el diseño de sistemas digitales donde la herramienta Verilog se hizo indispensable, lo que nos lleva a la pregunta qué es Verilog? Para enter que es Verilog, se necesita enter que es un HDL (por sus siglas en ingles de Hardware Description Language). Actualmente los sistemas digitales son altamente complejos y consisten de millones de elementos en su nivel de construcción más bajo, también lo sería si se observa este sistema en un nivel de compuertas lógicas y transistores de paso [21]. Realizar diseños basados en diagramas esquemáticos en estos niveles de complejidad, es una tarea ardua, por lo que para poder crear diseños realizables, se suelen usar HDL's que permiten realizar una descripción en texto del circuito electrónico, por medio de su comportamiento o documentando sus conexiones. A estos HDL's se les une la capacidad de utilizar herramientas que generan distintos niveles de abstracción. Estas herramientas son una gran colección de limitaciones y elementos, que en conjunto permiten dar una idea conceptual de un sistema digital y realizar las distintas etapas que envuelven su diseño, tales como el RTL (register transfer level), así como simulaciones, para la verificación de su correcto funcionamiento. Estas herramientas 8

25 9 también permiten la construcción de los distintos diagramas esquemáticos, tanto a nivel de compuertas, como a nivel de transistores. Verilog es uno de estos HDL's, creado originalmente entre 1983 y 1984, de forma propietaria [21], y liberado al dominio público al rededor del año En 1995 es enviado y estandarizado por IEEE standard # y en el 2001 vuelto a revisar y estandarizado como IEEE standard # Tiene una sintaxis similar a el lenguaje de programación de C, pero aunque tenga una sintaxis similar hay que hacer la diferencia de que Verilog no es un lenguaje de programación [1], si no que está pensado para describir hardware. Icarus Verilog Version 0.9.2, es una de las herramientas que pueden ser utilizadas, para el desarrollo del HDL escrito en verilog. Icarus puede mezclarse con otras herramientas [22] que permiten implementar Verilog, y a nivel de RTL, síntesis 1 y simulaciones si se desea. Para los distintos diagramas de ondas y su visualización se utilizó la herramienta GTKWave[24] que es una herramienta para sistemas Unix Win32 y Mac OSX. Gtkwave permite la lectura de los archivos estándar Verilog VCD/EVCD, que pueden ser producidos por la herramienta Icarus Verilog, para obtener y visualizar los diagramas de ondas. Estas herramientas fueron ampliamente usadas para el desarrollo del proyecto, y para el diseño y la verificación del sistema crossbar del bus y el árbitro. Además se 1 Herramienta de software que permiten de forma automática pasar de un nivel abstracto de RTL a un nivel más bajo de compuertas y Layout.

26 10 utilizaron estas herramienta por que el μp Theia ha sido escrito para poder ser sintetizado, aunque hasta el momento solo se han realizado simulaciones a nivel de comportamiento. 2.2 Sistemas Multiprocesadores, conceptos generales Para iniciar el estudio del bus del sistema GPU Theia, hay que empezar realizando un pequeño estudio de un sistema multiprocesador. Puesto que se podrían escribir varios textos solo sobre este tema, se enfatizará en los aspectos principales de estos esquemas y los que se encuentran estrechamente relacionados con el presente trabajo de investigación. En la actualidad dichos los sistemas multiprocesador se han vuelto muy comunes debido a la alta escalabilidad que permiten hoy en día los IC, permitio colocar en un mismo chip de silicio varios núcleos. Es muy común hoy en día escuchar a cerca de sistemas en chip SoC (system on chip por sus siglas en ingles) y más recientemente las redes en chip NoC (networks on chip igualmente por sus siglas en ingles), donde no solo se encuentra más de un núcleo en el chip, si no que también se encuentran otras unidades funcionales creando toda una red dispositivos. Las preguntas actuales que se encuentran alrededor del diseño de esquemas de multiprocesadores, según J. L. Henessy et al. [19] son: Cómo los procesadores en paralelo comparten datos? Cómo los procesadores en paralelo se coordinan y conectan entre ellos?

27 11 Cuantos procesadores pueden conectarse en paralelo? Para la primera preguntan existen dos conceptos importantes, los procesadores con un único espacio de direccionamiento, conocidos como procesadores de espacio compartido o memoria compartida (shared-memory processors) y los procesadores que utilizan un modelo de comunicación por mensajes (message passing). Para el primer caso, como su nombre lo dice, existe una única memoria principal la cual es compartida por todos los procesadores, mientras que para el segundo caso su memoria es privada y los procesadores se comunican a través de mensajes mediante rutinas de envío y recibo. El esquema de memoria compartida es más utilizados en IC, y en sistemas del tipo SoC, mientras que el modelo basado en la comunicación a través de mensajes se utiliza más en los esquemas de redes de computadoras y clusters, L.N. Bhuyan [3] los denomina sistemas multiprocesadores y multicomputador respectivamente. Los procesadores con memoria compartida, a su vez, se subdividen en otros dos estilos. Los procesadores de acceso uniforme o multiprocesadores simétricos, UMA o SMP (uniform memory access, symmetric multiprocessors) respectivamente. Y los procesadores de acceso no uniforme NUMA (no uniform memory access). El primer estilo se caracteriza por que los accesos a la memoria principal, toman el mismo tiempo sin importar, cuál núcleo realice el acceso, y sin importa cual palabra dentro de la memoria sea accedida. El acceso a cualquier palabra dentro de la memoria principal UMA o SMP toma el mismo tiempo. El μp Theia utiliza un esquema de este tipo donde

28 12 todos sus núcleos son simétricos, esto se puede comprobar puesto que un sólo núcleo es capaz de realizar por si mismo la tarea completa de rerizar una imagen. Por otro lado los microprocesadores NUMA cuentan con accesos a memoria no simétricos, donde el tiempo depe de qué zona de memoria se está accesando y por qué núcleo se está accesando, aunque estos últimos, son de un mayor reto para programar, pueden brindar una mayor escalabilidad. Para el caso del presente trabajo se enfatizará el estudio en los multiprocesadores de memoria compartida, puesto que el sistema multiprocesador GPU Theia utiliza un paradigma CROW (Concurrent Read Owned Write), donde se cuenta, con dos memorias, una UMA utilizada para la lectura y una Owned o propia, que es exclusiva para cada núcleo y es utilizada únicamente para la escritura, la investigación se enfoca en la memoria compartida UMA, que es la que utiliza la arquitectura de bus crossbar y el árbitro. La segunda pregunta, es uno de los objetos de estudio del actual trabajo, cómo realizan los procesadores sus conexiones en un sistema multiprocesador? Y cómo estos se comunican y coordinan para realizar varias tares por separado?, o como en este caso, una tarea en común. Existen dos tipos de interconexión, que se utilizan para realizar la organización, la coordinación, comunicación y conexión en estos sistemas. En la siguiente sección se analizará el estudio del primer tipo de conexión debido a que el sistema multi-núcleo Theia, utiliza un esquema de este tipo, los dos tipos de conexión son:

29 13 Los que son conectados por un bus, como se observa en la figura 2.1. Los que son conectados por una red, como se observa en la figura 2.2. Figura 2.1: Arquitectura de multiprocesadores conectadas por un bus Figura 2.2: Arquitectura de multiprocesador conectada por una red La tercera pregunta se responde realizando una combinación de los conceptos anteriormente vistos, J. L. Henessy et al. [19] realiza una tabla que se presenta enseguida,

30 14 donde se observa la cantidad de procesadores que se puede encontrar en un sistema, depio de su estilo y categoría: Tabla 2.1: Cantidad de procesadores depio de la categoría y estilo Categoría Estilo Modelo de Message passing NUMA comunicación Shered Memory SMP Conexión Redes física Bus Cantidad Procesadores Otro concepto importante que se estudiará es, la categorización de los sistemas multiprocesadores por sus instrucciones y datos. En 1966 Flynn tuvo la visión de como serían los procesadores en el futuro y realizó esta categorización en 4 clases diferentes, esta es conocida como la taxonomía de Flynn. Hoy en día se utiliza para la clasificación de los diferentes procesadores que podemos encontrar en el ámbito computacional: 1. SISD: Single instruction, single data, una instrucción un dato, utilizado en monoprocesadores. 2. SIMD: Single instruction, mutiple data, una instrucción múltiples datos. 3. MISD: Multiple instructions, single data, multiples instrucciones un dato. 4. MIMD: Multiple insuction, multiple data, múltiples instrucciones múltiples datos.

31 15 SISD La primera categoría es la que utilizan los procesadores de un solo núcleo, y son instrucciones que al ejecutarse son capaces de utilizar solo un dato sin explotar las instrucciones en paralelo ni el flujo de datos. SIMD La categoría SIMD es utilizada para procesadores gráficos y vectoriales que manejan grandes cantidades de datos con solo una instrucción para realizar cálculos más eficientes y mejorar el desempeño en escritura y lectura a memoria, así evita el acceso de cada dato por cada instrucción, las ventaja de esta clasificación en comparación con el de las computadoras SISD son: 1. Permite resultados indepientes a resultados previos, lo que permita pipelines más profundos y grandes tasas de reloj. 2. Una instrucción de vector se desenvuelve mejor, que muchas instrucciones simples, puesto que solo una instrucción significa, menos fetches, menos instrucciones de salto y menos saltos mal predichos. 3. Un vector de instrucciones puede realizar un acceso a un bloque de memoria por tiempo, disminuyen la latencia al acceso de memoria.

32 16 4. Estos accesos a memoria se realizan con un patrón conocido por lo que permite, que varios bancos de memoria suplan con datos. El sistema multi-núcleo Theia, es un procesador gráfico como se mencionó durante la introducción del trabajo, por lo que cada núcleo utiliza muchas operaciones vectoriales, y cada núcleo es un sistema que se encuentra dentro de esta categoría. MISD Este es una categoría que se encuentra con muy poca frecuencia, debido a que la efectividad de un sistema que utiliza múltiples instrucciones requiere de múltiples datos Sin embargo se puede encontrar en sistemas precisos que no puedan tolerar fallas y para ello requieran redundancia y utilicen paralelismo redundante. El ejemplo más representativo, es un sistema que se encuentra en un avión, donde se requieren varios subsistemas de respaldo, en caso en que uno falle se encontrará otro sistema trabajando sobre el mismo dato. MIMD Es el modelo que se encuentran, de forma general los sistemas distribuidos, donde cada procesador es indepiente y trabaja sobre datos indepientes, ya sean procesadores que compartan memoria, o procesadores de memoria privada. 2.3 Buses de conexión en sistemas computacionales

33 17 La principal diferencia entre los dos sistemas de conexión para multiprocesadores y multicomputador vistos anteriormente (conexión por bus y conexión por red) en la actualidad, radica en que una red de multicomputador es utilizado para conectar procesadores con memoria principal privada, que utilizan un modelo de comunicación de message passing, por lo este esquema es más usado, como se vio anteriormente, en los esquemas de redes de computadoras y clusters En la actualidad este esquema es utilizado ampliamente en telecomunicaciones y redes de computadoras. Mientras que los sistema de shared-memory, que son los más utilizados en microelectrónica y IC utilizan el esquema de bus Clasificación de INs Esta clasificación se da por 3 características según L.N. Bhuyan [3] ét al: Metodología de conmutación: que se divide en conmutación de paquetes y conmutación de circuitos. En el primer caso un mensaje es cortado en pequeños paquetes y transmitidos por una red en una forma de almacenar-y-reenviar (store-and-forward) en cada punto de conmutación de la red. Mientras que la conmutación de circuitos establece una ruta física entre la fuente y el destino, y los puntos de conmutación son los que establecen las diferentes conexiones para la ruta. Filosofía Temporal: Sincrónica, o asincrónica. El primer caso es ampliamente utilizado en los sistemas de control, y se caracteriza por que una señal de reloj que es emitida a todas las unidades, por lo que funcionan en una forma de bloqueo y la

34 18 comunicación se realiza solo en cada ciclo de reloj. Mientras que asíncronamente se opera sin reloj central, por lo que la comunicación se realza por medio, de protocolos como estrechamiento de mano ( hand shaking ). Estos últimos permiten más modularidad y escalabilidad, pero son mucho más difíciles de diseñar. Estrategia de control: Este se puede ser centralizado o descentralizado. La forma centralizada hay solo una fuente con todas las señales de control, donde este genera un cuello de botella. Para las topologías con gran cantidad de entradas y salidas, el diseño de este debería ser lo suficientemente complejo y eficiente para mantener un buen desempeño. Esto se puede evitar diseñando pequeños controladores, que se encuentran asociados a cada componente del sistema. A esta forma de realizar el control se le conoce como descentralizada Topologías de INs La topología de una interconexión es como están organizadas sus entradas y salidas en una red y como se interconectan todos las unidades funcionales en este, pondremos especial atención a la topología crossbar. Bus compartido (Shared Bus) Es la topología, con menor costo de implementación, pero con mayor cuello de botella, entre mayor sea la cantidad de unidades mayor será la espera para poder utilizar el bus [3].

35 19 Figura 2.3: Topología de Bus compartido Múltiples buses Anteriormente se comentó que el sistema de único bus se vuelve un cuello de botellas, que genera una reducción en el ancho de banda 2, una solución a este problema es el de conectar varios buses creando esta topología, donde se denota el sistema como NxMxB, donde N procesadores se comunican con M, memorias a través de B buses. 2 Término utilizado en el desempeño de las redes de interconexión, analizadas en la siguiente sección

36 20 Figura 2.4: Topología de múltiple bus Esquema de Bus tipo cross-bar El principal objetivo de una interconexión por medio de un esquema cross-bar, ya sea en una red o en un bus, es el de conectar un punto A con un punto B para iniciar algún tipo de comunicación [2], de forma no bloqueante, lo que cambia entre las dos conexiones es el tipo de información que se utiliza. En las redes se envían y reciben paquetes de información, mientras que en la interconexión de multiprocesadores se envían y reciben datos o instrucciones. Una conexión no bloqueante es aquella, que cuando realiza la conexión entre una entrada con una salida libre, esta siempre podrá encontrar un camino para realizar la conexión, y no es prevenida por conexiones ya realizadas, ni tampoco previene a otra entrada libre de poder conectarse con otra salida libre, si alguna conexión previene alguna otra conexión entre entradas y salidas libres, sería bloqueante en lugar de no bloqueante. Dicho concepto se puede observar en la figuras 2.5, (a) y (b) [2], donde las lineas discontinuas, representan conexiones posibles, mientras las lineas continuas

37 21 representan conexiones establecidas y los círculos negros representan puertos donde la conexión es válida. Se observa en (a) que la conexión de In0 a Out1 no previene la conexión de in1 a Out0, mientras que en (b) la conexión de In0 con Out1 previene la conexión de In1 a Out0. Figura 2.5: Interconexión no bloqueante (a) y bloqueante (b) La topología crossbar no es una única topología según Han et al. [4], este esquema se pueden categorizar en tres diferentes tipos: Una malla de interconexiones completa, a Full-crossbar. Interconexión de redes multi-etapa, multistage interconection network (MINs), cuenta con varios subtipos tales como, Benes, Omega, Delta, Baseline, Banyan, Clos entre otros. Interconexión de redes de jerarquía de crossbars, hierarchical crossbar interconnection networks (HCINs).

38 22 Lo que comparten en común estos esquemas es que las entradas libres pueden ser mapeadas con las salidas libres mediante una dirección, de una forma no bloqueante, y que su amaño se mide mediante la cantidad de entradas y salidas que sean conectadas, NxM. Un crossbar de 8x4, representa 8 entradas que pueden ser conectadas a 4 salidas. Las principales diferencias entre estos tres tipos de esquemas, es que el full-crossbar, este está constituido únicamente por dispositivos de conmutación simples llamados MINs. Estos esquemas de interconexión se conforman por múltiples capas de conmutadores simples para realizar la conexión de los diferentes caminos, y los HCINs, están compuestos por elementos de full-crossbar, que se encuentran organizados de una forma jerárquica [4]. El actual trabajo se concentrará en el tipo full-crossbar, que es que se emplea en la arquitectura del GPU Theia, los cambios realizados a dicho esquema se presentarán en los siguientes capítulos. En las siguientes figuras se presentan las distintas arquitecturas de crossbar, vistas anteriormente. Se observa en la figura 2.6 que el full-crossbar solo cuenta con una compuerta de paso que genera la conexión entre la entrada y la salida, mientras que para la arquitectura crossbar tipo MINs, figura 2.7, la unidad de conmutación es un arreglo de 4 compuertas de paso En este caso cada dispositivo de conmutación es de 2 entradas y 2 salidas pero el dispositivo de conmutación pude ampliar su rango como se observa en la figura 2.8 a un dispositivo de conmutación de 4x4, compuesto por bloques de conmutación de 2x2. En la figura 2.9 se observa una topología crossbar HCINs donde Xbar5 y Xbar6 representan topologías de crossbar que tiene una mayor jerarquía que las topologías de crossbar Xbar1,2,3 y 4.

39 23 Figura 2.6: Full-crossbar, solo un elemento de conmutación entre líneas Figura 2.7: Topología de una MINs tipo Benes, (a) Topología completa (b) construcción del dispositivo de conmutación

40 24 Figura 2.8: Dispositivo de conmutación de un MIN de 4x4 Figura 2.9: Topología de una HCIN Otras categorizaciones que pueden ser aplicados a los esquemas basados en crossbar, es en términos de su flexibilidad [2]: Bi-direcionales o unidireccionales: Para los bidireccionales los datos pueden fluir, tanto del punto A al B como de forma inversa, por lo que en este caso no se diferencia bien cuales son las entradas y cuales son las salidas, en el caso unidireccional esta diferencia es bien clara y los datos solo pueden fluir en un sentido.

41 25 Uno a uno (One-to-one) o multicasting: Uno-a-uno permite que para una entrada solo haya una salida figura 2.10, mientras que multicasting permite que una entrada tenga múltiples salidas figura Figura 2.10: Conexión uno a uno Figura 2.11: Conexión multicasting Completamente conectado o parcialmente conectado: Completamente conectado, es cuando cualquier salida puede alcanzar cualquier entrada libre. Mientras que en una red parcialmente conectada una entrada no alcanza, al menos una o más salidas dentro de la red,. En la figura 2.12 se muestra una red parcialmente conectada y en las figuras 2.10 y 2.11 se observan esquemas completamente conectados.

42 26 Figura 2.12: Cross-bar parcialmente conectado Configuración estática o dinámica: En el primer caso, la configuración del sistema se realiza durante su configuración y permanece de esta forma mientras el sistema se encuentre ejecutando y realizando una intercomunicación. Mientras que en el segundo caso, en la configuración dinámica, se permite una reconfiguración de las conexiones, incluso si se está realizando transferencia de datos en otro lugares del sistema Controladores en esquemas de INs, arbitraje Anteriormente se comentó, que una de las clasificaciones en las que se podía encontrar una IN's, es por su estrategia de control, ya sea centralizada o descentralizada. Esta estrategia de control es más comúnmente llamada arbitraje y los métodos de arbitraje son métodos necesarios para prevenir conflictos entre unidades que comparten un mismo recurso [9] y son necesarios también para proveer una eficiente y justa planificación de estos recursos. Un arbitraje centralizado se refiere a que existe únicamente un solo árbitro en el sistema, encargado de realizar todo el control del mismo. Mientras que una estrategia

43 27 descentralizada, la lógica de arbitraje es modular y cada salida tiene su propio arbitraje. Existen una gran cantidad de métodos de arbitraje así como de aplicaciones en las que son requeridos, pero no todos son óptimos para la utilización en una topología crossbar. Un arbitraje de un único bus no es la forma más óptima de realizar el control y la distribución de los recursos en un crossbar [10]. Un mal control de la repartición de recursos pueden generar que un solo procesador utilice el recurso por un tiempo indefinido, negándoselo a otro que también lo requiere, este comportamineto se le conoce como "starvation". En una topología de crossbar el mejor árbitro que se pude implementar según Hsin-Chou Chi [10], es un árbitro descentralizado. Algoritmo Round-Robin Un round-robin token passing de bus o de conmutador, es un algoritmo aplicado al arbitraje para garantizar justa repartición de los recursos. Es un algoritmo confiable que permite conocer el peor de los casos que resulta ser la cantidad de solicitantes menos uno, en este caso la cantidad de procesadores menos uno (N-1), el protocolo del algoritmo funciona de la siguiente forma[13]: Durante cada ciclo, uno de los maestros en un orden de round-robin tiene la mayor prioridad. Si el maestro que tiene el "token" no necesita el recurso en ese ciclo. El recurso le concede al maestro con la máxima prioridad, por debajo de el actual, que envíe la una solicitud.

44 28 Luego el maestro actual pasa el token al siguiente maestro en un orden de roundrobin. Comparación entre algoritmo Round-Robin, y otros algoritmos de arbitraje El diseño de un árbitro, a parte de realizarse para un justo repartimiento de los recursos debe diseñarse de tal forma, que produzca un buen desempeño en la red [10]. Para esto debe garantizarse poca latencia entre el microprocesador realizando la solicitud y el bloque de memoria concedio la solicitud. La latencia (conocida también como tiempo de respuesta), es el tiempo que se toma entre el comienzo de un evento y su finalización [20]. E.S. Shin et ál [13], realizaron un diseño sobre la aplicación de este esquema de arbitraje, en una interconexión de bus y de conmutación, utilizando una herramienta llamada RAG (Round robin Arbiter Generator ), para la elaboración de un algoritmo de round robin. Ellos realizaron estimaciones del área y del retardo que introduce dicha arquitectura al sistema y lo compararon con otros 2 esquemas de arbitraje. En las figuras 2.13 se encuentra el circuito lógico base que se utiliza en la arquitectura y la tabla 2.2 contiene la tabla de verdad del bloque de prioridad que utiliza. En las figuras 2.14 se presenta la arquitectura para un arbitraje de conmutación de 2x2 y 4x4 basado en el circuito lógico del arbitraje para bus. En la figura 2.15 se observa la extensión de este a un conmutador de 32x32, en esquema de árbol.

45 29 Figura 2.13: Circuito lógico básico del bus arbitration (BA) con el cual se implementa el switch arbitration (SA) Tabla 2.2: Tabla de verdad de los bloques de prioridad del circuito lógico de BA

46 30 Figura 2.14: (a) 2x2 SA (b) 4x4 SA (c)raíz 2x2 SA (d) raíz 4x4 SA

47 31 Figura 2.15: Arbitraje de un conmutador jerárquico para un conmutador de 32x32

48 32 En las figuras 2.16 y 2.17 se observa la estimación de área de los bloques de arbitraje de bus y de conmutación para esquemas de Ping-Pong Arbiter (PPA) [14], un Programmable Priority Encoder (PPE) [15] y el Switch Arbiter (SA), generado por E.S. Shin et ál [13]. En la figuras 2.18 y 2.19 se compara el retardo entre estas arquitecturas. En la figura 2.16, se observa que el esquema de arbitraje para el bus requiere de poca área, cuando este cuenta con valores bajos de MxM unidades de control. Esto puesto que la cantidad de compuertas requeridas para realizar la lógica de control es pequeña. Pero para valores más altos de MxM, su área crece significativamente, inclusive alcanzando valores cercanos a los árbitros de (PPA), (PPE), (SA) aunque estas contengan mayores cantidades de MxM unidades que la del bus. Para los retardos de la figura 2.18, el bus contiene el menor retardo cuando MxM cuenta con menor cantidad de unidades de arbitraje y este valor crece rápidamente después de 5, mientras que para las otros algoritmos sucede que para valores pequeños estos crecen rápidamente, y para valores altos estos se estabilizan sio SA. La arquitectura se estabiliza más rápido y que menos crece para valores pequeños.

49 33 Figura 2.16: Área estimada par el árbitro de bus diseñado por E.S. Shin et ál Figura 2.17: Estimación de área para los árbitros PPA, PPE y el diseñado por E.S. Shin et ál, SA

50 34 Figura 2.18: Estimación del retardo par el árbitro de bus diseñado por E.S. Shin et ál Figura 2.19: Estimación de retardo para los árbitros PPA, PPE y el diseñado por E.S. Shin et ál, SA Desempeño de los INs Terminología básica utilizada en la evaluación de desempeño Utilizando el método de L.N. Bhuyan ét al.[3] para le evaluación de desempeño de la INs, se necesita conocer inicialmente la terminología utilizada para los diferente parámetros que serán medidos y también se realizan ciertas suposiciones para simplificar el

51 35 modelo y poder hacer posible la realización de un modelo analítico que sea manejable. Esto puesto que si se utiliza un modelo real este sería muy complejo para poder realizar un modelo exacto[3]. En las ecuaciones 2.1 y 2.2 se observa la relación entre estos parámetros, 2.1 para buses sincrónicos y 2.2 para buses asincrónicos. T, N y λ: T representa el tiempo de escritura o lectura a memoria, N el número de procesadores y λ es la tasa de solicitudes a memoria. Ancho de banda, memory bandwith (BW): Es el promedio de módulos de memoria activos durante un ciclo de transferencia, sincrónica, activo se refiere que un procesador está realizando con éxito una operación de lectura o escritura. Probabilidad de aceptación (PA): Es la razón entre el ancho de banda esperado y la cantidad esperada de solicitudes generados por ciclo, sincrónico. Rimiento, Throughput (Thr): Promedio de paquetes entregados en una unidad de tiempo, utilizado en sistemas asincŕonicos, en multiprocesadores se mide como la cantidad de accesos completados por unidad de tiempo. Utilización del procesador (PU): Es el porcentaje de valor esperado en que un procesador se encuentra activo, se dice que el procesador está activo si se encuentra realizando computo interno sin acceder a la memoria. P u= BW N λ T ( )

52 36 Pu= Thr λ ( ) PA= BW p N ( ) Modelo de referencia uniforme, uniform reference model (URM): en este modelo se realiza la suposición de que las solicitudes a memoria principal realizadas por los procesadores se realizan con la misma probabilidad para cada módulo, este modelo es más preciso si se utiliza una memoria interleaved. Tiempo exponencial de procesamiento: La suposición se basa en que el tiempo en que se tarde en completar una solicitud y generar otra solicitud a la memoria principal es una variable aleatoria dentro de la distribución de probabilidad exponencial. Indepencia de solicitudes (también conocida como aproximación de Streker's): Supone que la solicitudes realizadas en un ciclo son indepientes de las realizadas en ciclos pasados. Esta suposición no es del todo cierta puesto que una solicitud que fue negada en un ciclo pasado, en el siguiente se volverá a realizar[3]. Para la obtención de los distintos modelos analíticos se utilizaron topologías sincrónicas y con conmutación de circuitos. Desempeño de la topología crossbar sincrónica

53 37 Esta topología puede otorgar una conexión directa entre todos los procesadores y los módulos de memoria. Esto ocurre si hay igual o mayor número de módulos de memoria que de unidades de procesamiento y si todos los procesadores realizan una solicitud a diferentes bloques de memoria en el sistema. Sin embargo esta capacidad genera un gran costo de hardware de O(NM), además que dada la aleatoriedad de los accesos a los diferentes módulos de memoria, dos o más procesadores pueden realizar solicitudes a un mismo bloque de memoria en un mismo momento del tiempo. Hacio la suposición de indepencia de solicitudes, y en un sistema con N procesadores y M módulos y con una probabilidad de p solicitudes generadas por un solo procesador con igual probabilidad para todos los bloques de memoria (URM) el ancho de banda es dado por la siguiente ecuación[3]: BW =M 1 1 P N M ( ) Desempeño de la topologías MIN's Las topología MIN's contiene un costo menor que la topología de crossbar, esta diferencia aumenta con el numero de multiprocesadores en el sistema. El costo de hardware que permiten estas topologías es de O(N logn) [3], y esta topología mantiene la conexión uno-a-uno deseada que se encuentra en el crossbar. Una topología MIN es una clasificación y dentro de esta se encuentran distintos esquemas y cada uno contiene un desempeño particular para las distintas aplicaciones, sin embargo según L.N. Bhuyan ét al.[3] la mayoria de estas IN son parecidas excepto por la interconexión entre los niveles

54 38 adyacentes, esto permite simplificar el estudio y comparación de distintas IN, obtenio una sola ecuación de una MIN tipo delta, figura 2.20, para el ancho de banda y suponer un comportamiento similar para distintas MIN's. Aplicando las suposiciones anteriormente vistas, si se tiene una red tipo delta con un tamaño de anxbn, cada nivel de la topología está constituida por un pequeño crossbar de axb. Las solicitudes en cualquier nivel dentro de la topología son indepientes y uniformemente distribuidas y los conmutadores adyacentes se comportan de forma similar por lo que se puede aplicar la ecuación ( ) de forma similar, con N=a y M=b, para las probabilidades de salidas de cada nivel de la topología se tiene la siguiente ecuación [3]: Pi 1 a Pi=1 1 b ( ) Donde, i es el i-ésimo nivel y en la ecuación ( ) se puede aplicar recursivamente para todos los niveles desde 1 i n, y la probabilidad de el último nivel determina el ancho de banda de la topología delta, la cuál es: BW =Pn b n ( )

55 39 Figura 2.20: Topología de una red interconexión tipo delta Desempeño de sistemas con multiples buses Una mejora simple que se puede agregar a la topología de único bus, que genera un gran cuelo de botella, más si se tiene una cantidad considerable de procesadores y de memorias o unidades operacionales, es el de agregar más de un bus de interconexión. Esta topología aparte de disminuir el cuello de botella, también ofrece una gran confiabilidad puesto que si alguno de los buses falla aún se encuentra, otro camino con el cual las unidades se pueden comunicar. Pero si se tiene en un sistema un mayor número de bloques de memoria o procesadores que la cantidad de buses, igual trá que haber un tiempo de espera si todos los recursos se encuentran utilizados, generando nuevamente un cuello de botella pero de menos repercusión que el de único bus. Con las suposiciones de indepencia de solicitudes y URM, para una cantidad dada de solicitudes a memoria

56 40 conocidas y conocio la cantidad de caminos dados para un direccionamiento, donde se denota x como la cantidad de bloques de memoria solicitados y M-x la cantiad de bloques libres (si se tiene una arquitectura con mayor número de bloques que de memorias), se puede obtener el ancho de banda por medio de[3]: ty N p N BW =M {1 1 } N p y 1 p N y M y y=b 1 x=b 1 x B x! M S y, x x (2.3.4 y M 7) Donde ty=min(y,m), y=b+1, y p es la probabilidad de solicitudes del procesador y la función S(y,x) junto con el factorial de x! Se obtiene de: x x! S y, x = 1 i x x i y i i=0 ( ) L.N. Bhuyan ét al.[3], realizó comparaciones con los modelos analíticos vistos anteriormente, comparando el costo del hardware y el desempeño de las tres interconexiones vistas y que se presentan en las figuras 2.21 y figura 2.22 para realizar una comparación entre estas. En la figura 2.21 se observa que la probabilidad de aceptación disminuye conforme aumentan el sistema, debido a la presencia de mayores procesadores realizando solicitudes a los distintos bloques de memoria, que aumentan la probabilidad de solicitud a bloques iguales. Esto causa una disminución en la probabilidad de aceptación, pero se observa que la topología de crossbar cerca de una distribución 4x4 este empieza a estabilizarse mientras que la topología MIN, sigue decrecio, pero con una piente

57 41 menor. Para un sistema de 16x16 el crossbar permanece estable mientras, MIN sigue disminuyo. En la figura 2.22 se observa como el ancho de banda, para sistemas con un tamaño 16x16. En este escenario el single bus brinda el menor ancho de banda, como era de predecir, puesto que un sistema de 16x16x1 generan grandes cuellos de botella, pero si se aumenta la cantidad de buses a un sistema 16x16x8 se observa que alcanza una gran cantidad de ancho de banda sobrepasando al de las MINs, y alcanzando casi el ancho de banda del crossbar. Figura 2.21: Probabilidad de aceptación para las topologías crossbar y MIN's

58 42 Figura 2.22: Ancho de banda para un bus de 16x16, y las distintas topologías Área y consumo de potencia El actual trabajo de investigación se concentra, en la investigación y diseño a nivel de RTL, por lo que principalmente se basó en el desarrollo de topologías y controladores. Estas topologías, afectan principalmente en desempeño, en cuanto ancho de banda y latencia se refiere. La idea de la mayor parte del diseño de IC es que sea realizable físicamente, por lo que aunque la potencia y área son abarcados en su mayoría a nivel de compuertas y microelectrónica, una estimación de ambos parámetros se vuelve necesaria en niveles de

59 43 abstracción más altos. Esto es especialmente cierto en la actualidad donde el éxito de las computadoras personales y sistemas móviles de comunicación buscan sistemas de menor tamaño y con menor consumo de potencia [7]. Existen actualmente métodos como el modelo basado en regresión y el modelo basado en muestreo para estimar la potencia del circuito también existen herramientas que permiten obtener una estimación de la potencia y área en niveles de abstracción de RTL[7] [8]. También por medio de una herramienta de síntesis se puede obtener la cantidad de compuertas utilizadas en el módulo diseñado y obtener una estimación de la cantidad de transistores y área a utilizada, V. Lahtinen et ál[11] desarrollaron una ecuación para estimar el área a utilizar en INs, ( ), donde N representa el número de procesadores: Area= N2 Area Switch bitwidth Area Arbiter N N Area IOBlock bitwidth ( ) 2 Enrique Coen-Alfaro[2], realizaró comparaciones entre 3 diferentes tipos IN, dos de la cuales son full-crossbar. Una se obtuvo por medio de un diseñador que dibujó manualmente los transistores en el layout y el segundo full-crossbar, obtenido mediante síntesis de un HDL mientras que la tercera se obtuvo apartir de una MINs, con configurción tipo Benes. En la figura 2.23 se observan las gráficas estimando la cantidad de transistores requerida por estas 3 topologías. Se observa que el full-crossbar, tiene un mayor costo que la topología Benes, con una mayor cantidad de transistores. Como se vio anteriormente, el

60 44 costo de un full-crossbar crece cuadraticamente si N=M, O(NxM), mientras que para una topología MIN este costo se da de forma logarítmica O(N logn). La figura 2.24 muestra el área requerida por las 3 topologías, donde se observa que aunque el full-crossbar sintetizado contiene mayor cantidad de transistores, al realizarse mediante un algorítmo de una herramienta, repartió más eficientemente la distribución de los tranasistores reducio el área utilizada por este. Figura 2.23: Cantidad de transistores requeridos para 3 diferentes topologías IN [2]

61 45 Figura 2.24: Área requerida por las 3 topologías distintas de IN [2] 2.4 Funcionamiento general del μp multi-núcleo Theia Como se mencionó brevemente en secciones anteriores, Theia es una unidad para el procesamiento gráfico o, GPU (por sus siglas en ingles de graphical processing unit), escrito en Verilog y que permite una arquitectura multi-núcleo. La tarea final que desempeña Theia es la de realizar una imagen rerizada, donde una imagen rerizada se refiere a la forma en que el proceso realiza una imagen a través de un modelo. Para realizar esta imagen de forma rerizada se utiliza un método llamado ray-cast, el cual presenta un funcionamiento paralelo, por lo que es aprovechado por la unidad multi-núcleo del Theia. Cada procesador es indepiente a los demás procesadores, al punto que cada núcleo es capaz de realizar, por si mismo, la tarea de generar la imagen, pero el desempeño

62 46 del GPU se ve afectado por el número de núcleos. Cada núcleo tiene una ALU (arithmetic logic unit) pipe-lined con instrucciones SIMD, y es capaz de realizar operaciones de punto fijo sobre vectores 3D. Las instrucciones pueden ser lógicas, aritméticas o de control[23], en la figura 2.25 se observa la arquitectura del GPU. Figura 2.25: Arquitectura del GPU Theia El GPU permite tener en cada memoria interna de los núcleos, el programa que será ejecutado para la rerización de la imagen. Este programa puede ser modificado para

63 47 obtener nuevos programas de shaders. En la figura 2.3, se observa un diagrama de bloques de la arquitectura del GPU [23]. La figura 2.3 es un ejemplo de 16 núcleos de la arquitectura del GPU Theia. Cada núcleo con que cuente el sistema, al ser indepiente, corre una copia local del código de shader de forma simultanea. Este código está escrito en el propio lenguaje de Theia, donde las entradas se reciben por la T-Memory y la Vertex Memory y coloca sus salidas en uno de los bancos OMen. Como se observa en la figura 2.3 y como se comentaba anteriormente, el GPU cuenta con 4 memorias distintas: T-memory Vertex Memory OMen Shader/Configuration Memory Donde la memoria, llamada T-memory, es una memoria n-way del tipo interleaved. La comunicación e interconexión entre los núcleos y esta memoria se realiza por medio de un crossbar para maximizar las lecturas concurrentes, puesto que los núcleos no pueden realizar escrituras sobre esta memoria. Cada dos núcleos se comparten una memoria caché de textura para acelerar la lectura de las texturas.

64 48 La memoria vertex contiene las primitivas para describir una escena, la interfaz entre los núcleos y esta memoria se realiza por medio del Hub/Switch, donde este le envía todas las primitivas de la actual geometría a todos los núcleos. Por cada núcleo que haya habrá un bloque de memoria OMen, debido a que a cada núcleo se le asigna un único bloque de esta memoria, cada núcleo puede escribir solo a su respectivo bloque de memoria OMen y de este bloque no se pueden realizar lecturas. La Shader/Configuration Memory, contiene el código del Shader a utilizar, y cada núcleo, como se vio anteriormente, corre una copia local en una memoria interna Memoria interleaved Muchos esquemas y sistemas actuales para distintas aplicaciones requieren no solo de computación intensa si no también procesar enormes cantidades de datos que debe ser leída a gran velocidad y de forma consecutiva o concurrente de la memoria para reducir el tiempo de procesamiento[12]. Una buena organización de la memoria mejora la utilización y la eficiencia de procesamiento. La memoria interleave es una forma de acomodar datos de forma no continua, para así incrementar el ancho de banda. Esta arquitectura de memoria provee los altos anchos de bandas requeridos, para procesadores tipo, pipelined, multiprocesadores y procesadores vectoriales como el GPU Theia[12]. En este tipo de configuración la memoria es construida por múltiples bloques que son conectados a los procesadores a través de un IN. Si se considera una memoria

65 49 compuesta por N=2n, bloques de memoria, donde cada módulo contiene w=2b, la capacidad total de la memoria será N*w=n+b, y se necesitaran (n+b) bits para direccionar cada palabra de la organización de la memoria. La memoria interled provee acceso concurrente a más de un módulo. Hay dos formas básicas para distribuir el direccionamiento en los bloques, Low-order y Highorder interleaving. En Low-order el direccionamiento adyacente es esparcido por los N bloques de memoria permitio acceso concurrente (C-access). Donde los lower-order nbits, son utilizados para direccionar el bloque de memoria y los restantes bits (higher-order b-bits), son utilizados para direccionar las palabras en dicho bloque. Para el direccionamiento high-order, el direccionamiento adyacente se realiza en el mismo bloque por lo que el acceso se comporta como un acceso secuencial (S-access), y donde los higherorder b-bits se usa para el direccionamiento del bloque mientras los restantes bits so utilzados para el direccionamiento de las palabras en dicho módulo[12]. Una de las memorias de la arquitectura del GPU Theia, la T-memory para ser más específicos, se encuentra organizada en una forma interleaved, de orden bajo Low-order, permitio accesos concurrentes (C-access) a los distintos núcleos, que desean acceso a los distintos datos adyacentes de forma paralela para realizar la lectura de las distintas texturas que deben aplicar a la imagen.

66 50

67 3. CAPÍTULO 3: Arquitectura de intercomunicación del crossbar en el GPU Theia Para realizar mejoras al sistema del bus de contención hubo que realizar estudios detallados de la arquitectura, y encontrar las vulnerabilidades que afectan dicho sistema. Como se vio anteriormente el sistema de crossbar se encuentra comunicando los núcleos, con la memoria de texturas, llamada T-memory. Esta memoria presenta una serie de ventajas para el GPU, puesto que le permite lecturas concurrentes, al ser una memoria interleaved. Otra ventaja que presenta la memoria al ser solo de lectura, es que no se debe prestar atención a la coherencia de datos, ahorrando grandes cantidades de lógica concerniente a este aspecto. 3.1 Bloques y señales de intercomunicación en el crossbar La arquitectura de intercomunicación, con la T-memory y los núcleos por medio del crossbar, se divide en dos módulos principales, encargados de realizar la interfaz de comunicación, entre estas unidades. Cada núcleo contiene en su interior cuatro bloques principales: EXE, IO, CONTROL y MEM [23] como se observa en la figura 3.1. MEM: Contiene una memoria ROM con código predeterminado, una RAM con código de usuario que puede sobreescribir el ROM, y también contiene registros y memoria mapeada de entrada y salida. 50

68 51 EXE: Unidad de ejecución contiene las unidades de, Fetch, decode, ALU y Write Back. Y contiene un esquema de Pipe-line. IO: Unidad de entrada y salida, implementa bloques de maestro y esclavo con protocolo Wishbone. Control: Control central de la máquina de estado finitos del núcleo. Figura 3.1: Diagrama de Bloques de la arquitectura de cada núcleo

69 Bloque TMemInterface (Module_TMeminterface.v), señales y registros El bloque de especial interés en este caso es el bloque IO, este contiene módulos para las diferentes comunicaciones con las memorias, y dentro de este se encuentra uno de los dos módulos encargado de realizar la interfaz con la T-memory. Este módulo es el TmemInterface, y tiene señales que realizan la intercomunicación, las señales correspondientes que realizan la comunicación se detallan enseguida: Registros y señales de entrada/salida. - Señales de control: Clock, Reset. - ienable: Señal que habilita el núcleo, junto con una dirección cuando desea realizar una lectura. - iaddres: Dirección de memoria solicitado por el núcleo. - odata: Datos correspondientes que se dirigen al núcleo, provenientes de la memoria. - odone: Señal que determina el fin de la operación de lectura a la T-memory. - GNT_I: Señal del árbitro del bloque de memoria que realiza la concesión al núcleo. - DAT_I: Datos provenientes de la memoria que llegan al módulo de interfaz.

70 53 - ADR_O: Dirección de memoria que solicita la interfaz al árbitro del bloque de memoria. - CYC_O: Señal proveniente de la interfaz que realiza la solicitud del bloque de memoria. - ACK_I, WE_O, STB_O: señales reservadas y no utilizadas por el módulo, pertenecen al protocolo WishBone. Registros y señales internos. - wcurrentword: Divide el tamaño de los datos de salida en 3 partes. - wdone: Señal que permite junto con la señal ienable determinar el final de la operación de lectura. - wlatchnow: Registro que determina cual de las 3 partes, de los datos de salida, se está obtenio de la memoria. odata, es una palabra de 96 bits de tamaño, donde se divide en tres partes, odata[95:64], odata[63:32], odata[31:0], que representan la parte x, y, z que conforman el pixel de la imagen Bloque de arbitraje (Module_BusArbitrer.v), señales y registros Por otra parte está el árbitro de cada bloque de memoria de la T-memory, este es el segundo bloque que permite la comunicación, y este realiza una comunicación de forma directa con el bloque de interfaz, TMemInterface de cada núcleo. Al haber una árbitro por

71 54 bloque representa una arquitectura de arbitraje descentralizada. Un diagrama de bloques de esta arquitectura se observa en la figura 3.2. Este bloque regula que varios núcleos realicen solicitudes simultáneas de lectura a un mismo banco de la memoria Tmem y realiza una repartición del recurso, las señales que contiene para realizar la comunicación se presentan enseguida: Registros y señales de entrada/salida. - Señales de control: Clock, Reset. - irequest: Esta señal del entrada determina cuales núcleos se encuentran realizando la solicitud el recurso, el tamaño de los bits es igual a la cantidad de núcleos del sistema. - ogrant: Este registro de salida determina que núcleo tiene la concesión del bus del respectivo bloque de memoria, el tamaño de este registro es igual al tamaño de la cantidad de núcleos en el sistema y solo un bit puede estar activo a la vez. - obusselect: Selecciona la linea del bus que es otorgada al núcleo con la actual concesión. Registros y señales internos. - wcurrentmastermask: Señal, que se modifica cada ciclo de reloj, si el bloque de memoria no ha sido concedido, por medio de un registro de corrimiento para

72 55 repartir el bloque de memoria entre los núcleos, si el bloque es concedido se deshabilita el registro y no se modifica. - wcurrentbusmaster: Señal que permite que un núcleo disponga del recurso hasta que concluya, la lectura, aunque otros dispositivos lo soliciten. Figura 3.2: Diagrama de bloques de la arquitectura descentralizada de arbitraje 3.2 Protocolo de comunicación inicial de los bloques en el crossbar Los bloques que realizan la comunicación tienen su respectivo protocolo para garantizar la comunicación entre el núcleo y el respectivo bloque de memoria solicitado por el núcleo. Este protocolo consiste en los siguientes pasos:

73 56 1. El núcleo realiza una solicitud de dirección mediante la instrucción TMREAD, junto con la dirección de memoria, para obtener el dato de lectura y habilitada mediante la señal ienable, el bloque TMemInterface. 2. Al habilitarse el bloque TMemInterface, este toma la instrucción iaddress de 96 bits con la dirección deseada y mediante un mux se dividen en tres palabras de 32 bits, para leer de los distintos bloques de memoria, los valores de los datos que requiere el núcleo (puesto que los datos también son de 96 bits y se dividen en los campos x, y, z de 32 bits cada uno). 3. El bloque TMemInterface, al ser habilitado por ienable inmediatamente, por medio de la señal CYC_O, realiza una solicitud del bloque correspondiente de la Tmemory y espera a la concesión. Los distintos bloques de la T-memory se distribuyen por medio de iaddress[x, y, z]%m donde M representa la cantidad de módulos de memoria. 4. Luego esta señal CYC_O, llega a la señal irequest del árbitro correspondiente del bloque solicitado. La señal irequest contiene una cantidad de bits igual a la cantidad de núcleos del sistema. Cualquier valor en el registro ireques de 2^[0,1,2...N], representa a que solo 1 núcleo realiza la solicitud, donde el intervalo [0,1,2...N] representa una posición de un núcleo, por ejemplo el valor 2^3, es una solicitud del bloque únicamente por el núcleo 4. Cualquier otro valor diferente a los mencionados anteriormente resulta de solicitudes por dos o más núcleos.

74 57 5. El módulo de arbitraje de cada bloque contiene una máscara, wcurrentmastermask, con un tamaño de palabra igual a irequest, la cual se encarga de repartir el bloque correspondiente de memoria entre todos los núcleos. Esta señal es la salida de un registro de corrimiento, el cual cada ciclo corre a la izquierda el único bit en 1 que contiene la palabra. De esta forma determina en dicho ciclo de reloj a que núcleo le toca el recurso. 6. Luego se realiza una AND lógica bit a bit entre los dos registros, (wcurrentmastermask y irequest), y de esta forma se obtiene la concesión del bus ogrant, esta señal es del mismo tamaño que irequest y cada bit de la palabra de ogrant se conecta con un núcleo donde el bit menos significativo representa el primer núcleo[0] y así con el resto de los núcleos hasta el bit más significativo de la palabra que representa el núcleo[n]. El registro de salida ogrant solo puede contener un 1 lógico entre todos los bits. 7. Los bits de la señal ogrant se dividen entre todos los GNT_I de los bloques TMemInterface, de todos los núcleos. Cuando esta señal GNT_I es activa se otorga el recurso del bloque de memoria al módulo TMeminterface del respectivo núcleo, y guarda los valores de los datos obtenidos de memoria en una de las tres partes del registro odato, mientras se solicitan y obtiene el resto de la palabra, también cuando se habilita GNT_I, se habilita el registro de corrimiento el cual modifica su salida y por e la señal wcurrentword, de esta forma sabe cuál de las tres partes

75 58 de la palabra odato se está obtenio de la memoria y en qué parte de esta palabra va. 8. Mientras un núcleo lee del bloque de memoria se activa la señal wcurrentrequest, deshabilitando los registros de corrimiento para que el núcleo tenga el recurso hasta que concluya la transferencia de los datos con ese respectivo bloque de memoria. 9. El procedimiento anterior se repite 3 veces, para cada uno de los componentes de 32 bits hasta formar una palabara de 96 para el bus interno del núcleo. Durante este periodo la señal de solicitud, CYC_O, permanece en alto hasta que las tres partes en las que se divide la palabra odato, sean obtenidas de los distinto bloques de memoria, esto se da cuando se alcanza el cuarto bit de la palabra wcurrentword[3], que por medio de un flip-flop habilita y mantiene la señal wdone, que realiza una & con ienable, generando un valor en el registro de salida odone que llega al núcleo para informarle que la operación de lectura a la T-memory ha concluido. En la figura 3.3 se observa un diagrama de ondas, protocolo de comunicación utilizado por el sistema de intercomunicación del GPU. El árbitro resuelve varias solicitudes generadas por distintos núcleos a un bloque, en este caso, mediante la memoria ROM del sistema, se hizo que todos los núcleos realizaran peticiones al mismo bloque de memoria. La dirección de la que quieren leer el dato es 0x A, que pertenece al segundo bloque de memoria (10%4=2).

76 59 Al forzar a que todos los núcleos hagan peticiones del mismo bloque de memoria se generan colisiones constantes en el bus. Esto se observa en el diagrama cuando inicialmente todos los núcleos realizan la peticiones, y los 4 bits (del 3-0) de los que se conforma la palabra irequest se encuentran en alto. Luego la máscara del árbitro selecciona los núcleos para otorgarles la concesión del bus, por lo que la máscara en este caso es igual que el registro de concesión ogrant. En el diagrama se aprecia también que la máscara coincide, en este caso, inicialmente con el tercer núcleo (core2, puesto que el rango va de 0 a 3), y un ciclo después de que se da la señal de ogrant esta llega al núcleo correspondiente por medio de la señal CYC_O, obtenio una tercera parte del dato deseado (en este caso como se está forzando a lectura del mismo bloque no se obtiene las 3 partes de las que conforman el dato, solo se obtiene una y se vuelve a leer del mismo bloque de memoria). Luego de concluida la transferencia del dato con el actual núcleo se procede con el siguiente con el que coincida con la máscara, que en el caso de la figura sería el cuarto núcleo puesto que la mascara cada ciclo de reloj mientras no realiza lectura del bloque realiza un desplazamiento a la izquierda sobre el registro de la máscara para darle concesión al siguiente núcleo. Se observa en la figura como el recurso del bloque se reparte entre todos los núcleos y como el registro ogrant se desplaza un bit a la izquierda con cada ciclo de reloj. Se observa como el arbitro inicial con que contaba el sistema resuelve las solicitudes una a una desplazando el bit del registro de la máscara.

77 60 Otra señal que se encuentra en el diagrama es obusselect, que se encarga de darle la conexión de la línea correspondiente en el crossbar, al núcleo al que se le dio la concesión de esta línea. Esta señal es una codificación binaria de la máscara puesto como se observa el valor 4 de ogrant se representa como el segundo bit en alto de esta palabra, como es es segundo bit el valor de obusselect es 2. Figura3.3: Diagrama de ondas con el protocolo del sistema, arbitraje resolvio colisiones forzadas En la figura 3.3, presentada anteriormente, se muestra un caso ficticio puesto que se estaban forzando colisiones para observar el comportamiento del árbitro del sistema y como este solucionaba las colisiones. En la figura 3.4 se observa un comportamiento más natural del sistema realizando sus respectivas solicitudes al sistema sin forzar colisiones. Se pueden

78 61 observar varios aspectos del comportamiento en el sistema de interconexión, el primer aspecto es como la solicitud del núcleo permanece en alto mientras se otorgan tres distintas concesiones para tres distintas direcciones de 32 bits para completar el dato de 96 bits. Otro aspecto interesante que se aprecia en la figura 3.4 es que la señal wcurrentmastermask (marcada en azul) realiza una & lógica con irequest y obtiene ogrant para el núcleo1 (Core1), el cual un ciclo de reloj después (marcado con los cursores) de coincidir la máscara con el irequest se otorga el recurso. Se apreciar como la señal GNT_I del núcleo1 da un pulso para la obtención de la segunda parte del dato que le corresponde, y el CYC_O permanece en alto hasta cuando realiza el tercer pulso de GNT_I que es cuando cae la señal CYC_O, y se obtiene la tercera parte del dato que le corresponde. Unos ciclos antes cuando se realiza el irequest, se observa que la máscara no coincide con el irequest, puesto que la solicitud está en el segundo bit y esta tiene que desplazar el bit desda la 3 poición (8 valor lógico) hasta que coincida con el irequest que es cuando este otorga el recurso. Inicialmente 3 núcleos del sistema(core1, core2, core3) realizan una solicitud al mismo bloque de memoria, con la señal CYC_O. Se observa en la señal irequest como se dan las solicitudes simultaneas a este bloque, también se aprecia como la máscara selecciona primero el núcleo1, y le otorga el recurso, mientras los otros núcleos esperan a que sea su turno. Se puede apreciar el retraso en los núcleos para la obtención del bloque de memoria.

79 62 Figura 3.4: Diagrama de ondas de protocolo de comunicación en operación normal entre los núcleos y los bloques de memoria

80 4. CAPÍTULO 4: Deficiencias y Mejoras en el Crossbar Es importante destacar que para mantener la modularidad del sistema, no se agregaron ni se quitaron señales ni registros externos del los módulos Module_BusArbitrer.v y Module_TMeminterface.v, por lo que únicamente se agregaron módulos internos y se realizaron bloques nuevos dentro de los módulos que mediante la lógica correspondiente convergían finalmente en las misma señales de entrada y salida utilizadas por estos módulos. 4.1 Medición del rimiento del crossbar Para tener una noción de cuanto se mejoró la contención de bus tipo crossbar en el sistema con las nuevas implementaciones, fue necesario tener una métrica del comportamiento inicial del sistema. Para esto se realizó una simulación del sistema inicial con la cantidad de núcleos y bloques de memoria con los que se podía contar en el sistema, por lo que se realizaron simulaciones del sistema para NxM de 2x2, 4x4, 8x8 y 16x16. Para la obtención de la métrica se diseñó un módulo, que se puede observar en el diagrama de bloques en la figura 4.1, denominado Module_BusArbiterCheker.v. Este módulo se encuentra dentro del testbench del RTL sensible a la señal irequest de cada bloque de memoria. Cuando esta señal cambia su valor, este cambio es detectado por el módulo que escribe un valor correspondiente a este evento de cambio. Si el valor de irequest era diferente de cero, el módulo escribe un carácter 1 en un archivo de texto específico de ese 63

81 64 bloque de memoria indicando que no había colisiones por la obtención de ese bloque de memoria. En caso de darse una colisión, un carácter 0 es escrito en el archivo. Para detectar si hubo una colisión o no, se verifica el el valor de irequest. Este valor es igual a 2^[n], donde n puede tomar cualquier valor natural incluyo al cero. De ser se supone que no hay ninguna colisión y se escribe un 1. Cualquier otro valor, esto se observa mejor en la tabla 4.1 que se construyó para un irequest de 4 bits. Figura 4.1: Diagrama de bloques con el módulo que realiza la métrica del sistema Tabla 4.1: Tabla de para la determinación de colisiones en crossbar Valor en el archivo.txt irequest X X 1 X X X X

82 65 Luego los datos eran recolectados por un programa en C++, para calcular la cantidad de colisiones, concesiones y solicitudes realizadas a cada bloque de memoria. Estas mediciones se realizaron bajo la aproximación de Streker's (indepencia de solicitudes), puesto que no se hace diferencia si el valor irequest cambia por un valor que realizó una solicitud anteriormente y no fue concedido el recurso. Los datos obtenidos en dicha simulación se resumen en la tabla 4.2, donde la probabilidad de aceptación se obtuvo como la razón entre las solicitudes concedidas sin causar colisiones, entre el total de solicitudes realizadas. Para el caso de la tabla 4.2 se calculó la probabilidad de aceptación para todo el sistema. En el Apéndice 1 se presenta la probabilidad de aceptación de cada bloque de memoria para los distintos sistemas NxM simulados, y el gráfico correspondiente de la tabla 4.2 se muestra en la figura 4.2. Tabla 4.2: Porcentaje de aceptación por cantidad de núcleos en el crossbar Se puede observar como la probabilidad de aceptación del sistema decrece cuando aumenta la cantidad de núcleos en el sistema, esto era de esperarse como se observó teóricamente al graficar la ecuación de L.N. Bhuyan et al [3].

83 66 Porecentaje de aceptación vs. Sistema NxN 100 Porcentaje Log2N Figura 4.2: Probabilidad de aceptación vs. Cantidad de núcleos para el sistema inicial 4.2 Aumento en la cantidad de bloques de memoria La primera mejora se logró alcanzar basándonos en las ecuaciones y , estudiadas anteriormente y observando sus parámetros. Se muestran respectivamente de nuevo las ecuaciones. PA= BW p N BW =M 1 1 P N M La ecuación es la ecuación utilizada para la probabilidad de aceptación, la cual se usa para determinar la probabilidad de que un núcleo realice una petición a un recurso y este sea concedido. Esta probabilidad de aceptación se determina a partir del ancho de banda. La segunda ecuación ( ) es utilizada para calcular el ancho de banda

84 67 posible en una topología tipo crossbar. Para la ecuación , los parámetro que conforman la conforman son: M cantidad de bloques de memoria, N cantidad de núcleos del sistema y p se define como la probabilidad de un núcleo de realizar una petición a un recurso en del sistema. Se observa que uno de los parámetros de es la cantidad de bloques de memoria en el sistema, donde L.N. Bhuyan ét al.[3], definió como P/M la probabilidad de que un núcleo solicite un bloque de memoria en particular, luego (1-P/M)N es la probabilidad de que ninguno de los N procesadores realice una petición a un bloque en particular. Al restarle 1, (1-(1-P/M)N ), se obtiene la probabilidad de que al menos un núcleo esté realizando una petición a ese bloque y finalmente multiplicando por la cantidad de bloques de memoria M, se obtiene el número esperado de peticiones por ciclo en el sistema. Estudiando la ecuación se observó que si se aumentaba la cantidad de bloques en el sistema se aumentaría el ancho de banda en el crossbar, y la probabilidad de aceptación aumentaría, mejorando el desempeño deseado de todo el sistema. La mejora se obtuvo mediante un scritp escrito por el profesor Diego Valverde, el cual permite modificar la cantidad de núcleos y de módulos de memoria variando así el tamaño del sistema. Como la mayoría de módulos se realizaron mediante directiva de verilog llamada generate, al variar este script el valor respectivo en el archivo de definiciones, se varia a su vez la cantidad de veces que se debe generar un bloque cambiando el tamaño del sistema. Realizando pruebas experimentales, los datos arrojados por la simulaciones se presentan en la tabla 4.3 y su gráfico en la figura 4.3.

85 68 Tabla 4.3: Porcentaje de aceptación para los núcleos con distintos Bloques de memoria Cuando se realizó el análisis de los datos anteriores, se obtuvieron resultados inesperados, se esperaba obtener un mayor porcentaje en la probabilidad de aceptación en las concesiones y se obtuvieron mejoras de apenas un 2%, en forma general, con excepción en los casos de un sistema de 8 núcleos en donde de el sistema mas bien bajó su probabilidad de aceptación en un -2,03%, o en el sistema para 2 núcleos donde se presenta un aumentó inicial de 7,48%, y luego de este aumento siguió incrementado poco menos del 2%. En la figura 4.3 se observa el comportamiento con una baja piente para los distintos casos, excepto para el caso inicial del sistema con 2 núcleos que presenta una mayor piente debido al aumento del 7,48%.

86 69 Porcentaje Porecentaje de aceptación vs. Cantidad de Bloques de memoria Núcleos 4 Núcleos 8 Núcleos 16 Núcleos Log2N Figura 4.3: Porcentaje de aceptación para varios núcleos con distintos bloques de memoria 4.3 Deficiencia del árbitro inicial en la concesión del recurso a los núcleos La razón del porqué no se obtuvo un mejoramiento significativo en la probabilidad de aceptación al aumentar los bloques de memoria se debe al árbitro del sistema. El tiempo que a este le tomaba en otorgar la concesión al núcleo, como fue mencionado en el desarrollo teórico según Hsin-Chou Chi et al [10], debe poseer poca latencia. Un árbitro con un tiempo de respuesta muy alto puede volver deficiente el sistema generando colisiones y disminuyo el ancho de banda, como se observó en el capítulo anterior.

87 70 La máscara del árbitro inicial tenía un comportamiento similar a el de un token ring, donde durante cada ciclo de reloj se rotaba a la izquierda el bit en el registro wcurrentmastermask, y cada vez que coincide este bit con un 1 en el irequest, se le otorgaba el recurso al núcleo correspondiente a dicha solicitud. El problema de este algoritmo es que si un núcleo realizaba la solicitud del recurso y justo en ese ciclo de reloj la máscara, wcurrentmastermask, el 1 se encontraba una posición a la izquierda (peor caso), el núcleo debía esperar una cantidad de ciclos de reloj igual a la cantidad de núcleos que tenga el sistema., Por ejemplo, si este era el único núcleo realizando la solicitud, y si el sistema es 2xM, entonces debía esperar al segundo ciclo del reloj. Si el sistema es de 4xM debía esperar al cuarto ciclo de reloj de la misma forma para 8xM y 16xM si en el bloque se encontraba más de un núcleo realizando la solicitud, el núcleo debía esperar que los que se encontraban más cerca del token completasen sus transacciones primero hasta que el token llegase al respectivo núcleo. Al tener que esperar más tiempo por el recurso, se generaban mayores colisiones puesto que mientras un núcleo esperaba la concesión, otro que ya había concluido en la obtención de un dato en otro bloque de memoria podía realizar una solicitud en el bloque de este primer núcleo generando una colisión. Si este segundo núcleo se encontraba más cerca del token de la máscara podía adelantar al bloque que realizó primero la solicitud tenio que esperar mayores tiempos por la concesión. Esto se comprueba en la tabla 4.3 y la figura 4.3 vistas anteriormente. Se observa como al crecer el número de núcleos disminuye la probabilidad de aceptación debido a que al aumentar las

88 71 esperas por el recurso se generan mayores colisiones y aumentan la cantidad de solicitudes en el sistema. En la figura 4.4 se observa un diagrama de ondas con el peor caso. Figura 4.4: Diagrama de ondas peor caso caso en la concesión del recurso Se observa como el núcleo3 (Core3), realiza la solicitud en el ciclo marcado por el cursor A, justo cuando realiza esta solicitud, la máscara resaltada en azul, el token se encuentra en el valor 1. Al ser el núcleo 3 el que realizó la solicitud, el valor de la máscara debe ser 8 para otorgarle el recurso. Esto se observa en el registro irequest dos espacios arriba de la máscara resaltada en azul. Se puede apreciar como el núcleo debe esperar cuatro ciclos de reloj mientras la máscara va desplazando el bit, para que esta coincida con la solicitud y un ciclo de reloj después se realiza la concesión al núcleo Concesión inmediata a una única solicitud

89 72 La segunda mejora que se realizó en el sistema del crossbar, consistió en realizar una concesión sin tener que esperar al token ring en el módulo del árbitro si un solo núcleo realiza una solicitud al bloque de memoria. Como pudimos observar en la figura 4.4, si un núcleo realiza la solicitud aunque este sea el único realizando la petición, este debe esperar a que la máscara coincida con la solicitud en irequest para otorgar el recurso., Esto genera colisiones, como se demostró anteriormente. Si un solo núcleo realiza una solicitud no es necesario realizar un arbitraje, solo dicho núcleo realiza la solicitud y no es necesario esperar a que el token le llegue para obtener la concesión del bus. Basados en este principio, se realizó un módulo capás de identificar si la palabra irequest contiene solo un bit en 1., Con esta mejora se identifica que solo se está realizando una concesión, un ciclo de reloj después, se codifica la posición del bit el cuál está realizando la solicitud y se da una señal de que se está realizando una única solicitud, por lo que la máscara cambia a un valor igual que el irequest., Un ciclo de reloj después, el núcleo obtiene la concesión. De esta manera, el tiempo de espera por un recurso si solo un núcleo realiza la solicitud se reduce de N-1 ciclos de reloj, en el peor de los casos, a 2 ciclos de reloj. Por otra parte si el bloque de memoria obtiene más de una sola solicitud en determinado momento, el árbitro se comporta de la misma forma como se ha visto en los casos anteriores.,esto ocurre cuando hay dos solicitudes y el token ring se encuentra en el otro extremo por lo que tomaría N-2 ciclos de reloj la obtención del recurso. Se puede observar en la figura 4.5 el diagrama de ondas con el comportamiento del árbitro con la mejora de concesión inmediata a una única solicitud.

90 73 Al realizar este módulo se introdujeron nuevas señales, registros y módulos que se presentan enseguida. wsinglerequest: Esta señal se pone en alto cuando se realiza solo una solicitud al bloque de memoria. wsinglemask: Esta es la máscara cuando wsinglerequest se encuentra en alto y tiene el mismo valor de irequest. wsystemmask: Esta es la señal que realiza una AND lógica bit a bit con irequest en el árbitro en lugar de la anterior wcurrentmask, y su valor puede ser el de wsinglemask, o wcurrentmask depio de si wsinglerequest se encuentra en alto o no. wsinglebusmaster: Este es la codificación de la posición del bit en irequest. wsystembusmaster: Este puede tener dos valores wsinglebusmaster o wcurrentbusmaster depio si wsinglerequest se encuentra en alto o no, y es la señal que le da la concesión del bus al respectivo núcleo. Módulo Compare_Request: este módulo secuencial se encarga de tomar la palabra irequest, y de comprar si se realiza una solicitud, ponio en alto wsinglerequest y codificando el bit que está realizando la solicitud, para dar el valor de wsinglebusmaster.

91 74 Figura 4.5: Diagrama de ondas para una concesión inmediata a una única solicitud En la figura 4.5 se observa el comportamiento anteriormente detallado de la mejora. Las señales que se presentan en este caso corresponden a un solo bloque de memoria. Como se aprecia en la parte superior de la figura, la señal irequest en el cursor A del núcleo 2 realiza una solicitud que corresponde a un valor igual a 4 en binario. Esta es una solicitud única. ne el algoritmo anterior, dicha señal hubiera tenido que esperar 3 ciclos de reloj más para que el token de la máscara coincidiera con el valor de irequest como se aprecia en la figura 4.5., Un ciclo después, luego de que se da la solicitud de lectura, en el cursor B, el árbitro del sistema levanta la señal de wsinglerequest y wsystemmask pasando de tener el valor del token a tener el valor del irequest. Esto activa la señal ogrant al núcleo correspondiente y una ciclo después en el cursor C, la señal GNT_I del

92 75 núcleo se levanta para obterner finalmente el dato deseado. En el cursor D se observa como llega una solicitud de varios núcleos. Cuando esto sucede, como se aprecia en el cursor E, la señal wsinglerequest cae, dándole paso al token para que realice el arbitraje. En el cursor F se observa como hay múltiples señales realizando la solicitudes al bloque. Un ciclo de reloj más tarde, la señal wsinglerequest que estaba en alto cae, y es el token el que nuevamente realiza el arbitraje. En la figura 4.6 se observa el comportamiento del sistema con la mejora de concesión inmediata a una única solicitud. Porcentaje Porecentaje de aceptación vs. Sistema NxN Mejora de única solicitud Sistema sin mejora Log2N Figura 4.6: Sistema con mejora de concesión inmediata a una única solicitud y sistema inicial sin mejora Se observa como el sistema 2x2 se comporta de la misma forma sin la mejora. Esto era de esperarse puesto que el tiempo que le toma a la máscara del sistema repartir el recurso entre todos los núcleos, es el mismo que le toma al sistema en detectar una única

93 76 solicitud. Se puede apreciar un aumento significativo en el porcentaje de aceptación para los sistemas de mayor tamaño., Para el sistema 4x4, 8x8 y 16x16, el porcentaje de mejora es de 7,43%, 19,72% y 31,56% respectivamente. Como se puede observar en la tabla 4.4, al cercer el sistema aumenta el porcentaje de mejora, debido a que la máscara en el sistema sin mejora tomaba mucho más tiempo en otorgar la concesión que cuando el tamaño del sistema aumenta, debido a que el token tenía que rotar entre más núcleos. Tabla 4.4: Porcentajes de aceptación del sistema, inicial, con única solicitud y diferencia en el porcentaje. 4.6 Mejora de aumento de bloques y única solicitud juntas Luego de aplicar la mejora de aumento de bloques y la mejora de única solicitud al bloque, se decidió juntarlas esperando tener un aumento aún mayor en el porcentaje de aceptación en el sistema. Al aplicar dicha mejora se observan los resultados en la figura 4.7.

94 77 Porcentaje Porecentaje de aceptación vs. Cantidad de Bloques de memoria Núcleos 4 Núcleos 8 Núcleos 16 Núcleos Log2N Figura 4.7: Probabilidad de aceptación con mejoras en el sistema de única solicitud y aumento de bloques. En la tabla 4.5 se encuentran los valores obtenidos utilizando ambas mejoras en el sistema. La principal mejora que se observa es la que se logró con una única solicitud al bloque. Cuando se agregó además la mejora de aumento de bloques, la mejora porcentual es de menor valor que el porcentaje obtenio con la mejora de única solicitud., El mayor porcentaje obtenido realizando aumento de bloques, como se observa en la tabla 4.6, es un aumento de 7,48% que se obtuvo al pasar de un sistema de 2x2 a uno de 2x4., En los sistemas de 2xM la mejora de única solicitud no tiene efecto., Al aumentar el sistema de 8x8 a 16x16, se aprecia una mejora de 5.19%, la cual es relativamente pequeña en comparación con el aumento obtenido por la mejora de única solicitud.. Por otro lado, al aumentar el sistema de 4x4 a 4x8, se aprecia una mayor mejora porcentual en comparación con la mejora de única solicitud con un aumento porcentual del 4,26%, que

95 78 equivale a un 3,17% por debajo del 7,43% de la mejora obtenida por una única solicitud de bloque. Tabla 4.5: Valores de los porcentajes de aceptación con mejor de aumento de bloques y de única solicitud Tabla 4.6: Porcentaje de mejora que se obtiene en con el aumento de bloques única solicitud 4.7 Mejora con prioridad lógica La última mejora se realizó basada en una versión del árbitro realizado por E.S. Shin et ál, analizado en la sección Este árbitro consiste en varios módulos de prioridad lógica. Cada módulo de de prioridad es habilitado por un registro de desplazamiento, el cuál tiene un tamaño de palabra igual a al cantidad de núcleos que haya en el sistema.,por esta razón la cantidad de módulos de prioridad lógica es igual a la cantidad de núcleos. Cada módulo de prioridad cuenta con una cantidad de entradas y

96 79 salidas igual a la cantidad de núcleos. Cada entrada del módulo de prioridad es un bit de irequest, con la particularidad de que para cada módulo de prioridad, el mismo bit de irequest contiene una posición diferente., De de esta manera se asegura que en cada ciclo de reloj, la prioridad de los núcleos cambia, garantizando justicia (fairness) en el repartimiento de los recursos., Esto se consigue fracias a un token que habilita los distintos módulos de prioridad con posición distinta en cada una de las solicitudes. Un diagrama esquemático es presentado en la sección En la figura 2.15 la tabla de verdad del módulo de prioridad que se presentó en la tabla 2.2 se presentan de nuevo: Figura 4.8: Circuito lógico básico del bus arbitration (BA) con el cual se implementa el switch arbitration (SA)

97 80 Tabla 4.7: Tabla de verdad de los bloques de prioridad del circuito lógico de BA La diferencia de este circuito con respecto al de E.S. Shin et ál, radica en que estos módulos de prioridad se implementaron con tamaño variable. Esto ajustar los módulos de prioridad a la cantidad de núcleos en el sistema. No se implementó una configuración en árbol como la propuesto por E.S. Shin et ál. Las señales, registros y módulos implementados en el árbitro con dicha mejora se resumen en seguida: Priority_In: Señales de entrada al módulo de prioridad. Priority_Output: Señales de salidad del módulo de prioridad. Or_In: Entradas al módulo que realiza una o lógica para generar el ogrant. wcurrentmastermask: Palabra con solo 1 bit en alto que se desplaza cada ciclo de reloj a la izquierda, para activar los distintos módulos de prioridad. Or_output: Salidad de cada compuerta OR para obtener el ogrant correspondiente. wcurrentbusmaster: señal que le otorga al obusselect el valor del núcleo que tiene derecho al recurso. wcurrentrequest: Señal que se coloca en alto cuando se está realizando una transaccion con el bloque de memoria.

98 81 Módulo Priority_Logic: Es el módulo de prioridad encargado de darle prioridad a las señales de irequest, mediante lógica combinatoria. OR_Module: Módulo utilizado para realizar la operación OR de una señal. Se utiliza un módulo para hacer uso de generate y variar la cantidad de entrada y numero de estos Compare_Request: Para este caso el módulo Compare_Request sostine la petición del núcleo, ponio en alto la señal wcurrentrequest y codificando la señal de Or_output para generar la señal wcurrentbusmaster. Un diagrama de ondas para ilustrar el funcionamiento del sistema se presenta enseguida. Figura 4.9: Diagrama de ondas del sistema empleando la mejora con los módulos de prioridad

99 82 Se puede observar que cada módulo es habilitado cuando la señal wcurrentmastermask lo selecciona. También se puede apreciar que cada bit de la palabra se encuentra desplazado una posición a la izquierda para cada módulo. Esto debido a que cada uno de estos se alambra de forma distinta para obtener distintas prioridades para cada módulo. Como cada módulo es seleccionado con la máscara del sistema, se garantiza una justa repartición. Podemos apreciar también que el sistema no tiene que esperar durante grandes cantidades de ciclos para dar una concesión del bloque al respectivo núcleo.se puede observar que dos ciclos antes del cursor A, el núcleo 1 realiza una solicitud., Sin embargo durante ese ciclo de reloj está sio atida la solicitud del núcleo 2. Cuando esta última finaliza dos ciclos después, se otorga el bloque de memoria al sistema. En conclusión., el sistema demora 2 ciclos de reloj en otorgar la concesión a un núcleo. A continuación se presentan en la tabla 4.8 y en la figura 4.10, los datos obtenidos del sistema a partir de las probabilidades de aceptación. Tabla 4.8: Probabilidades de aceptación de las mejoras de módulo de prioridad y única solicitud

100 83 Porecentaje de aceptación vs. Cantidad de núcleos Porcentaje 70 Mejora Módulo de prioridad Mejora de única solicitud Sistema sin mejora Log2N Figura 4.10: Sistema con mejora de módulo de prioridad, sistema única solicitud y sistema inicial sin mejora Se puede apreciar de la gráfica que el sistema no presenta una mejora significativa en comparación con la mejora de única solicitud en cuanto a la probabilidad de aceptación. En la tabla 4.9 y en la figura 4.11 se presentan los valores obtenidos luego de realizar la mejora y aumentar la cantidad de bloques de memoria del sistema. Tabla 4.9: Probabilidades de aceptación de las mejoras de módulo de prioridad junto con aumento de los bloques de memoria

101 84 Porecentaje de aceptación vs. Cantidad de Bloques de memoria Porcentaje 90 2 Núcleos 4 Núcleos 8 Núcleos 16 Núcleos Log2N Figura 4.11: Sistema con mejora de módulo de prioridad y aumentando los bloques del sistema Se observa que el sistema tampoco tuvo una mejora relativamente grande en comparación con la mejora inicial realizada por la única solicitud.tampoco se observa una mejora significativa al comparar con el sistema inicial sin mejora., Sin embargo, el sistema con módulo de prioridad obtiene porcentajes de mejora un tanto mayores que el sistema de única solicitud cuando se le agregan más bloques de memoria como se observa en la tabla Tabla 4.10: Porcentaje de mejora que se obtiene en con el aumento de bloques y modulo de prioridad