Prev: GTKWave 3.3.0 for Windows is available
Next: Please help, Xilinx FIFO problem!
From: Patrick Maupin on 19 Dec 2009 13:12
On Dec 19, 11:25 am, ghelbig <ghel...(a)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.
From: emeb on 20 Dec 2009 09:43
On Dec 19, 10:25 am, ghelbig <ghel...(a)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
From: Patrick Maupin on 20 Dec 2009 15:11
On Dec 20, 8:43 am, emeb <ebromba...(a)gmail.com> wrote:
> On Dec 19, 10:25 am, ghelbig <ghel...(a)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
From: ghelbig on 23 Dec 2009 13:40
On Dec 20, 12:11 pm, Patrick Maupin <pmau...(a)gmail.com> wrote:
> On Dec 20, 8:43 am, emeb <ebromba...(a)gmail.com> wrote:
>
>
>
> > On Dec 19, 10:25 am, ghelbig <ghel...(a)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.

Live and learn.
First  |  Prev  | 
Pages: 1 2
Prev: GTKWave 3.3.0 for Windows is available
Next: Please help, Xilinx FIFO problem!