Text item: Text_1
Date: February 28, 1994
From: Derrick Duehren (503) 696-4299, fax (503) 696-4904
Derrick_Duehren@ccm.jf.intel.com
Intel Program Manager
(Will Hobb's IBIS Assistant)
Intel Corporation
5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA
and
Will Hobbs (503) 696-4369, fax (503) 696-4210
Intel Modeling Manager
Subject: Minutes from IBIS Open Forum 2/18/94
To:
Anacad Steffen Rochel
Ansoft Henri Maramis
Atmel Corporation Dan Terry
Cadence Design Sandeep Khanna, Chris Reed,
Pawel Chadzynski, Kumar*
Contec Maah Sango*, Dermott Lynch,
Clark Cochran, Mike Venthon
Digital Equipment Corp. Barry Katz*
High Design Technology Michael Smith
HyperLynx Steve Kaufer, Kellee Crisafulli*
IBM Jay Diepenbrock*
IBM-Motorola alliance Lynn Warriner*, Hoa Quoc*, John Burnett*
Integrity Engineering Greg Doyle, Wayne Olhoft
Intel Corporation Stephen Peters*, Don Telian, Will Hobbs*
Arpad Muranyi*, Derrick Duehren*
Interconnectix, Inc. Bob Ross*
Intergraph Ian Dodd, David Wiens
IntuSoft Charles Hymowitz
Logic Modeling Corp. Randy Harr
Mentor Graphics Greg Seltzer, Ravender Goyal
Meta-Software Mei Wong, Mei-Ling Wei
MicroSim Arthur Wong*, Jerry Brown, Graham Bell
National Semiconductor Syed Huq*
North Carolina State U. Paul Franzon, Michael Steer, Steve Lipa
Performance Signal Integrity Vivek Raghawan, Eric Bracken*
Quad Design Jon Powell
Quantic Labs Mike Ventham, Zhen Mu
Racal-Redac John Berrie*
Siemens Nixdorf Werner Rissiek, Olaf Rethmeier*
Texas Instruments Bob Ward
Thomson-CSF/SCTF Jean Lebrun
Zeelan Technology Hiro Moriyasu, George Opsahl
CC:
Intel Corporation Randy Wilhelm, Jerry Budelman,
Intel IBIS team
In the list above, attendees at the 2/18/94 meeting are indicated by *
Upcoming Meetings: Date: Bridge: Res:
3/11/94 (415) 904-8944 661901
4/1/94 (415) 904-8944 661905
All meetings are 8:00 AM to 10:00 AM PST (16:00 to 18:00 UTC). We try to
have agendas out 7 days before each open forum and meeting minutes out
within 7 days after. When you call into the meeting, ask for the IBIS
Open Forum and give the bridge operator the reservation number.
Please note: If you know of someone new who wants to join the e-mail
reflector (ibis@vhdl.org) send e-mail to ibis-request@vhdl.org.
------------------------------------------------------------------------------
2/18/94 Meeting Agenda
----------------------
8:00 Check-in
8:05 Intros of new IBIS participants Hobbs
8:10 Review of 1/28 minutes Hobbs
Miscellany/Announcements Hobbs
BIRDs
Roster posted
Please use CRLFs (Duehren)
Opens for new issues All
Treasurer's Report Hobbs
8:20 Press updates Hobbs/All
Progress toward enlisting new IC vendors All
IBIS 2.0 (ratification at DAC?, process?) Hobbs
IBIS Cookbook Hobbs
Dues (shelved till DAC?) Hobbs
Standard driver? Muranyi, Powell
Quality of support, validation Hobbs
8:40 BIRD 6, Differential Pin Spec. Ross
BIRD 7, Open Specification Completion Ross
BIRD 8, Specification of V/I data monotonicity Crisafulli
Egg 1, mutual pin coupling Bracken
BIRD 9, Other model types Ross
Ramp measurement Reid, Ross, et. al.
Spice to IBIS Converter Lipa (NCSU)
9:25 Canright paper Ward
Formal BNF notation (BIRD?) Reed, Harr
BIRD 2, VIH, VIL Thresholds for Inputs Powell
9:35 High freq. and EMI Goyal, et. al.
Phased turn-on/off of multiple devices Powell
9:55 Wrap-up, Next Meeting Plans Hobbs
Minutes
-------
1. Intros of new IBIS participants
New participant: Racal-Redac: Wants in-house tools support for IBIS (high-
speed and DRC tools)
There were no corrections made to last month's minutes other than the
addition of the following new open forum participants from last month:
Digital Equipment Corp.
IBM-Motorola Alliance
National Semiconductor
2. Miscellany/Announcements
The current BIRDs are posted on vhdl.org. Apparently they were not posted
as individual files.
AR Derrick: to reorganize the BIRD files. He expects to have this done by
3/4/94. Note: Derrick now has sysop rights into vhdl.org (in
addition to Randy Harr of LMC).
The roster of IBIS Open Forum participants has been posted to vhdl.org.
Will Hobbs and Derrick Duehren have new email addresses. The previous
addresses work, but the messages come through cleaner using the following
new addresses:
Will_Hobbs@ccm2.jf.intel.com
Derrick_Duehren@ccm.jf.intel.com
3. Opens for new issues
We need help for new people developing models (see #8, below).
4. Treasurer's Report
We now have a $2,600 balance. Another golden parser was sold (to Anacad).
5. Press updates
EE Times of UK called Will Hobbs. So far, they have only played
telephone tag.
An EDA group (Open Model Forum) being formed to establish a universal
interface for logical models (EDA/Semi vendors getting together) met for
the first time this month and referenced IBIS as a model for how to
establish standards!
6. Progress toward enlisting new IC vendors
Will Hobbs is actively working with a new ASIC vendor (in a proprietary
relationship, so Intel can't say who, yet).
7. IBIS 2.0 (ratification at DAC?, process?)
We are trying to identify a good day at DAC to ratify IBIS 2.0. The
DAC schedule is not out yet. Will suggested that a steering committee
meet face-to-face before the DAC convention for a roll-up of the BIRDs
into 2.0. This roll-up could then be distributed to the IBIS participants
for review before the DAC conference. It was suggested that we hold the
IBIS meetings in the evenings at DAC as "Birds of a feather" sessions.
8. IBIS Cookbook
Lynn Warriner: We need an introductory toolkit (cookbook). Access to
Kellee's package was helpful.
The Intel version is nearly done. Some of the text, such as "how to do
measurements and extract the IBIS info" and "how to correlate against
SPICE", is generic and can be extracted. A sanitized version as a
starting place for an open IBIS cookbook should be ready in about a month.
Kellee volunteered to help newcomers as well as help extract the open
version of the cookbook from Intel's proprietary version.
National, DEC, IBM, and Motorola all asked for the cookbook. IBM needs it
now. They have an internal commitment to have the IBIS models out by
2/28/94.
9. Dues
None for now. We will reevaluate them if the need arises.
Later in the meeting, Kellee proposed limiting "official voting" rights to
those who have paid for the Golden Parser (GP). Those that don't really
need it. Silicon vendors, for example, could consider it a one-time dues
payment. In other words, dues can be the GP fee, and you get the GP free.
Official votes would come into play in case of dissension.
AR Will: post list of current GP license holders. Also post info on the
GP itself. What it is, how to get it.
We will close on this issue in the next open forum meeting.
10. Standard driver, quality of support, validation
Two topics we originally intended to treat separately are so intertwined
that the discussion continually bounced back and forth. The basic
questions are:
1. Is there a standard circuit that all simulators use?
2. If not, how can we trust the results of the simulations after we
release the models?
Related to this, if there is no standard model and no standard
simulator, how do silicon vendors know if the V/I tables they put in
IBIS models are correct? How can the models be verified?
Arpad prefers to not have his driver referred to as the "standard".
Kellee: Arpad's original model is not the standard, but a good starting
point. It needs tweaks, as others have done.
Lynn: If you use VCCS (Volt Control Current Source) instead of resistors,
you end up with exponential response instead of linear. It feels like we
need a mutually agreed upon simulation engine to verify integrity. This
would help validate that the numbers that are extracted are correct.
Maah: I don't think we (the Forum) are ready for selecting one simulator
as a standard, as we are all competitors. Who's tool is chosen as the
standard? Every vendor has responsibility to ensure the accuracy of their
own tool.
Lynn: HyperLynx created a derivative of Arpad's model, Quad tuned theirs
for IBIS, other simulators will probably do it different ways.
Kumar: There are many ways to implement the standard model. We may want
to solve different problems, too, which affects how you implement the
model.
Lynn: "We need a standard way of verifying V/I tables. I probably
surfaced this mess last time. I can generate V/I tables off simulation
and need a way to validate them."
Will: "The topologies shown in the Overview document are what Intel uses: a
couple of simple ones and a complex one to "break the model".
Within Intel, we use several different simulators and cross-check
the results." Will is aware of at least 5 vendors' simulators used at
various Intel sites.
Kellee: We need a suite of simulations and models to validate simulators
and verify IBIS compliance among simulators. We need to publish the test
suite, publish the expected results, and state that companies can self-
certify, such as "Output results correlate closely with the expected data."
Leave it to simulator vendors to determine what "closely" means.
Q: Is there a test suite?
A: Intel published one, although only for one type of model. IBIS model
suppliers can publish the tests and results. The results should "closely
follow," with interpretation left to individual users. Customers can see
for themselves how closely the tool meets the IBIS form.
AR Will: See if Intel/Don Telian can release waveforms for the
simulations in the Overview doc. The data should end up in
Postscript format so the curves can be universally accessed.
John Burnett: We need to specify which level of IBIS each company is
certified to. Can we publish a list of vendors that have self-certified,
passed test suites?
AR Everyone: If, and when you self-certify (run the test suite), send email
to Derrick_Duehren@ccm.jf.intel.com so Derrick can add the
information to the Participants Roster document. Include what
IBIS version level you support.
Lynn: I want to push IBIS back into our entire product line, 100's of
parts. I can feel comfortable in near term using a specific simulator,
but long-term, I need a standard simulator. A prime element in
standardizing IBIS is a method for proving compliance.
11. Other Questions:
Q: Regarding simulation at specific temperatures (0C, 50C, and 100C), are
we obligated to use these temperatures, or can we use whatever we specify
our parts at (-20, 50, 120, or whatever)? Is there a standard?
A: No - use your own min/max temperatures.
Kellee, Stephen: Use whatever temperatures give you the desired min and max
results. We need a BIRD to clear up this set of questions.
AR Lynn: Create a new BIRD. Clarify that temperature used should reflect
the mix/ max of the component.
AR Derrick: Send BIRD.TXT to Lynn (Done).
Q: What about dual voltage parts?
A: Stephen: Intel uses two separate models.
12. BIRD 6, Differential Pin Spec.
Bob Ross summarized the changes from 6.1, as documented in BIRD 6.2.
We may want to expand this BIRD later. Vdiff specifies difference of output
values, pdelay now has polarity associated with it. If positive, the
positive output is delayed with regard to negative output. Pin package
delays can be speced separately from buffer delay differences.
Kellee: Simulators need to know when to launch the ramp to achieve the
correct delay.
Bob: That's why we changed to tdelay instead of tskew; this actually
refers to launch delay rather than output delay.
Vote taken: BIRD 6.2 was unanimously approved.
13. BIRD 7, Open Specification Completion
Bob Ross summarized BIRD 7.2. We discussed the differences in methodology
between BIRDs 7.2 and 2.1. Are they two ways to do the same thing? Worst
case, there will be some overlap. Jon Powell was not present to comment
on BIRD 2.1.
Vote taken: BIRD 7.2 was unanimously approved.
14. BIRD 8, Specification of V/I data monotonicity
Kellee summarized, discussed what we should require to be monotonic in the
I/V tables: BIRD 8 proposes that user's choose voltage or current. Feedback
from the forum leaned in favor of requiring the voltage axis to be
monotonic.
Arpad has recently seen a case where the current was non- monotonic; i.e.,
a single voltage has two different current values.
AR Kellee: Repropose monotonic voltage and reopen discussion via email.
15. Egg 1, mutual pin coupling
No discussion.
16. BIRD 9, Other model types
Bob Ross briefly discussed the intent of Bird 9, not looking for assent
yet. By adding resistors as model types, we can eliminate unnecessary
processing of curves when a resistor would do. As yet, the BIRD does not
address series (two-port) resistors.
AR Bob Ross: Add series resisters to BIRD 9. (Done)
17. Ramp measurement
No discussion.
18. Spice to IBIS Converter
No discussion. Steve Lipa was not present to comment. From Steve's email
messages, good progress has been made. Steve plans to release his
converter to public domain. Ramp is not yet incorporated.
Steve is looking for SPICE models for testing the converter.
19. Canright paper
No discussion.
20. Formal BNF notation (BIRD?)
Bob Ross did some work on the BNF parser. Would like others to pick up on
it.
Update: Steve Lipa is also working on the parser. Bob posted his first
attempt to the reflector.
21. BIRD 2, VIH, VIL Thresholds for Inputs
No discussion.
22. High freq. and EMI
No discussion.
23. Phased turn-on/off of multiple devices
No discussion.
24. Wrap-up, Next Meeting Plans
The next meeting is 3/11/94.
Received on Mon Feb 28 19:08:02 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT