[ibis-macro] Re: Latest version of DC_Offset BIRD

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 27 Aug 2019 21:05:58 -0400 (EDT)

Arpad,

 

1.      If DC_Offset is not present, then what our EDA tool does is allow
the user to view the raw output of Rx AMI_GetWave or the "corrected"
waveform by adding "the mean value of the steady state high and low voltages
of the analog channel step response at the Rx pad".
2.      If DC_Offset is an In, then what our EDA tool does is allow the user
to view the raw output of Rx AMI_GetWave or the "corrected" waveform by
adding the value of DC_Offset which happens to be the same number as in 1
above ("the mean value of the steady state high and low voltages of the
analog channel step response at the Rx pad").
3.      If DC_Offset is an InOut, then what our EDA tool will do is allow
the user to view the raw output of Rx AMI_GetWave or the "corrected"
waveform by adding the value of output value of DC_Offset.

 

When this parameter is not present in the .ami file the model can do what it
wants. It does not have to assume anything. The model make wrote his model
with disregard for the "the mean value of the steady state high and low
voltages of the analog channel step response at the Rx pad". See 1 above for
what our EDA tool does. There is not requirement that any other EDA tool
should do.

 

If the EDA tool needs a default, then it is simply "the mean value of the
steady state high and low voltages of the analog channel step response at
the Rx pad".

 

Please remember that this spec has been and should continue to be a
description of the inputs and outputs of a DLL. We have repeatedly stated
that the EDA tool can analyze the outputs of the models any way it wishes
to. Here is where EDA tools can differentiate themselves.

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Office 978.461-0449 x 133

Mobile  720.417-3762



 

From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> On
Behalf Of Muranyi, Arpad
Sent: Tuesday, August 27, 2019 7:50 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Latest version of DC_Offset BIRD

 

Thinking about the question of "default" values some more:

 

While we were correct in the meeting that Format Value parameters don't

have defaults according to the spec, I think we still need to define what

value the model and EDA tool should use when this optional parameter is

not present in the .ami file, or what value the EDA tool should use when the

parameter is defined as Usage In.

 

So I think we should say something like this in Usage rules:

 

When this parameter is not present in the .ami file, the Rx algorithmic
model

and the EDA tool should assume a value of 0 volts.  When this parameter is

defined as Usage In, the EDA tool should assume a value of ___ (we need to

decide whether this should be 0 volts, or the input value).

 

Thanks,

 

Arpad

=============================================================

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, August 27, 2019 6:31 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Latest version of DC_Offset BIRD

 

Ambrish,

 

Thanks for yet another draft :).

 

The sentence you undeleted:

 

"When the DC_Offset is usage InOut, the output value of DC_Offset may return
a different value by Rx AMI_Init."

 

was deleted because it didn't provide any additional information to what we

already know about InOut parameters, namely that the model can return a

different value from what was passed into the model.  I don't mind keeping

this sentence, as it does no harm, but what is still missing is a real
DEFINITION

for what the MEANING of this output value is.  I thought we made it clear in

our discussion in the meeting that we had to state that the output value was

associated with the Rx GetWave output waveform (as opposed to being

associated with the channel's step response waveform), and I thought you

wrote something into this area during the meeting that I can't find in this

version now.  Why did that disappear?

 

Thanks,

 

Arpad

==============================================================

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Tuesday, August 27, 2019 4:20 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Latest version of DC_Offset BIRD

 

Hi All,

Attached is the latest version of the BIRD after today's discussion and
edits in the meeting.

I have deleted 1 more line in the Usage Rules as it felt redundant. 

I also undeleted this line: 'When the DC_Offset is usage InOut, the output
value of DC_Offset may return a different value by Rx AMI_Init.' 

as it clearly says how the DC_Offset value is returned (in the AMI_Init).

 

Please let me know if there are any comments/questions.

 

Thanks,

Ambrish.

JPEG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 08-2019