[ibis-macro] Re: Cross talk columns in impulse_matrix
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 17 Feb 2011 08:24:27 -0800
Ken,
You are making a good point. The question is how
the impulse_matrix is assembled. If the tool just
takes the modified main response from Tx1, Tx2,
Tx4, Tx5 and puts that into the crosstalk columns
for the victim's impulse_matrix then we can say that
the Tx Init function should not be allowed to modify
any of the crosstalk columns. And I agree that we
should probably mention this approach somewhere in
the spec.
On the other hand, on the Rx3 side the Rx Init should
still be allowed to change the crosstalk columns in
this impulse_matrix, correct? So the spec should be
changed to allow for that. Do you agree?
Regarding crosstalk cancellation, I am not quite sure
how that would work yet in terms of AMI. But this
looks like a new feature, not a specification correction,
so I would think that we should not be concerned about it
for IBIS v5.1.
Thanks,
Arpad
=========================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Thursday, February 17, 2011 9:04 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Cross talk columns in impulse_matrix
Hi Arpad,
Thanks for starting this discussion, and providing the clarifying
picture.
Some of the following is sort of "thinking aloud", with the intent of
helping to reach agreement.
So one thing that we started to talk about is that all the aggressor
Tx's
need to be given their own "thru" channel impulse responses (ex. Tx1 >
Rx1,
Tx2 > Rx2, etc.), so that they can figure out their own tap coefficients
independently. Hopefully this makes sense to everybody. If not, we
should
discuss that point first.
OK, now the impulse_matrix for the receiver of interest, Rx3 in this
case,
needs to be assembled, and given to Tx3. My thinking is that the
aggressor
columns of this matrix need to be populated by the 'modified" impulse
responses from the respective aggressor Tx's. So in your picture, column
2
(coming from Tx1) should be populated by the impulse response for Tx1 >
Rx3
MODIFIED by Tx1 already. I think that is what we need to end up with.
If it is done like this, then we can probably leave the spec as-is,
where a
given Tx only gets to modify the first column (i.e. only get to EQ its
own
thru channel). If so, then we probably just need a simple BIRD that
explains
the assumptions in the paragraph above. That would be a nice short-term
outcome.
Longer term, if necessary, we could consider EQ that includes crosstalk
cancellation, where the Tx (or Rx possibly) would do some modifications
to
the other aggressor columns as well. But I am thinking that this kind of
advanced functionality would probably be in a Rx AMI_GetWave function,
where
it would do real-time signal processing on raw waveforms just like a
real
device does.
If anyone has any feedback or anything else to add to this discussion,
comments are welcome.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, February 15, 2011 6:39 PM
To: IBIS-ATM
Subject: [ibis-macro] Cross talk columns in impulse_matrix
Hello everyone,
According to our discussion in the ATM teleconference today
I would like to start a thread on this email reflector about
the cross talk columns in the impulse_matrix.
I believe we all agree that the restriction on pg. 185 in the
current specification has to be removed:
| The AMI_Init function may return a modified impulse response by
modifying
| the first column of impulse_matrix. If the impulse response is
modified,
| the new impulse response is expected to represent the filtered
response.
| The number of items in the matrix should remain unchanged.
|
| The aggressor columns of the matrix should not be modified.
The question is what should replace it (if anything). The
spec has to have enough information for the model makers and
the EDA vendors so that models would work in the tools reliably,
but we don't want to over-specify things either, otherwise we
may paint ourselves into a corner.
Ken graciously volunteered to start with a BIRD draft, but I
would like to encourage everyone to offer suggestions so we
could solve this problem adequately.
The attachment contains the drawing we used in the ATM
teleconference today to discuss this topic.
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
---------------------------------------------------------------------
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:
