vtr-verilog-to-routing
vtr-verilog-to-routing copied to clipboard
6D router lookahead and 3D custom switch block conflicts
My branch (3d_track_to_track_conn) is working with 6d_router_lookahead for 3D custom switchblocks. The last commit id from 6D_router_lookahead that I merged with my branch is "c3a247092cf66167c4eb3b0c7d91fefecabb1fb2". Up to this commit, an 3D architecture with only switch block connections across dice was working properly. However, after 6d_router_lookahead with master branch, routing always errors out if there is no OPIN connection between dice even for a very large channel width (e.g., 1600).
Expected Behaviour
Routing stage should be completed with only switch block 3D connections.
Current Behaviour
Routing always fails for nets travelling across dice even for a very small circuits and very large channel width. The same circuit and architecture (attached below) used to route with channel width 60 without a problem. Now, router just errors out that no possible path exists. I have generated RR graph for both master branch and my branch commit id (1370c03) that was working before, the RR graphs are identical.
Architecture and Design Files
- arch file: 3D S4 with custom 3D switch blocks
- design file: alu4.blif, mult_5x6.blif
- vpr command line used: ./vpr ../vtr_flow/arch/multi_die/stratixiv_arch.timing.xml ../vtr_flow/benchmarks/blif/alu4.blif --route_chan_width 60 --pack --place --route
@vaughnbetz this is the issue to track 6d_router_lookahead and custom 3D switch blocks conflict.
Thanks for the detailed issue @saaramahmoudi . This should make it a lot easier to find ... an error out condition like this sounds like the lookahead builder is pruning some connection/option.
Thanks Sara for flagging the problem. In this PR, I have addressed the issue. I am running QoR to make sure it doesn't affect the run-time for 2D architecture. Feel free to merge it to your branch (I tested it, and it was passing the case that you mentioned).
Great, thanks! Changed the title from costume to custom switch blocks :).