Feature request: display macro clock insertion latency in timing reports in GUI

[oharboe]

Problem

When a design uses hardened macros (liberty black boxes) with internal clock trees, report_checks shows the macro's reg2out delay as a single opaque number. This delay includes two distinct components:

1. Clock insertion latency — the macro's internal CTS delay from its clock pin to its deepest register (recorded in the .lib as max_clock_tree_path)
2. Logic delay — the actual combinational path from the register output to the macro's output pin

At synthesis and pre-CTS stages, the parent design uses ideal clocks. Paths launched from a macro's internal register carry the macro's clock insertion latency as part of the data arrival time, but the capture side sees ideal clock at time 0. This makes macro-launched paths appear pessimistically worse by the full clock insertion latency. The slack is correct once the parent runs CTS, but at earlier stages the inflated arrival time is misleading.

Without visibility into the clock insertion component, users must manually parse .lib files to understand how much of a macro's delay is real logic vs. internal clock tree. This makes it hard to prioritize timing fixes at synthesis.

Proposed solution

Add an optional column or annotation to report_checks output that displays the max_clock_tree_path value from the liberty model when a timing path passes through a macro's sequential output pin. For example:

                                              Clk Ins.
     3    2.70   16.82 1519.88 1519.88 v cam/io_out[0] (CAM_8)    483.1
     ...

Or as a summary line after the macro pin:

     3    2.70   16.82 1519.88 1519.88 v cam/io_out[0] (CAM_8)
                                         ^ macro clk insertion: 483.1 ps (max_clock_tree_path)
                                         ^ logic delay: 1036.9 ps

The information is already available in the liberty model — it just needs to be surfaced in the report.

To view this problem, run:

bazelisk run --//:platform=gui //test/orfs/mock-array:MockArray_4x4_base_synth gui_synth

Workaround

We currently parse max_clock_tree_path from .lib files in a Tcl script and annotate timing paths post-hoc. This works but requires maintaining custom tooling that duplicates what the timing engine already knows.

Related

• The liberty max_clock_tree_path / min_clock_tree_path attributes on timing() arcs with timing_type : max_clock_tree_path encode this information
• OpenROAD issue #3759 discusses related clock handling for hierarchical macros

Suggested Solution

Vibe coded mock-up #9683

Additional Context

No response

[maliberty]

Requests for report_checks changes should go to sta not OR which is just a client.

[oharboe]

Look at the title: in the GUi.

Please look at the coded mock-up #9683