RE: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour

From: Muranyi, Arpad <arpad.muranyi_at_.....>
Date: Mon Jan 15 2007 - 08:23:48 PST
Todd,

Your explanation is excellent, couldn't
have done it any better.

Thanks,

Arpad
=======================================


-----Original Message-----
From: owner-ibis@server.eda.org [mailto:owner-ibis@server.eda.org] On Behalf Of Todd Westerhoff
Sent: Monday, January 15, 2007 7:16 AM
To: 'Dimitry Eisenshtat'
Cc: ibis@server.eda-stds.org; ibis-users@server.eda.org
Subject: RE: [IBIS-Users] RE: [IBIS] Ibis open drain strange behaviour

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)


-- 
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 08:24:17 2007

This archive was generated by hypermail 2.1.8 : Mon Jan 15 2007 - 08:24:51 PST