Richard:
I simply pointed out two approaches to handle the P&N skew, one is that we need to agree the skew limits and estimation methodology, and add them to the channels where
skews are not accounted for yet; another approach is to let channel contributors be responsible for including the skew (& skew compensation)
in their channels if they have not done so. My preference is the 2nd approach, same as you, as I do not think that COM should be response for the quality of the channel S-parameters wrt skew, and channel contributors should.
Agreed that some KR/CR channels contributed to 802.3dj already had skew included, and we should not
double count the skews for those channels.
As for the PKG, for Class A, the skew effect had been included in the design, 3D stacking, TC, and model extraction, hence, no need to add additional skew or double count the
skew. I believe that this is also the case for Class B.
Thanks!
Mike
From: Richard Mellitz <Richard.Mellitz@xxxxxxxxxx>
Sent: Friday, June 21, 2024 6:55 AM
To: Li, Peng Mike <peng.mike.li@xxxxxxxxx>; STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_B400G_ELEC] [802.3dj] 20 June electrical ad hoc - response to request for more details
Mike,
COM is applicable for the specific passed s-parameter. In my opinion, it would be the responsibility of s-parameter include skew. How skew is handled or filtered in each component is IP. For
this reason, I don’t think we can converge on skew for each component.
For the package it’s included in the measurements. Excess skew will cause pmax/Vf and ERL to decrease. The only work may need to be done as specification limits the excess common mode.
… Rich
|
From: Li, Peng Mike <peng.mike.li@xxxxxxxxx>
Sent: Friday, June 21, 2024 2:10 AM
To: Richard Mellitz <Richard.Mellitz@xxxxxxxxxx>;
STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Cc: Li, Peng Mike <peng.mike.li@xxxxxxxxx>
Subject: RE: [802.3_B400G_ELEC] [802.3dj] 20 June electrical ad hoc - response to request for more details
|
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.
|
We need to have an agreed skew frequency domain profile for each link component as they have different physical structures, and
an agreed method to add a skew to the S-parameters of each component, to converge, or we ask the channel contributors to include
skews in their channels contributed. For ref PKG skew, it needs to be addressed in 178A.
Mike
From: Richard Mellitz <000014533bad0b9c-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, June 20, 2024 1:35 PM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G_ELEC] [802.3dj] 20 June electrical ad hoc - response to request for more details
I agree there are sources of skew that may be different per component that compromise an end-to-end channel. Slide 13 of
kareti_3dj_02_2401.pdf
is the example of 4 types of skew that may exist in sub-components. Did you do a pulse response for each of these like you suggested in an earlier slide to make sure they look physical? I believe what you are suggesting is to add these frequency profiles
to channels. You can do this for your channels if you think this is what your components behavior is.
Unless you know the posted channels, if would be incorrect to add frequency domain skew profiles to them. Some of the posted channel already include expected skew too.
|
From: Upen Reddy Kareti (ureddy) <ureddy@xxxxxxxxx>
Sent: Thursday, June 20, 2024 2:44 PM
To: Richard Mellitz <Richard.Mellitz@xxxxxxxxxx>;
STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_B400G_ELEC] [802.3dj] 20 June electrical ad hoc - response to request for more details
|
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.
|
The method of introducing Skew in my case involves:
Based on measurements identify basic profiles in Freq domain that are combined to represent measured s-parameters then add that combined profile to the end-to-end freq domain s-parameters
Cables , pcb, packages and even silicon analog paths etc. may have their own profiles towards combined profile.
i.e., in Rich’s equation
∆ is varying over
and
this is introduced in s-param block in each direction and not per port.[RIM> it is per channel port.
D is indexed. It was intent was to see what happened if you add delay compensation to a Tx or Rx. I.e. trying to understand compensable vs compensable skew.
at present measurements show lot more skew than what we can afford for 224G , limiting
∆ to channel sub-components can achieve in terms of skew.
For example, Cable vendors may guide us for 224G application what we can use as a limit over all freq range of interest– say 1 ps/m or whatever.
[RIM> Perhaps skew is a double counted parameter and shouldn’t be spec’ed. It would be accounted for in COM.
-Upen
From: Richard Mellitz <000014533bad0b9c-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, June 20, 2024 10:53 AM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G_ELEC] [802.3dj] 20 June electrical ad hoc - response to request for more details
FYI: This is what how delay was added to a channel in the COM code.
|
From: Upen Reddy Kareti (ureddy) <00000d999961d690-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, June 20, 2024 1:02 PM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: [802.3_B400G_ELEC] [802.3dj] 20 June electrical ad hoc - response to request for more details
|
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 All,
Two requests were made during my presentation today– here are my responses
1> provide a link to my skew presentation – the following link is added to today’s presentation.
-
Identifying basic skew profiles in freq. domain slide 13 of
kareti_3dj_02_2401.pdf – actual step by step procedure how to add skew is not shared
2> Max tap values for under 40 dB insertion Loss – separate stats for the ones passing COM of 3 dB and the ones not passing of 3 dB.
-
note the following data is not as relevant once we start using COM code 4.6.3 as fixes are provided for tap location reporting issue.
- Also, when we configure with TX FFE and g_DC >0 setups.
For a case with post cursors of 8 fixed 3 banks (of 4 taps in each bank ) RX FFE span up to 100 UI and Package class B for both Transmitter and
Receiver:
Channels < 40 dB and passing 3dB COM.
Channels < 40 dB and failing 3dB COM.
Regards
Upen
To unsubscribe from the STDS-802-3-B400G-ELEC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-ELEC&A=1
To unsubscribe from the STDS-802-3-B400G-ELEC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-ELEC&A=1
To unsubscribe from the STDS-802-3-B400G-ELEC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-ELEC&A=1
To unsubscribe from the STDS-802-3-B400G-ELEC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-ELEC&A=1