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

From: Amit KUMAR <amit-hpc.kumar_at_.....>
Date: Thu Nov 29 2007 - 03:29:07 PST
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 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 Thu Nov 29 03:31:02 2007

This archive was generated by hypermail 2.1.8 : Thu Nov 29 2007 - 03:32:42 PST