RE: Clause 48: unaligned 8b10b stream problem

[brian.cruikshank@xxxxxxxxxxxxx]

Bob,

I agree this is an unlikely case.  Sometimes it seems that those unlikely cases actually happen when you do not expect it.  Maybe an transmit side causes this by a poor implementation and a PLL problem.

I do not see how the align_status=fail would occur as you mention below.  I do not think that the deskew_error would occur.  There is no timer (any more) for looking for no occurrences of ||A||.  So this would not cause deskew_error.  Since the bit alignment was wrong, an /A would not occur in any channels during the IPG.  So this would not cause the deskew_error to occur either.

In all likelihood, it eventually would hit something that would trigger the LOSS_OF_SYNC and the system would recover.  The more reaonsonable concern is that it might take longer than desired to recover.  This once again is because the 8b10b stream shifted by one can look like a mostly valid stream.

Often it seems that the group is very concerned about recovering quickly and sensing every bad packet.  I thought this might be a spot to give consideration.

/Brian

"Bob Noseworthy" <ren@xxxxxxxxxxx> Sent by: owner-stds-802-3-hssg@xxxxxxxx 05/01/01 05:13 PM

To:        <stds-802-3-hssg@xxxxxxxx>         cc:                 Subject:        RE: Clause 48: unaligned 8b10b stream problem

Brian,
  First lets assume the case you outlined actually happened - that a lane
slipped a bit but did not cause Loss of Sync.

In this case:
 - align_status=fail would occur within 8 frames (since the first ||I||
after every other frame would be an ||A||)
 - The receiver would then generate local fault
 - The RS would then transmit remote fault to the link partner sourcing the
line-rate frames
 - Upon reception of remote fault, the link partners RS would then inhibit
frame transmission and source ||I||

so in a worse case, if this unlikely scenario was occurring, then after 8
frames + the max round trip propagation delay, the Sync state machine would
lose sync (after receiving 4 bit-slipped /A/,/K/,or /R/ which would cause
PUDI=/INVALID/)

Given the unlikely nature of the problem, this "slow" recovery mechanism
seems to be adequate and requires no change to the standard.

Regards,
                 Bob Noseworthy
                 (603) 862-4342
                 UNH InterOperability Lab



-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of
brian.cruikshank@xxxxxxxxxxxxx
Sent: Tuesday, May 01, 2001 3:39 PM
To: stds-802-3-hssg@xxxxxxxx; rtaborek@xxxxxxxxxxxxx
Subject: Clause 48: unaligned 8b10b stream problem



Rich,

I have a concern about turning off comma detection and not having a timer to
indicate no recent commas.
I believe I am looking at this correctly.  Let me know if I am missing
something.

If a valid 8b10b stream becomes out of alignment, I believe there is a
chance that it would never be realigned.
It may be a statistically rare case, but I thought I would mention it.

Here is the case:
 - The interface is using maximum bandwidth for packets and is only
transmitting minimum IPG.
 - A bit slip or bit insertion in the stream happens so that bit alignment
is wrong.
 - Many of the valid codewords if shifted by one are still valid; this may
not cause Loss of Sync.  D21.5 can be shifted and be fine.  LOSyn takes 4
codeblock violations which consists of 4 codewords.  An occasional codeword
violation may not cause Loss of Sync to happen.
 - The IPG codewords shifted would not be valid, but they do not occur often
enough (with min IPG) to cause Loss of Sync.  This would only definately
cause 6 codeword violations or 2 codeblocks.
 - Since Loss of Sync never happened, the commas would never be detected and
the stream would never be realigned.

I have not had a chance to see statistically how many codwords can be
shifted and still be valid.  That is an important question.  The next
question will be is if that number is ok to not change the state machine.

/Brian Cruikshank

____________________________________________________
Brian Cruikshank
Mindspeed Techologies
Conexant Systems
5555 Central Ave
Boulder, CO 80301
Phone: (303) 543-2023
Cell:      (303) 641-9528
Fax:      (303) 543-2099
Email: brian.cruikshank@xxxxxxxxxxxxx