Aria V Display Port core sometimes disconnected

Hi,

Since you are using altera_dp IP which means this is Altera DisplayPort IP, not Bitec DisplayPort IP.

• You should be able to upgrade to latest Quartus version after you sort out the licensing issue with your local dFAE support. Pls try out Quartus Standard v20.1 if possible
• The reason you are seeing a lot of Bitec design internally is due to Altera previously purchased Bitec DisplayPort IP, modified and repackage into Altera DisplayPort IP

Now while you are reviewing your board design, let's sort out the debug step to capture the right debug status signal first in order to determine the right debug direction.

• DP Rx data flow from GPU -> FPGA (FPGA Transceiver Rx channel -> DP Rx Sink IP)
• That's why I mentioned earlier if Transceiver Rx channel can't capture/sample the Rx data properly then the data will break/corrupt in transceiver channel before reaching DP Rx IP. No point to debug DP RX IP anymore.
• We can monitor "Rx_is_lockedtodata" signal to check whether Rx channel CDR is in locked mode or not. Ignore "Rx_is_lockedtoref" as you are not using it. Both are status signal of CDR but it's meant for different CDR operation mode. You should be referring to "Rx_is_lockedtodata"
• CDR lock indicated the data rate speed is correct and Rx channel can sample data at the correct data rate speed. (but we won't know the correct data content is receive or not)
  • So, can you tell me whether "Rx_is_lockedtodata" stay high or de-asserted in your video test failure scenario ? Pls share with me the signal_tap file result
• Then next is to check whether correct video data content is sample correctly at DP Rx IP or not. You can monitor via MSA lock signal (which you already did)
  • You mentioned MSA loose lock. One of the possibility is due to data corruption due to high "bit error rate (BER)", bad signal integrity on the board - either on the refclk source or the DP Rx channel itself.
  • We can monitor DP soft 8b/10B decoder IP status signal like *code_err" and "disp_err" to verify whether it's related to high BER or not. Can you try to find these status signal in your signal_tap and capture them in failure condition ?
• Another possibility that I can think of is there is limitation of DP bandwidth transfer.
  • From your DP Rx sink IP setting, you configure it to 1.62G with 1 lane count only
  • May I know what exact video resolution and bit per colour that you set in your GPU ?
  • Attached is the DP BW calculation guideline to help you verify you video data transfer doesn't exceed DP link BW
• Another thing I noticed is your "pixel output mode" = single.
  • This may put some pressure on your design timing closure as you need higher DP operating frequency
  • May I know is your design timing closed at Quartus Timequest ?
  • Also, maybe you can consider to change the setting to "quad" to relax the design timing requirement

Thanks.

Regards,

dlim