How fast can a chip go before it starts getting the wrong answer?

A one-tile silicon experiment that predicts its own failure point — and will tell us whether the prediction was right.

Every digital chip has a speed limit. Push the clock a little faster, drop the supply a little lower, or let the die get hot, and eventually a signal arrives too late to be stored correctly. The chip does not crash or complain; it quietly returns a wrong number.

Engineers normally find that limit with software. A timing report estimates how long every path takes and declares how fast the design may safely run. But a report is a model of the chip, not the chip itself. This project builds a tiny piece of silicon whose only job is to expose the gap between the two.

The question: how accurately can pre-build timing analysis and two cheap on-chip speed sensors predict the exact clock speed at which an arithmetic circuit starts producing wrong answers?

The short version

If you want the engineering detail, the appendices hold every number generated so far.

Definitions of technical jargon are in Appendix A.

1. Define "too slow"

A digital chip is a very large collection of switches. When a switch flips, the change does not appear instantly at its output — it takes a little time to travel through the wire and the next gate. Individually that is picoseconds, but along a long path it adds up.

On each clock tick, registers take a snapshot of their input and hold it until the next tick. A timing failure happens when a snapshot is taken before the correct value has arrived: the register keeps the old value, and everything downstream of it is wrong. The fail is silent.

Three things make paths slower: a faster clock (less time per tick), a lower supply voltage, and a higher temperature. A chip that is perfectly correct at 10 MHz, 1.20 V, and 25 °C can fail at 50 MHz, or at 1.08 V, or when it is hot. Before a chip is built, software called static timing analysis (STA) estimates whether every path arrives in time, reporting slack — time to spare when positive, time missing when negative. This is how the industry decides how fast a design may run. But it is a model, and models disagree with reality in interesting ways. That disagreement is what this project plans to measure.

2. The experiment in one picture

Two predictions already exist, from completely different methods: static timing analysis, and a simulation of the manufactured gate netlist with per-cell delays annotated. They agree closely. What the real chip does is currently unknown.

The rest of this post explains how each prediction is made, what the design already proves, and what only silicon can settle.

3. Inside the chip: a suspect, a judge, and two stopwatches

The suspect. The device under test is a 16-bit ripple-carry adder — the simplest way to add in hardware: bit 0 produces a carry and hands it to bit 1, which hands its carry to bit 2, and so on. The carry rippling end to end is the slowest thing in the design. To control how slow, the adder is split into four 4-bit segments, and each segment boundary has a delay bank that can insert 0, 16, 32, or 48 inverter pairs. One inverter flips the value; a pair leaves it unchanged but costs time. Four settings × four segments gives a programmable path length.

That delay must physically survive synthesis, which would otherwise delete redundant inverters. The design uses preserved cell wrappers, and the built netlist is inspected afterwards: 384 DUT-bank inverters and two oscillator loops are present in the final layout (structure audit).

The judge. A separate, deliberately fast reference adder computes the same sum with no delay banks. It always settles long before it is used, so any disagreement means the slow adder's answer was captured too late — not that the arithmetic is wrong.

The shutter. The trick that makes failures observable is when the answer is photographed. New operands launch on a rising edge; the DUT's 17-bit answer is captured exactly once on the immediately following falling edge, then held. If it was still settling at that instant, the wrong value is frozen in place and a later, correct result cannot overwrite it. At the next frame boundary — 19 clock cycles after launch — the frozen sample is compared with the reference and an error counter is bumped.

How we lowered the required test frequency. The earlier design gave the adder a full clock cycle to finish. Its longest path was predicted to fail near 61.5 MHz at 25 °C, above our planned 50 MHz ceiling. Taking the snapshot on the falling edge gives it only half a cycle at 50% duty, so it can miss the deadline at a lower clock speed. With the same delay banks, the new predicted boundary is about 31 MHz at 25 °C. This makes room-temperature testing plausible without requiring a 125 °C test; the actual silicon boundary still needs measuring (original audit, half-cycle validation). Normal operation remains 10 MHz, giving the adder 50 ns to finish; the 10–50 MHz sweep deliberately searches for failures.

Four workloads. A pattern generator feeds the adder four operand streams: pseudorandom (PRBS), a repeating carry-heavy sequence, an alternating carry-free pattern, and a static hold. They push the same hardware along different paths. "Carry-heavy" is a stimulus label, not a claim — the timing analysis separately has to show the sequence really sensitizes the predicted path, and it does for the carry-heavy and PRBS patterns.

Two stopwatches. The tile also carries two ring oscillators — loops of an odd number of inverters that oscillate on their own at a frequency set by gate speed. They are the chip's built-in speedometers: one a generic inverter line, the other structure-matched, passing through delay banks and carry stages to resemble the adder's timing composition (canary RTL). Each drives a 16-bit counter.

4. Turning a timing report into a predicted speed

The experiment analysis fixes the configuration bits, then searches for paths that start at runtime-changing state (the operand registers) and end at the one-shot capture register. For a clock period T, HIGH-time fraction d, and extracted setup slack S, the required aperture is d × T − S. Setting the aperture to exactly what is required gives the predicted failure speed:

required HIGH time = d × T − S
predicted boundary frequency (MHz) = 1000 × d / required HIGH time (ns)

At nominal conditions with d = 0.5 and T = 20 ns, the carry-heavy path needs 16.13 ns of HIGH time, predicting first failures at 31.0 MHz. This is an estimate from extracted timing analysis — most trustworthy near the analyzed operating point, and reported with that caveat.

The important detail is which path is analyzed. The globally slowest path in the chip starts at static configuration bits that never change at runtime, so it answers a different question; the experiment analysis restricts itself to paths a real workload can actually excite.

5. What the pre-silicon work already shows

The delay settings work as designed. At nominal conditions, stepping the four banks together from 0000 through 1111, 2222, and 3333 lowers the predicted carry-heavy boundary from 84.5 to 53.5, 39.2, and 31.0 MHz — so the longest setting puts the predicted transition inside the planned sweep. A configuration that stays error-free up to 50 MHz is recorded as "beyond the measured range", never assigned a boundary of 50 MHz.

A timed workload really does fail. Running the routed netlist with cell delays annotated, at the longest delay setting and with the carry-heavy workload, gives a clean fail/pass transition at every corner:

199 completed comparisons per point. The timing analysis lands within 3.3 ns of the simulated transition at every corner — agreement between two independent models, not yet evidence about silicon.

The right clock property is being measured. If the chip reacted to frequency alone, changing the duty cycle would move the failure point. It does not. At a fixed 14 ns of HIGH time — reached with three different period/duty combinations — the simulation produces exactly 49 errors in 199 comparisons every time; at 18 ns, none. Timing analysis independently asks for 16.13 ns. The capture aperture, not the raw frequency, is the variable that matters.

Workload matters, and the model says so. The same hardware, at the same delay setting, has very different predicted limits depending on what it is asked to do:

The carry-free and static cases are honest "not measurable here" results: one lies above the board's 50 MHz ceiling, the other does not exist at all.

The speed sensors are modeled, and now transient-checked. Extracted analysis of the two oscillator loops predicts, at the longest sensor setting, 381.7 / 260.4 / 165.6 MHz for the generic canary and 150.6 / 103.3 / 66.1 MHz for the matched one (fast / typical / slow). The matched canary is consistently about 2.5× slower — what a longer loop should look like. Those are broken-loop timing estimates. A transistor-level transient simulation of the same post-route extracted netlist, for all 24 corner/setting/canary combinations, gives a mean SPICE/STA frequency ratio of 1.119 — 1.151 for the generic canary, 1.087 for the matched one, range 1.04–1.22, with no outliers. SPICE is faster than the static estimate in every case, which is the expected direction because the transient netlist carries no wire RC. Details and data: extracted RO transient validation.

What these results are not. The timed simulation annotates cell delays only and omits wire interconnect delays and flip-flop timing checks, so it cannot predict metastability or absolute silicon error probabilities. Agreement with STA is a cross-check between two models, not a silicon accuracy result. The transient RO check uses a cell-level extracted netlist with no interconnect RC, so it is a third model view, not silicon. The oscillators are modeled, not measured. And the library "corners" are model conditions — heating one die does not turn it into the slow corner.

