AER-RT: Interfaz de Red con Topología en Anillo para SNN ...

TESIS DE MÁSTER:

AER-RT: Interfaz de Red con Topología en Anillopara SNN Multi-FPGA

Estudios: Máster en Ingeniería Electrónica

Autor: Taho Dorta Pérez

Supervisor: Jordi Madrenas

Fecha: Julio 2013

INTERFAZ DE RED AER-RT ii

Índice general

1. Introducción 1

1.1. Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. De�niciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1. SNN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2. AER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3. Ubichip . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.4. SNAVA . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Objetivos y requisitos . . . . . . . . . . . . . . . . . . . . . . 51.4. Material de trabajo . . . . . . . . . . . . . . . . . . . . . . . . 61.5. Realización del proyecto . . . . . . . . . . . . . . . . . . . . . 6

2. Diseño 7

2.1. Estudio de la topología . . . . . . . . . . . . . . . . . . . . . . 72.1.1. Topología en Anillo . . . . . . . . . . . . . . . . . . . . 72.1.2. Topología en Estrella . . . . . . . . . . . . . . . . . . 92.1.3. Topología Punto a Punto . . . . . . . . . . . . . . . . 10

2.2. Estudio red jerárquica . . . . . . . . . . . . . . . . . . . . . . 112.3. Conclusión estudio arquitectura de red . . . . . . . . . . . . . 132.4. Elección de bus serie frente a paralelo . . . . . . . . . . . . . 132.5. Elección Aurora 8B/10B como protocolo serie de alta velocidad 14

3. Protocolo AER-RT 17

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2. Problemática de diseño . . . . . . . . . . . . . . . . . . . . . . 183.3. Sincronización entre los nodos del anillo . . . . . . . . . . . . 19

3.3.1. Sincronización de nodos mediante líneas punto a punto 193.3.2. Sincronización de nodos mediante línea adicional de

ready en pipeline . . . . . . . . . . . . . . . . . . . . . 193.3.3. Sincronización de nodos mediante paquetes de control 20

3.4. Protocolo AER-RT . . . . . . . . . . . . . . . . . . . . . . . . 213.4.1. Tipos de paquetes . . . . . . . . . . . . . . . . . . . . 223.4.2. Estructura de los paquetes . . . . . . . . . . . . . . . 233.4.3. Campos de los paquetes . . . . . . . . . . . . . . . . . 24

iii

INTERFAZ DE RED AER-RT iv

3.4.4. Detección de errores . . . . . . . . . . . . . . . . . . . 243.5. Interfaz entre AER-RT y sistema multiprocesador . . . . . . 25

3.5.1. Interfaz de datos . . . . . . . . . . . . . . . . . . . . . 253.5.2. Handshaking (o señales �eo_exec� y �eo_distrib�) . . . 273.5.3. Señal de Error . . . . . . . . . . . . . . . . . . . . . . 27

4. Arquitectura AER-RT 29

4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.1. Diferentes versiones . . . . . . . . . . . . . . . . . . . . 334.1.2. Metodología . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. Interfaz con sistema Multiprocesador . . . . . . . . . . . . . . 354.2.1. Problema adicional: 2 dominios de reloj . . . . . . . . 354.2.2. Input FIFO. Sincronización de datos de entrada . . . . 364.2.3. AER_2_SNAVA. Sincronización datos de salida . . . 37

4.3. Aurora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . 394.3.2. Generar Core . . . . . . . . . . . . . . . . . . . . . . . 404.3.3. Con�guración utilizada . . . . . . . . . . . . . . . . . . 414.3.4. Sistema de compensación de clock . . . . . . . . . . . 41

4.4. AER Tx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.1. Conexión con otros bloques . . . . . . . . . . . . . . . 424.4.2. Diagrama de bloques . . . . . . . . . . . . . . . . . . . 424.4.3. Tx Controller . . . . . . . . . . . . . . . . . . . . . . . 454.4.4. Tx Sync . . . . . . . . . . . . . . . . . . . . . . . . . . 474.4.5. Tx Bypass . . . . . . . . . . . . . . . . . . . . . . . . . 484.4.6. Tx Start . . . . . . . . . . . . . . . . . . . . . . . . . . 494.4.7. Tx Data . . . . . . . . . . . . . . . . . . . . . . . . . . 494.4.8. Tx Finish . . . . . . . . . . . . . . . . . . . . . . . . . 504.4.9. Tx Idle . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4.10. Modo �Debug� . . . . . . . . . . . . . . . . . . . . . . 50

4.5. AER Rx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.5.1. Conexión con otros bloques . . . . . . . . . . . . . . . 524.5.2. Diagrama de bloques . . . . . . . . . . . . . . . . . . . 534.5.3. Detector de paquetes . . . . . . . . . . . . . . . . . . . 564.5.4. Contadores de paquetes . . . . . . . . . . . . . . . . . 574.5.5. Generación AER ON . . . . . . . . . . . . . . . . . . . 574.5.6. Generación AER Done . . . . . . . . . . . . . . . . . . 584.5.7. Filtro Bypass (o escritura en FIFO de todos los paque-

tes a retransmitir) . . . . . . . . . . . . . . . . . . . . 584.5.8. Interfaz de salida AER_RX (o desencapsulación de los

paquetes de datos) . . . . . . . . . . . . . . . . . . . . 594.6. Bypass FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.7. AER Con�g . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.8. AER Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

INTERFAZ DE RED AER-RT v

5. Resultados 63

5.1. Simulación con retardos (o Timing Simulation) . . . . . . . . 635.2. Medidas de latencia para diferente número de nodos y dife-

rente número de spikes . . . . . . . . . . . . . . . . . . . . . . 635.2.1. Medidas anillo un nodo . . . . . . . . . . . . . . . . . 635.2.2. Medidas anillo dos nodos . . . . . . . . . . . . . . . . 655.2.3. Medidas anillo 3 nodos . . . . . . . . . . . . . . . . . . 67

5.3. Latencia del sistema AER-RT . . . . . . . . . . . . . . . . . . 675.4. Área utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.5. Máxima frecuencia . . . . . . . . . . . . . . . . . . . . . . . . 695.6. Consumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6. Sistema completo AER-RT + emulador de SNAVA 71

7. Conclusiones 77

INTERFAZ DE RED AER-RT vi

Índice de �guras

1.1. Esquema sistema Ubichip[4] . . . . . . . . . . . . . . . . . . . 31.2. Interfaz de red AER previo de bus compartido[3] . . . . . . . 4

2.1. Ring Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. Latencia de la red en función del número de nodos (o chips) . 92.3. Star Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4. Red en malla . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5. Distribución de probabilidad de localidad en redes SNN[2] . . 112.6. Red jerárquica híbrida . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Anillo AER-RT con 2 nodos . . . . . . . . . . . . . . . . . . . 173.2. Anillo AER-RT con 3 nodos . . . . . . . . . . . . . . . . . . . 183.3. Sincronismo línea externa punto a punto . . . . . . . . . . . . 203.4. Sincronismo entre chips mediante línea de control en pipeline 203.5. Arquitectura pipeline en anillo . . . . . . . . . . . . . . . . . 223.6. Esquema de la unión entre sistema MP y AER-RT en red con

3 nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7. Cronograma �Handshaking� entre AER-RT y sistema MP . . 27

4.1. Esquema AER-RT simpli�cado . . . . . . . . . . . . . . . . . 304.2. Versión de�nitiva Diagrama de bloques AER-RT . . . . . . . 314.3. Primera versión diagrama de bloques (Diciembre 2012) . . . . 344.4. Primer paso en el diseño incremental . . . . . . . . . . . . . . 354.5. Input FIFO Xilinx IP Core . . . . . . . . . . . . . . . . . . . 374.6. Diagrama de bloques AER_2_SNAVA . . . . . . . . . . . . . 384.7. Output FIFO Xilinx IP Core . . . . . . . . . . . . . . . . . . 384.8. Diagrama de estados máquina de estados de AER_2_SNAVA 394.9. Puertos AER_TX . . . . . . . . . . . . . . . . . . . . . . . . 434.10. Diagrama de bloque AER TX . . . . . . . . . . . . . . . . . . 444.11. Cronograma AER TX . . . . . . . . . . . . . . . . . . . . . . 454.12. Diagrama de estados Tx Controller . . . . . . . . . . . . . . . 464.13. Primera versión Maquina de estados de Tx Controller (total-

mente descartada) . . . . . . . . . . . . . . . . . . . . . . . . 474.14. Diagrama de estados Tx Sync . . . . . . . . . . . . . . . . . . 48

vii

INTERFAZ DE RED AER-RT viii

4.15. Diagrama de estados Tx Bypass . . . . . . . . . . . . . . . . . 494.16. Diagrama de estados Tx Start . . . . . . . . . . . . . . . . . . 504.17. Diagrama de estados Tx Data . . . . . . . . . . . . . . . . . . 514.18. Diagrama de estados Tx Finish . . . . . . . . . . . . . . . . . 514.19. Puertos AER_RX . . . . . . . . . . . . . . . . . . . . . . . . 534.20. Diagrama de bloque AER RX . . . . . . . . . . . . . . . . . . 544.21. Cronograma AER RX . . . . . . . . . . . . . . . . . . . . . . 564.22. Diagrama de estados detector de paquetes de datos propios . 574.23. Diagrama de estados generación de AER ON . . . . . . . . . 584.24. Bypass FIFO Xilinx IP Core . . . . . . . . . . . . . . . . . . . 60

5.1. Latencia en anillo de un nodo transmitiendo un único spike . 645.2. Latencia en anillo de un nodo transmitiendo 10 spikes . . . . 655.3. Latencia en anillo con dos nodos y transmitiendo un único spike 665.4. Latencia en anillo con dos nodos y transmitiendo 10 spikes . . 665.5. Latencia en anillo de tres nodos y transmitiendo 1 spike . . . 675.6. Latencia en anillo con tres nodos y transmitiendo 10 spikes . 685.7. Estimación de consumo AER-RT . . . . . . . . . . . . . . . . 70

6.1. Sistema AER-RT + emulador de SNAVA implementado entres Kintex-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2. Detalle conexiones en sistema AER-RT + emulador de SNA-VA implementado en tres Kintex-7 . . . . . . . . . . . . . . . 73

6.3. Detalle de señales en el chip 0 tomadas con el analizador lógicovirtual de Xilinx . . . . . . . . . . . . . . . . . . . . . . . . . 75

Índice de cuadros

2.1. Tabla comparativa con los ejemplos numéricos vistos en cadatopología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Tipos de paquetes AER-RT . . . . . . . . . . . . . . . . . . . 233.2. Paquete de Control AER-RT . . . . . . . . . . . . . . . . . . 243.3. Paquete de datos AER-RT . . . . . . . . . . . . . . . . . . . . 243.4. Cabecera AER-RT . . . . . . . . . . . . . . . . . . . . . . . . 253.5. Cabecera de control . . . . . . . . . . . . . . . . . . . . . . . 25

4.1. Equivalencia entre frecuencia de transmisión (serie) y frecuen-cia de trabajo (paralelo) . . . . . . . . . . . . . . . . . . . . . 41

4.2. Diferentes códigos para el modo Debug . . . . . . . . . . . . . 52

5.1. Medidas anillo con un nodo . . . . . . . . . . . . . . . . . . . 645.2. Medidas anillo con dos nodos . . . . . . . . . . . . . . . . . . 655.3. Medidas anillo con dos nodos . . . . . . . . . . . . . . . . . . 67

ix

INTERFAZ DE RED AER-RT x

Palabras clave

AER, chip-to-chip network architecture, ring topology, Aurora 8b/10b,SNN, SNAVA

xi

INTERFAZ DE RED AER-RT xii

Resum

En aquesta tesi de màster es presenta la interfície de xarxa AER-RT,una interfície de xarxa dissenyada per treballar conjuntament amb un siste-ma multiprocessador (MP) i crear així una xarxa SNN multi-xip e�cient iescalable.

La creació de la interfície de xarxa AER-RT sorgeix amb l'objectiu demillorar les prestacions del sistema MP SNAVA, el qual està sent desenvo-lupat pel grup d'investigació AHA de la UPC. SNAVA és un sistema MPemulador de xarxes SNN en hardware. Abans de la realització del projecte,la interfície de xarxa mostrava un conjunt de de�ciències en quant a velo-citat de transmissió i �exibilitat per formar xarxes multi-xip, dos aspectesfonamentals en aquest tipus de xarxes. AER-RT apareix com un substitut del'antiga interfície de xarxa de SNAVA, amb l'objectiu de millorar l'e�ciènciai l'escalabilitat del sistema global.

La interfície de xarxa dissenyada introdueix dos canvis que son clau permillorar l'e�ciència i l'escalabilitat del sistema. 1) La transmissió de les dadesxip-a-xip passa de ser paral·lela a ser sèrie d'alta velocitat; 2) La topologiade la xarxa passa de ser en bus compartit a ser en anell. El primer canvis'aconsegueix utilitzant el protocol per a comunicacions sèrie xip-a-xip Au-rora 8b/10b de Xilinx. I el segon, creant un nou protocol que permeti latransmissió de paquets en una xarxa multi-xip amb topologia en anell.

La interfície de xarxa dissenyada es prova conjuntament amb un emuladorde SNAVA, formant així una xarxa AER-RT real a nivell hardware. La xarxaes compon de 3 FPGAs Kintex-7 connectades en anell. L'elevada velocitat dela nova interfície de xarxa i la gran facilitat per fer-la créixer en nombre dexips fan que l'objectiu marcat a l'inici del projecte s'hagi assolit àmpliament.

xiii

INTERFAZ DE RED AER-RT xiv

Resumen

En esta tesis de máster se presenta el interfaz de red AER-RT, un inter-faz de red diseñado para trabajar junto a un sistema multiprocesador (MP)y crear una red SNN multi-chip e�ciente y escalable.

La creación del interfaz de red AER-RT surge con el objetivo de mejo-rar las prestaciones del sistema MP SNAVA que se desarrolla en el grupode investigación AHA de la UPC. SNAVA es un sistema MP emulador deredes SNN en hardware. Antes de la realización del proyecto el interfaz dered de SNAVA tiene una serie de de�ciencias en velocidad de transmisióny en �exibilidad para formar redes multi-chip, dos aspectos fundamentalesen este tipo de redes. AER-RT aparece como sustituto del antiguo interfazde red de SNAVA con el objetivo de mejorar la e�ciencia y escalabilidad delsistema global.

El interfaz de red diseñado introduce dos cambios clave para mejorar lae�ciencia y la escalabilidad del sistema. 1) La transmisión de los datos chip-to-chip pasa de ser paralela a ser serie de alta velocidad; 2) La topología dela red pasa de ser en bus compartido a ser en anillo. El primer cambio se con-sigue utilizando el protocolo para comunicaciones serie chip-to-chip Aurora8b/10b de Xilinx. Y el segundo creando un nuevo protocolo que permita latransmisión de paquetes en una red multi-chip con topología en anillo.

El interfaz de red diseñado se prueba junto a un emulador de SNAVAimplementando una red AER-RT real hardware. La red está compuesta por3 FPGAs Kintex-7 conectadas en anillo. La elevada velocidad del nuevo in-terfaz de red y la gran facilidad para hacerla crecer en número de chips hacenque el objetivo marcado al inicio del proyecto se haya cumplido ampliamente.

xv

INTERFAZ DE RED AER-RT xvi

Abstract

This thesis presents AER-RT network interface, a network interface desig-ned to work together a Multiprocessor System (MPS) and create an e�cientand scalable multi-chip SNN network.

The objective of AER-RT is to improve performance of SNAVA system.SNAVA is a MPS capable of SNN emulation in Hardware created by UPC'sAHA research group. Before this thesis, the network interface of SNAVAhave pitfalls regarding speed transmision and �exibility to create multi-chipnetworks, two important aspects in this kind of networks. AER-RT appearsas substitute of the old network interface of SNAVA with goal of improvespeed and scalability of the global system.

The network interface intruce two main changes to improve speed andscalability of the system. 1) The previous parallel chip-to-chip communica-tion becomes high speed serial communication. 2) The previous shared bustopology becomes ring topology. The �rst change is achieved by using XilinxAurora high speed communication protocol. And the second one, by crea-ting a new protocol able to transmit packages in a multi-chip ring topologynetwork.

The designed network interface is proved together a emulation of SNAVAsystem forming a real AER-RT network in Hardware. The network consistsin 3 Kintex-7 FPGAs connected forming a ring. The network works �nemaking the global SNN more e�cient and more �exible to grow.

xvii

INTERFAZ DE RED AER-RT xviii

Capítulo 1

Introducción

1.1. Presentación

En esta tesis de máster se presenta el interfaz de red AER-RT (AER-Ring Topology), una novedosa arquitectura de comunicaciones para SNNmulti-chip con las siguientes características:

Permite conectar un gran número de chips en anillo

El diseño es simétrico en cada nodo del anillo. Por lo tanto no haynecesidad de establecer un nodo máster

Es �exible en cuanto al número de nodos en el sistema

Permite altas velocidades de transmisión. La comunicación entre nodoses serie, punto a punto y de alta velocidad (del orden de Gbps)

Para la distribución de spikes utiliza el protocolo AER-RT encapsuladoen el protocolo serie de alta velocidad Aurora (protocolo propiedad deXilinx)

A continuación pasamos a introducir una serie de conceptos fundamentalespara entender el contexto en el que se enmarca esta tesis.

1.2. De�niciones

1.2.1. SNN

Las redes SNN (Spiking Neural Network) son un tipo de redes neurona-les. Pertenecen a la tercera generación de redes neuronales y se caracterizanpor representar de forma realista el funcionamiento neuronal. Su utilizaciónen sistemas bioinspirados o para emular sistemas neuronales reales está su-mamente extendido.

1

INTERFAZ DE RED AER-RT 2

Las redes SNN se pueden simular mediante Software o emular en Hard-ware. Debido a su arquitectura paralela, su gran demanda de cómputo y a lanecesidad de trabajar en tiempo real, la emulación de redes SNN en Hard-ware está plenamente justi�cada.

Las redes SNN emuladas en Hardware se implementan mediante un sis-tema multiprocesador (MP), donde los procesaodres (PE) se interconectanentre ellos a través de un interfaz de red. Cada procesador emula a una neu-rona y la sinapsis se emula mediante la transmisión de spikes. Un spike esun evento que se produce en una determinada neurona y que se transmite aotras neuronas adyacentes.

En redes SNN implementadas en Hardware uno de los principales desafíoses el diseño de la arquitectura de comunicaciones. Interesa una arquitecturade red que permita conectar el mayor número de neuronas trabajando dentrode la ventana que marca el tiempo real.

1.2.2. AER

AER es el acrónimo de Adress Event Representation. Es un protocoloque permite transmitir eventos de forma e�ciente dentro de una red, dondecada nodo es a la vez consumidor y generador de eventos. Los eventos seindican transmitiendo la dirección del elemento generador.

El Bus AER o protocolo AER es muy utilizado en redes SNN. En estetipo de redes las neuronas son generadores y consumidores de eventos. Y loseventos son los spikes que se transmiten en la red viajando de una neuronaa otra.

1.2.3. Ubichip

En el grupo de investigación AHA de la UPC se trabaja desde hace algu-nos años en el desarrollo de sistemas bioinspirados y redes neuromór�cas. Enconcreto, enmarcado dentro del proyecto �Perplexus�[1], AHA presenta unanovedosa arquitectura Hardware para emular redes de tipo SNN. Se trata dela arquitectura Ubichip.

La arquitectura Ubichip permite emular redes neuronales en un sistemamultichip, donde cada chip, o Ubichip, contiene un array de hasta 10x10neuronas. Para comunicar las neuronas entre sí se utiliza un interfaz de redbasado en el protocolo AER. Ver �gura 1.1 para un esquema detallado deUbichip.


Figura 1.1: Esquema sistema Ubichip[4]

El sistema multiprocesador implementado en un Ubichip es de tipo SIMD(�Single Instruction Multiple Data�). En este sistema el secuenciador se en-carga de enviar las instrucciones a todos los elementos procesadores (PE) delarray. Una vez el array de neuronas ha procesado los datos genera una seriede spikes para transmitir. Los spikes se transmiten por el bus AER. CadaUbichip al recibir los spikes los decodi�ca utilizando una memoria CAM. Enla memoria CAM de cada chip está mapeado qué spikes harán que se dispa-re su potencial de membrana. Para una información más detallada sobre laarquitectura Ubichip consultar la referencia [4].

El interfaz de comunicaciones de Ubichip es un bus �o� chip� con unatopología de bus compartido. La comunicación es paralela con palabras de 8bits. Este bus permite trabajar a frecuencias de hasta 5 MHz y admite unacierta escalabilidad, aunque el hecho de ser un bus compartido introducealgunas di�cultades en cuanto a la implementación física. Además a medidaque se conectan más chips al bus compartido la frecuencia de trabajo se re-duce. Tenemos un esquema de este interfaz de red previo en la �gura 1.2. Apartir de ahora se hará referencia a esta arquitectura de red como el interfazde red previo. Para una descripción más detallada sobre este interfaz de redprevio consultar la referencia [3].


Figura 1.2: Interfaz de red AER previo de bus compartido[3]

La duración estándar de un ciclo sináptico en el sistema Ubichip es de1 ms, es la ventana de tiempo que impone el trabajar en tiempo real enredes de tipo SNN. Cada ciclo sináptico se divide en 1) Fase de ejecucióny 2) Fase de distribución. Durante la fase de ejecución cada PE ejecuta susinstrucciones y genera una serie de spikes de salida. Durante la fase de distri-bución el interfaz de red distribuye los spikes generados por todos los chipsque componen el sistema. Para simpli�car supondremos que cada una de lasfases emplea la mitad de la ventana de tiempo de 1 ms, es decir la fase deejecución durará 0,5 ms y la fase de distribución otro tanto.

1.2.4. SNAVA

Recientemente en el grupo de investigación AHA de la UPC se han me-jorado las prestaciones del sistema Ubichip con la aparición de una nuevaarquitectura multiprocesador para redes de tipo SNN: SNAVA. SNAVA con-serva la misma �losofía de Ubichip pero incorpora una serie de mejoras. Porejemplo el cuello de botella que introducía el acceso a la memoria que contie-ne las instrucciones en cada chip se ha solucionado sustituyendo la memoriade tipo SRAM externa por memoria cache local. Otra novedad es la inclusiónde un sistema de virtualización que permite emular más de una neurona encada PE.

Sin embargo uno de los principales cuellos de botella de Ubichip, SNA-VA no lo soluciona. Es la distribución de spikes. El antiguo interfaz de red


se muestra insu�ciente para distribuir todos los spikes que genera un sis-tema SNAVA multichip de manera e�ciente. Este interfaz previo es pocoescalable por los problemas que introduce el bus compartido a la hora deincluir nuevos chips en la red. De hecho en la práctica sólo ha sido posibleimplementar una red SNN con un único chip. Además es poco e�ciente encuanto a velocidad de transmisión con frecuencias que no superan los 5 MHz.

El interfaz de red AER-RT que se presenta en este proyecto se ha desa-rrollado con el propósito de contribuir a la mejora de prestaciones de laarquitectura Ubichip. En concreto AER-RT implementa un novedoso inter-faz de red que mejora la e�ciencia y la escalabilidad del sistema global. Esteinterfaz ha sido adoptado por el sistema SNAVA como nuevo interfaz de redsustituyendo al interfaz previo de bus compartido.

1.3. Objetivos y requisitos

El objetivo de este proyecto es el de desarrollar un interfaz de red quepermita conectar neuronas en una red SNN multi-chip de forma e�ciente yescalable.

Características a optimizar con el diseño del interfaz de red AER-RT:

E�ciencia

Escalabilidad

Un interfaz de red e�ciente implica que la transmisión de spikes entre neu-ronas sea rápida. De esta manera tendremos capacidad para distribuir unmayor número de spikes, lo que supone poder emular un mayor número deneuronas en el sistema SNN.

Escalable hace referencia a la capacidad que tiene el sistema para crecer.En el caso que nos ocupa el interfaz de red tiene que permitir que el siste-ma multiprocesador que emula la red SNN crezca en número de chips y ennúmero de neuronas. Buscamos que al aumentar el tamaño del sistema lasprestaciones de éste no disminuyan y que la ampliación sea sencilla y baratade implementar.

La red estará formada por varios nodos, donde cada nodo es una FPGA.Las FPGAs tendrán que estar conectadas entre sí permitiendo la distribu-ción de spikes por todo el sistema. Cada nodo contendrá un array de, segúnla última versión de SNAVA, 10x10 PE con capacidad para emular hasta 700neuronas (7 neuronas emuladas en cada PE).


El interfaz entre el bloque AER-RT y el sistema multiprocesador tieneque ser compatible con el que tenía el interfaz previo de bus compartido.

1.4. Material de trabajo

Durante la realización del proyecto se dispone del siguiente material paraimplementar y depurar el diseño propuesto:

4 placas de evaluación KC705 [8]. Cada una de ellas con una FPGA dealtas prestaciones Kintex-7 de Xilinx

Cables SMA para transmisión de señales de alta frecuencia

Programa para simulación de sistemas digitales Questa Sim (de la casaMentor Graphics)

Herramientas de síntesis y rutado de Xilinx (Suite ISE)

Analizador lógico virtual ChipScope de Xilinx

1.5. Realización del proyecto

La realización del proyecto consta de las siguientes etapas:

1. Estudio de diferentes arquitecturas de red. Finalmente se opta por uninterfaz de red con topología en anillo y comunicación serie de altavelocidad. Este punto se explica en el capítulo 2

2. Diseño de protocolo AER-RT. En este punto se modi�ca el protocoloAER para que pueda ser utilizado en una red con topología en anillo.Los detalles de este protocolo se encuentran explicados en el capítulo3

3. Diseño de la arquitectura de red AER-RT. Esta es la parte dondese hace el diseño del sistema digital en VHDL . Los detalles de laarquitectura desarrollada están en el capítulo 4

4. Veri�cación de funcionamiento implementando un sistema SNN com-pleto. Para completar este paso se construye un sistema digital queemula el comportamiento del sistema multiprocesador SNAVA y quese conectará con el interfaz AER-RT. Se veri�ca el funcionamiento delsistema en una red en anillo con varios nodos y donde cada emuladorde SNAVA genera spikes pseudo-aleatorios periódicamente

Finalmente una vez validado el diseño, el interfaz AER-RT se ha incluido enel sistema SNAVA como nuevo interfaz de red con éxito.

Capítulo 2

Diseño

En este capítulo se presentan las principales decisiones de diseño que sehan adoptado a la hora de realizar el diseño del interfaz de red AER-RT, asaber:

Topología en anillo frente a bus compartido

Comunicación serie frente a comunicación paralela

Elección del protocolo físico para comunicaciones serie de alta velocidadque permite la comunicación FPGA-to-FPGA

2.1. Estudio de la topología

A continuación se estudian tres posibles topologías como sustitutas dela topología de bus compartido que presenta el interfaz de red previo. Paraevaluar la e�ciencia de cada topología se analiza cuantos nodos o chips ad-mitiría una red SNN respetando una ventana de tiempo para la distribuciónde spikes de 0,5 ms.

2.1.1. Topología en Anillo

Para realizar el estudio de las diferentes topologías de red utilizaremoslos siguientes parámetros:

#chips: número de chips que tiene la red (equivale a número de nodos)[spikes

neuronas

]AV

: Spikes transmitidos por cada neurona en cada fase de

distribución (valor medio)

N/C: Número de neuronas por chip

7


Figura 2.1: Ring Topology

[spikeschip

]AV

=[

spikesneurona

]AV

� N/C: Spikes transmitidos por chip en cada

fase de distribución (valor medio)

T: Latencia o tiempo en completarse la transmisión de todos los spikes.Tiempo de la fase de distribución de spikes

spikes totales del sistema: #chips �[spikeschip

]AV

En la �gura 2.1 se puede observar la estructura de una red en anillo. Laexpresión de la latencia en este tipo de redes se presenta en la ecuación 2.1.Esta expresión se obtiene teniendo en cuenta que el retardo en un sistema enpipeline es igual al retardo que introduce el pipeline más el retardo introdu-cido por el número de spikes total que viajan por el sistema. El retardo queintroduce el pipeline es igual al número de elementos que lo forman, en estecaso el número de chips del sistema. Y El retardo que introduce el número despikes total que viaja por el anillo lo aproximamos por el número de spikesque tarnsmite cada chip por el número de chips del sistema.

Tanillo =

[#chips+#chips �

[spikes

chip

]AV

]� 1/fCLK (2.1)

Tanillo∼= #chips �

[spikes

chip

]AV

� 1/fCLK (2.2)

#chips =T � fCLK[spikeschip

]AV

(2.3)

En la ecuación 2.2 simpli�camos el cálculo de la latencia despreciando elretardo que introduce el pipeline, ya que comparado con el número de spikesque se transmiten en todo el sistema es muy pequeño. Por lo tanto podemosconcluir que la latencia en este tipo de redes es proporcional al número dechips, el número de spikes por chip medio e inversamente proporcional a la


