I suspect this is an "it depends" sort of argument.
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:30 PM, C. Kumar <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
I have equally data supporting my view. we have been very successful with
that. You cannot go and make blanket statements.
------------------------------
*From:* Walter Katz <wkatz@xxxxxxxxxx>
*To:* C. Kumar <kumarchi@xxxxxxxxx>; Arpad_Muranyi@xxxxxxxxxx;
ibis@xxxxxxxxxxxxx
*Sent:* Thursday, June 11, 2015 6:17 PM
*Subject:* [ibis] Re: Flexibility of a specification
Kumar,
Not true. Optimizing the Tx to open the eye at the input to the Rx is just
wrong at date rates above 6 Gbps, and I have the data to prove it.
It probably is OK when we first put AMI together and the state of the art
was 3 Gbps and there was just a two tap Tx and a one tap DFE and very
limited CTLE.
Walter
*From:* C. Kumar [mailto:kumarchi@xxxxxxxxx]
*Sent:* Thursday, June 11, 2015 6:12 PM
*To:* wkatz@xxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx; ibis@xxxxxxxxxxxxx
*Subject:* Re: [ibis] Re: Flexibility of a specification
Walter:
Tx optimization is very useful and in the absense of backchannel support
works very nicely with proper constraints on post cursor.
also rx devices are not so brittle that they need eda tool to figure out
their adaptation settings. The devices are very sophisticate, robust and
will not under wide variety of starting points
------------------------------
*From:* Walter Katz <wkatz@xxxxxxxxxx>
*To:* Arpad_Muranyi@xxxxxxxxxx; ibis@xxxxxxxxxxxxx
*Sent:* Thursday, June 11, 2015 5:50 PM
*Subject:* [ibis] Re: Flexibility of a specification
Arpad,
You are correct. If we are not talking about communication from the Rx to
the Tx, then the EDA tool is controlling the configuration of the Tx and
the Rx. This is one of the modes that we want the optimization BIRD to
support. Currently EDA tools need to do a blind search (or we prefer an
intelligent blind search) to run the simulations with a range of Tx tap
equalizations. This is why the original concept of the Tx model optimizing
itself was always fundamentally flawed. We cannot do anything with old
models but we could (should) add a reserved parameter to the Tx so that the
Tx DLL can be run without risking the Tx changing its equalization based on
the Impulse Response of the channel that is input to the Tx (as I proposed
in the Redriver Flow clarification BIRD that is currently tabled in
IBIS_AMI.
Walter
*From:* ibis-bounce@xxxxxxxxxxxxx [mailto:ibis-bounce@xxxxxxxxxxxxx
<ibis-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Muranyi, Arpad
*Sent:* Thursday, June 11, 2015 5:28 PM
*To:* ibis@xxxxxxxxxxxxx
*Subject:* [ibis] Re: Flexibility of a specification
Walter,
Regarding: “…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.”
this sounds like you have the Backchannel BIRD (147) or its derivatives
in mind which is still in the future (if it will ever happen). I was
talking about the existing spec and existing models, and this was a
simple illustration with one example from the spec for why I think the
spec is inflexible.
Aside from that, you missed the point of the thoughts I had in mind
when I started this thread. The point I am trying to make is that we
will continually run into limitations if we use the spec to describe
what and how people should do. Consider plain old SPICE. Does the
SPICE language tell you that you can only write subcircuits with a
certain predetermined “footprint”? Does the SPICE language tell you
that you can only simulate the subcircuits you are allowed to write in
a certain order? Obviously not. That’s what I am suggesting we should
also do in IBIS-AMI (or IBIS in general). Give people a language, let
them write any function they want, and give them a simulator that allows
them to execute these functions in any order.
Disclaimer: There are my personal views, not my employer’s views. I
may say different things when I represent my employer’s views.
Thanks,
Arpad
========================================================================
*From:* ibis-bounce@xxxxxxxxxxxxx [mailto:ibis-bounce@xxxxxxxxxxxxx
<ibis-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Walter Katz
*Sent:* Thursday, June 11, 2015 4:01 PM
*To:* ibis@xxxxxxxxxxxxx
*Subject:* [ibis] FW: Re: Flexibility of a specification
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
Phone 303.449-2308
Mobile 303.335-6156
