allowing sub partitioning of keys for allowing retina/ssa to be filtered via routing

[alan-stokes]

depends upon:
FEC SpiNNakerManchester/SpiNNFrontEndCommon#320
SPY SpiNNakerManchester/sPyNNaker#526

• make work
• reviewed

[coveralls]

Coverage increased (+0.1%) to 68.24% when pulling 1461209 on reverse_ip_tag_multicast_source_destination_key_control into b36193b on master.

[dkfellows]

You had a few breaking problems; the main one was that you were using xrange. That currently has to be imported from six.moves in those cases (like this one!) where it makes sense to not just sometimes build a list of everything in Py2.7.

[alan-stokes]

i hadnt even finished this donal! note the make work flag not being set. lol.
if i was using xrange, id argue that it was already being used, as currently all ive done is move screw drivers around, to allow this to be feasible without cloned code everywhere. lol

[alan-stokes]

i have a suspisoion that the work ive done via atom filtering and router compressor with bitfields makes this work obsolete......... will assess later and see if it can be killed

[rowleya]

I know at one point we were looking at having a way of specifying that part of the key space of a device is covered, and I think this was an attempt at detecting this and at present raising an exception. This seems to be done here by having the receivers say which part of the key space is covered, and then you get an error if there isn't a receiver for each part. However I can't see how users would make use of this, certainly in things like PyNN where they wouldn't get access to the ability to set the bit of the key that needs to be received. I could see this being an interesting way of doing things, particularly if we can then detect the part of the key not needed and push this in to the routing table nearest to the transmitter.

I think this is therefore missing a couple of things that could make it work. Here is a TODO list:

• Add a way to specify the "parts" of a device that make sense to be divided up. This might be quite flexible depending on the device, and might be extendable for the device. An obvious example would be a retina device that has an "up polarity" part and a "down polarity" part, but it might equally have a "left half" and "right half" or other partitionings of the key space. The interface would have to have methods to get the key(s) and mask(s) of the part, as well as the key and mask of the whole device. Note that the parts might overlap.
• Each device part will probably return a vertex which can then be added to the graph. In sPyNNaker, this should allow the part to be wrapped in a Population as usual.
• The graph can be updated to support a "null" vertex. This is a target of nothing in the graph but it should be given a specific location (maybe a placement constraint). When routing encounters this vertex, it should route to no cores and no links (in rig this would be a routing constraint I think so this should be able to work in RigRoute also).
• An edge can be added from each "part" vertex to the null vertex. This can be added whether the part is used or not (this is the clever bit ;) ). Routing will now merge the route to the null vertex with any others; this means that if there is only an edge to the null vertex, it will route to nothing BUT importantly, an empty entry will be added. If there is any other edge, the empty routing entry will be merged with this and there will be no empty entry!

There may be better ways to do this, but this is my first plan...

[alan-stokes]

the view that was missing when i left it was that it used the connectivity to determine the edges and keys needed to basically sub divide at src instead of at the destination (which the bitfields work does). The problem you've hit, was one which i still needed to solve, and got stuck on. Which was, once you've figured the areas the user isn't interested in, how you create entries for them to a core for sucking up.

If id had finished it, the end user wouldn't ever see this stuff,. it would be hidden under the hood. But alas the math to figure the minimum keys and masks for uncovered keys was beyond me at the time of writing..... Having done the bitfield stuff.... it might be feasible to just use a bitfield to figure the left overs...... basically i think now with lessons learnt we could come back to this..... but not right now

[dkfellows]

Looks OK to me. Perhaps ElementAllocatorAlgorithm should just be ElementAllocator (since it doesn't actually match what we call an “algorithm”) but I've not looked what the impact of that change would be on downstream code. Perhaps fix that in a different PR?

[Christian-B]

is this this worth keeping let alone updating?

[rowleya]

I think this is now covered under other work now in master. Retinas can be sub-divided into machine vertices which represent different parts of the retina, and filtering is also supported, with machine vertices which go nowhere ending with empty routing entries.

[Christian-B]

to far behind as now covered by other work,