Hi Bob -
I think the first part of your statement:
I think any Model_Specific parameter of Format: List, Range, and Corner is
a candidate for the “SpecialParameters” list (except for tap names). The
model maker expects EDA tool to offer a choice to the user (unless the
selection is automated by the executable model (.dll or .so).
is the "mulberry bush" we ran around a lot in the meeting. I may be wrong,
but I think IBIS would specify (does it??) that a parameter of Format you
describe be presented to the user for selection. It's been that way ever
since I built my first model about a decade ago. But that's *all* IBIS
would expect the EDA tool to do with it.
Your second part:
Even though the selection names may provide obvious choices that are
closely linked to the executable model, the names and expected actions
are not officially specified. Another vendor can use the same name with
different selections and actions.
... I respectfully submit is not an issue because they only affect their
respective executables associated with the identically-named parameters and
the EDA tool should probably not be shuffling them together in the GUI
presented to the user in the rare case where both executables appear in the
same analysis. Apart from this minor issue, the ordinary function of any
Model_Specific parameter is a conversation between the model maker and the
user that the EDA platform (and IBIS) should be agnostic to.
Finally:
Also, if the parameter expects the EDA tool to perform some unspecified
action (such as processing the parameter) that only a few EDA vendors
have implemented, that parameter should be added to the list.
is the part which we are probably most concerned about clarifying at the
moment. I think we are in complete agreement that a Model_Specific
parameter which *must* be understood by the EDA platform to generate
*correct* results in any *standard* IBIS analysis should appear in the
table. A Model_Specific parameter which "aids" certain EDA platforms to
produce the *same* results (only, say, faster) than other IBIS-compliant
platforms would IMO not need to appear, because the user of the "slow"
platform would still get the right answer. And I as a model maker wouldn't
care if the model was run on some other IBIS platform unless the slowdown
was so great as to cause the user *problems* (in which case I would
voluntarily add it). And a parameter which enabled some extra-IBIS analysis
"feature" in one platform but which otherwise didn't impair ordinary use in
standard platforms need not appear unless the special analysis was critical
to successful channel design for any user who desired to use this serdes
and so as a model maker I wished to compel the user to exploit it.
It's these latter qualifications which we want to try to reach consensus
on, IMO. I'm willing to yield on the "fast/slow" example above, for example.
Regards,
Bob
On Wed, Sep 23, 2015 at 3:27 PM, Bob Ross <bob@xxxxxxxxxxxxxxxxx> wrote:
All,
I think any Model_Specific parameter of Format: List, Range, and Corner is
a candidate for the “SpecialParameters” list (except for tap names). The
model maker expects EDA tool to offer a choice to the user (unless the
selection is automated by the executable model (.dll or .so).
Even though the selection names may provide obvious choices that are
closely linked to the executable model, the names and expected actions
are not officially specified. Another vendor can use the same name with
different selections and actions.
Also, if the parameter expects the EDA tool to perform some unspecified
action (such as processing the parameter) that only a few EDA vendors
have implemented, that parameter should be added to the list.
Bob
*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:
ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Bob Miller (Redacted
sender "bob.miller" for DMARC)
*Sent:* Wednesday, September 23, 2015 1:48 PM
*To:* Muranyi, Arpad
*Cc:* IBIS-ATM
*Subject:* [ibis-macro] Re: Out-InOut BIRD draft 12
Well, I like it, Arpad <grin>...
This test would capture our "Exhibit A" pixie named "Tstonefile". It would
also capture pre-6.1 PAM4 parameters since if the user set the
Model_Specific parameter "Modulation" to "PAM4" in most IBIS-compliant
pre-6.1 platforms he would get the wrong result. It would *not* capture a
few hooks I embed into all my models to support exotic analyses on our own
internal "lab" platforms but which do *not* alter standard results on any
IBIS-compliant commercial EDA platforms.
Of course if you write the BIRD to capture these hooks I will just*
ignore* the "requirement" to declare them <wink>.
Anybody got an example of something we can agree we really want to capture
that Arpad's proposition does NOT capture?
Bob
On Wed, Sep 23, 2015 at 2:29 PM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
wrote:
Bob,
Thanks for your comments. When I wrote that text, I was still trying
to cover what I previously described as the “gray area”. But if we
all agree that we do not want to include those Model_Specific parameters
in this proposed Reserved parameter list which do not break the fundamental
operation of a model in any of the IBIS-compliant EDA tools, then we
could modify my text to reflect what you state in your comment here.
So here is the question to all:
Should we only flag those Model_Specific parameters which do not work
properly in strictly IBIS-compliant EDA tools for basic simulations,
or do we want to include those Model_Specific parameters also which
add on new/extended capabilities to the model for those tools which
know how to deal with it without breaking the basic simulations in
all other strictly IBIS-compliant tools?
Thanks,
Arpad
=========================================================================
*From:* Bob Miller [mailto:bob.miller@xxxxxxxxxxxxx]
*Sent:* Wednesday, September 23, 2015 3:20 PM
*To:* Mike LaBonte
*Cc:* Muranyi, Arpad; IBIS-ATM
*Subject:* Re: [ibis-macro] Re: Out-InOut BIRD draft 12
Partners-in-crime --
In case my point escaped notice (I was rather obtuse about it), "supporting
a simulation or analysis type not defined or described in this
specification” is actually* NOT* the case we are trying to capture with
the BIRD, at least as I understand it. "Materially altering the results
of a simulation or analysis type which is defined or described in this
specification via a mechanism which is not defined or described in this
specification and thus may not produce consistent results across EDA
platforms conforming to this specification" *IS* the Cornish pixie we are
trying to tack down.
At least I *think* it is <grin>...
Regards,
Bob
On Wed, Sep 23, 2015 at 2:03 PM, Mike LaBonte <mlabonte@xxxxxxxxxx> wrote:
Hi Arpad,
Picking up on just one phrase “not defined or described in the IBIS
specification”, I think since it appears in the specification it would
say “not defined or described in this specification”.
Another question is if “simulation or analysis types not defined or
described” covers all of the cases we would want it to. For example, even
though IBIS requires that “algorithmic models must be able to produce
valid results at any sample_interval”, many do not. For these
non-compliant models it could be useful to have a parameter stating the
range or set of values that work, and tools could try to accommodate. But
would everyone interpret that as supporting a “simulation or analysis type
not defined or described in this specification”?
Mike
*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:
ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Muranyi, Arpad
*Sent:* Wednesday, September 23, 2015 3:04 PM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: Out-InOut BIRD draft 12
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 <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
