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

Re: [10GBT] Frame delineation in 10GBT


You are correct that the 2 extra bits in 64b/66b allow for descrambling the bit stream - which is redundant when above LDPC. However, they also denote frame boundaries using the control codes. In Jose's proposal for 54b/65b he uses the fact that the block alignment is already given to reduce the sync from 2 bits down to 1 bit. The last bit could not be dropped as it must denote whether the next 64 bits are all data or whether there is a control code & a mix of control and data.

I will respond to Brett's other points later, although I don't see any downside to using the 64b/65b if the PHY vendors are happy with the bitwise nature. In EFM, 64b/66b (or derivations from it) was rejected because the PHY vendors wanted something byte oriented. As an aside, because the blocks are aligned, we could use an even more efficient code - say 512b/513b, combining the control code structure of the two encapsulations.


Booth, Bradley wrote:

Just a clarification on  There is a code in the XGMII (TXC = 1
and TXD = 0xFE) that is used to signal to the PCS to generate an error.
The PCS does not pass this error code but rather is responsible for
generating transmit data at the local device that when received at the
link partner's receiver will be interpreted as an error.  I believe what
you're trying to state is that Clause 61 PCS does not indicate that
there is an error code in Table 61-11.  Is that a correct

As an FYI, E and T are used for XGMII.  The /E/ is a XAUI code.  I don't
think that /T/ exists in 802.3ae.

As for aligning to Lane 0, I believe that is a moot point.  There are
many ways to align the octets to provide the correct sequence of
information across the XGMII.

As I look over the 64B/65B proposal, I do have a few questions.  The two
sync bits from 64B/66B was required by the PCS synchronizer to determine
the frame alignment so that the 64-bit data was descrambled.  The sync
bits plus the descrambled data were then decoded for XGMII mapping.  If
LDPC has its own framing and has pad information for passing control
information, then why do we require the extra bit?  From the information
I've seen on 64B/65B, the PHY control/pad bits could be used to serve
the same function that the control performs in 64B/66B.  Is the extra
bit supposed to perform any alignment/sync function?  If not, then is it
not redundant with the pad bits available?  If it is supposed to align
or help find the 64-bit data, then how can a single bit perform that


-----Original Message-----
From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On
Behalf Of Brett McClellan
Sent: Tuesday, August 17, 2004 9:42 AM
Subject: Re: [10GBT] Frame delineation in 10GBT


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:
" 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

Regarding the Lane 0 rule, according to Clause 46:
" 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,

-----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
Subject: Re: [10GBT] Frame delineation in 10GBT


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


Brett McClellan wrote:


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,

-----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
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

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
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.