[ibis-macro] Re: DC_Offset BIRD suggested changes

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: "'Ambrish Varma'" <ambrishv@xxxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 20 Aug 2019 12:39:47 -0400 (EDT)

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> 
Sent: Tuesday, August 20, 2019 12:01 PM
To: wkatz@xxxxxxxxxx; IBIS-ATM <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:

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