brian2genn package

binomial module

Implementation of BinomialFunction

codeobject module

Brian2GeNN defines two different types of code objects, GeNNCodeObject and GeNNUserCodeObject. GeNNCodeObject is the class of code objects that produce code snippets for GeNN neuron or synapse models. GeNNUserCodeObject is the class of code objects that produce C++ code which is used as “user-side” code in GeNN. The class derives directly from Brian 2’s CPPStandaloneCodeObject, using teh CPPCodeGenerator.

Exported members: GeNNCodeObject, GeNNUserCodeObject


GeNNCodeObject(owner, code, variables, ...) Class of code objects that generate GeNN “code snippets”
GeNNUserCodeObject(owner, code, variables, ...) Class of code objects that generate GeNN “user code”

correctness_testing module

Definitions of the configuration for correctness testing.

Exported members: GeNNConfiguration, GeNNConfigurationCPU, GeNNConfigurationOptimized








device module

Module implementing the bulk of the brian2genn interface by defining the “genn” device.

Exported members: GeNNDevice


CPPWriter(project_dir) Class that provides the method for writing C++ files from a string of code.
DelayedCodeObject(owner, name, ...) Dummy class used for delaying the CodeObject creation of stateupdater, thresholder, and resetter of a NeuronGroup (which will all be merged into a single code object).
GeNNDevice() The main “genn” device.
neuronModel() Class that contains all relevant information of a neuron model.
rateMonitorModel() CLass that contains all relevant information about a rate monitor.
spikeMonitorModel() Class the contains all relevant information about a spike monitor.
spikegeneratorModel() Class that contains all relevant information of a spike generator group.
stateMonitorModel() Class that contains all relvant information about a state monitor.
synapseModel() Class that contains all relevant information about a synapse model.


decorate(code, variables, shared_variables, ...) Support function for inserting GeNN-specific “decorations” for variables and parameters, such as $(.).
extract_source_variables(variables, varname, ...) Support function to extract the “atomic” variables used in a variable that is of instance Subexpression.
freeze(code, ns) Support function for substituting constant values.
get_compile_args() Get the compile args based on the users preferences.
get_genn_prefs() Get the GeNN preferences that are exposed in brian2genn user preferences.
stringify(code) Helper function to prepare multiline strings (potentially including quotation marks) to be included in strings.


genn_device The main “genn” device.

genn_generator module

The code generator for the “genn” language. This is mostly C++ with some specific decorators (mainly “__host__ __device__”) to allow operation in a CUDA context.

Exported members: GeNNCodeGenerator


GeNNCodeGenerator(*args, **kwds) “GeNN language”


get_var_ndim(v[, default_value]) Helper function to get the ndim attribute of a DynamicArrayVariable, falling back to the previous name dimensions if necessary.

insyn module

GeNN accumulates postsynaptic changes into a variable inSyn. The idea of this module is to check, for a given Synapses, whether or not it can be recast into this formulation, and if so to relabel the variables appropriately.

In GeNN, each synapses object has an associated variable inSyn. The idea is that we will do something like this in Brian terms:

v += w (synapses code) dv/dt = -v/tau (neuron code)

should be replaced by:

inSyn += w (synapses code) dv/dt = -v/tau (neuron code) v += inSyn; inSyn = 0; (custom operation carried out after integration step)

The reason behind this organisation in GeNN is that the communication of spike events and the corresponding updates of post-synaptic variables are separated out for better performance. In priniciple all kinds of operations on the pre- and post-synaptic variables can be allowed but with a heavy hit in the computational speed.

The conditions for this rewrite to be possible are as follows for presynaptic event code: - Each expression is allowed to modify synaptic variables. - An expression can modify a neuron variable only in the following ways:

neuron_var += expr (where expr contains only synaptic variables) neuron_var = expr (where expr-neuron_var can be simplified to contain only synaptic variables)
  • The set of modified neuron variables can only have one element

And for the postsynaptic code, only synaptic variables can be modified.

The output of this code should be: - Raise an error if it is not possible, explaining why - Replace the line neuron_var (+)= expr with addtoinSyn = new_expr - Return neuron_var so that it can be used appropriately in

The GeNN syntax is:

addtoinSyn = expr

Brian codegen implementation:

I think the correct place to start is given a Statement sequence for a Synapses pre or post code object, check the conditions. Then, we need to create two additional CodeObjects which overwrite translate_one_statement_sequence to call this function and rewrite the appropriate statement.


check_pre_code(codegen, stmts, vars_pre, ...) Given a set of statements stmts where the variables names in vars_pre are presynaptic, in vars_syn are synaptic and in vars_post are postsynaptic, check that the conditions for compatibility with GeNN are met, and return a new statement sequence translated for compatibility with GeNN, along with the name of the targeted variable.

preferences module

Preferences that relate to the brian2genn interface.