[ibis-macro] Re: More new BIRD drafts posted on the ATM website
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 24 May 2011 11:51:47 -0700
Walter,
I think we are mostly in agreement. I was only raising questions
about **msg because from early AMI discussions I remember that the
main concept was that the Init function initializes and allocates
memory for GetWave and AMI_Close deallocates them. With this
concept in my mind, I was wondering whether **msg was intended to
be used that way or not... This is perfectly doable from a technical
perspective, but the spec didn't help me to answer my question on
whether this was intended or not. The fact that **msg is missing
from the GetWave function made me think that maybe the Init
function's **msg was supposed to be used by GetWave also, but the
fact that there are two **AMI_parameters_out arguments made me
think the other way...
One way or another, we should make sure that the spec is clear on
this...
Thanks,
Arpad
===================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, May 24, 2011 1:26 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: More new BIRD drafts posted on the ATM
website
All,
I think using **msg to convey information from AMI_GetWave is dangerous
and unwarranted. Right now we enumerate return values of 0 for failure,
and 1 for success. I think the only correct thing for the EDA tool is to
gracefully terminate a simulation if AMI_Init or AMI_GetWave return 0.
We certainly can enumerate other possible return values, but they need
to be associated with other actions that the EDA tool is directed to
perform.
Each call to AMI_GetWave must assume that the addresses passed to the
DLL on previous calls to AMI_Init or AMI_GetWave are invalid (except for
AMI_memory). If the model maker wished to convey any additional
information that he might want to convey to the user, the model maker
should create a Model Specific (Usage Out) (Type String) parameter that
the EDA tool can display to the user. If you think it would be useful to
have a Reserved Parameter to do this, then the specification must
describe the actions that the EDA tool shall do based on the content of
the string returned. Adding such capability will require that actions
other than continue simulation or gracefully terminating simulation
would need to be required before such a new Reserved Parameter is
defined.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, May 24, 2011 12:35 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: More new BIRD drafts posted on the ATM website
Walter,
Thanks for your answers.
I will consider the first three questions answered, since they are at
the discretion of the EDA vendor or model maker and we don't seem to
need to write anything into the spec about them.
Regarding the answer to the **msg question, your answer indicates that
it was not intended to be used by AMI_GetWave. However, this is not
clear from reading the spec, and it seems that this "loophole" can
be "exploited" in some ways by model makers and EDA vendors, especially
if the two are the same people...
I also wonder how we could implement the suggestion Ambrish made for
the BIRD draft on the function return value to provide messages to the
EDA tool and its user about the various failures a GetWave function
could experience. If **msg is not available to GetWave it can only
send messages to the EDA tool through the AMI_parameters_out string
for which we either have to define some new reserved parameters for
messaging, or we would have to go the less rigorously defined
Model_Specific route (which might still be good enough to put
things on the screen or into undefined files).
The thing about letting GetWave use **msg is that it can be done
painlessly if we spell out a few rules (which might have to be done
either way to have a more robust spec). The only question is what
these rules should be.
Also, you say: "The EDA tool cannot assume that AMI_GetWave is going
to do anything with the **msg data except possibly de-allocate it"
and "AMI_GetWave may de-allocate memory allocated by previous calls
to AMI_Init and AMI_GetWave. AMI_Close is expected to de-allocate any
memory allocated by AMI_Init or AMI_GetWave not already de-allocated."
I was under the impression that the deallocation of memory was the
AMI_Close function's job (unless the nature of the multiple GetWave
calls would lead to "memory leaks" while they are executed). I feel
that we should be a little more specific in the spec than just say
things like "memory is allocated and deallocated by the model".
Part of me says that we shouldn't have to spell out every little
detail and allow some freedom for the model makers, but at the same
time I feel that we should make the model makers' life as easy as
possible. There are times when too much freedom can cause more
trouble than help...
Thanks,
Arpad
=====================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, May 24, 2011 10:21 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] More new BIRD drafts posted on the ATM website
Arpad,
Each call to an AMI_Init and AMI_GetWave use an independent set of
arguments which may or may not have the same pointer addresses and
memory. The only thing that must be maintained between the calls is
AMI_memory which the model allocates to stores persistent information
that gets communicated from the AMI_Init and AMI_GetWave to subsequent
calls to AMI_GetWave and AMI_Close.
Is the EDA tool supposed to provide two independent addresses for the
AMI_parameters_out arguments in the AMI_Init and AMI_GetWave fuctions?
WMK> "At the discretion of the EDA Tool"
Is the AMI_Init function and the AMI_GetWave function supposed to use
the
same string pointers (memory locations)?
WMK> I assume you mean memory location of the string: "At the discretion
of the model developer"
Are multiple AMI_GetWave functions supposed to use the same string
pointers
(memory location)?
WMK> I assume you mean memory location of the string: "At the discretion
of the model developer"
Is AMI_GetWave allowed to put string pointers into the **msg argument's
memory location?
No. The EDA tool cannot assume that AMI_GetWave is going to do anything
with the **msg data except possibly de-allocate it.
Spell out which function does the memory allocation (AMI_Init,
AMI_GetWave)
and which function does the deallocation (AMI_Close).
WMK> AMI_Init allocates the memory it allocates, and AMI_GetWave
allocates the memory it allocates. The DLL maintains the list of
allocated memory (in AMI_memory). AMI_GetWave may de-allocate memory
allocated by previous calls to AMI_Init and AMI_GetWave. AMI_Close is
expected to de-allocate any memory allocated by AMI_Init or AMI_GetWave
not already de-allocated.
Walter
Other related posts:
