[ibis-macro] Re: Question about GetWave_Exists
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 9 Mar 2012 20:20:29 +0000
Hello everyone,
Here is a little update on this topic.
I brought the question up in the IBIS Open Forum teleconference
this morning. The group was willing to entertain the idea of
dealing with this correction/clarification in the Editorial
group, but a suggestion was made that I should look at the latest
draft of IBIS v5.1 to see how what the specification looks like
with all the BIRDs put together. This is what I found,
using the Draft v0.125 version of the IBIS v5.1 document:
http://www.eda.org/ibis/editorial_wip/IBIS-5.1-draft-v125.pdf
A search for "GetWave_Exists" first takes me to pg. 169-170
where the Time Domain Simulation Reference Flow is discussed.
This is the section to which I was proposing to add the words
in red bold shown in my previous email (below).
However, the next occurrence of this word appears on pg. 192-193
where the parameter is defined and described like this:
Definition: Tells EDA platform whether the AMI_GetWave is implemented in this
model
Usage Rules: Note that if Init_Returns_Impulse is set to 'False', then
GetWave_Exists MUST be
set to 'True'.
I don't know where this definition comes from, but note that it
states that this parameter supposed to tell the tool whether the
function exists in the algorithmic model or not. There is no
mention that this parameter can be used to tell the tool whether
it should use the GetWave function or not when it exists.
I want to mention here in parentheses that the sentence in the
Usage Rules is kind of lopsided too, because it says that if
Init_Returns_Impulse is False, GetWave_Exists has to be set
to True. What this is really trying to say is that the model
should implement and contain an AMI_GetWave function, therefore
this parameter will also be to True. But if someone reads the
sentence as written on paper, they could interpret it as having
to set this parameter to True, regardless of whether the function
exists in the file or not... This is certainly not what we wanted
to say.
Going back to the main topic of this thread, this finding seems
to indicate that the original intent was that the GetWave_Exists
parameter would be used to inform the EDA tool about the content
of the algorithmic model. However, if we agree that we also want
to be able to use GetWave_Exists for controlling the EDA tool, we
will not only have to add the words I wrote in red bold below, but
we will also have to reword the Definition and Usage Rules
(on pg. 192-193 of the v0.125 draft) in the v5.1 specification.
Please do not take this as me trying to blow some little thing
out of proportion. We are dealing with a specification which
needs to be wordsmithed accurately so that there is no room for
twisting it and misinterpreting it later on. The better the
spec is written now, the fewer problems we will have later.
Another general observation on this whole discussion is that
this is one of those situations when we are dealing with a
completely redundant and unenforceable parameter. (An EDA
tool can check what functions exist in the DLL-s with a single
line of code, and our IBIS parser will not look inside the
DLL to verify whether this parameter is correct or not).
For this reason, if we ended up deciding that we shouldn't use
this parameter for anything else but tell the tool whether
the GetWave function exists in the DLL, I would make a proposal
to deprecate the parameter and get rid of it. There is absolutely
no need for it at all.
But for the same reason I feel that to get some use out of this
parameter, we might as well allow it to be used for "flow control"
with the modifications mentioned in this thread. But then the
next question becomes whether the name of this parameter is
appropriate based on what we are trying to use it for. But
changing its name is the same as getting rid of it and
introducing a new parameter...
So, shall we:
#1) change the definition of GetWave_Exists in IBIS v5.1 and
allow it to be used to tell the tool whether or not to use the
GetWave function in a DLL when it exists?
#2) remove this parameter from IBIS v5.1 and come up with a
new parameter for IBIS v5.2 with a better name in IBIS v5.2
to be used for "flow control"?
#3) do nothing, and reap the consequences of a vague
specification later?
As usual, questions, comments welcome...
Thanks,
Arpad
==================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Thursday, March 08, 2012 11:38 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question about GetWave_Exists
Todd,
Don't take me wrong, I am not against the idea to use this
parameter like that for debugging purposes, and actually I
like to have that capability. I am just trying to figure
out whether that was the intent of the spec, and if yes
how we should say it. Even though the deadline for BIRDs
is tomorrow, this might still get fixed as an editorial
change for v5.1 if the change is minimal.
The problem I see with BIRD 120.1 is that as you also pointed
out, following those words literally introduces the possibility
for calling GetWave when it doesn't exist. Even though I agree
that good programming practice can eliminate the consequences
of calling a non-existent function, this situation is an
indication that even when we (actually I) wrote this BIRD,
our (my) thinking of this parameter was that it is a true
reflection of the content of the DLL and not an instruction to
the EDA tool on what to with the functions in the DLL,
regardless of whether they exist or not.
It seems that we need to take one of two possible actions:
Either fix BIRD 120.1 and make it clear that this parameter
can be used to instruct the tool whether or not to execute
the GetWave function when it exists,
or
fix BIRD 120.1 so that it would clearly state that this parameter
should always truthfully reflect the content of the executable
and should not be used for anything else.
I wrote an example in my last posting with a suggestion on how
this could be corrected along the lines of the first option above.
We could also fix the wording of the "Time domain simulation reference
flow" section in BIRD 120.1 like this (added words in red bold):
| Step 5. If Tx GetWave_Exists is True and the GetWave function exists in
| the Tx algorithmic model, the output of Step 4 is presented to
| the Tx model's AMI_GetWave function and the Tx AMI_GetWave
| function is executed. The output of the Tx AMI_GetWave function
| is passed on to Step 6.
|
| Step 6a. If Tx GetWave_Exists is True and the GetWave function exists in
| the Tx algorithmic model, and Rx GetWave_Exists is True and the
| GetWave function exists in the Rx algorithmic model, the
| output of Step 5 is convolved with the output of Step 1 by the
| simulation platform and the result is passed on to Step 7.
|
| Step 6b. If Tx GetWave_Exists is False and Rx GetWave_Exists is True and
| the GetWave function exists in the Rx algorithmic model, the
| output of Step 4 is convolved with the output of Step 2 by the
| simulation platform and the result is passed on to Step 7.
|
| Step 6c. If Tx GetWave_Exists is False and Rx GetWave_Exists is False, the
| output of Step 4 is convolved with the output of Step 3 by the
| simulation platform and the result is passed on to Step 8.
|
| Step 6d. If Tx GetWave_Exists is True and the GetWave function exists in
| the Tx algorithmic model, and Rx GetWave_Exists is False, the
| output of Step 5 is convolved with the output of Step 1 and the
| Impulse Response of the Rx filter by the simulation platform and
| the result is passed on to Step 8. (The Impulse Response of the
| Rx filter may be obtained by deconvolving the output of Step 3 by
| the input of Step 3).
|
| Note: For the scenario where the Tx AMI_Init function does NOT include
| equalization effects (i.e. does not modify the impulse response of the
| channel), Step 6d is functionally equivalent to simply convolving the
| output of Step 5 with the output of Step 3.
|
| Step 7. If Rx GetWave_Exists is True and the GetWave function exists in
| the Rx algorithmic model, the output of Step 6 is presented to
| the Rx model's AMI_GetWave function and the Rx AMI_GetWave
| function is executed. The output of the Rx AMI_GetWave function
| is passed on to Step 8.
These changes would convey the idea that the EDA tool should only
execute the GetWave function when GetWave_Exists is true and the
GetWave function exists in the algorithmic model. This would not
only eliminate the problem of telling the tool to execute the function
when it doesn't exist, but would also let people know that the GetWave
function will only be executed if GetWave_Exists = True in the .ami
file even if the function exists in the algorithmic model.
If we agree on doing this, we could try to "sneak these changes in"
at the 11:59,999th hour into the v5.1 specification...
Thanks,
Arpad
==================================================================
Other related posts: