Walter, Mike,
Here are the suggested texts I received from the two of you
(privately and publicly), and my version following them:
WK: This reserved parameter lists the Model_Specific parameter(s) that the
model maker would like the EDA tool to use to affect simulation results.
ML: 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.
AM: This reserved parameter identifies by name all Model_Specific parameters
which require special EDA tool support to utilize special features in the
model, developed for simulation or analysis types not defined or described in
the IBIS specification, and consequently may not be supported by all EDA tools.
Please let me know what you think of it...
What I like about my version is that it is "passive", i.e. it
doesn't mention model makers, EDA vendors, or who is expecting
or doing what, etc..., it just "states the facts".
We might want to extend this language (and the features/syntax
of the new proposed reserved parameter) so that there would be
some indication for the level of deviation from standard behavior.
I still think that it should be useful to reveal whether the
Model_Specific parameter is either completely spec compliant
(green light), or whether it adds capabilities for new
analysis/simulation types without breaking the IBIS-standard
behavior of the model (yellow light) or whether it won't work
at all unless the EDA tool supports its particular features
(red light).
I will address the text under Usage Rules and Other Notes later...
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
