[ibis-macro] Re: Question about cross talk with AMI models
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 25 Jun 2010 16:48:32 -0700
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:
