Because of the thread-safety issues in the nextpnr arch API (#1388), router2 grew an abstraction layer for pip/bel manipulation. This has proved to be very useful, but it can be confusing to newcomers that router1 uses the arch API directly, but router2 has an abstraction. We should factor out the router2 abstraction layer and consider porting router1 to it; the abstraction layer would still be useful for a possible router3.
We could also consider abstracting out the router2 pathfinder; it can be confusing to see that the difference between r1 and r2 is in resolution congestion when they use entirely different pathfinders. (the r2 pathfinder could even be used to improve r1 runtime due to its efficiency)
Because of the thread-safety issues in the nextpnr arch API (#1388), router2 grew an abstraction layer for pip/bel manipulation. This has proved to be very useful, but it can be confusing to newcomers that router1 uses the arch API directly, but router2 has an abstraction. We should factor out the router2 abstraction layer and consider porting router1 to it; the abstraction layer would still be useful for a possible router3.
We could also consider abstracting out the router2 pathfinder; it can be confusing to see that the difference between r1 and r2 is in resolution congestion when they use entirely different pathfinders. (the r2 pathfinder could even be used to improve r1 runtime due to its efficiency)