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
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, September 22, 2015 7:31 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Out-InOut BIRD draft 12
Mike,
Thanks for posting the BIRD draft and for announcing it.
Regarding "In parameters require no new treatment. They only affect model
behavior and
all tools have equal access." at the end, Walter would disagree with you
on
that. I made a similar statement in the meeting today to which
he replied that it is correct that Usage In parameters are passed
into the model DLL, but the EDA tool can also pay attention to it
and act on it. One might argue that if the .ami file has information
for the EDA tool, it should use Usage Info for that purpose, but
then what if the same parameter would need to go to the model AND
to the tool too? Repeating the same parameter twice as Usage In
and Usage Info clearly doesn't make sense.
The same thoughts also apply to the "In" portion of Usage InOut
parameters.
Regarding the rest of your comments, what you are saying are similar
to my suggestion earlier about having a "Severity" indicator in
this proposed "warning mechanism". I brought up the same example
you mention, one can have a model with all kinds of proprietary
extensions, yet it could still give the same and correct results
for its basic functionalities in all tools even if a tool doesn't
support its extensions. In a case like that issuing the warning
about the out-of spec parameter may be misleading because it could
lead the user to think that the model is totally unusable in a tool
that doesn't support those features, yet in reality it might still
work very well for most of its purposes. My suggestion was discarded
rather quickly that it was going to get too complicated. So I think
what you are suggesting would be useful in many cases, but then the
question is, do we want to have this level of detail information in
this proposed new Reserved parameter?
Regarding the title mentioning the various usage types by name,
please remember where this BIRD draft started from. In its early
versions this BIRD draft tried to "clarify" what the simulator should
or shouldn't do with the data in the various usage types when the
parameter was Reserved or Model_Specific. The proposed text tried
to put a restriction on the EDA tool regarding what it was allowed
to do with the data in Model_Specific parameters of certain usage
types. So the various usage types were discussed very specifically
in the BIRD text. We moved away from that approach in our recent
discussions, but we didn't change the title of the BIRD. Since it
hasn't been submitted yet as an official BIRD, we can still change
the title if so desired. I am open for suggestions, but I would
prefer to first finish the content of it.
Thanks,
Arpad
=====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Tuesday, September 22, 2015 4:39 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Out-InOut BIRD draft 12
The BIRD draft discussed in the IBIS ATM meeting today was posted online.
Note that this is before changes made by Arpad in real time during the
meeting:
DATE
AUTHOR <http://www.eda.org/ibis/macromodel_wip/archive-author.html>
ORGANIZATION <http://www.eda.org/ibis/macromodel_wip/archive-org.html>
TITLE <http://www.eda.org/ibis/macromodel_wip/archive-title.html>
FORMATS
22-SEP-2015
Arpad Muranyi
Mentor Graphics
Out-InOut BIRD draft 12
(zip
<http://www.eda.org/ibis/macromodel_wip/archive/20150922/arpadmuranyi/Out-
InOut_BIRD_draft_12.zip> )(pdf
<http://www.eda.org/ibis/macromodel_wip/archive/20150922/arpadmuranyi/Out-
InOut%20BIRD%20draft%2012/Out_InOut_Info_BIRD_12.pdf> )
A number of comments were raised in the meeting, but I would like to bring
up one more. The BIRD title is "Clarification of Usage Out, InOut and Info
for IBIS AMI", yet the proposed specification text does not have those
Usage values, except that "Info" appears in an example. If they each have
special considerations these should be described.
A second consideration is that this new proposal potentially provides two
services:
1. Warning tools and therefore users that a model might not behave
the same in all tools, even using standard flows. TStoneFile was given as
an example.
2. Allowing any tool to know how to make use of special
capabilities, whether they relate to standard or non-standard flows.
Optimization parameters would be an example of non-standard flows.
Outlining one Usage at a time:
* Out and InOut parameters potentially produce information that
EDA tools could use differently.
o As discussed in the meeting today, one might argue that if dropping a
model into every known tool produces by default the same results for the
standard statistical and time domain simulation flows already discussed by
the specification, then maybe it can be said to be a compliant model even
if it has Out or InOut parameters with no standardized meanings for the
output data. In that case nothing new is required to make it compliant.
o If the output data provided by the model affects standard flows in
some tool(s) then some declaration of that is needed to support #1 above.
o Information could be added to say something about the "unused" model
output data to convey that there is potential for special capability
outside of standard flows, to support #2 above.
* Info parameters potentially contain information that EDA tools
could use differently. Since Info parameters are used only by tools, one
might argue that each EDA tool would easily be able to determine by
parameter name whether it is able to provide any kind of special support
for any Info parameter.
o No new AMI provision should be needed for tools to warn about
unexpected Info parameters. But tools other than the one(s) the Info
parameter is designed for will not know whether the Info parameter affects
standard flows or only non-standard flows. So their warning may or may not
be a false alarm.
o If the Info parameter affects standard flows in some tool(s) then
some declaration of that is needed to support #1 above for the other
tools.
o Information could be added to say something about the Info parameter
to convey that there is potential for special capability, to support #2
above.
* As the draft BIRD title implies, In parameters require no new
treatment. They only affect model behavior and all tools have equal
access. The specification, or at least the BIRD background, probably
should say that just for completeness.
Sorry for not posing this as BIRD language. I'm seeking feedback on the
concepts.
Mike
