gft_signed_mac answers incorrectly on silicon (clauses 0011, ok=0) while passing 2/2 in simulation — the die check is stronger than the spec's tests

[gHashTag]

gft_signed_mac — the ladder's central arithmetic operator — loads, runs, and answers incorrectly on real silicon, while passing every test its spec contains. This is an editorial and engineering decision, so it is filed rather than fixed.

The measurement

Same bench, same session, same toolchain, control satisfied — a foreign bitstream forced Done = 0 before ours brought it to 1:

operator	simulation	LUT	Fmax	on-die clauses	ok
gft_sadd	3 / 3 passed	1 312	18.24 MHz	1111	1
gft_signed_mac	2 / 2 passed	6 466	9.14 MHz	0011	0

beat = 1 in both reads: the MAC is alive and clocking. It closed timing at 9.14 MHz against a 2.21 MHz target — 4.1× margin — so a setup violation is not the obvious explanation.

The root issue is test strength, not silicon

The MAC's spec ships two simulation tests; its on-die check evaluates four clauses. The two that fail are not covered in simulation.

The die check is stronger than the suite the spec carries. That is why the defect survived to a physical load — the cheapest oracle in the project never asked the questions the most expensive one answers.

gft_sadd carries three tests and satisfies all four clauses: its suite and its die check agree because the behaviour is correct in both.

What this asks for

1. Derive the simulation tests from the on-die clauses. Free, and it moves this class of defect from "found after a bitstream load" to "found in seconds". This is the single highest-value change.
2. Diagnose the two failing clauses. They are clauses=0011 on USER1, design id 13, word 0xa5a5334e. Whether the fault is in the generated Verilog, the spec, or the on-die harness is not yet established.
3. Consider whether L4 should require oracle parity. A spec satisfies TESTABILITY today by containing tests. It can do so while its tests are weaker than a check the same repository already runs.

What is not claimed

Not that the φ-format is arithmetically wrong — the failure is in this implementation of one operator, on one part, with one toolchain. gft_sadd passing 4/4 establishes that the path and the reader are sound, which is what makes this red meaningful rather than suspect.

Every number here is recomputed from committed records by research/arxiv_tnf/verify_numbers.py (281 checks). Related: #683, #682, #681.

Filed by the autonomous wave loop.

[gHashTag]

Diagnosed (W976, #685). The word decodes exactly, and the two failing clauses have different causes.

ZERO is a logic defect — no hardware needed to confirm it

Driving the same generated Verilog in icarus with the wrapper's own operands:

[ZERO]  live=0 live2=0 -> 512    (must be 0)
[ZERO]  live=1 live2=7 -> 516    (must be 0)
[ZERO]  live=2 live2=14 -> 520   (must be 0)
[ZERO]  live=3 live2=21 -> 524   (must be 0)

points=64  ZERO violations=64

mac(0, x, 0, y) returns 512 + 4x instead of 0 — independent of the second operand over the range probed, reproduced in 25 µs of simulated time. Multiplying by zero does not give zero, and the residue is linear in one operand. Testbench committed as research/arxiv_tnf/tb_zero_comm_w976.v.

COMM is confirmed on silicon and unexplained off it

Three targeted attempts, zero reproductions:

attempt	coverage	violations
dense sweep	64 consecutive live	0
diverse probes	32 values incl. 0x7FFFFFFF, 0x80000000, 0xFFFFFFFF	0
per-cycle transients	960 samples across 23 operand changes	0, and 0 ready skew

The third tested a named mechanism: the clause registers are sticky (if (!comm_ok) c_comm <= 1'b0) and the comparison is not gated on ready, so one disagreeing cycle would latch it false forever. No such cycle occurs.

Remaining candidates: a physical effect (against a 4.1× timing margin), or an operand sequence the die reaches over hours that a bounded sweep does not. Recorded as unexplained rather than guessed.

Why it survived to a bitstream

The spec's tests cover exactly the two clauses that pass. ZERO and COMM are untested — and the two tests assert on fixed constants while every die clause drives live operands. A test that supplies one operand value cannot see a residue that grows with the operand.

Filed by the autonomous wave loop.

[gHashTag]

Root cause found (W977, #686): the MAC keeps a private copy of the multiply, and it lost the zero guard.

	line	zero guards
GftSmul	333: prod = __mul_noop((512 + am), (512 + bm))	if (a == 0) @258, if (b == 0) @262
GftSignedMac	69: prod = __mul_noop((512 + am), (512 + bm))	none — the word "zero" never appears

GftSignedMac is a flat module with zero instances of GftSmul or GftSadd. The 512 + is the format's implicit leading one, so a zero operand is multiplied as though it carried a hidden one — giving mac(0,x,0,y) = 512 + 4x.

One missing guard explains both die results: smul's ZERO clause is true on silicon, the MAC's is false.

Three cheaper hypotheses were tested and refuted first — sadd(0,0) = 0, smul(0,12345) = 0, and smul commutativity held over 20 pairs — which is what left the MAC's own body as the only place the defect could be. #685's measurement was also re-verified gated on ready and came back identical.

Suggested fix

Either emit the zero guard in the MAC's inline path, or — better — have the MAC instantiate GftSmul instead of re-deriving it. The second removes the class, not just this instance: nothing today compares two emissions of the same arithmetic.

Still open

gft_smul's COMM and IND clauses are false on the die and were not reproduced in simulation (20 operand pairs for COMM). Those remain unexplained and are separate from the zero defect.

Filed by the autonomous wave loop.