Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: stds-802-3-hssg@xxxxxxxx*Subject*: Re: 64B/66B Control Codes Mapping & Bit Order*From*: Rick Walker <walker@xxxxxxxxxxxxxxxxxxxxxxx>*Date*: Fri, 06 Oct 2000 18:39:49 -0700*cc*: "Ben Brown" <bbrown@xxxxxxxx>, thomast@xxxxxxxxxxxxxx*Sender*: owner-stds-802-3-hssg@xxxxxxxx

Dear Ben, Thomas, > I think I understand what you're doing. I also think it is wrong. > I think what I showed you is correct. I guess we need to wait for > the owner of this code to give us the real answer. I've definitely confused things here. I'm sorry. It wasn't intentional. The way of serializing the frame has changed over time and I had to doublecheck against our Verilog implementation to see how we had done it. http://grouper.ieee.org/groups/802/3/ae/public/jul00/walker_1_700.pdf is in fact, correct. In the last message, I erroneously said that the frame was composed of elements with MSB on the left, and then bytes were swapped during transmission leading to a scrambling of 7 bit fields. This was how we originally had done it, but it was changed in walker_1_700.pdf to the final method. The frame is properly composed in the order shown in slide 5 "Code Summary", following the bit order given in brackets "[]". The final frame is then transmitted by simply reading the bits in a left-to-right order, each frame at a time. As indicated in slide 5, TYPE bytes are sent LSB first, in the same way as data bytes. The table explicitly shows 0x1e serialized as "01111000". The bits are ordered in this way solely because Ethernet transmits bytes and computes CRC32 in a bit-reversed order. The control bytes are reversed during the parallel composition of the frame, rather than during a byte-oriented muxing, because this preserves the locality of the 7-bit fields. The mux then logically becomes a simple 1:66 and 66:1 function with no reordering. The frame order simply impacts the wiring of the multiplexers that do the frame composition and is otherwise free. So, the proper ordering is *not* interpretation 1, but rather that which was described in the Jyly presentation. I'm sorry to have contributed to the confusion. Here's a set of test vectors for Birdy's Verilog implementation that will hopefully make this completely unambiguous. // RS Output (Input to 64b/66b coder): //All control codes 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 07,1 fe,1 1c,1 3c,1 7c,1 bc,1 dc,1 f7,1 // Internal 66 bit frame prior to scrambler //01_01111000_00000000_11110010_11010110_01101101_00110101_01011001_10001111 // <--1e--> <--07-><--1e--><--2d--><--33--><--4b--><--55--><--66--><--78-> "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 "10" 1e 00 4f 6b b6 ac 9a f1 // Scrambled 66 bit output - scrambler initial state is all 1s) "10" 1e 00 4f 6b 36 5c e5 2d "10" 2b 27 4c 40 50 ac 3e 7b "10" a2 18 18 b5 3a 07 7a f4 "10" 26 fd 98 bc d0 d7 35 26 "10" b4 8b 56 33 fa a1 47 8a "10" 29 a7 52 a0 f4 26 e0 7e "10" d2 30 dd c9 12 45 f9 56 "10" b9 fd ca 5c 09 95 bf 71 "10" 46 af f6 91 da f1 0b 13 "10" eb 37 f0 84 f8 76 cd 25 Note that as in walker_1_700 page 9, the bytes in the above representation are transmitted from left to right, LSB first - except for the quoted preamble sync bits which are transmitted left to right in bitwise fashion. Best regards, -- Rick Walker

- Prev by Date:
**Clause 49 comments** - Next by Date:
**RE: Path Status (G1) latching** - Prev by thread:
**Re: 64B/66B Control Codes Mapping & Bit Order** - Next by thread:
**Re: 64B/66B Control Codes Mapping & Bit Order** - Index(es):