Subject: IBIS Open Forum Minutes of 12/3 Meeting

From: Will Hobbs <[email-masked]>
Date: Thu, 23 Dec 93 16:50:07 PST

Text item: Text_1

Date:     December 23, 1993

From:     Will Hobbs     (503) 696-4369,  fax (503) 696-4210
          Modeling Manager,
          Xcceleration Tools Group
          Intel Corporation
          Hillsboro, Oregon
          
Subject:  Minutes from IBIS Open Forum 12/03/93

To:

Anacad                       Petra Osterman
AnSoft                       Henri Maramis*
Atmel Corporation            Dan Terry
Cadence Design               Sandeep Khanna, Chris Reed,
                             Pawel Chadzynski, Kumar*
Contec                       Maah Sango*, Dermott Lynch, Clark Cochran
High Design Technology       Michael Smith
HyperLynx                    Steve Kaufer, Kellee Crisafulli*
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                Stephen Fenstermaker, Mei Wong*
MicroSim                     Arthur Wong, Meeling Wei, Jerry Brown,
                             Graham Bell
North Carolina State U.      Paul Franzon, Michael Steer
Performance Signal Integrity Vivek Raghawan, Eric Bracken*
Quad Design                  Jon Powell
Quantic Labs                 Mike Ventham, Zhen Mu
Siemens Nixdorf              Werner Rissiek*, 
Texas Instruments            Bob Ward*
Thomson-CSF/SCTF             Jean Lebrun
Zeelan Technology            Hiro Moriyasu, George Opsahl*, Samie Samaan,
                             Tay Wu

Cc:  Intel Corporation  Randy Wilhelm, Jerry Budelman,
                        Intel IBIS team

In the list above, attendees at the 12/3 meeting are indicated by *

Next Meeting:  January 7, 1994, 9:00 AM to 11:00 PST.
               The Phone number and Reservation number will be sent
               out in the week of Jan 2.

Please note:  If you know of someone new who wants to join the e-mail 
reflector ([email-masked]), or have updates to your e-mail address, e-
mail to [email-masked].

12/3 Meeting Agenda:

9:00  Check-in
9:05  Introductions of new IBIS members
9:10  11/12 Summit Minutes Review
      Opens for New Issues
9:15  Enlisting new IC Vendors
9:20  Opens from Summit, BIRDS
          BIRD 5:  Complex Package parameters, Pin Mapping
          New Model types
          BIRD 2.1 (VIH, VIL)
9:55  Other Opens
          How Do various EDA vendors support IBIS?
          Open Side
          IBIS V1.1 Wording error (Ramp rate versus time)
          Non-intrusive package parameter extraction
          Press Coverage
          IBIS Version 2.0 Plans
10:25 Wrap-Up
      Next Meeting Plans

1/7 Agenda

In keeping with the wishes of various participants, I have arranged 
the order to keep technical discussions later so that those who wish 
to leave early may do so.

9:00  Check-in
9:05  Introductions of new IBIS members
9:10  12/3 Summit Minutes Review
      Opens for New Issues
9:15  Another IBIS Press Release              Hobbs
      Enlisting new IC Vendors
      Forms of EDA support of IBIS            Hobbs
9:30  BIRD 5, Pin Mapping                     Bracken
      EGG 1, mutual pin coupling              Bracken
10:00 80 Column restriction?                  
      Non-intrusive pkg param extraction      Ward
      Formal BNF notation                     Reed, Harr
      VIH, VIL Thresholds for Inputs, BIRD 2  Powell
      Spice to IBIS Converter                 
10:30 IBIS 2.0 Goals                          Hobbs
      3D Modeling                             Muranyi
      New model_types (r-packs, etc.)         
      Modeling Feedback                       Hobbs, Peters
10:45 Phased turn-on/off of multiple devices  Powell
      Open Side Devices                       Crisafulli
      Other Updates (U of NC, DIE, etc.)      All
10:55 Wrap-up, Next Meeting Plans

Minutes:

I.  11/12 Minutes review, Open time for new issues:

There was one minor correction to the 11/12 IBIS minutes and a 
clarification.  Mentor was present at the summit (though only briefly 
during the lunch hour) and RLGC stands for resistance, inductance, 
conductance and capacitance.

II.  Enlisting new IC Vendors

Generally, everyone would like to have more IC vendors on board, but 
progress remains slow.  We need to keep informing customers and IC 
vendors of IBIS and be patient.

Kellee has been pushing IBIS during visits with customers.  As a 
result of this, Cypress Semiconductor has received inquiries from 
their customers and is now very interested in IBIS.

Bob Ward called from another site in TI, where a TI modeling council 
is held.  He discussed IBIS with the council.  In addition, one of 
TI's key customers has expressed interested.  Together, these should 
help increase IBIS interest at TI.

