Virtex-4FX DCM autoshutdown failure, any suggestions

Ray Andraka schrieb:

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

Hi Ray,

it defenetly is the NBTI macro issue. it seems only to popup in EDK
sometimes. So the same DCM that would otherwise work with same
connections and settings dosnt any more. Thanks for the jitter warning
I will sure theck those issues also if there is any trouble and when
doing
any new or re-designs.

Antti

Austin Lesea wrote:

> 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

 From answer record 21435:
Disabling Macro Insertion
If you can ensure that the clock source for any particular DCM will 
never stop, the extra logic insertion can be disabled using one of the 
following two methods:

- If none of the DCMs in your design require the clock stop circuitry 
(i.e., the DCM source clocks will never stop), you can globally disable 
the logic insertion by setting the XIL_DCM_AUTOCALIBRATION_OFF 
environment variable.

- You can also disable insertion on an individual basis by applying the 
DCM_AUTOCALIBRATION attribute to specific DCMs. Acceptable values are 
TRUE and FALSE, where TRUE (the default value) allows MAP to insert the 
clock stop circuitry, and FALSE disables the logic insertion. You can 
add this attribute to the HDL design source using the VHDL generic or 
Verilog defparam, or it can be entered as a synthesis attribute (check 
with your synthesis tool for the appropriate syntax).

When applying this attribute in the UCF file, the syntax is as follows:
INST DCM_INST DCM_AUTOCALIBRATION="FALSE";

Insertion of this circuit is not automatic for ISE7.1, only for 8.x, so 
if you are using 7.1 it isn't putting them in automatically.  Also, 
instantiate the straight DCM, not DCM_standby if that is what you are doing.

I haven't revisited the circuit used for the clock detect in the last 12 
months or so, but I do know the one in the first release was a 
demonstration on how not to design a circuit with multiple clocks.  We 
had no end of problems with trying to use it with a 125 MHz input clock.

Antti,

Just turn it off, you don't need it.

Also in another tech answer, they say the macro requires greater than
200 ms reset pulse!

From an tech answer (#21435):

- If none of the DCMs in your design require the clock stop circuitry
(i.e., the DCM source clocks will never stop), you can globally disable
the logic insertion by setting the XIL_DCM_AUTOCALIBRATION_OFF
environment variable.

- You can also disable insertion on an individual basis by applying the
DCM_AUTOCALIBRATION attribute to specific DCMs. Acceptable values are
TRUE and FALSE, where TRUE (the default value) allows MAP to insert the
clock stop circuitry, and FALSE disables the logic insertion. You can
add this attribute to the HDL design source using the VHDL generic or
Verilog defparam, or it can be entered as a synthesis attribute (check
with your synthesis tool for the appropriate syntax).

When applying this attribute in the UCF file, the syntax is as follows:
INST DCM_INST DCM_AUTOCALIBRATION="FALSE";

Austin


Antti wrote:
> Ray Andraka schrieb:
> 
>> 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.
> 
> Hi Ray,
> 
> it defenetly is the NBTI macro issue. it seems only to popup in EDK
> sometimes. So the same DCM that would otherwise work with same
> connections and settings dosnt any more. Thanks for the jitter warning
> I will sure theck those issues also if there is any trouble and when
> doing
> any new or re-designs.
> 
> Antti
> 

Austin Lesea schrieb:

> Antti,
>
> Just turn it off, you don't need it.
>
> Also in another tech answer, they say the macro requires greater than
> 200 ms reset pulse!
>
> From an tech answer (#21435):
>
> - If none of the DCMs in your design require the clock stop circuitry
> (i.e., the DCM source clocks will never stop), you can globally disable
> the logic insertion by setting the XIL_DCM_AUTOCALIBRATION_OFF
> environment variable.
>
> - You can also disable insertion on an individual basis by applying the
> DCM_AUTOCALIBRATION attribute to specific DCMs. Acceptable values are
> TRUE and FALSE, where TRUE (the default value) allows MAP to insert the
> clock stop circuitry, and FALSE disables the logic insertion. You can
> add this attribute to the HDL design source using the VHDL generic or
> Verilog defparam, or it can be entered as a synthesis attribute (check
> with your synthesis tool for the appropriate syntax).
>
> When applying this attribute in the UCF file, the syntax is as follows:
> INST DCM_INST DCM_AUTOCALIBRATION="FALSE";
>
> Austin
>

Thanks Austin,

I guess that is proper fix so will try. The issue was that the DCM are
in EDK and the EDK DCM doesnt have the AUTOCALIBRATE setting, those I
should figure out the not so easy to guess instance names and add them
the UCF, its no big deal now as the bottom of the problem is known.

Antti