FPGA Central

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

hansman wrote:
> 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

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

"hansman" <[email protected]> writes:

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

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.

> we are using a V5LXT with integrated PLL features.
>

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

--
[email protected]
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Martin Thompson wrote:
>> we are using a V5LXT with integrated PLL features.
> I guess that's a DCM rather than an analogue PLL.
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
will bounce.

If you want to contact me after that, try figuring out what
the next valid address will be...

"Sean Durkin" <[email protected]> wrote in message
news:[email protected]...
>
> 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.
>
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!
http://toolbox.xilinx.com/docsan/xil...e/libs/dcm.pdf

Cheers, Syms.

Symon wrote:
> 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!
> http://toolbox.xilinx.com/docsan/xil...e/libs/dcm.pdf
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...

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

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

"Austin Lesea" <[email protected]> wrote in message
news:[email protected]...
> 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).
>
Hi Guys,
What spread spectrum clock violates that spec.?
>
> Locking to a spread spectrum referenced clocked data stream is a
> requirement for the V5 MGTs (ie SATA), and yes, they do comply.
>

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.
http://en.wikipedia.org/wiki/Spread_...nal_generation
"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!

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)