Forum Discussion

vilem's avatar
vilem
Icon for New Contributor rankNew Contributor
3 months ago

DisplayPort Sink (Quartus 18.1) – horizontal pixel offset.

We are experiencing an issue with the DisplayPort Sink IP core (Quartus Prime 18.1), where the captured video stream becomes horizontally shifted after some runtime. The system works correctly after ...
general
VenT_Altera's avatar
VenT_Altera
Icon for Frequent Contributor rankFrequent Contributor
2 months ago

Hi vilem, 

 

My apologies for the delayed reply, and thanks for the update — the CRC reset restoring alignment is a very useful finding. 

Regarding a newer CRC on Quartus 18.1, the Clock Recovery Core is delivered with the design example for that Quartus release and is not supported as a standalone upgrade from a newer Quartus into 18.1. As a runtime workaround, automating the CRC reset you already validated (when the alignment is wrong). 

 

I have the following questions to clarify: 

  1. What is the device family/OPN, link rate and lane count set?  
  2. When the image is shifted, do MSA values (HSTART, HTOTAL, HWIDTH) stay the same, or do they change? Also, do msa_lock / rx_vid_locked / BER counters glitch at that moment? 
  3. While the image is shifted, does the DP Sink still declare video lock (rx_vid_locked asserted)?

 

On the extender: try a lower negotiated link rate or fewer lanes, check the firmware, since the failure only appears with the extender. 

 

Thanks. 

Best Regards, 

Ven

  • vilem's avatar
    vilem
    Icon for New Contributor rankNew Contributor
    2 months ago

    Hi Ven,

    ad 1) DP1.2-VisionXG-Fibers(S), 4 optical pairs, HBR2

    ad 2) When the image is shifted all MSA values stay the same. 

    ad 3) When the image is shifted DP Sink still declare video lock.

    In the meantime, we found that CRC itself amplifies the consequences of the issue cause. When we removed CRC from the design the frames did not stay shifted. There is only 1 frame shifted and the following frames are correct. The damaged frame is indicated in changing of SOL/SOF, EOL/EOF signals on the DP Sink output.

    Thanks

    Best Regards,

    Vilem

       

    • VenT_Altera's avatar
      VenT_Altera
      Icon for Frequent Contributor rankFrequent Contributor
      1 month ago

      Hi vilem,


      I sincerely apologize for the delayed response.


      May I know which FPGA device family you are using (e.g., Arria 10, Cyclone V, etc.)?

      As a workaround, would it be possible to implement the auto-reset CRC on glitch?

      I understand that migrating your design from Quartus v18.1 to the latest Quartus v26.1.1 may not be feasible in your scenario. Based on your observations, I noticed that a new FIFO_ADDR_WIDTH parameter was added to the Clock Recovery Core in Quartus v25.1 (https://docs.altera.com/r/docs/683273/25.3/displayport-ip-user-guide/clock-recovery-core-parameters). If feasible, you may create a simplified test design and increase the FIFO_ADDR_WIDTH from its default value of 9 to 10 using Quartus v25.1. This increases the depth of the input FIFO in the Clock Recovery Core and help to accommodate higher-jitter input sources. Prior to Quartus v25.1, the FIFO was fixed to value of 9. Starting from Quartus v25.1, this parameter was exposed at the top level of the bitec_clkrec module, allowing users to increase the FIFO depth when dealing with higher-jitter input sources.


      Thanks.

      Best Regards,

      Ven

      • vilem's avatar
        vilem
        Icon for New Contributor rankNew Contributor
        1 month ago

        Dear Ven,

        thank you for your reply. We use Arria V family. Is there any way how to use the new Clock Recovery Core (Quartus v25.1) in our Quartus v18.1 design?

        Thanks.

        best Regards,

        Vilem