Fangyi,
Thanks for the example, this answers my question, and your
suggestion below makes sense to me now. I agree with your
suggestion and changed the proposed text in red below to
incorporate it 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.
This, however, raises another question in my mind about the next
paragraph:
|* 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
leavesand
|* the "AMI parameters" of Usage Info and Out are not
included.
According to this, a normal branch would translate from this example:
(Model_Specific
(Tx_Strength (Usage In)(Format List 0 1 2 3 4 5 6 7)(Type
Integer)(Default 0)(Description "Differential Swing")
(Label "000: 1100mV" "001: 1050mV" "010: 1000mV" "011: 900mV"
"100: 800mV" "101: 600mV" "110: 400mV" "111: 0mV"))
(Tx_Equalization (Usage In)(Format List 0 1 2 3 4 5 6 7)(Type
Integer)(Default 0)(Description "Pre-Emphasis")
(Label "000: 0%" "001: 3%" "010: 4%" "011: 10.5%"
"100: 18.5%" "101: 28%" "110: 39%" "111: 52%"))
(Process (Corner 0 -1 1)(Usage In)(Type Integer)(Default
0)(Description "Process Corner")
(Label "0: tt" "-1: ss" "1: ff"))
) | End Model_Specific
To the following parameter string (to be passed into the DLL):
(AMI_RootName (Tx_Strength 0)(Tx_Equalization 0)(Process 0))
Based on the above text, I am not sure we have enough information
to translate your example to a parameter string. What would this
look like in the parameter string?:
(Model_Specific
(ffe (Description "FFE taps")
(-1 (Usage In) (Type Float) (Value 0.0) (Description "precursor"))
(0 (Usage In) (Type Float) (Value 1.0) (Description "main cursor"))
(1 (Usage In) (Type Float) (Value 0.0) (Description "post-cursor"))
)
)
(AMI_RootName (ffe (-1 0.0)(0 1.0)(1 0.0) ) )
or would it only be
(AMI_RootName (-1 0.0)(0 1.0)(1 0.0) )
This second translation will have problems if two branches contain
identical AMI parameter names, because they will become indistinguishable
and repeated in the parameter string.
The other thing I don't like in the wording of the text in this
paragraph is that words: "the 'Reserved_Parameters' and 'Model_Specific'
branches are not included," sound like that the entire branches are
eliminated, when it actually refers to the "Reserved_Parameter" and
"Model_Specific" branch names only and not the rest that is in those
branches.
So I would revise this paragraph to this (change 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' branch
names are
|* not included, the "AMI Parameter" branches become
leaves and
|* the "AMI parameters" of Usage Info and Out are not
included.
I still need to find a good way to describe what should be done
with the sub branch example you showed me. Do you have any
suggestions?
Thanks,
Arpad
=================================================================
*From:*fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
*Sent:* Thursday, December 02, 2010 12:25 AM
*To:* Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
*Subject:* RE: About the Typos BIRD comments from Fangyi
Hi, Arpad;
An example would be FFE taps.
(ffe (Description "FFE taps")
(-1 (Usage In) (Type Float) (Value 0.0) (Description "precursor"))
(0 (Usage In) (Type Float) (Value 1.0) (Description "main cursor"))
(1 (Usage In) (Type Float) (Value 0.0) (Description "post-cursor"))
)
Here "ffe" is a branch with sub-branches "-1", "0" and "1". Each of
the sub-branches is an "AMI Parameter".
Does this answer your question?
Fangyi
*From:*ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Muranyi, Arpad
*Sent:* Wednesday, December 01, 2010 10:16 PM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] Re: About the Typos BIRD comments from Fangyi
Fangyi,
I am trying to understand when we can have a branch with a
sub-branch. So far I could only find the Reserved_Parameters
and Model_Specific keywords as branch starters. Well, there
is Table, but I will ignore that for the time being. What
else can start a sub-branch?
I need to understand that before I can attempt to understand
and respond to your suggestion.
Could you please give me some hints here?
Thanks,
Arpad
===============================================================
*From:*fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
*Sent:* Wednesday, December 01, 2010 9:13 PM
*To:* Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
*Subject:* RE: About the Typos BIRD comments from Fangyi
Hi, Arpad and Walter;
Thanks for the clarification. Based on your emails there are two types
of branches.
1.A branch with sub-branch can only have leave of "Description"
2.A branch without sub-branch mush have leaves of Usage, Type, ....
and such a branch is an "AMI Parameter".
If this is correct you might want to add the first statement to the
BIRD to make it clear.
Regards,
Fangyi
*From:*ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Muranyi, Arpad
*Sent:* Wednesday, December 01, 2010 4:48 PM
*To:* ibis-macro@xxxxxxxxxxxxx
*Subject:* [ibis-macro] About the Typos BIRD comments from Fangyi
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. A branch which
|* contains one or more sub-branches may only contain the
|* Description <string> leaf/value pair in addition to the
|* sub-branches.
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
leavesand
|* 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
