search

ominux / vtr-verilog-to-routing

Automatically exported from code.google.com/p/vtr-verilog-to-routing
0 stars 0 forks source link

VPR: "subset"/"universal" SBs unrouteable at greater than min W #14

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. ./vpr N4K4L1Fci0.1Fco0.3SBuniversal.xml or1200_K4 -route -route_chan_width 64
2.
3.

What is the expected output? What do you see instead?
Binary search place and route finds the minimum channel width to be 54, via:
low, high, current -1 -1 182
low, high, current -1 182 92
low, high, current -1 92 46
low, high, current 46 92 70
low, high, current 46 70 58
low, high, current 46 58 52
low, high, current 52 58 56
low, high, current 52 56 54

Strangely, the circuit is unrouteable at W=64 (a point I'm interested in 
because it's minimum +20%) but is routeable at the other even-widths I tested 
in the range 54-70. This non-monotonic behaviour is a little bit unsettling 
considering the minimum channel width is found via binary search?

What version of the product are you using? On what operating system?
VTR 1.0 final, Linux 64-bit.

Please provide any additional information below.
.xml, .blif, .net, .place attached.

I've been doing a big architecture sweep across the typical FPGA parameters 
(N,K,I,L,SB,etc.) and I've found several more cases of this behaviour where it 
is unrouteable at minimum W + 20%, and this is but one example.

Original issue reported on code.google.com by eddie.h...@gmail.com on 16 Feb 2012 at 8:49

Attachments:

GoogleCodeExporter commented 9 years ago 
On several channel widths including W=64 (failing) and W=66 (successful) 
routes, I see warnings like this:

N4K4L1Fci0.1Fco0.3SBuniversal_W64.out:Warning (check_all_tracks_reach_pins):  
track 30 does not 
N4K4L1Fci0.1Fco0.3SBuniversal_W64.out-  connect to any CLB IPINs.
N4K4L1Fci0.1Fco0.3SBuniversal_W64.out:Warning (check_all_tracks_reach_pins):  
track 31 does not 
N4K4L1Fci0.1Fco0.3SBuniversal_W64.out-  connect to any CLB IPINs.
N4K4L1Fci0.1Fco0.3SBuniversal_W64.out:Warning (check_all_tracks_reach_pins):  
track 62 does not 
N4K4L1Fci0.1Fco0.3SBuniversal_W64.out-  connect to any CLB IPINs.
N4K4L1Fci0.1Fco0.3SBuniversal_W64.out:Warning (check_all_tracks_reach_pins):  
track 63 does not 
N4K4L1Fci0.1Fco0.3SBuniversal_W64.out-  connect to any CLB IPINs.

Original comment by eddie.h...@gmail.com on 16 Feb 2012 at 8:51

GoogleCodeExporter commented 9 years ago 
Lastly, I'm seeing the same behaviour for the subset SB pattern. The same 
circuit, with the same architecture parameters except for SB, produces a 
different placement and a different minimum channel width (W=70) still fails at 
20% increase: W=84.

I see no such failures across my sweep (4800 different architectures at W_min 
and 1.2*W_min) with the wilton SB.

Original comment by eddie.h...@gmail.com on 16 Feb 2012 at 8:57

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by jeffrey....@gmail.com on 16 Feb 2012 at 5:24

GoogleCodeExporter commented 9 years ago 
It has always been true that sometimes one gets unlucky in the switch patterns 
generated at a particular channel width, making it unrouteable when a smaller # 
of tracks is routable.

Original comment by Jonathan...@gmail.com on 16 Feb 2012 at 10:13

GoogleCodeExporter commented 9 years ago 
Fascinating. I know subset and universal are rarely used (and I included them 
in my sweep just out of curiosity, and I don't strictly need them for my 
analysis), but is there any way to swing the odds in our favour? 

I feel like using binary search to find its minimum channel width can be a 
little bit misleading in this case...

Original comment by eddie.h...@gmail.com on 17 Feb 2012 at 6:56

GoogleCodeExporter commented 9 years ago 
There have always been some issues with binary search, like this.   However, if 
you're running an experiment, and looking at  your data carefully,  you can see 
it in an individual circuit.

When you run a multi-circuit experiment, the numbers tend to average out and 
the few anomalies don't dominate (unless there really is something broken about 
the pattern, in which case you'll see that too).

Original comment by Jonathan...@gmail.com on 17 Feb 2012 at 5:52

GoogleCodeExporter commented 9 years ago

Original comment by JasonKai...@gmail.com on 9 May 2012 at 8:29