Talk:8b/10b encoding

Lowercase 'b' vs. Uppercase 'B'

Should this be "8b/10b" instead of "8B/10B" since little b means "bit"?--SFoskett 14:47, Sep 2, 2004 (UTC)

That's a good question. The 10GE FC draft spec refers to it as 8B/10B, but the PCI Express spec refers to it as 8b/10b. However this article gets named, we need a redirect from the other, IMO. MatthewWilcox 14:54, 24 Nov 2004 (UTC)

Finally renamed as most of the external links appear to use the lower-case variant. —Sladen 05:56, 27 August 2007 (UTC)

I studied also a 4b/5b encoding. Is it the same as this, referred to the byte (8 bits)? I can't find it in the Line code page. Maybe it is also known with some other name.--Luc4 Fri Sep 23 12:14:02 2005 (CEST)

I'm not especially familiar with 4b/5b encoding, but from what I gather here it appears to be somewhat similar but simpler. Aluvus 17:27, 16 June 2006 (UTC)

4b/5b is listed on that page... just as 4b5b. And yes, 4b/5b is similar but simplier. Mrand 18:26, 16 June 2006 (UTC)

8b/10b coding table

For eventual cut & paste into main article. (Go ahead and delete this section from talk if/when that's done.)

The 8 input bits of the 8B/10B code are conventionally identified by upper-case letters A through H, with A the low-order bit and H the high-order bit. Thus, in standard binary notiation, the byte is HGFEDCBA. The output is 10 bits, abcdei fghj, where a is transmitted first.

Coding is done in alternate 5-bit and 3-bit sub-blocks. As coding proceeds, the encoder maintains a "running disparity", the difference between the number of 1 bits and 0 bits transmitted. At the end of sub-block, this disparity is ±1, and can be represented by a single state bit. The input and the running disparity bit are used to select the coded bits as follows:

5b/6b code

input		RD = -1	RD = +1	input		RD = -1	RD = +1
	EDCBA	abcdei			EDCBA	abcdei
D.00	00000	100111	011000	D.16	10000	011011	100100
D.01	00001	011101	100010	D.17	10001	100011
D.02	00010	101101	010010	D.18	10010	010011
D.03	00011	110001		D.19	10011	110010
D.04	00100	110101	001010	D.20	10100	001011
D.05	00101	101001		D.21	10101	101010
D.06	00110	011001		D.22	10110	011010
D.07	00111	111000	000111	D.23	10111	111010	000101
D.08	01000	111001	000110	D.24	11000	110011	001100
D.09	01001	100101		D.25	11001	100110
D.10	01010	010101		D.26	11010	010110
D.11	01011	110100		D.27	11011	110110	001001
D.12	01100	001101		D.28	11100	001110
D.13	01101	101100		D.29	11101	101110	010001
D.14	01110	011100		D.30	11110	011110	100001
D.15	01111	010111	101000	D.31	11111	101011	010100
				K.28		001111	110000

3b/4b code

input		RD = -1	RD = +1
	HGF	fghj
D.x.0	000	1011	0100
D.x.1	001	1001
D.x.2	010	0101
D.x.3	011	1100	0011
D.x.4	100	1101	0010
D.x.5	101	1010
D.x.6	110	0110
D.x.P7	111	1110	0001
D.x.A7	111	0111	1000

Note that, while in most cases, the codes that depend on RD change it by ±2, the encodings of D.07 and D.x.3 do not change it.

There are two encodings for D.x.7, "primary" and "alternate". The alternate code is used after D.11, D.13 and D.14 when RD=-1, and after D.17, D.18 and D.20 when RD=+1. This ensures that bits eifgh are never all the same, and thus five consecutive identical bits never appear in normal output.

Using an additional 6B output value, called K.28, and/or the alternate D.x.A7 output in context where it would not be otherwise required, an additional 12 "bytes" can be formed. Some of these contain a "comma sequence" abcdeifg = 00111110 or 11000001, which never appears anywhere else in the bit stream, and can be used to establish the byte boundaries in the data stream.

These symbols are used by higher-level protocols to indicate boundaries or gaps (idle time) in the data stream. The names are assigned because their encoding is a slight variant of the corresponding D.x.y codes.

Control symbols

input	RD = -1	RD = +1
	abcdei fghj	abcdei fghj
K.28.0	001111 0100	110000 1011
K.28.1*	001111 1001	110000 0110
K.28.2	001111 0101	110000 1010
K.28.3	001111 0011	110000 1100
K.28.4	001111 0010	110000 1101
K.28.5*	001111 1010	110000 0101
K.28.6	001111 0110	110000 1001
K.28.7*	001111 1000	110000 0111
K.23.7	111010 1000	000101 0111
K.27.7	110110 1000	001001 0111
K.29.7	101110 1000	010001 0111
K.30.7	011110 1000	100001 0111

(^* K28.1, K28.5, and K28.7 are comma symbols, containing the comma sequence abcdeifg = 00111110 or 11000001. K28.7 must not appear after another K.28.7, or it would form a second false comma sequence.) —The preceding unsigned comment was added by 192.35.100.1 (talk • contribs).

Wow, you put a lot of work into that. However, I think it may be a little excessive for an encyclopedic article. It is a great ref tho. Maybe link to it from the main article and put it in wikisource or something like that? — RevRagnarok ^{Talk Contrib} 12:04, 17 August 2006 (UTC)

I think they are absolutely appropriate for an encyclopedia! Cburnett 03:29, 19 December 2006 (UTC)

Running Disparity (RD)

At least one part of this more detailed explanation should be included in the article: the discussion of Running Disparity. This Acronym (RD) is given in the article, but it is never explained (note: RD is not yet defined in the above discussion either, though it is pretty obvious what it refers to). Also, I liked the following external links, should they be added? http://www.xilinx.com/ipcenter/catalog/logicore/docs/encode_8b10b.pdf, http://www.xilinx.com/ipcenter/catalog/logicore/docs/decode_8b10b.pdf DaraParsavand 18:39, 9 January 2007 (UTC)

I strongly agree about adding an explanation to Running Disparity (RD). Not only is the word used in the article but also the abbreviation in the table - and it is never explained. Actually I came here (to the discussion page) in hope of just finding this. IHMO the article is already quiet technical and adding this information seems appropriate and gives a good indication on "how" 8B/10B "works". MJost 13:22, 10 January 2007 (UTC)

I've added something as the Running Disparity (and DC-freeness) is the chief reason that brought me to 8b/10b encoding in the first place. The explanation needs some work to point out that only −ve/0/+ve disparity needs to be stored as even through the slew can be −2/−1/0/+1/+2 the direction of the next code will always take it towards zero. Sladen 14:12, 19 August 2007 (UTC)

Merge from Fibre Channel 8B/10B encoding

I propose a merge, since Fibre Channel 8B/10B encoding contains the same information (maybe in friendlier form). Nothing specific to Fibre Channel, really. --Kubanczyk 14:58, 22 August 2007 (UTC)

Agreed. They are the same. —Mrand ^T-C 02:03, 27 August 2007 (UTC)

However, the use of the control characters differs from implementation to implementation. Fibre Channel uses K28.5 at the beginning of every Ordered Set, while the other control chars are unused. Maybe that should be rolled into the main article?

IMHO, Disparity not zero after two Blocks

The article sais "This means that there are just as many "1"s as "0"s in a string of two symbols". I don't see how this is possible. when e.g encoding

0x00, 0x31, 0x31, 0x31, 0x31, 0x31, ...

0x00 introduces a disparity and 0x31 (=D17.1 => 1000111001) can't change it.

So the "relative disparity" is granted to get zero only with an infinite number of characters.

In fact the running disparity never is 0. It starts with either -1 or +1 and with any 6 or 4 bit block it gets incremented by either of -2, 0, or +2, the increment's sign being opposite to the value's.

A similar (but supposedly correct) version of the statement would be "This means that the difference between "1"s aand "0"s in a string of at least 10 bits is no more than 2". --Mschnell 07:35, 20 September 2007 (UTC)

IMHO, Table "Effect of Running Disparity" hard to understand and not necessary

1) In table "5B/6B code" the input RD is noted as "RD=-2" and "RD=+2". IMHO RD always is either +1 or -1 so here this should be the same as with table "3B/4B code": "RD=-1" and "RD=+1". I think best you just would say "RD=-" and "RD=+" in both tables.

Moreover it could be helpful to add the Disparity effect (-2, 0 or +2) with any result code entry in both tables:

3b/4b code

input		RD = -1	RD = +1
	HGF	fghj
D.x.0	000	1011 (Dis=+2)	0100 (Dis=-2)
D.x.1	001	1001 (Dis= 0)
D.x.2	010	0101 (Dis= 0)
D.x.3	011	1100 (Dis= 0)	0011 (Dis= 0)
D.x.4	100	1101 (Dis=+2)	0010 (Dis=-2)
D.x.5	101	1010 (Dis= 0)
D.x.6	110	0110 (Dis= 0)
D.x.P7	111	1110 (Dis=+2)	0001 (Dis=-2)
D.x.A7	111	0111 (Dis=+2)	1000 (Dis=-2)

2) As the disparity is handeled equally when starting a 6 bit block and when starting a 4 bit block, you don't need to handle the disparity of complete 10 bit blocks at all.

So the table "Effect of Running Disparity" could be replaced by

Rules for Running Disparity

Previous RD	RD of 6 or 4 Bit Code	Next RD
-	-	Error
-	0	-
-	+	+
+	-	-
+	0	+
+	+	Error

In the text you could state that for each byte to be coded the rule is applied to the 5B/6B part first and to the 3B/4B part afterwards with the RD resulting then to be the carry to the next byte operation. --Mschnell 15:26, 19 September 2007 (UTC)

IMHO, "five identical bits must not appear in normal code" is not true

When generating e.g. D.18.7, D.19.7 (i.e. D.18.A7, D.19.P7) after RD=-1, the bit sequence will be 010011 0111 110010 0001. Here we do have five identical bits. But we don't have one of the dedicate commas (with two zero bits before the five ones, which is not possible with D.x.A7) --Mschnell 16:51, 19 September 2007 (UTC)

IMHO, a separate table for K-symbols is not necessary

We better enhance the 3b/4b table appropriately. (4 result columns D-, D+, K-, K+ --Mschnell 15:31, 24 September 2007 (UTC)

==

After I got no response here, I did most of the changes I suggested. Sorry for forgetting to log in first :( --Mschnell 09:04, 25 September 2007 (UTC)

Ideas for article improvement

Howdy all, the page is looking considerably better than it did not too long ago... good job everyone! Looking over it, here are a few thoughts I had:

• Any useful content (or simpler phrasing) in the Fibre Channel 8B/10B encoding article should be merged in and that article set to redirect here
• The "How it works" section should probably be moved down below the "Technologies that use 8b/10b" so that the encoding tables can be made to be a subsection of "how it works".
• While the concept described in the sentence about the Ethernet transformer is correct, the overall statement looks technically wrong since 1000Base-T doesn't use 8b/10b.
• Lastly, it seems like the intro could be re-written to be somewhat easier for laymen to understand.

Anyone interested, please feel free to be bold and do any (or all) of these! —Mrand ^T-C 14:12, 26 September 2007 (UTC)

while the first issue is beyond my nowledge and the last is hard to do for me as I'm not a native English speaker, I'll take a look at the two others tomorrow. --Mschnell 20:32, 27 September 2007 (UTC)

Differences with TMDS

According to the author the difference between IBM 8b10b and TMDS is subtle. But in my opinion the differences are significant:

• TMDS selects between 3 different encoding schemes depending on audio/video/control data content in a particular time. There are also differences in encoding between TMDS data channels.
• IBM 8b10b uses 5b6b and 3b4b subblocks while TMDS has a dedicated algorithm during the video data period.
• TMDS has special coding for q_out[8] and q_out[9].
• IBM 8b10b has much tighter control over the DC balance, while TMDS introduces the concept of a counter that tracks the disparity.

In my eyes the only thing in common is the translation from 8 bits to 10 bits.

What do you think about chancing this?

merging in the fiber channel article

Either Fiber channel uses a different scheme that I don't understand ("even/odd disparity") or it is plain wrong. If the latter, I think it could be deleted. I did change the link iom the "§fiber channel" page to point here. --Mschnell 14:05, 9 October 2007 (UTC)