How Good Are Your Clocks?

One of the trickiest tasks in designing a modern SoC is getting the clock tree(s) right. The two big reasons for this:

• the clocks can consume 30% or more of the power of the whole chip, so minimizing the number of buffers inserted is critical to keeping power under control
• the clock insertion delay and clock skew have a major impact on timing. If a flop on the early side of the skew window drives a flop on the late side, or vice versa, it can consume a large part of the setup/hold margin and so affect the maximum clock frequency that the chip will work at

The clock-tree is actually constructed during physical design during the clock-tree synthesis (CTS) phase. This is driven by constraints provided by the design team and so a large part of producing a good clock-tree is creating good constraints.

An additional issue is that increasingly SoCs are built out of blocks of IP assembled together. Typically the IP blocks are designed by a “front-end” design team, often overseas, and the physical design and assembly is done by a “back-end” team at the headquarters.

But this leads to another problem. The front-end designers have to come up with good constraints, plus avoid producing inherently unbalanced logic that will be difficult to clock. However they don’t think like back-end designers and don’t understand the physical CTS process well.

Meanwhile the back-end team doesn’t understand the clock structure well, and by that stage in the design process has little time for interaction. They will typically run with whatever the front-end teams gave them and do their best to close timing with what they have. But it is frustrating and may be impossible to close timing with a suboptimal clock tree.

ICScape has a tool, ClockExplorer, that addresses these problems. It provides front-end designers with feedback on the quality of the clock tree to find errors or suboptimal design. Structure and constraint checking can also evaluate clock quality, and help front-end and back-end designers to identify design problems that should be fixed early.

It then allows the front-end designers to communicate this information to the back-end designers and gives them similar feedback. It can also be used after CTS to do a more in-depth analysis taking the physical information into account. Of course at this point it can display a layout view, showing where the actual clock-paths run on the physical chip. For each problem, ClockExplorer can identify the problem, detail what issue it will cause and explain what needs to be changed to fix the problem. In this way it allows less experienced designers to be effective and avoid creating problems that will only show up later.

Note that ClockExplorer does not create the actual clock tree, that is still left to the CTS. ClockExplorer is a tool that allows front-end and back-end designers together to create good clock constraints, which in turn will lead to better clocks, lower power, and a fast timing closure process. In short, better CTS QoR.

ClockExplorer allows designers to look at a schematic of the clock tree. Since all the datapath elements are suppressed, it can handle extremely large designs very fast. For front-end designers it produces a timing dependency report, reports suboptimal structures, missing constraints and so on. It can automatically identify false paths or unnecessary balancing, and so minimize the number of buffers that will need to be inserted. The clock tree can be displayed by level or by delay.

As an example of its use on a 28nm design with 600K instances it reduced the clock tree buffer count by 40%, the hold time total negative slack (TNS) by 80% and so on. See the table below.

In summary, ClockExplorer is a tool offering structure and constraint checking, constraint optimization, and clock tree debugging.

More details on ClockExplorer are available on the ICScape website here.