Bob,
I disagree with most of what you say.
Regarding your 1st paragraph, we have seen tons of models with Model_Specific
parameters in the past which require a selection from the user. Just a few
examples to illustrate what I am referring to:
AGC settings
CTLE settings
Adaptation on/off
and the list goes on.
I don’t think anyone has a problem with making selections for any of these
parameters, because usually the description string (or the manual of the model)
provides enough information to know what these parameters mean. None of these
parameters rely on the EDA tool to do anything special. It just works. I
don’t see why these would need to be flagged as something that requires
special attention or treatment. (By the way, Format corner doesn’t require
user selection, the tool’s corner setting will automatically select the
corresponding value from its list, so you need to scratch that off your list
for that reason alone).
Regarding your 2nd paragraph, “normal” Model_Specific parameters do not require
any special actions. That’s why the above is working so far. The topic of
our discussion is about the case when the Model_Specific parameters do require
special actions.
But there are two possible scenarios in that category:
#1) the special actions are above and beyond the normal tasks of an AMI
model and not providing the special actions would still allow the user to
get the normal tasks done in ANY tool
#2) not supporting the special actions needed by the model renders the
model useless in any tool that can’t perform those special actions.
You seem to be suggesting to flag parameters in both of these categories.
If we did that, I think we should also have an accompanying qualifier
in that parameter list to say which of these two categories the parameter
falls into.
Others seem to suggest that we should only list those parameters which will
not work at all in tools which do not support the extra features in the model.
If we did that, we wouldn’t need the additional “qualifier”.
So my question is still open, which of these two categories should the new
proposed Reserved parameter flag?
Thanks,
Arpad
=================================================================================
From: Bob Ross [mailto:bob@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, September 23, 2015 4:27 PM
To: dmarc-noreply@xxxxxxxxxxxxx; Muranyi, Arpad
Cc: 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Out-InOut BIRD draft 12
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>
[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<mailto: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<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<mailto: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>
[mailto: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<mailto: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]
Sent: Tuesday, September 22, 2015 8:14 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto: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
