On-chip routing

[rowleya]

On chip routing could be done as follows:

Have the placement chip and key of each source you need to receive at each core. When you find you need an input from that chip, use the P2P routing table to tell you the link you need the information from, and ask that chip to send it to you (using NN packet? Would that get overloaded?). That chip then uses its P2P route to ask the adjacent chip, and so on until you reach the placement chip.

When that is complete, do compression on core if needed.

Further refinements:

• Keep the idea of a "source edge chip" for a Population (see the application router in PACMAN) and then the above routes to the source edge chip rather than the actual source chip. If something is routed to the source edge chip, the Population then needs to be routed to the source edge chip, so that chip knows the source chips of the Population and can ask those chips to route to it.
• This would all need to be aware of self-targets, which need to be handled using the full machine vertex keys, not the application vertex keys, at least on the chips containing that Population.

[Christian-B]

A possible compromise would be to do two stage routing. The between chip (link id) part done in python. The to core (process id) part done on core. Yes the Chip may then receive spikes that none of its cores would need

[rowleya]

This could also be done in two stages on machine. If you let the routing happen after synaptic expansion (or whatever equivalent there is for other front ends) that could leave a trace of what the chip really needs in terms of targets and avoid the need to route things to chips which have no core targets...

That would mean any application that doesn't have an expansion process would load the information from host. An application with an expansion process could avoid that load and instead write the information from the expansion cores.