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

Pre-CTS clock path timing analysis, automation

Posted: 08 May 2013     Print Version  Bookmark and Share

Keywords:VLSI  timing closure  clock tree synthesis 

Tools do have built-in fanin/fanout commands (i.e. commands to report the input or output cone given a pin) but these are 1) timing graph based reports and not structural reports; thus, if case-analysis or mode-based disabled arcs break some paths it would not be shown 2) the reporting format is not user-friendly. So, one has to go through the tedious process of manually traversing through the netlist to find the exact cause of the problem or load the desing without any case analysis. The better way is to have some automation for reporting fanin/fanout structurally (and not timing graph based) along with the case analysis reported in parallel. This allows the designer to report 'fanin' starting from generation node or report 'fanout' starting from the master node and see exactly where it breaks because of the wrong case analysis or the design defect. Figure 4 presents the graphical representations of some of the possible cases that may result in broken clock paths. We then present a format that may be used to report the tracing of fanin/fanout from a pin passed as an argument.

Figure 4: A few cases leading to broken clock paths in designs. (First two cases show the absence of logical connection between master and generated clocks, last three cases represent the case of structural connection missing/design defect.) (Click on image to enlarge.)

The above formatted report is to trace the fanin for an unclocked flop. Above report shows that the clock pin of the flop has a buffer in immediate fanin, which in turn is preceded by an and gate and so on. From this report, the reason for the clock not reaching clock pin is clear (The E and TE pins of clock gating cell are 0). The procedure we used is shown in figure 5.

Figure 5: Flowchart for procedure to trace fanin/fanout in tree format and help analyse broken clock paths. (Click on image to enlarge.)

Dealing with clock reconvergence cases in the design
Before the clock tree is implemented, it has to be ensured that the clock structure is correct and in accordance with intended design architecture. Also, the case analysis forced for a particular mode should be verified thoroughly. After the clock tree is implemented, clock path timing starts making its presence felt. Complex VLSI designs today have multiple clocks where the customer can choose to have any of them selected at any desired frequency. This leads to a lot of clock multiplexing in the design and thus there may be multiple clocks reaching the same clock pin through different paths. In fact, even clocks from the same source might take different paths to same sink in different modes. Merging multiple timing modes in a single run is prevalent in timing analysis making all sorts of paths visible simultaneously.

Besides mode merging there are very few genuine clock reconvergence cases and the more common cause would be inadvertently introduced logic defect in the design. Identification and categorisation of the reconvergence cases is all the more important because these false reconvergence cases in the design add undue pessimism to the timing analysis. Why? Because the default behaviour of the EDA tools is to assume the most pessimistic clock path combinations while analysing the design. Let's have a more detailed look at the scenario.

Figure 6: A classical case of reconvergence showing effect of CRPR on CPPR calculation.

The way EDA tools handle the reconvergence is through 'Clock Reconvergence Pessimism Removal' (CRPR) which essentially controls the calculation of Common Path Pessimism Removal (CPPR) in timing analysis. If there is any reconvergence in the design (like the one shown in the figure 6), we may choose whether to calculate CPPR (clock path pessimism removal) upto POINT 1 or POINT 2. CRPR should be pessimistic (upto POINT 2) only for real intentional reconvergence cases. There are two possible ways to deal with false reconvergence cases in the designs. One of these cases is to identify all the false reconvergence cases and defining mutually asynchronous clocks along the two diverged branches. By doing this, we make sure that the divergent clock paths are never taken into account simultaneously. But doing so is very tedious job and introduces complexity in timing analysis as there are a lot of reconvergent clock cases present. So, the number of clocks to be defined becomes huge and it requires a lot of effort to analyse.

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

Comment on "Pre-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