wiki:2015/universalaer15

How do we get AER devices to talk together?

The idea of AER has been around for a long time and most neuromorphic chips use some form of the basic technique: transmitting event packets containing the address of a neuron (or other element). But communicating between chips has always been vexed by problems of hardware pinouts, signal voltages, data encoding, and other very low-level issues. In this group we will explore an alternative method: using the existing Ethernet standards to create "plug-in" AER connectivity. Ethernet and its associated connectors, cabling, and hardware physical interfaces provide the low-level "plumbing" to avoid all the difficult issues, and then it would remain to define a "high-level" protocol that can be carried over Ethernet to transmit AER signals between devices. The crux of the approach is: use industry-standard interfaces until we are high enough that we are dealing with pure spikes.

A proposal

We offer to this workgroup a "straw man" - a protocol proposal, which we have implemented and made functional on SpiNNaker, for universal AER communications. The proposal bundles AER packets with a short standard header, allowing various "flavours" of AER packet including commands as well as bundles of events. All features are optional: users can choose to implement as little or as much of the complete feature set as their devices can support. The protocol is fire-and-forget: no device expects any response, so receivers can throw away and packets it doesn't understand. We suggest, but do not require, using UDP as the transport; with its unreliable connectionless protocol it is a good fit for a fire-and-forget system. The complete proposed specification is below.

So what do we do?

We have already linked some devices with programmable front-ends to SpiNNaker. In principle, ANY device that has an Ethernet port, uses spikes, and has enough programmability at the Ethernet side to install a simple packet decoder ought to be able to handle spikes in this format. We would like to see how many other "boxes" people bring that can be linked to SpiNNaker - or indeed to each other! That's the practical dimension.

A more open, exploratory dimension will look at what parts of the proposed protocol are suitable, with a view to crafting a standard for universal AER. The difference here is that unlike previous attempts which have been largely on-paper exercises, we can try them at CapoCaccia?. We have developed a device simulator that can emulate any flavour of packet and generate sequences of spikes, read from a file, pipe in data, and numerous other options so we can modify the simulator and the SpiNNaker implementation of the protocol to try various suggestions.

A complete tutorial on the current protocol, the SpiNNaker implementation, and the simulator will be given during the first week. Even if you're new we will provide enough information to start experimenting with external I/O. By the end of the workshop, although we don't expect to have devised a full and final specification for external AER (not by a long toss!), we hope people will have at least been able to explore the ideas: A) to link other systems together using the protocol; B) to have a list of "we need this" and "we don't need this" in an external AER protocol standard.

Meeting 1 28 April

The group met to discuss the protocol as proposed. The following observations were made.

1) Concerns arose over the possibility of expansion. For instance, what would happen if one wanted to send 128-bit addresses? It was noted that 2 reserved bits (called "Tag" in the description) could be used to support such expansion.

2) It was further remarked that these reserved bits ought to be specified as 00 in the current implementation, so that they would clearly not interfere with future versions of the protocol.

3) A second suggestion was made with respect to expansion, namely that there could be an "expansion" flag in the header, occupying one of the reserved bits, indicating that there was a second half-word (or more) of header. Such expansion flags could be chained together to create arbitrarily large headers

4) An important line of inquiry looked into the question of timestamps and how they were handled. In particular, what provision was made for synchronisation, establishment of a time reference, and time resolution. The idea in the original spec was that these would be considered device-handled at the destination, but it became clear that this would not always be adequate. It was agreed that intermediate translators at either the transmitter or receiver side should insert time stamps if required, preferably using a hardware reference. Such translation interfaces could handle the conversion between a local time referred in the time domain of the device and a global time referred in the time domain of the connection. It was also clarified that axonal delays and other forms of delay could be handled simply by inserting them as an offset to time stamps if required (that is, if the receiving device did not insert such delays automatically). One issue raised but not discussed at length is how the interface should handle timestamp rollover. In general the question of time and synchronisation remains an important issue to be addressed in forthcoming meetings.

5) The idea of probabilistic connections arose. Namely, if a device projects to possibly several independent devices with some probability of a given spike being received by each of the devices so targetted (a form of dynamic connectivity), should there be provision for this? It was agreed that this should not be the function of the specification as such and should be handled by the gateway on or connected to the device.

6) Various forms of compression were considered. The specification allows for compression through prefixes if desired, but the SpiNNaker group has also discussed a different method using command packets to specify almost arbitrary compression schemes. Indeed, many device-specific responses could be invoked using command packets as a "sideband" signalling method. However the preference of the SpiNNaker group is that packets are idempotent, i.e. all the information a receiver needs to decode the packet is contained within it and the receiver can thus be stateless. Generally however the feeling was that compression was not likely to be critical.

7) It was pointed out that over Ethernet, packets might well arrive out of order. Currently the interface specifies that the receiving device should handle packets in the order received unless timestamped - thus packets without time stamps are assumed to have spikes whose precise timing is not critical from the point of view of the receiving device. Timestamped packets can be handled according to timestamp.

8) A question was raised as to the intended purpose, scope, and performance requirements of the interface were. The original idea as expressed was that the interface should provide a facility for relatively low-speed (~10M spikes/sec max) spike communications between possibly distant systems that were not or could not be connected together directly. Lack of physical proximity between devices is one of the most important use cases for the interface.

