RE: [IBIS-Users] VT Data Length Mismatch and Over Clocking

From: Lance Wang <lwang@iometh.com>
Date: Wed May 25 2011 - 12:51:28 PDT

I think it is depended on how good the simulator's
interpolation/extrapolation method and overclocking handling algorithm for
IBIS models are.

 

You can do some simple tests to find out:

1. Increase bit width (UI) . if it is solved, it confirms overclocking
issue;

2. Adding the extra last points to make it flat. If it is solved, it
confirms interpolation/extrapolation issue;

 

So far, I haven't seen any simulator has the issue with different length VT
curves.

 

BTW, if you have issues with you IV curves even if it is without vt/iv match
errors, the simulators may use a "smoothing" method trying to fix it. It
could cause all the weird issues though.

 

Just FYI.

 

Best regards,

 

Lance Wang

IO Methodology Inc.

978-266-8981

 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
Of Mike LaBonte
Sent: Wednesday, May 25, 2011 3:07 PM
To: tom@teraspeed.com; 'Prabhat Ranjan'; 'Timothy Coyle'
Cc: IBIS
Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking

 

I think "By definition all time after a VT table has ended should equal the
last point in the VT table until a new transition occurs." raises an
interesting question. Since many V-T curves don't ever settle and the
calculated endpoint currents don't match the I-V curves perfectly, how many
simulators freeze the K factors when V-T data runs out as Tom suggested, and
how many allow the K factors go all the way to 0 or 100% after V-T data runs
out? The exact high and low state voltages would be different depending on
which approach was used.

Mike

On 5/25/11 12:18 PM, "Tom Dagostino" <tom@teraspeed.com> wrote:

I guess I'm surprised this causes an issue. I don't recall seeing anything
in the IBIS spec requiring equal length VT tables. By definition all time
after a VT table has ended should equal the last point in the VT table until
a new transition occurs.
 
I also see a lot of parts that have different output amplitude
specifications at low frequencies vs. high frequency. This implies the part
was never designed to have finished transitions at the fastest toggle rate
of the buffer. So overclocking is a reality in modern parts.
 
There are many parts that have much faster falling transition than rising.
A good example of this is an open sink. Others include RS232 and the like.
And I've seen many more normal totem pole outputs exhibit the same
characteristics. And I've seen the reverse where the rise is much faster
than the fall by a factor or 3 to 5. Why should the rising table(s) have
the same time duration as the falling?
 
Tom Dagostino
 
Teraspeed Labs
9999 SW Wilshire St.
Suite 102
Portland, OR 97225
USA
 
971-279-5325 Office
971-279-5326 FAX
503-430-1065 Cell
 
tom@teraspeed.com
www.teraspeed.com <http://www.teraspeed.com/>
 
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
401-284-1827
 
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
Of Prabhat Ranjan
Sent: Wednesday, May 25, 2011 8:22 AM
To: Timothy Coyle
Cc: ibis-users@eda.org
Subject: Re: [IBIS-Users] VT Data Length Mismatch and Over Clocking

Hello Timothy,

I have also came across the same problem with one simulator where different
time lengths of V-T waveform gave me completely wrong results and just
making all tables equal by adding same last point has solved the problem.
Simulator vendor has accepted it as bug in tool.

Various simulators take care this issue internally by extending the last
points to make them equal.Thats why, somewhere it is recommended to have
same two last points in VT curve. I have checked the same model with 2-3
another simulators and all of them give correct results with different time
length.

Regards
Prabhat

On Wed, May 25, 2011 at 8:14 PM, Timothy Coyle <tim.coyle@siconsultant.com>
wrote:

Hi,
I'm starting to run across quite a few IBIS models that have different time
lengths in the V-T waveforms even for corresponding loads. For example, a
Rising Waveform with 50 Ohms to Ground may have a total time of 5ns but the
equivalent Falling Waveform with 50 Ohms to Ground may have a total time of
10ns. So between the four different V-T waveforms they can all have a
different total time length. All of the waveforms transition to a "steady
state" but I'm wondering if this will cause potential problems in IBIS
simulators?
 
I know a lot of IBIS simulators say they can handle an over-clocked IBIS
model but will this cause even more issues? I've also actually started to
see a few models that say they must be over clocked to run properly
(apparently model developer had issues getting VT waveform to reach steady
state within bit time)
 
I would think that the VT waveform total lengths should be matched based
upon that they are used to define rise/fall transitions but clearly it all
depends on how EDA IBIS simulator processes this data. It's difficult to do
this type of correlation in multiple tools and without access to the
original SPICE model but wanted to see if anyone else is running into this
issue or can see potential issues with this type of model?
 
Best,
 
Timothy Coyle
President
Signal Consulting Group LLC
405 Western Ave #430
South Portland, ME 04106
Tel: 617.297.2566
Email: tim.coyle@siconsultant.com
Web: http://www.siconsultant.com <http://www.siconsultant.com/>
SharkSim <http://www.sharksim.com/> - Signal Integrity IBIS Modeling
Software

-- 
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 May 25 12:51:57 2011

This archive was generated by hypermail 2.1.8 : Wed May 25 2011 - 12:53:21 PDT