6. Is the chip physically real?

Yes — as a verified, signoff-clean design, not yet as returned silicon.

How we lowered area usage. We simplified the supporting logic while keeping all 384 DUT delay-bank inverters and both oscillator loops:

• Removed a duplicate 16-bit configuration register, reused the startup counter for pin-direction control, and trimmed the measurement-window counter from 16 bits to the 14 it needs.
• Replaced the step-by-step reference checker and its stored intermediate results with a direct adder. The operands already stay stable until comparison, so this extra storage was unnecessary.
• Changed the oscillator counters to ripple counters: each bit triggers the next, removing the wide incrementing logic while retaining 16-bit counts.

Together, these changes reduced storage cells from 195 to 152 and active cell area by about 12.5%. We could then lower the placement-density target from 82% to 72%. Final core utilization fell from 82.86% to 72.53% in the same tile. The saving comes from smaller circuitry; changing the density setting alone does not remove gates (development comparison, current build metrics).

The build passes 13 RTL tests, 9 functional gate-level tests with 4 intentional skips, and 10 Tiny Tapeout prechecks, covering configuration, error injection, canary masking, capture retention, freeze/resume, and counter behavior (local build manifest). It uses 72.53% of the core, with 152 sequential cells and 2,809 placed instances (1,637 standard cells plus filler), and reports zero routing DRC, Magic DRC, LVS, and antenna violations.

Normal submitted operation at 10 MHz closes timing comfortably at every corner — while the experiment deliberately overclocks past those limits. Sources: summary report, metrics.

7. What the silicon still has to answer

The measurement protocol was frozen before any silicon data exists (v2 protocol, prediction model). It measures the real boundary at a nominal anchor — room conditions, longest delay, carry-heavy workload — and gives each predictor exactly one multiplicative calibration factor from that single anchor, held fixed everywhere else. Today that factor is 1.0, a placeholder, not a fitted result. If the anchor turns out to be unreachable below 50 MHz, calibration is reported unavailable rather than quietly replaced.

The deliverables are prediction error, missed failures, false warnings, guardband cost, and workload dependence, reported both uncalibrated and calibrated, with negative and censored results kept. Transient validation of the oscillators is now done (extracted RO transient validation); still open: board clock delivery and operating limits, shuttle acceptance, and the measured correlation between the on-chip speed sensors and the arithmetic failure boundary.

The next useful result is a silicon dataset that can challenge the numbers recorded here. When it exists, this page will have to change.

Appendix A — Plain-language glossary

Appendix B — Every STA prediction (96 cases)

Three library corners × eight delay configurations × four workloads. Values are the predicted first-failure frequency in MHz; "no runtime path" means the workload never changes operands, so no boundary is defined.

B.1 How one number is produced

The longest configured path (3333), carry-heavy workload, showing the extracted arrival time at the capture register and the arithmetic that converts slack into a boundary:

The full table also records, per case: startpoint, endpoint, path delay, arrival, required time, slack, the case-analyzed configuration word, the worst unrelated register-to-register path, and the tool/PDK identity — see the CSV and JSON.

B.2 The ladder, in detail

Appendix C — Every timed-simulation run (23)

Cell-delay-annotated gate-level simulation of the routed netlist. Interconnect delays and flip-flop timing checks are not annotated. "Compared" is the number of completed comparisons; launches include the initial pipeline fill, so compared = max(launches − 1, 0).

Duty-cycle check (nominal corner). At 40%, 50%, and 60% duty, periods of 35.0, 28.0, and 23.33 ns all give 14 ns of HIGH time and 49 errors; periods of 45.0, 36.0, and 30.0 ns all give 18 ns of HIGH time and 0 errors. Controls: PRBS at a 40 ns period, carry-free alternating at 20 ns, and static hold at 20 ns all report 0 errors in 199 comparisons. Static hold has no runtime-sensitizable path, so the prediction table leaves its boundary undefined rather than inventing a value. Both the error counter and the launch counter saturate at 65,535, so longer measurements must be split into bounded batches. Source: sdfsim.csv, aperture-check.json.

