Skip to content

Withdraw the 323 MHz / 41.2 GOPS claim for the GF16 matmul - #626

Merged
gHashTag merged 1 commit into
mainfrom
fix/withdraw-unsupported-claim
Aug 8, 2026
Merged

Withdraw the 323 MHz / 41.2 GOPS claim for the GF16 matmul#626
gHashTag merged 1 commit into
mainfrom
fix/withdraw-unsupported-claim

Conversation

@gHashTag

@gHashTag gHashTag commented Aug 8, 2026

Copy link
Copy Markdown
Owner

I tried to re-derive the headline figure from the RTL and could not. Here is what the sources show.

The block has no registers

grep -c posedge returns 0 for every one of the nine copies of gf16_matmul4x4 / gf16_dot4 in these repositories — including the canonical tri-net/fpga/gf16. A block with no registers has no clock domain, so no achieved frequency can belong to it. 41.2 GOPS was 323 MHz × 128 ops/cycle, so it goes with it.

Two things that bear on "0 DSP48"

Finding Detail
gf16_mul.v line 29 full_mant_a * full_mant_b — a plain multiply. Synthesised for xc7, the real 4×4 matmul takes 64 DSP48 and 21,223 LUTs. Zero DSP is reachable by forcing fabric mapping (32,252 LUTs) — a synthesis choice, not a property of the arithmetic.
Both openXC7 top modules Feed the matmul literal constants with B as the identity matrix, so synthesis folds the arithmetic away. Those netlists are 54 cells: a 20-inverter ring oscillator, a 23-bit counter, two LEDs. Any frequency from them describes the counter.

What the pages say now

The synthesis figures measured today, and the withdrawal stated explicitly in the existing "what these results are not" section rather than quietly dropped. On a site whose premise is that its numbers were measured, a visible withdrawal is worth more than a claim nobody checked.

The sample report — linked from every page and every outreach email — is corrected the same way, and now explains that nextpnr-xilinx reports no frequency at all for DSP48 designs, with a worked sequential example at 112.33 MHz post-route.

Not touched: the arXiv papers and the profile README. Those are yours to correct, and they need the same pass.

🤖 Generated with Claude Code

Re-derived the figure from the RTL today and could not. What the sources show:

The GF16 4×4 matmul holds no registers. Not in the copy under t27/fpga/vivado,
not in the canonical one under tri-net/fpga/gf16, not in any of the nine copies
of gf16_matmul4x4 / gf16_dot4 across these repositories — `grep -c posedge`
returns 0 for every one. A block with no registers has no clock domain, so no
achieved frequency can belong to it, and 41.2 GOPS was derived from that
frequency times 128 operations per cycle, so it goes with it.

Two further things the re-check surfaced, both bearing on "0 DSP48":

- `gf16_mul.v` multiplies mantissas with a plain `*` (line 29 in both copies).
  Synthesised for xc7 the real 4×4 matmul takes 64 DSP48 blocks and 21,223
  LUTs. Zero DSP is reachable, but by forcing fabric mapping — 32,252 LUTs —
  which is a choice made at synthesis, not a property of the arithmetic.
- Both top modules used in the openXC7 flow feed the matmul literal constants,
  with B as the identity matrix, so synthesis folds the arithmetic away
  entirely. Those netlists come to 54 cells: a 20-inverter ring oscillator, a
  23-bit counter and two LEDs. Any frequency measured from them describes the
  counter, not a matrix multiplier.

The evidence page, the licensing page and the sample report now carry the
synthesis figures that were actually measured today, and the withdrawal is
stated in the "what these results are not" section rather than quietly dropped.
On a site whose whole premise is that its numbers were measured, a withdrawal
that is visible is worth more than a claim that was never checked.

Nothing here touches the arXiv papers or the profile README — those are the
author's to correct, and they need the same pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@gHashTag
gHashTag merged commit 89861ba into main Aug 8, 2026
23 of 42 checks passed
@gHashTag
gHashTag deleted the fix/withdraw-unsupported-claim branch August 8, 2026 11:04
github-actions Bot added a commit that referenced this pull request Aug 8, 2026
Withdraw the 323 MHz / 41.2 GOPS claim for the GF16 matmul (#626)

Re-derived the figure from the RTL today and could not. What the sources show:

The GF16 4×4 matmul holds no registers. Not in the copy under t27/fpga/vivado,
not in the canonical one under tri-net/fpga/gf16, not in any of the nine copies
of gf16_matmul4x4 / gf16_dot4 across these repositories — `grep -c posedge`
returns 0 for every one. A block with no registers has no clock domain, so no
achieved frequency can belong to it, and 41.2 GOPS was derived from that
frequency times 128 operations per cycle, so it goes with it.

Two further things the re-check surfaced, both bearing on "0 DSP48":

- `gf16_mul.v` multiplies mantissas with a plain `*` (line 29 in both copies).
  Synthesised for xc7 the real 4×4 matmul takes 64 DSP48 blocks and 21,223
  LUTs. Zero DSP is reachable, but by forcing fabric mapping — 32,252 LUTs —
  which is a choice made at synthesis, not a property of the arithmetic.
- Both top modules used in the openXC7 flow feed the matmul literal constants,
  with B as the identity matrix, so synthesis folds the arithmetic away
  entirely. Those netlists come to 54 cells: a 20-inverter ring oscillator, a
  23-bit counter and two LEDs. Any frequency measured from them describes the
  counter, not a matrix multiplier.

The evidence page, the licensing page and the sample report now carry the
synthesis figures that were actually measured today, and the withdrawal is
stated in the "what these results are not" section rather than quietly dropped.
On a site whose whole premise is that its numbers were measured, a withdrawal
that is visible is worth more than a claim that was never checked.

Nothing here touches the arXiv papers or the profile README — those are the
author's to correct, and they need the same pass.

Co-authored-by: Dmitrii Vasilev <admin@t27.dev>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant