Re: [10GBT] Frame delineation in 10GBT
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.
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.
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.
Best Regards,
Brett
-----Original Message-----
From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG]On
Behalf Of Hugh Barrass
Sent: Monday, August 16, 2004 7:38 AM
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: Re: [10GBT] Frame delineation in 10GBT
Brett,
You need to bear in mind that this is a PCS encapsulation - it is
intended for frame delineation in a byte stream. It sits above the PMA
coding and the block code, so there's no need to identify byte
boundaries, hence no need for commas. It cannot transmit error
characters in the middle of a frame. Why is that a major requirement?
Regarding the lane0 rule - I don't understand why that should be a
requirement. The frame encapsulation can be arbitrarily placed on a
bytestream, so there is no need to enforce any equivalent to the lane0
rule. The line code proposed is a 4-D PAM, therefore lane alignment is
given in the bytestream before it reaches the framing.
The main advantage is that it operates on byte boundaries with a simple
state machine. I will not be implementing silicon for this, so I will
leave the final choice to the guys who will. However, I believe that the
64/65 octet encapsulation would be much simpler to design for than the
64b/65b as proposed by Jose in July.
Furthermore, we could consider a more efficient implementation that uses
less padding within the LDPC frame or even uses the 64/65 sync
characters to identify LDPC framing (we would need to think about
implications of that). This could allow the baud rate to be reduced
somewhat.
Hugh.
Brett McClellan wrote:
>Hugh,
>
>After scanning clause 61, it appears to me that 64/65 octet encapsulation as it is now is missing some capability needed in 10GE. Can you clarify?
>
>- Can it handle ordered sets (like LF/RF)?
>- Can it transmit error control characters /E/ in the midst of a frame?
>
>Additionally, I think it would need to be changed to enforce the Lane0 rule for /S/ symbols.
>
>What advantage does this offer versus using 64b/65b grouped in blocks of eight such that they are byte aligned?
>
>
>Best Regards,
>Brett
>
>
>
>
>-----Original Message-----
>From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG]On
>Behalf Of Hugh Barrass
>Sent: Friday, August 13, 2004 10:19 AM
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: [10GBT] Frame delineation in 10GBT
>
>
>Brad et al,
>
>During the discussion on the proposal for framing in 10GBT, I mentioned
>that I thought the 64/65 octet encapsulation used in .3ah (Clause 61.3)
>would be a better proposition than 64b/66b (from .3ae) or 64b/65b (as
>described in the presentation). I know that this is a relatively small
>issue compared to the PAM-8 / PAM-12 discussion but I think that those
>involved in PCS definition would benefit from a good reading of the .3ah
>clause.
>
>The main benefit of the 64/65 octet encapsulation is that it is byte
>oriented and therefore much more straightforward to fit on top of the
>byte oriented LDPC coding. It has a very low overhead (1/64, duh!) and
>does not have any alignment issue with odd size frames. It also supports
>IPG compression (although that is not relevant for 10G) and has some
>spare codepoints for adding in prequalizer feedback data if required.
>
>It might also be worth considering the use of 64/65 to cover the dual
>function of LDPC block delineation as well as Ethernet frame
>delineation. This would require the use of some more codepoints for
>block flags, but shouldn't be difficult to achieve. I believe that we
>could get a PCS encapsulation that is significantly simpler to define
>and implement as well as being more robust and less overhead.
>
>If anybody is interested in this, I'd be willing to go through it in
>more detail - or else let me know that I am wasting my breath & I'll
>drop the subject.
>
>Hugh.
>
>
>