Re: [10GBT] Frame delineation in 10GBT
Brett,
I see where I screwed up. I was forgetting the mix of control and data,
and their use of the 10 sync encoding. Doh! Also found where the /T/
is being used. Yes, I was the editor, but it's been 2 years since I've
had to read it again.
Follow-up question, if we have so much padding going on, why are we
worried about "saving" a bit. Why not lose some pad bits, use the
64B/66B as it is and be done with it? It would definitely make writing
the specification a lot simpler.
Thanks,
Brad
-----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 11:24 AM
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: Re: [10GBT] Frame delineation in 10GBT
Brad,
Yes, thank you for clarifying my statement on the error code.
>>As an FYI, E and T are used for XGMII.
>>The /E/ is a XAUI code.
Thanks again, and I promise I won't say "zigmee" either ;-)
Regarding the 64B66B sync bits for the Clause 49 PCS:
There are two valid encodings of the sync bits, 01 and 10.
01 denotes that the block is entirely data bits and the 64-bit data
field follows.
10 denotes that the block is composed with some mix of data and control,
or control only. The remaining 64-bit field is generated based on the
content of the block.
The reception of a 11 or 00 header is an indication there may be an
alignment error.
Since the LDPC has its own framing, we don't need a 2-bit sync field.
Just one bit is enough to determine whether the block is composed
entirely of data bits or contains some control.
I think that the remaining pad bits in the proposal are used to align
the data into conveniently sized LDPC frames and subunits.
Brett
-----Original Message-----
From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG]On
Behalf Of Booth, Bradley
Sent: Tuesday, August 17, 2004 10:56 AM
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: Re: [10GBT] Frame delineation in 10GBT
Brett,
Just a clarification on 46.3.3.2. 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
interpretation?
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
function?
Thanks,
Brad
-----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
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: 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.
>
>
>