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

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

Symon,

DSS is gone.

Aust> Ray,

Austin Lesea wrote: 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.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

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?

John, As I said, maybe the "FACTORY_JF" thing helps. Is it in the Spartan 3? From Answer 13756 :-

1. 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!

"John_H" wrote

phase

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

Aust> If the simulation is showing many cycles between the phase_inc or phase_dec

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.