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

Re: [802.3_B400G] Oct 2022 Series Webpage Update

Hi Adee

Not only do I expect modules to support different channels, they already do so today using CTLE which has more than two choices. This has been a solved problem for decades. Multi-rate goes back to the early FC and datacom/telecom modules.

We have been lucky for many ethernet generations in having a single SerDes support different channels with acceptable power penalty. It's been so successful that we have started to think that's the way the world was meant to be. Unfortunately that free ride is over.

A SerDes configurable for two different channel losses is not going to be as low power as one optimized just for the lowest loss channel, but it's a start. My prediction is that when 200G/lane ships in high volume, it will only use XSR, because burning the extra power seems gratuitous. However, we are not proposing to only specify a low loss channel, but rather have a high  and low loss channel. Users can then decide how best to solve their application(s). When we get to 400G/lane, no one will even suggest that we should support the VSR channel.


On Sat, Sep 24, 2022 at 1:15 PM Adee Ran (aran) <aran@xxxxxxxxx> wrote:


You suggested below that “we should write multiple specifications to adequately meet the need of mushrooming applications”.

One of the specifications suggested is •               New XSR for NPO, twinax-over-PCB, active copper, and XSR front pluggable“. If we go down that path, a module built to support only the “XSR front pluggable” specification would not be pluggable into a “VSR front pluggable” port, right? You know about module R&D more than I do – do you expect different modules to be designed for each specification?

The way I look at it is, a module should support all possible hosts it may be plugged into. At 200G/lane it does require a fairly capable and flexible module, but supporting the “longer” ports would enable supporting the “shorter” ones too (with possible configuration, link training etc.). And assuming high-loss high-radix switches are a significant market potential, I would expect the “longer” port specification to support this application.


My next logical step is that is for C2M in all front panel pluggable form factors, one specification is required. Other specifications may be useful for other form factors, but I have not seen any contributions advocating for such form factors yet.





From: Chris Cole <chris@xxxxxxxxxxxxxxx>
Sent: Saturday, 24 September 2022 22:53
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update


Hi Upen


Sounds like the making of an excellent contribution. 


I received several private emails, asking what is a XSR front pluggable application. It may be helpful to others to share the explanation using an example from the CR discussion. 


The following link diagram has a 7" C2M to PCB trace length.



When first presented, some may have been confused, as I was, how it's possible to divide 19" in half, add a few more inches, and get 7". Perhaps it's the new math. 


Fortunately, Leesa came to the rescue and explained that outrigger modules are connected with internal cable:



while center modules have the shorter direct PCB trace connection. 


We will probably quible whether 7" is the right max PCB trace number for XSR because it doesn't seem worth it to have a specification that's only a couple of inches short of VSR functionality. Something like 4" seems more sensible. However, this gives us the idea of the application. 


It also lets us get a ballpark loss number for XSR loss. If we use the previously discussed 9.5dB for the ASIC, 5dB for the module, 1.4dB/inch PCB trace loss, we get ~20dB total loss. 


Upen, what number would you suggest for XSR loss?


Thank you




On Sat, Sep 24, 2022 at 8:26 AM Upen Reddy Kareti (ureddy) <ureddy@xxxxxxxxx> wrote:

Chris and all
Include me in these efforts.
note XSR and loss ranges depends on How large the radix of the switch – as large scale switch will have higher losss contribution.

I have studied all the with respect to 100T switch for

C2M applications – PCB host, cabled host, Hybrid including CPC and NPC to reduce the required overall loss consideration for low power serdes
XSR/XSR+ applications – CPO/NPO
let us discuss these in detail.


Thanks Upen


From: Chris Cole <chris@xxxxxxxxxxxxxxx>
Reply-To: Chris Cole <chris@xxxxxxxxxxxxxxx>
Date: Friday, September 23, 2022 at 6:32 PM
To: "STDS-802-3-B400G@xxxxxxxxxxxxxxxxx" <STDS-802-3-B400G@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update


Dear IEEE 802.3df Participants, 


I trust everyone rushed to review next week's material as soon as John announced its availability, and discovered the excellent exposition by Mr. Lusted. For those with limited time and trying to decide which presentation to read, may I kindly call your attention to:



As always, Kent is gently steering us towards wisdom, which for some of us who prefer the more direct approach, is a bit too old school. 


What's clear is that a single large loss AUI C2M is no longer sufficient and we should write multiple specifications to adequately meet the need of mushrooming applications, specifically:


  • Traditional large loss for LR backplane, CR passive DAC, and VSR front pluggable 
  • New XSR for NPO, twinax-over-PCB, active copper, and XSR front pluggable

Obviously the exact loss is TBD, however a good start for the XSR value are the shorter reach examples in last year's presentation by Sam and Nathan. 



In off-line discussions, there has been a lot of interest in XSR's potential to save power, which we will direct into a proposal for the next meeting. For those that would like to join us in contributing or reviewing, please send me an email so that we can put you on copy as we iterate a draft. 

Thank you






On Fri, Sep 23, 2022 at 1:12 PM John D'Ambrosia <jdambrosia@xxxxxxxxx> wrote:


The webpage for the Oct 2022 Series has been updated with all presentation material for next week -

The proposed PAR modification to IEEE P802.3df and the proposed IEEE P02.3dj PAR have been uploaded.

I wish to highlight the proposed PAR modification to IEEE P802.3df-  As previously noted, I was working with Mr. Law on getting the PARs entered into the MyProject system.  An issue has arisen that has not currently been resolved –

For the proposed PAR modification to P802.3df, the date for Item 4.2 could not be entered as presented to the Task Force.  The date proposed to the Task Force was Nov. 2023, however, the MyProject system will not permit entry of a date earlier than Jan 2024.  Mr. Law has contacted IEEE SA Solutions Support regarding this issue.  At this time the date of Jan 2024 has been entered for Item 4.2 with the following noted entered for 8.1 –

Item 4.2: The earliest date that Myproject would allow to be entered is Jan 2024. This prevented the entry of the desired date of Nov 2023. (A bug report has been submitted to IEEE SA Solutions Support. This item of the PAR will be updated to the desired date of Nov 2023 and this note deleted immediately upon a solution being provided.)

For the consideration of the Task Force - the motion to adopt this proposed PAR will be modified to allow modification of the PAR in accordance with the note above.


John D’Ambrosia

Chair, IEEE P802.3df Task Force

To unsubscribe from the STDS-802-3-B400G list, click the following link:

To unsubscribe from the STDS-802-3-B400G list, click the following link:

To unsubscribe from the STDS-802-3-B400G list, click the following link:

To unsubscribe from the STDS-802-3-B400G list, click the following link: