Please review prior to Thursday's (3/19/98 3:00PM)
meeting.
If you're not attending the meeting, and have
comments, please respond to Greg Edlund
at <[email protected]>
Thank You.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Proposal for an IBIS Accuracy Specification
>
>
>REQUESTER: Greg Edlund, Digital Equipment Corp., for the IBIS
>Accuracy Sub-Committee
>
>DATE SUBMITTED: 03/19/98
>DATE REVISED:
>DATE ACCEPTED BY IBIS OPEN FORUM:
>
>************************************************************************
>*******
>************************************************************************
>*******
>
>STATEMENT OF THE ISSUE:
>
> IBIS users need to know the level of accuracy for the models
>they are using. The IBIS models that are available today span a broad
>range of accuracy, and a user has no sure way of knowing how well he or
>she can expect system hardware to agree with behavioral simulations
>based on those models. This situation forces a user to choose between
>two undesirable paths: releasing hardware with unknown noise and timing
>margins or trying to develop his or her own IBIS models from sparse
>data.
>
>************************************************************************
>*******
>
>PROPOSED RESOLUTION:
>
> The IBIS Accuracy Sub-Committee and the IBIS Users Group propose
>an IBIS Accuracy Specification. This would take the form of a Word
>document that contains appropriate schematics, drawings, and tables.
>The IBIS Accuracy Specification is really a document unto itself rather
>than an amendment to IBIS since it is in essence different than IBIS.
>Therefore, the document you are reading is a proposal rather than a
>BIRD. By design the IBIS Accuracy Specification is a definition of a
>metric by which to measure accuracy. IBIS itself is a format for
>behavioral model parameters. We also expect to produce some material
>which is related to implementation but which would be best suited for
>inclusion in the IBIS Cookbook.
>
> The IBIS Accuracy Specification will become a document of
>understanding between IBIS model creators and IBIS model users. When a
>user calls for an accurate IBIS model in a component purchase
>specification, both the user and the semiconductor manufacturer will
>know exactly what each other means by accurate. We see semiconductor
>manufacturers becoming the primary creators of IBIS models since they
>are the owners of the source data necessary to create an IBIS model.
>
> The following is an outline of the proposed an IBIS Accuracy
>Specification:
>
> 1. Scope
> * Define which IBIS features and
>driver families to cover.
> * Define different levels of
>accuracy so the user can decide which is appropriate for his or her own
>application.
> 2. Test Loads
> * Define a minimum set of test
>loads appropriate for the IBIS features and driver families covered.
> 3. Measurement Techniques
> * Provide selection criteria for
>test equipment.
> * Describe how to account for the
>electrical characteristics of the test environment.
> 4. Comparison Metrics
> * Define a curve overlay metric
>for use when IC processing conditions are known.
> * Define an envelope metric for
>use when IC processing conditions are unknown.
> * Define a tabular format for
>reporting the results of the above comparisons.
> * Write a C program which
>implements the above metrics and creates a summary table.
>
>
> The intent behind the IBIS Accuracy Specification is to produce
>a document that is as simple as possible and yet complete. If we are to
>be successful, we need to focus on ease of implementation from the
>perspective of the semiconductor manufacturer. Toward this end, we hope
>some IBIS veterans will provide occasional editorial assistance to help
>keep us on track. As we reach milestones in the development process, we
>will publish our work for review by the IBIS Committee and Open Forum.
>If the first revision of the IBIS Accuracy Specification passes, it will
>become a an EIA-approved standard.
>
>************************************************************************
>*******
>
>DATA AND ANALYSIS:
>
> The idea of an IBIS Accuracy Specification was hatched at the
>second meeting of the IBIS User's Group on December 4, 1997. These
>meetings have been attended by some thirty to forty signal integrity
>engineers who represent a depth of system design experience and a broad
>base of system, semiconductor, and EDA firms. A common thread began to
>emerge: model quality has been a significant concern for decades,
>beginning with SPICE and continuing today with IBIS. We all agreed that
>signal integrity engineers spend far too many scarce resources
>addressing model issues; this detracts from job at hand, which is to
>solve system-level circuitry problems. We also agreed that in order for
>IBIS to continue making forward progress - and all seemed interested in
>this - we need to establish some process for assessing IBIS model
>accuracy.
>
> Among the model problems that we have uncovered over the years,
>perhaps the most common can be characterized as SPICE models that are
>not extracted from the I/O cell layout. IBIS models that are based on
>SPICE models can share this same problem. Since we are bound by
>intellectual property agreements, we are unable to disclose specific
>examples. ESD diode characteristics are certainly one of the more
>common problem areas, perhaps because extraction programs often do not
>handle them properly. Another problem is that the vendor may
>characterize the model under a standard load - typically a 50 pF
>capacitor - and does not consider a transmission line load. We are
>proposing at least two additional test loads: a transmission line
>terminated into its characteristic impedance and an open-ended
>transmission line, which checks the reflection coefficient of the I/O
>buffer. These techniques are outlined in a paper presented at
>DesignCon98 by Haller and Edlund, "Constructing Accurate Behavioral
>Models of I/O Buffers." There is always the possibility with SPICE
>models that the transistor model parameters do not reflect the true IC
>fabrication conditions; this indicates a process control problem.
>However, this kind of problem is very difficult for a system engineer to
>diagnose if he or she does not have access to data from process and
>model parameter monitors; this one reason why the semiconductor
>manufacturer is the logical origin of IBIS models.
>
> In addition to the problems mentioned above, IBIS models
>introduce another level of possible discrepancies between simulation and
>hardware. For example, the modeling engineer may not have made use of
>the IBIS features, e.g. VT tables, that were required to accurately
>model a given I/O buffer. If the modeling engineer did not spend enough
>time with the model, the user may find that it is not accurate over a
>broad range of loading conditions. And when IBIS models are derived
>from a single sample component, one is always left with the question of
>where the sample lies in relation to typical, fast, and slow silicon.
>
> The IBIS Accuracy Sub-Committee has designed and built a simple
>test board which demonstrates the techniques required to verify IBIS
>model accuracy for a 16821 CMOS push-pull output buffer. The
>device-under-test (DUT) drives a variety of test loads, as mentioned
>above. A second DUT is connected to test structures which facilitate
>measurement of IV curves and capacitance. When we finish debugging this
>board, we will post the schematics, layer plots, Gerber files, test
>procedures, and characterization report on the IBIS Web page.
>
>************************************************************************
>*******
>
>ANY OTHER BACKGROUND INFORMATION:
>
> "The purpose of the IBIS Accuracy Sub-Committee is to draft a
>specification for a metric which may be used to measure IBIS models
>against test silicon. It is our intention to have a specification
>approved by January 1999 and to identify a semiconductor manufacturer to
>serve as a beta site for the implementation of this specification by the
>same date."
>
> The IBIS Accuracy Sub-Committee has strong representation from
>the semiconductor, EDA, and system industries. We are already well on
>the way toward implementation by two major semiconductor companies,
>Fairchild Semiconductor and Texas Instruments.
>
> Greg Edlund, Digital Equipment (chair)
> Fawn Engelmann, EMC
> Greg Fitzgerald, Cadence Design Systems
> Bob Haller, Digital Equipment
> Bruce Heilbrunn, Stratus Computer
> Peter LaFlamme, Fairchild Semiconductor
> Harvey Stiegler, Texas Instruments
>
>************************************************************************
>*******
>
>
>----------
>Greg Edlund, Principal Engineer
>Server Product Development
>Digital Equipment Corp.
>129 Parker St. PKO3-1/20C
>Maynard, MA 01754
>(978) 493-4157 voice
>(978) 493-0941 FAX
>[email protected]
>
>