Bob,
Thanks for your comments and insight. I fully understand the neatness and
efficiency of optimizing in the Init function instead of the GetWave function.
So I am going to correct my words below from “natural human laziness” to
“desire to do things more neatly and efficiently”… ☺
Whether we are talking about separating Init and statistical IR processing,
or doing things in one or multiple functions is really not the issue either.
The
more I think of this problem, the more I am getting the impression that the
problem is that the flows described in the current spec did not foresee the
more recent modeling techniques coming, such as yours, together with some
of the more complicated channel/device types, such as redrivers, backchannel
optimization and probably a few more future evolutions in the trade. As a
result,
we allow quite a few modeling approaches which don’t all work together in
certain scenarios.
In light of this and the last slide of Walter’s presentation today, the problem
I see is that in the name of backward compatibility we don’t want to change
anything that is in the spec already, but we are also afraid of adding
completely
new capabilities too, because that might take too long to be adopted by EDA
vendors and model makers. I am a little skeptic that a strong recommendation
would be sufficient to encourage people to make dual models, as Walter
proposed it in his conclusion.
In attempt to drive this conversation towards a resolution, I would like to
hear answers/comments from all on this list on the following questions:
Do we agree with Walter’s conclusion that dual models would solve the
redriver flow problems? Is this solution scalable and expandable for multiple
redriver channels and crosstalk, etc…?
Is a “strong preference” verbiage sufficient in the spec to encourage people
to write such dual models? What do we do if we continue getting “problem
models”?
Would we be better off removing the Init_Returns_Impulse and GetWave_Exists
parameters from IBIS-AMI, which is the equivalent of “forcing” model makers
to write dual models?
I am eager to hear your answers…
Thanks,
Arpad
===============================================================
From: Bob Miller (APD) [mailto:bob.miller@xxxxxxxxxxxx]
Sent: Tuesday, May 16, 2017 3:56 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: Re: [ibis-macro] Re: Summary of discussion about BIRD 166.2
Separating Init from statistical processing could clean things up, but I
suspect that ship has already sailed (and sunk).<wink>...
I understand the conundrum imposed by adapt-in-init models like mine. I will
restate a proposal for a new reserved parameter Init_Requires_Impulse (Default
False) which I will happily set True for my legacy models. Perhaps one day I
may actually get a customer complaint about it and have to make the models
dual-tuning. Implementation of BCI models will push things towards GetWave, too.
Probably those of you who have been building sophisticated GetWave-adaptive
models for a while have all the wrinkles worked out, but adaptation, at least
in my rosy world, is more logically structured as a major
"if(tuning_auto){Tune_Model(<model_core>, <impulse_to_tune_to>);}" function in
AMI_Init,in which I create appropriate stimulus on-the-fly from the impulse,
process it through the model_core, learn from it, tweak taps in the model_core
and repeat as necessary. In AMI_GetWave, one must make the tuning function more
of an event-driven affair that retains state across GetWave calls of arbitrary
block_size, etc. Lots of deck-chair-arranging. When everything upstream of the
terminal Rx is LTI and the impulse in is an accurate representation of the
bit-by-bit waveform to be equalized, there is less advantage to tuning in
GetWave and at least some structural perks of doing it in Init,
Regards,
Bob
On Tue, May 16, 2017 at 12:47 PM, Muranyi, Arpad
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>> wrote:
Mike,
I think the real issue is not necessarily that we have multiple functions (Init
and GetWave),
but the “cross function” dependencies and the “communication walls” we have
between
them or the two types of simulations (statistical/bit by bit).
For example, the optimization results in the Init function may be needed in the
GetWave
function, or having to use the IR that is returned by Init in the bit by bit
flow when GetWave
doesn’t exist. One consequence of that is either having to duplicate the
filter algorithms in
both functions, or having to do de-convolution. Naturally, model makers don’t
want to
duplicate (natural human laziness) and the spec allows them to not duplicate.
That results
in the need for de-convolution, but that seems to be problematic numerically.
So I tend to agree with Ken(?) that we need to find a way to reduce the
“degrees of freedom”
so that we eliminate the need for having to do de-convolution. This could
probably be done
in several ways.
We could we could perhaps tighten up the exiting functions and eliminate some
options,
and make some requirements (such as dual models), but our discussions didn’t
seem to
think this would be possible due to backwards compatibility, and existing
models, etc…
This is why I thought, perhaps another approach might help, such as taking out
any
signal processing from Init and have a single function which supports both
statistical and
bit by bit simulations. But you are right, this may not require the use of one
function,
we might be able to achieve the same with multiple functions, as long as we
establish the
rules between them in such a way that doesn’t get in the way of supporting:
statistical only models (IR processing)
bit by bit only models (waveform processing)
models which support both of the above
models which use the IR only for optimization
models which use waveforms only for optimization/adaptation
models which use both the IR and/or the waveforms for optimization/adaptation
So in short, the solution is not necessarily to have a single function. It is
to make provisions
for the necessary information flow between the functions (or the various paths
inside a
function) . However, tweaking the spec with the existing functions may not be
possible,
so we might want to consider new functions/approaches.
Thanks,
Arpad
=====================================================================
From: Mirmak, Michael
[mailto:michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>]
Sent: Tuesday, May 16, 2017 12:46 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>;
IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: RE: [ibis-macro] Re: Summary of discussion about BIRD 166.2
Arpad,
To clarify, is the issue having multiple functions or is it that the Init
function is required and *may* have IR processing in it? In other words, would
keeping “Init” only for initialization and still having separate “statistical”
and GetWave functions reduce or eliminate the problem (rather than having a
single GetWave++ function for signal processing)?
A statistical-only function separate from Init was actually proposed in Dec.
2014, as part of an ATM discussion. Here’s the link (see p. 20ff):
http://www.ibis.org/macromodel_wip/archive/20141209/toddwesterhoff/IBIS-AMI%20and%20Co-optimization/Co-Optimization-IBIS-ATM_9Dec2014.pdf
- MM
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, May 16, 2017 10:38 AM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: Summary of discussion about BIRD 166.2
Hello Everybody,
I have a slightly higher level observation/comment on all this.
To me it seems that the real problem we have is that we allowed signal
processing
in the Init function. As a result we need to deal with the various
combinations of
whether the Init function returns a modified IR or not and whether GetWave
exists or not, and whether GetWave duplicates what the Init function does. This
results in a lot of possible combinations and as we saw it in Walter’s
presentation,
the total number of combinations increases exponentially when we have multiple
channels connected by repeaters.
I think if we made a somewhat radical change and used Init ONLY for what its
name
says, for initialization purposes, and do ALL signal processing in the GetWave
function
(or perhaps a NewName function), we could eliminate a lot of these problems. I
understand that we would still need to make provisions for the statistical and
bit
by bit flows (IR processing vs. waveform processing), but if all of that is
placed into
one function, we would not have the question of whether the same filter bock is
duplicated in two different functions or not. It seems that this “duplicate or
not”
issue is a big part of our problem, and perhaps eliminating that could help us
to
start making some progress in solving the rest of the flow issues (mixing
statistical
or bit by bit flows/models).
Just a thought…
Thanks,
Arpad
===================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, May 16, 2017 7:32 AM
To: RAO,FANGYI (K-USA,ex1)
<fangyi_rao@xxxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxxx>>; Bob Miller (APD)
<bob.miller@xxxxxxxxxxxx<mailto:bob.miller@xxxxxxxxxxxx>>
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: Summary of discussion about BIRD 166.2
Fangyi,
Actually not. I choose to not DOCUMENT a flow when the terminus Rx has a
GetWave and any one of the upstream Rx are Init-Only. The EDA tool need not
discard them, there are numerous flows that the EDA tool can use.
Secondly, any of the upstream Rx can be converted to Dual by the model maker.
What you have proposed in your BIRD is to add IR outputs to the AMI_Init
function so that an EDA tool can implement a proxy AMI GetWave, which as I said
in the previous line the model maker can do as easily in IBIS 6.1 by instead of
adding these IR to the AMI_Init output, storing these IR in the
AMI_model_memory, and implementing an AMI_GetWave which does the trivial job of
convolving these IR with the AMI_GetWave input.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308<tel:(303)%20449-2308>
Mobile 303.335-6156<tel:(303)%20335-6156>
From: RAO,FANGYI (K-USA,ex1) [mailto:fangyi_rao@xxxxxxxxxxxx]
Sent: Tuesday, May 16, 2017 2:56 AM
To: Bob Miller (APD) <bob.miller@xxxxxxxxxxxx<mailto:bob.miller@xxxxxxxxxxxx>>;
Walter Katz <wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>>
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: RE: [ibis-macro] Re: Summary of discussion about BIRD 166.2
Bob,
The revision in BIRD166.3 is asking the EDA tool to discard all the GetWave
functions in the system, including those in your models, if one Init-only model
is present, even for valid combinations of Init-only and dual models.
Regards,
Fangyi
From: Bob Miller (APD) [mailto:bob.miller@xxxxxxxxxxxx]
Sent: Thursday, May 11, 2017 8:03 AM
To: Walter Katz <wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>>
Cc: RAO,FANGYI (K-USA,ex1)
<fangyi_rao@xxxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxxx>>; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: Re: [ibis-macro] Re: Summary of discussion about BIRD 166.2
So I need a bit of clarification:
Does Walter's tweak eliminate Fangyi's objection?
Fangvi?
Regards,
Bob
On Thu, May 11, 2017 at 7:58 AM, Walter Katz
<wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>> wrote:
Fangyi,
I would like to reference what the Redriver/Retimer flow says about the time
domain flow:
Step 7. The simulation platform performs simulation on the upstream channel,
which consists of Tx1, physical channel 1, and Rx1, according to the AMI flow
defined in the specification for channels without Repeaters.
Step 8a. Redriver: The simulation platform uses the signal waveform at the
output end of Rx1’s algorithmic model in step 7, regardless whether Rx1’s
AMI_GetWave exists or not, as the stimulus of Tx2’s algorithmic model,
regardless whether Tx2’s AMI_GetWave exists or not, and performs simulation on
the downstream channel, which consists of Tx2, physical channel 2 and Rx2,
according to the AMI flow defined in the spec for channels without Redrivers.
Step 8b. Retimer: The simulation platform samples the output waveform of
Retimer Rx AMI_GetWave at ½ UI after each clock tick returned by the function,
generates a digital stimulus as the input to Tx2’s algorithmic model,
regardless whether Tx2’s AMI_GetWave exists or not, and performs simulation on
the downstream channel, which consists of Tx2, physical channel 2 and Rx2,
according to the AMI flow defined in the spec for channels without Redriver.
The logic level of the digital stimulus is 1 if sampled value >= Rx1’s
Rx_Receiver_Sensitivity and 0 if sampled value <= •Rx1’s
Rx_Receiver_Sensitivity. If –Rx1’s Rx_Receiver_Sensitivity < sampled value <
Rx1’s Rx_Reciver_Sensitivity, the logic level is unchanged from the previous
bit. The digital stimulus has values of -½ volt for logic 0 and +½ volt for
logic 1.
The flow that Fangyi refers to (highlighted RED) when Tx2 and Rx2 do not have
an AMI_GetWave is on page 178.
Step 6c. If Tx GetWave_Exists is False and Rx GetWave_Exists is False, the
output of Step 4 is convolved with the output of Step 3 by the EDA tool and the
result is passed on to Step 8.
Where
Step 3. The output of Step 2 is presented to the Rx executable model file’s
AMI_Init function and the Rx AMI_Init function is executed. The Rx AMI_Init
function may modify the impulse response or choose to leave it unchanged.
Step 4. The EDA tool produces a digital stimulus waveform. A digital stimulus
waveform is 0.5 when the stimulus is "high", -0.5 when the stimulus is "low",
and may have a value between -0.5 and 0.5 such that transitions occur when the
stimulus crosses 0.
Where does this digital stimulus come from. There is only one digital stimulus
in the Redriver Channel, it is the digital stimulus that is the input to Tx1.
When this stimulus is convolved with the IR output of Rx2 then all works
perfectly well.
Fangyi has represented the meaning of “according to the AMI flow defined in the
spec for channels without Redrivers” as using the non-digital stimulus output
of Rx1 as the waveform to convolve with the output of Rx2 AMI_Init, but the
“spec for channels without Redrivers” call for convolving the output of Rx
AMI_Init with a digital stimulus.
The following corrects step 8a in the existing IBIS 6.1 specification to
clarify that there are two cases for time domain simulations. One with Rx1,
Tx1, Tx2 and Rx2 having an AMI_GetWave, and one with Rx1, Tx1, Tx2 or Rx2 not
having an AMI_GetWave. Note that the time domain flow in the second case will
not include any of the AM_GetWave functions that do exist. Unless Rx1, Tx1, Tx2
and Rx2 are Dual Models any Redriver flow is problematic. It should be noted
that any AMI_Init only model can be enhanced to include an AMI_GetWave. An
alternative solution to this is to enhance IBIS to include additional IR
outputs of AMI_Init that describes the equalization of the model so that the
simulator can implement a proxy AMI_GetWave function when the AMI_GetWave
function does not exist.
Step 8a. Redriver when Tx1, Rx1, Tx2 and Rx2 have AMI_GetWave: The simulation
platform uses the signal waveform at the output end of Rx1’s algorithmic model
in step 7 as the stimulus of Tx2’s algorithmic model and performs simulation
on the downstream channel, which consists of Tx2, physical channel 2 and Rx2,
according to the AMI flow defined in the spec for channels without Redrivers.
Step 8b. Redriver when Tx1, Rx1, Tx2 or Rx2 do not have AMI_GetWave: The output
of Step 4 according to the AMI flow defined in the specification for channels
without Repeaters. is convolved with the output of Step 6a by the EDA tool and
the result is passed on to Step 8 according to the AMI flow defined in the
specification for channels without Repeaters.
Step 8c. Retimer: The simulation platform samples the output waveform of
Retimer Rx AMI_GetWave at ½ UI after each clock tick returned by the function,
generates a digital stimulus as the input to Tx2’s algorithmic model,
regardless whether Tx2’s AMI_GetWave exists or not, and performs simulation on
the downstream channel, which consists of Tx2, physical channel 2 and Rx2,
according to the AMI flow defined in the spec for channels without Redriver.
The logic level of the digital stimulus is 1 if sampled value >= Rx1’s
Rx_Receiver_Sensitivity and 0 if sampled value <= •Rx1’s
Rx_Receiver_Sensitivity. If –Rx1’s Rx_Receiver_Sensitivity < sampled value <
Rx1’s Rx_Reciver_Sensitivity, the logic level is unchanged from the previous
bit. The digital stimulus has values of -½ volt for logic 0 and +½ volt for
logic 1.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308<tel:(303)%20449-2308>
Mobile 303.335-6156<tel:(303)%20335-6156>
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>]
On Behalf Of RAO,FANGYI (K-USA,ex1)
Sent: Thursday, May 11, 2017 3:31 AM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: Summary of discussion about BIRD 166.2
All,
One unanimous agreement reached at the May 9 ATM that is missing in Walter’s
summary is that BIRD166.2 introduces artificial inflation of redirver
nonlinearity (e.g. limiting mode and compression), noise and crosstalks.
BTW, GetWave-only is a model problem but not a flow problem.
Regards,
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, May 10, 2017 5:16 AM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Summary of discussion about BIRD 166.2
All,
Let me summarize the discussion we had on May 9 about BIRD 166.2 by describing
five scenarios, and then some concluding remarks.
Scenario 1, all four AMI models in the Redriver flow (Tx1, Rx1, Tx2, Rx2) are
Init Only models.
The current flow in IBIS 6.1 is flawed because the Rx2 AMI_Init function does
not receive the complete IR input to properly determine its equalization.
There is unanimous agreement that BIRD 166.2 fixes this for statistical
simulations.
Scenario 2, all four AMI models in the Redriver flow (Tx1, Rx1, Tx2, Rx2) are
Dual models.
The current flow in IBIS 6.1 is flawed because the Rx2 AMI_Init function does
not receive the complete IR input to properly determine its equalization.
There is unanimous agreement that BIRD 166.2 fixes this for both statistical
and time domain simulations.
Scenario 3, the Tx1 and Rx1 AMI models are Dual Models and the Tx and Rx2) are
Init Only models.
The current flow in IBIS 6.1 is flawed because the Rx2 AMI_Init function does
not receive the complete IR input to properly determine its equalization.
There is unanimous agreement that BIRD 166.2 fixes the statistical flow, but
the time domain flow remains problematic.
Scenario 4, all four AMI models in the Redriver flow (Tx1, Rx1, Tx2, Rx2) are a
combination of Init Only and Dual models.
The current flow in IBIS 6.1 is flawed because the Rx2 AMI_Init function does
not receive the complete IR input to properly determine its equalization.
There is unanimous agreement that BIRD 166.2 fixes the statistical flow, but
the time domain flow remains problematic.
Scenario 5, one or more of the four AMI models in the Redriver flow (Tx1, Rx1,
Tx2, Rx2) are GetWave Only models.
There is no valid statistical flow.
The conclusion is that BIRD 166.2 is the correct statistical flow when all four
AMI models in the Redriver flow (Tx1, Rx1, Tx2, Rx2) are a combination of Init
Only and Dual models, and is the correct time domain flow when all four models
are Dual Models.
What I believe IBIS should do is:
1. Approve BIRD 166.2
2. Recommend that all four AMI models in the Redriver flow (Tx1, Rx1, Tx2,
Rx2) are Dual Models in order to support Time Domain flow.
* Note that any Init Only AMI model can easily be upgraded by the model
maker to a Dual Model.
1. Enhance IBIS AMI by adding additional IR outputs to the AMI_Init function
that contain the linear (CTLE) and non-linear (DFE) equalization of the model.
(Keysight AMI_Init Enhancement)
Which leads to the following questions:
1. Is the Keysight AMI_Init Enhancement necessary if all AMI Models are
Dual Models?
2. Is it easier for a model maker to implement the Keysight AMI_Init
Enhancement instead of making Dual Models?
3. If a model maker is too lazy to make a Dual Model, will he be too lazy to
implement the Keysight AMI_Init Enhancement?
4. Will the EDA tools that are used by model makers implement the Keysight
AMI_Init Enhancement?
Note that the Keysight AMI_Init Enhancement does not address the problem of
AMI_GetWave only models.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308<tel:(303)%20449-2308>
Mobile 303.335-6156<tel:(303)%20335-6156>
