From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #62 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Tuesday, July 12 2005 Volume 01 : Number 062 ---------------------------------------------------------------------- Date: Tue, 5 Jul 2005 17:30:50 +0530 From: "Subramanian, Sivaramakrishnan \(Sivaramakrishnan\)" Subject: [IBIS-Users] DC sweep This is a multi-part message in MIME format. - ------_=_NextPart_001_01C58159.2FFA7E08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, How can I extract V-I curves when the O/P of my buffer is edge-triggered and not level-sensitive? Basically, I have to do DC sweep to extract these curves.But I cannot=20 connect my inputs to steady voltage values as the O/P is edge-triggered, which needs transient analysis. Would anyone of you please let me know how to go about these buffers to extract VI curves? Thanks in advance, Sivaram =20 - ------_=_NextPart_001_01C58159.2FFA7E08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DC sweep

Hi all,

How can I extract V-I curves when the = O/P of my buffer is edge-triggered
and not level-sensitive?

Basically, I have to do DC sweep to = extract these curves.But I cannot
connect my inputs to steady voltage = values as the O/P is edge-triggered, which
needs transient analysis.

Would anyone of you please let me know = how to go about these buffers to extract
VI curves?

Thanks in advance,
Sivaram

 

- ------_=_NextPart_001_01C58159.2FFA7E08-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 5 Jul 2005 09:25:40 -0400 From: "Andrew Ingraham" Subject: [IBIS-Users] Re: [IBIS] DC sweep This is a multi-part message in MIME format. - ------=_NextPart_000_0208_01C58143.82A0DEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DC sweepSivaram, It sounds like you are confusing the purpose of sweeping the V-I curves. = It has nothing to do with edge-triggered or level-sensitive. The only thing you apply the swept voltage to, is the IC pin (actually, = the bonding pad). If your IC has an output buffer connected to that = pin, the swept voltage goes to the output of that buffer, but NOT to its = input. Its input should be connected to the normal things you would = normally connect to the input of that buffer; not the swept DC source. The purpose of the DC sweep is to measure the current vs. voltage = relationship at the pin. If the pin has an output or I/O buffer = connected to the pin, then that I-V relationship depends very strongly = on the state of the output buffer, which might be inactive (hi-Z), = driving low, or driving high; and you need to extract the I-V = relationships separately in each of those states. You need to place the = output buffer into each of those states (through whatever internal = controls the buffer has), one at a time, and then sweep the voltage at = the pin and measure the current, each time with the buffer held in one = state (i.e., constant voltages applied to its edge-triggered or = level-sensitive internal nodes). Then change those internal nodes to = put the buffer into its next state, and sweep the external voltage = again. If the pin is just an input buffer, then (unless the buffer has = feedback, like a "bus-hold" device, which makes it problematic for IBIS) = it doesn't make much difference what the input buffer is doing, whether = it is toggling, etc. Just sweep the input pin's voltage and measure the = input current. Hope this helps. Regards, Andy How can I extract V-I curves when the O/P of my buffer is = edge-triggered=20 and not level-sensitive?=20 Basically, I have to do DC sweep to extract these curves.But I cannot=20 connect my inputs to steady voltage values as the O/P is = edge-triggered, which=20 needs transient analysis.=20 Would anyone of you please let me know how to go about these buffers = to extract=20 VI curves?=20 Thanks in advance,=20 Sivaram=20 =20 - ------=_NextPart_000_0208_01C58143.82A0DEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DC sweep
Sivaram,
 
It sounds like you are confusing the = purpose of=20 sweeping the V-I curves.  It has nothing to do with edge-triggered = or=20 level-sensitive.
 
The only thing you apply the swept = voltage to, is=20 the IC pin (actually, the bonding pad).  If your IC has an = output=20 buffer connected to that pin, the swept voltage goes to the = output of=20 that buffer, but NOT to its input.  Its input should be connected=20 to the normal things you would normally connect to the input of = that=20 buffer; not the swept DC source.
 
The purpose of the DC sweep is to = measure the=20 current vs. voltage relationship at the pin.  If the pin has an = output or=20 I/O buffer connected to the pin, then that I-V relationship depends very = strongly on the state of the output buffer, which might be inactive = (hi-Z),=20 driving low, or driving high; and you need to extract the I-V = relationships=20 separately in each of those states.  You=20 need to place the output buffer into each of those states (through = whatever=20 internal controls the buffer has), one at a time, and then sweep the = voltage at=20 the pin and measure the current, each time with the buffer held in one = state=20 (i.e., constant voltages applied to its edge-triggered or = level-sensitive=20 internal nodes).  Then change = those internal=20 nodes to put the buffer into its next state, and sweep the external = voltage=20 again.
 
If the pin is just an input = buffer, then=20 (unless the buffer has feedback, like a "bus-hold" device, which makes = it=20 problematic for IBIS) it doesn't make much difference what the input = buffer is=20 doing, whether it is toggling, etc.  Just sweep the input pin's = voltage and=20 measure the input current.
 
Hope this helps.
 
Regards,
Andy
 
 

How can I extract V-I curves when the = O/P of my=20 buffer is edge-triggered
and = not=20 level-sensitive?

Basically, I have to do DC sweep to = extract these=20 curves.But I cannot
connect my = inputs to=20 steady voltage values as the O/P is edge-triggered, which =
needs transient analysis.

Would anyone of you please let me know = how to go=20 about these buffers to extract
VI=20 curves?

Thanks in advance,
Sivaram

 

- ------=_NextPart_000_0208_01C58143.82A0DEE0-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 05 Jul 2005 19:23:28 +0530 From: Akhilesh CHANDRA Subject: [IBIS-Users] Re: [IBIS] DC sweep - --------------070909030303080907010104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Sivaram, You can do one think use .save feature in your simulator. First apply a transient at i/p and see when your o/p is at steady state after this just use ,save feature to save voltage at all input node. you can save these voltage in one file and use this file in your simulation. It will give you good results. Regards Akhilesh Subramanian, Sivaramakrishnan (Sivaramakrishnan) wrote: > Hi all, > > How can I extract V-I curves when the O/P of my buffer is edge-triggered > and not level-sensitive? > > Basically, I have to do DC sweep to extract these curves.But I cannot > connect my inputs to steady voltage values as the O/P is > edge-triggered, which > needs transient analysis. > > Would anyone of you please let me know how to go about these buffers > to extract > VI curves? > > Thanks in advance, > Sivaram > > > - --------------070909030303080907010104 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Sivaram,

   You can do one think use .save feature in your simulator. First apply a transient at i/p and see when your o/p is at steady state after this just use ,save feature to save voltage at all input node. you can save these voltage in one file and use this file in your simulation. It will give you good results.

Regards
Akhilesh

Subramanian, Sivaramakrishnan (Sivaramakrishnan) wrote:
DC sweep

Hi all,

How can I extract V-I curves when the O/P of my buffer is edge-triggered
and not level-sensitive?

Basically, I have to do DC sweep to extract these curves.But I cannot
connect my inputs to steady voltage values as the O/P is edge-triggered, which
needs transient analysis.

Would anyone of you please let me know how to go about these buffers to extract
VI curves?

Thanks in advance,
Sivaram

 


- --------------070909030303080907010104-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 5 Jul 2005 10:18:51 -0600 From: rrwolff@micron.com Subject: [IBIS-Users] [IBIS] Open forum minutes (06/24/05) This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5817D.3B4D33C5 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5817D.3B4D33C5" - ------_=_NextPart_002_01C5817D.3B4D33C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <>=20 - ------_=_NextPart_002_01C5817D.3B4D33C5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [IBIS] Open forum minutes (06/24/05)

= <<m062405.txt>>

