[ibis-macro] Re: Some final questions on BIRD 123.
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <DBanas@xxxxxxxxxx>, <fangyi_rao@xxxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 09 Dec 2011 23:37:01 -0500 (EST)
All,
Let me give some real life examples on how Usage Out is used by AMI
models.
Rx AMI_GetWave DFE taps. These are model specific, but many models output
the value of the DFE tap on each call to GetWave. The EDA tool can plot
these values as a function of time. This tells the user how the DFE is
converging.
Some Rx GetWave models automatically modify the CTLE filter and gain. It
is useful for the model to output these values so the EDA tool can display
them to the User.
I think Usage Out is not useful for all of the BIRD 122 Jitter parameters,
and I have pointed this out numerous times in IBIS-ATM meetings, and in
e-mails to the reflector. I added Usage out to all of the Jitter BIRD
parameters to be consistent with Tx_DCD (IBIS 5.0) but left it open to the
committee as to whether to allow it or not. However, it is useful for
Rx_Noise, in particular with respect to Rx models with AGC. Since the
Rx_Noise is a function of gain, and there are AMI models that do want the
EDA tool to include the real Rx_Noise in time domain simulation it is a
requirement that Rx_Noise be allowed to be an Out. When BIRD 122 is
approved, then Rx_Noise can be a Reserved Parameter, and therefore it is
well defined how an EDA tool shall use the value of Rx_Noise out of Rx
GetWave to determine channel performance correctly. I point out that
existing users of AMI models need this functionality today, and EDA
companies that need to support their customers design requirements cannot
wait for IBIS to act. Nor should IBIS prevent EDA companies from
supporting their customers' requirements.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of David Banas
Sent: Friday, December 09, 2011 8:25 PM
To: 'fangyi_rao@xxxxxxxxxxx'; 'Arpad_Muranyi@xxxxxxxxxx';
'ibis-macro@xxxxxxxxxxxxx'
Subject: [ibis-macro] Re: Some final questions on BIRD 123.
Can you provide some context, explanation, references, etc.?
Thanks,
-db
From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Friday, December 09, 2011 5:05 PM
To: David Banas; Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: Some final questions on BIRD 123.
Would it make sense that the EDA tool should over-ride any value for a
particular parameter, which came back as a [Usage Out] parameter from
AMI_Init, with the value it sees coming back from AMI_GetWave, once it
starts `GetWaving'? If so, would that allow us to cut in half the number
of new parameters being introduced in BIRD 123?
David: my understanding is not.
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, December 06, 2011 10:35 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Some final questions on BIRD 123.
David,
I would like to respond to your last question:
"? What is the purpose of this phrase?"
This phrase has a long history and lots of heated
discussions behind it. Here is why:
Model_Specific parameters cannot be described in
the specification, because they can be anything
the model maker can imagine. For this reason,
the specification cannot describe the meaning of
Model_Specific parameters, and EDA tool vendors
cannot implement any actions based on them. We
should really not have any Model_Specific Usage Out
parameters in the specification, because other than
displaying them on the screen or saving them into
some log files, the EDA tool really can't use them
for anything else. This is why we started to put
verbiage in some of the recent BIRDs like the one
you are questioning, because currently the spec
doesn't prohibit Usage Out Model_Specific parameters.
On the other hand, Reserved parameters are fully
described in the specification i.e. their meaning
and how the model or EDA tool supposed to use or
generate them is completely described. Such parameters
can be Usage Out and the EDA tool will understand what
to do with them based on the specification.
The jitter parameters in BIRD 123 seem to be all
Reserved parameters. This means that we can fully
describe what they mean and how they are used and
generated.
However, another question that needs to be considered
is this:
A parameter is defined in the .ami file. The tool
reads it. If a parameter is Usage Out, the model
is outputting it to the EDA tool. If the .ami file
contains a value for a Usage Out parameter, what is
the tool supposed to do with it? Being Usage Out, it
will not pass it into the DLL, or should it pass it in
as an initial condition for the DLL? Or is the tool
supposed to use it as an initializer for itself before
the DLL outputs its own (perhaps new) value? In some
ways it really doesn't make sense to have values in the
.ami file for parameters of Usage Out, because they are
really supposed to be an output from the DLL. But the
spec doesn't discuss this as far as I know. So what is
the meaning of the value in the .ami file for parameters
Usage Out?
Another question: If the parameter is Usage Out, and we
have AMI_parameters_out arguments in both AMI_Init and
AMI_GetWave functions, then the spec has to describe
which of those two functions is returning the value for
the EDA tool so it would know when and where to look for
the returned value. This depends entirely on the meaning
and purpose of the parameter. This may be the reason
for that statement in Walter's BIRD you are questioning.
I hope this answers your question.
Thanks,
Arpad
===========================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of David Banas
Sent: Tuesday, December 06, 2011 4:28 PM
To: 'Walter Katz'; 'James Zhou'
Cc: 'IBIS-ATM'
Subject: [ibis-macro] Some final questions on BIRD 123.
Hi Walter,
I think I'm just about there. Just a couple of questions:
1. Referring to this excerpt from the most recent version of the
BIRD (123.3_Draft1):
Note:
The EDA Tool/Simulator shall use the values of these Jitter and Noise
parameters directly if they are Usage Info. If they are Usage Out, then
the EDA Tool/Simulator shall use their values generated by AMI_Init. The
model's AMI_GetWave function may return different values for these
parameters than the values returned by AMI_Init; the EDA Tool/Simulator
may report the values of such parameters to the user, but the EDA
Tool/Simulator may not change any inputs to AMI models or change other
result of the simulation based on the values returned for the parameters
in this BIRD by AMI_GetWave.
a. Why is there a necessary difference in EDA tool behavior,
depending upon whether the parameters are of type Info or Out?
b. If Init and GetWave can return different values for these
parameters, then why do we need 2 sets (i.e. - Rx_Sj and Rx_CDR_Sj)? It
seems like we ought to be able to have just one parameter, Rx_Sj, and let
Init return one value for it, while GetWave returns another, depending
upon how sophisticated its CDR modeling is.
c. Referring to the last phrase, above, "or change other result of
the simulation based on the values returned for the parameters in this
BIRD by AMI_GetWave.": broadly interpreted, couldn't this phrase preclude
an EDA tool from applying the post-processing necessary for accurate BER
estimation? What is the purpose of this phrase?
Thanks,
-db
_____
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If
you have received this message in error, please advise the sender by reply
e-mail, and delete the message and any attachments. Thank you.
_____
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If
you have received this message in error, please advise the sender by reply
e-mail, and delete the message and any attachments. Thank you.
_____
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If
you have received this message in error, please advise the sender by reply
e-mail, and delete the message and any attachments. Thank you.
Other related posts:
