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>
[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
