[ibis-macro] Re: revision of AMI_Resolve BIRD155
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <fangyi_rao@xxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 25 Jun 2013 14:51:30 -0400 (EDT)
Fangyi,
The flow is as follows:
1. User/EDA too determines the values of all Dep_In parameters and
all Info, In and InOut parameters that are not Dep_Out.
2. EDA tool calls AMI_Resolve with all Dep_In parameters.
a. AMI_Resolve determines the values of all Dep_Out Parameters
3. EDA tool calls AMI_Resolve_Close
4. EDA tool calls AMI_Init with all In and InOut parameters
a. AMI_Init returns the values of all Out and InOut parameters
5. EDA tool calls AMI_GetWave
a. AMI_GetWave returns the values of all Out and InOut parameters
b. Repeat step 5 N times
6. EDA tool call AMI_Close
There is no circular dependency.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Tuesday, June 25, 2013 2:42 PM
To: wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: revision of AMI_Resolve BIRD155
Hi, Walter;
To facilitate the discussion I constructed the following table for
different combinations of Dependency_Usage and Usage.
Info
In
InOut
Out
Dep_In
ok
ok
?
Not allowed
Dep_Out
ok
ok
?
Not allowed
Two combinations concern me.
If a parameter has the (Dep_In, InOut) attribute, then there could be
circular dependency between Resolve and Init.
If a parameter has the (Dep_Out, InOut) attribute, then returned values by
Resolve and Init could be inconsistent.
Fangyi
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 25, 2013 11:28 AM
To: RAO,FANGYI (A-USA,ex1); ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] revision of AMI_Resolve BIRD155
All,
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
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Tuesday, June 25, 2013 1:34 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] revision of AMI_Resolve BIRD155
Hi, All;
Please find the updated BIRD155 for resolving AMI parameter dependency in
the attachment. Major modifications include
1. Introduce usage type Dep. Parameters to be updated by the AMI_Resolve
function will have type Dep so that a parameter won't be updated twice by
AMI_Resolve and AMI_Init. The latter updates Out or InOut parameters.
2. Introduce a second API, AMI_Resolve_Close, to free memory allocated in
AMI_Resolve. This was suggested by Walter to allow user to call
AMI_Resolve outside of the AMI flow (w/o subsequent calls to
Init/GetWave/Close).
Your input is appreciated.
Thanks,
Fangyi
Other related posts:
