[ibis-macro] InOut/Out BIRD draft and IBIS-AMI model portability
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 4 May 2011 12:36:50 -0700
Hello everyone,
This discussion brought out a lot of good questions and ideas,
but I am not sure if it gave answers to what triggered it, the
question on what to do with the content of the last paragraph
of the InOut/Out BIRD draft.
To summarize in a few words, the "logic problem" we are trying
to solve in the specification with this BIRD draft is that
Model_Specific parameters cannot be defined in the specification
due to their very nature of being model specific. As a result,
an EDA tool is unable to interpret and process any of these
undefined parameters, so any expectation that Model_Specific
parameters passed to the EDA tool should participate in the
analysis in a meaningful way makes no logical sense (to me).
Why should we leave the door wide open in the specification
to allow people to write such models (knowingly, or due to
ignorance) when the outcome of the simulation with such
parameters will be questionable?
I understand that this "loophole" or "backdoor" comes handy
when there is a need for a new feature which can't be done
with the existing specification. However, there is nothing
in the specification that says that EDA vendors or model makers
are not allowed to do things of their own outside the specification.
No one can police that, but such activities should not claim
(and should not feel the need for claiming) IBIS specification
compliance.
As an example to illustrate this situation is the usage of
S-parameters for package modeling. We all know that currently
there is no way of using S-parameter package models in the
IBIS context, but most tools can use S-parameter blocks for
package modeling, and many IC vendors distribute S-parameter
models for their packages. Does anyone claim that these package
models are IBIS specification compliant, just because they are
used together in a simulator with IBIS [Model]s which come from
.ibs files in which the package data is all zeroed out? I guess
we all know the answer...
This entire discussion actually applies to (Usage Info) also
(sorry Todd). The only difference with Info is that the
parameter comes from the .ami parameter file instead of the
model. Other than that, the problem is the same, we are passing
undefined Model_Specific parameters to the EDA tool. How could
the tool interpret and process such parameters without knowing
what they mean?
However, the situation with Info is becoming more complex in
light of the emerging analog model BIRDs and the usage of the
IBIS-ISS subcircuits. If we had a set of fixed circuit parameters
for the analog IBIS-ISS subcircuit, they could all be made
Reserved Parameters as suggested in the original analog BIRD 119.
But the reason we favor the usage of IBIS-ISS subcircuits for
analog modeling is to stay away from hard coded analog model
descriptions. In this case there is no way of telling what the
circuit parameters will be for each analog model in the future.
This would require that the analog model parameters are declared
as Model_Specific parameters. But there is a paradox here. We
want to pass these analog model parameters to the tool with
Model_Specific (Usage Info) parameters, yet we can't define
the meaning of these parameters and what the tool should do
with them because they are Model_Specific.
I think this could be solved by inventing a new "usage" for this
purpose. We could call it (Usage IBIS-ISS). If a Reserved Parameter
is (Usage IBIS-ISS) we can describe it in the specification, we
can define what the EDA tool needs to do with it, even though the
meaning of the individual parameter names under (Usage IBIS-ISS)
would not be spelled out and defined in the Reserved Parameter
section of the specification.
So having said all this, I would propose the following changes
to the InOut/Out BIRD draft. Keep the current content pretty
much the same, but add the prohibition of (Usage Info) for
Model_Specific parameters to the text. In addition, either
in this BIRD draft, or a new BIRD draft, I would introduce a
new usage called IBIS-ISS for the purpose of allowing undefined
IBIS-ISS subcircuit parameters to be passed to the tool from
Reserved Parameters in the .ami file.
Comments welcome.
Thanks,
Arpad
===================================================================
Other related posts:
- » [ibis-macro] InOut/Out BIRD draft and IBIS-AMI model portability - Muranyi, Arpad
