Re: 64B66B bit ordering
Hi Ben,
> The picture on the slide titled "Bit ordering sequence" appears
> to show the creation of a single 64-bit word from 2 consecutive
> 32-bits words from the MAC (or RS). From this picture, it appears
> that the first word fills bytes 3 thru 0 and the second word fills
> bytes 7 thru 4. I would read this as the first word filling bits
> 31:0 and the second word filling bits 63:32. This doesn't account
> for the control bits but I think we can ignore them for now.
>
> Your definition of tx_tobe_coded describes "the most recently
> received TXD word in the 35:0 bit locations" (this does include
> the control bits).
>
> These definitions appear to be in conflict. Could you please
> clarify this?
I don't see the conflict. The tx_tobe_coded bits are from the RS layer
and include the data/control bits. 35:0 is 36 bits which is half of
9*4*2=72 bits, or the number of bits in one XGMII transfer.
These 72 bits get stripped down to either a pure 64 bit data field with no
data/control indicator bits, or a combination of data and control fields.
The "Bit ordering sequence" diagram ass simplifed to only show bit order
and assumes a pure data transfer. In the real case, the 8 data/control
flags have to be evaluated to generate the TYPE byte and control fields.
The drawing shows 32 bit transfers from the MAC, when we actually get
36 bit transfers. In the simplified example, we simply ignore the extra
bits.
Even so, I realize that the published information is still pretty
sketchy. I'm hoping that we can publish a basic coder in Verilog to
clarify these details.
The main piece missing from the presentation is that each of the various
sub fields are packed in *bit reversed* order. This includes each of
the 7 bit control fields. The data is then serialized left to right MSB
first.
Please let me know if this still isn't clear.
--
Rick Walker