Re: 64B66B bit ordering
Let me try again. I'm referring to the order of the words
received from the XGMII.
Let's call the 32-bit word transferred on clock tick N,
WORD[N] and the word transferred on clock tick N+1,
WORD[N+1]. In your picture on the slide titled "Bit ordering
sequence", I would say that WORD[N] would wind up in
BYTE3 thru BYTE0 and I would say that WORD[N+1] would wind
up in BYTE7 thru BYTE4. Do you agree?
In your "State machine notation conventions" slide, your
definition of tx_tobe_coded states: "the most recently
received TXD word in the 35:0 bit locations". To me, the
"most recently received TXD" would correspond to WORD[N+1]
in my definition above.
I guess what I'm missing is a bit to byte map. I picture
bits [35:0] corresponding to BYTE3 thru BYTE0 but these
should hold WORD[N].
Rick Walker wrote:
> 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
> 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
> Please let me know if this still isn't clear.
> Rick Walker
Router Products Division
1 Bedford Farms,
Bedford, NH 03110
603-629-3027 - Work
603-624-4382 - Fax
603-798-4115 - Home