Harden RSSI RX FSM filtering and payload timing

[bengineerd]

Description

Fix RSSI receive-side header filtering, SYN parameter staging, and payload-buffer timing.

RssiRxFsm previously accepted some malformed or unsupported receive-side combinations too late, or after partially updating local state. In particular, SYN parameter fields could be copied into the visible peer-parameter record before the full SYN header passed checksum and frame-boundary validation. DATA legality also depended partly on registered state from the previous segment, and duplicate DATA could enter the payload-buffer path before being rejected later.

The receive application path also assumed payload RAM read data was available in the same cycle that a buffered DATA entry was selected. That was fragile with the registered RAM path used in RssiCore, especially for one-word DATA frames and final-beat pause handling.

This changes RssiRxFsm to stage SYN parameters until the full SYN is validated, reject unsupported SYN/EACK/DATA flag combinations before payload buffering, require DATA to be the next in-order sequence before writing payload RAM, and add an explicit application READ_S state for registered RAM read latency. The RX FSM regression is ungated now that these cases pass.

Details

This fix is necessary because RSSI receive validation has to protect both protocol state and payload RAM contents. A malformed SYN should not alter the negotiated-parameter inputs seen by the connection FSM. DATA must carry the expected RSSI data semantics, not unsupported EACK/BUSY/NULL/RST combinations, and duplicate DATA should not be allowed to disturb receive-buffer side state after the original segment has already been delivered.

This usually worked until now because common traffic uses well-formed SYN/DATA headers, ordered delivery, and enough idle cycles that the registered RAM latency was not obvious. The bugs show up in directed regressions that intentionally send malformed SYNs, unsupported EACK/DATA flag combinations, checksum-failed payloads followed by retransmission, duplicate DATA after delivery, and one-word DATA through the same registered RAM timing used by RssiCore.

The relevant protocol intent is:

• RSSI headers carry fixed header lengths and checksums; those checks must pass before header fields are trusted.
• SYN carries connection parameters and should be accepted only as a clean SYN frame, not mixed with NULL, BUSY, RST, or unsupported EACK semantics.
• DATA and NULL are sequenced receive traffic; the hardware RX path only buffers the next in-order DATA payload.
• NULL updates receive sequencing/acknowledgement state but is not delivered as application payload.

The Rogue RSSI controller follows the same broad receive model:

• Header::verify() parses flags, checks the header length and checksum, and only then exposes sequence, acknowledge, and SYN parameter fields in Header.cpp;
• receive ACK and BUSY state are handled as control information before sequenced DATA/NULL processing in Controller.cpp;
• SYN is routed to the connection-state path rather than the application data path in Controller.cpp;
• DATA or NULL advances the receive sequence only when it matches nextSeqRx_, while duplicates are dropped in Controller.cpp;
• NULL frames are removed before application delivery in Controller.cpp.

Rogue's software controller can queue out-of-order frames, while this SURF RSSI v1 hardware path keeps the simpler in-order receive-buffer contract. This PR keeps that hardware contract, but makes the RTL enforce it before payload RAM writes and before visible SYN parameter updates.

Validation:

./.venv/bin/python -B -m pytest -q -p no:cacheprovider tests/protocols/rssi/test_RssiRxFsm.py
2 passed
./.venv/bin/python -B -m pytest -q -p no:cacheprovider tests/protocols/rssi
4 passed, 19 skipped
./.venv/bin/vsg -c vsg-linter.yml -f protocols/rssi/v1/rtl/RssiRxFsm.vhd protocols/rssi/v1/wrappers/RssiRxFsmWrapper.vhd
0 violations
git diff --check
clean

Related

Stacked on #1453.