[ibis-macro] Re: [EXT] Re: DC_Offset BIRD suggested changes

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 27 Aug 2019 15:56:32 +0000

Ambrish,

Thanks for the new draft.  I didn't read it yet, but I want to respond to the
question of contradiction in those two sentences.

Regarding "the other specifies the Out value (value used by EDA tool to 
postprocess) if the DC_Offset is Usage In"
one can say that if the parameter is Usage In, the Out value has to default to
something.  According to your BIRD draft, in this case the default value is the
In value.  This is what I thought to be a conflict with the previous  sentence,
which states that the default value for both In and Out is 0 volt.

Thanks,

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


From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Ambrish Varma
Sent: Tuesday, August 27, 2019 10:45 AM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; 'IBIS-ATM' 
<ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: [EXT] Re: DC_Offset BIRD suggested changes

Arpad,
Thanks for the comments and feedback. I have attached a revised version.

About the contradiction in these statements:

"Both default input and output values of DC_Offset are 0.0 Volt."
"If DC_Offset is  Usage In, the output value of DC_Offset is assumed to be the 
input value of DC_Offset."

These are not contradictory.
One specifies the default value of the In and Out parameters, the other 
specifies the Out value (value used by EDA tool to postprocess) if the 
DC_Offset is Usage In.

Thanks,
Ambrish.

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 12:18 AM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: [EXT] Re: DC_Offset BIRD suggested changes

EXTERNAL MAIL
Ambrish,

Thanks for preparing the new draft for this BIRD.  I have a few comments on it:

The first sentence of the definition and usage rules state the same thing.  This
is repetitious, one of them should be removed.

The following sentence (and the "general tone" of the BIRD) makes me wonder,
is DC_Offset strictly intended to be used for GetWave (TD) simulations ONLY, or
can it also be used for statistical simulation purposes ALSO?:

"This returned value can be added to the Rx AMI_GetWave output waveform by EDA 
tools to form the complete waveform at the Rx algorithmic model output..."

For example, could the DC_Offset value be added to the eye diagram that is the
result of a statistical simulation?  If yes, we should state that, if not, we 
should
state that it is not intended to be used in statistical simulations.

The next two sentences seem to contradict each other:

"Both default input and output values of DC_Offset are 0.0 Volt."
"If DC_Offset is  Usage In, the output value of DC_Offset is assumed to be the 
input value of DC_Offset."

This is not the proper abbreviation for "for example":

"for ex."

it should either be written out, or use the standard abbreviation: "e.g.".  
Also,
I am not sure I understand the "jargon" style in these words:

"CTE or AGC curves"

What "curves" are you talking about?  (Do you mean waveforms, or transfer
function / response curves, etc...)?  If I remember correctly, "volts" should be
lower case "V", but others may need to correct me on that...

Thanks,

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


From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
Sent: Monday, August 26, 2019 10:29 PM
To: Randy Wolff (rrwolff) <rrwolff@xxxxxxxxxx<mailto:rrwolff@xxxxxxxxxx>>; 
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; 'IBIS-ATM' 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>; 
fangyi_rao@xxxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxxx>
Subject: [ibis-macro] Re: [EXT] Re: DC_Offset BIRD suggested changes

Hi Randy,
Thanks for the feedback. Agree with most of your points.
I have added the requested statement for what the output value of the DC_Offset 
will be when it is Usage In. This should make it absolutely clear for both the 
Usage cases.
About your statement on the language "can be added". The BIRD does not require 
the EDA tool to do any particular math using the DC_Offset value (In or InOut). 
The EDA tool will do what the end customer would like the tool to do - with the 
updated, or originally calculated DC_Offset.

I have also made the editorial changes you requested.
The updated BIRD is attached.
Thanks,
Ambrish.

From: Randy Wolff (rrwolff) <rrwolff@xxxxxxxxxx<mailto:rrwolff@xxxxxxxxxx>>
Sent: Monday, August 26, 2019 6:44 PM
To: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; Ambrish Varma 
<ambrishv@xxxxxxxxxxx<mailto:ambrishv@xxxxxxxxxxx>>; 'IBIS-ATM' 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>; 
fangyi_rao@xxxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxxx>
Subject: RE: [EXT] [ibis-macro] Re: DC_Offset BIRD suggested changes

EXTERNAL MAIL
Ambrish, Walter, Fangyi,

