Hi Guys,

Just wondering if the CLKIN_PERIOD value needs to be set to the period
of input clock when instantiating a DCM component. I have a design
where input clock can be either 25MHz or 125MHz, the clock frequency
will change during operation. I will be using the DCM mainly for de-
skewing. What should the CLKIN_PERIOD be set to in this case?
Does it cause any problems if CLKIN_PERIOD is not set?

Cheers
Sudhir

On 29 Jan., 04:09, Sudhir Singh
<Sudhir.Si...@email.com> wrote:
> Hi Guys,
>
> Just wondering if the CLKIN_PERIOD value needs to be set to the period
> of input clock when instantiating a DCM component. I have a design
> where input clock can be either 25MHz or 125MHz, the clock frequency
> will change during operation. I will be using the DCM mainly for de-
> skewing. What should the CLKIN_PERIOD be set to in this case?
> Does it cause any problems if CLKIN_PERIOD is not set?
>
> Cheers
> Sudhir

Hi Sudhir,
the DCM should work as specified, regardless of the frequency given in
the coregenerator GUI or VHDL Generic Maps.
Only thing to considder is, that the DCM might loose it's frequency
locking when the input frequency changes.
You should do some post-par simulations and observe the LOCKED signal.
(Locking on a new frequency takes time.)

Have a nice synthesis
  Eilert

On Jan 29, 2:19=A0am, backhus
<goous...@googlemail.com> wrote:
> On 29 Jan., 04:09, Sudhir Singh <Sudhir.Si...@email.com> wrote:
>
> > Hi Guys,
>
> > Just wondering if the CLKIN_PERIOD value needs to be set to the period
> > of input clock when instantiating a DCM component. I have a design
> > where input clock can be either 25MHz or 125MHz, the clock frequency
> > will change during operation. I will be using the DCM mainly for de-
> > skewing. What should the CLKIN_PERIOD be set to in this case?
> > Does it cause any problems if CLKIN_PERIOD is not set?
>
> > Cheers
> > Sudhir
>
> Hi Sudhir,
> the DCM should work as specified, regardless of the frequency given in
> the coregenerator GUI or VHDL Generic Maps.
> Only thing to considder is, that the DCM might loose it's frequency
> locking when the input frequency changes.
> You should do some post-par simulations and observe the LOCKED signal.
> (Locking on a new frequency takes time.)
>
> Have a nice synthesis
> =A0 Eilert

If I'm not mistaken the CLKIN_PERIOD is mainly needed for the DFS
portion of the DCM, which you shouldn't need for phase shifting.
Also I've seen cases where the DCM loses lock and does not negate
the LOCKED signal.  You should monitor the status bits to be sure
that the DCM is locked, and reset it when you detect loss of lock.

Regards,
Gabor

All,

The clock in period for the DCM is used to set the configuration bits
for best performance (tap size, etc.).

If you don't set it to the right frequency range, you may not get the
best performance, and perhaps it won't work at all if you are set for
the low range, and the input is in the high range.

The absolute value (accuracy) of the number is not important.  The DCM
software in ISE is just trying to make decisions based on the low
frequency range, and the high frequency range.

So, for example, if the input is from 25 MHz to 150 MHz, any value in
this range is fine.

The DCM will track any input in this range, until it runs out of taps
with the delay lines.  Then LOCKED goes false (the only reason why it
does go false).

Also monitor CLOCK_IN_LOST status bit, as when the clock is lost, this
is the ONLY bit that changes (everything else is synchronous to
CLOCK_IN, so when it is lost, nothing will change, except this one
status bit).

Austin

Hi Guys,

Thank you all for the information you have given me.

Cheers
Sudhir