Arpad-I think your general direction is a useful one; however, there is one important misconception that needs to be corrected.
It is _not_ true that the tool could include the 'Reserved_Parameters' and 'Model_Specific' branch names in the parameter string passed to the model. That is not the branch structure the model is expecting, and so the model will gracefully ignore _the_ _entire_ _parameter_ _string_. I don't think that's what you want.
For example, if the model is expecting the parameter glorp->foo and what it gets is glorp->Model_Specific->foo, it will not recognize foo, and is not required to do so. This was the behavior of the very first example Tx model supplied by SiSoft in July 2007, and there are a lot of models in use today that still use this source code.
In particular, the tool could pass in the entire 'Reserved_Parameters' branch in the parameter string, the model would gracefully ignore the entire branch, and that would be OK.
If the tool were to pass in a parameter string that included the branch name 'Model_Specific' in the branch structure, the model would gracefully ignore the entire 'Model_Specific' branch, and that would _not_ be OK.
So, when the .ami file declares a parameter of type In, it is declaring that this is a parameter that the model is expecting to see in its input string.
When the .ami file declares a parameter of type Out, it is declaring/promising that the model's output parameter string will contain this parameter. This is certainly useful information to the model user, and can be of some use to the EDA tool. It would be prudent, however, for the EDA tool not to depend on this promise, or at least to complain if the promise is broken. It would also be nice if the EDA tool were to organize and report whatever it found in the parameter output string, declared or not.
We need to continually remind ourselves what IBIS-AMI is in the first place. It's an _interface_ _definition_. That means that if both the model and the EDA tool comply with the interface definition, they can communicate with each other correctly. Period, the end.
IBIS-AMI is not and should not be a specification of functionality, either for the model or the EDA tool. End users must define those requirements, possibly based on suggestions from individual companies. Thus, what the EDA tool actually does with the output parameter string is entirely outside the scope of IBIS.
Hope this helps. Mike S. On 12/13/2010 07:33 PM, Muranyi, Arpad wrote:
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 ==============================================================================