Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: /E/s and /T/s across the XGMII


At 10:31 AM 10/04/2000 -0400, you wrote:
>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.

Lets say in D state the next code to be en/(de)ocded 
is /E/ then the en/(de)coder just should go to state E en/(de)code /E/ and look
for the next code to be encoded and based on the next
code received the state should branch to E, D, T or Z. 

Since /E/ is allowed to appear anywhere it
should not affect the coding of the adjacent codes. 
And an /E/ code in an ethernet frame should not cause
an abnormal truncation of it either. 

>page 109. In fact, this errored packet won't even have
>a Terminate value across the XGMII.

And if things like this can happen on the XGMII interface
then it calls for some coding rules for XGMII interface too.


>Benjamin Brown
>2 Commerce Park West
>Suite 104 
>Bedford NH 03110
>603-641-9837 - Work
>603-491-0296 - Cell
>603-798-4115 - Home