Xavier NX S-Parameter Port Mapping

Hi,

I am looking for some kind of user guide/config guide for these multi-port s-parameters - specifically how to use them in Hyperlynx.

It’s not clear from examining the file how to assign the ports and wire them for e.g.) the Tx channel from the package die out through the connector.

The names are quite confusing, and there is no mapping guide really, that makes sense, in the file:

! Port[1] = PEX_RX1_N_U5_PB403
! Port[2] = PEX_RX1_P_U5_PB404
! Port[3] = PEX_RX11_N_U5_PB398
! Port[4] = PEX_RX11_P_U5_PB399
! Port[5] = PEX_TX1_N_U5_PB405
! Port[6] = PEX_TX1_P_U5_PB406
! Port[7] = PEX_TX11_N_U5_PB400
! Port[8] = PEX_TX11_P_U5_PB401
! Port[9] = UPHY_RX1_N_CN1_161
! Port[10] = UPHY_RX1_P_CN1_163
! Port[11] = UPHY_RX11_N_CN1_167
! Port[12] = UPHY_RX11_P_CN1_169
! Port[13] = UPHY_TX1_N_CN1_166
! Port[14] = UPHY_TX1_P_CN1_168
! Port[15] = UPHY_TX11_N_CN1_172
! Port[16] = UPHY_TX11_P_CN1_174

In other s-parameter files, it is common for human readable header information to contain e.g.)

!! PORT DEFINITIONS: 
!! 	Port 1		Backplane C2 --- B2 Daughter Card 	Port 2
!!	Port 3		Backplane D2 --- C2 Daughter Card 	Port 4 
!! 	Port 5		Backplane G2 --- E2 Daughter Card 	Port 6
!!	Port 7		Backplane H2 --- F2 Daughter Card 	Port 8		

Without this, it’s not clear how to map the ports and wire them up…

Thanks,
Dan

Hi, the mapping is Port[1] to [9] and [2] to [10]…as the same ‘RX1…’ in name.

I see that - but the naming isnt clear to me:

Is PB403 the SoC die? and CN1_161 the connector pin?

U5 is SoC.

Thanks.

And which side of the connector is the model characterized to? Is it the PCB land or the SODIMM pad?

Do I have to concatenate the SODIMM s-parameters in addition to this?

It includes SODIMM connector model.

Excellent, thanks for the clarification.

Might I suggest nVidia takes a page from other SI outputs from other suppliers and provide more documentation along these lines? Half-baked solutions/data sets are really annoying to work with.

Provide a sample channel construction, settings, and output waveforms so that us commoners can sanity check our tool configuration before trying to use them in our own use-cases.

Again, AMD-Xilinx does a great job with this - any of their UG docs that come with the AMI files and s-parameters for the packages would be a major upgrade over having to search forums for answers.

Tanks for the suggestion, will forward to relevant team.

For anyone reading this in the future - this is what I am referring to:

In another thread on this topic, I was asked by the SI team at nVidia why we might need an IBIS AMI model for the Rx side…the second image here shows the equalization process and what it does to show you the channel performance when those techniques are applied, versus without it.

A passive channel characterization can show you a lot, but a lot of my customers like to see these eye diagrams with proper models.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.