Clock tree synthesis, who’s responsibility?

During the physical implementation phase, I have seen engineers keep pushing the task of CTS (Clock Tree Synthesis) back and forth between the placed-and-route engineer and the engineer that delivers the netlist and constraints (Toplevel integration engineer). If the design closed timing, then everyone is happy. But when it is failing timing, which might be pretty late on the design phase, then the engineer start to push the responsibility around. I bet everyone has gone through that phase.

The ONLY solution is both engineers has to work together to UNDERSTAND both the logical behavior of the clock tree and the physical restriction in the early phase of the physical implementation. Note, even with the CDC clean netlist does not mean you have a clock tree that will work properly in the physical world. To make it worse, sometime clock tree synthesis is not part of the project planning and the management cannot comprehends the complexity of the clock structure.


Design Aspect:

It starts from the design phase where the clock structure is architect. The fundamental idea is to keep it simple and reduce the level of MUX. And if possible keep the clock logic in a single block/module. A clock diagram is a MUST, both for designer to verify the structure and to guide the PnR engineer in CTS. The “set_false_path” command  between clocks is for timing closure, might be not true for CTS. If logically a clock path is crossing to another clock domain accidentally, CTS will most likely assume those endpoints are part of the clock group. Flops used as dividers and other clock function within the CLOCK module might not necessary needs to be CTS, sometime special care is needed to ensure CTS is done correctly.

Physical Aspect:

Pay attention to FFs in the clock modules, most likely those FFs might not need to be balance with the design endpoints. Designer will need to confirm the clock structure, and also any logic that has clock propagating through. The chances of a “unwanted” clock snicking through is high if the design has a complex clock structure. It could be going through a MUX, an AND/OR gate or *AOI* gates. It doesn’t matter if functionally the clock is gated off, a good example will be a MUX that has a CLK1 and CLK2. The tool will see both of them and try its best to balance and make it work, this might cause issue in insertion delay etc. With in depth understanding and study of the netlist, correct “sinks, ignore and non-stop” points are inserted to control the “flow” of the clock. Pay attention to undesirable endpoints and ignore points. Some macro IP does not have clock pin define in the liberty file, PnR engineer will need to explicitly set it.



Both side engineers will have to understand the clock tree and do it as early as possible. First of all, the front-end engineer will have at least have a clock diagram in place. It is a benefit for the designer, as well as, the back-end engineer. Sometime it is hard to piece together the full toplevel clock structure. Start with the full chip SDC, pay attention to the relationship between the “create_clock” and the “create_generated_clock”. Draw it down and trace out the logic, that should give you an overall picture of the clock structure. Next, review those “async” clock group and “set_false_path” to make sure not clock domain crossing. Look for IP block that has clock logic in it, you might need to control them during CTS.

With all the information collected and drawn down, it is time to share it with the PnR engineer. Once the design is placed, the PnR engineer’s job is to scout around for clock related logic in the placed database. This is to ensure that clock logic is correctly placed, and not scattered all over the place or placed in a undesirable region of the floor plan. Identify flops inside the clock module and highlight them to the front-end engineer. Using the PnR tool to report the clock structure of the design (Pre-CTS) and review them with front-end designer. After the discussion, tweak the clock constraint and repeat the process until the Pre-CTS clock structure report is correct. Example if the CPU clock is ONLY driving 50 FF and the report is showing like 80 FF. Then something is wrong, maybe another clock has accidentally merged with CPU clock. Find the interception point and block it. Once this phase is done, go ahead and run your clock tree synthesis. Take note of the runtime and the insertion delay, and do a Post-CTS clock structure report. Review the shortest and longest clock path per skew group, if congestion is not the issue then it might be a design constraint problem. Finally, communicate the findings and concerns to the front-end engineer of how it might impact the CTS. There is NO one man show here, failure in ironing out the structure will only delay the project more.

Hopefully, this short article is able to help engineers to understand the importance of clock planning more and work out a solution that benefit both the front-end and back-end engineers.



0 Responses to “Clock tree synthesis, who’s responsibility?”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


My Gallery

Currently, I am posting my photographs on Imagekind. Their service provides international shipping. For more information, please refer to the links below.


Buy my art at ImageKind.com.


Return Policy

Contact Imagekind

Yosemite National Park Gallery

Alum Rock Park Gallery

Mono Lake

Some of my older postings

%d bloggers like this: