From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #67 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Monday, October 31 2005 Volume 01 : Number 067 ---------------------------------------------------------------------- Date: Tue, 04 Oct 2005 15:04:54 -0400 From: Paul Fernando Subject: Re: [IBIS-Users] Differential Buffer Modelling Arpad,

In differential buffers that contain common mode feedback, wouldn't it be more accurate to disconnect the feedback circuit before following this technique?

Regards,
Paul

Muranyi, Arpad wrote:

Kong-Yew,

 

1) Yes, you can apply this technique to receivers with ODT too.

 

2) I can't tell you which tool supports these keywords.  You

should ask the vendors or try the tool and see what happens.

 

Arpad

================================================================


From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Kong Yew Chan
Sent: Tuesday, October 04, 2005 3:27 AM
To: ibis-users@eda.org; ibis@eda.org
Subject: RE: [IBIS-Users] RE: [IBIS] Differential Buffer Modelling

Thanks Arpad! I have further questions, hope you don’t mind.

 

1)       Is this method of measuring differential current applicable to “receiver” with on-die termination?

2)       How does simulators interpret the [Series Current] keyword? Do they automatically apply the series [Model] upon locating the [Series Pin Mapping] information when the pins are used? Which simulator currently supports this keyword? HSPICE? Hyperlynx?

 

Thanks.

Kong-Yew

 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi, Arpad
Sent: Monday, October 03, 2005 11:49 PM
To: ibis-users@eda.org; ibis@eda.org
Subject: [IBIS-Users] RE: [IBIS] Differential Buffer Modelling

 

Kong-Yew,

 

1)  You are correct.  You would use Idiff and Vdiff for the table

    in [Series Current].

2)  You should use the same response (except with negative polarity)

    for the cancellation that you will use in your final model.  If

    it was an [R Series], use a negative resistance, if it was [Series

    Current], use the same PWL table (with the signs reversed).

 

I hope this helps.

 

Arpad Muranyi

Intel Corporation

=======================================================================

 

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Kong Yew Chan
Sent: Monday, October 03, 2005 6:21 AM
To: ibis-users@eda.org; ibis@eda.org
Subject: [IBIS] Differential Buffer Modelling

IBIS Gurus,

 

I have some questions about generating differential buffer model as stated in latest Cookbook 4.0.

1)          My normalized differential mode current has a similar plot as shown in Pg 36. It’s a function of the differential voltage, so that makes the usage of keyword [Series Current] appropriate in this case. To fill the I-V table, am I supposed to use the Vdiff vs Idiff ?

2)          For the V-T table data extraction, it was mentioned in Pg 40 that for [Series Current] keyword, PWL current source can be used to replace the R value. What should be the PWL response to represent the Idiff? (Idiff was only found to be a function of Vdiff from I-V extraction).

 

Please advise if my assumptions are incorrect.  

 

Thanks

Kong-Yew


|------------------------------------------------------------------ |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, 06 Oct 2005 08:50:16 +0000 From: "lau yy" Subject: [IBIS-Users] clock speed and [sim time]
Dear ALL,
 
Is there any relation between the clock speed (that the chip can work under) with [sim time] (in the .s2i)?
 
If let say, my product can work under 40MHz only, how can I related it to the IBIS model file?
 
As I changing the [sim time] of a same model file, the RAMP of the pins will change with different [sim time]. By changing this I can reduce some of the rising/falling waveform errors. Do this mean anything to my model?
 
 
 
rdgs
yylau
|------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 6 Oct 2005 15:40:12 -0700 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] Differential Buffer Modelling This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5CAC6.EA364900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, =20 I am not sure I understand what feedback you are referring to. Could you please explain? Legacy IBIS models are not able to model feedback anyway, so I am not sure what the context is for this question. =20 Arpad =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On = Behalf Of Paul Fernando Sent: Tuesday, October 04, 2005 12:05 PM To: Muranyi, Arpad; ibis-users@eda.org Subject: Re: [IBIS-Users] Differential Buffer Modelling Arpad, In differential buffers that contain common mode feedback, wouldn't it = be more accurate to disconnect the feedback circuit before following = this technique? Regards, Paul Muranyi, Arpad wrote:=20 Kong-Yew, =20 1) Yes, you can apply this technique to receivers with ODT too. =20 2) I can't tell you which tool supports these keywords. You should ask the vendors or try the tool and see what happens. =20 Arpad = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ________________________________ From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Kong = Yew Chan Sent: Tuesday, October 04, 2005 3:27 AM To: ibis-users@eda.org; ibis@eda.org Subject: RE: [IBIS-Users] RE: [IBIS] Differential Buffer Modelling =09 =09 Thanks Arpad! I have further questions, hope you don't mind. =20 1) Is this method of measuring differential current applicable to = "receiver" with on-die termination? 2) How does simulators interpret the [Series Current] keyword? Do = they automatically apply the series [Model] upon locating the [Series = Pin Mapping] information when the pins are used? Which simulator = currently supports this keyword? HSPICE? Hyperlynx?=20 =20 Thanks. Kong-Yew =20 =09 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On = Behalf Of Muranyi, Arpad Sent: Monday, October 03, 2005 11:49 PM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS-Users] RE: [IBIS] Differential Buffer Modelling =20 Kong-Yew, =20 1) You are correct. You would use Idiff and Vdiff for the table in [Series Current]. 2) You should use the same response (except with negative polarity) for the cancellation that you will use in your final model. If it was an [R Series], use a negative resistance, if it was [Series Current], use the same PWL table (with the signs reversed). =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=3D=3D=3D=3D=3D=3D=3D=3D =20 =09 ________________________________ From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Kong = Yew Chan Sent: Monday, October 03, 2005 6:21 AM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS] Differential Buffer Modelling IBIS Gurus, =20 I have some questions about generating differential buffer model as = stated in latest Cookbook 4.0. 1) My normalized differential mode current has a similar plot = as shown in Pg 36. It's a function of the differential voltage, so that = makes the usage of keyword [Series Current] appropriate in this case. To = fill the I-V table, am I supposed to use the Vdiff vs Idiff ? 2) For the V-T table data extraction, it was mentioned in Pg = 40 that for [Series Current] keyword, PWL current source can be used to = replace the R value. What should be the PWL response to represent the = Idiff? (Idiff was only found to be a function of Vdiff from I-V = extraction).=20 =20 Please advise if my assumptions are incorrect. =20 =20 Thanks Kong-Yew |------------------------------------------------------------------ |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=20 - ------_=_NextPart_001_01C5CAC6.EA364900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul,
 
I am not sure I understand what feedback=20 you
are referring to.  Could you please=20 explain?
Legacy IBIS models are not able to model=20 feedback
anyway, so I am not sure what the = context is=20 for
this question.
 
Arpad
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of Paul=20 Fernando
Sent: Tuesday, October 04, 2005 12:05 = PM
To:=20 Muranyi, Arpad; ibis-users@eda.org
Subject: Re: [IBIS-Users]=20 Differential Buffer Modelling

Arpad,

In differential buffers that contain common = mode=20 feedback, wouldn't it be more accurate to disconnect the feedback = circuit before=20 following this technique?

Regards,
Paul

Muranyi, Arpad = wrote:=20

Kong-Yew,

 

1) Yes, you can apply this technique to = receivers=20 with ODT too.

 

2) I can't tell you which tool supports = these=20 keywords.  You

should ask the vendors or try the tool and = see what=20 happens.

 

Arpad

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] = On Behalf=20 Of Kong Yew Chan
Sent: Tuesday, October 04, 2005 3:27=20 AM
To: ibis-users@eda.org; ibis@eda.org
Subject: RE:=20 [IBIS-Users] RE: [IBIS] Differential Buffer = Modelling

Thanks = Arpad! I have=20 further questions, hope you don=92t mind.

 

1)      =20 Is this = method of=20 measuring differential current applicable to =93receiver=94 with = on-die=20 termination?

2)      =20 How does = simulators=20 interpret the [Series Current] keyword? Do they automatically apply = the series=20 [Model] upon locating the [Series Pin Mapping] information when the = pins are=20 used? Which simulator currently supports this keyword? HSPICE? = Hyperlynx?=20

 

Thanks.

Kong-Yew

 

From: owner-ibis-users@eda.org = [mailto:owner-ibis-users@eda.org<= /A>]=20 On Behalf Of Muranyi,=20 Arpad
Sent: Monday, = October=20 03, 2005 11:49 PM
To: ibis-users@eda.org; ibis@eda.org
Subject: [IBIS-Users] RE: = [IBIS]=20 Differential Buffer Modelling

 

Kong-Yew,

 

1)  You are = correct.  You would use Idiff and Vdiff for the = table

    in=20 [Series Current].

2)  You = should use=20 the same response (except with negative polarity)

    for the=20 cancellation that you will use in your final model.  = If

    it was=20 an [R Series], use a negative resistance, if it was = [Series

   =20 Current], use the same PWL table (with the signs = reversed).

 

I hope this=20 helps.

 

Arpad=20 Muranyi

Intel=20 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=3D=3D=3D=3D=3D=3D=3D=3D

 

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] = On Behalf Of Kong Yew = Chan
Sent: Monday, October 03, 2005 = 6:21=20 AM
To: ibis-users@eda.org; ibis@eda.org
Subject: [IBIS] Differential = Buffer=20 Modelling

IBIS = Gurus,

 

I have some questions = about=20 generating differential buffer model as stated in latest Cookbook=20 4.0.

1)         =20 My normalized = differential mode=20 current has a similar plot as shown in Pg 36. It=92s a function of the = differential voltage, so that makes the usage of keyword [Series = Current]=20 appropriate in this case. To fill the I-V table, am I supposed to use = the=20 Vdiff vs Idiff ?

2)         =20 For the V-T table data = extraction,=20 it was mentioned in Pg 40 that for [Series Current] keyword, PWL = current=20 source can be used to replace the R value. What should be the PWL = response to=20 represent the Idiff? (Idiff was only found to be a function of Vdiff = from I-V=20 extraction).

 

Please advise if my = assumptions=20 are incorrect.  

 

Thanks

Kong-Yew


|----------------= - --------------------------------------------------=20 |For help or to subscribe/unsubscribe, email majordomo@eda.org |with = just the=20 appropriate command message(s) in the body: | | help | subscribe ibis = | subscribe ibis-users | unsubscribe ibis |=20 unsubscribe ibis-users | |or = email a=20 written request to ibis-request@eda.org. | |IBIS reflector archives = exist under:=20 | | http://www.eda.org/pub/ibis/email_archive/ Recent |=20 http://www.eda.org/pub/ibis/users_archive/ Recent |=20 http://www.eda.org/pub/ibis/email/ E-mail since 1993 - ------_=_NextPart_001_01C5CAC6.EA364900-- |------------------------------------------------------------------ |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 Oct 2005 18:37:33 -0700 From: "Mirmak, Michael" Subject: [IBIS-Users] Open Forum Teleconference Technical Discussion Material All, The IBIS Open Forum teleconference on Friday, Oct. 7 will feature a technical discussion related to power delivery modeling under IBIS in general and BIRD97/98 in particular. The slides for this discussion, by Arpad Muranyi of Intel Corp., can be found at the following URL: http://www.eda.org/ibis/futures/Quiet_line_experiment.pdf - - Michael Mirmak Intel Corp. Chair, EIA IBIS Open Forum http://www.eigroup.org/ibis/ http://www.eda.org/ibis/ |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Sun, 09 Oct 2005 10:09:53 +0000 From: "lau yy" Subject: [IBIS-Users] 2 different working voltage range
Dear ALL,
 
 
Recently, I trying to built a model for 2 different working voltage range.
 
According to the data sheet, the product can work under 2 different voltage range, let say 2.60V and 3.30V.
 
But, when I modeling this product, I found that only 1 of them pass the IBIS checker (for 3.30V) . The other 1 (2.60V) fail with errors on Falling/Rising Waveform. The schematic and control file I use is the same. I just use 2different references voltages.
 
Can I conclude that the product just can work under the voltage range that pass the IBIS checker ?
 
Thanks
 
rdgs
yylau
|------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Sun, 9 Oct 2005 11:04:15 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] 2 different working voltage range This is a multi-part message in MIME format. - ------=_NextPart_000_00C7_01C5CCC1.3020D660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Are you changing the termination voltage along with the operating voltage? Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of lau yy Sent: Sunday, October 09, 2005 3:10 AM To: ibis-users@eda.org Subject: [IBIS-Users] 2 different working voltage range Dear ALL, Recently, I trying to built a model for 2 different working voltage range. According to the data sheet, the product can work under 2 different voltage range, let say 2.60V and 3.30V. But, when I modeling this product, I found that only 1 of them pass the IBIS checker (for 3.30V) . The other 1 (2.60V) fail with errors on Falling/Rising Waveform. The schematic and control file I use is the same. I just use 2different references voltages. Can I conclude that the product just can work under the voltage range that pass the IBIS checker ? Thanks rdgs yylau |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 - ------=_NextPart_000_00C7_01C5CCC1.3020D660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Are=20 you changing the termination voltage along with the operating=20 voltage?
 

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

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

-----Original Message-----
From: = owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org]On Behalf Of lau = yy
Sent:=20 Sunday, October 09, 2005 3:10 AM
To:=20 ibis-users@eda.org
Subject: [IBIS-Users] 2 different working = voltage=20 range

Dear ALL,
 
 
Recently, I trying to built a model for 2 different = working=20 voltage range.
 
According to the data sheet, the product can work = under 2=20 different voltage range, let say 2.60V and 3.30V.
 
But, when I modeling this product, I found that only = 1 of them=20 pass the IBIS checker (for 3.30V) . The other 1 (2.60V) fail with = errors=20 on Falling/Rising Waveform. The schematic and control file I use is = the same.=20 I just use 2different references voltages.
 
Can I conclude that the product just can work = under the=20 voltage range that pass the IBIS checker ?
 
Thanks
 
