Walter, My response to your previous email must have just crossed this email in ether. I think my reply answers the 2nd question you raised in this message, but if it didn't, please ask again. Thanks, Arpad ================================================================= ________________________________ From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Friday, June 25, 2010 8:00 PM To: Muranyi, Arpad; IBIS-ATM Subject: RE: [ibis-macro] Re: Question about cross talk with AMI models Arpad, You correctly indicated that there was a complete doubling of the impulse matrix, so that old models would not be affected. So my second question. Exactly what Impulse Response goes into the first array (I assume it must be the normal impulse response that the Tx or Rx Init would get in the current flow (i.e. hAC(t) for the Tx, and hAC(t)xhTEI for the Rx). Fangyi described an Rx Model that had a DFE, and there was an optimizing algorithm that he described that would give him just the combined impulse response of the filter and the input impulse response, and not be able to determine the impulse response of the filter alone with. What could be in the second impulse response that would enable this model to return just the hREI of the filter that is required in one of the Opal(tm) flows, and in several of the flows that have GetWave_Exists=True, and Use_Init_Output=True. Walter Walter Katz 303.449-2308 Mobile 720.333-1107 wkatz@xxxxxxxxxx www.sisoft.com -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Walter Katz Sent: Friday, June 25, 2010 8:46 PM To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM Subject: [ibis-macro] Re: Question about cross talk with AMI models Arpad, As I understand it, you are adding an second impulse response after the first impulse response. However, this second impulse response would share the same expected memory locations as the first crosstalk impulse response. Walter Walter Katz 303.449-2308 Mobile 720.333-1107 wkatz@xxxxxxxxxx www.sisoft.com -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad Sent: Friday, June 25, 2010 7:49 PM To: IBIS-ATM Subject: [ibis-macro] Re: Question about cross talk with AMI models Mike, Thanks for your reply. I fully agree that we need to correct ambiguities in the spec, and that the ambiguities should not be used to change the meaning originally intended. This is the very reason I asked the question on this topic. I will have to read the document you sent in the attachment to see if that would help in fixing this part of the AMI spec. In the meantime I am surprised to hear that "As I understand it (and I hope I'm misinformed), there is now a proposal to change the semantics of the AMI interface in a way that would make it no longer possible to perform crosstalk analysis." because I am not aware of any such proposals. Could you please tell me what you are hearing about? Thanks, Arpad =============================================================== ________________________________ From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx] Sent: Friday, June 25, 2010 6:38 PM To: Muranyi, Arpad Cc: IBIS-ATM Subject: Re: [ibis-macro] Re: Question about cross talk with AMI models Arpad- Let's be kind and say that the sentence that concerns you was poorly written. It's vague at best, and, in its vague way, suggests something that is technically incorrect. Crosstalk analysis is an important capability. It's working with existing AMI models, and people are using this capability to do real work. As I understand it (and I hope I'm misinformed), there is now a proposal to change the semantics of the AMI interface in a way that would make it no longer possible to perform crosstalk analysis. If this is the case, I urge the people involved to reconsider. It is true that there have always been errors in the description of crosstalk analysis in the AMI specification, and it's because the people drafting the AMI specification at the time didn't fully understand how crosstalk analysis was going to work. A lot more information is now available (such as our DesignCon2009 paper.) Perhaps now would be a good time to fix those errors. For example, when we were drafting BIRD 104, SiSoft proposed a modification that would allow crosstalk aggressors to have a different data rate from the primary channel. (Document attached.) Given that we don't want to change the function signatures or their semantics, the solution would be a reserved parameter to provide the aggressor data rates. In summary, wherever there is vague language in the spec, we need to clean it up and make it precise. (We did that with clock_ticks, for example.) And there are still technical errors that need to be corrected. We should not, however, attempt to use the presence of vague language to fundamentally change the meaning of the specification. Mike S. On 06/25/2010 05:45 PM, Muranyi, Arpad wrote: Mike, Thanks for your reply. This is what puzzles me: If the Rx Init modifies the entire impulse_matrix with its (linear) filter (like you say), why does the spec say that "The AMI_Init function may return a modified impulse response by modifying the first column of impulse_matrix."? Does this mean that the modified aggressor responses are not supposed to be put into the impulse_matrix? If so, where are the modified aggressor responses supposed to be written or used? Or is this sentence incorrect, and is it supposed to say that "The AMI Init function may return the modified impulse response by modifying the impulse_matrix"? Thanks, Arpad ========================================================= ________________________________ From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx] Sent: Friday, June 25, 2010 5:07 PM To: Muranyi, Arpad Cc: IBIS-ATM Subject: Re: [ibis-macro] Question about cross talk with AMI models Arpad- In general a receiver's Init function should apply the receiver's linear response to the crosstalk impulse responses as well as to the primary channel impulse response; however if the receiver includes DFE, the DFE should only be applied to the primary channel impulse response. We've written a lot of models this way, and it has all worked correctly. We described this is a fair amount of detail in the paper on crosstalk analysis that we gave at DesignCon2009. Of course, this does mean that the EDA tool has to make the correct assumptions. However, the model behavior I've just described is the only behavior that makes any sense. (For those who are confused about modeling DFE in the Init function, please see the paper we presented at DesignCon2008.) Mike S. On 06/25/2010 04:38 PM, Muranyi, Arpad wrote: Hello AMI experts, As I was working on the AMI_flow BIRD, I noticed this sentence in the description of the impulse_matrix (pg. 185): | The AMI_Init function may return a modified impulse response by modifying | the first column of impulse_matrix. Knowing that the first column contains the primary channel's impulse response, and the remaining columns are the aggressor channels' impulse responses, I began to wonder why the Init function is not allowed to modify those impulse responses. I don't recall reading much in the spec about how cross talk is supposed to be handled. Is the AMI_Init function supposed to process the impulse responses of all the aggressors and combine those somehow with the primary channel's modified impulse response? It seems that this should be spelled out in more detail in the spec, otherwise the EDA tool implementation for handling cross talk my be different from how the model maker intended to describe/model the cross talk effects. I would like to hear comments on this, so we could make the necessary clarifications to the spec if needed. 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