| *** tpb has joined #vtr-dev | 00:00 | |
| elms | kem_: a test case was failing https://github.com/kmurray/libblifparse/pull/1 should be ready | 00:47 |
|---|---|---|
| tpb | Title: Expand id characters by elmsfu · Pull Request #1 · kmurray/libblifparse · GitHub (at github.com) | 00:47 |
| litghost | kem_: I'm working on moving from vpr https://github.com/verilog-to-routing/vtr-verilog-to-routing/commit/b01199a49e8a5f9955325807d63cb37aa07ec932 to master, and I'm seeing that the router is no longer able to route on the rrgraphs I'm generating. A new message is also popping up: | 22:13 |
| litghost | Warning 22509: No routing path found in high-fanout mode for net connection (to sink_rr 123689), retrying with full route tree | 22:13 |
| litghost | Warning 22510: No routing path found in high-fanout mode for net connection (to sink_rr 123673), retrying with full route tree | 22:13 |
| litghost | Warning 22511: No routing path found in high-fanout mode for net connection (to sink_rr 123666), retrying with full route tree | 22:13 |
| tpb | Title: Odin: fix malloc <0 in simulation · verilog-to-routing/vtr-verilog-to-routing@b01199a · GitHub (at github.com) | 22:13 |
| litghost | Where there router changes since July 2018 that would explain how the vpr router would lose the ability to route on the graph and start outputting that message? | 22:14 |
| litghost | Were* | 22:14 |
| litghost | Looks like the high-fanout mode caused the regression. Disabling high-fanout allowed the router to converge on a solution. Thoughts? | 22:30 |
| litghost | e.g. setting "--router_high_fanout_threshold -1" | 22:31 |
| kem_ | litghost: Yep I've been doing some work on the router. One of the optimizations changes how we handle routing high fanout nets. The new approach is more cpu-time efficient for high fanout nets. | 22:55 |
| litghost | kem_: Is it possible that the high fanout logic breaks on some routing graphs? | 22:56 |
| kem_ | litghost: In some cases though it may not find a route initially and falls back to the old method (hence the warnings) | 22:56 |
| litghost | kem_: In my case even with the fall back it totally fails to finish routing | 22:56 |
| litghost | kem_: So I guess there are two points of inquery: 1) why is the high fanout logic failing? 2) why doesn't the fallback work? | 22:57 |
| kem_ | litghost: Hmmm yep that seems odd. I think (2) is more concerning to me | 22:57 |
| litghost | kem_: It is worth noting that it appears to fallback every single iteration, might want to consider remembering if the high fanout routing failed in the previous iteration | 22:57 |
| litghost | I can provide the arch, rr graph, .net and place file | 22:58 |
| litghost | Should be able to replicate locally | 22:58 |
| kem_ | litghost: Yep that's a potential future optimization | 22:58 |
| kem_ | litghost: Bug and test case would be appreciated | 22:58 |
| kem_ | litghost: How accurate is the location information for the RR graph? The high fanout optimization uses a spatial look-up, so if the rr graph location information is off that may be a reason. | 22:59 |
| litghost | kem_: There are some errors, but they should off-by-one at most | 22:59 |
| litghost | kem_: We've completely disabled some of the check routing check's, rather than a soft check like what was suggested | 23:00 |
| kem_ | litghost: Yeah, it's hard to say. I suspect your rr graph is different from what we usually test on, so there is probably some violated assumption either there or in the router. Probably best to just get a test case to look at. | 23:02 |
| litghost | kem_: Will do | 23:02 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!