From owner-ibis Wed May 5 15:09:15 1999 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA08069 for ; Wed, 5 May 1999 15:09:14 -0700 (PDT) Received: from pcocd2.intel.com (pcocd2.intel.com [132.233.250.145]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id PAA23646 for ; Wed, 5 May 1999 15:03:33 -0700 (PDT) Received: from fri2012 (fri2012-57.fm.intel.com [10.1.57.39]) by pcocd2.intel.com (8.9.1a/8.9.1+p1/d: pcocd2.m4,v 1.4 1990/03/11 18:13:40 jcampbel Exp jcampbel $) with SMTP id PAA23582 for ; Wed, 5 May 1999 15:03:32 -0700 (PDT) From: Arpad Muranyi - PCD~ Received: by fri2012 (AIX 4.1/UCB 5.64/FMDT-RS6000) id AA163600; Wed, 5 May 1999 15:03:32 -0700 Date: Wed, 5 May 1999 15:03:32 -0700 Message-Id: <990505150332.ZM93964@fri2012.fm.intel.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: ibis@eda.org Subject: BIRD58.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.1990505150331.ZM93964.fm.intel.com" --PART-BOUNDARY=.1990505150331.ZM93964.fm.intel.com Content-Type: application/octet-stream ; name="BIRD58_1.TXT" Content-Transfer-Encoding: base64 Content-Disposition: attachment ; filename="BIRD58_1.TXT" X-Zm-Content-Name: BIRD58_1.TXT X-Zm-Decoding-Hint: mimencode -b -u VG8gYWxsIElCSVMgZmFucyBpbnRlcmVzdGVkLA0KDQpJIGFwb2xvZ2l6ZSBmb3IgdGhlIGRl bGF5IGluIHdyaXRpbmcgdGhpcyBpdGVyYXRpb24gb2YgQklSRDU4LiAgSW4gdGhpcw0KZG9j dW1lbnQgSSBhbSBhdHRlbXB0aW5nIHRvIGNvbWJpbmUgYWxsIHJlc3BvbnNlcyBJIHJlY2Vp dmVkIGFmdGVyIGlzc3VpbmcNCnRoZSBvcmlnaW5hbCBCSVJELiAgSSBob3BlIHRoaXMgaXRl cmF0aW9uIHdpbGwgYmUgbW9yZSBhY2NlcHRhYmxlLg0KDQpUaGFua3MsDQoNCkFycGFkDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCg0KQklSRCBJRCM6ICAgICAgICA1OC4xDQpJU1NV RSBUSVRMRTogICAgIERyaXZlciBTY2hlZHVsZSBrZXl3b3JkIGNsYXJpZmljYXRpb24NClJF UVVFU1RFUjogICAgICAgQXJwYWQgTXVyYW55aSwgSW50ZWwgQ29ycG9yYXRpb24NCkRBVEUg U1VCTUlUVEVEOiAgMy8yLzk5LCA1LzUvOTkNCkRBVEUgQUNDRVBURUQgQlkgSUJJUyBPUEVO IEZPUlVNOiAgcGVuZGluZw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KDQpTVEFURU1FTlQgT0YgVEhFIElTU1VFOg0KDQpUaGUgW0Ry aXZlciBTY2hlZHVsZV0gc2VjdGlvbiBvZiB0aGUgbGF0ZXN0IElCSVMgc3BlY2lmaWNhdGlv biAodjMuMikgZG9lcw0Kbm90IHByb3ZpZGUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHRoZSBt b2RlbCBtYWtlciBhbmQgRURBIHRvb2wgdmVuZG9yIG9uDQplc3NlbnRpYWwgZGV0YWlscyBv ZiB0aGlzIGtleXdvcmQuICBUaGUgc3BlYy4gY2FuIGJlIGludGVycHJldGVkIGluIHNldmVy YWwNCmRpZmZlcmVudCB3YXlzIHdoaWNoIGNhbiBsZWFkIHRvIHNlcmlvdXMgZGlzY3JlcGFu Y2llcyBhbmQgY29uc2VxdWVuY2VzLg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K DQpTVEFURU1FTlQgT0YgVEhFIFJFU09MVkVEIFNQRUNJRklDQVRJT05TOg0KDQpPbmUgcGFy YWdyYXBoIGZyb20gQklSRDM1LjMgaXMgaW5jbHVkZWQgaW4gdGhlIFtEcml2ZXIgU2NoZWR1 bGVdIHVzYWdlIHJ1bGVzDQpzZWN0aW9uIG9mIHRoZSBzcGVjaWZpY2F0aW9uLiAgVGhpcyBw b3J0aW9uIHNlZW1zIHRvIGhhdmUgYmVlbg0KaW5hZHZlcnRlbnRseSBsZWZ0IG91dCBmcm9t IHRoZSBzcGVjLiBhbmQgZXhwbGFpbnMgbW9zdCBvZiB0aGUgZ3JheSBhcmVhcy4NCg0KSW4g YWRkaXRpb24gdG8gdGhpcyBtaXNzaW5nIHBhcmFncmFwaCwgc29tZSBjaGFuZ2VzIGhhdmUg YmVlbiBtYWRlIHRvIHRoZSANCndvcmRpbmcgb2YgdGhlIGRlc2NyaXB0aW9uIG9mIHRoaXMg a2V5d29yZCBmb3IgY2xhcml0eS4NCg0KVGhlIGFkZGl0aW9uYWwgd29yZHMgZG8gbm90IGNo YW5nZSB0aGUgb3JpZ2luYWwgaW50ZW50IGJlaGluZCB0aGlzIGtleXdvcmQuIA0KSXQgaXMg b25seSBhZGRlZCB0byBzcGVsbCBvdXQgaG93IHRoZSBrZXl3b3JkIG11c3QgYmUgdXNlZCBz byB0aGF0IHRoZSBtb2RlbA0KbWFrZXIgYW5kIEVEQSB0b29sIHZlbmRvciBjb3VsZCBiZSBp biBhZ3JlZW1lbnQgb24gaG93IHRoZSBtb2RlbCB3b3Jrcy4NCg0KVGhlIG5ldyBzZWN0aW9u KHMpIGFyZSBtYXJrZWQgd2l0aCBhICIqIiBjaGFyYWN0ZXIgYXQgdGhlIGJlZ2lubmluZyBv ZiBlYWNoDQpsaW5lLg0KDQp8PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnwgICAgIEtleXdv cmQ6ICBbRHJpdmVyIFNjaGVkdWxlXQ0KfCAgICBSZXF1aXJlZDogIE5vDQp8IERlc2NyaXB0 aW9uOiAgRGVzY3JpYmVzIHRoZSByZWxhdGl2ZSBtb2RlbCBzd2l0Y2hpbmcgc2VxdWVuY2Ug Zm9yIHJlZmVyZW5jZWQNCnwgICAgICAgICAgICAgICBtb2RlbHMgdG8gcHJvZHVjZSBhIG11 bHRpLXN0YWdlZCBkcml2ZXIuDQp8IFVzYWdlIFJ1bGVzOiAgVGhlIFtEcml2ZXIgc2NoZWR1 bGVdIGtleXdvcmQgZXN0YWJsaXNoZXMgYSBoaWVyYXJjaGljYWwgb3JkZXINCnwgICAgICAg ICAgICAgICBiZXR3ZWVuIG1vZGVscyBhbmQgc2hvdWxkIGJlIHBsYWNlZCB1bmRlciB0aGUg W01vZGVsXSB3aGljaCANCnwgICAgICAgICAgICAgICBhY3RzIGFzIHRoZSB0b3AtbGV2ZWwg bW9kZWwuICBUaGUgc2NoZWR1bGVkIG1vZGVscyBhcmUgdGhlbiANCnwgICAgICAgICAgICAg ICByZWZlcmVuY2VkIGZyb20gdGhlIHRvcC1sZXZlbCBtb2RlbCBieSB0aGUgW0RyaXZlciBT Y2hlZHVsZV0NCnwgICAgICAgICAgICAgICBrZXl3b3JkLg0KfA0KfCogICAgICAgICAgICAg IFdoZW4gYSBtdWx0aS1zdGFnZWQgYnVmZmVyIGlzIG1vZGVsZWQgdXNpbmcgdGhlIFtEcml2 ZXINCnwqICAgICAgICAgICAgICBTY2hlZHVsZV0ga2V5d29yZCwgYWxsIG9mIGl0cyBzdGFn ZXMgKGluY2x1ZGluZyB0aGUgZmlyc3QNCnwqICAgICAgICAgICAgICBzdGFnZSwgb3Igbm9y bWFsIGRyaXZlcikgaGF2ZSB0byBiZSBtb2RlbGVkIGFzIHNjaGVkdWxlZA0KfCogICAgICAg ICAgICAgIG1vZGVscy4NCnwqDQp8KiAgICAgICAgICAgICAgSWYgdGhlcmUgaXMgc3VwcG9y dCBmb3IgdGhpcyBmZWF0dXJlIGluIGEgc2ltdWxhdG9yLCB0aGUNCnwqICAgICAgICAgICAg ICBbRHJpdmVyIFNjaGVkdWxlXSBrZXl3b3JkIHdpbGwgY2F1c2UgaXQgdG8gdXNlIHRoZQ0K fCogICAgICAgICAgICAgIFtQdWxsZG93bl0sIFtQdWxsZG93biBSZWZlcmVuY2VdLCBbUHVs bHVwXSwgW1B1bGx1cA0KfCogICAgICAgICAgICAgIFJlZmVyZW5jZV0sIFtWb2x0YWdlIFJh bmdlXSwgW1JhbXBdLCBbUmlzaW5nIFdhdmVmb3JtXSBhbmQNCnwqICAgICAgICAgICAgICBb RmFsbGluZyBXYXZlZm9ybV0ga2V5d29yZHMgZnJvbSB0aGUgc2NoZWR1bGVkIG1vZGVscw0K fCogICAgICAgICAgICAgIGluc3RlYWQgb2YgdGhlIHRvcC1sZXZlbCBtb2RlbCwgYWNjb3Jk aW5nIHRvIHRoZSB0aW1pbmcNCnwqICAgICAgICAgICAgICByZWxhdGlvbnNoaXBzIGRlc2Ny aWJlZCBpbiB0aGUgW0RyaXZlciBTY2hlZHVsZV0ga2V5d29yZC4gDQp8KiAgICAgICAgICAg ICAgQ29uc2VxdWVudGx5LCB0aGUga2V5d29yZHMgaW4gdGhlIGFib3ZlIGxpc3Qgd2lsbCBi ZSBpZ25vcmVkDQp8KiAgICAgICAgICAgICAgaW4gdGhlIHRvcC1sZXZlbCBtb2RlbC4gIEFs c28sIGFsbCBvdGhlciBrZXl3b3JkcyBub3Qgc2hvd24NCnwqICAgICAgICAgICAgICBpbiB0 aGUgYWJvdmUgbGlzdCB3aWxsIGJlIGlnbm9yZWQgaW4gdGhlIHNjaGVkdWxlZCBtb2RlbChz KS4NCnwqDQp8KiAgICAgICAgICAgICAgSG93ZXZlciwgYm90aCB0aGUgdG9wLWxldmVsIGFu ZCB0aGUgc2NoZWR1bGVkIG1vZGVsKHMpIGhhdmUNCnwqICAgICAgICAgICAgICB0byBiZSBj b21wbGV0ZSBtb2RlbHMsIGkuZS4gdGhleSBoYXZlIHRvIG9iZXkgYWxsIHJ1bGVzIG9mDQp8 KiAgICAgICAgICAgICAga2V5d29yZCByZXF1aXJlbWVudHMuDQp8Kg0KfCogICAgICAgICAg ICAgIEZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSByZWFzb25zIGFuZCBmb3Igc2ltdWxh dG9ycyB3aGljaA0KfCogICAgICAgICAgICAgIGRvIG5vdCBzdXBwb3J0IG11bHRpLXN0YWdl ZCBzd2l0Y2hpbmcsIHRoZSBrZXl3b3JkcyBpbiB0aGUNCnwqICAgICAgICAgICAgICBhYm92 ZSBsaXN0IGNhbiBiZSB1c2VkIGluIHRoZSB0b3AtbGV2ZWwgW01vZGVsXSB0byBkZXNjcmli ZQ0KfCogICAgICAgICAgICAgIHRoZSBvdmVyYWxsIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUg YnVmZmVyIGFzIGlmIGl0IHdhcyBhDQp8KiAgICAgICAgICAgICAgY29tcG9zaXRlIG1vZGVs LiAgSXQgaXMgbm90IGd1YXJhbnRlZWQsIGhvd2V2ZXIsIHRoYXQgc3VjaCBhDQp8KiAgICAg ICAgICAgICAgdG9wLWxldmVsIG1vZGVsIHdpbGwgeWllbGQgdGhlIHNhbWUgc2ltdWxhdGlv biByZXN1bHRzIGFzIGENCnwqICAgICAgICAgICAgICBmdWxsIG11bHRpLXN0YWdlIG1vZGVs LiAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhICJnb2xkZW4NCnwgICAgICAgICAgICAgICB3 YXZlZm9ybSIgZm9yIHRoZSBkZXZpY2UgY29uc2lzdGluZyBvZiBhIFtSaXNpbmcgV2F2ZWZv cm1dDQp8ICAgICAgICAgICAgICAgdGFibGUgYW5kIGEgW0ZhbGxpbmcgV2F2ZWZvcm1dIHRh YmxlIGJlIHN1cHBsaWVkIGluIHRoZQ0KfCAgICAgICAgICAgICAgIHRvcC1sZXZlbCBtb2Rl bCB0byBzZXJ2ZSBhcyBhIHJlZmVyZW5jZSBmb3IgdmFsaWRhdGlvbi4NCnwNCnwqICAgICAg ICAgICAgICBFdmVuIHRob3VnaCBzb21lIG9mIHRoZSBrZXl3b3JkcyBhcmUgaWdub3JlZCBp biB0aGUNCnwqICAgICAgICAgICAgICBzY2hlZHVsZWQgbW9kZWwsIGl0IG1heSBzdGlsbCBt YWtlIHNlbnNlIGluIHNvbWUgY2FzZXMgdG8NCnwqICAgICAgICAgICAgICBzdXBwbHkgY29y cmVjdCBkYXRhIHdpdGggdGhlbS4gIE9uZSBzdWNoIHNpdHVhdGlvbiB3b3VsZA0KfCogICAg ICAgICAgICAgIGFyaXNlIHdoZW4gYSBbTW9kZWxdIGlzIHVzZWQgYm90aCBhcyBhIHJlZ3Vs YXIgdG9wLWxldmVsDQp8KiAgICAgICAgICAgICAgbW9kZWwgYXMgd2VsbCBhcyBhIHNjaGVk dWxlZCBtb2RlbC4NCnwNCnwNCnwgICAgICAgICAgICAgICBUaGUgW0RyaXZlciBTY2hlZHVs ZV0gdGFibGUgY29uc2lzdHMgb2YgZml2ZSBjb2x1bW5zLiAgVGhlDQp8ICAgICAgICAgICAg ICAgZmlyc3QgY29sdW1uIGNvbnRhaW5zIHRoZSBtb2RlbCBuYW1lcyBvZiBvdGhlciBtb2Rl bHMgdGhhdA0KfCAgICAgICAgICAgICAgIGV4aXN0cyBpbiB0aGUgLmlicyBmaWxlLiAgVGhl IHJlbWFpbmluZyBmb3VyIGNvbHVtbnMgZGVzY3JpYmUNCnwgICAgICAgICAgICAgICBkZWxh eXM6ICBSaXNlX29uX2RseSwgUmlzZV9vZmZfZGx5LCBGYWxsX29uX2RseSwgYW5kDQp8KiAg ICAgICAgICAgICAgRmFsbF9vZmZfZGx5LiAgQWxsIHZhbHVlcyBhcmUgcmVmZXJlbmNlZCB0 byAwIHNlY29uZHMgZm9yDQp8ICAgICAgICAgICAgICAgdGhlIHN0YXJ0IG9mIHRoZSByaXNp bmcgdHJhbnNpdGlvbiBhbmQgMCBzZWNvbmRzIGZvciB0aGUNCnwgICAgICAgICAgICAgICBz dGFydCBvZiB0aGUgZmFsbGluZyB0cmFuc2l0aW9uLiAgQWxsIGRlbGF5cyBtdXN0IGJlIGVx dWFsDQp8KiAgICAgICAgICAgICAgdG8gb3IgZ3JlYXRlciB0aGFuIDAuICBUaGVyZSBhcmUg b25seSBmaXZlIHZhbGlkDQp8KiAgICAgICAgICAgICAgY29tYmluYXRpb25zIGluIHdoaWNo IHRoZXNlIHBhcmFtZXRlcnMgY2FuIGJlIHVzZWQ6DQp8Kg0KfCogICAgICAgICAgICAgICAg ICAxKSAgUmlzZV9vbl9kbHkgICB3aXRoICAgRmFsbF9vbl9kbHkNCnwqICAgICAgICAgICAg ICAgICAgMikgIFJpc2Vfb2ZmX2RseSAgd2l0aCAgIEZhbGxfb2ZmX2RseQ0KfCogICAgICAg ICAgICAgICAgICAzKSAgUmlzZV9vbl9kbHkgICB3aXRoICAgUmlzZV9vZmZfZGx5DQp8KiAg ICAgICAgICAgICAgICAgIDQpICBGYWxsX29uX2RseSAgIHdpdGggICBGYWxsX29uX2RseQ0K fCogICAgICAgICAgICAgICAgICA1KSAgQWxsIGZvdXIgZGVsYXlzIGRlZmluZWQNCnwqICAg ICAgICAgICAgICAgICAgICAgIChiZSBjYXJlZnVsIGFib3V0IGNvcnJlY3Qgc2VxdWVuY2lu ZykNCnwqDQp8KiAgICAgICAgICAgICAgVGhlIGZvdXIgZGVsYXkgcGFyYW1ldGVycyBoYXZl IHRoZSBtZWFuaW5nIGFzIGRlc2NyaWJlZA0KfCogICAgICAgICAgICAgIGJlbG93LiAgKE5v dGUgdGhhdCB0aGlzIGRlc2NyaXB0aW9uIGFwcGxpZXMgdG8gYnVmZmVyIHR5cGVzDQp8KiAg ICAgICAgICAgICAgd2hpY2ggaGF2ZSBib3RoIHB1bGx1cCBhbmQgcHVsbGRvd24gc3RydWN0 dXJlcy4gIEZvciB0aG9zZQ0KfCogICAgICAgICAgICAgIGJ1ZmZlciB0eXBlcyB3aGljaCBo YXZlIG9ubHkgYSBwdWxsdXAgb3IgcHVsbGRvd24gc3RydWN0dXJlLA0KfCogICAgICAgICAg ICAgIHRoZSBkZXNjcmlwdGlvbiBmb3IgdGhlIG1pc3NpbmcgcGFydCBjYW4gYmUgb21pdHRl ZC4pDQp8Kg0KfCogICAgICAgICAgICAgIEZhbGxfb25fZGx5IGlzIHRoZSBhbW91bnQgb2Yg dGltZSB0aGF0IGVsYXBzZXMgZnJvbSB0aGUNCnwqICAgICAgICAgICAgICBpbnRlcm5hbCBz aW11bGF0b3IgcHVsc2UgaW5pdGlhdGluZyBhIEZBTExJTkcgZWRnZSBhbmQgdGhlDQp8KiAg ICAgICAgICAgICAgdD0wIHRpbWUgb2YgdGhlIHdhdmVmb3JtIG9yIHJhbXAgdGhhdCB0dXJu cyB0aGUgSVYgY3VydmUgb2YNCnwqICAgICAgICAgICAgICB0aGUgUFVMTERPV04gZGV2aWNl IE9OLCBhbmQgdGhlIHQ9MCB0aW1lIG9mIHRoZSB3YXZlZm9ybSBvcg0KfCogICAgICAgICAg ICAgIHJhbXAgdGhhdCB0dXJucyB0aGUgSVYgY3VydmUgb2YgdGhlIFBVTExVUCBkZXZpY2Ug T0ZGIChpZg0KfCogICAgICAgICAgICAgIHRoZXkgd2VyZSBub3QgdHVybmVkIE9OIGFuZCBP RkYgYnkgYW5vdGhlciBldmVudCB5ZXQsDQp8KiAgICAgICAgICAgICAgcmVzcGVjdGl2ZWx5 KS4NCnwqDQp8KiAgICAgICAgICAgICAgRmFsbF9vZmZfZGx5IGlzIHRoZSBhbW91bnQgb2Yg dGltZSB0aGF0IGVsYXBzZXMgZnJvbSB0aGUNCnwqICAgICAgICAgICAgICBpbnRlcm5hbCBz aW11bGF0b3IgcHVsc2UgaW5pdGlhdGluZyBhIEZBTExJTkcgZWRnZSBhbmQgdGhlDQp8KiAg ICAgICAgICAgICAgdD0wIHRpbWUgb2YgdGhlIHdhdmVmb3JtIG9yIHJhbXAgdGhhdCB0dXJu cyB0aGUgSVYgY3VydmUgb2YNCnwqICAgICAgICAgICAgICB0aGUgUFVMTERPV04gZGV2aWNl IE9GRiwgYW5kIHRoZSB0PTAgdGltZSBvZiB0aGUgd2F2ZWZvcm0gb3INCnwqICAgICAgICAg ICAgICByYW1wIHRoYXQgdHVybnMgdGhlIElWIGN1cnZlIG9mIHRoZSBQVUxMVVAgZGV2aWNl IE9OIChpZg0KfCogICAgICAgICAgICAgIHRoZXkgd2VyZSBub3QgdHVybmVkIE9GRiBhbmQg T04gYnkgYW5vdGhlciBldmVudCB5ZXQsDQp8KiAgICAgICAgICAgICAgcmVzcGVjdGl2ZWx5 KS4NCnwqDQp8KiAgICAgICAgICAgICAgUmlzZV9vbl9kbHkgaXMgdGhlIGFtb3VudCBvZiB0 aW1lIHRoYXQgZWxhcHNlcyBmcm9tIHRoZQ0KfCogICAgICAgICAgICAgIGludGVybmFsIHNp bXVsYXRvciBwdWxzZSBpbml0aWF0aW5nIGEgUklTSU5HIGVkZ2UgYW5kIHRoZQ0KfCogICAg ICAgICAgICAgIHQ9MCB0aW1lIG9mIHRoZSB3YXZlZm9ybSBvciByYW1wIHRoYXQgdHVybnMg dGhlIElWIGN1cnZlIG9mDQp8KiAgICAgICAgICAgICAgdGhlIFBVTExVUCBkZXZpY2UgT04s IGFuZCB0aGUgdD0wIHRpbWUgb2YgdGhlIHdhdmVmb3JtIG9yDQp8KiAgICAgICAgICAgICAg cmFtcCB0aGF0IHR1cm5zIHRoZSBJViBjdXJ2ZSBvZiB0aGUgUFVMTERPV04gZGV2aWNlIE9G RiAoaWYNCnwqICAgICAgICAgICAgICB0aGV5IHdlcmUgbm90IHR1cm5lZCBPTiBhbmQgT0ZG IGJ5IGFub3RoZXIgZXZlbnQgeWV0LA0KfCogICAgICAgICAgICAgIHJlc3BlY3RpdmVseSku DQp8Kg0KfCogICAgICAgICAgICAgIFJpc2Vfb2ZmX2RseSBpcyB0aGUgYW1vdW50IG9mIHRp bWUgdGhhdCBlbGFwc2VzIGZyb20gdGhlDQp8KiAgICAgICAgICAgICAgaW50ZXJuYWwgc2lt dWxhdG9yIHB1bHNlIGluaXRpYXRpbmcgYSBSSVNJTkcgZWRnZSBhbmQgdGhlDQp8KiAgICAg ICAgICAgICAgdD0wIHRpbWUgb2YgdGhlIHdhdmVmb3JtIG9yIHJhbXAgdGhhdCB0dXJucyB0 aGUgSVYgY3VydmUgb2YNCnwqICAgICAgICAgICAgICB0aGUgUFVMTFVQIGRldmljZSBPRkYs IGFuZCB0aGUgdD0wIHRpbWUgb2YgdGhlIHdhdmVmb3JtIG9yDQp8KiAgICAgICAgICAgICAg cmFtcCB0aGF0IHR1cm5zIHRoZSBJViBjdXJ2ZSBvZiB0aGUgUFVMTERPV04gZGV2aWNlIE9O IChpZg0KfCogICAgICAgICAgICAgIHRoZXkgd2VyZSBub3QgdHVybmVkIE9OIGFuZCBPRkYg YnkgYW5vdGhlciBldmVudCB5ZXQsDQp8KiAgICAgICAgICAgICAgcmVzcGVjdGl2ZWx5KS4N CnwqDQp8KiAgICAgICAgICAgICAgTm90ZSB0aGF0IHNvbWUgdGltaW5nIGNvbWJpbmF0aW9u cyBtYXkgb25seSBiZSBwb3NzaWJsZSBpZg0KfCogICAgICAgICAgICAgIHRoZSB0d28gaGFs dmVzIG9mIGEgY29tcGxlbWVudGFyeSBidWZmZXIgYXJlIG1vZGVsZWQgDQp8KiAgICAgICAg ICAgICAgc2VwYXJhdGVseSBhcyB0d28gb3Blbl8qIG1vZGVscy4NCnwNCnwNCnwgICAgICAg ICAgICAgICBVc2UgJ05BJyB3aGVuIG5vIHRyYW5zaXRpb24gaXMgYXBwbGljYWJsZS4gIEZv ciBlYWNoIG1vZGVsLA0KfCAgICAgICAgICAgICAgIHRoZSB0cmFuc2l0aW9uIHNlcXVlbmNl IG11c3QgYmUgY29tcGxldGUsIGkuZS4sIGl0IG11c3Qgc3RhcnQNCnwgICAgICAgICAgICAg ICBhbmQgZW5kIGF0IHRoZSBzYW1lIHN0YXRlLiAgDQp8DQp8ICAgICAgICAgICAgICAgTm8g W0RyaXZlciBTY2hlZHVsZV0gbWF5IHJlZmVyZW5jZSBhIG1vZGVsIHdoaWNoIGl0c2VsZiBo YXMNCnwgICAgICAgICAgICAgICB3aXRoaW4gaXQgYSBbRHJpdmVyIFNjaGVkdWxlXSB0YWJs ZSBrZXl3b3JkLg0KfA0KfCBPdGhlciBOb3RlczogIFRoZSBhZGRlZCBtb2RlbHMgdHlwaWNh bGx5IGNvbnNpc3Qgb2YgT3Blbl9zaW5rIChPcGVuX2RyYWluKSANCnwgICAgICAgICAgICAg ICBvciBPcGVuX3NvdXJjZSBtb2RlbHMgdG8gcHJvdmlkZSBzZXF1ZW50aWFsbHkgaW5jcmVh c2VkIGRyaXZlDQp8ICAgICAgICAgICAgICAgc3RyZW5ndGhzLiAgVGhlIGFkZGVkIGRyaXZl IG1heSBiZSByZW1vdmVkIHdpdGhpbiB0aGUgc2FtZQ0KfCAgICAgICAgICAgICAgIHRyYW5z aXRpb24gZm9yIGEgbW9tZW50YXJ5IGJvb3N0IG9yIGR1cmluZyB0aGUgb3Bwb3NpdGUgDQp8 ICAgICAgICAgICAgICAgdHJhbnNpdGlvbi4NCnwNCnwgICAgICAgICAgICAgICBUaGUgc3lu dGF4IGFsc28gYWxsb3dzIGZvciByZWR1Y2luZyB0aGUgZHJpdmUgc3RyZW5ndGguIA0KfA0K fCAgICAgICAgICAgICAgIE5vdGUgdGhhdCB0aGUgUmlzZV9vbl9kbHksIFJpc2Vfb2ZmX2Rs eSwgRmFsbF9vbl9kbHksDQp8ICAgICAgICAgICAgICAgRmFsbF9vZmZfZGx5IHBhcmFtZXRl cnMgYXJlIHNpbmdsZSB2YWx1ZSBwYXJhbWV0ZXJzLCBzbyANCnwgICAgICAgICAgICAgICB0 eXBpY2FsLCBtaW5pbXVtIGFuZCBtYXhpbXVtIGNvbmRpdGlvbnMgY2Fubm90IGJlIGRlc2Ny aWJlZA0KfCAgICAgICAgICAgICAgIHdpdGggdGhlbSBkaXJlY3RseS4gIEluIG9yZGVyIHRv IGFjY291bnQgZm9yIHRob3NlIGVmZmVjdHMsDQp8ICAgICAgICAgICAgICAgb25lIGNhbiBy ZWZlciB0byB0aGUgZmFzdGVzdCB3YXZlZm9ybSB0YWJsZSB3aXRoIHRoZSBkZWxheQ0KfCAg ICAgICAgICAgICAgIG51bWJlciBhbmQgdGhlbiBpbnNlcnQgYW4gYXBwcm9wcmlhdGUgYW1v dW50IG9mIGhvcml6b250YWwNCnwgICAgICAgICAgICAgICBsZWFkIGluIHNlY3Rpb24gaW4g dGhvc2Ugd2F2ZWZvcm1zIHdoaWNoIG5lZWQgbW9yZSBkZWxheS4NCnwNCnwqICAgICAgICAg ICAgICBOb3RpY2UgdGhhdCB0aGUgQ19jb21wIHBhcmFtZXRlciBvZiBhIG11bHRpLXN0YWdl IGJ1ZmZlciBpcw0KfCogICAgICAgICAgICAgIGRlZmluZWQgaW4gdGhlIHRvcC1sZXZlbCBt b2RlbC4gIFRoZSB2YWx1ZSBvZiBDX2NvbXANCnwqICAgICAgICAgICAgICB0aGVyZWZvcmUg aW5jbHVkZXMgdGhlIHRvdGFsIGNhcGFjaXRhbmNlIG9mIHRoZSBlbnRpcmUNCnwqICAgICAg ICAgICAgICBidWZmZXIsIGluY2x1ZGluZyBhbGwgb2YgaXRzIHN0YWdlcy4gIFNpbmNlIHRo ZSByaXNpbmcgYW5kDQp8KiAgICAgICAgICAgICAgZmFsbGluZyB3YXZlZm9ybSBtZWFzdXJl bWVudHMgaW5jbHVkZSB0aGUgZWZmZWN0cyBvZg0KfCogICAgICAgICAgICAgIENfY29tcCwg ZWFjaCBvZiB0aGVzZSB3YXZlZm9ybXMgbXVzdCBiZSBnZW5lcmF0ZWQgd2l0aCB0aGUNCnwq ICAgICAgICAgICAgICB0b3RhbCBDX2NvbXAgcHJlc2VudCwgZXZlbiBpZiB0aGUgdmFyaW91 cyBzdGFnZXMgb2YgdGhlDQp8KiAgICAgICAgICAgICAgYnVmZmVyIGFyZSBjaGFyYWN0ZXJp emVkIGluZGl2aWR1YWxseS4NCnwNCnwgICAgICAgICAgICAgICBOb3RlOiBJbiBhIGZ1dHVy ZSByZWxlYXNlLCB0aGUgW0RyaXZlciBTY2hlZHVsZV0ga2V5d29yZCBtYXkNCnwgICAgICAg ICAgICAgICBiZSByZXBsYWNlZCBieSBhIG5ld2VyIG1ldGhvZCBvZiBzcGVjaWZpY2F0aW9u IHRoYXQgaXMgDQp8ICAgICAgICAgICAgICAgY29uc2lzdGVudCB3aXRoIHNvbWUgb3RoZXIg cGxhbm5lZCBleHRlbnNpb25zLiAgSG93ZXZlciwgdGhlDQp8ICAgICAgICAgICAgICAgW0Ry aXZlciBTY2hlZHVsZV0gc3ludGF4IHdpbGwgY29udGludWUgdG8gYmUgc3VwcG9ydGVkLg0K fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbRHJpdmVyIFNjaGVkdWxlXQ0KfCBNb2RlbF9u YW1lICAgICBSaXNlX29uX2RseSAgUmlzZV9vZmZfZGx5ICBGYWxsX29uX2RseSAgRmFsbF9v ZmZfZGx5DQogIE1PREVMX09VVCAgICAgIDAuMG5zICAgICAgICBOQSAgICAgICAgICAgIDAu MG5zICAgICAgICBOQQ0KfA0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBF eGFtcGxlcyBvZiBhZGRlZCBtdWx0aS1zdGFnZWQgdHJhbnNpdGlvbnMNCiAgTV9PX1NPVVJD RTEgICAgIDAuNW5zICAgICAgICBOQSAgICAgICAgICAgIDAuNW5zICAgICAgICBOQQ0KfCAg ICAgICAgICAgICAgbG93IChoaWdoLVopIHRvIGhpZ2ggICAgICAgIGhpZ2ggdG8gbG93ICho aWdoLVopDQogIE1fT19TT1VSQ0UyICAgIDAuNW4gICAgICAgICAxLjVuICAgICAgICAgIE5B ICAgICAgICAgICBOQQ0KfCAgICAgICAgICAgICAgIGxvdyB0byBoaWdoIHRvIGxvdyAgICAg ICAgICAgbG93IChoaWdoLVopDQogIE1fT19EUkFJTjEgICAgIDEuMG4gICAgICAgICBOQSAg ICAgICAgICAgIDEuNW4gICAgICAgICBOQQ0KfCAgICAgICAgICAgICAgbG93IHRvIGhpZ2gg KGhpZ2gtWikgICAgICAgIGhpZ2ggKGhpZ2gtWikgdG8gbG93DQogIE1fT19EUkFJTjIgICAg IE5BICAgICAgICAgICBOQSAgICAgICAgICAgIDEuNW4gICAgICAgICAyLjBuDQp8ICAgICAg ICAgICAgICAgICAgaGlnaCAoaGlnaC1aKSAgICAgICAgICAgaGlnaCB0byBsb3cgdG8gaGln aCANCnwNCnw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCg0KQU5BTFlTSVMgUEFUSC9EQVRBIFRIQVQgTEVEIFRPIFNQRUNJRklDQVRJT046 DQoNCkFuIGF0dGVtcHQgdG8gYnVpbGQgYW4gSUJJUyAzLjIgYnVmZmVyIG1vZGVsIGZvciBh IHRocmVlLXN0YWdlIGJ1ZmZlciB1c2luZw0KdGhlIFtEcml2ZXIgU2NoZWR1bGVdIGtleXdv cmQgZmFpbGVkLiAgVGhlIGluaXRpYWwgdGVzdGluZyBvZiB0aGlzIG1vZGVsDQp3aXRoIHRo ZSB0b29scyBvZiB0d28gRURBIHZlbmRvcnMgc2hvd2VkIG9ubHkgdHdvIG9mIHRoZSB0aHJl ZSBzdGFnZXMNCndvcmtpbmcuICBUaGlzIGhhcHBlbmVkIGJlY2F1c2UgdGhlIGZpcnN0IHN0 YWdlIG9mIHRoZSBidWZmZXIgd2FzIHBsYWNlZA0KaW50byB0aGUgIm1haW4iIFtNb2RlbF0g c2VjdGlvbiBvZiB0aGUgSUJJUyBtb2RlbCBkdWUgdG8gYSBwZXJzb25hbA0KaW50ZXJwcmV0 YXRpb24gb2YgdGhlIElCSVMgMy4yIHNwZWMuICBBZnRlciBjb25zdWx0aW5nIHdpdGggc2V2 ZXJhbCBwZW9wbGUsDQppdCBiZWNhbWUgYXBwYXJlbnQgdGhhdCB0aGUgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBtZW50aW9uIHNvbWUgb2YgdGhlIGtleQ0KaW5mb3JtYXRpb24gdGhhdCBp cyBuZWNlc3NhcnkgdG8gYnVpbGQgYSBjb3JyZWN0IElCSVMgbW9kZWwgZm9yIHRoaXMga2lu ZCBvZg0KYSBidWZmZXIuDQoNClRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGluIEJJUkQzNS4z IGNvbnRhaW5zIHRoZSBtaXNzaW5nIGluZm9ybWF0aW9uIHdoaWNoDQppcyBuZWNlc3Nhcnkg Zm9yIG1ha2luZyBjb3JyZWN0IElCSVMgbW9kZWxzIHVzaW5nIHRoZSBbRHJpdmVyIFNjaGVk dWxlXQ0Ka2V5d29yZC4gIFRoaXMgc2VjdGlvbiBzZWVtcyB0byBoYXZlIGJlZW4gYWNjaWRl bnRhbGx5IGxlZnQgb3V0IGZyb20gdGhlDQpzcGVjaWZpY2F0aW9uLCBhbmQgc2hvdWxkIGJl IHBhc3RlZCBpbnRvIHRoZSBhcHByb3ByaWF0ZSBsb2NhdGlvbiBhcyBzaG93bg0KYWJvdmUu ICAoTm90ZSB0aGF0IHRoZSBmaXJzdCBhbmQgc2Vjb25kIHNlbnRlbmNlcyBhcmUgZGVsZXRl ZCBiZWNhdXNlIHRoZXkNCmRvIG5vdCBwcm92aWRlIG5ldyBpbmZvcm1hdGlvbiBpbiB0aGUg Y29udGV4dCBhYm92ZSkuDQoNCiJUaGUgbmV3IGtleXdvcmQgW0RyaXZlciBTY2hlZHVsZV0g cHJvdmlkZXMgYSBzeW50YXggZm9yIHNlcXVlbmNpbmcgb3RoZXINCm1vZGVscy4gIFRoaXMg aXMgZ2l2ZW4gYXMgYSBrZXl3b3JkIHVuZGVyIHRoZSBbTW9kZWxdIGtleXdvcmQuICBJdCBv dmVycmlkZXMNCmFueSBleGlzdGluZyBbUHVsbHVwXSwgW1B1bGxkb3duXSBhbmQgW1JhbXBd IG9yIFtSaXNpbmcgV2F2ZWZvcm1dIGFuZCANCltGYWxsaW5nIFdhdmVmb3JtXSBkYXRhIGZv ciB0aGF0IG1vZGVsLiAgSG93ZXZlciwgdGhlIHJlcXVpcmVkIHRhYmxlcyBmb3INCltNb2Rl bF0gYXJlIHN0aWxsIHJlcXVpcmVkIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSByZWFz b25zIGZvciBzaW11bGF0b3JzDQp3aGljaCBkbyBub3Qgc3VwcG9ydCBtdWx0aS1zdGFnZWQg c3dpdGNoaW5nLiAgVGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUgdXNlZA0KYXMgYSBjb21wb3Np dGUgbW9kZWwgY3Jvc3MtY2hlY2ssIGFsdGhvdWdoIHRoZSByZXN1bHRpbmcgbW9kZWwgbWF5 IG5vdA0KcGVyZm9ybSBpbiB0aGUgc2FtZSBtYW5uZXIgYXMgdGhlIG11bHRpLXN0YWdlIG1v ZGVsLiINCg0KTnVtZXJvdXMgRU1BSUwgcmVzcG9uc2VzIHdlcmUgcG9zdGVkIGFmdGVyIEJJ UkQ1OCB3YXMgaXNzdWVkIG9uIDMtMi05OS4NCkFycGFkIE11cmFueWkgaGFkIG51bWVyb3Vz IHRlbGVwaG9uZSBjb252ZXJzYXRpb25zIHdpdGggQm9iIFJvc3MgYW5kIHBvc3RlZA0KYW4g RU1BSUwgcmVzcG9uc2Ugb24gMy0zMC05OS4gIFRoaXMgcmVzcG9uc2Ugd2FzIGFuIGF0dGVt cHQgdG8gc3VtbWFyaXplIHRoZQ0KaXNzdWVzIGFuZCB3YXMgZGlzY3Vzc2VkIGluIGEgc3Vi c2VxdWVudCBJQklTIE9wZW4gRm9ydW0gdGVsZWNvbmZlcmVuY2UNCm1lZXRpbmcuICBBcnBh ZCBNdXJhbnlpIHJlY2VpdmVkIGFuIEFSIHRvIGlzc3VlIEJJUkQ1OC4xICh0aGlzIGRvY3Vt ZW50KQ0KYmFzZWQgb24gdGhlIGFkZGl0aW9uYWwgZmVlZGJhY2suDQoNCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KDQpBTlkgT1RIRVIgQkFDS0dST1VORCBJTkZPUk1BVElPTjoNCg0K VGVsZXBob25lIGNvbnZlcnNhdGlvbiB3aXRoIEJvYiBSb3NzIG9uIDItMjYtOTkgY29uZmly bWVkIHRoYXQgdGhlIElCSVMNCnNwZWNpZmljYXRpb24gaXMgbWlzc2luZyB0aGUgZGVzY3Jp cHRpb24gb2Ygc29tZSBvZiB0aGUgdXNhZ2UgcnVsZXMgd2hpY2gNCndlcmUgZG9jdW1lbnRl ZCBpbiBCSVJEMzUuMyBhbmQgd2FzIGltcGxlbWVudGVkIGFjY29yZGluZ2x5IGluIElDWC4N Cg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= --PART-BOUNDARY=.1990505150331.ZM93964.fm.intel.com-- From owner-ibis Wed May 5 15:24:23 1999 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA08221 for ; Wed, 5 May 1999 15:24:22 -0700 (PDT) Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id PAA26505 for ; Wed, 5 May 1999 15:18:40 -0700 (PDT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 5 May 1999 15:18:40 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512703BB0BC9@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'ibis@eda.org'" Subject: BIRD58.1 in the body of the text Date: Wed, 5 May 1999 15:18:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" All, Just in case someone had a problem receiving the previous EMAIL with the BIRD as an attachment, here it is again in the body of the text. I apologize if the duplicate or the attachment caused any inconvenience. Arpad ============================================================================ === To all IBIS fans interested, I apologize for the delay in writing this iteration of BIRD58. In this document I am attempting to combine all responses I received after issuing the original BIRD. I hope this iteration will be more acceptable. Thanks, Arpad ============================================================================ == **************************************************************************** ** **************************************************************************** ** BIRD ID#: 58.1 ISSUE TITLE: Driver Schedule keyword clarification REQUESTER: Arpad Muranyi, Intel Corporation DATE SUBMITTED: 3/2/99, 5/5/99 DATE ACCEPTED BY IBIS OPEN FORUM: pending **************************************************************************** ** **************************************************************************** ** STATEMENT OF THE ISSUE: The [Driver Schedule] section of the latest IBIS specification (v3.2) does not provide enough information to the model maker and EDA tool vendor on essential details of this keyword. The spec. can be interpreted in several different ways which can lead to serious discrepancies and consequences. **************************************************************************** ** STATEMENT OF THE RESOLVED SPECIFICATIONS: One paragraph from BIRD35.3 is included in the [Driver Schedule] usage rules section of the specification. This portion seems to have been inadvertently left out from the spec. and explains most of the gray areas. In addition to this missing paragraph, some changes have been made to the wording of the description of this keyword for clarity. The additional words do not change the original intent behind this keyword. It is only added to spell out how the keyword must be used so that the model maker and EDA tool vendor could be in agreement on how the model works. The new section(s) are marked with a "*" character at the beginning of each line. |=========================================================================== == | Keyword: [Driver Schedule] | Required: No | Description: Describes the relative model switching sequence for referenced | models to produce a multi-staged driver. | Usage Rules: The [Driver schedule] keyword establishes a hierarchical order | between models and should be placed under the [Model] which | acts as the top-level model. The scheduled models are then | referenced from the top-level model by the [Driver Schedule] | keyword. | |* When a multi-staged buffer is modeled using the [Driver |* Schedule] keyword, all of its stages (including the first |* stage, or normal driver) have to be modeled as scheduled |* models. |* |* If there is support for this feature in a simulator, the |* [Driver Schedule] keyword will cause it to use the |* [Pulldown], [Pulldown Reference], [Pullup], [Pullup |* Reference], [Voltage Range], [Ramp], [Rising Waveform] and |* [Falling Waveform] keywords from the scheduled models |* instead of the top-level model, according to the timing |* relationships described in the [Driver Schedule] keyword. |* Consequently, the keywords in the above list will be ignored |* in the top-level model. Also, all other keywords not shown |* in the above list will be ignored in the scheduled model(s). |* |* However, both the top-level and the scheduled model(s) have |* to be complete models, i.e. they have to obey all rules of |* keyword requirements. |* |* For backwards compatibility reasons and for simulators which |* do not support multi-staged switching, the keywords in the |* above list can be used in the top-level [Model] to describe |* the overall characteristics of the buffer as if it was a |* composite model. It is not guaranteed, however, that such a |* top-level model will yield the same simulation results as a |* full multi-stage model. It is recommended that a "golden | waveform" for the device consisting of a [Rising Waveform] | table and a [Falling Waveform] table be supplied in the | top-level model to serve as a reference for validation. | |* Even though some of the keywords are ignored in the |* scheduled model, it may still make sense in some cases to |* supply correct data with them. One such situation would |* arise when a [Model] is used both as a regular top-level |* model as well as a scheduled model. | | | The [Driver Schedule] table consists of five columns. The | first column contains the model names of other models that | exists in the .ibs file. The remaining four columns describe | delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and |* Fall_off_dly. All values are referenced to 0 seconds for | the start of the rising transition and 0 seconds for the | start of the falling transition. All delays must be equal |* to or greater than 0. There are only five valid |* combinations in which these parameters can be used: |* |* 1) Rise_on_dly with Fall_on_dly |* 2) Rise_off_dly with Fall_off_dly |* 3) Rise_on_dly with Rise_off_dly |* 4) Fall_on_dly with Fall_on_dly |* 5) All four delays defined |* (be careful about correct sequencing) |* |* The four delay parameters have the meaning as described |* below. (Note that this description applies to buffer types |* which have both pullup and pulldown structures. For those |* buffer types which have only a pullup or pulldown structure, |* the description for the missing part can be omitted.) |* |* Fall_on_dly is the amount of time that elapses from the |* internal simulator pulse initiating a FALLING edge and the |* t=0 time of the waveform or ramp that turns the IV curve of |* the PULLDOWN device ON, and the t=0 time of the waveform or |* ramp that turns the IV curve of the PULLUP device OFF (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Fall_off_dly is the amount of time that elapses from the |* internal simulator pulse initiating a FALLING edge and the |* t=0 time of the waveform or ramp that turns the IV curve of |* the PULLDOWN device OFF, and the t=0 time of the waveform or |* ramp that turns the IV curve of the PULLUP device ON (if |* they were not turned OFF and ON by another event yet, |* respectively). |* |* Rise_on_dly is the amount of time that elapses from the |* internal simulator pulse initiating a RISING edge and the |* t=0 time of the waveform or ramp that turns the IV curve of |* the PULLUP device ON, and the t=0 time of the waveform or |* ramp that turns the IV curve of the PULLDOWN device OFF (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Rise_off_dly is the amount of time that elapses from the |* internal simulator pulse initiating a RISING edge and the |* t=0 time of the waveform or ramp that turns the IV curve of |* the PULLUP device OFF, and the t=0 time of the waveform or |* ramp that turns the IV curve of the PULLDOWN device ON (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Note that some timing combinations may only be possible if |* the two halves of a complementary buffer are modeled |* separately as two open_* models. | | | Use 'NA' when no transition is applicable. For each model, | the transition sequence must be complete, i.e., it must start | and end at the same state. | | No [Driver Schedule] may reference a model which itself has | within it a [Driver Schedule] table keyword. | | Other Notes: The added models typically consist of Open_sink (Open_drain) | or Open_source models to provide sequentially increased drive | strengths. The added drive may be removed within the same | transition for a momentary boost or during the opposite | transition. | | The syntax also allows for reducing the drive strength. | | Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, | Fall_off_dly parameters are single value parameters, so | typical, minimum and maximum conditions cannot be described | with them directly. In order to account for those effects, | one can refer to the fastest waveform table with the delay | number and then insert an appropriate amount of horizontal | lead in section in those waveforms which need more delay. | |* Notice that the C_comp parameter of a multi-stage buffer is |* defined in the top-level model. The value of C_comp |* therefore includes the total capacitance of the entire |* buffer, including all of its stages. Since the rising and |* falling waveform measurements include the effects of |* C_comp, each of these waveforms must be generated with the |* total C_comp present, even if the various stages of the |* buffer are characterized individually. | | Note: In a future release, the [Driver Schedule] keyword may | be replaced by a newer method of specification that is | consistent with some other planned extensions. However, the | [Driver Schedule] syntax will continue to be supported. |--------------------------------------------------------------------------- -- [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high | |=========================================================================== == **************************************************************************** ** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: An attempt to build an IBIS 3.2 buffer model for a three-stage buffer using the [Driver Schedule] keyword failed. The initial testing of this model with the tools of two EDA vendors showed only two of the three stages working. This happened because the first stage of the buffer was placed into the "main" [Model] section of the IBIS model due to a personal interpretation of the IBIS 3.2 spec. After consulting with several people, it became apparent that the specification does not mention some of the key information that is necessary to build a correct IBIS model for this kind of a buffer. The following paragraph in BIRD35.3 contains the missing information which is necessary for making correct IBIS models using the [Driver Schedule] keyword. This section seems to have been accidentally left out from the specification, and should be pasted into the appropriate location as shown above. (Note that the first and second sentences are deleted because they do not provide new information in the context above). "The new keyword [Driver Schedule] provides a syntax for sequencing other models. This is given as a keyword under the [Model] keyword. It overrides any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and [Falling Waveform] data for that model. However, the required tables for [Model] are still required for backwards compatibility reasons for simulators which do not support multi-staged switching. This information can be used as a composite model cross-check, although the resulting model may not perform in the same manner as the multi-stage model." Numerous EMAIL responses were posted after BIRD58 was issued on 3-2-99. Arpad Muranyi had numerous telephone conversations with Bob Ross and posted an EMAIL response on 3-30-99. This response was an attempt to summarize the issues and was discussed in a subsequent IBIS Open Forum teleconference meeting. Arpad Muranyi received an AR to issue BIRD58.1 (this document) based on the additional feedback. **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS specification is missing the description of some of the usage rules which were documented in BIRD35.3 and was implemented accordingly in ICX. **************************************************************************** ** From owner-ibis Mon May 10 12:53:58 1999 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA27752 for ; Mon, 10 May 1999 12:53:57 -0700 (PDT) Received: from fmsmsx28.FM.INTEL.COM (fmsmsx28.fm.intel.com [132.233.42.28]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id MAA28542 for ; Mon, 10 May 1999 12:48:13 -0700 (PDT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 May 1999 12:48:12 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512703BB0BE7@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'ibis@eda.org'" Subject: BIRD58.2 Date: Mon, 10 May 1999 12:48:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE9B1E.098BCB1D" 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_01BE9B1E.098BCB1D Content-Type: text/plain; charset="ISO-8859-1" All, Here is BIRD58.2. I am sending it both ways, in the body of the text, plus as an attachment. Keep wichever looks better (i.e. no line wrapping, etc). Sincerely, Arpad Muranyi Intel Corporation ============================================================================ == **************************************************************************** ** **************************************************************************** ** BIRD ID#: 58.2 ISSUE TITLE: Driver Schedule keyword clarification REQUESTER: Arpad Muranyi, Intel Corporation DATE SUBMITTED: 3/2/99, 5/5/99, 5/10/99 DATE ACCEPTED BY IBIS OPEN FORUM: pending **************************************************************************** ** **************************************************************************** ** STATEMENT OF THE ISSUE: The [Driver Schedule] section of the latest IBIS specification (v3.2) does not provide enough information to the model maker and EDA tool vendor on essential details of this keyword. The specification can be interpreted in many different ways which can lead to serious discrepancies and consequences. **************************************************************************** ** STATEMENT OF THE RESOLVED SPECIFICATIONS: A paragraph from BIRD35.3, which explains most of the gray areas, seems to have been inadvertently left out from the specification. On top of that, the usage rules section was fairly unclear to many readers, resulting in a lot of questions even in the presence of the missing paragraph. For this reason, the usage rules section was almost completely rewritten, in addition to pasting the missing paragraph from BIRD35.3 into it. The additional words or rewording do not change the original intent behind the keyword. The intention in these changes was only to spell out more clearly how the keyword should be used so that the model maker and EDA tool vendor could be in agreement on how the model works. The new section(s) of BIRD58.1 are marked with a "*" character at the beginning of each line. and the new section(s) of BIRD58.2 are marked with two asterisks "**" at the beginning of each line. |=========================================================================== == | Keyword: [Driver Schedule] | Required: No | Description: Describes the relative model switching sequence for referenced | models to produce a multi-staged driver. | Usage Rules: The [Driver schedule] keyword establishes a hierarchical order | between models and should be placed under the [Model] which | acts as the top-level model. The scheduled models are then | referenced from the top-level model by the [Driver Schedule] | keyword. | |* When a multi-staged buffer is modeled using the [Driver |* Schedule] keyword, all of its stages (including the first |* stage, or normal driver) have to be modeled as scheduled |* models. |* |* If there is support for this feature in a simulator, the |* [Driver Schedule] keyword will cause it to use the |* [Pulldown], [Pulldown Reference], [Pullup], [Pullup |* Reference], [Voltage Range], [Ramp], [Rising Waveform] and |* [Falling Waveform] keywords from the scheduled models |* instead of the top-level model, according to the timing |* relationships described in the [Driver Schedule] keyword. |* Consequently, the keywords in the above list will be ignored |* in the top-level model. Also, all other keywords not shown |* in the above list will be ignored in the scheduled model(s). |* |* However, both the top-level and the scheduled model(s) have |** to be complete models, i.e. all of the required keywords |** must be present and follow the syntactical rules. |* |* For backwards compatibility reasons and for simulators which |* do not support multi-staged switching, the keywords in the |* above list can be used in the top-level [Model] to describe |* the overall characteristics of the buffer as if it was a |* composite model. It is not guaranteed, however, that such a |* top-level model will yield the same simulation results as a |* full multi-stage model. It is recommended that a "golden | waveform" for the device consisting of a [Rising Waveform] | table and a [Falling Waveform] table be supplied in the | top-level model to serve as a reference for validation. | |* Even though some of the keywords are ignored in the |* scheduled model, it may still make sense in some cases to |* supply correct data with them. One such situation would |* arise when a [Model] is used both as a regular top-level |* model as well as a scheduled model. | | | The [Driver Schedule] table consists of five columns. The | first column contains the model names of other models that | exists in the .ibs file. The remaining four columns describe | delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and |** Fall_off_dly. The t=0 time of each delay is the event when |** the simulator's internal pulse initiates a rising or falling |** transition. All specified delay values must be equal to or |** greater than 0. There are only five valid combinations in |** which these delay values can be defined: |* |* 1) Rise_on_dly with Fall_on_dly |* 2) Rise_off_dly with Fall_off_dly |* 3) Rise_on_dly with Rise_off_dly |** 4) Fall_on_dly with Fall_off_dly |* 5) All four delays defined |* (be careful about correct sequencing) |* |* The four delay parameters have the meaning as described |* below. (Note that this description applies to buffer types |* which have both pullup and pulldown structures. For those |* buffer types which have only a pullup or pulldown structure, |** the description for the missing structure can be omitted.) |* |* Fall_on_dly is the amount of time that elapses from the |** internal simulator pulse initiating a FALLING edge to the |* t=0 time of the waveform or ramp that turns the IV curve of |* the PULLDOWN device ON, and the t=0 time of the waveform or |* ramp that turns the IV curve of the PULLUP device OFF (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Fall_off_dly is the amount of time that elapses from the |** internal simulator pulse initiating a FALLING edge to the |* t=0 time of the waveform or ramp that turns the IV curve of |* the PULLDOWN device OFF, and the t=0 time of the waveform or |* ramp that turns the IV curve of the PULLUP device ON (if |* they were not turned OFF and ON by another event yet, |* respectively). |* |* Rise_on_dly is the amount of time that elapses from the |** internal simulator pulse initiating a RISING edge to the |* t=0 time of the waveform or ramp that turns the IV curve of |* the PULLUP device ON, and the t=0 time of the waveform or |* ramp that turns the IV curve of the PULLDOWN device OFF (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Rise_off_dly is the amount of time that elapses from the |** internal simulator pulse initiating a RISING edge to the |* t=0 time of the waveform or ramp that turns the IV curve of |* the PULLUP device OFF, and the t=0 time of the waveform or |* ramp that turns the IV curve of the PULLDOWN device ON (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Note that some timing combinations may only be possible if |* the two halves of a complementary buffer are modeled |* separately as two open_* models. |* |* |** Use 'NA' when no delay value is applicable. For each |** scheduled model the transition sequence must be complete, |** i.e., the scheduled model must return to its initial state. | |** No [Driver Schedule] table may reference a model which |** itself has within it a [Driver Schedule] keyword. | | Other Notes: The added models typically consist of Open_sink (Open_drain) | or Open_source models to provide sequentially increased drive | strengths. The added drive may be removed within the same | transition for a momentary boost or during the opposite | transition. | | The syntax also allows for reducing the drive strength. | | Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, | Fall_off_dly parameters are single value parameters, so | typical, minimum and maximum conditions cannot be described | with them directly. In order to account for those effects, | one can refer to the fastest waveform table with the delay | number and then insert an appropriate amount of horizontal | lead in section in those waveforms which need more delay. | |* Notice that the C_comp parameter of a multi-stage buffer is |* defined in the top-level model. The value of C_comp |* therefore includes the total capacitance of the entire |* buffer, including all of its stages. Since the rising and |* falling waveform measurements include the effects of |* C_comp, each of these waveforms must be generated with the |* total C_comp present, even if the various stages of the |* buffer are characterized individually. | | Note: In a future release, the [Driver Schedule] keyword may | be replaced by a newer method of specification that is | consistent with some other planned extensions. However, the | [Driver Schedule] syntax will continue to be supported. |--------------------------------------------------------------------------- -- [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high | |=========================================================================== == **************************************************************************** ** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: An attempt to build an IBIS 3.2 buffer model for a three-stage buffer using the [Driver Schedule] keyword failed. The initial testing of this model with the tools of two EDA vendors showed only two of the three stages working. This happened because the first stage of the buffer was placed into the "main" [Model] section of the IBIS model due to a personal interpretation of the IBIS 3.2 spec. After consulting with several people, it became apparent that the specification does not mention some of the key information that is necessary to build a correct IBIS model for this kind of a buffer. The following paragraph in BIRD35.3 contains the missing information which is necessary for making correct IBIS models using the [Driver Schedule] keyword. This section seems to have been accidentally left out from the specification, and should be pasted into the appropriate location as shown above. "The new keyword [Driver Schedule] provides a syntax for sequencing other models. This is given as a keyword under the [Model] keyword. It overrides any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and [Falling Waveform] data for that model. However, the required tables for [Model] are still required for backwards compatibility reasons for simulators which do not support multi-staged switching. This information can be used as a composite model cross-check, although the resulting model may not perform in the same manner as the multi-stage model." Numerous EMAIL responses were posted after BIRD58 was issued on 3-2-99. Arpad Muranyi had numerous telephone conversations with Bob Ross and posted an EMAIL response on 3-30-99. This response was an attempt to summarize the issues and was discussed in a subsequent IBIS Open Forum teleconference meeting. Arpad Muranyi received an AR to issue BIRD58.1 (this document) based on the additional feedback. BIRD58.1 was discussed in the Open Forum teleconference on 5-7-99. BIRD58.2 is a result of the editorial changes that were requested in that meeting. **************************************************************************** ** ANY OTHER BACKGROUND INFORMATION: Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS specification is missing the description of some of the usage rules which were documented in BIRD35.3 and was implemented accordingly in ICX. **************************************************************************** ** ------_=_NextPart_000_01BE9B1E.098BCB1D Content-Type: text/plain; name="BIRD58_2.TXT" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="BIRD58_2.TXT" ************************************************************************= ****** ************************************************************************= ****** BIRD ID#: 58.2 ISSUE TITLE: Driver Schedule keyword clarification REQUESTER: Arpad Muranyi, Intel Corporation DATE SUBMITTED: 3/2/99, 5/5/99, 5/10/99 DATE ACCEPTED BY IBIS OPEN FORUM: pending ************************************************************************= ****** ************************************************************************= ****** STATEMENT OF THE ISSUE: The [Driver Schedule] section of the latest IBIS specification (v3.2) = does not provide enough information to the model maker and EDA tool vendor = on essential details of this keyword. The specification can be = interpreted in many different ways which can lead to serious discrepancies and = consequences. ************************************************************************= ****** STATEMENT OF THE RESOLVED SPECIFICATIONS: A paragraph from BIRD35.3, which explains most of the gray areas, seems = to have been inadvertently left out from the specification. On top of = that, the usage rules section was fairly unclear to many readers, resulting in a = lot of questions even in the presence of the missing paragraph. For this reason, the usage rules section was almost completely = rewritten, in addition to pasting the missing paragraph from BIRD35.3 into it. The additional words or rewording do not change the original intent = behind the keyword. The intention in these changes was only to spell out more clearly how the keyword should be used so that the model maker and EDA = tool vendor could be in agreement on how the model works. The new section(s) of BIRD58.1 are marked with a "*" character at the beginning of each line. and the new section(s) of BIRD58.2 are marked = with two asterisks "**" at the beginning of each line. |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D | Keyword: [Driver Schedule] | Required: No | Description: Describes the relative model switching sequence for = referenced | models to produce a multi-staged driver. | Usage Rules: The [Driver schedule] keyword establishes a = hierarchical order | between models and should be placed under the [Model] = which=20 | acts as the top-level model. The scheduled models are = then=20 | referenced from the top-level model by the [Driver = Schedule] | keyword. | |* When a multi-staged buffer is modeled using the [Driver |* Schedule] keyword, all of its stages (including the = first |* stage, or normal driver) have to be modeled as = scheduled |* models. |* |* If there is support for this feature in a simulator, = the |* [Driver Schedule] keyword will cause it to use the |* [Pulldown], [Pulldown Reference], [Pullup], [Pullup |* Reference], [Voltage Range], [Ramp], [Rising Waveform] = and |* [Falling Waveform] keywords from the scheduled models |* instead of the top-level model, according to the timing |* relationships described in the [Driver Schedule] = keyword.=20 |* Consequently, the keywords in the above list will be = ignored |* in the top-level model. Also, all other keywords not = shown |* in the above list will be ignored in the scheduled = model(s). |* |* However, both the top-level and the scheduled model(s) = have |** to be complete models, i.e. all of the required = keywords |** must be present and follow the syntactical rules. |* |* For backwards compatibility reasons and for simulators = which |* do not support multi-staged switching, the keywords in = the |* above list can be used in the top-level [Model] to = describe |* the overall characteristics of the buffer as if it was = a |* composite model. It is not guaranteed, however, that = such a |* top-level model will yield the same simulation results = as a |* full multi-stage model. It is recommended that a = "golden | waveform" for the device consisting of a [Rising = Waveform] | table and a [Falling Waveform] table be supplied in the | top-level model to serve as a reference for validation. | |* Even though some of the keywords are ignored in the |* scheduled model, it may still make sense in some cases = to |* supply correct data with them. One such situation = would |* arise when a [Model] is used both as a regular = top-level |* model as well as a scheduled model. | | | The [Driver Schedule] table consists of five columns. = The | first column contains the model names of other models = that | exists in the .ibs file. The remaining four columns = describe | delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and |** Fall_off_dly. The t=3D0 time of each delay is the = event when |** the simulator's internal pulse initiates a rising or = falling |** transition. All specified delay values must be equal = to or |** greater than 0. There are only five valid combinations = in |** which these delay values can be defined: |* |* 1) Rise_on_dly with Fall_on_dly |* 2) Rise_off_dly with Fall_off_dly |* 3) Rise_on_dly with Rise_off_dly |** 4) Fall_on_dly with Fall_off_dly |* 5) All four delays defined |* (be careful about correct sequencing) |* |* The four delay parameters have the meaning as described |* below. (Note that this description applies to buffer = types |* which have both pullup and pulldown structures. For = those |* buffer types which have only a pullup or pulldown = structure, |** the description for the missing structure can be = omitted.) |* |* Fall_on_dly is the amount of time that elapses from the |** internal simulator pulse initiating a FALLING edge to = the |* t=3D0 time of the waveform or ramp that turns the IV = curve of |* the PULLDOWN device ON, and the t=3D0 time of the = waveform or |* ramp that turns the IV curve of the PULLUP device OFF = (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Fall_off_dly is the amount of time that elapses from = the |** internal simulator pulse initiating a FALLING edge to = the |* t=3D0 time of the waveform or ramp that turns the IV = curve of |* the PULLDOWN device OFF, and the t=3D0 time of the = waveform or |* ramp that turns the IV curve of the PULLUP device ON = (if |* they were not turned OFF and ON by another event yet, |* respectively). |* |* Rise_on_dly is the amount of time that elapses from the |** internal simulator pulse initiating a RISING edge to = the |* t=3D0 time of the waveform or ramp that turns the IV = curve of |* the PULLUP device ON, and the t=3D0 time of the = waveform or |* ramp that turns the IV curve of the PULLDOWN device OFF = (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Rise_off_dly is the amount of time that elapses from = the |** internal simulator pulse initiating a RISING edge to = the |* t=3D0 time of the waveform or ramp that turns the IV = curve of |* the PULLUP device OFF, and the t=3D0 time of the = waveform or |* ramp that turns the IV curve of the PULLDOWN device ON = (if |* they were not turned ON and OFF by another event yet, |* respectively). |* |* Note that some timing combinations may only be possible = if |* the two halves of a complementary buffer are modeled=20 |* separately as two open_* models. |* |* |** Use 'NA' when no delay value is applicable. For each |** scheduled model the transition sequence must be = complete, |** i.e., the scheduled model must return to its initial = state. | |** No [Driver Schedule] table may reference a model which |** itself has within it a [Driver Schedule] keyword. | | Other Notes: The added models typically consist of Open_sink = (Open_drain)=20 | or Open_source models to provide sequentially increased = drive | strengths. The added drive may be removed within the = same | transition for a momentary boost or during the opposite = | transition. | | The syntax also allows for reducing the drive strength. = | | Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, | Fall_off_dly parameters are single value parameters, so = | typical, minimum and maximum conditions cannot be = described | with them directly. In order to account for those = effects, | one can refer to the fastest waveform table with the = delay | number and then insert an appropriate amount of = horizontal | lead in section in those waveforms which need more = delay. | |* Notice that the C_comp parameter of a multi-stage = buffer is |* defined in the top-level model. The value of C_comp |* therefore includes the total capacitance of the entire |* buffer, including all of its stages. Since the rising = and |* falling waveform measurements include the effects of |* C_comp, each of these waveforms must be generated with = the |* total C_comp present, even if the various stages of the |* buffer are characterized individually. | | Note: In a future release, the [Driver Schedule] = keyword may | be replaced by a newer method of specification that is=20 | consistent with some other planned extensions. = However, the | [Driver Schedule] syntax will continue to be supported. |-----------------------------------------------------------------------= ------ [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged = transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high=20 | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D ************************************************************************= ****** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: An attempt to build an IBIS 3.2 buffer model for a three-stage buffer = using the [Driver Schedule] keyword failed. The initial testing of this = model with the tools of two EDA vendors showed only two of the three stages working. This happened because the first stage of the buffer was = placed into the "main" [Model] section of the IBIS model due to a personal interpretation of the IBIS 3.2 spec. After consulting with several = people, it became apparent that the specification does not mention some of the = key information that is necessary to build a correct IBIS model for this = kind of a buffer. The following paragraph in BIRD35.3 contains the missing information = which is necessary for making correct IBIS models using the [Driver Schedule] keyword. This section seems to have been accidentally left out from = the specification, and should be pasted into the appropriate location as = shown above. "The new keyword [Driver Schedule] provides a syntax for sequencing = other models. This is given as a keyword under the [Model] keyword. It = overrides any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and=20 [Falling Waveform] data for that model. However, the required tables = for [Model] are still required for backwards compatibility reasons for = simulators which do not support multi-staged switching. This information can be = used as a composite model cross-check, although the resulting model may not perform in the same manner as the multi-stage model." Numerous EMAIL responses were posted after BIRD58 was issued on 3-2-99. Arpad Muranyi had numerous telephone conversations with Bob Ross and = posted an EMAIL response on 3-30-99. This response was an attempt to = summarize the issues and was discussed in a subsequent IBIS Open Forum teleconference meeting. Arpad Muranyi received an AR to issue BIRD58.1 (this = document) based on the additional feedback. BIRD58.1 was discussed in the Open Forum teleconference on 5-7-99. = BIRD58.2 is a result of the editorial changes that were requested in that = meeting. ************************************************************************= ****** ANY OTHER BACKGROUND INFORMATION: Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS specification is missing the description of some of the usage rules = which were documented in BIRD35.3 and was implemented accordingly in ICX. ************************************************************************= ****** ------_=_NextPart_000_01BE9B1E.098BCB1D-- From owner-ibis Tue May 11 10:34:12 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA02038 for ; Tue, 11 May 1999 10:34:02 -0700 (PDT) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id JAA25219 for ; Tue, 11 May 1999 09:34:42 -0700 Message-Id: <3.0.5.32.19990511102811.00af7bb0@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 11 May 1999 10:28:11 +0000 To: ibis@eda.org From: Matthew Flora Subject: IBIS Open Forum Minutes 7 May 1999 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DATE: 5/11/99 SUBJECT: 5/07/99 EIA IBIS Open Forum Meeting Minutes VOTING MEMBERS AND 1999 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Raj Raghuram*, Norio Matsui, Neven Orhanovic Avanti Nikolai Bannov Cadence Design Mike LaBonte* Cisco Systems Syed Huq Compaq Bob Haller*, Steve Coe, Shafir Rahman, Maher Elasad Cypress (Rajesh Manapat) EMC Corporation Fabrizio Zanella Fairchild Semiconductor [Peter LaFlamme], Craig Klem H.A.S. Electronics (Haruny Said) Hewlett Packard (EEsof, etc.) Paul Gregory, Henry Wu High Design Technology Razvan Ene HyperLynx Matthew Flora*, Kellee Crisafulli IBM Greg Edlund*, Michael Cohen, Praven Patel Incases Olaf Rethmeier, Werner Rissiek, David Eagles, Wilhelm Arnoldi, Ulrich Losch Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, Martin Chang, Dave Moxley, Kerry Nelson*, Jeff Day, Richard Mellitz, Peter Liou LSI Logic (Symbios Logic) Scott King Mentor Graphics Bob Ross*, Mohamed Mahmoud, Sherif Hammad, Jean Oudinot, Markku Kukkanen, Martin Groeber, Karine Loudet Mitsubishi (Tam Cao) Motorola (Ron Werner) National Semiconductor Milt Schwartz North East Systems Associates Edward Sayre, Michael Baxter, Kathy Breda NEC (Hiroshi Matsumoto) Philips Semiconductor Todd Andersen, Peter Christiaans Quantic EMC (Mike Ventham) Siemens Bernhard Unger, Christian Mitschke, Manfred Maurer, Peter Kaiser, Wolfram Meyer, Gerald Bannert, Harmut Ibowski, Katja Zuleeg, Hans Pichlmaier, Eckhard Lenski, Kortheuer Udo, Christian Sporrer SiQual Scott McMorrow Texas Instruments Jean-Claude Perrin, Shankar Balasubramaniah, Ramzi Ammar Thomson-CSF (Jean Lebrun) Time Domain Analysis Systems Dima Smolyansky Viewlogic Chris Rokusek*, Guy de Burgh, Cary Mandel, (Jon Powell) VeriBest Ian Dodd* VLSI Technology D.C. Sessions Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1999: 3Dfx Interactive Ken Wu Actel Corporation Silvia Montoya Alcatel Steven Criel Analytical Edge Robert Easson Applied Microelectronics Brian Sanderson BMW Friedrich Haslinger Bogatin Enterprise Eric Bogatin Bosch Telecom Detlef Wolf ECI Telecom Daniel Adar EIA [Patti Rusher], Cecilia Fleming*, Dan Heinemeier Electronique Catherine Gross EFM Consulting Ekkehard Miersch Intracon Design Mike Osmond FCI John Ellis Litton Systems Robert Bremer Molex Incorporated Gus Panella Nortel Networks (& Viewlogic) Martin Hall Oce Printing Systems Ernst Deiringer Praegitzer Design Rick Newell* Rockwell Collins Susan Tweeton, Ron Hau Samsung Jung-Gun Byun, Cheol-Seung Choi Signals & Systems Engineering Tom Hawkins STMicroelectronics Fabrice Boissieres, Philippe LeFevre StorageTek Nick Krull Sun Microsystems Victor Chang Tektronix Tom Brinkoetter Teradyne Mikhail Khusid VDOL Robert Novosel Xilinx Susan Wu (Unaffiliatied, Retired) Bruce Wenniger In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode May 28, 1999 (916) 356-9200 8-12114 2274622 Monday, June 21, 1999 DAC99 IBIS Summit Meeting - No Phone Bridge All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Rick Newell of Praegitzer Design indicated that Praegitzer Design has started up a small signal integrity group which uses many EDA tools. MEMBERSHIP UPDATE AND TREASURER'S REPORT Bob Ross reported that Siemens is now an official member. Cecilia Fleming is still working on checking payments. Bob now estimates about 24 or 25 members including some where payments still need to be verified. REVIEW OF MINUTES AND AR'S No corrections were made to the minutes. The AR's will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Bob noted that one reflector e-mail had the Happy99.exe virus as an attachment that should not be opened. A filter was set up on the author's e-mail address, but Matthew Flora will check if the person has "disinfected" himself. AR - Matthew to contact the "infected" subscriber to determine if the block on their address can be removed Matthew Flora mentioned that the new member information currently being sent out needs to be updated to give Cecilia Fleming as the EIA contact person. AR - Matthew will work with Bob on updating the new member information writeup. PRESS AND WEB PAGE UPDATES Bob Ross reported that Jim Lipman has written the article "Models Make the Difference in High-speed PC-board Design" in the April 15, 1999 issue of EDN. The article covers IBIS models and references simulator manufacturers. It is on pages 116-126 and also available from the following link. http://www.ednmag.com/ednmag/reg/1999/041599/df1.htm Also, the May 1999 issue of Printed Circuit Design Magazine contained articles with two references to IBIS. Jon Powell authored "SPICE or IBIS" on pages 12-17, and mention of IBIS was made in "Multi-board System-level Analysis" by Doug Kraemer on pages 32-34. Cecilia Fleming reported that Syed Huq can now do EIA IBIS Home page updates directly. NEW MODELS AVAILABLE, LIBRARY UPDATE Bob Ross reported a new SRAM IBIS model link from Galvantech: http://www.galvantech.com/ibis/ Also, 4 new technologies are added to the Philips link: http://www.philipslogic.com/support/ibis/ OPENS FOR NEW ISSUES Bob Ross on s2ibis2 maintenance and s2ibis3. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Bob Ross reported that the Committee Draft for Vote (CDV) phase was completed. The official vote was 8 to 1 with 5 abstentions. This information was reported on the IBIS reflector. Greg Ledenbach, Secretary of IEC TC93 and member of the US Technical Advisory Group (TAG) forwarded the letter ballot comments. Bob drafted and circulated the comments and some proposed responses for review. Cecilia stated that the draft comments sent to her have already been forwarded to Greg. After these are processed, the IEC 62014-1 document should be moved to the next phase (FDIS) leading to formal ratification of a Draft International Standard. The voting report link (split into two lines to avoid e-mail truncation) is: http://www.iec.ch/cgi-bin/procgi.pl/www/ iecwww.p?wwwlang=E&wwwprog=vote2.p&wcom=93&wclass=&wdoc=91&wsup= Bob also discussed the comments and draft responses and is including the text in these Minutes: NO VOTE COMMENTS: GERMANY: Comment 1: The document for commenting concerns version 2.1 of IBIS . The industry is already working with the EIA document IBIS Version 3.0 and is looking forward to version 3.1 which is already in progress as they are most interested in ongoing extensions and improvements. Industry confirmed that their needs are sufficiently served by the latest EIA standard and that they do not plan to use the older versions of IBIS published by IEC. We think that therefore the effort in this IEC project has no added value for the users. The project, if proceeded, should be based on the latest IBIS Version. EIA IBIS Open Forum Response to Comment 1: We thank you for your early support of our current IBIS Version 3.2 extensions. A national letter ballot for IBIS Version 3.2 is currently being conducted for EIA and ANSI approval. Upon completion of this vote, scheduled on June 23, 1999, and after the comments have been resolved, and after this document has been ratified as an official ANSI and EIA standard, we plan to forward this document as a proposed revision to IEC 62014-1. Downward compatibility with IBIS Version 2.1 will be maintained. IBIS Version 2.1 still remains sufficient for many components and will remain relevant by Version 3.2. We hope to forward IBIS Version 3.2 in 1999. Therefore, we feel that we agree with this comment and are using the "proposed revision" method to achieve the same objective. YES VOTE COMMENTS: FINLAND: Comment 1: We regard it very important that the structure of all IEC-standards produced by TC 93 are in accordance of ISO/IEC Directives Part 3. Proposed Change Regarding Comment 1: Move cl. 2 Introduction and cl 2.1 Future direction of IBIS away from the normative part before cl 1 Scope without clause numbering. The present Preface could be presented in the Annex (informative). EIA IBIS Open Forum Response to Comment 1: We assume that the document that was circulated was the official ANSI/EIA-656 document with sections consisted with EIA guidelines at the time of the adoption. We will make any necessary format change to be consistent with ISO/IEC Directives. Comment 2: EDA Home page has following information: While IBIS Version 2.1 remains the official ANSI/EIA and pending IEC standard, IBIS Version 3.2, containing some technical extensions, has been ratified on January 15, 1999 by the EIA/IBIS Open Forum. This document should be submitted for national and international standardization consideration. Proposed Change Regarding Comment 2: If this will happen we propose to discuss if Version 2.1 can already now be replaced with Version 3.2 EIA IBIS Open Forum Response to Comment 2: We agree with this comment. Upon completion of a letter ballot that will end on June 23, 1999, we plan to resolve the comments leading to the ratification of IBIS Version 3.2 as a national ANSI and EIA standard. Then we plan to forward this official document as an upgrade to IEC 62014-1. Comment 3: Definition BIRD is not then used in Normative part. Proposed Change Regarding Comment 3: Explain BIRD in the Introduction. EIA IBIS Open Forum Response to Comment 3: We agree with your comment. BIRD should be defined in the Introduction as Buffer Issue Resolution Document - a document used by the EIA IBIS Open Forum to implement changes to the Specification. Comment 4: According to ISO/IEC Directives Part 3 the numbering of the content shall be used for the reference purposes Proposed Change Regarding Comment 4: Clause: I/O Buffer Information Specification (IBIS) Version 2.1 should be numbered with number 6. Present Numbering also for the headings of sub-clauses e.g.: 6.1 Statement of Intent 6.2 General syntax rules and guidelines for ASCII Files, 6.3 Keywords 6.4 Notes on Data derivation method EIA IBIS Open Forum Response to Comment 4: We agree with your comment concerning Section 6. However, we do not intend to revise this document with sub-clauses because we would need to introduce more sub-clauses. We will consider this comment as a review comment on IBIS Version 3.2 which has "sub-clauses" (called Sections) for clarity and will resolve it in this document. SPAIN: Comment 1: We agree to the circulation of the draft as an FDIS in accordance with 2.7.1 of part 1 of the ISO/IEC Directives (or publication in the case of a draft Technical Report). EIA IBIS Open Forum Response to Comment 1: We agree with your comment. Thank you for your support. UNITED STATES: Comment 1: The table and figures of the document that was circulated as 93/91/CDV have been apparently generated with a variable width font, and they do not appear to be well-aligned. The USNC assumes that the final document will be printed using a uniform width font, and that the alignment of tables and figures will be checked again. EIA IBIS Open Forum Response to Comment 1: We agree with this comment. We believe that the official ANSI/EIA-656 needs to be checked and reformatted. UNITED KINGDOM Comment 1: The formatting of the document is inconsistent. Proposed Change Regarding Comment 1: Courier font throughout the document is suggested. EIA IBIS Open Forum Response to Comment 1: We agree with this comment. We will provide a consistently formatted .txt document. Bob noted that the negative vote and the comment from Finland regarding IBIS Version 3.X was really an endorsement of the IBIS activity and related to the ratification process. He believed the other comments on content and format probably concerned the surrounding "boiler-plate" material that exists in the official ANSI/EIA-656 document available from Global Engineering. There are some real formatting issues since it is a Word document with the IBIS text included in one section. Some line wrap-around text exists. Bob and Cecilia will deal with these formatting issues off-line to clean up the document as needed to be in compliance with the IEC requirements. Bob called for an endorsement vote that these comments be the official comments of the EIA IBIS Open Forum. This was approved by unanimous vote. Cecilia expressed concern that the IBIS Committee should have direct TAG representation to deal with any technical issues and to argue the IBIS Committee positions. Bob noted that there were no technical comments. All of the comments dealt with process and format issues and indicated support of IBIS. While he supports having TAG representation, Bob does not expect any problems at the TAG level. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - Bob Ross reported that he and Stephen Peters are planning to meet with Dr. Norio Matsui and Raj Raghuram next week on Wednesday, May 12, 1999 to explore further some IBIS and IMIC merger and linkage ideas and issues. - IEC 93/67/NP IBIS and EMC Simulation - Bob Ross had no further report - JC-16.2 Subcommittee: Modeling and Test - Bob Ross had no further report. IBIS (EAST) USERS GROUP MEETINGS Greg Edlund reported that a teleconference meeting was held on April 30, 1999. A number of issues were resolved on Version 1.2 of the IBIS Accuracy Specification. Greg has made the changes and is exploring uploading both a Word and Adobe Acrobat document so that comments can be made available for the next face-to-face Users group Meeting Bob Haller reported that a Users group Meeting is being planned at North East Systems Associates (NESA) on Thursday, May 13, 1999 at 3:00 P.M. to chart the course of the Users Group. They may consider having a phone in line. IBIS SUMMIT AT DESIGN AUTOMATION CONFERENCE Bob Ross noted that Cecilia Fleming has made arrangements for the IBIS Summit meeting at the Hilton Hotel in New Orleans, LA on Monday, June 21, 1999. This is adjacent to the Ernst M. Morial Convention Center where the Design Automation Conference (DAC) is being held. Cecilia stated that hotel space is limited, so make reservations as soon as possible. Bob stated that the Upcoming Events link on the EIA IBIS home page has a DAC99 link which would also have housing and hotel information. At the IBIS Summit, we will conduct our annual election of officers. People interested in holding an office are invited to contact Bob or other officers. Bob also anticipated that we may also devote some meeting time to discussing some letter ballot comments that have been received to date. Also several people are planning presentations. So we will invite discussion on any of our current topics including Accuracy Specification, Connector Specification, IMIC and new features, etc. Bob noted that Matthew Flora will handle the sign-ups for the meeting. Some details are already on the Upcoming Events link on the EIA IBIS home page. Matthew can be contacted at mbflora@hyperlynx.com or (425) 869-2320. Bob and Matthew will send out an announcement regarding the meeting. AR - Bob Ross and Matthew Flora send out an announcement for the EIA IBIS Summit Meeting on June 21, 1999. SP-4557 - IBIS VERSION 3.2 LETTER BALLOT Bob Ross reported that IBIS Version 3.2 is now open for public review and company voting for EIA and ANSI ratification. The links to the ballot form and to the document being reviewed are on the top level of the EIA IBIS home page: http://www.eia.org/eig/ibis/ibis.htm The project is noted as Standards Proposal 4557 (SP-4557). We are using the ver3_2.pdf document with page numbers and a table of contents for keywords that Arpad Muranyi produced. The ballot document SP-4557.pdf is to be mailed or FAXed back to EIA. Bob asked Cecilia Fleming to forward any comments received so that the EIA IBIS Open Forum can deal with them as soon as possible. Editorial comments are welcome, and Bob will be maintaining a revision document with corrections. Cecilia stated that she encourages a large turnout. Matthew Flora and Arpad mentioned that they had some editorial comments. Cecilia stated that she sent the ballot for notification and publication in an official ANSI newsletter for comments. The letter ballot deadline is June 23, 1999, but the ANSI deadline may be later. Cecilia will check on this and report to Bob. So the closing date for responses will be after the June 21, 1999 IBIS Summit Meeting. Bob noted that the voting information was sent to the IBIS reflectors, the SI reflector, JEDEC and to some other interested parties. Stephen Peters asked, and Bob confirmed that the official vote is by company. Bob also noted that the BIRD58.1 changes are expected to be submitted as a letter ballot editorial comment. IBIS TRAINING COURSE Bob Ross stated that Arpad Muranyi is making available his "Introduction to IBIS Models and IBIS Model Making" class Power Point slides to the IBIS Open Forum for downloading. This class was given in Phoenix Arizona as part of an Arizona State University short course. Bob Haller stated that the IBIS Users Group would be very interested in this material. Bob Ross stated that this course could be used to seed future IBIS education development. Arpad noted that he has Lab exercises, but upon questioning, noted that they require the internal IBIS Center tool. So the Lab exercises will not be uploaded. Arpad will send Bob a letter giving the EIA IBIS Open Forum permission to make public the course material [Done]. Bob noted that he will work with Syed Huq on providing a link to the material from the EIA IBIS Home page. AR - Bob Ross upload the IBIS Class slides provided by Arpad Muranyi to http://www.eda.org/pub/ibis/training/ [Done] COOKBOOK STATUS Stephen Peters commented that the timing and Vmeas clarification he recently sent to the IBIS reflector is added to his internal version of the IBIS Cookbook where he is collecting updates. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora distributed a model from Galileo Technology. S2IBIS2 MAINTENANCE AND S2IBIS3 (New Topic) Bob Ross initiated the discussion by noting that Scott McMorrow found a s2ibis2 source code bug and provided a correction. Also, Syed Huq had asked about work on s2ibis3 and some individuals in the IBIS Users Group commented on this. Bob stated that we have no formal mechanism to maintain s2ibis2 (and fix its defects) and we do not have an s2ibis3 project. He asked for ideas on how to proceed. Arpad Muranyi noted that currently s2ibis2 is offered as freeware. It could be sold. Bob added that he feels the best support comes from commercial offerings. Ian Dodd supported this position. Bob also mentioned that the s2ibis development was a funded project. We could consider how to fund s2ibis3 development (and s2ibis2 maintenance). Raj Raghuram was concerned that some vendors now provide commercial s2ibis translators which include some IBIS Version 3.X features. He felt that an IBIS Open Forum project may be in conflict with commercial offerings. Bob felt that the IBIS Open Forum should be permitted to maintain the existing s2ibis2 utility - and should deal with its problems, and the s2ibis3 would be a logical extension of this effort. The original idea of s2ibis was to provided a useful utility and also to seed the development of improved, commercial and Spice-specific versions. So continuing to do fixes and upgrades would continue to help everyone. Mike LaBonte noted that s2ibis2 is currently the most widely used utility to do SPICE to IBIS translation. He also asked if the IBIS page could list all of the vendors that supply s2ibis conversion. Bob noted that several links already exist to various free s2ibis conversion utilities. Per our policy, we do not provide direct links to commercial products. However, commercial offerings related to IBIS could be noted in a company's Roster entry or in a link on an EIA IBIS Open Forum members Poster link. Bob noted that s2ibis3 many not require an extensive list of enhancements because some of the features of IBIS Version 3.2 are formed by construction of parts of a model. Some extensions would be adding some subparameters that do not impact simulation and to perhaps deal with the [Series MOSFET] and [Series Current] models. Bob plans to continue this discussion at the next meeting. BUG34 - NO ERROR REPORTED FOR MISSING V/I TABLE IN OUTPUT BUFFERS Bob Ross noted that since no revised BUG34 proposal was generated, the discussion was deferred. Matthew Flora's AR is still open. AR - Matthew Flora issue a revised BUG34 to document the conditions where Warning messages are issued. IMIC AND IBIS As previously indicated, Bob Ross indicated that we will have more information after the meeting scheduled on May 12, 1999. We will discuss details on Merge, Linkage, and Independent standards options. Anyone who is interested is invited to attend. Matthew Flora asked for information concerning the history of the IMIC. Bob indicated that we have been aware of IMIC activities since about 1997, and several presentations (some of which are uploaded) have been given at IBIS Summit meetings that are documented in old IBIS minutes. Also the IMIC link (available through the EIA IBIS Home page) also points to some minutes documents. Bob indicated that the IMIC standard is being positioned to deal with power integrity and EMI problems to utilize the additional internal structural details. Raj Raghuram stated that the group is also working with an "ECALS" group on EMI issues. BIRD58.1 - DRIVER SCHEDULE KEYWORD CLARIFICATION Arpad Muranyi indicated that BIRD58 was issued to add a paragraph that was unintentionally omitted. As a result of some e-mail questions and the discussion at previous IBIS teleconference meetings, Arpad issued BIRD58.1 with some additions and rewording for the purposes of clarifying the original intent and not to introduce technical changes. Comments are welcome. Matthew Flora had a few editorial comments which he will provide to Arpad directly. Matthew questioned one clarification change regarding whether the power rails for [Voltage Range], [Pullup Reference], etc. are local to the scheduled model. After some discussion, Bob Ross indicated that that was the original intent and believes ibischk3 conducts the waveform voltage Warning check based on using the local power rails of the scheduled models. Matthew stated that he will check this. In paragraph 7, Matthew was confused about the time reference. After some discussion, we agreed to add the words "of the internal simulator pulse" because this wording is also used later in BIRD58.1. Matthew asked if this internal simulator pulse concept posed a restriction on some simulators. Arpad argued that the idea was consistent with the way simulators use the normal IBIS driver models. Bob Ross added that the simulator pulse widths and polarity could be adjusted so that only the internal simulator rising sequence or falling sequence is processed - if that were of concern in some simulators. Finally, Matthew asked whether the [Driver Schedule] methodology might create simulation discontinuities at the entered delay times. Arpad clarified that there should not be discontinuities since each of the scheduled drivers will have a [Ramp] or [Rising Waveform] and [Falling Waveform] to control the transition shape of the scheduled model operation. The scheduled time delay merely indicates the start of these transitions in a manner similar to how the regular driver [Model] operates. Arpad will collect the comments and issue BIRD58.2. Bob indicated that he will schedule a vote on BIRD58.2 at the next meeting. Also, BIRD58.2 will be referenced as a formal editorial comment to the Version 3.2 letter ballot. AR - Arpad Muranyi collect inputs and issue BIRD58.2. CONNECTOR PROPOSAL REVIEW (No Discussion) NEXT MEETING: The next teleconference meeting will be on Friday, May 28, 1999 from 8:00 AM to 10:00 AM. A vote on BIRD58.2 is scheduled. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentor.com Modeling Engineer, Interconnectix BU of Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 SECRETARY: Matthew Flora (425) 869-2320, Fax: (425) 881-1008 mbflora@hyperlynx.com Senior Engineer, HyperLynx, Inc. 17641 NE 67th Court Redmond, WA 98052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic Systems (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2/3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Wed May 12 10:13:33 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA07439; Wed, 12 May 1999 10:13:31 -0700 (PDT) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id JAA29747; Wed, 12 May 1999 09:14:19 -0700 Message-Id: <3.0.5.32.19990512100738.00b79400@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 12 May 1999 10:07:38 +0000 To: ibis@eda.org, ibis-users@eda.org From: Matthew Flora Subject: DAC99 IBIS Summit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" D A C I B I S S U M M I T M E E T I N G F I R S T A N N O U N C E M E N T DATE: Monday, June 21, 1993 TIME: 8:30 AM - Afternoon CITY: New Orleans, Louisiana LOCATION: Hilton Hotel, New Orleans Riverside, next to Ernest N. Morial Convention Center where the Design Automation Conference (DAC) is being held. ROOM: Chequers LUNCH: Refreshments and Lunch will be provided. AGENDA: The agenda is being planned. Some planned items are: SP-4557 Letter Ballot Comment Resolution based on comments received to date on pending standardization of IBIS Version 3.2. Election of Officers for 1999-2000. Presentations and Discussions on IBIS Topics. So far, tentative presentations are expected on Equation based models and IMIC. We are open to several more. Discussion on major IBIS 4.0 requirements. DAC: DAC is scheduled Monday - Friday, June 21 -25, 1999. The exhibitor portion is open from 10 AM to 6 PM on Monday - Wednesday. So there should be time after the IBIS Summit meeting to visit the show. For more information on DAC99 activities, housing, etc. visit the DAC99 URL. DAC URL: http://www.dac.com/ CALL FOR PRESENTATIONS: We are also open to technical presentations related to any current IBIS activity and to future IBIS needs. We already have several presentations planned. Contact Matthew Flora regarding your presentation: Presenter: Title: Estimated Time: We would like you to provide handouts for the meeting (about 25) and also an electronic copy for archiving. CALL FOR ATTENDEES: Please let Matthew Flora know if you are planning to attend so we have an estimate on food requirements. CONTACT: Matthew Flora mbflora@hyperlynx.com (425) 869-2320 From owner-ibis Thu May 13 05:38:30 1999 Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by server.eda.org (8.8.5/8.8.3) with SMTP id FAA10579 for ; Thu, 13 May 1999 05:38:29 -0700 (PDT) Received: from mailext03.compaq.com by mailext03.compaq.com via smail with esmtp id for ; Thu, 13 May 99 07:32:40 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 27-oct-98) Received: from mail.compaq.com([not looked up]) (peer mailint02.compaq.com[207.18.199.35]) by mailext03.compaq.com with SMTP id rcv000102; Thu, 13 May 1999 07:32:35 -0500 (CDT) Received: from exctay-gh01.bb.dec.com(really [16.52.48.15]) by mail.compaq.com via sendmail with esmtp id for ; Thu, 13 May 99 07:32:05 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 18-dec-97) Received: by exctay-gh01.bb.dec.com with Internet Mail Service (5.5.2559.0) id ; Thu, 13 May 1999 08:32:04 -0400 Message-ID: From: "Haller, Robert" To: "'ibis@eda.org'" Subject: FW: DATE CHANGE to IBIS Users group meeting Date: Thu, 13 May 1999 08:32:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2559.0) Content-Type: text/plain; charset="iso-8859-1" Please note the schedule change for the IBIS user group meeting. Regards, bob >================================================= >Subject: DATE CHANGE to IBIS Users group meeting > > >IBIS Team: > >Ed Sayre and I have run into a serious schedule flaw for >this Thursday's (5/13/99) IBIS meeting. We would like >to reschedule the meeting for: > > Date: Thursday, May 20th > Time: 3:00 PM > Place: NESA (Stow, MA) > Purpose: Get the IBIS User Group > momentum going again and > re-focus our efforts. > > >Let me know if you can make the change. > > >If this poses a serious inconvenience to the team, >perhaps someone else can host the May 13th meeting >at their site. Ed and I would be unable to attend >however. > >Sorry about this change. > >Thanks, > > Kathy Breda & Ed Sayre > >+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ >| NORTH EAST SYSTEMS ASSOCIATES, INC. | >| ------------------------------------- | >| "High Performance Engineering & Design" | >+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ >| Kathy Breda e-mail: breda@nesa.com | >| NESA, Inc. http://www.nesa.com/ | >| 636 Great Road Tel +1.978.897-8787 | >| Stow, MA 01775 USA Fax +1.978.897-5359 | >+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ > ----Original Message----- From: Kathy Breda [mailto:breda@nesa.com] Sent: Wednesday, May 12, 1999 1:32 PM To: Haller, Robert Subject: RE: DATE CHANGE to IBIS Users group meeting Glad you can attend. Please do forward the note! Thanks, Kathy At 03:22 PM 5/11/99 -0400, you wrote: >Kathy, >I can attend. Do you mind if I forward your note to the ibis open forum. I >mentioned that we want to get a phone link, and invited anyone from the open >forum to attend. >regards, >bob >Robert J. Haller >Compaq Computer Corporation >AlphaServer Product Development >Phone: (978) 493-4112 >Fax: (978) 493-0941 >robert.haller@compaq.com From owner-ibis Thu May 20 19:16:44 1999 Received: from bh.kyungpook.ac.kr (bh.kyungpook.ac.kr [155.230.10.2]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA09656 for ; Thu, 20 May 1999 19:16:43 -0700 (PDT) Received: from nature.kyungpook.ac.kr (nature.kyungpook.ac.kr [155.230.12.129]) by bh.kyungpook.ac.kr (8.8.8H1/8.8.8) with SMTP id KAA18657 for ; Fri, 21 May 1999 10:56:01 +0900 (KST) Received: from p13145 by nature.kyungpook.ac.kr (8.6.12h2/8.6.9) id LAA13185; Fri, 21 May 1999 11:13:22 +0900 Message-ID: <000501bea32f$5bba9ee0$910de69b@kyungpook.ac.kr> From: "±Ç¿ø¿Á" To: Subject: Please help me. Date: Fri, 21 May 1999 11:12:09 +0900 Organization: =?EUC-KR?B?sOa6z7Trx9Cxsw==?= =?EUC-KR?B?wPzA2rD4x9Cw+g==?= ASIC Lab. MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by server.eda.org id TAA09657 Hi. First, thank you for useful website to study IBIS. I'm a graduated student of Kyungpook Univ. in South Korea. These days I study IBIS. I want to simulate high frequency circuit.(check signal integrity, ringing effect, etc..) So I try to anaysis circuit using IBIS model. And I try to make model(Spice model) only using IBIS data. But it's very difficuilt for me. I can get IBIS information only ANSI/EIA-656 IBIS Home Page. So I search for IBIS information or reference book. I searched all web site and amazon book strore but can't find. Could tell me some information or reference to study IBIS. Please send mail for me. Anything(Book, Website, Document...) will helpful for me. Thank you. Paul from ROK. From owner-ibis Fri May 21 12:46:33 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA13389 for ; Fri, 21 May 1999 12:46:33 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id MAA07667; Fri, 21 May 1999 12:40:15 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id MAA07602; Fri, 21 May 1999 12:40:12 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3745B69D.3EB28997@mentor.com> Date: Fri, 21 May 1999 12:40:13 -0700 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis@eda.org Subject: IBIS AGENDA 5/28/99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS Open Forum Meeting Agenda for 5/28/99 Bridge Number Reservation # Passcode (916) 356-9200 8-12114 2274622 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Ross/Fleming - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:15 Administrative and Project Discussions International/External Progress - IEC 62014-1 (IBIS Version 2.1) Ross - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) Raghuram/Ross - 93/67/NP IBIS and EMC Simulation Perrin - JEDEC JC-16.2 Modeling and Testing Sessions IBIS (East) Users Group Meetings Edlund IBIS Summit Design Automation Conference Ross - Call for Presentations - Agenda SP-4557 - IBIS Version 3.2 Letter Ballot Ross/Fleming Cookbook Status Peters IBIS Model Review Committee Flora s2ibis2 Maintenance and s2ibis3 Ross New Administrative Issues All 9:00 Technical Discussion IMIC and IBIS Ross/Raghuram/Peters BUG34 - No Error Reported for Missing V/I Tables in Flora Output Buffers BIRD58.2 - Driver Schedule Keyword Clarification Muranyi (Vote) Connector Proposal Status Flora/Crisafulli Number of Points in VT table Muranyi IBIS 4.X Features All New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Peters 9:55 Sign Off From owner-ibis Fri May 28 05:47:27 1999 Received: from carabosse.oleane.net (carabosse.oleane.net [194.2.28.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA10777 for ; Fri, 28 May 1999 05:47:25 -0700 (PDT) Received: from iis000.microdata.fr (mailhost.microprocess.com [62.161.233.21]) by carabosse.oleane.net with ESMTP id OAA08700; Fri, 28 May 1999 14:37:36 +0200 Received: by IIS000.microdata.fr with Internet Mail Service (5.5.1960.3) id ; Fri, 28 May 1999 14:36:56 +0200 Message-ID: <3AC9A1611DF4D211AA8E00105AA56D8A033E61@IIS000.microdata.fr> From: Laurent Bernard To: Laurent Bernard Cc: "'Amul PATEL'" , "'Bertrand BAUDET'" , "'Bruno COLLIGNON'" , "'Bruno COLLIGNON Nouvelle'" , "'Bruno COLLIGNON Vieille'" , "'Bruno BLANCHARD'" , "'Cecile CORMORECHE'" , "'CompactPCI mailing list'" , "'Dave DUCKWORTH'" , "'Florent BRY @wanadoo'" , "'Francois MEYER'" , "'Gerard DECEMBRE'" , "'Gill Ritchie'" , "'Gilles BENZONI'" <100450.3231@compuserve.com>, "'Greg PLANE'" , "'High-Speed Digital Design'" , "'High-Speed Digital Design ''" , "'IBIS at VHDL.org'" , "'IBIS Mailing list'" , "'IBIS User forum'" , "'IBIS Users Forum'" , "'IPC DesignerCouncil'" , "'IPC TechNet'" , "'Jean Marc LAURENT ancienne'" <106537.2407@compuserve.com>, "'Jean Marc LAURENT nouvelle'" , Laurent Bernard , "'Laurent BERNARD @altern.org'" , "'Laurent BERNARD @chez.com'" , "'Laurent BERNARD @usa.net'" , "'Laurent PILATI'" , "'Mailing list CPCI'" , "'Mailing list CPCI ''" , "'Marie-Pierre MEQUINION'" , "'Marie-Pierre MEQUINION @ Price'" , "'Merced Discussion List'" , "'Micro-Wave List'" , "'Mike BRENT'" , "'Multiple recipients of list CHIPDIR-L'" , "'Patrick JOLY'" , "'PCI Mailing List'" , "'Philippe AUCOUTURIER'" , "'RCI'" <100447.1753@compuserve.com>, "'Recipients of EDESIGN digests'" , "'Reseau Anciens Groupe ESIEE'" , "'SCSI symbios mailing list'" , =?iso-8859-1?Q?=27S=E9verine_MAINE_BE/DIF/UIE=27?= , "'Signal Integrity LIST'" , "'Signal Integrity LIST ''" , "'Tasneen MOWJEE'" , "'Thanh Tuan Duong'" , "'Veronique Marchal'" , Gill Ritchie Subject: les adresses Date: Fri, 28 May 1999 14:36:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain From owner-ibis Fri May 28 05:47:29 1999 Received: from carabosse.oleane.net (carabosse.oleane.net [194.2.28.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA10780; Fri, 28 May 1999 05:47:28 -0700 (PDT) Received: from iis000.microdata.fr (mailhost.microprocess.com [62.161.233.21]) by carabosse.oleane.net with ESMTP id OAA08700; Fri, 28 May 1999 14:37:36 +0200 Received: by IIS000.microdata.fr with Internet Mail Service (5.5.1960.3) id ; Fri, 28 May 1999 14:36:56 +0200 Message-ID: <3AC9A1611DF4D211AA8E00105AA56D8A033E61@IIS000.microdata.fr> From: Laurent Bernard To: Laurent Bernard Cc: "'Amul PATEL'" , "'Bertrand BAUDET'" , "'Bruno COLLIGNON'" , "'Bruno COLLIGNON Nouvelle'" , "'Bruno COLLIGNON Vieille'" , "'Bruno BLANCHARD'" , "'Cecile CORMORECHE'" , "'CompactPCI mailing list'" , "'Dave DUCKWORTH'" , "'Florent BRY @wanadoo'" , "'Francois MEYER'" , "'Gerard DECEMBRE'" , "'Gill Ritchie'" , "'Gilles BENZONI'" <100450.3231@compuserve.com>, "'Greg PLANE'" , "'High-Speed Digital Design'" , "'High-Speed Digital Design ''" , "'IBIS at VHDL.org'" , "'IBIS Mailing list'" , "'IBIS User forum'" , "'IBIS Users Forum'" , "'IPC DesignerCouncil'" , "'IPC TechNet'" , "'Jean Marc LAURENT ancienne'" <106537.2407@compuserve.com>, "'Jean Marc LAURENT nouvelle'" , Laurent Bernard , "'Laurent BERNARD @altern.org'" , "'Laurent BERNARD @chez.com'" , "'Laurent BERNARD @usa.net'" , "'Laurent PILATI'" , "'Mailing list CPCI'" , "'Mailing list CPCI ''" , "'Marie-Pierre MEQUINION'" , "'Marie-Pierre MEQUINION @ Price'" , "'Merced Discussion List'" , "'Micro-Wave List'" , "'Mike BRENT'" , "'Multiple recipients of list CHIPDIR-L'" , "'Patrick JOLY'" , "'PCI Mailing List'" , "'Philippe AUCOUTURIER'" , "'RCI'" <100447.1753@compuserve.com>, "'Recipients of EDESIGN digests'" , "'Reseau Anciens Groupe ESIEE'" , "'SCSI symbios mailing list'" , =?iso-8859-1?Q?=27S=E9verine_MAINE_BE/DIF/UIE=27?= , "'Signal Integrity LIST'" , "'Signal Integrity LIST ''" , "'Tasneen MOWJEE'" , "'Thanh Tuan Duong'" , "'Veronique Marchal'" , Gill Ritchie Subject: les adresses Date: Fri, 28 May 1999 14:36:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain From owner-ibis Fri May 28 10:44:59 1999 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA11533 for ; Fri, 28 May 1999 10:44:37 -0700 (PDT) Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id KAA12733 for ; Fri, 28 May 1999 10:38:42 -0700 (PDT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 May 1999 10:38:41 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512703BB0C47@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'ibis@eda.org'" Subject: BIRD58.3 Date: Fri, 28 May 1999 10:38:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEA930.ED018C06" 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_01BEA930.ED018C06 Content-Type: text/plain; charset="iso-8859-1" To All, Here is the approved BIRD58.3 as an attachment. If any of you have problems receiving it without corruption, please let me know and I will re-send it in the body of the text. Arpad ======================================================================== ------_=_NextPart_000_01BEA930.ED018C06 Content-Type: text/plain; name="BIRD58_3.TXT" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="BIRD58_3.TXT" ************************************************************************= ****** ************************************************************************= ****** BIRD ID#: 58.3 ISSUE TITLE: Driver Schedule keyword clarification REQUESTER: Arpad Muranyi, Intel Corporation DATE SUBMITTED: 3/2/99, 5/5/99, 5/10/99, 5/28/99 DATE ACCEPTED BY IBIS OPEN FORUM: 5/28/99 ************************************************************************= ****** ************************************************************************= ****** STATEMENT OF THE ISSUE: The [Driver Schedule] section of the latest IBIS specification (v3.2) = does not provide enough information to the model maker and EDA tool vendor = on essential details of this keyword. The specification can be = interpreted in many different ways which can lead to serious discrepancies and = consequences. ************************************************************************= ****** STATEMENT OF THE RESOLVED SPECIFICATIONS: A paragraph from BIRD35.3, which explains most of the gray areas, seems = to have been inadvertently left out from the specification. On top of = that, the usage rules section was fairly unclear to many readers, resulting in a = lot of questions even in the presence of the missing paragraph. For this reason, the usage rules section was almost completely = rewritten, in addition to pasting the missing paragraph from BIRD35.3 into it. The additional words or rewording do not change the original intent = behind the keyword. The intention in these changes was only to spell out more clearly how the keyword should be used so that the model maker and EDA = tool vendor could be in agreement on how the model works. The new section(s) of BIRD58.1 are marked with a "*" character at the beginning of each line. The new section(s) of BIRD58.2 are marked with = two asterisks "**", and the new section(s) of BIRD58.3 are marked with = three asterisks "***" at the beginning of each line. |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D | Keyword: [Driver Schedule] | Required: No | Description: Describes the relative model switching sequence for = referenced | models to produce a multi-staged driver. | Usage Rules: The [Driver schedule] keyword establishes a = hierarchical order | between models and should be placed under the [Model] = which=20 | acts as the top-level model. The scheduled models are = then=20 | referenced from the top-level model by the [Driver = Schedule] | keyword. | |* When a multi-staged buffer is modeled using the [Driver |* Schedule] keyword, all of its stages (including the = first |* stage, or normal driver) have to be modeled as = scheduled |* models. |* |* If there is support for this feature in a simulator, = the |* [Driver Schedule] keyword will cause it to use the |* [Pulldown], [Pulldown Reference], [Pullup], [Pullup |* Reference], [Voltage Range], [Ramp], [Rising Waveform] = and |* [Falling Waveform] keywords from the scheduled models |* instead of the top-level model, according to the timing |* relationships described in the [Driver Schedule] = keyword.=20 |* Consequently, the keywords in the above list will be = ignored |* in the top-level model. Also, all other keywords not = shown |* in the above list will be ignored in the scheduled = model(s). |* |* However, both the top-level and the scheduled model(s) = have |** to be complete models, i.e. all of the required = keywords |** must be present and follow the syntactical rules. |* |* For backwards compatibility reasons and for simulators = which |* do not support multi-staged switching, the keywords in = the |* above list can be used in the top-level [Model] to = describe |* the overall characteristics of the buffer as if it was = a |* composite model. It is not guaranteed, however, that = such a |* top-level model will yield the same simulation results = as a |* full multi-stage model. It is recommended that a = "golden | waveform" for the device consisting of a [Rising = Waveform] | table and a [Falling Waveform] table be supplied in the | top-level model to serve as a reference for validation. | |* Even though some of the keywords are ignored in the |* scheduled model, it may still make sense in some cases = to |* supply correct data with them. One such situation = would |* arise when a [Model] is used both as a regular = top-level |* model as well as a scheduled model. | | | The [Driver Schedule] table consists of five columns. = The | first column contains the model names of other models = that | exists in the .ibs file. The remaining four columns = describe | delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and |** Fall_off_dly. The t=3D0 time of each delay is the = event when |** the simulator's internal pulse initiates a rising or = falling |** transition. All specified delay values must be equal = to or |** greater than 0. There are only five valid combinations = in |** which these delay values can be defined: |* |* 1) Rise_on_dly with Fall_on_dly |* 2) Rise_off_dly with Fall_off_dly |* 3) Rise_on_dly with Rise_off_dly |** 4) Fall_on_dly with Fall_off_dly |* 5) All four delays defined |* (be careful about correct sequencing) |* |* The four delay parameters have the meaning as described |* below. (Note that this description applies to buffer = types |* which have both pullup and pulldown structures. For = those |* buffer types which have only a pullup or pulldown = structure, |** the description for the missing structure can be = omitted.) |* |* Rise_on_dly is the amount of time that elapses from the |** internal simulator pulse initiating a RISING edge to = the |* t=3D0 time of the waveform or ramp that turns the IV = curve of |* the PULLUP device ON, and the t=3D0 time of the = waveform or |* ramp that turns the IV curve of the PULLDOWN device OFF = (if |*** they were not already turned ON and OFF, respectively, = by |*** another event). |* |* Rise_off_dly is the amount of time that elapses from = the |** internal simulator pulse initiating a RISING edge to = the |* t=3D0 time of the waveform or ramp that turns the IV = curve of |* the PULLUP device OFF, and the t=3D0 time of the = waveform or |* ramp that turns the IV curve of the PULLDOWN device ON = (if |*** they were not already turned ON and OFF, respectively, = by |*** another event). |* |* Fall_on_dly is the amount of time that elapses from the |** internal simulator pulse initiating a FALLING edge to = the |* t=3D0 time of the waveform or ramp that turns the IV = curve of |* the PULLDOWN device ON, and the t=3D0 time of the = waveform or |* ramp that turns the IV curve of the PULLUP device OFF = (if |*** they were not already turned ON and OFF, respectively, = by |*** another event). |* |* Fall_off_dly is the amount of time that elapses from = the |** internal simulator pulse initiating a FALLING edge to = the |* t=3D0 time of the waveform or ramp that turns the IV = curve of |* the PULLDOWN device OFF, and the t=3D0 time of the = waveform or |* ramp that turns the IV curve of the PULLUP device ON = (if |*** they were not already turned ON and OFF, respectively, = by |*** another event). |* |* Note that some timing combinations may only be possible = if |* the two halves of a complementary buffer are modeled=20 |* separately as two open_* models. |* |* |** Use 'NA' when no delay value is applicable. For each |** scheduled model the transition sequence must be = complete, |** i.e., the scheduled model must return to its initial = state. | |** No [Driver Schedule] table may reference a model which |** itself has within it a [Driver Schedule] keyword. | | Other Notes: The added models typically consist of Open_sink = (Open_drain)=20 | or Open_source models to provide sequentially increased = drive | strengths. The added drive may be removed within the = same | transition for a momentary boost or during the opposite = | transition. | | The syntax also allows for reducing the drive strength. = | | Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, | Fall_off_dly parameters are single value parameters, so = | typical, minimum and maximum conditions cannot be = described | with them directly. In order to account for those = effects, | one can refer to the fastest waveform table with the = delay | number and then insert an appropriate amount of = horizontal | lead in section in those waveforms which need more = delay. | |* Notice that the C_comp parameter of a multi-stage = buffer is |* defined in the top-level model. The value of C_comp |* therefore includes the total capacitance of the entire |* buffer, including all of its stages. Since the rising = and |* falling waveform measurements include the effects of |* C_comp, each of these waveforms must be generated with = the |* total C_comp present, even if the various stages of the |* buffer are characterized individually. | | Note: In a future release, the [Driver Schedule] = keyword may | be replaced by a newer method of specification that is=20 | consistent with some other planned extensions. = However, the | [Driver Schedule] syntax will continue to be supported. |-----------------------------------------------------------------------= ------ [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged = transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high=20 | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D ************************************************************************= ****** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: An attempt to build an IBIS 3.2 buffer model for a three-stage buffer = using the [Driver Schedule] keyword failed. The initial testing of this = model with the tools of two EDA vendors showed only two of the three stages working. This happened because the first stage of the buffer was = placed into the "main" [Model] section of the IBIS model due to a personal interpretation of the IBIS 3.2 spec. After consulting with several = people, it became apparent that the specification does not mention some of the = key information that is necessary to build a correct IBIS model for this = kind of a buffer. The following paragraph in BIRD35.3 contains the missing information = which is necessary for making correct IBIS models using the [Driver Schedule] keyword. This section seems to have been accidentally left out from = the specification, and should be pasted into the appropriate location as = shown above. "The new keyword [Driver Schedule] provides a syntax for sequencing = other models. This is given as a keyword under the [Model] keyword. It = overrides any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and=20 [Falling Waveform] data for that model. However, the required tables = for [Model] are still required for backwards compatibility reasons for = simulators which do not support multi-staged switching. This information can be = used as a composite model cross-check, although the resulting model may not perform in the same manner as the multi-stage model." Numerous EMAIL responses were posted after BIRD58 was issued on 3-2-99. Arpad Muranyi had numerous telephone conversations with Bob Ross and = posted an EMAIL response on 3-30-99. This response was an attempt to = summarize the issues and was discussed in a subsequent IBIS Open Forum teleconference meeting. Arpad Muranyi received an AR to issue BIRD58.1 (this = document) based on the additional feedback. BIRD58.1 was discussed in the Open Forum teleconference on 5-7-99. = BIRD58.2 is a result of the editorial changes that were requested in that = meeting. BIRD58.3 has a few new editorial changes which were requested at the = Open Forum teleconference on 5-28-99 before voting took place. ************************************************************************= ****** ANY OTHER BACKGROUND INFORMATION: Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS specification is missing the description of some of the usage rules = which were documented in BIRD35.3 and was implemented accordingly in ICX. ************************************************************************= ****** ------_=_NextPart_000_01BEA930.ED018C06--