Casey, Your analysis for the GetWave-only flow is correct. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Morrison, Casey Sent: Sunday, April 03, 2011 2:25 PM To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM Subject: [ibis-macro] 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 ====================================================================