RE: [ecc] clock management for Reed-Solomon systems

["AJ Sahagun" <aj@asti.dost.gov.ph>]

Hi, Chuck,

The system accepts a continuous stream of input.  It's part of a larger
transmitter/receiver system which is supposed to be able to handle the
transmission of any continuous serial data.  A buffer exists to collect 223
GF symbols at a time for the encoder to process (the buffer is essentially a
serial-to-parallel converter).  While it's true that the serial stream is
"buffered", it's not possible to pause the input by 32 byte times after
every 223 bytes since the specifications require that the input be
absolutely continuous.  The two clocks were set as such so that there would
be no pauses both at the input and output.

The purpose of buffering here is to actually facilitate continuous input.
With it, the system can encode a set of 223 bytes and at the same time
collect the next 223 bytes.

I don't think the two clocks can be derived from each other, since the ratio
is 255/223.  However, I do think it's possible to derive both of them from a
very very fast base clock, but I'm not 100% sure on its feasibility.  In the
current design, the two clocks will be given to the encoder and decoder by
an external source.

The present design allows a small amount of jitter to be present, as long as
the deviation is not large.  It's still vulnerable to "drifting", though.



-----Original Message-----
From: owner-ecc@opencores.org [mailto:owner-ecc@opencores.org]On Behalf
Of Chuck Sommer
Sent: Saturday, September 22, 2001 9:09 AM
To: ecc@opencores.org
Subject: Re: [ecc] clock management for Reed-Solomon systems


Sounds like an interesting question.

The controlling of transmit and receive clocks can easily
take a full term college level course to cover.

My experience with Reed-Solomon codes is with disk controllers.
In this case the data is transmitted to the controller a block (or set
of blocks) at a time via DMA into a buffer, not as a continuos
stream.  Inside the controller the data is taken from a buffer at the
transmit rate.  When the check-symbols are sent, the buffer is idle.

Maybe you should consider a system where the serial stream
is buffered and the serial data is not continuos.  So you could
send on your interface 223 bytes and then send no data during
the next 32 byte times.

If you explain more about your application it may become
clear what the real requirements are.  For example what controls
the input clock.  Can it be derived from the output clock?  How
stable does the input clock have to be?  Can it jitter between
2 frequencies to average out to the required frequency?  How
much latency in the channel is permitted?  Can you buffer several
blocks of data or is latency an issue?

I hope this is some help.

AJ Sahagun wrote:

> Hi!
>
> I don't know if this has been adressed before... but is anyone familiar or
> has had experience with clock management for Reed-Solomon error correction
> systems? (or ECC systems with two clocks, for that matter...)
>
> Currently, our group is designing a (255,223) RS system with serial input
> and output.  So two clocks are required, one for the input and one for the
> output, with a ratio of 255/223.  These two clocks have to be
synchronized,
> such that, after 255 cycles of the faster clock, the slower clock will
have
> undergone exactly 223 cycles.
>
> The biggest issue we see is that of "drifting" clocks, which will happen
if
> the clock frequency ratio is not exactly 255/223, or when either or both
of
> the clocks are exceptionally unstable.  When this happens, the encoding
and
> decoding modules might not do their job properly.
>
> I hope someone familiar with this and related issues can help me with
> this... Thanks!
>
> ---
>
> Also, does anyone know if there are any recommended framing and symbol/bit
> synchronization techniques for serial Reed-Solomon systems?  Thanks
again...
>
> _______________________________________________
> "Alcohol and Calculus don't mix.  Never drink and derive."
>
> Engr. Jonathan A. Sahagun
> Science Research Specialist
> Advanced Science & Technology Institute
> CP Garcia Ave., UP Diliman Technopark
> Quezon City, Philippines
> (+632) 435-1064 (Microelectronics Division)
> (+632) 435-1052 (Fax)
> http://www.asti.dost.gov.ph

--
To unsubscribe from ecc mailing list please visit http://www.opencores.org/mailinglists.shtml