Xavier NX - IBIS AMI for PCIe RX

Hi,

Without an AMI model for the Rx side of the PCIe lane, it’s not possible to run advanced pre-layout SI checks.

I don’t see one in the download package - is this a known gap?

Thanks,
Dan

There is t194_uphy_ibis_ami_rev1p01.zip in package.

There is, but there is no RX model, only a TX.

See attached.

image

We don’t provide RX AMI model, please use Seasim, which could download from PCI-SIG.

Got it, thanks.

To anyone who reads this post, nVidia does not provide all the AMI models necessary to run proper pre or post layout SI analysis for some reason.

PCI-SIG, I believe, is member based, requiring an annual membership fee, and SEASIM as well - to the best of my Google-fu abilities, is not free/open source.

So basically, nVidia did half the job here.

Hi, Please refer to our SI team’s comments:

What simulation tool are you using for AMI simulation? The famous EDA tools like ANSYS Designer or Keysight’s ADS has built-in AMI RX model for PCIe. You can use it for your PCB design verification.
We basically want customers follow our DG and TX and RX routing should be consistent.

Hyperlynx SI GHz

The bottom line is that other companies e.g. AMD-Xilinx, Intel-Altera etc provide Tx/Rx AMI models based on their specific drivers so that you can do full proper simulations and analysis pre and post layout.

Relying on generic models is not a preferred/ideal method - any ‘SI expert team’ would surely know that.

Not all customers can follow your design guide, their stack-ups will be different, their channel constructions will be different, they will have different connectors in play for system interconnect…

That solution is nonsense - stop trying to pretend like nVidia didn’t half-ass the solution, it’s a bad look.

Lastly, PCI-SIG is not free, it costs $4000/year for membership and access to SEASIM.

Please refer to below info:

What purpose do you want to use AMI models for? It’s supposed to just verify their PCB channel design. It’s not allowed to do further PHY tuning on a channel beyond spec.

Every channel design of standard interfaces like PCIe must be compliant with the spec. This is what our circuit team requires us for channel design.

If you don’t have SEASIM tool or PCIe compliance RX model, we can try to wrap up the model for you. (but need to verify the compatibility of Hyperlynx SI tool)
If you think your design cannot meet our DG due to different and complicated channel topology, I think one possible way that I know working for some customers is to ask you for your designed channel S-parameter, and we can ask our circuit team to do your RX simulation, as your RX simulation will be more accurate than AMI.

  • But again to emphasize that our circuit team would definitely requires the channel design to be compliant with PCIe spec.

I’m not sure there’s a ton of value in additional dialog…but here we go…
For me, the intended AMI use is like with any other AMI simulation…to simulate the ability to overcome channel loss and other physical interconnect issues via things like CTLE, FFE, DFE etc.

Other vendors supply the AMI models for both Tx/Rx so you know the limits of a particular driver/receiver (in my experience all are certainly not created equal - additional tap settings, or even some that do not have AGC etc) that can make/break certain channels.

With a generic model, you are taking some risk there, and I don’t think that there is any cogent argument for providing a Tx model and not the Rx model as well. Either the team believes in passive channel characterization completely, or it believes in IBIS-AMI simulations as a better measure. Providing half of the solution literally makes no sense.

Hyperlynx SI GHz is a very popular SI tool, and it works with IBIS, IBIS-AMI and yes, it does have generic SERDES AMI receivers - but that isn’t the point. The point is that other vendors provide a full and documented solution, and nVidia has provided a half-assed one.

For anyone else reading this in the future who may be new to this:

Back to basics: IBIS/IBIS-AMI and the path to LPDDR5 | 2021-01-28 | Signal Integrity Journal