[ibis-macro] Re: Usage Out syntax rules

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 15 Dec 2011 08:51:47 -0600

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
*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: