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, and welcome back to another Five-Minute Tutorial! Yes, I know it's been a while, but like most of you out there, I'm an ASIC designer, and you know how busy work can get. (Blogging is not my day job, but I enjoy doing it when I have some extra time!)Today's topic is how to set up your clock routing rules in Encounter. This is best done in the .ctstch file, so that your clocks are routed the way you want from the CTS stage. I'm going to show you how to set up shielded clocks, because we are seeing that in 45nm and below, shielding the clocks is more important than ever in order to avoid noise on the clock nets. (Noise on signal nets is bad enough, but if your clocks are affected by noise, then your SI results are going to look REALLY awful.)At the top of the .ctstch file, you'll want to define your routing rules like this: (I'll use a double-width double-space routing rule as my example, but it can be anything you want. We find good results with double-width double-space and shielding most of the time.)
#-- Wide_wire Route Type --RouteTypeName DoubleWideDoubleSpaceTopPreferredLayer 6BottomPreferredLayer 3NonDefaultRule DoubleWideDoubleSpaceEndRouteTypeName DoubleWideDoubleSpaceShieldTopPreferredLayer 6BottomPreferredLayer 3NonDefaultRule DoubleWideDoubleSpacePreferredExtraSpace 0Shielding VSS VSSEnd#-- Regular Route Type --RouteTypeName regularRouteTopPreferredLayer 6BottomPreferredLayer 3PreferredExtraSpace 1End
Notice that we have 3 sections: the wide-wire type, the same wide-wire type with shields, and then a regular route type. If your design is not too congested, you may not even need the regular route type, but I've included it for completeness.For the wide-wire route type, it's important to note that we've matched it to a NonDefaultRule. This rule must exist in your tech LEF. (For details on how to create a nondefault routing rule if your tech LEF doesn't come with one, see this previous Five-Minute Tutorial.)That was easy, right? All we have to do now is tell our clocks how we want each routing rule to be used. This is done in the clock definition section:
#------------------------------------------------------------# Clock Root : clk# Clock Name : coreClk#------------------------------------------------------------AutoCTSRootPin clkPeriod 10nsMaxDelay 1ns MinDelay 0ns MaxSkew 200ps SinkMaxTran 80ps BufMaxTran 80ps AddDriverCell BUFX4Buffer BUFX1 BUFX2 BUFX4 BUFX8NoGating NODetailReport YESRouteClkNet YESPostOpt YESOptAddBuffer YESRouteType DoubleWideDoubleSpaceShieldLeafRouteType DoubleWideDoubleSpaceEND
What we're saying here is to use the shielded wide rule everywhere except the routes to the leaf pins. There, we'll just use the wide rule without shielding because there may not be room. This is a typical methodology that will work for most designs, but your design may vary. Are things very congested at the leaf route level? Use the regularRoute rule instead. Have plenty of room? Go for shielding at the leaf level too. The key is to go ahead and route the clock nets at the CTS stage with the "RouteClkNet YES" parameter. That way you get more accurate timing results from CTS onward because the clock routes are real (and not trial route estimates).One final note about the TopPreferredLayer and BottomPreferredLayer: I picked these numbers based on my metal stack. You will have to decide which top/bottom preferred layers are right for you. That's all there is to it! I hope you've found this Five-Minute Tutorial useful. Don't forget, you can subscribe to the Digital Implementation Blogs so you never miss a new one.Kari Summers
hi Neeraja, I don't know that there is any "common" tree used. It's really design-dependent. As for other shapes, I'm guessing you mean things like H-tree, etc. I don't have any experience with those, but if you post a question to the forum, then maybe some other users can chime in with their experiences. Thanks for participating in Digital Implementation!
Hi Kari, can we use a modified shape/ tree as the clock tree in cadence? Which is the common clock tree used now?
Hi Bharath, You can use verifyGeometry -useNonDefaultSpacing to check that.
Is there any to find out how many nets are violating the NON DEFAULT RULE ?
Hi pfloe, If you're using a NONDEFAULT rule, the extra spacing should already be part of that rule, so you shouldn't have to also specify preferredExtraSpace. Although I suppose there's nothing to stop you! But as you said, preferredExtraSpace is a soft rule. You do bring up a good point though - because even extra spacing contained in a NONDEFAULT rule is technically a soft rule. If you want it to be a hard rule, you have to do this:
setNanoRouteMode -routeStrictlyHonorNonDefaultRule true.
Check out this option in the EDI Text Command Reference for more information, and thanks for bringing this up!
Using default routing rules (or routing out of the box) preferredExtraSpacing is a soft-rule. When specifying preferredExtraSpace in a NonDefaultRoutingRule, is it then understood by nanoRoute as a soft or hard routing constraint?
Hi Divya, yes - any spacing rule for a metal layer is with respect to that same metal layer.
One query - when ndr is specified as DoubleWideDoubleSpace, then doublespace honored by the tool is w.r.t the same metal layer. Isn't it?