RE: XGMII a/k/r and XGXS - PCS Interface
Hello Una,
I have interspersed my comments within your message,
>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?
On detecting atleast one /e/ in an 8 octet group, the simplest solution
for the 64/66
coder is to output a control frame with all /e/ i.e ZZZZ/ZZZZ
where Z holds the 64/66 equivalent code for /e/.
>(Actually, I don't know why ODDD isnt actually represented as ZDDD,
>because ODDD is usually a K*.* with 3 following data bytes).
Actually
1) O and Z are different : There are 8 possible
Zs, and 4 different Os.
2) are encoded differently: Zs are encoded as 6bit
entities with 3bit hamming protection.
while O
have different encoding
3) could come from different sources: based on Brad Booth and Osama
Ishida's drawings,
could
potentially come from the management interface and not
the
RS layer.
pg 2: http://grouper.ieee.org/groups/802/3/10G_study/email/bin00016.bin
pg 3: http://grouper.ieee.org/groups/802/3/10G_study/email/pdf00009.pdf
So it will probably be less confusing to keep different notations.
---------------------------------------------------------------------------
>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?
Having a XGMII i/f will be ideal. If not, the 66/64 coder front end will
have
to do all the requisite "type checking" before encoding. For e.g.,
DDDD/ZDDD is an error and will get encoded as ZZZZ/ZZZZ where Z carries
the 64/66 error code.
Such type checking coupled with state sequence validation, will ensure
only valid
packet formats are encoded.
For state sequence validation, see pg 9 :
http://grouper.ieee.org/groups/802/3/10G_study/public/jan00/walker_1_0100.pdf
>----------------------------------------------------------------
>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.
If we implement "type checking" at the coder front end, this shouldnt be
a problem.
>Regards,
>Una
Regards,
Birdy Amrutur
begin:vcard
n:Amrutur;Bharadwaj
tel;fax:650-857-3637
tel;home:408-244-5553
tel;work:650-813-3357
x-mozilla-html:FALSE
adr:;;3500 Deer Creek Rd. MS 26U-4;Palo Alto;CA;94304-1392;USA
version:2.1
email;internet:bharadwaj_amrutur@xxxxxxxxxxx
x-mozilla-cpt:;8544
fn:Bharadwaj Amrutur
end:vcard