Hi Natalie and Bob— Piling on with Bob and Natalie---the overview should be just that---a high-level summary that shows a basic view of the operation. As Natalie, says, you DON”T want too much detail because it may get out of sync with the normative text. We suffer from this problem too much as it is, with detailed text descriptions of state machines that can frequently cause confusion when the text is (unintentionally) not the same as the state machine. Regards, Steve Steven B. Carlson Chair, P802.3cy Greater than 10 Gb/s Electrical Automotive Ethernet PHY Task Force Executive Secretary, IEEE 802.3 Ethernet Working Group http://www.ieee802.org/3/index.html
President
High Speed Design, Inc. Portland, OR
scarlson@xxxxxxxxxxxxx From: NATALIE WIENCKOWSKI <nwienckowski@xxxxxxx>
Sent: Monday, March 29, 2021 12:48 PM
To: STDS-802-3-OMEGA@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_OMEGA] D1.0 comment #52 I prefer your method of having fewer details for an overview. If you have details in the overview, you need to be careful to keep this in sync with the requirements as the draft progresses. It is very easy to forget to do this and to have the items be out of sync.
Rubén, My proposed text is intended to be a high level overview — basically only describing the structure of a Transmit Block. I intentionally didn’t include much detail on how the parts of the Transmit Block are built. When I wrote my proposed text, I went to each referenced subclause and immediately found duplicate text (compared to the D1.0 Overview) of how that part of a Transmit Block was created with appropriate shall statements for conformance. I proposed deleting that detail from the D1.0 overview text. You go back to the style of lots of detail in your proposed PHD text. To me, the important thing for an overview is to make the point that the PHD is sent in multiple Transmit Blocks. That point is included in your proposed text, but can get lost in the detail you provide about the RS-FEC. This is a matter of style though and I am happy to go either way the TF chooses. —Bob
Dear Luisma, all, I've been working on a proposal for the PCS introductory paragraph, per comment 52. I realize that Bob already made a proposal in his comment 184, and I used it as a baseline, modifying the adopted nomenclature approved per comment 59. By the way, in case that this comment resolution is accepted, comments 54, 189, 191, 192 and 195 are also resolved, because the commented text has been replaced. The proposal is the following: "The BASE-AU PCS manages interleaving of xMII data streams with physical layer control information. The fixed-length Transmit Block provides the structure for time division multiplexing these two streams of information. A frame from the xMII can be contained in one or more Transmit Blocks, and xMII frame boundaries have no correlation to Transmit Block boundaries.
On the transmit path, the PCS repeatedly encodes 64-bits (8 octets) of the xMII data stream into 65-bits blocks using 64B/65B encoding (see 166.2.3.4). The encoded xMII data stream is also referred to as the payload.
The physical layer control is organized into a 224-bit long block called Physical Header Data (PHD) (See Table 166-2). The PHD is followed by the result of CRC16 calculation. The resulting 240-bit block is encoded using an interleaved Three Repetition Code (TRC) (See 166.2.3.3.4), which generates a 720-bit sequence called encoded PHD.
The encoded PHD is divided into a series of 20-bit long encoded PHD sub-blocks. Each 20-bit encoded PHD sub-block is placed in the Transmit Block after 80 65-bits blocks of payload. Each sequence of 80 65-bits blocks followed by a 20-bit encoded PHD sub-block is processed by a systematic RS-FEC (544, 522) code over Galois Field 2^10, which appends a 220-bit parity, producing 5440-bit RS-FEC code-words. A Transmit Block holds 36 RS-FEC codewords.
A Transmit Block is scrambled with an additive scrambler before transmission. The scrambler uses an LFSR that is initialized to a pre-defined value at the beginning of each Transmit Block.
On the receive path, the BASE-AU PCS performs the additive de-scrambling, decodes received RS-FEC codewords, and separates the payload from the control information. The received payload is 64B/65B decoded to create the xMII receive data stream. A series of received 20-bit PHD sub-blocks are concatenated and TRC decoded to reconstruct the PHD followed by a CRC16 (see 166.2.3.3). PHD information reliability is checked by CRC calculation and, if it is correct, then it is fed to state diagrams. PHD information exchange with the link partner provides bi-directional link monitoring, PHY control, capabilities announcement, and BASE-AU OAM message communication. (See Table 166-2)." Kind Regards, Rubén Rubén Pérez-Aranda
CTO at KDPOF _____________________________________________________________ Knowledge Development for POF, S.L. A: Ronda de Poniente 14 2º CD, 28760, Tres Cantos (Madrid), Spain P: +34 91 804 33 87 Ext:110
To unsubscribe from the STDS-802-3-OMEGA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-OMEGA&A=1
To unsubscribe from the STDS-802-3-OMEGA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-OMEGA&A=1
To unsubscribe from the STDS-802-3-OMEGA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-OMEGA&A=1
To unsubscribe from the STDS-802-3-OMEGA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-OMEGA&A=1 |