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
