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.

Any clues, hints, sympathy?

Redards,
Gary.

On Dec 18, 5:52=A0pm, 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. =A0The 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. =A0Shortly
> 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. =A0I 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. =A0Locked
> 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.

Regards,
Pat

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. =A0The 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. =A0Shortly
> 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. =A0I 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. =A0Locked
> 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.
>
> Any clues, hints, sympathy?
>
> Redards,
> Gary.

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!

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.
>
> > Any clues, hints, sympathy?
>
> > Redards,
> > Gary.

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:
> Details I should have included:
>
> The external clock is a synthesizer that defaults to 50MHz. =A0After
> initialization, it is changed to 100MHz. =A0The 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. =A0At the time
> the frequency is changed, I get a pulse on status[1]; after that, they
> are always low. =A0I'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. =A0The 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. =A0Shortly
> > > 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. =A0I 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. =A0Locked
> > > 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.
>
> > > Any clues, hints, sympathy?
>
> > > Redards,
> > > Gary.

On Dec 19, 11:25=A0am, ghelbig
<ghel...@lycos.com> wrote:
> Details I should have included:
>
> The external clock is a synthesizer that defaults to 50MHz. =A0After
> initialization, it is changed to 100MHz. =A0The 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.

On Dec 19, 10:25=A0am, ghelbig
<ghel...@lycos.com> wrote:
> Details I should have included:
>
> The external clock is a synthesizer that defaults to 50MHz. =A0After
> initialization, it is changed to 100MHz. =A0The 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. =A0At the time
> the frequency is changed, I get a pulse on status[1]; after that, they
> are always low. =A0I'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

On Dec 20, 8:43=A0am, emeb
<ebromba...@gmail.com> wrote:
> On Dec 19, 10:25=A0am, ghelbig <ghel...@lycos.com> wrote:
>
>
>
> > Details I should have included:
>
> > The external clock is a synthesizer that defaults to 50MHz. =A0After
> > initialization, it is changed to 100MHz. =A0The 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. =A0At the time
> > the frequency is changed, I get a pulse on status[1]; after that, they
> > are always low. =A0I'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

On Dec 20, 12:11=A0pm, Patrick Maupin
<pmau...@gmail.com> wrote:
> On Dec 20, 8:43=A0am, emeb <ebromba...@gmail.com> wrote:
>
>
>
> > On Dec 19, 10:25=A0am, ghelbig <ghel...@lycos.com> wrote:
>
> > > Details I should have included:
>
> > > The external clock is a synthesizer that defaults to 50MHz. =A0After
> > > initialization, it is changed to 100MHz. =A0The 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. =A0At the time
> > > the frequency is changed, I get a pulse on status[1]; after that, the=
y
> > > are always low. =A0I'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. =A0Especially 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.

Live and learn.