| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Brad, 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. Hugh. Booth, Bradley wrote: 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: |