[ibis-macro] Re: Some final questions on BIRD 123.
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 12 Dec 2011 18:53:11 +0000
Walter,
Thanks for the example to illustrate the problem and need.
Regarding "I added Usage out to all of the Jitter BIRD parameters to be
consistent with Tx_DCD (IBIS 5.0)",
I think "consistency" in this case may not make sense.
After all, these are Reserved parameters, and because of
that, we can write specific rules for each of them
independently. There is no need for consistency that
opens the doors for nonsense. If there would be a need
in the future for something that we can't imagine today,
we can always add that capability to the spec at that
time with a clear description (since we are talking
Reserved parameters). On the other hand, if we
insist to allow these parameters to be Out, we MUST
describe when and what and how, etc... the tool
can/should/must do with these, and when and what and
how, etc... the model can/should/must do with these.
I think this is still missing from the description of
these parameters. Like I mentioned it in my other
email not too long ago, is the value in the .ami
file supposed to be used as an initializer in the
EDA tool and/or the model? Is the tool supposed to
pass it into the model? Is the tool supposed to use
the output of AMI_Init, or AMI_GetWave, or both, when
and how? Is the model supposed to write the output
to AMI_Init, or AMI_GetWave, or both, when and how? Etc...
Regarding the tap coefficients, I wonder if we could make
them reserved somehow. I know this may be challenging,
because each model maker may call them by different names.
But (without having thought about this too much) I wonder
if we could use the Table in such a way that its first
column is a string with the name of the tap and the second
column contains the value for it. The table can have as
many rows as the number of taps in the device. This would
give the flexibility of having arbitrary tap names and number
of taps, yet the parameter could still be reserved. That
way we could describe them in the spec unambiguously, and
could be made In, or InOut as needed. Just an idea...
Regarding Rx_noise, can it be made a Reserved parameter?
If so, we can describe it unambiguously, correct?
Regarding "Nor should IBIS prevent EDA companies from supporting their
customers' requirements."
I am not sure why you bring this up in this context because
we seem to be talking about Reserved parameters here. But
this seems to allude to our discussion and pending BIRD
dealing with Model_Specific Out parameters. I don't want
to get into this in detail here now, but it simply does not
make sense to allow in the spec to have that. Otherwise hell
will brake lose. If you need to support something for your
innovative customers, you can still do that all you want.
Whether you do it with Model_Specific Out parameters or
outside the specification, doesn't matter, it will be not
portable anyway. So why should we use the spec to bless
and foster non-portable models? You might as well do it
outside the spec then...
Thanks,
Arpad
==============================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, December 09, 2011 10:37 PM
To: DBanas@xxxxxxxxxx; fangyi_rao@xxxxxxxxxxx; Muranyi, Arpad;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Some final questions on BIRD 123.
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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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>
[mailto:fangyi_rao@xxxxxxxxxxx]<mailto:[mailto:fangyi_rao@xxxxxxxxxxx]>
Sent: Friday, December 09, 2011 5:05 PM
To: David Banas; Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx<mailto: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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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:
