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.
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).
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.
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?
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.
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.
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.
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.
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.
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";
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.