From owner-ibis Tue Feb 1 08:57:41 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA00598 for ; Tue, 1 Feb 2000 08:57:41 -0800 (PST) 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.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id QAA11872 for ; Tue, 1 Feb 2000 16:57:10 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 01 Feb 2000 16:56:33 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id <1BYG88MR>; Tue, 1 Feb 2000 08:56:32 -0800 Message-ID: <4575832C8E71D111AC4100A0C96B512706458806@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'ibis@vhdl.org'" Subject: Re: Future directions for IBIS Date: Tue, 1 Feb 2000 08:55:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" All, It's been a while, but I thought it would still be interesting to you. I started a discussion in December about IBIS futures, and received numerous valuable responses. I compiled a summary in which I pulled all the main points of the responses together (I paraphrased some of the more verbal ones). I gave a short presentation on the subject at the IBIS Summit at Design Con 2000 yesterday. For the benefit of those who weren't there (or those who didn't get handouts any more), here is the summary of the responses. Note that my presentation will be uploaded shortly on the IBIS web site. This material is reprinted in the Appendix of the presentation. Sincerely, Arpad Muranyi Intel Corporation -------------------------------------------------------------------- Advantages: =========== 1) IBIS succeeded because it created an accepted standard for distributing simulatable descriptions of I/O buffers. 2) Good at classical CMOS drivers. 3) Adequate for TTL receivers. 4) OK for passing device pinouts. 5) OK for uncoupled package parasitics. 6) OK for selectable drive strength. Observations, disadvantages: ============================ 1a) IBIS is not truly behavioral, but a parameter list for pre-defined structures. 1b) IBIS assumes circuit topology to which the parameters are supplied. 1c) Each change requires committee approval and implementation in simulators. 2a) IBIS is somewhat arbitrary and is suffering from creeping functionalism. 2b) It would be less work to generalize a simulator, than to keep modifying them to take new data types every time the spec changes. 3) With Berkeley SPCIE it was known how it will handle L, R, C, K values. This is not the case with behavioral simulators. 4a) IBIS does not lead to accurate SSN and return path prediction, and no straightforward extension will be able to handle this. A fresh start is needed. 4b) No return path models. 4c) No coupled parasitics. 4d) IV curves in (most) behavioral simulators are connected to perfect ground which ruins the validity of coupled connector models. 4e) Problems in the package power distribution and pin to pin coupling information. 5) Poor receiver modeling. 6) No coupled drivers (e.g. Open-drain current mode differential). 7) No method for source modulation (gate starvation). 8) Problem is not with IBIS itself, it is a matter of IBIS taking on a job which isn't fundamentally behavioral, where a structural interconnect model works quite well. 9) Kumar was right! Needs (comments, recommendations): ================================== Do we need IBIS? ---------------- 1a) Revisit the need for IBIS. Can proprietary information be distributed through public or private encryption? 1b) Encrypted SPICE models have conflicts with name space and scaling. 1c) Next generation for IBIS is no simulation at all, but design rules, in terms of the customers of chip makers. Simulation needs to move forward, but not in the same broad fashion we once used to (at least in the PC space). 1d) We will not be able to simulate every possible configuration for the entire solution space. The customer will have to simulate their designs to make sure it will work. What to keep and/or add? ------------------------ 2a) Keep IBIS1.1, in fact do not abandon IBIS as it exists now. Change the direction of future IBIS enhancements. 2b) IBIS should remain a data standard, and should not be going in the direction of node description language because that exists already (SPICE). Focus on It curves which will aid SSN modeling. 2c) Keep the concept of IBIS models documenting the SI requirements. 2d) Keep the concept of an agreed upon standard. 2e) The need for microwave style modeling is clear. 2f) Check into using MMIC, a nodal simulator of the 90's which does a fine job of goal based parameter optimization. 3a) Use IBIS [Model] for drivers and receivers. 3b) Enhance IBIS as needed to model gate starvation. 3c) Enhance IBIS as needed to model input behavior. 3d) Receiver characterization should investigate using probability techniques. Output is between 0 and 1 representing probability. This may be the right way for "jittery receivers". 3e) Specify timings between buffers (skew). 4a) Represent some basic independent and dependent sources in matrix form. 4b) Don't forget Boolean capabilities in WSPICE, which may be required to characterize buffers. 4c) Need two agreed standards: - multi coupled lossy T-line, and - table driven, event triggered controlled current sources 4d) IBIS behavioral element needs to be standardized. Receiver model will become standardized subcircuits using these elements. S-parameter and LaPlace types will be useful also. Expressions should include logical 'if else' and derivatives. Language, syntax ---------------- 5a) Develop a SPICE like macro language describing the circuit with parameters and program logic. Parameters refer to tables, values, formulas in separate sections who's syntax matches existing IBIS [Model] and [Submodel] sections. 5b) IBIS should be a set of macro models that properly capture I/O edges and Vdd and GND transients. Table based IV macro models are appropriate. 5c) Need fundamental open work on what is needed to accurately model a driver with a macro model. 5d) Should be able to produce macro models from SPICE or measurements. 5e) Should be possible to translate the macro models into popular SPICE flavors. 5f) The IBIS committee needs to define and verify the standard structures for new devices. 6a) Use an XML based syntax which is essentially a structured SPICE. It should include BSPICE in addition to IV, Vt, etc. tables. May need to limit what SPICE elements to use. Lossy elements will need to be addressed soon. 6b) A perfect language should accept IBIS, SPICE, N-port network description language, graphical input, measurement based tables of S, Y, or Z-parameters by frequency or NDL equations. 6c) A common thread seems to be network description objects, object oriented language. Look at Agile user manual. It uses the linpack nonlinear PDE solvers. Smalltalk, and Matlab solver would work for prototyping. 7a) Netlist-like format is really necessary to define return path and coupling effects. 7b) A netlist type structure is the only sensible route forward. Would vote for an extended SPCIE syntax, which could be used to model existing devices, or we could redefine the current structures using the new syntax. 7c) Use EDIF netlist (or extended SPICE format which allows distributed parasitics) to model on-chip return paths. 7d) Proposing two sections, a parameter and a structure definition section. A netlist like language (inspired by SPICE) could be used to define them. However, since it will be processed, it could provide component types and parameters that do not exist in standard SPCIE. To provide a migration path, a set of structure definitions could be provided with any conforming IBIS simulator. Package ------- 8a) Do not include package in IBIS models. Use SPICE for that. 8b) Standardize die, pkg, and connector model on the CAD tool level. 8c) RLC will not be satisfactory for packaging, need lossy coupled transmission lines. 8d) Sounds like you are leading towards the 'Universal parser' for packaging related info with some common format. 8e) Use connector syntax or netlist to model package parasitics. 8f) Use some of the items from the proposed connector specification. Additional features to be considered: - Behavioral modeling of interconnects (S-parameters). - Consider delay and impedance (admittance) matrixes for cable modeling. Would have really liked to develop nodal methods for the connector specification but there was a pushback in those days. Really like the inclusion of PWR/GND references. IBIS-X ------ 9a) The IBIS-X approach proposes that in addition to the traditional IBIS prototype model, behavioral elements should be connected together nodally. The nodal approach allows build arbitrary packages around the buffer for SSN, power delivery, and return path modeling. 9b) A model is a multi port entity. Submodels are also allowed. 9c) In addition, provide hooks that enable simulators to incorporate external (transistor level) models through an API. 9d) Each model should also contain data book information for automated flight time and skew analysis. 9e) Not clear how behavioral simulator can call SPICE since SPICE is not set up to be callable. 9f) Question: Will it be IBIS calling other formats or other formats calling IBIS? 9g) IBIS-X should consider the connector RLC interconnect methodology for package. ==================================================================== From owner-ibis Tue Feb 8 11:54:18 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA03395 for ; Tue, 8 Feb 2000 11:54:17 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id OAA28680 for ; Tue, 8 Feb 2000 14:52:38 -0500 (EST) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id OAA23727 for ; Tue, 8 Feb 2000 14:52:37 -0500 (EST) Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id LAA18889 for ; Tue, 8 Feb 2000 11:51:33 -0800 (PST) Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4) id LAA00587; Tue, 8 Feb 2000 11:53:59 -0800 Date: Tue, 8 Feb 2000 11:53:59 -0800 From: guy@camarillo.viewlogic.com (Guy de Burgh) Message-Id: <200002081953.LAA00587@f22.viewlogic.com> To: ibis@eda.org Subject: EIA IBIS Summit Meeting Minutes (1/31/00) DATE: 2/8/00 SUBJECT: 1/31/00 EIA IBIS Summit Meeting Minutes VOTING MEMBERS AND 2000 PARTICIPANTS LIST: 3Com (Roy Leventhal) Applied Simulation Technology Raj Raghuram*, Norio Matsui*, Fred Ballesteri* Avanti Nikolai Bannov* Cadence Design Mike LaBonte*, Todd Westerhoff*, Ian Dodd*, Donald Telian* Cisco Systems Syed Huq*, Irfan Elahi*, John Fisher* Compaq Bob Haller*, Peter LaFlamme*, Ron Bellomio*, Shafiq Rahman*, Doug Burns* Cypress (Rajesh Manapat) EMC Corporation (Fabrizio Zanella), Fairchild Semiconductor Craig Klem* H.A.S. Electronics (Haruny Said) Agilent (EEsof, etc.) Mark Chang* Hewlett Packard Paul Gregory*, HyperLynx (& Pads Software) Matthew Flora, Kellee Crisafulli*, Gene Garat*, John Angulo, Al Davis*, Lynne Green* IBM Michael Cohen* Incases (Werner Rissiek) Intel Corporation Stephen Peters*, Arpad Muranyi*, Will Hobbs*, Richard Mellitz* LSI Logic (Larry Barnes) Mentor Graphics (& Veribest) Bob Ross*, Tom Dagostino*, Malcolm Ash*, Kim Owen* Mitsubishi Shahab Ahmed* Molex Incorporated Gus Panella* Motorola Ron Werner National Semiconductor Milt Schwartz* North East Systems Associates Edward Sayre*, Tony Sinker* NEC (Hiroshi Matsumoto) Nortel Networks Steve Coe* Philips Semiconductor D.C. Sessions* (& VLSI Technology) Quantic EMC (Mike Ventham) Siemens Bernhard Unger* SiQual Scott McMorrow*, Wis Macomson* Texas Instruments Stephen Nolan*, Ramzi Ammar*, Mac McCaughey*, Thomas Fisher* Time Domain Analysis Systems Dima Smolyansky*, Steven Corey* Viewlogic Systems Chris Rokusek, Guy de Burgh*, Jun Tian*, (Jon Powell) Via Technologies (Weber Chuang) OTHER PARTICIPANTS IN 2000: Actel Corp. Silvia Montoya* Avanti Mikio Kiyono* Brocade Communications Robert Badal* EIA (Cecilia Fleming) Jet Propulsion Lab John Treichlew* Rockwell Collins Ron Hau* Signals & Systems Engineering Tom Hawkins* Sun Microsystems Victor Chang* Xilinx, Inc. Susan Wu* In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode February 25, 2000 (916) 356-9200 4-299297 3855864 March 17, 2000 (916) 356-9200 4-299298 8432634 March 31, 2000 - DATE 2000 IBIS Summit Meeting (No Bridge) All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- ADDED NOTE AFTER THE MEETING Congratulations to Syed Huq for having his paper "Effective Signal Integrity Analysis Using IBIS Models" selected as a Best Paper at DesignCon 2000. ------------------------------------------------------------------------------ INTRODUCTIONS AND MEETING QUORUM Bob Ross opened the IBIS Summit Meeting held in Santa Clara, California. About 58 people representing 30 organizations attended throughout the day. The minutes capture some of the presentation content and related discussions. Most presentations will be uploaded after they are received at: http://www.eda.org/pub/ibis/summits/jun00/ Bob thanked the DesignCon2000 organization for providing the room, the refreshments and for the booth at the show. Bob thanked Milt Schwartz and National Semiconductor for handling the local arrangements including copying of presentations and also for providing the buffet lunch. Thank you to Viewlogic for providing the booth backdrop at the show and to Jon Powell for gathering the member company logos. Finally, thank you to Bob Haller for arranging the electrical demonstrations to be discussed later. Bob R. announced that Molex Incorporated is listed as a new member. Arpad Muranyi will be giving two days of classes on "Introduction to IBIS Models" and " IBIS Modeling Hands-on Experience" at the tutorial short course "Circuit Simulation and Signal Integrity in Microelectronic Circuits and Systems" at the University of Arizona on February 14-16 in Scottsdale, Arizona. Bob R. mentioned that IEC 62014-1 (IBIS Version 3.2) is scheduled to be published in August 2000, but we still need to follow up on its exact status. All the participants introduced themselves. A show of hands indicated that this group had strong semiconductor vendor and real designer participation, and moderate EDA vendor participation. SIMULTANEOUS SWITCHING NOISE (SSN) MODELING Dr. Bernhard Unger, Siemens AG Bernhard Unger expanded upon a proposal initially presented at the European IBIS Summit Meeting in March 1999. He showed results based on the two-waveform methodology using HSPICE and IBIS models of the Fairchild Semiconductor VCX16244 and the LSI Logic BD4 G10 technology. The enhanced method uses and additional Kssnr multiplier on the pullup table scaled voltage controlled current source and a kssnf multiplier on the pulldown table voltage controlled time scaled current sources. Both multipliers are a function of the (Vdd-Vss) voltage drop and model the feedback on the gate source voltage of the output transistors. These multipliers can be derived either by a golden waveform SSO V-T table or more directly by Pullup/Pulldown V-I tables as a function of Vdd under a specified load such as 50 ohms. Bernhard showed results for 6 switched VCX16244 outputs and 10 switched BD4 outputs. These results correlated better than results without the added multipliers. However, the best results were obtained when using an additional prestage capacitance designated Cpre between Vdd and Vss. Bernhard showed comparisons that were nearly equivalent to Spice simulations for most of the test cases. One test case for noise on a quite buffer showed same magnitude as the reference Spice simulation, but did not overlay as well as the other tests. Bernhard concluded that while the results are good, more investigations on the valid range and accuracy of the proposed model would be valuable. Arpad Muranyi questioned why C_comp was split into two parts, and Bernhard responded that he split C_comp for Spice simulation convergence improvement. We discussed further the splitting C_comp per pending BIRD65. Several attendees expressed interest in this general approach to SSN modeling. DESIGNCON2000 IBIS SUMMIT BOOTH DEMO Bob Haller, Compaq Bob Haller stated that the booth number 1039 is being setup. It is a neutral meeting place for IBIS members. Logos of many member companies are being displayed (thanks to Jon Powell). A test board for connector measurements is being displayed along with the accuracy test board. Bob thanked Agilent Technology for loaning the oscilloscope. The connector demonstration will show measurements: Impedance Crosstalk Single active technique Spreadsheet Propagation delay SSO (not demonstrated) This demonstration is a complement to the draft IBIS Connector Specification that will be on display to deal with an important industrial issue. BRIEF HISTORY OF THE IBIS COMMITTEE (Ad Hoc) Bob Ross displayed the list of contributors for June 1993 IBIS Version 1.0 that exists in the document. Many of the original founding companies are still active in the IBIS Open Forum, but with different names due to acquisitions and mergers. Among the current attendees where the founding members and former IBIS Chairs Donald Telian and Will Hobbs. Arpad Muranyi (not listed) and Kellee Crisafulli were also active in the "early" days. The specification lists names and "telephone" numbers. Email was just starting to be used. Bob noted that while Jon Powell's company name has changed about four times, his telephone number remains the same. We have continued since the very beginning to conduct teleconference meetings about every three weeks. Initially the minutes were distributed by surface mail and FAX. In the later years, we made use of e-mail lists and websites. The committee has grown to over 30 member companies with much broader user and semiconductor company representation than just Intel. The Specification has grown considerably, but many new important issue now exist. The new question is: what will the IBIS Committee and technical interaction be like in the next 7 and 1/2 years? IBIS CONNECTOR SPECIFICATION Gus Panella, Molex Gus Panella briefly introduced the pending IBIS Connector Specification and mentioned a few specific details in the document. Briefly, it support many different types of connector modeling methods and all types of connectors. For example the following are supported: Differential and unbalanced signaling Single line models (uncoupled) Multiline models (coupled) Cascaded models Angled connectors Cross connected pins Board to board Board to cable Furthermore, it has the following capabilities: Swath matrix to allow pin expansion without matrix expansion, Simulator compatible and consistent node mapping and parameter definition, More than one model can be described in just a few lines. Gus discussed the cascaded sections and showed that by changing just one section, different connector models can be produced to support connections to boards with different thicknesses. Third party vendors can add value in several areas including software to extract models from geometry, model confirmation service, etc. Gus then listed an number of activities for acceptance and promotion of the connector specification. These included a golden parser, a possible BNF description, reference models, accuracy methodology documentation, and general publicity. Upon questioning, Gus indicated that the connector proposal used the Maxwell matrix format. Bob Ross and Kellee Crisafulli joined Gus to discuss and attempt to resolve a few of the comments. After discussions and group votes, we agreed to modify the proposal in the following ways: The extension .ibiscnn will be changed to .icm for "IBIS Connector Model" since there might be cases under DOS representation under Windows where the extension is reduced to 3 characters The mixed 80 characters and 120 characters per line for "comment" versus technical lines was resolved to be a 120 character limit throughout. Longer matrix lines can still be wrapped, so no data is lost. The 120 character limit still allows printing the model in landscape mode for visual inspection. However, keeping lines less than 80 characters is still recommended, if possible, as good practice. The keywords [Email] and [Website] are to be replaced by one [Support] keyword provides a common location for contacting the source. This avoids specific syntax rules and also allows for new methods that could emerge. We were divided regarding the need and usage of [Redistribution] keyword and will take up this issue at a later time. The connector companies want this keyword. Gus and Bob had other items that needed to be discussed. However, Bob suggested that we continue the discussion on the reflector and at future meetings so we could move on to other items on the Agenda. USING STATISTICAL METHODS TO CHARACTERIZE RECEIVERS TO DETERMINE THE APPLICABILITY OF RECEIVER MODELING STANDARDIZATION Richard Mellitz, Intel As part of the general topic of behavioral input characterization Richard Mellitz defined a characterization process and showed some results. The basic problem is to improve timing simulation prediction over the "time to threshold" technique and also to determine of the characterization is feasible for a given receiver. Richard than described steps in the process to do this. Richard suggested and illustrated these stimuli and discussed what they would be testing: Slew Rate Case Slew rate Overdrive Threshold sensitivity Shelf Case Monotonic sensitivity Overdrive Threshold sensitivity Define threshold region of uncertainty Ringback Case Ringback sensitivity Notch discrimination Inflection Case Monotonic sensitivity Overdrive Threshold sensitivity Define threshold region of uncertainty Settling Case Settling voltage Overdrive Frequency Case Frequency noise sensitivity Noise amplitude rejection Power supply noise rejection Vref noise sensitivity Overlaying waveform and three-dimension plots based on Monte Carlo simulations were presented to illustrate these effects and to suggest some conclusions regarding some receivers: Have predictable delay and performance Have undesirable areas of operation, i.e., metastability, etc. Need specification margins to assure performance Are more sensitive to power supply noise Richard concluded by raising these questions: What is a necessary and sufficient set of input waveforms? What type of performance need to be modeled? What is delay as a function of receiver parameters? Where is a safe region of oxide wear out? When should a receiver be considered unpredictable? A number of questions and much discussion followed this presentation. BEHAVIORAL RECEIVER MODELING Donald Telian, Cadence Design Systems After the delicious buffet lunch hosted by National Semiconductor, Donald Telian commented that this is a major improvement from the early days of sandwiches and chips. Donald introduced the topic by showing how design methodology has evolved: Use terminations (mid-1980s) Driver scaling and tuning (early 1990s setting the stage for IBIS and for tools allowing topology optimization) Now - more detailed receiver modeling Behavioral receivers are needed for simplification, performance, and design optimization. Donald elaborated on these points and summarized that a receiver can be tuned just like we are used to doing with the driver and interconnect. Donald discussed three general approaches to receiver modeling: Silicon-level Spice description (slow and proprietary) Pre-configured behavioral description (has a defined structure, and imitates only one thing, and can be too limiting) Nodal behavioral description (models receivers characteristics and adaptable to arbitrary behaviors) Donald then outlined a nodal implementation dubbed as the Digital Universal Behavioral (DUB) Receiver Model. He showed and illustrated a block diagram consisting of these blocks: #1: Low Pass Filter - reject certain pulse spikes #2: Switching Function - receivers basic transfer function #5: Intrinsic Delay - delay for fastest edge #3: Edge Rate Detection - derivative of input signal effects delay #4: Delay Adder - dynamically adjusts circuit delay based on #3 The components to implement this include: Nodal language G (VCCS) and E (VCVS) Real-time adaptive delay line Subcircuit nesting and random node printing Donald then showed some speed and accuracy comparisons with Spice models and indicated good performance. More work could have yielded even higher accuracy. He recommends that if IBIS implements behavioral receivers, a nodal language be used to deal with unique situations. He stated that the compelling application that prompted the need for IBIS drivers was the PCI bus and the Pentium processor. Donald concluded by asking if there is a compelling application that requires behavioral receivers. D.C. Sessions responded by mentioning the double data rate (DDR) DRAM model needs, and Arpad Muranyi mentioned the PCI 133. FUTURE OF IBIS Bob Ross introduced the next segment of the meeting. We have already heard some specific proposals regarding SSN, connector modeling and input modeling. Regarding future directions, a number of overlapping proposals and suggestions have been issued. Bob then listed some options based on recent e-mail reflector comments: IBIS-X (Stephen Peters) API (Will Hobbs) BIRDxxx (not yet issued, Arpad Muranyi) Equations (Arpad Muranyi) Structures (Al Davis) Macromodels (Paul Franzon) Linkage Syntax in IBIS (Scott McMorrow) Enhanced IBIS for Inputs (D.C. Sessions) Also, Bob showed that we could also have links: Spice IMIC S-parameters EDIF VHDL-A or Verilog C etc. Some of the proposals are discussed in the remaining presentations. MACRO EXTENSIONS FOR IBIS Al Davis, HyperLynx Al Davis proposed that with macro extensions to IBIS we would not need so many BIRDS for advances. Macro extensions define the circuit topology, parameterize it, and also provides a library. Other options would be Spice IMIC, and VHDL or Verilog. Al then illustrated providing macro extension for several examples including a parallel and series terminator. The approach is compatible with such IBIS advances as Waveform, [Pullup] and [Pulldown] interactions; Series Switch [On] and [Off]; Correlation (typ, min, max) and Attachments ([Add Submodel], [Driver Schedule]). He illustrated this with a driver example. Al proposed these components: Spice R, L, C, V, I, E, G Some Spice extras such as voltage controlled conductance, resistance and capacitance (vcg, vcr, vccap) Non-Spice attributes for driver, trigger, and alarm Programming for assert, define, export, if, inherit, local, and select He concluded that a new section [Define Model] could be used to describe the topology of [Model] and [Submodel]. Al stated that a draft language reference manual as attached to his presentation. FUTURE DIRECTIONS FOR IBIS Arpad Muranyi, Intel Arpad Muranyi started the discussion by commenting on the IBIS reflector thread he started in December 1999 on what people thought should be done with the IBIS Specification. The results are summarized as an Appendix to the presentation. Arpad listed these problems: The current IBIS syntax is inflexible because the majority of the keywords are based on (individual) assumptions and usage rules Connectivity between die and package is also based on assumptions and usage rules This type of a syntax slows down growth and limits the possibility of adding new features quickly A specification with such syntax becomes unmanageable The solution is a new syntax that is: scalable (two .. N-terminal black boxes) general purpose (anything in the black box) nodal (allow arbitrary connections between black boxes and between a collection of black boxes and the outside world) Arpad showed a block diagram that had die interconnect circuitry between the package and the die. This diagram illustrated the concept behind an unreleased BIRDxxx proposal. Arpad listed these advantages: Supports current IBIS format (backward compatibility) Supports IMIC format Supports full Spice format Allows any level of abstraction available for flexibility, accuracy, and security (IP protection) To implement this, he uses a Spice syntax with some behavioral features. However, the borderline between just "model" and "just data" becomes fuzzy. Arpad proposes taking action by considering and adopting one of these options: A Spice-like nodal syntax An object oriented programming language style syntax XML language Ian Dodd stated that currently the EBD structure is a subset. D.C. Sessions commented that the package interconnect is becoming the dominant design issue. Also, other languages such as VHDL-AMS and Verilog should be considered. Don Telian suggested encryption as a possible solution. MODELING APPROACHES: TABLES VERSUS EQUATIONS Dr. Lynne Green, HyperLynx Lynne Green stated the problem that more points and more tables can produce very large files. As features and details are added, libraries of models can consume significant memory and also slow down loading and simulation. Lynne illustrated this with a worst case model. On the other hand, a few small tables load, search, and simulate rapidly. Tables can grow, but equations are always smaller and faster. Lynne cited a University of Washington study regarding a power FET model. Using equations improved storage, speed and accuracy. Lynne listed a number of specific benefits for using equations. She proposed more university investigation on: Small equation set Mix tables and equations parser for equations file size impact simulation impact DISCUSSION - THE FUTURE OF IBIS: THE IBIS-X PROPOSAL Stephen Peters, Intel Stephen Peters outlined the specific IBIS-X proposal by citing these guidelines: Retain features that support board level simulators and electrical rule driven routers Add features that support circuit type simulators Provide a path for external models (i.e., API Interface) Stephen showed and illustrated the outline consisting of these sections" File Header Component Model One important addition is to introduce [Begin Model]. It supports much of the existing IBIS [Model] keywords plus some proposed BIRD62.2 and BIRD63.2 input details. Also Stephen presented some port types that would be listed in a new [Port List] keyword: primary_io primary I/O pin pullup_ref power connection pins pulldown_ref pwrclamp_ref gndclamp_ref rcvr_ref gnd reference pin ctl a digital (I/O) control pin analog an analog control pin stim_in an external stimulus (not a component pin) receiver_out output of a receiver (not a component pin) The models section also supports nodal descriptions with conventional Spice-like syntax for resistors, inductors, capacitors and voltage and current sources. It also supports an Sxxx element for equations or tables for three terminal devices and Xxxx for attaching ports of submodels. Questions and discussion occurred on various aspects. Al Davis volunteered to work with Stephen and Arpad Muranyi to come up with a unified proposal. Will Hobbs proposed a trap door escape path using an application programmable interface (API). D.C. Sessions mentioned some new language alternatives. One concern is that the encryption may be platform independent. CLOSING REMARKS Bob Ross thanked Milt Schwartz and National Semiconductor for handling the local arrangements and providing the excellent lunch. Bob noted that the next IBIS Summit meeting is scheduled on Friday, March 31 in Paris, France at the end of the DATE2000 Conference. Also Bob set the next teleconference meeting on Friday, February 25, 2000 and stated that BIRD62.2 and BIRD63.2 are scheduled for a vote. Several people met briefly after the meeting to discuss the upcoming JEDEC/ IBIS working group meeting scheduled for Thursday, February 3, 2000. NEXT MEETING: The next teleconference meeting will be on Friday, February 25, 2000 from 8:00 AM to 10:00 AM. BIRD62.2 and BIRD63.2 are scheduled for voting. ------------------------------------------------------------------------------ JEDEC/IBIS WORKING GROUP MEETING - BRIEF NOTES Date/Time: Thursday, February 3, 2000, 1:00 PM - 5:00 PM Location/Host: Philips Semiconductor, San Jose, CA, D.C. Sessions Title: IBIS as a Specification Language Attendees: IBIS: Bob Ross, Mentor Graphics Kellee Crisafulli, HyperLynx Fred Ballesteri, Applied Simulation Technology Mike LaBonte, Cadence Design Systems Richard Mellitz, Intel Arpad Muranyi, Intel JEDEC: D.C. Sessions, Philips Semiconductor (Chair JC-16) Gil Russell, Infineon Technologies (Chair., JC-16.2) Howard Sussman, Sanyo Driving Force: Advances in DDR DRAMS Specification Needs (more clarification needed): 1. Differential Output Coupling at the Buffer to Pad level 2. A delta C_comp limit for buffers at the component level 3. SSTL-2 Input enhancements (BIRD62.2, BIRD63.2) Application Needs: 1. Relative Pad Delay (Skew in delay to pad) 2. Return Path details (possibly using Dr. Unger's SSN approach above) 3. Input Modeling (initially BIRD62.2, BIRD62.3 An IBIS Working Group on consisting of (at least) Arpad Muranyi, Kellee Crisafulli, Mike LaBonte, D.C. Sessions and Richard Mellitz will work on these issues and generate proposals. Next JEDEC and JC-16 and JC-42 Meetings: Friday, February 4, San Jose, California Report on the JEDEC/IBIS meeting and on future work Approximately March 7, 2000, Atlanta, Georgia ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@viewlogic.com Senior Manager, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jpowell@viewlogic.com Senior Scientist, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Signal Integrity Engineer, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 114715 N.E. 95th Street Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org/eig/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Tue Feb 8 16:33:28 2000 Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA04198 for ; Tue, 8 Feb 2000 16:33:28 -0800 (PST) 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.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id QAA04013 for ; Tue, 8 Feb 2000 16:32:20 -0800 (PST) Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 Feb 2000 00:32:20 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id <1RTWWLT8>; Tue, 8 Feb 2000 16:32:18 -0800 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C04069A04@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis@eda.org'" Subject: Bird 62.2 -- Enhanced Specification of Reciever Thresholds Date: Tue, 8 Feb 2000 16:32:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Hello All: In preperation for voting on this BIRD at the next IBIS teleconference (Feb 25th), I am reposting Bird 62.2. Please look it over, and direct any comments to ibis@eda.org. Regards, Stephen Peters Intel Corp. ----cut here ---- Buffer Issue Resolution Document (BIRD) BIRD ID#: 62.2 ISSUE TITLE: Enhanced Specification of Receiver Thresholds REQUESTOR: DC Sessions (Philips), Stephen Peters, Richard Melitz, Arpad Muranyi (Intel Corp). DATE SUBMITTED: Aug 24, 1999, Dec 28, 1999, Jan 6, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: **************************************************************************** *** **************************************************************************** *** STATEMENT OF THE ISSUE: When specifying receiver input thresholds the current specification allows only the traditional DC derived Vinh and Vinl parameters. These two parameters are no longer adequate for describing receivers used for high speed designs. This BIRD proposes four new input switching threshold parameters: Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc. These parameters are referenced to an reference point Vth, and this reference is allowed to vary with variations in a supply. **************************************************************************** *** STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Model Spec] keyword. |=========================================================================== == | Keyword: [Receiver Thresholds] | Required: No | Sub-Params: Vth, Vth_min, Vth_max, Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc, | Vth_sensitivity, Input_Ref_Supply | Description: The [Receiver Thresholds] keyword defines both a set of | receiver input thresholds as well as their sensitivity to | variations in a referenced supply. The subparameters are | defined as follows: | | Vth, Vth_min and Vth_max are the ideal input threshold voltage | at which the output of a digital logic receiver changes state. | Vth is the nominal input threshold voltage under the voltage, | temperature and process conditions that define 'typ'. Vth_min | is the minimum input threshold voltage at 'typ' conditions | while Vth_max is the maximum input threshold voltage at 'typ' | conditions. | | Vinh_ac is the voltage that a low-to-high going input waveform | must reach in order to guarantee that the receiver's output | has changed state. In other words, reaching Vinh_ac is | sufficient to guarantee a receiver state change. Vinh_ac is | expressed as an offset from Vth. | | Vinh_dc is the voltage that an input waveform must remain | above (more positive than) in order to guarantee that a | receiver output will NOT change state. Vinh_dc is expressed | as an offset from Vth. | | Vinl_ac is the voltage that a high-to-low going input waveform | must reach in order to guarantee that the receiver's output | has changed state. In other words, reaching Vinl_ac is | sufficient to guarantee a receiver state change. Vinl_ac | is expressed as an offset from Vth. | | Vinl_dc is the voltage that an input waveform must remain below | (more negative than) in order to guarantee that a receiver's | output will NOT change state. Vinh_dc is expressed as a | offset from Vth. | | Vth_sensitivity is a unitless number that specifies how Vth | varies with respect to the supply voltage defined by the | Input_Ref_Supply subparameter. Vth_sensitivity is defined | as: | | change in input threshold voltage | Vth_sensitivity = ------------------------------------ | change in referenced supply voltage | | Vth_sensitivity must be entered as a whole number or | decimal, not as a fraction. | | Input_Ref_Supply indicates which supply voltage Vth tracks; | i.e. it indicates which supply voltage change causes a change | in input threshold. The legal arguments to this subparameter | are VOLTAGE_RANGE (the supply voltage defined by the | [Voltage Range] keyword), PULLUP_REF (the supply voltage | defined by the [Pullup Reference] keyword), or EXT (an | external voltage defined by the [External Reference] keyword). | | | Usage Rules: The [Receiver Thresholds] keyword is valid if the model type | includes any reference to input or I/O. The Vinh_ac, Vinh_dc, | Vinl_ac, Vinh_dc and Vth subparameters are required and | override the Vinh, Vinl, Vinh+/- and Vinl+/- subparameters | declared under the [Model] or [Model Spec] keywords. The | Vth_min, Vth_max, Vth_sensitivity and Input_Ref_Supply | subparameters are optional. However, if the Vth_sensitivity | subparameter is present then the Input_Ref_Supply | subparameter must also be present. | | Subparameter Usage Rules: | Numerical arguments are separated from their associated | subparameter by an equals sign (=); white space around the | equals sign is optional. The argument to the | Input_Ref_Supply subparameter is separated from the | subparameter by white space. | | Vth at Minimum or Maximum Operating Conditions: | As described above, the Vth_min and Vth_max subparameters | define the minimum and maximum input threshold values under | typical operating conditions. There is no provision for | directly specifying Vth under minimum or maximum operating | conditions. Instead, these values are calculated using | the following equation: | | Vth(min/max) = Vth* + [(Vth_sensitivity) X (change in supply voltage)] | | where Vth* is either Vth, Vth_min or Vth_max as appropriate, | and the supply voltage is the one indicated by the | Input_Ref_Supply subparameter. | | | Differential Receivers: | For a single ended receiver the numerical values of Vth, | Vth_min and Vth_max are specified with respect to 0v. | However, if the [Receiver Threshold] keyword is describing | a differential receiver (i.e. is part of a [Model] statement | that describes a pin listed in the [Diff Pin] keyword), then | Vth is typically assigned a value of zero volts and the | Vth_min and Vth_max parameters are not used. The values of | Vinh_* and Vinl_* subparameters are still given as an | offset from Vth and become, in effect, the more traditional | Vdiff. | | Examples: | | A basic 3.3v single ended receiver using only the required | subparameters | Vth = 1.5v Vinh_ac = +225mV Vinh_dc = +100mV Vinl_ac = -225mV Vinl_dc = -100mV | | | A single ended receiver using an external threshold reference. In this | case the input threshold is the external reference voltage so | Vth_sensitivity equals 1. | Vth = 1.0v Vth_sensitivity = 1 Input_Ref_Supply EXT Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | | A fully specified single ended 3.3v CMOS receiver | Vth = 1.5v Vth_min = 1.45v Vth_max = 1.53v Vth_sensitivity = 0.45 Input_Ref_Supply VOLTAGE_RANGE Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | | A differential receiver | Vth = 0.0v Vinh_ac = +50mV Vinh_dc = +25mV Vinl_ac = -50mV Vinl_dc = -25mV 2) The following new keyword is defined and place in the specification following the [GND Clamp Reference] keyword |=========================================================================== == | Keyword: [External Reference] | Required: Yes, if a receiver's input threshold is determined by an | external reference voltage | Description: Defines a voltage source that supplies the reference voltage | used by a receiver for its input threshold reference. | Usage Notes: Provide actual voltages (not percentages in the typ, min max | format. "NA" is allowed for the min and max values only. |--------------------------------------------------------------------------- -- | variable typ min max [External Reference] 1.0v 0.95v 1.05v 3) Under section 2 of General Syntax Rules and Guidelines the following words are added to the list of reserved words. EXT - A reference to a voltage defined by the [External Reference] Keyword VOLTAGE_RANGE - A reference to a voltage defined by the [Voltage Range] keyword PULLUP_REFERENCE - A reference to a voltage defined by the [Pullup Reference] keyword **************************************************************************** ** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This proposal follows the recommendations of the JC-15 committee for specifying SDRAM inputs. Update for 62.1: Specified exactly which [Model] and [Model Spec] parameters are overridden by [Receiver Threshold] and changed the wording of the "Differential Receivers:" to indicate that the numerical value of Vth is *typically* assigned a value of 0v rather than *must* be assigned a value of zero. Update for 62.2 Under Usage Rules: added the section (Subparameter Usage Rules:) describing the syntax rules for seperating arguments from subparameters. Updated examples with this change. **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Melitz and Aprad Muranyi of Intel Corp. **************************************************************************** *** From owner-ibis Tue Feb 8 16:40:58 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA04227 for ; Tue, 8 Feb 2000 16:40:58 -0800 (PST) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id AAA14897 for ; Wed, 9 Feb 2000 00:40:28 GMT Received: from fmsmsx28.FM.INTEL.COM ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 Feb 2000 00:39:50 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0) id <1BYF0N2H>; Tue, 8 Feb 2000 16:39:48 -0800 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C04069A05@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis@eda.org'" Subject: Bird 63.2 -- Date: Tue, 8 Feb 2000 16:39:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Hello All: In preperation for a voting on this BIRD at the upcoming IBIS teleconference (Feb 25), I'm reposting Bird 63.2. Please look it over, and respond with any comments to ibis@eda.org. Regards, Stephen Peters Intel Corp. ---- cut here ----- Buffer Issue Resolution Document (BIRD) BIRD ID#: 63.3 ISSUE TITLE: Documentation of Receiver Setup and Hold Timing Conditions REQUESTOR: D.C. Sessions (Philips), Stephen Peters, Richard Melitz, Arpad Muranyi (Intel Corp.) DATE SUBMITTED: Sept 8, 1999, Dec 27, 1999, Jan 6, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: **************************************************************************** *** **************************************************************************** *** STATEMENT OF THE ISSUE: Currently, the edge rate and overdrive conditions under which a receiver's data book setup and hold timings are specified are not documented. This bird provides a way for the model creator to document those conditions in an IBIS file. **************************************************************************** *** STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Receiver Threshold] keyword. |=========================================================================== == | Keyword: [Tester Spec] | Required: No | Sub-Params: Tester_Vlow, Tester_Vhigh, Tester_Vth, Tester_Slew_Setup, | Tester_Slew_Hold | Description: The [Tester Spec] keyword documents the input overdrive | and tester slew rate conditions under which a device's | input setup and hold times are specified. The subparameters | are defined as follows: | | Tester_Vth is the point on the input waveform from | which an receivers setup and hold time is referenced. It is | usually the input voltage at which the output of a digital | logic receiver changes state. Tester_Vth is used as the | reference voltage for the Tester_Vlow and Tester_Vhigh | parameters. | | Tester_Vlow represents the starting voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the ending voltage of a | high-to-low going waveform. Tester_Vlow is expressed as an | offset from Tester_Vth. | | Tester_Vhigh represents the ending voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the starting voltage of | a high-to-low going waveform. Tester_Vhigh is expressed as an | offset from Tester_Vth. | | Tester_Slew_Setup is the tester waveform's slew rate at | which a receiver's setup time is specified. For purposes of | this keyword, slew rate is defined as: | | Tester_Vhigh - (Tester_Vlow) | Slew Rate = ------------------------------------------- | Time it takes to swing the above voltage | | Tester_Slew_Setup must be expressed as an explicit ratio | of voltage over time, and not reduced to a decimal number. | | Tester_Slew_Hold is the tester waveform's slew rate at which | a receiver's hold time is specified. Slew rate is defined | as above. Tester_Slew_Hold must be expressed as an explicit | ratio of voltage over time, and not reduced to a decimal | number. | | | Usage Rules: The [Tester Spec] keyword is valid if the model type | includes any reference to input or I/O. All subparameters | are required to be present. When entering a numeric value the | subparameter argument and the subparameter itself must | be separated by an equals sign (=). The argument to the | Tester_Skew_* subparameter must be seperated from the | subparameter itself by a white space. | | Differential Receivers: | For a single ended receiver the numerical value of | Tester_Vth is specified with respect to 0v. However, if | the [Tester Spec] keyword is describing a differential receiver | (i.e. is part of a [Model] statement that describes a pin | listed in the [Diff Pin] keyword), then the numerical value of | Tester_Vth is typically given as 0v. Tester_Vlow and | Tester_Vhigh are then assumed to represent the difference in | voltage between one input and the other. | | | A basic 3.3v single ended receiver Tester_Vth = 1.5v Tester_Vlow = -1.0v Tester_Vhigh = 2.5v Tester_Slew_setup 1v/ns Tester_Slew_hold 1v/ns | | A differential receiver Tester_Vth = 0V Tester_Vlow = -200mV Tester_Vhigh = +200mV Tester_Slew_setup 1.2v/1ns Tester_Slew_hold 1.2v/1ns | | **************************************************************************** *** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Like it's companion BIRD #62, this bird is an attempt to better specify and document a receiver's functionality. It follows the convention of the previous BIRDS in that most of the parameter values are specified as an offset from a reference voltage. This technique supports both single ended and differential receivers. Note that there are separate slew rate entries for setup and hold time. When formulating this bird the authors were not sure if receiver hold time was specified under different slew rate conditions than setup time. Thus, separate slew rate entries. These two parameters can be collapsed into one if further information indicates that this is not the case. Updates for 63.1: Corrected "Tester_Skew" to "Tester_Slew" in the examples (typo correction) and fixed up the Slew_rate equation by removing the absolute value markers. Changed Slew_rate so that it is expressed as an explicit ratio and not as a decimal (following the convention of [Ramp Rate]). Clarified the meaning of Tester_Vth. Finally, under "Differential Receivers:" changed the text to indicate that the numerical value of Tester_Vth is *typically* given as 0v rather than *must* be given as zero. Updates for 63.2: Syntax correction -- the argument to the Tester_Slew_* parameter should be seperated from the subparameter by white space, not an equals sign (it's a non-numeric argument). Corrected examples. **************************************************************************** *** ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Melitz and Aprad Muranyi of Intel Corp. **************************************************************************** *** From owner-ibis Wed Feb 9 16:48:02 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA10336 for ; Wed, 9 Feb 2000 16:48:01 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA26476; Wed, 9 Feb 2000 16:46:23 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id QAA14533; Wed, 9 Feb 2000 16:46:21 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <38A20A5E.B3EEFAF4@mentor.com> Date: Wed, 09 Feb 2000 16:46:22 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS BIRD63.2 Comments/Questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To Stephen Peters and IBIS Committee: I am finally starting to look at BIRD62.2 and BIRD63.2 and have these comments. My first comments are on BIRD63.2. Bob Ross Mentor Graphics 1. In general, I have problems with any slew rate definition. We have already mis-used it for the [Ramp] keyword where the only meaningful portion is dt, and we interpret it as the 20% to 80% value. The BIRD63.2 definition is (Tester_Vhigh - Tester_Vlow) / (deltaT for the above tester voltages) Presumably, these values are unreduced 0% to 100%. According to SSTL-2, for 2.5 V, EIA/JESD8-9, Sept. 1998, pg. 4, Slew = (VIHmin(ac) - VILmax(ac)) / (deltaT for the above (ac) voltages) where the delta ac voltage could fall inside the delta tester voltage according to the diagram. This would produce a different unreduced values _______ Tester_Vhigh / /<- VIHmin(ac) / /<- VILmax(ac) Tester_Vlow ____/ Does JEDEC have an official definition of slew rate? Where do you get the Tester_Vhigh and Tester_Vlow values if they are not the (ac) values? Are they documented in data sheets? If Tester_Vhigh and Tester_Vlow are given, then the numerator is redundant - a source of error. The 0% to 100% interpretation is inconsistent with the [Ramp] intepretation and also with a potential connector model interpretation. 2. According to the JEDEC document, the slew rate is a minimum value (i.e., faster signals are allowed). Should this be noted? 3. Should the Tester_Vhigh and Tester_Vlow values be deltas from Tester_Vref to be consistent with the BIRD62.2 subparameters? Tester_Vlow is listed as -1.0 V in the first example. 4. I do not like mixing differential and single-ended definitions by value. A new subparameter should to be defined if the Vth is to be interpreted for differential operation. I presume it is possible for a particular buffer in some technology to be used both in differential and single-ended mode. Sometimes simulators can control whether single-ended or differential is used. The differential example has the Tester_Vlow and Tester_Vhigh voltages relative to the differential voltage - an inconsistency. The slew rate voltage does not conform to the slew rate definition in the differential example. Is this intential? - is it always a single ended definition? 5. Cosmetic: I would prefer the proposed Sub-Parameter names to be the following: Vth_tester Vhigh_tester Vlow_tester Slew_setup_tester Slew_hold_tester etc. for the following consistency reason. So far, all of the subparameters of IBIS which are of the form: Xxxx_qqq = numerical value or Yyyy_zzz word follow the format of uppercase first letter and lower case remaining letters (e.g., Si_location, R_pkg, Model_type, R_fixture, V_fixture_min, S_overshoot_high, etc.) Moving V as the first letter gives the major definition of the subparameter and preserves this convention. We still remain case sensitive, so having a consistent convention is important. This was violated in BIRD63.2 where Tester_Slew_Setup was defined, but Tester_Slew_setup was used in the examples. So you see the problem. 6. Under Usage rules, Tester_Skew_* is used instead of "slew". From owner-ibis Wed Feb 9 16:54:11 2000 Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA10353 for ; Wed, 9 Feb 2000 16:54:10 -0800 (PST) Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA00992 for ; Wed, 9 Feb 2000 16:52:32 -0800 (PST) Message-Id: <200002100052.QAA00992@jasper.cisco.com> Date: Wed, 9 Feb 2000 16:52:32 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: about BIRD63.3 example To: ibis@eda.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CmTll6R4ipEPusUQJBWTXw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc IBISfans: I am looking at the 3.3v single ended receiver example in BIRD63.3 and here is the question: ----- example ----> . . | | A basic 3.3v single ended receiver Tester_Vth = 1.5v Tester_Vlow = -1.0v Tester_Vhigh = 2.5v Tester_Slew_setup 1v/ns Tester_Slew_hold 1v/ns . . Q) Since Tester_Vhigh is expressed as offset from Tester_Vth, should the value of Tester_Vhigh be 1.0 instead of 2.5v in the 3.3v example ? Regards, Syed Cisco Systems, Inc From owner-ibis Wed Feb 9 21:44:24 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id VAA11027 for ; Wed, 9 Feb 2000 21:44:19 -0800 (PST) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id VAA13800 for ; Wed, 9 Feb 2000 21:43:10 -0800 (PST) Received: from cadence.com (annex-chelmsford-20 [158.140.101.210]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id AAA07214 for ; Thu, 10 Feb 2000 00:42:01 -0500 (EST) Message-ID: <38A24FD8.69B7D31C@cadence.com> Date: Thu, 10 Feb 2000 00:42:48 -0500 From: Mike LaBonte Organization: Cadence Design Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: ibis@eda.org Subject: Re: IBIS BIRD63.2 Comments/Questions References: <38A20A5E.B3EEFAF4@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as VAA13800 at Wed Feb 9 21:43:10 2000 BIRD 63.2 covers a way to document the input signal conditions under which a receiver's data book setup and hold timings are specified. But I do not see sufficient discussion concerning how an analysis tool is expected to use this information. For example, if a particular simulation shows an input signal that differs radically from the conditions under which Tsetup and Thold are specified, are we supposed to somehow compensate? If there were multiple values of Tsetup and Thold each with a specification of input conditions, then the analysis tool could adjust the Tsetup and Thold values based on the input conditions seen. If this BIRD somehow ties to BIRD 61.1, then this should be stated. Maybe I will understand it once I read all of these new BIRDs. Mike From owner-ibis Thu Feb 10 15:40:31 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA15208 for ; Thu, 10 Feb 2000 15:39:27 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA09480; Thu, 10 Feb 2000 15:32:02 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA07540; Thu, 10 Feb 2000 15:32:01 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <38A34A70.1CDE055C@mentor.com> Date: Thu, 10 Feb 2000 15:32:00 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS BIRD62.2 Comments and Questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: Here are some BIRD62.2 comments and questions. These comments still suggest preserving the technical content of BIRD62.2 Bob Ross Mentor Graphics 1. General: JEDEC provideds some specific parameters for component specification. There are a lot of interacting sensitivities and tolerances. How should designers use them in real designs, and what should EDA tools do with them for two situations? Below is one approach. Is there a more simple way of using these parameters? Reference Supply reference: Vinh_ac, Vinh_dc, Vinl_dc, Vinl_ac referenced to these Vth calculations for typ, min, and max column corner analysis: Typ: 1 test: Vth Min: 2 tests: Vth_min scaled to MIN voltage reference Vth_max scaled to MIN voltage reference Max 2 tests: Vth_min scaled to MAX voltage reference Vth_max scaled to MAX voltage reference External Supply reference: Vinh_ac, Vinh_dc, Vinl_dc, Vinl_ac referenced to these Vth calculations for typ, min, and max column corner analysis: Typ: 1 test: Vth Min: 2 tests: Vth_min scaled to MIN external reference Vth_max scaled to MAX external voltage reference Max 2 tests: Vth_min scaled to MIN external reference Vth_max scaled to MAX external reference The remaining questions address some details. 2. Does JEDEC expect these parameters to be defined at the die or at the pin? Are they insensitive to ground and power bounce effects if Vref is tied to VDDQ? 3. Input_Ref_Supply. If a supply is given, then the syntax should support all four available references Power_clamp_ref Gnd_clamp_ref Pullup_ref Pulldown_ref Ext_ref These are more explicit references. The [Pin Mapping] keyword already sets the precedence that the explicit power rails should be named. VOLTAGE_RANGE can be ambiguous and should not be used since Pullup_ref and/or Power_clamp_ref functionally can override voltage range if all/either are given. For input structures, normally the power clamp reference might be used, not the pullup reference. The pullup reference might not be defined. 3. Generally I do not like mixing differential and single-ended specifications because it might be possible to have the external reference at 0 V and also some devices can be configured as single-ended or differential. 4. The [External Reference] keyword discription should have some additional text clarifying that the min and max columns DO NOT correspond to the [Model] min and max columns for the I-V and V-T tables. The entries in these columns are the min and max values of the external reference by magnitude. 5. Cosmetic: These would be my preferences for notation "consistency" throughout IBIS: Change Input_Ref_Supply to Input_ref_supply or to another name such as Reference_supply Change Ext to Ext_ref and use mixed case names suggested above Power_clamp_ref Gnd_clamp_ref Pullup_ref Pulldown_ref to be consistent with other "selections" in IBIS such as Open_drain, 3-state, Bus_hold, etc. The Vth_min and Vth_max notation of min and max may be confusing since the usage of min and max is different. It is really used as a plus and minus delta value for TYPICAL conditions from the Vth value under TYPICAL conditions. Delta values consistent with delta entries for Vinh_ac could be considered, although that would change the Vth(min/max) formula. Or,the actual values could still be used, but the name changed to Vth_upper, Vth_lower. There are just suggestions for consideration. From owner-ibis Wed Feb 16 16:18:28 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA01674; Wed, 16 Feb 2000 16:18:27 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA24130; Wed, 16 Feb 2000 16:16:46 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id QAA27518; Wed, 16 Feb 2000 16:16:45 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <38AB3DED.80EA64A5@mentor.com> Date: Wed, 16 Feb 2000 16:16:45 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-request@eda.org, si-list@silab.eng.sun.com Subject: IBIS EUROPEAN SUMMIT MEETING SECOND ANNOUNCEMENT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit E U R O P E A N I B I S S U M M I T M E E T I N G S E C O N D A N N O U N C E M E N T Time/Date: 8:30 AM - 2 PM, Friday, March 31, 2000 Location: Concorde-Lafayette Hotel (adjacent to Le Palais des Congress de Paris Porte Mailot - site of the DATE2000 Conference in Paris, France Rooms: Salon, Van Gogh, Pissarro Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: Cadence, INCASES, Mentor Graphics and Viewlogic DATE2000: March 27-30, 2000. The IBIS meeting is scheduled the day following the trade show portion of the Conference and the PCB Symposium. See http://www.date-conference.com for more information. BACKGROUND For the last several years we have been holding very successful European IBIS Summit Meetings. We plan a combination of the following: Submitted Presentations on IBIS Topics (See below) Less formal Ad Hoc Presentations and Discussions IBIS Questions and Answers TENTATIVE AGENDA SO FAR (titles may change) Agenda includes presentations, discussions and a free lunch. Some presentations planned so far include: Siemens IBIS Modeling Requirements for Semiconductor Vendors Gerald Bannert, Siemens IEC EMC/EMI Standardization Update Jean Claude Perrin, Texas Instruments IBIS Accuracy Study Sherif Hammad, Mentor Graphics Behavioral Receiver Modeling Patrick Dos Santos, Cadence Design Systems CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate in the European IBIS Summit meeting. If you plan to participate, please supply the information below: Name: E-mail address: Company: Telephone: Send to: Karine Loudet (karine_loudet@mentor.com) +33 1 40 94 74 54 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Some suggested subjects of interest are: IBIS Model Development Experiences Company IBIS Standards and Requirements Generating and Validating IBIS Models Future IBIS Requirements EMC/EMI IBIS 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. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Bob Ross (bob_ross@mentor.com) FOR FURTHER INFORMATION: Bob Ross, Chair, EIA/IBIS Open Forum Mentor Graphics 8005 S.W. Boeckman Road Wilsonville, Oregon 97070 USA (503) 685-0732 bob_ross@mentor.com From owner-ibis Thu Feb 17 10:46:43 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA05673 for ; Thu, 17 Feb 2000 10:46:42 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA26854; Thu, 17 Feb 2000 10:45:02 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA10426; Thu, 17 Feb 2000 10:45:00 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <38AC41AD.73D6CEF0@mentor.com> Date: Thu, 17 Feb 2000 10:45:01 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS MEETING AGENDA 2/25/00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 2/25/00 Bridge Number Reservation # Passcode (916) 356-9200 4-299297 3855864 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 Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) Perrin - JEDEC JC-16.2 Modeling and Testing Sessions DesignCon2000 IBIS Summit Feedback Ross/Schwartz JEDEC/IBIS Working Group Meeting Report Sessions/Ross DATE2000 IBIS Summit Planning Ross Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 8:45 Technical Discussion (some topics may be deferred) BIRD62.2 - Enhanced Chararcterization of Receiver Peters Thresholds (Vote) BIRD63.2 - Documentation of Receiver Setup and Hold Peters Timing Conditions (Vote) BIRD66 - [Model Spec] Vref Addition McMorrow/Ross Connector Proposal Review (Continued) Panella/Chrisafulli IBIS Futures Group Report (IBIS-X, API, BIRDxx) Peters BIRD61.1 - Enhanced Characterization of Receivers Peters BIRD64.1 - Package Model Selector Muranyi BIRD65 - C_comp Refinements Muranyi ibischk3 Bug Tracking Ross - BUG34 - No Error Reported for Missing V/I Tables Flora in Output Buffers - Repeated Voltage - 8.3 Version 2.1 Error - Series element does not work with I/O models New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Fri Feb 18 05:49:45 2000 Received: from g23.relcom.ru (g23.relcom.ru [193.125.152.117]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA14810 for ; Fri, 18 Feb 2000 05:49:43 -0800 (PST) Received: from d217.z194-58-100.relcom.ru (d217.z194-58-100.relcom.ru [194.58.100.217]) by g23.relcom.ru (8.8.8/Relcom-2A) with SMTP id QAA22394 ;Fri, 18 Feb 2000 16:33:16 +0300 (MSK) Message-ID: <000801bf7a14$8c890db0$d9643ac2@gena> From: "Gennadiy" To: Cc: Subject: ICS Date: Fri, 18 Feb 2000 16:31:11 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BF7A2D.913BDE00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF7A2D.913BDE00 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi Gentlemen, I've developed program ICS (IBIS Circuit Simulator), harmonic balance = engine for simulations of connections of digital integrated circuits. = The driver is given by IBIS model. ICS allows using S-parameters of elements (transmission lines, for = example) in simulations of the connections. S-parameters may be measured = or EM simulated. ICS has open library of elements. If anybody is interested in this program write me please. Best regards, Gennadiy ------=_NextPart_000_0005_01BF7A2D.913BDE00 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Hi Gentlemen,

I’ve developed program ICS (IBIS Circuit = Simulator),=20 harmonic balance engine for simulations of connections of digital = integrated=20 circuits. The driver is given by IBIS model.

ICS allows using S-parameters of elements = (transmission lines,=20 for example) in simulations of the connections. S-parameters may be = measured or=20 EM simulated. ICS has open library of elements.

If anybody is interested in this program write me = please.

Best regards,

Gennadiy

------=_NextPart_000_0005_01BF7A2D.913BDE00-- From owner-ibis Fri Feb 18 13:45:58 2000 Received: from osiris.vlsi.com (relayhost.vlsi.com [63.194.140.25]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA19330 for ; Fri, 18 Feb 2000 13:45:57 -0800 (PST) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id NAA12201; Fri, 18 Feb 2000 13:44:46 -0800 (PST) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris via smap (V2.0) id xma012188; Fri, 18 Feb 00 13:44:41 -0800 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id FAGHH6SS; Fri, 18 Feb 2000 14:43:50 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <38ADBD48.FDAC5ECC@vlsi.com> Date: Fri, 18 Feb 2000 14:44:40 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bob Ross CC: ibis@eda.org Subject: Re: IBIS BIRD62.2 Comments and Questions References: <38A34A70.1CDE055C@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Ross wrote: > The remaining questions address some details. > > 2. Does JEDEC expect these parameters to be defined > at the die or at the pin? Are they insensitive to > ground and power bounce effects if Vref is tied to > VDDQ? JEDEC, like IBIS, is focused on observable-at-the-pin parameters. The threshold guardbands provide room for the manufacturer to include noise margins. Someday, this is likely to change from sheer necessity. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Fri Feb 18 13:56:40 2000 Received: from osiris.vlsi.com (relayhost.vlsi.com [63.194.140.25]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA19414 for ; Fri, 18 Feb 2000 13:56:39 -0800 (PST) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id NAA12540; Fri, 18 Feb 2000 13:55:27 -0800 (PST) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris via smap (V2.0) id xma012531; Fri, 18 Feb 00 13:55:02 -0800 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id FAGHH6TB; Fri, 18 Feb 2000 14:54:11 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <38ADBFB5.8A6562ED@vlsi.com> Date: Fri, 18 Feb 2000 14:55:01 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Mike LaBonte CC: ibis@eda.org Subject: Re: IBIS BIRD63.2 Comments/Questions References: <38A20A5E.B3EEFAF4@mentor.com> <38A24FD8.69B7D31C@cadence.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike LaBonte wrote: > > BIRD 63.2 covers a way to document the input signal conditions under > which a receiver's data book setup and hold timings are specified. But I > do not see sufficient discussion concerning how an analysis tool is > expected to use this information. > > For example, if a particular simulation shows an input signal that > differs radically from the conditions under which Tsetup and Thold are > specified, are we supposed to somehow compensate? If there were multiple > values of Tsetup and Thold each with a specification of input > conditions, then the analysis tool could adjust the Tsetup and Thold > values based on the input conditions seen. > > If this BIRD somehow ties to BIRD 61.1, then this should be stated. > Maybe I will understand it once I read all of these new BIRDs. At the very least, it provides a correlation point for closing the timing analysis if the input waveforms DO match the criteria. Which was not explicit before. (How often have we seen customers measure input transitions at 0.8v and 2.0v regardless of reality?) And, yes, BIRD 61.x is an attempt to define the response to nonideal inputs. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Fri Feb 18 13:02:07 2000 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA19162; Fri, 18 Feb 2000 13:02:06 -0800 (PST) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id NAA15612; Fri, 18 Feb 2000 13:00:55 -0800 (PST) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 18 Feb 2000 21:00:53 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Feb 2000 13:00:51 -0800 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C04069A3F@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis@eda.org'" , "'ibis-users@eda.org'" Subject: Bird 62.3 -- Enhanced Specification of Receiver Thresholds Date: Fri, 18 Feb 2000 13:00:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Hello All: In response to Bob Ross's comments I have updated Bird 62 to 62.3. In brief, the subparameter Input_ref_supply has been changed to Reference_supply and the list of allowable arguments has been expanded. Also, to address Bob's concern about specifing differential recievers, I've added four new subparameters specifically for this case. These parameters specificy difference voltage and the minimum and maximum allowable input cross points when switching. Please read and be prepared to discuss this BIRD at the next phone conference. Regards, Stephen Peters Intel Corp. ====================== Buffer Issue Resolution Document (BIRD) BIRD ID#: 62.3 ISSUE TITLE: Enhanced Specification of Receiver Thresholds REQUESTER: DC Sessions (Philips), Stephen Peters, Richard Mellitz, Arpad Muranyi (Intel Corp). DATE SUBMITTED: Aug 24, 1999, Dec 28, 1999, Jan 6, 2000, Feb 18, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: **************************************************************************** *** **************************************************************************** *** STATEMENT OF THE ISSUE: When specifying receiver input thresholds the current specification allows only the traditional DC derived Vinh and Vinl parameters. These two parameters are no longer adequate for describing receivers used for high speed designs. This BIRD proposes four new input switching threshold parameters: Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc. These parameters are referenced to an reference point Vth, and this reference is allowed to vary with variations in a supply. **************************************************************************** *** STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Model Spec] keyword. |=========================================================================== == | Keyword: [Receiver Thresholds] | Required: No | Sub-Params: Vth, Vth_min, Vth_max, Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc, | Vth_sensitivity, Reference_supply, Vcross_min, Vcross_max, | Vdiff_ac, Vdiff_dc | Description: The [Receiver Thresholds] keyword defines both a set of | receiver input thresholds as well as their sensitivity to | variations in a referenced supply. The subparameters are | defined as follows: | | Vth, Vth_min and Vth_max is the ideal input threshold voltage | at which the output of a digital logic receiver changes state. | Vth is the nominal input threshold voltage under the voltage, | temperature and process conditions that define 'typ'. Vth_min | is the minimum input threshold voltage at 'typ' conditions | while Vth_max is the maximum input threshold voltage at 'typ' | conditions. | | Vinh_ac is the voltage that a low-to-high going input waveform | must reach in order to guarantee that the receiver's output | has changed state. In other words, reaching Vinh_ac is | sufficient to guarantee a receiver state change. Vinh_ac is | expressed as an offset from Vth. | | Vinh_dc is the voltage that an input waveform must remain | above (more positive than) in order to guarantee that a | receiver output will NOT change state. Vinh_dc is expressed | as an offset from Vth. | | Vinl_ac is the voltage that a high-to-low going input waveform | must reach in order to guarantee that the receiver's output | has changed state. In other words, reaching Vinl_ac is | sufficient to guarantee a receiver state change. Vinl_ac | is expressed as an offset from Vth. | | Vinl_dc is the voltage that an input waveform must remain below | (more negative than) in order to guarantee that a receiver's | output will NOT change state. Vinh_dc is expressed as a | offset from Vth. | | Vth_sensitivity is a unit less number that specifies how Vth | varies with respect to the supply voltage defined by the | Reference_supply subparameter. Vth_sensitivity is defined | as: | | change in input threshold voltage | Vth_sensitivity = ------------------------------------ | change in referenced supply voltage | | Vth_sensitivity must be entered as a whole number or | decimal, not as a fraction. | | Reference_supply indicates which supply voltage Vth tracks; | i.e. it indicates which supply voltage change causes a change | in input threshold. The legal arguments to this subparameter | are as follows: | Power_clamp_ref (the supply voltage defined by the | [POWER Clamp Reference] keyword) | Gnd_clamp_ref (the supply voltage defined by the | [GND Clamp Reference] keyword) | Pullup_ref (the supply voltage defined by the | [Pullup reference] keyword) | Pulldown_ref (the supply voltage defined by the | [Pulldown reference] keyword) | Ext_ref (the supply voltage defined by the | [External Reference] keyword) | | | | Vcross_min is the minimum voltage at which a differential | receivers' input signals may cross while switching and | still allow the receiver to meet its timing and functional | specifications. Vcross_min is specified with respect to | 0V. | | Vcross_max is the maximum voltage at which a differential | receivers' input signals may cross while switching and | still allow the receiver to meet its timing and functional | specifications. Vcross_max is specified with respect to | 0V. | | Vdiff_dc is the minimum voltage difference between the | inputs of a differential receiver that guarantees the | receiver will not change state. | | Vdiff_ac is the minimum voltage difference between the | inputs of a differential receiver that guarantees the | receiver will change state. | | | | Usage Rules: The [Receiver Thresholds] keyword is valid if the model type | includes any reference to input or I/O. For single ended | receivers the Vinh_ac, Vinh_dc, Vinl_ac, Vinh_dc and Vth | subparameters are required and override the Vinh, Vinl, | Vinh+/- and Vinl+/- subparameters declared under the | [Model] or [Model Spec] keywords. For single ended | receivers the Vth_min, Vth_max, Vth_sensitivity and | Reference_supply subparameters are optional. However, if | the Vth_sensitivity subparameter is present then the | Reference_supply subparameter must also be present. | | For differential receivers (i.e. the [Receiver Threshold] | keyword is part of a [Model] statement that describes a pin | listed in the [Diff Pin] keyword) then the Vcross_min, | Vcross_max, Vdiff_ac and Vdiff_dc subparameters are | required. The rest of the subparameters are not applicable to | differential receivers so are not used. The Vdiff_ac | Vdiff_dc values override the value of the Vdiff | subparameter specified by the [Diff Pin] keyword. Note | that Vcross_min and Vcross_max are valid over the devices | minimum and maximum operating conditions, and correspond | to the 'min' and 'max' columns used in the I-V and V-T | curves. | | Subparameter Usage Rules: | Numerical arguments are separated from their associated | subparameter by an equals sign (=); white space around the | equals sign is optional. The argument to the | Reference_supply subparameter is separated from the | subparameter by white space. | | Vth at Minimum or Maximum Operating Conditions: | As described above, the Vth_min and Vth_max subparameters | define the minimum and maximum input threshold values under | typical operating conditions. There is no provision for | directly specifying Vth under minimum or maximum operating | conditions. Instead, these values are calculated using | the following equation: | | Vth(min/max) = Vth* + [(Vth_sensitivity) X (change in supply voltage)] | | where Vth* is either Vth, Vth_min or Vth_max as appropriate, | and the supply voltage is the one indicated by the | Reference_Supply subparameter. | | | | Examples: | | A basic 3.3v single ended receiver using only the required | subparameters | Vth = 1.5v Vinh_ac = +225mV Vinh_dc = +100mV Vinl_ac = -225mV Vinl_dc = -100mV | | | A single ended receiver using an external threshold reference. In this | case the input threshold is the external reference voltage so | Vth_sensitivity equals 1. | Vth = 1.0v Vth_sensitivity = 1 Reference_Supply Ext_ref Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | | A fully specified single ended 3.3v CMOS receiver | Vth = 1.5v Vth_min = 1.45v Vth_max = 1.53v Vth_sensitivity = 0.45 Reference_supply Power_clamp_ref Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | | A differential receiver | Vcross_min = 0.65V Vcross_max = 0.90v Vdiff_ac = +200mv Vdiff_dc = +100mV 2) The following new keyword is defined and place in the specification following the [GND Clamp Reference] keyword |=========================================================================== == | Keyword: [External Reference] | Required: Yes, if a receiver's input threshold is determined by an | external reference voltage | Description: Defines a voltage source that supplies the reference voltage | used by a receiver for its input threshold reference. | Usage Notes: Provide actual voltages (not percentages in the typ, min max | format. "NA" is allowed for the min and max values only. | Note that the numerically largest value should be placed in | 'max' column, while the numerically smallest value should | be placed in the 'min' column. | |--------------------------------------------------------------------------- -- | variable typ min max [External Reference] 1.0v 0.95v 1.05v 3) Under section 2 of General Syntax Rules and Guidelines the following words are added to the list of reserved words. Ext_ref - A reference to a voltage defined by the [External Reference] Keyword Power_clamp_ref - A reference to a voltage defined by the [POWER Clamp Reference] keyword Gnd_clamp_ref - A reference to a voltage defined by the [GND Clamp Reference] keyword Pullup_ref - A reference to a voltage defined by the [Pullup Reference] keyword Pulldown_ref - A reference to a voltage defined by the [Pulldown Reference] keyword **************************************************************************** ** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This proposal follows the recommendations of the JC-15 committee for specifying SDRAM inputs. Update for 62.1: Specified exactly which [Model] and [Model Spec] parameters are overridden by [Receiver Threshold] and changed the wording of the "Differential Receivers:" to indicate that the numerical value of Vth is *typically* assigned a value of 0v rather than *must* be assigned a value of zero. Update for 62.2 Under Usage Rules: added the section (Subparameter Usage Rules:) describing the syntax rules for separating arguments from subparameters. Updated examples with this change. Update for 62.3 The subparameter Input_Ref_Supply was renamed to Reference_supply (this is to be consistent with other subparameter names). The list of arguments to the Reference_supply subparameter was expanded and clarified. A note was added to the [External Reference] keyword clarifying which values go in the min and max columns of this keyword. Finally, four new subparameters that describe differential receivers were added. **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Mellitz and Arpad Muranyi of Intel Corp. **************************************************************************** *** From owner-ibis Mon Feb 21 14:58:45 2000 Received: from qhars001.nortel.com (qhars001.NortelNetworks.com [192.100.101.18]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA17373 for ; Mon, 21 Feb 2000 14:58:44 -0800 (PST) Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com; Mon, 21 Feb 2000 22:57:03 +0000 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 21 Feb 2000 16:56:44 -0600 Received: from zmerd004.ca.nortel.com ([47.124.0.133]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FKDC63QY; Mon, 21 Feb 2000 17:56:36 -0500 Received: from americasm01.nt.com (wkpks00e.ca.nortel.com [47.125.49.19]) by zmerd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DZBZG3Z0; Mon, 21 Feb 2000 17:56:35 -0500 Sender: "Cass Russett" Message-ID: <38B1C2A3.8C32A70D@americasm01.nt.com> Date: Mon, 21 Feb 2000 17:56:35 -0500 From: "Cass Russett" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ibis@eda.org" Subject: Signal Integrity/IBIS Training Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I am interested in attending a training class focusing on IBIS model development and/or high speed board level signal integrity. The signal integrity class should ideally be tool-independent and targeted to engineers requiring more than a "rule of thumb" understanding of the issues.

Any recommendations would be appreciated,
Cass
--
Cass Russett
OPTera Packet Core Hardware Development -- Terabit Optical Router
Nortel Networks, Skypark Facility, Ottawa, ON, Canada
Email: crussett@nortelnetworks.com, Phone: (613) 765-8663, FAX: (613) 765-3552

  From owner-ibis Tue Feb 22 09:29:52 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA22012 for ; Tue, 22 Feb 2000 09:29:51 -0800 (PST) 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.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id RAA03950 for ; Tue, 22 Feb 2000 17:29:19 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 22 Feb 2000 17:28:39 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Feb 2000 09:28:38 -0800 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C04069A42@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis@eda.org'" Subject: Bird63.3 -- Documentation of receiver setup and hold conditions Date: Tue, 22 Feb 2000 09:28:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hello All: In response to Bob's comments here is an updated Bird 63. In brief, major changes include renaming the Tester_slew_rate parameter to Edge_rate, and specifying edge rate over the 20% to 80% voltage swing. In addition, for differential receivers the Vth_tester parameter now represents the cross point of the two differential signals and does not have to be set to any specific voltage. Both the bird (BIRD 63) and BIRD 62 will be up for discussion at this Friday's meeting. Regards, Stephen Peters Intel Corp. ==================================== Buffer Issue Resolution Document (BIRD) BIRD ID#: 63.3 ISSUE TITLE: Documentation of Receiver Setup and Hold Timing Conditions REQUESTOR: D.C. Sessions (Philips), Stephen Peters, Richard Mellitz, Arpad Muranyi (Intel Corp.) DATE SUBMITTED: Sept 8, 1999, Dec 27, 1999, Jan 6, 2000, Feb 17, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: **************************************************************************** * **************************************************************************** * STATEMENT OF THE ISSUE: Currently, the edge rate and overdrive conditions under which a receiver's data book setup and hold timings are specified are not documented. This bird provides a way for the model creator to document those conditions in an IBIS file. **************************************************************************** * STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Receiver Threshold] keyword. |=========================================================================== = | Keyword: [Tester Spec] | Required: No | Sub-Params: Vlow_tester, Vhigh_tester, Vth_tester, Edge_rate_setup, | Edge_rate_hold | Description: The [Tester Spec] keyword documents the input overdrive | and waveform edge rate conditions under which a device's | input setup and hold times are specified. The subparameters | are defined as follows: | | Vth_tester is the point on the input waveform from which | a receivers' setup and hold time is referenced. It is | usually the input voltage at which the output of a digital | logic receiver changes state. Vth_tester is used as the | reference voltage for the Vlow_tester and Vhigh_tester | parameters. For a differential receiver Vth_tester represents | the voltage point at which the true and complement input | waveforms cross. | | Vlow_tester represents the starting voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the ending voltage of a | high-to-low going waveform. Vlow_tester is expressed as an | offset from Vth_tester. | | Vhigh_tester represents the ending voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the starting voltage of | a high-to-low going waveform. Vhigh_tester is expressed as an | offset from Vth_teseter. | | Edge_rate_setup is the slope of the input waveform used when | specifying a receivers setup time. The slope must be valid | over the 20% to 80% points of the input voltage swing and is | calculated as follows: | | | (Vhigh_tester - Vlow_tester) X 0.6 | Edge_rate_* = ------------------------------------------ | time it takes to swing the above voltage | | Edge_rate_hold is the slope of the input waveform used when | specifying a receivers hold time. The slope must be valid | over the 20% to 80% points of the input voltage swing and is | calculated as shown above: | | Both Edge_rate_setup and Edge_rate_hold must be entered as | an unreduced fraction, with the numerator representing the | actual deltaV and the denominator representing the actual | deltaT. | | Usage Rules: The [Tester Spec] keyword is valid if the model type | includes any reference to input or I/O. All subparameters | are required to be present. When entering a numeric value the | subparameter argument and the subparameter itself must be | separated by an equals sign (=). The argument to the | Edge_rate_* parameters are separated from the parameter itself | by white space. | | Differential Receivers: | For a differential receiver the input setup and hold times | are specified with respect to the crossing point of the two | input waveforms as one switches L->H and the other switches | H->L. Therefore, if the [Tester Spec] keyword is describing | a differential receiver (i.e. is part of a [Model] statement | that describes a pin listed in the [Diff Pin] keyword), then | the numerical value of Vth_tester is assumed to be the point | at which the two input waveforms (the "true" and "complement" | inputs) cross. As with a single ended receiver, the true and | complement inputs are assumed to switch between Vlow_tester | and Vhigh_tester. | | | A basic 3.3v single ended receiver Vth_tester = 1.5v Vlow_tester = -1.0v Vhigh_tester = 1.0v Edge_rate_setup 1.2v/1.2nS Edge_rate_hold 1.2v/1.2nS | | A 2.5V SSTL receiver Vth_tester = 1.25v Vlow_tester = -0.75v Vhigh_tester = 0.75v Edge_rate_setup 900mv/0.9nS Edge_rate_hold 900mv/0.9nS | | A differential receiver Vth_tester = 0.65v Vlow_tester = -500mV Vhigh_tester = +500mV Slew_rate_setup 600mV/0.36nS Slew_rate_hold 600mV/0.36nS | | **************************************************************************** ** * ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Like it's companion BIRD #62, this bird is an attempt to better specify and document a receiver's functionality. It follows the convention of the previous BIRDS in that most of the parameter values are specified as an offset from a reference voltage. This technique supports both single ended and differential receivers. Note that there are separate slew rate entries for setup and hold time. When formulating this bird the authors were not sure if receiver hold time was specified under different slew rate conditions than setup time. Thus, separate slew rate entries. These two parameters can be collapsed into one if further information indicates that this is not the case. Updates for 63.1: Corrected "Tester_Skew" to "Tester_Slew" in the examples (typo correction) and fixed up the Slew_rate equation by removing the absolute value markers. Changed Slew_rate so that it is expressed as an explicit ratio and not as a decimal (following the convention of [Ramp Rate]). Clarified the meaning of Tester_Vth. Finally, under "Differential Receivers:" changed the text to indicate that the numerical value of Tester_Vth is *typically* given as 0v rather than *must* be given as zero. Updates for 63.2: Syntax correction -- the argument to the Tester_Slew_* parameter should be separated from the subparameter by white space, not an equals sign (it's a non-numeric argument). Corrected examples. Updates for 63.3 Tester_slew_rate (parameter and definition) was replaced by the Edge_rate_* parameter, where edge rate is specified from the 20% to 80% points on the input waveform. Vth_tester for a differential receiver now represents the crossing point of the two input waveforms, which is where the input setup and hold timing for a differential receiver are supposed to be referenced. Subparameter names have been changed to better conform to IBIS usage. **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-16 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Mellitz and Aprad Muranyi of Intel Corp. **************************************************************************** ** From owner-ibis Fri Feb 25 16:36:18 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA12681 for ; Fri, 25 Feb 2000 16:36:18 -0800 (PST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id AAA14939 for ; Sat, 26 Feb 2000 00:35:41 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 26 Feb 2000 00:35:01 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Feb 2000 16:35:00 -0800 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C04069A59@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis@eda.org'" Subject: BIRD 63.4 -- Enhanced Specification of Receiver Thresholds Date: Fri, 25 Feb 2000 16:34:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hello All: Per our converstation at this mornings IBIS teleconference I've updated BIRD 63. In brief, the major change was the addition of the Input_edge_rate subparameter. This subparmeter specified the minimum edge rate conditions under which a receivers setup and hold time specifications are still valid. For a complete list of changes, refer to the ANALYSIS PATH/DATA section at the end. Please read and comment soon, as this bird will be up for a vote at the Mar 17 IBIS Teleconference. Regards, Stephen Peters Intel Corp. ================ Buffer Issue Resolution Document (BIRD) BIRD ID#: 62.4 ISSUE TITLE: Enhanced Specification of Receiver Thresholds REQUESTER: DC Sessions (Philips), Stephen Peters, Richard Mellitz, Arpad Muranyi (Intel Corp). DATE SUBMITTED: Aug 24, 1999, Dec 28, 1999, Jan 6, 2000, Feb 18, 2000, Feb 25, 2000 DATE ACCEPTED BY IBIS OPEN FORUM: **************************************************************************** **************************************************************************** STATEMENT OF THE ISSUE: When specifying receiver input thresholds the current specification allows only the traditional DC derived Vinh and Vinl parameters. These two parameters are no longer adequate for describing receivers used for high speed designs. This BIRD proposes four new input switching threshold parameters: Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc. These parameters are referenced to an reference point Vth, and this reference is allowed to vary with variations in a supply. This bird also provides for specifying differential receivers and minimum edge rates. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Model Spec] keyword. |=========================================================================== | Keyword: [Receiver Thresholds] | Required: No | Sub-Params: Vth, Vth_min, Vth_max, Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc, | Threshold_sensitivity, Reference_supply, Vcross_low, | Vcross_high, Vdiff_ac, Vdiff_dc, Input_edge_rate | Description: The [Receiver Thresholds] keyword defines both a set of | receiver input thresholds as well as their sensitivity to | variations in a referenced supply. The subparameters are | defined as follows: | | Vth, Vth_min and Vth_max are the ideal input threshold | voltages at which the output of a digital logic receiver | changes state. Vth is the nominal input threshold voltage | under the voltage, temperature and process conditions that | define 'typ'. Vth_min is the minimum input threshold | voltage at 'typ' conditions while Vth_max is the maximum | input threshold voltage at 'typ' conditions. | | Vinh_ac is the voltage that a low-to-high going input | waveform must reach in order to guarantee that the | receiver's output has changed state. In other words, | reaching Vinh_ac is sufficient to guarantee a receiver | state change. Vinh_ac is expressed as an offset from Vth. | | Vinh_dc is the voltage that an input waveform must remain | above (more positive than) in order to guarantee that a | receiver output will NOT change state. Vinh_dc is | expressed as an offset from Vth. | | Vinl_ac is the voltage that a high-to-low going input | waveform must reach in order to guarantee that the | receiver's output has changed state. In other words, | reaching Vinl_ac is sufficient to guarantee a receiver | state change. Vinl_ac is expressed as an offset from Vth. | | Vinl_dc is the voltage that an input waveform must remain | below (more negative than) in order to guarantee that a | receiver's output will NOT change state. Vinh_dc is | expressed as an offset from Vth. | | Threshold_sensitivity is a unit less number that specifies | how Vth varies with respect to the supply voltage defined | by the Reference_supply subparameter. Threshold_sensitivity | is defined as: | | change in input threshold voltage | Threshold_sensitivity = ------------------------------------ | change in referenced supply voltage | | Threshold_sensitivity must be entered as a whole number or | decimal, not as a fraction. | | Reference_supply indicates which supply voltage Vth tracks; | i.e. it indicates which supply voltage change causes a | change in input threshold. The legal arguments to this | subparameter are as follows: | Power_clamp_ref (the supply voltage defined by the | [POWER Clamp Reference] keyword) | Gnd_clamp_ref (the supply voltage defined by the | [GND Clamp Reference] keyword) | Pullup_ref (the supply voltage defined by the | [Pullup reference] keyword) | Pulldown_ref (the supply voltage defined by the | [Pulldown reference] keyword) | Ext_ref (the supply voltage defined by the | [External Reference] keyword) | | | Input_edge_rate documents the minimum edge rate condition | under which a device's input setup and hold timings are | valid. For a single ended receiver the input signals | edge rate is measured between Vinh_ac and Vinl_ac, and is | calculated as shown below: | | Vinh_ac - Vinl_ac | Input_edge_rate = ------------------------------------------------ | time in transition between the above two voltages. | | | For a differential receiver the input signals edge rate | is measured across the span of Vdiff_ac, centered around | the crossing point of the two input waveforms. It is | calculated as shown below: | | Vdiff_ac | Input_edge_rate = ------------------------------------------------ | time in transition across the above voltage | | | Input_edge_rate must be entered as an unreduced fraction, | with the numerator representing the actual deltaV and the | denominator representing the actual deltaT. | | Vcross_low is the least positive voltage at which a | differential receivers' input signals may cross while | switching and still allow the receiver to meet its timing | and functional specifications. Vcross_low is specified | with respect to 0V. | | Vcross_high is the most positive voltage at which a | differential receivers' input signals may cross while | switching and still allow the receiver to meet its timing | and functional specifications. Vcross_low is specified | with respect to 0V. | | Vdiff_dc is the minimum voltage difference between the | inputs of a differential receiver that guarantees the | receiver will not change state. | | Vdiff_ac is the minimum voltage difference between the | inputs of a differential receiver that guarantees the | receiver will change state. | | | | Usage Rules: The [Receiver Thresholds] keyword is valid if the model type | includes any reference to input or I/O. For single ended | receivers the Vinh_ac, Vinh_dc, Vinl_ac, Vinh_dc, Vth and | Input_edge_rate subparameters are required and override the | Vinh, Vinl, Vinh+/- and Vinl+/- subparameters declared under | the [Model] or [Model Spec] keywords. For single ended | receivers the Vth_min, Vth_max, Threshold_sensitivity and | Reference_supply subparameters are optional. However, if | the Threshold_sensitivity subparameter is present then the | Reference_supply subparameter must also be present. | | For differential receivers (i.e. the [Receiver Thresholds] | keyword is part of a [Model] statement that describes a pin | listed in the [Diff Pin] keyword) then the Vcross_low, | Vcross_high, Vdiff_ac, Vdiff_dc and Input_edge_rate | subparameters are required. The rest of the subparameters | are not applicable. The Vdiff_ac and Vdiff_dc values | override the value of the Vdiff subparameter specified by | the [Diff Pin] keyword. Note that Vcross_low and | Vcross_high are valid over the device's minimum and maximum | operating conditions, and correspond to the 'min' and 'max' | columns used in the I-V and V-T curves. | | Subparameter Usage Rules: | Numerical arguments are separated from their associated | subparameter by an equals sign (=); white space around the | equals sign is optional. The argument to the | Reference_supply subparameter is separated from the | subparameter by white space. | | Vth at Minimum or Maximum Operating Conditions: | As described above, the Vth_min and Vth_max subparameters | define the minimum and maximum input threshold values under | typical operating conditions. There is no provision for | directly specifying Vth under minimum or maximum operating | conditions. Instead, these values are calculated using | the following equation: | | Vth(min/max) = Vth* + [(Threshold_sensitivity) X | (change in supply voltage)] | | where Vth* is either Vth, Vth_min or Vth_max as appropriate, | and the supply voltage is the one indicated by the | Reference_Supply subparameter. | | | | Examples: | | A basic 3.3v single ended receiver using only the required | subparameters | Vth = 1.5v Vinh_ac = +225mV Vinh_dc = +100mV Vinl_ac = -225mV Vinl_dc = -100mV Input_edge_rate = 450mV/1.5nS | | | A single ended receiver using an external threshold reference. In this | case the input threshold is the external reference voltage so | Threshold_sensitivity equals 1. | Vth = 1.0v Threshold_sensitivity = 1 Reference_Supply Ext_ref Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV Input_edge_rate = 400mV/0.4nS | | | A fully specified single ended 3.3v CMOS receiver | Vth = 1.5v Vth_min = 1.45v Vth_max = 1.53v Threshold_sensitivity = 0.45 Reference_supply Power_clamp_ref Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV Input_edge_rate = 400mV/0.4nS | | | A differential receiver | Vcross_low = 0.65V Vcross_high = 0.90v Vdiff_ac = +200mV Vdiff_dc = +100mV Input_edge_rate = 200mV/0.5nS 2) The following new keyword is defined and place in the specification following the [GND Clamp Reference] keyword |=========================================================================== == | Keyword: [External Reference] | Required: Yes, if a receiver's input threshold is determined by an | external reference voltage | Description: Defines a voltage source that supplies the reference voltage | used by a receiver for its input threshold reference. | Usage Notes: Provide actual voltages (not percentages in the typ, min max | format. "NA" is allowed for the min and max values only. | Note that the numerically largest value should be placed in | 'max' column, while the numerically smallest value should | be placed in the 'min' column. | |-------------------------------------------------------------------------- | variable typ min max [External Reference] 1.0v 0.95v 1.05v *************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This proposal follows the recommendations of the JC-15 committee for specifying SDRAM inputs. Update for 62.1: Specified exactly which [Model] and [Model Spec] parameters are overridden by [Receiver Threshold] and changed the wording of the "Differential Receivers:" to indicate that the numerical value of Vth is *typically* assigned a value of 0v rather than *must* be assigned a value of zero. Update for 62.2 Under Usage Rules: added the section (Subparameter Usage Rules:) describing the syntax rules for separating arguments from subparameters. Updated examples with this change. Update for 62.3 The subparameter Input_Ref_Supply was renamed to Reference_supply (this is to be consistent with other subparameter names). The list of arguments to the Reference_supply subparameter was expanded and clarified. A note was added to the [External Reference] keyword clarifying which values go in the min and max columns of this keyword. Finally, four new subparameters that describe differential receivers were added. Update for 62.4 Renamed Vth_sensitivity to Threshold_sensitivity. Remaned the voltage cross parameters to Vcross_low and Vcross_high. Added the Input_edge_rate subparameter from Bird 63.3. Input_edge_rate now follows the precise JEDEC definition. Finally, removed the section that made the arguments to the Reference_supply subparameter reserved words. They are simply enumerated arguments with a defined value, not reserved words with special meanings. *************************************************************************** ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-16 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Mellitz and Arpad Muranyi of Intel Corp. **************************************************************************** From owner-ibis Fri Feb 25 17:39:27 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA12853 for ; Fri, 25 Feb 2000 17:39:27 -0800 (PST) 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.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id BAA04308 for ; Sat, 26 Feb 2000 01:38:53 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Sat, 26 Feb 2000 01:38:13 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Feb 2000 17:38:12 -0800 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C04069A5D@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'ibis@eda.org'" Subject: BIRD63.4 should be BIRD62.4... Date: Fri, 25 Feb 2000 17:38:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hello All: Arpad Muranyi pointed out that the title of my post should have read BIRD62.4. It's correct in the bird, just not in the subject line. Sorry 'bout any confusion. Regards, Stephen From owner-ibis Mon Feb 28 16:39:11 2000 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA28476 for ; Mon, 28 Feb 2000 16:39:10 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id TAA27127 for ; Mon, 28 Feb 2000 19:37:24 -0500 (EST) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id TAA23400 for ; Mon, 28 Feb 2000 19:37:23 -0500 (EST) Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id QAA13591 for ; Mon, 28 Feb 2000 16:36:09 -0800 (PST) Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4) id QAA05655; Mon, 28 Feb 2000 16:39:17 -0800 Date: Mon, 28 Feb 2000 16:39:17 -0800 From: guy@camarillo.viewlogic.com (Guy de Burgh) Message-Id: <200002290039.QAA05655@f22.viewlogic.com> To: ibis@eda.org Subject: EIA IBIS Open Forum Meeting Minutes (2/25/00) DATE: 2/29/00 SUBJECT: 2/25/00 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2000 PARTICIPANTS LIST: 3Com Roy Leventhal* Agilent (EEsof, etc.) Mark Chang Hewlett Packard Paul Gregory Applied Simulation Technology Raj Raghuram, Norio Matsui, Fred Ballesteri Avanti Nikolai Bannov Cadence Design Mike LaBonte, Todd Westerhoff, Ian Dodd, Donald Telian Cisco Systems Syed Huq, Irfan Elahi, John Fisher Compaq Bob Haller, Peter LaFlamme, Ron Bellomio, Shafier Rahman, Doug Burns Cypress (Rajesh Manapat) EMC Corporation (Fabrizio Zanella), Fairchild Semiconductor Craig Klem H.A.S. Electronics (Haruny Said) HyperLynx (& Pads Software) Matthew Flora*, Kellee Crisafulli, Gene Garat, John Angulo*, Al Davis, Lynne Green IBM Michael Cohen* Incases (Werner Rissiek) Intel Corporation Stephen Peters*, Arpad Muranyi*, Will Hobbs, Richard Mellitz LSI Logic (Larry Barnes) Mentor Graphics (& Veribest) Bob Ross*, Tom Dagostino, Malcolm Ash, Kim Owen Mitsubishi Shahab Ahmed Molex Incorporated Gus Panella* Motorola Ron Werner National Semiconductor Milt Schwartz* North East Systems Associates Edward Sayre, Tony Sinker NEC (Hiroshi Matsumoto) Nortel Networks Steve Coe Philips Semiconductor D.C. Sessions* (& VLSI Technology) Quantic EMC (Mike Ventham) Siemens Bernhard Unger SiQual Scott McMorrow, Wis Macomson Texas Instruments Stephen Nolan*, Ramzi Ammar, Mac McCaughey, Thomas Fisher Time Domain Analysis Systems Dima Smolyansky, Steven Corey Via Technologies (Weber Chuang) Viewlogic Systems Chris Rokusek, Guy de Burgh, Jun Tian, (Jon Powell) OTHER PARTICIPANTS IN 2000: Actel Corp. Silvia Montoya Advansis Mikio Kiyono Brocade Communications Robert Badal EIA Cecilia Fleming* Jet Propulsion Lab John Treichlew Rockwell Collins Ron Hau Signals & Systems Engineering Tom Hawkins Sun Microsystems Victor Chang Xilinx, Inc. Susan Wu In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode March 17, 2000 (916) 356-9200 4-299298 8432634 March 31, 2000 - DATE 2000 IBIS Summit Meeting (No Bridge) All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Bob Ross noted that Viewlogic Systems plans to change its name to Innoveda. We will change the participants list when this change is formalized. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross reported that another connector company plans to join the IBIS Open Forum. Cecilia Fleming will send out invoice reminders in March. We have payment from about 20 companies so far, but have not received payment from many of the most active participants. REVIEW OF MINUTES AND AR'S The minutes of January 14, 2000 were approved without change. Bob Ross corrected the company name to Advansis for Mikio Kiyono on the January 31, 2000 IBIS Summit Minutes and made minor editorial corrections. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Bob Ross reported that Syed Huq added KAW and Apt Software to the IBIS Participation Roster. Syed also updated the Upcoming Events. He also broke out the Articles link into Articles, Presentations, Tutorials, and IBIS Summit Meetings. Bob Ross mentioned that the article "Cadence Rolls Intel Xeon Kit" on page 58 in the February 21, 2000 issue of Electronic Engineering Times references usage of IBIS Version 3.2 models. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported that two Infineon Technology ATM IBIS Models exit at: http://www.infineon.com/products/commics/abm.htm http://www.infineon.com/products/commics/aop.htm OPENS FOR NEW ISSUES None INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Cecilia Fleming reported that this IEC has possibly approved this document December 1999, but the publication target is around August 2000. We need to look into this further. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross had no updates. - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross will meet with the group in Paris on Thursday, March 30, 2000 before the IBIS Summit Meeting. - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross asked D.C. Sessions to report on this during the JEDEC/IBIS Working Group meeting scheduled below as an agenda item. DESIGNCON 2000 IBIS SUMMIT MEETING FEEDBACK Bob Ross asked for any feedback. Bob felt that the meeting was successful and we had good discussion on the IBIS future direction issues. The IBIS Booth was also successful and served its purpose as a meeting place and also to demonstrate connector and accuracy measurements. JEDEC/IBIS WORKING GROUP MEETING REPORT Bob Ross gave a report on the JEDEC/IBIS Working Group meeting based on the brief notes that were appended to the January 31, 2000 IBIS Minutes. These notes are repeated here: ------------ JEDEC/IBIS WORKING GROUP MEETING - BRIEF NOTES Date/Time: Thursday, February 3, 2000, 1:00 PM - 5:00 PM Location/Host: Philips Semiconductor, San Jose, CA, D.C. Sessions Title: IBIS as a Specification Language Attendees: IBIS: Bob Ross, Mentor Graphics Kellee Crisafulli, HyperLynx Fred Ballesteri, Applied Simulation Technology Mike LaBonte, Cadence Design Systems Richard Mellitz, Intel Arpad Muranyi, Intel JEDEC: D.C. Sessions, Philips Semiconductor (Chair JC-16) Gil Russell, Infineon Technologies (Chair., JC-16.2) Howard Sussman, Sanyo Driving Force: Advances in DDR DRAMS Specification Needs (more clarification needed): 1. Differential Output Coupling at the Buffer to Pad level 2. A delta C_comp limit for buffers at the component level 3. SSTL-2 Input enhancements (BIRD62.2, BIRD63.2) Application Needs: 1. Relative Pad Delay (Skew in delay to pad) 2. Return Path details (possibly using Dr. Unger's SSN approach above) 3. Input Modeling (initially BIRD62.2, BIRD62.3 An IBIS Working Group on consisting of (at least) Arpad Muranyi, Kellee Crisafulli, Mike LaBonte, D.C. Sessions and Richard Mellitz will work on these issues and generate proposals. Next JEDEC and JC-16 and JC-42 Meetings: Friday, February 4, San Jose, California Report on the JEDEC/IBIS meeting and on future work Approximately March 7, 2000, Atlanta, Georgia ------------ Bob confirmed the above date for JC-16, and Stephen Nolan stated that JC-42 would meet on March 6, 2000. D.C. Sessions reported on the JEDEC Meeting held on February 4, 2000. The main action of interest to the IBIS Committee was to create a DDR SDRAM IBIS model. JEDEC member companies will submit their IBIS models and the goal is to come up with a composite model that can be used for specification. D.C. asked for IBIS committee volunteers to help. So far one manufacturer has supplied their IBIS model. Others have been promised. Bob initially suggested using the IBIS Model review committee. However, D.C. wanted more technical assistance. Bob and others will help. Since a number of manufacturers are competitors, there is sensitivity regarding who sees the models. D.C. asked the IBIS Committee to draft a letter of intent preserving the confidentiality of the individual IBIS models while helping construct the composite model. Normally these models are copyrighted. This letter of intent would allow the IBIS Committee to distribute the model. Bob wanted to take this issue offline with D.C. Bob saw no problem, but wanted to clarify some of the administrative issues and move on to other agenda items. Stephen Nolan indicated that other JEDEC subcommittees will also need to create specification IBIS Models. DATE2000 IBIS SUMMIT PLANNING Bob Ross reviewed that the DATE2000 IBIS Summit meeting associated with the Design Automation and Testing in Europe conference is planned to be held in Paris, France on Friday, March 31, 2000. The meeting is planned to run from morning to early afternoon. Cadence Design has joined Incases, Viewlogic and Mentor Graphics as co-sponsors. Presentations planned so far cover these subjects (not necessarily the exact titles): Behavioral Receiver Modeling Patrick Dos Santos, Cadence Design Systems IEC EMC/EMI Standardization Update Jean Claude Perrin, Texas Instruments Siemens IBIS Modeling Requirements for Semiconductor Vendors Gerald Bannert, Siemens Tips and Tricks for Creating IBIS Models Cary Mandel, Viewlogic Validation IBIS Models Sherif Hammad, Mentor Bob plans some discussion of IBIS 4.0 and IBIS future plans. A few other presentations are welcome. The second announcement has been sent out. The signup contact person for this meeting will change due to maternity leave. COOKBOOK STATUS Stephen Peters had no report. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora reported that another model from Galileo Technology has been sent for review. Matthew is also contacting other people to update the distribution list. We are seeking EDA vendor who will be able to simulate the models on their tools and provide knowledgeable feedback and suggestions directly to the model developer on a confidential basis. This is to help the model developer provide IBIS models which are valid and useful to all EDA vendor products. BIRD62.3 ENHANCED CHARACTERIZATION OF RECEIVER THRESHOLDS Bob Ross stated that while BIRD62.3 had been scheduled for a vote, we had a recent changes to this and BIRD63.3. The IBIS Open Forum normally requires two weeks between final posting of an item for voting and the actual vote. This allows all interested parties to have an opportunity to review the pending document and prevents surprise changes. Stephen Peters outlined the changes. These changes were made in response to Bob's e-mail comments. Besides some notation changes, the main changes were to introduce new subparameters for differential specifications. These included Vcross_min and Vcross_max. Michael Cohen expressed concern that we are not using [Model Spec]. D.C. Sessions and Stephen reinforced that the min and max corners in [Model Spec] were had combined effects that differed from the definitions for Vth. The Vth_min and Vth_max conditions are deviations under typical conditions, and a formula is used to created the corner cases. This is documented in BIRD62.3. Milt Schwartz commented on the need for a differential load DC offset limits that might be measured at a split resistor common point. BIRD62.3 only deals with receiver thresholds. D.C. reinforced the need for BIRD62.3. In fact, he wanted to know and report at the next JEDEC meeting the level of EDA tool commitment to implementing the proposed [Receiver Thresholds] keyword. Bob expected EDA vendors to implement this feature, but in accordance to their product development cycles that are not made public. Bob stated while he would prefer not having the complications introduced by BIRD62.3, he was convinced that [Model Spec] would only be used for about one-half of the added functionality. He saw the need for BIRD62.3 based on the following reasons: - Recent JEDEC standards related to SSTL, and recent LVDS standards are using the terminology in BIRD62.3. Also actual component data sheets are using this terminology. - The variation of the external reference used for threshold cannot be correctly handled using the [Model Spec] keyword. - This proposal through the Vinh_ac and Vinl_ac adds new parameters that are similar to the margins used for receiver analysis. Arpad Muranyi noted the need for CMOS thresholds as a percentage of Vcc. Stephen stated that this would be covered. Milt asked if hysteresis inputs were covered. D.C. stated they were not and also that hysteresis inputs were undesirable because of potential timing skew problems. More discussion occurred regarding the need for the new keyword. Bob had some syntactical comments concerning conventions. He noted that a large list of voltage subparameters had a mixture of actual voltages, (Vth, Vth_max, Vth_min, Vcross_max, Vcross_min), delta voltages (Vinh_ac, Vinh_dc, Vinl_dc, and Vinl_ac), differential voltages (Vdiff_ac, Vdiff_dc), and a sensitivity designated by Vth_sensitivity. Bob also noted that Vth, Vth_max and Vth_min followed existing IBIS conventions. However, Vcross_min and Vcross_max did not have a "typical" counterpart. Stephen proposed renaming the subparameters to Vcross_low and Vcross_high. The Vdiff_ac and Vdiff_dc are clear since "diff" is used. Also, after some discussion, the "ac" and "dc" portions of Vinh and Vinl could signal differences from Vth. This would maintain the terminology that is similar to what JEDEC is using. Since all voltage subparameters begin with "V", the Vth_sensitivity may be confusing. Stephen plans to change this to Threshold_sensitivity. Finally, Stephen agreed with Bob's comment that the term Reserved Words was incorrect for some enumerated strings: Pullup_ref, Pulldown_ref, Gnd_clamp_ref, Power_clamp_ref, and Ext_ref. Stephen planned to issue BIRD62.4 with these changes. Bob will schedule BIRD62.4 for a vote at the next meeting. BIRD63.3 DOCUMENTATION OF RECEIVER SETUP AND HOLD TIMING CONDITIONS Bob Ross introduced BIRD63.3 by questioning what the simulator tools are supposed to do with the [Tester Spec] information, as documented. A separate database would already contain the setup and hold times that were extracted in compliance with documented tester conditions of BIRD63.3. Michael Cohen thought the proposed [Tester Spec] was required, but noted that many data sheets do not have the proposed information. Bob stated that this keyword was optional. D.C. Sessions commented that this was the glue between analog and timing simulation. Stephen Peters thought that the simulator vendors would use this information under circuit simulation. D.C. stated that the intent was to provide an input timing limit. It was not intended to document changes in delay as a function of input wave shape. This is done in BIRD61.1. Stephen asked for clarification of the amplitudes of the input swing and at what points to measure the delay. D.C. stated the voltage should go between Vinh_ac and Vinl_ac. Stephen indicated that this information could be included in BIRD62.3 as another receiver subparameter. D.C. and others agreed with this change. Stephen agreed to include this in the revised BIRD62.3. Stephen stated that his AR was to issue BIRD62.4 with all of the changes discussed today (February 25, 2000). [Done] Bob will schedule BIRD63.3 for a vote at the next meeting, but with the expectation that BIRD63.3 will be rejected. BIRD66 - [Model Spec] Vref ADDITION Not Discussed. CONNECTOR PROPOSAL REVIEW (CONTINUED) Roy Leventhal commented on the need to get this specification approved and wanted to move faster on it. Bob Ross also wanted to move faster, but we have been spending time on IBIS 4.0 and IBIS futures issues as well. D.C. Sessions suggested that Bob issue a progress report on the Connector Specification on what is firm and what is unknown. Bob stated that he did not plan to do this. Instead, he noted that there was not any real know issues with the technical content in Version 0.93. The syntax and conventions are still being reviewed. Also we need to continue to address some of the areas of difference with IBIS Version 3.2. Justifiable differences are OK, but we all need to understand and reach collective agreement on them. Otherwise the changes may just reflect (probably valid) personal preferences, but may not of sufficient importance to conflict with the conventions set in IBIS Version 3.2. Since progress is going slowly, Bob suggested that he get with Gus Panella and Kellee Crisafulli off line to get agreement on some syntax and convention issues. This will avoid taking up teleconference time. (We can bring the remaining open issues to the IBIS Open Forum.) IBIS FUTURES (IBIS-X, API, BIRDxx) Not Discussed. BIRD61.1 - ENHANCED CHARACTERIZATION OF RECEIVERS Not Discussed. BIRD64.1 - PACKAGE MODE SELECTOR Not Discussed. BIRD65 - C_comp REFINEMENTS Not Discussed. IBIS BUG TRACKING Although scheduled at the end, this topic was discussed at the early part of the meeting. Bob Ross had planned to have some new ibischk3 BUG reports ready for discussion and also formally discuss the solution proposals within BUG34 (No Error Reported for Missing V/I Tables in Output Buffers). Bob does plan for discussion at the next meeting. Bob stated that a new ibischk3 bug was reported. We made a change in IBIS Version 3.2 (from IBIS Version 3.1) where series elements now can connect to pins that contain Input and I/O and Output models. Before, only NC and Terminators were permitted. Unfortunately, the series tests for ibischk3 were not updated for this change. So ibischk3 will report an error when a series element is correctly connected to pins containing Input, I/O and Output buffers. NEXT MEETING: The next teleconference meeting will be on Friday, March 17, 2000 from 8:00 AM to 10:00 AM. BIRD62.3 and BIRD63.3 are scheduled for voting. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@viewlogic.com Senior Manager, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jpowell@viewlogic.com Senior Scientist, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Signal Integrity Engineer, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 114715 N.E. 95th Street Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org/eig/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ==============================================================================