Re: IBIS BUG41 Arguments

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

Bob Ross wrote:

> 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 ibischk-bug@vhdl.org.
>
> 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:

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