Refactor builder and vertices

[mundya]

I'm not completely done with this but would really appreciate some extra pairs of eyes.

Remaining issues:

• [x] Any form of custom connection from pass nodes (including probing them) breaks because non-Nengo objects can't be the used with Nengo connections. I think the solution is to replace replace_pass_through_nodes with some equivalent functionality.
• [ ] UART doesn't work because some routing entries don't make it on to the chip, currently trying to track this down.
• [ ] Unit tests are out of date :unamused:

Things to neaten:

• [ ] The intermediate representations and vertices need moving to some better locations to keep the builder and assembler neater.

---

When a Simulator is presented with a model it first builds it. Building entails:

1. Flattening the network.
2. Applying a series of transforms which modify the connectivity of the network.
3. Removing pass nodes.
4. Replacing all Nengo Connections with equivalents that have the full transform and a keyspace attribute.
5. Applying a second set of transforms which replace objects like Ensembles, and build their decoders.
6. Assigning an ID to all objects
7. Building the keyspace (determining the number of bits required to represent whether the packet is routed to UART (x, 1 bit), the object ID (o), the connection ID (i) and the dimension (d))
8. Applying that keyspace to all Connections

The builder returns a list of objects, a list of connections and the final keyspace.

When run is called some final assembly takes place:

1. Function of time Nodes are checked to see whether there's sufficient memory for them, if there is then they are converted into PACMAN vertices, otherwise they're left to be picked up by the IO building.
2. The IO building is used to construct IO, the prepare_network function performs this task.
3. The assembler is used to convert any remaining non-PACMAN objects into Vertices.
4. Everything runs as before...

Fixes the problem fixed in #78

[mossblaser]

Hello there. Not sure where to start with the code so I'll await some guidance about where my particular eyes would be most useful. Unfortunately away this weekend so will not get chance to look 'til monday.

Regarding UART, there's some extra fun involved which will need some input from the PACMAN team which is when multiple links are present (which will be the normal case once bandwidth ramps up since 8 links converge on an FPGA. The short term solution would probably be to support a field of a size that grows with the number of IO ports used. PACMAN involvement here would be the inclusion of some facility to ensure that streams containing the "IO" bit never cross the 'wrong' FPGA's links meaning that a single bit would be sufficient for the majority of multi-port I/O scenarios.

[mundya]

Hi, enjoy your weekend! Re UART and just IO in general, when SpiNNman/PACMAN support this via the transceiver then we can cross that bridge. For the moment I think assuming 1 connection remains safe. Worth bearing in mind though.