GF-T16 multiply: correct RTL, correct netlist, wrong bitstream through openXC7's DSP path

[gHashTag]

Summary

gft16_mul is correct — in simulation, in synthesis, and when mapped to LUTs. But a bitstream built from the DSP-mapped netlist through the openXC7 flow (yosys → nextpnr-xilinx → prjxray) computes the wrong answer on silicon.

Your RTL is not implicated and your published areas reproduce exactly. This is a warning for anyone building GF-T through openXC7 rather than your own flow.

What reproduces exactly

fpga/gft/SYNTH_RESULTS.md was re-run on a different host with yosys 0.63 (yours: 0.65), using your .ys scripts unmodified:

unit	DSP claim/meas	LUT claim/meas	CARRY4 claim/meas
gft16_mul	1 / 1	47 / 47	18 / 18
gft_add	0 / 0	483 / 483	45 / 45
gft_alu	3 / 3	634 / 634	114 / 114
gft_dot4_tile	4 / 4	705 / 708	124 / 124
gft_dot4	12 / 12	1673 / 1673	303 / 303

Four exact, one off by 3 LUT (0.4%, yosys version). No discrepancy of any kind in your numbers.

What fails

gft16_mul + gft_mul verbatim, in a port-less BSCANE2 harness, checked by your own KAT vectors from gft16_mul_kat_tb.v — no expected value re-derived, so no second implementation in the loop.

build	φ¹·φ¹ → (42,0)	1.5×1.5 → (43,64)	cells
iverilog, behavioural RTL	pass	pass	—
gate-level sim of the synthesised netlist vs xilinx/cells_sim.v	pass	pass	1 DSP48E1
bitstream, on silicon	pass	FAIL	1 DSP48E1, 56 LUT
bitstream, -nodsp, on silicon	pass	pass	0 DSP, 53 LUT

Hardware: 3× QMTech Wukong XC7A200T-FGG676, idcode 0x3636093. Five stable reads per build per board, each bracketed with a wrong-part bitstream so Done went 0 → 1 before every read. Reply nibble is {v0_ok, v1_ok, done, sig}:

DSP build       a5a5a5aa   v0 ok, v1 FAIL     boards 1:4, 1:6, 1:8
LUT-only build  a5a5a5af   v0 ok, v1 ok       boards 1:4, 1:6, 1:8

Deterministic, three dice, both directions.

Where the fault is — and is not

