James, I really don't know how to answer your question any better. Regarding the digital input, the [Ramp] and the waveforms, this is really not an input/output relationship as we know it in transfer functions and the like. The input is only a trigger that starts an analog process, and no more. If the analog process is a ramp, say 1V / 1ns, you will start an analog voltage at 0V and go up to 1V by the time reaches 1ns. While you do this, you iterate through time and solve for voltage and current as SPICE does. If you add I-V curves to it, the voltage and current relationship will make use of the data that is stored in the I-V table. This is all analog, and other than getting the process started, the "input" is not doing anything to it. This is similar to a parallel RC circuit, whose initial capacitor voltage is set to, say 1V. At the moment you "let go" of the initial voltage (source), the RC circuit will go to 0V with the familiar exponential relationship. In this case the initial condition was your "digital input" which was removed at a certain time (usually at t=0). IBIS models are no different from this, except they are made from PWL sources for [Ramp] and the I-V curves, instead of RC elements. "Supporting" or "proposing" something are two different things. In my previous email I said that the BIRDs I listed support the concept of modeling something with an almost ideal source and an S-parameter model. This means that it can be done. However, the spec is not going to say (propose) that a device should be modeled that way (or any other way). A specification is not a modeling cookbook. When did you see a SPICE manual describing how a differential driver should be put together from three transistors and two resistors? The SPICE manual will give you how to model a transistor and a resistor and the rest is up to the designer. Same thing goes for IBIS. We describe the rules on how you can define a source with a certain ramp, and how you can attach an S-parameter model, but we are not going to tell you what that should be used for. I hope this helps. Thanks, Arpad ================================================================ From: James Zhou [mailto:james.zhou@xxxxxxxxxx] Sent: Monday, March 12, 2012 8:39 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: Question on dividing up the Tx behavior between the AMI and analog portions of the model Hi Arpad, Thank you for your response again. Could you or anyone please point to a specific section in these texts that would invalidate my statement? I'd like to clarify that by "none of the existing Spec or BIRDs support such a modeling practice", I specifically refers to " using [Ramp] or [Rising/Falling Waveform] to represent analog part of IBIS AMI". It is evident to me that these keywords assume digital inputs. I don't see any BIRDs proposing the practice of "putting analog data into S-parameter block that followed legacy IBIS model", as well as "to drive that analog model with an ideal step function" for IBIS AMI modeling flow. Any reference to specific sections of BIRDs would help greatly to clarify this important issue. Walter's reply is also related to this subject which I will respond shortly. Thanks, James Zhou From: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx]<mailto:[mailto:Arpad_Muranyi@xxxxxxxxxx]> Sent: Monday, March 12, 2012 6:06 PM To: James Zhou; 'IBIS-ATM' Subject: RE: Question on dividing up the Tx behavior between the AMI and analog portions of the model James, Regarding "the answer is that none of the existing Spec or BIRDs support such a modeling practice", this is only true as far as the existing specification is concerned, but false for BIRDs. BIRD 122 described this http://www.eda.org/pub/ibis/birds/bird122.txt and BIRDs 166-118 + 129 describe this capability without explicitly mentioning AMI (since the proposed features in these BIRD can be used for other than AMI purposes too): http://www.eda.org/pub/ibis/birds/bird116.txt http://www.eda.org/pub/ibis/birds/bird117.3.txt http://www.eda.org/pub/ibis/birds/bird118.2.txt http://www.eda.org/pub/ibis/birds/bird129.txt In addition, BIRD 144 also provides a similar mechanism to do such modeling without going through the IBIS-ISS wrapper: http://www.eda.org/pub/ibis/birds/bird144.3.txt Thanks, Arpad ==================================================================== From: James Zhou [mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]> Sent: Monday, March 12, 2012 7:57 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: Question on dividing up the Tx behavior between the AMI and analog portions of the model Hi Arpad, If we apply the second paragraph in your email to David's original question, the answer is that none of the existing Spec or BIRDs support such a modeling practice (i.e. using [Ramp] or [Rising/Falling Waveform] to represent analog part of IBIS AMI, with the understanding that it may be possibly followed by S-parameter blocks). Regarding the first paragraph in your email, I agree with you that it is possible that David might have a S-parameter block following a legacy IBIS model and then "drive that analog model with an ideal step function". However I think it is very important to clarify that this modeling approach is not supported by IBIS 5.0 or any BIRDs and it is ASIC/EDA vendor proprietary. Thanks, James From: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx]<mailto:[mailto:Arpad_Muranyi@xxxxxxxxxx]> Sent: Monday, March 12, 2012 5:17 PM To: James Zhou; 'IBIS-ATM' Subject: RE: Question on dividing up the Tx behavior between the AMI and analog portions of the model James, I think both David and Terry were putting their analog data into their S-parameter block that followed their legacy IBIS model, but in order to drive that analog model with an ideal step function they had to make the [Ramp] or V-t table as steep as possible. Such text doesn't exist in the specification yet, because this is all evolving now as we speak. The analog BIRDs are currently discussed in the ATM meetings and we do not have the final results of what will go into the specification yet. Thanks, Arpad ===================================================== From: James Zhou [mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]> Sent: Monday, March 12, 2012 7:11 PM To: Muranyi, Arpad; 'IBIS-ATM' Subject: RE: Question on dividing up the Tx behavior between the AMI and analog portions of the model Hi Arpad, David used "V-T curves of the analog IBIS model" and Terry "setting my ramp with extremely high dv/dt". These statements suggest that (a) David put his analog data in [Rising/Falling Waveform] keyword and (b) Terry put his analog data in [Ramp] keyword. If that is true, and these data are given to an EDA tool, my question is how is the EDA tool supposed to connect the AMI output to the analog input? I don't see any text in IBIS Specification 5.0 or BIRDs that address this issue. (That is, when the analog part is represented by [Ramp] or [Rising/falling Waveform]). Please let me know if such text exist. Regards, James 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 4:51 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, As far as I can tell, the digital input signal (stimulus) you mentioned has nothing to do with what David and Terry are talking about. That digital signal is purely an indication for the analog signal (whether it is governed by [Ramp] or the V-t tables, doesn't matter) to begin its course. This is basically t=0 for the transition. The transition amplitude and slope is defined by the reference voltages of the I-V tables and [Ramp] or V-t tables. This is all analog. There are models out there which try to make this "model" as ideal as possible, giving it really fast edge rates and very strong I-V current relationships, so that the block that follows could be used for "wave shaping" and "impedance definition". I like to call this approach as the "Glorified Thevenin" model, in which the IBIS analog model acts as the ideal source and the next block (often times an S-parameter model) is the Thevenin impedance. But I don't see any relationship in this and the "digital" stimulus that goes into the legacy IBIS models. Thanks, 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 4: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.