-----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----- _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
