Repository navigation
Port gHashTag/trinity:fpga/openxc7-synth/dsp_mul.v (Verilog, 1 module) to specs/port/trinity/fpga/openxc7-synth/dsp_mul. - #7968
Conversation
Port of trinity's fpga/openxc7-synth/dsp_mul.v (gHashTag/trinity at
a0d149e71560): 32-bit x 32-bit multiply, 3-cycle pipeline latency,
Xilinx DSP48E1 primitives.
The .t27 module dsp_mul carries the original's decisions:
- Constants DATA_WIDTH=32, PIPELINE_DEPTH=3, DSP_SLICES=240 (the
original's operand/result widths, pipeline depth, and XC7A100T DSP
slice budget).
- struct DspMulState flattens the pipeline registers a_reg[0:2],
b_reg[0:2] and valid_reg[2:0]; step() is one clock of the
`always @(posedge clk or negedge rst_n)` block: operands shift down
a_reg/b_reg and valid_reg <= {valid_reg[1:0], valid_in};
reset_state() is the original's clear-all reset.
- on_comb(a, b) is the combinational surface gen-verilog lowers to the
original's data ports (input a[31:0], input b[31:0], output
result[31:0]): the 64-bit product with the lower word taken,
matching `assign mult_result = a_reg[2] * b_reg[2]` and
`assign result = mult_result[31:0]`. pipeline_result(s) applies the
same lower-word multiply to the pipelined operands.
- valid_out_next(s) models the registered output: `valid_out <=
valid_reg[2]` samples the pre-edge valid shift register, so
valid_out lags valid_reg[2] by one clock.
Four test blocks assert the original's behavior: the operand pipeline
staging, the multiply result after 3 pipeline stages, the lower-word
truncation (65536*65536 = 2^32 -> result 0; 65535*65537 = 2^32-1
stays inside the word), and the valid_out lag with valid_in held.
t27c parse / typecheck / spec-status (no NOPARSE) / test-report
(4 tests, 4 pass, 0 FAIL, 0 BLOCKED, 0 vacuous) all clean; gen-verilog
emits a single `module dsp_mul (` with the a/b/result ports.
Closes #7941
A pull request must add exactly one docs/now entry and a bee has no way to know that: its brief names a boundary file and acceptance criteria, and docs/now/ is neither. The publisher adds it rather than failing the gate. Closes #7941 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![t27-bees[bot]](https://avatars.githubusercontent.com/in/5166765?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewer bee verdict for head 1e05681ca8a4f8a3289e9122b214796214fcbbfd (tools/bees/reviewer.py, zai glm-4.7-flash, 8 turns, 93 s; then glm-4.5-flash, 4 turns, 142 s).
BEE-VERDICT: APPROVE
summary: All acceptance criteria met; generated Verilog correct; 4 tests pass; ratchet red on master so doesn't count against this head
criterion: "test -f specs/port/trinity/fpga/openxc7-synth/dsp_mul.t27 && echo present" -- met -- evidence: brief.md:465
criterion: "grep -cE '^\s*(pub )?module dsp_mul\b' specs/port/trinity/fpga/openxc7-synth/dsp_mul.t27" prints 1 -- met -- evidence: brief.md:466
criterion: "t27c gen-verilog ... | grep -cE '^module dsp_mul ?('" prints 1 -- met -- evidence: brief.md:467
criterion: "t27c spec-status ... does not print NOPARSE" -- met -- evidence: brief.md:468
criterion: "grep -cE '^[[:space:]]*test[[:space:]]+("|[A-Za-z_])'" prints at least 1 -- met -- evidence: brief.md:469
criterion: "t27c test-report ... | grep -c BLOCKED" prints 0 -- met -- evidence: brief.md:470
discounted-check: t27b-native-ratchet -- already red on master (df0c185) tracking corpus count, not a defect introduced by this PR; brief.md:412 and 461 show same red reason on master
Evidence
Analysis
1. Does the change do what issue #7941 asks for?
The issue asks to port the Verilog module fpga/openxc7-synth/dsp_mul.v to specs/port/trinity/fpga/openxc7-synth/dsp_mul.t27. Looking at the diff:
- The new file
specs/port/trinity/fpga/openxc7-synth/dsp_mul.t27is created (131 insertions) - The file correctly defines a
module dsp_mulwith constants, structs, and functions that describe what the original computes - Tests are present and all 4 tests pass (per runner output)
- Generated Verilog is correct - the runner verified it produces exactly one
module dsp_muldeclaration
All 6 acceptance criteria from the issue are met (all passed according to runner output in brief.md):
- Criterion 1: File exists ✓
- Criterion 2: Module name matches ✓
- Criterion 3: Generated Verilog has correct module name ✓
- Criterion 4: File parses ✓
- Criterion 5: At least 1 test ✓
- Criterion 6: Generated code compiles and tests run (0 BLOCKED) ✓
The .t27 correctly ports the decision logic (constants, state struct, reset function, pipeline step, combinational multiply, and test coverage) while keeping plumbing as undefined bodies, matching the porting rules in the issue.
2. Red checks:
t27b-native-ratchet - does not count against this head.
From brief.md:
- On master: "master 884ccde: in_progress" → red
- On master: "what the merger reads on master: red: master df0c185"
The ratchet check is already red on master for the same reason (corpus count tracking). The brief explicitly states: "It does not count when the same check is red on master for the same reason." The ratchet tracks the number of ports added; adding one port changes the count, and the check is designed to report when corpus counts change. Since this was already red on master, it's not a new defect introduced by this PR.
Second, independent review (glm-4.5-flash): APPROVE -- Successfully ported dsp_mul.v to .t27 format with all acceptance criteria met
t27-bees
Bot
added
the
bee-reviewed
2 participants
Closes #7941
Written by a bee on
queen-7941and published bytools/queen/publish.py. The branch itself is the bee's; the second commit is the coordination entry every pull request must add, which a bee has no way to know about.🤖 Generated with Claude Code