[ibis-macro] Re: AMI Flow question in connection with crosstalk
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Sun, 3 Apr 2011 11:41:08 -0700
Casey,
I think your are making a good point I didn't consider.
"In a time domain simulation for a given RX model, all M TX models will
generate a waveform (perhaps including some filtering and/or jitter).
Each waveform will then be combined (for example, through convolution)
with the M IRs representing the transfer between all M TXs and this
particular RX. These M waveforms will then be combined (for example,
through summation) to form the waveform at the input to this particular
RX."
This is certainly possible, but I think it may take quite
a bit of time to achieve. Each aggressor's Tx GetWave will
have to be executed with the same number of millions of bits
as the through channel's Tx GetWave. Doing this at the rate
of a minute or two per million bits for billions or trillions
of bits, times the number of aggressors may be prohibitive...
Thanks,
Arpad
==============================================================
From: Morrison, Casey [mailto:cmorrison@xxxxxx]
Sent: Sunday, April 03, 2011 1:25 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: AMI Flow question in connection with crosstalk
Arpad:
I still do not understand how we have a problem. Let me try to explain
both flows (or at least how I envision both flows to work):
Init-only flow:
Consider a case where the EDA tool is simulating M transmitters (M>1)
and N receivers (N>=1) simultaneously. The EDA tool will call Init for
all M TX models, and for each TX it will provide an impulse_matrix
consisting of N IRs. These N IRs describe the transfer between that
particular TX and all N RXs. Each TX model will modify the IR presented
to it--presumably adding some sort of filtering. The EDA tool will then
call Init for all N RX models, and for each RX it will provide an
impulse_matrix consisting of M IRs. These M IRs describe the transfer
between all M TXs and that particular RX, including any modifications
(i.e. filtering) made by each of the M TXs to their respective IR. Each
RX now has an impulse_matrix that contains:
* Victim TX filtering + thru channel + RX filtering
* Aggressor 1 TX filtering + crosstalk channel 1 + RX filtering
* ...
* Aggressor M TX filtering + crosstalk channel M + RX filtering
For each RX, the EDA tool would generate waveforms corresponding to all
M IRs returned by the RX Init function, it would sum these together, and
this would then represent the signal at the input to that particular RX
model.
GetWave-only flow:
Again consider a case where the EDA tool is simulating M transmitters
(M>1) and N receivers (N>=1) simultaneously. The EDA tool will call Init
for all M TX models and N RX models, but since this is a GetWave-only
flow, the IRs returned by the Init functions will not be used in time
domain simulations.
In a time domain simulation for a given RX model, all M TX models will
generate a waveform (perhaps including some filtering and/or jitter).
Each waveform will then be combined (for example, through convolution)
with the M IRs representing the transfer between all M TXs and this
particular RX. These M waveforms will then be combined (for example,
through summation) to form the waveform at the input to this particular
RX.
Perhaps I'm still missing the point (a very likely possibility).
Regards,
Casey
-----------------------
Casey T. Morrison
Texas Instruments, Inc.
Desk: 214-567-4250
Email: cmorrison@xxxxxx
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Sunday, April 03, 2011 12:45 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: AMI Flow question in connection with crosstalk
Casey,
Let me try to explain by summarizing the two flows (Init only and
GetWave only).
In the Init only flow, we take the channel's impulse response (IR),
feed it to Tx Init, and then to Rx Init. The algorithms in both
Init functions are expected to modify the IR and the result is
expected to represent the result at the output of the Rx. Adding
cross talk complicates this, as follows:
Cross talk comes for an adjacent channel which is driven by another
Tx. This Tx may be a completely different device, but even if it
is an identical device, its parameters (tap coefficients) may be
different from the Tx on the victim line. Now, recall that the
IR is obtained with respect to the EQ turned off in the Tx. So
in order to get the correct amplitudes at the Rx, the Tx filter
must be applied to the IR. This is not only true for the primary
signal, this is also true for the cross talk signal. Since the
aggressor Tx's settings might be different from the victim Tx's
settings, we first have to find out what each Tx settings are.
So even for the aggressor channels we need to run a normal analysis
first to find out what the aggressor Tx settings should be. Once
we know this, we apply that Tx filter to the crosstalk IR and pass
that modified crosstalk IR to the Rx Init. So the "impulse_matrix"
argument of Rx Init will contain the through channel IR modified
by the victim's Tx Init plus the crosstalk channel IR-s modified
by each corresponding aggressor Tx Init.
This works well in the Init only flow, because the Init functions
can get a full impulse response matrix in their "impulse_matrix"
argument and each Init function can modify the through and crosstalk
IR-s.
Now let's consider the GetWave only flow.
With the new flow BIRD, the input to GetWave is a bit pattern,
+/- 0.5 volts (basically an ideal digital waveform where the
only non-ideal feature might be jitter). The Tx GetWave has no
knowledge of any cross talk (or even waveform shape) effects
because the crosstalk IR-s are not passed into it.
The channel's IR is combined with the output of Tx GetWave in
the EDA tool (for example by convolution). True, this IR
matrix may contain crosstalk responses also, but if all the
aggressor's have a GetWave only flow, these crosstalk responses
will not include the filtering effects of the aggressor Tx
models. This is why I believe the crosstalk results will be
incorrect in a GetWave only flow.
This is actually an equivalent of setting Max_Init_Aggressors to
zero in the .ami file (or aggressors=0 in the Init call). So I
would think that if Init_Returns_Impulse=false in the .ami file,
the only logically correct value for Max_Init_Aggressors would be
zero, unless someone writes an Init function that doesn't modify
the through channel but DOES modify the crosstalk channel IR-s.
But if that was expected from Init functions (which could possibly
solve the above GetWave flow problem), we would have to rewrite
the meaning of Init_Returns_Impulse...
Anyone, please correct me if my understanding is wrong...
Thanks,
Arpad
================================================================
From: Morrison, Casey [mailto:cmorrison@xxxxxx]
Sent: Friday, April 01, 2011 11:45 PM
To: Muranyi, Arpad; IBIS-ATM
Subject: RE: AMI Flow question in connection with crosstalk
Arpad:
I'm not sure I understand why this is a problem. If a model has
Init_Returns_Impulse=false, then it's basically declaring that it models
all of its filtering/behavior in the AMI_Getwave function for time
domain simulations. Since all of its behavior is modeled in AMI_Getwave,
then it doesn't matter that the crosstalk impulse responses will not be
modified by the AMI_Init function. The transmitted signal, including any
noise introduced by aggressors, will be provided to the AMI_Getwave
function, which will then modify that signal with filtering, etc. Both
the signal and the noise will be modified by this filtering within the
AMI_Getwave function.
It's possible I'm misinterpreting your concern, so please correct me if
I have.
Regards,
Casey
-----------------------
Casey T. Morrison
Texas Instruments, Inc.
Desk: 214-567-4250
Email: cmorrison@xxxxxx
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, April 01, 2011 10:37 AM
To: IBIS-ATM
Subject: [ibis-macro] AMI Flow question in connection with crosstalk
Hello everyone,
I made an incorrect statement in the Open Forum Teleconference
about this topic, because this was only discussed in private
emails so far. Anyway, here is the summary of the question:
The crosstalk effects of a channel are captured in the crosstalk
impulse responses which are placed into the "impulse_matrix" for
the AMI_init functions. The AMI_Init functions are expected to
modify these impulse responses to include the filtering effects
on the crosstalk impulse responses. Note that the "impulse_matrix"
is not processed by the AMI_GetWave function, its input is a
(single) stimulus pattern which has nothing to do with crosstalk.
True, the EDA tool will convolve the impulse responses of the
channel with the waveforms coming out of Tx GetWave, but if the
Init function doesn't modify these impulse responses, the results
will be incorrect.
The problem is that one of the allowed combinations for how the
building blocks of a device are split between the Init and GetWave
functions is that the Init function doesn't modify the impulse
responses (Init_Returns_Impulse=false).
I wonder whether we need to do anything about this. Should we
eliminate this case from the AMI Flow and require the Init function
to always modify the impulse responses? Or should we require that
if Init_Returns_Impulse=false, the number of aggressors should also
be zero?
Or should all this be left to the knowledge of the model maker
(which might result in a bunch of bad models if they are
inexperienced)?
Thanks,
Arpad
====================================================================
Other related posts:
