[ibis-macro] Re: Some final questions on BIRD 123.

  • From: <fangyi_rao@xxxxxxxxxxx>
  • To: <DBanas@xxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 9 Dec 2011 18:05:15 -0700

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.

Other related posts: