[ibis-macro] Re: A question about GetWave's AMI_parameters_out

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Wed, 01 Dec 2010 11:09:19 -0600

Arpad-

I haven't looked, but I assume you're referring to Section 10. I was a primary author for that section. I'm not sure who else would admit to sharing that distinction with me.

I believe that what I said in my last e-mail would be pretty obvious to an experienced programmer; however, if you want more text in that area, it should be possible to phrase the substance of my previous e-mail as a clarification to the IBIS text.

I do wonder where we draw the line between specification and HOWTO document. I think the location of that line is going to depend at least somewhat on the reader, and so the question is not as clear as might at first appear.

Mike S.

On 12/01/2010 10:56 AM, Muranyi, Arpad wrote:
Thanks to all of you with the responses.  Mike's answer
comes closes to my problem, but none of the responses
quite answer my real question.  Let me rephrase it in a
different way.

The main problem I have is what Mike was stating, that the
spec doesn't state clearly what to do.  Since we are working
on corrections to the spec in the ATM meeting, I wonder if
we need to change the wording in this area to make things a
little more understandable and predictable.

Here is what causes the confusion in my mind:

Under the discussion of the Init function's arguments, we
see under AMI_parameters_out that memory is allocated and
de-allocated by the model.  Since this is under the Init
function, I might interpret that Init allocates memory for
the AMI_parameters_out argument of Init.  A little vague,
but I can live with that.

At this point I wonder who is going to de-allocate the memory
that was allocated for the above argument by Init?  Since we
don't want to lose the content in that location as soon as
Init is finished (before the EDA too cal grab it), I would
assume that this must be done by Close.  Again, a little vague,
but I could still live with that because I am familiar with
the concept that the Close function's purpose is to close up
shop in a nice way, i.e. release all memory.

The story is similar for AMI_memory_handle, but also quite
different.  The spec says the same for this argument, "The
memory pointed to by AMI_handle is allocated and de-allocated
by the model.", but this is allocated in the Init function
for use by the GetWave function: " Used to point to local
storage for the algorithmic block being modeled and shall
be passed back during the AMI_GetWave calls."  This starts
making me wonder whether the previous argument, AMI_parameters_out
is allocated by the Init function for its own use, or for
GetWave's use?  The spec doesn't say anything about that...

The last argument, msg doesn't say anything about who allocates
the memory for that.  Is it the tool , or is it the model?


Now, in the GetWave function's arguments description section
the spec repeats the AMI_parameters_out argument with the
statement that "The memory for this string is to be allocated
and deleted by the algorithmic model."  This is where things
get completely muddy.

Considering that the general purpose of Init is to set things
up for GetWave, which is demonstrated by the AMI_memory_handle
argument, I wonder whether the AMI_parameters_out argument of
GetWave is also set up by Init for the use of GetWave?  Even
if Init would also need to return something in this memory
location, I can still see that Init allocates memory for it,
returns something in it (if it has something to return) and
then GetWave uses the same location to return something after
each call to it.  Finally, Close could de-allocate it when done.

But I can also imagine that GetWave allocates its own memory
for this argument, and also that it allocates a different one
for each call (whether it makes sense or not), but none of this
is spelled out in the spec.  I think we should do better in a
spec than that...

So in order to fix (or clarify) this in the spec, I would like
to hear from the authors of this portion of the existing spec
what the intent was.  Please explain.

Thanks,

Arpad
=================================================================





-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Mike Steinberger
Sent: Wednesday, December 01, 2010 9:40 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: A question about GetWave's AMI_parameters_out

All-

I think Walter has stated the correct principle: the EDA platform should
only use the value of AMI_parameters_out from the latest call to the
model, regardless whether that was Init or GetWave.

Consider:
1. After the model function (Init or GetWave) returns, the value of
AMI_parameters_out must remain valid at least long enough for the EDA
platform to use it.
2. GetWave will typically be called many times. Although technically
feasible, it wouldn't make much sense for the model to keep all of the
AMI_parameters_out messages it's ever sent. That could be a lot of
memory that would remain allocated for no good reason.

One obvious solution, therefore, is for GetWave to de-allocate its last
AMI_parameters_out message before allocating a new one. Another possible
solution would be for the model to maintain an AMI_parameters_out buffer
that it overwrites as necessary. However, since IBIS 5.0 doesn't state
which of these two options to choose, we must assume that some model
developers have chosen one option, and other model developers the other.

Ergo, the principle Walter has stated.

Hope this helps.
Mike S.

On 12/01/2010 09:08 AM, Walter Katz wrote:
Arpad,

To be clear, AMI_Init may not deallocate parameters_out. The model is
responsible for maintaining a list of parameters_out allocations, The model
may deallocate any previously parameters_out allocated blocks. AMI_GetWave
may choose to allocate a new parameters_out block, or use an older one that
was not de-allocated. AMI_Close is responsible for deallocating any
paramerts_out blocks that had not been previously allocated. The EDA tool
may not assume that the parameters_out data from a previous call to AMI_Init
or AMI_GetWave is valid after a new call to AMI_GetWave.

Walter

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of ckumar
Sent: Wednesday, December 01, 2010 6:19 AM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: IBIS-ATM
Subject: [ibis-macro] Re: A question about GetWave's AMI_parameters_out

arpad:

the model is free to allocate and deallocate parameters_out at each call ,
whether it is to init and whether it is to getwave call. The model can also
allocate parameters_out just once. It is totally at the model's discretion.


On Tue, 30 Nov 2010 22:49:13 -0800, "Muranyi, Arpad"
<Arpad_Muranyi@xxxxxxxxxx>   wrote:
Hello everyone,



I am trying to understand sections 3.1.2.6 on pg. 186

and 3.2.2.4 on pg. 189 of the IBIS specification.



Both of these sections say that:  "The memory pointed

to by AMI_parameters_out is allocated and de-allocated

by the model.", but neither of these sections specify

whether this allocation supposed to be done in the Init

function, for both the Init and the GetWave function's

AMI_parameters_out, or whether the Init and the GetWave

functions have to allocate their own memory for this.



It is also not quite clear from this whether the two

AMI_parameters_out are really the same "variable" i.e.

memory location, or whether they are two independent

variables and memory locations, one for each function,

(regardless of which function does the allocation).



Could someone please shed some light on what the intent

was on this for me?



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

  
1�+���+^��i��0��Z��?�������f����u�p�����i����y�h�m�����y�b��(��������+�:.�˛���m��֧zf��:"n+&i���z�_�祊�l�����rۧ���r��e===

---------------------------------------------------------------------
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: