Xilinx V2P: DCM and changing input clock

S

Sean Durkin

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



Austin

Sean Durkin wrote:
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
Click to expand...
 
Hi Austin,

Austin Lesea wrote:

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).
OK, that's exactly what I did... I just thought maybe there is some more
Click to expand...
"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
 
On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com>
wrote:

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
Click to expand...
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.
 
Allan,

Good suggestion.

Timely too.

Thanks,

Austin

Allan Herriman wrote:
On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com
wrote:


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


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.
Click to expand...
 
On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com>
wrote:

Allan,

Good suggestion.

Timely too.

Thanks,

Austin
Click to expand...

Hi Austin,

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

Regards,
Allan.



Allan Herriman wrote:
On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com
wrote:


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


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.
Click to expand...
 
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).

Austin

Allan Herriman wrote:

On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com
wrote:


Allan,

Good suggestion.

Timely too.

Thanks,

Austin



Hi Austin,

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

Regards,
Allan.




Allan Herriman wrote:

On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com
wrote:



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


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.
Click to expand...
 
On Mon, 24 May 2004 07:25:34 -0700, Austin Lesea <austin@xilinx.com>
wrote:

Allan,

Any suggestions made here are taken seriously by me (at least) and
passed along to the ICDES group.
Click to expand...
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.

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

Austin

Allan Herriman wrote:

On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com
wrote:


Allan,

Good suggestion.

Timely too.

Thanks,

Austin



Hi Austin,

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

Regards,
Allan.




Allan Herriman wrote:

On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com
wrote:



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


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.
Click to expand...
 
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.

Austin

Allan Herriman wrote:
On Mon, 24 May 2004 07:25:34 -0700, Austin Lesea <austin@xilinx.com
wrote:


Allan,

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


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.


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

Austin

Allan Herriman wrote:


On Thu, 20 May 2004 10:30:30 -0700, Austin Lesea <austin@xilinx.com
wrote:



Allan,

Good suggestion.

Timely too.

Thanks,

Austin



Hi Austin,

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

Regards,
Allan.





Allan Herriman wrote:


On Wed, 19 May 2004 07:48:09 -0700, Austin Lesea <austin@xilinx.com
wrote:




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


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.
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top