29/11/2022: so what have you been working on, lofty?

[Ravenslofty]

this is a crosspost from my cohost post a few days ago. people might have missed me posting the link, and I also figured having an extra copy would be useful.

(yes, I meant to have this out on sunday, but oh well)

I spent most of my spare time during the week working on awooter. it's presently at the stage where after doing partitioning of the input netlist into arcs, it can then find a route for every arc. there isn't any congestion avoidance or nextpnr state update however, so this isn't usable in anger yet.

big thank you to @spacecat-chan and @jubilee for their help on various bits of debugging.

---

observation four: partitioning is highly parallel

I had assumed that the partitioner would run serially, casually picking pips, and this would be fine (enough) because the amount of parallelism in the router would make up for it. As it turns out, after writing the code, it's pretty easy to turn things into something MapReduce-like: for each arc, figure out if it needs partitioning, split it across a pip on the border, and then return the new arcs; these arcs can then be serially put into the four segments of the final partition.

observation five: you can't partition everything

this was annoying to realise after writing the partitioner and finding that the router couldn't find a path through wires. it comes down to FPGAs having special routing for clocks and for inter-slice carry signals; these get skipped (because nextpnr handles them separately) and put into a fifth "segment" respectively. the special-case segment is a little annoying to have, but it's easy enough to deal with, and the segment only has 1-2% of the total arcs in practice.

observation six: you can't partition everywhere

here's where nextpnr's low-level API bites a little; how do you know if a pip is routing that you can safely partition across? for a decent while my code used a duck test of sorts to guess if it was general routing, but this is impossible to get right. so for now, there's an explicit allow-list based on the name of the wires in the pip. this is... suboptimal, but effective.