Forum Discussion

relsaar's avatar
relsaar
Icon for New Contributor rankNew Contributor
5 years ago

Aria V Display Port core sometimes disconnected

Hi All We have a PCB board we designed with AMD 8860 GPU that sends DP video to Aria V Display Port core (Qsys). In some of our boards we sometimes have DP connection issues. The video signal goe...
Deshi_Intel's avatar
Deshi_Intel
Icon for Regular Contributor rankRegular Contributor
5 years ago

Hi,


I think the first thing we need to clarify is which DisplayPort IP that you are using here ? Are you using Bitec DisplayPort IP or Altera DisplayPort IP ?

  • If you are using Bitec DisplayPort IP
    • Then my suggestion to you will be to engage back Bitec for better issue support
    • I also share same concern with you on IP upgrade capability. Since this is not Altera IP, Intel Engineering won't support IP migration to latest Quartus version. Bitec should has their own IP migration strategy. Pls consult Bitec accordingly
  • Else if you are using Altera DisplayPort IP
    • Then it only make sense for you to perform IP migration to latest Quartus version.
    • Byright evaluation license should still able to generate sof file but I am not familiar with licensing issue. Perhaps you can contact your local FAE for licensing support ?


I presume you are referring to Rx channel CDR lock monitor signal (rx_is_lockedtodata)

  • Attached is the CDR loose lock debug checklist for your reference. It's targeted for C10 GX FPGA but the debug methodology is more or less the same
  • If you confirmed CDR is indeed loose lock on your board then there is no point to dump MSA log to debug DisplayPort anymore because your Rx transceiver channel already failed to sample/receive data in the first place before the data is passed to DisplayPort RX IP
  • When PPM threshold setting = 1000, it means it allow max PPM drift until 1000ppm while your oscillator ppm is only +-20ppm which is good. So, maybe ppm is not the issue here
  • Yup, your 135MHz refclk signal probe result looks bad but I am not sure is it due to your board design issue, or your probing contact issue or oscilloscope bandwidth issue ?
    • Did you manually hold your diff probe or use some tool to hold it or solder the probe tip on board ?
    • Also is your oscilloscope bandwidth at least 3x or 5x of 135MHz ?
    • Lastly, yes. Enable 100ohm OCT insides FPGA should help to improve the LVDS signal termination. Pls try it out.
  • You also mentioned your 1.67G Rx data transfer signal quality should be good
    • May I know how do you check it ? Did you run board simulation or use transceiver toolkit to to perform loopback testing on board ?


Thanks.


Regards,

dlim


  • relsaar's avatar
    relsaar
    Icon for New Contributor rankNew Contributor
    5 years ago

    Hi dlim

    We are using the IP catalog core from Quartos 15.0, I guess it is Intel Altera core but many of the generated files contain the word "bitech" on it. (see attachment). We intend to meet the local FAE tomorrow and check this issue.

    Regarding the lock signal I mentioned earlier - I'm sorry for the confusion - I was referring the MSA - lock that can be generated on the QSYS GUI as a trigger(see attached image)

    My signalTap also contain the below Transceiver Native PHY signals:

    • Rx_is_lockedtoref
    • Rx_is_lockedtordata

    I assume the first is indicating on ref clock signal integrity and the second on display port data signal integrity?

    Regarding the signal integrity issue,

    • Scope and probe BW are 4GHz
    • Probe was soldered to tips on board and was clumped to the PCB.
    • 100ohm OCT was not helpful

    Regarding your question on how we verify the video – we output the digital video signal from the Aria V in to external video encoder which convert it to analog screen. I was looking for the transceiver toolkit feature you mentioned but didn’t find such option. Can you please send me more info on how to use this feature?

    However after I reviewed the brd file I found out the LVDS clock pins, though short, have no ground plan above or below the clock signals. I suspect it is the root cause for the noise. In order to lower the clock noise I replaced the 162MHz clk with 50MHz clk and use Alt PLL to convert the clock back to 135MHz. It looks like the signal is less noisy now (see attached image).

    I’m running some tests to see if the failure is resolved or can be recreated again. Will update as soon as I have some answers.