Trace the result. Repeat the test.

Forge internal request verification

Internal requests are requests we issued ourselves in the form a customer would send; no customer is involved. The table lists every request issued so far, in the order issued. A delivery is the package sealed as a ZIP for the request: RTL, the placed-and-routed design, integration files and replay commands. Pass means every compared output equalled the integer reference model's value: in gate-level simulation of the routed netlist, and again when the delivery ZIP was unpacked and replayed. The count is the number of outputs compared.

Delivery time is the wall-clock time from intake to that verified replay, retries included. From request 004 onward it starts at the first observed intake. Requests 001 to 003 recorded only the acceptance of the request and start there. From request 010 onward a four-state cold-start pass of the routed netlist is also a delivery condition, and the time runs to the later of the verified replay and that pass.

Requests 003 to 010 were each implemented on two paths from the same frozen request: a baseline path, and a history path that also received the failure and repair records of earlier requests. When both paths pass, the table shows the delivery that finished first. The exception is a delivery found defective by a check after delivery: it is not shown as the request's delivery, and the fact is stated under What was delivered (request 009). Request 002 compared only the physical stage of one RTL, and 001 has a single path.

What was delivered

What the delivery in the table above is. Where two paths passed, this is the path that finished first, named next to the request number. For request 009, where a check after delivery found the first-finished delivery defective, it is the other path, as the note under the table states.

Requested clock and slack

The clock period is the request's target. Setup and hold slack are the margins left at that clock; both must be positive.

Cell area

Standard-cell area. SRAM macro area is listed separately.

One input, continuous

One test input to the block: a vector in 002, a patch in 003, a tile in 004, a frame in 005 to 009, a tile in 010. Continuous input means the input is never kept waiting and the output is never stalled. The time is the cycle count times the requested clock: computed, not measured on silicon.

Against the float reference

The integer outputs compared with the floating-point reference; where the cell gives a held-out count, on inputs held out from calibration. NRMSE is the relative L2 error over those inputs and must be at or below its limit. Min cosine is the lowest cosine similarity of any single input and must be at or above its limit. The limits were written in the request beforehand. Requests 009 and 010 also set the NRMSE limit on each input; the largest single-input NRMSE is listed too.

SHA-256

Of the delivery ZIP and of the routed netlist inside it. RTL, raw logs and the ZIPs stay internal; the hashes bind these numbers to those files. Full values are in the public summary JSON.

Swipe to see all columns

Request 008, checked after delivery. On 4,096 further inputs scored on the integer model, 62 single inputs exceed the 8% NRMSE limit when taken one at a time, the largest at 15.35%. The aggregate over the 4,096 is 3.34% with a minimum cosine of 0.9995, inside the request's limits. The request set its limit on the aggregate over the held-out inputs, so the delivery passed as written. It does not show that every single input is accurate. The input with the largest error under each of the two mask conditions (15.35% and 12.78%, ranked 1 and 4 among all inputs) was replayed with continuous input on both paths' routed netlists: all 6,144 outputs of the 4 replays equal the integer model's values.

Request 009, checked after delivery. The routed netlist of the baseline path, delivered first, failed an additional check after delivery: a four-state cold-start replay that applies a real reset edge gave 32 SRAM reset warnings and a wrong first read. The check was not part of the request's frozen acceptance, which the baseline delivery had passed first, at 5 h 10 min 54 s. The request and delivery tables therefore show the history path (5 h 17 min 16 s) instead. The history path's routed netlist passed the same check: 46 directed checks, 0 SRAM reset warnings. The repaired baseline delivery completed physical checks, 6,144 matching integer outputs and the same cold-start check (46 directed checks passed, 0 warnings) at 5 h 58 min 24 s. The cold-start check is a four-state simulation with the SRAM functional model, not a measurement on silicon.

Request 010, time of verified delivery. From this request on, a delivery needs both the clean-ZIP replay acceptance and a four-state cold-start pass of the routed netlist, and its time runs to the later of the two. Both paths passed the cold-start check at all three stages, RTL, generic synthesis and routed netlist; on the routed netlist, 62 directed checks passed with 0 SRAM reset warnings. Delivery times are 11 h 05 min 56 s for the baseline path and 11 h 05 min 48 s for the history path; to the ZIP replay acceptance alone they are 11 h 00 min 38 s and 11 h 04 min 03 s. The two paths' routed cold-start checks were started together, so the 8 s difference in delivery time and its order are not a difference between the paths; the ZIP replay acceptance of the baseline path came 3 min 25 s earlier. The request and delivery tables show the history path, whose delivery time is earlier, and the A/B summary does not count request 010 in either time order. Accuracy was checked separately on the final output, the residual sum, and on the branch value after layer scale. The table gives the residual sum; the branch value after layer scale has NRMSE 3.40%, max single-input NRMSE 3.47% and min cosine 0.9994, inside the same limits (NRMSE ≤ 8%, min cosine ≥ 0.995). The cold-start check is a four-state simulation with the SRAM functional model, not a measurement on silicon.

A/B: baseline and history paths

Requests 003 to 010 were each implemented once on each path, from the same request, inputs and acceptance limits. A retry is a repeated attempt after a failed automated check; shared retries happened in steps common to both paths.

• Delivered earlier with history: 004, 005, 008. Later: 003, 006, 007 (0.3 s), 009. Order not compared: 010.
• Cycles for one input fell: 004 −16.0%, 005 −31.1%, 006 −0.1%, 010 −0.1%. Rose: 003 +0.3%, 007 +0.3%, 008 +40.2%, 009 +1.2%. 4 of the 8 cycle-count changes are under 1%.

These are single observations, so the differences cannot be read as an effect of the history. Because the request table shows the earlier delivery, a request can show the path that finished first with more cycles (006, 008). Request 009 shows the history path, because a check after delivery found the delivery of the baseline path defective. Request 010 is counted as neither earlier nor later: both paths' cold-start checks were started together, so the order of the delivery times is not a difference between the paths. Request 002 compared the physical stage of one RTL only.

002 · Physical-stage A/B

Both paths used the same RTL, with and without earlier GF180 timing margins. Times cover place-and-route and gate replay for the final passing attempts. The final netlist hashes matched.

003 · Intake-to-delivery A/B

The paths implemented the same request against the same inputs and acceptance criteria. The history path received earlier failure and repair records.

004 · Intake-to-delivery A/B

The paths implemented the same request against the same inputs and acceptance criteria. The history path received earlier failure and repair records.

005 · Intake-to-delivery A/B

The paths implemented the same request against the same inputs and acceptance criteria. The history path received earlier failure and repair records.

006 · Intake-to-delivery A/B

The paths implemented the same request against the same inputs and acceptance criteria. The history path received earlier failure and repair records.

007 · Intake-to-delivery A/B

The paths implemented the same request against the same inputs and acceptance criteria. The history path received earlier failure and repair records.

008 · Intake-to-delivery A/B

The paths implemented the same request against the same inputs and acceptance criteria. The history path received earlier failure and repair records.

009 · Intake-to-delivery A/B

The paths implemented the same request against the same inputs and acceptance criteria. The history path received earlier failure and repair records. The elapsed times of both paths include 2 h 54 min of waiting that was not design or verification work: a tool usage-limit interruption and waiting for a cloud sign-in renewal.

010 · Intake-to-delivery A/B

The paths implemented the same request against the same inputs and acceptance criteria. The history path received earlier failure and repair records. The elapsed times of both paths include 6 h 53 min in which the run did not advance: a gap with no recorded work (6 h 15 min) and waiting for a cloud sign-in renewal after both paths' implementation had finished (38 min). They also include the failed first cloud run with its diagnosis and pre-test (17 min). Baseline path retry (1): SRAM reset warnings in the first directed check; the fix makes the reset edge a real transition on the SRAM enable. Shared verification retries (3): 2 fixes to shared verification runners after the request was frozen; 1 rerun of the first cloud run, in which both paths' routing passed but the shared packaging step stopped, with no path file changed. Shared reference preparation retries (1): 1 in reference preparation before the request was frozen. The order of the two delivery times comes from starting both cold-start checks together and is not counted in the A/B summary (see the note under What was delivered).

Public summary JSON · 2026-11-14