[IBIS] RE: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode

From: Todd Westerhoff <twesterh_at_.....>
Date: Wed Dec 05 2007 - 08:30:23 PST
All,

 

The simulated behavior of an IBIS model with properly trimmed IBIS curves shouldn't change - that's
the definition of "proper trimming".  The only time you should see a difference in behavior is when
you switch the buffer's state before the full time in the V-T curve has elapsed (usually referred to
as "overclocking").   V-T curves with extra dead time in the start of the curve will overclock at
lower speeds than trimmed curves will, which is why we trim V-T curves in the first place.  We trim
curves based on the understanding that a device really will operate at a target speed, but that V-T
curves with extra dead time will give the incorrect results.

 

You're correct that [Ramp] data is generally not used for simulation when V-T curves are present,
but that doesn't mean it's not important.  Some tools use [Ramp] data to choose what drivers to use
for crosstalk simulations (based on the theory that the fastest edge rate will produce the greatest
crosstalk).  Some tools will also use [Ramp] data as a fallback if they encounter problems using V-T
curves for analysis.

 

Hope that helps,

 

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

  _____  

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Ummalaneni, Venu Babu
(Venu)
Sent: Wednesday, December 05, 2007 5:17 AM
To: Amit KUMAR
Cc: Dimitry Eisenshtat; ibis@eda-stds.org; ibis-users@eda.org; Todd Westerhoff
Subject: RE: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode

 

Amit Kumar,

 

Thanks for your response. I too experienced the similar results with the hspice on "before trimming
vs after trimming the V-t curves". 

 

Regards,

Venu

  _____  

From: Amit KUMAR [mailto:amit-hpc.kumar@st.com] 
Sent: Thursday, November 29, 2007 4:59 PM
To: Ummalaneni, Venu Babu (Venu)
Cc: Dimitry Eisenshtat; ibis@eda-stds.org; ibis-users@eda.org; Todd Westerhoff
Subject: Re: [IBIS-Users] RE: Trimming V-t curves - IBIS model behavior in over clocking mode

Hello Dmitry

I have been using Hspice to simulate IBIS models for a while and i have observed that
there is no difference(or let me say miniscule diffrences) after trimming V-t curves.
It can make difference only if you have missed many intermediate points before trimming and 
after trimming they are included.
But if you have been careful enough to extract your V-t waveforms 
i feel trimming does not bring any improvement in the results.

Also i have felt that Ramp data is also not important if you have given V-t waveforms.
No matter how weird your ramp data may look simulation results will be good if your 
V-t waveforms are extracted properly.

One parameter which changes the waveform considerably is C_comp.
One should be careful in extracting C_comp as wrong calculation of C_comp can lead to bad results.

I leave to the experts to comment on my observations.

Regards
Amit Kumar
ST Microelectronics-Noida

Ummalaneni, Venu Babu (Venu) wrote:



Dmitry and all,
 
I am curious to know your experiences on the experiments with "trimming
V-t curves". Could some one please comment on the behavior of IBIS model
with Hspice simulator before and after trimming? I mean, whether the
correlation of the IBIS vs golden model in over clocking mode improved
after trimming the V-t curves?
 
Thanks & Best Regards,
Venu
 
-----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On
Behalf Of Dimitry Eisenshtat
Sent: Tuesday, January 16, 2007 3:32 AM
To: Todd Westerhoff
Cc: ibis@eda-stds.org; ibis-users@eda.org
Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour
 
Hi Todd,
first of all - thanks for your reply, as I said, I'm writing script for
trimming V/T tables in order to satisfy Cookbook recommendation, so your
explanation is really useful. Thank you :)
 
Ok, I see from your virtual DDR example that "over clocking" should
require special treatment on IBIS simulator side, and I finally decide
to avoid such situations and create IBIS models with V/T tables time
window up to  half of minimum signal period the buffer designed for.
 
Now some words about HOW I will do it. I think the most important point
you mentioned is "time correlation" of all given corner curves. I want
use simple algorithm for automatically trimming V/T curves, let me
explain. Lets say we have 12 transients, exactly as in your (most
common) example of push-pull buffer simulated in 3 corners with load of
50 ohm once to supply, once to ground. The steps will be:
 
1) Run spice simulations (with s2ibis* or manually, does not matter)
with as small time step as it possible for simulation time large enough
for weakest conditions (corner/load) transition to be finally completed.
 
The idea is to begin with "ideal" time resolution for all transitions
regions in our 12 curves.
 
2) For each curve find largest time interval (T1,T2) which satisfy
voltage tolerance of delta from initial and final DC solutions, i.e.
  |(V(T1)-Vstart)/VDD|  < Vtol,
  |(V(T2)-Vend)/VDD|    < Vtol
where Vtol tolerance chosen smaller than IBISCHK's one so the checker
will not report "DC endpoints" warning on trimmed tables latter. All
data points outside of this interval (T1,T2) are declared "dead zones" 
and have no importance. So the Vtol value actually plays as "dead zones"
 
definition criteria and should be the parameter to be changed if needed.
 
3) For all curves (rising/falling/load) of given corner find the minimum
T1 value, lets define it as T1_typ, T1_slow, T1_fast or T1_<corner>.
 
4) Calculate maximum interval dT_max = max {|T2-T1_<corner>|} for ALL
curves.
 
5) Shift all curves for given corner left in time by T1_<corner> value.
 
6) Truncate all curves at time dT_max (from new 0 time after shifting)
 
7) Add one points to end of each curve in order to form a line with zero
slope for case of some simulators extrapolation will be needed.
 
8) Remember, we start from "the best" time resolution, so it is possible
that we get desire time window from overclocking point of view, but
number of points in final V/T tables still exceeds the maximum allowed
by IBIS spec. In this case I suggest to use "greatest change algorithm" 
in order to decrease the number of tables points, as it described in
Cookbook (pages 63-64).
 
As the result, if I have no mistake, we will get "corner time-
correlated" tables. However, across corners correlation is not
guaranteed. My assumption is that the user will be interested in
analyzing the buffer's (buffer itself, I mean not control logic but
pullup/pulldown devices which actually drive the pad) corner-specific
behavioral/differences, so I at least do not worsen the model quality,
or even improve it. Anyway,  in some cases there will be no possibility
to satisfy "overclocking free" condition without shifting the corner's
curves one to each other, in other words without trimming different
amounts from different corners.
 
Does it make sense? I like to complete realizing this algorithm in perl
and try it on last DDR2 model I produced. Only IBIS simulator I have is
HSpice, so the plan is to compare the behavioral of IBIS model before
and after trimming. I hope the HSpice is bad enough in "over clocking" 
scenario, otherwise I will see no difference/improvements anyway :)
 
Regards,
    Dmitry
 
 
Todd Westerhoff wrote:
  

Sorry for the delay in reply - I took the weekend off ;-)
 
As far as non-time correlation between IBIS and transistor models goes
- no, it isn't a problem at all.  It's just important that people 
understand what a model represents and what it doesn't, so that they 
can draw the right conclusions from their simulations.  I was just 
re-iterating one of my favorite points with "time 0 in an IBIS model
    

is arbitrary".
  

To your point, it's worth noting that time 0 in a spice model-based 
simulation is often arbitrary as well.  A spice model represents only 
the output buffer at most, so if you're analyzing a device with a 
clock-to-out timing specification, you still need to figure out how to
    

 
  

combine the delays measured in simulation with the timing spec for the
    

device.
  

I think people often ascribe too much credibility to spice models.  
The model you receive is a function of how the netlist and parasitics 
for the buffer were extracted - it's far too easy to become confused 
about what part of the overall device the spice model represents.
 
As to page 70 of the IBIS cookbook - I agree with what it says.  That 
particular page is assuming a DDR device, so that a 100 MHz clock 
yields 200M transfers/sec, each with a 5 ns UI.  Let's suppose you 
have a model with a 6ns rising V-T curve for this case.  The simulator
    

 
  

will trigger the curve, begin sweeping the output, and then get 
retriggered at the 5ns point
- before the rising edge is complete.  What should the simulator do?
 
- should it just jump to the start of the falling curve (if it does, 
you may get a discontinuity on the output that can either glitch the 
output or cause a convergence problem)
 
