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
