[ibis-macro] Re: Yet another problem with Usage Out

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: James Zhou <james.zhou@xxxxxxxxxx>
  • Date: Fri, 16 Dec 2011 22:00:40 -0600

James-

You and I are pretty much in complete agreement. In particular, as long as the EDA tool can know how to form a correct input to the model and the model can know how to form a correct output to the EDA tool, then the specification has done its job. Nothing more is required.

Also, you are quite correct about reserved parameters. There is some information about a given model that the EDA tool needs in order to form a correct input to the model or interpret the output of the model correctly. That is, the information must directly affect the behavior of the EDA tool. This information is interpreted directly by the EDA tool and therefore must be expressed in a standard way. Also, this information concerns a specific model, and therefore must be expressed either by the model developer or the model itself. This is the role that reserved parameters play. Since the only role of reserved parameters is to convey specific information from the model developer or model to the EDA tool, the only Usages that make sense for a reserved parameter are Info (communication from the model developer to the EDA tool) or Out (communication directly from the model to the EDA tool).

Regarding model specific parameters with Format List, IBIS 5.0 defines that Format as selecting one value from a list of valid values. That's how the Format is defined, and the model developer depends on that definition in order to make sure that the user and EDA tool know how to form a correct input to the model. If the user or EDA tool were to assign their own interpretation to Format List, then the model developer would no longer be able to tell them that a valid input is one value from the list and not the entire list.

Bob Ross points out that BIRD 132 enables a model developer to describe an array-type value as a valid input to a model. I haven't been following IBIS-ATM very closely for quite a while, so I appreciate his bringing me up to date.

My point is that it is the model developer who defines the details required for a valid input to the model, in the context of the function signatures and syntaxes defined in IBIS 5.0.

I hope this helps.
Mike S.

On 12/16/2011 08:51 PM, James Zhou wrote:

Mike,

In IBIS 5.0, BIRD 127.4 and 123.x, I could not find any reserved parameters that are defined as Usage In or InOut, such as the table on page 148 of IBIS 5.0. Are you aware of any reserved parameters that are Usage In or InOut?

For model specific parameters, is it outside of the scope of the Specification to define their meaning and, how they should be processed by AMI_Init/GetWave or EDA tools (other than the fact that EDA tools must include them when constructing *AMI_parameters_in)?

To further illustrate this point, let's consider the example in your email: "When we have a parameter of Usage In and Format List, what do we send in to the model through ami_parameters_in? Do we send a single value or do we send the entire list? ". If this is a model specific parameter, would it only make sense to let the user making this decision? The EDA tool may also choose to make this decision based on its knowledge about a particular parameter in a particular model. In either of these cases, is it outside the scope of the Specification to make decisions about how to select values from model specific parameters? The only requirement that the Specification should impose upon EDA tools and AMI models (w.r.t. model specific parameters) is that, Usage In and Inout model specific parameters must be retrieved as is from .ami and passed to AMI_Init using *AMI_parameters_in, with the understanding that EDA tools may allow the user to select/manipulate them, before passing them to AMI_Init. However, it should be out of the scope of the Specification to regulate how they should be selected or manipulated.

Thanks,

James Zhou

*From:*ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Mike Steinberger
*Sent:* Friday, December 16, 2011 4:30 PM
*To:* Bob Ross
*Cc:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: Yet another problem with Usage Out

Bob-

Thanks for catching me up. This helps.

Mike S.

On 12/16/2011 05:43 PM, Bob Ross wrote:

Mike:

I do not know the answer in IBIS 5.0, but with BIRD132

http://www.eda.org/pub/ibis/birds/bird132.txt

the your line below could be specified in the .ami file as a

one-row Table:

Sent to Executable Model:

   (froboz(grue -1.3e9 0 -4.2e9 0))

-------

AMI  File:

(froboz

   (grue    (Usage In) (Type Float)

                (Table

                (Labels "number1" "number2" "number3" "number4")

                (-1.3e9 0 -4.2e9 0)

                )

  )

)

The Labels line is optional and is not transmitted.

The new Table syntax supports multi-line Tables and also

individual Type entries for each column, as shown in BIRD132

for all Usage choices.

We also support predefined two- and tree-valued Formats

(Gaussian, Dual-Dirac and DjRj), and the <data> for these

parameter would be two or three numbers according to the

proper definition of " leaf" in the Section 10 BNF as

(<parameter name> <value list>) as in your question.

Bob

*From:*ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Mike Steinberger
*Sent:* Friday, December 16, 2011 1:18 PM
*To:* ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
*Subject:* [ibis-macro] Re: Yet another problem with Usage Out

Arpad-

When we have a parameter of Usage In and Format List, what do we send in to the model through ami_parameters_in? Do we send a single value or do we send the entire list? We send in a single value selected from the list. There's no reason to suppose that a model sending a value back would do anything else. It will send back a single value from the list.

Consider, however, that currently we have no way to declare an array-type value in an AMI file. That makes the array value syntax we put into the parameter string definition considerably less useful. We have run into this problem a number of times in the work we've done; and the solution we came up with is not at all pretty.

For example, suppose I want the following parameter string sent into the model:

   (froboz(grue -1.3e9 0 -4.2e9 0))

According to IBIS 5.0, that's a valid parameter string syntax. The parameter grue has a value which is an array of floating point numbers.

What can I put in an AMI file that would tell the EDA tool to generate this parameter string?

Thanks.
Mike S.

On 12/16/2011 01:46 PM, Muranyi, Arpad wrote:

Hello everyone,
In the process of trying to make heads and tails
of this Usage Out discussion, I discovered another
interesting situation with the Usage Out parameters.
Let's assume that the .ami file contains this
perfectly legal parameter definition:
(MyExample
    (Description "Example")
    (Reserved_Parameters
       (MyRterm
          (Usage Out)
          (Type Integer)
          (List 100 80 90 110 120)
          (Default -1)
          (Description "Illustration")
       )
    )
)
What is the model supposed to return? A single
value or multiple values?  According to BIRD 127.4
the AMI_parameters_in/out strings can only contain
"leaf/value pairs", i.e. a single value for each
parameter name (or a Table according to BIRD 132).
|**** 2) the AMI Parameter branches Usage Out or Usage InOut are
|****               returned as leaf/value pairs in the AMI_parameters_out
|****               string.
If that is true, why would one define a Usage Out
parameter as anything else but Value, Default or Table?
If the purpose of defining a Usage Out parameter as
a List, for example, would be to tell the EDA tool
that the returned value from the Model is a List,
we are out of luck, since lists can't be passed
through the AMI_parameters_out strings.
It seems to me that we have another conflict here.
To remove this conflict we should not allow anything
else but Value, Default, or Table for Usage Out
parameters, or figure out a way to pass more than
just "leaf/value pairs" through the parameter string.
Comments, questions, suggestions welcome. Thanks, Arpad
======================================================
---------------------------------------------------------------------
IBIS Macro website  :http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
   To:ibis-macro-request@xxxxxxxxxxxxx  
<mailto:ibis-macro-request@xxxxxxxxxxxxx>
   Subject: unsubscribe
------------------------------------------------------------------------
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

Other related posts: