dw_upsizer: Pad when the fast path accepts a beat carrying TLAST

[dngr2]

Independent of #8 — different module, no shared lines, either can go first.

The bug

AcceptDataIn moves to Pad when a beat arrives with TLAST before the wide word is full, so the partial word gets flushed. The DataOut fast path (// already accept next subtransfer) also consumes a beat and latches its TLAST, but returns to AcceptDataIn unconditionally.

So a frame whose final beat is taken through that path is never padded. Its remainder sits in the register with the stream idle, and leaves later merged into whichever frame next fills the word.

One frame silently truncated, the next silently corrupted, and nothing reports an error.

Which lengths

Only lengths one beat past a word boundary reach the fast path with TLAST set. At 64 bits out / 8 bits in that is 9, 17, 25… A length of 1 is unaffected, because the first beat after reset is taken by AcceptDataIn.

Sweeping every length from 1 to 24 beats against the unfixed module:

  PASS  8-beat frame emits 1 word(s)
  FAIL  9-beat frame emits 2 word(s) -- emitted 1
  PASS  10..16-beat frames
  FAIL  17-beat frame emits 3 word(s) -- emitted 2
  PASS  18..24-beat frames

Exactly the ≡1 (mod 8) lengths, as the mechanism predicts.

This matters beyond the abstract case: pulp-ethernet instantiates this module in exactly this configuration on its receive path, so an Ethernet frame of 65, 73 or 1513 bytes hits it.

The fix

The beat accepted on the fast path is the first of a new word (counter_d == 1), and DataWidthOut > DataWidthIn is asserted at elaboration, so the word cannot already be full. TLAST alone therefore decides, and Pad handles the alignment exactly as it does for the AcceptDataIn path.

The testbench

test/tb_axi_stream_dw_upsizer_last.sv, registered in Bender.yml.

Two deliberate choices, both of which the bug hides behind:

• It sweeps every length from one beat to three words rather than picking one. A single hand-chosen length very likely misses this — I would have missed it myself had I not swept.
• It holds TVALID high across the frame. Insert a gap before the final beat and the fast path is never taken, so the bug does not appear.

Against the unfixed module three checks fail; with the fix all pass, including content checks that the 9-beat frame's tail byte, TKEEP=0x01 and TLAST are right rather than merely that two words came out.

Verified with Verilator 5.006. As with #8, CI here runs license, commit and verible lint but no simulation, so this is a local result and worth an independent check.

[dngr2]

Note on the force-push you will see on this branch: the commit author email was wrong, and I corrected it. The tree is unchanged — same diff, same tests, only the author metadata differs.

I know CONTRIBUTING.md asks contributors not to force-push. The alternative was leaving a commit whose author is not a linked GitHub account, and util/lint-commits.py rejects that, so amending seemed the lesser of the two. It will not happen again on this branch; any review feedback will come as new commits on top.

[fischeti]

Thanks a lot @dngr2. It would also really help if you could write down a cookie recipe.

[dngr2]

Ha — I think I'll keep the baking off GitHub. Happy to address anything on the actual upsizer change though; just point me at it and I'll push a commit.