cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jtx
Visitor
Visitor
941 Views
Registered: ‎12-03-2019

Displayport 1.4 TX - Native interface - fastclock, vid_clk ratio.

Hi,

I am implementing Displayport 1.4 TX , Native interface w/4ppc on a custom board  (w/Vivado 2019.2).

I have a question regarding use of the native interface. In PG299(v2.1) 14 May 22, 2019, page 58 :

‘Note: Data Valid might toggle if using a fast clock.’

I am getting image displayed on monitor when presenting an UHD@60Hz with a fast clock of 150MHz. The difference in clock ratios (150MHz(fast clock) and 133MHz(vid_clk)) is tuned by toggling the Data Valid within in the line/required timing).

When I try this for XGA(1024x768@60Hz->65MHz vid clk) resolution,  no image is presented on monitor. The VESA timing is (divided by 4) and ‘Data Valid’ toggled slower (evenly distributed) to compensate for the difference in ratio between the fast clock(150MHz) and vid_clk(16.25MHz). Are there any maximum ratio requirements between fast clock and vid_clk?

Thanks in advance.

 

0 Kudos
11 Replies
watari
Teacher
Teacher
914 Views
Registered: ‎06-16-2013

Hi @jtx 

 

Would you make sure MVID and NVID value on DPCD to investigate this issue when video timing is XGA ?

Also, how many lanes is DP Tx using ?

It might be PLL issue...

 

Best regards,

0 Kudos
florentw
Moderator
Moderator
875 Views
Registered: ‎11-09-2015

Hi @jtx 

The data valid can toggle during Vertical timing. However, it needs to remain stable during horizontal timing. As per pg299:

DP.JPG

This means you can have lines with no data but you cannot have pixel clocks with no data during a line where you had data

I guess this might be something you want to check on your design.

Hope that helps


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
jtx
Visitor
Visitor
847 Views
Registered: ‎12-03-2019

Hi,
the used mode is asynchronous, so the M- and N-value is automatically computed by source and writtten to the mainstream. Use 4ppc/4 lanes in HBR2 at the moment.

Thanks

0 Kudos
watari
Teacher
Teacher
838 Views
Registered: ‎06-16-2013

Hi @jtx 

 

According your explanation, DP Tx will generate dummy packets to fill in the blank.

However, a few monitors can't accept like this situation.

Because they want to change lane number, if they don't have enough adjusment logic...

 

Would you make sure HPD signal, too, if possible ?

 

Best regards,

0 Kudos
jtx
Visitor
Visitor
837 Views
Registered: ‎12-03-2019

Hi @florentw

So the data_valid shall be conitinious over the horisontal resolution (line) of 1024pix/4ppc=256 clocks in 'XGA mode'?


Based on this the vid_clk must be exact the pix clock frequency described in XGA VESA format 65MH/4 =16.25MHz, to obtain the right timing.
Am I right or am I missing something here?

On page 63 of PG299(v2.1) Desember 2, 2019:

'vid_clk: This is the primary user interface clock. It is based on the DisplayPort Standard, the
video clock can be derived from the link clock using mvid and nvid. In addition, vid_clk
should be greater than to [(Vtotal x Htotal x frames per second)/pixels per clock]'

Is the vid_clk description not intended for Native mode configuration since it states that vid_clk should be greater than 'format pix_clk'/ppc ?

Thanks

0 Kudos
florentw
Moderator
Moderator
786 Views
Registered: ‎11-09-2015

Hi @jtx 


@jtx wrote:

So the data_valid shall be conitinious over the horisontal resolution (line) of 1024pix/4ppc=256 clocks in 'XGA mode'?

[Florent] -Yes this is correct.


Based on this the vid_clk must be exact the pix clock frequency described in XGA VESA format 65MH/4 =16.25MHz, to obtain the right timing.
Am I right or am I missing something here?

[Florent] -Yes you are right

On page 63 of PG299(v2.1) Desember 2, 2019:

'vid_clk: This is the primary user interface clock. It is based on the DisplayPort Standard, the
video clock can be derived from the link clock using mvid and nvid. In addition, vid_clk
should be greater than to [(Vtotal x Htotal x frames per second)/pixels per clock]'

Is the vid_clk description not intended for Native mode configuration since it states that vid_clk should be greater than 'format pix_clk'/ppc ?

[Florent] - It should be greater or equal to [(Vtotal x Htotal x frames per second)/pixels per clock]. Small wording missing in the doc

Thanks


 


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
jtx
Visitor
Visitor
773 Views
Registered: ‎12-03-2019

Hi @florentw

@jtx wrote:

So the data_valid shall be conitinious over the horisontal resolution (line) of 1024pix/4ppc=256 clocks in 'XGA mode'?

[Florent] -Yes this is correct.


Based on this the vid_clk must be exact the pix clock frequency described in XGA VESA format 65MH/4 =16.25MHz, to obtain the right timing.
Am I right or am I missing something here?

[Florent] -Yes you are right

On page 63 of PG299(v2.1) Desember 2, 2019:

'vid_clk: This is the primary user interface clock. It is based on the DisplayPort Standard, the
video clock can be derived from the link clock using mvid and nvid. In addition, vid_clk
should be greater than to [(Vtotal x Htotal x frames per second)/pixels per clock]'

Is the vid_clk description not intended for Native mode configuration since it states that vid_clk should be greater than 'format pix_clk'/ppc ?

[Florent] - It should be greater or equal to [(Vtotal x Htotal x frames per second)/pixels per clock]. Small wording missing in the doc

[JTX] - If the vid_clk shall be be exact, how can it be greater? Should it only be equal in the statement above?

 

Thanks

Thanks

0 Kudos
florentw
Moderator
Moderator
767 Views
Registered: ‎11-09-2015

Hi @jtx 

vid_clk can be equal OR greater than [(Vtotal x Htotal x frames per second)/pixels per clock].

But if it is greater, then you need to manage the stream to make sure the data enable does not toggle durring horizontal period as mentioned earlier.

If you want to feed a true video signal (without toggling data enable during active period) then you need to have the exact pixel clock/ppc


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
florentw
Moderator
Moderator
694 Views
Registered: ‎11-09-2015

Hi @jtx 

Do you have any update on this? Was my reply clear enough for you?

Thanks and Regards


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
jtx
Visitor
Visitor
612 Views
Registered: ‎12-03-2019

Hi,

it seems that lower resolutions are presented correctly on the monitor when the fast clock is not higher than about 5% than the expected video clock frequency (still toggeling data enable within the line to achieve the right timing).

Thanks

samk
Moderator
Moderator
544 Views
Registered: ‎10-04-2017

Hi @jtx,

 

It looks like you were able to find a solution. Do you mind selecting the best response from the thread as a solution so that if someone else has the same issue it is easier to find and also to close the thread for the community?

 

Thank you,

Sam

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos