Re: Virtex-4FX DCM autoshutdown failure, any suggestions

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

.

Relevant Pages

  • Re: DCM Jitter
    ... I saw this comment in the Verilog file auto-generated by the DCM ... There has been information on the Xilinx tools that suggest that jitter ... The assumption here is that you have a low jitter clock presented to your ... I generated a verbose timing report, as you suggested, and every single path ...
    (comp.arch.fpga)
  • Re: DCM Jitter
    ... I saw this comment in the Verilog file auto-generated by the DCM ... There has been information on the Xilinx tools that suggest that jitter ... The assumption here is that you have a low jitter clock presented to your ... I generated a verbose timing report, as you suggested, and every single path ...
    (comp.arch.fpga)
  • Re: DCM Jitter
    ... I saw this comment in the Verilog file auto-generated by the DCM ... There has been information on the Xilinx tools that suggest that jitter from the DCMs - assuming the input jitter is clean to those devices - is included in the timing analysis. ... I'd suggest looking at the full timing report for a 200 MHz path and for a 50 MHz path. ... The assumption here is that you have a low jitter clock presented to your system for the DCMs to work from. ...
    (comp.arch.fpga)
  • Re: DCM Jitter
    ... I saw this comment in the Verilog file auto-generated by the DCM ... Austin didn't directly address the DCM-generated jitter. ... The assumption here is that you have a low jitter clock presented to your ... I generated a verbose timing report, as you suggested, and every single path ...
    (comp.arch.fpga)
  • Re: Virtex-4FX DCM autoshutdown failure, any suggestions
    ... DCM1 uses only FX output for PPC system clock (to get the clock into ... DCM will remove lock, output stop, everythings stops. ... 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. ...
    (comp.arch.fpga)