How long should rx_is_lockedtodata be asserted before a valid connection can ACTUALLY be assumed?

Had to tweak XCVR_RX_SD_THRESHOLD and XCVR_RX_COMMON_MODE_VOLTAGE values to 3 and VTT_0P70V respectively to get things working for PCML-1.5, but that did the trick.

In fact, activating the signal detect circuit gates rx_is_lockedtodata as well, so the only change needed in my state machine was to remove the delay timer.

Is signaldetect just looking for the common mode voltage to be above the specified value or is it actually watching for transitions?

After some more testing the reliability of establishing a connection is still flaky.

That is once a connection is successful it works great, but getting a connection is unreliably.

For example when in the bad state, every time the following packet is sent:

003C, 0200, 1234, 5678

The following is received:

003C, 023C, 1234, 567C, 5678

This is looking directly at rx_parallel_data with signal tap after both rx_is_lockedtodata and rx_std_signaldetect are high.

The state machine does not have any way to detect this because when empty packets are being sent they look fine:

003C, 0000, 0000, ....

Received:

003C, 0000, 0000, ....

Is it possible for rx_is_lockedtodata to have false positives (besides the 4us timeout)?

It is as if some component within the Native Phy is partially out of alignment.

Right now tx_std_clkout is connected to both tx_std_coreclkin and rx_std_coreclkin so as to keep everything in the same clock domain and simplify the design on my side. The documentation states that there is alignment logic that will take care of some discrepancy between rx_std_coreclkin and rx_std_clkout as long as they don't drift relative to each other. Since both FPGAs are running from the same reference, that requirement should be satisfied. Maybe the alignment logic is not as strong as the documentation suggests?

Maybe the state machine is going to have to do some additional handshaking by sending test data to make sure everything is aligned, then toggle rx_std_wa_patternalign again if that fails.

But that is annoying since sending a comma symbol (3C and datak=1) every packet really should be enough to get a good alignment.

Version info:

Quartus Prime Version 18.1.1 Build 646.

I'll try your points 1 and 2. In the meantime I've also included what I hope are the files that you are asking for.

As a side point:

You mention that connecting rx_clkout to rx_coreclkin is the recommended connection. I don't see this recommendation in any documentation.

On page 11-8 (pdf page 293) of this document https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/xcvr_user_guide.pdf

It says that it can be connected to any clock that the user wants. Specifically: "FPGA fabric clock, the FPGA fabric RX interface clock, or the input reference clock"

Obviously the clock used cannot drift relative to the transmitter or the fifo will overflow or underflow as the case may be, but that is guaranteed since I'm using the same reference for both FPGAs.

Admittedly that page is detailing information for the Low Latency PHY IP core not the Native PHY IP core. But that is not the only bit of information that is only mentioned for one variant of the IP core that is reasonably applicable to all the variants. For example, the fifo overflow possibility is only mentioned in the Interlaken section.

Is there better documentation somewhere else?