How do you use normalized slack to decide the achievable clock period?

Short Answer

Normalized slack divides a path's slack by the propagation delay it is allowed, so paths with different cycle counts can be compared on their effect on frequency. With the same launch and capture clock, the worst normalized slack gives the period change directly: ΔPeriod = −(worst normalized slack) × period. Enable it with set_app_var timing_enable_normalized_slack true (PT) before the timing update.

Technical Explanation

• Raw slack is misleading across path types. A single-cycle path at -10 ps with a 500 ps period has normalized slack -0.02. A four-cycle path at -20 ps with the same period is allowed 2,000 ps, so its normalized slack is -0.01. The first path limits frequency more even though its slack is smaller in magnitude.
• Set timing_enable_normalized_slack (PT) to true before timing analysis. report_timing -normalized_slack (PT) then reports the worst normalized slack, and the tool can sort paths by it.
• The normalized_slack attribute on paths from get_timing_paths (PT) is available only if normalized slack was enabled before the last full timing update.
• It costs runtime and memory. timing_max_normalization_cycles (PT) limits the allowed propagation delay to a multiple of the clock period; the default is four cycles.
• The period formula applies when launch and capture clocks are the same. For each domain, use the worst normalized slack among its paths. A positive result means the design can run faster, and the same formula gives a negative ΔPeriod.
• Latches need care. With advanced latch analysis, normalized slack can give the maximum frequency except for recovered paths and paths with latches identified as loop breakers or path breakers.
• The number is an estimate at the current netlist and parasitics. A slower clock changes nothing physical, but a faster one tightens every path, and the ECO work to reach it is a separate question.

Formula Or Decision Rule

• Normalized slack = path slack / allowed propagation delay for the path.
• Allowed propagation delay = number of allowed clock cycles × clock period (capped by timing_max_normalization_cycles (PT), default 4).
• Period change (same launch and capture clock): ΔPeriod = −(worst normalized slack) × period.
• Rule: new period = period + ΔPeriod; a negative ΔPeriod means the clock can be sped up.

What To Check

• That normalized slack was enabled before the last full timing update.
• Worst normalized slack per clock domain, not only the worst raw slack.
• Paths with launch and capture on different clocks, where the simple formula does not apply.
• Latch paths flagged as recovered, loop breakers or path breakers.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Worst normalized slack -0.01 on an 800 ps clock, so the period needs 8 ps more, within the agreed margin.
• Suspicious (illustrative): Worst normalized slack comes from a multicycle path whose exception has not been reviewed.
• Hard stop: Normalized slack below -0.10 on a single-cycle path at the target frequency. The period or the architecture has to change.

What The Interviewer Is Testing

• Can you compute normalized slack and the period change by hand?
• Knowing when the simple formula applies and when it does not.
• Awareness of the enabling variable, its timing, and the cycle cap.

Follow-up Question & Model Response

"What happens with paths between two clocks with different periods?"

Candidate Model Response: The PT UG says normalized slack of such a path indicates how much the clock period needs to change for the path to meet timing, but the simple ΔPeriod formula is stated for the case where launch and capture clocks are the same. For cross-clock paths I look at which clock I can actually change and how the two periods are related, and I compute that path separately rather than applying the same-clock formula. Often only one of the two clocks is negotiable, which changes the answer.