Figura 2.2: Latencia de la red en función del número de nodos (o chips)

frecuencia de trabajo.

En la ecuación 2.3 tenemos la expresión que indica el número de chipsque acepta el sistema en función de la latencia, la frecuencia y el número despikes transmitidos por chip.

Ejemplo numérico

Si �jamos la frecuencia de trabajo a 200MHz y el número de spikes trans-mitidos por chip en 105 (700 neuronas por chip y suponemos 15 spikes gene-radas cada 100 neuronas) el número máximo de chips que admite el sistemarespetando la ventana de 0,5 ms para la fase de distribución es de 952 chips.Si cada chip como decíamos tiene 700 neuronas esto hace un total de 660kneuronas. En la �gura 2.2 podemos ver la evolución de la latencia en funcióndel número de chips del sistema.

2.1.2. Topología en Estrella

En el caso de una topología en estrella (�gura 2.3) surge la necesidad deutilizar un elemento adicional en la red que actúe como repetidor.

En una red en estrella la latencia es igual a el retardo que introduce elchip con mayor número de spikes (peor caso) más el retardo introducido porel número de spikes global (ecuación 2.4). En este caso despreciamos el re-tardo que introduce el chip y obtenemos la misma expresión para la latenciaque en el anillo (ecuación 2.5).

Testrella =

[[spikes

chip

]MAX

+#chips �

[spikes

chip

]AV

]� 1/fCLK (2.4)


Figura 2.3: Star Topology

Figura 2.4: Red en malla

Testrella∼= #chips �

[spikes

chip

]AV

� 1/fCLK (2.5)

La desventaja en este tipo de arquitectura es la necesidad de un grannúmero de elementos repetidores. El número de repetidores necesarios vienede�nido por la cantidad de puertos de transmisión que tengan.

Ejemplo numérico

El número de chips máximo es el mismo que se obtiene con la topología enanillo: 952. El inconveniente es que necesitamos 90 repetidores en el sistema(suponiendo que cada repetidor dispone de 10 puertos de transmisión).

2.1.3. Topología Punto a Punto

En una red punto a punto o en malla como la de la �gura 2.4, la latenciaes igual al tiempo de transmisión en uno sólo de los chips. Tomamos el chipcon más spikes para transmitir como peor caso y obtenemos que la latenciaes igual al número de spikes que se transmiten en ese chip por el inverso dela frecuencia de trabajo (ecuación 2.6).


Figura 2.5: Distribución de probabilidad de localidad en redes SNN[2]

Tmalla =

[spikes

chip

]MAX

� 1/fCLK (2.6)

Si el número de enlaces serie fuera in�nito en cada chip, ésta sería sinduda la mejor opción. Debido a que todos los spikes se transmiten de formaconcurrente, la latencia sólo viene determinada por el número de spikes porchip y por la frecuencia de trabajo (no in�uye el número de chips del sistema).

El límite de esta topología lo impone el número de puertos de comuni-cación de cada chip. La topología punto a punto puede ser interesante paraformar alguna topología híbrida.

Ejemplo numérico

Si tomamos como ejemplo de chip una FPGA Kintex 7 disponemos de28 puertos de comunicación serie bidireccionales. Esto nos permitiría imple-mentar una red de hasta 28 chips (19k neuronas).

2.2. Estudio red jerárquica

En este apartado estudiamos la posibilidad de establecer diferentes nive-les de jerarquía en la red. Pensamos aprovechar la característica de localidadque tienen las neuronas al formar sinapsis. Según se desprende de la �gura2.5 las neuronas tienen más probabilidad de establecer lazos sinápticos conlas neuronas más cercanas.

Podemos aprovechar esta propiedad de localidad y por ejemplo crear unared con dos niveles de jerarquía: redes locales y red global. En la �gura 2.6se muestra un ejemplo de red jerárquica híbrida, en este caso cada chip tiene


Figura 2.6: Red jerárquica híbrida

una red local intra-chip (dentro del chip) de tipo bus compartido, y cadachip forma una red global o�-chip (fuera del chip) en anillo. En una red deeste tipo cada spike que se transmite en cada chip tiene una característicade localidad. Puede ser local o global. Por lo tanto tendremos que añadir acada spike esta propiedad.

Tjerarquica = MAX(Tlocal, Tglobal) (2.7)

Tjerarquica = Tglobal (2.8)

En una arquitectura de red jerárquica, con dos niveles de jerarquía, lalatencia se divide en latencia de la red local y latencia de la red global. Sila distribución de spikes se realiza en paralelo en las dos redes la latenciaserá igual a la mayor de ellas (ecuación 2.7). En el caso de una red SNN lalatencia está dominada por el tiempo que se invierte en transmitir los spikesglobales, por lo que obtenemos la expresión 2.8 para la latencia en una redjerárquica.

Por lo tanto siempre que no todos los spikes sean globales mejoraremosla e�ciencia del bus con respecto a una red no jerárquica (en el peor caso enel que todos los spikes sean globales la igualaremos).


Anillo Estrella Punto a Punto

#chips 952 952 28 (limitado por #puertos en chip)Hardware Adicional NO SI NO

Cuadro 2.1: Tabla comparativa con los ejemplos numéricos vistos en cadatopología

2.3. Conclusión estudio arquitectura de red

De las diferentes topologías analizadas la topología en anillo parece serla mejor elección. Tiene las mismas prestaciones que la topología en estrellay supone un ahorro signi�cativo en Hardware adicional (repetidores). La to-pología punto a punto o en malla tiene la mejor e�ciencia de bus pero estálimitado por las conexiones que tenga cada chip, puede ser interesante paraformar alguna topología híbrida.

Queda alguna topología que puede ser interesante por estudiar:

en mariposa

torus-3D

También se ha analizado que la mejor e�ciencia de red se consigue dotandode jerarquía a la arquitectura de red.

Debido a que tenemos una latencia prácticamente igual a una red en es-trella (o en bus compartido) y a su facilidad de implementación (no necesitaHardware adicional y necesita un reducido número de enlaces) decidimosdesarrollar una arquitectura de comunicaciones con topología en anillo. Secontempla también la posibilidad de extenderla en el futuro a una red jerár-quica.

2.4. Elección de bus serie frente a paralelo

Uno de los objetivos del proyecto es diseñar un interfaz de red que seae�ciente. Eso implica tener una velocidad elevada de transmisión de datos.Por este motivo se plantea la posibilidad de pasar de una comunicación pa-ralela, utilizada en el interfaz de red previo de Ubichip, a una comunicaciónserie de alta velocidad.

Trabajar a altas velocidades en un bus paralelo tiene una serie de des-ventajas:

Más interferencias


Di�cultad de rutar las líneas para igualar retardos

Además es más cara su implementación porque utiliza muchos puertosy líneas.

Por eso la tendencia en comunicaciones de alta velocidad es utilizar comuni-caciones serie:

Mejor integridad de la señal

Mayores frecuencias

Más barato

Por lo tanto para tener un sistema e�ciente se ha optado por una comunica-ción serie. La comunicación serie permite trabajar a frecuencias más elevadasque la paralela, además presenta una serie de ventajas en cuanto a la im-plementación: más barato (menos líneas a rutar, menos puertos a utilizar),mayor inmunidad frente a ruido e interferencias. El hecho de que la trans-misión sea serie añade además facilidad en cuanto a la conexión entre lasdiferentes tarjetas.

Para conseguir velocidades elevadas decidimos utilizar los bloques Giga-bit Transceivers que incorpora la FPGA Kintex-7. Esto supone la necesidadde utilizar un protocolo para transmitir los datos a alta velocidad. Existenvarias posibilidades [7]:

In�niband

Fiber Channel

SATA

PCIe

Finalmente nos decantamos por un protocolo que proporciona Xilinx de ma-nera gratuita y que está ampliamente soportado por las FPGAs de altasprestaciones de este fabricante: Aurora.

2.5. Elección Aurora 8B/10B como protocolo seriede alta velocidad

Al decidir utilizar comunicación serie de alta velocidad nos surge la nece-sidad de usar un protocolo adicional que encapsule los datos y los transmitaa alta velocidad. Esto implica que el protocolo elegido nos tiene que asegurar


una serie de prestaciones necesarias en comunicaciones de este tipo: compen-sación de errores, paridad, codi�cación, distribución de bits, etc. Estudiamosdiferentes opciones (ethernet, crear un protocolo propio, etc) pero �nalmen-te nos decidimos por utilizar el protocolo Aurora 8B/10B de Xilinx por 2razones: 1) simplicidad, 2) prestaciones adecuadas a nuestras necesidades.

Aurora 8B/10B [5] es un protocolo de nivel de enlace escalable y ligeropara comunicaciones serie de alta velocidad. Para utilizar el protocolo entu diseño Xilinx proporciona el Core de propiedad intelectual (IP) Aurora8B/10B. El Core permite establecer transmisión de datos serie entre distintosdispositivos usando los Gigabit Transceivers GTX, GTP y GTH de Xilinx.La velocidad de salida de los datos es escalable desde 480 Mb/s hasta 84,48Gb/s (si se utilizan varios transceivers en paralelo). Los canales de datospueden ser �full-duplex� o �simplex� (bidireccionales o unidireccionales).

Xilinx proporciona el Core en código VHDL o Verilog. En nuestro casousamos la versión en VHDL por compatibilidad con SNAVA.

El IP Core Aurora 8B/10B es versátil en cuanto a aplicaciones debidoa su bajo coste, velocidad escalable y amigable interfaz de usuario. Una delas aplicaciones que se señala en el datasheet del fabricante es �Chip-to-chiplinks�(comunicaciones entre distintos chips). Se señala que con este Core pue-des reemplazar fácilmente las conexiones paralelas entre chips por conexionesserie de alta velocidad, ya que el Core proporciona toda la lógica necesariapara utilizar los bloques Gigabit Transceivers de la FPGA. Además con unconsumo reducido de la lógica de la FPGA.

Como vemos el IP Core Aurora de Xilinx cumple el requisito de e�cienciaque estamos buscando para la red. Además combinado con la topología enanillo permitirá tener un sistema multi-chip escalable.

Ejemplo numérico

La frecuencia de bus máxima en Aurora utilizando un transceiver es de6,4 Gb/s. . Si seleccionamos el bus de datos con tamaño de 16 bits implicauna frecuencia de trabajo a nivel de usuario de 312 MHz. Si aplicamos estosnúmeros a la fórmula para calcular la latencia en una red con topología enanillo (ecuación 2.3) obtenemos una escalabilidad de hasta 1485 chips, másde 1 millón de neuronas.


Capítulo 3

Protocolo AER-RT

3.1. Introducción

En este capítulo se presenta el protocolo AER-RT (AER-Ring Topology).Este protocolo permite la transmisión de spikes en una red SNN con topolo-gía en anillo. La transmisión de spikes se realiza encapsulando los spikes enpaquetes de datos AER-RT que viajan a su vez encapsulados en el protocolode comunicaciones serie de alta velocidad Aurora 8B/10B.

En las �guras 3.1 y 3.2 podemos observar como sería la estructura de unared AER-RT con 2 y 3 nodos respectivamente. Cada nodo es una FPGA eincluye un bloque Aurora bidireccional.

A continuación se enumeran las principales características del protocoloAER-RT:

Está basado en el protocolo AER: la transmisión de spikes se realizatransmitiendo sólo la dirección de la neurona que genera el spike

Permite conectar múltiples chips en anillo

Permite sincronizar todos los chips del anillo para entrar en fase dedistribución al mismo tiempo

Figura 3.1: Anillo AER-RT con 2 nodos

17


Figura 3.2: Anillo AER-RT con 3 nodos

Permite la distribución por todo el anillo de los spikes que genera cadachip

Permite controlar si se pierde alguno de los spikes al viajar por el anillo

Permite añadir un nuevo nodo o chip al anillo sin que suponga cambiarel diseño del interfaz

No necesita que uno de los chips del anillo sea máster, el diseño estotalmente simétrico para todos los nodos del anillo

El único requisito es que cada nodo o chip esté identi�cado con unidenti�cador de chip que denominamos �chip-id�

El interfaz entre AER-RT y el sistema multiprocesador (puede serSNAVA u otro) está perfectamente de�nido y documentado

3.2. Problemática de diseño

El desarrollo del protocolo AER-RT presenta los siguientes puntos críticosa la hora de realizar el diseño

1. Sincronización entre diferentes nodos del anillo

2. Distribución de spikes en el anillo (necesidad de establecer un canal de�Bypass� en cada anillo)

3. Detectar cuando se ha completado la distribución de spikes


3.3. Sincronización entre los nodos del anillo

Uno de los primeros problemas a solucionar es cómo sincronizar los di-ferentes chips del anillo. En el sistema multiprocesador que acompaña alinterfaz de red AER-RT como sabemos hay un array de PE que emulanneuronas. Estos PE procesan los datos de entrada en la fase de ejecución ygeneran los spikes a distribuir durante la fase de distribución. El problemaes que todos los chips no tienen por que contener la misma secuencia deinstrucciones, por lo que en cada chip la fase de ejecución puede terminar enun momento distinto.

El problema a solucionar por lo tanto es como saber en un determinadochip que todos los chips han terminado la fase de ejecución y por lo tanto sepuede comenzar con la fase de distribución.

A continuación presentamos 3 alternativas para realizar la sincronización.

3.3.1. Sincronización de nodos mediante líneas punto a pun-to

Esta solución consiste en utilizar una puerta lógica de tipo AND dondecada una de sus entradas corresponde a una señal proviniente de cada unode los chips con información de si se ha acabado la fase de ejecución (1: seha acabado; 0: no se ha acabado). De esta manera cuando tengamos un 1lógico a la salida de la puerta AND podremos asegurar que todos los nodosestán listos para transmitir. Esta solución implica utilizar N + 1 cables enuna red de N nodos. Además necesitamos lógica adicional para implementarla puerta AND con tantas entradas como nodos tenga el sistema (ver �gura3.3). Como punto positivo la arquitectura Hardware sería simétrica en todoslos chips, ya que no necesita que un chip comience la transmisión, es decirno necesita que uno de los chips actúe como máster.

3.3.2. Sincronización de nodos mediante línea adicional deready en pipeline

Esta solución consiste en conectar cada chip con su vecino mediante unalínea externa (línea de ready). Mediante esta línea cada chip propaga suestado y el de los chips que lo preceden. Cuando tenemos un positivo a laentrada hay que esperar a que éste sea estable como mínimo el tiempo quetarda en propagarse la señal ready por todo el anillo.

Esta solución necesita menos líneas adicionales que la anterior, pero pre-senta el inconveniente que uno de los chips tiene que actuar como máster e


Figura 3.3: Sincronismo línea externa punto a punto

Figura 3.4: Sincronismo entre chips mediante línea de control en pipeline

iniciar la propagación de su estado (en la �gura 3.4 el chip_1). Esto implicadiferente lógica según el chip sea máster o no. O añadir un registro de con-�guración a cada chip que le indique si es máster. En la �gura 3.4 la señal�eo_exec� se pone a '1' cuando se completa la fase de ejecución.

3.3.3. Sincronización de nodos mediante paquetes de control

Esta solución consiste en utilizar el propio canal de comunicaciones pararealizar la sincronización. El proceso de sincronización según este métodoconsta de los siguientes pasos:

1. Cuando un chip ha terminado la fase de ejecución envía un paquete desincronización con su chip-id.

2. Cada chip va contabilizando los paquetes de sincronización que recibe.

3. Cuando un determinado chip contabiliza n paquetes de sincronizacióny el número de chips en el sistema es de n, entonces está sincronizadoy puede iniciar la fase de distribución.

Hay un desfase de como máximo de n ciclos de reloj entre que empieza atransmitir el primer chip hasta que lo hace el último. Pero esto no implica


ningún problema a nivel práctico.

Ésta es la solución que se utiliza �nalmente. Reúne la ventaja de tener undiseño de Hardware simétrico para cada nodo del anillo (no hay necesidadde nodo máster), y además no es necesario utilizar ningún recurso adicional.Eso sí, implica introducir un mecanismo de sincronización dentro del propioprotocolo.

3.4. Protocolo AER-RT

El protocolo AER-RT se encarga de distribuir mensajes de tipo AER(transmisión de dirección de elemento generador de evento) en una red mul-tiprocesador SNN. En primer lugar se encarga de sincronizar todos los nodosdel anillo. Una vez sincronizados todos los nodos, comienza la distribuciónde todos los spikes del sistema. Además cada spike, una vez que ha sidoprocesado por todos los nodos de la red, regresa al chip que lo generó y eneste punto muere. De esta manera podemos controlar en cada chip si se haperdido algún paquete de los que él mismo generó.

En la �gura 3.5 se presenta un esquema del funcionamiento del proto-colo: el chip �n� crea paquetes y los envía. Estos paquetes son recibidos yprocesados por el chip adyacente en el anillo �n+1�, el cual los reenvía al chip�n+2� del sistema. Finalmente cuando el paquete alcanza otra vez el chip n,donde fue generado, muere.

El protocolo consta de tres fases:

1. Fase de sincronización: Se envían paquetes de sincronismo para asegu-rar que la distribución de spikes comienza cuando todos los chips hanacabado la fase de ejecución

2. Distribución de spikes: Los spikes que genera cada chip son enviadoscomo paquetes de datos. Cada paquete tiene un tiempo de vida limi-tado. Una vez que ha recorrido todo el anillo y vuelve al chip que logeneró muere

3. Fin distribución de spikes. Un chip sabe que ha recibido todos los spi-kes del sistema cuando recibe el paquete FINISH que él mismo generópreviamente, o alternativamente cuando contabiliza tantos paquetesFINISH como nodos hay en el sistema. El paquete FINISH se envíacomo último paquete después de enviar el último spike en un determi-nado chip.


Figura 3.5: Arquitectura pipeline en anillo

3.4.1. Tipos de paquetes

En el interfaz de red diseñado, la información se transmite encapsuladaen paquetes AER-RT de 16 bits. Hay dos tipos de paquetes: paquetes dedatos y paquetes de control. En la tabla 3.1 se presentan los diferentes tiposde paquetes AER-RT.

Los paquetes de datos transmiten la dirección de la neurona fuente quegenera el spike (protocolo AER). Sin embargo no contienen información sobrequé chip ha generado el spike (chip-id). La dirección de cada chip (chip-id)va contenida en los paquetes de control. Por esta razón los paquetes de datossiempre han de ir precedidos de un paquete de control START, para conocerde que chip provienen.

Los paquetes de datos se transmiten en ráfagas. Cada ráfaga correspondea datos provenientes de un determinado chip y está precedida por un paque-te de START. El paquete de START es imprescindible ya que proporcionainformación sobre el chip id de todos los paquetes de datos de la ráfaga.Finalmente la ráfaga �naliza con un paquete de FINISH.

Dentro de los paquetes de control hay 4 subtipos: SYNC, START, FI-NISH y IDLE.

El paquete de control START se utiliza para transmitir el chip-id de lospaquetes de datos que precede.

El paquete de control FINISH se encarga de señalar cuando termina unaráfaga de datos de un determinado chip. Además permite conocer cuando seha terminado la fase de distribución. Cuando en el receptor contabilizamos


Control SYNCSTARTFINISHIDLE

Datos

Cuadro 3.1: Tipos de paquetes AER-RT

tantos paquetes FINISH como nodos hay en el sistema, podemos asegurarque la distribución de spikes se ha completado y que por lo tanto se ha com-pletado un ciclo AER-RT.

Los paquetes de control de sincronismo o paquetes SYNC son utilizadosdurante la fase de sincronización. Cada vez que un chip ha terminado la fasede ejecución en su sistema multiprocesador, y por lo tanto está listo paraentrar en la fase de distribución de spikes, envía un paquete de sincronismo.Este paquete simplemente contiene el chip-id del chip que lo generó. De for-ma equivalente cada chip en el anillo hará lo mismo cuando esté listo paracomenzar la fase de distribución de spikes. Finalmente cuando en un deter-minado chip se reciben todos los paquetes de sincronismo del sistema (tantoscomo nodos hay en el anillo), incluido el generado por él mismo, indica queya están todos los chips listos. En este momento se empiezan a distribuir losspikes por el anillo.

Los paquetes de control de tipo IDLE son paquetes que se generan cuandoel sistema está en reposo, de ahí su nombre. Este tipo de paquetes se añadióposteriormente a la primera concepción del protocolo. Surge como necesidaddespués de observar que si no se transmiten datos por el enlace serie duranteun periodo largo de tiempo, aparecen errores en el enlace. De esta maneraen los momentos que el protocolo está en reposo se envían constantementepaquetes de tipo IDLE. Así el enlace se mantiene en perfectas condiciones ysin ningún error.

3.4.2. Estructura de los paquetes

Los paquetes AER-RT son paquetes de 16 bits. Los paquetes de datos sedistinguen de los de control por el primer bit. Es la cabecera AER-RT (H).Si tenemos un 0 son paquetes de control y si tenemos un 1 son paquetes dedatos.

En los paquetes de datos tan sólo hay un bit de cabecera, los 15 bits res-tantes se pueden utilizar para transmitir datos (en el sistema implementadosólo utilizamos 11 de estos bits). La decisión de no incluir la dirección dechip en el paquete de datos nos permite una mayor e�ciencia en el número


1 bit 3 bits 5 bits 7 bitsH H_CONT UNUSED chip-id

Cuadro 3.2: Paquete de Control AER-RT

1 bit 4 bits 11 bitsH UNUSED _____DATOS_____

Cuadro 3.3: Paquete de datos AER-RT

de neuronas que podemos direccionar dentro de un mismo chip. Ver �gura3.3.

En los paquetes de control hay 3 bits adicionales de cabecera, es lo quellamaremos cabecera de control. Según el valor de éstos tres bits adicionalesidenti�caremos los diferentes paquetes de control: SYNC, START, FINISH,IDLE. Además en los 7 bits de menos peso está contenido el chip-id. Ver�gura 3.2.

3.4.3. Campos de los paquetes

A continuación se enumeran los diferentes campos que contienen los pa-quetes AER-RT. En las tablas 3.4 y 3.5 se muestran los valores de las cabe-ceras AER-RT y de control según el tipo de paquete.

1. H (1 bit). Cabecera. Indica el tipo de paquete

2. H_CONT (3 bits). Cabecera de control. Indica el tipo de paquete decontrol

3. UNUSED. Bits no utilizados pero disponibles si se quiere aumentar losbits utilizados para datos (en paquetes de datos) o para chip-id (enpaquetes de control)

4. chip-id (7 bits). Es la dirección del chip que generó el paquete. Nospermite hasta 128 chips (ampliable)

5. DATOS (11 bits). Es la dirección de la neurona que generó el spike.Permite hasta 2048 neuronas en cada chip. Ampliable hasta 32768neuronas por chip si utilizamos los 15 bits de datos del paquete dedatos.

3.4.4. Detección de errores

El hecho de que los paquetes de datos viajen por el anillo y vuelvan almismo chip que los generó permite conocer si se ha producido algún error o

Cabecera AER-RT Tipo de paquetes

0 Control1 Datos

Cuadro 3.4: Cabecera AER-RT

Cabecera de control Tipo de paquete

100 IDLE101 SYNC110 START111 FINISH

Cuadro 3.5: Cabecera de control

alguna pérdida de datos. De esta manera se planea detectar pérdidas de pa-quetes mediante un contador en transmisión y otro en recepción. Y detectarla integridad de los datos mediante el cálculo del �checksum� de los paquetesde datos transmitidos y recibidos.

3.5. Interfaz entre AER-RT y sistema multiproce-sador

El interfaz AER-RT está ideado para trabajar en conjunto con un sistemamultiprocesador. Por lo tanto es fundamental que quede bien de�nido elinterfaz entre ambos subsistemas. En la �gura 3.6 podemos observar la uniónde estos bloques en un esquema de red con 3 chips.

3.5.1. Interfaz de datos

¾Cómo le indica el sistema multiprocesador al interfaz AER-RT los spikesque quiere que se distribuyan por el sistema? El método consiste en escribiren la FIFO de entrada del interfaz AER-RT todos los spikes a transmitir, yacto seguido, una vez escritos todos los spikes, activar la señal que indica el�nal de la fase de ejecución �eo_exec�.

Por su parte el interfaz de recepción AER-RT irá sacando datos en el busde recepción a medida que los vaya recibiendo. Se planea construir un bloqueadicional que traduzca y sincronice la recepción de estos datos con el interfazde recepción del sistema SNAVA. Una vez recibidos todos los datos o spikesse genera un pulso en el puerto �eo_didtrib� que viaja hasta el sistema MPpara indicar que la fase de distribución se ha completado.

25

Figura 3.6: Esquema de la unión entre sistema MP y AER-RT en red con 3nodos

26


Figura 3.7: Cronograma �Handshaking� entre AER-RT y sistema MP

3.5.2. Handshaking (o señales �eo_exec� y �eo_distrib�)

Las señales de Handshaking entre AER-RT y el sistema MP permitenque cada bloque conozca en que punto del ciclo de emulación se encuentra.Recordamos que un ciclo de emulación se divide en fase de ejecución y fasede distribución de spikes.

El comienzo del protocolo AER-RT se produce al recibir un nivel lógicoalto en el puerto de entrada �eo_exec� (eo_exec=end of execution). El sis-tema multiprocesador le indica mediante esta señal al interfaz AER-RT queha terminado la fase de ejecución, y por lo tanto puede empezar la fase dedistribución.

Una vez terminada la distribución de spikes y por lo tanto completadoun ciclo AER-RT se le indica al sistema multiprocesador mediante un pulsoen el puerto de salida �eo_distrib� (eo_distrib = end of distribution).

De manera periódica se alternan fases de ejecución y de distribución conun cronograma para las señales �eo_exec� y �ei_exec� como el que vemos enla �gura 3.7.

3.5.3. Señal de Error

En el momento de generar la señal �eo_distrib�, que indica el �nal de lafase de distribución, se actualiza la señal de error �AER_error�. Si la señalvale uno quiere decir que durante la fase de distribución se han perdidopaquetes, en caso contrario la distribución de spikes se ha realizado conéxito.


Capítulo 4

Arquitectura AER-RT

4.1. Introducción

La función principal del interfaz de comunicaciones AER-RT es la dedistribuir spikes (o paquetes de datos) a lo largo de un anillo con N nodos.Por lo tanto, a nivel de Hardware, necesitamos un transmisor, un receptory un sistema de bypass que permita pasar los datos de un nodo a otro enel anillo. En la �gura 4.1 podemos ver un esquema simpli�cado del interfazAER-RT.

Como se puede apreciar en el esquema simpli�cado de la �gura 4.1, elsistema consta de cuatro bloques principales: Aurora, AER RX, BYPASS yAER TX.

El bloque Aurora se encarga de encapsular y desencapsular los datosque se transmiten y reciben con el protocolo serie de alta velocidadAurora de Xilinx

AER RX es el bloque de recepción donde se reciben los paquetes AER-RT provenientes del interfaz de recepción de Aurora. Los paquetes dedatos se desencapsulan y se envían al sistema multiprocesador

BYPASS es el bloque encargado de transmitir desde recepción hastatransmisión los paquetes recibidos que hay que retransmitir

AER TX se encarga de crear los paquetes AER-RT y de transmitirlosal bloque Aurora. Los paquetes de datos los crea a partir de los datosrecibidos del sistema multiprocesador

En la �gura 4.2 podemos observar un diagrama de bloques del interfazde red AER-RT más detallado. Vemos que el sistema de bypass se realizamediante una FIFO, es la que llamaremos �Bypass FIFO�. Esta FIFO se

29

Figura 4.1: Esquema AER-RT simpli�cado

30

Figura 4.2: Versión de�nitiva Diagrama de bloques AER-RT31

encarga de amortiguar los datos que se tienen que retransmitir. La FIFOde entrada �Input FIFO�, por su parte, se encarga de almacenar los spi-kes provenientes del sistema multiprocesador y que hay que distribuir porel anillo. El bloque AER Con�g se encarga de guardar los parámetros decon�guración del sistema (chip-id, ring_size, debug_mode). Por su parte elbloque AER_error se encarga de comprobar se se han perdido datos duran-te un ciclo de distribución. Si nos �jamos podemos ver que entre el bloqueAER RX y AER TX hay 2 señales de control: AER_on y AER_done. Es-tas señales son fundamentales para el correcto funcionamiento del sistemaAER-RT. AER_on permite identi�car cuando se ha completado la fase desincronización y puede empezar la fase de distribución; y AER_done indica�n de la fase de distribución y de ciclo AER-RT. El bloque CC_MODULEque conecta con Aurora es el bloque encargado de la compensación de clock.La compensación de clock se produce periódicamente en el enlace Aurora yconsiste en que el enlace queda inhabilitado durante un número de ciclos dereloj determinado mientras Aurorarealiza tareas de reajuste. Mientras el en-lace está inhabilitado no se pueden transmitir datos y el sistema se tiene queponer en un estado de espera hasta que se vuelva a liberar el enlace. Una vezliberado el sistema AER-RT reanuda su funcionamiento en el mismo puntoque se quedo en el inicio de la fase de compensación de clock.

En cuanto a los puertos de entrada/salida que dispone AER-RT paracomunicarse con el sistema multiprocesador podemos distinguir 2 tipos. Lasseñales de �Handshaking� con el sistema multiprocesador:

�AER_eo_exec� es una entrada. Permite que el sistema MP indiqueque ha terminado la fase de ejecución y que se puede comenzar unnuevo ciclo AER-RT

�AER_eo_distrib� es una salida. Permite noti�carle al sistema MPque la fase de distribución a concluido

y los diferentes interfaces para realizar la transmisión de datos:

Interfaz AER TX. El interfaz de transmisión permite que el sistema MPescriba los spikes que quiere que se distribuyan. Los spikes se almacenanen la FIFO de entrada �Input FIFO� hasta que se distribuyen por elanillo. El interfaz incluye la necesidad del reloj del sistema MP. El relojse utilizará para escribir en �Input FIFO�, ya que el interfaz de entradadiferencia entre 2 dominios de reloj, el de escritura y el de lectura. Deesta forma se puede realizar la sincronización de datos entre el sistemaMP y el interfaz AER-RT. Estos dos bloques están alimentados con 2señales de reloj físicamente diferente por lo que representan dominiosde reloj independientes

32


Interfaz AER RX. El interfaz de recepción devuelve al sistema mul-tiprocesador los spikes que provienen de la red multichip. El interfazconsiste en una señal de validación y el bus de datos

4.1.1. Diferentes versiones

La primera versión de la arquitectura de el interfaz AER-RT ya fue con-cebida en Diciembre de 2012 (�gura 4.3). En esta primera versión ya estáde�nida la arquitectura fundamental, aunque se irán introduciendo algunoscambios. Por ejemplo en un principio se pensaba utilizar el modo �Simplex�del IP Core Aurora (unidireccional) y �nalmente se ha utilizado el modo�Duplex� (bidireccional). La razón de este cambio es que la con�guraciónDuplex de Aurora es más robusta y más fácil de implementar. También secontemplaba la opción de que la arquitectura fuera jerárquica y que distin-guiera entre spikes locales y globales tal como se aprecia al observar que hayvarias FIFOs adicionales. Esta opción no se ha llegado a materializar porfalta de tiempo.

4.1.2. Metodología

Hemos tratado de crear un sistema lo más modular posible, además detratar de simpli�car al máximo el diseño (�losofía �KISS�: �Keep it simple,stupid�), si algo puede ser simple y funcionar no lo hagas complicado. Tam-bién se ha empleado con éxito la técnica de �divide and conquer� (�divide yvencerás�), lo que ha facilitado la implementación de los bloques más comple-jos como el controlador de transmisión. Además, una vez diseñado el sistemaen papel, se sigue un método de diseño incremental para implementar elsistema. Este método consiste en comenzar impementando un sistema bá-sico y, una vez probado y asegurada su robustez, ampliarlo con una nuevafuncionalidad. Y así progresivamente hasta que tengamos el diseño completo.

Por ejemplo, en una primera etapa implementamos un anillo muy simple,dónde un chip actúa como generador/receptor de datos pseudoaleatorios yel resto de chips hacen un bypass de lo que reciben. En la �gura 4.4 pode-mos ver esta primera etapa de diseño incremental. En esta primera etapa eldiseño ya es simétrico para todos los chips, seleccionamos si establecer ge-neración/recepción de datos o bypass mediante un multiplexor atacado porel parámetro de con�guración �chip-id�. Progresivamente fuimos añadiendofuncionalidades al sistema. Primero sincronización, luego datos, �nalmen-te detección de errores. Esta forma de trabajar permite localizar y depurarfácilmente las partes críticas del diseño.


Figura 4.3: Primera versión diagrama de bloques (Diciembre 2012)


Figura 4.4: Primer paso en el diseño incremental

4.2. Interfaz con sistema Multiprocesador

4.2.1. Problema adicional: 2 dominios de reloj

El sistema resultante al unir el interfaz de red AER-RT y el sistema mul-tiprocesador tiene dos dominios de reloj físicamente diferentes. El sistemaAER-RT utiliza el reloj recuperado de los datos transmitidos por el enlaceserie Aurora, y el sistema MP tiene su propio reloj. Estos relojes podemosajustarlos a la misma frecuencia, pero son relojes físicamente diferentes yque no están relacionados (por ejemplo no conocemos la diferencia de faseque hay entre ellos). Por lo que forman distintos dominios de reloj.

Por lo tanto necesitamos un mecanismo para poder establecer una co-municación entre señales que pertenecen a diferentes dominios de reloj. Paraello utilizamos sincronizadores.

Para sincronizar señales de control utilizaremos registros en cascada ali-mentados con el reloj del dominio de clock al que viaja la señal. Los buses dedatos se sincronizan mediante FIFOs de doble puerto con dominios de relojindependientes en la interfaz de escritura y en la de lectura.

La sincronización de los datos de entrada la realizamos mediante una FI-FO de sincronización. Este tipo de FIFOs tiene un reloj independiente parala escritura de datos y otro para la lectura. En nuestro caso esta función ladesempeña �INPUT FIFO�, creada a partir de el IP Core de Xilinx �FIFOGenerator� que permite la sincronización de los datos.

La sincronización de los datos de salida se realiza utilizando otra FIFO


de sincronización similar a la que se utiliza en la entrada. Es la FIFO �OUT-PUT FIFO� que se encuentra en el bloque AER_2_SNAVA (ver sección4.2.3 para más detalles sobre este bloque). Esta FIFO es similar a �INPUTFIFO� y permite sincronizar los datos entre los dos dominios de reloj.

El bloque adicional �AER_2_SNAVA� (ver �gura 4.6) se presenta co-mo un extra junto con el sistema AER-RT. Su función es la de adaptar elsistema AER-RT para trabajar conjuntamente con el sistema SNAVA. Deesta manera las particularidades de la comunicación con SNAVA están con-tenidas en el componente AER_2_SNAVA y el bloque AER-RT conserva suuniversalidad para conectar con otros sistemas MP.

La sincronización de las señales de �Handshaking�, a saber: �eo_exec�(de entrada) y �eo_distrib� (de salida) la realizamos utilizando registros desincronización conectados en cascada, en concreto utilizamos 3 registros encascada para reducir al mínimo la probabilidad de que aparezca metaestabili-dad. Al sincronizar �eo_exec� los registros de sincronización utilizan el relojdel AER-RT; Y al sincronizar �eo_distrib� los registros de sincronizaciónutilizan el reloj del sistema multiprocesador. Los registros de sincronizaciónse encuentran en el bloque adicional AER_2_SNAVA.

4.2.2. Input FIFO. Sincronización de datos de entrada

Esta FIFO se encarga de la sincronización de los datos de entrada. Pa-ra ello utilizamos una FIFO de doble puerto con relojes independiente paralectura y escritura.

Al poner esta FIFO dentro del sistema AER-RT estamos forzando queuno de los puertos de entrada del sistema sea el reloj del bloque multiproce-sador, que se utilizará como reloj de escritura en la FIFO de entrada.

Podríamos haber puesto la FIFO de entrada en el bloque externo �AER_2_SNAVA�para evitar el puerto de entrada con el clock de escritura (reloj del sistemamultiprocesador). Pero hemos decidido incluirla en el bloque AER-RT yaque ésta está totalmente integrada con el bloque de transmisión, y ademásasí el envío de spikes es tan intuitivo como escribir en una FIFO.

La profundidad es de 1024 palabras y tiene 4 ciclos de sincronizaciónpor seguridad. Se ha utilizado el IP Core de Xilinx �FIFO Generator� paraimplementarla (ver opciones de con�guración del IP Core en la �gura 4.5).


Figura 4.5: Input FIFO Xilinx IP Core

4.2.3. AER_2_SNAVA. Sincronización datos de salida

Este bloque actúa de interfaz entre el sistema de red AER-RT desarro-llado y el sistema multiprocesador SNAVA. Se ha decidido poner este bloquefuera del sistema AER-RT para dotar a éste de mayor generalidad. Ademásen este bloque se realiza la sincronización de los datos recibidos entre los 2dominios de reloj que hay en el sistema global.

El bloque AER-RT tiene su propio dominio de reloj. Y el Sistema SNAVAel suyo. La frecuencia de los relojes es la misma, pero son señales físicamentediferentes por lo tanto no es posible conocer cual será la diferencia de faseentre ellas. En el esquema de la �gura 4.6 identi�camos el reloj del AER enrojo y el del sistema multiprocesador en azul.

Para sincronizar los datos entre los dos dominios de reloj se utiliza unaFIFO de sincronización, la �OUTPUT FIFO�, de manera similar a comohicimos con �INPUT FIFO�. OUTPUT FIFO es una FIFO de doble puertodonde hay una entrada de reloj diferente para escritura y para lectura.

Por lo tanto los datos que se reciben del interfaz AER-RT se escriben enla FIFO de salida, con el reloj del AER-RT. Necesitamos una máquina deestados que se encargue de leer estos datos y enviarlos al sistema multipro-cesador SNAVA, esta vez con el reloj del SNAVA. Podemos ver el diagramade estados de esta máquina de estados en la �gura 4.8. En este diagrama


Figura 4.6: Diagrama de bloques AER_2_SNAVA

Figura 4.7: Output FIFO Xilinx IP Core


Figura 4.8: Diagrama de estados máquina de estados de AER_2_SNAVA

se observa como, cuando se recibe la señal �eo_distrib� (que indica �nal defase de distribución, por lo que sabemos que se han escrito todos los datosrecibidos en la FIFO de salida), se procede a la lectura de la FIFO y lavalidación de los datos leídos para que sean capturados por el sistema MP.A continuación cuando la FIFO de salida comunica que está vacía mediantela señal �out_empty�, lo que implica que se han leído y enviado todos losdatos al sistema MP, se procede a generar la señal �ei_exec� que indicará aSNAVA el �nal del ciclo AER-RT. Por último se comprueba que �eo_exec�se haya puesto a nivel bajo y se vuelve al estado de reposo �IDLE_ST�.

Señalar que es muy importante incluir en el �chero de �constraints� deldiseño (en Xilinx se usa el �chero UCF), las restricciones de frecuencia delos dos dominios de reloj. Además hay que incluir en las restricciones que seanalice el retardo entre los dominios, con la instrucción �From: To�. Nosotrosno lo hicimos en un principio y tuvimos problemas de retardo en alguna de laslíneas de lectura de la FIFO de salida. En todo caso el problema de retardose puede solucionar añadiendo registros de pipeline en el camíno crítico (verregistros RP en �gura 4.6).

4.3. Aurora

4.3.1. Introducción

Aurora es un protocolo de comunicaciones creado por Xilinx. Permiteimplementar comunicaciones serie de alta velocidad de una forma sencilla.Utiliza los transceivers de alta velocidad incluidos en las siguientes FPGAsde Xilinx: Virtex-7, Kintex-7, Virtex-6 y Spartan-6. La forma de incluirloen un diseño es generar el Core mediante la herramienta �Core generator�.


Principales características:

Serialización diferencial formato NRZ

8b/10b: DC balance, mismo número de 1 que 0 (disparity), bit tran-sittion density (permite recuperar el clk en recepción)

Clock compensation: permite hasta ±100ppm de error entre Tx y Rx

wire speed: 1 - 12 Gbps

Payload: 0,8 - 10Gbps

SCRAMBLING: Distribuir datos de forma aleatoria pero de forma quese puedan recuperar

4.3.2. Generar Core

Al generar el Core se pueden con�gurar los siguientes parámetros [6]:

Aurora Lanes: Es el número de canales que tendrá el enlace. Se puedenelegir entre 1 y 16. Cada canal se implementa haciendo uso de untransceiver.

Lane with: #bytes de datos a transmitir. Se pueden elegir 2 ó 4.

Line rate: velocidad de transmisión de datos sin codi�car.

GT REFCLK: Frecuencia del Clock que utiliza el transceiver.

El Core tiene las siguientes características de funcionamiento:

Data�ow Mode: Duplex o Simplex, es decir bidireccional (Transmisióny Recepción) o unidireccional (Transmisión o Recepción). En nuestrocaso utilizaremos modo Duplex

Interface: Framming o Streaming. Framing interesa si utilizas el busAMBA. Streaming es tan sencillo como escribir o leer datos en o deuna memoria. Usamos streaming

Flow Control: Permite establecer prioridad y controlar el �ujo de datos,velocidad, tipo. Ejemplo que no se rebose el bu�er de recepción. Evitapérdidas.

Backchannel: 2 opciones: Sidebans o Timer. Permite comunicación en-tre Core simplex tx y Core simplex rx. Sidebans son 4 puertos en cadaCore simplex que unimos mediante cable con su simplex partner. Timeres un sistema que mediante temporizador supone que la inicializacióndel partner se ha realizado correctamente. Usamos sidebands


Frecuencia transmisión Tamaño palabra @ Frecuencia trabajo

2.500 Gbps 16 bits @ 125 MHz3.125 Gbps 16 bits @ 156 MHz4.000 Gbps 16 bits @ 200MHz6.250 Gbps 16 bits @ 312 MHz3.125 Gbps 32 bits @ 77 MHz6.250 Gbps 32 bits @ 145 MHz

Cuadro 4.1: Equivalencia entre frecuencia de transmisión (serie) y frecuenciade trabajo (paralelo)

4.3.3. Con�guración utilizada

La con�guración utilizada es la siguiente:

# Aurora lanes = 1

lane width = 2

lane rate = 2,5 Gbps -> User Clock =125 Mhz

GT ref clock = 125 MHz. Reloj de jitter bajo

Modo de �ujo: Duplex

Interfaz: Streaming

Sin Flow Control

Localización física del transceiver en Kintex-7: Utiliza el Quad X0Y8[9]

Dependiendo de la frecuencia a la que quieras trabajar en el sistema elegirásuna determinada frecuencia de transmisión. En nuestro caso hemos con�-gurado el Core a 2,5 Gbps ya que queremos trabajar a 125 MHz, que es lafrecuencia a la que trabaja el sistema SNAVA. En la tabla 4.1 se puedenapreciar distintas con�guraciones en función de la frecuencia de trabajo quese desee y del tamaño del bus de datos.

4.3.4. Sistema de compensación de clock

