RE: /E/s and /T/s across the XGMII
Ben,
As I stated at the meeting, one of the things that
I believe should change in the state machine is the
behavior of putting out Error continuously once an
error has occurred.
A better behavior is:
when an error occurs on the input, go to the E state
and send one E code block.
once the input doesn't contain errors, go to the state
that necessary to relay the input.
Part of the reason I prefer this is that it is easier
to diagnose and get to root cause on error situations
when one has a more defined idea of what errors are
being seen and in what kind of situations they are
occurring. Sending continuous error isn't necessary
and it hides information for diagnosis.
Does this resolve the problem you see? I'm not quite
sure I understand your exact concern. Note that the
RS (and the XGXS) will need to tolerate the error
case of a transition from Data to Error to Idle
without a Terminate because an error can hit the
terminate.
Pat
-----Original Message-----
From: Ben Brown [mailto:bbrown@amcc.com]
Sent: Wednesday, October 04, 2000 7:32 AM
To: 802.3ae
Subject: /E/s and /T/s across the XGMII
Bob Grow, Pat Thaler,
Let's take a look at the following (XAUI less) case:
The transmit RS chooses to drive the "Transmit Error
Propagation" encoding across the XGMII during a packet,
as shown in figure 46-4, page 107.
The transmit PCS replaces that and all remaining words
in the packet, including the word with the Terminate,
with some number of 66-bit frames using the 0x1e Type
Field and 8 Cx values of /E/. This is due to the state
transition from the D state to the E state when
TYPE(tx_tobe_coded) equals neither D nor T. When the
RS/XGMII returns to sending Idles, the Transmit PCS
will return to the Z state and send frames with the
0x1e Type Field and Cx values of /I/.
The receive PCS follows the data coming from the
transmitter and pretty much tracks states, transitioning
from state D to state E when the transmitter does. When
it does this, it stops sending Data across the XGMII
and starts sending Receive Error. It does not do this
in just one byte location as depicted in Figure 46-5,
page 109. In fact, this errored packet won't even have
a Terminate value across the XGMII.
I don't think we can fix this by modifying the PCS,
given the limited code space allowed by the 64B/66B
encoding. I think we need to better describe the EOP
over the XGMII in the case of errored packets.
I haven't looked at XAUI/10GBASE-X PCS so I don't
know if the problem also exists there.
Thoughts?
Ben
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-798-4115 - Home
bbrown@amcc.com
-----------------------------------------