[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 09:35:06 -0700
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:
