Todd,
Thanks for your reply too. This email and
my last one
seemed to have crossed in ether, so you
actually answered
some of my questions as I was writing
them... However,
my main questions are still wide open, so
here is my reply
to your message.
1) I think you are incorrect in saying that
"-2,
-1, 0, 1 and 2 are all parameters" because as far as I can tell
from section "6c, bottom of pg. 149 ",
these are parameter
names:
| which is their tap number
(i.e., "-1" is the name of the
| first precursor tap, "0" is the name of the main tap, "1" is
| the name of the first postcursor tap, etc.) and the tap
| weights are declared to be of type Tap, then the EDA platform
2) I looked at section 3.1.2.6 (again) and I don't see any
rules spelled out here for the transformation from the .ami
file to the DLL parameter string. All I see here is rules
for what that DLL parameter string format should look like,
basically the tree/leaf format. But the content of the .ami
file follows the same tree/leaf rules, so this is not giving
me any information on how one translates into the other.
3) The two examples of this section could be somewhat better.
The first one includes words like "(spacing sync)" which I
have no clue what it refers to, the second one actually
indicates that the format from our favorite multi-billion
dollar company is perfectly legal:
"(leaf5 value5 value6 value7)"
What seems to be missing to me is the link between this format
and the .ami file's tree/leaf format.
4) Even the bottom of pg. 149 is only an explanation for the
format that goes into the .ami file, but there is no mention
there that this should be translated to something else for
the DLL's parameter string. I simply cannot find any mention
of the need to translate the content of the .ami file for the
DLL, consequently I can't find any rules about it either. Am
I missing something?
Thanks,
Arpad
==============================================================
Arpad,
I think you want to look at the IBIS 5.0 spec, Section 10, Item
3.1.2.6. In the BNF definition, it says:
| <leaf>:
| ( <parameter name> whitespace <value list> )
-2, -1, 0, 1 and 2 are all parameters of the branch called txtaps, I
believe, and thus are expressed as originally stated:
(txtaps (-2 0.2) (-1 -0.4) (0 2) (1 -0.4) (2 0.2))
Remember that the simulator knows that each parameter is of type Tap
and is expressed as a single value from a Range (from the .AMI file)
... thus, each parameter is expressed as a single floating point number
in the string sent to the .dll.
If the conclusion here is that the sample .AMI file section in Section
6c should more closely correspond to the .dll string shown in Section
10/3.1.2.6, to make the flow of parameters easier to follow ... I think
we'd agree with you!
This is one more of those things that we've learned from living with
the spec, where we have room for clarification.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
Muranyi, Arpad wrote:
Thanks for all the responses to attempt to answer my question.
I understand that the values I put into the string were all
defaults and the tool can (and should) change them to values
which are within the range as described in the original string
in the .ami file. I have no questions or problems with that.
However, I still don't understand where the rules come from
that this:
(txtaps
(-2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default 0.1)
(Description "Second Precursor Tap"))
(-1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default 0.2)
(Description "First Precursor Tap"))
(0 (Usage Inout)(Type Tap) (Format Range 1 -1 2)(Default 1)
(Description "Main Tap"))
(1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default2 0.2)
(Description "First Post cursor Tap"))
(2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default 0.1)
(Description "Second Post cursor Tap"))
) | End txtaps
supposed to be turned into this:
(txtaps (-2 0.2) (-1 -0.4) (0 2) (1 -0.4) (2 0.2))
and NOT this:
(txtaps 0.2 -0.4 2 -0.4 0.2)
(or anything else) for the DLL's parameter string. By the way, it just
so happens that the DLL-s of a multi-billion dollar company uses the
latter form in the parameter string for the tap coefficients. Todd,
Ambrish and Kumar you know who I am referring to because you have also
worked with them in the past (but that is besides the point now). If
both of these formats are correct, we have a problem with the AMI
specification because, as I said it earlier, the EDA tool would have
to deal with each DLL on a customized bases, which is clearly what the
AMI spec was trying to avoid.
On the other hand, if only one or the other format is legal in the
above examples, I want to know which one and why. Where are the rules
spelled out in the AMI specification that tells us how to do it right?
After all, if this company's DLL-s (which may have been developed with
the help of the experts formulating the AMI specification) are using
the incorrect parameter string format, we seem to have a problem...
Thanks,
Arpad
========================================================================
-----Original Message-----
From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
Sent: Friday, July 03, 2009 8:06 AM
To: ambrishv@xxxxxxxxxxx
Cc: Muranyi, Arpad; IBIS-ATM
Subject: Re: [ibis-macro] Re: Questions on AMI_parameters
Ambrish,
A minor point, but the string
(txtaps (-2 0.1) (-1 0.2) (0 1) (1 0.2) (2 0.1))
defines the string that would be passed to the model using the default
conditions described in the .ami file. As Kumar points out, one of the
purposes of the .ami file is to define which values are legal. Thus,
the string
(txtaps (-2 0.2) (-1 -0.4) (0 2) (1 -0.4) (2 0.2))
is just as legal, given the example .ami code provided:
(txtaps
(-2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default 0.1)
(Description "Second Precursor Tap"))
(-1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default 0.2)
(Description "First Precursor Tap"))
(0 (Usage Inout)(Type Tap) (Format Range 1 -1 2)(Default 1)
(Description "Main Tap"))
(1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default2 0.2)
(Description "First Post cursor Tap"))
(2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default 0.1)
(Description "Second Post cursor Tap"))
) | End txtaps
The method by which the EDA platform combines the information in the
.ami file and user input to derive the text string delivered to the
model is not defined by the spec ... and in fact, doesn't matter. The
only requirement is that the final string delivered to the model is in
the syntax you've indicated, and contains legal parameters and values as
defined in the .ami file.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
Ambrish Varma wrote:
Hi Arpad,
The parameter file (.ami) is supposed to be provided by the dll (model)
writer. As such, the parameters are going to be in a format that the
model would accept. In the example that is on page 150,
(txtaps (-2 0.1) (-1 0.2) (0 1) (1 0.2) (2 0.1))
would be the correct (and only) choice (format wise) to give back to the
model.
As far as the values that are going to be passed back to the model, the
EDA tool, with the help of the model user, will have to decide what
values (within the range provided by the model writer) will be passed
back to the model. The defaults can be used as a starting point as those
values are provided by the model writer and therefore are known to work.
Thanks,
Ambrish.
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, July 02, 2009 8:30 PM
To: IBIS-ATM
Subject: [ibis-macro] Questions on AMI_parameters
Hello everyone,
I would like to continue the discussion we started in last Tuesday's
ATM meeting related to the subject of the AMI_parameter string argument
that is passed into the DLL.
I took a little time to re-read the AMI portions of the IBIS v5.0
specification and I am still not getting the picture. On pg. 143 of
the PDF formatted version of the specification I see the following:
| The Parameter_File entry provides the name of the parameter
| file with an extension of .ami. This must be an external
| file and should reside in the same directory as the .ibs file
| and the shared object library file. It will consist of
| reserved and model specific (user defined) parameters for use
| by the EDA tool and for passing parameter values to the model.
Later on, on pg. 186 I see the following:
| 3.1.2.6 AMI_parameters (_in and _out)
| =====================================
|
| Memory for AMI_parameters_in is allocated and de-allocated by the EDA
| platform. The memory pointed to by AMI_parameters_out is allocated
and
| de-allocated by the model. This is a pointer to a string. All the
input
| from the IBIS AMI parameter file are passed using a string that been
| formatted as a parameter tree.
These two sections lead me to believe that the ***entire content***
of the .ami file was passed into the DLL through the parameter string
and the DLL was responsible to parse and extract the necessary
information
from that string.
Walter's comments in our last ATM meeting indicated that this was not
the case, and that the DLL was supposed to get a subset of the .ami
file's content in the parameter string. Further down on pg. 143 I
see some hints towards this in the examples and in the verbal and BNF
syntax rules for this string, but I still don't see hard and fast
rules on how the content of the .ami file gets reduced into something
that can be passed into the DLL.
If there are no rules on that, the EDA tool may formulate this subset
one way, while the DLL's author may formulate the expected subset in a
different way. Without such rules the DLL interface essentially becomes
undefined, and each DLL will have to be dealt with in a unique or custom
way. I thought that the purpose of the AMI specification was to prevent
exactly this situation. Let me illustrate this with one of the examples
from the specification.
There is an example on pg. 150 for how the Tx taps can be written up
in an .ami file:
(txtaps
(-2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default
0.1)
(Description "Second Precursor Tap"))
(-1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default
0.2)
(Description "First Precursor Tap"))
(0 (Usage Inout)(Type Tap) (Format Range 1 -1 2)(Default 1)
(Description "Main Tap"))
(1 (Usage Inout)(Type Tap) (Format Range 0.2 -0.4 0.4)(Default2
0.2)
(Description "First Post cursor Tap"))
(2 (Usage Inout)(Type Tap) (Format Range 0.1 -0.1 0.2)(Default
0.1)
(Description "Second Post cursor Tap"))
) | End txtaps
I agree that this cannot be passed into the DLL as it is, because in
this syntax there is nothing that tells the DLL what actual values
it should use for a given simulation (unless we make use of the
default values for that purpose, which is a little awkward). But
how is this format supposed to be translated for the DLL's parameter
string? I can see several ways:
(txtaps (-2 0.1) (-1 0.2) (0 1) (1 0.2) (2 0.1))
or
(txtaps 0.1 0.2 1 0.2 0.1)
or
(txtaps_2 0.1)
(txtaps_1 0.2)
(txtaps0 1)
(txtaps1 0.2)
(txtaps2 0.1)
etc...
(We should have a competition on how many different ways this
could be done :-) ). Please correct me if I am wrong on any of
this, I am willing to learn, but currently this is the way I
understand what we have in the specification.
Thanks,
Arpad
===================================================================
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