rdgs
yylau
|-------------------------------------------= - -----------------------=20 |For help or to subscribe/unsubscribe, email majordomo@eda.org |with = just the=20 appropriate command message(s) in the body: | | help | subscribe ibis=20 | subscribe ibis-users = | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS=20 reflector archives exist under: | | = http://www.eda.org/pub/ibis/email_archive/=20 Recent | http://www.eda.org/pub/ibis/users_archive/ Recent |=20 http://www.eda.org/pub/ibis/email/ E-mail since 1993 =
- ------=_NextPart_000_00C7_01C5CCC1.3020D660-- |------------------------------------------------------------------ |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 Oct 2005 11:06:04 -0700 From: Bob Ross Subject: [IBIS-Users] Asian IBIS Summit Third Announcement To All: This is the third announcement for the Asian IBIS Summit in Shenzhen, China, a major technology center near Hong Kong. The meeting is being held at the Crowne Plaza Hotel, and several IBIS experts are planning to attend. The agenda is nearly full with excellent presentations from US and Asian countries. The main benefit is to meet IBIS experts and people actively involved with IBIS model development, algorithm development, and usage. Some tentative titles/topics and presenters are: - - IBIS Committee Overview and IBIS Modeling Challenges Mirmak, Michael (Intel Corporation (USA) - - Using IBIS for SI Analysis Zhong, ZhangMin* and Wang, Lance** (Cadence Design Systems, *China and **USA) - - Fiberhome Telecommunications Technology Experiences with IBIS Models Zheng, Qi (Fiberhome Telecommunications Technology, China) - - (To be Determined) Shoji, Kazuyoshi (Hitachi ULSI Systems, Japan) - - Three Facets of IBIS: Interface, Behavior, and Measurement Dodd, Ian (Mentor Graphics Corporation, USA) - - IBIS and Power Delivery Systems Jiang, XiangZhong (Huawei Technologies, China) - - Power Delivery System Signal Return Path and SSO Analysis Guidelines Chen, Raymond (Sigrity, USA) - - How to Extract and Split the C_comp, and Why it is Important in Power Integrity Simulations Yang, Zhiping (Cisco Systems, USA) - - Macro Model and Multi-GHz System Simulation Zhu, ShunLin, (ZTE Corporation, China) - - IBIS Models for DDR2 Analysis Katz, Barry, (Signal Integrity Software (SiSoft), USA) - - JEITA EDA - WG Activity and Study of Interconnect Model Watanabe, Takeshi (NEC Electronics Corporation, Japan) - - IBIS Model and Algorithm Improvements Ross, Bob (Teraspeed Consulting Group, USA) Bob Ross Teraspeed Consulting Group Lance Wang Cadence Design Systems - ----------------------------------------------------------------------- ASIAN IBIS SUMMIT THIRD CALL FOR PARTICIPATION AND PRESENTATIONS - ----------------------------------------------------------------------- http://www.eda.org/pub/ibis/summits/dec05/ASIAN_IBIS_SUMMIT_CHINESE.pdf http://www.eda.org/pub/ibis/summits/dec05/ASIAN_IBIS_SUMMIT_CH_TRA-2.pdf ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A S I A N I B I S S U M M I T M E E T I N G Time/Date: Tuesday December 6, 2005, 8:00 AM to 5:30 PM Meeting starts at 9:00 AM Location: Crowne Plaza Hotel Shenzhen 9026 Shennan Rd, OCT Shenzhen, 518053 CHINA Tel: 86-755-26936888 Fax: 86-755-26936999 E-mail: cpsz@cpsz.com http://www.ichotelsgroup.com/h/d/cp/1/en/hd/SZXNS Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Primary Sponsor: Huawei Technologies Co-sponsors (in alphabetical order): Cadence Design Systems, Mentor Graphics Corporation, Signal Integrity Software (SiSoft), and Sigrity Contact us for details regarding sponsorship. Cost: FREE, including refreshments and buffet lunch Vendors: Some vendors will have information tables outside the meeting room BACKGROUND Shenzhen, next to Hong Kong, is a special economic zone in the Peoples Republic of China with many high technology companies and many development and sales offices of foreign companies. Many sites of interest are near the conference hotel. Like the European IBIS Summit, our objective is to reach out internationally to communicate with the local experts and to learn of regional concerns. CONFERENCE LANGUAGE The conference language is English, but we will plan for technical translation as needed in a manner to be determined. So presenters can optionally deliver in Chinese as long as an English version of the material is available. IBIS SUMMIT This meeting will be conducted as a formal IBIS Summit Meeting. Presentations will be archived in an electronic format on our Summits site, and minutes of the meeting will be issued. However, no formal decisions requiring votes will be planned. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Top-level Web Link: Country: Telephone: Comments: (Such as assistance for the travel requirements at the end) Send to BOTH: Bob Ross, Teraspeed Consulting Group bob@teraspeed.com Lance Wang, Cadence Design Systems lwang@cadence.com SIGNUP DEADLINE: November 25, 2005 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. If we have to select presentations for the number of time slots available, we will give preferential consideration to Asian-based presentations. Presentation Format: LCD Projection from meeting laptop computer Time: 15-30 Minutes including questions Electronic Archival: All presentations will uploaded to our public IBIS Summit archives Electronic Format: Power Point or Acrobat Presentation Copies: Available at the meeting for all attendees Presentation Deadline: November 7, 2005 to produce hard copies for the meeting If you plan a presentation, please ADD to the above registration information: Title of Presentation: Estimated Time: (30 minutes or less) Note: The agenda is full, but let us know if you are interested in doing a presentation. We may be able to adjust the schedule to allow for your presentation. We will notify you of acceptance and may follow up with questions when we form the program agenda. Note: Vendor promotional or business information is prohibited. Submitted presentations must be in English, although the delivery can be in a Chinese and translation to be arranged. Asian-based submissions are encouraged. AGENDA 8:15 - 9:00 Sign in, casual conversation, vendor tables 9:00 - 12:00 Presentations 12:00 - 13:30 Free buffet lunch, vendor tables 13:30 - 17:30 Presentations 17:30 - 18:30 Casual conversations, vendor tables The following companies are planning presentations: China: Huawei Technologies, ZTE Communications, Fiberhome Telecommunications Technology Japan: NEC Electronics Corportion (on JEITA), Hitachi ULSI Systems USA Cadence Design Systems, Cisco Systems, Intel Corporation, Mentor Graphics Corporation, Signal Intergrity Software (SiSoft), Sigrity, and Teraspeed Consulting Group LIST OF NEARBY HOTELS AND TRAVEL RULES Hotels in all price ranges can be found through internet searches. A link to the conference hotel, Crown Plaza Hotel Shenzhen, is: http://www.ichotelsgroup.com/h/d/cp/1/en/hd/SZXNS Comply with your travel rules, such as indicated in the link below to China and Shenzhen. Work with your travel agent. Notify us as a sign-up comment if you need assistance. Visas, if needed, should fall in the visit/business category: http://www.travelchinaguide.com/embassy/visa.htm - ----------------------------------------------------------------- - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 13 Oct 2005 08:26:08 -0600 From: rrwolff@micron.com Subject: [IBIS-Users] [IBIS] Open forum minutes (10/07/05) This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5D002.0D775A01 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5D002.0D775A01" - ------_=_NextPart_002_01C5D002.0D775A01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached are the minutes of the Friday, October 7, 2005 IBIS Open Forum teleconference. Randy Wolff IBIS Open Forum Secretary <>=20 - ------_=_NextPart_002_01C5D002.0D775A01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [IBIS] Open forum minutes (10/07/05)

Attached are the minutes of the = Friday, October 7, 2005 IBIS Open Forum teleconference.

Randy Wolff
IBIS Open Forum Secretary
= <<m100705.txt>>

- ------_=_NextPart_002_01C5D002.0D775A01-- - ------_=_NextPart_001_01C5D002.0D775A01 Content-Type: text/plain; name="m100705.txt" Content-Transfer-Encoding: base64 Content-Description: m100705.txt Content-Disposition: attachment; filename="m100705.txt" REFURTogMTAvMTIvMDUNCg0KU1VCSkVDVDogT2N0b2JlciA3LCAyMDA1IEVJQSBJQklTIE9wZW4g Rm9ydW0gTWVldGluZyBNaW51dGVzDQoNClZPVElORyBNRU1CRVJTIEFORCAyMDA1IFBBUlRJQ0lQ QU5UUw0KQWN0ZWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgUHJhYmh1IE1vaGFuDQpBZ2Vy ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAoTmlyYXYgUGF0ZWwpDQpBTUQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBXYXNpbSBVbGxhaCoNCkFuc29mdCBDb3Jwb3JhdGlvbiAgICAg ICAgICAgICAgIE1pY2hhZWwgQnJlbm5lbWFuDQpBcHBsaWVkIFNpbXVsYXRpb24gVGVjaG5vbG9n eSAgICBOb3JpbyBNYXRzdWkNCkNhZGVuY2UgRGVzaWduIFN5c3RlbXMgICAgICAgICAgIExhbmNl IFdhbmcqLCBbRG9uYWxkIFRlbGlhbl0sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEhlaWtvIER1ZGVrLCBTaGFuZ2xpIFd1KiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRHJhZ29zbGF2IE1pbG9zZXZlYywgS2VuIFdpbGxpcw0KQ2lzY28gU3lzdGVtcyAg ICAgICAgICAgICAgICAgICAgU3llZCBIdXEqLCBNaWtlIExhQm9udGUqLA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBUb2RkIFdlc3RlcmhvZmYsIFpoaXBpbmcgWWFuZyosDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZpbnUgQXJtdW11Z2hhbSwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2FsbWFuIEppdmEsIFNhdGlzaCBQcmF0YXBu ZW5pLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbC15b3VuZyBQYXJrLCBT ZXJnaW8gQ2FtZXJsbywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGhpbGxp cGUgU29jaG91eCwgRWRkaWUgV3UsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEd1cnByZWV0IEh1bmRhbCwgSmF5YW50aGkgTmF0YXJhamFuDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEFiZHVsUmFobWFuIFJhZmlxKg0KRmx1ZW50ICAgICAgICAgICAgICAg ICAgICAgICAgICAgKENoZXRhbiBEZXNhaSkNCkZyZWVzY2FsZSAgICAgICAgICAgICAgICAgICAg ICAgIEpvbiBCdXJuZXR0DQpHcmVlbiBTdHJlYWsgUHJvZ3JhbXMgICAgICAgICAgICBMeW5uZSBH cmVlbioNCkhpdGFjaGkgVUxTSSBTeXN0ZW1zICAgICAgICAgICAgIEthenV5b3NoaSBTaG9qaQ0K SHVhd2VpICAgICAgICAgICAgICAgICAgICAgICAgICAgKEppYW5nIFhpYW5nIFpob25nKQ0KSW50 ZWdyYXRlZCBDaXJjdWl0IFN5c3RlbXMgKElDUykgKERhbiBDbGVtZW50aSkNCkludGVsIENvcnBv cmF0aW9uICAgICAgICAgICAgICAgIE1pY2hhZWwgTWlybWFrKiwgQXJwYWQgTXVyYW55aSosDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1cmVzaCBDaGFuZHJhc2VraGFyDQpM U0kgTG9naWMgICAgICAgICAgICAgICAgICAgICAgICBGcmFuayBHYXNwYXJpaywgV2lsbGlhbSBM YXUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pa2UgSmVua2lucywgUmVn aW5hbGQgQ293bGV5LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBLdXN1bWFr dW1hcmkgTWF0dGENCk1hcnZlbGwgICAgICAgICAgICAgICAgICAgICAgICAgIEl0emlrIFBlbGVn Kg0KTWVudG9yIEdyYXBoaWNzICAgICAgICAgICAgICAgICAgSm9obiBBbmd1bG8qLCBHdXkgZGUg QnVyZ2gsIElhbiBEb2RkKiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3Rl dmVuIE1jS2lubmV5LCBLaW0gT3dlbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU3RlcGhhbmUgUm91c3NlYXUNCk1pY3JvbiBUZWNobm9sb2d5ICAgICAgICAgICAgICAgIFJh bmR5IFdvbGZmKiwgUGF1bCBHcmVnb3J5LCBCb2IgQ294DQpORUMgRWxlY3Ryb25pY3MgQ29ycG9y YXRpb24gICAgICBUYWtlc2hpIFdhdGFuYWJlLCBMb3JpIEFza2V3LA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBUYWt1cm8gVHN1amlrYXdhDQpQYW5hc29uaWMgICAgICAgICAg ICAgICAgICAgICAgICBBdHN1amkgSXRvDQpTYW10ZWMgICAgICAgICAgICAgICAgICAgICAgICAg ICBbT3R0byBCZW5uaWddDQpTaWVtZW5zIEFHICAgICAgICAgICAgICAgICAgICAgICBFY2toYXJk IExlbnNraSosIEthdGphIEtvbGxlciwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTWFuZnJlZCBNYXVyZXIsIEhlaW56IElib3dza2ksDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFdvbGZnYW5nIFJvaG1lciwgS2xhdXMgSHVlYm5lcg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBNaWNoYWVsIEtpbmRpag0KICAgU2llbWVucyBNZWRpY2Fs ICAgICAgICAgICAgICAgRGF2aWQgTGllYnkNClNpZ25hbCBJbnRlZ3JpdHkgU29mdHdhcmUgICAg ICAgIFJvYmVydCBIYWxsZXIqLCBEb3VnbGFzIEJ1cm5zLA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCYXJyeSBLYXR6LCBNaWtlIE1heWVyDQpTaWdyaXR5ICAgICAgICAgICAg ICAgICAgICAgICAgICBTYW0gQ2hpdHdvb2QsIEppbmcgVGluZywgUmF5bW9uZCBDaGVuKg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKaWFndWFuIEZhbmcsIFRlbyBZYXRtYW4s IE1pY2hhZWwgTGVpbnMNClNpbGVnbyAgICAgICAgICAgICAgICAgICAgICAgICAgIChKb2UgRnJv bmlld3NraSkNClNpbGljb24gSW1hZ2UgICAgICAgICAgICAgICAgICAgIChPb2sgS2ltKQ0KU3lu b3BzeXMgICAgICAgICAgICAgICAgICAgICAgICAgV2FycmVuIFdvbmcsIEFuZHkgVGFpDQpUZXJh c3BlZWQgQ29uc3VsdGluZyBHcm91cCAgICAgICBCb2IgUm9zcyosIFNjb3R0IE1jTW9ycm93LA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUb20gRGFnb3N0aW5vDQpUZXhhcyBJ bnN0cnVtZW50cyAgICAgICAgICAgICAgICAoU3RldmUgU3BlbmNlciksIE90aXMgR29ybGV5DQpY aWxpbnggICAgICAgICAgICAgICAgICAgICAgICAgICBSYXkgQW5kZXJzb24qLCBTYW5qYXkgTWVo dGENClp1a2VuICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwgU2NoYWVkZXIsIFJh bGYgQnJ1ZW5pbmcNCg0KT1RIRVIgUEFSVElDSVBBTlRTIElOIDIwMDU6DQpBbHRlcmEgICAgICAg ICAgICAgICAgICAgICAgICAgICBLaGFsaWQgQW5zYXJpDQpCYXlzaWRlIERlc2lnbiAgICAgICAg ICAgICAgICAgICBLZXZpbiBSb3NlbGxlDQpDZWxzaW9uaVggICAgICAgICAgICAgICAgICAgICAg ICBLZWxsZWUgQ3Jpc2FmdWxsaQ0KRGVsbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVi cmV5IFNwYXJrbWFuDQpFTUMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCcmlhbiBBcnNl bmF1bHQsIERhbmllbCBOaWxzc29uLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBKYXNvbiBQcml0Y2hhcmQsIEppbmh1YSBDaGVuDQpFbnRlcmFzeXMgTmV0d29ya3MgICAgICAg ICAgICAgICBGYWJyaXppbyBaYW5lbGxhDQpFUEZMICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBBbGFpbiBWYWNob3V4DQpGdWppdHN1IFNpZW1lbnMgQ29tcHV0ZXJzICAgICAgICBNYXJ0aW4g UmFtbWUNCkdFSUEgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaHJpcyBEZW5oYW0pDQpJ bmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgICAgICAgICBUaG9tYXMgU3RlaW5lY2tlLCBNaW5lYSBH b3Nwb2Rpbm92YSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQW1pciBNb3Rh bWVkaSwgWWFubiBaaW5zaXVzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBD aHJpc3RpYW4gU3BvcnJlciwgUmFkb3ZhbiBWdWxldGljDQpJTlNBIFRvdWxvdXNlICAgICAgICAg ICAgICAgICAgICBFdGllbm5lIFNpY2FyZA0KSk1EIEludGVybmF0aW9uYWwgICAgICAgICAgICAg ICAgSm9lIFNvY2hhDQpLQVcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBLYXp1aGlrbyBL dXN1bm9raQ0KTGV2ZW50aGFsIERlc2lnbiAgICAgICAgICAgICAgICAgUm95IExldmVudGhhbA0K THluZ3VlbnQgICAgICAgICAgICAgICAgICAgICAgICAgQW5kcmV3IExldnkNCk5ldExvZ2ljICAg ICAgICAgICAgICAgICAgICAgICAgIEVyaWMgSHN1DQpOb2tpYSAgICAgICAgICAgICAgICAgICAg ICAgICAgICBFcm5vIExhaHRlZW5tYXRpLCBUYXBhbmkgdm9uIFJhdW5lcg0KTm9ydGggQ2Fyb2xp bmEgU3RhdGUgVW5pdi4gICAgICAgQW1icmlzaCBWYXJtYSoNClBvbGl0ZWNuaW8gZGkgVG9yaW5v ICAgICAgICAgICAgIElnb3IgU3RpZXZhbm8NClNpMiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFN1bWl0IERhc0d1cHRhDQpTaWxpY29uIEJhbmR3aWR0aCAgICAgICAgICAgICAgICBbS2lt IEhlbGxpd2VsbF0NClNUTWljcm9lbGVjdHJvbmljcyAgICAgICAgICAgICAgIEFudG9uaW8gR2ly YXJkaSoNClN1biBNaWNyb3N5c3RlbXMgICAgICAgICAgICAgICAgIEd1c3Rhdm8gQmxhbmRvDQpU aW1lIERvbWFpbiBBbmFseXNpcyBTeXN0ZW1zICAgICBEaW1hIFNtb2x5YW5za3ksIFN0ZXZlIENv cmV5DQpXZXN0ZXJuIERpZ2l0YWwgICAgICAgICAgICAgICAgICBNb2hhbW1hZCBBbGkNCkluZGVw ZW5kZW50ICAgICAgICAgICAgICAgICAgICAgIEJlcm5oYXJkIFVuZ2VyIChTaWVtZW5zIHJldGly ZWQpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBLaW0gSGVsbGl3ZWxsDQoN Cg0KSW4gdGhlIGxpc3QgYWJvdmUsIGF0dGVuZGVlcyBhdCB0aGUgbWVldGluZyBhcmUgaW5kaWNh dGVkIGJ5ICouDQpQcmluY2lwYWwgbWVtYmVycyBvciBvdGhlciBhY3RpdmUgbWVtYmVycyB3aG8g aGF2ZSBub3QgYXR0ZW5kZWQgYXJlIGluDQpwYXJlbnRoZXNlcy4gUGFydGljaXBhbnRzIHdobyBu byBsb25nZXIgYXJlIGluIHRoZSBvcmdhbml6YXRpb24gYXJlIGluDQpzcXVhcmUgYnJhY2tldHMu DQoNClVQQ09NSU5HIE1FRVRJTkdTDQpUaGUgYnJpZGdlIG51bWJlcnMgZm9yIGZ1dHVyZSBJQklT IHRlbGVjb25mZXJlbmNlcyBhcmUgYXMgZm9sbG93czoNCg0KICAgICAgIERhdGUgICAgICAgICAg ICBUZWxlcGhvbmUgTnVtYmVyICAgIEJyaWRnZSAjICAgICBQYXNzY29kZQ0KT2N0b2JlciAyOCwg MjAwNSAgICAgICAxLTkxNi0zNTYtMjY2MyAgICAgICAgMiAgICAgICAgICA3NzQtNTY4Mw0KDQpB bGwgbWVldGluZ3MgYXJlIDg6MDAgQU0gdG8gOTo1NSBBTSBVUyBQYWNpZmljIFRpbWUuICBNZWV0 aW5nIGFnZW5kYXMNCmFyZSB0eXBpY2FsbHkgZGlzdHJpYnV0ZWQgc2V2ZW4gZGF5cyBiZWZvcmUg ZWFjaCBPcGVuIEZvcnVtLiAgTWludXRlcw0KYXJlIHR5cGljYWxseSBkaXN0cmlidXRlZCB3aXRo aW4gc2V2ZW4gZGF5cyBvZiB0aGUgY29ycmVzcG9uZGluZw0KbWVldGluZy4gIFdoZW4gY2FsbGlu ZyBpbnRvIHRoZSBtZWV0aW5nLCBwcm92aWRlIHRoZSBicmlkZ2UgbnVtYmVyIGFuZA0KcGFzc2Nv ZGUgYXQgdGhlIGF1dG9tYXRlZCBwcm9tcHRzLiAgSWYgYXNrZWQgYnkgYW4gb3BlcmF0b3IsIHBs ZWFzZQ0KcmVxdWVzdCB0byBqb2luIHRoZSBJQklTIE9wZW4gRm9ydW0gaG9zdGVkIGJ5IE1pY2hh ZWwgTWlybWFrLg0KRm9yIGludGVybmF0aW9uYWwgZGlhbC1pbiBudW1iZXJzLCBwbGVhc2UgY29u dGFjdCBNaWNoYWVsIE1pcm1hay4NCg0KTk9URTogIkFSIiA9IEFjdGlvbiBSZXF1aXJlZC4NCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1NSU5VVEVTLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCklOVFJPRFVDVElPTlMgQU5EIE1FRVRJTkcgUVVPUlVNDQpObyBu ZXcgcGFydGljaXBhbnRzLg0KDQoNCkNBTEwgRk9SIFBBVEVOVFMNCk1pY2hhZWwgTWlybWFrIGNh bGxlZCBmb3IgYW55IHBhdGVudHMgb3IgcGVuZGluZyBwYXRlbnRzIHJlbGF0ZWQgdG8gdGhlIElC SVMNClZlcnNpb24gMy4yLCA0LjAsIDQuMSwgb3IgSUNNIDEuMSBzcGVjaWZpY2F0aW9ucy4gIE5v IHBhdGVudHMgd2VyZSBkZWNsYXJlZC4NCg0KDQpNRU1CRVJTSElQIFVQREFURSBBTkQgVFJFQVNV UkVSJ1MgUkVQT1JUDQpNaWNoYWVsIE1pcm1hayByZXBvcnRlZCB0aGF0IHdlIGhhdmUgMzEgbWVt YmVycyBhcyBvZiB0b2RheSwgbm93IHRoYXQNCkZyZWVzY2FsZSBoYXMgcmVqb2luZWQuICBUaGUg YnVkZ2V0IGRlZmljaXQgaGFzIGJlZW4gcmVkdWNlZCB0byAkMjAwMCwgYW5kDQp0aGlzIHNob3Vs ZCBiZSBjbGVhcmVkIHdpdGggdHdvIGV4cGVjdGVkIElDTSBwYXJzZXIgcHVyY2hhc2VzLg0KDQoN ClJFVklFVyBPRiBNSU5VVEVTIEFORCBBUlMNCk1pY2hhZWwgTWlybWFrIHJldmlld2VkIHRoZSBt aW51dGVzIG9mIHRoZSBTZXB0ZW1iZXIgMTYsIDIwMDUgSUJJUyBPcGVuDQpGb3J1bSB0ZWxlY29u ZmVyZW5jZSBhbmQgdGhlIFNlcHRlbWJlciAxOSwgMjAwNSBJQklTIE9wZW4gRm9ydW0gU3VtbWl0 LiAgVGhlDQptaW51dGVzIG9mIGJvdGggd2VyZSBhcHByb3ZlZCB3aXRob3V0IGNoYW5nZS4NCg0K DQpQUkVTUyBBTkQgV0VCIFBBR0UgVVBEQVRFUw0KU3llZCBIdXEgcmVwb3J0ZWQgdGhhdCBoZSBo YWQgYWRkZWQgRnJlZXNjYWxlIHRvIHRoZSBtZW1iZXIgbGlzdCBhbmQgYWRkZWQNCnRoZSBTaWdy aXR5IGxvZ28uICBIZSBuZWVkcyB0byBtYWtlIGNoYW5nZXMgdG8gdGhlIGV2ZW50cyBwYWdlLiAg VGhlcmUgd2FzDQpzb21lIGRvd250aW1lIG9uIHRoZSBFSUEgc2VydmVyLCBidXQgdGhpcyBkaWQg bm90IGFmZmVjdCBhbnl0aGluZy4NCg0KDQpNQUlMSU5HIExJU1QgQURNSU5JU1RSQVRJT04NCkJv YiBSb3NzIHJlcG9ydGVkIHRoYXQgdGhlcmUgYXJlIHRocmVlIGVtYWlsIGFkZHJlc3NlcyB0cmVh dGluZyBJQklTIG1haWwNCmFzIFNQQU0uICBIZSBpcyB0cnlpbmcgdG8gcmVzb2x2ZSB0aGlzIGlz c3VlLg0KDQoNCk5FVyBNT0RFTFMgQVZBSUxBQkxFLCBMSUJSQVJZIFVQREFURQ0KTm8gdXBkYXRl Lg0KDQoNCk1JU0NFTExBTlkvQU5OT1VOQ0VNRU5UUw0KTm9uZS4NCg0KDQpPUEVOUyBGT1IgTkVX IElTU1VFUw0KQm9iIFJvc3MgbWVudGlvbmVkIHRoYXQgYSBCVUcgcmVwb3J0IHJlY2VpdmVkIGZy b20gVEkgdHVybmVkIG91dCB0byBub3QNCmJlIGEgQlVHLg0KDQoNCklOVEVSTkFUSU9OQUwvRVhU RVJOQUwgUFJPR1JFU1MNCg0KQk1BUyAyMDA1IENvbmZlcmVuY2UgU3VtbWFyeQ0KQXJwYWQgTXVy YW55aSBnYXZlIGEgc3VtbWFyeSBvZiB0aGUgQmVoYXZpb3JhbCBNb2RlbGluZyBhbmQgU2ltdWxh dGlvbg0KY29uZmVyZW5jZSB0aGF0IGhlIGF0dGVuZGVkLiAgQk1BUyBpcyBwYXJ0IG9mIHRoZSBJ RUVFIGFuZCBpcyBsYW5ndWFnZQ0KaW5kZXBlbmRlbnQuICBEaXNjdXNzaW9ucyBhdCB0aGUgbWVl dGluZyB3ZXJlIG9uIGJlaGF2aW9yYWwgbW9kZWxpbmcNCnRlY2huaXF1ZXMuICBNb3N0IHByZXNl bnRhdGlvbnMgd2VyZSBvbiBWSERMIGRlc2lnbiwgbW9kZWxpbmcsIGFuZA0Kc2ltdWxhdGlvbi4g IEFycGFkIHdhcyBpbnZpdGVkIHRvIHByZXNlbnQgbmV4dCB5ZWFyIGluIHRoZSBtZWV0aW5nIG9u IHdoYXQNCndlIGFyZSBkb2luZyBpbiBJQklTLiAgQXJwYWQgbWFkZSBhIGdvb2QgY29udGFjdCB3 aXRoIGEgdW5pdmVyc2l0eSBwcm9mZXNzb3INCmFuZCB3aWxsIGRpc2N1c3MgbW9kZWxpbmcgd2l0 aCBoaW0gbW9yZS4NCg0KVGhlcmUgY29udGludWUgdG8gYmUgdHdvIHBlbmRpbmcgc3RhbmRhcmRz IHVuZGVyIGNvbnNpZGVyYXRpb24gYnkgdGhlDQpJbnRlcm5hdGlvbmFsIEVsZWN0cm90ZWNobmlj YWwgQ29tbWlzc2lvbiAoSUVDKSB1bmRlciB0aGUgdGVjaG5pY2FsDQpjb21taXR0ZWUgVEM0Ny4g IEVhY2ggb2YgdGhlc2Ugc3RhbmRhcmRzIGhhdmUgbGlua3MgYmFjayB0byBJQklTLiAgV2UgYXJl DQp0aGUgYXBwcm9wcmlhdGUgY29tbWl0dGVlIHRvIHJldmlldyBhbmQgY29tbWVudCBvbiB0aGVz ZSBkb2N1bWVudHMuICBUaGUNCmRvY3VtZW50cyBhcmUgYXZhaWxhYmxlIGZvciB0ZWNobmljYWwg cmV2aWV3IGZyb20gQm9iIFJvc3MuICBNb3JlDQppbmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgYXQg dGhlIGZvbGxvd2luZyB1cmw6DQoNCiAgICAgIGh0dHA6Ly93d3cuaWVjLmNoDQoNClRoZSB0d28g c3RhbmRhcmRzIGFyZToNCg0KSUVDNjI0MDQgSS9PIEludGVyZmFjZSBNb2RlbCBmb3IgSW50ZWdy YXRlZCBDaXJjdWl0cyAoSU1JQykgYXMgNDdBLzcwNC9DRA0KKGNvbW1pdHRlZSBkcmFmdCkuICBU aGlzIGlzIGEgY29tcGV0aW5nIHN0YW5kYXJkIHdpdGggSUJJUyBhbmQgaXMgYW4NCmVuaGFuY2Vt ZW50IHRvIHNwaWNlIGxhbmd1YWdlcy4NCg0KTW9kZWxzIG9mIEludGVncmF0ZWQgQ2lyY3VpdHMg Zm9yIEVNSSBCZWhhdmlvcmFsIFNpbXVsYXRpb24gNDdBLzcxOS9OUA0KKG5ldyB3b3JrIHByb3Bv c2FsKS4gVGhpcyBpcyBhIGZvbGxvdyBvbiB0byBJQ0VNIChJQ0VNIGlzIDYyMDE0LTMpLg0KDQpC b2IgUm9zcyBtZW50aW9uZWQgdGhhdCBJRUMgVEM0Ny9TQzQ3QSBhcmUgaG9sZGluZyBzb21lIHdv cmtpbmcgZ3JvdXANCm1lZXRpbmdzIGluIEF1c3RpbiwgVGV4YXMgYXQgdGhlIEZyZWVzY2FsZSBT ZW1pY29uZHVjdG9yIGZhY2lsaXR5IG9uDQpPY3RvYmVyIDE3LTE5IGZvciBXRzkgYW5kIE9jdG9i ZXIgMjAtMjEgZm9yIFdHMi4gIFRoZXNlIG1lZXRpbmdzIGluY2x1ZGUNCklNSUMgYW5kIElDRU0g YWR2YW5jZXMgYW5kIHdpbGwgaGF2ZSBpbnRlcm5hdGlvbmFsIHBhcnRpY2lwYXRpb24uDQoNClRo ZSBFbGVjdHJpY2FsIFBlcmZvbWFuY2Ugb2YgRWxlY3Ryb25pYyBQYWNrYWdpbmcgKEVQRVApIGNv bmZlcmVuY2UgaXMgYmVpbmcNCmhlbGQgaW4gQXVzdGluIFRleGFzIG9uIE9jdG9iZXIgMjQtMjYu IFNvbWUgbWF0ZXJpYWwgaXMgb2YgaW50ZXJlc3QgdG8gSUJJUy4NCg0KDQpFSUEvQU5TSSBBUFBS T1ZBTCBBQ1RJVklUSUVTDQpSYW5keSBXb2xmZiByZXBvcnRlZCB0aGF0IGhlIGhhcyBhdHRlbXB0 ZWQgY29udGFjdGluZyB0aGUgR0VJQSB0d2ljZSBmb3INCm9mZmljaWFsIHJlc3VsdHMgb2YgdGhl IElDTSAxLjEgRUlBIGJhbGxvdGluZy4gIEhlIGhhcyBub3QgcmVjZWl2ZWQgYW55DQpjb25maXJt YXRpb24gb2YgdGhlIHZvdGUgcmVzdWx0cyB5ZXQ7IGhvd2V2ZXIsIHRoZSB1bm9mZmljaWFsIGNv dW50IHNob3dlZA0KdGhlIGJhbGxvdCBwYXNzaW5nIHVuYW5pbW91c2x5IHdpdGggMjIgbWVtYmVy cyB2b3RpbmcuICBSYW5keSBwbGFucyB0byBoYXZlDQphbiB1cGRhdGUgYXQgdGhlIG5leHQgbWVl dGluZyBpbmNsdWRpbmcgYW4gb2ZmaWNpYWwgdm90ZSBjb3VudCBhbmQgd29yZCBvZg0KY29udGlu dWluZyBhY3Rpdml0aWVzIHdpdGggc3VibWl0dGFsIG9mIElDTSAxLjEgZm9yIEFOU0kgYXBwcm92 YWwuDQoNCg0KU1VNTUlUUw0KDQotIERlc2lnbkNvbiBFYXN0IElCSVMgU3VtbWl0DQogIEJvYiBI YWxsZXIgcmVwb3J0ZWQgdGhhdCB0aGUgU3VtbWl0IHdlbnQgd2VsbCwgYnV0IGl0IHdvdWxkIGJl IGJldHRlciB0bw0KICBoYXZlIGEgbGFyZ2VyIGF1ZGllbmNlLiAgTm8gbG9naXN0aWNzIGlzc3Vl cyBhcm9zZS4gIE1pY2hhZWwgTWlybWFrDQogIGV4dGVuZGVkIHRoYW5rcyB0byBDYWRlbmNlLCBN ZW50b3IsIGFuZCBTaVNvZnQgZm9yIHRoZWlyIHNwb25zb3JzaGlwLiAgVGhlDQogIGJvb3RoIGhh cyBiZWVuIHJldHVybmVkIGFuZCBub3cgaW5jbHVkZXMgdGhlIElCSVMgYmFubmVyIGZyb20gTWlj aGFlbC4NCiAgQm9iIFJvc3MgbWVudGlvbmVkIHRvIEJvYiBIYWxsZXIgdGhhdCBoZSBuZWVkcyB0 byBzdWJtaXQgdGhlIGJpbGwgc29vbi4NCg0KLSBBc2lhbiBJQklTIFN1bW1pdA0KICBEZWNlbWJl ciA2LCAyMDA1IGlzIHRoZSBvZmZpY2lhbCBkYXRlIG9mIHRoZSBTdW1taXQuIEl0IHdpbGwgYmUg aGVsZCBhdA0KICB0aGUgQ3Jvd24gUGxhemEgSG90ZWwgaW4gU2hlbnpoZW4sIENoaW5hIG5lYXIg SG9uZyBLb25nLiAgVGhlIHN0ZWVyaW5nDQogIGNvbW1pdHRlZSBpcyBoZWFkZWQgYnkgSmlhbmcg WGlhbmcgWmhvbmcgb2YgSHVhd2VpLiAgT25lIHNwb25zb3IgZHJvcHBlZA0KICBvdXQsIGFuZCB0 aGUgZmluYW5jaWFsIHNwb25zb3JzIG5vdyBpbmNsdWRlIFNpZ3JpdHksIEh1YXdlaSwgQ2FkZW5j ZSwNCiAgTWVudG9yLCBhbmQgU2lTb2Z0LiAgQm9iIFJvc3MgcmVwb3J0ZWQgdGhhdCB0aGUgcHJv Z3JhbSBpcyBmdWxsLiAgVGhlcmUNCiAgYXJlIGZpdmUgcHJlc2VudGF0aW9ucyBmcm9tIEFzaWEg YW5kIHNldmVuIGZyb20gdGhlIFVTLiAgVGhlIGxpc3Qgb2YNCiAgcHJlc2VudGF0aW9ucyB3aWxs IGdvIG91dCBuZXh0IHdlZWsuDQoNClNwb25zb3JzaGlwIG9wcG9ydHVuaXRpZXMgZm9yIHRoZSBB c2lhbiBJQklTIFN1bW1pdCBhcmUgc3RpbGwgYXZhaWxhYmxlLA0Kd2l0aCBzcG9uc29ycyByZWNl aXZpbmcgZnJlZSBtZW50aW9ucyBpbiB0aGUgbWludXRlcywgYWdlbmRhLCBhbmQgb3RoZXINCmFu bm91bmNlbWVudHMuDQoNCg0KSUJJUyBRVUFMSVRZIENPTU1JVFRFRQ0KQm9iIEhhbGxlciByZXBv cnRlZCB0aGF0IHRoZSBjb21taXR0ZWUgbWV0IE9jdG9iZXIgNCBhbmQgdGhlIG5leHQgbWVldGlu ZyBpcw0KTm92ZW1iZXIgMS4gIFRoZXkgdGFsa2VkIG92ZXIgaG93IHZhcmlvdXMgY29tcGFuaWVz IGRvIHF1YWxpdHkgY2hlY2tzDQpjdXJyZW50bHkuICBUaGV5IHBsYW4gdG8gcmV2aWV3IE1pY2hh ZWwgTWlybWFrJ3MgZHJhZnQgcGFyc2VyIHNwZWNpZmljYXRpb24NCm5leHQgdGltZS4NCg0KVGhl IGxpbmsgdG8gdGhlIHF1YWxpdHkgY29tbWl0dGVlIGNoZWNrbGlzdCBpcyBhdDoNCg0KICAgaHR0 cDovL3d3dy5lZGEub3JnL3B1Yi9pYmlzL3F1YWxpdHlfd2lwLw0KDQoNCklCSVMgTU9ERUwgUkVW SUVXIENPTU1JVFRFRQ0KTHlubmUgR3JlZW4gcmVwb3J0ZWQgdGhhdCBubyBuZXcgbW9kZWxzIGhh dmUgYmVlbiByZWNlaXZlZCBpbiB0aGUgbGFzdCB0aHJlZQ0Kd2Vla3MuICBNb3N0IG1vZGVscyBj b21pbmcgaW4gYXJlIHVzaW5nIFMySUJJUzIgZm9yIG1vZGVsIGNyZWF0aW9uLCBhbmQgc2hlDQpp cyBlbmNvdXJhZ2luZyBwZW9wbGUgdG8gdXNlIFMySUJJUzMuICBCb2IgUm9zcyBtZW50aW9uZWQg dGhhdCB0aGVyZSBpcyBzb21lDQpjb25jZXJuIHdpdGggUzJJQklTMyBub3Qgd29ya2luZyB1bmRl ciBhbGwgTGludXggdmVyc2lvbnMuDQoNCg0KRlVUVVJFUyBBTkQgQ09PS0JPT0sgQ09NTUlUVEVF Uw0KTWljaGFlbCBNaXJtYWsgcmVwb3J0ZWQgdGhhdCB0aGVyZSB3ZXJlIG1lZXRpbmdzIG9mIGJv dGggY29tbWl0dGVlcyBvbmNlIHBlcg0Kd2VlayBvdmVyIHRoZSBsYXN0IHRocmVlIHdlZWtzLiAg RnV0dXJlcyBtZWV0aW5ncyBhcmUgYmVpbmcgaGVsZCBldmVyeSB3ZWVrDQp0byBmYWNpbGl0YXRl IEJJUkQ5NSBkaXNjdXNzaW9uLiAgVGhlcmUgaGF2ZSBiZWVuIG5vIG5ldyBkaXNjdXNzaW9ucyBv biB0aGUNCmNvb2tib29rIHNpbmNlIGl0IHdhcyByZWxlYXNlZC4gIEZ1dHVyZXMgZGlzY3Vzc2lv bnMgd2lsbCBiZSBvbiBwb3dlcg0KZGVsaXZlcnkgdG9waWNzIGZvciB0aGUgZm9yZXNlZWFibGUg ZnV0dXJlLg0KDQpSZWNlbnQgY29tbWl0dGVlIG1hdGVyaWFsIGlzIHN0b3JlZCBhdDoNCg0KICAg aHR0cDovL3d3dy5pYmlzLWluZm9ybWF0aW9uLm9yZy9mdXR1cmVzLw0KDQoNCk1BQ1JPTU9ERUxJ TkcgTElCUkFSWSBDT01NSVRURUUNCkFycGFkIE11cmFueWkgcmVwb3J0ZWQgdGhhdCB0aGV5IG1l dCBsYXN0IHdlZWsuICBBbGwgYnVmZmVyIHR5cGVzIGV4Y2VwdA0KRUNMIGFyZSBub3cgaW1wbGVt ZW50ZWQuICBUaGUgZmlyc3QgdmVyc2lvbiBvZiB0aGUgbGlicmFyeSBzaG91bGQgYmUNCmNvbXBs ZXRlZCBuZXh0IHdlZWsuICBBcnBhZCB3aWxsIG5lZWQgcGVvcGxlIHRvIHN0YXJ0IHVzaW5nIHRo ZSBsaWJyYXJ5LA0Kd3JpdGUgbWFjcm9tb2RlbCB0ZW1wbGF0ZXMsIGFuZCBlbmNvdXJhZ2UgdG9v bCB2ZW5kb3JzIHRvIGJlIGFibGUgdG8gcmVhZA0KdGhlc2UgbW9kZWxzLiAgQm9iIFJvc3MgbWVu dGlvbmVkIHRoYXQgdGhlIGVudGlyZSBsaWJyYXJ5IGlzIHN0cnVjdHVyZWQgYXMNCmFuYWxvZyBj b21wb25lbnRzIGZvciB1c2UgaW4gbm9uLUFNUyB0b29sIGVuZ2luZXMuICBBcnBhZCB3aWxsIGJl IHNvbGljaXRpbmcNCmZlZWRiYWNrIG9uIHRoZSBsaWJyYXJ5Lg0KDQpDb21taXR0ZWUgbWF0ZXJp YWwgY2FuIGJlIGZvdW5kIGF0IHRoZSBmb2xsb3dpbmcgdXJsOg0KDQogICAgICBodHRwOi8vd3d3 LmVkYS5vcmcvcHViL2liaXMvbWFjcm9tb2RlbF93aXAvDQoNCg0KTkVXIEFETUlOSVNUUkFUSVZF IElTU1VFUw0KQm9iIFJvc3MgbWVudGlvbmVkIHRoYXQgdGhlcmUgd2VyZSBlbWFpbHMgcmVjZW50 bHkgY29uY2VybmluZyBjb21waWxhdGlvbg0Kb2YgUzJJQklTMyBpbiBMaW51eCwgYW5kIGl0IHdv bid0IHdvcmsgaWYgeW91IGRvbid0IGhhdmUgdGhlIGxhdGVzdCB2ZXJzaW9uDQpvZiBKQVZBIGlu c3RhbGxlZC4gIEFtYnJpc2ggVmFybWEgd2lsbCBiZSBub3RpZmllZCBvZiB0aGVzZSBwcm9ibGVt cy4NCg0KDQpCSVJEOTUuNjogUE9XRVIgSU5URUdSSVRZIEFOQUxZU0lTIFVTSU5HIElCSVMNClN5 ZWQgSHVxIHJlcG9ydGVkIHRoYXQgdGhlcmUgd2VyZSBubyBhZGRpdGlvbmFsIHVwZGF0ZXMgdG8g dGhlIEJJUkQuICBIZQ0Kc3VtbWFyaXplZCB0aGF0IHRoaXMgQklSRCBoYXMgYmVlbiB3b3JrZWQg b24gc2luY2UgRGVjZW1iZXIgMjAwNC4gIFRoZSBCSVJEDQpzdGFydGVkIG91dCBtdWNoIGxhcmdl ciBhbmQgd2FzIGJyb2tlbiBkb3duIGV2ZW50dWFsbHkgdG8gdGFja2xlIGEgc21hbGxlcg0KcG9y dGlvbiBvZiBwb3dlciBkZWxpdmVyeSwgbmFtZWx5IFNTTiBzaW11bGF0aW9ucy4gIFN5ZWQgdGhh bmtlZCBldmVyeW9uZQ0KaW52b2x2ZWQgaW4gd29ya2luZyBvbiB0aGUgQklSRC4NCg0KQXJwYWQg TXVyYW55aSBhc2tlZCBhYm91dCBwZXJoYXBzIHJlLW9yZGVyaW5nIHRoZSBhZ2VuZGEgaW4gb3Jk ZXIgdG8gcHJlc2VudA0KaGlzIHNwZWNpYWwgdG9waWMgZmlyc3QsIGFzIGl0IGlzIHJlbGF0ZWQg dG8gcG93ZXIgZGVsaXZlcnkgaXNzdWVzLiAgTWljaGFlbA0KTWlybWFrIGFza2VkIHdoZXRoZXIg aXQgd291bGQgaGF2ZSBhIGRpcmVjdCByZWxhdGlvbiB0byB0aGUgQklSRDk1LjYgdm90ZS4NCkFy cGFkIGRpZCBub3QgdGhpbmsgaXQgd291bGQuICBTZXZlcmFsIG90aGVyIG1lbWJlcnMgZXhwcmVz c2VkIHRoYXQgdGhleQ0Kd291bGQgbGlrZSB0aGUgdm90ZSB0byBjb250aW51ZS4gIEFycGFkIHdh cyBhc2tlZCB0byBnaXZlIGEgcXVpY2sgc3VtbWFyeSBvZg0KaGlzIHByZXNlbnRhdGlvbi4gIEpv aG4gQW5ndWxvIG1lbnRpb25lZCB0aGF0IEFycGFkJ3MgcHJlc2VudGF0aW9uIHdhcw0KcmVsYXRl ZCB0byB0ZXN0IHNldHVwcyBvZiBCSVJEOTUuNiBldmFsdWF0aW9uLCBidXQgbm90IGRpcmVjdGx5 IHRvIHRoZSBCSVJELg0KSm9obiBhc2tlZCB0aGF0IENpc2NvIG1lbnRpb24gaG93IHRoZXkgaGFu ZGxlZCB0aGUgTWljcm9uIG1vZGVsIHRoYXQgaGFkDQptdWx0aXBsZSBwb3dlciBzdXBwbHkgY29u bmVjdGlvbnMuICBaaGlwaW5nIFlhbmcgc2FpZCB0aGF0IGlmIHlvdSB3ZXJlIG9ubHkNCmludGVy ZXN0ZWQgaW4gdGhlIHBvd2VyIHN1cHBseSBjb25uZWN0ZWQgZGlyZWN0bHkgdG8gdGhlIGJ1ZmZl ciBkcml2ZXINCnRyYW5zaXN0b3JzLCB0aGUgQklSRCBpcyBvay4gIElmIHlvdSBhcmUgaW50ZXJl c3RlZCBpbiBub2lzZSBvbiB0aGUgb3RoZXINCnBvd2VyIHN1cHBsaWVzLCB0aGVuIGl0IGRvZXMg bm90IHRlbGwgeW91IHRoaXMgaW5mb3JtYXRpb24uICBaaGlwaW5nIHNhaWQNCnRoYXQgaXQgaXMg aW1wb3J0YW50IHRvIGhvb2sgdXAgdGhlIG90aGVyIHBvd2VyIHN1cHBsaWVzIGNvcnJlY3RseSBp biBIU1BJQ0UNCnNvIHRoYXQgdGhleSBkbyBub3QgaW50cm9kdWNlIG5vaXNlIGludG8gdGhlIGRy aXZlciBzdXBwbHksIG90aGVyd2lzZSB5b3UNCmNhbiBub3QgY29ycmVsYXRlIGJldHdlZW4gSFNQ SUNFIGFuZCBJQklTLiAgSm9obiBzYWlkIHRoYXQgdGhlIHF1ZXN0aW9uIGlzDQp3aGV0aGVyIHRo aXMgQklSRCB3b3VsZCBjb3ZlciBtb3N0IGJ1ZmZlcnMgb3Igb25seSBhIGZldy4gIFpoaXBpbmcg ZmVsdCB0aGF0DQphZGRpdGlvbmFsIEktdCB0YWJsZXMgY291bGQgYmUgaW50cm9kdWNlZCBpbiB0 aGUgZnV0dXJlIHRvIGNvdmVyIGZ1dHVyZQ0KYnVmZmVycy4gIEFycGFkIHNhaWQgdGhhdCBpbiBs aWdodCBvZiBtYWNyb21vZGVsaW5nIHdvcmssIHRoaXMgY291bGQNCnByb2JhYmx5IGJlIG1vZGVs ZWQgd2l0aG91dCBJQklTIHNwZWNpZmljYXRpb24gY2hhbmdlcyB1c2luZyBtYWNyb21vZGVscy4N ClN5ZWQgZmVsdCB0aGF0IHRoaXMgcHJvcG9zYWwgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIElCSVMg c3BlY2lmaWNhdGlvbiBzbw0KdGhhdCB0aGVyZSBjb3VsZCBiZSBtdWx0aXBsZSB3YXlzIG9mIG1v ZGVsaW5nIHRoZXNlIGVmZmVjdHMuICBBbWJyaXNoIFZhcm1hDQphc2tlZCBhYm91dCB3aGV0aGVy IHRoZSBJLXQgdGFibGUgdmFsdWVzIGNvdWxkIGJlIG1lYXN1cmVkIGluIHRoZSBsYWIuDQpaaGlw aW5nIHNhaWQgdGhhdCBpdCB3b3VsZCBiZSBkaWZmaWN1bHQgaWYgdGhlIEkvT3MgYW5kIHRoZSBj b3JlIHNoYXJlZCB0aGUNCnNhbWUgcG93ZXIgc3VwcGx5LiAgSm9obiBBbmd1bG8gbWVudGlvbmVk IHRoYXQgdGhpcyBCSVJEIGRvZXMgbm90IGNvbXBsZXRlbHkNCnNvbHZlIHBvd2VyIHN1cHBseSBt b2RlbGluZyBpc3N1ZXMsIGFuZCBpdCB3aWxsIGhhdmUgdG8gYmUgc3VwcGxlbWVudGVkIGJ5DQpv dGhlciBCSVJEcy4gIExhbmNlIFdhbmcgY29tbWVudGVkIHRoYXQgaGUgZGlkIG5vdCBsaWtlIHRo ZSBpZGVhIG9mIGJyZWFraW5nDQpwb3dlciBkZWxpdmVyeSBpc3N1ZXMgdXAgaW50byBzbWFsbGVy IHBpZWNlczsgdGhhdCBoZSB3b3VsZCBsaWtlIHRvIHNlZSBvbmUNCmNvbXBsZXRlIHNvbHV0aW9u LiAgU3llZCBtZW50aW9uZWQgdGhhdCB0aGlzIEJJUkQgaGFkIHN0YXJ0ZWQgb3V0IG1vZGVsaW5n DQptYW55IGVmZmVjdHMgYW5kIHdhcyBwdXJwb3NlbHkgYnJva2VuIGRvd24gaW50byBzbWFsbGVy IHBpZWNlcy4NCg0KVGhlcmUgd2FzIGEgY2FsbCBmb3Igdm90ZSBvbiBhcHByb3ZhbCBvZiB0aGUg QklSRCB0ZXh0IGZvciBpbmNsdXNpb24gaW4gYQ0KZnV0dXJlIHZlcnNpb24gb2YgdGhlIElCSVMg c3BlY2lmaWNhdGlvbi4gIFRoZSB2b3RlIHBhc3NlZCB3aXRoIHRoZQ0KZm9sbG93aW5nIHZvdGUg dGFsbHk6DQoNCkFnZXJlICAgICAtIGFic3RhaW4NCkFNRCAgICAgICAtIHllcw0KQ2FkZW5jZSAg IC0gbm8NCkNpc2NvICAgICAtIHllcw0KRmx1ZW50ICAgIC0geWVzDQpHcmVlbiAgICAgLSB5ZXMN CkludGVsICAgICAtIGFic3RhaW4NCk1hcnZlbGwgICAtIHllcw0KTWVudG9yICAgIC0geWVzDQpN aWNyb24gICAgLSBhYnN0YWluDQpORUMgICAgICAgLSB5ZXMNClNpZW1lbnMgICAtIHllcw0KU2lz b2Z0ICAgIC0geWVzDQpTaWdyaXR5ICAgLSB5ZXMNClN5bm9wc3lzICAtIHllcw0KVGVyYXNwZWVk IC0geWVzDQpUSSAgICAgICAgLSB5ZXMNClhpbGlueCAgICAtIHllcw0KDQoNClNQRUNJQUwgVE9Q SUM6IFBIQVNFIERFTEFZIEFORCBQT1dFUiBERUxJVkVSWQ0KQXJwYWQgTXVyYW55aSBwcmVzZW50 ZWQgc29tZSBtYXRlcmlhbCBvbiBhbiBleHBlcmltZW50IHJlbGF0ZWQgdG8gZ2F0ZQ0KbW9kdWxh dGlvbi4gIEFycGFkIHVzZWQgaGlzICJJQklTIGNsYXNzIiB0cmFuc2lzdG9yIG1vZGVsIHRvIGxv b2sgYXQgZ2F0ZQ0KbW9kdWxhdGlvbi4gIEx5bm5lIEdyZWVuIGFza2VkIGFib3V0IHRoZSBidWxr IG5vZGUgb2YgdGhlIHRyYW5zaXN0b3JzLg0KQXJwYWQgcmVzcG9uZGVkIHRoYXQgdGhpcyBub2Rl IHdhcyBhbHdheXMgdGllZCB0byB0aGUgcmVzcGVjdGl2ZSBkaWUgcG93ZXINCm9yIGRpZSBncm91 bmQuIEFycGFkIGludmVzdGlnYXRlZCB0aGUgcmVzcG9uc2Ugb2YgdGhlIG91dHB1dCBub2RlIGFu ZCB0aGUNCmdhdGUgdm9sdGFnZSBub2RlIHdpdGggYSBzdXBwbHkgdm9sdGFnZSBjaGFuZ2luZyBi eSBvbmUgdm9sdCBvdmVyIHZhcmlvdXMNCnJhbXAgcmF0ZXMuICBIaXMgY29uY2x1c2lvbnMgd2Vy ZSB0aGF0IHRoZSBvdXRwdXQgdHJhbnNpc3RvcnMgZG8gbm90IGZvbGxvdw0KcmFwaWQgc3VwcGx5 IHZvbHRhZ2UgdmFyaWF0aW9ucyBpbnN0YW50YW5lb3VzbHksIHNvIHRoZSBnYXRlIG1vZHVsYXRp b24NCmVmZmVjdCBjYW5ub3QgYmUgbW9kZWxlZCBieSBEQyBtZWFzdXJlbWVudHMgYWxvbmUuICBT bywgdGhlIEFDIGVmZmVjdHMgbmVlZA0KdG8gYmUgaW5jbHVkZWQgaW4gQklSRDk3Lzk4IGJlZm9y ZSB0aGVzZSBCSVJEcyBjYW4gYmUgY29tcGxldGVkLg0KDQpBcnBhZCdzIHByZXNlbnRhdGlvbiBj YW4gYmUgZm91bmQgYXQgdGhlIGZvbGxvd2luZyBsaW5rOg0KDQpodHRwOi8vd3d3LmVkYS5vcmcv aWJpcy9mdXR1cmVzL1F1aWV0X2xpbmVfZXhwZXJpbWVudC5wZGYNCg0KDQpCSVJEOTcuMjogR0FU RSBNT0RVTEFUSU9OIEVGRkVDVA0KTm8gZGlzY3Vzc2lvbiAtIHNlZSB0aGUgc3BlY2lhbCB0b3Bp YyBhYm92ZS4NCg0KDQpCSVJEOTg6IEdBVEUgTU9EVUxBVElPTiBFRkZFQ1QgKFRBQkxFIEZPUk1B VCkNClNlZSBCSVJEOTcuMiBmb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIEJJUkQ5OC4NCg0KDQpJ QklTQ0hLNCBCVUcgU1RBVFVTDQpObyBuZXcgQlVHcyB0byBkaXNjdXNzLg0KDQoNCklDTUNISzEg QlVHIFNUQVRVUw0KTm8gbmV3IEJVR3MgdG8gZGlzY3Vzcy4NCg0KDQoNCk5FVyBURUNITklDQUwg SVNTVUVTDQpOb25lLg0KDQoNCk5FWFQgTUVFVElORw0KVGhlIG5leHQgSUJJUyBPcGVuIEZvcnVt IHRlbGVjb25mZXJlbmNlIHdpbGwgYmUgaGVsZCBPY3RvYmVyIDI4LCAyMDA1IGZyb20NCjg6MDAg QU0gdG8gMTA6MDAgQU0gVVMgUGFjaWZpYyBUaW1lLg0KDQoNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOT1RFUw0KDQpJQklTIENIQUlSOiBNaWNo YWVsIE1pcm1hayAoOTE2KSAzNTYtNDI2MSwgRmF4OiAoOTE2KSAzNzctMTA0Ng0KICAgICAgICAg ICAgbWljaGFlbC5taXJtYWtAaW50ZWwuY29tDQogICAgICAgICAgICBTZW5pb3IgQW5hbG9nIEVu Z2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbg0KICAgICAgICAgICAgRk02LTQ1DQogICAgICAgICAg ICAxOTAwIFByYWlyaWUgQ2l0eSBSZC4NCiAgICAgICAgICAgIEZvbHNvbSwgQ0EgIDk1NjMwDQoN ClZJQ0UgQ0hBSVI6IFN5ZWQgSHVxICg0MDgpIDUyNS0zMzk5LCBGYXg6ICg0MDgpIDUyNi01NTA0 DQogICAgICAgICAgICBzaHVxQGNpc2NvLmNvbQ0KICAgICAgICAgICAgTWFuYWdlciwgSGFyZHdh cmUgRW5naW5lZXJpbmcsIENpc2NvIFN5c3RlbXMNCiAgICAgICAgICAgIDE3MCBXZXN0IFRhc21h biBEcml2ZQ0KICAgICAgICAgICAgU2FuIEpvc2UsIENBIDk1MTM0LTE3MDYNCg0KU0VDUkVUQVJZ OiAgUmFuZHkgV29sZmYgKDIwOCkgMzYzLTE3NjQsIEZheDogKDIwOCkgMzY4LTM0NzUNCiAgICAg ICAgICAgIHJyd29sZmZAbWljcm9uLmNvbQ0KICAgICAgICAgICAgU2ltdWxhdGlvbiBFbmdpbmVl ciwgTWljcm9uIFRlY2hub2xvZ3ksIEluYy4NCiAgICAgICAgICAgIDgwMDAgUy4gRmVkZXJhbCBX YXkNCiAgICAgICAgICAgIE1haWwgU3RvcDogMDEtNzExDQogICAgICAgICAgICBCb2lzZSwgSUQg ODM3MDctMDAwNg0KDQpMSUJSQVJJQU46ICBMYW5jZSBXYW5nICg5NzgpIDI2Mi02Njg1LCBGYXg6 ICg5NzgpIDI2Mi02MzYzDQogICAgICAgICAgICBsd2FuZ0BjYWRlbmNlLmNvbQ0KICAgICAgICAg ICAgU2VuaW9yIE1lbWJlciwgVGVjaG5pY2FsIFN0YWZmLCBDYWRlbmNlIERlc2lnbiBTeXN0ZW1z LCBJbmMuDQogICAgICAgICAgICAyNzAgQmlsbGVyaWNhIFJvYWQNCiAgICAgICAgICAgIENoZWxt c2ZvcmQsIE1BIDAxODI0DQoNCldFQk1BU1RFUjogIFN5ZWQgSHVxICg0MDgpIDUyNS0zMzk5LCBG YXg6ICg0MDgpIDUyNi01NTA0DQogICAgICAgICAgICBzaHVxQGNpc2NvLmNvbQ0KICAgICAgICAg ICAgTWFuYWdlciwgSGFyZHdhcmUgRW5naW5lZXJpbmcsIENpc2NvIFN5c3RlbXMNCiAgICAgICAg ICAgIDE3MCBXZXN0IFRhc21hbiBEcml2ZQ0KICAgICAgICAgICAgU2FuIEpvc2UsIENBIDk1MTM0 LTE3MDYNCg0KUE9TVE1BU1RFUjogQm9iIFJvc3MgKDUwMykgMjQ2LTgwNDgsIEZheCA6ICg1MDMp IDIzOS00NDAwDQogICAgICAgICAgICBib2JAdGVyYXNwZWVkLmNvbQ0KICAgICAgICAgICAgU3Rh ZmYgU2NpZW50aXN0LCBUZXJhc3BlZWQgQ29uc3VsdGluZyBHcm91cA0KICAgICAgICAgICAgMTAy MzggU1cgTGFuY2FzdGVyIFJvYWQNCiAgICAgICAgICAgIFBvcnRsYW5kLCBPUiA5NzIxOQ0KDQoN ClRoaXMgbWVldGluZyB3YXMgY29uZHVjdGVkIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgR0VJQSBM ZWdhbCBHdWlkZXMgYW5kDQpHRUlBIE1hbnVhbCBvZiBPcmdhbml6YXRpb24gYW5kIFByb2NlZHVy ZS4NCg0KVGhlIGZvbGxvd2luZyBlLW1haWwgYWRkcmVzc2VzIGFyZSB1c2VkOg0KDQogIG1ham9y ZG9tb0BlZGEub3JnDQogICAgICBJbiB0aGUgYm9keSwgZm9yIHRoZSBJQklTIE9wZW4gRm9ydW0g UmVmbGVjdG9yOg0KICAgICAgc3Vic2NyaWJlIGliaXMgPHlvdXIgZS1tYWlsIGFkZHJlc3M+DQoN CiAgICAgIEluIHRoZSBib2R5LCBmb3IgdGhlIElCSVMgVXNlcnMnIEdyb3VwIFJlZmxlY3RvcjoN CiAgICAgIHN1YnNjcmliZSBpYmlzLXVzZXJzIDx5b3VyIGUtbWFpbCBhZGRyZXNzPg0KDQogICAg ICBIZWxwIGFuZCBvdGhlciBjb21tYW5kczoNCiAgICAgIGhlbHANCg0KICBpYmlzLXJlcXVlc3RA ZWRhLm9yZw0KICAgICAgVG8gam9pbiwgY2hhbmdlLCBvciBkcm9wIGZyb20gZWl0aGVyIHRoZSBJ QklTIE9wZW4gRm9ydW0gUmVmbGVjdG9yDQogICAgICAoaWJpc0BlZGEub3JnKSwgdGhlIElCSVMg VXNlcnMnIEdyb3VwIFJlZmxlY3Rvcg0KICAgICAgKGliaXMtdXNlcnNAZWRhLm9yZykgb3IgYm90 aC4gIFN0YXRlIHlvdXIgcmVxdWVzdC4NCg0KICBpYmlzLWluZm9AZWRhLm9yZw0KICAgICAgVG8g b2J0YWluIGdlbmVyYWwgaW5mb3JtYXRpb24gYWJvdXQgSUJJUywgdG8gYXNrIHNwZWNpZmljDQog ICAgICBxdWVzdGlvbnMgZm9yIGluZGl2aWR1YWwgcmVzcG9uc2UsIGFuZCB0byBpbnF1aXJlIGFi b3V0IGpvaW5pbmcNCiAgICAgIHRoZSBFSUEtSUJJUyBPcGVuIEZvcnVtIGFzIGEgZnVsbCBNZW1i ZXIuDQoNCiAgaWJpc0BlZGEub3JnDQogICAgICBUbyBzZW5kIGEgbWVzc2FnZSB0byB0aGUgZ2Vu ZXJhbCBJQklTIE9wZW4gRm9ydW0gUmVmbGVjdG9yLiAgVGhpcw0KICAgICAgaXMgdXNlZCBtb3N0 bHkgZm9yIElCSVMgU3RhbmRhcmRpemF0aW9uIGJ1c2luZXNzIGFuZCBmdXR1cmUgSUJJUw0KICAg ICAgdGVjaG5pY2FsIGVuaGFuY2VtZW50cy4gIEpvYiBwb3N0aW5nIGluZm9ybWF0aW9uIGlzIG5v dCBwZXJtaXR0ZWQuDQoNCiAgaWJpcy11c2Vyc0BlZGEub3JnDQogICAgICBUbyBzZW5kIGEgbWVz c2FnZSB0byB0aGUgSUJJUyBVc2VycycgR3JvdXAgUmVmbGVjdG9yLiAgVGhpcyBpcw0KICAgICAg dXNlZCBtb3N0bHkgZm9yIElCSVMgY2xhcmlmaWNhdGlvbiwgY3VycmVudCBtb2RlbGluZyBpc3N1 ZXMsIGFuZA0KICAgICAgZ2VuZXJhbCB1c2VyIGNvbmNlcm5zLiAgSm9iIHBvc3RpbmcgaW5mb3Jt YXRpb24gaXMgbm90IHBlcm1pdHRlZC4NCg0KICBpYmlzLWJ1Z0BlZGEub3JnDQogICAgICBUbyBy ZXBvcnQgaWJpc2NoayBwYXJzZXIgYnVncy4gIFRoZSBCdWcgUmVwb3J0IEZvcm0gUmVzaWRlcyBv bg0KICAgICAgZWRhLm9yZyBpbiAvcHViL2liaXMvYnVncy9pYmlzX2J1Z3MvYnVnZm9ybS50eHQg YWxvbmcgd2l0aA0KICAgICAgcmVwb3J0ZWQgYnVncy4NCg0KICBpY20tYnVnQGVkYS5vcmcNCiAg ICAgIFRvIHJlcG9ydCBpY21jaGsxIHBhcnNlciBidWdzLiAgVGhlIEJ1ZyBSZXBvcnQgRm9ybSBS ZXNpZGVzIG9uDQogICAgICBlZGEub3JnIGluIC9wdWIvaWJpcy9idWdzL2ljbV9idWdzL2ljbV9i dWdmb3JtLnR4dCBhbG9uZyB3aXRoDQogICAgICByZXBvcnRlZCBidWdzLg0KDQogICAgICBUbyBy ZXBvcnQgczJpYmlzLCBzMmliaXMyIGFuZCBzMmlwbHQgYnVncywgdXNlIHRoZSBCdWcgUmVwb3J0 DQogICAgICBGb3JtcyB3aGljaCByZXNpZGUgdW5kZXIgZWRhLm9yZyBpbg0KICAgICAgL3B1Yi9p YmlzL2J1Z3MvczJpYmlzL2J1Z3MyaS50eHQsDQogICAgICAvcHViL2liaXMvYnVncy9zMmliaXMy L2J1Z3MyaTIudHh0IGFuZA0KICAgICAgL3B1Yi9pYmlzL2J1Z3MvczJpcGx0L2J1Z3NwbHQudHh0 IHJlc3BlY3RpdmVseS4NCg0KSW5mb3JtYXRpb24gb24gSUJJUyB0ZWNobmljYWwgY29udGVudHMs IElCSVMgcGFydGljaXBhbnRzIGFuZCBhY3R1YWwNCklCSVMgbW9kZWxzIGFyZSBhdmFpbGFibGUg b24gdGhlIElCSVMgSG9tZSBwYWdlOg0KDQogIGh0dHA6Ly93d3cuZWlncm91cC5vcmcvaWJpcy9p YmlzLmh0bQ0KDQpDaGVjayB0aGUgSUJJUyBmaWxlIGRpcmVjdG9yeSBvbiBlZGEub3JnIGZvciBt b3JlIGluZm9ybWF0aW9uIG9uDQpwcmV2aW91cyBkaXNjdXNzaW9ucyBhbmQgcmVzdWx0czoNCg0K ICBodHRwOi8vd3d3LmVkYS5vcmcvcHViL2liaXMvZGlyZWN0b3J5Lmh0bWwNCg0KQWxsIGVkYS5v cmcgZG9jdW1lbnRzIGNhbiBiZSBhY2Nlc3NlZCB1c2luZyBhIG1pcnJvcjoNCg0KICBodHRwOi8v d3d3LmliaXMtaW5mb3JtYXRpb24ub3JnDQoNCk5vdGUgdGhhdCB0aGUgInB1Yi9pYmlzIiB0ZXh0 IHNob3VsZCBiZSByZW1vdmVkIGZyb20gZGlyZWN0b3J5IG5hbWVzDQp3aGVuIHRoaXMgVVJMIG1p cnJvciBpcyB1c2VkLg0KDQoqIE90aGVyIHRyYWRlbWFya3MsIGJyYW5kcyBhbmQgbmFtZXMgYXJl IHRoZSBwcm9wZXJ0eSBvZg0KICB0aGVpciByZXNwZWN0aXZlIG93bmVycy4NCg0K - ------_=_NextPart_001_01C5D002.0D775A01-- |------------------------------------------------------------------ |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 Oct 2005 09:03:46 +0530 From: "Vivek Kumar Sundriyal" Subject: [IBIS-Users] VMeas, Rref, Rload parameters Hi all , Some basic questions. Can anyone elaborate more on the Vmeas, Rref and Rload parameter ? The IBIS documentation describes : [Vmeas] : Defines the reference voltage level for board-level timing simulation. [Rref] : Defines the resistive load used when specifying the propagation delay or output switching time. [Rload] : Describes the load resistance to use when performing the simulations for the ramp rate data. But could not get what exactly this means. Any help on this will be appriciated. 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: Thu, 13 Oct 2005 21:24:59 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] VMeas, Rref, Rload parameters Vivek These parameters are found in the datasheet. They are the timing test load. When the manufacturer publishes the propagation delays, etc. these delays have to be into a known load. These parameters are the known load. Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Vivek Kumar Sundriyal Sent: Thursday, October 13, 2005 8:34 PM To: ibis-users@eda.org Subject: [IBIS-Users] VMeas, Rref, Rload parameters Hi all , Some basic questions. Can anyone elaborate more on the Vmeas, Rref and Rload parameter ? The IBIS documentation describes : [Vmeas] : Defines the reference voltage level for board-level timing simulation. [Rref] : Defines the resistive load used when specifying the propagation delay or output switching time. [Rload] : Describes the load resistance to use when performing the simulations for the ramp rate data. But could not get what exactly this means. Any help on this will be appriciated. 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: Mon, 17 Oct 2005 16:13:47 -0700 From: "Ray Anderson" Subject: [IBIS-Users] Per-Pin Distributed RLC Support This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5D370.6DED9179 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In reviewing a large sampling of IBIS models from numerous vendors I have yet to find any that implement the distributed RLC format as described in the [Pin Numbers] section of the IBIS spec. (pages 117-120 in the 4.1 spec) =20 I was wondering if anyone is aware of any published models that take advantage of this method of describing package parasitics. =20 Regards, =20 - -Ray =20 =20 Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Department Advanced Package R&D Xilinx Inc. =20 =20 - ------_=_NextPart_001_01C5D370.6DED9179 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

In reviewing a large sampling of IBIS models from = numerous vendors I have yet to find any that implement the distributed RLC format = as described in the [Pin Numbers] section of the IBIS spec. (pages 117-120 = in the 4.1 spec)

 

I was wondering if anyone is aware of any published = models that take advantage of this method of describing package = parasitics.

 

Regards,

 

-Ray

 

 

Raymond = Anderson

Senior Signal Integrity Staff Engineer

Product = Technology Department

Advanced = Package R&D

Xilinx = Inc.

 <= /p>

 

- ------_=_NextPart_001_01C5D370.6DED9179-- |------------------------------------------------------------------ |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, 18 Oct 2005 00:01:43 +0000 From: "lau yy" Subject: [IBIS-Users] regarding the rising n falling waveform again
Dear Tom,
 
Is me agian, the guy who asking the rising/falling waveform.
 
This time, I facing another problem, and wish to have your opinion. The recent model that I build, where having pullup problem. The problem is no mather how I change the IN and EN of my IO pins, I cant get the dv/dt_r in positive value although I set my model as I/O_OPEN_SINK.
 
For the falling waveform, although is look fine but also fail for the checker for 0v references.
 
The rising waveform is not working for 0v references and vcc references. The data is state at some value, it do change in a small scale but not showing a rising.
 
