From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #50 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Friday, January 14 2005 Volume 01 : Number 050 ---------------------------------------------------------------------- Date: Thu, 06 Jan 2005 10:39:33 -0800 From: arnab Subject: [IBIS-Users] queries regarding ibis This is a multi-part message in MIME format. - ------=_NextPart_000_0068_01C4F3DC.0291C9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have some doubts regarding generation of ibis models 1.Is it possible to generate IO model for 2 power supplies?If yes then = how do we go about it? 2. Can we have the ibis models generated for a high drive as well as low = drive for the i/o buffers.Presently we keep the drive low and generate = the models. Any help in this regard would be appreciated.Thanking in advance. warm regards arnab hazarika - ------=_NextPart_000_0068_01C4F3DC.0291C9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

I have some doubts regarding = generation of=20 ibis models

1.Is it possible to generate IO model for 2 power=20 supplies?If yes then how do we go about it?

2. Can we have the ibis models generated for a high drive as = well as=20 low drive for the i/o buffers.Presently we keep the drive low and = generate the=20 models.

Any help in this = regard would=20 be appreciated.Thanking in advance.

warm regards

arnab=20 hazarika

Hi all,

I have some doubts regarding = generation of=20 ibis models

1.Is it possible to generate IO model for 2 power=20 supplies?If yes then how do we go about it?

warm regards

arnab=20 hazarika

- ------=_NextPart_000_0068_01C4F3DC.0291C9C0-- Scanned by the SecureSynergy VirusScreen Service. For more information log on to : http://www.securesynergyonline.com or http://www.securesynergy.com - ----------------------------------------------------------------- |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 |------------------------------------------------------------------ |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, 6 Jan 2005 10:02:48 -0800 From: "lgreen" Subject: RE: [IBIS-Users] [IBIS] queries regarding ibis This is a multi-part message in MIME format. - ------=_NextPart_000_0026_01C4F3D6.E057D520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Arnab, 1) To use two power supplies to the I/O buffer: Edit the SPICE input file(s) to add the DC power supply, and make sure the node name matches the appropriate pin on the buffer. Avoid the use of ".GLOBAL" commands. 2) The two drive conditions (high/low) are two separate models. You need to modify the SPICE netlist to set the I/O buffer into its high-drive state and create a second model. Use [Model Selector] to allow swapping of model assignment. 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 _____ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of arnab Sent: Thursday, January 06, 2005 10:40 AM To: ibis@eda.org Cc: ibis-users@eda.org Subject: [IBIS-Users] [IBIS] queries regarding ibis Hi all, I have some doubts regarding generation of ibis models 1.Is it possible to generate IO model for 2 power supplies?If yes then how do we go about it? 2. Can we have the ibis models generated for a high drive as well as low drive for the i/o buffers.Presently we keep the drive low and generate the models. Any help in this regard would be appreciated.Thanking in advance. warm regards arnab hazarika - ------=_NextPart_000_0026_01C4F3D6.E057D520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, = Arnab,

1) = To use two power supplies to the I/O buffer: Edit the SPICE = input file(s) to add the DC power supply, and make sure the node name matches = the appropriate pin on the buffer. Avoid the use of = “.GLOBAL” commands.

2) = The two drive conditions (high/low) are two separate = models. You need to modify the SPICE netlist to set the I/O buffer into its = high-drive state and create a second model. Use [Model Selector] to allow = swapping of model assignment.

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

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of arnab
Sent: Thursday, January = 06, 2005 10:40 AM
To: ibis@eda.org
Cc: = ibis-users@eda.org
Subject: [IBIS-Users] = [IBIS] queries regarding ibis

Hi = all,

I have some doubts = regarding generation of ibis models

1.Is it possible to = generate IO model for 2 power supplies?If yes then how do we go = about it?

2. Can we have the ibis models generated for a high drive as well as low = drive for the i/o buffers.Presently we keep the drive low and generate the = models.

Any help in this regard would be appreciated.Thanking in = advance.

warm = regards

arnab = hazarika

- ------=_NextPart_000_0026_01C4F3D6.E057D520-- |------------------------------------------------------------------ |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, 6 Jan 2005 12:35:35 -0800 From: "Muranyi, Arpad" Subject: [IBIS-Users] RE: [IBIS] queries regarding ibis This is a multi-part message in MIME format. - ------_=_NextPart_001_01C4F42F.46B73EC8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Arnab, =20 What do you mean by "for 2 power supplies"? A single I/O connected to 2 different voltages, or the same I/O buffer being used once at one voltage and another time at another supply voltage? =20 If it is the latter, you can use the [Model Selector] keyword with multiple [Model]s each of which are made with a different voltage. =20 If it is the former, than I wonder how that buffer works, because I can't see how, for example, a pullup could pull to two different voltages... =20 However, please note that each IV table has their own reference voltage keywords, which allows you to connect them to different voltages. An example for this would be a 5 volt safe 3.3 volt PCI buffer where the pullup uses 3.3 V and the power clam uses 5 v. =20 I hope this helps. =20 Arpad Muranyi Intel Corporation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 arnab Sent: Thursday, January 06, 2005 10:40 AM To: ibis@eda.org Cc: ibis-users@eda.org Subject: [IBIS] queries regarding ibis Hi all, =20 I have some doubts regarding generation of ibis models =20 1.Is it possible to generate IO model for 2 power supplies?If yes then = how do we go about it? 2. Can we have the ibis models generated for a high drive as well as low = drive for the i/o buffers.Presently we keep the drive low and generate = the models. Any help in this regard would be appreciated.Thanking in advance. =20 warm regards arnab hazarika - ------_=_NextPart_001_01C4F42F.46B73EC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Arnab,

What do you mean by "for 2 power supplies"? A single=20 I/O

connected to 2 different voltages, or the same I/O=20 buffer

being used once at one voltage and another time at=20 another

supply voltage?

If it is the latter, you can use the [Model Selector]=20 keyword

with multiple [Model]s each of which are made with a=20 different

voltage.

If it is the former, than I wonder how that buffer=20 works,

because I can't see how, for example, a pullup = could=20 pull

to two different voltages...

However, please note that each IV table has their own=20 reference

voltage keywords, which allows you to connect them to=20 different

voltages. An example for this would be a 5 volt safe 3.3 = volt=20 PCI

buffer where the pullup uses 3.3 V and the power clam uses 5=20 v.

I hope this helps.

Arpad Muranyi

Intel Corporation

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 arnab
Sent: = Thursday,=20 January 06, 2005 10:40 AM
To: ibis@eda.org
Cc:=20 ibis-users@eda.org
Subject: [IBIS] queries regarding=20 ibis

Hi all,

I have some doubts regarding = generation of=20 ibis models

1.Is it possible to generate IO model for 2 power=20 supplies?If yes then how do we go about it?

2. Can we have the ibis = models=20 generated for a high drive as well as low drive for the i/o = buffers.Presently we=20 keep the drive low and generate the models.

Any=20 help in this regard would be appreciated.Thanking in=20 advance.

warm regards

arnab=20 hazarika

