From owner-ibis Tue Apr 3 13:01:06 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f33K13528954 for ; Tue, 3 Apr 2001 13:01:05 -0700 (PDT) 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 QAA00340 for ; Tue, 3 Apr 2001 16:00:32 -0400 (EDT) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id QAA01146 for ; Tue, 3 Apr 2001 16:00:29 -0400 (EDT) Received: from innoveda.com ([139.181.6.202]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with ESMTP id NAA23259 for ; Tue, 3 Apr 2001 13:00:15 -0700 (PDT) Message-ID: <3ACA2B88.97D87288@innoveda.com> Date: Tue, 03 Apr 2001 12:59:04 -0700 From: Guy de Burgh Organization: Innoveda X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: EIA IBIS open Forum Minutes Content-Type: multipart/mixed; boundary="------------70E1153FDF99BCDF8F16EFE1" This is a multi-part message in MIME format. --------------70E1153FDF99BCDF8F16EFE1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------70E1153FDF99BCDF8F16EFE1 Content-Type: text/plain; charset=us-ascii; name="m033001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="m033001.txt" DATE: 4/2/01 SUBJECT: 3/30/01 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2001 PARTICIPANTS LIST: 3Com (& CommWorks) Roy Leventhal* Agilent (Mark Chang) Ansoft Corporation (Eric Bracken) Apple Computer John Figueroa Applied Simulation Technology Raj Raghuram, Norio Matsui, Fred Balistreri Avanti (Chen Hongyu) Brocade Communications Robert Badal Cadence Design Ian Dodd, Patrick Dos Santos, Heiko Dudek Cisco Systems Syed Huq, Lungfu Chen Compaq Peter LaFlamme, Ron Bellomio, Quang Dam, Bill Ham* Cypress (Rajesh Manapat) EMC Corporation Brian Arsenault, Jinhua Chen Fairchild Semiconductor Adam Tambone IBM Michael Cohen, Greg Edlund, Wes Martin, Yeon-Chang Hahm, Bill DeVey, Pravin Patel* Innoveda (& HyperLynx) Guy de Burgh, John Angulo, Cary Mandel Intel Corporation Stephen Peters*, Arpad Muranyi*, Dave Lorang, Michael Mirmak, Qinglun Chen, Will Hobbs LSI Logic Larry Barnes* Mentor Graphics Bob Ross*, Tom Dagostino, Chris Reid, Mike Donnelly, Hazem Hegazy, Tony Dunbar, Griff Derryberry, Dan Lake, Sherif Hammad, Mohammed Korany, Weston Beal, Chris Swaim, Ali Samii, Eric Ronger, Karine Loudet Micron Technology Randy Wolff, Yong Phan Mitsubishi (Tam (Tom) Cao) Molex Incorporated Gus Panella, Brian O'Malley Motorola (Ron Werner) National Semiconductor Milt Schwartz* Nortel Networks Calvin Trowell North East Systems Associates Edward Sayre Philips Semiconductor Zack Ciccone, Rob Mataheroe Quantic EMC (Mike Ventham) Robinson-Nugent, Inc. (Alexander Barr) Siemens (& Automotive) AG Bernhard Unger, Helmut Katzier, Katja Koller, Wolfram Meyer, Eckhard Lenski, Gerald Bannert, Burkhard Muller, Christian Marot, Manfred Maurer, Amir Motamedi, Hans Pichlmaier Signal Integrity Software Douglas Burns, Barry Katz, Walter Katz SiQual Scott McMorrow, Rob Hinz, Bernard Voss, Chris Brewster Texas Instruments Thomas Fisher, Stephen Nolan, Ramzi Ammar, Jean Claude Perrin* Time Domain Analysis Systems Dima Smolyansky, Steve Corey Tyco Electronics (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) John Berrie OTHER PARTICIPANTS IN 2001: Actel Corporation Silvia Montoya Acuson Kim Helliwell AMCC Jeff Smith ASIS Ltd David Wright BMW Friedrich Hasinger Cereva Networks Bob Haller EADS Airbus Industry Claude Huet (Aerospatiale) EFM Ekkehard Miersch, Horle Raines EIA Cecilia Fleming* FCI Sercu Stefaan Foundary Networks Bertram Chan Framatom Conectors Danny Morlion Fraunhofer Institute Mariusz Faferko, Peter Kralicek Reliability and Integration Fujitsu Ltd Tadashi Arai, Takeshi Murakami Heidelberger Druchmaschinen AG Wolfgang Kleinfeldt Huawei Technologies Rachild Chen Hyundai Electronics Jongho Kang Infineon Technologies Christian Sporrer Intrinsix Corporation Steven Chin National Institute of Applied Etienne Sicard Science (INSA) Nokia Tapani von Ravner, Mika Castren, Janne Uusitalo Oak Technology Darmin Jin Plexus Technology Group Joseph Socha Sintecs Hans Klos STMicroelectronics Peter Hirt, Fabrice Boissieres Sun Adrian Udenze Xilinx Susan Wu Independent, Consultant Al Davis* 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 April 20, 2001 (916) 356-9200 2-524674 3881934 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 Bill Ham is an interconnect architect at Compaq. He has a long term interest in modeling and has been involved with the t10 committee on SCSI issues and on the t11 committee on fiber channel issues. Bill is interested in common methodologies and in launch signals that vary with the data pattern. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross is expecting the final year 2000 financial report per a conversation with Cecilia Fleming. Also, Bob estimates that we have about 25 paid members this year. Cecilia plans to mail reminder invoices, and Bob will work with her regarding some new addresses. REVIEW OF MINUTES AND AR'S The March 2, 2001 IBIS Minutes were approved without change. The March 16, 2001 European IBIS Summit Meeting Minutes were approved with the following corrections reported by Bob Ross: The presentation title by Etienne Sicard was corrected to: EMC MODEL FOR PREDICTION OF PARASITIC EMISSION and the co-author is corrected to Claude Huet for the presentation by Jean Claude Perrin: INTEGRATED CIRCUITS MODELING, ICEM, INTEGRATED CIRCUITS ELECTROMAGNETIC MODEL, PROPOSAL: IEC62014-3 The corrected version of the minutes will be uploaded. The ARs will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Bob Ross reported that IBIS and the IBIS Accuracy Report was mentioned in the March 2001 issue of Printed Circuit Design, "Ensuring Signal Integrity in Microprocessor Motherboards and Memory" by Dima Smolyansky, pp. 18 - 24. NEW MODELS AVAILABLE, LIBRARY UPDATE Roy Leventhal reported that he updated the links of the IBIS Models page and plans to do some more corrections. Bob Ross stated that anyone who finds any problems should notify Roy. OPENS FOR NEW ISSUES Bob Ross - BUG55 - Control-Z Can be Used as End-of-File INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Bob Ross reported that we are waiting for vote on the FDIS (Final Draft International Standard). It is expected to close on April 13, 2001. If the vote is successful, then IBIS Version 3.2 can be published as an official international standard. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - No report. - IEC 62014-3 (ICEM) Integrated Circuit Electromagnetic Model Proposal (formerly, IEC 93/67/NP IBIS and EMC Simulation) - Jean Claude Perrin reported that IEC 62014-3, a technical report is expected to take two to three months for balloting. In the mean time, the Committee is working on a Cookbook to provide measurement methods to get the necessary parameters if they are not provided by semiconductor manufacturers. Jean Claude will send information by e-mail to Bob Ross. Bob asked Jean Claude if it was OK to download the document under consideration by IEC and put it on the IBIS FTP site for review. Jean Claude thought this would be all right. Jean Claude also stated that he seeks more participation in the Committee. - JEDEC JC-16 - Modeling and Testing - No report. - T10, Project 1414-DT - SCSI Signal Modeling (a Technical Committee of the National Committee for Information Technology (NCITS)) - Larry Barnes reported that the next meeting will be held April 2-4, 2001 in Massachusetts, and the following meeting will be in June or July in Connecticut. The SCSI Signal Modeling (SSM) Technical Report should be closed at that time. A new version of the document will be uploaded by Monday, April 1, 2001 and can be found under: http://www.t10.org/ssm.htm or directly at: ftp://ftp.t10.org/drafts/ssm/ssm-r03.pdf It contains references to the IBIS Cookbook and credits Stephen Peters for his work. Bob Ross indicated that he has made some editorial comments. Bill Ham initiated a technical discussion, which we conducted at this time since Larry had to leave early. Bill outlined the technical challenge that the launch signal strengths depend on the data pattern. Currently there are two levels (strong and weak), but more levels could be generated. Larry commented that the SCSI technology calls for differential current source drivers. Each side might be considered to have two drivers for full strength, but the second driver switches from a source to a sink if a second successive bit occurs. A fallback mechanism would describe this effect. The driver switches direction rather than just turns off (as Bob had suggested in private e-mail to Larry). The [Driver Schedule] keyword could describe this, but the SCSI Committee needs this description for typ, min and max conditions. Al Davis suggested working with the IBIS Futures committee so that a proper model type could be described. Larry will do this. Stephen Peters will provide Larry with the meeting information. Bob indicated that we should still investigate this through the BIRD process and target it for an IBIS Version 4.0 release. The actual implementation might still be through the macro language and a Version 4.0 template. DATE 2001 EUROPEAN IBIS SUMMIT MEETING FEEDBACK Bob Ross asked for comments. Bob stated that we had a lot of presentations, but we managed to get the key information presented and still have some questions and discussions after each one. Bob thanked Syed Huq for uploading Acrobat .pdf versions of the Power Point presentations. Arpad Muranyi commented that the presentations were high quality. Some interesting new ways to use the IBIS data files were given. Arpad felt that some advances need to be considered for IBIS-X implementation. DESIGN AUTOMATION CONFERENCE 2001 IBIS SUMMIT MEETING PLANS Bob Ross outlined the general plans for the next IBIS Summit Meeting. The annual meeting is held along with the Design Automation Conference (DAC). This year it is in Las Vegas, Nevada. The IBIS Summit Meeting will be held in the Hilton Hotel adjacent to the Las Vegas Convention Center. It is scheduled for Thursday, June 21, 2001, the day after the trade show portion of DAC. This meeting is sponsored by the IBIS Open Forum through the dues, and Bob will ask Guy de Burgh to coordinate the local arrangements. Bob stated that we hold election of IBIS officers. Elections are open to anyone, and nominations will be accepted at the meeting. However, Bob would also like to find out who is interested in serving so we can announce the candidates several meetings before the DAC IBIS Summit Meeting. In addition, we will plan to have presentations and discussions. We will probably have sessions on: Connector Specification IBIS-X IBIS Version 4.0 Issues Possibly other topics such as enhanced buffer extraction Roy Leventhal stated that he will probably give a presention at the IBIS Summit Meeting in September in Massachusetts. IBIS MODEL REVIEW COMMITTEE DISCUSSION Bob Ross reported that IBIS models from AMD and UTMC have been sent out by John Angulo for review. CONNECTOR PROPOSAL REVIEW Bob Ross stated that he had planned to start the Connector Specification review at this meeting, but did not have time to prepare for it. He plans to have another Connector Working Group Meeting on April 3, 2001 to consider more cleanup of the document. The first review will now be planned for the next meeting and expected to focus on the Header section. It should be aligned with the IBIS-X document header. Al Davis has started to prototype the Specification, but has uncovered some technical issues. He will bring them up to the Connector Working Group. Bob asked for some details off line. Al may discuss this at the Connector Working Group meeting. IBIS FUTURES (IBIS-X, API, BIRDxx) Stephen Peters summarized the discussions of the March 20, 2001 Working Group meeting. The Working Group is ready to release to the Open Forum the top level specification. A component section similar to that in IBIS Verison 3.2 has been added, but with some editorial changes to fit better with the IBIS-X structure. Stephen reported that the formal documentation of the macro-language still needs to be done. Also, the library guide needs to be written. The IBIS Futures Working Group wants to work with the Connector Working Group to insure the documents are compatible. The next IBIS Futures Working Group meeting is scheduled for April 3, 2001 and every two weeks thereafter. BIRD69.1 - GOLDEN WAVEFORMS Bob Ross suggested withdrawing BIRD69.1 since BIRD70 was issued to cover the same functions. The BIRD69.1 author, Greg Edlund, favors moving forward with BIRD70. Bob called for a vote on BIRD69.1 BIRD69.1 was rejected by Unanimous Vote BIRD70 - GOLDEN WAVEFORMS Al Davis introduced BIRD70 since Greg Edlund could not attend this meeting. BIRD70 contains some syntactical revisions to make it fit better with the IBIS-X macro language. It separates the testing portion of an IBIS model from the existing model portion used for electrical characterization. BIRD70 (and a future BIRD70.1) propose that the golden waveform information be located under a [Test Data] and [Test Load] keyword, not under the [Model] keyword as was proposed in BIRD69.1. (In BIRD70, the waveforms are still under the [Rising Waveform] and [Falling Wave] keywords.) Al and Bob Ross commented on a few points and also stated that some BIRD70.1 changes were already planned. Bob wanted the detailed discussions to be conducted after BIRD70.1 is issued. Al commented that he did not like listing default [Test Load] values. Bob agreed. If the sub-parameter is missing, the defaults should be automatically set to open for shunt elements, and short for series elements. Transmission lines without the Td subparameter value would be assumed to be shorted. The default voltage might be an issue, but BIRD70.1 should provide a solution. Bob stated that Greg Edlund plans to issue BIRD70.1. Some editorial changes might be given to Greg beforehand. BIRD70.1 will add a subparameter to name the Driver model. It will describe the equivalent package model directly, if used L, C, and R subparameters. AR - Greg Edlund issue BIRD70.1 with planned revisions and other submitted changes. OTHER PENDING BIRDS Bob Ross commented that the Fallback Submodel BIRD had been discussed earlier as part of the SCSI t10 report. There is still needed for this BIRD to describe the dynamic output control functionality. Two other BIRDs include one proposal for PCI thresholds, and one for simultaneous Switched Outputs (SSO). IBISCHK3 BUG TRACKING Bob Ross stated that Matthew Flora provided fixes to BUG53 and BUG34. The fixes have been included in a new ibischk3 Version 3.2.7. No other fixes were done so that the new executable could be released soon. Prior to the new Version, ibischk3 incorrectly issued Warnings for correct *Open* IBIS models. Matthew generated new source code and distributed it to the companies that had purchased source code licenses. Matthew also generated the Windows executable. Guy de Burgh generated executables for Unix systems. Bob stated that the new executables are uploaded: http://www.eda.org/pub/ibis/ibischk3/ The older Verison 3.2.5 and Version 3.2.6 executables are archived under this directory. Bob expects Syed Huq to generate and upload the new executables for Linux. - BUG54 - Corners with NA give Bad Test Load Warnings Because Michael Mirmak could not attend this meeting, and because Bob needed to consider how to implement BUG54, Bob decided to postpone the discussion on how to resolve BUG54 until the next meeting. Bob commented that BIRD54 had been modified in response to comments from the March 2, 2001 IBIS meeting. - BUG55 - Control-Z Can be Used as End-of-File (new agenda item) Bob Ross introduced BUG55, authored by Matthew Flora. BUG55 describes a situation that in older DOS and Windows based file, a control-Z can serve as an End-of-File character. Sometimes these characters are incorrectly inserted within a file. If they exist, further ibischk3 processing of the file is terminated. The resolution is to set a flag to read Windows files in binary mode. Then incorrect characters such as control-Z can be detected in in a file in the same manner that they are now detected in Unix operating systems. Al Davis had some questions. Bob suggested reviewing BUG55 which is now uploaded under http://www.eda.org/pub/ibis/bugs/ibischk/ to get a more precise description of the technical details. Bob classified BUG55 as Annoying, Low, Open. The plan is to fix it, unless some technical concerns are uncovered. NEXT MEETING: The next teleconference meeting will be on Friday, April 20, 2001, 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 stephen.peters@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@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Roy Leventhal (837) 797-2152, Fax: (847) 222-2799 roy_leventhal@3com.com Senior Engineer, CommWorks Corp. (a wholly owned 3Com subsidiary) 1800 W. Central Rd. Mt. Prospect, IL 60056-2293 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 jangulo@innoveda.com Development Engineer, Innoveda 14715 N.E. 95th Street, Suite 200 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.eigroup.org/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. ============================================================================== --------------70E1153FDF99BCDF8F16EFE1-- From owner-ibis Wed Apr 11 05:00:53 2001 Received: from palgong.knu.ac.kr (palgong.kyungpook.ac.kr [155.230.12.2]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3BC0m519757 for ; Wed, 11 Apr 2001 05:00:52 -0700 (PDT) Received: from adagio ([155.230.13.223]) by palgong.knu.ac.kr (8.11.0/8.11.0) with SMTP id f3BC0tj05174 for ; Wed, 11 Apr 2001 21:00:56 +0900 (KST) Message-ID: <000c01c0c27f$0a8d9560$df0de69b@knu.ac.kr> From: =?ks_c_5601-1987?B?w9a5q7+t?= To: Subject: A question for IBIS data Date: Wed, 11 Apr 2001 21:00:45 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C0C2CA.7A042C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C0C2CA.7A042C10 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiBNeSBuYW1lIGlzIE1vby15ZXVsIENob2ksIHRoZSBncmFkdWF0ZSBzdHVkZW50 IG9mIEt5dW5ncG9vayBOYXRpb25hbCBVbml2ZXJzaXR5LCBLT1JFQS4NCkkgaGF2ZSBzdHVkaWVk IHRoZSBJQklTIHRvIFNQSUNFIG1vZGVsaW5nIGFuZCBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgcmlz aW5nIGFuZCBmYWxsaW5nIHdhdmVmb3JtLiBJIGtub3cgdGhhdCB0aGUgd2F2ZWZvcm0gcGFyYW1l dGVyIGlzIHRpbWUtdm9sdGFnZSBkYXRhIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgd2hlcmUgdGhl IHZvbHRhZ2VzIGFyZSBtZWFzdXJlZC4gU3BlY2lhbGx5LCB3aGVuIHRoZSBEVVQgcGFyYW1ldGVy IGV4aXN0LCBJIGxpa2UgdG8ga25vdyB0aGUgbm9kZSBtZWFzdXJlZC4NCiBJIGFtIGxvb2tpbmcg Zm93YXJkIHRvIHlvdXIgcmVwbHksIHRoYW5rIHlvdS4gDQpIYXZlIGEgbmljZSBkYXkuDQoNCkJl c3QgcmVnYXJkcywNCk1vby15ZXVsIENob2kNCg== ------=_NextPart_000_0009_01C0C2CA.7A042C10 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLDwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDs8L0ZP TlQ+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mj5NeSBuYW1lIGlzIE1vby15ZXVsIA0KQ2hvaSwg dGhlIGdyYWR1YXRlIHN0dWRlbnQgb2YgS3l1bmdwb29rIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtP UkVBLjwvRk9OVD48L0RJVj4NCjxESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGhhdmUgc3R1ZGll ZCB0aGUgSUJJUyB0byBTUElDRSBtb2RlbGluZyBhbmQgaGF2ZSBhIA0KcXVlc3Rpb24mbmJzcDth Ym91dCByaXNpbmcgYW5kIGZhbGxpbmcgd2F2ZWZvcm0uIEkga25vdyB0aGF0IHRoZSB3YXZlZm9y bSANCnBhcmFtZXRlciBpcyB0aW1lLXZvbHRhZ2UgZGF0YSBidXQgSSBkb24ndCZuYnNwO3VuZGVy c3RhbmQgd2hlcmUgdGhlIHZvbHRhZ2VzIA0KYXJlIG1lYXN1cmVkLiBTcGVjaWFsbHksJm5ic3A7 d2hlbiB0aGUmbmJzcDtEVVQgcGFyYW1ldGVyIA0KZXhpc3QsJm5ic3A7SSZuYnNwO2xpa2UgdG8g a25vdyB0aGUgbm9kZSBtZWFzdXJlZC48QlI+Jm5ic3A7SSBhbSBsb29raW5nIGZvd2FyZCANCnRv IHlvdXIgcmVwbHksIHRoYW5rIHlvdS4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ SGF2ZSBhIG5pY2UgZGF5LjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj5CZXN0IHJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ TW9vLXlldWwgQ2hvaTwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0009_01C0C2CA.7A042C10-- From owner-ibis Wed Apr 11 07:25:14 2001 Received: from mtvwca1-smrly1.gtei.net (mtvwca1-smrly1.gtei.net [128.11.176.196]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3BEPA520402 for ; Wed, 11 Apr 2001 07:25:13 -0700 (PDT) Received: from fairchild-cp.fairchildsemi.com (fairchild-cp.fairchildsemi.com [192.233.132.79]) by mtvwca1-smrly1.gtei.net (Postfix) with SMTP id EB1125F8E for ; Wed, 11 Apr 2001 14:24:42 +0000 (GMT) Received: FROM fairchildsemi.com BY hqnttest01.fairchildsemi.com ; Wed Apr 11 10:24:01 2001 -0400 Received: from notes.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4) id KAA09795; Wed, 11 Apr 2001 10:21:40 -0400 Subject: A question for IBIS data To: From: Adam.Tambone@fairchildsemi.com Date: Wed, 11 Apr 2001 10:21:39 -0400 Message-ID: X-MIMETrack: Serialize by Router on SPNOTES01/Corporate/FSC(Release 5.0.6a |January 17, 2001) at 04/11/2001 10:21:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Moo-yeul, The voltages in the V-t waveforms represent the output voltages of the DUT. The node these voltages are taken from is the output node. The question is what were the loading conditions in which the data was taken and did it include package parasitics. The sub-parameters: L_fixture, R_fixture, V_fixture, C_fixture specify the loading conditions in which the V-t data was taken. The sub-parameters: L_dut, R_dut, C_dut specify the package parasitics that are included in the V-t data taken. If the above subparameters are not included in the IBIS datasheet then the V-t data was taken at a node that does not include packaging or a load. The effect of c_comp is included in the V-t data. See pgs42-44 of the 3.2 spec. Adam Tambone From owner-ibis Thu Apr 12 17:39:52 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3D0do529569 for ; Thu, 12 Apr 2001 17:39:51 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA27690; Thu, 12 Apr 2001 17:39:16 -0700 (PDT) Received: from mentor.com (bobr-laptp.wv.mentorg.com [147.34.53.78]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2X80C18Z; Thu, 12 Apr 2001 17:39:16 -0700 Message-ID: <3AD64AAA.83F27BB0@mentor.com> Date: Thu, 12 Apr 2001 17:39:06 -0700 From: Bob Ross Organization: Mentor Graphics Corporation X-Mailer: Mozilla 4.61 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS Meeting Agenda 4/20/01 Content-Type: multipart/mixed; boundary="------------E2FD8574F5D3549614D37DAC" This is a multi-part message in MIME format. --------------E2FD8574F5D3549614D37DAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------E2FD8574F5D3549614D37DAC Content-Type: text/plain; charset=us-ascii; name="agenda.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="agenda.txt" IBIS Open Forum Meeting Agenda for 4/20/01 Bridge Number Reservation # Passcode (916) 356-9200 2-524674 3881934 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 Leventhal, 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) Ross - IEC 62014-3 (ICEM) Integrated Circuits Electromagnetic Model Proposal (IEC 93/67/NP IBIS and EMC Simulation) Perrin/Ross - JEDEC JC-16 Modeling and Testing Sessions - T10, Project 1414-DT - SCSI Signal Modeling Barnes DAC 2001 IBIS Summit Meeting Planning Ross IBIS Model Review Committee Angulo New Administrative Issues All 8:30 Technical Discussion (some topics may be deferred) Connector Proposal Review Panella/Ross IBIS Futures Group Report (IBIS-X, API, BIRDxx) Peters BIRD70 - Golden Waveforms Edlund Other Pending BIRDS Ross ibischk3 Bug Tracking Ross - BUG54 - Corners with NA Give Bad Test Load Warnings Mirmak - BUG56 - Parser Fails to Detect Always Flowing Current Flora New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off --------------E2FD8574F5D3549614D37DAC-- From owner-ibis Fri Apr 13 14:35:22 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3DLZI505797 for ; Fri, 13 Apr 2001 14:35:19 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA27987; Fri, 13 Apr 2001 14:34:36 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2X80CGPZ; Fri, 13 Apr 2001 14:34:35 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3AD770E7.E4D0E0ED@mentor.com> Date: Fri, 13 Apr 2001 14:34:31 -0700 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: =?iso-8859-1?Q?=C3=D6=B9=AB=BF=AD?= CC: ibis@eda.org Subject: Re: A question for IBIS data References: <000c01c0c27f$0a8d9560$df0de69b@knu.ac.kr> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by relay1.wv.mentorg.com id OAA27987 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id f3DLaF505798 Hello Moo-yeul: The waveform is taken at the junction of the _dut and _fixture parameters if the _dut parameters exist. Otherwise, it is taken at the output node directly. Bob Ross Mentor Graphics ÃÖ¹«¿­ wrote: > > Hello, > > My name is Moo-yeul Choi, the graduate student of Kyungpook National > University, KOREA. > I have studied the IBIS to SPICE modeling and have a question about rising and > falling waveform. I know that the waveform parameter is time-voltage data but > I don't understand where the voltages are measured. Specially, when the DUT > parameter exist, I like to know the node measured. > I am looking foward to your reply, thank you. > Have a nice day. > > Best regards, > Moo-yeul Choi From owner-ibis Mon Apr 16 08:49:08 2001 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3GFn1507040 for ; Mon, 16 Apr 2001 08:49:04 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA245314 for ; Mon, 16 Apr 2001 11:46:59 -0400 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id LAA160046 for ; Mon, 16 Apr 2001 11:43:27 -0400 Importance: Normal Subject: BIRD 70.1 To: ibis@vhdl.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Gregory R Edlund" Date: Mon, 16 Apr 2001 10:47:50 -0500 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.6a |January 17, 2001) at 04/16/2001 10:48:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Here is BIRD 70.1 for discussion at Friday's Open Forum conference call. After discussion with Bob Ross and Al Davis, I made some significant changes that should make it upwardly compatible. Please note that this BIRD sets up the infrastructure for a future BIRD to facilitate non-RC standard loads. In fact, that BIRD becomes almost trivial. I have two questions for readers: 1) Semiconductor vendors: If your customers require you to supply Golden Waveforms and IF a production-quality SPICE-to-IBIS modeling tool were available to support them, would this BIRD enable you to do so? 2) EDA vendors: If your customers asked you to support automated analysis of Golden Waveforms and produce a correlation figure of merit table, would this BIRD enable you to do so? Thanks for your consideration everyone! Greg Greg Edlund Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com ******************************************************************************* ******************************************************************************* BIRD ID#: 70.1 ISSUE TITLE: Golden Waveforms REQUESTOR: Greg Edlund, IBM DATE SUBMITTED: April 16, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Golden Waveforms are a set of SPICE waveforms simulated using known ideal test loads. They are useful in verifying the accuracy of behavioral simulation results for any given simulator. They are not the same thing as the traditional VT tables recommended in the "IBIS Cookbook." The "I/O Buffer Accuracy Handbook" recommends a set of ideal test loads for classical push-pull and open-drain drivers. There is currently a problem with including Golden Waveforms in an IBIS datasheet: the simulator tries to use these waveforms to construct its stimulus waveform, and erroneous simulations result. This BIRD proposes a new syntactical construct to tell the simulator that a waveform is a Golden Waveform. The simulator may then choose to ignore the data or (better yet) run a set of simulations using the network and circuit parameters provided and report the correlation between the simulation results and the Golden Waveforms. The mechanism for describing a Golden Waveform involves two new keywords whose scope is global: [Test Load] and [Test Data]. Under the [Test Data] keyword are two new keywords whose scope is local: [Rising Golden Waveform] and [Falling Golden Waveform]. [Test Load] is a description of a test load network that may be referenced by any Golden Waveform under the [Test Data] keyword. [Test Data] is a marker keyword that indicates the beginning of a group of Golden Waveforms. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: |============================================================================= | Keywords: [Test Data] | Required: No | Description: Indicates the beginning of a pair of Golden Waveforms | and references the conditions under which they were derived. | An IBIS file may contain any number of [Test Data] sections | representing different driver and load combinations. | | Sub-Params: Test_data_type, Driver_model, Test_load, Test_point, | T_period, T_meas, V_meas | | Usage Rules: The name following the [Test Data] keyword is required. | It allows a tool to select which data to analyze. | | The Test_data_type subparameter is required, and its value | must be either "single_ended" or "differential." | | The Driver_model subparameter is required. Its value | specifies the "device-under-test" and must be a valid [Model] | name. | | The Test_load subparameter is required and indicates which | [Test Load] was used to derive the Golden Waveforms. It must | reference a valid [Test Load] name. | | The Test_point subparameter is optional. It indicates which | node in the test load network the Golden Waveforms represent. | The legal values for Test_point are "near" and "far." If | Test_point is not specified, it defaults to "far." | | The T_period subparameter is optional. In the case that the | Golden Waveforms represent more than one rising or falling | edge, the T_period subparameter tells the simulator the | period between rising or falling edges. This subparameter | is useful when constructing a test load in which a reflection | from the first edge hits the driver during the second edge. | | The T_meas subparameter is optional. It captures the time | at which the standard load crosses the threshold specified | in the component datasheet during a SPICE simulation. This | subparameter is useful when correlating timing intervals | between SPICE and behavioral simulations. It defines the | beginning of a timing interval. | | The V_meas subparameter is optional and is also used to | perform timing interval correlation. The end of a timing | interval is defined as the time when a Golden Waveform or | a behavioral waveform crosses V_meas. | | A timing interval in a behavioral waveform begins when | the waveform crosses V_meas defined in the [Model] keyword | while driving C_ref and R_ref, i.e. the standard load defined | in the component datasheet. Note that there are two | DIFFERENT V_meas subparameters in IBIS: one associated with | [Model] and one associated with [Test Data]. | |----------------------------------------------------------------------------- [Test Data] Data1 Test_data_type single_ended Driver_model Buffer1 Test_load Load1 Test_point far T_period = 10ns | variable typ min max T_meas 1.0ns 0.5ns 1.5ns V_meas 0.75V 0.75V 0.75V | |============================================================================= | Keywords: [Rising Golden Waveform], [Falling Golden Waveform] | Required: Yes (within the scope of [Test Data]) | Description: Describes the shape of the rising and falling Golden | Waveforms of a given driver and a given [Test Load]. | A model developer may use the [Rising Golden Waveform] and | [Falling Golden Waveform] keywords to document Golden | Waveforms whose purpose is to facilitate the correlation of | SPICE and behavioral simulations. | | Sub-Params: None. | | Usage Rules: The process, temperature, and voltage conditions under which | the Golden Waveforms are generated must be identical to those | used to generate the VI and VT tables. The Golden Waveforms | must be generated using unpackaged driver and receiver models. | The simulator must NOT use the Golden Waveform tables in the | construction of its internal stimulus function. | |----------------------------------------------------------------------------- | [Rising Golden Waveform] | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Golden Waveform] | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | |============================================================================= | Keywords: [Test Load] | Required: No | Description: Defines a generic test load network and its associated | electrical parameters for reference by Golden Waveforms | under the [Test Data] keyword. The Golden Waveform | tables access a given [Test Load] by the value of the | Test_load subparameter under the [Rising Golden Waveform] | and [Falling Golden Waveform] keywords. | | Sub-Params: Test_data_type, C1_near, Rs_near, Ls_near, C2_near, Rp1_near, | Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, | C1_far, V_term1, V_term2, Receiver_model, R_diff_near, | R_diff_far. | | Usage Rules: The value of the Test_data_type subparameter must be either | "single_ended" or "differential." | | The subparameters specify the electrical parameters | associated with a fixed generic test load. The diagram | below describes the single_ended test load. | | All subparameters except Test_data_type are optional. | If omitted, series elements are shorted and shunt elements | are opened by default. | | | V_term1 | o-----------o | | | | \ \ receiver_model_name | ______ / / ______ | | | NEAR Rp1_near \ \ Rp1_far FAR | | | | |\ | / / | |\ | | | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \ | | | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-| > | | | | / | | | | Td | | | | | / | | | |/ | | C1_near | \ Zo \ | C2_far | | |/ | | |______| === === / / === === |______| | | C2_near | \ \ | C1_far | | | | / / | | | | | | V_term2 | | | | o--------------o o-----------o o--------------o | | Rp2_near Rp2_far | | GND GND | | | If the Td subparameter is present, then the Zo subparameter | must also be present. If the Td subparameter is not present, | then the simulator must remove the transmission line from | the network and short the two nodes to which it was | connected. | | V_term1 defines the termination voltage for parallel | termination resistors Rp1_near and Rp1_far. This voltage | is not related to the [voltage range] keyword. | V_term2 defines the termination voltage for parallel | termination resistors Rp2_near and Rp2_far. | | Receiver_model is optional and indicates which, if any, | receiver is connected to the far end node. If not used, the | network defaults to no receiver. | | If Test_load_type is differential, a the test load is a | pair of the above circuits. If the R_diff_near subparameter | is used, it is connected between the near nodes of the two | circuits. If the R_diff_far subparameter is used, it is | connected between the near nodes of the two circuits. | |----------------------------------------------------------------------------- | [Test Load] Load1 Test_load_type single_ended C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff = 100 Receiver_model Input1 | variable typ min max Vterm1 1.5 1.4 1.6 Vterm2 0.0 0.0 0.0 | | Example Transmission Line and Receiver test load from "I/O Buffer Accuracy | Handbook," section 3.4.4. | [Test Load] Tline_rcv Td = 1n Zo = 50 Receiver_model Input1 |----------------------------------------------------------------------------- ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Please refer to BIRD 69.1 for history. BIRD 70 came about a result of an attempt to make BIRD 69.1 upwardly compatible with IBIS-X. BIRD 70 is actually more compact and efficient because it allows multiple models to access the same [Test Load]. Recommendations came from Bob Ross, Al Davis, and the IBIS Open Forum, 3/2/01. Changes between BIRD 69.1 and BIRD 70: 1. Scope of the "generic test load" is now global rather than being local to a particular model. This is a big improvement. 2. Added one subparameter, Golden_test_load, to [Rising Waveform], [Falling Waveform] keywords. Added text to describe new the subparameter. The Golden_test_load subparameter calls a [Test Load]. 3. Exported all the other code to the new [Test Load] keyword. 4. Removed T_ref subparameter. To do timing correlation, the simulator can pick a point on the 50 Ohm VT waveform as its "SPICE reference point" and then simulate both the 50 Ohm load and the Golden_test_load to calculate a time difference. 5. Removed Pkg_pin parameter. It is too complicated. The user can model a simple single-pin lumped circuit using the parameters supplied. 6. Added Tline_present subparameter. If not used, the Tline should be removed from the simulation rather than assigned a very small delay value. This prevents the simulator from taking ridiculously small time steps. 7. Replaced V_termxxx with tables similar to the dV/dt_x subparameters. This makes the BIRD more economical. 8. Got rid of the paragraph that read, "Using the Golden Waveform tables..." This seemed to be redundant. 9. Specified which parameters are optional and which are required. Changes between BIRD 70 and BIRD 70.1: 1. Moved the Golden Waveforms OUT of the [Model] scope and under the scope of a new keyword, [Test Data]. 2. Changed [Rising Waveform] to [Rising Golden Waveform]. Changed [Falling Waveform] to [Falling Golden Waveform]. 3. Added subparameter Driver_model under [Rising Golden Waveform] and [Falling Golden Waveform]. This is necessary because the waveforms are now outside the scope of the [Model]. 4. Changed the subparameter Golden_test_load to Test_load. 5. Added the V_meas subparameter to indicate where timing correlation measurements should begin and end. 6. Added subparameters Test_data_type and Test_load_type to facilitate upward compatibility with future versions of IBIS. 7. Removed Tline_present subparameter in favor of language explaining that the simulator should remove the Tline if Td is not present. 8. Moved Driver_model, Test_load, V_meas under the scope of [Test Data]. 9. Added T_meas subparameter to facilitate timing correlation. 10. R_diff became R_diff_near and R_diff_far. 11. Added T_period subparameter to allow multi-cycle correlation in the case where a reflection hits the driver while it is switching. BIRD 70.1 adds 205 lines of code to IBIS, of which 162 are comments. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: See BIRD 69.1. ******************************************************************************* From owner-ibis Mon Apr 16 10:15:40 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3GHFb507385 for ; Mon, 16 Apr 2001 10:15:39 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA27225; Mon, 16 Apr 2001 10:15:00 -0700 (PDT) Received: by svr-orw-exc-02.wv.mentorg.com with Internet Mail Service (5.5.2653.19) id <2X80C2GK>; Mon, 16 Apr 2001 10:14:59 -0700 Message-ID: <2179BC5B6583D311B44700508B441469041775D3@svr-orw-exc-02.wv.mentorg.com> From: "Reid, Chris" To: "'ibis@vhdl.org'" Subject: Reduced strength drivers and Driver Schedules Date: Mon, 16 Apr 2001 10:13:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hello, At the IBIS summit meeting in January Larry Barnes indicated the need for IBIS support of the SCSI drivers which reduce their drive strength when the same bit value is held for more than one bit period. This can be accomplished with the current driver schedule, and can be made a little more robust by adding a new (previously illegal) schedule with a change in the interpretation. It is easiest to explain with an example. As I understand it the driver can be modeled as two stages. Both stages are on for the first bit, then only one of them if the next bit is the same as the previous bit. For example, if the bit pattern is: 0 1 1 1 0 1 0 0 0 Then the pattern for the two drivers should be: 0 1 1 1 0 1 0 0 0 (the primary driver has the same bit pattern as above.) 1 1 0 0 0 1 0 1 1 (the secondary driver helps only when the bit sense changes.) (here I'm assuming the initial bit value (0) has been held for at least one previous bit period.) For example, if the primary driver is 50 ohm and the secondary driver is 100 ohm then the combined driver has four states: Ls: Both pulling low: (1/(1/50 + 1/100)) = 33.333 ohms pulling low Lw: 100 ohms high and 50 ohms low Hw: 100 ohms low and 50 ohms high Hs: Both pulling high So the combined two drivers in the above case are in the states: Lw Hs Hw Hw Ls Hs Ls Lw Lw (0 1 1 1 0 1 0 0 0) For simplicity assume the bit period is 5 ns (in actuality its 6.25 ns). Then a driver schedule as follows will produce the desired states: MS1: Driver Rise-On Rise-Off Fall-On Fall-Off d50Ohm 0 NA 0 NA d100Ohm NA 5ns NA 5ns The initial state is obtained by assuming the driver has been in that state for a long time. For example, suppose the simulation starts with the driver low. Then we assume that a long time ago there was a falling transition. This means that d50Ohm is in the low state and d100Ohm is in the high state (because a "long time" is more than 5 ns.) Remember, the Fall-Off delay is when the driver is supposed to make a rising transition relative to the falling edge. Similarly a Rise-Off delay is when the driver is supposed to make a falling transition relative to the rising edge. Thus the d100Ohm driver switches exactly opposite to the d50Ohm driver but with a 5ns delay. If each bit period is 5 ns then a little work will convince you that the above driver schedule will produce the sequence of states given above as the desired sequence for the example bit pattern. There is another way to accomplish almost the same thing, but with more flexibility and some differences as will be explained below. Consider the driver schedule: MS2: Driver Rise-On Rise-Off Fall-On Fall-Off d50Ohm 0 NA 0 NA d100Ohm 0 5ns 0 5ns This schedule is not legal in IBIS 3.2. The reason is that it calls for a falling transition (fall-on delay equal to zero) when the driver may already be low because of the 5ns rise-off delay! However, there is a simple way to use this schedule. If the schedule says to transition low when the device is already low, just stay there. Similarly, if it says to transition high when it is already high, just leave the device high. With this understanding the second driver schedule (MS2) produces exactly the same result as the first one (MS1) in the case where every bit period is 5ns. The difference is that MS2 also allows other possibilities which may be interesting for some devices. It also behaves differently if some bits are held for less than 5ns. For example, consider driving these two schedules with a pulse train defined as: Start Low (assume it has been low for a long time) Then transition at the times: 0ns 4ns Then MS1 produces the states: Lw if t < 0 Hs if 0 <= t < 4ns Lw if 4ns <= t < 5ns Ls if 5ns <= t < 9ns Lw if 9ns <= t But MS2 produces the states: Lw if t < 0 Hs if 0 <= t < 4ns Ls if 4ns <= t <= 9ns Lw if 9ns <= t The difference is that MS1 is in state Lw from 4ns to 5ns while MS2 is in state Ls for that time period (the low transition starts at 4ns.) The reason for this difference is the MS2 schedules d100Ohm to transition low at time 5ns because of the master rising transition at time 0. It also schedules a falling transition at time 4ns because of the master falling transition at time 4ns. Thus the transition occurs at 4ns and when the 5ns transition is reached d100Ohm is already in the low state so there is nothing to do. Thus the MS2 version may be better than the MS1 version because: 1) It responds better to over clocking (the 4ns transition example.) 2) It is more flexible. On the other hand, MS1 requires no change to IBIS so can be used now. Note that the change to make MS2 usable would not involve a new syntax, just a new way to use the driver schedule when all four transitions are specified. Interested parties please respond. We need a BIRD if people think MS2 is a good way to go. Otherwise, MS1 shows that these drivers can already be simulated with IBIS (assuming your simulation vendor supports full driver schedules.) Thanks, Chris Reid From owner-ibis Mon Apr 16 10:47:42 2001 Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3GHlc507524 for ; Mon, 16 Apr 2001 10:47:40 -0700 (PDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 16 Apr 2001 13:46:34 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Apr 2001 13:46:36 -0400 Message-ID: <31AF4D00A662D211B6D10000F8BCBC2403DFA296@bcarua63.ca.nortel.com> From: "Hassan Ali" To: ibis Subject: SpecctraQuest/HSPICE IBIS implementation Date: Mon, 16 Apr 2001 13:46:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C69D.2AF81380" X-Orig: 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_000_01C0C69D.2AF81380 Content-Type: text/plain; charset="iso-8859-1" I have created an IBIS model of a differential driver from its HSPICE model. When I use the IBIS model in a SpecctraQuest simulation, the results match those I obtain from an HSPICE simulation using the HSPICE model. However, when I use the IBIS model in an HSPICE simulation, I obtain different results. The output waveform seems to be scaled somehow as shown in the attached JPEG file. The yellow curve is the correct output; the blue curve is the incorrect one. Does anybody know what gives rise to that apparent scaling? (BTW: I obtain same results in HSPICE 99.2 and 2000.4). Thanks. Hassan. <> ------_=_NextPart_000_01C0C69D.2AF81380 Content-Type: image/jpeg; name="sq_hspice_waveforms.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sq_hspice_waveforms.jpg" /9j/4AAQSkZJRgABAAEAYABgAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW5jLiBWMS4wMQD/2wCE ABQODxEPDBQREBEXFRQYHjMhHhwcHj4sLyUzSkFOTEhBR0ZRXHVjUVdvWEZHZotnb3l9g4WDT2KQ mo+AmXWBg34BFRcXHhoePCEhPH5UR1R+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fv/EAaIAAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+foRAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNU VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/AABEIASUC8wMBEQACEQEDEQH/ 2gAMAwEAAhEDEQA/AMH/AISXV/8An7/8hp/hRYvnkH/CS6v/AM/f/kNP8KLBzyD/AISXV/8An7/8 hp/hRYOeQf8ACS6v/wA/f/kNP8KLBzyD/hJdX/5+/wDyGn+FFg55B/wkur/8/f8A5DT/AAosHPIP +El1f/n7/wDIaf4UWDnkX4NV1WR7YSakVSaCSdisCEqE38AcZ+57daLBzyG/8JBJ/wBBe7/8AYv/ AIuiwc8g/wCEgk/6C93/AOAMX/xdFg55B/wkEn/QXu//AABi/wDi6LBzyD/hIJP+gvd/+AMX/wAX RYOeQf8ACQSf9Be7/wDAGL/4uiwc8g/4SCT/AKC93/4Axf8AxdFg55B/wkEn/QXu/wDwBi/+LosH PIP+Egk/6C93/wCAMX/xdFg55B/wkEn/AEF7v/wBi/8Ai6LBzyD/AISCT/oL3f8A4Axf/F0WDnkS xazNNHO66xdAQoHbNjFyNwXj5vVhRYOeRF/wkEn/AEF7v/wBi/8Ai6LBzyD/AISCT/oL3f8A4Axf /F0WDnkH/CQSf9Be7/8AAGL/AOLosHPIP+Egk/6C93/4Axf/ABdFg55B/wAJBJ/0F7v/AMAYv/i6 LBzyD/hIJP8AoL3f/gDF/wDF0WDnkH/CQSf9Be7/APAGL/4uiwc8g/4SCT/oL3f/AIAxf/F0WDnk H/CQSf8AQXu//AGL/wCLosHPIP8AhIJP+gvd/wDgDF/8XRYOeQf8JBJ/0F7v/wAAYv8A4uiwc8g/ 4SCT/oL3f/gDF/8AF0WDnkH/AAkEn/QXu/8AwBi/+LosHPIP+Egk/wCgvd/+AMX/AMXRYOeRLcaz NbyBH1i6JKI/FjF0ZQw/i9DRYOeRF/wkEn/QXu//AABi/wDi6LBzyD/hIJP+gvd/+AMX/wAXRYOe Qf8ACQSf9Be7/wDAGL/4uiwc8g/4SCT/AKC93/4Axf8AxdFg55EVvq623meTql2vmyGR/wDQozlj 1P36BKTRL/wkEn/QXu//AABi/wDi6LD55EcOsiAOItUuk3uXbFjFyxOST89AlNok/wCEgk/6C93/ AOAMX/xdFh88g/4SCT/oL3f/AIAxf/F0WDnkH/CQSf8AQXu//AGL/wCLosHPIP8AhIJP+gvd/wDg DF/8XRYOeQf8JBJ/0F7v/wAAYv8A4uiwc8g/4SCT/oL3f/gDF/8AF0WDnkSxazNNHO66xdAQoHbN jFyNwXj5vVhRYOeRF/wkEn/QXu//AABi/wDi6LBzyD/hIJP+gvd/+AMX/wAXRYOeQf8ACQSf9Be7 /wDAGL/4uiwc8g/4SCT/AKC93/4Axf8AxdFg55B/wkEn/QXu/wDwBi/+LosHPIP+Egk/6C93/wCA MX/xdFg55B/wkEn/AEF7v/wBi/8Ai6LBzyD/AISCT/oL3f8A4Axf/F0WDnkH/CQSf9Be7/8AAGL/ AOLosHPIP+Egk/6C93/4Axf/ABdFg55B/wAJBJ/0F7v/AMAYv/i6LBzyD/hIJP8AoL3f/gDF/wDF 0WDnkH/CQSf9Be7/APAGL/4uiwc8g/4SCT/oL3f/AIAxf/F0WDnkS3GszW8gR9YuiSiPxYxdGUMP 4vQ0WDnkRf8ACQSf9Be7/wDAGL/4uiwc8g/4SCT/AKC93/4Axf8AxdFg55B/wkEn/QXu/wDwBi/+ LosHPIP+Egk/6C93/wCAMX/xdFg55B/wkEn/AEF7v/wBi/8Ai6LBzyD/AISCT/oL3f8A4Axf/F0W DnkH/CQSf9Be7/8AAGL/AOLosHPIP+Egk/6C93/4Axf/ABdFg55B/wAJBJ/0F7v/AMAYv/i6LBzy D/hIJP8AoL3f/gDF/wDF0WDnkH/CQSf9Be7/APAGL/4uiwc8g/4SCT/oL3f/AIAxf/F0WDnkH/CQ Sf8AQXu//AGL/wCLosHPIli1maaOd11i6AhQO2bGLkbgvHzerCiwc8iL/hIJP+gvd/8AgDF/8XRY OeQf8JBJ/wBBe7/8AYv/AIuiwc8g/wCEgk/6C93/AOAMX/xdFg55B/wkEn/QXu//AABi/wDi6LBz yD/hIJP+gvd/+AMX/wAXRYOeQf8ACQSf9Be7/wDAGL/4uiwc8g/4SCT/AKC93/4Axf8AxdFg55B/ wkEn/QXu/wDwBi/+LosHPIP+Egk/6C93/wCAMX/xdFg55B/wkEn/AEF7v/wBi/8Ai6LBzyD/AISC T/oL3f8A4Axf/F0WDnkH/CQSf9Be7/8AAGL/AOLosHPIP+Egk/6C93/4Axf/ABdFg55B/wAJBJ/0 F7v/AMAYv/i6LBzyJbjWZreQI+sXRJRH4sYujKGH8XoaLBzyIv8AhIJP+gvd/wDgDF/8XRYOeQf8 JBJ/0F7v/wAAYv8A4uiwc8g/4SCT/oL3f/gDF/8AF0WDnkc7QQFABQAUAFABQA5FLuqKQCxwNxAH 4k8CgDbETQy2UblCw064yUcOP+W3cEigDDKMEDlTtJIDY4JHUfqPzpXV7AJTAKACgAoAKACgAoAK ACgCWJYTHOZXKuEBiA/ibcOD+G4/hQBFQAUAFABQAUAFABQAUAFABQAUAFABQAUAS3CwrIBA5ZNi Ek/3to3D8DkUARUAFABQAUAFABQAUAFABQAUAFABQAUASxLCY5zK5VwgMQH8Tbhwfw3H8KAIqACg AoAKACgAoAKACgAoAKACgAoAKACgCW4WFZAIHLJsQkn+9tG4fgcigCKgAoAKACgAoAKACgAoAKAC gAoAKAFRGkdURSzMcBQMkn0pNpK7AvxaRdmOcy2V2rhAYgIW+Ztw4PHpuP4Vl9Yo/wAy+9DszPrY QUAFABQAUAFABQAUAFABQAUAFABQAUAS3CwrIBA5ZNiEk/3to3D8DkUARUAFABQAUAFABQAUAFAB QAUAbtgImudMWdisJsZxIw6hczZP5VFRyUW4K7BFS8SzM5Wa4uU2ABUW2Xaq9Rj95yOc55znOTnN YU3U5bxS+9//ACP/AA2xTsQeXp3/AD9XX/gMv/xdac1b+Vfe/wDIWgeXp3/P1df+Ay//ABdHNW/l X3v/ACDQPL07/n6uv/AZf/i6Oat/Kvvf+QaB5enf8/V1/wCAy/8AxdHNW/lX3v8AyDQPL07/AJ+r r/wGX/4ujmrfyr73/kGgeXp3/P1df+Ay/wDxdHNW/lX3v/INA8vTv+fq6/8AAZf/AIujmrfyr73/ AJBoH2i1h/497XzGH/LSds89iFGAPodw/qck5fFK3p/n+qsGgf2pfjiO7liXskTeWo+irgCj2FLr G/rr+LC7J4NX1EQ3I+03UmYwN3mt+7+dfm/p/wACo+r0f5V9yC7IPtKXXyXYVXPS4C/MD/tAfeHq cbu+TjBORw1ht2/y7fl6bgQXEEltMYpQAwAPDBhgjIORweCK0hNTV0LYjqgCgAoAKACgAoAKACgA oAKACgAoAmu23TKfI8j92g24xnCD5vx6/jQBDQAUAFABQAUAFABQAUAFABQAUAFABQBNA2IbkeR5 mYwN2P8AV/Ovzf0/4FQBDQAUAFABQAUAFABQAUAFABQAUAFABQAUAWZkkubpEhtGVzGgEaLkthB8 2Md8bvxqZSUVeTsgHf2dOv8ArHgiA+9vnTcvrlc7sj0xn2rP20el38n+e36DsH2S3HLajAQOoRJC x+mVAz9SPrR7SfSD/D/MLB5enf8AP1df+Ay//F0c1b+Vfe/8g0Dy9O/5+rr/AMBl/wDi6Oat/Kvv f+QaB5enf8/V1/4DL/8AF0c1b+Vfe/8AINA8vTv+fq6/8Bl/+Lo5q38q+9/5BoHl6d/z9XX/AIDL /wDF0c1b+Vfe/wDINA8vTv8An6uv/AZf/i6Oat/Kvvf+QaB5enf8/V1/4DL/APF0c1b+Vfe/8g0D y9O/5+rr/wABl/8Ai6Oat/Kvvf8AkGgeXp3/AD9XX/gMv/xdHNW/lX3v/INA+02sXNvZZb1nk8za e2AAo/MEf1OSb+KX3K3+f4WC6EfUb10aP7TIkbDBjjOxMdxtGB+lNUaad7a993971C7I4GxDcjyP MzGBux/q/nX5v6f8CrURL/aVy/F032tP7s5LY+hzkfgRnHNY+wgvg930/qz+Y7kc8KhBPAS0JOOe qH+639D3/MCoyd+WW/5/1+H3NhBWggoAKACgAoAKACgAoAKACgAoAKAJrtt0ynyPI/doNuMZwg+b 8ev40AQ0AFABQAUAFABQAUAFABQA5FLuqKQCxwNxAH4k8CgDbETQy2UblCw064yUcOP+W3cEigDF aV3jSNjlUztyOme2fT29z6mpUUm2uoDKoAoAKACgAoAKACgAoAKALFssxguzE4VBEDKD/Eu9eB+O 0/hQBXoAtQOs8JtpmAYD9w7HAU5+6T2U8/Q4PAJrKScXzx+f9d/076DKzo0bsjqVZTgqRgg+laJp q6EJTAKACgAoAKACgAoAKACgAoAKALF6syzqJ3DP5UZBH93Yu0fgMCgCvQAUAFABQAUAFABQAUAF ABQAUAFABQBYtlmMF2YnCoIgZQf4l3rwPx2n8KAK9ABQAUAFABQAUAFABQAUAFABQAUATwWrSoZG kjhiBwZJDgZ9ABknqOgOMjNZyqKLsld/18vvHYk86zg/1ELTOOkk+Nv12DuPckH054nlqS+J2Xl/ n/wE/MNCTULu/JEFzdMyNHG3lo2EClQyjaMAYGO1ONKEXdLXv1+/cLsoVqIKACgAoAKACgAoAKAC gAoAKACgAoAsWyzGC7MThUEQMoP8S714H47T+FAFegCezmWGceaCYXBSVR1Knrj3HUZ7gVnUi5R0 36f1+fkNDLiFred4XIJU/eXow7EeoI5BqoSU4qSER1QBQAUAFABQAUAFABQAUAFABQBYvVmWdRO4 Z/KjII/u7F2j8BgUAV6ACgAoAKACgAoAKACgAoAKANmD/lx/7B1x/wC1qAMagAoAKACgAoAKACgA oAKACgCWJYTHOZXKuEBiA/ibcOD+G4/hQBFQAUAW7v8A0iGO8HLN8k3++O5/3hzk9SHrGn7jdP7v T/gfgrDfcqVsIKACgAoAKACgAoAKACgAoAKAJbhYVkAgcsmxCSf720bh+ByKAIqACgAoAKACgAoA KACgAoAKACgAoAKAJYlhMc5lcq4QGID+Jtw4P4bj+FAEVABQAUAFABQAUAFABQAUAFABQBb8qKz5 uFWabp5BLAJ/vkY59gevXGMHHmlU+HRd/wDL/N/Le49iCeeW4cPM5cgYGeij0A7D2FaRhGCtFCI6 oCW4WFZAIHLJsQkn+9tG4fgcigCKgAoAKACgAoAKACgAoAKACgAoAKACgCWJYTHOZXKuEBiA/ibc OD+G4/hQBFQAUAWz/pVgzHma2xk92jOAP++TgeuGHZax+Cduj/P/AIP6d2PoVK2EFABQAUAFABQA UAFABQAUAFAEtwsKyAQOWTYhJP8Ae2jcPwORQBFQAUAFABQAUAFABQAUAFADkUM6qXCAnBZs4Huc c0AbYRY5bJElSVRp1xh0BAP+u9QD+lAGFQAUAFABQAUAFABQAUAFABQBNA2IbkeR5mYwN2P9X86/ N/T/AIFQBDQAUAW9P/eyPaHkXC7VH+31THoc8Z9GPSsa3upT7fl1/DX1SGuxUrYQUAFABQAUAFAB QAUAFABQAUATXbbplPkeR+7QbcYzhB8349fxoAhoAKACgAoAKACgAoAKACgAoAKACgAoAmgbENyP I8zMYG7H+r+dfm/p/wACoAhoAKACgAoAKACgAoAKACgAoAt/8eH/AF9/+if/ALP/ANB/3vu4/wAX /D+f/A/P03exUrYQUAFAE1226ZT5Hkfu0G3GM4QfN+PX8aAIaACgAoAKACgAoAKACgAoAKACgAoA KAJoGxDcjyPMzGBux/q/nX5v6f8AAqAIaACgC1p7r57QyMFjnQxMWOACfuknsAwUn6fhWVVPl5lu tf8AP8LjRWdGjdkdSrKcFSMEH0rRNNXQhKYBQAUAFABQAUAFABQAUAFAE1226ZT5Hkfu0G3GM4Qf N+PX8aAIaACgAoAKACgAoAKACgAoAKANmD/lx/7B1x/7WoAxqACgAoAKACgAoAKACgAoAKALFssx guzE4VBEDKD/ABLvXgfjtP4UAV6ACgBUdo3V0YqynIYHBB9aTSaswLN+i+ak8ahEuE80KBgKckMA Ow3A49sVnSbs4vpp/l+G/mNlWtRBQAUAFABQAUAFABQAUAFAFi9WZZ1E7hn8qMgj+7sXaPwGBQBX oAKACgAoAKACgAoAKACgAoAKACgAoAsWyzGC7MThUEQMoP8AEu9eB+O0/hQBXoAKACgAoAKACgAo AKACgC6HbTkKoxS8JGWU4MQ7rnsx4zjpjHcgYWVV3fw/n/wO3ffomPYpVuIKACgAoAsXqzLOoncM /lRkEf3di7R+AwKAK9ABQAUAFABQAUAFABQAUAFABQAUAFAFi2WYwXZicKgiBlB/iXevA/HafwoA r0AFABQBb1H55IbjtPCrc9SR8rE+5ZWP41jR0Tj2b/zX4MbKlbCCgAoAKACgAoAKACgAoAKALF6s yzqJ3DP5UZBH93Yu0fgMCgCvQAUAFABQAUAFABQAUAFADkUM6qXCAnBZs4Hucc0AbYRY5bJElSVR p1xh0BAP+u9QD+lAGFQAUAFABQAUAFABQAUAFABQBLEsJjnMrlXCAxAfxNuHB/DcfwoAioAKACgC 2n77SpE/it5PMAH91sKxP4hPzP4Yv3aqffT7tV+o+hUrYQUAFABQAUAFABQAUAFABQBLcLCsgEDl k2IST/e2jcPwORQBFQAUAFABQAUAFABQAUAFABQAUAFABQBLEsJjnMrlXCAxAfxNuHB/DcfwoAio AKACgAoAKACgAoAKALVsixQSXUihtpCRKwyGfrkjuAP1K5BBrKbbkoL5+n/B/K/UaKzu0js7sWZj ksTkk+taJJKyEJTAKACgAoAluFhWQCByybEJJ/vbRuH4HIoAioAKACgAoAKACgAoAKACgAoAKACg AoAliWExzmVyrhAYgP4m3Dg/huP4UARUAFABQBb/ANdpXq9tJ9Tsb+QDD83/ADx+Gr6/mv8ANfkP oVK2EFABQAUAFABQAUAFABQAUAS3CwrIBA5ZNiEk/wB7aNw/A5FAEVABQAUAFABQAUAFABQAUAFA GzB/y4/9g64/9rUAY1ABQAUAFABQAUAFABQAUAFAE0DYhuR5HmZjA3Y/1fzr839P+BUAQ0AFABQB b0v5r0Qdp1aHB6ZYYXPsG2n8M1jX0hzdtfu3/AaKlbCCgAoAKACgAoAKACgAoAKAJrtt0ynyPI/d oNuMZwg+b8ev40AQ0AFABQAUAFABQAUAFABQAUAFABQAUATQNiG5HkeZmMDdj/V/Ovzf0/4FQBDQ AUAFABQAUAFABQBJbwtcTCNCBwWJPQADJP4AE1M5KCuwH3cyyuixgiKJAiA9cdSfxJJxzjOO1TTi 4pt7v+vy0GyCtBBQAUAFABQBNdtumU+R5H7tBtxjOEHzfj1/GgCGgAoAKACgAoAKACgAoAKACgAo AKACgCaBsQ3I8jzMxgbsf6v51+b+n/AqAIaACgAoAt6X81/HAfu3H7k+nzcA474OD9QKxr6Qcu2v 3f57DW5UrYQUAFABQAUAFABQAUAFABQBNdtumU+R5H7tBtxjOEHzfj1/GgCGgAoAKACgAoAKANO1 sLWfQr6982b7RbeX8m0BBubHXknj6Y96AKNtA1zcJChALnG5uijuT6ADkn0FAFzWbCCwe0Fs8jpP apMTIADls9h06dOfrQBWt7eKZC0l7BAQcbZA5J9/lUigDWjiRbiwiFxGyf2fOPNAbb/y255GePpQ BjrBGfOzdQr5f3ch/wB51+78v88daAEaJBbrKLiNnJwYgG3L7njH5HvQA9reIXCxC9gZCMmUB9q+ x+XP5DvQA1YIz52bqFfL+7kP+86/d+X+eOtACNEgt1lFxGzk4MQDbl9zxj8j3oAe1vELhYhewMhG TKA+1fY/Ln8h3oAasEZ87N1Cvl/dyH/edfu/L/PHWgBGiQW6yi4jZycGIBty+54x+R70APa3iFws QvYGQjJlAfavsflz+Q70ANWCM+dm6hXy/u5D/vOv3fl/njrQBPBA/wDZ9zLDdQ/6sebDht+3eo/u 467TwaAImt4hcLEL2BkIyZQH2r7H5c/kO9ADVgjPnZuoV8v7uQ/7zr935f5460AI0SC3WUXEbOTg xANuX3PGPyPegB7W8QuFiF7AyEZMoD7V9j8ufyHegC1qcEb6jdym6hXdiZQQ/wA+8bsL8vvjnH4d saGlNLtp92g3uUmiQW6yi4jZycGIBty+54x+R71sIe1vELhYhewMhGTKA+1fY/Ln8h3oAasEZ87N 1Cvl/dyH/edfu/L/ADx1oARokFusouI2cnBiAbcvueMfke9AD2t4hcLEL2BkIyZQH2r7H5c/kO9A DVgjPnZuoV8v7uQ/7zr935f5460AI0SC3WUXEbOTgxANuX3PGPyPegB7W8QuFiF7AyEZMoD7V9j8 ufyHegBqwRnzs3UK+X93If8Aedfu/L/PHWgCe/gdBHJPdQyStHH+7UNuVdg25+UD7uOhNAETW8Qu FiF7AyEZMoD7V9j8ufyHegBqwRnzs3UK+X93If8Aedfu/L/PHWgBGiQW6yi4jZycGIBty+54x+R7 0APa3iFwsQvYGQjJlAfavsflz+Q70ANWCM+dm6hXy/u5D/vOv3fl/njrQAjRILdZRcRs5ODEA25f c8Y/I96AHtbxC4WIXsDIRkygPtX2Py5/Id6AGrBGfOzdQr5f3ch/3nX7vy/zx1oARokFusouI2cn BiAbcvueMfke9AD2t4hcLEL2BkIyZQH2r7H5c/kO9ADVgjPnZuoV8v7uQ/7zr935f5460AI0SC3W UXEbOTgxANuX3PGPyPegB7W8QuFiF7AyEZMoD7V9j8ufyHegCW2gcw3/AJV1CqRx/PkN+8XeMbfl /vbeuOv1oArtEgt1lFxGzk4MQDbl9zxj8j3oAe1vELhYhewMhGTKA+1fY/Ln8h3oAasEZ87N1Cvl /dyH/edfu/L/ADx1oARokFusouI2cnBiAbcvueMfke9AD2t4hcLEL2BkIyZQH2r7H5c/kO9ADVgj PnZuoV8v7uQ/7zr935f5460AI0SC3WUXEbOTgxANuX3PGPyPegC89vFaQiD7bAXugC0mHwkY5AI2 5+YgHp2HZqx+Od+i/P8A4H690PZFJYIz52bqFfL+7kP+86/d+X+eOtbCEaJBbrKLiNnJwYgG3L7n jH5HvQA9reIXCxC9gZCMmUB9q+x+XP5DvQA1YIz52bqFfL+7kP8AvOv3fl/njrQAjRILdZRcRs5O DEA25fc8Y/I96AHtbxC4WIXsDIRkygPtX2Py5/Id6AJru3YTyC4vYC8cUZQ4f94uwbQuF9MDnFAF ZokFusouI2cnBiAbcvueMfke9AD2t4hcLEL2BkIyZQH2r7H5c/kO9ADVgjPnZuoV8v7uQ/7zr935 f5460AI0SC3WUXEbOTgxANuX3PGPyPegB7W8QuFiF7AyEZMoD7V9j8ufyHegBqwRnzs3UK+X93If 951+78v88daAEaJBbrKLiNnJwYgG3L7njH5HvQA9reIXCxC9gZCMmUB9q+x+XP5DvQA1YIz52bqF fL+7kP8AvOv3fl/njrQAjRILdZRcRs5ODEA25fc8Y/I96AHtbxC4WIXsDIRkygPtX2Py5/Id6AGr BGfOzdQr5f3ch/3nX7vy/wA8daAEaJBbrKLiNnJwYgG3L7njH5HvQBbgtTm5jh1C38ryQ0sm19u3 evH3c53beg/GgCqsEZ87N1Cvl/dyH/edfu/L/PHWgBGiQW6yi4jZycGIBty+54x+R70APa3iFwsQ vYGQjJlAfavsflz+Q70ANWCM+dm6hXy/u5D/ALzr935f5460AWtWiT7S9yLiMvcESmEBtybxu5OM HGccH8PTGhpTS7afdoN7ldreIXCxC9gZCMmUB9q+x+XP5DvWwhqwRnzs3UK+X93If951+78v88da AEaJBbrKLiNnJwYgG3L7njH5HvQA9reIXCxC9gZCMmUB9q+x+XP5DvQA1YIz52bqFfL+7kP+86/d +X+eOtACNEgt1lFxGzk4MQDbl9zxj8j3oAe1vELhYhewMhGTKA+1fY/Ln8h3oAasEZ87N1Cvl/dy H/edfu/L/PHWgBGiQW6yi4jZycGIBty+54x+R70AWby3YX0cVxewNmJD5oD7VXYNoPy5+7t7d+e9 AFdYIz52bqFfL+7kP+86/d+X+eOtACNEgt1lFxGzk4MQDbl9zxj8j3oAsfYrf/oK2n/fMv8A8RQB VhhlnlEUEbyyN0VFJJ/AUAPuLO6tNv2m2mg3Z2+YhXOPTNAENAF21v8A7Ppd9ZeVu+1eX8+7G3ac 9O+aACK/FvbxrawIku1lmdwJBKCwI+VgQMYFAD9W1RtT+y7oUi8iFYvlA+YjvwBge3QdutAGfQBs wf8ALj/2Drj/ANrUAY1ABQAUAFABQAUAFABQAUAFAEsSwmOcyuVcIDEB/E24cH8Nx/CgCKgAoAKA CgC3dfPp9lIOiq8Jz6hi35YcfrWMNKkl6P8AC36DexUrYQUAFABQAUAFABQAUAFAEtwsKyAQOWTY hJP97aNw/A5FAEVABQAUAFABQAUAFABQAUAFABQAUAFAEsSwmOcyuVcIDEB/E24cH8Nx/CgCKgAo AKACgAoAKAJ7OFZpwJSRCgLysOoUdce56DPcis6knGOm/T+vz8hoZcTNcTvK4ALH7q9FHYD0AHAF VCKhFRQiOqAKACgAoAKACgCW4WFZAIHLJsQkn+9tG4fgcigCKgAoAKACgAoAKACgAoAKACgAoAKA CgCWJYTHOZXKuEBiA/ibcOD+G4/hQBFQAUAFABQBbuv3llZz9wrQsT1JU5/LaygfTHYVjT0nKPz+ /wD4KY2VK2EFABQAUAFABQAUAFABQBLcLCsgEDlk2IST/e2jcPwORQBFQAUAFAGto09+8UtlZXMN mh/eTTswjOOAMv1AzgAD+8aAJ7+61GwgaCXVrfUYrlWVkE3nBcDg8/dOTkY7j2oAwqACgAoAKAHI oZ1UuEBOCzZwPc45oA1Lp/sgsPJkjm/0ORNyhsEM0oOMgHua1pQ9pLl9fyE3Yy2Rl6iqq4epSdpI E0xCrAZKkfhUyo1Iq8otL0C6Da2cbT+VCo1G2lF3XkF0GCM8HipdOavdbbjuBVgMlSPwqpUakVeU Wl6Cug2tnG0/lQqNRtpRd15BdBgjPB4qXTmr3W247gVYDJUj8KqVGpFXlFpegroNrZxtP5UKjUba UXdeQXQYIzweKl05q91tuO5LE4iinV4dxkQKrEfcO4HI/AEfjVSo1Iq8otL0FdEW1s42n8qFRqNt KLuvILoMEZ4PFS6c1e623HcQgg4IxSlFxdpKzAKkC3Z/vre4tehZfOU+6Ann22lvxx71jU92UZ/L 77frb5XGipWwgoAKACgAoAKACgAoAKAJrtt0ynyPI/doNuMZwg+b8ev40AQ0AFABQAUAFABQAUAF ABQAUAFABQAUATQNiG5HkeZmMDdj/V/Ovzf0/wCBUAQ0AFABQAUAFABQBb/49tO/6aXX6Rqf6sPq Nnoax+Op5R/P/gL8/IeyKlbCCgAoAKACgAoAUAnoKqMJS2VwJrrc8qkW5h/doNuOuEA3fj1/GrjR qSV4xbXoK6IcHjg81KpzdrLfYdw2tnG0/lVOjUTScXd+QroArEZCn8qI0akleMW16BdBg8cHmpVO btZb7DuG1s42n8qp0aiaTi7vyFdAFYjIU/lRGjUkrxi2vQLoMHjg81KpzdrLfYdw2tnG0/lVOjUT ScXd+QroArEZCn8qI0akleMW16BdBg8cHmpVObtZb7DuG1s42n8qp0aiaTi7vyFdAFYjIU/lRGjU krxi2vQLoMHjg81KpzdrLfYdyaDcsVwPs5k3Rgbsf6v51O7+n/Aqp0aiaTi7vyFdEIViMhT+VEaN SSvGLa9AugweODzUqnN2st9h3EIIOCMUpRcXaSswCpAt2/76wuIOrJiZO544YAfQ5Psn5Yz92cZd 9P8AL/Jeo+hUrYQUAFABQAUAFABQAUAFAE1226ZT5Hkfu0G3GM4QfN+PX8aAIaACgAoA6DwvbkSt dbdylXibdZPOo+7/AHe5BYfQe9AB4pjjj+y+XFDHnfny7F7bPTru+9/T8aAOfoAKACgAoAKANOSF potOVCAVs5H59FeVj+grahV9lUU+1/yE1dGc7bicZAPbNXXr+1k3G6T6XBKwhZiMFj+dZyrVJK0p Nr1CyDc2c7j+dCrVE21J3fmFkGTzyeal1Ju93vuOwFmIwWP51Uq1SStKTa9RWQbmzncfzoVaom2p O78wsgyeeTzUupN3u99x2AsxGCx/OqlWqSVpSbXqKyDc2c7j+dCrVE21J3fmFkGTzyeal1Ju93vu OxNAkskNyysu2OMM+4ZON6jj0OSPTjNVKtUkrSk2vUVkQ7mzncfzoVaom2pO78wsgyeeTzUupN3u 99x2FLsQATkCtZ4mpUSjN3S/r1FZINy7eV59c0KpS5LOGve/6bBZk1nKtveQXGdxikV9p4zg5xmh 4alWpuHtLNrqvLuF2nsNu7c2t5NBu3eVIybsYzg4zXLBuVONRqyY+tiGqAKACgAoAKACgAoAKALF 6syzqJ3DP5UZBH93Yu0fgMCgCvQAUAFABQAUAFABQAUAFABQAUAFABQBYtlmMF2YnCoIgZQf4l3r wPx2n8KAK9ABQAUAFABQBJbwNc3CQoQC5xk9FHcn2A5NTJ8qv/XoBLeOJpS0YKwIAkSnrtHTj1PU +5JreGEqU6PtJ9dfW/b/AIPQXMm7IgATncT7YHWtIRoa88nptZbg79ABUDkEn60qcqMVeUbv10B3 AsMYC4/WidWm01CFr/P7u3mCTF8z0VR9BVvFPpCK+QuUQSMM4PXmphi60L8r316D5UJub175/Go9 vU79b/MLIUuxIJPSqnias2nKWq+X5AkkT3v2hJ1E8m5vKjIK9NpRdo/AYFRGtUirRk0vULIr5Ixy eKlVJq1ntsOwbmzncfzqnWqNpuTuvMVkAZgMBiPxojWqRVoyaXqFkGSMcnipVSatZ7bDsG5s53H8 6p1qjabk7rzFZAGYDAYj8aI1qkVaMml6hZBkjHJ4qVUmrWe2w7BubOdx/Oqdao2m5O68xWQBmAwG I/GiNapFWjJpeoWQZIxyeKlVJq1ntsOwbmzncfzqnWqNpuTuvMVkAZgMBiPxojWqRVoyaXqFkGSM cnipVSatZ7bDsWLb7Q0F2YpMKsQMgPUrvXgfjtP4VTrVG03J3XmKyK4ZgMBiPxojWqRVoyaXqFkG SMcnipVSatZ7bDsLvPfnjHNa/Wajd5a6W11/pisgLK2Mrj1xVTrU6lrwt3t29BJNFixligvI5HY+ XnDqByUIww/EEionQo1YS5Z2fS/ltd+vr8xptEVzbvbXMsD4LRMVYr0yDislGTgp20aT+/a/YZFU gFABQAUAFABQAUAFAFi9WZZ1E7hn8qMgj+7sXaPwGBQBXoAKACgDY0i8t47VrWW/vbBy5ZZoXJTo PvIDntwR689KAJb+XTvIYzard6tNtYQhgyJGSMZO4k+h4/u80AYVABQAUAFADkUM6qXCAnBZs4Hu cc0AbYRY5bJElSVRp1xh0BAP+u9QD+lAGFQAUAFABQAUAFABQAUAFABQBLEsJjnMrlXCAxAfxNuH B/DcfwoAioAKACgAoAKALt8xJtZwceZbr8vptyn67M/jRhK86MnyvZv8fe/UJJMqhlJ+ZfyrrjVo yf7yG/b8LLYmz6BsBPysPxp/V4TlanNW210f9eemoXtuNKlTgjmsKlGpTlyyWo00xKyGFABQAUAF AEtwsKyAQOWTYhJP97aNw/A5FAEVABQAUAFABQAUAFABQAUAFABQAUAFAEsSwmOcyuVcIDEB/E24 cH8Nx/CgCKgAoAKAF2NnGDWyoVb25df6+8V0KQq453euK0lCjTS15n16dO/9edhastwOYrC4m4Uv iGPHB55Yg+wGD7P+eFfFTqyhT2S1svw/O/yGopalKpbbd2MKQBQAUAFABQAUAFAEtwsKyAQOWTYh JP8Ae2jcPwORQBFQAUAFABQAUAFABQAUAFABQAUAFABQBLEsJjnMrlXCAxAfxNuHB/DcfwoAioAK ACgAoAKALuoMxkinU4E8KsfUkfKxPuWVjn3pYWtUpRlCDtZv8dV+FkEkmVAU7r+Rrqpzo3tOOnk/ xE0+gBdx4IGfU0oUPaNKMkr935+m4N2EKsATjgcVMqFSKcmtFoF0JWIwoAKACgAoAluFhWQCByyb EJJ/vbRuH4HIoAioAKACgC1Y2ZvGmAfb5cZfAUsWOQqqAO5ZlH40AT6vpQ0wxhbqO4ySkmwH5JFA LL743Dn68DFAGdQAUAFABQAUAbMH/Lj/ANg64/8Aa1AGNQAUAFABQAUAFABQAUAFABQBNA2IbkeR 5mYwN2P9X86/N/T/AIFQBDQAUAFABQAUAWx+90gqOtvNuIHOQ4Az7AFAP+BD8cfhq+q/L/O/4D6F SthBQAU02tgHGRjjJziuieKq1Lc7ulrsLlSAFduCvPrmlGpSUOVw173/AECzuA8vvuqo/Vre9zfg LUMISfmIHbIqVGjKT95paW0u/wAB6gVUYw+fwpzp0Vblnf5P7wu+xPdbXmBMfkYjQbdvXCD5v+Bd fxohTou/NO3yf3hd9ivhf73f07VHJT/m6226d/8AgBqKVUYw+fwq506Ktyzv8n94XfYAq85fH4UQ p0Xfmnb5P7wu+wmF/vd/TtUclP8Am6226d/+AGopVRjD5/CrnToq3LO/yf3hd9gCrzl8fhRCnRd+ advk/vC77CYX+939O1RyU/5uttunf/gBqKVUYw+fwq506Ktyzv8AJ/eF32AKvOXx+FEKdF35p2+T +8LvsJhf73f07VHJT/m6226d/wDgBqKVUYw+fwq506Ktyzv8n94XfYAq85fH4UQp0Xfmnb5P7wu+ wmF/vd/TtUclP+brbbp3/wCAGpYh2rDcAR+bujA3bf8AVfOvzf0/4FVzp0Vblnf5P7wu+xAAnOWP tgU4QoK7nJ+Vlv5/8ATv0AFAOQSamEqMUnKLb+5DdxC3PAx/SpnVTk3BW2+VvP8Ar7wsBZj1JNKd apU+J3BJISshlu9/dQ21sP4IxI3oWfBz/wB87B9QfqcafvOU/l92n53GypWwgoAKACgAoAKACgAo Amu23TKfI8j92g24xnCD5vx6/jQBDQAUAFABQAUAFABQAUAFABQAUAFABQBNA2IbkeR5mYwN2P8A V/Ovzf0/4FQBDQAUAFABQAUAW1/e6Q694JgwA9HGGJ9gVQf8C9xWL92qvNflt+b+4fQqVsIKAFDF TkGtKdWdN3i7CauLvJOTgnGORWjxM5S5p2btbVBZAWBx8gB9qqdanO14JNb20uu1v1Ek11AbOc7h 9KUHh3dzTXpbb5j1E+U45x61mlTfKr279vkGopC54bt6VcqdJNpTurduvb/ghdk93taRT5fkHykG zbjOEHzfj1/Gn7OjyX59e1n9wXfYgAXPLY49KUadJtJzsrduvb/ghdgQueG7elEqdJNpTurduvb/ AIIXYoVMcvj8KuNKg0m6ln6MV32NXwz5iajJNFJdL5MRYraoHdwSFwAeO4PIPSuQoXX7N7KG3iL3 HlRSTRRpMuAAHyGX1BDDn1B7YwAY1ABQAUAFADkUM6qXCAnBZs4Hucc0AbYRY5bJElSVRp1xh0BA P+u9QD+lAGFQAUAFABQAUAFABQAUAFABQBYtlmMF2YnCoIgZQf4l3rwPx2n8KAK9ABQAUAFABQBb 0z57r7Melyphx7n7ufYMFP4d+lY1tI8/bX/P8LjRUrYQUAFABQAUAFABQAUAWL1ZlnUTuGfyoyCP 7uxdo/AYFAFegAoAKACgAoAKACgAoAKACgAoAKACgCxbLMYLsxOFQRAyg/xLvXgfjtP4UAV6ACgA oAKAJ7KFbi8jjkJEed0hHUIOWP4AE1nUk4QbW/T16fiNDLiZrm5lncANK5cgdMk5qoRUIqK6CI6o AoAKACgAoAKACgAoAsXqzLOoncM/lRkEf3di7R+AwKAK9ABQAUAFABQAUAFABQAUAFABQAUAFAFi 2WYwXZicKgiBlB/iXevA/HafwoAr0AFABQAUAFAFvTPnuvsx6XKmHHufu59gwU/h36VjW0jz9tf8 /wALjRUrYQUAFABQAUAFABQAUAWL1ZlnUTuGfyoyCP7uxdo/AYFAFegAoAKANjwwgfVGxAZ5FiYx os5hYtx90gjtnPPTJ5xggGxq9vBLEwvdOeC5Fu8nmSX5kaIL93gkghmIA75LccZoA4+gAoAKACgA oA2YP+XH/sHXH/tagDGoAKACgAoAKACgAoAKACgAoAliWExzmVyrhAYgP4m3Dg/huP4UARUAFABQ AUAFABQBb1P57r7SOlyomz7n72PYMGH4d+tY0dI8nbT/AC/Cw2VK2EFABQAUAFABQAUAS3CwrIBA 5ZNiEk/3to3D8DkUARUAFABQAUAFABQAUAFABQAUAFABQAUASxLCY5zK5VwgMQH8Tbhwfw3H8KAI qACgAoAKALdp+6tLq57hRChHYvnP4bQ4/EfUY1PelGHz+7/g2GipWwgoAKACgAoAKACgAoAKAJbh YVkAgcsmxCSf720bh+ByKAIqACgAoAKACgAoAKACgAoAKACgAoAKAJYlhMc5lcq4QGID+Jtw4P4b j+FAEVABQAUAFABQAUAW9T+e6+0jpcqJs+5+9j2DBh+HfrWNHSPJ20/y/Cw2VK2EFABQAUAFABQA UAS3CwrIBA5ZNiEk/wB7aNw/A5FAEVABQAUAaGjyQQzzyzJbu6Qs0S3IJRmBHBHc7d2M98UAXvE7 wsLXyGtRE5kkiS2TavlkgKx4++dpB9No6UAYNABQAUAFADkCl1EhKpn5ioyQPYcZoA2wIllshA7v H/Z1xhnUKT/ruwJ/nQBhUAFABQAUAFABQAUAFABQAUATQNiG5HkeZmMDdj/V/Ovzf0/4FQBDQAUA FABQAUAFAFs/vdIDHrbzBQTzkOCcewBQn/gR/HH4atu6/L/O/wCA+hUrYQUAFABQAUAFABQBNdtu mU+R5H7tBtxjOEHzfj1/GgCGgAoAKACgAoAKACgAoAKACgAoAKACgCaBsQ3I8jzMxgbsf6v51+b+ n/AqAIaACgAoAKALd3+6tLW27hTM4PYvjH4bQh/E/QY0/elKfy+7/g3GypWwgoAKACgAoAKACgAo AKAJrtt0ynyPI/doNuMZwg+b8ev40AQ0AFABQAUAFABQAUAFABQAUAFABQAUATQNiG5HkeZmMDdj /V/Ovzf0/wCBUAQ0AFABQAUAFABQBbb9/piEcvbMVb/cY5H4Bt2T/tL+GK92o+z/ADX/AALfcx9C pWwgoAKACgAoAKACgCa7bdMp8jyP3aDbjGcIPm/Hr+NAENABQAUAdH4dk2adcLnRvnbb/prYf+E/ ivHT157UAVfEJf8A0cGXSzGNxWPTz8qnjJb3PH5UAY1ABQAUAFABQBswf8uP/YOuP/a1AGNQAUAF ABQAUAFABQAUAFABQBYtlmMF2YnCoIgZQf4l3rwPx2n8KAK9ABQAUAFABQAUAW9O/eSS2o+9cx+W h/2twZR+JUD2zntWNbRKfbX9H917jRUrYQUAFABQAUAFABQBYvVmWdRO4Z/KjII/u7F2j8BgUAV6 ACgAoAKACgAoAKACgAoAKACgAoAKALFssxguzE4VBEDKD/Eu9eB+O0/hQBXoAKACgCexhW4voYZC RGzjew/hX+I+2Bk5rOrJwg5LcaGXEzXNzLO4AaVy5A6ZJzVQioRUV0ER1QBQAUAFABQAUAFABQAU AWL1ZlnUTuGfyoyCP7uxdo/AYFAFegAoAKACgAoAKACgAoAKACgAoAKACgCxbLMYLsxOFQRAyg/x LvXgfjtP4UAV6ACgAoAKACgAoAt6d88k1v2nhZeOpI+ZQPcsqj8axraJS7Nf5P8ABjRUrYQUAFAB QAUAFABQBYvVmWdRO4Z/KjII/u7F2j8BgUAV6ACgAoA3vDNtcq8l5EskaEGFLiOATGJ+CTs68rkZ x/FQBF4hvorz7OBffb5U3bp/s4i+U4wuO+CGP/AqAMagDWs7Wzm8O6jcGF/tNv5WJDJx8z44AA7e ufwoAqaZGJr1YvsZvHcFY4g5UFuxOOcDr1H1oAfrC2SXoSxIKqiiTYSU8z+LYTyV+vv2oAht0s2Q m5nnjfPAjhDjH1LCgDWjWAXFgqSSGD+z5/nMYDY/fZ+XOP1oAx1W1/fbpphj/VYiB3dfvfN8vbpm gBGWAW6sskhnz8yGMBQPZs5PbtQA9ksxcKqzzmDHzOYQGB9l3YPbvQA1Vtf326aYY/1WIgd3X73z fL26ZoARlgFurLJIZ8/MhjAUD2bOT27UAPZLMXCqs85gx8zmEBgfZd2D270ANVbX99ummGP9ViIH d1+983y9umaAEZYBbqyySGfPzIYwFA9mzk9u1AD2SzFwqrPOYMfM5hAYH2Xdg9u9ADVW1/fbpphj /VYiB3dfvfN8vbpmgCSNLI2UjPPMLkL8kflgITuH8WSfu5PQfX1AGslmLhVWecwY+ZzCAwPsu7B7 d6AGqtr++3TTDH+qxEDu6/e+b5e3TNACMsAt1ZZJDPn5kMYCgezZye3agB7JZi4VVnnMGPmcwgMD 7Luwe3egBqra/vt00wx/qsRA7uv3vm+Xt0zQAjLALdWWSQz5+ZDGAoHs2cnt2oAkH2WO7jMVzcCM c+YIgHVu2Bu+nORSaTVmBPfRWf2maZZJEimBlt1WEYIJPyn5htwQRxnpn0rOi3y8r3Wn9eq1Gyoy wC3VlkkM+fmQxgKB7NnJ7dq1EPZLMXCqs85gx8zmEBgfZd2D270ANVbX99ummGP9ViIHd1+983y9 umaAEZYBbqyySGfPzIYwFA9mzk9u1AD2SzFwqrPOYMfM5hAYH2Xdg9u9ADVW1/fbpphj/VYiB3df vfN8vbpmgCS6SyWOM208zyFV3q0YCg7fmw2cnnjp+J7gDWSzFwqrPOYMfM5hAYH2Xdg9u9ADVW1/ fbpphj/VYiB3dfvfN8vbpmgBGWAW6sskhnz8yGMBQPZs5PbtQA9ksxcKqzzmDHzOYQGB9l3YPbvQ A1Vtf326aYY/1WIgd3X73zfL26ZoARlgFurLJIZ8/MhjAUD2bOT27UAPZLMXCqs85gx8zmEBgfZd 2D270ANVbX99ummGP9ViIHd1+983y9umaAEZYBbqyySGfPzIYwFA9mzk9u1AD2SzFwqrPOYMfM5h AYH2Xdg9u9ADVW1/fbpphj/VYiB3dfvfN8vbpmgBGWAW6sskhnz8yGMBQPZs5PbtQA9ksxcKqzzm DHzOYQGB9l3YPbvQA6FLIpdebPMrKv8Ao+Ix85z/ABc8cf8A6+MEAiZYBbqyySGfPzIYwFA9mzk9 u1AD2SzFwqrPOYMfM5hAYH2Xdg9u9ADVW1/fbpphj/VYiB3dfvfN8vbpmgC1ZrBHZXFysknnpEU2 tGAmX+XG7OSdpY4wOh9OcaurjHu/y1/Ow0V2SzFwqrPOYMfM5hAYH2Xdg9u9bCGqtr++3TTDH+qx EDu6/e+b5e3TNACMsAt1ZZJDPn5kMYCgezZye3agB7JZi4VVnnMGPmcwgMD7Luwe3egBqra/vt00 wx/qsRA7uv3vm+Xt0zQAjLALdWWSQz5+ZDGAoHs2cnt2oAeyWYuFVZ5zBj5nMIDA+y7sHt3oAaq2 v77dNMMf6rEQO7r975vl7dM0AIywC3VlkkM+fmQxgKB7NnJ7dqAHslmLhVWecwY+ZzCAwPsu7B7d 6AHzR6eskgiuJygRTGfKHzNt+YNyNvPHGfx7gELLALdWWSQz5+ZDGAoHs2cnt2oAeyWYuFVZ5zBj 5nMIDA+y7sHt3oAaq2v77dNMMf6rEQO7r975vl7dM0AIywC3VlkkM+fmQxgKB7NnJ7dqAHslmLhV WecwY+ZzCAwPsu7B7d6AGqtr++3TTDH+qxEDu6/e+b5e3TNACMsAt1ZZJDPn5kMYCgezZye3agB7 JZi4VVnnMGPmcwgMD7Luwe3egBqra/vt00wx/qsRA7uv3vm+Xt0zQAjLALdWWSQz5+ZDGAoHs2cn t2oAeyWYuFVZ5zBj5nMIDA+y7sHt3oAaq2v77dNMMf6rEQO7r975vl7dM0AIywC3VlkkM+fmQxgK B7NnJ7dqALEcWmmSQPdXAjEeUbyAGL7hxt3EYxk9R/iAQKtr++3TTDH+qxEDu6/e+b5e3TNACMsA t1ZZJDPn5kMYCgezZye3agB7JZi4VVnnMGPmcwgMD7Luwe3egBqra/vt00wx/qsRA7uv3vm+Xt0z QAjLALdWWSQz5+ZDGAoHs2cnt2oAeyWYuFVZ5zBj5nMIDA+y7sHt3oAIvs6PI4uJ0ZDmFljGSR0J +b5e3TNJpNWYE+qR2yTF4mdZJdsvlCMBEVxuADZ5xkDoKzotuCv00+7Qb3IGSzFwqrPOYMfM5hAY H2Xdg9u9aiGqtr++3TTDH+qxEDu6/e+b5e3TNACMsAt1ZZJDPn5kMYCgezZye3agB7JZi4VVnnMG PmcwgMD7Luwe3egBqra/vt00wx/qsRA7uv3vm+Xt0zQAjLALdWWSQz5+ZDGAoHs2cnt2oAmnj09b tFhuJ2tyilnMQ3BscgDIzz7/AJ4yQCJVtf326aYY/wBViIHd1+983y9umaAEZYBbqyySGfPzIYwF A9mzk9u1AFjytL/5/Lv/AMBV/wDjlAFjSJLG1Rrm5v72GUkoIrQbXxwdxY8Y7Y+lAEWrap/aTxH7 OkflqF3k7pJOAMu3G48eg60AZ9AFqC+lt7C6s0VDHdbN5IORtORigCez1iSzhEUdpasPKeFyUIaR XIJ3EEE4xgelAFO4lSZw0dvHAAMbYyxB9/mJNAEVAGzB/wAuP/YOuP8A2tQBjUAFABQAUAFABQAU AFABQAUATQNiG5HkeZmMDdj/AFfzr839P+BUAQ0AFABQAUAFABQAUAW4/wB7pUydWgkWRR6KflY/ n5f+c1i/dqp99P1X6/1YfQqVsIKACgAoAKACgCa7bdMp8jyP3aDbjGcIPm/Hr+NAENABQAUAFABQ AUAFABQAUAFABQAUAFAE0DYhuR5HmZjA3Y/1fzr839P+BUAQ0AFABQBbl/c6ZBGOs7GZsdwCVX8Q Q/5j8MY+9Ub7afq/0H0KlbCCgAoAKACgAoAKACgAoAKAJrtt0ynyPI/doNuMZwg+b8ev40AQ0AFA BQAUAFABQAUAFABQAUAFABQAUATQNiG5HkeZmMDdj/V/Ovzf0/4FQBDQAUAFABQAUAFABQBbP7/T Af47VgvHdGJP4ANnn/bHtWPwVPKX5r/NfkPoVK2EFABQAUAFABQBNdtumU+R5H7tBtxjOEHzfj1/ GgCGgAoAKACgAoAKACgAoAKAHIFLqJCVTPzFRkgew4zQBtgRLLZCB3eP+zrjDOoUn/XdgT/OgDCo AKACgAoAKACgAoAKACgAoAsWyzGC7MThUEQMoP8AEu9eB+O0/hQBXoAKACgAoAKACgAoAns5lhnH mgmFwUlUdSp649x1Ge4FZ1IuUdN+n9fn5DQy4ha2uZYHILROUJHTIOKqElOKkuotiOqAKACgAoAK ALF6syzqJ3DP5UZBH93Yu0fgMCgCvQAUAFABQAUAFABQAUAFABQAUAFABQBYtlmMF2YnCoIgZQf4 l3rwPx2n8KAK9ABQAUAW9T+W9MHQW6rDgdMqMNj2Lbj+Oaxoaw5u+v37fgNlSthBQAUAFABQAUAF ABQAUAFAFi9WZZ1E7hn8qMgj+7sXaPwGBQBXoAKACgAoAKACgAoAKACgAoAKACgAoAsWyzGC7MTh UEQMoP8AEu9eB+O0/hQBXoAKACgAoAKACgAoAsWEqR3SiY4gk/dy8Z+U9Tj1HUe4FZVYtx93dar1 /rT0GiKaJ4JnhkXa8bFWGc4I4NXGSklJbMQyqAKACgAoAKALF6syzqJ3DP5UZBH93Yu0fgMCgCvQ AUAFABQAUAFABQAUAFABQBswf8uP/YOuP/a1AGNQAUAFABQAUAFABQAUAFABQBLEsJjnMrlXCAxA fxNuHB/DcfwoAioAKACgAoAKACgAoAKALdx/pFnFcj78eIZfwHyH/vkEcf3MnrWMPcm4d9V+v46/ PyGVK2EFABQAUAFAEtwsKyAQOWTYhJP97aNw/A5FAEVABQAUAFABQAUAFABQAUAFABQAUAFAEsSw mOcyuVcIDEB/E24cH8Nx/CgCKgAoAt6Z8l19pPS2UzZ9x93PsWKj8e3Wsa2seTvp/n+FxoqVsIKA CgAoAKACgAoAKACgAoAKAJbhYVkAgcsmxCSf720bh+ByKAIqACgAoAKACgAoAKACgAoAKACgAoAK AJYlhMc5lcq4QGID+Jtw4P4bj+FAEVABQAUAFABQAUAFABQBbuf39nBc/wAa/uZMf7IG0n0yvH/A CfWsYe7Nw+a+e/46/MZUrYQUAFABQAUAS3CwrIBA5ZNiEk/3to3D8DkUARUAFABQAUAFABQAUAFA BQA5ApdRISqZ+YqMkD2HGaANsCJZbIQO7x/2dcYZ1Ck/67sCf50AYVABQAUAFABQAUAFABQAUAFA E0DYhuR5HmZjA3Y/1fzr839P+BUAQ0AFABQAUAFABQAUAFAE9pMsLusgJilQo4HXHUH8CAccZxjv WdSLkk1uv6/LQaGXELW87wuQSp+8vRh2I9QRyDVQkpxUkIjqgCgAoAKAJrtt0ynyPI/doNuMZwg+ b8ev40AQ0AFABQAUAFABQAUAFABQAUAFABQAUATQNiG5HkeZmMDdj/V/Ovzf0/4FQBDQAUAW/wDU aV6PcyfQ7F/mCx/NPyx+Kr6fm/8AJfmPoVK2EFABQAUAFABQAUAFABQAUAFAE1226ZT5Hkfu0G3G M4QfN+PX8aAIaACgAoAKACgAoAKACgAoAKACgAoAKAJoGxDcjyPMzGBux/q/nX5v6f8AAqAIaACg AoAKACgAoAKACgC1YupdraVgsc427mOAjfwt7YPBPoWrKqmlzrdf01/XWw0VnRo3ZHUqynBUjBB9 K0TTV0ISmAUAFABQBNdtumU+R5H7tBtxjOEHzfj1/GgCGgAoAKACgAoAKACgAoAKACgDZg/5cf8A sHXH/tagDGoAKACgAoAKACgAoAKACgAoAsWyzGC7MThUEQMoP8S714H47T+FAFegAoAKACgAoAKA CgAoAKALb/6VZK45ltlxJ7pkBT7kE7fptx0NYr3J26P8+v8An63HuVK2EFABQAUAWL1ZlnUTuGfy oyCP7uxdo/AYFAFegAoAKACgAoAKACgAoAKACgAoAKACgCxbLMYLsxOFQRAyg/xLvXgfjtP4UAV6 ACgC3qP7uaO2/wCfaMRn1Dclh+DMw+gH1rGjqnPvr+i/Cw2VK2EFABQAUAFABQAUAFABQAUAFAFi 9WZZ1E7hn8qMgj+7sXaPwGBQBXoAKACgAoAKACgAoAKACgAoAKACgAoAsWyzGC7MThUEQMoP8S71 4H47T+FAFegAoAKACgAoAKACgAoAKALdx/pUP2teZV4nUfgA/wCPfrz3+YCsYe4+Tp0/y+XTy9GP cqVsIKACgAoAsXqzLOoncM/lRkEf3di7R+AwKAK9ABQAUAFABQAUAFABQAUAOQKXUSEqmfmKjJA9 hxmgDbAiWWyEDu8f9nXGGdQpP+u7An+dAGFQAUAFABQAUAFABQAUAFABQBLEsJjnMrlXCAxAfxNu HB/DcfwoAioAKACgAoAKACgAoAKACgCS3ma3nSVACVP3W6MO4PqCOCKmcVOLiwH3MKxiOWIkwygl c8lSDypPqP5EHAziphJu8Xuv6v8A11uhkFaCCgAoAluFhWQCByybEJJ/vbRuH4HIoAioAKACgAoA KACgAoAKACgAoAKACgAoAliWExzmVyrhAYgP4m3Dg/huP4UARUAW9M+S6+0npbKZs+4+7n2LFR+P brWNbWPJ30/z/C40VK2EFABQAUAFABQAUAFABQAUAFABQBLcLCsgEDlk2IST/e2jcPwORQBFQAUA FABQAUAFABQAUAFABQAUAFABQBLEsJjnMrlXCAxAfxNuHB/DcfwoAioAKACgAoAKACgAoAKACgCS 3ma3mEiAHgqQehBGCPxBIqZxU1ZgPvIVhnIiJMLgPEx6lT0z7jocdwamnJyjrv1/r8vIbIK0EFAB QBLcLCsgEDlk2IST/e2jcPwORQBFQAUAFABQAUAFABQAUAFABQBswf8ALj/2Drj/ANrUAY1ABQAU AFABQAUAFABQAUAFAE0DYhuR5HmZjA3Y/wBX86/N/T/gVAENABQAUAFABQAUAFABQAUAFAE0E/lb kdd8L/fTOM+hB7Edj/MEgxOHNqtGv6/r/MAuoPImKq2+M8xyYwHXsf8A63Y5HUUQnzK/Xr5AyGrA KAJrtt0ynyPI/doNuMZwg+b8ev40AQ0AFABQAUAFABQAUAFABQAUAFABQAUATQNiG5HkeZmMDdj/ AFfzr839P+BUAQ0AW5f9FsxB0mm2vJ7JgFRn3zkj/d7g1jH3583RbevX/JfPoPYqVsIKACgAoAKA CgAoAKACgAoAKACgCa7bdMp8jyP3aDbjGcIPm/Hr+NAENABQAUAFABQAUAFABQAUAFABQAUAFAE0 DYhuR5HmZjA3Y/1fzr839P8AgVAENABQAUAFABQAUAFABQAUAFAFi1lQ4t7g4gdvvYyYz/eH9R3A 9cEZTi/ijv8An5f5dvvu0RSxPDIY5Fww98/Qg9x71cZKSuhDKoAoAmu23TKfI8j92g24xnCD5vx6 /jQBDQAUAFABQAUAFABQAUAFADkCl1EhKpn5ioyQPYcZoA2wIllshA7vH/Z1xhnUKT/ruwJ/nQBh UAFABQAUAFABQAUAFABQAUAWLZZjBdmJwqCIGUH+Jd68D8dp/CgCvQAUAFABQAUAFABQAUAFABQA UATwTqqGKdDLCTu2htpU+qnBx78c/gCM5QbfNF2f9f1/TGE9uI0EsUgmhJxuAIKnsGHY4+o64Jwa Izu7NWf9bf1fugsQVoIsXqzLOoncM/lRkEf3di7R+AwKAK9ABQAUAFABQAUAFABQAUAFABQAUAFA Fi2WYwXZicKgiBlB/iXevA/HafwoALGJHmMky7oYV8yQZ6gcAevJIGe2c9qyqyaVo7vRf15bjRFL K80hkkOWPtjHoAOw9quMVFWQhlUAUAFABQAUAFABQAUAFABQAUAFAFi9WZZ1E7hn8qMgj+7sXaPw GBQBXoAKACgAoAKACgAoAKACgAoAKACgAoAsWyzGC7MThUEQMoP8S714H47T+FAFegAoAKACgAoA KACgAoAKACgAoAsRTxtGIbpWZF+46H5o8/XqO+OOehGTnKUGnzQ3/P8Arv8Ag9Bkc8LQOFYhlI3K 69GHqP8APHIPNXGSkhEdUBYvVmWdRO4Z/KjII/u7F2j8BgUAV6ACgAoAKACgAoAKACgAoAKANmD/ AJcf+wdcf+1qAMagAoAKACgAoAKACgAoAKACgCWJYTHOZXKuEBiA/ibcOD+G4/hQBFQAUAFABQAU AFABQAUAFABQAUAFAEkE8tu5eFyhIwcdGHoR3HsamUIzVpICf7Razf8AHxa+W3/PSBsc9yVOQfoN o/pnyTj8Mr+v+f6u49B8tgsrg6a/2mMqvy5Al3YG4bOp5z0yMd+DR7ZR+NW/L79vvs/ILdirPbzW zhLiGSJiMhXUqcevNaRnGavF3FsR1QBQAUAFABQAUAFABQAUAFABQAUAWrK0+1R3B5BjQFWJCpuL DhmPA43dSOR+FROpGG/9fILDbmVAot7c5hXBJx/rGxy30649B2yTmYRfxS3/ACX9b+flYZXrUQUA FABQAUAFABQAUAFABQAUAFABQBLcLCsgEDlk2IST/e2jcPwORQBFQAUAFABQAUAFABQAUAFABQAU AFABQBLEsJjnMrlXCAxAfxNuHB/DcfwoAioAKACgAoAKACgAoAKACgAoAKACgCeC7lhQxgh4ScmJ xlSfXHY44yMH3rOVOMnfr3/r8th3JPLtbn/VP9mlP/LOQ5Qn2bt9G4Hdqm84b6r8fu/y+SDQW/sZ LUq6xS+QVTEjKdpYqCwB6EZzjHUDv1qo1YTdovULFOtBBQAUAFABQAUAFAF7RPLOsWqTQRzpJKiF ZM4GWHPBGfxyPagBmrIsesXqRqFRZ3CqowANx4FADLd7NUIuYJ5HzwY5ggx9CpoA1o2gNxYMkcgg /s+f5DIC2P32fmxj9KAMdWtR526GY5/1WJQNvX73y/N26YoARmg+zqqxyCcH5nMgKkey4yO3egB7 PZ/aFZYJxAB8yGYFifZtuB27UANVrUeduhmOf9ViUDb1+98vzdumKAEZoPs6qscgnB+ZzICpHsuM jt3oAez2f2hWWCcQAfMhmBYn2bbgdu1ADVa1HnboZjn/AFWJQNvX73y/N26YoARmg+zqqxyCcH5n MgKkey4yO3egB7PZ/aFZYJxAB8yGYFifZtuB27UANVrUeduhmOf9ViUDb1+98vzdumKAJYpIBYzo tpI85QBpS4KoN45C7cjsuc9/egBjPZ/aFZYJxAB8yGYFifZtuB27UANVrUeduhmOf9ViUDb1+98v zdumKAEZoPs6qscgnB+ZzICpHsuMjt3oAez2f2hWWCcQAfMhmBYn2bbgdu1ADVa1HnboZjn/AFWJ QNvX73y/N26YoARmg+zqqxyCcH5nMgKkey4yO3egB7PZ/aFZYJxAB8yGYFifZtuB27UANVrUeduh mOf9ViUDb1+98vzdumKAEZoPs6qscgnB+ZzICpHsuMjt3oAez2f2hWWCcQAfMhmBYn2bbgdu1ADV a1HnboZjn/VYlA29fvfL83bpigBGaD7OqrHIJwfmcyAqR7LjI7d6AHs9n9oVlgnEAHzIZgWJ9m24 HbtQA1WtR526GY5/1WJQNvX73y/N26YoAlvJIHSMLaSQThEDEuNrDaOQu0EZ4Ocnr70ASRagLeVR atew23V41usEt65CgDt2PSs5UoTd5RT+Q7tD11OE+cJ7KOVG/wBWoWNNvXG4qgJ7dCvT3qfYpbNr 5t/ndBca19YfZ1VdIhE4PzOZpCpHsucjt3o9nL+d/h/kFx7X+mfaFZdFQQAfMhuHLE+zdB27Uezl /O/w/wAguQvc2EjsTp5iTPyCGcg4/wBosGz+GO/4HJUW0vvX+Vg0G+fYpzFZM59J5iy/+OhTn8fw o5Kj3l9y/wA7hoWGv9M+0Ky6KggA+ZDcOWJ9m6Dt2o9nL+d/h/kFxFvtOHnbtHjOf9VieQbev3uf m7dMUezl/O/w/wAguNa+sPs6qukQicH5nM0hUj2XOR270ezl/O/w/wAguPa/0z7QrLoqCAD5kNw5 Yn2boO3aj2cv53+H+QXEW+04edu0eM5/1WJ5Bt6/e5+bt0xR7OX87/D/ACC41tTUW6pFawpKDyTF Gy49ACm705LGj2Merf3v/MLj21WL7QrLaIIAPmQxwlifZvLwO3aj2Ee7+9/5hcb9tE8d2JbeSVNm IgrKFtwWHOAuOSFBI25yfWrhTjDb+vmK5TZoPs6qscgnB+ZzICpHsuMjt3qwHs9n9oVlgnEAHzIZ gWJ9m24HbtQA1WtR526GY5/1WJQNvX73y/N26YoARmg+zqqxyCcH5nMgKkey4yO3egB7PZ/aFZYJ xAB8yGYFifZtuB27UANVrUeduhmOf9ViUDb1+98vzdumKAEZoPs6qscgnB+ZzICpHsuMjt3oAez2 f2hWWCcQAfMhmBYn2bbgdu1ADVa1HnboZjn/AFWJQNvX73y/N26YoARmg+zqqxyCcH5nMgKkey4y O3egB7PZ/aFZYJxAB8yGYFifZtuB27UANVrUeduhmOf9ViUDb1+98vzdumKAEZoPs6qscgnB+ZzI CpHsuMjt3oAez2f2hWWCcQAfMhmBYn2bbgdu1AEtzJatNIWspocxoIlEgG35B8zfL82eDxjr70AV 2aD7OqrHIJwfmcyAqR7LjI7d6AHs9n9oVlgnEAHzIZgWJ9m24HbtQA1WtR526GY5/wBViUDb1+98 vzdumKAEZoPs6qscgnB+ZzICpHsuMjt3oAez2f2hWWCcQAfMhmBYn2bbgdu1ADVa1HnboZjn/VYl A29fvfL83bpigBGaD7OqrHIJwfmcyAqR7LjI7d6AHs9n9oVlgnEAHzIZgWJ9m24HbtQA1WtR526G Y5/1WJQNvX73y/N26YoARmg+zqqxyCcH5nMgKkey4yO3egB7PZ/aFZYJxAB8yGYFifZtuB27UANV rUeduhmOf9ViUDb1+98vzdumKAEZoPs6qscgnB+ZzICpHsuMjt3oAsxS2YecrYzvAYgGBlBZDuHz BtmB2HTv15oArq1qPO3QzHP+qxKBt6/e+X5u3TFACM0H2dVWOQTg/M5kBUj2XGR270APZ7P7QrLB OIAPmQzAsT7NtwO3agBqtajzt0Mxz/qsSgbev3vl+bt0xQAjNB9nVVjkE4PzOZAVI9lxkdu9AD2e z+0KywTiAD5kMwLE+zbcDt2oAarWo87dDMc/6rEoG3r975fm7dMUAIzQfZ1VY5BOD8zmQFSPZcZH bvQA9ns/tCssE4gA+ZDMCxPs23A7dqAGq1qPO3QzHP8AqsSgbev3vl+bt0xQAjNB9nVVjkE4PzOZ AVI9lxkdu9AD2ez+0KywTiAD5kMwLE+zbcDt2oAarWo87dDMc/6rEoG3r975fm7dMUAIzQfZ1VY5 BOD8zmQFSPZcZHbvQBce8SDUElggubRPKVWSObY7DaMHcF7/ACnoc9e9TKEZq0lcNhV1OJvOFzaL cBvubtit35dgoZj05BGefWs/YxXwtr5/o9PwHca15pz26odKCS5+eSOdhkewOcduue/4Hs5raf3p fol+YXRF5mnf8+t1/wCBK/8AxFHLW/mX3P8AzDQqVsIKACgAoAfDK9vPHNE22SNgynGcEHIoAJpX nnkmlbdJIxZjjGSTk0AMoA27VGkfT0jUs7afcBVUZJP77gUAUf7H1T/oG3f/AH4b/CgA/sfVP+gb d/8Afhv8KAD+x9U/6Bt3/wB+G/woAP7H1T/oG3f/AH4b/CgA/sfVP+gbd/8Afhv8KAD+x9U/6Bt3 /wB+G/woAP7H1T/oG3f/AH4b/CgA/sfVP+gbd/8Afhv8KAD+x9U/6Bt3/wB+G/woAP7H1T/oG3f/ AH4b/CgCaDSdXENyEsrhFMYDq0LZcb14HHXOD9AaAIf7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv 8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9+G/w oAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34b/Cg A/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv8KAJ rvSdXMymSyuJW8tAGSFsAbBgdOoGAfcGgCH+x9U/6Bt3/wB+G/woAP7H1T/oG3f/AH4b/CgA/sfV P+gbd/8Afhv8KAD+x9U/6Bt3/wB+G/woAP7H1T/oG3f/AH4b/CgA/sfVP+gbd/8Afhv8KAD+x9U/ 6Bt3/wB+G/woAP7H1T/oG3f/AH4b/CgA/sfVP+gbd/8Afhv8KAD+x9U/6Bt3/wB+G/woAP7H1T/o G3f/AH4b/CgA/sfVP+gbd/8Afhv8KAD+x9U/6Bt3/wB+G/woAmg0nVxDchLK4RTGA6tC2XG9eBx1 zg/QGgCH+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9 +G/woAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34 b/CgA/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv 8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34b/CgCa70nVzMpksriVvLQBkhbAGwYHTqBgH3BoAh /sfVP+gbd/8Afhv8KAD+x9U/6Bt3/wB+G/woAP7H1T/oG3f/AH4b/CgA/sfVP+gbd/8Afhv8KAD+ x9U/6Bt3/wB+G/woAP7H1T/oG3f/AH4b/CgA/sfVP+gbd/8Afhv8KAD+x9U/6Bt3/wB+G/woAP7H 1T/oG3f/AH4b/CgA/sfVP+gbd/8Afhv8KAD+x9U/6Bt3/wB+G/woAP7H1T/oG3f/AH4b/CgA/sfV P+gbd/8Afhv8KAJoNJ1cQ3ISyuEUxgOrQtlxvXgcdc4P0BoAh/sfVP8AoG3f/fhv8KAD+x9U/wCg bd/9+G/woAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt 3/34b/CgA/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f /fhv8KAD+x9U/wCgbd/9+G/woAP7H1T/AKBt3/34b/CgA/sfVP8AoG3f/fhv8KAD+x9U/wCgbd/9 +G/woAmu9J1czKZLK4lby0AZIWwBsGB06gYB9waAIf7H1T/oG3f/AH4b/CgA/sfVP+gbd/8Afhv8 KAD+x9U/6Bt3/wB+G/woApUAFABQAUAFABQAUAWtOginu9k4cxrHI5CMATtQtjJBx09KALKJpbWM tz9mux5ciJt+0rzuDHOfL/2f1oAh83S/+fO7/wDApf8A43QBNeppdpfT232a7fyZGTd9pUZwcZx5 dAA6aWtjFc/Zrv8AeSOm37SvG0Kc58v/AGv0oALJNLu763tvs12nnSKm77Spxk4zjy6AIfN0v/nz u/8AwKX/AON0ATOmlrYxXP2a7/eSOm37SvG0Kc58v/a/SgAtE0u5maP7NdriN3z9pU/dQtj/AFff GKAIfN0v/nzu/wDwKX/43QBNOmlww20n2a7Pnxl8faV+X52XH+r/ANnP40AECaXNDcyfZrtfIjD4 +0r83zquP9X/ALWfwoAh83S/+fO7/wDApf8A43QBNdppdtMsf2a7bMaPn7So+8gbH+r7ZxQAQJpc 0NzJ9mu18iMPj7SvzfOq4/1f+1n8KAIfN0v/AJ87v/wKX/43QBNeppdpfT232a7fyZGTd9pUZwcZ x5dAAiaW1jLc/ZrseXIibftK87gxzny/9n9aACyTS7u+t7b7Ndp50ipu+0qcZOM48ugCHzdL/wCf O7/8Cl/+N0ATOmlrYxXP2a7/AHkjpt+0rxtCnOfL/wBr9KACyTS7u+t7b7Ndp50ipu+0qcZOM48u gCHzdL/587v/AMCl/wDjdAE06aXDDbSfZrs+fGXx9pX5fnZcf6v/AGc/jQAWiaXczNH9mu1xG75+ 0qfuoWx/q++MUAQ+bpf/AD53f/gUv/xugCa7TS7aZY/s122Y0fP2lR95A2P9X2zigAgTS5obmT7N dr5EYfH2lfm+dVx/q/8Aaz+FAEPm6X/z53f/AIFL/wDG6AJrtNLtplj+zXbZjR8/aVH3kDY/1fbO KABE0trGW5+zXY8uRE2/aV53BjnPl/7P60AQ+bpf/Pnd/wDgUv8A8boAmvU0u0vp7b7Ndv5MjJu+ 0qM4OM48ugAdNLWxiufs13+8kdNv2leNoU5z5f8AtfpQAWSaXd31vbfZrtPOkVN32lTjJxnHl0AQ +bpf/Pnd/wDgUv8A8boAmdNLWxiufs13+8kdNv2leNoU5z5f+1+lABaJpdzM0f2a7XEbvn7Sp+6h bH+r74xQBD5ul/8APnd/+BS//G6AJp00uGG2k+zXZ8+Mvj7Svy/Oy4/1f+zn8aACBNLmhuZPs12v kRh8faV+b51XH+r/ANrP4UAQ+bpf/Pnd/wDgUv8A8boAmu00u2mWP7NdtmNHz9pUfeQNj/V9s4oA IE0uaG5k+zXa+RGHx9pX5vnVcf6v/az+FAEPm6X/AM+d3/4FL/8AG6AJr1NLtL6e2+zXb+TIybvt KjODjOPLoAETS2sZbn7Ndjy5ETb9pXncGOc+X/s/rQAWSaXd31vbfZrtPOkVN32lTjJxnHl0AQ+b pf8Az53f/gUv/wAboAmdNLWxiufs13+8kdNv2leNoU5z5f8AtfpQAWiaXczNH9mu1xG75+0qfuoW x/q++MUAQ+bpf/Pnd/8AgUv/AMboAmnTS4YbaT7Ndnz4y+PtK/L87Lj/AFf+zn8aAC0TS7mZo/s1 2uI3fP2lT91C2P8AV98YoAh83S/+fO7/APApf/jdAE12ml20yx/Zrtsxo+ftKj7yBsf6vtnFABAm lzQ3Mn2a7XyIw+PtK/N86rj/AFf+1n8KAIfN0v8A587v/wACl/8AjdAE16ml2l9PbfZrt/JkZN32 lRnBxnHl0ACJpbWMtz9mux5ciJt+0rzuDHOfL/2f1oAh83S/+fO7/wDApf8A43QBNeppdpfT232a 7fyZGTd9pUZwcZx5dAA6aWtjFc/Zrv8AeSOm37SvG0Kc58v/AGv0oALJNLu763tvs12nnSKm77Sp xk4zjy6AIfN0v/nzu/8AwKX/AON0ATTppcMNtJ9muz58ZfH2lfl+dlx/q/8AZz+NABaJpdzM0f2a 7XEbvn7Sp+6hbH+r74xQBD5ul/8APnd/+BS//G6AJp00uGG2k+zXZ8+Mvj7Svy/Oy4/1f+zn8aAC BNLmhuZPs12vkRh8faV+b51XH+r/ANrP4UAQ+bpf/Pnd/wDgUv8A8boAmu00u2mWP7NdtmNHz9pU feQNj/V9s4oAETS2sZbn7Ndjy5ETb9pXncGOc+X/ALP60AQ+bpf/AD53f/gUv/xugCa9TS7S+ntv s12/kyMm77Sozg4zjy6ABE0trGW5+zXY8uRE2/aV53BjnPl/7P60AFkml3d9b232a7TzpFTd9pU4 ycZx5dAEPm6X/wA+d3/4FL/8boAmdNLWxiufs13+8kdNv2leNoU5z5f+1+lABaJpdzM0f2a7XEbv n7Sp+6hbH+r74xQBD5ul/wDPnd/+BS//ABugCadNLhhtpPs12fPjL4+0r8vzsuP9X/s5/GgAtE0u 5maP7NdriN3z9pU/dQtj/V98YoAh83S/+fO7/wDApf8A43QBNdppdtMsf2a7bMaPn7So+8gbH+r7 ZxQAQJpc0NzJ9mu18iMPj7SvzfOq4/1f+1n8KAIfN0v/AJ87v/wKX/43QBNeppdpfT232a7fyZGT d9pUZwcZx5dAGZQAUAFABQAUAFABQBLbztbyF0AJKOnPoylT+hoAioAKACgAoAKACgAoAKACgCxL YXkDxpNaTxvIcIrxkFj6D16igCWO3v7eSSz+xzCW5j2+W0TbyoYNkD6p/OgCrNDLbymKeN4pF6q6 kEfgaAGUAFABQAUAFABQAUAFABQAUAFAE1vZ3V3u+zW0023G7y0LYz64oAI7O6mgeeK2meJM7nVC VXAycntxQBLcRXlxCL17WQQBETzRGdmFAQc9O350AVKACgAoAKACgAoAKACgAoAKACgAoAKALGZ7 I3FvLEY3kQI6yKQwG5WHH4CgCvQAUAFABQAUAFABQAUAFABQAUAFADkRpHVI1LOxwqqMkn0FAA6N G7JIpV1OGVhgg+hoAs3kV46R3VxayRxsiIjmMhWAUAYJ65AzQBUoAKACgAoAKACgAoAKACgAoAKA CgB/ky+R5/lv5W7Zv2nbuxnGfXFADop2hjnRQCJkCNnsNwbj8VFADZoZbeUxTxvFIvVXUgj8DQAy gAoAKACgAoAKACgAoAKACgAoAciNI6pGpZ2OFVRkk+goAHRo3ZJFKupwysMEH0NAFm8ivHSO6uLW SONkREcxkKwCgDBPXIGaAKlABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAFvSXWPWLJ5 GCos6FmY4AG4cmgDsLa3W21+K4eWe2EmoTL5E0nyyEocSKMDucd+o5oAgskaLRbeykUpdNp92BAw w5JcEDb15wcfQ0AOuIA+lyAW0M15bWFoipKoLRvluMHv0+XvwMHOCAc54jit4Nfu4rRUWJWGFQ8A 4GR7c547UAZlABQAUAFABQAUAFABQAUAFAHU+HAX0qAJF9pZdTjZo8E+UNv+s+XB/PI46UAadsQ9 9pdwkvnQW816ZpwQVXJJBYjgZBB7daAK3/Lr9q/5d/7B8rzf4N+cbc9M54xQAzxBZWsMGrn7Jbwr G0H2Zo1CksR8w474/h9MHHOSAcfQAUAFABQAUAFABQAUAFABQAUAPhmlt5RLBI8Ui9GRiCPxFAHX XkcL+K9caeCOYR2JdVkGRkIn4j6jmgDE8QwxRy2EkcaRtPZRSyBFCgsc5OBwOnagDJoAKACgAoAK ACgAoAKACgAoAKANDQZpYdcs/KkePfMiNtYjcpYZB9RQA/ULSe71zVPITf5Mksr8gYUMcnmgDbe2 vLK8gsZYJ7lZ54DfXcqF0k+YbUBPG0Zxk8k8cDigCprcFudKuZo7aGJ4dTeBDGu35NucH15GeenQ YHFAHOUAFABQAUAFABQAUAFABQAUAFAG7JNLN4HTzZHfZfhF3MTtUR8AegoAr2tr9hImupo7ad4l ktvM3EEMCN+UBIIxwOOcHtggHVatDbrfCVoLeaSbU4YmZ49xVTGuV5HPH1HPr0AOK1OJLfVbuGJd scczqoznADECgCrQAUAFABQAUAFABQAUAFABQBoaDNLDrln5Ujx75kRtrEblLDIPqKAH6haT3eua p5Cb/JkllfkDChjk80AdNf2kVxrE1zvmSKS4tRhnBhvFOOAMDOBz1PegDJ1uC3OlXM0dtDE8OpvA hjXb8m3OD68jPPToMDigDnKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAtQX0t vYXVmioY7rZvJByNpyMUAVaACgAoAKACgAoAKACgAoAKACgAoAKACgC1qN9LqV/JeTqiySYyEBA4 AHf6UAVaACgAoAKACgAoAKACgAoAlt4kmcrJcRwADO6QMQfb5QTQBoXWhy2k08D3UDzwJveONZWI GM9dmO45zjmgCoNNvztxZXB3MUX903LDOQOOowfyNADYrC8neRIbSeR4jh1SMkofQ+nQ0AV6ANZ/ D12jTo0kIe38oSoNzFTIcAcDkjvjPtmgCnJp93Gzj7PMypvO8RsAQpwx5HQHrnp3oAGsZV0xL8Mj QtIYjgnKMBnBz6jnjNABYWMt/LIkbIixRtLI7k4VR1PGT+QoAnt9I+0WUt2t/aiOEKZdwkym7gA/ Lzz6ZoAkg0G5uHslimgYXhkETZYD5OpPGRnHH9KAK9ppd1d/a9qbPskbSS7wRjH8PTr14PoaAH3O lG0giknvLdGmhEyR/OWKkcdFxn8aAIbmxltrW1uWZHiuVLIyk9QcEEHuD+HoTQBVoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoA6a41axfXdZuVnzFc2TRRNsb5mKqMYxxyD1oANU1axuP7d8mfd 9q+z+T8jDdtxu7cY96ALt1rmm3FzNsnhGL2O4SSaOQrgRquQFwSQR0OBQBzkN4h8Rx30rYjN2JWb bjA35Jxk/lk/jQBuJdwaXq2sRXr+U8l7DKgwWyol3k8Z/hINAEq69YLqOnP9rIginupJflbA3Fth xjnhvwzQBj2H7nwpqsknCzyRRRn+8yncR7cc0AGkfvdC1q2TmVo45Qv+yjZY59gRQBDYXcEOharb SPiWfyvLXB+ba2Tz24oA09K1axt/7C82fb9k+0ed8jHbuzt7c59qAHQ69aG1ulfEUl3ZyGchPvz4 CgcKMcAt6Zc0AV9SvoLmxtFgvLQeVZJE6SW5aTcAcgMUOPbkUAQS/ufBkEcnDT3rSxj+8qrtJ9ue KAMagAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgDtf+EP0/wD57XP/AH0v/wATSub+zQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDP a5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+ l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4 mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh 7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8 Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n /wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5 /wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/7 6X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8A iaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4e zQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/ wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp/ /Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDP a5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+ l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4 mi4ezQf8Ifp//Pa5/wC+l/8AiaLh7NB/wh+n/wDPa5/76X/4mi4ezRJJ4Vs5tnm3d4+xQi7pAdqj oBxwKLh7NEf/AAh+n/8APa5/76X/AOJouHs0SN4Vs3iSJ7u8aOPOxTICFz1wMcUXD2aCHwrZ28ol gu7yKRejJIAR+IFFw9miP/hD9P8A+e1z/wB9L/8AE0XD2aD/AIQ/T/8Antc/99L/APE0XD2aD/hD 9P8A+e1z/wB9L/8AE0XD2aD/AIQ/T/8Antc/99L/APE0XD2aJJPCtnNs827vH2KEXdIDtUdAOOBR cPZoj/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2 aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q /T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/ AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/ AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30 v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE 0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9m g/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/h D9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+ e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1 z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L /wDE0XD2aD/hD9P/AOe1z/30v/xNFw9mg/4Q/T/+e1z/AN9L/wDE0XD2aP/Z ------_=_NextPart_000_01C0C69D.2AF81380-- From owner-ibis Mon Apr 16 12:23:19 2001 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3GJNF508000 for ; Mon, 16 Apr 2001 12:23:18 -0700 (PDT) Received: from SMTP (orsmsx226.jf.intel.com [192.168.65.226]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id TAA28847; Mon, 16 Apr 2001 19:22:34 GMT Received: from orsmsx228.JF.INTEL.COM ([192.168.70.228]) by 192.168.70.226 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 16 Apr 2001 19:22:34 0000 (GMT) Received: by ORSMSX228 with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Apr 2001 12:22:33 -0700 Message-ID: <7FD5C79AD680D211AC4100A0C96B501C084A7649@orsmsx49.jf.intel.com> From: "Peters, Stephen" To: "'Gregory R Edlund'" , ibis@vhdl.org Subject: RE: BIRD 70.1 Date: Mon, 16 Apr 2001 12:22:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi Greg: A question and comment. 1. The [Test Data] keyword includes a Driver_model subparameter to specify a driver model. Should there also be a Receiver_model subparameter to specify the receiver? 2. The [Rising Golden Waveform]/[Falling Golden Waveform] keywords are "Required: Yes (within the scope of [Test Data]". I think I understand what you are trying to say -- if [Test Data] is present then the golden waveforms must also be present -- but both [Test Data] and the golden waveform keywords belong in the global scope. I'd make the requirement read "Required: Yes, if [Test Data] is present." Regards, Stephen -----Original Message----- From: Gregory R Edlund [mailto:gedlund@us.ibm.com] Sent: Monday, April 16, 2001 8:48 AM To: ibis@vhdl.org Subject: BIRD 70.1 Here is BIRD 70.1 for discussion at Friday's Open Forum conference call. After discussion with Bob Ross and Al Davis, I made some significant changes that should make it upwardly compatible. Please note that this BIRD sets up the infrastructure for a future BIRD to facilitate non-RC standard loads. In fact, that BIRD becomes almost trivial. I have two questions for readers: 1) Semiconductor vendors: If your customers require you to supply Golden Waveforms and IF a production-quality SPICE-to-IBIS modeling tool were available to support them, would this BIRD enable you to do so? 2) EDA vendors: If your customers asked you to support automated analysis of Golden Waveforms and produce a correlation figure of merit table, would this BIRD enable you to do so? Thanks for your consideration everyone! Greg Greg Edlund Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com **************************************************************************** *** **************************************************************************** *** BIRD ID#: 70.1 ISSUE TITLE: Golden Waveforms REQUESTOR: Greg Edlund, IBM DATE SUBMITTED: April 16, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending **************************************************************************** *** **************************************************************************** *** STATEMENT OF THE ISSUE: Golden Waveforms are a set of SPICE waveforms simulated using known ideal test loads. They are useful in verifying the accuracy of behavioral simulation results for any given simulator. They are not the same thing as the traditional VT tables recommended in the "IBIS Cookbook." The "I/O Buffer Accuracy Handbook" recommends a set of ideal test loads for classical push-pull and open-drain drivers. There is currently a problem with including Golden Waveforms in an IBIS datasheet: the simulator tries to use these waveforms to construct its stimulus waveform, and erroneous simulations result. This BIRD proposes a new syntactical construct to tell the simulator that a waveform is a Golden Waveform. The simulator may then choose to ignore the data or (better yet) run a set of simulations using the network and circuit parameters provided and report the correlation between the simulation results and the Golden Waveforms. The mechanism for describing a Golden Waveform involves two new keywords whose scope is global: [Test Load] and [Test Data]. Under the [Test Data] keyword are two new keywords whose scope is local: [Rising Golden Waveform] and [Falling Golden Waveform]. [Test Load] is a description of a test load network that may be referenced by any Golden Waveform under the [Test Data] keyword. [Test Data] is a marker keyword that indicates the beginning of a group of Golden Waveforms. **************************************************************************** *** STATEMENT OF THE RESOLVED SPECIFICATIONS: |=========================================================================== == | Keywords: [Test Data] | Required: No | Description: Indicates the beginning of a pair of Golden Waveforms | and references the conditions under which they were derived. | An IBIS file may contain any number of [Test Data] sections | representing different driver and load combinations. | | Sub-Params: Test_data_type, Driver_model, Test_load, Test_point, | T_period, T_meas, V_meas | | Usage Rules: The name following the [Test Data] keyword is required. | It allows a tool to select which data to analyze. | | The Test_data_type subparameter is required, and its value | must be either "single_ended" or "differential." | | The Driver_model subparameter is required. Its value | specifies the "device-under-test" and must be a valid [Model] | name. | | The Test_load subparameter is required and indicates which | [Test Load] was used to derive the Golden Waveforms. It must | reference a valid [Test Load] name. | | The Test_point subparameter is optional. It indicates which | node in the test load network the Golden Waveforms represent. | The legal values for Test_point are "near" and "far." If | Test_point is not specified, it defaults to "far." | | The T_period subparameter is optional. In the case that the | Golden Waveforms represent more than one rising or falling | edge, the T_period subparameter tells the simulator the | period between rising or falling edges. This subparameter | is useful when constructing a test load in which a reflection | from the first edge hits the driver during the second edge. | | The T_meas subparameter is optional. It captures the time | at which the standard load crosses the threshold specified | in the component datasheet during a SPICE simulation. This | subparameter is useful when correlating timing intervals | between SPICE and behavioral simulations. It defines the | beginning of a timing interval. | | The V_meas subparameter is optional and is also used to | perform timing interval correlation. The end of a timing | interval is defined as the time when a Golden Waveform or | a behavioral waveform crosses V_meas. | | A timing interval in a behavioral waveform begins when | the waveform crosses V_meas defined in the [Model] keyword | while driving C_ref and R_ref, i.e. the standard load defined | in the component datasheet. Note that there are two | DIFFERENT V_meas subparameters in IBIS: one associated with | [Model] and one associated with [Test Data]. | |--------------------------------------------------------------------------- -- [Test Data] Data1 Test_data_type single_ended Driver_model Buffer1 Test_load Load1 Test_point far T_period = 10ns | variable typ min max T_meas 1.0ns 0.5ns 1.5ns V_meas 0.75V 0.75V 0.75V | |=========================================================================== == | Keywords: [Rising Golden Waveform], [Falling Golden Waveform] | Required: Yes (within the scope of [Test Data]) | Description: Describes the shape of the rising and falling Golden | Waveforms of a given driver and a given [Test Load]. | A model developer may use the [Rising Golden Waveform] and | [Falling Golden Waveform] keywords to document Golden | Waveforms whose purpose is to facilitate the correlation of | SPICE and behavioral simulations. | | Sub-Params: None. | | Usage Rules: The process, temperature, and voltage conditions under which | the Golden Waveforms are generated must be identical to those | used to generate the VI and VT tables. The Golden Waveforms | must be generated using unpackaged driver and receiver models. | The simulator must NOT use the Golden Waveform tables in the | construction of its internal stimulus function. | |--------------------------------------------------------------------------- -- | [Rising Golden Waveform] | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Golden Waveform] | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | |=========================================================================== == | Keywords: [Test Load] | Required: No | Description: Defines a generic test load network and its associated | electrical parameters for reference by Golden Waveforms | under the [Test Data] keyword. The Golden Waveform | tables access a given [Test Load] by the value of the | Test_load subparameter under the [Rising Golden Waveform] | and [Falling Golden Waveform] keywords. | | Sub-Params: Test_data_type, C1_near, Rs_near, Ls_near, C2_near, Rp1_near, | Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, | C1_far, V_term1, V_term2, Receiver_model, R_diff_near, | R_diff_far. | | Usage Rules: The value of the Test_data_type subparameter must be either | "single_ended" or "differential." | | The subparameters specify the electrical parameters | associated with a fixed generic test load. The diagram | below describes the single_ended test load. | | All subparameters except Test_data_type are optional. | If omitted, series elements are shorted and shunt elements | are opened by default. | | | V_term1 | o-----------o | | | | \ \ receiver_model_name | ______ / / ______ | | | NEAR Rp1_near \ \ Rp1_far FAR | | | | |\ | / / | |\ | | | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \ | | | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-| > | | | | / | | | | Td | | | | | / | | | |/ | | C1_near | \ Zo \ | C2_far | | |/ | | |______| === === / / === === |______| | | C2_near | \ \ | C1_far | | | | / / | | | | | | V_term2 | | | | o--------------o o-----------o o--------------o | | Rp2_near Rp2_far | | GND GND | | | If the Td subparameter is present, then the Zo subparameter | must also be present. If the Td subparameter is not present, | then the simulator must remove the transmission line from | the network and short the two nodes to which it was | connected. | | V_term1 defines the termination voltage for parallel | termination resistors Rp1_near and Rp1_far. This voltage | is not related to the [voltage range] keyword. | V_term2 defines the termination voltage for parallel | termination resistors Rp2_near and Rp2_far. | | Receiver_model is optional and indicates which, if any, | receiver is connected to the far end node. If not used, the | network defaults to no receiver. | | If Test_load_type is differential, a the test load is a | pair of the above circuits. If the R_diff_near subparameter | is used, it is connected between the near nodes of the two | circuits. If the R_diff_far subparameter is used, it is | connected between the near nodes of the two circuits. | |--------------------------------------------------------------------------- -- | [Test Load] Load1 Test_load_type single_ended C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff = 100 Receiver_model Input1 | variable typ min max Vterm1 1.5 1.4 1.6 Vterm2 0.0 0.0 0.0 | | Example Transmission Line and Receiver test load from "I/O Buffer Accuracy | Handbook," section 3.4.4. | [Test Load] Tline_rcv Td = 1n Zo = 50 Receiver_model Input1 |--------------------------------------------------------------------------- -- **************************************************************************** *** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Please refer to BIRD 69.1 for history. BIRD 70 came about a result of an attempt to make BIRD 69.1 upwardly compatible with IBIS-X. BIRD 70 is actually more compact and efficient because it allows multiple models to access the same [Test Load]. Recommendations came from Bob Ross, Al Davis, and the IBIS Open Forum, 3/2/01. Changes between BIRD 69.1 and BIRD 70: 1. Scope of the "generic test load" is now global rather than being local to a particular model. This is a big improvement. 2. Added one subparameter, Golden_test_load, to [Rising Waveform], [Falling Waveform] keywords. Added text to describe new the subparameter. The Golden_test_load subparameter calls a [Test Load]. 3. Exported all the other code to the new [Test Load] keyword. 4. Removed T_ref subparameter. To do timing correlation, the simulator can pick a point on the 50 Ohm VT waveform as its "SPICE reference point" and then simulate both the 50 Ohm load and the Golden_test_load to calculate a time difference. 5. Removed Pkg_pin parameter. It is too complicated. The user can model a simple single-pin lumped circuit using the parameters supplied. 6. Added Tline_present subparameter. If not used, the Tline should be removed from the simulation rather than assigned a very small delay value. This prevents the simulator from taking ridiculously small time steps. 7. Replaced V_termxxx with tables similar to the dV/dt_x subparameters. This makes the BIRD more economical. 8. Got rid of the paragraph that read, "Using the Golden Waveform tables..." This seemed to be redundant. 9. Specified which parameters are optional and which are required. Changes between BIRD 70 and BIRD 70.1: 1. Moved the Golden Waveforms OUT of the [Model] scope and under the scope of a new keyword, [Test Data]. 2. Changed [Rising Waveform] to [Rising Golden Waveform]. Changed [Falling Waveform] to [Falling Golden Waveform]. 3. Added subparameter Driver_model under [Rising Golden Waveform] and [Falling Golden Waveform]. This is necessary because the waveforms are now outside the scope of the [Model]. 4. Changed the subparameter Golden_test_load to Test_load. 5. Added the V_meas subparameter to indicate where timing correlation measurements should begin and end. 6. Added subparameters Test_data_type and Test_load_type to facilitate upward compatibility with future versions of IBIS. 7. Removed Tline_present subparameter in favor of language explaining that the simulator should remove the Tline if Td is not present. 8. Moved Driver_model, Test_load, V_meas under the scope of [Test Data]. 9. Added T_meas subparameter to facilitate timing correlation. 10. R_diff became R_diff_near and R_diff_far. 11. Added T_period subparameter to allow multi-cycle correlation in the case where a reflection hits the driver while it is switching. BIRD 70.1 adds 205 lines of code to IBIS, of which 162 are comments. **************************************************************************** *** ANY OTHER BACKGROUND INFORMATION: See BIRD 69.1. **************************************************************************** *** From owner-ibis Tue Apr 17 07:45:30 2001 Received: from smtphost.smartm.com ([158.116.149.132]) by server.eda.org (8.11.0/8.11.0) with SMTP id f3HEjO512831 for ; Tue, 17 Apr 2001 07:45:29 -0700 (PDT) Received: by smtphost.smartm.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A31.005411B0 ; Tue, 17 Apr 2001 08:18:15 -0700 X-Lotus-FromDomain: APEX DATA INC From: Ramesh.Reddy@smartm.com To: ibis@vhdl.org Message-ID: <88256A31.00540FF6.00@smtphost.smartm.com> Date: Tue, 17 Apr 2001 20:02:24 +0500 Subject: question on Tflight Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi all i have a question on Tflight when i am measuring Tflight b/n processor and 440bx both for fast and slow corner, i am getting Tflight_min (fastcorner) value more than Tflight_max (slowcorner). I am measuring Tflight as per guide lines. can i get like that ? or i am going wrong. regards ramesh From owner-ibis Tue Apr 17 08:20:34 2001 Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3HFKV512979 for ; Tue, 17 Apr 2001 08:20:33 -0700 (PDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id PAA08693; Tue, 17 Apr 2001 15:20:00 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 17 Apr 2001 15:19:59 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id <27CN84KF>; Tue, 17 Apr 2001 08:19:57 -0700 Message-ID: From: "Kern, Frank" To: "'Ramesh.Reddy@smartm.com'" Cc: ibis@vhdl.org Subject: RE: question on Tflight Date: Tue, 17 Apr 2001 08:19:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Hi Ramesh, I have seen this for some designs. Upon investigation, we found a simple explanation. The minimum threshold voltage for the slow corner is lower than the value for the fast corner. Also the starting low voltage level, Vol, for the slow corner is higher than the fast corner value. As a consequence, the slow case has to transition through a lesser amount of voltage compared to the fast case, which can result in a slow corner flight time appearing faster than the fast case. Kern Intel Corporation -----Original Message----- From: Ramesh.Reddy@smartm.com [mailto:Ramesh.Reddy@smartm.com] Sent: Tuesday, April 17, 2001 8:02 AM To: ibis@vhdl.org Subject: question on Tflight Hi all i have a question on Tflight when i am measuring Tflight b/n processor and 440bx both for fast and slow corner, i am getting Tflight_min (fastcorner) value more than Tflight_max (slowcorner). I am measuring Tflight as per guide lines. can i get like that ? or i am going wrong. regards ramesh From owner-ibis Tue Apr 17 08:41:56 2001 Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3HFfr513035 for ; Tue, 17 Apr 2001 08:41:55 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id EE4711A3; Tue, 17 Apr 2001 08:43:57 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 71D2C283; Tue, 17 Apr 2001 08:43:57 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id <27D2J5TD>; Tue, 17 Apr 2001 11:40:51 -0400 Message-ID: From: "Ingraham, Andrew" To: "'Ramesh.Reddy@smartm.com'" Cc: ibis@vhdl.org Subject: RE: question on Tflight Date: Tue, 17 Apr 2001 11:40:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain > i have a question on Tflight > when i am measuring Tflight b/n processor and 440bx both for fast and > slow > corner, > i am getting Tflight_min (fastcorner) value more than Tflight_max > (slowcorner). > I am measuring Tflight as per guide lines. > can i get like that ? I am not sure if this is relevant to your question; I don't know whose "guidelines" you are using; etc. But if you define Tflight as the difference between the signal at the far end of your actual trace, and the transmitted signal with a standard test load, this can happen, especially if the test load is capacitive. (Doing it this way makes it easier to add the driver's datasheet delay to Tflight, and the result is the total delay to the receiver's input.) In the slow corner case, the driving device's delay into the standard test load is more, so it is a larger number that you subtract from the total delay to get Tflight. If the test load is highly capacitive, it can exaggerate this effect, causing the delay with the test load to become larger at a faster rate than that with your real load. You can even get negative "wire" delays this way, especially in the slow corner case. Regards, Andy From owner-ibis Tue Apr 17 10:22:17 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3HHMF513590 for ; Tue, 17 Apr 2001 10:22:16 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f3HHLdW26168; Tue, 17 Apr 2001 13:21:39 -0400 From: "Todd Westerhoff" To: "Ingraham, Andrew" , Cc: Subject: RE: question on Tflight Date: Tue, 17 Apr 2001 13:22:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Andy is absolutely right ... and capacitive test loads make the problems worse. Moral of the story: When using a fast driver, look only at the min flight times (ignore the max ones) When using a slow driver, look only at the max flight times (ignore the min ones) If you want to perform an intersting "sanity check" of your SI models, find the output delay into the test load for the fast and slow driver cases (variously called "Buffer Delay", "TIME_TO_VM" and others), and then subtract those numbers from the datasheet values for Tcomin and Tcomax, respectively. The number you get represents what I think of as the "internal delay" of the part - the time between when the clock input triggers and time "0" of the SI simulation. This isn't a real delay, because of the different ways the output can be modeled, but it's an interesting "figure of merit" exercise. In some of the devices we've worked with recently, this exercise led to the conclusion that the output stage could be triggered up to 1ns _before_ the device received its input clock. This wasn't the actual case - but it provided us with some valuable insight about just how much the part's timing numbers were being guard-banded. Todd. -----Original Message----- From: Ingraham, Andrew [mailto:Andrew.Ingraham@compaq.com] Sent: Tuesday, April 17, 2001 11:41 AM To: 'Ramesh.Reddy@smartm.com' Cc: ibis@vhdl.org Subject: RE: question on Tflight > i have a question on Tflight > when i am measuring Tflight b/n processor and 440bx both for fast and > slow > corner, > i am getting Tflight_min (fastcorner) value more than Tflight_max > (slowcorner). > I am measuring Tflight as per guide lines. > can i get like that ? I am not sure if this is relevant to your question; I don't know whose "guidelines" you are using; etc. But if you define Tflight as the difference between the signal at the far end of your actual trace, and the transmitted signal with a standard test load, this can happen, especially if the test load is capacitive. (Doing it this way makes it easier to add the driver's datasheet delay to Tflight, and the result is the total delay to the receiver's input.) In the slow corner case, the driving device's delay into the standard test load is more, so it is a larger number that you subtract from the total delay to get Tflight. If the test load is highly capacitive, it can exaggerate this effect, causing the delay with the test load to become larger at a faster rate than that with your real load. You can even get negative "wire" delays this way, especially in the slow corner case. Regards, Andy From owner-ibis Tue Apr 17 12:33:56 2001 Received: from mako.hhnetwk.com ([65.198.127.146]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3HJXs514055 for ; Tue, 17 Apr 2001 12:33:55 -0700 (PDT) Received: from westerhoff (IDENT:root@ssh2.hhnetwk.com [192.168.0.2]) by mako.hhnetwk.com (8.11.0/bg-001114) with SMTP id f3HJXBW29922; Tue, 17 Apr 2001 15:33:12 -0400 From: "Todd Westerhoff" To: "Todd Westerhoff" , "Ingraham, Andrew" , Cc: Subject: RE: question on Tflight Date: Tue, 17 Apr 2001 15:33:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal A clarification to my earlier post -- Please note that the statements: When using a fast driver, look only at the min flight times (ignore the max ones) When using a slow driver, look only at the max flight times (ignore the min ones) are meant only for the case where the output delay in spec'd into a large (~50pF) capacitive load. Sorry for any confusion ... Todd. -----Original Message----- From: Todd Westerhoff [mailto:twester@hhnetwk.com] Sent: Tuesday, April 17, 2001 1:22 PM To: Ingraham, Andrew; Ramesh.Reddy@smartm.com Cc: ibis@vhdl.org Subject: RE: question on Tflight Andy is absolutely right ... and capacitive test loads make the problems worse. Moral of the story: When using a fast driver, look only at the min flight times (ignore the max ones) When using a slow driver, look only at the max flight times (ignore the min ones) If you want to perform an intersting "sanity check" of your SI models, find the output delay into the test load for the fast and slow driver cases (variously called "Buffer Delay", "TIME_TO_VM" and others), and then subtract those numbers from the datasheet values for Tcomin and Tcomax, respectively. The number you get represents what I think of as the "internal delay" of the part - the time between when the clock input triggers and time "0" of the SI simulation. This isn't a real delay, because of the different ways the output can be modeled, but it's an interesting "figure of merit" exercise. In some of the devices we've worked with recently, this exercise led to the conclusion that the output stage could be triggered up to 1ns _before_ the device received its input clock. This wasn't the actual case - but it provided us with some valuable insight about just how much the part's timing numbers were being guard-banded. Todd. -----Original Message----- From: Ingraham, Andrew [mailto:Andrew.Ingraham@compaq.com] Sent: Tuesday, April 17, 2001 11:41 AM To: 'Ramesh.Reddy@smartm.com' Cc: ibis@vhdl.org Subject: RE: question on Tflight > i have a question on Tflight > when i am measuring Tflight b/n processor and 440bx both for fast and > slow > corner, > i am getting Tflight_min (fastcorner) value more than Tflight_max > (slowcorner). > I am measuring Tflight as per guide lines. > can i get like that ? I am not sure if this is relevant to your question; I don't know whose "guidelines" you are using; etc. But if you define Tflight as the difference between the signal at the far end of your actual trace, and the transmitted signal with a standard test load, this can happen, especially if the test load is capacitive. (Doing it this way makes it easier to add the driver's datasheet delay to Tflight, and the result is the total delay to the receiver's input.) In the slow corner case, the driving device's delay into the standard test load is more, so it is a larger number that you subtract from the total delay to get Tflight. If the test load is highly capacitive, it can exaggerate this effect, causing the delay with the test load to become larger at a faster rate than that with your real load. You can even get negative "wire" delays this way, especially in the slow corner case. Regards, Andy From owner-ibis Wed Apr 18 11:38:10 2001 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3IIc3519918 for ; Wed, 18 Apr 2001 11:38:04 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA268496 for ; Wed, 18 Apr 2001 14:35:58 -0400 Received: from d27ml104.rchland.ibm.com (d27ml104.rchland.ibm.com [9.5.39.61]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id OAA37600 for ; Wed, 18 Apr 2001 14:32:22 -0400 Importance: Normal Subject: BIRD 70.1 - take 2 To: ibis@vhdl.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Gregory R Edlund" Date: Wed, 18 Apr 2001 13:36:50 -0500 X-MIMETrack: Serialize by Router on d27ml104/27/M/IBM(Release 5.0.6a |January 17, 2001) at 04/18/2001 01:37:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii As a result of yesterday's IBIS Futures conference call, I have made a few changes to BIRD 70.1. I removed the "Test_point" subparameter and replaced it by a near/far qualifier to the [Rising/Falling Waveform] keywords. As I understood the conversation yesterday, the two remaining points of discussion are: 1) Do we need additional Test_load_types to cover all differential test loads allowable by IBIS today? Bob Ross says yes. 2) Is the Tmeas subparameter necessary? I have added some ASCII art to the BIRD in hopes of clarifying item 2. Hopefully this BIRD is close to completion! Greg ******************************************************************************* ******************************************************************************* BIRD ID#: 70.1 ISSUE TITLE: Golden Waveforms REQUESTOR: Greg Edlund, IBM DATE SUBMITTED: March 16, 2001; April 18, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Golden Waveforms are a set of SPICE waveforms simulated using known ideal test loads. They are useful in verifying the accuracy of behavioral simulation results for any given simulator. They are not the same thing as the traditional VT tables recommended in the "IBIS Cookbook." The "I/O Buffer Accuracy Handbook" recommends a set of ideal test loads for classical push-pull and open-drain drivers. There is currently a problem with including Golden Waveforms in an IBIS datasheet: the simulator tries to use these waveforms to construct its stimulus waveform, and erroneous simulations result. This BIRD proposes a new syntactical construct to tell the simulator that a waveform is a Golden Waveform. The simulator may then choose to ignore the data or (better yet) run a set of simulations using the network and circuit parameters provided and report the correlation between the simulation results and the Golden Waveforms. The mechanism for describing a Golden Waveform involves two new keywords whose scope is global: [Test Load] and [Test Data]. Under the [Test Data] keyword are four new keywords whose scope is local: [Rising Waveform Near], [Falling Waveform Near], [Rising Waveform Far], [Falling Waveform Far]. [Test Load] is a description of a test load network that may be referenced by any Golden Waveform under the [Test Data] keyword. [Test Data] is a marker keyword that indicates the beginning of a group of Golden Waveforms. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: |============================================================================= | Keywords: [Test Data] | Required: No | Description: Indicates the beginning of a set of Golden Waveforms | and references the conditions under which they were derived. | An IBIS file may contain any number of [Test Data] sections | representing different driver and load combinations. | | Sub-Params: Test_data_type, Driver_model, Test_load, | Tmeas_rise, Tmeas_fall, Vx_rise, Vx_fall | | Usage Rules: The name following the [Test Data] keyword is required. | It allows a tool to select which data to analyze. | | The Test_data_type subparameter is required, and its value | must be either "Single_ended" or "Differential." | | The Driver_model subparameter is required. Its value | specifies the "device-under-test" and must be a valid [Model] | name. | | The Test_load subparameter is required and indicates which | [Test Load] was used to derive the Golden Waveforms. It must | reference a valid [Test Load] name. | | The Tmeas_rise, Tmeas_fall, Vx_rise, and Vx_fall subparameters | are all optional. They work in concert with the standard load | parameters under the [Model] keyword (Cref, Rref, Vref, Vmeas) | to define two timing intervals for timing correlation. | Tmeas_rise is the time at which the SPICE standard load | rises through Vmeas with the SAME driver input that was | used to derive the Golden Waveform tables. | | SPICE simulation of standard load (not captured in IBIS file) | ________________ | / \ | /--- Vmeas \ | ____/ \______________ | + Tmeas_rise | | SPICE simulation of Test_load (captured in [Test Data]) | ________________ | / \ | /--- Vx_rise \ | ______________/ \______________ | + | |<------->| Timing Interval 1 | | | Behavioral simulation of standard load | ________________ | / \ | /--- Vmeas \ | ____/ \______________ | + | | Behavioral simulation of Test_load | ________________ | / \ | /--- Vx_rise \ | ______________/ \______________ | + | |<------->| Timing Interval 2 | |----------------------------------------------------------------------------- [Test Data] Data1 Test_data_type Single_ended Driver_model Buffer1 Test_load Load1 | variable typ min max Tmeas_rise 1.0ns 0.5ns 1.5ns Tmeas_fall 1.0ns 0.5ns 1.5ns Vx_rise 0.75V 0.75V 0.75V Vx_fall 0.75V 0.75V 0.75V | |============================================================================= | Keywords: [Rising Waveform Near], [Falling Waveform Near], | [Rising Waveform Far], [Falling Waveform Far] | Required: At least one Rising/Falling waveform pair is required under | the scope of the [Test Data] keyword. Two pairs are allowed. | Description: Describes the shape of the rising and falling Golden | Waveforms of a given driver and a given [Test Load]. | A model developer may use the [Rising Waveform Near/Far] and | [Falling Waveform Near/Far] keywords to document Golden | Waveforms whose purpose is to facilitate the correlation of | SPICE and behavioral simulations. | | Sub-Params: None. | | Usage Rules: The process, temperature, and voltage conditions under which | the Golden Waveforms are generated must be identical to those | used to generate the VI and VT tables. The Golden Waveforms | must be generated using unpackaged driver and receiver models. | The simulator must NOT use the Golden Waveform tables in the | construction of its internal stimulus function. | |----------------------------------------------------------------------------- | [Rising Waveform Far] | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Waveform Far] | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | |============================================================================= | Keywords: [Test Load] | Required: No | Description: Defines a generic test load network and its associated | electrical parameters for reference by Golden Waveforms | under the [Test Data] keyword. The Golden Waveform | tables correspond to a given [Test Load] which is specified | by the Test_load subparameter under the [Test Data] keyword. | | Sub-Params: Test_data_type, C1_near, Rs_near, Ls_near, C2_near, Rp1_near, | Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, | C1_far, V_term1, V_term2, Receiver_model, R_diff_near, | R_diff_far. | | Usage Rules: The value of the Test_data_type subparameter must be either | "Single_ended" or "Differential." | | The subparameters specify the electrical parameters | associated with a fixed generic test load. The diagram | below describes the single_ended test load. | | All subparameters except Test_data_type are optional. | If omitted, series elements are shorted and shunt elements | are opened by default. | | | V_term1 | o-----------o | | | | \ \ receiver_model_name | ______ / / ______ | | | NEAR Rp1_near \ \ Rp1_far FAR | | | | |\ | / / | |\ | | | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \ | | | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-| > | | | | / | | | | Td | | | | | / | | | |/ | | C1_near | \ Zo \ | C2_far | | |/ | | |______| === === / / === === |______| | | C2_near | \ \ | C1_far | | | | / / | | | | | | V_term2 | | | | o--------------o o-----------o o--------------o | | Rp2_near Rp2_far | | GND GND | | | If the Td subparameter is present, then the Zo subparameter | must also be present. If the Td subparameter is not present, | then the simulator must remove the transmission line from | the network and short the two nodes to which it was | connected. | | V_term1 defines the termination voltage for parallel | termination resistors Rp1_near and Rp1_far. This voltage | is not related to the [voltage range] keyword. | V_term2 defines the termination voltage for parallel | termination resistors Rp2_near and Rp2_far. | | Receiver_model is optional and indicates which, if any, | receiver is connected to the far end node. If not used, the | network defaults to no receiver. | | If Test_load_type is differential, a the test load is a | pair of the above circuits. If the R_diff_near subparameter | is used, it is connected between the near nodes of the two | circuits. If the R_diff_far subparameter is used, it is | connected between the near nodes of the two circuits. | |----------------------------------------------------------------------------- | [Test Load] Load1 Test_load_type Single_ended C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff = 100 Receiver_model Input1 | variable typ min max Vterm1 1.5 1.4 1.6 Vterm2 0.0 0.0 0.0 | | Example Transmission Line and Receiver test load from "I/O Buffer Accuracy | Handbook," section 3.4.4. | [Test Load] Tline_rcv Td = 1n Zo = 50 Receiver_model Input1 |----------------------------------------------------------------------------- ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Please refer to BIRD 69.1 for history. BIRD 70 came about a result of an attempt to make BIRD 69.1 upwardly compatible with IBIS-X. BIRD 70 is actually more compact and efficient because it allows multiple models to access the same [Test Load]. Recommendations came from Bob Ross, Al Davis, and the IBIS Open Forum, 3/2/01. Changes between BIRD 69.1 and BIRD 70: 1. Scope of the "generic test load" is now global rather than being local to a particular model. This is a big improvement. 2. Added one subparameter, Golden_test_load, to [Rising Waveform], [Falling Waveform] keywords. Added text to describe new the subparameter. The Golden_test_load subparameter calls a [Test Load]. 3. Exported all the other code to the new [Test Load] keyword. 4. Removed T_ref subparameter. To do timing correlation, the simulator can pick a point on the 50 Ohm VT waveform as its "SPICE reference point" and then simulate both the 50 Ohm load and the Golden_test_load to calculate a time difference. 5. Removed Pkg_pin parameter. It is too complicated. The user can model a simple single-pin lumped circuit using the parameters supplied. 6. Added Tline_present subparameter. If not used, the Tline should be removed from the simulation rather than assigned a very small delay value. This prevents the simulator from taking ridiculously small time steps. 7. Replaced V_termxxx with tables similar to the dV/dt_x subparameters. This makes the BIRD more economical. 8. Got rid of the paragraph that read, "Using the Golden Waveform tables..." This seemed to be redundant. 9. Specified which parameters are optional and which are required. Changes between BIRD 70 and BIRD 70.1: 1. Moved the Golden Waveforms OUT of the [Model] scope and under the scope of a new keyword, [Test Data]. 2. Changed [Rising Waveform] to [Rising Waveform Near/Far]. Changed [Falling Waveform] to [Falling Waveform Near/Far]. 3. Added subparameter Driver_model under [Rising Golden Waveform] and [Falling Golden Waveform]. This is necessary because the waveforms are now outside the scope of the [Model]. 4. Changed the subparameter Golden_test_load to Test_load. 5. Added the Vx_rise/fall subparameters to indicate the end of a timing interval for timing correlation. 6. Added Tmeas_rise/fall to facilitate timing correlation. 7. Added subparameters Test_data_type and Test_load_type to facilitate upward compatibility with future versions of IBIS. 8. Removed Tline_present subparameter in favor of language explaining that the simulator should remove the Tline if Td is not present. 9. Moved Driver_model and Test_load under the scope of [Test Data]. 10. R_diff became R_diff_near and R_diff_far. BIRD 70.1 adds 230 lines of code to IBIS, of which 172 are comments. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: See BIRD 69.1. ******************************************************************************* Greg Edlund Electrical Packaging IBM Server Technology Development 3605 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Wed Apr 18 10:17:56 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3IHHs519578; Wed, 18 Apr 2001 10:17:55 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA11173; Wed, 18 Apr 2001 10:17:18 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2X80CNC8; Wed, 18 Apr 2001 10:17:17 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3ADDCC1B.57FF331C@mentor.com> Date: Wed, 18 Apr 2001 10:17:15 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: IBIS Version 3.2 [Fwd: IEC 62014-1 Ed.1] Content-Type: multipart/mixed; boundary="------------69A67E87F818929FCE85E23A" This is a multi-part message in MIME format. --------------69A67E87F818929FCE85E23A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: Cecilia Fleming of EIA reports that IBIS Version 3.2 has been approved for release as an international standard under IEC. The vote link is below. It should be published by IEC in about a month. Bob Ross Mentor Graphics --------------69A67E87F818929FCE85E23A Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from newsgw.mentorg.com ([192.94.38.137]) by svr-orw-exc-03.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2N98C51Z; Wed, 18 Apr 2001 05:43:59 -0700 Received: from eia.org by newsgw.mentorg.com (8.8.8/CF5.40F) id FAA06290; Wed, 18 Apr 2001 05:43:41 -0700 (PDT) Received: from EIADOM-Message_Server by eia.org with Novell_GroupWise; Wed, 18 Apr 2001 08:41:43 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 18 Apr 2001 08:41:28 -0400 From: "Cecilia Fleming" To: Subject: IEC 62014-1 Ed.1 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob: It looks like it was approved go to: http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=3DE&wwwprog=3Dv= ote2.p&wcom=3D93&wclass=3D&wdoc=3D129&wsup=3D Cece --------------69A67E87F818929FCE85E23A-- From owner-ibis Wed Apr 18 14:57:53 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3ILvp520528 for ; Wed, 18 Apr 2001 14:57:52 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA06178; Wed, 18 Apr 2001 14:57:14 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2X80C3DK; Wed, 18 Apr 2001 14:57:13 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3ADE0DB7.46B623B5@mentor.com> Date: Wed, 18 Apr 2001 14:57:11 -0700 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 Friday 4/20/01 Connector Spec. Review Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: We will be discussing a work in progress Connector Specification at the meeting. At the next meeting we will cover sections 1-6 (Header Section), pages 1-10. The purpose is to present/educate the IBIS Open Forum about proposed details and to get the next level of input before presenting the document for a committee vote. The latest version is under the Connector Info link of: http://www.eda.org/pub/ibis/connector/ I expect this to be updated regularly as we make changes and gain further understanding. Some of the changes will be editorial to be in alignment with the work done by the IBIS Futures Working Group. The current version for review is 0.961B, under ICM_961B.PDF. Bob Ross Mentor Graphics From owner-ibis Thu Apr 19 11:13:37 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3JIDX525947 for ; Thu, 19 Apr 2001 11:13:35 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA24194; Thu, 19 Apr 2001 11:12:55 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2X80CP6K; Thu, 19 Apr 2001 11:12:55 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3ADF2AA7.35280D29@mentor.com> Date: Thu, 19 Apr 2001 11:12:55 -0700 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: apanella@molex.com, ibis@eda.org Subject: Re: IBIS Meeting Friday 4/20/01 Connector Spec. Review References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: Version 0.962 of the Connector Specification is now uploaded for review under: http://www.eda.org/pub/ibis/connector/ICM0962.PDF Bob Ross Mentor Graphics apanella@molex.com wrote: > > <>Bob... > > 0.962 attached > > _gus > > -----Original Message----- > From: Bob Ross > Sent: Wednesday, April 18, 2001 4:57 PM > To: ibis@eda.org > Subject: IBIS Meeting Friday 4/20/01 Connector Spec. Review > > To All: > > We will be discussing a work in progress Connector > Specification at the meeting. At the next meeting > we will cover sections 1-6 (Header Section), pages 1-10. > The purpose is to present/educate the IBIS Open Forum > about proposed details and to get the next level of > input before presenting the document for a committee > vote. > > The latest version is under the Connector Info > link of: > > http://www.eda.org/pub/ibis/connector/ > > I expect this to be updated regularly as we make > changes and gain further understanding. Some of the > changes will be editorial to be in alignment with > the work done by the IBIS Futures Working Group. > > The current version for review is 0.961B, under > ICM_961B.PDF. > > Bob Ross > Mentor Graphics > > -------------------------------------------------------------------------------- > Name: ICM0962.PDF > ICM0962.PDF Type: Portable Document Format (application/pdf) > Encoding: base64 > Download Status: Not downloaded with message From owner-ibis Thu Apr 19 16:33:25 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3JNXN527101 for ; Thu, 19 Apr 2001 16:33:25 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA20885; Thu, 19 Apr 2001 16:32:46 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2X80CQ9B; Thu, 19 Apr 2001 16:32:45 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3ADF759A.CD2D8891@mentor.com> Date: Thu, 19 Apr 2001 16:32:42 -0700 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 CC: "Ross, Bob" Subject: IBIS BIRD70.2 Comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: Greg Edlund recently issued IBIS BIRD70.2 for Golden Waveforms. It was issued as a revised BIRD70.1, but it is uploaded as BIRD70.2 under: http://www/eda/org/pub/ibis/birds/ My general comment (that has been shared privately already with Greg) is that BIRD70.2 should be extended to cover differential Golden Waveforms in a more robust and useful manner. The overall criteria should be: Does it support all of the commonly used technologies today (SSTL-*, LVDS, etc.)? Also, BIRD70.2 should support some cases where the inverting driver or the inverting receiver can be different than the non-inverting driver or receiver. BIRD70.2 already proposes a fairly useful and general test configuration for Single-ended loads and tests. I believe only a few additions are need to make it useful for general Differential tests. Under [Test Load], I would make these changes: Add Receiver_model_Inverting | Optional Under [Test Load] Add Driver_model_Inverting | Optional Add a section for [Differntial Waveform Near] [Differntial Waveform Far] There may be some other parameters needed related to some of the threshold and timing details, but I need to study this further. Bob Ross Mentor Graphics From owner-ibis Mon Apr 23 17:57:08 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3O0v6b16864 for ; Mon, 23 Apr 2001 17:57:07 -0700 (PDT) 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 UAA00924 for ; Mon, 23 Apr 2001 20:56:27 -0400 (EDT) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id UAA16513 for ; Mon, 23 Apr 2001 20:56:25 -0400 (EDT) Received: from f22.innoveda.com (f22.camarillo.innoveda.com [139.181.194.48]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id RAA24047 for ; Mon, 23 Apr 2001 17:56:21 -0700 (PDT) Received: by f22.innoveda.com (SMI-8.6/SMI-SVR4) id RAA03017; Mon, 23 Apr 2001 17:56:22 -0700 Date: Mon, 23 Apr 2001 17:56:22 -0700 From: guy@camarillo.innoveda.com (Guy de Burgh) Message-Id: <200104240056.RAA03017@f22.innoveda.com> To: ibis@eda.org Subject: EIA IBIS Open Forum Meeting Minutes DATE: 4/23/01 SUBJECT: 4/20/01 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 2001 PARTICIPANTS LIST: 3Com (& CommWorks) Roy Leventhal* Agilent (Mark Chang) Ansoft Corporation (Eric Bracken) Apple Computer John Figueroa Applied Simulation Technology Raj Raghuram, Norio Matsui, Fred Balistreri Avanti (Chen Hongyu) Brocade Communications Robert Badal Cadence Design Ian Dodd, Patrick Dos Santos, Heiko Dudek Cisco Systems Syed Huq, Lungfu Chen Compaq Peter LaFlamme, Ron Bellomio, Quang Dam, Bill Ham Cypress (Rajesh Manapat) EMC Corporation Brian Arsenault, Jinhua Chen Fairchild Semiconductor Adam Tambone IBM Michael Cohen, Greg Edlund*, Wes Martin, Yeon-Chang Hahm, Bill DeVey, Pravin Patel Innoveda (& HyperLynx) Guy de Burgh*, John Angulo*, Cary Mandel, Matthew Flora* Intel Corporation Stephen Peters*, Arpad Muranyi*, Dave Lorang, Michael Mirmak*, Qinglun Chen, Will Hobbs LSI Logic Larry Barnes* Mentor Graphics Bob Ross*, Tom Dagostino, Chris Reid, Mike Donnelly, Hazem Hegazy, Tony Dunbar, Griff Derryberry, Dan Lake, Sherif Hammad, Mohammed Korany, Weston Beal, Chris Swaim, Ali Samii, Eric Ronger, Karine Loudet Micron Technology Randy Wolff, Yong Phan Mitsubishi (Tam (Tom) Cao) Molex Incorporated Gus Panella, Brian O'Malley Motorola (Ron Werner) National Semiconductor Milt Schwartz* Nortel Networks Calvin Trowell North East Systems Associates Edward Sayre Philips Semiconductor Zack Ciccone, Rob Mataheroe Quantic EMC (Mike Ventham) Robinson-Nugent, Inc. (Alexander Barr) Siemens (& Automotive) AG Bernhard Unger, Helmut Katzier, Katja Koller, Wolfram Meyer, Eckhard Lenski, Gerald Bannert, Burkhard Muller, Christian Marot, Manfred Maurer, Amir Motamedi, Hans Pichlmaier Signal Integrity Software Douglas Burns, Barry Katz, Walter Katz SiQual Scott McMorrow, Rob Hinz, Bernard Voss, Chris Brewster Texas Instruments Thomas Fisher, Stephen Nolan, Ramzi Ammar, Jean Claude Perrin* Time Domain Analysis Systems Dima Smolyansky, Steve Corey Tyco Electronics (Russell Moser) Via Technologies (Weber Chuang) Zuken (& Incases) John Berrie OTHER PARTICIPANTS IN 2001: Actel Corporation Silvia Montoya Acuson Kim Helliwell AMCC Jeff Smith ASIS Ltd David Wright BMW Friedrich Hasinger Cereva Networks Bob Haller EADS Airbus Industry Claude Huet (Aerospatiale) EFM Ekkehard Miersch, Horle Raines EIA Cecilia Fleming FCI Sercu Stefaan Foundary Networks Bertram Chan Framatom Conectors Danny Morlion Fraunhofer Institute Mariusz Faferko, Peter Kralicek Reliability and Integration Fujitsu Ltd Tadashi Arai, Takeshi Murakami Heidelberger Druchmaschinen AG Wolfgang Kleinfeldt Huawei Technologies Rachild Chen Hyundai Electronics Jongho Kang Infineon Technologies Christian Sporrer Intrinsix Corporation Steven Chin National Institute of Applied Etienne Sicard Science (INSA) Nokia Tapani von Ravner, Mika Castren, Janne Uusitalo Oak Technology Darmin Jin Plexus Technology Group Joseph Socha Sintecs Hans Klos STMicroelectronics Peter Hirt, Fabrice Boissieres Sun Adrian Udenze Xilinx Susan Wu Independent, Consultant Al Davis* 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 May 11 (916) 356-2663 2 0210511 June 1 (916) 356-2663 2 6352088 Thursday June 21, 2001 IBIS Summit Meeting, No Phone Bridge All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum, and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Long time IBIS participant Matthew Flora from Innoveda joined us for the first time this year. His main IBIS involvement is with ibischk3 development and issues (bugs). MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross gave a final year 2000 financial report based on the latest adjustments. A synopsis is below: Budget Actual Income: 22,500.00 23,545.50 Parser: 0 6,252.00 Royalties: 1,000.00 4,335.77 --------- --------- Total Income: 23,500.00 34,133.27 Total Expenses: 15,710.00 13,050.16 Total Allocations: 6,370.00 6,632.84 --------- --------- Total Payments: 22,080.00 19,683.00 ========= ========= Net Income: $1,420.00 $14,550.27 Some of the income is already targeted for ibischk3 parser development work. All of the income is carried over to this year and available for projects. Bob stated that our budget for this year is about the same, except that the EIA expenses have been increased by $3,000 for administrative support. Our membership income may be less this year due to current economic conditions. Bob also stated the Cecilia Fleming sent invoices again to companies that have not paid. We currently have about 25 paid members. Bob expects about 30 this year, down from 34. So we expect a break-even year. REVIEW OF MINUTES AND AR'S The March 30, 2001 IBIS Minutes were approved without change. The ARs will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Bob Ross reported IBIS references in two articles in the April 2001 issue of Printed Circuit Design: "Signal Integrity Fundamentals" by Lynne Green, pp. 16 - 18, and "People to Know, Howard W. Johnson, The Wizard of Black Magic", by Andy Shaughnessy, pp 34 - 35, 43. Also IBIS is mentioned in the March 2001 issue of High Density Interconnect Magazine, "TDR for Characterization and Modeling of Electronic Packaging, Part 1" by Dima Smolyansky. Bob reported that Syed updated the Upcoming Events Link. Also a new IBIS Futures Working Group link is added and another logo has been added to the Poster link. NEW MODELS AVAILABLE, LIBRARY UPDATE Roy Leventhal announced that the IBIS Models page has been updated. A few company names have been changed. Roy is currently in maintenance mode and may add some internal hyper-links for easier access within the page. Bob Ross reported that Galileo Technology now has an IBIS model at: http://www.galileot.com/products/internetworking/horizon/96100A.IBS Bob stated he was glad that Roy is now maintaining the IBIS models page and keeping it up to date. Report any new models to Roy. OPENS FOR NEW ISSUES None. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 3.2) - Bob Ross reported that the vote closed on April 13, 2001, and IEC 62014-1 was approved 7 Yes, 0 No and 5 Abstaining. Bob expects that IBIS Version 3.2 will be published by IEC in about a month as an international standard. The link showing the country voting results is (split into two lines): http://www.iec.ch/cgi-bin/procgi.pl/www/ iecwww.p?wwwlang=E&wwwprog=vote2.p&wcom=93&wclass=&wdoc=129&wsup= - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - No report. - IEC 62014-3 (ICEM) Integrated Circuit Electromagnetic Model Proposal (formerly, IEC 93/67/NP IBIS and EMC Simulation) - Jean Claude Perrin reported that the working draft of the document has been received by IEC. Jean Claude will send Bob Ross a copy of the document for uploading on the IBIS page on Monday, April 23, 2001. The official document needs to be re-formatted according to IEC guidelines before it is approved. This should take about a month. Jean Claude will contact Bob concerning how to proceed next. Bob stated that he has created a subdirectory for EMC data on: http://www.eda.org/pub/ibis/emc/ He has an older presentation under it and plans to put the European IBIS Summit presentations related to EMC under this link as well [Done]. - JEDEC JC-16 - Modeling and Testing - No report. - T10, Project 1414-DT - SCSI Signal Modeling (a Technical Committee of the National Committee for Information Technology (NCITS)) - Larry Barnes commented that he reviewed IBIS reflector e-mail sent by Chris Reid on "Reduced Strength Drivers and Driver Schedules" with his designers. They generally liked the approach and also Chris' possible improvement. However, they added that the clock signal frequency was "negotiatable". In the future, Larry would like a solution that uses the clock signal. Currently, multiple driver schedules would be needed. Chris' improvement might help here. Bob Ross concluded that IBIS Version 3.2 currently solves the problem to a satisfactory level, and Larry stated that this takes care of some proposed SCSI advances for the next few years. DESIGN AUTOMATION CONFERENCE 2001 IBIS SUMMIT MEETING PLANS Bob Ross gave the general plans for the next IBIS Summit Meeting. The annual meeting is conducted along with the Design Automation Conference (DAC), held this year in Las Vegas, Nevada. The IBIS Summit Meeting will be in the Hilton Hotel adjacent to the Las Vegas Convention Center. The meeting date is Thursday, June 21, 2001, the day following the trade show portion of DAC. This meeting is sponsored by the IBIS Open Forum through the dues. Guy de Burgh will coordinate the signups, presentations and other local logistics. EIA and Cecilia Fleming will help with the meeting site and luncheon logistics. Bob stated that the first announcement should be sent out at the end of April or beginning of May. Bob estimated about 10 are attending so far based on responses at this meeting and on other contacts. Typically about 25 people attend. Larry Barnes asked if there would be a teleconference phone line since travel is more restricted. Bob stated that they are quite expensive (hundreds of dollars) and he would prefer not to have one. Bob asked Guy to investigate bringing an LCD projector since Hotel rental prices are usually quite high. Bob also stated that he prefers overhead foils for better meeting flow and interaction. Bob noted that the annual election of IBIS officers occurs at that meeting. Nominations are open to anyone, but the Chair and Vice-chair must be from EIA IBIS Open Forum member companies. Nominations will be accepted at the meeting. Bob stated that the existing slate of officers are willing to serve again in their current positions. The only difference is that Bob and Stephen Peters are planning to switch Chair and Vice-Chair roles. Even so, all positions are open, and other candidates are welcome. Bob outlined other meeting topics and possible presentations: Connector Specification IBIS-X IBIS Version 4.0 Issues Possibly other topics such as enhanced buffer extraction and driver schedule modeling. The meeting is scheduled for all day, but it will probably end early. We typically have fewer presentations for this meeting than at other Summit meetings. IBIS MODEL REVIEW COMMITTEE DISCUSSION John Angulo stated that no new models have been received. Bob Ross knows of one that may be submitted. John also mentioned that the number of companies reviewing models has dropped to two. He needs a representative from another company and will pursue this off-line. CONNECTOR PROPOSAL REVIEW Bob Ross reported on a meeting with Bob, Stephen Peters and Gus Panella held on April 17, 2001 to discuss alignment issues with the IBIS-X draft and the Connector Specification. The IBIS Futures Working Group had used some of the Connector Specification ideas for the IBIS-X document. As a result they are similar, but some differences have emerged. The group agreed on a number of details and Gus issued Version 9.62 for review. Connector Working Group meetings will be scheduled every second Tuesday one hour before the IBIS Futures Group meeting, with the next one occurring on May 1, 2001. Bob indicated that the Connector Working Group meeting teleconference numbers will be sent to the IBIS Reflector to open up the participation to anyone who is interested. Larry Barnes stated that he might attend since the SCSI Committee also is interested in connector issues. Bob gave several reasons for the introductory review. We now want to get the document into a state where we can vote on it. We want to educate the IBIS community on what is in it and on how to read it. And we want to examine more closely some decisions we have made since they will also apply to the IBIS-X documents. Bob noted that the Connector Specification will still need to be cleaned up editorially, and this will be going on while we are reviewing the technical content. So a number of upgrade releases should be issued. For reference, Bob compared the IBIS Connector Specification with both the IBIS Version 3.2 document and a Version 0.23 draft of the IBIS-X document. Ideally we should have identical descriptions for identical items. However, different groups worked on similar sections and injected some different ideas. We now need review the differences and decide on what to make a standard. The organization of the Connector Specification is similar to that of the IBIS-X document. The Table for Contents shows the keywords. Bob noted that the location of [Manufacturer] needs to be discussed since it differs from IBIS Version 3.2. Sections 1 (General Introduction) and Section 2 (Statement of Intent) contain text that will probably be revised when the document is finalized. However, Section 2 gives a good start and needs to be reviewed. Section 3 (Revision History) currently contains entries to show changes while the document is evolving, but these will be removed upon release of the official Version 1.0. Bob noted some issues and observations in Secton 4 (General Syntax Rules and Guidelines): The file name paragraph is missing and should be added. The information was purposely moved in the Connector Specification document to the [File Name] keyword. Guideline 11 refers to some sample models. The samples are obsolete, and Bob feels that this section is not necessary or appropriate. Guidelines 12 and 13 give some addition numerical recommendations. This should be reviewed. A general Begin Header Guideline that is in the IBIS-X document is missing. (Adding Begin Header was done as a recent revision.) The statement in in IBIS-X allows for any text before [Begin Header] rather than just the default comment character. This was done to allow HTML tags to be used for Web formatting. Section 5 (Keyword Tree Diagram) is very helpful is probably necessary when reading the Connector Specification as a roadmap to show how keywords relate to each other. The tree itself reveals some issues. [Manufacturer] is listed twice. [Disclaimer] and [Copyright] are listed together. Bob showed how significant sections are now blocked by [Begin ..] [End ..] keywords. Stephen Peters stated that IBIS-X should also have a tree diagram section. Bob then covered Section 6 (Keywords). Section 6 should be called IBIS File Header and another section is needed for Global Keywords (such as the [Comment Char] keyword), similar to IBIS-X. Bob briefly pointed out some issues and observations in Section 6. The format for each keyword is similar to IBIS Version 3.2, except an Argument: line is added. Bob asked if [Notes] is global. Stephen thought is was just a Header keyword. Bob suggested checking with ibischk3. [Bob checked and it is just a header keyword that cannot be placed randomly in the file.] Due to merging of some text, a number of Header keywords need some extra text removed. The [IBIS Cn Model Ver] keyword is no longer the first keyword. It appears directly after the [Begin Header] keyword. As previously mentioned, [Disclaimer] and [Copyright] should be documented as two keywords in both the Connector Specification and the IBIS-X document. Some of the line and file length conditions are different. Both new documents have a common 120 character limit on each line. There are a number of editorial errors and incorrect entries (such as Text Block instead of Test String for Arguments) that can be handled off-line. This is revealed by direct comparison of the IBIS-X and Connector Specification documents. The [Notes] text needs to be changed since the new keyword [Redistribution Text] was added in case the new required keyword [Redistribution] is listed as "Specific". Bob pointed out that required [Redistribution] keyword allows EDA tools to automatically detect if a file can be sent anywhere ("Yes") or if it was provided by the vendor with restrictions (designated by "No" or "Specific"). This short review revealed that a more detailed examination is needed. Also some editorial changes can be identified. Bob and Stephen will work with Gus Panella to resolve and correct some of the differences noted so far. IBIS FUTURES (IBIS-X, API, BIRDxx) Stephen Peters reported on the IBIS Futures Working Group Meetings of April 3, 2001 and April 17, 2001. The Working Group meets bi-weekly, and the next meeting is scheduled on May 1, 2001. As previously mentioned, the IBIS Futures Working Group is interested in alignment with the IBIS Connector Specification. Stephen indicated that the Working Group needs to document what has been done. Anyone interested in technical writing is welcome to join and help out. The following documents are being written: IBIS-X Header Specification Macro Language Document Library Document for the IBIS Model section in IBIS-X format Bob Ross noted that a top level link has been added to the EIA IBIS Open Forum home page to the IBIS Futures Working Group documents. So far it contains minutes of meetings and a few older documents. Some more recent documents need to be uploaded. BIRD70.2 - GOLDEN WAVEFORMS Greg Edlund introduced the changes leading to BIRD70.2. Top-level keywords [Test Data] and [Test Load] were introduced. The [Test Data] section contains [Rising Waveform Near], [Rising Waveform Far], [Falling Waveform Near] and [Falling Waveform Far]. Greg added the Test_data_type and Test_load_type subparameters which have "Single-ended" or "Differential" arguments. He also expanded the differential load to include R_diff_near and R_diff_far. Larry Barnes asked where these were attached, and Greg responded that they attach to the nodes at each end of the transmission line. Greg also revised and added detail on timing correlation portion of BIRD70.2. Bob Ross commented that it was important to provide for differential golden waveforms in a very robust manner consistent with current technologies. This would take only a few additions to the base that has been established. The additions would include [Test Data] keywords and [Test Load] subparameters for the case of different inverting and non-inverting drivers and receivers: [Differential Waveform Near] [Differential Waveform Far] Driver_model_inverting Receiver_model_inverting Bob did not have time to study the timing parameters introduced in BIRD70.2. Issues still exist in this area. Also, other parameters might be needed for differential operation. Futhermore, all of the cases of Differential and Single-ended loads and data need to be examined for consistency. Greg stated that he wanted private feedback from EDA and semiconductor vendors concerning if there are any difficulties with providing the data or implementing the specified tests described in BIRD70.2. Roy Leventhal supported getting the input. IBISCHK3 BUG TRACKING (Other Pending BIRDs was moved to the end) Bob Ross reported that he contacted Atul Agarwal for a quote on the work he has done and will do to fix Bugs up through pending BUG56. The estimate was $3126. Bob thought this was reasonable and we should expect to pay Atul this year, upon completion. Bob stated Syed is still planning to upload the Linux executable for ibischk3 Version 3.2.7. - BUG54 - Corners with NA give Bad Test Load Warnings Bob Ross commented that he finally studied the test case given for BUG54 and the nature of BUG54. It documents that a Warning is properly not issued if [Pullup] table with 0 A entries is included. The Warning is incorrectly issued if this table is (correctly) omitted. Michael Mirmak confirmed that this is the case. There are other concerns regarding the interpretation of NA in min and max tables, but Michael wanted to simplify the issue to deal with the [Pullup] table problem. Bob concurred and felt that we should not try to deal with an any more general problem. The consensus was to fix BUG54 to eliminate the Warning message dependency on the [Pullup] table. - BUG56 Parser Fails to Detect Always Flowing Current Matthew Flora introduced BUG56 indicating that he has seen IBIS models with clamp tables documenting that currents are always flowing. Matthew feels that this is not what IBIS intended, nor does it represent how physical devices normally operate. Bob Ross stated that current sources were syntactically legal in IBIS and there was no reason to restrict them. However, Matthew's concerns were valid since in most devices the current does shut down or change direction at some point in an I-V table. It is most likely to be a model error if this is not the case. Larry Barnes indicated that current sources could exist in terminators. Bob proposed that a Warning could be issued if the current in an I-V table did not cross zero or did not approach zero to within some reasonably low (noise) value. Al Davis stated that [Gnd Clamp] tables and [Power Clamp] tables should cross 0 A at a common point and that current sources were not proper. Since we were running out of time, we did not reach closure on how to resolve BUG56. This discussion will be continued at the next meeting. OTHER PENDING BIRDS (moved to the end) Bob Ross outlined very briefly some of the needed BIRDs. We need a possible fallback submodel BIRD that is decoupled from another one discussed previously for [Driver Schedule] improvement for SCSI operation is needed. We also need the PCI BIRD and the SSO BIRD. NEXT MEETING: The next teleconference meeting will be on Friday, May 11, 2001, from 8:00 AM to 10:00 AM. Stephen Peters will chair this meeting. ============================================================================== 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 stephen.peters@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@innoveda.com Senior Manager, Innoveda 1369 Del Norte Rd. Camarillo, CA 93010-8437 LIBRARIAN: Roy Leventhal (837) 797-2152, Fax: (847) 222-2799 roy_leventhal@3com.com Senior Engineer, CommWorks Corp. (a wholly owned 3Com subsidiary) 1800 W. Central Rd. Mt. Prospect, IL 60056-2293 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 869-2320, Fax: (425) 881-1008 jangulo@innoveda.com Development Engineer, Innoveda 14715 N.E. 95th Street, Suite 200 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.eigroup.org/ibis/ibis.htm Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Tue Apr 24 08:42:55 2001 Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3OFgrb27090 for ; Tue, 24 Apr 2001 08:42:54 -0700 (PDT) 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 LAA14757 for ; Tue, 24 Apr 2001 11:42:14 -0400 (EDT) Received: from taurus.camarillo.innoveda.com (taurus.camarillo.innoveda.com [139.181.194.20]) by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id LAA06827 for ; Tue, 24 Apr 2001 11:42:13 -0400 (EDT) Received: from f22.innoveda.com (f22.camarillo.innoveda.com [139.181.194.48]) by taurus.camarillo.innoveda.com (8.9.3/8.9.3) with SMTP id IAA29095 for ; Tue, 24 Apr 2001 08:42:09 -0700 (PDT) Received: by f22.innoveda.com (SMI-8.6/SMI-SVR4) id IAA03101; Tue, 24 Apr 2001 08:42:10 -0700 Date: Tue, 24 Apr 2001 08:42:10 -0700 From: guy@camarillo.innoveda.com (Guy de Burgh) Message-Id: <200104241542.IAA03101@f22.innoveda.com> To: ibis@eda.org Subject: DAC 2001 IBIS Meeting Announcement D A C 2 0 0 1 I B I S S U M M I T M E E T I N G F I R S T A N N O U N C E M E N T DATE: Thursday, June 21, 2001 TIME: 8:30 AM - 5:00 PM CITY: Las Vegas, Nevada LOCATION: Las Vegas Hilton Hotel (adjacent to the Convention Center) ROOM: To be Announced LUNCH: Free Refreshments and Lunch will be provided. AGENDA: The agenda is being planned. Some planned items are: Election of Officers for 2001 - 2002 Connector Specification IBIS-X IBIS Version 4.0 Issues Possibly other topics such as enhanced buffer extraction and driver schedule modeling. We welcome presentations and discussions on IBIS topics. DAC 2001: DAC is scheduled Monday - Friday, June 18 - 22, 2001. The exhibitor portion is open from Monday - Wednesday. For more information on DAC 2001 activities, housing, etc., visit the DAC URL: DAC URL: http://www.dac.com/ CALL FOR PRESENTATIONS: We are also open to technical presentations (usually 30 minutes or less) related to any current IBIS activity and to future IBIS needs. Contact Guy de Burgh regarding your presentation: Presenter: Title: Estimated Time: Please plan to use regular overhead slides for the presentation. It is possible that an LCD projector will be available, but do not assume this to be so at this time. We would like you to provide handouts for the meeting (about 25) and also an electronic copy for archiving. CALL FOR ATTENDEES: Please let Guy de Burgh know if you are planning to attend so we have an estimate on food requirements. CONTACT: Guy de Burgh IBIS Secretary gdeburgh@innoveda.com (805) 988-8250 ext. 6823 From owner-ibis Wed Apr 25 16:55:26 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3PNtM907034 for ; Wed, 25 Apr 2001 16:55:25 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA04033; Wed, 25 Apr 2001 16:54:46 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSKBH15T; Wed, 25 Apr 2001 16:54:50 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3AE763C3.554CE1C2@mentor.com> Date: Wed, 25 Apr 2001 16:54:43 -0700 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 - EMC Document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: For your information and reference, an unofficial draft of a document being developed for EMC modeling has been uploaded for review under http://www.eda.org/pub/ibis/emc/ The document is ICEMmodel.doc. Some other related material has also been uploaded. This official document will contain editorial revisions per some IEC Guidelines and will be issued later. Comments are welcome. Bob Ross Mentor Graphics. From owner-ibis Fri Apr 27 01:40:14 2001 Received: from orion.crisa.es (orion.crisa.es [195.53.91.2]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3R8eBj11177 for ; Fri, 27 Apr 2001 01:40:12 -0700 (PDT) Received: from [192.168.5.117] (helo=casiopea) by orion.crisa.es with smtp (Exim 3.02 #1) id 14t5fv-0003Rj-00 for ibis@eda.org; Fri, 27 Apr 2001 10:40:35 +0000 From: "=?iso-8859-1?Q?Enrique_Mart=EDn_Adalid?=" To: Subject: Looking for IBIS models Date: Fri, 27 Apr 2001 10:43:20 +0200 Message-ID: <000001c0cef6$1caa1880$7505a8c0@casiopea.crisa.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 I´m looking for IBIS models -whose manufacturers don´t appear in your excellent page (eigroup.org)-. Exactly: - Temic (or Atmel) MG2T technology - White Electronics Design WMS512K8 and WS512K38 Any Suggestion? Best Regards, E. Martin Adalid eadalid@crisa.es From owner-ibis Mon Apr 30 15:20:36 2001 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.11.0/8.11.0) with ESMTP id f3UMKXj27511 for ; Mon, 30 Apr 2001 15:20:35 -0700 (PDT) Received: from svr-orw-exc-02.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id PAA22906; Mon, 30 Apr 2001 15:19:54 -0700 (PDT) Received: from mentor.com (bob.wv.mentorg.com [147.34.83.63]) by svr-orw-exc-02.wv.mentorg.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSKBHLYF; Mon, 30 Apr 2001 15:20:04 -0700 Sender: bobr@relay1.mentorg.com Message-ID: <3AEDE507.F1A54E6E@mentor.com> Date: Mon, 30 Apr 2001 15:19:51 -0700 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 CC: stephen.peters@intel.com Subject: IBIS BIRD71 - Timing Test Loads in [Model Spec] to Support PCI & PCI-X Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IBIS Committee: Stephen Peters is submitting BIRD71 for consideration in IBIS Version 4.0. Bob Ross Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 71 ISSUE TITLE: Timing Test Loads in [Model Spec] to Support PCI & PCI-X REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: April 30, 2001 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The IBIS specification lacks a way to specify minimum and maximum values for timing test load parameters. In addition, the current set of timing test load parameters (Cref, Rref) are applied to both edges of an output waveform, thus making them inadequate for describing the timing tests loads used by the PCI-X bus specification. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following additional subparameters are added to the [Model Spec] keyword: Cref, Rref, Vref_rising, Vref_falling, Cref_rising, Cref_falling, Rref_rising, Rref_falling, Vmeas_rising, Vmeas_falling. Changes and additions to the [Model Spec] keyword are shown by the |* lines |============================================================================= | 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, Cref, Rref, Cref_rising, Cref_falling, Rref_rising, |* Rref_falling, Vref_rising, Vref_falling, Vmeas_rising, |* Vmeas_falling. | 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 |* Cref Timing specification capacitive load |* Rref Timing specification resistance load |* Cref_rising Timing spec capacitive load for rising edges |* Cref_falling Timing spec capacitive load for falling edges |* Rref_rising Timing spec resistance load for rising edges |* Rref_falling Timing spec resistance load for falling edges |* Vref_rising Timing spec test load voltage for rising edges |* Vref_falling Timing spec test load voltage for falling edges |* Vmeas_rising Measurement voltage for rising edge timing |* measurements |* Vmeas_falling Measurement voltage for falling edge timing |* measurements | | 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, Vref, Cref, Rref rules: |* |* The Vmeas, Vref, Cref and Rref values under the [Model Spec] |* keyword override their respective values entered elsewhere. |* Note that a Vmeas, Vref, Cref or Rref subparameters may not be |* used if its edge specific version (*_rising or *_falling) is |* used. |* |* Cref_rising, Cref_falling, Rref_rising, Rref_falling, |* Vref_rising, Vref_falling, Vmeas_rising, Vmeas_falling rules: |* |* Use these subparameters when specifying separate timing test |* loads and voltages for rising and falling edges. If one |* 'rising' or 'falling' subparameter is used, then the |* corresponding 'rising' or 'falling' subparameter must be |* present. The values listed in these subparameters override any |* corresponding Cref, Vref, Rref or Vmeas values entered |* 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 | | Timing test load voltage reference example | Vref 1.25 1.15 1.35 | An SSTL-2 example | |* BEGIN ADDED EXAMPLE |* |* rising and falling timing test load example (values from PCI-X spec) |* Cref_falling 10p 10p 10p Cref_rising 10p 10p 10p Rref_rising 25 500 25 | typ value not specified Rref_falling 25 500 25 | typ value not specified Vref_rising 0 1.5 0 Vref_falling 3.3 1.5 3.6 Vmeas_rising 0.941 0.885 1.026 | vmeas = 0.285(vcc) Vmeas_falling 2.0295 1.845 2.214 | vmeas = 0.615(vcc) |* |* |* END ADDED EXAMPLE |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDxx is issued because of a long standing problem with specifying PCI compliant drivers. In PCI 2.2, minimum timing values are specified into a 0pF load, while maximum timing parameters are specified into a 50pF load. There was no way to specify this cleanly in IBIS. In addition, the PCI-X specification goes even further in specifying separate timing test loads for maximum rising and falling edges, and a single test load for the minimum case. In order to satisy the PCI-X spec all eight variations of Cref, Vref, Rref and Vmeas has to be included. Note that the PCI-X minimum test load is represented by it's Thevinen equivalent. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ******************************************************************************