[ibis-macro] Re: AMI Parameter String question
- From: <fangyi_rao@xxxxxxxxxxx>
- To: <wkatz@xxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 10 Dec 2009 12:35:39 -0700
Hi, Walter;
In the new proposed BIRD some reserved parameters can have Usage In. Does it
mean these parameters not only control EDA tool but also configure model?
Thanks,
Fangyi
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Thursday, December 10, 2009 4:06 AM
To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: AMI Parameter String question
Arpad,
What Mike said was the ideal when we first created AMI, and I think it is an
ideal that we should strive for. In this ideal, Model_Specific parameters
should be used to configure the model, and return any configuration changes
that the model makes. These should generally be In, InOut and Out
parameters. Parameters that need to control how the EDA tool operates should
be Reserved_Parameters. You may recall that I wanted to introduce the
concept of Publishing parameters, so that IC Vendors could release models
with Info parameters that would eventually migrate to the Reserved Parameter
section. The IBIS ATM committee rejected this concept, so SiSoft has had no
other choice but to make them Model_Specific parameters, give notice to the
other EDA companies that such parameters are required (e.g. Tstonefile), and
propose them as Reserved Parameters to the committee. One specific example
of this is the fundamental limitation of IBIS to handle broadband IO buffer
models, which are required by high speed SerDes. This gets even more
complicated when the IO Buffer us a function of the selected configuration
if the AMI model. There are more than three corners in this world. This is
one of the reasons for introducing a standard way of implementing what IBM
and we are calling a conditional processor.
SiSoft is committed to building and supporting models to the IBIS/AMI
standard. When IBIS/AMI cannot support the IC Vendors requirements, then we
carefully document model specific Info parameters, and we commit to our IC
Vendors that we will propose enhancements to the IBIS/AMI standard
appropriately. We release IBIS models with |SiSoft parameters, and AMI
models with Model Specific Info parameters, and AMI models with our own
conditional processor. We very much to make these Model_Specific Info
parameters Reserved Parameters, and we want to standardize on a conditional
processor. We have several ideas in this area, but this is one case where we
will need other EDA vendors to contribute.
Fangyi asked a pertinent question several moths ago, what do I do with a
Model Specific parameter that is an out. The answer then was "Display It".
I have rambled a bit, and digressed from you original question. The EDA tool
already knows what the Reserved Parameters are so the name of the Reserved
Parameters is sufficient, and though general true that Reserved Parameters
are Info, and Model Specific Parameters are In, InOut and Out, these are not
rules specified in the current standard and is already violated in the
current standard.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Wednesday, December 09, 2009 8:10 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI Parameter String question
Mike, Walter,
So if the EDA tool uses this rule to formulate the
parameter string for the DLL:
"2. The .ami declares two classes of parameters: parameters intended for
use by the EDA platform and parameters for use by the model. The
parameters for the EDA platform go in the Reserved_Parameters branch of
the .ami file and the parameters for the model go in the Model_Specific
branch."
and we are now proposing to get rid of (or ignore) these
two keywords (branches), how will the EDA tool know which
parameter is supposed to be used for it own use or for
creating the parameter string for the DLL?
Thanks,
Arpad
==========================================================
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Wednesday, December 09, 2009 3:34 PM
To: Muranyi, Arpad
Cc: IBIS-ATM
Subject: Re: [ibis-macro] AMI Parameter String question
Arpad-
I agree with Ambrish's answer.
Perhaps we should re-read the IBIS spec to make sure it states these
points clearly, but here's how it goes:
1. The name of the root of the parameter tree is the name of the root of
the parameter tree which is to be passed into the model.
2. The .ami declares two classes of parameters: parameters intended for
use by the EDA platform and parameters for use by the model. The
parameters for the EDA platform go in the Reserved_Parameters branch of
the .ami file and the parameters for the model go in the Model_Specific
branch.
3. There is a BRANCH in the .ami file for every PARAMETER in the
parameter string sent to the model. The EDA platform has to have some
mechanism for producing or obtaining a parameter VALUE for each
parameter in the parameter string sent to the model. Each such parameter
value must be consistent with the information in the corresponding
branch in the .ami file.
4. It should not be necessary for every parameter declared in the .ami
file to appear in the parameter string for the model. Rather, the model
should have built in default values that will use when a parameter is
missing in the parameter string.
5. The model should silently ignore any parameter or branch it doesn't
recognize. As extra-good software craftsmanship, it would be nice if the
model echoed back through the msg interface the number of parameters it
did recognize.
Almost all of these points are reflected in Ambrish's example.
Hope this helps.
Mike S.
Muranyi, Arpad wrote:
> Hello everyone,
>
> At the expense of sounding like a broken record, I would
> like to ask the question (again) about how the EDA tool
> supposed to formulate the parameter string that is passed
> into the AMI DLL from the .ami file that is provided by
> the model maker with the DLL. Let's take the example from
> the IBIS 5.0 spec:
>
>
|=======================================================================
> ======
> | Example of Parameter File
>
|=======================================================================
> ======
> (mySampleAMI | Name given to the Parameter
> file
> (Description "Sample AMI File")
> (Reserved_Parameters | Required heading
>
> (Ignore_Bits (Usage Info) (Type Integer) (Default 21)
> (Description "Ignore 21 Bits"))
> (Max_Init_Aggressors (Usage Info) (Type Integer)(Default 25))
> (Init_Returns_Impulse (Usage Info) (Type Boolean)(Default True))
> (GetWave_Exists (Usage Info) (Type Boolean) (Default True))
> ) | End Reserved_Parameters
>
> (Model_Specific | Required heading
> (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
> (tx_freq_offset (Format Range 1 0 150) (Type UI) (Default 0))
> ) | End Model_Specific
> ) | End SampleAMI
> |
>
|=======================================================================
> ======
>
> If, for example, I want to formulate a simple parameter string for a
DLL
> that uses nothing else but the tap coefficient parameters, what would
> that
> parameter sting look like (taking the defaults from above)?
>
> (mySampleAMI
> (Description "Sample AMI File")
> (Model_Specific
> (txtaps
> (-2 0.1)
> (-1 0.2)
> (0 1)
> (1 0.2)
> (2 0.1)
> )
> )
> )
>
>
> or would it be ONLY:
>
> (txtaps
> (-2 0.1)
> (-1 0.2)
> (0 1)
> (1 0.2)
> (2 0.1)
> )
>
>
> Or anything else?
>
> 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
Other related posts:
