[ibis-macro] Re: A question about GetWave's AMI_parameters_out
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 1 Dec 2010 10:55:51 -0800
Mike,
Yes, I am talking about Section 10.
Please tell me how an experienced programmer would know the following
from reading the current IBIS specification:
1) Whose responsibility is to allocate the memory for the char **msg
argument of AMI_Init? EDA tool, or AMI model? (pg. 187, section 3.1.2.8)
2) Quoting Walter: "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." This implies that the Init function allocates
one memory location to be used by Init as well as GetWave, and by the
multiple calls to GetWave. This also implies that the allocation is done
by Init, and only Init, and the de-allocation is done by Close and only
Close.
However, this is not in the spec. The EDA vendor or model maker can
assume anything they want. Some assumptions may be safer than others, but
if this is the "best practice" recommendation which currently comes through
the grape wine, why shouldn't it be in the specification? After all, if
my tool implements this recommendation, then anything else that is more
elaborate in the model goes to waste. Why should we let the model maker
work hard on something elaborate that will never be used in a tool, based
on the above recommendation? Or turn it around, if this is how all models
will be written, then why should the EDA tool vendor implement all kinds
of more elaborate features if they will never be used by a model?
Wouldn't a specification be more useful if it spelled out such rules
so that the EDA tool and model implementations wouldn't be based on
tell-tale rules and assumptions spread around by word of mouth? I
thought that was the purpose of a spec.
3) Quoting Walter again: " To be clear, AMI_Init may not deallocate
parameters_out." and a little later: "The model may deallocate any
previously parameters_out allocated blocks." The problem I see here
as well as in the current specification is that the word "model" is
used frequently instead of the exact name of the function. Strictly
speaking the second quote here contradicts the first quote, because
the word "model" could mean either of its three functions, so while
the first quote says Init may not de-allocate the parameters_out
memory, the second quote says it can do that...
I don't think that even an experienced programmer would know what this
means. On the contrary, an experienced programmer (like our parser
developer) applying plain logic to such statements climbs up the wall
in misery because they simply don’t know what was intended and how to
implement such statements in code.
I hope that it is obvious from the above explanation that my intent
is not to turn the specification into a Cook Book or HOWTO document.
Please answer the question in #1 above, and confirm that the implications
I stated in #2 above are correct. If so, I would suggest a BIRD to clarify
these in the specification.
Thanks,
Arpad
============================================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Mike Steinberger
Sent: Wednesday, December 01, 2010 11:09 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: A question about GetWave's AMI_parameters_out
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:
