[ibis-macro] Re: Some final questions on BIRD 123.
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 12 Dec 2011 16:31:11 -0500 (EST)
Arpad,
This is an issue for IBIS AMI Check. Do we want to require that Out
parameters have a value, require that they do not have a value, or make it
optional. I do not care.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, December 12, 2011 4:23 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Some final questions on BIRD 123.
Walter,
The quote from the jitter BIRD is clear, but there is
one problem in the spec that is not mentioned in that
paragraph and as far as I remember anywhere in the spec.
What is the exact syntax of an Out parameter? Pg. 144
says this:
All reserved
| parameters must be in the following format:
|
| (parameter_name (Usage <usage>)(Type <data_type>)
| (Default <values>) (Description <string>))
We revised this in BIRD 127.3 to:
|* All parameters must be in the following format:
|*
|* (parameter_name (Usage <usage>)
|* (Type <data_type>)
|* ({Format} <data_format> <data>)
|* (Default <value>)
|* (Description <string>))
but I don't recall anything discussing whether value is
required for Out parameters. If we think logically, for
Out parameters the .ami file should not have a value,
since the value comes from the model. However, the spec
doesn't mention what to do in this case. Is the model
author supposed to put a value there (since the above
rule kind of implies that "(Default <value>)" is required)?
If so, what is the purpose of the value? Is it simply a
dummy value to satisfy the spec requirement, or is it
supposed to be used in a more meaningful manner, as in
using it for an initial condition, etc.? Even if we don't
make a blanket statement about this in the spec, I think
we should say something along these lines in the description
of those Reserved parameters which are "Out". Or, we should
revisit this in BIRD 127.3 and revise the above statement
to define the general syntax for Out parameters.
Regarding "SiSoft has not released ANY model that uses
Model Specific Out parameters (Type Tap excepted) to
modify simulation flow", are you saying that SiSoft DOES
use Model_Specific Out parameters to "modify simulation
flow"?
Thanks,
Arpad
==============================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, December 12, 2011 1:51 PM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Some final questions on BIRD 123.
Arpad,
Re (usage Out) of jitter parameters (your second point). The Jitter BIRD
says:
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.
I think this is pretty clear.
Regarding "consistency" (your first point).
I agree it can be on a case by case basis. We can either leave them all
"Infor or Out", or all "Info", or be selective. We have never seen one
that is "Out".
Regarding "Rx_Noise".
This is proposed to be a Reserved parameter in the Jitter BIRD. This is
the one parameter in the Jitter BIRD that should be allowed to be an Out
and the values from Rx GetWave should be used. I have stated this in the
IBIS-ATM meetings, and in e-mails to the reflector.
Regarding "Nor should IBIS prevent EDA companies from supporting their
customers' requirements."
SiSoft (QCD) does use the output of parameters that are described in BIRDs
officially submitted to the Open Forum in accordance with the
specification of those parameters in those BIRDs. We do not wait for IBIS
to approve them. SiSoft (QCD) also uses the values of Tx and Rx (Type Tap)
parameters that are returned from the models. I agree that one should not
bless the use of non-portable models by using the values of "Out"
parameters that have not been formally documented to the IBIS community
using the mechanism of formally submitting a BIRD fully describing how
these out parameters shall be used by the EDA tool. On the other hand,
IBIS cannot keep such advantages hostage by not addressing them in a
timely fashion. I will bet you $10,000 (figuratively) that SiSoft has not
released ANY model that uses Model Specific Out parameters (Type Tap
excepted) to modify simulation flow (other than parameters fully described
in BIRDs that have been formally submitted to IBIS).
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, December 12, 2011 1:53 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Some final questions on BIRD 123.
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] 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:
