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

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <dmarc-noreply@xxxxxxxxxxxxx>, "'Ambrish Varma'" <ambrishv@xxxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>, <fangyi_rao@xxxxxxxxxxxx>
  • Date: Mon, 26 Aug 2019 18:53:30 -0400 (EDT)

Randy,

 

I agree that if DC_Offset is an In, the EDA tool can add this value of the
DC_Offset to the waveform. 

 

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 Randy Wolff (Redacted sender "rrwolff" for DMARC)
Sent: Monday, August 26, 2019 6:44 PM
To: wkatz@xxxxxxxxxx; 'Ambrish Varma' <ambrishv@xxxxxxxxxxx>; 'IBIS-ATM'
<ibis-macro@xxxxxxxxxxxxx>; fangyi_rao@xxxxxxxxxxxx
Subject: [ibis-macro] Re: [EXT] Re: DC_Offset BIRD suggested changes

 

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

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Office 978.461-0449 x 133

Mobile  720.417-3762



 

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.

 

2.      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).

 

3.      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

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Office 978.461-0449 x 133

Mobile  720.417-3762



 

JPEG image

Other related posts: