Digilog
From Merlin Systems Wiki
DIGILOG: A 3D environment to simulate massively parallel spiking neural networks with a real-time hardware implementation using large numbers of cost-effective interconnected microcontrollers. Dr M.P.Norman and P.Peglar Merlin Systems Corp. Ltd
Abstract
DIGILOG has been designed to investigate the behaviour of large numbers of heterogeneous spiking neurons and then to be able to physically implement the simulation in real-time using inexpensive micro-controller based hardware. The DIGILOG hardware system will simulate around 300 spiking nodes per CPU, with 16 CPU’s per board giving a board level performance of around 5000 nodes at a price of 10 pence per neuron. It is envisaged that large numbers of boards can be interconnected in a distributed connection topology giving real-time simulations of over ½ million nodes. The DIGILOG software tool allows bespoke neuron code to be described using JAVA files processed at runtime. Topographical descriptions are abstracted into a machine independent format that can be transported between other simulators (with suitable import filters). The separation of connection structure from parameters and process descriptions is an important requirement for physical hardware implementation.
media:DIGILOG.pdf - Download as PDF
Introduction
A key feature of the DIGLOG software is the 3D presentation layer. The behaviour of spiking neurons can be difficult to interpret and an interactive 3D environment provides a highly intuitive information rich environment to make structural design choices and investigate distributed structures. The DIGILOG simulation environment has been designed to emulate interaction with the physical world providing interfaces to sensor and actuator models.
3D design tool with interactive 6DOF viewpoints available in multiple views. Hetrogeneous networks are supported. High-level description language for node parameters and connection topologies. Multiple views – multiple views can be displayed attached to one or more networks. Interactive simulation of spiking behaviour. High level description language for world objects and structures. Events are used between model, view and controller allowing each to be hosted on one or more physical platforms. Distinction between static and dynamic data for ease of hardware implementation. Flexible logging options. Node processing code is described in JAVA.
The presentation layer provides a 3D view of the network or network(s) being designed. Each view has a 6DOF moveable viewpoint, multiple views can be rendered for one or more networks simultaneously. The Digilog supports a range of input devices and could be used as part of an immersive virtual reality system. The presentation layer is also used to simultaneously display other physical elements such as actuators, sensors, robots and buildings. Events during simulation are automatically reflected into all views. Events can be generated and received by all objects in the system i.e. structures can be affected by neurons and vice versa. Each network consists of nodes and groups and each group consists of other nodes and groups. The nesting of groups can be arbitrarily complex. By dividing networks in this manner it is possible to organise very large numbers of neurons, but it is also possible to identify common population patterns and re-use them. A further benefit of this partitioning system is that it provides a convenient subdivision for implementation of node populations in micro-controller hardware.
Network Representation
A network description is broken down into a topographical description of nodes, parameters and connection structures and a description of how the node is processed by the simulation engine. The topographical description is made in a high level language similar to XML:
The same nested group structure is adopted within the topographical description language, allowing common neural patterns to be assigned symbolic names and reused throughout one or more designs. Node behaviours are described in a separate JAVA file, which is executed at runtime. Users are able to write new node behaviours without the source code of the overall system. Neuron models during simulation are processed at runtime.
Physical Model
The simulation environment has been designed to allow network simulations to interact with simulations of other physical objects. Physical objects are described in a hierarchical data structure allowing complex linked structures to be described. The physical model is also rendered in 3D as with other network representations and is updated during simulation. The purpose is to display physical elements such as a robot or actuators and sensors (see bipedal structure below). The physical model can be updated during simulations via sensors and actuator events triggered via the simulation engine, providing a cohesive simulation environment. Currently the physical environment does not model real-world dynamics, but this could be added as required at a later date.
Simulations
The simulation engine is written in JAVA. It reads the network model and processes the node execution files. Each nodes behaviour can be logged during simulation and written to a file for later analysis. Whilst executing code the simulation engine generates events, which are sent to all registered clients. In practice each view registers as a client, but sensors and actuators or physical models could also be event recipients. Specific analysis tools could also be clients receiving events. By decoupling the model, view and control layers into an event driven architecture it is possible to distribute processing tasks across multiple physical machines. The simulation engine is geared around spiking communications between nodes and is able to generate events for each spike generated. Neuron processing code is described in JAVA files, which are processed at runtime. The simulation is able to support heterogeneous mixes of neurons as long as they support spiking as the basic input/output mechanism. Several mechanisms have been designed at the group level to simplify convergent/divergent connections between groups by integration inputs/outputs onto virtual input/output nodes on a per group basis. This provides an effective mechanism for simplification at the hardware level also, but if necessary can be overridden to provide direct mapping from a sub-cell within a group to a sub-cell within any other group.
Software Architecture
Hardware Implementation
One of the key objectives of the DIGILOG environment is to provide a cost-effective scaleable architecture that can be implemented in commonly available micro-controllers.
The DIGILOG hardware environment uses micro-controllers to simulate around 300 neurons per micro each with on average 3 inputs and 3 outputs (supporting node signalling at 100Hz). Sixteen micro’s are closely connected on a single board (known as a cluster board) measuring around 10cmx10cm in a 4x4 toroid structure.
However, by using just one additional link per processor, shortcuts can be added that make the maximum inter-processor distance only 2 steps. The extra links look like this :–
Cluster boards can be arbitrarily connected together to simulate large numbers of neurons. Each cluster board supports the following common services to all 16 micros:–
local power regulator crystal clock at 16Mhz buffering for common control signals connections for micro programming
The cluster board has several pluggable inter-board signal connectors and a ‘main’ connector carrying power and ‘common’ signals.
The inter-board signals are arranged into fixed-size groups called I/O Channels.
Each channel is a group of 8 io pairs, brought to a pluggable connector for connection to other cluster boards.
Having established the inter-CPU connections, the remaining 3 i/o pairs per processor are used for inter-cluster channels. Each channel should connect to a variety of different CPUs. With 16 processors, we have 48 spare io-pairs, so these form 6 separate ‘i/o‑channels’.
System Level Services
All the boards are provided with power and a common SYNC signal. A single ‘system master’ board will source the SYNC signal, and provide a PC interface for configuration and monitoring. Configuration and monitoring are performed over the main i/o channels under micro control, while re-programming is done on a micro-by-micro basis by plugging a programmer into a given board. The neuron and connection configuration data is stored in onboard SRAM and/or EEPROM and not in program space. For configuration, all micros are addressed more-or-less as one. For debugging it is possible to re-route on chip resources to a PC for logging purposes. However there is a practical limit to the number of signals that can be monitored at any given time. The hardware implementation favours a highly distributed sparsely connected structure rather than structures with very high numbers of convergent or divergent connections.
The system has been designed with the expectation that large numbers of cluster boards (100+) would be connected together (as shown above). Each cluster board is only 10cmx10cm and it is envisaged each board would be distributed to local regions of a robot to handle for example sensor input or actuator drive.
All the CPU’s are self-programming so it is possible to dynamically change the connection structure at runtime. However, in our current implementation only neuron and connection parameters are changeable.
Software->Hardware Translation
Currently, there is no automatic mapping between the high-level network description and the implementation in hardware. This mapping is similar to the problem present in FPGA design/synthesis tools. If the designer chooses a group population size of no more than 300 nodes then the process of selecting physical resources is greatly simplified but almost certainly sub-optimal. The current hardware assumes this approach, but future investigations are likely to lead to programs that can provide automatic mapping for particular hardware configurations.
Conclusion
The DIGILOG tool is an ambitious first attempt to provide a cohesive modelling environment incorporating a software and hardware simulation environment for biologically realistic neurons with explicit spiking behaviour. The DIGILOG system has been optimised to allow hardware simulation using large numbers of cheap micro-controllers. Although other physical implementations are possible this system has been designed to implement around 500K neurons within a sparsely connected structure. It is also possible to create smaller numbers of highly interconnected neurons within the same hardware but this approach has not yet been analysed. The DIGILOG cluster boards were implemented on a double-sided PCB and as a result were extremely complex to route and populate. It is expected that a future design will simplify this by implementing the design on multi-layer PCB. Each cluster board is able to simulate around 5000 nodes, indicating a cost per neuron of around 10 pence. The mapping of simulation structure into physical hardware is a complex process, but is simplified in the DIGILOG tool by providing an additional modelling abstraction to the group level. A group level abstraction enables the designer to build CPU sized populations of cells. By nesting group cells extremely complex 3D structures can be described and still remain intuitive for the designer to work with. In the latest micro’s it is now possible to single-step a program running in hardware from a PC to enable debugging of code. The DIGLOG code does not yet provide this feature in full but the implementation of a PC driven clock cycle and the ability to monitor specific on board signals goes some way to providing this. The effectiveness of this feature is still being assessed. The DIGILOG environment has been developed by Merlin Systems Corp. Ltd to implement a bipedal control system capable of controlling over a 100 muscles (Humaniform Muscles) in parallel in real-time. It is anticipated that the system will be able to cope with the integration of sensory signals from muscles and joints, and be able to process this information to generate appropriate motor drive signals for the muscles. Work is currently progress assessing the performance of large numbers of interconnected cluster boards and detailed results will be presented in future papers.
References
M.P.Norman – PhD Thesis. P.Peglar (MSC) Dissertation John Taylor – Leaky Integrator Guido Bugmann – University of Plymouth,Neurodynamics Research Group
