Walter,
That example is just one out of a gazillion other possibilities the
model maker might want to do with your favorite parameter called Framis.
The specification doesn’t have any limitation for what could be invented
and you don’t seem to want the specification to have any such limits.
For example, another model maker might want the tool to integrate the
values returned from each GetWave call in a Model_Specific parameter
and expect the tool to make a really nice and meaningful plot for the
user.
A third model maker might just want to have the EDA tool to do the
opposite, take a derivative of it, and plot it in yet another way.
May be one of these would need to be plotted against another one of
these. No doubt, all being a very good and useful thing.
Even if these requirements are documented in the User’s Manual of
the model, how long do you think it will take for an EDA vendor to
implement these requests after they get such a model from a model
maker and release a new version of the tool?
But once again, can you envision the model maker wanting to work with
each of the tool vendors to give them all the information necessary to
implement what is necessary for that model to make that model platform
independent?
Or, can you envision the EDA vendors to spend the time with all model
makers and implement custom code in the tools for every one of them?
Hmmm… I am not sure that we are in the custom EDA software business...
I think we should revisit the discussion we had a few months ago on
the flexibility of the spec. Maybe a more flexible specification
could achieve what you have in mind here…
Thanks,
Arpad
=========================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, July 29, 2015 5:55 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: PAM4 Out parameters question from yesterday's
meeting.
Arpad,
So if a model maker outputs a Model Specific parameter Framis, and the
documentation with the model says that the buffer works better with Framis
being as small as possible, and we give our customers the ability to optimize
the system to minimize the value of Framis, “Is this not a good thing”.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, July 29, 2015 5:49 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: PAM4 Out parameters question from yesterday's meeting.
Walter,
Forget about the specific wording for a moment and let us
focus on the logic of this situation.
The greatest advantages of IBIS modeling is portability and
interoperability. I have seen these words in numerous SiSoft
presentations, so I think we are in agreement there. This was
one of the main reasons the IBIS standard was invented and the
main reason it was successful for so many years, despite its
numerous and sometimes serious limitations.
Suppose a model maker creates a model with a Model_Specific
parameter which supposed to have a very unique purpose in that
model. Since this is a Model_Specific parameter, the specification
cannot describe its meaning, purpose, usage, etc…, so EDA vendors
cannot implement any support for that very unique purpose (unless
they are good friends with the model maker, or perhaps are the
same company).
Now how portable is this model?
Do you think the IBIS specification should endorse and encourage
this situation, essentially undermining its own fundamental purpose
of promoting and supporting portable and interoperable models?
Let’s answer these questions first, and once we have the answer we
can worry how that should be worded, if at all.
Thanks,
Arpad
=====================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, July 29, 2015 4:20 PM
To: Muranyi, Arpad; curtis.clark@xxxxxxxxx<mailto:curtis.clark@xxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: PAM4 Out parameters question from yesterday's meeting.
Arpad,
To be specific, in
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20110613/arpadmuranyi/Out-InOut%20BIRD%20draft%2010/Out_InOut_BIRD_10.pdf
| However, in order to be compliant with this specification, Model_Specific
| parameters of (Usage Out), (Usage InOut) or (Usage Info) must not be used
| in any way to influence the EDA platform in how it prepares the input data
| for the algorithmic models, and/or how it processes the data returned by
| the algorithmic models.
I think the intent is quite clear. The specification describes the inputs and
outputs of a DLL. The specification has some reference flows. So this is an
attempt to limit what an EDA tool can do with Model Specific Out parameters. Or
do I not understand the meaning of “must not be used in any way”. And what does
“compliant with this specification” mean. The .ibs file, the .ami file and .dll
have “compliant” rules, since when are we in the business of “compliant” rules
for EDA tools?
Walter
