Fangyi, This discussion started yesterday as an exercise, answering a question: “So, there are no "mathematical tricks" one can play in the DLL to account for the absence of the analog buffer model in the impulse response? ” I tried to answer in a positive way showing how the S-parameters can be updated by the DLL. With crosstalk, this operation either becomes more complicated, or requires more calls to the models, depending on the way we choose. In one case, if we have 8 port model describing two coupled channels, it would require adding the 4-port buffer model to just two ports of the 8-port model: not very convenient. But, another approach to handling x-talk is first to decompose the 8 port model into a collection of four 4-port models, each representing the ‘channel’ for a driver/receiver pair, then proceed as before. BTW, your proposal about resolving dependencies by AMI DLL calls is interesting, because nothing like AMI model itself knows the details on how the parameters depend on each other. But, on the other hand, can such resolution be made without letting the model know about something about the channel. Do you think that this hypothetical function should also take non-equalized channel response as an input, and if it does, what it should know about it? Vladimir From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] Sent: Wednesday, December 12, 2012 8:40 PM To: Dmitriev-Zdorov, Vladimir; twesterh@xxxxxxxxxx; gedlund@xxxxxxxxxx Cc: ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL What is the termination of each port of the combined s-parameter? S-parameter alone doesn’t sufficiently describe the analog circuit. We still need to know the termination to calculate impulse response, unless we assume it’s infinite (based on the statement that analog/DLL interface has high impedance). On a separate note, please don’t forget crosstalk. If there are N interfering differential channels, we need a 4N-port S-parameter. The AMI DLL pretty much needs to run a SPICE simulator to combine the analog model into the s4Np. Fangyi From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Dmitriev-Zdorov, Vladimir Sent: Wednesday, December 12, 2012 11:39 AM To: twesterh@xxxxxxxxxx; 'Gregory R Edlund' Cc: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL In an abstract/theoretical way, it is still possible that AMI DLL correctly takes care of the “impulse response” by adding its internal model to it. Then however it should not be an ‘impulse response’, but 2- or 4-port S-parameters representing the core portion of the channel, which does not include analog models. Each model then can ‘append’ its analog part to the S-parameters, and restore the resulting impulse response, if needed for equalization. Instead of returning the updated impulse response, the Init function (or how we call it) will return the updated touchstone file, which then is passed to the Rx model, with the same purpose. The objection here is that Tx must have the complete channel info, with Rx analog model, before its Init function can start thinking about equalization, but then ‘appending’ analog models could be either separated from Init, and organized as one more function, possibly combined with what Fangyi proposed about resolving dependences, or we could still do everything in just one function, but perform a few cycles of Initialization, for example: (Tx_Init(), Rx_Init()), (Tx_Init(), Rx_Init()) … which resembles “backchannel” communication on Init() stage. Of course, the writer of the AMI model must be able to do some operations with touchstone files, such as appending the model to it, and converting it into transfer function, finding impulse response by IFFT, etc. From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Wednesday, December 12, 2012 11:51 AM To: 'Gregory R Edlund' Cc: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL Greg, Ask yourself how the person writing an algorithmic model should accurately model the reflections associated with an unspecified channel. If there’s a way to do that, I’d like to hear about it. Todd. Todd Westerhoff VP, Software Products Signal Integrity Software Inc. • www.sisoft.com<http://www.sisoft.com> 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 (978) 461-0449 x24 • twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx> “I want to live like that” -Sidewalk Prophets From: Gregory R Edlund [mailto:gedlund@xxxxxxxxxx] Sent: Wednesday, December 12, 2012 1:41 PM To: Todd Westerhoff Cc: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: Re: [ibis-macro] Analog Buffer Model Inside DLL Todd, Thanks for the response. So, there are no "mathematical tricks" one can play in the DLL to account for the absence of the analog buffer model in the impulse response? You can tell I haven't taken enough time to think this through all the way. I'm having a knee-jerk reaction to a discussion that's going on internally. 8-) I'm about to dig into the IBIS 5.1 flow material to support my position. I just wanted to make sure I had my ducks in a row and get some outside corroboration. Anyone else care to chime in? Greg Edlund Senior Engineer Signal Integrity and System Timing IBM Systems & Technology Group 3605 Hwy. 52 N Bldg 050-3 Rochester, MN 55901 [Inactive hide details for Todd Westerhoff ---12/12/2012 12:31:11 PM---Greg, That is not possible. The analog model, by definiti]Todd Westerhoff ---12/12/2012 12:31:11 PM---Greg, That is not possible. The analog model, by definition, interacts with the channel and must be From: Todd Westerhoff <twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx>> To: Gregory R Edlund/Rochester/IBM@IBMUS Cc: "ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>" <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>> Date: 12/12/2012 12:31 PM Subject: Re: [ibis-macro] Analog Buffer Model Inside DLL ________________________________ Greg, That is not possible. The analog model, by definition, interacts with the channel and must be included in the impulse response. The equalization, also by definition, is considered to be electrically isolated from the channel and is thus represented in the DLL. Putting the analog model in the DLL violates a fundamental assumption of IBIS-AMI. You may get good-looking results, but they will be invalid. Todd. -- Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx> www.sisoft.com<http://www.sisoft.com/> “I want to live like that" -Sidewalk Prophets On Dec 12, 2012, at 1:13 PM, Gregory R Edlund <gedlund@xxxxxxxxxx<mailto:gedlund@xxxxxxxxxx>> wrote: What nasty things are likely to happen if someone puts the analog buffer model inside the DLL? At the very least, the impulse response will be incorrect. Are there any circumstances under which this can work correctly? Greg Edlund Senior Engineer Signal Integrity and System Timing IBM Systems & Technology Group 3605 Hwy. 52 N Bldg 050-3 Rochester, MN 55901