Hi Arpad, I am sorry to hear that your "fingers are starting to hurt from all this typing :) ". I deeply appreciate your replies with attention to details and please don't feel obliged to do so in the future, especially when we also have other responsibilities at work place. Sincerely, James Zhou From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Tuesday, March 13, 2012 6:37 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model James, "Legacy IBIS models represented by [Ramp] or [Rising/Fall Waveform] are not LTI in general." You hit the nail on its head, right on... But not all of your details are correct. "suppose you drive an IBIS model with 1V pulse, and you get 1V output. However if you drive it with 0.1V pulse, instead of getting 0.1V output, you get 0V" This is incorrect. Let's separate this into two parts. The logic level of '1' or '0' in the digital stimulus has no thresholds, it is either logic '1' or '0'. There is no voltage or amplitude associated with this. This stimulus indicates the t=0 for the transition the [Ramp] and waveform based buffer model does. The model's amplitude is determined by the reference voltages of the I-V tables and the load impedance. There are no ifs and buts as far as this stimulus, it either switches or not. If by "suppose you drive an IBIS model with 1V pulse" you are referring to the D_to_A converter's voltage levels which is used to drive an analog circuit block representing the buffer's impedance, there are still no thresholds associated with it. The analog circuit (or S-parameter model) that follows this converter will generate a proportional output voltage, no matter what the amplitude of the D_to_A converter is. So there is no such thing that a 0.1V signal will have 0 output. "By definition, [Ramp] or [Rising/Falling Waveform] are only triggered by an input event at time=t0. All input amplitude variations have no impact on the output (unless they cause a trigger of Rising/Falling waveforms). Such a system cannot be represented by an impulse response. " Again, there are no thresholds, so the above sentence is not quite correct. But think about it this way: The system's transfer function doesn't involve the logic '1' or '0' of the stimulus (or the transition between these states) because these logic states are not directly related to the voltages or currents in the system. The transfer function of an analog driver (or even receiver) consists of its I-V relationship (and time) between the signal pad and the supply rails. If you force the voltage on the signal pad, the buffer will respond with a current, or vice versa. The response you get may depend on the logic state of the digital input stimulus and the bit pattern that changes it, which is a variation with respect to time. So in short, the transfer function of a buffer is pretty much impedance as a function of voltage and time. (You may also add frequency to that, but that really doesn't change the above discussion much). Some sources of non-linearities may involve a nonlinear I-V relationship, which looks like a curve instead of straight line on the I-V plot, and time variances may involve a changing impedance with respect to time, and similar artifacts. These effects are assumed to be negligible in the current IBIS-AMI specification whether it is true or not. Even though legacy analog models (using I-V curves) have the capabilities to describe a non-linear I-V relationship, for AMI purposes it is advisable not to make such non-linear analog models. Also, even though legacy IBIS models do have the capability to describe asymmetric rise and fall times, it is better not to make models exhibiting such behaviors. The new analog modeling proposals which make use of the D_to_A converters as ideal sources and S-parameters or similar linear circuits for modeling the impedance and rise/fall time of the buffer do away with the possibility to make non LTI analog buffer models, but these modeling techniques are not going to do away with the facts of real life, which is generally non-LTI. In order to include such capabilities in AMI-style algorithmic simulations, we would have to revisit the fundamentals of our AMI approach. My colleague, Vladimir gave a presentation on that topic a while ago, but so far the ideas presented there didn't catch on. http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20091014/vladimirdmitrievzdorov/How%20to%20account%20for%20non-LTI%20of%20Tx%20analog%20buffer%20in%20IBIS%20AMI%20flow/AMI_Tx_With_Admittance.pdf The question on how anyone goes about extracting the impulse response hAC(t) with or without the [Ramp] or waveforms and the I-V curves, or employing any other technique is a very complicated topic. It is best left to the rocket scientists of each EDA vendor. Who knows, they may even have some snake oil in their secret sauce. As long as each vendor can claim that they have the best and most accurate algorithms to generate impulse responses, their customers will be happy. The IBIS specification is only here to make sure that given the same impulse response the same model should pretty much get you the same results, no matter on whose simulator the model is executed. The question of how good the impulse response is falls into the category of garbage in - garbage out discussions as far as the AMI spec is concerned. I hope this helps... Arpad P. S. Please try not to ask more questions unless absolutely necessary, my fingers are starting to hurt from all this typing ( :) ). =============================================================================== From: James Zhou [mailto:james.zhou@xxxxxxxxxx] Sent: Tuesday, March 13, 2012 6:34 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model Arpad, One more comment on " to generate hAC(t)... the EDA tool would give a stimulus to the Tx analog model corresponding to a rising or falling step function, such as a digital '0' and '1' or '1' and '0' to get a rising or falling step waveform" I think there are some potential problems to obtain hAC(t) in this way. First of all, hAC(t) can only represent LTI block. Legacy IBIS models represented by [Ramp] or [Rising/Fall Waveform] are not LTI in general. One simple example is shown here: suppose you drive an IBIS model with 1V pulse, and you get 1V output. However if you drive it with 0.1V pulse, instead of getting 0.1V output, you get 0V. If the above process is permissible by the Specification to generate hAC(t) from [Ramp] or [Rising/Falling Waveform], some linearization process must be used either implicitly or explicitly. This linearization process may not be trivial for any arbitrary legacy IBIS model and I think the Specification should provide sufficient information such that all EDA tools should end up with the same hAC(t) from the same data. By definition, [Ramp] or [Rising/Falling Waveform] are only triggered by an input event at time=t0. All input amplitude variations have no impact on the output (unless they cause a trigger of Rising/Falling waveforms). Such a system cannot be represented by an impulse response. Regards, James Zhou From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of Muranyi, Arpad Sent: Tuesday, March 13, 2012 2:02 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model James, Regarding: "please clarify what is actually driving the input terminals of Tx analog block (which is the first stage of the entire analog channel, represented by hAC(t))", there are several different ways to generate hAC(t), but one way to do it is to run a time domain simulation using a step function and take the derivative of the resulting waveform at the Rx. In order to do this, the EDA tool would give a stimulus to the Tx analog model corresponding to a rising or falling step function, such as a digital '0' and '1' or '1' and '0' to get a rising or falling step waveform. How this is implemented is entirely up to the EDA vendor, that's why the IBIS specification doesn't give you these details. But the point is that this stimulus has nothing to do with x(t) which is what goes into AMI_GetWave during an AMI simulation. Regarding: "(a) Instead of "driving the channel topology by the Tx I-V, [Ramp], or V-t based analog model", the "digital stimulus" actually drives the Tx AMI input. The Tx AMI output should drive these analog models, if such practices are allowed by the Specification. It neither makes sense to me (to drive a legacy IBIS model with x(t) or Tx AMI output) nor specified by IBIS 5.0 or BIRDs that this is permissible and doable." Which digital stimulus are you talking about in "the "digital stimulus" actually drives the Tx AMI input"? There are two digital stimuli. One that is used to stimulate the analog Tx model to generate the impulse response (hAC(t)) for the channel, and another one that is the input to the Tx AMI_GetWave function during the AMI simulation. Why do you say "The Tx AMI output should drive these analog models"? I don't see that in the AMI flow diagram. Even though you might want to do that in your approach, this is not what the IBIS AMI flow suggests. Regarding: "since the "digital stimulus" x(t) is in fact amplitude continuous, if it is used to drive the D_to_A in Tx", this statement is not correct. x(t) is not used to drive the D_to_A (or the input) of the Tx analog model. It is used as the input to the Tx GetWave function. I hope this helps. Arpad ======================================================================= From: James Zhou [mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]> Sent: Tuesday, March 13, 2012 1:15 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model Hi Arpad, I agree with the first part of your response, which basically states that x(t) = b(t) * p(t) and, x(t) drives Tx AMI block. In case of using AMI_GetWave, x(t) is passed to AMI_GetWave through *wave variable. Even though labeled as "digital stimulus", x(t) is amplitude continuous and time discrete. With reference to "The analog model was used in generating the channel's impulse response hAC(t), but it is not driven by the output of Tx GetWave as you concluded", If this is the case, please clarify what is actually driving the input terminals of Tx analog block (which is the first stage of the entire analog channel, represented by hAC(t)). With reference to "As far as I know the analog models are exercised the same way as in a usual legacy IBIS simulation using the tool's digital stimulus (though the D_to_A converters in Tx), driving the channel topology by the Tx I-V, [Ramp] or V-t based analog model, to obtain an impulse response as seen at the Rx", there are several issues here: (a) Instead of "driving the channel topology by the Tx I-V, [Ramp], or V-t based analog model", the "digital stimulus" actually drives the Tx AMI input. The Tx AMI output should drive these analog models, if such practices are allowed by the Specification. It neither makes sense to me (to drive a legacy IBIS model with x(t) or Tx AMI output) nor specified by IBIS 5.0 or BIRDs that this is permissible and doable. (b) since the "digital stimulus" x(t) is in fact amplitude continuous, if it is used to drive the D_to_A in Tx, all amplitude information would be lost, except the rise/fall transitions. Thanks, James Zhou From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of Muranyi, Arpad Sent: Monday, March 12, 2012 9:36 PM To: 'IBIS-ATM' Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model James, Knowing that Walter is enjoying the IEEE meetings in Hawaii, I will try to help a little. Please refer to the flow diagram that was used in the discussions towards the new flow. See pg. 17 in this presentation: http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100713/toddwesterhoff/IBIS-AMI%20Flows/Flows_July2010-v2.pdf Note that the input to the Tx GetWave function is labeled "Digital stimulus" and x(t). Also note that x(t) is explained in more detail in this presentation on pg. 13-14: http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20061212/toddwesterhoff/Serial%20Link%20Terminology/serial_link_terminology.pdf where "TX data" is b(t) convolved with p(t) which we later simply referred to as x(t) in our flow diagrams. Please note also that on pg. 17 of the first presentation above, the output of Tx GetWave is convolved with the channel impulse response hAC(t) and the result of that is the input to Rx GetWave. There is no analog model present in this flow. The analog model was used in generating the channel's impulse response hAC(t), but it is not driven by the output of Tx GetWave as you concluded. So your conclusions that: " Equivalently, the legacy IBIS [Ramp] and [Rising/Falling Waveform] keywords have no roles in this process." and "D_to_A is not needed in IBIS AMI, or at least in between Tx AMI block and its analog block. Because the output of Tx AMi is already analog, why bother using a D_to_A? " seem to be incorrect to me. As far as I know the analog models are exercised the same way as in a usual legacy IBIS simulation using the tool's digital stimulus (though the D_to_A converters in Tx), driving the channel topology by the Tx I-V, [Ramp] or V-t based analog model, to obtain an impulse response as seen at the Rx. Of course there are other techniques to achieve equivalent results, but it is not the role of the IBIS specification to enumerate all possible methods in the trade. I hope this helps... Arpad ========================================================================= From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of James Zhou Sent: Monday, March 12, 2012 9:02 PM To: Walter Katz; Terry.Chen@xxxxxxxxxx<mailto:Terry.Chen@xxxxxxxxxx>; DBanas@xxxxxxxxxx<mailto:DBanas@xxxxxxxxxx>; 'IBIS-ATM' Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model Hi Walter, Thanks for your response and clarification. The issues can be separated as the following: (1) "determine the Impulse Response of a channel": I fully agree with you that "Tx analog portion takes the output of the algorithmic section of an AMI model". Equivalently, the legacy IBIS [Ramp] and [Rising/Falling Waveform] keywords have no roles in this process. This is a subject that has caused much confusion in the end-user community and we need to clarify it in terms of both (a) what are the intentions of model makers when IBIS AMI analog model data is put in [Ramp] [Raising/Falling Waveform] keywords and (b) What should the EDA tools do about those data in IBIS AMI modeling (i.e. when deriving impulse response) (2) "the fundamental confusion of using [External Model] with IBIS-ISS subckts": in my opinion, D_to_A is not needed in IBIS AMI, or at least in between Tx AMI block and its analog block. Because the output of Tx AMi is already analog, why bother using a D_to_A? ( I understand D_to_A is useful for general IBIS [External Model] not involving AMI). (3) "one must be very careful to make sure that return loss is properly accounted for": I fully agree. IBIS Specification should provide clear guidelines on how to achieve this both at model creation time and model simulation time. I think enforcing reverse isolation is too restrictive for existing silicon implementation and it will cause larger errors when return loss is lower. It is much simpler and better to require the disclosure (knowledge) of Tx AMI block output impedance (which is assumed to be high impedance by many, anyway) and, not imposing any artificial requirements on the AMI analog block (such as reverse isolation which in fact does not exist in many silicon). Thanks, James Zhou From: Walter Katz [mailto:wkatz@xxxxxxxxxx]<mailto:[mailto:wkatz@xxxxxxxxxx]> Sent: Monday, March 12, 2012 4:50 PM To: James Zhou; Terry.Chen@xxxxxxxxxx<mailto:Terry.Chen@xxxxxxxxxx>; DBanas@xxxxxxxxxx<mailto:DBanas@xxxxxxxxxx>; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model James, The IBIS analog model is only useful to determine the Impulse Response of a channel. You are absolutely correct that in reality a SerDes Tx analog portion takes the output of the algorithmic section of an AMI model to drive an analog model (e.g. an on-die S-parameter s4p, a simpler RC circuit at described in BIRD 122, or an ISS subckt as defined in BIRD 116). IBIS AMI assumes an LTI channel, and IBIS-ISS defines all of the LTI elements available in HSPICE. This is the fundamental confusion of using [External Model] with IBIS-ISS subckts describing the analog section. As written now, BIRD 116 identifies the input of the Tx ISS subckt using the D_to_A statement, which essentially defines a voltage swing and rise time - equivalent to Ramp. The correct interpretation is that the D_to_A statement is only to define the input to the Tx analog circuit, and is valid to determine the Impulse Response of the channel. Because of silicon drivers are in fact LTI, one can do the shaping of the waveform in the algorithmic section, but one must be very careful to make sure that return loss is properly accounted for. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of James Zhou Sent: Monday, March 12, 2012 5:11 PM To: Terry.Chen@xxxxxxxxxx<mailto:Terry.Chen@xxxxxxxxxx>; DBanas@xxxxxxxxxx<mailto:DBanas@xxxxxxxxxx>; 'IBIS-ATM' Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model Hi David and Terry, Both of your emails mentioned "analog IBIS model" and "IBIS-analog portion" represented by [Ramp] and/or [Rising/Falling Waveform] keywords in IBIS file. However, these "analog" IBIS models only take digital input signals, as stated in IBIS Specification 5.0, page 71-72 and section 6b. The output of the "analog" IBIS model is not capable of tracking the amplitude changes in the input (other than a rise/fall transition). It would not make sense to feed the Tx AMI output to such digital inputs based on IBIS Specification 5.0. If this approach of using [Ramp] and/or [Rising/falling Waveform] keywords to represent "analog IBIS model" is adopted by IBIS AMI flow, some clarification is needed on how to interpret and implement it. Regards, James Zhou QLogic Corp. From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of Chen, Terry Sent: Thursday, March 08, 2012 10:33 AM To: DBanas@xxxxxxxxxx<mailto:DBanas@xxxxxxxxxx>; 'IBIS-ATM' Subject: [ibis-macro] Re: Question on dividing up the Tx behavior between the AMI and analog portions of the model Hi David, Actually I am interested in other's response to this question as well... But, for the TX Driver I am currently modeling, I am doing exactly what you have prescribed and using the IBIS-analog portion as effectively an ideal step function (by setting my ramp with extremely high rise/fall dv/dt) and letting the step response filter inside my AMI model to shape my output waveform. Now, I am not sure if this is the "right" or "ideal" way to do it, but I am getting a reasonably good correlation in my Re-driver model with the actual lab measurements (the max jitter mismatch is < 8ps). I hope this is at least an useful data point for you. Regards, Terry From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of David Banas Sent: Thursday, March 08, 2012 1:15 PM To: 'IBIS-ATM' Subject: [ibis-macro] Question on dividing up the Tx behavior between the AMI and analog portions of the model Hi all, Is it customary to split up the Tx behavior, such that the FFE is modeled in the AMI model and the pulse shaper in the analog model? Or, is there a different dividing line that has been identified as "best practice". (Or, am I completely off in the weeds?) The context for this question: I just managed to get good correlation between our latest Tx AMI model and the HSPICE model. And then I realized that, having dumped all of the behavior into the AMI model, I would need to put an ideal step function into the V-T curves of the analog IBIS model. And I wasn't sure that would be a good idea. (I'm guessing that that would reek havoc in most simulators; is that correct?) Thanks, David Banas Sr. Member Technical Staff Altera<http://www.altera.com/> +1-408-544-7667 - desk Did you know Altera offers over 150 free online technical training courses<http://www.altera.com/servlets/searchcourse?coursetype=Online&WT.mc_id=t9_ot_mi_mi_tx_a_311>? Take one today! ________________________________ Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. ________________________________ 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. ________________________________ 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.