La compensación de clock es un mecanismo fundamental en comunica-ciones chip-to-chip dónde cada chip tiene su propio reloj. Este reloj es de lamisma frecuencia en todos los chips del sistema pero son físicamente distin-tos. Por lo tanto aunque a priori tengan la misma frecuencia siempre habráuna pequeña diferencia de frecuencia entre los diferentes relojes. Esta dife-rencia se compensa periódicamente en el sistema realizando una parada enla transmisión de datos y enviando secuencias de compensación de clock.


4.4. AER Tx

4.4.1. Conexión con otros bloques

El bloque AER TX, como se aprecia en la �gura 4.9, conecta con lossiguientes bloques:

Aurora. El interfaz consiste en habilitar datos para su transmisión siem-pre que la señal ready indique que el enlace Aurora está disponible

Input FIFO. De aquí se obtienen los datos provenientes del sistemamultiprocesador. Es decir, los spikes que se tienen que distribuir portodo el sistema. En la FIFO de entrada están los datos crudos, sinningún tipo de cabecera AER-RT. Es un interfaz de lectura de la FIFO

Bypass FIFO. Aquí se encuentran paquetes AER-RT, pueden ser dedatos o de control, que esperan a ser retransmitidos. Es un interfaz delectura de la FIFO

AER RX. De el bloque AER RX se obtienen las principales señalesinternas de control del protocolo AER-RT: AER_on y AER_done.AER_on indica que la fase de sincronización se ha completado conéxito y que por lo tanto se puede comenzar la distribución de spikes;AER_done indica que la fase de distribución de spikes ha �nalizado yque por lo tanto el ciclo AER-RT ha llegado a su �n

AER Con�g. De este bloque se obtienen los parámetros de con�gura-ción y las entradas de habilitación del modo Debug. Los principalesparámetros de con�guración en cada chip son: chip-id, Ring_size ydebug_mode

AER Error. Este bloque se encarga de comprobar que no se han per-dido datos durante la distribución de spikes. Comprueba que todos lospaquetes de datos que genera un determinado chip llegan de nuevo alchip a través del anillo. No se garantiza el contenido de los paquetesde datos

4.4.2. Diagrama de bloques

El funcionamiento del bloque AER TX consiste en la transmisión de lospaquetes AER-RT. Desde el punto de vista del bloque AER TX, cada cicloAER-RT se puede dividir en varias etapas:

1. IDLE. Etapa de reposo. Se envían paquetes de tipo IDLE constante-mente para mantener el enlace de comunicaciones.

2. SYNC. Fase de sincronización. Se envían varios paquetes de sincroni-zación. En la versión actual del sistema se envían 2 paquetes SYNC


Figura 4.9: Puertos AER_TX

3. BYPASS SYNC. Se hace el �bypass� de paquetes de sincronismo reci-bidos de otros chips

4. START. Se envía el paquete de START

5. DATA. Se envían paquetes de datos

6. FINISH. Se envían paquetes de FINISH

7. BYPASS DATA. Bypass de los paquetes de START, DATOS y FINISHde otros chips

8. Fin. Cuando se recibe el último paquete de FINISH

La transición entre estas diferentes fases, la dirige el bloque �Tx Controller�.Tx Controller habilita, según la fase de trabajo en que se encuentre, uno(nunca dos a la vez) de los diferentes bloques que podemos ver en la �gura4.10.

Esta aproximación modular de dividir el transmisor en varios submódu-los con una función muy concreta, permite mayor �exibilidad a la hora demodi�car el protocolo y mayor robustez a la hora de identi�car y depurarerrores. El enfoque consiste en establecer una serie líneas de �hand shake�entre el Tx controller y los diferentes bloques de transmisión. Estas líneaspermiten a �Tx Controller� habilitar cada módulo, y además permiten quecada módulo le comunique a �Tx Controller� si ha terminado su operación osi todavía la está ejecutando. Finalmente mediante un multiplexor se selec-ciona cual de los bloques transmisores se conecta con el puerto de salida de


Figura 4.10: Diagrama de bloque AER TX


Figura 4.11: Cronograma AER TX

datos que ataca el IP Core Aurora.

En el cronograma de la �gura 4.11 se puede apreciar como se habilitanlos diferentes bloques de transmisión. Y como a la salida se multiplexa encada caso la salida del bloque que interesa. Además podemos observar laproporción de tiempo que se emplea en cada etapa de transmisión. En estecaso se está simulando un anillo con dos nodos, y la transmisión de un únicopaquete de datos.

4.4.3. Tx Controller

Este bloque es el cerebro del transmisor, se encarga de dirigir su funciona-miento habilitando los diferentes bloques transmisores que hay en el sistema.En función de una serie de señales de control decide que bloque toca activaren cada momento y durante cuanto tiempo.

En la �gura 4.12 se puede observar la máquina de estados del bloqueTx Controller. Como se aprecia cada etapa de la transmisión se identi�cafácilmente:

TX_IDLE. Estado de reposo. Se envían paquetes de tipo IDLE

TX_SYNC. Envío paquete de sincronización


Figura 4.12: Diagrama de estados Tx Controller

TX_BP_1. Bypass de paquetes de sincronización

TX_START. Envío de paquete START

TX_DATA. Envío de paquetes de datos, previa lectura de �INPUTFIFO�

TX_FINISH. Envío paquete de FINISH

TX_BP_2. Bypass paquetes de datos de otros chips

TX_BP_XT. Estado extra de bypass, necesario por si queda algúnpaquete en la �FIFO bypass� cuando se recibe la señal �AER_done�

TX_IDLE_2. Estado de reposo. Es necesario esperar que �eo_exec�baje a cero antes de ir al estado �TX_IDLE�. Se envían paquetes detipo IDLE

Cabe destacar que llegar a este diseño de el controlador no fue inmediato. Laprimera aproximación (en una etapa muy temprana) fue implementar todoel protocolo en una sola máquina de estados, tal como se aprecia en la �gura4.13. Pero enseguida fue evidente que su complejidad no era manejable y seoptó por la solución modular que hemos visto. Utilizando un enfoque mo-dular la máquina de estados del Tx controller es bastante intuitiva y por lo


Figura 4.13: Primera versión Maquina de estados de Tx Controller (total-mente descartada)

tanto fácil de depurar y de ampliar si fuera necesario.

De hecho durante el diseño de el sistema hemos tenido que efectuar algúncambio o ampliación del protocolo. Haber seguido este enfoque modular des-de primeras etapas en el diseño ha posibilitado la facilidad y rapidez con queestas modi�caciones han sido incluidas. Por ejemplo en un primer momentoel protocolo no utilizaba paquetes de START ni de IDLE. Con un enfoqueno modular la inclusión de este tipo de paquetes en el protocolo supone elrediseño de toda la máquina de estados. Con un enfoque modular el cambioconsiste en crear un bloque que se encargué de enviar este tipo de paquetesy hacer pequeños cambios en la máquina de estados de Tx Controller.

Por último señalar que es muy útil para la depuración del sistema, alprobarlo en la placa, tener una salida con el estado de la máquina de estadosde Tx Controller. De esta forma podemos saber en que fase de transmisión seencuentra el sistema en cualquier momento, ayudando así a depurar errores.

4.4.4. Tx Sync

El bloque Tx Sync se encarga de enviar un paquete de sincronismo y degenerar un �acknowledge� para el bloque Tx Controller cuando este paquetese ha enviado con éxito. La señal de �acknowledge� es necesaria porque puedesuceder que en el momento que Tx controller habilite el bloque sync el en-lace Aurora no esté listo (se encuentre en fase de compensación de reloj porejemplo). De esta manera Tx controller espera hasta que Tx Sync le contesteque el paquete se ha enviado con éxito.


Figura 4.14: Diagrama de estados Tx Sync

Como se aprecia en el diagrama de estados de la �gura 4.14, el envío delpaquete de sincronismo se produce cuando se recibe la señal de habilitacióny además el canal de transmisión está listo (señal �ready_tx�). Después delenvío se genera la señal �sy_done� para comunicarle a Tx Controller que seha realizado la transmisión.

4.4.5. Tx Bypass

Este bloque se encarga de:

1. Leer paquetes AER-RT de la FIFO Bypass

2. Transmitir los paquetes leídos

3. Detener la transmisión si se está realizando la compensación de clocken el enlace Aurora

4. Reanudar la transmisión cuando la compensación de clock ha sido com-pletada

Este bloque es el que implementa la estructura pipeline del anillo por lotanto interesa que los datos se lean y se envíen en ráfaga (Burst). Esto seconsigue realizando una primera lectura de la FIFO bypass, y a continuaciónleyendo y enviando a la vez. Estados �BP_READ� y �BP_READ_WRITE�en el diagrama de estados de la �gura 4.15. Si nos �jamos en este diagramaveremos el estado �BP_PAUSE�. A este estado viaja el bloque Tx Bypasscuando se habilita la señal que indica que hay una compensación de clock enel enlace Aurora.


Figura 4.15: Diagrama de estados Tx Bypass

Cuando se activa la compensación de clock, la señal �RDY� se pone acero para indicar que no se pueden transmitir datos a partir de ese momentohasta que se vuelva a poner a uno.

4.4.6. Tx Start

De manera similar a Tx Sync el envío de paquetes de control de tipoStart se realiza siguiendo un mecanismo de Handshaking con Tx Controller.Diagrama de estados en �gura 4.16.

4.4.7. Tx Data

De manera similar a Tx Bypass, Tx Data se encarga de leer los datos deInput FIFO y de enviarlos hacia el bus AER-RT. Hay 2 diferencias funda-mentales con Tx Bypass.

1. Lo que se lee de la FIFO son datos crudos no paquetes AER-RT. Porlo tanto a los datos leídos hay que añadirle la cabecera AER-RT antesde enviarlos a través del anillo.


Figura 4.16: Diagrama de estados Tx Start

2. Sabemos según el protocolo establecido en la comunicación con el siste-ma multiprocesador, que al comenzar la fase de distribución de spikestodos los datos ha transmitir ya han sido escritos en la FIFO de entra-da. Por lo tanto al terminar de leer la FIFO de entrada y de transmitirlos paquetes de datos sabemos que no pueden haber nuevos datos en�Input FIFO� hasta un nuevo ciclo AER-RT.

Diagrama de estados en �gura 4.17.

4.4.8. Tx Finish

Idem a Tx Start y Tx Sync. Diagrama de estados en �gura 4.18.

4.4.9. Tx Idle

Idem a Tx Start, Tx Sync y Tx Finish, con la única diferencia que lapérdida de alguno de los paquetes IDLE no es crítica. Por lo tanto no esnecesario realizar handshake con Tx controller para asegurar que no se pierdeninguno de los paquetes IDLE generados por el bloque Tx Idle

4.4.10. Modo �Debug�

Para facilitar la depuración del sistema se incluye en AER TX la posibi-lidad de habilitar los diferentes bloques de transmisión desde fuera del chip.Esto se consigue habilitando el modo �Debug� mediante un pulsador externo.Una vez el sistema está en modo �Debug�, podremos seleccionar mediantetres interruptores cual de los bloques de transmisión queremos activar. En latabla 4.2 tenemos los códigos necesarios para activar cada uno de los bloques


Figura 4.17: Diagrama de estados Tx Data

Figura 4.18: Diagrama de estados Tx Finish


Switch Modo

000 F_gen/F_check001 Bypass010 Sync011 START100 Data101 Finish110 Idle

Cuadro 4.2: Diferentes códigos para el modo Debug

de transmisión.

El modo Debug ha facilitado la depuración Hardware del sistema permi-tiendo identi�car qué tipos de paquetes o que fase de funcionamiento es laque produce algún error. Es una forma de aislar errores muy e�caz en unsistema tan complejo.

El código �000� del modo Debug es una con�guración extra que sólo seutiliza para depuración. Permite que en el chip seleccionado se generen da-tos pseudo-aleatorios. En AER RX a su vez hay un bloque, que igualmentesólo se usa en depuración, que comprueba si se ha perdido alguno de losdatos pseudo-aleatorios. De esta forma podemos comprobar la calidad delenlace. Por ejemplo una con�guración muy útil es poner uno de los chipsen Modo �000� y los demás en modo Bypass. De esta forma podemos com-probar la calidad del anillo monitorizando si se pierde algún paquete. Dehecho hay múltiples posibilidades de depuración combinando anillos con di-ferente número de nodos y con diferentes códigos de depuración en cada uno.

Este modo de funcionamiento se añadió bastante pronto en el diseño alcomprobar empíricamente que en el enlace se producían errores. Eran erroresde tipo Software. Estos errores indican pérdida de alineamiento, paridad, etc.y es difícil de identi�car la causa que los produce ya que en simulación noaparecen.

4.5. AER Rx

4.5.1. Conexión con otros bloques

El bloque AER RX conecta con los siguientes bloques:

Aurora. Recibe datos provenientes del enlace Aurora

Bypass FIFO. Interfaz de escritura. AER RX escribe en �bypass FIFO�

Figura 4.19: Puertos AER_RX

los datos que necesitan ser retransmitidos

AER TX. En AER RX se generan las señales AER_ON y AER_doneque se envían hacia AER_TX

AER Con�g. De este bloque se obtienen los parámetros de con�gura-ción y las entradas de habilitación del modo Debug. Los principalesparámetros de con�guración en cada chip son: chip-id, Ring_size yModo_debug

AER Error. Este bloque se encarga de comprobar que no se han per-dido datos durante la distribución de spikes. Comprueba que todos lospaquetes de datos que genera un determinado chip llegan de nuevo alchip a través del anillo. No se garantiza el contenido de los paquetesde datos

Contadores de paquetes AER-RT. Es muy útil tener la posibilidad demonitorizar los tipos de paquetes que llegan al receptor. La maneramás e�ciente de realizar esta monitorización es mediante contadoresde paquetes.

4.5.2. Diagrama de bloques

El bloque AER RX se encarga de:

1. Detectar cuando �naliza la fase de sincronización y empieza la fase dedistribución de spikes. Lo hace contabilizando paquetes de sincroniza-ción y lo indica activando la señal interna de control AER_on

53

Figura 4.20: Diagrama de bloque AER RX

54


2. Guardar el chip-id de cada ráfaga de datos que recibe. Lo hace guar-dando el chip-id de los paquetes de control START

3. Detectar el �nal de la fase de distribución. Lo hace detectando el últimopaquete de control de FINISH, y lo indica activando la señal internade control AER_done

4. Contabilizar e identi�car los paquetes que se reciben. Lo hace medianteel uso de contadores

5. Filtrar los paquetes que se tienen que retransmitir. Lo hace medianteel bloque �Filtro Bypass�

6. Filtrar y desencapsular los paquetes de datos que se envían al sistemamultiprocesador. Lo hace mediante el bloque �Filtro AER RX�

Para realizar todas estas funciones nos valemos de señales de detección de di-ferentes tipos de paquetes. Es decir, tenemos una señal �valid� que nos indicaque se ha recibido un paquete; Y además tenemos las señales de detección detipo de paquete, que se activarán según el tipo de paquete recibido, Y señalesde detección de paquete propio que se activarán si recibimos un paquete connuestro chip-id.

Utilizando estas señales de detección construimos una serie de bloquesque realizarán las funciones antes descritas:

1. Bloque generador de AER_on

2. Chip-id extractor

3. Bloque generador de AER_done

4. Contadores

5. Filtro Bypass

6. Filtro AER RX

En el cronograma de la �gura 4.21 podemos ver un ciclo AER-RT para unared con 2 nodos y la transmisión de un spike por parte de cada nodo. Eneste cronograma los puntos 1 y 2 (en rojo) señalan el inicio y el �nal de lafase de distribución respectivamente.

1. se genera AER_on al recibir los paquetes de sincronismo. En este casose reciben 4 paquetes de sincronismo, dos por cada chip

2. se genera AER_done al detectar el último paquete de �nish

También se puede observar como se detectan los paquetes de start, �nish ydata de cada chip. Y como los datos del propio chip se distinguen activandola señal �own_data_detected�.


Figura 4.21: Cronograma AER RX

4.5.3. Detector de paquetes

Según la cabecera que contenga el paquete recibido activaremos la señalde tipo de paquete recibido que corresponda.

Tenemos las siguientes señales que indican que el paquete recibido es deun tipo o otro:

detect_sync. Indica que se ha recibido un paquete de sincronismo. Seutiliza en la generación de AER_on

detect_start. Indica que se ha recibido un paquete de start. Se utilizapara detectar paquetes de datos propios. En concreto para guardar elchip-id asociado a una determinada ráfaga de datos

detect_data. Indica que el paquete recibido es de datos. Se utiliza enel �ltro de salida. También se utiliza para detectar datos propios.

detect_�nish. Indica que se ha recibido un paquete de �nish. Se utilizaen la generación de AER_done

detect_own_ctrl. Indica que el paquete de control recibido es propio.Se utiliza en el Filtro Bypass y para detectar paquetes de datos propios

detect_own_data. Indica que el paquete de datos recibido es propio.Se utiliza en el Filtro Bypass

En el caso de detectar si el paquete de datos recibido es propio (señal �de-tect_own_data�), es decir ha sido generado por el propio chip que lo estárecibiendo, utilizamos una máquina de estados (ver �gura 4.22). En el mo-mento de recibir un paquete de tipo START, y además el campo chip-id deese paquete corresponde con el chip-id del chip receptor, sabemos que losdatos que recibiremos a continuación serán datos propios.


Figura 4.22: Diagrama de estados detector de paquetes de datos propios

4.5.4. Contadores de paquetes

Tenemos contadores para llevar un inventario de los diferentes tipos depaquetes que se recibe en el receptor.

Contador de paquetes de sincronismo (cont_sync). Se utiliza en lageneración de la señal de comienzo de distribución de spikes �AER_on�

Contador de paquetes de start (cont_start).

Contador de paquetes de datos (cont_data).

Contador de paquetes de �nish (cont_�nish). Se utiliza en la genera-ción de la señal de �nal de protocolo �AER_done�

Contador de paquetes de control propios (cont_own_ctrl).

Contador de paquetes de datos propios (cont_own_data). Se utilizaen el control de errores, al comparar este contador con el contador depaquetes transmitidos, que se encuentra en AER_TX

4.5.5. Generación AER ON

Lógica encargada de detectar y señalizar mediante la señal �AER_on�que la fase de sincronización se ha completado. Por lo tanto la distribuciónde spikes en AER_TX comienza cuando recibe AER_on a nivel alto. Comopodemos apreciar en el diagrama de estados de la �gura 4.23, AER_on


Figura 4.23: Diagrama de estados generación de AER ON

se activa cuando se recibe un paquete de sincronismo y además el númerode paquetes de sincronismo recibidos es mayor que el número de nodos enla red menos 1. Como en el diseño �nal cada chip envía dos paquetes desincronismo comparamos que el contador sea mayor que 2*N -1. Para queel contador esté actualizado en el momento de la comprobación, la señal dedetección de SYNC se retrasa 2 ciclos de reloj mediante registros.

4.5.6. Generación AER Done

Bloque encargado de generar la señal de �nal de protocolo AER_done.AER done se genera cuando se detecta un paquete de tipo �nish y además elcontador de paquetes �nish es mayor que el tamaño del anillo (Ring_SIZE)menos uno. Para que el contador esté actualizado en el momento de la com-probación, la señal de detección de FINISH se retrasa 2 ciclos de reloj me-diante registros.

4.5.7. Filtro Bypass (o escritura en FIFO de todos los pa-quetes a retransmitir)

Este bloque se encarga de escribir en la FIFO �Bypass FIFO� los pa-quetes, tanto de datos como de control, que hay que retransmitir. Hay quediferenciar qué paquetes hay que retransmitir y qué paquetes mueren en estepunto. De ésto se encarga el �ltro. Por norma general todos los paquetespropios, tanto de datos como de control mueren en este punto y por lo tantono se retransmiten. La excepción son los paquetes de tipo IDLE que nunca


se retransmiten, sean propios o no.

Por lo tanto este bloque escribe los paquetes recibidos en la FIFO debypass, siempre que no sean paquetes de tipo �own_data�, �own_ctrl� o�idle�.

4.5.8. Interfaz de salida AER_RX (o desencapsulación delos paquetes de datos)

Este bloque se encarga de generar la salida que conectará con el sistemamultiprocesador. Por lo tanto debemos enviar cada spike de datos con sucorrespondiente chip-id. Pasos:

1. Guardar chip-id correspondiente a cada ráfaga de datos recibida

2. Desencapsular los datos

3. Generar las señales de datos y habilitación que viajan hacia el sistemamultiprocesador

Para obtener el chip-id de cada ráfaga de datos utilizamos el bloque �chip-id_extractor�. Este bloque se encarga de actualizar el registro que contieneel chip-id cada vez que se recibe un paquete de tipo start.

Pra validar los datos recibidos ponemos en el bus de datos de salida losdatos y el chip-id y activamos la señal de validación del interfaz AER derecepción. El bus de datos de recepción es un bus de 18 bits (11 bits dedatos + 7 bits de chip-id)

4.6. Bypass FIFO

Este bloque se encarga de almacenar los datos que se han de retransmi-tir. AER RX escribe los paquetes recibidos que se han de retransmitir ensu puerto de escritura. AER_TX, por su parte, se encarga de su lectura.La inclusión de esta FIFO es fundamental porque no siempre que AER RXpone un paquete para retransmitir, AER-TX está listo para hacerlo. Por lotanto tiene que existir la posibilidad de que los datos se mantengan duranteun cierto tiempo en la FIFO.

La elección del tamaño de la FIFO es muy importante. No debemosexcedernos en su tamaño ya que desperdiciaríamos recursos, pero tampocoquedarnos cortos ya que podríamos perder datos si la FIFO se llena (over-�ow). Por lo tanto hay que llegar a un compromiso entre área y seguridadde no perder datos. Elegimos una profundidad de 1024 palabras.


Figura 4.24: Bypass FIFO Xilinx IP Core

Utilizamos el IP Core de Xilinx �FIFO Generator� para implementar laFIFO �Bypass FIFO� (en la �gura 4.24 se puede ver la con�guración del IPCore).

4.7. AER Con�g

Bloque dónde se con�guran los diferentes parámetros del sistema:

1. chip-id.

2. Ring_size

3. Modo Debug

4. Código Debug

Los diferentes parámetros del sistema se pueden con�gurar externamente.Mediante el interfaz ethernet que utiliza SNAVA podemos con�gurar losdiferentes parámetros de con�guración desde una aplicación en el PC. Elprocedimiento consiste en mapear en la memoria de el interfaz ethernet losregistros de con�guración.

Alternativamente a la hora de depurar el funcionamiento del sistemaAER_RT podemos con�gurar los diferentes valores de con�guración me-diante interruptores externos. Ahorrándonos así la necesidad de incluir el


interfaz Ethernet en el diseño en la etapa de depuración.

Tener el bloque que se encarga de guardar los registros de con�guraciónaislado del sistema principal, permite �exibilidad en cuanto al método que seutilizará para actualizar estos registros. De esta forma la decisión de cómo secon�guren los registros no inter�ere en el funcionamiento del sistema global.

Además para facilitar la simulación, en el código VHDL del diseño seha puesto la variable genérica �ONLY_SIM�, que en caso de valer '1' indicaque los parámetros de con�guración se obtienen directamente por Software.De esta manera se simpli�ca la escritura de registros de con�guración ensimulación, permitiendo ahorrar tiempo y centrar esfuerzos en depurar elfuncionamiento del protocolo.

4.8. AER Error

Este bloque se encarga de comprobar si se ha perdido algún paquete dedatos en la fase de distribución. Para ello nos valemos de una de las caracte-rísticas del sistema AER-RT: Todos los datos generados por un determinadochip viajan por el anillo hasta que regresan a ese mismo chip. En el momentode regresar es cuando mueren y no continúan desplazándose por el anillo enuna nueva vuelta.

Esta característica permite que cada chip pueda comprobar si alguno delos paquetes que él genero se ha perdido durante su transmisión a través delanillo. Si uno de los chips detecta pérdida de paquetes se lo indicará al siste-ma multiprocesador mediante un pulso en el puerto de salida �AER_error�.Además hay un contador de salida de 8 bits que va contabilizando los pa-quetes perdidos en cada ciclo.

El mecanismo para detectar una pérdida de paquete es muy sencillo. EnTransmisión (AER TX) tenemos un contador que contabiliza todos los pa-quetes de datos generados por ese determinado chip. A su vez, en recepción(AER_RX) tenemos un contador de paquetes de datos propios recibidos. Al�nalizar un ciclo AER-RT se comparan estos dos contadores si su valor esdiferente se genera un pulso en la señal �AER_error�, y además se reseteanlos dos contadores.

Este sistema permite saber si se ha perdido algún paquete, pero no ase-gura la integridad de los datos contenidos en cada paquete. La integridad delos datos se podría controlar añadiendo el checksum de los paquetes de datosen transmisión y comprobándolo en recepción.


Capítulo 5

Resultados

5.1. Simulación con retardos (o Timing Simulation)

Para realizar la simulación con retardos del diseño se utiliza el �chero conextensión �.sdf�. Este �chero se obtiene al realizar el �Place and route� con lasherramientas de síntesis de Xilinx. En este �chero se indica la posición física�nal que ocupará la lógica en la FPGA. Por lo tanto incluye información so-bre retardos que es muy útil a la hora de realizar una simulación más realista

Para mantener la jerarquía del diseño al realizar una simulación con retar-dos es imprescindible incluir el atributo �keep hierarchy� en el código VHDLde cada modulo VHDL que se quiera veri�car en simulación. De esta formalas señales resultantes para simulación mantienen una jerarquía, lo que faci-lita la localización de las señales a depurar. En caso contrario en un diseñogrande es sumamente engorroso manejar todas la señales sin estructura je-rárquica.

5.2. Medidas de latencia para diferente número denodos y diferente número de spikes

En este apartado se obtiene la latencia de nuestro sistema. La latenciaequivale al tiempo que emplea el protocolo AER-RT en realizar la fase dedistribución de spikes. La latencia se divide en 1) Fase de sincronización y2) Fase de distribución. Para obtener la latencia del sistema se han realizadomúltiples medidas.

5.2.1. Medidas anillo un nodo

En primer lugar realizamos medidas de latencia en un anillo con un sólonodo. El número de spikes que genera el sistema MP lo variamos de 0 hasta

63


Spikes/chip Fase Sinc. (en ciclos de reloj) Fase Distr. (en ciclos de reloj)

0 43 451 43 495 43 5310 43 58

Cuadro 5.1: Medidas anillo con un nodo

Figura 5.1: Latencia en anillo de un nodo transmitiendo un único spike

10 spikes. El resultado de estas medidas lo tenemos en la tabla 5.1. Hemosnormalizado las medidas para mostrarlas en función de ciclos de reloj y no detiempo absoluto. Las medidas absolutas dependen de la frecuencia de relojque se utilice en el sistema AER-RT y, como sabemos, ésta es con�gurable.Las medidas se obtienen a partir de la simulación del sistema, en la �gura5.1 y 5.2 podemos apreciar el cronograma de un ciclo AER-RT al transmitiruno y 10 spikes respectivamente.

A partir de estas medidas generalizamos la latencia para un anillo de unnodo mediante las ecuaciones 5.1 y 5.2. Donde �s� es el número de spikes quese transmiten en cada nodo o chip.

Tn=1 [ciclos] [s = 0] = 43 + 45 (5.1)

Tn=1 [ciclos] [s > 0] = 43 + 49 + (s− 1) (5.2)


Figura 5.2: Latencia en anillo de un nodo transmitiendo 10 spikes


0 83 841 83 885 83 9210 83 97

Cuadro 5.2: Medidas anillo con dos nodos

5.2.2. Medidas anillo dos nodos

De manera análoga a la red con un nodo realizamos medidas en una redcon dos nodos, donde el número de spikes que transmite cada nodo o chippuede variar. En la tabla 5.2 tenemos medidas de latencia normalizada paradiferente número de spikes por nodo. En las �guras 5.3 y 5.4 tenemos eldetalle de las medidas cuando se realiza transmisión de 1 y 10 spikes en cadachip respectivamente.

A partir de estas medidas obtenemos la expresión de la latencia en unanillo de dos nodos (ecuación 5.3 y 5.4). Donde �s� es el número de spikestransmitidas por nodo.

Tn=2 [ciclos] [s = 0] = 83 + 84 (5.3)

Tn=2 [ciclos] [s > 0] = 83 + 88 + (s− 1) (5.4)


Figura 5.3: Latencia en anillo con dos nodos y transmitiendo un único spike

Figura 5.4: Latencia en anillo con dos nodos y transmitiendo 10 spikes



0 120 1211 120 1255 120 12910 120 134

Cuadro 5.3: Medidas anillo con dos nodos

Figura 5.5: Latencia en anillo de tres nodos y transmitiendo 1 spike

5.2.3. Medidas anillo 3 nodos

El resultado de las medidas para un anillo con tres nodos lo encontramosen la tabla 5.3. Y el detalle de las medidas para transmisión de 1 y 10 spikespor nodo lo encontramos en las �guras 5.5 y 5.6.

A partir de estas medidas obtenemos en la latencia en un anillo de 3nodos (ecuaciones 5.5 y 5.6). Donde �s� es el número de spikes.

Tn=3 [ciclos] [s = 0] = 120 + 121 (5.5)

Tn=3 [ciclos] [s > 0] = 120 + 125 + (s− 1) (5.6)

5.3. Latencia del sistema AER-RT

A partir de las medidas anteriores obtenemos la ecuación que de�ne lalatencia para un sistema AER-RT con N nodos o chips. La expresión que


Figura 5.6: Latencia en anillo con tres nodos y transmitiendo 10 spikes

de�ne esta latencia con unidades normalizadas a ciclos de reloj la encontra-mos en la ecuación 5.10. Donde �s� es el número de spikes transmitidas pornodo, y �N� es el número de nodos en el sistema. La expresión es aproxima-da (símbolo ∼=) porque el resultado puede variar algún ciclo arriba o abajo.Ésto es debido a 2 motivos. 1) si s=0 la expresión cambia ligeramente comohemos visto; y 2) La latencia puede variar algunos ciclos en cada nueva faseAER-RT debido a el efecto de la compensación de reloj que se produce enel enlace Aurora.

TAER−RT [ciclos] = TSY NC + TDISTRIB (5.7)

TSY NC [ciclos] ∼= 40 ∗N (5.8)

TDISTRIB [ciclos] ∼= 40 ∗N + (s− 1) (5.9)

TAER−RT [ciclos] ∼= 40 ∗N + 40 ∗N + (s− 1) (5.10)

Podemos observar que la latencia es directamente proporcional al númerode nodos del sistema, por lo que se demuestra que el sistema es totalmenteescalable: La pérdida de prestaciones al aumentar el número de chips delsistema es lineal.


5.4. Área utilizada

A continuación se presenta un resumen de la utilización de recursos lógi-cos al implementar el sistema AER-RT en una FPGA Kintex-7 de Xilinx

Device Utilization Summary:

Slice Logic Utilization:

Number of Slice Registers: 735 out of 407,600 1%

Number used as Flip Flops: 735

Number used as Latches: 0

Number used as Latch-thrus: 0

Number used as AND/OR logics: 0

Number of Slice LUTs: 612 out of 203,800 1%

Number used as logic: 507 out of 203,800 1%

Number using O6 output only: 250


Number using O5 and O6: 189

Number used as ROM: 0

Number used as Memory: 54 out of 64,000 1%

Number used as Dual Port RAM: 0

Number used as Single Port RAM: 0

Number used as Shift Register: 54



Number using O5 and O6: 8

Number used exclusively as route-thrus: 51

Number with same-slice register load: 46

Number with same-slice carry load: 5

Number with other load: 0

La utilización de recursos es muy baja lo que con�rma la viabilidad deimplementar el interfaz de red AER-RT junto con el sistema multiprocesador.Además el hecho de ocupar un mínimo de lógica permite más espacio paramapear más neuronas en el sistema MP.

5.5. Máxima frecuencia

A continuación se presenta un informe sobre la máxima frecuencia de tra-bajo que admite el sistema AER-RT. Este informe lo genera la herramientade síntesis y rutado de Xilinx que se utiliza para implementar el diseño. Yse basa en información de retardos en los caminos más críticos del sistema.

Timing Summary: ---------------

Speed Grade: -2


Figura 5.7: Estimación de consumo AER-RT

Minimum period: 2.704ns (Maximum Frequency: 369.790MHz)

Minimum input arrival time before clock: 0.344ns

Maximum output required time after clock: 1.023ns

Maximum combinational path delay: 0.000ns

Se puede concluir a partir de estos resultados que el sistema permitetrabajar a altas frecuencias (hasta 369 MHz). En la versión de AER-RTprobada con SNAVA se trabaja a frecuencias de 125 MHz ya que es la máximafrecuencia a la que trabaja SNAVA. Si en un futuro SNAVA optimiza suarquitectura para trabajar a frecuencias más elevadas el interfaz de red AER-RT podrá adaptarse y trabajar a esa nueva frecuencia de trabajo.

5.6. Consumo

En la �gura 5.7 se muestra el consumo de potencia medio del interfazde red AER-RT. Vemos que el consumo total es de 524 mW. Destacar queprácticamente un 50% (247 mW) del consumo se produce en el transceiver(GTXE2).

Capítulo 6

Sistema completo AER-RT +emulador de SNAVA

Para acabar de veri�car el funcionamiento del interfaz de red AER-RT seconstruye una red SNN con tres chips. El sistema MP que se utiliza para estaprueba es un bloque que emula el comportamiento de SNAVA. Para teneruna veri�cación realista el emulador de SNAVA este bloque trabaja con unreloj físicamente diferente al que utiliza AER-RT, de esta manera tenemosdos dominios de reloj.

En las �guras 6.1 y 6.2 se presentan dos fotos del sistema físico con elque se han realizado las pruebas. Cada una de las placas de evaluación quese ve en las fotos es uno de los nodos del sistema AER-RT. En este casotenemos tres chips o nodos. El chip superior tiene el chip-id 0, el del medioel chip-id 1 y el inferior el chip-id 2. El esquema de conexión es similar alque se presentó en la �gura 3.2 de la sección 3. Los puertos de transmisión yrecepción son diferenciales, de esta forma se consigue una señal más robustay resistente a interferencias.

En la �gura 6.3 tenemos una instantánea del analizador lógico virtualde Xilinx conectado al chip con chip-id 0. En ella vemos la evolución de lasdiferentes señales internas del sistema AER-RT. De todas ellas nos �jaremosen las que están resaltadas en rojo. A continuación describimos la funciónde estas señales en términos generales:

AER_tx_wr_i es la señal de habilitación de escritura del interfaz AERTX. Indica escritura de spike en FIFO de entrada para su posteriortransmisión

AER_tx_data_i es el bus de datos del interfaz AER TX

AER_eo_exec es la señal de Handshaking que indica �n de la fase deejecución

71


Figura 6.1: Sistema AER-RT + emulador de SNAVA implementado en tresKintex-7


Figura 6.2: Detalle conexiones en sistema AER-RT + emulador de SNAVAimplementado en tres Kintex-7


aer_on_i es una señal interna del sistema AER-RT que indica �n dela fase de distribución e inicio de la fase de distribución

aer_done_cs es una señal interna del sistema AER-RT que indica �nde la fase de distribución y �n de un ciclo AER-RT

aer_rx_valid_i es la señal de validación del interfaz AER RX. Indicadato válido en el bus de recepción

aer_rx_data_1 son los bits de más peso del bus de recepción. En elviaja el chip-id

aer_rx_data_2 son los bits de menos peso del bus de recepción. Enel viajan los spikes

Para facilitar la comprensión hemos numerado (en rojo) los diferentes acon-tecimientos que se pueden observar en la captura de pantalla de la �gura6.3:

1. El emulador de SNAVA escribe en la FIFO de entrada los spikes adistribuir, en este caso son 7 spikes

2. El emulador de SNAVA, una vez escritos los spikes, activa la señal deAER_eo_exec. En este punto comienza un ciclo AER-RT que comosabemos consta de fase de sincronización y fase de distribución

3. Se activa la señal interna AER_on, lo que indica que la fase de sincro-nización se ha completado. Empieza por tanto la fase de distribución

4. Durante la fase de distribución el chip 0 va recibiendo los spikes quehan generado todos los chips que forman el anillo, incluido él mismo.Vemos un tren de tres pulsos, estos pulsos habilitan los spikes recibidosde cada chip. En primer lugar nos llegan los 7 spikes del chip 1, acontinuación los 7 spikes del chip 2 y �nalmente los 7 spikes generadospor el chip 0 (es decir nosotros mismos)

5. Finalmente cuando se reciben todos los paquetes FINISH de todoslos chips se activa la señal interna AER_done que indica que el cicloAER-RT ha �nalizado


Figura 6.3: Detalle de señales en el chip 0 tomadas con el analizador lógicovirtual de Xilinx


Capítulo 7

Conclusiones

A nivel personal ha sido un proyecto largo y complicado pero muy in-teresante. Me ha permitido trabajar con señales serie de alta velocidad enFPGA, que es un tema que está bastante de actualidad en la industria. Anivel de diseño digital me ha permitido adquirir soltura a la hora programaren VHDL. Además de profundizar en el manejo de herramientas avanzadaspara la simulación y síntesis de circuitos digitales.

Una de las lecciones importantes a nivel de diseño, y que menciono enel capítulo de arquitectura, es la importancia de crear un diseño modulardesde primeras etapas en el diseño. Este enfoque facilita la modi�cación ydepuración del sistema enormemente.

A nivel más práctico de resultados el objetivo que nos propusimos alprincipio del proyecto se ha conseguido. Hemos creado un interfaz de redmulti-chip e�ciente y escalable.

Tan e�ciente que el cuello de botella que introducía el interfaz de redprevio ha desaparecido, ahora el interfaz de red puede trabajar a frecuenciasiguales o incluso superiores que el sistema MP.

El interfaz diseñado permite que el sistema crezca en número de chips demanera fácil. Tan fácil como con�gurar dos parámetros en cada chip: �chip-id� y �Ring_size� que indican la identi�cación de cada nodo en el anillo y eltamaño del anillo respectivamente. El sistema ha sido probado en un anillode hasta 4 chips con éxito.

A continuación, como medida del nivel de escalabilidad que puede alcan-zar el interfaz AER-RT, me gustaría demostrar la viabílidad de un sistemade hasta 4 millones de neuronas. El hecho de tener hasta 15 bits disponiblesen los paquetes de datos nos permite una escalabilidad en número de neuro-

77


nas por chip de hasta 32768. Con 7 bits para el chip-id podemos direccionarhasta 128 chips dentro del mismo sistema. Si hacemos cuentas esto suponela capacidad de implementar un sistema de hasta 4194304 neuronas.

Calculamos la latencia de esta teórica red SNN con 4 Millones de neu-ronas y comprobamos que el requisito de no superar un tiempo de 0,5 msse cumple ampliamente. La latencia es de 75,77 us, tan solo un 15% de lamáxima latencia permitida. En la ecuación 7.1 se muestran las operacionesrealizadas. Como hacíamos en el capítulo de diseño suponemos que la fre-cuencia de generación de spikes es de 15 spikes cada 100 neuronas. Por lotanto si cada chip tiene 32768 neuronas ésto hace un valor de 4915 spikes ge-nerados en cada chip (s en la ecuación). N hemos dicho que es 128 chips y lafrecuencia la ponemos a 200 MHz que es una frecuencia razonable de trabajo.

T = [40 ∗N + 40 ∗N + (s− 1)] ∗ 1

f= 75, 77us (7.1)

s [spikes/chip] = 4915

f = 200MHz

N [chips] = 128

El otro objetivo que era ser adoptado por SNAVA como nuevo interfazde red también se ha cumplido. El sistema se ha probado en un sistema de2x2 neuronas en cada chip formando un anillo de hasta 4 chips con éxito.

Como línea de trabajo futuro hay 2 mejoras que se podrían realizar en elinterfaz AER-RT de manera no muy complicada y que se mencionan en estedocumento.

1. Dotar a el interfaz de red AER-RT de jerarquía. Una primera apro-ximación consistiría en diferenciar entre transmisión de spikes localesy transmisión de spikes globales. Por lo tanto estableceríamos una redde 2 niveles de jerarquía. El nivel global sería el anillo tal como estáimplementado actualmente. Y el nivel local consistiría en transmitirlos spikes locales dentro del mismo chip, sin necesidad de distribuirlosa través del anillo. De esta manera se mejoraría la e�ciencia en funciónde la localidad de las neuronas en un determinado chip.


2. Añadir una nueva prestación en el control de errores. Comprobar, nosolo que no se pierdan paquetes de datos como se hace hasta ahora, sinotambién la integridad de los datos recibidos. La forma más sencilla deimplementarlo sería añadiendo el checksum de los datos a los paquetesde datos que se transmiten. Una vez en recepción se compararía siel checsum calculado en recepción coincide con el de transmisión. Encaso a�rmativo podemos asegurar que todos los datos recibidos soncorrectos y en caso negativo sabemos que hay datos corruptos.


Bibliografía

[1] PERPLEXUS project, Contract no. 34632. Project reference TEC2008-06028/TEC

[2] Javier Iglesias. Emergence of Oriented Circuits driven by Synaptic Pru-ning associated with Spike-Timing-Dependent Plasticity (STDP). Tesisde Doctorado, 2005

[3] Moreno, J.-M.; Fernández, D.; Kotynia, L., "Synchronous Digital Im-plementation of the AER Communication Scheme for Emulating Large-Scale Spiking Neural Networks Models," Adaptive Hardware and Sys-tems, 2009. AHS 2009. NASA/ESA Conference on , vol., no., pp.189,196,July 29 2009-Aug. 1 2009 doi: 10.1109/AHS.2009.14

[4] J. Madrenas, J. M. Moreno; �Strategies in SIMD Computing for Com-plex Neural Bioinspired Applications� AHS; Proceedings of the 2009NASA/ESA Conference on Adaptive Hardware and Systems, pp. 376-381. Moscone Convention Center, San Francisco, California, USA, July29 � August 1, 2009.

[5] Aurora 8B/10B Protocol Speci�cation. Link: http://www.xilinx.

com/support/documentation/ip_documentation/aurora_8b10b_

protocol_spec_sp002.pdf

[6] LogiCORE IP Aurora 8B/10B v8.3 Product Guide. Link: http:

//www.xilinx.com/support/documentation/ip_documentation/

aurora_8b10b/v8_3/pg046-aurora-8b10b.pdf

[7] High-Speed Serial I/O Made Simple A Designers' Guide, with FPGAApplications. Abhijit Athavale and Carl Christensen. Link: http://www.xilinx.com/publications/archives/books/serialio.pdf

[8] KC705 Evaluation Board for the Kintex-7 FPGA User Gui-de. Link: http://www.xilinx.com/support/documentation/boards_and_kits/kc705/ug810_KC705_Eval_Bd.pdf

[9] 7 Series FPGAs GTX/GTH Transceivers User Guide. Link:http://www.xilinx.com/support/documentation/user_guides/

ug476_7Series_Transceivers.pdf

81


[10] Frank Vahid. Digital Design with RTL Design, VHDL, and Verilog.Editorial Wiley, segunda edición 2011

[11] Steve Kilts. Advanced FPGA design : architecture, implementation, andoptimization. Ed. Wiley, 2007

[12] J. Bhasker. A VHDL primer. Ed. Prentice Hall, 1999

[13] James D. McCabe. Network analysis, architecture, and design. Ed.MK/Morgan Kaufmann, segunda edición 2003

AER-RT: Interfaz de Red con Topología en Anillo para SNN ...

Documents