detailRoute vs trialRoute

Hi Rajesh,

There's not a way to have reportRoute key off trialRoute differences instead of half-perimeter net wirelengths.  Would you explain a little more the scenario(s) you're seeing that this information would be particularly helpful?  It might give us reason to pursue an enhancement to the tool.

The net lengths are *not* stored as part of the net object in Encounter.  There are "dbNetLenX" and "dbNetLenY" but if you create a serpentine route you'll notice that it's more of a half-perimeter number that's reported.  Here's a code example I cooked up that leverages dbGet to capture wire coordinates and adds up the total wire length:

set totalLength 0
foreach pt [dbGet $net.wires.pts] {
  if {$pt != "0x0"} {
    set a [lindex $pt 0]
    set ax [lindex $a 0]
    set ay [lindex $a 1]
    set b [lindex $pt 1]
    set bx [lindex $b 0]
    set by [lindex $b 1]
    set xlen [expr $bx - $ax]
    set ylen [expr $by - $ay]
    set len [expr abs($xlen) + abs($ylen)]
    set totalLength [expr $totalLength + $len]
  }
}
puts "$totalLength"

Maybe you could use this on your design as a starting point for comparing whether trialRoute vs. detailRoute is more enlightening than half-perimeter vs. detailRoute.  Let us know what you find, and if I can be of further assistance on scripting especially.

Thanks,
Bob

 Bob,

Thanks for the script.The only limitation in the script is that trialRoute and detailRoute wirelengths have to be computed in a different databases.If the netlength information is stored as part of net object, we can query it easily.

Here are some reasons, i feel, why we should have a trialRoute vs detailRoute comparison

1. In case of multi-fanout nets half-perimeter lengths are way-off compared to the detail route. Trial route might be a good indicator as it is based on steiner route.

2. Since all the optimizations are based on trialRoute information, it would make sense to have a correlation between trialRoute and detailRoute readily available.

3. Does layer assignment happen while calculating half-perimeter net lengths?

If net lengths are not stored as part of net object, does it mean reportWire calculates the wirelength (both detail and half-perimeter) everytime it is invoked. For a larger design with millions of nets this could have a big runtime hit.

Thanks for the feedback on the reasons why trialRoute vs. detaiRoute comparison would be useful.  I will pass this along to our developers.  In parallel with that, I'd encourage you to file an enhancement request with the Cadence support folks you work directly with on an ongoing basis, or on http://support.cadence.com

You're right that the trialRoute lengths with the script example I shared would need to be stored (via a hash table or a side file) in order to use it to compare to detailRoute.

Half-perimeter net lengths are (I believe) what are stored in dbNetLenX/dbNetLenY so I don't think it needs to be recalculated on the fly.  I could be wrong on that though.

I can see there being complexity in implementing what you're requesting from our developer's perspective.  Say for example, someone runs trialRoute and then edits the routes manually.  Then they save the design and exit the tool.  Then they restore the design.  Then later, at some point, they call reportRoute and want it to compare trialRoute to detailRoute.  I can see it being non-trivia for the trialRouted lengths to be accurate and persistent in this scenario.

I hope this helps understand why this isn't straightforward.  Thanks for raising this issue- even if we don't have this capability straight away, I think it's useful to understand the subject a little better and know what options are/aren't available if you or other users are working in this space.

Hi,

I have a question related to this topic and would appreciated if someone could help: I have a design which trialRoute and globalRoute cong map show good congestion and timing. globalDetailRoute however detour a group of signals (about 100) around one memory (where trialRoute just route straight through) which causes 400ps timing difference for this group. "optDesign -postRoute" couldn't bring the timing back to pre-route (~ -100ps WNS). The design still routable. Any comments, suggestions?

Thanks.

Khanh