Typical Overflow ?

Hi Houman,

If you're talking about the following trialRoute output: (just before the Congestion Distribution table)

Phase 1f route (0:00:01.4 809.2M):
Usage: (19.5%H 20.1%V) = (6.054e+06um 7.331e+06um) = (4324061 2909069)
OvInObst: 0 = 0/60 (0.00% H) + 0/4518 (0.00% V)
Overflow: 74 = 4 ([b]0.00% H[/b]) + 70 ([b]0.01% V[/b])

A very general target for trialRoute overflow numbers is 0.01%. This is not to say that the design is unroutable if the numbers are higher. You just need to investigate the congested areas and maybe try an early nanoroute to check that trialroute is correlating well. Your particular design may be fine with 0.04%, for example. If I see numbers around 0.10% or higher, there is usually a problem, but most of the time it can be fixed by adjusting the floorplan (moving rams, adding blockage around corners, etc.).

I don't really notice this guideline changing with the number of routing layers in a design, which makes sense since it's just a percentage of overflowed gcells. If you have too many overflowed gcells in any technology, routing will be difficult.

The Encounter User Guide has a good description of all the trialRoute results.

I wonder if some other designers here have different numbers that work for them?

- Kari

Hi Houman,

If you're talking about the following trialRoute output: (just before the Congestion Distribution table)

Phase 1f route (0:00:01.4 809.2M):
Usage: (19.5%H 20.1%V) = (6.054e+06um 7.331e+06um) = (4324061 2909069)
OvInObst: 0 = 0/60 (0.00% H) + 0/4518 (0.00% V)
Overflow: 74 = 4 ([b]0.00% H[/b]) + 70 ([b]0.01% V[/b])

A very general target for trialRoute overflow numbers is 0.01%. This is not to say that the design is unroutable if the numbers are higher. You just need to investigate the congested areas and maybe try an early nanoroute to check that trialroute is correlating well. Your particular design may be fine with 0.04%, for example. If I see numbers around 0.10% or higher, there is usually a problem, but most of the time it can be fixed by adjusting the floorplan (moving rams, adding blockage around corners, etc.).

I don't really notice this guideline changing with the number of routing layers in a design, which makes sense since it's just a percentage of overflowed gcells. If you have too many overflowed gcells in any technology, routing will be difficult.

The Encounter User Guide has a good description of all the trialRoute results.

I wonder if some other designers here have different numbers that work for them?

- Kari

Apologies for the double-post and the garbled trialRoute result. I was trying to put some numbers in bold, but it didn't work. The trialRoute snippet should look like this:

Phase 1f route (0:00:01.4 809.2M):
Usage: (19.5%H 20.1%V) = (6.054e+06um 7.331e+06um) = (4324061 2909069)
OvInObst: 0 = 0/60 (0.00% H) + 0/4518 (0.00% V)
Overflow: 74 = 4 (0.00% H) + 70 (0.01% V)

Hi Kari,
Thanks for your reply
I was looking at a cadence design workshop notes and there it says the horizontal or vertical overflow when using 3 metal layers should be less than .5%. It could be upto 1% when using 6 metal layer! I am not sure how accurate this would be.

Thanks,

Houman

Hi,

The number also depend on if you are using higheffort with trialRoute. In my design I always has to use highEffort, or else trialRoute will always think there are congestion and start to detour and as a result timing closure with trialRoute become difficult.

I think it is always good to run a nanoroute early. This will give you an idea of the congestion. trialRoute has so many option and when trialRoute show congestion it may be you did not use one of the option....

Regards,
Eng Han

Hi Houman,

I guess it's hard to pin down a specific number to go by. All of my designs are kind of similar, so I sort of have a "feel" for a set of numbers that works for me. But they may be different for you. Also, as Eng Han mentions, different settings can affect these numbers too. But for 6 metal layers, 1% sounds extremely high. After a few correlations with nanoRoute, you should get a feel for your process.

- Kari

Thanks Kari and Eng Han, It was really helpful.

Houman

If you can solve all your routing congestion issues with trialroute -medium Effort (the default ) ot better still -low Effort, then nanoroute is going to have a much easier time of it.

I have seen cases where trial route -high Effort reported reasonable congestion numbers but nanoroute would never complete cleanly.

Also get used to looking at the GCell overflow display under "all colors" > "view only" this is the absolute worst case congestion scenario, every single Gcell overflow is shown..

AND as Eng Han pointed out "it is always good to run a nanoroute early"

Shawn

nHi everbody,
First thanks so much for your responds.

in the trial route I get a overflow of 0% H and 0.3 V,
after that, when the global detail routing is completed I get this :
#Max overcong = 10 tracks.
#Total overcon = 1.43%.
#Worst layer Gcell overcong rate = 8.56%.
 and also when I do a verify density it detects no violation.

I was just wondering if my design is routable?

Thanks,

Houman

Are you setting -updateRemainTrks for trial route? This option helps to better correlate trial route and nanoroute results.

setTrialRouteMode -updateRemainTrks

Determines whether to update congestion data after the layer assignment phase of Trial Route mode. Updating the congestion data displays congestion that is closer to the actual Trial Route result.

From past experience if the trialroute results with -remainUpdateTrks are > than 4% over congested then nanoroute will not be able to route cleanly.


Regards,

Elvis