Withdraw the 323 MHz / 41.2 GOPS claim for the GF16 matmul - #626
Merged
Conversation
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>
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 posedgereturns 0 for every one of the nine copies ofgf16_matmul4x4/gf16_dot4in these repositories — including the canonicaltri-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"
gf16_mul.vline 29full_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.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-xilinxreports 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