RE: More comments (clauses 49 & 46)
Ben,
Good questions.
On R_TYPE, since the E is defined as anything that is not one of the other
frame types and a frame with an invalid sync header can't be one of the
other types, then it is implicit in the current definition that a sync
header violation makes the frame an E type but it should be made explicit. I
will add words to do so.
On your second comment, it seemed important to remove the checks for next
frame type from the transmit state machine because they impose a burden of a
pipeline storage stage on the implementation. The original walker_1_0700
state machine only considered an S block to be valid after a C or T block
and that check doesn't make the state machine harder to implement so it
seemed reasonable to keep it in. It also has some benefit as you state.
On the third ocmment (and also related somewhat to your second comment), it
may be that the frame type should be E when a frame is received that has a
control character of E in it. At least, if the frame is all E's, it should
be detected as an E frame or the end delimiter check on the receiver will
pass some frames to the RS as okay that should have had an error.
If a transmit machine is sending D frames followed by a T and then an
errored frame, it will send a the D frames followed by the T followed by a
valid block filled with the E character according to the change to which we
agreed. The receiver should get an error on the frame but if the block of
all E characters is detected as a C frame, it will pass the frame to the
XGMII with no errors and the RS won't detect the error. I think I should
modify the FRAME_TYPE descriptions for C and E to make a frame of all E
characters be detected as an E frame.
Regards,
Pat
-----Original Message-----
From: Ben Brown [mailto:bbrown@xxxxxxxx]
Sent: Thursday, November 16, 2000 10:36 AM
To: 802.3ae
Subject: 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
-----------------------------------------