Scott,
While I am not disputing your points about non-LTI analog models,
keep in mind that IBIS does not prevent anyone from making LTI
analog models.
The I-V curves can be straight lines, and rising/falling waveforms
can be symmetrical. The V-t tables are optional, you can use [Ramp].
We left it in the hands of the model makers to make LTI analog models
for their AMI models. If they don’t, it is their problem (or their
customers’).
But your suggestion about including checks in the IBIS parser and
issuing warnings or errors about non-LTI analog models is an
interesting one. Even if the IBIS committee doesn’t want to pay
for the development of such checks in the IBIS parser, EDA vendors
might want to consider implementing such tests in their tools and
inform their users about the dangerous conditions… Our tool actually
does have such checks built in…
Thanks,
Arpad
========================================================================
From: ibis-bounce@xxxxxxxxxxxxx [mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of
Scott McMorrow
Sent: Thursday, June 11, 2015 5:41 PM
To: Walter Katz
Cc: ibis@xxxxxxxxxxxxx
Subject: [ibis] Re: FW: Re: Flexibility of a specification
Walter
I'm not saying other platforms do not have their issues. All have problems
with non-LTI modeling which they wash over. However, the IBIS-AMI
specification allows a model maker to create analog models that are non-LTI.
The spec is at fault here, since it allows an IBIS Tx or Rx model to be used in
the Analog channel, without any direction on what is required to be done should
the model turn out to be non-LTI. At the least, the IBIS parser should check
for non-LTI models and flag them as errors.
I disagree about comparision and characterization with high loss channels.
Characterization should be done with low loss short channels, as they are more
likely to "break" the modeler's unstated assumptions. This was the case with
IBIS I/V and V/T curve modeling, and it is the case with Serdes modeling. The
worst corner cases often come with high reflectivity, short channels, where
low-Q resonances can break the system quickly. This happens all the time with
electrical links to optical modules and components, as it does with short
backplane channels. If you want to model near end crosstalk correctly, then it
is imperative that the reflection coefficient of the Tx and Rx silicon is
correct. Get it wrong, and you may miss the mark by 2-to-1.
So there are multiple problems that I see for correlation:
1) what does the EDA tool or analog modeler do to linearize a non-LTI model
IBIS-AMI analog model?
2) How do we correlate a non-real IBIS-AMI analog model that has a C_comp of 0
pF, and no auxiliary model to describe the analog section.
3) How do we correlate an IBIS-AMI analog model with physical systems when only
one impedance is defined by the I/V curves?
I know of two FPGA vendors who's 28G model exhibit these issues.
[http://teraspeed.com/images/logo-02.png]
Scott McMorrow
Consultant - R&D
Teraspeed Consulting - A Division of Samtec
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
On Thu, Jun 11, 2015 at 6:26 PM, Walter Katz
<wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>> wrote:
Scott,
Let’s put AMI modeling aside, and talk about what people are doing with MatLab,
Stat-Eye, or 802.3bj COM. They all need the same Impulse Response (or
equivalent Pulse Response) of the channel. So they all suffer from the same
problem of generating an Impulse Response of the channel. AMI modeling is just
Stat-Eye and MatLab with IP protection, interoperable models and portable
models. So the LTI assumption and the limitations it introduces for short, low
loss channels has been a limitation the industry has always had. And to your
point, the comparison of various EDA tools should be done using 20, 30 and 35
dB channels. We do these comparisons all of the time.
Walter
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx<mailto:scott@xxxxxxxxxxxxx>]
Sent: Thursday, June 11, 2015 6:00 PM
To: Walter Katz
Cc: ibis@xxxxxxxxxxxxx<mailto:ibis@xxxxxxxxxxxxx>
Subject: Re: [ibis] FW: Re: Flexibility of a specification
Walter
to clarify, I am not speaking of the channel they modeled, but rather the
Analog modeling of the Tx and Rx.
Scott
[http://teraspeed.com/images/logo-02.png]
Scott McMorrow
Consultant - R&D
Teraspeed Consulting - A Division of Samtec
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
On Thu, Jun 11, 2015 at 5:59 PM, Scott McMorrow
<scott@xxxxxxxxxxxxx<mailto:scott@xxxxxxxxxxxxx>> wrote:
Yes, I am speaking of the paper that you referenced as an example of "... EDA
Vendor tools do not use the AMI models correctly." In this case, I'd say that
it is quite possible, based on what I have seen, that the Analog modeling
itself was performed incorrectly.
[http://teraspeed.com/images/logo-02.png]
Scott McMorrow
Consultant - R&D
Teraspeed Consulting - A Division of Samtec
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
On Thu, Jun 11, 2015 at 5:55 PM, Walter Katz
<wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>> wrote:
Scott,
I assume that you are referring to the paper comparing AMI simulation results
(http://www.designcon.com/santaclara/scheduler/session/ibis-ami-model-simulations-over-six-eda-platforms).
I cannot speak to the reality of the channel they chose to compare.
Walter
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx<mailto:scott@xxxxxxxxxxxxx>]
Sent: Thursday, June 11, 2015 5:29 PM
To: Walter Katz
Cc: ibis@xxxxxxxxxxxxx<mailto:ibis@xxxxxxxxxxxxx>
Subject: Re: [ibis] FW: Re: Flexibility of a specification
Walter
Thank you for the very nice presentation
Interestingly enough, the presentation that you referenced from DesignCon makes
absolutely no reference to the following words
Analog
Capacitance
Termination
In fact, nothing is said regarding the analog portion of the IBIS-AMI model.
From a fundamental physics point of view, if a particular manufacturer does not
model the Analog model correctly (and to my knowledge the one that wrote the
paper do not) and pass it on for the simulator to use, then one cannot say
whether or not any of the simulations performed on the 6 EDA tools is even
close to correct.
I have fundamental issues with models that have 0 pF die capacitance, or die
capacitance that is out of range for the class of serdes that is being modeled.
For example, a 28Gbps driver that has 700 fF of capacitance, and a receiver
with 1.2 pF of capacitance. Knowing that these values cannot be physically
correct for a 28G serdes, what should I do when they show me eye patterns from
several simulators, that do not show the appropriate eye closure and frequency
dependent attenulation that I would expect with these Tx and Rx die capacitance
values.
Scott
[http://teraspeed.com/images/logo-02.png]
Scott McMorrow
Consultant - R&D
Teraspeed Consulting - A Division of Samtec
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
On Thu, Jun 11, 2015 at 5:01 PM, Walter Katz
<wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>> wrote:
All,
I have seen 18 e-mails yesterday on IBIS-AMI. They indicate the following
things to me:
1. There are many of us (users and EDA vendors) frustrated with the
quality of AMI models delivered by IC Vendors
a. Models are not interoperable
b. Models do not work on all EDA platforms
c. Models do not work on all computer hardware
d. Models are delivered DOA
e. Models do not comply with the standard
2. There are many users frustrated with the fact that EDA platforms do
not give the same result
3. The IBIS spec does not have a cookbook that tells model makers how to
write models
4. Some of the e-mails are written by people who do not understand what
AMI modeling is and what it is not
5. …
What is IBIS-AMI
There is the IBIS 6.0 specification and a paper we recently gave at DesignCon
http://www.designcon.com/santaclara/scheduler/session/understanding-ibis-ami-simulations.
But let me describe here how simple it is. AMI models are executable code that
links in directly to the EDA simulation tool as a Dynamically7 Loaded Library
(DLL on Windows or a Shared Object on Linux). There are three functions in the
DLL: AMI_Init, AMI_GetWave and AMI_Close.
• The AMI_Init function initializes the function and can output results
that an EDA tool can do statistical analysis.
o The input to Tx AMI_Init is an Impulse Response of the channel and
configuration of the model as described in an ASCII .ami file that is supplied
with the DLL.
o There is no magic to create an Impulse Response of the channel. It can be
done by simulating a Step Response with the IBS model for the Tx and Rx and
the interconnect (channel) between the Tx and Rx. The time derivative of this
Step Response is the Impulse Response. There are other methods of generating
this Impulse Response in the frequency domain as well. They should give the
identical result (within the numerical accuracy of each of the methods). This
Impulse Response (or a Pulse Response that can be trivially generated from an
Impulse Response) is exactly the input to Stat-Eye, COM, or any SerDes MatLab
based tool.
o There is no magic to create the configuration that controls the operation
of the DLL. This is explained in the IBIS 6.0 spec.
o The output of the Tx AMI_Init function is an Impulse Response modified by
the Tx equalization (usually but not necessarily an FFE filter)
o The input to the Rx AMI_Init function is the Impulse Response output of the
Tx AMI_Init function, and the configuration of the Rx model as described in the
Rx .ami file.
o Both the Tx and Rx .ami files describe the controls that the user has in
configuring the silicon itself, and should correspond either directly or with
some mapping software into the registers that the hardware used to configure
the silicon.
o The output of the Rx AMI_Init function is an Impulse Response at the Rx
latch (decision point) that the EDA tool can use to generate a Statistical Eye,
and information that the EDA tool can use to generate a Clock PDF function.
o The EDA tool is responsible for generating bathtub curves, BER, and other
analysis of the Rx output.
• The AMI_GetWave function is used to do time domain simulations. The
input to the Tx AMI_GetWave function is a stimulus waveform with a well-defined
format, the output of the Tx_GetWave function is a waveform which includes the
Tx equalization. This is convolved with the Impulse Response of the channel to
generate the waveform input to Rx AMI_GetWave. The output of Rx AMI_GetWave is
a waveform at the Rx latch (decision point), and clock times that can be used
to sample the waveform. The EDA tool is responsible for analyzing the Rx
outputs.
• The AMI_Close function is used when the simulation is complete to
free memory.
This is all there is. The inputs and outputs requirement are precisely defined
by the IBIS 6.0 standard. All is not perfect however. A model can support just
statistical, just time domain or both statistical and time domain processing.
This is particularly problematic when a Tx model does not support statistical.
There are other special cases – like repeater models and retimer models that
are not discussed here.
As for comments about the flexibility of the specification, both SiSoft and
Keysight demonstrated prototype implementations of PAM4 in their AMI simulators
at DesignCon. It only took us a couple of weeks to resolve our differences and
write a BIRD (172) to enable PAM4 AMI modeling. Dotting the I’s and crossing
the T’s took another month or two. The resulting BIRD is ready to be approved
at this week’s Open Forum. IBIS would be well served by approving this BIRD and
including it in IBIS 6.1. IBIS should commit itself to being responsive to the
needs of the IC Vendor, User and EDA Vendor communities.
What are the Problems
The biggest problem that we see are non-compliant models. It is easy to write a
parser for the .ibs and .ami ASCII files to insure that they comply to the IBIS
specification, it is harder to test for the actions of the executable to be
compliant. Engineers who develop IP and use tools such as MatLab often do not
have the expertise to write quality C code, they do not necessarily have both
32 bit and 64 bit environments to build on, and they use tools to develop their
models that might have samples per bit or block size limitations. Writing bug
free software is not easy, but just like there is no excuse for model writers
delivering IBIS files that do not pass the IBIS parser, there is no excuse for
AMI model writers from running their models on Windows and Linux 32 bit and 64
bit computers exercising every possible value of each of the AMI parameters
that are input to the model, and making sure that the models to not crash, and
give expected results. It is inexcusable for a model writer to deliver a model
without documenting the inputs and outputs and the models limitations.
The next problem that is tarnishing the AMI modeling committee is that EDA
Vendor tools do not use the AMI models correctly. See for example
http://www.designcon.com/santaclara/scheduler/session/ibis-ami-model-simulations-over-six-eda-platforms.
The bottom line is that Users need to reject IC Vendor parts when the IC Vendor
AMI models do not pass a set of usability requirements. Nothing gets an IC
Vendors attention better than the Golden Rule, he who has the Gold Rules.
Both SiSoft and Cadence have supplied the source code for a program that can
exercise an AMI DLL. It is not big deal to write scripts that can exercise a
DLL with a full set of inputs.
One Should Not Confuse Analogue Simulation with AMI Simulation
Generating the Impulse Response is a different problem then generating the AMI
simulation. For example, the following statement is misleading:
“A number of folks that I communicate with have expressed great frustration
with the use of IBIS-AMI models in their simulators of choice. Are there
examples and a user guide which go beyond the specification?”
One should not expect or require that a single simulator can both analyze the
channel to generate the Impulse Response and also do the AMI simulation. These
are separate problems. There are simulators that can do both, but there are
simulators out there that do one well and the other either not at all or poorly.
So a SPICE simulator can be IBIS compliant, but not AMI compliant. It is
certainly valid to use that SPICE simulator to generate the Impulse Response of
the channel, but do not expect it to be able to do the AMI simulation.
Optimization Confusion
There were several e-mails relating to optimization that indicate that even us
experts do not agree on what the specification says. E-mails like the following
muddle the landscape and need to be called out and corrected:
I would like to give you an example for the inflexibility of the IBIS-AMI
specification. The words I used before (“canned”) may not have been the
best choice, but let’s not argue over that.
Multiple SERDES experts would say these days that there are times when it
is better to optimize the Rx CTLE to the channel’s IR without including
the Tx EQ effects. Since the CTLE is usually LTI, its algorithm can very
well be placed in the Rx Init function. However, on the bottom of pg. 172
this is what the spec says:
“Under certain circumstances, for example when the Rx AMI_Init function
includes an optimization
algorithm, the impulse response presented to the Rx AMI_Init function must
include the Tx
equalization effects for the optimization to work correctly.”
This statement doesn’t seem to allow the CTLE be optimized without the Tx
EQ’s effects. Do you consider this to be a flexible specification? Do you
see a way around this requirement in the DLL’s algorithms? Do you think
it is OK for EDA vendors to ignore this statement in the specification and
still be considered IBIS spec compliant?
Although Cadence and SiSoft disagree on the details of how messages are defined
that get passed back and forth between the Tx and Rx model, we both agree that
the Rx model controls the Tx equalization. The statement “the impulse response
presented to the Rx AMI_Init function must include the Tx equalization effects
for the optimization to work correctly” in no way precludes the Rx from setting
the Tx equalization. Thus the CTLE can be optimized with whatever Tx
equalization the Rx model chooses. I would expect that an Rx optimization
algorithm will set the Tx equalization to off (or the minimal amount of Tx
equalization that will allow the Rx to evaluate an eye), then optimize its CTLE
and DFE, and then make incremental changes to the Tx to fine tune the channel.
So for those of us evaluating the various equalization messaging methods one
would want one that is capable of setting the Tx equalization to either off,
low, or one of a number of presets, and then be able to change the Tx
equalization incrementally.
32 Bit VS 64 Bit
This is a potentially difficult computer science problem that is simply solved
by the model maker supplying both 32 bit and 64 bit versions of the model.
Advanced Features – Supporting Innovation
Models that support advanced features do not work on all simulators. This is
not a negative – it is a positive! Take PAM4 as an example. The authors of the
PAM4 BIRD (SiSoft, Keysight, Avago and Xilinx) are developing (and delivering)
PAM4 models to companies that are designing PAM4 systems as we speak. We
initially privately, and then publicly in BIRD 172 defined new AMI Reserved
Parameters that have enabled IC Vendors to move forward developing models,
enabled EDA tool vendors to move forward enhancing their tools, and users to
evaluate channels and make engineering decisions today. Until BIRD 172 is
approved, and until IBIS 6.1 (or so) is approved, and until IBIS supplies a
parser that supports these new Reserved Parameters, we are all supporting these
parameters in the Model Specific section of a .ami file. Converting these IBIS
6.0 models to IBIS 6.1 will simply require that these Model Specific parameters
be move to the Reserved Parameter section of the IBIS file. Other EDA Vendors
are free to implement this PAM4 functionality as they see fit. So I quote
“Only the 2nd can be blamed on the IBIS committee and only if the complaint is
that they don’t move fast enough.”
Non-Compliant AMI Models
The only solution to deal with model makers who supply models with fixed
samples per bit or fixed block sizes, is for users to not buy those parts
(remember the Golden Rule). If model makers think it is too much of a burden to
write models at any block size and samples per bit, they should submit a BIRD
that makes Samples_Per_Bit and Block_Size reserved parameters, become dues
paying members of IBIS and vote it in the standard. These problems have been
around from the beginning. We even submitted a BIRD to allow a model to declare
Samples_Per_Bit as a reserved parameter that would have required the EDA tool
to do the “Torque Conversion” in the simulator.
Enforcing Better Models – AMI Model Plug Fests!
There were statements like “IBIS should require a Model User Guide”, “IBIS
should supply tools that validate models”, … It is easy to say that every AMI
model should have a Model User Guide, and someone can make such a motion at
this Friday’s Open Forum. Is someone going to write a specification one what
should be in an AMI Model User Guide? Can we write a parser to verify that a
Model User Guide is complete and correct? Who is going to spec a tool to
validate a model? More interesting, who is going to write a spec to validate an
AMI EDA Tool? Imagine organizing an IBIS AMI Plug Fest (like the PCIeG3 Plug
Fests).
IBIS Cannot Do Anything, But You Can
The IBIS organization is most likely forbidden to name specific IC Vendors, EDA
Vendors or User offenders of the standard in order to protect the innocence of
the guilty, and I think this will prohibit IBIS from effectively addressing
these problems. Ultimately it is the user of IBIS models that need to stand up
and do this. I suspect that someone could start a Blog somewhere and continue
this discussion outside of the IBIS umbrella.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
