clock tree quality

Hi, Rajesh,

From timing consideration, if a clock tree make the timing closure easier or could make it with larger margin (for example, allow larger clock uncertainty), then, I will think this clock tree is better.

Generally, timing closure is the first priority, therefore, the above criterion is the king.  Also, other factors may get in. such as insertion delay (or level of clock tree). Too large the insertion delay (or too many clock tree level) may create other issues like power assumption, OCV, routing conggestion (sometimes, we need to use wider wires, larger space, and even shield for clock wire).  So, physically, I like the clock tree as simple as possible.

 Another thing I will look into it is the final standard cell density in the block  and total routing wire length after timing closure.  If the clock tree is not perfectly fit into the design, the hold timing opt may add thousands and thousands of buffers/inverters and therefore, make the block very crowded, which may even impact the routability of the block. So, check the density and total routing wire length after the timing closure achieved.

- Gele

Hi Gele,

Thanks for the quick response. However, trying to check for timing closure could result in a huge TAT.

Is there a quick and better way to gauge the quality of the clock tree just after cts is done?

- Rajesh

Hi, Rajesh,

If only judge from the clock tree itself, I will take one with smaller skew.  Before a clock tree exists, idea (zero skew) tree is used during the synthesis and pre-CTS opt. If the clock tree has small skew, the chance is higher that we will not see any big surprise when we check timing after CTS since the actual clock tree is very close to idea clock. 

The other parameter we need to check is the insertion delay. This should satisfy the front-end requirement. If the insertion delay is too huge, it may make the timing outside of this block hard to meet.

You mentioned that you have different ctstch files. If you like to compare "apple" to "apple", you could clean up a ctstch file after you have the clock tree built according to it using cleanupSpecifyClockTree command and then, reload a common one by using "specifyClockTree -clockfile the_common_ctstch_file" and report your clock tree (reportClockTree).

Gele

 Hi Gele,

Thanks for the information. I too was thinking on the same lines and tried to reload the common spec file to report and compare. However i'm not sure if the metrics reported are correct. For example, no. of buffers for the clock roots are reported as zero (proably because the clock tree was not built using this clock root) while insertion delays and skew numbers had some values.

 As i mentioned in my initial post, i would like to compare the clock tree quality from a wide range of metrics. Probably the clock tree area and power also plays an important role.

 If you can think of any metric, other than the ones that we had already gone over, it would be great.

-Rajesh

Hi, Rajesh,

 After I reloaded a new ctstch file, the clock tree report did include the clock tree buffer number and clock tree level information. My new ctstch file and the old one that I used to create the clock tree only differs a little in the sub-tree handling portion, so FE still could get the built tree recognized correctly.  Also, 7.1 is the FE version that I was using...

Gele

 Hi Gele,

I guess it depends on the clock root definition.

Case 1 : i have a place-holder buffer, connecting to input clock pin, inside the core and set that as AutoCTSRootPin and build a clock tree from there 

Case 2 : Define the IO clock pin (driving the place-holder buffer) as the AutoCTSRootPin.

If i try to load in the case 2 ctstch to report the metrics from clock tree db (done using case 1), the results would not be correct as the clock tree was not built from the IO pin.

But the other case (loading case 1 ctstch in case 2 clock tree db) could provide the correct (?) results.

- Rajesh

Note : This is just one case mentioned for explanation purpose. As we go  through reconvergent-clock clock root definitions, it could get complicated.

Hi, Rajesh,

 That is a good observation! In this case, probably, it will be more reliable to write a tcl script to trace down the clock tree from the clock root and record all the buffers (even clock gating devices) to create a summary about buffer usage inside a tree by yourself.

- Gele

 Hi everyone,

This seems to be an interesting topic! All the metrics you mentioned so far (both of you), are indeed quite important. Usually we are concerned about timing closure and our designs actually being functional that we tend to forget that the clock tree is the major contributor of dynamic power consumption. So, in a design where power consumption is a hard constraint, I would perform IR drop analysis to the two designs and estimate their power consumption using a common VCD file.

 As another experiment, I would run the same test but this time instead of using buffers for the clock tree I would use inverters (generally smaller, faster and less power-hungry than buffers) and see what happens.

-Alex

Good!

http://www.pspcool.net

 Once your CTS result meet or close to your clock spec, it's good.

There is no common standard for the CTS quality and it really depands on your design requiremt.