Games / Log forensics / Clock tree

Clock tree

Each case shows the tail of a real run, ending where the tool stopped or warned. Say what caused it, or what to do about it. A case you miss returns later in the round and starts its schedule over; one you get right returns after 1, 3, 7, then 21 days. Keys 1 to 4 choose an option, h shows a hint, and Enter moves on. Progress is stored in this browser.

SourceEach case is the tail of a real run of the gcd design on Nangate45 in the openroad/orfs container, with one thing wrong. The same failures happen on commercial tools in different words: what carries across is the reasoning from the last few lines back to the cause. Reference: the OpenROAD documentation (OpenROAD-flow-scripts on GitHub).

All 5 cases in this stage, with answers

Clock tree synthesis just ran. What happened, and what does it cost?

3_1_cts log

clock_tree_synthesis -sink_clustering_enable -repair_clock_nets
[INFO CTS-0050] Root buffer is CLKBUF_X3.
[INFO CTS-0051] Sink buffer is CLKBUF_X3.
[INFO CTS-0052] The following clock buffers will be used for CTS:
                    CLKBUF_X3
[INFO CTS-0049] Characterization buffer is CLKBUF_X3.
[WARNING CTS-0083] No clock nets have been found.
[INFO CTS-0008] TritonCTS found 0 clock nets.
[WARNING CTS-0082] No valid clock nets in the design.
[INFO CTS-0500] Runtime: 0.42s

There was no clock to build a tree from, so the clock stays unbuffered.

Hint: The buffers were chosen. Ask what they were going to be used on.

The tool picked its buffers, looked for nets driven by a defined clock, and found none. It reports this as a warning and exits cleanly, so the run continues to routing with the clock driven by whatever the netlist had. Everything downstream, from skew to hold repair, is then meaningless.

# the clock has to exist before this stage
create_clock -name core_clock -period 0.46 [get_ports clk]

What is wrong, and where was it decided?
4_1_cts log
```
clock_tree_synthesis -sink_clustering_enable -repair_clock_nets -buf_list NOSUCHBUF_X1
[ERROR CTS-0126] No physical master cell found for buffer NOSUCHBUF_X1.
Error: cts.tcl, 36 CTS-0126
Elapsed time: 0:00.23[h:]min:sec. CPU time: user 0.19 sys 0.05 (100%). Peak memory: 114032KB.
make[1]: *** [Makefile:511: do-4_1_cts] Error 1
make: *** [Makefile:511: results/nangate45/gcd/no_clkbuf/4_1_cts.odb] Error 2
```
The buffer list names a cell the library does not contain.

Hint: The name in the message also appears in the command above it.

The buffer list overrides the tool's own choice, and nothing checks the names until they are needed. The command line is printed directly above the error, which is where to read the name from. The same failure follows a library swap, when the new library spells its buffers differently.
```
export CTS_BUF_LIST = CLKBUF_X1 CLKBUF_X2 CLKBUF_X3
```

This is a run that worked. What is the tool doing here?

4_1_cts log

[INFO CTS-0010]  Clock net "clk" has 35 sinks.
[INFO CTS-0008] TritonCTS found 1 clock nets.
[INFO CTS-0097] Characterization used 1 buffer(s) types.
[INFO CTS-0201] 0 blockages from hard placement blockages and placed macros will be used.
[INFO CTS-0027] Generating H-Tree topology for net clk.
[INFO CTS-0028]  Total number of sinks: 35.
[INFO CTS-0090]  Sinks will be clustered based on buffer max cap.
[INFO CTS-0030]  Number of static layers: 0.
[INFO CTS-0020]  Wire segment unit: 14000  dbu (7 um).
[INFO CTS-0023]  Original sink region: [(5890, 7170), (63650, 68770)].
[INFO CTS-0024]  Normalized sink region: [(0.420714, 0.512143), (4.54643, 4.91214)].
[INFO CTS-0025]     Width:  4.1257.
[INFO CTS-0026]     Height: 4.4000.
 Level 1
    Direction: Vertical
    Sinks per sub-region: 18
    Sub-region size: 4.1257 X 2.2000

Splitting the sinks in half, alternating direction, to build a balanced tree.

Hint: Read the levels: what is being halved each time, and along which axis?

An H-tree is built by bisecting the region the sinks occupy, vertically then horizontally, until each sub-region holds few enough sinks to drive directly. The numbers to read are the sink count, the region it spans, and where it stopped. Knowing what a healthy log looks like is what makes an unhealthy one obvious.

# nothing to fix; this is the shape a working clock tree leaves behind
report_clock_skew

The spacing between clock buffers was set to one micrometre. What did that do?
4_1_cts log
```
clock_tree_synthesis -sink_clustering_enable -repair_clock_nets -distance_between_buffers 1
        ...
[INFO CTS-0021]  Distance between buffers: 0 units (1 um).
[INFO CTS-0035]  Number of sinks covered: 35.
[INFO CTS-0018]     Created 7 clock buffers.
[INFO CTS-0012]     Minimum number of buffers in the clock path: 3.
[INFO CTS-0013]     Maximum number of buffers in the clock path: 3.
[INFO CTS-0015]     Created 7 clock nets.
```
More buffers and a deeper tree, on a block too small to need either.

Hint: Compare seven buffers and a minimum depth of three against five and two.

The default run of this design builds five buffers with a minimum depth of two. Forcing one every micrometre gives seven and a depth of three, and the design area grows from 716 to 764 square micrometres. Depth costs variation and power. The knob is there for large blocks with long clock runs, and it does harm on a small one.
```
# leave the spacing to the tool unless the tree is genuinely long
export CTS_BUF_DISTANCE = 60
```
Hold violations appear everywhere after the clock tree. Put these in the order you would work through them.
1. check the hold uncertainty in the constraints
2. check the skew the clock tree actually achieved
3. confirm setup is closed, since hold fixes will slow the paths
4. let repair insert hold buffers
Hint: Rule out what you wrote before you rule out what the tool did.

Everywhere at once means a common cause, and the cheapest common cause is a number someone typed. Skew comes next, since a badly balanced tree creates hold failures across a whole region. Setup has to be settled before hold, because the buffers hold repair inserts add delay. Only then is inserting buffers the right move rather than a way to hide something.