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?
This is more clear in the "Code Summary" table. You can see that the
first transfer /D0D1D2D3/ is loaded into the frame bit fields 0:31. The
second /transfer D4D5D6D7/ is loaded into bit fields 32:63.
I think this is equivalent to your assumption above.
> 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].
This is a labelling problem. In the Code Summary table, the bit fields
are numbered 0-63 in a left-right order. The state machine description
labels them in the opposite order. We'll have to straighten this out.
In the meantime, you can verify your implementation by checking against
the "sample 64b/66b test vector" slide. This makes everything quite
clear except for the way the 7-bit control fields are packed. (These
are still ambiguous as the only coded control bits are all zeros and are
symmetric from right-left).
I don't see any simple way to state all of this precisely enough in
pictures to be completely unambiguous. I'm hoping that some Verilog code
and a more complete set of test vectors will serve the purpose.
If you have any ideas for a way to elegantly describe all these details
in a simple slide, please take a shot at it and I'll be happy to add
it to the documentation of the code.
Best regards,
--
Rick Walker