[Open-graphics] How we compute video clocks

[Timothy Normand Miller]

On 3/4/08, Michael Meeuwisse <mickeymeeuw at gmail.com> wrote:
>
>  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?

I think you will want to have the odd numbers for more precise control
over the frequencies you get.  Also, don't worry that the duty cycle
isn't 50/50.  The DCM will fix that.

>
>
>  > 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.

You TOGGLE it every clock, which divides by 2.

>  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?

Yup.

>
>
>  >>  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[1] end up being 1?

Yes.

BTW, only clock on clocks.  Then use 'if' to decide whether or not to assign.

>         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?

Yup.

>  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.

The final clock output should go through a BUFG.

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

I tend to use Hungarian-like notation only on module ports so that you
can tell the direction from an instance (with pass by name) what the
directions are.

-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project