- ------_=_NextPart_001_01C4F42F.46B73EC8-- |------------------------------------------------------------------ |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, 07 Jan 2005 12:50:36 -0800 From: Ray Anderson Subject: [IBIS-Users] General question on IBIS and SSO simulations After working on Power Distribution issues at the PCB level for quite a number of years I'm now tasked with upgrading our company's IBIS models with respect to package parasitic modeling. As an aid in coming up to speed on some of the issues involved I have a general question in regards to utilizing IBIS models to simulate SSO noise issues. I've reviewed a number of the presentations and papers on the IBIS website from past Summits and other sources and have come away with a mixed message regarding the usefulness of IBIS in modeling SSO. I am trying to determine if it will be useful to our customers if we provide full parasitic information for the power and ground nets in our parts. Can that RLC information effectively be utilized in IBIS simulations to produce useful results? From what I've read, some authors contend that IBIS models are adequate to model SSO problems if proper package parasitic data and on chip capacitance data is provided while it seems that some others tend to question whether it can be done today with the present state of IBIS. Any comments and/or advice on the topic will be most welcome. Raymond Anderson Senior Signal Integrity Staff Engineer Xilinx Inc. |------------------------------------------------------------------ |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, 07 Jan 2005 13:03:55 -0800 From: Ray Anderson Subject: Re: [IBIS-Users] General question on IBIS and SSO simulations I just wanted to add that I am aware of the modifications and issues raised during the BIRD95 discussions. As any enhancements based on that BIRD are at this time unknown and in any case won't be implemented into simulators until some time in the not-so-near future, my question was framed with the present IBIS capabilities and limitations in mind. - -Ray Ray Anderson wrote: > > After working on Power Distribution issues at the PCB level for quite > a number of years I'm now tasked with upgrading our company's IBIS > models with respect to package parasitic modeling. As an aid in coming > up to speed on some of the issues involved I have a general question > in regards to utilizing IBIS models to simulate SSO noise issues. > > I've reviewed a number of the presentations and papers on the IBIS > website from past Summits and other sources and have come away with a > mixed message regarding the usefulness of IBIS in modeling SSO. I am > trying to determine if it will be useful to our customers if we > provide full parasitic information for the power and ground nets in > our parts. Can that RLC information effectively be utilized in IBIS > simulations to produce useful results? From what I've read, some > authors contend that IBIS models are adequate to model SSO problems > if proper package parasitic data and on chip capacitance data is > provided while it seems that some others tend to question whether it > can be done today with the present state of IBIS. > > Any comments and/or advice on the topic will be most welcome. |------------------------------------------------------------------ |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: Sat, 08 Jan 2005 23:37:39 +0200 From: Peleg Itzik Subject: [IBIS-Users] BIRD 95 Comments. Hello All I sure think that BIRD 95 is very important and will enhance IBIS modeling a step foreword. Power Integrity Analysis is very important part when evaluation the performance of an interface. My notes to SSO/ SSN analysis using IBIS based on my experience. I have tried to connect an IBIS model with inductive supply and compare it to its SPICE source pad with the same conditions. (when comparing the IBIS to the SPICE using ideal supply the results are the same). The results I got were: 1. The power drop in the IBIS power terminal was bigger then the spice. 2. The signal degradation (rise time) was bigger in the spice (the spice has a significant degradation of the rise time while the IBIS looked almost the same as ideal supply case). This results mismatch since I would expect that in the system with the bigger drop in the power rail the bigger degradation of the signal would be. I have to mention that I have tried it in one simulation tool and I am relaying on the tool implementation of IBIS (I didn't try to implement myself the IBIS using primitive parts). And now for the question: Assuming that the currents I_bypass, I_pre, I_term in BIRD 95 diagram are totally zero. This is the case for the current IBIS modeling that we have without BIRD 95. I will expect lower current consumption then the real SPICE and as a results lower power drop in the IBIS. Also I would expect degradation of the rise time like the spice. This is contrary to what I have seen and describe above. Because of that I have tried to ask in the teleconference (7/jan) if there's an algorithm that IBIS can mimic Spice when the power supply drop. I think that BIRD 95 can led us to the ability to get more accurate current consumption of the IBIS Buffer and then we get the response of the power system to this currents and get the power supply voltage drop. In this point if IBIS cant translate this voltage drop to a correct behavior in the IO pin then all the effort is useless. I would like also to know if some one has tried to compare IBIS to SPICE on non ideal power supply and got good correlation. I can implement the IBIS myself in the simulation tool, If theoretically IBIS can give the right results in the IO pin due to the voltage drop (Can someone back this up and provide some feedback on that). And back to BIRD 95: The current is measured with the resistance and inductance of the power supply rail of the pad. While the rising and falling v(t) table are measured with ideal supply. Isn't it better to measure the current on an ideal supply so the current is correlated to the voltage response that was capture in the rising or falling wave form. Please elaborate why the current is measured with the inductance and resistance. - -- Regards Itzik Peleg Board Technology Group Marvell Semiconductor Israel Ltd 6 Ha'mada St. Industrial Area P.O.Box 692 Yokneam 20692 ISRAEL Email - itzik.peleg@il.marvell.com Tel - +972 4 9091192 Cell - +972 54 4452482 Fax - +972 4 9091501 WWW Page: http://www.marvell.com ======================================================================== This message may contain confidential, proprietary or legally privileged information. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone, or by e-mail and delete the message from your computer. Thank you! ======================================================================== |------------------------------------------------------------------ |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: Sat, 08 Jan 2005 14:01:11 -0800 From: Syed Huq Subject: Re: [IBIS-Users] BIRD 95 Comments. Hi Peleg, Thanks for your comments on the 7th teleconf. Some responses in-line - Syed On Sat, 2005-01-08 at 13:37, Peleg Itzik wrote: > And back to BIRD 95: > > The current is measured with the resistance and inductance of the power > supply rail of the pad. While the rising and falling v(t) table are > measured with ideal supply. > Isn't it better to measure the current on an ideal supply so the current > is correlated to the voltage response that was capture in the rising or > falling wave form. > Please elaborate why the current is measured with the inductance and > resistance. The L_xxx and R_xxx in the diagram are on-die parasitics. These are part of the encrypted SPICE you may have. We wanted to show that these components are present in your netlist as you make your measurements. These user is *not* placing any specific L_xxx or R_xxx to make these measurements. We do want time coreelated V/T and I/T. Ideal supply maynot give you the kind of SSN you wish to simulate. Regards, Syed - -- IBIS Vice-Chair & Webmaster Cisco Systems, Inc |------------------------------------------------------------------ |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: Sat, 8 Jan 2005 16:12:12 -0800 From: "Zhiping Yang" Subject: Re: [IBIS-Users] BIRD 95 Comments. Hi Peleg, Thanks for your comments on our proposal. Very good questions about the IBIS model capability in SSO simulation. Since Syed has replied your questions on the BIRD95, I will try to answer your questions on the IBIS itself. Current version of IBIS could over-estimate or under-estimate the SSO noise in the simulation when it is compared with HSPICE model. I will explain in what conditions it will over-estimate and in what conditions it will under-estimate. Current IBIS model neglects the pre-driver current. If the predriver current is relatively large (which is typical for very complicated I/O buffer at 0.13um process and below), the IBIS model will underestimate the SSO noise. If the HSPICE model only include the last stage of the I/O buffer and there are relatively large amount of on-die decaps are embedded in the HSPICE model itself, the SSO simulation with IBIS model will overestimate the SSO noise. This is the case that you already saw in your simulation. The first reason for over-estimate is that IBIS simulator is very hard (I don't know whether I should say impossible) to adjust the buffer driver strength due to the voltage drop. A lot of IBIS simulators on the market will not adjust, so the current is the same as the ideal power supply which is bigger than nonideal power supply. The second reason is that on-die decap in the HSPICE model could provide the high-speed current which is needed for high-speed I/O switching. For current IBIS, it is not able to model the on-die decap, so all the high-speed current has to come from the outside of the I/O buffer, which could overestimate the I/O current when it is compared to the HSPICE model. If you have any questions on my explanations, please let me know. Thanks. Best regards, Zhiping - ----- Original Message ----- From: "Peleg Itzik" To: "IBIS Users" Sent: Saturday, January 08, 2005 1:37 PM Subject: [IBIS-Users] BIRD 95 Comments. > Hello All > > I sure think that BIRD 95 is very important and will enhance IBIS > modeling a step foreword. > Power Integrity Analysis is very important part when evaluation the > performance of an interface. > > My notes to SSO/ SSN analysis using IBIS based on my experience. > > I have tried to connect an IBIS model with inductive supply and compare > it to its SPICE source pad with the same conditions. > (when comparing the IBIS to the SPICE using ideal supply the results are > the same). > The results I got were: > 1. The power drop in the IBIS power terminal was bigger then the spice. > 2. The signal degradation (rise time) was bigger in the spice (the spice > has a significant degradation of the rise time while the IBIS looked > almost the same as ideal supply case). > > This results mismatch since I would expect that in the system with the > bigger drop in the power rail the bigger degradation of the signal would be. > > I have to mention that I have tried it in one simulation tool and I am > relaying on the tool implementation of IBIS (I didn't try to implement > myself the IBIS using primitive parts). > > And now for the question: Assuming that the currents I_bypass, I_pre, > I_term in BIRD 95 diagram are totally zero. This is the case for the > current IBIS modeling that we have without BIRD 95. I will expect lower > current consumption then the real SPICE and as a results lower power > drop in the IBIS. > Also I would expect degradation of the rise time like the spice. This is > contrary to what I have seen and describe above. > > Because of that I have tried to ask in the teleconference (7/jan) if > there's an algorithm that IBIS can mimic Spice when the power supply drop. > I think that BIRD 95 can led us to the ability to get more accurate > current consumption of the IBIS Buffer and then we get the response of > the power system to this currents and get the power supply voltage drop. > In this point if IBIS cant translate this voltage drop to a correct > behavior in the IO pin then all the effort is useless. > > I would like also to know if some one has tried to compare IBIS to SPICE > on non ideal power supply and got good correlation. > I can implement the IBIS myself in the simulation tool, If theoretically > IBIS can give the right results in the IO pin due to the voltage drop > (Can someone back this up > and provide some feedback on that). > > And back to BIRD 95: > > The current is measured with the resistance and inductance of the power > supply rail of the pad. While the rising and falling v(t) table are > measured with ideal supply. > Isn't it better to measure the current on an ideal supply so the current > is correlated to the voltage response that was capture in the rising or > falling wave form. > Please elaborate why the current is measured with the inductance and > resistance. > > -- > Regards > > Itzik Peleg > Board Technology Group > > Marvell Semiconductor Israel Ltd > 6 Ha'mada St. Industrial Area > P.O.Box 692 Yokneam 20692 ISRAEL > Email - itzik.peleg@il.marvell.com > Tel - +972 4 9091192 > Cell - +972 54 4452482 > Fax - +972 4 9091501 > WWW Page: http://www.marvell.com > ======================================================================== > This message may contain confidential, proprietary or legally privileged > information. The information is intended only for the use of the > individual or entity named above. If the reader of this message is not > the intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. > If you have received this communication in error, please notify us > immediately by telephone, or by e-mail and delete the message from > your computer. > > Thank you! > ======================================================================== > > > > |------------------------------------------------------------------ > |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, 10 Jan 2005 01:58:13 +0000 From: "lee yang" Subject: [IBIS-Users] IV Curves Hi IBIS experts: I have a few questions regarding IBIS data: 1) What is the reason of ground clamp and pulldown data is ground relative while power clamp and pullup data is vcc relative? 2) The IV curves data is covered from -vcc to 2vcc, in what condition the voltage would become -vcc? (eg1: output is driving vcc and the receiver end is being shorted, the reflection coefficient is -1, then the maximum negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v and the reciever end is being shorted, the reflection coefficient is -1 as well, would it be any reflection if the output is driving 0V with reciever end being shorted to ground?) Hope you all could shed some light here. Thanks. Yours Faithfully, LY _________________________________________________________________ Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ New look and improved results. Give it a try! |------------------------------------------------------------------ |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: Sun, 9 Jan 2005 20:41:50 -0800 From: "Tom Dagostino" Subject: RE: [IBIS-Users] IV Curves Think about reflections off an open transmission line for your answer. Tom Dagostino Teraspeed Consulting Group LLC 503-430-1065 tom@teraspeed.com www.teraspeed.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of lee yang Sent: Sunday, January 09, 2005 5:58 PM To: ibis-users@eda.org Subject: [IBIS-Users] IV Curves Hi IBIS experts: I have a few questions regarding IBIS data: 1) What is the reason of ground clamp and pulldown data is ground relative while power clamp and pullup data is vcc relative? 2) The IV curves data is covered from -vcc to 2vcc, in what condition the voltage would become -vcc? (eg1: output is driving vcc and the receiver end is being shorted, the reflection coefficient is -1, then the maximum negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v and the reciever end is being shorted, the reflection coefficient is -1 as well, would it be any reflection if the output is driving 0V with reciever end being shorted to ground?) Hope you all could shed some light here. Thanks. Yours Faithfully, LY _________________________________________________________________ Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ New look and improved results. Give it a try! |------------------------------------------------------------------ |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, 10 Jan 2005 07:10:47 +0000 From: "lee yang" Subject: RE: [IBIS-Users] IV Curves Hi Tom, Thanks for your responce... However, i couldn't get you clearly. If the transmission line is being opened, the reflection coefficient is 1, how could it become -vcc? Appreciate if you could explain it in more details. Could someone please help with my 2 questions below? Thanks and much appreciated. - -LY >From: "Tom Dagostino" >Reply-To: >To: "lee yang" , >Subject: RE: [IBIS-Users] IV Curves >Date: Sun, 9 Jan 2005 20:41:50 -0800 > >Think about reflections off an open transmission line for your answer. > >Tom Dagostino >Teraspeed Consulting Group LLC >503-430-1065 >tom@teraspeed.com >www.teraspeed.com > >-----Original Message----- >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On >Behalf Of lee yang >Sent: Sunday, January 09, 2005 5:58 PM >To: ibis-users@eda.org >Subject: [IBIS-Users] IV Curves > > >Hi IBIS experts: > >I have a few questions regarding IBIS data: >1) What is the reason of ground clamp and pulldown data is ground relative >while power clamp and pullup data is vcc relative? >2) The IV curves data is covered from -vcc to 2vcc, in what condition the >voltage would become -vcc? (eg1: output is driving vcc and the receiver end >is being shorted, the reflection coefficient is -1, then the maximum >negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v and >the >reciever end is being shorted, the reflection coefficient is -1 as well, >would it be any reflection if the output is driving 0V with reciever end >being shorted to ground?) >Hope you all could shed some light here. >Thanks. > >Yours Faithfully, >LY > >_________________________________________________________________ >Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ New >look and improved results. Give it a try! > >|------------------------------------------------------------------ >|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 _________________________________________________________________ Block pop-up ads with MSN Toolbar. http://toolbar.msn.com.my/ |------------------------------------------------------------------ |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, 10 Jan 2005 09:33:50 +0100 From: Antonio GIRARDI Subject: [IBIS-Users] RE: BIRD95: Power Integrity Analysis Using IBIS Dear Muranyi, I agree with you about the need to identify a solution for describing the "gate modulation effect" by legacy buffer modeling techniques. I think this solution will increase a lot the quality and accuracy of IBIS model simulations, expecially in the design of high-speed systems. About this issue, we have done internally a lot of benchmarking activities to evaluate the accuracy of IBIS SSO simulations vs SPICE ones, because it is a very critical bottleneck to perform accurate IBIS signal integrity analysis for system-in-packages design. To reduce the mismatching IBISvsSPICE, we have identified two mandatory steps: 1) to estimate the capacitances of the IC power nodes and back-annotate them to IBIS models. The capacitances considered are fullchip and include the total self and mutual capacitances between buffers (Vddq, Gndq) and core (Vdd, Gnd) power nodes, including also the equivalent capacitances of ESD structures and parassitic diodes connected to power nodes. This step permits to recover the correct behaviour of the power and ground nodes, but it doesn't solve the error due the "gate modulation effect" lack which impacts on the delay and ringing simulations accuracy. 2) to solve the "gate modulation effect" error. For this goal we have implemented the Vgs modulation description using the VHDL-AMS language, starting from the IBIS model template suggested by you. The results seem to be very interesting. Our approach has been based on extrapolating some tables which describe the current through pullup and pulldown for different values of Vgs, keeping the Vds values fixed. I think this approach might be implemented also by legacy buffer modeling techniques, but it has to be joined to a new IBIS simulation stategy in the EDA tools available on the market. I think the [Series Composite Current] keyword in the BIRD95 also presents this need. Best regards, Antonio Girardi > Muranyi, Arpad wrote: > >> Mike (and Syed), >> >> Nice comments! Your main concern raises a question in my mind >> regarding on-die power delivery (passive) networks. This subject >> has popped up here and there in discussions, but so far no one >> has raised it as an issue so clearly and as importantly as you >> and Norio Matsui. >> >> Up until now we have considered a buffer having a single point >> Power and GND connection (unless it was using different supply >> voltages for clamps). Except for some groupings done by the good >> old [Pin Mapping] keyword, these supplies were all shorted together >> with all power and GND pads. >> >> It seems that if these concerns you and Norio are raising are >> driven by a common need, we would also need to consider how >> power is distributed between the buffers and their sub-blocks. >> >> However, if one of the primary purpose of doing BIRD95 is >> to make better SSN simulations possible (including the power >> delivery networks), we would also need to consider the >> so-called "gate modulation effect" for which I have heard >> a lot a IBIS criticism since the mid 90's. (This effect >> is the one that reduces the drive strength of the output >> stage due to the supply voltage reduction which arises with >> power delivery noise). If we don't account for that, no >> matter how well we know how the currents are distributed >> between power GND and the output, they are still going to >> be wrong... >> >> Now, adding more than 4 supply nodes to a buffer is not possible >> with [Model] or [External Model], only with [External Circuit]. >> This implies that describing predriver currents independently >> could only be done with models using the new language extensions. >> To me it seems that Syed's proposal is an attempt to provide an >> interim solution using the legacy buffer modeling techniques. >> The level of detail you and Norio brought up could only be >> addressed by the new generation of models which will be written >> with those languages. I hope that by then we will also figure >> out how to use ICM with IBIS to describe the on-die passive >> interconnects to make it all work together. >> >> However, the gate modulation effect could still be described >> relatively well within the legacy IBIS framework with a few simple >> parameters. For an example we could look at how HSPICE's B-element >> does it with the "spu_scal" and "spd_scal" parameters. These were >> implemented on our request to do just that, but there are no IBIS >> keywords or subparameters to transfer these coefficients in an >> IBIS file. I wonder whether we should include these features >> in BIRD95? >> >> Regarding #4, current should be positive into the power node, >> into the I/O node, but OUT OF the GND node. >> >> Regarding #6, very good point, but it all depends on whether the >> diff pair is just two independent single ended buffers driven in the >> opposite directions, or a true (current source + current steering >> transistors) construction. Legacy IBIS can't do the second one, >> period. So how would someone translate a measurement done on a >> true diff buffer to a model that can only do two single ended >> buffers driven in opposite directions? I am not saying that this >> is impossible, but I don't see an immediate solution, and I didn't >> spend time on thinking about it yet. >> >> There is another issue that I ran into recently in connection with >> differential buffers when they are designed with bipolar transistors. >> It is a pain taking IV curves of these, because due to the nature of >> the bipolar output transistors the two outputs are much less >> independent as in the case with MOSFET outputs. (The nature of >> bipolar transistors is such that the output voltage will have >> a great effect of the bias levels of the predrivers, and thereby >> other half of the output). I don't know what we can or should do >> with these animals in an IBIS I-V curve sense. This is not >> necessarily a BIRD95 problem, but since you brought up your >> question, I had to mention it. >> >> Regarding #7, I feel these tables should be under subparameters >> inside the [xxx Waveform] keywords. That way there would be >> no confusions. (I hope). >> >> Arpad >> ================================================================== >> >> -----Original Message----- >> From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of >> Mike LaBonte >> Sent: Wednesday, December 29, 2004 8:34 AM >> To: ibis@eda.org; 'ibis-users' >> Subject: RE: [IBIS] Re: [IBIS-Users] BIRD95: Power Integrity Analysis >> Using IBIS >> >> BIRD95 reminds us of the difficulties associated with the current >> profile >> issue, but hopefully this time we can work it through to a >> conclusion. My >> comments: >> >> 1) Norio Matsui may have raised the most important issue, the fact that >> there may not be exactly one bypass capacitor and one pre-driver section >> associated with one buffer, all sharing current from one supply. In fact >> this case seems quite unlikely. Scaling the total bypass capacitance, >> pre-driver current and output current for an arbitrary slice of a >> component >> down to one of it's buffers should a model that is likely not very >> accurate >> for any single buffer, or for any collection of buffers unless the >> collection happens to be equal to those in the slice. And a single >> current >> profile still doesn't solve the correct apportionment of current to >> paths >> from distinct power supply voltages. >> >> 2) Accepting for the moment that we are attempting to represent multiple >> current paths with a single table here, why not specify ground current >> instead of power current? Isn't it more likely that all of these >> currents >> flow through a single ground plane than through a single power plane? >> >> 3) Although the IBIS specification limits itself with regard to >> explaining >> how a simulator might use the data, I feel that some effort might be >> warranted here to advance the cause of consistency among simulators. For >> starters, should we have some words of wisdom explaining that the >> current >> out of the pad can be determined, and represents the difference >> between the >> current into the power supply (if there is only one) and out through >> ground >> (if there is only one). Digging deeper, how will the simulator decide >> how >> much of the current passing through ground is "crowbarred" through the >> pullup and pulldown, versus passing through the other current path >> formed by >> the bypass capacitors and pre-drivers? This has a bearing on the >> turn-on/off >> rates chosen for the pullup/pulldown. Mainly I would like to see some >> discussion of this from simulator people, to validate that the >> simulation >> outcome is deterministic. Even if there has been discussion already >> within >> the IBIS committee, it would be good to make a record in the IBIS >> specification for future implementers. >> >> 4) I think the text should clarify that positive values represent >> current >> flowing into the buffer. >> >> 5) Although it may seem obvious, maybe the specification should >> clarify that >> in the case of open_XXX models, where current is supplied by the test >> fixture, that current is not to be accounted for in the [Series >> Composite >> Current]. >> >> 6) What would the [Series Composite Current] profile look like for a >> differential output buffer? Presumably these must be taken as a pair, >> and >> the total current for the pair ideally remains nearly static. Should we >> require the measurements to be taken this way, or should we allow model >> makers to provide separate P and N models with different current >> profiles? >> >> 7) The proposed [Series Composite Current] keyword associates itself >> with a >> preceding [XXX Waveform] keyword, and is thus position dependent. Some >> existing IBIS keywords are position dependent. For example, [Ramp] is >> part >> of a second level of hierarchy under [Model]. But I think [Series >> Composite >> Current] would be a third level of hierarchy, being under [XXX >> Waveform], >> which is under [Model]. Is this OK, or would it be better to simply >> add 3 >> more columns to the [XXX Waveform] tables? >> >> 8) Can the [Series Composite Current] keyword follow only some [XXX >> Waveform] tables and not others? >> >> 9) The text describes [Series Composite Current] as current flowing >> through >> R_VDD, but the circuit diagram calls it R_VDDQ. >> >> 10) More nit picking: I had to modify the ASCII circuit diagram to >> make it >> line up right. >> >> It's great to be discussing this important issue again. Overall I am >> left >> wondering if the various current paths can reasonably be merged into a >> single table. >> >> Mike LaBonte >> >> |------------------------------------------------------------------ >> |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, 10 Jan 2005 11:02:45 -0500 From: "Andrew Ingraham" Subject: [IBIS-Users] Re: Basic questions about IBIS Andrew, Gee, I was hoping some others would chime in here by now. Oh well. > About 3, > A. So, chips are usually not made according to SPICE file; > On the contrary, SPICE files are extracted from chip and guess. Essentially yes, but early SPICE files can also be created before a chip is designed, based on the schematic for the chip, and on the designer's expectations. You can make SPICE files from either a schematic design, or an actual chip layout. When someone is designing a chip, they can make SPICE files that represent how they hope the chip will behave, before there is any silicon or even a layout. If it is a new IC process too, then you could say the entire SPICE model including its .MODEL parameters includes some guess, since even the process has not been proven yet. After the chip is made, they can also make SPICE files that represent the final, actual chip layout. Not everyone goes through both steps. In any event, a good IC designer *should* always adjust their final SPICE models (whether they came from schematics or from the layout) according to how the chip actually behaves. Usually not the other way around. It is easier to make a SPICE model fit actual silicon behavior, than the other way around. If the chip doesn't behave the way he wanted it to, he may go back and tweak the chip design somewhat, but in the end, he ought to adjust the SPICE model according to how the chip truly behaves. > Thus, SPICE-derived IBIS model and encrypted SPICE > model are not as accurate as measurement-based IBIS model. (except some > situation) SPICE models, whether encrypted or not, could be just as accurate as any IBIS model. (Encryption has nothing to do with it.) On basic principles, a SPICE-derived IBIS model could be less accurate than a measurement-based IBIS model, because it is one more level removed from reality. Each level, or translation from one form to another, incurs additional errors. Reality is the chip itself. A SPICE model that has been correlated to agree with measurements, is one level away from reality. An IBIS model from measurements, is also one level away from reality. An IBIS model created from the SPICE model, is two levels away from reality, so there CAN be a greater chance of it not agreeing with reality. But it's not a guarantee. A SPICE model that has never been correlated with measurements, should be treated with suspicion, and an IBIS model derived from it is almost surely less accurate than one made from measurements. But on the other hand, anyone can create a lousy IBIS file from measurements. If someone hands you a chip and a SPICE model, and asks you to make an IBIS model, you may not know who created the SPICE model and whether it is accurate. There are many bad SPICE models out there too. Making a SPICE- derived IBIS model could just perpetuate a lie that was in the SPICE model, that the designer never bothered to correct. Making a measurement-based IBIS model can at least be traced to the chip's actual electrical behavior. > B. So, the extremes of SPICE-derived model are only > expectations. ... I'm not in the IC process business so I don't "know the real scoop" here ... but as far as process extremes is concerned, I believe that the following are true: (1) IC manufacturers set statistical limits on their IC process, beyond which there is some statistical confidence that no (defect-free) parts will be made. Some SPICE model extremes are based on these statistical expectations. IC vendors can also make test chips that are meant to represent the process extremes, which they do by intentionally varying some key factor(s) in the chip-making process. Because they require special changes to the IC process, they aren't cheap. In theory they can use these test chips to verify SPICE model extremes. (2) IC manufacturers put test limits into their automatic test equipment, used to test and screen every part manufactured, and this tends to set the limits on the extremes of characteristics of the parts they sell. (Except for black-market (reject) parts that sometimes find their way onto the market!) Because the ATE tests may or may not directly test the parameters of interest, sometimes they are indirect. > C. If everything is optimized, how long will it usually > take to generate a IBIS3.2 model of one I/O buffer? Gee, I don't know ... I'm going to guess no more than a day? (Maybe two; one to measure, one to massage the data.) Assuming of course that the people doing it were really set up beforehand and didn't need to do any more research or fixturing, and that the package modeling is simple. > About 4, > A. I would like to know whether the influence from fab process > is smaller than the influence from temperature and voltage or not. This is probably a moving target, and it's been a while since I looked at this, but I recall that the fab process was dominant. Today they may have tighter controls on process variations, which might have reversed that. They can also design temperature and voltage compensated buffers that remove some of those dependencies on (say) buffer speed. > B. For most IBIS model, the typical temperature is room > temperature, however, for some chips (ex: CPU), the temperature is much > higher than room temperature. > Is it reasonable to ask chip vendors to change the > typical temperature. That's a really good thing to discuss with whoever makes your IBIS models. It's one of the things I don't particularly like about models that include environmental effects. No chip runs at room temperature. > 5. In IBIS, the "max" curves are measured / simulated under the condition > "maximum buffer strength + lowest temperature + largest voltage" > and the "min" curves are measured / simulated under the condition > "minimum buffer strength + highest temperature + smallest voltage". > I think it is not sufficient to simulate the ringback: as I know the > ringing caused by maximum buffer strength is much larger the minimum > buffer strength, but "smallest voltage - VIH" is smaller than "largest > voltage - VIH", we cannot make sure whether the ringback margin is > sufficient even if the simulation results of min and max passed. (Because > the smallest ringback margin should be under the condition "maximum buffer > strength + lowest temperature + smallest voltage") I think this question deals more with the particular simulation strategy (and the simulator) you use. You could simulate using a "max" model for the driver and a "min" model for the receiver, if your simulator allows you to do this. (Unless, of course, you are talking about a bi-directional transceiver monitoring its own output.) Personally, I prefer to decide what input thresholds *I* want to use, so in SPICE I look for the worst-case input thresholds, plus a small margin, and I ignore what the IBIS model may say. I hoped someone else would comment on that question. > 6. Chip vendors usually set the largest and smallest voltage according to > their maximum tolerance (for example 20%), however, the voltage error rate > of our regulator is usually not so large. So the worst cases in IBIS > model are not the same with the worst cases in our PCBA. Furthermore, > sometimes the typical voltage we use is not the same with the original. I > would like to know whether there is a method to generate the IBIS model we > need. I don't know. Except that you could have someone create custom IBIS models for your particular needs. You have cited many of the reasons why I prefer to use SPICE models rather than IBIS models! In recent years I have been rather disappointed to see so many IBIS models *replace* SPICE models in terms of their availability. To me, nothing beats a good SPICE model. A good SPICE model does what you want it to. An IBIS model doesn't. But it keeps the lawyers happy. :-( 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: Mon, 10 Jan 2005 08:43:20 -0800 From: "lgreen" Subject: RE: [IBIS-Users] IV Curves Hello, Lee, Please see answers inserted. - - Lynne - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of lee yang Sent: Sunday, January 09, 2005 5:58 PM To: ibis-users@eda.org Subject: [IBIS-Users] IV Curves Hi IBIS experts: I have a few questions regarding IBIS data: 1) What is the reason of ground clamp and pulldown data is ground relative while power clamp and pullup data is vcc relative? - -- This was an arbitrary decision made in the IBIS 1.0 specification. Note that GND-and Pulldown tables currents shift relative to ground (and currents usually go through 0A at GND), while Power- and Pullup tables shift when Vcc changes (and currents usually go through 0A at Vcc). 2) The IV curves data is covered from -vcc to 2vcc, in what condition the voltage would become -vcc? (eg1: output is driving vcc and the receiver end is being shorted, the reflection coefficient is -1, then the maximum negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v and the reciever end is being shorted, the reflection coefficient is -1 as well, would it be any reflection if the output is driving 0V with reciever end being shorted to ground?) - -- A load with a small capacitance has a reflection coefficient close to +1. For an open circuit termination, the reflection coefficient is +1. A rising waveform into an "open circuit" load can cause 2*Vcc at the driver, and a falling reflection (starting at Vcc) can cause -Vcc at the driver. Hope you all could shed some light here. Thanks. Yours Faithfully, LY _________________________________________________________________ Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ New look and improved results. Give it a try! |------------------------------------------------------------------ |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, 10 Jan 2005 08:32:45 -0800 From: "Tom Dagostino" Subject: RE: [IBIS-Users] IV Curves If you have a 3.3V step going from 3.3 to 0V and it hits an open transmission line it will reflect back to -3.3V. Tom Dagostino Teraspeed Consulting Group LLC 503-430-1065 tom@teraspeed.com www.teraspeed.com - -----Original Message----- From: lee yang [mailto:changly_80@hotmail.com] Sent: Sunday, January 09, 2005 11:11 PM To: tom@teraspeed.com; ibis-users@eda.org Subject: RE: [IBIS-Users] IV Curves Hi Tom, Thanks for your responce... However, i couldn't get you clearly. If the transmission line is being opened, the reflection coefficient is 1, how could it become -vcc? Appreciate if you could explain it in more details. Could someone please help with my 2 questions below? Thanks and much appreciated. - -LY >From: "Tom Dagostino" >Reply-To: >To: "lee yang" , >Subject: RE: [IBIS-Users] IV Curves >Date: Sun, 9 Jan 2005 20:41:50 -0800 > >Think about reflections off an open transmission line for your answer. > >Tom Dagostino >Teraspeed Consulting Group LLC >503-430-1065 >tom@teraspeed.com >www.teraspeed.com > >-----Original Message----- >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On >Behalf Of lee yang >Sent: Sunday, January 09, 2005 5:58 PM >To: ibis-users@eda.org >Subject: [IBIS-Users] IV Curves > > >Hi IBIS experts: > >I have a few questions regarding IBIS data: >1) What is the reason of ground clamp and pulldown data is ground relative >while power clamp and pullup data is vcc relative? >2) The IV curves data is covered from -vcc to 2vcc, in what condition the >voltage would become -vcc? (eg1: output is driving vcc and the receiver end >is being shorted, the reflection coefficient is -1, then the maximum >negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v and >the >reciever end is being shorted, the reflection coefficient is -1 as well, >would it be any reflection if the output is driving 0V with reciever end >being shorted to ground?) >Hope you all could shed some light here. >Thanks. > >Yours Faithfully, >LY > >_________________________________________________________________ >Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ New >look and improved results. Give it a try! > >|------------------------------------------------------------------ >|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 _________________________________________________________________ Block pop-up ads with MSN Toolbar. http://toolbar.msn.com.my/ |------------------------------------------------------------------ |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, 10 Jan 2005 08:58:27 -0800 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] IV Curves Just a couple of refinements to the answers I have seen so far. 1) Actually none of the IV curves are GND relative any more, this is just a terminology that is left over from the first version of the IBIS specification. Note that all four IV curves now have an associated [*** Reference] keyword, which defines the voltage for the origin of the IV curve. Therefore a pulldown IV curve for an RS232 driver could be referenced to -12 V, for example, which is not GND relative by any means... It is true, in most cases we reference the pulldown and GND clamp IV curves to 0 V, so it is easy to forget about this capability. 2) Lynne said it right, but I would like to add, that even if you have a perfect open at the end of the T-line, the 2Vcc or -Vcc doubling will only happen if your driver is superconductive, i.e. very low impedance. This is because the T-line voltage doubling doubles the incident step, which is determined by the voltage division based on the T-line impedance, and the driver impedance. So the 2Vcc and -Vcc voltages are kind of an absolute maximum condition which will most likely never happen. Arpad Muranyi Intel Coproation ==================================================================== - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of lgreen Sent: Monday, January 10, 2005 8:43 AM To: 'lee yang'; ibis-users@eda.org Subject: RE: [IBIS-Users] IV Curves Hello, Lee, Please see answers inserted. - - Lynne - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of lee yang Sent: Sunday, January 09, 2005 5:58 PM To: ibis-users@eda.org Subject: [IBIS-Users] IV Curves Hi IBIS experts: I have a few questions regarding IBIS data: 1) What is the reason of ground clamp and pulldown data is ground relative while power clamp and pullup data is vcc relative? - -- This was an arbitrary decision made in the IBIS 1.0 specification. Note that GND-and Pulldown tables currents shift relative to ground (and currents usually go through 0A at GND), while Power- and Pullup tables shift when Vcc changes (and currents usually go through 0A at Vcc). 2) The IV curves data is covered from -vcc to 2vcc, in what condition the voltage would become -vcc? (eg1: output is driving vcc and the receiver end is being shorted, the reflection coefficient is -1, then the maximum negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v and the reciever end is being shorted, the reflection coefficient is -1 as well, would it be any reflection if the output is driving 0V with reciever end being shorted to ground?) - -- A load with a small capacitance has a reflection coefficient close to +1. For an open circuit termination, the reflection coefficient is +1. A rising waveform into an "open circuit" load can cause 2*Vcc at the driver, and a falling reflection (starting at Vcc) can cause -Vcc at the driver. Hope you all could shed some light here. Thanks. Yours Faithfully, LY _________________________________________________________________ Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ New look and improved results. Give it a try! |------------------------------------------------------------------ |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: Mon, 10 Jan 2005 12:50:17 -0500 From: "Zanella, Fabrizio" Subject: RE: [IBIS-Users] General question on IBIS and SSO simulations Good question, Ray. I hope we can begin a good discussion on utilizing today's IBIS models to model SSO noise. My answer is yes, it will be very useful if I can get full parasitic information of power and ground nets in packages. Regards, Fabrizio Zanella Signal Integrity Enterasys Networks Andover, MA Phone: 978-684-1340 fzanella@enterasys.com - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Ray Anderson Sent: Friday, January 07, 2005 3:51 PM To: ibis-users@eda.org Subject: [IBIS-Users] General question on IBIS and SSO simulations After working on Power Distribution issues at the PCB level for quite a number of years I'm now tasked with upgrading our company's IBIS models with respect to package parasitic modeling. As an aid in coming up to speed on some of the issues involved I have a general question in regards to utilizing IBIS models to simulate SSO noise issues. I've reviewed a number of the presentations and papers on the IBIS website from past Summits and other sources and have come away with a mixed message regarding the usefulness of IBIS in modeling SSO. I am trying to determine if it will be useful to our customers if we provide full parasitic information for the power and ground nets in our parts. Can that RLC information effectively be utilized in IBIS simulations to produce useful results? From what I've read, some authors contend that IBIS models are adequate to model SSO problems if proper package parasitic data and on chip capacitance data is provided while it seems that some others tend to question whether it can be done today with the present state of IBIS. Any comments and/or advice on the topic will be most welcome. Raymond Anderson Senior Signal Integrity Staff Engineer Xilinx Inc. |------------------------------------------------------------------ |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, 10 Jan 2005 10:04:37 -0800 From: "Sam Chitwood" Subject: [IBIS-Users] BIRD95 modeling suggestion This is a multi-part message in MIME format. - ------=_NextPart_000_0169_01C4F6FB.CB0BF840 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi everyone, =20 From Friday's conf call, it seems that there will be a number of issues surrounding BIRD95. I would like to draw attention to one issue with = the suggested model. The schematic includes resistances and partial = inductances for power and ground. There are a few issues with this methodology. = First, there is no mutual inductance between the two - this is required for the partials to be meaningful. Then, what physical location is selected for = the measurement of VDDQ's current such that the inductances and resistance = are accurately modeled in the extraction? =20 =20 Do we expect the IBIS model builders to include a distributed PDS = network in their extractions? The schematic shows L and R going into the devices = as a whole, but there is no PDS model shown between the on-die cap, the pre-driver, nor the final driver. I suspect this will be the typical simulation setup, where all components are directly connected to the = same power and ground nodes, without a distributed on-die PDS model. =20 I recommend that we remove the resistances and partial inductances from = the schematic. This will further enforce the concept that the IBIS device = is a "black box" - the actual, physical location of the power and ground connections are then clearly defined. Their connections to the rest of = the system are then unambiguous, and interconnect modeling remains in the = final simulator's domain. =20 I've included the schematic below for reference. Best regards, =20 Sam =20 =20 |------------------------------------------------------------------------= - -- (**) | = | <--- | ___________________________________________________________|___VDDQ | | | | | | = | | | | | | | = | | ----- | | | | = | | | E | | / | | = | | | S | ---------------- \ P_| --- PowerClamp = | | | R | | Pre-Driver | / || / \ = | | ----- | Circuit | \ ||__ --- = | | | | powered by | | | | = | | | | VDDQ | | | | | I_sig = | | ----- ---------------- | | | | -------> = | | | E | | o-----o--|----o------------------- I/O | | S | | | | | | = | | | | L | | | | / | | | = | |I_bypass| ----- I_pre| |I_term| \ N_| v --- GNDClamp = | | | | | | | / || I_cb / \ = | | v | v | v \ ||_ --- = | | ----- | | | | = | | ----- C_p+b | | | | = | | |___________________|_________|_____|_______|_______________|____GND | = | | = | |------------------------------------------------------------------------= - -| =20 =20 =20 =20 - ------=_NextPart_000_0169_01C4F6FB.CB0BF840 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi everyone,

