Arpad, Bob,
I think we need to come up with configurations which guarantee the same
results on all EDA platforms, and are not onerous requirements on the model
maker. This happens when
* Tx are Dual Models
* Repeater/Redriver Rx are Dual Models
* Terminal Rx are either Dual Models or GetWave-Only models
1. Our experience is that all Tx models we have evaluated are well
represented by Dual models, and that the Init flow and GetWave flow
correlate very well.
2. Terminal Rx models that are Init-Only can be easily enhanced by the
model
maker to be Dual models and the Init flow and GetWave flow correlate very
well.
a. The additional IR outputs proposed by Fangyi is an alternative way that
model maker can make these “Dual” models for the purpose of this discussion
since it allows for the EDA tool to generate an accurate proxy AMI_GetWave.
3. Making Repeater/Redriver Rx Dual Models is not as trivial as 1 and 2
because of saturation (compression) that is handled more correctly in the
AMI_GetWave function, but the output of a Redriver Rx AMI_Init is still
useful for input to downstream Rx.
This is all we can hope to accomplish.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, May 17, 2017 3:15 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Summary of discussion about BIRD 166.2
Bob,
While I can see the reasons for your points, the problem is that the
“promise of IBIS-AMI”
about “interoperability” and “flexibility” is starting to fade:
<https://ibis.org/summits/jun10/katz.pdf>
https://ibis.org/summits/jun10/katz.pdf
Not just between different vendors, but it seems even within the same vendor’s
models.
The problem I see is that when a certain model doesn’t work as the user
expects, finger
pointing begins. This usually starts by the customer blaming the EDA
company’s product(s).
The simulation results are wrong, there must be a bug in the simulator. Way
too many
times it turns out that the problem is in the model(s), not the simulator.
So how far should the IBIS specification go in trying to “guide” the model
makers with
rules/restrictions in the direction of making better or more compatible
models? Is it
the job of the spec to do that? Or are we better off not putting any
checks/restrictions
into the spec, and let the model makers/users and EDA vendors deal with the
associated
headaches?
Thanks,
Arpad
=========================================================================
From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx [ <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller
Sent: Wednesday, May 17, 2017 10:11 AM
To: Walter Katz < <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx>
Cc: Ambrish Varma < <mailto:ambrishv@xxxxxxxxxxx> ambrishv@xxxxxxxxxxx>;
IBIS-ATM < <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Summary of discussion about BIRD 166.2
Ambrish-
I would heartily agree that no one should be required to produce dual
(Init_Returns_Impulse) models -- especially Rx models. (I was perhaps
clumsily trying to say just that). I fully understand and appreciate the
concern that some (many) model correlation and accuracy requirements can
make the production of a necessarily misleading Init impulse undesirable.
I think we can agree that it is not necessary to make every model in
IBIS_AMI, created to serve a particular purpose and particular customer set,
play perfectly and accurately with every possible model created by another
maker for another application and customer set. And I think it is perfectly
OK for IBIS to allow incompatible models to exist out there when the model
makers responsible do not expect significant customer need to play well with
the other set. For IBIS to impose significant unnecessary constraints on the
otherwise successful implementations is counterproductive, Business needs
will drive compatibility solutions betwen model makers (e.g you add Init to
a Tx if it is easy to do or I add an option for tuning to spin in GetWave).
There are parts of my own organization that support customers successfully
with GetWave_Exists:False models and see absolutely no reason to ever
implement AMI_Getwave, to my continued amusement. I view AMI_GetWave as
absolutely essential to performing accurate channel analysis on the designs
my models support and, as I am not supporting designs intended for
rebuffered channels, can exploit the upstream LTI'ness to "tune in AMI_Init"
and produce an approximate impulse_out which can be compared to the (more
accurate) GetWave response to ascertain the impairment due to non-LTI
effects -- something our customers (and our own design teams) find extremely
valuable.
I want to impose my constraints on you no more than I think you want to
impose your constraints on me. If we can meet in the middle with some
mutually acceptable accommodation, great!. If not, "good enough". I view
this lively discussion as exploring if "great!" is possible.
Regards,
Bob
On Wed, May 17, 2017 at 8:22 AM, Walter Katz <wkatz@xxxxxxxxxx
<mailto:wkatz@xxxxxxxxxx> > wrote:
Ambrish,
First, if all of the models in an AMI simulation are written as you
describe, and all of the AMI_GetWave models either to adaptation (usually
Rx) or use the AMI parameters set in the call to the AMI Init function, then
your models will work correctly in all EDA tools with the established flow.
Also your models will work upstream of a Broadcom Rx AMI model which does
not do adaptation, as long as the user understands that since the Broadcom
Rx AMI model does not have an “impulse response that is presented to the Rx
AMI_Init function will always than includes the effects of the Tx filter.”
The user will need to be able to set the various Rx AMI parameter (e.g.
peaking filter and DFE tap coefficients) manually.
This is what I meant by all upstream models not being Dual are problematic.
They require the user to sweep the values of the downstream Rx, or for the
EDA tool to figure out what the effective Tx equalization is by doing
special time domains simulations on the Tx AMI_GetWave (as described in
papers we have given at DesignCon 2017).
So your models are perfectly legal, and either limit the use model of a User
of this combinations of models, or puts a burden on EDA tools to handle this
case.
I have not suggested that we impose writing Dual models, I simply defined
the situations where upstream GetWave Only models are problematic. I also
agree that creating Dual Rx models can be difficult, and that GetWave-Only
terminal Rx models must be supported accurately in the standard.
Model makers need to understand the burden that they are putting on both the
users of their models and EDA tools of delivering GetWave-Only AMI models,
and think I accurately demonstrated that burden. I also have experience that
it is not difficult to build Dual Tx AMI models which both the AMI_Init and
AMI_GetWave can be accurately correlated with each other and with data from
both transistor simulation and/or measurements of the Tx silicon.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone <tel:(303)%20449-2308> 303.449-2308
Mobile <tel:(303)%20335-6156> 303.335-6156
From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx [mailto: ;
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> ibis-macro-bounce@xxxxxxxxxxxxx] On
Behalf Of Ambrish Varma
Sent: Wednesday, May 17, 2017 9:40 AM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Summary of discussion about BIRD 166.2
Hi Bob, Arpad,
We produce lot of models for our customers which are faithful to the device.
That is - the device model are Getwave only models. These models are backed
by extensive and expensive correlation work. Because of this work we are
able to stand by our models. We use AMI_Init to truly initialize and pass
parameters to the model. We oppose any effort to arbitrarily impose a
technique of the day on us. That will be impractical, impose enormous cost
on us and our customers. Besides, we will be scrambling to explain and
justify inevitable model inconsistencies that will come by having an
AMI_Init that returns some/part of the equalization and an AMI_Getwave that
includes the comprehensive model that represents silicon.
The IBIS spec clearly states (following the steps in ‘TIME DOMAIN SIMULATION
REFERENCE FLOW’) that if there is an AMI_Getwave in the all the models in
the link – time domain simulations should be an achievable goal (step 6a, pg
178).
We are not saying that there may not be issues with the specification as
is – but I just want to reiterate that if there are AMI_Init function with
Init_Returns_Impulse=True in all the models in the link then one should be
able to perform Statistical or Time Domain Simulation without any issues.
Similarly if there are AMI_Getwave function available and
GetWave_Exists=True in all the models in the link then one should be able to
perform true time domain simulations without any issues *and* without any
other requirements.
Walters slides and subsequent statements from Bob did not appear to
corroborate that.
Nothing in the IBIS Spec prohibits Dual Models – but making them a
requirement will be an unnecessary burden for reasons described above.
I would like to also comment on Bob’s ‘adapt-in-init’ models. This section
in the Spec (TIME DOMAIN SIMULATION REFERENCE FLOW) actually mentions
exactly such models:
‘Note: The Rx executable model file writer should keep in mind that it is
not guaranteed that the
impulse response that is presented to the Rx AMI_Init function will always
include the effects of
the Tx filter. Therefore the Rx AMI_Init function may not be able to
perform accurate
optimization under all circumstances. For this reason, the parameters of
the Rx AMI_Init function
should always default to valid values or have a mechanism to accept
user-defined coefficients and
allow the user to turn off any automatic optimization routines to ensure
successful simulations.’
So – in some sense – this is a model issue that the model maker was already
made aware of. I do not believe we should retro-fit the spec to allow for
existence of such models.
Thanks,
Ambrish.
From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx [ <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller
Sent: Tuesday, May 16, 2017 7:43 PM
To: Muranyi, Arpad < <mailto:Arpad_Muranyi@xxxxxxxxxx>
Arpad_Muranyi@xxxxxxxxxx>
Cc: IBIS-ATM < <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Summary of discussion about BIRD 166.2
I think this is an accurate assessment:
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 [...] 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.
So, What to Do. I suspect we can all agree that there seems to be no
"elegant" solution.
we can
* try to make IBIS-AMI "elegant" by disallowing things that have been in
circulation for quite a while (e.g. models require valid init impulse_in,
models don't implement getwave). Risk fracturing the community w/o broad
consensus.
* try to "patch" the status quo by adding things (per the Keysight
proposal).
* try to identify "canonical" implementations which are indefinitely
supportable and warn about others, e.g when an Init_Requires_Impulse:True
model is downstream of an Init_Returns_Impulse:False model or an
Init_Returns_Impulse=False model is in a statistical simulation or (?) a
GetWave_Exists: False model is in a bit_by_bit simulation. Doesn't mean
IBIS-AMI can't "patch" some of the problematic cases.
I tend to gravitate most to some combination of the last two as opposed to a
major overhaul of What's Allowed, unless the benefits are very compelling.
Regards,
Bob
On Tue, May 16, 2017 at 4:41 PM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> > wrote:
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: ;<mailto:bob.miller@xxxxxxxxxxxx>
bob.miller@xxxxxxxxxxxx]
Sent: Tuesday, May 16, 2017 3:56 PM
To: Muranyi, Arpad < <mailto:Arpad_Muranyi@xxxxxxxxxx>
Arpad_Muranyi@xxxxxxxxxx>
Cc: IBIS-ATM < <mailto:ibis-macro@xxxxxxxxxxxxx> 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: ;<mailto:michael.mirmak@xxxxxxxxx>
michael.mirmak@xxxxxxxxx]
Sent: Tuesday, May 16, 2017 12:46 PM
To: Muranyi, Arpad < <mailto:Arpad_Muranyi@xxxxxxxxxx>
Arpad_Muranyi@xxxxxxxxxx>; IBIS-ATM < <mailto:ibis-macro@xxxxxxxxxxxxx>
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):
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ibis.org_macromodel-5Fwip_archive_20141209_toddwesterhoff_IBIS-2DAMI-2520and-2520Co-2Doptimization_Co-2DOptimization-2DIBIS-2DATM-5F9Dec2014.pdf&d=DwMFaQ&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=0Gavo25Aqgu_F0CPGlNHGxaE1UHA4ptnU3q-kd8FzDQ&m=OlxEdhRioHleWNSS7EkDtQQPM_7374ys4UQFyXZjBi8&s=kdkRIrkkKNr4D_iNCkWjn-gUSdqJRYyupB-IymqG9MU&e=>http://www.ibis.org/macromodel_wip/archive/20141209/toddwesterhoff/IBIS-AMI%20and%20Co-optimization/Co-Optimization-IBIS-ATM_9Dec2014.pdf-
MMFrom:
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>ibis-macro-bounce@xxxxxxxxxxxxx [
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Muranyi, ArpadSent: Tuesday, May 16, 2017 10:38 AMTo: IBIS-ATM <
<mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>Subject:
[ibis-macro] Re: Summary of discussion about BIRD 166.2Hello 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 signalprocessingin the Init function.
As a result we need to deal with the variouscombinations ofwhether the Init
function returns a modified IR or not and whether GetWaveexists or not, and
whether GetWave duplicates what the Init function does.Thisresults in a lot of
possible combinations and as we saw it in Walter’spresentation,the total number
of combinations increases exponentially when we havemultiplechannels connected
by repeaters.I think if we made a somewhat radical change and used Init ONLY
for what itsnamesays, for initialization purposes, and do ALL signal processing
in theGetWave function(or perhaps a NewName function), we could eliminate a lot
of these problems.Iunderstand that we would still need to make provisions for
the statisticaland bitby bit flows (IR processing vs. waveform processing), but
if all of that isplaced intoone function, we would not have the question of
whether the same filter bockisduplicated in two different functions or not. It
seems that this “duplicateor not”issue is a big part of our problem, and
perhaps eliminating that could helpus tostart making some progress in solving
the rest of the flow issues (mixingstatisticalor bit by bit flows/models).Just
a
thought…Thanks,Arpad===================================================================From:
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>ibis-macro-bounce@xxxxxxxxxxxxx [
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Walter KatzSent: Tuesday, May 16, 2017 7:32 AMTo: RAO,FANGYI
(K-USA,ex1) < <mailto:fangyi_rao@xxxxxxxxxxxx>fangyi_rao@xxxxxxxxxxxx>; Bob
Miller (APD) <<mailto:bob.miller@xxxxxxxxxxxx> bob.miller@xxxxxxxxxxxx>Cc:
IBIS-ATM < <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>Subject:
[ibis-macro] Re: Summary of discussion about BIRD 166.2Fangyi,Actually not. I
choose to not DOCUMENT a flow when the terminus Rx has aGetWave and any one of
the upstream Rx are Init-Only. The EDA tool need notdiscard them, there are
numerous flows that the EDA tool can use.Secondly, any of the upstream Rx can
be converted to Dual by the modelmaker. What you have proposed in your BIRD is
to add IR outputs to theAMI_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 inIBIS 6.1 by instead of adding these IR to the AMI_Init output,
storing theseIR in the AMI_model_memory, and implementing an AMI_GetWave which
does thetrivial job of convolving these IR with the AMI_GetWave
input.WalterWalter Katz <mailto:wkatz@xxxxxxxxxx> wkatz@sisoft.comPhone
<tel:(303)%20449-2308> 303.449-2308Mobile <tel:(303)%20335-6156>
303.335-6156From: RAO,FANGYI (K-USA,ex1) [
<mailto:fangyi_rao@xxxxxxxxxxxx>mailto:fangyi_rao@xxxxxxxxxxxx]Sent: Tuesday, ;
May 16, 2017 2:56 AMTo: Bob Miller (APD) <
<mailto:bob.miller@xxxxxxxxxxxx>bob.miller@xxxxxxxxxxxx>; Walter Katz <
<mailto:wkatz@xxxxxxxxxx>wkatz@xxxxxxxxxx>Cc: IBIS-ATM <
<mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>Subject: RE:
[ibis-macro] Re: Summary of discussion about BIRD 166.2Bob,The revision in
BIRD166.3 is asking the EDA tool to discard all the GetWavefunctions in the
system, including those in your models, if one Init-onlymodel is present, even
for valid combinations of Init-only and dual models.Regards,FangyiFrom: Bob
Miller (APD) [
<mailto:bob.miller@xxxxxxxxxxxx>mailto:bob.miller@xxxxxxxxxxxx]Sent: Thursday, ;
May 11, 2017 8:03 AMTo: Walter Katz < <mailto:wkatz@xxxxxxxxxx>
wkatz@xxxxxxxxxx>Cc: RAO,FANGYI (K-USA,ex1) <
<mailto:fangyi_rao@xxxxxxxxxxxx>fangyi_rao@xxxxxxxxxxxx>; IBIS-ATM <
<mailto:ibis-macro@xxxxxxxxxxxxx>ibis-macro@xxxxxxxxxxxxx>Subject: Re:
[ibis-macro] Re: Summary of discussion about BIRD 166.2So I need a bit of
clarification:Does Walter's tweak eliminate Fangyi's objection?
Fangvi?Regards,BobOn 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 timedomain flow:Step 7.
The simulation platform performs simulation on the upstream channel,which
consists of Tx1, physical channel 1, and Rx1, according to the AMIflow defined
in the specification for channels without Repeaters.Step 8a. Redriver: The
simulation platform uses the signal waveform at theoutput end of Rx1’s
algorithmic model in step 7, regardless whether Rx1’sAMI_GetWave exists or not,
as the stimulus of Tx2’s algorithmic model,regardless whether Tx2’s AMI_GetWave
exists or not, and performs simulationon the downstream channel, which consists
of Tx2, physical channel 2 andRx2, according to the AMI flow defined in the
spec for channels withoutRedrivers.Step 8b. Retimer: The simulation platform
samples the output waveform ofRetimer Rx AMI_GetWave at ½ UI after each clock
tick returned by thefunction, generates a digital stimulus as the input to
Tx2’s algorithmicmodel, regardless whether Tx2’s AMI_GetWave exists or not, and
performssimulation on the downstream channel, which consists of Tx2,
physicalchannel 2 and Rx2, according to the AMI flow defined in the spec
forchannels without Redriver. The logic level of the digital stimulus is 1
ifsampled 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 unchangedfrom the
previous bit. The digital stimulus has values of -½ volt for logic0 and +½ volt
for logic 1.The flow that Fangyi refers to (highlighted RED) when Tx2 and Rx2
do nothave an AMI_GetWave is on page 178.Step 6c. If Tx GetWave_Exists is False
and Rx GetWave_Exists is False, theoutput of Step 4 is convolved with the
output of Step 3 by the EDA tool andthe result is passed on to Step 8.
WhereStep 3. The output of Step 2 is presented to the Rx executable model
file’sAMI_Init function and the Rx AMI_Init function is executed. The Rx
AMI_Initfunction may modify the impulse response or choose to leave it
unchanged.Step 4. The EDA tool produces a digital stimulus waveform. A
digitalstimulus waveform is 0.5 when the stimulus is "high", -0.5 when the
stimulusis "low", and may have a value between -0.5 and 0.5 such that
transitionsoccur when the stimulus crosses 0.Where does this digital stimulus
come from. There is only one digitalstimulus in the Redriver Channel, it is the
digital stimulus that is theinput to Tx1. When this stimulus is convolved with
the IR output of Rx2 thenall works perfectly well.Fangyi has represented the
meaning of “according to the AMI flow defined inthe spec for channels without
Redrivers” as using the non-digital stimulusoutput 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 outputof Rx AMI_Init with a digital
stimulus.The following corrects step 8a in the existing IBIS 6.1 specification
toclarify 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
Rx2not having an AMI_GetWave. Note that the time domain flow in the second
casewill 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
shouldbe noted that any AMI_Init only model can be enhanced to include
anAMI_GetWave. An alternative solution to this is to enhance IBIS to
includeadditional IR outputs of AMI_Init that describes the equalization of
themodel so that the simulator can implement a proxy AMI_GetWave function
whenthe AMI_GetWave function does not exist.Step 8a. Redriver when Tx1, Rx1,
Tx2 and Rx2 have AMI_GetWave: Thesimulation platform uses the signal waveform
at the output end of Rx1’salgorithmic model in step 7 as the stimulus of Tx2’s
algorithmic model andperforms simulation on the downstream channel, which
consists of Tx2,physical channel 2 and Rx2, according to the AMI flow defined
in the specfor channels without Redrivers.Step 8b. Redriver when Tx1, Rx1, Tx2
or Rx2 do not have AMI_GetWave: Theoutput of Step 4 according to the AMI flow
defined in the specification forchannels without Repeaters. is convolved with
the output of Step 6a by theEDA tool and the result is passed on to Step 8
according to the AMI flowdefined in the specification for channels without
Repeaters.Step 8c. Retimer: The simulation platform samples the output waveform
ofRetimer Rx AMI_GetWave at ½ UI after each clock tick returned by thefunction,
generates a digital stimulus as the input to Tx2’s algorithmicmodel, regardless
whether Tx2’s AMI_GetWave exists or not, and performssimulation on the
downstream channel, which consists of Tx2, physicalchannel 2 and Rx2, according
to the AMI flow defined in the spec forchannels without Redriver. The logic
level of the digital stimulus is 1 ifsampled 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 unchangedfrom the previous
bit. The digital stimulus has values of -½ volt for logic0 and +½ volt for
logic 1.WalterWalter Katzwkatz@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 AMTo:
IBIS-ATM <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >Subject:
[ibis-macro] Re: Summary of discussion about BIRD 166.2All,One unanimous
agreement reached at the May 9 ATM that is missing in Walter’ssummary is that
BIRD166.2 introduces artificial inflation of redirvernonlinearity (e.g.
limiting mode and compression), noise and crosstalks.BTW, GetWave-only is a
model problem but not a flow problem.Regards,FangyiFrom:
ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter KatzSent: Wednesday, May 10, 2017 5:16 AMTo: IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >Subject:
[ibis-macro] Summary of discussion about BIRD 166.2All,Let me summarize the
discussion we had on May 9 about BIRD 166.2 bydescribing 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 functiondoes not receive the complete IR input
to properly determine itsequalization.There is unanimous agreement that BIRD
166.2 fixes this for statisticalsimulations.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 functiondoes not receive the complete IR
input to properly determine itsequalization.There is unanimous agreement that
BIRD 166.2 fixes this for both statisticaland 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
functiondoes not receive the complete IR input to properly determine
itsequalization.There is unanimous agreement that BIRD 166.2 fixes the
statistical flow, butthe 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 functiondoes not receive the complete IR input to properly
determine itsequalization.There is unanimous agreement that BIRD 166.2 fixes
the statistical flow, butthe 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 allfour AMI models in the
Redriver flow (Tx1, Rx1, Tx2, Rx2) are a combinationof Init Only and Dual
models, and is the correct time domain flow when allfour models are Dual
Models.What I believe IBIS should do is:1. Approve BIRD 166.22. Recommend
that all four AMI models in the Redriver flow (Tx1, Rx1, Tx2,Rx2) are Dual
Models in order to support Time Domain flow.a. Note that any Init Only AMI
model can easily be upgraded by the modelmaker to a Dual Model.3. Enhance
IBIS AMI by adding additional IR outputs to the AMI_Init functionthat contain
the linear (CTLE) and non-linear (DFE) equalization of themodel. (Keysight
AMI_Init Enhancement)Which leads to the following questions:1. Is the Keysight
AMI_Init Enhancement necessary if all AMI Models areDual Models?2. Is it
easier for a model maker to implement the Keysight AMI_InitEnhancement instead
of making Dual Models?3. If a model maker is too lazy to make a Dual Model,
will he be too lazy toimplement the Keysight AMI_Init Enhancement?4. Will the
EDA tools that are used by model makers implement the KeysightAMI_Init
Enhancement?Note that the Keysight AMI_Init Enhancement does not address the
problem ofAMI_GetWave only models.WalterWalter Katzwkatz@xxxxxxxxxx
<mailto:wkatz@xxxxxxxxxx>Phone 303.449-2308 <tel:(303)%20449-2308>Mobile
303.335-6156 <tel:(303)%20335-6156>
