|Welcome to The Neuromorphic Engineer|
|A common language for neuronal networks in software and hardware|
PDF version | Permalink
Fast information processing in the brain is performed by the exchange of brief electrical pulses (called action potentials, or spikes) between neurons that are connected in complex networks. Models of such networks may either be simulated in software1 or implemented in VLSI hardware.2 Numerical simulation in software has the advantages of flexibility and the commodity status of digital computers, with simulations being performed on systems ranging from individual desktop machines, through clusters, up to supercomputers.3 The main advantages of physical emulation in analog or mixed-signal neuromorphic hardware arise from the locally analog and massively parallel nature of the computations together with the very small spatial scale of VLSI components. The benefits are high scalability, computational speed, and low power consumption.
Typically, specification of neuronal network models—the mechanisms of individual neurons and the pattern and properties of the connections between them—is done by editing a configuration file, using a graphical interface to set parameters, or, most flexibly, writing a script in an interpreted programming language. A major problem that impedes communication between researchers, reproducibility of results, and building upon previous work, is that each software simulator or hardware system has its own configuration format, graphical interface or special-purpose programming language. This makes the translation of a model from one system to another—and especially from software to hardware—arduous, time-consuming and error-prone.
However, the availability of multiple simulators and hardware systems has many advantages, particularly in cross-checking results and in exploiting the complementary features of different systems, e.g., the flexibility of a simulator and the speed of a hardware system. A common interface for specifying models that would work across multiple systems would retain the benefits of simulator/hardware diversity while reducing or removing the translation barrier. We have developed such a common interface, PyNN (pronounced ‘pine’) that enables simulation scripts to be run on any supported system (currently four different software simulators and one neuromorphic hardware system) without modification.
PyNN4 (available from http://neuralensemble.org/PyNN), is both an application programming interface (API) for the Python programming language5 and an implementation of the interface for a number of systems (currently the NEURON,6 NEST,7 PCSIM8 and Brian9 simulators and the FACETS neuromorphic mixed-signal VLSI system).10,11 A simulation script is written in Python, with neuronal network modelling functions and classes provided by PyNN, and optionally exploiting the extensive capabilities for numerical data analysis and visualisation available in Python or in third-party extensions such as NumPy.11 It can then be run on any supported ‘back-end’ system without modification, except for a single parameter specifying which back-end to use.
PyNN takes care of translating the neuron, synapse and network models into the required form for a given simulator, consistent handling of physical units, and consistent handling of random numbers, and provides a high-level, object-oriented interface to enable structured development of large-scale, complex models. A simple example of a network of excitatory and inhibitory neurons exhibiting self-sustained activity is shown in Figures 1 and 2.
Adding support for a new simulator or hardware back-end requires writing a Python module that implements the PyNN API for that system. However, much of the code in the current implementation is shared between back-ends, and only a small number of simulator-specific functions and classes need be defined to take advantage of the entire API and future extensions to it. It is not required that the simulator or control software have a Python interface, since code-generation can be used in this case, but obviously this makes two-way communication and interactive use more difficult. The API is defined independently of any particular implementation, and is versioned. This means that developers of an interface to a new system are not required to contribute code back to the project (although this is welcomed), but simply need to implement the published API in order to take advantage of being able to run a PyNN simulation on their system.
In summary, PyNN greatly simplifies the tasks of writing simulator-independent neuronal network models, of transferring models from software simulators to neuromorphic hardware systems, and of cross-validating simulation results between different systems. In the future, we hope to see implementations of the interface for further simulators and hardware systems (developers interested in an implementation for their own system are encouraged to contact us) and to implement inter-operability with other tools for neuroscience model description, such as NeuroML.12 We expect that increased adoption of PyNN will accelerate progress in computational neuroscience by facilitating reproducibility and cross-validation of published models and by stimulating component reuse, and that it will close the gap between computational neuroscientists and neuromorphic engineers, making neuromorphic hardware more easily exploitable by non-hardware experts.
Tell us what to cover!
If you'd like to write an article or know of someone else who is doing relevant and interesting stuff, let us know. E-mail the editor and suggest the subject for the article and, if you're suggesting someone else's work, tell us their name, affiliation, and e-mail.