Hi Arpad,
One of the intentions of introducing PAM4_UpperThreshold, …,
PAM4_UpperEyeOffset, …, in BIRD175.3, and now PAM_Thresholds and PAM_Offsets in
BIRD 213.1 is for model and EDA tool to capture threshold and offset wandering
dynamically.
Best,
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> On
Behalf Of walter.m.katz@xxxxxxxxx
Sent: Wednesday, June 29, 2022 12:09 PM
To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Question about the PAMn BIRD
CAUTION: This message originates from an external sender.
Arpad,
Comments below.
Walter
Walter Katz
720.417-3762
walter.m.katz@xxxxxxxxx<mailto:walter.m.katz@xxxxxxxxx>
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: Wednesday, June 29, 2022 2:40 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Question about the PAMn BIRD
Hello Everyone,
I ran into a question regarding the PAMn BIRD (213.1), just in time before the
vote.. 😊
The two new parameters “PAM_Thresholds” and “PAM_Offsets” are defined as Usage
Out.
The BIRD doesn’t say whether these values are supposed to be returned by the
AMI_Init
or the AMI_GetWave function. That implies that the model can return these
values from
either of these functions.
WMK>It implies that the model can return these values from both of these
functions.
Since a simulation usually consists of multiple calls to the AMI_GetWave
function, this
opens the door for the model to return a different value from each AMI_GetWave
call.
WMK> And yes it will! As the CTLE, and AGD, and CDR, DFE and FFE adapt, the eye
will change and the thresholds will change. The EDA can track this and display
how these metrics change and particularly how long it takes to stabilize and
how unstable it can be.
Now, put yourself in the position of an EDA tool vendor, trying to build an eye
diagram
and make measurements on it with these parameters changing in each AMI_GetWave
call. Without going into the details, things can get pretty messy very
quickly. Is this
intentional, or was this something we didn’t think about? Should these
parameters be
restricted to be returned by the AMI_Init function only?
WMK> This is the intention of ignore bits, to tell the EDA tool how long to
wait to insure that these metrics have stabilized.
In case this was intentional, here are a few thoughts to think about.
Consider, for example, the threshold values. If the intent is to support
“threshold
wander”, the values returned by each AMI_GetWave would result in a “staircase”
threshold waveform. The width of these “steps” will depend on the block size
the
EDA tool uses for their AMI_GetWave calls. Since the spec doesn’t tell the EDA
tool
what block size they can/should use for the AMI_GetWave calls, it is up to the
tool
how wide these steps become. The results can become quite different between
different EDA vendors’ tools.
WMK> Users of any EDA tool should run that tool with different block size and
plot the behavior of the model over time.
In reality, if anything, the threshold wander would most likely be a continuous
waveform during the entire length of the simulation (waveform). How good is it
to apply stepwise changing thresholds to the waveforms, especially if the
steps are
quite wide (thousands of UIs)?
WMK> As good as it can be! Yes, this is always an limitation of every
simulator. For SPICE simulations, we often have to reduce the .tran step size
to see the behavior of interest.
There are probably many other similar questions that could be raised, and most
of them would also apply to the timing offset parameter too…
WMK> I think I answered all the questions, My answers apply to both the Voltage
Thresholds and Timing Thresholds.
Thanks,
Arpad
========================================================================
