[ibis-macro] Re: Tx (dual) > Rx (init only) combo for time domain
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <kwillis@xxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 15 Sep 2010 12:03:58 -0400
Ken,
In summary, it will be legal to have a channel with the Tx and Rx being
independently either Init only, GetWave only, or dual (9 cases). With Dual
models the user/EDA tool can determine whether to use simple flows or value
added flows.
The basic principles for "Model Writers" is as follows:
Tx Init expects as its input the impulse response of the channel.
Tx Init will return the impulse response of the channel modified by the Tx
Equalization if Init_Modifies_Impulse is True.
If Tx Getwave exists:
Tx Getwave expects as its input a digital stimulus waveform.
Tx Getwave will return the stimulus waveform modified by the Tx Equalization
(which may not necessarily be LTI).
Rx Init expects as its input the impulse response of the channel modified by
the Tx Equalization (output of Tx Init)
Rx Init will return its input (output of Tx Init) modified by the Rx
Equalization if Init_Modifies_Impulse is True.
If Rx Getwave exists
Rx Getwave expects as its input the output of Tx GetWave modified by the
impulse response of the channel.
Rx Getwave will return its input modified by the Rx Equalization (and
optionally clock ticks)
The documentation of the Rx model should indicate what the Rx Init function
will do if it just receives as its input the impulse response of the channel
that does not include the equalization of the Tx.
Walter
Walter Katz
303.449-2308
Mobile 303.883-2120
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Ken Willis
Sent: Wednesday, September 15, 2010 11:12 AM
To: IBIS-ATM
Subject: [ibis-macro] Tx (dual) > Rx (init only) combo for time domain
Hi everyone,
Having been shouted down 2 weeks in a row on this, here is my (final)
attempt to express an opinion on this particular problematic combination. I
am concerned the current path we are on will lead to confusion amongst model
developers and users for a long time. Here is my proposal, with some
background first:
There are multiple time domain combinations that include "Rx (init only)":
Tx (init only) > Rx (init only)
----------------------------------------
This is well-defined, so no problem.
Tx (getwave only) > Rx (init only)
-----------------------------------------------
This is also well-defined. Tx (getwave) modifies the bit stream, Rx (init
only) modifies the channel's impulse response, and the 2 get convolved
together, per Arpad's flow charts.
In this combination, if the Rx doesn't optimize its own settings, then this
flow works fine, and is a good reference flow. No problem here either.
But what if Rx does have optimization capabilities? You can't give it the
channel's impulse response modified by the Tx, because the Tx doesn't have
that functionality. So the only reasonable thing to do in this case is turn
off the Rx optimization in the model (typically available, and should be
recommended in the spec) and set whatever programmable settings the Rx has
interactively, or through sweeps or something. So this scenario WILL require
some special handling by the user, no matter what. But note that there is
only 1 flow here for this combination, and is easily understandable /
explainable. This has significant value in and of itself.
Tx (dual) > Rx (init only)
-----------------------------------
Since the Tx is a dual model in this case, either of the first 2
combinations could be utilized by the user. If the Rx performs optimization,
the first one is appropriate to use. If Rx doesn't perform optimization, the
second one can be used. Who decides if the Rx does optimization or not? At
this point, for the sake of simplicity and keeping this a "clarification"
BIRD, my suggestion is that we leave it to the user at this point, and avoid
new Booleans. I think that is reasonable. The user should know what models
they are using and what their capabilities are.
Yes, we will lose some accuracy by using the Tx init functionality vs. Tx
getwave. But seeing that we are still using a simple init-only Rx, this
trade-off is acceptable to me to avoid the added complexity of a special
flow.
True, this doesn't use Tx getwave and have your Rx do optimization at the
same time. But this is no different than the boat you are in with the second
combination above, so NOTHING new here.
What I am against is making up a special flow for this one specific case
(time domain/dual Tx/init-only Rx/Rx does optimization). I think that is the
wrong thing to do in a specification for a reference flow. I think the
reference flow for this problematic combination should be the same as one of
the first 2 well-defined combinations. If a particular EDA tool wants to go
above and beyond and offer a more advanced value-added flow, that of course
should be allowed. But it should an option to do so, and NOT mandated in the
reference flow.
Remember, we got rid of "split" models because they were more complicated
than they were worth. "Dual" models were intended (by me anyway) to mean you
use either the model's getwave or init, but not both together. The flow
currently being considered for this combination violates that idea, and is
overly complicated.
Summary of Proposal
--------------------------------
- No special flows for special cases in the reference flow!
- With a "dual" Tx, user can legally pick either of its 2 functionalities
based on the Rx's functionality
- EDA tools can add their own value-added flow for specific combinations if
they want to
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx <mailto:kwillis@xxxxxxxxxxx>
Other related posts:
