[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecc] clock management for Reed-Solomon systems
The Convolutional code is a great complement to the RS code. With
convolutional coding the occasional bit error is easily corrected. When
the errors are concentrated (as happens with random errors) the code
gets confused and creates a burst of errors. So with random errors the
convolutional code fixes the occasional bit error and when the errors
are concentrated it concentrates them even more. The RS code on
the other hand does poorly with occasional errors because a 1 bit
error takes out a whole symbol.
On the other hand the errors of your channel may not be totally
random. Some channels give bursts of errors for example CDs
and disks get errors due to problems with the media. On a CD
scratch can take out many bits of data.
AJ Sahagun wrote:
> Convolutional coding won't be implemented, but considering that it is the
> common practice, we may consider including Convolutional coding in the
> future.
>
> As for the wireless channel, the exact specs are not available to me, but I
> think the modulation system won't be able to give block symbol/timing, so
> that part will have to be handled by the RS decoder.
>
> -----Original Message-----
> From: owner-ecc@opencores.org [mailto:owner-ecc@opencores.org]On Behalf
> Of Chuck Sommer
> Sent: Wednesday, September 26, 2001 12:05 AM
> To: ecc@opencores.org
> Subject: Re: [ecc] clock management for Reed-Solomon systems
>
> Is there going to be a convolutional coding on top of the RS coding?
>
> Will the wireless channel be modulated to provide block or symbol
> timing information? For example if frequency hopping occured at the
> Symbol boundry then the modulation system would provide Symbol
> boundry timing information.
>
> AJ Sahagun wrote:
>
> > The data transmission rate would be around 2MBps. The transmission
> channel
> > is a wireless channel. Currently it's a straightforward non-multiplexed
> > two-point transmit-receive configuration.
> >
> > -----Original Message-----
> > From: owner-ecc@opencores.org [mailto:owner-ecc@opencores.org]On Behalf
> > Of Chuck Sommer
> > Sent: Tuesday, September 25, 2001 12:52 PM
> > To: ecc@opencores.org
> > Subject: Re: [ecc] clock management for Reed-Solomon systems
> >
> > By the way what sort of data rates are we talking about?
> >
> > What does the transmission channel look like?
> >
> > AJ Sahagun wrote:
> >
> > > 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
--
To unsubscribe from ecc mailing list please visit http://www.opencores.org/mailinglists.shtml