Story Transcript
TESIS DE MÁSTER:
AER-RT: Interfaz de Red con Topología en Anillo para 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2.
De niciones . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2.1.
SNN . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2.2.
AER . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.3.
Ubichip
. . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.4.
SNAVA
. . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.
Objetivos y requisitos
1.4.
Material de trabajo . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
6
1.5.
Realización del proyecto
6
. . . . . . . . . . . . . . . . . . . . .
5
2. Diseño
7
2.1.
Estudio de la topología . . . . . . . . . . . . . . . . . . . . . .
7
2.1.1.
Topología en Anillo . . . . . . . . . . . . . . . . . . . .
7
2.1.2.
Topología en Estrella
9
2.1.3.
Topología Punto a Punto
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.
Estudio red jerárquica
. . . . . . . . . . . . . . . . . . . . . .
11
2.3.
Conclusión estudio arquitectura de red . . . . . . . . . . . . .
13
2.4.
Elección de bus serie frente a paralelo
13
2.5.
Elección Aurora 8B/10B como protocolo serie de alta velocidad 14
. . . . . . . . . . . . .
3. Protocolo AER-RT
17
3.1.
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.
Problemática de diseño . . . . . . . . . . . . . . . . . . . . . .
18
3.3.
Sincronización entre los nodos del anillo
. . . . . . . . . . . .
19
3.3.1.
Sincronización de nodos mediante líneas punto a punto
19
3.3.2.
Sincronización de nodos mediante línea adicional de ready en pipeline . . . . . . . . . . . . . . . . . . . . .
3.3.3. 3.4.
Sincronización de nodos mediante paquetes de control
Protocolo AER-RT . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1.
Tipos de paquetes
3.4.2.
Estructura de los paquetes
. . . . . . . . . . . . . . . . . . . .
3.4.3.
Campos de los paquetes
iii
17
19 20 21 22
. . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . .
24
INTERFAZ DE RED AER-RT
3.4.4. 3.5.
iv
Detección de errores
. . . . . . . . . . . . . . . . . . .
Interfaz entre AER-RT y sistema multiprocesador
. . . . . .
3.5.1.
Interfaz de datos
. . . . . . . . . . . . . . . . . . . . .
25
3.5.2.
Handshaking (o señales eo_exec y eo_distrib) . . .
27
3.5.3.
Señal de Error
27
. . . . . . . . . . . . . . . . . . . . . .
4. Arquitectura AER-RT 4.1.
4.2.
4.3.
4.4.
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
29
4.1.1.
Diferentes versiones . . . . . . . . . . . . . . . . . . . .
33
4.1.2.
Metodología . . . . . . . . . . . . . . . . . . . . . . . .
33
Interfaz con sistema Multiprocesador . . . . . . . . . . . . . .
35
4.2.1.
Problema adicional: 2 dominios de reloj
. . . . . . . .
35
4.2.2.
Input FIFO. Sincronización de datos de entrada . . . .
36
4.2.3.
AER_2_SNAVA. Sincronización datos de salida
37
. . .
Aurora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.3.1.
Introducción
39
4.3.2.
Generar Core . . . . . . . . . . . . . . . . . . . . . . .
40
4.3.3.
Con guración utilizada . . . . . . . . . . . . . . . . . .
41
4.3.4.
Sistema de compensación de clock
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
41
AER Tx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.4.1.
Conexión con otros bloques
. . . . . . . . . . . . . . .
42
4.4.2.
Diagrama de bloques . . . . . . . . . . . . . . . . . . .
42
4.4.3.
Tx Controller . . . . . . . . . . . . . . . . . . . . . . .
45
4.4.4.
Tx Sync . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.4.5.
Tx Bypass . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.4.6.
Tx Start . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.4.7.
Tx Data . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.4.8.
Tx Finish
. . . . . . . . . . . . . . . . . . . . . . . . .
50
4.4.9.
Tx Idle . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.4.10. Modo Debug 4.5.
24 25
. . . . . . . . . . . . . . . . . . . . . .
50
AER Rx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.5.1.
Conexión con otros bloques
. . . . . . . . . . . . . . .
52
4.5.2.
Diagrama de bloques . . . . . . . . . . . . . . . . . . .
53
4.5.3.
Detector de paquetes . . . . . . . . . . . . . . . . . . .
56
4.5.4.
Contadores de paquetes
57
4.5.5.
Generación AER ON . . . . . . . . . . . . . . . . . . .
57
4.5.6.
Generación AER Done . . . . . . . . . . . . . . . . . .
58
4.5.7.
Filtro Bypass (o escritura en FIFO de todos los paque-
4.5.8.
Interfaz de salida AER_RX (o desencapsulación de los
tes a retransmitir)
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
paquetes de datos) . . . . . . . . . . . . . . . . . . . .
58 59
4.6.
Bypass FIFO
. . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.7.
AER Con g . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.8.
AER Error
61
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
INTERFAZ DE RED AER-RT
5. Resultados 5.1. 5.2.
v
Simulación con retardos (o Timing Simulation)
. . . . . . . .
63 63
Medidas de latencia para diferente número de nodos y diferente número de spikes . . . . . . . . . . . . . . . . . . . . . .
63
5.2.1.
Medidas anillo un nodo
. . . . . . . . . . . . . . . . .
63
5.2.2.
Medidas anillo dos nodos
. . . . . . . . . . . . . . . .
65
5.2.3.
Medidas anillo 3 nodos . . . . . . . . . . . . . . . . . .
67
5.3.
Latencia del sistema AER-RT . . . . . . . . . . . . . . . . . .
67
5.4.
Área utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.5.
Máxima frecuencia
5.6.
Consumo
. . . . . . . . . . . . . . . . . . . . . . . .
69
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6. Sistema completo AER-RT + emulador de SNAVA 7. Conclusiones
71 77
INTERFAZ DE RED AER-RT
vi
Índice de guras 1.1.
Esquema sistema Ubichip[4] . . . . . . . . . . . . . . . . . . .
3
1.2.
Interfaz de red AER previo de bus compartido[3]
. . . . . . .
4
2.1.
Ring Topology
. . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.
Latencia de la red en función del número de nodos (o chips) .
9
2.3.
Star Topology . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.4.
Red en malla
. . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.5.
Distribución de probabilidad de localidad en redes SNN[2] . .
11
2.6.
Red jerárquica híbrida . . . . . . . . . . . . . . . . . . . . . .
12
3.1.
Anillo AER-RT con 2 nodos . . . . . . . . . . . . . . . . . . .
17
3.2.
Anillo AER-RT con 3 nodos . . . . . . . . . . . . . . . . . . .
18
3.3.
Sincronismo línea externa punto a punto . . . . . . . . . . . .
20
3.4.
Sincronismo entre chips mediante línea de control en pipeline
20
3.5.
Arquitectura pipeline en anillo
22
3.6.
Esquema de la unión entre sistema MP y AER-RT en red con 3 nodos
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.7.
Cronograma Handshaking entre AER-RT y sistema MP
4.1.
Esquema AER-RT simpli cado
4.2.
Versión de nitiva Diagrama de bloques AER-RT
4.3.
Primera versión diagrama de bloques (Diciembre 2012) . . . .
34
4.4.
Primer paso en el diseño incremental . . . . . . . . . . . . . .
35
4.5.
Input FIFO Xilinx IP Core
37
4.6.
Diagrama de bloques AER_2_SNAVA . . . . . . . . . . . . .
38
4.7.
Output FIFO Xilinx IP Core
38
4.8.
Diagrama de estados máquina de estados de AER_2_SNAVA
39
4.9.
Puertos AER_TX
43
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
27 30 31
4.10. Diagrama de bloque AER TX . . . . . . . . . . . . . . . . . .
44
4.11. Cronograma AER TX
. . . . . . . . . . . . . . . . . . . . . .
45
4.12. Diagrama de estados Tx Controller . . . . . . . . . . . . . . .
46
4.13. Primera versión Maquina de estados de Tx Controller (totalmente descartada)
. . . . . . . . . . . . . . . . . . . . . . . .
47
4.14. Diagrama de estados Tx Sync . . . . . . . . . . . . . . . . . .
48
vii
INTERFAZ DE RED AER-RT
viii
4.15. Diagrama de estados Tx Bypass . . . . . . . . . . . . . . . . .
49
4.16. Diagrama de estados Tx Start . . . . . . . . . . . . . . . . . .
50
4.17. Diagrama de estados Tx Data . . . . . . . . . . . . . . . . . .
51
4.18. Diagrama de estados Tx Finish
51
4.19. Puertos AER_RX
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
53
4.20. Diagrama de bloque AER RX . . . . . . . . . . . . . . . . . .
54
4.21. Cronograma AER RX
56
. . . . . . . . . . . . . . . . . . . . . .
4.22. Diagrama de estados detector de paquetes de datos propios
.
57
. . . . . . . . .
58
4.24. Bypass FIFO Xilinx IP Core . . . . . . . . . . . . . . . . . . .
60
5.1.
Latencia en anillo de un nodo transmitiendo un único spike
.
64
5.2.
Latencia en anillo de un nodo transmitiendo 10 spikes
. . . .
65
5.3.
Latencia en anillo con dos nodos y transmitiendo un único spike 66
5.4.
Latencia en anillo con dos nodos y transmitiendo 10 spikes . .
66
5.5.
Latencia en anillo de tres nodos y transmitiendo 1 spike
67
5.6.
Latencia en anillo con tres nodos y transmitiendo 10 spikes
5.7.
Estimación de consumo AER-RT
4.23. Diagrama de estados generación de AER ON
6.1.
.
68
. . . . . . . . . . . . . . . .
70
Sistema AER-RT + emulador de SNAVA implementado en tres Kintex-7
6.2.
. . . . . . . . . . . . . . . . . . . . . . . . . . .
72
Detalle conexiones en sistema AER-RT + emulador de SNAVA implementado en tres Kintex-7
6.3.
. . .
. . . . . . . . . . . . . . .
73
Detalle de señales en el chip 0 tomadas con el analizador lógico virtual de Xilinx
. . . . . . . . . . . . . . . . . . . . . . . . .
75
Índice de cuadros 2.1.
Tabla comparativa con los ejemplos numéricos vistos en cada topología
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.
Tipos de paquetes AER-RT
3.2.
Paquete de Control AER-RT
3.3.
Paquete de datos AER-RT . . . . . . . . . . . . . . . . . . . .
24
3.4.
Cabecera AER-RT
. . . . . . . . . . . . . . . . . . . . . . . .
25
3.5.
Cabecera de control
. . . . . . . . . . . . . . . . . . . . . . .
25
4.1.
. . . . . . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . . .
24
Equivalencia entre frecuencia de transmisión (serie) y frecuencia de trabajo (paralelo) . . . . . . . . . . . . . . . . . . . . .
41
4.2.
Diferentes códigos para el modo Debug . . . . . . . . . . . . .
52
5.1.
Medidas anillo con un nodo
64
5.2.
Medidas anillo con dos nodos
. . . . . . . . . . . . . . . . . .
65
5.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 sistema multiprocessador (MP) i crear així una xarxa SNN multi-xip e cient i escalable. La creació de la interfície de xarxa AER-RT sorgeix amb l'objectiu de millorar les prestacions del sistema MP SNAVA, el qual està sent desenvolupat pel grup d'investigació AHA de la UPC. SNAVA és un sistema MP emulador 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 velocitat de transmissió i exibilitat per formar xarxes multi-xip, dos aspectes fonamentals en aquest tipus de xarxes. AER-RT apareix com un substitut de l'antiga interfície de xarxa de SNAVA, amb l'objectiu de millorar l'e ciència i l'escalabilitat del sistema global. La interfície de xarxa dissenyada introdueix dos canvis que son clau per millorar l'e ciència i l'escalabilitat del sistema. 1) La transmissió de les dades xip-a-xip passa de ser paral·lela a ser sèrie d'alta velocitat; 2) La topologia de la xarxa passa de ser en bus compartit a ser en anell. El primer canvi s'aconsegueix utilitzant el protocol per a comunicacions sèrie xip-a-xip Aurora 8b/10b de Xilinx. I el segon, creant un nou protocol que permeti la transmissió de paquets en una xarxa multi-xip amb topologia en anell. La interfície de xarxa dissenyada es prova conjuntament amb un emulador de SNAVA, formant així una xarxa AER-RT real a nivell hardware. La xarxa es compon de 3 FPGAs Kintex-7 connectades en anell. L'elevada velocitat de la nova interfície de xarxa i la gran facilitat per fer-la créixer en nombre de xips 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 interfaz 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 mejorar las prestaciones del sistema MP SNAVA que se desarrolla en el grupo de investigación AHA de la UPC. SNAVA es un sistema MP emulador de redes SNN en hardware. Antes de la realización del proyecto el interfaz de red de SNAVA tiene una serie de de ciencias en velocidad de transmisión y en exibilidad para formar redes multi-chip, dos aspectos fundamentales en este tipo de redes. AER-RT aparece como sustituto del antiguo interfaz de red de SNAVA con el objetivo de mejorar la e ciencia y escalabilidad del sistema global. El interfaz de red diseñado introduce dos cambios clave para mejorar la e ciencia y la escalabilidad del sistema. 1) La transmisión de los datos chipto-chip pasa de ser paralela a ser serie de alta velocidad; 2) La topología de la red pasa de ser en bus compartido a ser en anillo. El primer cambio se consigue utilizando el protocolo para comunicaciones serie chip-to-chip Aurora 8b/10b de Xilinx. Y el segundo creando un nuevo protocolo que permita la transmisió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 SNAVA implementando una red AER-RT real hardware. La red está compuesta por 3 FPGAs Kintex-7 conectadas en anillo. La elevada velocidad del nuevo interfaz de red y la gran facilidad para hacerla crecer en número de chips hacen que 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 designed to work together a Multiprocessor System (MPS) and create an e cient and 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's AHA research group. Before this thesis, the network interface of SNAVA have pitfalls regarding speed transmision and exibility to create multi-chip networks, two important aspects in this kind of networks. AER-RT appears as substitute of the old network interface of SNAVA with goal of improve speed and scalability of the global system. The network interface intruce two main changes to improve speed and scalability of the system. 1) The previous parallel chip-to-chip communication becomes high speed serial communication. 2) The previous shared bus topology becomes ring topology. The rst change is achieved by using Xilinx Aurora high speed communication protocol. And the second one, by creating a new protocol able to transmit packages in a multi-chip ring topology network. The designed network interface is proved together a emulation of SNAVA system forming a real AER-RT network in Hardware. The network consists in 3 Kintex-7 FPGAs connected forming a ring. The network works ne making 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 (AERRing Topology), una novedosa arquitectura de comunicaciones para SNN multi-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 hay necesidad 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 nodos es serie, punto a punto y de alta velocidad (del orden de Gbps) Para la distribución de spikes utiliza el protocolo AER-RT encapsulado en el protocolo serie de alta velocidad Aurora (protocolo propiedad de Xilinx) A continuación pasamos a introducir una serie de conceptos fundamentales para 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 neuronales. Pertenecen a la tercera generación de redes neuronales y se caracterizan por representar de forma realista el funcionamiento neuronal. Su utilización en sistemas bioinspirados o para emular sistemas neuronales reales está sumamente extendido.
1
INTERFAZ DE RED AER-RT
2
Las redes SNN se pueden simular mediante Software o emular en Hardware. Debido a su arquitectura paralela, su gran demanda de cómputo y a la necesidad de trabajar en tiempo real, la emulación de redes SNN en Hardware está plenamente justi cada.
Las redes SNN emuladas en Hardware se implementan mediante un sistema multiprocesador (MP), donde los procesaodres (PE) se interconectan entre ellos a través de un interfaz de red. Cada procesador emula a una neurona y la sinapsis se emula mediante la transmisión de spikes. Un spike es un evento que se produce en una determinada neurona y que se transmite a otras neuronas adyacentes.
En redes SNN implementadas en Hardware uno de los principales desafíos es el diseño de la arquitectura de comunicaciones. Interesa una arquitectura de red que permita conectar el mayor número de neuronas trabajando dentro de la ventana que marca el tiempo real.
1.2.2.
AER
AER es el acrónimo de Adress Event Representation. Es un protocolo que permite transmitir eventos de forma e ciente dentro de una red, donde cada nodo es a la vez consumidor y generador de eventos. Los eventos se indican transmitiendo la dirección del elemento generador.
El Bus AER o protocolo AER es muy utilizado en redes SNN. En este tipo de redes las neuronas son generadores y consumidores de eventos. Y los eventos son los spikes que se transmiten en la red viajando de una neurona a otra.
1.2.3.
Ubichip
En el grupo de investigación AHA de la UPC se trabaja desde hace algunos años en el desarrollo de sistemas bioinspirados y redes neuromór cas. En concreto, enmarcado dentro del proyecto Perplexus [1], AHA presenta una novedosa arquitectura Hardware para emular redes de tipo SNN. Se trata de la arquitectura Ubichip.
La arquitectura Ubichip permite emular redes neuronales en un sistema multichip, donde cada chip, o Ubichip, contiene un array de hasta 10x10 neuronas. Para comunicar las neuronas entre sí se utiliza un interfaz de red basado en el protocolo AER. Ver gura 1.1 para un esquema detallado de Ubichip.
INTERFAZ DE RED AER-RT
3
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 encarga de enviar las instrucciones a todos los elementos procesadores (PE) del array. Una vez el array de neuronas ha procesado los datos genera una serie de spikes para transmitir. Los spikes se transmiten por el bus AER. Cada Ubichip al recibir los spikes los decodi ca utilizando una memoria CAM. En la memoria CAM de cada chip está mapeado qué spikes harán que se dispare su potencial de membrana. Para una información más detallada sobre la arquitectura Ubichip consultar la referencia [4].
El interfaz de comunicaciones de Ubichip es un bus o chip con una topología de bus compartido. La comunicación es paralela con palabras de 8 bits. Este bus permite trabajar a frecuencias de hasta 5 MHz y admite una cierta escalabilidad, aunque el hecho de ser un bus compartido introduce algunas di cultades en cuanto a la implementación física. Además a medida que se conectan más chips al bus compartido la frecuencia de trabajo se reduce. Tenemos un esquema de este interfaz de red previo en la gura 1.2. A partir de ahora se hará referencia a esta arquitectura de red como el interfaz de red previo. Para una descripción más detallada sobre este interfaz de red previo consultar la referencia [3].
INTERFAZ DE RED AER-RT
4
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 de 1 ms, es la ventana de tiempo que impone el trabajar en tiempo real en redes de tipo SNN. Cada ciclo sináptico se divide en 1) Fase de ejecución y 2) Fase de distribución. Durante la fase de ejecución cada PE ejecuta sus instrucciones y genera una serie de spikes de salida. Durante la fase de distribución el interfaz de red distribuye los spikes generados por todos los chips que componen el sistema. Para simpli car supondremos que cada una de las fases emplea la mitad de la ventana de tiempo de 1 ms, es decir la fase de ejecució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 mejorado las prestaciones del sistema Ubichip con la aparición de una nueva arquitectura multiprocesador para redes de tipo SNN: SNAVA. SNAVA conserva la misma losofía de Ubichip pero incorpora una serie de mejoras. Por ejemplo el cuello de botella que introducía el acceso a la memoria que contiene las instrucciones en cada chip se ha solucionado sustituyendo la memoria de tipo SRAM externa por memoria cache local. Otra novedad es la inclusión de un sistema de virtualización que permite emular más de una neurona en cada PE. Sin embargo uno de los principales cuellos de botella de Ubichip, SNAVA no lo soluciona. Es la distribución de spikes. El antiguo interfaz de red
INTERFAZ DE RED AER-RT
5
se muestra insu ciente para distribuir todos los spikes que genera un sistema SNAVA multichip de manera e ciente. Este interfaz previo es poco escalable por los problemas que introduce el bus compartido a la hora de incluir nuevos chips en la red. De hecho en la práctica sólo ha sido posible implementar una red SNN con un único chip. Además es poco e ciente en cuanto 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 desarrollado con el propósito de contribuir a la mejora de prestaciones de la arquitectura Ubichip. En concreto AER-RT implementa un novedoso interfaz de red que mejora la e ciencia y la escalabilidad del sistema global. Este interfaz ha sido adoptado por el sistema SNAVA como nuevo interfaz de red sustituyendo al interfaz previo de bus compartido.
1.3. Objetivos y requisitos El objetivo de este proyecto es el de desarrollar un interfaz de red que permita conectar neuronas en una red SNN multi-chip de forma e ciente y escalable.
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 neuronas sea rápida. De esta manera tendremos capacidad para distribuir un mayor número de spikes, lo que supone poder emular un mayor número de neuronas 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 sistema multiprocesador que emula la red SNN crezca en número de chips y en número de neuronas. Buscamos que al aumentar el tamaño del sistema las prestaciones de éste no disminuyan y que la ampliación sea sencilla y barata de 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 distribución de spikes por todo el sistema. Cada nodo contendrá un array de, según la última versión de SNAVA, 10x10 PE con capacidad para emular hasta 700 neuronas (7 neuronas emuladas en cada PE).
INTERFAZ DE RED AER-RT
6
El interfaz entre el bloque AER-RT y el sistema multiprocesador tiene que 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 para implementar y depurar el diseño propuesto: 4 placas de evaluación KC705 [8]. Cada una de ellas con una FPGA de altas 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 casa Mentor 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 un interfaz de red con topología en anillo y comunicación serie de alta velocidad. Este punto se explica en el capítulo 2 2. Diseño de protocolo AER-RT. En este punto se modi ca el protocolo AER para que pueda ser utilizado en una red con topología en anillo. Los detalles de este protocolo se encuentran explicados en el capítulo 3 3. Diseño de la arquitectura de red AER-RT. Esta es la parte donde se hace el diseño del sistema digital en VHDL . Los detalles de la arquitectura desarrollada están en el capítulo 4 4. Veri cación de funcionamiento implementando un sistema SNN completo. Para completar este paso se construye un sistema digital que emula el comportamiento del sistema multiprocesador SNAVA y que se conectará con el interfaz AER-RT. Se veri ca el funcionamiento del sistema en una red en anillo con varios nodos y donde cada emulador de SNAVA genera spikes pseudo-aleatorios periódicamente Finalmente una vez validado el diseño, el interfaz AER-RT se ha incluido en el 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 se han adoptado a la hora de realizar el diseño del interfaz de red AER-RT, a saber: 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 velocidad que 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 de la topología de bus compartido que presenta el interfaz de red previo. Para evaluar la e ciencia de cada topología se analiza cuantos nodos o chips admitiría una red SNN respetando una ventana de tiempo para la distribución de spikes de 0,5 ms.
2.1.1.
Topología en Anillo
Para realizar el estudio de las diferentes topologías de red utilizaremos los siguientes parámetros: #chips: número de chips que tiene la red (equivale a número de nodos)
h
i
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
INTERFAZ DE RED AER-RT
8
Figura 2.1: Ring Topology
h
i
spikes chip AV
=
h
i
spikes neurona 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
h
i
spikes chip AV
En la gura 2.1 se puede observar la estructura de una red en anillo. La expresió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 en pipeline es igual al retardo que introduce el pipeline más el retardo introducido por el número de spikes total que viajan por el sistema. El retardo que introduce el pipeline es igual al número de elementos que lo forman, en este caso el número de chips del sistema. Y El retardo que introduce el número de spikes total que viaja por el anillo lo aproximamos por el número de spikes que tarnsmite cada chip por el número de chips del sistema.
spikes Tanillo = #chips + #chips 1/fCLK chip AV
Tanillo
spikes ∼ 1/fCLK = #chips chip AV T fCLK i #chips = h
spikes chip AV
(2.1)
(2.2)
(2.3)
En la ecuación 2.2 simpli camos el cálculo de la latencia despreciando el retardo que introduce el pipeline, ya que comparado con el número de spikes que se transmiten en todo el sistema es muy pequeño. Por lo tanto podemos concluir que la latencia en este tipo de redes es proporcional al número de chips, el número de spikes por chip medio e inversamente proporcional a la
INTERFAZ DE RED AER-RT
9
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 chips que acepta el sistema en función de la latencia, la frecuencia y el número de spikes transmitidos por chip.
Ejemplo numérico Si jamos la frecuencia de trabajo a 200MHz y el número de spikes transmitidos por chip en 105 (700 neuronas por chip y suponemos 15 spikes generadas cada 100 neuronas) el número máximo de chips que admite el sistema respetando 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 660k neuronas. En la gura 2.2 podemos ver la evolución de la latencia en función del 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 de utilizar 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 el chip con mayor número de spikes (peor caso) más el retardo introducido por el número de spikes global (ecuación 2.4). En este caso despreciamos el retardo que introduce el chip y obtenemos la misma expresión para la latencia que en el anillo (ecuación 2.5).
Testrella =
spikes chip
M AX
spikes + #chips chip
1/fCLK AV
(2.4)
INTERFAZ DE RED AER-RT
10
Figura 2.3: Star Topology
Figura 2.4: Red en malla
Testrella
spikes ∼ = #chips chip
1/fCLK
(2.5)
AV
La desventaja en este tipo de arquitectura es la necesidad de un gran número de elementos repetidores. El número de repetidores necesarios viene de 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 en anillo: 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 latencia es igual al tiempo de transmisión en uno sólo de los chips. Tomamos el chip con más spikes para transmitir como peor caso y obtenemos que la latencia es igual al número de spikes que se transmiten en ese chip por el inverso de la frecuencia de trabajo (ecuación 2.6).
INTERFAZ DE RED AER-RT
11
Figura 2.5: Distribución de probabilidad de localidad en redes SNN[2]
Tmalla
spikes = chip
1/fCLK
(2.6)
M AX
Si el número de enlaces serie fuera in nito en cada chip, ésta sería sin duda la mejor opción. Debido a que todos los spikes se transmiten de forma concurrente, la latencia sólo viene determinada por el número de spikes por chip 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 comunicación de cada chip. La topología punto a punto puede ser interesante para formar alguna topología híbrida.
Ejemplo numérico Si tomamos como ejemplo de chip una FPGA Kintex 7 disponemos de 28 puertos de comunicación serie bidireccionales. Esto nos permitiría implementar una red de hasta 28 chips (19k neuronas).
2.2. Estudio red jerárquica En este apartado estudiamos la posibilidad de establecer diferentes niveles de jerarquía en la red. Pensamos aprovechar la característica de localidad que tienen las neuronas al formar sinapsis. Según se desprende de la gura 2.5 las neuronas tienen más probabilidad de establecer lazos sinápticos con las neuronas más cercanas. Podemos aprovechar esta propiedad de localidad y por ejemplo crear una red con dos niveles de jerarquía: redes locales y red global. En la gura 2.6 se muestra un ejemplo de red jerárquica híbrida, en este caso cada chip tiene
INTERFAZ DE RED AER-RT
12
Figura 2.6: Red jerárquica híbrida
una red local intra-chip (dentro del chip) de tipo bus compartido, y cada chip forma una red global o-chip (fuera del chip) en anillo. En una red de este tipo cada spike que se transmite en cada chip tiene una característica de localidad. Puede ser local o global. Por lo tanto tendremos que añadir a cada spike esta propiedad.
Tjer´arquica = M AX(Tlocal , Tglobal )
(2.7)
Tjer´arquica = Tglobal
(2.8)
En una arquitectura de red jerárquica, con dos niveles de jerarquía, la latencia se divide en latencia de la red local y latencia de la red global. Si la distribución de spikes se realiza en paralelo en las dos redes la latencia será igual a la mayor de ellas (ecuación 2.7). En el caso de una red SNN la latencia está dominada por el tiempo que se invierte en transmitir los spikes globales, por lo que obtenemos la expresión 2.8 para la latencia en una red jerárquica. Por lo tanto siempre que no todos los spikes sean globales mejoraremos la e ciencia del bus con respecto a una red no jerárquica (en el peor caso en el que todos los spikes sean globales la igualaremos).
INTERFAZ DE RED AER-RT
13
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 cada topología
2.3. Conclusión estudio arquitectura de red De las diferentes topologías analizadas la topología en anillo parece ser la mejor elección. Tiene las mismas prestaciones que la topología en estrella y supone un ahorro signi cativo en Hardware adicional (repetidores). La topologí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 para formar 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 dotando de jerarquía a la arquitectura de red. Debido a que tenemos una latencia prácticamente igual a una red en estrella (o en bus compartido) y a su facilidad de implementación (no necesita Hardware adicional y necesita un reducido número de enlaces) decidimos desarrollar una arquitectura de comunicaciones con topología en anillo. Se contempla también la posibilidad de extenderla en el futuro a una red jerárquica.
2.4. Elección de bus serie frente a paralelo Uno de los objetivos del proyecto es diseñar un interfaz de red que sea e 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 paralela, utilizada en el interfaz de red previo de Ubichip, a una comunicación serie de alta velocidad. Trabajar a altas velocidades en un bus paralelo tiene una serie de desventajas: Más interferencias
INTERFAZ DE RED AER-RT
14
Di cultad de rutar las líneas para igualar retardos Además es más cara su implementación porque utiliza muchos puertos y líneas.
Por eso la tendencia en comunicaciones de alta velocidad es utilizar comunicaciones 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 comunicación serie. La comunicación serie permite trabajar a frecuencias más elevadas que la paralela, además presenta una serie de ventajas en cuanto a la implementació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 transmisión sea serie añade además facilidad en cuanto a la conexión entre las diferentes tarjetas. Para conseguir velocidades elevadas decidimos utilizar los bloques Gigabit Transceivers que incorpora la FPGA Kintex-7. Esto supone la necesidad de utilizar un protocolo para transmitir los datos a alta velocidad. Existen varias posibilidades [7]: In niband Fiber Channel SATA PCIe Finalmente nos decantamos por un protocolo que proporciona Xilinx de manera gratuita y que está ampliamente soportado por las FPGAs de altas prestaciones de este fabricante: Aurora.
2.5. Elección Aurora 8B/10B como protocolo serie de alta velocidad Al decidir utilizar comunicación serie de alta velocidad nos surge la necesidad de usar un protocolo adicional que encapsule los datos y los transmita a alta velocidad. Esto implica que el protocolo elegido nos tiene que asegurar
INTERFAZ DE RED AER-RT
15
una serie de prestaciones necesarias en comunicaciones de este tipo: compensación de errores, paridad, codi cación, distribución de bits, etc. Estudiamos diferentes opciones (ethernet, crear un protocolo propio, etc) pero nalmente nos decidimos por utilizar el protocolo Aurora 8B/10B de Xilinx por 2 razones: 1) simplicidad, 2) prestaciones adecuadas a nuestras necesidades. Aurora 8B/10B [5] es un protocolo de nivel de enlace escalable y ligero para comunicaciones serie de alta velocidad. Para utilizar el protocolo en tu diseño Xilinx proporciona el Core de propiedad intelectual (IP) Aurora 8B/10B. El Core permite establecer transmisión de datos serie entre distintos dispositivos 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,48 Gb/s (si se utilizan varios transceivers en paralelo). Los canales de datos pueden ser full-duplex o simplex (bidireccionales o unidireccionales). Xilinx proporciona el Core en código VHDL o Verilog. En nuestro caso usamos la versión en VHDL por compatibilidad con SNAVA. El IP Core Aurora 8B/10B es versátil en cuanto a aplicaciones debido a su bajo coste, velocidad escalable y amigable interfaz de usuario. Una de las aplicaciones que se señala en el datasheet del fabricante es Chip-to-chip links(comunicaciones entre distintos chips). Se señala que con este Core puedes reemplazar fácilmente las conexiones paralelas entre chips por conexiones serie de alta velocidad, ya que el Core proporciona toda la lógica necesaria para utilizar los bloques Gigabit Transceivers de la FPGA. Además con un consumo reducido de la lógica de la FPGA. Como vemos el IP Core Aurora de Xilinx cumple el requisito de e ciencia que estamos buscando para la red. Además combinado con la topología en anillo permitirá tener un sistema multi-chip escalable.
Ejemplo numérico La frecuencia de bus máxima en Aurora utilizando un transceiver es de 6,4 Gb/s. . Si seleccionamos el bus de datos con tamaño de 16 bits implica una frecuencia de trabajo a nivel de usuario de 312 MHz. Si aplicamos estos números a la fórmula para calcular la latencia en una red con topología en anillo (ecuación 2.3) obtenemos una escalabilidad de hasta 1485 chips, más de 1 millón de neuronas.
INTERFAZ DE RED AER-RT
16
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 topología en anillo. La transmisión de spikes se realiza encapsulando los spikes en paquetes de datos AER-RT que viajan a su vez encapsulados en el protocolo de comunicaciones serie de alta velocidad Aurora 8B/10B.
En las guras 3.1 y 3.2 podemos observar como sería la estructura de una red AER-RT con 2 y 3 nodos respectivamente. Cada nodo es una FPGA e incluye un bloque Aurora bidireccional.
A continuación se enumeran las principales características del protocolo AER-RT: Está basado en el protocolo AER: la transmisión de spikes se realiza transmitiendo 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 de distribución al mismo tiempo
Figura 3.1: Anillo AER-RT con 2 nodos
17
INTERFAZ DE RED AER-RT
18
Figura 3.2: Anillo AER-RT con 3 nodos
Permite la distribución por todo el anillo de los spikes que genera cada chip 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 cambiar el diseño del interfaz No necesita que uno de los chips del anillo sea máster, el diseño es totalmente simétrico para todos los nodos del anillo El único requisito es que cada nodo o chip esté identi cado con un identi cador de chip que denominamos chip-id El interfaz entre AER-RT y el sistema multiprocesador (puede ser SNAVA 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íticos a 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
INTERFAZ DE RED AER-RT
19
3.3. Sincronización entre los nodos del anillo Uno de los primeros problemas a solucionar es cómo sincronizar los diferentes chips del anillo. En el sistema multiprocesador que acompaña al interfaz de red AER-RT como sabemos hay un array de PE que emulan neuronas. Estos PE procesan los datos de entrada en la fase de ejecución y generan los spikes a distribuir durante la fase de distribución. El problema es que todos los chips no tienen por que contener la misma secuencia de instrucciones, por lo que en cada chip la fase de ejecución puede terminar en un momento distinto.
El problema a solucionar por lo tanto es como saber en un determinado chip que todos los chips han terminado la fase de ejecución y por lo tanto se puede 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 punto
Esta solución consiste en utilizar una puerta lógica de tipo AND donde cada una de sus entradas corresponde a una señal proviniente de cada uno de los chips con información de si se ha acabado la fase de ejecución (1: se ha acabado; 0: no se ha acabado). De esta manera cuando tengamos un 1 lógico a la salida de la puerta AND podremos asegurar que todos los nodos están listos para transmitir. Esta solución implica utilizar N + 1 cables en una red de N nodos. Además necesitamos lógica adicional para implementar la puerta AND con tantas entradas como nodos tenga el sistema (ver gura 3.3). Como punto positivo la arquitectura Hardware sería simétrica en todos los chips, ya que no necesita que un chip comience la transmisión, es decir no necesita que uno de los chips actúe como máster.
3.3.2.
Sincronización de nodos mediante línea adicional de ready en pipeline
Esta solución consiste en conectar cada chip con su vecino mediante una línea externa (línea de ready). Mediante esta línea cada chip propaga su estado y el de los chips que lo preceden. Cuando tenemos un positivo a la entrada hay que esperar a que éste sea estable como mínimo el tiempo que tarda en propagarse la señal ready por todo el anillo.
Esta solución necesita menos líneas adicionales que la anterior, pero presenta el inconveniente que uno de los chips tiene que actuar como máster e
INTERFAZ DE RED AER-RT
20
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 implica diferente 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 para realizar la sincronización. El proceso de sincronización según este método consta de los siguientes pasos: 1. Cuando un chip ha terminado la fase de ejecución envía un paquete de sincronizació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ón y el número de chips en el sistema es de n, entonces está sincronizado y puede iniciar la fase de distribución. Hay un desfase de como máximo de n ciclos de reloj entre que empieza a transmitir el primer chip hasta que lo hace el último. Pero esto no implica
INTERFAZ DE RED AER-RT
21
ningún problema a nivel práctico.
Ésta es la solución que se utiliza nalmente. Reúne la ventaja de tener un diseño de Hardware simétrico para cada nodo del anillo (no hay necesidad de 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 propio protocolo.
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 multiprocesador SNN. En primer lugar se encarga de sincronizar todos los nodos del anillo. Una vez sincronizados todos los nodos, comienza la distribución de todos los spikes del sistema. Además cada spike, una vez que ha sido procesado por todos los nodos de la red, regresa al chip que lo generó y en este punto muere. De esta manera podemos controlar en cada chip si se ha perdido algún paquete de los que él mismo generó.
En la gura 3.5 se presenta un esquema del funcionamiento del protocolo: el chip n crea paquetes y los envía. Estos paquetes son recibidos y procesados 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 asegurar que la distribución de spikes comienza cuando todos los chips han acabado la fase de ejecución 2. Distribución de spikes: Los spikes que genera cada chip son enviados como paquetes de datos. Cada paquete tiene un tiempo de vida limitado. Una vez que ha recorrido todo el anillo y vuelve al chip que lo generó muere 3. Fin distribución de spikes. Un chip sabe que ha recibido todos los spikes del sistema cuando recibe el paquete FINISH que él mismo generó previamente, o alternativamente cuando contabiliza tantos paquetes FINISH como nodos hay en el sistema. El paquete FINISH se envía como último paquete después de enviar el último spike en un determinado chip.
INTERFAZ DE RED AER-RT
22
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 encapsulada en paquetes AER-RT de 16 bits. Hay dos tipos de paquetes: paquetes de datos y paquetes de control. En la tabla 3.1 se presentan los diferentes tipos de paquetes AER-RT.
Los paquetes de datos transmiten la dirección de la neurona fuente que genera el spike (protocolo AER). Sin embargo no contienen información sobre qué 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 datos siempre han de ir precedidos de un paquete de control START, para conocer de que chip provienen.
Los paquetes de datos se transmiten en ráfagas. Cada ráfaga corresponde a datos provenientes de un determinado chip y está precedida por un paquete de START. El paquete de START es imprescindible ya que proporciona informació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, FINISH y IDLE.
El paquete de control START se utiliza para transmitir el chip-id de los paquetes de datos que precede.
El paquete de control FINISH se encarga de señalar cuando termina una ráfaga de datos de un determinado chip. Además permite conocer cuando se ha terminado la fase de distribución. Cuando en el receptor contabilizamos
INTERFAZ DE RED AER-RT
Control
23
SYNC START FINISH IDLE
Datos Cuadro 3.1: Tipos de paquetes AER-RT
tantos paquetes FINISH como nodos hay en el sistema, podemos asegurar que la distribución de spikes se ha completado y que por lo tanto se ha completado un ciclo AER-RT. Los paquetes de control de sincronismo o paquetes SYNC son utilizados durante la fase de sincronización. Cada vez que un chip ha terminado la fase de ejecución en su sistema multiprocesador, y por lo tanto está listo para entrar 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 forma equivalente cada chip en el anillo hará lo mismo cuando esté listo para comenzar la fase de distribución de spikes. Finalmente cuando en un determinado chip se reciben todos los paquetes de sincronismo del sistema (tantos como nodos hay en el anillo), incluido el generado por él mismo, indica que ya están todos los chips listos. En este momento se empiezan a distribuir los spikes por el anillo. Los paquetes de control de tipo IDLE son paquetes que se generan cuando el 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 necesidad después de observar que si no se transmiten datos por el enlace serie durante un periodo largo de tiempo, aparecen errores en el enlace. De esta manera en los momentos que el protocolo está en reposo se envían constantemente paquetes de tipo IDLE. Así el enlace se mantiene en perfectas condiciones y sin ningún error.
3.4.2.
Estructura de los paquetes
Los paquetes AER-RT son paquetes de 16 bits. Los paquetes de datos se distinguen 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 de datos. En los paquetes de datos tan sólo hay un bit de cabecera, los 15 bits restantes se pueden utilizar para transmitir datos (en el sistema implementado sólo utilizamos 11 de estos bits). La decisión de no incluir la dirección de chip en el paquete de datos nos permite una mayor e ciencia en el número
INTERFAZ DE RED AER-RT
24
1 bit
3 bits
5 bits
7 bits
H
H_CONT
UNUSED
chip-id
Cuadro 3.2: Paquete de Control AER-RT 1 bit
4 bits
11 bits
H
UNUSED
_____DATOS_____
Cuadro 3.3: Paquete de datos AER-RT
de neuronas que podemos direccionar dentro de un mismo chip. Ver gura 3.3. En los paquetes de control hay 3 bits adicionales de cabecera, es lo que llamaremos cabecera de control. Según el valor de éstos tres bits adicionales identi 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 paquetes AER-RT. En las tablas 3.4 y 3.5 se muestran los valores de las cabeceras 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 de control 3. UNUSED. Bits no utilizados pero disponibles si se quiere aumentar los bits utilizados para datos (en paquetes de datos) o para chip-id (en paquetes de control) 4. chip-id (7 bits). Es la dirección del chip que generó el paquete. Nos permite 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 32768 neuronas por chip si utilizamos los 15 bits de datos del paquete de datos.
3.4.4.
Detección de errores
El hecho de que los paquetes de datos viajen por el anillo y vuelvan al mismo chip que los generó permite conocer si se ha producido algún error o
Cabecera AER-RT
Tipo de paquetes
0
Control
1
Datos
Cuadro 3.4: Cabecera AER-RT Cabecera de control
Tipo de paquete
100
IDLE
101
SYNC
110
START
111
FINISH
Cuadro 3.5: Cabecera de control
alguna pérdida de datos. De esta manera se planea detectar pérdidas de paquetes mediante un contador en transmisión y otro en recepción. Y detectar la integridad de los datos mediante el cálculo del checksum de los paquetes de datos transmitidos y recibidos.
3.5. Interfaz entre AER-RT y sistema multiprocesador El interfaz AER-RT está ideado para trabajar en conjunto con un sistema multiprocesador. Por lo tanto es fundamental que quede bien de nido el interfaz entre ambos subsistemas. En la gura 3.6 podemos observar la unión de 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 spikes que quiere que se distribuyan por el sistema? El método consiste en escribir en la FIFO de entrada del interfaz AER-RT todos los spikes a transmitir, y acto 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 bus de recepción a medida que los vaya recibiendo. Se planea construir un bloque adicional que traduzca y sincronice la recepción de estos datos con el interfaz de recepción del sistema SNAVA. Una vez recibidos todos los datos o spikes se genera un pulso en el puerto eo_didtrib que viaja hasta el sistema MP para 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 3 nodos
26
INTERFAZ DE RED AER-RT
27
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 permiten que 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 fase de distribución de spikes. El comienzo del protocolo AER-RT se produce al recibir un nivel lógico alto en el puerto de entrada eo_exec (eo_exec=end of execution). El sistema multiprocesador le indica mediante esta señal al interfaz AER-RT que ha terminado la fase de ejecución, y por lo tanto puede empezar la fase de distribución. Una vez terminada la distribución de spikes y por lo tanto completado un ciclo AER-RT se le indica al sistema multiprocesador mediante un pulso en 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 con un cronograma para las señales eo_exec y ei_exec como el que vemos en la 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 la fase de distribución, se actualiza la señal de error AER_error. Si la señal vale uno quiere decir que durante la fase de distribución se han perdido paquetes, en caso contrario la distribución de spikes se ha realizado con éxito.
INTERFAZ DE RED AER-RT
28
Capítulo 4
Arquitectura AER-RT 4.1. Introducción La función principal del interfaz de comunicaciones AER-RT es la de distribuir 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 receptor y un sistema de bypass que permita pasar los datos de un nodo a otro en el anillo. En la gura 4.1 podemos ver un esquema simpli cado del interfaz AER-RT. Como se puede apreciar en el esquema simpli cado de la gura 4.1, el sistema consta de cuatro bloques principales: Aurora, AER RX, BYPASS y AER TX.
El bloque Aurora se encarga de encapsular y desencapsular los datos que se transmiten y reciben con el protocolo serie de alta velocidad Aurora de Xilinx AER RX es el bloque de recepción donde se reciben los paquetes AERRT provenientes del interfaz de recepción de Aurora. Los paquetes de datos se desencapsulan y se envían al sistema multiprocesador BYPASS es el bloque encargado de transmitir desde recepción hasta transmisión los paquetes recibidos que hay que retransmitir AER TX se encarga de crear los paquetes AER-RT y de transmitirlos al bloque Aurora. Los paquetes de datos los crea a partir de los datos recibidos del sistema multiprocesador En la gura 4.2 podemos observar un diagrama de bloques del interfaz de red AER-RT más detallado. Vemos que el sistema de bypass se realiza mediante 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 31 Diagrama de bloques AER-RT
encarga de amortiguar los datos que se tienen que retransmitir. La FIFO de entrada Input FIFO, por su parte, se encarga de almacenar los spikes provenientes del sistema multiprocesador y que hay que distribuir por el anillo. El bloque AER Con g se encarga de guardar los parámetros de con guración del sistema (chip-id, ring_size, debug_mode). Por su parte el bloque AER_error se encarga de comprobar se se han perdido datos durante un ciclo de distribución. Si nos jamos podemos ver que entre el bloque AER RX y AER TX hay 2 señales de control: AER_on y AER_done. Estas señales son fundamentales para el correcto funcionamiento del sistema AER-RT. AER_on permite identi car cuando se ha completado la fase de sincronizació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_MODULE que 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 y consiste en que el enlace queda inhabilitado durante un número de ciclos de reloj determinado mientras Aurorarealiza tareas de reajuste. Mientras el enlace está inhabilitado no se pueden transmitir datos y el sistema se tiene que poner en un estado de espera hasta que se vuelva a liberar el enlace. Una vez liberado el sistema AER-RT reanuda su funcionamiento en el mismo punto que 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 para comunicarse con el sistema multiprocesador podemos distinguir 2 tipos. Las señales de Handshaking con el sistema multiprocesador: AER_eo_exec es una entrada. Permite que el sistema MP indique que ha terminado la fase de ejecución y que se puede comenzar un nuevo ciclo AER-RT AER_eo_distrib es una salida. Permite noti carle al sistema MP que 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 MP escriba los spikes que quiere que se distribuyan. Los spikes se almacenan en la FIFO de entrada Input FIFO hasta que se distribuyen por el anillo. El interfaz incluye la necesidad del reloj del sistema MP. El reloj se utilizará para escribir en Input FIFO, ya que el interfaz de entrada diferencia entre 2 dominios de reloj, el de escritura y el de lectura. De esta forma se puede realizar la sincronización de datos entre el sistema MP y el interfaz AER-RT. Estos dos bloques están alimentados con 2 señales de reloj físicamente diferente por lo que representan dominios de reloj independientes
32
INTERFAZ DE RED AER-RT
33
Interfaz AER RX. El interfaz de recepción devuelve al sistema multiprocesador los spikes que provienen de la red multichip. El interfaz consiste 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 concebida en Diciembre de 2012 ( gura 4.3). En esta primera versión ya está de nida la arquitectura fundamental, aunque se irán introduciendo algunos cambios. 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ón Duplex de Aurora es más robusta y más fácil de implementar. También se contemplaba la opción de que la arquitectura fuera jerárquica y que distinguiera entre spikes locales y globales tal como se aprecia al observar que hay varias FIFOs adicionales. Esta opción no se ha llegado a materializar por falta de tiempo.
4.1.2.
Metodología
Hemos tratado de crear un sistema lo más modular posible, además de tratar 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. También se ha empleado con éxito la técnica de divide and conquer (divide y vencerás), lo que ha facilitado la implementación de los bloques más complejos como el controlador de transmisión. Además, una vez diseñado el sistema en papel, se sigue un método de diseño incremental para implementar el sistema. Este método consiste en comenzar impementando un sistema básico y, una vez probado y asegurada su robustez, ampliarlo con una nueva funcionalidad. 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 y el resto de chips hacen un bypass de lo que reciben. En la gura 4.4 podemos ver esta primera etapa de diseño incremental. En esta primera etapa el diseño ya es simétrico para todos los chips, seleccionamos si establecer generación/recepción de datos o bypass mediante un multiplexor atacado por el parámetro de con guración chip-id. Progresivamente fuimos añadiendo funcionalidades al sistema. Primero sincronización, luego datos, nalmente detección de errores. Esta forma de trabajar permite localizar y depurar fácilmente las partes críticas del diseño.
INTERFAZ DE RED AER-RT
Figura 4.3: Primera versión diagrama de bloques (Diciembre 2012)
34
INTERFAZ DE RED AER-RT
35
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 multiprocesador tiene dos dominios de reloj físicamente diferentes. El sistema AER-RT utiliza el reloj recuperado de los datos transmitidos por el enlace serie Aurora, y el sistema MP tiene su propio reloj. Estos relojes podemos ajustarlos a la misma frecuencia, pero son relojes físicamente diferentes y que no están relacionados (por ejemplo no conocemos la diferencia de fase que hay entre ellos). Por lo que forman distintos dominios de reloj. Por lo tanto necesitamos un mecanismo para poder establecer una comunicación entre señales que pertenecen a diferentes dominios de reloj. Para ello utilizamos sincronizadores. Para sincronizar señales de control utilizaremos registros en cascada alimentados con el reloj del dominio de clock al que viaja la señal. Los buses de datos se sincronizan mediante FIFOs de doble puerto con dominios de reloj independientes en la interfaz de escritura y en la de lectura. La sincronización de los datos de entrada la realizamos mediante una FIFO de sincronización. Este tipo de FIFOs tiene un reloj independiente para la escritura de datos y otro para la lectura. En nuestro caso esta función la desempeña INPUT FIFO, creada a partir de el IP Core de Xilinx FIFO Generator que permite la sincronización de los datos. La sincronización de los datos de salida se realiza utilizando otra FIFO
INTERFAZ DE RED AER-RT
36
de sincronización similar a la que se utiliza en la entrada. Es la FIFO OUTPUT FIFO que se encuentra en el bloque AER_2_SNAVA (ver sección 4.2.3 para más detalles sobre este bloque). Esta FIFO es similar a INPUT FIFO y permite sincronizar los datos entre los dos dominios de reloj.
El bloque adicional AER_2_SNAVA (ver gura 4.6) se presenta como un extra junto con el sistema AER-RT. Su función es la de adaptar el sistema AER-RT para trabajar conjuntamente con el sistema SNAVA. De esta manera las particularidades de la comunicación con SNAVA están contenidas en el componente AER_2_SNAVA y el bloque AER-RT conserva su universalidad 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 de sincronización conectados en cascada, en concreto utilizamos 3 registros en cascada para reducir al mínimo la probabilidad de que aparezca metaestabilidad. Al sincronizar eo_exec los registros de sincronización utilizan el reloj del AER-RT; Y al sincronizar eo_distrib los registros de sincronización utilizan el reloj del sistema multiprocesador. Los registros de sincronización se 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. Para ello utilizamos una FIFO de doble puerto con relojes independiente para lectura y escritura.
Al poner esta FIFO dentro del sistema AER-RT estamos forzando que uno de los puertos de entrada del sistema sea el reloj del bloque multiprocesador, 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 sistema multiprocesador). Pero hemos decidido incluirla en el bloque AER-RT ya que ésta está totalmente integrada con el bloque de transmisión, y además así 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ón por seguridad. Se ha utilizado el IP Core de Xilinx FIFO Generator para implementarla (ver opciones de con guración del IP Core en la gura 4.5).
INTERFAZ DE RED AER-RT
37
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 desarrollado y el sistema multiprocesador SNAVA. Se ha decidido poner este bloque fuera del sistema AER-RT para dotar a éste de mayor generalidad. Además en este bloque se realiza la sincronización de los datos recibidos entre los 2 dominios de reloj que hay en el sistema global.
El bloque AER-RT tiene su propio dominio de reloj. Y el Sistema SNAVA el suyo. La frecuencia de los relojes es la misma, pero son señales físicamente diferentes por lo tanto no es posible conocer cual será la diferencia de fase entre ellas. En el esquema de la gura 4.6 identi camos el reloj del AER en rojo y el del sistema multiprocesador en azul.
Para sincronizar los datos entre los dos dominios de reloj se utiliza una FIFO de sincronización, la OUTPUT FIFO, de manera similar a como hicimos con INPUT FIFO. OUTPUT FIFO es una FIFO de doble puerto donde 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 en la FIFO de salida, con el reloj del AER-RT. Necesitamos una máquina de estados que se encargue de leer estos datos y enviarlos al sistema multiprocesador SNAVA, esta vez con el reloj del SNAVA. Podemos ver el diagrama de estados de esta máquina de estados en la gura 4.8. En este diagrama
INTERFAZ DE RED AER-RT
Figura 4.6: Diagrama de bloques AER_2_SNAVA
Figura 4.7: Output FIFO Xilinx IP Core
38
INTERFAZ DE RED AER-RT
39
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 de fase de distribución, por lo que sabemos que se han escrito todos los datos recibidos en la FIFO de salida), se procede a la lectura de la FIFO y la validació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 mediante la señal out_empty, lo que implica que se han leído y enviado todos los datos al sistema MP, se procede a generar la señal ei_exec que indicará a SNAVA 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 del diseño (en Xilinx se usa el chero UCF), las restricciones de frecuencia de los dos dominios de reloj. Además hay que incluir en las restricciones que se analice el retardo entre los dominios, con la instrucción From: To. Nosotros no lo hicimos en un principio y tuvimos problemas de retardo en alguna de las líneas de lectura de la FIFO de salida. En todo caso el problema de retardo se puede solucionar añadiendo registros de pipeline en el camíno crítico (ver registros RP en gura 4.6).
4.3. Aurora 4.3.1.
Introducción
Aurora es un protocolo de comunicaciones creado por Xilinx. Permite implementar comunicaciones serie de alta velocidad de una forma sencilla. Utiliza los transceivers de alta velocidad incluidos en las siguientes FPGAs de Xilinx: Virtex-7, Kintex-7, Virtex-6 y Spartan-6. La forma de incluirlo en un diseño es generar el Core mediante la herramienta Core generator.
INTERFAZ DE RED AER-RT
40
Principales características: Serialización diferencial formato NRZ 8b/10b: DC balance, mismo número de 1 que 0 (disparity), bit transittion 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 que se 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 pueden elegir entre 1 y 16. Cada canal se implementa haciendo uso de un transceiver. 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ón y Recepción) o unidireccional (Transmisión o Recepción). En nuestro caso utilizaremos modo Duplex Interface: Framming o Streaming. Framing interesa si utilizas el bus AMBA. Streaming es tan sencillo como escribir o leer datos en o de una memoria. Usamos streaming Flow Control: Permite establecer prioridad y controlar el ujo de datos, velocidad, tipo. Ejemplo que no se rebose el buer de recepción. Evita pérdidas. Backchannel: 2 opciones: Sidebans o Timer. Permite comunicación entre Core simplex tx y Core simplex rx. Sidebans son 4 puertos en cada Core simplex que unimos mediante cable con su simplex partner. Timer es un sistema que mediante temporizador supone que la inicialización del partner se ha realizado correctamente. Usamos sidebands
INTERFAZ DE RED AER-RT
41
Frecuencia transmisión
Tamaño palabra @ Frecuencia trabajo
2.500 Gbps
16 bits @ 125 MHz
3.125 Gbps
16 bits @ 156 MHz
4.000 Gbps
16 bits @ 200MHz
6.250 Gbps
16 bits @ 312 MHz
3.125 Gbps
32 bits @ 77 MHz
6.250 Gbps
32 bits @ 145 MHz
Cuadro 4.1: Equivalencia entre frecuencia de transmisión (serie) y frecuencia de 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ás una 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 la frecuencia a la que trabaja el sistema SNAVA. En la tabla 4.1 se pueden apreciar distintas con guraciones en función de la frecuencia de trabajo que se 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 comunicaciones chip-to-chip dónde cada chip tiene su propio reloj. Este reloj es de la misma frecuencia en todos los chips del sistema pero son físicamente distintos. Por lo tanto aunque a priori tengan la misma frecuencia siempre habrá una pequeña diferencia de frecuencia entre los diferentes relojes. Esta diferencia se compensa periódicamente en el sistema realizando una parada en la transmisión de datos y enviando secuencias de compensación de clock.
INTERFAZ DE RED AER-RT
42
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 los siguientes bloques: Aurora. El interfaz consiste en habilitar datos para su transmisión siempre que la señal ready indique que el enlace Aurora está disponible Input FIFO. De aquí se obtienen los datos provenientes del sistema multiprocesador. Es decir, los spikes que se tienen que distribuir por todo el sistema. En la FIFO de entrada están los datos crudos, sin ningún tipo de cabecera AER-RT. Es un interfaz de lectura de la FIFO Bypass FIFO. Aquí se encuentran paquetes AER-RT, pueden ser de datos o de control, que esperan a ser retransmitidos. Es un interfaz de lectura de la FIFO AER RX. De el bloque AER RX se obtienen las principales señales internas 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 y que 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 guración y las entradas de habilitación del modo Debug. Los principales parámetros de con guración en cada chip son: chip-id, Ring_size y debug_mode AER Error. Este bloque se encarga de comprobar que no se han perdido datos durante la distribución de spikes. Comprueba que todos los paquetes de datos que genera un determinado chip llegan de nuevo al chip a través del anillo. No se garantiza el contenido de los paquetes de datos
4.4.2.
Diagrama de bloques
El funcionamiento del bloque AER TX consiste en la transmisión de los paquetes AER-RT. Desde el punto de vista del bloque AER TX, cada ciclo AER-RT se puede dividir en varias etapas: 1. IDLE. Etapa de reposo. Se envían paquetes de tipo IDLE constantemente para mantener el enlace de comunicaciones. 2. SYNC. Fase de sincronización. Se envían varios paquetes de sincronización. En la versión actual del sistema se envían 2 paquetes SYNC
INTERFAZ DE RED AER-RT
43
Figura 4.9: Puertos AER_TX
3. BYPASS SYNC. Se hace el bypass de paquetes de sincronismo recibidos 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 FINISH de 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 gura 4.10.
Esta aproximación modular de dividir el transmisor en varios submódulos con una función muy concreta, permite mayor exibilidad a la hora de modi car el protocolo y mayor robustez a la hora de identi car y depurar errores. 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íneas permiten a Tx Controller habilitar cada módulo, y además permiten que cada módulo le comunique a Tx Controller si ha terminado su operación o si todavía la está ejecutando. Finalmente mediante un multiplexor se selecciona cual de los bloques transmisores se conecta con el puerto de salida de
INTERFAZ DE RED AER-RT
Figura 4.10: Diagrama de bloque AER TX
44
INTERFAZ DE RED AER-RT
45
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 habilitan los diferentes bloques de transmisión. Y como a la salida se multiplexa en cada caso la salida del bloque que interesa. Además podemos observar la proporción de tiempo que se emplea en cada etapa de transmisión. En este caso se está simulando un anillo con dos nodos, y la transmisión de un único paquete de datos.
4.4.3.
Tx Controller
Este bloque es el cerebro del transmisor, se encarga de dirigir su funcionamiento 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 activar en cada momento y durante cuanto tiempo. En la gura 4.12 se puede observar la máquina de estados del bloque Tx Controller. Como se aprecia cada etapa de la transmisión se identi ca fácilmente: TX_IDLE. Estado de reposo. Se envían paquetes de tipo IDLE TX_SYNC. Envío paquete de sincronización
INTERFAZ DE RED AER-RT
46
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 INPUT FIFO 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ún paquete 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 de tipo IDLE Cabe destacar que llegar a este diseño de el controlador no fue inmediato. La primera aproximación (en una etapa muy temprana) fue implementar todo el protocolo en una sola máquina de estados, tal como se aprecia en la gura 4.13. Pero enseguida fue evidente que su complejidad no era manejable y se optó por la solución modular que hemos visto. Utilizando un enfoque modular la máquina de estados del Tx controller es bastante intuitiva y por lo
INTERFAZ DE RED AER-RT
47
Figura 4.13: Primera versión Maquina de estados de Tx Controller (totalmente 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ún cambio o ampliación del protocolo. Haber seguido este enfoque modular desde primeras etapas en el diseño ha posibilitado la facilidad y rapidez con que estas modi caciones han sido incluidas. Por ejemplo en un primer momento el protocolo no utilizaba paquetes de START ni de IDLE. Con un enfoque no modular la inclusión de este tipo de paquetes en el protocolo supone el rediseño de toda la máquina de estados. Con un enfoque modular el cambio consiste en crear un bloque que se encargué de enviar este tipo de paquetes y 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, al probarlo en la placa, tener una salida con el estado de la máquina de estados de Tx Controller. De esta forma podemos saber en que fase de transmisión se encuentra 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 de generar un acknowledge para el bloque Tx Controller cuando este paquete se ha enviado con éxito. La señal de acknowledge es necesaria porque puede suceder que en el momento que Tx controller habilite el bloque sync el enlace Aurora no esté listo (se encuentre en fase de compensación de reloj por ejemplo). De esta manera Tx controller espera hasta que Tx Sync le conteste que el paquete se ha enviado con éxito.
INTERFAZ DE RED AER-RT
48
Figura 4.14: Diagrama de estados Tx Sync
Como se aprecia en el diagrama de estados de la gura 4.14, el envío del paquete de sincronismo se produce cuando se recibe la señal de habilitación y además el canal de transmisión está listo (señal ready_tx). Después del envío se genera la señal sy_done para comunicarle a Tx Controller que se ha 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 clock en el enlace Aurora 4. Reanudar la transmisión cuando la compensación de clock ha sido completada Este bloque es el que implementa la estructura pipeline del anillo por lo tanto interesa que los datos se lean y se envíen en ráfaga (Burst). Esto se consigue realizando una primera lectura de la FIFO bypass, y a continuación leyendo 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 diagrama veremos el estado BP_PAUSE. A este estado viaja el bloque Tx Bypass cuando se habilita la señal que indica que hay una compensación de clock en el enlace Aurora.
INTERFAZ DE RED AER-RT
49
Figura 4.15: Diagrama de estados Tx Bypass
Cuando se activa la compensación de clock, la señal RDY se pone a cero para indicar que no se pueden transmitir datos a partir de ese momento hasta 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 tipo Start 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 de Input FIFO y de enviarlos hacia el bus AER-RT. Hay 2 diferencias fundamentales con Tx Bypass. 1. Lo que se lee de la FIFO son datos crudos no paquetes AER-RT. Por lo tanto a los datos leídos hay que añadirle la cabecera AER-RT antes de enviarlos a través del anillo.
INTERFAZ DE RED AER-RT
50
Figura 4.16: Diagrama de estados Tx Start
2. Sabemos según el protocolo establecido en la comunicación con el sistema multiprocesador, que al comenzar la fase de distribución de spikes todos los datos ha transmitir ya han sido escritos en la FIFO de entrada. Por lo tanto al terminar de leer la FIFO de entrada y de transmitir los 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 la pérdida de alguno de los paquetes IDLE no es crítica. Por lo tanto no es necesario realizar handshake con Tx controller para asegurar que no se pierde ninguno 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 posibilidad 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 mediante tres interruptores cual de los bloques de transmisión queremos activar. En la tabla 4.2 tenemos los códigos necesarios para activar cada uno de los bloques
INTERFAZ DE RED AER-RT
Figura 4.17: Diagrama de estados Tx Data
Figura 4.18: Diagrama de estados Tx Finish
51
INTERFAZ DE RED AER-RT
52
Switch
Modo
000
F_gen/F_check
001
Bypass
010
Sync
011
START
100
Data
101
Finish
110
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 permitiendo identi car qué tipos de paquetes o que fase de funcionamiento es la que produce algún error. Es una forma de aislar errores muy e caz en un sistema tan complejo. El código 000 del modo Debug es una con guración extra que sólo se utiliza para depuración. Permite que en el chip seleccionado se generen datos pseudo-aleatorios. En AER RX a su vez hay un bloque, que igualmente sólo se usa en depuración, que comprueba si se ha perdido alguno de los datos pseudo-aleatorios. De esta forma podemos comprobar la calidad del enlace. Por ejemplo una con guración muy útil es poner uno de los chips en Modo 000 y los demás en modo Bypass. De esta forma podemos comprobar la calidad del anillo monitorizando si se pierde algún paquete. De hecho hay múltiples posibilidades de depuración combinando anillos con diferente 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 al comprobar empíricamente que en el enlace se producían errores. Eran errores de 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 no aparecen.
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_done que se envían hacia AER_TX AER Con g. De este bloque se obtienen los parámetros de con guración y las entradas de habilitación del modo Debug. Los principales parámetros de con guración en cada chip son: chip-id, Ring_size y Modo_debug AER Error. Este bloque se encarga de comprobar que no se han perdido datos durante la distribución de spikes. Comprueba que todos los paquetes de datos que genera un determinado chip llegan de nuevo al chip a través del anillo. No se garantiza el contenido de los paquetes de datos Contadores de paquetes AER-RT. Es muy útil tener la posibilidad de monitorizar los tipos de paquetes que llegan al receptor. La manera más e ciente de realizar esta monitorización es mediante contadores de 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 de distribución de spikes. Lo hace contabilizando paquetes de sincronización y lo indica activando la señal interna de control AER_on
53
Figura 4.20: Diagrama de bloque AER RX
54
INTERFAZ DE RED AER-RT
55
2. Guardar el chip-id de cada ráfaga de datos que recibe. Lo hace guardando el chip-id de los paquetes de control START 3. Detectar el nal de la fase de distribución. Lo hace detectando el último paquete de control de FINISH, y lo indica activando la señal interna de control AER_done 4. Contabilizar e identi car los paquetes que se reciben. Lo hace mediante el uso de contadores 5. Filtrar los paquetes que se tienen que retransmitir. Lo hace mediante el bloque Filtro Bypass 6. Filtrar y desencapsular los paquetes de datos que se envían al sistema multiprocesador. Lo hace mediante el bloque Filtro AER RX Para realizar todas estas funciones nos valemos de señales de detección de diferentes tipos de paquetes. Es decir, tenemos una señal valid que nos indica que se ha recibido un paquete; Y además tenemos las señales de detección de tipo de paquete, que se activarán según el tipo de paquete recibido, Y señales de detección de paquete propio que se activarán si recibimos un paquete con nuestro chip-id. Utilizando estas señales de detección construimos una serie de bloques que 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 una red con 2 nodos y la transmisión de un spike por parte de cada nodo. En este cronograma los puntos 1 y 2 (en rojo) señalan el inicio y el nal de la fase de distribución respectivamente. 1. se genera AER_on al recibir los paquetes de sincronismo. En este caso se 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 y data de cada chip. Y como los datos del propio chip se distinguen activando la señal own_data_detected.
INTERFAZ DE RED AER-RT
56
Figura 4.21: Cronograma AER RX
4.5.3.
Detector de paquetes
Según la cabecera que contenga el paquete recibido activaremos la señal de tipo de paquete recibido que corresponda. Tenemos las siguientes señales que indican que el paquete recibido es de un tipo o otro: detect_sync. Indica que se ha recibido un paquete de sincronismo. Se utiliza en la generación de AER_on detect_start. Indica que se ha recibido un paquete de start. Se utiliza para detectar paquetes de datos propios. En concreto para guardar el chip-id asociado a una determinada ráfaga de datos detect_data. Indica que el paquete recibido es de datos. Se utiliza en el ltro de salida. También se utiliza para detectar datos propios. detect_ nish. Indica que se ha recibido un paquete de nish. Se utiliza en 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 detect_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 momento de recibir un paquete de tipo START, y además el campo chip-id de ese paquete corresponde con el chip-id del chip receptor, sabemos que los datos que recibiremos a continuación serán datos propios.
INTERFAZ DE RED AER-RT
57
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 de paquetes que se recibe en el receptor. Contador de paquetes de sincronismo (cont_sync). Se utiliza en la generació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 generació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 utiliza en el control de errores, al comparar este contador con el contador de paquetes 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ón de spikes en AER_TX comienza cuando recibe AER_on a nivel alto. Como podemos apreciar en el diagrama de estados de la gura 4.23, AER_on
INTERFAZ DE RED AER-RT
58
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úmero de paquetes de sincronismo recibidos es mayor que el número de nodos en la red menos 1. Como en el diseño nal cada chip envía dos paquetes de sincronismo comparamos que el contador sea mayor que 2*N -1. Para que el contador esté actualizado en el momento de la comprobación, la señal de detecció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 el contador 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 comprobación, la señal de detección de FINISH se retrasa 2 ciclos de reloj mediante registros.
4.5.7.
Filtro Bypass (o escritura en FIFO de todos los paquetes a retransmitir)
Este bloque se encarga de escribir en la FIFO Bypass FIFO los paquetes, tanto de datos como de control, que hay que retransmitir. Hay que diferenciar qué paquetes hay que retransmitir y qué paquetes mueren en este punto. De ésto se encarga el ltro. Por norma general todos los paquetes propios, tanto de datos como de control mueren en este punto y por lo tanto no se retransmiten. La excepción son los paquetes de tipo IDLE que nunca
INTERFAZ DE RED AER-RT
59
se retransmiten, sean propios o no. Por lo tanto este bloque escribe los paquetes recibidos en la FIFO de bypass, siempre que no sean paquetes de tipo own_data, own_ctrl o idle.
4.5.8.
Interfaz de salida AER_RX (o desencapsulación de los paquetes de datos)
Este bloque se encarga de generar la salida que conectará con el sistema multiprocesador. Por lo tanto debemos enviar cada spike de datos con su correspondiente 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 sistema multiprocesador Para obtener el chip-id de cada ráfaga de datos utilizamos el bloque chipid_extractor. Este bloque se encarga de actualizar el registro que contiene el 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 los datos y el chip-id y activamos la señal de validación del interfaz AER de recepción. El bus de datos de recepción es un bus de 18 bits (11 bits de datos + 7 bits de chip-id)
4.6. Bypass FIFO Este bloque se encarga de almacenar los datos que se han de retransmitir. AER RX escribe los paquetes recibidos que se han de retransmitir en su 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 RX pone un paquete para retransmitir, AER-TX está listo para hacerlo. Por lo tanto tiene que existir la posibilidad de que los datos se mantengan durante un cierto tiempo en la FIFO. La elección del tamaño de la FIFO es muy importante. No debemos excedernos en su tamaño ya que desperdiciaríamos recursos, pero tampoco quedarnos 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 seguridad de no perder datos. Elegimos una profundidad de 1024 palabras.
INTERFAZ DE RED AER-RT
60
Figura 4.24: Bypass FIFO Xilinx IP Core
Utilizamos el IP Core de Xilinx FIFO Generator para implementar la FIFO Bypass FIFO (en la gura 4.24 se puede ver la con guración del IP Core).
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 los diferentes parámetros de con guración desde una aplicación en el PC. El procedimiento consiste en mapear en la memoria de el interfaz ethernet los registros de con guración. Alternativamente a la hora de depurar el funcionamiento del sistema AER_RT podemos con gurar los diferentes valores de con guración mediante interruptores externos. Ahorrándonos así la necesidad de incluir el
INTERFAZ DE RED AER-RT
61
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ón aislado del sistema principal, permite exibilidad en cuanto al método que se utilizará para actualizar estos registros. De esta forma la decisión de cómo se con 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 se ha puesto la variable genérica ONLY_SIM, que en caso de valer '1' indica que 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 en simulación, permitiendo ahorrar tiempo y centrar esfuerzos en depurar el funcionamiento del protocolo.
4.8. AER Error Este bloque se encarga de comprobar si se ha perdido algún paquete de datos en la fase de distribución. Para ello nos valemos de una de las características del sistema AER-RT: Todos los datos generados por un determinado chip viajan por el anillo hasta que regresan a ese mismo chip. En el momento de regresar es cuando mueren y no continúan desplazándose por el anillo en una nueva vuelta. Esta característica permite que cada chip pueda comprobar si alguno de los paquetes que él genero se ha perdido durante su transmisión a través del anillo. Si uno de los chips detecta pérdida de paquetes se lo indicará al sistema 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 paquetes perdidos en cada ciclo. El mecanismo para detectar una pérdida de paquete es muy sencillo. En Transmisión (AER TX) tenemos un contador que contabiliza todos los paquetes 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 es diferente se genera un pulso en la señal AER_error, y además se resetean los dos contadores. Este sistema permite saber si se ha perdido algún paquete, pero no asegura la integridad de los datos contenidos en cada paquete. La integridad de los datos se podría controlar añadiendo el checksum de los paquetes de datos en transmisión y comprobándolo en recepción.
INTERFAZ DE RED AER-RT
62
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 con extensión .sdf . Este chero se obtiene al realizar el Place and route con las herramientas 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 sobre 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 retardos es imprescindible incluir el atributo keep hierarchy en el código VHDL de cada modulo VHDL que se quiera veri car en simulación. De esta forma las señales resultantes para simulación mantienen una jerarquía, lo que facilita la localización de las señales a depurar. En caso contrario en un diseño grande es sumamente engorroso manejar todas la señales sin estructura jerárquica.
5.2. Medidas de latencia para diferente número de nodos y diferente número de spikes En este apartado se obtiene la latencia de nuestro sistema. La latencia equivale al tiempo que emplea el protocolo AER-RT en realizar la fase de distribución de spikes. La latencia se divide en 1) Fase de sincronización y 2) Fase de distribución. Para obtener la latencia del sistema se han realizado múltiples medidas.
5.2.1.
Medidas anillo un nodo
En primer lugar realizamos medidas de latencia en un anillo con un sólo nodo. El número de spikes que genera el sistema MP lo variamos de 0 hasta
63
INTERFAZ DE RED AER-RT
64
Spikes/chip
Fase Sinc. (en ciclos de reloj)
Fase Distr. (en ciclos de reloj)
0
43
45
1
43
49
5
43
53
10
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. Hemos normalizado las medidas para mostrarlas en función de ciclos de reloj y no de tiempo absoluto. Las medidas absolutas dependen de la frecuencia de reloj que 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 gura 5.1 y 5.2 podemos apreciar el cronograma de un ciclo AER-RT al transmitir uno y 10 spikes respectivamente.
A partir de estas medidas generalizamos la latencia para un anillo de un nodo mediante las ecuaciones 5.1 y 5.2. Donde s es el número de spikes que se 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)
INTERFAZ DE RED AER-RT
65
Figura 5.2: Latencia en anillo de un nodo transmitiendo 10 spikes Spikes/chip
Fase Sinc. (en ciclos de reloj)
Fase Distr. (en ciclos de reloj)
0
83
84
1
83
88
5
83
92
10
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 red con dos nodos, donde el número de spikes que transmite cada nodo o chip puede variar. En la tabla 5.2 tenemos medidas de latencia normalizada para diferente número de spikes por nodo. En las guras 5.3 y 5.4 tenemos el detalle de las medidas cuando se realiza transmisión de 1 y 10 spikes en cada chip respectivamente. A partir de estas medidas obtenemos la expresión de la latencia en un anillo de dos nodos (ecuación 5.3 y 5.4). Donde s es el número de spikes transmitidas por nodo.
Tn=2 [ciclos] [s = 0] = 83 + 84
(5.3)
Tn=2 [ciclos] [s > 0] = 83 + 88 + (s − 1)
(5.4)
INTERFAZ DE RED AER-RT
66
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
INTERFAZ DE RED AER-RT
67
Spikes/chip
Fase Sinc. (en ciclos de reloj)
Fase Distr. (en ciclos de reloj)
0
120
121
1
120
125
5
120
129
10
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 encontramos en la tabla 5.3. Y el detalle de las medidas para transmisión de 1 y 10 spikes por nodo lo encontramos en las guras 5.5 y 5.6. A partir de estas medidas obtenemos en la latencia en un anillo de 3 nodos (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 la latencia para un sistema AER-RT con N nodos o chips. La expresión que
INTERFAZ DE RED AER-RT
68
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 encontramos en la ecuación 5.10. Donde s es el número de spikes transmitidas por nodo, y N es el número de nodos en el sistema. La expresión es aproximada (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 como hemos visto; y 2) La latencia puede variar algunos ciclos en cada nueva fase AER-RT debido a el efecto de la compensación de reloj que se produce en el enlace Aurora.
TAER−RT [ciclos] = TSY N C + TDIST RIB
(5.7)
TSY N C [ciclos] ∼ = 40 ∗ N
(5.8)
TDIST RIB [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úmero de nodos del sistema, por lo que se demuestra que el sistema es totalmente escalable: La pérdida de prestaciones al aumentar el número de chips del sistema es lineal.
INTERFAZ DE RED AER-RT
69
5.4. Área utilizada A continuación se presenta un resumen de la utilización de recursos lógicos 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 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 Number used as logic: 507 out of 203,800 Number using O6 output only: 250 Number using O5 output only: 68 Number using O5 and O6: 189 Number used as ROM: 0 Number used as Memory: 54 out of 64,000 Number used as Dual Port RAM: 0 Number used as Single Port RAM: 0 Number used as Shift Register: 54 Number using O6 output only: 46 Number using O5 output only: 0 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
1%
1% 1%
1%
La utilización de recursos es muy baja lo que con rma la viabilidad de implementar 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 para mapear 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 trabajo que admite el sistema AER-RT. Este informe lo genera la herramienta de síntesis y rutado de Xilinx que se utiliza para implementar el diseño. Y se basa en información de retardos en los caminos más críticos del sistema.
Timing Summary: --------------Speed Grade: -2
INTERFAZ DE RED AER-RT
70
Figura 5.7: Estimación de consumo AER-RT
Minimum Minimum Maximum Maximum
period: 2.704ns (Maximum Frequency: 369.790MHz) input arrival time before clock: 0.344ns output required time after clock: 1.023ns combinational path delay: 0.000ns
Se puede concluir a partir de estos resultados que el sistema permite trabajar a altas frecuencias (hasta 369 MHz). En la versión de AER-RT probada con SNAVA se trabaja a frecuencias de 125 MHz ya que es la máxima frecuencia a la que trabaja SNAVA. Si en un futuro SNAVA optimiza su arquitectura para trabajar a frecuencias más elevadas el interfaz de red AERRT 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 interfaz de red AER-RT. Vemos que el consumo total es de 524 mW. Destacar que prá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 se construye una red SNN con tres chips. El sistema MP que se utiliza para esta prueba es un bloque que emula el comportamiento de SNAVA. Para tener una veri cación realista el emulador de SNAVA este bloque trabaja con un reloj físicamente diferente al que utiliza AER-RT, de esta manera tenemos dos dominios de reloj. En las guras 6.1 y 6.2 se presentan dos fotos del sistema físico con el que se han realizado las pruebas. Cada una de las placas de evaluación que se ve en las fotos es uno de los nodos del sistema AER-RT. En este caso tenemos tres chips o nodos. El chip superior tiene el chip-id 0, el del medio el chip-id 1 y el inferior el chip-id 2. El esquema de conexión es similar al que se presentó en la gura 3.2 de la sección 3. Los puertos de transmisión y recepción son diferenciales, de esta forma se consigue una señal más robusta y resistente a interferencias. En la gura 6.3 tenemos una instantánea del analizador lógico virtual de Xilinx conectado al chip con chip-id 0. En ella vemos la evolución de las diferentes señales internas del sistema AER-RT. De todas ellas nos jaremos en las que están resaltadas en rojo. A continuación describimos la función de estas señales en términos generales: AER_tx_wr_i es la señal de habilitación de escritura del interfaz AER TX. Indica escritura de spike en FIFO de entrada para su posterior transmisió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 de ejecución
71
INTERFAZ DE RED AER-RT
72
Figura 6.1: Sistema AER-RT + emulador de SNAVA implementado en tres Kintex-7
INTERFAZ DE RED AER-RT
73
Figura 6.2: Detalle conexiones en sistema AER-RT + emulador de SNAVA implementado en tres Kintex-7
INTERFAZ DE RED AER-RT
74
aer_on_i es una señal interna del sistema AER-RT que indica n de la 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 n de 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. Indica dato 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 el viaja el chip-id aer_rx_data_2 son los bits de menos peso del bus de recepción. En el viajan los spikes Para facilitar la comprensión hemos numerado (en rojo) los diferentes acontecimientos que se pueden observar en la captura de pantalla de la gura 6.3: 1. El emulador de SNAVA escribe en la FIFO de entrada los spikes a distribuir, en este caso son 7 spikes 2. El emulador de SNAVA, una vez escritos los spikes, activa la señal de AER_eo_exec. En este punto comienza un ciclo AER-RT que como sabemos 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 sincronizació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 que han generado todos los chips que forman el anillo, incluido él mismo. Vemos un tren de tres pulsos, estos pulsos habilitan los spikes recibidos de cada chip. En primer lugar nos llegan los 7 spikes del chip 1, a continuación los 7 spikes del chip 2 y nalmente los 7 spikes generados por el chip 0 (es decir nosotros mismos) 5. Finalmente cuando se reciben todos los paquetes FINISH de todos los chips se activa la señal interna AER_done que indica que el ciclo AER-RT ha nalizado
INTERFAZ DE RED AER-RT
75
Figura 6.3: Detalle de señales en el chip 0 tomadas con el analizador lógico virtual de Xilinx
INTERFAZ DE RED AER-RT
76
Capítulo 7
Conclusiones A nivel personal ha sido un proyecto largo y complicado pero muy interesante. Me ha permitido trabajar con señales serie de alta velocidad en FPGA, que es un tema que está bastante de actualidad en la industria. A nivel de diseño digital me ha permitido adquirir soltura a la hora programar en VHDL. Además de profundizar en el manejo de herramientas avanzadas para la simulación y síntesis de circuitos digitales.
Una de las lecciones importantes a nivel de diseño, y que menciono en el capítulo de arquitectura, es la importancia de crear un diseño modular desde primeras etapas en el diseño. Este enfoque facilita la modi cación y depuración del sistema enormemente.
A nivel más práctico de resultados el objetivo que nos propusimos al principio del proyecto se ha conseguido. Hemos creado un interfaz de red multi-chip e ciente y escalable.
Tan e ciente que el cuello de botella que introducía el interfaz de red previo ha desaparecido, ahora el interfaz de red puede trabajar a frecuencias iguales o incluso superiores que el sistema MP.
El interfaz diseñado permite que el sistema crezca en número de chips de manera fácil. Tan fácil como con gurar dos parámetros en cada chip: chipid y Ring_size que indican la identi cación de cada nodo en el anillo y el tamaño del anillo respectivamente. El sistema ha sido probado en un anillo de hasta 4 chips con éxito.
A continuación, como medida del nivel de escalabilidad que puede alcanzar el interfaz AER-RT, me gustaría demostrar la viabílidad de un sistema de hasta 4 millones de neuronas. El hecho de tener hasta 15 bits disponibles en los paquetes de datos nos permite una escalabilidad en número de neuro-
77
INTERFAZ DE RED AER-RT
78
nas por chip de hasta 32768. Con 7 bits para el chip-id podemos direccionar hasta 128 chips dentro del mismo sistema. Si hacemos cuentas esto supone la capacidad de implementar un sistema de hasta 4194304 neuronas. Calculamos la latencia de esta teórica red SNN con 4 Millones de neuronas y comprobamos que el requisito de no superar un tiempo de 0,5 ms se cumple ampliamente. La latencia es de 75,77 us, tan solo un 15 % de la máxima latencia permitida. En la ecuación 7.1 se muestran las operaciones realizadas. Como hacíamos en el capítulo de diseño suponemos que la frecuencia de generación de spikes es de 15 spikes cada 100 neuronas. Por lo tanto si cada chip tiene 32768 neuronas ésto hace un valor de 4915 spikes generados en cada chip (s en la ecuación). N hemos dicho que es 128 chips y la frecuencia la ponemos a 200 MHz que es una frecuencia razonable de trabajo.
T = [40 ∗ N + 40 ∗ N + (s − 1)] ∗
1 = 75, 77us f
(7.1)
s [spikes/chip] = 4915
f = 200M Hz N [chips] = 128 El otro objetivo que era ser adoptado por SNAVA como nuevo interfaz de red también se ha cumplido. El sistema se ha probado en un sistema de 2x2 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 el interfaz AER-RT de manera no muy complicada y que se mencionan en este documento. 1. Dotar a el interfaz de red AER-RT de jerarquía. Una primera aproximación consistiría en diferenciar entre transmisión de spikes locales y transmisión de spikes globales. Por lo tanto estableceríamos una red de 2 niveles de jerarquía. El nivel global sería el anillo tal como está implementado actualmente. Y el nivel local consistiría en transmitir los spikes locales dentro del mismo chip, sin necesidad de distribuirlos a través del anillo. De esta manera se mejoraría la e ciencia en función de la localidad de las neuronas en un determinado chip.
INTERFAZ DE RED AER-RT
79
2. Añadir una nueva prestación en el control de errores. Comprobar, no solo que no se pierdan paquetes de datos como se hace hasta ahora, sino también la integridad de los datos recibidos. La forma más sencilla de implementarlo sería añadiendo el checksum de los datos a los paquetes de datos que se transmiten. Una vez en recepción se compararía si el checsum calculado en recepción coincide con el de transmisión. En caso a rmativo podemos asegurar que todos los datos recibidos son correctos y en caso negativo sabemos que hay datos corruptos.
INTERFAZ DE RED AER-RT
80
Bibliografía [1] PERPLEXUS project, Contract no. 34632. Project reference TEC200806028/TEC [2] Javier Iglesias. Emergence of Oriented Circuits driven by Synaptic Pruning associated with Spike-Timing-Dependent Plasticity (STDP). Tesis de Doctorado, 2005 [3] Moreno, J.-M.; Fernández, D.; Kotynia, L., "Synchronous Digital Implementation of the AER Communication Scheme for Emulating LargeScale Spiking Neural Networks Models," Adaptive Hardware and Systems, 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 Complex Neural Bioinspired Applications AHS; Proceedings of the 2009 NASA/ESA Conference on Adaptive Hardware and Systems, pp. 376381. Moscone Convention Center, San Francisco, California, USA, July 29 August 1, 2009.
http://www.xilinx. com/support/documentation/ip_documentation/aurora_8b10b_ protocol_spec_sp002.pdf
[5] Aurora
8B/10B
Protocol
Speci cation.
Link:
http: //www.xilinx.com/support/documentation/ip_documentation/ aurora_8b10b/v8_3/pg046-aurora-8b10b.pdf
[6] LogiCORE
IP
Aurora
8B/10B
v8.3
Product
Guide.
Link:
[7] High-Speed Serial I/O Made Simple A Designers' Guide, with FPGA
http:// www.xilinx.com/publications/archives/books/serialio.pdf Applications. Abhijit Athavale and Carl Christensen. Link:
[8] KC705
Evaluation
Board
for
the
Kintex-7
FPGA
User
Gui-
http://www.xilinx.com/support/documentation/boards_ and_kits/kc705/ug810_KC705_Eval_Bd.pdf de. Link:
[9] 7
Series
FPGAs
GTX/GTH
Transceivers
User
Guide.
Link:
http://www.xilinx.com/support/documentation/user_guides/ ug476_7Series_Transceivers.pdf
81
INTERFAZ DE RED AER-RT
82
[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, and optimization. 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