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

Re: [802.3_EPLCA] Updated minutes for 10/22 and deadline to request a presentation

Hi George and Arvind et al,

TL/DR:  Agree w/ George.

WRT to CFI and study group's "study charter", it is limited to improving latency and latency variations associated with PLCA to help meet control loop applications in automotive, robotics, and other segments.  Doing anything else would be a bait-&-switch.

This said, there are several pent up needs to improve bit rate, coding, PHY electricals, , etc.  These should be explored via established process (essentially a new CFI directly or via NEA if it is a brand new concept and then to CFI).  I would encourage them and may participate but not in the eventual task force that would address "PLCA improvements", not PHY improvements, which could run in parallel of one forms.   Now if the ONLY way to improve PLCA is via new PHY, that would be in scope.   So all the technical feasibility contributions (all of them) have been incredibly useful.

best

Yong.



On Thu, Oct 29, 2026 at 10:52 AM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:

Just to be clear, the phy rates we quote are the information rate, not the line rate on the medium of PCS-encoded symbols.

Thank you for the clarification that you intend to use the same DME symbol timing. It isn’t quite clear how that works if the Ethernet rate is actually 12.5 Mbps.  If the 80 nsec DME timing is kept, then the ethernet rate is something a little less than 12.5 Mbps (to account for different encoding) which is a strange rate for ethernet…

 

Changes to the delay table should be viewed with caution – and are quite concerning.  Every time 802.3 has touched that it is more complex than it looks.  Lots of interaction with the MII and the MAC timing, and it requires multiple corner cases to be worked.  Half duplex and compatibility with the MII is hard.  Remember, blocking of encoding and changing that has impact on delays in the phy itself.  FWIW, I don’t see any reason for an 802.3 standard to

 

Regardless, while the MAC is rateless, parameterization is in terms of bit times which are defined.  Where is the Ethernet bit time defined for the PHY mod you are describing?  Nowhere.  We’d have to do it – that makes a new PHY, or substantially changes the PHY specification to describe a new Ethernet rate.

 

Ethernet projects for decades have been described in terms of either interfacing with an existing Ethernet rate or defining a new Ethernet rate.  There is currently no nominal 12.5 Mb/s (or close) Ethernet rate.  In short, adding a 12.5 Mbps Ethernet rate is, in my opinion, outside the announcements of the CFI and outside the scope of the chartering motion and the project – which doesn’t mention the PHY.

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: Subramaniam Aravindhan <Subramaniam.Aravindhan@xxxxxxxxxxxx>
Sent: Thursday, October 29, 2026 8:47 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-EPLCA@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPLCA] Updated minutes for 10/22 and deadline to request a presentation

 

Hi George,

 

   Thanks for the clarification on the PAR and the objectives.

 

   The PHY rate is already 12.5 Mbps (80 ns bit rate) and we are not changing the rate and there is only one rate for both PLCA and EPLCA.

 

  Yes, as you have pointed out Table 147-6 and Open Alliance compliance tests have some critical timings and these need to be analyzed carefully. My initial analysis is, only PCS needs update for 4B/5B change and end of frame change; of course, need to do more analysis to cross check that there are no other changes in PMA needed.

 

   Since we are adding an elasticity buffer in the PCS, it is expected to increase the Tx and Rx delay since PCS layer is defined as part of the PHY.

  • Table 147-6, 1st row:  The Tx-Delay is expected to increase by one nibble timing (PCS needs to wait for two 4-bit nibbles from PLCA to form a 5-bit data to PMA).  
    • “TX_EN/TX_ER sampled to MDI output” delay: Not clear why the spec has tight timing requirement here, PLCA is expected to start sending COMMITs even before TX_EN.  
  • Table 147-6, 6th row: The RX data path delay is expected to increase by 3-4 nibble timing as we have to strip the “Length” information.
    • Likely we have enough margin since the max delay is 4 uS. The 2nd row CRS timing is more critical, and it is not expected to change.

 

The MAC layer timers are already defined in terms of bit rate, and hence not expecting changes in MAC due to data rate change from 10 Mbps to 12.5 Mbps (or 2.5 MHz clock to 3.125 MHz clock).

 

Thx,

Arvind

 

From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, October 27, 2026 5:36 PM
To: Subramaniam Aravindhan <arvind@xxxxxxxxxxxx>; STDS-802-3-EPLCA@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPLCA] Updated minutes for 10/22 and deadline to request a presentation

 

Regarding the “PAR template” and objectives, I think you are confused – the objectives aren’t part of the PAR.  The objectives are an 802.3-level document, and can be modified by the working group.  The PAR, however, is submitted through the standards committee (LMSC) and approved (or not) by the IEEE SA Standards Board (SASB), with recommendation by NesCom.The actual questions to be answered in the PAR are controlled by the SASB and contained in an online PAR form - the “major” questions are in the presentation you list.

 

Regarding new PHYs and ethernet rates, you’d need to change more than the PCS.  You’d have to change text not just in clause 147 and 188, but in all the descriptions of the 10BASE-T1S PHY in 802.3 to indicate that the phy can be 12.5 Mbps PHY in certain scenarios (if you are adding it as new option to the existing PHY giving it an alternate rate), and adding a way for management to show this (especially since there are no MDIO registers in the RS).  If instead of making it an option, you’d be making a new PHY type, 12.5MBASE-T1M, you’d need to make that definition in all the right places.

