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

[Chuck Sommer <ChuckSommer@mediaone.net>]

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

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