Re: [10GBT] Frame delineation in 10GBT
Brett,
Replies in line:
Brett McClellan wrote:
>Hugh,
>
>According to Clause 46, the PHY must be capable of passing both the Local Fault (LF) and Remote Fault (RF) messages. In the XGMII, these are ordered sets.
>It appears that the 64/65 octet encapsulation only supports one "out of sync" message.
>
For EFM copper, the RF & LF were carried in the block coding overhead.
10GBT could do the same or else it would be trivial to add a byte or two
of information to the "out of sync" message.
>
>Regarding the Error character, according to Clause 46:
>"46.3.3.2 Conditions for generation of transmit Error control characters
>If, during the process of transmitting a frame, it is necessary to request that the PHY deliberately corrupt the contents of the frame in such a manner that a receiver will detect the corruption with the highest degree of probability, then an Error control character may be asserted on a transmit lane by the appropriate encoding of the lane's TXD and TXC signals."
>
>Since the PCS cannot pass Error characters, I assume the PCS will prematurely terminate transmission of a frame upon reception of an /E/. First, this does not meet the requirement of clause 46.
>Second, if the Terminate character at the end of frame is replaced by /E/ at the RS, this PCS (as it is currently specified) will not make any distinction between the /E/ and the /T/ and the frame will be passed as normal.
>
This is really a matter of granularity. For both 64b/66b (similarly
64b/65b) and for 64/65 octet, the error will be reflected in the next
codeword. The difference is that the codeword granularity is 64 bits in
one case 512 bits in the other case. The question is, how much does that
matter?
>
>Regarding the Lane 0 rule, according to Clause 46:
>"46.3.3.3 Response to received invalid frame sequences
>The 10 Gb/s PCS is required to either preserve the column alignment of the transmitting RS, or align the Start control character to lane 0. The RS shall not indicate DATA_VALID to the MAC for a Start control character received on any other lane. Error free 10 Gb/s operation will not change the SFD alignment in lane 3. A 10 Gb/s MAC/RS implementation is not required to process a packet that has an SFD in a position other than lane 3 of the column following the column containing the Start control character."
>
>The Lane 0 rule would not be applied at the PMA, but must be enforced at the RS/XGMII. Therefore the PCS must be able to enforce this rule. The 64/65 octet encapsulation does not.
>
>I'm not against the idea of an octet based PCS, however I do not think it is as easy as just selecting the PCS from Clause 61 since it lacks some fundamental capabilities that the 64b/65b PCS supports.
>
I think that this issue is completely orthogonal to the encapsulation
coding.
A receiving PCS must extract a packet stream from the incoming bit (or
byte) stream. It must then align the start codes of those packets
appropriately on the XGMII. This is the same for any encapsulation,
there is no advantage for either method.
Once more, I'll state: I don't have a problem supporting 64b/65b
(although I dislike the amount of padding that requires a raw bit rate
of >11.8Gb/s for a 10Gb/s link). I had thought that PHY developers would
prefer a byte oriented encapsulation that could also be used for LDPC
code block delineation if needed. If you (and other PHY developers)
consider that this is not sufficient advantage and that 64b/65b is
preferable, then I will drop the subject. I will not be designing any
PHYs anytime soon (unless someone pays me a lot of money!).
Hugh.