[ibis-macro] Re: Question on BIRD197.3

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 9 Jul 2019 16:37:00 +0000

Fangyi,

Regarding "If you agree that DC_Offset is a property of the analog channel...",

at this point I don't have a preference in either direction, but I think the 
definition
should be made clearer to eliminate any possibility for misinterpretation...

Thanks,

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

From: Fangyi Rao [mailto:fangyi_rao@xxxxxxxxxxxx]
Sent: Tuesday, July 9, 2019 1:12 AM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx
Subject: RE: Question on BIRD197.3

Hi Arpad,

I recall that initially we were considering two equivalent options to handle 
the impulse response in AMI_Init for single-ended signal. Option one was to 
replace impulse response with step response. In this case we didn't need a new 
DC_Offset parameter. Option two was to keep the impulse response but introduce 
the new DC_Offset parameter. We later decided on option two. So I always think 
that the combination of DC_Offset and impulse response is equivalent to step 
response and hence DC_Offset is a property of the analog channel (or, in your 
term, the channel characterization waveform). Maybe we shall make this clear in 
the BIRD.

If you agree that DC_Offset is a property of the analog channel,  then your 
concern is no longer a problem.

Regards,
Fangyi

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: Monday, July 08, 2019 9:27 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Question on BIRD197.3


[EXTERNAL]
Fangyi,

Thanks for your answers.  I would like to "dwell" a little more on your #1 and 
#2 answers and
forget about the rest for a while, because the rest are all dependent on those 
answers.

The definition of DC_Offset says the following in the BIRD:

"The mean value of the steady state high and low voltages of the channel at the 
Rx pad."

I am not sure I completely agree with you that this implies that DC_Offset is a 
property of
the analog channel (at least not the way it is written).  In IBIS-AMI we have 
two things, one
is the channel characterization and the second is the execution of the AMI 
DLLs.  For the
channel characterization we say that it should NOT include any EQ effects (pg. 
197):

[cid:image001.png@01D5364A.9BBD4550]

Even though it doesn't use the same words, this channel characterization is 
taken from
the Rx die pad waveform (="the receiver's front end").  And then, in the AMI 
flow we
have the Rx GetWave input waveform, which is also an equivalent of the Rx die 
pad
waveform, but this waveform DOES include the Tx EQ effects.

Which if these two are we referring to in the definition of the DC_Offset 
parameter by
saying "Rx pad"?  If we are talking about the channel characterization 
waveform, I agree
the possible shifting from the Tx EQ is not included.  But if we are talking 
about the
Rx GetWave input waveform (which also represents the Rx die pad waveform) than 
it
could have DC components coming from the Tx EQ.

Which of these two waveforms is the DC_Offset definition referring to?  The 
first part
of that sentence doesn't make this more clear either:

"The mean value of the steady state high and low voltages of the channel"

This could refer to the channel characterization waveform just as well as the 
Rx GetWave
input waveform...   So I am sensing some vagueness in this definition...

Thanks,

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

From: Fangyi Rao [mailto:fangyi_rao@xxxxxxxxxxxx]
Sent: Monday, July 8, 2019 7:58 PM
To: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; Muranyi, Arpad 
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>; 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: Question on BIRD197.3

Hi Arpad,

Sorry for my delayed reply. Please note that


  1.  DC_Offset is a property of the analog channel. It does not take into 
account the effect of Tx DLL.
  2.  Because of #1, in the GetWave flow, we do not need to expect Tx output to 
center at the x-axis.
  3.  Because of #2, and also because in AMI we assume the interface between 
DLL and analog channel has high impedance, Tx GetWave can just add any DC to 
its output. Tx DLL does not need to know or change DC_Offset.

Regarding your comment "then the Tx output should be centered around the 
x-axis", it's not true. Please see #2 above.

Regarding your comment "then the Tx should remove that DC component from its 
output, and add that value to DC_Offset, so in case someone wants to reproduce 
the real waveform at the output of Rx GetWave, they would be able to "figure 
in" the amount of DC shift that came from the Tx GetWave too...", it's not true 
either. Please see #3 above.

Regards,
Fangyi

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On 
Behalf Of Walter Katz
Sent: Tuesday, July 02, 2019 6:43 PM
To: Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>; 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Question on BIRD197.3


[EXTERNAL]
Arpad,

True, a good Tx design should be able to generate a waveform balanced around 
0V, however there could be some impairments in the Tx (such as saturation on 
high signals) that could distort the waveforms introducing some asymmetry in 
the outgoing channel that an Rx could compensate for.

I think the market will sort this out, and since at least two EDA companies 
have developed DDR5 AMI models that have a DC_Offset. Because of the tolerance 
and non-linearity rules on the value of the VrefDQ register, there is no way to 
predict the NRZ_Threshold, and it is treated as 0 when analyzing Rx GetWave 
output.

If the model maker simulates channel time domain with the voltages adjusted by 
DC_Offset to handle certain non-linearities in the Rx, and if he outputs that 
waveform offset by DC_Offset, it is OK as long as he says the NRX_Threshold is 
~ the same as DC_Offset. It is pretty obvious to me that if the NRZ_Threshold 
is <~ 100mV then it is likely that the EDA tool will need to shift the waveform 
for the user. On the other hand, if the NRZ_Threshold is >~.5V, then its likely 
the EDA tool would know that it does not need to shift the waveform.

Walter





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

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, July 2, 2019 8:27 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Question on BIRD197.3

Walter,

That is the point I was trying to make, the Tx doesn't know any of that.

But if the definition of the channel impulse response is that it is taken
at the Rx die pad, and the Tx GetWave output convolved with the channel
IR is also considered to be the Rx die pad waveform, than the Tx output
should be centered around the x-axis.  Consequently if the Tx had any
internal artifacts which would have added some DC component to the
waveform it received (which was centered on the x-axis), then the Tx
should remove that DC component from its output, and add that value
to DC_Offset, so in case someone wants to reproduce the real waveform
at the output of Rx GetWave, they would be able to "figure in" the amount
of DC shift that came from the Tx GetWave too...

Thanks,

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

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, July 2, 2019 1:55 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>; 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Question on BIRD197.3

Arpad,

And how does the Tx GetWave know how to put in a DC Offset, or any offset at 
all. All it can possibly have is the IR of the channel that was passed into Tx 
AMI_Init. DC_Offset is not an input to the Tx model.

Walter

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

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, July 2, 2019 2:30 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Question on BIRD197.3

Hello Everyone,

I noticed something while reading the BIRD.

The definition makes the following statement:

"The mean value of the steady state high and low voltages of the channel at the 
Rx pad."

Notice that this basically says that the DC_Offset is defined as the DC 
component of the
waveform at the Rx die pad.  This makes sense, because the channel impulse 
response
we pass into the AMI simulation (Tx Init) is based on the waveform at the Rx 
die pad.

Now, the problem I see is that in the GetWave flow the Rx GetWave function gets 
the
output waveform of the Tx GetWave function (convolved with the channel IR).  I 
don't
see anything in the spec that Tx GetWave has to return a zero DC component 
waveform.
In our discussions it was even said that the Tx GetWave is allowed to return a 
waveform
with a DC component.

But ask ourselves the question:  What does the waveform coming out of the Tx 
GetWave
and convolved with the channel IR represent?  As far as I can tell, that 
waveform is the
equivalent of the Rx die pad waveform.

So I see a conflict here.  The DC_Offset parameter defines the Rx die pad 
waveform as
a zero DC component waveform, but at the same time we allow the Tx GetWave 
function
to produce a waveform WITH a DC component.  I think the definition of this 
DC_Offset
parameter implies that the Tx GetWave output must have NO DC component, but we
don't say that anywhere.

Or is my thinking flawed somewhere?

Thanks,

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

PNG image

JPEG image

Other related posts:

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