Walter, That's true, but you can determine the waveform induced by each aggressor without actually running its DLL, as long as you assume that the aggressor to victim impulse response remains unchanged over time. Typically, Tx behaves more in LTI way compared to Rx. In this case BTW, the convolution becomes much cheaper since one of the participants is piecewise constant. This scenario does not cover adaptive equalization in Tx aggressor, but if you first ran simulation for it, the 'modified' impulse responses could become available as well. Vladimir -----Original Message----- From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Friday, February 18, 2011 9:45 AM To: Dmitriev-Zdorov, Vladimir; kwillis@xxxxxxxxxxx; Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Cross talk columns in impulse_matrix Vladimir, N convolutions if you only had one victim Rx. How would you suggest doing time domain simulations with multiple aggressors without determining the waveform at each aggressor at each victim Rx. Walter -----Original Message----- From: Dmitriev-Zdorov, Vladimir [mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx] Sent: Friday, February 18, 2011 11:31 AM To: Walter Katz; kwillis@xxxxxxxxxxx; Muranyi, Arpad; IBIS-ATM Subject: RE: [ibis-macro] Re: Cross talk columns in impulse_matrix Walter, OK, I see now. This flow presumes that you have to run all N instances of all xtalk aggressors and perform ~N^2 convolutions. Seems very expensive. Vladimir -----Original Message----- From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Friday, February 18, 2011 9:20 AM To: Dmitriev-Zdorov, Vladimir; kwillis@xxxxxxxxxxx; Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Cross talk columns in impulse_matrix Vladimir, The output of the Tx Aggressor waveform is it's stimulus modified by the Tx aggressor equalization. The waveform contribution of this Tx Aggressor at the Rx Victim is this waveform modified by the crosstalk impulse response between the Tx aggressor and the Rx Victim. The actual waveform input to the Rx Getwave needs to include the above waveform from all of the Tx aggressors. Walter -----Original Message----- From: Dmitriev-Zdorov, Vladimir [mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx] Sent: Friday, February 18, 2011 11:04 AM To: wkatz@xxxxxxxxxx; kwillis@xxxxxxxxxxx; Muranyi, Arpad; IBIS-ATM Subject: RE: [ibis-macro] Re: Cross talk columns in impulse_matrix 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