Tuesday, 2019-03-05

*** tpb has joined #vtr-dev00:00
elmskem_: a test case was failing https://github.com/kmurray/libblifparse/pull/1 should be ready00:47
tpbTitle: Expand id characters by elmsfu · Pull Request #1 · kmurray/libblifparse · GitHub (at github.com)00:47
litghostkem_: 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
litghostWarning 22509: No routing path found in high-fanout mode for net connection (to sink_rr 123689), retrying with full route tree22:13
litghostWarning 22510: No routing path found in high-fanout mode for net connection (to sink_rr 123673), retrying with full route tree22:13
litghostWarning 22511: No routing path found in high-fanout mode for net connection (to sink_rr 123666), retrying with full route tree22:13
tpbTitle: Odin: fix malloc <0 in simulation · verilog-to-routing/[email protected] · GitHub (at github.com)22:13
litghostWhere 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
litghostWere*22:14
litghostLooks like the high-fanout mode caused the regression.  Disabling high-fanout allowed the router to converge on a solution.  Thoughts?22:30
litghoste.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
litghostkem_: 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
litghostkem_: In my case even with the fall back it totally fails to finish routing22:56
litghostkem_: 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 me22:57
litghostkem_: 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 iteration22:57
litghostI can provide the arch, rr graph, .net and place file22:58
litghostShould be able to replicate locally22:58
kem_litghost: Yep that's a potential future optimization22:58
kem_litghost: Bug and test case would be appreciated22: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
litghostkem_: There are some errors, but they should off-by-one at most22:59
litghostkem_: We've completely disabled some of the check routing check's, rather than a soft check like what was suggested23: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
litghostkem_: Will do23:02

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!