More comments (clauses 49 & 46)
Pat, Bob,
Clause 49:
I don't see where sh_valid=false is explicitly used to make sure
that R_TYPE(rx_coded<65:0>) results in an E type. I think it was
stated that an invalid sync header resulted in an invalid code
word and was counted in the counter that we defined in the
break out discussion. Since it does all that, it also ought to
generate an Error to the XGMII.
Clause 49:
In the interest of "trusting" that the XGMII is an error free
interface, we removed the testing of delimiter robustness from
the transmit state machine. We did this by no longer checking
that the type encodings following a T are appropriate values.
We justified this by stating that this test is happening on
the receive side before the MAC so it was not required here.
The other packet delimiter (S) still has some robustness built
in. It is ignored if it follows an error, i.e. the transmit
state machine is in the TX_E state. However, I think this is
good. Here's why: If the transmit state machine allowed a
transition from TX_E to TX_S upon detection of an S, the receiver
would see an E followed by an S. However, the receive state
machine would see this E, this perfectly coded E with clean
sync header bits, as a C so it would be in the RX_C state. It
would then see the S and send the packet clean. Because the
transmit state machine drops the S, the receive state machine
would sit in state RX_C for an extra clock tick then go to
RX_E for a clock tick when it got the first D word.
Clause 49 & 46:
This brings up another interesting point about how the
PCS & RS currently handle delimiter robustness. Consider
the case of a packet that is ended with the following
octet stream (broken into 8-octet words that a 64b/66b
PCS might encounter):
DDDDDDDD
DDDDTEII
IIIIIIII
The PCS would send to the XGMII these bytes exactly as is
and would not replace the T word (or even the T octet) with
Es. Because the PCS treats any of the defined encodings in
table 49-1 (other than T & S) as C, it decodes and forwards
what it receives (barring actual decoder violations).
Will the RS corrupt this packet? Does the RS expect the
PCS to corrupt the /T/ if the C following the T is anything
but an I?
Enjoy,
Ben
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-647-2291 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------