Is my model got problem or the circuit itself got problem? or there were other problems?
 
Below were my setting :
[Model] IO0
[Model type] I/O_open_sink
[Power clamp reference] 3.00 2.70 3.60
[Gnd clamp reference]   0   0   0
[Pullup reference]      3.00 2.70 3.60
[Pulldown reference]    0   0   0
[Rising waveform] 500 0 0 0 NA NA NA NA NA
[Rising waveform] 500 3.00 2.70 3.60 NA NA NA NA NA
[Falling waveform] 500 0 0 0 NA NA NA NA NA
[Falling waveform] 500 3.00 2.70 3.60 NA NA NA NA NA
[Vinl] 0.8
[Vinh] 2.10
[Cref] 30pF
[Vmeas] 1.50
[Rload] 50
[Model file] hsp.mod hspmin.mod hspmax.mod
Here, my ramp data :
[Ramp]
| variable       typ                 min                 max
dV/dt_r          -0.6000m/-0.2000n  -1.2000m/0.4000n  -0.6000m/-0.2000n
dV/dt_f          0.7236/2.6060n      0.4002/4.0761n      1.3476/1.4710n
 
ANd here the error message of my Falling waveform :
 
ERROR - Model IO0: The [Falling Waveform]
      with [R_fixture]=500 Ohms and [V_fixture_max]=0V
      has MAX column DC endpoints of  0.00V and  3.40v, but
      an equivalent load applied to the model's I-V tables yields
      different voltages ( 0.00V and  0.00V),
      a difference of 100.00% and 178015.78%, respectively.
 
 
