Forum Discussion

JoEl's avatar
JoEl
Icon for Occasional Contributor rankOccasional Contributor
6 years ago
Solved

DisplayPort_TX IP in image video mode

Hi all,

I am working on transfer from classic DisplayPort video interface with Hsync, Vsync and DE to video image interface. Reason to switch is suport of adaptive synfchronization which should be supported and we want it to balance output FIFO loading by clock speed on output (almost same clock, faster or slower only by addition fractions of 1Hz increment).

I set whole interface as is described in manual page 49and you can check pictures in attachment. Second attachment is NIOSII sw with settings based on demo design. Is it here something I missed ? with video interface it worked but it doesn't have adaptive_sync property.

I appriciate any help,

Josef

  • JoEl's avatar
    JoEl
    6 years ago

    Hi guys,

    Finall answer on whats wrong with picture (protocol)at top is video valid signal. It have to be zero in blanking, and it have to be valid when eol, eof, sof and sol occur.

6 Replies

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    6 years ago
    Hi Josef, Can you help to clarify few things below so that I can help you better. 1) May I know which Intel FPGA that you are referring here ? is it Arria 10 or other FPGA family ? 2) Are you using Quartus Standard edition or Pro edition ? Which Quartus revision to be exact ? 3) Is this Display Port Tx only design or Display port Rx loopback to Tx design ? 4) Are you running the testing with your own design or using Display Port example design ? Thanks. Regards, dlim
  • JoEl's avatar
    JoEl
    Icon for Occasional Contributor rankOccasional Contributor
    6 years ago

    Hi dlim,

    I always forgot to write all important information...

    1) Design is for Arria 10

    2) I have QuartusII 18.1.1 pro

    3) It's TX only design

    4) It's my own design derived from example...

    Best regards,

    Josef

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    6 years ago
    Hi Josef, Thanks for the clarification. I checked back DP user guide doc. For DP TX, user is only required to checked "Enable Video Input Image Port" setting in DP source IP to enable adaptive sync feature. I believed you have done so. Byright it should work. 1) May I know what's the exact failure that you see with the adaptive sync feature ? 2) Also to clarify, DP IP adaptive sync feature only support AMD freesync, not Nvidia Gsync. Just to confirm your end monitor is using freesync or Gsync ? 3) Probably stupid question but have you turned on your GPU and monitor adaptive sync feature ? Just to double confirm Thanks. Regards, dlim
    • JoEl's avatar
      JoEl
      Icon for Occasional Contributor rankOccasional Contributor
      6 years ago

      Hi dlim,

      1)I might described my problem badly - we want to use clock enable at video_im_interface since there is table refering to feature that data don't need to be valid at every clock cycle and you are able to prolong period by deasserting txN_im_valid and slow down output for balancing input fifo. Sorry for wrong interpretation.

      2) our end device is generator/checker for now and we are able to see whats going on in cable.

      My current problem is that I generate correct data for tx_im_interface but HW checker doesn't see any valid video. As I have attached I generate valid, sof, eof, sol, eol... only thing is that we deassert video image valid on every second cycle as you can see in picture but according to design guide this should not be a problem.

      we find that when internal pattern generator is used, MSA params were calculated correctly which is not with HDMI source (same rate only difference is video valid deaserting) but link isn't trained and loop in training mode....so nor generator nor HDMI generate valid output.

  • JoEl's avatar
    JoEl
    Icon for Occasional Contributor rankOccasional Contributor
    6 years ago

    Hi all,

    problem with video_im_interface was caused by using clock_enble from our interface to drive video_im_valid. This signal stays valid even in blanking which cause endless data stream to dp_tx. This bug invoke interface training every few clock cycles. With video_im_valid correction - during blanking (bitwise & with data_enable), it seems to be correct with internal HDL signal generator.

    With HDMI source from outside with more variable clock_enable signal (caused by oversampling of HDMI) signal is not able to measure input parameters so there are no output clock / data, but link was established.

    Q: Is it problem to use clock enable like we have it in picture below ?

    point to think about: I agree that we should have valid pixel when eol/eof occur - can it be problem?

    Thank you,

    JoEl

  • JoEl's avatar
    JoEl
    Icon for Occasional Contributor rankOccasional Contributor
    6 years ago

    Hi guys,

    Finall answer on whats wrong with picture (protocol)at top is video valid signal. It have to be zero in blanking, and it have to be valid when eol, eof, sof and sol occur.