Re: IBIS BUG41 Arguments

From: Stephen Nolan <s-nolan1@ti.com>
Date: Tue May 23 2000 - 07:10:04 PDT

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

Received on Tue May 23 07:11:14 2000

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT