XIlinx V2P7: DCM won't lock

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

Reply to
Sean Durkin
Loading thread data ...

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

formatting link

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.

fine.

Reply to
John Adair

John,

Couldn't have said it better.

Also, I would start a webcase with the hotline.

Aust> I would look at the power supply for the DCM. Is the Vccaux directly

Reply to
Austin Lesea

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

Reply to
Phil Hays

Phil Hays schrieb:

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

Reply to
Sean Durkin

Austin Lesea schrieb:

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

Reply to
Sean Durkin

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

formatting link

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.

Reply to
John Adair

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...

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.

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

cu, Sean

Reply to
Sean Durkin

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,

Aust> John Adair wrote:

Reply to
Austin Lesea

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.