[ibis-macro] Questions on AMI_parameters
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 2 Jul 2009 17:29:42 -0700
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
Other related posts:
