*2.2. SpiNNaker Network*

The kernel of the interconnection among all cores of all chips of the simulator is the router, specifically designed to deliver packets as fast as possible (0.1 µs per hop) [16]. The particular design of the router, despite limitations on the synchronous transmission of packets [17,18], allows transmission of two operative packet types—Multicast (MC) and Point to Point (P2P). The length of these packets can be up to 72 bits and can carry a 32 bits long payload.

*Multicast* (MC) packets can reach many cores across the board. In neural simulations, they are widely used in order to spread neural potentials to multiple destinations. Point-to-Point (P2P) packets can be used for chip-to-chip transmissions. Each chip is uniquely identified by its coordinates (x, y), which define the chip's position in the chip mesh. P2P packets are always delivered to a chip's monitor processors.

The APIs of the SpiNNaker system provide a higher level of abstraction that simplifies the usage of chip interconnection. The SpiNNaker Datagram Protocol (SDP) can be used to manage communication between processors up to 256 Bytes [14]. The Monitor Processors act as a middleware between the SDP protocol and the on-board network. A Monitor Processor that receives an SDP packet splits the whole frame into 32-bit fragments to be delivered in the internal network through the P2P packets.

## *2.3. SpiNNaker Software*

The software used to run a simulation managing the boards involves board-side code developed in C and Assembly [19] and host-side code mostly written in Python [20].

In this work we used the software stack provided by the SpinMPI library—a partial implementation of MPI on SpiNNaker [7] able to fully exploit the communication potential provided by the architecture, using the Application Command Framework (ACF) and the Multicast Communication Middleware (MCM) to manage communications.

The ACF uses the Application Command Protocol (ACP) to implement a Remote Procedure Call (RPC) capability in SpiNNaker at the application level [21]. Moreover, this library implements the *memory entity* concept. A memory entity is a managed memory space (DTCM, SysRAM, SDRAM), identified by an integer number, on which it is possible to perform CRUD operations (Create, Read, Update, Delete) locally or remotely. A *memory entity* can be created with a size limit of 256 Byte, that is, the ACP payload limit. The MCM instead implements unicast and broadcast communications, exploiting the multicast network capabilities of SpiNNaker.
