Re: SJTP:Phantom sync headers
All,
I've finally had a chance to actually implement the logic
to generate and search for the patterns. I then went back
and read this thread and thought I'd add a few comments.
Jonathan,
It sounds like you're suggesting we actually implement a
protocol for generation of the patterns so that the receiver
can sync up on the insertion of the new seed:
Jonathan Thatcher wrote:
>
> 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.
>
How long should the transmitter remain in this initial state
of sending Seed A without inverting or using Seed B? How do
you know when the receiver is in sync with this first part
of the process? Is there any feedback to the transmitter,
either directly or though management? What if this is being
done remotely (station 1 to station 2) rather than with a
local loopback? What if the receiver doesn't get sync due
to bit errors?
Pat,
Your message in Tuesday's meeting was that you liked the
idea of the 4-error method. Your emails in this thread
bounced back and forth between this method and a protocol
specific/counting method. I'll assume you have settled on
the 4-error method.
In this method, how does the receiver sync up to the
128 block boundaries? Does it look for a single error
and assume that is the start? Does it look for 127 blocks
without errors? What if there are enough bit errors to
never have 127 simultaneous error free blocks?
I might recommend that it look for 4 errors that are
all exactly 128 blocks apart in order to find the
boundaries. This would probably make it work in the
presence of errors. There must be a counter even in
this method to verify the separation of the errors then
to know when to skip the expected errors once in sync.
Any thoughts would be appreciated. I think this is a
missing piece of the comment resolution that should be
considered before we get to St. Louis so some of us
have a chance to simulate it and see what works and
what doesn't.
Thanks,
Ben
> 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
> > > >
> > >
> >
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------