Walter, (I changed the subject line so we know what this thread is all about). Thanks for your comment, I agree partially, but not completely. You say "...if it has one of the following leaves...", which doesn't make sense to me. We can't have Usage or Type alone. What did you refer to by "one of"? The bottom part of the list under "Allowed-Value Method" or the whole list? Even with considering the bottom part of the list, this interpretation is flawed because under certain circumstances Default and Value are mutually exclusive. On the other hand, I like the sentence "A branch that is an AMI parameter may not contain a branch." I think we should use that in the BIRD. How about if the Typos BIRD would say the following: |* 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. Note that I left out the word "only" Fangyi suggested, but added the words in red at the end. To address comment #3 from Fangyi, I added a few words to the end of the paragraph on the top of pg. 5 of the BIRD draft shown in red: |* 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' branches are |* not included, the "AMI Parameter" branches become leaves and |* the "AMI parameters" of Usage Info and Out are not included. This actually raises a few more questions in my mind, especially with the other email thread I started not too long ago about the AMI_parameters_out argument in mind. I can't find anything in the specification that describes how the DLL returns an Out or InOut parameters and how the EDA tool is supposed to look for them. Here are the possibilities that come to my mind. Let's start with an InOut example first to make my question easier to understand. The AMI_parameters_in argument is a pointer to a string, and the content of the string contains the InOut parameter name with a value. The DLL reads this value, and after some number crunching decides to return a different value. Where should this output value go? 1) The DLL could overwrite the string that it was given by the EDA tool in the same memory location. Recall, the argument is a pointer to the string, and it could be processed "in place", just as we do with the impulse matrix. 2) On the other hand, we have another argument for AMI_parameters_out. Is this where the DLL is supposed to put the output value it generated? If so, I would imagine that the DLL has to make a copy of the AMI_parameter (leaf value) string with the new value in the value location and put it in the memory location of AMI_parameters_out. 3) However, let's consider an example when the Init function contains an optimizer which takes initial values for the tap coefficients and after some number crunching returns better coefficients. I would think that in this case the tap coefficients will be declared as InOut arguments, and the initial values given to the Init function will be overwritten by the Init function when the optimizer is done. Now, how is this result propagated to the GetWave function? Notice that the GetWave function doesn't have an AMI_parameters_in argument. This makes me think that the AMI_parameters_in argument of the Init function is also visible to the GetWave function, and the modified tap coefficients from the Init function are passed to GetWave through the AMI_parameters_in memory location. This implies that the return value of an InOut argument should be returned in place (which is #1 above). Using this thinking we won't need the AMI_parameters_out argument for returning the values of InOut arguments. 4) Now let's put another twist to this story and consider an Out argument. Is the parameter string supposed to contain the name of the AMI parameter name and a place holder for the return value so that the Init function can modify this string in place when it outputs the value? Or, is the parameter string not supposed to include the name of the Out argument, and is the Init function supposed to modify this string in place and add that AMI parameter to it? Or, is the Init function supposed to use the AMI_parameters_out argument for returning Out parameters? 5) Studying the spec I also noticed that the AMI_parameters_out argument is optional for GetWave, but for Init we don't say that it is optional, so I assume it is required (correct me if I overlooked something). Shouldn't the AMI_parameters_out be consistently optional or required for both Init and GetWave? Depending on the answers above, if the output should be placed in the AMI_parameters_out argument, we can't say that it is optional, at least not if the input parameter string includes Out or InOut parameters. Sorry for the lengthy discussion here. I almost feel like I may not see the tree from the forest here, and if that is true, please correct my "observations" above. On the other hand, I the tree is indeed not visible in our "spec forest", I think we need to do a little more cleaning. Thanks, Arpad ======================================================================== == From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Wednesday, December 01, 2010 2:42 PM To: fangyi_rao@xxxxxxxxxxx; Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: IBIS-ATM teleconference - Agenda for 11/30/2010 My definition of a parameter is: A parameter tree contains a root, branches and leaves. A branch of the parameter tree is an AMI Parameter, if it has one of the following leaves. A branch that is an AMI parameter may not contain a branch. Usage Type Default Allowed-Value Method Value List Range Increment Corner Steps Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx Sent: Tuesday, November 30, 2010 2:53 PM To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: IBIS-ATM teleconference - Agenda for 11/30/2010 Hi, Arpad; I have following questions regarding the Typo BIRD. 1. On page 2, shall we merge the two modifications on line 140 into one? 2. At the bottom of page 4, shall we say "A branch in the .ami file is an "AMI Parameter" if it only contains the leaves Type, Usage, and any of the following leaves"? Shall we explicitly state that a branch having Usage and/or Type and a sub-branch is illegal? 3. The first paragraph on page 5 seems to suggest that parameters of Usage Info and Out are also passed into the DLL by the parameter string for AMI Init. Thanks, Fangyi