| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Brad, Rich, Ben, Rick,
Commenting on Brad's latest drawing:
-----------------------------------------
I agree with your current summary of what crosses the XGMII interface,
and the XAUI interface. One thing that would need to be captured, though,
is the restriction in what can cross each byte lane - for example the /s/
can only be present in XGMII lane 0.
However, what is being carrier across the medium is not 10B codes, but
64b/66b codewords (in a serial PMD case) which are much more restricted:
Data Codewords
or
Mixed Data/Control Codewords
These are then sub-typed to
DDDD/DDDD
ZZZZ/ZZZZ
ZZZZ/SDDD
TZZZ/ZZZZ and all other 7 EOP options
+ new proposals for ODDD etc.
I don't know what code sequences were planned for mapping /e/ combinations,
but lets assume that is covered also - Rick, had you thought about this?
(Actually, I don't know why ODDD isnt actually represented as ZDDD,
because ODDD is usually a K*.* with 3 following data bytes).
---------------------------------------------------------------------------
Another subject to tackle from this drawing is the interface between
the XGXS block and the PCS block in the PHY.I had proposed that this interface
be XGMII. This would require an XGXS Receive state machine, which would
handle error conditions (illegal framing conditions, errors, illegal
K character combinations, loss of sync) or as Rick Walker put it so clearly:
>>
>> "clean up your trash, put your fire out,
>> scatter the ashes, and restore your camp to the way you found it".
>>
and then a PCS Transmit state machine would map from XGMII into 66b
codewords.
However, if this proposal seems overly complex, then I think you have to
look at the alternative, which involves a 'simple' mapping table from
XAUI stream to 64b/66b Codewords, without a state-machine. This all works
beautifully when there are no errors. There is a 66b codeword defined for
all expected HARI sequences. But what happens when an error occurs:
Consider a case where 1 of the 4 HARI deserialisers in the PHY looses bit
alignment (moves off by one bit). We now have a problem where the receive
sync state machine on that lane will lose sync, and the decoded 10B stream
will have errors. In 1000BASE X PCS Receive, we would have terminated the
packet with error, and ignored 10B input until SYNC_ACQUIRED became true.
In my proposed XGXS Receive statemachine, this could equate to terminating
the packet with XGMII /e/ and /t/ flagging bad packet. Then the PCS transmit
state machine would map this into a 66b codeword indicating packet errors
If there is no state-machine, what will the PCS output? If XGXS continues
to present illegal codes, we want to ensure the packet gets terminated
correctly, but how is this achieved in a predictable fashion?
----------------------------------------------------------------
Another question that I have, which relates to the XGXS - PCS interface
comes from the 66b Codeword summary:
Take the case of a codeword ZZZZ/ZZZZ. The PCS does not need to place any
constraint on the specific Control characters carried - for example if
it was requested to map eight 'K28.7 Type' characters in sequence, it would
happily do so. I don't expect that there will be any restrictions here,
except to conform to one of the 66b Codeword types.
Therefore - if the XGXS (in the PHY) does not 'clean up' in error
conditions, then the PCS will end up transmitting illegal sequences. We are
now propagating a local XAUI link problem to the outside world, which seems
unnecessary. So I see this as another good argument for getting the XGXS to
decode back to an XGMII interface, and let the PCS work with this as a
starting point.
Regards,
Una
-----Original Message-----
From: Booth, Bradley [mailto:bradley.booth@xxxxxxxxx]
Sent: 06 April 2000 23:31
To: HSSG
Subject: RE: XGMII a/k/r
Ben,
I used lower case letters to avoid confusion between what XAUI uses and what
the XGMII uses. I had the /O/ code-group generated and terminated in the
PCS, instead of the RS. Plus, like you noticed, I took out /RF/ and /BL/.
I was going to use a different coding for what is on the MDI, but I didn't
want to create too much confusion.
Cheers,
Brad
-----Original Message-----
From: Brown, Ben [BAY:NHBED:DS48]
[mailto:bebrown@xxxxxxxxxxxxxxxxxx]
Sent: Thursday, April 06, 2000 4:30 PM
To: HSSG
Subject: Re: XGMII a/k/r
Brad,
Other than the missing /RF/ and /BL/
code-groups/characters/bytes
or whatever we're calling them these days, how is this
picture
different from page 2 of Rich Taborek's original collection?
Ben