RE: SJTP:Phantom sync headers
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
-----------------------------------------