Wednesday, 2018-06-27

*** tpb has joined #vtr-dev00:00
*** digshadow has joined #vtr-dev05:26
kem_mithro: Have you looked at the RR graph generated from the shorted switch regression test architecture: ?14:32
tpbTitle: vtr-verilog-to-routing/shorted_flyover_wires.xml at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithrokem_: I _think_ I have them working17:14
mithrokem_: but it seems to make the design unroutable17:14
mithrobenreynwar: Would you happen to be around? I need another small rr_graph tool :-P17:35
benreynwarmithro: Yeah, I can have a look tonight.  What is it?17:40
mithrobenreynwar: I need to give the tool a starting node and an ending node and want to check there is a pathway between them17:40
mithrobenreynwar: I feel like that might already be part of that other tool?17:42
benreynwarmithro: Yep.  It just needs exposing with a command line parameter.17:43
mithrobenreynwar: Take a look at my ice40-generate branch17:45
benreynwarmithro:  I'll take a look after work today.17:46
mithrobenreynwar: It also looks like I broke the tool in some way17:47
mithroAs it is reporting lots of inaccessible nodes...17:48
mithrobenreynwar: Another thing would be a "rr_graph optimizer" -- the idea would be to merge all nodes which are connected together via a "short"17:58
mithroOh - it's reporting the carry chains :-P18:00
kem_mithro: Its hard to say what the issue is. We have basic regression tests to check that shorted switches work, so I would lean towards a specification issue.19:10
kem_mithro:  Have you tried pulling up the RR graph in the GUI an clicking on some of the shorted connections? They should be highlighted as a single unit.19:10
kem_mithro: How many shorted connections are you adding? If its a lot, you might need to be careful to ensure they don't cause large parts of the RR graph to be shorted together (i.e. so only a single logical connection can use those nodes), which would cause routing problems.19:13
mithrokem_: I don't think I have done that20:04
mithroYeap, been clicking on the wires in GUIs20:04
mithrokem_: need to look up what the colours mean again20:26
mithrobenreynwar: Turns out it was *really* easy to make your existing tool work the way I wanted20:32
mithrobenreynwar: I just added a filter to the sink/src ids20:32
tpbTitle: rr_graph: Allow filtering and output better names. · mithro/[email protected] · GitHub (at
mithroBlue: track to block input pin20:36
mithroRedish-pink: block output pin to track20:36
mithroGreen: track to track20:36
mithroPurple: block output pin to block input pin (i.e. <directlist> connection)20:36
mithroGray: Non-configurable edge20:36
mithrokem_: Is there a way to output conflicting paths?20:38
kem_mithro: One way is to run routing with the GUI and turn the congestion toggle on20:46
mithrokem_: Yeah - I don't quite know how to read that...20:46
kem_mithro: Basically the colour maps to how overused an RR node is (i.e. 1 means not overused, 3 means occupancy is 3x capacity)20:47
mithrokem_: So, everything is blue... and the numbers all seem to be less than 120:48
kem_mithro: Interesting, I think the congestion heatmap only draws things that have an overuse ratio strictly > 1, so a nearly legal solution with only a couple overused nodes should only highlight a small number of nodes (i.e. channels mostly white)20:54
mithroLooking now20:57
mithrokem_: Oh, I hadn't realized the congestion is per net, if you keep clicking it it cycles through them22:56
mithrokem_: blue == track which can drive this track, red == tracks that can be driven by this track?23:55

Generated by 2.13.1 by Marius Gedminas - find it at!