Thanks
 
rdgs
yylau
|------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 17 Oct 2005 17:37:12 -0700 From: "Tom Dagostino" Subject: [IBIS-Users] RE: regarding the rising n falling waveform again This is a multi-part message in MIME format. - ------=_NextPart_000_003E_01C5D341.6840A850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Well, lets think about this buffer for a moment. From your file it calls this buffer: [Model type] I/O_open_sink An open sink buffer does not have a pullup device. The drain (collector) node of the pulldown device is not connected to a pullup device. So, there is no source of current pulling the load up to Vdd. So, if you have a resistance tied to ground such as the 500 Ohm resistor in your example and the pulldown device is on you will have both sides of the resistor at ground potential. If the pulldown device is off then the ground side of the resistor is grounded and the end tied to the buffer is now floating. There is nothing to pull that node to any other voltage other than ground. Conversely, if your 500 Ohm load is tied to Vdd then the pulldown device can make one end of the resistor approach ground potential while the end of the resistor tied to Vdd will remain at Vdd. So, you should see transitions when the load is tied to Vdd but you cannot see any transitions when the load is tied to ground. For the grounded load to have a transition you need to have a path from the power supply through the load to ground and back through the power supply. In electronics there must be a complete circuit of some kind for current to flow. Since the impedance between the supply to the load resistor is high (read open circuit) there is no where for the electrons to flow. Conversely one could compute the current as I = E/R. In your case E = 3.00 Volts in the typical case but the R is an open circuit - R is close to infinity. Thus the current is close to zero. Thus from Ohms Law again (E = IR) 0.0000000000000A * 500 Ohms = 0.000 Volts. 99.9999% of the open sink buffers I have seen do not have a powerclamp or a pullup thus there is no need for the powerclamp or pullup references. Since there is no pullup you do not need to have these two lines: [Rising waveform] 500 0 0 0 NA NA NA NA NA [Falling waveform] 500 0 0 0 NA NA NA NA NA For the ramp section IBIS will take the dV/dT_r from the load to ground and will take the dV/dT_f from the load to Vdd in a push pull buffer. Since you told the conversion program there was rising falling waveforms with the load terminated to ground the program is taking the data that cannot be. If these two lines are not present then for this buffer the dV/dT_r and dV/dT_f will be taken from the rising terminated to Vdd and falling terminated to Vdd. Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 -----Original Message----- From: lau yy [mailto:tok47@hotmail.com] Sent: Monday, October 17, 2005 5:02 PM To: tom@teraspeed.com; ibis-users@eda.org Subject: regarding the rising n falling waveform again Dear Tom, Is me agian, the guy who asking the rising/falling waveform. This time, I facing another problem, and wish to have your opinion. The recent model that I build, where having pullup problem. The problem is no mather how I change the IN and EN of my IO pins, I cant get the dv/dt_r in positive value although I set my model as I/O_OPEN_SINK. For the falling waveform, although is look fine but also fail for the checker for 0v references. The rising waveform is not working for 0v references and vcc references. The data is state at some value, it do change in a small scale but not showing a rising. Is my model got problem or the circuit itself got problem? or there were other problems? Below were my setting : [Model] IO0 [Model type] I/O_open_sink [Power clamp reference] 3.00 2.70 3.60 [Gnd clamp reference] 0 0 0 [Pullup reference] 3.00 2.70 3.60 [Pulldown reference] 0 0 0 [Rising waveform] 500 0 0 0 NA NA NA NA NA [Rising waveform] 500 3.00 2.70 3.60 NA NA NA NA NA [Falling waveform] 500 0 0 0 NA NA NA NA NA [Falling waveform] 500 3.00 2.70 3.60 NA NA NA NA NA [Vinl] 0.8 [Vinh] 2.10 [Cref] 30pF [Vmeas] 1.50 [Rload] 50 [Model file] hsp.mod hspmin.mod hspmax.mod Here, my ramp data : [Ramp] | variable typ min max dV/dt_r -0.6000m/-0.2000n -1.2000m/0.4000n -0.6000m/-0.2000n dV/dt_f 0.7236/2.6060n 0.4002/4.0761n 1.3476/1.4710n ANd here the error message of my Falling waveform : ERROR - Model IO0: The [Falling Waveform] with [R_fixture]=500 Ohms and [V_fixture_max]=0V has MAX column DC endpoints of 0.00V and 3.40v, but an equivalent load applied to the model's I-V tables yields different voltages ( 0.00V and 0.00V), a difference of 100.00% and 178015.78%, respectively. Thanks rdgs yylau - ------=_NextPart_000_003E_01C5D341.6840A850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Well,=20 lets think about this buffer for a moment.  From your file it calls = this=20 buffer:
 
