Re: SJTP:Phantom sync headers
Pat, Jonathan,
Thanks for your clarifications. I think I understand what
you are both proposing now.
I really like Pat's idea:
1) The RX can begin its 7-bit counter at any point in the
pattern;
2) The RX ignores the first error that occurs in the 128
blocks since it is guaranteed that there will always be
at least 1 block error in every 128 due to the method of
generating seeds;
3) After the first error, all subsequent errors in the
block of 128 cause the error counter to increment.
The ramification of this approach is that a real error
is ignored if it comes before the seed-load error in each
set of 128 blocks but this only means the seed-load error
will be counted.
This protocol is about as simple as I can imagine. However,
it cannot be ignored and must be included in any proposed
solution that we include in the SJTP comment.
I think the additional complexity of Jonathan's proposal
is not necessary. The only advantage is that it gets
around ignoring 1 block of every 128. We decided in the
last meeting that this was not required for an adequate
analysis of BER. If it can be shown that ignoring this
1 block does impact BER, then a more detailed protocol
may be necessary.
Ben
pat_thaler@xxxxxxxxxxx wrote:
>
> My comments are added in below marked by <PAT>
>
> -----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>The transmitter doesn't have to go into a special mode for the receiver
> to get sync. I think what Jonathan was describing in saying that the Rx side
> would "lock on" the normal seed is that the receiver would load the seed
> into the pattern generator every 64 bits. If it is a 64-bit parallel
> implementation or a multiple of that width, this could be done by loading
> the seed into the generator and then not updating the generator contents
> with the incoming data as one would in normal operation until the output
> matched the expected output. In a bit serial implementation, one would have
> to load the seed every 64-bits. What this method avoids is the need to put a
> value in at the receiver that is the expected pattern generated by the seed.
> In the absence of bit errors, one gets lock within one cycle of the 4-seed
> pattern without any need to put the transmitter into a special mode.
>
> <PAT> Of course, what this description ignores is the question of how one
> determines that sync has been lost so that the receiver can capture lock to
> the pattern start again. If one loses lock, one will get an error every time
> the receiver loads a seed plus one will get an error every time the
> transmitter loads a seed. One can't use the transmitter seed-load caused
> errors easily to realize there is a loss of lock because one can't
> differentiate them from other errors in due to BER especially pattern
> related errors. One could use some measure of errors on the first block
> after receiver seed load to generate a resync notification. For instance, if
> the last 3 seed loads were each preceded by an error, then resync the
> receiver.
>
> <PAT> With the method proposed, one just has to receive the block after the
> 1st seed load correctly one time to get sync. Error rate would have to be so
> bad that one consistantly was unable to get 64 bits without error or there
> would have to be a data dependent problem such that there were always errors
> in the first blcok after the seed to cause a failure to lock. If error rate
> is so bad that one is consistantly unable to get 64 bits without error, then
> one won't get block lock and will know that the receiver is unable to
> function under the test conditions. It would be a good idea to chose
> patterns where the stressful part of the pattern is not in the first 64 bits
> after the seed if this method of obtaining sync is applied.
>
> <PAT> One complication with the sync method is that it makes it a bit more
> difficult to know how long the time period to which a BER count applies. At
> a minimum will have to add a pattern sync bit which latches loss of pattern
> sync to the MDIO registers so that one will know whether the pattern has
> been in sync since the last reading.
>
> 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?
>
> <PAT> The charm of the 4-errors method is that one doesn't
> sync the receiver at all. In the 4-errors case, one relies
> on the fact that not loading seeds at the receiver will
> produce exactly one bad block each time the transmitter loads
> a seed.
>
> <PAT> What 4-errors requires is that the receiver count out
> 128 block windows. In each window, the receiver ignores the
> first error which occurs in the window. That is, the receiver
> doesn't increment the bad block count for the first error in
> the window. It does increment the count for any subsequent
> errors until the next window starts.
>
> <PAT> Let's look at the case where the transmitter happens to
> be loading the seed somewhere in the middle of the receiver's
> window, say the 60th block of the window. When no "real" errors
> occur, the first error of the window will happen on the 60th
> block and the receiver will ignore it. Perhaps a real error occurs
> on the 3 block of the window. That error won't be counted since it
> is the first in the window, but the error caused by seed load at
> the 60th block will then be counted. One real error happened and
> one error was counted.
>
> <PAT> This method does place one requirement on the seeds. A seed
> load must produce an error. That is, the seed value should be
> different than the 58-bit pattern transmitted just prior to the
> seed load. This doesn't seem to be a severe restriction and is
> less stringent than the requirement in the sync based methods which
> is that the seed value used for sync not appear elsewhere in the pattern.
>
> 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.
>
> <PAT> I agree that this is the main missing piece.
>
> 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
> -----------------------------------------
--
-----------------------------------------
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
-----------------------------------------