RE: [IBIS-Users] RE: [IBIS] RE: IBIS model behavior between Vinh and Vinl input

From: Akhilesh CHANDRA <akhilesh.chandra_at_.....>
Date: Mon Jan 14 2008 - 20:44:14 PST
Hello Todd,

    I am agree with you that present input receiver model are not enough
correct for complete analysis. I will make new BIRD to define better way to
make IBIS model for input receiver. Your feedback are important to make it
more useful in all application.

Regards
Akhilesh 

-----Original Message-----
From: owner-ibis@server.eda.org [mailto:owner-ibis@server.eda.org] On Behalf
Of Todd Westerhoff
Sent: Monday, January 07, 2008 9:06 PM
To: ibis@server.eda-stds.org; ibis-users@server.eda.org
Subject: RE: [IBIS-Users] RE: [IBIS] RE: IBIS model behavior between Vinh
and Vinl input

Akhilesh,

Now I think I've got it - you're talking about instantiating an IBIS input
buffer in your simulation, and looking at the signal at the input buffer's
output pin?

I've always considered IBIS to be a pad to pad spec (with the exception of
[External Model]) and as such, I haven't paid much attention to what comes
out of the far end of the input buffer.  You can propose a BIRD to define
that behavior more clearly, although I'm concerned that people will believe
the result is more meaningful than it is.  Input buffers have
characteristics that IBIS has no current ability to model - propagation
delay, for instance.  

I still believe the issue at the root of this discussion is a timing issue.
Why do we perform signal integrity simulations?  To ensure our designs will
work before we build them.  How do we prove that?  We demonstrate that the
design has adequate timing and voltage margin under all anticipated
operating conditions.

My point is that timing and signal integrity go hand in hand.  One of the
fundamental goals of signal integrity is derivation of interconnect delays
that can be used to assess whether a system will achieve target timing
margins.  The way you need to perform signal integrity simulations and
measure interconnect delays is critically dependent on the way component
timing is specified, which is driven by the way that parts are tested and
qualified in production.

I don't believe you can establish voltage thresholds for your IBIS models
without understanding how your components are tested in production.
Datasheet setup and hold specs are predicated on testing the device under
specific conditions, with specific edge rates on the clock and data inputs,
and measuring delays based on specific voltage levels.  Signal integrity
analysis derives interconnect delays that are combined with data sheet
timing numbers during timing analysis.  If you don't "normalize"
interconnect delays properly based on component timing specs, then you're
not going to correctly predict the system's actual timing margins.
 
Spice studies will tell you a lot about how an input buffer actually
behaves, but you still need to normalize simulation results based on
datasheet timing ... which leads into a discussion of simulation timing
thresholds, waveform quality thresholds, the difference between the two, and
IBIS.
That's a much longer discussion, but the bottom line is that you need a lot
more than just Vinl and Vinh to get the whole timing/SI job done for high
performance components.

The process of normalizing interconnect delays gets pretty involved, and is
difficult to communicate through text-based email. SiSoft is presenting a
Webinar on DDR3 later this month that talks to the concept of interconnect
delay normalization and the errors that can result from improper analysis.
SiSoft will also be presenting a paper at Designcon (Feb 6, Session 6-WP1)
that talks to the subject in more detail.  You can find more information on
both these presentations at www.sisoft.com if you're interested.

Hope that helps,

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: Akhilesh CHANDRA [mailto:akhilesh.chandra@st.com]
Sent: Sunday, January 06, 2008 7:45 AM
To: 'Todd Westerhoff'; ibis@eda-stds.org; owner-ibis-users@eda.org;
ibis-users@eda.org
Cc: Akhilesh CHANDRA
Subject: RE: [IBIS-Users] RE: [IBIS] RE: IBIS model behavior between Vinh
and Vinl input

I am talking about receiver of a design. I don't have issue with switching
point I have doubt about the IBIS models behavior between Vinh and VINL
values of receiver. Our receiver model have vinh and vinl values that we
extract from spice simulation. When we run simulation with our IBIS models
then till Vinl output is 0V and above Vinh it's 1V. Most of the simulator
show this behavior.

  What about the output when input is between Vinh and Vinl. IBIS spec say
output should be X but what is X. Different simulator interpreted it by
different way, some show 0.5V other show a smooth transition of output
between Vinh and vinl. In my view we will need to define IBIS behavior
between vinh and Vinl. 


Regards
Akhilesh
-----Original Message-----
From: owner-ibis@server.eda.org [mailto:owner-ibis@server.eda.org] On Behalf
Of Todd Westerhoff
Sent: Friday, January 04, 2008 11:57 PM
To: ibis@server.eda-stds.org; owner-ibis-users@server.eda.org;
ibis-users@server.eda.org
Subject: RE: [IBIS-Users] RE: [IBIS] RE: IBIS model behavior between Vinh
and Vinl input

All,

I'm going to jump in the middle here, even though I didn't have the time to
read this thread as thoroughly as I would have like.

