From owner-ibis Mon Nov 1 09:34:54 1999 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA29147 for ; Mon, 1 Nov 1999 09:34:52 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id MAA07196 for ; Mon, 1 Nov 1999 12:33:56 -0500 (EST) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id MAA27543 for ; Mon, 1 Nov 1999 12:33:55 -0500 (EST) Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id JAA02507 for ; Mon, 1 Nov 1999 09:34:44 -0800 (PST) Date: Mon, 1 Nov 1999 09:34:44 -0800 (PST) From: Guy de Burgh Message-Id: <199911011734.JAA02507@taurus.camarillo.viewlogic.com> To: ibis@eda.org Subject: EIA IBIS Open Forum Meeting Minutes - 10/29/99 DATE: 11/1/99 SUBJECT: 10/29/99 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: Applied Simulation Technology Raj Raghuram, Norio Matsui, Neven Orhanovic, Fred Ballesteri Avanti Nikolai Bannov* Cadence Design Mike LaBonte, Todd Westerhoff Cisco Systems Syed Huq Compaq Bob Haller*, Steve Coe, Shafir Rahman, Maher Elasad, Peter LaFlamme, Doug Burns Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella, Alex Nosovitski, Shan Haq Fairchild Semiconductor [Peter LaFlamme], Craig Klem, Graham Connolly, Christian Klein H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu HyperLynx (& Pads Software) Matthew Flora*, Kellee Crisafulli, Lynne Green, John Angulo*, Gene Garat, Robin Edwards IBM Greg Edlund, Michael Cohen*, Praven Patel, Paul Clouser 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, Tom Dagostino, Mohamed Nasef Mitsubishi (Tam Cao) Motorola (Ron Werner) National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda, Ed Sayre III, Jinhua Chen NEC (Hiroshi Matsumoto) Nortel Networks Martin Hall (& at Viewlogic), Calvin Trowell Ross Pryor* 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 Time Domain Analysis Systems Dima Smolyansky, Steven Corey Viewlogic Systems Chris Rokusek, Guy de Burgh*, Cary Mandel, (Jon Powell) VeriBest Ian Dodd Via Technologies (Weber Chuang) VLSI Technology D.C. Sessions OTHER PARTICIPANTS IN 1999: 3Com Roy Leventhal 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 Celestica Danny Da Silva Dynamics Research Corporation Mike Walsh ECI Telecom Daniel Adar EIA [Patti Rusher], Cecilia Fleming*, Dan Heinemeier Electronique Catherine Gross EFM Consulting Ekkehard Miersch FCI John Ellis Foxcomm Jeff Walden General DataComm Laurence Michaels High Design Technology Razvan Ene Hitachi ULSI Hideki Fukuda Infineon Thomas Latzel Intracon Design Mike Osmond KAW Shinichi Maeda Litton Systems Robert Bremer Lucent Jason Pritchard Matsushita Atsuji Itoh Molex Incorporated Gus Panella* Newbridge Networks Bruce Carlile Oce Printing Systems Ernst Deiringer Praegitzer Design Rick Newell, Paul Galloway, Joe Socha Rockwell Collins Susan Tweeton, Ron Hau Rode Consulting Chris Rode Samsung Jung-Gun Byun, Cheol-Seung Choi Shindengen Tsuyoshi Horigome Signals & Systems Engineering Tom Hawkins STMicroelectronics Fabrice Boissieres, Philippe LeFevre Stratus Keith Vieira StorageTek Nick Krull Sun Microsystems Victor Chang Kevin Ko, Greg Fitzgerald, Nick LaPlaca 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 November 19, 1999 (916) 356-9200 2-356763 7473493 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 participants. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross has already announced that Via Technologies and Nortel Networks have joined making the total IBIS Open Forum Membership at 32. All members have now paid. Because the most recent members joined late in 1999, we will probably carry their membership through year 2000 and issue invoices only for differences in dues, if any. REVIEW OF MINUTES AND AR'S The October 1, 1999 IBIS Open Forum Meeting and October 14, 1999 IBIS Summit Meeting minutes were approved without change. Other AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Bob Ross reported that Syed Huq made some more Roster page updates and Guy de Burgh has been tracking down the final membership names. The last report indicated that information is still needed from three member companies. Bob noted that a show link has been added for show literature on conferences we participate in at: http://www.eda.org/pub/ibis/shows/designcon2000/ The Upcoming Events page also links to this for the DesignCon2000 IBIS Meeting. Also Bob stated that Mike LaBonte sent out the announcement that a public domain version of (including source code of user interface) of Spitran from Cadence is uploaded on the IBIS home page under FREE Tools. http://www.eia.org/eig/ibis/ibis.htm and is available for downloading on http://www.eda.org/pub/ibis/s2ibis/spitran/ Bob reported the article "Models for Signal Integrity Simulation" in the October 1999 issue of Printed Circuit Design by Lynne Green on pp. 22-24. Bob reported that four Siemens IBIS presentations are available from the Siemens site including three which were given at IBIS Summits: http://www.atd.siemens.de/it-dl.alt/eda/emv/download/ibis_summit399.pdf http://www.atd.siemens.de/it-dl.alt/eda/emv/download/ibis_summit299.pdf http://www.atd.siemens.de/it-dl.alt/eda/emv/download/ibis_summit98.pdf http://www.atd.siemens.de/it-dl.alt/eda/emv/download/ibis_be_ft98.pdf Finally, Bob reported the article "Models for Signal Integrity Simulation" in the October 1999 issue of Printed Circuit Design by Lynne Green on pp. 22-24. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported that Jon Powell is still updating the Model page. Bob reported these additions and changes: Clear Logic has IBIS Models under http://www.clear-logic.com/literature/ibis.html Integrated Circuits Systems, Inc. (ICS) has one model under: http://www.icst.com/pdf/ics1523.ibs Integrated Silicon Solutions, Inc. (ISSI) has a place for links. The SRAM products already show IBIS model entries. http://www.issi.com/models.html Samsung Models online again for DRAM, SRAMS, Graphic Memory, Mask ROM, and Flash Products in these links, respectively: http://www.usa.samsungsemi.com/simulationmodels/dram/dram.htm http://www.usa.samsungsemi.com/simulationmodels/sram/sram.htm http://www.usa.samsungsemi.com/simulationmodels/gram/gram.htm http://www.usa.samsungsemi.com/simulationmodels/mrom/mrom.htm http://www.usa.samsungsemi.com/simulationmodels/flash/flash.htm Tundra Semiconductor has some IBIS Models that are downloadable and also available through direct contact. These are found by following the Products links to the Toolbox link: http://www.tundra.com/ Xilinx IBIS Models have moved to http://support.xilinx.com/support/troubleshoot/htm_index/sw_ibis.htm OPENS FOR NEW ISSUES Arpad Muranyi on BIRD64 - Package Model Selector Arpad Muranyi on BIRD65 - C_comp Refinements INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Cecilia Fleming reported that progress is continuing, but IEC has decided to substitute Version 3.2. Bob Ross commented that a copyright issue between EIA and IEC was favorably resolved so that EIA (and the IBIS Open Forum) retains the copyright to control and modify the document. Cecilia stated that she expects IEC 62014-1 to be officially ratified within a few months. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross reported that a Version 1.2 has been posted for review by December 25, 1999. The link to this document can be found on the Specs page of the EIA IBIS home page. - IEC PWI 93-1 Models of Integratd Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross had no report. - JC-16.2 Subcommittee: Modeling and Test - Bob Ross had no report. IBIS SUMMIT OCTOBER 14, 1999 REVIEW Bob Ross felt that we had a successful IBIS Summit Meeting on October 14, 1999 with good interaction. We unintentionally scheduled the meeting on the last day of the PCB Conference East trade show, and several participants had to leave early (or could not attend). This was due the the trade show being unexpectedly shifted by one day to avoid Columbus day holiday rates for setup costs. Bob noted that we are planning to hold the next East Coast IBIS Summit Meeting on Thursday, September 14, 1999, possibly at Worchester, Massachusetts where the PCB Conference East is being held. We believe this is a non-trade show day. FUTURE IBIS SUMMITS Bob Ross noted that the DesignCon2000 IBIS Summit Meeting is being planned for Monday, January 31, 1999 in Santa Clara, California. Jon Powell will be coordinating the trade show IBIS booth arrangements. National Semiconductor will sponsor the lunch, and DesignCon2000 will sponsor (fund) the meeting room and other refreshments. This is the normal arrangement because the IBIS Open Forum is officially an Associate Sponsor of DesignCon2000. Bob noted the he had sent out a DesignCon2000 invitation note to register early. October 31, 1999 was the last day for discounts. However, employees of any of the 32 member companies will also get discounts to the DesignCon2000 Conference. Returning attendees will get the best discount (20%) to the Conference. As noted earlier, the DesignCon2000 advance registration brochure can be accessed from the IBIS home page Upcoming Events link. Bob stated that the IBIS Summit Meeting at Date2000 in Paris, France is being planned on Friday, March 31, 1999 from the morning through early afternoon. This will accommodate European participants to return home on Friday. So far Incases and Mentor Graphics are co-sponsors, but we are seeking other co-sponsors. S2IBIS3 COMMITTEE REPORT Michael Cohen reported on meetings held on October 21, 1999 and October 28, 1999. He stated that teleconference meetings are now being held every Thursday. Work is continuing on a requirements specification. Michael expects that it will be made available by the end of the year. IBIS DUES AND FUNDING Bob opened the discussion on IBIS Funding and dues by giving some background information. The IBIS Open Forum membership currently costs $500 per year. Actual expenses were much less than the money received and we would just leave the remaining money with EIA to cover the administrative overhead and expenses for the services provided. The EIA accounting system has never provided the EIA IBIS Open Forum meaningful information about actual expenses or income. However, EIA has now improved the accounting and reporting system and now able to track income and expenses better. Based on reasonable allocations for EIA services, we can now allocate some reasonable costs for direct EIA support (part of Cecilia Fleming and staff) and other EIA services for legal, accounting, international representation, etc. Bob gave a projected Year 2000 budget that was sent out to the IBIS reflector (and is included in the Minutes below). Bob explained some to the items. The income is based on an estimated 30 members, at $500 per year. The Other Income is an estimation of the royalties to the IBIS Open Forum for Global Engineering Standards sales (before, we hand no record of this). The Travel & Entertainment expense and Meetings and Conference Expense are for the IBIS Summit Meeting held in June and associated with the Design Automation Conference. Unlike other Summit Meetings, this IBIS Summit Meeting is supported directly by the EIA IBIS dues. Cecilia noted that EIA appears to be comfortable with the expense allocations in the Budget. However, the formal EIA discussion on total budget issues was deferred until December 1999. Bob also felt that the allocations were very reasonable for the services provided and for the official national recognition we have achieved that could only be obtained through affiliation with an organization such as EIA. We still continue to self-fund a number of activities (other IBIS Summits, teleconference calls) and special projects (such as ibischk3 development.) through additional contributions. BUDGET: INCOME IBIS Membership Dues $15,000 Other Income 1,000 Fees & Assessments EXPENSES Basis: ------------------------------ IBIS Budget Salaries and Benefits $9,000 Interest Expense Not Allocated Occupancy 610 Bad debts Not Allocated Depreciation 250 Printing 200 Postage 150 Freight & Delivery 100 Travel & Entertainment 2,000 Telephone 200 Meetings and Conference Exp. 2,000 Professional Services Direct Expense Memberships & Subscriptions Not Allocated Web Site Services Not Allocated Advertising & Promotions 500 Show Expenses (Deleted) Office Supplies & Misc. 700 ------- Total Exp. Before Corp. Alloc. 15,710 Corporate EIA 4,000 ------- Total Expenses 19,710 ------- Projected Loss 3,710 ------- Bob noted that the proposed budget projects a loss. We have already discussed this topic at the October 1, 1999 meeting and felt comfortable with a modest dues increase. Unlike previous years, a key difference in Year 2000 and beyond is that we will retain and carry over any profits in the IBIS account. (Up to now, it has been a "use it or lose it" arrangement.) Bob suggested we consider a dues increase to either $750 (break even) or $1000 (modest profit to fund some of the activities). Bob Haller commented on the fact that in several companies, a $1000 expense is the amount where more internal signatures are needed - causing more difficulty in authorizing the expenditure. After further discussion it was agreed that we will propose to the year 2000 dues to $750. Bob then indicated that based on the original IBIS Charter created when IBIS became part of EIA, dues increases require a vote of two-thirds of the members. In our case this would now be 21 members. This is more stringent than official EIA approval guidelines (approval by three forths of a margin from votes cast by a majority of members (3/4 of 17, or 13). Or we could require just a simple majority of members (17). In any case, since this is an issue regarding financial commitment, we need this proposal to be voted on and approved by a substantial part of the IBIS Open Forum Member Companies. Michael Cohen asked about the resolution of the discussion of IBIS Bylaws with EIA per the June 21, 1999 IBIS meeting. Bob noted that we plan to use the "escape clause" mechanism (noted in the October 1, 1999 Meeting Minutes) that support alternative modes of operation that already exist. Much of the EP-20 bylaw guidelines would substantially change the way we operate. The guidelines do not work well with our mode of operation of conducting frequent teleconference meetings and using public e-mail reflectors for conducting discussions. So we plan to comply by not changing our current mode of operation. After some more discussion Bob indicated that we will do our balloting on the proposed membership fee increase by polling the Member companies (primary and secondary representatives) by e-mail. We want to achieve a significant consensus - probably 17 to 21 votes as an indication of approval. Guy de Burgh will send out and tabulate the ballots. The deadline for e-mail vote will be November 18, 1999, just prior to the next IBIS teleconference meeting. Bob conducted a roll-call vote and we already recorded 8 affirmative votes and no negative votes on raising the IBIS Membership dues to $750 per year. AR - Guy de Burgh create a letter ballot to e-mail to members on dues increase to $750 and send it out to the IBIS Member companies. [Done] NEW IBIS OFFICER POSITIONS Bob Ross also indicated that creating new IBIS Officer positions is technically a Charter change requiring a similar consensus as above. So we will also send out a letter ballot for the new Postmaster position (already staffed by Matthew Flora) and the Webmaster position (already staffed by Syed Huq), as a formality. The four existing and two new positions are listed for reference: Position Responsibilities ----------------------------------------------------------------------------- Chairperson Oversee all forum activities, preside at all general meetings. Finance authority. This person must be an employee of a Membership Company. Vice Chair Cover for chair and secretary in their absence, coordinate all public relations (press releases, media contacts). This person must be an employee of a Membership Company. Secretary Coordinate logistics of all meetings, take and publish meeting minutes within 10 days of meeting. [Delete this task since it is transferred to the Postmaster: Work with or act as file server sysop to maintain the reflector and on-line files.] This person does not need to be an employee of a Membership Company. Librarian Maintain the library of public IBIS models, including verifying authenticity and compliance before posting. This person does not need to be an employee of Membership Company. Webmaster Maintains the contents of the official EIA IBIS Open Forum Web site and Roster files under www.eia.org either directly or through contact with EIA staff. This person does not need to be an employee of a Membership Company. Postmaster Maintains the e-mail distribution lists and performs file server sysop activities for the on-line files on the IBIS site: www.eda.org/pub/ibis/. This person does not need to be an employee of a Membership Company. AR - Guy de Burgh create a letter ballot to e-mail to amend the charter to include the new Webmaster and Postmaster positions and send it out to IBIS member companies. [Done] COOKBOOK STATUS Stephen Peters had no report. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora reported that he recently sent out for review a model from Cimaron (an AMCC company). (Added after the meeting - Matthew also sent out earlier a model of a series switch from Fairchild Semiconductor for review.) Matthew Flora is looking for some more EDA companies to review models. (He has five so far and needs a replacement name for one of the companies.) Ross Pryor voluteered to help, but Bob Ross explained that the Model Review Committee is composed of EDA simulator vendors so that the review process could actually include simulation in a variety of simulators. It also would not have one semiconductor vendor review the models from another semiconductor vendor - a potentially sensitive issue for some vendors. (Bob thanked Ross for volunteering and hopes he will help in another area.) Bob and Matthew will work off line on getting some new Model Review Committee members. IBISCHK3 BUG REPORT STATUS Matthew Flora indicated that he just issued an updated BUG34 in compliance with the AR for specific suggestions on the conditions where Warning Messages should be issued. Since updated BUG34 has just been issued, Matthew wanted to defer the discussion to the next meeting AR - Matthew Flora issue a revised BUG34 to document the conditions where Warning messages are issued [Done]. CONNECTOR PROPOSAL STATUS Because Gus Panella needed to leave early, we moved the Connector Proposal Status discussion as the next discussion item. Bob Ross briefly summarized that since introduction of the Connector Specification proposal at the February 1, 1999 IBIS Summit Meeting, there has been no IBIS Open Forum action. The IBIS Open Forum was heavily involved in formal closure and ratification of IBIS Version 3.2. Since the Connector Specification was proposed as a separate document, it did not need to be considered while IBIS Version 3.2 was being considered. However, related documents have been uploaded under: http://www.eda.org/pub/ibis/connector/ Gus Panella stated that there have been a few review comments. They have been incorporated into a revised version. One of the main comments dealt with defining and describing the matrix. Bob Haller asked whether cables are supported. Gus stated that the intention was to focus on just connectors. Bob Ross stated that he thought that using it for modeling cables was valid. However, the first release of the document does not include frequency dependent losses or skin effect losses. One of the other issues to consider is whether the format can be applied to the existing package model format. Bob Haller also asked about some other changes, and Gus reponded that the suggestions have been implemented in unreleased updates. Bob Ross suggested that we now plan Connector Specification discussion as an actual Agenda item. Gus indicated that he can participate in the next teleconference meeting. A new document may be available by that time. We need to look at it from a full Committee and broader EDA Vendor perspective to discover any implementation and usage issues. BIRD61 - ENHANCED CHARACTERIZATION OF RECEIVERS BIRD62 - ENHANCED CHARACTERIZATION OF RECEIVER THRESHOLDS (discussed First) BIRD63 - DOCUMENTATION OF RECEIVER SETUP AND HOLD TIMING CONDITIONS Stephen Peters reported no further progress on BIRD61, BIRD62 and BIRD63. We are still waiting for some possible behavioral input modeling proposals for BIRD61. Bob Ross indicated that there has been plenty of reflector discussion on BIRD61, and some general issues remain unresolved. There also may be some syntax detail issues regarding BIRD62 and BIRD63. However, the general concepts seem to be acceptable. All of these BIRDs need to be considered in the context of some alternative ideas for future extensions of IBIS that are now being discussed. BIRD64 - PACKAGE MODEL SELECTOR Arpad Muranyi introduced BIRD64 to deal with the fact that some components need several package models for analysis. A primary application would be to issue min and max package models to support corner analysis. Several people have already issued comments on the IBIS reflector. Most comments provide syntax variations but support the same functionality. Arpad initially started with formatting the [Package Model Selector] keyword similar to the [Model Selector] keyword format. However, he decided on a more simple approach that was not exactly compatible. Bob Ross commented that [Model Selector] was designed to simultaneously change the I/O buffer model for several pins, whereas the [Package Model Selector] would change the package model for just one [Component]. Stephen Peters stated that he supported the simpler approach. Arpad thought that the choice of format depended on what would be best for a GUI (or for automated processing). Bob summarized some choices available including those suggested on the IBIS reflector: 1. Do nothing. We already support different package configurations. This support requires issuing a different [Component] model for each package configuration. If we are dealing with only two or three variations, this may be acceptable. 2. [Package Model Selector] as in BIRD64 where the selection choices replace the [Package Model] keyword. 3. [Package Mode Selector] at higher level, similar to [Model Selector], where [Package Model] references the [Package Model Selector] by name, which in turn references the list of package models. 4. Extend [Package Model] from one call into a typ-min-max format rather than using [Package Model Selector]. We ended the discussion in order to move on to other Agenda items. BIRD65 - C_comp REFINEMENTS Arpad Muranyi also introduced BIRD65. BIRD65 provides detail by documenting how portions of C_comp can be connected the various power rails. Michael Cohen stated that the nomenclature was not clear. For example he did not realize that C_comp_pu was the portion of C_comp connected to the [Pullup Reference Voltage]. The overview definition is given in the introductory information, but is not stated in the actual replacement text proposed by BIRD65. Arpad stated that he clarify the C_comp elements in the proposed text. Bob Ross indicated that BIRD65 was proposed to support more accurate ground and power bounce analysis. The basic idea is seems sound. However, we may need to consider it in the context of some other alternative proposals that may accomplish the same objective. Arpad closed by noting that he is looking for IBIS reflector comments about the possibility of adding capacitance as a function of voltage tables. APPLICATION PROGRAM INTERFACE (API) DISCUSSION In the remaining time, Stephen Peters discussed the intent of the API. He stated that new device technologies and functions in devices often require new IBIS keywords and take time to be approved. In the mean time the actual structural model (such as a Spice model) could be used, but issue rapidly to support EDA Vendors. To prevent revealing intellectual property details, such a model could be issued as part of some executable code. Stephen stated that he has initiated a proposal to describe the interface to such an API. The major extension are to also include ground and power ports for some more detailed analysis. With a standardized interface, models could be issued in a timely manner as part of an executable. The draft proposal is currently being review internally. It does have implications concerning an evolution of IBIS and is temporarily designated as "IBIS-X". Stephen expects the proposal to be issued on the IBIS reflector early next week (week of November 1, 1999). NEXT MEETING: The next teleconference meeting will be on Friday, November 19, 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-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@viewlogic.com Senior Manager, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic Systems 1369 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. 114715 N.E. 95th Street Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org 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 Nov 5 08:30:11 1999 Received: from beta.dmz-eu.st.com (beta.st.com [164.129.1.35]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA05276 for ; Fri, 5 Nov 1999 08:30:10 -0800 (PST) From: Riccardo.GIORDANI@st.com Received: from eux100.sgp.st.com (eux100.sgp.st.com [164.129.225.7]) by beta.dmz-eu.st.com (Postfix) with ESMTP id E330E2883 for ; Fri, 5 Nov 1999 16:28:26 +0000 (GMT) Received: from localhost (root@localhost) by eux100.sgp.st.com (8.8.6 (PHNE_17190)/8.8.6) with SMTP id RAA16506 for ibis@eda.org; Fri, 5 Nov 1999 17:24:21 +0100 (MET) X-OpenMail-Hops: 2 Date: Fri, 5 Nov 1999 17:23:47 +0100 Message-Id: Subject: C_comp value MIME-Version: 1.0 To: ibis@eda.org Content-Type: text/plain; charset=US-ASCII; name="C_comp" Content-Disposition: inline; filename="C_comp" Content-Transfer-Encoding: 7bit Dear Gentleman , I have some doubts about the C_comp value inside the IBIS model. I hope you can help me. I read this definition inside the IBIS spec : C_comp defines the silicon Die capacitance .. but I did not understand well. This is the value I obtain from a parasitic extraction from layout or it is the input or output capacitance I can read inside my chip Spec ? Thank you in advance for your help , Your Sincerelly Riccardo Giordani From owner-ibis Tue Nov 9 04:44:51 1999 Received: from mail.huawei.com.cn ([202.96.135.132]) by server.eda.org (8.8.5/8.8.3) with ESMTP id EAA27532 for ; Tue, 9 Nov 1999 04:44:48 -0800 (PST) Received: from huawei.com.cn ([10.11.72.32]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA17761; Tue, 9 Nov 1999 20:43:00 +0800 Message-ID: <38281695.D49DE70E@huawei.com.cn> Date: Tue, 09 Nov 1999 20:41:57 +0800 From: sunweifeng X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ibis-users , "ibis-vhdl.org" Subject: help Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sir, There are some questions for the motorola's ibis model of mpc860, hope you can help me. I simulated my design using above ibis model by signoise of cadence, and found: 1. The pullup voltage range of this model is -10V to 5V, do think it is right? If not, would you please to tell me how to modify it ? 2. The receiver simulation waveform have overshoot at the falling and undershoot at the rising when the I_O1 or I_O2 buffer of mpc860 is a driver. I think the waveform is not correct, do you think so? 3. If remove the rising waveform and falling waveform parameter from the model, the clamp have only the dv/dt, simulated the same net again, the receiver waveform don't have the overshoot at the falling and undershoot at rising, but the high level of receiver waveform is not 3.3V, it is 2.6V. Maybe it also is not right. I want to know how modify the model parameter to increase the high level to 3.3V? Atteched file is ibis model of mpc860, hope you can help me to check it and tell me why, and hope you can tell me how to check a ibis model accuracy . thanks a lot. Best Regareds, Sun Weifeng From owner-ibis Tue Nov 9 18:05:58 1999 Received: from mail.huawei.com.cn ([202.96.135.132]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA01725 for ; Tue, 9 Nov 1999 18:05:05 -0800 (PST) Received: from huawei.com.cn ([10.11.72.32]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA27009; Wed, 10 Nov 1999 10:03:17 +0800 Message-ID: <3828D224.1B149CC7@huawei.com.cn> Date: Wed, 10 Nov 1999 10:02:13 +0800 From: sunweifeng X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ibis-users , "ibis-vhdl.org" Subject: Help Content-Type: multipart/mixed; boundary="------------9F935E63637944FA62032BC9" This is a multi-part message in MIME format. --------------9F935E63637944FA62032BC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sir, There are some questions for the motorola's ibis model of mpc860, hope you can help me. I simulated my design using above ibis model by signoise of cadence, and found: 1. The pullup voltage range of this model is -10V to 5V, do think it is right? If not, would you please to tell me how to modify it ? 2. The receiver simulation waveform have overshoot at the falling and undershoot at the rising when the I_O1 or I_O2 buffer of mpc860 is a driver. I think the waveform is not correct, do you think so? 3. If remove the rising waveform and falling waveform parameter from the model, the clamp have only the dv/dt, simulated the same net again, the receiver waveform don't have the overshoot at the falling and undershoot at rising, but the high level of receiver waveform is not 3.3V, it is 2.6V. Maybe it also is not right. I want to know how modify the model parameter to increase the high level to 3.3V? Atteched file is ibis model of mpc860, hope you can help me to check it and tell me why, and hope you can tell me how to check a ibis model accuracy . thanks a lot. Best Regareds, Sun Weifeng --------------9F935E63637944FA62032BC9 Content-Type: application/x-unknown-content-type-IBS_auto_file; name="mpc860.ibs" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mpc860.ibs" fCoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KfCAvIDdcJzcgICAgICAgICAgIE1vdG9yb2xhIFBvd2Vy cGMgTVBDODYwIEkvTyBCdWZmZXIgSUJJUyBGaWxlDQp8IFwgXCAgICAgICAgICAgICAgICAg ICAgICAgICAgTW90b3JvbGEgSW5jLg0KfCAvIC8gICAgICAgICAgICAgICAgICAgICAgDQp8 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQoNCltJQklTIFZlcl0gICAgICAyLjENCltGaWxlIG5hbWVd ICAgICBtcGM4NjAuaWJzDQpbRmlsZSBSZXZdICAgICAgMi4wDQpbRGF0ZV0gICAgICAgICAg Ni8xMC85Ng0KW05vdGVzXSAgICAgICAgDQp8KioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQp8ICAgICAg ICAgICBDb21wb25lbnQgTVBDODYwDQp8KioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCltDb21wb25l bnRdICAgICBNUEM4NjANCltNYW51ZmFjdHVyZXJdICBNb3Rvcm9sYQ0KW1BhY2thZ2VdDQpS X3BrZyAgIDAgICAwICAgMA0KTF9wa2cgICAwICAgMCAgIDANCkNfcGtnICAgMCAgIDAgICAw DQoNCg0KW1Bpbl1zaWduYWxfbmFtZSBtb2RlbF9uYW1lDQoxICAgQTEgICAgICAgICAgICAg ICAgICAgQ0xLDQoyICAgQTIgICAgICAgICAgICAgICAgICBBQ1BVDQp8MSAgIG5nbmRfcCAg ICAgICAgICAgICAgICAgICBHTkQNCnwyICAgbGQzICAgICAgICAgICAgICAgICAgICAgIElf TzINCjMgICBsZDIgICAgICAgICAgICAgICAgICAgICAgSV9PMg0KNCAgIGxkMSAgICAgICAg ICAgICAgICAgICAgICBJX08yDQo1ICAgbGQwICAgICAgICAgICAgICAgICAgICAgIElfTzIN CjYgICBsb2FkX2hzeW5jX3NkYWNrMV9iICAgICAgSV9PMg0KNyAgIGxjZGFjX2xvZSAgICAg ICAgICAgICAgICBJX08yDQo4ICAgZnJhbWVfdnN5bmMgICAgICAgICAgICAgIElfTzINCjkg ICBzaGlmdF9jbGtfc2RhY2syX2IgICAgICAgSV9PMg0KMTAgIHNwYXJlMyAgICAgICAgICAg ICAgICAgICBJX08xDQoxMSAgaXJxN19iICAgICAgICAgICAgICAgICAgIElfTzENCjEyICBp cnExX2IgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTMgIGlycTBfYiAgICAgICAgICAgICAg ICAgICBJX08xDQoxNCAgZFswXSAgICAgICAgICAgICAgICAgICAgIElfTzENCjE1ICBkWzhd ICAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTYgIGRbMTJdICAgICAgICAgICAgICAgICAg ICBJX08xDQoxNyAgZFsxM10gICAgICAgICAgICAgICAgICAgIElfTzENCjE4ICBkWzRdICAg ICAgICAgICAgICAgICAgICAgSV9PMQ0KMTkgIGRbMTddICAgICAgICAgICAgICAgICAgICBJ X08xDQoyMCAgZFsyM10gICAgICAgICAgICAgICAgICAgIElfTzENCjIxICBkWzI3XSAgICAg ICAgICAgICAgICAgICAgSV9PMQ0KMjIgIGRbMV0gICAgICAgICAgICAgICAgICAgICBJX08x DQoyMyAgbmduZF9yICAgICAgICAgICAgICAgICAgIEdORA0KMjQgIG52Y2NfciAgICAgICAg ICAgICAgICAgICBQT1dFUg0KMjUgIGRbOV0gICAgICAgICAgICAgICAgICAgICBJX08xDQoy NiAgZFsxMF0gICAgICAgICAgICAgICAgICAgIElfTzENCjI3ICBkWzExXSAgICAgICAgICAg ICAgICAgICAgSV9PMQ0KMjggIGRbMl0gICAgICAgICAgICAgICAgICAgICBJX08xDQoyOSAg ZFszXSAgICAgICAgICAgICAgICAgICAgIElfTzENCjMwICBkWzE0XSAgICAgICAgICAgICAg ICAgICAgSV9PMQ0KMzEgIGRbMTVdICAgICAgICAgICAgICAgICAgICBJX08xDQozMiAgZFsx Nl0gICAgICAgICAgICAgICAgICAgIElfTzENCjMzICBkWzVdICAgICAgICAgICAgICAgICAg ICAgSV9PMQ0KMzQgIGRbMThdICAgICAgICAgICAgICAgICAgICBJX08xDQozNSAgdnNzICAg ICAgICAgICAgICAgICAgICAgIEdORA0KMzYgIHZkZCAgICAgICAgICAgICAgICAgICAgICBQ T1dFUg0KMzcgIGRbMTldICAgICAgICAgICAgICAgICAgICBJX08xDQozOCAgZFsyMF0gICAg ICAgICAgICAgICAgICAgIElfTzENCjM5ICBkWzIxXSAgICAgICAgICAgICAgICAgICAgSV9P MQ0KNDAgIGRbMjJdICAgICAgICAgICAgICAgICAgICBJX08xDQo0MSAgZFs2XSAgICAgICAg ICAgICAgICAgICAgIElfTzENCjQyICBkWzI0XSAgICAgICAgICAgICAgICAgICAgSV9PMQ0K NDMgIGRbMjVdICAgICAgICAgICAgICAgICAgICBJX08xDQo0NCAgZFsyNl0gICAgICAgICAg ICAgICAgICAgIElfTzENCjQ1ICBuZ25kX24gICAgICAgICAgICAgICAgICAgR05EDQo0NiAg bnZjY19uICAgICAgICAgICAgICAgICAgIFBPV0VSDQo0NyAgZFs3XSAgICAgICAgICAgICAg ICAgICAgIElfTzENCjQ4ICBkWzI4XSAgICAgICAgICAgICAgICAgICAgSV9PMQ0KNDkgIGRb MjldICAgICAgICAgICAgICAgICAgICBJX08xDQo1MCAgZFszMF0gICAgICAgICAgICAgICAg ICAgIElfTzENCjUxICBkWzMxXSAgICAgICAgICAgICAgICAgICAgSV9PMQ0KNTIgIGRwMV9p cnE0X2IgICAgICAgICAgICAgICBJX08xDQo1MyAgZHAyX2lycTVfYiAgICAgICAgICAgICAg IElfTzENCjU0ICBkcDNfaXJxNl9iICAgICAgICAgICAgICAgSV9PMQ0KNTUgIGRwMF9pcnEz X2IgICAgICAgICAgICAgICBJX08xDQo1NiAgbnZjY19sICAgICAgICAgICAgICAgICAgIFBP V0VSDQo1NyAgY2xrb3V0ICAgICAgICAgICAgICAgICAgIENMSw0KNTggIG5nbmRfbCAgICAg ICAgICAgICAgICAgICBHTkQNCjU5ICBpcGE2ICAgICAgICAgICAgICAgICAgICAgSV9PMQ0K NjAgIGlwYTUgICAgICAgICAgICAgICAgICAgICBJX08xDQo2MSAgaXBhNCAgICAgICAgICAg ICAgICAgICAgIElfTzENCjYyICBpcGEzICAgICAgICAgICAgICAgICAgICAgSV9PMQ0KNjMg IGlwYTJfaW9pczE2YV9iICAgICAgICAgICBJX08xDQo2NCAgaXBhMSAgICAgICAgICAgICAg ICAgICAgIElfTzENCjY1ICBpcGEwICAgICAgICAgICAgICAgICAgICAgSV9PMQ0KNjYgIGlw YTcgICAgICAgICAgICAgICAgICAgICBJX08xDQo2NyAgdmRkaCAgICAgICAgICAgICAgICAg ICAgIFBPV0VSDQo2OCAgdnNzc3luMSAgICAgICAgICAgICAgICAgIEdORA0KNjkgIHZzc3N5 biAgICAgICAgICAgICAgICAgICBHTkQNCjcwICB4ZmMgICAgICAgICAgICAgICAgICAgICAg SV9PMQ0KNzEgIHZkZHN5biAgICAgICAgICAgICAgICAgICBQT1dFUg0KNzIgIHdhaXRiX2Ig ICAgICAgICAgICAgICAgICBJX08xDQo3MyAgd2FpdGFfYiAgICAgICAgICAgICAgICAgIElf TzENCjc0ICBrYXB3ciAgICAgICAgICAgICAgICAgICAgSV9PMQ0KNzUgIHBvcmVzZXRfYiAg ICAgICAgICAgICAgICBJX08xDQo3NiAgcnN0Y29uZl9iICAgICAgICAgICAgICAgIElfTzEN Cjc3ICBzcmVzZXRfYiAgICAgICAgICAgICAgICAgSV9PMQ0KNzggIGhyZXNldF9iICAgICAg ICAgICAgICAgICBJX08xDQo3OSAgdGV4cCAgICAgICAgICAgICAgICAgICAgIElfTzENCjgw ICB4dGFsICAgICAgICAgICAgICAgICAgICAgSV9PMQ0KODEgIGV4dGFsICAgICAgICAgICAg ICAgICAgICBJX08xDQo4MiAgY2xrNGluICAgICAgICAgICAgICAgICAgIElfTzENCjgzICB2 c3MgICAgICAgICAgICAgICAgICAgICAgR05EDQo4NCAgdmRkICAgICAgICAgICAgICAgICAg ICAgIFBPV0VSDQo4NSAgZXh0X20xICAgICAgICAgICAgICAgICAgIElfTzENCjg2ICBleHRf bTIgICAgICAgICAgICAgICAgICAgSV9PMQ0KODcgIG9wM19tb2RjazJfZHNkbyAgICAgICAg ICBJX08xDQo4OCAgb3AyX21vZGNrMV9zdHNfYiAgICAgICAgIElfTzENCjg5ICBuZ25kX3cg ICAgICAgICAgICAgICAgICAgR05EDQo5MCAgbnZjY193ICAgICAgICAgICAgICAgICAgIFBP V0VSDQo5MSAgb3AxICAgICAgICAgICAgICAgICAgICAgIElfTzENCjkyICBvcDAgICAgICAg ICAgICAgICAgICAgICAgSV9PMQ0KOTMgIGV4dF9tMyAgICAgICAgICAgICAgICAgICBJX08x DQo5NCAgZXh0X200ICAgICAgICAgICAgICAgICAgIElfTzENCjk1ICBrcl9iX2lycTRfYiAg ICAgICAgICAgICAgSV9PMQ0KOTYgIGFsZWEgICAgICAgICAgICAgICAgICAgICBJX08xDQo5 NyAgaXBiNl9kc2RpX2F0MCAgICAgICAgICAgIElfTzENCjk4ICBhbGViX2RzY2tfYXQxICAg ICAgICAgICAgSV9PMQ0KOTkgIGlwYjJfaW9pczE2Yl9iX2F0MiAgICAgICBJX08xDQoxMDAg aXBiN19wdHJfYXQzICAgICAgICAgICAgIElfTzENCjEwMSBuZ25kX2sgICAgICAgICAgICAg ICAgICAgR05EDQoxMDIgbnZjY19rICAgICAgICAgICAgICAgICAgIFBPV0VSDQoxMDMgaXBi MF9pd3AwX3ZmbHMwICAgICAgICAgIElfTzENCjEwNCBpcGIxX2l3cDFfdmZsczEgICAgICAg ICAgSV9PMQ0KMTA1IGlwYjNfbHdwMl92ZjIgICAgICAgICAgICBJX08xDQoxMDYgaXBiNF9s d3AwX3ZmMCAgICAgICAgICAgIElfTzENCjEwNyBpcGI1X2x3cDFfdmYxICAgICAgICAgICAg SV9PMQ0KMTA4IHJzdl9iX2lycTJfYiAgICAgICAgICAgICBJX08xDQoxMDkgYnVyc3RfYiAg ICAgICAgICAgICAgICAgIElfTzENCjExMCBjcl9iX2lycTNfYiAgICAgICAgICAgICAgSV9P MQ0KMTExIGZyel9iX2lycTZfYiAgICAgICAgICAgICBJX08xDQoxMTIgc3BhcmU0ICAgICAg ICAgICAgICAgICAgIElfTzENCjExMyBiYl9iICAgICAgICAgICAgICAgICAgICAgQUNQVQ0K MTE0IGJnX2IgICAgICAgICAgICAgICAgICAgICBJX08xDQoxMTUgYnJfYiAgICAgICAgICAg ICAgICAgICAgIElfTzENCjExNiBuZ25kX2MgICAgICAgICAgICAgICAgICAgR05EDQoxMTcg bnZjY19jICAgICAgICAgICAgICAgICAgIFBPV0VSDQoxMTggdHNfYiAgICAgICAgICAgICAg ICAgICAgIEFDUFUNCjExOSB0ZWFfYiAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTIwIHRh X2IgICAgICAgICAgICAgICAgICAgICBBQ1BVDQoxMjEgYmlfYiAgICAgICAgICAgICAgICAg ICAgIEFDUFUNCjEyMiBiZGlwX2JfZ3BsYjVfYiAgICAgICAgICAgSV9PMQ0KMTIzIGdwbGE0 X2IgICAgICAgICAgICAgICAgICBJX08xDQoxMjQgbmduZF9tICAgICAgICAgICAgICAgICAg IEdORA0KMTI1IG52Y2NfbSAgICAgICAgICAgICAgICAgICBQT1dFUg0KMTI2IGdwbGE1X2Ig ICAgICAgICAgICAgICAgICBJX08xDQoxMjcgZ3BsYjRfYiAgICAgICAgICAgICAgICAgIElf TzENCjEyOCB3cl9iICAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTI5IGNzMF9iICAgICAg ICAgICAgICAgICAgICBJX08xDQoxMzAgY3MxX2IgICAgICAgICAgICAgICAgICAgIElfTzEN CjEzMSBjczJfYiAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTMyIGNzM19iICAgICAgICAg ICAgICAgICAgICBJX08xDQoxMzMgbnZjY19kICAgICAgICAgICAgICAgICAgIFBPV0VSDQox MzQgbmduZF9kICAgICAgICAgICAgICAgICAgIEdORA0KMTM1IGNlMWFfYiAgICAgICAgICAg ICAgICAgICBJX08xDQoxMzYgY2UyYV9iICAgICAgICAgICAgICAgICAgIElfTzENCjEzNyBj czdfYl9jZTJiX2IgICAgICAgICAgICAgSV9PMQ0KMTM4IGNzNl9jZTFiX2IgICAgICAgICAg ICAgICBJX08xDQoxMzkgY3M1X2IgICAgICAgICAgICAgICAgICAgIElfTzENCjE0MCBjczRf YiAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTQxIGdwbGFiM19iX2NzM19iICAgICAgICAg ICBJX08xDQoxNDIgZ3BsYWIyX2JfY3MyX2IgICAgICAgICAgIElfTzENCjE0MyBuZ25kX3kg ICAgICAgICAgICAgICAgICAgR05EDQoxNDQgbnZjY195ICAgICAgICAgICAgICAgICAgIFBP V0VSDQoxNDUgb2VfYl9ncGxhYjFfYiAgICAgICAgICAgIElfTzENCjE0NiBncGxhMF9iX2dw bGIwX2IgICAgICAgICAgSV9PMQ0KMTQ3IHdlM19iX2JzYjNfYl9wY3dlX2IgICAgICBJX08x DQoxNDggd2UyX2JfYnNiMl9iX3Bjb2VfYiAgICAgIElfTzENCjE0OSBuZ25kX2YgICAgICAg ICAgICAgICAgICAgR05EDQoxNTAgbnZjY19mICAgICAgICAgICAgICAgICAgIFBPV0VSDQox NTEgd2UxX2JfYnNiMV9iX2lvd3JfYiAgICAgIElfTzENCjE1MiB3ZTBfYl9ic2IwX2JfaW9y ZF9iICAgICAgSV9PMQ0KMTUzIHNwYXJlMSAgICAgICAgICAgICAgICAgICBJX08xDQoxNTQg YnNhMF9iICAgICAgICAgICAgICAgICAgIElfTzENCjE1NSBic2ExX2IgICAgICAgICAgICAg ICAgICAgSV9PMQ0KMTU2IG5nbmRfbyAgICAgICAgICAgICAgICAgICBHTkQNCjE1NyBudmNj X28gICAgICAgICAgICAgICAgICAgUE9XRVINCjE1OCBic2EyX2IgICAgICAgICAgICAgICAg ICAgSV9PMQ0KMTU5IGJzYTNfYiAgICAgICAgICAgICAgICAgICBJX08xDQoxNjAgdmRkICAg ICAgICAgICAgICAgICAgICAgIFBPV0VSDQoxNjEgdnNzICAgICAgICAgICAgICAgICAgICAg IEdORA0KMTYyIHRzaXoxICAgICAgICAgICAgICAgICAgICBJX08xDQoxNjMgdHNpejBfcmVn X2IgICAgICAgICAgICAgIElfTzENCjE2NCBhWzMxXSAgICAgICAgICAgICAgICAgICAgSV9P MQ0KMTY1IGFbMjZdICAgICAgICAgICAgICAgICAgICBJX08xDQoxNjYgYVsyMl0gICAgICAg ICAgICAgICAgICAgIElfTzENCjE2NyBhWzI4XSAgICAgICAgICAgICAgICAgICAgSV9PMQ0K MTY4IGFbMThdICAgICAgICAgICAgICAgICAgICBJX08xDQoxNjkgYVszMF0gICAgICAgICAg ICAgICAgICAgIElfTzENCjE3MCBhWzI1XSAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTcx IG5nbmRfcyAgICAgICAgICAgICAgICAgICBHTkQNCjE3MiBudmNjX3MgICAgICAgICAgICAg ICAgICAgUE9XRVINCjE3MyBhWzI0XSAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTc0IGFb MjNdICAgICAgICAgICAgICAgICAgICBJX08xDQoxNzUgYVsyOV0gICAgICAgICAgICAgICAg ICAgIElfTzENCjE3NiBhWzIxXSAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTc3IGFbMjBd ICAgICAgICAgICAgICAgICAgICBJX08xDQoxNzggYVsxOV0gICAgICAgICAgICAgICAgICAg IElfTzENCjE3OSBhWzI3XSAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTgwIGFbMTddICAg ICAgICAgICAgICAgICAgICBJX08xDQoxODEgYVsxNl0gICAgICAgICAgICAgICAgICAgIElf TzENCjE4MiBhWzE1XSAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTgzIGFbMTRdICAgICAg ICAgICAgICAgICAgICBJX08xDQoxODQgYVsxM10gICAgICAgICAgICAgICAgICAgIElfTzEN CjE4NSBhWzEyXSAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTg2IGFbMTFdICAgICAgICAg ICAgICAgICAgICBJX08xDQoxODcgYVsxMF0gICAgICAgICAgICAgICAgICAgIElfTzENCjE4 OCBhWzldICAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTg5IG5nbmRfZSAgICAgICAgICAg ICAgICAgICBHTkQNCjE5MCBudmNjX2UgICAgICAgICAgICAgICAgICAgUE9XRVINCjE5MSBh WzhdICAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTkyIGFbN10gICAgICAgICAgICAgICAg ICAgICBJX08xDQoxOTMgYVs2XSAgICAgICAgICAgICAgICAgICAgIElfTzENCjE5NCBhWzVd ICAgICAgICAgICAgICAgICAgICAgSV9PMQ0KMTk1IGFbNF0gICAgICAgICAgICAgICAgICAg ICBJX08xDQoxOTYgYVszXSAgICAgICAgICAgICAgICAgICAgIElfTzENCjE5NyBhWzJdICAg ICAgICAgICAgICAgICAgICAgSV9PMQ0KMTk4IGFbMV0gICAgICAgICAgICAgICAgICAgICBJ X08xDQoxOTkgYVswXSAgICAgICAgICAgICAgICAgICAgIElfTzENCjIwMCB2ZGRoICAgICAg ICAgICAgICAgICAgICAgUE9XRVINCjIwMSBwYlszMV0gICAgICAgICAgICAgICAgICAgSV9P Mg0KMjAyIHBhWzE1XSAgICAgICAgICAgICAgICAgICBJX08yDQoyMDMgcGJbMzBdICAgICAg ICAgICAgICAgICAgIElfTzINCjIwNCBwY1sxNV0gICAgICAgICAgICAgICAgICAgSV9PMg0K MjA1IHBiWzI5XSAgICAgICAgICAgICAgICAgICBJX08yDQoyMDYgcGFbMTRdICAgICAgICAg ICAgICAgICAgIElfTzINCjIwNyBwY1sxNF0gICAgICAgICAgICAgICAgICAgSV9PMg0KMjA4 IHBiWzI4XSAgICAgICAgICAgICAgICAgICBJX08yDQoyMDkgbmduZF92ICAgICAgICAgICAg ICAgICAgIEdORA0KMjEwIG52Y2NfdiAgICAgICAgICAgICAgICAgICBQT1dFUg0KMjExIHBh WzEzXSAgICAgICAgICAgICAgICAgICBJX08yDQoyMTIgcGNbMTNdICAgICAgICAgICAgICAg ICAgIElfTzINCjIxMyBwYlsyN10gICAgICAgICAgICAgICAgICAgSV9PMg0KMjE0IHBhWzEy XSAgICAgICAgICAgICAgICAgICBJX08yDQoyMTUgcGNbMTJdICAgICAgICAgICAgICAgICAg IElfTzINCjIxNiBwYlsyNl0gICAgICAgICAgICAgICAgICAgSV9PMg0KMjE3IHBhWzExXSAg ICAgICAgICAgICAgICAgICBJX08yDQoyMTggdGRvX2RzZG8gICAgICAgICAgICAgICAgIElf TzINCjIxOSB0bXMgICAgICAgICAgICAgICAgICAgICAgSV9PMg0KMjIwIHRyc3RfYiAgICAg ICAgICAgICAgICAgICBJX08yDQoyMjEgdGNrX2RzY2sgICAgICAgICAgICAgICAgIElfTzIN CjIyMiB0ZGlfZHNkaSAgICAgICAgICAgICAgICAgSV9PMg0KMjIzIHZzcyAgICAgICAgICAg ICAgICAgICAgICBHTkQNCjIyNCB2ZGQgICAgICAgICAgICAgICAgICAgICAgUE9XRVINCjIy NSBzcGFyZTIgICAgICAgICAgICAgICAgICAgSV9PMg0KMjI2IHBiWzI1XSAgICAgICAgICAg ICAgICAgICBJX08yDQoyMjcgcGFbMTBdICAgICAgICAgICAgICAgICAgIElfTzINCjIyOCBw YlsyNF0gICAgICAgICAgICAgICAgICAgSV9PMg0KMjI5IHBjWzExXSAgICAgICAgICAgICAg ICAgICBJX08yDQoyMzAgcGJbMjNdICAgICAgICAgICAgICAgICAgIElfTzINCjIzMSBwYVs5 XSAgICAgICAgICAgICAgICAgICAgSV9PMg0KMjMyIHBjWzEwXSAgICAgICAgICAgICAgICAg ICBJX08yDQoyMzMgbmduZF9hICAgICAgICAgICAgICAgICAgIEdORA0KMjM0IG52Y2NfYSAg ICAgICAgICAgICAgICAgICBQT1dFUg0KMjM1IHBiWzIyXSAgICAgICAgICAgICAgICAgICBJ X08yDQoyMzYgcGFbOF0gICAgICAgICAgICAgICAgICAgIElfTzINCjIzNyBwY1s5XSAgICAg ICAgICAgICAgICAgICAgSV9PMg0KMjM4IHBiWzIxXSAgICAgICAgICAgICAgICAgICBJX08y DQoyMzkgcGFbN10gICAgICAgICAgICAgICAgICAgIElfTzINCjI0MCBwY1s4XSAgICAgICAg ICAgICAgICAgICAgSV9PMg0KMjQxIHBiWzIwXSAgICAgICAgICAgICAgICAgICBJX08yDQoy NDIgcGFbNl0gICAgICAgICAgICAgICAgICAgIElfTzINCjI0MyBwYlsxOV0gICAgICAgICAg ICAgICAgICAgSV9PMg0KMjQ0IHBhWzVdICAgICAgICAgICAgICAgICAgICBJX08yDQoyNDUg cGJbMThdICAgICAgICAgICAgICAgICAgIElfTzINCjI0NiBwYVs0XSAgICAgICAgICAgICAg ICAgICAgSV9PMg0KMjQ3IHBjWzddICAgICAgICAgICAgICAgICAgICBJX08yDQoyNDggcGJb MTddICAgICAgICAgICAgICAgICAgIElfTzINCjI0OSBwYVszXSAgICAgICAgICAgICAgICAg ICAgSV9PMg0KMjUwIHBjWzZdICAgICAgICAgICAgICAgICAgICBJX08yDQoyNTEgbmduZF9i ICAgICAgICAgICAgICAgICAgIEdORA0KMjUyIG52Y2NfYiAgICAgICAgICAgICAgICAgICBQ T1dFUg0KMjUzIHBiWzE2XSAgICAgICAgICAgICAgICAgICBJX08yDQoyNTQgcGFbMl0gICAg ICAgICAgICAgICAgICAgIElfTzINCjI1NSBwY1s1XSAgICAgICAgICAgICAgICAgICAgSV9P Mg0KMjU2IHBiWzE1XSAgICAgICAgICAgICAgICAgICBJX08yDQoyNTcgcGFbMV0gICAgICAg ICAgICAgICAgICAgIElfTzINCjI1OCBwY1s0XSAgICAgICAgICAgICAgICAgICAgSV9PMg0K MjU5IHBiWzE0XSAgICAgICAgICAgICAgICAgICBJX08yDQoyNjAgcGFbMF0gICAgICAgICAg ICAgICAgICAgIElfTzINCjI2MSBsZDggICAgICAgICAgICAgICAgICAgICAgSV9PMg0KMjYy IGxkNyAgICAgICAgICAgICAgICAgICAgICBJX08yDQoyNjMgbGQ2ICAgICAgICAgICAgICAg ICAgICAgIElfTzINCjI2NCBsZDUgICAgICAgICAgICAgICAgICAgICAgSV9PMg0KMjY1IGxk NCAgICAgICAgICAgICAgICAgICAgICBJX08yDQoyNjYgbnZjY19wICAgICAgICAgICAgICAg ICAgIFBPV0VSDQoNCnwqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCnwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBNb2RlbCBJX08xDQp8KioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQp8DQpbTW9kZWxd ICAgICAgIElfTzENCk1vZGVsX3R5cGUgICAgMy1zdGF0ZQ0KUG9sYXJpdHkgTm9uLUludmVy dGluZw0KQ19jb21wICAgMCAgIDAgICAwDQpbVm9sdGFnZSByYW5nZV0gICAgMy4zdiAgICAg IDMuMHYgICAgICAzLjZ2DQpbUHVsbGRvd25dDQotNSAgICAgICAgICAgICAgLTkuMjUwOTEg ICAgICAgIC05LjQwOTc2ICAgICAgICAtOS4xMzc1OQ0KLTQgICAgICAgICAgICAgIC02Ljk5 OTY3ICAgICAgICAtNy4xNzA0MyAgICAgICAgLTYuODc1NjcNCi0zICAgICAgICAgICAgICAt NC43NTQwMiAgICAgICAgLTQuOTM3MTMgICAgICAgIC00LjYxODgzDQotMiAgICAgICAgICAg ICAgLTIuNTI1MTUgICAgICAgIC0yLjcyMjA0ICAgICAgICAtMi4zNzcyNg0KLTEgICAgICAg ICAgICAgIC0wLjM4NzkyMSAgICAgICAtMC41ODY4NTEgICAgICAgLTAuMjQ3NTIyDQowICAg ICAgICAgICAgICAgMC4wMDA2MzkzMTYgICAgIDAuMDAwODE3MDk2ICAgICAwLjAwMDUwMDc0 MQ0KMSAgICAgICAgICAgICAgIDAuMDU4MjA3NSAgICAgICAwLjAzODg1MDcgICAgICAgMC4w ODQzMjY1DQoyICAgICAgICAgICAgICAgMC4xMDgxNzggICAgICAgIDAuMDcxNTYwOSAgICAg ICAwLjE1NzEzDQozICAgICAgICAgICAgICAgMC4xNDY2OTggICAgICAgIDAuMDk2NzE1ICAg ICAgICAwLjIxMjg4OQ0KNCAgICAgICAgICAgICAgIDAuMTcyOTA2ICAgICAgICAwLjExNjEz MyAgICAgICAgMC4yNDg3NA0KNSAgICAgICAgICAgICAgIDAuMjA1Njk5ICAgICAgICAwLjEz NjgyNCAgICAgICAgMC4yODk5ODkNCjYgICAgICAgICAgICAgICAwLjIzODc1MSAgICAgICAg MC4xNTYxMzkgICAgICAgIDAuMzQ2OTQxDQo3ICAgICAgICAgICAgICAgMC4yNzA4MDkgICAg ICAgIDAuMTcyNTM5ICAgICAgICAwLjQwMDQ1MQ0KOCAgICAgICAgICAgICAgIDAuMzAwNzUg ICAgICAgICAwLjE4NTY2NCAgICAgICAgMC40NTQ5MzQNCjkgICAgICAgICAgICAgICAwLjMy NzkxNCAgICAgICAgMC4xOTU2NjUgICAgICAgIDAuNTA5OTQyDQoxMCAgICAgICAgICAgICAg MC4zNDcwMTEgICAgICAgIDAuMTgyNjQxICAgICAgICAwLjU2MzUzNA0KW1B1bGx1cF0NCi0x MCAgICAgICAgICAgICAgMTMuMTc1MSAgICAgICAgIDEzLjk0MyAgICAgICAgICAxMi40ODE5 DQotOSAgICAgICAgICAgICAgIDEwLjkxNyAgICAgICAgICAxMS42OTc2ICAgICAgICAgMTAu MjENCi04ICAgICAgICAgICAgICAgOC42NTkzMyAgICAgICAgIDkuNDUzNjYgICAgICAgICA3 LjkzNzM4DQotNyAgICAgICAgICAgICAgIDYuNDAzODIgICAgICAgICA3LjIxMTM3ICAgICAg ICAgNS42NzE3Mw0KLTYgICAgICAgICAgICAgICA0LjE1ODA5ICAgICAgICAgNC45NzU3MiAg ICAgICAgIDMuNDE3NTYNCi01ICAgICAgICAgICAgICAgMS45MzY2MSAgICAgICAgIDIuNzU5 ODEgICAgICAgICAxLjE5NzkyDQotNCAgICAgICAgICAgICAgIDAuMDgzMDM2NiAgICAgICAw LjYyNzg5OCAgICAgICAgMC4xMzQ2OTYNCi0zICAgICAgICAgICAgICAgMC4wNjY2OTg5ICAg ICAgIDAuMDMzNDU2NyAgICAgICAwLjEyNzA3OA0KLTIgICAgICAgICAgICAgICAwLjA2MTEy NzMgICAgICAgMC4wMzE2NjUzICAgICAgIDAuMTEwNTkxDQotMSAgICAgICAgICAgICAgIDAu MDQwODY3NSAgICAgICAwLjAyMzE0NzQgICAgICAgMC4wNjg0NjQxDQowICAgICAgICAgICAg ICAgLTAuMDAxMTQ2NzkgICAgIC0wLjAwMTE1NDcgICAgICAtMC4wMDEyMTU1Mw0KMSAgICAg ICAgICAgICAgIC0wLjA1NzAxMTMgICAgICAtMC4wMzczNjM1ICAgICAgLTAuMDg0NzUxNQ0K MiAgICAgICAgICAgICAgIC0wLjExNzc0NCAgICAgICAtMC4wNzc5ODYzICAgICAgLTAuMTcy Mjg4DQozICAgICAgICAgICAgICAgLTAuMTczNjY4ICAgICAgIC0wLjExNTc0OCAgICAgICAt MC4yNTA2ODMNCjQgICAgICAgICAgICAgICAtMC4yMTA4NjYgICAgICAgLTAuMTM4OTc3ICAg ICAgIC0wLjMwNDQxNQ0KNSAgICAgICAgICAgICAgIC0wLjE1MDMxNSAgICAgICAtMC4wNzYx ODg3ICAgICAgLTAuMjY0NTA2DQpbR05EX2NsYW1wXQ0KMC4wdiAgICAgICAgICAgICAwLjBt ICBOQSAgICAgIE5BDQotMC41diAgICAgICAgICAgLTEwLjBtICBOQSAgICAgIE5BDQotMC43 diAgICAgICAgICAgLTIwLjBtICBOQSAgICAgIE5BDQotNS4wdiAgICAgICAgICAtNDAwLjBt ICBOQSAgICAgIE5BDQpbUE9XRVJfY2xhbXBdDQogMC4wdiAgICAgICAgICAgICAwLjBtICBO QSAgICAgIE5BDQotMC41diAgICAgICAgICAgIDEwLjBtICBOQSAgICAgIE5BDQotMC43diAg ICAgICAgICAgIDIwLjBtICBOQSAgICAgIE5BDQotNS4wdiAgICAgICAgICAgNDAwLjBtICBO QSAgICAgIE5BDQoNCltSYW1wXQ0KZFYvZHRfciAgICAgICAgIDEuOC8xbiAgIDEuNS8xLjZu ICAgICAgICAgMi4xLzAuODNuDQpkVi9kdF9mICAgICAgMi4yNS8xLjNuICAgMS42LzEuM24g ICAgICAgICAyLzAuNDNuDQpbUmlzaW5nIFdhdmVmb3JtXQ0KUl9maXh0dXJlPTUwMA0KVl9m aXh0dXJlPTMuMw0KVl9maXh0dXJlX21pbj0zLjANClZfZml4dHVyZV9tYXg9My42DQpDX2Zp eHR1cmU9NTBwDQpMX2ZpeHR1cmU9MTBuDQoxRS0wOSAgICAgICAgICAgICAgIDIuMzU2OTJF LTA4ICAgICAgICAgNy4zMDk3NUUtMDggICAgICAgICAtNi4zMDMzMkUtMDcNCjEuNUUtMDkg ICAgICAgICAgICAgLTIuNTA1NTJFLTA2ICAgICAgICAxLjg2NDMxRS0wNyAgICAgICAgIC0y LjIwMTY4RS0wNg0KMkUtMDkgICAgICAgICAgICAgICAtMi4zNDk5OUUtMDYgICAgICAgIC0z LjE3Njg0RS0wNiAgICAgICAgMy4xNTIxOUUtMDcNCjIuNUUtMDkgICAgICAgICAgICAgMi4w NDEzN0UtMDUgICAgICAgICAtMi45NzEwOUUtMDYgICAgICAgIDAuMDE1MTIwOA0KM0UtMDkg ICAgICAgICAgICAgICAtMC4wMDM5ODc4NyAgICAgICAgIDEuNTg4NDVFLTA1ICAgICAgICAg MC41NjYyOTUNCjMuNUUtMDkgICAgICAgICAgICAgMC4wNjQ2MTAyICAgICAgICAgICAxLjMx OTA0RS0wNSAgICAgICAgIDEuNzQ2MTkNCjRFLTA5ICAgICAgICAgICAgICAgMC40NjQ1MzQg ICAgICAgICAgICAtMC4wMDQxMTA3OSAgICAgICAgIDIuODQwNzcNCjQuNUUtMDkgICAgICAg ICAgICAgMS4wNjc0NSAgICAgICAgICAgICAtMC4wMDM2MTI0OCAgICAgICAgIDMuNTU4MzIN CjVFLTA5ICAgICAgICAgICAgICAgMS42MzMzOSAgICAgICAgICAgICAwLjA1ODg2MzQgICAg ICAgICAgIDMuOTE0NDINCjUuNUUtMDkgICAgICAgICAgICAgMi4xMjU4ICAgICAgICAgICAg ICAwLjIyNzcyMyAgICAgICAgICAgIDMuOTQzNQ0KNkUtMDkgICAgICAgICAgICAgICAyLjU0 NDQ0ICAgICAgICAgICAgIDAuNDU5NzkxICAgICAgICAgICAgMy44MDY0MQ0KNi41RS0wOSAg ICAgICAgICAgICAyLjg1NzY5ICAgICAgICAgICAgIDAuNzE3Mzk5ICAgICAgICAgICAgMy42 MjU2DQo3RS0wOSAgICAgICAgICAgICAgIDMuMDcyNTcgICAgICAgICAgICAgMC45OTI2NDUg ICAgICAgICAgICAzLjQ3MzE5DQo3LjVFLTA5ICAgICAgICAgICAgIDMuMTc1MzIgICAgICAg ICAgICAgMS4yNjk2OSAgICAgICAgICAgICAzLjQwNzg1DQo4RS0wOSAgICAgICAgICAgICAg IDMuMjI0NTkgICAgICAgICAgICAgMS41MzMxNiAgICAgICAgICAgICAzLjQxMTY0DQo4LjVF LTA5ICAgICAgICAgICAgIDMuMjI5NzMgICAgICAgICAgICAgMS43ODI0NCAgICAgICAgICAg ICAzLjQ1ODI5DQo5RS0wOSAgICAgICAgICAgICAgIDMuMjE5NDQgICAgICAgICAgICAgMi4w MTAzOCAgICAgICAgICAgICAzLjUwOTYxDQo5LjVFLTA5ICAgICAgICAgICAgIDMuMjA1ODMg ICAgICAgICAgICAgMi4yMDkzOSAgICAgICAgICAgICAzLjU0Mzg1DQoxLjBFLTA4ICAgICAg ICAgICAgICAgMy4xOTcyMyAgICAgICAgICAgICAyLjM3NSAgICAgICAgICAgICAgIDMuNTU0 MjQNCjEuMDVFLTA4ICAgICAgICAgICAgMy4xOTE3MSAgICAgICAgICAgICAyLjUwODczICAg ICAgICAgICAgIDMuNTUyNTINCjEuMUUtMDggICAgICAgICAgICAgMy4xOTA5MyAgICAgICAg ICAgICAyLjYwNjM4ICAgICAgICAgICAgIDMuNTQwNzQNCjEuMTVFLTA4ICAgICAgICAgICAg My4xOTIxICAgICAgICAgICAgICAyLjY4MyAgICAgICAgICAgICAgIDMuNTI3MTYNCjEuMkUt MDggICAgICAgICAgICAgMy4xOTM5NCAgICAgICAgICAgICAyLjczNTA5ICAgICAgICAgICAg IDMuNTIwMjkNCjEuMjVFLTA4ICAgICAgICAgICAgMy4xOTUzICAgICAgICAgICAgICAyLjc3 Mzg3ICAgICAgICAgICAgIDMuNTE0MTQNCjEuM0UtMDggICAgICAgICAgICAgMy4xOTY1OSAg ICAgICAgICAgICAyLjgwMDIxICAgICAgICAgICAgIDMuNTE1NzINCjEuMzVFLTA4ICAgICAg ICAgICAgMy4xOTY3NCAgICAgICAgICAgICAyLjgxNjIyICAgICAgICAgICAgIDMuNTE5Mw0K MS40RS0wOCAgICAgICAgICAgICAzLjE5NjgyICAgICAgICAgICAgIDIuODI4OTUgICAgICAg ICAgICAgMy41MjM4OQ0KMS40NUUtMDggICAgICAgICAgICAzLjE5NjQ5ICAgICAgICAgICAg IDIuODM1MjMgICAgICAgICAgICAgMy41MjY0Nw0KMS41RS0wOCAgICAgICAgICAgICAzLjE5 NjI2ICAgICAgICAgICAgIDIuODM5NiAgICAgICAgICAgICAgMy41MjcyDQoxLjU1RS0wOCAg ICAgICAgICAgIDMuMTk2MTIgICAgICAgICAgICAgMi44NDI4MSAgICAgICAgICAgICAzLjUy Njg5DQoxLjZFLTA4ICAgICAgICAgICAgIDMuMTk2MSAgICAgICAgICAgICAgMi44NDUxNSAg ICAgICAgICAgICAzLjUyNjAzDQoxLjY1RS0wOCAgICAgICAgICAgIDMuMTk2MDkgICAgICAg ICAgICAgMi44NDY3MyAgICAgICAgICAgICAzLjUyNTI2DQoxLjdFLTA4ICAgICAgICAgICAg IDMuMTk2MSAgICAgICAgICAgICAgMi44NDc5MyAgICAgICAgICAgICAzLjUyNDcNCjEuNzVF LTA4ICAgICAgICAgICAgMy4xOTYxMSAgICAgICAgICAgICAyLjg0OTEyICAgICAgICAgICAg IDMuNTI0MTMNCjEuOEUtMDggICAgICAgICAgICAgMy4xOTYxMyAgICAgICAgICAgICAyLjg0 OTYzICAgICAgICAgICAgIDMuNTIzODQNCjEuODVFLTA4ICAgICAgICAgICAgMy4xOTYxNCAg ICAgICAgICAgICAyLjg1MDA3ICAgICAgICAgICAgIDMuNTI0MDcNCjEuOUUtMDggICAgICAg ICAgICAgMy4xOTYxNSAgICAgICAgICAgICAyLjg1MDUxICAgICAgICAgICAgIDMuNTI0MzEN CjEuOTVFLTA4ICAgICAgICAgICAgMy4xOTYxNiAgICAgICAgICAgICAyLjg1MDgzICAgICAg ICAgICAgIDMuNTI0NTINCjJFLTA4ICAgICAgICAgICAgICAgMy4xOTYxNyAgICAgICAgICAg ICAyLjg1MDk5ICAgICAgICAgICAgIDMuNTI0NjINCjIuMDVFLTA4ICAgICAgICAgICAgMy4x OTYxNyAgICAgICAgICAgICAyLjg1MTE2ICAgICAgICAgICAgIDMuNTI0NzINCjIuMUUtMDgg ICAgICAgICAgICAgMy4xOTYxOCAgICAgICAgICAgICAyLjg1MTMyICAgICAgICAgICAgIDMu NTI0ODINCltGYWxsaW5nIFdhdmVmb3JtXQ0KUl9maXh0dXJlPTUwMA0KVl9maXh0dXJlPTAN ClZfZml4dHVyZV9taW49MC4wDQpWX2ZpeHR1cmVfbWF4PTAuMA0KQ19maXh0dXJlPTUwcA0K TF9maXh0dXJlPTEwbg0KMUUtMDkgICAgICAgICAgICAgICAzLjMgICAgICAgICAgICAgICAg IDMgICAgICAgICAgICAgICAgICAgMy41OTk5OQ0KMS41RS0wOSAgICAgICAgICAgICAzLjI5 OTk5ICAgICAgICAgICAgIDMgICAgICAgICAgICAgICAgICAgMy42MDAwMQ0KMkUtMDkgICAg ICAgICAgICAgICAzLjMgICAgICAgICAgICAgICAgIDIuOTk5OTkgICAgICAgICAgICAgMy41 OTk5Mw0KMi41RS0wOSAgICAgICAgICAgICAzLjI5OTcxICAgICAgICAgICAgIDMgICAgICAg ICAgICAgICAgICAgMy41OTQ1DQozRS0wOSAgICAgICAgICAgICAgIDMuMzAwMTUgICAgICAg ICAgICAgMy4wMDAwMSAgICAgICAgICAgICAzLjM0NjMyDQozLjVFLTA5ICAgICAgICAgICAg IDMuMjgwNSAgICAgICAgICAgICAgMi45OTk5MyAgICAgICAgICAgICAyLjg0MDgxDQo0RS0w OSAgICAgICAgICAgICAgIDMuMTQ5MDIgICAgICAgICAgICAgMy4wMDAwMyAgICAgICAgICAg ICAyLjIyMzkNCjQuNUUtMDkgICAgICAgICAgICAgMi45MTE2MSAgICAgICAgICAgICAyLjk5 OTc1ICAgICAgICAgICAgIDEuNjA3MzcNCjVFLTA5ICAgICAgICAgICAgICAgMi42MDQ3MiAg ICAgICAgICAgICAyLjk5MDkyICAgICAgICAgICAgIDEuMDYwMTUNCjUuNUUtMDkgICAgICAg ICAgICAgMi4yNTU1NiAgICAgICAgICAgICAyLjk0NjQ2ICAgICAgICAgICAgIDAuNjQ2MDQy DQo2RS0wOSAgICAgICAgICAgICAgIDEuOTEyOTYgICAgICAgICAgICAgMi44Njk0OSAgICAg ICAgICAgICAwLjM1NDI0OA0KNi41RS0wOSAgICAgICAgICAgICAxLjU3MzMyICAgICAgICAg ICAgIDIuNzU4OTYgICAgICAgICAgICAgMC4xODIwOTgNCjdFLTA5ICAgICAgICAgICAgICAg MS4yNTM4NCAgICAgICAgICAgICAyLjYxNTk0ICAgICAgICAgICAgIDAuMTA0NjU4DQo3LjVF LTA5ICAgICAgICAgICAgIDAuOTgyNjMgICAgICAgICAgICAgMi40NTUwMiAgICAgICAgICAg ICAwLjA4Njk2NTMNCjhFLTA5ICAgICAgICAgICAgICAgMC43NTMzNjEgICAgICAgICAgICAy LjI4MDI2ICAgICAgICAgICAgIDAuMDkzODU3NQ0KOC41RS0wOSAgICAgICAgICAgICAwLjU4 MzA4NiAgICAgICAgICAgIDIuMDk2NjEgICAgICAgICAgICAgMC4xMDcyMTYNCjlFLTA5ICAg ICAgICAgICAgICAgMC40NDk0OTMgICAgICAgICAgICAxLjkxMTUxICAgICAgICAgICAgIDAu MTE4MTcNCjkuNUUtMDkgICAgICAgICAgICAgMC4zNTU5MjEgICAgICAgICAgICAxLjczMDky ICAgICAgICAgICAgIDAuMTI0MDg2DQoxRS0wOCAgICAgICAgICAgICAgIDAuMjk0MDcgICAg ICAgICAgICAgMS41NjIxMyAgICAgICAgICAgICAwLjEyNjU0Mw0KMS4wNUUtMDggICAgICAg ICAgICAwLjI0NjM5NiAgICAgICAgICAgIDEuMzkzNjQgICAgICAgICAgICAgMC4xMjY1MjUN CjEuMUUtMDggICAgICAgICAgICAgMC4yMTc5NTkgICAgICAgICAgICAxLjIzMDc0ICAgICAg ICAgICAgIDAuMTI2NTA2DQoxLjE1RS0wOCAgICAgICAgICAgIDAuMTk5MDc2ICAgICAgICAg ICAgMS4wODUyICAgICAgICAgICAgICAwLjEyNTYxOQ0KMS4yRS0wOCAgICAgICAgICAgICAw LjE4NTU3OCAgICAgICAgICAgIDAuOTUyNTE4ICAgICAgICAgICAgMC4xMjQ3MTUNCjEuMjVF LTA4ICAgICAgICAgICAgMC4xNzkxNjIgICAgICAgICAgICAwLjgzMzA2ICAgICAgICAgICAg IDAuMTI0NDU1DQoxLjNFLTA4ICAgICAgICAgICAgIDAuMTczOTI5ICAgICAgICAgICAgMC43 MzA2OCAgICAgICAgICAgICAwLjEyNDIwMw0KMS4zNUUtMDggICAgICAgICAgICAwLjE3MTE5 OCAgICAgICAgICAgIDAuNjQzNzkyICAgICAgICAgICAgMC4xMjQyOTMNCjEuNEUtMDggICAg ICAgICAgICAgMC4xNjk1MDIgICAgICAgICAgICAwLjU2NzY3NSAgICAgICAgICAgIDAuMTI0 Mzg1DQoxLjQ1RS0wOCAgICAgICAgICAgIDAuMTY4NTY3ICAgICAgICAgICAgMC41MDU3NDEg ICAgICAgICAgICAwLjEyNDQ2Ng0KMS41RS0wOCAgICAgICAgICAgICAwLjE2Nzk1ICAgICAg ICAgICAgIDAuNDU0MTQ4ICAgICAgICAgICAgMC4xMjQ1MjENCjEuNTVFLTA4ICAgICAgICAg ICAgMC4xNjc1MyAgICAgICAgICAgICAwLjQxMjc4MyAgICAgICAgICAgIDAuMTI0NTUyDQox LjZFLTA4ICAgICAgICAgICAgIDAuMTY3MzEzICAgICAgICAgICAgMC4zNzc4MjkgICAgICAg ICAgICAwLjEyNDU2DQoxLjY1RS0wOCAgICAgICAgICAgIDAuMTY3MTMzICAgICAgICAgICAg MC4zNTIwNzcgICAgICAgICAgICAwLjEyNDU2NQ0KMS43RS0wOCAgICAgICAgICAgICAwLjE2 NzAyNiAgICAgICAgICAgIDAuMzI4ODkzICAgICAgICAgICAgMC4xMjQ1NjUNCjEuNzVFLTA4 ICAgICAgICAgICAgMC4xNjY5MTkgICAgICAgICAgICAwLjMwNzcxMiAgICAgICAgICAgIDAu MTI0NTY1DQoxLjhFLTA4ICAgICAgICAgICAgIDAuMTY2ODExICAgICAgICAgICAgMC4yOTQ3 NiAgICAgICAgICAgICAwLjEyNDU2NQ0KMS44NUUtMDggICAgICAgICAgICAwLjE2NjcwNCAg ICAgICAgICAgIDAuMjgxODA4ICAgICAgICAgICAgMC4xMjQ1NjQNCjEuOUUtMDggICAgICAg ICAgICAgMC4xNjY2NjkgICAgICAgICAgICAwLjI3MTMwMiAgICAgICAgICAgIDAuMTI0NTY0 DQoxLjk1RS0wOCAgICAgICAgICAgIDAuMTY2NjY5ICAgICAgICAgICAgMC4yNjQxMDkgICAg ICAgICAgICAwLjEyNDU2NA0KMkUtMDggICAgICAgICAgICAgICAwLjE2NjY2OSAgICAgICAg ICAgIDAuMjU3NTI0ICAgICAgICAgICAgMC4xMjQ1NjMNCnwNCnwqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNb2RlbCAgSV9PMg0KfCoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KfA0KW01vZGVsXSAgICAgICAgIElfTzINCk1vZGVsX3R5cGUgICAg ICAzLXN0YXRlDQpQb2xhcml0eSAgICAgICAgTm9uLUludmVydGluZw0KQ19jb21wICAgMCAg IDAgICAwDQpbVm9sdGFnZSByYW5nZV0gMy4zdiAgICAgICAgICAgIDMuMHYgICAgICAgICAg ICAzLjZ2DQp8DQpbUHVsbGRvd25dDQoNCi01ICAgICAgICAgICAgICAtNy4wMTQ0MyAgICAg ICAgLTcuMTMxMDcgICAgICAgIC02LjkzMjE3DQotNCAgICAgICAgICAgICAgLTUuMzA3NzYg ICAgICAgIC01LjQzNDQ2ICAgICAgICAtNS4yMTYzOQ0KLTMgICAgICAgICAgICAgIC0zLjYw NDkyICAgICAgICAtMy43NDE4OSAgICAgICAgLTMuNTA0MTUNCi0yICAgICAgICAgICAgICAt MS45MTQ3NiAgICAgICAgLTIuMDYzMDcgICAgICAgIC0xLjgwMzQ0DQotMSAgICAgICAgICAg ICAgLTAuMjkzNTMzICAgICAgIC0wLjQ0NDY4MiAgICAgICAtMC4xODU2NQ0KMCAgICAgICAg ICAgICAgIDAuMDAwNDkwNjQxICAgICAwLjAwMDYyNjU1ICAgICAgMC4wMDAzODU0NDcNCjEg ICAgICAgICAgICAgICAwLjAzNTc0MDcgICAgICAgMC4wMjQwOTI4ICAgICAgIDAuMDUwOTg4 DQoyICAgICAgICAgICAgICAgMC4wNjY0NTMyICAgICAgIDAuMDQ0NjY4NCAgICAgICAwLjA5 NDc4Nw0KMyAgICAgICAgICAgICAgIDAuMDkwNTIgICAgICAgICAwLjA2MTEzMDIgICAgICAg MC4xMjg1OTINCjQgICAgICAgICAgICAgICAwLjEwODAyNyAgICAgICAgMC4wNzQ5MTMzICAg ICAgIDAuMTUxNzE4DQo1ICAgICAgICAgICAgICAgMC4xMjg3NzUgICAgICAgIDAuMDg5NTIx NyAgICAgICAwLjE3NzYzDQo2ICAgICAgICAgICAgICAgMC4xNDc1NTcgICAgICAgIDAuMDk4 NDgxMyAgICAgICAwLjIwNzA4Mw0KNyAgICAgICAgICAgICAgIDAuMTYxNjcgICAgICAgICAw LjEwNjUyNCAgICAgICAgMC4yMzY0NzcNCjggICAgICAgICAgICAgICAwLjE3NTU5NSAgICAg ICAgMC4xMTQ5NDggICAgICAgIDAuMjYyOTAyDQo5ICAgICAgICAgICAgICAgMC4xODk4MDkg ICAgICAgIDAuMTIyNDU3ICAgICAgICAwLjI4ODkzOQ0KMTAgICAgICAgICAgICAgIDAuMjAw NjI1ICAgICAgICAwLjEyMzA0OSAgICAgICAgMC4zMTQ3NA0KW1B1bGx1cF0NCi0xMCAgICAg ICAgICAgICAgOS45NzQ4NCAgICAgICAgIDEwLjU1NzMgICAgICAgICA5LjQ0MTQ2DQotOSAg ICAgICAgICAgICAgIDguMjYzNSAgICAgICAgICA4Ljg1Njk5ICAgICAgICAgNy43MTg1OA0K LTggICAgICAgICAgICAgICA2LjU1MjQ5ICAgICAgICAgNy4xNTcyNiAgICAgICAgIDUuOTk2 NTgNCi03ICAgICAgICAgICAgICAgNC44NDM5NiAgICAgICAgIDUuNDU5MDggICAgICAgICA0 LjI4MDIxDQotNiAgICAgICAgICAgICAgIDMuMTQxNyAgICAgICAgICAzLjc2NTM4ICAgICAg ICAgMi41NzAyNg0KLTUgICAgICAgICAgICAgICAxLjQ1NzYgICAgICAgICAgMi4wODYyNiAg ICAgICAgIDAuODg3MDI0DQotNCAgICAgICAgICAgICAgIDAuMDUyNDI5OSAgICAgICAwLjQ3 MTQyOSAgICAgICAgMC4wODEyNTU1DQotMyAgICAgICAgICAgICAgIDAuMDQwNDQwNyAgICAg ICAwLjAyMDMxNTQgICAgICAgMC4wNzY2Mjg5DQotMiAgICAgICAgICAgICAgIDAuMDM3MDU5 MyAgICAgICAwLjAxOTI1NjMgICAgICAgMC4wNjY2MTg1DQotMSAgICAgICAgICAgICAgIDAu MDI1MDE2OCAgICAgICAwLjAxNDE5MDkgICAgICAgMC4wNDE1MDA0DQowICAgICAgICAgICAg ICAgLTAuMDAwODAwMDYxICAgICAtMC4wMDA4MjE4OSAgICAgIC0wLjAwMDg4ODIwNQ0KMSAg ICAgICAgICAgICAgIC0wLjAzNTM3MDYgICAgICAgLTAuMDIzNTc3OSAgICAgICAtMC4wNTIw MjA1DQoyICAgICAgICAgICAgICAgLTAuMDcxMjcxNCAgICAgICAtMC4wNDcxMDczICAgICAg IC0wLjEwMzY0OA0KMyAgICAgICAgICAgICAgIC0wLjA5MzQxOCAgICAgICAgLTAuMDYxMjY1 NiAgICAgICAtMC4xMzU0NDMNCjQgICAgICAgICAgICAgICAtMC4wMzk4MzE4ICAgICAgIC0w LjAyMTkxNzcgICAgICAgLTAuMDcxMDc1NQ0KNSAgICAgICAgICAgICAgIC0wLjAyNTkwNDUg ICAgICAgLTAuMDE0OTg4NyAgICAgICAtMC4wNDg2MTM4DQoNCltHTkRfY2xhbXBdDQogMC4w diAgICAgICAgICAgICAwLjBtICBOQSAgICAgIE5BDQotMC41diAgICAgICAgICAgLTEwLjBt ICBOQSAgICAgIE5BDQotMC43diAgICAgICAgICAgLTIwLjBtICBOQSAgICAgIE5BDQotNS4w diAgICAgICAgICAtNDAwLjBtICBOQSAgICAgIE5BDQpbUE9XRVJfY2xhbXBdDQogMC4wdiAg ICAgICAgICAgICAwLjBtICBOQSAgICAgIE5BDQotMC41diAgICAgICAgICAgIDEwLjBtICBO QSAgICAgIE5BDQotMC43diAgICAgICAgICAgIDIwLjBtICBOQSAgICAgIE5BDQotNS4wdiAg ICAgICAgICAgNDAwLjBtICBOQSAgICAgIE5BDQoNCg0KDQpbUmFtcF0NCg0KZFYvZHRfciAg ICAgICAgICAgIDEuNy8wLjduICAgICAgICAxLjAvMC44biAgICAgICAgMi4xLzAuNDVuDQpk Vi9kdF9mICAgICAgICAgICAgMi40LzEuNm4gICAgICAgIDEuMC8zLjRuICAgICAgICAyLjIv MS4zbg0KDQpbUmlzaW5nIFdhdmVmb3JtXQ0KUl9maXh0dXJlPTUwMA0KVl9maXh0dXJlPTMu Mw0KVl9maXh0dXJlX21pbj0zLjANClZfZml4dHVyZV9tYXg9My42DQpDX2ZpeHR1cmU9NTBw DQpMX2ZpeHR1cmU9MTBuDQoxRS0wOSAgICAgICAgICAgICAgIDEuOTUwNTFFLTA4ICAgICAg ICAgNC43MzYwNkUtMDggICAgICAgICAtNy41NDI5RS0wNw0KMS41RS0wOSAgICAgICAgICAg ICAtMi4zMTA2NkUtMDYgICAgICAgIDEuMjI5OTZFLTA3ICAgICAgICAgLTEuMTgyNTZFLTA2 DQoyRS0wOSAgICAgICAgICAgICAgIC02LjYxNDgxRS0wNyAgICAgICAgLTIuNTM3MzdFLTA2 ICAgICAgICAtOS4xODQ0NkUtMDYNCjIuNUUtMDkgICAgICAgICAgICAgLTEuODc3ODZFLTA1 ICAgICAgICAtMS43NDg4MkUtMDYgICAgICAgIDAuMDI2OTcwMg0KM0UtMDkgICAgICAgICAg ICAgICAtMC4wMDMwNjg5MSAgICAgICAgIDEuNzQxODZFLTA1ICAgICAgICAgMC41MzYzMzIN CjMuNUUtMDkgICAgICAgICAgICAgMC4wOTE4NzY4ICAgICAgICAgICAtMC4wMDA0MTcwNjcg ICAgICAgIDEuMzI1MDgNCjRFLTA5ICAgICAgICAgICAgICAgMC40MTU0NjYgICAgICAgICAg ICAtMC4wMDQzMDk3NSAgICAgICAgIDEuOTU0OTINCjQuNUUtMDkgICAgICAgICAgICAgMC43 NzkxOCAgICAgICAgICAgICAwLjAwNzIyNTY5ICAgICAgICAgIDIuNDk0NDUNCjVFLTA5ICAg ICAgICAgICAgICAgMS4xMTk1NCAgICAgICAgICAgICAwLjA3OTM4MSAgICAgICAgICAgIDIu OTE2MDUNCjUuNUUtMDkgICAgICAgICAgICAgMS40NjU3OCAgICAgICAgICAgICAwLjIwODE1 MSAgICAgICAgICAgIDMuMTk4NjQNCjZFLTA5ICAgICAgICAgICAgICAgMS43ODI5OSAgICAg ICAgICAgICAwLjM2MjM4ICAgICAgICAgICAgIDMuMzcxNA0KNi41RS0wOSAgICAgICAgICAg ICAyLjA2NTQgICAgICAgICAgICAgIDAuNTMyNDQ3ICAgICAgICAgICAgMy40NTgyDQo3RS0w OSAgICAgICAgICAgICAgIDIuMzEzNzEgICAgICAgICAgICAgMC43MTEzNjYgICAgICAgICAg ICAzLjQ5NDQyDQo3LjVFLTA5ICAgICAgICAgICAgIDIuNTE5NyAgICAgICAgICAgICAgMC44 ODc2MDEgICAgICAgICAgICAzLjQ5NjIyDQo4RS0wOSAgICAgICAgICAgICAgIDIuNjg3NzIg ICAgICAgICAgICAgMS4wNjEzNSAgICAgICAgICAgICAzLjQ4ODIxDQo4LjVFLTA5ICAgICAg ICAgICAgIDIuODExNjggICAgICAgICAgICAgMS4yMzAwNyAgICAgICAgICAgICAzLjQ3OQ0K OUUtMDkgICAgICAgICAgICAgICAyLjkwODQ3ICAgICAgICAgICAgIDEuMzg5NDUgICAgICAg ICAgICAgMy40NzIxMQ0KOS41RS0wOSAgICAgICAgICAgICAyLjk3NjIgICAgICAgICAgICAg IDEuNTQ0NzcgICAgICAgICAgICAgMy40Njg5OA0KMUUtMDggICAgICAgICAgICAgICAzLjAy MTA5ICAgICAgICAgICAgIDEuNjg3NDEgICAgICAgICAgICAgMy40Njc4Nw0KMS4wNUUtMDgg ICAgICAgICAgICAzLjA1MjkyICAgICAgICAgICAgIDEuODIxNDcgICAgICAgICAgICAgMy40 Njc1Mg0KMS4xRS0wOCAgICAgICAgICAgICAzLjA3ODU1ICAgICAgICAgICAgIDEuOTUyOTkg ICAgICAgICAgICAgMy40Njc5Mw0KMS4xNUUtMDggICAgICAgICAgICAzLjA5MTk0ICAgICAg ICAgICAgIDIuMDYwNzggICAgICAgICAgICAgMy40NjgzNA0KMS4yRS0wOCAgICAgICAgICAg ICAzLjEwMzU5ICAgICAgICAgICAgIDIuMTY4NTggICAgICAgICAgICAgMy40Njg3Mg0KMS4y NUUtMDggICAgICAgICAgICAzLjEwODY0ICAgICAgICAgICAgIDIuMjU5ODUgICAgICAgICAg ICAgMy40NjkwOA0KMS4zRS0wOCAgICAgICAgICAgICAzLjExMzM2ICAgICAgICAgICAgIDIu MzQyODMgICAgICAgICAgICAgMy40NjkzDQoxLjM1RS0wOCAgICAgICAgICAgIDMuMTE1MjYg ICAgICAgICAgICAgMi40MDg1MiAgICAgICAgICAgICAzLjQ2OTI1DQoxLjRFLTA4ICAgICAg ICAgICAgIDMuMTE3MTcgICAgICAgICAgICAgMi40NzA3NCAgICAgICAgICAgICAzLjQ2OTIx DQoxLjQ1RS0wOCAgICAgICAgICAgIDMuMTE3OTUgICAgICAgICAgICAgMi41MTcxICAgICAg ICAgICAgICAzLjQ2OTEzDQoxLjVFLTA4ICAgICAgICAgICAgIDMuMTE4NDggICAgICAgICAg ICAgMi41NTU5NCAgICAgICAgICAgICAzLjQ2OTA5DQoxLjU1RS0wOCAgICAgICAgICAgIDMu MTE4ODUgICAgICAgICAgICAgMi41ODkwMSAgICAgICAgICAgICAzLjQ2OTA3DQoxLjZFLTA4 ICAgICAgICAgICAgIDMuMTE5MDUgICAgICAgICAgICAgMi42MTY5MyAgICAgICAgICAgICAz LjQ2OTA3DQoxLjY1RS0wOCAgICAgICAgICAgIDMuMTE5MjEgICAgICAgICAgICAgMi42Mzg1 OCAgICAgICAgICAgICAzLjQ2OTA4DQoxLjdFLTA4ICAgICAgICAgICAgIDMuMTE5MzIgICAg ICAgICAgICAgMi42NTc1MyAgICAgICAgICAgICAzLjQ2OTA4DQoxLjc1RS0wOCAgICAgICAg ICAgIDMuMTE5NDIgICAgICAgICAgICAgMi42NzY0OCAgICAgICAgICAgICAzLjQ2OTA5DQox LjhFLTA4ICAgICAgICAgICAgIDMuMTE5NTIgICAgICAgICAgICAgMi42ODY5NCAgICAgICAg ICAgICAzLjQ2OTA5DQoxLjg1RS0wOCAgICAgICAgICAgIDMuMTE5NjMgICAgICAgICAgICAg Mi42OTcwMyAgICAgICAgICAgICAzLjQ2OTA5DQoxLjlFLTA4ICAgICAgICAgICAgIDMuMTE5 NjYgICAgICAgICAgICAgMi43MDcxMiAgICAgICAgICAgICAzLjQ2OTENCjEuOTVFLTA4ICAg ICAgICAgICAgMy4xMTk2NyAgICAgICAgICAgICAyLjcxNDY0ICAgICAgICAgICAgIDMuNDY5 MQ0KMkUtMDggICAgICAgICAgICAgICAzLjExOTY4ICAgICAgICAgICAgIDIuNzE5MzYgICAg ICAgICAgICAgMy40NjkxDQoyLjA1RS0wOCAgICAgICAgICAgIDMuMTE5NjggICAgICAgICAg ICAgMi43MjQwOCAgICAgICAgICAgICAzLjQ2OTENCjIuMUUtMDggICAgICAgICAgICAgMy4x MTk2OSAgICAgICAgICAgICAyLjcyODggICAgICAgICAgICAgIDMuNDY5MTENCjIuMTVFLTA4 ICAgICAgICAgICAgMy4xMTk2OSAgICAgICAgICAgICAyLjczMTM3ICAgICAgICAgICAgIDMu NDY5MTENCjIuMkUtMDggICAgICAgICAgICAgMy4xMTk3ICAgICAgICAgICAgICAyLjczMzQ3 ICAgICAgICAgICAgIDMuNDY5MTENCltGYWxsaW5nIFdhdmVmb3JtXQ0KUl9maXh0dXJlPTUw MA0KVl9maXh0dXJlPTANClZfZml4dHVyZV9taW49MC4wDQpWX2ZpeHR1cmVfbWF4PTAuMA0K Q19maXh0dXJlPTUwcA0KTF9maXh0dXJlPTEwbg0KMUUtMDkgICAgICAgICAgICAgICAzLjMg ICAgICAgICAgICAgICAgIDMgICAgICAgICAgICAgICAgICAgMy41OTk5OQ0KMS41RS0wOSAg ICAgICAgICAgICAzLjI5OTk5ICAgICAgICAgICAgIDMgICAgICAgICAgICAgICAgICAgMy42 MDAwMQ0KMkUtMDkgICAgICAgICAgICAgICAzLjMgICAgICAgICAgICAgICAgIDIuOTk5OTkg ICAgICAgICAgICAgMy41OTk5Mw0KMi41RS0wOSAgICAgICAgICAgICAzLjI5OTcxICAgICAg ICAgICAgIDMgICAgICAgICAgICAgICAgICAgMy41OTQ1DQozRS0wOSAgICAgICAgICAgICAg IDMuMzAwMTUgICAgICAgICAgICAgMy4wMDAwMSAgICAgICAgICAgICAzLjM0NjMyDQozLjVF LTA5ICAgICAgICAgICAgIDMuMjgwNSAgICAgICAgICAgICAgMi45OTk5MyAgICAgICAgICAg ICAyLjg0MDgxDQo0RS0wOSAgICAgICAgICAgICAgIDMuMTQ5MDIgICAgICAgICAgICAgMy4w MDAwMyAgICAgICAgICAgICAyLjIyMzkNCjQuNUUtMDkgICAgICAgICAgICAgMi45MTE2MSAg ICAgICAgICAgICAyLjk5OTc1ICAgICAgICAgICAgIDEuNjA3MzcNCjVFLTA5ICAgICAgICAg ICAgICAgMi42MDQ3MiAgICAgICAgICAgICAyLjk5MDkyICAgICAgICAgICAgIDEuMDYwMTUN CjUuNUUtMDkgICAgICAgICAgICAgMi4yNTU1NiAgICAgICAgICAgICAyLjk0NjQ2ICAgICAg ICAgICAgIDAuNjQ2MDQyDQo2RS0wOSAgICAgICAgICAgICAgIDEuOTEyOTYgICAgICAgICAg ICAgMi44Njk0OSAgICAgICAgICAgICAwLjM1NDI0OA0KNi41RS0wOSAgICAgICAgICAgICAx LjU3MzMyICAgICAgICAgICAgIDIuNzU4OTYgICAgICAgICAgICAgMC4xODIwOTgNCjdFLTA5 ICAgICAgICAgICAgICAgMS4yNTM4NCAgICAgICAgICAgICAyLjYxNTk0ICAgICAgICAgICAg IDAuMTA0NjU4DQo3LjVFLTA5ICAgICAgICAgICAgIDAuOTgyNjMgICAgICAgICAgICAgMi40 NTUwMiAgICAgICAgICAgICAwLjA4Njk2NTMNCjhFLTA5ICAgICAgICAgICAgICAgMC43NTMz NjEgICAgICAgICAgICAyLjI4MDI2ICAgICAgICAgICAgIDAuMDkzODU3NQ0KOC41RS0wOSAg ICAgICAgICAgICAwLjU4MzA4NiAgICAgICAgICAgIDIuMDk2NjEgICAgICAgICAgICAgMC4x MDcyMTYNCjlFLTA5ICAgICAgICAgICAgICAgMC40NDk0OTMgICAgICAgICAgICAxLjkxMTUx ICAgICAgICAgICAgIDAuMTE4MTcNCjkuNUUtMDkgICAgICAgICAgICAgMC4zNTU5MjEgICAg ICAgICAgICAxLjczMDkyICAgICAgICAgICAgIDAuMTI0MDg2DQoxRS0wOCAgICAgICAgICAg ICAgIDAuMjk0MDcgICAgICAgICAgICAgMS41NjIxMyAgICAgICAgICAgICAwLjEyNjU0Mw0K MS4wNUUtMDggICAgICAgICAgICAwLjI0NjM5NiAgICAgICAgICAgIDEuMzkzNjQgICAgICAg ICAgICAgMC4xMjY1MjUNCjEuMUUtMDggICAgICAgICAgICAgMC4yMTc5NTkgICAgICAgICAg ICAxLjIzMDc0ICAgICAgICAgICAgIDAuMTI2NTA2DQoxLjE1RS0wOCAgICAgICAgICAgIDAu MTk5MDc2ICAgICAgICAgICAgMS4wODUyICAgICAgICAgICAgICAwLjEyNTYxOQ0KMS4yRS0w OCAgICAgICAgICAgICAwLjE4NTU3OCAgICAgICAgICAgIDAuOTUyNTE4ICAgICAgICAgICAg MC4xMjQ3MTUNCjEuMjVFLTA4ICAgICAgICAgICAgMC4xNzkxNjIgICAgICAgICAgICAwLjgz MzA2ICAgICAgICAgICAgIDAuMTI0NDU1DQoxLjNFLTA4ICAgICAgICAgICAgIDAuMTczOTI5 ICAgICAgICAgICAgMC43MzA2OCAgICAgICAgICAgICAwLjEyNDIwMw0KMS4zNUUtMDggICAg ICAgICAgICAwLjE3MTE5OCAgICAgICAgICAgIDAuNjQzNzkyICAgICAgICAgICAgMC4xMjQy OTMNCjEuNEUtMDggICAgICAgICAgICAgMC4xNjk1MDIgICAgICAgICAgICAwLjU2NzY3NSAg ICAgICAgICAgIDAuMTI0Mzg1DQoxLjQ1RS0wOCAgICAgICAgICAgIDAuMTY4NTY3ICAgICAg ICAgICAgMC41MDU3NDEgICAgICAgICAgICAwLjEyNDQ2Ng0KMS41RS0wOCAgICAgICAgICAg ICAwLjE2Nzk1ICAgICAgICAgICAgIDAuNDU0MTQ4ICAgICAgICAgICAgMC4xMjQ1MjENCjEu NTVFLTA4ICAgICAgICAgICAgMC4xNjc1MyAgICAgICAgICAgICAwLjQxMjc4MyAgICAgICAg ICAgIDAuMTI0NTUyDQoxLjZFLTA4ICAgICAgICAgICAgIDAuMTY3MzEzICAgICAgICAgICAg MC4zNzc4MjkgICAgICAgICAgICAwLjEyNDU2DQoxLjY1RS0wOCAgICAgICAgICAgIDAuMTY3 MTMzICAgICAgICAgICAgMC4zNTIwNzcgICAgICAgICAgICAwLjEyNDU2NQ0KMS43RS0wOCAg ICAgICAgICAgICAwLjE2NzAyNiAgICAgICAgICAgIDAuMzI4ODkzICAgICAgICAgICAgMC4x MjQ1NjUNCjEuNzVFLTA4ICAgICAgICAgICAgMC4xNjY5MTkgICAgICAgICAgICAwLjMwNzcx MiAgICAgICAgICAgIDAuMTI0NTY1DQoxLjhFLTA4ICAgICAgICAgICAgIDAuMTY2ODExICAg ICAgICAgICAgMC4yOTQ3NiAgICAgICAgICAgICAwLjEyNDU2NQ0KMS44NUUtMDggICAgICAg ICAgICAwLjE2NjcwNCAgICAgICAgICAgIDAuMjgxODA4ICAgICAgICAgICAgMC4xMjQ1NjQN CjEuOUUtMDggICAgICAgICAgICAgMC4xNjY2NjkgICAgICAgICAgICAwLjI3MTMwMiAgICAg ICAgICAgIDAuMTI0NTY0DQoxLjk1RS0wOCAgICAgICAgICAgIDAuMTY2NjY5ICAgICAgICAg ICAgMC4yNjQxMDkgICAgICAgICAgICAwLjEyNDU2NA0KMkUtMDggICAgICAgICAgICAgICAw LjE2NjY2OSAgICAgICAgICAgIDAuMjU3NTI0ICAgICAgICAgICAgMC4xMjQ1NjMNCjIuMDVF LTA4ICAgICAgICAgICAgMC4xNjY2NjkgICAgICAgICAgICAwLjI1MzE5NSAgICAgICAgICAg IDAuMTI0NTYzDQoyLjFFLTA4ICAgICAgICAgICAgIDAuMTY2NjY5ICAgICAgICAgICAgMC4y NDg4NjUgICAgICAgICAgICAwLjEyNDU2Mg0KMi4xNUUtMDggICAgICAgICAgICAwLjE2NjY2 OSAgICAgICAgICAgIDAuMjQ2MTAxICAgICAgICAgICAgMC4xMjQ1NjINCjIuMkUtMDggICAg ICAgICAgICAgMC4xNjY2NjkgICAgICAgICAgICAwLjI0Mzg4MyAgICAgICAgICAgIDAuMTI0 NTYxDQoNCltNb2RlbF0gICAgICAgICBDTEsNCk1vZGVsX3R5cGUgICAgICBPdXRwdXQNClBv bGFyaXR5ICAgICAgICBOb24tSW52ZXJ0aW5nDQpDX2NvbXAgICAwICAgMCAgIDANCg0KW1Zv bHRhZ2UgcmFuZ2VdIDMuM3YgICAgICAgICAgICAzLjB2ICAgICAgICAgICAgMy42dg0KDQpb UHVsbGRvd25dDQotNSAgICAgICAgICAgICAgICAgIC0xMC4wNDc2ICAgICAgICAgICAgLTEw LjIyODIgICAgICAgICAgICAtOS45MTUzOQ0KLTQgICAgICAgICAgICAgICAgICAtNy42MDk0 MyAgICAgICAgICAgIC03LjgwMjYyICAgICAgICAgICAgLTcuNDY2NjENCi0zICAgICAgICAg ICAgICAgICAgLTUuMTczNDMgICAgICAgICAgICAtNS4zNzkyMyAgICAgICAgICAgIC01LjAx OTkNCi0yICAgICAgICAgICAgICAgICAgLTIuNzQ4MDcgICAgICAgICAgICAtMi45NjY2OSAg ICAgICAgICAgIC0yLjU4MzM1DQotMSAgICAgICAgICAgICAgICAgIC0wLjQxNjM2ICAgICAg ICAgICAgLTAuNjM2NDMyICAgICAgICAgICAtMC4yNTkyNTENCjAgICAgICAgICAgICAgICAg ICAgMC4wMDA3MTk0NzMgICAgICAgICAwLjAwMDg2OTU4MyAgICAgICAgIDAuMDAwNjAyNjcz DQoxICAgICAgICAgICAgICAgICAgIDAuMDEzMjgwOCAgICAgICAgICAgMC4wMDg1NDA0MyAg ICAgICAgICAwLjAxOTk5NDkNCjIgICAgICAgICAgICAgICAgICAgMC4xNTk3NDQgICAgICAg ICAgICAwLjA3NTE4NCAgICAgICAgICAgIDAuMjUyNw0KMyAgICAgICAgICAgICAgICAgICAw LjE2Nzg5ICAgICAgICAgICAgIDAuMTAyNTAxICAgICAgICAgICAgMC4yNjI1NDQNCjQgICAg ICAgICAgICAgICAgICAgMC4xODExNTggICAgICAgICAgICAwLjMxNjU2OCAgICAgICAgICAg IDAuMjY3NjIxDQo1ICAgICAgICAgICAgICAgICAgIDAuNzc3OTQ4ICAgICAgICAgICAgMC45 ODQ5NTggICAgICAgICAgICAwLjYyMDM4DQo2ICAgICAgICAgICAgICAgICAgIDEuNDY5MTcg ICAgICAgICAgICAgMS42NzUzNiAgICAgICAgICAgICAxLjMxMTk5DQo3ICAgICAgICAgICAg ICAgICAgIDIuMTcwMjEgICAgICAgICAgICAgMi4zNzMwMiAgICAgICAgICAgICAyLjAxNzQ4 DQo4ICAgICAgICAgICAgICAgICAgIDIuODc4NTUgICAgICAgICAgICAgMy4wNzYwMiAgICAg ICAgICAgICAyLjczMjYxDQo5ICAgICAgICAgICAgICAgICAgIDMuNTkzNTEgICAgICAgICAg ICAgMy43ODMyOCAgICAgICAgICAgICAzLjQ1NzIyDQoxMCAgICAgICAgICAgICAgICAgIDQu MzE1MzcgICAgICAgICAgICAgNC40OTUxMiAgICAgICAgICAgICA0LjE5MTg2DQpbUHVsbHVw XQ0KLTEwICAgICAgICAgICAgICAxNC4zNTMxICAgICAgICAgMTUuMTYyOCAgICAgICAgIDEz LjY1NzcNCi05ICAgICAgICAgICAgICAgMTEuOTA3NCAgICAgICAgIDEyLjczMjcgICAgICAg ICAxMS4xOTQ1DQotOCAgICAgICAgICAgICAgIDkuNDYzNCAgICAgICAgICAxMC4zMDM4ICAg ICAgICAgOC43MzM3MQ0KLTcgICAgICAgICAgICAgICA3LjAyMDc5ICAgICAgICAgNy44NzU5 MyAgICAgICAgIDYuMjc1MDUNCi02ICAgICAgICAgICAgICAgNC41ODIwNiAgICAgICAgIDUu NDUwNDQgICAgICAgICAzLjgyMjExDQotNSAgICAgICAgICAgICAgIDIuMTYxODIgICAgICAg ICAzLjAzNjU5ICAgICAgICAgMS40MDMzMw0KLTQgICAgICAgICAgICAgICAwLjEzNjk1MSAg ICAgICAgMC43MDY5NyAgICAgICAgIDAuMjQ0MjMxDQotMyAgICAgICAgICAgICAgIDAuMTIy Nzk2ICAgICAgICAwLjA2MzcxNzggICAgICAgMC4yMjk4NzINCi0yICAgICAgICAgICAgICAg MC4xMTIxNjUgICAgICAgIDAuMDYwMDUxICAgICAgICAwLjAyMDM2MTQNCi0xICAgICAgICAg ICAgICAgMC4wMDcyMTMxNyAgICAgIDAuMDA2OTQ2NjIgICAgICAwLjAxMjA4OTMNCjAgICAg ICAgICAgICAgICAtMC4wMDA2NTA4MDkgICAgIC0wLjAwMDcyNzYzNyAgICAgLTAuMDAwNTIw MjYxDQoxICAgICAgICAgICAgICAgLTAuMTQ0OTYxICAgICAgICAtMC4yMTM2OTggICAgICAg IC0wLjA5Nzc4ODYNCjIgICAgICAgICAgICAgICAtMC44MTA0NyAgICAgICAgIC0wLjg4MDI2 MyAgICAgICAgLTAuNzU3NzQ5DQozICAgICAgICAgICAgICAgLTEuNTAwODIgICAgICAgICAt MS41NjgyNiAgICAgICAgIC0xLjQ1MDEzDQo0ICAgICAgICAgICAgICAgLTIuMTk2MDcgICAg ICAgICAtMi4yNjE2MyAgICAgICAgIC0yLjE0NjkNCjUgICAgICAgICAgICAgICAtMi44OTMz OCAgICAgICAgIC0yLjk1NzQxICAgICAgICAgLTIuODQ1NTcNCg0KDQpbR05EX2NsYW1wXQ0K DQogMC4wdiAgICAgICAgICAgICAwLjBtICBOQSAgICAgIE5BDQotMC41diAgICAgICAgICAg LTEwLjBtICBOQSAgICAgIE5BDQotMC43diAgICAgICAgICAgLTIwLjBtICBOQSAgICAgIE5B DQotNS4wdiAgICAgICAgICAtNDAwLjBtICBOQSAgICAgIE5BDQpbUE9XRVJfY2xhbXBdDQog MC4wdiAgICAgICAgICAgICAwLjBtICBOQSAgICAgIE5BDQotMC41diAgICAgICAgICAgIDEw LjBtICBOQSAgICAgIE5BDQotMC43diAgICAgICAgICAgIDIwLjBtICBOQSAgICAgIE5BDQot NS4wdiAgICAgICAgICAgNDAwLjBtICBOQSAgICAgIE5BDQoNCltSYW1wXQ0KZFYvZHRfciAg ICAgICAgICAgIDIuNC8xLjVuICAgICAgICAyLjAvMi4wbiAgICAgICAgMi4wLzEuNW4NCmRW L2R0X2YgICAgICAgICAgICAyLjUvMS41biAgICAgICAgMi41LzIuMG4gICAgICAgIDIuNS8x LjVuDQoNCltSaXNpbmcgV2F2ZWZvcm1dDQpSX2ZpeHR1cmU9NTAwDQpWX2ZpeHR1cmU9My4z DQpWX2ZpeHR1cmVfbWluPTMuMA0KVl9maXh0dXJlX21heD0zLjYNCkNfZml4dHVyZT01MHAN CkxfZml4dHVyZT0xMG4NCjFFLTA5ICAgICAgICAgICAtMi4wMzc0NkUtMDcgICAgLTEuNTg1 NzZFLTA2ICAgIDguMDc2NTNFLTA1DQoxLjVFLTA5ICAgICAgICAgMC4wMDAxNzI1NTMgICAg IDYuODA0M0UtMDYgICAgICAwLjAxMTkyODQNCjJFLTA5ICAgICAgICAgICAtMC4wMDM3NTIx NSAgICAgMC4wMDAxMzM3MjIgICAgIDAuNjcwMTU2DQoyLjVFLTA5ICAgICAgICAgMC4wODA1 NzczICAgICAgIDYuNTUyMTRFLTA1ICAgICAxLjY0NDA5DQozRS0wOSAgICAgICAgICAgMC42 MzA2NTkgICAgICAgIC0wLjAwMTg4OTc4ICAgICAxLjkxNzkxDQozLjVFLTA5ICAgICAgICAg MS41MDg1OCAgICAgICAgIC0wLjAwNTk5NTA2ICAgICAyLjQzNTc2DQo0RS0wOSAgICAgICAg ICAgMi4zNjc1OSAgICAgICAgIDAuMDQ4NjMxNCAgICAgICAyLjQzNzc3DQo0LjVFLTA5ICAg ICAgICAgMi45NjcxNyAgICAgICAgIDAuMjU3MzU3ICAgICAgICAyLjUwMTExDQo1RS0wOSAg ICAgICAgICAgMy4xMjI5MSAgICAgICAgIDAuNTU4OTY3ICAgICAgICAyLjYwMzMxDQo1LjVF LTA5ICAgICAgICAgMy4wNDQyNiAgICAgICAgIDAuOTYzMjU2ICAgICAgICAyLjY1NDQxDQo2 RS0wOSAgICAgICAgICAgMy4wMjcyOCAgICAgICAgIDEuNDE4NDEgICAgICAgICAyLjcyNDAz DQo2LjVFLTA5ICAgICAgICAgMi45ODkzMyAgICAgICAgIDEuODU1MjkgICAgICAgICAyLjc3 NjQ3DQo3RS0wOSAgICAgICAgICAgMi45NjMxOSAgICAgICAgIDIuMjQyMjggICAgICAgICAy LjgyNDE2DQo3LjVFLTA5ICAgICAgICAgMi45MzcwNyAgICAgICAgIDIuNTMyNzkgICAgICAg ICAyLjg2NjA1DQo4RS0wOSAgICAgICAgICAgMi45MTM4NSAgICAgICAgIDIuNjkzNzIgICAg ICAgICAyLjkwMjk2DQo4LjVFLTA5ICAgICAgICAgMi44OTM1MyAgICAgICAgIDIuNzM1MzMg ICAgICAgICAyLjkzNTA0DQo5RS0wOSAgICAgICAgICAgMi44NzQ3MiAgICAgICAgIDIuNzIy ODMgICAgICAgICAyLjk2MjQ1DQo5LjVFLTA5ICAgICAgICAgMi44NTc5OSAgICAgICAgIDIu Njg4NTcgICAgICAgICAyLjk4NzA0DQoxRS0wOCAgICAgICAgICAgMi44NDMwMSAgICAgICAg IDIuNjU4MjggICAgICAgICAzLjAwODA4DQoxLjA1RS0wOCAgICAgICAgMi44Mjg1NiAgICAg ICAgIDIuNjI4MDQgICAgICAgICAzLjAyODENCjEuMUUtMDggICAgICAgICAyLjgxNjcgICAg ICAgICAgMi41OTkzOCAgICAgICAgIDMuMDQzMjYNCjEuMTVFLTA4ICAgICAgICAyLjgwNDky ICAgICAgICAgMi41NzMyNCAgICAgICAgIDMuMDU4MDgNCjEuMkUtMDggICAgICAgICAyLjc5 MzgzICAgICAgICAgMi41NDc5MSAgICAgICAgIDMuMDcxODkNCjEuMjVFLTA4ICAgICAgICAy Ljc4NTM0ICAgICAgICAgMi41MjQ1MiAgICAgICAgIDMuMDgxMDENCjEuM0UtMDggICAgICAg ICAyLjc3Njg2ICAgICAgICAgMi41MDI3ICAgICAgICAgIDMuMDkwMTMNCjEuMzVFLTA4ICAg ICAgICAyLjc2ODM4ICAgICAgICAgMi40ODE4MiAgICAgICAgIDMuMDk5MjUNCjEuNEUtMDgg ICAgICAgICAyLjc1OTkgICAgICAgICAgMi40NjI0ICAgICAgICAgIDMuMTA4MzcNCjEuNDVF LTA4ICAgICAgICAyLjc1MzU4ICAgICAgICAgMi40NDQ1OSAgICAgICAgIDMuMTE0MDkNCjEu NUUtMDggICAgICAgICAyLjc0NzgzICAgICAgICAgMi40Mjc3MiAgICAgICAgIDMuMTE5MDIN CjEuNTVFLTA4ICAgICAgICAyLjc0MjU5ICAgICAgICAgMi40MTE4NCAgICAgICAgIDMuMTIz MzMNCjEuNkUtMDggICAgICAgICAyLjczODE0ICAgICAgICAgMi4zOTcyNSAgICAgICAgIDMu MTI2NjcNCjEuNjVFLTA4ICAgICAgICAyLjczMzk3ICAgICAgICAgMi4zODMzMiAgICAgICAg IDMuMTI5NzYNCjEuN0UtMDggICAgICAgICAyLjczMDMzICAgICAgICAgMi4zNjkzOCAgICAg ICAgIDMuMTMyMzkNCjEuNzVFLTA4ICAgICAgICAyLjcyNjY5ICAgICAgICAgMi4zNTcyICAg ICAgICAgIDMuMTM1MDENCjEuOEUtMDggICAgICAgICAyLjcyMzA0ICAgICAgICAgMi4zNDU3 MSAgICAgICAgIDMuMTM3NjMNCjEuODVFLTA4ICAgICAgICAyLjcxOTQgICAgICAgICAgMi4z MzQyMiAgICAgICAgIDMuMTM5NTkNCjEuOUUtMDggICAgICAgICAyLjcxNjYzICAgICAgICAg Mi4zMjI3MiAgICAgICAgIDMuMTQxMTcNCjEuOTVFLTA4ICAgICAgICAyLjcxNDI5ICAgICAg ICAgMi4zMTMyNCAgICAgICAgIDMuMTQyNzUNCjJFLTA4ICAgICAgICAgICAyLjcxMTk1ICAg ICAgICAgMi4zMDQwOCAgICAgICAgIDMuMTQzODgNCjIuMDVFLTA4ICAgICAgICAyLjcwOTYx ICAgICAgICAgMi4yOTQ5MiAgICAgICAgIDMuMTQ0OTENCjIuMUUtMDggICAgICAgICAyLjcw NzI4ICAgICAgICAgMi4yODU3NiAgICAgICAgIDMuMTQ1OTUNCjIuMTVFLTA4ICAgICAgICAy LjcwNTU3ICAgICAgICAgMi4yNzc5NiAgICAgICAgIDMuMTQ2NjgNCjIuMkUtMDggICAgICAg ICAyLjcwNDAxICAgICAgICAgMi4yNzA2ICAgICAgICAgIDMuMTQ3MzINCjIuMjVFLTA4ICAg ICAgICAyLjcwMjU4ICAgICAgICAgMi4yNjM2MSAgICAgICAgIDMuMTQ3ODcNCg0KW0ZhbGxp bmcgV2F2ZWZvcm1dDQpSX2ZpeHR1cmU9NTAwDQpWX2ZpeHR1cmU9MA0KVl9maXh0dXJlX21p bj0wLjANClZfZml4dHVyZV9tYXg9MC4wDQpDX2ZpeHR1cmU9NTBwDQpMX2ZpeHR1cmU9MTBu DQoxRS0wOSAgICAgICAgICAgICAgIDMuMyAgICAgICAgICAgICAgICAgMyAgICAgICAgICAg ICAgICAgICAzLjU5OTMxDQoxLjVFLTA5ICAgICAgICAgICAgIDMuMjk1MTkgICAgICAgICAg ICAgMyAgICAgICAgICAgICAgICAgICAzLjMzNzY2DQoyRS0wOSAgICAgICAgICAgICAgIDMu MTExMjMgICAgICAgICAgICAgMy4wMDAwOSAgICAgICAgICAgICAyLjI0NjA0DQoyLjVFLTA5 ICAgICAgICAgICAgIDIuODE4ODIgICAgICAgICAgICAgMi45NzA0NSAgICAgICAgICAgICAw LjU4NDU0OQ0KM0UtMDkgICAgICAgICAgICAgICAyLjEwNzc4ICAgICAgICAgICAgIDIuODQ1 NjggICAgICAgICAgICAgLTAuODA1ODc5DQozLjVFLTA5ICAgICAgICAgICAgIDEuMDg0NTMg ICAgICAgICAgICAgMi43ODAyMSAgICAgICAgICAgICAtMS40MjEyMQ0KNEUtMDkgICAgICAg ICAgICAgICAwLjExNTUyNiAgICAgICAgICAgIDIuNjA0ODMgICAgICAgICAgICAgLTEuMTA5 NTUNCjQuNUUtMDkgICAgICAgICAgICAgLTAuNTM2NDE5ICAgICAgICAgICAyLjMwMjQzICAg ICAgICAgICAgIC0wLjU4MDY0MQ0KNUUtMDkgICAgICAgICAgICAgICAtMC43NTMzMTYgICAg ICAgICAgIDEuODc5MzIgICAgICAgICAgICAgLTAuMTc2NzUxDQo1LjVFLTA5ICAgICAgICAg ICAgIC0wLjU3OTQxOSAgICAgICAgICAgMS4zNjY1ICAgICAgICAgICAgICAtMC4wMjAxNTkN CjZFLTA5ICAgICAgICAgICAgICAgLTAuMzU1MTIzICAgICAgICAgICAwLjgzNTIyNCAgICAg ICAgICAgIDAuMDM3Mzc0Mw0KNi41RS0wOSAgICAgICAgICAgICAtMC4yNDA1OSAgICAgICAg ICAgIDAuMzYwNTk0ICAgICAgICAgICAgMC4wOTIzOTk2DQo3RS0wOSAgICAgICAgICAgICAg IC0wLjE1NDM0NCAgICAgICAgICAgMC4wMjExMzU3ICAgICAgICAgICAwLjEzNjIzNA0KNy41 RS0wOSAgICAgICAgICAgICAtMC4wNjQ4NTY4ICAgICAgICAgIC0wLjEzOTE2MiAgICAgICAg ICAgMC4xNjc1DQo4RS0wOSAgICAgICAgICAgICAgIDAuMDAzODcyNjQgICAgICAgICAgLTAu MTUzOTIzICAgICAgICAgICAwLjE5MjU3Ng0KOC41RS0wOSAgICAgICAgICAgICAwLjA1OTc5 NzQgICAgICAgICAgIC0wLjA3Nzc3NDYgICAgICAgICAgMC4yMTA3MTgNCjlFLTA5ICAgICAg ICAgICAgICAgMC4xMDgzMzEgICAgICAgICAgICAwLjAwODY1Njg1ICAgICAgICAgIDAuMjI1 NDU0DQo5LjVFLTA5ICAgICAgICAgICAgIDAuMTQ3MjQ0ICAgICAgICAgICAgMC4wNTM1MTI2 ICAgICAgICAgICAwLjIzNjI5OA0KMUUtMDggICAgICAgICAgICAgICAwLjE4MDMwMiAgICAg ICAgICAgIDAuMDkyNzgzICAgICAgICAgICAgMC4yNDQ1NzYNCjEuMDVFLTA4ICAgICAgICAg ICAgMC4yMDg3NTcgICAgICAgICAgICAwLjE0MDUxMiAgICAgICAgICAgIDAuMjUxODgNCjEu MUUtMDggICAgICAgICAgICAgMC4yMzE3MDggICAgICAgICAgICAwLjE3NTY0NCAgICAgICAg ICAgIDAuMjU2NjI2DQoxLjE1RS0wOCAgICAgICAgICAgIDAuMjUzNzg4ICAgICAgICAgICAg MC4yMDY2NzEgICAgICAgICAgICAwLjI2MTM3MQ0KMS4yRS0wOCAgICAgICAgICAgICAwLjI3 MDAxMiAgICAgICAgICAgIDAuMjM4MDU4ICAgICAgICAgICAgMC4yNjQyODkNCjEuMjVFLTA4 ICAgICAgICAgICAgMC4yODU3NzEgICAgICAgICAgICAwLjI2NDExMiAgICAgICAgICAgIDAu MjY2MzM1DQoxLjNFLTA4ICAgICAgICAgICAgIDAuMjk2NjI3ICAgICAgICAgICAgMC4yODcy NzggICAgICAgICAgICAwLjI2ODM4Mg0KMS4zNUUtMDggICAgICAgICAgICAwLjMwNzQ4NCAg ICAgICAgICAgIDAuMzA5MjI5ICAgICAgICAgICAgMC4yNzA0MjkNCjEuNEUtMDggICAgICAg ICAgICAgMC4zMTgzNCAgICAgICAgICAgICAwLjMyODg4ICAgICAgICAgICAgIDAuMjcyNDc1 DQoxLjQ1RS0wOCAgICAgICAgICAgIDAuMzI1NjI2ICAgICAgICAgICAgMC4zNDU3MzcgICAg ICAgICAgICAwLjI3MzE2OA0KMS41RS0wOCAgICAgICAgICAgICAwLjMzMTg1MSAgICAgICAg ICAgIDAuMzYxMjEgICAgICAgICAgICAgMC4yNzM3MTENCjEuNTVFLTA4ICAgICAgICAgICAg MC4zMzcyMzIgICAgICAgICAgICAwLjM3NTM5ICAgICAgICAgICAgIDAuMjc0MTQyDQoxLjZF LTA4ICAgICAgICAgICAgIDAuMzQxMzUgICAgICAgICAgICAgMC4zODcxNzcgICAgICAgICAg ICAwLjI3NDQyOA0KMS42NUUtMDggICAgICAgICAgICAwLjM0NTEyOSAgICAgICAgICAgIDAu Mzk4NDk0ICAgICAgICAgICAgMC4yNzQ2NzgNCjEuN0UtMDggICAgICAgICAgICAgMC4zNDgy NSAgICAgICAgICAgICAwLjQwODY3NSAgICAgICAgICAgIDAuMjc0ODU3DQoxLjc1RS0wOCAg ICAgICAgICAgIDAuMzUxMzcxICAgICAgICAgICAgMC40MTg2NTggICAgICAgICAgICAwLjI3 NTAzNw0KMS44RS0wOCAgICAgICAgICAgICAwLjM1NDQ5MiAgICAgICAgICAgIDAuNDI4NDk4 ICAgICAgICAgICAgMC4yNzUyMTYNCjEuODVFLTA4ICAgICAgICAgICAgMC4zNTczMDMgICAg ICAgICAgICAwLjQzNjA2OSAgICAgICAgICAgIDAuMjc1Mzk1DQoxLjlFLTA4ICAgICAgICAg ICAgIDAuMzU5MDcgICAgICAgICAgICAgMC40NDM2NDEgICAgICAgICAgICAwLjI3NTQ3Nw0K MS45NUUtMDggICAgICAgICAgICAwLjM2MDgzOCAgICAgICAgICAgIDAuNDUxMTU2ICAgICAg ICAgICAgMC4yNzU1MTENCjJFLTA4ICAgICAgICAgICAgICAgMC4zNjIyNCAgICAgICAgICAg ICAwLjQ1Njg0MyAgICAgICAgICAgIDAuMjc1NTQ0DQoyLjA1RS0wOCAgICAgICAgICAgIDAu MzYzNDE0ICAgICAgICAgICAgMC40NjI1MzEgICAgICAgICAgICAwLjI3NTU3OA0KMi4xRS0w OCAgICAgICAgICAgICAwLjM2NDU4OCAgICAgICAgICAgIDAuNDY4MjE4ICAgICAgICAgICAg MC4yNzU2MTENCjIuMTVFLTA4ICAgICAgICAgICAgMC4zNjU0MjcgICAgICAgICAgICAwLjQ3 Mjc4NCAgICAgICAgICAgIDAuMjc1NjQNCjIuMkUtMDggICAgICAgICAgICAgMC4zNjYxNDcg ICAgICAgICAgICAwLjQ3Njk0OCAgICAgICAgICAgIDAuMjc1NjYyDQp8KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTW9kZWwgQUNQVQ0KfCoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KDQpbTW9kZWxdICAgICAgICAgQUNQVQ0KTW9kZWxfdHlwZSAg ICAgIDMtc3RhdGUNClBvbGFyaXR5ICAgICAgICBOb24tSW52ZXJ0aW5nDQpDX2NvbXAgICAw ICAgMCAgIDANCg0KW1ZvbHRhZ2UgcmFuZ2VdIDMuM3YgICAgICAgICAgICAzLjB2ICAgICAg ICAgICAgMy42dg0KDQpbUHVsbGRvd25dDQotNSAgICAgICAgICAgICAgLTM2OS41NTcgICAg ICAgIC0yOTguNzcyICAgICAgICAtNDU0Ljg2DQotNCAgICAgICAgICAgICAgLTI2Mi44MDQg ICAgICAgIC0yMTEuMjM1ICAgICAgICAtMzI1LjE0Mg0KLTMgICAgICAgICAgICAgIC0xNTYu MDU4ICAgICAgICAtMTIzLjcwMyAgICAgICAgLTE5NS40MjkNCi0yICAgICAgICAgICAgICAt NTMuOTMwMiAgICAgICAgLTQ1LjIzMTEgICAgICAgIC02Ni4xNzAxDQotMSAgICAgICAgICAg ICAgLTAuMzg3MTUyICAgICAgIC0wLjU4NTgxOCAgICAgICAtMC4yNDg0NjINCjAgICAgICAg ICAgICAgICAwLjAwMTc1NTYzICAgICAgMC4wMDIxNTIwNSAgICAgIDAuMDAxNDU0MjINCjEg ICAgICAgICAgICAgICAwLjA1MDc3NzMgICAgICAgMC4wMzEzNjk3ICAgICAgIDAuMDc5MTEx Mw0KMiAgICAgICAgICAgICAgIDAuMDcxNDQyOCAgICAgICAwLjA0MDA5NjYgICAgICAgMC4x MjA0MDMNCjMgICAgICAgICAgICAgICAwLjA3NDczOTIgICAgICAgMC4wNDExMTEgICAgICAg IDAuMTI5NjM5DQo0ICAgICAgICAgICAgICAgMC4wNzU5ODc3ICAgICAgIDAuMjI0NjM5ICAg ICAgICAwLjEzMjEzDQo1ICAgICAgICAgICAgICAgMjguNjAwMiAgICAgICAgIDQwLjU3NTQg ICAgICAgICAxMS4zMjUzDQo2ICAgICAgICAgICAgICAgMTE4LjA3ICAgICAgICAgIDExNi44 NDEgICAgICAgICAxMTIuNTI1DQo3ICAgICAgICAgICAgICAgMjIyLjYwOCAgICAgICAgIDIw Mi4xNyAgICAgICAgICAyNDAuMDI5DQo4ICAgICAgICAgICAgICAgMzI3LjE3MiAgICAgICAg IDI4Ny41MTMgICAgICAgICAzNjcuNTY5DQo5ICAgICAgICAgICAgICAgNDMxLjc0NiAgICAg ICAgIDM3Mi44NjYgICAgICAgICA0OTUuMTIzDQoxMCAgICAgICAgICAgICAgNTM2LjMyOCAg ICAgICAgIDQ1OC4yMjMgICAgICAgICA2MjIuNjg1DQpbUHVsbHVwXQ0KLTEwICAgICAgICAg ICAgICA1NTEuMTM3ICAgICAgICAgNDczLjkwNCAgICAgICAgIDYzNi42NQ0KLTkgICAgICAg ICAgICAgICA0NDQuMzc4ICAgICAgICAgMzg2LjM2ICAgICAgICAgIDUwNi45MjINCi04ICAg ICAgICAgICAgICAgMzM3LjYyICAgICAgICAgIDI5OC44MTggICAgICAgICAzNzcuMTk3DQot NyAgICAgICAgICAgICAgIDIzMC44NjYgICAgICAgICAyMTEuMjc5ICAgICAgICAgMjQ3LjQ3 Ng0KLTYgICAgICAgICAgICAgICAxMjQuMTIgICAgICAgICAgMTIzLjc0NiAgICAgICAgIDEx Ny43NjUNCi01ICAgICAgICAgICAgICAgMzIuNDQzMiAgICAgICAgIDQ1LjMxMzIgICAgICAg ICAxMy4zODU2DQotNCAgICAgICAgICAgICAgIDAuMDg0MzYxNyAgICAgICAxLjg4ODA2ICAg ICAgICAgMC4xMzk3ODkNCi0zICAgICAgICAgICAgICAgMC4wNjY5OTU2ICAgICAgIDAuMDMw OTYzNiAgICAgICAwLjEzMTY2Ng0KLTIgICAgICAgICAgICAgICAwLjA1ODQ2NjEgICAgICAg MC4wMjczMTkzICAgICAgIDAuMTE0MDU2DQotMSAgICAgICAgICAgICAgIDAuMDM4Mzk0NyAg ICAgICAwLjAxOTQyNTggICAgICAgMC4wNjk4NzQ0DQowICAgICAgICAgICAgICAgLTAuMDAx NjE0ODIgICAgICAtMC4wMDE2MjY0NiAgICAgIC0wLjAwMTQyNzg4DQoxICAgICAgICAgICAg ICAgLTAuMDU2MzQxOSAgICAgICAtMC4wMzU2NjUyICAgICAgIC0wLjA4NzI1OTgNCjIgICAg ICAgICAgICAgICAtNDkuNTM4ICAgICAgICAgIC00MC42MTI4ICAgICAgICAgLTYxLjc1NDkN CjMgICAgICAgICAgICAgICAtMTQ5LjQ5ICAgICAgICAgIC0xMTYuODk0ICAgICAgICAgLTE4 OS4wNzkNCjQgICAgICAgICAgICAgICAtMjUzLjk5NCAgICAgICAgIC0yMDIuMTg2ICAgICAg ICAgLTMxNi41NTcNCjUgICAgICAgICAgICAgICAtMzU4LjQ2NSAgICAgICAgIC0yODcuNDc1 ICAgICAgICAgLTQ0My45NTUNCg0KW0dORF9jbGFtcF0NCiAwLjB2ICAgICAgICAgICAgIDAu MG0gIE5BICAgICAgTkENCi0wLjV2ICAgICAgICAgICAtMTAuMG0gIE5BICAgICAgTkENCi0w Ljd2ICAgICAgICAgICAtMjAuMG0gIE5BICAgICAgTkENCi01LjB2ICAgICAgICAgIC00MDAu MG0gIE5BICAgICAgTkENCltQT1dFUl9jbGFtcF0NCiAwLjB2ICAgICAgICAgICAgIDAuMG0g IE5BICAgICAgTkENCi0wLjV2ICAgICAgICAgICAgMTAuMG0gIE5BICAgICAgTkENCi0wLjd2 ICAgICAgICAgICAgMjAuMG0gIE5BICAgICAgTkENCi01LjB2ICAgICAgICAgICA0MDAuMG0g IE5BICAgICAgTkENCg0KDQpbUmFtcF0NCg0KZFYvZHRfciAgICAgICAgICAgIDIuNS8yLjVu ICAgICAgICAyLjAvMy44biAgICAgICAgMi41LzEuMG4NCmRWL2R0X2YgICAgICAgICAgICAy LjIvMi4zbiAgICAgICAgMS43LzQuNG4gICAgICAgIDIuNC8wLjhuDQoNCltSaXNpbmcgV2F2 ZWZvcm1dDQpSX2ZpeHR1cmU9NTAwDQpWX2ZpeHR1cmU9My4zDQpWX2ZpeHR1cmVfbWluPTMu MA0KVl9maXh0dXJlX21heD0zLjYNCkNfZml4dHVyZT01MHANCkxfZml4dHVyZT0xMG4NCjFF LTA5ICAgICAgICAgICAxLjY2NDc0RS0wOCAgICAgNy41NDMwMkUtMDggICAgIC0yLjk0OTA4 RS0wNw0KMS41RS0wOSAgICAgICAgIC04LjY4OTMzRS0wNyAgICAxLjQ4NDg5RS0wNyAgICAg LTEuMzY3NTdFLTA2DQoyRS0wOSAgICAgICAgICAgLTEuNzczOTlFLTA2ICAgIC01LjA5MTQ0 RS0wNyAgICAtMS43ODg2N0UtMDYNCjIuNUUtMDkgICAgICAgICAtMS44MDE4NEUtMDYgICAg LTIuMTI1NzdFLTA2ICAgIC0zLjM4MjA1RS0wNg0KM0UtMDkgICAgICAgICAgIDMuMjU2NjZF LTA2ICAgICAtMS4zNzMyNEUtMDYgICAgLTAuMDAwMjQzMDQzDQozLjVFLTA5ICAgICAgICAg LTQuNDQ0NTZFLTA1ICAgIC0xLjc4OTg2RS0wNyAgICAwLjAwNzA3NDYNCjRFLTA5ICAgICAg ICAgICAtMC4wMDAxNjMzODUgICAgMi41OTU3MUUtMDYgICAgIDAuMzYxOTk2DQo0LjVFLTA5 ICAgICAgICAgLTAuMDAxMjU1MTMgICAgIDguNTg2MDNFLTA2ICAgICAxLjQyNzUzDQo1RS0w OSAgICAgICAgICAgMC4wMDAzMjYxMzEgICAgIDEuODM0MjVFLTA1ICAgICAyLjYxNjMxDQo1 LjVFLTA5ICAgICAgICAgMC4xMjM3NjkgICAgICAgIDMuNTY4MDlFLTA1ICAgICAzLjQyMjA3 DQo2RS0wOSAgICAgICAgICAgMC41NjExMjMgICAgICAgIDUuMDY5NEUtMDUgICAgICAzLjgx NzU5DQo2LjVFLTA5ICAgICAgICAgMS4xNzQxICAgICAgICAgIC0wLjAwMDIxMjU3OCAgICAz Ljg5OTAyDQo3RS0wOSAgICAgICAgICAgMS43MjYyOCAgICAgICAgIC0wLjAwMTk0NTE4ICAg ICAzLjc5NDY4DQo3LjVFLTA5ICAgICAgICAgMi4xNTYwOCAgICAgICAgIC0wLjAwNTI2Mjky ICAgICAzLjYyODgNCjhFLTA5ICAgICAgICAgICAyLjUyNzg3ICAgICAgICAgMC4wMDMyMzY3 ICAgICAgIDMuNDk0OTENCjguNUUtMDkgICAgICAgICAyLjgxMDQ5ICAgICAgICAgMC4wNzA0 ODUyICAgICAgIDMuNDM0DQo5RS0wOSAgICAgICAgICAgMy4wMTQxNyAgICAgICAgIDAuMjIw MjQ3ICAgICAgICAzLjQzMjI2DQo5LjVFLTA5ICAgICAgICAgMy4xMjU4NyAgICAgICAgIDAu NDM5ODg4ICAgICAgICAzLjQ2OA0KMUUtMDggICAgICAgICAgIDMuMTczNDUgICAgICAgICAw LjY3NzI3MSAgICAgICAgMy41MDc5Mw0KMS4wNUUtMDggICAgICAgIDMuMTk5NDMgICAgICAg ICAwLjkxOTM5MiAgICAgICAgMy41MzU2OA0KMS4xRS0wOCAgICAgICAgIDMuMTk4NDMgICAg ICAgICAxLjE3MTk4ICAgICAgICAgMy41NDcwOA0KMS4xNUUtMDggICAgICAgIDMuMTk2NDgg ICAgICAgICAxLjQyODY3ICAgICAgICAgMy41NDMyMQ0KMS4yRS0wOCAgICAgICAgIDMuMTkw OTkgICAgICAgICAxLjY3MjQ5ICAgICAgICAgMy41MzUyDQoxLjI1RS0wOCAgICAgICAgMy4x ODc5NiAgICAgICAgIDEuODg3MzMgICAgICAgICAzLjUyNzY5DQoxLjNFLTA4ICAgICAgICAg My4xODY3NiAgICAgICAgIDIuMDgwNjkgICAgICAgICAzLjUyMDk5DQoxLjM1RS0wOCAgICAg ICAgMy4xODc0ICAgICAgICAgIDIuMjQ5MzUgICAgICAgICAzLjUxNzIyDQoxLjRFLTA4ICAg ICAgICAgMy4xODgwOSAgICAgICAgIDIuMzkzNiAgICAgICAgICAzLjUxNzE2DQoxLjQ1RS0w OCAgICAgICAgMy4xODg2NiAgICAgICAgIDIuNDk5OTkgICAgICAgICAzLjUxOTUxDQoxLjVF LTA4ICAgICAgICAgMy4xODkwMyAgICAgICAgIDIuNTg0NTQgICAgICAgICAzLjUyMTY3DQox LjU1RS0wOCAgICAgICAgMy4xODkyNCAgICAgICAgIDIuNjQ3NTQgICAgICAgICAzLjUyMzEx DQoxLjZFLTA4ICAgICAgICAgMy4xODkzICAgICAgICAgIDIuNjk0MjMgICAgICAgICAzLjUy MzQNCjEuNjVFLTA4ICAgICAgICAzLjE4OTM0ICAgICAgICAgMi43MzQwMSAgICAgICAgIDMu NTIzNTUNCjEuN0UtMDggICAgICAgICAzLjE4OTM1ICAgICAgICAgMi43NTkzICAgICAgICAg IDMuNTIzNDQNCjEuNzVFLTA4ICAgICAgICAzLjE4OTM2ICAgICAgICAgMi43ODQ1OCAgICAg ICAgIDMuNTIzMzINCjEuOEUtMDggICAgICAgICAzLjE4OTM4ICAgICAgICAgMi43OTUxOCAg ICAgICAgIDMuNTIzMjENCjEuODVFLTA4ICAgICAgICAzLjE4OTM5ICAgICAgICAgMi44MDU3 MiAgICAgICAgIDMuNTIzMTMNCjEuOUUtMDggICAgICAgICAzLjE4OTM5ICAgICAgICAgMi44 MTYyNyAgICAgICAgIDMuNTIzMDQNCjEuOTVFLTA4ICAgICAgICAzLjE4OTQgICAgICAgICAg Mi44MjMzMSAgICAgICAgIDMuNTIyOTYNCjJFLTA4ICAgICAgICAgICAzLjE4OTQgICAgICAg ICAgMi44MjY4NCAgICAgICAgIDMuNTIyODgNCjIuMDVFLTA4ICAgICAgICAzLjE4OTQgICAg ICAgICAgMi44MjkyMSAgICAgICAgIDMuNTIyNzkNCjIuMUUtMDggICAgICAgICAzLjE4OTQg ICAgICAgICAgMi44MzExOSAgICAgICAgIDMuNTIyNzENCjIuMTVFLTA4ICAgICAgICAzLjE4 OTQgICAgICAgICAgMi44MzIzMSAgICAgICAgIDMuNTIyNzINCjIuMkUtMDggICAgICAgICAz LjE4OTQxICAgICAgICAgMi44MzMxNCAgICAgICAgIDMuNTIyNzgNCjIuMjVFLTA4ICAgICAg ICAzLjE4OTQyICAgICAgICAgMi44MzM3OCAgICAgICAgIDMuNTIyODQNCg0KW0ZhbGxpbmcg V2F2ZWZvcm1dDQpSX2ZpeHR1cmU9NTAwDQpWX2ZpeHR1cmU9MA0KVl9maXh0dXJlX21pbj0w LjANClZfZml4dHVyZV9tYXg9MC4wDQpDX2ZpeHR1cmU9NTBwDQpMX2ZpeHR1cmU9MTBuDQox RS0wOSAgICAgICAgICAgMy4zICAgICAgICAgICAgIDMgICAgICAgICAgICAgICAzLjYNCjEu NUUtMDkgICAgICAgICAzLjMgICAgICAgICAgICAgMyAgICAgICAgICAgICAgIDMuNTk5OTkN CjJFLTA5ICAgICAgICAgICAzLjI5OTk5ICAgICAgICAgMyAgICAgICAgICAgICAgIDMuNg0K Mi41RS0wOSAgICAgICAgIDMuMyAgICAgICAgICAgICAyLjk5OTk5ICAgICAgICAgMy41OTk5 OQ0KM0UtMDkgICAgICAgICAgIDMuMzAwMDEgICAgICAgICAzICAgICAgICAgICAgICAgMy41 OTk2NQ0KMy41RS0wOSAgICAgICAgIDMuMjk5ODUgICAgICAgICAzICAgICAgICAgICAgICAg My41MDcwOA0KNEUtMDkgICAgICAgICAgIDMuMjk5NTggICAgICAgICAzICAgICAgICAgICAg ICAgMi43ODIzOQ0KNC41RS0wOSAgICAgICAgIDMuMjk5MTUgICAgICAgICAzICAgICAgICAg ICAgICAgMS41OTM3NQ0KNUUtMDkgICAgICAgICAgIDMuMjIyNDMgICAgICAgICAyLjk5OTk5 ICAgICAgICAgMC42MjAyODMNCjUuNUUtMDkgICAgICAgICAyLjgzMDg5ICAgICAgICAgMi45 OTk5NyAgICAgICAgIDAuMDAyMjQ0MDkNCjZFLTA5ICAgICAgICAgICAyLjI1NjU4ICAgICAg ICAgMi45OTk5OCAgICAgICAgIC0wLjI4MDc0OQ0KNi41RS0wOSAgICAgICAgIDEuNzMyNjMg ICAgICAgICAzICAgICAgICAgICAgICAgLTAuMzAyNDg2DQo3RS0wOSAgICAgICAgICAgMS4y MzczNiAgICAgICAgIDIuOTk5OTUgICAgICAgICAtMC4xNTY3DQo3LjVFLTA5ICAgICAgICAg MC43NjQ5MjcgICAgICAgIDIuOTg0MjQgICAgICAgICAwLjAyMTMwNg0KOEUtMDkgICAgICAg ICAgIDAuNDA1NDU1ICAgICAgICAyLjg4NTk5ICAgICAgICAgMC4xNDUzNjENCjguNUUtMDkg ICAgICAgICAwLjE5NTI3MyAgICAgICAgMi42OTUwOSAgICAgICAgIDAuMTgyMzg0DQo5RS0w OSAgICAgICAgICAgMC4wOTQzNTU2ICAgICAgIDIuNDc1NDEgICAgICAgICAwLjE2MTg3DQo5 LjVFLTA5ICAgICAgICAgMC4wNjY4ODg2ICAgICAgIDIuMjExNjQgICAgICAgICAwLjExMDkx Nw0KMUUtMDggICAgICAgICAgIDAuMDcwMDUwNSAgICAgICAxLjkxODQ1ICAgICAgICAgMC4w NjY1NjENCjEuMDVFLTA4ICAgICAgICAwLjA4MjkzOTggICAgICAgMS42MjU2OCAgICAgICAg IDAuMDQwNzA5Mg0KMS4xRS0wOCAgICAgICAgIDAuMDkzMjMzNiAgICAgICAxLjM1NTY2ICAg ICAgICAgMC4wMzgzMjc5DQoxLjE1RS0wOCAgICAgICAgMC4wOTc4OTM3ICAgICAgIDEuMTA4 NzggICAgICAgICAwLjA0ODI5MzINCjEuMkUtMDggICAgICAgICAwLjA5ODM4NDkgICAgICAg MC44NzUxMzUgICAgICAgIDAuMDYyMzM5DQoxLjI1RS0wOCAgICAgICAgMC4wOTY1NTM5ICAg ICAgIDAuNjcyNDg4ICAgICAgICAwLjA3NDUwMQ0KMS4zRS0wOCAgICAgICAgIDAuMDk0NzYy NiAgICAgICAwLjUyMzE2OCAgICAgICAgMC4wODA4NDEyDQoxLjM1RS0wOCAgICAgICAgMC4w OTM0Mzk3ICAgICAgIDAuNDA4MTY5ICAgICAgICAwLjA4MDIxMjkNCjEuNEUtMDggICAgICAg ICAwLjA5MjkwNjggICAgICAgMC4zMjM5MTEgICAgICAgIDAuMDc1NzM5OA0KMS40NUUtMDgg ICAgICAgIDAuMDkzMTQxNSAgICAgICAwLjI2MzM0OSAgICAgICAgMC4wNzEyODM2DQoxLjVF LTA4ICAgICAgICAgMC4wOTM0MDA5ICAgICAgIDAuMjE5NTM5ICAgICAgICAwLjA2ODc3MzkN CjEuNTVFLTA4ICAgICAgICAwLjA5MzU4MDIgICAgICAgMC4xOTIyMzIgICAgICAgIDAuMDY3 ODI4OA0KMS42RS0wOCAgICAgICAgIDAuMDkzNjI1MiAgICAgICAwLjE3MjQ1NyAgICAgICAg MC4wNjgxNDEyDQoxLjY1RS0wOCAgICAgICAgMC4wOTM2NTM4ICAgICAgIDAuMTYwNzU0ICAg ICAgICAwLjA2ODgyOTcNCjEuN0UtMDggICAgICAgICAwLjA5MzY1MDIgICAgICAgMC4xNTIz NTUgICAgICAgIDAuMDY5NzYwMQ0KMS43NUUtMDggICAgICAgIDAuMDkzNjQ2NiAgICAgICAw LjE0Mzk1NSAgICAgICAgMC4wNzA1NTM0DQoxLjhFLTA4ICAgICAgICAgMC4wOTM2NDMgICAg ICAgIDAuMTM4OTExICAgICAgICAwLjA3MDY3MzcNCjEuODVFLTA4ICAgICAgICAwLjA5MzYz OTQgICAgICAgMC4xMzYzOTQgICAgICAgIDAuMDcwNzk0DQoxLjlFLTA4ICAgICAgICAgMC4w OTM2MzE4ICAgICAgIDAuMTM0NzI1ICAgICAgICAwLjA3MDkxNDMNCjEuOTVFLTA4ICAgICAg ICAwLjA5MzYyMjIgICAgICAgMC4xMzM3NDQgICAgICAgIDAuMDcwNzMyNw0KMkUtMDggICAg ICAgICAgIDAuMDkzNjEyNiAgICAgICAwLjEzMjkxNiAgICAgICAgMC4wNzAzNzMyDQoyLjA1 RS0wOCAgICAgICAgMC4wOTM2MDMgICAgICAgIDAuMTMyNDg2ICAgICAgICAwLjA3MDAxMzcN CjIuMUUtMDggICAgICAgICAwLjA5MzU5MzUgICAgICAgMC4xMzIwNTYgICAgICAgIDAuMDY5 NjU0MQ0KMi4xNUUtMDggICAgICAgIDAuMDkzNTg4OCAgICAgICAwLjEzMTgxNiAgICAgICAg MC4wNjk3MDY1DQoyLjJFLTA4ICAgICAgICAgMC4wOTM1ODc5ICAgICAgIDAuMTMxNjYxICAg ICAgICAwLjA2OTg4MTcNCjIuMjVFLTA4ICAgICAgICAwLjA5MzU4OCAgICAgICAgMC4xMzE1 NTEgICAgICAgIDAuMDcwMDYwNw0KMi4zRS0wOCAgICAgICAgIDAuMDkzNTg4MiAgICAgICAw LjEzMTQ3NCAgICAgICAgMC4wNzAxNjg1DQoNCg0KW0VuZF0NCg== --------------9F935E63637944FA62032BC9-- From owner-ibis Fri Nov 12 13:22:48 1999 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA22852; Fri, 12 Nov 1999 13:22:48 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id PAA04791; Fri, 12 Nov 1999 15:22:17 -0600 (CST) Received: from smtp2.molex.com(150.150.15.101) by molexinc-bh.molex.com via smap (4.1) id xma004698; Fri, 12 Nov 99 15:21:24 -0600 Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 000750D7; Fri, 12 Nov 99 15:18:46 +0000 Mime-Version: 1.0 Date: Fri, 12 Nov 1999 15:18:15 +0000 Message-ID: <000750D7.CE21031@molex.com> Subject: Re:IBIS-X proposal To: ibis@eda.org, ibis-users@eda.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Stephen and other "IBISians" For what it is worth.... When I initially started with the IBISCnn specification (IBISCnn = IBIS Connector Specification).... I really tried to incorporate a nodal methods. And, for what it is worth, I still think it would be a powerful addition. However, at the time (and maybe still) there seemed to be a lot of resistance to incorporating a "SPICE deck like approach" in the IBIS specification. Further, I really like the inclusion of the PWR/GND (or maybe more specifically, current return path) references. For what it is worth, these have been included in the IBISCnn specification (soon to be available for your critical reviews). As such, after IBISCnn is available, I would greatly appreciate your comments. If it would help the group, I would also suggest that the IBISCnn RLCs interconnection metodology may address Stephans: "package model consisting of a network of R/L/Cs (a SPICE like description). Therefore, the IBIS-X proposal allows the guts of a model to be a nodal network consisting of passive components". As such, maybe it may also be possible to represent " some basic independent and dependent sources" in the same "matrix" format. Also, it is important to know that the IBISCnn specification does incorporate "NO GROUND" models. Unfortunately, this functionality is lost if a simulator insists on having "perfect ground" reference points on both sides of a connector. Best Regards, _gus ____________________Reply Separator____________________ Subject: IBIS-X proposal Author: Stephen Peters Date: 11/12/99 12:42 PM Hello All: At the recent IBIS summit there was a fair amount of discussion regarding the future of IBIS. Among the issues the IBIS community has been wrestling with are: 1. the growth in complexity of the specification, 2. support for power/gnd and return path modeling 3. receiver modeling, and 4. the need for a general escape mechanism that allows simulators to incorporate user created models (models that the simulator may not otherwise support). So far, there has been a proposal for incorporating an API (application programming interface) into IBIS, which addresses point four above. However, to fully support an API I belive that the current IBIS description would have to change. Specifically, models would have to become multi-ported entities with explicit power and ground ports tied to component pins. In fact, I belive to in order to fully address the problems of complexity (added keywords for every new type of buffer) and return path modeling there needs to be a new, general buffer description language, one that supports IBIS type simulators but also allows a model to be used directly by a circuit simulator. To that end I'm making a proposal called IBIS-X. I am aware that this is a fairly radical proposal (for example, it is not backwards compatible with the existing IBIS specification), but I belive it does address directly both the needs of those producing models as well as those designing high speed electrical interconnects. Please look it over and make your comments. This will be on the agenda at the next IBIS phone conference. Best Regards, Stephen Peters Intel Corp. From owner-ibis Fri Nov 12 14:31:07 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 OAA23064 for ; Fri, 12 Nov 1999 14:31:07 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA29589; Fri, 12 Nov 1999 14:30:07 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA26811; Fri, 12 Nov 1999 14:30:06 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <382C94ED.AB216E5B@mentor.com> Date: Fri, 12 Nov 1999 14:30:05 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Agenda 11/19/99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 11/19/99 Bridge Number Reservation # Passcode (916) 356-9200 2-356763 7473493 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) Perrin - JEDEC JC-16.2 Modeling and Testing Sessions DesignCon2000 IBIS Summit Planning Ross/Schwartz DATE2000 IBIS Summit Planning Ross S2ibis3 Committee Activities Cohen IBIS Dues and Funding Voting Ross New IBIS Officer Postions Voting Ross Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 9:00 Technical Discussion BUG34 - No Error Reported for Missing V/I Tables Flora in Output Buffers BIRD61 - Enhanced Characterization of Receivers Peters BIRD62 - Enhanced Chararcterization of Receiver Peters Thresholds BIRD63 - Documentation of Receiver Setup and Hold Peters Timing Conditions BIRD64 - Package Model Selector Muranyi BIRD65 - C_comp Refinements Muranyi Other Proposals (IBIS-X, API, etc.) Peters/Muranyi Connector Proposal Status Panella New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Fri Nov 12 12:50:02 1999 Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA22676; Fri, 12 Nov 1999 12:49:58 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id NAA11198; Fri, 12 Nov 1999 13:00:09 -0800 (PST) Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35]) by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id MAA09157; Fri, 12 Nov 1999 12:49:25 -0800 (PST) Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1]) by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id MAA08505; Fri, 12 Nov 1999 12:42:06 -0800 (PST) Message-Id: <199911122042.MAA08505@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: IBIS-X proposal Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Nov 1999 12:42:05 -0800 From: Stephen Peters Hello All: At the recent IBIS summit there was a fair amount of discussion regarding the future of IBIS. Among the issues the IBIS community has been wrestling with are: 1. the growth in complexity of the specification, 2. support for power/gnd and return path modeling 3. receiver modeling, and 4. the need for a general escape mechanism that allows simulators to incorporate user created models (models that the simulator may not otherwise support). So far, there has been a proposal for incorporating an API (application programming interface) into IBIS, which addresses point four above. However, to fully support an API I belive that the current IBIS description would have to change. Specifically, models would have to become multi-ported entities with explicit power and ground ports tied to component pins. In fact, I belive to in order to fully address the problems of complexity (added keywords for every new type of buffer) and return path modeling there needs to be a new, general buffer description language, one that supports IBIS type simulators but also allows a model to be used directly by a circuit simulator. To that end I'm making a proposal called IBIS-X. I am aware that this is a fairly radical proposal (for example, it is not backwards compatible with the existing IBIS specification), but I belive it does address directly both the needs of those producing models as well as those designing high speed electrical interconnects. Please look it over and make your comments. This will be on the agenda at the next IBIS phone conference. Best Regards, Stephen Peters Intel Corp. ----------- cut here ----------- The following is a proposal for a new format to be used for creating and specifying I/O buffer models. This format is an evolution of the current IBIS description, and provides a couple of fundamental enhancements when compared with the current specification. Specifically: a) IBIS-X provides for much greater flexibility in model descriptions. Buffers can be described using either the traditional IBIS prototype model or the user may create their own buffer model by using a set of passive and behavioral elements connected together nodally. Nodal descriptions provide a direct path into circuit simulators, and nodal descriptions are also used to build arbitrary package models around a buffer. b) IBIS-X provides support for return path modeling. Component power and gnd pins are connected directly to a model instance, thus allowing true system level simulations that incorporate board decoupling effects, ground return effects, etc. c) The IBIS-X proposal provides the necessary hooks that enable simulators to incorporate an external models thru an API. IBIS-X COMPARED TO IBIS As with the original IBIS specification, the IBIS-X description is targeted towards transmission line and board level SI simulators. To this end IBIS-X sticks with the "component centric" format -- each pin of a component is listed, and pins are attached to a model witch can be used over and over again. Furthermore, each pin (model) is explicitly declared as a driver or receiver and each model contains the 'data book' information (timing test loads, Vinh/Vinl, etc.) that allows for automatic SI and flight time analysis. The biggest difference is that the IBIS-X description allows a buffer/receiver model to connect not just to an I/O pin, but also to power/gnd pin(s). It does this by making the [Model] a multi-port entity. By allowing a model to have explicit power ports a circuit type simulator (or an enhanced behavioral simulator) can modulate the power and ground rails of a behavioral model, thus incorporating the effects of board level power distribution (including ground return paths) into a simulation (i.e. enables true system level simulation). As mentioned above, the IBIS-X spec allows the model maker a choice of descriptions. Model makers should be able to model a driver or receiver to the level of detail required and/or appropriate. Traditional I/V,V/T descriptions are still very useful and the IBIS-X proposal fully supports a pure behavioral description of an driver or receiver. In other cases, the user may want to model a buffer behaviorally, but surround the buffer with a package model consisting of a network of R/L/Cs (a SPICE like description). Therefore, the IBIS-X proposal allows the guts of a model to be a nodal network consisting of passive components, some basic independent and dependent sources, and submodels. In turn, a submodel can consist of behavioral descriptions, nodal networks, more submodels, or a coupling matrix (used to describe pin coupling). By using a approach based on nodal description and submodels, it should be straightforward to incorporate a package model around a buffer, or to group buffers together to simulation SSO effects, etc. Finally, the IBIS-X proposal prepares the way for a behavioral simulator to execute transistor level models by allowing a model or submodel to call an external model which is executed via an API. I should point out that adding an API to the existing IBIS specification is possible, but to make it useful there still needs to be some mechanism to define/declare a multi-port model and associate those ports with the various [Voltage] keywords of the current spec and the pins of the component. ========= Details, and a shot at syntax ============== FILE HEADER The file header info remains pretty much the same as in the current IBIS spec. [Template Version] version # [Comment Char] | by default [File Name] file name.ibx [Date] date [Source] ASCII text [Notes] ASCII text [Disclaimer] ASCII text [Copyright] ASCII text COMPONENT SECTION The major function of the component section is to map the component pins to a model. However, instead of calling out just a model the [Pin] keyword connects pins to a specific port on a model. The [Model Selector] functionality is retained, along with the [Diff Pin] keyword. However, the [Diff Pin] keywords function has been changed to list only skew between differential outputs only. (Note: To aid parsing each "section" of the spec begins with a [Begin "Section Name"] keyword and ends with an [End "Section Name"] keyword. [Begin Component] [Component] component name [Manufacture] manufactures name [Pin] pin_name signal_name model_name port_name R_pin L_pin C_pin (Note: only a *model_name* is allowed, not a submodel name. To support IBIS compatible descriptions NC, PWR and GND are legal pin connections, and a generic R_pin, L_pin and C_pin can be included.) [Diff Pin] inverting_pin non_inverting skew_typ skew_typ skew_max [Model Selector] [End Component] MODEL SECTION The purpose of the model section is to identify the top model type (input, output, bidir, etc.), list the data book specs that support SI simulators and board level timing products (timing test loads, input parameters, etc.), define the ports of the model and finally, provide a place to put the guts of a model. [Begin Model] model_name model_type = select from list C_comp* = I/O capacitance value [Temperature_Range] typ min max [Pullup Reference] typ min max [Pulldown Reference] typ min max [POWER Clamp Reference] typ min max [GND Clamp Reference] typ min max [Receiver Reference] type min max (The voltage range keywords are used a bit differently than in IBIS. These keywords indicate the voltage at the associated model port. For a traditional behavioral simulator these value still end up being the references for the I/V curves. For an IBIS-X simulator they would be a fixed voltage at the pins, and a structural description can be used to put a package model in between the pin (port) and the buffer model itself. For a pure SPICE simulator (where the board level power distribution is modeled) these keywords serve mostly as documentation.) [Driver Spec] (timing test loads, Vmeas, etc. Use if a model is an output or I/O) [Receiver Spec] (input thresholds, overshoot/undershoot thresholds, etc. Use if a model is a receiver or I/O) [Port list] port_name port_type (port types are: primary_io | primary I/O pin pullup_ref | power connection pin pulldown_ref | power connection pin pwrclamp_ref | power connection pin gndclamp_ref | power connection pin rcvr_ref | power connection pin gnd | reference pin ctl | a digital (1/0) control pin analog | an analog control pin stim_in | external stimulus (not a component pin) recevier_out | output of a receiver (not a component pin) ) [Begin Model Description] description_type = behavioral | structural (put the guts of the model here) [End Model Description] [End Model] MODEL DESCRIPTIONS A model can be described in one of three forms: A conventional behavioral (IBIS) description, a nodal description that interconnects submodels and passive components, or a call to an external file. For a traditional IBIS description, the following keywords are supported (initial list). [Pullup]/[Pulldown]/[POWER Clamp]/[GND Clamp] [Rising Waveform]/[Falling Waveform] [Ramp] [TTgnd]/[TTpower] [Driver Schedule] (replace by IBIS submodel mechanism?) [Add Submodel] [SubModel] (Note: The keywords that support series switches, series devices, or terminator networks have not been included. Given that these devices are adequately supported in IBIS, or could be described using a circuit description, I have not included them in the initial list.) A nodal description connects passive components, submodels and independent voltage and current sources together. Transistors are not supported, but a general three terminal device is included. Syntax would be some most common denominator of the existing SPICE variants. Rxxx node1 node2 value= explicit value or equation (resistance) Lxxx node1 node2 value= explicit value or equation (inductance) Cxxx node1 node2 value= explicit value or equation (capacitance) Vxxx node1 node2 value= explicit value, equation or table (V source) Ixxx node1 node2 value= explicit value, equation or table (I source) Sxxx node1 node2 node3 value = equation or table(s) (three terminal device) Xxxx port1=>node1, port2=>node2, ...parameter1=>value,... (submodel) Finally, the guts of a model (or a submodel in a nodal or IBIS description) could be a call to an externally defined model that the simulator executes via an API (applications programming interface). The syntax of the call has yet to be worked out, but one would expect something like Xxxx port1=>node1, port2=>port2,... parameter1=>"path to model file", ...) One question that has been puzzling me is the mechanism used to apply stimulus to the external model. Does the simulator simply flip the stim_in node from '0' to '1', or does the user have to attach an explicit stimulus source? SUBMODELS Submodels are used both by behavioral descriptions ([Submodel] statements) and nodal descriptions (Xxxx calls). Submodels are a lot like top level [Models], but they do not include any of the top level simulation information nor can they connect directly to a component pin. Again, behavioral, structural and calls to external models are supported. In addition, a submodel can support a matrix type description of a passive network. [Begin Submodel] submodel_name description_type = behavioral | structural | matrix [Port List] (port name, but do we need a description??) (put description of submodel here) [End Submodel] [End] From owner-ibis Sat Nov 13 13:47:13 1999 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA28682 for ; Sat, 13 Nov 1999 13:47:13 -0800 (PST) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id NAA07575; Sat, 13 Nov 1999 13:46:40 -0800 (PST) Message-Id: <199911132146.NAA07575@pop.nwlink.com> Received: from KELLEE98 by ip210.c246.blk1.bel.nwlink.com via smtpd (for mail.nwlink.com [209.20.130.40]) with SMTP; 13 Nov 1999 21:48:35 UT X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sat, 13 Nov 1999 13:46:37 -0800 To: ibis@eda.org, apanella@molex.com, kellee@hyperlynx.com From: Kellee Crisafulli Subject: IBIS connector specification released to open forum In-Reply-To: <382C94ED.AB216E5B@mentor.com> 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 NAA28683 Hi IBIS fans, The IBIS connector sub-group today completed work on the final draft of the connector specification V0.92. I forwarded the specification along with a changes document to Syed to have it placed on the IBIS web site. Please accept this email as the official notification from the connector sub-group to the IBIS open forum that we are releasing the connector specification to you. I chose not to send the entire specification to the whole IBIS group as it is around 1600 lines long. It should be available to the general public as soon as Syed can get it put on the web site. NOTICE: This is not a released specification! This version is the release from the sub-group to the full group. What remains to be done: 1) Full open forum must comment and changes if any included in the document. 2) It must be voted on and approved by the open forum. 3) A Golden parser must be written to insure that models developed have no syntax errors. Along with this development the existing golden example models provided by the connector sub group must be improved to comply with the current specification. 4) Existing connector model creation and simulation methods should be enhanced to support the new IBIS connector format. This might effect connector manufacturers as well as CAE tool suppliers. This is the end of a nearly 2 year project for the people involved. I know many of you will not be 100% happy with the result but please don't forget that we are a large group and must forge a result that is acceptable to the majority. Also consider that this specification is long over due and it is the 2nd attempt by the IBIS group to create a connector specification. So please be gentle in your criticism .... Please direct your comments to the normal IBIS reflector both Gus and I will be watching for your questions and will do our best to answer them. best wishes... Kellee Crisafulli, PADS software/Hyperlynx Gus Panella, Mollex *************************************************************** Members of the IBIS connector sub-group and others that have assisted with developing with this specification. Eric Bogatin, Ansoft/Bogatin Enterprises Steve Chau, AMP Kellee Crisafulli, PADS software/HyperLynx John Ellis, Berg Mark Gailus, Teradyne Fran Hart, Dell Bob Haller, Compaq Jay Diepenbrock, IBM Mikhail Khusid, Teradyne Igor Kochikov, PADS software/HyperLynx Gus Panella, Mollex Inc. Katie Rothstein, Teradyne Guy de Burgh, Viewlogic Systems Jeff Walden, AMP/Foxconn Fabrizio Zanella, EMC corp --------------------------------------------------------- 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 Mon Nov 15 13:25:10 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 NAA05533; Mon, 15 Nov 1999 13:25:10 -0800 (PST) Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA10261; Mon, 15 Nov 1999 13:24:08 -0800 (PST) Message-Id: <199911152124.NAA10261@jasper.cisco.com> Date: Mon, 15 Nov 1999 13:24:07 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: IBIS connector specification released to open forum To: ibis@eda.org, apanella@molex.com, kellee@hyperlynx.com Cc: ibis-users@eda.org, shuq@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: ECMkTI1XuoicW0eMQ77Uww== 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 NAA05534 The IBIS website has been updated with a link 'Connector Info' on the main page http://www.eia.org/eig/ibis/ibis.htm. Select the link. Then download the two document(ver 0.92): IbisConSpec_v092.txt IbisConUpdates_v092.txt Regards, Syed Webmaster Cisco Systems, Inc > > Hi IBIS fans, > > The IBIS connector sub-group today completed work > on the final draft of the connector specification V0.92. > > I forwarded the specification along with a changes document > to Syed to have it placed on the IBIS web site. > > Please accept this email as the official notification from > the connector sub-group to the IBIS open forum that we are > releasing the connector specification to you. > > I chose not to send the entire specification to the whole > IBIS group as it is around 1600 lines long. It should be > available to the general public as soon as Syed can get it > put on the web site. > > NOTICE: This is not a released specification! This version is > the release from the sub-group to the full group. > > What remains to be done: > > 1) Full open forum must comment and changes if any included > in the document. > 2) It must be voted on and approved by the open forum. > 3) A Golden parser must be written to insure that models developed > have no syntax errors. Along with this development the existing > golden example models provided by the connector sub group must be > improved to comply with the current specification. > 4) Existing connector model creation and simulation methods should > be enhanced to support the new IBIS connector format. > This might effect connector manufacturers as well as CAE tool suppliers. > > This is the end of a nearly 2 year project for the people involved. > I know many of you will not be 100% happy with > the result but please don't forget that we are a large group and > must forge a result that is acceptable to the majority. > Also consider that this specification is long over due and it is the > 2nd attempt by the IBIS group to create a connector specification. > So please be gentle in your criticism .... > > Please direct your comments to the normal IBIS reflector > both Gus and I will be watching for your questions > and will do our best to answer them. > > best wishes... > Kellee Crisafulli, PADS software/Hyperlynx > Gus Panella, Mollex > > *************************************************************** > Members of the IBIS connector sub-group and others that have > assisted with developing with this specification. > Eric Bogatin, Ansoft/Bogatin Enterprises > Steve Chau, AMP > Kellee Crisafulli, PADS software/HyperLynx > John Ellis, Berg > Mark Gailus, Teradyne > Fran Hart, Dell > Bob Haller, Compaq > Jay Diepenbrock, IBM > Mikhail Khusid, Teradyne > Igor Kochikov, PADS software/HyperLynx > Gus Panella, Mollex Inc. > Katie Rothstein, Teradyne > Guy de Burgh, Viewlogic Systems > Jeff Walden, AMP/Foxconn > Fabrizio Zanella, EMC corp > > --------------------------------------------------------- > 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 Tue Nov 16 17:45:54 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 RAA14124 for ; Tue, 16 Nov 1999 17:45:53 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA01295; Tue, 16 Nov 1999 17:44:51 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA27214; Tue, 16 Nov 1999 17:44:49 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <38320891.38F2C957@mentor.com> Date: Tue, 16 Nov 1999 17:44:49 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS BIRD66 - [Model Spec] Vref Addition Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: This is officially issued as BIRD66. Bob Ross Mentor Graphics All, I would like to submit the following Bird on behalf of SiQual to modify the current [Model Spec]. It is attached below regards, scott Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com ****************************************************************************** ****************************************************************************** BIRD ID#: 66 ISSUE TITLE: [Model Spec] Vref Addition REQUESTER: Scott McMorrow, SiQual DATE SUBMITTED: November 15, 1999 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Vref may need to be different for min and max columns. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Changes and additions to the [Model Spec] keyword are shown by the |* lines to add Vref with typ-min-max values: |============================================================================= | Keyword: [Model Spec] | Required: No | Sub-Params: Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high, | S_overshoot_low, D_overshoot_high, D_overshoot_low, | D_overshoot_time, Pulse_high, Pulse_low, Pulse_time, Vmeas |* Vref | Description: The [Model Spec] keyword defines four columns under which | specification subparameters are defined. | | The following subparameters are defined: | Vinh Input voltage threshold high | Vinl Input voltage threshold low | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- | S_overshoot_high Static overshoot high voltage | S_overshoot_low Static overshoot low voltage | D_overshoot_high Dynamic overshoot high voltage | D_overshoot_low Dynamic overshoot low voltage | D_overshoot_time Dynamic overshoot time | Pulse_high Pulse immunity high voltage | Pulse_low Pulse immunity low voltage | Pulse_time Pulse immunity time | | Vmeas Measurement voltage for timing measurements |* Vref Timing specification test load voltage | | Usage Rules: [Model Spec] must follow all other subparameters under the | [Model] keyword. | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum be must be placed | on a single line and must be separated by at least one white | space or tab character. All four columns are required under | the [Model Spec] keyword. However, data is required only in | the typical column. If minimum and/or maximum values are not | available, the reserved word "NA" must be used indicating the | typical value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage Range settings. | | Unless noted below, each subparameter does not require having | any other subparameter. | | Vinh, Vinl rules: | | The threshold subparameter lines provide additional min and | max column values, if needed. The typ column values are still | required and would be expected to override the Vinh and Vinl | subparameter values specified elsewhere. Note: the syntax | rule that require inserting Vinh and Vinl under models remains | unchanged even if the values are defined under the [Model | Spec] keyword. | | To mimic a hysteresis effect, the values of Vinh and Vinl may | be interchanged such that the Vinl value is larger than the | Vinh value. However, simulators may process this information | differently or report an error. | | Vinh+, Vinh-, Vinl+, Vinl- rules: | | The four hysteresis subparmeters must all be defined before | the hysteresis threshold rules become effective. Otherwise | the standard threshold subparameters remain in effect. The | hysteresis thresholds shall be at the Vinh+ and Vinh- values | for a low-to-high transition, and at the Vinl+ and Vinl- | values for a high-to-low transition. | | S_overshoot_high, S_overshoot_low rules: | | The static overshoot subparameters provide the voltage values | for which the model is no longer guaranteed to function | correctly. | | D_overshoot_high, D_overshoot_low, D_overshoot_time rules: | | The dynamic overshoot values provide a time window during | which the overshoot may exceed the static overshoot limits | but be below the dynamic overshoot limits. D_overshoot_time | is required for dynamic overshoot testing. In addition, if | D_overshoot_high is specified, then S_overshoot_high is | necessary for testing beyond the static limit. Similarly, if | D_overshoot_low is specified, then S_overshoot_low is | necessary for testing beyond the static limit. | | Pulse_high, Pulse_low, Pulse_time rules: | | The pulse immunity values provide a time window during which | a rising pulse may exceed the nearest threshold value but | be below the pulse voltage value and still not cause the | input to switch. Pulse_time is required for pulse immunity | testing. A rising response is tested only if Pulse_high is | specified. Similarly, a falling response is tested only if | Pulse_low is specified. The rising response may exceed the | Vinl value, but remain below the Pulse_high value. | Similarly, the falling response may drop below the Vinh value, | but remain above the Pulse_low value. In either case the | input is regarded as immune to switching if the responses | are within these extended windows. If the hysteresis | thresholds are defined, then the rising response shall use | Vinh- as the reference voltage, and the falling response shall | use Vinl+ as the reference voltage. | | Vmeas rules: | | The Vmeas values under the [Model Spec] keyword override the | Vmeas entry elsewhere. |* |* Vref rules: |* The Vref values under the [Model Spec] keyword override the |* Vref entry elsewhere |----------------------------------------------------------------------------- [Model Spec] | Subparameter typ min max | | Thresholds | Vinh 3.5 3.15 3.85 | 70% of Vcc Vinl 1.5 1.35 1.65 | 30% of Vcc | | Vinh 3.835 3.335 4.335 | Offset from Vcc | Vinl 3.525 3.025 4.025 | for PECL | | Hysteresis | Vinh+ 2.0 NA NA | Overrides the Vinh- 1.6 NA NA | thresholds Vinl+ 1.1 NA NA Vinl- 0.6 NA NA | All 4 are required | | Overshoot | S_overshoot_high 5.5 5.0 6.0 | Static overshoot S_overshoot_low -0.5 NA NA D_overshoot_high 6.0 5.5 6.5 | Dynamic overshoot D_overshoot_low -1.0 -1.0 -1.0 | requires | | D_overshoot_time D_overshoot_time 20n 20n 20n | & static overshoot | | Pulse Immunity | Pulse_high 3V NA NA | Pulse immunity Pulse_low 0 NA NA | requires Pulse_time 3n NA NA | Pulse_time | | Timing Thresholds | Vmeas 3.68 3.18 4.68 | A 5 volt PECL | | example | |*** ADDED EXAMPLE BELOW: | Timing test load voltage reference example | Vref 1.25 1.15 1.35 | An SSTL-2 example | |*** END OF ADDED EXAMPLE |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDxx is issued because the Timing specification test load voltage value Vref defined under the [Model] keyword changes with the Vcc reference voltage for some technologies (such as SSTL-2) when used for the min or max column. This will cause incorrect timing test load corrections to be created for the min and max corners. Adding Vref to the [Model Spec] section is necessary to correctly simulate output timing and skew across the entire process range. A simple typical Vref value, as is currently used, will cause some simulators to report incorrect delay due to improper measurement of the output timing parameters. Device output timing specifications for SSTL-2 for DDR devices are guaranteed into the following standard load for the typical case: Cref = 30.000000pF Vref = 1.50000V Rref = 50.000000 For the minimum case: Cref = 30.000000pF Vref = 1.15000V Rref = 50.000000 For the maximum case: Cref = 30.000000pF Vref = 1.35000V Rref = 50.000000 It is impossible to correlate device output performance to only a typical test load with the current method. This enhancement to the [Model Spec] was incorrectly excluded from the previous BIRD 55. The inclusion of a simple timing measurement threshold region should also be considered for inclusion into this bird. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Tue Nov 16 21:42:43 1999 Received: from rgate2.ricochet.net (rgate2.ricochet.net [204.179.143.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id VAA14959 for ; Tue, 16 Nov 1999 21:42:42 -0800 (PST) Received: from hyperstar (mg-206191146-191.ricochet.net [206.191.146.191]) by rgate2.ricochet.net (8.9.3/8.9.3) with SMTP id XAA14134 for < ibis@eda.org>; Tue, 16 Nov 1999 23:42:06 -0600 (CST) Message-Id: <199911170542.XAA14134@rgate2.ricochet.net> X-Sender: kellee@pop.nwlink.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 16 Nov 1999 21:41:25 -0800 To: : From: Kellee Crisafulli Subject: IBIS connector specification vote Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi all, I would like to move that an item of business be added to the next meeting agenda to discuss voting on the IBIS connector specification. 1) It was introduced in Jan 1999 at the Design Con IBIS meeting. 2) All open items that came up at that meeting have been addressed by the connector sub-group. The specification was modified to either address them, post-pone them till another released or close them. 3) It is badly needed by the industry. 4) It has been examined by several major connector vendors, simulation vendors, and industry experts in the area of electromagnetic's and it is considered acceptable. 5) It follows the grammar and syntax of the existing IBIS specification 6) It uses syntax that is backward compatible with the IBIS .pkg specification. As far as I know all the goals we set to accomplish have been achieved. Check out the information at the IBIS web site... http://www.eda.org/pub/ibis/connector/ I don't expect a vote at the next meeting; I would however like it to be scheduled for a vote. best wishes. Kellee From owner-ibis Tue Nov 16 22:59:41 1999 Received: from g23.relcom.ru (g23.relcom.ru [193.125.152.117]) by server.eda.org (8.8.5/8.8.3) with ESMTP id WAA15288 for ; Tue, 16 Nov 1999 22:59:40 -0800 (PST) Received: from d32.z194-58-100.relcom.ru (d32.z194-58-100.relcom.ru [194.58.100.32]) by g23.relcom.ru (8.8.8/Relcom-2A) with SMTP id JAA20390 for ;Wed, 17 Nov 1999 09:56:32 +0300 (MSK) Message-ID: <000101bf30c8$cc267c90$20643ac2@gena> From: "Gennadiy" To: Subject: IBIS for frequency-domain simulation? Date: Wed, 17 Nov 1999 09:53:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Hi, Gentlemen, I know about IBIS for time-domain simulation of electronic circuits, in SPICE. Do you have any info about using IBIS model for frequency-domain simulation? Best regards, Gennadiy From owner-ibis Wed Nov 17 09:51:45 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 JAA19754 for ; Wed, 17 Nov 1999 09:51:44 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA14294; Wed, 17 Nov 1999 09:50:42 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id JAA08467; Wed, 17 Nov 1999 09:50:41 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3832EAF0.DC707AD5@mentor.com> Date: Wed, 17 Nov 1999 09:50:40 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: kellee@hyperlynx.com CC: ibis@eda.org, bob_ross@mentorg.com Subject: Re: IBIS connector specification vote References: <199911170542.XAA14134@rgate2.ricochet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kellee: You and the others have done an outstanding job producing the Connector Specification document. The Connector proposal is scheduled for discussion at the Friday, November 19, 1999 meeting at the end. I anticipate that there will be enough time for an extended introductory discussion. We are also thinking of two meetings in December where one will be devoted to one or two major technical issues. The Connector proposal is a candidate for an such an extended discussion. What is needed is for the IBIS group to seriously review the proposal and to provide comments. Then we can close off all new issues and vote on the proposal. Best Regards, Bob Ross Mentor Graphics Kellee Crisafulli wrote: > > Hi all, > > I would like to move that an item of business be added to the > next meeting agenda to discuss voting on the IBIS connector > specification. > > 1) It was introduced in Jan 1999 at the Design Con IBIS > meeting. > 2) All open items that came up at that meeting have been addressed > by the connector sub-group. The specification was modified > to either address them, post-pone them till another released or > close them. > 3) It is badly needed by the industry. > 4) It has been examined by several major connector vendors, > simulation vendors, and industry experts in the area of > electromagnetic's and it is considered acceptable. > 5) It follows the grammar and syntax of the existing IBIS specification > 6) It uses syntax that is backward compatible with the IBIS .pkg > specification. > > As far as I know all the goals we set to accomplish have been > achieved. > > Check out the information at the IBIS web site... > http://www.eda.org/pub/ibis/connector/ > > I don't expect a vote at the next meeting; I would however > like it to be scheduled for a vote. > > best wishes. > Kellee From owner-ibis Fri Nov 19 17:04:51 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 RAA09359 for ; Fri, 19 Nov 1999 17:04:50 -0800 (PST) Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id VAA05295 for ; Fri, 19 Nov 1999 21:04:34 GMT Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 19 Nov 1999 17:04:15 -0800 Message-ID: <4575832C8E71D111AC4100A0C96B512704A79ACC@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'ibis@vhdl.org'" Subject: Future directions for IBIS Date: Fri, 19 Nov 1999 17:04:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi IBIS folks, I decided to write this EMAIL on the future directions for IBIS to air some of my thoughts on this subject. I would like to get you thinking and stimulate a conversation so that we could make good decisions. I will try to talk in general terms so that we can see things in a broader view, but I will also give some examples to illustrate the issues. The spec starts getting out of hand mostly because of the inflexible keyword structure and inconsistencies. Keywords have very specific functions and assumptions, that's what makes them so inflexible. Inconsistencies prevent the reuse of the same syntax and/or keyword in different situations. For example, I just wrote BIRD 64, and found out that what I thought was a very simple addition was impossible. I wanted to make a package selector keyword that is identical to the model selector keywords, but it couldn't be done, because the rules are different for the package model names and buffer model names. One allows 40, the other allows 20 characters. One allows spaces, the other doesn't. I also started to write a BIRD on (what I thought) a simple keyword that would have allowed the on-die power distribution and return path modeling. It would have resembled the [Pin Numbers] keyword from the package section, except it would have described the interconnect between die pads and buffer models on the die. The idea is great, but syntactically does not work out as simple as it could. Why? Because the [Pin Numbers] keyword depends on a few other keywords ([Number of Pins], [Number of Sections], [Model Data], etc). They could all be reused, but two changes would have to be made in two of those keyword's usage rules. Besides, these keywords are all called "package" something, and it would be too confusing to describe die-interconnects with keywords that are called "package" something. So the next option would be to basically copy the whole package chapter with these minor name and rule changes into a brand new chapter called "Die Interconnect Modeling". This, however, increases the size of the specification, duplicates a lot of things but also increases the number of inconsistencies. Thinking about this problem I started to wonder whether I could use the EBD or new connector proposal, but I realized that each one of these have some specific characteristics which result in the same situation. To sum it up, we have four areas for interconnect modeling, each of which needs a separate chapter in the spec. This is ridiculous, because each of these are interconnect models! We should be able to come up with a syntax that is general enough to handle them all! I don't want to hold back the approval of the new connector spec. We need it badly, and it is way too late. I am just talking about all this so we can make a better plan for the future. Now, we have an option to take the spec and rigorously look at all these syntactical problems and clean it up and make it more efficient. However, at the same time we are beginning to feel the need for nodal connectivity. The new connector spec proposal introduces nodal connectivity in the [Begin_Cn_Pin_Map] keyword into IBIS. Stephen's IBIS-X proposal revolves heavily around nodal structuring, and I was going to use something similar to the [Begin_Cn_Pin_Map] in my unfinished die-interconnect BIRD also. So we all agree that this is a must. The question is whether we should do it through "mapping" keywords, or the good old SPICE way (or any other newly invented syntax). Regarding buffer modeling: Stephen's proposal of an API is essentially a hook to SPICE simulators from behavioral tools which would be used mostly when there are new features that can't be described by existing IBIS keywords. Can't do it in IBIS, so do it in SPICE (from an IBIS simulator). Again, it seems that we want SPICE capabilities. But why? Because IBIS is inflexible. What if IBIS could do what IMIC can do? Describe a buffer on a transistor level with behavioral transistors. Or take an intermediate level, describe a buffer with a building-block architecture, using primitives. A primitive could be as low as an IMIC behavioral transistor, but could be a basic inverter, or a block of the whole buffer, such as predriver, output stage, receiver, etc. This way one could put together a model behaviorally, using any level of abstraction according to the need of the buffer's characteristics. However, this would also require nodal connectivity. Oh yes, I almost forgot about equations. These are a special kind of controlled sources. Yes, behavioral. Allowing any node to be connected to another node by any function (S-parameter, and you name it). In a general case they let you reference any node voltage and/or branch current a part of the equation (not all SPICE tools do this well). These animals can't exist without a nodal approach either. So we want nodal connectivity a netlist type approach for any level of abstraction, behavioral and possibly full SPICE description capabilities. Doesn't this sound like a SPICE with enhanced behavioral elements? Let's turn around the picture. What does SPICE not have that IBIS has? Most SPICE flavors do not do too well on behavioral modeling, and board level simulation hooks. Board file readers are missing, measure statements are stone age style. The simulation results are in raw data format, and there are no good post processing tools to interpret the results. What if we added IMIC style behavioral transistors to SPICE tools? What if we added IBIS style behavioral buffers (building blocks) to SPICE tools? What if we added nice and useful measurement statements? Add a front end tool that reads PCB layout files. Add a 3D graphical output visualization tool to interpret the results. (Some IBIS tools could learn more about this too). No matter how we look at it, it seems to that we are experiencing the need for a merger between the SPICE world and the behavioral tool's world. It seems to me that SPICE addresses buffer design, while behavioral tools address system design with their main features. With the emerging needs in system design, BOTH kinds of tools are lacking, even though SPICE is still good for buffer design. The real question in my opinion is: How can we improve on our system design tools? What is easier to do? Clean up IBIS and invent a nodal language, advance the behavioral black box approach with a possible merger with IMIC, add SPICE support into them though an API, or take the existing SPICE tools and add those "system design" features that IBIS tools have and are good at? I would like to read a lot of replies to this one... Arpad ============================================================================ ============= From owner-ibis Fri Nov 19 17:15:12 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 RAA09463 for ; Fri, 19 Nov 1999 17:15:11 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA16720; Fri, 19 Nov 1999 17:14:07 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA08885; Fri, 19 Nov 1999 17:14:06 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3835F5DD.75E6DBCB@mentor.com> Date: Fri, 19 Nov 1999 17:14:05 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS BIRD64.1 - Package Model Selector Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Committee: Arpad Muranyi submitted BIRD 64.1 in response to a number of recent comments including those made at the November 19, 1999 IBIS Meeting. BIRD64.1 does not necessarily implement some of the comments. The Analysis and Background sections have been expanded significantly and contain some of the rationale for this revision. We expect more discussion and debate. Bob Ross Mentor Graphics ******************************************************************************* ******************************************************************************* BIRD ID#: 64.1 ISSUE TITLE: Package Model Selector REQUESTER: Arpad Muranyi, Intel DATE SUBMITTED: 10-25-99, 11-19-99 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The current IBIS specification (3.2) does not provide a selection mechanism for multiple package models. This may be necessary when a certain die is shipped in various package styles, or when the corner cases of the package are described with different package models. This BIRD is written to provide an easy solution to this deficiency. This feature will allow simulator tools to implement a user friendly package model selection interface and/or better automation for batch and sweep simulations. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: A new keyword shall be introduced in the IBIS specification to provide a user friendly package model selection mechanism for components which use multiple package models. The proposed keyword [Package Model Selector] shall contain a list of all package model names that the simulator can pick from. The first entry in the list is considered to be the default package model. The package model names listed under the [Package Model Selector] must follow the rules of the package model names associated with the [Package Model] keyword. To help the user of the simulator tool to make an intelligent choice, it is highly recommended that a description be placed to the right of each package model name in the list as a comment. |============================================================================= | Keyword: [Package Model Selector] | Required: No. | Description: Used to select a package model from a list of package models. | Sub-Params: None. | Usage Rules: The [Package Model Selector] keyword can be used in place of | the [Package Model] keyword. The only difference between the | two keywords is that the [Package Model Selector] allows | multiple package models to be listed. All package model names | must appear below the [Package Model Selector] keyword. | | The package model names listed under the [Package Model | Selector] must follow the rules of the package model names | associated with the [Package Model] keyword. | | The first entry under the [Package Model selector] keyword | shall be considered the default by the simulator tool. |============================================================================= | [Package Model Selector] | 208-pin_plastic_PQFP_package-even_mode | What more can be said here? 208-pin_plastic_PQFP_package-odd_mode | It's all in the name. 208-pin_ceramic_PQFP_package-even_mode | More comments and descriptions here. 208-pin_ceramic_PQFP_package-odd_mode | And some more here too. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Problem statement Some components are shipped in multiple package styles. Also, there are situations when the corner cases of a package are modeled with multiple package models. Currently, in these cases the user of the IBIS model has to manually edit the IBIS file to change the package model name that is called by the [Package Model] keyword in order to reference a different package model. This makes automated simulations difficult, if not impossible. Possible solutions Add a new, simple keyword to the IBIS specification which works similar to the already existing [Model Selector] keyword. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Several IBIS model users expressed their desire in private conversations and IBIS meetings to have such a package model selection mechanism in the IBIS specification to make their work easier. An alternate syntax was suggested by Bob Ross during an EMAIL and telephone correspondence on 10/25/99. The suggested syntax is identical to the [Model Selector] syntax, according to which the [Package Model Selector] would be assigned a name that is called by the (higher level) [Package Model] keyword. However, unlike in the [Model Selector] case, there is no need for calling the [Package Model Selector] from a higher level. This BIRD favors the simpler vs. the more consistent approach. Scott McMorrow made a request in an EMAIL on 11/12/99 to incorporate typ., min., and max. columns in the list of package models under the model selector name to assist in automating the package model selection based on corner cases. According to the exisiting rules this is not possible, becuase the package model names are allowed to be up to 40 characters in length. Three package model names on the same line could add up to 122 characters, which violates the current 80 character per line rules of the IBIS specification. Further, package model names are allowed to include blank characters, which requires a delimiter other than the space or tab character between the typ., min., and max. columns. The usage of a new delimiter introduces another inconsistency in the IBIS specification, since spaces and/or tab characters are widely used as delimiters between columns in current IBIS versions. A technical dilemma regarding the automated selection of package models based on typ., min., and max. qualifiers remains to be answered also. What do typ., min., and max. represent? Impedance, wave velocity, trace length, or perhaps the amount of cross talk? Simulation tool users will most likely make their choices based on individual preferences, possibly depending on project requirements. For this reason it seems to make more sense to give only a list that contains all of the package models without the typ., min., and max. qualifiers. The selection and automated usage of the various package models should then be done through a GUI or configuration mechanisms provided by the tool. The differences between the model name and package model name restrictions required a change even in this BIRD. The description field of the [Model Selector] keyword is separated by one or more space or tab character(s) from the model name. However, since package model names can contain blank characters, space or tab characters will not work as delimiters for the description field of the [Package Model Selector] keyword. Since the contents of the description field is only used for informational purposes which does not effect the simulations I decided to use the comment character (|) as the delimiter for now. This option was actually discussed for the [Model Selector] also but voted down for the reason that tools reading an IBIS model have all the rights to ignore all comments, therefore a GUI would not know how to distinguish between a legitimate descrription and a meaningless comment. Does anyone have a better suggestion? ****************************************************************************** From owner-ibis Mon Nov 22 10:52:20 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 KAA22660 for ; Mon, 22 Nov 1999 10:52:19 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA21153; Mon, 22 Nov 1999 10:51:16 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA05640; Mon, 22 Nov 1999 10:51:14 -0800 (PST) Message-ID: <3839903F.CB7632F2@mentor.com> Date: Mon, 22 Nov 1999 10:49:35 -0800 From: Ted Creedon X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Muranyi, Arpad" CC: "'ibis@vhdl.org'" Subject: Re: Future directions for IBIS References: <4575832C8E71D111AC4100A0C96B512704A79ACC@fmsmsx36.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Perhaps we should revisit the need for IBIS in the first place. Couldn't proprietary information be distributed through the simulator vendors using public/private keying? Regarding the "nodal simulator" discussion, there is a very fine modeling language in the documentation for a microwave simulator used for the MMIC program in the 90's. I have the source code under license and have read the code extensively as well as several versions of Spice code. The MMIC simulator does a particularly fine job of goal based parameter optimization, including syntactical representations of typ[min,max] parameter values and also does yield analysis based on manufacturing statistical tolerances. It isn't clear how a behavioral simulator would "call" Spice since Spice isn't set up to be callable. Spice wants to build the Y matrix from parsed input and invert it in the time domain. We should recall that Spice 3f5 is an integrated circuit simulator which does not support nonlinear devices in the frequency domain (which are used to characterize interconnect). And I don't see any analysis tool vendor except one that intends to correlate calculated vs measured results (i.e. loss tangent, Er, anisotropic Er, skin effect, surface roughness, etc., etc.). The discussion has left out the Boolean capabilities in WSpice which may be required to characterize buffers. And all this needs to run in a finite time. The subject of analog design languages has a varied history going back to the AHDL workshops at Dartmouth in 1985. The analog designers abandoned the effort to the CS majors since the need for graphical input representation couldn't be met with a 128 key keyboard! Anyway, this is no small effort. I agree with the basic notion that as digital design speeds are now up to 10GHz, and PC designs are running up to 400Mhz baseband with 50-100 ps risetimes, the need for microwave style modeling is clear. Ted Creedon "Muranyi, Arpad" wrote: > Hi IBIS folks, > > I decided to write this EMAIL on the future directions for IBIS to air some > of > my thoughts on this subject. I would like to get you thinking and stimulate > a conversation so that we could make good decisions. I will try to talk in > general > terms so that we can see things in a broader view, but I will also give some > examples to illustrate the issues. > > The spec starts getting out of hand mostly because of the inflexible keyword > structure and inconsistencies. Keywords have very specific functions and > assumptions, > that's what makes them so inflexible. Inconsistencies prevent the reuse of > the same > syntax and/or keyword in different situations. For example, I just wrote > BIRD 64, and > found out that what I thought was a very simple addition was impossible. I > wanted to > make a package selector keyword that is identical to the model selector > keywords, but > it couldn't be done, because the rules are different for the package model > names and > buffer model names. One allows 40, the other allows 20 characters. One > allows spaces, > the other doesn't. > > I also started to write a BIRD on (what I thought) a simple keyword that > would have > allowed the on-die power distribution and return path modeling. It would > have > resembled the [Pin Numbers] keyword from the package section, except it > would have > described the interconnect between die pads and buffer models on the die. > The idea > is great, but syntactically does not work out as simple as it could. Why? > Because > the [Pin Numbers] keyword depends on a few other keywords ([Number of Pins], > [Number > of Sections], [Model Data], etc). They could all be reused, but two changes > would > have to be made in two of those keyword's usage rules. Besides, these > keywords are > all called "package" something, and it would be too confusing to describe > die-interconnects > with keywords that are called "package" something. So the next option would > be to > basically copy the whole package chapter with these minor name and rule > changes into > a brand new chapter called "Die Interconnect Modeling". This, however, > increases the > size of the specification, duplicates a lot of things but also increases the > number > of inconsistencies. > > Thinking about this problem I started to wonder whether I could use the EBD > or new > connector proposal, but I realized that each one of these have some specific > characteristics which result in the same situation. > > To sum it up, we have four areas for interconnect modeling, each of which > needs a separate > chapter in the spec. This is ridiculous, because each of these are > interconnect models! > We should be able to come up with a syntax that is general enough to handle > them all! > > I don't want to hold back the approval of the new connector spec. We need > it badly, > and it is way too late. I am just talking about all this so we can make a > better plan > for the future. > > Now, we have an option to take the spec and rigorously look at all these > syntactical > problems and clean it up and make it more efficient. However, at the same > time we > are beginning to feel the need for nodal connectivity. The new connector > spec proposal > introduces nodal connectivity in the [Begin_Cn_Pin_Map] keyword into IBIS. > Stephen's > IBIS-X proposal revolves heavily around nodal structuring, and I was going > to use > something similar to the [Begin_Cn_Pin_Map] in my unfinished > die-interconnect BIRD > also. So we all agree that this is a must. The question is whether we > should do it > through "mapping" keywords, or the good old SPICE way (or any other newly > invented > syntax). > > Regarding buffer modeling: Stephen's proposal of an API is essentially a > hook to > SPICE simulators from behavioral tools which would be used mostly when there > are new > features that can't be described by existing IBIS keywords. Can't do it in > IBIS, so > do it in SPICE (from an IBIS simulator). Again, it seems that we want SPICE > capabilities. But why? Because IBIS is inflexible. What if IBIS could do > what > IMIC can do? Describe a buffer on a transistor level with behavioral > transistors. > Or take an intermediate level, describe a buffer with a building-block > architecture, > using primitives. A primitive could be as low as an IMIC behavioral > transistor, > but could be a basic inverter, or a block of the whole buffer, such as > predriver, > output stage, receiver, etc. This way one could put together a model > behaviorally, > using any level of abstraction according to the need of the buffer's > characteristics. > However, this would also require nodal connectivity. > > Oh yes, I almost forgot about equations. These are a special kind of > controlled > sources. Yes, behavioral. Allowing any node to be connected to another > node by > any function (S-parameter, and you name it). In a general case they let you > reference any node voltage and/or branch current a part of the equation (not > all > SPICE tools do this well). These animals can't exist without a nodal > approach > either. > > So we want nodal connectivity a netlist type approach for any level of > abstraction, > behavioral and possibly full SPICE description capabilities. Doesn't this > sound > like a SPICE with enhanced behavioral elements? > > Let's turn around the picture. What does SPICE not have that IBIS has? > Most SPICE > flavors do not do too well on behavioral modeling, and board level > simulation hooks. > Board file readers are missing, measure statements are stone age style. The > simulation > results are in raw data format, and there are no good post processing tools > to interpret > the results. > > What if we added IMIC style behavioral transistors to SPICE tools? What if > we added > IBIS style behavioral buffers (building blocks) to SPICE tools? What if we > added > nice and useful measurement statements? Add a front end tool that reads PCB > layout > files. Add a 3D graphical output visualization tool to interpret the > results. (Some > IBIS tools could learn more about this too). > > No matter how we look at it, it seems to that we are experiencing the need > for a merger > between the SPICE world and the behavioral tool's world. It seems to me > that SPICE > addresses buffer design, while behavioral tools address system design with > their > main features. With the emerging needs in system design, BOTH kinds of > tools are > lacking, even though SPICE is still good for buffer design. The real > question in my > opinion is: How can we improve on our system design tools? > > What is easier to do? Clean up IBIS and invent a nodal language, advance > the behavioral > black box approach with a possible merger with IMIC, add SPICE support into > them though > an API, or take the existing SPICE tools and add those "system design" > features that > IBIS tools have and are good at? > > I would like to read a lot of replies to this one... > > Arpad > ============================================================================ > ============= From owner-ibis Mon Nov 22 13:13:55 1999 Received: from tuna.cacc.ncsu.edu (tuna.cacc.ncsu.edu [152.1.192.29]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA23186 for ; Mon, 22 Nov 1999 13:13:55 -0800 (PST) Received: (from paulf@localhost) by tuna.cacc.ncsu.edu (8.8.4/UC02Jan97) id QAA22155; Mon, 22 Nov 1999 16:13:05 -0500 (EST) From: "Paul Franzon" Message-Id: <9911221613.ZM22153@eos.ncsu.edu> Date: Mon, 22 Nov 1999 16:13:05 -0500 In-Reply-To: Ted Creedon "Re: Future directions for IBIS" (Nov 22, 10:49) References: <4575832C8E71D111AC4100A0C96B512704A79ACC@fmsmsx36.fm.intel.com> <3839903F.CB7632F2@mentor.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: paulf@eos.ncsu.edu, "Muranyi, Arpad" , Ted Creedon Subject: Re: Future directions for IBIS ... IBIS 2000 Cc: "'ibis@vhdl.org'" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I think both Arpad and Ted raise some very good issues. I would like to recommend that the community takes a moment to think where they want to take IBIS in the next century....IBIS 2000??? Feedback/comments are welcome. Some global comments: o IBIS succeeded because it created an accepted standard for distributing simulatable descriptions of I/O buffers. Prevous attempts at encrypted I/O model distrubution basicly failed for a variety of reasons (proprietary/custom spices, IP conerns, too much effort, etc.). In comparison IBIS is an enourmous success. It solved the 'I dont want to/cant give out the Spice netlist for my driver' problem. o From a technical point of view, the IBIS standard is somehat arbitrary in terms of its makeup and is IMHO suffering from creeping functionalism. For example (on the arbitrariness), when writing 2ibis, we had to make arbitrary decisions about how the different parts of the circuit response are assigned to the different parts of the macromodel. (BTW, this does not detract from the utility of the tool at all) o IBIS does not lead to accurate SSN prediction and IMHO no straightforward extension will be able handle this or return path issues properly. A fresh start is needed. IBIS has already run out of steam for the ultra high speed board designer. Some recommendations for 'IBIS 2000': o Keep IBIS 1. Keep a behavioral standard that can has a large level of agreement and buy-in. In fact, do not abandon IBIS as it exists now. o Change the direction for future IBIS enhancements. Here could be some recommendations: - From a technical point of view, IBIS should be mainly be a set of macromodels that properly capture I/O edges and Vdd and Gnd transients. (BTW, the latter is somewhat difficult.) Table-based VI macro-models are appropriate. - It should be possible to produce this macromodel from a Spice netlist (S2ibis) or a measurement procedure. - It should be possible to translate the macromodels into the more popular spice flavours with a very simple 1:1 translation. o Drop including the package. There is no technical reason why IBIS should be getting into package parasitic modeling. Why cant vendors just distribute an RLC netlist? There is no reason to invent a new standard for this (vanilla Spice is fine) and I fail to see how such netlists can be considered core corporate IP and thus have to be protected (please let me know if this last statement is wrong). With proper netlists, the accuracy of SSN, package xtalk and return path simulation would go up. o Keep the concept of the IBIS model also documenting SI requirements. This is not done properly elsewhere in the documentation, so might as well leave it here. o Keep the concept of an agreed-upon-standard. It has worked well to now. I do feel that there is a need for fundamental and open work on what is needed to accurately model a driver with a macromodel. IBIS 1 worked fine just by thinking the issues through a little. IBIS 2000 needs some experimental investigative work as to how it should approach macromodeling. Eyeballing a model wont work. That work could be be done in an Industry lab or (shameless plug follows) in an open University setting. (SRC would be the appropriate sponsor, by the way). Regards, Paul On Nov 22, 10:49, Ted Creedon wrote: > Subject: Re: Future directions for IBIS > All, > > Perhaps we should revisit the need for IBIS in the first place. Couldn't > proprietary information be distributed through the simulator vendors using > public/private keying? > > Regarding the "nodal simulator" discussion, there is a very fine modeling > language in the documentation for a microwave simulator used for the MMIC > program in the 90's. I have the source code under license and have read the code > extensively as well as several versions of Spice code. The MMIC simulator does a > particularly fine job of goal based parameter optimization, including > syntactical representations of typ[min,max] parameter values and also does yield > analysis based on manufacturing statistical tolerances. > > It isn't clear how a behavioral simulator would "call" Spice since Spice isn't > set up to be callable. Spice wants to build the Y matrix from parsed input and > invert it in the time domain. We should recall that Spice 3f5 is an integrated > circuit simulator which does not support nonlinear devices in the frequency > domain (which are used to characterize interconnect). And I don't see any > analysis tool vendor except one that intends to correlate calculated vs measured > results (i.e. loss tangent, Er, anisotropic Er, skin effect, surface roughness, > etc., etc.). > > The discussion has left out the Boolean capabilities in WSpice which may be > required to characterize buffers. > > And all this needs to run in a finite time. > > The subject of analog design languages has a varied history going back to the > AHDL workshops at Dartmouth in 1985. The analog designers abandoned the effort > to the CS majors since the need for graphical input representation couldn't be > met with a 128 key keyboard! > > Anyway, this is no small effort. I agree with the basic notion that as digital > design speeds are now up to 10GHz, and PC designs are running up to 400Mhz > baseband with 50-100 ps risetimes, the need for microwave style modeling is > clear. > > > Ted Creedon > > "Muranyi, Arpad" wrote: > > > Hi IBIS folks, > > > > I decided to write this EMAIL on the future directions for IBIS to air some > > of > > my thoughts on this subject. I would like to get you thinking and stimulate > > a conversation so that we could make good decisions. I will try to talk in > > general > > terms so that we can see things in a broader view, but I will also give some > > examples to illustrate the issues. > > > > The spec starts getting out of hand mostly because of the inflexible keyword > > structure and inconsistencies. Keywords have very specific functions and > > assumptions, > > that's what makes them so inflexible. Inconsistencies prevent the reuse of > > the same > > syntax and/or keyword in different situations. For example, I just wrote > > BIRD 64, and > > found out that what I thought was a very simple addition was impossible. I > > wanted to > > make a package selector keyword that is identical to the model selector > > keywords, but > > it couldn't be done, because the rules are different for the package model > > names and > > buffer model names. One allows 40, the other allows 20 characters. One > > allows spaces, > > the other doesn't. > > > > I also started to write a BIRD on (what I thought) a simple keyword that > > would have > > allowed the on-die power distribution and return path modeling. It would > > have > > resembled the [Pin Numbers] keyword from the package section, except it > > would have > > described the interconnect between die pads and buffer models on the die. > > The idea > > is great, but syntactically does not work out as simple as it could. Why? > > Because > > the [Pin Numbers] keyword depends on a few other keywords ([Number of Pins], > > [Number > > of Sections], [Model Data], etc). They could all be reused, but two changes > > would > > have to be made in two of those keyword's usage rules. Besides, these > > keywords are > > all called "package" something, and it would be too confusing to describe > > die-interconnects > > with keywords that are called "package" something. So the next option would > > be to > > basically copy the whole package chapter with these minor name and rule > > changes into > > a brand new chapter called "Die Interconnect Modeling". This, however, > > increases the > > size of the specification, duplicates a lot of things but also increases the > > number > > of inconsistencies. > > > > Thinking about this problem I started to wonder whether I could use the EBD > > or new > > connector proposal, but I realized that each one of these have some specific > > characteristics which result in the same situation. > > > > To sum it up, we have four areas for interconnect modeling, each of which > > needs a separate > > chapter in the spec. This is ridiculous, because each of these are > > interconnect models! > > We should be able to come up with a syntax that is general enough to handle > > them all! > > > > I don't want to hold back the approval of the new connector spec. We need > > it badly, > > and it is way too late. I am just talking about all this so we can make a > > better plan > > for the future. > > > > Now, we have an option to take the spec and rigorously look at all these > > syntactical > > problems and clean it up and make it more efficient. However, at the same > > time we > > are beginning to feel the need for nodal connectivity. The new connector > > spec proposal > > introduces nodal connectivity in the [Begin_Cn_Pin_Map] keyword into IBIS. > > Stephen's > > IBIS-X proposal revolves heavily around nodal structuring, and I was going > > to use > > something similar to the [Begin_Cn_Pin_Map] in my unfinished > > die-interconnect BIRD > > also. So we all agree that this is a must. The question is whether we > > should do it > > through "mapping" keywords, or the good old SPICE way (or any other newly > > invented > > syntax). > > > > Regarding buffer modeling: Stephen's proposal of an API is essentially a > > hook to > > SPICE simulators from behavioral tools which would be used mostly when there > > are new > > features that can't be described by existing IBIS keywords. Can't do it in > > IBIS, so > > do it in SPICE (from an IBIS simulator). Again, it seems that we want SPICE > > capabilities. But why? Because IBIS is inflexible. What if IBIS could do > > what > > IMIC can do? Describe a buffer on a transistor level with behavioral > > transistors. > > Or take an intermediate level, describe a buffer with a building-block > > architecture, > > using primitives. A primitive could be as low as an IMIC behavioral > > transistor, > > but could be a basic inverter, or a block of the whole buffer, such as > > predriver, > > output stage, receiver, etc. This way one could put together a model > > behaviorally, > > using any level of abstraction according to the need of the buffer's > > characteristics. > > However, this would also require nodal connectivity. > > > > Oh yes, I almost forgot about equations. These are a special kind of > > controlled > > sources. Yes, behavioral. Allowing any node to be connected to another > > node by > > any function (S-parameter, and you name it). In a general case they let you > > reference any node voltage and/or branch current a part of the equation (not > > all > > SPICE tools do this well). These animals can't exist without a nodal > > approach > > either. > > > > So we want nodal connectivity a netlist type approach for any level of > > abstraction, > > behavioral and possibly full SPICE description capabilities. Doesn't this > > sound > > like a SPICE with enhanced behavioral elements? > > > > Let's turn around the picture. What does SPICE not have that IBIS has? > > Most SPICE > > flavors do not do too well on behavioral modeling, and board level > > simulation hooks. > > Board file readers are missing, measure statements are stone age style. The > > simulation > > results are in raw data format, and there are no good post processing tools > > to interpret > > the results. > > > > What if we added IMIC style behavioral transistors to SPICE tools? What if > > we added > > IBIS style behavioral buffers (building blocks) to SPICE tools? What if we > > added > > nice and useful measurement statements? Add a front end tool that reads PCB > > layout > > files. Add a 3D graphical output visualization tool to interpret the > > results. (Some > > IBIS tools could learn more about this too). > > > > No matter how we look at it, it seems to that we are experiencing the need > > for a merger > > between the SPICE world and the behavioral tool's world. It seems to me > > that SPICE > > addresses buffer design, while behavioral tools address system design with > > their > > main features. With the emerging needs in system design, BOTH kinds of > > tools are > > lacking, even though SPICE is still good for buffer design. The real > > question in my > > opinion is: How can we improve on our system design tools? > > > > What is easier to do? Clean up IBIS and invent a nodal language, advance > > the behavioral > > black box approach with a possible merger with IMIC, add SPICE support into > > them though > > an API, or take the existing SPICE tools and add those "system design" > > features that > > IBIS tools have and are good at? > > > > I would like to read a lot of replies to this one... > > > > Arpad > > ============================================================================ > > ============= > >-- End of excerpt from Ted Creedon -- ---Paul Franzon, Professor, North Carolina State University 919 515 7351, fax. 919 515 2285, www.ece.ncsu.edu/erl/faculty/paulf.html Rm. 443, Engineering Graduate Research Center, Centennial Campus smail: ECE, Box 7914, NCSU, Raleigh NC 27695-7914 Fedex: Rm. 419, EGRC, 1010 Main Campus Dve, NCSU, Raleigh NC 27695-7914 From owner-ibis Mon Nov 22 14:15:35 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 OAA23413 for ; Mon, 22 Nov 1999 14:15:34 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA09240; Mon, 22 Nov 1999 14:14:30 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA15156; Mon, 22 Nov 1999 14:14:29 -0800 (PST) Message-ID: <3839C044.56E21EDF@mentor.com> Date: Mon, 22 Nov 1999 14:14:28 -0800 From: Ted Creedon X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Franzon CC: "Muranyi, Arpad" , Ted Creedon , "'ibis@vhdl.org'" Subject: Re: Future directions for IBIS ... IBIS 2000 References: <4575832C8E71D111AC4100A0C96B512704A79ACC@fmsmsx36.fm.intel.com> <3839903F.CB7632F2@mentor.com> <9911221613.ZM22153@eos.ncsu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Absolutely agree on using university types to help on the language definition and need for funding. RLC will not be satisfactory for all packaging. Need lossy coupled transmission lines. Let's think in the reverse direction - top down. Suppose we have the perfect language, what would it do? Accept IBIS Accept Spice Accept a N port network description language (NDL) Accept graphical input Accept measurement based tables of S parameters (or Y or Z) by frequency or NDL equations Others I haven't thought about The common thread I see here is network description objects. An object being defined as data and methods in its own container. That is, an object knows enough about itself to be able to describe itself to you. The theory here is that if an object oriented language can be fashioned, we don't care about the implementation details which is where we're hung up. I can share the Agile user manual with whoever, it's not in machine readable form. It would be possible to stick Agile on a server somewhere so interested parties could play. Its a Motif/unix app. that uses the linpack nonlinear pde solvers and it was written in C by 2 RF electrical engineers. Took about 8 man years including comparing calculated vs. measured results. Perhaps a Smalltalk parser and Matlab solver would work for protyping. Ted Paul Franzon wrote: > I think both Arpad and Ted raise some very good issues. I would > like to recommend that the community takes a moment to think where > they want to take IBIS in the next century....IBIS 2000??? > > Feedback/comments are welcome. > > Some global comments: > > o IBIS succeeded because it created an accepted standard for distributing > simulatable descriptions of I/O buffers. Prevous attempts at encrypted > I/O model distrubution basicly failed for a variety of reasons > (proprietary/custom spices, IP conerns, too much effort, etc.). In > comparison IBIS is an enourmous success. It solved the 'I dont > want to/cant give out the Spice netlist for my driver' problem. > > o From a technical point of view, the IBIS standard is somehat arbitrary > in terms of its makeup and is IMHO suffering > from creeping functionalism. For example (on the arbitrariness), when > writing 2ibis, we had to make arbitrary decisions about how the > different > parts of the circuit response are assigned to the different parts of the > macromodel. > (BTW, this does not detract from the utility of the tool at all) > > o IBIS does not lead to accurate SSN prediction and IMHO no > straightforward > extension will be able handle this or return path issues properly. A > fresh start is needed. IBIS has already run out of steam for the ultra > high speed board designer. > > Some recommendations for 'IBIS 2000': > > o Keep IBIS 1. > Keep a behavioral standard that can has a large level of agreement > and buy-in. In fact, do not abandon IBIS as it exists now. > > o Change the direction for future IBIS enhancements. > Here could be some recommendations: > - From a technical point of view, IBIS should be mainly be a set of > macromodels that properly capture I/O edges and Vdd and Gnd > transients. > (BTW, the latter is somewhat difficult.) Table-based VI > macro-models are appropriate. > - It should be possible to produce this macromodel from a Spice netlist > (S2ibis) or a measurement procedure. > - It should be possible to translate the macromodels into the more > popular spice flavours with a very simple 1:1 translation. > > o Drop including the package. > There is no technical reason why IBIS should be getting into package > parasitic modeling. Why cant vendors just distribute an RLC netlist? > There is no reason to invent a new standard for this (vanilla Spice > is fine) and I fail to see how such netlists can be considered > core corporate IP and thus have to be protected (please let me know > if this last statement is wrong). > > With proper netlists, the accuracy of SSN, package xtalk and return > path simulation would go up. > > o Keep the concept of the IBIS model also documenting SI requirements. > This is not done properly elsewhere in the documentation, so might as > well leave it here. > > o Keep the concept of an agreed-upon-standard. It has worked well to now. > > I do feel that there is a need for fundamental and open work on what > is needed to accurately model a driver with a macromodel. IBIS 1 > worked fine just by thinking the issues through a little. IBIS 2000 > needs some experimental investigative work as to how it should approach > macromodeling. Eyeballing a model wont work. > > That work could be be done in an Industry lab or > (shameless plug follows) in an open University setting. (SRC would > be the appropriate sponsor, by the way). > > Regards, > > Paul > > On Nov 22, 10:49, Ted Creedon wrote: > > Subject: Re: Future directions for IBIS > > All, > > > > Perhaps we should revisit the need for IBIS in the first place. Couldn't > > proprietary information be distributed through the simulator vendors > using > > public/private keying? > > > > Regarding the "nodal simulator" discussion, there is a very fine > modeling > > language in the documentation for a microwave simulator used for the > MMIC > > program in the 90's. I have the source code under license and have read > the code > > extensively as well as several versions of Spice code. The MMIC > simulator does a > > particularly fine job of goal based parameter optimization, including > > syntactical representations of typ[min,max] parameter values and also > does yield > > analysis based on manufacturing statistical tolerances. > > > > It isn't clear how a behavioral simulator would "call" Spice since Spice > isn't > > set up to be callable. Spice wants to build the Y matrix from parsed > input and > > invert it in the time domain. We should recall that Spice 3f5 is an > integrated > > circuit simulator which does not support nonlinear devices in the > frequency > > domain (which are used to characterize interconnect). And I don't see > any > > analysis tool vendor except one that intends to correlate calculated vs > measured > > results (i.e. loss tangent, Er, anisotropic Er, skin effect, surface > roughness, > > etc., etc.). > > > > The discussion has left out the Boolean capabilities in WSpice which may > be > > required to characterize buffers. > > > > And all this needs to run in a finite time. > > > > The subject of analog design languages has a varied history going back > to the > > AHDL workshops at Dartmouth in 1985. The analog designers abandoned the > effort > > to the CS majors since the need for graphical input representation > couldn't be > > met with a 128 key keyboard! > > > > Anyway, this is no small effort. I agree with the basic notion that as > digital > > design speeds are now up to 10GHz, and PC designs are running up to > 400Mhz > > baseband with 50-100 ps risetimes, the need for microwave style modeling > is > > clear. > > > > > > Ted Creedon > > > > "Muranyi, Arpad" wrote: > > > > > Hi IBIS folks, > > > > > > I decided to write this EMAIL on the future directions for IBIS to air > some > > > of > > > my thoughts on this subject. I would like to get you thinking and > stimulate > > > a conversation so that we could make good decisions. I will try to > talk in > > > general > > > terms so that we can see things in a broader view, but I will also > give some > > > examples to illustrate the issues. > > > > > > The spec starts getting out of hand mostly because of the inflexible > keyword > > > structure and inconsistencies. Keywords have very specific functions > and > > > assumptions, > > > that's what makes them so inflexible. Inconsistencies prevent the > reuse of > > > the same > > > syntax and/or keyword in different situations. For example, I just > wrote > > > BIRD 64, and > > > found out that what I thought was a very simple addition was > impossible. I > > > wanted to > > > make a package selector keyword that is identical to the model > selector > > > keywords, but > > > it couldn't be done, because the rules are different for the package > model > > > names and > > > buffer model names. One allows 40, the other allows 20 characters. > One > > > allows spaces, > > > the other doesn't. > > > > > > I also started to write a BIRD on (what I thought) a simple keyword > that > > > would have > > > allowed the on-die power distribution and return path modeling. It > would > > > have > > > resembled the [Pin Numbers] keyword from the package section, except > it > > > would have > > > described the interconnect between die pads and buffer models on the > die. > > > The idea > > > is great, but syntactically does not work out as simple as it could. > Why? > > > Because > > > the [Pin Numbers] keyword depends on a few other keywords ([Number of > Pins], > > > [Number > > > of Sections], [Model Data], etc). They could all be reused, but two > changes > > > would > > > have to be made in two of those keyword's usage rules. Besides, these > > > keywords are > > > all called "package" something, and it would be too confusing to > describe > > > die-interconnects > > > with keywords that are called "package" something. So the next option > would > > > be to > > > basically copy the whole package chapter with these minor name and > rule > > > changes into > > > a brand new chapter called "Die Interconnect Modeling". This, > however, > > > increases the > > > size of the specification, duplicates a lot of things but also > increases the > > > number > > > of inconsistencies. > > > > > > Thinking about this problem I started to wonder whether I could use > the EBD > > > or new > > > connector proposal, but I realized that each one of these have some > specific > > > characteristics which result in the same situation. > > > > > > To sum it up, we have four areas for interconnect modeling, each of > which > > > needs a separate > > > chapter in the spec. This is ridiculous, because each of these are > > > interconnect models! > > > We should be able to come up with a syntax that is general enough to > handle > > > them all! > > > > > > I don't want to hold back the approval of the new connector spec. We > need > > > it badly, > > > and it is way too late. I am just talking about all this so we can > make a > > > better plan > > > for the future. > > > > > > Now, we have an option to take the spec and rigorously look at all > these > > > syntactical > > > problems and clean it up and make it more efficient. However, at the > same > > > time we > > > are beginning to feel the need for nodal connectivity. The new > connector > > > spec proposal > > > introduces nodal connectivity in the [Begin_Cn_Pin_Map] keyword into > IBIS. > > > Stephen's > > > IBIS-X proposal revolves heavily around nodal structuring, and I was > going > > > to use > > > something similar to the [Begin_Cn_Pin_Map] in my unfinished > > > die-interconnect BIRD > > > also. So we all agree that this is a must. The question is whether > we > > > should do it > > > through "mapping" keywords, or the good old SPICE way (or any other > newly > > > invented > > > syntax). > > > > > > Regarding buffer modeling: Stephen's proposal of an API is > essentially a > > > hook to > > > SPICE simulators from behavioral tools which would be used mostly when > there > > > are new > > > features that can't be described by existing IBIS keywords. Can't do > it in > > > IBIS, so > > > do it in SPICE (from an IBIS simulator). Again, it seems that we want > SPICE > > > capabilities. But why? Because IBIS is inflexible. What if IBIS > could do > > > what > > > IMIC can do? Describe a buffer on a transistor level with behavioral > > > transistors. > > > Or take an intermediate level, describe a buffer with a building-block > > > architecture, > > > using primitives. A primitive could be as low as an IMIC behavioral > > > transistor, > > > but could be a basic inverter, or a block of the whole buffer, such as > > > predriver, > > > output stage, receiver, etc. This way one could put together a model > > > behaviorally, > > > using any level of abstraction according to the need of the buffer's > > > characteristics. > > > However, this would also require nodal connectivity. > > > > > > Oh yes, I almost forgot about equations. These are a special kind of > > > controlled > > > sources. Yes, behavioral. Allowing any node to be connected to > another > > > node by > > > any function (S-parameter, and you name it). In a general case they > let you > > > reference any node voltage and/or branch current a part of the > equation (not > > > all > > > SPICE tools do this well). These animals can't exist without a nodal > > > approach > > > either. > > > > > > So we want nodal connectivity a netlist type approach for any level of > > > abstraction, > > > behavioral and possibly full SPICE description capabilities. Doesn't > this > > > sound > > > like a SPICE with enhanced behavioral elements? > > > > > > Let's turn around the picture. What does SPICE not have that IBIS > has? > > > Most SPICE > > > flavors do not do too well on behavioral modeling, and board level > > > simulation hooks. > > > Board file readers are missing, measure statements are stone age > style. The > > > simulation > > > results are in raw data format, and there are no good post processing > tools > > > to interpret > > > the results. > > > > > > What if we added IMIC style behavioral transistors to SPICE tools? > What if > > > we added > > > IBIS style behavioral buffers (building blocks) to SPICE tools? What > if we > > > added > > > nice and useful measurement statements? Add a front end tool that > reads PCB > > > layout > > > files. Add a 3D graphical output visualization tool to interpret the > > > results. (Some > > > IBIS tools could learn more about this too). > > > > > > No matter how we look at it, it seems to that we are experiencing the > need > > > for a merger > > > between the SPICE world and the behavioral tool's world. It seems to > me > > > that SPICE > > > addresses buffer design, while behavioral tools address system design > with > > > their > > > main features. With the emerging needs in system design, BOTH kinds > of > > > tools are > > > lacking, even though SPICE is still good for buffer design. The real > > > question in my > > > opinion is: How can we improve on our system design tools? > > > > > > What is easier to do? Clean up IBIS and invent a nodal language, > advance > > > the behavioral > > > black box approach with a possible merger with IMIC, add SPICE support > into > > > them though > > > an API, or take the existing SPICE tools and add those "system design" > > > features that > > > IBIS tools have and are good at? > > > > > > I would like to read a lot of replies to this one... > > > > > > Arpad > > > > ============================================================================ > > > ============= > > > >-- End of excerpt from Ted Creedon > > -- > ---Paul Franzon, Professor, North Carolina State University > 919 515 7351, fax. 919 515 2285, www.ece.ncsu.edu/erl/faculty/paulf.html > Rm. 443, Engineering Graduate Research Center, Centennial Campus > smail: ECE, Box 7914, NCSU, Raleigh NC 27695-7914 > Fedex: Rm. 419, EGRC, 1010 Main Campus Dve, NCSU, Raleigh NC 27695-7914 From owner-ibis Mon Nov 22 15:23:01 1999 Received: from tuna.cacc.ncsu.edu (tuna.cacc.ncsu.edu [152.1.192.29]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA23606 for ; Mon, 22 Nov 1999 15:23:00 -0800 (PST) Received: (from paulf@localhost) by tuna.cacc.ncsu.edu (8.8.4/UC02Jan97) id SAA22761; Mon, 22 Nov 1999 18:22:18 -0500 (EST) From: "Paul Franzon" Message-Id: <9911221822.ZM22759@eos.ncsu.edu> Date: Mon, 22 Nov 1999 18:22:13 -0500 In-Reply-To: Ted Creedon "Re: Future directions for IBIS ... IBIS 2000" (Nov 22, 14:14) References: <4575832C8E71D111AC4100A0C96B512704A79ACC@fmsmsx36.fm.intel.com> <3839903F.CB7632F2@mentor.com> <9911221613.ZM22153@eos.ncsu.edu> <3839C044.56E21EDF@mentor.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Ted Creedon Subject: Re: Future directions for IBIS ... IBIS 2000 Cc: "Muranyi, Arpad" , "'ibis@vhdl.org '" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 22, 14:14, Ted Creedon wrote: > Subject: Re: Future directions for IBIS ... IBIS 2000 > Absolutely agree on using university types to help on the language definition > and need for funding. > > RLC will not be satisfactory for all packaging. Need lossy coupled transmission > lines. Sorry, Ted, I was not clear. I meant an RLC matrix in Spice format. This handles losses and coupling. It can also handle frequency-dependent losses in a practical sense (ie. up to a cutoff frequency). The advantages are that the format is well known, widely used and can handle just about anything (though sometimes a little clumsilly e.g. S-parameter information has to be fitted to an RLC ladder network). The disadvantages is needing a smart parser for other formats, e.g. S parameters. It sounds like you are leading towards the concept of the 'Universal parser' for packaging-related info and with some common format. ie. Take in format X, produce simulatable format Y for simulator Z. A lot of these pieces already exist, scattered around various vendors. Also, Verilog-AMS and VHDL-AMS most likely has standards for some of these formats. A Universal parser would be a significant development effort. Many parts of this would have definite value as some of the vendor stuff is very buried in one simulator or expensive. Regards, Paul > > Let's think in the reverse direction - top down. > > Suppose we have the perfect language, what would it do? > > Accept IBIS > Accept Spice > Accept a N port network description language (NDL) > Accept graphical input > Accept measurement based tables of S parameters (or Y or Z) by frequency or NDL > equations > Others I haven't thought about > > The common thread I see here is network description objects. An object being > defined as data and methods in its own container. That is, an object knows > enough about itself to be able to describe itself to you. > > The theory here is that if an object oriented language can be fashioned, we > don't care about the implementation details which is where we're hung up. > > I can share the Agile user manual with whoever, it's not in machine readable > form. It would be possible to stick Agile on a server somewhere so interested > parties could play. Its a Motif/unix app. that uses the linpack nonlinear pde > solvers and it was written in C by 2 RF electrical engineers. Took about 8 man > years including comparing calculated vs. measured results. > > Perhaps a Smalltalk parser and Matlab solver would work for protyping. > > Ted > > > > Paul Franzon wrote: > > > I think both Arpad and Ted raise some very good issues. I would > > like to recommend that the community takes a moment to think where > > they want to take IBIS in the next century....IBIS 2000??? > > > > Feedback/comments are welcome. > > > > Some global comments: > > > > o IBIS succeeded because it created an accepted standard for distributing > > simulatable descriptions of I/O buffers. Prevous attempts at encrypted > > I/O model distrubution basicly failed for a variety of reasons > > (proprietary/custom spices, IP conerns, too much effort, etc.). In > > comparison IBIS is an enourmous success. It solved the 'I dont > > want to/cant give out the Spice netlist for my driver' problem. > > > > o From a technical point of view, the IBIS standard is somehat arbitrary > > in terms of its makeup and is IMHO suffering > > from creeping functionalism. For example (on the arbitrariness), when > > writing 2ibis, we had to make arbitrary decisions about how the > > different > > parts of the circuit response are assigned to the different parts of the > > macromodel. > > (BTW, this does not detract from the utility of the tool at all) > > > > o IBIS does not lead to accurate SSN prediction and IMHO no > > straightforward > > extension will be able handle this or return path issues properly. A > > fresh start is needed. IBIS has already run out of steam for the ultra > > high speed board designer. > > > > Some recommendations for 'IBIS 2000': > > > > o Keep IBIS 1. > > Keep a behavioral standard that can has a large level of agreement > > and buy-in. In fact, do not abandon IBIS as it exists now. > > > > o Change the direction for future IBIS enhancements. > > Here could be some recommendations: > > - From a technical point of view, IBIS should be mainly be a set of > > macromodels that properly capture I/O edges and Vdd and Gnd > > transients. > > (BTW, the latter is somewhat difficult.) Table-based VI > > macro-models are appropriate. > > - It should be possible to produce this macromodel from a Spice netlist > > (S2ibis) or a measurement procedure. > > - It should be possible to translate the macromodels into the more > > popular spice flavours with a very simple 1:1 translation. > > > > o Drop including the package. > > There is no technical reason why IBIS should be getting into package > > parasitic modeling. Why cant vendors just distribute an RLC netlist? > > There is no reason to invent a new standard for this (vanilla Spice > > is fine) and I fail to see how such netlists can be considered > > core corporate IP and thus have to be protected (please let me know > > if this last statement is wrong). > > > > With proper netlists, the accuracy of SSN, package xtalk and return > > path simulation would go up. > > > > o Keep the concept of the IBIS model also documenting SI requirements. > > This is not done properly elsewhere in the documentation, so might as > > well leave it here. > > > > o Keep the concept of an agreed-upon-standard. It has worked well to now. > > > > I do feel that there is a need for fundamental and open work on what > > is needed to accurately model a driver with a macromodel. IBIS 1 > > worked fine just by thinking the issues through a little. IBIS 2000 > > needs some experimental investigative work as to how it should approach > > macromodeling. Eyeballing a model wont work. > > > > That work could be be done in an Industry lab or > > (shameless plug follows) in an open University setting. (SRC would > > be the appropriate sponsor, by the way). > > > > Regards, > > > > Paul > > > > On Nov 22, 10:49, Ted Creedon wrote: > > > Subject: Re: Future directions for IBIS > > > All, > > > > > > Perhaps we should revisit the need for IBIS in the first place. Couldn't > > > proprietary information be distributed through the simulator vendors > > using > > > public/private keying? > > > > > > Regarding the "nodal simulator" discussion, there is a very fine > > modeling > > > language in the documentation for a microwave simulator used for the > > MMIC > > > program in the 90's. I have the source code under license and have read > > the code > > > extensively as well as several versions of Spice code. The MMIC > > simulator does a > > > particularly fine job of goal based parameter optimization, including > > > syntactical representations of typ[min,max] parameter values and also > > does yield > > > analysis based on manufacturing statistical tolerances. > > > > > > It isn't clear how a behavioral simulator would "call" Spice since Spice > > isn't > > > set up to be callable. Spice wants to build the Y matrix from parsed > > input and > > > invert it in the time domain. We should recall that Spice 3f5 is an > > integrated > > > circuit simulator which does not support nonlinear devices in the > > frequency > > > domain (which are used to characterize interconnect). And I don't see > > any > > > analysis tool vendor except one that intends to correlate calculated vs > > measured > > > results (i.e. loss tangent, Er, anisotropic Er, skin effect, surface > > roughness, > > > etc., etc.). > > > > > > The discussion has left out the Boolean capabilities in WSpice which may > > be > > > required to characterize buffers. > > > > > > And all this needs to run in a finite time. > > > > > > The subject of analog design languages has a varied history going back > > to the > > > AHDL workshops at Dartmouth in 1985. The analog designers abandoned the > > effort > > > to the CS majors since the need for graphical input representation > > couldn't be > > > met with a 128 key keyboard! > > > > > > Anyway, this is no small effort. I agree with the basic notion that as > > digital > > > design speeds are now up to 10GHz, and PC designs are running up to > > 400Mhz > > > baseband with 50-100 ps risetimes, the need for microwave style modeling > > is > > > clear. > > > > > > > > > Ted Creedon > > > > > > "Muranyi, Arpad" wrote: > > > > > > > Hi IBIS folks, > > > > > > > > I decided to write this EMAIL on the future directions for IBIS to air > > some > > > > of > > > > my thoughts on this subject. I would like to get you thinking and > > stimulate > > > > a conversation so that we could make good decisions. I will try to > > talk in > > > > general > > > > terms so that we can see things in a broader view, but I will also > > give some > > > > examples to illustrate the issues. > > > > > > > > The spec starts getting out of hand mostly because of the inflexible > > keyword > > > > structure and inconsistencies. Keywords have very specific functions > > and > > > > assumptions, > > > > that's what makes them so inflexible. Inconsistencies prevent the > > reuse of > > > > the same > > > > syntax and/or keyword in different situations. For example, I just > > wrote > > > > BIRD 64, and > > > > found out that what I thought was a very simple addition was > > impossible. I > > > > wanted to > > > > make a package selector keyword that is identical to the model > > selector > > > > keywords, but > > > > it couldn't be done, because the rules are different for the package > > model > > > > names and > > > > buffer model names. One allows 40, the other allows 20 characters. > > One > > > > allows spaces, > > > > the other doesn't. > > > > > > > > I also started to write a BIRD on (what I thought) a simple keyword > > that > > > > would have > > > > allowed the on-die power distribution and return path modeling. It > > would > > > > have > > > > resembled the [Pin Numbers] keyword from the package section, except > > it > > > > would have > > > > described the interconnect between die pads and buffer models on the > > die. > > > > The idea > > > > is great, but syntactically does not work out as simple as it could. > > Why? > > > > Because > > > > the [Pin Numbers] keyword depends on a few other keywords ([Number of > > Pins], > > > > [Number > > > > of Sections], [Model Data], etc). They could all be reused, but two > > changes > > > > would > > > > have to be made in two of those keyword's usage rules. Besides, these > > > > keywords are > > > > all called "package" something, and it would be too confusing to > > describe > > > > die-interconnects > > > > with keywords that are called "package" something. So the next option > > would > > > > be to > > > > basically copy the whole package chapter with these minor name and > > rule > > > > changes into > > > > a brand new chapter called "Die Interconnect Modeling". This, > > however, > > > > increases the > > > > size of the specification, duplicates a lot of things but also > > increases the > > > > number > > > > of inconsistencies. > > > > > > > > Thinking about this problem I started to wonder whether I could use > > the EBD > > > > or new > > > > connector proposal, but I realized that each one of these have some > > specific > > > > characteristics which result in the same situation. > > > > > > > > To sum it up, we have four areas for interconnect modeling, each of > > which > > > > needs a separate > > > > chapter in the spec. This is ridiculous, because each of these are > > > > interconnect models! > > > > We should be able to come up with a syntax that is general enough to > > handle > > > > them all! > > > > > > > > I don't want to hold back the approval of the new connector spec. We > > need > > > > it badly, > > > > and it is way too late. I am just talking about all this so we can > > make a > > > > better plan > > > > for the future. > > > > > > > > Now, we have an option to take the spec and rigorously look at all > > these > > > > syntactical > > > > problems and clean it up and make it more efficient. However, at the > > same > > > > time we > > > > are beginning to feel the need for nodal connectivity. The new > > connector > > > > spec proposal > > > > introduces nodal connectivity in the [Begin_Cn_Pin_Map] keyword into > > IBIS. > > > > Stephen's > > > > IBIS-X proposal revolves heavily around nodal structuring, and I was > > going > > > > to use > > > > something similar to the [Begin_Cn_Pin_Map] in my unfinished > > > > die-interconnect BIRD > > > > also. So we all agree that this is a must. The question is whether > > we > > > > should do it > > > > through "mapping" keywords, or the good old SPICE way (or any other > > newly > > > > invented > > > > syntax). > > > > > > > > Regarding buffer modeling: Stephen's proposal of an API is > > essentially a > > > > hook to > > > > SPICE simulators from behavioral tools which would be used mostly when > > there > > > > are new > > > > features that can't be described by existing IBIS keywords. Can't do > > it in > > > > IBIS, so > > > > do it in SPICE (from an IBIS simulator). Again, it seems that we want > > SPICE > > > > capabilities. But why? Because IBIS is inflexible. What if IBIS > > could do > > > > what > > > > IMIC can do? Describe a buffer on a transistor level with behavioral > > > > transistors. > > > > Or take an intermediate level, describe a buffer with a building-block > > > > architecture, > > > > using primitives. A primitive could be as low as an IMIC behavioral > > > > transistor, > > > > but could be a basic inverter, or a block of the whole buffer, such as > > > > predriver, > > > > output stage, receiver, etc. This way one could put together a model > > > > behaviorally, > > > > using any level of abstraction according to the need of the buffer's > > > > characteristics. > > > > However, this would also require nodal connectivity. > > > > > > > > Oh yes, I almost forgot about equations. These are a special kind of > > > > controlled > > > > sources. Yes, behavioral. Allowing any node to be connected to > > another > > > > node by > > > > any function (S-parameter, and you name it). In a general case they > > let you > > > > reference any node voltage and/or branch current a part of the > > equation (not > > > > all > > > > SPICE tools do this well). These animals can't exist without a nodal > > > > approach > > > > either. > > > > > > > > So we want nodal connectivity a netlist type approach for any level of > > > > abstraction, > > > > behavioral and possibly full SPICE description capabilities. Doesn't > > this > > > > sound > > > > like a SPICE with enhanced behavioral elements? > > > > > > > > Let's turn around the picture. What does SPICE not have that IBIS > > has? > > > > Most SPICE > > > > flavors do not do too well on behavioral modeling, and board level > > > > simulation hooks. > > > > Board file readers are missing, measure statements are stone age > > style. The > > > > simulation > > > > results are in raw data format, and there are no good post processing > > tools > > > > to interpret > > > > the results. > > > > > > > > What if we added IMIC style behavioral transistors to SPICE tools? > > What if > > > > we added > > > > IBIS style behavioral buffers (building blocks) to SPICE tools? What > > if we > > > > added > > > > nice and useful measurement statements? Add a front end tool that > > reads PCB > > > > layout > > > > files. Add a 3D graphical output visualization tool to interpret the > > > > results. (Some > > > > IBIS tools could learn more about this too). > > > > > > > > No matter how we look at it, it seems to that we are experiencing the > > need > > > > for a merger > > > > between the SPICE world and the behavioral tool's world. It seems to > > me > > > > that SPICE > > > > addresses buffer design, while behavioral tools address system design > > with > > > > their > > > > main features. With the emerging needs in system design, BOTH kinds > > of > > > > tools are > > > > lacking, even though SPICE is still good for buffer design. The real > > > > question in my > > > > opinion is: How can we improve on our system design tools? > > > > > > > > What is easier to do? Clean up IBIS and invent a nodal language, > > advance > > > > the behavioral > > > > black box approach with a possible merger with IMIC, add SPICE support > > into > > > > them though > > > > an API, or take the existing SPICE tools and add those "system design" > > > > features that > > > > IBIS tools have and are good at? > > > > > > > > I would like to read a lot of replies to this one... > > > > > > > > Arpad > > > > > > ============================================================================ > > > > ============= > > > > > >-- End of excerpt from Ted Creedon > > > > -- > > ---Paul Franzon, Professor, North Carolina State University > > 919 515 7351, fax. 919 515 2285, www.ece.ncsu.edu/erl/faculty/paulf.html > > Rm. 443, Engineering Graduate Research Center, Centennial Campus > > smail: ECE, Box 7914, NCSU, Raleigh NC 27695-7914 > > Fedex: Rm. 419, EGRC, 1010 Main Campus Dve, NCSU, Raleigh NC 27695-7914 > >-- End of excerpt from Ted Creedon -- ---Paul Franzon, Professor, North Carolina State University 919 515 7351, fax. 919 515 2285, www.ece.ncsu.edu/erl/faculty/paulf.html Rm. 443, Engineering Graduate Research Center, Centennial Campus smail: ECE, Box 7914, NCSU, Raleigh NC 27695-7914 Fedex: Rm. 419, EGRC, 1010 Main Campus Dve, NCSU, Raleigh NC 27695-7914 From owner-ibis Mon Nov 22 16:00:48 1999 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA23718 for ; Mon, 22 Nov 1999 16:00:48 -0800 (PST) Received: from mediaone.net ([24.218.144.159]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id TAA14010 for ; Mon, 22 Nov 1999 19:00:00 -0500 (EST) Sender: csrode@chmls06.mediaone.net Message-ID: <3839D9F5.D63650FC@mediaone.net> Date: Mon, 22 Nov 1999 19:04:05 -0500 From: "Christian S. Rode" X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686) X-Accept-Language: en MIME-Version: 1.0 To: ibis@vhdl.org Subject: XMLSPICE (Re: Future directions for IBIS) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If I had a vote, it would be for an XML-based syntax that is essentially structured SPICE. It should include BSPICE (only because it's freely available) implementations of nominal/best/worst buffer or connector _in addition to_ VI/VT/etc tables. It's almost SPICE, so it's extensible and it has data structure to it that behavioral simulators can read and modify. You may need to limit what SPICE elements can be used to controlled sources, R's, L's(K's), C's and T's (...and?). And lossy elements will need to be addressed soon... No concrete syntax suggestion yet. I just spent about a minute just now looking at the IMIC spec, enough to think that it could benefit from XML structure. Anybody know of other SPICEs, besides Apsim's, that handle the EIAJ TABLE extension? Chris Rode From owner-ibis Tue Nov 23 04:21:30 1999 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id EAA27799 for ; Tue, 23 Nov 1999 04:21:15 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id GAA24075 for ; Tue, 23 Nov 1999 06:20:41 -0600 (CST) Received: from smtp2.molex.com(150.150.15.101) by molexinc-bh.molex.com via smap (4.1) id xma024045; Tue, 23 Nov 99 06:19:42 -0600 Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 00086D04; Tue, 23 Nov 99 06:17:07 +0000 Mime-Version: 1.0 Date: Tue, 23 Nov 1999 06:11:30 +0000 Message-ID: <00086D04.CE21031@molex.com> Subject: Re[2]: Future directions for IBIS ... IBIS 2000 To: "Paul Franzon" , Ted Creedon Cc: "Muranyi; Arpad" , ibis@vhdl.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part In the "for what it's worth" category: For a little while now, some of us have been deeply involved with the creation of a connector model specification. Included in the PROPOSED specification (THIS IS NOT A FINAL SPECIFICATION YET): * SLM: Single Line Model definition (non-coupled) * MLM: Multi Line Model definition (COUPLED) * CMLM: Cascaded Multi Line Model definition (COUPLED) * Matrix based modeling * by R, L, C matrices (Inductance matrix is a "partial inductance matrix") * Fixed Pin mapping (to help facilitate nodal style interconnects) * Floating pin mapping (pin mapping set up to be flexible to accept different size models. (Does this mean that there is a provision to create a variable size model.. based on the matrix construct?.... Yes, it does!) * "Swath" matrix operator... basically allows the inclusion of a variable size model (especially for connectors). Kind of like an automated banded matrix. * Ability to cascade matrices. As such one connector (interconnect?) model can be made up of multiple cascaded and stub matrices. As such, keeping some (most) frequency dependence. Obviously, this really depends on the "completeness" the model creator. (There is also a "minimum risetime definition" in the model to help assist users of the model) * coupling * expanded line length * included a reference to jpg file for the model * model ftp / www site address for updates Some of the items could be added into the general spec if deemed worthy. What we did not put in to the specification at this time: * Behavioral modeling of interconnects. The most popular way to do this for an interconnect is probably s-parameters. This is seen as a potential FUTURE upgrade to the specification. As it was thought that the most important thing to do was to get some interconnect models into the IBIS stream. * The specification was set up to deal with most (99%??) of today's connector issues. As such it can deal with many other interconnect issues as well (package, cable, other?).... but, it is not perfect for them. For example... cables.... for cables, it would probably be nice to have Propagation Delay and Impedance (maybe admittance too?) matrices directly. Yet, another future upgrade....?? Other issues: * With SPICE, it was generally known how Berkeley SPICE will handle: L, C, R, and k values. Unfortunately, we do not have the luxury with non-SPICE simulators that use IBIS. * With the creation of connector SPICE models... The model creator controlled the "circuit" generated from the matrix. In this case, each simulator will be able to generate one or more kinds of circuit for each R,L,C matrix set. This can be good and bad. * It will still be possible for someone to connect a "perfect ground" to both sides (input and output ports) of a connector. This will effectively ruin the simulations based on that circuit construction that use COUPLED models. The more that I follow the list.. the more I think that the standard IBIS "I/V" curves are generated by the use of a "perfect ground". Hopefully, simulators do not need to assign a "perfect ground" in the every equation that references a IBIS semiconductor model. BOTTOM LINE: Every connector that can be represented by a SPICE model today.. can also be represented by the matrix approach in the Connector Specification. I am not sure on the access that you may have to the "0.92 PROPOSED IBIS Connector Specification. If required, I can supply a URL to the site. _gus: 630-969-4617 apanella@molex.com ____________________Reply Separator____________________ Subject: Re: Future directions for IBIS ... IBIS 2000 Author: "Paul Franzon" Date: 11/22/99 6:22 PM Sorry, Ted, I was not clear. I meant an RLC matrix in Spice format. This handles losses and coupling. It can also handle frequency-dependent losses in a practical sense (ie. up to a cutoff frequency). The advantages are that the format is well known, widely used and can handle just about anything (though sometimes a little clumsilly e.g. S-parameter information has to be fitted to an RLC ladder network). The disadvantages is needing a smart parser for other formats, e.g. S parameters. It sounds like you are leading towards the concept of the 'Universal parser' for packaging-related info and with some common format. ie. Take in format X, produce simulatable format Y for simulator Z. A lot of these pieces already exist, scattered around various vendors. Also, Verilog-AMS and VHDL-AMS most likely has standards for some of these formats. A Universal parser would be a significant development effort. Many parts of this would have definite value as some of the vendor stuff is very buried in one simulator or expensive. Regards, Paul From owner-ibis Tue Nov 23 16:13:35 1999 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA01100 for ; Tue, 23 Nov 1999 16:13:34 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id TAA29107 for ; Tue, 23 Nov 1999 19:12:26 -0500 (EST) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id TAA06979 for ; Tue, 23 Nov 1999 19:12:25 -0500 (EST) Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id QAA22807 for ; Tue, 23 Nov 1999 16:12:53 -0800 (PST) Date: Tue, 23 Nov 1999 16:12:53 -0800 (PST) From: Guy de Burgh Message-Id: <199911240012.QAA22807@taurus.camarillo.viewlogic.com> To: ibis@eda.org Subject: 11/19/99 EIA IBIS Open Forum Meeting Minutes DATE: 11/23/99 SUBJECT: 11/19/99 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: Applied Simulation Technology Raj Raghuram*, Norio Matsui, Neven Orhanovic, Fred Ballesteri Avanti Nikolai Bannov Cadence Design Mike LaBonte*, Todd Westerhoff Cisco Systems Syed Huq* Compaq Bob Haller*, Steve Coe, Shafir Rahman, Maher Elasad, Peter LaFlamme, Doug Burns Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella, Alex Nosovitski, Shan Haq Fairchild Semiconductor [Peter LaFlamme], Craig Klem, Graham Connolly, Christian Klein H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu HyperLynx (& Pads Software) Matthew Flora*, Kellee Crisafulli*, Lynne Green, John Angulo*, Gene Garat, Robin Edwards IBM Greg Edlund, Michael Cohen*, Praven Patel, Paul Clouser 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, Tom Dagostino, Mohamed Nasef Mitsubishi (Tam Cao) Motorola Ron Werner* National Semiconductor Milt Schwartz* North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda, Ed Sayre III, Jinhua Chen NEC (Hiroshi Matsumoto) Nortel Networks Martin Hall (& at Viewlogic), Calvin Trowell Ross Pryor 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 Time Domain Analysis Systems Dima Smolyansky, Steven Corey Viewlogic Systems Chris Rokusek, Guy de Burgh, Cary Mandel, (Jon Powell) VeriBest [Ian Dodd] Via Technologies (Weber Chuang) VLSI Technology D.C. Sessions OTHER PARTICIPANTS IN 1999: 3Com Roy Leventhal 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 Celestica Danny Da Silva Dynamics Research Corporation Mike Walsh ECI Telecom Daniel Adar EIA [Patti Rusher], Cecilia Fleming, Dan Heinemeier Electronique Catherine Gross EFM Consulting Ekkehard Miersch FCI John Ellis Foxcomm Jeff Walden General DataComm Laurence Michaels High Design Technology Razvan Ene Hitachi ULSI Hideki Fukuda Infineon Thomas Latzel Intracon Design Mike Osmond KAW Shinichi Maeda Litton Systems Robert Bremer Lucent Jason Pritchard Matsushita Atsuji Itoh Molex Incorporated Gus Panella Newbridge Networks Bruce Carlile Oce Printing Systems Ernst Deiringer Praegitzer Design Rick Newell, Paul Galloway, Joe Socha Rockwell Collins Susan Tweeton, Ron Hau Rode Consulting Chris Rode Samsung Jung-Gun Byun, Cheol-Seung Choi Shindengen Tsuyoshi Horigome Signals & Systems Engineering Tom Hawkins STMicroelectronics Fabrice Boissieres, Philippe LeFevre Stratus Keith Vieira StorageTek Nick Krull Sun Microsystems Victor Chang Kevin Ko, Greg Fitzgerald, Nick LaPlaca 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 December 3, 1999 (916) 356-9200 2-368940 5714412 December 17, 1999 (916) 356-9200 2-368942 8917482 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 Ron Werner of Motorola joined and introduce himself as a user of IBIS models and also as the Chair of the Design Automation Division at EIA under which the EIA IBIS Open Forum resides. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross indicated that the membership still is at 32, but this will drop to 30 next year due to some acquisitions of member companies by member companies. Bob indicated that Cecilia Fleming (who could not attend this meeting) is allocating several thousand dollars of royalty revenue to the IBIS Committee based on the re-distribution of revenues from a discontinued EIA Committee. REVIEW OF MINUTES AND AR'S The October 29, 1999 IBIS Open Forum Meeting minutes were approved without change. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Syed Huq indicated that there is a Siemens roster update. He also added new links on EIA IBIS Home page for Connector Info and (later in the meeting) for the s2ibis3 Project. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross indicated that Jon Powell plans to update the Model Page next week. Bob also indicated more IBIS models now exist under several company links, and/or the pages have been re-located for Philips Semiconductor, TI, and Motorola. Some IBIS model links appear to have disappeared probably as result of mergers and acquisitions (for example, IC Works and Quality Semiconductor). The Hewlett Packard link for the VCSEL Transceiver IBIS Mole is now under the Agilent link: http://www.semiconductor.agilent.com/fiber/ibis.html Matthew Flora reported that the Intel PCI-to-PCI Bridge IBIS Models are under: http://developer.intel.com/design/bridge/ibis/index.htm OPENS FOR NEW ISSUES Scott McMorrow on BIRD66 - [Model Spec] Vref Addition INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Bob Ross had no further progress report from Cecilia Fleming. However formal ratification of IBIS Version 3.2 as IEC 62104-1 is still expect shortly (months or less). - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross had no further report and repeated from last meeting that a Version 1.2 has been posted for review with a deadline of December 25, 1999. Note added after the meeting: the link to the document has been moved and is now located at the bottom of: http://tsc.eiaj.or.jp/eds/iopg.htm - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross had no report. - JC-16.2 Subcommittee: Modeling and Test - Bob Ross had no report. DESIGNCON 2000 IBIS SUMMIT PLANNING Bob Ross stated that the IBIS Summit meeting is being held on Monday, January 31, 2000 in Santa Clara, California. The IBIS Open Forum is listed again as an Associate Sponsor of DesignCon 2000 which means that DesignCon is providing the meeting room and refreshments and also booth space. Milt Schwartz offered that National Semiconductor is sponsoring again the buffet luncheon. He also stated that presenters may send him electronic copies, and National Semiconductor will make copies available at the meeting. Bob indicated that Jon Powell will be providing the booth and coordinating the setup. He plans again to have IBIS Open Forum member company logos posted on the backdrop. It will be a place to meet, pick up literature, and possibly host an electronic accuracy demonstration. Bob stated plans that we will be sending out the first notice in early December. We do have several presentations and will plan on some extended discussions on some of the new topics that are now being considered. DATE2000 IBIS SUMMIT PLANNING Bob Ross commented that the DATE2000 IBIS Summit meeting associated with the Design Automation and Testing in Europe conference is still planned to be held in Paris, France on Friday, March 31, 2000. However, the meeting date may be moved up to Monday, March 27 in order to find a suitable room. Mentor Graphics and Incases are co-sponsors, but others are expected. The PCB Symposium is scheduled for Thursday, March 30, 2000. S2IBIS3 COMMITTEE REPORT Michael Cohen listed and thanked the participants of the Spice to IBIS subcommittee for the work done, and particularly Syed Huq for serving as the editor of a draft requirements document. Several weekly meetings were held, and the document is now ready for the IBIS Open Forum to review. Syed stated that a link exists to the directory where the document resides from the IBIS Home Page under s2ibis3 Project: http://www.eia.org/eig/ibis/ibis.htm or directly from http://www.eda.org/pub/ibis/s2ibis3/ Everyone is invited to review and comment on the contents of the document. The committee wants feedback before it is officially released. Michael stated that the next meeting is planned for Thursday, December 2, 1999 to draft a letter requesting bids on the requirements. Raj Raghuram voiced his concern that this project may compete with existing commercial products and questioned whether it was appropriate for the IBIS Open Forum to pursue this. Furthermore, the IBIS Open Forum had visibility of such products. We discussed this briefly, and Bob Ross asked to plan further discussion at the next meeting since we had several other topics to discuss. IBIS DUES AND FUNDING Bob Ross reported on the e-mail ballot votes tallied by Guy de Burgh (who could not attend this meeting) plus some votes from attendees at the meeting that were either not sent or not yet received and reported by Guy. The total official vote to change the yearly IBIS Open Forum dues to $750.00 is 23 YES, 2 NO, and 7 No-responses. Bob reported each company's vote at the meeting. Bob then stated that two of the No-responses were from companies that had merged with other member companies that had voted YES. Bob considered that their vote could be also be counted as YES. However, these additional votes were not technically needed. Consistent with the most stringent internal IBIS requirement that two-thirds (21) of the official EIA IBIS Open Forum Members must approve a Charter change, the new rate is official approved. NEW IBIS OFFICER POSITIONS Bob also reported on the e-mail ballot votes tallied by Guy de Burgh the vote on the Charter change to add the Postmaster and Webmaster positions as official EIA IBIS Open Forum officers. Bob also collected unreported votes at the meeting. The official vote is 24 YES, 0 NO and 8 No-responses. Bob reported each company's vote at the meeting. Although not technically needed, two of the No-response votes could also fall in the YES category. The Charter revision creating the new positions is officially approved. The revised section that was published in the October 29, 1999 minutes is repeated for reference: Position Responsibilities ----------------------------------------------------------------------------- Chairperson Oversee all forum activities, preside at all general meetings. Finance authority. This person must be an employee of a Membership Company. Vice Chair Cover for chair and secretary in their absence, coordinate all public relations (press releases, media contacts). This person must be an employee of a Membership Company. Secretary Coordinate logistics of all meetings, take and publish meeting minutes within 10 days of meeting. [Delete this task since it is transferred to the Postmaster: Work with or act as file server sysop to maintain the reflector and on-line files.] This person does not need to be an employee of a Membership Company. Librarian Maintain the library of public IBIS models, including verifying authenticity and compliance before posting. This person does not need to be an employee of Membership Company. Webmaster Maintains the contents of the official EIA IBIS Open Forum Web site and Roster files under www.eia.org either directly or through contact with EIA staff. This person does not need to be an employee of a Membership Company. Postmaster Maintains the e-mail distribution lists and performs file server sysop activities for the on-line files on the IBIS site: www.eda.org/pub/ibis/. This person does not need to be an employee of a Membership Company. CONNECTOR PROPOSAL Bob Ross moved the Connector Proposal discussion originally scheduled at the very end as the next item in the Agenda since Kellee Chrisafulli had to leave early. Kellee provided background information that a sub-committee of EDA vendors and connector vendors produced a draft connector specification document. The draft was presented at the February 1, 1999 IBIS Summit Meeting and was also uploaded for review. Several comments were made at that meeting. Most of the comments dealt with additional clarifications. The revised document is now available for review and for the IBIS Open Forum to take action. Kellee reported that the sub-committee decided to focus only on modeling connectors since that was the compelling need and also not to get bogged down in some more general issues associated with package models and electrical board descriptions. Kellee indicated that a previous proposal by the IBIS Open Forum might have died because it tried to be too general. Kellee stated that the new ideas in the connector document could be applied to package models in the future. Also, after further investigation, Kelly stated that the sub-committee decided to postpone dealing with frequency dependent losses. However, he saw no barrier to including them in a future version. As stated earlier, the link to the Connector Specification directory that contains the latest documents is now available from the EIA IBIS Home page and is also accessible directly at: http://www.eda.org/pub/ibis/connector/ Stephen Peters and Arpad Muranyi asked several clarifying questions on whether the (frequency dependent) conductance matrix was included, and Kellee responded that it was not. Furthermore he stated that the decision to postpone losses was made after consulting with a number of internal technical experts. Arpad stated that he reviewed the document and did not find any reference to length statements. Kellee thought that this was an oversight. Bob Ross stated that the IBIS Open Forum needed to look and validate the big decisions and also comment on the small issues. The February 1, 1999 IBIS Summit presentation which contains some committee rationale is also in the location above. The big issues include keeping the document focused on connectors only (versus expanding it to included packages and Electrical Board Descriptions), using the matrix methodology similar to the coupled package model methodology in the IBIS Standard (versus a nodal or Spice-like methodology), checking the EDA and connector vendor support, and deferring losses. The smaller issues deal with syntax alignment, with IBIS and some syntax and keyword decisions that are different from IBIS. Bob also commented that some sample connector models that were originally on the CD ROM given to attendees at the February 1, 1999 IBIS Summit Meeting were not uploaded. Kellee responded that he will check that the examples are consistent with the revised syntax and will work with Matthew Flora to upload the examples. Scott McMorrow raised the issue that modern connectors have tolerances and that minimum and maximum models are needed along with typical models. He also presented some ideas on syntax. Arpad suggested multiple connector models. Bob asked to postpone the discussion until the BIRD64 discussion since Scott had recently raised a similar concern on the BIRD64 proposal. Arpad asked whether the document would be processed as a separate document or a section in the IBIS document. Kellee stated that he would like to see the document as an official section in the IBIS document (along with package models, Electrical Board Descriptions). However, it is currently structured as a stand-alone document. Bob felt that it would be easier to deal with the document as a stand-alone document. The overall IBIS document was becoming very large and there were other IBIS issues being considered that could slow down the release of the connector document if it were to be included as part of IBIS. Bob outlined a scenario similar to the one used to ratify various levels of IBIS. The EIA IBIS Open Forum could seriously review the document and then ratify it at a "Version 1.0" level once all the issues have been resolved. A separate Connector BIRD process might be used if a number of issues were raised. This would stabilize the syntax. Then a parser could be developed to check the syntax and also to independently review and uncover confusing or unclear sections in the document. A number of editorial and possibly minor technical changes would be made, and the revised document would be ratified at the Version 1.1 level. Then it might be forwarded to EIA for a public letter ballot review as part of the national EIA and ANSI ratification process. Ron Werner concurred with this approach and suggested that we continue to process the Connector document as an independent document. COOKBOOK STATUS The normal Agenda sequence was then resumed. Stephen Peters had no report. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora reported that a new model from Intel has been distributed for review. BUG34 - NO ERRORS REPORTED FOR MISSING V/I TABLES IN OUTPUT BUFFERS Bob Ross asked Matthew Flora to defer the discussion on BUG34 until a later meeting. Unlike some of the BUGs where a simple solution exists, this bug contains some enhanced Warning messages that need to be discussed. Bob plans to send this BUG out to the IBIS reflectors for reference. Also, we need to decide who will provide the fix. Currently two minor BUGs have been fixed, but they not significant enough to go through the processes to issue a new ibischk3 release at this time. BIRD61 - ENHANCED CHARACTERIZATION OF RECEIVERS BIRD62 - ENHANCED CHARACTERIZATION OF RECEIVER THRESHOLDS (discussed First) BIRD63 - DOCUMENTATION OF RECEIVER SETUP AND HOLD TIMING CONDITIONS Stephen Peters still has not had time to provide updates and corrections to BIRD62 and BIRD63 in response to comments. Stephen also stated that BIRD61 needs some further work to describe behavioral receivers. He expects Don Telium of Cadence to present some ideas at the IBIS Summit meeting on January 31, 2000. While not directly related to the above BIRDs, Bob Ross mentioned that the IBIS Committee is at a cross-roads. The Version 3.2 document is already quite large. It can be improved, but we need to decide between some fundamental and possibly overlapping approaches that are now being proposed. So the content of IBIS Version 4.0 might be just minor specification and technical improvements associated with current technology or it might include some major additions. Some proposals and activities include: IBIS Version 4.0 Specification additions (including BIRDs 62, 63, 66) Input Modeling Simulation (BIRD61) Other Version 4.0 technical details (BIRDs 64, 65, and more) IBIS-X to be discussed later, possible alternative BIRDxxx, and possible inclusion of an application programmable interface (API). Possibly resurrecting older proposals related to SSO, ground bounce. Spice and IMIC links Considering analog VHDL Connector Specification Other Activities - Spice to IBIS, Accuracy Specification, Education, etc. Bob concluded that at least some minor refinements to IBIS Version 3.2 leading to IBIS 4.0 are needed and can be ratified at this time without conflicting with other possible approaches. BIRD64 - PACKAGE MODEL SELECTOR Bob Ross and Arpad Muranyi commented on some of the alternatives presented in response to BIRD64 to allow package model selections for an IBIS Component. These alternatives include: Do nothing, just issue separate component models Use [Package Model Selector] to list separate choices as in BIRD64 Use [Package Model Selector] in a manner similar to [Model Selector] (also extend [Package Model] syntax to include typ, min, max models) Scott McMorrow discussed another option that he recently presented on the IBIS reflector. He proposed a syntax for using the [Package Model Selector] for different packages, and each of these packages would have columns for typ, min and max models. Scott argued that this extension would also be useful for Electrical Board Descriptions and would avoid loading several Component models for the same component. The newer syntax would also support having EDA tools doing package model selection automatically for corner analysis. Scott gave an example of a 208 pin BGA. He stated that the typical column package model might reference the single line model, the minimum column model might reference the odd-mode extraction, and the maximum column model might reference the even-mode extraction. More discussion occurred. Bob commented that there were two different applications. One application was to select different packages and one was to select typ, min, and max variations of the same package. An original, IBIS assumption has been that detailed pin level models gave would be relatively constant compared to the wider electrical variations between typ, min, and max I/O buffer models. We ended the discussion in order to move on to the next Agenda items. BIRD65 - C_comp REFINEMENTS Bob Ross commented that BIRD65 might be an easy technical addition to ratify, but needs to be considered in the context of some other fundamental proposals that might better deal with current distribution details. Bob asked Arpad to defer the discussion so we could move on to other Agenda topics. BIRD66 - [Model Spec] Vref ADDITION (Inserted Agenda Item) Scott McMorrow introduced BIRD66, He proposed adding Vref as a [Model Spec] subparameter to allow different Vref values for min and max voltage settings. Scott argued that this variation is needed to support certain technologies such as SSTL. Bob Ross commented that we have considered this before and will need more time to discuss it fully. BIRD66 opens the door again for allowing other possibilities such as also allowing min and max Rref and Cref values, adding an Rseries element in the test load (as in SSTL) and also specifying independent loads for rising and falling edges (such as those used in some PCI specifications.) IBIS-X In the remaining time Stephen Peters introduced a general IBIS-X proposal that he recently sent to the IBIS reflector. The issues he wanted to address are: The IBIS document is becoming too complex Extensions are needed for detailed power and ground return path analysis Behavioral receiver models are needed An Application Program Interface (API) escape mechanism is needed for solutions which have not been standardized (such as nodal syntax and black box support) Stephen started by questioning what is need to support an API. The elements of the IBIS-X proposal then evolved. Like IBIS, IBIS-X is component centric. However, it is not entirely backward compatible. It contains some of the more useful IBIS syntax and table structure, but uses a [Begin Component] and [End Component] and [Begin Model] and [End Model] module structure. The Model syntax is expanded to include ports to document the ground and power connections. Arpad Muranyi stated that he agrees with the goals. In general he sees the benefit of having IBIS (with specification detail) and having Spice. In fact Arpad stated that would be nice if Spice Vendors would add specification detail. Arpad also has a potentially simpler "BIRDxxx approach based on some keyword additions to IBIS to add a [Die Interconnect] section. This would be in addition to the Package Model, Electrical Board Description, and possible Connector sections Bob Ross concluded the discussion by briefly presenting some more elements contained in the IBIS-X proposal: Proposed BIRD6x keywords: [Reference Voltage] [Driver Spec] [Receiver Spec] Port list Nodal syntax addition for L, R, C, I, V, S (equations) and X (subcircuits) [Submodel] Bob indicated that the discussion will be continued. NEXT MEETING: The next teleconference meeting will be on Friday, December 3, 1999 from 8:00 AM to 10:00 AM. The following meeting will be on Friday, December 17, 1999. Two meetings spaced two weeks apart were scheduled so that we could devote more time to the significant technical issues that are now emerging. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-209 2111 NE 25th Ave. Hillsboro, OR 97124-5961 SECRETARY: Guy de Burgh (805) 988-8250, Fax: (805) 988-8259 gdeburgh@viewlogic.com Senior Manager, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jpowell@viewlogic.com Senior Scientist, Viewlogic Systems 1369 Del Norte Rd. Camarillo, CA 93010 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Signal Integrity Engineer, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 114715 N.E. 95th Street Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org/eig/ibis/ibis.htm/ Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Wed Nov 24 04:56:23 1999 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id EAA05505 for ; Wed, 24 Nov 1999 04:56:22 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id GAA04188 for ; Wed, 24 Nov 1999 06:55:45 -0600 (CST) Received: from smtp2.molex.com(150.150.15.101) by molexinc-bh.molex.com via smap (4.1) id xma004148; Wed, 24 Nov 99 06:55:00 -0600 Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 00089747; Wed, 24 Nov 99 06:52:22 +0000 Mime-Version: 1.0 Date: Wed, 24 Nov 1999 06:47:09 +0000 Message-ID: <00089747.CE21031@molex.com> Subject: Frequency Dependent and Lossy To: ibis@eda.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part First, To the entire group... I am sorry that I missed the last meeting. I was fully planning on being there... had an unfortunate incident that came up that need my immediate attention... I will plan on being at the next meeting. However, in the spirit of helping... I would like to address a few of the comments from the meeting notes: This email topic: "Stephen Peters and Arpad Muranyi asked several clarifying questions on whether the (frequency dependent) conductance matrix was included, and Kellee responded that it was not. Furthermore he stated that the decision to postpone losses was made after consulting with a number of internal technical experts." In my mind there are two issues built into this statement: 1. Frequency dependence: At this time a "FREQUENCY DEPENDENT COMPONENT" is not built into the specification... However... CASCADED MATRICES are built in to the specification. The cascaded matrix allows the model to represent asymetrical or symetrical filtering effects that are typically found in interconnect structures with multiple discontinuities (i.e. allows you to represent a pole/zero as they actually occur as the energy passes through the length of the interconnect). Thus representing each discontinuity on it's own.. in a series and/or stub configurations. As such, it is quite reasonable to expect that by using a cascaded model, it is possible to extend the operation point of a model to the limits of the performance limits of the interconnect being modeled. With BERKELEY SPICE models (no vendor specifi SPICE extensions required) , using a cascaded modeling approach... today, a 6GHz 3dB bandwidth is a typical modeling requirement (9GHz. is also possible). Yes this can be confirmed to both frequency domain and time domain lab measurements. Further, I would also suggest that a frequency dependent component is really something more than just a swept series resistance that varies as a function of frequncy in a single lumped model. As such, to do a true frequency dependent model, something more like a behavioral model (s-parameters anyone?) would be the most appropriate method of representation. 2. Conductance matrix: At this time a conductance matrix as such is not built in to the specification. I think that when this effect comes into play (I do not have supporting data, but my guess that conductance becomes significant at frequencies greater 8 GHz. ....at least in devices as short as connectors) that the "s-parameter" solution would be the best solution to correctly implement dielectric loss effects. So why noy implement s- parameters now * Model complexity.... the connector matrix models that are setup in the proposed connector specification can be in the 100's to 1000's of lines. I've seen (and created) mulitport s-parameter models that are 100x the size. Of course, this depends on the frequncy step size and frequncy range of the model. * We really wanted to incorporate an unlimited pin size connector using a "swath" as proposed in the specification. As the s-parameter matrix is not a "single value per coupling / self node" (like , for instance an inductance matrix would be)... I had no idea on how to handle the complexity of a swathed s-parameter. * Many simulators that use IBIS models are time domain based... the complexity of adding s-parameters may be too difficult. * The proverbial , We approached the proposed specification with a "Walk before you run philosophy". * We also wanted to focus on the connector models that are primarily available today... and be able to implement those as soon as possible into a new format. _gus: 630-969-4617 apanella@molex.com From owner-ibis Wed Nov 24 05:00:29 1999 Received: from mail.huawei.com.cn ([202.96.135.132]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA05540 for ; Wed, 24 Nov 1999 05:00:09 -0800 (PST) Received: from huawei.com.cn ([10.11.72.32]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA28682; Wed, 24 Nov 1999 20:56:43 +0800 Message-ID: <383BE01A.7D46CD10@huawei.com.cn> Date: Wed, 24 Nov 1999 20:54:50 +0800 From: sunweifeng X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ibis-users , "ibis-vhdl.org" Subject: Help Content-Type: multipart/alternative; boundary="------------6BD24409C4129EB8858344EE" --------------6BD24409C4129EB8858344EE Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Hi Sir, I used the s2ibis2 to transit the spice model to ibis model. I run the demo under the directory ex1, and there following note when run "s2ibis2.solaris buffer.s2i" : s2ibis2.solaris v1.1 -- North Carolina State University s2ibis2.solaris: Reading input file buffer...done. s2ibis2.solaris: Analyzing component MCM Driver . s2ibis2.solaris: Starting HSpice job with input putout.spi. s2ibis2.solaris: Error in executing HSpice. s2ibis2.solaris: Error 0 s2ibis2.solaris: Fatal error. However it is OK when run "hspice buffer.sp", would please tell me why? Thank you very much. Best Regards, Sun Weifeng --------------6BD24409C4129EB8858344EE Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 7bit Hi Sir,

  I used the s2ibis2 to transit the spice model to ibis model. I run the demo under the directory ex1, and there following note when run "s2ibis2.solaris buffer.s2i" :
s2ibis2.solaris v1.1 -- North Carolina State University
s2ibis2.solaris: Reading input file buffer...done.
s2ibis2.solaris: Analyzing component MCM Driver .
s2ibis2.solaris: Starting HSpice job with input putout.spi.
s2ibis2.solaris: Error in executing HSpice.
s2ibis2.solaris: Error 0
s2ibis2.solaris: Fatal error.
  However it is OK when run "hspice buffer.sp", would please tell me why?
Thank you very much.

Best Regards,
 

Sun Weifeng --------------6BD24409C4129EB8858344EE-- From owner-ibis Wed Nov 24 05:37:00 1999 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA05769 for ; Wed, 24 Nov 1999 05:36:58 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id HAA10442 for ; Wed, 24 Nov 1999 07:36:22 -0600 (CST) Received: from smtp2.molex.com(150.150.15.101) by molexinc-bh.molex.com via smap (4.1) id xma010159; Wed, 24 Nov 99 07:35:28 -0600 Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 00089883; Wed, 24 Nov 99 07:32:50 +0000 Mime-Version: 1.0 Date: Wed, 24 Nov 1999 07:32:42 +0000 Message-ID: <00089883.CE21031@molex.com> Subject: Frequency Dependent and Lossy ... more on Conductance To: ibis@eda.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Oooppsss I forgot one thing 2. Conductance matrix: At this time a conductance matrix as such is not built in to the specification. I think that when this effect comes into play (I do not have supporting data, but my guess that conductance becomes significant at frequencies greater 8 GHz. ....at least in devices as short as connectors) that the "s-parameter" solution would be the best solution to correctly implement dielectric loss effects. The specification does allow off-diagonals to be present in the resistance matrix.... Although not a real "conductance matrix".... it may help. _gus: 630-969-4617 apanella@molex.com From owner-ibis Wed Nov 24 05:36:58 1999 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA05767 for ; Wed, 24 Nov 1999 05:36:57 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id HAA10425 for ; Wed, 24 Nov 1999 07:36:20 -0600 (CST) Received: from smtp2.molex.com(150.150.15.101) by molexinc-bh.molex.com via smap (4.1) id xma010153; Wed, 24 Nov 99 07:35:27 -0600 Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 00089881; Wed, 24 Nov 99 07:32:50 +0000 Mime-Version: 1.0 Date: Wed, 24 Nov 1999 07:30:42 +0000 Message-ID: <00089881.CE21031@molex.com> Subject: Min / Max Models To: ibis@eda.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part This email topic: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Scott McMorrow raised the issue that modern connectors have tolerances and that minimum and maximum models are needed along with typical models. He also presented some ideas on syntax. Arpad suggested multiple connector models." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I think the multiple model approach is probably best suited for the specification. The specification was made to accept matrices that can be used interchangeably. As such, to add min / max matrices would be easy to do in the specification today. However, I do have a couple issues with maybe some of the basic premise of using min/max matrices. Please keep in mind, I do not understand the scope of where the min / max parameters are proposed to be used. * If you were to use the specification to model a connector with different length pins (or a package where the leadframe pins to the corners are longer than the others), I would contend that there should be a model that represents the entire set of major discontinuities (and use the swath operator where it is applicable). Each discontinuity would be modeled as a coupled representation to all other near by pins. I do not think in this case that a min/max should be used. * Connector tolerances.... hmmmm... I am not sure what tolerances are of concern... but I would like to make a couple general comments. Impedance tolerance.... this is effectively handled by cascaded matrix. Each matrix defines the impedance (LCR) of a portion of the length of the entire connector.... including the approximate respect with regards to time. Impedance is probably better handle in this way as opposed to min/ma CL values Capacitance tolerance and Inductance Tolerance: Many people model a connector as a single lumped circuit (i.e. a SLM) ... A single lumped model could very well suffer a severe "overburdening" effect with this parameter due to the distributed nature of an interconnection. Cascaded would be less so... And maybe a question? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * What is min/max? 3 sigma... if you mention this, you by definition build in the tolerance of the measurement process.. Is it worst case based on production tolerances... Is it worst case based on as manufactured tolerances... What is the temperature / humidity range? What about contact resistance and how it may or may not vary under different shock loads.... How do we make sure that it is consistent between vendors. This could open up a big can of worms. Also, for what it is worth, I know that there are connectors with mechanical dimensions on the prints that are "Critical To Function" (or CTF) that ONLY are there to maintain electrical design goals and tolerances. _gus: 630-969-4617 From owner-ibis Wed Nov 24 08:55:31 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 IAA06597 for ; Wed, 24 Nov 1999 08:55:30 -0800 (PST) Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id IAA09637; Wed, 24 Nov 1999 08:54:21 -0800 (PST) Message-Id: <199911241654.IAA09637@jasper.cisco.com> Date: Wed, 24 Nov 1999 08:54:21 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: Help To: ibis-users@cda.org, ibis@vhdl.org, sunweifeng@huawei.com.cn MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uKQMIZ5MzcT+OkLST8jPOA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Look at your 'putout.out' or 'putout.st0' file for errors.. Syed > Date: Wed, 24 Nov 1999 20:54:50 +0800 > From: sunweifeng > MIME-Version: 1.0 > To: ibis-users , "ibis-vhdl.org" > Subject: Help > X-SMTP-HELO: server.eda.org > X-SMTP-MAIL-FROM: owner-ibis@server.eda.org > X-SMAP-Received-From: outside > X-SMTP-PEER-INFO: server.eda.org [171.64.101.101] > > Hi Sir, > > I used the s2ibis2 to transit the spice model to ibis model. I run the > demo under the directory ex1, and there following note when run > "s2ibis2.solaris buffer.s2i" : > s2ibis2.solaris v1.1 -- North Carolina State University > s2ibis2.solaris: Reading input file buffer...done. > s2ibis2.solaris: Analyzing component MCM Driver . > s2ibis2.solaris: Starting HSpice job with input putout.spi. > s2ibis2.solaris: Error in executing HSpice. > s2ibis2.solaris: Error 0 > s2ibis2.solaris: Fatal error. > However it is OK when run "hspice buffer.sp", would please tell me > why? > Thank you very much. > > Best Regards, > > > Sun Weifeng From owner-ibis Wed Nov 24 08:58:38 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 IAA06628 for ; Wed, 24 Nov 1999 08:58:38 -0800 (PST) Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id IAA09768; Wed, 24 Nov 1999 08:57:02 -0800 (PST) Message-Id: <199911241657.IAA09768@jasper.cisco.com> Date: Wed, 24 Nov 1999 08:57:02 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: Help To: ibis-users@eda.org, ibis@vhdl.org, sunweifeng@huawei.com.cn MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uKQMIZ5MzcT+OkLST8jPOA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Look at your 'putout.out' or 'putout.st0' file for errors.. Syed > Date: Wed, 24 Nov 1999 20:54:50 +0800 > From: sunweifeng > MIME-Version: 1.0 > To: ibis-users , "ibis-vhdl.org" > Subject: Help > X-SMTP-HELO: server.eda.org > X-SMTP-MAIL-FROM: owner-ibis@server.eda.org > X-SMAP-Received-From: outside > X-SMTP-PEER-INFO: server.eda.org [171.64.101.101] > > Hi Sir, > > I used the s2ibis2 to transit the spice model to ibis model. I run the > demo under the directory ex1, and there following note when run > "s2ibis2.solaris buffer.s2i" : > s2ibis2.solaris v1.1 -- North Carolina State University > s2ibis2.solaris: Reading input file buffer...done. > s2ibis2.solaris: Analyzing component MCM Driver . > s2ibis2.solaris: Starting HSpice job with input putout.spi. > s2ibis2.solaris: Error in executing HSpice. > s2ibis2.solaris: Error 0 > s2ibis2.solaris: Fatal error. > However it is OK when run "hspice buffer.sp", would please tell me > why? > Thank you very much. > > Best Regards, > > > Sun Weifeng From owner-ibis Wed Nov 24 09:07:11 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 JAA06678 for ; Wed, 24 Nov 1999 09:07:10 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA29620; Wed, 24 Nov 1999 09:06:04 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id JAA27409; Wed, 24 Nov 1999 09:06:03 -0800 (PST) Message-ID: <383C1B01.D0746DD@mentor.com> Date: Wed, 24 Nov 1999 09:06:09 -0800 From: Ted Creedon X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: apanella@molex.com CC: ibis@eda.org Subject: Re: Frequency Dependent and Lossy References: <00089747.CE21031@molex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You are right on. Just a 400 mhz connector can cause problems due to inaccurate modeling therefore inaccurate specification by the customer therefore lack of process control by the vendor. And this is in addition to the Z0 change at the connector. Two things will happen 1. the designers will get smarter and stop using high speed connectors thus avoiding the problem and 2. Ibis will eventually figure out how to model frequency dependent devices. Sets of S parameters for N ports are the only comprehensive solution now because the only accurate information available is from instruments or 3D field solvers. However the condensation of the information into something useable (the S parameter sets can be viewed as a (N-1)*ntables dimensioned surface where N=# of ports, ntables=no of frequency points for each Nport set of S parameters). We're running into this already for via modeling. The problem of characterizing e' + je'' which vary with frequency is a area of active interest. Particularly since many designers choose to create this problem by using FR4 rather than a good dielectric like Duroid or Kapton. Which is worse because for FR4 boards e' and je'' are anisotropic - it varies with the fiberglass mat orientation in XY and and may also vary in the Z direction. Don't forget you're trying to control the electrical length to less than 100ps and keep the rise time out of the quadratic range (RC line rather than LC). As an example a large digital system could be flip chipped on a MCM - no PCI busses, AGP busses, ISA busses or memory connectors with a microwave launch to the keyboard/mouse and display. And satellite or fiber. If one stops and thinks of the advantages in miniaturizing, lowering manufacturing cost and simplifying simulation we might design ourselves out of a job. ted apanella@molex.com wrote: > First, > > To the entire group... I am sorry that I missed the last meeting. I was fully > planning on being there... had an unfortunate incident that came up that need > my immediate attention... > > I will plan on being at the next meeting. > > However, in the spirit of helping... I would like to address a few of the > comments from the meeting notes: > > This email topic: > > "Stephen Peters and Arpad Muranyi asked several clarifying questions on > whether the (frequency dependent) conductance matrix was included, and Kellee > responded that it was not. Furthermore he stated that the decision to > postpone losses was made after consulting with a number of internal technical > experts." > > In my mind there are two issues built into this statement: > > 1. Frequency dependence: At this time a "FREQUENCY DEPENDENT COMPONENT" is not > built into the specification... However... CASCADED MATRICES are built in to > the specification. The cascaded matrix allows the model to represent > asymetrical or symetrical filtering effects that are typically found in > interconnect structures with multiple discontinuities (i.e. allows you to > represent a pole/zero as they actually occur as the energy passes through the > length of the interconnect). Thus representing each discontinuity on it's own.. > in a series and/or stub configurations. As such, it is quite reasonable to > expect that by using a cascaded model, it is possible to extend the operation > point of a model to the limits of the performance limits of the interconnect > being modeled. > > With BERKELEY SPICE models (no vendor specifi SPICE extensions required) , using > a cascaded modeling approach... today, a 6GHz 3dB bandwidth is a typical > modeling requirement (9GHz. is also possible). Yes this can be confirmed to > both frequency domain and time domain lab measurements. > > Further, I would also suggest that a frequency dependent component is really > something more than just a swept series resistance that varies as a function of > frequncy in a single lumped model. As such, to do a true frequency dependent > model, something more like a behavioral model (s-parameters anyone?) would be > the most appropriate method of representation. > > 2. Conductance matrix: At this time a conductance matrix as such is not built > in to the specification. I think that when this effect comes into play (I do > not have supporting data, but my guess that conductance becomes significant at > frequencies greater 8 GHz. ....at least in devices as short as connectors) that > the "s-parameter" solution would be the best solution to correctly implement > dielectric loss effects. > > So why noy implement s- parameters now > * Model complexity.... the connector matrix models that are setup in the > proposed connector specification can be in the 100's to 1000's of lines. I've > seen (and created) mulitport s-parameter models that are 100x the size. Of > course, this depends on the frequncy step size and frequncy range of the model. > * We really wanted to incorporate an unlimited pin size connector using a > "swath" as proposed in the specification. As the s-parameter matrix is not a > "single value per coupling / self node" (like , for instance an inductance > matrix would be)... I had no idea on how to handle the complexity of a swathed > s-parameter. > * Many simulators that use IBIS models are time domain based... the complexity > of adding s-parameters may be too difficult. > * The proverbial , We approached the proposed specification with a "Walk before > you run philosophy". > * We also wanted to focus on the connector models that are primarily available > today... and be able to implement those as soon as possible into a new format. > > _gus: 630-969-4617 > apanella@molex.com From owner-ibis Wed Nov 24 09:34: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 JAA06791 for ; Wed, 24 Nov 1999 09:34:59 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id JAA02899; Wed, 24 Nov 1999 09:33:53 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id JAA02116; Wed, 24 Nov 1999 09:33:51 -0800 (PST) Message-ID: <383C2186.B17EAA5A@mentor.com> Date: Wed, 24 Nov 1999 09:33:58 -0800 From: Ted Creedon X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: apanella@molex.com CC: ibis@eda.org Subject: Re: how many dimensions References: <00089881.CE21031@molex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, but if a single Nport's S parameters can be represented with a 2 dimensional array then adding by frequency makes the surface a 3D surface. So there is an option to reduce the data and make that a future part of the spec or just include all the data and let the vendors do it. ted From owner-ibis Wed Nov 24 13:11:24 1999 Received: from gti.net (apollo.gti.net [199.171.27.7]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA07503 for ; Wed, 24 Nov 1999 13:11:23 -0800 (PST) Received: from bill (ts5m-pool0-250.gti.net [208.216.126.250]) by gti.net (8.9.3/8.8.8) with SMTP id OAA29805; Wed, 24 Nov 1999 14:35:16 -0500 (EST) Message-Id: X-Sender: bebner@mail.gti.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 24 Nov 1999 14:32:35 -0500 To: bebner@gti.net From: Bill Ebner Subject: New sensor accurately evaluates lamination planarity and misregistration Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Engineer:

I am writing to inform you of a new product of ours - a sensor film that reveals the stress distribution and magnitude between any two surfaces that come in contact -=A0 by changing color. The intensity of the resultant color is quantifiable and enables you to determine precisely what the PSI is at any point on the contacting surfaces.=A0 This product is useful for assessing interfacial stresses that occur at gasketed and flanged interfaces, in lamination presses, roller systems and heat sealers, during welding, in materials testing and from impact forces.

If you would like a FREE product sample or literature please let me know and I will be sure to send it out=A0 immediately.=A0 Please be sure to include an approximate PSI range that you want to experiment with for the application you have in mind. Pressurex is available in five sample ranges.=A0 Please choose one:

28 - 85 PSI
70 - 350 PSI
350 - 1400 PSI
1400 - 7100 PSI
7100 - 18,500 PSI

Also be sure to include your contact information (address, phone, fax, etc.)

Thank you for your time.


Bill Ebner
Sensor Products Inc.=A0
188 Rt. 10=A0 Ste. 307
E. Hanover, NJ=A0 07936=A0 USA

http:\\www.fujiprescale.net

ph 973.560.9092
fx=A0 973.884.1699



This message is sent in compliance with the new email bill: SECTION 301. Per Section 301, Paragraph (a) (2) (C) of S. 1618.

Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word =93remove=94 in the text body area.















From owner-ibis Wed Nov 24 13:35: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 NAA07568 for ; Wed, 24 Nov 1999 13:35:01 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA24378; Wed, 24 Nov 1999 13:33:56 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA13852; Wed, 24 Nov 1999 13:33:56 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <383C59C2.F70E32D3@mentor.com> Date: Wed, 24 Nov 1999 13:33:54 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: Early IBIS Agenda 12/3/99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 12/3/99 Bridge Number Reservation # Passcode (916) 356-9200 2-368940 5714412 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) Perrin - JEDEC JC-16.2 Modeling and Testing Sessions DesignCon2000 IBIS Summit Planning Ross/Schwartz DATE2000 IBIS Summit Planning Ross Cookbook Status Peters IBIS Model Review Committee Flora S2ibis3 Proposal Discussion Cohen New Administrative Issues All 8:45 Technical Discussion (some topics may be deferred) Connector Proposal Review Chrisafulli/Panella IBIS Futures (IBIS-X, API, BIRDxx) Peters/Muranyi BIRD64 - Package Model Selector Muranyi BIRD66 - [Model Spec] Vref Addition McMorrow/Ross BUG34 - No Error Reported for Missing V/I Tables Flora in Output Buffers BIRD61 - Enhanced Characterization of Receivers Peters BIRD62 - Enhanced Chararcterization of Receiver Peters Thresholds BIRD63 - Documentation of Receiver Setup and Hold Peters Timing Conditions BIRD65 - C_comp Refinements Muranyi New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Mon Nov 29 11:11:29 1999 Received: from mta3.snfc21.pbi.net (mta3.snfc21.pbi.net [206.13.28.141]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA29890 for ; Mon, 29 Nov 1999 11:11:29 -0800 (PST) Received: from postoffice.pacbell.net ([209.79.182.203]) by mta3.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FLZ00KLC3SYGF@mta3.snfc21.pbi.net> for ibis@vhdl.org; Mon, 29 Nov 1999 11:07:55 -0800 (PST) Date: Mon, 29 Nov 1999 10:07:06 -0800 From: Jon Powell Subject: Altera To: "ibis@vhdl.org" Reply-to: jpowell@viewlogic.com Message-id: <3842C0CA.6F8E415A@postoffice.pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) Content-type: multipart/mixed; boundary="------------A1E91A98F8C39FCB64507BB5" This is a multi-part message in MIME format. --------------A1E91A98F8C39FCB64507BB5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I have update the ibis model page (direct link below). There is a new format, I have added many links and a alphabetic directory (sort of). All links were verified over thanksgiving (some sites were down and they are listed accordingly). I plan to do this again over Christmas (what fun!!!) so please send me any updates, fixes, gratuitous misspellings, etc. your friendly neighborhood IBIS librarian, Jon Powell http://www.viewlogic.com/ibis/ -- Jon Powell Director of HSSD Consulting Services Viewlogic Systems, INC. 805 988 8250 --------------A1E91A98F8C39FCB64507BB5 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Base: "http://www.viewlogic.com/ibis/" Altera

IBIS<= FONT FACE=3D"Arial,helvetica" SIZE=3D7> Model Page
 

This directory contains pointers to all known (by me) public IBIS mode= l sources. IBIS models that are located at individual company reflectors = are listed for completeness but their content is maintained by the indivi= dual companies. This site is maintained by the IBIS Open Forum as a free = service to the Industry.
 

To add models to this list or recommend a change of the text an= d comments provided (IC companies, you can even send lists of models or m= odel families) please contact jp= owell@viewlogic.com . (as the IBIS Open Forum Librarian)

All links have been rechecked as of the update date on the bott= om of this page. At this time all of these links are either operational o= r have problems as noted in the text. Any help finding lost pages would b= e appreciated.


 

A B C D E F G H I J K L M N O P Q<= /FONT> R S T U N W <= FONT FACE=3D"Courier New" SIZE=3D5>X Y Z

 

 
 

= =

Company

Links

Comments

Act= el

Mo= dels 
locat= ion verified 11/20/1999

Models for SX, MX, 1200XL/3200DX, Act3 (non-PCI), Act2,= and Act1 Families.  
Like other programmable part families, these models come w= ith device models and general package parasitics only. The actual package= d models must be created by the user.

= Agilent

Model= s

Location Verified 11/20/1999

One transceiver model is available for download and the= re is a list of other models that are available through contact with a fi= eld service engineer.

This company used to be HP

Altera

Altera IBIS hom= e page 
(location verified 11/20/1999)

Includes IBIS support for APEX20k, FLEX10k, EPF10K, EPF= 10K250A, EPF10K50V,  EPF10K130V, EPF10K100B, FLEX10KE, EPF6016, EPF6= 010A, EPF6016A, EPF6024A, EPF8282A, EPF8452A, EPF8636A, EPF8820A, EPF8118= 8A, EPF81500A, EPF8282AV, MAX9000A, MAX7000A, MAX7000AE, MAX7000S, EPM703= 2, MAX3000A, and the Configuration Device Families.   Like other programmable part families, these models come w= ith device models and general package parasitics only. The actual package= d models must be created by the user.

AMD

Models 
Location Verified 11/20/1999

Many models here in the AM29BL, AM29DL, AM29F, AM29LV, = and AM29PL families.

AMD-= K6 models 
Locatio= n Verified 11/20/1999

Several Varieties of AMD K6 models.

AMI

Models&= nbsp; 
Location v= erified 11/20/1999

Various timing generation products in the FS family.

Aptos Semiconductor C= orp.

Aptos has sold their Ram technology to Integrated Silicon Solutions

Atmel

Models
Location Verified 11/21/1999

Atmel has one model that represents their buffers.

Like other programmable part families, these models come with device m= odels and general package parasitics only. The actual packaged models mus= t be created by the user.

Clear Logic

Models
Location Verified 11/21/1999

Models for the CL7000E, CL7000= S, and CL8000 families.

Like other programmable part families, these mod= els come with device models and general package parasitics only. The actu= al packaged models must be created by the user.

Cypress<= /TD>

Models

Location Verified 11/21/1999

Cypress has models listed under the categories of: Data= Communications, Specialty Memories, FCT Logic, Memories, Programmable Lo= gic, and Timing Technologies.

Enh= anced Memory Systems

Request Models

Location Verified 11/21/1999

Enhanced Memory Systems has a model request form for or= dering IBIS models of various components.

Fairchild

Models

Location Verified 11/21/1999

Fairchild has models for the [AC] [ACT] [ACTQ] [FAST] [= GTLP] [HC] [LCX] [LS] [LVT] [LVTH] [SCAN] [TinyLogic]and [VCX] families.<= /FONT>

Ga= lvantech

Models

Location Verified 11/21/1999

A number of what appear to be memory part models.

Hewlet= t-Packard

HP semiconductors is now Ag= ilent. No Other IBIS models apparent in search of HP w= eb page (11/22/1999)

Hyundai Electronics=

Register for models

Location verified 11/21/1999

You have to register and get a username and password, b= ut then you can download models in the EDO DRAM, SDRAM, DDR SDRAM, and Di= rect RDRAM families.

IBM=

IBM Microelectronics

Location Verified 11/21/1999

has DRAM models at this site. You must be a registered = IBM customer to download this model 

Ebedded Power PC Models

A= nother Pointer

Location Verified 11/21/1999

This site has been updated and now has complete pinout = IBIS models for many PowerPC variants.

Integrated Circuits Sy= stems, Inc.  

Models<= /FONT>

Location Verified 11/21/1999

(ICS) has one model for the 1523.

Integrated Circuit Systems. ICS Webmaster Reports: "At this time we cr= eate the IBIS models and send them to customers on an as needed basis. We= currently do not have plans of including them on our web for competition= security reasons"

IDT

Poin= ters to model pages

Location Verified 11/22/1999

There are a number of pointers here to reference pages,= some of which do hold IBIS models. The reference areas are marked: SRAM = Models, RISC Processor Models, FIFO Models, Multi-Port and Dual-Port SRAM= Models, and Logic Models

Editors Notes: Though there are many pointers to files noted as IBIS m= odels, on this date (11/22/1999) jnp was unable to access any of these fi= les. (If anyone has different luck, let me know)

Infineon

Dram Models

Location verified 11/22/1999

These models were hard to find and it looks like the re= ferring page may move around some. There are models for 16M and 64M DRAM = products.

(note: This company used to be Siemens)

I have found references to other IBIS models but no act= ual models. If you have found more models, please let me know.

Intel

Intel link = ;

Location Verified 11/22/1999

Intel puts out a lot of models and updates their site o= ften. When in doubt, try a search of this link which is the developers si= te.

Intel has a lot of models that are not on their Web site, many are onl= y available under NDA. Contact your INTEL sales rep and ask.

i96= 0

Location Verified 11/22/1999

Links to IBIS models for various varieties of the i960 = family

Pentium II Processors

Location Verified 11/22/1999

Link to Pentium II IBIS models (stored in ZIP format). = Also some directions on corner selection and use.

Pentium Pro Processors

Location Verified 11/22/1999

Pentium Pro IBIS model (in txt format)

Mo= dels

Location Verified 11/22/1999

Another reference to (new) i960 models.

Mo= dels

Location Verified 11/22/1999

PCI to PCI Bridge Models

International Microelectronics.

Models

Location Verified 11/22/1999

This site has been changed from exe executables to just= plain txt files for easy download. It has a lot of models of the C SC an= d SX variety. Though this is an active link, I have not been able to find= a general company home page.

Integrated Silicon Sol= utions, Inc. (ISSI) 

Models

Location Verified 11/22/1999

This site is still under construction. The customer is = instructed to contact ISSI directly for "simulation" models.

Lucent Technologies

= FPGA models

Location Verified 11/22/1999

IBIS models for 2C-A, 2T-A, 3C and 3T FPGA families.

Like other programmable part families, these models com= e with device models and general package parasitics only. The actual pack= aged models must be created by the user.

Mi= cron

Models

Location Verified 11/22/1999

IBIS Models for 64Meg EDO RAM, 16 Meg SDRAM, 64 Meg SDR= AM, 128 Meg SDRAM, ZBT SRAM, 4Mb, 8Mb families.

This page seems to be under development so you might want to check her= e for other Micron models too.

request form

Location Verified 11/22/1999

Request form for other part "simulation" Models.=

Mitsubishi<= /FONT>

Link to Mod= els page

Location Verified 11/22/1999

The link we used to use appears to not be operational. = This page points to the IBIS models web page (which was not operational a= t the time of this update)(jnp 11/22/1999)

Mosel Vitelic<= /FONT>

Models

Location Verified 11/22/1999

Hidden in here are references to Mosel Vitelic IBIS mod= els. Models for various DRAM components including 16M DRAM and 64M DRAM (= 3 and 5 volt). The models appear to be packaged in .exe format (so you ne= ed a PC to extract them).

Motorola

Search

Location Verified 11/22/1999

Main search engine. Try searching for IBIS or Models he= re (if you don't see the right link below)

Models

Location Verified 11/22/1999

Page with references to a few IBIS models including: 68= 360, MPC860, MPC8260

Models

Location Verified 11/22/1999

FACT, LCX and ECL families can be found. Some IBIS and = some SPICE models.

Models

Location Verified 11/22/1999

Models for Asynchronous Fast SRAMs, BurstRAMs, CAMs, Do= uble Data Rate (DDR) RAMs, Integrated Cache Solutions, Late Write RAMs, S= eparate and Dual I/O Devices, Tag RAMs and ZBT™ RAMs. Some IBIS mod= els and some SPICE models

Motorola Power PC

Location Verified 11/22/1999

Various kinds of PowerPC models.

= National

Models

Location Verified 11/22/1999

National Semiconductor provides IBIS models from variou= s product lines including: interface, Clock Generation & Support (CGS= ), Data Acquisition, Super I/O, DRAM Controllers, Local Area Network Prod= ucts, and RTC (Real Time Clock) Families

P= ericom

Models

Location Verified 11/22/1999

Pericom has IBIS models for various MUX, Bus driver, Bu= s Switch and other logic components.

Philips Logic<= /FONT>

M= odels

Web site down, could not verify 11/22/1999

Philips Semiconductors Logic Products 
= Philips Semiconductors offers IBIS models for most of thei= r logic families including: ABT, AHC, AHCT, ALVC, A= LVT, AVC, FBL, GTL, LVC, LVT. 
(text from Philips)

Mo= re Models

Web site down, could not verify 11/22/1999

PMC-Sierra

Mo= dels

PMC-Sierra has various IBIS models available for downlo= ad to users who agree to license agreement . (you can click on "agree" at= the web site). Includes models for TQUAD, TOCTL, SPECTRA, S/UNI, and FRE= EDM families

Quality Semiconductor

models

=

Web site down, could not verify 11/22/1999

The web site appears to be no longer operational, and j= udging from the Stock page, I think this company is off the air. Please c= ontact me with any other data.

QuickLogic Corp.

models<= /P>

Location Verified 11/22/1999

There is one IBIS file for all quicklogic devices.

Samsung

Dram Products

Location Verified 11/22/1999

Various DRAM models

SRAM Products

Location Verified 11/22/1999

Various SRAM models

Graphic Memory Products

Location Verified 11/22/1999

Synchronous DRAM and Graphic RAM models

Mask ROM PRODUCTS

Location Verified 11/22/1999

Mask Rom Models.

Flash Products

Location Verified 11/22/1999

NAND Flash Models

SDRAM

Location Verified 11/22/1999

DDR and Synchronous RAM models

Siemens Semiconducto= r

All of these devices appear to now be listed under the = new company name of Infineon

Texas = Instruments

New = link

Location Verified 11/22/1999

This is a link to all of the TI logic families IBIS mod= els (Check it out), including ABT, ALB, ALVC, GTL, HSTL, LVC, LVT and SST= L

PC100 Compliant Clock Distribution Circuits

Location Verified 11/22/1999

IBIS models for TI clocks and Timers

Interface

Location Verified 11/22/1999

Models for LVDS screen drivers and other interface devi= ces

Data Driver (LVDS)

Location Verified 11/22/1999

Assorted LVDS and other data driver models

Models

Location Verified 11/22/1999

TMS320C and other IBIS models

Tundra Semiconductor=

Models

Location Verified 11/22/1999

If you look through the product info there are some ref= erences to IBIS models. I could not find any but they are evidently worki= ng on them so you might want to try again.

Xi= linx

M= odels

Location Verified 11/22/1999

Direct web access to lots of Xilinx models including: V= irtex, Spartan, CPLD's and PROM's. These files are in ZIP or compressed t= ar format.

Like other programmable part families, these models come with device m= odels and general package parasitics only. The actual packaged models mus= t be created by the user

 

 
 

Site Last Update 11/22/99 by Jon Powell (IBIS Librarian= )

 

--------------A1E91A98F8C39FCB64507BB5-- From owner-ibis Mon Nov 29 13:54:06 1999 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA00494 for ; Mon, 29 Nov 1999 13:54:05 -0800 (PST) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 29 Nov 1999 15:52:31 -0600 Received: from zmerd004.ca.nortel.com ([47.124.0.133]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XHBWKMA4; Mon, 29 Nov 1999 16:52:21 -0500 Received: from americasm01.nt.com (wkpks00e.ca.nortel.com [47.125.49.19]) by zmerd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VT9CWLCV; Mon, 29 Nov 1999 16:52:19 -0500 Sender: "Cass Russett" Message-ID: <3842F58A.D4D21A5E@americasm01.nt.com> Date: Mon, 29 Nov 1999 16:52:10 -0500 From: "Cass Russett" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@vhdl.org Subject: Req for Info: Differential Buffers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The typical construct for converting Spice models to IBIS -- namely, Spice deck fixtures for producing V/I and V/T curves, do not appear directly relevant for converting differential buffers. For example, if the non-inverting transmit buffer output is connected to the S2IBIS2 fixture, how should the inverting output be connected? Please note that the manner in which the inverting output is connected does have an impact on the response of the non-inverting output. If the non-inverting output is ignored, then the results do not correlate to the actual buffer behavior because of the tightly matched current sourcing and sinking of the respective outputs. If the non-inverting output is connected to something, what is it for both the V/I and V/T fixtures? In short, what is the established procedure for differential buffers? Thanks in advance for any assistance, Cass Russett From owner-ibis Mon Nov 29 16:39:29 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 QAA00826 for ; Mon, 29 Nov 1999 16:39:29 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA02630; Mon, 29 Nov 1999 16:38:20 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id QAA21941; Mon, 29 Nov 1999 16:38:18 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <38431C7B.FA90EED@mentor.com> Date: Mon, 29 Nov 1999 16:38:19 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Cass Russett , ibis@eda.org CC: bob_ross@mentorg.com Subject: Re: Req for Info: Differential Buffers References: <3842F58A.D4D21A5E@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cass: You raise a good question. The IBIS format does not support documenting the [Rising Waveform] and [Falling Waveform] tables using differential loads, nor does it support any possible interaction in I-V characteristics between outputs. However, I believe there are still some approximate approaches that will be very accurate. Some suggestions are given below. You may need to configure the test circuit given by s2ibis and use the [iterate] command to get an adjusted extraction. You also need to compare the simulation results. For V-T tables: 1. Use "equivalent single-ended load on each buffer connected to the mid-level voltage. This does not guarentee that the inverting buffer sees the same current as the non-inverting buffer - as you have noted. Nor does it capture any non-inverting and inverting buffer interaction. It may be possible to adjust this approach using controlled current sources to inject the same output current into the non-inverting node. However, this seems equivalent to the second alternative. 2. Use a true differential resistance in the Spice extraction of the [Rising Waveform] and [Falling Waveform] tables. However, put the equivalent single ended loads in the IBIS file - as an approximation. This captures the voltage waveforms under correct Spice simulation conditions using the correct differential load. The fact that these are documented based on single-ended loads is incorrect since the mid-point voltage is usually not constant. However, the IBIS simultations should generate the same non-inverting and inverting voltage waveforms when the device is terminated with a true differential load. (The accuracy of doing this may be simulator dependent.) I recommend this approach. For I-V tables: 1. Do the Spice I-V extractions with the non-inverting output connected to the mid-point voltage. A refinement to this would be to connect the non-inverting output to the equivalent single-ended load, as an approximation. The I-V table may not capture exactly the inverting and non-inverting interactions, but it should be a good approximation. I recommend this approach. 2. If there is significant interaction on I-V characteristics between the non-inverting and inverting outputs, then this may work: Configure the Spice source such that tbe non-inverting output has the same current as the non-inverting output for I-V extractions by using a controlled current source. This might provide a more accurate representation of the I-V characteristics. Bob Ross Mentor Graphics Cass Russett wrote: > > The typical construct for converting Spice models to IBIS -- namely, > Spice deck fixtures for producing V/I and V/T curves, do not appear > directly relevant for converting differential buffers. > > For example, if the non-inverting transmit buffer output is connected to > the S2IBIS2 fixture, how should the inverting output be connected? > Please note that the manner in which the inverting output is connected > does have an impact on the response of the non-inverting output. > > If the non-inverting output is ignored, then the results do not > correlate to the actual buffer behavior because of the tightly matched > current sourcing and sinking of the respective outputs. If the > non-inverting output is connected to something, what is it for both the > V/I and V/T fixtures? > > In short, what is the established procedure for differential buffers? > > Thanks in advance for any assistance, > Cass Russett From owner-ibis Tue Nov 30 11:08:35 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 LAA06232 for ; Tue, 30 Nov 1999 11:08:35 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA14780; Tue, 30 Nov 1999 11:07:26 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA16361; Tue, 30 Nov 1999 11:07:24 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <3844206C.211D2AB1@mentor.com> Date: Tue, 30 Nov 1999 11:07:24 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Meeting Reminder 12/3/99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 12/3/99 Bridge Number Reservation # Passcode (916) 356-9200 2-368940 5714412 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 3.2) Ross/Fleming - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation (formerly designated as IEC 93/67/NP IBIS and EMC Simulation) Perrin - JEDEC JC-16.2 Modeling and Testing Sessions DesignCon2000 IBIS Summit Planning Ross/Schwartz DATE2000 IBIS Summit Planning Ross Cookbook Status Peters IBIS Model Review Committee Flora S2ibis3 Proposal Discussion Cohen New Administrative Issues All 8:45 Technical Discussion (some topics may be deferred) Connector Proposal Review Chrisafulli/Panella IBIS Futures (IBIS-X, API, BIRDxx) Peters/Muranyi BIRD64 - Package Model Selector Muranyi BIRD66 - [Model Spec] Vref Addition McMorrow/Ross BUG34 - No Error Reported for Missing V/I Tables Flora in Output Buffers BIRD61 - Enhanced Characterization of Receivers Peters BIRD62 - Enhanced Chararcterization of Receiver Peters Thresholds BIRD63 - Documentation of Receiver Setup and Hold Peters Timing Conditions BIRD65 - C_comp Refinements Muranyi New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Tue Nov 30 14:10:20 1999 Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA06932 for ; Tue, 30 Nov 1999 14:10:19 -0800 (PST) From: micohen@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA24166 for ; Tue, 30 Nov 1999 16:56:59 -0600 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id RAA36980 for ; Tue, 30 Nov 1999 17:09:09 -0500 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256839.0079BD03 ; Tue, 30 Nov 1999 17:09:42 -0500 X-Lotus-FromDomain: IBMUS To: ibis@eda.org Message-ID: <85256839.0079BC58.00@d54mta04.raleigh.ibm.com> Date: Tue, 30 Nov 1999 17:08:42 -0500 Subject: SPICE-To-IBIS Version 3 (S2IBIS3) Proposal Now Available For Review Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello everyone! I would like to announce the SPICE-To-IBIS Version 3 (S2IBIS3) Project Proposal to everyone who was not present at the last IBIS Open Forum Meeting held last Friday, November 26, 1999. The proposal can be found on the IBIS Home Page: http://www.eia.org/eig/ibis/ibis.htm or directly at: http://www.eda.org/pub/ibis/s2ibis3/ Please review the "s2ibis3_PR_1_00.txt" document; if you have any comments, please post them on this reflector to help stimulate discussions. Again, let me thank everyone who participated on the subcommittee; your hard work is much appreciated! The members of this subcommittee are: Michael Cohen (Chairperson) IBM Personal Systems Group Syed Huq Cisco Systems Christian Klein (Secretary) Fairchild Semiconductors Mike LaBonte Cadence Design Systems Arpad Muranyi Intel Corporation Bob Ross Mentor Graphics Mohamed Nasef Mentor Graphics Jerry Hayes IBM Sherif Hammad Mentor Graphics Regards, Michael Cohen Chairperson, SPICE To IBIS Subcommittee From owner-ibis Tue Nov 30 15:58:39 1999 Received: from vlad.eng.mcd.mot.com (ftfservr.phx.mcd.mot.com [144.191.26.101]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA07380 for ; Tue, 30 Nov 1999 15:58:39 -0800 (PST) Received: from eng.mcd.mot.com (horizon.phx.mcd.mot.com [144.191.12.156]) by vlad.eng.mcd.mot.com (Postfix) with ESMTP id 7CC7D180E for ; Tue, 30 Nov 1999 16:58:01 -0700 (MST) Sender: gtruong@eng.mcd.mot.com Message-ID: <384461DC.16C80364@eng.mcd.mot.com> Date: Tue, 30 Nov 1999 16:46:37 -0700 From: gerald_truong X-Mailer: Mozilla 4.5 [en] (X11; I; AIX 4.1) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: sweeping range... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I am trying to change the sweeping range for certain curves in s2ibis2 to avoid non-convergence problems but I am finding myself unsuccessful at it. Does someone know how to modify the sweeping range for s2ibis2? Thank you in advance. Gerald Truong Motorola Computer Group (602)438-3525 From owner-ibis Tue Nov 30 16:30:30 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 QAA07505 for ; Tue, 30 Nov 1999 16:30:29 -0800 (PST) Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA25530; Tue, 30 Nov 1999 16:28:57 -0800 (PST) Message-Id: <199912010028.QAA25530@jasper.cisco.com> Date: Tue, 30 Nov 1999 16:28:57 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: sweeping range... To: ibis@eda.org, gtruong@eng.mcd.mot.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7zYwUOoZLN2YzZQRwbZGRw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Hi, At the end of your .spi file, you may see some statements like below: VOUTS2I out 0 DC 0 VCCS2I vdd 0 DC 3 VGNDS2I gnd 0 DC 0 VINS2I in 0 DC 3.3 .TEMP 27 .OPTIONS INGOLD=2 .DC VOUTS2I -3 6 0.1 <---- Edit this line .PRINT DC I(VOUTS2I) .END The above .DC statement is sweeping from -3V to +6V in 0.1V increment. You should be editing the .spi file that *failed* the DC convergence. Just to make sure it works with the new sweep range you define, you could run spice standalone on this spi file. Something like this: % hspice putout.spi > mynewfile.out Regards, Syed Cisco Systems, Inc > > Hello all, > > I am trying to change the sweeping range for certain curves in > s2ibis2 to avoid non-convergence problems but I am finding myself > unsuccessful at it. Does someone know how to modify the sweeping range > for s2ibis2? > > Thank you in advance. > > Gerald Truong > Motorola Computer Group > (602)438-3525 > > From owner-ibis Tue Nov 30 16:47:06 1999 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA07537 for ; Tue, 30 Nov 1999 16:47:05 -0800 (PST) Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35]) by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id TAA28710 for ; Tue, 30 Nov 1999 19:45:46 -0500 (EST) Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id TAA16652 for ; Tue, 30 Nov 1999 19:45:46 -0500 (EST) Received: from viewlogic.com (IDENT:jonp@linux.camarillo.viewlogic.com [139.181.194.149]) by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with ESMTP id QAA14260 for ; Tue, 30 Nov 1999 16:46:10 -0800 (PST) Sender: jonp@camarillo.viewlogic.com Message-ID: <38440D67.516AC9C5@viewlogic.com> Date: Tue, 30 Nov 1999 09:46:16 -0800 From: Jon Powell X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ibis@vhdl.org Subject: DesignCon Booth Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello IBIS members, As you may know, IBIS hosts a booth at DesignCon every year. What we have been doing for the past year (or so) is a 10x10 booth with logo's of all member companies prominently displayed. I am in charge of this operation and here is how it works: 1) Every IBIS member company (approved by Bob Ross) is entitled to a corporate logo sign on the booth backdrop. 2) The sign must be 8.5X11 inches. 3) The sign must be on a hard backing (foam board is typical) 4) It must be a general company logo (no product specific ads) 5) I will put velcro on the sign back for attaching to the booth. 6) You won't get the sign back. Now, I have a large number of signs from last year from the following companies. If you want me to use last years sign, please send me an official looking email stating such. I will NOT put up any logo's that I don't have authorization for. Mentor Graphics (Off red on white background) Xilinx (Black and off-red on white background, but it has a lot of aliasing in the characters) National Semi (white on blue background) Hyperlynx (light blue on white background) Veribest (black on white) Incases (purple and black on white) TI (black on white) HP (black on white, a lot of aliasing in the LOGO (ie. looks very fuzzy)) APSIM (many colors on white. Also looks pretty fuzzy) cadence (black and red on white) Cisco (many colors on white. looks good) NESA (black and blue on white) Viewlogic (red and black on white) NC (white on red in white) INTEL (blue on white) Compaq (red on white, looks a little fuzzy) Cypress (black on white) My personal recommendation, if you don't remember what you sign looked like last year, send me a new one. regards, jon (IBIS LIBRARIAN) From owner-ibis Tue Nov 30 16:53:01 1999 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA07570 for ; Tue, 30 Nov 1999 16:53:00 -0800 (PST) Received: from dlep8.itg.ti.com ([157.170.134.88]) by gatekeep.ti.com (8.9.3/8.9.3) with ESMTP id SAA20533; Tue, 30 Nov 1999 18:51:21 -0600 (CST) Received: from dlep8.itg.ti.com (localhost [127.0.0.1]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id SAA19101; Tue, 30 Nov 1999 18:50:58 -0600 (CST) Received: from dlee71.itg.ti.com (dlee71.itg.ti.com [157.170.135.149]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id SAA19089; Tue, 30 Nov 1999 18:50:58 -0600 (CST) Received: by dlee71.itg.ti.com with Internet Mail Service (5.5.2448.0) id ; Tue, 30 Nov 1999 18:50:25 -0600 Message-ID: From: "Fisher, Thomas" To: "'micohen@us.ibm.com'" Cc: "'ibis@eda.org'" Subject: RE: Virus Alert Date: Tue, 30 Nov 1999 18:50:01 -0600 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3B96.0D8ABE40" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF3B96.0D8ABE40 Content-Type: text/plain; charset="iso-8859-1" Michael, glad that you didn't try to open the 'exe' file. As you suspected, it is one of the viruses running rampant and I am in the process of clearing it from my machine. Sorry once again. (I guess some people just have too much time on their hands) Regards, Thomas Fisher (TI/Dallas) -----Original Message----- From: micohen@us.ibm.com [mailto:micohen@us.ibm.com] Sent: Tuesday, November 30, 1999 5:05 PM To: Fisher, Thomas Subject: RE: SPICE-To-IBIS Version 3 (S2IBIS3) Proposal Now Available For Review Thomas, Are the attached files for real, or have you been infected by one of the Viruses running rampant? Since I suspect the latter, I have not attempted to open the file (WinZip does not recognize it as a self-extracting Zip file). 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 "Fisher, Thomas" on 11/30/99 05:45:49 PM To: Michael Cohen/Raleigh/IBM@IBMUS cc: Subject: RE: SPICE-To-IBIS Version 3 (S2IBIS3) Proposal Now Available For Review Hi ! I received your email and I shall send you a reply ASAP. Till then, take a look at the attached zipped docs. bye. <> ------_=_NextPart_001_01BF3B96.0D8ABE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Virus Alert

Michael, glad that you didn't try to open the 'exe' = file.  As you suspected, it is one of the viruses running rampant = and I am in the process of clearing it from my machine.  Sorry = once again.  (I guess some people just have too much time on their = hands)

Regards, Thomas Fisher  (TI/Dallas)

-----Original Message-----
From: micohen@us.ibm.com [mailto:micohen@us.ibm.com]=
Sent: Tuesday, November 30, 1999 5:05 PM
To: Fisher, Thomas
Subject: RE: SPICE-To-IBIS Version 3 (S2IBIS3) = Proposal Now Available
For Review




Thomas,

Are the attached files for real, or have you been = infected by one of the
Viruses running rampant?  Since I suspect the = latter, I have not attempted
to open the file (WinZip does not recognize it as a = self-extracting Zip
file).

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


"Fisher, Thomas" <tomfisher@ti.com> = on 11/30/99 05:45:49 PM

To:   Michael = Cohen/Raleigh/IBM@IBMUS
cc:
Subject:  RE: SPICE-To-IBIS Version 3 (S2IBIS3) = Proposal Now Available For
      Review




Hi !
I received your email and I shall send you a reply = ASAP.
Till then, take a look at the attached zipped = docs.
bye.
 <<zipped_files.exe>>

------_=_NextPart_001_01BF3B96.0D8ABE40--