Repository navigation
Conversation
On silicon SetStandby aborts a reception, and a receiver that comes back to receive locks on only if enough preamble is left to detect. The inbox grace hands such a frame over anyway, which hides a driver that re-arms its receiver mid-frame or scans for activity while a frame is arriving. vsx_set_strict_receive turns the grace off for a host whose clock is the engine's own: a frame is refused unless the receiver entered receive with a detectable preamble still to come and stayed there to the end, and preamble detection only counts symbols heard in receive. vsx_frames_aborted counts the refusals. ABI 1.7; off by default, so every existing host is unchanged.
…d onto withdraws its header The part has no interrupt for a preamble that came to nothing, so a flag raised for a frame that never finished stays until the firmware clears it. Clearing both flags with the carrier hid that, and with it every firmware path that times a stale flag out. Under strict receive they now latch. HeaderValid is the model's stand-in for a header it cannot decode, raised from how long the carrier has lasted. Failure 3 on vsx_deliver_frame_failed says the receiver detected a frame and never locked onto it, and withdraws that stand-in while leaving PreambleDetected latched. Without strict receive it does nothing.
…eamble again ClearIrqStatus also forgot that this carrier's preamble and header had been detected, so the next tick raised them again for a preamble long gone. A driver that re-arms after every packet never saw it, because its receiver came back too late to hear the old preamble; one that stays in receive had its flags raised again on every clear and read busy for whole frames. Under strict receive the markers now outlive the clear and reset with the carrier. The lenient model keeps the old behaviour, which has the same fault, for the emulated hosts.
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
2 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.
On silicon
SetStandbyaborts a reception, a receiver that returns to receive locks on only if enough preamble is left to detect, and the detection flags stay latched until the firmware clears them. The model hid all three: the inbox grace delivered frames the receiver was not listening for, and the flags were cleared when the carrier ended. That hides any driver that re-arms mid-frame, runs CAD while a frame is arriving, or times out a stale flag.vsx_set_strict_receive(chip, on): a frame is received only if the receiver entered receive with at least four preamble symbols still to come and stayed in receive to the end. Preamble detection only counts symbols heard while in receive, and HeaderValid needs a detected preamble. The detection flags stay latched when the carrier ends.vsx_deliver_frame_failedfailure 3: the receiver detected the frame and never locked onto it. Under strict receive this withdraws the HeaderValid the model raised from the carrier's length and leaves PreambleDetected latched. Otherwise it does nothing. A library older than 1.7 reads 3 as a CRC error, so a host sends it only to 1.7 or later.ClearIrqStatusno longer makes the chip detect the same carrier's preamble and header again. Before, a clear mid-frame was followed on the next tick by both flags returning for a preamble that had long gone. A driver that re-arms after every packet never saw this, but one that stays in continuous receive read busy for whole frames: about 5 times the busy time on a 159-node run. The lenient model still has this fault, and I have left it alone so the emulated hosts are unchanged.vsx_frames_aborted(chip): how many frames were refused. This is a separate call rather than avsx_countersfield, so a host built against the older header is not handed a larger struct.Tests:
test/test_listening.cppcovers the grace still applying with strict receive off, a frame received while listening throughout, a re-arm in the payload losing the frame, a re-arm early in the preamble still locking on, a late start hearing no preamble, flags latching past the carrier, failure 3 withdrawing HeaderValid only under strict receive, failure 3 not being read as a CRC error, and a clear mid-frame staying clear for the rest of that carrier.test_c_abi.ccovers the two new entry points, including with a null handle.