DVI clock generation

Hi!

I am starting a DVI Board design. The purpose is to generate DVI data in an FPGA. interface it to an DVI transmitter from silicon image. There are quite a lot of data formats to support with dvi. a list is shown below. my question is ho to generate this pixel clocks, ranging from 52MHz to 165MHz. Can anyone give a hint?

we are using a V5LXT with integrated PLL features.

regards hans

formatver hor FrRatePclk[MHz] Drate [Mbps] WUXGA 1920 1200 85 281,25 6750 WUXGA 1920 1200 75 245,25 5886 WUXGA 1920 1200 60 193,25 4638 WUXGA 1920 1200 50 158,25 3798 UXGA 1600 1200 85 235 5640 UXGA 1600 1200 75 204,75 4914 UXGA 1600 1200 60 161 3864 UXGA 1600 1200 50 131,5 3156 SXGA 1280 1024 85 159,5 3828 SXGA 1280 1024 75 138,75 3330 SXGA 1280 1024 60 109 2616 SXGA 1280 1024 50 88,5 2124 XGA 1024 768 85 94,5 2268 XGA 1024 768 75 82 1968 XGA 1024 768 60 63,5 1524 XGA 1024 768 50 52 1248

Reply to
hansman
Loading thread data ...

Is your intent to generate the frequencies inside the FPGA? If this is the case, you might find that you need to update the bitstream to change the DCM loop multiply and divide constants. This was at least true in Virtex 2 / Spartan 3. There are many options for frequency generation off-chip. Look at Cypress offerings (e.g. CY22392 but beware of jitter), and ICS (too many to list here). Some PLL chips allow you to route the feedback externally, allowing at least partial control of the frequency directly in the FPGA. Others have simple 2 or 3 wire interfaces to update internal registers. Most of these chips can take the reference directly from an inexpensive crystal, or you can drive them with an existing clock frequency.

HTH, Gabor

Reply to
Gabor

With a PLL - generate a line-clock and configure the PLL to multiply this up to the number of pixels (including sync widths) that you need for your chosen resolution.

I guess that's a DCM rather than an analogue PLL. In which case the jitter on the multiplied signal is likely to be too high for the DVI chip to tolerate (as that has another PLL in it which multiplies up the pixel clock to multiplex the data bits down the DVI wires).

Or does V-5 now have low enough jitter PLLs for this to work?

When I did it, I used an external ICS1523 PLL, with a lineclock from the FPGA, to feed pixel clock back to the FPGA and to the DVI chip (a TI TFP410).

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
 Click to see the full signature
Reply to
Martin Thompson

Nope, Virtex5 does indeed have analogue PLLs, half as many as DCMs. The FAE told us this was because of the increasing popularity of spread spectrum clocks (like in PCs), and the only way to handle those is a PLL, so Xilinx saw a demand there.

Can't comment on how good they are (jitter-wise and such), Xilinx has not yet graced us with Virtex5-parts :)

--
The FROM:-address in this posting is valid until the end of
the month only, after that every e-mail sent to this address
 Click to see the full signature
Reply to
Sean Durkin

Hi Sean, That must be why Xilinx don't support the spread spectrum feature the DCMs have/used to have? Sounds like your FAE is bluffing!

formatting link

Cheers, Syms.

Reply to
Symon

Well, he was talking about spread spectrum clocks as INPUT clocks to the FPGA, not as outputs of a DCM. Supposedly (I've never had the pleasure of dealing with spread spectrum clocks) DCMs can't handle that and won't lock, at least in some cases. But now with PCI-E and SATA and everything going serial and spread-spectrummy this is something people want.

But he was still bluffing in a lot of ways when he presented the new architecture. Like availability and prices. :)

cu, Sean

--
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...
Reply to
Sean Durkin

All,

Yes, DCM's have a fixed 300 ps cycle to cycle jitter max in high frequency mode (1000 ps cycle to cycle in low frequency mode) limit for clock input jitter (not to exceed to lock).

The PLL in V5 has no such restriction. The characterization of this PLL is now done, and in review, and, it looks like a PLL! Basically, the jitter input tolerance is very large (spread spectrum is no issue), and the output jitter is very small. Details after the review of the report.

Generating spread spectrum is another matter. Spartan 3, and 3E have an application for their DCM which will create a very nice spread spectrum clock which is well within the DVI specifications (useful for commercial folks who don't want to put their systems inside fully shielded metal enclosures!). This uses some features of the DCM in 3, 3E that are not present in V4, nor even in V5. It remains to be seen if V4 or V5 could play any of the same tricks as 3, 3E, and create a useful spread spectrum clock, but we have had no customer interest in Virtex-Land.

Locking to a spread spectrum referenced clocked data stream is a requirement for the V5 MGTs (ie SATA), and yes, they do comply.

As well the V5 MGT has the OOB signalling required by standards like PCIe (along with the PCIe MAC in hard logic).

There seems to be a widening divergence in the needs and wants of the "high-end" FPGA customer vs. the "high volume" FPGA customer. The product lines are evolving to reflect those differences.

Austin

Reply to
Austin Lesea

PLL with what reference? What's the max. jitter allowance? First of all you need a crystal or an oscillator then try to multipply/divide it to a desired freq. If you want the pixel clock to be line-locked to some sources then you need something likes ICS1523 otherwise forget about it. IMHO something like a programmable oscillator would be suitable in your app.

regards,

hansman wrote:

Reply to
Marlboro

Hi Guys, What spread spectrum clock violates that spec.?

Certainly not SATA.

Quote from t'internet:- Serial ATA allows the use of spread spectrum clocking (SSC), or intentional low frequency modulation of the transmitter clock. The purpose of this modulation is to spread the spectral energy to mitigate the unintentional interference of radio frequency. The modulation frequency of SSC shall be in the range of 30 KHz to 33 KHz.

SATA talks about SSC with a bandwidth of maybe 2000ppm, you're not gonna get

300ps jumps with modulation of DCM compatible clocks at c.30kHz.

I guess the main reason for having these PLLs in V5 is their jitter attenuation properties. Maybe it's hard for the FAE to say that because for years he's been slagging off A's PLLs. ;-) Of course, there's no reason why a design DCM can't attenuate jitter, but only down to the limit imposed by the minimum delay change.

Finally, I wonder if spread spectrum clocking in this context is a complete con merely to get around the CE / FCC regulations. The amount of energy radiated is just the same, and it's arguable that spreading the spectrum makes it more likely to interfere with something than not spreading. The regulations should impose limits for power radited over a bigger bandwidth to prevent interference. Using a regulatory 120kHz band is not a good idea if you're trying to prevent interference with a 6 MHz TV signal.

formatting link
"The usefulness of spread spectrum clocking as a method of actually reducing interference is often debated" ... oh dear, that sounds ominous. Let's end this thread now! :-) Cheers, Syms. p.s. Sean, thanks for explaining what your FAE was talking about!

Reply to
Symon

Symon,

First, you are correct that the power is spread over a wider frequency band by 'spread spectrum', and is in no way reduced (the same power, either way). It that sense, it is a sham, as the noise floor just rises. Or, if you have a wideband channel, the spread spectrum is just a real pain, as it is all there, audible (or visible), interfering. Most of the spread spectrum clock generators use a triangular wideband FM modulation, so they are really very annoying if your receiver is wide enough to hear it (it just howls). "True" ss would be a psuedo noise signal, which is less annoying, but still interference! These ss clock generatorss do "fool" the FCC and CE test setups into believing they are "not there." As far as a police or fire radio is concerned, they are not 'there', and will not interfere.

Second, Xilinx was always careful to note that specific implementations of PLLs might not deliver all the benefits that should be there, due to limitations with sharing common ground, and power, adjacent circuit interference, etc. Not that we are able to be immune from everything, but at least by studying the competition, and knowing the weaknesses, we could set the goal to exceed their performance (which we did).

Third, the "normal" spread spectrum is unable to cause a DCM to lose lock, or prevent it from locking (as you so rightly point out). We just did not want to have to characterize a dozen or so spread spectrum clock generators and our DCM to PROVE it. Since the 300 ps spec applies to the clock edges that are critical (which are 6 clocks apart in V2, V2P, and 36 clocks apart in V4, V5), it is tough to be absolutely sure that in 36 clock, 300 ps will never accrue. Are you sure? If so, then use our DCM with your spread spectrum clock.

Austin

PS:

Drove by a hybrid electric vehicle yesterday, and it completely wiped out a low power distant FM radio station (went from full quieting stereo music to loud hash and buzzing!). Cars do not have to meet FCC or CE rules. A real sham. (and a shame)

Reply to
Austin Lesea

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.