DCM and CLKFX - is this allowed?

RobertP schrieb am 06.10.2004 16:16:

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

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:

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.

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,

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.

Aust> Hi Austin,

Jim, that's not enough. We did that, M and D can be any intger up to 32, and the input frequency must be higher than 1 MHz, and the output frequency must be higher than 24 MHz, but not higher than 450 MHz

But that does not stop users' imagination. So we get the question that started this thread. And that's why I added the explanation: multiply alone, or divide alone are allowed to seemingly violate the spec, as long as the input and output specs are obeyed. "Don't speculate, believe us!" We engineers have this wide-ranging imagination (thank God) and we are trained to think worst case (thank God, but sometimes it can mislead...) Peter Alfke

I think you are saying this :

Fo = fi * M/D; Valid for this range of numbers 1 or divide alone are allowed to seemingly violate the spec, as long as the

Here I am lost: the equation form I was proposing has no partial answer, so you cannot have multiply alone or divide alone.

Perhaps, but throw that collection of words at someone who has english as a second language, and they are likely to get confused. is this another warning/caveat, or an explanation ?

My point is that concise expressions leave much less to the imagination, and cross language barriers much easier.

-jg

I'd love to be able to do that on a V2. I would be more then happy to go through a reset of the DCM to give it a chance. Alas, my design is a parasite project on a board made for another purpose, so I can't change the chip out:-(

In my application, the DCM output is sent off-chip to devices under test.

--
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

The trouble from a frequency synthesis perspective is the engineering history with PLLs. Typical PLLs before silicon VCOs were common had the reference divided down to a freqeuncy fed to the phase comparator. The VCO's output frequency was also scaled down to the same frequency. The resulting fraction can be an M/D figure as in the DCM.

With silicon VCOs improving in performance and cost over recent years, it's common to have a high frequency VCO with two dividers: one to do a phase comparison with the input, the other to provide the output frequency. The rato again can be represented as M/D.

Since the DCM doesn't use a VCO, the PLL mindset doesn't apply in the classical sense so the very low phase comparator in the first approach or the very high frequency VCO in the second aren't an issue. That's why the comment.

It's more of a clean NCO than a VCO.

Austin, Keep it up, I for one enjoy the pun-ishment.

John, I'd suggest a numerically controlled oscilator (NCO) / scaling accumulator / DDFS (see

In the latest parts, you can clock a 10 bit accumulator at >500 MHz, allowing your microblaze to run up to 250MHz (do they go that fast? I'll be using one soon). You would get more resolutions than the

5-bits M, 5-bits D of the CLKFX. If you are scaling the clock for power conservation, you probably would not need more than 6 bits. Also, no worries about the period dropping below the minimum that the microblaze configuration was routed for. And far easier to program than partial re-config.

Regards, John

Yes, it certainly keeps the punters happy.

I think Microblaze fmax is somewhere around 150MHz these days, but climbing all the time esp in V4.

Thanks for the tip - certainly much easier than partial reconfig.

I confess a strange desire to find useful things to do with partial reconfiguration - however as the devices get bigger and faster, the candidate set seems to get smaller and smaller. Perhaps if it weren't so painful re: tools and design flow (and I hear there are changes in the wind that might answer that wish)

Cheers,

John