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.
Anyone has seen bad local congestion with Encounter 6.1* after CTS? In
my previous project, I had issue with this. In my current project which
use a much larger process technology I am face with this issue again. I
don't have this issue before with 5.*.
With the local congestion, optDesign is not able to size some of the cells, result in plenty of large negative slack.
Hi Eng Han,Here's how I'd recommend troubleshooting problems like these...I think it's important to differentiate between local placement density and local routing congestion. Usually, we're alerted to these kinds of problems via the routing congestions markers trialRoute creates in the display. When I see areas of high routing congestion, I like to assess what the placement density is in that region using the "Query Placement Utilization" widget at the top of the Encounter GUI that allows you to draw a box and it reports back the placement density in the box. If that number is high (like greater than 90%) I'd agree that a you have a situation where high local placement density is causing local routing congestion.From there- how to solve it? There's a lot of different things that can cause this to occur. I'd recommend determining at which stage in the flow the problem first presents itself. If it's truly only at the CTS stage and no earlier, a couple of things to look for would be:1) In the area of local routing congestion, select all of the clock buffers ("selectInstByCellName *CKBUF*" is an easy way) and determine if there's a lot of clock buffers in the area. If there are, then it would be useful to reserve space in this region for clock buffers. You can do this with cell padding, perhaps on all the flops in the design ("specifyCellPad"), placement density screens, or by asking the placer not to exceed a maximum density (setPlaceMode -maxDensity").2) The problem could have to do with the routing rules you're using for your clock nets. If the width, spacing, or shielding of the clock nets is too aggressive it may just be too darn hard to route the clock nets the way you're requesting. BTW, it's recommended to do routing concurrent with CTS in Encounter (RouteClkNet YES) in your clock tree spec file. Further, you might want to relax the width of the routing only at the leaf level ("LeafRouteType" in your clock tree spec file).Finally, I'd be curious to find out whether the problem occurs prior to optDesign -postCTS -or- after. If after, then I'd be especially curious whether hold fixing is causing the density problem or setup fixing. If hold fixing, the cell padding approach would be applicable, and it would also be worth checking out your hold uncertainty to make sure it's not unrealistically aggressive.Please report back your findings and whether you've been able to resolve your congestion issues. I'm sure others would be interested in your findings.Hope this helps,Bob
Hi Bob,First to clarify my issue. I should say "high local placement utilization" and not "local congestion". There is no congestion even when with the high local utilizaiton. The local utilization is very high. By eyeball, it is almost (or it is) 100% for more than 10 rows and 30-50 std cell width (I cannot remember exactly, this is my impression).There is no issue before CTS (so physical synthesis part is okay). Also, I have not perform fix hold, so the problem occur only during CTS.I study the issue breifly. I think it is due to the tool size-up all the clock gates (CG)r. The design uses RC to insert cg even only when one FF is gated. So the design has 7000+ CG. Before CTS, most of the CG are 2x. After CTS, most of the CG are 12x and 16x. I believe this is causing local congestion.Now, before you think I have issue with my CTS specification file, I have tried many things. I have used mainly default setting, relaxed setting, and many in-between. I end up disable the high drive CG. It helps some, but not completely.Now again (:>) before you double my technology, I am using TSMC 0.18um lef, captable (with co-relation with QX), etc etc. This library cannot be that bad, correct?Back to my observation and feeling. I don't have this issue when I use 4.* and 5.* but for 2 consecutive projects I have this issue. I tend to think there is something in 6.* that make this happen. Of course I can be wrong; I hope to hear from the users of 6.* if they also face the same issue. Also, spread out the cells to ease local congestion is a basic function of the placer. Although all the cells have been placed, and CTS suppose to make minimum movement of the cells, I think something can be done here in an automated way.By the way, in a previous project I try to use cell/instance padding but it does not seem to be supported anymore by the new moduleplan placer. I am not 100% sure here...Regards,Eng Han
I think i had seen the same problem in my design. I think the problem is with the new placement engine in 6.2 (default modulePlan). It tends to cluster cells much closer(for timing) than the old placement engine. You might want to try the same design/script but turn off the modulePlan placement engine (-noModulePlan?).li siang
I am answering my own question I posted in this thread.I confirm that cell padding is supported by 6.1USR3 with moduleplan. I am using it now.Regards,Eng Han