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 

As we all know, SoC design flow involves two processes: frontend, where RTL coding and verification of design intent are performed, and backend, where actual physical implementation of design takes place. It is quite apt to say that backend cycle also consists of two sub-processes – i) Before clock tree has been implemented, also known as pre-clock tree synthesis (CTS) stages; and ii) After clock tree has been implemented (post-CTS stages).

As we have discussed in Part 1, pre-CTS stages include synthesis of the RTL logic into gate-level netlist mapped to technology and placement of the design modules. In pre-CTS stages, clocks are considered as ideal and focus is mainly on data path optimisation along with clock architecture understanding and exploration. From timing point of view, clock paths come into picture at post-CTS stage. Here, clock skew, clock reconvergence (if any) and clock path parasitic elements start making their presence felt and pose an additional challenge to timing closure process, presenting a post-CTS timing profile that is entirely different from the pre-CTS one. So, it is very important to manage clock paths efficiently for optimum clock latencies and clock skews. SoCs today have complex clock architectures and clock tree synthesis usually ends up generating lot of diverged clock paths, it thus becomes important to organise and intelligently bin these paths to effectively debug potential clock skew/latency problems. Similarly in routing/signal-integrity phases of the design manual techniques like clock buffer insertion, sizing etc are taken up so as to meet critical timing paths without disturbing rest of the design. We have tried to present some techniques to deal with clock path timing in physical design flow. In this paper, we will be dealing with post-CTS timing analysis techniques only as we have already covered pre-CTS techniques in another article before.

Analysing uniquified clock paths
Static timing analysis is all about timing paths that may amount to millions; with each end-point having multiple startpoints. On the contrary, number of paths traversed by clock is fewer. The clock is generally built in the form of a symmetric tree having very few roots (equal in number to the number of sources) and the number of sinks is equal to the number of sequential elements (or we can also call them as end-points) in the design (Flops, memories, latches etc.). If we look at clock path upto each sink, in a particulare mode, the number of clock paths is also equal to the number of sinks (may be greater if we merge modes as more than one clock might be reaching a clock sink or same clock may be taking more than one paths as mentioned above, but is comparable to and is of the order of number of end-points). If we ignore the last level of clock tree buffers, total number of uniquified clock paths becomes much less as each buffer will have a fanout greater than or equal to one. The more we go away from the sinks ignoring more levels of buffers, uniquified clock paths become less and less. It is important to find the uniquified clock paths in the design so that the timing profile through these points may be found out. Timing tools concentrate mainly on meeting the timing by optimising the logic in data paths as clock tree is set don't touch. More than often, the violating paths exist in bins after the first level of timing optimisation by the tool has been carried out. So, instead of optimising data path logic, we may get away with clock tweaking for a few branches (as mentioned below in next point). That is why, it becomes very important to find out what all clock branches are the ones that are violating for both setup and hold. Doing so, we can figure out which points to focus on for scope to pushing/pulling. Doing so can save us from unnecessarily optimising data paths for setup as well as for hold. We developed a procedure that returns the uniquified clock paths for the timing paths passed to it as argument. Figure 1 shows the sample output of the procedure when passed top 10000 violating paths as argument to it.

Figure 1: Contents of file uniq_launch_paths_5_levels.rpt.

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