Skip to content

fix(trit): ternary MAC adder_tree_27 overflow — wrong dot product on dense vectors - #1733

Merged
gHashTag merged 1 commit into
masterfrom
fix/mac-adder-tree-overflow
Aug 5, 2026
Merged

gHashTag merged 1 commit into
masterfrom
fix/mac-adder-tree-overflow

Conversation

@gHashTag

@gHashTag gHashTag commented Aug 5, 2026 •

Copy link
Copy Markdown
Owner

Model-critical correctness bug in the ternary MAC core, found by a new functional testbench.

Bug

adder_tree_27 (from gen-trit-stdlib, wrapped by trit27_dot_product → pipeline_stage2_compute) declared level-2 as wire signed [3:0] l2 [0:2]; (range [-8, +7]). But each l2[j] = l1[3j] + l1[3j+1] + l1[3j+2] with l1 ∈ [-3, +3] has range [-9, +9] — so a group of 9 same-sign trits (sum ±9, or even ±8) overflows.

Symptom: input = {27{+1}}, weight = {27{+1}} → expected dot product +27, actual −21 (each level-2 group of 9 wrapped +9 → −7; 3 × −7 = −21). Single-trit / sparse cases were correct, so the existing substring asserts never caught it.

Fix

Widen l2 to signed [4:0] (range [−16, +15]). Level-1 (signed [2:0] holds [−3,+3]) and level-3 (signed [5:0] holds [−27,+27]) were already correct.

Verification

New golden-vector functional testbench tests/bitnet_compute_mac.rs (iverilog + vvp) drives pipeline_stage2_compute with known trit chunks:

  • allP×allP = +27, allP×allN = −27, allN×allN = +27, allZ = 0, single-trit = +1, multi-chunk +27 then −27 accumulates to 0.
    All pass after the fix; −21/+21 before it. Skips gracefully without iverilog. The unit test that had codified the buggy signed [3:0] width is updated.

trit_stdlib.rs is not under the FROZEN_HASH seal (only compiler.rs), so no reseal. Full suite green apart from the pre-existing, unrelated bitnet_top reds (#1726).

This is the functional instrument that makes the engine-top datapath fix (input≡weight aliasing at bitnet_top.rs:217) provable, per the observability-before-mutation discipline.

🤖 Generated with Claude Code

Closes #1732

…verflow)

adder_tree_27 declared level-2 as signed [3:0] (range [-8,+7]), but each
l2[j] = l1[3j]+l1[3j+1]+l1[3j+2] with l1 in [-3,+3] has range [-9,+9]. A
group of 9 same-sign trits (sum +/-9) overflowed, so an all-+1 dot product
read -21 instead of +27. Widen l2 to signed [4:0].

Found by a new golden-vector functional testbench (tests/bitnet_compute_mac.rs,
iverilog+vvp) that drives pipeline_stage2_compute with known trit chunks and
checks the accumulated result. Updated the unit test that had asserted the
buggy signed [3:0] width. trit_stdlib.rs is not under the FROZEN_HASH seal;
no reseal.

Closes #1732

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-05 18:00:49 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 1
PRs with All Checks Green 49
READY 0
FAILING 1
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=864a709e6e17 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag
gHashTag merged commit 19c01fc into master Aug 5, 2026
27 of 30 checks passed
@gHashTag
gHashTag deleted the fix/mac-adder-tree-overflow branch August 5, 2026 18:03
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.

bug: ternary MAC adder_tree_27 overflows on dense same-sign vectors (wrong dot product)

1 participant