A tool knows if it can handle special Model_Specific parameters when it
recognizes their names. To that tool it is as though it were a
Reserved_Parameter. But since the special names are not actually reserved
there is a risk an unaware model maker might accidentally use one of these
parameter names, and some tool might try to so something special with it.
For this the Reserved_Parameter we have been discussing can help. Even if
it recognizes a parameter name as special, a tool should not do anything
special with it unless it is listed in the parameter name table (don't
want to use its name until we've settled on that).
But this makes listing the special parameters required for model makers
who don't want to take that risk. As an alternative I think they might
just use more unique parameter names, possibly prefixed with proprietary
names. That would negate the ability to propose the names used as new
Reserved_Parameters and have them take effect in all tools once the BIRD
is incorporated, assuming we will not allow proprietary content in
Reserved_Parameter names.
A few thoughts regarding the "severity" indicator:
1. It has to be defined clearly so that there is some hope of being
interpreted the same way by all.
2. I'm reminded of the IBIS Quality specification IQ levels, which
would indicate the level of impact failure to pass a check might have.
3. We need a better name for it. Severity implies a sequence of
magnitudes, whereas I think this is about categories of capabilities.
Mike
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, September 25, 2015 12:35 AM
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] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 24, 2015 8:48 PM
To: IBIS-ATM <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] 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] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 24, 2015 11:55 AM
To: IBIS-ATM <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] On Behalf Of Muranyi, Arpad
Sent: Thursday, September 24, 2015 11:28 AM
To: IBIS-ATM <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] 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
