Home > Community > Blogs > Digital Implementation > five minute tutorial setting up clock routing rules
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Five-Minute Tutorial: Setting Up Clock Routing Rules

Comments(7)Filed under: Digital Implementation, Routing, clocks, encounter, EDI, tutorial, five-minute, .ctstch, Shielding, clock routing

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 DoubleWideDoubleSpace
TopPreferredLayer 6
BottomPreferredLayer 3
NonDefaultRule DoubleWideDoubleSpace
End

RouteTypeName DoubleWideDoubleSpaceShield
TopPreferredLayer 6
BottomPreferredLayer 3
NonDefaultRule DoubleWideDoubleSpace
PreferredExtraSpace 0
Shielding VSS VSS
End

#-- Regular Route Type --
RouteTypeName regularRoute
TopPreferredLayer 6
BottomPreferredLayer 3
PreferredExtraSpace 1
End


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 clk
Period         10ns
MaxDelay       1ns
MinDelay       0ns
MaxSkew        200ps
SinkMaxTran    80ps
BufMaxTran     80ps
AddDriverCell  BUFX4
Buffer         BUFX1 BUFX2 BUFX4 BUFX8
NoGating       NO
DetailReport   YES
RouteClkNet    YES
PostOpt        YES
OptAddBuffer   YES
RouteType      DoubleWideDoubleSpaceShield
LeafRouteType  DoubleWideDoubleSpace

END


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

Comments(7)

By divya on May 11, 2011
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?

By Kari on May 11, 2011
Hi Divya, yes - any spacing rule for a metal layer is with respect to that same metal layer.


By pfloe on June 22, 2011
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?

By Kari on June 23, 2011
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!
- Kari

By Bharath on January 9, 2013
Is there any to find out how many nets are violating the NON DEFAULT RULE ?

By Bharath on January 9, 2013
Is there any to find out how many nets are violating the NON DEFAULT RULE ?

By Kari on January 9, 2013
Hi Bharath, You can use verifyGeometry -useNonDefaultSpacing to check that.

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. 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. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.