[ibis-macro] Re: About the Typos BIRD comments from Fangyi

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 14 Dec 2010 10:53:42 -0500 (EST)

Arpad,

 

Again this should be very simple.

 

If a parameter Usage is In or InOut, the EDA tool is expected to include
it in the parameters_in string.  The DLL should ignore anything that is
not an In or InOut.

 

If the parameter Usage is Out or InOut the DLL should include it in the
parameters_out string. The EDA tool should ignore anything that is not an
Out or InOut.

 

The DLL may report an error or use some internal default value if an In or
InOut is not included in the parameters_in string.

 

The EDA Tool may report an error or use some internal default value if an
Out or InOut is not included in the parameters_out string.

 

Walter

 

 

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, December 13, 2010 8:33 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

Radek, and Everyone,

 

I am trying to clean up the Typos BIRD draft and I have a

basic question about the parameter strings (in/out).  This

goes along the lines of comment d) from Radek below.

 

If we say that the AMI executable should gracefully ignore

everything that it doesn't need, we do not have to spell

out anything about what should not be included in the AMI

parameters in string.  The ONLY rule we need to mention is

that the AMI parameter branches are converted to leaf/value

pairs.  The tool could include the 'Reserved_parameters'

and/or 'Model_specific' branch names as well as Usage Info,

and Out, etc. in the parameter string, because they will

have to be ignored gracefully anyway, right?

 

The same question goes for the AMI_parameters_out string.

If we want to be consistent, we should also say that the

EDA tool should ignore anything in that string that is not

a Usage Out leaf/value pair.  Based on that the AMI executable

could return anything it wants to, including the entire

string that it received as the input.  I have seen models

which did that, and this was actually a nice feature for

debugging purposes, because it gave me a cozy feeling that

the model "understood" what I passed into it.  And if the

model makers are smart, they will return the correct spelling

of the input string in case it was passed into the model

incorrectly.

 

While this approach is useful, it raises the question, what

is really the meaning of Usage In, Out, as compared with the

meaning of parameters_in and parameters_out?  In the first

case In and Out refers to the direction the parameter is

supposed to be passed, but in the second, the meaning is

referring to the direction in which the parameter string

is traveling.  These two are not the same, and become

inconsistent if we disregard the Usage In/Out and include

both Usage In/Out in both strings.  This bothers my purist

thinking a little, even though I like its benefits, as I

described it above.

 

QUESTION:

 

What should we say in our AMI specification?  Should the

EDA tool pass a rigorously filtered string to the AMI

executable (including only Usage In/InOut), or should it

pass anything that is in the .ami file?

 

Similarly, should we say in the AMI specification that

the AMI executable is only allowed to pass back to the

EDA tool Usage Out parameters, or should we allow the

model to pass back anything it wants, including the

possibility to repeat back the entire AMI_parameters_in

string (with modifications for the Usage Out parameters)?

 

Thanks,

 

Arpad

============================================================

 

 

 

From: radek_biernacki@xxxxxxxxxxx [mailto:radek_biernacki@xxxxxxxxxxx] 
Sent: Monday, December 06, 2010 7:57 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

Hi Arpad,

 

Sorry for a delayed reply. I would suggest expanding the text to cover the
following issues:

 

(a)    description of how the "Reserved Parameters" and "Model Specific"
names are to be not included: if a name is not included does it mean that
the corresponding pair of parentheses is also removed (I think so - but we
need to say so). Perhaps we could define it as "branch collapsing"),

(b)   the opening sentence seems to cover both the "_in" and the "_out"
strings, yet in Item 3 the parameters of Usage Out are excluded; perhaps
we can cover each case separately,

(c)    we need to say whether all "In" and "InOut" parameters in the case
of the "_in" string, and all "InOut" and "Out" in the case of the "_out"
string shall be included, and whether the order shall be consistent with
the AMI file,

(d)   we need to say whether the DLL shall gracefully ignore any other
parameter whose name may or may even not be in the AMI file (if so, we do
not need to say that parameters other than (c) need to be omitted,

(e)   for Item 4 we need to define the process of making branches to
become leaves,

(f)     we need to precisely define Value (and Default) for parameters
whose format requires more than one number to constitute a value, or we
may coin another terms such as "composite value".

 

Radek

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, December 03, 2010 8:32 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

Hello AMI Experts,

 

This thread stopped a day or so ago without reaching a conclusion.

I am going to summarize the questions I would like to get answered.

 

 

1)  When does a branch become an "AMI parameter"?  Does this have

to be spelled out in the IBIS-ATM specification, or does this belong

to a Cookbook or HOWTO document?

 

Currently this is what I have in the Typos BIRD draft:

 

|*              A branch in the .ami file is an "AMI Parameter" if it

|*              contains the leaves Type, Usage, and any of the following

|*              leaves:

|*

|*                   Default

|*                   <data_format> or Format <data_format>

|*

|*              and does not contain another branch.  A branch which

|*              contains one or more sub-branches may only contain the

|*              Description <string> leaf/value pair in addition to the

|*              sub-branches.

 

 

2)  What is supposed to be passed into the AMI executable model in the

parameter string, and what is supposed to be omitted from this string?

Does this have to be spelled out in the IBIS-ATM specification, or does

this belong to a Cookbook or HOWTO document?

 

Currently this is what I have in the Typos BIRD draft:

 

**************************************************************************
******

REMOVE THIS PARAGRAPH if the next few are agreed
on:****************************

|*              The tree data structure passed in and out of the DLL

|*              described in section 3.1.2.6 of Section 10 of this
document

|*              is similar to the tree data structure in the .ami file
except

|*              the 'Reserved_Parameters' and 'Model_Specific' branch
names are

|*              not included, the "AMI Parameter" branches become leaves
and

|*              the "AMI parameters" of Usage Info and Out are not
included.

END OF REMOVED
PARAGRAPH********************************************************

**************************************************************************
******

|*

|*              The parameter string passed in and out of the DLL
(described in

|*              section 3.1.2.6 of Section 10 of this document) is
formatted

|*              the same way as the tree data structure in the .ami file
with

|*              the following exceptions:

|*

|*                1) The "Reserved_Parameters" and "Model_Specific" branch

|*                   names are not included

|*                2) None of the Description leaf/value pairs are included

|*                3) AMI Parameter branches or sub branches with Usage
Info

|*                   or Usage Out are omitted, but all other branches or
sub

|*                   branches are included

|*                4) AMI Parameter branches with Usage In or Usage InOut

|*                   become leaves

|*

 

 

3)      Define how/where the DLL returns Out or InOut parameters and

how/where the EDA tool is supposed to look for these values.  Does

this have to be spelled out in the IBIS-ATM specification, or does

this belong to a Cookbook or HOWTO document?

 

There is nothing on this topic in the Typos BIRD draft, nor can I

find anything about this in the current IBIS specification.

 

Thanks,

 

Arpad

==========================================================================
====

Other related posts:

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