- should the simulator "pipeline" the waveform results, and just 
remember the next edge starts 1 ns later - and if the input edges keep
    

 
  

coming faster than the curve length, how long should the simulator 
keep this up before it starts clipping data?
 
... my earlier point was that the IBIS spec has no guidance on how a 
simulator should handle "overclocking" and different simulators DO 
handle this issue different ways.  That being the case, it's best to 
avoid the problem by complying with the strong recommendation on page
    

70.
  

As far as curve trimming goes, allow me to provide a *brief* overview,
    

 
  

although I'm sure this subject has been discussed previously.
Pointers into the archive for this subject from others would be
    

appreciated.
  

Let's consider a push-pull output stage instead of open drain - 
open-drain will just be a simpler case.
 
Each output should have the following V-T curves
  
  [Corners]         x [Edge]             x [Loading]
 
  [Min / Typ / Max] x [Rising / Falling] x [50 ohms GND / 50 ohms
    

VDDQ]
  

... for a total of 12 sets of V-T curves.  
 
... for each [Corner]/[Loading] combination, it is ESSENTIAL that if 
you trim dead time off one curve, you trim the SAME amount of dead 
time off the other.  As an example, if you trim 1ns off the start of 
the [Min]/[Rising]/[50 ohms GND] curve, you MUST trim 1ns off the 
[Min]/[Rising]/[50 ohms VDDQ] curve.  If the second curve was already 
rising at that point, well, you need to trim less.
 
This is what's called "time correlation" between curves, and it must 
be maintained.
 
... good practice dictates that you coordinate your trimming across 
all four of the V-T waveforms for any corner.  If you don't do this, 
you'll introduce duty cycle distortion into the simulated waveform 
without meaning to.  I believe this is now considered to be required 
practice.  So, if you trim 1ns off the start of the [Min]/[Rising]/[50
    

 
  

ohms GND] curve, you really, really should trim 1ns off the following
    

curves:
  

  [Min]/[Rising]/[50 ohms VDDQ]
  [Min]/[Falling]/[50 ohms GND]
  [Min]/[Falling]/[50 ohms VDDQ]
 
... so that time correlation is maintained across all the [Min] 
curves.  As before, if you go to trim any of the curves and find the 
transition was already starting, you need to trim less.
 
I don't believe IBIS requires that you coordinate trimming across
    

corners.
  

Thus, you can trim different amounts from the [Min] and [Typ] curve
    

sets.
  

In practice, you'll find this is useful because if you try to 
coordinate trimming across a 3 corners, the amount you are able to 
trim may be sharply limited.  It's important to understand, though, 
that if you trim different amounts from the different corners, the 
time correlation between the corners will be lost.  Strictly speaking,
    

 
  

that's not a problem, as time 0 in an IBIS simulation is arbitrary.
HOWEVER - if users of the model simulate the [Min] and [Typ] cases and
    

 
  

overlay the results, they will draw incorrect conclusions if they
    

assume the curves are time-correlated.
  

It probably goes without saying, but - you can trim any amount of dead
    

 
  

time you want off the END of a curve once the slope is zero.  Good 
practice says the last two points should form a line with zero slope, 
so that any extrapolation the simulator performs does what you expect.
 
As in all modeling - knowing what you've got is the first step in 
understanding what conclusions you can draw.
 
Arpad & others - please correct me if I've gotten any of this wrong
    

...
  

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: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On 
Behalf Of Dimitry Eisenshtat
Sent: Saturday, January 13, 2007 3:58 AM
To: Todd Westerhoff
Cc: ibis@eda-stds.org; ibis-users@eda.org
Subject: Re: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour
 
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
 
... (previous thread clipped)
 
 
    

 
 
--
  +---------------------------------------------------------+
  | Dmitry Aizenshtat         Circuit Design Engineer, NSTA |
  | Tel : 972-9-9702-020               Fax : 972-9-9702-001 |
  | mailto:dimita@taux01.nsc.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 1993
 
  

 


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

-- 
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 Wed Dec 5 08:32:55 2007

This archive was generated by hypermail 2.1.8 : Wed Dec 05 2007 - 08:33:53 PST