DCM and CLKFX - is this allowed?

Hello,
I have an input clock of 125MHz coming to VirtexII device. I want to 
derive 80MHz clock from it.
The way I wanted to go is to use CLKFX output with 16/25 (M/D) factor. 
Can I do this without violating timing requirements for the DCM?
Both the input and output frequencies are within allowed range and I get 
no warnings neither from architecture wizard nor from online CLKFX 
jitter calculator, however I'm not fully understand the sentence from 
user guide ug002:

"For example, assume input frequency = 50 MHz, M = 25, and D = 8 (note 
that M and D values have no common factors and hence cannot be reduced). 
The output frequency is correctly 156.25 MHz, although 25 x 50 MHz = 
1.25 GHz and 50 MHz / 8 = 6.25 MHz, and both of these values are far 
outside the range of the input frequency."

Does this mean that I cannot use 16/25 factor in my case?

-- 
RobertP.

RobertP schrieb am 06.10.2004 16:16:

> "For example, assume input frequency = 50 MHz, M = 25, and D = 8 (note 
> that M and D values have no common factors and hence cannot be reduced). 
> The output frequency is correctly 156.25 MHz, although 25 x 50 MHz = 
> 1.25 GHz and 50 MHz / 8 = 6.25 MHz, and both of these values are far 
> outside the range of the input frequency."
> 
> Does this mean that I cannot use 16/25 factor in my case?
There should not be any problems with that.

The paragraph from the user guide is just supposed to tell you that you 
can do a COMBINED multiply by 16 and divide by 25, even if the SINGLE 
operations would violate the allowed frequency ranges. That means even 
though you cannot multiply 125MHz*16=2000MHz or divide 125MHz/25=5MHz on 
its own, you can do the COMBINED operation.

cu,
Sean

Thanks for quick response.
I looked into Spartan3 xapp462. It confirms what you are telling (this 
time without any doubts).


-- 
RobertP.

Mea culpa!
I was the one who added this sentence into the manual, in order to really
clarify the issue. Apparently I was not clear enough...
So: In a combined multiply-divide operation, only the input frequency and
the final output frequency must fall into the specified ranges.
Multiplication and division are not performed in sequence, but really as a
simultaneous combined mathematical operation, so the DCM never sees the
result of multiplication alone, or of division alone.
This is not intuitively obvious, and a circut description would be far too
complex, so we have to explain it in English, and you must take our word for
it. Well, you will also experience that it works.  :-)
Peter Alfke


> From: RobertP <r_p_u_d_l_i_k@poczta.onet.pl>
> Organization: news.onet.pl
> Newsgroups: comp.arch.fpga
> Date: Wed, 06 Oct 2004 16:16:09 +0200
> Subject: DCM and CLKFX - is this allowed?
> 
> Hello,
> I have an input clock of 125MHz coming to VirtexII device. I want to
> derive 80MHz clock from it.
> The way I wanted to go is to use CLKFX output with 16/25 (M/D) factor.
> Can I do this without violating timing requirements for the DCM?
> Both the input and output frequencies are within allowed range and I get
> no warnings neither from architecture wizard nor from online CLKFX
> jitter calculator, however I'm not fully understand the sentence from
> user guide ug002:
> 
> "For example, assume input frequency = 50 MHz, M = 25, and D = 8 (note
> that M and D values have no common factors and hence cannot be reduced).
> The output frequency is correctly 156.25 MHz, although 25 x 50 MHz =
> 1.25 GHz and 50 MHz / 8 = 6.25 MHz, and both of these values are far
> outside the range of the input frequency."
> 
> Does this mean that I cannot use 16/25 factor in my case?
> 
> -- 
> RobertP.

Peter Alfke wrote:

> I was the one who added this sentence into the manual, in order to really
> clarify the issue. Apparently I was not clear enough...
> So: In a combined multiply-divide operation, only the input frequency and
> the final output frequency must fall into the specified ranges.
> Multiplication and division are not performed in sequence, but really as a
> simultaneous combined mathematical operation, so the DCM never sees the
> result of multiplication alone, or of division alone.

Is there a description, even a relatively simple one, about
how DCMs work?   I understand analog PLL's with dividers on
the input and output feeding the phase comparator, where the
intermediate frequency does matter, at least a little bit.

-- glen

Glen,

Let me try to explain it.

The digital frequency synthesizer uses a tapped delay line oscillator as 
its source of output clock.

The taps are adjusted such that the output frequency is related to the 
input frequency by the M and D values.

At every input clock divided by D, or every output clock divided by M 
(equivalent), the phase of the output is hard sync'ed to the input 
rising edge (what we refer to as 'concurrence').  In this way the total 
phase error is not unbounded (as in is in a PLL), but is never worse 
than the worst wrong guess at the tap value.

Most folks will recognize after they perform some thought experiments 
that changing the tap value is too coarse to actually allow the phase 
error to remain as small as we claim.

A clever design technique (patented) is used by which we a priori change 
tap values between concurrences to estimate in advance the proper 
combination of delays to exactly match one CLKFX cycle.

I refer to this as a 'tap dance.' (please forgive my humor, but it is 
part of my personality....)  Change the M, or D, or input frequency, and 
the 'tap dance' changes such that the loop stays locked, and the output 
remains phase and frequency locked to the input.

In this way, the phase error (if the oscillator is perfect) is never 
worse than a tap value for one whole concurrence cycle (D cycles of 
input clock, or M cycles of output clock).

Austin



glen herrmannsfeldt wrote:
> 
> 
> Peter Alfke wrote:
> 
>> I was the one who added this sentence into the manual, in order to really
>> clarify the issue. Apparently I was not clear enough...
>> So: In a combined multiply-divide operation, only the input frequency and
>> the final output frequency must fall into the specified ranges.
>> Multiplication and division are not performed in sequence, but really 
>> as a
>> simultaneous combined mathematical operation, so the DCM never sees the
>> result of multiplication alone, or of division alone.
> 
> 
> Is there a description, even a relatively simple one, about
> how DCMs work?   I understand analog PLL's with dividers on
> the input and output feeding the phase comparator, where the
> intermediate frequency does matter, at least a little bit.
> 
> -- glen
> 

Peter Alfke wrote:
> Mea culpa!
> I was the one who added this sentence into the manual, in order to really
> clarify the issue. Apparently I was not clear enough...
> So: In a combined multiply-divide operation, only the input frequency and
> the final output frequency must fall into the specified ranges.
> Multiplication and division are not performed in sequence, but really as a
> simultaneous combined mathematical operation, so the DCM never sees the
> result of multiplication alone, or of division alone.
> This is not intuitively obvious, and a circut description would be far too
> complex, so we have to explain it in English, and you must take our word for
> it. Well, you will also experience that it works.  :-)
> Peter Alfke

  Maybe you could try a maths based description, generally that's
much better than English ?

Fo = fi * M/D;
Valid for
  LLimitM < M < ULimitM    [You fill out the Limits ]
  LLimitD < D < ULimitD

and if there are interactions (Limits depend on other variables value) , 
then expand this as necessary.




> 
> 
> 
>>From: RobertP <r_p_u_d_l_i_k@poczta.onet.pl>
>>Organization: news.onet.pl
>>Newsgroups: comp.arch.fpga
>>Date: Wed, 06 Oct 2004 16:16:09 +0200
>>Subject: DCM and CLKFX - is this allowed?
>>
>>Hello,
>>I have an input clock of 125MHz coming to VirtexII device. I want to
>>derive 80MHz clock from it.
>>The way I wanted to go is to use CLKFX output with 16/25 (M/D) factor.
>>Can I do this without violating timing requirements for the DCM?
>>Both the input and output frequencies are within allowed range and I get
>>no warnings neither from architecture wizard nor from online CLKFX
>>jitter calculator, however I'm not fully understand the sentence from
>>user guide ug002:
>>
>>"For example, assume input frequency = 50 MHz, M = 25, and D = 8 (note
>>that M and D values have no common factors and hence cannot be reduced).
>>The output frequency is correctly 156.25 MHz, although 25 x 50 MHz =
>>1.25 GHz and 50 MHz / 8 = 6.25 MHz, and both of these values are far
>>outside the range of the input frequency."
>>
>>Does this mean that I cannot use 16/25 factor in my case?
>>
>>-- 
>>RobertP.
> 
> 

Hi Austin,

Austin Lesea wrote:

> I refer to this as a 'tap dance.' (please forgive my humor, but it is 
> part of my personality....)  Change the M, or D, or input frequency, and 
> the 'tap dance' changes such that the loop stays locked, and the output 
> remains phase and frequency locked to the input.
> 
> In this way, the phase error (if the oscillator is perfect) is never 
> worse than a tap value for one whole concurrence cycle (D cycles of 
> input clock, or M cycles of output clock).

