[ibis-macro] Re: Question about GetWave_Exists
- From: James Zhou <james.zhou@xxxxxxxxxx>
- To: "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 9 Mar 2012 14:48:43 -0800
Hi Arpad,
Your comments and suggestions involve the issue of "double-counting". BIRD
120.1 describes it in lines 411-440 (cut and pasted at the end of this email).
Existing time-domain reference flow as described in BIRD 120.1, cannot
systematically avoid and resolve double-counting. Specifically, the existing
flow cannot detect whether double-counting is present in a given model. It
relies on EDA tools with or without end-user inputs to make decisions for
avoiding double counting.
BIRD 120.1 makes two recommendations to avoid double counting. The first of
which is not to use Tx AMI_GetWave (lines 421-422). The second of which is not
to use Rx AMI_GetWave (lines 423-431).
To look at this from another perspective: "when the Tx AMI model contains an
AMI_GetWave function that performs a similar or better equalization than the Tx
AMI_Init function"
the recommendation is to: " not utilize the Tx AMI_GetWave functionality, by
treating the Tx AMI model as if the Tx GetWave_Exists was False." The
recommendation for Rx AMI_GetWave is similar (i.e. not to use it). So why
would the model maker provides a "better" AMI_GetWave function only to find out
that it should not be used?
Your suggestion #1) and #2) help to answer the following questions:
(1) is there a AMI_GetWave function in the DLL?
(2) should AMI_GetWave function be used in time domain simulation?
(3) who makes the decision on whether or not to use AMI_GetWave, based on what
criteria and information?
It would be very helpful to get clear answers for these questions in the new
Spec.
Thanks,
James Zhou
BIRD 120.1, lines 411-440:
| Under certain circumstances, for example when the Rx_AMI_Init function
| includes an optimization algorithm, the impulse response presented to the
| Rx_AMI_Init function must include the Tx equalization effects for the
| optimization to work correctly. However, when the Tx AMI model contains an
| AMI_GetWave function that performs a similar or better equalization than
| the Tx AMI_Init function, there is a possibility for 'double-counting' the
| equalization effects in the Tx model. To allow for such models to work
| correctly, the EDA tool can operate in one of several ways, two of which
| are documented here:
| - not utilize the Tx AMI_GetWave functionality, by treating the Tx AMI
| model as if the Tx GetWave_Exists was False.
| - use deconvolution to obtain the impulse response of the Rx filter.
| Since the AMI_Init function contains a linear and time invariant
| algorithm, the Rx equalization can be represented as an impulse
| response. Since the output of the Rx AMI_Init function (output of
| Step 3) is an impulse response modified by the Rx equalization (e.g.
| by convolving the input of the Rx AMI_Init function with the impulse
| response of the Rx filter), the impulse response of the Rx filter can
| be obtained by deconvolving the output of Step 3 with the input
| presented to Step 3.
|
| Note: The Rx Model writer should keep in mind that it is not guaranteed
| that the impulse response that is presented to the Rx AMI_init function
| will always include the effects of the Tx filter. Therefore the Rx
| AMI_Init function may not be able to perform accurate optimization under
| all circumstances. For this reason, the parameters of the Rx AMI_Init
| function should always default to valid values or have a mechanism to
| accept user defined coefficients and allow the user to turn off any
| automatic optimization routines to ensure successful simulations.
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Friday, March 09, 2012 12:20 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question about GetWave_Exists
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
==================================================================
________________________________
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
Other related posts:
