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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 29 Aug 2019 15:46:14 +0000

Walter,

This could go under "Other Notes".  There is no need to create a new heading 
"Explanation"...

I wonder about this sentence:

"specifying DC_Offset as an Input to the Rx AMI_Init function allows the Rx 
AMI_Init function
and the Rx AMI_GetWave function to account for non-linearities in the 
equalization"

If I remember correctly, the AMI_Init function can only do LTI algorithms 
(while the AMI_GetWave
function can do non-LTI algorithms as well).  If that is correct, the above 
sentence needs to be
changed.

Thanks,

Arpad
============================================================================

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, August 28, 2019 9:03 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; 'IBIS-ATM' 
<ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Latest version of DC_Offset BIRD

Arpad, Ambrish,

Can I suggest the following:

Replace
Definition:           The input value of DC_Offset is the mean value of the 
steady state high and low voltages of the analog channel step response at the 
Rx pad. When the DC_Offset is usage InOut, the output value of DC_Offset may 
return a different value by Rx AMI_Init.  This returned value can be added to 
the Rx AMI_GetWave output waveform by EDA tools. The sum of DC_Offset and Rx 
AMI_GetWave output waveform forms the complete waveform.
With
Definition:           The input value of DC_Offset is the mean value of the 
steady state high and low voltages of the analog channel step response at the 
Rx pad.
Explanation:      AMI modeling was original based on differential SerDes 
channels. AMI modeling has been extended to handle single ended channels such 
as DDR5. The basic assumption has been that the equalization in both the Tx and 
Rx AMI models assume that the single ended signal is adjusted so that the 
signals are nominally centered around zero. Because the input to the Rx 
AMI_Init function is an Impulse Response, specifying DC_Offset as an Input to 
the Rx AMI_Init function allows the Rx AMI_Init function and the Rx AMI_GetWave 
function to account for non-linearities in the equalization between the Rx pad 
and the Rx latch. These non-linearities may occur at the input differential 
gain and DFE adder. DC_Offset is also the nominal mean voltage of the single 
ended waveform measured at the pad relative to the ground reference node of the 
Rx [GND Clamp Reference]. The waveform input to the Rx AMI_GetWave is nominally 
centered around zero. Note that "nominally zero" is used because the actual 
waveform may not have a balanced number of high and low states. The waveform 
output of the Rx AMI_GetWave is the waveform at the latch relative to the latch 
threshold. It may be useful for the user to compare this waveform to a waveform 
measured or simulated at the Rx pad whose voltage is relative to the [GND Clamp 
Reference]. The EDA tool or user can visualize this by adding to the waveform 
"mean value of the steady state high and low voltages of the analog channel 
step response at the Rx pad", which is the same value the EDA tool would use to 
set the input value of DC_Offset. This adjusted waveform is called the 
"complete waveform". If DC_Offset is an InOut, the output value of DC_Offset 
may return a different value by Rx AMI_Init or Rx AMI_GetWave function. In this 
case the EDA tool or user can creates the "complete waveform"  by adding the 
output value of DC_Offset to the waveform.

Walter

Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Office 978.461-0449 x 133
Mobile  720.417-3762
[cid:image001.jpg@01D55E56.F64800D0]

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

Walter,

I understand all that, but that's not what I am talking about.

I am talking about writing a spec that has no ambiguities, loopholes
and doesn't rely on anecdotal information.  That's all...

Thanks,

Arpad
====================================================

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, August 28, 2019 7:26 AM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>; 
'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: Latest version of DC_Offset BIRD

Arpad,

If you subtract something, to make it centered around zero, put it through a 
filter that keeps it centered around zero the natural thing to do is to either 
display the result centered around zero are add back in what you subtracted in 
the first place. The bottom line is the result your are about - BER and Margin 
do not care whether to added back in the amount you originally subtracted or 
not.  The actual value of the waveform output is meaningless to this analysis.

Since the spec clearly says that the waveform output shall be analyzed around 
"0", then what engineering decision can be made by shifting the waveform by any 
amount as long as one shifts the measurement point ("0") by the same amount?

Walter

Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Office 978.461-0449 x 133
Mobile  720.417-3762
[cid:image001.jpg@01D55E56.F64800D0]

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

Walter,

In that case the BIRD (spec) should state that if the parameter is not present,
then the model can do anything it wants, and the EDA tool can do anything it
wants (or whatever) when the parameter is not present or is a Usage In.

The point is that this is a spec, and we should try to not have ambiguities in 
it...

Of course, not saying anything about this is equivalent to "do anything you 
want",
so let's save some ink and paper by not saying anything and keep people in
suspense, not knowing for sure what the outcome will be.  :)

Thanks,

Arpad
==============================================================

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, August 27, 2019 8:06 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>; 
'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: RE: [ibis-macro] Re: Latest version of DC_Offset BIRD

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
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Office 978.461-0449 x 133
Mobile  720.417-3762
[cid:image001.jpg@01D55E56.F64800D0]

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On 
Behalf Of Muranyi, Arpad
Sent: Tuesday, August 27, 2019 7:50 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto: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