What does HyperTrace/graph-based refinement change in ECO fixing, and when does it not pay off?

Short Answer

HyperTrace accelerates path-based analysis, and PrimeTime can use it to speed up ECO fixing when fix_eco_timing (PT) runs with a PBA mode. It changes runtime, not the fixing goal: the same PBA slack is targeted, reached faster. It needs a PrimeECO license, and it pays off little when fixing is graph-based or when the PBA work is small to begin with.

Technical Explanation

• Enable it with set_app_var eco_enable_graph_based_refinement true (PT). This variable is separate from timing_enable_graph_based_refinement (PT), which controls HyperTrace for reporting.
• For fix_eco_timing (PT), HyperTrace supports -pba_mode exhaustive and -pba_mode ml_exhaustive. For fix_eco_power (PT) it also supports -pba_mode path; the same enabling variable is needed, but the reporting refinement threshold variables are not used.
• Check the log. The message PTECO-115, "Running HyperTrace-based ECO fixing", confirms full use. If you see PTECO-116 instead, the tool is only partly using HyperTrace.
• The -path_selection_options option of fix_eco_timing (PT) is not supported for HyperTrace fixing. Using it drops to partial integration (PTECO-116), and the reporting refinement threshold variables must then be set to suitable values for ECO fixing.
• Graph refinement data is updated automatically during ECO fixing, so you do not rebuild it between iterations.
• It does not pay off when fixing runs without a PBA mode, because there is no PBA work to accelerate. It also gains little when there are few violations and the PBA recalculation is already cheap.
• ML-PBA (ml_exhaustive) trades accuracy for speed and can miss worse violations. It is fine for early fixing, but final numbers must come from regular exhaustive PBA.

What To Check

• License availability for PrimeECO before planning a HyperTrace run.
• PTECO-115 or PTECO-116 in the ECO log.
• Whether the script uses -path_selection_options with fix_eco_timing.
• Runtime and remaining violations against the same run without the variable.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): PTECO-115 in the log, same remaining violations as the non-HyperTrace run, and a clear runtime drop.
• Suspicious (illustrative): PTECO-116 in the log because a path selection option is set; gain is partial.
• Hard stop: No PrimeECO license, or final signoff numbers taken from an ml_exhaustive fixing run. Neither is acceptable for signoff.

What The Interviewer Is Testing

• Knowing HyperTrace changes runtime, not the fixing target.
• Recognising the two separate variables and the log messages.
• Can you say when the extra license is not worth it?

Follow-up Question & Model Response

"Would you sign off on the result of a HyperTrace ECO run?"

Candidate Model Response: I would sign off on the design after the ECO, not on the fixing log. After the changes are implemented and re-extracted, I run a full analysis with regular exhaustive PBA in all scenarios. If fixing used ml_exhaustive, that final check is required, because ML-PBA can miss worse paths. HyperTrace only made fixing faster; the evidence comes from the final analysis. The ECO log is useful for explaining what changed, not for proving the design meets timing.