[ibis-macro] Re: Question about cross talk with AMI models
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Sun, 27 Jun 2010 10:25:50 -0700
Walter,
I am fully aware that this case is not working with current
models which have an optimizer in the Rx AMI_Init function
and I didn't claim that the new flow will produce correct
results with such models. I claim that the new flow will
produce the SAME (incorrect) results with such old models
as the flow in the existing spec does.
The point I am trying to make here is that since the existing
specification's flow doesn't produce correct results with
current models which have such optimization, then there are
either no such usable models out there today, or the models
or the EDA tools in which they produce correct results must
be not compliant with the spec.
If there are no such models out there today, then the new
proposed flow doesn't do any harm by not finding a solution
to make them work correctly, because they don't exist. People
will simply start writing their new models according to the
new flow.
If there are models out there today which produce incorrect
results with the existing or proposed flows, they will have
to be re-written anyway to produce correct results. This
will be made possible with the proposed new flow.
If there are non-compliant models or tools out there today
which work properly with this case with the existing flow,
then those who wrote such models or tools took a risk by
writing non-compliant models or tools. The ATM Task Group's
goal is not to accommodate non-compliant models or tools by
adjusting the specification to what they have implemented.
The goal is to correct the flaws in the specification the
best possible way. I firmly believe that my latest flow
proposal is an elegant solution for the flaws we discovered
in the existing flow because it requires few changes, i.e.
it is simple, while it is also robust, not requiring special
rules, and de-convolution. (Quote from the Opal document,
pg 17: "...it is not possible to remove all of the numerical
artifacts from the deconvolution operation.")
Arpad
==============================================================
________________________________
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Sunday, June 27, 2010 8:06 AM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Question about cross talk with AMI models
Arpad,
Please look as slide "AMI flow #8 - TD simulations with Tx GetWave only"
In the third row of the Tx selector, Tx GetWave Exists is True, Use Init
Output is False, and Tx Returns Impulse is X, since X is do not care, I
which choose X to mean True. In this case the input to Rx Init is
hAC(t). In your new flow, the data in the impulse response that old
models read (data matrix) will not include the equalization of the Tx,
the optimizing Rx will generate a different and an incorrect set of tap
coefficients.
In any case, how is the EDA tool to determine hREI(t) that is used in
the table Data after Rx Init?
I stand by my statement that existing models will work incorrectly in
these new flows, here is just one example.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Sunday, June 27, 2010 3:06 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Question about cross talk with AMI models
Walter,
1) Existing models are hopefully(!) written in compliance with
the existing specification. The graphical representation of the
flow in the existing IBIS-AMI specification was uploaded to the
ATM web site on September 21, 2009. It is slide #1 in the
following file:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20090921/arpadmurany
i/AMI%20flows:%20IBIS%205.0%20and%202009%20Sept%208,15%20proposals/AMI_F
lows.pdf
I hope we all still agree that this flow was flawed regarding
the order of Step 4 and 5, and that we still all agree that
we want it to be corrected as shown on slide #2 for IBIS 5.1.
Now, compare that corrected flow on slide #2 of the above file
with the corresponding slide #10 in the following file (which
is my latest proposal):
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100622/arpadmurany
i/AMI%20Flows%208/AMI_Flows_8.pdf
Aside from the "double input" for Rx AMI_Init and the drawing
style differences, these two flows are identical!
Considering that the second input for Rx AMI_Init is read-only
in my latest proposal, if an existing model doesn't read it,
nothing bad can happen. Also, considering that the data path
through the first input is identical to the flow that is in the
currently existing specification, I would confidently conclude
that old models will work the same exact way in the proposed
flow as they did in the existing flow.
So from the perspective of existing models, the only practical
difference between the flow in the existing specification and
my latest proposal is the order in which the Tx GetWave call
and the EDA tool convolution (Steps 4 and 5 in the existing
reference flow) is executed. Which, by the way, implies that
an existing Rx model which contains an optimization algorithm
will use the wrong impulse response whether it is executed with
the flow in the existing specification or my proposed new flow.
The only way we can get an Rx model's optimizer to work with
the correct impulse response is if we implement my latest flow
proposal.
2) Regarding the "Do not deprecate" rule in IBIS, if I interpret
the text you quoted from the IBIS specification literally,
EVERY SINGLE CHANGE WE MAKE TO THE SPEC CAN ONLY BE A NEW FEATURE,
EVEN IF IT IS ONLY A CORRECTION. Let me explain this with the
flow correction indicated on slide #2 in the first file above.
If we cannot change the order of the Tx GetWave call and the EDA
convolution as it is described in the 5.0 specification today
(i.e. deprecate it) even if it is an honest mistake and incorrect
and we are required to support it for the rest of our lives, than
the only way to change the order of those two steps is to add a
new flow to the 5.1 specification, in addition to what is there
already. THEREFORE THE NEW FLOW CANNOT BE ANYTHING ELSE BUT A
NEW FEATURE.
The problem is that the (assumed) flow is not defined by a keyword
in the IBIS specification, and I am not sure how we could indicate
in a model which flow they are intended to be used with. So if we
were to support the existing flow AND the fixed flow in IBIS 5.1,
we would have to find a mechanism to select between the two flows.
I will leave this exercise to those who are proponents of the
"Do not deprecate" rule to the letter of the law.
3) Having said that, if making any changes to the specification
(even just changing the order between the Tx GetWave call and the
EDA tool convolution) is considered to be a NEW FEATURE, we can
pack up and close up shop based on the decision we made in the
ATM meetings about making only corrections to the specification
and not add new features. I, who made that suggestion, can
certainly testify that this was not my intension, but if that is
how the majority of the people interpret it (based on twisting my
words or the words of the spec around), we can certainly consider
doing that.
4) It is certainly not clear from the existing specification whether
its authors had any intension of supporting optimization in the
AMI_Init function(s), because it is not mentioned anywhere in the
specification as far as I can tell. Looking at the reference flow
of the existing spec in Section 2.3 it doesn't look like people who
wrote that section thought of that scenario because if there was
an optimizer in Rx AMI_Init, it would get the wrong input when Tx
Use_Init_Output=F.
I consider my suggestion of adding that second input to the Rx AMI_Init
function a CORRECTION because I was led to believe in the ATM flow
discussions that the capability of having optimization in the Init
function was part of the original intent in the specification. If
you consider it a new feature and the majority of people agree with
that, I can remove it from the flow diagram. But I have to remind
you that this will bring us back to a flow diagram that is identical
to the one shown on slide #2 of the first file referenced above
(after spending nine months on this) and we will end up with a
flow that will not support optimization algorithms in the Rx
AMI_Init function, even if you don't have any issues doing
de-convolutions, because the Tx Use_Init_Output=F setting doesn't
allow you to give the Rx AMI_Init function the correct input.
5) By the way, the flow associated with the Init_Returns_Filter
Boolean you proposed (slide #3 in the first file referenced above)
would have required more drastic changes to the flow than what
I made in my latest proposal (compare slide #3 in the first file
with slide #10 in the second file reference above). There are
several more convolutions done by the EDA tool, the Boolean
selectors are moved to the right side, new Boolean switches are
introduced. And, that flow would still require de-convolution
with models which don't support the proposed Init_Returns_Filter
switch. I certainly do not consider this a "much simpler solution"
compared with my latest flow proposal... (but who knows, this may
be a subjective opinion).
6) Having reviewed these old slides, I am even more convinced that
my latest flow proposal is the most elegant solution to the problems
we wanted to correct. It makes the least amount of changes to the flow
in the existing specification, it solves the problems we wanted to
solve (including optimization) without introducing any de-convolution,
it doesn't require any new Boolean switches, it doesn't require any
special rules about when to ignore certain Boolean switches, etc...
I hope this will help you to understand the elegance of my latest
proposed flow better, and I certainly hope that you will not get
bogged down by the letter of the law regarding the deprecation
rule and the decision we made in the ATM meetings about addressing
corrections only in order to speed up our progress. I believe that
arguing over those topics at this stage of the progress we made
with the flow diagram delays our progress considerably, and for
this reason I am very surprised and disappointed that you, who
voiced your frustration about others bogging down our discussions
seem to be starting to follow their footsteps now by raising these
types of issues...
Sincerely,
Arpad
======================================================================
________________________________
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, June 25, 2010 8:45 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Question about cross talk with AMI models
Arpad,
Existing Rx models only know about the first one. So you are proposing
that the impulse response that they see and act on depends on the flow
that you selected. Since the optimization done by the Rx is a function
of this impulse response then the optimization done by existing models
in your proposed flows will be incorrect and different then used as
specified in IBIS 5.0.
I quote from Section 2 of IBIS
| Commitment to Backward Compatibility. Version 1.0 is the first valid
IBIS
| ASCII file format. It represents the minimum amount of I/O buffer
| information required to create an accurate IBIS model of common CMOS
and
| bipolar I/O structures. Future revisions of the ASCII file will add
items
| considered to be "enhancements" to Version 1.0 to allow accurate
modeling
| of new, or other I/O buffer structures. Consequently, all future
revisions
| will be considered supersets of Version 1.0, allowing backward
| compatibility. In addition, as modeling platforms develop support for
| revisions of the IBIS ASCII template, all previous revisions of the
template
| must also be supported.
Not only does this proposal violate the IBIS Do Not Deprecate Rule, it
is also an enhancement, and the group made a clear decision not to
consider any enhancements until the major errors in the specification
were corrected. The decision was clear to not consider
Init_Returns_Filter because it was an enhancement, an alternate and much
simpler solution than what you are proposing here.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Friday, June 25, 2010 8:57 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Question about cross talk with AMI models
Walter,
Nope, your understanding is not correct. I may not have
articulated this clearly enough, but my proposal would
take the entire impulse_matrix as we know it today and
make a duplicate (in terms of memory space) for the whole
thing. This includes the primary channel and all of its
aggressors.
The difference between the two (complete) impulse-matrices
is that one contains the data that comes out of the selector
box in my flow diagram drawing and the other one will
always contain the output that comes from Tx AMI_Init.
The first of these is what the filter in the Rx AMI_Init
function will modify (read from it and write back to it
in place) and the second of these is only there to be read
by the Rx AMI_Init function's optimizer (if it has any).
The fact that the second one always comes from the Tx AMI_Init
guarantees that the optimizer will get the modified impulse
response from Tx AMI_Init, so that it can optimize to what
Tx AMI_Init did to the channel impulse response. And the
fact that the first one comes from the selector box on the
flow diagrams guarantees that the impulse response that the
Rx _AMI_Init will modify does not have the Tx AMI_Init
functions modifications if the Tx Use_Init_Output = F,
which is how we can eliminate the need for de-convolution
in this and all other cases.
Please let me know if this is still not clear...
Thanks,
Arpad
=============================================================
________________________________
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, June 25, 2010 7:46 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Question about cross talk with AMI models
Arpad,
As I understand it, you are adding an second impulse response after the
first impulse response. However, this second impulse response would
share the same expected memory locations as the first crosstalk impulse
response.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad
Sent: Friday, June 25, 2010 7:49 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Question about cross talk with AMI models
Mike,
Thanks for your reply. I fully agree that we need to correct
ambiguities in the spec, and that the ambiguities should not
be used to change the meaning originally intended. This is
the very reason I asked the question on this topic. I will
have to read the document you sent in the attachment to see
if that would help in fixing this part of the AMI spec.
In the meantime I am surprised to hear that "As I understand it (and I
hope I'm misinformed), there is now a proposal to change the semantics
of the AMI interface
in a way that would make it no longer possible to perform crosstalk
analysis." because
I am not aware of any such proposals. Could you please tell
me what you are hearing about?
Thanks,
Arpad
===============================================================
________________________________
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Friday, June 25, 2010 6:38 PM
To: Muranyi, Arpad
Cc: IBIS-ATM
Subject: Re: [ibis-macro] Re: Question about cross talk with AMI models
Arpad-
Let's be kind and say that the sentence that concerns you was poorly
written. It's vague at best, and, in its vague way, suggests something
that is technically incorrect.
Crosstalk analysis is an important capability. It's working with
existing AMI models, and people are using this capability to do real
work. As I understand it (and I hope I'm misinformed), there is now a
proposal to change the semantics of the AMI interface in a way that
would make it no longer possible to perform crosstalk analysis. If this
is the case, I urge the people involved to reconsider.
It is true that there have always been errors in the description of
crosstalk analysis in the AMI specification, and it's because the people
drafting the AMI specification at the time didn't fully understand how
crosstalk analysis was going to work. A lot more information is now
available (such as our DesignCon2009 paper.) Perhaps now would be a good
time to fix those errors.
For example, when we were drafting BIRD 104, SiSoft proposed a
modification that would allow crosstalk aggressors to have a different
data rate from the primary channel. (Document attached.) Given that we
don't want to change the function signatures or their semantics, the
solution would be a reserved parameter to provide the aggressor data
rates.
In summary, wherever there is vague language in the spec, we need to
clean it up and make it precise. (We did that with clock_ticks, for
example.) And there are still technical errors that need to be
corrected. We should not, however, attempt to use the presence of vague
language to fundamentally change the meaning of the specification.
Mike S.
On 06/25/2010 05:45 PM, Muranyi, Arpad wrote:
Mike,
Thanks for your reply. This is what puzzles me:
If the Rx Init modifies the entire impulse_matrix with its
(linear) filter (like you say), why does the spec say that
"The AMI_Init function may return a modified
impulse response by modifying the first column
of impulse_matrix."?
Does this mean that the modified aggressor responses are
not supposed to be put into the impulse_matrix? If so,
where are the modified aggressor responses supposed to
be written or used? Or is this sentence incorrect, and
is it supposed to say that "The AMI Init function may
return the modified impulse response by modifying the
impulse_matrix"?
Thanks,
Arpad
=========================================================
________________________________
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Friday, June 25, 2010 5:07 PM
To: Muranyi, Arpad
Cc: IBIS-ATM
Subject: Re: [ibis-macro] Question about cross talk with AMI models
Arpad-
In general a receiver's Init function should apply the receiver's linear
response to the crosstalk impulse responses as well as to the primary
channel impulse response; however if the receiver includes DFE, the DFE
should only be applied to the primary channel impulse response. We've
written a lot of models this way, and it has all worked correctly. We
described this is a fair amount of detail in the paper on crosstalk
analysis that we gave at DesignCon2009.
Of course, this does mean that the EDA tool has to make the correct
assumptions. However, the model behavior I've just described is the only
behavior that makes any sense.
(For those who are confused about modeling DFE in the Init function,
please see the paper we presented at DesignCon2008.)
Mike S.
On 06/25/2010 04:38 PM, Muranyi, Arpad wrote:
Hello AMI experts,
As I was working on the AMI_flow BIRD, I noticed this sentence
in the description of the impulse_matrix (pg. 185):
| The AMI_Init function may return a modified impulse response by
modifying
| the first column of impulse_matrix.
Knowing that the first column contains the primary channel's
impulse response, and the remaining columns are the aggressor
channels' impulse responses, I began to wonder why the Init
function is not allowed to modify those impulse responses.
I don't recall reading much in the spec about how cross talk
is supposed to be handled. Is the AMI_Init function supposed
to process the impulse responses of all the aggressors and
combine those somehow with the primary channel's modified impulse
response? It seems that this should be spelled out in more
detail in the spec, otherwise the EDA tool implementation for
handling cross talk my be different from how the model maker
intended to describe/model the cross talk effects.
I would like to hear comments on this, so we could make the
necessary clarifications to the spec if needed.
Thanks,
Arpad
==================================================================
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
