XIlinx V2P7: DCM won't lock

[Sean Durkin]

Hi *,

I need some pointers from the gurus...

I have two different designs, let's call them A and B. Both use 3 DCMs,
both have the same input clock (it's all running in the FPGA on the same
board). The DCMs in both designs are used to generate the same mupltiple
frequencies, and are connected identically (i.e. regarding the BUFGs for
the input and feedback and such). In design A, the DCMs lock, in B they
won't, even if I manually put DCMs and the corresponding BUFGs in the
same positions as in the design A via UCF constraints.

So basically what I have is identical DCMs, hooked up identically, with
identical input clocks, but in one design they won't lock.

Now if I load design A into the FPGA, wait for the DCMs to lock, and
then load the other design, the DCMs stay locked and everything work's fine.

How can this be? Does the load on the output of a DCM affect it's
ability to lock somehow? What else can cause DCMs not to lock despite of
valid input frequency?

cu,
Sean

 

[John Adair]

I would look at the power supply for the DCM. Is the Vccaux directly
connected to a Vcco power rail if so possible problem there. Otherwise look
at the jitter on input clocks at each level. Thirdly if you have a DCM chain
hold the DCM in reset until the input clock is stable (locked).

John Adair
Enterpoint Ltd. - Home of Broaddown2
http://www.enterpoint.co.uk

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.


"Sean Durkin" <smd@despammed.com> wrote in message
news:2h5ve2F8pr4iU1@uni-berlin.de...

Hi *,

I need some pointers from the gurus...

I have two different designs, let's call them A and B. Both use 3 DCMs,
both have the same input clock (it's all running in the FPGA on the same
board). The DCMs in both designs are used to generate the same mupltiple
frequencies, and are connected identically (i.e. regarding the BUFGs for
the input and feedback and such). In design A, the DCMs lock, in B they
won't, even if I manually put DCMs and the corresponding BUFGs in the
same positions as in the design A via UCF constraints.

So basically what I have is identical DCMs, hooked up identically, with
identical input clocks, but in one design they won't lock.

Now if I load design A into the FPGA, wait for the DCMs to lock, and
then load the other design, the DCMs stay locked and everything work's
fine.

How can this be? Does the load on the output of a DCM affect it's
ability to lock somehow? What else can cause DCMs not to lock despite of
valid input frequency?

cu,
Sean

 

[Austin Lesea]

John,

Couldn't have said it better.

Also, I would start a webcase with the hotline.

Austin

John Adair wrote:

I would look at the power supply for the DCM. Is the Vccaux directly
connected to a Vcco power rail if so possible problem there. Otherwise look
at the jitter on input clocks at each level. Thirdly if you have a DCM chain
hold the DCM in reset until the input clock is stable (locked).

John Adair
Enterpoint Ltd. - Home of Broaddown2
http://www.enterpoint.co.uk

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.


"Sean Durkin" <smd@despammed.com> wrote in message
news:2h5ve2F8pr4iU1@uni-berlin.de...

Hi *,

I need some pointers from the gurus...

I have two different designs, let's call them A and B. Both use 3 DCMs,
both have the same input clock (it's all running in the FPGA on the same
board). The DCMs in both designs are used to generate the same mupltiple
frequencies, and are connected identically (i.e. regarding the BUFGs for
the input and feedback and such). In design A, the DCMs lock, in B they
won't, even if I manually put DCMs and the corresponding BUFGs in the
same positions as in the design A via UCF constraints.

So basically what I have is identical DCMs, hooked up identically, with
identical input clocks, but in one design they won't lock.

Now if I load design A into the FPGA, wait for the DCMs to lock, and
then load the other design, the DCMs stay locked and everything work's

fine.

How can this be? Does the load on the output of a DCM affect it's
ability to lock somehow? What else can cause DCMs not to lock despite of
valid input frequency?

cu,
Sean

 

[Phil Hays]

Sean Durkin wrote:

I have two different designs, let's call them A and B. Both use 3 DCMs,
both have the same input clock (it's all running in the FPGA on the same
board). The DCMs in both designs are used to generate the same mupltiple
frequencies, and are connected identically (i.e. regarding the BUFGs for
the input and feedback and such). In design A, the DCMs lock, in B they
won't, even if I manually put DCMs and the corresponding BUFGs in the
same positions as in the design A via UCF constraints.

So basically what I have is identical DCMs, hooked up identically, with
identical input clocks, but in one design they won't lock.

Now if I load design A into the FPGA, wait for the DCMs to lock, and
then load the other design, the DCMs stay locked and everything work's fine.

How can this be? Does the load on the output of a DCM affect it's
ability to lock somehow? What else can cause DCMs not to lock despite of
valid input frequency?

Output pins with heavy loads near the clock pins can add jitter to the
input clock signal if they happen to switch near the clock edges.

Are you resetting the DCM? A reset (3 clock cyles or longer) after
configuration and stable clock may be needed to get the DCM to lock
reliably.


--
Phil Hays
Phil_hays at posting domain should work for email

 

[Sean Durkin]

Phil Hays schrieb:

Output pins with heavy loads near the clock pins can add jitter to the
input clock signal if they happen to switch near the clock edges.

Are you resetting the DCM? A reset (3 clock cyles or longer) after
configuration and stable clock may be needed to get the DCM to lock
reliably.
Yes, I am resetting them. Actually, I'm doing now what Austin suggested

in another thread, i.e. continually checking if the DCMs have locked, if
not reset them, wait for 10ms, and check again.

But the thing that puzzles me, is that both designs are more or less
identical, the only difference being that in the second variant there is
some logic added. The rest (output pins, input clock, the entire
hardware) is identical.

cu,
Sean

 

[Sean Durkin]

Austin Lesea schrieb:

John,

Couldn't have said it better.

Also, I would start a webcase with the hotline.
OK, I'll do that. But, as I said earlier, the thing that puzzles me, is

that input clocks, output pins etc. are all identical in both designs.
The only difference is in design B there is some more logic added, the
rest is the same. Obviously that affects the locking/not locking of the
DCMs... I've experienced something similar before, when I added a
Chipscope-Core to the design, and as long as that was connected the DCMs
wouldn't lock either. The only solution was to use a separate DCM to
generate a clock for Chipscope.

But could the following help:

Assuming that the amount of logic connected to the output of a DCM does
matter or some nearby output pins add jitter to the input clock, could I
use a BUFGMUX at the output of the DCMs, and use the lock-output of the
DCM as select-signal to switch between the DCM-output and GND? That way
I could disable all logic in the FPGA until the DCMs are locked.

Until then it seems I have to configure the FPGA twice to get the design
running.

cu,
Sean

 

[John Adair]

If you want to make your logic "quiet" I would suggest using a set/reset or
clock enable as the simplest way. This isn't going to solve issues after
locking.

I might have missed it in the thread but is your Vccaux connected in any
way to a Vcco rail ? If it isn't please ignore the following:

Statement - 2 designs that are similar at HDL level may be very different
designs after synthesis. mapping and p&r.

In terms of I/O power noise if you have not used I/O registers for all I/O
in the design then significant differences in power noise may be experienced
between 2 functional similar designs but never the less different. One line
of HDL code can in some circumstances make a large difference in actual
implementation. With non-I/O registers the effective output timing varies
widely between I/O. The main consequence of this is switching of outputs is
spread over a window of time rather than be close together. Using non-I/O
registers you can get a different I/O timing spread, and hence noise, every
time you make a minor alteration or difference.

The good thing about spreading the switching of I/Os is that ground bounce
and other power noise effects is usually less than a design that fully uses
I/O registers.

Ok so rather than bore everyone any more I suggest that if your Vccaux is
connected to a Vcco you try and reduce noise in that Vcco. One way to do
this is to reduce the drive on I/Os and add slew rate control. A more
extreme method is to move I/O timing by using either both edges of the clock
switching half the outputs on one edge the other half on the other edge.
This technique can be further extended using multiples of the clock with
clock enable or even phases from a DCM. Other techniques involve locking
registers in particular places of the fabric to induce different timing
between I/O. The latter is very much a last resort as timing can vary widely
between batches, temperature, voltage etc.

