[ibis-macro] Re: PAM4 Out parameters question from yesterday's meeting.

  • From: Ambrish Varma <ambrishv@xxxxxxxxxxx>
  • To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>
  • Date: Thu, 30 Jul 2015 15:41:25 +0000

Hi Bob,
What do you mean when you say ‘IBIS-defined Model_Specific InOut parameter’ and
‘IBIS-defined InOut parameter’? Is this not the Reserved_Parameter? If it is –
then all EDA tools and ‘modellers’ are aware of its behavior.

BTW – modeller sounds way better than ‘model maker’ ☺

Thanks,
Ambrish.

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Bob Miller
Sent: Thursday, July 30, 2015 11:19 AM
To: wkatz@xxxxxxxxxx
Cc: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: PAM4 Out parameters question from yesterday's meeting.

Walter, Arpad (et. al.):
As a "model maker" I completely understand that I cannot expect any EDA vendor
to implement any functionality with respect to a Model_Specific parameter I
dream up other than what is agreed on in IBIS. (I can and occasionally have
asked reeeeeely nicely, but that's another story ;-) )
That having been said, standardizing EDA behavior, just like standardizing
model behavior, is something I think we want to be really careful about. In
both areas we may stifle truly great contributions to the art by short-sighted
restrictions -- I believe we've seen some examples of this in the past.
With respect to Walter's Model_Specific "Framis", if I invented it outside of
IBIS, I need to define it in such a way so that it plays nice with the EDA
platform's default treatment of generic InOut parameters. Now since there is no
specification in IBIS as to what Framis means, there is nothing that the EDA
platform is obligated to do with it. If I intimate that the customer should set
Framis to minimum, perhaps in certain cases, I better add another
Model_Specific parameter "Use_Fixed_Framis" which is a switch which informs the
model not to alter the value of Framis passed in by the user. In both cases the
model returns Framis in parameters_out.
On the other hand, if "Framis" is an IBIS-defined Model_Specific InOut
parameter which affects what the EDA tool presents to the user, as a model
maker I need to understand what the EDA tool is going to do with it, implying
some level of specification in IBIS as to what this parameter is supposed to
mean and what EDA tools are supposed to do with it. Also, (and I think this is
the crux of the issue at hand here) we need some specification as to when the
EDA tool is actually going to pay attention to the model's updates to the
parameter in AMI_parameters_out, both in Init and GetWave. I think the default
for any IBIS-defined InOut parameter should be that the EDA platform *always*
updates it's value for the parameter with the value the model returns in
parameters_out. If this is an IBIS-defined parameter, it may be appropriate for
the EDA platform to alter this parameter again before passing it back to the
model in the next pass, It then becomes the responsibility of the EDA tool and
modeller to make sure the value is never changed inappropriately. I believe
this protocol is both the most general and can be restricted (by either or both
parties) to implement any appropriate limitation.
In very specific cases where we all agree "bad things will happen" if a
parameter is altered by either the model or the EDA platform perhaps we add
appropriate restrictions. But I suspect we implement these restrictions as
cases/circumstances where "the model shall not change" or "the EDA platform
shall not change" a parameter. The basic default behavior that all returned
parameters are read need not changed. Great power. Great responsibility. All
that.

Regards,
Bob

On Thu, Jul 30, 2015 at 7:52 AM, Walter Katz
<wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>> wrote:
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<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

Other related posts: