The gap
The W-series took GF-T's own operators to the die: bitstream_w973.json records a
full native openxc7 run (yosys → nextpnr-xilinx → prjxray, no Docker) on
xc7a200tfbg676-1, Fmax 80.35 MHz, timing PASS; confirm_w990.json records
gft_signed_mac reading 0xa5a5337f identically across four placements and three
distinct BSCAN sites. That is real on-die measurement.
The paper's headline hardware claim is not among it. Grepping
research/arxiv_tnf/measurements/*.json for tef_add_full or tekum16_adder
returns nothing. The numbers the paper trades on —
tef_add_full @ TNF(4,8): 397 LUT / 45 CARRY4 vs takum16 linear model
1,182 LUT / 211 CARRY4 = 2.98×tekum8_decode.v: 542 LUT vs 1 LUT for the TNF field slice- full datapath 38×
— are all yosys post-synthesis, no P&R, no board. So the format's own operators have
been to silicon and the competitor comparison has not.
What to run
Both adders through the same flow W973 used, same part, and record post-P&R
utilisation rather than post-synthesis:
| design |
path |
| TNF adder |
fpga/tef/tef_add_full.v at (4,8) |
| tekum adder |
fpga/openxc7-synth/tekum16_adder.v |
Record per design: LUT, CARRY4, DSP48E1 after place-and-route, Fmax, and
PASS/FAIL — in the same shape as bitstream_w973.json so verify_numbers.py can
check it.
Watch the counting trap. PR #599 established that every xc7 LUT figure had been
exactly 3× too high: synth_xilinx prints its own statistics before ours, and the
sample summed all blocks. Count once, from the post-P&R report.
Why this is filed rather than done
nextpnr-xilinx is not installed on the host this was written from — only
nextpnr-ice40, which cannot target Artix-7. The full flow lives on the host that
produced W973 (/Users/playom/t27/… appears in deletion_w992.json). yosys and
openFPGALoader are here; place-and-route is not.
Coordinate before running. Three AX7203 boards are on one bus and another
session has been driving them for die reads. Two agents on one JTAG chain is the
shared-medium failure this project already has a doctrine about: a poisoned bus
makes correct designs test as broken.
The gap
The W-series took GF-T's own operators to the die:
bitstream_w973.jsonrecords afull native openxc7 run (yosys → nextpnr-xilinx → prjxray, no Docker) on
xc7a200tfbg676-1, Fmax 80.35 MHz, timing PASS;confirm_w990.jsonrecordsgft_signed_macreading0xa5a5337fidentically across four placements and threedistinct BSCAN sites. That is real on-die measurement.
The paper's headline hardware claim is not among it. Grepping
research/arxiv_tnf/measurements/*.jsonfortef_add_fullortekum16_adderreturns nothing. The numbers the paper trades on —
tef_add_full@ TNF(4,8): 397 LUT / 45 CARRY4 vs takum16 linear model1,182 LUT / 211 CARRY4 = 2.98×
tekum8_decode.v: 542 LUT vs 1 LUT for the TNF field slice— are all yosys post-synthesis, no P&R, no board. So the format's own operators have
been to silicon and the competitor comparison has not.
What to run
Both adders through the same flow W973 used, same part, and record post-P&R
utilisation rather than post-synthesis:
fpga/tef/tef_add_full.vat (4,8)fpga/openxc7-synth/tekum16_adder.vRecord per design: LUT, CARRY4, DSP48E1 after place-and-route, Fmax, and
PASS/FAIL — in the same shape as
bitstream_w973.jsonsoverify_numbers.pycancheck it.
Watch the counting trap. PR #599 established that every xc7 LUT figure had been
exactly 3× too high:
synth_xilinxprints its own statistics before ours, and thesample summed all blocks. Count once, from the post-P&R report.
Why this is filed rather than done
nextpnr-xilinxis not installed on the host this was written from — onlynextpnr-ice40, which cannot target Artix-7. The full flow lives on the host thatproduced W973 (
/Users/playom/t27/…appears indeletion_w992.json). yosys andopenFPGALoaderare here; place-and-route is not.Coordinate before running. Three AX7203 boards are on one bus and another
session has been driving them for die reads. Two agents on one JTAG chain is the
shared-medium failure this project already has a doctrine about: a poisoned bus
makes correct designs test as broken.