Problem locking a DCM driven by FX output of another DCM

On Sep 6, 3:05 pm, "MM" <mb...@yahoo.com> wrote:
> "John McCaskill" <jhmccask...@gmail.com> wrote in message
>
> news:1189108426.459585.116970@w3g2000hsg.googlegroups.com...
>
>
>
> > 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
>
> 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


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

Regards,

John McCaskill
www.fastertechnology.com

"MM" <mbmsv@yahoo.com> wrote in message 
news:5kb4tjF2u4qpU1@mid.individual.net...
> "John McCaskill" <jhmccaskill@gmail.com> wrote in message 
> news:1189108426.459585.116970@w3g2000hsg.googlegroups.com...
>>
>> 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
>>
>
> 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

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 

"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:13e0pj9mt7vep3a@corp.supernews.com...
>
> Do you need those exact frequencies or values within a range?  If the 
> latter, what range?
>

Exact.

> Also...  V4 speedgrade which?

-10

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

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

"MM" <mbmsv@yahoo.com> wrote in message 
news:5kb550F2v2a0U1@mid.individual.net...
> "John_H" <newsgroup@johnhandwork.com> wrote in message 
> news:13e0m5eprs3aje6@corp.supernews.com...
>>
>> 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.
>
> The design can be altered but at a high cost, as I will need to redesign 
> many other pieces...
>
> /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 <= '1';
    accum <= accum - 47;
  else
    enable_96 <= '0';
    accum <= accum + 40;
  end if;
end if;

Then use the 210MHz clock with the enable? Probably not much more jittery 
than the cascaded DCMs!

BTW, the ~38.62MHz signal can be generated by dividing the 210MHz by three 
in regular logic and feeding this 70MHz to the DCM. IIRC, only the rising 
edge is important to the CLKIN of the DCM, so the mark-space ratio after the 
divide by three isn't a problem.

HTH, Syms.

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:fbr7ac$l83$1@aioe.org...
> "MM" <mbmsv@yahoo.com> wrote in message
> How about not generating the clocks, but clock enables from the 210MHz 
> signal? For example, to make the ~96.55MHz signal:-
>

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 

On Sep 7, 8:53 am, "MM" <mb...@yahoo.com> wrote:
> "Symon" <symon_bre...@hotmail.com> wrote in message
>
> news:fbr7ac$l83$1@aioe.org...
>
> > "MM" <mb...@yahoo.com> wrote in message
> > How about not generating the clocks, but clock enables from the 210MHz
> > signal? For example, to make the ~96.55MHz signal:-
>
> 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
www.fastertechnology.com

"John McCaskill" <jhmccaskill@gmail.com> wrote in message 
news:1189175806.333897.306440@r29g2000hsg.googlegroups.com...
>
> 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.

Thanks for sharing your experience John.

/Mikhail