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