Appendix D — Every ring-oscillator prediction (24 rows)

Modeled loop delay, oscillation frequency, and predicted edge counts per counter window (256 / 1,024 / 4,096 / 16,384 clock cycles) at a 50 MHz reference clock. Counts marked ✗ exceed 65,536 and would wrap in the 16-bit hardware counters.

Only the 256-cycle window (win0) fits in 16 bits for both canaries at every corner, which is why the frozen protocol predeclares selection 3 with window 0. Two caveats for host analysis: the status byte's "dead" flags only report a zero count after a window — they are not calibrated warnings that the DUT is about to fail — and the canary counters, unlike the error and launch counters, have no overflow flag, so a wrapped count is silently wrong. An earlier attempt to read canary counts out of the signoff simulation was discarded as invalid: oscillator timing arcs are disabled in the constraints, so those cells carry hard zero delays and the counts are simulator artifacts (diagnosis). Source: ro_predict.csv.

Appendix E — Prediction model and calibration

Model tpv-predict-2.0.0, frozen before any silicon data. Two canary predictors scale the nominal STA ladder by the ratio of the modeled oscillator count at the target corner to the count at nominal conditions, at the same reference clock, selection, and window. Nominal RO-based predictions therefore equal nominal STA by construction — their agreement is not evidence that one canary is more accurate than the other.

Predicted first-failure frequency (MHz), carry-heavy workload

Predicted first-failure frequency (MHz), PRBS workload

Predeclared canary readout, selection 3, window 0 (256 cycles)

Calibration. Each predictor gets one factor k = F_measured / P_predicted from the nominal anchor (1.20 V, 25 °C, delay 3333, carry-heavy). Every pre-silicon row currently carries k = 1.0 as an explicit placeholder. If the anchor is censored above 50 MHz, calibration is reported unavailable. Host analysis must also rescale counts by the measured clock frequency (the model assumes 50 MHz), account for the fact that the window counter starts before the oscillators are enabled (about 253 of 256 nominal cycles), and reject wrapped or ambiguous counts. The full 288-row predictor table is in predictions.csv; the generated summary is predict/summary.md.

Appendix F — Verification, signoff, and build provenance

Test results (local build local-dev-safe10)

The functional gate-level suite removes oscillator loops and runs with zero delay; it checks synthesized logic and the external protocol, not timing. Structural checks confirm 384 DUT-bank inverters, two oscillator loops, and 17 one-shot capture flops survive into the built netlist.

Physical metrics

Build identity. All quantitative experiment results on this page come from the local development package local-dev-safe10, build commit 7b20196bb74195649679fae6313a891712e87458, analyzed on a dirty worktree with the listed source files verified against the build commit. Tools: LibreLane 3.0.5, IHP PDK revision c4b8b4e5e7a05f375cca3815d51b3a37721fbf5c, support-tools revision 01d5d2814fa9dd61e9d211e0b235a4a592a9316a. The placement figure and the archived CI manifest come from a separate build: GitHub Actions run 34158224984 on commit b9f03f798978840c8bdc2bb574877408e0f33f4c, whose GDS, precheck, gate-level, and viewer jobs all succeeded (manifest). The two identities are not mixed. Earlier "v1" full-cycle datasets exist in the repository's history but are not used anywhere on this page.

Appendix G — Reproducing the figures and data

Every data figure in this post is regenerated from the archived CSVs by one script:

# from the repository root, inside the devcontainer
source /ttsetup/venv/bin/activate
python tools/plot_v2_blog.py

The script runs no HDL, no timing analysis, and no simulation; it only replots archived data and writes docs/figures/v2/provenance.json with the input hashes, tool versions, and the schematic/simulated status of each figure. The architecture diagram is hand-drawn from the RTL, and the placement map comes from tools/plot_v2_placement.py with its own provenance. Raw data lives in data/safe10/: experiment_sta.csv and .json (96 STA cases), sdfsim.csv and .json (23 simulation runs), ro_predict.csv and .json (24 oscillator rows), predict/ (model outputs), and verification/ (tests, structure, metrics, aperture check, build manifest).