- ------_=_NextPart_002_01C5817D.3B4D33C5-- - ------_=_NextPart_001_01C5817D.3B4D33C5 Content-Type: text/plain; name="m062405.txt" Content-Transfer-Encoding: base64 Content-Description: m062405.txt Content-Disposition: attachment; filename="m062405.txt" REFURTogMDYvMzEvMDUNCg0KU1VCSkVDVDogSnVuZSAyNCwgMjAwNSBFSUEgSUJJUyBPcGVuIEZv cnVtIE1lZXRpbmcgTWludXRlcw0KDQpWT1RJTkcgTUVNQkVSUyBBTkQgMjAwNSBQQVJUSUNJUEFO VFMNCkFjdGVsICAgICAgICAgICAgICAgICAgICAgICAgICAgIFByYWJodSBNb2hhbg0KQWdlcmUg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKE5pcmF2IFBhdGVsKQ0KQU1EICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgV2FzaW0gVWxsYWgNCkFuc29mdCBDb3Jwb3JhdGlvbiAgICAgICAg ICAgICAgIE1pY2hhZWwgQnJlbm5lbWFuDQpBcHBsaWVkIFNpbXVsYXRpb24gVGVjaG5vbG9neSAg ICBOb3JpbyBNYXRzdWkNCkNhZGVuY2UgRGVzaWduIFN5c3RlbXMgICAgICAgICAgIExhbmNlIFdh bmcsIFtEb25hbGQgVGVsaWFuXSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SGVpa28gRHVkZWssIFNoYW5nbGkgV3UqLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBEcmFnb3NsYXYgTWlsb3NldmVjLCBLZW4gV2lsbGlzDQpDaXNjbyBTeXN0ZW1zICAgICAg ICAgICAgICAgICAgICBTeWVkIEh1cSosIE1pa2UgTGFCb250ZSwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVG9kZCBXZXN0ZXJob2ZmLCBaaGlwaW5nIFlhbmcsDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZpbnUgQXJtdW11Z2hhbSwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2FsbWFuIEppdmEsIFNhdGlzaCBQcmF0YXBuZW5pLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbC15b3VuZyBQYXJrLCBTZXJnaW8g Q2FtZXJsbywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGhpbGxpcGUgU29j aG91eCwgRWRkaWUgV3UsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEd1cnBy ZWV0IEh1bmRhbCwgSmF5YW50aGkgTmF0YXJhamFuDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEFiZHVsUmFobWFuIFJhZmlxDQpGbHVlbnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAoQ2hldGFuIERlc2FpKQ0KSGl0YWNoaSBVTFNJIFN5c3RlbXMgICAgICAgICAgICAgS2F6 dXlvc2hpIFNob2ppDQpIdWF3ZWkgICAgICAgICAgICAgICAgICAgICAgICAgICAoSmlhbmcgWGlh bmcgWmhvbmcpDQpJQk0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoV2VzbGV5IE1hcnRp biksIEguIEpvaG4gQmVhdHR5DQpJbnRlZ3JhdGVkIENpcmN1aXQgU3lzdGVtcyAoSUNTKSAoRGFu IENsZW1lbnRpKQ0KSW50ZWwgQ29ycG9yYXRpb24gICAgICAgICAgICAgICAgTWljaGFlbCBNaXJt YWsqLCBBcnBhZCBNdXJhbnlpKiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U3VyZXNoIENoYW5kcmFzZWtoYXINCkxTSSBMb2dpYyAgICAgICAgICAgICAgICAgICAgICAgIEZy YW5rIEdhc3BhcmlrKiwgV2lsbGlhbSBMYXUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE1pa2UgSmVua2lucywgUmVnaW5hbGQgQ293bGV5LA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBLdXN1bWFrdW1hcmkgTWF0dGENCk1hcnZlbGwgICAgICAgICAgICAg ICAgICAgICAgICAgIEl0emlrIFBlbGVnKg0KTWVudG9yIEdyYXBoaWNzICAgICAgICAgICAgICAg ICAgSm9obiBBbmd1bG8sIEd1eSBkZSBCdXJnaCwgSWFuIERvZGQqLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBTdGV2ZW4gTWNLaW5uZXksIEtpbSBPd2VuLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVwaGFuZSBSb3Vzc2VhdQ0KTWljcm9uIFRlY2hu b2xvZ3kgICAgICAgICAgICAgICAgUmFuZHkgV29sZmYqLCBQYXVsIEdyZWdvcnkNCk5FQyBFbGVj dHJvbmljcyBDb3Jwb3JhdGlvbiAgICAgIFRha2VzaGkgV2F0YW5hYmUsIExvcmkgQXNrZXcsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRha3VybyBUc3VqaWthd2ENClBhbmFz b25pYyAgICAgICAgICAgICAgICAgICAgICAgIEF0c3VqaSBJdG8NClNhbXRlYyAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtPdHRvIEJlbm5pZ10NClNpZW1lbnMgQUcgICAgICAgICAgICAgICAg ICAgICAgIEVja2hhcmQgTGVuc2tpKiwgS2F0amEgS29sbGVyKg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNYW5mcmVkIE1hdXJlciwgSGVpbnogSWJvd3NraSwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgV29sZmdhbmcgUm9obWVyLCBLbGF1cyBIdWVibmVy DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwgS2luZGlqDQogICBT aWVtZW5zIE1lZGljYWwgICAgICAgICAgICAgICBEYXZpZCBMaWVieQ0KU2lnbmFsIEludGVncml0 eSBTb2Z0d2FyZSAgICAgICAgUm9iZXJ0IEhhbGxlciwgRG91Z2xhcyBCdXJucywNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFycnkgS2F0eiwgTWlrZSBNYXllcg0KU2lncml0 eSAgICAgICAgICAgICAgICAgICAgICAgICAgU2FtIENoaXR3b29kLCBKaW5nIFRpbmcsIFJheW1v bmQgQ2hlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKaWFndWFuIEZhbmcs IFRlbyBZYXRtYW4NClNpbGVnbyAgICAgICAgICAgICAgICAgICAgICAgICAgIChKb2UgRnJvbmll d3NraSkNClNpbGljb24gSW1hZ2UgICAgICAgICAgICAgICAgICAgIChPb2sgS2ltKQ0KU3lub3Bz eXMgICAgICAgICAgICAgICAgICAgICAgICAgV2FycmVuIFdvbmcsIEFuZHkgVGFpDQpUZXJhc3Bl ZWQgQ29uc3VsdGluZyBHcm91cCAgICAgICBCb2IgUm9zcyosIFNjb3R0IE1jTW9ycm93LA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUb20gRGFnb3N0aW5vDQpYaWxpbnggICAg ICAgICAgICAgICAgICAgICAgICAgICBSYXkgQW5kZXJzb24sIFNhbmpheSBNZWh0YQ0KWnVrZW4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljaGFlbCBTY2hhZWRlciwgUmFsZiBCcnVlbmlu Zw0KDQpPVEhFUiBQQVJUSUNJUEFOVFMgSU4gMjAwNToNCkFsdGVyYSAgICAgICAgICAgICAgICAg ICAgICAgICAgIEtoYWxpZCBBbnNhcmkNCkJheXNpZGUgRGVzaWduICAgICAgICAgICAgICAgICAg IEtldmluIFJvc2VsbGUNCkNlbHNpb25pWCAgICAgICAgICAgICAgICAgICAgICAgIEtlbGxlZSBD cmlzYWZ1bGxpDQpEZWxsICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdWJyZXkgU3Bhcmtt YW4qDQpFTUMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCcmlhbiBBcnNlbmF1bHQsIERh bmllbCBOaWxzc29uLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKYXNvbiBQ cml0Y2hhcmQsIEppbmh1YSBDaGVuDQpFbnRlcmFzeXMgTmV0d29ya3MgICAgICAgICAgICAgICBG YWJyaXppbyBaYW5lbGxhDQpFUEZMICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGFpbiBW YWNob3V4DQpGcmVlc2NhbGUgICAgICAgICAgICAgICAgICAgICAgICBKb24gQnVybmV0dA0KRnVq aXRzdSBTaWVtZW5zIENvbXB1dGVycyAgICAgICAgTWFydGluIFJhbW1lDQpHRUlBICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoQ2hyaXMgRGVuaGFtKQ0KR3JlZW4gU3RyZWFrIFByb2dyYW1z ICAgICAgICAgICAgTHlubmUgR3JlZW4qDQpJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgICAgICAg ICBUaG9tYXMgU3RlaW5lY2tlLCBNaW5lYSBHb3Nwb2Rpbm92YSwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQW1pciBNb3RhbWVkaSwgWWFubiBaaW5zaXVzLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDaHJpc3RpYW4gU3BvcnJlciwgUmFkb3ZhbiBWdWxl dGljDQpJTlNBIFRvdWxvdXNlICAgICAgICAgICAgICAgICAgICBFdGllbm5lIFNpY2FyZA0KSk1E IEludGVybmF0aW9uYWwgICAgICAgICAgICAgICAgSm9lIFNvY2hhDQpLQVcgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBLYXp1aGlrbyBLdXN1bm9raQ0KTGV2ZW50aGFsIERlc2lnbiAgICAg ICAgICAgICAgICAgUm95IExldmVudGhhbA0KTmV0TG9naWMgICAgICAgICAgICAgICAgICAgICAg ICAgRXJpYyBIc3UNCk5va2lhICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVybm8gTGFodGVl bm1hdGksIFRhcGFuaSB2b24gUmF1bmVyDQpOb3J0aCBDYXJvbGluYSBTdGF0ZSBVbml2LiAgICAg ICBBbWJyaXNoIFZhcm1hDQpQb2xpdGVjbmlvIGRpIFRvcmlubyAgICAgICAgICAgICBJZ29yIFN0 aWV2YW5vDQpTaTIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdW1pdCBEYXNHdXB0YQ0K U2lsaWNvbiBCYW5kd2lkdGggICAgICAgICAgICAgICAgW0tpbSBIZWxsaXdlbGxdDQpTdW4gTWlj cm9zeXN0ZW1zICAgICAgICAgICAgICAgICBHdXN0YXZvIEJsYW5kbw0KVGltZSBEb21haW4gQW5h bHlzaXMgU3lzdGVtcyAgICAgRGltYSBTbW9seWFuc2t5LCBTdGV2ZSBDb3JleQ0KV2VzdGVybiBE aWdpdGFsICAgICAgICAgICAgICAgICAgTW9oYW1tYWQgQWxpDQpJbmRlcGVuZGVudCAgICAgICAg ICAgICAgICAgICAgICBCZXJuaGFyZCBVbmdlciAoU2llbWVucyByZXRpcmVkKSwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgS2ltIEhlbGxpd2VsbA0KDQpJbiB0aGUgbGlzdCBh Ym92ZSwgYXR0ZW5kZWVzIGF0IHRoZSBtZWV0aW5nIGFyZSBpbmRpY2F0ZWQgYnkgKi4NClByaW5j aXBhbCBtZW1iZXJzIG9yIG90aGVyIGFjdGl2ZSBtZW1iZXJzIHdobyBoYXZlIG5vdCBhdHRlbmRl ZCBhcmUgaW4NCnBhcmVudGhlc2VzLiBQYXJ0aWNpcGFudHMgd2hvIG5vIGxvbmdlciBhcmUgaW4g dGhlIG9yZ2FuaXphdGlvbiBhcmUgaW4NCnNxdWFyZSBicmFja2V0cy4NCg0KVVBDT01JTkcgTUVF VElOR1MNClRoZSBicmlkZ2UgbnVtYmVycyBmb3IgZnV0dXJlIElCSVMgdGVsZWNvbmZlcmVuY2Vz IGFyZSBhcyBmb2xsb3dzOg0KDQogICAgICAgRGF0ZSAgICAgICAgICBUZWxlcGhvbmUgTnVtYmVy ICAgIEJyaWRnZSAjICAgICBQYXNzY29kZQ0KICAgSnVseSAxNSwgMjAwNSAgICAgMS05MTYtMzU2 LTI2NjMgICAgICAgIDEgICAgICAgICAgOTY2LTMxODENCg0KQWxsIG1lZXRpbmdzIGFyZSA4OjAw IEFNIHRvIDk6NTUgQU0gVVMgUGFjaWZpYyBUaW1lLiAgTWVldGluZyBhZ2VuZGFzDQphcmUgdHlw aWNhbGx5IGRpc3RyaWJ1dGVkIHNldmVuIGRheXMgYmVmb3JlIGVhY2ggT3BlbiBGb3J1bS4gIE1p bnV0ZXMNCmFyZSB0eXBpY2FsbHkgZGlzdHJpYnV0ZWQgd2l0aGluIHNldmVuIGRheXMgb2YgdGhl IGNvcnJlc3BvbmRpbmcNCm1lZXRpbmcuICBXaGVuIGNhbGxpbmcgaW50byB0aGUgbWVldGluZywg cHJvdmlkZSB0aGUgYnJpZGdlIG51bWJlciBhbmQNCnBhc3Njb2RlIGF0IHRoZSBhdXRvbWF0ZWQg cHJvbXB0cy4gIElmIGFza2VkIGJ5IGFuIG9wZXJhdG9yLCBwbGVhc2UNCnJlcXVlc3QgdG8gam9p biB0aGUgSUJJUyBPcGVuIEZvcnVtIGhvc3RlZCBieSBNaWNoYWVsIE1pcm1hay4NCkZvciBpbnRl cm5hdGlvbmFsIGRpYWwtaW4gbnVtYmVycywgcGxlYXNlIGNvbnRhY3QgTWljaGFlbCBNaXJtYWsu DQoNCk5PVEU6ICJBUiIgPSBBY3Rpb24gUmVxdWlyZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tTUlOVVRFUy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJ TlRST0RVQ1RJT05TIEFORCBNRUVUSU5HIFFVT1JVTQ0KTm8gbmV3IG1lbWJlcnMuDQoNCg0KQ0FM TCBGT1IgUEFURU5UUw0KTWljaGFlbCBNaXJtYWsgY2FsbGVkIGZvciBhbnkgcGF0ZW50cyBvciBw ZW5kaW5nIHBhdGVudHMgcmVsYXRlZCB0byB0aGUgSUJJUw0KVmVyc2lvbiAzLjIsIDQuMCwgNC4x LCBvciBJQ00gMS4wIHNwZWNpZmljYXRpb25zLiAgTm8gcGF0ZW50cyB3ZXJlIGRlY2xhcmVkLg0K DQoNCk1FTUJFUlNISVAgVVBEQVRFIEFORCBUUkVBU1VSRVInUyBSRVBPUlQNCk1pY2hhZWwgTWly bWFrIHJlcG9ydGVkIHRoYXQgd2UgYXJlIG9mZmljaWFsbHkgYXQgMjggbWVtYmVycy4gIEEgcmVx dWVzdCBmb3INCmFuIGludm9pY2UgZnJvbSBHcmVlbiBTdHJlYWsgUHJvZ3JhbXMgaXMgYmVpbmcg cHJvY2Vzc2VkLiAgTWljaGFlbA0KZW5jb3VyYWdlZCBwZW9wbGUgdG8gaGVscCBmaW5kIG5ldyBt ZW1iZXJzLiAgVGhlIERBQyBJQklTIFN1bW1pdCBDaGFpcidzDQpyZXBvcnQgY29udGFpbnMgZGV0 YWlsZWQgaW5mb3JtYXRpb24gb24gdGhlIGJ1ZGdldC4NCg0KDQpSRVZJRVcgT0YgTUlOVVRFUyBB TkQgQVJTDQpNaWNoYWVsIE1pcm1hayByZXZpZXdlZCB0aGUgbWludXRlcyBvZiB0aGUgSnVuZSAz LCAyMDA1IElCSVMgT3BlbiBGb3J1bQ0KdGVsZWNvbmZlcmVuY2UuICBUaGUgbWludXRlcyBvZiB0 aGUgbWVldGluZyB3ZXJlIGFwcHJvdmVkIHdpdGhvdXQgY2hhbmdlcy4NCg0KDQpQUkVTUyBBTkQg V0VCIFBBR0UgVVBEQVRFUw0KU3llZCBIdXEgcmVwb3J0ZWQgdGhhdCB0aGUgZXZlbnRzIHBhZ2Ug d2FzIHVwZGF0ZWQgdG8gbW92ZSB0aGUgREFDIGV2ZW50DQpsaXN0aW5nLg0KDQoNCk1BSUxJTkcg TElTVCBBRE1JTklTVFJBVElPTg0KQm9iIFJvc3MgcmVwb3J0ZWQgdGhhdCBldmVyeXRoaW5nIGlz IHJ1bm5pbmcgbm9ybWFsbHkuDQoNCg0KTkVXIE1PREVMUyBBVkFJTEFCTEUsIExJQlJBUlkgVVBE QVRFDQpNaWNoYWVsIE1pcm1hayByZXBvcnRlZCB0aGF0IExhbmNlIFdhbmcgaGFzIHVwZGF0ZWQg dGhlIGxpYnJhcnkgdG8gY2hhbmdlDQpzb21lIGxpbmtzLg0KDQoNCk1JU0NFTExBTlkvQU5OT1VO Q0VNRU5UUw0KQm9iIFJvc3MgcmVxdWVzdGVkIHRvIGRpc2N1c3MgdGhlIGxpY2Vuc2luZyBvZiB0 aGUgcGFyc2VyIHNvZnR3YXJlLiAgQWxzbywNCmhlIG1lbnRpb25lZCB0aGF0IHRoZSBtZW1iZXJz aGlwIHJvc3RlciBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZsZWN0IHdoaWNoDQptZW1iZXJzIGhh dmUgbm90IHBhaWQgZm9yIHRoZSBjdXJyZW50IHllYXIncyBtZW1iZXJzaGlwLg0KDQoNCk9QRU5T IEZPUiBORVcgSVNTVUVTDQpOb25lLg0KDQoNCkVMRUNUSU9OIFJFU1VMVFMgQU5EIDIwMDUtMjAw NiBPRkZJQ0VSUw0KTWljaGFlbCBNaXJtYWsgYW5ub3VuY2VkIHRoYXQgdGhlIG9mZmljZXJzIGhh dmUgbm90IGNoYW5nZWQgZnJvbSB0aGUNCnByZXZpb3VzIHllYXIuICBUaGUgb2ZmaWNlcnMgYXJl Og0KSUJJUyBDaGFpcjogTWljaGFlbCBNaXJtYWsNClZpY2UgQ2hhaXI6IFN5ZWQgSHVxDQpTZWNy ZXRhcnk6ICBSYW5keSBXb2xmZg0KTGlicmFyaWFuOiAgTGFuY2UgV2FuZw0KV2VibWFzdGVyOiAg U3llZCBIdXENClBvc3RtYXN0ZXI6IEJvYiBSb3NzDQoNCk1pY2hhZWwgZXhwcmVzc2VkIHRoYW5r cyB0byB0aGUgb2ZmaWNlcnMgZm9yIHRoZWlyIHdvcmsgb3ZlciB0aGUgbGFzdCB5ZWFyLg0KDQpJ TlRFUk5BVElPTkFML0VYVEVSTkFMIFBST0dSRVNTDQpNaWNoYWVsIE1pcm1hayByZXBvcnRlZCBv biB0aGUgSUVFRSBQMTA3Ni4xIHByZXNlbnRhdGlvbiBhdCBEQUMuICBUaGlzDQpwcmVzZW50YXRp b24gd2FzIGEgcmVzdWx0IG9mIEFycGFkIE11cmFueWkncyBwcmVzZW50YXRpb24gYXQgdGhlIERB VEUNCmNvbmZlcmVuY2UuICBUaGUgZ29hbCBvZiBNaWNoYWVsJ3MgcHJlc2VudGF0aW9uIHdhcyB0 byBhbGVydCB0aGUgQU1TDQp3b3JraW5nIGdyb3VwcyB0aGF0IElCSVMgaXMgdXNpbmcgdGhlaXIg bGFuZ3VhZ2VzIGluIHRoZSBuZXcgSUJJUw0Kc3BlY2lmaWNhdGlvbnMuICBUaGVzZSBwcmVzZW50 YXRpb25zIGhhdmUgZm9zdGVyZWQgZ29vZCBjb21tdW5pY2F0aW9ucw0KYmV0d2VlbiBJQklTIGFu ZCB0aGUgQU1TIHdvcmtpbmcgZ3JvdXBzLg0KDQpTZWUgdGhlICJNZWV0aW5ncyIgbGluazoNCg0K ICAgaHR0cDovL3d3dy5lZGEub3JnL3ZoZGwtYW1zLw0KDQpCb2IgUm9zcyBkaXNjdXNzZWQgc29t ZSBwZW5kaW5nIHN0YW5kYXJkcyB1bmRlciBjb25zaWRlcmF0aW9uIGJ5IHRoZQ0KSW50ZXJuYXRp b25hbCBFbGVjdHJvdGVjaG5pY2FsIENvbW1pc3Npb24gKElFQykgdW5kZXIgdGhlIHRlY2huaWNh bA0KY29tbWl0dGVlIFRDNDcuICBFYWNoIG9mIHRoZXNlIHN0YW5kYXJkcyBoYXZlIGxpbmtzIGJh Y2sgdG8gSUJJUy4gIE1vcmUNCmluZm9ybWF0aW9uIGNhbiBiZSBmb3VuZCBhdCB0aGUgZm9sbG93 aW5nIHVybDoNCg0KICAgICAgaHR0cDovL3d3dy5pZWMuY2gNCg0KVGhlIHR3byBzdGFuZGFyZHMg YXJlOg0KDQpJRUM2MjQwNCBJL08gSW50ZXJmYWNlIE1vZGVsIGZvciBJbnRlZ3JhdGVkIENpcmN1 aXRzIChJTUlDKSBhcyA0N0EvNzA0L0NEDQooY29tbWl0dGVlIGRyYWZ0KS4gIFRoaXMgaXMgYSBj b21wZXRpbmcgc3RhbmRhcmQgd2l0aCBJQklTIGFuZCBpcyBhbg0KZW5oYW5jZW1lbnQgdG8gc3Bp Y2UgbGFuZ3VhZ2VzLg0KDQpNb2RlbHMgb2YgSW50ZWdyYXRlZCBDaXJjdWl0cyBmb3IgRU1JIEJl aGF2aW9yYWwgU2ltdWxhdGlvbiA0N0EvNzE5L05QDQoobmV3IHdvcmsgcHJvcG9zYWwpLiBUaGlz IGlzIGEgZm9sbG93IG9uIHRvIElDRU0gKElDRU0gaXMgNjIwMTQtMykuDQoNClNvbWUgb2YgdGhp cyBhY3Rpdml0eSB3YXMgbW92ZWQgZnJvbSBUQzkzIHdoZXJlIElCSVMgdXNlZCB0byByZXNpZGUu ICBUaGUNCmRvY3VtZW50cyBhcmUgYXZhaWxhYmxlIGZvciB0ZWNobmljYWwgcmV2aWV3IGZyb20g Qm9iLiAgQm9iIG1lbnRpb25lZCB0aGF0DQpiZWNhdXNlIG9mIG91ciByZWxhdGVkIElCSVMgc3Rh bmRhcmQgYW5kIGFjdHVhbCBpbnZvbHZlbWVudCwgd2UgYXJlIHRoZQ0KYXBwcm9wcmlhdGUgY29t bWl0dGVlIHRvIHJldmlldyBhbmQgY29tbWVudCBvbiB0aGVzZSBkb2N1bWVudHMuDQoNCkJvYiBS b3NzIG1lbnRpb25lZCBhIFdvcmtzaG9wIG9uIEVsZWN0cm9tYWduZXRpYyBDb21wYXRpYmlsaXR5 IGFuZCBTaWduYWwNCkludGVncml0eSB0aGF0IGlzIGJlaW5nIGhlbGQgaW4gQmFuZ2tvaywgVGhh aWxhbmQgSnVseSAxOC0yMiwgMjAwNS4gIFRoZQ0Kd29ya3Nob3AgaXMgY29uZHVjdGVkIGJ5IHNv bWUgcGVvcGxlIGFjdGl2ZSBpbiB0aGUgU2lnbmFsIFByb3BhZ2F0aW9uIG9uDQpJbnRlcmNvbm5l Y3RzIChTUEkpIGFuZCBFUEVQIGNvbmZlcmVuY2VzIGFuZCBhcyBhIGpvaW50IEV1cm9wZWFuL0Fz aWFuDQphY3Rpdml0eSBvbiBFTUMvU0kgdG8gaGVscCBpbXByb3ZlIHVuaXZlcnNpdHkgY291cnNl cyBpbiBUaGFpbGFuZC4gIE1vcmUNCmluZm9ybWF0aW9uIGNhbiBiZSBmb3VuZCBhdCB0aGUgZm9s bG93aW5nIHVybDoNCg0KICAgaHR0cDovL3d3dy5hdW5wLWVtY3RyYWluaW5nLnBvbGl0by5pdC9l dmVudHMvc2VtaW5hci5hc3ANCg0KTHlubmUgR3JlZW4gbWVudGlvbmVkIHRoYXQgYSBzcGVha2Vy IGZyb20gdGhlIFNpbGljb24gSW50ZWdyYXRpb24NCkluaXRpYXRpdmUgKFNpMikgZ2F2ZSBhbiB1 cGRhdGUgYXQgdGhlIERBQyBJQklTIFN1bW1pdCBvbiBob3cgdGhlaXINCmluaXRpYXRpdmUgYWlt ZWQgYXQgaW1wcm92aW5nIHNpbGljb24gbW9kZWxpbmcgaXMgcmVsYXRlZCB0byBJQklTLg0KDQoN CkVJQS9BTlNJIEFQUFJPVkFMIEFDVElWSVRJRVMNClJhbmR5IFdvbGZmIHJlcG9ydGVkIHRoYXQg aGUgaGFzIGlucXVpcmVkIGZyb20gdGhlIEdFSUEgb24gdGhlIHN0YXR1cyBvZg0KSUJJUyAzLjIg cmViYWxsb3RpbmcgZm9yIEFOU0kgYXBwcm92YWwuICBUaGUgR0VJQSBoYXMgc28gZmFyIG5vdCBy ZXNwb25kZWQNCmFzIHRvIHdoZW4gdGhlIHB1YmxpYyByZXZpZXcgcGVyaW9kIGFzc29jaWF0ZWQg d2l0aCBBTlNJIGFwcHJvdmFsIHdpbGwgYmUNCmNvbXBsZXRlLg0KDQoNClMySUJJUzMgU1RBVFVT DQpObyBuZXcgdXBkYXRlLg0KDQpTMklCSVMzIFYxLjAgZXhlY3V0YWJsZXMgY2FuIGJlIGRvd25s b2FkZWQgZnJvbToNCg0KICBodHRwOi8vd3d3LmVjZS5uY3N1LmVkdS9lcmwvaWJpcy9zMmliaXMz L3MyaWJpczMuaHRtDQoNCg0KSUNNIFNQRUNJRklDQVRJT04gQU5EIFBBUlNFUiBTVEFUVVMNCk1p Y2hhZWwgTWlybWFrIG9wZW5lZCB1cCB0aGUgdGhpcmQgYW5kIGZpbmFsIG9mZmljaWFsIGZvcm1h bCByZWFkaW5nIGFuZA0KY29tbWVudCBwZXJpb2QuICBTb21lIG1pbm9yIGVkaXRvcmlhbCBjaGFu Z2VzIHN1Y2ggYXMgc3BlbGxpbmcgYW5kIGRhdGUNCmNoYW5nZXMgaGF2ZSBiZWVuIG1hZGUgdG8g dGhlIHNwZWNpZmljYXRpb24gc2luY2UgdGhlIGxhc3QgcmV2aWV3LiAgTm8gbmV3DQpjb21tZW50 cyB3ZXJlIG1hZGUuICBBIHZvdGUgd2lsbCBiZSBzY2hlZHVsZWQgZm9yIHRoZSBuZXh0IG1lZXRp bmcgZm9yDQpyZWxlYXNlIHRvIHRoZSBHRUlBIGFzIGFwcHJvdmVkIGFuZCBvcGVuIGZvciByZWxl YXNlIGZvciBjb21tZW50LiAgQm9iIFJvc3MNCmFza2VkIGFib3V0IGFkZGluZyBpbiB0aGUgdW5p dCBTaWVtZW5zIGFzIGEgYmFzZSB1bml0IGZvciBjb25kdWN0YW5jZSBpbiB0aGUNCnNwZWNpZmlj YXRpb24uICBUaGlzIHdhcyBkaXNjdXNzZWQgYW5kIGFwcHJvdmVkIGZvciBhZGRpdGlvbiB0byB0 aGUNCnNwZWNpZmljYXRpb24uDQoNCg0KU1VNTUlUUw0KDQotIERBQyBJQklTIFN1bW1pdCwgVHVl c2RheSwgSnVuZSAxNCwgMjAwNSwgQW5haGVpbSwgQ0ENCg0KICBNaWNoYWVsIE1pcm1hayBzdW1t YXJpemVkIHRoZSBTdW1taXQuICBUaGVyZSB3ZXJlIDMxIHBlb3BsZSByZXByZXNlbnRpbmcNCiAg MTcgb3JnYW5pemF0aW9ucyBpbiBhdHRlbmRhbmNlLiAgUHJlc2VudGF0aW9uIG1hdGVyaWFscyB3 aXRoIHRoZSBleGNlcHRpb24NCiAgb2YgdGhlIG1pbnV0ZXMgYXJlIG9ubGluZS4gIFRoZXJlIHdh cyBhIGhlYXZ5IGNvbmNlbnRyYXRpb24gb24gcG93ZXINCiAgZGVsaXZlcnkgaXNzdWVzLCBidXQg b3RoZXIgdG9waWNzIGluY2x1ZGVkIElDTSBhbmQgSUJJUyBsaW5raW5nLCBhIGxpYnJhcnkNCiAg cHJvcG9zYWwsIEktViBjdXJ2ZSB1c2FnZSwgYW5kIGEgY2FsbCBmb3IgYm9vayByZXZpZXdlcnMu ICBNaWNoYWVsDQogIGV4cHJlc3NlZCB0aGFua3MgdG8gY28tc3BvbnNvcnMgQ2FkZW5jZSBhbmQg TWVudG9yIGFuZCBldmVyeW9uZSBlbHNlIHRoYXQNCiAgaGVscGVkIG91dC4gIEJvYiBSb3NzIG1l bnRpb25lZCB0aGF0IGhlIHdvdWxkIGxpa2UgdG8gc2VlIGFkLWhvYw0KICBwcmVzZW50YXRpb25z IHRpdGxlZCB3aXRob3V0IHRoZSBhZC1ob2MgcmVmZXJlbmNlIHdoZW4gcG9zdGVkIG9ubGluZSBm b3INCiAgc2VhcmNoaW5nIHB1cnBvc2VzLiAgTHlubmUgR3JlZW4gbWVudGlvbmVkIHRoYXQgb25l IGJvb2sgcmV2aWV3ZXIgY2FtZQ0KICBmb3J3YXJkIGZvbGxvd2luZyBoZXIgcHJlc2VudGF0aW9u IGF0IHRoZSBzdW1taXQsIGFuZCBzaGUgZW5jb3VyYWdlZA0KICBvdGhlcnMgdG8gaGVscCBvdXQu DQoNCi0gRGVzaWduQ29uIEVhc3QgSUJJUyBTdW1taXQNCiAgRGVzaWduQ29uIEVhc3Qgd2lsbCBi ZSBoZWxkIGluIFdvcmNlc3RlciwgTWFzc2FjaHVzZXR0cyBmcm9tIFNlcHRlbWJlcg0KICAxOS0y MSwgMjAwNS4gIFNlcHRlbWJlciAxOSB3aWxsIGJlIHRoZSBJQklTIFN1bW1pdC4gIElCSVMgd2ls bCBiZSBhbg0KICBhc3NvY2lhdGUgc3BvbnNvci4gIEJvYiBSb3NzIHJlcG9ydGVkIHRoYXQgcGxh bnMgYXJlIHByb2NlZWRpbmcuICBNaWNoYWVsDQogIE1pcm1hayB3aWxsIHRha2UgY2FyZSBvZiB0 aGUgY29udHJhY3Qgc2lnbmluZyBzb29uLiAgVGhlIElFQyB3aWxsIHByb3ZpZGUNCiAgYSBtZWV0 aW5nIHJvb20gaW4gdGhlIERDVSBjb25mZXJlbmNlIGNlbnRlci4gIFRoZXJlIGlzIGEgdGVsZWNv bmZlcmVuY2UNCiAgYnJpZGdlIHBsYW5uZWQgZm9yIHRoZSBzdW1taXQuICBUaGlzIHdpbGwgYmUg cGFpZCBmb3IgYnkgdGhlIElCSVMNCiAgY29tbWl0dGVlIGFuZCBjb3N0cyBhYm91dCAkMTQwLiAg THVuY2ggaXMgcHJvdmlkZWQgYXMgcGFydCBvZiB0aGUgTW9uZGF5DQogIGtleW5vdGUgc3BlYWtl ciBsdW5jaCBzcGVlY2guICBDYWRlbmNlL1Npc29mdCBhcmUgY28tc3BvbnNvcmluZyB0aGUgZXZl bnQuDQogIElhbiBEb2RkIGlzIGNvb3JkaW5hdGluZyB0aGUgYm9vdGggYW5kIHdpbGwgYXJyYW5n ZSBmb3IgaXRzIHRyYW5zZmVyIHRvDQogIE1hc3NhY2h1c2V0dHMuICBMb2NhbCBzZXR1cCBvZiB0 aGUgYm9vdGggbmVlZHMgdG8gYmUgY29vcmRpbmF0ZWQuDQoNCi0gQXNpYW4gSUJJUyBTdW1taXQN CiAgQm9iIFJvc3MgbWVudGlvbmVkIHRoYXQgdmVyeSBwcmVsaW1pbmFyeSBwbGFubmluZyBoYXMg YmVndW4uICBQbGFucyBhcmUNCiAgZm9jdXNpbmcgb24gU2hlbnpoZW4sIENoaW5hIG5lYXIgSG9u ZyBLb25nLCB0ZW50YXRpdmVseSBpbiBlYXJseSBEZWNlbWJlci4NCiAgTWFueSBhY3RpdmUgQ2hp bmVzZSBhbmQgVVMgYmFzZWQgY29tcGFuaWVzIGFyZSB0aGVyZS4gIEl0IGxvb2tzIHRvIGJlIGEN CiAgbGFyZ2UgbWVldGluZywgbWF5YmUgdXAgdG8gMjAwIHBlb3BsZS4gU3BvbnNvcnNoaXAgaXMg cGxhbm5lZCBmcm9tIEh1YXdlaQ0KICBhbmQgQ2FkZW5jZSBhcyB3ZWxsIGFzIG90aGVycy4gVGhl cmUgYXJlIG1hbnkgZmluYW5jaWFsIGxvZ2lzdGljcw0KICBpc3N1ZXMgdG8gd29yayBvdXQuDQoN ClNwb25zb3JzaGlwIG9wcG9ydHVuaXRpZXMgZm9yIERlc2lnbkNvbiBFYXN0IGFyZSBzdGlsbCBh dmFpbGFibGUsIHdpdGgNCnNwb25zb3JzIHJlY2VpdmluZyBmcmVlIG1lbnRpb25zIGluIHRoZSBt aW51dGVzLCBhZ2VuZGEsIGFuZCBvdGhlcg0KYW5ub3VuY2VtZW50cy4NCg0KDQpJQklTIFFVQUxJ VFkgQ09NTUlUVEVFDQpCb2IgUm9zcyBjb25maXJtZWQgdGhhdCBKdWx5IDEyIGlzIHRoZSBuZXh0 IG1lZXRpbmcuICBUaGUgbGFzdCBtZWV0aW5nIHdhcw0KSnVuZSA3LiAgRWNraGFyZCBMZW5za2kg bWVudGlvbmVkIHRoYXQgW1BpbiBNYXBwaW5nXSB3YXMgYmVpbmcgdGFsa2VkIGFib3V0Lg0KDQpU aGUgbGluayB0byB0aGUgcXVhbGl0eSBjb21taXR0ZWUgY2hlY2tsaXN0IGlzIGF0Og0KDQogICBo dHRwOi8vd3d3LmVkYS5vcmcvcHViL2liaXMvcXVhbGl0eV93aXAvDQoNCg0KSUJJUyBNT0RFTCBS RVZJRVcgQ09NTUlUVEVFDQpMeW5uZSBHcmVlbiByZXBvcnRlZCB0aGF0IG9uZSBtb2RlbCBjYW1l IGluLiAgU2hlIHJlY29tbWVuZGVkIHNldmVyYWwNCmNoYW5nZXMgdG8gZml4IHByb2JsZW1zLg0K DQoNCkZVVFVSRVMgQU5EIENPT0tCT09LIENPTU1JVFRFRVMNCk1pY2hhZWwgTWlybWFrIHJlcG9y dGVkIHRoYXQgdGhlcmUgd2VyZSBtZWV0aW5ncyBvZiBib3RoIGNvbW1pdHRlZXMNCnllc3RlcmRh eS4gIFRoZSB0aW1lIG9mIHRoZSBtZWV0aW5nIHdhcyBjaGFuZ2VkIHRvIFRodXJzZGF5IG1vcm5p bmdzLg0KVGhlcmUgd2VyZSBkaXNjdXNzaW9ucyBvZiBCSVJEOTksIEJJUkQ5NCwgYW5kIGEgdmVy eSBicmllZiBkaXNjdXNzaW9uIG9mDQpCSVJEOTUuICBNZW1iZXJzIGFsc28gZGlzY3Vzc2VkIGEg cHJvcG9zYWwgZm9yIGxpbmtpbmcgb2YgSUJJUyBhbmQgSUNNDQpzcGVjaWZpY2F0aW9ucy4gIFRo ZSBDb29rYm9vayB3YXMgYnJpZWZseSBkaXNjdXNzZWQuICBUaGUgbGFzdCBzZWN0aW9uIG9uDQpz cGxpdHRpbmcgQ19jb21wIHdhcyBhZGRlZCBieSBBcnBhZC4gIEl0IGlzIHZlcnkgY2xvc2UgdG8g YmVpbmcgcG9zdGVkIGZvcg0KcmV2aWV3LiAgTWljaGFlbCB3b3VsZCBsaWtlIHRvIHNlZSBpdCBy ZXZpZXdlZCBhbmQgYXBwcm92ZWQgc2hvcnRseSBmb3INCnJlbGVhc2UuDQoNClJlY2VudCBjb21t aXR0ZWUgbWF0ZXJpYWwgaXMgc3RvcmVkIGF0Og0KDQogICBodHRwOi8vd3d3LmliaXMtaW5mb3Jt YXRpb24ub3JnL2Z1dHVyZXMvDQoNCg0KTkVXIEFETUlOSVNUUkFUSVZFIElTU1VFUw0KQSBkaXNj dXNzaW9uIGVuc3VlZCBvbiBsaWNlbnNpbmcgYWN0aXZpdHkuICBNaWNoYWVsIE1pcm1hayByZXBv cnRlZCB0aGF0DQpvZmZpY2lhbCBkb2N1bWVudHMgcGFydGljdWxhcmx5IGZvciBJQ00gY2hlY2sg YXJlIGJlaW5nIGRyYXduIHVwLiAgVGhlDQpsaWNlbnNlIG9mIHRoZSBwcml2YXRlIHZlcnNpb24g b2YgdGhlIElDTUNISyBzb2Z0d2FyZSB3YXMgcmVsZWFzZWQgdG8gdGhlDQpJQklTIENvbW1pdHRl ZSBmcm9tIEtlbGx5IEdyZWVuLiAgQm9iIFJvc3MgZmVsdCB0aGF0IHRoZSBkb2N1bWVudHMgaGFk IHRvbw0KbWFueSBzaWduYXR1cmUgcmVxdWlyZW1lbnRzIGZvciB0aGUgR0VJQS4NCg0KDQpCSVJE OTk6IEFNUyBMQU5HVUFHRSBWRVJTSU9OUw0KQXJwYWQgTXVyYW55aSBpbnRyb2R1Y2VkIEJJUkQ5 OS4gIFRoZSBCSVJEIGF0dGVtcHRzIHRvIGxpZnQgYW4gZXhhY3QNCnZlcnNpb24gbnVtYmVyIGZy b20gYmVpbmcgbWVudGlvbmVkIGluIHRoZSBJQklTIHNwZWNpZmljYXRpb24gcmVnYXJkaW5nDQpB TVMgbGFuZ3VhZ2VzLiAgVGhlIHZlcnNpb24gbnVtYmVyIGlzIHJlbW92ZWQgYW5kIHJlcGxhY2Vk IHdpdGggYSBzdGF0ZW1lbnQNCnRoYXQgdGhlIGxhdGVzdCB2ZXJzaW9uIHNob3VsZCBiZSBzdXBw b3J0ZWQuICBUaGlzIGlzIHNvIHRoYXQgdGhlIGxhdGVzdA0KZmVhdHVyZXMgb2YgdGhlIEFNUyBs YW5ndWFnZXMgd2lsbCBhdXRvbWF0aWNhbGx5IGJlIGF2YWlsYWJsZSBmb3IgdXNlIGJ5DQpJQklT IG1vZGVsIHdyaXRlcnMuICBBcnBhZCBtZW50aW9uZWQgdGhhdCBNZW50b3IgaGFkIGV4cHJlc3Nl ZCBjb25jZXJuIHdpdGgNCnRoZSBCSVJELCBzbyBoZSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGEgZGlz Y3Vzc2lvbiBvbiB0aGUgSUJJUyByZWZsZWN0b3IuICBJYW4NCkRvZGQgc2FpZCB0aGF0IGhlIHN1 cHBvcnRlZCBoYXZpbmcgYSBzcGVjaWZpYyB2ZXJzaW9uIGluIHRoZSBzcGVjaWZpY2F0aW9uLA0K b3RoZXJ3aXNlIHRoZSBtb2RlbCB1c2VyIHdvdWxkIGhhdmUgdG8gY2hlY2sgd2l0aCB0aGUgc29m dHdhcmUgdmVuZG9ycyB0bw0Kc2VlIHdoYXQgQU1TIHZlcnNpb24gaXMgc3VwcG9ydGVkLiAgSGUg ZmVsdCB0aGlzIHdvdWxkIG1ha2UgdGhlDQpzcGVjaWZpY2F0aW9uIG1vcmUgY29uc2lzdGVudC4g IEJvYiBSb3NzIG1lbnRpb25lZCB0aGF0IHRoZXJlIHdhcyBuZXZlciBhbnkNCmludGVudCB0byBz dXBwb3J0ICJsYXRlciIgdmVyc2lvbnMgb2YgU1BJQ0UuICBUaGUgZml4ZWQgYmFzZWxpbmUgaW4g dGhlDQpzcGVjaWZpY2F0aW9uIHdhcyBjaG9zZW4gYXMgYSBjb21tb24gcHVibGljIGJhc2UtbGlu ZSBzaW5jZSBtb3N0IHZlbmRvcnMNCmhhdmUgYWRvcHRlZCB1bmlxdWUgc3ludGF4ZXMgYmV5b25k IHRoYXQgYmFzZWxpbmUuIFRoZSBkaXNjdXNzaW9uIGlzIHBsYW5uZWQNCnRvIGNvbnRpbnVlIG9u IHRoZSByZWZsZWN0b3IgYW5kIHdpbGwgYmUgY3Jvc3MtcG9zdGVkIHRvIG90aGVyIHJlZmxlY3Rv cnMuDQoNCkJJUkQ5NC4xOiBDTEFSSUZJQ0FUSU9OUyBPTiBbRElGRiBQSU5dIFBBUkFNRVRFUlMN CkFycGFkIE11cmFueWkgcmVwb3J0ZWQgdGhhdCBCb2IgUm9zcyBzZW50IEFycGFkIHNvbWUgY29t bWVudHMuICBCb2INCm1lbnRpb25lZCB0aGF0IGRpZmZlcmVudCBkaWZmZXJlbnRpYWwgc3dpdGNo aW5nIHZhbHVlcyB3ZXJlIG9yaWdpbmFsbHkgaW4NCnRoZSBzcGVjaWZpY2F0aW9uIHRvIGluZGlj YXRlIGRpZmZlcmVuY2VzIGJldHdlZW4gZHJpdmUgYW5kIHJlY2VpdmUgbW9kZXMuDQpBcnBhZCBp cyBwbGFubmluZyB0byBtYWtlIHNvbWUgY2hhbmdlcyB0byB0aGUgQklSRCBub3cuICBBcnBhZCB1 bmRlcnN0b29kDQp0aGF0IFZkaWZmIGlzIGZvciB0aGUgcmVjZWl2ZXIgaW5wdXQgdGhyZXNob2xk IHBhcmFtZXRlciBvbmx5LCBob3dldmVyIGl0DQphcHBlYXJzIHRoYXQgaXQgY291bGQgYmUgdXNl ZCB0byBpbmRpY2F0ZSBhIGRpZmZlcmVudGlhbCBWbWVhcyB2YWx1ZSBmb3INCmZsaWdodCB0aW1l IG1lYXN1cmVtZW50cyBvZiBhbiBvdXRwdXQuICBUaGUgbGFuZ3VhZ2Ugd2lsbCBuZWVkIHRvIGJl IGNsZWFuZWQNCnVwLCBhbmQgdGhpcyB3aWxsIGJlIGRpc2N1c3NlZCBvZmZsaW5lLiAgVGhlIHZv dGUgd2lsbCBiZSBwb3N0cG9uZWQuDQoNCg0KQklSRDk1LjU6IFBPV0VSIElOVEVHUklUWSBBTkFM WVNJUyBVU0lORyBJQklTDQpTeWVkIEh1cSByZXBvcnRlZCBvbiBldmVudHMgYXQgdGhlIElCSVMg c3VtbWl0IGF0IERBQy4gIENhZGVuY2UgZXhwcmVzc2VkDQpjb25jZXJuIG92ZXIgbW9kZWxpbmcg U1NPIHNpbXVsYXRpb25zIHdpdGggQklSRDk1LjUuICBaaGlwaW5nIFlhbmcgcHJlc2VudGVkDQpp bmZvcm1hdGlvbiBvbiB0aGlzIHR5cGUgb2Ygc2ltdWxhdGlvbiBhdCB0aGUgc3VtbWl0LiAgU3ll ZCBoYXMgbm90IHNlZW4gYW55DQpyZXF1ZXN0cyBmb3IgY2hhbmdlcyB0byB0aGUgQklSRCByZWNl bnRseS4gIEJvYiBSb3NzIGV4cHJlc3NlZCB0aGF0IHRoZQ0KZm9jdXMgb2YgQklSRDk1LjUgc2Vl bXMgdG8gYmUgb24gU1NOIHNpbXVsYXRpb25zLiAgSGUgYWxzbyBzdW1tYXJpemVkIG90aGVyDQpj b25jZXJucyB0aGF0IGNhbWUgdXAgd2l0aCByZWxhdGlvbiB0byB0aGUgZ3JvdW5kIGJvdW5jZSBz aW11bGF0aW9uDQpwcmVzZW50YXRpb24gZ2l2ZW4gYnkgU2lncml0eS4gIFN5ZWQgYXNrZWQgaG93 IHRvIHByb2NlZWQgZnJvbSB0aGlzIHBvaW50Lg0KSWFuIERvZGQgc3VnZ2VzdGVkIGNvbnRhY3Rp bmcgQ2FkZW5jZSBhbmQgYXNraW5nIHRoZW0gdG8gcHJlc2VudCBhIHNjaGVkdWxlDQpmb3IgYWRk cmVzc2luZyB0aGVpciBjb25jZXJucy4gIE1pY2hhZWwgTWlybWFrIHRvb2sgdGhlIEFSIHRvIGNv bnRhY3QgS2VuDQpXaWxsaXMgYXQgQ2FkZW5jZS4NCg0KQklSRDk3LjI6IEdBVEUgTU9EVUxBVElP TiBFRkZFQ1QNCkRpc2N1c3Npb24gZGVmZXJyZWQuDQoNCg0KQklSRDk4OiBHQVRFIE1PRFVMQVRJ T04gRUZGRUNUIChUQUJMRSBGT1JNQVQpDQpObyBkaXNjdXNzaW9uIGR1ZSB0byB0aW1lIGNvbnN0 cmFpbnRzLg0KDQoNCklCSVNDSEs0IEJVRyBTVEFUVVMNCk5vIHVwZGF0ZS4NCg0KSUNNQ0hLMSBC VUcgU1RBVFVTDQpObyB1cGRhdGUuDQoNCk5FVyBURUNITklDQUwgSVNTVUVTDQpOb25lLg0KDQoN Ck5FWFQgTUVFVElORw0KVGhlIG5leHQgSUJJUyBPcGVuIEZvcnVtIHRlbGVjb25mZXJlbmNlIHdp bGwgYmUgaGVsZCBKdWx5IDE1LCAyMDA1IGZyb20NCjg6MDAgQU0gdG8gMTA6MDAgQU0gVVMgUGFj aWZpYyBUaW1lLg0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBOT1RFUw0KDQpJQklTIENIQUlSOiBNaWNoYWVsIE1pcm1hayAoOTE2KSAzNTYt NDI2MSwgRmF4OiAoOTE2KSAzNzctMTA0Ng0KICAgICAgICAgICAgbWljaGFlbC5taXJtYWtAaW50 ZWwuY29tDQogICAgICAgICAgICBTZW5pb3IgQW5hbG9nIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3Jh dGlvbg0KICAgICAgICAgICAgRk02LTQ1DQogICAgICAgICAgICAxOTAwIFByYWlyaWUgQ2l0eSBS ZC4NCiAgICAgICAgICAgIEZvbHNvbSwgQ0EgIDk1NjMwDQoNClZJQ0UgQ0hBSVI6IFN5ZWQgSHVx ICg0MDgpIDUyNS0zMzk5LCBGYXg6ICg0MDgpIDUyNi01NTA0DQogICAgICAgICAgICBzaHVxQGNp c2NvLmNvbQ0KICAgICAgICAgICAgTWFuYWdlciwgSGFyZHdhcmUgRW5naW5lZXJpbmcsIENpc2Nv IFN5c3RlbXMNCiAgICAgICAgICAgIDE3MCBXZXN0IFRhc21hbiBEcml2ZQ0KICAgICAgICAgICAg U2FuIEpvc2UsIENBIDk1MTM0LTE3MDYNCg0KU0VDUkVUQVJZOiAgUmFuZHkgV29sZmYgKDIwOCkg MzYzLTE3NjQsIEZheDogKDIwOCkgMzY4LTM0NzUNCiAgICAgICAgICAgIHJyd29sZmZAbWljcm9u LmNvbQ0KICAgICAgICAgICAgU2ltdWxhdGlvbiBFbmdpbmVlciwgTWljcm9uIFRlY2hub2xvZ3ks IEluYy4NCiAgICAgICAgICAgIDgwMDAgUy4gRmVkZXJhbCBXYXkNCiAgICAgICAgICAgIE1haWwg U3RvcDogMS03MTENCiAgICAgICAgICAgIEJvaXNlLCBJRCA4MzcwNy0wMDA2DQoNCkxJQlJBUklB TjogIExhbmNlIFdhbmcgKDk3OCkgMjYyLTY2ODUsIEZheDogKDk3OCkgMjYyLTYzNjMNCiAgICAg ICAgICAgIGx3YW5nQGNhZGVuY2UuY29tDQogICAgICAgICAgICBTZW5pb3IgTWVtYmVyLCBUZWNo bmljYWwgU3RhZmYsIENhZGVuY2UgRGVzaWduIFN5c3RlbXMsIEluYy4NCiAgICAgICAgICAgIDI3 MCBCaWxsZXJpY2EgUm9hZA0KICAgICAgICAgICAgQ2hlbG1zZm9yZCwgTUEgMDE4MjQNCg0KV0VC TUFTVEVSOiAgU3llZCBIdXEgKDQwOCkgNTI1LTMzOTksIEZheDogKDQwOCkgNTI2LTU1MDQNCiAg ICAgICAgICAgIHNodXFAY2lzY28uY29tDQogICAgICAgICAgICBNYW5hZ2VyLCBIYXJkd2FyZSBF bmdpbmVlcmluZywgQ2lzY28gU3lzdGVtcw0KICAgICAgICAgICAgMTcwIFdlc3QgVGFzbWFuIERy aXZlDQogICAgICAgICAgICBTYW4gSm9zZSwgQ0EgOTUxMzQtMTcwNg0KDQpQT1NUTUFTVEVSOiBC b2IgUm9zcyAoNTAzKSAyNDYtODA0OCwgRmF4IDogKDUwMykgMjM5LTQ0MDANCiAgICAgICAgICAg IGJvYkB0ZXJhc3BlZWQuY29tDQogICAgICAgICAgICBTdGFmZiBTY2llbnRpc3QsIFRlcmFzcGVl ZCBDb25zdWx0aW5nIEdyb3VwDQogICAgICAgICAgICAxMDIzOCBTVyBMYW5jYXN0ZXIgUm9hZA0K ICAgICAgICAgICAgUG9ydGxhbmQsIE9SIDk3MjE5DQoNCg0KVGhpcyBtZWV0aW5nIHdhcyBjb25k dWN0ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBHRUlBIExlZ2FsIEd1aWRlcyBhbmQNCkdFSUEg TWFudWFsIG9mIE9yZ2FuaXphdGlvbiBhbmQgUHJvY2VkdXJlLg0KDQpUaGUgZm9sbG93aW5nIGUt bWFpbCBhZGRyZXNzZXMgYXJlIHVzZWQ6DQoNCiAgbWFqb3Jkb21vQGVkYS5vcmcNCiAgICAgIElu IHRoZSBib2R5LCBmb3IgdGhlIElCSVMgT3BlbiBGb3J1bSBSZWZsZWN0b3I6DQogICAgICBzdWJz Y3JpYmUgaWJpcyA8eW91ciBlLW1haWwgYWRkcmVzcz4NCg0KICAgICAgSW4gdGhlIGJvZHksIGZv ciB0aGUgSUJJUyBVc2VycycgR3JvdXAgUmVmbGVjdG9yOg0KICAgICAgc3Vic2NyaWJlIGliaXMt dXNlcnMgPHlvdXIgZS1tYWlsIGFkZHJlc3M+DQoNCiAgICAgIEhlbHAgYW5kIG90aGVyIGNvbW1h bmRzOg0KICAgICAgaGVscA0KDQogIGliaXMtcmVxdWVzdEBlZGEub3JnDQogICAgICBUbyBqb2lu LCBjaGFuZ2UsIG9yIGRyb3AgZnJvbSBlaXRoZXIgdGhlIElCSVMgT3BlbiBGb3J1bSBSZWZsZWN0 b3INCiAgICAgIChpYmlzQGVkYS5vcmcpLCB0aGUgSUJJUyBVc2VycycgR3JvdXAgUmVmbGVjdG9y DQogICAgICAoaWJpcy11c2Vyc0BlZGEub3JnKSBvciBib3RoLiAgU3RhdGUgeW91ciByZXF1ZXN0 Lg0KDQogIGliaXMtaW5mb0BlZGEub3JnDQogICAgICBUbyBvYnRhaW4gZ2VuZXJhbCBpbmZvcm1h dGlvbiBhYm91dCBJQklTLCB0byBhc2sgc3BlY2lmaWMNCiAgICAgIHF1ZXN0aW9ucyBmb3IgaW5k aXZpZHVhbCByZXNwb25zZSwgYW5kIHRvIGlucXVpcmUgYWJvdXQgam9pbmluZw0KICAgICAgdGhl IEVJQS1JQklTIE9wZW4gRm9ydW0gYXMgYSBmdWxsIE1lbWJlci4NCg0KICBpYmlzQGVkYS5vcmcN CiAgICAgIFRvIHNlbmQgYSBtZXNzYWdlIHRvIHRoZSBnZW5lcmFsIElCSVMgT3BlbiBGb3J1bSBS ZWZsZWN0b3IuICBUaGlzDQogICAgICBpcyB1c2VkIG1vc3RseSBmb3IgSUJJUyBTdGFuZGFyZGl6 YXRpb24gYnVzaW5lc3MgYW5kIGZ1dHVyZSBJQklTDQogICAgICB0ZWNobmljYWwgZW5oYW5jZW1l bnRzLiAgSm9iIHBvc3RpbmcgaW5mb3JtYXRpb24gaXMgbm90IHBlcm1pdHRlZC4NCg0KICBpYmlz LXVzZXJzQGVkYS5vcmcNCiAgICAgIFRvIHNlbmQgYSBtZXNzYWdlIHRvIHRoZSBJQklTIFVzZXJz JyBHcm91cCBSZWZsZWN0b3IuICBUaGlzIGlzDQogICAgICB1c2VkIG1vc3RseSBmb3IgSUJJUyBj bGFyaWZpY2F0aW9uLCBjdXJyZW50IG1vZGVsaW5nIGlzc3VlcywgYW5kDQogICAgICBnZW5lcmFs IHVzZXIgY29uY2VybnMuICBKb2IgcG9zdGluZyBpbmZvcm1hdGlvbiBpcyBub3QgcGVybWl0dGVk Lg0KDQogIGliaXMtYnVnQGVkYS5vcmcNCiAgICAgIFRvIHJlcG9ydCBpYmlzY2hrIHBhcnNlciBi dWdzLiAgVGhlIEJ1ZyBSZXBvcnQgRm9ybSBSZXNpZGVzIG9uDQogICAgICBlZGEub3JnIGluIC9w dWIvaWJpcy9idWdzL2liaXNfYnVncy9idWdmb3JtLnR4dCBhbG9uZyB3aXRoDQogICAgICByZXBv cnRlZCBidWdzLg0KDQogIGljbS1idWdAZWRhLm9yZw0KICAgICAgVG8gcmVwb3J0IGljbWNoazEg cGFyc2VyIGJ1Z3MuICBUaGUgQnVnIFJlcG9ydCBGb3JtIFJlc2lkZXMgb24NCiAgICAgIGVkYS5v cmcgaW4gL3B1Yi9pYmlzL2J1Z3MvaWNtX2J1Z3MvaWNtX2J1Z2Zvcm0udHh0IGFsb25nIHdpdGgN CiAgICAgIHJlcG9ydGVkIGJ1Z3MuDQoNCiAgICAgIFRvIHJlcG9ydCBzMmliaXMsIHMyaWJpczIg YW5kIHMyaXBsdCBidWdzLCB1c2UgdGhlIEJ1ZyBSZXBvcnQNCiAgICAgIEZvcm1zIHdoaWNoIHJl c2lkZSB1bmRlciBlZGEub3JnIGluDQogICAgICAvcHViL2liaXMvYnVncy9zMmliaXMvYnVnczJp LnR4dCwNCiAgICAgIC9wdWIvaWJpcy9idWdzL3MyaWJpczIvYnVnczJpMi50eHQgYW5kDQogICAg ICAvcHViL2liaXMvYnVncy9zMmlwbHQvYnVnc3BsdC50eHQgcmVzcGVjdGl2ZWx5Lg0KDQpJbmZv cm1hdGlvbiBvbiBJQklTIHRlY2huaWNhbCBjb250ZW50cywgSUJJUyBwYXJ0aWNpcGFudHMgYW5k IGFjdHVhbA0KSUJJUyBtb2RlbHMgYXJlIGF2YWlsYWJsZSBvbiB0aGUgSUJJUyBIb21lIHBhZ2U6 DQoNCiAgaHR0cDovL3d3dy5laWdyb3VwLm9yZy9pYmlzL2liaXMuaHRtDQoNCkNoZWNrIHRoZSBJ QklTIGZpbGUgZGlyZWN0b3J5IG9uIGVkYS5vcmcgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24NCnBy ZXZpb3VzIGRpc2N1c3Npb25zIGFuZCByZXN1bHRzOg0KDQogIGh0dHA6Ly93d3cuZWRhLm9yZy9w dWIvaWJpcy9kaXJlY3RvcnkuaHRtbA0KDQpBbGwgZWRhLm9yZyBkb2N1bWVudHMgY2FuIGJlIGFj Y2Vzc2VkIHVzaW5nIGEgbWlycm9yOg0KDQogIGh0dHA6Ly93d3cuaWJpcy1pbmZvcm1hdGlvbi5v cmcNCg0KTm90ZSB0aGF0IHRoZSAicHViL2liaXMiIHRleHQgc2hvdWxkIGJlIHJlbW92ZWQgZnJv bSBkaXJlY3RvcnkgbmFtZXMNCndoZW4gdGhpcyBVUkwgbWlycm9yIGlzIHVzZWQuDQoNCiogT3Ro ZXIgdHJhZGVtYXJrcywgYnJhbmRzIGFuZCBuYW1lcyBhcmUgdGhlIHByb3BlcnR5IG9mDQogIHRo ZWlyIHJlc3BlY3RpdmUgb3duZXJzLg0K - ------_=_NextPart_001_01C5817D.3B4D33C5-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 6 Jul 2005 09:04:00 -0700 From: "Muranyi, Arpad" Subject: [IBIS-Users] RE: [IBIS] DC sweep This is a multi-part message in MIME format. - ------_=_NextPart_001_01C58244.52F5D4C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are times when obtaining and IV curve with .DC sweeps is impossible. If the buffer has flip/flops, SPICE is not going to know how to find the operating points in the circuit. You will have to run a few clock cycles worth of simulations before the output will be in the correct state. =20 The good news is that IV curves do not have to be measured in the .DC mode. You can do just as well in .TRAN mode. Just connect an ideal source to the node you are trying to get the IV curve from. Define a ramping voltage for this ideal source (either PWL, or PULSE, or whatever), and measure its current. =20 Make sure that the polarity of the current measurement is correct when you use it for IBIS models, and make sure that the ramp is slow, in the ms range, not ns or ps. If you sweep too fast, your error in the current reading will increase doe to the parasitic capacitance in the circuit (I=3DC*dV/dt). =20 I hope this will help... =20 Arpad =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 ________________________________ From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Andrew = Ingraham Sent: Tuesday, July 05, 2005 6:26 AM To: ibis-users@eda.org; ibis@eda.org Subject: Re: [IBIS] DC sweep Sivaram, =20 It sounds like you are confusing the purpose of sweeping the V-I curves. = It has nothing to do with edge-triggered or level-sensitive. =20 The only thing you apply the swept voltage to, is the IC pin (actually, = the bonding pad). If your IC has an output buffer connected to that = pin, the swept voltage goes to the output of that buffer, but NOT to its = input. Its input should be connected to the normal things you would = normally connect to the input of that buffer; not the swept DC source. =20 The purpose of the DC sweep is to measure the current vs. voltage = relationship at the pin. If the pin has an output or I/O buffer = connected to the pin, then that I-V relationship depends very strongly = on the state of the output buffer, which might be inactive (hi-Z), = driving low, or driving high; and you need to extract the I-V = relationships separately in each of those states. You need to place the = output buffer into each of those states (through whatever internal = controls the buffer has), one at a time, and then sweep the voltage at = the pin and measure the current, each time with the buffer held in one = state (i.e., constant voltages applied to its edge-triggered or = level-sensitive internal nodes). Then change those internal nodes to = put the buffer into its next state, and sweep the external voltage = again. =20 If the pin is just an input buffer, then (unless the buffer has = feedback, like a "bus-hold" device, which makes it problematic for IBIS) = it doesn't make much difference what the input buffer is doing, whether = it is toggling, etc. Just sweep the input pin's voltage and measure the = input current. =20 Hope this helps. =20 Regards, Andy =20 =20 How can I extract V-I curves when the O/P of my buffer is = edge-triggered=20 and not level-sensitive?=20 Basically, I have to do DC sweep to extract these curves.But I cannot=20 connect my inputs to steady voltage values as the O/P is = edge-triggered, which=20 needs transient analysis.=20 Would anyone of you please let me know how to go about these buffers to = extract=20 VI curves?=20 Thanks in advance,=20 Sivaram - ------_=_NextPart_001_01C58244.52F5D4C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DC sweep
There are times when obtaining and IV curve = with=20 .DC
sweeps is impossible.  If the buffer has = flip/flops,
SPICE is not going to know how to find=20 the=20 operating
points in the circuit.  You will have=20 to=20 run a few
clock cycles worth of simulations before=20 the=20 output
will be in the correct = state.
 
