Subject: IBIS BUG41 Arguments

From: Bob Ross <[email-masked]>
Date: Mon, 22 May 2000 14:18:46 -0700

To All:

One of the discussion topics at the May 26, 2000 IBIS teleconference
meeting will be BUG41.  Currently ibischk3 reports an Error if 
the same pin is used for more that one differential input described
under the [Diff Pin] keyword.  BUG41 proposes to relax this to a
Warning message.

This issue arose with respect to describing SSTL-2 inputs whose inputs
are physically differential buffers connected to a common, external
reference voltage (designated VREF, but different from the timing test
load Vref)

There is no explicit statement in IBIS that prohibits using the same
pin for several differential inputs.  We did not anticipate this
application, and the Error report was designed in ibischk3.

The purpose of this document is to collect arguments in favor and
against making the ibischk3 parser change (and related Specification
clarification).

More arguments and discussions are welcome.  BIRD41 is at the end for
reference.

Bob Ross
Mentor Graphics

Arguments in Favor:

1. Not prohibited in IBIS.
2. Physical part uses differential inputs
3. Effect of VREF noise on timing needs to be considered - can be handled
   directly with differential inputs
4. Current [Pin Mapping] keyword provides no association with VREF
   supplies or dividers.
5. Changing ibischk3 test from Error to Warning still alerts model
   developer if a pin is used several times for differential inputs.
6. Supports some extreme cases (beyond the Spec.) where voltages are
   actually changed on VREF to set logic states.
7. VREF referenced input structures are becoming common-place.

Arguments Against:

1. While not prohibited, this application was not intended as confirmed by
   the ibischk3 Error.
2. Incompatible to some (but not necessarily all) EDA tools implementations
   for differential buffer analysis.
3. Contrary to a fundamental notion that differential nets should have
   complimentary signals.
4. Single-ended and differential timing testing methods may be different
   (crossover versus VREF)
5. Differential net layout driven by IBIS Model may be inconsistent (e.g.,
   should VREF line be matched time or length, or how will the inverting
   VREF line be designed for controlled differential impedance with all other
   non-inverting lines.

6. Nets are really driven by single-ended drivers, so they are functionally
   single-ended.
7. Model developers (and EDA tools) may ignore Warning messages.
8. BIRD62.6 was designed to handle this type of network reference to VREF.
9. Should not have different input if VREF is not available externally.

---------------------------------------------------------------------------

******************************************************************************
********************* IBIS GOLDEN PARSER BUG REPORT FORM *********************
******************************************************************************

INSTRUCTIONS

To report a bug in the IBIS golden parser.  Please fill out the top part
of the following form and send the complete form to [email-masked].

A list of reported bugs will be maintained on vhdl.org.

******************************************************************************

PARSER VERSION NUMBER: IBIS_CHK V3.2.5

PLATFORM (SPARC, HP700, PC, etc.):  SPARC

OS AND VERSION:  Solaris

REPORTED BY:  Bob Ross, Mentor Graphics
              (Based on discussions with Stephen Nolan, Texas Instrumens)

DATE:  May 9, 2000

DESCRIPTION OF BUG:
The parser should be changed to issue a Warning message instead of an Error
message when common pins are used for differential pins.

(The error can be preserved when the common pin positioned both as a 
non-inverting and also as an inverting pin.)

This change is requested because of SSTL-2 and SSTL-3 technology where
common pins are used for VREF and the buffers are constructed using
differential inputs and IBIS Version 3.2 does not specificly prohibit having
a common pin for more than one differential buffer.

The file below currently generates the following messages:

Checking bug41.ibs for IBIS 3.2 Compatibility...

ERROR - Component 'Test': inv_pin '3' is not unique.
ERROR - Component 'Test': Diff_pin '3' already in use as an inv_pin.
ERROR - Component 'Test': Diff_pin '3' already in use as an inv_pin.
ERROR - Component 'Test': [Series Pin Mapping] Pin2 '2': model type cannot be
Series or Series_switch.

Errors  : 4

File Failed

Note, only the first error would be changed to a Warning.  The second and
third error would remain because it is caused the the last line under
[Diff Pin] which puts the non-inverting common pin as an inverting pin.
the last error is covered by BUG40.

Also note, the Series elements can be connected to common pins. 

INSERT IBIS FILE DEMONSTRATING THE BUG:

|
|***************************************************************
|
|
[IBIS Ver]      3.2
[Comment Char]  |_char
[File Name]     bug41.ibs
[File Rev]      1.0
[Date]          May 9, 2000

[Component]      Test
[Manufacturer]   Test File
[Package]
| variable      typ             min             max
R_pkg           0.0m            NA              NA
L_pkg           0.0nH           NA              NA
C_pkg           0.0pF           NA              NA
|
[Pin]        signal_name     model_name       R_pin   L_pin   C_pin
  1             PAD            In         NA      NA      NA
  2             PAD            In         NA      NA      NA

  3             VTT            POWER         NA      NA      NA
  4             PADN           In         NA      NA      NA

|
|
[Series Pin Mapping]  pin_2    model_name    function_table_group
        1               2      Rseries
        2               3      Rseries

[Diff Pin]  inv_pin  vdiff  tdelay_typ tdelay_min tdelay_max
|
 1           3       150mV    -0ns        NA        NA
 2           3       150mV      0ns        NA        NA  
 3           4       150mV      0ns        NA        NA  

|
|****************************************************************
|                         MODEL Rseries
|****************************************************************
[Model]            Rseries
Model_type         Series
|
C_comp                   0.02pF   0.01pF  0.03pF
[Voltage Range]          2.50     2.30    2.70
|
| variable      R(typ)      R(min)     R(max)
[R Series]      100ohm      90ohm      110ohm
|
|
|****************************************************************
|                         MODEL Term
|****************************************************************
|
|
[Model]            Term
Model_type         Terminator
Vinl  = 1.25V
Vinh = 2.5
C_comp                   0.02pF   0.01pF  0.03pF
[Voltage Range]          2.50     2.30    2.70
|

|****************************************************************
|                         MODEL In
|****************************************************************
|
[Model]            In
Model_type         Input
Vinl  = 1.25V
Vinh = 2.5
C_comp                   0.02pF   0.01pF  0.03pF
[Voltage Range]          2.50     2.30    2.70
|
|****************************************************************
|                         MODEL Out
|****************************************************************
|
[Model]            Out
Model_type         Output
Vmeas  = 1.25V
C_comp                   0.02pF   0.01pF  0.03pF
[Voltage Range]          2.50     2.30    2.70
|
[Pulldown]
-5  -1  -1  -1
10   2   2   2
[Pullup]
-5   1   1   1
10  -2  -2  -2
[Ramp]
dV/dt_r  1/1n 1/1n 1/1n
dV/dt_f  1/1n 1/1n 1/1n
|
[End]

******************************************************************************
******************** BELOW FOR ADMINISTRATION AND TRACKING *******************
******************************************************************************

BUG NUMBER: 41

SEVERITY: [FATAL, SEVERE, MODERATE, ANNOYING, ENHANCEMENT] 

PRIORITY: [HIGH, MEDIUM, LOW]                                

STATUS: [OPEN, CLOSED, WILL NOT FIX, NOT A BUG]               

FIXED VERSION:  

FIXED DATE:

NOTES ON BUG FIX:

---

From: Scott McMorrow <[email-masked]>
Date: Mon, 22 May 2000 18:36:50 -0700

Bob,

Having had some very recent experience with simulating and
measuring Vref noise and it's effect on timing, I will give my
input.

1) If this application of differential inputs is intended to
"trick" an IBIS simulator into allowing a variable input threshold
without modifying the IBIS model, then I believe this would be
a reasonable application.  In this case, Vref truly acts like
a static voltage.

