Prev: Free VHDL or Verilog Simulator
Next: Spartan 6 PLL - Why such a strict input jitter requirement?
From: Patrick Maupin on 31 Mar 2010 14:55
On Mar 31, 12:53 pm, Bill Valores <bill.valo...(a)gmail.com> wrote:

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

It sounds very much like what I built.

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

I didn't try to stress it to breaking, but I never saw any problems,
and we did lots of lab work over a couple of months.

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

I think the user guide may have too much leftover S3 DCM info (which
is way different than S3E DCM).

> Thanks again for your answers. You really were helpful.

Glad to hear it! Thanks for letting me know you're up and running.

Regards,
Pat
From: John_H on 31 Mar 2010 15:13
On Mar 31, 1:53 pm, Bill Valores <bill.valo...(a)gmail.com> wrote:
>
> 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.

You stated earlier that "I understand that clock jitter has been a
primary suspect where problems have arisen."

That jolted a couple brain cells loose. Jitter on the 50 MHz
reference clock was the problem in our system prototype across the
country (a problem we never had locally with a different front-end
transmitter). When the problem was isolated further down, the clock
quality was identified as a strong issue. A couple changes were made
on the board providing the 50 MHz reference clock (and three
communications links tied to it) to make it a much cleaner version of
its earlier self and the problems with PSDONE coming in late (or
never) went away. I'm certain the PSDONE detection logic was fine (it
was even reworked a few times to try to figure things out) and the
limits of the phase shift were not at issue.

When I did have the poor quality clock and the PSDONE response was
persnickety, I set up a BlockRAM counter to enumerate the number of
instances of the PSDONE taking N cycles to report, N being from 1 to
512. I recall the trend being logarithmic. When I plotted the data I
used a log scale to deal with the wide range of counts. The plot was
roughly a staircase with a linear (on the log graph) trend. Several
delay times would be approximately the same count of instances, then
markedly fewer for several more similar counts, and so on down the
logarithmic staircase. With the jitter problem fixed, the response
from the PSDONE was fixed as well.

Happy shifting!
From: Patrick Maupin on 31 Mar 2010 16:36
On Mar 31, 2:13 pm, John_H <newsgr...(a)johnhandwork.com> wrote:
> On Mar 31, 1:53 pm, Bill Valores <bill.valo...(a)gmail.com> wrote:
>
>
>
> > 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.
>
> You stated earlier that "I understand that clock jitter has been a
> primary suspect where problems have arisen."
>
> That jolted a couple brain cells loose.  Jitter on the 50 MHz
> reference clock was the problem in our system prototype across the
> country (a problem we never had locally with a different front-end
> transmitter).  When the problem was isolated further down, the clock
> quality was identified as a strong issue.  A couple changes were made
> on the board providing the 50 MHz reference clock (and three
> communications links tied to it) to make it a much cleaner version of
> its earlier self and the problems with PSDONE coming in late (or
> never) went away.  I'm certain the PSDONE detection logic was fine (it
> was even reworked a few times to try to figure things out) and the
> limits of the phase shift were not at issue.
>
> When I did have the poor quality clock and the PSDONE response was
> persnickety, I set up a BlockRAM counter to enumerate the number of
> instances of the PSDONE taking N cycles to report, N being from 1 to
> 512.  I recall the trend being logarithmic.  When I plotted the data I
> used a log scale to deal with the wide range of counts.  The plot was
> roughly a staircase with a linear (on the log graph) trend.  Several
> delay times would be approximately the same count of instances, then
> markedly fewer for several more similar counts, and so on down the
> logarithmic staircase.  With the jitter problem fixed, the response
> from the PSDONE was fixed as well.
>
> Happy shifting!

yeah, whether you're using dynamic phase shift or not, experience has
shown me that Xilinx DLLs and DCMs can be exceptionally unhappy if you
are not giving them a clean clock. If the 1ns max jitter figure
bandied about in another thread is any indication, this may still be
true even with the new PLL-based architecture. For clocks of unknown
provenance, I usually use a PLL in front of the FPGA to clean the
clock, and use some separate FPGA logic on a local oscillator to
monitor the DCM locked indicator and reset the DCM if there are
issues. In the past, I have used Cypress RoboClocks and InstaClocks
for pre-FPGA jitter cleanup. On my last design, I actually used one
of my own company's (different division's) parts (the ZL30132) which
was, admittedly, overkill for what I needed, but was effectively free
for me (and it seems to work quite well, to boot).

Regards,
Pat
From: -jg on 31 Mar 2010 17:19
On Apr 1, 5:53 am, Bill Valores <bill.valo...(a)gmail.com> wrote:
> 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.

Going outside the limits can be very useful.
* It confirms the limit is correctly understood
* it gives useful insight, into failure modes, and thus
a place to look, should issues appear later.
* Knowing what something cannot do, often gives more
insight, than knowing what it can do :)

Vendors should do more of this, and providing a piece of test/example/
exercise code like you have done, is something they should all be
encouraged to do.

-jg
From: Patrick Maupin on 31 Mar 2010 19:47
On Mar 31, 4:19 pm, -jg <jim.granvi...(a)gmail.com> wrote:

> Going outside the limits can be very useful.
> * It confirms the limit is correctly understood
> * it gives useful insight, into failure modes, and thus
>   a place to look, should issues appear later.
> * Knowing what something cannot do, often gives more
> insight, than knowing what it can do :)

Absolutely agreed; "play time" is when most learning occurs.

> Vendors should do more of this, and providing a piece of test/example/
> exercise code like you have done, is something they should all be
> encouraged to do.

Xilinx sometimes is reluctant to disclose how or why things work, so
good luck with your campaign of getting them to disclose how or why
things DON'T work. A big company finds it easy to find the downside
in a disclosure ("Altera will figure out our weaknesses and explain
them to customers; patent trolls will notice that we are infringing
their putative IP.") often without noticing the simple upside that an
informed customer is a happy customer.

Pat
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?