The good news is that IV curves do not have = to=20 be
measured in the .DC mode.  You can do = just as=20 well
in .TRAN mode.  Just connect an ideal = source to=20 the
node you are trying to get the IV curve = from. =20 Define
a ramping voltage for this ideal source = (either=20 PWL,
or PULSE, or whatever), and measure its=20 current.
 
Make sure that the polarity of the current=20 measurement
is correct when you use it for IBIS models, = and=20 make
sure that the ramp is slow, in the ms range, = not=20 ns
or ps.  If you sweep too fast, your = error in=20 the
current reading will increase doe to the=20 parasitic
capacitance in the circuit=20 (I=3DC*dV/dt).
 
I hope this will help...
 
Arpad
=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

From: owner-ibis@eda.org=20 [mailto:owner-ibis@eda.org] On Behalf Of Andrew = Ingraham
Sent:=20 Tuesday, July 05, 2005 6:26 AM
To: ibis-users@eda.org;=20 ibis@eda.org
Subject: Re: [IBIS] DC sweep

Sivaram,
 
It sounds like you are confusing the = purpose of=20 sweeping the V-I curves.  It has nothing to do with edge-triggered = or=20 level-sensitive.
 
The only thing you apply the swept = voltage to, is=20 the IC pin (actually, the bonding pad).  If your IC has an = output=20 buffer connected to that pin, the swept voltage goes to the = output of=20 that buffer, but NOT to its input.  Its input should be connected=20 to the normal things you would normally connect to the input of = that=20 buffer; not the swept DC source.
 
The purpose of the DC sweep is to = measure the=20 current vs. voltage relationship at the pin.  If the pin has an = output or=20 I/O buffer connected to the pin, then that I-V relationship depends very = strongly on the state of the output buffer, which might be inactive = (hi-Z),=20 driving low, or driving high; and you need to extract the I-V = relationships=20 separately in each of those states.  You=20 need to place the output buffer into each of those states (through = whatever=20 internal controls the buffer has), one at a time, and then sweep the = voltage at=20 the pin and measure the current, each time with the buffer held in one = state=20 (i.e., constant voltages applied to its edge-triggered or = level-sensitive=20 internal nodes).  Then change = those internal=20 nodes to put the buffer into its next state, and sweep the external = voltage=20 again.
 
If the pin is just an input = buffer, then=20 (unless the buffer has feedback, like a "bus-hold" device, which makes = it=20 problematic for IBIS) it doesn't make much difference what the input = buffer is=20 doing, whether it is toggling, etc.  Just sweep the input pin's = voltage and=20 measure the input current.
 
Hope this helps.
 
Regards,
Andy
 
 

How can I extract V-I curves when the = O/P of my=20 buffer is edge-triggered
and = not=20 level-sensitive?

Basically, I have to do DC sweep to = extract these=20 curves.But I cannot
connect my = inputs to=20 steady voltage values as the O/P is edge-triggered, which =
needs transient analysis.

Would anyone of you please let me know = how to go=20 about these buffers to extract
VI=20 curves?

Thanks in advance,
Sivaram

- ------_=_NextPart_001_01C58244.52F5D4C2-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 6 Jul 2005 16:26:11 -0700 From: "Muranyi, Arpad" Subject: [IBIS-Users] FW: *-AMS language versions in IBIS Hello everyone, I would like to generate discussion on VHDL-AMS and Verilog-AMS version numbers in the IBIS specification. The IBIS 4.1 spec says, in part, the following: | "VHDL-AMS" refers to "IEEE Standard VHDL Analog and Mixed-Signal | Extensions", approved March 18, 1999 by the IEEE-SA Standards Board and | designated IEEE Std. 1076.1-1999. | | "Verilog-AMS" refers to the Analog and Mixed-Signal Extensions to | Verilog-HDL as documented in the Verilog-AMS Language Reference, Version | 2.0. Please note that the *-AMS version numbers mentioned in the IBIS spec are fixed values. Verilog-AMS is already past Version 2.2 of its LRM, and VHDL-AMS is due for a five-year renewal soon. As written, every time new version of these languages comes out, the IBIS specification will have to be updated to change the *-AMS version numbers. With IBIS updates occurring very infrequently, new and useful features in the *-AMS specifications may not be available to the IBIS community for over a year (or more) after the new LRMs are approved. In attempt to remedy this problem, I authored BIRD99 which can be found at: http://www.vhdl.org/pub/ibis/birds/bird99.txt. The BIRD makes the *-AMS language versions listed in the IBIS specification the *minimum* supported set, but permits support of more recent versions. From my perspective as a model-maker and user, there are times when I cannot solve certain modeling problems without some of the latest features in the *-AMS languages and tools. This is not permitted in IBIS 4.1, as written. However, I understand there are other views on this situation, which became apparent in our (healthy) debate in the last IBIS Open Forum teleconference. I would like to continue and expand the discussion here to get a better overall picture on the problem so we can find the best solution for this problem. Please express your opinions and needs, so we could make a wise decision for the IBIS specification. Thanks, Arpad ======================================================================== ==== |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 07 Jul 2005 23:51:30 +0000 From: "lau yy" Subject: [IBIS-Users] rising waveform
Dear ALL,
 
Can someone show me my mistake? The warning message like below.
 
WARNING - Model DQ0: The [Rising Waveform]
      with [R_fixture]=70 Ohms and [V_fixture_max]=3.1V
      has MAX column DC endpoints of  1.74V and  3.10v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 1.71V and  3.10V),
      a difference of  1.94% and  0.01%, respectively.
Thanks alot.
 
 
 
rdgs
yylau
|------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 7 Jul 2005 17:08:48 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] rising waveform This is a multi-part message in MIME format. - ------=_NextPart_000_002D_01C58316.8A2559F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit There are several different reasons why this can occur. First is you did not let the waveform complete its rise (but that does not seem to be the case here), second the 70 Ohms in the model does not match the load used in the VT extraction. Third, the termination voltage used in the extraction does not match the one in the model. Forth, the summation of the clamp and pullup tables does not match the characteristics of the buffer as simulated., etc. Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of lau yy Sent: Thursday, July 07, 2005 4:52 PM To: ibis-users@eda.org Subject: [IBIS-Users] rising waveform Dear ALL, Can someone show me my mistake? The warning message like below. WARNING - Model DQ0: The [Rising Waveform] with [R_fixture]=70 Ohms and [V_fixture_max]=3.1V has MAX column DC endpoints of 1.74V and 3.10v, but an equivalent load applied to the model's I-V tables yields different voltages ( 1.71V and 3.10V), a difference of 1.94% and 0.01%, respectively. Thanks alot. rdgs yylau |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 - ------=_NextPart_000_002D_01C58316.8A2559F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There=20 are several different reasons why this can occur.  First is you did = not let=20 the waveform complete its rise (but that does not seem to be the case = here),=20 second the 70 Ohms in the model does not match the load used in the VT=20 extraction.  Third, the termination voltage used in the extraction = does not=20 match the one in the model.  Forth, the summation of the clamp and = pullup=20 tables does not match the characteristics of the buffer as simulated.,=20 etc.
 

Tom Dagostino
Teraspeed(R) Labs
13610 SW Harness = Lane
Beaverton, OR=20 97008
503-430-1065
tom@teraspeed.com
www.teraspeed.com

Te= raspeed=20 Consulting Group LLC
121 North River Drive
Narragansett, RI=20 02882
401-284-1827

-----Original Message-----
From: = owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org]On Behalf Of lau = yy
Sent:=20 Thursday, July 07, 2005 4:52 PM
To:=20 ibis-users@eda.org
Subject: [IBIS-Users] rising=20 waveform

Dear ALL,
 
Can someone show me my mistake? The warning message = like=20 below.
 
WARNING - Model DQ0: The [Rising Waveform]=20
      with [R_fixture]=3D70 Ohms and=20 [V_fixture_max]=3D3.1V
      has MAX = column DC=20 endpoints of  1.74V and  3.10v,=20 but
      an equivalent load applied to = the=20 model's I-V tables yields
      different = voltages=20 ( 1.71V and  3.10V),
      a = difference=20 of  1.94% and  0.01%, respectively.
Thanks alot.
 
 
 
rdgs
yylau
|-------------------------------------------= - -----------------------=20 |For help or to subscribe/unsubscribe, email majordomo@eda.org |with = just the=20 appropriate command message(s) in the body: | | help | subscribe ibis=20 | subscribe ibis-users = | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS=20 reflector archives exist under: | | = http://www.eda.org/pub/ibis/email_archive/=20 Recent | http://www.eda.org/pub/ibis/users_archive/ Recent |=20 http://www.eda.org/pub/ibis/email/ E-mail since = 1993
- ------=_NextPart_000_002D_01C58316.8A2559F0-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 07 Jul 2005 17:59:29 -0700 From: Bob Ross Subject: Re: [IBIS-Users] rising waveform Hl YY Lau: I would like to see the exact end points of the Rising Waveform Max table because there is a numerical issue. The Warning Message should be issued only if the mismatch is equal to or greater than 2.0% of the total calculated swing. In this case the swing is from 1.71 to 3.10 V or 1.39, and 2% of this is 0.0278 V. Your actual mismatch 0.03 V - outside of the 2% tolerance. Howover the reported mismatch is 1.91%, and no Warning should have been issued. So your starting point might be rounded up to 1.74 from a smaller value - causing a Warning message, but the actual values used to calculate the persentages might be the unrounded values - inside the 2% tolerance. If this is the case, we are not doing the calculations and reporting correctly However, there could be other numerical issues. I would have to see the full model to determine this. Bob lau yy wrote: > Dear ALL, > > Can someone show me my mistake? The warning message like below. > > WARNING - Model DQ0: The [Rising Waveform] > with [R_fixture]=70 Ohms and [V_fixture_max]=3.1V > has MAX column DC endpoints of 1.74V and 3.10v, but > an equivalent load applied to the model's I-V tables yields > different voltages ( 1.71V and 3.10V), > a difference of 1.94% and 0.01%, respectively. > Thanks alot. > > > > rdgs > yylau > |------------------------------------------------------------------ |For > help or to subscribe/unsubscribe, email majordomo@eda.org |with just the > appropriate command message(s) in the body: | | help | subscribe ibis | > subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or > email a written request to ibis-request@eda.org. | |IBIS reflector > archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ > Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | > http://www.eda.org/pub/ibis/email/ E-mail since 1993 - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 07 Jul 2005 19:28:38 -0700 From: Bob Ross Subject: [IBIS-Users] Re: [IBIS] FW: *-AMS language versions in IBIS Arpad: I support your view. The presumption is that the interested groups advancing the standardized languages are providing corrections and important advances to serve the industry. IBIS should be able to make use of the advances when officially available. Some new features may take time to adopt. However, that is not a valid reason for purposefully keeping IBIS fixed on a previous version. This creates the problem of when to advance the verision to some new, but non-current level. We cannot have any process based on commerical concensus because industrial plans are confidential and outside the scope of what IBIS can discuss. Instead, we must provide the best feature set to industry as a target (and reward) for the first company to adopt. Others can follow if it makes business sense. This keeps us out of confidential product development issues while automatically keeping IBIS up to date. However, the burden of what features to use shifts to the model developer. The model developer must know what features exist in the target tools of interest and use alternative (perhaps less optimal) approaches in order for the models to work and be validated. Otherwise the models would not be tested - a very dangerous practice. Bob Muranyi, Arpad wrote: > Hello everyone, > > I would like to generate discussion on VHDL-AMS and Verilog-AMS version > numbers in the IBIS specification. The IBIS 4.1 spec says, in part, the > following: > > | "VHDL-AMS" refers to "IEEE Standard VHDL Analog and Mixed-Signal > | Extensions", approved March 18, 1999 by the IEEE-SA Standards Board > and > | designated IEEE Std. 1076.1-1999. > | > | "Verilog-AMS" refers to the Analog and Mixed-Signal Extensions to > | Verilog-HDL as documented in the Verilog-AMS Language Reference, > Version > | 2.0. > > Please note that the *-AMS version numbers mentioned in the IBIS spec > are > fixed values. Verilog-AMS is already past Version 2.2 of its LRM, and > VHDL-AMS is due for a five-year renewal soon. > > As written, every time new version of these languages comes out, the > IBIS > specification will have to be updated to change the *-AMS version > numbers. > With IBIS updates occurring very infrequently, new and useful features > in > the *-AMS specifications may not be available to the IBIS community for > over a year (or more) after the new LRMs are approved. > > In attempt to remedy this problem, I authored BIRD99 which can be found > at: http://www.vhdl.org/pub/ibis/birds/bird99.txt. The BIRD makes the > *-AMS > language versions listed in the IBIS specification the *minimum* > supported > set, but permits support of more recent versions. > >>From my perspective as a model-maker and user, there are times when I > cannot > solve certain modeling problems without some of the latest features in > the > *-AMS languages and tools. This is not permitted in IBIS 4.1, as > written. > However, I understand there are other views on this situation, which > became > apparent in our (healthy) debate in the last IBIS Open Forum > teleconference. > I would like to continue and expand the discussion here to get a better > overall picture on the problem so we can find the best solution for this > problem. > > Please express your opinions and needs, so we could make a wise decision > for the IBIS specification. > > Thanks, > > Arpad > ======================================================================== > ==== > > ----------------------------------------------------------------- > |For help or to subscribe/unsubscribe, email majordomo@eda.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or email a request to ibis-request@eda.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda.org/pub/ibis/email_archive/ Recent > | http://www.eda.org/pub/ibis/users_archive/ Recent > | http://www.eda.org/pub/ibis/email/ E-mail since 1993 > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Fri, 8 Jul 2005 08:54:03 +0530 From: "Vivek Kumar Sundriyal" Subject: Re: [IBIS-Users] rising waveform Lau , I also had a similar problem sometime back. And the way to resolve is to increase the simulation time. In your case, a small increase in sim time should do the job. Cheers , Vivek "lau yy" cc: Sent by: Subject: [IBIS-Users] rising waveform owner-ibis-users@ eda.org 07/08/05 05:21 AM Dear ALL, Can someone show me my mistake? The warning message like below. WARNING - Model DQ0: The [Rising Waveform] with [R_fixture]=70 Ohms and [V_fixture_max]=3.1V has MAX column DC endpoints of 1.74V and 3.10v, but an equivalent load applied to the model's I-V tables yields different voltages ( 1.71V and 3.10V), a difference of 1.94% and 0.01%, respectively. Thanks alot. rdgs yylau |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 7 Jul 2005 23:43:41 -0400 From: "Andrew Ingraham" Subject: Re: [IBIS-Users] rising waveform > I also had a similar problem sometime back. And the way to resolve is to > increase the simulation time. > In your case, a small increase in sim time should do the job. Probably not in this case. This case is different. The final endpoint has an error of only 0.01%. It is the starting point that is off and is triggering the warning message. I think the other reasons cited by Tom Dagostino are where you should look. Another possibility is that the leading edge of the V/T data was manually truncated, and a little too much of it was cut off. Regards, Andy |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 7 Jul 2005 21:19:45 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] rising waveform I don't think this is the case in this model. The rising edge is the problem area. The end of the rise makes it to the power supply voltage of 3.10 Volts. Increasing the simulation time will only get you more of the output at 3.10 Volts. The issue is the starting voltage being higher than the IV curves predict. Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Vivek Kumar Sundriyal Sent: Thursday, July 07, 2005 8:24 PM To: lau yy Cc: ibis-users@eda.org; owner-ibis-users@eda.org Subject: Re: [IBIS-Users] rising waveform Lau , I also had a similar problem sometime back. And the way to resolve is to increase the simulation time. In your case, a small increase in sim time should do the job. Cheers , Vivek "lau yy" cc: Sent by: Subject: [IBIS-Users] rising waveform owner-ibis-users@ eda.org 07/08/05 05:21 AM Dear ALL, Can someone show me my mistake? The warning message like below. WARNING - Model DQ0: The [Rising Waveform] with [R_fixture]=70 Ohms and [V_fixture_max]=3.1V has MAX column DC endpoints of 1.74V and 3.10v, but an equivalent load applied to the model's I-V tables yields different voltages ( 1.71V and 3.10V), a difference of 1.94% and 0.01%, respectively. Thanks alot. rdgs yylau |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Fri, 8 Jul 2005 23:28:47 -0700 From: "Mirmak, Michael" Subject: [IBIS-Users] Agenda, IBIS Open Forum teleconference for July 15, 2005 IBIS Open Forum Meeting Agenda for July 15, 2005 Telephone Number Bridge Passcode 1-916-356-2663 1 966-3181 All meetings are 8:00 AM to 9:55 AM US Pacific Time. When calling into the meeting, provide the bridge number and passcode at the automated prompts. If asked by an operator, please request to join the IBIS Open Forum hosted by Michael Mirmak. For international numbers, please contact Michael Mirmak. 8:00 Check-In, Intros, Announcements Mirmak - Intros of New IBIS Participants, Meeting Quorum Mirmak - Call for Patents Mirmak - Membership Update and Treasurer's Report Mirmak - Review of Previous Meeting's Minutes (and ARs) Mirmak June 24, 2005 Open Forum Minutes - Web Page Updates Huq - Mailing List Administration Ross - Library Update Wang - Announcements, Opens for New Issues All 8:15 Project Discussions and Subcommittee Reports International/External Progress - IEC TC47 Ross - Other activities All EIA, ANSI Approval Activities Wolff ICM 1.1 Specification Status Green/Mirmak - Call for Approval Vote Summit Status All - DesignCon East - Asian IBIS Summit - Other Events Subcommittee Reports - Quality Haller - Model Review Green - Futures Mirmak - Cookbook Mirmak New Issues All 8:45 Technical Discussion BIRD99: AMS Language Versions Muranyi BIRD94.1: Clarifications on [Diff Pin] Parameters Muranyi BIRD95.5: Power Integrity Analysis using IBIS Huq et al BIRD97.2: Gate Modulation Effect Muranyi BIRD98: Gate Modulation Effect (table format) Muranyi IBISCHK4 BUG Status Angulo/Mirmak ICMCHK1 BUG Status Green/Mirmak New Technical Issues All 9:50 Wrap Up and Next Meeting Plans Mirmak - August 5, 2005 IBIS Open Forum 9:55 Sign Off |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 17:40:21 +0530 From: "Vivek Kumar Sundriyal" Subject: [IBIS-Users] Warning - "Typical value never becomes zero" Hi , I have developed the IBIS model using s2ibis3 and I am using IBIS version 3.2 When I compile the .ibs file, I get the following warning : WARNING - Model MODEL1: POWER Clamp : Typical value never becomes zero WARNING - Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING - Model MODEL1: POWER Clamp : Maximum value never becomes zero On looking at the Power clamp data, the current values that I get at 0.0V are : 0.3193mA 72.3000uA 0.6643mA for typ,min and max respectively. Can anyone elaborate on this warning ? And how serious is this ? Cheers , Vivek |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 14:52:03 +0200 From: Subject: [IBIS-Users] Differences between Hspice netlist simulation and Hspice B-element simulation - bug or feature? This is a multi-part message in MIME format. - ------_=_NextPart_001_01C58617.55FA3194 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi IBIS Experts, I have extracted IBIS model. To check the quality of this model I have = compared the results of simulation on Hspice B-element with simulation = on netlist - that means, I have used exactly the same stimuli applied on B-element = and on netlist (IBIS is extracted out of this netlist). What is disturbing me is that I see a difference between B-element and = netlist waveforms, i.e. B-element is always delayed in comparison to = netlist result. What is even more disturbing is that this delay is not = the same for rising and falling edge. Rising edge of B-element is = delayed for around 20ps and falling edge of B-element is delayed for = around 40ps. I have a feeling that this delay is somehow connected with = transient analysis step (.TRAN 1.96e-11 1.96e-09) but I am not sure. = Once again, I apply exactly the same stimuli on B-element and on netlist = (and of course the same termination - load). Has that to do something = with some version of Hspice or it is a problem of IBIS extraction tool = (s2ibis2)? So the question is: Is this difference between B-element and Hspice bug = or feature? If it is bug is it a problem of s2ibis2 or I perhaps the = question what is Hspice doing with B-element? And finally - what should = I do to repair the problem? Many thanks for any advice! Radovan Best regards / Mit freundlichen Gr=FC=DFen / S po=B9tovanjem Radovan Vuleti=E6 Infineon Technologies AG MP PD PDE Room 03.911 Balanstra=DFe 73 D-81541 M=FCnchen Phone: +49 (0)89 234 20108 Fax: +49 (0)89 234 27705 Fax (PC): +49 (0)89 234 955 5305=20 E-mail: radovan.vuletic@infineon.com - ------_=_NextPart_001_01C58617.55FA3194 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Differences between Hspice netlist simulation and Hspice = B-element simulation - bug or feature?

Hi IBIS Experts,

I have extracted IBIS model. To check = the quality of this model I have compared the results of simulation on = Hspice B-element with simulation on netlist -

that means, I have used exactly the = same stimuli applied on B-element and on netlist (IBIS is extracted out = of this netlist).

What is disturbing me is that I see a = difference between B-element and netlist waveforms, i.e. B-element is = always delayed in comparison to netlist result. What is even more = disturbing is that this delay is not the same for rising and falling = edge. Rising edge of B-element is delayed for around 20ps and falling = edge of B-element is delayed for around 40ps. I have a feeling that this = delay is somehow connected with transient analysis step (.TRAN 1.96e-11 = 1.96e-09) but I am not sure. Once again, I apply exactly the same = stimuli on B-element and on netlist (and of course the same termination = - - load). Has that to do something with some version of Hspice or it is a = problem of IBIS extraction tool (s2ibis2)?

So the question is: Is this difference = between B-element and Hspice bug or feature? If it is bug is it a = problem of s2ibis2 or I perhaps the question what is Hspice doing with = B-element? And finally - what should I do to repair the = problem?

Many thanks for any advice!
Radovan

Best regards / Mit = freundlichen Gr=FC=DFen / S po=B9tovanjem
Radovan = Vuleti=E6

Infineon Technologies AG
MP PD PDE
Room = 03.911
Balanstra=DFe 73
D-81541 M=FCnchen

Phone:          = +49 (0)89 234 20108
Fax:    =         +49 (0)89 234 = 27705
Fax (PC):       +49 (0)89 = 234 955 5305

E-mail: radovan.vuletic@infineon.com

- ------_=_NextPart_001_01C58617.55FA3194-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 18:25:38 +0530 From: Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hi Vivek, I have the following opinion about your problem. 1) For 0.0V as input your typical and maximum current values are significantly higher than they should be. The minimum current value is tolerable. They should be in micro-amps(i.e extremely low...very close to 0.0 A). Hence the errors. 2)You can remove the "Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING " by simply changing the Minimum current to 0.3000uA from 72.3000uA. Since the current is already in micro-Amperes this change will be quite insignifucant. 3)However you cannot do this to your typ and max curent readings, since such a change will be considered as a significant change. I suggest you go back to your netlist design,source files and check the Power Clamp part once again. Hope this helps. Regards, Nilimp Bhatt - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Vivek Kumar Sundriyal Sent: Monday, July 11, 2005 5:40 PM To: ibis-users@eda.org Subject: [IBIS-Users] Warning - "Typical value never becomes zero" Hi , I have developed the IBIS model using s2ibis3 and I am using IBIS version 3.2 When I compile the .ibs file, I get the following warning : WARNING - Model MODEL1: POWER Clamp : Typical value never becomes zero WARNING - - Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING - - Model MODEL1: POWER Clamp : Maximum value never becomes zero On looking at the Power clamp data, the current values that I get at 0.0V are : 0.3193mA 72.3000uA 0.6643mA for typ,min and max respectively. Can anyone elaborate on this warning ? And how serious is this ? Cheers , Vivek |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org with just |the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 17:28:11 +0200 From: Subject: [IBIS-Users] C_comp This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5862D.25A16213 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi IBIS experts (once again), Now about C_comp: in IBIS specification is written that the C_comp = defines the silicon die capacitance and that influences [Ramp] = parameters. Question would be how (is it used as capacitive load)? Is the [Ramp] the only parameter that is influenced by C_comp = influences, or there are some other things too? I mean, when I generate [Rising Waveform] and [Falling Waveform] = intrinsic capacitances of drivers and receivers, ESD structures and = wiring are already accounted (in netlist), so I assume that taking into = the account C_comp too would be kind of double counting.=20 Later, when simulation tool is using IBIS model, if there are [Rising = Waveform] and [Falling Waveform] this waveforms will be taken, so the = information about driver/receiver, ESD and wiring capacitances will be = "extracted" out of this curves, C_comp is not used - true or not? If there are no [Rising Waveform] or [Falling Waveform] the [Ramp] = parameter will be taken (true or not?). In this case simulation tool is = using only [Ramp] data (this data intrinsically contain C_comp), so the = C_comp is not used (true or not?) Once again, many thanks for any help! Regards, Radovan Best regards / Mit freundlichen Gr=FC=DFen / S po=B9tovanjem Radovan Vuleti=E6 Infineon Technologies AG MP PD PDE Room 03.911 Balanstra=DFe 73 D-81541 M=FCnchen Phone: +49 (0)89 234 20108 Fax: +49 (0)89 234 27705 Fax (PC): +49 (0)89 234 955 5305=20 E-mail: radovan.vuletic@infineon.com - ------_=_NextPart_001_01C5862D.25A16213 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable C_comp

Hi IBIS experts (once again),

Now about C_comp: in IBIS specification = is written that the C_comp defines the silicon die capacitance and that = influences [Ramp] parameters. Question would be how (is it used as = capacitive load)?

Is the [Ramp] the only parameter that = is influenced by C_comp influences, or there are some other things = too?

I mean, when I generate [Rising = Waveform] and [Falling Waveform] intrinsic capacitances of  drivers = and receivers, ESD structures and wiring are already accounted (in = netlist), so I assume that taking into the account C_comp too would be = kind of double counting.

Later, when simulation tool is using = IBIS model, if there are [Rising Waveform] and [Falling Waveform] this = waveforms will be taken, so the information about driver/receiver, ESD = and wiring capacitances will be "extracted" out of this = curves, C_comp is not used - true or not?

If there are no [Rising Waveform] or = [Falling Waveform] the [Ramp] parameter will be taken (true or not?). In = this case simulation tool is using only [Ramp] data (this data = intrinsically contain C_comp), so the C_comp is not used (true or = not?)

Once again, many thanks for any = help!
Regards,
Radovan

Best regards / Mit = freundlichen Gr=FC=DFen / S po=B9tovanjem
Radovan = Vuleti=E6

Infineon Technologies AG
MP PD PDE
Room = 03.911
Balanstra=DFe 73
D-81541 M=FCnchen

Phone:          = +49 (0)89 234 20108
Fax:    =         +49 (0)89 234 = 27705
Fax (PC):       +49 (0)89 = 234 955 5305

E-mail: radovan.vuletic@infineon.com

- ------_=_NextPart_001_01C5862D.25A16213-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 08:56:13 -0700 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] C_comp This is a multi-part message in MIME format. - ------_=_NextPart_001_01C58631.10976D0A Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Radovan, =20 IBIS simulators have a special algorithm which doesn't allow the C_comp to load the Vt curves or ramp in the model, but allows it to be visible for signals which arrive at the model. IN other words it is not visible from the inside out, but it is visible from the outside in. =20 Correct, when there is not Vt data in a model, Ramps are used. =20 Arpad =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 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On = Behalf Of Radovan.Vuletic@infineon.com Sent: Monday, July 11, 2005 8:28 AM To: ibis-users@eda.org Subject: [IBIS-Users] C_comp Hi IBIS experts (once again),=20 Now about C_comp: in IBIS specification is written that the C_comp = defines the silicon die capacitance and that influences [Ramp] = parameters. Question would be how (is it used as capacitive load)? Is the [Ramp] the only parameter that is influenced by C_comp = influences, or there are some other things too?=20 I mean, when I generate [Rising Waveform] and [Falling Waveform] = intrinsic capacitances of drivers and receivers, ESD structures and = wiring are already accounted (in netlist), so I assume that taking into = the account C_comp too would be kind of double counting.=20 Later, when simulation tool is using IBIS model, if there are [Rising = Waveform] and [Falling Waveform] this waveforms will be taken, so the = information about driver/receiver, ESD and wiring capacitances will be = "extracted" out of this curves, C_comp is not used - true or not? If there are no [Rising Waveform] or [Falling Waveform] the [Ramp] = parameter will be taken (true or not?). In this case simulation tool is = using only [Ramp] data (this data intrinsically contain C_comp), so the = C_comp is not used (true or not?) Once again, many thanks for any help!=20 Regards,=20 Radovan=20 Best regards / Mit freundlichen Gr=FC=DFen / S po=B9tovanjem=20 Radovan Vuleti=E6=20 Infineon Technologies AG=20 MP PD PDE=20 Room 03.911=20 Balanstra=DFe 73=20 D-81541 M=FCnchen=20 Phone: +49 (0)89 234 20108=20 Fax: +49 (0)89 234 27705=20 Fax (PC): +49 (0)89 234 955 5305=20 E-mail: radovan.vuletic@infineon.com=20 - ------_=_NextPart_001_01C58631.10976D0A Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable C_comp
Radovan,
 
IBIS simulators have a special algorithm = which=20 doesn't
allow the C_comp to load the Vt curves or = ramp in=20 the
model, but allows it to be visible for = signals=20 which
arrive at the model.  IN other words it = is not=20 visible
from the inside out, but it is visible from = the=20 outside
in.
 
Correct, when there is not Vt data in a = model,=20 Ramps
are used.
 
Arpad
=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

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of=20 Radovan.Vuletic@infineon.com
Sent: Monday, July 11, 2005 = 8:28=20 AM
To: ibis-users@eda.org
Subject: [IBIS-Users]=20 C_comp

Hi IBIS experts (once again),

Now about C_comp: in IBIS specification = is written=20 that the C_comp defines the silicon die capacitance and that influences = [Ramp]=20 parameters. Question would be how (is it used as capacitive = load)?

Is the [Ramp] the only parameter that is = influenced=20 by C_comp influences, or there are some other things too?

I mean, when I generate [Rising Waveform] = and=20 [Falling Waveform] intrinsic capacitances of  drivers and = receivers, ESD=20 structures and wiring are already accounted (in netlist), so I assume = that=20 taking into the account C_comp too would be kind of double counting. =

Later, when simulation tool is using IBIS = model, if=20 there are [Rising Waveform] and [Falling Waveform] this waveforms will = be taken,=20 so the information about driver/receiver, ESD and wiring capacitances = will be=20 "extracted" out of this curves, C_comp is not used - true or = not?

If there are no [Rising Waveform] or = [Falling=20 Waveform] the [Ramp] parameter will be taken (true or not?). In this = case=20 simulation tool is using only [Ramp] data (this data intrinsically = contain=20 C_comp), so the C_comp is not used (true or not?)

Once again, many thanks for any = help!=20
Regards,
Radovan

Best regards / Mit = freundlichen=20 Gr=FC=DFen / S po=B9tovanjem =
Radovan = Vuleti=E6

Infineon Technologies=20 AG
MP PD=20 PDE
Room 03.911
Balanstra=DFe 73
D-81541 M=FCnchen

Phone: =20         +49 (0)89 234 = 20108=20
Fax:    =         +49=20 (0)89 234 27705
Fax (PC):       = +49 (0)89 234=20 955 5305

E-mail:=20 radovan.vuletic@infineon.com

- ------_=_NextPart_001_01C58631.10976D0A-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 08:58:39 -0700 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] Differences between Hspice netlist simulation and Hspice B-element simulation - bug or feature? This is a multi-part message in MIME format. - ------_=_NextPart_001_01C58631.67CD3599 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Radovan, =20 =20 This could be also a problem with s2ibis. If you are careful with time correlating the Vt data you generate with the stimulus that triggered it, then you should be able to get correct waveform overlays between your SPICE and IBIS models. Watch out for the threshold levels on the SPICE model's input, and the slope of the stimulus on it also... =20 Arpad =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 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On = Behalf Of Radovan.Vuletic@infineon.com Sent: Monday, July 11, 2005 5:52 AM To: ibis-users@eda.org Subject: [IBIS-Users] Differences between Hspice netlist simulation and = Hspice B-element simulation - bug or feature? Hi IBIS Experts,=20 I have extracted IBIS model. To check the quality of this model I have = compared the results of simulation on Hspice B-element with simulation = on netlist - that means, I have used exactly the same stimuli applied on B-element = and on netlist (IBIS is extracted out of this netlist). What is disturbing me is that I see a difference between B-element and = netlist waveforms, i.e. B-element is always delayed in comparison to = netlist result. What is even more disturbing is that this delay is not = the same for rising and falling edge. Rising edge of B-element is = delayed for around 20ps and falling edge of B-element is delayed for = around 40ps. I have a feeling that this delay is somehow connected with = transient analysis step (.TRAN 1.96e-11 1.96e-09) but I am not sure. = Once again, I apply exactly the same stimuli on B-element and on netlist = (and of course the same termination - load). Has that to do something = with some version of Hspice or it is a problem of IBIS extraction tool = (s2ibis2)? So the question is: Is this difference between B-element and Hspice bug = or feature? If it is bug is it a problem of s2ibis2 or I perhaps the = question what is Hspice doing with B-element? And finally - what should = I do to repair the problem? Many thanks for any advice!=20 Radovan=20 Best regards / Mit freundlichen Gr=FC=DFen / S po=B9tovanjem=20 Radovan Vuleti=E6=20 Infineon Technologies AG=20 MP PD PDE=20 Room 03.911=20 Balanstra=DFe 73=20 D-81541 M=FCnchen=20 Phone: +49 (0)89 234 20108=20 Fax: +49 (0)89 234 27705=20 Fax (PC): +49 (0)89 234 955 5305=20 E-mail: radovan.vuletic@infineon.com=20 - ------_=_NextPart_001_01C58631.67CD3599 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Differences between Hspice netlist simulation and = Hspice B-element simulation - bug or feature?
Radovan,
 
 
This could be also a problem with s2ibis.  If you are=20 careful
with time correlating the Vt data you generate with the=20 stimulus
that triggered it, then you should be able to get=20 correct
waveform overlays between your SPICE and IBIS models.  = Watch=20 out
for the threshold levels on the SPICE model's input, and the=20 slope
of the stimulus on it also...
 
Arpad
=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
From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of=20 Radovan.Vuletic@infineon.com
Sent: Monday, July 11, 2005 = 5:52=20 AM
To: ibis-users@eda.org
Subject: [IBIS-Users] = Differences=20 between Hspice netlist simulation and Hspice B-element simulation - bug = or=20 feature?

Hi IBIS Experts,

I have extracted IBIS model. To check the = quality of=20 this model I have compared the results of simulation on Hspice B-element = with=20 simulation on netlist -

that means, I have used exactly the same = stimuli=20 applied on B-element and on netlist (IBIS is extracted out of this=20 netlist).

What is disturbing me is that I see a = difference=20 between B-element and netlist waveforms, i.e. B-element is always = delayed in=20 comparison to netlist result. What is even more disturbing is that this = delay is=20 not the same for rising and falling edge. Rising edge of B-element is = delayed=20 for around 20ps and falling edge of B-element is delayed for around = 40ps. I have=20 a feeling that this delay is somehow connected with transient analysis = step=20 (.TRAN 1.96e-11 1.96e-09) but I am not sure. Once again, I apply exactly = the=20 same stimuli on B-element and on netlist (and of course the same = termination -=20 load). Has that to do something with some version of Hspice or it is a = problem=20 of IBIS extraction tool (s2ibis2)?

So the question is: Is this difference = between=20 B-element and Hspice bug or feature? If it is bug is it a problem of = s2ibis2 or=20 I perhaps the question what is Hspice doing with B-element? And finally = - - what=20 should I do to repair the problem?

Many thanks for any advice! =
Radovan

Best regards / Mit = freundlichen=20 Gr=FC=DFen / S po=B9tovanjem =
Radovan = Vuleti=E6

Infineon Technologies=20 AG
MP PD=20 PDE
Room 03.911
Balanstra=DFe 73
D-81541 M=FCnchen

Phone: =20         +49 (0)89 234 = 20108=20
Fax:    =         +49=20 (0)89 234 27705
Fax (PC):       = +49 (0)89 234=20 955 5305

E-mail:=20 radovan.vuletic@infineon.com

- ------_=_NextPart_001_01C58631.67CD3599-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 10:20:52 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Before you change your model you need to understand what is causing the currents that you see. Is there some kind of weak pulldown device associated with his input? If you just change one entry in your IV tables you are likely to cause other problems. You have not shown us any other data from the tables. If you just change the 0.00V current value you will likely get a non-monotonic error. Warnings are OK in IBIS models if you have done the engineering to know that the cause of the warning is really the characteristic of the device. Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of nilimp.vipul@wipro.com Sent: Monday, July 11, 2005 5:56 AM To: Vivek.Kumar.Sundriyal@nsc.com; ibis-users@eda.org Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hi Vivek, I have the following opinion about your problem. 1) For 0.0V as input your typical and maximum current values are significantly higher than they should be. The minimum current value is tolerable. They should be in micro-amps(i.e extremely low...very close to 0.0 A). Hence the errors. 2)You can remove the "Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING " by simply changing the Minimum current to 0.3000uA from 72.3000uA. Since the current is already in micro-Amperes this change will be quite insignifucant. 3)However you cannot do this to your typ and max curent readings, since such a change will be considered as a significant change. I suggest you go back to your netlist design,source files and check the Power Clamp part once again. Hope this helps. Regards, Nilimp Bhatt - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Vivek Kumar Sundriyal Sent: Monday, July 11, 2005 5:40 PM To: ibis-users@eda.org Subject: [IBIS-Users] Warning - "Typical value never becomes zero" Hi , I have developed the IBIS model using s2ibis3 and I am using IBIS version 3.2 When I compile the .ibs file, I get the following warning : WARNING - Model MODEL1: POWER Clamp : Typical value never becomes zero WARNING - - Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING - - Model MODEL1: POWER Clamp : Maximum value never becomes zero On looking at the Power clamp data, the current values that I get at 0.0V are : 0.3193mA 72.3000uA 0.6643mA for typ,min and max respectively. Can anyone elaborate on this warning ? And how serious is this ? Cheers , Vivek |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org with just |the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 10:24:44 -0700 From: "Lynne D. Green" Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hello, Vivek, Yes, this is serious. Simulation symptoms could include DC convergence failure and/or transient convergence failure. Consider this circuit: - - When the voltage at the I/O pin is the same as PowerRef, there is 0.000V across the resistor. The resistor current is thus 0.0A. However, your clamp table says that 0.3193mA is flowing under this condition. In this case, the two currents are not equal, and KCL is violated. Best things to check are [Power Ref] and [Power Clamp Ref]. One could also check SPICE tolerance options to make sure they are not too large. Best regards, Lynne "IBIS training when you need it, where you need it." Dr. Lynne Green Green Streak Programs http://www.greenstreakprograms.com 425-788-0412 lgreen22@mindspring.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Vivek Kumar Sundriyal Sent: Monday, July 11, 2005 5:10 AM To: ibis-users@eda.org Subject: [IBIS-Users] Warning - "Typical value never becomes zero" Hi , I have developed the IBIS model using s2ibis3 and I am using IBIS version 3.2 When I compile the .ibs file, I get the following warning : WARNING - Model MODEL1: POWER Clamp : Typical value never becomes zero WARNING - Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING - Model MODEL1: POWER Clamp : Maximum value never becomes zero On looking at the Power clamp data, the current values that I get at 0.0V are : 0.3193mA 72.3000uA 0.6643mA for typ,min and max respectively. Can anyone elaborate on this warning ? And how serious is this ? Cheers , Vivek |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 09:49:39 -0600 From: "Bilski, Robert" Subject: [IBIS-Users] ibis 10/100 ethernet models This is a multi-part message in MIME format. - ------_=_NextPart_001_01C58630.25AC576D Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have a question about 10/100 Ethernet IBIS models.. Recently I started = working with ICX and I noticed that most vendors do not provide IBIS = models for their ethernet side of the components. Could someone tell me = what is the reason behind this. Where can I get ethernet models or how = should I create them? What do I do when modeling ethernet?, etc.=20 =20 Your help will be greatly appreciated. =20 Best Regards =20 Robert =20 The information contained in this e-mail message is PRIVATE. It may = contain confidential information and may be legally privileged. It is = intended for the exclusive use of the addressee(s). If you are not the = intended recipient, you are hereby notified that any dissemination, = distribution or reproduction of this communication is strictly = prohibited. If the intended recipient(s) cannot be reached or if a = transmission problem has occurred, please notify the sender immediately = by return e-mail and destroy all copies of this message.=20 Thank you.=20 - ------_=_NextPart_001_01C58630.25AC576D Content-Type: text/html; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable C_comp
Hi=20 all,
 
I have=20 a question about 10/100 Ethernet IBIS models.. Recently I started = working=20 with ICX and I noticed that most vendors do not provide IBIS models for = their=20 ethernet side of the components. Could someone tell me what is the = reason behind=20 this. Where can I get ethernet models or how should I create them? What = do I do=20 when modeling ethernet?, etc.
 
Your=20 help will be greatly appreciated.
 
Best=20 Regards
 
Robert
 

The information contained in this = e-mail message is PRIVATE. It may contain confidential information and = may be legally privileged. It is intended for the exclusive use of the = addressee(s). If you are not the intended recipient, you are hereby = notified that any dissemination, distribution or reproduction of this = communication is strictly prohibited. If the intended recipient(s) = cannot be reached or if a transmission problem has occurred, please = notify the sender immediately by return e-mail and destroy all copies of = this message.
Thank you. =

- ------_=_NextPart_001_01C58630.25AC576D-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 11:05:12 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Lynne If there is a pulldown resistor or some other device that is sinking current to some other voltage then the current in the powerclamp table will not be 0 current at 0.00 Volts. True, a pulldown should be included in the groundclamp but we don't know enough about this buffer to know what has happened in it. Is there a termination to some intermediate voltage? We don't know. The model maker needs to determine the cause of this current before anyone can say if this current is a problem or not. The engineering must be done first then conclusions can be drawn, not the other way around. Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lynne D. Green Sent: Monday, July 11, 2005 10:25 AM To: 'Vivek Kumar Sundriyal'; ibis-users@eda.org Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hello, Vivek, Yes, this is serious. Simulation symptoms could include DC convergence failure and/or transient convergence failure. Consider this circuit: - - When the voltage at the I/O pin is the same as PowerRef, there is 0.000V across the resistor. The resistor current is thus 0.0A. However, your clamp table says that 0.3193mA is flowing under this condition. In this case, the two currents are not equal, and KCL is violated. Best things to check are [Power Ref] and [Power Clamp Ref]. One could also check SPICE tolerance options to make sure they are not too large. Best regards, Lynne "IBIS training when you need it, where you need it." Dr. Lynne Green Green Streak Programs http://www.greenstreakprograms.com 425-788-0412 lgreen22@mindspring.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Vivek Kumar Sundriyal Sent: Monday, July 11, 2005 5:10 AM To: ibis-users@eda.org Subject: [IBIS-Users] Warning - "Typical value never becomes zero" Hi , I have developed the IBIS model using s2ibis3 and I am using IBIS version 3.2 When I compile the .ibs file, I get the following warning : WARNING - Model MODEL1: POWER Clamp : Typical value never becomes zero WARNING - Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING - Model MODEL1: POWER Clamp : Maximum value never becomes zero On looking at the Power clamp data, the current values that I get at 0.0V are : 0.3193mA 72.3000uA 0.6643mA for typ,min and max respectively. Can anyone elaborate on this warning ? And how serious is this ? Cheers , Vivek |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 11 Jul 2005 16:21:26 -0700 From: "Lynne D. Green" Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hello, Vivek. Tom speaks much truth. An on-die pullup "resistor" could be included in a [Power Clamp] table. If the pullup resistor went to the clamp reference, one could expect 0A at 0V, but not if it went to [Pullup Ref]. This could be addressed in [Notes] information by a model maker. As always, the IBIS Model Review Committee welcomes models for review and comment. http://www.eigroup.org/ibis/support.htm Best regards, Lynne - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Tom Dagostino Sent: Monday, July 11, 2005 11:05 AM To: Lynne D. Green; 'Vivek Kumar Sundriyal'; ibis-users@eda.org Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Lynne If there is a pulldown resistor or some other device that is sinking current to some other voltage then the current in the powerclamp table will not be 0 current at 0.00 Volts. True, a pulldown should be included in the groundclamp but we don't know enough about this buffer to know what has happened in it. Is there a termination to some intermediate voltage? We don't know. The model maker needs to determine the cause of this current before anyone can say if this current is a problem or not. The engineering must be done first then conclusions can be drawn, not the other way around. Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lynne D. Green Sent: Monday, July 11, 2005 10:25 AM To: 'Vivek Kumar Sundriyal'; ibis-users@eda.org Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hello, Vivek, Yes, this is serious. Simulation symptoms could include DC convergence failure and/or transient convergence failure. Consider this circuit: - - When the voltage at the I/O pin is the same as PowerRef, there is 0.000V across the resistor. The resistor current is thus 0.0A. However, your clamp table says that 0.3193mA is flowing under this condition. In this case, the two currents are not equal, and KCL is violated. Best things to check are [Power Ref] and [Power Clamp Ref]. One could also check SPICE tolerance options to make sure they are not too large. Best regards, Lynne "IBIS training when you need it, where you need it." Dr. Lynne Green Green Streak Programs http://www.greenstreakprograms.com 425-788-0412 lgreen22@mindspring.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Vivek Kumar Sundriyal Sent: Monday, July 11, 2005 5:10 AM To: ibis-users@eda.org Subject: [IBIS-Users] Warning - "Typical value never becomes zero" Hi , I have developed the IBIS model using s2ibis3 and I am using IBIS version 3.2 When I compile the .ibs file, I get the following warning : WARNING - Model MODEL1: POWER Clamp : Typical value never becomes zero WARNING - Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING - Model MODEL1: POWER Clamp : Maximum value never becomes zero On looking at the Power clamp data, the current values that I get at 0.0V are : 0.3193mA 72.3000uA 0.6643mA for typ,min and max respectively. Can anyone elaborate on this warning ? And how serious is this ? Cheers , Vivek |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org with just |the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org with just |the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 12 Jul 2005 17:54:05 +0530 From: "Vivek Kumar Sundriyal" Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hi , Thanks to all of you for replying to my query. The problem that I faced was due to an error from my end in setting up the spice. I did not hook up one of the signals which caused the problem of a high current at 0.0V. I made the desired changes and I now get currents in the range of nA/pA at 0.0V I hope this is not an issue (current is pA/nA is close to zero) Thanks , Vivek "Lynne D. Green" , ibis-users@eda.org cc: 07/12/05 04:51 AM Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hello, Vivek. Tom speaks much truth. An on-die pullup "resistor" could be included in a [Power Clamp] table. If the pullup resistor went to the clamp reference, one could expect 0A at 0V, but not if it went to [Pullup Ref]. This could be addressed in [Notes] information by a model maker. As always, the IBIS Model Review Committee welcomes models for review and comment. http://www.eigroup.org/ibis/support.htm Best regards, Lynne - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Tom Dagostino Sent: Monday, July 11, 2005 11:05 AM To: Lynne D. Green; 'Vivek Kumar Sundriyal'; ibis-users@eda.org Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Lynne If there is a pulldown resistor or some other device that is sinking current to some other voltage then the current in the powerclamp table will not be 0 current at 0.00 Volts. True, a pulldown should be included in the groundclamp but we don't know enough about this buffer to know what has happened in it. Is there a termination to some intermediate voltage? We don't know. The model maker needs to determine the cause of this current before anyone can say if this current is a problem or not. The engineering must be done first then conclusions can be drawn, not the other way around. Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Lynne D. Green Sent: Monday, July 11, 2005 10:25 AM To: 'Vivek Kumar Sundriyal'; ibis-users@eda.org Subject: RE: [IBIS-Users] Warning - "Typical value never becomes zero" Hello, Vivek, Yes, this is serious. Simulation symptoms could include DC convergence failure and/or transient convergence failure. Consider this circuit: - - When the voltage at the I/O pin is the same as PowerRef, there is 0.000V across the resistor. The resistor current is thus 0.0A. However, your clamp table says that 0.3193mA is flowing under this condition. In this case, the two currents are not equal, and KCL is violated. Best things to check are [Power Ref] and [Power Clamp Ref]. One could also check SPICE tolerance options to make sure they are not too large. Best regards, Lynne "IBIS training when you need it, where you need it." Dr. Lynne Green Green Streak Programs http://www.greenstreakprograms.com 425-788-0412 lgreen22@mindspring.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Vivek Kumar Sundriyal Sent: Monday, July 11, 2005 5:10 AM To: ibis-users@eda.org Subject: [IBIS-Users] Warning - "Typical value never becomes zero" Hi , I have developed the IBIS model using s2ibis3 and I am using IBIS version 3.2 When I compile the .ibs file, I get the following warning : WARNING - Model MODEL1: POWER Clamp : Typical value never becomes zero WARNING - Model MODEL1: POWER Clamp : Minimum value never becomes zero WARNING - Model MODEL1: POWER Clamp : Maximum value never becomes zero On looking at the Power clamp data, the current values that I get at 0.0V are : 0.3193mA 72.3000uA 0.6643mA for typ,min and max respectively. Can anyone elaborate on this warning ? And how serious is this ? Cheers , Vivek |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org with just |the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org with just |the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 12 Jul 2005 12:27:24 -0700 From: "Nash, Tim J (FL51)" Subject: [IBIS-Users] Which IBIS version to use??? This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C58717.BB6818EA Content-Type: text/plain There seems to be some confusion among my peers as to which IBIS version we should be working to. The latest ANSI version appears to be 3.2, but there are specifications available up to 4.1. The parser available in latest released versions of Hyperlinx and ICX is still v3.2, so I'm not sure that Hyperlinx or ICX would even recognize v4.1 keywords. Is there an "official" committee recommendation of what version should be utilized in new designs - the latest available, or the latest ANSI approved version? Thanks in advance, Tim __________________________________ Timothy J. Nash, P.E. > Honeywell, Inc. > Defense & Space Electronic Systems > 13350 U.S. Hwy 19 N > M/S 825-1 > Clearwater, FL 33764-7290 > Office : 727-539-2437 > Fax : 727-539-2183 > Email : tim.j.nash@honeywell.com > - ------_=_NextPart_001_01C58717.BB6818EA Content-Type: text/html Content-Transfer-Encoding: quoted-printable Which IBIS version to use???

There seems to be some confusion among = my peers as to which IBIS version we should be working to.  The = latest ANSI version appears to be 3.2, but there are specifications = available up to 4.1.  The parser available in latest released = versions of Hyperlinx and ICX is still v3.2, so I'm not sure that = Hyperlinx or ICX would even recognize v4.1 keywords.  Is there an = "official" committee recommendation of what version should be = utilized in new designs - the latest available, or the latest ANSI = approved version?

Thanks in advance,
Tim



__________________________________
Timothy J. = Nash, P.E.
Honeywell, = Inc.
Defense & = Space Electronic Systems
13350 U.S. Hwy = 19 N
M/S = 825-1
Clearwater, = FL  33764-7290
Office : = 727-539-2437
Fax     : 727-539-2183
Email  = :  tim.j.nash@honeywell.com

- ------_=_NextPart_001_01C58717.BB6818EA-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 12 Jul 2005 13:45:00 -0700 From: "Muranyi, Arpad" Subject: [IBIS-Users] Re: IV curve sweep range Hello everyone, I hope you don't mind that I brought this discussion to the IBIS and IBIS users reflectors, but I wanted to save Mike a bunch of forwarding these messages to and from me (since I don't want to sign up to the IBIS quality list at the moment). Plus the subject ultimately is a spec related one, so it may not hurt to discuss it in these lists. I agree with Tom, that those original IBIS ranges are still useful. The point I was trying to make is that IBIS REQUIRES those ranges, period. True, the parser doesn't flag models now which do not obey these requirements of the IBIS specification, but technically these models are out of spec. Also true, the model maker can always do a smaller range, and then add two points on the two ends, just to satisfy the spec requirements, but if the table has 100 points already, the model make will have to figure out which other two points they have to remove before they can add the points at the ends. Forcing the model maker to generate models for the -Vcc to 2Vcc range may reduce the quality of the model, because many points may be used up in those areas of the curves which never get used, and at times it may not be possible to generate those points due to convergence issues. The comment from Bob about the current limiting at 1A or 10A seems to be a related, but different issue. I would like to see that the IBIS specification is fixed so that it doesn't REQUIRE the -Vcc to 2Vcc range. But I agree, this may be a difficult one, because if we just eliminate the rule, we may start getting a bunch of useless models, if people don't know what ranges they should provide. So what should the spec say then? Spell out some STRONGLY RECOMMENDED rules? Thanks, Arpad ================================================================== - -----Original Message----- From: ibis-quality-bounce@freelists.org [mailto:ibis-quality-bounce@freelists.org] On Behalf Of Robert Haller Sent: Tuesday, July 12, 2005 1:03 PM To: ibis-quality@freelists.org Subject: [ibis-quality] Re: IV curve sweep range Tom, Michael Agreed that sweeping over the entire range makes sense in come cases and it is excessive in others. But in order to avoid excess currents and meet the spec in its presently approved state, the committee reached consensus that limiting the current at something resonable (1Amp) below the hard ibis check ceiling of 10 Amps seemed acceptable. We want to minimize warnings from the parser and most devices (that people are simulating with IBIS) operate below an 1 amp. The point we were trying to make was when sweep terminated devices (i.e. ODT) it is important to sweep across the entire 'legal' range to avoid simulators interpolating or extrapolating. I have persoannly always had an issue with the excessivly wide range and would support a bird that reduces it to something reasonable. The rub is getting consensus in Open forum on what is reasonable with all of the exceptions.... my $.02 Bob Tom Dagostino wrote: >There are still a lot non busses that people need to simulate, not all of >them will be terminated. In addition some people simulate open connectors >which may have non terminated lines by definition. So, yes there are places >where it does not make sense to do the -Vcc to 2*Vcc range but there are >cases still where it makes sense. > >Tom Dagostino >Teraspeed(R) Labs >13610 SW Harness Lane >Beaverton, OR 97008 >503-430-1065 >tom@teraspeed.com >www.teraspeed.com > >Teraspeed Consulting Group LLC >121 North River Drive >Narragansett, RI 02882 >401-284-1827 > >-----Original Message----- >From: ibis-quality-bounce@freelists.org >[mailto:ibis-quality-bounce@freelists.org]On Behalf Of Mirmak, Michael >Sent: Tuesday, July 12, 2005 12:00 PM >To: ibis-quality@freelists.org >Subject: [ibis-quality] IV curve sweep range > > >Forwarded from Arpad Muranyi... > >- MM > >-----Original Message----- >From: Muranyi, Arpad >Sent: Tuesday, July 12, 2005 11:20 AM >To: ibis-quality-bounce@freelists.org >Cc: Mirmak, Michael >Subject: IV curve sweep range > >Hello everyone, > >I am not monitoring this email reflector, and I don't plan on >subscribing, but Mike Mirmak forwarded me a message regarding the IV >curve sweep range discussion, to which I would like to add a few >comments. I don't know what exactly is being proposed, I am just going >to mention my views here. > >The problem I see is that IBIS requires a sweep range of -Vcc to 2*Vcc. >This comes from the days when most buffers switched rail to rail and >most buses were unterminated. The reason for this range stems from the >T-line reflection theory, that the signal can double at the end of the >line. If we had a strong driver, which could drive close to the rail, >then the doubling of this signal could span a range close to -Vcc or >+2*Vcc assuming no clamping effects at the end of the line. > >The problem is that most modern buses and drivers are not operating like >this any more. For one, the signal swing >doesn't go rail-to-rail any more, and second, most buses are terminated. >Even if we ignore the termination question, the reduced-swing signaling >alone warrants a reconsideration of the IBIS rule. > >One of my favorite examples is GTL. The signal goes from a low level >between 0-0.5V to a high level of 1.5V. If I took 0-1.5, even if I >doubled the signal swing on the top and bottom, I would get a range of >-1.5V to 3.0V. Aside from the fact that the bus is terminated and we >will never see a doubling at the end of the T-line, compare this range >with what IBIS would require if this buffer was powered by 3.3V: it >would be -3.6V to 6.6V, almost double! This clearly doesn't make sense. > >I would propose that we should write a BIRD on this, and change the IBIS >specification so that it would not REQUIRE the range of -Vcc to 2*Vcc. >I am not sure what it should say yet, but I would definitely NOT favor >that the parser should be changed to check the ranges in the IBIS files >against the IBIS rules. I would much prefer to have a rule that is >based on signaling, though I have to admit that this may be somewhat >more complicated to spell out. > >Please comment, > >Arpad >=========================================================== >--------------------------------------------------------------------- >IBIS Quality website: http://www.eda.org/pub/ibis/quality_wip/ >IBIS Quality archives: http://www.freelists.org/archives/ibis-quality >To unsubscribe send an email: > To: ibis-quality-request@freelists.org > Subject: unsubscribe > > >--------------------------------------------------------------------- >IBIS Quality website: http://www.eda.org/pub/ibis/quality_wip/ >IBIS Quality archives: http://www.freelists.org/archives/ibis-quality >To unsubscribe send an email: > To: ibis-quality-request@freelists.org > Subject: unsubscribe > > > - --------------------------------------------------------------------- IBIS Quality website: http://www.eda.org/pub/ibis/quality_wip/ IBIS Quality archives: http://www.freelists.org/archives/ibis-quality To unsubscribe send an email: To: ibis-quality-request@freelists.org Subject: unsubscribe |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 12 Jul 2005 14:06:26 -0700 From: "Beal, Weston" Subject: RE: [IBIS-Users] Which IBIS version to use??? This is a multi-part message in MIME format. - ------_=_NextPart_001_01C58725.915925FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tim, =20 Since IBIS 2.1 I've not seen any simulator that support and utilizes all keywords and parameters of any version of the IBIS spec. You need to evaluate what aspects of the IBIS spec apply to your I/O pins and use those appropriate keywords. Then you specify the IBIS version of the file to be the lowest number that includes the features you've used. Throughout this process you should read the latest version of the specification since it will be the clearest and most complete description of the various features. =20 Even though ICX might not explicitly state that it supports IBIS 4.1, it does support the [external model], [external circuit], [node declaration], and [circuit call] keywords quite well. Check the ICX modeling guide for slight differences from the official IBIS syntax. =20 Regards, Weston =20 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Nash, Tim J (FL51) Sent: Tuesday, July 12, 2005 12:27 PM To: ibis-users@eda.org Subject: [IBIS-Users] Which IBIS version to use??? There seems to be some confusion among my peers as to which IBIS version we should be working to. The latest ANSI version appears to be 3.2, but there are specifications available up to 4.1. The parser available in latest released versions of Hyperlinx and ICX is still v3.2, so I'm not sure that Hyperlinx or ICX would even recognize v4.1 keywords. Is there an "official" committee recommendation of what version should be utilized in new designs - the latest available, or the latest ANSI approved version? Thanks in advance,=20 Tim=20 __________________________________=20 Timothy J. Nash, P.E.=20 Honeywell, Inc.=20 Defense & Space Electronic Systems=20 13350 U.S. Hwy 19 N=20 M/S 825-1=20 Clearwater, FL 33764-7290=20 Office : 727-539-2437=20 Fax : 727-539-2183=20 Email : tim.j.nash@honeywell.com=20 - ------_=_NextPart_001_01C58725.915925FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Which IBIS version to use???
Tim,
 
Since IBIS 2.1 I've not seen any simulator = that support=20 and utilizes all keywords and parameters of any version of the IBIS = spec. You=20 need to evaluate what aspects of the IBIS spec apply to your I/O pins = and use=20 those appropriate keywords. Then you specify the IBIS version of the = file to be=20 the lowest number that includes the features you've used. Throughout = this=20 process you should read the latest version of the specification since it = will be=20 the clearest and most complete description of the various=20 features.
 
Even though ICX might not explicitly state = that it=20 supports IBIS 4.1, it does support the [external model], [external = circuit],=20 [node declaration], and [circuit call] keywords quite well. Check the = ICX=20 modeling guide for slight differences from the official IBIS=20 syntax.
 
Regards,
Weston
 

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of Nash, Tim J=20 (FL51)
Sent: Tuesday, July 12, 2005 12:27 PM
To:=20 ibis-users@eda.org
Subject: [IBIS-Users] Which IBIS version to = use???

There seems to be some confusion among my = peers as to=20 which IBIS version we should be working to.  The latest ANSI = version=20 appears to be 3.2, but there are specifications available up to = 4.1.  The=20 parser available in latest released versions of Hyperlinx and ICX is = still v3.2,=20 so I'm not sure that Hyperlinx or ICX would even recognize v4.1 = keywords. =20 Is there an "official" committee recommendation of what version should = be=20 utilized in new designs - the latest available, or the latest ANSI = approved=20 version?

Thanks in advance,
Tim



__________________________________
Timothy J. Nash, P.E.
Honeywell, Inc.
Defense & Space Electronic = Systems=20
13350 U.S. Hwy 19 = N=20
M/S 825-1 =
Clearwater, FL  = 33764-7290=20
Office : = 727-539-2437=20
Fax     :=20 727-539-2183
Email  :  tim.j.nash@honeywell.com=20

- ------_=_NextPart_001_01C58725.915925FE-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 12 Jul 2005 16:26:03 -0500 From: Subject: RE: [IBIS-Users] Re: IV curve sweep range I would like to see the sweep range linked to the allowed or expected signal swing. If the buffer can be used in a "less than perfectly terminated" topology where rising or falling overshoot outside 0 to Vcc can happen, then the sweep should be REQUIRED to cover that range. If the signal swing will always be well within 0 to Vcc, then a reduced sweep range could be allowed. my $.02 Aubrey Sparkman Enterprise Engineering Signal Integrity Team Dell, Inc. Aubrey_Sparkman@Dell.com (512) 723-3592 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi, Arpad Sent: Tuesday, July 12, 2005 3:45 PM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS-Users] Re: IV curve sweep range Hello everyone, I hope you don't mind that I brought this discussion to the IBIS and IBIS users reflectors, but I wanted to save Mike a bunch of forwarding these messages to and from me (since I don't want to sign up to the IBIS quality list at the moment). Plus the subject ultimately is a spec related one, so it may not hurt to discuss it in these lists. I agree with Tom, that those original IBIS ranges are still useful. The point I was trying to make is that IBIS REQUIRES those ranges, period. True, the parser doesn't flag models now which do not obey these requirements of the IBIS specification, but technically these models are out of spec. Also true, the model maker can always do a smaller range, and then add two points on the two ends, just to satisfy the spec requirements, but if the table has 100 points already, the model make will have to figure out which other two points they have to remove before they can add the points at the ends. Forcing the model maker to generate models for the -Vcc to 2Vcc range may reduce the quality of the model, because many points may be used up in those areas of the curves which never get used, and at times it may not be possible to generate those points due to convergence issues. The comment from Bob about the current limiting at 1A or 10A seems to be a related, but different issue. I would like to see that the IBIS specification is fixed so that it doesn't REQUIRE the -Vcc to 2Vcc range. But I agree, this may be a difficult one, because if we just eliminate the rule, we may start getting a bunch of useless models, if people don't know what ranges they should provide. So what should the spec say then? Spell out some STRONGLY RECOMMENDED rules? Thanks, Arpad ================================================================== - -----Original Message----- From: ibis-quality-bounce@freelists.org [mailto:ibis-quality-bounce@freelists.org] On Behalf Of Robert Haller Sent: Tuesday, July 12, 2005 1:03 PM To: ibis-quality@freelists.org Subject: [ibis-quality] Re: IV curve sweep range Tom, Michael Agreed that sweeping over the entire range makes sense in come cases and it is excessive in others. But in order to avoid excess currents and meet the spec in its presently approved state, the committee reached consensus that limiting the current at something resonable (1Amp) below the hard ibis check ceiling of 10 Amps seemed acceptable. We want to minimize warnings from the parser and most devices (that people are simulating with IBIS) operate below an 1 amp. The point we were trying to make was when sweep terminated devices (i.e. ODT) it is important to sweep across the entire 'legal' range to avoid simulators interpolating or extrapolating. I have persoannly always had an issue with the excessivly wide range and would support a bird that reduces it to something reasonable. The rub is getting consensus in Open forum on what is reasonable with all of the exceptions.... my $.02 Bob Tom Dagostino wrote: >There are still a lot non busses that people need to simulate, not all of >them will be terminated. In addition some people simulate open connectors >which may have non terminated lines by definition. So, yes there are places >where it does not make sense to do the -Vcc to 2*Vcc range but there are >cases still where it makes sense. > >Tom Dagostino >Teraspeed(R) Labs >13610 SW Harness Lane >Beaverton, OR 97008 >503-430-1065 >tom@teraspeed.com >www.teraspeed.com > >Teraspeed Consulting Group LLC >121 North River Drive >Narragansett, RI 02882 >401-284-1827 > >-----Original Message----- >From: ibis-quality-bounce@freelists.org >[mailto:ibis-quality-bounce@freelists.org]On Behalf Of Mirmak, Michael >Sent: Tuesday, July 12, 2005 12:00 PM >To: ibis-quality@freelists.org >Subject: [ibis-quality] IV curve sweep range > > >Forwarded from Arpad Muranyi... > >- MM > >-----Original Message----- >From: Muranyi, Arpad >Sent: Tuesday, July 12, 2005 11:20 AM >To: ibis-quality-bounce@freelists.org >Cc: Mirmak, Michael >Subject: IV curve sweep range > >Hello everyone, > >I am not monitoring this email reflector, and I don't plan on >subscribing, but Mike Mirmak forwarded me a message regarding the IV >curve sweep range discussion, to which I would like to add a few >comments. I don't know what exactly is being proposed, I am just going >to mention my views here. > >The problem I see is that IBIS requires a sweep range of -Vcc to 2*Vcc. >This comes from the days when most buffers switched rail to rail and >most buses were unterminated. The reason for this range stems from the >T-line reflection theory, that the signal can double at the end of the >line. If we had a strong driver, which could drive close to the rail, >then the doubling of this signal could span a range close to -Vcc or >+2*Vcc assuming no clamping effects at the end of the line. > >The problem is that most modern buses and drivers are not operating like >this any more. For one, the signal swing doesn't go rail-to-rail any >more, and second, most buses are terminated. >Even if we ignore the termination question, the reduced-swing signaling >alone warrants a reconsideration of the IBIS rule. > >One of my favorite examples is GTL. The signal goes from a low level >between 0-0.5V to a high level of 1.5V. If I took 0-1.5, even if I >doubled the signal swing on the top and bottom, I would get a range of >-1.5V to 3.0V. Aside from the fact that the bus is terminated and we >will never see a doubling at the end of the T-line, compare this range >with what IBIS would require if this buffer was powered by 3.3V: it >would be -3.6V to 6.6V, almost double! This clearly doesn't make sense. > >I would propose that we should write a BIRD on this, and change the IBIS >specification so that it would not REQUIRE the range of -Vcc to 2*Vcc. >I am not sure what it should say yet, but I would definitely NOT favor >that the parser should be changed to check the ranges in the IBIS files >against the IBIS rules. I would much prefer to have a rule that is >based on signaling, though I have to admit that this may be somewhat >more complicated to spell out. > >Please comment, > >Arpad >=========================================================== >--------------------------------------------------------------------- >IBIS Quality website: http://www.eda.org/pub/ibis/quality_wip/ >IBIS Quality archives: http://www.freelists.org/archives/ibis-quality >To unsubscribe send an email: > To: ibis-quality-request@freelists.org > Subject: unsubscribe > > >--------------------------------------------------------------------- >IBIS Quality website: http://www.eda.org/pub/ibis/quality_wip/ >IBIS Quality archives: http://www.freelists.org/archives/ibis-quality >To unsubscribe send an email: > To: ibis-quality-request@freelists.org > Subject: unsubscribe > > > - --------------------------------------------------------------------- IBIS Quality website: http://www.eda.org/pub/ibis/quality_wip/ IBIS Quality archives: http://www.freelists.org/archives/ibis-quality To unsubscribe send an email: To: ibis-quality-request@freelists.org Subject: unsubscribe |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org with just |the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 12 Jul 2005 14:35:51 -0700 From: "Nash, Tim J (FL51)" Subject: RE: [IBIS-Users] Which IBIS version to use??? This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C58729.ACD319A3 Content-Type: text/plain Weston, I've noticed what you are talking about. If you look in any documentation for ICX or Hyperlinx (I'm not sure about SpectraQuest), I don't think that global support for any particular version of IBIS is explicitly stated anywhere. I'm not sure why this is. Is it because the standard is in such a state of flux (i.e. growth of keywords) or is the reason more political in nature? I know I'm speculating as to what the reason may be, but it makes it difficult to plan any sort of analysis, when your not clearly sure of what a tool does and doesn't support without reading the manual cover-to-cover. If tools said they support version 3.2, then you could rest assured that it supported EVERYTHING in 3.2, not just KEY FEATURES of 3.2. Thanks, Tim _____ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Beal, Weston Sent: Tuesday, July 12, 2005 5:06 PM To: ibis-users@eda.org Subject: RE: [IBIS-Users] Which IBIS version to use??? Tim, Since IBIS 2.1 I've not seen any simulator that support and utilizes all keywords and parameters of any version of the IBIS spec. You need to evaluate what aspects of the IBIS spec apply to your I/O pins and use those appropriate keywords. Then you specify the IBIS version of the file to be the lowest number that includes the features you've used. Throughout this process you should read the latest version of the specification since it will be the clearest and most complete description of the various features. Even though ICX might not explicitly state that it supports IBIS 4.1, it does support the [external model], [external circuit], [node declaration], and [circuit call] keywords quite well. Check the ICX modeling guide for slight differences from the official IBIS syntax. Regards, Weston _____ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Nash, Tim J (FL51) Sent: Tuesday, July 12, 2005 12:27 PM To: ibis-users@eda.org Subject: [IBIS-Users] Which IBIS version to use??? There seems to be some confusion among my peers as to which IBIS version we should be working to. The latest ANSI version appears to be 3.2, but there are specifications available up to 4.1. The parser available in latest released versions of Hyperlinx and ICX is still v3.2, so I'm not sure that Hyperlinx or ICX would even recognize v4.1 keywords. Is there an "official" committee recommendation of what version should be utilized in new designs - the latest available, or the latest ANSI approved version? Thanks in advance, Tim __________________________________ Timothy J. Nash, P.E. Honeywell, Inc. Defense & Space Electronic Systems 13350 U.S. Hwy 19 N M/S 825-1 Clearwater, FL 33764-7290 Office : 727-539-2437 Fax : 727-539-2183 Email : tim.j.nash@honeywell.com - ------_=_NextPart_001_01C58729.ACD319A3 Content-Type: text/html Which IBIS version to use???
Weston,
 
I've noticed what you are talking about.  If you look in any documentation for ICX or Hyperlinx (I'm not sure about SpectraQuest), I don't think that global support for any particular version of IBIS is explicitly stated anywhere.  I'm not sure why this is.  Is it because the standard is in such a state of flux (i.e. growth of keywords) or is the reason more political in nature?  I know I'm speculating as to what the reason may be, but it makes it difficult to plan any sort of analysis, when your not clearly sure of what a tool does and doesn't support without reading the manual cover-to-cover.  If tools said they support version 3.2, then you could rest assured that it supported EVERYTHING in 3.2, not just KEY FEATURES of 3.2.
 
Thanks,
Tim

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Beal, Weston
Sent: Tuesday, July 12, 2005 5:06 PM
To: ibis-users@eda.org
Subject: RE: [IBIS-Users] Which IBIS version to use???

Tim,
 
Since IBIS 2.1 I've not seen any simulator that support and utilizes all keywords and parameters of any version of the IBIS spec. You need to evaluate what aspects of the IBIS spec apply to your I/O pins and use those appropriate keywords. Then you specify the IBIS version of the file to be the lowest number that includes the features you've used. Throughout this process you should read the latest version of the specification since it will be the clearest and most complete description of the various features.
 
Even though ICX might not explicitly state that it supports IBIS 4.1, it does support the [external model], [external circuit], [node declaration], and [circuit call] keywords quite well. Check the ICX modeling guide for slight differences from the official IBIS syntax.
 
Regards,
Weston
 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Nash, Tim J (FL51)
Sent: Tuesday, July 12, 2005 12:27 PM
To: ibis-users@eda.org
Subject: [IBIS-Users] Which IBIS version to use???

There seems to be some confusion among my peers as to which IBIS version we should be working to.  The latest ANSI version appears to be 3.2, but there are specifications available up to 4.1.  The parser available in latest released versions of Hyperlinx and ICX is still v3.2, so I'm not sure that Hyperlinx or ICX would even recognize v4.1 keywords.  Is there an "official" committee recommendation of what version should be utilized in new designs - the latest available, or the latest ANSI approved version?

Thanks in advance,
Tim



__________________________________
Timothy J. Nash, P.E.
Honeywell, Inc.
Defense & Space Electronic Systems
13350 U.S. Hwy 19 N
M/S 825-1
Clearwater, FL  33764-7290
Office : 727-539-2437
Fax     : 727-539-2183
Email  :  tim.j.nash@honeywell.com

- ------_=_NextPart_001_01C58729.ACD319A3-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 12 Jul 2005 14:37:43 -0700 From: Abdulrahman Rafiq Subject: Re: [IBIS-Users] Which IBIS version to use??? Tim,

The latest IBIS version is 4.1 . ICX does support,  as for Hyperlynx, Mentor Graphic's has incorporated ver4.1 in the engineering builds for the next release.

Hope this helps in answering your question.

Abdulrahman Rafiq
Cisco Systems, Inc


From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Nash, Tim J (FL51)
Sent: Tuesday, July 12, 2005 12:27 PM
To: ibis-users@eda.org
Subject: [IBIS-Users] Which IBIS version to use???

There seems to be some confusion among my peers as to which IBIS version we should be working to.  The latest ANSI version appears to be 3.2, but there are specifications available up to 4.1.  The parser available in latest released versions of Hyperlinx and ICX is still v3.2, so I'm not sure that Hyperlinx or ICX would even recognize v4.1 keywords.  Is there an "official" committee recommendation of what version should be utilized in new designs - the latest available, or the latest ANSI approved version?

Thanks in advance,
Tim



__________________________________
Timothy J. Nash, P.E.
Honeywell, Inc.
Defense & Space Electronic Systems
13350 U.S. Hwy 19 N
M/S 825-1
Clearwater, FL  33764-7290
Office : 727-539-2437
Fax     : 727-539-2183
Email  :  tim.j.nash@honeywell.com 


-- 
===========================================================================
      |           |       Abdulrahman Rafiq
     :|:         :|:      Hardware/IO Interconnect Engineer
    :|||:       :|||:     (DSW Tech Group/Central-Engineering/SIPD)
 .:|||||||:...:|||||||:.  Phone    : +1-408-527-5540
 C i s c o S y s t e m s  Fax      : +1-408-526-6603
                          Email    : arafiq@cisco.com
                          Epage    : arafiq@epage.cisco.com
      www.cisco.com       MailStop : SJCG/2/2
      800-250-4800        URL      : http://wwwin-people.cisco.com/~arafiq
============================================================================
(Refrence URL, IBIS Committee: http://www.eigroup.org/ibis/)

|------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ End of ibis-users V1 #62 ************************