|
Load chain0.ccm show display run the model |
This model has a very simple cell with a synapse population configured so that a single input spike generates a post-synaptic conductance which causes the cell to spike about five milliseconds later. There are three such cells connected together, constituting a sort of spike delay line.
In this example, the outputs of the cells could have been connected directly to the spike concatenator, but instead, SpikeRelay components have been interposed between the cells and the concatenator. The reason for this is that the spike outputs in the cells themselves are already within a group, and normally ports in grouped items are only exposed to the level above, not higher, in a hierarchical group. Therefore, it is possible to capture this compound (including the spike relays) as a new compound object. This is what has been done for the next example.
|
Load chain1.ccm show display run the model |
As for the first example, but with the three cells and their spike relays captured in a compound device. In the resulting device, the spike relays are exposed, but not the internals of the cells themselves. This is a deliberate design feature - that ports should only be accessible from the same level or one level up in a hierarchical group. The design advantage is that it makes it easier to implement optimisations of compound objects: one can be sure that an application is not going to access ports arbitrarily far down the hierarchy (because we made it impossible). To the user, it imposes the requirement that for every port which may need to be exposed a relay object should be included in the compound. As yet this seems a reasonable requirement and helps clarify the structure of the model, but we are open to suggestions.