RE: SJTP:Phantom sync headers
Don,
Please let's reconsider and simplify this discussion. While there are other
ways to accomplish the goal, I would like to argue that the following is
most easily understood and least likely to be misinterpreted. If someone
wishes to implement it differently, "let it be."
1. Both the Tx and the Rx have EXACTLY IDENTICAL pattern generators. This
includes any inversions, etc.
2. Both the Tx and the Rx have the ability to indefinitely repeat the
first/primary/positive-logic seed (for use in OMA measurement, etc).
3. It is possible, therefore, to use these to "features" of the pattern
generator on the Rx side to "lock on" the nominal seed until it detects a
match and then "release" the scrambler for normal operation. Yes, there are
timing and race conditions that are not resolved by this description. But,
the function should be unambiguous.
We can add complexity to the description of this to have it more closely
represent and actual implementation. First, we must agree on the
representation so that our customers are not confused.
jonathan
> -----Original Message-----
> From: Alderrou, Don [mailto:don.alderrou@xxxxxxxxx]
> Sent: Thursday, May 10, 2001 10:03 PM
> To: 'pat_thaler@xxxxxxxxxxx'; bbrown@xxxxxxxx
> Cc: stds-802-3-hssg-serialpmd@xxxxxxxx
> Subject: RE: SJTP:Phantom sync headers
>
>
>
> Pat,
>
> The one thing that I think you are missing to describe about
> checking the
> bits at the receiver is that the data pattern is also changed
> (inverted)
> when the new seed is loaded. This can be worked around by
> matching the
> received bits against both the expected data and it's
> inversion. I don't
> think this method will have much effect on the error counting (do you
> agree?)
>
> It would be much less costly to implement this (bit checking
> on the data and
> inversion) with Pat's crude "Four errors" method below.
> Having to sync to
> the pattern and using counters to predict seed changes seems
> like way too
> much logic/cost for this function.
>
> --Don (Going away for the weekend, type to you on Mon)
>
>
> > -----Original Message-----
> > From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> > Sent: Thursday, May 10, 2001 6:31 PM
> > To: bbrown@xxxxxxxx; don.alderrou@xxxxxxxxx
> > Cc: stds-802-3-hssg-serialpmd@xxxxxxxx
> > Subject: RE: SJTP:Phantom sync headers
> >
> >
> > Ben,
> >
> > That was an advantage of the proposal for the receiver to
> > look for a pattern
> > in the descrambler and load the seed based on reaching that pattern.
> >
> > Once block sync has been acquired and data starts running into the
> > descrambler, there will only be errors after each seed
> > change. Once 58 bits
> > have been received with the new seed, the descrambler will
> > have locked. So,
> > at any time other than the block immediatly after a seed
> > change (or the
> > block after a transmission error), the scrambler and
> > descrambler states will
> > be synced.
> >
> > What we have to provide is a way to sync the scrambler load
> > at the receiver.
> > One way we could do that is to load a value into the receiver
> > that is the
> > scrambler state right before the loading of Seed A. When the
> > scrambler state
> > reaches that value, Seed A will be loaded and from there on
> > the timer takes
> > over. If this method is used, one will need to check the
> > patterns to ensure
> > that that value doesn't appear in the scrabler at any other
> > point during the
> > test.
> >
> > The other cruder method is to not try to sync the receiver
> > scrambler at all.
> > One knows that then one will get 4 errored blocks per every
> > repeat of the
> > pattern. Run a counter in the receiver at the seed load rate
> > and don't count
> > the first error in each seed load time. (This assumes we
> count errored
> > blocks rather than errored bits. If one counts errored bits,
> > it gets more
> > complicated because the number of those will depend on the
> particular
> > pattern sent.)
> >
> > Regards,
> > Pat
> >
> > -----Original Message-----
> > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > Sent: Thursday, May 10, 2001 4:48 PM
> > To: Alderrou Don
> > Cc: serialpmd
> > Subject: Re: SJTP:Phantom sync headers
> >
> >
> >
> >
> > Don,
> >
> > This is a good point. Especially with such a short
> > pattern, it may be difficult for the receiver to
> > power up "knowing" where it is in the
> >
> > Seed A
> > Seed A Invert
> > Seed B
> > Seed B Invert
> >
> > loop. There may be many errors in the beginning while
> > waiting to sync up on the pattern... As we develop
> > seeds, this is another aspect of the project that
> > could greatly benefit from PCS simulations.
> >
> > Ben
> >
> > "Alderrou, Don" wrote:
> > >
> > > Ben,
> > >
> > > Another issue which I've not heard discussed is in the
> > receiver error
> > > detection logic. Once the 64B/66B receiver has Block_Lock,
> > the error
> > > detection logic needs to find "pattern sync" at the
> beginning of the
> > jitter
> > > test pattern. The pattern as proposed will invert the data
> > & scrambler
> > > seed, thus the receiver needs to also do this at the proper
> > time to check
> > > for errors. If the data & seed are not chosen wisely,
> > there could be
> > > similar "phantom pattern sync" issues. A simple way around
> > this is to
> > have
> > > some "sync frames" similar to the WAN A1/A2 as part of
> the pattern.
> > >
> > > --Don
> > >
> >
>