From: Bill Valores on
Hello,

I'm trying to figure out how much delay variance I can achieve using
the variable phase shifter on a Spartan 3E device. I may change the
input frequency if that helps me, and use the CLKFX output as target
clock, so basically I need to figure out how to choose CLKIN wisely to
get an adequate phase shift.

The datasheet and user guide seem to agree on

If CLKIN < 60 MHz: MAX_STEPS = ±[INTEGER(10 •(TCLKIN – 3))]
If CLKIN > 60 MHz: MAX_STEPS = ±[INTEGER(15 •(TCLKIN – 3))]

which is a pretty weird relationship, if I may say so. I can't see why
the clock's frequency would matter at all, since the delay line steps
don't depend on the frequency. The fact that this equation is
discontinuous at 60 MHz doesn't make it look better. What looks even
more weird is that since the minimal input frequency is 5 MHz, we get
MAX_STEPS of ±(10 •(200 – 3)) which is ±1970 steps, or with a 20ps
step size, ±39.4 ns of delay! That is four times longer than the delay
line dedicated for a fixed phase shifting. Or eight times? I'm lost.

But I'm in good company, it seems. Reading the XAPP 485's attached
sample code, auto_phase_align_s3s.v header comment says "Note counters
are long enough (13-bit) for operation down to 5 MHz assuming 25 pS
per tap. (200,000/25=8000)". Looks like someone thought that the FPGA
has a 200 ns delay line. It's getting even more impressive.

The ug331 Spartan 3E user guide offers a hint: Table 3-32 says what
happens in different situations. Among others, there's this situation
labeled "≥ +Limit and < +255" which is commented as "end of delay
line".

So maybe this sums up to that effectively MAX_STEPS could never exceed
±255 steps? That would guarantee a minimal delay swing of ±5.12 ns (if
each delay tap is 20ps) which sounds pretty familiar (the maximal
delay of other Xilinx FPGAs is 5ns, I believe). But sensible as this
sounds to me, I've not been able to find a conclusive statement about
this.

Can anyone shed some light on this?

Thanks in advance,
Bill
From: Patrick Maupin on
On Mar 29, 3:42 pm, Bill Valores <bill.valo...(a)gmail.com> wrote:
> Hello,
>
> I'm trying to figure out how much delay variance I can achieve using
> the variable phase shifter on a Spartan 3E device. I may change the
> input frequency if that helps me, and use the CLKFX output as target
> clock, so basically I need to figure out how to choose CLKIN wisely to
> get an adequate phase shift.
>
> The datasheet and user guide seem to agree on
>
> If CLKIN < 60 MHz: MAX_STEPS = ±[INTEGER(10 •(TCLKIN – 3))]
> If CLKIN > 60 MHz: MAX_STEPS = ±[INTEGER(15 •(TCLKIN – 3))]
>
> which is a pretty weird relationship, if I may say so. I can't see why
> the clock's frequency would matter at all, since the delay line steps
> don't depend on the frequency. The fact that this equation is
> discontinuous at 60 MHz doesn't make it look better. What looks even
> more weird is that since the minimal input frequency is 5 MHz, we get
> MAX_STEPS of ±(10 •(200 – 3)) which is ±1970 steps, or with a 20ps
> step size, ±39.4 ns of delay! That is four times longer than the delay
> line dedicated for a fixed phase shifting. Or eight times? I'm lost.
>
> But I'm in good company, it seems. Reading the XAPP 485's attached
> sample code, auto_phase_align_s3s.v header comment says "Note counters
> are long enough (13-bit) for operation down to 5 MHz assuming 25 pS
> per tap. (200,000/25=8000)". Looks like someone thought that the FPGA
> has a 200 ns delay line. It's getting even more impressive.
>
> The ug331 Spartan 3E user guide offers a hint: Table 3-32 says what
> happens in different situations. Among others, there's this situation
> labeled "≥ +Limit and < +255" which is commented as "end of delay
> line".
>
> So maybe this sums up to that effectively MAX_STEPS could never exceed
> ±255 steps? That would guarantee a minimal delay swing of ±5.12 ns (if
> each delay tap is 20ps) which sounds pretty familiar (the maximal
> delay of other Xilinx FPGAs is 5ns, I believe). But sensible as this
> sounds to me, I've not been able to find a conclusive statement about
> this.
>
> Can anyone shed some light on this?
>
> Thanks in advance,
> Bill

About a year ago, I had to do some fairly fine-grained phase-shifting
to poke at a hardware problem on a chip we build. I used a Nexys2
board (S3E), used Xilinx's equation, and on an 8.192 MHz clock (which
their equation says ought to be able to go +/- 1190 steps, if I read
it right, I just did the "nearest power of two" thing and went +/-
1024 steps. IIRC, the actual step size I measured in the lab was
around 25 ps, and it seemed to be not only monotonic, but also to have
very little variance in the steps.

I had an external PLL creating a 98 MHz clock from the 8.192 MHz by
multiplying by 12, and I could cycle through several periods of the 98
MHz clock with no problem.

My test jig worked flawlessly with no discontinuities. I have no idea
what they do or how they do it, but I have no complaints about that
portion of the datasheet. No, pretty much all my Xilinx complaints
have to do with software rather than hardware, but you don't have
enough time for that...

Regards,
Pat
From: austin on
Bill,

The DCM "fits" a delay line of 256 taps long, to the period of the
clock input signal.

In 3E & 3A, a different architecture was used than in the V2, V2P, 3
and V4, where the taps are always 20 to 40 ps long, and there are
always enough of them to even fit 256 of them to a 5 MHz input clock.

I know, its magic.

Austin






From: austin on
Bill,

Oops. I mean that it has as many taps as required to "fit" a 5 MHz
input clock, not 256 like V2, V2P, 3, and V4....

Magic...

Austin
From: glen herrmannsfeldt on
austin <austin(a)xilinx.com> wrote:

> Oops. I mean that it has as many taps as required to "fit" a 5 MHz
> input clock, not 256 like V2, V2P, 3, and V4....

So as the process gets faster, the number of taps will increase?

(With a margin big enough for process/temperature/voltage variations.)

-- glen