I (Will) have now received inquiries from, and sent information to, 
Cypress, Motorola, IBM, Toshiba, Signetics, Atmel, National 
Semiconductor, NEC, AT&T, Phillips, IDT and Micron, in addition to 
Texas Instruments and Intel, of course.  Derrick Duehren, who works 
with me, will be contacting individuals at these companies to gauge 
their interest.

III.  BIRD 5.  Pin Mapping

Between the summit and the December meeting, several messages went out 
on the reflector about pin mapping in the package, with the hope of 
being able to better model ground bounce and problems resulting from 
simultaneous switching of outputs.  One of the messages was a 
preliminary proposal from Eric Bracken.  We discussed this.

Eric stated that RLGC, which most people in the discussion and at the 
summit appeared to like, "works pretty well when there is only a 
single path from the pad to the pin, but it gets more complicated when 
you have branching, or several segments such as bonding wire, lead 
frame, etc."  The question is how do you handle the more complex 
cases?

Kumar suggested we keep IBIS simple, handling the simplest cases now 
with an RLGC matrix, then tackle the more difficult cases later, or 
provide a way of breaking out into a sub-circuit.  E.g., if you have 
14 pins, you could have a 14X14 matrix.  We could use a keyword that 
says that there is an RLGC matrix present.

If the vendor is supplying the model, the vendor could put out the pin 
mapping information, but determining that from outside measurements 
would be very difficult.  In the DIE work, according to Randy, most of 
the tools can't handle the complexity we're describing now anyway, so 
do we want to deal with this yet?  Kellee feels that ground bounce is 
the biggest missing piece right now.  He likes what Eric described 
regarding a bus structure.

Bob Ward raised the issue of mutual coupling through the lead frames, 
which is probably less than the coupling through the chip 
metallization.  This complexity is not addressed by BIRD 5 yet, but we 
should probably go with the proposal as a start.  Power buses are 
inside the chip which don't correspond cleanly with the pins that 
connect to the power and ground pins.  Kellee wondered if we have to 
have that level of complexity represented in BIRD 5 needed to be 
successful to at least 70% as opposed to 0 that we have now.

The discussion then turned to more complex pin mappings, such as a 
power bus tied to several pins on one side and supplying current to 
several buffers on the other end.  Arpad suggested the possibility of 
a power tree structure?  The discussion touched on various 
complications, such as rings, or parallel interconnected power 
structures.  Bob Ward suggested the concept of a "threaded tree"  that 
could be interconnected by naming certain levels with the same name (a 
trunk!).

Kellee and Bob suggested that BIRD 5 be cleaned up and a separate BIRD 
6 be issued that covers trees.  We should then continue the discussion 
on e-mail.

A/R Kumar, Eric Bracken:  Re-write BIRD 5 in standard format by next 
week.  Update:  Done, with two revisions prompted by e-mail 
discussions, giving us BIRD 5.2.

A/R Bob Ward:  Generate initial crack (quack) at another BIRD to 
address power trees, with understanding that further discussion will 
occur.  This new BIRD may be, but is not required to be, a superset of 
BIRD 5.

IV.  New Model types

Several discussions in the past have alluded to a desire to represent 
other types of components in an IBIS-compatible format, such as pull-
up resistors, etc.  We did not spend much time discussing this topic, 
but would urge anyone with a string desire for that capability in IBIS 
to generate a BIRD, or an EGG.  (OK, for those that haven't been 
following the e-mail discussion, Eric Bracken kicked off a discussion 
on mutual coupling between pins, and because it was preliminary and 
thus preceded a BIRD, he termed the suggestion an EGG.)

V.  BIRD 2.1 (VIH, VIL)

This discussion was tabled until next meeting.  Jon Powell not 
present.

VI.  How Do various EDA vendors support IBIS?

Although we have active participation by quite a few simulator 
vendors, nowhere have we gathered together data that describes how 
each vendor supports IBIS.  Some vendors have created a product-
specific IBIS-to-their model converter, others accept native IBIS 
models, still others may have written application notes describing how 
to use IBIS data in their simulators.  I (Will) asked for descriptions 
from everyone on how their company supports IBIS.  This information 
will be given to our field sales and applications engineers and 
marketing folks so we can answer customer questions.  I stated that if 
someone did not want to make their information publicly available, I 
would still like the information and would protect the information.

A/R All EDA vendors:  Please describe how you support IBIS (converter, 
application note, native IBIS models, etc.).  Send this information to 
Will Hobbs, [email-masked]

A/R Will:  compile the information, and make it available to the IBIS 
Open Forum, excluding that information which the vendors do not wish 
to share publicly.

Update,  after the meeting I received the following information from 
Kellee at HyperLynx.  This is exactly the type of information I am 
seeking:

     IBIS support by Linesim Pro from HyperLynx

1) Any IBIS file can be used directly as a 'NATIVE' file by Linesim 
Pro Version 3.0 or newer.
2) A single model in an IBIS file can selected, loaded and viewed 
directly by LineSim Pro.
3) Several IBIS models can be included in a single file and used as a 
library.  Note: this library file still complies completely with the 
IBIS specification and can be checked with the IBIS check program.

VII.  Open Side

Kellee suggested he generate a BIRD and that we keep this topic as an 
open.

A/R Kellee:  Generate a BIRD describing the Open Side issues and 
proposing how to handle them.

VIII.  IBIS V1.1 Wording error (Ramp rate versus time)

Stephen Peters and I noticed a wording problem in IBIS V1.1 with 
respect to the description of ramp rates.  The particular offending 
section describes ramp rates as ramp times, which is confusing, since 
the min ramp data is the slow corner and thus relates to ramp rate, 
not time:

| Ramp times for CMOS devices:                                         |
|   typ = nominal voltage,  50 degrees C, typical process              |
|   min = low voltage tol, 100 degrees C, typical process, minus "Y%"  |
|   max = hi voltage tol,    0 degrees C, typical process, plus  "Y%"  |
|                                                                      |
| Ramp times for bipolar devices:                                      |
|   To be determined by manufacturer.                                  |

A/R Will Hobbs or Stephen Peters:  Generate a BIRD to have the above 
wording refer to ramp rate rather than ramp time.

IX.  Non-intrusive package parameter extraction

At the summit, Bob Ward alluded to work being done at Texas 
Instruments to dynamically and non-invasively extract package 
parameter information by measurement.  Because he was unsure if this 
was proprietary, he said he would look into it and describe the work 
if he could.  Since then, he has learned that TI has published some 
papers on this work and that it is not classified.  Bob also mentioned 
that Bob Canwright of Convex has done some good work on this subject, 
too.  At the time of the December meeting, however, Bob Ward had not 
yet received the material, and was therefore unable to comment.  This 
will be a future topic.

A/R Bob Ward:  When you receive the papers, summarize via e-mail and 
we will put the topic on the agenda for future discussions.

X.  Press Coverage

The press response to our October press release was underwhelming.  
This is somewhat surprising, given the nearly unprecedented level of 
cooperation happening between the large number of companies 
participating in the IBIS consortium.  Kellee felt the magnitude of 
this effort is significant enough for front page coverage, not obscure 
footnote coverage.  I brought up the summit as having been a good 
opportunity to use as a press generator, but felt that too much time 
has now elapsed.  Kellee disagreed, feeling that it wasn't too late.  
Mei Wong of Meta-Software would like Intel Marcom to drive this.

A/R Will:  Fire up Intel Marcom to generate press.  Update:  In 
process.

XI.  2.0 Goals

Kellee asked what the goals for IBIS V2.0 were, indicating that hot 
needs must be the driving force behind the next revision.  I stated 
that I felt February was a good target date, though not cast in 
concrete, but that we still needed to define everything we need to put 
into 2.0.  My primary goal is to make sure the devices I need to model 
can be handled by IBIS and that key customer requests are addressed.  
The key items I was hoping for in 2.0 are controlled slew rate support 
and feedback.  Customers are clearly interested in support for ground 
bounce studies.

There was some fear expressed that if we introduce new IBIS revisions 
too quickly that may scare off newcomers.  Kellee indicated we must 
communicate clearly with IC Vendors that they can produced 1.1 models, 
even though there may be a 2.0.

We discussed how to handle allowing both very complex models and 
simple models, and that perhaps we should define IBIS model levels;  
The simplest acceptable IBIS model would be a level 1 model, ones that 
added some advanced IBIS features such as power and ground structure, 
would be higher level models, level 2, 3, ....  Perhaps we should 
identify each parameter as participating in a particular level.  We 
agreed to address these levels as we put together IBIS Version 2.0.

Regarding controlled slew rate modeling, Arpad feels it can be 
addressed through his 3-D modeling work.  3-D descriptions can 
probably be handled with two to four more tables with % scaling 
factors to interpolate.

A/R Arpad:  Generate a BIRD describing the 3-D proposal.

Feedback is probably a superset of surface curves.  Will wondered if 
there could be a feedback transfer function approach that would allow 
the V/I curves to be scaled appropriately based on the feedback.  We 
weren't sure if or how such transfer functions can be measured.

XII.  IBIS Overview Document:

Will mentioned that he and Robin Rosenbaum had finished making all the 
changes to the introduction to IBIS document and was now distributing 
it to people inquiring about IBIS.

A/R Will:  Make the overview document available to the Forum.  Update:  
I sent the Word For Windows file to Randy Harr who will put it onto 
vhdl.org.

XIII.  Next Meeting Plans

Due to the impending holidays, the next meeting was set for January 7, 
1994.  See the first page of these minutes for details.

A closing quote from Eric Bracken's mail:  "On the first day of 
Christmas, my true love gave to me, an IBIS with a parse tree..."

Happy Holidays, IBIS team!  This has been a great year.  See you next 
year!