Re: 64B/66B Control Codes Mapping & Bit Order
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