[ibis-macro] Re: Cross talk columns in impulse_matrix > take 2
- From: "Ken Willis" <kwillis@xxxxxxxxxxx>
- To: "'Walter Katz'" <wkatz@xxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 21 Feb 2011 18:52:28 -0500
Hi Walter,
You're right, my last response didn't make sense. My mistake on the
aggressor Rx EQs. They do not come into play here. Let me try again, to keep
the discussion moving. New responses below.
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 Ken Willis
Sent: Monday, February 21, 2011 10:02 AM
To: 'Walter Katz'; Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Cross talk columns in impulse_matrix
Hi Walter,
Responses below.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, February 18, 2011 10:19 AM
To: kwillis@xxxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: RE: [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.
KW > OK, I think your first approach above is saying the same thing as my
original email in this thread, so I believe this part is in general
agreement. This same approach also applies to time domain simulation where
the aggressor Tx's use modified impulse response techniques as well,
correct?
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.
KW > Agreed, the GetWave flow is more straightforward in this case. But
remember also that there could be a combination of Init-based and
GetWave-based EQ going on in the time domain flow. The Tx aggressors for
example could use modified impulse response techniques with Init, while
the main channel uses Tx GetWave. But I don't see a conflict with that.
WMK> Since we all agree that "Use_Init_Output" is being deprecated (we are
no longer supporting models with a combination of Init-based and
GetWave-based EQ going on in the time domain flow) then I think it is
silly for us to try document flows that are going away.
KW > I was referring to the case where the aggressor Tx models were
different than that of the main Tx, where the aggressor Tx models used
AMI_Init for EQ and the main Tx used AMI_GetWave. That is a possible
combination, no?
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.
KW > I am not clear on this last part. The main Tx would have the
impulse_matrix, where the aggressor columns were populated by the
aggressor Tx's, and included the respective EQ effects. So it doesn't seem
that the main Tx would need to modify anything but its own column.
WMK> Please let me know how the Rx Impulse Matrix input can include the
equalization of each of the Tx aggressors without each Tx being able to
modify the impulse response of its aggressivety to the victim Rx Impulse
Matricies.
KW > Yes, the Tx's would have to modify their impulse responses. I was
referring to which columns the "main" Tx would be allowed to modify, before
the main Rx was involved.
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:
- » [ibis-macro] Re: Cross talk columns in impulse_matrix > take 2 - Ken Willis
