"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
Reply by John McCaskill●September 7, 20072007-09-07
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
Reply by MM●September 7, 20072007-09-07
"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
Reply by Symon●September 7, 20072007-09-07
"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.
Reply by MM●September 6, 20072007-09-06
"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
Reply by John_H●September 6, 20072007-09-06
"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
Reply by John McCaskill●September 6, 20072007-09-06
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
Reply by MM●September 6, 20072007-09-06
"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
Reply by MM●September 6, 20072007-09-06
"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
Reply by John McCaskill●September 6, 20072007-09-06
On Sep 6, 2:40 pm, "MM" <mb...@yahoo.com> wrote:
> "John McCaskill" <jhmccask...@gmail.com> wrote in message
>
> news:1189106556.202143.39700@o80g2000hse.googlegroups.com...
>
>
>
> > 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.
>
> 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
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
www.fastertechnology.com