In doing so, in addition to the PCS, you’d also need to at least change the PMA, if only because the DME timing is located (not saying there isn’t more), and, maybe more concerning, the delay table, Table 147-6, which was difficult to balance and debug in 802.3cg/802.3da, will likely need adjustment for the new rate.  Many of these values and details depend on the Ethernet bit time at the MII, and the delay isn’t allocated to the PCS or the PMA (because what matters is the delay between MII & the medium) but can be located anywhere between the MII and the MDI.

Regarding formal scope, there is the small matter that the CFI did not mention changes to the PHY, addition of a 12.5 Mb/s rate, and instead focused on PLCA, and the chartering motion for the study group, below from the July 2026 minutes, which specifically focuses on PLCA, and not the PHY.

MOTION #21

Move that the IEEE 802.3 Working Group request the formation of a Study Group to develop a Project Authorization Request (PAR) and Criteria for Standards Development (CSD) for Physical Layer Collision Avoidance (PLCA) Multidrop Latency, Jitter, and Scalability Enhancements.

 

While the MII clock comes from the PHY, and Table 4-2 lumps everything less than 100 Mb/s into one column, it parameterizes by bit time and in order to do that, you need to understand the relevant Ethernet rates.  Adding a 12.5 Mb/s rate to Ethernet would change the underlying bit time, and effect these timings of a half-duplex MAC – further expanding the project’s scope for compatibility.

 

Ethernet is an intricate web that survives because we observe the layers and the boundaries we sign up to. I hope this helps you understand.   Much of PLCA is the way it is because we were specifically fitting into the definitions of the 10 Mb/s half-duplex MII and MAC definitions. Those would need to be reexamined with any change to timing.

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

From: Subramaniam Aravindhan <0000649de2e66a52-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, October 27, 2026 4:51 PM
To: STDS-802-3-EPLCA@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPLCA] Updated minutes for 10/22 and deadline to request a presentation

 

Hi Natalie and all,

 

  Few more thoughts on the 4B/5B change proposal in the PCS layer:

 

>>A participant asked if the presenter was proposing to change the MAC data rate to 12.5 Mb/s.  The presenter answered in the affirmative.

>>Ms. Wienckowski stated that changes considering changes to the MAC data rate were beyond the scope of the CFI and the Study Group’s charter.

 

  • The 10BASET1S is already using 12.5Mbps transceivers and we are not making any changes to the medium, or transceiver, or multidrop method.
  • In a shared medium multi-drop protocol, for example whether a node gets 1Mbps or 1.25Mbps bandwidth is transparent and does not affect upper layer protocol; only helps.
  • The changes are localized to PCS layer and there are no changes in MAC. In the MAC MII interface definition, the clock is input to MAC and controlled by PCS/PLCA.
  • We are still backward compatible, and this capability would be enabled only in the context of EPLCA when all the nodes are of EPLCA type in a zone.
  • 25% improvement with a limited changes to PCS layer is still a good performance improvement. Especially the bandwidth requirements of the new zonal applications are only going to keep increasing. The layer-3 and above protocol overheads are also increasing in automotive applications due to timestamping requirements and other header overheads. Compared to CAN, the Layer-2 and above layers overhead in ethernet is much higher which already reduces usable bandwidth. For example, with a 64-byte payload we are already at ~64-byte of overhead due to Layer-2, and Layer-3; which is 50% usable bandwidth.

 

On the PAR, don’t we have to follow the following template? Where does the “PLCA Enhancement SG Objectives” slides fit in the PAR?

      PAR.pptx

 

Thx,
Arvind

 

 

From: Natalie Wienckowski <natalie@xxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, October 27, 2026 11:46 AM
To: STDS-802-3-EPLCA@xxxxxxxxxxxxxxxxx
Subject: [802.3_EPLCA] Updated minutes for 10/22 and deadline to request a presentation

 

Dear Colleagues,

 

I have updated the minutes for October 22nd to add the following to the notes on Enhanced PLCA (EPLCA) –Technical Feasibility Study For Predictable Max Latency –Study3

A participant asked if the presenter was proposing to change the MAC data rate to 12.5 Mb/s.  The presenter answered in the affirmative.

Ms. Wienckowski stated that changes considering changes to the MAC data rate were beyond the scope of the CFI and the Study Group’s charter.

 

Please keep in mind the scope of the CFI and the Study Group's charter as you prepare presentations for the upcoming Plenary.  If you plan to attend and have not yet done so, please register for the meeting and pay the required meeting fee.  While you do not have to be a WG voter to vote in the Study Group, you are still required to pay all necessary meeting fees to participate.

 

Here is a reminder of the deadline to request time to present:

 

November 9-12, 2026 (Plenary) (Requests due AOE October 29, Presentations due AOE November 3)

Priorities during the meeting:

  1. Respond to comments from other 802 groups on our PAR and CSD submissions
  2. Discussion and approval of Objectives
  3. Other presentations

Thanks,

 

Natalie Wienckowski

In-Vehicle Networking Solutions LLC

IEEE P802.3dm Chair and Chief Editor

IEEE P802.3 EPLCA SG Chair Pro Tem

natalie@xxxxxxxxxxxxxxxxxxx

To unsubscribe from the STDS-802-3-EPLCA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1

To unsubscribe from the STDS-802-3-EPLCA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1

To unsubscribe from the STDS-802-3-EPLCA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1

To unsubscribe from the STDS-802-3-EPLCA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1