Prev: Free VHDL or Verilog Simulator
Next: Spartan 6 PLL - Why such a strict input jitter requirement?
From: John_H on 29 Mar 2010 23:37
On Mar 29, 6:06 pm, austin <aus...(a)xilinx.com> wrote:
> 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

Austin - are you up on your Spartan3E variable phase shift trivia?

There is unfortunately no 256-tap fit (for the variable phase shift,
at least). The variable phase shift is a tap-by-tap adjustment unlike
most every other family out there which did the 256 tap "fit" properly
even if it took more than one inc or dec to change taps. The limits
defined by the data sheet ended up being a very unusual set of numbers
and is enough to make an engineer sweat about whether they'll be able
to get the phase shift they want. I was happy to get the 3 bit
periods of phase adjustment out of the 300 MHz multiplied clock (based
off a 50MHz reference). But what a wild ride that was! I ended up
with correspondence directly with the silicon designer when the phase
inc/dec update started ignoring commands on occasion.

So, Bill - word of caution... If you use the variable phase shift and
consider the "about 100 clocks" to make sure the adjustment occurs -
or similarly worded metric - you may have occasion where the
adjustment doesn't happen or at least for a duration much longer than
expected. I ended up with a timeout count such that if I didn't get
an ack after a certain period of time, I retried the adjustment.
Sadly, I forget what the final implementation included, whether the
timeout was still the way to go or if there was a "real" solution.
From: Bill Valores on 30 Mar 2010 07:14
Thank you for your answers.

I take it that they're serious about having some 4000 taps. Also, I
keep hearing (reading, actually) about the variable phase shifter
taking a long time to acknowledge its commands. Make me wonder why,
since all we're asking for is "what you did right now, just another
tap".

I wish someone revealed what really goes on there, and how they
reached those peculiar equations. All this feels like witchcraft.

I'm going to experiment a bit. The problem is that my experiments will
be on a stepping 0 FPGA, while the target board will have a stepping 1
high speed grade chip. With all this mystery, I wonder if that's going
to make a difference (and they obviously did something with the DCM
between the steppings).

Bill.
From: Patrick Maupin on 30 Mar 2010 09:30
On Mar 30, 6:14 am, Bill Valores <bill.valo...(a)gmail.com> wrote:
> Thank you for your answers.
>
> I take it that they're serious about having some 4000 taps. Also, I
> keep hearing (reading, actually) about the variable phase shifter
> taking a long time to acknowledge its commands. Make me wonder why,
> since all we're asking for is "what you did right now, just another
> tap".
>
> I wish someone revealed what really goes on there, and how they
> reached those peculiar equations. All this feels like witchcraft.
>
> I'm going to experiment a bit. The problem is that my experiments will
> be on a stepping 0 FPGA, while the target board will have a stepping 1
> high speed grade chip. With all this mystery, I wonder if that's going
> to make a difference (and they obviously did something with the DCM
> between the steppings).
>
> Bill.

$179.00 gets you a XC3S1200E on a Digilent Nexys2 board. Add 30 bucks
or so for overnight shipping, and I don't know why you have to be on a
different stepping...

Regards,
Pat
From: Bill Valores on 30 Mar 2010 11:28
You definitely have a point there. With a board on my table (which I
obviously have everything set up with) I didn't even think in that
direction. Now it's my laziness and having a lot of handy
communication features with the current board vs. the risk that the
test won't be valid.

Plus the fact that the clock source will be the same on my board and
the one I'm targeting. I understand that clock jitter has been a
primary suspect where problems have arisen.

I guess I'll start with my board and see how stable this feels.

Thanks,
Bill

On Mar 30, 3:30 pm, Patrick Maupin <pmau...(a)gmail.com> wrote:
>
> $179.00 gets you a XC3S1200E on a Digilent Nexys2 board.  Add 30 bucks
> or so for overnight shipping, and I don't know why you have to be on a
> different stepping...
>
> Regards,
> Pat

From: Bill Valores on 31 Mar 2010 13:53
Hi again,

Impatient as I am, I went for testing the variable phase shifter on
the existing board. I ran on a xc3s1600e-4 stepping 0, which is not
what I'll have in the end, but the results were so encouraging, that I
feel pretty safe to jump to another device with no further checks.

I wrote a small Verilog module (the "state machine" below), which
sends shift commands in order to reach a certain position, which I set
through some register interface. Given that I wrote the module right
(which it seems like I did), I could arbitrarily jump to any position
I liked, just by changing the register. I had the shifted clock and a
reference clock wired to a testpoint, and I also had a signal going
high whenever my state machine was between PSEN and PSDONE (that is,
waiting). The latter turned out very interesting.

So I fed the DCM with a 5 MHz clock (minimal frequency) and started
playing around. Things went very smooth as long as I remained within
the per-spec ±1970 steps boundary. In my case I got around 22.75ps per
step (measured by jumping 1000 steps or so) consistently. I thought
this number was absurd, but it turned out to be true: The chip allows
±39.4 ns of delay. That's a useful rail of nearly 80 ns. Pretty
impressive.

But I didn't stop there. I went for larger shifts until things started
to break. ±4000 was OK. When I tried 4500 in either direction, hell
broke lose. The most interesting thing was that the state machine was
waiting for PSDONE. I didn't look deeply into how much time each PSEN-
PSDONE cycle took, but it appeared long, random, and sometimes
completely stuck. In one occasion, the state machine waited for quite
a while, and then suddenly the "waiting" line went low again. On the
scope I saw a 2.5 MHz clock on the DCM's output (the original
frequency divided by two).

This random behavior appears suspiciously similar to reports I've read
from people who said that the PSDONE came much later than expected.
Which makes me think (or hope?) that their problem was in their own
logic, which accidentally pushed the phase shifter beyond its limit.

Another interesting thing about this result, is that the region of
4000-4500 steps is where the extra delay gets close to half a clock
cycle. On the scope, it was pretty evident that things started to go
wrong when the shifted clock got close to a 180 degree shift. And this
might explain the rule allowing 10 steps (0.4 ps at most) for each ns
of cycle period on the shifted clock. As for those extra 3ns, I
suppose there's a reason as well.

I tried this again with a 33.3 MHz input clock. The behavior was the
same. Hell broke lose when the shifting reached half a clock cycle.

In short, all this starts to make sense to me. This looks like "follow
the spec and everything will be all right". The bottom line is that
the datasheet was right, and the user guide was confusing.

Thanks again for your answers. You really were helpful.
Bill.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Free VHDL or Verilog Simulator
Next: Spartan 6 PLL - Why such a strict input jitter requirement?