Motivation

Most of us use multineuron chips and sensors in our research, and to do so develop custom software according to our requirements. As things stand now, every lab develops its own software infrastructure. A lot of effort goes into developing the AER interfacing software, spike management and setting biases and displaying data. With the growing number of labs and groups working on these devices, there is tremendous duplication of effort apart from the diverse software packages developed.

We propose to gather, discuss and present software that already exists. We further propose the possibility of standardizing the software modules in use and move towards a unified open-source software. The motivation behind this effort is to provide easy accessibility to neuromorphic hardware, prevent duplication and benefit from the community of developer users and non-developer users as well. In addition, a shared approach over usability of neuromorphic hardware will possibly steer the hardware developers community towards the contruction of compatible devices, increasing the possibilities of adoption of such devices in real applications.

The Capocaccia CNE workshop offers a unique and exiting opportunity to sit together and discuss this topic. We hope that this year discussions will pave the way for a fruitful and continuous communication between communities also after the end of the workshop in order to possibly have a proper Workgroup session on next year workshop.

Existent software

The CNE workshop offers a unique opportunity to exchange ideas with the first-line developers of the most used software packages for hardware based neural networks and software simulators. We will outline some of the key features of the different approaches so that people willing to participate to the discussion sessions will have some background.

pyNCS

pyNCS is a set of python modules that permit interaction with real-time spiking neuromorphic hardware. It aims at easy of use and extreme modularity.

• Institute of Neuroinformatics, Zurich (CH)
• Grants: Scandle, SoundRec?

pyNN

PyNN (pronounced 'pine' ) is a is a simulator-independent language for building neuronal network models. The PyNN API aims to support modelling at a high-level of abstraction (populations of neurons, layers, columns and the connections between them) while still allowing access to the details of individual neurons and synapses when required. The absatraction layer provided by pyNN permits control of neuromorphic hardware aiming at large-scale, fast simulation of neural networks.

• Ruprecht-Karls-Universität, Heidelberg (DE)
• Grants: FACETS

jAER

jAER is a set of Java tools for Address-Event Representation (AER) neuromorphic chips: monitoring, sequencing, rendering, logging, and processing events. jAER has a really nice interface to offline or online process AER data using filters.

• Institute of Neuroinformatics, University of Zurich and ETHZ, Zurich (CH)
• Main developer: Toby Delbruck

Software simulators and data-processing modules

The ease of programming of python based software simulators gives the possibility to write wrappers or modules to interface the scripting layer to neuromorphic hardware instead of using the simulator engine. This is the case of Brian software simulator, for example. It is important to coordinate with already existing interfaces to understand how to efficiently interface neuromorphic chips (sensors or computational modules) to the software flow.

Brian

Brian is a simulator for spiking neural networks available on almost all platforms. The motivation for this project is that a simulator should not only save the time of processors, but also the time of scientists.

• Département d’Informatique, École Normale Supérieure, Paris (FR)
• Romain Brette and Dan Goodman

mdp

From the user’s perspective, MDP is a collection of supervised and unsupervised learning algorithms and other data processing units that can be combined into data processing sequences and more complex feed-forward network architectures.

From the scientific developer’s perspective, MDP is a modular framework, which can easily be expanded. The implementation of new algorithms is easy and intuitive. The new implemented units are then automatically integrated with the rest of the library.

We put this software here because it would be interesting to keep in mind its approach while developing cortical-like processing models using neuromorphic hardware. Unfortunately there are no developers from the mdp team in Capocaccia. Informations on mdp  here.

Thoughts

Modularity

Real-time hardware aims at the possibility of embedding neuromorphic devices on behaving robots. On the implementation side, this implies high modularity in order to be able to easily interface to new hardware. What is the best solution for that? The pyNCS approach uses text files for the definition of the architecture of the chips so that the system knows how to communicate with the drivers and translate the AER events. On the other hand, the pyNN approach aims at complete abstraction of the neuron models implemented in hardware. Can we move further?

Ease of use

Most of the packages out there are now very ease to use. They share a common structure: build populations, connect, do something. There are technical distinction that we could discuss which are important for developing the interfacing with the low-level drivers.

Communication

AER is widely adopted, no discussion about other techniques, but which hardware interface? We propose the AEX interface from Daniel Fasnacht which is the results of many discussions through other CNE workshops and Telluride workshops over the past years. To discuss this in more detail we suggest to subscribe to Asynchronous Infrastructures for AER

Parameters

Parameters we set on the software are not exactly reproduced by the hardware because of the intrinsic mismatch of the chip fabrication. There are several approach that aim at solving or working-around the problem of this, namely parameter translation. A black-box approach permits to interface to unknown hardware without knowing all the technical details of it. A calibration based approach instead permits a faster configuration of parameters once the calibration has been performed. Can we move further?

Report

After two meetings, the participating communities, mainly Heidelberg (FACETS/BrainScaleS) and INI Zurich (SCANDLE/SoundRec), where able to spot a set of problems which is common to a large part of the neuromorphic engineering community, which relates to the need of a standardized description of neuromorphic devices. Here we describe the thoughts that have been exposed during the worshop.

Motivation

Neuromorphic engineers propose a wide range of useful devices in the attempt to solve various task that traditional technology cannot. Most often these devices come with special features that make them unique and this forces a group of researchers to develop specific software to configure the hardware and interface it to neural network definition packages, e.g. pyNN. This costs the group large efforts in building software modules that are only partially different from the ones that have been already proposed, without being able to re-use large pieces of code already written. In addition, the diversity of software modules for hardware configuration inhibits the exchange of ideas between neuromorphic communities, mainly because of the impossibility to exchange pieces of code. This problematic is similar to what graphics boards manufacturers faced when GPU technologies where becoming widely adopted, and GL/OpenGL libraries have been proposed.

Spotting the problem

In a general experiment with neuromorphic devices, the user interface let the reseracher define the topology of the neural network and its parameters. The interface interfaces to the hardware translating the definition informations in hardware parameters, with regards to topology, connectivity and so on. At the drivers level, the hardware definitions interface to the devices for the actual setting of parameters and the communication.

At the definition level there have been several efforts by the different community of neuromorphic engineers to provide a common interface capable of cover the widest possible range of possibilities. One of the most successful examples is pyNN, which provides functionalities for the definition of neural networks with arbitrary topologies.

As mentioned above, pyNN has been developed with the purpose of providing a software-simulator-independent package that let the user define arbitrarily complex neural networks and than switch between software simulators in order to choose the one that suits best the specific problem (in terms of speed of computation or memory efficiency and so on).

Even though there have been efforts to control neuromorphic hardware with pyNN, the lack of a common solution for the description of device-specific capabilities imposes the researchers to write their own device-specific software modules, which then need to be described by a second software module at the level of the biological-description in a way that pyNN can understand. This limits the appealing of such an interface to the community of hardware developers who prefer to leave the duty of implementing these software modules to the users, who obviously have less knowledge about the features of the hardware devices.

Several communities share similar problematics in this respect. While the 'real-time community' sees the flexibility of implementation above as a 'conditio sine qua non' for the development of their system, other communities too are facing the problem of 'mapping' the description of the neural network into hardware parameters.

We think that this mapping is the core of the problem here and as a community the different groups of researchers should spend efforts in solving this limitation by agreeing on a standard format for the description of hardware architectures.

Conclusions and proposed actions

The discussion group of Capo Caccia CNE 2011 proposes to develop a standardized description of neuromorphic devices, in the form of XML markup language file, collecting the biological and non-biological, device-specific information about the neuromorphic hardware. For example, this description would include the total number of neurons on a device, the modeled neuron, the parameter translation from physical quantities (e.g. time constants) and hardware parameters (e.g. biases), but also the informations about specific hardware controls such as output buffers, communication controls, and so on.

We promised to create a source of information on the web to let every group of neuromorphic engineers share their views on the problem and propose methods to solve it. The webpage will be a container for the different solutions that researchers came up with until now. This will the chance for every neuromorphic engineer to share an XML template that he thinks best represent their neuromorphic hardware. We will encourage participants to be actively participating in the discussions to come by being ourselves active parts of these discussions.

The webpage will be initially hosted in the pyNN website. We think that the pyNN community has enough momentum to attract neuromorphic hardware and software developers and constitutes a solid basis of software modules which can be adapted and expanded to include hardware interfaces.

We think that these actions create the basis for the long-term goal of defining a new standard for the description of neuromorphic devices. We wish to pave the way for a wide-range usability of neuromorphic devices as information processing units and computational modules in several applications.

Name Proposals for the Neuromorphic Hardware Markup Language

Here is a list of proposed names. You can add your proposal until Monday 30th of May. We will then set up a new doodle poll with all proposals with 3 options (yes, ifneedbe, no), so that you can also make negative votes.

• neuromorphicML
• norML - NeuromORphic Markup Language
• NML Neuromorphic Markup Language
• NMML NeuroMorphic? Markup Language
• AbNorML - Abstract Neuromorphic Markup Language
• NORMAL - NeuromORphicMArkupLanguage
• NHML - Neuromorphic Hardware Markup Language
• NMHML - NeuroMorphic? Hardware Markup Language
• NHDL - Neuromorphic Hardware Description Language
• NerDL - Neuromorphic Description Language
• NArLi - Neuromorphic Abstract Lingo
• GNArL - Generalized Neuromorphic AbstRaction? Language
• dirndl - Device-Independent neuRoNal hardware Description Language
• SNArL - Simplified Neuromorphic AbstRaction? Language
• HANDLE - Hardware Abstraction aNd Description LanguagE
• HANDL - Hardware Abstraction aNd Description Language
• ANhAL - A Neuromorphic hardware Abstraction Language
• Kevin - a nice name, don't you think?
• OpenNL - Open Neuromorphic Libraries (following OpenGL)