[ibis-macro] Re: Comments on BIRD 145 AMI_Resolve Dependency BIRD
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 4 Sep 2013 08:36:31 -0400 (EDT)
Arpad,
In IBIS 5.0, 5.1 and 6.0 an .ami file is specifically linked to a DLL and
a [Model]. BIRD 160 allows both parameters and converter parameters in an
[External Model] to be defined in a parameter tree file (not limited to a
.ami file) that are Usage In or Info.
There is no meaning of a .ami file, except in the context of an
association with a DLL and a [Model]. BIRD 155 goes a step further in
linking a .ami file to a DLL to resolve the value of dependent parameters.
As BIRD 155 is currently written, the input to AMI_Resolve and AMI_Init
are all Usage In, Usage InOut ami parameters, and the output is all Usage
Dep parameters. This requires that BIRD 160 be modified (in IBIS 7.0) to
allow parameters and converter parameters to be Usage In, Info and Dep.
If BIRD 155 was modified to add a new (Dependency_Usage In|Out) leaf, then
the input to AMI_Resolve are all Dependency_Usage In parameters and the
output of AMI_Resolve are all Dependency_Usage Out parameters and the
inputs and outputs of AMI_Init remain the same as in IBIS 6.0. No change
is required BIRD 160 in IBIS 7.0.
The issue you raise regarding using [External Model] parameters and
converter parameters referencing an .ami file that has (Usage Dep) or
(Dependency_Usage In|Out) parameters when that .ami file (and an
associated DLL) is not specified in the same [Model]. I do agree that with
(Usage Dep) BIRD 160 needs some words that require a linkage of the .ami
and DLL within the same [Model] (my head spins when considering what words
to use for such parameters in [External Circuit] which has no such
association with a [Model]. I point out that if BIRD 155 was modified to
use Dependency_Usage, and if a BIRD 160 parameter or converter parameter
referenced an .ami parameter that was Dependency_Uage Out, and there was
no association of this .ami file with a DLL in the [Model] or [External
Circuit] then the EDA tool would not have access to the DLL to resolve
these parameters, and would therefore need to rely on the fact that the
parameters are Usage In or Info, and the user/EDA tool would need to
select the values of these parameters from the allowed values specified
for them.
In summary:
1. With (Usage Dep) BIRD 160 language needs to be modified to allow
parameters and converter parameters to reference .ami parameters that are
Usage In, Info and Dep, and require the .ami file and DLL be defined in
the [Model].
2. With (Dependency_Usage In|Out) one could add the following to the
BIRD 160 language:
a. If a parameters or converter parameters reference .ami parameters
that is (Dependency_Usage Out), and the .ami file is not associated with a
DLL in the [Model], then the User/EDA tool shall select a value for that
parameter based on the allowed values for that parameter in its format.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, September 04, 2013 2:59 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Comments on BIRD 145 AMI_Resolve Dependency BIRD
Walter,
This is supposed to be comments on BIRD 155 (not BIRD 145),
correct?
Regarding: "We have spent about 50 man hours on this, and how using
(Usage Dep) affects other BIRDS (e.g. BIRD 160 is still not resolved),"
as far as I can tell, the questions we are discussing in BIRD 155
related to BIRD 160 would still be the same regardless whether we
had "Usage Dep", or "Dependency_Usage Out". So I don't see how we
would have saved that many man hours by calling it a different name.
Thanks,
Arpad
=====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Saturday, August 31, 2013 8:58 AM
To: IBIS-ATM
Subject: [ibis-macro] Comments on BIRD 145 AMI_Resolve Dependency BIRD
All,
Comments on BIRD 145 AMI_Resolve Dependency BIRD
On June 25, I sent out the following to this reflector:
I strongly suggest that we have a new parameter leaf "Dependency_Usage"
that determines what the inputs and outputs of the AMI_Resolve function.
The following describes the "Dependency_Usage" leaf.
1. A new optional leaf for all parameters "Dependency_Usage", which
can have the values "In" or "Out". If "In" then the parameter is an
independent parameter. If "Out" then the parameter is a dependent
parameter.
a. Usage and Dependency_Usage are independent, except Usage Out
cannot also have Dependency_Usage.
b. Any parameter (Reserved or Model Specific) parameter can have
Dependency_Usage "In" (except if Usage Out) .
c. Any parameter (Reserved or Model Specific) parameter can have
Dependency_Usage "Out" (except if Usage Out) . In addition, the following
parameters cannot have Dependency_Usage "Out".
i. The following Reserved Parameters
1. DLL configuration Info parameters
a. GetWave_Exists
b. Init_Returns_Impulse
c. Max_number_of_agressors
d. AMI_Version
e. Supporting_Files
f. ResolveDependentParam_Exists
2. Parameters filled in by EDA tool
a. DLL_Path
b. DLL_id
June 25 Minutes
- Walter: The model user first has to make various parameter value
selections.
- Input to Resolve function is "Info".
- Output of Resolve is classic "Info" parameters.
- We need to know which are "Dep-In" and which are "Dep-Out". Which are
which?
- Overloading Usage with "Dep" is a confusing way to handle it.
July 2 Minutes
- Walter: I propose a Dependency_Usage leaf with values In or Out.
- Walter: In BIRD 160 we have a parameter passed in, nothing says it can't
be Usage Out.
- All an EDA tool can do with Model_Specific Out parameters is report
their values.
The ATM group decided to go with (Usage Dep) instead of (Dependency
In|Out). My statement on June 25 "Overloading Usage with "Dep" is a
confusing way to handle it." Has been born out based on extensive
discussions in the last 9 IBIS - ATM meetings. We have spent about 50 man
hours on this, and how using (Usage Dep) affects other BIRDS (e.g. BIRD
160 is still not resolved),
On June 25 I said that (Usage Dep) was a mistake, I repeat that statement
now. If (Usage Dep) remains in the BIRD I will still support BIRD 155 in
the Open Forum, but will record my objections at that time.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
