[ibis-macro] Re: After reviewing the IBIS AMI BIRDs we have identified a problem with BIRD 127 ...

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 19 Jan 2012 00:33:37 +0000

Walter,

Couldn't this echoing be done using
the AMI_Init "msg" argument?  After
all this is only for the user's
debugging pleasures, not for the
EDA tool's usage...

Thanks,

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

From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Walter Katz
Sent: Wednesday, January 18, 2012 5:54 PM
To: IBIS-ATM
Subject: [ibis-macro] After reviewing the IBIS AMI BIRDs we have identified a 
problem with BIRD 127 ...

All,

After reviewing the IBIS AMI BIRDs we have identified a problem with the 
following in BIRD 127 ...

|*              The AMI executable model must return a string to the EDA tool
|**             through the AMI_parameters_out argument.  This string must
|**             contain all of the leaf/value pair formatted Usage InOut and
|**             Usage Out AMI parameters if there are any defined in the
|**             .ami file.  No other information may be included in this
|**             string.  The string must always include the root name of
|**             the parameter tree, even if there are no parameters to return
|**             to the EDA tool.

In the AMI DLLs that SiSoft has written we return the values of In parameters 
in the AMI_parameters_out argument. We put these values in a spreadsheet that 
is available to the user. The key point is that if a User questions the results 
they're getting, and they want to make sure the model configured itself as 
expected, they will want the model to echo back to them the configuration it 
actually assumed. I plan on submitting a BIRD to change the above to remove "no 
other information may be included in this string."

Some supporting comments:


1.  One of the reasons for the LISP style parenthetical data format is that any 
part of the data can easily be ignored. Parsers are expected to look for what 
they need in it, nor figure out what to do with every item as with some 
formats. If extra content is not a problem there is no need to restrict content.

2.  No one has complained about the models that we have created that return 
(Usage In) parameters in the AMI_parameters_out argument. Since EDA tools must 
already deal with this I see no reason that this change should cause a problem.

Please plan that we will be submitting a BIRD to address this change.

Walter


Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 720.333-1107

Other related posts: