Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Hi,I just wonder how much is the typical horizontal and vertical overflow so that the design be routable. I think this should depend on the number of metal layers in the design, I am using 6 metal layers in my design.Thanks,Houman
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 replyI 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 -updateRemainTrksDetermines 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
Houman,I would try to figure out why you're getting the .3V in trialRoute. I always look at the "thermal" congestion map after a trialRoute. In 6.2, on the All Colors form, in the View Only tab, turn on Horizontal Congest and Vertical Congest (or in your case, just turn on vertical). The "hotter" the color, the more congestion. Pink and white are very bad. Usually I will see this in an area that can be fixed by a floorplan modification. In versions prior to 6.2, you didn't have to open All Colors to turn these on. They were just on the side, called HCongest and VCongest.I don't usually look at the nanoroute overcon numbers, so I'm sorry I don't have any advice there. :-)- Kari