I'd like to give some feedback and get clarification on the BIRD proposal from 
Ambrish before the vote in ATM tomorrow.

Ambrish, you have removed NRZ_Threshold from the BIRD.  I am also ok with this, 
since it can be addressed in a separate BIRD.  Also agree with your statement 
from the ATM minutes "NRZ_Threshold could be applicable to all AMI simulations, 
but DC_Offset was for single-ended applications."  Walter also discussed 
potentially not needing NRZ_Threshold at all, instead making the model maker 
shift the waveform output of AMI_GetWave.  We'll need to discuss this idea 
further.

From the model maker's perspective, I do like that the BIRD is very clear about 
what are the responsibilities of the model maker and the EDA tool given these 
statements:

  1.  The output Rx AMI GetWave waveform returned by the AMI model must be 
nominally centered around zero.
  2.  It is the responsibility of the EDA tool to perform any shifting of the 
output waveform.

The default settings of DC_Offset are a little confusing based on the following:

Ambrish, did you remove the statement "If the parameter is defined as Usage In, 
the output value of DC_Offset is accordingly assumed to be 0.0 Volt."  so when 
DC_Offset is Usage In, there is no value for DC_Offset as an output to assume?

I think your intent based on Example 1 is for the default output value of 
DC_Offset to be the input value (for DC_Offset as Usage In).  Fangyi stated 
this in the ATM minutes as well.  Would it be better to state this explicitly 
by adding the statement "If the parameter is defined as Usage In, the output 
value of DC_Offset is accordingly assumed to be the input value of DC_Offset."? 
 The EDA tool still chooses what to do with this value, either to display the 
waveform as-is or with a shift of the input value of DC_Offset.

Radek also noted (documented in the ATM minutes) that the BIRD has the language 
"can be added". Given that the EDA tool chooses whether to use the output (or 
default) value of DC_Offset at all, I'm wondering what's the use of outputting 
DC_Offset.  Only for potentially having the EDA tool display a desired voltage 
shift?


Some editorial feedback on Ambrish's BIRD:

  1.  In Usage Rules, need to change "AMI GetWave" to "AMI_GetWave"
  2.  Should "nominally centered around zero" be "nominally centered around 
zero Volts"?
  3.  Background Information comment on BIRD197.5 will need to be changed to 
reflect actual changes to the BIRD draft from BIRD197.4

Thanks,
Randy


From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On 
Behalf Of Fangyi Rao
Sent: Tuesday, August 20, 2019 12:45 PM
To: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; 'Ambrish Varma' 
<ambrishv@xxxxxxxxxxx<mailto:ambrishv@xxxxxxxxxxx>>; 'IBIS-ATM' 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [EXT] [ibis-macro] Re: DC_Offset BIRD suggested changes

Hi Ambrish,

The BIRD is simple. It basically states that


  1.  Complete waveform at Rx algorithmic model output = Rx GetWave output 
waveform + output value of DC_Offset
  2.  NRZ_Threshold applied to the complete waveform at Rx algorithmic model 
output = output value of NRZ_Threshold + output value of DC_Offset

Which part of it is difficult for you to  understand?

In your Rx model 1 example, you are mixing up input DC_Offset and output 
DC_Offset and setting the default output DC_Offset at input DC_Offset. This is 
confusing. DC_Offset at input and output are totally independent quantities. In 
most cases they are not equal.

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, August 20, 2019 9:40 AM
To: 'Ambrish Varma' <ambrishv@xxxxxxxxxxx<mailto:ambrishv@xxxxxxxxxxx>>; 
'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: DC_Offset BIRD suggested changes


[EXTERNAL]
Ambrish,

I have no problem with your version. I think it is equivalent to mine. In my 
draft the EDA tool has the option to add DC_Offset to the waveform - it does 
not have to. You have taken NRZ_Threshold out, you assume it to be 0.0 V. I am 
OK with that as well. Personally, I have always thought that DC_Offset should 
be In (and not InOut). In our tool we let the user either plot the Waveform 
Output, or the Waveform Output + the input value of DC_Offset. If the model 
does not have DC_Offset at all, we can plot the Waveform Output + "the mean 
value of the steady state high and low voltages of the analog channel step 
response at the Rx pad".

In SerDes ToolBox we will supply examples with DC_Offset as an In, and the 
model will return a Waveform with an NRZ_Threshold = 0. Therefor no need for 
DC_Offset as an InOut or NRZ_Threshold. This is how we will document best 
practices for singled ended signaling.

We are in violent agreement.

Walter

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

From: Ambrish Varma <ambrishv@xxxxxxxxxxx<mailto:ambrishv@xxxxxxxxxxx>>
Sent: Tuesday, August 20, 2019 12:01 PM
To: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; IBIS-ATM 
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: RE: DC_Offset BIRD suggested changes

Thanks Walter.
We believe that this draft is still quite difficult to understand to implement  
or use the DC_Shift in an AMI model. It is still not very clear to us when a 
model needs to do what in order to simply use the DC_Shift value provided by 
the EDA tool.
It is unnecessarily complex and may implicitly imply certain things for the 
model maker (or the EDA tool vendor) that they may not fully understand.

Here are our concerns:


  1.  The fact that the model needs to use the DC_Offset, not just to determine 
the model parameters such as CTE code - but also shift the output waveform is 
not evident from the text.


  1.  When DC_Shift being InOut - this sentence is very confusing:
"If DC_Offset is an InOut, then if the EDA tool adds DC_Offset to the waveform 
at the Rx algorithmic model output to form a complete waveform, then it should 
also add DC_Offset to the value of NRZ_Threshold when analyzing the complete 
waveform."

In this version of the BIRD we are conflating the DC_Shift and the 
NRZ_Threshold values. The NRZ_Threshold is an offset from the actual center and 
is a relative value (should not be an absolute value). The NRZ_Threshold 
defines the sampling point and is valid for all signals. For this reason, we 
suggest that we split this BIRD in two - one for DC_Shift for single ended 
signals (attached) and the 2nd for NRZ_Threshold (will work on later).


  1.  Generally - a proposal always covers the basic default scenario - and our 
most basic scenario has been - EDA tool sends the value of DC_Shift as In, AMI 
model uses it to find internal settings/DFE coeffs. performs GW with waveform 
still centered 'nominally' around zero and sends the waveform to EDA tool which 
takes the waveform and (if needed) shifts it for the user.

Overall. I believe I will have a hard time explaining to a model maker what 
they need to do to use this parameter.

In the attached BIRD we have tried to perform clear division of labor and both 
the model maker and the EDA tool vendor would know what to do with the 
parameter and waveform outputs.

For simplicity's sake - we suggest we should only support model 1. Here are the 
2 examples that I include in the BIRD.

Example 1: the complete waveform at the Rx algorithmic model output ranges 
within [-0.4, 0.6].
DC_Offset is Usage In.
Rx model 1:
*       EDA tool inputs DC_Offset of 0.1
*       Rx AMI_GetWave returns output waveform ranges within [-0.5, 0.5]
*       EDA tool may shift waveform with input value of DC_Offset (0.1)

Example 2: the complete waveform at the Rx algorithmic model output ranges 
within [0.0, 1.0].
DC_Offset is Usage InOut
Rx model 1:
*       EDA tool inputs DC_Offset of 0.5
*       Rx AMI_Init returns DC_Offset of 0.6
*       Rx AMI_GetWave returns output waveform ranges within [-0.5, 0.5]
*       EDA tool may shift waveform with output value of DC_Offset (0.6)

We can discuss these in the ATM meeting today.

Thanks,
Ambrish.


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: Monday, August 19, 2019 6:01 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] DC_Offset BIRD suggested changes

EXTERNAL MAIL
All,

I would like to suggest some changes I made to the DC_Offset BIRD as made in 
the enclosed 197.5 draft 1

The substantive change is to NRZ_Threshold:

The threshold voltage EDA tools use to detect the NRZ logic level in the 
waveform at the Rx algorithmic model output. If DC_Offset is an InOut, then if 
the EDA tool adds DC_Offset to the waveform at the Rx algorithmic model output 
to form a complete waveform, then it should also add DC_Offset to the value of 
NRZ_Threshold when analyzing the complete waveform.

With this change, the NRZ_Threshold will work with the waveform output of Rx 
AMI_GetWave. If the EDA tool adds the Out value of DC_Offset to the waveform, 
then it would add it to NRZ_Threshold. I changed one model, and added a third 
model to example 2. I also change an "is to" to a "can".

Walter

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

JPEG image

Other related posts:

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