Andrew Rowley

Yes - this is sort-of done in that connections get expanded on the machine, but CSA on the machine would certainly allow more powerful generation of connections

If too many packets arrive at the core at the same time, and they can't all be processed within a single timestep, it will throw those away. This is by...

Do you have an example of the error being generated? This might indicate which bit is losing the packets to make it more clear...

The first case where it loses packets is expected if the receiver core is overloaded, and from the messages, it is. It doesn't seem related to delay extension overload here...

It is possible that it instead uses time=0 for the last_pre_spike time. This should be flagged as an invalid time as it might cause potentiation when depression is expected.

!= 0 isn't quite enough - really we need a flag to indicate if there has been a pre-spike or not (since there might actually be one at time=0)

This is the "other side" of this issue - that you can re-use the synaptic information in a different context in your application with a simple reusable component. This is...

sPyNNaker/neural_modelling/makefiles/neuron/IF_curr_exp_stdp_mad_pair_additive/Makefile has: TIMING_DEPENDENCE = $(NEURON_DIR)/neuron/plasticity/stdp/timing_dependence/timing_pair_impl.c sPyNNaker/neural_modelling/makefiles/neuron/IF_curr_exp_stdp_mad_nearest_pair_additive/Makefile has: TIMING_DEPENDENCE = $(NEURON_DIR)/neuron/plasticity/stdp/timing_dependence/timing_nearest_pair_impl.c These are two independent things. It looks like you were looking at timing_pair in this case, which as a uint16_t...

I think this was a one-per-edge deal. We get this in structural plasticity I believe, but not currently in STDP. We could also support a per-synapse thing if desired, although...

Some steps that could come after this (i.e. in other PRs) are: 1. Add reader that makes the data end up in Neo format (as you suggested) 2. Make the...