menu

Universal AER Protocols for Multi-System Simulation

We have many devices out there generating and using AER packets of some form in various ways. Wouldn't it be nice if we could link them together to form larger, multi-system simulations? Up until recently, the main problem was that everyone was using a different 'flavour' of AER, with different connectors, protocols, etc. This workgroup is part of an ongoing effort to fix that.

Continuing the work from last year's CapoCaccia where we discussed and implemented a prototype for a standard, transport-independent AER protocol, we will be working with a draft version of the specification that has arisen out of this. We will continue to refine and define the draft, and we will also have available a preliminary implementation of the spec usable with the SpiNNaker platform. By the end of the workshop we will aim to have a multi-system simulation up and running and possibly some performance benchmarks as well.

Login to become a member send

Timetable

Day Time Location
Tue, 26.04.2016 15:00 - 16:00 disco
Wed, 04.05.2016 14:00 - 15:00 Disco

This workgroup as mentioned will continue the work from last year on an AER protocol. The specification Icon PRAERIE specification (168.1 KB) as defined last year specifies an unreliable 'fire-and-forget' communications link with stateless transceivers. AER 'events' are bundled into packets containing up to 256 such events. Events have any combination of address, payload, and timestamp fields, supporting 16-, 32- and 64-bit word sizes. A command protocol is also supported for tasks such as device configuration and exchange of supported features. Several global commands have been specified that are common across all devices. Others can be defined which are device-specific. A device may implement any partial part of the specification and drop any packets corresponding to formats or commands it does not support.

We will have an implementation of the preliminary specification available for use and customisation. As per previous versions it uses UDP as the transport and runs over Ethernet using standard connectors and cabling. The implementation, written in C, is separated into an interface and a device driver. We have written a SpiNNaker device driver and the code for the implementation can be used to implement your own transceiver for your own device (e.g. on a microcontroller). If you have an FPGA interface it would make a useful project to implement the transceiver on the FPGA.

There are a few issues in the specification still to be fully resolved:

1)  The complete set of standard commands;

2) Handling of time synchronisation;

3) Certain details of the protocol with respect to timestamp order within a packet.

We will aim to have these decided by the end of the first week and get on with a demo system during the second week. Our goal is by end of CapoCaccia to have a simulation linking at least an AER-generating sensor with a neural processor, and potentially more (the more AER devices the merrier!).

Accomplished by the end of the workshop:

The group interfaced with the YARP-SpiNNaker-DVS-ATIS workgroup. After some abortive attempts to use a direct link to SpiNNaker we used the universal AER protocol to effect the link and test the system for linking retina with cortical processing for orientation selectivity and disparity processing. More details will be available on the YARP-SpiNNaker workgroup page. This system substantially realises the stated goal for the workgroup above.

We resolved the queston of timestamp order and packet processing. Designers of PRAERIE interfaces should understand that if their transceiver supports reception from multiple PRAERIE devices it will need to have internal reorder buffers that inspect each event within a packet and reorder according to timestamp. This is in addition to any sequence-based reordering. It is strongly recommended that the transceiver implement a fixed time horizon for reordering. The specification has been updated to clarify that timestamp order within a packet must be strictly increasing. No device may issue sequential packets whose timestamps are not strictly increasing, e.g. a device cannot sent a packet with timestamps 1 and 3 and then a different one with timestamp 2 even if the header does not specify a sequence number.

Commands still need further discussion.

 

Leaders

Alexander Rast
Alan Stokes

Members

JUAN BARRIOS AVILES
Alexander Rast
Alan Stokes
Qi Xu