Another point regarding the latency of the dynamic phase shifting - the
data sheet states:

"The phase adjustment may require as many as 100 CLKIN cycles plus
three PSCLK cycles to take effect, at which point the output PSDONE
goes High for one PSCLK cycle."

In reality, what does "may require" mean?

Is there anything that can be done (eg. through CLKIN or PSCLK
frequency selection say) to reduce this 100 CLKIN cycles?

Does this "100 CLKIN cycles" vary between devices, with Vcc, temp?

I would like to avoid experiments with actual devices during my design
phase.

PeterC wrote:
> Thank you Brian - pointers to answer records and the past thread
> greatly appreciated.

 Sure;  I can't find my folder of DCM simulation notes right now, but
searching the Xilinx Answer Records for "DCM" or "DCM simulation"
will turn up a boatload of the DCM simulation quirks; I've listed some
more of them below.

 You may also want to try running a post-PAR timing simulation to see
what the DCM delay looks like with the back-annotated delays.

11067   SimPrim - ModelSim Simulations: Input and Output clocks
        of the DCM and CLKDLL models do not appear to be de-skewed

13213   UniSim, SimPrim, Simulation - How do I simulate the DCM
        without connecting the CLK Feedback (CLKFB) port? (VHDL)

11344   UniSim - Variables passed to GENERICs in functional simulation
        are not working properly (VHDL)

18390   7.1i Timing Analyzer/TRACE - Changing the DESKEW_ADJUST
        parameter does not affect the DCM value (Tdcmino)

20845   6.3i UniSim, Simulation- There is a Delta-cycle difference
        between clk0 and clk2x in the DCM model

22064   7.1i UniSim, Simulation - There is a Delta-cycle difference
        between CLK0 and CLKDV in the DCM model

6362    UniSim, SimPrim, Simulation - When I simulate a DCM or CLKDLL,
        the LOCKED signal does not activate unless simulation is run in
        ps time resolution

18115   8.1i/7.1i Simulation - DCM outputs are "0" and the DCM does not
        lock UniSim and SimPrim VHDL models) (DCM reset requirement)

19005   Virtex-II/Virtex-II Pro, Clocking Wizard - The LOCKED signal
        doed noy go high for cascaded DCM when CLKDV is used

have fun,
Brian

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

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

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.

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

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

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

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?