SpiNNaker Project - System Software.
System Software Components
The SpiNNaker run-time software involves three different devices:
- Host machine -- for application I/O and monitoring.
- SpiNNaker monitor cores -- for application support and system monitoring. Additionally, one of them communicates with the host over Ethernet.
- SpiNNaker application cores -- to run applications.
- ybug -- [host software] interacts with scamp on the monitor cores and provides a simple command/debug interface to start applications and examine memory and on-chip resources.
- scamp -- [monitor core software] interacts with ybug on the host and sark on the application cores. Supports system-wide inter-processor communication and communication with the host.
- sark -- [application core software] interacts with scamp on the monitor core and provides the ability to use the core hardware/peripherals in an abstracted way. For example, starting a 1ms timer, setting an entry in the multicast routing table or installing a handler to deal with packet arrival.
Application Programming Model
The SpiNNaker programming model is a simple, event-driven model. Applications do not control execution flow, they can only indicate the functions, referred to as callbacks, to be executed when specific events occur, such as the arrival of a packet, the completion of a Direct Memory Access (DMA) transfer or the lapse of a periodic time interval. The SpiNNaker Application Run-time Kernel (sark) controls the flow of execution and schedules/dispatches application callback functions.
|
The figure to the left shows the basic architecture of the event-driven framework. Application developers write callback routines that are associated with events of interest and register them at a certain priority with the kernel. When the corresponding event occurs the scheduler either executes the callback immediately and atomically (in the case of a non-queueable callback) or places it into a scheduling queue at a position according to its priority (in case of a queueable callback). When control is returned to the dispatcher (following the completion of a callback) the highest-priority queueable callback is executed. Queueable callbacks do not necessarily execute atomically: they may be pre-empted by non-queueable callbacks if a corresponding event occurs during their execution. The dispatcher goes to sleep (low-power consumption state) if the callback queue is empty and will be awakened by any event. The SpiNNaker API supports the programming model providing functions to register callbacks, enter and exit critical sections, communicate with other cores and the host, trigger DMA operations and other useful tasks. |