Radovan, I understand what you're saying and agree - I thought it was worth noting the caveats for the group. One more caveat - while I think all IBIS simulators use a 1V "control input" to trigger the IBIS model, I believe they differ on the input voltage that triggers the waveform. Some use 0.5V, others use anything above 0V (rising) and below 1V (falling). Changing the edge rate of the control input will change the output waveform timing, to your original point. Thanks, Todd. Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@sisoft.com www.sisoft.com -----Original Message----- From: Radovan.Vuletic@qimonda.com [mailto:Radovan.Vuletic@qimonda.com] Sent: Monday, January 15, 2007 4:11 AM To: twesterh@sisoft.com; ibis@eda-stds.org; ibis-users@eda.org Subject: RE: [IBIS] Ibis open drain strange behaviour Hi Tod, I believe that you have started/mentioned now 2 different topics, that according to my opinion should be separated: 1.) correlation between HSpice and IBIS models and 2.) "overclocking of IBIS models" as some prefer to call it or "frequency dependant IBIS models" (sounds very funny) as others prefer to call it. About correlation between HSpice and IBIS models: - I absolutely agree with you that if one knows what is he/she doing comparison between HSpice and IBIS is not necessary. - Zero time point is for IBIS not strictly defined, IBIS model creator can/should/must cut rising/falling waveforms to get "frequently independent models" But, if one still wants to compare simulation outputs of Spice netlist and unchanged IBIS model (generated out of very same Spice netlist) there will be a difference (time shift) in result that is independent on "buffer delay" due to using of stimuli by IBIS simulation tool (once again I limit my discussion only on HSpice, but I think most of the people are using HSpice) - for me one year ago this was unexpected and I believe that this was original question of Dimitry as well. Reason is, as mentioned in my previous mail, that as soon as a stimuli is applied on Spice netlist something "happens" immediately (at least in HSpice) and as soon as transistors has reached their thresholds, internal capacitances are filled out, etc. that can be seen in waveform. For IBIS output model, if you applying for example rising transition, nothing will change until stimuli on input reaches 0.8V, just than starts "buffer delay". For slow stimuli this effect is more obvious than for fast stimuli - if one applies step function (physically not justified, but still) this effect disappears. As you said about "overclocking of IBIS models" it could be discussed very, very long ... Regards, Radovan -----Original Message----- From: owner-ibis@server.eda.org [mailto:owner-ibis@server.eda.org] On Behalf Of Todd Westerhoff Sent: Friday, January 12, 2007 7:31 PM To: ibis@server.eda-stds.org; ibis-users@server.eda.org Subject: RE: [IBIS] Ibis open drain strange behaviour Radovan, I believe the qualifications to time correlation between HSpice and IBIS are - not necessarily, and yes, if. Time 0 is an IBIS simulation is not guaranteed to have any special significance. You'd like to think that you could simulate your transistor and IBIS model side by side into the same load and expect them to line up, but there is no part of the spec that guarantees this. The IBIS waveform and the HSpice waveform will match in rise/fall time and shape, but they are not guaranteed to align in time. Time 0 is an IBIS model is arbitrary, which is one of the reasons why "buffer delay" simulations are used to normalize the simulated interconnect delays (flight times) to the component timing specifications - this is where Vref, Rref and Cref come from. IF the person creating the IBIS model uses a particular ramp rate at the HSpice model input, and IF the model creator uses the simulated HSpice waveform in the IBIS model without trimming it, and IF the IBIS simulator uses a similar ramp rate to stimulate the IBIS model with comparable triggering thresholds, then - yes, the transistor and IBIS simulations will line up in time. In practice, this occurs pretty often - but it's important to understand why. Most IBIS extraction software takes the simulated waveform from HSpice and puts it into the IBIS model unaltered (i.e. the IBIS output waveform does not start rising at time 0, it includes the "intrinsic" delay of the output buffer). As you pointed out, the ramp rate of the input to the buffer (in both the HSpice and IBIS simulations) is usually very fast compared to the ramp rate of the output. Thus, even if the input ramp rates or triggering thresholds are somewhat mismatched, the difference gets swamped by the much slower output ramp rate (and the simulations line up, or appear to). You need a significant mismatch in the stimulus rates to see a difference. However, one gets into trouble when the intrinsic delay of the output buffer approaches the device's data rate. The output may not finish "switching" in the IBIS curve before the next data bit is triggered. This particular behavior is problematic - the IBIS spec (last I looked) had no specific recommendation on how simulators should handle "overclocking", and different simulators handle this different ways. This is a big problem for semiconductor suppliers, as their models can have different behavior in different tools. The solution? Well, the IBIS spec does not guarantee that time 0 is when the input to the output buffer switches. Time 0 in an IBIS simulation is arbitrary. So, the model creators trim the "dead time" off the front end of the rising and falling V-T curves to ensure the outputs stabilize before the end of the data unit interval, and the time correlation to HSpice is lost. There are specific restrictions on how the dead time may be trimmed, which is a longer discussion. Point is, time correlation between IBIS and HSpice is not guaranteed. It happens frequently, but only as a consequence of the model building process. Dimitry was correct to point out that time 0 in HSpice is often arbitrary in itself - if we're dealing with a component with a clock-to-output spec, then we really have no idea when the output buffer in the device gets triggered with respect to the device's external clock pin anyway. Hope that helps, or was at least coherent ... Todd. Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@sisoft.com www.sisoft.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Mon Jan 15 07:23:05 2007
This archive was generated by hypermail 2.1.8 : Mon Jan 15 2007 - 07:23:23 PST