Skip to content
MachAI Lens Help

Release notes

Newest release first.

Lens does not yet carry release version numbers; releases are identified by date, and the version you are running is the date of the latest commit in your copy of the repository (git log -1 --format=%cd in the project root).

2026-08-24: POCV runs now read the corner Value, not the statistical Mean

This change applies to every run whose timing reports were produced with POCV (report_timing -variation, the statistical columns). Numbers on screen change the next time you launch Lens. Your reports have not changed; what changed is which column Lens reads.

What was wrong

A POCV slack line prints three numbers: the Mean, the Sensitivity, and the corner Value that the verdict is judged against.

slack (VIOLATED)    0.012    0.007   -0.007

Lens read the first number. On the line above, it showed +0.012, a passing slack, for a path that the tool itself printed as VIOLATED at -0.007.

The paths table, the timing-budget waterfall and the run summary all took slack from the first number. The waterfall's other figures were read the same way: arrival, required, uncertainty, CRPR, clock network delay, clock latency and library check.

What you will see change

  • Every POCV path's slack is now its corner Value.
  • Paths you saw as marginally passing may now show as violating. That is the report's own verdict, which the Mean was hiding.
  • The timing-budget waterfall's arrival, required, CRPR, clock network delay and library check also move to their corner Values. The waterfall and the paths table now agree with each other and with the report file.
  • Runs without POCV (no -variation) are unchanged, down to the byte.

How Lens decides which column to read

A report declares its own layout twice: the -variation option in the command echo, and the Mean Sensit … Value column-header row. Lens follows the column-header row, which is the declaration next to the rows. If the two ever disagree, Lens logs a warning naming both and still follows the column-header row. It never decides by counting numbers.

The warning is written to the terminal window you started Lens from, not to the app's screens, so keep that window open if you want to see it.

Saved runs

Lens parses saved run summaries again each time it shows them. After you upgrade, Lens does not reuse results it parsed before the fix, so it cannot show you those stale results.

You need do nothing for saved runs: run summaries are parsed again from your reports each time they are shown, and the parse cache is keyed by parser version, so results parsed before this fix are never served again. If a run made from a POCV report still looks wrong after upgrading, run that scenario again.

2026-08-18: Corrected setup and hold reporting for PrimeTime and Fusion Compiler runs

This change applies to every PrimeTime and Fusion Compiler run that this release analyses. Numbers on screen and in saved runs will change. Your reports have not changed; what changed is which report Lens reads.

What was wrong

Lens decided which of your two timing reports was the setup report and which was the hold report by looking at the file name. A name containing max counted as setup, unless it also contained min. The word timing contains min.

So *_max_timing_GBA.rpt, the default setup pattern that Lens shipped with, was rejected as a setup report and dropped entirely. The hold report became the run's main report, and the run went ahead with no setup report at all. Fusion Compiler's report_timing.max was affected in the same way.

What you will see change

Runs whose setup side really had violations were reporting a clean setup. Expect three changes:

  1. Setup violations appear where Lens showed none before. They were always in your reports; Lens was not reading them.
  2. A run's overall WNS changes. It was the hold figure, because hold was the only side being read. It is now the worse of the two sides.
  3. The long-net and net-delay columns fill in. They were computed from the hold report, which is usually clean, so they read zero. They are now computed from the setup report.

Stages whose setup side was genuinely clean show the same numbers as before. If nothing changes for your project, nothing was wrong with it.

Also corrected in this release

  • A clean setup side is no longer overwritten by the hold figure. A clean setup is 0.00, which Lens treated as missing and replaced with the overall WNS (the hold number), labelled Setup WNS. This applied to healthy designs specifically.
  • Inverted clock names are no longer confused with the clocks they are named after. PrimeTime writes CLK' for a clock's falling-edge sense. Lens was deleting the apostrophe, so CLK' was treated as CLK, which can be a different real clock in the same report. Clock names containing / (hierarchical names) or a bus index such as gen_clk[3] were damaged in the same way.
  • "No violations" no longer covers up a failed lookup. An empty violators table now tells apart four cases, and only the last one says that a clock is clean:
    1. The report could not be found.
    2. The clock could not be matched to any path in the report.
    3. The report is a sample and cannot establish that a clock is clean.
    4. The report lists every violating path, and none of them involve this clock.
  • When Lens refuses a run for an incomplete scenario, it now tells you why. Before, it hit an internal error and showed a generic failure message instead of the reason.
  • Clock skew derived from PrimeTime reports now works for lowercase clock names, which is essentially all of them. Before, it was silently selecting no paths.

Saved runs from before this release

Saved runs are not rewritten. When you open a saved run, Lens re-derives its setup side from the report file recorded with that run, so what you see is correct. The figures stored on disk stay as they were until the run is re-run.

Comparing an old run against a new one is safe: both go through the same re-derivation, and neither compares setup against hold.

Known issue, not fixed in this release

On reports with POCV (variation) columns, Lens read slack from the Mean column instead of the corner Value, so violation counts were understated.

This is the issue the 2026-08-24 release above fixes: from that release, Lens reads the corner Value.

Still have a question?

Updated 19 October 2026