A quick scan tells me that Model_Specific Usage Out and InOut parameters
exist in 79% of the AMI files I have seen. These are from quite a few
vendors, a total of 190 unique Model_Specific Out and InOut parameter
names. It might be fair to say that the output data from these inherently
have no standard meaning for EDA tools, yet the tools today are not
confused by them. Documenting the special nature of these might be best
left to documentation.
One caveat regarding my proposal to use IBIS section 10.2.2 to delimit
what should be supported equally across all tools: that section barely
touches on the topic of the analog model, and we have had a good number of
BIRDs proposing new AMI parameters relating to the analog model.
Mike
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, September 22, 2015 11:58 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Out-InOut BIRD draft 12
Mike,
I tend to agree with your point about having to distinguish between the
various grades of specialness of a Model_Specific parameter.
I would summarize your example the following way:
A Model_Specific parameter would not need to be listed in this new
Reserved parameter if the parameter doesn't require the EDA tool to
perform some actions that cannot be described in the IBIS specification
for that parameter to generate the fundamental simulation results (eye
diagrams and BER plots).
A Model_Specific parameter should be listed in this new Reserved parameter
if support for the parameter in the EDA tool is required in order to
generate correct fundamental simulation results (eye diagrams and BER
plots).
The gray area is the case when the Model_Specific parameter provides
additional information based on which an EDA tool which knows the meaning
of these parameters might provide additional analysis results for the user
beyond the fundamental simulation results (eye diagram and BER plots), but
EDA tools unable to do so would still be able to simulate and generate the
fundamental simulation results correctly. One could argue that these
parameter do not need to be listed in the proposed new Reserved parameter
because these models still work correctly in all EDA tools even if they do
not support the model's special Model_Specific parameters. On the other
hand, one might say that these parameters should also be listed because
the presence of these parameters might confuse the EDA tool and/or the
user if they do not know that these parameters have a special purpose that
may not be supported by all tools.
This is why I thought that having a "severity" or similar indicator would
be useful to at least have a way to distinguish between these three
scenarios (like red, yellow, green).
That's my take on this. Thanks for your text proposal, I will munch on
it. I personally didn't like the words "tell the EDA tool" either...
Thanks,
Arpad
=================================================================
From: Mike LaBonte [mailto:mlabonte@xxxxxxxxxx]
Sent: Tuesday, September 22, 2015 8:14 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Out-InOut BIRD draft 12
Hi Arpad,
True, I should not have written that In parameters can't affect the EDA
tool; I subconsciously trivialized the possibility of that. And I'm not
saying anything necessarily new, just getting it out in writing for email
discussion.
We have a challenge here in that we usually try to make things easy for
model makers and users at the expense of tool developers, but in this case
we are talking about changes to allow tool developers to safely lead. It
might be going too far to have detailed info in AMI files on the impacts
of some parameters. But a simplistic
ThereIsSomethingWrongWithTheseParameters list might engender user
perception problems, unless we clarify when model makers should use it and
what it means for the user.
So to simplify things we can first ignore scenario #2, the one that would
allow any tool to make use of special model capabilities. Yes, that would
be more complex and it might fall short anyway. So we are back to the
list.
But if we will form a simple list of special parameters the rules should
be clear on why a particular parameter would want to be on the list. For
example models exist today with Out and InOut parameters that provide
simple diagnostic data should anyone want to see it. There would be no
reason to include those on the list, right? Yet if a tool decides to use
that data to accomplish something special then suddenly those parameters
do need to be on the list? But maybe if the output data has no effect on
ordinary simulation, that would except them from the list?
How about if we change:
"This reserved parameter tells the EDA tool which Model_Specific
parameter(s) rely on non-IBIS-standard features in the EDA tool, and
consequently may not be supported by all EDA tools."
to:
"This reserved parameter identifies the names of
Model_Specific parameter(s) that rely on EDA tool support for simulation
types not described in section 10.2.2, and consequently may not be
supported by all EDA tools."
The reason I eliminated "tells the EDA tool which" is to not imply in any
way that this must be used, since doing so could make existing IBIS
compliant models no longer comply (although they would still pass
IBISCHK). If we accept the proposal to use section 10.2.2 to define which
parameters would be candidates for the list, then maybe it could be called
something like SpecialSecenarioParameters or SpecialApplicationParameters
or LimitedSupportParameters, and 10.2.2 might even note "See GENERAL
RESERVED PARAMETERS for information about other simulation types with
limited support." At the end of the first paragraph.
Mike
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
