Minutes from the 18 August 2015 IBIS-ATM meeting are attached.
Randy
IBIS Macromodel Task Group
Meeting date: 18 August 2015
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
Curtis Clark
Avago (LSI) Xingdong Dai
Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC David Banas
Marc Kowalski
Ericsson: Anders Ekholm
IBM Steve Parker
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Nicholas Tzou
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: * John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp. James Zhou
Andy Joy
SiSoft: * Walter Katz
* Todd Westerhoff
Mike LaBonte
Synopsys Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: Bob Ross
TI: Alfred Chong
(Note: Agilent has changed to Keysight)
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- None.
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- None
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Todd: They look fabulous.
- Todd: Motion to approve.
- Arpad: Second.
- No objections.
-------------
New Discussion:
Info, Out, InOut BIRD draft:
- Arpad: Last week we had a discussion on Info, Out and InOut, discussing how
to tighten up the spec on it.
We could have a new branch, so if a parameter ends up in the spec it won't
lead to parsing issues.
We could have a sub-branch under Model Specific but agreed it wouldn't be a
good idea so the DLL wouldn't need to be rewritten if the parameter
becomes standardized.
I would like to make a decision today on what the rules should be.
- Todd: What problem are we trying to solve?
- Arpad: His understanding is that one of the main strengths of IBIS is
portability.
If we have Model Specific parameters with these usages, a model could
become non-portable and IBIS will become less usable in the end.
- Todd: So, the problem is that parameters that get put in the model affect
how the model interacts with the simulator, and these are not part of the
existing definitions of parameters.
Are we trying to prevent it from happening, acknowledge it happens and
standardize it? What is the goal?
- Arpad: The goal is preventing EDA vendors from hearing complaints about
models not working in all tools.
We need to make it clear that certain features are for certain tools.
- Todd: It is a delicate topic of standardizing the non-standard. So, it seems
we are saying that if you work outside the standard, then you should
identify it clearly with this mechanism.
We are acknowledging that this happens.
- Arpad: If we make a model that works in only one tool, is it an IBIS model,
since it doesn't follow the spec?
- Todd: So are we going to say that these models are ok?
- Arpad: The spec does allow now models that will be proprietary, due to a
loophole. This is mostly AMI-specific.
- Ambrish: Why hide behind the spec and pass something that will for sure not
work in other tools?
Why not use comment characters so the parser doesn't choke?
We have used this before and it has worked.
- Walter: How can any Out or InOut parameter cause any tool to have problems?
- Ambrish: You are hiding behind the Out parameter to see different results in
different tools.
- Walter: What if a manual that came with the model reports what an Out
parameter does and issues warnings?
If the model maker documents what the Out parameter does, and an EDA tool
chooses to read that parameter or the user does, why should we
prevent
that from happening?
- John: The Model Specific branch is for this type of information already.
- Todd: Arpad is right in saying there is a loophole. Results can be affected
by these Out parameters.
- John: Model Specific parameters can affect the output by allowing the user
to change certain settings.
But there can be tool-specific implementations.
- Ambrish: We could prevent Model Specific parameters from being Info so that
they are only used by the tools.
- Todd: So we are trying to address model portability between tools.
Are we trying to tell EDA vendors their simulator shouldn't recognize
specific parameters and do special things?
Or are we just trying to let people know this is happening in a standard
way?
- Arpad: We can allow this, but we shouldn't lead users into thinking the model
is completely IBIS compliant and will work in all tools.
- Todd: Users don't always understand nuances of the standard, don't want to,
and don't want to get into details when they just want to get their
work done.
He has spent a lot of time telling customers why certain models don't work.
He learned to find ways of just getting models to work.
Support for Touchstone files is an example.
You'll get the same result just dropping the S-parameter in the schematic.
- Walter: You won't get the same result.
The model says to use a specific Touchstone file.
But the user gets things confused half the time and sets it up wrong.
Model makers don't want this source of error.
They just want it linked in the AMI file.
SiSoft did something proprietary to fix the issue.
- Todd: There are cases when tools are innovating, and hopefully they are at
least telling people what they are doing.
There is a point when this solution gets brought to IBIS.
If it isn't accepted, then at some point models need to be rewritten to
support a standard way.
- Ambrish: When does the reconciliation process happen?
How should we prevent proprietary methods from continuing to be used and
not get updated to use standard methods?
How can we move Model Specific parameters back into the spec?
- Radek: There have been discussions that all the simulators don't know what
to do with the Model Specific parameters.
- Arpad: What if we suggest that Model Specific parameters can only have In
types.
The parser could allow Out but flag it with a message.
- Todd: There are good uses for Out types.
- Ambrish: Can we say that Info is not allowed?
That type is meant for the tool only.
- Todd: That is stifling innovation.
- Ambrish: The parser could issue a warning.
- Radek: In that case the simulation should error out if the parser fails.
- Todd: There are three parts to this.
Can we advance the standard and allow model portability with information
sharing?
There is then a responsibility to bring new ideas to the standard.
Then There is a time when models have to be brought into compliance.
- Ambrish: What can you do when a parameter notifies you that a model may work
differently in different tools?
- Todd: It could be put in Reserved Parameters and cause a parser issue.
One thing is that we could use the notification method of comments such as
"|SiSoft".
The burden is not legislation but notification.
Or we can come up with a new method.
- Ambrish: The parser does the job of notifying you of potential issues.
- Walter: It seems best to use the comment field when there is an advanced
feature.
- Ambrish: This means you can't legislate any way of controlling this.
But it is a good way of notification.
- Walter: In reference to Radek's comments, making Model Specific parameters
that are Out was not a loophole.
It was specifically intended to do these kinds of things.
That was the mechanism for experimenting with new things that could go
into the standard. This was not a loophole.
- Ambrish: Is there any issue with a parser warning that parameters in Model
Specific may cause differences in different tools?
- Todd: Maybe we should make a legitimate place for these parameters.
If we just take Info type Model Specific parameters and flag them, there
are workarounds like making them In type so they don't generate
parser
messages.
Generating parser messages does create a tone of models being bad.
It would be better to legitimize the model innovations.
- Walter: Motioned to table the unofficial BIRD and continue with the way
things are handled now.
No second.
- Arpad: Coming back to how to make this legitimate, John said there was an
issue with my previous suggestion, but I would like to understand better.
Can't we have a way to pass proprietary parameters by inventing new
Usage types, such as InfoProrietary, OutProprietary, InOutProprietary
and use these for the non-standard, innovative parameters?
- John: InOut does the legitimate thing and Info does the proprietary thing.
- Radek: When you put something into the Model Specific section, you don't
pass the branch name into the DLL.
We are asking for a better established way of informing the user.
We have a description string in the definition of the parameters.
That could be used to inform the user.
- Arpad: The parser can't flag that.
- Radek: The parser could flag a Model Specific section with Info or InOut,
noting that the model could be proprietary.
- John: Jitter parameters in the Model Specific branch could be Out.
There is a hole for notification.
- Arpad: I think we should continue thinking about a solution to this.
- Todd: There has been better agreement on the notification aspect of this.
We want the user to easily see that a model may only work in specific
tools.
-------------
Next meeting: 25 August 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
