Variable phase shift on Spartan3 DCMs. Does it work?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Has anyone used the variable phase shift in Spartan3 DCMs?   My
potential application will dither the receive clock and then filter the
incoming data to obtain a much finer than clock cycle resolution on time
of arrival measurements on a digital one bit input.  The phase shift
update rate would be about 3 MHz, and each phase update is simply an
increment or decrement.  I'm hoping to get in the neighborhood of 300ps
resolution by reading the repetitive input signal with the phase of the
input register clock in/decremented on successive takes over roughly 180
reads.

The questions are:
Does it work as advertised?
Is the time from PSEN to phase change constant for fixed clkin, psclk
frequencies and constant DCM parameters other than the phase shift?
I assume the output jitter is the +/-150ps specified plus whatever
jitter is present on clkin.  Is that correct?

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: Variable phase shift on Spartan3 DCMs. Does it work?
Ray, I will try to find out.What clock frequency?
But in the meantime, I would use Virtex-4LX25 (plentifully available)
and use its fine-grained input delay line, severalof them in
inparallel, with  80 ps difference between them. You would not have to
make multiple measurements, just one would give you the answer.
But I know you are smart enough to figure this out, plus more
tricks...:-)
I'm in love with that 64-tap input delay line...
Peter Alfke


Re: Variable phase shift on Spartan3 DCMs. Does it work?
Ray,
I've used it on V2PRO, and it seemed to work fine. Read up on the "Factory
JF" parameter; this has got something to do with the phase update rate. I
wonder if your application could take advantage of the DSS mode built into
the DCMs. Or did they get rid of that in Spartan3?
Cheers, Syms.

p.s. Peter, be careful, those delay lines are 'high maintenance'! ;-)

"Peter Alfke"  wrote
Quoted text here. Click to load it



Re: Variable phase shift on Spartan3 DCMs. Does it work?
Symon,

DSS is gone.

Austin

Symon wrote:
Quoted text here. Click to load it

Re: Variable phase shift on Spartan3 DCMs. Does it work?
Peter, can you get me Virtex4 for under $12?  If so, I'll gladly use
that instead.   Target device is a spartan3-50 for cost reasons.  Syms,
as Austin noted, DSS is not in S3.  Clock looks like it will be about
100 MHz, and I'll be bumping the phase up by a quarter cycle in 64
increments.  Will be using the 0 and 90 clk outs, both edges to get
measurements in each phase quadrant to keep the number of measurements
reasonable. (Simulation works fine on it, so as long as the simulation
matches the hardware, it will be OK).  Thanks.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: Variable phase shift on Spartan3 DCMs. Does it work?
If the simulation is showing many cycles between the phase_inc or phase_dec
to the completion of the phase adjustment, you may be good from all the
investigations I did before.

I thought there were something like 89 DLL cycles required before the phase
adjustment was "complete" and the next adjustment would occur.  With a 100
MHz clock and 3 MHz adjustment rate, that doesn't mesh.

I was hoping someone with a greater knowledge of the DLLs and DCMs across
the families might comment on the number of cycles required.

Anyone?


Quoted text here. Click to load it



Re: Variable phase shift on Spartan3 DCMs. Does it work?
John,
As I said, maybe the "FACTORY_JF" thing helps. Is it in the Spartan 3? From
Answer 13756 :-

2. Increase the FACTORY_JF setting to 'FFFF. The DCM updates its taps
approximately every twenty input clocks when the "FACTORY_JF" attribute is
set to 0xFFFF. (The default settings of 0xC080h result in updates that occur
much more slowly.) Note that a well-decoupled and stable power supply is the
preferred solution.
Increasing the FACTORY_JF setting may introduce a small amount of jitter
(~30 ps) because the DCM frequently updates its delay line. (This is why
FACTORY_JF is not set to the maximum value by default.) If the power supply
is unstable, the phase error introduced may be much bigger than the extra
jitter introduced; therefore, increasing the FACTORY_JF setting may improve
the design.

Cheers, Syms.
p.s. I see Xilinx have now got a Google search on their website. It seems to
work much better than the regular search!

Quoted text here. Click to load it
phase



Re: Variable phase shift on Spartan3 DCMs. Does it work?
John,

I used to have the numbers written down somewhere.  But that isn't the
point.

I believe it was something like so many clocks (86 seems to be what I
remember from V2)from the CLKIN domain, followed by three clocks in the
PSCLK domain.  It is non-deterministic, hence the reason for the PSDONE
bit:  some shifts do not require all the clocks.  There is basically a
mathematical operation going on here -- we multiply the desired phase
counter serially (8 bits, or a fraction of 256, where 256/256 = one
whole period) by the number of taps presently used ot hold a whole
period.  That then tells us the tap location of the desired phase.

It is recommended (required) that you wait for PSDONE.  In subsequent
versions, there are slight differences in this logic to do the math
(clock cycles per update), so if I told you a number, and you used it,
you would probably break in a future version of the DCM in a new family
(like V4).  Wait for PSDONE, and then everything is gauranteed to work.

I know the simulation model is a rough algorithmic version of what
really happens, but I wouldn't count on it to be the actual
representation of the "right" number of cycles, as it will not behave
like a serial arithmetic multiplier.

So, do not use a fixed number of cycles.  That isn't what we gaurantee.
  We gaurantee that PSDONE tells you that it is done shifting.

It will take fewer clocks (on average, depending on the values of where
the taps are for one full period, and where you are shifting to/from)
than the total number to do the arithmetic, so any number I give you
will change from family to family, and doesn't help anyway (as it
represents the maximum, only).

Austin

John_H wrote:
Quoted text here. Click to load it

Re: Variable phase shift on Spartan3 DCMs. Does it work?
So, bottom line, the simulation might not provide 100% results for PSDONE
but should give a rough approximation.
33 cycles at a CLKIN of 100 MHz may not be enough.
The algorithm Ray Andraka produces should be based on PSDONE for minimum
phase update step size.

Thanks.


Quoted text here. Click to load it



Site Timeline