From owner-ibis Wed Jun 2 18:12:02 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA02051 for ; Wed, 2 Jun 1999 18:11:56 -0700 (PDT) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id RAA06243 for ; Wed, 2 Jun 1999 17:16:18 -0700 Message-Id: <3.0.5.32.19990602180559.00abb920@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 02 Jun 1999 18:05:59 +0000 To: ibis@eda.org From: Matthew Flora Subject: IBIS Open Forum Minutes 28 May 1999 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DATE: 6/2/99 SUBJECT: 5/28/99 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Raj Raghuram, Norio Matsui, Neven Orhanovic Avanti Nikolai Bannov Cadence Design Mike LaBonte* Cisco Systems Syed Huq* Compaq Bob Haller*, Steve Coe, Shafir Rahman, Maher Elasad Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella Fairchild Semiconductor [Peter LaFlamme], Craig Klem H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu High Design Technology Razvan Ene HyperLynx Matthew Flora*, Kellee Crisafulli IBM Greg Edlund, Michael Cohen*, Praven Patel Incases Olaf Rethmeier*, Werner Rissiek, David Eagles, Wilhelm Arnoldi, Ulrich Losch Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, Martin Chang, Dave Moxley, Kerry Nelson*, Jeff Day, Richard Mellitz, Peter Liou LSI Logic (Symbios Logic) Scott King Mentor Graphics Bob Ross*, Mohamed Mahmoud, Sherif Hammad, Jean Oudinot, Markku Kukkanen, Martin Groeber, Karine Loudet Mitsubishi (Tam Cao) Motorola (Ron Werner) National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda NEC (Hiroshi Matsumoto) Philips Semiconductor Todd Andersen, Peter Christiaans Quantic EMC (Mike Ventham) Siemens Bernhard Unger, Christian Mitschke, Manfred Maurer, Peter Kaiser, Wolfram Meyer, Gerald Bannert, Harmut Ibowski, Katja Zuleeg, Hans Pichlmaier, Eckhard Lenski, Kortheuer Udo, Christian Sporrer SiQual Scott McMorrow Texas Instruments Jean-Claude Perrin, Shankar Balasubramaniah, Ramzi Ammar Thomson-CSF (Jean Lebrun) Time Domain Analysis Systems Dima Smolyansky Viewlogic Chris Rokusek*, Guy de Burgh, Cary Mandel, (Jon Powell) VeriBest Ian Dodd* VLSI Technology D.C. Sessions Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1999: 3Dfx Interactive Ken Wu Actel Corporation Silvia Montoya Alcatel Steven Criel Analytical Edge Robert Easson Applied Microelectronics Brian Sanderson BMW Friedrich Haslinger Bogatin Enterprise Eric Bogatin Bosch Telecom Detlef Wolf ECI Telecom Daniel Adar EIA [Patti Rusher], Cecilia Fleming, Dan Heinemeier Electronique Catherine Gross EFM Consulting Ekkehard Miersch Intracon Design Mike Osmond FCI John Ellis Litton Systems Robert Bremer Molex Incorporated Gus Panella Nortel Networks (& Viewlogic) Martin Hall Oce Printing Systems Ernst Deiringer Praegitzer Design Rick Newell Rockwell Collins Susan Tweeton, Ron Hau Samsung Jung-Gun Byun, Cheol-Seung Choi Signals & Systems Engineering Tom Hawkins STMicroelectronics Fabrice Boissieres, Philippe LeFevre StorageTek Nick Krull Sun Microsystems Victor Chang Tektronix Tom Brinkoetter Teradyne Mikhail Khusid VDOL Robert Novosel Xilinx Susan Wu (Unaffiliatied, Retired) Bruce Wenniger 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 Monday, June 21, 1999 DAC99 IBIS Summit Meeting - No Phone 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 No new attendees. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross had no update, but still needs to work with Cecilia Fleming on payment status. REVIEW OF MINUTES AND AR'S No corrections were made to the minutes. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None PRESS AND WEB PAGE UPDATES Bob Ross reported that the June 1999 issue of Integrated System Design (ISD) has an article "EDA Standards for the Millennium" on pp. 17 - 28 which has a table that lists IBIS Version 3.2 as one of the standards. Bob also noted that some IBIS Training Courses have been uploaded to http://www.eda.org/pub/ibis/training/ Per the discussion at the last meeting, Arpad Muranyi made available his "Introduction to IBIS Models and IBIS Model Making" class Power Point slides. These were part of a short course set of tutorials given in April 1999 in Phoenix Arizona by the Arizona State University. These slides were uploaded as Foils99.zip. Also Arpad did a similar presentation in Hannover, Germany in May, 1999. He produced a modified set of slides that did not reference the proprietary IBIS Center program. These Power Point slides were uploaded as Hannover.zip. Bob indicated that Todd Westerhoff announced a downloadable Power Point tutorial "Basic SI and Timing Budgets for Common Clock Designs" on the SI reflector. The material also addresses issues regarding the timing test load and Vmeas in IBIS models. Todd has given Bob permission to upload the slides in the training directory. Bob indicated that there was no vendor-specific content in the presentation and asked the group if there were any objections to uploading this presentation. The group agreed to having the presentation uploaded. AR - Bob Ross upload timing101a.zip to the training directory above [Done]. Syed Huq reported that he has turned over the material to Cecilia Fleming on Upcoming events and the link to the training directory. He did run into a password issue that prevents him from doing the uploads himself. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported that the Aptos Semiconductor IBIS model link is down since the operations have been sold. OPENS FOR NEW ISSUES Arpad Muranyi on single ended and differential model selection. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Bob Ross reported that the comments voted on at the last meeting have been submitted to the US Technical Advisory Group (TAG) for formal processing. The comments will be formally forwarded to IEC. After they are processed, the IEC 62014-1 document should be moved to the next phase (FDIS) leading to formal ratification of a Draft International Standard. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross reported that he and Stephen Peters met with Dr. Norio Matsui and Raj Raghuram on Wednesday, May 12, 1999 to explore further some IBIS and IMIC merger and linkage ideas and issues. This will be discussed later in the meeting. - IEC 93/67/NP IBIS and EMC Simulation Bob Ross had no further report - JC-16.2 Subcommittee: Modeling and Test Bob Ross had no further report. IBIS (EAST) USERS GROUP MEETINGS Bob Haller reported that the IBIS Users Group meeting held on May 20, 1999 at North East Systems Associates was well attended. Since Minutes will be sent out, Bob just briefly summarized the topics covered: IBIS Accuracy Specification Connector Modeling IBIS Training Holding Regular IBIS Users Group Face-to-Face Meetings Bob Ross reported that Kathy Breda has reserved a room on Thursday, October 14, 1999 at the Marlborough Holiday Inn for the IBIS Summit Meeting that occurs at the same time as the PCB Conference East. Bob Haller commented that the IBIS Accuracy Specification Group would like to have actual correlation examples of IBIS models at that meeting. IBIS SUMMIT AT DESIGN AUTOMATION CONFERENCE Bob Ross noted that EIA will have a booth in which an IBIS poster will be displayed. Alpert Designs, Inc. will use last year's IBIS poster but with an updated theme for the new poster. The IBIS Summit Meeting is scheduled for Monday, June 21, 1999 at the Hilton Hotel, New Orleans Riverside (Chequers Room) in New Orleans, Louisiana. The hotel is adjacent to the Ernst M. Morial Convention Center where the Design Automation Conference (DAC) is being held. Bob expects people to show up at 8:30 for refreshments. The meeting should start at 9:00 AM and last into the afternoon. Lunch will be provided to the participants. The tentative Agenda includes: Business & Discussions - Election of Officers for 1999-2000 - Version 3.2 Response Issues - Open BIRDs Discussion - Version 4.X Features Presentations - IBIS 98-99 Overview - Bob Ross, Mentor Graphics - Accuracy Specification Update - Bob Haller, Compaq - ECALS-2 and the EMI Problem - Atsushi Ito, Matsushita - Equation Based Modeling, Arpad Muranyi, Intel Bob estimated that about 17 people have signed up so far. Bob asked Matthew Flora to send out another meeting announcement shortly. [Note on sign-ups: Matthew Flora will handle the sign-ups for the meeting. Some details are already on the Upcoming Events link on the EIA IBIS home page. Matthew can be contacted at mbflora@hyperlynx.com or (425) 869-2320.] AR - Bob Ross and Matthew Flora send out a second announcement for the EIA IBIS Summit Meeting on June 21, 1999. SP-4557 - IBIS VERSION 3.2 LETTER BALLOT Bob Ross reminded everyone to VOTE. A strong show of support is needed for this to be ratified. The EIA letter ballot deadline is Wednesday, June 23, 1999. Bob relayed a report from Cecilia Fleming that the ballot on IBIS Version 3.2 has also been published in the appropriate ANSI document. The ANSI deadline is Tuesday, August 3, 1999. As with IBIS Version 2.1, there may be a brief period of time where IBIS Version 3.2 is an EIA standard before becoming and ANSI/EIA standard. The document being considered and also the form used for voting are accessed from the EIA IBIS home page: http://www.eia.org/eig/ibis/ibis.htm The document is in Adobe format (ver3_2.pdf) and the ballot (SP-4557.pdf) needs to be signed and returned by surface mail or faxed to EIA. Editorial corrections are welcome. COOKBOOK STATUS Stephen Peters had no report. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora indicated one request for information on the process. S2IBIS2 MAINTENANCE AND S2IBIS3 Bob Ross started the discussion by indicating that this was a continuation of the discussion at the May 7, 1999 meeting. Bob noted that a s2ibis2 problem reported by Scott McMorrow and a solution were forwarded to an individual who is interested in providing an upgrade. This opened the door to a long discussion on what to do about s2ibis2 maintenance and s2ibis3 generation. Michael Cohen observed that the public domain s2ibis2 utility is widely used as the "official" IBIS model generator. However, he still sees defective models. Syed Huq proposed that we consider hiring a contractor to fix s2ibis2 bugs and do s2ibis3 development. Ian Dodd noted the problem that in order to make s2ibis more portable (for NT operating systems), he had to rewrite the LEX and YACC dependent portions. Mike LaBonte suggested commercial vendor might make available the generic code of their vendor specific s2ibis2 utility. Ian and Matthew Flora noted that users of the utility could provide financial support of the generic utility development. After some more discussion, Ian noted that we need to specify what we want. Bob formed a committee to look into this consisting of Michael Cohen, Ian Dodd, Mike LaBonte and Syed Huq. Bob agreed to provide them with the e-mail addresses. Furthermore Bob will schedule time at the IBIS Summit Meeting on June 21, 1999 for a report since this group plans to attend. The discussion continued. Arpad Muranyi suggested that we might consider a web-based s2ibis utility that does not depend on a locally distributed s2ibis utility. He cited some utilities offered on the Signal Integrity reflector as examples. Michael Cohen cautioned that since s2ibis2 requires flavors of SPICE, he would be restricted to using a commercial SPICE without having dedicated local licenses. He felt that the licensing restrictions would prevent many SPICEs from being used. Chris Rokusek commented that a public domain Berkeley Spice could be used. However, many SPICE models come with commercial SPICE vendor-specific syntax and process models. Bob commented that what is needed are the list of bugs to be fixed, the flavors of SPICE to be supported, and the platforms and operating systems (e.g., UNIX and NT) to be supported. Then potential contractors can provide a bid on doing the s2ibis2 and s2ibis3 upgrades. Currently five flavors are supported. More may be needed plus a means to support semiconductor vendor proprietary SPICEs. LEX and YACC code may need to be replaced with generated code for portability. BUG34 - NO ERROR REPORTED FOR MISSING V/I TABLE IN OUTPUT BUFFERS Bob Ross noted that there is still no revised BUG34 proposal. So the discussion was deferred. Matthew Flora's AR is still open. AR - Matthew Flora issue a revised BUG34 to document the conditions where Warning messages are issued. IMIC AND IBIS Bob Ross reported on a meeting held on Wednesday, May 12, 1999 with Bob, Stephen Peters, Raj Raghuram and Norio Matsui and hosted by Applied Simulation Technology. A number of topics discussed and Bob reported on some of the discussion at that meeting: The team reviewed the history of the activity and then asked what the IBIS Committee and the EIAJ IMIC Committee would want. For background, Bob noted that IBIS Version 3.2 is going through formal national standards body ratification processes. Now is the time to think about future needs including how to relate IBIS with the IMIC proposal. At the meeting Norio stressed that IMIC Committee does not want to see IBIS replaced. The IMIC proposal was developed to provide models for not only Signal Integrity problems, but and also for Power Integrity and EMI problems. Bob noted that IBIS has some specification and information details such as input voltage thresholds, timing test loads, and Model_type that are used for Signal Integrity applications. Norio stated that EIAJ is looking for a merger solution of IBIS and IMIC. Some IMIC members may be advocating a merger or combination of two standards, giving the semiconductor vendors a choice of formats. Bob felt that this flexibility could provide too much of a burden on EDA vendors and customers. For just Signal Integrity applications, there was no proven benefit that one approach was better than the other. Bob noted some syntax/structural incompatibility details between IBIS and IMIC. Allowing a mixture of information might result in incomplete information for the application. Bob commented that commercial/EDA vendors provide many IBIS models to deal with user needs. At the meeting the proposals were positioned as follows with respect to SPICE and to levels of abstraction: IBIS - Behavioral IMIC - Behavioral and Structural SPICE - Structural The higher level formats can be derived from the lower level formats. Norio noted that IBIS has a fixed model that requires syntax changes for enhancements. IMIC supports a network description and is more flexible. We explored in more detail what is really the preferred level of merger by each group. Norio indicated that he would like IBIS to support netlists. Also he would like to see IBIS support table level transistor models. Bob indicated that it would be useful if IMIC supported a complete IBIS Buffer [Model] syntax as a 5-7 terminal element (4 power rails, I/O, and possibly input and enable) in IMIC. We looked at independent positioning with linkages. This would allow each standard to be optimized for its application and still leverage the data in the other standard. IBIS could call IMIC (or SPICE) transistor models and netlists. Netlists could be used for packages. EIAJ is looking at consumer electronics, automobile microprocessors, ASICS, and faster applications. IMIC or IBIS could be used for system level applications. For automotive electronics, the location of the ground reference is becoming a fundamental issue, and EMI/EMC are big concerns. We agreed that complex package modeling is very difficult with both the IMIC and IBIS approaches. A simplified approach may be useful. Norio noted that the IMIC Committee is monitoring an EIAJ EMI activity called ECALS-2. Norio also mentioned that an IMIC Meeting will be held on June 1, 1999 to discuss the comments of this meeting. Stephen Peters provided some additional observations about the meeting. He felt that the IMIC format could provide a longer term EMI and Power Integrity solution. IMIC was potentially superior in dealing with SSO analysis. The network description was appealing for package modeling. Stephen noted that a fundamental problem with IMIC format is that it needs a netlist level buffer description to support the transistor level table SPICE approach. Stephen did not see how IMIC could replace IBIS unless some specific advantages were demonstrated. Bob noted that they discussed other topics including simulator performance and the IBIS Series Model element. Bob concluded the report of the meeting and stated that we need specific proposals and justification in order to proceed toward any of the merger proposals above. BUG34 - NO ERROR REPORTED FOR MISSING V/I TABLE IN OUTPUT BUFFERS Bob Ross noted that since no revised BUG34 proposal was generated, the discussion was deferred. Matthew Flora's AR is still open. AR - Matthew Flora issue a revised BUG34 to document the conditions where Warning messages are issued. BIRD58.2 - DRIVER SCHEDULE KEYWORD CLARIFICATION Arpad Muranyi commented on the history of BIRD58.2 starting with the original intent of adding a critical paragraph that existed in the original BIRD35.3. Based on subsequent feedback, more clarification detail was added to BIRD58.2 while retaining the original technical intent. Bob Ross and others commented that BIRD58.2 clarified a number of points. Bob called for any comments. Bob suggested a minor editorial change to change the order of the detailed description of the delay columns to the same order as the syntax: Rise_on_dly, Rise_off_dly, Fall_on_dly, and Fall_off_dly. Also Bob suggested improving the wording of the clause in the last sentence of four paragraphs (note OFF and ON are interchanged as appropriate): (if they were not turned OFF and ON by another event yet, respectively). After some discussion Matthew Flora suggested the correction: (if they were not already turned OFF and ON, respectively, by another event). With no further comments, Bob Ross called for a vote on BIRD58.2 with the modifications above (to be issued as BIRD58.3). BIRD58.2 as modified was approved by unanimous vote. AR - Arpad Muranyi issue approved BIRD58.3 with the changes above. [Done] The editorial changes of BIRD58.3 will be submitted as an editorial comment and are expected to be part of the EIA and ANSI Version 3.2 document. NUMBER OF POINTS IN VT TABLE Bob Ross introduced the issue that IBIS has a 100 point limit on all tables. This limit may not be adequate for certain circumstances and for automated IBIS model generation. Chris Rokusek stated he would support allowing more points for better accuracy. He thought that in most cases the points need to be properly filtered in order to achieve good accuracy with 100 points or less. Mike LaBonte commented that he has seen high frequency effects that change the simulation between filtered and unfiltered tables. Bob Haller noted that an internal tool has a 1000 point limit in tables. Michael Cohen has seen IBIS models with data points in tables commented out to comply with the 100 point restriction. Arpad Muranyi elaborated on the issue. The IBIS Specification is clear that for VI tables, the 100 point limit applies to the voltage axis. However for VT tables, it is not clear whether the 100 point limit applies to the time axis or to each of the voltage columns. The historical rationale for the 100 point limitation was that some SPICE controlled source table formats were limited to 100 table points. Furthermore, Arpad indicated that the 100 point limit was not a problem for the VI tables. He has an algorithm to select the best 100 points out of a larger number of extracted points. The points at which the maximum table curvature occurs is in the same region for VI tables. However, VT tables provide the biggest challenge for providing accurate data with 100 points. The typical, minimum, and maximum column waveforms tend to be shifted with respect to each other. The points of maximum curvature where you want the highest density of points tend to be in different regions of the time axis. Stephen Peters also noted that he has seen the areas of maximum curvature to be at different time regions. So each table could be theoretically limited to having a different set of 33 time points spread out in different time regions. This could provide a much courser resolution for each of the columns and could compromise the accuracy of the data. In a SPICE implementation of IBIS comparison with the structural SPICE model simulation, Arpad encountered a situation where more VT points were needed to achieve acceptable accuracy. The general agreement was that the 100 point limit should be relaxed. Bob Ross listed some options: Do nothing - keep the 100 point limit Allow the 100 point limit to be interpreted for each column Raise the 100 point limit to a higher number (say, 1000 points) Do not provide a limit. The consensus was to provide a conservative limit such as 1000. If no limit is provided, valid IBIS models might be created with an unnecessarily large number of points. This could create very large databases and slow down the simulations. The option of changing the limit to apply to each column appeared to be an unnecessary complication in any model generation utility such as s2ibis2. Arpad commented that he allows the option to fill in the NA data with numerical values. Even though the 100 point limitation is in IBIS Version 3.2, the ibischk3 parser could be changed to issue a Warning message instead of an error message since there are cases where the additional points are needed. Bob Ross commented that a BIRD needs to be generated for IBIS Version 4.X to increase the number of points. 1001 points would allow numerically nice endpoints such as 0 and 10 ns with equally spaced points for easy automated generation. However, it should be recommended that more than 100 points should be used only in situations where it is necessary for accuracy. Arpad commented that in any case, the IBIS Specification needs to be clarified concerning whether the limit applies to the number of rows in the table (X-axis) or to the number of numerical data values in each column (Y-axis). CONNECTOR PROPOSAL REVIEW Matthew Flora reported that Gus Panella is working on a description of the matrices in the Connector Model proposal. SINGLE ENDED AND DIFFERENTIAL MODEL SELECTION (New Issue) Arpad Muranyi raised the concern on the IBIS reflector that some devices have outputs which can be used for differential or single ended operation. Michael Cohen added that he uses a SCSI chip with these characteristics. There is no provision within IBIS Version 3.2 to handle this in one component. The solution on the reflector was to provide two separate component models. Bob Ross indicated that this was the correct response. We have discussed this issue in the past. To resolve this within IBIS we might have to write a BIRD on a differential model selector. IBIS 4.X FEATURES Bob Ross briefly mentioned some features requested for IBIS Version 4.X: Input Tables Removal of 100 Point Limit Differential Overshoots Possible SPICE/IMIC Linkages for Netlists and Models EMI Extensions Connector Models Accuracy Specification Extensions Syed Huq added that differential loads should be considered. Bob noted that more discussion should occur at the IBIS Summit Meeting. Final comment - Bob Haller would like to reserve some meeting time for the IBIS Accuracy Specification Issues. Bob suggested that the changes will be introduced at the Summit. Discussion can be scheduled at the next teleconference meeting. NEXT MEETING: The next meeting is the EIA IBIS Open Forum Summit Meeting on Monday, June 21, 1999 in the Hilton Hotel in New Orleans, Louisiana. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Interconnectix BU of 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-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 SECRETARY: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 17641 NE 67th Court Redmond, WA 98052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic Systems (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 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 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 Wed Jun 2 18:18:20 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA02059; Wed, 2 Jun 1999 18:18:18 -0700 (PDT) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id RAA06263; Wed, 2 Jun 1999 17:22:41 -0700 Message-Id: <3.0.5.32.19990602181222.00aee740@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 02 Jun 1999 18:12:22 +0000 To: ibis@eda.org, ibis-users@eda.org From: Matthew Flora Subject: DAC IBIS Summit Meeting - Second Announcement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" D A C 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 DATE: Monday, June 21, 1993 TIME: 8:30 AM - Afternoon CITY: New Orleans, Louisiana LOCATION: Hilton Hotel, New Orleans Riverside, next to Ernest N. Morial Convention Center where the Design Automation Conference (DAC) is being held. ROOM: Chequers LUNCH: Refreshments and Lunch will be provided. AGENDA: The agenda is being planned. Some planned items are: Business & Discussions: - Election of Officers for 1999-2000 - Open BIRDs Discussion - IBIS Version 3.2 Letter Ballot Response Issues - s2ibis2/3 Project Report - Version 4.X Features Expected Presentations to Date: - IBIS 98-99 Overview - Bob Ross, Mentor Graphics - Accuracy Specification Update - Bob Haller, Compaq - ECALS-2 and the EMI Problem - Atsushi Ito, Matsushita - Equation Based Modeling, Arpad Muranyi, Intel - Status of IMIC, Hideki Fukuda, Hitachi DAC: DAC is scheduled Monday - Friday, June 21 -25, 1999. The exhibitor portion is open from 10 AM to 6 PM on Monday - Wednesday. So there should be time after the IBIS Summit meeting to visit the show. For more information on DAC99 activities, housing, etc. visit the DAC99 URL. DAC URL: http://www.dac.com/ CALL FOR PRESENTATIONS: Along with the presentatations currently planned, we welcome other technical presentations related to any current IBIS activity and to future IBIS needs. Contact Matthew Flora (see below) regarding your presentation: Presenter: Title: Estimated Time: We would like you to provide handouts for the meeting (about 25) and also an electronic copy for archiving. CALL FOR ATTENDEES: Please let Matthew Flora know if you are planning to attend so we have an estimate on food requirements. CONTACT: Matthew Flora mbflora@hyperlynx.com (425) 869-2320 From owner-ibis Thu Jun 3 11:09:52 1999 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA06552 for ; Thu, 3 Jun 1999 11:09:51 -0700 (PDT) From: micohen@us.ibm.com Received: from southrelay02.raleigh.ibm.com by smtp3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA25462; Thu, 3 Jun 1999 14:02:58 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v1.8) with SMTP id OAA26138; Thu, 3 Jun 1999 14:03:25 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256785.00632B4A ; Thu, 3 Jun 1999 14:03:11 -0400 X-Lotus-FromDomain: IBMUS To: Matthew Flora cc: ibis@eda.org Message-ID: <85256785.00632759.00@d54mta04.raleigh.ibm.com> Date: Thu, 3 Jun 1999 14:02:35 -0400 Subject: Re: IBIS Open Forum Minutes 28 May 1999 - Correction Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Matthew, I was reading the minutes you posted, and have a correction/clarification to make: In the minutes, you state (in the section dealing with S2IBIS): ... Michael Cohen cautioned that since s2ibis2 requires flavors of SPICE, he would be restricted to using a commercial SPICE without having dedicated local licenses. He felt that the licensing restrictions would prevent many SPICEs from being used. ... Actually, this is not just a problem for me. ANYONE would be restricted due to the various commercial SPICEs having Wide Area Network (WAN) restrictions which would prohibit anyone from hosting the SPICE tool for general use outside of a 5 to 10 mile radius of the server. Generally, these licenses specify that only people within the company that purchased the license may use the tool, and only at that specific site. The exemption to this rule would be if the owner of the SPICE (e.g., Avanti for HSpice) would host the S2IBIS tool on its web site. However, in this case we would have numerous SPICE manufacturers hosting the S2IBIS tool (one for HSPICE, one for PSPICE, etc.). I hope this clarifies what I was trying to say in the meeting. Regards, Michael Cohen IBM Personal Systems Group Design Tools Department D-26D/B-201/R-D104H 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919-543-4042 (T/L 441-4042) FAX: 919-543-8221 (T/L 441-8221) Internet Address: micohen@us.ibm.com IBM Internal Addresses: From Lotus Notes (#1): Michael Cohen/Raleigh/IBM From Lotus Notes (#2): micohen@ibmus From VM: micohen@ibmusm21 Matthew Flora on 06/02/99 02:05:59 PM To: ibis@eda.org cc: (bcc: Michael Cohen/Raleigh/IBM) Subject: IBIS Open Forum Minutes 28 May 1999 DATE: 6/2/99 SUBJECT: 5/28/99 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Raj Raghuram, Norio Matsui, Neven Orhanovic Avanti Nikolai Bannov Cadence Design Mike LaBonte* Cisco Systems Syed Huq* Compaq Bob Haller*, Steve Coe, Shafir Rahman, Maher Elasad Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella Fairchild Semiconductor [Peter LaFlamme], Craig Klem H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu High Design Technology Razvan Ene HyperLynx Matthew Flora*, Kellee Crisafulli IBM Greg Edlund, Michael Cohen*, Praven Patel Incases Olaf Rethmeier*, Werner Rissiek, David Eagles, Wilhelm Arnoldi, Ulrich Losch Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, Martin Chang, Dave Moxley, Kerry Nelson*, Jeff Day, Richard Mellitz, Peter Liou LSI Logic (Symbios Logic) Scott King Mentor Graphics Bob Ross*, Mohamed Mahmoud, Sherif Hammad, Jean Oudinot, Markku Kukkanen, Martin Groeber, Karine Loudet Mitsubishi (Tam Cao) Motorola (Ron Werner) National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda NEC (Hiroshi Matsumoto) Philips Semiconductor Todd Andersen, Peter Christiaans Quantic EMC (Mike Ventham) Siemens Bernhard Unger, Christian Mitschke, Manfred Maurer, Peter Kaiser, Wolfram Meyer, Gerald Bannert, Harmut Ibowski, Katja Zuleeg, Hans Pichlmaier, Eckhard Lenski, Kortheuer Udo, Christian Sporrer SiQual Scott McMorrow Texas Instruments Jean-Claude Perrin, Shankar Balasubramaniah, Ramzi Ammar Thomson-CSF (Jean Lebrun) Time Domain Analysis Systems Dima Smolyansky Viewlogic Chris Rokusek*, Guy de Burgh, Cary Mandel, (Jon Powell) VeriBest Ian Dodd* VLSI Technology D.C. Sessions Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1999: 3Dfx Interactive Ken Wu Actel Corporation Silvia Montoya Alcatel Steven Criel Analytical Edge Robert Easson Applied Microelectronics Brian Sanderson BMW Friedrich Haslinger Bogatin Enterprise Eric Bogatin Bosch Telecom Detlef Wolf ECI Telecom Daniel Adar EIA [Patti Rusher], Cecilia Fleming, Dan Heinemeier Electronique Catherine Gross EFM Consulting Ekkehard Miersch Intracon Design Mike Osmond FCI John Ellis Litton Systems Robert Bremer Molex Incorporated Gus Panella Nortel Networks (& Viewlogic) Martin Hall Oce Printing Systems Ernst Deiringer Praegitzer Design Rick Newell Rockwell Collins Susan Tweeton, Ron Hau Samsung Jung-Gun Byun, Cheol-Seung Choi Signals & Systems Engineering Tom Hawkins STMicroelectronics Fabrice Boissieres, Philippe LeFevre StorageTek Nick Krull Sun Microsystems Victor Chang Tektronix Tom Brinkoetter Teradyne Mikhail Khusid VDOL Robert Novosel Xilinx Susan Wu (Unaffiliatied, Retired) Bruce Wenniger 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 Monday, June 21, 1999 DAC99 IBIS Summit Meeting - No Phone 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 No new attendees. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross had no update, but still needs to work with Cecilia Fleming on payment status. REVIEW OF MINUTES AND AR'S No corrections were made to the minutes. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None PRESS AND WEB PAGE UPDATES Bob Ross reported that the June 1999 issue of Integrated System Design (ISD) has an article "EDA Standards for the Millennium" on pp. 17 - 28 which has a table that lists IBIS Version 3.2 as one of the standards. Bob also noted that some IBIS Training Courses have been uploaded to http://www.eda.org/pub/ibis/training/ Per the discussion at the last meeting, Arpad Muranyi made available his "Introduction to IBIS Models and IBIS Model Making" class Power Point slides. These were part of a short course set of tutorials given in April 1999 in Phoenix Arizona by the Arizona State University. These slides were uploaded as Foils99.zip. Also Arpad did a similar presentation in Hannover, Germany in May, 1999. He produced a modified set of slides that did not reference the proprietary IBIS Center program. These Power Point slides were uploaded as Hannover.zip. Bob indicated that Todd Westerhoff announced a downloadable Power Point tutorial "Basic SI and Timing Budgets for Common Clock Designs" on the SI reflector. The material also addresses issues regarding the timing test load and Vmeas in IBIS models. Todd has given Bob permission to upload the slides in the training directory. Bob indicated that there was no vendor-specific content in the presentation and asked the group if there were any objections to uploading this presentation. The group agreed to having the presentation uploaded. AR - Bob Ross upload timing101a.zip to the training directory above [Done]. Syed Huq reported that he has turned over the material to Cecilia Fleming on Upcoming events and the link to the training directory. He did run into a password issue that prevents him from doing the uploads himself. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported that the Aptos Semiconductor IBIS model link is down since the operations have been sold. OPENS FOR NEW ISSUES Arpad Muranyi on single ended and differential model selection. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Bob Ross reported that the comments voted on at the last meeting have been submitted to the US Technical Advisory Group (TAG) for formal processing. The comments will be formally forwarded to IEC. After they are processed, the IEC 62014-1 document should be moved to the next phase (FDIS) leading to formal ratification of a Draft International Standard. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross reported that he and Stephen Peters met with Dr. Norio Matsui and Raj Raghuram on Wednesday, May 12, 1999 to explore further some IBIS and IMIC merger and linkage ideas and issues. This will be discussed later in the meeting. - IEC 93/67/NP IBIS and EMC Simulation Bob Ross had no further report - JC-16.2 Subcommittee: Modeling and Test Bob Ross had no further report. IBIS (EAST) USERS GROUP MEETINGS Bob Haller reported that the IBIS Users Group meeting held on May 20, 1999 at North East Systems Associates was well attended. Since Minutes will be sent out, Bob just briefly summarized the topics covered: IBIS Accuracy Specification Connector Modeling IBIS Training Holding Regular IBIS Users Group Face-to-Face Meetings Bob Ross reported that Kathy Breda has reserved a room on Thursday, October 14, 1999 at the Marlborough Holiday Inn for the IBIS Summit Meeting that occurs at the same time as the PCB Conference East. Bob Haller commented that the IBIS Accuracy Specification Group would like to have actual correlation examples of IBIS models at that meeting. IBIS SUMMIT AT DESIGN AUTOMATION CONFERENCE Bob Ross noted that EIA will have a booth in which an IBIS poster will be displayed. Alpert Designs, Inc. will use last year's IBIS poster but with an updated theme for the new poster. The IBIS Summit Meeting is scheduled for Monday, June 21, 1999 at the Hilton Hotel, New Orleans Riverside (Chequers Room) in New Orleans, Louisiana. The hotel is adjacent to the Ernst M. Morial Convention Center where the Design Automation Conference (DAC) is being held. Bob expects people to show up at 8:30 for refreshments. The meeting should start at 9:00 AM and last into the afternoon. Lunch will be provided to the participants. The tentative Agenda includes: Business & Discussions - Election of Officers for 1999-2000 - Version 3.2 Response Issues - Open BIRDs Discussion - Version 4.X Features Presentations - IBIS 98-99 Overview - Bob Ross, Mentor Graphics - Accuracy Specification Update - Bob Haller, Compaq - ECALS-2 and the EMI Problem - Atsushi Ito, Matsushita - Equation Based Modeling, Arpad Muranyi, Intel Bob estimated that about 17 people have signed up so far. Bob asked Matthew Flora to send out another meeting announcement shortly. [Note on sign-ups: Matthew Flora will handle the sign-ups for the meeting. Some details are already on the Upcoming Events link on the EIA IBIS home page. Matthew can be contacted at mbflora@hyperlynx.com or (425) 869-2320.] AR - Bob Ross and Matthew Flora send out a second announcement for the EIA IBIS Summit Meeting on June 21, 1999. SP-4557 - IBIS VERSION 3.2 LETTER BALLOT Bob Ross reminded everyone to VOTE. A strong show of support is needed for this to be ratified. The EIA letter ballot deadline is Wednesday, June 23, 1999. Bob relayed a report from Cecilia Fleming that the ballot on IBIS Version 3.2 has also been published in the appropriate ANSI document. The ANSI deadline is Tuesday, August 3, 1999. As with IBIS Version 2.1, there may be a brief period of time where IBIS Version 3.2 is an EIA standard before becoming and ANSI/EIA standard. The document being considered and also the form used for voting are accessed from the EIA IBIS home page: http://www.eia.org/eig/ibis/ibis.htm The document is in Adobe format (ver3_2.pdf) and the ballot (SP-4557.pdf) needs to be signed and returned by surface mail or faxed to EIA. Editorial corrections are welcome. COOKBOOK STATUS Stephen Peters had no report. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora indicated one request for information on the process. S2IBIS2 MAINTENANCE AND S2IBIS3 Bob Ross started the discussion by indicating that this was a continuation of the discussion at the May 7, 1999 meeting. Bob noted that a s2ibis2 problem reported by Scott McMorrow and a solution were forwarded to an individual who is interested in providing an upgrade. This opened the door to a long discussion on what to do about s2ibis2 maintenance and s2ibis3 generation. Michael Cohen observed that the public domain s2ibis2 utility is widely used as the "official" IBIS model generator. However, he still sees defective models. Syed Huq proposed that we consider hiring a contractor to fix s2ibis2 bugs and do s2ibis3 development. Ian Dodd noted the problem that in order to make s2ibis more portable (for NT operating systems), he had to rewrite the LEX and YACC dependent portions. Mike LaBonte suggested commercial vendor might make available the generic code of their vendor specific s2ibis2 utility. Ian and Matthew Flora noted that users of the utility could provide financial support of the generic utility development. After some more discussion, Ian noted that we need to specify what we want. Bob formed a committee to look into this consisting of Michael Cohen, Ian Dodd, Mike LaBonte and Syed Huq. Bob agreed to provide them with the e-mail addresses. Furthermore Bob will schedule time at the IBIS Summit Meeting on June 21, 1999 for a report since this group plans to attend. The discussion continued. Arpad Muranyi suggested that we might consider a web-based s2ibis utility that does not depend on a locally distributed s2ibis utility. He cited some utilities offered on the Signal Integrity reflector as examples. Michael Cohen cautioned that since s2ibis2 requires flavors of SPICE, he would be restricted to using a commercial SPICE without having dedicated local licenses. He felt that the licensing restrictions would prevent many SPICEs from being used. Chris Rokusek commented that a public domain Berkeley Spice could be used. However, many SPICE models come with commercial SPICE vendor-specific syntax and process models. Bob commented that what is needed are the list of bugs to be fixed, the flavors of SPICE to be supported, and the platforms and operating systems (e.g., UNIX and NT) to be supported. Then potential contractors can provide a bid on doing the s2ibis2 and s2ibis3 upgrades. Currently five flavors are supported. More may be needed plus a means to support semiconductor vendor proprietary SPICEs. LEX and YACC code may need to be replaced with generated code for portability. BUG34 - NO ERROR REPORTED FOR MISSING V/I TABLE IN OUTPUT BUFFERS Bob Ross noted that there is still no revised BUG34 proposal. So the discussion was deferred. Matthew Flora's AR is still open. AR - Matthew Flora issue a revised BUG34 to document the conditions where Warning messages are issued. IMIC AND IBIS Bob Ross reported on a meeting held on Wednesday, May 12, 1999 with Bob, Stephen Peters, Raj Raghuram and Norio Matsui and hosted by Applied Simulation Technology. A number of topics discussed and Bob reported on some of the discussion at that meeting: The team reviewed the history of the activity and then asked what the IBIS Committee and the EIAJ IMIC Committee would want. For background, Bob noted that IBIS Version 3.2 is going through formal national standards body ratification processes. Now is the time to think about future needs including how to relate IBIS with the IMIC proposal. At the meeting Norio stressed that IMIC Committee does not want to see IBIS replaced. The IMIC proposal was developed to provide models for not only Signal Integrity problems, but and also for Power Integrity and EMI problems. Bob noted that IBIS has some specification and information details such as input voltage thresholds, timing test loads, and Model_type that are used for Signal Integrity applications. Norio stated that EIAJ is looking for a merger solution of IBIS and IMIC. Some IMIC members may be advocating a merger or combination of two standards, giving the semiconductor vendors a choice of formats. Bob felt that this flexibility could provide too much of a burden on EDA vendors and customers. For just Signal Integrity applications, there was no proven benefit that one approach was better than the other. Bob noted some syntax/structural incompatibility details between IBIS and IMIC. Allowing a mixture of information might result in incomplete information for the application. Bob commented that commercial/EDA vendors provide many IBIS models to deal with user needs. At the meeting the proposals were positioned as follows with respect to SPICE and to levels of abstraction: IBIS - Behavioral IMIC - Behavioral and Structural SPICE - Structural The higher level formats can be derived from the lower level formats. Norio noted that IBIS has a fixed model that requires syntax changes for enhancements. IMIC supports a network description and is more flexible. We explored in more detail what is really the preferred level of merger by each group. Norio indicated that he would like IBIS to support netlists. Also he would like to see IBIS support table level transistor models. Bob indicated that it would be useful if IMIC supported a complete IBIS Buffer [Model] syntax as a 5-7 terminal element (4 power rails, I/O, and possibly input and enable) in IMIC. We looked at independent positioning with linkages. This would allow each standard to be optimized for its application and still leverage the data in the other standard. IBIS could call IMIC (or SPICE) transistor models and netlists. Netlists could be used for packages. EIAJ is looking at consumer electronics, automobile microprocessors, ASICS, and faster applications. IMIC or IBIS could be used for system level applications. For automotive electronics, the location of the ground reference is becoming a fundamental issue, and EMI/EMC are big concerns. We agreed that complex package modeling is very difficult with both the IMIC and IBIS approaches. A simplified approach may be useful. Norio noted that the IMIC Committee is monitoring an EIAJ EMI activity called ECALS-2. Norio also mentioned that an IMIC Meeting will be held on June 1, 1999 to discuss the comments of this meeting. Stephen Peters provided some additional observations about the meeting. He felt that the IMIC format could provide a longer term EMI and Power Integrity solution. IMIC was potentially superior in dealing with SSO analysis. The network description was appealing for package modeling. Stephen noted that a fundamental problem with IMIC format is that it needs a netlist level buffer description to support the transistor level table SPICE approach. Stephen did not see how IMIC could replace IBIS unless some specific advantages were demonstrated. Bob noted that they discussed other topics including simulator performance and the IBIS Series Model element. Bob concluded the report of the meeting and stated that we need specific proposals and justification in order to proceed toward any of the merger proposals above. BUG34 - NO ERROR REPORTED FOR MISSING V/I TABLE IN OUTPUT BUFFERS Bob Ross noted that since no revised BUG34 proposal was generated, the discussion was deferred. Matthew Flora's AR is still open. AR - Matthew Flora issue a revised BUG34 to document the conditions where Warning messages are issued. BIRD58.2 - DRIVER SCHEDULE KEYWORD CLARIFICATION Arpad Muranyi commented on the history of BIRD58.2 starting with the original intent of adding a critical paragraph that existed in the original BIRD35.3. Based on subsequent feedback, more clarification detail was added to BIRD58.2 while retaining the original technical intent. Bob Ross and others commented that BIRD58.2 clarified a number of points. Bob called for any comments. Bob suggested a minor editorial change to change the order of the detailed description of the delay columns to the same order as the syntax: Rise_on_dly, Rise_off_dly, Fall_on_dly, and Fall_off_dly. Also Bob suggested improving the wording of the clause in the last sentence of four paragraphs (note OFF and ON are interchanged as appropriate): (if they were not turned OFF and ON by another event yet, respectively). After some discussion Matthew Flora suggested the correction: (if they were not already turned OFF and ON, respectively, by another event). With no further comments, Bob Ross called for a vote on BIRD58.2 with the modifications above (to be issued as BIRD58.3). BIRD58.2 as modified was approved by unanimous vote. AR - Arpad Muranyi issue approved BIRD58.3 with the changes above. [Done] The editorial changes of BIRD58.3 will be submitted as an editorial comment and are expected to be part of the EIA and ANSI Version 3.2 document. NUMBER OF POINTS IN VT TABLE Bob Ross introduced the issue that IBIS has a 100 point limit on all tables. This limit may not be adequate for certain circumstances and for automated IBIS model generation. Chris Rokusek stated he would support allowing more points for better accuracy. He thought that in most cases the points need to be properly filtered in order to achieve good accuracy with 100 points or less. Mike LaBonte commented that he has seen high frequency effects that change the simulation between filtered and unfiltered tables. Bob Haller noted that an internal tool has a 1000 point limit in tables. Michael Cohen has seen IBIS models with data points in tables commented out to comply with the 100 point restriction. Arpad Muranyi elaborated on the issue. The IBIS Specification is clear that for VI tables, the 100 point limit applies to the voltage axis. However for VT tables, it is not clear whether the 100 point limit applies to the time axis or to each of the voltage columns. The historical rationale for the 100 point limitation was that some SPICE controlled source table formats were limited to 100 table points. Furthermore, Arpad indicated that the 100 point limit was not a problem for the VI tables. He has an algorithm to select the best 100 points out of a larger number of extracted points. The points at which the maximum table curvature occurs is in the same region for VI tables. However, VT tables provide the biggest challenge for providing accurate data with 100 points. The typical, minimum, and maximum column waveforms tend to be shifted with respect to each other. The points of maximum curvature where you want the highest density of points tend to be in different regions of the time axis. Stephen Peters also noted that he has seen the areas of maximum curvature to be at different time regions. So each table could be theoretically limited to having a different set of 33 time points spread out in different time regions. This could provide a much courser resolution for each of the columns and could compromise the accuracy of the data. In a SPICE implementation of IBIS comparison with the structural SPICE model simulation, Arpad encountered a situation where more VT points were needed to achieve acceptable accuracy. The general agreement was that the 100 point limit should be relaxed. Bob Ross listed some options: Do nothing - keep the 100 point limit Allow the 100 point limit to be interpreted for each column Raise the 100 point limit to a higher number (say, 1000 points) Do not provide a limit. The consensus was to provide a conservative limit such as 1000. If no limit is provided, valid IBIS models might be created with an unnecessarily large number of points. This could create very large databases and slow down the simulations. The option of changing the limit to apply to each column appeared to be an unnecessary complication in any model generation utility such as s2ibis2. Arpad commented that he allows the option to fill in the NA data with numerical values. Even though the 100 point limitation is in IBIS Version 3.2, the ibischk3 parser could be changed to issue a Warning message instead of an error message since there are cases where the additional points are needed. Bob Ross commented that a BIRD needs to be generated for IBIS Version 4.X to increase the number of points. 1001 points would allow numerically nice endpoints such as 0 and 10 ns with equally spaced points for easy automated generation. However, it should be recommended that more than 100 points should be used only in situations where it is necessary for accuracy. Arpad commented that in any case, the IBIS Specification needs to be clarified concerning whether the limit applies to the number of rows in the table (X-axis) or to the number of numerical data values in each column (Y-axis). CONNECTOR PROPOSAL REVIEW Matthew Flora reported that Gus Panella is working on a description of the matrices in the Connector Model proposal. SINGLE ENDED AND DIFFERENTIAL MODEL SELECTION (New Issue) Arpad Muranyi raised the concern on the IBIS reflector that some devices have outputs which can be used for differential or single ended operation. Michael Cohen added that he uses a SCSI chip with these characteristics. There is no provision within IBIS Version 3.2 to handle this in one component. The solution on the reflector was to provide two separate component models. Bob Ross indicated that this was the correct response. We have discussed this issue in the past. To resolve this within IBIS we might have to write a BIRD on a differential model selector. IBIS 4.X FEATURES Bob Ross briefly mentioned some features requested for IBIS Version 4.X: Input Tables Removal of 100 Point Limit Differential Overshoots Possible SPICE/IMIC Linkages for Netlists and Models EMI Extensions Connector Models Accuracy Specification Extensions Syed Huq added that differential loads should be considered. Bob noted that more discussion should occur at the IBIS Summit Meeting. Final comment - Bob Haller would like to reserve some meeting time for the IBIS Accuracy Specification Issues. Bob suggested that the changes will be introduced at the Summit. Discussion can be scheduled at the next teleconference meeting. NEXT MEETING: The next meeting is the EIA IBIS Open Forum Summit Meeting on Monday, June 21, 1999 in the Hilton Hotel in New Orleans, Louisiana. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Interconnectix BU of 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-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 SECRETARY: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 17641 NE 67th Court Redmond, WA 98052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic Systems (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 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 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 Fri Jun 4 12:38:04 1999 Received: from ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA12341 for ; Fri, 4 Jun 1999 12:38:03 -0700 (PDT) From: micohen@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id PAA39228; Fri, 4 Jun 1999 15:30:27 -0400 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v1.8) with SMTP id PAA32480; Fri, 4 Jun 1999 15:31:34 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256786.006B41B6 ; Fri, 4 Jun 1999 15:31:31 -0400 X-Lotus-FromDomain: IBMUS To: si-list@silab.eng.sun.com, ibis@eda.org Message-ID: <85256786.006B3FEB.00@d54mta04.raleigh.ibm.com> Date: Fri, 4 Jun 1999 15:30:59 -0400 Subject: IBIS Subcommittee Requests Input Regarding S2IBIS2 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, May 28, 1999, the IBIS Committee, through the IBIS Open Forum Meeting, decided to evaluate the requirements of taking ownership of the Spice to IBIS tool (s2ibis2), originally developed at North Carolina State University. created a subcommittee to evaluate the current condition and recommend changes to the , back to the IBIS Committee. Regards, Michael Cohen IBM Personal Systems Group Design Tools Department D-26D/B-201/R-D104H 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919-543-4042 (T/L 441-4042) FAX: 919-543-8221 (T/L 441-8221) Internet Address: micohen@us.ibm.com IBM Internal Addresses: From Lotus Notes (#1): Michael Cohen/Raleigh/IBM From Lotus Notes (#2): micohen@ibmus From VM: micohen@ibmusm21 From owner-ibis Fri Jun 4 13:42:15 1999 Received: from ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA12445 for ; Fri, 4 Jun 1999 13:42:14 -0700 (PDT) From: micohen@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id QAA82234; Fri, 4 Jun 1999 16:34:38 -0400 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v1.8) with SMTP id QAA40344; Fri, 4 Jun 1999 16:35:48 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256786.00712081 ; Fri, 4 Jun 1999 16:35:38 -0400 X-Lotus-FromDomain: IBMUS To: si-list@silab.eng.sun.com, ibis@eda.org Message-ID: <85256786.00711F3F.00@d54mta04.raleigh.ibm.com> Date: Fri, 4 Jun 1999 16:35:07 -0400 Subject: RE: IBIS Subcommittee Requests Input Regarding S2IBIS2 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sorry, all. My post was accidentally sent prematurely. Please watch the reflectors for the official version; I will be sending it out later today. Regards, Michael Cohen IBM Personal Systems Group Design Tools Department D-26D/B-201/R-D104H 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919-543-4042 (T/L 441-4042) FAX: 919-543-8221 (T/L 441-8221) Internet Address: micohen@us.ibm.com IBM Internal Addresses: From Lotus Notes (#1): Michael Cohen/Raleigh/IBM From Lotus Notes (#2): micohen@ibmus From VM: micohen@ibmusm21 "Muranyi, Arpad" on 06/04/99 04:26:18 PM To: Michael Cohen/Raleigh/IBM@IBMUS cc: Subject: RE: IBIS Subcommittee Requests Input Regarding S2IBIS2 This mail seems to be corrupted. Could you please post it again? Arpad ==================================================================== -----Original Message----- From: micohen@us.ibm.com [mailto:micohen@us.ibm.com] Sent: Friday, June 04, 1999 12:31 PM To: si-list@silab.eng.sun.com; ibis@eda.org Subject: IBIS Subcommittee Requests Input Regarding S2IBIS2 On Friday, May 28, 1999, the IBIS Committee, through the IBIS Open Forum Meeting, decided to evaluate the requirements of taking ownership of the Spice to IBIS tool (s2ibis2), originally developed at North Carolina State University. created a subcommittee to evaluate the current condition and recommend changes to the , back to the IBIS Committee. Regards, Michael Cohen IBM Personal Systems Group Design Tools Department D-26D/B-201/R-D104H 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919-543-4042 (T/L 441-4042) FAX: 919-543-8221 (T/L 441-8221) Internet Address: micohen@us.ibm.com IBM Internal Addresses: From Lotus Notes (#1): Michael Cohen/Raleigh/IBM From Lotus Notes (#2): micohen@ibmus From VM: micohen@ibmusm21 From owner-ibis Fri Jun 4 14:32:45 1999 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA12606 for ; Fri, 4 Jun 1999 14:32:44 -0700 (PDT) From: micohen@us.ibm.com Received: from southrelay02.raleigh.ibm.com by smtp3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA18382; Fri, 4 Jun 1999 17:25:49 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v1.8) with SMTP id RAA54784; Fri, 4 Jun 1999 17:26:17 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256786.0075C363 ; Fri, 4 Jun 1999 17:26:17 -0400 X-Lotus-FromDomain: IBMUS To: ibis@eda.org, si-list@silab.eng.sun.com Message-ID: <85256786.0075C2C5.00@d54mta04.raleigh.ibm.com> Date: Fri, 4 Jun 1999 17:25:47 -0400 Subject: IBIS Subcommittee Formed to Review Spice to IBIS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello everyone. On May 28, 199, the IBIS Committee, via the IBIS Open Forum Teleconference, formed a subcommittee to determine the viability of taking ownership of the Spice to IBIS (s2ibis2) tool, originally written at North Carolina State University. This subcommittee will eventually report back to the IBIS Committee the following: 1. Any known bugs with the current tool. 2. Any future enhancements for the next generation tool (s2ibis3). From these lists, the IBIS Committee and this subcommittee will draft a "requirements" list, and pending funding, request bids from various sources to update/rewrite the tool. Like the IBIS Parser, we want to keep the Spice to IBIS tool in the public domain (open source). As chairperson of this subcommittee, I am asking for your help. If you are a user, or one of the many programmers, of the current Spice to IBIS tool, I am looking for your feedback to make the next tool better. If you know of any bugs, or have any enhancement requests, please let us know by posting your comments to either the IBIS or SI reflector. If you wish to keep your comments psuedo-confidential, please feel free to send them directly to myself at "micohen@us.ibm.com". Please be as specific as you can. In the case of bug reports, we may need to contact you off-line to get more information and/or testcases. Please send your responses no later than June 18, as we will be discussing this topic at the IBIS Summit Meeting, which will be held Monday, June 21. Disclaimer: all participants on this subcommittee, as well as those on the IBIS Committee, are volunteers, attempting to make this tool better. We are not getting paid, nor receiving any benefits, from this work. So please, be kind with your comments. Regards, Michael Cohen IBM Personal Systems Group Design Tools Department D-26D/B-201/R-D104H 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919-543-4042 (T/L 441-4042) FAX: 919-543-8221 (T/L 441-8221) Internet Address: micohen@us.ibm.com IBM Internal Addresses: From Lotus Notes (#1): Michael Cohen/Raleigh/IBM From Lotus Notes (#2): micohen@ibmus From VM: micohen@ibmusm21 From owner-ibis Mon Jun 7 08:48:00 1999 Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by server.eda.org (8.8.5/8.8.3) with SMTP id IAA20101 for ; Mon, 7 Jun 1999 08:47:59 -0700 (PDT) Received: from mailext03.compaq.com by mailext03.compaq.com via smail with esmtp id for ; Mon, 7 Jun 99 10:41:48 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 27-oct-98) Received: from mail.compaq.com([not looked up]) (peer mailint02.compaq.com[207.18.199.35]) by mailext03.compaq.com with SMTP id rcv026205; Mon, 7 Jun 1999 10:41:47 -0500 (CDT) Received: from exchou-gh01.im.hou.compaq.com(really [172.18.219.203]) by mail.compaq.com via sendmail with esmtp id for ; Mon, 7 Jun 99 10:39:54 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 18-dec-97) Received: by exchou-gh01.im.hou.compaq.com with Internet Mail Service (5.5.2559.0) id ; Mon, 7 Jun 1999 10:39:53 -0500 Message-ID: <427351B4DEABD111A99400805F19E9BB02D62B1B@exchou-prod0901.eng.hou.compaq.com> From: "Beal, Weston" To: ibis@eda.org Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS Date: Mon, 7 Jun 1999 09:12:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2559.0) Content-Type: text/plain; charset="ISO-8859-1" Michael, I think this is a worthy endeavor and I applaud your goal. I've been using s2ibis2q (my Compaq version of s2ibis2) for a couple of years, and have a few particular items that I see as weaknesses. The three items which I fixed were easy and didn't take much time. First the default of 2 significant digits in the spice output was much too little. I changed it to 5 digits and have seen good results. In reality, this should probably be configurable from the control file. The second thing that I fixed was to subtract both the power clamp and ground clamp curves from the pullup and pulldown curves. In general, this is not needed, but I don't want it to bite me in the shorts when I'm not looking. The third thing that I changed was the number of points in the time waveforms from 50 to 101. I have to remove one point to comply with the golden parser, but I get better detail. On the issue of number of points in a curve or waveform, I think the user should be able to define any degree of granularity and the IBIS creator tool should have an algorithm to remove points in linear regions. If the resulting curve still has too many points, then increase the linearity tolerance and try it again. One other thing that bothers me is that the data input files (spice output files) must have the same number of data points at the same voltage or time values. I realize that it would take a bit more work, but I would expect to be able to give any three sets of data and have the IBIS creator interpolate and extrapolate as needed in order to create complete IBIS tables. This is not needed when your spice models behave nicely, but how often does that happen? Most of the time, my spice simulations do not converge very far outside the normal operating range and I am forced to fake data or cut off the good data to the same range as the problem data. Regards, Weston Beal Signal Integrity Engineer Compaq Computer Corp. -----Original Message----- From: micohen@us.ibm.com [mailto:micohen@us.ibm.com] Sent: Friday, 04 June, 1999 4:26 PM To: ibis@eda.org; si-list@silab.eng.sun.com Subject: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS Hello everyone. On May 28, 199, the IBIS Committee, via the IBIS Open Forum Teleconference, formed a subcommittee to determine the viability of taking ownership of the Spice to IBIS (s2ibis2) tool, originally written at North Carolina State University. This subcommittee will eventually report back to the IBIS Committee the following: 1. Any known bugs with the current tool. 2. Any future enhancements for the next generation tool (s2ibis3). From these lists, the IBIS Committee and this subcommittee will draft a "requirements" list, and pending funding, request bids from various sources to update/rewrite the tool. Like the IBIS Parser, we want to keep the Spice to IBIS tool in the public domain (open source). As chairperson of this subcommittee, I am asking for your help. If you are a user, or one of the many programmers, of the current Spice to IBIS tool, I am looking for your feedback to make the next tool better. If you know of any bugs, or have any enhancement requests, please let us know by posting your comments to either the IBIS or SI reflector. If you wish to keep your comments psuedo-confidential, please feel free to send them directly to myself at "micohen@us.ibm.com". Please be as specific as you can. In the case of bug reports, we may need to contact you off-line to get more information and/or testcases. Please send your responses no later than June 18, as we will be discussing this topic at the IBIS Summit Meeting, which will be held Monday, June 21. Disclaimer: all participants on this subcommittee, as well as those on the IBIS Committee, are volunteers, attempting to make this tool better. We are not getting paid, nor receiving any benefits, from this work. So please, be kind with your comments. Regards, Michael Cohen IBM Personal Systems Group Design Tools Department D-26D/B-201/R-D104H 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919-543-4042 (T/L 441-4042) FAX: 919-543-8221 (T/L 441-8221) Internet Address: micohen@us.ibm.com IBM Internal Addresses: From Lotus Notes (#1): Michael Cohen/Raleigh/IBM From Lotus Notes (#2): micohen@ibmus From VM: micohen@ibmusm21 **** To unsubscribe from si-list: send e-mail to majordomo@silab.eng.sun.com. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list **** From owner-ibis Mon Jun 7 12:29:26 1999 Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA21160 for ; Mon, 7 Jun 1999 12:29:26 -0700 (PDT) Received: from hyperstar (ip28.du1.lynn.nwlink.com [209.20.140.28]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id MAA00804; Mon, 7 Jun 1999 12:22:52 -0700 (PDT) Message-Id: <199906071922.MAA00804@smtp.nwlink.com> X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 07 Jun 1999 12:18:33 -0700 To: "Beal, Weston" , ibis@eda.org From: Kellee Crisafulli Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS In-Reply-To: <427351B4DEABD111A99400805F19E9BB02D62B1B@exchou-prod0901.e ng.hou.compaq.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi I have a comment on Weston's comment on the number of data points. I disagree on one point. Instead of increasing the number of points generated in the IBIS file the spice to IBIS tool should improve the quality of the points choosen. I can hand build files with 50 points that out perform files with 400 points. The big gain is that the FILE SIZE is reduced with higher accuracy. Large IBIS files will take up many megabytes on 1000's of hard drives. The V/I and V/T tables are the largest part of IBIS files. Increasing them 4 x will generally increase the file size 3 x or more. >The third thing that I changed was the number of points in the time >waveforms from 50 to 101. I have to remove one point to comply with the >golden parser, but I get better detail. On the issue of number of points in >a curve or waveform, I think the user should be able to define any degree of >granularity and the IBIS creator tool should have an algorithm to remove >points in linear regions. If the resulting curve still has too many points, >then increase the linearity tolerance and try it again. Best wishes... Kellee From owner-ibis Mon Jun 7 23:45:25 1999 Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by server.eda.org (8.8.5/8.8.3) with SMTP id XAA22880 for ; Mon, 7 Jun 1999 23:45:25 -0700 (PDT) Received: from mailext03.compaq.com by mailext03.compaq.com via smail with esmtp id for ; Tue, 8 Jun 99 01:39:26 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 27-oct-98) Received: from mail.compaq.com([not looked up]) (peer mailint02.compaq.com[207.18.199.35]) by mailext03.compaq.com with SMTP id rcv020530; Tue, 8 Jun 1999 01:39:21 -0500 (CDT) Received: from exchou-gh02.im.hou.compaq.com(really [172.18.219.204]) by mail.compaq.com via sendmail with esmtp id for ; Mon, 7 Jun 99 18:13:00 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 18-dec-97) Received: by exchou-gh02.im.hou.compaq.com with Internet Mail Service (5.5.2559.0) id ; Mon, 7 Jun 1999 18:11:54 -0500 Message-ID: <427351B4DEABD111A99400805F19E9BB02D62B22@exchou-prod0901.eng.hou.compaq.com> From: "Beal, Weston" To: "'Kellee Crisafulli'" , ibis@eda.org Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS Date: Mon, 7 Jun 1999 18:11:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2559.0) Content-Type: text/plain; charset="iso-8859-1" Kellee, You're disagreeing a mute point. Your point was the same point I was trying to state by saying, "the IBIS creator tool should have an algorithm to remove points in linear regions." We should delete all these extra data points. The problem that s2ibis has now is that all points are equal difference. They should be closer in knee points and very sparse is linear regions. The IBIS creator tool should have an algorithm to clean out extra data. So, I agree with you and now you can agree with me. Later, Weston Beal Signal Integrity Engineer Compaq Computer Corp. -----Original Message----- From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] Sent: Monday, 07 June, 1999 2:19 PM To: Beal, Weston; ibis@eda.org Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS Hi I have a comment on Weston's comment on the number of data points. I disagree on one point. Instead of increasing the number of points generated in the IBIS file the spice to IBIS tool should improve the quality of the points choosen. I can hand build files with 50 points that out perform files with 400 points. The big gain is that the FILE SIZE is reduced with higher accuracy. Large IBIS files will take up many megabytes on 1000's of hard drives. The V/I and V/T tables are the largest part of IBIS files. Increasing them 4 x will generally increase the file size 3 x or more. >The third thing that I changed was the number of points in the time >waveforms from 50 to 101. I have to remove one point to comply with the >golden parser, but I get better detail. On the issue of number of points in >a curve or waveform, I think the user should be able to define any degree of >granularity and the IBIS creator tool should have an algorithm to remove >points in linear regions. If the resulting curve still has too many points, >then increase the linearity tolerance and try it again. Best wishes... Kellee From owner-ibis Tue Jun 8 09:39:05 1999 Received: from mail-gw.pacbell.net (mail-gw.pacbell.net [206.13.28.25]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA26672 for ; Tue, 8 Jun 1999 09:39:05 -0700 (PDT) From: jonp@pacbell.net Received: from postoffice.pacbell.net (ppp-209-79-182-234.vntrcs.pacbell.net [209.79.182.234]) by mail-gw.pacbell.net (8.9.3/8.9.3) with ESMTP id JAA25740; Tue, 8 Jun 1999 09:29:47 -0700 (PDT) Message-ID: <375D442C.7AD1F960@postoffice.pacbell.net> Date: Tue, 08 Jun 1999 09:26:20 -0700 Reply-To: jonp@pacbell.net X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) MIME-Version: 1.0 To: "Beal, Weston" CC: "'Kellee Crisafulli'" , ibis@eda.org Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS References: <427351B4DEABD111A99400805F19E9BB02D62B22@exchou-prod0901.eng.hou.compaq.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree with Weston. Either that or remove the quite artificial limit of number of points in an IBIS file. I have actually been faced with the problem that even with software to remove extra points I cannot create IBIS models to the accuracy that I desire with the 100 point limitation. jon powell Viewlogic Consulting Services Beal, Weston wrote: > Kellee, > > You're disagreeing a mute point. Your point was the same point I was trying > to state by saying, "the IBIS creator tool should have an algorithm to > remove points in linear regions." We should delete all these extra data > points. The problem that s2ibis has now is that all points are equal > difference. They should be closer in knee points and very sparse is linear > regions. The IBIS creator tool should have an algorithm to clean out extra > data. > > So, I agree with you and now you can agree with me. > > Later, > Weston Beal > Signal Integrity Engineer > Compaq Computer Corp. > > -----Original Message----- > From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] > Sent: Monday, 07 June, 1999 2:19 PM > To: Beal, Weston; ibis@eda.org > Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to > Review Spice to IBIS > > Hi > > I have a comment on Weston's comment on the number of data > points. > I disagree on one point. Instead of increasing the number > of points generated > in the IBIS file the spice to IBIS tool should improve the > quality of the > points > choosen. > > I can hand build files with 50 points that out perform files > with 400 points. > The big gain is that the FILE SIZE is reduced with higher > accuracy. > Large IBIS files will take up many megabytes on 1000's of > hard drives. > The V/I and V/T tables are the largest part of IBIS files. > Increasing them 4 x will generally increase the file size 3 > x or more. > > >The third thing that I changed was the number of points in > the time > >waveforms from 50 to 101. I have to remove one point to > comply with the > >golden parser, but I get better detail. On the issue of > number of points in > >a curve or waveform, I think the user should be able to > define any degree of > >granularity and the IBIS creator tool should have an > algorithm to remove > >points in linear regions. If the resulting curve still has > too many points, > >then increase the linearity tolerance and try it again. > > Best wishes... > Kellee From owner-ibis Tue Jun 8 11:52:43 1999 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 LAA27137 for ; Tue, 8 Jun 1999 11:52:42 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA03927; Tue, 8 Jun 1999 11:44:07 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA02802; Tue, 8 Jun 1999 11:44:05 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <375D6476.16EA8240@mentor.com> Date: Tue, 08 Jun 1999 11:44:06 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org CC: jonp@pacbell.net, "Beal, Weston" , "'Kellee Crisafulli'" Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS References: <427351B4DEABD111A99400805F19E9BB02D62B22@exchou-prod0901.eng.hou.compaq.com> <375D442C.7AD1F960@postoffice.pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: We the 100 point VT limit up at the last IBIS Meeting based on the fact that several people felt that accuracy could be compromised. The general consensus was to consider a conservative 1000(1) point limit for a future Version of IBIS. An expanded discussion is in the minutes stored at http://www.eda.org/pub/ibis/minutes/min1999/m052899.txt I think we should consider more flexability regarding the number of points (including going beyond the limit) in the upgraded s2ibis2/3 utility. Bob Ross Mentor Graphics jonp@pacbell.net wrote: > > I agree with Weston. > > Either that or remove the quite artificial limit of number of points in an IBIS > file. > I have actually been faced with the problem that even with software to remove > extra points I cannot > create IBIS models to the accuracy that I desire with the 100 point limitation. > > jon powell > Viewlogic Consulting Services > > Beal, Weston wrote: > > > Kellee, > > > > You're disagreeing a mute point. Your point was the same point I was trying > > to state by saying, "the IBIS creator tool should have an algorithm to > > remove points in linear regions." We should delete all these extra data > > points. The problem that s2ibis has now is that all points are equal > > difference. They should be closer in knee points and very sparse is linear > > regions. The IBIS creator tool should have an algorithm to clean out extra > > data. > > > > So, I agree with you and now you can agree with me. > > > > Later, > > Weston Beal > > Signal Integrity Engineer > > Compaq Computer Corp. > > > > -----Original Message----- > > From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] > > Sent: Monday, 07 June, 1999 2:19 PM > > To: Beal, Weston; ibis@eda.org > > Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to > > Review Spice to IBIS > > > > Hi > > > > I have a comment on Weston's comment on the number of data > > points. > > I disagree on one point. Instead of increasing the number > > of points generated > > in the IBIS file the spice to IBIS tool should improve the > > quality of the > > points > > choosen. > > > > I can hand build files with 50 points that out perform files > > with 400 points. > > The big gain is that the FILE SIZE is reduced with higher > > accuracy. > > Large IBIS files will take up many megabytes on 1000's of > > hard drives. > > The V/I and V/T tables are the largest part of IBIS files. > > Increasing them 4 x will generally increase the file size 3 > > x or more. > > > > >The third thing that I changed was the number of points in > > the time > > >waveforms from 50 to 101. I have to remove one point to > > comply with the > > >golden parser, but I get better detail. On the issue of > > number of points in > > >a curve or waveform, I think the user should be able to > > define any degree of > > >granularity and the IBIS creator tool should have an > > algorithm to remove > > >points in linear regions. If the resulting curve still has > > too many points, > > >then increase the linearity tolerance and try it again. > > > > Best wishes... > > Kellee From owner-ibis Tue Jun 8 17:06:32 1999 Received: from ptldpop2.ptld.uswest.net (ptldpop2.ptld.uswest.net [198.36.160.2]) by server.eda.org (8.8.5/8.8.3) with SMTP id RAA28135 for ; Tue, 8 Jun 1999 17:06:31 -0700 (PDT) Received: (qmail 5887 invoked by alias); 9 Jun 1999 00:00:34 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 5862 invoked by uid 0); 9 Jun 1999 00:00:33 -0000 Received: from premiumf6.ptld.uswest.net (HELO vasthorizons.com) (207.225.90.6) by ptldpop2.ptld.uswest.net with SMTP; 9 Jun 1999 00:00:33 -0000 Message-ID: <375DAE9F.789B3D3A@vasthorizons.com> Date: Tue, 08 Jun 1999 17:00:31 -0700 From: Scott McMorrow Reply-To: scott@vasthorizons.com X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS References: <427351B4DEABD111A99400805F19E9BB02D62B22@exchou-prod0901.eng.hou.compaq.com> <375D442C.7AD1F960@postoffice.pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I second Jon's opinon. There is no real reason to limit the number of points in IV or VT tables. I have often used a simulator which allows an arbitrary number of points over 100 to create high resolution simulations. 256 to 512 is often useful to capture rising edge timing information accurate to 1ps, along with driver overshoot behavior to within 1 mv of HSpice simulations. Model size makes no difference to me. It is the result that matters. Scott McMorrow SiQual jonp@pacbell.net wrote: > I agree with Weston. > > Either that or remove the quite artificial limit of number of points in an IBIS > file. > I have actually been faced with the problem that even with software to remove > extra points I cannot > create IBIS models to the accuracy that I desire with the 100 point limitation. > > jon powell > Viewlogic Consulting Services > > Beal, Weston wrote: > > > Kellee, > > > > You're disagreeing a mute point. Your point was the same point I was trying > > to state by saying, "the IBIS creator tool should have an algorithm to > > remove points in linear regions." We should delete all these extra data > > points. The problem that s2ibis has now is that all points are equal > > difference. They should be closer in knee points and very sparse is linear > > regions. The IBIS creator tool should have an algorithm to clean out extra > > data. > > > > So, I agree with you and now you can agree with me. > > > > Later, > > Weston Beal > > Signal Integrity Engineer > > Compaq Computer Corp. > > > > -----Original Message----- > > From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] > > Sent: Monday, 07 June, 1999 2:19 PM > > To: Beal, Weston; ibis@eda.org > > Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to > > Review Spice to IBIS > > > > Hi > > > > I have a comment on Weston's comment on the number of data > > points. > > I disagree on one point. Instead of increasing the number > > of points generated > > in the IBIS file the spice to IBIS tool should improve the > > quality of the > > points > > choosen. > > > > I can hand build files with 50 points that out perform files > > with 400 points. > > The big gain is that the FILE SIZE is reduced with higher > > accuracy. > > Large IBIS files will take up many megabytes on 1000's of > > hard drives. > > The V/I and V/T tables are the largest part of IBIS files. > > Increasing them 4 x will generally increase the file size 3 > > x or more. > > > > >The third thing that I changed was the number of points in > > the time > > >waveforms from 50 to 101. I have to remove one point to > > comply with the > > >golden parser, but I get better detail. On the issue of > > number of points in > > >a curve or waveform, I think the user should be able to > > define any degree of > > >granularity and the IBIS creator tool should have an > > algorithm to remove > > >points in linear regions. If the resulting curve still has > > too many points, > > >then increase the linearity tolerance and try it again. > > > > Best wishes... > > Kellee From owner-ibis Tue Jun 8 21:20:06 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id VAA28670 for ; Tue, 8 Jun 1999 21:20:05 -0700 (PDT) Received: from Kellee98 ([192.168.148.110]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id UAA27233; Tue, 8 Jun 1999 20:25:24 -0700 Message-Id: <199906090325.UAA27233@jake.hyperlynx.com> X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 08 Jun 1999 21:14:09 -0700 To: scott@vasthorizons.com, ibis@eda.org From: Kellee Crisafulli Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS In-Reply-To: <375DAE9F.789B3D3A@vasthorizons.com> References: <427351B4DEABD111A99400805F19E9BB02D62B22@exchou-prod0901.eng.hou.compaq.com> <375D442C.7AD1F960@postoffice.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id VAA28672 Hi all, At the risk of repeating myself there are several very good reasons to limit the number of points in the IV and VT tables. e.g. disk size, transfer time, overall accuracy improvement. The last one may surprise you but I do feel that including for example a 3rd VT table buys more than increasing the number of points for most models. I do agree the number of points could be increased to say 256 to pick yet another arbitrary spot on the wall. I would prefer to see a model creator like Arpad propose a new limit based on actual demonstrated requirements where some form of data reduction is used. I feel we should keep this number as small as we can and still create accurate models to insure the files sizes and download times are reasonable. I think the biggest problem here is spice to ibis. People are always generating models with the maximum number of points. I see many many models that will work EXACTLY the same with 1/3 this many points if they are placed sensibly instead of using a linear spread. I am worried that if we set the limit at 1000 we will have all the new models with 1000 points...... Just doesn't make sense to me sorry... especially with more and more VT tables being used. best wishes... Kellee At 05:00 PM 6/8/99 -0700, Scott McMorrow wrote: >I second Jon's opinon. > >There is no real reason to limit the number of points in >IV or VT tables. I have often used a simulator which allows >an arbitrary number of points over 100 to create high >resolution simulations. 256 to 512 is often useful to >capture rising edge timing information accurate to 1ps, along >with driver overshoot behavior to within 1 mv of HSpice >simulations. > >Model size makes no difference to me. It is the result that >matters. > >Scott McMorrow >SiQual > >jonp@pacbell.net wrote: > >> I agree with Weston. >> >> Either that or remove the quite artificial limit of number of points in an IBIS >> file. >> I have actually been faced with the problem that even with software to remove >> extra points I cannot >> create IBIS models to the accuracy that I desire with the 100 point limitation. >> >> jon powell >> Viewlogic Consulting Services >> >> Beal, Weston wrote: >> >> > Kellee, >> > >> > You're disagreeing a mute point. Your point was the same point I was trying >> > to state by saying, "the IBIS creator tool should have an algorithm to >> > remove points in linear regions." We should delete all these extra data >> > points. The problem that s2ibis has now is that all points are equal >> > difference. They should be closer in knee points and very sparse is linear >> > regions. The IBIS creator tool should have an algorithm to clean out extra >> > data. >> > >> > So, I agree with you and now you can agree with me. >> > >> > Later, >> > Weston Beal >> > Signal Integrity Engineer >> > Compaq Computer Corp. >> > >> > -----Original Message----- >> > From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] >> > Sent: Monday, 07 June, 1999 2:19 PM >> > To: Beal, Weston; ibis@eda.org >> > Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to >> > Review Spice to IBIS >> > >> > Hi >> > >> > I have a comment on Weston's comment on the number of data >> > points. >> > I disagree on one point. Instead of increasing the number >> > of points generated >> > in the IBIS file the spice to IBIS tool should improve the >> > quality of the >> > points >> > choosen. >> > >> > I can hand build files with 50 points that out perform files >> > with 400 points. >> > The big gain is that the FILE SIZE is reduced with higher >> > accuracy. >> > Large IBIS files will take up many megabytes on 1000's of >> > hard drives. >> > The V/I and V/T tables are the largest part of IBIS files. >> > Increasing them 4 x will generally increase the file size 3 >> > x or more. >> > >> > >The third thing that I changed was the number of points in >> > the time >> > >waveforms from 50 to 101. I have to remove one point to >> > comply with the >> > >golden parser, but I get better detail. On the issue of >> > number of points in >> > >a curve or waveform, I think the user should be able to >> > define any degree of >> > >granularity and the IBIS creator tool should have an >> > algorithm to remove >> > >points in linear regions. If the resulting curve still has >> > too many points, >> > >then increase the linearity tolerance and try it again. >> > >> > Best wishes... >> > Kellee > --------------------------------------------------------- Have a great day.... Kellee Crisafulli HyperLynx, a division of Pads Software Inc. SI,EMC,X-talk and IBIS tools for the Windows platform E-mail: web:   --------------------------------------------------------- From owner-ibis Wed Jun 9 09:08:54 1999 Received: from mail-gw.pacbell.net (mail-gw.pacbell.net [206.13.28.25]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA02944 for ; Wed, 9 Jun 1999 09:08:54 -0700 (PDT) From: jonp@pacbell.net Received: from postoffice.pacbell.net (ppp-209-79-182-187.vntrcs.pacbell.net [209.79.182.187]) by mail-gw.pacbell.net (8.9.3/8.9.3) with ESMTP id JAA12529; Wed, 9 Jun 1999 09:02:53 -0700 (PDT) Message-ID: <375E8F5C.D6FD0174@postoffice.pacbell.net> Date: Wed, 09 Jun 1999 08:59:25 -0700 Reply-To: jonp@pacbell.net X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) MIME-Version: 1.0 To: Kellee Crisafulli CC: scott@vasthorizons.com, ibis@eda.org Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS References: <427351B4DEABD111A99400805F19E9BB02D62B22@exchou-prod0901.eng.hou.compaq.com> <375D442C.7AD1F960@postoffice.pacbell.net> <199906090325.UAA27233@jake.hyperlynx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is a comment from a model creator: I have written extensive software to deal with the ideal selection of non-redundant data. I have found that the 100 point limit is over restrictive for both IV and VT curves. (that is, I have example models that cannot be constructed inside the 100 point limit and still be as accurate as I want (ie. as accurate as the XTK model I made at the same time)). I don't think that model size or transmission time should really be a major consideration. Disk space if free. Bandwidth is soaring. The IBIS format should be relieved of artificial barriers. Our goal should be to make it easy for people to make good IBIS data sets, not a big pain. jon Kellee Crisafulli wrote: > Hi all, > > At the risk of repeating myself there are several very good > reasons to limit the number of points in the IV and VT tables. > e.g. disk size, transfer time, overall accuracy improvement. > > The last one may surprise you but I do feel that including for > example a 3rd VT table buys more than increasing the number of points > for most models. > > I do agree the number of points could be increased to say 256 to > pick yet another arbitrary spot on the wall. I would prefer to > see a model creator like Arpad propose a new limit based on > actual demonstrated requirements where some form of data reduction is > used. > > I feel we should keep this number as small as we can and still create > accurate models to insure the files sizes and download times are reasonable. > > I think the biggest problem here is spice to ibis. People are always > generating models with the maximum number of points. I see many many models > that will work EXACTLY the same with 1/3 this many points if they are placed > sensibly instead of using a linear spread. > > I am worried that if we set the limit at 1000 we will have all the new > models with 1000 points...... > Just doesn't make sense to me sorry... especially with more and more > VT tables being used. > best wishes... > Kellee > > At 05:00 PM 6/8/99 -0700, Scott McMorrow wrote: > >I second Jon's opinon. > > > >There is no real reason to limit the number of points in > >IV or VT tables. I have often used a simulator which allows > >an arbitrary number of points over 100 to create high > >resolution simulations. 256 to 512 is often useful to > >capture rising edge timing information accurate to 1ps, along > >with driver overshoot behavior to within 1 mv of HSpice > >simulations. > > > >Model size makes no difference to me. It is the result that > > >matters. > > > >Scott McMorrow > >SiQual > > > >jonp@pacbell.net wrote: > > > >> I agree with Weston. > >> > >> Either that or remove the quite artificial limit of number of points in > an IBIS > >> file. > >> I have actually been faced with the problem that even with software to > remove > >> extra points I cannot > >> create IBIS models to the accuracy that I desire with the 100 point > limitation. > >> > >> jon powell > >> Viewlogic Consulting Services > >> > >> Beal, Weston wrote: > >> > >> > Kellee, > >> > > >> > You're disagreeing a mute point. Your point was the same point I was > trying > >> > to state by saying, "the IBIS creator tool should have an algorithm to > >> > remove points in linear regions." We should delete all these extra data > >> > points. The problem that s2ibis has now is that all points are equal > >> > difference. They should be closer in knee points and very sparse is > linear > >> > regions. The IBIS creator tool should have an algorithm to clean out > extra > >> > data. > >> > > >> > So, I agree with you and now you can agree with me. > >> > > >> > Later, > >> > Weston Beal > >> > Signal Integrity Engineer > >> > Compaq Computer Corp. > >> > > >> > -----Original Message----- > >> > From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] > >> > Sent: Monday, 07 June, 1999 2:19 PM > >> > To: Beal, Weston; ibis@eda.org > >> > Subject: RE: [SI-LIST] : IBIS Subcommittee > Formed to > >> > Review Spice to IBIS > >> > > >> > Hi > >> > > >> > I have a comment on Weston's comment on the number of > data > >> > points. > >> > I disagree on one point. Instead of increasing the > number > >> > of points generated > >> > in the IBIS file the spice to IBIS tool should improve > the > >> > quality of the > >> > points > >> > choosen. > >> > > >> > I can hand build files with 50 points that out perform > files > >> > with 400 points. > >> > The big gain is that the FILE SIZE is reduced with higher > >> > accuracy. > >> > Large IBIS files will take up many megabytes on 1000's of > >> > hard drives. > >> > The V/I and V/T tables are the largest part of IBIS > files. > >> > Increasing them 4 x will generally increase the file > size 3 > >> > x or more. > >> > > >> > >The third thing that I changed was the number of > points in > >> > the time > >> > >waveforms from 50 to 101. I have to remove one point to > >> > comply with the > >> > >golden parser, but I get better detail. On the issue of > >> > number of points in > > >> > >a curve or waveform, I think the user should be able to > >> > define any degree of > >> > >granularity and the IBIS creator tool should have an > >> > algorithm to remove > >> > >points in linear regions. If the resulting curve > still has > >> > too many points, > >> > >then increase the linearity tolerance and try it again. > >> > > >> > Best wishes... > >> > Kellee > > > --------------------------------------------------------- > Have a great day.... > Kellee Crisafulli > HyperLynx, a division of Pads Software Inc. > SI,EMC,X-talk and IBIS tools for the Windows platform > E-mail: > web: > --------------------------------------------------------- From owner-ibis Wed Jun 9 09:10:47 1999 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 JAA02956 for ; Wed, 9 Jun 1999 09:10:47 -0700 (PDT) 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 JAA28693; Wed, 9 Jun 1999 09:04:20 -0700 (PDT) Message-Id: <199906091604.JAA28693@jasper.cisco.com> Date: Wed, 9 Jun 1999 09:04:20 -0700 (PDT) From: Syed Huq Reply-To: Syed Huq Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS To: scott@vasthorizons.com, ibis@eda.org, kellee@hyperlynx.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: Z/NgKnBWjQ2t4p9I5UgGvA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by server.eda.org id JAA02958 Hi, Kellee makes a good point here. Many times, within s2ibis2, the [Sim time] is left as 15.0ns when you are just trying to get the Rising waveform or Falling waveform. Since most devices will switch within the first 3ns, the rest of the datapoints after 3ns becomes quite useless. If the model developer uses the proper [Sim time] for the technology being simulated, a lower number of V/T points can server the purpose very well. [Sim time] in s2ibis2 dictates the transient simulation time. Regards, Syed Cisco Systems, Inc > > Hi all, > > At the risk of repeating myself there are several very good > reasons to limit the number of points in the IV and VT tables. > e.g. disk size, transfer time, overall accuracy improvement. > > The last one may surprise you but I do feel that including for > example a 3rd VT table buys more than increasing the number of points > for most models. > > I do agree the number of points could be increased to say 256 to > pick yet another arbitrary spot on the wall. I would prefer to > see a model creator like Arpad propose a new limit based on > actual demonstrated requirements where some form of data reduction is > used. > > I feel we should keep this number as small as we can and still create > accurate models to insure the files sizes and download times are reasonable. > > I think the biggest problem here is spice to ibis. People are always > generating models with the maximum number of points. I see many many models > that will work EXACTLY the same with 1/3 this many points if they are placed > sensibly instead of using a linear spread. > > I am worried that if we set the limit at 1000 we will have all the new > models with 1000 points...... > Just doesn't make sense to me sorry... especially with more and more > VT tables being used. > best wishes... > Kellee > > > At 05:00 PM 6/8/99 -0700, Scott McMorrow wrote: > >I second Jon's opinon. > > > >There is no real reason to limit the number of points in > >IV or VT tables. I have often used a simulator which allows > >an arbitrary number of points over 100 to create high > >resolution simulations. 256 to 512 is often useful to > >capture rising edge timing information accurate to 1ps, along > >with driver overshoot behavior to within 1 mv of HSpice > >simulations. > > > >Model size makes no difference to me. It is the result that > > >matters. > > > >Scott McMorrow > >SiQual > > > >jonp@pacbell.net wrote: > > > >> I agree with Weston. > >> > >> Either that or remove the quite artificial limit of number of points in > an IBIS > >> file. > >> I have actually been faced with the problem that even with software to > remove > >> extra points I cannot > >> create IBIS models to the accuracy that I desire with the 100 point > limitation. > >> > >> jon powell > >> Viewlogic Consulting Services > >> > >> Beal, Weston wrote: > >> > >> > Kellee, > >> > > >> > You're disagreeing a mute point. Your point was the same point I was > trying > >> > to state by saying, "the IBIS creator tool should have an algorithm to > >> > remove points in linear regions." We should delete all these extra data > >> > points. The problem that s2ibis has now is that all points are equal > >> > difference. They should be closer in knee points and very sparse is > linear > >> > regions. The IBIS creator tool should have an algorithm to clean out > extra > >> > data. > >> > > >> > So, I agree with you and now you can agree with me. > >> > > >> > Later, > >> > Weston Beal > >> > Signal Integrity Engineer > >> > Compaq Computer Corp. > >> > > >> > -----Original Message----- > >> > From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] > >> > Sent: Monday, 07 June, 1999 2:19 PM > >> > To: Beal, Weston; ibis@eda.org > >> > Subject: RE: [SI-LIST] : IBIS Subcommittee > Formed to > >> > Review Spice to IBIS > >> > > >> > Hi > >> > > >> > I have a comment on Weston's comment on the number of > data > >> > points. > >> > I disagree on one point. Instead of increasing the > number > >> > of points generated > >> > in the IBIS file the spice to IBIS tool should improve > the > >> > quality of the > >> > points > >> > choosen. > >> > > >> > I can hand build files with 50 points that out perform > files > >> > with 400 points. > >> > The big gain is that the FILE SIZE is reduced with higher > >> > accuracy. > >> > Large IBIS files will take up many megabytes on 1000's of > >> > hard drives. > >> > The V/I and V/T tables are the largest part of IBIS > files. > >> > Increasing them 4 x will generally increase the file > size 3 > >> > x or more. > >> > > >> > >The third thing that I changed was the number of > points in > >> > the time > >> > >waveforms from 50 to 101. I have to remove one point to > >> > comply with the > >> > >golden parser, but I get better detail. On the issue of > >> > number of points in > > >> > >a curve or waveform, I think the user should be able to > >> > define any degree of > >> > >granularity and the IBIS creator tool should have an > >> > algorithm to remove > >> > >points in linear regions. If the resulting curve > still has > >> > too many points, > >> > >then increase the linearity tolerance and try it again. > >> > > >> > Best wishes... > >> > Kellee > > > --------------------------------------------------------- > Have a great day.... > Kellee Crisafulli > HyperLynx, a division of Pads Software Inc. > SI,EMC,X-talk and IBIS tools for the Windows platform > E-mail: > web:   > --------------------------------------------------------- > From owner-ibis Wed Jun 9 09:35:56 1999 Received: from oliver.al.dynip.com (root@209-63-189-109.sea.jps.net [209.63.189.109]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA03044 for ; Wed, 9 Jun 1999 09:35:44 -0700 (PDT) Received: from oliver.al.dynip.com (al@oliver [192.168.22.2]) by oliver.al.dynip.com (8.8.7/8.8.7) with SMTP id JAA15290 for ; Wed, 9 Jun 1999 09:23:30 -0700 Sender: al@oliver.al.dynip.com Message-ID: <375E1354.5F1382C@ieee.org> Date: Wed, 09 Jun 1999 07:10:12 +0000 From: Al Davis X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.32 i686) MIME-Version: 1.0 To: ibis@eda.org Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS References: <427351B4DEABD111A99400805F19E9BB02D62B22@exchou-prod0901.eng.hou.compaq.com> <375D442C.7AD1F960@postoffice.pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit jonp@pacbell.net wrote: > I have actually been faced with the problem that even with software to remove > extra points I cannot > create IBIS models to the accuracy that I desire with the 100 point limitation. I don't believe even 10000 points would provide the accuracy you desire, because the limits to accuracy are usually elsewhere. For example .... 100 points chosen to be uniformly spaced in voltage, modeling a 5 volt rising waveform, provides a data point every .2 volts. Assuming that the interpolation is completely bogus, this leads to a worst case error of .1 volts. In reality, interpolation is much better than that, and even this choice of data points is far from optimal, so the accuracy is much better than this. Remember, this isn't DC, but the dynamically changing voltage during a high speed transition. Some questions .... Is your Spice model that accurate? (I don't think so.) If you measure one real unit with perfect accuracy, and compare to the next one, are they this close to each other. (I don't think so.) Are your instruments this accurate? (Don't forget that you change the reading when you attach the probe.) What if the real load is different from the test load? Since the driving impedance is nonlinear, and not specified anywhere, even with perfectly accurate and complete data for the nominal load, all bets are off for anything else. Sure, the voltage is right, into a resistor, but what about reflections and noise? How accurate is the rest of the simulation? There are other ways to improve the accuracy. One obvious one is to carefully select the data points (as Kellee said). Another is to add another VT table with a different load. (As Kellee also said) The third table does much more to improve accuracy than more points will do. Tying the load resistor to a middle voltage does a good job at modeling the overlap. I wouldn't object to removing the limit entirely, because whatever the limit is, most files will use it, without any valid reason. With no limit at all, it is up to the modeler to decide what trade-offs to use. Maybe with nothing in the spec saying how many points to use, we might actually get some good 20 point models, that are more accurate than the 256 (or whatever) point models that we will get if the limit is raised, and the capability is there for those rare cases when you really do need the extra points. So, maybe the answer is to remove the hard limit, but add a comment that tables with more than 50 points are rarely worth the extra space. From owner-ibis Wed Jun 9 11:35:54 1999 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 LAA00342 for ; Wed, 9 Jun 1999 11:35:53 -0700 (PDT) Received: from fmsmsx28.FM.INTEL.COM (fmsmsx28.fm.intel.com [132.233.42.28]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id LAA08082 for ; Wed, 9 Jun 1999 11:29:57 -0700 (PDT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Jun 1999 11:29:56 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512703BB0C6A@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: ibis@eda.org Subject: RE: 100-points limit discussion Date: Wed, 9 Jun 1999 11:29:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" All, I agree with all of you, and at the same time a also disagree with some of the points raised (no pun intended). 1) I believe that we are mixing at least two issues here. One is on the subject of the number of points limit in the IBIS specification, the other is regarding how s2ibis generates points. The third one relates to the intelligence and experience of the model maker. (There is no need to run a waveform simulation for 20 ns at 1 ps step time generating 20k points when the edge reaches steady state in 2-3 ns and 3k points would be sufficient, as someone already mentioned it). IBIS does not need uniformly spaced data, in fact, in Section 3 the spec says the following: | 9) The V/I data tables should use enough data points around sharply curved | areas of the V/I curves to describe the curvature accurately. In linear | regions there is no need to define unnecessary data points. It is not stated, but this also applies to V-t curves. The problem is that s2ibis doesn't know how to pick the best 100 points, so it generates uniformly spaced data with a bunch of redundant, unnecessary points in the linear regions. This uses up the 100 points quickly without much benefit, just because the software doesn't have a best 100 point picker routine. We should not blame the IBIS spec for this deficiency. 2) On the other hand, YES, I do agree that we need to raise the points limit in IBIS because the way things are now DOES limit much needed accuracy in some cases. I demonstrated this in a test case when I overlaid the waveforms of a SPICE and its equivalent IBIS model. The question is what should be the new magic number. 3) History / current situation: The real reason for the 100 points came from the 100 point limits of the PWL sources in the SPICE world. We didn't want to exclude SPICE vendors and users from behavioral simulations. To make that possible without having to ask each SPICE vendor to rewrite all of their PWL sources, we had to introduce the 100 point limit. There were no technical, engineering reasons behind this rule. We found the first problem when I was writing my "Best 100-points" algorithm (for my IBIS Center program that we use internally to make IBIS models). I realized in this process, that there is a difference in the outcome when we count the X-axis points, or the Y-axis points because the typ., min., and max. tables use a common X-axis. When the three sets of Y-axis data are curved in different areas of the X-axis, in the theoretical extreme we could end up with 300 X-axis points while each of the Y-axis has only 100 points. The IBIS 1.1 specification did not say anything about how the 100 points were supposed to be counted. We did discuss this in the Open Forum Teleconference, but choose not to do anything about it in terms of changing or clarifying the IBIS spec. It was verbally said, however, that we should count X-axis points to be safe. I don't remember whether I found this before IBIS 2.1 was ratified or later, but somehow the most important IBIS 2.1 addition, the V-t curves ([... Waveform] tables) inherited the same problem. IBIS 3.x has a few I-V curve related additions. It seems that in effort to make the spec clearer we not only defined it better for the new keywords, but for the sake of consistency we also changed the wording in the usage rules section of the old keywords, such as the [Pulldown], [Pullup], [GND Clamp] and [POWER Clamp]. | ...first and last voltage points on any V/I table. Each V/I | table must have at least 2, but not more than 100, voltage | points. where "voltage points" defines that the counter should count 100 X-axis points. It is interesting to note that the [... Waveform] keywords were still left vague in the IBIS 3.x spec: | ...parses down the table. The waveform table can contain a | maximum of 100 data points. A maximum of 100 waveform tables | are allowed per model. Note that for backward compatibility, 4) Now, why did I write this all down? Well, to give some sense for the proposal that I am about to make here. It can be seen from the above history that, for one, the spec is still inconsistent regarding how to count the points in the waveforms and I-V curves, but more importantly, there is no technical reason for the X-axis counted 100 points in the I-V curves. There is another piece of information that is necessary before I make my proposal. I have not seen any generic PWL source in any SPICE flavor which can handle one X-axis column with multiple Y-axis columns. So if someone uses generic controlled sources in SPICE for building behavioral models which use IBIS data, they will have to separate the typ., min., and max. columns of the IBIS model into three separate PWL sources. Therefore, if we still want to support any SPICE tool by observing their 100 point limits in the PWL sources, it is sufficient to count the points in the Y-axis. On the other hand, if there are newer implementations in SPICE that support IBIS data directly, such as the new B-element in HSPICE, chances are that being new, they can easily implement any (new) IBIS rule. 5) So, based on all this, I propose that we should allow for counting 100 points in the Y-axis. This will still work with any old SPICE PWL source, yet would significantly raise the accuracy of the curves. By doing this, we are really not changing the original intent of the spec. One problem that Bob raised in a private conversation to me is that this will force NA-s into the Y-columns, which is not desirable, even though it is perfectly legal. For this reason he suggested that we should just allow 300 points as counted in the X-axis, which essentially yields the same level of accuracy. The problem I see with this method is that this way the Y-axis can also end up with 300 points, which may prevent the data be used in old SPICE PWL sources. 6) On the other hand, if we do not care about SPICE PWL sources, we can raise the limit to practically any number. The things we need to consider then are what some already brought up in this discussion, file size, distribution, but I would add speed of simulation also. My understanding is that the larger the tables get, the more if-then-else evaluations will need to be done which can slow down the simulator. 7) I tend to agree that unlimited points may not be a good idea, because (forgive me) there is no cure for laziness and stupidity. We may end up with a lot of large files with no reason, or added accuracy. Please comment. Arpad Muranyi Intel Corporation ============================================================================ ======= From owner-ibis Wed Jun 9 11:49:46 1999 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 LAA00362 for ; Wed, 9 Jun 1999 11:49:45 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA26217; Wed, 9 Jun 1999 11:43:15 -0700 (PDT) Received: from kappa2.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA14563; Wed, 9 Jun 1999 11:43:13 -0700 (PDT) Received: by localhost with Microsoft MAPI; Wed, 9 Jun 1999 11:43:48 -0700 Message-ID: <01BEB26D.56A84400.tom_dagostino@mentorg.com> From: tomda To: "'jonp@pacbell.net'" , Kellee Crisafulli Cc: "scott@vasthorizons.com" , "ibis@eda.org" Subject: =?iso-8859-1?Q?RE=3A_=5BSI=2DLIST=5D_=3A_IBIS_Subcommittee_For?= =?iso-8859-1?Q?med_to_Review_Spice_to=09IBIS?= Date: Wed, 9 Jun 1999 11:43:47 -0700 Organization: Mentor Graphics X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There are several questions that beg to be asked to fuel this discussion. How accurate does a model (simulation) need to be? If the accuracy requirement can be nailed down then a meaningful discussion can be had on the number of points required. So far we have not addressed this part of the problem. Once we start down this path we will have to start understanding the algorithms used, different mathematics will generate different results given input data. I've seen too many models that have way too much precision build into the model. E.g., 43.0156898745 mA When people insist on generating lots of decimal points there is a tendency to generate lots of data points to justify the precision in the data. In many cases of models I have seen with this there are datapoints that show the difference in the 6th decimal point. I agree that disk space is free and MIPS are getting there too. Artificial limits on the number of points are not good for models. But maybe there are other ways of solving this problem. Equations for VI curves may be the way to go and let the simulator decide the voltage step is an alternative. Like Jon, I use algorithms to reduce the number of points in our VI tables with very good results. I've not seen VI curves that needed over 100 points after processing. Jon, what kinds of parts require more than 100 points? Tom Dagostino Mentor Graphics -----Original Message----- From: jonp@pacbell.net [SMTP:jonp@pacbell.net] Sent: Wednesday, June 09, 1999 8:59 AM To: Kellee Crisafulli Cc: scott@vasthorizons.com; ibis@eda.org Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS Here is a comment from a model creator: I have written extensive software to deal with the ideal selection of non-redundant data. I have found that the 100 point limit is over restrictive for both IV and VT curves. (that is, I have example models that cannot be constructed inside the 100 point limit and still be as accurate as I want (ie. as accurate as the XTK model I made at the same time)). I don't think that model size or transmission time should really be a major consideration. Disk space if free. Bandwidth is soaring. The IBIS format should be relieved of artificial barriers. Our goal should be to make it easy for people to make good IBIS data sets, not a big pain. jon Kellee Crisafulli wrote: > Hi all, > > At the risk of repeating myself there are several very good > reasons to limit the number of points in the IV and VT tables. > e.g. disk size, transfer time, overall accuracy improvement. > > The last one may surprise you but I do feel that including for > example a 3rd VT table buys more than increasing the number of points > for most models. > > I do agree the number of points could be increased to say 256 to > pick yet another arbitrary spot on the wall. I would prefer to > see a model creator like Arpad propose a new limit based on > actual demonstrated requirements where some form of data reduction is > used. > > I feel we should keep this number as small as we can and still create > accurate models to insure the files sizes and download times are reasonable. > > I think the biggest problem here is spice to ibis. People are always > generating models with the maximum number of points. I see many many models > that will work EXACTLY the same with 1/3 this many points if they are placed > sensibly instead of using a linear spread. > > I am worried that if we set the limit at 1000 we will have all the new > models with 1000 points...... > Just doesn't make sense to me sorry... especially with more and more > VT tables being used. > best wishes... > Kellee > > At 05:00 PM 6/8/99 -0700, Scott McMorrow wrote: > >I second Jon's opinon. > > > >There is no real reason to limit the number of points in > >IV or VT tables. I have often used a simulator which allows > >an arbitrary number of points over 100 to create high > >resolution simulations. 256 to 512 is often useful to > >capture rising edge timing information accurate to 1ps, along > >with driver overshoot behavior to within 1 mv of HSpice > >simulations. > > > >Model size makes no difference to me. It is the result that > > >matters. > > > >Scott McMorrow > >SiQual > > > >jonp@pacbell.net wrote: > > > >> I agree with Weston. > >> > >> Either that or remove the quite artificial limit of number of points in > an IBIS > >> file. > >> I have actually been faced with the problem that even with software to > remove > >> extra points I cannot > >> create IBIS models to the accuracy that I desire with the 100 point > limitation. > >> > >> jon powell > >> Viewlogic Consulting Services > >> > >> Beal, Weston wrote: > >> > >> > Kellee, > >> > > >> > You're disagreeing a mute point. Your point was the same point I was > trying > >> > to state by saying, "the IBIS creator tool should have an algorithm to > >> > remove points in linear regions." We should delete all these extra data > >> > points. The problem that s2ibis has now is that all points are equal > >> > difference. They should be closer in knee points and very sparse is > linear > >> > regions. The IBIS creator tool should have an algorithm to clean out > extra > >> > data. > >> > > >> > So, I agree with you and now you can agree with me. > >> > > >> > Later, > >> > Weston Beal > >> > Signal Integrity Engineer > >> > Compaq Computer Corp. > >> > > >> > -----Original Message----- > >> > From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] > >> > Sent: Monday, 07 June, 1999 2:19 PM > >> > To: Beal, Weston; ibis@eda.org > >> > Subject: RE: [SI-LIST] : IBIS Subcommittee > Formed to > >> > Review Spice to IBIS > >> > > >> > Hi > >> > > >> > I have a comment on Weston's comment on the number of > data > >> > points. > >> > I disagree on one point. Instead of increasing the > number > >> > of points generated > >> > in the IBIS file the spice to IBIS tool should improve > the > >> > quality of the > >> > points > >> > choosen. > >> > > >> > I can hand build files with 50 points that out perform > files > >> > with 400 points. > >> > The big gain is that the FILE SIZE is reduced with higher > >> > accuracy. > >> > Large IBIS files will take up many megabytes on 1000's of > >> > hard drives. > >> > The V/I and V/T tables are the largest part of IBIS > files. > >> > Increasing them 4 x will generally increase the file > size 3 > >> > x or more. > >> > > >> > >The third thing that I changed was the number of > points in > >> > the time > >> > >waveforms from 50 to 101. I have to remove one point to > >> > comply with the > >> > >golden parser, but I get better detail. On the issue of > >> > number of points in > > >> > >a curve or waveform, I think the user should be able to > >> > define any degree of > >> > >granularity and the IBIS creator tool should have an > >> > algorithm to remove > >> > >points in linear regions. If the resulting curve > still has > >> > too many points, > >> > >then increase the linearity tolerance and try it again. > >> > > >> > Best wishes... > >> > Kellee > > > --------------------------------------------------------- > Have a great day.... > Kellee Crisafulli > HyperLynx, a division of Pads Software Inc. > SI,EMC,X-talk and IBIS tools for the Windows platform > E-mail: > web: > --------------------------------------------------------- From owner-ibis Wed Jun 9 12:28:18 1999 Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA00496 for ; Wed, 9 Jun 1999 12:28:17 -0700 (PDT) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 9 Jun 1999 15:21:51 -0400 Message-ID: <1180113EC576D011AADE0060975B88B369CB32@neonet_server1.nexabit.com> From: Marc Humphreys To: ibis@eda.org Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS Date: Wed, 9 Jun 1999 15:21:51 -0400 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Al, I think you took Jon's comment out of context and went off on a tanget, missing his point completely. I think Jon's point was simply that when creating an XTK model from the same initial VI curve data (measured even), via two different methods ( For arguments sake one via the GOLDEN process - probably by hand, and the other via IBIS) that the filtering effect of the 100 point limitation hinders the ability to create two identically behaving models strictly attributable to the (currently)limited VI data in the 'IBIS'ed version' of that same data - No matter how carefully those 100 point where chosen! ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------- Marc Humphreys Nexabit Networks, Inc. 508-460-3355 x236 e-mail: mhumphreys@nexabit.com ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------- > -----Original Message----- > From: Al Davis [SMTP:aldavis@ieee.org] > Sent: Wednesday, June 09, 1999 3:10 AM > To: ibis@eda.org > Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice > to IBIS > > jonp@pacbell.net wrote: > > I have actually been faced with the problem that even with software > to remove > > extra points I cannot > > create IBIS models to the accuracy that I desire with the 100 point > limitation. > > I don't believe even 10000 points would provide the accuracy you > desire, > because the limits to accuracy are usually elsewhere. > > For example .... > 100 points chosen to be uniformly spaced in voltage, modeling a 5 volt > rising waveform, provides a data point every .2 volts. Assuming that > the interpolation is completely bogus, this leads to a worst case > error > of .1 volts. In reality, interpolation is much better than that, and > even this choice of data points is far from optimal, so the accuracy > is > much better than this. Remember, this isn't DC, but the dynamically > changing voltage during a high speed transition. > > Some questions .... > > Is your Spice model that accurate? (I don't think so.) > > If you measure one real unit with perfect accuracy, and compare to the > next one, are they this close to each other. (I don't think so.) > > Are your instruments this accurate? (Don't forget that you change the > reading when you attach the probe.) > > What if the real load is different from the test load? Since the > driving impedance is nonlinear, and not specified anywhere, even with > perfectly accurate and complete data for the nominal load, all bets > are > off for anything else. > > Sure, the voltage is right, into a resistor, but what about > reflections > and noise? > > How accurate is the rest of the simulation? > > > There are other ways to improve the accuracy. One obvious one is to > carefully select the data points (as Kellee said). Another is to add > another VT table with a different load. (As Kellee also said) The > third table does much more to improve accuracy than more points will > do. Tying the load resistor to a middle voltage does a good job at > modeling the overlap. > > > I wouldn't object to removing the limit entirely, because whatever the > limit is, most files will use it, without any valid reason. With no > limit at all, it is up to the modeler to decide what trade-offs to > use. > Maybe with nothing in the spec saying how many points to use, we might > actually get some good 20 point models, that are more accurate than > the > 256 (or whatever) point models that we will get if the limit is > raised, > and the capability is there for those rare cases when you really do > need > the extra points. So, maybe the answer is to remove the hard limit, > but > add a comment that tables with more than 50 points are rarely worth > the > extra space. From owner-ibis Wed Jun 9 13:34:51 1999 Received: from mail-gw5.pacbell.net (mail-gw5.pacbell.net [206.13.28.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA00721 for ; Wed, 9 Jun 1999 13:34:50 -0700 (PDT) From: jonp@pacbell.net Received: from postoffice.pacbell.net (ppp-209-79-182-73.vntrcs.pacbell.net [209.79.182.73]) by mail-gw5.pacbell.net (8.9.3/8.9.3) with ESMTP id NAA16492; Wed, 9 Jun 1999 13:28:51 -0700 (PDT) Message-ID: <375ECDB1.AC6A6137@postoffice.pacbell.net> Date: Wed, 09 Jun 1999 13:25:21 -0700 Reply-To: jonp@pacbell.net X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) MIME-Version: 1.0 To: ibis@vhdl.org Subject: [Fwd: 100-points limit discussion] Content-Type: multipart/mixed; boundary="------------24E666D9ADAC15A9706C93A1" This is a multi-part message in MIME format. --------------24E666D9ADAC15A9706C93A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------24E666D9ADAC15A9706C93A1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <375ECD85.713FB317@postoffice.pacbell.net> Date: Wed, 09 Jun 1999 13:24:37 -0700 From: jonp@postoffice.pacbell.net Reply-To: jonp@pacbell.net X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) MIME-Version: 1.0 To: "Muranyi, Arpad" Subject: Re: 100-points limit discussion References: <4575832C8E71D111AC4100A0C96B512703BB0C6A@fmsmsx36.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree with all of Arpad's point except the "laziness and stupidity" issue. I don't think there should be a limit, I think the ibis data should be as easy to generate as possible. I think that all of the burden of doing something difficult should be on the EDA vendors. And since I represent an EDA vendor, I think that this is a fair thing to say. My personal preference is to have all of the data that is possible so that I can decide which part of the data my tools needs to "do its best". I don't want someone else second guessing me by trying to pick out the "right" points. They may be right for me but wrong for my competitor (or vice versa). IBIS should be about data and making it easy for IC vendors to generate that data, not about modeling. Let the data flow !! jon Muranyi, Arpad wrote: > All, > > I agree with all of you, and at the same time a also disagree with some of > the points raised (no pun intended). > > 1) I believe that we are mixing at least two issues here. One is on the > subject of the number of points limit in the IBIS specification, the other > is regarding how s2ibis generates points. The third one relates to the > intelligence and experience of the model maker. (There is no need to run > a waveform simulation for 20 ns at 1 ps step time generating 20k points > when the edge reaches steady state in 2-3 ns and 3k points would be > sufficient, > as someone already mentioned it). > > IBIS does not need uniformly spaced data, in fact, in Section 3 the spec > says > the following: > > | 9) The V/I data tables should use enough data points around sharply > curved > | areas of the V/I curves to describe the curvature accurately. In > linear > | regions there is no need to define unnecessary data points. > > It is not stated, but this also applies to V-t curves. The problem is that > s2ibis doesn't know how to pick the best 100 points, so it generates > uniformly > spaced data with a bunch of redundant, unnecessary points in the linear > regions. > This uses up the 100 points quickly without much benefit, just because the > software doesn't have a best 100 point picker routine. We should not blame > the IBIS spec for this deficiency. > > 2) On the other hand, YES, I do agree that we need to raise the points > limit > in IBIS because the way things are now DOES limit much needed accuracy in > some > cases. I demonstrated this in a test case when I overlaid the waveforms of > a > SPICE and its equivalent IBIS model. The question is what should be the new > magic number. > > 3) History / current situation: The real reason for the 100 points came > from > the 100 point limits of the PWL sources in the SPICE world. We didn't want > to > exclude SPICE vendors and users from behavioral simulations. To make that > possible without having to ask each SPICE vendor to rewrite all of their PWL > sources, we had to introduce the 100 point limit. There were no technical, > engineering reasons behind this rule. > > We found the first problem when I was writing my "Best 100-points" algorithm > (for my IBIS Center program that we use internally to make IBIS models). I > realized in this process, that there is a difference in the outcome when we > count the X-axis points, or the Y-axis points because the typ., min., and > max. > tables use a common X-axis. When the three sets of Y-axis data are curved > in > different areas of the X-axis, in the theoretical extreme we could end up > with > 300 X-axis points while each of the Y-axis has only 100 points. The IBIS > 1.1 > specification did not say anything about how the 100 points were supposed to > be > counted. We did discuss this in the Open Forum Teleconference, but choose > not > to do anything about it in terms of changing or clarifying the IBIS spec. > It > was verbally said, however, that we should count X-axis points to be safe. > > I don't remember whether I found this before IBIS 2.1 was ratified or later, > but > somehow the most important IBIS 2.1 addition, the V-t curves ([... Waveform] > tables) inherited the same problem. > > IBIS 3.x has a few I-V curve related additions. It seems that in effort to > make > the spec clearer we not only defined it better for the new keywords, but for > the > sake of consistency we also changed the wording in the usage rules section > of the > old keywords, such as the [Pulldown], [Pullup], [GND Clamp] and [POWER > Clamp]. > > | ...first and last voltage points on any V/I table. Each V/I > | table must have at least 2, but not more than 100, voltage > | points. > > where "voltage points" defines that the counter should count 100 X-axis > points. > It is interesting to note that the [... Waveform] keywords were still left > vague > in the IBIS 3.x spec: > > | ...parses down the table. The waveform table can contain a > | maximum of 100 data points. A maximum of 100 waveform > tables > | are allowed per model. Note that for backward > compatibility, > > 4) Now, why did I write this all down? Well, to give some sense for the > proposal > that I am about to make here. It can be seen from the above history that, > for one, > the spec is still inconsistent regarding how to count the points in the > waveforms > and I-V curves, but more importantly, there is no technical reason for the > X-axis > counted 100 points in the I-V curves. > > There is another piece of information that is necessary before I make my > proposal. > I have not seen any generic PWL source in any SPICE flavor which can handle > one > X-axis column with multiple Y-axis columns. So if someone uses generic > controlled > sources in SPICE for building behavioral models which use IBIS data, they > will have to > separate the typ., min., and max. columns of the IBIS model into three > separate PWL > sources. Therefore, if we still want to support any SPICE tool by observing > their 100 > point limits in the PWL sources, it is sufficient to count the points in the > Y-axis. > > On the other hand, if there are newer implementations in SPICE that support > IBIS data > directly, such as the new B-element in HSPICE, chances are that being new, > they can > easily implement any (new) IBIS rule. > > 5) So, based on all this, I propose that we should allow for counting 100 > points > in the Y-axis. This will still work with any old SPICE PWL source, yet > would > significantly raise the accuracy of the curves. By doing this, we are > really > not changing the original intent of the spec. > > One problem that Bob raised in a private conversation to me is that this > will force > NA-s into the Y-columns, which is not desirable, even though it is perfectly > legal. > For this reason he suggested that we should just allow 300 points as counted > in the > X-axis, which essentially yields the same level of accuracy. The problem I > see with > this method is that this way the Y-axis can also end up with 300 points, > which may > prevent the data be used in old SPICE PWL sources. > > 6) On the other hand, if we do not care about SPICE PWL sources, we can > raise the > limit to practically any number. The things we need to consider then are > what some > already brought up in this discussion, file size, distribution, but I would > add > speed of simulation also. My understanding is that the larger the tables > get, the > more if-then-else evaluations will need to be done which can slow down the > simulator. > > 7) I tend to agree that unlimited points may not be a good idea, because > (forgive me) > there is no cure for laziness and stupidity. We may end up with a lot of > large files > with no reason, or added accuracy. > > Please comment. > > Arpad Muranyi > Intel Corporation > ============================================================================ > ======= --------------24E666D9ADAC15A9706C93A1-- From owner-ibis Wed Jun 9 13:43:02 1999 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 NAA00740 for ; Wed, 9 Jun 1999 13:43:02 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA13096; Wed, 9 Jun 1999 13:36:36 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA10167; Wed, 9 Jun 1999 13:36:36 -0700 (PDT) Message-ID: <375ED053.17DD4968@mentor.com> Date: Wed, 09 Jun 1999 13:36:35 -0700 From: Ted Creedon X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tomda CC: "'jonp@pacbell.net'" , Kellee Crisafulli , "scott@vasthorizons.com" , "ibis@eda.org" Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS References: <01BEB26D.56A84400.tom_dagostino@mentorg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Correctly written software would treat VI curves as objects which could be arrays of points, fitted curve coefficients, etc. The point is that the software should not care how you represent your data. Mentor has developed an object oriented data model for the IBIS spec including C++ header files. The object oriented approach allows IBIS spec changes to be updated with minimum impact on other software modules. The IBIS committee should investigate data modelling prior to getting too involved with implementation details. Ted Creedon > From owner-ibis Wed Jun 9 14:48:19 1999 Received: from InterJet.apsimtech.com (appliedsim-sdsl784k-gw.mv.best.net [206.184.220.92]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA00903 for ; Wed, 9 Jun 1999 14:48:17 -0700 (PDT) Received: (from daemon@localhost) by InterJet.apsimtech.com (8.8.5/8.8.5) id OAA17388; Wed, 9 Jun 1999 14:33:03 -0700 (PDT) Received: from apsim3.apsimtech.com(192.168.1.103), claiming to be "apsim3" via SMTP by InterJet.apsimtech.com, id smtpd017384; Wed Jun 9 21:32:54 1999 Sender: fred@apsimtech.com Message-ID: <375EDD24.1CF6@apsimtech.com> Date: Wed, 09 Jun 1999 14:31:16 -0700 From: Fred Balistreri Organization: Apsim X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: "Muranyi, Arpad" CC: ibis@eda.org Subject: Re: 100-points limit discussion References: <4575832C8E71D111AC4100A0C96B512703BB0C6A@fmsmsx36.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A few points need to be clarified in Arpad's statements. The 100 point limit did not come from the SPICE world. It came from a restriction in the particuliar brand of SPICE being used by ????? at the time. As an example my company is a SPICE vendor with no restriction on PWL number of points. Our derivitive is Berkeley SPICE 3C1 circa 1980's something. Basing a standard on third party EDA vendor restrictions is @#*%#$#@! in my opinion. My point here is don't blame this on SPICE. There is enough blame going around the SPICE world. This is an IBIS problem. B source may be new in some SPICE programs but its been around at least since Berkeley 3C1 SPICE. Secondly as a model builder my two cents are that 100 points were fine in the original IBIS when there was no v/t information. If done correctly 100 points for I/V information is more than enough. The addition of v/t information may have changed all that. Thirdly, s2ibis is a public program written by students at UNC, and at that its origin is now maybe 3 or 4 years ago. Why is the whole IBIS world relying on this tool? There are a few multi hundreds of million of dollar in sales EDA companies and at least one over 1 billion in sales EDA company that claim support for IBIS. Yet all of these companies I am led to believe rely on an old public domain software program. Oddly enough there is enough complaints and questions brought up by s2ibis that an innocent bystander would have plenty of doubts about this program! My point here is that IBIS is the standard NOT s2ibis....and there are alternatives to s2ibis albiet not free. In my opinion the 100 point limit can be lifted as it seems that its a problem already. Muranyi, Arpad wrote: > > All, > > I agree with all of you, and at the same time a also disagree with some of > the points raised (no pun intended). > > 1) I believe that we are mixing at least two issues here. One is on the > subject of the number of points limit in the IBIS specification, the other > is regarding how s2ibis generates points. The third one relates to the > intelligence and experience of the model maker. (There is no need to run > a waveform simulation for 20 ns at 1 ps step time generating 20k points > when the edge reaches steady state in 2-3 ns and 3k points would be > sufficient, > as someone already mentioned it). > > IBIS does not need uniformly spaced data, in fact, in Section 3 the spec > says > the following: > > | 9) The V/I data tables should use enough data points around sharply > curved > | areas of the V/I curves to describe the curvature accurately. In > linear > | regions there is no need to define unnecessary data points. > > It is not stated, but this also applies to V-t curves. The problem is that > s2ibis doesn't know how to pick the best 100 points, so it generates > uniformly > spaced data with a bunch of redundant, unnecessary points in the linear > regions. > This uses up the 100 points quickly without much benefit, just because the > software doesn't have a best 100 point picker routine. We should not blame > the IBIS spec for this deficiency. > > 2) On the other hand, YES, I do agree that we need to raise the points > limit > in IBIS because the way things are now DOES limit much needed accuracy in > some > cases. I demonstrated this in a test case when I overlaid the waveforms of > a > SPICE and its equivalent IBIS model. The question is what should be the new > magic number. > > 3) History / current situation: The real reason for the 100 points came > from > the 100 point limits of the PWL sources in the SPICE world. We didn't want > to > exclude SPICE vendors and users from behavioral simulations. To make that > possible without having to ask each SPICE vendor to rewrite all of their PWL > sources, we had to introduce the 100 point limit. There were no technical, > engineering reasons behind this rule. > > We found the first problem when I was writing my "Best 100-points" algorithm > (for my IBIS Center program that we use internally to make IBIS models). I > realized in this process, that there is a difference in the outcome when we > count the X-axis points, or the Y-axis points because the typ., min., and > max. > tables use a common X-axis. When the three sets of Y-axis data are curved > in > different areas of the X-axis, in the theoretical extreme we could end up > with > 300 X-axis points while each of the Y-axis has only 100 points. The IBIS > 1.1 > specification did not say anything about how the 100 points were supposed to > be > counted. We did discuss this in the Open Forum Teleconference, but choose > not > to do anything about it in terms of changing or clarifying the IBIS spec. > It > was verbally said, however, that we should count X-axis points to be safe. > > I don't remember whether I found this before IBIS 2.1 was ratified or later, > but > somehow the most important IBIS 2.1 addition, the V-t curves ([... Waveform] > tables) inherited the same problem. > > IBIS 3.x has a few I-V curve related additions. It seems that in effort to > make > the spec clearer we not only defined it better for the new keywords, but for > the > sake of consistency we also changed the wording in the usage rules section > of the > old keywords, such as the [Pulldown], [Pullup], [GND Clamp] and [POWER > Clamp]. > > | ...first and last voltage points on any V/I table. Each V/I > | table must have at least 2, but not more than 100, voltage > | points. > > where "voltage points" defines that the counter should count 100 X-axis > points. > It is interesting to note that the [... Waveform] keywords were still left > vague > in the IBIS 3.x spec: > > | ...parses down the table. The waveform table can contain a > | maximum of 100 data points. A maximum of 100 waveform > tables > | are allowed per model. Note that for backward > compatibility, > > 4) Now, why did I write this all down? Well, to give some sense for the > proposal > that I am about to make here. It can be seen from the above history that, > for one, > the spec is still inconsistent regarding how to count the points in the > waveforms > and I-V curves, but more importantly, there is no technical reason for the > X-axis > counted 100 points in the I-V curves. > > There is another piece of information that is necessary before I make my > proposal. > I have not seen any generic PWL source in any SPICE flavor which can handle > one > X-axis column with multiple Y-axis columns. So if someone uses generic > controlled > sources in SPICE for building behavioral models which use IBIS data, they > will have to > separate the typ., min., and max. columns of the IBIS model into three > separate PWL > sources. Therefore, if we still want to support any SPICE tool by observing > their 100 > point limits in the PWL sources, it is sufficient to count the points in the > Y-axis. > > On the other hand, if there are newer implementations in SPICE that support > IBIS data > directly, such as the new B-element in HSPICE, chances are that being new, > they can > easily implement any (new) IBIS rule. > > 5) So, based on all this, I propose that we should allow for counting 100 > points > in the Y-axis. This will still work with any old SPICE PWL source, yet > would > significantly raise the accuracy of the curves. By doing this, we are > really > not changing the original intent of the spec. > > One problem that Bob raised in a private conversation to me is that this > will force > NA-s into the Y-columns, which is not desirable, even though it is perfectly > legal. > For this reason he suggested that we should just allow 300 points as counted > in the > X-axis, which essentially yields the same level of accuracy. The problem I > see with > this method is that this way the Y-axis can also end up with 300 points, > which may > prevent the data be used in old SPICE PWL sources. > > 6) On the other hand, if we do not care about SPICE PWL sources, we can > raise the > limit to practically any number. The things we need to consider then are > what some > already brought up in this discussion, file size, distribution, but I would > add > speed of simulation also. My understanding is that the larger the tables > get, the > more if-then-else evaluations will need to be done which can slow down the > simulator. > > 7) I tend to agree that unlimited points may not be a good idea, because > (forgive me) > there is no cure for laziness and stupidity. We may end up with a lot of > large files > with no reason, or added accuracy. > > Please comment. > > Arpad Muranyi > Intel Corporation > ============================================================================ > ======= -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com From owner-ibis Thu Jun 10 08:24:20 1999 Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA05920 for ; Thu, 10 Jun 1999 08:24:19 -0700 (PDT) From: jonp@pacbell.net Received: from postoffice.pacbell.net (ppp-209-79-182-246.vntrcs.pacbell.net [209.79.182.246]) by mta1.snfc21.pbi.net (8.8.8/8.7.1+antispam) with ESMTP id IAA10733; Thu, 10 Jun 1999 08:18:06 -0700 (PDT) Message-ID: <375FD65B.675E277B@postoffice.pacbell.net> Date: Thu, 10 Jun 1999 08:14:35 -0700 Reply-To: jonp@pacbell.net X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) MIME-Version: 1.0 To: Fred Balistreri CC: "Muranyi, Arpad" , ibis@eda.org Subject: Re: 100-points limit discussion References: <4575832C8E71D111AC4100A0C96B512703BB0C6A@fmsmsx36.fm.intel.com> <375EDD24.1CF6@apsimtech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fred, We don't use S2IBIS here at Viewlogic. We use an internal tool (that I developed). It is tied heavily to XTK as it uses it for auto QA and such. We are planning on making it available as a product but right now it isn't supportable enough to sell (or give away) to the general public. Things like, it only runs on certain Unix platforms. My group does use this program (called VML for Virtual Modeling Lab) to write and QA the IBIS models that we generate for IC companies. regards, jon Fred Balistreri wrote: > A few points need to be clarified in Arpad's statements. The 100 point > limit did not > come from the SPICE world. It came from a restriction in the particuliar > brand of > SPICE being used by ????? at the time. As an example my company is a > SPICE vendor with > no restriction on PWL number of points. Our derivitive is Berkeley SPICE > 3C1 circa > 1980's something. Basing a standard on third party EDA vendor > restrictions is @#*%#$#@! > in my opinion. My point here is don't blame this on SPICE. There is > enough blame going > around the SPICE world. This is an IBIS problem. B source may be new in > some SPICE > programs but its been around at least since Berkeley 3C1 SPICE. > > Secondly as a model builder my two cents are that 100 points were fine > in the original > IBIS when there was no v/t information. If done correctly 100 points > for I/V > information is more than enough. The addition of v/t information may > have changed all > that. > > Thirdly, s2ibis is a public program written by students at UNC, and at > that its > origin is now maybe 3 or 4 years ago. Why is the whole IBIS world > relying on this > tool? There are a few multi hundreds of million of dollar in sales EDA > companies and > at least one over 1 billion in sales EDA company that claim support for > IBIS. Yet all > of these companies I am led to believe rely on an old public domain > software program. > Oddly enough there is enough complaints and questions brought up by > s2ibis that an > innocent bystander would have plenty of doubts about this program! My > point here is that IBIS is the standard NOT s2ibis....and there are > alternatives to > s2ibis albiet not free. > > In my opinion the 100 point limit can be lifted as it seems that its a > problem > already. > > Muranyi, Arpad wrote: > > > > All, > > > > I agree with all of you, and at the same time a also disagree with some of > > the points raised (no pun intended). > > > > 1) I believe that we are mixing at least two issues here. One is on the > > subject of the number of points limit in the IBIS specification, the other > > is regarding how s2ibis generates points. The third one relates to the > > intelligence and experience of the model maker. (There is no need to run > > a waveform simulation for 20 ns at 1 ps step time generating 20k points > > when the edge reaches steady state in 2-3 ns and 3k points would be > > sufficient, > > as someone already mentioned it). > > > > IBIS does not need uniformly spaced data, in fact, in Section 3 the spec > > says > > the following: > > > > | 9) The V/I data tables should use enough data points around sharply > > curved > > | areas of the V/I curves to describe the curvature accurately. In > > linear > > | regions there is no need to define unnecessary data points. > > > > It is not stated, but this also applies to V-t curves. The problem is that > > s2ibis doesn't know how to pick the best 100 points, so it generates > > uniformly > > spaced data with a bunch of redundant, unnecessary points in the linear > > regions. > > This uses up the 100 points quickly without much benefit, just because the > > software doesn't have a best 100 point picker routine. We should not blame > > the IBIS spec for this deficiency. > > > > 2) On the other hand, YES, I do agree that we need to raise the points > > limit > > in IBIS because the way things are now DOES limit much needed accuracy in > > some > > cases. I demonstrated this in a test case when I overlaid the waveforms of > > a > > SPICE and its equivalent IBIS model. The question is what should be the new > > magic number. > > > > 3) History / current situation: The real reason for the 100 points came > > from > > the 100 point limits of the PWL sources in the SPICE world. We didn't want > > to > > exclude SPICE vendors and users from behavioral simulations. To make that > > possible without having to ask each SPICE vendor to rewrite all of their PWL > > sources, we had to introduce the 100 point limit. There were no technical, > > engineering reasons behind this rule. > > > > We found the first problem when I was writing my "Best 100-points" algorithm > > (for my IBIS Center program that we use internally to make IBIS models). I > > realized in this process, that there is a difference in the outcome when we > > count the X-axis points, or the Y-axis points because the typ., min., and > > max. > > tables use a common X-axis. When the three sets of Y-axis data are curved > > in > > different areas of the X-axis, in the theoretical extreme we could end up > > with > > 300 X-axis points while each of the Y-axis has only 100 points. The IBIS > > 1.1 > > specification did not say anything about how the 100 points were supposed to > > be > > counted. We did discuss this in the Open Forum Teleconference, but choose > > not > > to do anything about it in terms of changing or clarifying the IBIS spec. > > It > > was verbally said, however, that we should count X-axis points to be safe. > > > > I don't remember whether I found this before IBIS 2.1 was ratified or later, > > but > > somehow the most important IBIS 2.1 addition, the V-t curves ([... Waveform] > > tables) inherited the same problem. > > > > IBIS 3.x has a few I-V curve related additions. It seems that in effort to > > make > > the spec clearer we not only defined it better for the new keywords, but for > > the > > sake of consistency we also changed the wording in the usage rules section > > of the > > old keywords, such as the [Pulldown], [Pullup], [GND Clamp] and [POWER > > Clamp]. > > > > | ...first and last voltage points on any V/I table. Each V/I > > | table must have at least 2, but not more than 100, voltage > > | points. > > > > where "voltage points" defines that the counter should count 100 X-axis > > points. > > It is interesting to note that the [... Waveform] keywords were still left > > vague > > in the IBIS 3.x spec: > > > > | ...parses down the table. The waveform table can contain a > > | maximum of 100 data points. A maximum of 100 waveform > > tables > > | are allowed per model. Note that for backward > > compatibility, > > > > 4) Now, why did I write this all down? Well, to give some sense for the > > proposal > > that I am about to make here. It can be seen from the above history that, > > for one, > > the spec is still inconsistent regarding how to count the points in the > > waveforms > > and I-V curves, but more importantly, there is no technical reason for the > > X-axis > > counted 100 points in the I-V curves. > > > > There is another piece of information that is necessary before I make my > > proposal. > > I have not seen any generic PWL source in any SPICE flavor which can handle > > one > > X-axis column with multiple Y-axis columns. So if someone uses generic > > controlled > > sources in SPICE for building behavioral models which use IBIS data, they > > will have to > > separate the typ., min., and max. columns of the IBIS model into three > > separate PWL > > sources. Therefore, if we still want to support any SPICE tool by observing > > their 100 > > point limits in the PWL sources, it is sufficient to count the points in the > > Y-axis. > > > > On the other hand, if there are newer implementations in SPICE that support > > IBIS data > > directly, such as the new B-element in HSPICE, chances are that being new, > > they can > > easily implement any (new) IBIS rule. > > > > 5) So, based on all this, I propose that we should allow for counting 100 > > points > > in the Y-axis. This will still work with any old SPICE PWL source, yet > > would > > significantly raise the accuracy of the curves. By doing this, we are > > really > > not changing the original intent of the spec. > > > > One problem that Bob raised in a private conversation to me is that this > > will force > > NA-s into the Y-columns, which is not desirable, even though it is perfectly > > legal. > > For this reason he suggested that we should just allow 300 points as counted > > in the > > X-axis, which essentially yields the same level of accuracy. The problem I > > see with > > this method is that this way the Y-axis can also end up with 300 points, > > which may > > prevent the data be used in old SPICE PWL sources. > > > > 6) On the other hand, if we do not care about SPICE PWL sources, we can > > raise the > > limit to practically any number. The things we need to consider then are > > what some > > already brought up in this discussion, file size, distribution, but I would > > add > > speed of simulation also. My understanding is that the larger the tables > > get, the > > more if-then-else evaluations will need to be done which can slow down the > > simulator. > > > > 7) I tend to agree that unlimited points may not be a good idea, because > > (forgive me) > > there is no cure for laziness and stupidity. We may end up with a lot of > > large files > > with no reason, or added accuracy. > > > > Please comment. > > > > Arpad Muranyi > > Intel Corporation > > ============================================================================ > > ======= > > -- > Fred Balistreri > fred@apsimtech.com > > http://www.apsimtech.com From owner-ibis Thu Jun 10 08:43:58 1999 Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by server.eda.org (8.8.5/8.8.3) with SMTP id IAA06107 for ; Thu, 10 Jun 1999 08:43:57 -0700 (PDT) Received: from mailext03.compaq.com by mailext03.compaq.com via smail with esmtp id for ; Thu, 10 Jun 99 10:37:42 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 27-oct-98) Received: from mail.compaq.com([not looked up]) (peer mailint02.compaq.com[207.18.199.35]) by mailext03.compaq.com with SMTP id rcv020392; Thu, 10 Jun 1999 10:37:37 -0500 (CDT) Received: from excsin-gh01.asia.compaq.com(really [16.177.2.7]) by mail.compaq.com via sendmail with esmtp id for ; Thu, 10 Jun 99 10:35:30 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 18-dec-97) Received: by EXCSIN-GH01 with Internet Mail Service (5.5.2559.0) id ; Thu, 10 Jun 1999 23:35:28 +0800 Message-ID: From: "Haller, Robert" To: ibis@eda.org Subject: RE: 100-points limit discussion Date: Thu, 10 Jun 1999 23:35:17 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2559.0) Content-Type: text/plain; charset="iso-8859-1" Folks, I have been following this discussion and will reiterate my opinion (given in the most recent IBIS open forum). We have both an internal IBIS format and internal tool that originally had a 100 point IV curve limit (just like IBIS). I found it necessary to increase the number of points in order to accurately model technologies which use high current and are terminated (small changes in V can translate into big changes in I). I found insufficient points in the IV curve caused DC level problems and AC transient inaccuracies. We increased our internal limit to 1000 points which resulted in significant improvement in model accuracy and sufficient headroom so we don't have to visit this again. my $0.02 Bob Robert J. Haller Compaq Computer Corporation AlphaServer Product Development Phone: (978) 493-4112 Fax: (978) 493-0941 robert.haller@compaq.com -----Original Message----- From: jonp@pacbell.net [mailto:jonp@pacbell.net] Sent: Thursday, June 10, 1999 11:15 AM To: Fred Balistreri Cc: Muranyi, Arpad; ibis@eda.org Subject: Re: 100-points limit discussion Fred, We don't use S2IBIS here at Viewlogic. We use an internal tool (that I developed). It is tied heavily to XTK as it uses it for auto QA and such. We are planning on making it available as a product but right now it isn't supportable enough to sell (or give away) to the general public. Things like, it only runs on certain Unix platforms. My group does use this program (called VML for Virtual Modeling Lab) to write and QA the IBIS models that we generate for IC companies. regards, jon Fred Balistreri wrote: > A few points need to be clarified in Arpad's statements. The 100 point > limit did not > come from the SPICE world. It came from a restriction in the particuliar > brand of > SPICE being used by ????? at the time. As an example my company is a > SPICE vendor with > no restriction on PWL number of points. Our derivitive is Berkeley SPICE > 3C1 circa > 1980's something. Basing a standard on third party EDA vendor > restrictions is @#*%#$#@! > in my opinion. My point here is don't blame this on SPICE. There is > enough blame going > around the SPICE world. This is an IBIS problem. B source may be new in > some SPICE > programs but its been around at least since Berkeley 3C1 SPICE. > > Secondly as a model builder my two cents are that 100 points were fine > in the original > IBIS when there was no v/t information. If done correctly 100 points > for I/V > information is more than enough. The addition of v/t information may > have changed all > that. > > Thirdly, s2ibis is a public program written by students at UNC, and at > that its > origin is now maybe 3 or 4 years ago. Why is the whole IBIS world > relying on this > tool? There are a few multi hundreds of million of dollar in sales EDA > companies and > at least one over 1 billion in sales EDA company that claim support for > IBIS. Yet all > of these companies I am led to believe rely on an old public domain > software program. > Oddly enough there is enough complaints and questions brought up by > s2ibis that an > innocent bystander would have plenty of doubts about this program! My > point here is that IBIS is the standard NOT s2ibis....and there are > alternatives to > s2ibis albiet not free. > > In my opinion the 100 point limit can be lifted as it seems that its a > problem > already. > > Muranyi, Arpad wrote: > > > > All, > > > > I agree with all of you, and at the same time a also disagree with some of > > the points raised (no pun intended). > > > > 1) I believe that we are mixing at least two issues here. One is on the > > subject of the number of points limit in the IBIS specification, the other > > is regarding how s2ibis generates points. The third one relates to the > > intelligence and experience of the model maker. (There is no need to run > > a waveform simulation for 20 ns at 1 ps step time generating 20k points > > when the edge reaches steady state in 2-3 ns and 3k points would be > > sufficient, > > as someone already mentioned it). > > > > IBIS does not need uniformly spaced data, in fact, in Section 3 the spec > > says > > the following: > > > > | 9) The V/I data tables should use enough data points around sharply > > curved > > | areas of the V/I curves to describe the curvature accurately. In > > linear > > | regions there is no need to define unnecessary data points. > > > > It is not stated, but this also applies to V-t curves. The problem is that > > s2ibis doesn't know how to pick the best 100 points, so it generates > > uniformly > > spaced data with a bunch of redundant, unnecessary points in the linear > > regions. > > This uses up the 100 points quickly without much benefit, just because the > > software doesn't have a best 100 point picker routine. We should not blame > > the IBIS spec for this deficiency. > > > > 2) On the other hand, YES, I do agree that we need to raise the points > > limit > > in IBIS because the way things are now DOES limit much needed accuracy in > > some > > cases. I demonstrated this in a test case when I overlaid the waveforms of > > a > > SPICE and its equivalent IBIS model. The question is what should be the new > > magic number. > > > > 3) History / current situation: The real reason for the 100 points came > > from > > the 100 point limits of the PWL sources in the SPICE world. We didn't want > > to > > exclude SPICE vendors and users from behavioral simulations. To make that > > possible without having to ask each SPICE vendor to rewrite all of their PWL > > sources, we had to introduce the 100 point limit. There were no technical, > > engineering reasons behind this rule. > > > > We found the first problem when I was writing my "Best 100-points" algorithm > > (for my IBIS Center program that we use internally to make IBIS models). I > > realized in this process, that there is a difference in the outcome when we > > count the X-axis points, or the Y-axis points because the typ., min., and > > max. > > tables use a common X-axis. When the three sets of Y-axis data are curved > > in > > different areas of the X-axis, in the theoretical extreme we could end up > > with > > 300 X-axis points while each of the Y-axis has only 100 points. The IBIS > > 1.1 > > specification did not say anything about how the 100 points were supposed to > > be > > counted. We did discuss this in the Open Forum Teleconference, but choose > > not > > to do anything about it in terms of changing or clarifying the IBIS spec. > > It > > was verbally said, however, that we should count X-axis points to be safe. > > > > I don't remember whether I found this before IBIS 2.1 was ratified or later, > > but > > somehow the most important IBIS 2.1 addition, the V-t curves ([... Waveform] > > tables) inherited the same problem. > > > > IBIS 3.x has a few I-V curve related additions. It seems that in effort to > > make > > the spec clearer we not only defined it better for the new keywords, but for > > the > > sake of consistency we also changed the wording in the usage rules section > > of the > > old keywords, such as the [Pulldown], [Pullup], [GND Clamp] and [POWER > > Clamp]. > > > > | ...first and last voltage points on any V/I table. Each V/I > > | table must have at least 2, but not more than 100, voltage > > | points. > > > > where "voltage points" defines that the counter should count 100 X-axis > > points. > > It is interesting to note that the [... Waveform] keywords were still left > > vague > > in the IBIS 3.x spec: > > > > | ...parses down the table. The waveform table can contain a > > | maximum of 100 data points. A maximum of 100 waveform > > tables > > | are allowed per model. Note that for backward > > compatibility, > > > > 4) Now, why did I write this all down? Well, to give some sense for the > > proposal > > that I am about to make here. It can be seen from the above history that, > > for one, > > the spec is still inconsistent regarding how to count the points in the > > waveforms > > and I-V curves, but more importantly, there is no technical reason for the > > X-axis > > counted 100 points in the I-V curves. > > > > There is another piece of information that is necessary before I make my > > proposal. > > I have not seen any generic PWL source in any SPICE flavor which can handle > > one > > X-axis column with multiple Y-axis columns. So if someone uses generic > > controlled > > sources in SPICE for building behavioral models which use IBIS data, they > > will have to > > separate the typ., min., and max. columns of the IBIS model into three > > separate PWL > > sources. Therefore, if we still want to support any SPICE tool by observing > > their 100 > > point limits in the PWL sources, it is sufficient to count the points in the > > Y-axis. > > > > On the other hand, if there are newer implementations in SPICE that support > > IBIS data > > directly, such as the new B-element in HSPICE, chances are that being new, > > they can > > easily implement any (new) IBIS rule. > > > > 5) So, based on all this, I propose that we should allow for counting 100 > > points > > in the Y-axis. This will still work with any old SPICE PWL source, yet > > would > > significantly raise the accuracy of the curves. By doing this, we are > > really > > not changing the original intent of the spec. > > > > One problem that Bob raised in a private conversation to me is that this > > will force > > NA-s into the Y-columns, which is not desirable, even though it is perfectly > > legal. > > For this reason he suggested that we should just allow 300 points as counted > > in the > > X-axis, which essentially yields the same level of accuracy. The problem I > > see with > > this method is that this way the Y-axis can also end up with 300 points, > > which may > > prevent the data be used in old SPICE PWL sources. > > > > 6) On the other hand, if we do not care about SPICE PWL sources, we can > > raise the > > limit to practically any number. The things we need to consider then are > > what some > > already brought up in this discussion, file size, distribution, but I would > > add > > speed of simulation also. My understanding is that the larger the tables > > get, the > > more if-then-else evaluations will need to be done which can slow down the > > simulator. > > > > 7) I tend to agree that unlimited points may not be a good idea, because > > (forgive me) > > there is no cure for laziness and stupidity. We may end up with a lot of > > large files > > with no reason, or added accuracy. > > > > Please comment. > > > > Arpad Muranyi > > Intel Corporation > > ============================================================================ > > ======= > > -- > Fred Balistreri > fred@apsimtech.com > > http://www.apsimtech.com From owner-ibis Thu Jun 10 10:09:38 1999 Received: from sdcomm.acceltech.com (gw.acceltech.com [134.8.1.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA06454 for ; Thu, 10 Jun 1999 10:09:37 -0700 (PDT) Received: by SDCOMM.acceltech.com with Internet Mail Service (5.5.2232.9) id ; Thu, 10 Jun 1999 10:03:39 -0700 Message-ID: <9E4C2E2E4A6CD211978B00104B61BC136501FD@SDCOMM.acceltech.com> From: Jessica Morrison To: IBIS@eda.org Subject: current version Date: Thu, 10 Jun 1999 10:03:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" What is the currently released version of IBIS? I have seen version 3 files, but I don't know if version 3 is officially released yet. Jessica Morrison ACCEL Technologies 619-350-3000 ext. 120 From owner-ibis Thu Jun 10 10:40:27 1999 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 KAA06614 for ; Thu, 10 Jun 1999 10:40:26 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA19700; Thu, 10 Jun 1999 10:33:59 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA06210; Thu, 10 Jun 1999 10:33:56 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <375FF706.47333C40@mentor.com> Date: Thu, 10 Jun 1999 10:33:58 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Jessica Morrison CC: IBIS@eda.org Subject: Re: current version References: <9E4C2E2E4A6CD211978B00104B61BC136501FD@SDCOMM.acceltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jessica: The official ANSI/EIA-656 version is Version 2.1 The most current of IBIS is Version 3.2. This has been officially ratified by the EIA IBIS Open Forum. Portions of Version 3.2 are currently being supported by industry. Also Version 3.2 is currently undergoing letter ballot review for national standardization as EIA-656A and ANSI/EIA-656A. Best Regards, Bob Ross Mentor Graphics Jessica Morrison wrote: > > What is the currently released version of IBIS? > > I have seen version 3 files, but I don't know if version 3 is officially > released yet. > Jessica Morrison > ACCEL Technologies > 619-350-3000 ext. 120 From owner-ibis Thu Jun 10 11:13:15 1999 Received: from mailhub.analogy.com (mailhub.analogy.com [149.117.1.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA06816 for ; Thu, 10 Jun 1999 11:13:12 -0700 (PDT) Received: from outlook.analogy.com (outlook.analogy.com [149.117.80.101]) by mailhub.analogy.com (8.9.1/8.9.1) with ESMTP id LAA09337 for ; Thu, 10 Jun 1999 11:06:44 -0700 (PDT) Received: by outlook.analogy.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Jun 1999 11:06:43 -0700 Message-ID: <76A4AFCC3CFDD21184C600105A5FD6AA32C8@uknt1.analogy.com> From: "Wilson, Peter" To: ibis@eda.org Subject: RE: 100-points limit discussion Date: Thu, 10 Jun 1999 11:07:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi, Is there a specification of the methodology (over and above the basic specification for IBIS) to adhere to when creating IBIS models from simulation results and in the opposite flow for the creation of simulation models from an IBIS specification ? This should ensure that regardless of which language/simulator was being used, there would be confidence that the simulations would be able to be validated AND verified. (Particularly relevant now with the emergence of mixed signal/analog HDLs such as IEEE 1076.1 and Verilog-AMS) This would also assist both the vendors/universities creating tools and also designers who have to work with ultimately the simulation models (either direct IBIS models or indirect models -such as spice derived from IBIS) Thanks, Peter Peter R. Wilson Technical Specialist - Analogy Europe and Asia Email : peterw@analogy.com Tel : +44 1793 432286 Fax : +44 1793 488098 WWW : http://www.analogy.com > -----Original Message----- > From: jonp@pacbell.net [SMTP:jonp@pacbell.net] > Sent: Thursday, June 10, 1999 4:15 PM > To: Fred Balistreri > Cc: Muranyi, Arpad; ibis@eda.org > Subject: Re: 100-points limit discussion > > Fred, > > We don't use S2IBIS here at Viewlogic. We use an internal tool (that I developed). > It is tied heavily to XTK as it uses it for auto QA and such. > > We are planning on making it available as a product but right now it isn't > supportable enough to sell (or give away) to the general public. Things like, it > only runs on certain Unix platforms. > > My group does use this program (called VML for Virtual Modeling Lab) to write and > QA the IBIS models that we generate for IC companies. > > regards, > jon > > > Fred Balistreri wrote: > > > A few points need to be clarified in Arpad's statements. The 100 point > > limit did not > > come from the SPICE world. It came from a restriction in the particuliar > > brand of > > SPICE being used by ????? at the time. As an example my company is a > > SPICE vendor with > > no restriction on PWL number of points. Our derivitive is Berkeley SPICE > > 3C1 circa > > 1980's something. Basing a standard on third party EDA vendor > > restrictions is @#*%#$#@! > > in my opinion. My point here is don't blame this on SPICE. There is > > enough blame going > > around the SPICE world. This is an IBIS problem. B source may be new in > > some SPICE > > programs but its been around at least since Berkeley 3C1 SPICE. > > > > Secondly as a model builder my two cents are that 100 points were fine > > in the original > > IBIS when there was no v/t information. If done correctly 100 points > > for I/V > > information is more than enough. The addition of v/t information may > > have changed all > > that. > > > > Thirdly, s2ibis is a public program written by students at UNC, and at > > that its > > origin is now maybe 3 or 4 years ago. Why is the whole IBIS world > > relying on this > > tool? There are a few multi hundreds of million of dollar in sales EDA > > companies and > > at least one over 1 billion in sales EDA company that claim support for > > IBIS. Yet all > > of these companies I am led to believe rely on an old public domain > > software program. > > Oddly enough there is enough complaints and questions brought up by > > s2ibis that an > > innocent bystander would have plenty of doubts about this program! My > > point here is that IBIS is the standard NOT s2ibis....and there are > > alternatives to > > s2ibis albiet not free. > > > > In my opinion the 100 point limit can be lifted as it seems that its a > > problem > > already. > > > > Muranyi, Arpad wrote: > > > > > > All, > > > > > > I agree with all of you, and at the same time a also disagree with some of > > > the points raised (no pun intended). > > > > > > 1) I believe that we are mixing at least two issues here. One is on the > > > subject of the number of points limit in the IBIS specification, the other > > > is regarding how s2ibis generates points. The third one relates to the > > > intelligence and experience of the model maker. (There is no need to run > > > a waveform simulation for 20 ns at 1 ps step time generating 20k points > > > when the edge reaches steady state in 2-3 ns and 3k points would be > > > sufficient, > > > as someone already mentioned it). > > > > > > IBIS does not need uniformly spaced data, in fact, in Section 3 the spec > > > says > > > the following: > > > > > > | 9) The V/I data tables should use enough data points around sharply > > > curved > > > | areas of the V/I curves to describe the curvature accurately. In > > > linear > > > | regions there is no need to define unnecessary data points. > > > > > > It is not stated, but this also applies to V-t curves. The problem is that > > > s2ibis doesn't know how to pick the best 100 points, so it generates > > > uniformly > > > spaced data with a bunch of redundant, unnecessary points in the linear > > > regions. > > > This uses up the 100 points quickly without much benefit, just because the > > > software doesn't have a best 100 point picker routine. We should not blame > > > the IBIS spec for this deficiency. > > > > > > 2) On the other hand, YES, I do agree that we need to raise the points > > > limit > > > in IBIS because the way things are now DOES limit much needed accuracy in > > > some > > > cases. I demonstrated this in a test case when I overlaid the waveforms of > > > a > > > SPICE and its equivalent IBIS model. The question is what should be the new > > > magic number. > > > > > > 3) History / current situation: The real reason for the 100 points came > > > from > > > the 100 point limits of the PWL sources in the SPICE world. We didn't want > > > to > > > exclude SPICE vendors and users from behavioral simulations. To make that > > > possible without having to ask each SPICE vendor to rewrite all of their PWL > > > sources, we had to introduce the 100 point limit. There were no technical, > > > engineering reasons behind this rule. > > > > > > We found the first problem when I was writing my "Best 100-points" algorithm > > > (for my IBIS Center program that we use internally to make IBIS models). I > > > realized in this process, that there is a difference in the outcome when we > > > count the X-axis points, or the Y-axis points because the typ., min., and > > > max. > > > tables use a common X-axis. When the three sets of Y-axis data are curved > > > in > > > different areas of the X-axis, in the theoretical extreme we could end up > > > with > > > 300 X-axis points while each of the Y-axis has only 100 points. The IBIS > > > 1.1 > > > specification did not say anything about how the 100 points were supposed to > > > be > > > counted. We did discuss this in the Open Forum Teleconference, but choose > > > not > > > to do anything about it in terms of changing or clarifying the IBIS spec. > > > It > > > was verbally said, however, that we should count X-axis points to be safe. > > > > > > I don't remember whether I found this before IBIS 2.1 was ratified or later, > > > but > > > somehow the most important IBIS 2.1 addition, the V-t curves ([... Waveform] > > > tables) inherited the same problem. > > > > > > IBIS 3.x has a few I-V curve related additions. It seems that in effort to > > > make > > > the spec clearer we not only defined it better for the new keywords, but for > > > the > > > sake of consistency we also changed the wording in the usage rules section > > > of the > > > old keywords, such as the [Pulldown], [Pullup], [GND Clamp] and [POWER > > > Clamp]. > > > > > > | ...first and last voltage points on any V/I table. Each V/I > > > | table must have at least 2, but not more than 100, voltage > > > | points. > > > > > > where "voltage points" defines that the counter should count 100 X-axis > > > points. > > > It is interesting to note that the [... Waveform] keywords were still left > > > vague > > > in the IBIS 3.x spec: > > > > > > | ...parses down the table. The waveform table can contain a > > > | maximum of 100 data points. A maximum of 100 waveform > > > tables > > > | are allowed per model. Note that for backward > > > compatibility, > > > > > > 4) Now, why did I write this all down? Well, to give some sense for the > > > proposal > > > that I am about to make here. It can be seen from the above history that, > > > for one, > > > the spec is still inconsistent regarding how to count the points in the > > > waveforms > > > and I-V curves, but more importantly, there is no technical reason for the > > > X-axis > > > counted 100 points in the I-V curves. > > > > > > There is another piece of information that is necessary before I make my > > > proposal. > > > I have not seen any generic PWL source in any SPICE flavor which can handle > > > one > > > X-axis column with multiple Y-axis columns. So if someone uses generic > > > controlled > > > sources in SPICE for building behavioral models which use IBIS data, they > > > will have to > > > separate the typ., min., and max. columns of the IBIS model into three > > > separate PWL > > > sources. Therefore, if we still want to support any SPICE tool by observing > > > their 100 > > > point limits in the PWL sources, it is sufficient to count the points in the > > > Y-axis. > > > > > > On the other hand, if there are newer implementations in SPICE that support > > > IBIS data > > > directly, such as the new B-element in HSPICE, chances are that being new, > > > they can > > > easily implement any (new) IBIS rule. > > > > > > 5) So, based on all this, I propose that we should allow for counting 100 > > > points > > > in the Y-axis. This will still work with any old SPICE PWL source, yet > > > would > > > significantly raise the accuracy of the curves. By doing this, we are > > > really > > > not changing the original intent of the spec. > > > > > > One problem that Bob raised in a private conversation to me is that this > > > will force > > > NA-s into the Y-columns, which is not desirable, even though it is perfectly > > > legal. > > > For this reason he suggested that we should just allow 300 points as counted > > > in the > > > X-axis, which essentially yields the same level of accuracy. The problem I > > > see with > > > this method is that this way the Y-axis can also end up with 300 points, > > > which may > > > prevent the data be used in old SPICE PWL sources. > > > > > > 6) On the other hand, if we do not care about SPICE PWL sources, we can > > > raise the > > > limit to practically any number. The things we need to consider then are > > > what some > > > already brought up in this discussion, file size, distribution, but I would > > > add > > > speed of simulation also. My understanding is that the larger the tables > > > get, the > > > more if-then-else evaluations will need to be done which can slow down the > > > simulator. > > > > > > 7) I tend to agree that unlimited points may not be a good idea, because > > > (forgive me) > > > there is no cure for laziness and stupidity. We may end up with a lot of > > > large files > > > with no reason, or added accuracy. > > > > > > Please comment. > > > > > > Arpad Muranyi > > > Intel Corporation > > > ============================================================================ > > > ======= > > > > -- > > Fred Balistreri > > fred@apsimtech.com > > > > http://www.apsimtech.com > > From owner-ibis Thu Jun 10 16:10:45 1999 Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA08022 for ; Thu, 10 Jun 1999 16:10:44 -0700 (PDT) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id QAA26526 for ; Thu, 10 Jun 1999 16:03:53 -0700 (PDT) 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.vlsi.com via smap (V2.0) id xma026518; Thu, 10 Jun 99 16:03:45 -0700 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 MFF92NB8; Thu, 10 Jun 1999 16:03:44 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <37604450.7AE4026D@vlsi.com> Date: Thu, 10 Jun 1999 16:03:44 -0700 From: "D. C. Sessions" Reply-To: ibis@eda.org Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Re: 100-points limit discussion References: <4575832C8E71D111AC4100A0C96B512703BB0C6A@fmsmsx36.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Muranyi, Arpad" wrote: > 6) On the other hand, if we do not care about SPICE PWL sources, we can > raise the > limit to practically any number. The things we need to consider then are > what some > already brought up in this discussion, file size, distribution, but I would > add > speed of simulation also. My understanding is that the larger the tables > get, the > more if-then-else evaluations will need to be done which can slow down the > simulator. > > 7) I tend to agree that unlimited points may not be a good idea, because > (forgive me) > there is no cure for laziness and stupidity. We may end up with a lot of > large files > with no reason, or added accuracy. I would *hope* that nobody is using raw PWL for modeling. Not only is it slow and bulky, but worst of all it's unnecessarily inaccurate. Cubic spline algorithms are fast and only need to be run once (when the model is read in) and can even be used with simple scripts supporting SPICE simulators. After that you use a piecewise-cubic model with a minimum of inflection points and NO first- or second-order discontinuities. The large number of source points is needed mainly to make sure that there is plenty of coverage in 'interesting' regions, and secondarily as a mechanism for judging when to remove inflection points. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Thu Jun 10 16:38:47 1999 Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA08118 for ; Thu, 10 Jun 1999 16:38:47 -0700 (PDT) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id QAA27730 for ; Thu, 10 Jun 1999 16:32:20 -0700 (PDT) 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.vlsi.com via smap (V2.0) id xma027717; Thu, 10 Jun 99 16:31:56 -0700 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 MFF92ND7; Thu, 10 Jun 1999 16:31:54 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <37604AEB.E767229F@vlsi.com> Date: Thu, 10 Jun 1999 16:31:55 -0700 From: "D. C. Sessions" Reply-To: ibis@eda.org Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Re: IBIS Subcommittee Formed to Review Spice to IBIS References: <427351B4DEABD111A99400805F19E9BB02D62B22@exchou-prod0901.eng.hou.compaq.com> <375D442C.7AD1F960@postoffice.pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Aside: maybe we should take the [SI-LIST] out of the Subject? jonp@pacbell.net wrote: > > I agree with Weston. > > Either that or remove the quite artificial limit of number of points in an IBIS > file. > I have actually been faced with the problem that even with software to remove > extra points I cannot > create IBIS models to the accuracy that I desire with the 100 point limitation. I'm having a problem with this, Jon. With inflection points chosen using the usual spline algorithms, 100 points should be enough for almost ANY monotonic transition. Oddly enough, I don't disagree with increasing the point count, but "you can't model it accurately otherwise" just isn't obvious to me. Could you give us an example? > Beal, Weston wrote: > > > Kellee, > > > > You're disagreeing a mute point. Your point was the same point I was trying > > to state by saying, "the IBIS creator tool should have an algorithm to > > remove points in linear regions." We should delete all these extra data > > points. The problem that s2ibis has now is that all points are equal > > difference. They should be closer in knee points and very sparse is linear > > regions. The IBIS creator tool should have an algorithm to clean out extra > > data. > > > > So, I agree with you and now you can agree with me. > > > > Later, > > Weston Beal > > Signal Integrity Engineer > > Compaq Computer Corp. > > > > -----Original Message----- > > From: Kellee Crisafulli [mailto:kellee@hyperlynx.com] > > Sent: Monday, 07 June, 1999 2:19 PM > > To: Beal, Weston; ibis@eda.org > > Subject: RE: [SI-LIST] : IBIS Subcommittee Formed to > > Review Spice to IBIS > > > > Hi > > > > I have a comment on Weston's comment on the number of data > > points. > > I disagree on one point. Instead of increasing the number > > of points generated > > in the IBIS file the spice to IBIS tool should improve the > > quality of the > > points > > choosen. > > > > I can hand build files with 50 points that out perform files > > with 400 points. > > The big gain is that the FILE SIZE is reduced with higher > > accuracy. > > Large IBIS files will take up many megabytes on 1000's of > > hard drives. > > The V/I and V/T tables are the largest part of IBIS files. > > Increasing them 4 x will generally increase the file size 3 > > x or more. > > > > >The third thing that I changed was the number of points in > > the time > > >waveforms from 50 to 101. I have to remove one point to > > comply with the > > >golden parser, but I get better detail. On the issue of > > number of points in > > >a curve or waveform, I think the user should be able to > > define any degree of > > >granularity and the IBIS creator tool should have an > > algorithm to remove > > >points in linear regions. If the resulting curve still has > > too many points, > > >then increase the linearity tolerance and try it again. > > > > Best wishes... > > Kellee -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Thu Jun 10 16:55:48 1999 Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA08175 for ; Thu, 10 Jun 1999 16:55:48 -0700 (PDT) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id QAA28279 for ; Thu, 10 Jun 1999 16:49:21 -0700 (PDT) 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.vlsi.com via smap (V2.0) id xma028268; Thu, 10 Jun 99 16:49:18 -0700 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 MFF92N16; Thu, 10 Jun 1999 16:49:17 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <37604EFD.E33E579A@vlsi.com> Date: Thu, 10 Jun 1999 16:49:17 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org CC: ibis@eda.org Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice to IBIS References: <1180113EC576D011AADE0060975B88B369CB32@neonet_server1.nexabit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Marc Humphreys wrote: > > Al, > > I think you took Jon's comment out of context and went off on a tanget, > missing his point completely. I think Jon's point was simply that when > creating an XTK model from the same initial VI curve data (measured > even), > via two different methods ( For arguments sake one via the GOLDEN > process > - probably by hand, and the other via IBIS) that the filtering effect > of the > 100 point limitation hinders the ability to create two identically > behaving models strictly attributable to the (currently)limited > VI data in the 'IBIS'ed version' of that same data - No matter how > carefully those 100 point where chosen! For some reason, computer people presented with mathematical tasks always like bigger hammers. An amazing number of programs still do numerical integration by rectangular summation instead of Simpson's Rule -- and then use ten or more times as much granularity in an attempt to make up the difference. OF COURSE if you're relying on a piecewise-linear approximation you're going to need a gazillion points. The solution isn't to use more points, it's to get smarter and use a better interpolation. The graphics gang figured this out a while ago, and THEY do it in hardware at video data rates. > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > ------------- > Marc Humphreys > Nexabit Networks, Inc. > 508-460-3355 x236 > e-mail: mhumphreys@nexabit.com > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > ------------- > > > -----Original Message----- > > From: Al Davis [SMTP:aldavis@ieee.org] > > Sent: Wednesday, June 09, 1999 3:10 AM > > To: ibis@eda.org > > Subject: Re: [SI-LIST] : IBIS Subcommittee Formed to Review Spice > > to IBIS > > > > jonp@pacbell.net wrote: > > > I have actually been faced with the problem that even with software > > to remove > > > extra points I cannot > > > create IBIS models to the accuracy that I desire with the 100 point > > limitation. > > > > I don't believe even 10000 points would provide the accuracy you > > desire, > > because the limits to accuracy are usually elsewhere. > > > > For example .... > > 100 points chosen to be uniformly spaced in voltage, modeling a 5 volt > > rising waveform, provides a data point every .2 volts. Assuming that > > the interpolation is completely bogus, this leads to a worst case > > error > > of .1 volts. In reality, interpolation is much better than that, and > > even this choice of data points is far from optimal, so the accuracy > > is > > much better than this. Remember, this isn't DC, but the dynamically > > changing voltage during a high speed transition. > > > > Some questions .... > > > > Is your Spice model that accurate? (I don't think so.) > > > > If you measure one real unit with perfect accuracy, and compare to the > > next one, are they this close to each other. (I don't think so.) > > > > Are your instruments this accurate? (Don't forget that you change the > > reading when you attach the probe.) > > > > What if the real load is different from the test load? Since the > > driving impedance is nonlinear, and not specified anywhere, even with > > perfectly accurate and complete data for the nominal load, all bets > > are > > off for anything else. > > > > Sure, the voltage is right, into a resistor, but what about > > reflections > > and noise? > > > > How accurate is the rest of the simulation? > > > > > > There are other ways to improve the accuracy. One obvious one is to > > carefully select the data points (as Kellee said). Another is to add > > another VT table with a different load. (As Kellee also said) The > > third table does much more to improve accuracy than more points will > > do. Tying the load resistor to a middle voltage does a good job at > > modeling the overlap. > > > > > > I wouldn't object to removing the limit entirely, because whatever the > > limit is, most files will use it, without any valid reason. With no > > limit at all, it is up to the modeler to decide what trade-offs to > > use. > > Maybe with nothing in the spec saying how many points to use, we might > > actually get some good 20 point models, that are more accurate than > > the > > 256 (or whatever) point models that we will get if the limit is > > raised, > > and the capability is there for those rare cases when you really do > > need > > the extra points. So, maybe the answer is to remove the hard limit, > > but > > add a comment that tables with more than 50 points are rarely worth > > the > > extra space. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Thu Jun 10 18:08:28 1999 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 SAA08406 for ; Thu, 10 Jun 1999 18:08:27 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id SAA20516; Thu, 10 Jun 1999 18:02:01 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id SAA23114; Thu, 10 Jun 1999 18:01:59 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37606007.CA4FA5BF@mentor.com> Date: Thu, 10 Jun 1999 18:01:59 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "Wilson, Peter" CC: ibis@eda.org Subject: IBIS Specification Methodology References: <76A4AFCC3CFDD21184C600105A5FD6AA32C8@uknt1.analogy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter: It would be nice if there were a standardized method to process IBIS models. However, for historical reasons and EDA tool vendor algorithm evolution, the "best" methods to process the data is not known and could be debated. More comments are in your text. Best Regards, Bob Ross Mentor Graphics Wilson, Peter wrote: > > Hi, > > Is there a specification of the methodology (over and above the basic specification for IBIS) to adhere to when creating IBIS models from simulation results and in the opposite flow for the creation of simulation models from an IBIS specification ? No. There is no specified methodology. One method may be better than another for a specific application. Also one method may be better than another based on what criteria is used in determining what is the best simulation result. However, some common methods are emerging based on (some form of) deriving multiplying coefficients over time to transition the [Pulldown] tables and [Pullup] tables from on/off to off/on. So I believe some defendable processing algorithms can be encoded in an HDL. > > This should ensure that regardless of which language/simulator was being used, there would be confidence that the simulations would be able to be validated AND verified. (Particularly relevant now with the emergence of mixed signal/analog HDLs such as IEEE 1076.1 and Verilog-AMS) > > This would also assist both the vendors/universities creating tools and also designers who have to work with ultimately the simulation models (either direct IBIS models or indirect models -such as spice derived from IBIS) > > Thanks, > Peter > > Peter R. Wilson > Technical Specialist - Analogy Europe and Asia > Email : peterw@analogy.com > Tel : +44 1793 432286 > Fax : +44 1793 488098 > WWW : http://www.analogy.com > From owner-ibis Fri Jun 11 15:20:40 1999 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 PAA14432; Fri, 11 Jun 1999 15:20:40 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA24410; Fri, 11 Jun 1999 15:14:11 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id PAA04097; Fri, 11 Jun 1999 15:14:10 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37618A32.5A97A636@mentor.com> Date: Fri, 11 Jun 1999 15:14:10 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org, si-list@silab.eng.sun.com CC: cfleming@eia.org Subject: REMINDER TO VOTE ON IBIS SP-4557 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: REMINDER TO VOTE ON SP-4557. Download the ballot form from the EIA IBIS home page: http://www.eia.org/eig/ibis/ibis.htm Return by surface mail or FAX the completed, signed form. Vote is by COMPANY only. DEADLINE is June 23, 1999. Standards Proposal 4557 is a proposed revision to EIA-656 "I/O Buffer Information Specification (IBIS) to Version 3.2 to be pubished, if approved, as EIA-656-A and as an American National Standard. Thank you Bob Ross Chair, EIA IBIS Open Forum Mentor Graphics From owner-ibis Mon Jun 14 02:29:59 1999 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by server.eda.org (8.8.5/8.8.3) with ESMTP id CAA21320 for ; Mon, 14 Jun 1999 02:29:58 -0700 (PDT) X-Envelope-Sender-Is: sporrer@christl.hl.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id LAA12289 for ; Mon, 14 Jun 1999 11:23:59 +0200 (MET DST) Received: from mustang.mchm.siemens.de (mustang.mchm.siemens.de [190.1.24.98]) by mail1.siemens.de (8.9.3/8.9.3) with ESMTP id LAA04381 for ; Mon, 14 Jun 1999 11:23:58 +0200 (MET DST) Received: from christl.hl.siemens.de (root@christl.hl.siemens.de [172.29.16.38]) by mustang.mchm.siemens.de (8.9.3/8.9.3) with ESMTP id LAA11495 for ; Mon, 14 Jun 1999 11:23:57 +0200 (MET DST) Received: from lampe.hl.siemens.de (sporrer@lampe [172.29.19.104]) by christl.hl.siemens.de (8.8.5/8.8.5) with ESMTP id LAA05528; Mon, 14 Jun 1999 11:23:53 +0200 (MET DST) From: Sporrer cad52 Received: (from sporrer@localhost) by lampe.hl.siemens.de (8.8.5/8.8.5) id LAA19421; Mon, 14 Jun 1999 11:23:52 +0200 (MET DST) Date: Mon, 14 Jun 1999 11:23:52 +0200 (MET DST) Message-Id: <199906140923.LAA19421@lampe.hl.siemens.de> Cc: sporrer@hl.siemens.de To: ibis@eda.org Subject: Question Vinh/l+, Vinh/l- Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Jsb6v8cMeBRVB6cRPXGuJg== Hi, I am from Infineon Technolgies AG, Munich (former Siemens Semiconductor) and responsible for the generation of IBIS models for our IO-cell libraries. For IBIS 3.x I have a problem with the meaning of Vinh+, Vinh-, Vinl+ and Vinl- subparameters inside the [Model Spec] Keyword. What is the difference between Vinh/l+ and Vinh/l- ? What is the meaning of Vt+/Vt- ? Process, temperature and voltage variation is considered in the typ, min and max columns. But what kind of variation must be done to get different Vin(h+-)/(l+-) values? I hope somebody can help me. Thanks Christian. Christian Sporrer Infineon Technologies Munich Email: Christian.Sporrer@infineon.com Tel: +49 89 234 24069 Fax: +49 89 234 28555 From owner-ibis Mon Jun 14 12:08:27 1999 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 MAA23420; Mon, 14 Jun 1999 12:08:27 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA15701; Mon, 14 Jun 1999 12:00:45 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id MAA13646; Mon, 14 Jun 1999 12:00:43 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3765515C.BE532580@mentor.com> Date: Mon, 14 Jun 1999 12:00:44 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org CC: will.hobbs@intel.com Subject: [Fwd: REMINDER TO VOTE ON IBIS SP-4557] Content-Type: multipart/mixed; boundary="------------284FD0A2ACD1280186A12E34" This is a multi-part message in MIME format. --------------284FD0A2ACD1280186A12E34 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Will: Just to clarify, only one vote per COMPANY is allowed. So if several votes are received from a company, and they disagree, we will need to resolve any disagreement by identifying the selecting the vote from the primary representative. However, we will officially review and respond to any comment received. Thanks, Bob Ross Mentor Graphics --------------284FD0A2ACD1280186A12E34 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline >Received: from relay1.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id QAA15125; Fri, 11 Jun 1999 16:32:49 -0700 (PDT) Received: from relay1.wv.mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id QAA15125; Fri, 11 Jun 1999 16:32:49 -0700 (PDT) Received: from thalia.fm.intel.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA29070; Fri, 11 Jun 1999 16:32:49 -0700 (PDT) Received: from fmsmsx28.FM.INTEL.COM (fmsmsx28.fm.intel.com [132.233.42.28]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id QAA03220 for ; Fri, 11 Jun 1999 16:32:48 -0700 (PDT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Jun 1999 16:32:48 -0700 Message-ID: From: "Hobbs, Will" To: "'Bob Ross'" Subject: RE: REMINDER TO VOTE ON IBIS SP-4557 Date: Fri, 11 Jun 1999 16:32:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Bob, You might want to mention EIA's policy concerning what votes actually count. Is it one vote per member company, and all comments will be reviewed and responded to, or do all votes count? Will -----Original Message----- From: Bob Ross [mailto:bob_ross@mentorg.com] Sent: Friday, June 11, 1999 3:14 PM To: ibis@eda.org; ibis-users@eda.org; si-list@silab.eng.sun.com Cc: cfleming@eia.org Subject: REMINDER TO VOTE ON IBIS SP-4557 To All: REMINDER TO VOTE ON SP-4557. Download the ballot form from the EIA IBIS home page: http://www.eia.org/eig/ibis/ibis.htm Return by surface mail or FAX the completed, signed form. Vote is by COMPANY only. DEADLINE is June 23, 1999. Standards Proposal 4557 is a proposed revision to EIA-656 "I/O Buffer Information Specification (IBIS) to Version 3.2 to be pubished, if approved, as EIA-656-A and as an American National Standard. Thank you Bob Ross Chair, EIA IBIS Open Forum Mentor Graphics --------------284FD0A2ACD1280186A12E34-- From owner-ibis Mon Jun 14 12:11:01 1999 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 MAA23442 for ; Mon, 14 Jun 1999 12:11:00 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA15965; Mon, 14 Jun 1999 12:04:34 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id MAA14337; Mon, 14 Jun 1999 12:04:32 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <37655241.2FE7E4F1@mentor.com> Date: Mon, 14 Jun 1999 12:04:33 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org Subject: AGENDA IBIS SUMMIT MEETING 6/21/99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A G E N D A D A C I B I S S U M M I T M E E T I N G Monday, June 21, 1999 Hilton Hotel, New Orleans Riverside Chequers Room New Orleans, Louisiana 8:30 AM REFRESHMENTS 9:00 AM INTRODUCTIONS 9:15 AM IBIS 1998 - 1999 & MEETING OVERVIEW - Bob Ross, Mentor Graphics 9:30 AM GENERAL BUSINESS - Announcements - Officer Elections for 1998-1999 - IBIS Version 3.2 Issues & Discussion - Opens & Other Business 10:00 AM ACCURACY SPECIFICATION UPDATE - Bob Haller, Compaq 10:30 AM BREAK 10:45 PM S2IBIS2/3 REPORT & DISCUSSSION - Michael Cohen, IBM & s2ibis2/3 Committee 11:15 AM BEHAVIORAL RECEIVERS - Stephen Peters, Intel 11:30 AM EQUATION BASED MODELING - Arpad Muranyi, Intel 12:00 PM LUNCH (PROVIDED) 1:00 PM UPDATE ON IMIC ACTIVITY - Hideki Fukuda, Hitachi 1:30 PM ECALS-2 AND THE EMI PROBLEM - Atsushi Ito, Matsushita 2:00 PM NEW IBIS VERSION 4.X FEATURES DISCUSSION 2:30 PM ANY OTHER ISSUES - Next Meeting 3:00 PM BREAK & END OF MEETING _____________________________________________________________________________ DAC: DAC is scheduled Monday - Friday, June 21 -25, 1999. The exhibitor portion is open from 10 AM to 6 PM on Monday - Wednesday. So there should be time after the IBIS Summit meeting to visit the show. For more information on DAC99 activities, housing, etc. visit the DAC99 URL. DAC URL: http://www.dac.com/ CALL FOR PRESENTATIONS: Ad Hoc Presentations are still welcome. All presentors plan to bring slides for use with an overhead projector. We would like you to provide handouts for the meeting (about 25) and also an electronic copy for archiving. CALL FOR ATTENDEES: Please let Matthew Flora know if you are planning to attend so we have an estimate on food requirements. CONTACT: Matthew Flora mbflora@hyperlynx.com (425) 869-2320 From owner-ibis Tue Jun 15 06:18:06 1999 Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA27950 for ; Tue, 15 Jun 1999 06:18:04 -0700 (PDT) Received: from mailgw.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8/3.7W-florida) with ESMTP id WAA25625; Tue, 15 Jun 1999 22:13:13 +0900 (JST) Received: by mailgw.melco.co.jp (3.7W-mailgw) id WAA15663; Tue, 15 Jun 1999 22:15:31 +0900 (JST) Received: from elgw.isl.melco.co.jp (isvax [133.141.13.130]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) with ESMTP id WAA04294; Tue, 15 Jun 1999 22:11:57 +0900 (JST) Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id WAA03782; Tue, 15 Jun 1999 22:14:26 +0900 (JST) Received: from zilch by islgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id WAA23127; Tue, 15 Jun 1999 22:13:24 +0900 (JST) Message-Id: <199906151313.WAA23127@islgw.isl.melco.co.jp> X-My-Real-Login-Name: yamagi; islgw MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Denshin 8 Go V321.1b7 Date: Tue, 15 Jun 1999 22:08:51 +0900 In-Reply-To: Your message of "Mon, 14 Jun 1999 11:23:52 +0200 (MET DST)" <199906140923.LAA19421@lampe.hl.siemens.de> References: <199906140923.LAA19421@lampe.hl.siemens.de> From: Keitarou Yamagishi To: ibis@eda.org, bob_ross@mentorg.com Cc: yamagi@isl.melco.co.jp Subject: IBISCHK3 X-MailEditor: Den8 MailEditor V1.2 Hi, Now I study the ibischk3 programs. I have two questions. 1. This program is platform-oriented. In "http://www.eda.org/pub/ibis/ibischk3/" of IBIS Open Forum "FREE Tools", there are seven ibischk3 programs for dec_4, dos32, hp_10, ibm_4, linux, sun_4 and sun_5. And these programs is developed by different developer. So I guess there are some original document or specification common for these 7 programs. Anybody knows where there are? 2. One of above 7 programs is for dos32. Perhaps this is Windows version. Is this program Y2K compariant? Thank you. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Keitarou Yamagishi _/ _/ $B!!(JMITSUBISHI ELECTRIC CORPORATION _/ _/ $B!!(JINFORMATION TECHNOLOGY R&D CENTER _/ _/ $B!!(JE-mail$B!'(Jyamagi@isl.melco.co.jp _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-ibis Tue Jun 15 17:16:36 1999 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 RAA00669 for ; Tue, 15 Jun 1999 17:16:35 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA05104; Tue, 15 Jun 1999 17:10:07 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA28402; Tue, 15 Jun 1999 17:10:05 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3766EB5D.82510B6C@mentor.com> Date: Tue, 15 Jun 1999 17:10:05 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Keitarou Yamagishi , ibis@eda.org Subject: Re: IBISCHK3 References: <199906140923.LAA19421@lampe.hl.siemens.de> <199906151313.WAA23127@islgw.isl.melco.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yamagishi-san My responses are in your text. Best Regards, Bob Ross Mentor Graphics Keitarou Yamagishi wrote: > > Hi, > > Now I study the ibischk3 programs. I have two questions. > > 1. This program is platform-oriented. In "http://www.eda.org/pub/ibis/ibischk3/" > of IBIS Open Forum "FREE Tools", there are seven ibischk3 programs for dec_4, > dos32, hp_10, ibm_4, linux, sun_4 and sun_5. And these programs is developed by > different developer. So I guess there are some original document or specification > common for these 7 programs. Anybody knows where there are? These executable are all derived from the same source code. Only one developer is involved. Only the companies that funded the development project have access to the source code and the embedded documentation. The source specification is IBIS Version 3.2. > > 2. One of above 7 programs is for dos32. Perhaps this is Windows version. > Is this program Y2K compariant? > It has not gone through formal Y2K compliance testing. However, I believe it is Y2K since the [Date] field is just a text string and is not used for any ibischk3 processing. > Thank you > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > _/ Keitarou Yamagishi _/ > _/ $B!!(JMITSUBISHI ELECTRIC CORPORATION _/ > _/ $B!!(JINFORMATION TECHNOLOGY R&D CENTER _/ > _/ $B!!(JE-mail$B!'(Jyamagi@isl.melco.co.jp _/ > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-ibis Tue Jun 15 17:58:59 1999 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 RAA00797 for ; Tue, 15 Jun 1999 17:58:59 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA07169; Tue, 15 Jun 1999 17:52:30 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA03667; Tue, 15 Jun 1999 17:52:28 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3766F54C.D4D72201@mentor.com> Date: Tue, 15 Jun 1999 17:52:28 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Sporrer cad52 CC: ibis@eda.org Subject: Re: Question Vinh/l+, Vinh/l- References: <199906140923.LAA19421@lampe.hl.siemens.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Christian: Some specifications for Schmitt trigger (or hysteresis) inputs give values in terms of Vt+ for the high threshold value and Vt- for a low threshold value. One old example is the 74XXX132 series of devices. The Texas Instruments TTL Logic data book gives min, typ and max Vt+ and min, typ, and max Vt- values and defines them as Positive-Going Threshold Voltage Vt+ and Negative-Going Threshold Voltage Vt- From BIRD39 the following diagram illustrates how the hysteresis subparameters are defined: ^ O | +-------+----<----+--------+------------ U | ! ! ! ! T | ! ! ! ! P | ! ! ! ! U | ! ! ! ! T | ! ! ! ! | v v ^ ^ V | ! ! ! ! O | ! ! ! ! L | ! ! ! ! T | ! ! ! ! T | ! ! ! ! A | ! ! ! ! G | ! ! ! ! E | -----------+-------+---->----+--------+ |_____________________________________________________________> Vinl- Vinl+ Vinh- Vinh+ INPUT VOLTAGE IBIS Version 3.2 relates the Vt+ and Vt- min and max values that may appear in data books as follows: | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- Whether or not the data book uses the Vt+ and Vt- terminology, the hysteresis or Schmitt trigger inputs should be entered consistent with the figure above. Best Regards, Bob Ross Mentor Graphics Sporrer cad52 wrote: > > Hi, > > I am from Infineon Technolgies AG, Munich (former Siemens > Semiconductor) and responsible for the generation of IBIS > models for our IO-cell libraries. > > For IBIS 3.x I have a problem with the meaning of Vinh+, > Vinh-, Vinl+ and Vinl- subparameters inside the > [Model Spec] Keyword. > What is the difference between Vinh/l+ and Vinh/l- ? > What is the meaning of Vt+/Vt- ? > > Process, temperature and voltage variation is considered > in the typ, min and max columns. But what kind of > variation must be done to get different Vin(h+-)/(l+-) > values? > > I hope somebody can help me. > > Thanks Christian. > > Christian Sporrer > Infineon Technologies Munich > Email: Christian.Sporrer@infineon.com > Tel: +49 89 234 24069 > Fax: +49 89 234 28555 From owner-ibis Wed Jun 16 01:09:34 1999 Received: from ramses.erlm.siemens.de (ramses.erlm.siemens.de [195.63.95.194]) by server.eda.org (8.8.5/8.8.3) with ESMTP id BAA02389 for ; Wed, 16 Jun 1999 01:09:33 -0700 (PDT) Received: from tcenter.erlm.siemens.de (tcenter.erlm.siemens.de [193.25.63.21]) by ramses.erlm.siemens.de (8.8.8/8.8.8) with ESMTP id KAA02490; Wed, 16 Jun 1999 10:03:04 +0200 (MET DST) Received: from mchr900a.139.25.176.83 (mail.mchr2.siemens.de [195.210.172.6]) by tcenter.erlm.siemens.de (8.9.0/8.9.0) with ESMTP id JAA06634; Wed, 16 Jun 1999 09:50:30 +0200 (MET DST) Received: by FFSERVER with Internet Mail Service (5.0.1460.8) id <20W8XG6Z>; Wed, 16 Jun 1999 09:59:53 +0200 Message-ID: From: Unger Bernhard To: Sporrer cad52 , Bob Ross Cc: ibis@eda.org Subject: AW: Question Vinh/l+, Vinh/l- Date: Wed, 16 Jun 1999 09:59:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Hello Bob: The Vinh+, Vinh-, Vinl+ and Vinh- definition is a litle bit confusing for me. We take the Vinh+ and the Vinl+ values, which have been evaluated under max conditions and the Vinh- and Vinl- values, which have been evaluated under min conditions and put these data in the typ colum of the IBIS file. Why we don't put these data in the max and min colums? Yes I know there must be data in the typ colum but nevertheless it stays confusing for me. Best regards Bernhard > ---------- > Von: Bob Ross[SMTP:bob_ross@mentorg.com] > Gesendet: Mittwoch, 16. Juni 1999 02:52 > An: Sporrer cad52 > Cc: ibis@eda.org > Betreff: Re: Question Vinh/l+, Vinh/l- > > Hello Christian: > > Some specifications for Schmitt trigger (or hysteresis) inputs > give values in terms of Vt+ for the high threshold value and > Vt- for a low threshold value. > > One old example is the 74XXX132 series of devices. > > The Texas Instruments TTL Logic data book gives min, typ and > max Vt+ and min, typ, and max Vt- values and defines them as > Positive-Going Threshold Voltage Vt+ and Negative-Going Threshold > Voltage Vt- > > From BIRD39 the following diagram illustrates how the hysteresis > subparameters are defined: > > ^ > O | +-------+----<----+--------+------------ > U | ! ! ! ! > T | ! ! ! ! > P | ! ! ! ! > U | ! ! ! ! > T | ! ! ! ! > | v v ^ ^ > V | ! ! ! ! > O | ! ! ! ! > L | ! ! ! ! > T | ! ! ! ! > T | ! ! ! ! > A | ! ! ! ! > G | ! ! ! ! > E | -----------+-------+---->----+--------+ > |_____________________________________________________________> > Vinl- Vinl+ Vinh- Vinh+ > INPUT VOLTAGE > > > IBIS Version 3.2 relates the Vt+ and Vt- min and max values that may > appear in data books as follows: > > | Vinh+ Hysteresis threshold high max Vt+ > | Vinh- Hysteresis threshold high min Vt+ > | Vinl+ Hysteresis threshold low max Vt- > | Vinl- Hysteresis threshold low min Vt- > > > Whether or not the data book uses the Vt+ and Vt- terminology, the > hysteresis or Schmitt trigger inputs should be entered consistent > with the figure above. > > Best Regards, > Bob Ross > Mentor Graphics > > > Sporrer cad52 wrote: > > > > Hi, > > > > I am from Infineon Technolgies AG, Munich (former Siemens > > Semiconductor) and responsible for the generation of IBIS > > models for our IO-cell libraries. > > > > For IBIS 3.x I have a problem with the meaning of Vinh+, > > Vinh-, Vinl+ and Vinl- subparameters inside the > > [Model Spec] Keyword. > > What is the difference between Vinh/l+ and Vinh/l- ? > > What is the meaning of Vt+/Vt- ? > > > > Process, temperature and voltage variation is considered > > in the typ, min and max columns. But what kind of > > variation must be done to get different Vin(h+-)/(l+-) > > values? > > > > I hope somebody can help me. > > > > Thanks Christian. > > > > Christian Sporrer > > Infineon Technologies Munich > > Email: Christian.Sporrer@infineon.com > > Tel: +49 89 234 24069 > > Fax: +49 89 234 28555 > From owner-ibis Wed Jun 16 12:05:46 1999 Received: from ns1.mentorg.com (ns1.mentorg.com [192.94.38.65]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA05729 for ; Wed, 16 Jun 1999 12:05:45 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by ns1.mentorg.com (8.8.8/CF5.40F) id LAA19237; Wed, 16 Jun 1999 11:59:08 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA21821; Wed, 16 Jun 1999 11:59:05 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3767F3FA.6A1138D@mentor.com> Date: Wed, 16 Jun 1999 11:59:06 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Unger Bernhard CC: Sporrer cad52 , Bob Ross , ibis@eda.org Subject: Re: AW: Question Vinh/l+, Vinh/l- References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernhard: The most conservative approach is to enter all subparameters as typical column entries. However, I agree with your observation that Vinh+ and Vinl+ could be the max column entries and Vinh- and Vinl- could be min colunn entries. Other data may exist in the datasheet (such as graphs showing the relationship of Vt+ and Vt- with respect to Vcc) to allow defendable estimates for Vinh+, Vinh-, Vinl+, and Vinl- for each of the three colunms. This would produce a more realistic model with tighter threshold bands typ, min, and max conditions. However, this would require entering data that is derived from, but may not be directly available from the datasheet. Best Regards, Bob Ross Mentor Graphics Unger Bernhard wrote: > > Hello Bob: > > The Vinh+, Vinh-, Vinl+ and Vinh- definition is a litle bit confusing for > me. We take the Vinh+ and the Vinl+ values, which have been evaluated under > max conditions and the Vinh- and Vinl- values, which have been evaluated > under min conditions and put these data in the typ colum of the IBIS file. > Why we don't put these data in the max and min colums? > Yes I know there must be data in the typ colum but nevertheless it stays > confusing for me. > > Best regards > > Bernhard > > > ---------- > > Von: Bob Ross[SMTP:bob_ross@mentorg.com] > > Gesendet: Mittwoch, 16. Juni 1999 02:52 > > An: Sporrer cad52 > > Cc: ibis@eda.org > > Betreff: Re: Question Vinh/l+, Vinh/l- > > > > Hello Christian: > > > > Some specifications for Schmitt trigger (or hysteresis) inputs > > give values in terms of Vt+ for the high threshold value and > > Vt- for a low threshold value. > > > > One old example is the 74XXX132 series of devices. > > > > The Texas Instruments TTL Logic data book gives min, typ and > > max Vt+ and min, typ, and max Vt- values and defines them as > > Positive-Going Threshold Voltage Vt+ and Negative-Going Threshold > > Voltage Vt- > > > > From BIRD39 the following diagram illustrates how the hysteresis > > subparameters are defined: > > > > ^ > > O | +-------+----<----+--------+------------ > > U | ! ! ! ! > > T | ! ! ! ! > > P | ! ! ! ! > > U | ! ! ! ! > > T | ! ! ! ! > > | v v ^ ^ > > V | ! ! ! ! > > O | ! ! ! ! > > L | ! ! ! ! > > T | ! ! ! ! > > T | ! ! ! ! > > A | ! ! ! ! > > G | ! ! ! ! > > E | -----------+-------+---->----+--------+ > > |_____________________________________________________________> > > Vinl- Vinl+ Vinh- Vinh+ > > INPUT VOLTAGE > > > > > > IBIS Version 3.2 relates the Vt+ and Vt- min and max values that may > > appear in data books as follows: > > > > | Vinh+ Hysteresis threshold high max Vt+ > > | Vinh- Hysteresis threshold high min Vt+ > > | Vinl+ Hysteresis threshold low max Vt- > > | Vinl- Hysteresis threshold low min Vt- > > > > > > Whether or not the data book uses the Vt+ and Vt- terminology, the > > hysteresis or Schmitt trigger inputs should be entered consistent > > with the figure above. > > > > Best Regards, > > Bob Ross > > Mentor Graphics > > > > > > Sporrer cad52 wrote: > > > > > > Hi, > > > > > > I am from Infineon Technolgies AG, Munich (former Siemens > > > Semiconductor) and responsible for the generation of IBIS > > > models for our IO-cell libraries. > > > > > > For IBIS 3.x I have a problem with the meaning of Vinh+, > > > Vinh-, Vinl+ and Vinl- subparameters inside the > > > [Model Spec] Keyword. > > > What is the difference between Vinh/l+ and Vinh/l- ? > > > What is the meaning of Vt+/Vt- ? > > > > > > Process, temperature and voltage variation is considered > > > in the typ, min and max columns. But what kind of > > > variation must be done to get different Vin(h+-)/(l+-) > > > values? > > > > > > I hope somebody can help me. > > > > > > Thanks Christian. > > > > > > Christian Sporrer > > > Infineon Technologies Munich > > > Email: Christian.Sporrer@infineon.com > > > Tel: +49 89 234 24069 > > > Fax: +49 89 234 28555 > > From owner-ibis Wed Jun 16 12:16:01 1999 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA05766 for ; Wed, 16 Jun 1999 12:16:00 -0700 (PDT) From: micohen@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA150922; Wed, 16 Jun 1999 15:09:51 -0400 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.02) with SMTP id PAA52870; Wed, 16 Jun 1999 15:09:56 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256792.0069442E ; Wed, 16 Jun 1999 15:09:47 -0400 X-Lotus-FromDomain: IBMUS To: ibis@eda.org, si-list@silab.eng.sun.com Message-ID: <85256792.006941FB.00@d54mta04.raleigh.ibm.com> Date: Wed, 16 Jun 1999 15:08:43 -0400 Subject: IBIS Subcommittee Formed to Review Spice to IBIS (Reminder) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello everyone. This is a reminder to all persons who have not yet sent in their responses to my note dated June 4, 1999: >Hello everyone. > >On May 28, 199, the IBIS Committee, via the IBIS Open Forum Teleconference, >formed a subcommittee to determine the viability of taking ownership of the >Spice to IBIS (s2ibis2) tool, originally written at North Carolina State >University. This subcommittee will eventually report back to the IBIS >Committee the following: > 1. Any known bugs with the current tool. > 2. Any future enhancements for the next generation tool (s2ibis3). > >From these lists, the IBIS Committee and this subcommittee will draft a >"requirements" list, and pending funding, request bids from various >sources to update/rewrite the tool. Like the IBIS Parser, we want to keep >the Spice to IBIS tool in the public domain (open source). > >As chairperson of this subcommittee, I am asking for your help. If you are a >user, or one of the many programmers, of the current Spice to IBIS tool, I am >looking for your feedback to make the next tool better. If you know of any >bugs, or have any enhancement requests, please let us know by posting your >comments to either the IBIS or SI reflector. If you wish to keep your >comments psuedo-confidential, please feel free to send them directly to >myself at "micohen@us.ibm.com". Please be as specific as you can. In the >case of bug reports, we may need to contact you off-line to get more >information and/or testcases. > >Please send your responses no later than June 18, as we will be discussing >this topic at the IBIS Summit Meeting, which will be held Monday, June 21. > >Disclaimer: all participants on this subcommittee, as well as those on >the IBIS Committee, are volunteers, attempting to make this tool better. We >are not getting paid, nor receiving any benefits, from this work. So please, >be kind with your comments. > To date, we have received approximately 30 responses, some dealing with the 100 point IBIS limitation. If you have any other enhancement requests, or bug reports (not directly relating to the 100 point discussion), please send them to the reflector(s) or myself. Again, thank you to all those who have already responded. Regards, Michael Cohen IBM Personal Systems Group Design Tools Department D-26D/B-201/R-D104H 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919-543-4042 (T/L 441-4042) FAX: 919-543-8221 (T/L 441-8221) Internet Address: micohen@us.ibm.com IBM Internal Addresses: From Lotus Notes (#1): Michael Cohen/Raleigh/IBM From Lotus Notes (#2): micohen@ibmus From VM: micohen@ibmusm21 From owner-ibis Sun Jun 27 13:43:43 1999 Received: from unknown (ts004d06.atl-ga.concentric.net [206.173.82.162]) by server.eda.org (8.8.5/8.8.3) with SMTP id NAA23672; Sun, 27 Jun 1999 13:43:39 -0700 (PDT) From: cc123@boardermail.com Message-Id: <199906272043.NAA23672@server.eda.org> Subject: laser printer toner advertisement Date: Mon, 28 Jun 1999 00:59:03 BENCHMARK SUPPLY 7540 BRIDGEGATE COURT ATLANTA GA 30350 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $89 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS 10 WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 800-650-5062**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 (CALL 770-512-0511 BEFORE FAXING) BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. NOTE NUMBER (3): OWNERS OF ANY OF THE DOMAINS THAT APPEAR IN THE HEADER OF THIS MESSAGE,ARE IN NO WAY ASSOCIATED WITH, PROMOTING, DISTRIBUTING OR ENDORSING ANY OF THE PRODUCTS ADVERTISED HEREIN AND ARE NOT LIABLE TO ANY CLAIMS THAT MAY ARISE THEREOF. From owner-ibis Tue Jun 29 09:14:56 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA01454 for ; Tue, 29 Jun 1999 09:14:49 -0700 (PDT) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id IAA04670 for ; Tue, 29 Jun 1999 08:02:22 -0700 Message-Id: <3.0.5.32.19990629090846.00a9cb20@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 29 Jun 1999 09:08:46 +0000 To: ibis@eda.org From: Matthew Flora Subject: IBIS Summit Meeting Minutes 21 Jun 1999 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DATE: 6/29/99 SUBJECT: 6/21/99 EIA IBIS Summit Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Raj Raghuram, Norio Matsui*, Neven Orhanovic Avanti Nikolai Bannov Cadence Design Mike LaBonte* Cisco Systems Syed Huq* Compaq Bob Haller*, Steve Coe, Shafir Rahman, Maher Elasad Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella Fairchild Semiconductor [Peter LaFlamme], Craig Klem H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu High Design Technology Razvan Ene HyperLynx (& Pads Software) Matthew Flora, Kellee Crisafulli, Lynne Green* IBM Greg Edlund, Michael Cohen*, Praven Patel Incases Olaf Rethmeier, Werner Rissiek, David Eagles, Wilhelm Arnoldi, Ulrich Losch Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, Martin Chang, Dave Moxley, Kerry Nelson, Jeff Day, Richard Mellitz, Peter Liou, Will Hobbs*, Henri Maramis* LSI Logic (Symbios Logic) Scott King* Mentor Graphics Bob Ross*, Mohamed Mahmoud, Sherif Hammad, Jean Oudinot, Markku Kukkanen, Martin Groeber, Karine Loudet, Hisham Gamal*, Evgeny Wasserman* Mitsubishi (Tam Cao) Motorola (Ron Werner) National Semiconductor Milt Schwartz* North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda NEC (Hiroshi Matsumoto) Philips Semiconductor Todd Andersen, Peter Christiaans Quantic EMC (Mike Ventham) Siemens Bernhard Unger, Christian Mitschke, Manfred Maurer, Peter Kaiser, Wolfram Meyer, Gerald Bannert, Harmut Ibowski, Katja Zuleeg, Hans Pichlmaier, Eckhard Lenski, Kortheuer Udo, Christian Sporrer SiQual Scott McMorrow Texas Instruments Jean-Claude Perrin, Shankar Balasubramaniah, Ramzi Ammar, Thomas Fisher* Thomson-CSF (Jean Lebrun) Time Domain Analysis Systems Dima Smolyansky Viewlogic Systems Chris Rokusek*, Guy de Burgh*, Cary Mandel, (Jon Powell) VeriBest Ian Dodd* VLSI Technology D.C. Sessions* Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1999: 3Dfx Interactive Ken Wu Actel Corporation Silvia Montoya Alcatel Steven Criel Analytical Edge Robert Easson Applied Microelectronics Brian Sanderson BMW Friedrich Haslinger Bogatin Enterprise Eric Bogatin Bosch Telecom Detlef Wolf ECI Telecom Daniel Adar EIA [Patti Rusher], Cecilia Fleming*, Dan Heinemeier Electronique Catherine Gross EFM Consulting Ekkehard Miersch FCI John Ellis Hitachi ULSI Hideki Fukuda* Infineon Thomas Latzel* Intracon Design Mike Osmond Litton Systems Robert Bremer Matsushita Atsuji Itoh* Molex Incorporated Gus Panella Nortel Networks Martin Hall (& at Viewlogic), Calvin Trowell* Oce Printing Systems Ernst Deiringer Praegitzer Design Rick Newell Rockwell Collins Susan Tweeton, Ron Hau Samsung Jung-Gun Byun, Cheol-Seung Choi Shindengen Tsuyoshi Horigome* Signals & Systems Engineering Tom Hawkins STMicroelectronics Fabrice Boissieres, Philippe LeFevre StorageTek Nick Krull Sun Microsystems Victor Chang, Kevin Ko* Tektronix Tom Brinkoetter Teradyne Mikhail Khusid VDOL Robert Novosel Xilinx Susan Wu (Unaffiliated, Retired) Bruce Wenniger 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 July 23, 1999 (916) 356-9200 8-27037 9387986 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 ------------------------------------- IBIS SUMMIT MEETING The IBIS Summit Meeting was held at the Hilton Riverside Hotel in New Orleans, Louisiana, near the site of the Design Automation conference (DAC99). About 27 people representing 21 organizations participated. (14 member companies participated). The minutes just briefly note some meeting content and some other business and discussions. Most of the presentations will be uploaded on the World Wide Web at: http://www.eda.org/pub/ibis/summits/jun99/ Bob asked presentors who have not done so to send him electronic copies. PRELIMINARY BUSINESS: INTRODUCTIONS Bob Ross opened the meeting by introducing Cecilia Fleming of the EIA and thanking her for handling the meeting's logistical and food arrangements. Bob noted that EIA has a booth at DAC which includes an IBIS poster created by Alpert Designs. Bob also thanked Matthew Flora for handling the meeting registration. Bob introduced the current officers in attendance (Bob Ross, Chair, Stephen Peters, Vice Chair, and unofficially Syed Huq, Webmaster), and also noted the services of Matthew Flora, Secretary and Jon Powell, Librarian who could not attend. Bob also welcomed several new participants from Japan: Hideki Fukuda, Atsuji Itoh, and Tsuyoshi Horigome. Everybody then introduced themselves. PRESS AND WEB PAGE UPDATES Bob Ross reported on several IBIS related articles. In the June 1999 issue of Printed Circuit Design, Keith Felton and Todd Westerhoff wrote a guest editorial article "High-Speed PCB Simulation, Is It Time for a Change?" on pp. 42-45 & 63. In the May 27, 1999 issue of EDN, the article by Dan Strassberg "Digital Busses, Analog Problems" pp. 73-86 gives brief mention of IBIS. In the June 7, 1999 issue of EE Times, Ed Sayre authored "Board Design Toes Transmission Line", pp. 70 & 84 and provides general IBIS information. "Signal Integrity and Behavioral Models of Digital Devices" by I.A. Maio, I.S. Stievano, and F.G. Ganavero, Proceedings of the 1999 Zurich Symposium on EMC, February 1999 investigates IBIS simulation algorithms. DEADLINE FOR SP-4557 Bob Ross noted that the deadline for ballots was June 23, 1999. Signed ballots needed to be returned to EIA by surface mail or by FAX. Cecilia Fleming noted that a strong show of support is needed. So far about 12 Yes votes had been received. Two contained some non-controversial comments. Later in the meeting Bob discussed the two comments: One comment suggested having Vmeas and Vref, Rref, and Cref mandatory for output and I/O buffers. The initial rationale for making them optional was to support upward compatibility from Version 1.1 level IBIS models which did not support these subparameters. The second comment was to implement the already approved BIRD58.3 editorial changes to IBIS Version 3.2. Bob suggested that a small group of officers review these and other comments that will come in and draft the formal responses for the IBIS Open Forum to review and approve. The ANSI deadline is August 3, 1999. Bob expected comments received by EIA after June 23, 1999 will still be considered. OVERVIEW PRESENTATION: IBIS 1998 - 1999 & MEETING OVERVIEW - Bob Ross, Mentor Graphics Bob Ross gave a brief summary of 1998 - 1999 progress. This included an update on the standards. IBIS Version 3.2 was ratified January 15, 1999 and is currently undergoing EIA and ANSI review as noted above. Also, IBIS Version 2.1 is going to enter the next phase (FDIS). The only objection to this was really a vote supporting IBIS Version 3.2 instead. Cecilia Fleming mentioned that IBIS Version 3.2 may be put on a fast track after the US ratification activity is completed. Bob provided the current statistics for 1999 participation and membership showing that the high level of IBIS activity has been maintained. Bob noted that besides the formal ratification issues, the major areas of concern are: IBIS Version 4.X additions, Connector Specification, s2ibis3 upgrade planning, IBIS User Group activities regarding the Accuracy Specification and Educational program, and Relationships with EIAJ IMIC and ECALS-2. The committee is following European EMC/EMI and JEDEC activity. On education, Bob noted that material from Arpad Muranyi and Todd Westerhoff could help seed the activity and has been uploaded to: http://www.eda.org/pub/ibis/training/ The remainder of the meeting was outlined as Business (Annual Election of Officers, etc.) Updates (Accuracy and s2ibis2/3 Committees) New Ideas (Behavioral Inputs and Equations) EIAJ Activities (IMIC and ECALS-2) IBIS Version 4.X Features Discussions Other Discussions and Ad Hoc Presentations (We ran out of time for the IBIS Version 4.X features discussion.) BUSINESS CONTINUED: ELECTION OF OFFICERS After some discussion, we added the position of Webmaster (to manage the Web content). D.C. Sessions suggested that Postmaster (to manage the mailing lists) also be added. The following people were nominated and unanimously elected to serve for the 1999 - 2000 year: Chair: Bob Ross, Mentor Graphics Vice-chair: Stephen Peters, Intel Secretary: Guy de Burgh, Viewlogic Librarian: Jon Powell, Viewlogic Webmaster: Syed Huq, Cisco Systems Postmaster: Matthew Flora, HyperLynx The motion was made to amend the bylaws and create the Webmaster and Postmaster positions and corresponding job descriptions. This was approved by a unanimous vote. Will Hobbs asked what is needed for a quorum and what vote is needed. Bob stated that he uses 5 as a quorum for teleconference meetings as stated in the original bylaws. However, Cecilia Fleming noted that we need to align our bylaws with EIA EP-20 for certain official votes. A majority of the official members are required for some votes, and a two-thirds majority is required for standards votes. Bob and Cecilia will research this. AR - Bob Ross and Cecilia Fleming research what is needed to align the IBIS bylaws with EP-20. AR - Bob Ross and Cecilia write position definitions for the new positions of Webmaster and Postmaster. APPRECIATION PLAQUES Cecilia Fleming and Will Hobbs (former Chair. of the EIA IBIS Open Forum) provided EIA plaques to the following people who served as officers (official and unofficial) in appreciation for their service during the last year: Bob Ross Stephen Peters Matthew Flora Jon Powell Syed Huq OPENS FOR NEW ISSUES D.C. Sessions - JEDEC JC-42.3 Report (discussed next) Tsuyoshi Horigome - Unscheduled presentation on Shidengen's Activity on EDA Model and Simulation of Electric Circuit (added at the end of the meeting) JEDEC JC-42.3 REPORT D.C. Sessions who serves in a (mutual) liaison roll between the IBIS Open Forum and JEDEC JC-42 reported on a recent Vancouver JEDEC JC-42.3 meeting concerning Double Data Rate SDRAMs. The JEDEC committee concluded that there is a characterization issue: the slew rate of 1V/ns depends on the loading conditions. The JC-42.3 Committee requests a specification (from the IBIS Open Forum) on derating the slew rate. The reason is that the current derating method works in test conditions, but not in real designs. PRESENTATIONS: (These notes just summarize some of the contents and some discussions on the presentations. Refer to the uploaded presentations for more content.) IBIS ACCURACY SPECIFICATION DAC UPDATE - Bob Haller, Compaq Bob Haller commented on some recent updates to the Accuracy Specification: VT table (golden waveform) and Open drain drivers, simplified correlation levels, and a revised test board. The specification serves as a communication vehicle and reference document. It is not perfect, nor does it cover IBIS Version 3.2 features. Bob asked for help regarding: Test cases for the specification Script/Code for the accuracy correlation metric (Bob has some Perl scripts that need finishing before he can upload them) Technical discussions in the IBIS Open Forum Constructive feedback Acceptance by Users, EDA and semiconductor vendors Pursuit of EIA approval Used by purchasing departments In summary, he needs more volunteers, approvals and, in the future, Version 3.2 enhancements. Bob Ross noted that we will have a technical discussion at the next meeting. The latest accuracy spec. (Version 1.2 document) has not yet been uploaded. AR - Bob Ross put Version 1.2 document on the eda.org website: http://www.eda.org/pub/ibis/accuracy/ IBIS OPEN FORUM SPICE TO IBIS SUBCOMMITTEE STATUS REPORT - Michael Cohen, IBM Michael Cohen introduced the Subcommittee members and the mission to recommend if the IBIS Open Forum should become responsible for the SPICE to IBIS translator code. The secondary mission is to draft some enhancement and bug fix requirements and suggest how to fund the project. Michael discussed the meetings and activities to date. He also presented Mike LaBonte's s2ibis flow to create an IBIS part model. Some general ideas so far are to make the tools be platform and SPICE simulator independent, have good documentation, and have maintainable code. Having a Web based tool is not a goal. Michael reported on feedback to date concerning the enhancement requests and bug reports. Michael also noted that the developer Michael Steer from North Carolina State University believes that the IBIS Golden Parser can be used for the next generation of s2ibis3. To summarize, the committee plans to compile a list of bugs and enhancement requests, make a recommendation to the IBIS Open Forum, generate a list of requirements, and help determine how to fund the project and get bids. SPITRAN: A GUI FOR S2IBIS2 - Mike LaBonte, Cadence Bob Ross introduced Mike LaBonte after commenting that the GUI interface source code is expected to be made publicly available and may also be offered for use in the s2ibis translator project. Mike outlined its general features: Written as a Java application - platform portable Audits SPICE files Prepares top level test circuits Prepares s2ibis control files Runs NCSU s2ibis2 For the remainder of the presentation Mike stepped through an application and showed the GUI templates. In response to comments during and after the presentation, Mike noted that what he is presenting is based on alpha code that will need improvements. He prefers multiple windows with simple questions rather than complex windows. Blank space can be used for explanations. The GUI focuses on doing one buffer at a time. Other code would be used to assemble the complete IBIS model. ADVANCED BEHAVIORAL TIMING ADJUSTMENT - Richard Mellitz, Intel - Adapted and Presented by Stephen Peters, Intel Stephen Peters introduced input buffer modeling by stating that Vinh and Vinl specifications and corresponding derating methods are no longer realistic for newer technologies. Actual input waveforms derate the data. One proposal uses a charge approximation based on finding the area under the input voltage versus time curve. Charge is assumed proportional to this area. Once the threshold crossings are determined, the flight time is adjusted for charge using an area based table. A similar adjustment method is used to determine actual ringback severity. This presentation prompted some discussion concerning the best approach for modeling inputs. D.C. Session indicated that he had considered a similar approach. He had presented at earlier meetings a different proposal based on actual time derating tables using an empirically derived 3/2 power voltage relationship. D.C. suggested he work with Stephen and Richard to agree upon an Input modeling proposal and to submit a BIRD for a Version 4.X extension. THOUGHTS ON EQUATIONS IN IBIS MODELS - Arpad Muranyi, Intel Arpad Muranyi provided background material to characterize SPICE, table driven, and IBIS (or behavioral) models. All models are behavioral. One differentiation is that SPICE models reveal process and circuit information, table driven models can hide the process information, and IBIS models can hide both process and circuit details. Arpad listed benefits of using equations: Equations are more compact Equations are more flexible and general Equations may be faster than lookup tables Equations allow easy scalability However, there can also be problems providing more burden to the model developer and simulator tool. Arpad gave examples where equations could be used in IBIS: Vinh, Vinl as a function of voltage, C_comp as a function of I/O pad voltage, scaling of I/V and V/T data, curve fitting of I/V and V/T data, etc. Equations can assist in the proper accounting of GND and Vcc currents for bounce simulations. This accounting also needs to includes how portions of C_comp are attached to Vcc and GND for both current allocation and possible decoupling effects. An actual simulation shows less bounce than predicted by the standard IBIS model connected to GND. Arpad also showed a "bleed through' effect that differ between PMOS and NMOS pullups. Others noted this as "clock through" or "forward feedback". Arpad also presented some ideas for considerations using equations for modeling transfer functions, power distribution on the die, and treating the model as a matrix - for the purpose of promoting more discussion on the subject. Transfer function could deal with complex impedances or conductances and other transformations. A possible 3 - model can be considered. EIAJ-IMIC Hideki Fukuda, Hitachi Hideki Fukuda, Chair of the I/O Interface Model Project Group under EIAJ in Japan provided much material. Some points are highlighted below. As an overview Fukuda-san gave the goals and history of the activity. The group is positioned under the Technical Standard Center along with a Package Electrical Characterization Project Group. Activity and numerous meetings with the IBIS Open Forum began in August, 1996. One immediate goal is to release Draft Version 1.2 in June, 1999. Fukuda-san gave a general technical overview description of the I/O model, IC, and Board components and of the table SPICE format. IMIC can be used for signal integrity, power integrity and (in the future) EMI simulations Some comparisons between IMIC and SPICE simulations for signal integrity and power integrity situations. Table SPICE simulations performed faster, but Stephen Peters questioned that since some of the results were done using different SPICE simulators the algorithm differences may also contribute to speed differences. However, good correlation was demonstrated for some test cases with coupled ground and power lines. Future work consists of Creating application notes - Signal Integrity of complex buffers - Power/ground bounce - Package electrical characterization Dealing with new technologies - Release an EMI model - Characterize new types of packages - Model a DRAM module Fukuda-san outlined an approach for handling EMI emission form a board: Use terminal currents to find the magnetic field of the circuits of the IC. Model terminal currents by transforming a time varying resistor into a voltage controlled MOSFET transistor Simulate EM emission from the board through its cables The simulation and modeling environment was classified into the Behavioral World and the Netlist World. SPICE, IMIC, Netlist IC simulators and Netlist PCB simulators fall in the Netlist World. IBIS and Behavioral based PCB simulators fall into the Behavioral World. Some Netlist PCB simulators now support IBIS, and IBIS models are being generated from s2ibis conversion. IMIC models fall in between SPICE and IBIS models, and IBIS models could also be generated from an IMIC to IBIS converter. IMIC models could support Netlist Based PCB Simulators. Fukuda-san sees an expansion of IBIS to support IMIC and some of the Netbase simulation environment. He concludes that such a move would benefit all parties - the electronic equipment industry, the EDA industry, and the IC industry. He also concludes that joint work by IBIS and IMIC could improve the silicon interface in PCB simulation. OUTLINE OF ECALS-2 PROJECT AND INVESTIGATION ON EMC/EMI SIMULATION MODELS FOR NON-ICS - Atsuji Itoh, Matsushita Atsuji Itoh, Chair of WG1 for Information Standardization showed ECALS-2 organizational structure. The overall goal of ECALS-2 is to standardize component information and to establish information exchange protocols. Funding is provided by MITI - Japan's Ministry of International Trade and Industry. The WG1 activities are Standardization of Dictionary and EDA model for electronic component information. One of its missions is to promote the EDA mode Representation standard (EDA Simulation Model, Logic Symbol, Footprint, etc.) Another group (SWG12) is involved with confirming the validity of IBIS and IMIC models for non-IC components and provide suggestions regarding IBIS and IMIC. The primary application is EMC/EMI simulation for digital consumer electronics and mobile applications. The consumer electronic design is moving toward rapid digitalization, speed (time to market and shortened lead times) and increased high speed, high density PCBs. Innovations are being made in the design processes, but it continues to be difficult to get simulation models of any format (IBIS, IMIC, SPICE, etc.). One focus of the WG1 group concerns non-IC EMC/EMI models for passive components, connectors and discrete semiconductor devices. IBIS is currently weak in comparison to SPICE for models of EMI filters and discrete networks. IBIS can be used for power semiconductors. Some preliminary results of discussions with model providers and users were given. Some conclusions so far are: Any data format is acceptable (IBIS, IMIC, SPICE), Effort must be made to expedite format standardization and expansion of the range of application, Need a checking tool for full EDA support, Standardization is required and relationships or migration between standard s need to be established between IBIS, IMIC, IEC TC93/WG6. SHINDENGENS'S ACTIVITY ON EDA Model AND SIMULATION OF ELECTRIC CIRCUIT (Added presentation) - Tsuyoshi Horigome, Shindengen Electric Mfg. Co. Tsuyoshi Horigome offered a brief presentation illustrating the user problem of getting EDA models in a timely manner. He showed an example simulating noise in a power module circuit. Model quality and cost are the primary issues, and it took nine months to get good models. FINAL COMMENTS: Bob Ross reminded people to get their SP-4557 comments in. IBIS Version 4.X Discussion was deferred. D.C. Sessions noted that the input and coupled package extensions were critical. Bob noted that the connector activity may relate to coupled package extensions. The next teleconference meeting was proposed to be Friday, July 23, 1999 to avoid conflicting with some vacation plans. NEXT MEETING: The next teleconference meeting will be on Friday, July 23, 1999 from 8:00 AM to 10:00 AM. ============================================================================== 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-56 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 jonp@qdt.com Senior Scientist, Viewlogic Systems 1385 Del Norte Rd. Camarillo, CA 93010 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. 17641 NE 67th Court 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 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 Jun 29 13:15:55 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA02605 for ; Tue, 29 Jun 1999 13:15:52 -0700 (PDT) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id MAA05665 for ; Tue, 29 Jun 1999 12:03:25 -0700 Message-Id: <3.0.5.32.19990629130947.00b76b10@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 29 Jun 1999 13:09:47 +0000 To: ibis@eda.org From: Matthew Flora Subject: [Driver Schedule] question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hello, The [Driver Schedule] keyword supplies a list of other models which are brought into the circuit at specified times. My question is: Can the list of scheduled models contain references to [Model Selectors]'s as well as to [Model]'s? Although this would make things flexible, it would also require more user involvement at a low level. Thanks in advance, Matthew Flora IBIS Open Forum Postmaster (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com HyperLynx, 17641 NE 67th Court, Redmond, WA 98052 USA From owner-ibis Tue Jun 29 13:54:37 1999 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 NAA02791 for ; Tue, 29 Jun 1999 13:54:37 -0700 (PDT) Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA23441; Tue, 29 Jun 1999 13:48:29 -0700 (PDT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Jun 1999 13:48:29 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512703BB0CBD@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'Matthew Flora'" , ibis@eda.org Subject: RE: [Driver Schedule] question Date: Tue, 29 Jun 1999 13:48:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Matt, Even though the spec doesn't explicitly say that the [Model Selector] cannot call another [Model Selector]s, the usage rules only mention [Model]s throughout the description of the keyword. For keeping things simple, I would prefer not to allow nested selectors, though I can't say that it is strictly illegal either. Arpad ======================================================================== -----Original Message----- From: Matthew Flora [mailto:mbflora@hyperlynx.com] Sent: Tuesday, June 29, 1999 6:10 AM To: ibis@eda.org Subject: [Driver Schedule] question Hello, The [Driver Schedule] keyword supplies a list of other models which are brought into the circuit at specified times. My question is: Can the list of scheduled models contain references to [Model Selectors]'s as well as to [Model]'s? Although this would make things flexible, it would also require more user involvement at a low level. Thanks in advance, Matthew Flora IBIS Open Forum Postmaster (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com HyperLynx, 17641 NE 67th Court, Redmond, WA 98052 USA From owner-ibis Tue Jun 29 14:02:44 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA02864 for ; Tue, 29 Jun 1999 14:02:42 -0700 (PDT) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id MAA05978; Tue, 29 Jun 1999 12:50:03 -0700 Message-Id: <3.0.5.32.19990629135625.00985e70@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 29 Jun 1999 13:56:25 +0000 To: "Muranyi, Arpad" From: Matthew Flora Subject: RE: [Driver Schedule] question Cc: ibis@eda.org In-Reply-To: <4575832C8E71D111AC4100A0C96B512703BB0CBD@fmsmsx36.fm.intel .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Arpad, >Even though the spec doesn't explicitly say that the [Model Selector] >cannot call another [Model Selector]s, the usage rules only mention [Model]s >throughout the description of the keyword. For keeping things simple, I >would prefer not to allow nested selectors, though I can't say that it is >strictly illegal either. I think the spec does say that nested [Model Selector]'s are not allowed. What I meant to be asking is can a [Model Selector] be inside (referenced by) a [Driver Schedule]? Cheers, Matt From owner-ibis Tue Jun 29 15:11:19 1999 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 PAA03053 for ; Tue, 29 Jun 1999 15:11:19 -0700 (PDT) Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id PAA09473 for ; Tue, 29 Jun 1999 15:05:15 -0700 (PDT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Jun 1999 15:05:14 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512704A797A1@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'ibis@eda.org'" Subject: RE: [Driver Schedule] question Date: Tue, 29 Jun 1999 15:05:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Matt, I am sorry, I misunderstood your question. Reading the usage rules of the [Model Selector] keyword, I would say that only the [Pin] and [Series Pin Mapping] keywords should call the [Driver Schedule] keyword, even though it doesn't explicitly say that no other keywords are allowed to reference it. Again, this seems to add unnecessary complexity, and it may confuse too many people and software. Do you actually have a buffer that does this? Arpad ============================================================================ ================= -----Original Message----- From: Matthew Flora [mailto:mbflora@hyperlynx.com] Sent: Tuesday, June 29, 1999 6:56 AM To: Muranyi, Arpad Cc: ibis@eda.org Subject: RE: [Driver Schedule] question Arpad, >Even though the spec doesn't explicitly say that the [Model Selector] >cannot call another [Model Selector]s, the usage rules only mention [Model]s >throughout the description of the keyword. For keeping things simple, I >would prefer not to allow nested selectors, though I can't say that it is >strictly illegal either. I think the spec does say that nested [Model Selector]'s are not allowed. What I meant to be asking is can a [Model Selector] be inside (referenced by) a [Driver Schedule]? Cheers, Matt From owner-ibis Tue Jun 29 16:24:55 1999 Received: from ptldpop2.ptld.uswest.net (ptldpop2.ptld.uswest.net [198.36.160.2]) by server.eda.org (8.8.5/8.8.3) with SMTP id QAA03277 for ; Tue, 29 Jun 1999 16:24:54 -0700 (PDT) Received: (qmail 11024 invoked by alias); 29 Jun 1999 23:18:48 -0000 Delivered-To: fixup-ibis@eda.org@fixme Received: (qmail 10988 invoked by uid 0); 29 Jun 1999 23:18:46 -0000 Received: from premiumf6.ptld.uswest.net (HELO vasthorizons.com) (207.225.90.6) by ptldpop2.ptld.uswest.net with SMTP; 29 Jun 1999 23:18:46 -0000 Message-ID: <37795458.9E7543C4@vasthorizons.com> Date: Tue, 29 Jun 1999 16:18:48 -0700 From: Scott McMorrow Reply-To: scott@vasthorizons.com X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Flora CC: "Muranyi, Arpad" , ibis@eda.org Subject: Re: [Driver Schedule] question References: <3.0.5.32.19990629135625.00985e70@hyperwall> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matt, Seems to me that what is not excluded by the specification is allowed. Personally, I would rather see [Model Selector]'s point to [Driver Schedule]'s. This makes much more sense from an actual engineering perspective. Regards, Scott Matthew Flora wrote: > Arpad, > > >Even though the spec doesn't explicitly say that the [Model Selector] > >cannot call another [Model Selector]s, the usage rules only mention [Model]s > >throughout the description of the keyword. For keeping things simple, I > >would prefer not to allow nested selectors, though I can't say that it is > >strictly illegal either. > > I think the spec does say that nested [Model Selector]'s are not allowed. > What I meant to be asking is can a [Model Selector] be inside (referenced by) > a [Driver Schedule]? > > Cheers, > Matt From owner-ibis Tue Jun 29 17:11:00 1999 Received: from mail-gw6.pacbell.net (mail-gw6.pacbell.net [206.13.28.41]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA03375 for ; Tue, 29 Jun 1999 17:11:00 -0700 (PDT) From: jonp@pacbell.net Received: from postoffice.pacbell.net (ppp-209-79-182-220.vntrcs.pacbell.net [209.79.182.220]) by mail-gw6.pacbell.net (8.9.3/8.9.3) with ESMTP id RAA07838; Tue, 29 Jun 1999 17:04:19 -0700 (PDT) Message-ID: <37795DD5.DCA7AA91@postoffice.pacbell.net> Date: Tue, 29 Jun 1999 16:59:17 -0700 Reply-To: jonp@pacbell.net X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) MIME-Version: 1.0 To: "ibis@vhdl.org" Subject: IBIS model page updated Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The IBIS model page has been updated. Thanks to everyone who contributed. Please keep those cards and letters (ok, email) coming. Also, any IC companies who would like to contribute some text to the page, I would be glad to include any IBIS specific technical information (keep it short, about a paragraph, limit to model and technology types or other pertinent data). You new librarian, Jon Powell IBIS model page located at: www.viewlogic.com/ibis From owner-ibis Wed Jun 30 11:55:03 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA08111 for ; Wed, 30 Jun 1999 11:55:01 -0700 (PDT) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id KAA09819; Wed, 30 Jun 1999 10:42:42 -0700 Message-Id: <3.0.5.32.19990630114855.0091ca40@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 30 Jun 1999 11:48:55 +0000 To: arpad.muranyi@intel.com From: Matthew Flora Subject: RE: [Driver Schedule] question Cc: ibis@eda.org In-Reply-To: <4575832C8E71D111AC4100A0C96B512704A797A1@fmsmsx36.fm.intel .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Arpad, >I am sorry, I misunderstood your question. Reading the usage rules of the >[Model Selector] keyword, I would say that only the [Pin] and [Series Pin >Mapping] keywords should call the [Driver Schedule] keyword, even though it >doesn't explicitly say that no other keywords are allowed to reference it. >Again, this seems to add unnecessary complexity, and it may confuse too many >people and software. Do you actually have a buffer that does this? I am sorry, let me give a contrived example. In the example below, notice that [Model] X contains a [Driver Schedule] and that that [Driver Schedule] is referencing [Model Selector] foo. Is that legal? Thanks, Matt [Model Selector] foo | Model_name Comment Y ultra mode Z extra ultra (magic) mode [Model] A . . . [Model] B . . . [Model] X . . [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly foo ... A ... B ... . . [Model] Y . . . [Model] Z . . .