[ibis-macro] Re: Cross talk columns in impulse_matrix
- From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- To: <wkatz@xxxxxxxxxx>, <kwillis@xxxxxxxxxxx>, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 18 Feb 2011 09:04:17 -0700
Hi Walter,
I should admit I cannot get through the following sentence:
> Time Domain: The output of the Tx aggressor GetWave has the aggressor
equalization, and the EDA tool convolves this with the crosstalk channel
impulse response to get the crosstalk waveform at the victim Rx pad.
The output from Tx aggressor GetWave is its own waveform, and unlike
Init, GetWave has no other responses or waveforms in its arguments.
Vladimir
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, February 18, 2011 8:19 AM
To: kwillis@xxxxxxxxxxx; Muranyi, Arpad; 'IBIS-ATM'
Subject: [ibis-macro] Re: Cross talk columns in impulse_matrix
Ken,
There are two cases here, statistical and time domain.
Statistical: In order to generate the Rx crosstalk impulse columns, the
EDA tool needs to know what the effect of the aggressor Tx equalization
is
on each of the channel crosstalk impulse responses. This can be done
either by adding these crosstalk impulse responses to the Tx aggressor
Init calls and the Tx aggressor Init modifies each of them, or the EDA
tool needs to de-convolve the Tx aggressor on-column matrix to determine
the Tx aggressor equalization that needs to be applied to the crosstalk
channel impulse responses.
Time Domain: The output of the Tx aggressor GetWave has the aggressor
equalization, and the EDA tool convolves this with the crosstalk channel
impulse response to get the crosstalk waveform at the victim Rx pad.
Bottom line: In statistical flow, we either require the EDA tool do
de-convolution, or allow the Tx Init to have an impulse response matrix,
and the Tx modifies them all by the equalization in the Init.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Friday, February 18, 2011 9:52 AM
To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Cross talk columns in impulse_matrix
Hi Arpad,
I usually see the advanced Rx models using GetWave, so in this case it
would be a moot point. But those Rx GetWave models do react based on the
crosstalk channels as well as its thru channel. So I would have to say
"yes", I agree with you.
One thing that might make sense (more thinking "aloud" here) is that we
could take the convention that an AMI model can modify anything it wants
in the impulse_matrix it is presented with. But we could update the flow
so that the tools behave like this:
- Tx AMI models only get presented with the one-column matrix for their
own thru channel
- Rx AMI models get presented with the full impulse_matrix
This way AMI models don't have to worry about what they can and cannot
modify. The tool flow takes care of what they are given as inputs. Your
thoughts?
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: Thursday, February 17, 2011 11:24 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Cross talk columns in impulse_matrix
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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:
