[P0][matched-substrate] GF16 vs posit16/takum16/binary16 head-to-head на AX7203 (закрыть FL-002)

[gHashTag]

Цель

Закрыть открытую гипотезу breadth-as-moat через pre-registered matched-substrate эксперимент: прогнать GF16, posit16, takum16, binary16 на одной плате AX7203 (XC7A200T-2FBG484I, IDCODE 0x13636093) в идентичных условиях.

Что сделать

• Собрать 4 RTL-кодека на одной FPGA-подложке (open-source takum-16 RTL как референс)
• Единый тестбенч + идентичный harness (LUT / Fmax / decode-conformance)
• UART-лог N/N bit-exact @160000 baud для каждого формата
• Свести head-to-head таблицу: lut_lc / routable / decode_pass

Критерии закрытия (Tier-E chain 4/4)

CI run GREEN URL + bitstream SHA256 + UART fails=0 + IDCODE 0x13636093 для GF16.
Статус результата: [измерено на FPGA]. НЕ заявлять превосходство до фактических чисел.

Ссылки

• protocol/MATCHED_SUBSTRATE_EXPERIMENT.md (репо arith2027-goldenfloat)
• FL-002 falsification ledger
• Позиционный документ goldenfloat_positioning_2026 (приоритет P0, закрывает риск R3)

[gHashTag]

Cross-repo dependency — blocks gHashTag/arith2027-goldenfloat#4

This issue's matched-substrate head-to-head data (GF16 vs posit16/takum16/binary16 on
AX7203) is Contribution #3 of the ARITH-2027 submission tracked in
arith2027-goldenfloat#4
(task-list item: "Дождаться данных matched-substrate"). #4 cannot complete until #233
delivers. Linking here for bidirectional traceability.

(Note: cross-repo GitHub task-list items don't auto-tick on close — when #233 lands,
manually update the checkbox in arith2027-goldenfloat#4.)

[gHashTag]

Matched-substrate head-to-head — HW data (2026-07-04, AX7203)

All four 16-bit formats flashed + UART-verified on the same AX7203 (IDCODE 0x13636093 = XC7A200T rev 1) today. Every format is bit-exact on silicon, fails=0. This is the measured substrate for the breadth-as-moat / FL-002 comparison.

Format	Op proven on HW	HW result	LUT (CI-synth)	BRAM	Bitstream SHA256
binary16	decode (exhaustive)	65536/65536	131	0	4504943e…
posit16	decode (64-vec seeded)	64/64	175	0	179a7194…
gf16	ADD compute (512+HAS_INF)	512/512	468	0	d709df05…
takum16	decode (64-vec seeded, BRAM-LUT)	64/64	32281	BRAM	5cfd2e4b…

Tier-E re-proofs on #199: gf16 ADD → issuecomment-4881164443; posit16/takum16/binary16 → consolidated decode re-proof comment (same thread).

Reading (honest, no superlatives)

• All four correct on one substrate. No format fails on AX7203; each is bit-exact vs its independent golden (posit/takum via mpmath-class oracles, binary16 via C-library half + explicit NaN-payload, gf16 via in-width+commutativity+HAS_INF).
• Cost spread is large and real. binary16 (131 LUT) ≈ posit16 (175) ≪ gf16 (468) ≪≪ takum16 (32281, BRAM-LUT — takum's log-domain decode needs a 65536-entry LUT). This is measured LUT from yosys, not estimated.
• gf16 tested as ADD compute (its GoldenFloat strength — the parametric MAC). A pure decode head-to-head (gf16 decode vs the others' decode) needs the gf16 decode cell separately; flagged as a follow-up if a strict apples-to-apples decode-only table is wanted for the ARITH submission.
• fmax NOT captured — nextpnr writes Max frequency to /tmp inside the Docker CI runner, not published as an artifact. If fmax is needed for the matched-substrate table, it must be re-captured from a local nextpnr run (out of scope for this replay).

What this closes / leaves open for #233

• Closes: all four formats are now HW-replayed on one dated substrate (2026-07-04) — the "is the comparison measured?" question is answered YES.
• Open (FL-002 breadth-as-moat): "correct on HW" ≠ "breadth moat". breadth-as-moat remains an [открытая гипотеза] — this data is necessary but not sufficient to claim it. The GF-family coverage (GF4..GF256 via one parametric gf_adder_param) is the moat argument; this quartet proves the 16-bit instance on silicon but does not by itself falsify/confirm the broader claim.
• Open (gf16 decode): add gf16 decode cell to make the table decode-only apples-to-apples, if ARITH reviewers want it.

This data feeds ARITH-2027 contribution #3 (arith2027-goldenfloat#4) and the arXiv:2606.05017 flagship artifact.

[gHashTag]

Unblocker for the apples-to-apples decode head-to-head → tracked in #237

The gf16-decode cell (decode gf16 u16 → FP32) does not exist yet — all gf16 RTL is compute (add/mul/alu/mac). The current quartet data above compares gf16 as ADD-compute against posit16/takum16/binary16 as decode, which is not apples-to-apples. A reviewer at ARITH (arith2027-goldenfloat#4) will flag exactly this.

Full design ТЗ filed as #237 (P0): RTL spec, 5-class decode law, testbench plan, AX7203 XDC, CI-workflow, Tier-E 4/4 acceptance. Until #237 lands, the decode-only cost-spread column (binary16=131 / posit16=175 / gf16=~tens-150 / takum16=32281) is estimated for gf16, not measured. When #237 closes, update this table to a strict 4-format decode-only comparison.