Avoiding Clock Tree Synthesis (CTS) Pitfalls. This application note discusses some common problems that many design engineers today face when they try to run CTS. It also suggests steps you can take to avoid these problems. It is always a good idea to invest the time at the beginning to understand the clock structure and the clock gating in your design. You should also know where your gating elements are placed and the topology of your floorplan including the location of sync points. That will ensure that you are building clock trees that will give you good timing results. This knowledge will also help you make clock tree decisions that will help CTS build better quality clock trees.
The following list provides suggestions for dealing with problems you may encounter. A. Big insertion delays. Some of the things you can check if you have big insertion delays are:
1. Are there delay cells in the design?
Check to see if there are delay cells in the netlist that are present in the current design. These could be causing delay that cannot be optimized and CTS is building clock trees which match all other paths to this worst insertion delay.
2. Are there cells marked "dont touch" in the design? There could be cells in the design that are marked "don’t touch" which prevents CTS from deleting them and building optimal clock trees. 3. Can the floorplan be modified to be more clock friendly? Sometimes it helps to consider CTS (and timing) as a constraint for floorplanning. Long skinny channels leading to more long skinny placement channels will give both timing optimization and CTS problems. Consider using soft blockages or refloorplan.
4. Can you define new create_clocks that will assist CTS(divide and rule)?
Many times running CTS on the main clock pin is not the optimal way to build clock trees. It may help to divide the clock tree based on the floorplan and the syncpins and build sub clocks, then define the sync pins and build the upper main clock.
5. Are the syncPins defined correctly for macros?
It is a good idea to check the syncPins file to see if the sync pins make sense. Also check that the numbers are accurate and that the time units are correct.
6. If there are ignore pins in the design are they defined as ignore pins? If there are ignore pins in the design, make sure you define these as ignore pins before running CTS.
7. Have you used varRouteRules and propogated by astMarckClockTree? Defining varRouteRules helps to reduce the insertion delay. Define shielding, and double or more width rules for clock nets, and propagate them using astMarkClockTree.
8. Are the CTU buffers marked as "dont use"? Some technologies use clock tree buffers. Make sure you are using these only for your clock tree. Also make sure they are not marked "dont use".
9. Be creative and use different CTS intParams to get better results.
There are several CTS options in the form that you can try to change to get better or more desireable CTS results.
10. Use the Block option in CTS in the first attempt. This usually gives better insertion and skew results. If your design is less than 5% std cell utilization try the Top option.
11. CTO is designed to work on skew and will not reduce insertion delay once it is built. Try providing a higher skew goal during CTS.
12. Use inverters only to build the clock tree if possible.
13. Define variable route rules with greater than default widths and clearance and also shield the clock nets. Then propagate these rules using astMarkClockTree. This will help insertion delay.
B. Unreasonable skew.
Some of the things you can check if you have unreasonable skew are:
1. All the above except A(11).
All the issues discussed above also apply to skew debugging.
2. Do you have derived clocks that do not need skew matching? If you have clocks that get divided and some branches do not need skew balancing with the rest, then build clock trees for them separately and do not allow skew calculation between them. You can define sync pins or ignore pins at cross-over points.;
3. Look closely at your worst path(s) for possible culprits. It is quite likely that some of your worst paths have an issue which is preventing CTS from optimizing them and is causing all other paths to get delay added to match the insertion delay or better skew.
4. Use intParams areaBased and ECOWinSize to help the Overlap Removal (OV) engine..
C. CTS doesn't run properly. Some of the things you can check if CTS doesn't run properly are: 1. All of the above.
For general quality of results issues, all the above points should be checked.
2. Are the SDC constraints loaded and is create_clock defined? If there are no create_clock statements in the SDC file loaded, CTS will not run. Make sure you have at least one create_clock in your SDC file. It is good practice to have set_clock_transition, set_clock_latency, and set_clock_uncertainty also defined. For the SDC latency values to be honored, the intParam axSetIntParam "acts" "clock uncertainty goal" 1 should be set. CTS uses constraints in the CTS form as first priority, then it uses the constraints in the intParams, and then it uses SDC constraints. Having these in the SDC file will also enable the timer to account for your skew and insertion delay in optimization steps.
3. If you have multiple create_clock statements in a path, did you set the "define ataPropagateClockThruCreateClock" correctly?
This is a new define parameter in the 2003.06 release and it needs to be set correctly.
4. Build the clock tree on lower clocks, then define the sync pins and run CTS on next level up (divide and conquer).
This is a good practice when building clock trees. Always remember to define sync pins if you need them.
5. astSetDontTouch ?clock_buffers.list? #f done?! If your CTS buffers have a "dont use" property in your library, you need to set that to false.
6. Are the clock nets marked "dont touch" or is set_case_analysis defined? Occasionally you may end up with a "dont touch" property on your clock net as a results of your analysis. Make sure you reset this using the astmarkClockTree command. Also if your SDC constraints have a set_case_analysis defined that disables the clock net, CTS will not build clock trees.
7. Is create_clock defined on a non-physical hierarchical pin? If you define create_clock on a pin that is not present physically and is only present in the heirarchical netlist, CTS will not be able to run.
8. Try different CTS options and use the one that gives the best results. As always, it is a good idea to experiment and try out different CTS options and intParams to get the best result.
Ignore pins are user defined. Commands such as ataDefineIgnorePin and dbDefineIgnorePin can be used to mark pins that do not need to be balanced during CTS.
sync pins is defined by user,Just one constraint,Astro will consider the constraint when do CTS.CTS understand sync pins and try to improve skew, based on the syncPins.
About Timing analysis,Just check your timing report,Find the timing violation path. Try to fix them. 1. If the timing violation caused by High Fanout,Try to insert some buffer,invert.debase the fanout number. 2. If you find the timing violation cause by long time path(net delay),Try to modify cell position.Move the cells together.(but you must consider congestion map)
3. If the timing violation caused by the cell driven strength,Try to gate size,change big driver cells.--buffer sizing,Gate sizing
4.If the violation caused by complex logic(net delay + cell delay > timing period) Maybe you need to redo synthesis.Get a better netlist. Optimztize your netlist.
5. Also, check your SDC file, Clock source delay/network and so on.
6. if the violation caused by the big clock skew,Then you need redo CTS/CTO
.......
What is timing ok? Most of customer will use Primetime to check it,No timing violation(Setup and hold) Postive slack,No max capitance violations,No trans violations.
ps,Astro cts will identifies the following pins as implicit ignore pins by itself. 1. A clock input pin of a logic gate that does not have a timing arc to its output pin 2. A clock input pin of a logic gate whose output is an open net (not connected to any logic) 3. sequential gate's clock input pin that does not have trigger-edge information 4. A sequential gate's input pin that is not defined as a clock port or pin 5. The boundary output port of the current cell Quote: Let’s say there enough routing resources available, timing is fine, can you increase clock buffers in clock network? If so will there be any impact on other parameters?
Yes, you can add buffers to your clock network, but why? If your timing is OK, why do you want to add buffers to your design? If you just want to increase the insertion delay of the clock by adding buffers just below the root, you can do that if you want (but why?). If you start putting buffers anywhere else in the clock network you risk increasing the skew and/or increasing the insertion delay. And, of course, more or bigger buffers means more dynamic power consumption.
Quote: How do you optimize skew/insertion delays in CTS?
Skew and insertion delay are parameters that pull against each other. If you want to decrease your skew you have to add more buffers which increases your insertion delay. The way CTS tools work is that first the flip-flops are clustered, then a buffer tree is built that distributes the clock signal with an acceptable slew, and finally buffers are added to balance all the endpoints in the tree. The details of the techniques are complex and typically trade secrets.
Quote: What are differences in clock constraints from pre CTS (Clock Tree Synthesis) to post CTS (Clock Tree Synthesis)
Pre-CTS constraints are called clock network latency and clock uncertainty. After the clock is built, these are measured as insertion delay and skew.
Quote: What constraints you add in CTS (Clock Tree Synthesis) for clock gates?
Clock gates, like any other sequential element, have a setup and hold check on their enable input. In other words, a clock gate adds another timing path (the clock gate enable path) that must be satisfied.
Quote: What do clock constraints file contain?
Clock constraints consist of some of the following: (a) clock definitions with a waveform, a source point, and a network latency and skew (b) source latency definitions for clocks (c) generated clock definitions (and virtual clock definitions) (d) input delays and output delays (e) balancing constraints (only in some formats - not SDC) (f) stop pins (only in some formats - not SDC) (g) timing exceptions such as multicycle paths and false paths (not strictly clock info) (h) guidance on desired tree structure (number of levels, gates to use, ...)
Quote: How to analyze clock tree reports?
Check if the insertion delay targets and skew targets have been met for all clocks.
Quote: How do you minimize clock skew/ balance clock tree
It is a difficult task almost always done by an automatic tool. You insert the correct types and number of buffers at the correct locations to balance the tree. Some older methodologies rely on H-trees or clock meshes, but these do not work well with modern technologies.
文章评论(0条评论)
登录后参与讨论