Release Candidate v2.73.0#1441
Open
ruck314 wants to merge 102 commits into
Open
Conversation
Appears to work fine.
Add a generic to allow for disabling of the safe buffering scheme. This reduces the number of buffers from three to one, saving on resources. However, it becomes possible to write to/read from the same buffer at the same time, possibly corrupting the data. This option may be used if the user knows that write/read never happens at the same time and would like to save on resources.
Supported in newer VHDL standards but not the one used for vivado build it seems.
The non-oneshot one would drop triggers it seems (on hardware). Not sure if this is really due to the synchronizer or some more intricate timing issue that just happens to be resolved from switching to the oneshot synchronizer...
Implement handshake between clock domains to make sure no signals are missed. Allow trigger signal synchronous to either data or axil clock.
Does not test async clock case. Would be harder to validate and not sure if necessary.
They will be mentioned in PR thread.
Returning from wait to idle state before rdMoveDoneSync is de-asserted leads to the FSM immediately moving back to wait and thus jumping between wait and idle until rdMoveDoneSync returns to 0. Now the FSM waits until rdMoveDoneSync returns to 0, then moves back to idle.
…dRxReg The 0x24 address decode had its read and write actions swapped: the write branch drove rdata from r.rxPowerDown while the read branch loaded v.rxPowerDown from wdata. Swap them so AXI-Lite writes set rxPowerDown and reads return its current value.
…eadback The read decode never cleared v.axilReadSlave.rdata before the address case, so bits left over from a previous read of a wider register could leak into the readback of a narrower field. Zero rdata at the start of every read transaction, matching the JesdRxReg decode.
… multiframe Per JESD204B section 8.2 (Figure 50) and 8.3 (Tables 20/21), the second ILAS multiframe must carry /Q/ (K28.4) at octet 1 followed by 14 link-configuration octets including the FCHK checksum. JesdIlasGen previously emitted only the /R/ and /A/ frame delimiters. - JesdIlasGen: add mfCnt/wordCnt counters and emit /Q/ plus the 14 config octets during the second multiframe (mfCnt=1) in GT byte order. FCHK is the mod-256 sum of config octets 0-12. - Add Q_CHAR_C (K28.4, 0x9C) to Jesd204bPkg. - Thread the ILAS link-config generics (DID_G, BID_G, M_G, N_G, NPRIME_G, CS_G, S_G, HD_G, CF_G) through JesdTxLane and Jesd204bTx, and drive per-lane LID via a new lid_i port. All generics and the lid_i port are defaulted so existing instantiations compile unchanged. The SURF RX ILA state counts multiframes and does not parse config octets, so the added content cannot break SURF-to-SURF links.
…mments - Jesd204bPkg: drop the unused jesdScrambler procedure (no references anywhere in the library; the per-lane scrambling lives in JesdScrCmb/descrambler logic). - JesdSyncFsmRx: correct the comma-detect comment (the AND chain spans four consecutive cycles, not three) and remove the stale readBuff TODO note. - Jesd204bTx: replace the 'scrambling not tested' header warning now that TX scrambling is exercised end-to-end by the cocotb loopback bench.
…s plumbing Add a cocotb-based regression suite for the JESD204B library under tests/protocols/jesd204b: - jesd204b_test_utils.py: golden models (LFSR scrambler, LMFC, ILAS timeline builders) and shared testbench helpers - Unit benches: JesdLmfcGen, JesdScramblerWrapper, Jesd16bTo32b, Jesd32bTo16b, JesdSyncFsmTx, JesdIlasGen, JesdTxLane, JesdSyncFsmRx, JesdAlignFrRepCh, JesdRxLane - Register benches: JesdTxReg and JesdRxReg full map walks - test_Jesd204bLoopback: end-to-end TX-to-RX loopback across parameter cases with golden scrambler cross-checks - README with the coverage model and bench-to-module map Add cocotb-facing wrappers under protocols/jesd204b/wrappers that flatten record ports and expose AXI-Lite/GT interfaces for simulation (JesdTxLaneWrapper, JesdRxLaneWrapper, JesdScramblerWrapper, Jesd204bTxWrapper, Jesd204bRxWrapper, Jesd204bLoopbackWrapper), and load them from ruckus.tcl.
HTSP: parameterize HtspRxFifo/HtspTxFifo application AXI-Stream width
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1441 +/- ##
=======================================
Coverage ? 24.93%
=======================================
Files ? 273
Lines ? 23856
Branches ? 0
=======================================
Hits ? 5949
Misses ? 17907
Partials ? 0 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Enforce RAM_ADDR_WIDTH_G <= 32 so that axilR.rdFinalAddr fits a 32 bit register (32 bit wide should be enough in practice). Move the remaining registers to make space. Test case had to be adjusted to now test for the new softTrig register.
RoCEv2: AXI-Stream RDMA datapath, engine refactor, DCQCN + line-rate RDMA-SEND
Implement AxiStreamFrameBuffer
PR #1418 was merged from a fork that never ran CI. Its test module imported numpy, which is not listed in pip_requirements.txt, so the CI runner failed at pytest collection time with ModuleNotFoundError and returned a non-zero exit code despite all other tests passing. numpy was used only for the pi and e constants that set the asynchronous clock ratios. Replace them with the stdlib math module (identical values) so the test no longer needs numpy, matching the rest of the suite.
fix(axi-stream): drop numpy dependency from AxiStreamFrameBuffer test
Upgrade third-party actions to their latest release and pin each to the full commit SHA (tag recorded in the trailing comment), per the slaclab SHA-pinning policy. First-party slaclab/ruckus reusable workflows are left on @main.
Repo hygiene: pin/upgrade Actions to SHAs
The outbound DHCP Discover/Request built the SECS/FLAGS word as x"00080000", which places 0x08 in the flags-high byte on the wire (AXI lane 0 = first wire byte), yielding flags=0x0800. The RFC 2131 4.1 broadcast flag is bit 15 (0x8000), so the intended value is x"00800000". With the broadcast flag clear, a spec-compliant server unicasts its Offer/ACK to the not-yet-leased yiaddr. On some networks that reply is never delivered to the client (it does not yet own the IP), so the client never receives the Offer and loops on Discover, never acquiring an address. Setting the broadcast flag makes the server broadcast the reply, which the client reliably receives. The bug is present in every release since v1.0.0. Add a regression test: extract_dhcp_bootp_flags() plus assertions in the DHCP offer/ack sequence test that the Discover and Request advertise the broadcast flag. The test fails on the unpatched RTL (flags=0x0800) and passes with the fix.
RFC 2131 (figure 2) marks the 15 non-broadcast bits of the BOOTP flags field as MUST-BE-ZERO. The bitmask assertion (flags & 0x8000) would still pass if a future change set stray bits (e.g. 0x8800). Assert exact equality to 0x8000 instead — strictly stronger, and the RTL already emits exactly that value. Test-only change; no RTL touched.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…er, retransmit) Add four cocotb tests to test_UdpEngineDhcp.py that all pass on the current RTL, locking in RFC 2131 client-side behavior beyond the happy-path DORA sequence: - Mismatched-XID offer is discarded; the engine re-discovers (RFC 2131 4.4.1). - Mismatched-CHADDR offer is discarded even when the XID matches. - Full offer/request/ack completes with a scrambled TLV option block (leading pad, subnet mask, 17-byte domain name, lease time, server identifier, interleaved pads, message-type last), exercising the byte-serial option parser's ordering and unknown-option handling. - With no server reply, the discover is retransmitted after the communication timeout. build_dhcp_reply_payload gains a keyword-only raw_options escape hatch so tests can supply an arbitrary option block without duplicating the fixed-header construction; the default path is unchanged. Adds DHCP_OPT_PAD/SUBNET_MASK/ DOMAIN_NAME option-code constants.
The IDLE_S state incremented the transaction ID on every transmission, including the SELECTING-state DHCP Request that VERIFY_S triggers immediately after accepting an Offer (it forces commCnt := 0, re-entering the IDLE_S transmit path). RFC 2131 4.4.1 / Table 5 requires that Request to carry the same XID as the Discover/Offer exchange, so the previous behavior sent a Request with discover_xid + 1. Guard the XID increment: bump it only for a new Discover (dhcpReq = '0') or a lease renewal (leaseCnt /= 0). The SELECTING Request (dhcpReq = '1', leaseCnt = 0) now reuses the existing XID; renewal transactions still take a fresh one. Fail-first evidence: adding the request_xid == discover_xid assertion to udp_engine_dhcp_offer_ack_sequence_test fails on the pre-fix RTL with "Request XID 0x00000002 does not match Discover XID 0x00000001"; with the RTL guard applied the full module passes (5/5 cocotb tests), and the wider tests/ethernet regression passes (68/68).
The regression job collected tests/axi, tests/base, tests/dsp, tests/protocols, and tests/ethernet/RoCEv2, but not tests/ethernet/UdpEngine, so the UdpEngine cocotb suite (including the DHCP corner-case coverage) never executed in CI. Add tests/ethernet/UdpEngine to the pytest invocation so these tests run on every push.
Add RSSI regression foundation
Fix DHCP BOOTP broadcast flag and XID continuity in UdpEngineDhcp (RFC 2131)
ruck314
marked this pull request as ready for review
July 13, 2026 18:56
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
4 participants
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.
Description