From Friday’s conf call, it seems that there will be a number of issues surrounding BIRD95. I would like to draw attention to one issue with the = suggested model. The schematic includes resistances and partial inductances = for power and ground. There are a few issues with this = methodology. First, there is no mutual inductance between the two – this is = required for the partials to be meaningful. Then, what physical location is = selected for the measurement of VDDQ’s current such that the inductances = and resistance are accurately modeled in the extraction? =

Do we expect the IBIS model builders to include a distributed PDS network in their extractions? The schematic shows = L and R going into the devices as a whole, but there is no PDS model shown = between the on-die cap, the pre-driver, nor the final driver. I suspect this = will be the typical simulation setup, where all components are directly = connected to the same power and ground nodes, without a distributed on-die PDS model.

I recommend that we remove the resistances and = partial inductances from the schematic. This will further enforce the = concept that the IBIS device is a “black box” – the actual, = physical location of the power and ground connections are then clearly = defined. Their connections to the rest of the system are then unambiguous, and interconnect modeling remains in the final simulator’s = domain.

I’ve included the schematic below for = reference. Best regards,

Sam

|---------------------------------------------------=
- ----------------------- =
  (**)

|       &nb=
sp;           &nbs=
p;            =
;            =
        =
        =
            &=
nbsp;|   <---

|   =
           _______=
____________________________________________________|___VDDQ

|       &nb=
sp;     =
|            =
       =
|         =
|     |       |         &nb=
sp;     | =

|       &nb=
sp;     =
|            =
       =
|         =
|     |       |         &nb=
sp;     | =

|       &nb=
sp;   -----    =
            &=
nbsp;|         =
|     |       =
|           &nb=
sp;   | =

| =
          | E =
|            =
     =
|         =
/     |       | =
            &=
nbsp; | =

|      =
     | S =
|        ----------------   =
\   P_|      --- PowerClamp   | =

|       &nb=
sp;   | R |        |  =
Pre-Driver  |   / =
||         / \ =
            &=
nbsp;| =

|       &nb=
sp;   -----        | =
  Circuit    |   \ =
||__       --- =
            &=
nbsp;| =

|       &nb=
sp;     =
|          |  powered =
by  |   |     =
|       | =
            &=
nbsp; | =

|       &nb=
sp;     =
|          =
|     VDDQ     |   =
|     |  |    |   =
I_sig =
      | =

|       &nb=
sp;   -----        =
- ----------------   |     |  =
|    |   ------->    | =

|       &nb=
sp;   | E |      =
           | =
        =
o-----o--|----o------------------- =
I/O

|       &nb=
sp;   | S =
|            =
     =
|         =
|     |  |    | =
            &=
nbsp; | =

| =
       |  | L =
|            =
|    |      |  =
/     |  |    | =
            &=
nbsp; | =

|I_bypass|  =
- -----       I_pre|    =
|I_term|  \   N_|  v   --- GNDClamp     | =

|        =
|    =
|            =
  |    |      |  =
/  ||   I_cb / \ =
            &=
nbsp;| =

|       =
 v    =
|            =
  v    |      v  =
\  ||_       --- =
            &=
nbsp;| =

|       =
    -----       &n=
bsp;         =
|         =
|     |       =
|           &nb=
sp;   | =

|       =
    ----- =
C_p+b           =
|         =
|     |       =
|   =
            |=

|       =
      |___________________|_________|_____|=
_______|_______________|____GND|       &nb=
sp;           &nbs=
p;            =
;            =
            &=
nbsp;    =
            |=
   
|       &nb=
sp;           &nbs=
p;            =
;            =
            &=
nbsp;            &nb=
sp;   | =
  
|---------------------------------------------------=
- ----------------------|

- ------=_NextPart_000_0169_01C4F6FB.CB0BF840-- |------------------------------------------------------------------ |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, 10 Jan 2005 12:01:39 -0800 From: "Zhiping Yang" Subject: Re: [IBIS-Users] Re: [IBIS] RE: BIRD95: Power Integrity Analysis Using IBIS Hi Arpad, Thanks for your comments. Please see my replies in your e-mail. Thanks. Best regards, Zhiping - ----- Original Message ----- From: "Muranyi, Arpad" To: ; "ibis-users" Sent: Wednesday, January 05, 2005 4:03 PM Subject: RE: [IBIS-Users] Re: [IBIS] RE: BIRD95: Power Integrity Analysis Using IBIS > Zhiping, > > I would like to comment on your paragraph on the gate modulation > effect. I think your statement "For the current IBIS, the power > is assumed to be perfect" is not entirely true. Think about the > "Vcc relative" IV curves and the package modeling, for example. > The origin of each IV curve is associated with a corresponding > [XYZ Reference] keyword. Using appropriate package parasitics and > [Pin Mapping], these reference voltages are allowed to bounce as > the buffers are switching. So the power of the buffers do not > have to be perfect in the IBIS world. Yes. I understood that some EDA tools could let IBIS to simulate the SSO, but my concern is that their results may not be correct. Besides the "gate modulation effect" which we talked about, my personal understanding is that even the SSO noice can be simulated with exisiting IBIS model, but the noise coupling mechanism from power to signal pin may not be implemented or not implemented correctly. In another word, could the power noise impact on the rising/falling edge in IBIS simulation match to the HSPICE simulation? I could be wrong and I am working on some simulations in HSPICE to verify it. > > It is a different story that the strength of the buffer is not > modulated in most IBIS simulators based on the bouncing rail > voltages. But this capability would not be very difficult to > add. We could get started by just adding two parameters to > the IBIS specification which would have the same meaning that > I mentioned before in the HSPICE B-element. I just read the HSPICE manual on these two parameters (spu_scal and spd_scal) you mentioned. I didn't see any detailed explainations on how to use them. Do you have any examples to show their impact on the IBIS performance? Personally I feel it may improve the IBIS performance, but it still can not completely solve the "gate modulation effects" in IBIS. > > The first thing to decide is whether these should be part of > BIRD95. If yes, we can continue on this thread and discuss > how it should be defined. If not, we can start another thread > and BIRD to do it separately. Any takers to write it up? > > Arpad > ================================================================= > > -----Original Message----- > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Zhiping Yang > Sent: Wednesday, January 05, 2005 3:30 PM > To: Roy Leventhal; twesterh@cisco.com; ibis@eda.org; 'ibis-users' > Subject: [IBIS-Users] Re: [IBIS] RE: BIRD95: Power Integrity Analysis Using IBIS > > Hi Roy, > > Very well said about the IBIS model. > > For current BIRD95, our intention was not to completely solving the power > integrity problem in one proposal. As a first step to improve the IBIS > model capability and accuracy in SSO simulation, we proposed to add IvsT > information of the I/O power pin into existing IBIS model. We think this > IvsT table will provide enough info on Xbar current, Pre-driver current from > VDDQ, internal termination current and embedded decoupling current within > I/O cell which are neglected in current IBIS model. We really not expect > IBIS model with added IvsT info could complete replace the SPICE model in > SSO simulation, but we do think it can greatly reduce the simulation > accuracy gap between the SPICE model and IBIS model. > > About the "gate modulation effect" Arpad and Todd mentioned, I think it is > more like a problem which can be correctly addressed by EDA tool vendor. > Certainly in order to correctly solve this problem in IBIS, the IBIS model > should provide enough information for the EDA tool vendor to use them. For > the current IBIS, the power is assumed to be perfect, so there is no correct > way to consider this effect in the EDA tool. With the introduction of > BIRD95, EDA tool vendors could think how to simulate power noise due to I/O > switching (as a first step, the mutual impact between the I/O network and > power network may not be able to fully considered). I think it is > relatively easily to implement the impact of I/O noise to the power network, > but it is relatively hard to implement the impact of power noise to the I/O > network by using IBIS model. I may be wrong. There are a lot of smart > people in the EDA industry and they may be able to figure out how to > implement it correctly (or closer to the SPICE model). > > Best regards, > > Zhiping > > ----------------------------------------------------------------- > |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 |------------------------------------------------------------------ |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, 10 Jan 2005 12:40:11 -0800 From: "Muranyi, Arpad" Subject: [IBIS-Users] RE: BIRD95: Power Integrity Analysis Using IBIS Zhiping, I will just quote your latest response to reduce the size of this thread. You raise a good concern. There is room for a lot of improvements to get IBIS to reproduce the same PD simulation results as an equivalent SPICE model. However, there are a lot of features in the existing capabilities of IBIS to improve the accuracy of IBIS models for SSO simulations, and many of these are still not utilized in many cases. You mentioned power to signal coupling, and I would add power to GND coupling. Not too many people realize that the primary reason for the additional C_comp parameters in the 4.0 specification was exactly for this reason (C_comp_pullup, C_comp_pulldown, C_comp_power_clamp, C_comp_gnd_clamp). The single C_comp concept didn't allow for describing such coupling. Another detail that is not realized many times is that if the total C_comp is split into two parts, one between the I/O pad and Vcc and the other between the I/O pad and GND, these two capacitors will automatically introduce a Vcc to GND coupling too! In addition, if this was not enough to model the total decoupling between Vcc and GND, one can always add more to it using the already existing series keywords, which can also be connected between power and GND pins. This solution is not the most elegant, since it uses a separate [Model] of type Series, but either way, it can be done. Regarding the HSPICE manual, if you can get a hold of manuals of earlier versions (sorry, but I can't remember exactly which one has it), you may find a little more on this. The problem is that the writer of the manual didn't seem to understand what this does and the equations are wrong, that is probably why it was taken out... Anyway, what it does is this: The actual voltage between power and GND is compared against the value which is in the IBIS file either in [Voltage Range], or the difference between the PU and PD reference keywords. If the instantaneous voltage is different from the nominal value, the IV curve will be scaled according to the pu_scal or pd_scal values. If the "scal" value is 1, the IV curve is scaled by the same proportion the supply voltage changed. In other words, a 10% change in the supply voltage will change the IV curve by 10% also. If the "scal" value is 0, there will be no change in the IV curves. If it was 0.5, then a 10% change in the supply voltage will result in a 5% change in the IV curves, etc... (The value of "scal" is not restricted to be between 0-1). I hope that the Synopsys lawyers are not going to chase after me for publishing this... It is in their advantage anyway if people know how to use this feature, right? We all know that due to the second order nature of MOSFETs this linear relationship is not exact. However, this scaling is not designed to go all the way down to 0 volts. In the range of the relatively small modulation this linear approximation seem to be sufficient. However, if it turns out that it is not, we can always improve on it by changing the equations to be more precise. Arpad - ---------------------------------------------------------------------------- - ---------------------------------------------------------------------------- - -----Original Message----- From: Zhiping Yang [mailto:zhiping@cisco.com] Sent: Monday, January 10, 2005 12:02 PM To: Muranyi, Arpad; ibis@eda.org; ibis-users Subject: Re: [IBIS-Users] Re: [IBIS] RE: BIRD95: Power Integrity Analysis Using IBIS ... Yes. I understood that some EDA tools could let IBIS to simulate the SSO, but my concern is that their results may not be correct. Besides the "gate modulation effect" which we talked about, my personal understanding is that even the SSO noice can be simulated with exisiting IBIS model, but the noise coupling mechanism from power to signal pin may not be implemented or not implemented correctly. In another word, could the power noise impact on the rising/falling edge in IBIS simulation match to the HSPICE simulation? I could be wrong and I am working on some simulations in HSPICE to verify it. ... I just read the HSPICE manual on these two parameters (spu_scal and spd_scal) you mentioned. I didn't see any detailed explainations on how to use them. Do you have any examples to show their impact on the IBIS performance? Personally I feel it may improve the IBIS performance, but it still can not completely solve the "gate modulation effects" in 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 ------------------------------ Date: Mon, 10 Jan 2005 16:04:32 -0800 From: Syed Huq Subject: [IBIS-Users] Final call for Presentation and participation - DesignCon2005 IBIS summit - ----------------------------------------------------------------------- IBIS SUMMIT FINAL CALL FOR PARTICIPATION & PRESENTATIONS - ----------------------------------------------------------------------- I B I S S U M M I T M E E T I N G Time/Date: Monday January 31st, 2005 8:00 AM to 5 PM Location: Santa Clara Convention Center Santa Clara, CA Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: DesignCon If your company would be interested in sponsoring this event, please contact Syed Huq . Benefits to sponsors include formal recognition at the meeting and acknowledgement in the Calls for Papers and meeting minutes. Your financial support strengthens the organization by allowing IBIS to focus resources on industry activities rather than raising money, and you will receive generous thanks for your support. DesignCon Conference January 31- February 3rd, 2005 Santa Clara Convention Center Santa Clara, CA Exhibit registration is Free if you register before December 15, 2004. Come and visit IBIS Booth 940. See http://www.designcon.com/ for more information. Conference Catalog: http://www.eda.org/pub/ibis/summits/jan05/DC05_Catalog.pdf BACKGROUND DesignCon is the premier annual Silicon Valley event for the electronic design automation (EDA) and semiconductor industry. Topics of current interest to the EIA IBIS Open Forum are addressed at DesignCon. This meeting will be conducted as a formal IBIS Summit Meeting. Presentations are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate in the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to: Syed Huq CALL FOR PRESENTATIONS We are seeking presentations from individuals who have experiences of interest to the IBIS modeling community. In the past, these have included demonstrations of modeling techniques, explanations of behavioral algorithms and descriptions of difficulties encountered in specific applications. Of particular interest are topics related to model correlation, modeling building experiences and comparisons to other modeling methods. Presentations may be addressed to any and all levels of IBIS experience, from beginning to advanced. Format of Presentation: LCD Projection with Windows laptop. Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. Electronic presentations should be made available by January 24, 2005 for uploading and copying to the presentation laptop. Presentors are responsible for bringing 50 copies if not received by January 24. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimated Time: Send this to: Syed Huq AGENDA The agenda includes presentations, discussions, breaks, and a luncheon (which will be provided if you are registered with DesignCon). This will be developed as presentation proposals are received. |------------------------------------------------------------------ |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, 11 Jan 2005 12:22:03 +0800 From: "Andrew_Chien\(???\)" Subject: RE: [IBIS-Users] Re: Basic questions about IBIS Dear Mr. Ingraham, I'm deeply appreciative of your kindly help. Really thank you for so many detail informations about IBIS model, chip process, and measurement. I also expected some chip vendors could give me some comments, but it seems that they are not interested in these questions. About 4&6, since our tool can use encrypted SPICE model, I think I should do my best to convince our vendors to provide correlated encrypted SPICE model. About 5, it's strange that in IBIS4.1 Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, Vth, Vth_min and Vth_max are all defined for 'typ' condition. But I can modify the model to fit min & max condition. Thanks and Best regards Andrew - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Andrew Ingraham Sent: Tuesday, January 11, 2005 12:03 AM To: ibis@eda.org; ibis-users@eda.org Subject: [IBIS-Users] Re: Basic questions about IBIS Andrew, Gee, I was hoping some others would chime in here by now. Oh well. > About 3, > A. So, chips are usually not made according to SPICE file; > On the contrary, SPICE files are extracted from chip and guess. Essentially yes, but early SPICE files can also be created before a chip is designed, based on the schematic for the chip, and on the designer's expectations. You can make SPICE files from either a schematic design, or an actual chip layout. When someone is designing a chip, they can make SPICE files that represent how they hope the chip will behave, before there is any silicon or even a layout. If it is a new IC process too, then you could say the entire SPICE model including its .MODEL parameters includes some guess, since even the process has not been proven yet. After the chip is made, they can also make SPICE files that represent the final, actual chip layout. Not everyone goes through both steps. In any event, a good IC designer *should* always adjust their final SPICE models (whether they came from schematics or from the layout) according to how the chip actually behaves. Usually not the other way around. It is easier to make a SPICE model fit actual silicon behavior, than the other way around. If the chip doesn't behave the way he wanted it to, he may go back and tweak the chip design somewhat, but in the end, he ought to adjust the SPICE model according to how the chip truly behaves. > Thus, SPICE-derived IBIS model and encrypted SPICE > model are not as accurate as measurement-based IBIS model. (except some > situation) SPICE models, whether encrypted or not, could be just as accurate as any IBIS model. (Encryption has nothing to do with it.) On basic principles, a SPICE-derived IBIS model could be less accurate than a measurement-based IBIS model, because it is one more level removed from reality. Each level, or translation from one form to another, incurs additional errors. Reality is the chip itself. A SPICE model that has been correlated to agree with measurements, is one level away from reality. An IBIS model from measurements, is also one level away from reality. An IBIS model created from the SPICE model, is two levels away from reality, so there CAN be a greater chance of it not agreeing with reality. But it's not a guarantee. A SPICE model that has never been correlated with measurements, should be treated with suspicion, and an IBIS model derived from it is almost surely less accurate than one made from measurements. But on the other hand, anyone can create a lousy IBIS file from measurements. If someone hands you a chip and a SPICE model, and asks you to make an IBIS model, you may not know who created the SPICE model and whether it is accurate. There are many bad SPICE models out there too. Making a SPICE- derived IBIS model could just perpetuate a lie that was in the SPICE model, that the designer never bothered to correct. Making a measurement-based IBIS model can at least be traced to the chip's actual electrical behavior. > B. So, the extremes of SPICE-derived model are only > expectations. ... I'm not in the IC process business so I don't "know the real scoop" here ... but as far as process extremes is concerned, I believe that the following are true: (1) IC manufacturers set statistical limits on their IC process, beyond which there is some statistical confidence that no (defect-free) parts will be made. Some SPICE model extremes are based on these statistical expectations. IC vendors can also make test chips that are meant to represent the process extremes, which they do by intentionally varying some key factor(s) in the chip-making process. Because they require special changes to the IC process, they aren't cheap. In theory they can use these test chips to verify SPICE model extremes. (2) IC manufacturers put test limits into their automatic test equipment, used to test and screen every part manufactured, and this tends to set the limits on the extremes of characteristics of the parts they sell. (Except for black-market (reject) parts that sometimes find their way onto the market!) Because the ATE tests may or may not directly test the parameters of interest, sometimes they are indirect. > C. If everything is optimized, how long will it usually > take to generate a IBIS3.2 model of one I/O buffer? Gee, I don't know ... I'm going to guess no more than a day? (Maybe two; one to measure, one to massage the data.) Assuming of course that the people doing it were really set up beforehand and didn't need to do any more research or fixturing, and that the package modeling is simple. > About 4, > A. I would like to know whether the influence from fab process > is smaller than the influence from temperature and voltage or not. This is probably a moving target, and it's been a while since I looked at this, but I recall that the fab process was dominant. Today they may have tighter controls on process variations, which might have reversed that. They can also design temperature and voltage compensated buffers that remove some of those dependencies on (say) buffer speed. > B. For most IBIS model, the typical temperature is room > temperature, however, for some chips (ex: CPU), the temperature is much > higher than room temperature. > Is it reasonable to ask chip vendors to change the > typical temperature. That's a really good thing to discuss with whoever makes your IBIS models. It's one of the things I don't particularly like about models that include environmental effects. No chip runs at room temperature. > 5. In IBIS, the "max" curves are measured / simulated under the condition > "maximum buffer strength + lowest temperature + largest voltage" > and the "min" curves are measured / simulated under the condition > "minimum buffer strength + highest temperature + smallest voltage". > I think it is not sufficient to simulate the ringback: as I know the > ringing caused by maximum buffer strength is much larger the minimum > buffer strength, but "smallest voltage - VIH" is smaller than "largest > voltage - VIH", we cannot make sure whether the ringback margin is > sufficient even if the simulation results of min and max passed. (Because > the smallest ringback margin should be under the condition "maximum buffer > strength + lowest temperature + smallest voltage") I think this question deals more with the particular simulation strategy (and the simulator) you use. You could simulate using a "max" model for the driver and a "min" model for the receiver, if your simulator allows you to do this. (Unless, of course, you are talking about a bi-directional transceiver monitoring its own output.) Personally, I prefer to decide what input thresholds *I* want to use, so in SPICE I look for the worst-case input thresholds, plus a small margin, and I ignore what the IBIS model may say. I hoped someone else would comment on that question. > 6. Chip vendors usually set the largest and smallest voltage according to > their maximum tolerance (for example 20%), however, the voltage error rate > of our regulator is usually not so large. So the worst cases in IBIS > model are not the same with the worst cases in our PCBA. Furthermore, > sometimes the typical voltage we use is not the same with the original. I > would like to know whether there is a method to generate the IBIS model we > need. I don't know. Except that you could have someone create custom IBIS models for your particular needs. You have cited many of the reasons why I prefer to use SPICE models rather than IBIS models! In recent years I have been rather disappointed to see so many IBIS models *replace* SPICE models in terms of their availability. To me, nothing beats a good SPICE model. A good SPICE model does what you want it to. An IBIS model doesn't. But it keeps the lawyers happy. :-( 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 CONFIDENTIALITY NOTE : The information in this e-mail is confidential and privileged; it is intended for use solely by the individual or entity named as the recipient hereof. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient is strictly prohibited and may violate applicable laws. If you have received this e-mail in error, please delete the original message and notify us by return email or collect call immediately. Thank you. High Tech Computer Corporation |------------------------------------------------------------------ |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, 12 Jan 2005 01:08:15 +0000 From: "lee yang" Subject: RE: [IBIS-Users] IV Curves Hi all, Thanks for the answers, i appreciate them very much. I am sorry to say that i am poor in SI, i couldn't get how the reflection for an open circuit transmission with coefficient=1 cause the voltage at driver site become -vcc (the reflection is the multiplication of voltage (vcc) and coefficient (+1) which end up with +vcc)? I am sorry but could someone shed some light to get rid of my confusion? Much appreciated. - -Lee >From: "Muranyi, Arpad" >To: >Subject: RE: [IBIS-Users] IV Curves >Date: Mon, 10 Jan 2005 08:58:27 -0800 > >Just a couple of refinements to the answers I have seen >so far. > >1) Actually none of the IV curves are GND relative any more, >this is just a terminology that is left over from the first >version of the IBIS specification. > >Note that all four IV curves now have an associated [*** Reference] >keyword, which defines the voltage for the origin of the IV curve. >Therefore a pulldown IV curve for an RS232 driver could be referenced >to -12 V, for example, which is not GND relative by any means... >It is true, in most cases we reference the pulldown and GND clamp IV >curves to 0 V, so it is easy to forget about this capability. > >2) Lynne said it right, but I would like to add, that even if you >have a perfect open at the end of the T-line, the 2Vcc or -Vcc >doubling will only happen if your driver is superconductive, >i.e. very low impedance. This is because the T-line voltage >doubling doubles the incident step, which is determined by the >voltage division based on the T-line impedance, and the driver >impedance. So the 2Vcc and -Vcc voltages are kind of an absolute >maximum condition which will most likely never happen. > >Arpad Muranyi >Intel Coproation >==================================================================== > > >-----Original Message----- >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf >Of lgreen >Sent: Monday, January 10, 2005 8:43 AM >To: 'lee yang'; ibis-users@eda.org >Subject: RE: [IBIS-Users] IV Curves > >Hello, Lee, >Please see answers inserted. >- Lynne > >-----Original Message----- >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf >Of lee yang >Sent: Sunday, January 09, 2005 5:58 PM >To: ibis-users@eda.org >Subject: [IBIS-Users] IV Curves > >Hi IBIS experts: > >I have a few questions regarding IBIS data: >1) What is the reason of ground clamp and pulldown data is ground relative >while power clamp and pullup data is vcc relative? >-- This was an arbitrary decision made in the IBIS 1.0 specification. >Note that GND-and Pulldown tables currents shift relative to ground >(and currents usually go through 0A at GND), while Power- and Pullup tables >shift when Vcc changes (and currents usually go through 0A at Vcc). > >2) The IV curves data is covered from -vcc to 2vcc, in what condition the >voltage would become -vcc? (eg1: output is driving vcc and the receiver end >is being shorted, the reflection coefficient is -1, then the maximum >negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v and >the > >reciever end is being shorted, the reflection coefficient is -1 as well, >would it be any reflection if the output is driving 0V with reciever end >being shorted to ground?) >-- A load with a small capacitance has a reflection coefficient close to >+1. >For an open circuit termination, the reflection coefficient is +1. >A rising waveform into an "open circuit" load can cause 2*Vcc at the >driver, >and a falling reflection (starting at Vcc) can cause -Vcc at the driver. > > >Hope you all could shed some light here. >Thanks. > >Yours Faithfully, >LY > >_________________________________________________________________ >Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ New >look and improved results. Give it a try! > >|------------------------------------------------------------------ >|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 _________________________________________________________________ Get your mobile ringtones, operator logos and picture messages from MSN Mobile http://msn.smsfactory.no/ |------------------------------------------------------------------ |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, 12 Jan 2005 08:52:17 -0700 From: rrwolff@micron.com Subject: RE: [IBIS-Users] IV Curves Lee, The reflection coefficient is a measure of mismatch between the impedance of the transmission line and the impedance of the load. It indicates how much energy reflects off the load back down the transmission line and with what phase shift. The reflection coefficient can vary from -1 to +1 and indicates a phase shift from 0 to 180 degrees. The equation for reflection coefficient (RC) is: RC=(Zl-Zo)/(Zl+Zo), where Zl is the impedance of the load and Zo is the impedance of the transmission line. Let's look at three cases where Zo is 50 ohms in each case. Case 1: The load is an open circuit, so Zl=infinity RC=(infinity-50)/(infinity+50) = 1 The reflected voltage (Vr) would be forward voltage (Vf)*RC = Vcc*1 = Vcc The load voltage (Vload) is Vf+Vr = Vcc+Vcc = 2*Vcc Case 2: The load is perfectly matched, so Zl=50 RC=(50-50)/(50+50) = 0 Vr = Vf*RC = Vcc*0 = 0 Vload = Vf+Vr = Vcc+0 = Vcc Case 3: The load is a short (very, very low impedance), so Zl=0 RC=(0-50)/(0+50) = -1 Vr = Vf*RC = Vcc*-1 = -Vcc Vload = Vf+Vr = Vcc+(-Vcc) = 0 You can see that in case 3, -Vcc is reflected towards the driver. I hope this helps. Randy Wolff Micron Technology - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of lee yang Sent: Tuesday, January 11, 2005 6:08 PM To: arpad.muranyi@intel.com; ibis-users@eda.org Subject: RE: [IBIS-Users] IV Curves Hi all, Thanks for the answers, i appreciate them very much. I am sorry to say that i am poor in SI, i couldn't get how the reflection for an open circuit transmission with coefficient=1 cause the voltage at driver site become -vcc (the reflection is the multiplication of voltage (vcc) and coefficient (+1) which end up with +vcc)? I am sorry but could someone shed some light to get rid of my confusion? Much appreciated. - -Lee >From: "Muranyi, Arpad" >To: >Subject: RE: [IBIS-Users] IV Curves >Date: Mon, 10 Jan 2005 08:58:27 -0800 > >Just a couple of refinements to the answers I have seen >so far. > >1) Actually none of the IV curves are GND relative any more, >this is just a terminology that is left over from the first >version of the IBIS specification. > >Note that all four IV curves now have an associated [*** Reference] >keyword, which defines the voltage for the origin of the IV curve. >Therefore a pulldown IV curve for an RS232 driver could be referenced >to -12 V, for example, which is not GND relative by any means... >It is true, in most cases we reference the pulldown and GND clamp IV >curves to 0 V, so it is easy to forget about this capability. > >2) Lynne said it right, but I would like to add, that even if you >have a perfect open at the end of the T-line, the 2Vcc or -Vcc >doubling will only happen if your driver is superconductive, >i.e. very low impedance. This is because the T-line voltage >doubling doubles the incident step, which is determined by the >voltage division based on the T-line impedance, and the driver >impedance. So the 2Vcc and -Vcc voltages are kind of an absolute >maximum condition which will most likely never happen. > >Arpad Muranyi >Intel Coproation >==================================================================== > > >-----Original Message----- >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf >Of lgreen >Sent: Monday, January 10, 2005 8:43 AM >To: 'lee yang'; ibis-users@eda.org >Subject: RE: [IBIS-Users] IV Curves > >Hello, Lee, >Please see answers inserted. >- Lynne > >-----Original Message----- >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf >Of lee yang >Sent: Sunday, January 09, 2005 5:58 PM >To: ibis-users@eda.org >Subject: [IBIS-Users] IV Curves > >Hi IBIS experts: > >I have a few questions regarding IBIS data: >1) What is the reason of ground clamp and pulldown data is ground relative >while power clamp and pullup data is vcc relative? >-- This was an arbitrary decision made in the IBIS 1.0 specification. >Note that GND-and Pulldown tables currents shift relative to ground >(and currents usually go through 0A at GND), while Power- and Pullup tables >shift when Vcc changes (and currents usually go through 0A at Vcc). > >2) The IV curves data is covered from -vcc to 2vcc, in what condition the >voltage would become -vcc? (eg1: output is driving vcc and the receiver end >is being shorted, the reflection coefficient is -1, then the maximum >negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v and >the > >reciever end is being shorted, the reflection coefficient is -1 as well, >would it be any reflection if the output is driving 0V with reciever end >being shorted to ground?) >-- A load with a small capacitance has a reflection coefficient close to >+1. >For an open circuit termination, the reflection coefficient is +1. >A rising waveform into an "open circuit" load can cause 2*Vcc at the >driver, >and a falling reflection (starting at Vcc) can cause -Vcc at the driver. > > >Hope you all could shed some light here. >Thanks. > >Yours Faithfully, >LY > >_________________________________________________________________ >Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ New >look and improved results. Give it a try! > >|------------------------------------------------------------------ >|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 _________________________________________________________________ Get your mobile ringtones, operator logos and picture messages from MSN Mobile http://msn.smsfactory.no/ |------------------------------------------------------------------ |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, 13 Jan 2005 00:01:37 +0000 From: "lee yang" Subject: RE: [IBIS-Users] IV Curves Hi Randy Wolff, Thanks a lot for your detail and useful explaination, i appreciate it very much. Now, i have a much better idea about the reflection. I have a further question: In case 3 below, although the reflected voltage is -vcc, the total voltage in driver site is 0V. Do you have any example that shows the voltage at driver site is at -vcc? (which is cover by IBIS voltage range.) Many thanks. Appreciated, Lee >From: rrwolff@micron.com >To: >CC: >Subject: RE: [IBIS-Users] IV Curves >Date: Wed, 12 Jan 2005 08:52:17 -0700 > >Lee, > >The reflection coefficient is a measure of mismatch between the >impedance of the transmission line and the impedance of the load. It >indicates how much energy reflects off the load back down the >transmission line and with what phase shift. The reflection coefficient >can vary from -1 to +1 and indicates a phase shift from 0 to 180 >degrees. > >The equation for reflection coefficient (RC) is: >RC=(Zl-Zo)/(Zl+Zo), where Zl is the impedance of the load and Zo is the >impedance of the transmission line. Let's look at three cases where Zo >is 50 ohms in each case. > >Case 1: The load is an open circuit, so Zl=infinity >RC=(infinity-50)/(infinity+50) = 1 >The reflected voltage (Vr) would be forward voltage (Vf)*RC = Vcc*1 = >Vcc >The load voltage (Vload) is Vf+Vr = Vcc+Vcc = 2*Vcc > >Case 2: The load is perfectly matched, so Zl=50 >RC=(50-50)/(50+50) = 0 >Vr = Vf*RC = Vcc*0 = 0 >Vload = Vf+Vr = Vcc+0 = Vcc > >Case 3: The load is a short (very, very low impedance), so Zl=0 >RC=(0-50)/(0+50) = -1 >Vr = Vf*RC = Vcc*-1 = -Vcc >Vload = Vf+Vr = Vcc+(-Vcc) = 0 > >You can see that in case 3, -Vcc is reflected towards the driver. I >hope this helps. > >Randy Wolff >Micron Technology > >-----Original Message----- >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On >Behalf Of lee yang >Sent: Tuesday, January 11, 2005 6:08 PM >To: arpad.muranyi@intel.com; ibis-users@eda.org >Subject: RE: [IBIS-Users] IV Curves > >Hi all, >Thanks for the answers, i appreciate them very much. >I am sorry to say that i am poor in SI, i couldn't get how the >reflection >for an open circuit transmission with coefficient=1 cause the voltage at > >driver site become -vcc (the reflection is the multiplication of voltage > >(vcc) and coefficient (+1) which end up with +vcc)? I am sorry but could > >someone shed some light to get rid of my confusion? >Much appreciated. > >-Lee > > >From: "Muranyi, Arpad" > >To: > >Subject: RE: [IBIS-Users] IV Curves > >Date: Mon, 10 Jan 2005 08:58:27 -0800 > > > >Just a couple of refinements to the answers I have seen > >so far. > > > >1) Actually none of the IV curves are GND relative any more, > >this is just a terminology that is left over from the first > >version of the IBIS specification. > > > >Note that all four IV curves now have an associated [*** Reference] > >keyword, which defines the voltage for the origin of the IV curve. > >Therefore a pulldown IV curve for an RS232 driver could be referenced > >to -12 V, for example, which is not GND relative by any means... > >It is true, in most cases we reference the pulldown and GND clamp IV > >curves to 0 V, so it is easy to forget about this capability. > > > >2) Lynne said it right, but I would like to add, that even if you > >have a perfect open at the end of the T-line, the 2Vcc or -Vcc > >doubling will only happen if your driver is superconductive, > >i.e. very low impedance. This is because the T-line voltage > >doubling doubles the incident step, which is determined by the > >voltage division based on the T-line impedance, and the driver > >impedance. So the 2Vcc and -Vcc voltages are kind of an absolute > >maximum condition which will most likely never happen. > > > >Arpad Muranyi > >Intel Coproation > >==================================================================== > > > > > >-----Original Message----- > >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On >Behalf > >Of lgreen > >Sent: Monday, January 10, 2005 8:43 AM > >To: 'lee yang'; ibis-users@eda.org > >Subject: RE: [IBIS-Users] IV Curves > > > >Hello, Lee, > >Please see answers inserted. > >- Lynne > > > >-----Original Message----- > >From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On >Behalf > >Of lee yang > >Sent: Sunday, January 09, 2005 5:58 PM > >To: ibis-users@eda.org > >Subject: [IBIS-Users] IV Curves > > > >Hi IBIS experts: > > > >I have a few questions regarding IBIS data: > >1) What is the reason of ground clamp and pulldown data is ground >relative > >while power clamp and pullup data is vcc relative? > >-- This was an arbitrary decision made in the IBIS 1.0 specification. > >Note that GND-and Pulldown tables currents shift relative to ground > >(and currents usually go through 0A at GND), while Power- and Pullup >tables > >shift when Vcc changes (and currents usually go through 0A at Vcc). > > > >2) The IV curves data is covered from -vcc to 2vcc, in what condition >the > >voltage would become -vcc? (eg1: output is driving vcc and the receiver >end > >is being shorted, the reflection coefficient is -1, then the maximum > >negative voltage is 0V (vcc + (-1*vcc)=0); eg2: output is driving 0v >and > >the > > > >reciever end is being shorted, the reflection coefficient is -1 as >well, > >would it be any reflection if the output is driving 0V with reciever >end > >being shorted to ground?) > >-- A load with a small capacitance has a reflection coefficient close >to > >+1. > >For an open circuit termination, the reflection coefficient is +1. > >A rising waveform into an "open circuit" load can cause 2*Vcc at the > >driver, > >and a falling reflection (starting at Vcc) can cause -Vcc at the >driver. > > > > > >Hope you all could shed some light here. > >Thanks. > > > >Yours Faithfully, > >LY > > > >_________________________________________________________________ > >Find answers fast with MSN Search BETA. http://beta.search.msn.com.my/ >New > >look and improved results. Give it a try! > > > >|------------------------------------------------------------------ > >|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 > >_________________________________________________________________ >Get your mobile ringtones, operator logos and picture messages from MSN >Mobile http://msn.smsfactory.no/ > >|------------------------------------------------------------------ >|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 > > _________________________________________________________________ Get an advanced look at the new version of MSN Messenger. http://messenger.msn.com.my/Beta/Default.aspx |------------------------------------------------------------------ |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, 12 Jan 2005 21:30:05 -0800 From: "lgreen" Subject: RE: [IBIS-Users] IV Curves Lee- Consider Randy's case 1, except switching from Vcc to 0V: The reflected voltage (Vr) would be forward voltage (Vf)*RC = -Vcc*1 = -Vcc The load voltage (Vload) is Vf+Vr = -Vcc+(0) = -Vcc You might consider checking out some of the excellent transmission line textbooks. The books by Dr. Johnson and by Eric Bogatin are also good. - - Lynne - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of lee yang Sent: Wednesday, January 12, 2005 4:02 PM To: rrwolff@micron.com Cc: ibis-users@eda.org Subject: RE: [IBIS-Users] IV Curves Hi Randy Wolff, Thanks a lot for your detail and useful explaination, i appreciate it very much. Now, i have a much better idea about the reflection. I have a further question: In case 3 below, although the reflected voltage is -vcc, the total voltage in driver site is 0V. Do you have any example that shows the voltage at driver site is at -vcc? (which is cover by IBIS voltage range.) Many thanks. Appreciated, Lee > |------------------------------------------------------------------ |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, 14 Jan 2005 16:12:31 +0530 From: "Vivek Kumar Sundriyal" Subject: [IBIS-Users] Problem with POWER_CLAMP data Hi , I am using s2ibis2 to generate the IBIS Models. I come across the following problem with the POWER_CLAMP curves. In the POWERCLAMP curves, for extreme voltage conditions, I get a very high current of about 49A( which is wrong). Now if i closely observe the pct1.spi, i find that the sweep has been set in the following manner : .DC VOUTS2I 3.3 5.1 0.1 But in the IBIS file, the POWER CLAMP data has been generated from -1.8V to 0.0V. And the current at -1.8V is 49A. What can be the problem ? Is it the behaviour of the buffer or is it a bug with s2ibis2 ? How can i get out from this problem ? The SPICE engine that i use is HSPICE. Thanks , 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: Fri, 14 Jan 2005 17:42:25 +0530 From: "Vivek Kumar Sundriyal" Subject: [IBIS-Users] Query on Pullup/Pulldown Hi , Working on s2ibis2, i find put1.spi and dut1.spi for the generation of the pullup data. Can anyone explain why do we need two sets of files for the pull up data ? How does s2ibis2 extrapolate/interpolate these values into the final .ibs file ? Thanks, 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: Fri, 14 Jan 2005 10:30:43 -0500 From: "Andrew Ingraham" Subject: Re: [IBIS-Users] Problem with POWER_CLAMP data Vivek, There is no problem, except maybe that your SPICE models are unrealistic when stressed this far. The real device probably can't sink 49 amps, but your SPICE model says that it does. This is not an uncommon problem with SPICE models, many of which forget to include diode series resistance. Thus you get extremely steep curves with huge currents in forward conduction, in the SPICE model. There is nothing wrong with the fact that the POWER CLAMP goes from 0V to -1.8V. Remember, the POWER CLAMP table is VDD-relative, and if VDD is 3.3V, then 3.3V at the device pin corresponds to 0V in the IBIS table, and 5.1V at the device pin corresponds to -1.8V in the IBIS table. Is the 49A value a problem if left alone? Maybe, or maybe not. If the SPICE model was OK, then so is the IBIS model; that is, the IBIS model is no worse than the SPICE model. It is at the extreme far end of the clamp curve, well away from normal operation, and it is unlikely that the simulator will converge on a voltage near that point. That large a current value helps push the simulator back into the more normal operating region where the currents are less. This will happen with both the SPICE model and the IBIS model. If you don't like the 49A, you should fix the SPICE model. Regards, Andy > In the POWERCLAMP curves, for extreme voltage conditions, I get a very > high current of about 49A( which is wrong). Now if i closely observe the > pct1.spi, i find that the sweep has been set in the following manner : > > .DC VOUTS2I 3.3 5.1 0.1 > > But in the IBIS file, the POWER CLAMP data has been generated from -1.8V > to 0.0V. And the current at -1.8V is 49A. > > What can be the problem ? Is it the behaviour of the buffer or is it a bug > with s2ibis2 ? How can i get out from this problem ? |------------------------------------------------------------------ |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, 14 Jan 2005 11:49:13 -0500 From: "Ambrish Varma" Subject: RE: [IBIS-Users] Query on Pullup/Pulldown Hello Vivek, put1.spi is the setup file for the entire driver whereas dut1.spi is the file with the driver disabled (to get the clamp current). The pullup current you see in the model is the difference of the 2 currents to give the performance of only the driver. We then take only a few points from the linear part of the curve and a majority of points from the 'interesting' part of the curve. That's a 100 feet view of how things are done in s2ibis2. Hope that helps, Ambrish. Ambrish K Varma akvarma@ncsu.edu North Carolina State University ph(919)513-2015, fax(919)515-2285 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Vivek Kumar Sundriyal Sent: Friday, January 14, 2005 7:12 AM To: ibis-users@eda.org; owner-ibis-users@eda.org Subject: [IBIS-Users] Query on Pullup/Pulldown Hi , Working on s2ibis2, i find put1.spi and dut1.spi for the generation of the pullup data. Can anyone explain why do we need two sets of files for the pull up data ? How does s2ibis2 extrapolate/interpolate these values into the final .ibs file ? Thanks, 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: Fri, 14 Jan 2005 09:07:04 -0800 From: Syed Huq Subject: Re: [IBIS-Users] Query on Pullup/Pulldown put1 - Pull-up Typical dut1 - Disabled Pull-up Typical Most likely this is a 3-state Model_type so it needs to capture the V/I tables while the output stages are "ON" and while they are "Tri-state'ed" etc.. If your Model_type is "Output" only, you will not see the duxx files. Syed - -- IBIS Vice-Chair & Webmaster Cisco Systems, Inc On Fri, 2005-01-14 at 04:12, Vivek Kumar Sundriyal wrote: > Hi , > > Working on s2ibis2, i find put1.spi and dut1.spi for the generation of the > pullup data. > > Can anyone explain why do we need two sets of files for the pull up data ? > > How does s2ibis2 extrapolate/interpolate these values into the final .ibs > file ? > > Thanks, > > 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: Fri, 14 Jan 2005 15:40:33 -0800 From: "Mirmak, Michael" Subject: [IBIS-Users] IIRD8.3: Distinct Model_pinmap and Model_nodemap Names This is a multi-part message in MIME format. - ------_=_NextPart_001_01C4FA92.711E10A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The enclosed revised IIRD, Distinct Model_pinmap and Model_nodemap Names, is posted on behalf of Bob Ross of Teraspeed Consulting Group. The document makes minor changes to an IIRD already scheduled for an approval vote at the January 28, 2005 IBIS Open Forum teleconference. - - Michael Mirmak Intel Corp. Chair, EIA IBIS Open Forum - ------_=_NextPart_001_01C4FA92.711E10A0 Content-Type: text/plain; name="IIRD8.3.txt" Content-Transfer-Encoding: base64 Content-Description: IIRD8.3.txt Content-Disposition: attachment; filename="IIRD8.3.txt" ICAgICAgICAgICAgICAgIElDTSBJc3N1ZSBSZXNvbHV0aW9uIERvY3VtZW50ICAoSUlSRCkNCg0K SUlSRCBJRCM6ICAgICAgICA4LjMNCklTU1VFIFRJVExFOiAgICAgRGlzdGluY3QgTW9kZWxfcGlu bWFwIGFuZCBNb2RlbF9ub2RlbWFwIE5hbWVzDQpSRVFVRVNUT1I6ICAgICAgIEJvYiBSb3NzLCBU ZXJhc3BlZWQgQ29uc3VsdGluZyBHcm91cA0KREFURSBTVUJNSVRURUQ6ICBTZXB0ZW1iZXIgMjIs IDIwMDQNCkRBVEUgUkVWSVNFRDogICAgTm92ZW1iZXIgMjEsIDIwMDQsIERlY2VtYmVyIDI0LCAy MDA0LCBKYW51YXJ5IDEzLCAyMDA1DQpEQVRFIEFDQ0VQVEVEIEJZIElCSVMgT1BFTiBGT1JVTTog UEVORElORw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNClNU QVRFTUVOVCBPRiBUSEUgSVNTVUU6DQoNCk1vZGVsX3Bpbm1hcCBhbmQgTW9kZWxfbm9kZW1hcCBu YW1lcyB1bmRlciBbVHJlZSBQYXRoIERlc2NyaXB0aW9uXSBhbmQNCltOb2RhbCBQYXRoIERlc2Ny aXB0aW9uXSBuZWVkIHRvIGJlIGRpc3RpbmN0IHRvIGFsbG93IGludGVyZmFjaW5nIHdpdGggSUJJ Uw0Kb3Igb3RoZXIgdHlwZXMgb2YgY29ubmVjdGlvbnMuICBJZiB0aGUgbmFtZXMgYXJlIHJldXNl ZCwgdGhlbiBhIG1ldGhvZA0KaXMgbmVlZGVkIGZvciBFREEgdG9vbHMgdG8gaWRlbnRpZnkgdGhl IHNwZWNpZmljIG5hbWUgZm9yIGNvbm5lY3Rpb25zLg0KDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoN ClNUQVRFTUVOVCBPRiBUSEUgUkVTT0xWRUQgU1BFQ0lGSUNBVElPTlM6DQoNClN0YXRlbWVudHMg YXJlIGFkZGVkIHRoYXQgdGhlIE1vZGVsX3Bpbm1hcCBhbmQgTW9kZWxfbm9kZW1hcCBuYW1lcyBt dXN0DQplaXRoZXIgYmUgZGlzdGluY3Qgb3IgZWxzZSBkaWZmZXJlbnRpYXRlZCBieSBhIG5ldyBz dWJwYXJhbWV0ZXIgIlNpZGUiDQp1bmRlciBbVHJlZSBQYXRoIERlc2NyaXB0aW9uXSBhbmQgW05v ZGFsIFBhdGggRGVzY3JpcHRpb25dLg0KDQpDaGFuZ2UgaW5zdHJ1Y3Rpb24gbGluZXMgYXJlIGlk ZW50aWZpZWQgYnkgfCoqDQpDaGFuZ2VzIGFyZSBpZGVudGlmaWVkIGJ5IHwqLCB8KioqLCB8Kioq KiBsaW5lcy4NClNvbWUgdW5jaGFuZ2VkIHBvcnRpb25zIGFyZSBvbWl0dGVkLg0KDQoNCnwqKiBN T0RJRlkgVEhFIFRSRUUgRElBR1JBTSBJTiBUSEUgUE9SVElPTiBCRUxPVw0KDQoNCnwtLS8tLVtC ZWdpbiBJQ00gRmFtaWx5XSAgICAgICAgICAgICAgICAgIHwgKHNlZSBDaGFwdGVyIDcpDQp8ICB8 ICB8LS1bTWFudWZhY3R1cmVyXQ0KfCAgfCAgfC0tW0lDTSBGYW1pbHkgRGVzY3JpcHRpb25dDQp8 ICB8ICB8LS1bSUNNIE1vZGVsIExpc3RdIA0KfCAgfCAgDQp8ICB8LS0vLS1bQmVnaW4gSUNNIE1v ZGVsXQ0KfCAgfCAgfCAgfCAgSUNNX21vZGVsX3R5cGUNCnwgIHwgIHwgIHwgIFNHUg0KfCAgfCAg fCAgfCAgUmVmX2ltcGVkYW5jZQ0KfCAgfCAgfCAgfC0tW0lDTSBNb2RlbCBEZXNjcmlwdGlvbl0N CnwgIHwgIHwgIHwtLVtUcmVlIFBhdGggRGVzY3JpcHRpb25dDQp8ICB8ICB8ICB8ICAgICBNb2Rl bF9waW5tYXANCg0KfCoqIEFkZCB0aGlzIGxpbmUNCnwgIHwgIHwgIHwgICAgIFNpZGUNCnwqKiBF bmQgb2YgYWRkaXRpb24NCg0KfCAgfCAgfCAgfCAgICAgRm9yaywgRW5kZm9yaw0KfCAgfCAgfCAg fCAgICAgU2VjdGlvbg0KfCAgfCAgfCAgfC0tW05vZGFsIFBhdGggRGVzY3JpcHRpb25dDQp8ICB8 ICB8ICB8ICAgICBNb2RlbF9ub2RlbWFwDQoNCnwqKiBBZGQgdGhpcyBsaW5lDQp8ICB8ICB8ICB8 ICAgICBTaWRlDQp8KiogRW5kIG9mIGFkZGl0aW9uDQoNCnwgIHwgIHwgIHwgICAgIE5fc2VjdGlv bg0KfCAgfCAgfCAgfC0tW0lDTSBTd2F0aCBQYXJhbWV0ZXJzXSAgICAgICAgfCAob3B0aW9uYWws IGZvciBzd2F0aHMpDQp8ICB8ICB8ICB8ICAgICBMZWZ0X2VkZ2UNCnwgIHwgIHwgIHwgICAgIFJp Z2h0X2VkZ2UNCnwgIHwgIHwgIHwgICAgIFRvcF9lZGdlDQp8ICB8ICB8ICB8ICAgICBCb3R0b21f ZWRnZQ0KfCAgfCAgfCAgfC0tW0lDTSBTd2F0aCBQaW4gTnVtYmVyc10gICAgICAgfCAob3B0aW9u YWwsIGZvciBzd2F0aHMpDQp8ICB8ICBcLS1bRW5kIElDTSBNb2RlbF0NCnwgIHwNCnwgIHwtLVtJ Q00gUGluIE1hcF0gICAgICAgICAgICAgICAgICAgICAgIHwgUGlucyB0byBQaHlzaWNhbA0KfCAg fCAgICBQaW5fb3JkZXINCnwgIHwgICAgTnVtX29mX2NvbHVtbnMNCnwgIHwgICAgTnVtX29mX3Jv d3MNCnwgIHwgICAgUGluX2xpc3QNCnwgIHwtLVtJQ00gTm9kZSBNYXBdICAgICAgICAgICAgICAg ICAgICAgIHwgTm9kZXMgdG8gUGh5c2ljYWwNCnwgIFwtLVtFbmQgSUNNIEZhbWlseV0NCnwNCg0K DQp8KiogTUFLRSBDSEFOR0VTIFRPIFRIRSBbVHJlZSBQYXRoIERlc2NyaXB0aW9uXSBLRVlXT1JE IFNIT1dOIEJFTE9XOg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgICBLZXl3b3JkOiBbVHJl ZSBQYXRoIERlc2NyaXB0aW9uXQ0KICAgIFJlcXVpcmVkOiBZZXMsIGlmIFtOb2RhbCBQYXRoIERl c2NyaXB0aW9uXSBkb2VzIG5vdCBleGlzdA0KDQp8KiogRGVsZXRlIHRoaXMgbGluZQ0KICBTdWIt cGFyYW1zOiBNb2RlbF9waW5tYXAsIFNlY3Rpb24sIEZvcmssIEVuZGZvcmsNCnwqKiBBZGQgdGhp cyBsaW5lDQogIFN1Yi1wYXJhbXM6IE1vZGVsX3Bpbm1hcCwgU2lkZSwgU2VjdGlvbiwgRm9yaywg RW5kZm9yaw0KfCoqIEVuZCBvZiBhZGRpdGlvbg0KDQogICAgIFVzZWQgQnk6IFtCZWdpbiBJQ00g TW9kZWxdDQogICAgICAgIFVzZXM6IFtJQ00gUGluIE1hcF0NCiBEZXNjcmlwdGlvbjogVGhpcyBr ZXl3b3JkIGRlc2NyaWJlcyB0aGUgY29ubmVjdGlvbiBwYXRoIGJldHdlZW4gdGhlIHBpbiBvciAN CiAgICAgICAgICAgICAgcGlucyBvbiBvbmUgc2lkZSBvZiB0aGUgaW50ZXJjb25uZWN0IGFuZCB0 aGUgY29ycmVzcG9uZGluZyBzZXQNCiAgICAgICAgICAgICAgb2YgcGlucyBvbiB0aGUgb3RoZXIg c2lkZS4gIFRoaXMgcGluIHRvIHBpbiBpbnRlcmNvbm5lY3QgaXMNCiAgICAgICAgICAgICAgZGl2 aWRlZCBpbnRvIG9uZSBvciBtb3JlICJzZWN0aW9ucyIsIHdoZXJlIGVhY2ggc2VjdGlvbiBjb25z aXN0cyANCiAgICAgICAgICAgICAgb2YgUkxHQyBkYXRhLiAgU2VjdGlvbnMgYXJlIGdlbmVyYWxs eSBjYXNjYWRlZCBpbiBzZXJpZXMsIGJ1dCAgIA0KICAgICAgICAgICAgICB0aGUgRm9yayBhbmQg RW5kZm9yayBzdWJwYXJhbWV0ZXJzIGFsbG93IHNlY3Rpb25zIHRvIGJyYW5jaCBvZmYgDQogICAg ICAgICAgICAgIHRoZSBtYWluIGludGVyY29ubmVjdCBwYXRoIGFzIGEgc3R1YiBvciB0ZWUuDQpV c2FnZSBSdWxlczogIEEgW1RyZWUgUGF0aCBEZXNjcmlwdGlvbl0gaXMgdXNlZCB3aGVuIGFsbCBv ZiB0aGUgc2VjdGlvbnMgaW4gYQ0KICAgICAgICAgICAgICBnaXZlbiBpbnRlcmNvbm5lY3QgaGF2 ZSBvbmUtdG8tb25lIG1hcHBpbmcuICBJbiBvdGhlciB3b3JkcywgDQogICAgICAgICAgICAgIGVh Y2ggcGluIGlzIGVsZWN0cmljYWxseSBjb25uZWN0ZWQgdG8gYXQgbGVhc3Qgb25lIG90aGVyIHBp biBvZiANCiAgICAgICAgICAgICAgdGhlIGludGVyY29ubmVjdCB0aHJvdWdoIGEgY29uZHVjdG9y LiAgVG9wb2xvZ2llcyB3aGVyZSBwaHlzaWNhbCANCiAgICAgICAgICAgICAgY3Jvc3Npbmcgb2Yg b25lIGNvbmR1Y3RvciBvdmVyIG9yIHVuZGVyIGFub3RoZXIgb2NjdXJzIHNoYWxsIG5vdCANCiAg ICAgICAgICAgICAgYmUgZGVzY3JpYmVkIHVzaW5nIFtUcmVlIFBhdGggRGVzY3JpcHRpb25dLiAN Cg0KfCoqIFNldmVyYWwgcGFyYWdyYXBocyBhcmUgb21pdHRlZCAuLi4uLg0KDQoNCiAgICAgICAg ICAgICAgVGhlIFtUcmVlIFBhdGggRGVzY3JpcHRpb25dIGtleXdvcmQgbGluZSBpcyBmb2xsb3dl ZCBieSBhdCBsZWFzdCANCiAgICAgICAgICAgICAgb25lIE1vZGVsX3Bpbm1hcCBhbmQgb25lIFNl Y3Rpb24gc3VicGFyYW1ldGVycyB3aGljaCBkZXNjcmliZSANCiAgICAgICAgICAgICAgdGhlIHBp bi10by1jb25kdWN0b3IgbWFwcGluZywgYW5kIHRoZSB0b3BvbG9neSBvZiB0aGUgDQogICAgICAg ICAgICAgIGludGVyY29ubmVjdC4gIFRoZSBlbGVjdHJpY2FsIHByb3BlcnRpZXMgb2YgYW4gaW50 ZXJjb25uZWN0IA0KICAgICAgICAgICAgICBzZWN0aW9uIGFyZSBkZXNjcmliZWQgaW4gdGhlIG1h dHJpY2VzIHVuZGVyIHRoZSANCiAgICAgICAgICAgICAgW0JlZ2luIElDTSBTZWN0aW9uXSBrZXl3 b3JkIHdoaWNoIGFyZSByZWZlcmVuY2VkIGJ5IHRoZSBTZWN0aW9uIA0KICAgICAgICAgICAgICBz dWJwYXJhbWV0ZXIocyksIGRpc2N1c3NlZCBiZWxvdy4gIEJyYW5jaGVzIG9yICJUIiBjb25uZWN0 aW9ucyANCiAgICAgICAgICAgICAgYXJlIGluZGljYXRlZCBieSB0aGUgIkZvcmsiIGFuZCAiRW5k Zm9yayIgc3VicGFyYW1ldGVycy4gIFRyZWUNCiAgICAgICAgICAgICAgcGF0aCBkZXNjcmlwdGlv bnMgYXJlIHRlcm1pbmF0ZWQgd2l0aCBhIE1vZGVsX3Bpbm1hcCANCiAgICAgICAgICAgICAgc3Vi cGFyYW1ldGVyLg0KDQogICAgICAgICAgICAgIFRoZXNlIHN1YnBhcmFtZXRlcnMgYXJlIGRlc2Ny aWJlZCBpbiBkZXRhaWwgYmVsb3cuICANCg0KDQogICAgICAgICAgICAgIE1vZGVsX3Bpbm1hcA0K DQogICAgICAgICAgICAgIEEgcGF0aCBkZXNjcmlwdGlvbiBiZWdpbnMgd2l0aCB0aGUgcmVxdWly ZWQgc3VicGFyYW1ldGVyIA0KICAgICAgICAgICAgICBNb2RlbF9waW5tYXAuICBUaGlzIHN1YnBh cmFtZXRlciBpcyBmb2xsb3dlZCBieSB0aGUgbmFtZSBvZiBhIA0KICAgICAgICAgICAgICAicGlu IG1hcCIgd2hpY2ggbmFtZXMgdGhlIHBpbnMgb24gdGhhdCBlbmQgb2YgdGhlIGludGVyY29ubmVj dC4gIA0KICAgICAgICAgICAgICBBIHNlY29uZCBNb2RlbF9waW5tYXAgaXMgdXNlZCBhdCB0aGUg ZW5kIG9mIHRoZSBwYXRoIGRlc2NyaXB0aW9uIA0KICAgICAgICAgICAgICB0byByZWZlcmVuY2Ug dGhlIHBpbiBtYXAgdXNlZCBmb3IgdGhlIG90aGVyIGVuZCBvZiB0aGUgDQogICAgICAgICAgICAg IGludGVyY29ubmVjdC4gIFRoZSBNb2RlbF9waW5tYXAgc3VicGFyYW1ldGVyIGNhbiBhbHNvIGJl IHVzZWQgdG8gDQogICAgICAgICAgICAgIHJlZmVyZW5jZSBhIHBpbiBtYXAgZm9yIHRoZSBwaW5z IGF0IHRoZSBlbmQgb2YgYW55IEZvcmsuICBOb3RlIA0KICAgICAgICAgICAgICB0aGF0IHRoZSBw aW4gbWFwIG5hbWUgZ2l2ZW4gYXMgYW4gYXJndW1lbnQgdG8gYSBNb2RlbF9waW5tYXAgDQogICAg ICAgICAgICAgIHN1YnBhcmFtZXRlciBtdXN0IG1hdGNoIHRoZSBuYW1lIG9mIGEgcGluIG1hcCBk ZWZpbmVkIGJ5IGEgDQogICAgICAgICAgICAgIHN1YnNlcXVlbnQgW0lDTSBQaW4gTWFwXSBrZXl3 b3JkLg0KDQogICAgICAgICAgICAgIFRoZSBhcmd1bWVudCB0byB0aGUgTW9kZWxfcGlubWFwIHN1 YnBhcmFtZXRlciBhbmQgdGhlIHN1Yi0NCiAgICAgICAgICAgICAgcGFyYW1ldGVyIGl0c2VsZiBh cmUgc2VwYXJhdGVkIGJ5IHdoaXRlc3BhY2UuICBUaGVyZSBjYW4gYmUgYXMgDQogICAgICAgICAg ICAgIG1hbnkgTW9kZWxfcGlubWFwIHN1YnBhcmFtZXRlcnMgYXMgcmVxdWlyZWQsIGJ1dCBlYWNo IG11c3QgYmUgb24gDQogICAgICAgICAgICAgIGEgc2luZ2xlIGxpbmUuDQoNCnwqIERlbGV0ZSB0 aGlzIHBhcmFncmFwaDoNCg0KICAgICAgICAgICAgICBJbiBnZW5lcmFsLCBhbiBpbnRlcmNvbm5l Y3Qgd2lsbCBoYXZlIGEgc2luZ2xlIHBpbiBtYXAgdGhhdCBpcyANCiAgICAgICAgICAgICAgcmVm ZXJlbmNlZCBhdCB0aGUgYmVnaW5uaW5nIGFuZCBlbmQgb2YgYSBwYXRoIGRlc2NyaXB0aW9uLg0K DQp8KiogUmVwbGFjZSB3aXRoIHRoaXMgcGFyYWdyYXBoOg0KDQp8KioqKiAgICAgICAgIE9uZSBv ciBtb3JlIE1vZGVsX3Bpbm1hcCBsaW5lcyBjYW4gZXhpc3QsIGJ1dCBlYWNoIHBpbiBtYXANCnwq KioqICAgICAgICAgbmFtZSBtdXN0IGJlIHVuaXF1ZSBhbmQgcmVmZXJlbmNlIGEgZGlmZmVyZW50 IFtJQ00gUGluIE1hcF0NCnwqKioqICAgICAgICAgZGVzY3JpcHRpb24gZXZlbiBpZiB0aGUgY29u dGVudCBpcyBkZW50aWNhbC4gIEFsdGVybmF0aXZlbHksDQp8KioqKiAgICAgICAgIHRoZSBzYW1l IE1vZGVsX3Bpbm1hcCBtYXkgYmUgdXNlZCwgYnV0IHRoZSBzdWJwYXJhbWV0ZXIgU2lkZQ0KfCoq KiogICAgICAgICBkZXNjcmliZWQgYmVsb3cgbXVzdCBmb2xsb3cgbmV4dC4NCg0KfCoqIEVuZCBv ZiByZXBsYWNlbWVudCBwYXJhZ3JhcHRoDQoNCnwqKiBBZGQgbmV3IHN1Yi1zZWN0aW9uDQoNCiAg ICAgICAgICAgICAgU2lkZQ0KDQp8KioqKiAgICAgICAgIElmIGEgTW9kZWxfcGlubWFwIHBpbiBt YXAgbmFtZSBpcyByZXBlYXRlZCB3aXRoaW4gYQ0KICAgICAgICAgICAgICBbVHJlZSBQYXRoIERl c2NyaXB0aW9uXSBrZXl3b3JkLCB0aGUgU2lkZSBzdWJwYXJhbWV0ZXIgaXMNCiAgICAgICAgICAg ICAgcmVxdWlyZWQgYW5kIHBvc2l0aW9uZWQgYXMgdGhlIG5leHQgbGluZSB1bmRlciB0aGUgTW9k ZWxfcGlubWFwDQp8KioqKiAgICAgICAgIHN1YnBhcmFtZXRlci4gIFRoZSBTaWRlIHN1YnBhcmFt ZXRlciBpcyBmb2xsb3dlZCBhIHVuaXF1ZSBzaWRlDQp8KioqKioqICAgICAgIG5hbWUuICBUaGlz IHNpZGUgbmFtZSBpZGVudGlmaWVzIGEgc3BlY2lmaWMgcGluIG1hcCBjb25uZWN0aW9uDQp8Kioq KioqICAgICAgIGZyb20gc2V2ZXJhbCB3aXRoIHRoZSBzYW1lIG5hbWUuDQogICAgICAgICAgICAg IA0KICAgICAgICAgICAgICBUaGUgU2lkZSBzdWJwYXJhbWV0ZXIgaXMgcmVxdWlyZWQgZm9yIGFs bCBNb2RlbF9waW5tYXAgbGluZXMgd2l0aA0KICAgICAgICAgICAgICBpZGVudGljYWwgcGluIG1h cCBuYW1lcy4gIFRoZSBTaWRlIHN1YnBhcmFtZXRlciBpcyBvcHRpb25hbCB3aGVuDQogICAgICAg ICAgICAgIHRoZSBwaW4gbWFwIG5hbWUgaXMgdW5pcXVlLg0KDQp8KiogRW5kIG9mIHN1Yi1zZWN0 aW9uIGFkZGl0aW9uDQoNCg0KfCoqIE1PRElGWSBUSEUgRVhBTVBMRSBBUyBTSE9XTiBCRUxPVw0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIklDTSBNb2RlbCIgRXhhbXBsZXMgDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KRXhhbXBsZSAxOiBBIHNpbXBsZSBzaW5nbGUgbGluZSBtb2RlbCB3aXRoIG9u ZSBzZWN0aW9uDQoNCiAgICAgICAgU2VjdEENClBvcnQxID4tLS0tLS0tLTwgUG9ydDINCg0KW0Jl Z2luIElDTSBNb2RlbF0gTXlNb2RlbEV4YW1wbGUxDQpJQ01fbW9kZWxfdHlwZSBTTE1fZ2VuZXJh bA0KU0dSIDM6MQ0KUmVmX2ltcGVkYW5jZT01MA0KDQpbVHJlZSBQYXRoIERlc2NyaXB0aW9uXQ0K TW9kZWxfcGlubWFwICBFeGFtcGxlMV9waW5tYXANCg0KfCoqIEFkZCB0aGVzZSBsaW5lcw0KU2lk ZSBBICAgICAgICAgICB8IFRoZSBNb2RlbF9waW5tYXAgbmFtZSBpcyByZXVzZWQsIHNvIFNpZGUg YW5kIGEgdW5pcXVlDQogICAgICAgICAgICAgICAgIHwgc2lkZSBuYW1lIGlzIHJlcXVpcmVkDQp8 KiogRW5kIG9mIGFkZGl0aW9uDQoNCiAgU2VjdGlvbiBNdWx0PTEgRGlhZ29uYWxfbWF0cml4MQ0K TW9kZWxfcGlubWFwICBFeGFtcGxlMV9waW5tYXANCg0KfCoqIEFkZCB0aGVzZSBsaW5lcw0KU2lk ZSBCICAgICAgICAgICB8IFRoZSBNb2RlbF9waW5tYXAgbmFtZSBpcyByZXVzZWQsIHNvIFNpZGUg YW5kIGEgdW5pcXVlDQogICAgICAgICAgICAgICAgIHwgc2lkZSBuYW1lIGlzIHJlcXVpcmVkDQp8 KiogRW5kIG9mIGFkZGl0aW9uDQoNCiAgLg0KICAuDQogIC4NCltFbmQgSUNNIE1vZGVsXQ0KDQoN CnwqKiBSZW1haW5kZXIgb2YgdGhlIEV4YW1wbGUgaXMgb21pdHRlZCAuLi4NCg0KDQp8KiogTUFL RSBDSEFOR0VTIFRPIFRIRSBbTm9kYWwgUGF0aCBEZXNjcmlwdGlvbl0gS0VZV09SRCBTSE9XTiBC RUxPVzoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAgICAgS2V5d29yZDogW05vZGFsIFBhdGgg RGVzY3JpcHRpb25dDQogICAgUmVxdWlyZWQ6IFllcywgaWYgW1RyZWUgUGF0aCBEZXNjcmlwdGlv bl0gZG9lcyBub3QgZXhpc3QNCg0KfCoqIERlbGV0ZSB0aGlzIGxpbmUNCiAgU3ViLXBhcmFtczog Tl9zZWN0aW9uLCBNb2RlbF9ub2RlbWFwDQp8KiogQWRkIHRoaXMgbGluZQ0KICBTdWItcGFyYW1z OiBOX3NlY3Rpb24sIE1vZGVsX25vZGVtYXAsIFNpZGUNCnwqKiBFbmQgb2YgYWRkaXRpb24NCg0K ICAgICBVc2VkIEJ5OiBbQmVnaW4gSUNNIE1vZGVsXQ0KICAgICAgICBVc2VzOiBbSUNNIE5vZGUg TWFwXQ0KIERlc2NyaXB0aW9uOiBUaGlzIGtleXdvcmQgbWFya3MgdGhlIGJlZ2lubmluZyBvZiBh IG5vZGFsIHBhdGggZGVzY3JpcHRpb24uIA0KICAgICAgICAgICAgICBJdCBjb250YWlucyB0aGUg aW5mb3JtYXRpb24gb24gaG93IHR3byBvciBtb3JlIG5vZGVzIGFyZSANCiAgICAgICAgICAgICAg Y29ubmVjdGVkLiAgVGhlIG5vZGFsIGRlc2NyaXB0aW9uIHN0eWxlIGFsbG93cyBmb3IgYW55IGFy Yml0cmFyeSANCiAgICAgICAgICAgICAgdG9wb2xvZ2llcyB0byBiZSBkZXNjcmliZWQuDQoNCiAg ICAgICAgICAgICAgTm9kZXMgZGVmaW5lIHRoZSBjb25uZWN0aW9uIHBvaW50cyB3aGVyZSB0aGUg Y29uZHVjdG9ycyBvZiB0d28NCiAgICAgICAgICAgICAgb3IgbW9yZSBzZWN0aW9ucyBhcmUgam9p bmVkIHRvZ2V0aGVyLCBvciB3aGVyZSB0aGUgcGF0aCBpcw0KICAgICAgICAgICAgICBpbnRlcmZh Y2VkIHRvIHRoZSBvdXRzaWRlIHdvcmxkLiAgUGxlYXNlIG5vdGUgdGhhdCBzaW5nbGUNCiAgICAg ICAgICAgICAgY29ubmVjdGlvbnMgKGRhbmdsaW5nIGVuZHMpIGF0IG5vZGVzIGFyZSBhbHNvIHBl cm1pdHRlZC4gIFRodXMNCiAgICAgICAgICAgICAgbm9kZXMgY2FuIHJlcHJlc2VudCBhbnkgY29u bmVjdGlvbiBwb2ludHMsIGluY2x1ZGluZyBwaW5zIChvbg0KICAgICAgICAgICAgICBlaXRoZXIg c2lkZSBvZiBjb25uZWN0b3JzLCBwYWNrYWdlcywgb3Igc29ja2V0cyksIHBhZHMgYW5kDQogICAg ICAgICAgICAgIGJ1bXBzIG9mIGEgZGllICh3aGVyZSB0aGUgY29ubmVjdGlvbnMgdG8gdGhlIHBh Y2thZ2Ugb3IgcHJpbnRlZCANCiAgICAgICAgICAgICAgY2lyY3VpdCBib2FyZCBhcmUgbWFkZSks IG9yIHRoZSBlbmRzIG9mIGVpdGhlciBzaWRlIG9mIA0KICAgICAgICAgICAgICBpbnRlcmNvbm5l Y3Qgc2VjdGlvbnMgb2YgcHJpbnRlZCBjaXJjdWl0IGJvYXJkcy4NCg0KICAgICAgICAgICAgICBB biBpbnRlcmNvbm5lY3QgcGF0aCBtYXkgaGF2ZSBvbmUgb3IgbW9yZSBzZWN0aW9ucyB3aGVyZSBl YWNoDQogICAgICAgICAgICAgIHNlY3Rpb24gaXMgZGVzY3JpYmVkIGJ5IFJMR0Mgb3IgUy1wYXJh bWV0ZXIgbWF0cmljZXMuICBNdWx0aXBsZSANCiAgICAgICAgICAgICAgc2VjdGlvbnMgd2l0aGlu IGEgcGF0aCBkZXNjcmlwdGlvbiBtYXkgYmUgY29ubmVjdGVkIGluIGFueSANCiAgICAgICAgICAg ICAgYXJiaXRyYXJ5IG1hbm5lciBieSB1c2luZyB0aGUgdXN1YWwgbm9kZSBuYW1pbmcgdGVjaG5p cXVlcy4gIA0KICAgICAgICAgICAgICBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBzd2F0aCBmZWF0dXJl cyBjYW5ub3QgYmUgdXNlZCB3aXRoIHRoaXMgDQogICAgICAgICAgICAgIGtleXdvcmQuICBBbHNv IG5vdGUgdGhhdCB0aGUgdXNlIG9mIGJvdGggUkxHQyBhbmQgUy1wYXJhbWV0ZXIgDQogICAgICAg ICAgICAgIG1hdHJpeCBkYXRhIGZvciBzZWN0aW9ucyB3aXRoaW4gdGhlIHNhbWUgDQogICAgICAg ICAgICAgIFtOb2RhbCBQYXRoIERlc2NyaXB0aW9uXSBpcyBwcm9oaWJpdGVkLg0KIFVzYWdlIFJ1 bGVzOiBUaGUgW05vZGFsIFBhdGggRGVzY3JpcHRpb25dIGtleXdvcmQgbWF5IGFwcGVhciBtdWx0 aXBsZSB0aW1lcw0KICAgICAgICAgICAgICBpbiB0aGUgZmlsZSwgaG93ZXZlciBpdCBtYXkgYXBw ZWFyIG9ubHkgb25jZSBiZXR3ZWVuIGVhY2ggcGFpciANCiAgICAgICAgICAgICAgb2YgW0JlZ2lu IElDTSBNb2RlbF0vW0VuZCBJQ00gTW9kZWxdIGtleXdvcmRzLg0KDQp8KiogU2V2ZXJhbCBwYXJh Z3JhcGhzIGFyZSBvbWl0dGVkIC4uLi4uDQoNCg0KICAgICAgICAgICAgICBNb2RlbF9ub2RlbWFw DQoNCiAgICAgICAgICAgICAgVGhlIHJlcXVpcmVkIHN1YnBhcmFtZXRlciBNb2RlbF9ub2RlbWFw IGlzIHVzZWQgdG8gcmVmZXJlbmNlIHRoZSANCiAgICAgICAgICAgICAgW0lDTSBOb2RlIE1hcF0g a2V5d29yZCB3aGljaCBwcm92aWRlcyBhIG1hcHBpbmcgYmV0d2VlbiB0aGUgDQogICAgICAgICAg ICAgIGFjdHVhbCBkYXRhIGJvb2sgcGluIChvciBzaWduYWwpIG5hbWVzIGFuZCB0aGUgbm9kZSBu YW1lcyB1c2VkIA0KICAgICAgICAgICAgICBpbiB0aGUgcGF0aCBkZXNjcmlwdGlvbi4NCg0KICAg ICAgICAgICAgICBBIHBhdGggZGVzY3JpcHRpb24gbXVzdCBoYXZlIGF0IGxlYXN0IG9uZSBvY2N1 cnJlbmNlIG9mIHRoZQ0KICAgICAgICAgICAgICByZXF1aXJlZCBzdWJwYXJhbWV0ZXIgTW9kZWxf bm9kZW1hcCwgYnV0IGNhbiBoYXZlIGFzIG1hbnkNCiAgICAgICAgICAgICAgTW9kZWxfbm9kZW1h cCBzdWJwYXJhbWV0ZXJzIGFzIG5lZWRlZCB0byBhZGVxdWF0ZWx5IGRlc2NyaWJlDQogICAgICAg ICAgICAgIHRoZSBpbnRlcmNvbm5lY3QuICBUaGUgbnVtYmVyIG9mIE1vZGVsX25vZGVtYXAgc3Vi cGFyYW1ldGVycyAgDQogICAgICAgICAgICAgIHVzZWQgaW4gYSBwYXRoIGRlc2NyaXB0aW9uIHdv dWxkIGJlIHR5cGljYWxseSB0aGUgc2FtZSBhcyB0aGUNCiAgICAgICAgICAgICAgbnVtYmVyIG9m IGVuZHMgb3Igc2lkZXMgaW4gYSBjb25uZWN0b3Igb3IgaW50ZXJjb25uZWN0LiAgRWFjaA0KICAg ICAgICAgICAgICBNb2RlbF9ub2RlbWFwIHN1YnBhcmFtZXRlciBtdXN0IGJlIG9uIGEgc2luZ2xl IGxpbmUuDQoNCiAgICAgICAgICAgICAgVGhlIE1vZGVsX25vZGVtYXAgc3VicGFyYW1ldGVyIGlz IGZvbGxvd2VkIGJ5IG9uZSBhcmd1bWVudCwgIA0KICAgICAgICAgICAgICB3aGljaCB0aGUgbmFt ZSBvZiBhIG5vZGUgbWFwLiAgVGhlIGFyZ3VtZW50IG11c3QgbWF0Y2ggdGhlIG5hbWUgDQogICAg ICAgICAgICAgIG9mIGEgbm9kZSBtYXAgZGVmaW5lZCBieSBhIHN1YnNlcXVlbnQgW0lDTSBOb2Rl IE1hcF0ga2V5d29yZC4gIA0KICAgICAgICAgICAgICBUaGUgYXJndW1lbnQgYW5kIHRoZSBzdWJw YXJhbWV0ZXIgbXVzdCBiZSBzZXBhcmF0ZWQgYnkgYXQgbGVhc3QgDQogICAgICAgICAgICAgIG9u ZSB3aGl0ZSBzcGFjZS4NCg0KfCoqIEFkZCB0aGlzIHBhcmFncmFwaDoNCg0KfCoqKiogICAgICAg ICBPbmUgb3IgbW9yZSBNb2RlbF9ub2RlbWFwIGxpbmVzIGNhbiBleGlzdCwgYnV0IGVhY2ggbm9k ZSBtYXANCnwqKioqICAgICAgICAgbmFtZSBtdXN0IGJlIHVuaXF1ZSBhbmQgcmVmZXJlbmNlIGEg ZGlmZmVyZW50IFtJQ00gTm9kZSBNYXBdDQp8KioqKiAgICAgICAgIGRlc2NyaXB0aW9uIGV2ZW4g aWYgdGhlIGNvbnRlbnQgaXMgaWRlbnRpY2FsLiAgQWx0ZXJuYXRpdmVseSwNCnwqKioqICAgICAg ICAgdGhlIHNhbWUgTW9kZWxfbm9kZW1hcCBtYXkgYmUgdXNlZCwgYnV0IHRoZSBzdWJwYXJhbWV0 ZXIgU2lkZQ0KfCoqKiogICAgICAgICBkZXNjcmliZWQgYmVsb3cgbXVzdCBmb2xsb3cgbmV4dC4N Cg0KfCoqIEVuZCBvZiBhZGRlZCBwYXJhZ3JhcGgNCg0KDQp8KiogQWRkIG5ldyBzdWItc2VjdGlv bg0KDQogICAgICAgICAgICAgIFNpZGUNCg0KfCoqKioqKiAgICAgICBJZiBhIE1vZGVsX25vZGVt YXAgbm9kZSBuYW1lIGlzIHJlcGVhdGVkIHdpdGhpbiBhDQogICAgICAgICAgICAgIFtOb2RhbCBQ YXRoIERlc2NyaXB0aW9uXSBrZXl3b3JkLCB0aGUgU2lkZSBzdWJwYXJhbWV0ZXIgaXMNCnwqKioq ICAgICAgICAgcmVxdWlyZWQgYW5kIHBvc2l0aW9uZWQgYXMgdGhlIG5leHQgbGluZSB1bmRlciB0 aGUNCnwqKioqICAgICAgICAgTW9kZWxfbm9kZW1hcCBzdWJwYXJhbWV0ZXIuICBUaGUgU2lkZSBz dWJwYXJhbWV0ZXIgaXMgZm9sbG93ZWQNCnwqKioqICAgICAgICAgYnkgYSB1bmlxdWUgc2lkZSBu YW1lIHRvIGFsbG93IHRvb2xzIHRvIGlkZW50aWZ5IHdoaWNoIG9mIHRoZQ0KfCoqKiogICAgICAg ICBpZGVudGljYWwgbm9kZSBtYXBzIHRvIG1ha2UgdGhlIGNvbm5lY3Rpb24uDQogICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICBUaGUgU2lkZSBzdWJwYXJhbWV0ZXIgaXMgcmVxdWlyZWQgZm9y IGFsbCBNb2RlbF9ub2RlbWFwIGxpbmVzDQp8KioqKiAgICAgICAgIHdpdGggaWRlbnRpY2FsIG5v ZGUgbWFwIG5hbWVzLiAgVGhlIFNpZGUgc3VicGFyYW1ldGVyIGlzDQp8KioqKioqICAgICAgIGZv bGxvd2VkIGJ5IGEgdW5pcXVlIHNpZGUgbmFtZS4gIFRoaXMgc2lkZSBuYW1lIGlkZW50aWZpZXMg YQ0KfCoqKioqKiAgICAgICBzcGVjaWZpYyBub2RlIG1hcCBjb25uZWN0aW9uIGZyb20gc2V2ZXJh bCB3aXRoIHRoZSBzYW1lIG5hbWUuDQoNCg0KfCoqIEVuZCBvZiBzdWItc2VjdGlvbiBhZGRpdGlv bg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KQU5BTFlTSVMgUEFUSC9EQVRBIFRIQVQgTEVE IFRPIFNQRUNJRklDQVRJT046DQoNCk9yaWdpbmFsbHkgaXQgd2FzIGFzc3VtZWQgdGhhdCBpZiB0 aGUgcGlub3V0IGF0IGVhY2ggZW5kIG9mIGFuIGludGVyY29ubmVjdA0Kc3VjaCBhcyBhIGNvbm5l Y3RvciBoYWQgdGhlIHNhbWUgcGluIG51bWJlcnMsIHRoZW4gdGhlIHNhbWUgW0lDTSBQaW4gTWFw XQ0KdGFibGUgY291bGQgYmUgdXNlZCBhcyByZWZlcmVuY2VkIGJ5IHRoZSBNb2RlbF9waW5tYXAu DQoNCkhvd2V2ZXIsIHRoaXMgbGVhZHMgdG8gYW1iaWd1b3VzIGJlZ2luLWVuZCBjb25kaXRpb25z IGZvciBzdHJhaWdodCB0aHJvdWdoDQpwYXRocyBhbmQgcG9zc2libGUgYW1iaWd1aXR5IGZvciBz cGxpdHRlciB0b3BvbG9naWVzIHBvc3NpYmxlIGluIGJvdGggdGhlDQpUcmVlIFBhdGggRGVzY3Jp cHRpb25dIGFuZCBbTm9kYWwgUGF0aCBEZXNjcmlwdGlvbl0gd2hlbiBhIHNwZWNpZmljIGVuZA0K bmVlZHMgdG8gYmUgY29ubmVjdGVkIGV4dGVybmFsbHkuICBTbyB1bmlxdWUgTW9kZWxfcGlubWFw IGFuZCBNb2RlbF9ub2RlbWFwDQpuYW1lcyBhcmUgZXhwbGljaXRseSBzcGVjaWZpZWQgdG8gYXNz aXN0IGluIHRoZSBjb3JyZWN0IGNvbm5lY3Rpb24uDQoNClRoaXMgcHJlcGFyZXMgSUNNIGZvciBh IHBvc3NpYmxlIElCSVMgQklSRCB0byBjb25uZWN0IElCSVMgd2l0aCBJQ00gdXNpbmcNCnRoZSBt dWx0aS1saW5ndWFsIGZvcm1hdC4NCg0KVGhlIGxhbmd1YWdlIGlzIG5vdCBjaGFuZ2VkIHJlZ2Fy ZGluZyBwb3NzaWJsZSBzaW5nbGUgTW9kZWxfcGlubWFwIGFuZA0KTW9kZWxfbm9kZW1hcCBsaW5l cy4gIEFuZCBVbm1hdGVkIG1vZGVsIHdpbGwgaGF2ZSBhIHNpbmdsZSBNb2RlbF8qbWFwIGxpbmUu DQoNCklJUkQ4LjE6DQoNCkEgbmV3IHN1YnBhcmFtZXRlciAiU2lkZSIgaXMgaW50cm9kdWNlZCBz byB0aGF0IHRoZSBzYW1lIE1vZGVsX3Bpbm1hcCBuYW1lDQpjYW4gYmUgdXNlZCBzZXZlcmFsIHRp bWVzIHdpdGhvdXQgcmVxdWlyaW5nIGNvcGluZyBhbiBlbnRpcmUgW0lDTSBQaW4gTWFwXQ0KdGFi bGUuICBJdCBpcyBhbHNvIGludHJvZHVjZWQgZm9yIE1vZGVsX25vZGVtYXAgZm9yIHRoZSBzYW1l IHJlYXNvbi4NClRoaXMgb3B0aW9uIHdhcyBjaG9zZW4gYW1vbmcgdGhlIGZvbGxvd2luZzoNCg0K KDEpIERvIG5vdGhpbmcgLSBOTyBzeW50YXggY2hhbmdlLCBjb21wYXRpYmxlIHdpdGggMS4wDQog ICAgd2FzdGVmdWwgZm9yIGxhcmdlIGNvbm5lY3RvcnMNCigyKSBEZXZpc2UgYW4gZXh0ZW5zaW9u IGNvbnZlbnRpb24gRXhhbXBsZTFfQSwgRVhhbXBsZTFfQiAuLi4gRXhhbXBsZTEvQS4NCiAgICBF eHRlbnNpb24gbWF5IGNvbmZsaWN0IHdpdGggYW4gYWN0dWFsIG5hbWluZyBjb252ZW50aW9uLiAN CigzKSBJbnRyb2R1Y2UgT3B0aW9uYWwgc3VicGFyYW1ldGVyIG9yIHNlY29uZCBjb2x1bW4gT1Ig c2luZ2xlIFNQQUNFDQogICAgRXhhbXBsZTEgU2lkZSBBICAgb3IgRXhhbXBsZTEgQQ0KICAgIEhv d2V2ZXIsIGNhbGxpbmcgcm91dGluZSBtdXN0IHdvcmsgd2l0aC93aXRob3V0IGV4dGVuc2lvbi4N Cig0KSBQZXJoYXBzIGludHJvZHVjZSBpbiB0aGUgW0lDTSBQaW4gTWFwXSBhbmQgW0lDTSBOb2Rl IE1hcF0NCiAgICBhKSBtdWx0aXBsZSBuYW1lcyANCiAgICBiKSBBbm90aGVyX25hbWUgICB4eHh4 eCAgc3VicGFyYW1ldGVyIHN5bnRheA0KDQpPcHRpb24gKDMpIHdpdGggYSBkaXN0aW5jdCBzdWJw YXJhbWV0ZXIgU2lkZSBpcyBjaG9zZW4gYXMgYXMgdGhlIG1ldGhvZA0KdGhhdCBpcyBjb25zaXN0 ZW50IHdpdGggdGhlIHJlc3Qgb2YgdGhlIHNwZWNpZmljYXRpb24uDQoNCklJUkQ4LjINCg0KU29t ZSBlZGl0b3JpYWwgY2hhbmdlcyBwZXIgQXJwYWQgTXVyYW55aSdzIGNvbW1lbnRzIGFyZSBtYWRl IGFuZCBub3RlZA0KYnkgfCoqKiogbGluZXMNCg0KSUlSRDguMw0KDQpTb21lIG1pbm9yIGVkaXRv cmlhbCBjaGFuZ2VzIHN1Z2dlc3RlZCBieSBBcnBhZCBNdXJuYXlpIG5vdGVkIGJ5DQp8KioqKioq IGxpbmVzLiAgKGNvcnJlY3Rpb24gb2YgcGluIHRvIG5vZGUsIGFuZCByZXdyaXRpbmcgb2YgdGhl DQpsYXN0IHNlbnRlbmNlIGluIHR3byBwYXJhZ3JhcGhzLikNCg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KDQpBTlkgT1RIRVIgQkFDS0dST1VORCBJTkZPUk1BVElPTjoNCg0KSUlSRDggYXNzdW1lcyB0 aGF0IElJUkQ2IHdpbGwgYmUgcmVqZWN0ZWQuDQoNClRoZSBnb2xkZW4gcGFyc2VyIG11c3QgYmUg Y29ycmVjdGVkIHRvIGFjY2VwdCBvbmx5IG9uZSBNb2RlbF8qbWFwIG9yIGVsc2UNCnRlc3QgdGhh dCB0aGUgYXJndW1lbnRzIG9mIHNldmVyYWwgYXJlIHVuaXF1ZS4NCg0KSUlSRDggd2FzIGRpc2N1 c3NlZCBhdCB0aGUgT2N0b2JlciAyOSwgMjAwNCBJQklTIG1lZXRpbmcgYW5kIHRoZSBOb3ZlbWVi ZXINCjQsIDIwMDQgSUJJUyBGdXR1cmVzIE1lZXRpbmcuICBUaGUgYWN0aW9uIGl0ZW0gd2FzIHRv IGludmVzdGlnYXRlIGEgYmV0dGVyDQptZXRob2Qgb2YgZGlmZmVyZW50aWF0aW5nIHRoZSB0ZXJt aW5hbHMgYnkgc29tZSBuYW1lLCBleHRlbnNpb24gb3IgbmFtZQ0KYW5kIHN1YnBhcmFtZXRlciB0 byBhdm9pZCB0aGUgbmVlZCB0byBwcm92aWRlIGxhcmdlLCBpZGVudGljYWwgcGluIHRhYmxlcy4N Cg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KDQo= - ------_=_NextPart_001_01C4FA92.711E10A0-- |------------------------------------------------------------------ |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 #50 ************************