[ibis-macro] Re: Question about GetWave_Exists
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 13 Mar 2012 01:26:24 +0000
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]
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
Other related posts:
