cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor
Visitor
5,692 Views
Registered: ‎06-07-2013

About HDMI , TMDS, XAPP495 and pixel clocks

Hi!!!

 

I am starting to learn how the xapp495 source code works, learning about clocks, etc (it is my first  "serious" verilog code).

 

I found something strange :

 

//640x480@60HZ
parameter HPIXELS_VGA = 11'd640; //Horizontal Live Pixels
parameter VLINES_VGA = 11'd480; //Vertical Live ines
parameter HSYNCPW_VGA = 11'd96; //HSYNC Pulse Width
parameter VSYNCPW_VGA = 11'd2; //VSYNC Pulse Width
parameter HFNPRCH_VGA = 11'd16; //Horizontal Front Portch
parameter VFNPRCH_VGA = 11'd11; //Vertical Front Portch
parameter HBKPRCH_VGA = 11'd48; //Horizontal Front Portch
parameter VBKPRCH_VGA = 11'd31; //Vertical Front Portch

 

so, i guess that the total pixel size is =

 

horizontal : 640 + 96 + 16 + 48 = 800

vertical = 480 + 2 + 11 + 31 = 524

 

so, the pixel clock should be = 800x524x60 = 25152000 hz or 25.152Mhz

 

but the code for the DCM generator (dynamic using SPI) :

 

SW_VGA: //25 MHz pixel clock
begin
pclk_M <= 8'd2 - 8'd1;
pclk_D <= 8'd4 - 8'd1;
end

 

from a 50Mhz clock input, multiply by 2, and divides by 4 = 25Mhz exact.

 

so, what about the difference between 25Mhz and 25.152Mhz? we were talking about pixels, so, we can not miss "a few", or the signal will be out of sync, right? or the vsync, hsync will correct that? (i guess 'sync' it is about that, but how?)

 

in this case, we will emit more pixels every second ,but in the case of the SW_SXGA, it is like 107.9Mhz, so, we are sending less pixels every second... i guess that at some point, i will lose something.

 

what am I missing?

 

Thank you!!! and by the way, I love this spartan6!!

 

Tags (4)
0 Kudos
3 Replies
Highlighted
Scholar
Scholar
5,679 Views
Registered: ‎09-16-2009

Re: About HDMI , TMDS, XAPP495 and pixel clocks

 

Your calculations look right (I didn't check it against any standard).  You're right about the discrepency.  So what happens to that delta between the two?  The only thing that can move - your refresh rate won't be exactly 60Hz.

 

Now, will your source/sync work at this non-standard refresh rate?  I don't know - it probably will.

 

For production designs, you've got to do extra work to insure that the clock rates are correct and meet appropriate video specs.  This can be accomplished multiple ways depending on your design requirements.

 

--Mark

0 Kudos
Highlighted
Visitor
Visitor
5,676 Views
Registered: ‎06-07-2013

Re: About HDMI , TMDS, XAPP495 and pixel clocks

oh, yes, the frame rate!! so,we miss a complete frame...

 

we could adjust more the DCM, but :

 

>>> from fractions import Fraction
>>> Fraction ( 25152000 , 50000000 )
Fraction(1572, 3125)

 

we need at least, 12bits for a precise clock, and the DCM spi interface only uses 8bits :/

 

but i guess that it is ok loosing some frames.. we could approx more the frame rate playings with the multiplier and divisor

0 Kudos
Highlighted
Scholar
Scholar
5,673 Views
Registered: ‎09-16-2009

Re: About HDMI , TMDS, XAPP495 and pixel clocks

There's usually two possibilities:

 

1.  You're not the "Master" timing reference.  Something else is.  You close a loop on some kind of PLL to lock your timing to that reference to achieve a precise frequency lock.

 

2.    You are the timing reference.  In this case change your oscillator to a more appropriate value in order to achieve the required frames rate.  As you've noticed a DCM doesn't give you this type of granularity.

 

Regards,

 

Mark

 

0 Kudos