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