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?