[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: