From owner-ibis Wed Aug 1 08:42:36 2001 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f71FgZ7n014361; Wed, 1 Aug 2001 08:42:36 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id PAA05374; Wed, 1 Aug 2001 15:42:24 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 01 Aug 2001 15:42:23 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 08:42:22 -0700 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A78C2@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'Hailong Wang'" , ibis@eda.org, ibis-users@eda.org Subject: RE: About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_du t, L_dut Date: Wed, 1 Aug 2001 08:41:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11AA0.73E128F0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11AA0.73E128F0 Content-Type: text/plain; charset="gb2312" Greetings: the R_pkg, C_pkg and L_pkg values are used to specify the minimum and maximum values of the pin resistance, capacitance and inductance for the entire package. These values appear under the [Package] keyword. The R_dut, C_dut and L_dut only represent the electrical characteristics of the pin used when gathering data for the [Rising Waveform] and [Falling Waveform] keywords. The 'dut' in R_dut etc. means 'device under test'. (Please note that it is recomended to gather the data in the waveform tables with R_dut, C_dut and L_dut set to zero). Regards, Stephen Peters Intel Corp. -----Original Message----- From: Hailong Wang [mailto:hlwang@avanticorp.com] Sent: Sunday, July 29, 2001 7:42 PM To: ibis@eda.org; ibis-users@eda.org Subject: About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut Hi, I found that the R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut have the very similar functions. But form the IBIS Specification V3.2, I found they are different. So I am confused, and want to the relationship between them. Thanks in advance! -- Best Regards. Hai-long Wang Tel:021-62837026x228 Avant! Shanghai R&D Center, 16th Floor, SunTong InfoPort Plaza No.55, West Huaihai Road, Shanghai, 200030, P.R.China ------_=_NextPart_001_01C11AA0.73E128F0 Content-Type: text/html; charset="gb2312"
Greetings:
 
  the R_pkg, C_pkg and L_pkg values are used to specify the minimum and maximum values of the pin resistance, capacitance and inductance for the entire package. These values appear under the [Package] keyword.  The R_dut, C_dut and L_dut only represent the electrical characteristics of the pin used when gathering data for the [Rising Waveform] and [Falling Waveform] keywords.  The 'dut' in R_dut etc. means 'device under test'.
 
(Please note that it is recomended to gather the data in the waveform tables  with R_dut, C_dut and L_dut set to zero).
 
  Regards,
  Stephen Peters
  Intel Corp.
-----Original Message-----
From: Hailong Wang [mailto:hlwang@avanticorp.com]
Sent: Sunday, July 29, 2001 7:42 PM
To: ibis@eda.org; ibis-users@eda.org
Subject: About relationshipp between R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut

Hi,
    I found that the R_pkg,C_pkg,L_pkg and R_dut, C_dut, L_dut have the very similar functions. But form the IBIS Specification V3.2, I found they are different. So I am confused, and want to the relationship between them.

Thanks in advance! 

-- 
Best Regards.
Hai-long Wang
Tel:021-62837026x228
Avant! Shanghai R&D Center,  16th Floor, SunTong InfoPort Plaza
No.55, West Huaihai Road, Shanghai, 200030, P.R.China
 
------_=_NextPart_001_01C11AA0.73E128F0-- From owner-ibis Fri Aug 3 02:00:56 2001 Received: from mailhost.avanticorp.com (mailhost.avanticorp.com [63.167.1.13]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7390p7n023985; Fri, 3 Aug 2001 02:00:54 -0700 (PDT) Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f7390ok20532; Fri, 3 Aug 2001 02:00:50 -0700 (PDT) Received: from ally.china.avanticorp.com (ally.china.avanticorp.com [172.21.16.10]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f7390mp20521; Fri, 3 Aug 2001 02:00:49 -0700 (PDT) Received: from avanticorp.com (mundas.china.avanticorp.com [172.21.18.46]) by ally.china.avanticorp.com (8.9.1b+Sun/8.9.3) with ESMTP id RAA07251; Fri, 3 Aug 2001 17:00:19 +0800 (CST) Sender: lli@avanticorp.com Message-ID: <3B6A681E.FFB35DB9@avanticorp.com> Date: Fri, 03 Aug 2001 17:00:14 +0800 From: Li Li X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: zh, en MIME-Version: 1.0 To: "'ibis@eda.org'" , "'ibis-users@eda.org'" Subject: about [Driver Schedule] Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Hi, I got some questions about [Driver Schedule]. Are there any other relationships between the models defined in [Driver Schedule] except timing relationships? How can I judge the way buffer of this model is connected to that of other models with the timing relationships? Where can I find the documents or test cases about [Driver Schedule]? Any comment or suggestion will be greatly appreciated. Thanks, Li From owner-ibis Fri Aug 3 08:18:07 2001 Received: from eia.org (gw.eia.org [207.17.181.50]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f73FI57n025079; Fri, 3 Aug 2001 08:18:06 -0700 (PDT) Received: from EIADOM-Message_Server by eia.org with Novell_GroupWise; Fri, 03 Aug 2001 11:10:47 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 03 Aug 2001 11:10:36 -0400 From: "Cecilia Fleming" To: , , Subject: Re: about [Driver Schedule] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f73FKv7n025080 Our bank information is as follows: First Union National Bank ABA# 056007604 ACCT# 2000005725537 Bank Swift Code: PNBPUS33 Regards, Cece >>> Li Li 08/03/01 05:00AM >>> Hi, I got some questions about [Driver Schedule]. Are there any other relationships between the models defined in [Driver Schedule] except timing relationships? How can I judge the way buffer of this model is connected to that of other models with the timing relationships? Where can I find the documents or test cases about [Driver Schedule]? Any comment or suggestion will be greatly appreciated. Thanks, Li From owner-ibis Fri Aug 3 11:36:07 2001 Received: from cambridge1-smrly1.gtei.net (cambridge1-smrly1.gtei.net [199.94.215.242]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73Ia47n025672 for ; Fri, 3 Aug 2001 11:36:06 -0700 (PDT) Received: from fairchild3-cp-fc.fairchildsemi.com (smtp2-fc.fairchildsemi.com [192.233.132.91]) by cambridge1-smrly1.gtei.net (Postfix) with SMTP id 27720A75E for ; Fri, 3 Aug 2001 15:33:43 +0000 (GMT) Received: FROM dnsbak.fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Fri Aug 03 11:30:58 2001 -0400 Received: from notes.fairchildsemi.com (fsce16.fairchildsemi.com [172.21.18.66]) by dnsbak.fairchildsemi.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00371; Fri, 3 Aug 2001 11:33:40 -0400 (EDT) Subject: Re: about [Driver Schedule] To: "Cecilia Fleming" Cc: , , From: Adam.Tambone@fairchildsemi.com Date: Fri, 3 Aug 2001 11:33:38 -0400 Message-ID: X-MIMETrack: Serialize by Router on SPNOTES01/Corporate/FSC(Release 5.07a |May 14, 2001) at 08/03/2001 11:33:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii OUCH! Someone is bumming! Adam Tambone From owner-ibis Tue Aug 7 16:21:44 2001 Received: from mailhost.avanticorp.com (mailhost.avanticorp.com [63.167.1.13]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f77NLg7n010247 for ; Tue, 7 Aug 2001 16:21:44 -0700 (PDT) Received: from mailhost.avanticorp.com (localhost [127.0.0.1]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f77NLfL14858 for ; Tue, 7 Aug 2001 16:21:41 -0700 (PDT) Received: from mailhost.india.avanticorp.com ([202.169.173.179]) by mailhost.avanticorp.com (8.10.1/8.10.1) with ESMTP id f77NLdp14846 for ; Tue, 7 Aug 2001 16:21:40 -0700 (PDT) Received: from avanticorp.com (ddthp100.india.avanticorp.com [172.24.1.125]) by mailhost.india.avanticorp.com (8.10.0/8.10.0) with ESMTP id f780QTB29239 for ; Wed, 8 Aug 2001 04:56:29 +0430 (IRST) Sender: bharath@avanticorp.com Message-ID: <3B710B5C.6F44CDA8@avanticorp.com> Date: Wed, 08 Aug 2001 04:50:20 -0500 From: Bharat Kumar Bhatt Organization: Avanti , India X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis-users@eda.org Subject: information on driver schedule Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sir, Where shall i find information regarding "driver schedule" in IBIS. thanks bharath. From owner-ibis Wed Aug 8 12:47:17 2001 Received: from mail.nesa.com (gw.nesa.com [64.3.167.94]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f78JlD7n013644; Wed, 8 Aug 2001 12:47:15 -0700 (PDT) Received: from porky (porky.nesa.com [172.29.121.18]) by mail.nesa.com (8.9.3/8.9.3) with SMTP id WAA21022; Tue, 7 Aug 2001 22:09:39 -0400 Message-Id: <3.0.5.32.20010808154634.00934100@mail.nesa.com> X-Sender: breda@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 08 Aug 2001 15:46:34 -0400 To: ibis@eda.org, ibis-users@eda.org From: Kathy Breda Subject: IBIS Summit - 2nd call for participation and presentations Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS SUMMIT SECOND CALL FOR PARTICIPATION & PRESENTATIONS!!! ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 8:30 AM - 5:00 PM, Thursday, September 13, 2001 Location: The Crowne Plaza Hotel 10 Lincoln Square Worcester, MA Tel: (508) 791-1600 Fax: (508) 791-1796 Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: North East Systems Associates, Inc. (NESA), IBIS Users Group Others to be determined WE ARE LOOKING FOR ADDITIONAL SPONSORS! (contact Kathy Breda, breda@nesa.com or Bob Ross, bob_ross@mentor.com) PCB Conference: September 10-14, 2001 East Worcester's Centrum Centre Worcester, Massachusetts See http://www.pcbeast.com/ for more information. BACKGROUND The IBIS Users Group (IBIS East) has been formed under the leadership of Dr. Edward Sayre from North East Systems Associates, Inc. (NESA) and has been meeting to consider and forward IBIS model user concerns. As a result of East coast meetings, the group has developed an IBIS Accuracy Handbook document and has initiated the project to format Connector Models. These topics plus others of current interest to the EIA IBIS Open Forum will be discussed at this meeting. This meeting will be conducted as a formal IBIS Summit Meeting. Presentation are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to: Kathy Breda (breda@nesa.com) CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Format of Presentation: Overhead Projections Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. Electronic presentations should be made available by September 7, 2001. Otherwise the presenter will be expected to provide up to 50 copies for distribution. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Kathy Breda (breda@nesa.com) AGENDA The agenda includes presentations, discussions, breaks, and a luncheon (which will be provided). This will be developed as presentation proposals are received. So far the following presentations are planned: "A Proposal for s2ibis3", Michael Steer, North Carolina State University "Modeling the Radiated Emission of Micro-controllers", Etienne Sicard, National Institute of Applied Science (INSA/DEIG), France "Power/Ground Simulation with IBIS Models and Pin Mapping Issues", Raj Raghuram, Sigrity, Inc. A user presentation - title to be determined, Bob Haller, Cereva Plus IBIS Macro Language and demonstration, IBIS Connector Specification, and other IBIS issues. LIST OF NEARBY HOTELS See http://www.pcbeast.com for travel directions, hotels and other information. ************************************************************** 0000,0000,8080
_____________________________________________________________________________________________________
Kathy Breda | Director of Marketing & Sales North East Systems Associates, Inc. | 5 LAN Drive, Suite 200 | Westford, MA 01886 [T] 978-392-8787 [F] 978-392-8686 [W] www.nesa.com
From owner-ibis Thu Aug 9 11:28:21 2001 Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f79ISJ7n017641 for ; Thu, 9 Aug 2001 11:28:20 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA12300 for ; Thu, 9 Aug 2001 18:28:19 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 09 Aug 2001 18:28:10 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 11:25:57 -0700 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A78E3@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis-users@eda.org'" Subject: IBIS Open Forum Teleconference Agenda Date: Thu, 9 Aug 2001 11:25:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" (Apparently, not everyone received the agenda for tomorrow's IBIS open forum meeting. I'm resending this to the users list.) IBIS Open Forum Meeting Agenda for 8/10/01 Bridge Number Reservation # Passcode New Number --> (877) 299-1938 none 6350164 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Peters - Intros of New IBIS Participants, Meeting Quorum Peters - Membership Update and Treasurers Report Fleming/Ross - Review of Previous Meeting's Minutes (and ARs) Peters - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Leventhal, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Peters - IEC 62014-3 (ICEM) Integrated Circuits Electromagnetic Model Proposal (IEC 93/67/NP IBIS and EMC Simulation) Perrin/Peters - JEDEC JC-16 Modeling and Testing Sessions - T10, Project 1414-DT - SCSI Signal Modeling Barnes PCBEAST 2001 IBIS Summit Meeting Ross - Funding IBIS Model Review Committee Angulo/Ross Majordomo Update Angulo New Administrative Issues All 8:45 Technical Discussion Connector Proposal Review Peters/Ross IBIS Futures Group Report (IBIS-X, API, BIRDxx) Peters -- IBIS-X Parser Funding BIRD70.4 - Golden Waveforms (VOTE) Edlund BIRD71 - Timing Test Loads in [Model Spec] to Support Peters PCI & PCI-X (VOTE) BIRD72 - Accommodating PMOS and NMOS/PMOS Series FET Dagostino/Ross Models BIRD73 - Fall Back Submodel Ross Other Pending BIRDS Peters ibischk3 Bug Tracking Ross - BUG58 - Wrong Bug Number for Missing R,L,C_pkg Ross Subparameter(s) - BUG59 - Crash with Decimal Points for [Package] Mirmak Subparameters New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Fri Aug 10 10:02:53 2001 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7AH2o7n022265 for ; Fri, 10 Aug 2001 10:02:52 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA247042; Fri, 10 Aug 2001 12:58:54 -0400 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7AGr8o33528; Fri, 10 Aug 2001 12:53:08 -0400 Importance: Normal Subject: BIRD 70.5 To: ibis-users@vhdl.org Cc: bob_ross@mentorg.com, sjpeters@ichips.intel.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Gregory R Edlund" Date: Fri, 10 Aug 2001 12:00:49 -0500 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 12:00:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii I made the following changes according to our discussion at today's Open Forum call: 1. Specified table format should conform with [Rising/Falling Waveform]. 2. Specified measurement location as driver/receiver I/O pad. 3. Only one waveform required rather than one waveform pair. 4. Changed Test_Load to Test_load. 5. Specified non-inverting driver output when using single-ended waveform with differential driver. 6. Changed "SPICE" to "reference waveforms." Greg Edlund Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com ******************************************************************************* ******************************************************************************* BIRD ID#: 70.5 ISSUE TITLE: Golden Waveforms REQUESTOR: Greg Edlund, IBM DATE SUBMITTED: March 16, 2001; April 16, 2001; April 18, 2001; May 4, 2001; July 23, 2001; August 10, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Golden Waveforms are a set of SPICE waveforms simulated using known ideal test loads. They are useful in verifying the accuracy of behavioral simulation results for any given simulator. They are not the same thing as the traditional VT tables recommended in the "IBIS Cookbook." The "I/O Buffer Accuracy Handbook" recommends a set of ideal test loads for classical push-pull and open-drain drivers. There is currently a problem with including Golden Waveforms in an IBIS datasheet: the simulator tries to use these waveforms to construct its stimulus waveform, and erroneous simulations result. This BIRD proposes a new syntactical construct to tell the simulator that a waveform is a Golden Waveform. The simulator may then choose to ignore the data or (better yet) run a set of simulations using the network and circuit parameters provided and report the correlation between the simulation results and the Golden Waveforms. The mechanism for describing a Golden Waveform involves two new keywords whose scope is global: [Test Load] and [Test Data]. Under the [Test Data] keyword are eight Wavevform keywords whose scope is local. [Test Load] is a description of a test load network that may be referenced by any Golden Waveform under the [Test Data] keyword. [Test Data] is a marker keyword that indicates the beginning of a group of Golden Waveforms. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: |============================================================================= | | Keywords: [Test Data] | Required: No | Description: Indicates the beginning of a set of Golden Waveforms | and references the conditions under which they were derived. | An IBIS file may contain any number of [Test Data] sections | representing different driver and load combinations. | | Sub-Params: Test_data_type, Driver_model, Driver_model_inv, Test_load | | Usage Rules: The name following the [Test Data] keyword is required. | It allows a tool to select which data to analyze. | | The Test_data_type subparameter is required, and its value | must be either "Single_ended" or "Differential." | The value of Test_data_type must match the value of |* Test_load_type found in the load called by Test_load. | | The Driver_model subparameter is required. Its value | specifies the "device-under-test" and must be a valid [Model] | name. Driver_model_inv is only legal if Test_data_type is | Differential. Driver_model_inv is not required but may be | used in the case in which a differential driver uses two | different models for the inverting and non-inverting pins. | | The Test_load subparameter is required and indicates which | [Test Load] was used to derive the Golden Waveforms. It must | reference a valid [Test Load] name. | |----------------------------------------------------------------------------- | [Test Data] Data1 Test_data_type Single_ended Driver_model Buffer1 Test_load Load1 | |============================================================================= | | Keywords: [Rising Waveform Near], [Falling Waveform Near], | [Rising Waveform Far], [Falling Waveform Far], | [Diff Rising Waveform Near], [Diff Falling Waveform Near], | [Diff Rising Waveform Far], [Diff Falling Waveform Far] |* Required: At least one Rising/Falling waveform is required under the | scope of the [Test Data] keyword. | Description: Describes the shape of the rising and falling Golden |* Waveforms of a given driver and a given [Test Load] measured |* at the driver I/O pad (near) or receiver I/O pad (far). | A model developer may use the [Rising Waveform Near/Far] and | [Falling Waveform Near/Far] keywords to document Golden | Waveforms whose purpose is to facilitate the correlation of |* reference waveforms and behavioral simulations. | | Sub-Params: None. | | Usage Rules: The process, temperature, and voltage conditions under which | the Golden Waveforms are generated must be identical to those | used to generate the VI and VT tables. The Golden Waveforms | must be generated using unpackaged driver and receiver models. | The simulator must NOT use the Golden Waveform tables in the | construction of its internal stimulus function. | |* The tables must conform to the format described under the |* [Rising Waveform] and [Falling Waveform] keywords. | | Both differential and single-ended waveforms are allowed | regardless of the value of Test_data_type. If Test_data_type | is Singled_ended then differential waveforms will be ignored. | If Test_data_type is Differential, a single-ended waveform |* refers to the model specified by Driver_model and the |* non-inverting driver output. | |----------------------------------------------------------------------------- | [Rising Waveform Far] | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Waveform Far] | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | |============================================================================= | | Keywords: [Test Load] | Required: No | Description: Defines a generic test load network and its associated | electrical parameters for reference by Golden Waveforms | under the [Test Data] keyword. The Golden Waveform | tables correspond to a given [Test Load] which is specified | by the Test_load subparameter under the [Test Data] keyword. | | Sub-Params: Test_load_type, C1_near, Rs_near, Ls_near, C2_near, Rp1_near, | Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, | C1_far, V_term1, V_term2, Receiver_model, Receiver_model_inv, | R_diff_near, R_diff_far. | | Usage Rules: The Test_load_type subparameter is required, and its value | must be either "Single_ended" or "Differential." | | The subparameters specify the electrical parameters | associated with a fixed generic test load. The diagram | below describes the single_ended test load. | | All subparameters except Test_load_type are optional. | If omitted, series elements are shorted and shunt elements | are opened by default. | | | V_term1 | o-----------o | | | | \ \ receiver_model_name | ______ / / ______ | | | NEAR Rp1_near \ \ Rp1_far FAR | | | | |\ | / / | |\ | | | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \ | | | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-| > | | | | / | | | | Td | | | | | / | | | |/ | | C1_near | \ Zo \ | C2_far | | |/ | | |______| === === / / === === |______| | | C2_near | \ \ | C1_far | | | | / / | | | | | | V_term2 | | | | o--------------o o-----------o o--------------o | | Rp2_near Rp2_far | | GND GND | | | If the Td subparameter is present, then the Zo subparameter | must also be present. If the Td subparameter is not present, | then the simulator must remove the transmission line from | the network and short the two nodes to which it was | connected. | | V_term1 defines the termination voltage for parallel | termination resistors Rp1_near and Rp1_far. This voltage | is not related to the [Voltage Range] keyword. | If either Rp1_near or Rp1_far is used, then V_term1 must | also be used. | | V_term2 defines the termination voltage for parallel | termination resistors Rp2_near and Rp2_far. | If either Rp2_near or Rp2_far is used, then V_term2 must | also be used. | | | Receiver_model is optional and indicates which, if any, | receiver is connected to the far end node. If not used, the | network defaults to no receiver. | | Receiver_model_inv is not required but may be used in the | case in which a differential receiver uses two different | models for the inverting and non-inverting pins. | Receiver_model_inv is ignored if Test_load_type is | Single-ended. | | If Test_load_type is Differential, then the test load is a | pair of the above circuits. If the R_diff_near or R_diff_far | subparameter is used, a resistor is connected between the | near or far nodes of the two circuits. If Test_load_type is | Single_ended, R_diff_near and R_diff_far are ignored. | |----------------------------------------------------------------------------- | [Test Load] Load1 Test_load_type Single_ended C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff_far = 100 Receiver_model Input1 | variable typ min max Vterm1 1.5 1.4 1.6 Vterm2 0.0 0.0 0.0 | | Example Transmission Line and Receiver test load from "I/O Buffer Accuracy | Handbook," section 3.4.4. | [Test Load] Tline_rcv Td = 1n Zo = 50 Receiver_model Input1 | |----------------------------------------------------------------------------- ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Please refer to BIRD 69.1 for history. BIRD 70 came about a result of an attempt to make BIRD 69.1 upwardly compatible with IBIS-X. BIRD 70 is actually more compact and efficient because it allows multiple models to access the same [Test Load]. Recommendations came from Bob Ross, Al Davis, and the IBIS Open Forum, 3/2/01. Changes between BIRD 69.1 and BIRD 70: 1. Scope of the "generic test load" is now global rather than being local to a particular model. This is a big improvement. 2. Added one subparameter, Golden_test_load, to [Rising Waveform], [Falling Waveform] keywords. Added text to describe new the subparameter. The Golden_test_load subparameter calls a [Test Load]. 3. Exported all the other code to the new [Test Load] keyword. 4. Removed T_ref subparameter. To do timing correlation, the simulator can pick a point on the 50 Ohm VT waveform as its "SPICE reference point" and then simulate both the 50 Ohm load and the Golden_test_load to calculate a time difference. 5. Removed Pkg_pin parameter. It is too complicated. The user can model a simple single-pin lumped circuit using the parameters supplied. 6. Added Tline_present subparameter. If not used, the Tline should be removed from the simulation rather than assigned a very small delay value. This prevents the simulator from taking ridiculously small time steps. 7. Replaced V_termxxx with tables similar to the dV/dt_x subparameters. This makes the BIRD more economical. 8. Got rid of the paragraph that read, "Using the Golden Waveform tables..." This seemed to be redundant. 9. Specified which parameters are optional and which are required. Changes between BIRD 70 and BIRD 70.1/70.2: 1. Moved the Golden Waveforms OUT of the [Model] scope and under the scope of a new keyword, [Test Data]. 2. Changed [Rising Waveform] to [Rising Waveform Near/Far]. Changed [Falling Waveform] to [Falling Waveform Near/Far]. 3. Added subparameter Driver_model under [Rising Golden Waveform] and [Falling Golden Waveform]. This is necessary because the waveforms are now outside the scope of the [Model]. 4. Changed the subparameter Golden_test_load to Test_load. 5. Added the Vx_rise/fall subparameters to indicate the end of a timing interval for timing correlation. 6. Added Tmeas_rise/fall to facilitate timing correlation. 7. Added subparameters Test_data_type and Test_load_type to facilitate upward compatibility with future versions of IBIS. 8. Removed Tline_present subparameter in favor of language explaining that the simulator should remove the Tline if Td is not present. 9. Moved Driver_model and Test_load under the scope of [Test Data]. 10. R_diff became R_diff_near and R_diff_far. 11. Removed timing-related keywords: Tmeas_rise, Tmeas_fall, Vx_rise, Vx_fall This function can be achieved with less complexity by including a Golden Waveform that represents the standard (timing) test load. 12. Added four differential waveform keywords. Changes between BIRD 70.3 and BIRD 70.4 (see lines beginning with |* ): 1. Added subparameter Driver_model_inv under [Test Data]. 2. Added subparameter Receiver_model_inv under [Test Load]. 3. Added language defining the legal values of Test_data_type. 4. Made Test_load_type a required subparameter. 5. Made Vterm subparameters required if the corresponding resistors are used. Changes between BIRD 70.4 and BIRD 70.5 (see lines beginning with |* ): 1. Specified table format should conform with [Rising/Falling Waveform]. 2. Specified measurement location as driver/receiver I/O pad. 3. Only one waveform required rather than one waveform pair. 4. Changed Test_Load to Test_load. 5. Specified non-inverting driver output when using single-ended waveform with differential driver. 6. Changed "SPICE" to "reference waveforms." ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: See BIRD 69.1. ****************************************************************************** From owner-ibis Fri Aug 10 10:32:28 2001 Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7AHWQ7n022347; Fri, 10 Aug 2001 10:32:27 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id RAA01633; Fri, 10 Aug 2001 17:32:25 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 10 Aug 2001 17:32:25 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 10:32:24 -0700 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A78E5@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis-users@eda.org'" , "'ibis@eda.org'" Subject: ibis@eda.org address experiencing problems, use ibis-users@eda.or g Date: Fri, 10 Aug 2001 10:32:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Greetings: With the recent changeover to Majordomo, users have been experiencing problems with posts to the general IBIS mailing list (ibis@eda.org) not propagating to everyone on the list. While the IBIS postmaster and the folks in charge of the eda.org server investigate this problem, I ask everyone to Cc: any postings you make to the IBIS reflector to the ibis-users@eda.org mail address also. The IBIS users reflector is unaffected and is propagating normally. To those on the IBIS users reflector I apologize for the extra mail traffic. Hopefully, we will have this problem resolved shortly. Regards, Stephen Peters Intel Corp. Chair EIA/IBIS Open Forum From owner-ibis Mon Aug 13 15:15:04 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7DMF27n003369; Mon, 13 Aug 2001 15:15:03 -0700 (PDT) Received: from svr-orw-exc-01.wv.mentorg.com ([147.34.96.78]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA24459; Mon, 13 Aug 2001 15:15:01 -0700 (PDT) Received: by svr-orw-exc-01.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 15:15:54 -0700 Received: from mentor.com (bob.wv.mentorg.com [147.34.70.103]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q51HDB1F; Mon, 13 Aug 2001 15:16:49 -0700 Message-ID: <3B78515E.4C06A898@mentor.com> From: "Ross, Bob" To: r58559@email.sps.mot.com, yokede@msil.sps.mot.com, ibis-users@eda.org Cc: stephen.peters@intel.com, ibis@eda.org Subject: IBIS - I/O Buffer Modeling Cookbook Date: Mon, 13 Aug 2001 15:14:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Hello Yoked: We are temporarily having reflector e-mail problems, so you message did not get sent to the general list. However, I am responding on the ibis-users reflector and copying Stephen Peters, who authored the Cookbook. My responses are in your text noted by "*" marks. These are brief responses without looking at the Cookbook document. I am trying to convey what was intended, not any editorial issues regarding how it is documented. Bob Ross Mentor Graphics --------------------- Subject: I/O buffer modeling cookbook From: Yoked Erlich (r58559) (r58559@email.sps.mot.com) Date: Sun Aug 12 2001 - 04:18:21 PDT Hi , I would like to ask some questions about the 'I/O buffer modeling cookbook' paper (revision 2.0X) , Which I've got from 'www.eig.org' web site. 1. Is there anywhere I can find revision 3.2 cookbook? * No, a Version 3.2 Cookbook has not been written. Cookbook 2 was intended to cover Version 3.2 features, but we never got that far. 2. I've an I/O buffer model which working in some chip pads as I/O , some pads as steady input and some pads as steady output. I would like to know if the buffer grouping is made by the buffer type or by the pad direction? If buffer type is the answer so one model with I/O type in enough for this buffer, If pad direction is the answer so three model is needed for this buffer , I/O model , Input model and Output model ( in this case Input and Output model tests will be exactly the same as I/O model ) . * If the buffer is truely an I/O, then it should be provided and documented as I/O. A user might have additional knowledge that certain I/O buffers are configured only as Input or Output buffers. It would be permissible to modify that instance of the model and just change the Model_type. That would help the EDA tool do only the simulations that are relevant for the design. 3-6 questions are about 'Extracting Data for the [Ramp] keyword' paragraph in the cookbook : 3. It is written that 'if the device does not have enough drive capability to make a significant output transition than a higher load may be used' , How much is significant output transition ? * I do not have any hard guideline. I prefer impedances in the order of magnitude of transmission line loads since that is a typical high-speed design application. That ususally captures a fast edge that would be seen with a PCB interconnect. * This makes no sense for certain weak buffers which would require multiple reflections to change from one state to the other for an open line. If the application is not high-speed, then it does not manner. I would guess that a higher value load might be OK for a driver source impedance > 300 ohms. Others might have different ideas. 4. it is written that ' For an open drain , measure the rise and fall time into the load resistor and voltage used by the manufacture when specifying propagation delays' , This sentence is not clear what is the test structure in open drain buffer case?. * This is ambiguous. I prefer low impedance (50 ohm) pullups to capture a faster edge. This may be in the order of magnitude of the load seen during the intial part of the transition when the device is connected through a PCB interconnect. 5. it is written that ' Falling edge ramp data is captured with the load resistor tied to VCC' , Is VCC mean the pmos Driver source voltage (pad voltage) or low voltage? * This means that one end of the load resistor is connected to Vcc, and the other end is connected to the output pad. 6. It is written that 'simulations are performed with C_comp included in the circuit' , This sentence is not clear. As I understood C_comp is the capacitance seen when looking from the pad back into the buffer , It is written that C_comp should be added to the simulation , but C_comp is not a capacitor it is capacitance measurement. * It is difficult to de-embed the die capacitance information from a Spice net list (since some of the contribution is due to paramaters within the transistor/diode models) or from a real physical measurements. * So the intent is to clarify that the die capacitance is already included in any waveform extraction. Since C_comp is a first order approximation of the die capacitance, its effects should be included in an EDA tool simulation. I have not looked at the specific wording, but I assume this is confusing. 7. In 'Ground Clamp' paragraph it is written that 'The data in table must cover the range of -Vcc to Vcc ' , Isn't it suppose to be -Vcc to 2*Vcc ? * This response also covers 9. * No, the minimum range is intended to be -vcc to vcc. The Power Clamp covers from vcc to 2vcc. When this minimum range was established, most Inputs were at negligle current at Vcc and the slope (current vs voltage) was also nearly 0. So concatenation of the tables produced the same effect as extrapolation. * It is allowed to extend the clamp ranges beyond the specified range. In some cases you should do so, especially if you are including the effect of an internal terminator. In such cases, the conditions above are not met, and I prefer -vcc to 2vcc for both clamp tables. Care must be taken so that currents are not double counted. However, for many situations, the "minimal" IBIS guidelines are sufficient. 8. In 'pulldn' paragraph it is written 'If the buffer is a 3-state device then first subtract the ground clamp current from the pulldown current then enter the result into the [pulldown] table' , first , it is written above the graph 'Pullup I/V curve after subtraction of ground clamp currents' Which is probably mistake. second , Should I replace the pulldn results in Ibis model file after the subtraction? * What is entered in the [Pulldown] table is the result after subtraction. 9. In 'Power Clamp' It is written that 'the data in the table must cover the range of vcc to vcc*2' , Isn't the range suppose to be -Vcc to 2*Vcc ? * See 7 above. -- With regards, Yoked. _____________________________________ E-mail: yokede@msil.sps.mot.com Tel: 972-9-9522482 Fax: 972-9-9522888 WIRELESS CIRCUIT - IO GROUP MOTOROLA SEMICONDUCTOR ISRAEL From owner-ibis Tue Aug 14 00:40:17 2001 Received: from web4502.mail.yahoo.com (web4502.mail.yahoo.com [216.115.105.63]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f7E7eF7n007162 for ; Tue, 14 Aug 2001 00:40:16 -0700 (PDT) Message-ID: <20010814074015.17669.qmail@web4502.mail.yahoo.com> Received: from [61.13.36.193] by web4502.mail.yahoo.com via HTTP; Tue, 14 Aug 2001 15:40:15 CST Date: Tue, 14 Aug 2001 15:40:15 +0800 (CST) From: "=?big5?q?Tomus,tog?=" Subject: RE: IBIS - I/O Buffer Modeling Cookbook To: ibis-users@eda.org MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Hi : The IBIS ver. 3.2 is not written in CookBook, but the method is found in Specification Section 9 4) point transit Time extraction , it may be some help for to find the wave form. Thank! ibis-users from yahoo Hello Yoked: We are temporarily having reflector e-mail problems, so you message did not get sent to the general list. However, I am responding on the ibis-users reflector and copying Stephen Peters, who authored the Cookbook. My responses are in your text noted by "*" marks. These are brief responses without looking at the Cookbook document. I am trying to convey what was intended, not any editorial issues regarding how it is documented. Bob Ross Mentor Graphics --------------------- Subject: I/O buffer modeling cookbook From: Yoked Erlich (r58559) (r58559@email.sps.mot.com) Date: Sun Aug 12 2001 - 04:18:21 PDT Hi , I would like to ask some questions about the 'I/O buffer modeling cookbook' paper (revision 2.0X) , Which I've got from 'www.eig.org' web site. 1. Is there anywhere I can find revision 3.2 cookbook? * No, a Version 3.2 Cookbook has not been written. Cookbook 2 was intended to cover Version 3.2 features, but we never got that far. 2. I've an I/O buffer model which working in some chip pads as I/O , some pads as steady input and some pads as steady output. I would like to know if the buffer grouping is made by the buffer type or by the pad direction? If buffer type is the answer so one model with I/O type in enough for this buffer, If pad direction is the answer so three model is needed for this buffer , I/O model , Input model and Output model ( in this case Input and Output model tests will be exactly the same as I/O model ) . * If the buffer is truely an I/O, then it should be provided and documented as I/O. A user might have additional knowledge that certain I/O buffers are configured only as Input or Output buffers. It would be permissible to modify that instance of the model and just change the Model_type. That would help the EDA tool do only the simulations that are relevant for the design. 3-6 questions are about 'Extracting Data for the [Ramp] keyword' paragraph in the cookbook : 3. It is written that 'if the device does not have enough drive capability to make a significant output transition than a higher load may be used' , How much is significant output transition ? * I do not have any hard guideline. I prefer impedances in the order of magnitude of transmission line loads since that is a typical high-speed design application. That ususally captures a fast edge that would be seen with a PCB interconnect. * This makes no sense for certain weak buffers which would require multiple reflections to change from one state to the other for an open line. If the application is not high-speed, then it does not manner. I would guess that a higher value load might be OK for a driver source impedance > 300 ohms. Others might have different ideas. 4. it is written that ' For an open drain , measure the rise and fall time into the load resistor and voltage used by the manufacture when specifying propagation delays' , This sentence is not clear what is the test structure in open drain buffer case?. * This is ambiguous. I prefer low impedance (50 ohm) pullups to capture a faster edge. This may be in the order of magnitude of the load seen during the intial part of the transition when the device is connected through a PCB interconnect. 5. it is written that ' Falling edge ramp data is captured with the load resistor tied to VCC' , Is VCC mean the pmos Driver source voltage (pad voltage) or low voltage? * This means that one end of the load resistor is connected to Vcc, and the other end is connected to the output pad. 6. It is written that 'simulations are performed with C_comp included in the circuit' , This sentence is not clear. As I understood C_comp is the capacitance seen when looking from the pad back into the buffer , It is written that C_comp should be added to the simulation , but C_comp is not a capacitor it is capacitance measurement. * It is difficult to de-embed the die capacitance information from a Spice net list (since some of the contribution is due to paramaters within the transistor/diode models) or from a real physical measurements. * So the intent is to clarify that the die capacitance is already included in any waveform extraction. Since C_comp is a first order approximation of the die capacitance, its effects should be included in an EDA tool simulation. I have not looked at the specific wording, but I assume this is confusing. 7. In 'Ground Clamp' paragraph it is written that 'The data in table must cover the range of -Vcc to Vcc ' , Isn't it suppose to be -Vcc to 2*Vcc ? * This response also covers 9. * No, the minimum range is intended to be -vcc to vcc. The Power Clamp covers from vcc to 2vcc. When this minimum range was established, most Inputs were at negligle current at Vcc and the slope (current vs voltage) was also nearly 0. So concatenation of the tables produced the same effect as extrapolation. * It is allowed to extend the clamp ranges beyond the specified range. In some cases you should do so, especially if you are including the effect of an internal terminator. In such cases, the conditions above are not met, and I prefer -vcc to 2vcc for both clamp tables. Care must be taken so that currents are not double counted. However, for many situations, the "minimal" IBIS guidelines are sufficient. 8. In 'pulldn' paragraph it is written 'If the buffer is a 3-state device then first subtract the ground clamp current from the pulldown current then enter the result into the [pulldown] table' , first , it is written above the graph 'Pullup I/V curve after subtraction of ground clamp currents' Which is probably mistake. second , Should I replace the pulldn results in Ibis model file after the subtraction? * What is entered in the [Pulldown] table is the result after subtraction. 9. In 'Power Clamp' It is written that 'the data in the table must cover the range of vcc to vcc*2' , Isn't the range suppose to be -Vcc to 2*Vcc ? * See 7 above. -- With regards, Yoked. _____________________________________ E-mail: yokede@msil.sps.mot.com Tel: 972-9-9522482 Fax: 972-9-9522888 WIRELESS CIRCUIT - IO GROUP MOTOROLA SEMICONDUCTOR ISRAEL _________________________________________________________ Do You Yahoo!? 登記免費的 @yahoo.com.tw 電子郵件 @ http://mail.yahoo.com.tw Get your free @yahoo.com.tw address at http://mail.yahoo.com.tw From owner-ibis Thu Aug 16 07:52:11 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7GEq67n016696 for ; Thu, 16 Aug 2001 07:52:11 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7GEpXT08344 for ; Thu, 16 Aug 2001 07:51:33 -0700 (PDT) Received: from shuq-u10.cisco.com (shuq-u10.cisco.com [10.34.20.148]) by mira-sjcd-4.cisco.com (Mirapoint) with SMTP id ABD89328; Thu, 16 Aug 2001 07:51:16 -0700 (PDT) Message-Id: <200108161451.ABD89328@mira-sjcd-4.cisco.com> Date: Thu, 16 Aug 2001 07:51:16 -0700 (PDT) From: Syed Huq Reply-To: Syed Huq Subject: FREE IBIS utility from Zuken To: ibis-users@eda.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LO1aW+0Yf24EE+yw4Pzp7g== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc IBIS fans: Zuken is providing a FREE utility that can give you additional information on an IBIS model along with parsing the model. "ibisinf" does more than simple checking (that it will do only without any argument) - with either -c (for component info) or -m for model info it will pass out all information of all the components (or the models) which are included in that IBIS file. Runs on Solaris, HP, Linux and Windows. Follow the link and look under the Golden Parser: http://www.eigroup.org/IBIS/tools.htm Regards, Syed webmaster From owner-ibis Tue Aug 21 07:41:42 2001 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7LEfe7n007517; Tue, 21 Aug 2001 07:41:41 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA15913; Tue, 21 Aug 2001 07:41:34 -0700 (MST)] Received: [from msgtel1.sps.mot.com (msgtel1.sps.mot.com [216.2.95.1]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA26099; Tue, 21 Aug 2001 07:41:32 -0700 (MST)] Received: from motorola.com ([223.143.95.68]) by msgtel1.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA2EFD; Tue, 21 Aug 2001 17:45:03 +0300 Sender: yokede@pobox2.mot.com Message-ID: <3B8272AF.73AAA8C1@motorola.com> Date: Tue, 21 Aug 2001 17:39:43 +0300 From: yoked erlich X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Ross, Bob" , ibis-users@eda.org, stephen.peters@intel.com, ibis@eda.org, "Sergey Sofer (r53493)" CC: Lior Aviv Subject: Re: IBIS - I/O Buffer Modeling Cookbook References: <3B78515E.4C06A898@mentor.com> Content-Type: multipart/mixed; boundary="------------ED3B6BFAD69F0FFCEA61E194" This is a multi-part message in MIME format. --------------ED3B6BFAD69F0FFCEA61E194 Content-Type: multipart/alternative; boundary="------------4A80BE336704D4CEAA171CF1" --------------4A80BE336704D4CEAA171CF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , There are another few questions about ibischk3 results: 1. I've got the next warning: WARNING - [Model] iovb has no description of the buffer's high state DC drive characteristics (no [Pullup] table). This warning can be silenced by changing the Model_type or by adding a [Pullup] table. This cell ('iovb') is 'Open_drain' type which according to Ibis maker cook book do not suppose to have [Pullup] table , only the [pulldown],[gnd_clamp] and [power_clamp] tables , What do you think might be the reason of this error ?. 2. I've got the next warning: WARNING (line 427) - Pulldown Typical data is non-monotonic WARNING (line 427) - Pulldown Maximum data is non-monotonic WARNING (line 428) - Pulldown Minimum data is non-monotonic according to pulldn subtraction gnd_clamp cookbook and standard instructions , it is impossible to get monotonic data. It is even mentioned in the standard that the [pulldn] or [pullup] tables might be non-monotonic. Is it all right to ignore this warning ? With regards Yoked. "Ross, Bob" wrote: > Hello Yoked: > > We are temporarily having reflector e-mail problems, > so you message did not get sent to the general list. > > However, I am responding on the ibis-users reflector > and copying Stephen Peters, who authored the Cookbook. > My responses are in your text noted by "*" marks. These > are brief responses without looking at the Cookbook > document. I am trying to convey what was intended, > not any editorial issues regarding how it is documented. > > Bob Ross > Mentor Graphics > > --------------------- > > Subject: I/O buffer modeling cookbook > From: Yoked Erlich (r58559) (r58559@email.sps.mot.com) > Date: Sun Aug 12 2001 - 04:18:21 PDT > > Hi , > > I would like to ask some questions about the 'I/O buffer modeling > cookbook' > paper (revision 2.0X) , Which I've got from 'www.eig.org' web site. > > 1. Is there anywhere I can find revision 3.2 cookbook? > > * No, a Version 3.2 Cookbook has not been written. Cookbook 2 was > intended to cover Version 3.2 features, but we never got that far. > > 2. I've an I/O buffer model which working in some chip pads as I/O , > some pads as steady input and some pads as steady output. > I would like to know if the buffer grouping is made by the buffer > type or by the pad direction? > If buffer type is the answer so one model with I/O type in enough > for this buffer, > If pad direction is the answer so three model is needed for this > buffer , I/O model , Input model and Output model > ( in this case Input and Output model tests will be exactly the same > as I/O model ) . > > * If the buffer is truely an I/O, then it should be provided and > documented as I/O. A user might have additional knowledge that > certain I/O buffers are configured only as Input or Output buffers. > It would be permissible to modify that instance of the model and > just change the Model_type. That would help the EDA tool do > only the simulations that are relevant for the design. > > 3-6 questions are about 'Extracting Data for the [Ramp] keyword' > paragraph in the cookbook : > 3. It is written that 'if the device does not have enough > drive capability to make a significant output transition than a > higher load may be used' , > How much is significant output transition ? > > * I do not have any hard guideline. I prefer impedances in the > order of magnitude of transmission line loads since that is a > typical high-speed design application. That ususally captures > a fast edge that would be seen with a PCB interconnect. > > * This makes no sense for certain weak buffers which would > require multiple reflections to change from one state to the > other for an open line. If the application is not high-speed, > then it does not manner. I would guess that a higher value > load might be OK for a driver source impedance > 300 ohms. > Others might have different ideas. > > 4. it is written that ' For an open drain , measure the rise and fall > time into the load resistor and voltage used > by the manufacture when specifying propagation delays' , This > sentence is not clear > what is the test structure in open drain buffer case?. > > * This is ambiguous. I prefer low impedance (50 ohm) pullups to > capture a faster edge. This may be in the order of magnitude of > the load seen during the intial part of the transition when the > device is connected through a PCB interconnect. > > 5. it is written that ' Falling edge ramp data is captured with the load > resistor tied to VCC' > , Is VCC mean the pmos Driver source voltage (pad voltage) or low > voltage? > > * This means that one end of the load resistor is connected to > Vcc, and the other end is connected to the output pad. > > 6. It is written that 'simulations are performed with C_comp included in > the circuit' , This sentence is not clear. > As I understood C_comp is the capacitance seen when looking from the > pad back into the buffer , > It is written that C_comp should be added to the simulation , but > C_comp is not a capacitor it is capacitance measurement. > > * It is difficult to de-embed the die capacitance information from a > Spice net list (since some of the contribution is due to paramaters > within the transistor/diode models) or from a real physical measurements. > > * So the intent is to clarify that the die capacitance is already > included in any waveform extraction. Since C_comp is a first order > approximation of the die capacitance, its effects should be included > in an EDA tool simulation. I have not looked at the specific > wording, but I assume this is confusing. > > 7. In 'Ground Clamp' paragraph it is written that 'The data in table > must cover the range of -Vcc to Vcc ' , > Isn't it suppose to be -Vcc to 2*Vcc ? > > * This response also covers 9. > > * No, the minimum range is intended to be -vcc to vcc. The Power > Clamp covers from vcc to 2vcc. When this minimum range was > established, most Inputs were at negligle current at Vcc and the > slope (current vs voltage) was also nearly 0. So concatenation > of the tables produced the same effect as extrapolation. > > * It is allowed to extend the clamp ranges beyond the specified > range. In some cases you should do so, especially if you are > including the effect of an internal terminator. In such cases, > the conditions above are not met, and I prefer -vcc to 2vcc for > both clamp tables. Care must be taken so that > currents are not double counted. However, for many situations, > the "minimal" IBIS guidelines are sufficient. > > 8. In 'pulldn' paragraph it is written 'If the buffer is a 3-state > device then first subtract the ground clamp current > from the pulldown current then enter the result into the [pulldown] > table' , > first , it is written above the graph 'Pullup I/V curve after > subtraction of ground clamp currents' Which is probably mistake. > second , Should I replace the pulldn results in Ibis model file > after the subtraction? > > * What is entered in the [Pulldown] table is the result after > subtraction. > > 9. In 'Power Clamp' It is written that 'the data in the table must cover > the range of vcc to vcc*2' , > Isn't the range suppose to be -Vcc to 2*Vcc ? > > * See 7 above. > > -- > With regards, > Yoked. > _____________________________________ > E-mail: yokede@msil.sps.mot.com > Tel: 972-9-9522482 Fax: 972-9-9522888 > WIRELESS CIRCUIT - IO GROUP > MOTOROLA SEMICONDUCTOR ISRAEL -- With regards, Yoked. _____________________________________ E-mail: yokede@motorola.com Tel: 972-9-9522482 Fax: 972-9-9522888 WIRELESS CIRCUIT - IO GROUP MOTOROLA SEMICONDUCTOR ISRAEL --------------4A80BE336704D4CEAA171CF1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ,

There are another few questions about ibischk3 results:

1. I've got the next warning:
 WARNING - [Model] iovb has no description of the buffer's high state
                    DC drive characteristics (no [Pullup] table).  This warning
                    can be silenced by changing the Model_type or by adding a
                    [Pullup] table.
This cell ('iovb') is 'Open_drain' type which according to Ibis maker cook book do not
suppose to have [Pullup] table , only the [pulldown],[gnd_clamp] and [power_clamp] tables ,
What do you think might be the reason of this error ?.

2. I've got the next warning:
WARNING (line  427) - Pulldown Typical data is non-monotonic
WARNING (line  427) - Pulldown Maximum data is non-monotonic
WARNING (line  428) - Pulldown Minimum data is non-monotonic
according to pulldn subtraction gnd_clamp cookbook and standard instructions ,
it is impossible to get monotonic data.
It is even mentioned in the standard that the [pulldn] or  [pullup] tables might be non-monotonic.
Is it all right to ignore this warning ?

With regards

Yoked.
"Ross, Bob" wrote:

Hello Yoked:

We are temporarily having reflector e-mail problems,
so you message did not get sent to the general list.

However, I am responding on the ibis-users reflector
and copying Stephen Peters, who authored the Cookbook.
My responses are in your text noted by "*" marks.  These
are brief responses without looking at the Cookbook
document.  I am trying to convey what was intended,
not any editorial issues regarding how it is documented.

Bob Ross
Mentor Graphics

---------------------

Subject: I/O buffer modeling cookbook
From: Yoked Erlich (r58559) (r58559@email.sps.mot.com)
Date: Sun Aug 12 2001 - 04:18:21 PDT

Hi ,

I would like to ask some questions about the 'I/O buffer modeling
cookbook'
paper (revision 2.0X) , Which I've got from 'www.eig.org' web site.

1. Is there anywhere I can find revision 3.2 cookbook?

* No, a Version 3.2 Cookbook has not been written.  Cookbook 2 was
intended to cover Version 3.2 features, but we never got that far.

2. I've an I/O buffer model which working in some chip pads as I/O ,
some pads as steady input and some pads as steady output.
    I would like to know if the buffer grouping is made by the buffer
type or by the pad direction?
    If buffer type is the answer so one model with I/O type in enough
for this buffer,
    If pad direction is the answer so three model is needed for this
buffer , I/O model , Input model and Output model
    ( in this case Input and Output model tests will be exactly the same
as I/O model ) .

* If the buffer is truely an I/O, then it should be provided and
documented as I/O.  A user might have additional knowledge that
certain I/O buffers are configured only as Input or Output buffers.
It would be permissible to modify that instance of the model and
just change the Model_type.  That would help the EDA tool do
only the simulations that are relevant for the design.

3-6 questions are about 'Extracting Data for the [Ramp] keyword'
paragraph in the cookbook :
3. It is written that 'if the device does not have enough
     drive capability to make a significant output transition than a
higher load may be used' ,
     How much is significant output transition ?

* I do not have any hard guideline.  I prefer impedances in the
order of magnitude of transmission line loads since that is a
typical high-speed design application.  That ususally captures
a fast edge that would be seen with a PCB interconnect.

* This makes no sense for certain weak buffers which would
require multiple reflections to change from one state to the
other for an open line.  If the application is not high-speed,
then it does not manner.   I would guess that a higher value
load might be OK for a driver source impedance > 300 ohms.
Others might have different ideas.

4. it is written that ' For an open drain , measure the rise and fall
time into the load resistor and voltage used
    by the manufacture when specifying propagation delays' , This
sentence is not clear
    what is the test structure in open drain buffer case?.

* This is ambiguous.  I prefer low impedance (50 ohm) pullups to
capture a faster edge.  This may be in the order of magnitude of
the load seen during the intial part of the transition when the
device is connected through a PCB interconnect.

5. it is written that ' Falling edge ramp data is captured with the load
resistor tied to VCC'
    , Is VCC mean the pmos Driver source voltage (pad voltage) or low
voltage?

* This means that one end of the load resistor is connected to
Vcc, and the other end is connected to the output pad.

6. It is written that 'simulations are performed with C_comp included in
the circuit' , This sentence is not clear.
    As I understood C_comp is the capacitance seen when looking from the
pad back into the buffer ,
    It is written that C_comp should be added to the simulation , but
C_comp is not a capacitor it is capacitance measurement.

* It is difficult to de-embed the die capacitance information from a
Spice net list (since some of the contribution is due to paramaters
within the transistor/diode models) or from a real physical measurements.

* So the intent is to clarify that the die capacitance is already
included in any waveform extraction.  Since C_comp is a first order
approximation of the die capacitance, its effects should be included
in an EDA tool simulation.  I have not looked at the specific
wording, but I assume this is confusing.

7. In 'Ground Clamp' paragraph it is written that 'The data in table
must cover the range of -Vcc to Vcc ' ,
    Isn't it suppose to be -Vcc to 2*Vcc ?

* This response also covers 9.

* No, the minimum range is intended to be -vcc to vcc.  The Power
Clamp covers from vcc to 2vcc.  When this minimum range was
established, most Inputs were at negligle current at Vcc and the
slope (current vs voltage) was also nearly 0.  So concatenation
of the tables produced the same effect as extrapolation.

* It is allowed to extend the clamp ranges beyond the specified
range.  In some cases you should do so, especially if you are
including the effect of an internal terminator.  In such cases,
the conditions above are not met, and I prefer -vcc to 2vcc for
both clamp tables.  Care must be taken so that
currents are not double counted.  However, for many situations,
the "minimal" IBIS guidelines are sufficient.

8. In 'pulldn' paragraph it is written 'If the buffer is a 3-state
device then first subtract the ground clamp current
    from the pulldown current then enter the result into the [pulldown]
table' ,
    first , it is written above the graph 'Pullup I/V curve after
subtraction of ground clamp currents' Which is probably mistake.
    second , Should I replace the pulldn results in Ibis model file
after the subtraction?

* What is entered in the [Pulldown] table is the result after
subtraction.

9. In 'Power Clamp' It is written that 'the data in the table must cover
the range of vcc to vcc*2' ,
    Isn't the range suppose to be -Vcc to 2*Vcc ?

* See 7 above.

--
With regards,
Yoked.
_____________________________________
E-mail:       yokede@msil.sps.mot.com
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP
MOTOROLA     SEMICONDUCTOR     ISRAEL

-- 

With regards,

Yoked.

_____________________________________
E-mail:           yokede@motorola.com
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP                 
MOTOROLA     SEMICONDUCTOR     ISRAEL
  --------------4A80BE336704D4CEAA171CF1-- --------------ED3B6BFAD69F0FFCEA61E194 Content-Type: text/x-vcard; charset=us-ascii; name="yokede.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for yoked erlich Content-Disposition: attachment; filename="yokede.vcf" begin:vcard n:Erlich;Yoked tel;cell:051-957314 tel;fax:09-9522888 tel;home:09-8985166 tel;work:09-9522482 x-mozilla-html:FALSE org:Motorola Semiconductor L.T.D;IO - WIRELESS adr:;;Hadolev 20a;Zuran;;;ISRAEL version:2.1 email;internet:yokede@msil.sps.mot.com x-mozilla-cpt:;-32248 fn:Yoked Erlich end:vcard --------------ED3B6BFAD69F0FFCEA61E194-- From owner-ibis Tue Aug 21 09:09:40 2001 Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f7LG9b7n007751 for ; Tue, 21 Aug 2001 09:09:39 -0700 (PDT) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for server.eda.ORG [171.64.101.101]) with SMTP; 21 Aug 2001 16:09:29 UT Received: from hlgw.hyperlynx.com (hlgw.hyperlynx.com [192.168.149.1]) by mail.hyperlynx.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id JAA24977; Tue, 21 Aug 2001 09:09:25 -0700 Message-ID: <000a01c12a5b$c92d6330$90cab58b@redmond.innoveda.com> From: "Matthew Flora" To: "yoked erlich" , , "Sergey Sofer \(r53493\)" Cc: "Lior Aviv" Received: from no.name.available by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 21 Aug 2001 16:09:27 UT References: <3B78515E.4C06A898@mentor.com> <3B8272AF.73AAA8C1@motorola.com> Subject: Re: IBIS - I/O Buffer Modeling Cookbook Date: Tue, 21 Aug 2001 09:10:21 -0700 Organization: Innoveda MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Dear Yoked Erlich, Regarding your first question: Which version of ibischk3 are you using? The latest version available is 3.2.7. There was a bug in earlier versions that generated incorrect warnings for open drain buffers. Best regards, Matthew Flora ----- Original Message ----- From: "yoked erlich" To: "Ross, Bob" ; ; ; ; "Sergey Sofer (r53493)" Cc: "Lior Aviv" Sent: Tuesday, August 21, 2001 7:39 AM Subject: Re: IBIS - I/O Buffer Modeling Cookbook > Hi , > > There are another few questions about ibischk3 results: > > 1. I've got the next warning: > WARNING - [Model] iovb has no description of the buffer's high state > DC drive characteristics (no [Pullup] table). This > warning > can be silenced by changing the Model_type or by adding > a > [Pullup] table. > This cell ('iovb') is 'Open_drain' type which according to Ibis maker cook > book do not > suppose to have [Pullup] table , only the [pulldown],[gnd_clamp] and > [power_clamp] tables , > What do you think might be the reason of this error ?. > > 2. I've got the next warning: > WARNING (line 427) - Pulldown Typical data is non-monotonic > WARNING (line 427) - Pulldown Maximum data is non-monotonic > WARNING (line 428) - Pulldown Minimum data is non-monotonic > according to pulldn subtraction gnd_clamp cookbook and standard instructions > , > it is impossible to get monotonic data. > It is even mentioned in the standard that the [pulldn] or [pullup] tables > might be non-monotonic. > Is it all right to ignore this warning ? > > With regards > > Yoked. > "Ross, Bob" wrote: > > > Hello Yoked: > > > > We are temporarily having reflector e-mail problems, > > so you message did not get sent to the general list. > > > > However, I am responding on the ibis-users reflector > > and copying Stephen Peters, who authored the Cookbook. > > My responses are in your text noted by "*" marks. These > > are brief responses without looking at the Cookbook > > document. I am trying to convey what was intended, > > not any editorial issues regarding how it is documented. > > > > Bob Ross > > Mentor Graphics > > > > --------------------- > > > > Subject: I/O buffer modeling cookbook > > From: Yoked Erlich (r58559) (r58559@email.sps.mot.com) > > Date: Sun Aug 12 2001 - 04:18:21 PDT > > > > Hi , > > > > I would like to ask some questions about the 'I/O buffer modeling > > cookbook' > > paper (revision 2.0X) , Which I've got from 'www.eig.org' web site. > > > > 1. Is there anywhere I can find revision 3.2 cookbook? > > > > * No, a Version 3.2 Cookbook has not been written. Cookbook 2 was > > intended to cover Version 3.2 features, but we never got that far. > > > > 2. I've an I/O buffer model which working in some chip pads as I/O , > > some pads as steady input and some pads as steady output. > > I would like to know if the buffer grouping is made by the buffer > > type or by the pad direction? > > If buffer type is the answer so one model with I/O type in enough > > for this buffer, > > If pad direction is the answer so three model is needed for this > > buffer , I/O model , Input model and Output model > > ( in this case Input and Output model tests will be exactly the same > > as I/O model ) . > > > > * If the buffer is truely an I/O, then it should be provided and > > documented as I/O. A user might have additional knowledge that > > certain I/O buffers are configured only as Input or Output buffers. > > It would be permissible to modify that instance of the model and > > just change the Model_type. That would help the EDA tool do > > only the simulations that are relevant for the design. > > > > 3-6 questions are about 'Extracting Data for the [Ramp] keyword' > > paragraph in the cookbook : > > 3. It is written that 'if the device does not have enough > > drive capability to make a significant output transition than a > > higher load may be used' , > > How much is significant output transition ? > > > > * I do not have any hard guideline. I prefer impedances in the > > order of magnitude of transmission line loads since that is a > > typical high-speed design application. That ususally captures > > a fast edge that would be seen with a PCB interconnect. > > > > * This makes no sense for certain weak buffers which would > > require multiple reflections to change from one state to the > > other for an open line. If the application is not high-speed, > > then it does not manner. I would guess that a higher value > > load might be OK for a driver source impedance > 300 ohms. > > Others might have different ideas. > > > > 4. it is written that ' For an open drain , measure the rise and fall > > time into the load resistor and voltage used > > by the manufacture when specifying propagation delays' , This > > sentence is not clear > > what is the test structure in open drain buffer case?. > > > > * This is ambiguous. I prefer low impedance (50 ohm) pullups to > > capture a faster edge. This may be in the order of magnitude of > > the load seen during the intial part of the transition when the > > device is connected through a PCB interconnect. > > > > 5. it is written that ' Falling edge ramp data is captured with the load > > resistor tied to VCC' > > , Is VCC mean the pmos Driver source voltage (pad voltage) or low > > voltage? > > > > * This means that one end of the load resistor is connected to > > Vcc, and the other end is connected to the output pad. > > > > 6. It is written that 'simulations are performed with C_comp included in > > the circuit' , This sentence is not clear. > > As I understood C_comp is the capacitance seen when looking from the > > pad back into the buffer , > > It is written that C_comp should be added to the simulation , but > > C_comp is not a capacitor it is capacitance measurement. > > > > * It is difficult to de-embed the die capacitance information from a > > Spice net list (since some of the contribution is due to paramaters > > within the transistor/diode models) or from a real physical measurements. > > > > * So the intent is to clarify that the die capacitance is already > > included in any waveform extraction. Since C_comp is a first order > > approximation of the die capacitance, its effects should be included > > in an EDA tool simulation. I have not looked at the specific > > wording, but I assume this is confusing. > > > > 7. In 'Ground Clamp' paragraph it is written that 'The data in table > > must cover the range of -Vcc to Vcc ' , > > Isn't it suppose to be -Vcc to 2*Vcc ? > > > > * This response also covers 9. > > > > * No, the minimum range is intended to be -vcc to vcc. The Power > > Clamp covers from vcc to 2vcc. When this minimum range was > > established, most Inputs were at negligle current at Vcc and the > > slope (current vs voltage) was also nearly 0. So concatenation > > of the tables produced the same effect as extrapolation. > > > > * It is allowed to extend the clamp ranges beyond the specified > > range. In some cases you should do so, especially if you are > > including the effect of an internal terminator. In such cases, > > the conditions above are not met, and I prefer -vcc to 2vcc for > > both clamp tables. Care must be taken so that > > currents are not double counted. However, for many situations, > > the "minimal" IBIS guidelines are sufficient. > > > > 8. In 'pulldn' paragraph it is written 'If the buffer is a 3-state > > device then first subtract the ground clamp current > > from the pulldown current then enter the result into the [pulldown] > > table' , > > first , it is written above the graph 'Pullup I/V curve after > > subtraction of ground clamp currents' Which is probably mistake. > > second , Should I replace the pulldn results in Ibis model file > > after the subtraction? > > > > * What is entered in the [Pulldown] table is the result after > > subtraction. > > > > 9. In 'Power Clamp' It is written that 'the data in the table must cover > > the range of vcc to vcc*2' , > > Isn't the range suppose to be -Vcc to 2*Vcc ? > > > > * See 7 above. > > > > -- > > With regards, > > Yoked. > > _____________________________________ > > E-mail: yokede@msil.sps.mot.com > > Tel: 972-9-9522482 Fax: 972-9-9522888 > > WIRELESS CIRCUIT - IO GROUP > > MOTOROLA SEMICONDUCTOR ISRAEL > > -- > > With regards, > > Yoked. > > _____________________________________ > E-mail: yokede@motorola.com > Tel: 972-9-9522482 Fax: 972-9-9522888 > WIRELESS CIRCUIT - IO GROUP > MOTOROLA SEMICONDUCTOR ISRAEL > > > From owner-ibis Tue Aug 21 11:40:03 2001 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7LIdx7n008002; Tue, 21 Aug 2001 11:40:00 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA08249; Tue, 21 Aug 2001 18:39:24 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 21 Aug 2001 18:39:15 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 11:39:13 -0700 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A791F@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'yoked erlich'" , "Ross, Bob" , ibis-users@eda.org, "Peters, Stephen" , ibis@eda.org, "Sergey Sofer (r53493)" Cc: Lior Aviv Subject: RE: IBIS - I/O Buffer Modeling Cookbook Date: Tue, 21 Aug 2001 11:39:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12A70.90BFD7C0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12A70.90BFD7C0 Content-Type: text/plain; charset="iso-8859-1" Hi Yoked: Regarding the non-monotonic warnings, I would still check the line number on the pulldown curves and verify what is causing the non-monotonic warning. It should be the area where ground clamp current was subtracted from the total pulldown current and not somewhere else. By the way, when creating a model for a non-tristatable output (i.e. one in which either the pullup or pulldown curves are always on) one does not have to subtract ground and power clamp current from the curves. In this case the warning should not occur. Regards, Stephen Peters Intel Corp. -----Original Message----- From: yoked erlich [mailto:yokede@motorola.com] Sent: Tuesday, August 21, 2001 7:40 AM To: Ross, Bob; ibis-users@eda.org; stephen.peters@intel.com; ibis@eda.org; Sergey Sofer (r53493) Cc: Lior Aviv Subject: Re: IBIS - I/O Buffer Modeling Cookbook Hi , There are another few questions about ibischk3 results: 1. I've got the next warning: WARNING - [Model] iovb has no description of the buffer's high state DC drive characteristics (no [Pullup] table). This warning can be silenced by changing the Model_type or by adding a [Pullup] table. This cell ('iovb') is 'Open_drain' type which according to Ibis maker cook book do not suppose to have [Pullup] table , only the [pulldown],[gnd_clamp] and [power_clamp] tables , What do you think might be the reason of this error ?. 2. I've got the next warning: WARNING (line 427) - Pulldown Typical data is non-monotonic WARNING (line 427) - Pulldown Maximum data is non-monotonic WARNING (line 428) - Pulldown Minimum data is non-monotonic according to pulldn subtraction gnd_clamp cookbook and standard instructions , it is impossible to get monotonic data. It is even mentioned in the standard that the [pulldn] or [pullup] tables might be non-monotonic. Is it all right to ignore this warning ? With regards Yoked. "Ross, Bob" wrote: Hello Yoked: We are temporarily having reflector e-mail problems, so you message did not get sent to the general list. However, I am responding on the ibis-users reflector and copying Stephen Peters, who authored the Cookbook. My responses are in your text noted by "*" marks. These are brief responses without looking at the Cookbook document. I am trying to convey what was intended, not any editorial issues regarding how it is documented. Bob Ross Mentor Graphics --------------------- Subject: I/O buffer modeling cookbook From: Yoked Erlich (r58559) (r58559@email.sps.mot.com) Date: Sun Aug 12 2001 - 04:18:21 PDT Hi , I would like to ask some questions about the 'I/O buffer modeling cookbook' paper (revision 2.0X) , Which I've got from 'www.eig.org' web site. 1. Is there anywhere I can find revision 3.2 cookbook? * No, a Version 3.2 Cookbook has not been written. Cookbook 2 was intended to cover Version 3.2 features, but we never got that far. 2. I've an I/O buffer model which working in some chip pads as I/O , some pads as steady input and some pads as steady output. I would like to know if the buffer grouping is made by the buffer type or by the pad direction? If buffer type is the answer so one model with I/O type in enough for this buffer, If pad direction is the answer so three model is needed for this buffer , I/O model , Input model and Output model ( in this case Input and Output model tests will be exactly the same as I/O model ) . * If the buffer is truely an I/O, then it should be provided and documented as I/O. A user might have additional knowledge that certain I/O buffers are configured only as Input or Output buffers. It would be permissible to modify that instance of the model and just change the Model_type. That would help the EDA tool do only the simulations that are relevant for the design. 3-6 questions are about 'Extracting Data for the [Ramp] keyword' paragraph in the cookbook : 3. It is written that 'if the device does not have enough drive capability to make a significant output transition than a higher load may be used' , How much is significant output transition ? * I do not have any hard guideline. I prefer impedances in the order of magnitude of transmission line loads since that is a typical high-speed design application. That ususally captures a fast edge that would be seen with a PCB interconnect. * This makes no sense for certain weak buffers which would require multiple reflections to change from one state to the other for an open line. If the application is not high-speed, then it does not manner. I would guess that a higher value load might be OK for a driver source impedance > 300 ohms. Others might have different ideas. 4. it is written that ' For an open drain , measure the rise and fall time into the load resistor and voltage used by the manufacture when specifying propagation delays' , This sentence is not clear what is the test structure in open drain buffer case?. * This is ambiguous. I prefer low impedance (50 ohm) pullups to capture a faster edge. This may be in the order of magnitude of the load seen during the intial part of the transition when the device is connected through a PCB interconnect. 5. it is written that ' Falling edge ramp data is captured with the load resistor tied to VCC' , Is VCC mean the pmos Driver source voltage (pad voltage) or low voltage? * This means that one end of the load resistor is connected to Vcc, and the other end is connected to the output pad. 6. It is written that 'simulations are performed with C_comp included in the circuit' , This sentence is not clear. As I understood C_comp is the capacitance seen when looking from the pad back into the buffer , It is written that C_comp should be added to the simulation , but C_comp is not a capacitor it is capacitance measurement. * It is difficult to de-embed the die capacitance information from a Spice net list (since some of the contribution is due to paramaters within the transistor/diode models) or from a real physical measurements. * So the intent is to clarify that the die capacitance is already included in any waveform extraction. Since C_comp is a first order approximation of the die capacitance, its effects should be included in an EDA tool simulation. I have not looked at the specific wording, but I assume this is confusing. 7. In 'Ground Clamp' paragraph it is written that 'The data in table must cover the range of -Vcc to Vcc ' , Isn't it suppose to be -Vcc to 2*Vcc ? * This response also covers 9. * No, the minimum range is intended to be -vcc to vcc. The Power Clamp covers from vcc to 2vcc. When this minimum range was established, most Inputs were at negligle current at Vcc and the slope (current vs voltage) was also nearly 0. So concatenation of the tables produced the same effect as extrapolation. * It is allowed to extend the clamp ranges beyond the specified range. In some cases you should do so, especially if you are including the effect of an internal terminator. In such cases, the conditions above are not met, and I prefer -vcc to 2vcc for both clamp tables. Care must be taken so that currents are not double counted. However, for many situations, the "minimal" IBIS guidelines are sufficient. 8. In 'pulldn' paragraph it is written 'If the buffer is a 3-state device then first subtract the ground clamp current from the pulldown current then enter the result into the [pulldown] table' , first , it is written above the graph 'Pullup I/V curve after subtraction of ground clamp currents' Which is probably mistake. second , Should I replace the pulldn results in Ibis model file after the subtraction? * What is entered in the [Pulldown] table is the result after subtraction. 9. In 'Power Clamp' It is written that 'the data in the table must cover the range of vcc to vcc*2' , Isn't the range suppose to be -Vcc to 2*Vcc ? * See 7 above. -- With regards, Yoked. _____________________________________ E-mail: yokede@msil.sps.mot.com Tel: 972-9-9522482 Fax: 972-9-9522888 WIRELESS CIRCUIT - IO GROUP MOTOROLA SEMICONDUCTOR ISRAEL -- With regards, Yoked. _____________________________________ E-mail: yokede@motorola.com Tel: 972-9-9522482 Fax: 972-9-9522888 WIRELESS CIRCUIT - IO GROUP MOTOROLA SEMICONDUCTOR ISRAEL ------_=_NextPart_001_01C12A70.90BFD7C0 Content-Type: text/html; charset="iso-8859-1"
Hi Yoked:
 
  Regarding the non-monotonic warnings, I would still check the line number on the pulldown curves and verify what is causing the non-monotonic warning.  It should be the area where ground clamp current was subtracted from the total pulldown current and not somewhere else.
  By the way, when creating a model for a non-tristatable output (i.e. one in which either the pullup or pulldown curves are always on) one does not have to subtract ground and power clamp current from the curves.  In this case the warning should not occur.
 
  Regards,
  Stephen Peters
  Intel Corp.
 
-----Original Message-----
From: yoked erlich [mailto:yokede@motorola.com]
Sent: Tuesday, August 21, 2001 7:40 AM
To: Ross, Bob; ibis-users@eda.org; stephen.peters@intel.com; ibis@eda.org; Sergey Sofer (r53493)
Cc: Lior Aviv
Subject: Re: IBIS - I/O Buffer Modeling Cookbook

Hi ,

There are another few questions about ibischk3 results:

1. I've got the next warning:
 WARNING - [Model] iovb has no description of the buffer's high state
                    DC drive characteristics (no [Pullup] table).  This warning
                    can be silenced by changing the Model_type or by adding a
                    [Pullup] table.
This cell ('iovb') is 'Open_drain' type which according to Ibis maker cook book do not
suppose to have [Pullup] table , only the [pulldown],[gnd_clamp] and [power_clamp] tables ,
What do you think might be the reason of this error ?.

2. I've got the next warning:
WARNING (line  427) - Pulldown Typical data is non-monotonic
WARNING (line  427) - Pulldown Maximum data is non-monotonic
WARNING (line  428) - Pulldown Minimum data is non-monotonic
according to pulldn subtraction gnd_clamp cookbook and standard instructions ,
it is impossible to get monotonic data.
It is even mentioned in the standard that the [pulldn] or  [pullup] tables might be non-monotonic.
Is it all right to ignore this warning ?

With regards

Yoked.
"Ross, Bob" wrote:

Hello Yoked:

We are temporarily having reflector e-mail problems,
so you message did not get sent to the general list.

However, I am responding on the ibis-users reflector
and copying Stephen Peters, who authored the Cookbook.
My responses are in your text noted by "*" marks.  These
are brief responses without looking at the Cookbook
document.  I am trying to convey what was intended,
not any editorial issues regarding how it is documented.

Bob Ross
Mentor Graphics

---------------------

Subject: I/O buffer modeling cookbook
From: Yoked Erlich (r58559) (r58559@email.sps.mot.com)
Date: Sun Aug 12 2001 - 04:18:21 PDT

Hi ,

I would like to ask some questions about the 'I/O buffer modeling
cookbook'
paper (revision 2.0X) , Which I've got from 'www.eig.org' web site.

1. Is there anywhere I can find revision 3.2 cookbook?

* No, a Version 3.2 Cookbook has not been written.  Cookbook 2 was
intended to cover Version 3.2 features, but we never got that far.

2. I've an I/O buffer model which working in some chip pads as I/O ,
some pads as steady input and some pads as steady output.
    I would like to know if the buffer grouping is made by the buffer
type or by the pad direction?
    If buffer type is the answer so one model with I/O type in enough
for this buffer,
    If pad direction is the answer so three model is needed for this
buffer , I/O model , Input model and Output model
    ( in this case Input and Output model tests will be exactly the same
as I/O model ) .

* If the buffer is truely an I/O, then it should be provided and
documented as I/O.  A user might have additional knowledge that
certain I/O buffers are configured only as Input or Output buffers.
It would be permissible to modify that instance of the model and
just change the Model_type.  That would help the EDA tool do
only the simulations that are relevant for the design.

3-6 questions are about 'Extracting Data for the [Ramp] keyword'
paragraph in the cookbook :
3. It is written that 'if the device does not have enough
     drive capability to make a significant output transition than a
higher load may be used' ,
     How much is significant output transition ?

* I do not have any hard guideline.  I prefer impedances in the
order of magnitude of transmission line loads since that is a
typical high-speed design application.  That ususally captures
a fast edge that would be seen with a PCB interconnect.

* This makes no sense for certain weak buffers which would
require multiple reflections to change from one state to the
other for an open line.  If the application is not high-speed,
then it does not manner.   I would guess that a higher value
load might be OK for a driver source impedance > 300 ohms.
Others might have different ideas.

4. it is written that ' For an open drain , measure the rise and fall
time into the load resistor and voltage used
    by the manufacture when specifying propagation delays' , This
sentence is not clear
    what is the test structure in open drain buffer case?.

* This is ambiguous.  I prefer low impedance (50 ohm) pullups to
capture a faster edge.  This may be in the order of magnitude of
the load seen during the intial part of the transition when the
device is connected through a PCB interconnect.

5. it is written that ' Falling edge ramp data is captured with the load
resistor tied to VCC'
    , Is VCC mean the pmos Driver source voltage (pad voltage) or low
voltage?

* This means that one end of the load resistor is connected to
Vcc, and the other end is connected to the output pad.

6. It is written that 'simulations are performed with C_comp included in
the circuit' , This sentence is not clear.
    As I understood C_comp is the capacitance seen when looking from the
pad back into the buffer ,
    It is written that C_comp should be added to the simulation , but
C_comp is not a capacitor it is capacitance measurement.

* It is difficult to de-embed the die capacitance information from a
Spice net list (since some of the contribution is due to paramaters
within the transistor/diode models) or from a real physical measurements.

* So the intent is to clarify that the die capacitance is already
included in any waveform extraction.  Since C_comp is a first order
approximation of the die capacitance, its effects should be included
in an EDA tool simulation.  I have not looked at the specific
wording, but I assume this is confusing.

7. In 'Ground Clamp' paragraph it is written that 'The data in table
must cover the range of -Vcc to Vcc ' ,
    Isn't it suppose to be -Vcc to 2*Vcc ?

* This response also covers 9.

* No, the minimum range is intended to be -vcc to vcc.  The Power
Clamp covers from vcc to 2vcc.  When this minimum range was
established, most Inputs were at negligle current at Vcc and the
slope (current vs voltage) was also nearly 0.  So concatenation
of the tables produced the same effect as extrapolation.

* It is allowed to extend the clamp ranges beyond the specified
range.  In some cases you should do so, especially if you are
including the effect of an internal terminator.  In such cases,
the conditions above are not met, and I prefer -vcc to 2vcc for
both clamp tables.  Care must be taken so that
currents are not double counted.  However, for many situations,
the "minimal" IBIS guidelines are sufficient.

8. In 'pulldn' paragraph it is written 'If the buffer is a 3-state
device then first subtract the ground clamp current
    from the pulldown current then enter the result into the [pulldown]
table' ,
    first , it is written above the graph 'Pullup I/V curve after
subtraction of ground clamp currents' Which is probably mistake.
    second , Should I replace the pulldn results in Ibis model file
after the subtraction?

* What is entered in the [Pulldown] table is the result after
subtraction.

9. In 'Power Clamp' It is written that 'the data in the table must cover
the range of vcc to vcc*2' ,
    Isn't the range suppose to be -Vcc to 2*Vcc ?

* See 7 above.

--
With regards,
Yoked.
_____________________________________
E-mail:       yokede@msil.sps.mot.com
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP
MOTOROLA     SEMICONDUCTOR     ISRAEL

-- 

With regards,

Yoked.

_____________________________________
E-mail:           yokede@motorola.com
Tel: 972-9-9522482 Fax: 972-9-9522888
WIRELESS     CIRCUIT  - IO      GROUP                 
MOTOROLA     SEMICONDUCTOR     ISRAEL
 
------_=_NextPart_001_01C12A70.90BFD7C0-- From owner-ibis Wed Aug 22 14:56:46 2001 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MLui7n012003 for ; Wed, 22 Aug 2001 14:56:46 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA321412 for ; Wed, 22 Aug 2001 17:54:33 -0400 Received: from d01ml221.pok.ibm.com (d01ml221.pok.ibm.com [9.117.200.51]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7MLmik181930 for ; Wed, 22 Aug 2001 17:48:44 -0400 Subject: To: ibis-users@eda.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hirut Asfaw" Date: Wed, 22 Aug 2001 17:56:39 -0400 X-MIMETrack: Serialize by Router on D01ML221/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/22/2001 05:56:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi all, Can anyone explain to me the real purpose of Dynamic Power/Gnd Clamp, which is in addition to the Power/Gnd Clamp tables included in an IBIS models. Thanks, Hirut Hirut Asfaw ASIC I/O Developement IBM Microelectronics Division External: (802) 769-0652 T/L: 6-0652 hasf@us.ibm.com From owner-ibis Thu Aug 23 06:40:40 2001 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7NDeb7n014615 for ; Thu, 23 Aug 2001 06:40:39 -0700 (PDT) X-Envelope-Sender-Is: Henry.Piedel@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id f7NDeap20634 for ; Thu, 23 Aug 2001 15:40:36 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 15:40:34 +0200 Message-ID: From: Henry.Piedel@infineon.com To: ibis-users@eda.org Subject: Differential Pair with AC Coupling Date: Thu, 23 Aug 2001 15:40:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hello, Can anyone give me their experiences with using IBIS modelling for a PECL differential pair with AC Coupling? (@ up to 1.5 GHz). Does it work - can / should it be done? Thanks. Henry Piedel Infineon Technologies AG Applications Engineer COM FO D E Tel.: +49 (0)30 386-36021 Fax: +49 (0)30 386-24939 henry.piedel@infineon.com ***** VISIT US AT: http://www.infineon.com/ ***** From owner-ibis Mon Aug 27 12:24:01 2001 Received: from mail.nesa.com (gw.nesa.com [64.3.167.94]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7RJNx7n005668; Mon, 27 Aug 2001 12:24:00 -0700 (PDT) Received: from porky (porky.nesa.com [172.29.121.18]) by mail.nesa.com (8.9.3/8.9.3) with SMTP id PAA01675; Mon, 27 Aug 2001 15:23:47 -0400 Message-Id: <3.0.5.32.20010827152346.00965310@mail.nesa.com> X-Sender: breda@mail.nesa.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 27 Aug 2001 15:23:46 -0400 To: ibis@eda.org, ibis-users@eda.org From: Kathy Breda Subject: Reminder: IBIS Summit - East 9/13/01 Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ------------------------------------------------------- > IBIS SUMMIT > FIRST CALL FOR > PARTICIPATION, > PRESENTATIONS > & SPONSORSHIP!!!! > ------------------------------------------------------- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I B I S S U M M I T M E E T I N G > > Time/Date: 8:30 AM - 5:00 PM, Thursday, September 13, 2001 > > Location: The Crowne Plaza Hotel > 10 Lincoln Square > Worcester, MA > Tel: (508) 791-1600 > Fax: (508) 791-1796 > > Content: Presentations and Discussions > > Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. > > Sponsors: North East Systems Associates, Inc. (NESA), > IBIS Users Group > Others to be determined > WE ARE LOOKING FOR ADDITIONAL SPONSORS! > (contact Kathy Breda, breda@nesa.com > or Bob Ross, bob_ross@mentor.com) > > PCB Conference: September 10-14, 2001 > East Worcester's Centrum Centre > Worcester, Massachusetts > See http://www.pcbeast.com/ for more information. > > BACKGROUND > > The IBIS Users Group (IBIS East) has been formed under the leadership of > Dr. Edward Sayre from North East Systems Associates, Inc. (NESA) and has > been meeting to consider and forward IBIS model user concerns. As a result > of East coast meetings, the group has developed an IBIS Accuracy Handbook > document and has initiated the project to format Connector Models. These > topics plus others of current interest to the EIA IBIS Open Forum will be > discussed at this meeting. > > This meeting will be conducted as a formal IBIS Summit Meeting. Presentation > are expected to be available and archived in an electronic format, and minutes > of the meeting will be issued. Any pending formal decisions (votes) will be > announced at least two weeks prior to the meeting. > > CALL FOR PARTICIPANTS > > People involved in IBIS Model development, EDA tool development, and digital > circuit design are invited to participate to the Summit meeting. If you plan > to participate, please register with the information below: > > Name: > E-mail address: > Company: > Telephone: > > Send to: > > Kathy Breda (breda@nesa.com) > > > CALL FOR PRESENTATIONS > > We are seeking presentations from individuals who have IBIS experiences > or issues. > > Format of Presentation: Overhead Projections > Time: 15-30 Minutes > Electronic Archival: We request electronic versions so that the > presentations can be archived and also made > available to non-attendees. Formats used in > the past have been text, Power Point, Word, > Postscript, and Acrobat. Electronic presentations > should be made available by September 7, 2001. > Otherwise the presenter will be expected to provide > up to 50 copies for distribution. > > If you plan a presentation, please supply > > Title: > Presenter: > E-mail address: > Company: > Telephone: > > Estimate Time: > > Send this to: > > Kathy Breda (breda@nesa.com) > > AGENDA > > The agenda includes presentations, discussions, breaks, and a luncheon (which > will be provided). This will be developed as presentation proposals are > received. So far the following presentatation is planned: > > "A Proposal for s2ibis3", Michael Steer, North Carolina State University > > "Modeling the Radiated Emission of Micro-controllers", Etienne Sicard, > National Institute of Applied Science (INSA/DEIG), France > > Plus IBIS Macro Language and demonstration, IBIS Connector Specification, > and other IBIS issues. > > LIST OF NEARBY HOTELS > > See http://www.pcbeast.com for travel directions, hotels and other > information. > > ************************************************************** 0000,0000,8080
_____________________________________________________________________________________________________
Kathy Breda | Director of Marketing North East Systems Associates, Inc. | 5 LAN Drive, Suite 200 | Westford, MA 01886 [T] 978-392-8787 [F] 978-392-8686 [W] www.nesa.com
From owner-ibis Mon Aug 27 14:51:41 2001 Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7RLpd7n005992 for ; Mon, 27 Aug 2001 14:51:40 -0700 (PDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA20673 for ; Mon, 27 Aug 2001 21:51:27 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 27 Aug 2001 21:51:26 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 14:51:23 -0700 Message-ID: <10C8636AE359D4119118009027AE99870C5A751A@FMSMSX34> From: "Muranyi, Arpad" To: ibis-users@eda.org Subject: RE: Purpose of dynamic clamps Date: Mon, 27 Aug 2001 14:35:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hirut, Here at Intel we came up with some clamping mechanisms that reduce over/undershoot, consequently ringback by bringing the knee voltage of the clamping device closer to the rail voltage, or the signal levels. The problem is that the knee of the I-V curves is never perfectly sharp, there is some rounding. Due to this rounding one can either not clamp well, or will have to put up with some leakage during the steady state portions of the signal. To reduce this DC current flow (and power consumption), we came up with some clamping ideas where the knee voltage is moved dynamically. Unfortunately I can't tell you much more about this unless I let them chop my head off, because there are some proprietary ideas involved. I hope this gives you some insight to what these dynamic clamps are used for. Arpad Muranyi Intel Corporation =========================================================== -----Original Message----- From: Hirut Asfaw [mailto:hasf@us.ibm.com] Sent: Wednesday, August 22, 2001 2:57 PM To: ibis-users@eda.org Subject: Hi all, Can anyone explain to me the real purpose of Dynamic Power/Gnd Clamp, which is in addition to the Power/Gnd Clamp tables included in an IBIS models. Thanks, Hirut Hirut Asfaw ASIC I/O Developement IBM Microelectronics Division External: (802) 769-0652 T/L: 6-0652 hasf@us.ibm.com From owner-ibis Tue Aug 28 08:36:08 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SFa67n008803; Tue, 28 Aug 2001 08:36:07 -0700 (PDT) Received: from svr-cas-exc-01.sje.mentorg.com ([134.86.32.11]) by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA06805; Tue, 28 Aug 2001 08:36:06 -0700 (PDT) Received: by svr-cas-exc-01.sje.mentorg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 08:35:58 -0700 Received: from mentor.com (bob.wv.mentorg.com [147.34.70.103]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q51HD7TR; Tue, 28 Aug 2001 08:38:10 -0700 Message-ID: <3B8BBA5F.DCFA51D@mentor.com> From: "Ross, Bob" To: ibis@eda.org, ibis-users@eda.org Subject: IBIS SUMMIT THIRD CALL REMINDER Date: Tue, 28 Aug 2001 08:35:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12FD7.70CC5D00" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12FD7.70CC5D00 Content-Type: text/plain To All: Here is an updated reminder with more presentation detail. Bob Ross Mentor Graphics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS SUMMIT THIRD CALL FOR PARTICIPATION & PRESENTATIONS!!! ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 8:30 AM - 5:00 PM, Thursday, September 13, 2001 Location: The Crowne Plaza Hotel 10 Lincoln Square Worcester, MA Tel: (508) 791-1600 Fax: (508) 791-1796 Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: North East Systems Associates, Inc. (NESA), IBIS Users Group Mentor Graphics IBIS Open Forum WE ARE LOOKING FOR ADDITIONAL SPONSORS! (contact Kathy Breda, breda@nesa.com or Bob Ross, bob_ross@mentor.com) PCB Conference: September 10-14, 2001 East Worcester's Centrum Centre Worcester, Massachusetts See http://www.pcbeast.com/ for more information. BACKGROUND The IBIS Users Group (IBIS East) has been formed under the leadership of Dr. Edward Sayre from North East Systems Associates, Inc. (NESA) and has been meeting to consider and forward IBIS model user concerns. As a result of East coast meetings, the group has developed an IBIS Accuracy Handbook document and has initiated the project to format Connector Models. These topics plus others of current interest to the EIA IBIS Open Forum will be discussed at this meeting. This meeting will be conducted as a formal IBIS Summit Meeting. Presentation are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to: Kathy Breda (breda@nesa.com) CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Format of Presentation: Overhead Projections Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. Electronic presentations should be made available by September 7, 2001. Otherwise the presenter will be expected to provide up to 50 copies for distribution. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Kathy Breda (breda@nesa.com) AGENDA The agenda includes presentations, discussions, breaks, and a luncheon (which will be provided). This will be developed as presentation proposals are received. So far the following presentations are planned: "A Proposal for s2ibis3", Michael Steer, North Carolina State University "Modeling the Radiated Emission of Micro-controllers", Etienne Sicard, National Institute of Applied Science (INSA/DEIG), France "Power/Ground Simulation with IBIS Models and Pin Mapping Issues", Raj Raghuram, Sigrity, Inc. "From Model Creator to Model User", Bob Haller, Cereva Plus IBIS Macro Language and demonstration, IBIS Connector Specification, and other IBIS issues. LIST OF NEARBY HOTELS See http://www.pcbeast.com for travel directions, hotels and other information. ************************************************************** ------_=_NextPart_001_01C12FD7.70CC5D00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable IBIS SUMMIT THIRD CALL REMINDER

To All:

Here is an updated reminder with more = presentation
detail.

Bob Ross
Mentor Graphics


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  =
-------------------------------------------------------  =
IBIS SUMMIT  
        THIRD = CALL FOR  
          &nb= sp;     PARTICIPATION & 
          &nb= sp;           &nb= sp; PRESENTATIONS!!!  
-------------------------------------------------------  =
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  =

          &nb= sp;  I B I S   S U M M I T   M E E T I N = G 

Time/Date:   8:30 AM - 5:00 PM, Thursday, = September 13, 2001 

Location:    The Crowne Plaza = Hotel 
          &nb= sp;  10 Lincoln Square 
          &nb= sp;  Worcester, MA 
          &nb= sp;  Tel:  (508) 791-1600 
          &nb= sp;  Fax:  (508) 791-1796 
          &nb= sp;     
Content:     Presentations and = Discussions 

Purpose:     Solicit and Exchange = IBIS Model Related Information and Ideas. 

Sponsors:    North East Systems = Associates, Inc. (NESA), 
          &nb= sp;  IBIS Users Group
          &nb= sp;  Mentor Graphics
          &nb= sp;  IBIS Open Forum
          &nb= sp;  WE ARE LOOKING FOR ADDITIONAL SPONSORS! 
          &nb= sp;       (contact Kathy Breda, = breda@nesa.com 
          &nb= sp;       or Bob Ross, = bob_ross@mentor.com) 

PCB Conference: September 10-14, 2001 
East          = ;  Worcester's Centrum Centre 
          &nb= sp;     Worcester, Massachusetts 
          &nb= sp;     See http://www.pcbeast.com/ for more = information. 

BACKGROUND 

The IBIS Users Group (IBIS East) has been formed = under the leadership of   
Dr. Edward Sayre from North East Systems Associates, = Inc. (NESA) and has 
been meeting to consider and forward IBIS model user = concerns.  As a result 
of East coast meetings, the group has developed an = IBIS Accuracy Handbook 
document and has initiated the project to format = Connector Models.  These 
topics plus others of current interest to the EIA = IBIS Open Forum will be 
discussed at this meeting. 

This meeting will be conducted as a formal IBIS = Summit Meeting.  Presentation 
are expected to be available and archived in an = electronic format, and minutes 
of the meeting will be issued.  Any pending = formal decisions (votes) will be 
announced at least two weeks prior to the = meeting. 


CALL FOR PARTICIPANTS 

People involved in IBIS Model development, EDA tool = development, and digital 
circuit design are invited to participate to the = Summit meeting.  If you plan 
to participate, please register with the information = below: 

  Name: 
  E-mail address: 
  Company: 
  Telephone: 

Send to: 

  Kathy Breda (breda@nesa.com) 
   

CALL FOR PRESENTATIONS 

We are seeking presentations from individuals who = have IBIS experiences 
or issues. 

Format of Presentation:  Overhead = Projections 
Time:         &nbs= p;          15-30 = Minutes 
Electronic Archival:     We = request electronic versions so that the 
          &nb= sp;           &nb= sp;  presentations can be archived and also made 
          &nb= sp;           &nb= sp;  available to non-attendees.  Formats used in  =
          &nb= sp;           &nb= sp;  the past have been text, Power Point, Word,   =
          &nb= sp;           &nb= sp;  Postscript, and Acrobat.  Electronic presentations  =
          &nb= sp;           &nb= sp;  should be made available by September 7, 2001. 
          &nb= sp;           &nb= sp;  Otherwise the presenter will be expected to provide  =
          &nb= sp;           &nb= sp;  up to 50 copies for distribution. 


If you plan a presentation, please supply  =

  Title: 
  Presenter: 
  E-mail address: 
  Company: 
  Telephone: 

  Estimate Time: 

Send this to: 

  Kathy Breda (breda@nesa.com) 


AGENDA 

The agenda includes presentations, discussions, = breaks, and a luncheon (which 
will be provided).  This will be developed as = presentation proposals are 
received.  So far the following presentations = are planned: 
   
  "A Proposal for s2ibis3", Michael = Steer, North Carolina State University 

  "Modeling the Radiated Emission of = Micro-controllers", Etienne Sicard, 
  National Institute of Applied Science = (INSA/DEIG), France 

  "Power/Ground Simulation with IBIS Models = and Pin Mapping Issues", 
  Raj Raghuram, Sigrity, Inc. 

  "From Model Creator to Model User", = Bob Haller, Cereva 

  Plus IBIS Macro Language and demonstration, = IBIS Connector Specification, 
  and other IBIS issues. 

LIST OF NEARBY HOTELS 

See http://www.pcbeast.com for travel directions, = hotels and other 
information. 

**************************************************************<= /FONT>

------_=_NextPart_001_01C12FD7.70CC5D00-- From owner-ibis Thu Aug 30 10:37:51 2001 Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) with SMTP id f7UHbm7n018691 for ; Thu, 30 Aug 2001 10:37:50 -0700 (PDT) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for server.eda.ORG [171.64.101.101]) with SMTP; 30 Aug 2001 17:37:44 UT Received: from hlgw.hyperlynx.com (hlgw.hyperlynx.com [192.168.149.1]) by mail.hyperlynx.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id KAA21508 for ; Thu, 30 Aug 2001 10:37:39 -0700 Message-ID: <4be501c1317a$c87b27d0$8ecab58b@Kaluga> From: "John Angulo" To: Received: from no.name.available by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 30 Aug 2001 17:37:43 UT Subject: Re: Test msg: please ignore Date: Thu, 30 Aug 2001 10:39:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Test message only... John Angulo IBIS Open Forum Postmaster