Todd, ok, we understand that time correlation between IBIS and HSpice is not guaranteed, but is it really problem? I mean, in the most often situation there is no place for such comparison at all, because you have only IBIS model, no spice netlist is available. This is the first reason for making IBIS (if simulator speed is not an issue), is it right? Lets say, I'm with semiconductor vendor side, I have the netlist of the buffer, I make the IBIS model based on spice simulations, not lab measurements, so on final step when the model is ready I like to check it vs. original spice behavioral. This is the only situation I agree the comparison is important. But in such case there is no REAL problem - I know exactly about the delay, and if it is the only difference between the IBIS & spice - I don't care. I want ask you about IBIS simulator aspect of the point we are talking about. Look, I find in "Cookbook for ver4" strongly recommendation to trim IBIS model time tables at least to half of max buffer frequency period. (http://www.vhdl.org/pub/ibis/cookbook/cookbook-v4.pdf page 70, 5.4.2 V-T Table Windowing). Can you please prefer from simulator software side - is it really problem for the simulator if the time table window is more then such time interval? And one additional point, you wrote "There are specific restrictions on how the dead time may be trimmed, which is a longer discussion" - right now I writes perl script which will trim tables in order to leave only transition region and decrease the time window as the Cookbook recommends to do. So, can you please explain about these restrictions? Thanks, Dmitry Todd Westerhoff wrote: > 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 > > > > =========================================================================================== The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond. -- 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 Sat Jan 13 00:58:43 2007
This archive was generated by hypermail 2.1.8 : Sat Jan 13 2007 - 00:59:55 PST