Cypress

Please refer to the README before getting started. Please also consider the examples at Github . When starting your own project, please begin with the example project which demonstrates how to include cypress as an external project.

This page (at the moment) can be used to search for extended functionality of cypress that is not covered in the Readme or in the examples. This mainpage contains some more details about how to setup the hardware locally.

Note: all config parameters that are introduced in the following are provided via 'simulator={"option" : value, "option2" : value2}' (in all examples via the cli) at runtime.

There are two possible scenarios for random number generation: random input/source spikes and probability-based connectors.

• Connectors provide a seed option, as well as choosing the RNG algorithm and have to be fixed connector wise
• Spikes can be seeded connector wise (it a parameter of the neuron model), or globally using cypress::RNG::instance().seed(1234), where 1234 has to be replaced with your seed.

Backend specific details

GeNN

When building cypress, GeNN is automatically download and installed. Currently, the backend implemntation does not allow to set individual neuron parameters. Only population wise varying parameters are allowed. GeNN is only build once. Make sure to have the correct CUDA_PATH defined at built time, otherwise GeNN is built without GPU support. See also GeNN documentation for more detailed information. The cypress backend is loaded at runtime, so building new applications it is irrelevant whether CUDA_PATH is defined or not.

At runtime, you have the following options:

• timestep time accuracy/resolution of the internally used Euler integration. values between 0.01 ms and 1 ms should be working. The smaller the value, the slower the simulation and the more accurate. Default: 0.1ms
• gpu: True to actually use an nvidia gpu, false for CPU simulation. Failure on missing Cuda, missing Cuda at first built of cypress or no supported card available. Default: false
• double: False for using floats internally, True for double. Default: false

NEST

Install using the Setup script. It will install everything to ~/venvs/nest. Activate the environment via source ~/venvs/nest/bin/activate.

Runtime configuration options are e.g.

• threads : int, where int has to be replaced by the number of threads you want to use
• spike_precision: "off_grid", allow more precise spike times
• timestep : float, value for the accuracy of the simulation, defaults to 0.1ms
• timing : Does extensive timing measurements, might slow-down simulation
• keep_compile: If the backend instance is kept, and only weights of list connectors and input spikes are changed, we can reuse the genn compiled code, will speed-up execution

NEST actually comes with two backends, one via Python (using pyNN –> pynn.nest) and one using the SLI interpreter (nest). Both backends should provide similar results, depending on your network the Python or the SLI backend will be faster.

NOTE: Spike values that are smaller than your timestep will be ignored! To be safe, use the simulators only after a few ms!

Spikey

For software installation to standard directory ~/venvs/spikey/ refer to Setup script. Uncomment the last code part by removing the : " and ". If you do not want to install nest, do not forget to comment out the middle part of the script. Afterwards, execute the script to install the Spikey software. If you stumble upon some errors about missing packages, please refer to the guidebook. After installation, activate the virtual environment via source ~/venvs/spikey/bin/activate before working with Spikey.

The hardware system is connected via usb cable. Please use an active USB hub or and y-cable to connect Spikey to two USB connectors. Spikey uses a bit more current then it is specified in the USB specification. On linux you will need to add the following UDEV rule to your system (google UDEV and your distro to learn how to do that) : SUBSYSTEMS=="usb", ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="1003", MODE:="0666"

When running simulations, there are some hardware limitations that have to be kept in mind.

• A population can only have either excitatory or inhibitory outgoing connections
• Positive weights are in between 0.001 and 0.015 in 0.001 steps (4 bit)
• Negative weights are in between -0.004 and -0.06 in 0.004 steps (4 bit)
• E_rev_E is set to 0mV, E_rev_I can be chosen between -80 and -55 mV. The same goes for reversal, reset and threshold potential.
• Spikey consists of two chips. Neurons on on chip can not communicate inside and outside of the same chip
• The hardware is analogue. Therefore you should expect deviations from the simulation.

To counter some of the mapping issues, there are two options you can use:

• mappingOffset : int neurons are mapped to the hardware in the order of their creation, with mappingOffset default = 0
• neuronPermution : [...] providing a list for the order of the mapping

Furthermore:

• calibIcb : true activates experimental calibration for tau_refrac, otherwise it will always be around 1ms

Keep an eye at the logs, if the system reports that spike buffers are almost full, you might have lost some of the spikes. Either, spike rate is too high, or simulation time to long!

SpiNNaker

SpiNNaker is connected via LAN. I recommend to use a usb-lan dongle if no lan port is free on your system. Please set a manual IP address like 192.168.240.99 and a sub-mask 255.255.255.0. The small SpiNN3/large SpiNN5 boards will have the IP 192.168.240.253/192.168.240.1. This IP must be set in ~/.spynnaker.cfg (created after first try to simulate something on SpiNNaker) as machineName, as well as the version (3 or 5).

For installation, please use the same procedure as for the Spikey system, except you uncomment the first part of the script. See also SpiNNaker docu

Issues might relate to overloaded cores, not finished cores, or dropped packages. There are two options to work around these issues:

• Reducing the timestep to 0.1ms or even 0.01ms
• Reducing the source_neurons_per_core or neurons_per_core to values below 255

Another issue is related to a fixed overhead of projections/connections. If you encounter a situation where the system is running out of memory before actually running the simulation, although the network should map to the hardware (less neurons than number of cores times 255, where SpiNN3 has 16*4 and SpiNN5 16*49 cores for simulation of neurons), you can try to merge your connections in a single FromListConnector. Note also, that every high-level population is mapped to at least on core, and there is at most one population per core, such that you cannot have more populations than cores.

BrainScaleS

The BrainScaleS interface library BS2Cypress is loaded dynamically at runtime. For more details on the hardware system, you should consider the paper or take a look at the guidebook. The backend supports the following runtime configurations:

• neuron_size Number of neuron circuits combined to one neuron. Possible values: 2,4,6,...; Default: 4
• big_capacitor Using big capacitors on HICANNs. Possible values: true, false; Default: true
• bandwidth Consider the firing rate of input neurons and only use the partial maximal bandwidth. The smaller the value, the less neurons are mapped to a single HICANN. Possible values: values between [0,1]; Default: 0.8
• calib_path Path to calibration files. Possible values: "path/to/calib" ; Default: Current default calib path
• synapse_loss Allow the loss of synapses while mapping to the hardware system. Possible values are true (allowing loss), false (failure on loss). Default : false
• ess Use the simulation of the hardware system instead of the hardware. Possible values: true, false. Default: false
• keep_mapping : True for in the loop simulations, where only low-level weights or input spikes are changed and you want to keep the mapping
• full_list_connect : True if the list connection should be all to all, inhibitory and excitatory, with only those synpases != 0 defined by the list connector. Required for in the loop simulations and training, where inhibitory connections might become excitatory (or vice versa) and you want to reuse the mapping

Only on the hardware:

• hicann and wafer: Choose the Wafer and the HICANN for your network emulation. Possible values: Available HICANNs and Wafers, also list of HICANNs; Default: 297 and 33. Also possible is a list of lists of HICANNs, e.g. [[296,297],[320,321,340,341],[322,342]], which will map the first population to HICANNs 296,297, the second population to HICANNs [320,321,340,341], ..., in the order of their creation in the high level code.
• digital_weight: Directly set the digital weight instead of PyNN weights. Currently not supports ListConnectors with varying weights. Possible values: true, false; Default: false