Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Clause 48: unaligned 8b10b stream problem




Brian,
 First off, this email largely restates Pat's comment, just with more (too
much) detail on the amount of errors in a 1 bit slipped nominal IPG.  But if
you have that pathologic need to keep reading, then by all means...

 I assumed you were describing a case where a bit slip occurs on one lane
(XAUI or LX4).  In which case, a deskew_error would occur and proceed as I
described.
 I can't judge the likelihood of all four lane transmitters or receivers
slipping, but I assume this to be unlikely.
 But, lets assume this actually happened.  In which case we could look at
lane 0, where at a minimum there would be only 1 column of idle, which would
look something like this: ...D/K/S/D21.2(0x55)/D...  Normally though, clock
deletion of ||R|| would not be occurring (not for every IPG), and even with
DIC operating, worst case, every 4 frames there would be a frame with an IPG
with 3 columns of idle (again, ignoring clock compensation)

Thus, with 3 columns of idle, lane 0 could take on only 5 possible forms:
Case 1: /K/R/R/S/D21.2
Case 2: /K/R/K/S/D21.2
Case 3: /K/R/A/S/D21.2
Case 4: /A/R/R/S/D21.2
Case 5: /A/R/K/S/D21.2
Assuming the slipped 10bitcodes outside of this IPG region somehow remain
valid, then lets look at how many errors might occur in these sequences
assuming 4 types of shifts (left 1 bit, shift in a 0; left 1 bit, shift in a
1; right 1 bit, shift in a 0; right 1 bit, shift in a 1)  and for each type
of shift, the sequence might start with RD=negative, or RD=positive.  Thus
there's 8 scenarios to go through for each case. I go through those at the
end, but lets skip that for now...

Summary:
 All 1bit left shifts, of 20 scenarios: 40% have 2 errors, 40% have 3
errors, 20% have 4 errors
 All 1bit right shifts, of 20 scenarios: 20% have 2 errors, 40% have 3
errors, 40% have 4 errors

Now lets cast aside our assumption that "no" errors are occuring in the
10bitcodes outside of the IPG.
To lose sync in the worst case (when only 2 errors occur in the IPG), the
sync state machine on lane 0 would have to see 1 error in 4 codegroups
before the IPG and 1 error in 4 codegroups after the IPG, or any similar
permutation resulting in loss of sync.    One error outside of the cases
I've outlined is likely to occur in the CRC, leaving one error to occur by
chance.  But in the worst case (a left shift), this need for 2 errors is
occuring in only 40% of these IPG cases.

Since 20% of these cases would cause a loss of sync, a *simple* argument
could be made that: these IPG cases outlined would occur at least once every
4 frames (due to DIC), and 1 out of 5 of them would cause loss of sync, thus
every 20frames at least one should cause loss of sync.  Not rigourous, but
hopefully enough to obviate the need to add a timer for this remotest of
scenarios.


	Bob Noseworthy
	(603) 862-4342
	UNH InterOperability Lab
	IOL Development Staff active w/ DOCSIS, Ethernet,
	Fast Ethernet, Fibre Channel, & Gigabit Ethernet.


The details of the 20 difference scenarios per shift are outlined below:

Left shift 1bit, shift in a 0
  Case 1: /K/R/R/S/D21.2 ->
    Start RD='-':  2 Invalids
    Start RD='+':  1 Invalid & 2 RD errors
  Case 2: /K/R/K/S/D21.2 ->
    Start RD='-':  2 Invalids & 2 RD errors
    Start RD='+':  3 Invalid
  Case 3: /K/R/A/S/D21.2 ->
    Start RD='-':  1 Invalids & 1 RD errors
    Start RD='+':  2 Invalid
  Case 4: /A/R/R/S/D21.2 ->
    Start RD='-':  2 Invalid
    Start RD='+':  1 Invalids & 2 RD errors
  Case 5: /A/R/K/S/D21.2 ->
    Start RD='-':  2 Invalids & 2 RD errors
    Start RD='+':  3 Invalids

Left Shift 1bit, shift in a 1
  Case 1: /K/R/R/S/D21.2 ->
    Start RD='-':  2 Invalids
    Start RD='+':  1 Invalid & 2 RD errors
  Case 2: /K/R/K/S/D21.2 ->
    Start RD='-':  2 Invalids & 2 RD errors
    Start RD='+':  3 Invalid
  Case 3: /K/R/A/S/D21.2 ->
    Start RD='-':  1 Invalids & 1 RD errors
    Start RD='+':  2 Invalid
  Case 4: /A/R/R/S/D21.2 ->
    Start RD='-':  2 Invalid
    Start RD='+':  1 Invalids & 2 RD errors
  Case 5: /A/R/K/S/D21.2 ->
    Start RD='-':  2 Invalids & 2 RD errors
    Start RD='+':  3 Invalids

Right shift 1bit, shift in a 0
  Case 1: /K/R/R/S/D21.2 ->
    Start RD='-':  1 Invalid & 2 RD errors
    Start RD='+':  1 Invalid & 2 RD errors
  Case 2: /K/R/K/S/D21.2 ->
    Start RD='-':  3 Invalid & 1 RD errors
    Start RD='+':  3 Invalid & 1 RD errors
  Case 3: /K/R/A/S/D21.2 ->
    Start RD='-':  1 Invalid & 1 RD errors
    Start RD='+':  1 Invalid & 1 RD errors
  Case 4: /A/R/R/S/D21.2 ->
    Start RD='-':  3 RD errors
    Start RD='+':  3 RD errors
  Case 5: /A/R/K/S/D21.2 ->
    Start RD='-':  2 Invalid & 2 RD errors
    Start RD='+':  2 Invalid & 2 RD errors

Right Shift 1bit, shift in a 1
  Case 1: /K/R/R/S/D21.2 ->
    Start RD='-':  1 Invalid & 2 RD errors
    Start RD='+':  1 Invalid & 2 RD errors
  Case 2: /K/R/K/S/D21.2 ->
    Start RD='-':  3 Invalid & 1 RD errors
    Start RD='+':  3 Invalid & 1 RD errors
  Case 3: /K/R/A/S/D21.2 ->
    Start RD='-':  1 Invalid & 1 RD errors
    Start RD='+':  1 Invalid & 1 RD errors
  Case 4: /A/R/R/S/D21.2 ->
    Start RD='-':  3 RD errors
    Start RD='+':  3 RD errors
  Case 5: /A/R/K/S/D21.2 ->
    Start RD='-':  2 Invalid & 2 RD errors
    Start RD='+':  2 Invalid & 2 RD errors


More info than you care about, this is the same info as above, but listed on
a case-for-case basis.  If you're actually reading all this (not just this
line) then you've earned a gold star and maybe even my favorite Irish bevy:
Case 1: /K/R/R/S/D21.2 ->
  Left shift 1bit, shift in a 0
    Start RD='-':  2 Invalids
    Start RD='+':  1 Invalid & 2 RD errors
  Left Shift 1bit, shift in a 1
    Start RD='-':  2 Invalids
    Start RD='+':  1 Invalid & 2 RD errors
  Right shift 1bit, shift in a 0
    Start RD='-':  1 Invalid & 2 RD errors
    Start RD='+':  1 Invalid & 2 RD errors
  Right Shift 1bit, shift in a 1
    Start RD='-':  1 Invalid & 2 RD errors
    Start RD='+':  1 Invalid & 2 RD errors

Case 2: /K/R/K/ ->
  Left shift 1bit, shift in a 0
    Start RD='-':  2 Invalids & 2 RD errors
    Start RD='+':  3 Invalid
  Left Shift 1bit, shift in a 1
    Start RD='-':  2 Invalids & 2 RD errors
    Start RD='+':  3 Invalid
  Right shift 1bit, shift in a 0
    Start RD='-':  3 Invalid & 1 RD errors
    Start RD='+':  3 Invalid & 1 RD errors
  Right Shift 1bit, shift in a 1
    Start RD='-':  3 Invalid & 1 RD errors
    Start RD='+':  3 Invalid & 1 RD errors

Case 3: /K/R/A/ ->
  Left shift 1bit, shift in a 0
    Start RD='-':  1 Invalids & 1 RD errors
    Start RD='+':  2 Invalid
  Left Shift 1bit, shift in a 1
    Start RD='-':  1 Invalids & 1 RD errors
    Start RD='+':  2 Invalid
  Right shift 1bit, shift in a 0
    Start RD='-':  1 Invalid & 1 RD errors
    Start RD='+':  1 Invalid & 1 RD errors
  Right Shift 1bit, shift in a 1
    Start RD='-':  1 Invalid & 1 RD errors
    Start RD='+':  1 Invalid & 1 RD errors

Case 4: /A/R/R/ ->
  Left shift 1bit, shift in a 0
    Start RD='-':  2 Invalid
    Start RD='+':  1 Invalids & 2 RD errors
  Left Shift 1bit, shift in a 1
    Start RD='-':  2 Invalid
    Start RD='+':  1 Invalids & 2 RD errors
  Right shift 1bit, shift in a 0
    Start RD='-':  3 RD errors
    Start RD='+':  3 RD errors
  Right Shift 1bit, shift in a 1
    Start RD='-':  3 RD errors
    Start RD='+':  3 RD errors

Case 5: /A/R/K/ ->
  Left shift 1bit, shift in a 0
    Start RD='-':  2 Invalids & 2 RD errors
    Start RD='+':  3 Invalids
  Left Shift 1bit, shift in a 1
    Start RD='-':  2 Invalids & 2 RD errors
    Start RD='+':  3 Invalids
  Right shift 1bit, shift in a 0
    Start RD='-':  2 Invalid & 2 RD errors
    Start RD='+':  2 Invalid & 2 RD errors
  Right Shift 1bit, shift in a 1
    Start RD='-':  2 Invalid & 2 RD errors
    Start RD='+':  2 Invalid & 2 RD errors



-----Original Message-----
From: brian.cruikshank@xxxxxxxxxxxxx [mailto:brian.cruikshank@xxxxxxxxxxxxx]
Sent: Wednesday, May 02, 2001 11: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