Clock Recovery

[Robert G. Kaimer Jr.]

I have what seems to be a simple problem, but after a month's work I'm
at a total loss. I need to recover the clock (and resample data) from a
256 kHz data stream in an FPGA. Eventually I'll need to recover
different data rates and types, but right now it's just 256 kHz NRZ. (I
have an 8.192 MHz system clock.) The incoming data is not pristine by
any means, but I'm having a hard time just generating a stable clock
based on it.

Is anyone familiar with a good way to approach this? Thanks in advance
for your time.

Bob

 

[Jonathan Bromley]

On Thu, 23 Aug 2007 04:35:43 GMT, "Robert G. Kaimer Jr."
<rkaimer1@frontiernet.net> wrote:

I have what seems to be a simple problem, but after a month's work I'm
at a total loss. I need to recover the clock (and resample data) from a
256 kHz data stream in an FPGA. Eventually I'll need to recover
different data rates and types, but right now it's just 256 kHz NRZ. (I
have an 8.192 MHz system clock.) The incoming data is not pristine by
any means, but I'm having a hard time just generating a stable clock
based on it.

It's not necessarily a simple problem. However, your data rate is
slow enough to permit quite extensive filtering and oversampling,
so there should be no insuperable obstacles. Tell us more about
the data format (for example, how long can you go without seeing
a transition?) and the statistics of the "not pristine" data (how
much clock jitter? how much pulse width distortion due to asymmetry
between rise and fall delays? are the edges clean, or do they
thrash around close to a transition? do you get noise spikes
and/or glitches?).
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Robert G. Kaimer Jr. wrote:

I have what seems to be a simple problem, but after a month's work I'm
at a total loss. I need to recover the clock (and resample data) from a
256 kHz data stream in an FPGA.

The problem with NRZ is that there can be
unlimited bursts of all one or zero with
no transitions.

I would use the system clock to measure
the pulse widths and recover the bitstream
data to start with.

-- Mike Treseler

 

[mk]

On Thu, 23 Aug 2007 04:35:43 GMT, "Robert G. Kaimer Jr."
<rkaimer1@frontiernet.net> wrote:

I have what seems to be a simple problem, but after a month's work I'm
at a total loss. I need to recover the clock (and resample data) from a
256 kHz data stream in an FPGA. Eventually I'll need to recover
different data rates and types, but right now it's just 256 kHz NRZ. (I
have an 8.192 MHz system clock.) The incoming data is not pristine by
any means, but I'm having a hard time just generating a stable clock
based on it.

Is anyone familiar with a good way to approach this? Thanks in advance
for your time.

Bob

With just the two clock speeds you mention it's relatively easy. The
basic idea is to find where the edges are and then sample at the
middle of the bit. So you come up with an estimate of where the edge
is (say oversample by 20 & average a number of edge locations (from 0
to 19) to get your initial estimate) and then over time update your
estimate of the edge location based on an pseudo LS calculation. One
solution might be to generate an error based on where your estimate is
and where you see the new edge and filter this error with a PI or PID
controller and apply it to update your estimate. Once you have an
error how much and what kind of filtering you need to do depends
completely on input jitter, your jitter rejection & tracking
requirements.

 

[Jonathan Bromley]

On Thu, 23 Aug 2007 09:58:29 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

The problem with NRZ is that there can be
unlimited bursts of all one or zero with
no transitions.

But surely all practical comms schemes that use NRZ
line discipline (CANbus, for example) always have
some kind of bit-stuffing or framing arrangements
to ensure that there is an upper limit on the time
between transitions?

I would use the system clock to measure
the pulse widths and recover the bitstream
data to start with.

My personal experience is that digital-PLL schemes
are usually somewhat simpler than measurement schemes.
But it is often necessary to treat rising and falling
edges separately, because of rise/fall asymmetry in
the physical communications link. The OP has 32x
oversampling, which makes it easy for him to do
glitch filtering, digital PLL, and compensation for
rise/fall timing differences.

I still say, though, that we need some more information
about the problem environment. Strange that the OP has
not yet come back with some more details.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Allan Herriman]

On Fri, 24 Aug 2007 09:19:23 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Thu, 23 Aug 2007 09:58:29 -0700, Mike Treseler
mike_treseler@comcast.net> wrote:

The problem with NRZ is that there can be
unlimited bursts of all one or zero with
no transitions.

But surely all practical comms schemes that use NRZ
line discipline (CANbus, for example) always have
some kind of bit-stuffing or framing arrangements
to ensure that there is an upper limit on the time
between transitions?

SONET is a practical comms scheme that uses NRZ line discipline. It
uses scrambling to improve bit transition density. Of course, with a
zero overhead encoding scheme there is no guarantee of any particular
run length. A run length of 72 is usually taken as the worst case for
design purposes.
There are framing signals in the bit stream but they can be more than
100k bits apart in the higher speed interfaces, meaning that they
can't be relied upon to affect the run length.


BTW, a long run length causes the jitter specifications to be much
tighter, leading to a cost penalty vs otherwise similar interfaces
(e.g. 10Gb/s SONET vs 10Gb/s Ethernet).


Regards,
Allan

 

[Mike Treseler]

Jonathan Bromley wrote:

But surely all practical comms schemes that use NRZ
line discipline (CANbus, for example) always have
some kind of bit-stuffing or framing arrangements
to ensure that there is an upper limit on the time
between transitions?

Yes, but as you say, Robert has given us none
of these details. My comments were an unsuccessful
nudge for more information. I suspect that his actual
objective is not to generate a clock, but
to decode the data.

I still say, though, that we need some more information
about the problem environment. Strange that the OP has
not yet come back with some more details.

I can only speculate.
I expect that he has solved the problem
and is perhaps embarrassed for having asked.
Which is too bad, because it sounded like
an interesting problem.


-- Mike Treseler

 

[Jonathan Bromley]

On Sat, 25 Aug 2007 03:52:16 +1000,
Allan Herriman <allanherriman@hotmail.com> wrote:

SONET is a practical comms scheme that uses NRZ line discipline. It
uses scrambling to improve bit transition density.

Cool. I didn't know that.

A run length of 72 is usually taken as the worst case for
design purposes.

At 10Gb/s, with the bitstream randomized by the scrambling,
a run length of 72 or more will (by my somewhat flaky
probability calculations) occur roughly once every 30,000
YEARS.... Sounds like pretty conservative design to me!

Presumably SONET also includes some kind of error recovery
mechanism? (Please humour me, I'm totally ignorant about
SONET and similar big-budget telecomms protocols.)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Allan Herriman]

On Sat, 25 Aug 2007 15:31:21 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Sat, 25 Aug 2007 03:52:16 +1000,
Allan Herriman <allanherriman@hotmail.com> wrote:

SONET is a practical comms scheme that uses NRZ line discipline. It
uses scrambling to improve bit transition density.

Cool. I didn't know that.

A run length of 72 is usually taken as the worst case for
design purposes.

At 10Gb/s, with the bitstream randomized by the scrambling,
a run length of 72 or more will (by my somewhat flaky
probability calculations) occur roughly once every 30,000
YEARS.... Sounds like pretty conservative design to me!

Presumably SONET also includes some kind of error recovery
mechanism? (Please humour me, I'm totally ignorant about
SONET and similar big-budget telecomms protocols.)

It will drop out then reframe after some ms. This will happen every
now and then (although probably not in the lifetime of the product,
because the probability is quite low as you noted).

When SONET was first envisioned, the composite data stream was made up
by byte interleaving tributaries. The tributaries in turn were were
made up of byte interleaving 64kb/s voice data channels (e.g. E1/DS1,
E3/DS3, etc.).
Each of these channels was independent, so it was basically impossible
to mount a denial of service attack by putting the inverse of the
scrambler sequence in any given channel.
The SONET designers used a (tiny) 7 bit scrambler as it seemed
adequate.

Later (e.g. 1990s), SONET was used to carry to carry bulk data. E.g.
RFC 1619 (Packet over SONET, 1994) maps HDCL frames directly into the
SPE, which in essence means that entire packets (up to 64kbytes) can
appear directly on the fibre with nothing other than the weak
scrambler to improve transition density.

The designers realised their mistake, and RFC 2615 replaced RFC 1619
in 1999. The change added a 43 bit scrambler to the HDLC data before
it was mapped to the SPE:


"The major change from RFC 1619 is the addition of payload
scrambling when inserting the HDLC-like framed PPP packets
into the SONET STS-SPE/SDH Higher Order VC. RFC 1619 was
operationally found to permit malicious users to generate
packets with bit patterns that could create SONET/SDH-layer
low-transition-density synchronization problems, emulation
of the SDH set-reset scrambler pattern, and replication of
the STM-N frame alignment word."


More modern formats (e.g. GFP, which is like POS, but has more useful
header information) retain the 43 bit scrambler.

http://www.ietf.org/rfc/rfc1619.txt
http://www.ietf.org/rfc/rfc2615.txt

Regards,
Allan

 

[Robert G. Kaimer Jr.]

My apologies. An emergency at home took me away from work for a few days
and I am just getting back up to speed.

The system in question is a redesign for a custom gate array, the
manufacturer of which has left the business. Our documentation is scant
and we are trying to work within the original requirements of the system
as a whole, which doesn't place any requirements on the received data
other than rate and type.

Looking at the original system, I've noted that the received data is
much "cleaner" than on the new card, which has started an internal
disagreement about most of what you have questioned.

Once I get some resolution on what I have to work with, I'll be back
with an update. My thanks again to all for your comments thus far.


Bob


Mike Treseler wrote:

Jonathan Bromley wrote:

But surely all practical comms schemes that use NRZ
line discipline (CANbus, for example) always have
some kind of bit-stuffing or framing arrangements
to ensure that there is an upper limit on the time
between transitions?

Yes, but as you say, Robert has given us none
of these details. My comments were an unsuccessful
nudge for more information. I suspect that his actual
objective is not to generate a clock, but
to decode the data.

I still say, though, that we need some more information
about the problem environment. Strange that the OP has
not yet come back with some more details.

I can only speculate.
I expect that he has solved the problem
and is perhaps embarrassed for having asked.
Which is too bad, because it sounded like
an interesting problem.


-- Mike Treseler

 

[colin]

"mk" <kal*@dspia.*comdelete> wrote in message
news:8tgrc3d377mpg24luaf4pfpmqihhmaqord@4ax.com...

On Thu, 23 Aug 2007 04:35:43 GMT, "Robert G. Kaimer Jr."
rkaimer1@frontiernet.net> wrote:

I have what seems to be a simple problem, but after a month's work I'm
at a total loss. I need to recover the clock (and resample data) from a
256 kHz data stream in an FPGA. Eventually I'll need to recover
different data rates and types, but right now it's just 256 kHz NRZ. (I
have an 8.192 MHz system clock.) The incoming data is not pristine by
any means, but I'm having a hard time just generating a stable clock
based on it.

Is anyone familiar with a good way to approach this? Thanks in advance
for your time.

Bob

With just the two clock speeds you mention it's relatively easy. The
basic idea is to find where the edges are and then sample at the
middle of the bit. So you come up with an estimate of where the edge
is (say oversample by 20 & average a number of edge locations (from 0
to 19) to get your initial estimate) and then over time update your
estimate of the edge location based on an pseudo LS calculation. One
solution might be to generate an error based on where your estimate is
and where you see the new edge and filter this error with a PI or PID
controller and apply it to update your estimate. Once you have an
error how much and what kind of filtering you need to do depends
completely on input jitter, your jitter rejection & tracking
requirements.

divide the main clock to give you a clock wich is close,
then when ever you get a data transition determine the phase relative to
that clock
accumulate the error and add the average as a phase offset to the divided
clock,
ofc you also have to adjust the divisor too so that the phase offset keeps
within limits.

you might need fractional divison for the clock,
ie change the divisor by +-1 cycle by cycle.

Colin =^.^=

 

[Robert G. Kaimer Jr.]

I certainly didn't expect all this help. I really do appreciate it.

One thing our Sr. Scientist mentioned is AVTS, or Absolute-Value
Tracking Symbol Synchronization. He employed it once years ago, but the
hardware at the time couldn't support the speed he needed so he ended up
working values out by hand and storing them in PROM. He doesn't remember
exactly how he did the calculations.

I'm not discounting any of the suggestions made so far, but has anyone
had any experience with this?

Thanks,
Bob



Robert G. Kaimer Jr. wrote:

I have what seems to be a simple problem, but after a month's work I'm
at a total loss. I need to recover the clock (and resample data) from a
256 kHz data stream in an FPGA. Eventually I'll need to recover
different data rates and types, but right now it's just 256 kHz NRZ. (I
have an 8.192 MHz system clock.) The incoming data is not pristine by
any means, but I'm having a hard time just generating a stable clock
based on it.

Is anyone familiar with a good way to approach this? Thanks in advance
for your time.

Bob

 

[Robert G. Kaimer Jr.]

This sounds closest to what I've been trying so far. I'm getting
reasonable values out of the filter that averages the errors, but
something goes south when I try to recreate the clock. I think part of
my problem is confusion regarding whether an edge is early or late.


colin wrote:

"mk" <kal*@dspia.*comdelete> wrote in message
news:8tgrc3d377mpg24luaf4pfpmqihhmaqord@4ax.com...
On Thu, 23 Aug 2007 04:35:43 GMT, "Robert G. Kaimer Jr."
rkaimer1@frontiernet.net> wrote:

I have what seems to be a simple problem, but after a month's work I'm
at a total loss. I need to recover the clock (and resample data) from a
256 kHz data stream in an FPGA. Eventually I'll need to recover
different data rates and types, but right now it's just 256 kHz NRZ. (I
have an 8.192 MHz system clock.) The incoming data is not pristine by
any means, but I'm having a hard time just generating a stable clock
based on it.

Is anyone familiar with a good way to approach this? Thanks in advance
for your time.

Bob
With just the two clock speeds you mention it's relatively easy. The
basic idea is to find where the edges are and then sample at the
middle of the bit. So you come up with an estimate of where the edge
is (say oversample by 20 & average a number of edge locations (from 0
to 19) to get your initial estimate) and then over time update your
estimate of the edge location based on an pseudo LS calculation. One
solution might be to generate an error based on where your estimate is
and where you see the new edge and filter this error with a PI or PID
controller and apply it to update your estimate. Once you have an
error how much and what kind of filtering you need to do depends
completely on input jitter, your jitter rejection & tracking
requirements.

divide the main clock to give you a clock wich is close,
then when ever you get a data transition determine the phase relative to
that clock
accumulate the error and add the average as a phase offset to the divided
clock,
ofc you also have to adjust the divisor too so that the phase offset keeps
within limits.

you might need fractional divison for the clock,
ie change the divisor by +-1 cycle by cycle.

Colin =^.^=

 

[Magne]

Robert G. Kaimer Jr. wrote:

I have what seems to be a simple problem, but after a month's work I'm
at a total loss. I need to recover the clock (and resample data) from a
256 kHz data stream in an FPGA. Eventually I'll need to recover
different data rates and types, but right now it's just 256 kHz NRZ. (I
have an 8.192 MHz system clock.) The incoming data is not pristine by
any means, but I'm having a hard time just generating a stable clock
based on it.

Is anyone familiar with a good way to approach this? Thanks in advance
for your time.

Bob

Hi Bob,

the usual way to use NRZ is to have predefined frames and a nominal bitrate.

If you have to decode a raw bit-stream I know about a Xilinx Application
(XAPP224) note the discusses a serial receiver for NRZ implemented in
FPGA fabric. If you google for "digital phase follower" you might find
something interesting as well.


Mamu

 

[colin]

"Robert G. Kaimer Jr." <rkaimer1@frontiernet.net> wrote in message
news:2qHAi.14739$ya1.12843@news02.roc.ny...

This sounds closest to what I've been trying so far. I'm getting
reasonable values out of the filter that averages the errors, but
something goes south when I try to recreate the clock. I think part of my
problem is confusion regarding whether an edge is early or late.

presuming you clock the data on the rising edge then the transition should
occur on the falling edge,
so if it ocurs when the clock is low its late, high its early,
ofc u probly need to know how early or late it is.

problem is when you get long runs of 1 or 0 and the clock can drift more
than 1/2 bit position.
one option is to use 4x data clock and store 4 bits for each data bit,
its then possible to do some processing and work out a possible clock
correction wich gives the least errors for the length of a whole data
poacket.

depends if you have the processing power somewhere to do that.

or you could just make sure the clocks at each end have a very tight
tolerance.

Colin =^.^=