[Model type]=20 I/O_open_sink
An=20 open sink buffer does not have a pullup device.  The drain = (collector)=20 node of the pulldown device is not connected to a pullup = device.  So,=20 there is no source of current pulling the load up to Vdd. =20
 
So, if=20 you have a resistance tied to ground such as the 500 Ohm resistor in = your=20 example and the pulldown device is on you will have both sides of the = resistor=20 at ground potential. If the pulldown device is off then the  ground = side of=20 the resistor is grounded and the end tied to the buffer is now = floating. =20 There is nothing to pull that node to any other voltage other than = ground. =20
 
Conversely, if your 500 Ohm load is tied to Vdd then the = pulldown device=20 can make one end of the resistor approach ground potential while the end = of the=20 resistor tied to Vdd will remain at Vdd.  So, you should see = transitions=20 when the load is tied to Vdd but you cannot see any transitions when the = load is=20 tied to ground. 
 
For=20 the grounded load to have a transition you need to have a path from the = power=20 supply through the load to ground and back through the power = supply.  In=20 electronics there must be a complete circuit of some kind for current to = flow.  Since the impedance between the supply to the load = resistor is=20 high (read open circuit) there is no where for the electrons to = flow. =20 Conversely one could compute the current as I =3D E/R.  In your = case E =3D 3.00=20 Volts in the typical case but the R is an open circuit - R is close to=20 infinity.  Thus the current is close to zero.  Thus from Ohms = Law=20 again (E =3D IR) 0.0000000000000A * 500 Ohms =3D 0.000 = Volts.
 
99.9999% of the open sink buffers I have seen do not have a = powerclamp or=20 a pullup thus there is no need for the powerclamp or pullup=20 references.
 
Since=20 there is no pullup you do not need to have these two = lines:
 
[Rising waveform] 500 0 0 0 NA NA = NA NA=20 NA
[Falling waveform] 500 0 0 0 NA NA = NA NA=20 NA
 
For=20 the ramp section IBIS will take the dV/dT_r from the load to ground and = will=20 take the dV/dT_f from the load to Vdd in a push pull buffer. Since you = told the=20 conversion program there was rising falling waveforms with the load = terminated=20 to ground the program is taking the data that cannot be.  If these = two=20 lines are not present then for this buffer the dV/dT_r and dV/dT_f will = be taken=20 from the rising terminated to Vdd and falling terminated to=20 Vdd.

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

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

-----Original Message-----
From: lau yy=20 [mailto:tok47@hotmail.com]
Sent: Monday, October 17, 2005 = 5:02=20 PM
To: tom@teraspeed.com; = ibis-users@eda.org
Subject:=20 regarding the rising n falling waveform again

Dear Tom,
 
Is me agian, the guy who asking the rising/falling=20 waveform.
 
This time, I facing another problem, and wish to have = your=20 opinion. The recent model that I build, where having pullup problem. = The=20 problem is no mather how I change the IN and EN of my IO pins, I = cant get=20 the dv/dt_r in positive value although I set my model as = I/O_OPEN_SINK.
 
For the falling waveform, although is look fine but = also fail=20 for the checker for 0v references.
 
The rising waveform is not working for 0v references = and vcc=20 references. The data is state at some value, it do change in a small = scale but=20 not showing a rising.
 
Is my model got problem or the circuit itself got = problem? or=20 there were other problems?
 
Below were my setting :
[Model] IO0
[Model type] I/O_open_sink
[Power = clamp=20 reference] 3.00 2.70 3.60
[Gnd clamp reference]   = 0  =20 0   0
[Pullup reference]      = 3.00 2.70=20 3.60
[Pulldown reference]    0   = 0  =20 0
[Rising waveform] 500 0 0 0 NA NA NA NA NA
[Rising waveform] = 500 3.00=20 2.70 3.60 NA NA NA NA NA
[Falling waveform] 500 0 0 0 NA NA NA NA=20 NA
[Falling waveform] 500 3.00 2.70 3.60 NA NA NA NA NA
[Vinl]=20 0.8
[Vinh] 2.10
[Cref] 30pF
[Vmeas] 1.50
[Rload] = 50
[Model=20 file] hsp.mod hspmin.mod hspmax.mod
Here, my ramp data :
[Ramp]
| = variable      =20 = typ           &nbs= p;    =20 = min           &nbs= p;    =20 max
dV/dt_r         =20 -0.6000m/-0.2000n  -1.2000m/0.4000n =20 = - -0.6000m/-0.2000n
dV/dt_f       &nb= sp; =20 0.7236/2.6060n     =20 0.4002/4.0761n      1.3476/1.4710n
 
ANd here the error message of my Falling waveform : =
 
ERROR - Model IO0: The [Falling Waveform]=20
      with [R_fixture]=3D500 Ohms and=20 [V_fixture_max]=3D0V
      has MAX column = DC=20 endpoints of  0.00V and  3.40v,=20 but
      an equivalent load applied to = the=20 model's I-V tables yields
      different = voltages=20 ( 0.00V and  0.00V),
      a = difference of=20 100.00% and 178015.78%, respectively.
 
 
Thanks
 
rdgs
yylau
- ------=_NextPart_000_003E_01C5D341.6840A850-- |------------------------------------------------------------------ |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, 17 Oct 2005 17:39:17 -0700 From: "Tom Dagostino" Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support This is a multi-part message in MIME format. - ------=_NextPart_000_0042_01C5D341.B2906670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ray Do any of the simulators support this? Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Ray Anderson Sent: Monday, October 17, 2005 4:14 PM To: ibis-users@eda.org Cc: Ray Anderson Subject: [IBIS-Users] Per-Pin Distributed RLC Support In reviewing a large sampling of IBIS models from numerous vendors I have yet to find any that implement the distributed RLC format as described in the [Pin Numbers] section of the IBIS spec. (pages 117-120 in the 4.1 spec) I was wondering if anyone is aware of any published models that take advantage of this method of describing package parasitics. Regards, -Ray Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Department Advanced Package R&D Xilinx Inc. - ------=_NextPart_000_0042_01C5D341.B2906670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ray
 
Do any=20 of the simulators support this?
 

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

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

-----Original Message-----
From: = owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org]On Behalf Of Ray=20 Anderson
Sent: Monday, October 17, 2005 4:14 = PM
To:=20 ibis-users@eda.org
Cc: Ray Anderson
Subject: = [IBIS-Users]=20 Per-Pin Distributed RLC Support

In reviewing a large = sampling of=20 IBIS models from numerous vendors I have yet to find any that = implement the=20 distributed RLC format as described in the [Pin Numbers] section of = the IBIS=20 spec. (pages 117-120 in the 4.1 spec)

 

I was wondering if = anyone is aware=20 of any published models that take advantage of this method of = describing=20 package parasitics.

 

Regards,

 

-Ray

 

 

Raymond=20 Anderson

Senior = Signal=20 Integrity Staff Engineer

Product = Technology=20 Department

Advanced = Package=20 R&D

Xilinx=20 Inc.

 

 

- ------=_NextPart_000_0042_01C5D341.B2906670-- |------------------------------------------------------------------ |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, 18 Oct 2005 08:42:27 +0200 From: Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5D3AF.1B3E00B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Tom, I think that you put the right question, so let me elaborate this little bit further: =20 1. are there any available tools that generate/extract such RLC data out of package data? =20 2. before I submit the request to package experts to extract one more package format (they will crucify me anyway :-) I would like to know how many people would like/intend to use it =20 3. I know that the next question is not fair and that I compare here apples and oranges, but if you have one one side such RLC data and on the other side Sparse Matrix data what would you prefer to use? - My choice will be always Sparse Matrix - unless there is some very specific request =20 4. last but not least, quiet honestly, for me it is still little bit unclear what is meant to describe with "fork" and "endfork" branches ... Is it meant to indicate that for example 2 or more pads are sharing the same pin/ball or something similar - or I am missing the point totally? I thing that one picture (perhaps also in specs) could help on this place. =20 Regards, Radovan -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Tom Dagostino Sent: Tuesday, October 18, 2005 2:39 AM To: Ray Anderson; ibis-users@eda.org Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support =09 =09 Ray =20 Do any of the simulators support this? =20 Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com =09 Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827=20 -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Ray Anderson Sent: Monday, October 17, 2005 4:14 PM To: ibis-users@eda.org Cc: Ray Anderson Subject: [IBIS-Users] Per-Pin Distributed RLC Support =09 =09 In reviewing a large sampling of IBIS models from numerous vendors I have yet to find any that implement the distributed RLC format as described in the [Pin Numbers] section of the IBIS spec. (pages 117-120 in the 4.1 spec) =20 I was wondering if anyone is aware of any published models that take advantage of this method of describing package parasitics. =20 Regards, =20 -Ray =20 =20 Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Department Advanced Package R&D Xilinx Inc. =20 =20 - ------_=_NextPart_001_01C5D3AF.1B3E00B6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
Tom, I=20 think that you put the right question, so let me elaborate this = little bit=20 further:
 
1. are=20 there any available tools that generate/extract such RLC data out of = package=20 data?
 
2.=20 before I submit the request to package experts to extract one more = package=20 format (they will crucify me anyway :-)  I would like to know how = many=20 people would like/intend to use it
 
3. I=20 know that the next question is not fair and that I compare here apples = and=20 oranges, but if you have one one side such RLC data and on the = other=20 side Sparse Matrix data what would you prefer to use? - My choice = will be=20 always Sparse Matrix - unless there is some very specific=20 request
 
4.=20 last but not least, quiet honestly, for me it is still little bit = unclear what=20 is meant to describe with "fork" and "endfork"  branches ... Is it = meant to=20 indicate that for example 2 or more pads are sharing the = same pin/ball=20 or something similar - or I am missing the point totally? I thing = that one=20 picture (perhaps also in specs) could help on this=20 place.
 
Regards,
Radovan
-----Original Message-----
From:=20 owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On = Behalf Of=20 Tom Dagostino
Sent: Tuesday, October 18, 2005 2:39=20 AM
To: Ray Anderson; ibis-users@eda.org
Subject: = RE:=20 [IBIS-Users] Per-Pin Distributed RLC Support

Ray
 
Do=20 any of the simulators support this?
 

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

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

-----Original Message-----
From: = owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org]On Behalf Of Ray=20 Anderson
Sent: Monday, October 17, 2005 4:14 = PM
To:=20 ibis-users@eda.org
Cc: Ray Anderson
Subject:=20 [IBIS-Users] Per-Pin Distributed RLC Support

In reviewing a large = sampling of=20 IBIS models from numerous vendors I have yet to find any that = implement the=20 distributed RLC format as described in the [Pin Numbers] section of = the IBIS=20 spec. (pages 117-120 in the 4.1 spec)

 

I was wondering if = anyone is=20 aware of any published models that take advantage of this method of=20 describing package parasitics.

 

Regards,

 

-Ray

 

 

Raymond=20 Anderson

Senior = Signal=20 Integrity Staff Engineer

Product=20 Technology Department

Advanced Package=20 R&D

Xilinx = Inc.

 

 

= - ------_=_NextPart_001_01C5D3AF.1B3E00B6-- |------------------------------------------------------------------ |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, 18 Oct 2005 09:13:18 -0400 From: "Todd Westerhoff \(twesterh\)" Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5D3E5.B5565EDD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Radovan, =20 I suspect the reason people are asking for this data is because at the speeds we're dealing with, large packages are really acting like transmission lines. We can clearly see the effects in the lab - measure the input pin of a large device where the driver is serially terminated and you'll see the "ledging" characteristic associated with a transmission line. Lumped RLC parasitics, whether in per-pin or matrix form, won't necessarily reproduce this behavior. =20 I use the term "necessarily" on purpose - some simulators convert package RLC parasitics into their transmission line equivalents - so you'll see transmission line behavior in all cases - but that is implementation-dependent. Explicitly expressing the parasitics as a transmission line should force the simulator to model it that way [or so one would hope]. =20 This isn't an issue for all devices - but it's an issue for devices that are, say, more than 1" square with signaling edge rates less than 250ps. You can take the same rules of thumb for evaluating line length vs. edge rate and distributed/lumped line behavior at the board level and apply them to packages - the problem is the same. =20 Fork/endfork statements are used to describe branches in package routing. Not that common anymore, I grant you - but once upon a time, plating bars and associated package stubs were common, and the fork/endfork statements were used to describe the stub. They're also common in the few cases where discrete devices are part of the package routing. =20 Todd. =20 Todd Westerhoff High Speed Design Group Manager Cisco Systems 1414 Massachusetts Ave - Boxboro, MA - 01719 email:twesterh@cisco.com ph: 978-936-2149 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 "Always do right. This will gratify some people and astonish the rest." =20 - - Mark Twain =20 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Radovan.Vuletic@infineon.com Sent: Tuesday, October 18, 2005 2:42 AM To: tom@teraspeed.com; ray.anderson@xilinx.com; ibis-users@eda.org Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support Hi, =20 Tom, I think that you put the right question, so let me elaborate this little bit further: =20 1. are there any available tools that generate/extract such RLC data out of package data? =20 2. before I submit the request to package experts to extract one more package format (they will crucify me anyway :-) I would like to know how many people would like/intend to use it =20 3. I know that the next question is not fair and that I compare here apples and oranges, but if you have one one side such RLC data and on the other side Sparse Matrix data what would you prefer to use? - My choice will be always Sparse Matrix - unless there is some very specific request =20 4. last but not least, quiet honestly, for me it is still little bit unclear what is meant to describe with "fork" and "endfork" branches ... Is it meant to indicate that for example 2 or more pads are sharing the same pin/ball or something similar - or I am missing the point totally? I thing that one picture (perhaps also in specs) could help on this place. =20 Regards, Radovan -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Tom Dagostino Sent: Tuesday, October 18, 2005 2:39 AM To: Ray Anderson; ibis-users@eda.org Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support =09 =09 Ray =20 Do any of the simulators support this? =20 Tom Dagostino Teraspeed(R) Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 tom@teraspeed.com www.teraspeed.com =09 Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827=20 -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf Of Ray Anderson Sent: Monday, October 17, 2005 4:14 PM To: ibis-users@eda.org Cc: Ray Anderson Subject: [IBIS-Users] Per-Pin Distributed RLC Support =09 =09 In reviewing a large sampling of IBIS models from numerous vendors I have yet to find any that implement the distributed RLC format as described in the [Pin Numbers] section of the IBIS spec. (pages 117-120 in the 4.1 spec) =20 I was wondering if anyone is aware of any published models that take advantage of this method of describing package parasitics. =20 Regards, =20 -Ray =20 =20 Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Department Advanced Package R&D Xilinx Inc. =20 =20 - ------_=_NextPart_001_01C5D3E5.B5565EDD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Radovan,
 
I suspect the reason people are asking for this = data is=20 because at the speeds we're dealing with, large packages are really = acting like=20 transmission lines.  We can clearly see the effects in the lab=20 - - measure the input pin of a large device where the driver is = serially=20 terminated and you'll see the "ledging" characteristic associated with a = transmission line.  Lumped RLC parasitics, whether in per-pin or = matrix=20 form, won't necessarily reproduce this behavior.
 
I use the term "necessarily" on purpose - some = simulators=20 convert package RLC parasitics into their transmission line=20 equivalents - so you'll see transmission line behavior in all cases = - - but=20 that is implementation-dependent.  Explicitly expressing the = parasitics as=20 a transmission line should force the simulator to model it that way [or = so one=20 would hope].
 
This isn't an issue for all devices - but it's = an issue for=20 devices that are, say, more than 1" square with signaling edge rates = less than=20 250ps.  You can take the same rules of thumb for evaluating line = length vs.=20 edge rate and distributed/lumped line behavior at the board level and = apply them=20 to packages - the problem is the same.
 
Fork/endfork statements are used to = describe branches=20 in package routing.  Not that common anymore, I grant you - but = once upon a=20 time, plating bars and associated package stubs were common, and the=20 fork/endfork statements were used to describe the stub.  They're = also=20 common in the few cases where discrete devices are part of the package=20 routing.
 
Todd.
 
Todd Westerhoff
High = Speed Design=20 Group Manager
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - = 01719=20 email:twesterh@cisco.com
ph:=20 978-936-2149
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 
"Always do = right.
 This will=20 gratify some people and astonish the rest."
 
- Mark = Twain
 

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of=20 Radovan.Vuletic@infineon.com
Sent: Tuesday, October 18, = 2005 2:42=20 AM
To: tom@teraspeed.com; ray.anderson@xilinx.com;=20 ibis-users@eda.org
Subject: RE: [IBIS-Users] Per-Pin = Distributed RLC=20 Support

Hi,
 
Tom, I=20 think that you put the right question, so let me elaborate this = little bit=20 further:
 
1. are=20 there any available tools that generate/extract such RLC data out of = package=20 data?
 
2.=20 before I submit the request to package experts to extract one more = package=20 format (they will crucify me anyway :-)  I would like to know how = many=20 people would like/intend to use it
 
3. I=20 know that the next question is not fair and that I compare here apples = and=20 oranges, but if you have one one side such RLC data and on the = other=20 side Sparse Matrix data what would you prefer to use? - My choice = will be=20 always Sparse Matrix - unless there is some very specific=20 request
 
4.=20 last but not least, quiet honestly, for me it is still little bit = unclear what=20 is meant to describe with "fork" and "endfork"  branches ... Is it = meant to=20 indicate that for example 2 or more pads are sharing the = same pin/ball=20 or something similar - or I am missing the point totally? I thing = that one=20 picture (perhaps also in specs) could help on this=20 place.
 
Regards,
Radovan
-----Original Message-----
From:=20 owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On = Behalf Of=20 Tom Dagostino
Sent: Tuesday, October 18, 2005 2:39=20 AM
To: Ray Anderson; ibis-users@eda.org
Subject: = RE:=20 [IBIS-Users] Per-Pin Distributed RLC Support

Ray
 
Do=20 any of the simulators support this?
 

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

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

-----Original Message-----
From: = owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org]On Behalf Of Ray=20 Anderson
Sent: Monday, October 17, 2005 4:14 = PM
To:=20 ibis-users@eda.org
Cc: Ray Anderson
Subject:=20 [IBIS-Users] Per-Pin Distributed RLC Support

In reviewing a large = sampling of=20 IBIS models from numerous vendors I have yet to find any that = implement the=20 distributed RLC format as described in the [Pin Numbers] section of = the IBIS=20 spec. (pages 117-120 in the 4.1 spec)

 

I was wondering if = anyone is=20 aware of any published models that take advantage of this method of=20 describing package parasitics.

 

Regards,

 

-Ray

 

 

Raymond=20 Anderson

Senior = Signal=20 Integrity Staff Engineer

Product=20 Technology Department

Advanced Package=20 R&D

Xilinx = Inc.

 

 

= - ------_=_NextPart_001_01C5D3E5.B5565EDD-- |------------------------------------------------------------------ |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, 21 Oct 2005 19:23:54 -0700 From: "Mirmak, Michael" Subject: [IBIS-Users] Agenda, IBIS Open Forum teleconference for Oct. 28, 2005 IBIS Open Forum Meeting Agenda for October 28, 2005 Telephone Number Bridge Passcode 1-916-356-2663 2 774-5683 All meetings are 8:00 AM to 9:55 AM US Pacific Time. When calling into the meeting, provide the bridge number and passcode at the automated prompts. If asked by an operator, please request to join the IBIS Open Forum hosted by Michael Mirmak. For international numbers, please contact Michael Mirmak. 8:00 Check-In, Intros, Announcements Mirmak - Intros of New IBIS Participants, Meeting Quorum Mirmak - Call for Patents Mirmak - Membership Update and Treasurer's Report Mirmak - Review of Previous Meeting's Minutes (and ARs) Mirmak October 7, 2005 Open Forum Minutes - Web Page Updates Huq - Mailing List Administration Ross - Library Update Wang - Announcements, Opens for New Issues All 8:15 Project Discussions and Subcommittee Reports International/External Progress - BMAS Summary Muranyi - TC93/TC47 Updates Ross EIA, ANSI Approval Activities Wolff - Status of ICM 1.1 Standardization Summit Status All - Asian IBIS Summit (Dec. 6) - DesignCon - Other Events Task Group Reports - Quality Haller - Model Review Green - Futures Mirmak - Cookbook Mirmak - Macromodeling Library Muranyi New Issues All 8:45 Technical Discussion BIRD97.2: Gate Modulation Effect Muranyi BIRD98: Gate Modulation Effect (table format) Muranyi Options for Next IBIS Version Discussion Mirmak - Including Pending & Draft BIRDs IBISCHK4 BUG Status All ICMCHK1 BUG Status All New Technical Issues All 9:50 Wrap Up and Next Meeting Plans Mirmak - November 18, 2005 IBIS Open Forum 9:55 Sign Off |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 24 Oct 2005 10:47:45 -0700 From: Bob Ross Subject: [IBIS-Users] Asian IBIS Summit Fourth Announcement To All: This is the fourth announcement for the Asian IBIS Summit in Shenzhen, China, a major technology center near Hong Kong. The meeting is being held at the Crowne Plaza Hotel, and several IBIS experts are planning to attend. The agenda is full with excellent presentations from US and Asian countries. The main benefit is to meet IBIS experts and people actively involved with IBIS model development, algorithm development, and usage. Some tentative titles/topics and presenters are shown below to show the meeting content. The exact titles and all co-authors will be listed after the presentations are submitted by November 7. - - IBIS Committee Overview and IBIS Modeling Challenges Mirmak, Michael (Intel Corporation (USA) - - Using IBIS for SI Analysis Zhong, ZhangMin* and Wang, Lance** (Cadence Design Systems, *China and **USA) - - Fiberhome Telecommunications Technology Experiences with IBIS Models Zheng, Qi (Fiberhome Telecommunications Technology, China) - - JEITA EDA - WG Activity and Study of Interconnect Model Watanabe, Takeshi (NEC Electronics Corporation, Japan) - - Three Facets of IBIS: Interface, Behavior, and Measurement Dodd, Ian (Mentor Graphics Corporation, USA) - - IBIS and Power Delivery Systems Jiang, XiangZhong (Huawei Technologies, China) - - Power Delivery System Signal Return Path and SSO Analysis Guidelines Chen, Raymond (Sigrity, USA) - - How to Extract and Split the C_comp, and Why it is Important in Power Integrity Simulations Yang, Zhiping (Cisco Systems, USA) - - Macro Model and Multi-GHz System Simulation Zhu, ShunLin, (ZTE Corporation, China) - - IBIS Models for DDR2 Analysis Katz, Barry, (Signal Integrity Software (SiSoft), USA) - - Practical Measurement vs. Simulation Correlation with DDR2 667 Interface Shoji, Kazuyoshi (Hitachi ULSI Systems, Japan) - - Simulation with IBIS in Tight Timing Budget System Sui, ShiJu, (ZTE Corporation, China) - - Improving IBIS Models and Algorithms Ross, Bob (Teraspeed Consulting Group, USA) Bob Ross Teraspeed Consulting Group Lance Wang Cadence Design Systems - ----------------------------------------------------------------------- ASIAN IBIS SUMMIT FOURTH CALL FOR PARTICIPATION AND PRESENTATIONS - ----------------------------------------------------------------------- http://www.eda.org/pub/ibis/summits/dec05/ASIAN_IBIS_SUMMIT_CHINESE.pdf http://www.eda.org/pub/ibis/summits/dec05/ASIAN_IBIS_SUMMIT_CH_TRA-2.pdf ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A S I A N I B I S S U M M I T M E E T I N G Time/Date: Tuesday December 6, 2005, 8:00 AM to 5:30 PM Meeting starts at 9:00 AM Location: Crowne Plaza Hotel Shenzhen 9026 Shennan Rd, OCT Shenzhen, 518053 CHINA Tel: 86-755-26936888 Fax: 86-755-26936999 E-mail: cpsz@cpsz.com http://www.ichotelsgroup.com/h/d/cp/1/en/hd/SZXNS Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Primary Sponsor: Huawei Technologies Co-sponsors (in alphabetical order): Cadence Design Systems, Mentor Graphics Corporation, Signal Integrity Software (SiSoft), and Sigrity Contact us for details regarding sponsorship. Cost: FREE, including refreshments and buffet lunch Vendors: Some vendors will have information tables outside the meeting room BACKGROUND Shenzhen, next to Hong Kong, is a special economic zone in the Peoples Republic of China with many high technology companies and many development and sales offices of foreign companies. Many sites of interest are near the conference hotel. Like the European IBIS Summit, our objective is to reach out internationally to communicate with the local experts and to learn of regional concerns. CONFERENCE LANGUAGE The conference language is English, but we will plan for technical translation as needed in a manner to be determined. So presenters can optionally deliver in Chinese as long as an English version of the material is available. IBIS SUMMIT This meeting will be conducted as a formal IBIS Summit Meeting. Presentations will be archived in an electronic format on our Summits site, and minutes of the meeting will be issued. However, no formal decisions requiring votes will be planned. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Top-level Web Link: Country: Telephone: Comments: (Such as assistance for the travel requirements at the end) Send to BOTH: Bob Ross, Teraspeed Consulting Group bob@teraspeed.com Lance Wang, Cadence Design Systems lwang@cadence.com SIGNUP DEADLINE: November 25, 2005 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. If we have to select presentations for the number of time slots available, we will give preferential consideration to Asian-based presentations. Presentation Format: LCD Projection from meeting laptop computer Time: 15-30 Minutes including questions Electronic Archival: All presentations will uploaded to our public IBIS Summit archives Electronic Format: Power Point or Acrobat Presentation Copies: Available at the meeting for all attendees Presentation Deadline: November 7, 2005 to produce hard copies for the meeting If you plan a presentation, please ADD to the above registration information: Title of Presentation: Estimated Time: (30 minutes or less) Note: The agenda is full, but let us know if you are interested in doing a presentation. We may be able to adjust the schedule to allow for your presentation. We will notify you of acceptance and may follow up with questions when we form the program agenda. Note: Vendor promotional or business information is prohibited. Submitted presentations must be in English, although the delivery can be in a Chinese and translation to be arranged. Asian-based submissions are encouraged. AGENDA 8:15 - 9:00 Sign in, casual conversation, vendor tables 9:00 - 12:00 Presentations 12:00 - 13:30 Free buffet lunch, vendor tables 13:30 - 17:30 Presentations 17:30 - 18:30 Casual conversations, vendor tables The following companies are planning presentations: China: Huawei Technologies, ZTE Corporation, Fiberhome Telecommunications Technology Japan: NEC Electronics Corportion (on JEITA), Hitachi ULSI Systems USA Cadence Design Systems, Cisco Systems, Intel Corporation, Mentor Graphics Corporation, Signal Intergrity Software (SiSoft), Sigrity, and Teraspeed Consulting Group LIST OF NEARBY HOTELS AND TRAVEL RULES Hotels in all price ranges can be found through internet searches. A link to the conference hotel, Crown Plaza Hotel Shenzhen, is: http://www.ichotelsgroup.com/h/d/cp/1/en/hd/SZXNS Comply with your travel rules, such as indicated in the link below to China and Shenzhen. Work with your travel agent. Notify us as a sign-up comment if you need assistance. Visas, if needed, should fall in the visit/business category: http://www.travelchinaguide.com/embassy/visa.htm - ----------------------------------------------------------------- - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 25 Oct 2005 09:06:16 -0700 From: "Mirmak, Michael" Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5D97E.07C9A525 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, =20 Intel Corp. has issued distributed RLC information in IBIS customer models in the past. An example of this would be the Intel ICH3 I/O Hub. The model is available under NDA. =20 - - Michael Mirmak ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Ray Anderson Sent: Monday, October 17, 2005 4:14 PM To: ibis-users@eda.org Cc: Ray Anderson Subject: [IBIS-Users] Per-Pin Distributed RLC Support In reviewing a large sampling of IBIS models from numerous vendors I have yet to find any that implement the distributed RLC format as described in the [Pin Numbers] section of the IBIS spec. (pages 117-120 in the 4.1 spec) =20 I was wondering if anyone is aware of any published models that take advantage of this method of describing package parasitics. =20 Regards, =20 - -Ray =20 =20 Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Department Advanced Package R&D Xilinx Inc. =20 =20 - ------_=_NextPart_001_01C5D97E.07C9A525 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ray,
 
Intel Corp. has issued distributed RLC = information in=20 IBIS customer models in the past.  An example of this would be = the=20 Intel ICH3 I/O Hub.  The model is available under = NDA.
 
- Michael Mirmak

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of Ray=20 Anderson
Sent: Monday, October 17, 2005 4:14 PM
To:=20 ibis-users@eda.org
Cc: Ray Anderson
Subject: = [IBIS-Users]=20 Per-Pin Distributed RLC Support

In reviewing a large = sampling of=20 IBIS models from numerous vendors I have yet to find any that implement = the=20 distributed RLC format as described in the [Pin Numbers] section of the = IBIS=20 spec. (pages 117-120 in the 4.1 spec)

 

I was wondering if anyone = is aware=20 of any published models that take advantage of this method of describing = package=20 parasitics.

 

Regards,

 

-Ray

 

 

Raymond=20 Anderson

Senior = Signal=20 Integrity Staff Engineer

Product = Technology=20 Department

Advanced = Package=20 R&D

Xilinx=20 Inc.

 

 

- ------_=_NextPart_001_01C5D97E.07C9A525-- |------------------------------------------------------------------ |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, 25 Oct 2005 09:38:09 -0700 From: "Beal, Weston" Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support This is a multi-part message in MIME format. - ------_=_NextPart_001_01C5D982.7C15DCEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, =20 ICX has supported the distributed package model for many years (except the Fork and Endfork parameters). I remember in the "old days" using ICX to simulate busses that included the Intel model that Michael mentioned along with other Intel models. It seems that there were only a few other models besides the Intel chipsets that used these distributed package models. =20 Later, Weston =20 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Mirmak, Michael Sent: Tuesday, October 25, 2005 9:06 AM To: Ray Anderson; ibis-users@eda.org Subject: RE: [IBIS-Users] Per-Pin Distributed RLC Support Ray, =20 Intel Corp. has issued distributed RLC information in IBIS customer models in the past. An example of this would be the Intel ICH3 I/O Hub. The model is available under NDA. =20 - - Michael Mirmak ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Ray Anderson Sent: Monday, October 17, 2005 4:14 PM To: ibis-users@eda.org Cc: Ray Anderson Subject: [IBIS-Users] Per-Pin Distributed RLC Support In reviewing a large sampling of IBIS models from numerous vendors I have yet to find any that implement the distributed RLC format as described in the [Pin Numbers] section of the IBIS spec. (pages 117-120 in the 4.1 spec) =20 I was wondering if anyone is aware of any published models that take advantage of this method of describing package parasitics. =20 Regards, =20 - -Ray =20 =20 Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Department Advanced Package R&D Xilinx Inc. =20 =20 - ------_=_NextPart_001_01C5D982.7C15DCEE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ray,
 
ICX has supported the distributed package = model for=20 many years (except the Fork and Endfork parameters). I remember in the = "old=20 days" using ICX to simulate busses that included the Intel model that = Michael=20 mentioned along with other Intel models. It seems that there were only a = few=20 other models besides the Intel chipsets that used these distributed = package=20 models.
 
Later,
Weston
 

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of Mirmak,=20 Michael
Sent: Tuesday, October 25, 2005 9:06 AM
To: = Ray=20 Anderson; ibis-users@eda.org
Subject: RE: [IBIS-Users] Per-Pin = Distributed RLC Support

Ray,
 
Intel Corp. has issued distributed RLC = information in=20 IBIS customer models in the past.  An example of this would be = the=20 Intel ICH3 I/O Hub.  The model is available under = NDA.
 
- Michael Mirmak

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of Ray=20 Anderson
Sent: Monday, October 17, 2005 4:14 PM
To:=20 ibis-users@eda.org
Cc: Ray Anderson
Subject: = [IBIS-Users]=20 Per-Pin Distributed RLC Support

In reviewing a large = sampling of=20 IBIS models from numerous vendors I have yet to find any that implement = the=20 distributed RLC format as described in the [Pin Numbers] section of the = IBIS=20 spec. (pages 117-120 in the 4.1 spec)

 

I was wondering if anyone = is aware=20 of any published models that take advantage of this method of describing = package=20 parasitics.

 

Regards,

 

-Ray

 

 

Raymond=20 Anderson

Senior = Signal=20 Integrity Staff Engineer

Product = Technology=20 Department

Advanced = Package=20 R&D

Xilinx=20 Inc.

 

 

- ------_=_NextPart_001_01C5D982.7C15DCEE-- |------------------------------------------------------------------ |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, 28 Oct 2005 14:07:19 -0700 From: "Angulo, John" Subject: [IBIS-Users] Inappropriate I-V tables in open_drain/source model types At today's IBIS teleconference, I raised the issue of whether a bug report should be logged against ibischk for its treatment of I-V tables inappropriate to the model type. Specifically, there should be no [Pullup] table, or at least no non-zero currents for the [Pullup] table in a model using open drain/sink topology, and there should be no non-zero [Pulldown] table in a model using open source topology. If an inappropriate I-V table is present (with non-zero currents), ibischk issues a warning message. However, it goes on to check I-V/V-t endpoint agreement using all the model's I-V tables. Should ibischk instead ignore the I-V table incompatible with the model_type? A motivation for doing this is that sometimes model makers mistakenly put internal bias characteristics for open_* parts into the [Pullup] and [Pulldown] tables. Ignoring inappropriate I-V tables during I-V/V-t checking would expose this by causing I-V/V-t mismatches. However, if using the inappropriate I-V table causes an I-V/V-t mismatch, the current parser behavior exposes the problem. So it may be valuable to report both when ignoring the table causes a problem and when using the table causes a problem. I can report that at least one popular SI tool does not ignore the inappropriate table. The existing parser behavior has in fact encouraged this policy. It is not safe for the SI tool to ignore one of the I-V tables the parser depended on to "bless" the model, unless it does the alternative endpoint checking itself. Would it be worth adding a separate I-V/V-t endpoint check under the assumption of open_* topology to highlight models that depend on significant currents in the inappropriate table? Would it equivalently be worth elevating the inappropriate-table warning to an error? It seems unsafe to drop the existing I-V/V-t test policy for open_* models. John Angulo Software Development Engineer Hyperlynx Products Mentor Graphics Corp. |------------------------------------------------------------------ |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, 28 Oct 2005 17:12:42 -0700 From: Bob Ross Subject: [IBIS-Users] Re: [IBIS] Inappropriate I-V tables in open_drain/source model types John: The dual mode V-T waveform checking option is unnecessary. I now favor elevating the inconsistency to Error, but not change the existing V-T mismatch checking. The fact that the V-T checking is not consistent with a Model_type assumption does force the issue. (If the V-T checking was consistent with Model_type and the non-zero [Pullup] or [Pulldown] table was NOT included, then I would consider keeping this as a Warning.) The Error message forces the modeler or the user to address the problem. Then the checking will already be correctly in place when the Model_type inconsistency is addressed. Bob Angulo, John wrote: > At today's IBIS teleconference, I raised the issue of whether a bug > report should be logged against ibischk for its treatment of I-V tables > inappropriate to the model type. Specifically, there should be no > [Pullup] table, or at least no non-zero currents for the [Pullup] table > in a model using open drain/sink topology, and there should be no > non-zero [Pulldown] table in a model using open source topology. > > If an inappropriate I-V table is present (with non-zero currents), > ibischk issues a warning message. However, it goes on to check I-V/V-t > endpoint agreement using all the model's I-V tables. > > Should ibischk instead ignore the I-V table incompatible with the > model_type? A motivation for doing this is that sometimes model makers > mistakenly put internal bias characteristics for open_* parts into the > [Pullup] and [Pulldown] tables. Ignoring inappropriate I-V tables > during I-V/V-t checking would expose this by causing I-V/V-t mismatches. > > > However, if using the inappropriate I-V table causes an I-V/V-t > mismatch, the current parser behavior exposes the problem. > > So it may be valuable to report both when ignoring the table causes a > problem and when using the table causes a problem. I can report that at > least one popular SI tool does not ignore the inappropriate table. The > existing parser behavior has in fact encouraged this policy. It is not > safe for the SI tool to ignore one of the I-V tables the parser depended > on to "bless" the model, unless it does the alternative endpoint > checking itself. > > Would it be worth adding a separate I-V/V-t endpoint check under the > assumption of open_* topology to highlight models that depend on > significant currents in the inappropriate table? Would it equivalently > be worth elevating the inappropriate-table warning to an error? It > seems unsafe to drop the existing I-V/V-t test policy for open_* models. > > John Angulo > Software Development Engineer > Hyperlynx Products > Mentor Graphics Corp. > > ----------------------------------------------------------------- > |For help or to subscribe/unsubscribe, email majordomo@eda.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or email a request to ibis-request@eda.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda.org/pub/ibis/email_archive/ Recent > | http://www.eda.org/pub/ibis/users_archive/ Recent > | http://www.eda.org/pub/ibis/email/ E-mail since 1993 > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Mon, 31 Oct 2005 08:38:46 -0800 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] Re: [IBIS] Inappropriate I-V tables in open_drain/source model types I am not sure whether I follow the details of this discussion, but I wouldn't implement variations of the IV/Vt checking routine based on the model type. I would just simply check for the existence of IV tables against the model type, and issue warnings or error messages based on that. And by existence I mean I would also check whether the table is all zero or not... Arpad =================================================== - -----Original Message----- From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Bob Ross Sent: Friday, October 28, 2005 5:13 PM To: Angulo, John Cc: ibis; ibis-users Subject: [IBIS-Users] Re: [IBIS] Inappropriate I-V tables in open_drain/source model types John: The dual mode V-T waveform checking option is unnecessary. I now favor elevating the inconsistency to Error, but not change the existing V-T mismatch checking. The fact that the V-T checking is not consistent with a Model_type assumption does force the issue. (If the V-T checking was consistent with Model_type and the non-zero [Pullup] or [Pulldown] table was NOT included, then I would consider keeping this as a Warning.) The Error message forces the modeler or the user to address the problem. Then the checking will already be correctly in place when the Model_type inconsistency is addressed. Bob Angulo, John wrote: > At today's IBIS teleconference, I raised the issue of whether a bug > report should be logged against ibischk for its treatment of I-V tables > inappropriate to the model type. Specifically, there should be no > [Pullup] table, or at least no non-zero currents for the [Pullup] table > in a model using open drain/sink topology, and there should be no > non-zero [Pulldown] table in a model using open source topology. > > If an inappropriate I-V table is present (with non-zero currents), > ibischk issues a warning message. However, it goes on to check I-V/V-t > endpoint agreement using all the model's I-V tables. > > Should ibischk instead ignore the I-V table incompatible with the > model_type? A motivation for doing this is that sometimes model makers > mistakenly put internal bias characteristics for open_* parts into the > [Pullup] and [Pulldown] tables. Ignoring inappropriate I-V tables > during I-V/V-t checking would expose this by causing I-V/V-t mismatches. > > > However, if using the inappropriate I-V table causes an I-V/V-t > mismatch, the current parser behavior exposes the problem. > > So it may be valuable to report both when ignoring the table causes a > problem and when using the table causes a problem. I can report that at > least one popular SI tool does not ignore the inappropriate table. The > existing parser behavior has in fact encouraged this policy. It is not > safe for the SI tool to ignore one of the I-V tables the parser depended > on to "bless" the model, unless it does the alternative endpoint > checking itself. > > Would it be worth adding a separate I-V/V-t endpoint check under the > assumption of open_* topology to highlight models that depend on > significant currents in the inappropriate table? Would it equivalently > be worth elevating the inappropriate-table warning to an error? It > seems unsafe to drop the existing I-V/V-t test policy for open_* models. > > John Angulo > Software Development Engineer > Hyperlynx Products > Mentor Graphics Corp. > > ----------------------------------------------------------------- > |For help or to subscribe/unsubscribe, email majordomo@eda.org > |with the appropriate command message(s) in the body: > | > | help > | subscribe ibis > | subscribe ibis-users > | unsubscribe ibis > | unsubscribe ibis-users > | > |or email a request to ibis-request@eda.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda.org/pub/ibis/email_archive/ Recent > | http://www.eda.org/pub/ibis/users_archive/ Recent > | http://www.eda.org/pub/ibis/email/ E-mail since 1993 > - -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |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 #67 ************************