James, I don’t believe that IBIS 5.1 assumes any of 5 ideal impedance conditions listed on slide 7. I believe that some people interpret the spec this way, but it’s precisely that interpretation of the spec that I’m asserting is incorrect. Todd. Todd Westerhoff VP, Software Products Signal Integrity Software Inc. • www.sisoft.com 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 (978) 461-0449 x24 • twesterh@xxxxxxxxxx “I want to live like that” -Sidewalk Prophets From: James Zhou [mailto:james.zhou@xxxxxxxxxx] Sent: Sunday, December 16, 2012 5:42 AM To: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL Hi Todd, the responses are entered after your original comments/questions for easy viewing. James ----------------------------------------------------------------------------------------------------------------------------------------------------------- Todd: Let’s say there’s a significant capacitance at the RX die pad. I get where the “edge rate rolloff” in the forward direction can be included in the algorithmic model. However, in the physical circuit, a negative reflection occurs at the RX package/die boundary, sending energy back into the network, where it can hit other discontinuities and reflect again (forward this time), adding ISI some number of bit times later. James: This is a good example to continue the discussion. Todd: In the scheme proposed, the interaction of the RX die capacitance and the network has been eliminated, because the RX analog model was idealized. As a result, there is no reflection from the RX pad in the impulse response from Network Characterization. James: The proposed scheme rigorously solves the cascaded network without any systematic errors (see attached for details). Todd: Do we agree that this is a real physical effect that needs to be included in the analysis? If so, it needs to be modeled somehow. James: Agree completely. The proposed solution (attached) does exactly that. Todd: In the proposed scheme, it’s up to the algorithmic model to add the effect of the RX pad reflection back into the analysis. The only thing the RX algorithmic model has to work with is the impulse response, itself an amalgam of the TX analog output characteristics, TX equalization and the interconnect network. It tells how energy is transferred from the TX voltage source to the RX pad, but nothing about what happens to any energy reflected back into the network from the RX. That part of the network model has been discarded by this point in the analysis. James: In the proposed scheme, all Rx pad reflections are properly and rigorously treated by the cascading equations, which are computed by the EDA tool at simulation time. Please see attachments for details. Todd: So, given that the RX algorithmic model has no information about what happens to any energy the RX reflects back into the network, how can the algorithmic model account for reflection-based ISI? James: The Rx reflection was computed at simulation time by EDA tool. The Rx AMI model does not need to do anything on impedance mismatch. ----------------------------------------------------------------------------------------------------------------------------------------------------------- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Friday, December 14, 2012 1:00 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL James, Thanks for your reply. Here’s what I still don’t get: Let’s say there’s a significant capacitance at the RX die pad. I get where the “edge rate rolloff” in the forward direction can be included in the algorithmic model. However, in the physical circuit, a negative reflection occurs at the RX package/die boundary, sending energy back into the network, where it can hit other discontinuities and reflect again (forward this time), adding ISI some number of bit times later. In the scheme proposed, the interaction of the RX die capacitance and the network has been eliminated, because the RX analog model was idealized. As a result, there is no reflection from the RX pad in the impulse response from Network Characterization. Do we agree that this is a real physical effect that needs to be included in the analysis? If so, it needs to be modeled somehow. In the proposed scheme, it’s up to the algorithmic model to add the effect of the RX pad reflection back into the analysis. The only thing the RX algorithmic model has to work with is the impulse response, itself an amalgam of the TX analog output characteristics, TX equalization and the interconnect network. It tells how energy is transferred from the TX voltage source to the RX pad, but nothing about what happens to any energy reflected back into the network from the RX. That part of the network model has been discarded by this point in the analysis. So, given that the RX algorithmic model has no information about what happens to any energy the RX reflects back into the network, how can the algorithmic model account for reflection-based ISI? Am I still missing something? Thanks! Todd. Todd Westerhoff VP, Software Products Signal Integrity Software Inc. • www.sisoft.com 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 (978) 461-0449 x24 • twesterh@xxxxxxxxxx “I want to live like that” -Sidewalk Prophets From: James Zhou [mailto:james.zhou@xxxxxxxxxx] Sent: Friday, December 14, 2012 3:31 PM To: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: Analog Buffer Model Inside DLL Hi Todd, My reading of Greg's original question is that only the on-chip (or possibly also on package) analog components would be included in the DLL. In this situation, the model creator knows which S-parameter (or any other format chosen by model creator) file to use under a given set of AMI parameters. It does not need to be passed in the AMI function calls. They are "logistically internal" to the model (they are likely to be some external files shipped with and managed by the DLL). Once the response of these on-chip analog circuitry are included in the DLL, they will not be included in the channel impulse response (which might be a real scary thing to do). However the S-parameters of the external channel network will still be processed by the EDA tool. As scary as it may sound, this practice actually makes things much easier and clear for all parties involved. It does not invalidate anything in IBIS 5.1, it only requires a small but important enhancement in IBIS 5.1 to allow the waveform generator (aka AMI block) to have arbitrary output impedance, most likely provided in a snp file (which data is already available in existing models) In IBIS AMI the signal source (aka AMI block) is most often considered as the digital block or some sort, but as Walter often says " a nose by any other name still smells" , the waveform generator (aka signal source, aka AMI block) could be anything as long as it provides an output waveform UNDER A KNOWN LOADING CONDITION. It is a standard practice in network cascading to have arbitrary known loading conditions at network interfaces . It is neither necessary nor beneficial to impose any restrictions on the input/output impedances of the network components. My recommendations are the following: (1) REMOVE THE RESTRICTIONS ON THE OUTPUT IMPEDANCE OF THE WAVEFORM GENERATOR (aka the DLL block) , AND ALLOW IT TO HAVE ANY KNOWN OUTPUT IMPEDANCE SUPPLIED IN A SNP FILE. (2) REMOVE THE RESTRICTIONS ON THE INPUT IMPEDANCE OF THE ANALOG CHANNEL (this restriction is caused by the isolation requirement of IBIS 5.1, which should be lifted in future releases) On isolation: Some postings seem to suggest that the signal source (aka AMI block) and the analog channel must be isolated in order to correctly account for the impedance conditions. It's worth noting that isolation is an exceptional and very restrictive condition which is not necessary at all. By lifting this restriction from IBIS 5.1, things will become much clear and easier to understand with little or no burden on implementation. Detailed technical information can be provided if there is any interest to pursue this further. James Zhou From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Friday, December 14, 2012 5:23 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL James, Maybe I’m missing something ... how would the algorithmic model get the S-parameters for the channel network to be cascaded, given that only an impulse response is passed in? Todd. Todd Westerhoff VP, Software Products Signal Integrity Software Inc. • www.sisoft.com 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 (978) 461-0449 x24 • twesterh@xxxxxxxxxx “I want to live like that” -Sidewalk Prophets From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of James Zhou Sent: Thursday, December 13, 2012 6:28 PM To: michael.mirmak@xxxxxxxxx; gedlund@xxxxxxxxxx; mike@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL Considering Greg's original question (put analog buffer inside dll), even though IBIS 5.1 does not support this practice, technically it is a network cascade problem that had been solved time ago in network theory using S-parameters. Although "nasty things" could happen if someone "puts the analog buffer model inside the DLL", it can be easily avoided by the time-tested S-parameter network cascading formula, in which case the impulse response CAN also be made correct. Many of the IBIS AMI models I have seen so far treat the AMI-to-analog interface as perfectly matched (which is referred to as "isolated" in some communications). This makes the network cascading problem easier. However this is only a special case of a more general problem of network cascading with mismatch, which solutions are readily available and can be derived easily using S-parameter theory. I have recently run into a case where the AMI channel simulation generated incorrect amplitude. The EDA tool vendor contributed the cause to misinterpretation of AMI to Tx analog interface impedance in the model. From users point of view, this kind of problems can be very difficult and time-consuming to debug. It would be very helpful to further clarify these issues in the specification by some working examples as Michael has suggested. James Zhou From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael Sent: Thursday, December 13, 2012 11:51 AM To: gedlund@xxxxxxxxxx; mike@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL (putting on my user hat) I would have to agree with Greg here. We are seeing cases where the relationship between the data in the traditional IBIS [Model] – including C_comp, I-V tables and V-t tables – and the algorithmic model – the .ami file and accompanying DLL -- isn’t consistently defined or implemented. It’s understandable that complex, non-LTI behaviors in the traditional [Model] data would be undesirable to include alongside an algorithmic model (for example, a non-linear I-V curve set or, if traditional IBIS supported it, a complex, voltage-dependent buffer capacitance representation). However, the discussion here implies that realistic, simple traditional [Model] data should always be present, not zeroed out as Greg is seeing. If the language in the specification says the data is “used” for analog channel characterization, perhaps that language isn’t strong enough to ensure that both the right data and the right processing algorithms are used to combine them? Alternately, could we define some simple tests of analog and algorithmic model interaction to show that “everything’s working OK?” For example, in traditional IBIS, one of the key tests we have used to show how C_comp functions is to ask a user to: - Simulate an IBIS driver into a resistive load - Simulate the same driver into a lengthy (hopefully mismatched) transmission line - Alter the C_comp (even setting it to zero) in the driver model, re-run both tests above, and observe the behavior We would expect to see the resistive load cases not differ much at all, due to the way C_comp double-counting is avoided in most tools. However, there should be a fairly big difference in the t-line cases due to reflections interacting differently with the changed C_comp. Do we have, or can we produce, a set of similar tests that would demonstrate that a traditional + algorithmic model set is working correctly, together, in a given simulation environment? - MM From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Gregory R Edlund Sent: Thursday, December 13, 2012 9:56 AM To: mike@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL Mike & Others, I didn't mean to propose any changes to the existing IBIS 5.1 flow. I was responding to a question that arose within the company about the validity of an AMI model that has no analog buffer model in the .ibs file (empty tables and zero C_comp). The vendor claims that information is stored in the DLL. Maybe it is, but the model is not IBIS 5.1 compliant nor will it produce a physical simulation with any simulator on the market. I think we need to focus our efforts on building momentum behind IBIS 5.1, and that means building confidence among the user community by establishing a base of high-quality models. 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 Mike LaBonte ---12/12/2012 04:48:48 PM---I understood Greg's proposal as simply implementing "forwardMike LaBonte ---12/12/2012 04:48:48 PM---I understood Greg's proposal as simply implementing "forward" simulation of analog effects within a From: Mike LaBonte <mike@xxxxxxxxxxx> To: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx> Cc: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx> Date: 12/12/2012 04:48 PM Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL Sent by: ibis-macro-bounce@xxxxxxxxxxxxx _____ I understood Greg's proposal as simply implementing "forward" simulation of analog effects within a DLL, such that it only affects the output of each stage, no chance to create or respond to backward signals. It's easy to see that this is going to be a problem. Vladimir's proposal amounts to embedding s-parameter models within DLLs, to be selected and either passed to the EDA tool or combined with the channel response right within the DLL. These are completely different proposals. The latter idea could be seen as a combination of Fangyi's proposal that the DLL be able to make choices based on inputs then communicate them back out, and the idea that the analog model should be s-parameters, resulting in the ability to simply embed the s-parameter data sets in the DLL, which communicates the correct set back out based on settings. One observation is that we now seem to have more proposals putting the analog model in the AMI model than proposals keeping it in the legacy IBIS domain. Mike On Wed, Dec 12, 2012 at 5:14 PM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx> wrote: Todd, The original question from Greg was: “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? This spawned a bunch of replies ranging from “why not” to “impossible”, mostly on theoretical bases. You may be right that this may not be practical at the moment, but that’s not what the question was about. Whether it is worth solving or not could be discussed in a separate thread. Who knows, we might find out that it is worth considering it… Thanks, Arpad ======================================================= From: Todd Westerhoff [mailto: <mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx] Sent: Wednesday, December 12, 2012 4:07 PM To: Muranyi, Arpad Cc: ibis-macro@xxxxxxxxxxxxx Subject: Re: [ibis-macro] Re: Analog Buffer Model Inside DLL ... and revisiting one of the fundamental assumptions on which all of IBIS-AMI is based. Which, based on past experience, is expensive, both in terms of time and effort. I therefore assert that this is a problem that isn't worth solving. Todd. -- Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 <tel:%28978%29%20461-0449%20x24> twesterh@xxxxxxxxxx www.sisoft.com <http://www.sisoft.com/> “I want to live like that" -Sidewalk Prophets On Dec 12, 2012, at 5:01 PM, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx> wrote: Todd, I did not suggest that this was possible under the umbrella of the current v5.1 IBIS specification. In one of my responses I stated: “We would also need to revisit the AMI flow a little bit, but that’s just detail.” which implies a spec change, as far as I can tell… Thanks, Arpad =================================================== From: Todd Westerhoff [ <mailto:twesterh@xxxxxxxxxx> mailto:twesterh@xxxxxxxxxx] Sent: Wednesday, December 12, 2012 3:56 PM To: Muranyi, Arpad Cc: <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx Subject: Re: [ibis-macro] Re: Analog Buffer Model Inside DLL Arpad, We have a published spec that says the analog model is to be included in the calculation of that channel impulse response. Anything else is not compliant. Todd. -- Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 <tel:%28978%29%20461-0449%20x24> twesterh@xxxxxxxxxx www.sisoft.com <http://www.sisoft.com/> “I want to live like that" -Sidewalk Prophets On Dec 12, 2012, at 4:21 PM, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx> wrote: Todd, This is not super-theoretical-science in the clouds. It can be done just as practically and “easily” as the EQ, DFE and CDR AMI algorithms can be done in the DLL-s. It involves the same kind of algorithm knowledge, and programming skill. The question is, do we want to let model makers to do this, and possibly get a bunch of bad models from inexperienced people, or should we, the EDA vendors still have the opportunity to sell our expertise and provide higher quality and more reliable solutions to our customers and AMI model users. Thanks, Arpad ========================================================== From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> ibis-macro-bounce@xxxxxxxxxxxxx [ <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Wednesday, December 12, 2012 2:54 PM To: Dmitriev-Zdorov, Vladimir; 'Gregory R Edlund' Cc: <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Analog Buffer Model Inside DLL Vladimir, Not clear to me how you propose to handle the reflections associated with discontinuities at the point where the TX and RX analog circuits interface to the channel. More importantly, even if it’s theoretically possible, that doesn’t make it practical. I’ll admit I’m guessing here, but I expect Greg wants to solve a problem, not just establish that it should be possible to solve it. Todd. Todd Westerhoff VP, Software Products Signal Integrity Software Inc. • <http://www.sisoft.com/> www.sisoft.com 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 <tel:%28978%29%20461-0449%20x24> (978) 461-0449 x24 • <mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx “I want to live like that” -Sidewalk Prophets From: Dmitriev-Zdorov, Vladimir [ <mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx> mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx] Sent: Wednesday, December 12, 2012 2:39 PM To: <mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx; 'Gregory R Edlund' Cc: <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx Subject: RE: [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: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 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: <mailto:ibis-macro@xxxxxxxxxxxxx> 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. • <http://www.sisoft.com/> www.sisoft.com 6 Clock Tower Place • Suite 250 • Maynard, MA 01754 <tel:%28978%29%20461-0449%20x24> (978) 461-0449 x24 • <mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx “I want to live like that” -Sidewalk Prophets From: Gregory R Edlund [ <mailto:gedlund@xxxxxxxxxx> mailto:gedlund@xxxxxxxxxx] Sent: Wednesday, December 12, 2012 1:41 PM To: Todd Westerhoff Cc: <mailto:ibis-macro@xxxxxxxxxxxxx> 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 <image001.gif>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 < <mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx> To: Gregory R Edlund/Rochester/IBM@IBMUS Cc: " <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx" < <mailto:ibis-macro@xxxxxxxxxxxxx> 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 <tel:%28978%29%20461-0449%20x24> 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> 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 _____ This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. _____ This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. _____ This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.