From speters@ichips.intel.com Thu Nov 4 16:41:35 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06336; Thu, 4 Nov 93 16:41:35 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Thu, 4 Nov 93 16:40:38 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Thu, 4 Nov 93 16:40:29 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Thu, 4 Nov 93 16:40:32 PST Message-Id: <9311050040.AA01007@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD #3 Date: Thu, 04 Nov 1993 16:40:31 -0800 From: Stephen Peters Hello fellow IBISains -- As promised during the last open forum meeting I started to write a revised BIRD for ECL. However....as I tried to address the issues concerning clamp-diodes references, specifing voltage rails, etc. it became apparent that I was trying to kill two stones with one BIRD. Therefore, BIRD #3 has become a proposal that deals with the whole issue of handling multi- supply devices and specifing devices that don't follow the standard pullup/pulldown reference paradigm. BIRD #4 will follow shortly, and it deals stricly with the issue of reducing the required voltage range when specifing ECL outputs. I look forward to your comments. Best Regards, Stephen Peters Intel Corp. ---------------------------------------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: 0003 ISSUE TITLE: Multiple power supplies and references REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: Nov 4, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The IBIS specification currently does not address devices that use more than one supply, or devices in which the pullups, pulldowns, power_clamp or gnd_clamp diodes are referenced to voltages other than that specified by the [Voltage range] keyword. This BIRD proposes a general way in which both multiple power supplies can be defined and V/I curve can be referenced to specific supplies. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The specific change involves adding four new keywords: [Pullup reference], [Pulldown reference], [POWER_clamp reference] and [GND_clamp reference]. These keywords are defined as shown below. The following text replaces the current text for the [Voltage range] keyword. |========================================================================== | Keyword: [Voltage range] | Required: Yes |Description: Used to define the power supply voltage tolerance over which | the the model is intended to operate. It also specifies the | default voltage rail the pullup and POWER_clamp V/I data is | referenced to. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |--------------------------------------------------------------------------- | variable typ min max [Voltage range] 5.0v 4.5v 5.5v |=========================================================================== | Keyword: [Pullup reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a voltage rail other than that defined by | the [Voltage range] keyword as the reference voltage | for the pullup V/I data. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_r values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pullup reference] 5.0V 4.5V 5.5V |=========================================================================== | Keyword: [Pulldown reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a power supply rail other than 0v as the | reference voltage for the pulldown V/I data. If this keyword | is not present the voltage data points in the pullup V/I table | are referenced to 0v. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: This keyword, if present, also defines the voltage range over | which the min and max dV/dt_f values are derived. |--------------------------------------------------------------------------- | variable typ min max [Pulldown reference] 0V 0V 0V |=========================================================================== | Keyword: [POWER_clamp reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a voltage rail other than that defined by | the [Voltage range] keyword as the reference voltage | for the POWER_clamp V/I data. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |--------------------------------------------------------------------------- | variable typ min max [POWER_clamp reference] 5.0V 4.5V 5.5V |=========================================================================== | Keyword: [GND_clamp reference] | Required: Yes, if the [Voltage range] keyword is not present. |Description: Used to define a power supply rail other than 0v as the | reference voltage for the GND_clamp V/I data. If this keyword | is not present the voltage data points in the pullup V/I table | are referenced to 0v. |Usage Rules: Actual voltages (not percentages) are to be presented in the | usual typ, min, max format. "NA" is allowed for the min and | max values only. |Other Notes: Refer to the "NOTES ON SPECIFYING POWER SUPPLIES" section below. |--------------------------------------------------------------------------- | variable typ min max [GND_clamp reference] 0V 0V 0V |============================================================================ | NOTES ON SPECIFYING POWER SUPPLIES | It is the intention that standard TTL and CMOS devices be specified | using only the [Voltage range] keyword. However, in cases where | the output characteristics of a device depend on more than a single | supply and ground, or a pullup, pulldown or clamp structure is referenced | to something other than the default supplys, the additional 'reference' | keywords are to be used. | If the [Voltage range] keyword is not present then all four of the | other keywords must be present. If the [Voltage range] keyword is | present the other keywords are optional and may or may not be used as | required. It is legal (although redundant) for an optional keyword to | specify the same voltage as specified by the [Voltage range] keyword. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Most of the above is fairly self-explanatory. The key here is to realize that the four 'reference' keywords, in effect, create separate power supply rails that override the default [Voltage range] supply. The intention was to create a very general and flexible way to handle multiple supply devices and ECL. To illustrate with some examples: 1. An RS23 line driver has a +/- 12V output swing. One way to specify this device is shown below typ min max [Voltage range] 12.0V 11.5V 12.5V | fixes pullup and | POWER_clamp ref [Pulldown reference] -12.0V -12.5V -11.5V | fixes pulldown ref [GND_clamp reference] -12.0V -12.5v -11.5V | fixes GND_clamp ref Optionally, the [Voltage range] keyword could be replaced with the [Pullup reference] and [POWER_clamp] reference. 2. A device uses two supplies, a 3V supply for its I/O and a 5V supply for it's internal logic. The power clamp diodes are referenced to the 5V supply. Their are two equally valid ways this device can be specified. typ min max [Voltage range] 3.3V 3.0V 3.6V | fixes pullup reference [POWER_clamp reference 5.0V 4.5V 5.5V | fixes POWER_clamp | reference typ min max [Voltage range] 5.0V 4.5V 5.5V | fixes both pullup and | POWER_clamp reference [Pullup reference] 3.3V 3.0V 3.6V | overrides [Voltage | range] specification | on the pullup 3. When specifying a device with an ECL type output structure, the pulldown curves must be referenced to the most positive supply (the same one that the pullup curves are referenced to). The easiest way to do this is define the value of the [Voltage range] as 0v. Both the pullup AND pulldown V/I curves will be referenced to 0v (remember, the pulldown defaults to 0v). typ min max [Voltage range] 0V 0V 0V | VCC supply [Pulldown reference] 0V 0V 0V | not really | required, its | specified for | completeness [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Alternately, one could specify the VEE supply and then override the default values of the pullup and pulldown references typ min max [Voltage range] -4.5V -4.0V -5.5v | VEE supply [Pullup reference] 0v 0v 0V [Pulldown reference] 0v 0v 0v [GND_clamp reference] -4.5V -3.5V -5.5V | ESD diode Finally, to specify ECL logic that is used with a +5V supply (positive ECL) one can do the following: typ min max [Voltage range] 5.0V 4.5V 5.5V | VCC supply [Pulldown reference] 5.0V 4.5V 5.5V | override default The default references are used for the pullup and GND_clamp V/I curves. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From speters@ichips.intel.com Fri Nov 5 13:39:16 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15590; Fri, 5 Nov 93 13:39:16 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 5 Nov 93 13:38:26 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 5 Nov 93 13:38:09 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 5 Nov 93 13:38:12 PST Message-Id: <9311052138.AA03889@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD #4, ECL bird Date: Fri, 05 Nov 1993 13:38:12 -0800 From: Stephen Peters Greetings again -- As promised, here is the BIRD that deals with specifing ECL type outputs. Because the issue of pulldown V/I curve reference has been addressed in the previous BIRD (BIRD #3), this bird deals strictly with the reduced output voltage swing issue. Best Regards, Stephen Peters P.S. -- In my haste to get BIRD #3 finished I inadvertently forgot to include the following: ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: The author wishs to acknowledge Kelly Crisafulli of Hyperlynx and Kumar of Cadence Design Systems for planting the ideas that became this BIRD. ****************************************************************************** ------------------------ cut here -------------------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: 0004 ISSUE TITLE: ECL Extensions REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: November 5, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: This proposal addresses the need to extend the IBIS specification to include devices with Emitter Coupled Logic (ECL) type output structures. The proposed changes are two in number: (1) Lessening the required voltage range over which an ECL output is characterized. (2) Explicitly specifying under what output conditions data is gathered for inclusion in the pullup and pulldown tables. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) The first change is to relax (decrease) the range of voltage values required when tabulating the V-I characteristics of an ECL output. For an ECL device it is proposed the range be decreased to VCC (the most positive power supply) to VCC - 2.2 volts (currently the range is from GND - POWER to 2*POWER). Specifically, add the following to Item 2 in the "NOTES ON DATA DERIVATION METHOD" section of the specification: When tabulating output data for ECL type devices, the voltage points must span the range of VCC to VCC - 2.2V. This range applies to both the pullup and pulldown tables. Note that this range applies ONLY when characterizing an ECL output. (3) Secondly, it is proposed to explicitly state in the specification under what output conditions data is gathered for the pullup and pulldown tables and that, in both cases, the voltage data is referenced to VCC. The proposed explanation should be placed in the 'Other Notes' section of the text describing the [Pulldown] and [Pullup] keywords and is as follows: When tabulating data for ECL devices, the data in the pulldown table is measured with the output in the 'logic low' state. In other words, the data in the table represents the V-I characteristics of the output when the output is at the most negative of its two logic levels. Likewise, the data in the pullup table is measured with the output in the 'logic one' state and represents the V-I characteristics when the output is at the most positive logic level. Note that in BOTH these cases the data is referenced to the VCC supply voltage, using the equation Vtable = Vcc - Voutput. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: (1) The reason the voltage range over which an ECL output is specified should be relaxed is that, with ECL, one is dealing with much smaller signal swings and terminated transmission lines. The rational for specifying such a large voltage range was to allow for the case of a CMOS output driving an unterminated transmission line. When an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, a CMOS output that swings rail-to-rail could see a reflection of up to 2*VCC (or -VCC in the negative direction). However, with an ECL output, the output swing is only ~800mv (typically -.9v to -1.7v) and furthermore, because of the vary nature of ECL, any transmission lines will be terminated with an Rt close to the lines Zo. Even in the case where the mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv, and the voltage range at the source due to reflections is -.6 to -2.0v. Therefore, a range of VCC to VCC -2.2v is adequate to specify the output under any reasonable conditions, and should be enough to allow simulators to extrapolate the curves. (3) The second proposal is an effort to make perfectly clear to both the user and the person creating an IBIS specification for a particular part how ECL device are to be handled. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From ccm!Cathy_Lundberg@intelhf.intel.com Mon Nov 8 16:48:51 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13296; Mon, 8 Nov 93 16:48:51 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0owhFW-000MPSC; Mon, 8 Nov 93 16:47 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0owiGb-00004PC; Mon, 8 Nov 93 17:53 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 8 Nov 93 17:53:09 PST Date: Mon, 8 Nov 93 17:53:09 PST From: Cathy Lundberg Message-Id: <931108175309_19@ccm.hf.intel.com> To: Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org Cc: Cathy_Lundberg@ccm.hf.intel.com Subject: November 5, 1993 November 5, 1993 From: Cathy Lundberg (503) 696-4620, fax (503) 696-4904 Will Hobbs (503) 696-4369, fax (503) 696-4210 Subject: Minutes from IBIS Open Forum 10/29/93 To: Anacad Petra Osterman AnSoft Henri Maramis Cadence Design Sandeep Khanna, Chris Reed, Pawel Chadzynski, Kumar* Contec Maah Sango*, Clark Cochran High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Gary Saunders, Jim Alexander, Don Telian, Arpad Muranyi*, Donna Rendon, Will Hobbs*, Cathy Lundberg* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd IntuSoft Charles Hymowitz Logic Modeling Corp. Randy Harr* Mentor Graphics Greg Seltzer, Ravender Goyal Meta-Software Stephen Fenstermaker MicroSim Arthur Wong*, Meeling Wei, Jerry Brown, Graham Bell North Carolina State University Paul Franzon PC Ware Paul Munsey 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 10/29 meeting are indicated by * Future meetings: Face to face IBIS Summit, Santa Clara, CA: Nov. 12, 1993, 8:00-5:00 PST Phone number: (916)356-9999. Reservation Number: 130639 Please note: If you know of someone new who wants to join the email reflector (ibis@lmc.com), or have updates to your email address, email to ibis-request@vhdl.org. 10/29 Meeting Agenda: 9:00 Check-in 9:05 Introductions of new IBIS members 9:10 10/1 Minutes Review, Opens for New Issues Will Hobbs 9:15 Press Release, Trademark issue Randy Harr, Will Hobbs 9:25 Summit Planning Attendees Presenters Discussion Chairs, Topics 9:40 SCVs Will Hobbs, All 9:45 BBS Updates Siuki Chan, Randy Harr 9:50 BIRDS ECL, BIRD #1 Stephen Peters VIH, VIL Input Threshold, Bird #2 Jon Powell 10:20 10/1 Opens #6 Open Side (shelved) Kellee Crisafulli #7 .pkg Eric Bracken #8 Thresholds for Timing Jon Powell #9 Monotonicity Kellee Crisafulli, Arpad Muranyi 10:50 Wrap-Up Action Items Next Meeting Plans Minutes I. Open Issues: Atmel called, they will be doing IBIS models. Motorola will do IBIS models of the PowerPC. They may attend the summit. No corrections to minutes. Paul Munsey has not been paid by one company. The group agreed that a check should be issued to Paul by Will from the IBIS account. AR: Will - issue check to Paul Munsey from the IBIS account. Update: waiting on final confirmation of facts. Changes to coding style would make 2.0 easier to use, and easier to write translators. Jon would like people to talk to Paul about it. We'll send out directions to get to the summit to reflector by next Monday. A map will also be sent with the faxed minutes. AR: Cathy - send directions to get to the summit to the reflector. DONE AR: Cathy - fax map to Bob Ward. DONE II. Press Release: Texas Instruments didn't get deleted from the copy and TI did appear in a couple of places as supporting the IBIS standard. The final release went out without Randy's review. Key editors were called about the mistake and corrected copies were faxed to several places. No backlash is expected at TI. We have a letter on letterhead from every company but Intel authorizing the press release. The IBIS Overview document that will be sent out on request by Karen Kirkpatrick at Cadence has not been sent to her yet; It has been reviewed by various Intel people and Jon Powell and still needs some revision. It is a nice overview, but gets too specific in some areas. For example, some simulator vendors have varying support for the ability to accurately model traces, so the document should give transmission line values instead of trace lengths, etc. Subsequent to the meeting, we learned that Cadence has received a few requests yet as far as we know. Robin (Intel's tech writer working on the document) is making final revisions. She will finish shortly and we will submit it to vhdl.org and fax it to our standard fax list. The press release got low coverage because of the HyperLynx press release that went out earlier. Also, the press release was just on white paper, not on slick letterhead with a packet. The next time we issue a press release we should have each company generate their own press release which we can then assemble together to send out. We need to make sure we time it right and release the information at the same time. We have some potential logos to use for IBIS. The results of the trademark search are in a 50 page document that Logic Modeling has - any paying IBIS member can get it from them. III. Summit planning: A session led by Kumar of Cadence and Eric Bracken (now Vivek Reghawan) of Performance Signal Integrity will discuss modeling simultaneous switching / ground bounce, which drivers talk to which pins, different supplies powering different pins, representing Vcc pins shared by buffers, timing and noise implications and dual supply components. AR: Kumar - let Will or Cathy know your topic of discussion by 11/5. Other potential sessions: Data measurement and derivation methods - how semiconductor vendors derive data. Other semiconductor vendors have rise times characterized differently than Intel does. It would be nice to have Intel, Motorola and Texas Instruments talk about this. In order for IBIS to be useful, semiconductor vendors need to get involved. Will is inviting some companies to the summit. Others should do the same. We would like to see foils ahead of time so we can have copies prepared. We will also send out copies afterward as necessary. November 12 IBIS conference agenda 8:00 - 5:00 SC4-150 Note: Intel will provide coffee and lunch. 8:00 All Assemble, get aquainted, have coffee 8:20 Will Hobbs Intel IC vendor view of IBIS 8:45 Randy Harr LMC Die 0.9 bare die spec work with National 9:15 Bob Ross Interconnectix Measurement and Extraction of buffer data 9:45 Break 10:05 Jon Powell Quad-Design Slew Controlled Devices 10:25 Arpad Muranyi Intel V/I/T 10:40 Panel Handling Dynamic Characterization of Buffers 12:00 Lunch 1:00 Kumar Cadence Implementation of IBIS models using current controlled voltage sources 1:20 Vivek Raghawan Performance Package Parameters Signal Integrity 1:40 Panel Package Parameters 2:10 Panel SSO: Sharing of Vcc and Ground 2:45 Break 3:05 BIRD discussion, voting 4:00 Open issues, action item review, summary BIRDs BIRD #1 We discussed ICs in which diodes and buffer transistors are referenced to different voltage rails. Stephen Peters proposed that he add support for multiple voltage rails to BIRD#1. Because of the other issues that came up with diodes on ECL parts and requirements for mixed supply parts, he decided to rewrite the BIRD#1 to include voltage rail statements, put it out as BIRD#3, to substitute for BIRD#1, and close BIRD#1. Since the meeting, Stephen concluded that it was easier to revise and close BIRD#1, replaced by BIRD#3, dealing with ECL alone. He has also created BIRD#4 to address multiple rails. On the subject that Bob Ross brought up during the previous meeting regarding diodes on ECL parts, the clamp diodes on ECL parts are strictly for ESD protection and don't affect the signals in normal operating conditions. The signal swings in ECL are so small that the ESD diode should never be forward biased. If the diodes are turned on, the part is far beyond operating ranges. With the new voltage rail support in BIRD#4, the user would be able to specify the ESD diodes. Kumar discussed Cadence's approach to multiple rails. In their table called VI, they use a keyword, "vreference" that specifies the Vcc used for that curve. Kumar says that this approach is very simple and works. AR: Kumar write up example and send to reflector. - Done. BIRD#2 Bird 2 - there are many unresolved issues regarding input thresholds. There was a discussion on what the real trip point should be for logic devices and how we might handle non-logic devices such as resistor packs. AR- Jon Powell post BIRD#2 to reflector Friday afternoon. DONE We engaged in a discussion on monotonic behavior. There are two aspects to be dealt with. 1) How should we deal with output buffers that exhibit non-monotonic behavior (and in what situations does this occur), and 2) Must data be entered in the IBIS file monotonically? 1) Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior in curves?" If this is a requirement, the parser must check for monotonicity. Jon Powell said that customers want to model non-monotonic parts. Non-monotonic behavior can result from slow feedback designed to prevent parts from melting; thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a convergence problem for some simulators? Is a DC representation of the curve acceptable for some devices? Due to DC current limiting, DC measurements may imply non-monotonic behavior that would never actually occur under real switching conditions. How do we measure in an AC manner instead of DC manner? Behavior that is nonmonotonic due to feedback goes into the controlled slew rate discussion, modeling the dynamic characteristics of device. For IBIS to be useful, it must deal with negative resistance regions. 2) Monotonic data entry: We felt that in IBIS tables, voltage values should be monotonically rising or falling, but that current values may change. The parser should check whether the data is good, but it shouldn't restrict the type of data. A BIRD against the parser should be written at some point to add checks for this in rev 2.0. No specific AR owner was identified. From contec!contec.COM!maah@netcom.com Tue Nov 9 16:48:54 1993 Return-Path: Received: from netcomsv.netcom.com (uucp4.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24072; Tue, 9 Nov 93 16:48:54 PST Received: from contec.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA08950; Tue, 9 Nov 93 16:47:33 PST Received: from contec4.contec.COM ([192.9.200.168]) by contec.COM (4.1/SMI-4.1) id AA25561; Tue, 9 Nov 93 16:42:43 PST Date: Tue, 9 Nov 93 16:42:43 PST From: maah@contec.COM Message-Id: <9311100042.AA25561@contec.COM> To: ibis@vhdl.org Subject: BIRD 2 Gentle IBIS folk! I have a few comments to make about BIRD 2 at this time. I believe we are also planning to discuss BIRD 2 at the upcoming IBIS summit on November 12, 1993. 1. Some clarifications are needed as to why we need VINL and VINH, from the technical point of view. It would appear that I-V data along with some ac parameters (capacitances, etc.) should be sufficient for inputs/receivers. 2. Requiring specicifications of VINL and VINH increases the amount of data that the vendors must supply, and this could prevent widespread acceptance of the IBIS specs. 3. IBIS should be useful for both digital as well as analog designs, since we are only looking at the inputs and outputs. Requiring VINL and VINH as BIRD 2 proposes would restrict the applicability and usefulness of IBIS to digital devices only, since analog devices don't have VINL nor VINH. 4. Anybody who was certified as IBIS-capable/IBIS-ready can already handle inputs/receivers without the requirement of VINL and VINH. Maah Sango Contec Microelectronics USA Inc. From bward@dadhb1.ti.com Wed Nov 17 09:32:18 1993 Received: from ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21470; Wed, 17 Nov 93 09:32:18 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.65c/LAI-3.2) id AA04663; Wed, 17 Nov 1993 11:32:35 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA25823; Wed, 17 Nov 1993 11:27:26 -0600 Received: from emu.dadhb1.ti.com by node_4c136 with SMTP (5.65c/IDA1.4.4.1-Domain/OS) id AA18045; Wed, 17 Nov 1993 11:24:34 -0600 From: Bob Ward Received: by emu.dadhb1.ti.com id ; Wed, 17 Nov 93 11:24:36 -0600 Return-Path: Message-Id: <9311171724.AA10668@emu.dadhb1.ti.com> Subject: Package parameter measurements To: ibis@vhdl.org Date: Wed, 17 Nov 93 11:24:35 CST Mailer: Elm [revision: 70.85] Hello fellow "bird" watchers - ( Actually I couldn't resist the urge, you're right the pun is bad. ) First let me congratulate everyone for a most enjoyable and productive summit! I thought there was some truly excellent discussion there, and hope for more in the future. Thanks to Intel for hosting it! While in the course of some of the discussion, the subject came up about whether or not package parameters are indeed measurable or not. We in TI have had a method for doing so for some time, and I have known of it but not much about it. At the time of the meeting I said nothing about it since I wasn't sure of the proprietary or non-proprietary nature of it. I have asked around and found that it is not proprietary and has been presented at some conference or another. I have requested a paper on it and am told it is being sent to me. When I receive it I will either summarize it, or send out a reference to it depending on what it is exactly. -- ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= ___ (o o) -------------------------------ooO-(_)-Ooo----------------------------------- Here I sit in endless joy, 'cause I was here before Kilroy!!! From speters@ichips.intel.com Wed Nov 24 16:45:17 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23529; Wed, 24 Nov 93 16:45:17 PST Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 24 Nov 93 16:44:18 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 24 Nov 93 16:44:11 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 24 Nov 93 16:44:14 PST Message-Id: <9311250044.AA08078@xtg801.intel.com> To: ibis@vhdl.org Subject: Ramp "time" vs. Ramp "rate" Date: Wed, 24 Nov 1993 16:44:13 -0800 From: Stephen Peters Hello fellow IBISans -- There is a inconsistancy in the wording of the specification regarding the dV/dt_f and dV/dv_r parameters. In section of 3 of the "NOTES ON DATA DERIVATION METHOD" the first section that specifies the output loading refers to ramp "rate". The second section that outlines the minimum and maximum conditions refers to ramp "time". It may look like a small point but it was causing a bit of confusion among several modlers here as they tried to figure out what really was ment. I don't know if this is worth a bird on it own, but I wanted to bring it to peoples attention. Best Regards, Stephen Peters Intel Corp. From ccm!Will_Hobbs@intelhf.intel.com Mon Nov 29 11:49:20 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12287; Mon, 29 Nov 93 11:49:20 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p4EZu-000MNdC; Mon, 29 Nov 93 11:48 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p4Edm-0000Q7C; Mon, 29 Nov 93 11:52 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 29 Nov 93 11:52:10 PST Date: Mon, 29 Nov 93 11:52:10 PST From: Will Hobbs Message-Id: <931129115210_5@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Summit Minutes, Part Deux Minutes Fall '93 IBIS Open Forum Summit Santa Clara, CA, 11/12/93 Will Hobbs Part 2, Afternoon Session Afternoon Session Kumar of Cadence: Simultaneous Switching Noise, A Package Library Based System Key to modeling packaging noise is in the library: Cadence defines three levels in its hierarchical packaging model: I/O Cell Level (the circuit), Pin Level (bonding pad placement), Package Level. Cadence has added a mapping file that relates an I/O model to a particular Vcc and ground pin. This had been a part of the IBIS specification originally, but there was doubt that vendors would give out the mapping data, so it was dropped. To model Vcc, ground and signal coupling effects, the models need to supply Vcc information, mutual inductance and skew between switching times of outputs that share Vccs and grounds. Signal and ground mutual inductance can actually improve the ground bounce characteristics. In any case, if mutual inductance has an effect, it is worth modeling. The data needs to be used in the correct way. If mutual inductance is included, you need to keep signals in the right order and make sure all are modeled; otherwise, some effects will not be correctly modeled. Cadence would like to solicit our feedback on how packaging should be handled; is Cadence's hierarchical approach the way we want to do it? Vivek Raghawan of Performance Signal Integrity: Packaging. Vivek's presentation was a good follow-on to Kumar's discussion. IBIS as it currently exists, assumes there is no coupling between pins, that power and ground are at fixed potentials, and it ignores the fact that on-die Vdd is not equal to board Vdd, etc. Vivek discussed the complexity of the mutual coupling, approaching a complex matrix of n**2 couplings (n-= number of pins). The size of this matrix can be reduced by arbitrarily limiting scope of interest to 2 neighbor pins on a DIP, or on a PGA to 8 neighbors (but which 8? -- depends on routing). Simultaneous switching of outputs (SSO) induces ground bounce that can result in false triggering of receiving devices, or shift the inputs of the IC that is switching so the inputs falsely trigger. They also create timing delays at the receiving end. Adding in ground planes seriously complicates modeling the ground potential at different points on the plane (and chip) Likewise, adding multiple power and ground pins (as exist on most packages) is complicated-- you can't blindly assume they are in parallel. Another complication is that package wires go through discontinuities. Vivek proposes an addition to IBIS with an optional [Package] keyword. If present, specifies .pkg file to use. If absent, the package models (Rpin, etc.) in the .ibs file is used. A .pkg file would include a linear sub-circuit, with valid elements of R, L, C, K. We need a port naming convention. There was a discussion between Cadence, Performance, Quad, Contec and TI of the use of K (applicable to Spice) and RLGC(?) nXn matrix representation. Bob Ward of TI expressed the fear that if we use the SPICE syntax, it will send the wrong message to customers, that we really want to avoid SPICE syntax as much as possible. Otherwise, people may be tempted to think that SPICE is valid at the frequencies we are looking at, which is not the case. Jon Powell told us of an SSO problem at one of their customers where an IBIS model predicted a 0.4 nS rise time, but the actual rise time of the part was 2 nS, due to ground bounce delays. This underscores the need for package model improvements. A/R Kumar: Issue a BIRD on pin mapping. A/R Vivek: Address how to add more complex package model including pin to pin coupling. Break Birds BIRD 2. Jon Powell, Input Thresholds Jon' motivation in proposing BIRD #2 was to improve the usefulness of IBIS models for customers wishing to do timing analysis of their systems. Models are needed for signal integrity and for static timing analysis. The latter requires input threshold data, since otherwise you don't know what to measure the delay to. In general, we felt that we don't want to restrict IBIS to digital only, so Input thresholds have to be optional. If digital, we could default to 0.8 volts for Vil and to and 2.0 volts for Vih. We talked about an input-type parameter, such as "input = digital", input_analog = analog, input_load = .... The default input type would be digital and the default thresholds would be Vil = 0.8, Vih = 2.0. We felt the parser (or the simulator) should check for model input-type. If the input is digital and the IBIS model fails to include the threshold data, the parser (simulator) must issue a warning that says no threshold is specified, and therefore the defaults for Vil (0.8 V) and Vih (2.0 V) are assumed. This would allow for backward compatibility with IBIS 1.1 and would also allow other defaults to be used as appropriate. After this discussion, Jon volunteered to rewrite the BIRD and re-submit it. A/R Jon Powell: Re-write Bird 2 to 2.1, re-submit to the reflector for discussion at upcoming Open Forum telephone conferences. BIRD #3, Multiple Rails, Stephen Peters. Stephen outlined the problem that he had encountered on a multiple voltage processor: An output buffer was supplied by the 3.3V rail and the clamping diode was connected to the 5V rail. BIRD 3 addresses this problem. Kumar discussed Cadence's approach which calls out the rail at the top of the V/I column. After some discussion, we realized that Stephen's approach covered the same purpose and Stephen pointed out that his intention was to preserve as much as possible the same format already in IBIS. We briefly discussed Vcc relative versus ground relative specification, with no new conclusion. The observation was made that Gnd_clamp doesn't make sense if the low clamp isn't = gnd. We suggested High_clamp and Low_clamp, to which Jon Powell pointed out that just clamp is probably adequate, since the polarity of the clamp diode is implicit in the V/I data. We voted on BIRD #3 and passed it. It will be incorporated into IBIS Version 2.0. Bird #4, ECL Extension, Stephen Peters Stephen described BIRD #4 which supersedes BIRD #1. In essence, this BIRD relaxes the range over which data is collected, and requires the model file to explicitly say over what range data was generated. This BIRD, too, passed approval and will be incorporated into IBIS Version 2.0. Open Discussion, Open Issues All day, we had been collecting issues to address if we had time at the end. The list included devices that employ feedback, monotonicity, and parser improvements. Feedback, Will Hobbs and Bob Ward Bob Ward (Texas Instruments) and Will Hobbs (Intel) discussed devices that have feedback, with GTL as the front-runner of concern. The discussion addressed the real problem posed by feedback, whose characteristics depend on the reflected wave. We reached no conclusion other than that we needed to seriously address the problem quickly, and that it wasn't going to be easy to solve. Jon Powell requested a set of voltage waveforms at the output pin of GTL drivers into different loads. Monotonicity, General Discussion We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. Parser Improvements We briefly touched on ways that the parser could be improved, such as having it check for data range compliance and monotonically represented tables. Another improvement would be if the parser could alert the user to bad or suspicious data (.e.g., message saying 29 A in middle of nA data is suspicious). Jon Powell mentioned that he had some specific suggestions on how to improve coding style but would wait until we engaged a software engineer to tackle the Golden Parser for IBIS 2.0. Conclusion, Final Comments We reviewed the goals of the summit, which the summit largely met. All attendees expressed the feeling that the summit was worthwhile, and some suggested we get together face to face much more frequently, such as every 2-3 months. We decided to get together at least twice annually, and when we were approaching a critical juncture on a particular issue we could also convene. The level of interest and involvement by the EDA industry remains extremely high, and there is a slowly increasing level of participation by IC vendors. We agreed that we must engage many more IC vendors in IBIS if we are to achieve the level of effectiveness and acceptance in the electronic industry that we feel IBIS should enjoy. It is clear that I/O models are increasing in importance and that our efforts serve a real need. Over the last year we have tackled many challenges and have succeeded in establishing IBIS as an industry standard. At this summit, we shared a tremendous amount of information, clarified our joint vision of where we are going, and created some challenging goals for ourselves for the coming year. I want to sincerely thank all those who made the effort to attend, present and participate in this summit, and I hope this level of participation will continue in the coming year as we meet in our phone conferences to tackle our challenges. And, I hope to see you all at the next IBIS Open Forum Summit. From ccm!Will_Hobbs@intelhf.intel.com Mon Nov 29 11:49:11 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12284; Mon, 29 Nov 93 11:49:11 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p4EZs-000MNcC; Mon, 29 Nov 93 11:48 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p4Edk-0001KuC; Mon, 29 Nov 93 11:52 PST Received: by ccm.hf.intel.com (ccmgate) Mon, 29 Nov 93 11:52:07 PST Date: Mon, 29 Nov 93 11:52:07 PST From: Will Hobbs Message-Id: <931129115207_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Open Forum Summit Minutes, Part 1 I have already fax-ed these minutes to all those who attended the summit, as well as many who didn't. but to make sure that all those who may be interested in what happened at the IBIS summit, I am posting them to the ibis reflector. Due to limitations in our mailing program, I've had to split the minutes into two parts. This is part 1. Part 2 will go out under separate cover (boy, what an anachronism that is!). Regards, Will Hobbs Intel Corporation Minutes Fall '93 IBIS Open Forum Summit Santa Clara, CA, 11/12/93 Will Hobbs Part 1, Morning Session Attendees: Cadence Design Systems Zaki Rakib, Kumar Contec Microelectronics Maah Sango Intel Corporation Charles Anyimi, Gregg Fortner, Will Hobbs, Arpad Muranyi, Stephen Peters Interconnectix Incorporated Bob Ross Intergraph Electronics Walter Katz Logic Modeling Corporation Randolph Harr MicroSim Corporation Arthur Wong Performance Signal Integrity Vivek Raghavan Quad Design Jon Powell Quantic Laboratories Mike Ventham Siemens Nixdorf/Cadlab Ralf Bruening Texas Instruments Bob Ward Zeelan Technology Hiro Moriyasu Agenda AM All Assemble, get acquainted, have coffee Will Hobbs Intel IC vendor view of IBIS Randy Harr LMC Die 0.9 bare die spec work with National Bob Ross Interconnectix Measurement and Extraction of buffer data Stephen Peters Intel Obtaining Model Data from Simulation Break Jon Powell Quad-Design Slew Controlled Devices Arpad Muranyi Intel I/V/T Panel Handling Dynamic Char. of Buffers Lunch PM Kumar Cadence Simultaneous Switching Noise: A Package Library Based System Vivek Raghawan Performance Package Parameters Signal Integrity Break BIRD discussions: Jon Powell Quad Design BIRD 2 Stephen Peters Intel BIRDs 1, 3, 4 Open issues, action item review, summary Summit Goals * Synch up, share information * Share Industry/Company Updates * Discuss current areas of exploration and needs * Explore technical achievements, challenges * Successful techniques in use today * Problems or unsolved mysteries * Resolve ambiguity * Close in on IBIS 2.0 Definition * Identify ‘94 goals * Extend state of the art * Support customers’ needs * Make models widely available * Engage more IC vendors in IBIS activities We accomplished many of these goals. Specifically: * We reviewed the results of IBIS to date. * We learned ways in which various companies were generating or extracting model data, and shared our thoughts on how to improve this data gathering process. * We identified areas of fairly immediate future concern for IBIS, such as modeling switching noise, complex package interactions, feedback and controlled slew rate devices. * We brainstormed on solutions to certain technical problems. * We clarified some areas that had not been clear to everyone, such as monotonic entry of data. * We ratified two proposals for IBIS 2.0, one for specifying multiple rails, and one for relaxing voltage ranges so that ECL can be supported. * We reviewed another BIRD (specifying input thresholds) and generated requests for two more (related to packaging and supply noise), to focus on in upcoming Open Forum meetings. * We shared much information on specific modeling needs, customer expectations and demands from each company's perspective. * We re-affirmed the need to engage more IC Vendors in IBIS activities. * We renewed our friendships. Morning Session Will Hobbs: An IC Vendor's View of IBIS, Distribution of I/O models After we introduced ourselves, I outlined the agenda and set forth some of the goals I hoped could be achieved at the summit. I then summarized the accomplishments of the IBIS Open Forum to date. I described where models fit in the design flow of systems and components, outlined the three phases of model development and described how Intel distributes our models. Because Intel's strongest efforts are focused on new products, most Intel IBIS models have not been distributed except under non-disclosure. Of approximately 20 such models, only one, for the 82430 PCI chipset, has been generally released. Randy Harr of LMC: DIE 0.9 bare die spec work with National Randy Harr of Logic Modeling discussed the work LMC and National Semiconductor are undertaking with ARPA on the DIE MCM (Multi-Chip Module) specification, dealing with bare die on a substrate and interconnected to other die on the same substrate. Randy described some of the bare die work currently in progress. IBM is using up to 120 die on a ceramic substrate and other customers are doing chip on board. A new approach is called Chips First, in which cavities are created on the board with the die occupying the cavities, tied together through gold interconnects on an overlying layer. The big problem for MCM manufacturers is getting information about the die from the die manufacturers. (pad locations, models, dimensions, etc.). The problem is exacerbated by changes in die size and re-layout between steppings that they are not informed of. DIE = Device Information Exchange, which is now at revision 0.9, is the answer to this information flow problem. LMC is working with MCM foundries (IBM, Motorola, nCHIP, TI, Hughes, National Semiconductor, MMS), EDA vendors (Mentor, Harris EDA, Intergraph, Cadence, Racal Redac) and bare die vendors (National Semiconductor, Intel, Micron, IDT, Motorola, TI). The group is representing DIE and IBIS in SGML (standard Generalized mark-up language), a data interchange format for textual information that allows the viewer to choose the formatting. SGML is being heavily used for hypertext applications. Mosaic is a new application that "turns all of Internet to an SGML file," including video, text, sound, etc., from across the Internet. Any SGML document can therefore be viewed worldwide over Internet using Mosaic. To put IBIS ASCII into SGML format only requires putting the keywords in angle brackets instead of square ones, and a few other changes to mark end of file. Randy volunteered to help companies convert their syntax over to SGML format. There is DIE 0.9 information in vhdl.org in /pub/die/ Randy's foils went into details on the actual format of the DIE file, which is organized hierarchically, with some information required and other information optional. In addition to internally specified data, the specification allows external references to other files in other formats, including IBIS, BSDL, VHDL, WAVES and EDIF descriptions. DIE 0.9 adds a definition of what subset of IBIS data is required for DIE files. Randy suggests we add that subset definition to the IBIS specification itself. Randy's presentation ended with specific recommendations for "improvements" to IBIS: 1. Well defined measurement methodologies 2. Explicit process de-rating 3. Change the pull_up Vcc-reference to ground-reference 4. Add I/V/T modeling to pull_up and pull_down 5. Improve the package model so beam lead (TAB, ribbon) devices can be incorporated nicely 6. Clean up and normalize syntax, possibly change to SGML style Note 1: At Intel, we considered item 2 originally, and chose not to explicitly call that out for two reasons: different processes require different de-ratings, and vendors may not wish to make the size of their process variations public knowledge. -- Will Note 2: Item 1 is addressed in V1.1 of IBIS to the extent possible, since equipment varies from company to company. We (the Open Forum) may choose at some time to put out a measurement guide that improves on this. Item 3 has been discussed repeatedly and will not be changed due to backward compatibility issues. Items 4 and 5 were addressed at the Summit, and will be subjects of further discussion and BIRDs. Bob Ross of Interconnectix: Measurement and Extraction of Buffer Data Bob's foils focused on obtaining model data by measurement of silicon, for both CMOS and TTL technologies. The measurement process is largely a database management problem. The problem is in mapping data: you might not have all parts in all packages, so you have to figure out how to map data from a part in one package type into another package. It is also an inventory control problem, cataloging, mapping data. The data comes from data books and from measurement. Bob's remaining discussion focused on measurement. Sweep range is an issue, because some devices can be destroyed by sweeping beyond the rail. There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Many databases contain >200 data points. They select a subset of the data, generally based on a fitting algorithm to make model smaller without sacrificing key data. Measuring with data book loads can often produce misleading results. For example, some devices connected to a 500 ohm load will exhibit large overshoot due to on-chip charge storage effects. One would rarely or never see this in a real system. IBIS specifies a 50 ohm load, but that's not always appropriate. The challenges in measuring data from parts include test board considerations; power supply selection, logic state selection, range selection, signal integrity problems, presence of nearby grounds, 50 ohm transmission line environment, clean signal sources, high speed data acquisition hardware, load configuration, method of automatic data acquisition and storage. "Clamp data is the most significant, most under-specified data in dealing with signal integrity problems." Stephen Peters of Intel: Obtaining Model Data from Simulation Stephen Peters described how Intel creates IBIS data from our internal Spice-like simulator called TIM/CSE. He also described how Intel engineers validate the data against silicon, and some of the problems in obtaining data. The model engineer acquires the I/O buffer schematic and process file from their respective engineers, and analyzes the schematic to see what portion of the design has to be modeled. (S)he also must understand enough of the circuit to know which nodes to tie to what state to produce a rising or falling edge, a high or low state. The derived model is used in a simulation into standard loads; the actual buffer circuitry design is simulated into those loads in the Intel simulator, and the results are compared against simulations of the IBIS models run on representative commercial simulators using the same loads. When silicon becomes available, curve tracers are used with a slow sweep to obtain actual data which is then correlated against the data derived from simulation. Corrections to the model are made if necessary. Jon Powell of Quad Design: Behavioral Models and Time-Varying Devices. Jon discussed the problem of modeling slew-rate controlled devices. He described one method used to obtain slew control, which involves paralleling multiple output devices and turning them on sequentially. Unfortunately, the behavior of such designs is difficult to measure with a DC measurement methodology: transistor switching transitions are not predictable from DC measurement. We therefore need a simple AC measurement technique. The other approach to controlling slew rate, using feedback, poses other problems. Feedback is not adequately addressed in IBIS so far. Jon showed an example using a SPICE and an IBIS model: with a 50 pF load, IBIS and SPICE match well, but for a 50 ohm load, the non-feedback (IBIS) model exhibited an extremely fast rise time, while the SPICE version showed the correct, slower, slew rate. (Overlap of turn-on and tun off was eliminated on that particular example that caused the difference.) Although DC measurement techniques fail to show the turn-on/off timings, by using terminated transmission lines in SPICE simulations you can see the turn-off and turn-on of various devices easily. Jon then looked at generating data from devices by using AC I/V curves: by driving different transmission line loads, you can generate different I/V data, but this is time consuming. Conclusion: Preferably, I/V data should be developed from SPICE models by the IC manufacturer, since all semiconductor vendors have internal circuit modeling capabilities. Arpad Muranyi of Intel: Present State of IBIS Modeling, and Extending it to Handle I/V/T. Arpad focused on ramps, and how they can be specified in a non-linear fashion. One problem is that at the point of transition from high to ramp-down, the V/I curves that are applied to the simulation are switched from the pull-up to the pull-down. This could cause a step, a discontinuity. Presently, as the ramp-down occurs, the voltage that acts as a pointer into the V/I curve data is the difference voltage between the output pin and the buffer output (the curve data). Jon said that Quad understands that there is a time involved in switching from the pull-up curve to the pull-down curve, and inserts a smoothing function to represent this switching transition. Arpad feels we need a surface plot to show how the V/I curves vary with respect to time. We would need four surface plots to fully specify a buffer: pull-up turn-on, pull-up turn-off, pull-down turn-on, pull-down turn-off. Data can be derived from SPICE fairly easily, but so far we haven't come up with an adequate way via measurement. If you measure devices driving into a constant voltage, you cancel package capacitance. If you measure into constant current, you cancel out inductance; measuring into a constant voltage cancels capacitive effects; and measuring into a constant impedance incurs effects from both capacitance and inductance. Although the point was understated, Arpad called me later to emphasize that he has had success with 3D modeling and that he would write up some details for distribution to attendees. Arpad's family of curves was generated by holding a voltage constant, then turning on and off the voltage, plotting current against time, then re-running at a different voltage. Turn-off time is much faster than turn-on. Turn-on time is determined by the gate R/C of the pre-driver. Generally, slew rates aren't controlled by keeping the pull-down on partially while you are turning on the pull-up (or vice-versa). Except in DC load conditions, the turn-off characteristics can probably be largely ignored. The challenges we must address: * How do we represent this surface data? * How many points are needed to describe the surface? * How can IBIS transport the data? (Some assumptions can reduce the amount of data points.) * How can this data be measured? (Need a fast current probe) * How do we deal with package effects? Panel discussion, chaired by Jon Powell and Arpad Muranyi: Handling Dynamic Characterization of Buffers Jon expressed dismay that some of the key drivers from the EDA industry were absent, notably Kellee Crisafulli of HyperLynx, and Integrity. For Quad, their primary interest is the device switching time (how long a transistor takes to turn on or off) and the delay between the turn on times of parallel devices. Stephen made the point that V/I curves vary depending on the DC point; Jon said that at least in Quad's case, they know how transistors turn on and turn off and they account for that. If IC Vendors wanted to provide the more complete V/I data, you could gain 2% more accuracy, but at the expense of huge amounts of simulation time. We don't want to so complicate the gathering of data that manufacturers will be scared off. We could have several levels of model so we could still keep it simple for those that don't want to gather the surface data. Data points could be minimized by creating a polynomial that describes the surface or describes the scaling factor to be applied to the V/I curves. Ground bounce simulation is the critical thing customers are after in wanting slew rate control information. Lunch Lunch time discussion abounded between individuals, and I wasn't taking notes. From ccm!Will_Hobbs@intelhf.intel.com Tue Nov 30 11:24:34 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24961; Tue, 30 Nov 93 11:24:34 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p4afd-000MOTC; Tue, 30 Nov 93 11:23 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p4ajd-0000dLC; Tue, 30 Nov 93 11:27 PST Received: by ccm.hf.intel.com (ccmgate) Tue, 30 Nov 93 11:27:41 PST Date: Tue, 30 Nov 93 11:27:41 PST From: Will Hobbs Message-Id: <931130112741_11@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Meeting Reminder, 12/3 From: Will Hobbs, (503) 696-4369; fax (503) 696-4210 Manager, Models Engineering Xcceleration Tools Group Intel Corporation 5200 N.E. Elam Young Parkway Hillsboro, Oregon 97124 Subject: Meeting Reminder, 12/3 Date: November 29, 1993 When: December 3, 1993, 9:00 AM to 11:00 PDT. Where: Phone number, (415) 904-8944. How: Reservation number is 550560 (this meeting only). Dial direct, ask for Will Hobbs in the IBIS Open Forum. Please note: If you know of someone new who wants to join the email reflector (ibis@lmc.com), or if you have updates to your email address, email to ibis-request@vhdl.org. IBIS Agenda, 12/03 9:00 Check-in 9:05 Introductions of new IBIS members 9:10 11/12 Summit Minutes Review, Opens for New Issues Will Hobbs 9:15 Enlisting new IC Vendors W. Hobbs, All 9:20 Opens from Summit Complex package Specifications Vivek Raghawan Pin Mapping Kumar New Model Types (R-Packs, etc.) Jon Powell 9:50 BIRDS VIH, VIL Input Threshold, Bird #2.1 Jon Powell 10:15 Other Opens How do EDA Vendors support IBIS? W. Hobbs, All Open Side K. Crisafulli Spec Ambiguity (ramp time) W. Hobbs, S. Peters 10:50 Wrap-Up Action Items Next Meeting Plans From Mei.Wong@bunyip.metasw.com Wed Dec 1 11:50:55 1993 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07862; Wed, 1 Dec 93 11:50:55 PST Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28447; Wed, 1 Dec 93 14:49:12 -0500 Received: from lauto.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 144808.22492; Wed, 1 Dec 1993 14:48:08 EST Received: by lmodel.lmc.com (/\==/\ Smail3.1.24.1 #24.7) id ; Wed, 1 Dec 93 11:52 PST Received: from metasw.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10756; Wed, 1 Dec 93 14:41:19 -0500 Received: from bunyip.metasw.com ([192.0.4.5]) by metasw.com (4.1/SMI-4.1) id AA29831; Wed, 1 Dec 93 11:41:40 PST Received: from cc:Mail by bunyip.metasw.com id AA754774840 Wed, 01 Dec 93 11:40:40 EST Date: Wed, 01 Dec 93 11:40:40 EST From: Mei.Wong@bunyip.metasw.com (Mei Wong) Encoding: 177 Text Message-Id: <9311017547.AA754774840@bunyip.metasw.com> To: ibis@lmc.com Cc: Mei.Wong@bunyip.metasw.com Subject: IBIS To whom it may concern, please add mei@metasw.com to IBIS distribution list. Thanks. Regards, Mei Hsu Wong Product Marketing Manager Meta-Software Inc. (408) 369-5407 From cpk@Cadence.COM Wed Dec 1 14:26:52 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08772; Wed, 1 Dec 93 14:26:52 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id OAA22529 for ; Wed, 1 Dec 1993 14:19:02 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma022511; Wed Dec 1 14:18:11 1993 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA26754; Wed, 1 Dec 93 14:21:15 -0800 Received: by hot (5.65+/1.5) id AA22339; Wed, 1 Dec 93 17:24:03 -0500 Date: Wed, 1 Dec 93 17:24:03 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9312012224.AA22339@hot> To: ibis@vhdl.org Subject: BIRD #??? (yet to be issued) Cc: cpk@Cadence.COM Hi guys: I am sorry I forgot the procedure to issue a BIRD. Here is my proposal which has to yet get the official BIRDIE seal. ------------cut----------------------------------------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: ???? ISSUE TITLE: Pwr and gnd pin mapping REQUESTER: C. Kumar, Cadence Design Systems DATE SUBMITTED: December 1, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: This proposal addresses the need to extend the IBIS specification to include ground and power pin mappings. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The proposal is to add two more optional columns to the pin specification statement. These columns are named gnd (for ground) and pwr (power). These identify the power and ground pins associated with the signal pin in question. Following is an example: Pin] signal_name model_name gnd pwr 1 RAS0# Buffer1 10 18 2 RAS1# Buffer2 12 20 .... ... ... 10 GND GND1 ... 12 GND GND2 .... 18 Vcc3 PWR1 ... 20 Vcc5 PWR2 ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: 1. There are devices which have multiple power and ground supplies. The above format will unambiguosely identify the power and ground pins associated with a given signal. Besides the suggested extension is evolutionary and should be easy to digest. ***************************************************************************** ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From ccm!Don_A_Telian@intelhf.intel.com Wed Dec 1 15:43:49 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09217; Wed, 1 Dec 93 15:43:49 PST Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0p51C0-000MO8C; Wed, 1 Dec 93 15:42 PST Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0p51GA-0001CgC; Wed, 1 Dec 93 15:47 PST Received: by ccm.hf.intel.com (ccmgate) Wed, 1 Dec 93 15:47:01 PST Date: Wed, 1 Dec 93 15:47:01 PST From: Don A Telian Message-Id: <931201154701_1@ccm.hf.intel.com> To: Arpad_Muranyi@ccm.hf.intel.com, Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org Cc: cpk@Cadence.COM Subject: Re: BIRD #??? (yet to be issued) Kumar, Many signals will reference multiple pwr or gnd pins. How would you handle that? The BIRD seems to make allowance for only one pin. Is the bussing of "GND2" carried through its name? Don Telian _________________________________________________________________________ Hi guys: I am sorry I forgot the procedure to issue a BIRD. Here is my proposal which has to yet get the official BIRDIE seal. ------------cut--------------------------------------------------------------- --- Buffer Issue Resolution Document (BIRD) BIRD ID#: ???? ISSUE TITLE: Pwr and gnd pin mapping REQUESTER: C. Kumar, Cadence Design Systems DATE SUBMITTED: December 1, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: ****************************************************************************** -* ****************************************************************************** -* STATEMENT OF THE ISSUE: This proposal addresses the need to extend the IBIS specification to include ground and power pin mappings. ****************************************************************************** -* STATEMENT OF THE RESOLVED SPECIFICATIONS: The proposal is to add two more optional columns to the pin specification statement. These columns are named gnd (for ground) and pwr (power). These identify the power and ground pins associated with the signal pin in question. Following is an example: Pin] signal_name model_name gnd pwr 1 RAS0# Buffer1 10 18 2 RAS1# Buffer2 12 20 .... ... ... 10 GND GND1 ... 12 GND GND2 .... 18 Vcc3 PWR1 ... 20 Vcc5 PWR2 ****************************************************************************** -* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: 1. There are devices which have multiple power and ground supplies. The above format will unambiguosely identify the power and ground pins associated with a given signal. Besides the suggested extension is evolutionary and should be easy to digest. ***************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** -* From cpk@Cadence.COM Thu Dec 2 06:41:16 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18429; Thu, 2 Dec 93 06:41:16 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id GAA19663; Thu, 2 Dec 1993 06:32:03 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma019646; Thu Dec 2 06:31:55 1993 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA11479; Thu, 2 Dec 93 06:34:55 -0800 Received: by hot (5.65+/1.5) id AA22631; Thu, 2 Dec 93 09:37:51 -0500 Date: Thu, 2 Dec 93 09:37:51 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9312021437.AA22631@hot> To: Arpad_Muranyi@ccm.hf.intel.com, Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org, Don_A_Telian@ccm.hf.intel.com Subject: Re: BIRD #??? (yet to be issued) This scheme has an implied assumption. i.e. each signal can be uniquley identified with one power and one ground pin, while the package itself can have multiple power and ground pins. It merely makes the association between signal pin and corresponding power and ground pins explicit. If you have a more robust scheme can you propose it? Thanx - kumar From bracken@valhalla.performance.com Thu Dec 2 07:41:46 1993 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18759; Thu, 2 Dec 93 07:41:46 PST Received: by valhalla.performance.com (4.1/SMI-4.1) id AA01145; Thu, 2 Dec 93 10:41:51 EST Message-Id: <9312021541.AA01145@valhalla.performance.com> To: ibis@vhdl.org Subject: Re: BIRD #??? (yet to be issued) In-Reply-To: Your message of "Thu, 02 Dec 93 09:37:51 EST." <9312021437.AA22631@hot> Date: Thu, 02 Dec 93 10:41:49 -0500 From: bracken@valhalla.performance.com Y'all, Say we have: Pins: 11 12 13 21 22 23 + + + + + + | | | | | | | | | | | | Buses: +-----+------+-----> to a few +-----+------+-----> to a few GNDBUS1 drivers GNDBUS2 more In Kumar's suggested format we have: [Pin] signal_name model_name gnd pwr 1 RAS0# Buffer1 10 18 2 RAS1# Buffer2 12 20 .... ... ... 11 GND GNDBUS1 12 GND GNDBUS1 13 GND GNDBUS1 .... 21 GND GNDBUS2 22 GND GNDBUS2 23 GND GNDBUS2 One problem with this (as I see it) is that the *model* names GND and POWER are "special" (they indicate that the pin is NOT connected to an ordinary nonlinear I-V curve model, and so we don't go looking for that model in the .ibs file.) In the suggested format above, we don't have any way to tell that GNDBUS1 isn't an I-V model. The *signal* names, of course, are sacred because they appear in the schematic symbol for the part. Pins that connect to separate internal buses might just be given the same name (e.g. GND) in the schematic, and so we can't rely on these to distinguish buses. I suggest we instead use the two remaining columns to specify the associated bus names; for example, [Pin] signal_name model_name gnd pwr 1 RAS0# Buffer1 GNDBUS1 PWRBUS1 2 RAS1# Buffer2 GNDBUS2 PWRBUS2 .... ... ... 11 GND GND GNDBUS1 NA 12 GND GND GNDBUS1 NA 13 GND GND GNDBUS1 NA .... 21 GND GND GNDBUS2 NA 22 GND GND GNDBUS2 NA 23 GND GND GNDBUS2 NA It's now clear which pin is a lowly ground pin (and not an I-V model), and it's also clear to which bus every GND pin and every driver is connected. Now there's no ambiguity--I think... But what would we do with buffers that have connections to multiple supply voltages? --Eric Bracken bracken@performance.com From bward@dadhb1.ti.com Thu Dec 2 07:58:17 1993 Return-Path: Received: from lobby.ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18851; Thu, 2 Dec 93 07:58:17 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by lobby.ti.com with SMTP (5.65c/LAI-3.2) id AA17867; Thu, 2 Dec 1993 09:57:28 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA29827; Thu, 2 Dec 1993 09:52:49 -0600 Message-Id: <199312021552.AA29827@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA12207; Thu, 2 Dec 1993 09:50:23 -0600 Date: Thu, 2 Dec 1993 09:50:23 -0600 From: Bob Ward To: ibis@vhdl.org Subject: BIRD #??? ( yet to be issued ) Ibis folks - Don Telian beat me to it, but his concern about signal pins mapping to multiple power or ground pins is real. We have chips that do just that, with the bussing connections made both on the leadframe and on the chip. In fact we need to be ready to handle all the possibilities of one power/ground pin mapping to several signals, one signal mapping to several power/ground pairs, one to one mapping, etc. I am not quite sure I have the answer as to how to do it in the ibis data tables, but I can add weight to the reality of the requirement. Thanks, ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= ___ (o o) -------------------------------ooO-(_)-Ooo----------------------------------- Here I sit in endless joy, 'cause I was here before Kilroy!!! From cpk@Cadence.COM Thu Dec 2 08:53:52 1993 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19183; Thu, 2 Dec 93 08:53:52 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id IAA23947; Thu, 2 Dec 1993 08:46:02 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma023932; Thu Dec 2 08:45:37 1993 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA18326; Thu, 2 Dec 93 08:48:36 -0800 Received: by hot (5.65+/1.5) id AA22719; Thu, 2 Dec 93 11:51:32 -0500 Date: Thu, 2 Dec 93 11:51:32 -0500 From: cpk@cadence.com (C. Kumar) Message-Id: <9312021651.AA22719@hot> To: ibis@vhdl.org, bracken@valhalla.performance.com Subject: Re: BIRD #??? (yet to be issued) I think Eric's proposal is more general while still being simple and evolutionary. Is there anybody else who can think of even a better solution? - kumar From bward@dadhb1.ti.com Thu Dec 2 08:56:38 1993 Return-Path: Received: from ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19186; Thu, 2 Dec 93 08:56:38 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.65c/LAI-3.2) id AA09835; Thu, 2 Dec 1993 10:57:46 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA02676; Thu, 2 Dec 1993 10:49:52 -0600 Message-Id: <199312021649.AA02676@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA12234; Thu, 2 Dec 1993 10:47:35 -0600 Date: Thu, 2 Dec 1993 10:47:35 -0600 From: Bob Ward To: ibis@vhdl.org Subject: More on BIRD #??? Just One More Thing (tm) [Promises, promises!] So I just sent my note about adding weight to the requirement about using multiple power and ground pin mappings, and Eric Bracken's letter showed up that indicates I should have elaborated further on our bussing structure. In at least one case, we have a chip that will be particularly nasty for things like simultaneous switching studies, even though that is one thing that ibis models will be in demand for. The structure in question is this: pwr/gnd pwr/gnd p p ----------- i i | n n leadframe | | | +-+-------+------+------+-+ ----------- | | | | bond wire/pad | | | | +-+-+ +-+-+ +-+-+ +-+-+ ----------- | | | | | | | | | d d d d d d d d | r r r r r r r r | i i i i i i i i on chip v v v v v v v v | e e e e e e e e | r r r r r r r r | | | | | | | | | ----------- | | | | | | | | leadframe The leadframe busses at least two, sometimes four, power or ground pins together. This is tapped at several points to provide connections to the chip, where pairs of drivers are bussed together with on chip metalizing, on both power and ground sides. Now it seems to me that if we are trying to determine this from external measurements made at the pins, we could if the right combinations of simultaneous switchings were induced while the output is monitored on the pin of interest. But without some knowledge of the circuit to start from, the number of measurements is potentially huge, and the data potentially confusing. I guess I toss this out to the group by way of saying "Help!", if anyone has thoughts on how to handle this, I would like to hear them. I admit to being more than a little at a loss how to measure this in general and then also how to specify it in ibis-isms once measured. In specific cases it can be asserted, and I would accept it, that it doesn't matter anyway. That may the situation in more cases than I think, and if that is so I am most happy to not worry about it. But at the moment I am worried about it. Discussion? From bward@dadhb1.ti.com Thu Dec 2 13:46:08 1993 Return-Path: Received: from ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20799; Thu, 2 Dec 93 13:46:08 PST Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.65c/LAI-3.2) id AA21134; Thu, 2 Dec 1993 15:47:26 -0600 Received: from node_4c136 (80_51.sc.ti.com) by tilde.csc.ti.com id AA22848; Thu, 2 Dec 1993 15:40:55 -0600 Message-Id: <199312022140.AA22848@tilde.csc.ti.com> Received: by node_4c136 (5.65c/IDA1.4.4.1-Domain/OS) id AA12790; Thu, 2 Dec 1993 15:38:38 -0600 Date: Thu, 2 Dec 1993 15:38:38 -0600 From: Bob Ward To: ibis@vhdl.org Subject: Some more yet on the power bus question Hi, ibis folks - Thus saith bracken@valhalla.performance.com on 12 DEC 93 at 1538.48 hrs : > >Bob, > > I have a few questions regarding this "complex" example: > > 1) You say "in at least one case" this will occur--that makes it sound > like you folks don't design things this way very often. Do you > see that situation changing (i.e. will more designs be done this > way in the forseeable future?) > > 2) How fast is such a design operating? The faster you go, the more > important the "details" become. > > If it's a high-speed design that needs a high level of detail, then it > seems to me that you have the following choices: > > a) Use a SPICE subcircuit, with elements for each "leg" of this > topology; > > b) Measure the Z-parameters of the structure (inject an AC current > into each pin, and measure the resulting voltage drops > to every other pin.) Do this versus frequency from DC > to "daylight" (or the maximum freq. of interest.) Or, use S > parameters. > > c) Use RLGC matrices, with some additional information about how > each "leg" comes together at various nodes. I assert that > this approach is tantamount to having a SPICE subcircuit, > but harder to read. > >You're quite right that the laboratory measurements become very >difficult, even for finding the S or Z parameters. For SPICE or RLGC >matrices, lab work may be next to impossible. At that point, you need >numerical field solver software to generate the equivalent RL(G)C >networks. > We have just started this style of grouping with some faster parts in hopes of getting less interaction between simultaneously switching drivers. The proof is in the testing, and if it works well, we will do more parts this way. Just at the moment we have done a couple that are not yet publically announced, but are fast. The details are indeed important. I will not upstage the announcement by saying just how fast is fast, but "Spice level" simulations show the sensitivity to detail to be considerable. I would hope to be able to make ibis style models rather than Spice models for all the usual reasons, less work ( maybe ), less exposure of proprietary circuitry, etc. The use of RLGC matrices was kicked around at the summit, and may be the only real option for this case. In fact it may be the primary option for capturing leadframe parasitics in general. I would, as I assume most of us would, like to see a more "ibis-like" description, but that may not be possible. I am awaiting a paper from one of our modelling labs here concerning measurement of package parasitics to see if the methods they discuss are applicable here. I am told that I can share at least a summary, if not the whole paper, with the ibis group, and I will as soon as I receive it and make a little sense out of it. Real heavy duty field solving will probably become necessary before much longer to get a good representation of package parasitics, since measurements are very delicate at best. The main thrust of what I am saying in my example is that "here are shades of things to come" and I hope we can grow ibis into a big enough and tough enough bird to be able to handle it. ============================================================================= __ / / \ / / Bob Ward /__ / / / / / / MSG: SQU / \ _ /_ / / / _ __ _ / INET: bward@dadhb1.ti.com (____ / (_)_ /__) (__(__/ (_(_/ (_(_/ 713+274-4146 Voice 713+274-3911 Fax ============================================================================= ___ (o o) -------------------------------ooO-(_)-Ooo----------------------------------- Here I sit in endless joy, 'cause I was here before Kilroy!!! From lmsi!milpitas.lmc.com!randyh@UB.com Thu Dec 2 15:31:47 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21432; Thu, 2 Dec 93 15:31:47 PST Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA13793; Thu, 2 Dec 93 15:27:16 PST Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA15044; Thu, 2 Dec 93 15:23:11 PST Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA02005; Thu, 2 Dec 93 15:23:11 PST Date: Thu, 2 Dec 93 15:23:11 PST From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9312022323.AA02005@fiji.lmsi.com> To: bward@dadhb1.ti.com Subject: Re: More on BIRD #??? Cc: ibis@vhdl.org For whatever it is worth: We studied this issue in deciding what to do with the DIE spec work. See the files: pub/die/wrkshop2/electric.{mif,ps} (white paper on topic) pub/die/wrkshop2/trans_te.{mif,ps} (viewfoils on topic) on vhdl.org (use same email request to archive@vhdl.org, ftp, etc. as for ibis). We discovered and analyzed the various forms (even more detailed and difficult than Bob Ward reports) but discovered most of the power / ground bounce analysis tools could not handle the complexity. We decided to simplify to what Kumar of Cadence (or Eric's extension) is proposing -- one power and one ground pin specification per signal pad. See the DIE_PADS_SUPPLY_GROUPING (page 75 of the DIE Format Reference Manual ver 0.9; in file pub/die/die0-9/die0-9.{rtf,ps} or on floppy given at Summit) for our method of specification. By the way, it is a Level 1 setting also! randy harr randyh@milpitas.lmc.com