RE: SJTP:Phantom sync headers
Don,
Have a good weekend.
I wasn't missing the inversion. My thought was that if one only needs to get
sync at one point in the repeating pattern. After that point, timers can
load the seeds. So, one can look for the value expected in the scrambler
just before the load of Seed A. Then one can load Seed A Invert, Seed B, and
Seed B Invert based on counters from that point. It minimizes the cost of
doing the compare if it only has to be done for one value. Not that it takes
that much to do a compare to a value and its inversion - if all the AND
gates in the comparitor output 0, you have the inversion; if they all output
1, you have the value. But I wasn't going to compare for the second seed
either.
Thinking about it, one could search for the data pattern that occurs right
after the seed load. That would be simpler to calculate from the seed.
Another reason I like the 4-errors method is it doesn't require a sync
protocol while the pattern match and count method does. Does one always load
the seed and restart the counters when one sees the expected pattern
(allowing the sync to slip temporarily to the wrong place if a bit error
causes a slip) or do we get fancier and specify that one has to see an
unexpected pattern a number of times or an error after a load a number of
times before slipping the sync? It isn't necessarily a lot of gates in the
end, but it seems excessive for the purpose.
Also, if one does the pattern match and count method, one has to check the
patterns to ensure that the search value only occurs once. I'm pretty sure
that with constant data pattern into the scrambler, the scrambler output
will only reoccur if the chosen segments cover an overlapping sections of
the full scrambler cycle, but it just adds a bit of pain to the seed
selection process.
So overall, I lean to the 4-errors method.
Regards,
Pat
-----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
> >
>