Walter,
Quoting from the BIRD draft:
****************************************************************************
ANY OTHER BACKGROUND INFORMATION:
The issue was raised that the process of adopting new features is very
slow in IBIS and there was a need to be able to make use of such
unintended capabilities on a temporary bases. However, the majority
of the participants felt that new capabilities can be implemented in
tools and models outside the specification until the specification
incorporates the new features.
Suggestions on how to make the specification more flexible were also
mentioned in these discussions, but will not be captured here due to
the complexity of the topic.
****************************************************************************
Thanks
Arpad
=================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, July 30, 2015 8:53 AM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: PAM4 Out parameters question from yesterday's
meeting.
Arpad,
You made my point exactly!
You have documented exactly what is happening, and how the standard is
improving. This is the exact process we went through with vendors to develop
the PAM4 specification, and what Cadence did to develop their backchannel BIRD.
We all use Model Specific parameters to solve the customers problems., and in
fact the model makers want their models to be portable between EDA vendors so
they drive the EDA vendors to standardize the use of these Model Specific
parameters, and then drive the EDA vendors to bring these to IBIS to
standardize them.
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 7:22 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: PAM4 Out parameters question from yesterday's meeting.
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<mailto: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
