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

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.)

On 4 Apr 2006 21:02:31 -0700, "PeterC" <peter@geckoaudio.com> 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?

PeterC wrote:
>
>Is this clk_in to clk0_out phase relationship shown in the behavioural
>simulation accurate?
>

Allan Herriman replied:
>
> It's meant to make the phase of the feedback input (clkfb) the same as
> the clock input (clkin)
>

 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

Jim Granville wrote:
> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:

[ ... snip ...]

> >Spartan-3E FPGAs behave differently.
>
> Whilst we are on this subject, to this detail,
> can you give some info on how does Spartan 3E differ, and why ?
>
> -jg

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.
http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=23004

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
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.

Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:

> Jim Granville wrote:
> 
>>Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
> 
> 
> [ ... snip ...]
> 
> 
>>>Spartan-3E FPGAs behave differently.
>>
>>Whilst we are on this subject, to this detail,
>>can you give some info on how does Spartan 3E differ, and why ?
>>
>>-jg
> 
> 
> 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.
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=23004
> 
> 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.

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.

Austin

Jim Granville wrote:

> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
> 
>> Jim Granville wrote:
>>
>>> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
>>
>>
>>
>> [ ... snip ...]
>>
>>
>>>> Spartan-3E FPGAs behave differently.
>>>
>>>
>>> Whilst we are on this subject, to this detail,
>>> can you give some info on how does Spartan 3E differ, and why ?
>>>
>>> -jg
>>
>>
>>
>> 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.
>> http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=23004
>>
>> 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.
> 
> 
> 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
> 
> 

Austin Lesea wrote:
> 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.

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



>>>> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
>>> 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.

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,

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> 
>> 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.
> 
> 
> 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
> 
> 
> 
>>>>> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:
>>>>
>>>> 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.
> 
>