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 All,

This is starting to sound like the discussions around insertion loss (IL) budgets we’ve had in the past. I realize IL is a strong factor but perhaps it gives the wrong message.  One problem is IL works great as long as topologies are very similar. I don’t think we are moving that direction. I agree we can classify and set goals according to IL but relative SNR seems prudent too.  I think it would be useful to somehow introduce an implementation penalty  (ImP) based on SNR differences between the low power solution and the high loss solutions.

 

For example, say the <xx dB channel (say 20 dB) become the first channel set.  So,  ImP could be 0 dB for these. Now consider the between xx and yy dB  channel (say 20 dB to 36 dB) set. Maybe the acceptable ImP is -6 dB or something else we can determine.  

 

I’m struggling with how ImP be can made palatable for standards audience consumption.

 

I did a “COM lite” simulation with the akinwale_3df_01_2209 channels with no crosstalk, jitter, or noise using a FFE3/DFE1.

It sort of suggest there is a  -6 dB COM penalty between 20 dB and 36 dB die to die insertion loss. If we start to add in crosstalk, noise, and jitter the data would change. Perhaps you folks can embellish with this. See data below.

 

… Rich

 

 

COM      "IL Die to Die"

(db)        (dB)

3.4         15.5

3.5         16.3

3.2         17.3

3.3         18.0

3.4         19.0

3.4         19.8

2.6         21.5

2.2         22.4

2.0         23.3

1.9         24.1

2.1         25.0

1.6         26.7

1.6         27.6

1.4         28.4

1.0         29.3

0.1         31.0

-0.5        31.9

-0.5        32.8

-1.1        33.6

-2.2        35.3

-2.9        36.2

 


Richard Mellitz,
Samtec Southeast
Office: 803-908-4411
www.samtec.com

From: Chris Cole <chris@xxxxxxxxxxxxxxx>
Sent: Wednesday, September 28, 2022 4:51 PM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

Hi Ali

 

70 deg C is not a good number for hyper-scaler data center ambient temp. Perhaps a better PCB loss from Brandon's presentation is 1.5dB/in. I will stick with 9" VSR reach as that has been the presented worst case, which gives 6.8dB XSR trace loss. 

 

3dB IC plus 5dB connector/plug/PCB is a lot and does not allow for design trade-offs like better connector. However, this is nickel and diming the total, which is better done later. 

 

Mostly using your numbers:  7.5 + 6.8 + 8 = 22.3 dB XSR line card loss.  

 

So perhaps the 22dB number in Kent's presentation is the right one. 

 

Chris

 

On Wed, Sep 28, 2022 at 12:40 PM Ali Ghiasi <aghiasi@xxxxxxxxx> wrote:

Hello Chris,

 

As you recall Adee’s package loss for 30 mm should go down by about 2 dB after correction for surface roughness.

Linecards require 10” of PCB, Brandon best loss reported at room temp was 1.35 dB/in and I expect this loss will be at least 1.65 dB worst case at 70 ºC.

The updated tally would be:

ASIC - 7.5 dB (30 mm trace)

PCB - 16.5 dB

Connector/plug - 5 dB

CDR - 3 dB

Total Loss = 32 dB for conventional AUI so under 36 dB is not a bad number😉

 

Thanks,

Ali Ghiasi

 

 



On Sep 28, 2022, at 12:07 PM, Chris Cole <chris@xxxxxxxxxxxxxxx> wrote:

 

Hello Upen and Adee,

 

I now see the wisdom of John and Kent steering us away from NPO and CPO. I don't know what came over me to doubt them.  I am now repentant. 

 

Below is the baseline model for a front pluggable XSR line card. I am using the original OIF definition of XSR which is the same C and M at both ends as VSR but half the reach. If we use 9" to for the PCB trace reach for standard front pluggable VSR line cards, that gives us 4.5" for XSR. Here is the budget:

 

image.png

 

I don't see anything terribly aggressive here.

 

30dB application has been mentioned by others on the call and in Uppen's email. I am sure that's a wonderful application, it's just not this one.

 

As per Kent's suggestion on the call, 30dB should be considered the "low AUI" mode for the 36dB spec., in which the 36dB is the "high" AUI. 

 

Chris

 

On Wed, Sep 28, 2022 at 11:37 AM Adee Ran (aran) <0000147b29386f6c-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Joshua,

I asked about front panel pluggable because this is the area where we have some channel/package contributions. With these I can use to run analysis and explore what operation points we can suggest (equalization, DER, loss combinations).

I would be glad to do similar exploration for NPO/CPO but unfortunately there are no channel and package contributions in this area.

I see that there are some proposals already for how CPO/NPO AUI will look like and even how much power will be consumed without channel data – but I’m not smart enough to do that.

 

</Adee>

 

From: Joshua Kim <joshua.kim.6b@xxxxxxxxxxxxx>
Sent: Wednesday, 28 September 2022 21:24
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

Dear Adee,

I replied to Ali about your email.

Am I correctly understanding that you brought the options based on Straw poll #1?

BR, Joshua

 

From: Ali Ghiasi <aghiasi@xxxxxxxxx>
Sent: Wednesday, September 28, 2022 11:20 AM
To: Joshua Kim <joshua.kim.6b@xxxxxxxxxxxxx>
Cc: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

Hello Joshua,

 

Correct option III, is not for front panel pluggable and will address NPO/CPO applications.

 

Thanks,

Ali Ghiasi
Ghiasi Quantum LLC
Office (408)352-5346

 

 

 

On Sep 28, 2022, at 11:17 AM, Joshua Kim <joshua.kim.6b@xxxxxxxxxxxxx> wrote:

 

Hi Ali,

We had two straw polls today.

I see your option ‘III’ is not from the first straw poll result which aimed to ‘Front panel pluggable assumed option’ only which I believe Adee opened the dialog based on.

Please correct me, if I misunderstood you.

BR,

Joshua

 

From: Ali Ghiasi <aghiasi@xxxxxxxxx> 
Sent: Wednesday, September 28, 2022 10:55 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

Hello Adee:

 

We have at least 3 classes of AUIs

          I. Conventional package PCB up to 36 dB

          II. Advance package with cable or CPC up to 22 dB

          II. Co-packaged with or without 1st level package ~18 dB or ~12 dB

 

The difference between 1 and 2 is certainly greater than just 1 order of magnitude in DER.  AUI type 1 would require something like 40 UI span equalizer, possibly MLSE turned on, and FEC termination.

AUI type 2 likely can operate with an equalizer with 12-16 UI span and DER of ~1E-5.  AUI type 3 exact EQ will be dependent if we have the 1st level package or not, so there is a range of possibility but overall simpler than AUI type 2.

 

AUI Type I, II, and III are different specifications and each should have their own clause, but some product in the market place be a superset that can support more than one AUI types.

 

Thanks,

Ali Ghiasi

 

 

On Sep 28, 2022, at 10:35 AM, Adee Ran (aran) <0000147b29386f6c-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

 

Following today’s call and straw polls, I’m thinking of doing some analysis for the “lower loss” AUI.

 

I can see the two specifications going in a few directions:

  1. “Long AUI”: up to 36 dB with termination of the RS544 (DER≈1e-4); “Short AUI”: up to x dB without termination (DER≈1e-5). Essentially segmented/concatenated, but with the same bits on the optics for both. Electrical specs may be the same, except for the BER/DER parameter. This would enable modules with no RS-FEC implementation – lower area, power, AND latency.
  1.  
  2. “Long AUI”: same as above; “Short AUI”: up to x dB with weaker SerDes assumptions (equalization etc.) but same DER target. Both assume termination of the RS-FEC. Different electrical specs. “low loss” modules can have lower power and area, but a relatively small effect on latency.
  3. A combination of the two above – if something can be gained (I’m not sure)
  4. Something else?

 

Is there a preferred direction?

 

</Adee>

 

From: Chris Cole <chris@xxxxxxxxxxxxxxx> 
Sent: Wednesday, 28 September 2022 7:12
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

Hi Jeff

 

Yes, if you have a wide loss dynamic range then of course calibration or training is critical. But the more important question is why have it in the first place. 

 

For many generations of copper interconnect, the loss was dominated by one segment of the channel. In that case, one large gain stage works just fine. But this is no longer the case. The packages at both ends, the PCB trace(s), the cable if there is one, all are significant contributors. 

 

 

Basic math tells us that a single large gain stage is a power inefficient solution to this problem. That's nothing new. Nearly two hundred years ago, people figured that when stringing telegraph lines they needed to intersperse them with repeaters. They didn't have the math to help them understand why. However, we do, so what's our excuse? 

 

A DAC at 224G/lane is not the lowest power solution; it's the highest power solution. To add insult to injury you and Gary want to force this overgrown gain on C2M channels that don't need it. Training or calibration hardly makes it palatable.

 

Chris

 

On Tue, Sep 27, 2022 at 3:29 PM Jeffery Maki <jmaki@xxxxxxxxxxx> wrote:

Chris,

 

I don’t need to have a self-driving car to get anti-lock brakes.

 

The challenge here is calibration of control. A scheme that is robust to miscalibration is enabling.

 

Jeff

 

 

Juniper Business Use Only

From: Chris Cole <chris@xxxxxxxxxxxxxxx> 
Sent: Tuesday, September 27, 2022 2:07 PM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

[External Email. Be cautious of content]

 

That's a great idea. Swiss Army knife do-it-all engineering solutions have always resulted in lowest cost and power. 

 

In the same vein, we should adopt Coherent ZR for all optical PMD reaches. After all, it's powerful link training is fully capable of adapting to the worst case multi-hundred km channels, and all shorter applications down to tens of meters. 

Chris

 

On Tue, Sep 27, 2022 at 11:21 AM Jeffery Maki <00000d5963b8071f-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Gary,

 

I indeed hope it becomes mute.

 

The discussion here was recalling that AUI was devised with two loss targets for 100G electrical lanes. We avoided detailed parameter programming. To embrace even more complex configuration, then link training indeed becomes attractive.

 

Jeff

 

 

Juniper Business Use Only

From: Gary Nicholl (gnicholl) <00000bb92642e11e-dmarc-request@xxxxxxxxxxxxxxxxx> 
Sent: Tuesday, September 27, 2022 6:14 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

[External Email. Be cautious of content]

 

Does all of this become mute when we move to electrical link training for 200G C2M ?

 

I thought the intent of link training is that rather than having a pre-defined set of parameters based on the worst-case channel (or in the case of 3ck the two worst channels of AUI-S and AUI-L),  that the parameters are adapted to match the actual channel ?

 

Gary

 

From: Jeffery Maki <00000d5963b8071f-dmarc-request@xxxxxxxxxxxxxxxxx> 
Sent: Tuesday, September 27, 2022 12:39 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

Chris,

 

I agree deeper thinking needed. How we indicate and configure AUI support is an important problem too or interop between host and module may never happen despite all the excellent deep thinking.

 

Jeff

 

 

Juniper Business Use Only

From: Chris Cole <chris@xxxxxxxxxxxxxxx> 
Sent: Monday, September 26, 2022 4:33 PM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

[External Email. Be cautious of content]

 

I am glad we have zeroed in on the critical aspect of what needs to be done.

 

I was trying to distract us with side topics like the loss budget and applications scenarios, but perhaps that will just fall out of getting the correct host id. 

 

Chris

 

On Mon, Sep 26, 2022 at 3:57 PM Jeffery Maki <00000d5963b8071f-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Ali,

 

AUI-S and AUI-L are not PMDs in SFF-8024. They are Host Electrical Interface IDs. At present, they are seen as two configurations of one implementation. Please see IEEE 802.3ck, where they are defined as such.

 

How do you see mapping “classes of AUIs” to Host Electrical Interface IDs?

 

Jeff

 

 

Juniper Business Use Only

From: Ali Ghiasi <aghiasi@xxxxxxxxx> 
Sent: Monday, September 26, 2022 10:15 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

[External Email. Be cautious of content]

 

Hello Jeff,

 

AUI-S and AUI-L is are two settings for the same retime interface (4/5 taps FFE with RX CTLE+4DFE taps), assuming we will introduce some level of adaptive transmitter via CMIS-LT/CL136 you could have 1000’s of valid TX settings.

It is unfortunate that in SFF-8024 AUI-S/L are defined as if they were different PMDs, they are just two settings for one PMD!

 

The discussions here is if IEEE should define different classes of AUI as illustrated below https://www.ieee802.org/3/df/public/22_07/ghiasi_3df_02a_2207.pdf , C2M/VSR, XSR+, XSR, ..

AUI-I, II, III, and IV all are in my opinion within the scope of the 802.3df.

 

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

 

Thanks,

Ali Ghiasi

 

 

 

On Sep 26, 2022, at 9:58 AM, Jeffery Maki <00000d5963b8071f-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

 

John,

 

I thought we already agreed to leverage IEEE 802.3ck. I was simply pointing out that we have for instance 100GAUI-1-S and 100GAUI-1-L from IEEE 802.3ck, which I understand we will similarly develop 800GAUI-8-S and 800GAUI-8-L.

 

Jeff

 

 

Juniper Business Use Only

From: John D'Ambrosia <jdambrosia@xxxxxxxxx> 
Sent: Saturday, September 24, 2022 5:07 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] Oct 2022 Series Webpage Update

 

[External Email. Be cautious of content]

 

Jeff 

At this point for 200g lanes - no decisions have been made.  Perhaps there is progress elsewhere but that does not apply within our project.

 

As always we are a contribution driven organization.

 

John

Sent from my iPhone

 

On Sep 24, 2022, at 3:42 AM, Chris Cole <chris@xxxxxxxxxxxxxxx> wrote:

 

When we finish the first draft we will send it to you. 

 

On Sep 23, 2022, at 8:32 PM, Jeffery Maki <jmaki@xxxxxxxxxxx> wrote:

 

Chris,

 

We already have AUI-S and AUI-L for two ranges essentially of loss, not just one. Regardless, we do have more kinds of implementations needing support from the standard.

 

Jeff

 

 

Non-Juniper

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

 

[External Email. Be cautious of content]

 

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:

 

  1. Traditional large loss for LR backplane, CR passive DAC, and VSR front pluggable 
  2. 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

 

Chris

 

 

 

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

All,

The webpage for the Oct 2022 Series has been updated with all presentation material for next week - https://www.ieee802.org/3/df/public/22_10/index.html.

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- https://www.ieee802.org/3/df/public/22_10/22_0927/PAR_P802p3df_Proposed_220927.pdf.  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.

Regards,

John D’Ambrosia

Chair, IEEE P802.3df Task Force

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

 

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


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