2) If this application is intended to account for noise effects
on input timing, I would suggest that this will not be very
accurate at all. For the following reasons:

    a) Vref has a propensity to pick up noise from the power
and ground planes in the GHz region from minor plane
resonances that occur.  These effects will not be modeled
in any reasonable time by any known simulator.

    b) Vref inputs on devices are extremely complex and are
generally not direct connections to the receiver differential
amplifiers.  Among manufacturers of devices there are various
methods of filtering Vref on the die to exclude external and
internally generated noise.  We  mortals will most likely never
have access to the actual on-chip vref circuits decks.  These
are the "secret sauce" that makes a particular device out perform
the other competition.

    c) Vref is subject to displacement currents originating from
the input transistors of the receiving device.  Internal parasitic
gate capacitance can cause some significant currents.
(See b) above.)

Thus, my feed back to the IBIS committee is that I would not
be opposed to modifying the parser to generate a warning
when a pin is mapped to multiple differential inputs, however
I would make this a VERY STRONG warning indeed.  What is
actually simulated will not be close to the real circuit at all, if one
is concerned with the AC transient response of the entire
system of Vref and single ended inputs.  Although I must say
it is a nice "trick" to easily generate a variable switching
threshold.

best regards,

scott

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.com

---

From: Stephen Nolan <[email-masked]>
Date: Tue, 23 May 2000 08:45:30 -0500

Scott, 

Please let me address your comments.

> a reasonable application.  In this case, Vref truly acts like

Vref could be used this way. In fact, when taken to the extreme, Vref can also
be used as an inverting logic input that forces all the outputs to a known logic
level.

> accurate at all. For the following reasons:

I disagree. And, in fact IBM made a very compelling showing recently at the
Future DRAM Task Group Meeting in San Jose that a small amount of shift in Vref
(or the crossing voltage) can cause a significant shift in the timing. So it is
VERY important to be able to model these effects.

> in any reasonable time by any known simulator.

Vref might not be a separate plane.  Vref could simply be a trace on a signal
plane that is subject to the same effects as any other signal trace (eg. xtalk,
common-mode noise).

> are the "secret sauce" that makes a particular device out perform

On simple logic devices, Vref DOES simply tie to the other side of the
differential input. See the attached datasheet for an example of a device that
we are trying to provide a model for TODAY!

> gate capacitance can cause some significant currents.

Doesn't C_comp take care of this?

-- 
Regards,
Stephen M. Nolan

---

From: Stephen Nolan <[email-masked]>
Date: Tue, 23 May 2000 09:10:04 -0500

All,

In case you are not familiar with the JEDEC SSTL specifications, I have attached
the SSTL_2 spec. This is the technology that is driving this BUG report.
-- 
Regards,
Stephen M. Nolan