[ibis-macro] Re: Usage Out syntax rules

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 16 Dec 2011 18:25:49 +0000

Mike,

Regarding "Your definition of "default" is very different from any other that I 
have ever encountered.",
I don't think so.  I am just applying the same definition to
something different from what you are applying it to.  And this
is happening because the spec doesn't spell out how to apply it.

Regarding "... I still don't see what problem your proposed BIRD solves", this 
is
what I am trying to solve with this proposed BIRD...

Thanks,

Arpad
=================================================================

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Mike Steinberger
Sent: Friday, December 16, 2011 9:48 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Usage Out syntax rules

Arpad-

Your definition of "default" is very different from any other that I have ever 
encountered.

The operative phrase from BIRD 127.4 is "for the case when the user doesn't 
make that selection". I see that that phrase is limited in that for parameters 
with Usage Out, it's the model that makes the selection and not the user. So 
that phrase probably should be modified to read "for the case when the user or 
the model doesn't make that selection."

Your statement about Default being THE value is very surprising, in that if the 
Default value is THE value, then there's no reason to have the other Formats 
such as Range, List, etc. According to your statement, these formats would be 
ignored, and the Default value would be used regardless. I don't see how that 
can make any sense.

With the possible exception of editing the phrase in BIRD 127.4, I still don't 
see what problem your proposed BIRD solves.

Mike S.

On 12/15/2011 02:28 PM, Muranyi, Arpad wrote:
Mike,

Let's clarify what the meaning of "Default" is then and
review what the spec and BIRD 127.4 says about it.

In BIRD 127.4 we say that
- Default and Value are mutually exclusive, i.e. single
   valued parameters can only have Value <data> or Default <data>
   but not both.
- All other types of parameters are multi valued, Range, List, etc...
   in which case Default is optional and is used for the purpose of
   "selecting" a value from all of the possibilities within the range
   or list, for the case when the user doesn't make that selection.

In the latter case, the meaning of Default to me is not so
much about what initial conditions the EDA tool should assume
while it is waiting for the "real thing" to arrive.  In this
context, Default to me means that from all the possible values
defined in the .ami file, this is THE value that should be
passed on.  Whether that value is supposed to be interpreted as
an initial condition (or default) in the tool or not would
depend on the definition, or description (semantics) of the
parameter itself which is a different story.

In the former case, Default and Value are treated as synonyms,
but at the end it is still just a value that is passed on.  My
interpretation is still the same, that whether the value is
supposed to be treated as an initial condition (or default)
in the tool or not would depend on the definition, or description
(semantics) of the parameter itself.

So I think of "Default" in the .ami file as a default for the
selection mechanism for multi valued parameters so that one
value could be passed on whether the user makes the selection
or not.  I do not think of "Default" in the .ami file to mean
that these values are to be treated in the EDA tool as initial
conditions or defaults for Usage Out parameters whose real value
will be given to the EDA tool later by the AMI model.  In this
context my view is that the spec does not define or even mention
that Usage Out parameters are supposed to be initialized in the
EDA tool using the values in the .ami file.

This is the hole I see in the spec that needs to be plugged.
We need to describe or define what the purpose of the <data>
in the .ami file is for Usage Out parameters.  It seems (even from
this thread) that different people may interpret the situation
differently, and I think this can cause problems down the line.

Regarding "I hope we're not trying to make all tools produce the same results", 
yes and no.
There are some basic expectations where all tools should produce the
same results, but there are situations when the results may differ due
to proprietary secret sauce algorithms.  Here is yet another possibly
stupid example, an integration.  If two tools produce different results
because they and/or the model maker had different assumptions on how
a Usage Out parameter would initialize the integration constant, one
tool might return a DC shifted waveform while the other might not.  In
this case I would indeed expect the two tools to give the same results
with the same input parameters in the .ami file.

Thanks,

Arpad
========================================================================





From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Thursday, December 15, 2011 1:30 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Usage Out syntax rules

Arpad-

First of all, it seems like we need a better example.

Secondly, it seems that the problem we're trying to solve is to make sure that 
models can run in all tools. That's good. However, I still don't see how 
differing assumptions about how to interpret the default value of an Out 
parameter could cause model to be unable to run in different tools.

Thirdly, I hope we're not trying to make all tools produce the same results. 
That's outside the scope of the IBIS specification, and yet it seems to be the 
problem you're trying to address.

Fourthly, the very definition of a default value is that it's the value to be 
used until another value becomes available. I believe this principle clearly 
applies in the circumstances you're describing, and is sufficient to completely 
answer the questions you're posing.

