That's a good question. Since the paragraph after the one I previously
quoted says:
The executable model shall return a string to the EDA tool through the
AMI_parameters_out argument. This string shall contain all of the leaf
formatted Usage InOut and Usage Out AMI parameters if there are any defined
in the AMI parameter definition file.
I think that implies the EDA tool should complain (or is at least free to
complain) in the situation you described.
Thanks,
Curtis
On Tue, Nov 1, 2016 at 5:04 PM, Bob Miller (APD) <bob.miller@xxxxxxxxxxxx>
wrote:
want, right?The model maker can specify Usage InOut if that's the behavior they
Yes. That's what I did to patch the model. In my particular case it wasn't
the *value* passed in that the model wanted or cared about; it merely
used the presence of the parameter in the parameters_in string to decide
whether to present the parameter at all in the parameters_out string. So in
strict terms the usage is not really InOut. This patch had the side-effect
of allowing the user to select a value for the parameter, which was
summarily ignored by the model.
Interesting enough (and possibly an issue), the EDA tool used the Default
value for this Reserved Parameter (PAM4_UpperEyeOffset) when the model
failed to return a value. No warning, no error, just mystically incorrect
post-simulation analysis.
I later modified the model to remove this "auto-hide" feature, rendering
the conundrum moot.
Question: What should the EDA tool do (if anything) when a Usage Out
parameter defined in the .ami file is NOT returned by the model?
Regards,
Bob
On Tue, Nov 1, 2016 at 2:26 PM, Curtis Clark <curtis.clark@xxxxxxxxx>
wrote:
Walter is correct, here's the appropriate section (page 202 of IBIS 6.1):
The EDA tool shall pass a string to the executable model through the
AMI_parameters_in argument. This string shall contain all of the
leaf-formatted Usage In and Usage InOut AMI parameters if there are any
defined in the .ami file. No other information may be included in this
string. The string shall always include the root name of the parameter
tree, even if there are no parameters to pass to the algorithmic model.
Even without that explicit statement, I would consider it an error for
the EDA tool to put Usage out parameters in the AMI_parameters_in string.
The model maker can specify Usage InOut if that's the behavior they want,
right?
Thanks,
Curtis
On Tue, Nov 1, 2016 at 2:16 PM, Bob Miller <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
I agree with Walter. Been caught by this before (executable model subtly
expecting the EDA tool to pass Usage Out parameters into AMI_Init in the
parameter string). Some do, but more importantly, *some don't as there
is no requirement to do so. *I fixed my model rather than demand that
all EDA tools bow to me.
Regards,
Bob
On Tue, Nov 1, 2016 at 11:46 AM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
MM,
The following implies that Usage Out arguments are passed by the EDA
tool to the executable model file in the **AMI_Parameters_In string to
AMI_Init. I do not think that this is correct.
Unless otherwise noted, specific Usage Out arguments or data provided
as Format are effectively ignored and will be simply passed by the EDA tool
to the executable model file.
Walter
*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@free
lists.org] *On Behalf Of *Mirmak, Michael
*Sent:* Tuesday, November 1, 2016 1:37 PM
*To:* IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) <ibis-macro@xxxxxxxxxxxxx>
*Subject:* [ibis-macro] Draft Format and Usage Out Clarifications BIRD
As requested in a previous ATM meeting, please find enclosed a draft
BIRD, Format and Usage Out Clarifications.
Comments and questions are of course welcome and encouraged.
- MM
