[ibis-macro] Re: Unanswered question from last week.
- From: David Banas <DBanas@xxxxxxxxxx>
- To: Walter Katz <wkatz@xxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 16 Apr 2014 20:13:13 +0000
Thanks, Walter.
-db
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, April 16, 2014 11:13 AM
To: David Banas; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Unanswered question from last week.
David,
I see your point. And yes I agree that there should be a reserved parameter
that puts the Tx in Manual, Auto and Co-Optimization mode:
(Tx_Optimization_Mode (List "Manual" "Auto" "Co-Optimize") (Usage In) (Type
String) (Description
"Manual: Tx Equalization will be based on Tx parameter inputs
AMI_Init will not alter the Tx equalization
AMI_GetWave will not alter the Tx equalization
Auto: Tx Equalization will be based on impulse response
input to AMI_Init
AMI_GetWave will not alter the Tx equalization
Co-Optimize Initial Tx Equalization will be based on Tx parameter inputs
AMI_Init will not alter the Tx equalization
AMI_GetWave will alter the Tx equalization based on inputs to AMI_GetWave"))
Walter
From: David Banas [mailto:DBanas@xxxxxxxxxx]
Sent: Wednesday, April 16, 2014 1:40 PM
To: Walter Katz; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Unanswered question from last week.
Likewise.
-db
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, April 16, 2014 10:05 AM
To: David Banas; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Unanswered question from last week.
David,
See my responses below.
Walter
From: David Banas [mailto:DBanas@xxxxxxxxxx]
Sent: Wednesday, April 16, 2014 12:35 PM
To: Walter Katz; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Unanswered question from last week.
Hi Walter,
Thanks for your response.
Please, see my replies in-line, below.
Thanks,
-db
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, April 16, 2014 4:34 AM
To: David Banas; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Unanswered question from last week.
David,
Suppose a user sets up a simulation with Tx tap coefficients -.15,.85,0. for
taps -1, 0 and 1 respectively.
[David Banas] Ok.
And then suppose the Tx AMI_Init function changed the tap settings to
-.2,.75,-.05.
[David Banas] I will suppose no such thing. If the user has manually set tap
weights, then he is operating the model in "manual" mode and there should be no
danger of the model changing anything without his knowledge. In the scenario I
was proposing, the user is in complete control of how the Tx model operates. If
he wants to set the taps himself, he uses "manual" mode; if he wants the Tx
model to take a SWAG at it, he uses "auto" mode; if he wants the Tx to
participate in some sort of co-optimization training algorithm, he puts it in
that mode, etc.
<WMK> Exactly so. The Tx model needs a method to be in Manual or Auto Mode. I
claim that Manual mode is the same as co-optimization mode, the Tx model is
told what to do - either by the user selecting tap values or the Rx model
selecting tap values.
[David Banas] I disagree. I believe, at least, three modes are required. I
don't think my users would appreciate putting my model in "manual" mode, only
to find out that the EDA tool thought it knew better and instructed the model
to change the tap weights the user had set. If the user directs the model to
operate in "manual" mode, then it better operate in manual mode.
There is no requirement in the spec that the Tap parameter be an InOut, so if
it was an In, how does the user know that the tap coefficients have changed?
And if they have changed, what have they changed to? How does the user know how
to program his BIOS to optimize the operation of the channel?
[David Banas] Although I have no objection to changing the type of the tap
weight parameters to InOut, I suppose he could read the simulation log. It
might be reasonable to expect that a model which exerts any control over the
tap weights be expected to report their final values in the msg parameter of
the AMI_Init() call, for instance.
<WMK> We should use (Usage InOut), this is exactly what InOut was designed for.
The EDA tool needs to know how the Tx is changing Tap Index or Tap
Coefficients. This will become evident when I will show how the flows I
described in the last slide of Tuesdays presentation. For example, the Rx may
choose a specific set of Tx tap coefficients, but the Tx DLL will need to
determine what Index setting are closest to these coefficients, and then
determine the actual tap coefficients that the Tx can use.
[David Banas] As I said, I have no objection to the tap weights being of type
InOut.
Even if the Tap was InOut, and it reported to the user what the change was the
user is going to get a performance result using -.2,.75,-.05. which will give
him a more open eye at the input to the Rx but a worse eye at the output of the
Rx.
Your response, very importantly, included the following "and if the user has
opted to NOT use the Tx model 'co-opt' mode, but rather to use some 'auto'
feature of the Tx model". So you are saying that the Tx model NEEDS a 'auto
feature that can be turned on and off.
[David Banas] Nope. I'm saying that, if the Tx model happens to offer such an
operational mode to its user as a convenience, then its only obligation is tell
the user what tap weights it set, not the tool.
<WMK> The DLL tells the user through the tool. To support the various flows in
the last slide of Tuesday's presentation the Tx DLL must communicate with the
tool. For example, for PCIe time domain co-optimization, the Tx GetWave must
tell the Rx GetWave what the tap coefficients are in order for the Rx GetWave
backchannel to recommend a changed set of tap coefficients. Note that 802.3KR
backchannel sends increments to the taps, while PCIe sends tap coefficient
values.
[David Banas] You're tending to collapse each one of these points into the
co-optimization context. Please, stay aware that there are, at least, 3
different modes of operation we need to support, going forward:
1. "Manual" - The user selects that tap weights, and nothing else should
change them.
2. "Auto" - Some convenience feature in the model helps the user choose
the tap weights, based solely upon the channel impulse response. No
co-optimization is assumed or supported.
3. "Co-optimize" - The Tx model supports a full-blown co-optimization
protocol, accepting tap weight adjustment commands from the Rx, via the EDA
tool, and reporting back its tap weights to the Rx, via the EDA tool. (The term
"tap weights", as used here, is intended to be generic; it could mean: index,
increment, value, etc.)
This is exactly what I said when I said for Redriver Tx and for Tx involved in
co-optimization.
[David Banas] But, I'm suggesting that an "auto" mode might have utility for
the user, completely outside of any re-driver or co-optimization context. It
might just be a nice convenience feature model makers add, in order to assist
their users "narrow the parameter space". And let's, please, be careful about
potentially legislating away a model maker's ability to provide such a
convenience.
<WMK> Many Rx models today have manual and auto settings. There are very few Tx
models that have an auto capability, and the one that I am aware of does not
have a switch to turn it on or off. If a Tx model is going to support
backchannel and co-optimization, and if it has an auto/manual capability, the
user (or tool) needs to be able to be able to set the model to manual. If we
want the tool to do this automatically we do need to legislate a standard way
of setting auto/manual.
[David Banas] Then, let's make sure we provide the user of a Tx model a way of
indicating to the EDA tool that he actually wants the Tx model to take part in
co-optimization. Let's not allow the EDA tool to presume that it knows better
than the user how the Tx model should be used. Let's have a third option for
the operational mode of the Tx, "co-opt.", so that, if the user sets the Tx to
"manual" mode, he can actually count on it operating in manual mode. That is,
he can actually count on nothing else altering the tap weights he has selected.
I suggested a reserved parameter to turn the Tx self-optimization on and off.
So we either force the user to read the Tx Model users guide to figure this
out, or use a reserved parameter. In any case I believe the user should control
this, and not leave it solely up to the Tx model to make this decision as you
suggested in your question.
[David Banas] On this point (i.e. - The user should be in control of how the
model operates.), I think we're in violent agreement.
<WMK> I agree, but if the user is requesting backchannel or co-optimization
then we should make it reliable that the Tx be put into "manual" mode
automatically. I will be proposing one way to do this next week, but there may
be other ways as well. If we were talking about controlling the Rx the problem
is very complicated, but for Tx the problem is very simple since there is only
one IC vendor that I am aware of that is delivering Tx models that do this.
[David Banas] So, I agree with the first half of your first sentence (the
important part being, "if the user is requesting..."), and completely disagree
with the second half. The Tx should never be put into a mode the user did not
intend. If the user wants the Tx to participate in co-optimization, then he
will put the Tx into "co-optimization" mode. If he wants manual control of the
tap weights, then he will put the Tx into "manual" mode and set the tap
weights. And, if he does this, he certainly doesn't want the EDA tool thinking
that it knows better than him and pulling the Tx model out of "manual" mode and
putting it into "co-optimize" mode. If he wants the Tx to participate in
co-optimization, he will say so.
Walter
From: David Banas [mailto:DBanas@xxxxxxxxxx]
Sent: Tuesday, April 15, 2014 5:17 PM
To: Walter Katz; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Unanswered question from last week.
I think my original question is more true to my intended inquiry, than either
alternative you propose.
And, understand that the case I'm envisioning is one in which the user doesn't
want EDA tool driven co-optimization to occur. (Otherwise, he'd do that.)
In such an instance, and if the user has opted to NOT use the Tx model 'co-opt'
mode, but rather to use some 'auto' feature of the Tx model, in which that
model chooses the optimum FIR coefficients based solely upon the channel
impulse response and not expecting to take part in any Tx/Rx co-optimization,
why must the Tx AMI_Init() function alert the EDA tool that it has done so?
(Mike M., that is what you were suggesting; right?)
Thanks,
-db
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, April 15, 2014 1:29 PM
To: David Banas; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Unanswered question from last week.
David,
Your statement is not quite correct. I think the statement should be:
Why must the Tx .ami file tell the EDA tool, if it assisted the user in
choosing "optimum" tap weights?
or
Why must the Tx .ami file tell allow the EDA tool to tell the Tx AMI_Init() to
assist the user in choosing "optimum" tap weights?
The reason for letting the EDA tool know what the Tx AMI_Init() function is
doing (or controlling what the Tx AMI_Init() function is doing is important in
co-optimization, particularly in the statistical flow. The Rx AMI_Init needs to
know the Tx equalization used to generate the input to the Rx AMI_Init, and
when the Rx AMI_Init returns an optimized Tx tap coefficients, the Tx AMI_Init
function needs to be called with these coefficients, and the Tx AMI_Init must
use the equalization for these tap coefficients.
Does this answer your question?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of David Banas
Sent: Tuesday, April 15, 2014 2:30 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Unanswered question from last week.
Hi all,
I asked a question, at the end of Walter's presentation last week, which I
don't think was ever answered. So, I'd like to ask it, again:
Why must the Tx AMI_Init() function tell the EDA tool, if it assisted the user
in choosing "optimum" tap weights?
(How, for instance, is this use case different than the user relying on, say,
MATLAB to help him find optimum tap weights and setting those MATLAB-prescribed
values in the AMI model, by hand?)
Thanks,
-db
________________________________
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply e-mail,
and delete the message and any attachments. Thank you.
________________________________
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply e-mail,
and delete the message and any attachments. Thank you.
________________________________
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply e-mail,
and delete the message and any attachments. Thank you.
________________________________
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply e-mail,
and delete the message and any attachments. Thank you.
________________________________
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply e-mail,
and delete the message and any attachments. Thank you.
Other related posts:
