Talk:8b/10b encoding
From Wikipedia, the free encyclopedia
[edit] 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)
[edit] 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:
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 |
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.
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)
[edit] 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)
-
[edit] 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)
- 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?
[edit] 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)
[edit] 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:
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
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)
[edit] 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)
[edit] 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)
[edit] ==
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)
[edit] 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)
[edit] 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)