Skip to content
MachAI Lens Help

Compare two runs

Lens Compare is one window with three modes, chosen with tab buttons: Scenario Analyzer, Stage Compare and Build Compare. Stage Compare and Build Compare compare a baseline with a candidate.

Choose a mode

Mode What it compares What it shows
Stage Compare One stage against another: pre-CTS, post-CTS, post-route, PT-final and so on Per-clock deltas, and the detailed path view, Path Diff
Build Compare Two PrimeTime builds, or two Tempus builds, aggregated across all scenarios Per-clock aggregate deltas; for path detail, it hands off to Path Diff

Build Compare finds clock and scenario regressions in aggregate. To inspect the comparable paths for a scenario, select Open Path Diff → on its row, which takes you into Stage Compare.

Lens compares runs from the same tool flow only. Comparing PrimeTime (PT) against Fusion Compiler (FC), or PrimeTime against Tempus, is not offered, and the refusal names both tools. Build Compare accepts two builds of the same scenario-shaped flow, PrimeTime or Tempus; it refuses Fusion Compiler and Innovus builds and gives the reason: they organise results by stage rather than by scenario.

For one database across several PVT scenarios, or for a scenario-level ranking, use Scenario Analyzer instead.

Open Lens Compare

  1. On the Timing Review tab, select Compare Runs in the top bar. Lens Compare opens on Scenario Analyzer.
  2. Select the Stage Compare or Build Compare tab button.
  3. Choose the baseline and the candidate. In Stage Compare, the Baseline and Candidate dropdowns list the saved runs from every registered build in the project; under each, Lens shows the run's path and stage. Pick any two runs of the same tool flow, for example a Fusion Compiler post-CTS run against its post-route run. Choosing the same run on both sides is allowed and shows a Same Run Selected warning: every path is then common. In Build Compare, the two dropdowns list the registered builds, each tagged with its tool, for example [PT]; pick two different builds of the same tool.

Read Stage Compare

Stage Compare shows:

  • the change in WNS, TNS and violations for each clock
  • the regressing clocks, ranked
  • dominant-clock shift detection
  • a heatmap of clock-skew deltas
  • the Path Diff list: paths common to both sides, new in the candidate, or removed

The header names both sides. If the two sides' reports were produced by different tools, it warns: Comparing across report dialects (PrimeTime vs Tempus). Deltas may reflect tool differences, not design changes.

This is not a contradiction of the same-tool rule. The tool flow is the workflow a build was set up for; the dialect is what actually wrote each report file, which Lens detects from the file's contents. Two runs of the same flow can hold reports from different tools, for example a Tempus report that was loaded under a PrimeTime-flow build, and that is the case the warning covers.

Read Build Compare

Build Compare shows, aggregated across all scenarios:

  • a coverage strip, which says how many scenarios were matched
  • aggregate WNS, TNS and violation chips
  • aggregate deltas for each clock

The coverage strip also names each side's report dialect, summarised over the runs being aggregated. A side whose runs disagree reads mixed dialects, and a side with a file that was not identified reads, for example, PrimeTime (1 file unrecorded). The strip carries the same cross-dialect warning as Stage Compare.

Build Compare stays the aggregate view. For detailed path inspection, go to Path Diff.

Go from Build Compare to Path Diff

Select a clock in the per-clock table. The Scenario drilldown table below it (headed Scenario drilldown — select a clock row above until you do) then lists that clock's matched scenarios with their setup and hold deltas, and its last column, Action, holds Open Path Diff → for each scenario. Clicking elsewhere on a row only selects it; only the action column opens Path Diff.

Lens takes the matched build scenario, the clock and the timing side (setup or hold) into Stage Compare, and keeps the baseline → candidate direction. The transferred clock and side set the Path Diff selection: it never falls back to a clock left over from an earlier Stage Compare session, or to All Clocks.

Lens checks the handoff before it switches. If the clock is missing from the Stage Compare comparison that Lens resolves, or the exact matched baseline and candidate runs cannot be resolved, Lens stays in Build Compare and shows a short message saying why, rather than switching into a partial state.

When the handoff is valid:

  • Stage Compare focuses Path Diff, so you do not have to scroll to find it.
  • Lens starts an Active Investigation for that target, or reuses the one already started for it.
  • If there are no comparable paths, Stage Compare still opens on that exact clock and side and shows a no comparable paths result.

An Active Investigation is Lens's record of the engineering problem you are pursuing across its views, as distinct from what it is displaying right now. There is one open investigation per project. Running Explain Selected Scenario Delta on its own does not start one; following the Open Path Diff → it recommends does.

Read Path Diff

You can also reach Path Diff directly in Stage Compare. Its controls are in three rows:

  • Filters: a Clock dropdown (one clock at a time; there is no All Clocks), a SETUP / HOLD toggle, a Scenario dropdown (default All Scenarios), Top-K (10, 25 or 50; default 25), and Sort (Worst ΔSlack, the default; Best ΔSlack; Worst Candidate Slack; Largest |ΔSlack|).
  • Search: a substring filter across path group, startpoint and endpoint.
  • State: a summary line, Common paths: X | New in Candidate: Y | Removed: Z | Regressing: R | Improving: I, and a status chip.

The table's columns are Path (P#, with the full start → end in a tooltip), Startpoint, Endpoint, Base Slack (ns), Cand Slack (ns), ΔSlack (ns) in colour, and Shift Visual.

The Shift Visual is a skew-style marker: a hollow grey dot for the baseline, a filled cyan dot for the candidate, and an arrow from baseline to candidate, green if the path is improving and red if it is regressing.

Status chip Meaning
READY Neither side is empty, and at least one matched path remains after the filters.
PARTIAL One side is empty, or neither is empty but no path matches after the filters.
UNAVAILABLE Both sides are empty or missing, for example because setup or hold paths are missing, or parsing failed for both.

Click a row for a detail popup: the clock, type and scenario; the base, candidate and Δ slack; and the raw path block in monospace. Right-click a row to copy the startpoint, the endpoint or the full path.

Digital Soul actions

Digital Soul, the copilot panel built into Lens, sits in a drawer in Lens Compare. In Stage Compare and Build Compare, the Quick tab holds four pair-level actions. They need only a loaded baseline and candidate, not a selected row (in Build Compare, two builds with matched scenarios), and they are fully deterministic: they make no AI call. Actions that need a selected row are on Extended.

Mode Quick Extended
Stage Compare Diagnose Stage Compare, Create Stage Compare Debug Plan, Review Stage Compare Evidence, Draft Stage Compare Summary Explain Selected Delta (a row in Top Timing Regressions); Explain Selected Clock Delta (a row in Timing Delta Overview)
Build Compare Diagnose Build Compare, Create Build Compare Debug Plan, Review Build Compare Evidence, Draft Build Compare Summary Explain Selected Clock Impact (a clock row in PT Build Aggregate); Explain Selected Scenario Delta (a clock row, then a Scenario Drilldown row)

After you open Path Diff from Build Compare, the drawer switches to two deterministic actions: Explain Path Diff and Create Path Diff Debug Plan.

A selected-row action is enabled only when the row you clicked belongs to the baseline → candidate pair that is active now. Changing the baseline or the candidate (or a stage), swapping the two sides, or handing a row to the other compare mode clears the selection and disables the action. A matching clock name alone never keeps it enabled.

The two Build Compare Extended cards show a BUILD PAIR strip with both builds, the direction and the selected clock (and scenario). Copy Result and a History recall of a comparison show both original sides, the direction and the classification (NEW, FIXED, IMPROVED or REGRESSED), and a recalled result keeps its original pair after the selectors move to a different pair.

Stage Compare validity has three states:

  • When the same scenario and corner are confirmed, the card shows no warning.
  • When they cannot be confirmed, it shows a neutral COMPARE IDENTITY NOT CONFIRMED note.
  • Only a proven scenario or corner difference carries the amber ⚠ COMPARE VALIDITY WARNING on overview and summary cards.

A difference in stage alone is expected in Stage Compare and is never treated as a scenario or corner mismatch. Build Compare cards always show a matched-scenario coverage strip.

Known issue: a stale Quick card after a pair change

After you change the Build Compare baseline or candidate, a Quick pair-level card generated before the change stays visible until you run another action. The next action gives a fresh result for the new pair, but until then the old card can sit beside a different pair. The two kinds of Extended card show the banner ⏳ RESULT FROM PREVIOUS CONTEXT — RUN AN ACTION TO REFRESH when this happens; Quick cards do not.

Check the card's own context line before you quote it: under the card's Parsed Timing Evidence heading, a dimmed line gives the run name, the scenario name and the clock count (for example run post_route_v3 · scenario func_ss_0p72v_125c · 12 clocks), naming the run the card was built from.

See also

Still have a question?

Updated 19 October 2026