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>
Sent: Monday, August 26, 2019 6:44 PM
To: wkatz@xxxxxxxxxx; Ambrish Varma <ambrishv@xxxxxxxxxxx>; 'IBIS-ATM'
<ibis-macro@xxxxxxxxxxxxx>; 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@01D55C63.EDDB2F20]
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@01D55C63.EDDB2F20]
Attachment:
DC_Offset_08262019.docx
Description: DC_Offset_08262019.docx