Global Sources
EE Times-India
EE Times-India > EDA/IP

Post-CTS clock path timing analysis, automation

Posted: 14 May 2013     Print Version  Bookmark and Share

Keywords:RTL  verification  clock tree synthesis 

Thus, we see that uniquified clock paths reduce in number as we move towards the root of the clock tree. As there is more number of flops in fanout of the root, hence, more number of paths covered. Some will be setup critical, while others will be hold critical. As we move towards the root, probability of finding both setup and hold violating paths increases. Hence, the probability that setup and hold will be impacted on pushing/pulling increases. In general, we can say that the probability to find the scope to push/pull clock is more near the sinks. Figure 2 the procedure that we used to uniquify clock paths.

Figure 2: Procedure to unqiufy clock paths.

Balancing clock paths for optimal skew
As mentioned earlier, it is possible to uniquify clock paths for top violating paths and find out which clock branches are the culprit ones. We may, then, want to play with the culprit branches so as to get rid of the timing violations through it. But, to treat it the way we want, it is necessary to know the timing profile for all the end-points through the branch. In designs, there are two kinds of paths that concern designer. Some are setup critical while others are hold critical. Setup critical paths are the ones with large number of logic levels. On the other hand, hold critical paths are those with lesser number of logic levels. It may be the case that the signals being launched from one branch of clock tree are setup critical. So, we can afford to build that branch at a slightly lesser latency than other clock branches so as to make these paths less setup critical. Similarly, if the paths being captured on the flops on a clock branch are setup critical, we can afford to build it at a larger latency. The reverse is true for hold critical paths. So, if the clock tree is balanced, there will be some clock branches that have margin to be pushed while others can be pulled by certain margin. After first level of optimisation, there will be some paths that will be violating on setup side while others will be violating on hold side. Mostly, these paths exist in bunches. So, instead of optimising bunches of data paths for setup or hold, intelligent tweaking with the clock skew may be a better option.

E.g. Let us say, the paths ending at most of flops from a clock branch are violating in hold. So, pulling this branch by a certain margin will help. But, same paths will deteriorate in setup. So, if there is not sufficient margin in setup at these points (except for a few points that can be managed easily), there is no point in pulling the branch of clock tree. In general, pulling a clock branch degrades setup timing for paths ending at the branch and hold timing for paths starting from the branch. Similarly, it eases setup timing for paths starting from the branch and hold timing for paths ending at the branch. The reverse is true if we push a clock branch. It may be a better option to add 1-2 clock buffers rather than optimising 100s of data paths.

 First Page Previous Page 1 • 2 • 3 Next Page Last Page

Comment on "Post-CTS clock path timing analysis,..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top