feat(gtx7): resolve odd comma landings in fabric behind RX_ODD_ALIGN_MODE_G

[ruck314]

Description

Gtx7RxFixedLatPhaseAligner answered an odd comma landing by forcing Gtx7RxRst back to INIT, unbounded and unobservable, so a link whose CDR kept landing odd never finished its RX reset.

New RX_ODD_ALIGN_MODE_G on Gtx7Core and Gtx7RxFixedLatPhaseAligner:

• "RESET" (default) - today's behavior, bit for bit. Callers that leave the generic unset are unaffected.
• "BITSLIP" - resolves an odd landing in fabric: slide to a residue of 1 using only even rxSlide counts, then present a constant one-bit slice of the aligner's word history. The RX is never reset, so bring-up is bounded.

	"RESET"	"BITSLIP"
Fabric latency added	0	exactly 1 rxUsrClk: 5.385 ns @ 3.714 Gbps, 8.403 ns @ 2.380 Gbps
Odd landing	asserts the aligner's rxReset, re-locks the CDR	resolved in fabric, RX never reset
Bring-up	unbounded relock loop	bounded

"BITSLIP" is fixed-latency for every landing, odd and even. Three quantities are in play and they are easy to conflate:

Quantity	Granularity	Landing-dependent?
Fabric stages to rxDataOut	whole rxUsrClk	No. One stage, all twenty landings.
Absolute latency vs "RESET"	whole rxUsrClk	No. Constant +1 rxUsrClk.
PMA recovered-clock phase	sub-UI, bounded by 1 UI	Open, see below.

The first row is what a user application sees on rxData, and it holds because rxDataAlignedSel asserts in both of the aligner's terminal states, not only the slipped one:

rxDataAlignedSelInt <= '1' when (BITSLIP_MODE_C and ((r.state = ALIGNED_S) or (r.state = ALIGNED_SLIP_S))) else '0';

An even landing therefore takes the registered path too. Letting it fall through to rxDataInt is the natural-looking design and is the trap: even landings would be combinational off RXDATA while odd landings sat one stage behind, so the two parities would differ by a full parallel-clock period, 5.385 ns @ 3.714 Gbps. Both terminal states instead source the word one rxUsrClk after the GT presented it, ALIGNED_S from the previous GT word unshifted and ALIGNED_SLIP_S from that word shifted up one bit with its missing MSB taken live. One stage is the floor rather than a convenience: at a final offset of 1 the aligned word's last bit only arrives with the next GT word, so it cannot be presented combinationally.

Getting there also depends on slideCount := i-2 in the odd branch, which issues i-1 pulses, an even count, so every odd landing settles at a residue of exactly 1 and the fabric slice is a constant bit range rather than an offset-dependent one.

That constant is EXPECTED_TRAIL in the regression, asserted per mode rather than argued, and each of the twenty landings is checked to present the same frame on the same cycle as every other one in its mode. Choosing "BITSLIP" costs one re-calibration of the absolute number, not run-to-run jitter.

Opting into "BITSLIP"

Needs RX_ALIGN_MODE_G = "FIXED_LAT" and RX_BUF_EN_G = false, both enforced by an elaboration assert, plus rxDataValidIn driven from a decoder rather than left at its '1' default. "BITSLIP" never asserts the aligner's rxReset, so recovery from a lost alignment rests entirely on Gtx7RxRst's DATA_VALID supervision. Several in-tree callers hardwire rxDataValidIn => '1' and would need that port wired first.

The one open question: sub-UI, silicon and not RTL

Even landings settle at GT offset 0, odd landings at offset 1. Whether a final offset of 1 costs a sub-UI recovered-clock phase step relative to offset 0 is a property of the GTX PMA, not of this RTL, and no fabric simulation can settle it. It is bounded by 1 UI, one twentieth of the word clock: 269.2 ps @ 3.714 Gbps, 420.2 ps @ 2.380 Gbps. This is separate from the fabric latency contract above, which is constant across landings either way.

Removing the term at all would mean refusing odd landings, which is exactly what "RESET" does and what "BITSLIP" declines to do. Settling it is a hardware measurement (power-cycle N times, bin a latency measurement on landing parity) that has not been made, so a link with a sub-UI phase budget should stay on "RESET" until it is.

For that measurement, landedValid is the bin discriminator, not landedOffset: the observer latches only the first odd offset seen since reset, so landedValid = '1' marks the odd class with its actual offset in landedOffset, and landedValid = '0' marks the even class. There is no positive even-landing marker.

Also on this branch, independent of the above

• cPllRefClkLostOut added to Gtx7Core, exposing CPLLREFCLKLOST. This is an entity interface change: a new out port with no default, so a caller using positional association must be updated. Named association, the SLAC convention, needs no change.
• WAIT_TIME_CDRLOCK_G added, decoupling the CDR-lock wait count from SIM_RESET_SPEEDUP. Its -1 default selects the previous derivation, so it is behavior-preserving.

Verification

• Cocotb (tests/xilinx/gtx7/test_Gtx7RxFixedLatPhaseAligner.py): both modes across all twenty comma landings, driven from a bit-accurate serial stream. Each landing must align, present a correctly comma-aligned word, and present the same frame on the same cycle as every other landing in its mode; per-mode absolute latency is pinned against EXPECTED_TRAIL and mutation-tested. Scope limit: the aligner is elaborated, but Gtx7Core's output mux is reproduced by the harness, since Gtx7Core needs GTXE2_CHANNEL and does not build under GHDL.
• "RESET" equivalence: pre-change and post-change aligners co-simulated from identical stimulus are cycle-identical on rxReset, rxSlide and rxPhaseAlignmentDone over 12000 cycles spanning five aligner-driven RX resets.
• VCS co-simulation with real GTX7 primitives: under "BITSLIP" the affected lane reaches RX reset done from an odd landing and holds it for 2.07 ms with no further cycling. With both mode generics at their defaults, the same bench reproduces the pre-change failure identically.
• Three Vivado 2024.1 runs on XC7K160TFBG484-2: timing closes with no new critical-warning message classes, and the untouched lane's elaborated GTXE2_CHANNEL parameters match the pre-change baseline apart from an enumerated set of corrected constants.
• Hardware: the affected lane holds RX reset done through a full software startup sequence, and the previously-working lane still links up. Hardware covered link-up and regression, not latency; the latency contract rests on simulation.

landedOffset and oddLandingCount are declared inside the "BITSLIP" generate, so the legacy path gains no logic, but they are reachable only by hierarchical netlist name under dont_touch. Promoting them to real output ports is left to a follow-up.