[ibis-macro] Re: Question about GetWave_Exists

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 8 Mar 2012 17:37:51 +0000

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



From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] 
On Behalf Of Todd Westerhoff
Sent: Thursday, March 08, 2012 10:01 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question about GetWave_Exists

Needless to say, that last part should have been "... it does prove useful in 
some debugging situations ..."

And this is after I had my eyes fixed.  Sheesh.

Todd.


Todd Westerhoff
VP, Software Products

Signal Integrity Software Inc. * www.sisoft.com<http://www.sisoft.com/>
6 Clock Tower Place * Suite 250 * Maynard, MA 01754
(978) 461-0449 x24  *  twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx>


"Three in the morning and I'm still awake,
So I picked up a pen and a page ... "
                                             -Sidewalk Prophets

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Todd Westerhoff
Sent: Thursday, March 08, 2012 9:22 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question about GetWave_Exists

Arpad,

The original intent, if I remember correctly, was to provide clear-text 
documentation on what the model did and didn't do.  You're correct that the EDA 
tool could query the entry points itself and I don't think we considered that 
when the text was first written.  But - the point stands, the .ami file 
provides clear text that the user can see.

Approved BIRD 120.1 is more explicit.  Beginning at line 448, we see things 
like this:

| Step 5.  If Tx GetWave_Exists is True 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.

This is clear - the value declared in the .ami file is to be used to control 
the analysis flow.  No matter what anyone was (or wasn't) thinking when this 
text was written, this is what the text-to-be-included in IBIS 5.1 says.

There is an obvious implication here; the reverse of the original question you 
proposed.  If the .ami file claims Getwave exists and it actually doesn't, an 
EDA tool that blindly follows the directive will attempt to call an entry point 
that doesn't exist.  The existing text could be augmented to include that 
consideration and recommend that the tool verify the entry point actually 
exists BEFORE calling it.  I consider this to be good programming practice that 
everyone has probably incorporated already, or will after this discussion - 
without any further activity on the committee's part.

Bottom line, I think [this is my opinion], the EDA tool should do what the .ami 
file says - otherwise, why bother having the parameter at all?  While the 
ability to turn Getwave access on/off for a model that supports Getwave is an 
unusual application, I agree with David - it does provide useful in some 
debugging situations and is worth keeping around - besides, that's what the 
current text says.

Thanks for the question,

Todd.


Todd Westerhoff
VP, Software Products

Signal Integrity Software Inc. * www.sisoft.com<http://www.sisoft.com/>
6 Clock Tower Place * Suite 250 * Maynard, MA 01754
(978) 461-0449 x24  *  twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx>


"Three in the morning and I'm still awake,
So I picked up a pen and a page ... "
                                             -Sidewalk Prophets

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 07, 2012 6:42 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question about GetWave_Exists

Ambrish,

Even though I tend to agree with you, I wonder
what was the purpose of putting this parameter
into the AMI specification.

The reason I wonder is because any programmer
skillful in the art knows how to obtain the
entry points to the functions in a DLL, i.e.
they can figure it out programmatically whether
the function exists or not, and if they are
careful programmers, they will not call the
function if the pointer to it is a null...

Having that in mind, who is this information in
the .ami file targeted to, and for what purpose?

Thanks,

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

From: Ambrish Varma 
[mailto:ambrishv@xxxxxxxxxxx]<mailto:[mailto:ambrishv@xxxxxxxxxxx]>
Sent: Wednesday, March 07, 2012 4:22 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: Question about GetWave_Exists

Arpad,
The parameter value was supposed to be an answer to the question Getwave Exists 
in the AMI model or not?
So I do believe that the .ami file was written incorrectly.
Thanks,
-Ambrish.




[cid:image003.gif@01CCFD17.F4C6B4C0]



Ambrish Varma   |  Member of Consulting Staff

P: 978.262.6431   www.cadence.com<http://www.cadence.com>










________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 07, 2012 5:05 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Question about GetWave_Exists

Hello everyone,

I would like to ask a question about the GetWave_Exists
AMI parameter.  This is what I see in the specification
on pg. 144:


| GetWave_Exists:
|
| GetWave_Exists is of usage Info and type Boolean. It tells
| the EDA platform whether the "AMI_GetWave" function is
| implemented in this model. Note that if Init_Returns_Impulse
| is set to "False", then Getwave_Exists MUST be set to "True".


I came across a model recently in which the AMI DLL does have
a GetWave function, but the .ami file says GetWave_Exists = False.
The vendor says that they want to use this AMI parameter as
a switch to be able to tell the EDA tool whether to invoke
the GetWave function or not.

The way I read the above specification snippet is that this
parameter supposed to tell the tool whether this function
exists in the DLL or not.  If this parameter was to be used
to control whether the EDA tool should make use of it or not,
we should have given this parameter a different name, something
like this:

Use_GetWave_Function_If_Exists

I am curious to hear what our experts have to say about this.
Is the model's .ami file written incorrectly?  Should we advise
the model maker to not use this AMI parameter this way?

How should the EDA vendor handle this situation?  Should the
tool execute the GetWave function when it exists, regardless
of what this parameter says, or should it only execute the
GetWave function if this parameter is set to True, regardless
of whether the GetWave function exists in the DLL or not :).

Thanks,

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

GIF image

GIF image

GIF image

Other related posts: