My apologies if this has been addressed - my web searches came up empty.
I am using a DCM in a spartan3 to generate the internal clocks - a 1-X clock and a 1/2-X clock.
The output of the DCM goes to a BUFG. The output of the BUFG goes to the feedback pin of the DCM, and to the rest of the logic.
After initialization, the input clock changes frequency. Shortly after that, I send a reset (7 clock wide) to the DCM.
The locked signal from the DCM goes away about 22uS after the input clock changes. I see a short pulse on status[1] indicating that it didn't like the input clock, and 22uS later Locked goes low.
About 20uS after that, I send the reset pulse to the DCM. Locked never (never) goes high again.
The output clock is present, but the logic is behaving like the warning on pg 15 of Xapp462 ("can exhibit glitches, spikes, or other spurious behavior") is very true.
> My apologies if this has been addressed - my web searches came up > empty.
> I am using a DCM in a spartan3 to generate the internal clocks - a 1-X > clock and a 1/2-X clock.
> The output of the DCM goes to a BUFG. The output of the BUFG goes to > the feedback pin of the DCM, and to the rest of the logic.
> After initialization, the input clock changes frequency. Shortly > after that, I send a reset (7 clock wide) to the DCM.
> The locked signal from the DCM goes away about 22uS after the input > clock changes. I see a short pulse on status[1] indicating that it > didn't like the input clock, and 22uS later Locked goes low.
> About 20uS after that, I send the reset pulse to the DCM. Locked > never (never) goes high again.
> The output clock is present, but the logic is behaving like the > warning on pg 15 of Xapp462 ("can exhibit glitches, spikes, or other > spurious behavior") is very true.
Is the new input clock frequency within the valid frequency range for using feedback? (That range is a lot smaller than if you are only using the DFS).
Also, I know Xilinx says it will reset after 4 clocks, but for some reason I always seem to reset for longer than that. Can't remember if I've ever been burned or if it just seemed to work out that way.
Don't rely on the locked signal for anything. Use the status lines and make your own locked signal.
The DCM does take a while to fully lock up during which time you will get strange frequencies and strange mark/space ratios. If you are trying to do something like a power saving frequency switch you might be better either to use clock enables to change effective clock rate or alternatively using an external synthesiser that supports these sort of frequency changes a bit more elegantly.
John Adair Enterpoint Ltd.- Home of Merrick1. The Data Mining Solution.
On 18 Dec, 23:52, ghelbig <ghel...@lycos.com> wrote:
> My apologies if this has been addressed - my web searches came up > empty.
> I am using a DCM in a spartan3 to generate the internal clocks - a 1-X > clock and a 1/2-X clock.
> The output of the DCM goes to a BUFG. The output of the BUFG goes to > the feedback pin of the DCM, and to the rest of the logic.
> After initialization, the input clock changes frequency. Shortly > after that, I send a reset (7 clock wide) to the DCM.
> The locked signal from the DCM goes away about 22uS after the input > clock changes. I see a short pulse on status[1] indicating that it > didn't like the input clock, and 22uS later Locked goes low.
> About 20uS after that, I send the reset pulse to the DCM. Locked > never (never) goes high again.
> The output clock is present, but the logic is behaving like the > warning on pg 15 of Xapp462 ("can exhibit glitches, spikes, or other > spurious behavior") is very true.
The external clock is a synthesizer that defaults to 50MHz. After initialization, it is changed to 100MHz. The DCM is used to reduce the skew between the internal clock and the external clock and create a half-speed clock for some of the logic.
Some percentage of the time, the chip "just don't run"; my current theory is that the clock comes up strange.
I'm not getting anything useful from the status lines. At the time the frequency is changed, I get a pulse on status[1]; after that, they are always low. I've waited "forever", and the locked signal never goes true.
Thanks!
On Dec 19, 2:36 am, John Adair <g...@enterpoint.co.uk> wrote:
> Don't rely on the locked signal for anything. Use the status lines and > make your own locked signal.
> The DCM does take a while to fully lock up during which time you will > get strange frequencies and strange mark/space ratios. If you are > trying to do something like a power saving frequency switch you might > be better either to use clock enables to change effective clock rate > or alternatively using an external synthesiser that supports these > sort of frequency changes a bit more elegantly.
> John Adair > Enterpoint Ltd.- Home of Merrick1. The Data Mining Solution.
> On 18 Dec, 23:52, ghelbig <ghel...@lycos.com> wrote:
> > My apologies if this has been addressed - my web searches came up > > empty.
> > I am using a DCM in a spartan3 to generate the internal clocks - a 1-X > > clock and a 1/2-X clock.
> > The output of the DCM goes to a BUFG. The output of the BUFG goes to > > the feedback pin of the DCM, and to the rest of the logic.
> > After initialization, the input clock changes frequency. Shortly > > after that, I send a reset (7 clock wide) to the DCM.
> > The locked signal from the DCM goes away about 22uS after the input > > clock changes. I see a short pulse on status[1] indicating that it > > didn't like the input clock, and 22uS later Locked goes low.
> > About 20uS after that, I send the reset pulse to the DCM. Locked > > never (never) goes high again.
> > The output clock is present, but the logic is behaving like the > > warning on pg 15 of Xapp462 ("can exhibit glitches, spikes, or other > > spurious behavior") is very true.
I would suggest holding the DCM in reset until the input clock is stable and running at correct rate. Note also the lock times can be up nearly 3ms in some circumstances going by the data in datasheet ds099.
John Adair Enterpoint Ltd. - Home of Drigmorn3. The Spartan-6 Starter Board.
On 19 Dec, 17:25, ghelbig <ghel...@lycos.com> wrote:
> The external clock is a synthesizer that defaults to 50MHz. After > initialization, it is changed to 100MHz. The DCM is used to reduce > the skew between the internal clock and the external clock and create > a half-speed clock for some of the logic.
> Some percentage of the time, the chip "just don't run"; my current > theory is that the clock comes up strange.
> I'm not getting anything useful from the status lines. At the time > the frequency is changed, I get a pulse on status[1]; after that, they > are always low. I've waited "forever", and the locked signal never > goes true.
> Thanks!
> On Dec 19, 2:36 am, John Adair <g...@enterpoint.co.uk> wrote:
> > Don't rely on the locked signal for anything. Use the status lines and > > make your own locked signal.
> > The DCM does take a while to fully lock up during which time you will > > get strange frequencies and strange mark/space ratios. If you are > > trying to do something like a power saving frequency switch you might > > be better either to use clock enables to change effective clock rate > > or alternatively using an external synthesiser that supports these > > sort of frequency changes a bit more elegantly.
> > John Adair > > Enterpoint Ltd.- Home of Merrick1. The Data Mining Solution.
> > On 18 Dec, 23:52, ghelbig <ghel...@lycos.com> wrote:
> > > My apologies if this has been addressed - my web searches came up > > > empty.
> > > I am using a DCM in a spartan3 to generate the internal clocks - a 1-X > > > clock and a 1/2-X clock.
> > > The output of the DCM goes to a BUFG. The output of the BUFG goes to > > > the feedback pin of the DCM, and to the rest of the logic.
> > > After initialization, the input clock changes frequency. Shortly > > > after that, I send a reset (7 clock wide) to the DCM.
> > > The locked signal from the DCM goes away about 22uS after the input > > > clock changes. I see a short pulse on status[1] indicating that it > > > didn't like the input clock, and 22uS later Locked goes low.
> > > About 20uS after that, I send the reset pulse to the DCM. Locked > > > never (never) goes high again.
> > > The output clock is present, but the logic is behaving like the > > > warning on pg 15 of Xapp462 ("can exhibit glitches, spikes, or other > > > spurious behavior") is very true.
On Dec 19, 11:25 am, ghelbig <ghel...@lycos.com> wrote:
> Details I should have included:
> The external clock is a synthesizer that defaults to 50MHz. After > initialization, it is changed to 100MHz. The DCM is used to reduce > the skew between the internal clock and the external clock and create > a half-speed clock for some of the logic.
> Some percentage of the time, the chip "just don't run"; my current > theory is that the clock comes up strange.
There are a few possibilities here. A couple off the top of my head:
1) Your synthesizer has excessive jitter at 100 MHz;
2) Your clock termination, board traces, etc. smear the clock out and reduce the amplitude greatly at 100 MHz. This can also look (to the FPGA) like jitter, as you have a slow ramp through the transition region, but this could even look like missing clocks if it is bad enough.
My favorite debugging technique in this scenario is to blow off the DLL, and take the clock straight out another I/O pin, and hang a scope off it. This is a little hard to do at 100 MHz, so the next best thing is to take the clock in as a clock (again without the DLL), and have a couple of counters, one running off the posedge, and one running off the negedge. For example, if you bring the outputs of a divide by four on the negedge and a divide by four on the posedge out a couple of pins, now you have two locked 25 MHz signals. Put them on a scope on infinite persistence, and look for anomalies.
HTH, Pat
1) Your clock termination frequency doesn't actual swi Have you checked the jitter of the input clock when it is running at 100 MHz.
> The external clock is a synthesizer that defaults to 50MHz. After > initialization, it is changed to 100MHz. The DCM is used to reduce > the skew between the internal clock and the external clock and create > a half-speed clock for some of the logic.
> Some percentage of the time, the chip "just don't run"; my current > theory is that the clock comes up strange.
> I'm not getting anything useful from the status lines. At the time > the frequency is changed, I get a pulse on status[1]; after that, they > are always low. I've waited "forever", and the locked signal never > goes true.
> Thanks!
Another suggestion, probably as helpful as "is it plugged in?" - make sure that the logic which generates your DCM reset isn't being clocked by that DCM. I facepalmed this once...
> On Dec 19, 10:25 am, ghelbig <ghel...@lycos.com> wrote:
> > Details I should have included:
> > The external clock is a synthesizer that defaults to 50MHz. After > > initialization, it is changed to 100MHz. The DCM is used to reduce > > the skew between the internal clock and the external clock and create > > a half-speed clock for some of the logic.
> > Some percentage of the time, the chip "just don't run"; my current > > theory is that the clock comes up strange.
> > I'm not getting anything useful from the status lines. At the time > > the frequency is changed, I get a pulse on status[1]; after that, they > > are always low. I've waited "forever", and the locked signal never > > goes true.
> > Thanks!
> Another suggestion, probably as helpful as "is it plugged in?" - make > sure that the logic which generates your DCM reset isn't being clocked > by that DCM. I facepalmed this once...
> Eric
Yeah, that's an excellent idea. Especially in a complicated design, reset loops are easy to achieve...
> On Dec 20, 8:43 am, emeb <ebromba...@gmail.com> wrote:
> > On Dec 19, 10:25 am, ghelbig <ghel...@lycos.com> wrote:
> > > Details I should have included:
> > > The external clock is a synthesizer that defaults to 50MHz. After > > > initialization, it is changed to 100MHz. The DCM is used to reduce > > > the skew between the internal clock and the external clock and create > > > a half-speed clock for some of the logic.
> > > Some percentage of the time, the chip "just don't run"; my current > > > theory is that the clock comes up strange.
> > > I'm not getting anything useful from the status lines. At the time > > > the frequency is changed, I get a pulse on status[1]; after that, they > > > are always low. I've waited "forever", and the locked signal never > > > goes true.
> > > Thanks!
> > Another suggestion, probably as helpful as "is it plugged in?" - make > > sure that the logic which generates your DCM reset isn't being clocked > > by that DCM. I facepalmed this once...
> > Eric
> Yeah, that's an excellent idea. Especially in a complicated design, > reset loops are easy to achieve...
> Pat
I think I found a solution.
The external clock is spec'd at 150 fS (150 femptoseconds) of jitter, so I didn't go there.
The status lines are near useless; observed behavior does not match their description. No amount of futzing with reset would make it behave as documented.
I am switching the synthesizer from 50MHz to 100MHz after initialization. According to the data sheet, either the low range (18~167 MHz) or the high range (48~280 MHz) should be "just fine".
In practice, the high range works (the DCM regains lock), and the low range does not.
|
