[ibis-macro] Re: Questions on AMI_parameters
- From: "Ambrish Varma" <ambrishv@xxxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>
- Date: Tue, 7 Jul 2009 01:12:49 -0400
Hi Arpad,
The specification lays out the suggested way to represent the taps with
the leaves -2, -1, 0 1 and 2 of the txtaps branch as indicated in the
.ami extract and as Mike points out. So there is no doubt where
(txtaps (-2 0.2) (-1 -0.4) (0 2) (1 -0.4) (2 0.2))
comes from.
The answer to your question about the representation of the taps as
(txtaps 0.2 -0.4 2 -0.4 0.2) could lie in the fact that these models
from the multi-billion dollar company existed way before the
specification did and it might be a simple oversight on the part of the
model maker in order to make these model a 100% IBIS compatible.
Besides, if they were a loose variation of the table format - they
should be
(txtaps (0.2 -0.4 2 -0.4 0.2)).
Thanks,
Ambrish.
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Monday, July 06, 2009 10:07 PM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: IBIS-ATM
Subject: [ibis-macro] Re: Questions on AMI_parameters
Arpad-
Both formats you refer to are legal, but only one of them matches the
definition given in the associated .ami file. The section of .ami file
and associated segment of parameter string came from a somewhat smaller
company than the one you allude to, and in fact we couldn't quite get
the .ami file format, as defined in the standard to quite match the
larger company's construction.
In particular, in the parameter string segment (txtaps (-2 0.2) (-1
-0.4) (0 2) (1 -0.4) (2 0.2)), "txtaps" is a branch of the parameter
tree that has leaves named "-1", "0", "1", and "2". These leaves are all
of format type "Tap" and they follow the rules we all agreed to.
Furthermore, this is exactly what the associated .ami file segment says.
The parameter string segment (txtaps 0.2 -0.4 2 -0.4 0.2) is a single
leaf named "txtaps" whose value is an array of floating point numbers.
This is a perfectly valid parameter string, albeit one with a very
different structure from the one above. In point of fact, however, we
had a hard time describing the array-type value in the .ami file. The
best we could come up with at the time was some distortion of the Table
format. This is one of a large number of holes we need to patch in the
standard.
Hope this helps.
Mike S.
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
---------------------------------------------------------------------
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
Other related posts:
