clarification: clock doubling in Spartan 3

May 23, 2007 7 Replies

Rate this thread:

John Larkin 19 years ago

If we design an S3-based system using an internal clock doubler, the design software wants to know our input frequency. In our case, we want to double the incoming 20 MHz clock to 40 MHz for internal use.

In other applications, the incoming clock may range from, say, 18 to

25 MHz, and we'd like to use the same FPGA design without recompiling. Looking at the Xapps and datasheets, it's implied that the clock doubler will double an incoming clock over the specified range (18 to
167 MHz in) without otherwise being "told" the nominal input frequency. Is that right?

Thanks,

John

Vote

John Larkin 19 years ago

And I guess there are two parts to the question: how do the DFS and the DLL blocks operate in this regard? If we use the DFS, we can go below 18 MHz as the input, which would be nice.

John

Vote

austin 19 years ago

John,

18 MHz is the lower limit for the Spartan 3 DLL, and the Spartan 3 DFS could go even lower than 18 MHz -- down to 9 MHz (to multiply and provide a clock out that is 2X the clock in).

25 MHz is well below the low frequency mode of the DLL/DCM, so one bitstream fits all (one setting will lock for any input in the range of

18 to 25 MHz).

If the frequency changes while it is running, you may have to reset the DCM for it to lock. The DCM tracks up to a point, but delay line overflow or underflow may happen which then requires a reset to restart.

Aust> >

Vote

John_H 19 years ago

The "one bitstream for two frequencies" might be confusing because of the frequency setting on the DCM itself (the primitive's parameter). The mention that the value is used "to optimize jitter" never was very clear to me.

I'd suggest that for a DCM with zero phase offset, compiling with the highest frequency value as the specification for the UCF will keep the system running at a fixed frequency across that entire range. For a DCM with fixed phase offset, however, I'd suggest due-diligence to make sure that neither the setup nor the hold times on the various paths are compromised. Except for this rare situation, it appears the DFS-only mode should support everything nicely.

- John_H

Vote

austin 19 years ago

John,

The input frequency is used only for estimating jitter, and to help calculate any timing period numbers. It is also used to set low or high frequency mode, if not set explicitly.

It does not affect the bitstream.

Aust> The "one bitstream for two frequencies" might be confusing because of the

Vote

austin 19 years ago

Lastly,

The DFS can not be sync'd to the DLL when the input clock is too low for the DLL (below 18 MHz in this case).

If phase synchronization is required, then the range starts at 18 MHz.

If phase synchronization is not required, then do not use the CLK0, 90,

180, 270, 2X, 2x_b, DV outputs, and only use the CLKFX, CLKFX-B outputs.

Leave the CLKFB input not connected.

This instantiates ONLY the DFS element.

Now it works from 9 MHz up, and the CLKFX outputs are 2X the input.

There is no guaranteed phase relationship from the CLKIN to the DFS to the CLKFX outputs in the DFS only mode.

Aust> John,

Vote

John Larkin 19 years ago

Thanks. We just need a clock, with no phase requirements, so we'll do as you suggest. The CPU clock might run from 16 to maybe 25 MHz, so this will work nicely.

John

Vote

PeteS 19 years ago

In which case, what is the rate frequency that breaks the lock? Is it related to the system clock or not?

Cheers

PeteS

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required