Any ideas (or experience) on what happens if you twiddle DCM 
configuration bits on the fly (a la partial reconfig)?  I'm guessing it 
would be safe to hold the DCM in reset, change the tap configuration, 
then restart it, but that's not much use if the DCM is clocking the very 
same logic that is driving the partial reconfiguration :)

I'm picturing a self-reconfiguring microblaze uClinux system dynamically 
scaling its own clock...

John

Hi John,
Others more familiar with the DCM can probably provide more detail on
this, but the ew generation of the DCM in Virtex-4 supports the new
Dynamic Reconfiguration Port, which is a memory type-interface, which
allows a user to dyamically change the DCM configuration. It should be
relatively easy to dynamically change the DCM tap or M/D numbers. So
in short, it should be possible to have an MicroBlaze system
automatically throttle it's own clock.
Also, I beleive if you increment or decrement the tap by 1 tap at a
time, the DCM should not loose lock durig this process.

Hope this is helpful !




John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<ck1rpt$ubf$1@bunyip.cc.uq.edu.au>...
> Hi Austin,
> 
> Austin Lesea wrote:
> 
> > I refer to this as a 'tap dance.' (please forgive my humor, but it is 
> > part of my personality....)  Change the M, or D, or input frequency, and 
> > the 'tap dance' changes such that the loop stays locked, and the output 
> > remains phase and frequency locked to the input.
> > 
> > In this way, the phase error (if the oscillator is perfect) is never 
> > worse than a tap value for one whole concurrence cycle (D cycles of 
> > input clock, or M cycles of output clock).
> 
> Any ideas (or experience) on what happens if you twiddle DCM 
> configuration bits on the fly (a la partial reconfig)?  I'm guessing it 
> would be safe to hold the DCM in reset, change the tap configuration, 
> then restart it, but that's not much use if the DCM is clocking the very 
> same logic that is driving the partial reconfiguration :)
> 
> I'm picturing a self-reconfiguring microblaze uClinux system dynamically 
> scaling its own clock...
> 
> John

John,

Unfortunately the DFS part of the DCM will lose lock if you dynamically 
change M or D.  Due to the hard sync feature, the oscillator risks 
stopping if the phase if off by too much (see CLKFX_STOPPED status bit).

V4 has some changes to keep the oscilltor running even in adverse 
conditions, as does Spartan 3, but we haven't finished characterizing 
just how tolerant of the jumps the DFS is.  And maybe we won't, as it 
isn't worth it (such a phase glitch on CLKIN would cause lots of other 
problems with timing violations in logic anyway).

Changing M or D, and then reseting is supported, however.

Turns out you can change the CLKIN frequency and the DFS will track, as 
long as the input changes slowly enoguh that the logic has time to 
follow it.  Taps update every 3 (VII, II Pro, S3) or 6 (V4) clocks, so I 
suggest that one has at least 100 updates (300 or 600 clocks) before the 
input frequency is changed by more than a tap in phase (absolutely safe 
critieria for tracking).

The DLL part risks running off either end of the delay line as it is 
trying to zero the skew as you change input frequency, so the DLL can 
not track a changing input outside of the specification in the data sheet.

Austin

John Williams wrote:
> Hi Austin,
> 
> Austin Lesea wrote:
> 
>> I refer to this as a 'tap dance.' (please forgive my humor, but it is 
>> part of my personality....)  Change the M, or D, or input frequency, 
>> and the 'tap dance' changes such that the loop stays locked, and the 
>> output remains phase and frequency locked to the input.
>>
>> In this way, the phase error (if the oscillator is perfect) is never 
>> worse than a tap value for one whole concurrence cycle (D cycles of 
>> input clock, or M cycles of output clock).
> 
> 
> Any ideas (or experience) on what happens if you twiddle DCM 
> configuration bits on the fly (a la partial reconfig)?  I'm guessing it 
> would be safe to hold the DCM in reset, change the tap configuration, 
> then restart it, but that's not much use if the DCM is clocking the very 
> same logic that is driving the partial reconfiguration :)
> 
> I'm picturing a self-reconfiguring microblaze uClinux system dynamically 
> scaling its own clock...
> 
> John