[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: [email protected] [mailto:[email protected]]On Behalf
> Of Chuck Sommer
> Sent: Tuesday, September 25, 2001 1:21 AM
> To: [email protected]
> 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: [email protected] [mailto:[email protected]]On Behalf
> > Of Chuck Sommer
> > Sent: Saturday, September 22, 2001 9:09 AM
> > To: [email protected]
> > 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