[ibis-macro] Re: Question about GetWave_Exists
- From: James Zhou <james.zhou@xxxxxxxxxx>
- To: "twesterh@xxxxxxxxxx" <twesterh@xxxxxxxxxx>, ATM Working Group <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 14 Mar 2012 14:30:13 -0700
Todd,
It is the paragraph starting with "Under certain circumstances".
Regards,
James
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Todd Westerhoff
Sent: Wednesday, March 14, 2012 2:22 PM
To: ATM Working Group
Subject: [ibis-macro] Re: Question about GetWave_Exists
James,
Then we're talking about BIRD 120.1, case 7? That's the only place I know of
where double counting could legitimately be considered as an issue.
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: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Wednesday, March 14, 2012 5:10 PM
To: twesterh@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Question about GetWave_Exists
Todd,
The reason to bring up "double-counting" (in a thread to discuss
GetWave_Exists) is because, double-counting will cause the value of
GetWave_Exists to be reset from true to false, according to BIRD120.1.
Regards,
James
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: Wednesday, March 14, 2012 12:14 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question about GetWave_Exists
I'm confused.
Double-counting hasn't been a problem since BIRD 107. Why are we talking about
it again?
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: Monday, March 12, 2012 9:26 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question about GetWave_Exists
James,
Sorry for the late reply to your message.
Your observation is correct that one of the suggestions made
n the current flow text to eliminate double counting is to not
use GetWave. This, however, comes with the willful degradation
of accuracy as you correctly noted. I personally did not like
this text in the BIRD that proposed it, and I spent actually
long months on a different flow before this one was approved
in which there was no need for de-convolution or any
possibility for double counting, but that proposal was voted
down by the ATM group.
Those who were in favor of the flow being incorporated into
the next specification reasoned that we all know how to do
de-convolution now and there is no need to look for ways to
avoid it.
Regarding your three questions, I don't see a need to answer
the first one. It is a trivial piece of code to query the
DLL for the entry point to its functions. There is no need
to tell the EDA tool what is inside the DLL, the tool can find
our for itself. In fact a good programmer will always check
whether the address is a "null" before executing anything...
Your 2nd and 3rd questions are good to keep in mind when we
finalize the wording for the Definition and Usage Rules
of this parameter.
Thanks,
Arpad
================================================================
From: James Zhou
[mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]>
Sent: Friday, March 09, 2012 4:49 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Question about GetWave_Exists
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
________________________________
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.
________________________________
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:
