Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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>
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>
The method of introducing Skew in my case involves: 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>
FYI: This is what how delay was added to a channel in the COM code.
From: Upen Reddy Kareti (ureddy) <00000d999961d690-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi All, Two requests were made during my presentation today– here are my responses
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.
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 |