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

  • From: "Bob Miller" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "bob.miller@xxxxxxxxxxxxx" for DMARC)
  • To: ambrishv@xxxxxxxxxxx
  • Date: Thu, 30 Jul 2015 10:59:04 -0600

Arpad -

This may be a misconception on my part -- we have only recently had
parameters defined here which actually need to be passed to/from the
executable, as opposed to merely used by the EDA platform. It has not been
clear to me that all EDA platforms routinely pass Reserved_Parameters to
the executable. If so, sorry for the confusion -- interpret my use of
"IBIS-defined Model_Specific" as "Reserved_Parameters passed to/from the
executable"

On Thu, Jul 30, 2015 at 9:41 AM, Ambrish Varma <ambrishv@xxxxxxxxxxx> wrote:

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’ J



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> 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] *On Behalf Of *Muranyi, Arpad
*Sent:* Wednesday, July 29, 2015 7:22 PM
*To:* 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 <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 <ibis-macro-bounce@xxxxxxxxxxxxx>] *On
Behalf Of *Muranyi, Arpad
*Sent:* Wednesday, July 29, 2015 5:49 PM
*To:* 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 <wkatz@xxxxxxxxxx>]
*Sent:* Wednesday, July 29, 2015 4:20 PM
*To:* Muranyi, Arpad; curtis.clark@xxxxxxxxx; 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: