06-07-2013 03:40 AM
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 :
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
pclk_M <= 8'd2 - 8'd1;
pclk_D <= 8'd4 - 8'd1;
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!!
06-07-2013 07:57 AM
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.
06-07-2013 08:24 AM
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 )
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
06-07-2013 08:32 AM
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.