Cleared: the RTL (passes behavioural sim) and yosys (its DSP-mapped netlist passes gate-level sim against yosys's own DSP48E1 model).

Remaining: nextpnr-xilinx FASM emission, or prjxray's DSP48E1 frame model.

The natural hypothesis — that the DSP's operating mode never reaches the bitstream, which would explain why only the nonzero-product vector fails — is refuted: the FASM carries OPMODE, ALUMODE, INMODE and the register controls (21 non-GND DSP lines), and prjxray models the tile with 436 segbits.

Separating nextpnr from prjxray needs a reference bitstream for the same netlist (Vivado, or a DSP48E1 unit test with known frames). Not attempted here.

Practical consequence

On the openXC7 flow, -nodsp costs 3 LUT (56 → 53) and both vectors pass. The DSP is not a saving on this flow.

Your on-chip claims were made through your own flow on an AX7203, which this does not test — it tests openXC7 on a QMTech board.

Reproduce

yosys -p "read_verilog -sv gft_mul.v gft16_mul.v <harness>.v; \
          synth_xilinx -family xc7 -top <harness> -flatten; write_json k.json"
nextpnr-xilinx --chipdb xc7a200t*.bin --json k.json --fasm k.fasm
# fasm2frames, xc7frames2bit, openFPGALoader
# expect a5a5a5aa ; then add -nodsp and expect a5a5a5af

Full write-up and harness: docs/reports/TRINET-DSP-DEFECT-W723.md and fpga/verilog/gft_kat_jtag.v in gHashTag/t27, branch claude/igla-fpga-improvements-3f5e1a.

[gHashTag]

Update — isolated to a 40-line reproducer, and it is not GF-T

Two follow-up experiments narrow this considerably, and both of my earlier hypotheses are refuted.

-nodsp blocks DSP inference but keeps an explicit instance, so one bitstream can carry a hand-instantiated DSP48E1 and a LUT-built reference of the same product, with the die comparing them.

build	simulation	silicon	DSP48E1
constant operands, USE_DPORT("FALSE")	pass	PASS	1
constant operands, USE_DPORT("TRUE") + pre-adder	pass	PASS	1
live operands from an LFSR	pass	FAIL	1

Reply nibble {dsp==lut, lut!=0, agree, done}: a5a5a5af for both constant builds, a5a5a5a5 for the live one. Five stable reads each, every one bracketed with a wrong-part bitstream so Done went 0 → 1.

The DSP48E1's static configuration is not the problem — feeding it live fabric signals is.

Refuted: "the operating mode never reaches the bitstream"

It does. The FASM carries OPMODE, ALUMODE, INMODE and the register controls (21 non-GND DSP lines), and prjxray models the tile with 436 segbits.

Refuted: "the D-port pre-adder path is at fault"

The FASM diff between the working probe and the failing gft16_mul was exactly three lines — USE_DPORT[0] twice and ZIS_INMODE_INVERTED[2] — which looked decisive. But a probe built with USE_DPORT("TRUE") and INMODE[2]=1 passes on silicon, duplicated FASM line and all.

So the duplicated USE_DPORT[0] is harmless. The diff compared two designs that differed in more than one way.

Where it points now

Routing data into the DSP48E1 input pins — nextpnr-xilinx's DSP input routing, or prjxray's model of those pips. Separating those two still needs a reference bitstream (Vivado), which this host does not have.

Why this matters beyond GF-T

The reproducer is ~40 lines of Verilog with no GF-T, no gft16_mul, and no 47-LUT multiplier: fpga/verilog/dsp_probe.v and fpga/verilog/dsp_probe_live.v in gHashTag/t27, branch claude/igla-fpga-improvements-3f5e1a. Anyone using openXC7 with a DSP fed from the fabric is exposed, not just GF-T.

Your RTL and your published areas remain unaffected — they reproduced exactly (see the opening comment).

[gHashTag]

What the workaround costs — the -nodsp table

Since the DSP path yields a wrong bitstream on openXC7 when its operands come from the fabric, the usable area figures for that flow are the -nodsp ones. Measured with your own .ys scripts, yosys 0.63, synth_xilinx -flatten ± -nodsp:

unit	DSP	LUT	CARRY4	LUT (-nodsp)	ΔLUT	LUT per DSP
gft16_mul	1	47	18	236	+189	189
gft_add	0	483	45	483	0	—
gft_alu	3	634	114	640	+6	2
gft_dot4_tile	4	708	124	1504	+796	199
gft_dot4	12	1673	303	6000	+4327	361

Forecast registered before the run was 200–400 LUT per DSP; measured 189 / 199 / 361 on the units that do real multiplying.

Two observations you may find useful regardless of this bug

1. gft16_mul is a 236-LUT unit on openXC7, not a 47-LUT one. The single DSP carries most of its work. This does not touch your published figure — which reproduced exactly — but any comparison against LUT-network prior art built through openXC7 should use 236.

2. gft_alu sheds all three DSP48E1 for six LUT. Two LUT apiece. yosys is inferring three hard macros for work that is essentially free in fabric. Even on a flow where the DSP path is correct that looks like an inference artefact worth a look; on this flow, -nodsp for gft_alu is strictly better — same size, and it avoids the broken path entirely.

These are yosys stat cell counts, pre-route, and not a hardware claim. The defect they respond to is the hardware-measured one in the comments above.