[ibis-macro] Re: Question about cross talk with AMI models
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 25 Jun 2010 21:44:42 -0400
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
<mailto:ibis-macro-request@xxxxxxxxxxxxx>
Subject: unsubscribe
Other related posts:
