Connect with us

10BASE-T Clock Recovery PLL

Discussion in 'Electronic Design' started by Andrew Holme, Jun 6, 2004.

Scroll to continue with content
  1. Andrew Holme

    Andrew Holme Guest

  2. Thanks Andrew
    Thats just what i wanted, line drivers for CAT5 cable, but hadn't got
    around to googling yet!
    I'm not using it for ethernet, just loads of digital audio!



    martin

    Serious error.
    All shortcuts have disappeared.
    Screen. Mind. Both are blank.
     
  3. Mike

    Mike Guest

    I don't think your problem is with your charge pump transistors.

    I'm assuming the upper trace in your scope photo is your loop filter
    voltage. If it is, then you have at least two problems.

    1. At the start of the preamble, the voltage on your loop filter is hitting
    its limit. As soon as it limits, the loop response is no longer linear.

    2. At the end of the data, the loop is losing lock when it hits the
    checksum. If it loses lock at the checksum, it will lose lock when you
    replace the 0x55 data with real data. Your phase detector is supposed to
    handle nonuniform data, but it looks as though it's not.

    I have two suggestions:

    1. Since you've got some programming experience, why not write a
    time-domain simulator for your PLL? It's not that difficult, and with your
    C++ knowledge, you can create classes for the phase detector, charge pump,
    loop filter, and VCO. Adding nonlinearities is relatively easy, so you can
    include saturation effects and such. Start with ideal models for the logic
    and loop filter, and spend your time creating more detailed models for the
    charge pump and VCO.

    2. There is an initial frequency offset in your system which your step
    response is ignoring. The actual input has a ramp (frequency error) in
    addition to a step (phase error). The slope of the ramp is proportional to
    the frequency offset: larger frequency errors will result in longer lock
    times.

    Data recovery systems like this are typically implemented with a reference
    clock, which provides a frequency close to the data frequency until data
    begins arriving. When the preamble begins, the PLL reference is switched
    from the reference clock to the data. In many designs, the VCO is stopped
    during the switchover time, then restarted in phase with the data. The
    effect is that the initial frequency and phase errors are small, so the
    loop can lock quickly.

    -- Mike --
     
  4. Jim Thompson

    Jim Thompson Guest

    See also "DualD-PFD.pdf" on the S.E.D/Schematics page of my website
    for a more robust clearing method.

    ...Jim Thompson
     
  5. Mike

    Mike Guest

    In the PFD thread a week or so ago, Mike Monett made the claim:

    My reply was:

    Did you run into the same problem? It sure seems like there should be
    enough prop-delay around the loop to guarantee that both flops get reset,
    but the effects of failure are pretty obvious (and pretty catastrophic when
    you're trying to lock quickly). For me, it showed up in a mature product,
    in a very mature IC process, that had been shipping for over five years.
    You'd think by that time we'd have seen every possible variation...

    I implemented the same concept; in ECL, the AND and SR flop can all be
    combined into one compact and relatively fast gate.

    -- Mike --
     
  6. Mike Monett

    Mike Monett Guest

    Mike, Google news was down recently, so I was unable to reply to that
    thread.

    Yes, of course I have had bizarre failures with existing ecl products
    also. But these were layout problems or device failures, not
    fundamental design issues. In the case of the phase/frequency detector
    under discussion, I would not change the design. Besides, there's not
    much you can do with it anyway:)
    Did you change the design, or tweak the process to get it working
    again?
    Mike
     
  7. Mike

    Mike Guest

    This wasn't a layout or device failure. Every part failed, in a customer's
    high volume production line. The problem was with the PFD, and you wouldn't
    change the design? What *would* you do?
    As I said in the next sentence, we changed the design.

    -- Mike --
     
  8. Mike Monett

    Mike Monett Guest

    Gee Mike, you went from a mature, working product to 100% failure?
    Scary...

    What was different about the customer's usage from previous customers?

    Was this the standard dual-D (or 5 NANDS PFD), or a different design?

    Did you have a dedicated tester for the pll, and could you duplicate
    the failure? (By dedicated tester, I mean did you have a way to lock
    up the pll to a stream of clocks, then vary one bit over a suitable
    range to view the response of the pll?)

    What caused the failure, and what did you do to fix it?

    Mike
     
  9. John Miles

    John Miles Guest

    Neat stuff! I'm about to document a new large-scale project, and your
    pages (along with the http://www.fpga4fun.com/ page you linked to) are
    providing some good inspiration.

    -- jm
     
  10. Mike

    Mike Guest

    It was a standard DFF PFD. As I've pointed out twice, the fix was to
    implement a circuit similar to Jim's. If you look at his, you'll find that
    the reset occurs when UP and DN are both high, but it only goes away when
    they are _both_ low.

    Compare that with the operation of a standard PFD, and the problem will
    become clear.

    -- Mike --
     
  11. Andrew Holme

    Andrew Holme Guest

Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-