[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ecc] clock management for Reed-Solomon systems
Hi, Chuck,
Your "playing with numbers" suggestion sounds good. Come to think of it, we
do need some extra bits for synchronization. I'll explore this suggestion
of yours in greater detail.
Thanks, and best regards,
-aj
-----Original Message-----
From: owner-ecc@opencores.org [mailto:owner-ecc@opencores.org]On Behalf
Of Chuck Sommer
Sent: Tuesday, September 25, 2001 1:21 AM
To: ecc@opencores.org
Subject: Re: [ecc] clock management for Reed-Solomon systems
Let us look at these clocks.
My assumption is the output clock of the encoder is the most
critical (I could be wrong) since it drives the bit time of the
transmit system (whatever that is). Also as you said (in your
first message) there is the question of synchronizing the blocks
at the receiver. Let us look at other options.
Instead of transmitting 223 symbols of information (n) in 255 (k)
symbol times (one block) why not play with the numbers a little.
Reduce the number of data symbols in the block to 222 and
transmit 254 symbols in the block. In addition add 5 symbols
outside the block code to help synchronize the blocks.
So in the time it takes for the serial input to provide 222 symbols
your transmit clock will cycle 259 symbols. Why is this good?
Because the Least Common Multiple of these 2 numbers is
1554. (222 * 7 = 259 * 6). So a Fast clock operating at 7
times the input clock rate will operate at 6 times the transmit
clock rate. Now what to do with the 5 extra symbols. The
simplest thing is to setup a fixed pattern to corrolate on to
locate the block boundry. Rember that the channel is noisy
thus having errors so you cannot expect to receive this pattern
perfectly every time.
Hope this helps... Chuck
AJ Sahagun wrote:
> 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