[ibis-macro] Re: Unanswered question from last week.
- From: Walter Katz <wkatz@xxxxxxxxxx>
- To: "David Banas" <DBanas@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 16 Apr 2014 13:05:01 -0400 (EDT)
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
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
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.
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.
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.
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.
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.
Walter
From: David Banas [mailto:DBanas@xxxxxxxxxx]
Sent: Tuesday, April 15, 2014 5:17 PM
To: Walter Katz; 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
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] On Behalf Of David Banas
Sent: Tuesday, April 15, 2014 2:30 PM
To: 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.
Other related posts:
