Arpad,
The Usage In (and InOut) parameters are defined in the .ami file with the
allowed values that can be input to the model, and asked the User to
supply those inputs to the DLL. The model maker tells the User how to set
these in the (Description ) of the parameter or in the model
documentation.
You might say that the Model Maker is telling the User/EDA tool how to set
these input values, and an EDA tool can chose to somehow automate setting
those input values to help the User.
So the answer to "the AMI DLL will still generate the same and correct
results in both tools?" is yes, because the DLL will have the same inputs
on all tools, were some tools may help the user set up these inputs.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, October 5, 2015 4:00 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
So are you saying that if an AMI DLL expects certain data
in a Model_Specific input parameter and a tool that knows
what to give it provides the expected data and another tool
that doesn't know what to do with it doesn't provide the
expected data, the AMI DLL will still generate the same and
correct results in both tools?
Thanks,
Arpad
============================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, October 05, 2015 2:54 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Out-InOut BIRD, lets get real
Arpad,
No, it does not make sense.
"some of the special Model_Specific parameters may actually be inputs and
in case the tool doesn't support it"
If any "Model_Specific parameter is an input" has nothing to do with the
tool supporting it, it is the DLL that uses it. So the output of the DLL
will be the same whether the EDA tool supported it or not. What is
different may be the way the EDA tool analyzes the output.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, October 5, 2015 3:40 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
Walter,
Yes, it makes perfect sense what I said.
Here is why:
First you stated that "Whether a .ami file has these special parameters or
not,
the model will always generate the same results on all EDA tools when
presented with
the same inputs", and I agree with this completely.
Then you added that "What is possible is that different EDA tools may run
the
models differently, or interpret the output of the models differently",
which is a
list of reasons why the results may be different. In this list
you only mention how the AMI DLL is executed or how its output
is interpreted, but you didn't mention that some of the special
Model_Specific parameters may actually be inputs and in case the
tool doesn't support it, the input provided by the tool to the model
may be insufficient, and may cause the model to generate different
results. So the different outcome is not only due to how the model
is executed or how its output is interpreted, but also what the
inputs are to the model (which is basically what you said in your
first sentence)...
Regarding "The input to the AMI_Init function is totally defined by the
.AMI In and InOut parameters.",
I would disagree with that, since there can be any number of
Model_Specific parameters which may very well define input(s)
to the model that are NOT defined in the IBIS specification at
all. This can go way beyond the Tstonefile example mentioned
frequently in these discussions.
Thanks,
Arpad
======================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, October 02, 2015 6:53 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Out-InOut BIRD, lets get real
Arpad,
What do you mean by different input. Makes no sense. The input to the
AMI_Init function is totally defined by the .AMI In and InOut parameters.
The Impulse Response is the Input Response of the analog channel which is
defined by the .ibs file and the interconnect. Tstonefile might be an
example of the .ami parameters affecting the input of a model, but this is
an unusual case where the industry needed a way to document the analog
behavior of a model that IBIS would not support. The Tstonefile parameter
could have been replaced with documentation from the IC vendor on what
analogue buffer model the EDA tool needed to use to generate the IR of the
channel.
There is one IC Vendor that is delivering their IBIS/AMI models with
on-die S-Parameters but they are neither using Tstonefile (because it is
non-standard), nor are they using [External Model] because apparently all
EDA tool are not supporting [External Model]. These model are not
compliant either because the IBIS [Model] does not describe the analog
behavior of the buffer to be used to generate the IR of the channel.
So how is our parser going to flag this model as non-compliant?
Walter
From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx [ <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, October 02, 2015 4:59 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
Walter,
Don't forget that AMI models also need input, i.e. the EDA tools
may present different input to the models, especially when these
special features are present in the model.
Thanks,
Arpad
=================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, September 29, 2015 1:50 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Out-InOut BIRD, lets get real
Arpad,
Whether a .ami file has these special parameters or not, the model will
always generate the same results on all EDA tools when presented with the
same inputs. What is possible is that different EDA tools may run the
models differently, or interpret the output of the models differently.
Walter
From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx [ <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, September 29, 2015 12:40 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
Here is a new version of the verbiage I just came up with
for the Definition section that I would like to discuss in
today's meeting:
This reserved parameter identifies by name all Model_Specific parameters
which require special features that are not described in the IBIS
specification to be present in the EDA tool to utilize special features in
the model. Consequently, IBIS-AMI models containing such parameters may
not be portable and may not generate the same results in all EDA tools.
Thanks,
Arpad
============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 24, 2015 11:35 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
Walter,
Thanks for the clear answer. By the way, my analogy with
hot or cold had nothing to do with the topic, I could have
used rain or shine, or anything else, I just wanted to
illustrate that I felt that I got a "Yes" to an "OR" question.
Anyway, now that I understand that you would flag both cases,
"A" and "B", my next question (again) is, whether we should
have a "severity" indicator along with this list next to
each Model_Specific parameter name to give an indication
whether the model would not work at all, or whether it just
would not give the "above and beyond" information if the tool
doesn't support its special parameter. I believe it would be
useful to have that information, but some people say that
this would complicate matters too much. But how would the
user know without this indicator whether they can use the
model at all with the tool they got or not? I would like to
get a consensus on that question now.
So this time I am going to ask a Yes/No question:
"Should we have some sort of a severity indicator"?
Thanks,
Arpad
=================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, September 24, 2015 8:01 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Out-InOut BIRD, lets get real
Arpad,
See below, my answer was Yes:
Arpad,
Yes, and that is when the User reads the documentation. At least he knows
he has to read the documentation and ask his EDA vendor what the EDA
vendor does.
Walter
Of course it should flag #A and #B. I though you analogy to Hot and Cold
was to the degree that it effects the results, and the "temperature" is
dealt with in the comments.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 24, 2015 8:48 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
Walter,
I don't understand why answering that simple question has to be so
difficult.
"Should the new Reserved parameter flag case B only, or both A and B?"
Here are my comments on your three examples:
If the simulator stimulus is not 8B10B encoded and the results are
pessimistic, the results are still correct, because the waveforms in
real life would be just as pessimistic if the hardware would run
without 8B10B encoding, correct? If yes, the model works as designed
whether the user pays attention to the need to set the stimulus to
8B10B encoding or not.
Now, if there is a Model_Specific parameter that tells the EDA tool
to use 8B10B stimulus and the tool doesn't interpret this parameter
and as a result is uses a regular PRBS stimulus, the results can still
be considered correct in the sense of fundamental IBIS-AMI, because
the AMI model and tool presented the correct answer to the user that
corresponds to the PRBS stimulus. So the lack of support for this
special Model_Specific parameter did not break the results. The
only problem is that the results were not as good as it could have
been if the parameter would have been supported in the tool. But
if this special parameter is listed in the new proposed parameter,
the user might look into the situation and read the description or
the manual to find out what it was supposed to do and why (if they
haven't done it yet). After doing so the user can still set the
tool's stimulus options manually to use an 8B10B encoded stimulus
and get the "better" results after all. I would classify this
situation as severity "yellow" ("A") because everything works according
to the IBIS specification, except the special feature needs special
attention. But I would prefer to flag this and list this parameter
in the new proposed Reserved parameter, because if it is not listed,
the user may not notice that the results they were working with were
not the intended results.
Your second example is very similar to the previous example. In this
case, in absence of support for a special parameter, the user will
need to select the appropriate Tx model depending on the CTLE settings
they use. This is a "dependency table" problem. If the tool doesn't
do it automatically, the used can hopefully still do it manually.
No matter what, the results are still correct according to the settings
used in the simulation, except that the settings may not be correct
without manual intervention. Garbage in, garbage out, but the answer
is still correct according to the settings used: garbage.
In your 3rd example my answer would depend on what you mean by
"the Rx model returns a parameter that the Model maker wants the EDA tool
to use in some waveform analysis calculation"
If "analysis" here refers to the basic eye and BER plot, and these would
be wrong without observing this parameter, I would call this a severity
"red"
("B") because non IBIS compliant only tool would be able to generate the
correct
results. But if "analysis" here means something beyond the basic eye and
BER
plots and these plots could still be correctly generated by all IBIS
compliant
only tools, I would call this a severity "yellow" ("A") condition, because
the
parameter is only needed for the extra, beyond the IBIS specification
stuff,
not the basic stuff.
So my question is still open:
"Should the new Reserved parameter flag case B only, or both A and B?"
I would prefer both.
Thanks,
Arpad
==========================================================================
=====
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, September 24, 2015 4:46 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
Arpad,
Yes!
If Cold is the model has no Model Specific parameters that are "Non
Standard", "Not Cold" is a .ami file that does have Model Specific
parameters that are "Non Standard". It is up to the documentation provided
by the Model Maker to describe the temperature of the "Non Standard" Model
Specific parameters.
At the point that this .ami model goes to a User, the Model Maker should
have already documented what he expects an EDA tool to do with these
parameters. The Model Maker in this documentation should describe what
functionality will be lacking if the EDA tool does not support the actions
the Model Maker would like the EDA tool to do with these parameters. There
are many grades of temperature between your #A and #B.
So, for my example:
1. An example of this is a requirement that this Tx has 8b10b
encoding built into it and simulator needs to generate an 8b10b pattern
(incorrectly written below)
a. Many (if not all) EDA tools can generate an 8b10b stimulus
pattern, and if the User does not direct an EDA tool (that does not
support this parameter) to use an 8b10b then the BER will be pessimistic.
Is this cold, tepid, hot or lukewarm?
2. Another example is that analog model required to generate the
impulse response of the channel is a function of the CTLE AMI setting.
a. This could be cold, tepid, hot or lukewarm, depending on whether
the EDA tool give the User the capability to use different analog models
for different CTLE settings, and how much the analog model differ between
different CTLE settings.
3. Another example is that the Rx model returns a parameter that the
Model maker wants the EDA tool to use in some waveform analysis
calculation. Again, the model maker can indicate if this is cold, tepid,
hot or lukewarm depending on what this calculation does.
I think we have to assume that Users can read, and read the documentation
that comes with the model, and that model makers can write clear
documentation.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 24, 2015 11:55 AM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
Walter,
Your answer is like: Is it hot or cold? Yes.
Thanks a lot.
Arpad
================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, September 24, 2015 10:41 AM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Out-InOut BIRD, lets get real
Arpad,
Yes, and that is when the User reads the documentation. At least he knows
he has to read the documentation and ask his EDA vendor what the EDA
vendor does.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 24, 2015 11:28 AM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Out-InOut BIRD, lets get real
Walter,
In summary, the two purposes you describe are
#1 Control the AMI DLL,
#2 Control the EDA tool.
But the second one can still be done in two different ways:
#A Without breaking the basic functionality of the model, i.e.
all tool can generate the basic eye diagrams and BER plots
correctly, and the tool that is capable of doing extra stuff
for that particular model can do more than the basics for
their user
#B The model would only work correctly in those EDA tool(s) which
understand these special Model_Specific parameters and other
tools will not be able do anything useful with the model.
Should the new Reserved parameter flag case B only, or both A and B?
Thanks,
Arpad
=====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, September 24, 2015 9:46 AM
To: IBIS-ATM
Subject: [ibis-macro] Out-InOut BIRD, lets get real
All,
Let's step back and discuss what AMI Model Specific parameters are all
about:
1. There are two primary purposes of Model Specific AMI parameters
a. Control what the DLL does
i. The
DLL should be controlled the way the silicon works
1. These usually map into the hardware registers that control the
actual buffer
2. Tx Tap settings
3. Rx CTLE settings
ii.
Model maker want to allow the user to turn on and off model features
iii. Use
to configure the DLL when the DLL supports multiple buffer implementations
b. Report to the user what the DLL did
i. DFE
tap values
2. The model maker wants to convey information to the User/EDA tool
on how to control simulations
a. An example of this is a requirement that this Tx model has 8b10b
encoding built into it
b. Another example is that analog model required to generate the
impulse response of the channel is a function of the CTLE AMI setting
c. Another example is that the Rx model returns a parameter that the
Model maker wants the EDA tool to use in some waveform analysis
calculation
The issue here is that the Model Maker, the User and the EDA Vendor wants
the Model Maker to add Model Specific parameters to allow the EDA tool to
programmatically do the functions described in 2. Above. The perpous of
this BIRD should be a mechanism that the Model Make can convery to the
User and the EDA tool that such Model Specific parameters exists, and a
standard place for him to document the parameters and what he is expecting
the EDA tool to do with them, whether they are Info parameters, In
parameters, Out parameters, or InOut parameters.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
