Date: 8 May 97 17:17:43 -0700
Subject: 8B/10B bit order and CRC impact
From: "Jerry Hauck" <Jerry_Hauck@ccm.sc.intel.com>
To: p1394b@fireflyinc.com
X-Mailer: Cyberdog/2.0
MIMEEnabled: Y
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-000453F0"
Content-Transfer-Encoding: 7bit


--Cyberdog-MixedBoundary-000453F0
Content-Type: text/enriched; charset=macintosh
Content-Transfer-Encoding: 8bit
X-Fontfamily: Monaco
X-Fontsize: 9

<SMALLER><SMALLER><FIXED>     P1394b'ers,

     

     At our 4/7 meeting in San Jose I accepted the action item to detail 

     any flexibility or constraints we may encounter in assigning the bit 

     order in which uncoded 1394 quadlets could be presented to or 

     received from an IBM 8B/10B decoder.

     

     During our 5/5 - 5/6 meetings, I presented a brief summary which I'll 

     attempt to capture here.  Other standards employing the IBM 8B/10B 

     code (including Fibre Channel and Serial Express) have chosen a bit 

     mapping between their protocol layer datapaths and the 8B/10B codec 

     which results in a least significant to most significant bit 

     transmission order.  While there is a desire to maintain synergy with 

     these standards to facilitate reuse of test equipment and mental 

     cycles, the impact to burst error detection should be considered.

     

     As the attached argument illustrates, a packet protected by a CRC 

     calculated in MSB to LSB order but transmitted in a bit transposed LSB 

     to MSB order does not retain the same burst error detection 

     properties.  Unlike Fibre Channel or Serial Express, legacy and 

     interoperability with DS encoded streams prevents P1394b from 

     redefining the bit order for CRC-32 generation.

     

     CONCLUSION: If P1394b adopts IBM 8B/10B coding, then CRC burst 

     detection properties mandate that the MSB from the link layer must be 

     transmitted first on the wire.

     

     If interested, read on ...

     

     Jerry Hauck

     Intel Corp

     (408) 765-5528

     jerry_hauck@ccm.sc.intel.com

     

     --------------------------------------------------------------------- 

     ***WARNING*** I use "MSB" to indicate "most significant BIT" and "LSB" 

     to indicate "least significant BIT"

     

     

     The Widmer/Franaszek 8B/10B coding paper uses the following 

     well-accepted nomenclature:

     

        The bits in an uncoded byte are designated as A, B, C, D, E, F, G, 

        and H.  (MSB or LSB is not specified.)

     

        Given the uncoded bits A through H, the 8B/10B codec will generate 

        a 10 bit coded symbol with bit designations of a, b, c, d, e, i, f, 

        g, h, and j.  To maintain the disparity, run length, and error 

        detection properties of the code, the bit serial order of 

        transmission is specified from first to last by the 

        non-alphabetical sequence repeated here: a, b, c, d, e, i, f, g, h, 

        j.  ('a' is sent first, 'j' is last)

     

     The essential choice we face is the designation of "A" or "H" as the 

     MSB for our uncoded bytes.  Other standards (e.g., Fibre Channel and 

     P1394.2) have adopted a common mapping: the most significant bit of 

     each uncoded byte is bound to the "H" term of the 8B/10B codec.  

     (Reference N.2 in Fibre Channel or 7.12.2 in Draft .777 of Serial 

     Express.)

     

     To efficiently re-use existing silicon, test equipment, and designer's 

     mental capacity, it would be natural for us to follow suite and adopt 

     "H" as our MSB.  This choice may be most critical in our infancy as we 

     make use of Fibre Channel silicon for early beta prototypes.

     

     Unfortunately, the mapping of "H" as MSB has some impact on CRC 

     generation and resulting burst error protection which now deserves some 

     attention.  Bear with me since pictures are not easily available.

     

     One of the nice properties of the CRC-32 chosen for 1394 is that it 

     detects all single bursts <<= 32 bits in length (for uncoded data).  

     Consider how burst errors in the encoded (10-bit) domain translate into 

     the uncoded (8-bit) domain:

     

        Assertion: A burst error of length 35 or less in the 10-bit domain 

        translates into a burst error of length 32 or less in the 8-bit 

        domain.

     

        Proof: Recall that 8B/10B coding is based on alternating 5B/6B and 

        3B/4B subblocks.  With the exception of some out-of-band control 

        symbols, bit errors are always confined to the subblock in which they 

        occur.  An error in the 5B/6B subblock results in a worst case burst 

        error of length 5 in the 8-bit domain.  Similarly, an error in the 

        3B/4B subblock results in a length 3 burst error in the 8-bit domain. 

        A burst error of length 35 in the 10-bit domain is confined to at 

        most 8 subblocks (four pairs of 6 & 4 bit subblocks).  Thus, the 

        largest resulting burst in the uncoded domain has a length of 32 

        bits.

     

     From the above, it can be concluded that single bursts of up to 35 

     digits on the line are guaranteed to be detected by the CRC-32 *if and 

     only if* the CRC generation and checking is performed in the order of 

     transmission; i.e., if uncoded bits 'A' through 'E' (which correspond 

     to the sub-block in which 'a' through 'i' are transmitted) are 

     considered more significant than bits 'F' through 'H' (which correspond 

     to the subblock in which 'f' through 'j' are transmitted).

     

     The designation of "H" as MSB directly contradicts the above since it 

     results in an LSB to MSB transmission order while 1394 CRC's are 

     calculated from MSB to LSB.  The consequence then of declaring "H" as 

     MSB is that a 32-bit burst error across the A through H outputs of the 

     8B/10B decoder can now span 40 bits when written in MSB to LSB order of 

     H through A due to the bit swapping performed on each byte.  The 40-bit 

     burst could go undetected.  (Working backwards, the largest line burst 

     still guaranteed to be detected is now 25 bits.)

     

     Fibre Channel and P1394.2 both pre-compensate for this by redefining 

     the CRC-32 generation/checking to proceed from LSB to MSB in a first 

     through last byte order.  Unfortunately, this solution is less than 

     desirable for P1394b since legacy links have a fixed computation order 

     of MSB to LSB.

     

     In the above discussion, I did not consider the inherent error 

     detection of the 8B/10B code.  It could be argued that the weakened 

     CRC burst detection is acceptable since the 8B/10B checks improve 

     the probability of catching errors.

     


</FIXED></SMALLER></SMALLER>
--Cyberdog-MixedBoundary-000453F0--