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

From: Ummalaneni, Venu Babu (Venu) <Venu.Ummalaneni_at_.....>
Date: Wed Dec 05 2007 - 02:17:10 PST
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 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 02:18:22 2007

This archive was generated by hypermail 2.1.8 : Wed Dec 05 2007 - 02:19:23 PST