I'm confused by what Akhilesh is describing.  Akhilesh, are you saying your
driver can't drive the receiver's input pin beyond the VIL and VIH
thresholds?  If that is truly the case, then you need to consider the
datasheet specifications for your receiving device very carefully.  It's not
a matter of what thresholds you have in an IBIS models you received (they
may not be correct), nor is it a matter of what behavior a HSPICE model of
the input buffer might exhibit.  It's a matter of how the part's performance
is specified and guaranteed, and that's in the datasheet.

There can be a difference between the thresholds a signal is timed to, and
the thresholds that a switching signal must ultimately attain to ensure a
valid switching event.  Distinguishing between "signal quality" and "signal
timing" thresholds in IBIS models can get pretty tricky, even for those of
us who've been at it a while.

What caught my eye was your initial description of the buffer as a
"hysteresis buffer", although I don't know if you meant the driving or
receiving device.  If you meant the receiving device, it could well be the
case that the part is _timed_ to a voltage between the VIL and VIH
thresholds, but chances are, the signal still has to _attain_ VIL and VIH
thresholds to be valid.

The device timing specifications are key to understanding what simulations
to perform and how to interpret the results.

Hope that helps,

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@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Tom
Dagostino
Sent: Friday, January 04, 2008 1:02 PM
To: 'Muranyi, Arpad'; 'Akhilesh CHANDRA'; ibis@eda-stds.org;
owner-ibis-users@eda.org; ibis-users@eda.org
Subject: RE: [IBIS-Users] RE: [IBIS] RE: IBIS model behavior between Vinh
and Vinl input

Arpad

I think we are in agreement.  I took Akhilesh's comment:

IBIS specs don't define that how logic X represent in IBIS simulation, Due
to this different simulator give different behavior for X. In my view we
will need to define how logic X represent in IBIS model simulation. It will
help to align all the simulator results.

To mean that he wanted to define X as a 1 or 0.  

Tom Dagostino
Teraspeed(R) Labs
13610 SW Harness Lane
Beaverton, OR 97008
503-430-1065
503-430-1285 FAX
tom@teraspeed.com
www.teraspeed.com

Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
401-284-1827 


-----Original Message-----
From: owner-ibis@server.eda.org [mailto:owner-ibis@server.eda.org] On Behalf
Of Muranyi, Arpad
Sent: Friday, January 04, 2008 9:41 AM
To: tom@teraspeed.com; Akhilesh CHANDRA; ibis@server.eda-stds.org;
owner-ibis-users@server.eda.org; ibis-users@server.eda.org
Subject: RE: [IBIS-Users] RE: [IBIS] RE: IBIS model behavior between Vinh
and Vinl input

Tom,

I may disagree with you on this one.  The 1 volt and 0 volt representation
of "true" and "false" is just as "unreal" as an "X".  None of these are
actual waveforms.  These are indicators which tells you whether the input
signal was below, above, or between Vinh and Vinl.  I think it is plain
wrong to have a "1" or a "0" on the output of the receiver when the signal
is between Vinh and Vinl and it misleads the user of these tools thinking
that they have good signal integrity while they have problems.

I fully agree that digital parts are not made to operate with waveforms
between Vinh and Vinl.  Ant that is exactly the reason we should have an
output value of "X" to find out when the waveforms are in that region.
And that fact that you described that the "actual output ... will change"
is exactly the reason for the "X", because we simply don't know what it will
be.  It is not guaranteed that it will be a "1" or a "0".  How do you
describe that if not with an "X"?

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

-----Original Message-----
From: Tom Dagostino [mailto:tom@teraspeed.com]
Sent: Friday, January 04, 2008 1:34 AM
To: 'Akhilesh CHANDRA'; Muranyi, Arpad; ibis@server.eda-stds.org;
owner-ibis-users@server.eda.org; ibis-users@server.eda.org
Subject: RE: [IBIS-Users] RE: [IBIS] RE: IBIS model behavior between Vinh
and Vinl input

...
...
...

But having all simulators default to some arbitrary state when the input is
between the reference levels is setting the user up for failure.  People
tend to assume if the simulator says X, X is real.  If they don't see X in
the real circuit then there is something wrong.  Not all parts will conform
to some arbitrarily designated state.

Digital parts are not made to operate with their inputs between Vinh and
Vinl.  Most parts have specifications that state the minimum slew rate
(input risetime/falltime) as the input to the part transitions between the
two reference levels.  The actual output of an input buffer for a given
input voltage between Vinl and Vinh will change depending on the internal
noise of the IC, the noise on the input, process, temperature, voltage,
phase of the moon, crosstalk, etc.

Tom Dagostino
Teraspeed(R) Labs
13610 SW Harness Lane
Beaverton, OR 97008
503-430-1065
503-430-1285 FAX
tom@teraspeed.com
www.teraspeed.com

Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
401-284-1827

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


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


-- 
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 14 20:45:27 2008

This archive was generated by hypermail 2.1.8 : Mon Jan 14 2008 - 20:46:36 PST