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]
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
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
