Clock Stretching

Clock stretching recovery is what happens the instant a timing-speculation circuit like a Razor flip-flop actually catches a path that was too slow for the clock period it was given: detecting the error is only half the job, and the other half is giving the pipeline a way to redo the computation correctly without a full pipeline flush or a system reset — which is exactly what stretching the clock period for one cycle, right after the error is flagged, accomplishes.

Detecting an Error Is Not the Same as Fixing It a late-arriving value still has to be recomputed correctly before the pipeline can move on Normal cycle — combinational path settles before the clock edge clock edge — value already correct Slow cycle — path too late for the ordinary clock edge clock edge arrives — value still settling, not yet valid error flagged — shadow latch catches the correct late value Recovery cycle — the clock stretches to give the shadow value time to propagate one widened cycle — recovery only, not a stall of the whole pipeline The shadow latch already has the right answer — it just needed more time to reach it A single stretched cycle lets that correct value finish propagating into the main pipeline register, so the pipeline resumes from a correct state without replaying the whole instruction.

The recovery mechanism exploits a detail this series has already covered in passing: a Razor-style design keeps a second, delayed shadow latch sampling the same signal slightly later than the main pipeline register, specifically so the shadow copy can catch the value that the main register missed. When the error-detection logic compares the main register's value against the shadow latch's value and finds a mismatch, it knows a timing violation occurred on that specific path during that specific cycle — but the shadow latch, clocked later, has already captured what the correct value actually was, since it samples after the slow path has had more time to settle. Recovery, then, does not mean recomputing from scratch; it means getting that already-correct shadow value into the main pipeline register properly, which simply requires giving the circuit one extra cycle's worth of time before continuing.

Clock stretching accomplishes exactly that by inserting a single widened clock cycle immediately after the error is detected, rather than stopping the whole pipeline or restarting the instruction from an earlier stage. The clock generation logic, upon receiving the error flag, holds the next clock edge back for an extra, bounded amount of time — long enough for the shadow latch's value to propagate cleanly into the main register — and then resumes normal-period clocking from the following cycle onward. This is a localized, single-cycle correction rather than a global stall: only the specific pipeline stage and cycle where the error occurred experiences the stretch, and throughput elsewhere in the pipeline is unaffected except for that one recovery cycle's worth of lost cycle time.

Why This Is Worth Doing at All better-than-worst-case design trades rare, cheap recoveries for everyday speed Conventional worst-case design clock period fixed for the rarest, slowest case • Margin paid on every single cycle • Slowest possible path sets the clock • No error ever occurs — by design Guaranteed correctness, but speed is capped by a rare case Better-than-worst-case design clock period set for the typical case • Faster clock on every typical cycle • Rare slow paths flagged, not avoided • Clock stretching fixes it when it happens Small, occasional recovery cost buys a faster clock everywhere else Clock stretching is the mechanism that makes this tradeoff safe to accept Without a reliable recovery path, timing speculation would just be a design that occasionally computes the wrong answer.

This recovery mechanism is what makes the entire timing-speculation strategy safe to adopt in the first place, rather than merely academically interesting. A conventional design sets its clock period to accommodate the single worst-case critical path, paying that margin on every cycle even though the worst case rarely actually occurs — a conservative but simple guarantee of correctness. Better-than-worst-case design instead sets the clock for the typical case, runs faster on the overwhelming majority of cycles, and accepts that occasionally a particular path will not finish in time; clock stretching recovery is the specific mechanism that turns that occasional slow path from a silent correctness failure into a detected, corrected, single-cycle delay. Without a reliable recovery path, detecting a timing error would be useless — the pipeline would still need to be reset or the whole system marked unreliable — which is exactly why error detection and stretching recovery are always designed as a matched pair rather than either one being deployed alone.

The cost of recovery has to stay low and bounded for the whole approach to pay off, which places a real constraint on how the technique is actually deployed. If timing violations occurred frequently, the cumulative cost of repeated stretched cycles would erase the speed advantage the faster typical-case clock was supposed to deliver in the first place — the entire value proposition depends on timing errors being rare events under normal operating conditions, with the faster clock paying off across the much larger number of cycles that never need recovery at all. This is why better-than-worst-case techniques are typically deployed alongside dynamic voltage and frequency scaling or adaptive guard-banding rather than as a replacement for conservative timing margin altogether — the system tunes itself to keep the error rate low enough that recovery remains the rare exception, not a frequent event eating into the speed gain.

Design approachClock period set forHandles rare slow paths byThroughput cost
Conventional worst-caseSlowest possible critical pathNever occurring, by marginPaid every cycle
Better-than-worst-case + clock stretchingTypical-case critical pathDetect, then stretch one cycle to recoverPaid only on rare error cycles

Clock stretching recovery is the half of timing speculation that makes the other half trustworthy — detecting a late path is only useful information if the system also has a cheap, local way to act on it correctly. By reusing a shadow latch's already-correct value and giving it exactly one extra cycle to arrive, the pipeline recovers from a rare timing miss the same way it would have avoided one entirely under worst-case design, just paying that cost only when it is actually needed instead of on every single cycle.

Take clock stretching further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app