Mike S.

On 12/15/2011 01:05 PM, Muranyi, Arpad wrote:
Mike,

I did say that "It may not be the best
example, but I hope it illustrates my thinking".

Re "What <data> are you referring to, specifically?"
I am referring to "<data>" that is described
in the spec and BIRD 127.4 as "<data>", i.e.
the value(s) provided for the various parameters.

Re "What problem would they be trying to solve that would cause either the EDA 
vendor or their tool to choose some value other than the one supplied by the 
model developer?", this is irrelevant to this discussion.

The question is about data flow between the .ami
file, EDA tool, and AMI model.  The spec says
Usage Info data goes from the .ami file to the EDA
tool, Usage Out goes from the AMI model to the EDA
tool, Usage In goes from the .ami file to the AMI
model, Usage InOut goes from the .ami file to the
AMI model and then from the AMI model to the EDA
tool.  So the question remains, if the .ami file
supplies <data> (values) with Usage Out, but the
spec says that for Usage Out the value comes from
the AMI model, what are we supposed to do with the
data that is supplied in the .ami file for the Usage
Out parameters?  Since there are many options for
what to do with that data, I expect that different
EDA vendors and model makers might decide to do
different things.  This may result in non-portability,
and non-interoperability.

Re "Supposing the EDA vendor or their tool chose a value other than one
supplied by the model developer and they happened to get it wrong, how
does that concern IBIS?"  This is not what I am talking about.
I am talking about a situation when the model developer
can supply two values without being able to tell the
EDA tool which one to use and when.  One of the values
in the .ami file in the Usage Out parameter's <data>
and the other value returned by the AMI model for the
same Usage Out parameter.

Re #3 below, I am not talking about that at all.  Like
I said, my example may not have been a perfect one, but
you should have looked past that instead of starting to
pick on its imperfection.  Please try to talk about the
problem, not about how my illustrations are imperfect.

Thanks,

Arpad
========================================================




From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Thursday, December 15, 2011 11:34 AM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Usage Out syntax rules

Arpad-

I can't see how your example represents anything that people/EDA tools are 
doing now, or would do to solve a plausible problem.

1. Your example supposes that the EDA tool vendor (not just the EDA tool) 
decides to store the <data> for internal data structure initialization. What 
<data> are you referring to, specifically? What problem would they be trying to 
solve that would cause either the EDA vendor or their tool to choose some value 
other than the one supplied by the model developer?

2. Supposing the EDA vendor or their tool chose a value other than one supplied 
by the model developer and they happened to get it wrong, how does that concern 
IBIS?

3. Your example supposes that some bad thing can happen if the model supplies 
some value such as 0 or -1, and you give dividing by zero as an example of such 
a bad thing. Almost every programmer knows how to avoid dividing by zero, and 
most decent programmers know to validate all of the assertions their 
computation is based on before they attempt the computation. (Any who don't 
should read Jon Bentley's classic book Programming Pearls.) Is it IBIS' 
responsibility to protect less competent programmers from themselves?

So far as I can tell, you've hypothesized a problem that doesn't actually exist 
when we have enough problems to solve which have come from real user projects.

Mike S.

On 12/15/2011 11:04 AM, Muranyi, Arpad wrote:
Mike,

Regarding "So far, you haven't provided a compelling description of one.",
I thought I did.  Would you please tell me what you
think of this example?  It may not be the best
example, but I hope it illustrates my thinking:

"If an EDA tool vendor decides to do what you say [opt to store the
<data> for internal data structure initialization] based on
their own really smart thinking, but the model's author
decides that this value in the .ami file is not going to
be useful for anything because the real value will come
from their model, and they put a bogus number, like 0 or -1
in the .ami file, you might end up getting divide by zero
errors or similar fun things if the nature of the parameter
might be such that it can't handle negative numbers or zero.
This is why I feel that the spec MUST say something about
what the number in the .ami file is used for, or say that
it should be ignored."

Thanks,

Arpad
=====================================================

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Thursday, December 15, 2011 8:52 AM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Usage Out syntax rules

Arpad-

I don't see that there's a problem to solve in the first place. So far, you 
haven't provided a compelling description of one.

Let's not confuse the parameter declaration with the parameter itself. All that 
a .ami file contains is parameter declarations with static initializations 
(that is, default values). The parameter itself is what's passed in or out of 
the model. Any of the statically initialized parameter values in the .ami file, 
including those of Usage Info, can be over-written by the model, the EDA tool 
or the user for whatever reason they choose. (You may disagree with any 
decision by an EDA tool or a user to over-write a parameter value, but that's 
none of our business.) They are an initial value and no more.

In the case of parameters of Usage Out, any initial value almost certainly will 
be over-written by the model itself. There's no question about where the value 
comes from. If the model outputs the parameter, as promised in the .ami file, 
then the parameter's initial value will be over-written, and can be ignored. If 
the model does not output the parameter even though it was declared in the .ami 
file, then that's an obvious error that the model developer should correct, and 
will correct if the users demand it.

Statically initialized variable declarations exist in many programming 
languages, most notably C. We're using these declarations in exactly the same 
way in IBIS-AMI as they are used in all the other programming languages. They 
don't have a problem and, as far as I can tell, neither do we.

Mike S.

On 12/14/2011 11:13 PM, Muranyi, Arpad wrote:
Bob,

Let's distinguish between two things in this discussion.

#1)  The technical solution that this BIRD draft proposes,
#2)  The question whether there is a problem in the existing
     spec and the existing BIRDs

For the first one, I am not saying that this is the
only way to solve the problem.  In fact, if you look
at the first message (on the bottom), you will see that
I was originally considering several approaches in the
form of questions.  I wrote the BIRD draft as it stands
based on one private feedback, which seems to be the
simplest approach.  But I am open for suggestions, and
I really don't care how we solve the problem, as long as
we solve it.

For the second one, we need to agree on whether there is
a problem or not.  Correct me if I am wrong, but as far as
I can tell, we have a logic conflict in the spec.  It's as
if we had two outputs driving one input without a selector.
One output is the Usage Out parameter in the .ami file
(providing a value for the EDA tool - but I am not even sure
to whom this value is provided) and the other output
is the model which is also sending a value to the EDA tool.
How do you propose to resolve this conflict without saying
anything about which one to use and under what conditions?
Currently the spec doesn't say anything about that.

In addition, if the purpose of these duplicate values is to
define an initial condition, how would an EDA vendor know
whether they should use the value in the .ami file to
initialize themselves, or the model?  Recall, the parameters
in the .ami file go to the tool if they are Info, or the model
if they are In, but where do they go from the .ami file if
they are Out?  We know if they are Out, they go from the model
to the tool, but where does the <data> supposed to go from the
.ami file?  This is simply not defined in the spec.  Maybe a
better circuit equivalent of this situation is a driver without
being connected to anything.  Why is it there then?  Some may
assume it is there for this reason, others may assume it is
there for another reason, and incompatibility and non-portability
will set in very quickly...

As I stated it before, I am open to suggestions, I don't
feel that we have to solve the problem the way this draft
proposes it, but I think we do need to something about it.
I don't even mind leaving the general syntax as is, but
then I will demand that each parameter that is defined as
Usage Out should spell out the rules on these questions,
so there would be no ambiguities left in the spec.  (This
would lead to a lot of repetition in the spec, though, so
I think we would be wiser to modify the general syntax).

Now, some specific answers to your email.

Regarding "It should NOT be confused or misread as a syntax statement
that <data> is optional for some <data_format> cases in an .ami file.", I
didn't make that suggestion in this BIRD draft.  (I did
consider it in the email on the bottom, but didn't put it
into the BIRD draft).

Regarding "In fact, an EDA tool might opt to store the <data> for internal
data structure initialization.", this is exactly the case in point.
If an EDA tool vendor decides to do what you say based on
their own really smart thinking, but the model's author
decides that this value in the .ami file is not going to
be useful for anything because the real value will come
from their model, and they put a bogus number, like 0 or -1
in the .ami file, you might end up getting divide by zero
errors or similar fun things if the nature of the parameter
might be such that it can't handle negative numbers or zero.
This is why I feel that the spec MUST say something about
what the number in the .ami file is used for, or say that
it should be ignored.

Regarding "Rule 7  adds a new restriction it is a syntactical violation
for Default to be used at all for Usage Out parameters.", why is this a
violation?  The rule with this new addition is that it is
not allowed for Usage Out parameters, and optional for all
others, and it is not allowed together with Value.  Prohibiting
Default in Usage Out Value doesn't conflict with anything,
it is prohibited for two reasons, one because it is Value,
and second because it is Usage Out.  I don't see any violations,
am I missing something?
Regarding "Also, since and optional Default overrides <typ> in some cases
and is used in place of Value for other parameters, nothing
is gained be adding the new syntax restriction.", consider this:

<typ> is part of <data>.  If <data> is ignored by my new rule,
<typ> is ignored too.  What is the interpretation of Default,
if it is allowed?  Is it supposed to be in effect, so that the
ignored <data> is substituted with its value?  If this was the
case, we would be back to square one, because the whole purpose
of this BIRD was to make <data> ineffective for Usage Out
parameters to remove the ambiguities they introduce.  If this
is what we want to achieve with this BIRD, shouldn't Default
also be either ignored, or prohibited?  I chose to prohibit it,
since we already have a prohibition with Value, and to me it is
cleaner to eliminate extra bogus data in the .ami file than allow
them to be there for no other reason than to be ignored.

Thanks,

Arpad
===================================================================

From: Bob Ross [mailto:bob@xxxxxxxxxxxxx]
Sent: Wednesday, December 14, 2011 8:27 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Usage Out syntax rules

All:

I already presented some objections to Arpad, and I see no
need for this BIRD.  I am not convinced of any technical need,
and more rules cost money in terms of more documentation,
more test cases and error codes and mistakes/delays in
developing a parser.

-----

Rule 10 should NOT be listed under Notes because it is
not a syntax rule.  It should be placed elsewhere.

The rule provides EDA tool guidance as to how to
handle <data> in the .ami file for a Usage Out parameter.
It should NOT be confused or misread as a syntax statement
that <data> is optional for some <data_format> cases in an
.ami file.

In fact, an EDA tool might opt to store the <data> for internal
data structure initialization.  So it is questionable to state
or require EDA tools to absolutely ignore <data>

------

Rule 7  adds a new restriction it is a syntactical violation
for Default to be used at all for Usage Out parameters.

For clarity, this must be stated as a separate rule to avoid
mixing a  set of <data_format> exceptions with Usage
exceptions.

Also, the full rule must also be added in one or more sections
such as where Default is given and perhaps where Out is
introduced.  The Notes are not the primary source for a rule,
but just a partial summary of restrictions noted explained
elsewhere.   Otherwise the documentation is internally
inconsistent - a problem for the parser developer.

Also, since and optional Default overrides <typ> in some cases
and is used in place of Value for other parameters, nothing
is gained be adding the new syntax restriction.

-------

So I do not see the value or need for this proposal.

Bob

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 14, 2011 3:40 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Usage Out syntax rules

Hello,

I took the initiative and wrote a new BIRD draft to
address the issues I brought up in the email below.
(See attached file).

The way this BIRD is written doesn't change any of
the .ami file syntax, i.e. Usage Out parameters are
still required to contain <data>, but the BIRD states
that this data is ignored.  The other new rule I added
was to prohibit Default when the Usage is Out, since
the <data> is coming from the model, and I don't see
why we should pay attention to Default in the .ami file
when <data> is ignored anyway.

Please take a few minutes to review it and send me
your questions, comments, suggestions if you have any.
I would hope that this simple BIRD would not take up
much of our time, and could be submitted to the Open
Forum in a short time.

Thanks,

Arpad
========================================================

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Muranyi, Arpad
Sent: Monday, December 12, 2011 5:38 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Usage Out syntax rules

All,

I looked at BIRD 127.4 again to see what the options
might be to say something about Usage Out parameters.
I double checked, and this text applies to all parameters,
Reserved and Model_Specific:

|*              All parameters must be in the following format:
|*
|*              (parameter_name (Usage <usage>)
|*                              (Type <data_type>)
|*                              ({Format} <data_format> <data>)
|*                              (Default <value>)
|*                              (Description <string>))

There is another rule that Default and Format Value can't
coexist in the same parameter.  All other Formats are
allowed to have Default.  We could possibly refine/revise
the notes below this syntax definition.  Here are the
relevant notes which could be considered:

|*              4) The <data_format> selection of Value and Default are
|*                 always mutually exclusive.  Certain parameters may require
|*                 Value or Default, but Value and Default are not allowed to
|*                  be present together for the same parameter.
|*              5) <data_format> is always required for selections other
|*                 than Value.
|*              6) Default is optional for <data_format> Range, List, Corner,
|*                 Increment and Steps.
|*              7) Default is not allowed for <data_format> Table, Gaussian,
|*                 Dual-Dirac and DjRj.

We should probably state that for Usage Out,

-   Default is not allowed

-   Format Value is not allowed

-   and <data> shall be omitted for all other <data_format>s.

Table poses an interesting exception.  According to BIRD 132,
tables of Usage Out are still required to contain a single row
of data, so that the tool would know how many columns are in a
row when it reads the flattened data coming from the model.

Questions, comments, suggestions are welcome.

Thanks,

Arpad
================================================================

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 12-2011