[ibis-macro] Tx (dual) > Rx (init only) combo for time domain
- From: "Ken Willis" <kwillis@xxxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 15 Sep 2010 11:12:02 -0400
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
<mailto:kwillis@xxxxxxxxxxx> kwillis@xxxxxxxxxxx
Other related posts:
