Virtex-4FX DCM autoshutdown failure, any suggestions

Hi

if anyone has seen the same or has any ideas how to avoid the issue I
am faced please help - I am trying to get it solved myself (my deadline
is today 21:00 german time) but kinda stuck currently.

problem:

Virtex-4FX12
2 DCMs in series
DCM1 uses only FX output for PPC system clock (to get the clock into
DLL input range)
DCM2 generates 3X clock proc clock for PPC

it all works for 360 milliseconds after configuration. then the first
DCM will remove lock, output stop, everythings stops. the delay 360
milliseconds is not dependand on the first DCM clock ratio settings. if
PPC is held in reset then the DCMs still shut down after the same 360
milliseconds.

any ideas? what to check? I have Lecroy 2GS/s DSO on some signals and
power supply lines but not seeing anything at the time where the DCM
shut off.

thanks in advance for any suggestions,

Antti

Antti schrieb:

> Hi
>
> if anyone has seen the same or has any ideas how to avoid the issue I
> am faced please help - I am trying to get it solved myself (my deadline
> is today 21:00 german time) but kinda stuck currently.
>
> problem:
>
> Virtex-4FX12
> 2 DCMs in series
> DCM1 uses only FX output for PPC system clock (to get the clock into
> DLL input range)
> DCM2 generates 3X clock proc clock for PPC
>
> it all works for 360 milliseconds after configuration. then the first
> DCM will remove lock, output stop, everythings stops. the delay 360
> milliseconds is not dependand on the first DCM clock ratio settings. if
> PPC is held in reset then the DCMs still shut down after the same 360
> milliseconds.
>
> any ideas? what to check? I have Lecroy 2GS/s DSO on some signals and
> power supply lines but not seeing anything at the time where the DCM
> shut off.
>
> thanks in advance for any suggestions,
>
> Antti

thanks for all the fine suggestions, the issue has been fixed.

Antti

> thanks for all the fine suggestions, the issue has been fixed.
> 

Out of curiosity, What was the problem ?


   Sylvain

Antti,

We do not support the use of a DCM being supplied clock by CLKFX of
another DCM.  There are just too many variables where the jitter from
the first DCM will cause the second DCM to not be able to lock, or to
lose lock.

That said, your symptom does not match what I just described:  the first
DCM is losing lock.

That is usually because the input clock to the first DCM is not stable
when it initially locks, and then as the input clock stabilizes, the DCM
can not track it, and loses lock.

The LOCK pin can only go low if the delay line taps overflow or
underflow, which suggests that the frequency is changing while the
device was locking (or was out of range).

Try delaying the startup of the DCM, until the input clock is stable.

The other cause is too much jitter on the CLKIN of the DCM.  That you
can determine with your Lecroy.  Measure cycle to cycle jitter, if there
is any cycle to cycle greater than 1n for low frequency range, or 300 ps
for high frequency range, you will lose lock.

What is the M and D of the first DCM?  Larger values of M result in
larger jitter, and also have more trouble locking to a signal that is
wandering around.

Vccaux changes used to be a cause of concern, but in V4 we redesigned
the regulator that provides the voltages for the delay lines.  A sudden
change in Vccaux should not affect the lock of the DCM in V4 (as long as
that change is within the Vccaux specifications).

Lastly, if the first DCM is multiplying up the frequency to be within
the range of the second DCM, I am assuming its CLKIN input is less than
the min input frequency.  Thus the first DCM should not be using the
CLKFB pin.  If the CLKFB pin is connected, then the software will also
be trying to get the DLL part of the DCM to lock, and it will fail to do
so (with an input below its lock range).

Austin



Antti wrote:
> Hi
> 
> if anyone has seen the same or has any ideas how to avoid the issue I
> am faced please help - I am trying to get it solved myself (my deadline
> is today 21:00 german time) but kinda stuck currently.
> 
> problem:
> 
> Virtex-4FX12
> 2 DCMs in series
> DCM1 uses only FX output for PPC system clock (to get the clock into
> DLL input range)
> DCM2 generates 3X clock proc clock for PPC
> 
> it all works for 360 milliseconds after configuration. then the first
> DCM will remove lock, output stop, everythings stops. the delay 360
> milliseconds is not dependand on the first DCM clock ratio settings. if
> PPC is held in reset then the DCMs still shut down after the same 360
> milliseconds.
> 
> any ideas? what to check? I have Lecroy 2GS/s DSO on some signals and
> power supply lines but not seeing anything at the time where the DCM
> shut off.
> 
> thanks in advance for any suggestions,
> 
> Antti
> 

Austin Lesea schrieb:

> Antti,
>
[snip]

> the min input frequency.  Thus the first DCM should not be using the
> CLKFB pin.  If the CLKFB pin is connected, then the software will also
> be trying to get the DLL part of the DCM to lock, and it will fail to do
> so (with an input below its lock range).
>
> Austin

weird - the thing is that the DCM chaining works fine, in ISE
and in EDK sometimes, and the single DCM in DFS mode works
in EDK also always with CLKFB no connected.

but with an PPC design in EDK when the CLKFB is not connected
then I think the DCM_STANDBY macro jumps in and shuts down
the DCM, well Xilinx docs say the standby macro tracks idle state
longer 100ms, hm the 360 milliseconds sounds still plausible time
for the shutdown macro to activate

connecting the 12MHz input clock that *IS* defenetly clean
and stable to both CLKIN _and_ CLKFB fixed the issue.

surpsingly I have EDK microblaze systems with similarly chained DCMs
where CLKFB of first DCM is not connected that work.

BTW after reading xilinx AR=B4s I did not find a clear note that DCM
chaining from FX is not allowed, there was note that Arch wizard does
not support it yet, but not that it want work or can not be used.

Antti

Antti,

The chaining rule is there somewhere, and it should state that a CLKIN
is not allowed to be driven from a CLKFX of a previous DCM.

Also no more than two DCM shall be cascaded.

This an old restriction, since V2, and has not changed (as the jitter on
CLKFX has not changed).

I have heard about the DCM NBTI macro causing headaches before, and that
may be the problem.  I do not know how to disable it.  Maybe a quick
email to the hotline would point you to how to disable it.

It may be the 12 MHz is too slow and trips the macro "loss of clock"
circuit?

What value of M do you use to multiply the 12 MHz by?

Austin

Antti wrote:
> Austin Lesea schrieb:
> 
>> Antti,
>>
> [snip]
> 
>> the min input frequency.  Thus the first DCM should not be using the
>> CLKFB pin.  If the CLKFB pin is connected, then the software will also
>> be trying to get the DLL part of the DCM to lock, and it will fail to do
>> so (with an input below its lock range).
>>
>> Austin
> 
> weird - the thing is that the DCM chaining works fine, in ISE
> and in EDK sometimes, and the single DCM in DFS mode works
> in EDK also always with CLKFB no connected.
> 
> but with an PPC design in EDK when the CLKFB is not connected
> then I think the DCM_STANDBY macro jumps in and shuts down
> the DCM, well Xilinx docs say the standby macro tracks idle state
> longer 100ms, hm the 360 milliseconds sounds still plausible time
> for the shutdown macro to activate
> 
> connecting the 12MHz input clock that *IS* defenetly clean
> and stable to both CLKIN _and_ CLKFB fixed the issue.
> 
> surpsingly I have EDK microblaze systems with similarly chained DCMs
> where CLKFB of first DCM is not connected that work.
> 
> BTW after reading xilinx AR�s I did not find a clear note that DCM
> chaining from FX is not allowed, there was note that Arch wizard does
> not support it yet, but not that it want work or can not be used.
> 
> Antti
> 

Austin Lesea schrieb:

