Xilinx V2P: DCM and changing input clock

Hi *,

I use several DCMs in my V2P7-design, and have the following problem:

After the FPGA is configured, the input clock is outside of DCM specs (it's somewhere in the 1MHz-range). Of course, the DCMs can't achieve a lock with this. Awhile later (the exact time is unknown) the input clock is switched to 25MHz. In order for the DCMs to lock, I then have to issue an external reset.

What I'd like is some way to do this automatically. Normally, I'd use the status(1)-bit from the DCM, which should indicate the input clock was lost while changing. But this bit is obviously only set when a lock was achieved before and the clock is lost after that. If the DCM never locks in the first place, the status-bit is never set.

The main problem here is that I don't know exactly when the input clock will be changing, i.e. when I have to issue the reset.

Any ideas? Is there some clever way to do this I'm not seeing?

cu, Sean

Reply to
Sean Durkin
Loading thread data ...

Sean,

Brute force!

As long as the locked signal is low, periodically reset the DCM, and see if the locked signal remains low.

It takes a little state machine, and it would have to run off the DCM CLKIN (which is OK, just assume it is running at 25 MHz to calculate how many counts you need to wait to make sure that LOCKED has gone high).

Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset the DCM).

(pseudo code below)

while CLKIN_STOPPED = 1 (clock is running)

assert (reset for one clock) wait XX uSec

check DCM: DCM not operating? (check approp. status) assert reset (for one clock) wait XX uSec else do nothing

wait XX uSec (use one counter for all waits)

go to check DCM

Aust> Hi *,

Reply to
Austin Lesea

OK, that's exactly what I did... I just thought maybe there is some more "elegant" way to do this I'm not seeing. But if the pros say that is the way to go I'll stick with it. :)

Thanks for the confirmation, Austin!

cu, Sean

Reply to
Sean Durkin

Hi Austin,

Is there any fundamental reason why this logic couldn't be built into the DCM and be enabled/disabled by a config bit?

The "wait XX usec" might be a problem, but this could by worked around in a number of ways (e.g. by using psclk as a timing reference, etc.)

I find that having to add this state machine to all DCMs just to get them to work reliably is a bit of a pain.

Regards, Allan.

Reply to
Allan Herriman

Allan,

Good suggestion.

Timely too.

Thanks,

Aust> >

Reply to
Austin Lesea

Hi Austin,

Are you hinting that this feature may be added in future silicon?

Regards, Allan.

Reply to
Allan Herriman

Allan,

Any suggestions made here are taken seriously by me (at least) and passed along to the ICDES group.

The fact that it can be done in the fabric means that it isn't critical, but when we go and poll customers, we may find it is common IP that is similar to all. In that case, the 'Virtex Vortex' takes over, and it gets sucked into the chip (like many other good ideas).

Aust> >

Reply to
Austin Lesea

Good. The "auto-DCM-relocker" will need the following features (at least):

  1. Auto-relock feature can be disabled by a config bit, which allows "good 'ol mode" to be emulated. Auto-relock will be off by default.
  2. There needs to be a new status bit which indicates that the auto-relock feature has been active (to aid fault finding, etc.). This bit would be reset by a) config and b) user reset of DCM.

How would you expect to implement the "wait XX uSec" part of the design? Every FPGA design I've ever done has had a reliable (i.e. not via a DLL, PLL or DCM) clock somewhere in the range 2MHz to 50MHz. Such a clock could be connected to the PSCLK input of the DCM (or perhaps a new input?) and there would be a new DCM attribute to indicate the freq / period of this clock. Or maybe you can do it with analog delays on the chip (?)

Regards, Allan.

Reply to
Allan Herriman

Allan,

I will let the ICDES folks solve the problems. It is enough that we specify the feature!

Since the DCM is entirely digital (state machines and delay lines), it is pretty trivial to see if the states are progressing, stuck, or not valid.

Aust> >

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.