[Open-graphics] Dot clocks on OGD1

[Stephen Warren]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

howard parkin wrote:
> 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).

So, "freq" is divided by both 2 and 4 at once, so the /4 is used for the
logic, and the /2 is optionally available for the final output stage?

In other words, "freq" is the pixel clock, irrespective of single- v.s.
double-wide outputs.

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

Is this scheme based on the DCM configurations mentioned here:

http://www.xilinx.com/products/boards/s3estarter/files/s3esk_frequency_generator.pdf

http://www.xilinx.com/products/boards/s3estarter/files/s3esk_frequency_generator.zip

There are some notes either in that PDF, or in the accompanying code,
that indicate that this special undocumented DCM/DLL mode, whilst it
does great things for cleaning up jitter, has the side-effect of some
slight frequency wander.

I also saw a comp.arch.fpga post (that I can't find right now) that
hinted that a Xilinx FAE had been attempting to get this feature
documented, but gave up after the wander was found.

Is there other Xilinx documentation available that discusses this
DCM/DLL mode? Does it characterize how much wander one gets in practice?

Anywa, the reason I ask is that at least some video standard specs
include max tolerances for things like pixel clocks, of the order of
+/-0.5%. If there's significant wander in the DCM, and/or any basic
frequency inaccuracy due to limitations in resolution when generating
the clock, there could be some spec compliance issues.

I was previously worried about the ability to hit that % error rate,
(with the 32 multiplier) based solely on the synthesizer accuracy, even
ignoring any DCM/DLL frequency wander. However, with the 128 multiplier,
things look OK even at the max frequency of single-link DVI.

The largest pixel clocks around the 165MHz single-link DVI limit are:

Clock Hz        Delta to        Max error[1]
                next higher
165888000.00		
165517241.38	370758.62	0.11
164517024.79	1000216.59	0.3
164102564.10	414460.69	0.13

Max error relative to an arbitrary desired clock (worst case at 1/2 way
between the 2 clocks), expressed as a % fraction of the mid-point clock.

So, that looks OK now.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGacBPhk3bo0lNTrURAuf/AJ0Ubb3DGciKk/ov0joSHlzfXkwdhwCfeSl5
HT12SP+vJtHffDKNtJgLHzE=
=6GRc
-----END PGP SIGNATURE-----