[Open-graphics] How we compute video clocks

[Michael Meeuwisse]

On 4 Mar 2008, at 23:32, Timothy Normand Miller wrote:

> First, don't bother with sanity checks in the hardware.  It's the
> software driver developer's responsibility to put in the appropriate
> checks or indeed never generate bad numbers in the first place. There
> are rare occasions, where a bad value could physically fry something,
> where you might want to put in a check, but I don't think that's the
> case here.

I wasn't sure about the input to the DCM, and what it's output would  
be if the input is too fast. Got rid of the checks, but don't know  
how it'll behave after a reset. Essentially the DCM input will be 133  
MHz at that point.

> Also, your pre-divider looks like it's going to divide by 2N, not N.

Correct. If the divider is 4, one output clock cycle will take 8  
input clock cycles. I figured this wasn't a big issue since if we  
want 96, we can easily set the divider to 48. This completely avoids  
the issue of how to deal with halves, etc.

> For N=1, you just want to mux in the clock.  For N=2, you toggle a
> register _every_ cycle.  For even numbers, it's easy.  For odd
> numbers, you alternate counting floor(N/2) and ceil(N/2).  So, for
> N=2, the counts are 1, 1, 1, 1....  For N=3, the counts are 1, 2, 1,
> 2, 1, 2...  Actually, you probably want to subtract 1 from all of the
> numbers I just gave, but you get the idea.  Also, there are other
> optimizations we can make, but we'll start here.

Not an issue if we divide by 2N, right?

> You probably have a similar bug with your divide-by-2-to-the-M post- 
> divider.

I don't think so. If I want to divide by 1, I keep on setting the  
countdown to zero, thus essentially toggle the output every clock.  
Divide by 4 sets the countdown to 2, etc. I did make a typo there,  
the cases should be 1, 2, 4, 8, 16, 32, not 1 - 6.

> For the DCM feedback, we don't care about the phase of this clock
> relative to anything else, but we do need a feedback.  I think you can
> just wire CLK0 directly to CLKFB.

I'll find some docs about what this feedback is all about. But a wire  
connecting CLK0 to CLKFB will do the trick?

>>  So anyway, I figure we don't have this implemented yet, and it's  
>> time
>>  I get laughed at* for trying to write something in Verilog. See
>>  attached. *Any* comments are most welcome, I'm not even sure if I  
>> get
>>  the concept of wires completely yet. ;)
>
> Ask questions.  We'll answer.  :)

Ok, this one I wasn't sure about:
	valid_divisor[1] <= divisor1 > 0 && divisor1 < 7;
Is this syntactically correct? As in, if divisor is > 0 and < 7, will  
valid_divisor[0] end up being 1?
	valid_divisor[0] <= divisor0_reg > (sel_base? 22: 18);
And following the previous one, will it still work if there's a  
conditional squeezed in there?

Also, I'm not passing lots of signals I'm using as clocks through a  
BUFG or anything. Should I? Say, divisor0_out for example.

Lastly I'm not sure if my naming convention is understandable. I  
personally don't really like the _reg bits. It just looks wrong :)

Cheers,

Michael
www.projectvga.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vid_clock.v
Type: application/octet-stream
Size: 6869 bytes
Desc: not available
Url : http://lists.duskglow.com/open-graphics/attachments/20080305/df6b3b80/vid_clock-0001.obj
-------------- next part --------------