RE: [IBIS-Users] Differences between Hspice netlist simulation and Hspice B-element simulation - bug or feature?

From: Sam Chitwood <samchitwood_at_.....>
Date: Mon Aug 07 2006 - 09:10:07 PDT
Hi Radovan,

A 0ps rise time is ok for IBIS because the stimulus signal is simply a
trigger for the algorithms to start the transitions; there is nothing
physical associated with the stimulus node.  However, this is typically not
true for transistor-level models so different stimuli are required.

A number of EDA tools (but probably not all) use the 0.2 V and 0.8 V trigger
points (mainly so that HSPICE decks can be directly used in other tools).
This was established a long time ago.  The IBIS forum does not commonly
discuss 'how' EDA companies should implement capabilities - read the IBIS
spec. on Series MOSFET for an example.  :-)

A percentage of the voltage rail could have been used for the trigger
points, but that might require unique stimuli for each rail (and each
typ/min/max).  The fixed 0.2 and 0.8 scheme allows users to create a
database of trigger sub-circuits that can be used with any supply voltage.
Now that you know how it works, I think you'll find it useful.

I hope I've answered some of your questions.
Thanks,

Sam


-----Original Message-----
From: owner-ibis-users@server.eda-stds.org
[mailto:owner-ibis-users@server.eda-stds.org] On Behalf Of
Radovan.Vuletic@qimonda.com
Sent: Monday, August 07, 2006 8:30 AM
To: Xuefeng.Chen@synopsys.com; weston.beal@intel.com;
ibis-users@server.eda-stds.org
Subject: RE: [IBIS-Users] Differences between Hspice netlist simulation and
Hspice B-element simulation - bug or feature?

Hi experts,

many thanks Weston and Xuefeng for your answers. I have to apologies that it
wasn't immediately clear in my first mail, but I would never send mail to
this forum if just delaying of stimuli for 30ps would solve my problems. 
Problem was, as I wrote in my mail, that in some cases rising edge was
showing very good overlap between transistor netlist and IBIS, but falling
edges were shifted - in other cases (with some other stimuli frequencies)
falling edges were overlapping but rising edges were delayed - this problem
unfortunately can't be solved by simple shifting stimuli. Hint that Xuefeng
gave was really good (but who really reads such boring stuff as Additional
Notes in HSpice SI Guide?). So just to recapitulate for the other people who
can see/have the same problem - please find bellow the excerpt out of HSpice
SI  Guide:

"Voltage Thresholds
Voltages applied to the input and enable nodes are digital signals. They
should
be either 0 or 1. You can specify input voltage as:
V_in nd_in 0 pulse (0 3.3 0 0.5n 0.5n 4n 8n)
However, IC circuit simulation currently detects only two thresholds, 20%
and
80% of [0,1] swing, that is, 0.2V and 0.8V. If a buffer is non-inverting and
in a
LOW state, it starts the transition to a HIGH state, if V_in > 0.8V. If the
buffer is
in HIGH state, it will start the transition to LOW state, if V_in < 0.2V.
Specifying
input voltage in the range [0, 3.3V] as in the above example does not make
LOW -> HIGH transitions better in any way, but can add uncertainty over the
0.5ns time interval, when the transition actually occurs."

--- end of excerpt

Originaly I used PULSE with 100ps rising/falling time with sweep from 0 to
1.5V. (and 0.2V and 0.8V are pretty asymmetrical to this range)
When I used PULSE stimuli with 0ps rising and falling waveform and around 10
times finer resolution for simulation (.TRAN  1.36e-11 used for IBIS model
extraction and .TRAN 1ps for simulation (although Xuefeng will say that it
is perhaps not properly to say, since there is dynamic step control) I saw
significantly better data-eye diagram and very good overlap between rising
and falling edges - Nice! However, that rises a question if 0ps
rising/falling waveforms are physically justified.

Q U E S T I O N :
=================

Above mentioned problem is kind of missing definition in IBIS models (O.K.
not in definition of IBIS, but definitely for usage of IBIS models).
Shouldn't be standardized how every tool should approach simulation of IBIS
models with respect to input and enable nodes? I mean 0.2V for low and 0.8V
for high is very strange - I could accept 20% of Vdd and 80% of Vdd, but to
define input thresholds as absolute values, totally independent on
technology and supply voltage is somehow user unfriendly (however, in HSpice
it is at least mentioned in some additional note). Furthermore, it seems
that every tool vendor has freedom to treat/process stimuli to input and
enable node as she/he will. That leads to the fact that I can have several
different output waveforms although I am using same model and stimuli - but
different tool!?!

I am pretty sure that this topic was already discussed among the people that
are using IBIS, but what was the outcome?
Is there somebody who is still driving this topics? Is there intention to
standardize behavior of inputs to IBIS models?

Regards,
Radovan

-----Original Message-----
From: Xuefeng Chen [mailto:Xuefeng.Chen@synopsys.com] 
Sent: Friday, August 04, 2006 4:26 AM
To: Beal, Weston; Vuletic Radovan (QAG PD PDE MEM); ibis-users@eda-stds.org
Subject: RE: [IBIS-Users] Differences between Hspice netlist simulation and
Hspice B-element simulation - bug or feature?

Radovan,
   Weston's suggestions are very good.
   In addition, I have two points to mention when using HSPICE 

1) ".TRAN 1.36e-11 1.36e-09" does not mean exactly the time step is 13.6ps.
Dynamic time step control will be used in transient analysis. You can try
option DELMAX to set the maximum time step.

2) Input stimulus is dealt with by two voltage thresholds 0.2v and 0.8v
which decides the starting time point of buffer's transition. So it's better
to set (vhigh+vlow)/2 = 0.5 if you use PULSE voltage source as stimulus.

Of course, I think the most important thing is the waveform tables as Weston
mentioned. 

Best regards
Xuefeng







-----Original Message-----
From: owner-ibis-users@eda-stds.org [mailto:owner-ibis-users@eda-stds.org]
On Behalf Of Beal, Weston
Sent: 2006?8?4? 2:04
To: Radovan.Vuletic@qimonda.com; ibis-users@eda-stds.org
Subject: RE: [IBIS-Users] Differences between Hspice netlist simulation and
Hspice B-element simulation - bug or feature?

Radovan,

First, you should not expect the curves to line up in time. The IBIS data
does not represent all of the output buffer. Generally, the voltage at the
pin of an IBIS model will transition sooner than the voltage at the pin of a
full transistor-level model. The curves should be the same if you can slide
one in time to compensate for this time offset. Try delaying the stimulus to
the IBIS model by 30ps.

In your pictures I see that the curve shapes are still a little bit off.
It's difficult to know what causes this without seeing your simulation
files. Look at the IBIS rising and falling waveform tables to see if the
time extents are close to the actual transition. You want as many
time-points as possible describing the actual transition and not waste them
in flat regions. Different simulators deal with the flat regions at the
beginning and end of the transition in different ways.

I hope this helps a bit. Good Luck!

Regards,
Weston


-----Original Message-----
From: owner-ibis-users@server.eda-stds.org
[mailto:owner-ibis-users@server.eda-stds.org] On Behalf Of
Radovan.Vuletic@qimonda.com
Sent: Thursday, August 03, 2006 8:38 AM
To: ibis-users@server.eda-stds.org
Subject: [IBIS-Users] Differences between Hspice netlist simulation and
Hspice B-element simulation - bug or feature?

Hi experts, 

sorry that I trigger the same topic once again, but now it keeps me busy
already more than one week and I am pretty sure that the problem is not a
way how I extract IBIS model, but somewhere else! 

Before I elaborate the problem let me notice that I get the same result if I
use 2ibis2 or s2ibis3 or if I use HSpice or some company internal analog
simulator for extraction of IBIS model. 

Let me elaborate the problem: 
1. IBIS model is generated (say with s2ibis2, but irrelevant, since there is
a same result with s2ibis3) 2. I take one of spice decks for extracting
rising waveform generated by extraction tool (say a00DQ40.spi) - this should
be spice deck for generating 1st rising waveform in typical case. 
This spice deck of course contains the netlist of my circuit. 
3. I modify this spice deck only that  I instantiate in it just generated
IBIS buffer model (in step 1.) as a B-element - in other words, I just put
there IBIS model - B-element and do nothing else 4. stimuli and load for
netlist remains the same and I use exactly the same stimuli and load for
IBIS model as well (of course, netlist, IBIS model and their stimulus and
loads are separated) 5. simulate such modified spice deck with HSpice and
compare the outputs: netlist vs. IBIS model

Problem:
What I expect to get on output is very good overlap between Hspice
simulation of netlist and IBIS model, BUT what I get on output is a fact
that falling or rising edges don't overlap i.e. there is some 30ps delay
(Please take a look on attached snapshots "zoom1.gif" and "zoom2.gif").
Signal "dq_40_ohm" is output of netlist, signal "io_ron_040_hspice_typ". You
can see a real delay and not some different slopes due to different loads.

Transient analysis is done with (.TRAN 1.36e-11 1.36e-09) - i.e. simulation
step (for IBIS extraction) is 13.6ps. 

What worries me even more is a fact that in some cases (for different
stimuli frequencies) I see that rising edges are overlapping and falling are
delayed and in some cases (some other frequency of stimuli) I see that
falling edges are overlapping and rising are delayed, so I don't know even
where should I cut  ("taylor") my V-t curves when behavior seems to be so
arbitrary and frequency dependant. 

I know, some of you would say that 20-30ps are no problem, but exactly this
20-30ps are shifting (upwards or downwards) crossing point of rising and
falling edges and destroy duty cycle and data eye diagram (target is
800MHz). Problem is independent on slope of stimuli (so with 1ps slope or
100ps of slope of stimuli I see the same result) 

I know that we should not speak on this forum about tools and vendors and I
terribly apologize that I will still mention some of them - but on the end
all our models are used with some these tools and I think that it is
necessary that we exchange information about our experiences with this tools
as well. So the problem is analysed with different tools:

- I see above mentioned problem when simulating with HSpice (versions
2004.09, 2005.03 and 2006.03) netlist vs. IBIS model
- I see effect of above mentioned problem when simulating with ADS - using
only IBIS model  - rising and falling edge crossing points are shifted same
as in HSpice
- with SpecctraQuest (also simulating only with IBIS model) I see the right
results!


So I am pretty confused, what is correct? A few different simulators, but
only one is showing a right result (or at least result that I consider as a
proper).
What is your experience? Have you noticed something similar? Can somebody
from you do the same procedure on one of your designs (compare IBIS vs.
HSpice on the same way as I done)?

Has somebody an idea, proposal?

Best regards / Mit freundlichen Grüßen / S po¹tovanjem Radovan Vuletic

Qimonda AG
QAG PD PDE
MUC/10.2.236 AP 3
Am Campeon 1-12
D-85579 Neuebiberg

Phone:		+49 (0)89 234 20108
Fax (PC):	+49 (0)89 234 955 5305 

E-mail: radovan.vuletic@qimonda.com
 <<zoom2.gif>>  <<zoom1.gif>> 

--------------------------------------------------------------------
|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

--------------------------------------------------------------------
|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


--------------------------------------------------------------------
|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 Aug 7 09:10:12 2006

This archive was generated by hypermail 2.1.8 : Mon Aug 07 2006 - 09:11:30 PDT