How does the DCM phase shifting circuitry work? Xilinx Spartan 3

The DCM is covered well in the data sheets.

The Spartan3 DC & Switching data sheet specifies a tap resolution of 30 to

The variable phase shift is different between Spartan3 and Spartan3E. Since you're using Spartan3, the "older" style of variable phase shift is used: each PSINCDEC event is 1/256 of the CLKIN, not 1 tap delay. The Spartan3 Functional data sheet has 3 paragraphs on Variable Phase Shift mode that talks about the 1/256 increment. What might not be clear is that there is a period after the PSINCDEC event before the next event can be applied, providing a fundamental limit to the speed of phase adjustment the system can attain. Those details are also mentioned in the same paragraphs.

Each PSINCDEC event *might not* result in a tap change since ~40 ps corresponds to 10 ns. Faster than ~100 MHz will have more than one event per tap change on average. Slower than ~100 MHz (the DCM is good to 25 MHz) you get more than one tap changed per event on average. The transition point is dependent on the actual tap delay.

Happy reading!

Peter A. can probably help. It sounds like you are looking for a simple controlled delay line, with predictable behaviour ?

The DCM is a lot more than that: when you see signals like 'locked' and PSDONE, and mention of negative delays, then there is more 'under the hood' than a simple delay line.

Thus you are likely to see jitter, but ISTR Peter A. has mentioned there are ways to 'dumb down' the DCM, to a simpler subset, but more predictable operation.

ie your challenge is likely to be (somehow) turning off the features you do not need :)

-jg

Craig,

The delay line has many taps, but the phase shifter has only 256 possible settings (from 0/256 to 255/256 of one period).

So, if you increment, or decrement, you will phase shift by 1/256 of a period, or by nothing at all (if 1/256 of a period is less than one tap of the physical delay line).

Take a "simple" case of 39.063 MHz (25.6 ns period):

Each increment or decrement will phase shift by 100 ps (or the nearest tap granularity to the desired phase).

Aust> Essentially I need to know, for any given DCM configuration, how much

Thanks for the responses. That clears things up quite a bit. One followup question, is the ratio of tap increment/decrement to the CLKIN frequency fixed at DCM creation, or is it dynamic? If during normal operation I increase CLKIN from 39.063MHz to 51.723MHz will the ratio remain the same? Or will I see a proportionally larger phase shift with the faster clock?

- Craig

For Spartan-3 FPGAs, the VARIABLE phase shift is _always_ a fraction (1/256th) of the input clock period--the equivalent of about 1.4 degrees or pi/128 radians. In Spartan-3 FPGAs, the DCM logic converts this value to the appropriate number of tap delays, with each tap being between 30 to 60 ps.

Assume a 166.667 MHz clock, which has a 6 ns clock period. Each PSINCDEC increment/decrement step is 6/265 ns = ~23 ps, less than a tap delay. The DCM control logic will decide wether or not to actually shift when the shift value falls below the tap resolution.

Or, let's take your specific example.

If CLKIN is 39.063 MHz, then the clock period is ~26 ns. Each PSINCDEC value is 26/256 ns = ~102 ps.

If you changed the input clock to 51.723 MHz (please reset the DCM when changing input frequencies please), then the clock period shrinks to ~19.33 ns. Now each PSINCDEC value is 19.33/256 ns = ~75.5 ps. On Spartan-3, the size of the PSINCDEC value changes according to the input clock frequency. Spartan-3E FPGAs behave differently.

Did this sufficiently answer your question?

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs

--------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.

Perfect Steve thanks. Thanks everyone!

- Craig

Would it be correct to also add this ?

- Chooses the nearest physical [~40ns] tap, to the desired delay (N x

- Saturates at nom 10ns

Whilst we are on this subject, to this detail, can you give some info on how does Spartan 3E differ, and why ?

-jg

Craig,

Remains the same.

Aust> Thanks for the responses. That clears things up quite a bit. One

Jim,

Yes, nearest tap to actual value, and as for how Spartan stuff works, I have to defer to those engineers (as they did things differently).

Austin

Jim Granville wrote:

A somewhat related question: I have simulated (behavioural) a Spartan 3 DCM with the PHASE_SHIFT parameter initialized to zero. I am using the DCM in Variable phase shift mode. Input frequency is 100 MHz.

However, the behavioural simulation shows that once the core asserts LOCKED_OUT high, there is still a significant (approx. 3 ns) phase shift between the input clock and clk0_out.

Is this clk_in to clk0_out phase relationship shown in the behavioural simulation accurate?

(Apologies for tagging onto the end of this thread, I wanted to get an answer efficiently and a few of the DCM gurus are likely to still be looking at this thread.)

It's meant to make the phase of the feedback input (clkfb) the same as the clock input (clkin). If you have an external (to the DCM) delay between the clk0 output and the feedback input, you will see a phase shift between clkin and clk0.

Does this match your configuration?

Regards, Allan

Thanks Allan.

That makes sense. I did not have the clkfb input enabled as I am not trying to compensate for skew. I have just added it to the core, re-compiled and re-simulated and there is still the same phase shift between clkin and clk0 (=clkfb). Admittedly I do not reset the core (as is recommended following the inclusion of clkfb).

Must I reset the core?

Obviously I am still missing something or there is a discrepancy between the behavioural model of the DCM and its real operation - but I very much doubt that this is the case given the maturity of the S3 device.

Any other hints?

Allan Herriman replied:

One caution: the default DCM configuration inserts an intentional delay in the DCM feedback path, making the clkfb LEAD the input clock by about 1.5 ns in the V2 family (not sure about S3 numbers).

This is done to insure zero hold at IOB inputs in the default SYSTEM_SYNCHRONOUS mode.

This also used to cause 'clock creep' in cascaded DCM's, but the latest S/W might set the DCM to SOURCE_SYNCHRONOUS if it sees a cascade.

The V2 delay element is described nicely in XAPP259 v1.0 (pp 4-5); however, the equivalent documention for S3, XAPP462 v1.1 (pp 32-34), is horribly confused by the notion that delaying feedback makes the output clock happen earlier.

See also Answer Records 15350 and 13024

Simulation modeling of DCM delays over the years has been, er, quirky.

For past threads, google comp.arch.fpga for "DCM SOURCE_SYNCHRONOUS"

Brian

The only difference is in the DLL phase shifter feature included with the DCM. Most everything else is identical between Spartan-3 and Spartan-3E DCMs.

There's a summary of the differences in the following Answer Record, but I'll follow up here with the abbreviated version.

In FIXED phase shift mode, the difference depends on which version ISE that you are using, as described in the data sheet and the Answer Record. Physically, the Spartan-3 DLL performs a fixed phase shift by as much as a full clock cycle forward or backward. The Spartan-3E DLL performs a fixed phase shift by as much as _half_ a clock cycle forward or backward. For nearly all applications, the Spartan-3E half-clock shift provides the same flexibility as the full clock shift, but with significantly less silicon.

In VARIABLE phase shift mode, the difference is that the Spartan-3 DLL performs a variable phase shift in fractions of a clock period, 1/256th of a full circle. Think degrees, angles, radians, using your favorite angular unit. Extra logic within the Spartan-3 DLL calculates the delay line change. The Spartan-3E DLL also performs a variable phase shift using a delay line. However, in Spartan-3E, you have raw control over the delay. The shift is always in time, not in some angular unit.

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs

--------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.

Thanks, When you say time for 3E, do you mean 'calibrated time', or some multiple of a ~30-60ps delay chain ? I can see that the extra logic in the -3, (should?) track temp/Vcc changes - or does it grab the multiplier only when the DCM is reset ?

How does the -3E manage temp/vcc/process variations, or does the user do that ?

-jg

Jim,

The tap state machine is always trying to keep one entire period in one of the delay lines. This way, the unit is always self calibrating, it always "knows" how many taps equals one period.

So when you ask for 23/256 of a period shift, the arithmetic unit solves for the closet tap (truncating).

To make the silicon take up less space, the delay line itself is optimized to not change over the PVT (as much as it would otherwise).

How this is done is the subject of issued patents, so for those that are curious, they can look these up.

Aust> Steve Knapp (Xil>

Yes, I can follow that for the -3, but Steve was suggesting the 3E was slightly different, so I was wanting to clarify the deails.

-jg

Thank you Brian - pointers to answer records and the past thread greatly appreciated.

Jim,

I do not think it is any different in this regard, but Steve will correct me if I am wrong,

Aust> Aust>