Problem locking a DCM driven by FX output of another DCM

Forgot to mention that it is all taking place in a V4 device...

/Mikhail

The FX output jitter spec of the DCMs does not meet the input jitter requirements of the DCMs. What you are trying to do will not work reliably.

Regards,

John McCaskill

Yes, I remember reading it... So, no hope here? Anyone from Xilinx? I don't care much about the output jitter on the two DCMs, I just need them to produce the clocks at right frequencies.... If I can't do it, I am in real trouble...

Thanks, /Mikhail

Skip the first DCM, and use the other two in FX mode. If they do not lock in the phase relationship that you need, reset one of them.

Regards,

John McCaskill

The problem is not so much in the phase, but in the CLKFX_DIVIDE and CLKFX_MULTIPLY values I need to get the required frequencies. The maximim CLKFX_DIVIDE is not big enough to allow for what you are suggesting... I've actually spent a lot of time trying to avoid the first DCM, but couldn't find a solution.

/Mikhail

I agree with John McCaskill. If you can't generate your later clocks in FX mode from the initial clock, you can't get there from here.

What is the system input and DCM output frequencies you need? Must they be phase aligned?

If the design can still be altered, a different clock might be used to feed the DCMs in the first place (such as 70 MHz to generate all the clocks, even what was the system clock) or go through an external jitter clean-up clock chip to then feed the DCMs.

With the architecture fixed as it is now, it won't work.

- John_H

2/3 and 2/6 should get you there. I think that those are valid combinations for M and D. 2/3 * 210 = 140 2/6 * 210 = 70

Regards,

John McCaskill

Not sure what you are trying to say here... This is pretty much what my first DCM with PMCD is doing. The final clocks are (70/29)*16 and (140/29)*20.

/Mikhail

The design can be altered but at a high cost, as I will need to redesign many other pieces...

/Mikhail

My mistake, what are the two freqencies you are tring to generate?

Regards,

John McCaskill

Do you need those exact frequencies or values within a range? If the latter, what range?

Also... V4 speedgrade which?

And are you an FPGA power user or still a bit green with the more detailed stuff?

- John_H

Exact.

-10

I don't know everything, but I am not a novice :)

While we were having this conversation I changed my design to have separate resets for all 3 DCMs. So far, it seems to have worked and they all now lock happily...

/Mikhail

Hi Mikhail,

How about not generating the clocks, but clock enables from the 210MHz signal? For example, to make the ~96.55MHz signal:-

if rising_edge(clk_210) then if accum >= 64 then enable_96

Hi Symon,

My original design did use 70 MHz clock enable. When I needed to change it (for a different reason) I decided in favour of multiple clocks mostly because I had a lot of trouble meeting timing constraints in the original design and had to resort to specifying multi-cycle paths... I do realize however that having multiple clocks create other problems! Anyways, for now my clocks seem to work fine, so I will probably stick to them for a while, that is until I run into metastability somewhere :)

Thanks, /Mikhail

I would recommend against using the DCMs they way you are now. I made the same mistake of using the FX output of one DCM to feed others. It worked for quite a while, but as I added more stuff to the design, it started to fail intermittently. If you do not want to use clock enables as Symon suggested, consider using logic to generate the clocks. As long as you can tolerate the jitter, you can take the output of the clock generator and buffer it with a BUFG to distribute it.

Regards,

John McCaskill

Thanks for sharing your experience John.

/Mikhail