Meeting 2 30 April

The session focussed on a proposal by Taras Iakymchuk to adapt the packet format for additional options. It was argued that the question of synchronisation could be difficult and the problems particularly of out-of-order packets could be very troublesome, if no timestamps are sent. The proposal was the following:

1) The header length is extended to 32 bits.

2) An 8-bit counter field is added, which gives the packet sequence number. This can identify out-of-order reception.

3) Support for keys, timestamps, and payloads within each spike is added. This rearranges the first byte of the header:

Bit 7 : 0 = spike packet, 1 = command packet Bit 6 : 0 = 16-bit keys (addresses) and timestamps (if any), 1 = 32-bit keys and timestamps (if any) Bit 5 : 0 = No timestamps, 1 = with timestamps Bits 4-3 : 00 = No payload, 01 = 16-bit payload, 10 = 32-bit payload, 11 = 128-bit payload ? Bit 2 : 0 = No key prefix, 1 = with key prefix Bit 1 : 0 = No timestamp prefix, 1 = with timestamp prefix Bit 0 : 0 = No payload prefix, 1 = with payload prefix

4) 8 bits reserved for future use - set to 0 (subsequently modified by the group)

The group agreed that the 32-bit extension was reasonable, with the counter and reserved bytes being considered optional In addition, Taras Iakymchuk suggested a basic command protocol - a group of essential commands that devices that support any command protocol ought to support as a minimal set. It was agreed to discuss this although no decisions were made structure of these commands at this meeting.

Claudio Luck suggested that certain protocols from the multimedia domain might be of use, but on reflection it was decided that these might add too much interface complexity.

There was an extensive discussion on timebase - the time quantum for timestamps, and start time. Person (Adrian Whatley)? indicated one particular concern - how to detect what the "stimulus onset" time was for an external spike train injected into a sending device by an experimenter was, in cases where the start-of-stimulus did not correspond to the first spike, particularly if the sending device was already sending spikes in a sparse spiking mode. After discussion it was concluded that though there were no perfect answers, command packets might be used to indicate this - perhaps with some sort of synchronisation protocol.

For this case and others, the group agreed to define one more bit of the added 16 as an extension bit - that indicates to a receiving device that there are device-specific requirements (such as e.g. response required or specific command sequences expected) that will be sent via further command packets. What commands occur are device-specific.

Meeting 3 2 May

The group held a brief meeting on 2 May to discuss the problems associated with synchronisation, packet loss, and stateful devices. It was agreed that since the basic protocol is transport-agnostic, TCP should be used when reliable transmission of packets is expected, UDP can be used when this is not required. For example reliable transmission might be required when indicating time reference start. Devices can mix protocols freely, although receivers are not required to support TCP.

Meeting 4 4 May

Further discussion related to protocol header definition.

It was suggested that IPv6 implementation http://www.embedded.com/design/prototyping-and-development/4024592/IPv6-on-a-microcontroller should be considered which already provides several features the AER protocol has been considering. Others claimed that IPv6 features are not uniformly supported or are at least stripped out in many systems. Notwithstanding either position, considerations of transport independence (the AER protocol is envisioned as independent of transport) suggest that features embedded in IPv6 should probably be for the moment retained in the specification, with the possibility of future review.

Another important consideration raised is that of security. If the protocol is to be certified for Brain/Machine? interfacing then safety & security of information that can manipulate neurons would almost certainly be required. Additional information on security is available on http://www.tcpipguide.com/free/t_IPSecurityIPSecProtocols.htm. Further discussion is required on this point and the question of whether the protocol was to be suitable for BMI has not been considered yet.

The group extensively discussed the question of extensible payload fields, particularly for the jAER system which allows arbitrary-length payloads. After considerable debate the most likely proposal appears to be the use of special payload prefix values in the header to indicate long payloads. However, the question of how to calculate the length of a packet based only on information in the AER header (again mindful that the protocol should be transport-independent and packets idempotent) remains unresolved. Further discussion is again necessary on these points.

Command protocol definition was briefly brought up but deferred until the next meeting.

Results 8 May

Following discussions the group agreed in principle to the protocol as defined in the attached document "CapoCacciaAERProposal.pdf". The question of long payloads it was decided was implementable using a special command protocol and the combination "No Payload" and "With Payload Prefix" in the header but deferred in the details to further discussion post-workshop. Also the question of command protocol definition proved unresolvable within the scope of the workshop and will be determined later. It was decided that security would not be considered in the protocol. As designed the protocol was not envisioned for system-critical applications like BMI and thus such considerations for the moment were out of scope.

Alexander Rast, Taras Iakymchuk and Damir Vodenicarevic worked together to develop a linked system using SpiNNaker, a Virtex6 FPGA board, and a silicon cochlea. By the afternoon of 8 May this was working with communication between the 3 systems over a local private network using simple packets without payloads or timestamps, and a live demo was available. Further work post-workshop will extend the connectivity to cases over the internet and refine command packets, payloads, and other details of the protocol.

Last modified 4 years ago Last modified on 05/22/15 00:29:21

Attachments (4)

Download all attachments as: .zip