Searching \ for '[EE] NRZ clock extractor PLL, take 2!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/timers.htm?key=clock
Search entire site for: 'NRZ clock extractor PLL, take 2!'.

Exact match. Not showing close matches.
PICList Thread
'[EE] NRZ clock extractor PLL, take 2!'
2011\01\03@210334 by Philip Pemberton

face
flavicon
face
Right then...

I've scanned the current schematic for the Teletext Data Separator from my lab notebook. Here it is in all its scribbly, hand-drawn, chickenscratched glory:
  http://www.philpem.me.uk/temp/ttxpll.pdf

And the ETSI Teletext Specification is here:

http://www.etsi.org/deliver/etsi_i_ets/300700_300799/300706/01_60/ets_300706e01p.pdf

  (FYI: only pages 14 through about 20 are of any interest to this discussion)

For reference, here's what I want to do:

  - I want to take a Teletext-format NRZ data stream and extract the clock, so I can then extract the data stream
  - This is to archive Teletext pages before the digital switch-over. "Archival for posterity". That and it seemed like a fun project (until I started designing the PLL!)
  - Data rate is 6.9375MHz, plus or minus 25ppm.
  - Data packets are 45 bytes long:
    - 3 byte preamble (01010101 01010101 11100100) - even parity
    - 2-byte address (Hamming coded, odd parity)
    - 40 bytes of data (odd parity)
  - The PLL needs to lock by the end of the second preamble byte, ready to receive the framing byte (11100100).

  - I've scrapped the 74HCT4046 PLL I was using, in favour of a Hogge phase detector and VCXO.
  - My VCXO is based on a 74HCT04 and uses a varactor for tuning.
  - The VCXO's frequency ranges from 6.93738MHz (0V across varactor) to 6.93758MHz (5V across varactor). Somewhat asymmetrical, but close to what's required (6.9375MHz at 2.5V is the ideal). The range on this may be a little narrow -- 25ppm is 6.937327MHz to 6.937673MHz.

The problem at the moment is that while the output data and clock are valid (or *look* valid on the scope), the PLL doesn't seem to be locking. The voltage at "VCO Vin" seems to rise and fall in a sawtooth (and a VERY slow one at that) but there doesn't seem to be a point where VCO_Vin stays at one particular value.

My theories at the moment are:
  - The circuit is built on breadboard. Stray track-to-track capacitance is screwing up the loop filter, VCO or both.
  - The VCO range just plain isn't wide enough. Thus, the loop keeps searching, but never hits the right phase/frequency.
  - There isn't enough current going into the varactor to make the frequency change significantly. This seems plausible -- I tested the VCXO by wiring it up to a lab power supply and varying the output voltage.
  - The loop filter just plain isn't right.

Can anyone offer any insight or assistance?

Thanks,
-- Phil.
spam_OUTpiclistTakeThisOuTspamphilpem.me.uk
http://www.philpem.me.uk

2011\01\03@222439 by Marcel Duchamp

picon face
On 1/3/2011 6:03 PM, Philip Pemberton wrote:
> Right then...
>
>     - The loop filter just plain isn't right.
>
> Can anyone offer any insight or assistance?
>
> Thanks,

Nope. Not the least bit.

But... break the loop open at "VCO VIN".  Connect a pot or power supply, etc. to the VCO input and vary it.  Do you get the expected result?

Divide and conquer.  Perhaps the VCO can't slew fast enough for the data rate?  PLL's have lots of parameters and each must be right (obviously).   Go down the list and you will find the problem somewhere probably.

Good luck

2011\01\04@203929 by Philip Pemberton

face
flavicon
face
On 04/01/11 03:25, Marcel Duchamp wrote:
> Divide and conquer.  Perhaps the VCO can't slew fast enough for the data
> rate?  PLL's have lots of parameters and each must be right (obviously).
>    Go down the list and you will find the problem somewhere probably.

I've pretty much written off the VCXO/74LS "hybrid" design. It's not stable, and I fed the VCXO a several-dozen kHz signal only to see it fall to pieces... Nope, not gonna work.

V2.0 is a total redesign using a "digital PLL" of sorts. I have:
  - A DCM to convert the 13.875MHz input clock (2*Fdat) into a much faster 111MHz clock (16*Fdat). This should provide a reasonable amount of phase resolution :)
  - A transition detector picks out the transitions in the incoming data stream -- the bit clock, with the odd missing clock (or 14 in the case of a Clock Cracker stream).
  - A counter which spends most of its life incrementing at 16*Fdat. If a transition is detected (or the counter value reaches 15), it gets reset to 0. A 'sample trigger' pulse is output when the counter value is equal to 7.

Fdat is the data rate, 6.9375MHz.

The transition detector is a 2-bit shift register which stores the last two samples of the data input. A new sample is clocked in at 16*Fdat:
  shiftreg[1] <= shiftreg[0]
  shiftreg[0] <= data_in
If (shiftreg[0] == shiftreg[1]) and (shiftreg[0] != data_in), then a transition occurred and the TRANSITION_DETECTED register is set. Otherwise, TRANSITION_DETECTED is clear.

The counter "is what it is" -- a 5-bit binary counter with asynchronous reset. Think of a 74HC4040, but smaller, and with a pair of fixed-value binary comparators on the output.

It works pretty well -- I rigged the scope to trigger off of SAMPLE_PULSE, set DATA to show full-screen with infinite persistence, and left it running while I made (and drank) a cup of tea. When I came back, there wasn't a single data transition the PLL had missed -- the sample pulse struck right between the samples, plus/minus about 20ns. Close enough to consider "perfect".

Next step: make it work on a Xilinx 9572XL CPLD. 72 macrocells and 34 user I/Os... I wonder if I can fit a small FIFO in there too... hmm...

-- Phil.
.....piclistKILLspamspam@spam@philpem.me.uk
http://www.philpem.me.uk

2011\01\04@211200 by Oli Glaser

flavicon
face
On 04/01/2011 02:03, Philip Pemberton wrote:
> The problem at the moment is that while the output data and clock are
> valid (or*look*  valid on the scope), the PLL doesn't seem to be
> locking. The voltage at "VCO Vin" seems to rise and fall in a sawtooth
> (and a VERY slow one at that) but there doesn't seem to be a point where
> VCO_Vin stays at one particular value.
>
> My theories at the moment are:
>     - The circuit is built on breadboard. Stray track-to-track
> capacitance is screwing up the loop filter, VCO or both.
>     - The VCO range just plain isn't wide enough. Thus, the loop keeps
> searching, but never hits the right phase/frequency.
>     - There isn't enough current going into the varactor to make the
> frequency change significantly. This seems plausible -- I tested the
> VCXO by wiring it up to a lab power supply and varying the output voltage..
>     - The loop filter just plain isn't right.

If you hadn't said the sawtooth waveform was very slow, I would have suggested maybe the feedback is reacting too fast and therefore just oscillating between min/max values. A (larger) RC filter on the VCO input would probably help there if that was the case.
Judging from your last mail though, it seems the problem has been solved?
If so, good stuff (PLLs are fiddly things at the best of times so well done) Out of interest though (and for others benefit in the future) what exactly did you change and did you pin down the original problem?


2011\01\05@065751 by Philip Pemberton

face
flavicon
face
On 05/01/11 02:11, Oli Glaser wrote:
> Judging from your last mail though, it seems the problem has been solved?
> If so, good stuff (PLLs are fiddly things at the best of times so well
> done) Out of interest though (and for others benefit in the future) what
> exactly did you change and did you pin down the original problem?

I have no idea why the original PLL wouldn't lock, and I don't intend to try using an analogue PLL for clock extraction again...

The 'new' design (the counter-and-transition-detector pseudo-PLL) works across a rather wide input frequency range -- I've had it running from 6.5 to 7.5MHz. Considering the specification is 6.9375MHz +/- 25ppm, that seems pretty good, and far more than is required.

At the moment I'm waiting for a couple of TI CDCE925 PLL synthesizers to arrive -- these chips connect to a clock crystal and have two onboard PLL multipliers and five onboard dividers. They're programmed over I2C, and the max output frequency is over 200MHz... If memory serves, they're sold as clock drivers for the TI DaVinci and Omap processors, but going by the datasheet they'll work just as well for FPGAs.

The other option would be to get a custom-made TTL oscillator module... I'd rather not go down that road, those things tend to get expensive, and I already have a bag full of 13.875MHz 18pF crystals (2*6.8375MHz). The TI PLL chip is nonvolatile (EEPROM), field reprogrammable (I2C), and has a built in crystal oscillator and programmable xtal load capacitor. It's as close to a 'no parts' product as you can reasonably expect to get... even to the point where the software does almost all the design work for you. "Magic."

-- Phil.
piclistspamKILLspamphilpem.me.uk
http://www.philpem.me.uk

2011\01\05@082103 by Oli Glaser

flavicon
face
On 05/01/2011 11:57, Philip Pemberton wrote:
> At the moment I'm waiting for a couple of TI CDCE925 PLL synthesizers to
> arrive -- these chips connect to a clock crystal and have two onboard
> PLL multipliers and five onboard dividers. They're programmed over I2C,
> and the max output frequency is over 200MHz... If memory serves, they're
> sold as clock drivers for the TI DaVinci and Omap processors, but going
> by the datasheet they'll work just as well for FPGAs.

Good choice, I should/would have mentioned something like that if I wasn't so rushed at the moment - I am using a CDCE706 on my PIC18/FPGA board I mentioned before - works very nicely indeed. TI make some great, reasonably priced timing solution ICs - IIRC there was one I was looking at in that family (I think) that will lock on to a clock and you can select phase shift/frequency multiplication etc very accurately (it's possible that would have done the job for you - will let you know if I recall the part no, think it was a CDCxxxx something on RS/Farnell - definitely a TI chip)
NI make some really good timing ICs too - I just got some samples from them for my scope proto board, very impressive specs but (for the ones I got) expensive too. I know they do some similar (cheaper) ones too though that are worth checking out for varying demands/prices (speed/delay/no of outputs/CMOS/LVDS etc)

2011\01\05@191713 by Philip Pemberton

face
flavicon
face
On 05/01/11 13:20, Oli Glaser wrote:

[re TI CDCE925 clock gen]

> Good choice, I should/would have mentioned something like that if I
> wasn't so rushed at the moment - I am using a CDCE706 on my PIC18/FPGA
> board I mentioned before - works very nicely indeed.

Always nice to know the 'sister chip' works nicely. Hopefully its big brother will work just as well :)

I did find it curious that the list price on the 925 is less than the 913 (the same chip with fewer PLLs and dividers)... Hm. Not that I'm grumbling of course! :)

> NI make some really good timing ICs too - I just got some samples from
> them for my scope proto board, very impressive specs but (for the ones I
> got) expensive too. I know they do some similar (cheaper) ones too
> though that are worth checking out for varying demands/prices
> (speed/delay/no of outputs/CMOS/LVDS etc)

NI as in National Instruments? The GPIB guys?

Or do you mean National Semiconductor (NSC)?

-- Phil.
.....piclistKILLspamspam.....philpem.me.uk
http://www.philpem.me.uk

2011\01\05@222349 by Oli Glaser

flavicon
face
On 06/01/2011 00:16, Philip Pemberton wrote:
>> NI make some really good timing ICs too - I just got some samples from
>> >  them for my scope proto board, very impressive specs but (for the ones I
>> >  got) expensive too. I know they do some similar (cheaper) ones too
>> >  though that are worth checking out for varying demands/prices
>> >  (speed/delay/no of outputs/CMOS/LVDS etc)
> NI as in National Instruments? The GPIB guys?
>
> Or do you mean National Semiconductor (NSC)?

Doh! there goes my brain again... :-)
I did mean National Semiconductor yes - just checked and the samples I got are part of the LMK range (LMK04000) so it was that family I was thinking of, and the LMX range.
I think possibly the LMX range is more what you might be looking for at the moment - the LMK range are precision jitter cleaners/clock generators/conditioners targeted mainly at e.g. high speed ADCs ( the adjustable ps delay, fs jitter and stuff is what I am interested in)
Both ranges are worth checking out though, plus there are a few app notes on PLLs and Clock/Timing issues:
http://www.national.com/analog/timing_clocking#appnotes

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...