RE: Clause 48: unaligned 8b10b stream problem

[brian.cruikshank@xxxxxxxxxxxxx]

Pat, Bob:

I agree it is a small case.  Just thought I would point it out.  

It sounds like it is not a big concern.

/Brian

pat_thaler@xxxxxxxxxxx 05/02/01 11:58 AM

To:        brian.cruikshank@xxxxxxxxxxxxx, ren@xxxxxxxxxxx         cc:        stds-802-3-hssg@xxxxxxxx         Subject:        RE: Clause 48: unaligned 8b10b stream problem

Brian,
 
If a bit slip happens on one lane (or on less than all the lanes), then
there will be /A/s detected on the lanes that are still aligned. Whenever an
/A/ is detected on a lane that is still aligned, it will produce an error.
 
If a slip happened on all the lanes, then the align_status=fail could occur
on occasion because misaligned data can look like an /A/ but there wouldn't
be any guarantee of it happenning. 
 
So, if an extremely pathological case happened where:
  All the lanes slipped
  All the slips were to positions where only the /K/ caused violations
during IPG (I think there is one such position)
  Packets are being sent so rapidly that the IPG was never longer than 8
characters per lane.
  Packet data such that code violations were sparsely placed during the
data.
So a lot of data is being sent, but it is mostly using a limited data set.
Note also that even if the data doesn't use all the characters, the CRC will
and any code violation in the CRC adds to the code violations detected in
the IPG.
 
I'm not convinced this situation would ever happen in real usage. 
 
If we wanted to protect against it, possible remedies would be:
 
Add a variable that indicates detection of  a misaligned comma - 
 
 
-----Original Message-----
From: brian.cruikshank@xxxxxxxxxxxxx [mailto:brian.cruikshank@xxxxxxxxxxxxx]
Sent: Wednesday, May 02, 2001 8:32 AM
To: ren@xxxxxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx
Subject: RE: Clause 48: unaligned 8b10b stream problem



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