Ken, Responses below. It is clear that whoever introduced the crosstalk impulse matrix in February 2007, did not, and seem to still not understand how crosstalk propagates from each Tx to each Rx in a coupled SerDes system. SiSoft has determined the details of the flow that are required to make this happen, and we have documented what we have done to IBIS-ATM, and have verified it works properly based on correlation with real world measurement of several real world manufactured and delivered systems. I believe Fangyi and Vladimir agree with the SiSoft view of this. The responses below are harsh, but are correct. Walter -----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 > I think as with discussion on Tx AMI_Init, the crosstalk columns would need to be modified by their own respective Rx AMI_Init functions (from their own thru channels) to build out the impulse matrix that is provided to the primary, or victim Rx. WMK> This makes no sense to me. 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. 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 include 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. 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