RE: [IBIS] Ibis open drain strange behaviour

From: Todd Westerhoff <twesterh_at_.....>
Date: Mon Jan 15 2007 - 07:22:30 PST
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 1993
Received 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