[Open-graphics] Dot clocks on OGD1

[howard parkin]

On 6/7/07, Stephen Warren <s-t-open-graphics at wwwdotorg.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Timothy Miller wrote:
> > Ok, here's what we're going to do.  We've been able to save some
> > money on the design of the board and manage to get most dotclocks
> > we'd want to get.  The board has two crystal oscillators on it.
> > One is at 150MHz.  The other is at 155.52MHz.  Each one goes into
> > an adjustable 8-bit counter divider that lets you divide by any
> > number from 1 to 256 (although some of the smaller numbers will
> > result in clock rates that are too high), then the output of that
> > goes into a clock manager that multiplies it by 32 (adjustable in
> > design but fixed for use).  The same logic is duplicated for each
> > head, so each has its own independent clock at any of the available
> > frequences.
> >
> > The formula for the dot clock is:
> >
> > freq = 150*32/N or 155.52*32/N
> >
> > The actual clock frequency is 1/4 or 1/2 of this, because we
> > process multiple pixels in parallel.
>
> I'm slightly confused about this; is the "freq" result in the formula
> above the physical clock that's clocking the logic, or is it the pixel
> clock? The description of how "freq" is generated indicates that it's
> the physical logic clock.
>
> In which case, if multiple pixels are processed in parallel, isn't the
> logical pixel clock 4x or 2x this, not 1/4 or 1/2 this?

The "freq" number is the highest clock frequency we generate.
It is divided by 2 or 4 and the divided clocks used to clock video
logic. Since we process 4 pixels at one time, the 1/4 clock
is used to clock most of the video logic. The pixel stream
is subsequently converted to 2 pixels at the 1/2 clock rate
or 1 pixel at the "freq" clock rate depending on whether
we're trying to generate single-link DVI (1 pixel wide),
dual link DVI (2 pixels wide) or analogue (1 pixel wide).

By the way, we've found a way to multiply by 128,
not 32, so we can get finer resolution.


>
> My immediate question: Doesn't the 8-bit counter introduce a huge amount
> of jitter into the clock signal?

No. If you start with a clock without any phase noise or jitter, then the
divided clock has no phase phase noise or jitter either.


>Can the Xilinx DCM actually clean up jitter?

There is a tweek that can modify the effective loop bandwidth
of the frequency synthesis part of a DCM, but you have to dig
deep into the Xilinx documentation to find it and it can only be
applied during bit stream generation.

By default, Xilinx sets the B/W of the frequency synthesizer fairly
high, so that the DCM locks quickly and there's not a lot of jitter
reduction. Not that we need it, because the input clock is directly
derived from a crystal oscillator.