RE: SJTP:Phantom sync headers
Ben,
Sorry, I seem to have confused you. Let me be more precise.
The Tx pattern generator starts and runs continuously through the normal A,
!A, B, !B pattern. It knows nothing of the Rx and makes no assumptions about
any Rx state. It just runs.
The Rx pattern generator KNOWS that if
1. it is synchronized at the 64 bit boundard and
2. that it generates the same first 64 bits of the A sub-pattern that the Tx
generator does, and that
3. if it continuously generates the same first 64 bits until these match
exactly the incomming pattern from the Tx, and
4. at that point starts to run free (just as the Tx generator does, no
longer repeating the 64 bit start of pattern), that
5. it is synchronized.
Does that help?
The other (perhaps confusing) point I was making before was that the Tx
pattern generator can use this same kind of lock on the initial 64 bit
pattern (repeating that portion of the A pattern continuously and not free
running through the rest of the A, !A, B, !B pattern) to generate a very
short pattern for measuring optical power (etc). In short, it could generate
a square wave or any number of other simple, short, patterns.
jonathan
> -----Original Message-----
> From: Ben Brown [mailto:bbrown@xxxxxxxx]
> Sent: Thursday, May 17, 2001 12:33 PM
> To: Jonathan Thatcher
> Cc: 'Alderrou Don'; 'pat_thaler@xxxxxxxxxxx';
> stds-802-3-hssg-serialpmd@xxxxxxxx
> Subject: 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
> -----------------------------------------
>