Fangyi,
Thanks for confirming that. In that case, I would summarize it this way, with
the assumption
that the goal is to end up with the same results in both cases (i.e. be able to
recover the
physical waveform and the logic levels at the Rx latch):
Approach 1:
- Rx GetWave output = slicer input signal - threshold
- When intended threshold is non-zero, Rx output signal is shifted
considerably from the physical signal at the Rx latch
- Requires that the Rx DLL returns a DC_Offset to the EDA tool in
order to be able to recover the physical signal at the Rx latch
- (NRZ logic level can be detected using the existing
Rx_Receiver_Sensitivity parameter)
Approach 2:
- Rx GetWave output = slicer input signal
- Requires additional threshold parameter (NRZ_Threshold) to be used
by EDA tools when detecting the NRZ logic level at the Rx output
Parameters DC_Offset and DC_for_Statistical are needed in both approaches 1 & 2
Would you agree with this summary? If yes, we need to decide whether:
#1) we want the Rx DLL return a waveform that is centered on the X-axis and make
DC_Offset an InOut so that the Rx DLL can return the amount of shifting it did
to do
that (which, by the way was not my suggestion), or
#2) whether we want the Rx DLL return the physical waveform and add another
parameter, called NRZ_Threshold by which the Rx DLL can tell the EDA tool how to
evaluate the logic level of that waveform.
Thanks,
Arpad
===================================================================
From: Fangyi Rao [mailto:fangyi_rao@xxxxxxxxxxxx]
Sent: Monday, June 17, 2019 5:45 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx
Subject: RE: DC_Offset BIRD197 revision 5
Hi Arpad,
Your observation is correct. If Rx model returns the threshold, then in both
approaches EDA tools can both recover the physical waveform at the Rx latch and
detect the logic level.
Our difference is in the mechanism used by Rx model to return threshold. I
proposed the new parameter NRZ_Threshold considering that we have similar
parameters for PAM4. What you suggested is basically reusing an existing In
parameter and changing its usage to InOut. In theory this parameter doesn't
have to be DC_Offset. It can be any existing parameter of usage In. Both ways
will work. But in your way the naming of DC_Offset gives the impression that
the threshold is at the DC component of the Rx latch signal, which is not
necessarily true as illustrated by the two cases with non-ideal slicer
thresholds in my presentation.
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: Sunday, June 16, 2019 8:49 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: DC_Offset BIRD197 revision 5
[EXTERNAL]
Fangyi,
Thanks for the updated documents.
Regarding the sub-bullets on the last slide for approach 1, wouldn't the EDA
tool be able to reproduce
the physical waveform at the Rx latch if the DC_Offset parameter was an InOut,
and the Rx DLL returned
the amount of shifting it applied to the waveform to push it to be on the
X-axis? In your first sub bullet
you say:
* Rx GetWave output = slicer input signal - threshold
which to me sounds like that the returned DC_Offset is essentially the same
thing as the threshold.
In different words, if the AMI model returned a threshold value in either
approach, the EDA tool could
either recover the physical waveform at the Rx latch (approach 1), or detect
the logic level (approach 2).
If the above is all correct, I think the 5th main bullet is only true if the
BIRD doesn't have provisions for
the AMI model to return the threshold value in approach 1, but if the BIRD
would do that, EDA tool
would be able to reproduce the physical waveform and also detect the logic
level with either approach.
So the EDA tool wants to be able to reproduce the same results regardless of
which approach we take,
then both approaches should have provisions for the Rx AMI model to return the
threshold value
(regardless of what we call it, DC_Offset or NRZ_Threshold).
Or am I missing something?
Thanks,
Arpad
=================================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Fangyi Rao
Sent: Saturday, June 15, 2019 11:42 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] DC_Offset BIRD197 revision 5
Hi All,
Please find in attachment the revision of BIRD197 with the proposed NRZ
threshold parameter as discussed in last week's ATM. I also attached the
updated presentation based on Arpad's suggestions.
Regards,
Fangyi
