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

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.
Deniciones . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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.
Conguració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 Cong . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 simplicado
4.2.
Versión denitiva 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 ecient 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 deciè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'eciència
i l'escalabilitat del sistema global.
La interfície de xarxa dissenyada introdueix dos canvis que son clau per
millorar l'eciè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 eciente 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 deciencias 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 eciencia y escalabilidad del
sistema global.
El interfaz de red diseñado introduce dos cambios clave para mejorar la
eciencia 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 ecient
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 ecient 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. Deniciones
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 justicada.
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 eciente 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órcas. 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 decodica 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 dicultades 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 simplicar 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 insuciente para distribuir todos los spikes que genera un sistema SNAVA multichip de manera eciente. 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 eciente 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 eciencia 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 eciente y
escalable.
Características a optimizar con el diseño del interfaz de red AER-RT:
Eciencia
Escalabilidad
Un interfaz de red eciente 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 modica 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. Vericació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 verica 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 eciencia 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 simplicamos 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
denido 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 innito 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 inuye 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árquica = M AX(Tlocal , Tglobal )
(2.7)
Tjerárquica = 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 eciencia 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 signicativo en Hardware adicional (repetidores). La topología punto a punto o en malla tiene la mejor eciencia 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 eciencia 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
eciente. 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
Dicultad 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 eciente 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]:
Inniband
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, codicació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 eciencia
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é identicado con un
identicador de chip que denominamos chip-id
El interfaz entre AER-RT y el sistema multiprocesador (puede ser
SNAVA u otro) está perfectamente denido 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 conguració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 eciencia 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
identicaremos 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 denido 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 simplicado del interfaz
AER-RT.
Como se puede apreciar en el esquema simplicado 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 simplicado
30
Figura 4.2: Versión denitiva 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 Cong se encarga de guardar los parámetros de
conguració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 identicar 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 noticarle 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á
denida 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 conguració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 simplicar 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 conguració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 conguració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 identicamos 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 congurar 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 codicar.
GT REFCLK: Frecuencia del Clock que utiliza el transceiver.
El Core tiene las siguientes características de funcionamiento:
Dataow 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.
Conguración utilizada
La conguració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 congurado 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 conguraciones 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 Cong. De este bloque se obtienen los parámetros de conguración y las entradas de habilitación del modo Debug. Los principales
parámetros de conguració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
modicar el protocolo y mayor robustez a la hora de identicar 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 identica
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 modicaciones 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 identicar qué tipos de paquetes o que fase de funcionamiento es la
que produce algún error. Es una forma de aislar errores muy ecaz en un
sistema tan complejo.
El código 000 del modo Debug es una conguració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 conguració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 identicar 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 Cong. De este bloque se obtienen los parámetros de conguración y las entradas de habilitación del modo Debug. Los principales
parámetros de conguració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 eciente 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 identicar 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 (overow). 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 conguración del IP
Core).
4.7. AER Cong
Bloque dónde se conguran 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 congurar externamente.
Mediante el interfaz ethernet que utiliza SNAVA podemos congurar los
diferentes parámetros de conguración desde una aplicación en el PC. El
procedimiento consiste en mapear en la memoria de el interfaz ethernet los
registros de conguración.
Alternativamente a la hora de depurar el funcionamiento del sistema
AER_RT podemos congurar los diferentes valores de conguració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 conguració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
conguren los registros no interere 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 conguración se obtienen directamente por Software.
De esta manera se simplica la escritura de registros de conguració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 vericar 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 congurable.
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 dene 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
dene 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 conrma 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 vericar 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 vericació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 modicació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 eciente y escalable.
Tan eciente 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 congurar dos parámetros en cada chip: chipid y Ring_size que indican la identicació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 eciencia 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 armativo 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
Specication.
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