From NEST

Synapses in NEST: An overview

This overview is intended first of all for those users who would like to implement their own neuron models.

There is currently an intense discussion around synapses on the mailing list, in particular synapse models that need access to information about the state or history of the receiving neuron. I would like to give a brief overview over how synapses are currently implemented in NEST to---hopefully---reduce confusion.

Synapses in NEST come in two parts: (i) a Connection object that manages synaptic weight and delay, and (ii) code implementing the synaptic currents or conductances resulting from a spike arrival; the latter is always coded in the model neuron class. I will discuss both parts in turn. Some of the discussion below is simplified, ignoring issues of parallelization; my intent is to give you the general idea.

All targets of a given neuron are stored in a target list containing one Connection object per target. When a spike is sent, NEST traverses the target list and sends information about the spike, i.e., weight, delay and spike time to each receiving neuron. Some synapses implement spike-time dependent plasticity, i.e., they modify the synaptic weight stored in the Connection object based on the spike history of the receiving neuron. These synapses access the spike history through special member functions of the receiving neuron class, which must be derived from ArchivingNode (most models are). Details are explained in the appendix of Morrison et al. (2007) Neural Comput 19:1437-1467.

When a spike arrives at a neuron by a call to its handle(SpikeEvent&) method, the SpikeEvent provides information about the synaptic weight, the spike time, and the delay, so that the actual arrival time of the spike can be calculated. It is now entirely up to the neuron class to handle this information. In particular, all dynamics of synaptic currents or conductances must be implemented in the neuron model. See iaf_neuron and iaf_cond_alpha for examples of how this is done. We currently do not have any publicly available models with voltage-dependent synapses, such as NMDA channels. A simple way to introduce such a voltage dependency in, e.g., the iaf_cond_alpha model would be to multiply the synaptic conductance g(t) with a sigmoidal function m(V) in the expression computing the right-hand side of the membrane potential equation. It is a bit unfortunate that one needs to include the code for the synaptic currents/conductances anew in each new neuron model, but for many simpler models this leads to more efficient code than one would obtain if synaptic current dynamics were represented by separate objects. We will consider changing this in the future, though.

Introducing NMDA channels obviously raises the question of how to differentiate input to different types of channels on a neuron, e.g., AMPA, GABA_A, GABA_B, and NMDA channels. Most NEST models are very simplistic in this respect so far: they differentiate at most between an excitatory and an inhibitory synapse, and all input with positive weight is handled by the excitatory, all with negative weight by the inhibitory synapse. More channels can be handled using the receptor type/receiver port mechanism in NEST. Please see iaf_alpha_cond_mc for an example.

Time is a very important issue when processing spikes. Especially when the effect of a spike on the neuron depends on the history or state of the neuron, it is crucial that one considers causality carefully. This is the reason why history information about a neuron is available only via the ArchivingNode interface, while state information is currently "exported" only through the UniversalDataLogger interface (under development, available in few neurons today). The Morrison et al (2007) paper mentioned above has more on spike history handling.

NEST delivers spikes in batches. Simulation proceeds for min_delay (minimum delay) time. During this time, any generated spikes are stored in a central spike queue. After each min_delay interval, spikes are delivered from the central queue via the ConnectionManager and the Connection objects to the individual neurons. All delays are handled inside the neuron, as described above. This means that when a spike "passes through" the Connection object, the actual biological arrival time (time when spike occured at sender plus delay) of the spike may be up to max_delay (maximum delay) time units in the future. This means, in particular, that Connection objects cannot perform any computations that depend on the state of the neuron at the time of "biological" spike arrival; they can only use historic information. Another important point is that spikes do NOT pass the Connection object in correct order of biological arrival time---they are unordered in time.