More simply you can also add more decoupling and separate your Vccaux from
any Vcco power rails. Not always easy in already designed and built product.


John Adair
Enterpoint Ltd. - Home of Broaddown2
http://www.enterpoint.co.uk

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.


"Sean Durkin" <smd@despammed.com> wrote in message
news:2h9hnfFa6a0hU1@uni-berlin.de...

Austin Lesea schrieb:

John,

Couldn't have said it better.

Also, I would start a webcase with the hotline.
OK, I'll do that. But, as I said earlier, the thing that puzzles me, is
that input clocks, output pins etc. are all identical in both designs.
The only difference is in design B there is some more logic added, the
rest is the same. Obviously that affects the locking/not locking of the
DCMs... I've experienced something similar before, when I added a
Chipscope-Core to the design, and as long as that was connected the DCMs
wouldn't lock either. The only solution was to use a separate DCM to
generate a clock for Chipscope.

But could the following help:

Assuming that the amount of logic connected to the output of a DCM does
matter or some nearby output pins add jitter to the input clock, could I
use a BUFGMUX at the output of the DCMs, and use the lock-output of the
DCM as select-signal to switch between the DCM-output and GND? That way
I could disable all logic in the FPGA until the DCMs are locked.

Until then it seems I have to configure the FPGA twice to get the design
running.

cu,
Sean

 

[Sean Durkin]

John Adair wrote:

If you want to make your logic "quiet" I would suggest using a set/reset or
clock enable as the simplest way. This isn't going to solve issues after
locking.
I don't have any issues after locking, my problem is the DCMs not

locking in the first place. After they've locked, everything works fine,
the output clock is as perfect as it gets coming from a DCM, and they
never lose lock again.
The entire design is kept in reset until all DCMs have locked. In one
variant the design will never come out of reset, since the DCMs never
lock, even though at that particular time no outputs are active at all,
or at least they shouldn't be switching; so there should be no power
noise added from switching I/Os as far as I understand it...

I might have missed it in the thread but is your Vccaux connected in any
way to a Vcco rail ? If it isn't please ignore the following:
It is, but this is more or less a finished product and I can't do

anything about it now. But I'll keep that in mind for future designs.

Statement - 2 designs that are similar at HDL level may be very different
designs after synthesis. mapping and p&r.
Yes, that's right, the whole design flow seems rather "chaotic"

cu,
Sean

 

[Austin Lesea]

Sean,

One issue with the DCM's is that they need the CLKFB input stable when
they start if they are to lock.

A common problem is that the CLKIN, or the CLKFB (or both) are not
stable when DONE goes high, so the DCM fails to lock. A subsequent
reset usually solves this problem.

Again, it sounds like you should send this to the hotline, as they are
well versed in getting to the root of these issues,

Austin

Sean Durkin wrote:

John Adair wrote:

If you want to make your logic "quiet" I would suggest using a
set/reset or
clock enable as the simplest way. This isn't going to solve issues after
locking.

I don't have any issues after locking, my problem is the DCMs not
locking in the first place. After they've locked, everything works fine,
the output clock is as perfect as it gets coming from a DCM, and they
never lose lock again.
The entire design is kept in reset until all DCMs have locked. In one
variant the design will never come out of reset, since the DCMs never
lock, even though at that particular time no outputs are active at all,
or at least they shouldn't be switching; so there should be no power
noise added from switching I/Os as far as I understand it...

I might have missed it in the thread but is your Vccaux connected in any
way to a Vcco rail ? If it isn't please ignore the following:

It is, but this is more or less a finished product and I can't do
anything about it now. But I'll keep that in mind for future designs.

Statement - 2 designs that are similar at HDL level may be very different
designs after synthesis. mapping and p&r.

Yes, that's right, the whole design flow seems rather "chaotic"

cu,
Sean