> Antti,
>
> The chaining rule is there somewhere, and it should state that a CLKIN
> is not allowed to be driven from a CLKFX of a previous DCM.
>
> Also no more than two DCM shall be cascaded.
>
> This an old restriction, since V2, and has not changed (as the jitter on
> CLKFX has not changed).
>
> I have heard about the DCM NBTI macro causing headaches before, and that
> may be the problem.  I do not know how to disable it.  Maybe a quick
> email to the hotline would point you to how to disable it.
>
> It may be the 12 MHz is too slow and trips the macro "loss of clock"
> circuit?
>
> What value of M do you use to multiply the 12 MHz by?
>
> Austin
>
> Antti wrote:
> > Austin Lesea schrieb:
> >
> >> Antti,
> >>
> > [snip]
> >
> >> the min input frequency.  Thus the first DCM should not be using the
> >> CLKFB pin.  If the CLKFB pin is connected, then the software will also
> >> be trying to get the DLL part of the DCM to lock, and it will fail to =
do
> >> so (with an input below its lock range).
> >>
> >> Austin
> >
> > weird - the thing is that the DCM chaining works fine, in ISE
> > and in EDK sometimes, and the single DCM in DFS mode works
> > in EDK also always with CLKFB no connected.
> >
> > but with an PPC design in EDK when the CLKFB is not connected
> > then I think the DCM_STANDBY macro jumps in and shuts down
> > the DCM, well Xilinx docs say the standby macro tracks idle state
> > longer 100ms, hm the 360 milliseconds sounds still plausible time
> > for the shutdown macro to activate
> >
> > connecting the 12MHz input clock that *IS* defenetly clean
> > and stable to both CLKIN _and_ CLKFB fixed the issue.
> >
> > surpsingly I have EDK microblaze systems with similarly chained DCMs
> > where CLKFB of first DCM is not connected that work.
> >
> > BTW after reading xilinx AR=B4s I did not find a clear note that DCM
> > chaining from FX is not allowed, there was note that Arch wizard does
> > not support it yet, but not that it want work or can not be used.
> >
> > Antti
> >

50, 72 and 100MHz out from first DCM all had the 360 milliseconds
shutdown. for the moment the connection of input clock to both CLKIN
AND CLKFB of the first DCM seems to fix the issue.

If there is another better workaround solution, well I will possible
open webcase or something, for tonight I got it working, what is needed
right now.

Antti

Antti wrote:
> Hi
> 
> if anyone has seen the same or has any ideas how to avoid the issue I
> am faced please help - I am trying to get it solved myself (my deadline
> is today 21:00 german time) but kinda stuck currently.
> 
> problem:
> 
> Virtex-4FX12
> 2 DCMs in series
> DCM1 uses only FX output for PPC system clock (to get the clock into
> DLL input range)
> DCM2 generates 3X clock proc clock for PPC
> 
> it all works for 360 milliseconds after configuration. then the first
> DCM will remove lock, output stop, everythings stops. the delay 360
> milliseconds is not dependand on the first DCM clock ratio settings. if
> PPC is held in reset then the DCMs still shut down after the same 360
> milliseconds.
> 
> any ideas? what to check? I have Lecroy 2GS/s DSO on some signals and
> power supply lines but not seeing anything at the time where the DCM
> shut off.
> 
> thanks in advance for any suggestions,
> 
> Antti
> 

Antti,

I don't think this is your problem since you said it is the first DCM 
losing lock, however check to make sure the jitter out of the first DCM 
is within the max jitter input specs for the second DCM.  In most cases, 
you violate the max jitter spec when trying to drive a second DCM with 
the clkfx output of the first.  Perhaps you can change it around so that 
the first is doing clkx2 and the second is doing the clkfx?  Otherwise, 
at least check the jitter for your M and D values to satisfy yourself 
that the jitter is not too much for the second DCM

Then again, I'm sure you already know all this ;-)

Second question: are you using the NBTI macro?  I don't know what 
changes Xilinx has made to it in the past 16 months.  The original 
version for the devices that don't have the DCM changes had race 
conditions that made it unreliable for higher clock input frequencies, 
at least on paper.  We had no end of problems getting it to react 
properly when starting a clock up after the FPGA had been programmed. 
There were several revisions to the circuit since then, but we have not 
looked at them here to see if the race problem was addressed or not.  We 
are leaving the NBTI circuit out for designs that have a crystal on the 
board now.

Antti wrote:

> Austin Lesea schrieb:
> 
> 
>>Antti,
>>
> 
> [snip]
> 
> 
>>the min input frequency.  Thus the first DCM should not be using the
>>CLKFB pin.  If the CLKFB pin is connected, then the software will also
>>be trying to get the DLL part of the DCM to lock, and it will fail to do
>>so (with an input below its lock range).
>>
>>Austin
> 
> 
> weird - the thing is that the DCM chaining works fine, in ISE
> and in EDK sometimes, and the single DCM in DFS mode works
> in EDK also always with CLKFB no connected.
> 
> but with an PPC design in EDK when the CLKFB is not connected
> then I think the DCM_STANDBY macro jumps in and shuts down
> the DCM, well Xilinx docs say the standby macro tracks idle state
> longer 100ms, hm the 360 milliseconds sounds still plausible time
> for the shutdown macro to activate
> 
> connecting the 12MHz input clock that *IS* defenetly clean
> and stable to both CLKIN _and_ CLKFB fixed the issue.
> 
> surpsingly I have EDK microblaze systems with similarly chained DCMs
> where CLKFB of first DCM is not connected that work.
> 
> BTW after reading xilinx AR�s I did not find a clear note that DCM
> chaining from FX is not allowed, there was note that Arch wizard does
> not support it yet, but not that it want work or can not be used.
> 
> Antti
> 

Antti,

see my note above.  You might try taking out the DCM_standby and replace 
them with a straight DCM to see if it clears up the problem.  If you are 
using 8.1, there is a envrionment variable to avoid the auto-insertion.

Antti,

Yes, it looks like the macro thinks the clock is no present.

I would open a webcase just so that someone is aware of this.

Austin

Antti wrote:
> Austin Lesea schrieb:
> 
>> Antti,
>>
>> The chaining rule is there somewhere, and it should state that a CLKIN
>> is not allowed to be driven from a CLKFX of a previous DCM.
>>
>> Also no more than two DCM shall be cascaded.
>>
>> This an old restriction, since V2, and has not changed (as the jitter on
>> CLKFX has not changed).
>>
>> I have heard about the DCM NBTI macro causing headaches before, and that
>> may be the problem.  I do not know how to disable it.  Maybe a quick
>> email to the hotline would point you to how to disable it.
>>
>> It may be the 12 MHz is too slow and trips the macro "loss of clock"
>> circuit?
>>
>> What value of M do you use to multiply the 12 MHz by?
>>
>> Austin
>>
>> Antti wrote:
>>> Austin Lesea schrieb:
>>>
>>>> Antti,
>>>>
>>> [snip]
>>>
>>>> the min input frequency.  Thus the first DCM should not be using the
>>>> CLKFB pin.  If the CLKFB pin is connected, then the software will also
>>>> be trying to get the DLL part of the DCM to lock, and it will fail to do
>>>> so (with an input below its lock range).
>>>>
>>>> Austin
>>> weird - the thing is that the DCM chaining works fine, in ISE
>>> and in EDK sometimes, and the single DCM in DFS mode works
>>> in EDK also always with CLKFB no connected.
>>>
>>> but with an PPC design in EDK when the CLKFB is not connected
>>> then I think the DCM_STANDBY macro jumps in and shuts down
>>> the DCM, well Xilinx docs say the standby macro tracks idle state
>>> longer 100ms, hm the 360 milliseconds sounds still plausible time
>>> for the shutdown macro to activate
>>>
>>> connecting the 12MHz input clock that *IS* defenetly clean
>>> and stable to both CLKIN _and_ CLKFB fixed the issue.
>>>
>>> surpsingly I have EDK microblaze systems with similarly chained DCMs
>>> where CLKFB of first DCM is not connected that work.
>>>
>>> BTW after reading xilinx AR�s I did not find a clear note that DCM
>>> chaining from FX is not allowed, there was note that Arch wizard does
>>> not support it yet, but not that it want work or can not be used.
>>>
>>> Antti
>>>
> 
> 50, 72 and 100MHz out from first DCM all had the 360 milliseconds
> shutdown. for the moment the connection of input clock to both CLKIN
> AND CLKFB of the first DCM seems to fix the issue.
> 
> If there is another better workaround solution, well I will possible
> open webcase or something, for tonight I got it working, what is needed
> right now.
> 
> Antti
>