From: owner-ibis-users@eda.org (ibis-users) To: ibis-users-digest@eda.org Subject: ibis-users V1 #73 Reply-To: Sender: owner-ibis-users@eda.org Errors-To: owner-ibis-users@eda.org Precedence: bulk ibis-users Wednesday, January 4 2006 Volume 01 : Number 073 ---------------------------------------------------------------------- Date: Tue, 20 Dec 2005 10:20:02 -0800 From: "Mirmak, Michael" Subject: RE: [IBIS-Users] IBIS model correlation... This is a multi-part message in MIME format. - ------_=_NextPart_001_01C60591.FE5BEBD5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Venu, =20 Thanks for your interest in IBIS. After looking at the waveforms and parser output, I have a few comments: =20 1) I strongly agree with Itzik that the min corner V-t tables should be allowed to settle to their final DC level to remove I-V/V-t mismatches. 2) The ground clamp table is highly discontinuous. While this shouldn't cause problems in the operating region, I cannot vouch for what tools will do to or with the summed data when the pulldown and ground clamp tables are added together to drive. You may wish to add some data points (the table contains fewer than 50) or recheck your extraction procedure for that device state. 3) I note that the voltage ordering for the pulldown and ground clamp tables is positive-to-negative. This is perfectly legal in IBIS, but I recall this has caused simulators some trouble in the distant past. Have you tried reordering these negative-to-positive and checking the results? 4) To clarify, are you using a test load with a capacitor *before* the transmission line? Is there a reason your test load includes this unusual structure? 5) Please ensure that your SPICE tool is using all the V-t tables available (some tools feature a setting for a number of rising and/or falling tables -- ensure this is set to use all 4 present in your model). 6) (minor point) You may wish to make use of the [Test Load] and [Test Data] keywords to include your loading and correlation waveform information from your SPICE tool, to ease comparison. 7) One last question: how does the correlation look into a capacitor alone (both values) and a transmission line alone? If these match well, I would inquire with your vendor about checking the algorithm used for a mixed load like this one. =20 Good luck! =20 - - Michael Mirmak Intel Corp. =20 =20 =20 - ------_=_NextPart_001_01C60591.FE5BEBD5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hspice vs IBIS model correlation at different = capacitive loads
Venu,
 
Thanks for your interest in IBIS.  After = looking at=20 the waveforms and parser output, I have a few = comments:
 
1) I strongly agree with Itzik that the min = corner V-t=20 tables should be allowed to settle to their final DC level to remove = I-V/V-t=20 mismatches.
2) The ground clamp table is highly = discontinuous. =20 While this shouldn't cause problems in the operating region, I cannot = vouch for=20 what tools will do to or with the summed data when the pulldown and = ground=20 clamp tables are added together to drive.  You may wish to add some = data=20 points (the table contains fewer than 50) or recheck your = extraction=20 procedure for that device state.
3) I note that the voltage ordering for the = pulldown and=20 ground clamp tables is positive-to-negative.  This is perfectly = legal in=20 IBIS, but I recall this has caused simulators some trouble in the = distant=20 past.  Have you tried reordering these negative-to-positive and = checking=20 the results?
4) To=20 clarify, are you using a test load with a capacitor *before* the = transmission=20 line?  Is there a reason your test load includes this unusual=20 structure?
5)=20 Please ensure that your SPICE tool is using all the V-t tables available = (some=20 tools feature a setting for a number of rising and/or falling tables -- = ensure=20 this is set to use all 4 present in your model).
6)=20 (minor point) You may wish to make use of the [Test Load] and [Test = Data]=20 keywords to include your loading and correlation waveform information = from your=20 SPICE tool, to ease comparison.
7) One=20 last question: how does the correlation look into a capacitor alone = (both=20 values) and a transmission line alone?  If these match well, I = would=20 inquire with your vendor about checking the algorithm used for a mixed = load like=20 this one.
 
Good=20 luck!
 
-=20 Michael Mirmak
 =20 Intel Corp.
  =

 
 
- ------_=_NextPart_001_01C60591.FE5BEBD5-- |------------------------------------------------------------------ |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, 22 Dec 2005 17:39:13 +0530 From: "Patel, Nirav \(Nirav\)" Subject: RE: [IBIS] RE: [IBIS-Users] IBIS model correlation... This is a multi-part message in MIME format. - ------_=_NextPart_001_01C606F0.85AFD0B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael Mirmak, =20 Thanks for spending time in reviewing our issue and valuable suggestions. Please see my responses in line with your suggestions. =20 1) I strongly agree with Itzik that the min corner V-t tables should be allowed to settle to their final DC level to remove I-V/V-t mismatches. - - Good point we will run for longer time. 2) The ground clamp table is highly discontinuous. While this shouldn't cause problems in the operating region, I cannot vouch for what tools will do to or with the summed data when the pulldown and ground clamp tables are added together to drive. You may wish to add some data points (the table contains fewer than 50) or recheck your extraction procedure for that device state. - - We will work with simulator vendor to see if we get their opinion. 3) I note that the voltage ordering for the pulldown and ground clamp tables is positive-to-negative. This is perfectly legal in IBIS, but I recall this has caused simulators some trouble in the distant past. Have you tried reordering these negative-to-positive and checking the results? - - Interesting point, we will give a try. 4) To clarify, are you using a test load with a capacitor *before* the transmission line? Is there a reason your test load includes this unusual structure? - - Usually, we use transmission line and then capacitor as per typical verification setup. However, for ATA buffer, we got the suggestion to do verification without transmission line also. 5) Please ensure that your SPICE tool is using all the V-t tables available (some tools feature a setting for a number of rising and/or falling tables -- ensure this is set to use all 4 present in your model). - - Yes, as per the user guide, tool is using all 4 v-t waveforms.=20 6) (minor point) You may wish to make use of the [Test Load] and [Test Data] keywords to include your loading and correlation waveform information from your SPICE tool, to ease comparison. - - Yes. We need to update our methodology to support it. However, do you have any idea how simulator will use these data? 7) One last question: how does the correlation look into a capacitor alone (both values) and a transmission line alone? If these match well, I would inquire with your vendor about checking the algorithm used for a mixed load like this one. - - We used transmission line and 30pf in the initial verification setup. Hspice and IBIS did NOT match very well. Then we used transmission line and 5pf in the verification setup. (did NOT match). After getting suggestions, we did verification with only 5pf load. Hspice and IBIS matched well. When we used 30pf alone, hspice and IBIS are not matching. Now, we need to find what can be the reason. =20 Thanks in advance, Nirav/Venu =20 =20 - ------_=_NextPart_001_01C606F0.85AFD0B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hspice vs IBIS model correlation at different capacitive = loads

Michael Mirmak,

 

Thanks for spending time in = reviewing our issue and valuable suggestions. Please see my responses in line with = your suggestions.

 

1) I strongly = agree with Itzik that the min corner V-t tables should be allowed to settle to = their final DC level to remove I-V/V-t mismatches.

- Good point we will run for longer = time.

2) The ground = clamp table is highly discontinuous.  While this shouldn't cause problems in = the operating region, I cannot vouch for what tools will do to or = with the summed data when the pulldown and ground clamp tables are added together = to drive.  You may wish to add some data points (the table contains = fewer than 50) or recheck your extraction procedure for that device = state.

- We will work with simulator = vendor to see if we get their opinion.

3) I note that = the voltage ordering for the pulldown and ground clamp tables is positive-to-negative.  This is perfectly legal in IBIS, but I = recall this has caused simulators some trouble in the distant past.  = Have you tried reordering these negative-to-positive and checking the = results?

- Interesting point, we will give a = try.

4) To clarify, = are you using a test load with a capacitor *before* the transmission line?  = Is there a reason your test load includes this unusual = structure?

- Usually, we use transmission line = and then capacitor as per typical verification setup. However, for ATA = buffer, we got the suggestion to do verification without transmission line = also.

5) Please ensure = that your SPICE tool is using all the V-t tables available (some tools = feature a setting for a number of rising and/or falling tables -- ensure this is = set to use all 4 present in your model).

- Yes, as per the user guide, tool = is using all 4 v-t waveforms.

6) (minor point) = You may wish to make use of the [Test Load] and [Test Data] keywords to include = your loading and correlation waveform information from your SPICE tool, to = ease comparison.

- Yes. We need to update our = methodology to support it. However, do you have any idea how simulator will use = these data?

7) One last = question: how does the correlation look into a capacitor alone (both values) and a transmission line alone?  If these match well, I would inquire with = your vendor about checking the algorithm used for a mixed load like this = one.

- We used transmission line and = 30pf in the initial verification setup. Hspice and IBIS did NOT match very well. = Then we used transmission line and 5pf in the verification = setup. (did NOT match). After getting suggestions, we did verification with only 5pf = load. Hspice and IBIS matched well. When we used 30pf alone, hspice and IBIS are not matching. Now, we need to find what can be the reason.

 

Thanks in = advance,

Nirav/Venu


 

 

- ------_=_NextPart_001_01C606F0.85AFD0B4-- |------------------------------------------------------------------ |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, 22 Dec 2005 19:17:25 +0530 From: "Ummalaneni, Venu Babu \(Venu\)" Subject: [IBIS-Users] Why IO buffer name is limited to a max of 20 characters This is a multi-part message in MIME format. - ------_=_NextPart_001_01C606FE.3E0A84EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Is there any specific reason exist to restrict the IO buffer name to a maximum of 20 chars in our IBIS standard? Can't we change this rule to allow more than 20 chars as buffer name?=20 =20 Recently, I experienced some IO buffers which have more than 20 chars in their names. So, I have to truncate the IBIS model name to support this rule. If choice is given I do not want to truncate the IBIS model name.=20 =20 Thanks in advance, =20 Best Regards, Venu =20 - ------_=_NextPart_001_01C606FE.3E0A84EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hspice vs IBIS model correlation at different capacitive = loads

Hi All,

 

Is there any specific reason exist = to restrict the IO buffer name to a maximum of 20 chars in our IBIS standard? = Can’t we change this rule to allow more than 20 chars as buffer name? =

 

Recently, I experienced some IO = buffers which have more than 20 chars in their names. So, I have to truncate the = IBIS model name to support this rule. If choice is given I do not want to = truncate the IBIS model name.

 

Thanks in = advance,

 

Best Regards,

Venu

 

- ------_=_NextPart_001_01C606FE.3E0A84EC-- |------------------------------------------------------------------ |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, 22 Dec 2005 19:33:10 +0530 From: Vinayak Ghatawade Subject: [IBIS-Users] R-Load Hi, I had this query as to why we need to model the buffers with R-load as in most of the cases it is c-load w/without TL line is driven by the buffer). does it reflect on the TL impedence that it drives? (50ohm environment) Also are there any reading material available in the web as to how the I/V and ramp/VT data get used by the boardlevel simulator. If we have I/V and V/T mismatches due to buffer transient behaviour how does the tool interpret this information. Thanks vinayak |------------------------------------------------------------------ |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, 22 Dec 2005 11:18:11 -0500 From: "Andrew Ingraham" Subject: [IBIS-Users] Re: R-Load > I had this query as to why we need to model the buffers with R-load > as in most of the cases it is c-load w/without TL line is > driven by the buffer). > > does it reflect on the TL impedence that it drives? (50ohm environment) I think you hit the nail right on the head. If the buffer drives a transmission line that is 3 ns long, the device sees an effective load of Zo (typically in the vicinity of 50-80 ohms) for the first 6 ns after it switches. Regards, Andy |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 22 Dec 2005 10:29:05 -0800 From: "Muranyi, Arpad" Subject: [IBIS-Users] RE: [IBIS] R-Load Vinayak, In addition to the answer you already got to the first part of your message here is something to answer the second part. This may not how every tool vendor does it, but you can look at p. 37 in the IBIS_class_2003_11_03.pdf file in: http://www.eda.org/pub/ibis/training/IBIS_class_2003.zip or p. 4-9 in: http://www.eda.org/pub/ibis/summits/jun03b/muranyi1.pdf to get a better understanding on how IV and Vt curves work together. Arpad ========================================================== - -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Vinayak Ghatawade Sent: Thursday, December 22, 2005 6:03 AM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS] R-Load Hi, I had this query as to why we need to model the buffers with R-load as in most of the cases it is c-load w/without TL line is driven by the buffer). does it reflect on the TL impedence that it drives? (50ohm environment) Also are there any reading material available in the web as to how the I/V and ramp/VT data get used by the boardlevel simulator. If we have I/V and V/T mismatches due to buffer transient behaviour how does the tool interpret this information. Thanks vinayak - ----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Thu, 22 Dec 2005 14:15:28 -0800 From: Bob Ross Subject: [IBIS-Users] IBIS Computers Upgrade Hi: The IBIS reflectors and access to the IBIS content on http://www.eda.org/pub/ibis/ or http://www.ibis-information.org/ will be down intermittantantly during the holidays for an upgrade. Nearly all of the critical IBIS information is stored here. Also note, that the IBIS Home site under EIA or GEIA is currently down while a more serious problem is being resolved. Bob IBIS Postmaster - ------------------------------------------------------------------------ Subject: RE: End of the year patch run on eda.org Sorry, left out a detail. I intend to start the patch run just after midnight Saturday morning and it usually takes between 8-10 hours to complete. After cleanup, everything should be stable again by 4:00 PM at the latest. Ladies and Gentlemen, Since we will be restructuring the support contract for the EDA.org server with Accellera to more of a T&M contract in the new year, I need to get in one last full patch upgrade on the server before the end of the year. As such, I will be starting a full patch run on the server on Saturday morning December 24, that will periodically interrupt service through out the day. If you receive complaints from members that things are not working, tell them that we are having a maintenance period and to try again later. Thank you for your patience and have a Happy Holidays and Happy New Year! - -- 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, 22 Dec 2005 19:32:58 -0800 From: "Lynne D. Green" Subject: [IBIS-Users] IBIS Model Review: was: hspice vs IBIS model correlation at different capacitive loads This is a multi-part message in MIME format. - ------=_NextPart_000_0007_01C6072E.846F8930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Happy holidays! The IBIS Model Review Committee continues to accept models for review, even during the holiday season. Access to the IBIS web site is not required. People creating models are encouraged to submit models to the IBIS Model Review Committee at lgreen22@mindspring.com. Please include "IBIS Model Review" as the email subject and attach the model as a plain text file. Best regards, Lynne Green _____ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Ummalaneni, Venu Babu (Venu) Sent: Thursday, December 15, 2005 3:07 AM To: Itzik Peleg; Todd Westerhoff (twesterh); ibis-users@eda.org; ibis@eda.org Subject: RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at different capacitive loads Itzik Peleg, Thanks for your concern. I think there is no such feedback. Here, I am attaching the IBIS model. Thanks & Regards, Venu - ------=_NextPart_000_0007_01C6072E.846F8930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hspice vs IBIS model correlation at different = capacitive loads
Happy holidays!
 
The IBIS Model Review Committee continues to = accept=20 models for review, even during the holiday season.  Access to the = IBIS web=20 site is not required.
 
People creating models are encouraged to = submit=20 models to the IBIS Model Review Committee at lgreen22@mindspring.com. = ; Please=20 include "IBIS Model Review" as the email subject and attach the model as = a plain=20 text file.
 
Best regards,
Lynne Green


 

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of Ummalaneni, Venu = Babu=20 (Venu)
Sent: Thursday, December 15, 2005 3:07 = AM
To: Itzik=20 Peleg; Todd Westerhoff (twesterh); ibis-users@eda.org;=20 ibis@eda.org
Subject: RE: [IBIS] RE: [IBIS-Users] hspice vs = IBIS=20 model correlation at different capacitive loads

Itzik Peleg,
 
Thanks for your concern. I think there is no such =
feedback.
 
Here, I am attaching the IBIS =
model.
 
Thanks & =
Regards,
Venu

 

- ------=_NextPart_000_0007_01C6072E.846F8930-- |------------------------------------------------------------------ |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, 23 Dec 2005 10:46:50 +0530 From: Vinayak Ghatawade Subject: [IBIS-Users] Re: [IBIS] Re: R-Load This is a multi-part message in MIME format. - --------------010007090106050902040308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andy, Thanks for clarifying this. The other concern i had was a. How does the V/T data(Ramp) and I/V data get used up at the boardlevel when simulted by a tool. As far as my knowledge goes ramp rate is imp but not V/T data for o/p and bidi buffers. I/V data generally depicts the drive strength of a buffer, how does this correlate into tranisient behaviour by board level tool when data(swicthing from 1 to 0 and 0 to 1 at some freq) is applied at dummy i/p pin. Do we have some documnt (board design) to understand how the IBIS data is interpreted by the signal integrity tool. Thanks again for your reply. Regards vinayak Andrew Ingraham wrote: >>I had this query as to why we need to model the buffers with R-load >>as in most of the cases it is c-load w/without TL line is >>driven by the buffer). >> >>does it reflect on the TL impedence that it drives? (50ohm environment) >> >> > >I think you hit the nail right on the head. > >If the buffer drives a transmission line that is 3 ns long, the device sees >an effective load of Zo (typically in the vicinity of 50-80 ohms) for the >first 6 ns after it switches. > >Regards, >Andy > > >----------------------------------------------------------------- >|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 > > - --------------010007090106050902040308 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Andy,

Thanks for clarifying this.

The other concern i had was
a. How does the  V/T data(Ramp) and I/V data
get used up at the boardlevel when simulted by a tool.

As far as my knowledge goes ramp rate is imp but not V/T data
for o/p and bidi buffers. I/V data generally depicts the drive strength
of a buffer, how does this correlate into tranisient behaviour by
board level tool when data(swicthing from 1 to 0 and 0 to 1 at some freq)
is applied at dummy i/p pin.

Do we have some documnt (board design) to understand how the IBIS data
is interpreted by the signal integrity tool.

Thanks again for your reply.

Regards
vinayak

Andrew Ingraham wrote: 
I had this query as to why we need to model the buffers with R-load
as in most of the cases it is c-load w/without TL line is
driven by the buffer).

does it reflect on the TL impedence that it drives? (50ohm environment)
    

I think you hit the nail right on the head.

If the buffer drives a transmission line that is 3 ns long, the device sees
an effective load of Zo (typically in the vicinity of 50-80 ohms) for the
first 6 ns after it switches.

Regards,
Andy


- -----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|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

- --------------010007090106050902040308-- |------------------------------------------------------------------ |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, 23 Dec 2005 09:06:22 -0700 From: rrwolff@micron.com Subject: [IBIS-Users] [IBIS] Open forum minutes (12/16/05) This is a multi-part message in MIME format. - ------_=_NextPart_001_01C607DA.D18F6485 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C607DA.D18F6485" - ------_=_NextPart_002_01C607DA.D18F6485 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached are the minutes of the Friday, December 16, 2005 IBIS Open Forum teleconference. Randy Wolff IBIS Open Forum Secretary <>=20 - ------_=_NextPart_002_01C607DA.D18F6485 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [IBIS] Open forum minutes (12/16/05)

Attached are the minutes of the = Friday, December 16, 2005 IBIS Open Forum teleconference.

Randy Wolff
IBIS Open Forum Secretary

= <<m121605.txt>>


- ------_=_NextPart_002_01C607DA.D18F6485-- - ------_=_NextPart_001_01C607DA.D18F6485 Content-Type: text/plain; name="m121605.txt" Content-Transfer-Encoding: base64 Content-Description: m121605.txt Content-Disposition: attachment; filename="m121605.txt" REFURTogMTIvMjEvMDUNCg0KU1VCSkVDVDogRGVjZW1iZXIgMTYsIDIwMDUgRUlBIElCSVMgT3Bl biBGb3J1bSBNZWV0aW5nIE1pbnV0ZXMNCg0KVk9USU5HIE1FTUJFUlMgQU5EIDIwMDUgUEFSVElD SVBBTlRTDQpBY3RlbCAgICAgICAgICAgICAgICAgICAgICAgICAgICBQcmFiaHUgTW9oYW4NCkFn ZXJlICAgICAgICAgICAgICAgICAgICAgICAgICAgIChOaXJhdiBQYXRlbCkNCkFNRCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFdhc2ltIFVsbGFoDQpBbnNvZnQgQ29ycG9yYXRpb24gICAg ICAgICAgICAgICBNaWNoYWVsIEJyZW5uZW1hbiwgSmFjayBRaXUsIFpoaWJpbiBMaQ0KQXBwbGll ZCBTaW11bGF0aW9uIFRlY2hub2xvZ3kgICAgTm9yaW8gTWF0c3VpDQpDYWRlbmNlIERlc2lnbiBT eXN0ZW1zICAgICAgICAgICBMYW5jZSBXYW5nLCBbRG9uYWxkIFRlbGlhbl0sDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEhlaWtvIER1ZGVrLCBTaGFuZ2xpIFd1LA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEcmFnb3NsYXYgTWlsb3NldmVjLCBLZW4gV2ls bGlzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMYW5iaW5nIENoZW4sIEd1 YW5nbGkgSnUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRha2FkYSBOb3Jp a2F6dSwgSGFpdGFvIFllLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaaGFu Z21pbiBaaG9uZywgS2UgWHUNCkNpc2NvIFN5c3RlbXMgICAgICAgICAgICAgICAgICAgIFN5ZWQg SHVxKiwgTWlrZSBMYUJvbnRlLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBU b2RkIFdlc3RlcmhvZmYsIFtaaGlwaW5nIFlhbmddLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBWaW51IEFybXVtdWdoYW0sIFNhbG1hbiBKaXZhLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBTYXRpc2ggUHJhdGFwbmVuaSwgSWwteW91bmcgUGFyaywNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VyZ2lvIENhbWVybG8sIFBoaWxsaXBl IFNvY2hvdXgsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVkZGllIFd1LCBH dXJwcmVldCBIdW5kYWwsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpheWFu dGhpIE5hdGFyYWphbiwgQWJkdWxSYWhtYW4gUmFmaXEsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEJpbGwgQ2hlbg0KRmx1ZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAg KENoZXRhbiBEZXNhaSkNCkZyZWVzY2FsZSAgICAgICAgICAgICAgICAgICAgICAgIEpvbiBCdXJu ZXR0DQpHcmVlbiBTdHJlYWsgUHJvZ3JhbXMgICAgICAgICAgICBMeW5uZSBHcmVlbioNCkhpdGFj aGkgVUxTSSBTeXN0ZW1zICAgICAgICAgICAgIEthenV5b3NoaSBTaG9qaQ0KSHVhd2VpIFRlY2hu b2xvZ2llcyAgICAgICAgICAgICAgWGlhbmd6aG9uZyBKaWFuZywgSmluIENoZW4sDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1biBDaGVuLCBGZW4gRGFpLCBaaGlnYW8gRGVu ZywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWXVtaW5nIER1LCBNaW5nIEZ1 LCBKaWFuIEhhbywgQm8gSGUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFpv bmdiaW4gSG9uZywgRGFveHVlIEh1LCBIb25nbWVpIEh1LA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBKaW4gSHUsIFBlbmcgSHUsIFFpbmdodSBIdSwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQnJ1Y2UgSHVhbmcsIFZpY2t5IEh1YW5nLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBXYW5ldGEgSHVhbmcsIFdlbmdpYW5nIEh1YW5nLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYaWJpbiBIdWFuZywgRGFiaW4gSmks IFJvbmdodWEgSmlhLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKaWFuZ3l1 IEppYW8sIEhvbmdsaW4gTGVpLCBBdXlpbmcgTGksDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEppbmp1biBMaSwgSnVuIExpLCBRaWFuZyBMaSwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2hhbnpob25nIExpLCBTaGl5aW5nIExpLCBaaGVuaG9uZyBMaSwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVHJhY3kgTGl1LCBXZWlkb25nIExp dSwgWW9uZyBMaSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWXVwaW5nIExp dSwgWmhvbmd5dSBNYW8sIEthbmdodWEgT3UsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFFpbmdzaGFuIFF1YW4sIEFteSBUYW5nLCBTaGVuZyBUYW5nLA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTdGVwaGVuIFdhbmcsIFhpYW9kb25nIFdhbmcsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFpodWxpbiBXZWksIEhvbmdMaWFuZyBZYW5n LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBRaW5nc29uZyBZZSwgSG9uZ2No ZW5nIFlpbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSmlhbiBaaGFuZywg S3VuIFpoYW5nLCBTaGVuZ2xpIFpoYW5nLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBIb25nIFpoZW4sICBZYW4gWmh1DQogICBIaVNpbGljb24gVGVjaG5vbG9naWVzICAgICAg ICBKaWFuIEhhbywgTGVvIEh1DQogICBIdWF3ZWktM0NvbSBUZWNobm9sb2dpZXMgICAgICBTdGVw aGVuIEN1aSwgRGFvWHVlIEh1LCBKaWFuSnVuIEx1LA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBKdW4gTWFvLCBCbyBXYW5nLCBNaW5nYW4gWGlhbmcsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFFpbmd4aSBaaGFuZywgV2VuaHVhIFpodQ0KSW50ZWdyYXRl ZCBDaXJjdWl0IFN5c3RlbXMgKElDUykgKERhbiBDbGVtZW50aSkNCkludGVsIENvcnBvcmF0aW9u ICAgICAgICAgICAgICAgIE1pY2hhZWwgTWlybWFrLCBBcnBhZCBNdXJhbnlpLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTdXJlc2ggQ2hhbmRyYXNla2hhciwgQmlsbCBHb25n LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBLdWVuIFlldyBMYW0sIEZhbmdo dSBMaSwgRGFuIExpdSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmFuZyBM diwgS2l0dHkgWWUsIFhpbmp1biBaaGFuZw0KTFNJIExvZ2ljICAgICAgICAgICAgICAgICAgICAg ICAgRnJhbmsgR2FzcGFyaWssIFdpbGxpYW0gTGF1LA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBNaWtlIEplbmtpbnMsIFJlZ2luYWxkIENvd2xleSwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgS3VzdW1ha3VtYXJpIE1hdHRhLCBLaW0gSGVsbGl3ZWxsKg0K TWFydmVsbCAgICAgICAgICAgICAgICAgICAgICAgICAgSXR6aWsgUGVsZWcqDQpNZW50b3IgR3Jh cGhpY3MgICAgICAgICAgICAgICAgICBKb2huIEFuZ3VsbyosIEd1eSBkZSBCdXJnaCwgSWFuIERv ZGQqLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdGV2ZW4gTWNLaW5uZXks IEtpbSBPd2VuLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVwaGFuZSBS b3Vzc2VhdSwgSGVucnkgTGksIFlhbiBMaXUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFZpdmlhbiBQYW4sIERhbm55ICBQZXJuZywgTGlmdSBZb3UsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFRvbnkgWmhvdQ0KTWljcm9uIFRlY2hub2xvZ3kgICAgICAg ICAgICAgICAgUmFuZHkgV29sZmYqLCBQYXVsIEdyZWdvcnksIEJvYiBDb3gNCk5FQyBFbGVjdHJv bmljcyBDb3Jwb3JhdGlvbiAgICAgIFRha2VzaGkgV2F0YW5hYmUsIExvcmkgQXNrZXcsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRha3VybyBUc3VqaWthd2ENClBhbmFzb25p YyAgICAgICAgICAgICAgICAgICAgICAgIEF0c3VqaSBJdG8NClNhbXRlYyAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtPdHRvIEJlbm5pZ10NClNpZW1lbnMgQUcgICAgICAgICAgICAgICAgICAg ICAgIEVja2hhcmQgTGVuc2tpKiwgS2F0amEgS29sbGVyLA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBNYW5mcmVkIE1hdXJlciwgSGVpbnogSWJvd3NraSwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgV29sZmdhbmcgUm9obWVyLCBLbGF1cyBIdWVibmVyDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwgS2luZGlqDQogICBTaWVt ZW5zIE1lZGljYWwgICAgICAgICAgICAgICBEYXZpZCBMaWVieQ0KU2lnbmFsIEludGVncml0eSBT b2Z0d2FyZSAgICAgICAgW1JvYmVydCBIYWxsZXJdLCBEb3VnbGFzIEJ1cm5zLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBCYXJyeSBLYXR6LCBNaWtlIE1heWVyDQpTaWdyaXR5 ICAgICAgICAgICAgICAgICAgICAgICAgICBTYW0gQ2hpdHdvb2QsIEppbmcgVGluZywgUmF5bW9u ZCBDaGVuLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKaWFndWFuIEZhbmcs IFRlbyBZYXRtYW4sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwg TGVpbnMsIEpvZSBZdQ0KU2lsZWdvICAgICAgICAgICAgICAgICAgICAgICAgICAgKEpvZSBGcm9u aWV3c2tpKQ0KU2lsaWNvbiBJbWFnZSAgICAgICAgICAgICAgICAgICAgKE9vayBLaW0pDQpTVE1p Y3JvZWxlY3Ryb25pY3MgICAgICAgICAgICAgICBBbnRvbmlvIEdpcmFyZGkNClN5bm9wc3lzICAg ICAgICAgICAgICAgICAgICAgICAgIFdhcnJlbiBXb25nLCBBbmR5IFRhaSwgU2h1bG9uZyBXdQ0K VGVyYXNwZWVkIENvbnN1bHRpbmcgR3JvdXAgICAgICAgQm9iIFJvc3MqLCBTY290dCBNY01vcnJv dywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVG9tIERhZ29zdGlubw0KVGV4 YXMgSW5zdHJ1bWVudHMgICAgICAgICAgICAgICAgT3RpcyBHb3JsZXkNClhpbGlueCAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJheSBBbmRlcnNvbiwgU2FuamF5IE1laHRhDQpadWtlbiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBNaWNoYWVsIFNjaGFlZGVyLCBSYWxmIEJydWVuaW5nLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQYXRyaWNrIEZhbmcsIEhvbmdydW4g TGkNCg0KT1RIRVIgUEFSVElDSVBBTlRTIElOIDIwMDU6DQpBbHRlcmEgICAgICAgICAgICAgICAg ICAgICAgICAgICBLaGFsaWQgQW5zYXJpDQpBcHBsZSBDb21wdXRlciAgICAgICAgICAgICAgICAg ICBaaGlwaW5nIFlhbmcNCkJheXNpZGUgRGVzaWduICAgICAgICAgICAgICAgICAgIEtldmluIFJv c2VsbGUNCkJlaWppbmcgUGVraW5nIFVuaXZlcnNpdHkgICAgICAgIENodW5mZW5nIExpLCBKaWFu aHVhIExpYW5nLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKaW5nbGluIEx1 YSwgU2hlbmd5b25nIFBlbmcsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpp bmcgU3VuDQpDZWxzaW9uaVggICAgICAgICAgICAgICAgICAgICAgICBLZWxsZWUgQ3Jpc2FmdWxs aQ0KQ2hpbmEgSW50ZWdyYXRlZCBDaXJjdWl0cyAgICAgICAgTGl5b3VuZyBEaW5nDQpEZWxsICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBdWJyZXkgU3BhcmttYW4NCkVETiBDaGluYSAgICAg ICAgICAgICAgICAgICAgICAgIFRyYWN5IFRhbmcNCkVFIFRpbWVzIENoaW5hICAgICAgICAgICAg ICAgICAgIExha2VyIFB1LCBNZWxvZHkgWmhhbw0KICAoR2xvYmFsIFNvdXJjZXMgYW5kIENNUCkN CkVNQyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJyaWFuIEFyc2VuYXVsdCwgRGFuaWVs IE5pbHNzb24sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEphc29uIFByaXRj aGFyZCwgSmluaHVhIENoZW4NCkVudGVyYXN5cyBOZXR3b3JrcyAgICAgICAgICAgICAgIFtGYWJy aXppbyBaYW5lbGxhXSwgQm9iIEhhbGxlcioNCkVQRkwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEFsYWluIFZhY2hvdXgNCkZpYmVyaG9tZSBUZWxlY29tbXVuaWNhdGlvbnMgICAgIFFpYW4g TGlhbywgV2FvIFRhbmcsIFdlbldlaSBYaWFvLA0KICAgVGVjaG5vbG9naWVzICAgICAgICAgICAg ICAgICAgICAgUWkgWmhlbmcNCkZveGNvbm4gVGVjaG5vbG9neSBHcm91cCAgICAgICAgIEVyaWMg TGVlLCBTY290dCBMaW4sIEZyZWQgT3UsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZyZWQgUWksIEtldmluIFdhbmcsIEphc29uIFpoYW5nDQpGdWppdHN1IFNpZW1lbnMgQ29t cHV0ZXJzICAgICAgICBNYXJ0aW4gUmFtbWUNCkdFSUEgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChDaHJpcyBEZW5oYW0pDQpHbG9iYWwgRW5naW5lZXJpbmcgU29sdXRpb25zICAgICBaZW4g TGlhbw0KSUJNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSC4gSm9obiBCZWF0dHkNCklu ZmluZW9uIFRlY2hub2xvZ2llcyBBRyAgICAgICAgIFRob21hcyBTdGVpbmVja2UsIE1pbmVhIEdv c3BvZGlub3ZhLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbWlyIE1vdGFt ZWRpLCBZYW5uIFppbnNpdXMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENo cmlzdGlhbiBTcG9ycmVyLCBSYWRvdmFuIFZ1bGV0aWMNCklOU0EgVG91bG91c2UgICAgICAgICAg ICAgICAgICAgIEV0aWVubmUgU2ljYXJkDQpKRUlUQSAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUb3NoaXJvIEhvbmRhDQpKTUQgSW50ZXJuYXRpb25hbCAgICAgICAgICAgICAgICBKb2UgU29j aGENCktBVy9KYXBhbiAgICAgICAgICAgICAgICAgICAgICAgIEthenVoaWtvIEt1c3Vub2tpDQpM ZW5vdm8gICAgICAgICAgICAgICAgICAgICAgICAgICBXZWkgS2FuZywgV2VueGluIExpbg0KTGV2 ZW50aGFsIERlc2lnbiAgICAgICAgICAgICAgICAgUm95IExldmVudGhhbA0KTHluZ3VlbnQgICAg ICAgICAgICAgICAgICAgICAgICAgQW5kcmV3IExldnkNCk5ldExvZ2ljICAgICAgICAgICAgICAg ICAgICAgICAgIEVyaWMgSHN1DQpOb2tpYSAgICAgICAgICAgICAgICAgICAgICAgICAgICBFcm5v IExhaHRlZW5tYXRpLCBUYXBhbmkgdm9uIFJhdW5lcg0KTm9ydGggQ2Fyb2xpbmEgU3RhdGUgVW5p di4gICAgICAgQW1icmlzaCBWYXJtYQ0KUG9saXRlY25pbyBkaSBUb3Jpbm8gICAgICAgICAgICAg SWdvciBTdGlldmFubw0KUURJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmFuZyBZYW5n LCBGZW4gWWFuZw0KU2hlbnpoZW4gQnVyZWF1IG9mIFNjaWVuY2UsICAgICAgSmlhbiBMdQ0KICAg VGVjaG5vbG9neSAmIEluZm9ybWF0aW9uDQpTaTIgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTdW1pdCBEYXNHdXB0YQ0KU2lsaWNvbiBCYW5kd2lkdGggICAgICAgICAgICAgICAgW0tpbSBI ZWxsaXdlbGxdDQpTdW4gTWljcm9zeXN0ZW1zICAgICAgICAgICAgICAgICBHdXN0YXZvIEJsYW5k bw0KVGFuZGVtIENvbnN1bHRpbmcgICAgICAgICAgICAgICAgSmFjayBMdW8NClRpbWUgRG9tYWlu IEFuYWx5c2lzIFN5c3RlbXMgICAgIERpbWEgU21vbHlhbnNreSwgU3RldmUgQ29yZXkNCiAgIChu b3cgVGVrdHJvbml4KQ0KVG9zaGliYSAgICAgICAgICAgICAgICAgICAgICAgICAgWWFzbWFzYSBL b25kbw0KVVRTdGFyY29tIFRlbGVjb20gQ28uICAgICAgICAgICAgWGlhbmdhbyBXZWksIEZlbmdY dWUgWWluZywgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERpbmd6aWFuZyBa aG91DQpXZXN0ZXJuIERpZ2l0YWwgICAgICAgICAgICAgICAgICBNb2hhbW1hZCBBbGkNClpURSBD b3Jwb3JhdGlvbiAgICAgICAgICAgICAgICAgIFl1bmhhbmcgR2FvLCBZdW5oYW5nIEdhbywNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2h1bm1laSBIdWFuZywgSHVpcWlhbmcg SmluZywgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEthbmcgTGksIFlvbmdG ZW5nIExpLCBDaHVuamllIExpdSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SmlhbiBQZW5nLCBMaW4gTmEgU2h1YW5nLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTaGlqdSBTdWksIEppdXpob3UgVGFuZywNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgWGluZ2hhaSBUYW5nLCBDaGFuZ2p1biBXYW5nLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBEYWd1byBXYW5nLCBYaWFubWVpIFdhbmcsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIExlaWppYSBYaW9uZywgWHVlcXVhbiBZdSwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hlbmdqdW4gWmhhbmcsIEhhaWxvbmcgWmhhbmcs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEl2YW4gWmhhbmcsIEx1IFpoYW5n LCBTaHVubGluIFpodQ0KSW5kZXBlbmRlbnQgICAgICAgICAgICAgICAgICAgICAgQmVybmhhcmQg VW5nZXIgKFNpZW1lbnMgcmV0aXJlZCksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtLaW0gSGVsbGl3ZWxsXQ0KVW5rbm93biAgICAgICAgICAgICAgICAgICAgICAgICAgWGlh b3l1biBCYW8sIENhbHRvbmcgTHVvDQoNCg0KSW4gdGhlIGxpc3QgYWJvdmUsIGF0dGVuZGVlcyBh dCB0aGUgbWVldGluZyBhcmUgaW5kaWNhdGVkIGJ5ICouDQpQcmluY2lwYWwgbWVtYmVycyBvciBv dGhlciBhY3RpdmUgbWVtYmVycyB3aG8gaGF2ZSBub3QgYXR0ZW5kZWQgYXJlIGluDQpwYXJlbnRo ZXNlcy4gUGFydGljaXBhbnRzIHdobyBubyBsb25nZXIgYXJlIGluIHRoZSBvcmdhbml6YXRpb24g YXJlIGluDQpzcXVhcmUgYnJhY2tldHMuDQoNClVQQ09NSU5HIE1FRVRJTkdTDQpUaGUgYnJpZGdl IG51bWJlcnMgZm9yIGZ1dHVyZSBJQklTIHRlbGVjb25mZXJlbmNlcyBhcmUgYXMgZm9sbG93czoN Cg0KICAgICAgIERhdGUgICAgICAgICAgICBUZWxlcGhvbmUgTnVtYmVyICAgIEJyaWRnZSAjICAg ICBQYXNzY29kZQ0KSmFudWFyeSA2LCAyMDA2ICAgICAgICAxLTkxNi0zNTYtMjY2MyAgICAgICAg MSAgICAgICAgICAyNjAtOTc0NA0KDQpBbGwgbWVldGluZ3MgYXJlIDg6MDAgQU0gdG8gOTo1NSBB TSBVUyBQYWNpZmljIFRpbWUuICBNZWV0aW5nIGFnZW5kYXMNCmFyZSB0eXBpY2FsbHkgZGlzdHJp YnV0ZWQgc2V2ZW4gZGF5cyBiZWZvcmUgZWFjaCBPcGVuIEZvcnVtLiAgTWludXRlcw0KYXJlIHR5 cGljYWxseSBkaXN0cmlidXRlZCB3aXRoaW4gc2V2ZW4gZGF5cyBvZiB0aGUgY29ycmVzcG9uZGlu Zw0KbWVldGluZy4gIFdoZW4gY2FsbGluZyBpbnRvIHRoZSBtZWV0aW5nLCBwcm92aWRlIHRoZSBi cmlkZ2UgbnVtYmVyIGFuZA0KcGFzc2NvZGUgYXQgdGhlIGF1dG9tYXRlZCBwcm9tcHRzLiAgSWYg YXNrZWQgYnkgYW4gb3BlcmF0b3IsIHBsZWFzZQ0KcmVxdWVzdCB0byBqb2luIHRoZSBJQklTIE9w ZW4gRm9ydW0gaG9zdGVkIGJ5IE1pY2hhZWwgTWlybWFrLg0KRm9yIGludGVybmF0aW9uYWwgZGlh bC1pbiBudW1iZXJzLCBwbGVhc2UgY29udGFjdCBNaWNoYWVsIE1pcm1hay4NCg0KTk9URTogIkFS IiA9IEFjdGlvbiBSZXF1aXJlZC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1N SU5VVEVTLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklOVFJPRFVDVElPTlMg QU5EIE1FRVRJTkcgUVVPUlVNDQpLaW0gSGVsbGl3ZWxsIG9mIExTSSBMb2dpYyBpbnRyb2R1Y2Vk IGhpbXNlbGYuICBIZSB3b3JrcyBpbiBhIHBhY2thZ2luZw0KZ3JvdXAgZG9pbmcgc2ltdWxhdGlv biBhbmQgbW9kZWxpbmcuICBCb2IgSGFsbGVyIGhhcyBqb2luZWQgdGhlIGNvcmUNCnJvdXRpbmcg Z3JvdXAgYXQgRW50ZXJhc3lzIFN5c3RlbXMuICBCb2IgaXMgYSBtb2RlbCB1c2VyIG5vdyBpbnN0 ZWFkIG9mIGENCm1vZGVsIGJ1aWxkZXIuIA0KDQoNCkNBTEwgRk9SIFBBVEVOVFMNClN5ZWQgSHVx IGNhbGxlZCBmb3IgYW55IHBhdGVudHMgb3IgcGVuZGluZyBwYXRlbnRzIHJlbGF0ZWQgdG8gdGhl IElCSVMNClZlcnNpb24gMy4yLCA0LjAsIDQuMSwgb3IgSUNNIDEuMSBzcGVjaWZpY2F0aW9ucy4g IE5vIHBhdGVudHMgd2VyZSBkZWNsYXJlZC4NCg0KDQpNRU1CRVJTSElQIFVQREFURSBBTkQgVFJF QVNVUkVSJ1MgUkVQT1JUDQpTeWVkIEh1cSByZXBvcnRlZCB0aGF0IG1lbWJlcnNoaXAgaW52b2lj ZXMgZm9yIDIwMDYgaGF2ZSBiZWVuIHNlbnQgb3V0IGJ5DQpHRUlBLg0KDQoNClJFVklFVyBPRiBN SU5VVEVTIEFORCBBUlMNClN5ZWQgSHVxIHJldmlld2VkIHRoZSBtaW51dGVzIG9mIHRoZSBOb3Zl bWJlciAxOCwgMjAwNSBJQklTIE9wZW4gRm9ydW0NCnRlbGVjb25mZXJlbmNlIGFuZCB0aGUgRGVj ZW1iZXIgNiwgMjAwNSBBc2lhbiBJQklTIE9wZW4gRm9ydW0gU3VtbWl0DQptZWV0aW5nLiAgQm9i IFJvc3MgcmVxdWVzdGVkIGFkZGluZyBLZSBYdSdzIG5hbWUgdW5kZXIgQ2FkZW5jZSBpbiB0aGUN CkFzaWFuIHN1bW1pdCBtaW51dGVzLiAgVGhlIG1pbnV0ZXMgd2VyZSBhcHByb3ZlZCB3aXRoIHRo ZXNlIGNoYW5nZXMuDQoNCg0KUFJFU1MgQU5EIFdFQiBQQUdFIFVQREFURVMNClN5ZWQgSHVxIHJl cG9ydGVkIHRoYXQgdGhlIERlc2lnbkNvbiBkYXRlIGhhcyBiZWVuIHVwZGF0ZWQgYW5kIHRoZSBB c2lhbiANCklCSVMgc3VtbWl0IGhhcyBiZWVuIG1vdmVkIHRvIHRoZSBib3R0b20gb2YgdGhlIGV2 ZW50cyBwYWdlLg0KDQoNCk1BSUxJTkcgTElTVCBBRE1JTklTVFJBVElPTg0KQm9iIFJvc3MgcmVw b3J0ZWQgdGhhdCBldmVyeXRoaW5nIGlzIHJ1bm5pbmcgbm9ybWFsbHksIGJ1dCB0aGVyZSBoYXZl IGJlZW4NCmEgbG90IG9mIGJvdW5jZXMgZnJvbSBBT0wgYWNjb3VudHMuICBUaGVzZSBhY2NvdW50 cyBtYXkgbmVlZCB0byBiZSBkcm9wcGVkLg0KDQoNCk5FVyBNT0RFTFMgQVZBSUxBQkxFLCBMSUJS QVJZIFVQREFURQ0KTm8gdXBkYXRlLg0KDQoNCk1JU0NFTExBTlkvQU5OT1VOQ0VNRU5UUw0KTm9u ZS4NCg0KDQpPUEVOUyBGT1IgTkVXIElTU1VFUw0KTm9uZS4NCg0KDQpJTlRFUk5BVElPTkFML0VY VEVSTkFMIFBST0dSRVNTDQpUaGVyZSBjb250aW51ZSB0byBiZSB0d28gcGVuZGluZyBzdGFuZGFy ZHMgdW5kZXIgY29uc2lkZXJhdGlvbiBieSB0aGUNCkludGVybmF0aW9uYWwgRWxlY3Ryb3RlY2hu aWNhbCBDb21taXNzaW9uIChJRUMpIHVuZGVyIHRoZSB0ZWNobmljYWwNCmNvbW1pdHRlZSBUQzQ3 LiAgRWFjaCBvZiB0aGVzZSBzdGFuZGFyZHMgaGF2ZSBsaW5rcyBiYWNrIHRvIElCSVMuICBXZSBh cmUNCnRoZSBhcHByb3ByaWF0ZSBjb21taXR0ZWUgdG8gcmV2aWV3IGFuZCBjb21tZW50IG9uIHRo ZXNlIGRvY3VtZW50cy4gIFRoZQ0KZG9jdW1lbnRzIGFyZSBhdmFpbGFibGUgZm9yIHRlY2huaWNh bCByZXZpZXcgZnJvbSBCb2IgUm9zcy4gIE1vcmUNCmluZm9ybWF0aW9uIGNhbiBiZSBmb3VuZCBh dCB0aGUgZm9sbG93aW5nIHVybDoNCg0KICAgICAgaHR0cDovL3d3dy5pZWMuY2gNCg0KVGhlIHR3 byBzdGFuZGFyZHMgYXJlOg0KDQpJRUM2MjQwNCBJL08gSW50ZXJmYWNlIE1vZGVsIGZvciBJbnRl Z3JhdGVkIENpcmN1aXRzIChJTUlDKSBhcyA0N0EvNzA0L0NEDQooY29tbWl0dGVlIGRyYWZ0KS4g IFRoaXMgaXMgYSBjb21wZXRpbmcgc3RhbmRhcmQgd2l0aCBJQklTIGFuZCBpcyBhbg0KZW5oYW5j ZW1lbnQgdG8gc3BpY2UgbGFuZ3VhZ2VzLg0KDQpNb2RlbHMgb2YgSW50ZWdyYXRlZCBDaXJjdWl0 cyBmb3IgRU1JIEJlaGF2aW9yYWwgU2ltdWxhdGlvbiA0N0EvNzE5L05QDQoobmV3IHdvcmsgcHJv cG9zYWwpLiBUaGlzIGlzIGEgZm9sbG93IG9uIHRvIElDRU0gKElDRU0gaXMgNjIwMTQtMykuDQoN Cg0KRUlBL0FOU0kgQVBQUk9WQUwgQUNUSVZJVElFUw0KUmFuZHkgV29sZmYgbWVudGlvbmVkIHRo YXQgdGhlIElDTSAxLjEgc3BlY2lmaWNhdGlvbiB3YXMgb2ZmaWNpYWxseSBhcHByb3ZlZA0KYXMg YSBHRUlBIHN0YW5kYXJkLiAgVGhlIHN0YW5kYXJkIGhhcyBiZWd1biB0aGUgQU5TSSBhcHByb3Zh bCBwcm9jZXNzLCBhbmQNCndlIHNob3VsZCBoZWFyIG1vcmUgYWJvdXQgaXRzIHN0YXR1cyBuZXh0 IG1vbnRoLiAgUmFuZHkgYnJpZWZseSBkaXNjdXNzZWQNCnR1cm5pbmcgdGhlIENvb2tib29rIHZl cnNpb24gNCBpbnRvIGFuIGVuZ2luZWVyaW5nIGJ1bGxldGluLiAgU3llZCBIdXENCnN1Z2dlc3Rl ZCB0aGF0IHdlIGRpc2N1c3MgdGhpcyBmdXJ0aGVyIGluIHRoZSBuZXh0IEZ1dHVyZXMgbWVldGlu ZywgYXMgDQpNaWNoYWVsIE1pcm1hayBwcm9iYWJseSBoYXMgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBob3cgd2Ugd291bGQgaGFuZGxlIA0KaGF2aW5nIGNvcGllcyBvZiB0aGUgY29va2Jvb2sgb24g b3VyIHdlYnNpdGUuDQoNCg0KU1VNTUlUUw0KDQotIEFzaWFuIElCSVMgU3VtbWl0DQogIFRoZSBT dW1taXQgd2FzIGhlbGQgRGVjZW1iZXIgNiwgMjAwNSBhdCB0aGUgQ3Jvd24gUGxhemEgSG90ZWwg aW4gU2hlbnpoZW4sDQogIENoaW5hIG5lYXIgSG9uZyBLb25nLiAgQm9iIFJvc3MgY29tbWVudGVk IHRoYXQgaXQgd2VudCB2ZXJ5IHdlbGwuICBUaGUNCiAgU3VtbWl0IG1pbnV0ZXMgaW5jbHVkZWQg YSBsaW5rIHRvIHRoZSBzdW1taXQgd2Vic2l0ZS4gIFRoaXMgc2l0ZSBub3cgaGFzDQogIHBpY3R1 cmVzIHBvc3RlZC4gIFRoZSBJQklTIGNvbW1pdHRlZSBsZWFkZXJzaGlwIGFuZCB0aGUgU3VtbWl0 IHNwb25zb3JzIA0KICBoYWQgbHVuY2ggd2l0aCA0IHJlcG9ydGVycyByZXByZXNlbnRpbmcgdGhy ZWUgQ2hpbmVzZSBlZGEgcGFwZXJzLiAgMTMgDQogIHByZXNlbnRhdGlvbnMgd2VyZSBrZXB0IG9u IHNjaGVkdWxlLiAgMTU1IHBlb3BsZSBhdHRlbmRlZCBvZmZpY2lhbGx5LiAgDQogIFN5ZWQgSHVx IG1lbnRpb25lZCB0aGF0IExhbmNlIFdhbmcgZGlkIGFuIGV4Y2VsbGVudCBqb2Igb2YgdHJhbnNs YXRpbmcgdGhlDQogIHByZXNlbnRhdGlvbnMgZnJvbSBDaGluZXNlIHRvIEVuZ2xpc2ggYW5kIHZp Y2UgdmVyc2EuICBUaGUgYm9va2xldA0KICBwcmludGluZyB3b3JrZWQgdmVyeSB3ZWxsLiAgQnJp bmdpbmcgaW4gYSBoaWdoZXIgbGV2ZWwgZ292ZXJubWVudCBvZmZpY2lhbA0KICBicm91Z2h0IHVw IGF0dGVuZGFuY2UuICBTeWVkIHRoYW5rZWQgQm9iIGZvciBhbGwgaGlzIHdvcmsgaW4gcGxhbm5p bmcgdGhlDQogIHN1bW1pdC4NCg0KLSBEZXNpZ25Db24NCiAgVGhlIERlc2lnbkNvbiBTdW1taXQg d2lsbCBiZSBoZWxkIFRodXJzZGF5IEZlYnJ1YXJ5IDksIDIwMDYgaW4gU2FudGENCiAgQ2xhcmEs IENhbGlmb3JuaWEuICBGcmVkIEJhbGlzdHJlcmkgd2lsbCBoYW5kbGUgdGhlIHJlZ2lzdHJhdGlv bi4gIEJvYg0KICBSb3NzIG1lbnRpb25lZCB0aGF0IENpc2NvIHdpbGwgYmUgYSBwcmltYXJ5IHNw b25zb3Igb2YgdGhlIGV2ZW50LiAgSXQgaXMNCiAgcGxhbm5lZCB0byBzZXR1cCB0aGUgSUJJUyBi b290aCBmb3IgVHVlc2RheSBhbmQgV2VkbmVzZGF5LiAgQm9vdGggc2V0dXANCiAgd2lsbCBuZWVk IHRvIGJlIGNvb3JkaW5hdGVkIHdpdGggTWVudG9yLiAgS2ltIEhlbGxpd2VsbCBtYXkgYmUgYWJs ZSB0bw0KICBoZWxwIG91dCB3aXRoIGJvb3RoIHNldHVwLiAgQm9iIGlzIHRoZSBtYWluIGNvbnRh Y3QgZm9yIHBhcGVyIGlkZWFzLg0KDQotIERBVEUNCiAgQm9iIFJvc3MgcmVwb3J0ZWQgdGhhdCBS YWxmIEJydWVuaW5nIGlzIGluIGNoYXJnZSBvZiBvcmdhbml6aW5nIHRoZSBEQVRFDQogIHN1bW1p dCwgYW5kIGhlIGhhcyBzZW50IG91dCB0aGUgZmlyc3QgYW5ub3VuY2VtZW50LiAgSXQgd2lsbCBi ZSBGcmlkYXksDQogIE1hcmNoIDEwLCAyMDA2LiAgRWNraGFyZCBMZW5za2kgbWVudGlvbmVkIHRo YXQgcm9vbSBhcnJhbmdlbWVudHMgYXJlDQogIGJlaW5nIG1hZGUuDQogIA0KLSBPdGhlcg0KICBC b2IgUm9zcyBtZW50aW9uZWQgdGhhdCB0aGVyZSBhcmUgb3Bwb3J0dW5pdGllcyBmb3Igb3RoZXIg c3VtbWl0cyBpbiBBc2lhDQogIGN1cnJlbnRseSBiZWluZyB0YWxrZWQgYWJvdXQuICANCg0KU3Bv bnNvcnNoaXAgb3Bwb3J0dW5pdGllcyBmb3IgRGVzaWduQ29uIGFuZCBEQVRFIGFyZSBzdGlsbCBh dmFpbGFibGUsIHdpdGgNCnNwb25zb3JzIHJlY2VpdmluZyBmcmVlIG1lbnRpb25zIGluIHRoZSBt aW51dGVzLCBhZ2VuZGEsIGFuZCBvdGhlcg0KYW5ub3VuY2VtZW50cy4NCg0KDQpJQklTIFFVQUxJ VFkgQ09NTUlUVEVFDQpCb2IgUm9zcyByZXBvcnRlZCB0aGF0IE1pa2UgTGFib250ZSB3aWxsIHNl cnZlIGFzIGEgdGVtcG9yYXJ5IGNoYWlyIGR1cmluZw0KdGhlIHRyYW5zaXRpb24gb2YgQm9iIEhh bGxlciBsZWF2aW5nIGFzIHRoZSBjaGFpci4gIFRoZXJlIHdhcyBhIG1lZXRpbmcNCkRlY2VtYmVy IDEzLCBhbmQgbWVldGluZ3MgYXJlIG9jY3VycmluZyBvbmNlIGEgbW9udGguICBKYW51YXJ5IDEw IHdpbGwgYmUNCnRoZSBuZXh0IG1lZXRpbmcuICBUaGV5IGFyZSBzdGlsbCBkaXNjdXNzaW5nIGNh dXRpb24gc3RhdGVtZW50cy4NCg0KVGhlIGxpbmsgdG8gdGhlIHF1YWxpdHkgY29tbWl0dGVlIGNo ZWNrbGlzdCBpcyBhdDoNCg0KICAgaHR0cDovL3d3dy5pYmlzLWluZm9ybWF0aW9uLm9yZy9xdWFs aXR5X3dpcC8NCg0KDQpJQklTIE1PREVMIFJFVklFVyBDT01NSVRURUUNCkx5bm5lIEdyZWVuIHJl cG9ydGVkIHRoYXQgbm8gbmV3IG1vZGVscyBoYXZlIGNvbWUgaW4uDQoNCg0KRlVUVVJFUyBBTkQg Q09PS0JPT0sgQ09NTUlUVEVFUw0KU3llZCBIdXEgcmVwb3J0ZWQgdGhhdCB0aGVyZSB3aWxsIGJl IGEgbWVldGluZyBuZXh0IHdlZWsuDQoNClJlY2VudCBjb21taXR0ZWUgbWF0ZXJpYWwgaXMgc3Rv cmVkIGF0Og0KDQogICBodHRwOi8vd3d3LmliaXMtaW5mb3JtYXRpb24ub3JnL2Z1dHVyZXMvDQoN Cg0KTUFDUk9NT0RFTElORyBMSUJSQVJZIENPTU1JVFRFRQ0KQm9iIFJvc3MgcmVwb3J0ZWQgdGhh dCB0aGUgbGFzdCBtZWV0aW5nIHdhcyBjYW5jZWxsZWQuICBUaGVyZSBpcyBpbnZvbHZlbWVudA0K b2YgYSBOQ1NVIHN0dWRlbnQgdG8gZG8gc29tZSBBTVMgY29kaW5nIG5vdy4gIA0KDQpDb21taXR0 ZWUgbWF0ZXJpYWwgY2FuIGJlIGZvdW5kIGF0IHRoZSBmb2xsb3dpbmcgdXJsOg0KDQogICAgICBo dHRwOi8vd3d3LmliaXMtaW5mb3JtYXRpb24ub3JnL21hY3JvbW9kZWxfd2lwLw0KDQoNCk5FVyBB RE1JTklTVFJBVElWRSBJU1NVRVMNCk5vbmUuDQoNCg0KQklSRDk3LjI6IEdBVEUgTU9EVUxBVElP TiBFRkZFQ1QNCk5vIGRpc2N1c3Npb24uDQoNCg0KQklSRDk4OiBHQVRFIE1PRFVMQVRJT04gRUZG RUNUIChUQUJMRSBGT1JNQVQpDQpTZWUgQklSRDk3LjIgZm9yIGRpc2N1c3Npb24gcmVsYXRlZCB0 byBCSVJEOTguDQoNCg0KQklSRDEwMDogQUxMT1cgQU5BTE9HLU9OTFkgKi1BTVMgTU9ERUwgVEVS TUlOQUxTDQpCb2IgUm9zcyByZXZpZXdlZCB0aGUgQklSRCBicmllZmx5LiAgSGUgbWVudGlvbmVk IHBlcmhhcHMgYWRkaW5nIG1vcmUNCmV4YW1wbGVzIHRvIHRoZSBCSVJEIG9mIFZIREwgY29kaW5n LCBhcyB0aGVyZSB3ZXJlIHR3byBub3RlcyBpbiB0aGUgQklSRA0KYWJvdXQgdGhpcyBwb3NzaWJp bGl0eS4gIElhbiBEb2RkIHdhcyBub3QgZW50aHVzaWFzdGljIGFib3V0IGFkZGluZyBtb3JlDQpl eGFtcGxlcywgYnV0IGhlIHdpbGwgd29yayB3aXRoIEFycGFkIE11cmFueWkgdG8gYWRkIGFuIGV4 YW1wbGUuDQoNCg0KQklSRDEwMTogU0VDVElPTiA2QiwgRklHVVJFIDEyIEVYQU1QTEUgTk9URQ0K Qm9iIFJvc3MgcmVwb3J0ZWQgdGhhdCB0aGUgcHVycG9zZSBvZiB0aGUgQklSRCBpcyB0byBhZGQg b25lIG5vdGUgYWJvdmUNCkZpZ3VyZSAxMiBkb2N1bWVudGluZyB0aGF0IHNvbWUgb2YgdGhlIG1h dGVyaWFsIGluIEZpZ3VyZSAxMiBpcyBub3QgcGFydCBvZg0KdGhlIGN1cnJlbnQgc3BlY2lmaWNh dGlvbi4gIFRoZXJlIGFyZSBzb21lIHBhZCB0byBwaW4gY29ubmVjdGlvbnMgaW4gdGhlDQpmaWd1 cmUgaW4gYW50aWNpcGF0aW9uIG9mIElDTSBsaW5rYWdlLCBob3dldmVyIHRoaXMgbGlua2FnZSBp cyBub3QgcGFydCBvZg0KdGhlIHNwZWNpZmljYXRpb24gY3VycmVudGx5LiAgVGhpcyBCSVJEIHdv dWxkIGJlIGNsZWFudXAgZm9yIElCSVMgdmVyc2lvbg0KNC4yLiAgVGhpcyBCSVJEIHdpbGwgYmUg cHV0IHVwIGZvciBhIHZvdGUgYXQgdGhlIG5leHQgSUJJUyBPcGVuIEZvcnVtDQptZWV0aW5nLg0K DQoNCklCSVNDSEs0IEJVRyBTVEFUVVMNCk5vIHVwZGF0ZS4NCg0KDQpJQ01DSEsxIEJVRyBTVEFU VVMNCkx5bm5lIEdyZWVuIHJlcG9ydGVkIHRoYXQgdGhlcmUgd2FzIHByZXZpb3VzbHkgYSByZXF1 ZXN0IHRvIGxvb2sgYXQgc2F2aW5nDQp0aGUgSUNNQ0hLMSBvdXRwdXQgdG8gYSBmaWxlLiAgU2hl IHNhaWQgdGhhdCBkZXRhaWxzIG9mIHRoaXMgYXJlIGFkZHJlc3NlZA0KaW4gdGhlIGhlbHAgZmls ZS4NCg0KDQpORVcgVEVDSE5JQ0FMIElTU1VFUw0KTm9uZS4NCg0KDQpORVhUIE1FRVRJTkcNClRo ZSBuZXh0IElCSVMgT3BlbiBGb3J1bSB0ZWxlY29uZmVyZW5jZSB3aWxsIGJlIGhlbGQgSmFudWFy eSA2LCAyMDA2IGZyb20NCjg6MDAgQU0gdG8gMTA6MDAgQU0gVVMgUGFjaWZpYyBUaW1lLiAgQSB2 b3RlIGlzIHNjaGVkdWxlZCBvbiBCSVJEMTAxLg0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOT1RFUw0KDQpJQklTIENIQUlSOiBNaWNoYWVs IE1pcm1hayAoOTE2KSAzNTYtNDI2MSwgRmF4OiAoOTE2KSAzNzctMTA0Ng0KICAgICAgICAgICAg bWljaGFlbC5taXJtYWtAaW50ZWwuY29tDQogICAgICAgICAgICBTZW5pb3IgQW5hbG9nIEVuZ2lu ZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbg0KICAgICAgICAgICAgRk02LTQ1DQogICAgICAgICAgICAx OTAwIFByYWlyaWUgQ2l0eSBSZC4NCiAgICAgICAgICAgIEZvbHNvbSwgQ0EgIDk1NjMwDQoNClZJ Q0UgQ0hBSVI6IFN5ZWQgSHVxICg0MDgpIDUyNS0zMzk5LCBGYXg6ICg0MDgpIDUyNi01NTA0DQog ICAgICAgICAgICBzaHVxQGNpc2NvLmNvbQ0KICAgICAgICAgICAgTWFuYWdlciwgSGFyZHdhcmUg RW5naW5lZXJpbmcsIENpc2NvIFN5c3RlbXMNCiAgICAgICAgICAgIDE3MCBXZXN0IFRhc21hbiBE cml2ZQ0KICAgICAgICAgICAgU2FuIEpvc2UsIENBIDk1MTM0LTE3MDYNCg0KU0VDUkVUQVJZOiAg UmFuZHkgV29sZmYgKDIwOCkgMzYzLTE3NjQsIEZheDogKDIwOCkgMzY4LTM0NzUNCiAgICAgICAg ICAgIHJyd29sZmZAbWljcm9uLmNvbQ0KICAgICAgICAgICAgU2ltdWxhdGlvbiBFbmdpbmVlciwg TWljcm9uIFRlY2hub2xvZ3ksIEluYy4NCiAgICAgICAgICAgIDgwMDAgUy4gRmVkZXJhbCBXYXkN CiAgICAgICAgICAgIE1haWwgU3RvcDogMDEtNzExDQogICAgICAgICAgICBCb2lzZSwgSUQgODM3 MDctMDAwNg0KDQpMSUJSQVJJQU46ICBMYW5jZSBXYW5nICg5NzgpIDI2Mi02Njg1LCBGYXg6ICg5 NzgpIDI2Mi02MzYzDQogICAgICAgICAgICBsd2FuZ0BjYWRlbmNlLmNvbQ0KICAgICAgICAgICAg U2VuaW9yIE1lbWJlciwgVGVjaG5pY2FsIFN0YWZmLCBDYWRlbmNlIERlc2lnbiBTeXN0ZW1zLCBJ bmMuDQogICAgICAgICAgICAyNzAgQmlsbGVyaWNhIFJvYWQNCiAgICAgICAgICAgIENoZWxtc2Zv cmQsIE1BIDAxODI0DQoNCldFQk1BU1RFUjogIFN5ZWQgSHVxICg0MDgpIDUyNS0zMzk5LCBGYXg6 ICg0MDgpIDUyNi01NTA0DQogICAgICAgICAgICBzaHVxQGNpc2NvLmNvbQ0KICAgICAgICAgICAg TWFuYWdlciwgSGFyZHdhcmUgRW5naW5lZXJpbmcsIENpc2NvIFN5c3RlbXMNCiAgICAgICAgICAg IDE3MCBXZXN0IFRhc21hbiBEcml2ZQ0KICAgICAgICAgICAgU2FuIEpvc2UsIENBIDk1MTM0LTE3 MDYNCg0KUE9TVE1BU1RFUjogQm9iIFJvc3MgKDUwMykgMjQ2LTgwNDgsIEZheCA6ICg1MDMpIDIz OS00NDAwDQogICAgICAgICAgICBib2JAdGVyYXNwZWVkLmNvbQ0KICAgICAgICAgICAgU3RhZmYg U2NpZW50aXN0LCBUZXJhc3BlZWQgQ29uc3VsdGluZyBHcm91cA0KICAgICAgICAgICAgMTAyMzgg U1cgTGFuY2FzdGVyIFJvYWQNCiAgICAgICAgICAgIFBvcnRsYW5kLCBPUiA5NzIxOQ0KDQoNClRo aXMgbWVldGluZyB3YXMgY29uZHVjdGVkIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgR0VJQSBMZWdh bCBHdWlkZXMgYW5kDQpHRUlBIE1hbnVhbCBvZiBPcmdhbml6YXRpb24gYW5kIFByb2NlZHVyZS4N Cg0KVGhlIGZvbGxvd2luZyBlLW1haWwgYWRkcmVzc2VzIGFyZSB1c2VkOg0KDQogIG1ham9yZG9t b0BlZGEub3JnDQogICAgICBJbiB0aGUgYm9keSwgZm9yIHRoZSBJQklTIE9wZW4gRm9ydW0gUmVm bGVjdG9yOg0KICAgICAgc3Vic2NyaWJlIGliaXMgPHlvdXIgZS1tYWlsIGFkZHJlc3M+DQoNCiAg ICAgIEluIHRoZSBib2R5LCBmb3IgdGhlIElCSVMgVXNlcnMnIEdyb3VwIFJlZmxlY3RvcjoNCiAg ICAgIHN1YnNjcmliZSBpYmlzLXVzZXJzIDx5b3VyIGUtbWFpbCBhZGRyZXNzPg0KDQogICAgICBI ZWxwIGFuZCBvdGhlciBjb21tYW5kczoNCiAgICAgIGhlbHANCg0KICBpYmlzLXJlcXVlc3RAZWRh Lm9yZw0KICAgICAgVG8gam9pbiwgY2hhbmdlLCBvciBkcm9wIGZyb20gZWl0aGVyIHRoZSBJQklT IE9wZW4gRm9ydW0gUmVmbGVjdG9yDQogICAgICAoaWJpc0BlZGEub3JnKSwgdGhlIElCSVMgVXNl cnMnIEdyb3VwIFJlZmxlY3Rvcg0KICAgICAgKGliaXMtdXNlcnNAZWRhLm9yZykgb3IgYm90aC4g IFN0YXRlIHlvdXIgcmVxdWVzdC4NCg0KICBpYmlzLWluZm9AZWRhLm9yZw0KICAgICAgVG8gb2J0 YWluIGdlbmVyYWwgaW5mb3JtYXRpb24gYWJvdXQgSUJJUywgdG8gYXNrIHNwZWNpZmljDQogICAg ICBxdWVzdGlvbnMgZm9yIGluZGl2aWR1YWwgcmVzcG9uc2UsIGFuZCB0byBpbnF1aXJlIGFib3V0 IGpvaW5pbmcNCiAgICAgIHRoZSBFSUEtSUJJUyBPcGVuIEZvcnVtIGFzIGEgZnVsbCBNZW1iZXIu DQoNCiAgaWJpc0BlZGEub3JnDQogICAgICBUbyBzZW5kIGEgbWVzc2FnZSB0byB0aGUgZ2VuZXJh bCBJQklTIE9wZW4gRm9ydW0gUmVmbGVjdG9yLiAgVGhpcw0KICAgICAgaXMgdXNlZCBtb3N0bHkg Zm9yIElCSVMgU3RhbmRhcmRpemF0aW9uIGJ1c2luZXNzIGFuZCBmdXR1cmUgSUJJUw0KICAgICAg dGVjaG5pY2FsIGVuaGFuY2VtZW50cy4gIEpvYiBwb3N0aW5nIGluZm9ybWF0aW9uIGlzIG5vdCBw ZXJtaXR0ZWQuDQoNCiAgaWJpcy11c2Vyc0BlZGEub3JnDQogICAgICBUbyBzZW5kIGEgbWVzc2Fn ZSB0byB0aGUgSUJJUyBVc2VycycgR3JvdXAgUmVmbGVjdG9yLiAgVGhpcyBpcw0KICAgICAgdXNl ZCBtb3N0bHkgZm9yIElCSVMgY2xhcmlmaWNhdGlvbiwgY3VycmVudCBtb2RlbGluZyBpc3N1ZXMs IGFuZA0KICAgICAgZ2VuZXJhbCB1c2VyIGNvbmNlcm5zLiAgSm9iIHBvc3RpbmcgaW5mb3JtYXRp b24gaXMgbm90IHBlcm1pdHRlZC4NCg0KICBpYmlzLWJ1Z0BlZGEub3JnDQogICAgICBUbyByZXBv cnQgaWJpc2NoayBwYXJzZXIgYnVncy4gIFRoZSBCdWcgUmVwb3J0IEZvcm0gUmVzaWRlcyBvbg0K ICAgICAgZWRhLm9yZyBpbiAvcHViL2liaXMvYnVncy9pYmlzX2J1Z3MvYnVnZm9ybS50eHQgYWxv bmcgd2l0aA0KICAgICAgcmVwb3J0ZWQgYnVncy4NCg0KICBpY20tYnVnQGVkYS5vcmcNCiAgICAg IFRvIHJlcG9ydCBpY21jaGsxIHBhcnNlciBidWdzLiAgVGhlIEJ1ZyBSZXBvcnQgRm9ybSBSZXNp ZGVzIG9uDQogICAgICBlZGEub3JnIGluIC9wdWIvaWJpcy9idWdzL2ljbV9idWdzL2ljbV9idWdm b3JtLnR4dCBhbG9uZyB3aXRoDQogICAgICByZXBvcnRlZCBidWdzLg0KDQogICAgICBUbyByZXBv cnQgczJpYmlzLCBzMmliaXMyIGFuZCBzMmlwbHQgYnVncywgdXNlIHRoZSBCdWcgUmVwb3J0DQog ICAgICBGb3JtcyB3aGljaCByZXNpZGUgdW5kZXIgZWRhLm9yZyBpbg0KICAgICAgL3B1Yi9pYmlz L2J1Z3MvczJpYmlzL2J1Z3MyaS50eHQsDQogICAgICAvcHViL2liaXMvYnVncy9zMmliaXMyL2J1 Z3MyaTIudHh0IGFuZA0KICAgICAgL3B1Yi9pYmlzL2J1Z3MvczJpcGx0L2J1Z3NwbHQudHh0IHJl c3BlY3RpdmVseS4NCg0KSW5mb3JtYXRpb24gb24gSUJJUyB0ZWNobmljYWwgY29udGVudHMsIElC SVMgcGFydGljaXBhbnRzIGFuZCBhY3R1YWwNCklCSVMgbW9kZWxzIGFyZSBhdmFpbGFibGUgb24g dGhlIElCSVMgSG9tZSBwYWdlOg0KDQogIGh0dHA6Ly93d3cuZWlncm91cC5vcmcvaWJpcy9pYmlz Lmh0bQ0KDQpDaGVjayB0aGUgSUJJUyBmaWxlIGRpcmVjdG9yeSBvbiBlZGEub3JnIGZvciBtb3Jl IGluZm9ybWF0aW9uIG9uDQpwcmV2aW91cyBkaXNjdXNzaW9ucyBhbmQgcmVzdWx0czoNCg0KICBo dHRwOi8vd3d3LmVkYS5vcmcvcHViL2liaXMvZGlyZWN0b3J5Lmh0bWwNCg0KQWxsIGVkYS5vcmcg ZG9jdW1lbnRzIGNhbiBiZSBhY2Nlc3NlZCB1c2luZyBhIG1pcnJvcjoNCg0KICBodHRwOi8vd3d3 LmliaXMtaW5mb3JtYXRpb24ub3JnDQoNCk5vdGUgdGhhdCB0aGUgInB1Yi9pYmlzIiB0ZXh0IHNo b3VsZCBiZSByZW1vdmVkIGZyb20gZGlyZWN0b3J5IG5hbWVzDQp3aGVuIHRoaXMgVVJMIG1pcnJv ciBpcyB1c2VkLg0KDQoqIE90aGVyIHRyYWRlbWFya3MsIGJyYW5kcyBhbmQgbmFtZXMgYXJlIHRo ZSBwcm9wZXJ0eSBvZg0KICB0aGVpciByZXNwZWN0aXZlIG93bmVycy4NCg0K - ------_=_NextPart_001_01C607DA.D18F6485-- |------------------------------------------------------------------ |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, 29 Dec 2005 17:27:02 -0600 From: "Dunbar, Tony" Subject: [IBIS-Users] Touchstone File Format Spec. This is a multi-part message in MIME format. - ------_=_NextPart_001_01C60CCF.601A4AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 The Touchstone File Format Specification copyright is held by the EIA/IBIS Open Forum. At least, as far as I can tell that's the case, given the footnote on the cover of the latest revision of the spec. I can find. =20 That revision is 'Rev 1.1', dated 10/1/2003, and is marked 'DRAFT'. =20 Is there anyone who can confirm that is the latest and current version? Is there any current work underway to move the spec. beyond the draft version? =20 I'm curious because the date seems so old to me and it's still in draft form after all this time. =20 Thanks! Tony - ------_=_NextPart_001_01C60CCF.601A4AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
The = Touchstone=20 File Format Specification copyright is held by the EIA/IBIS Open Forum. = At=20 least, as far as I can tell that's the case, given the footnote on the = cover of=20 the latest revision of the spec. I can find.
 
That = revision is=20 'Rev 1.1', dated 10/1/2003, and is marked = 'DRAFT'.
 
Is = there anyone=20 who can confirm that is the latest and current version? Is there any = current=20 work underway to move the spec. beyond the draft = version?
 
I'm = curious=20 because the date seems so old to me and it's still in draft form = after all=20 this time.
 
Thanks!
Tony
- ------_=_NextPart_001_01C60CCF.601A4AB0-- |------------------------------------------------------------------ |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, 29 Dec 2005 18:26:34 -0800 From: "Peters, Stephen" Subject: RE: [IBIS-Users] Touchstone File Format Spec. This is a multi-part message in MIME format. - ------_=_NextPart_001_01C60CE8.7426300A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tony: =20 Yes, the Touchstone File Format Spec doc is copyright by the EIA/IBIS Open Forum and rev 1.1 is the latest and current version. And yes, apparently version 1.1 was never officially voted on by the Open Forum. I found the following paragraph from the Sept. 12, 2003 Open Forum minutes (it was at this meeting the ICM spec was approved).=20 =20 Some concerns were raised regarding whether the Agilent Touchstone(TM) document written by the Open Forum required an approval vote. The Open Forum members agreed that, until further information was received from Agilent regarding the draft 1.2 document, no further action should be taken on approving the Agilent Touchstone(TM) document. =20 As far as I can tell, the rev 1.2 spec was never perused. Off hand, I cannot say what the difference between rev. 1.1 and 1.2 was, but I doubt it was major. =20 It might be worthwhile for the Open Forum to make rev 1.1 official. =20 Regards, Stephen Peters Intel Corp. =20 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Dunbar, Tony Sent: Thursday, December 29, 2005 3:27 PM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS-Users] Touchstone File Format Spec. =20 Hi, =20 The Touchstone File Format Specification copyright is held by the EIA/IBIS Open Forum. At least, as far as I can tell that's the case, given the footnote on the cover of the latest revision of the spec. I can find. =20 That revision is 'Rev 1.1', dated 10/1/2003, and is marked 'DRAFT'. =20 Is there anyone who can confirm that is the latest and current version? Is there any current work underway to move the spec. beyond the draft version? =20 I'm curious because the date seems so old to me and it's still in draft form after all this time. =20 Thanks! Tony - ------_=_NextPart_001_01C60CE8.7426300A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Tony:

 

   Yes, the Touchstone = File Format Spec doc is copyright by the EIA/IBIS Open Forum and rev 1.1 is = the latest and current version.  And yes, apparently version 1.1 was = never officially voted on by the Open Forum.  I found the following = paragraph from the Sept. 12, 2003 Open Forum minutes (it was at this meeting the = ICM spec was approved).

 

Some concerns were raised regarding whether the Agilent = Touchstone(TM)

document written by the Open Forum required an approval vote.  = The

Open Forum members agreed that, until further information was = received

from Agilent regarding the draft 1.2 document, no further action = should

be taken on approving the Agilent Touchstone(TM) = document.

 

As far as I can = tell, the rev 1.2 spec was never perused. Off hand, I cannot say what the = difference between rev. 1.1 and 1.2 was, but I doubt it was = major.

 

It might be = worthwhile for the Open Forum to make rev 1.1 official.

 

Regards,

  Stephen = Peters

  Intel = Corp.

 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Dunbar, Tony
Sent: Thursday, December = 29, 2005 3:27 PM
To: ibis-users@eda.org; ibis@eda.org
Subject: [IBIS-Users] = Touchstone File Format Spec.

 

Hi,

 

The Touchstone File Format Specification copyright = is held by the EIA/IBIS Open Forum. At least, as far as I can tell that's the = case, given the footnote on the cover of the latest revision of the spec. I = can find.

 

That revision is 'Rev 1.1', dated = 10/1/2003, and is marked 'DRAFT'.

 

Is there anyone who can confirm that is the latest = and current version? Is there any current work underway to move the spec. = beyond the draft version?

 

I'm curious because the date seems so old to = me and it's still in draft form after all this = time.

 

Thanks!

Tony

- ------_=_NextPart_001_01C60CE8.7426300A-- |------------------------------------------------------------------ |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, 30 Dec 2005 14:33:13 -0700 From: mhaque@micron.com Subject: [IBIS-Users] Fork-Endfork in IBIS EBD Models Hi All, When creating IBIS EBD model for multi die package, is multiple fork and endfork statement allowed for one main branch? For example if the device has 4 die and from each pad bondwires are connected to one external ball is it okay to describe the path description as below? Note the last fork-endfork statement. Is it necessary that the original path needs to be continued and therefore the path description has to end with a series path? [Path Description] QUAD_DIE_SIGNAL A1 Len=0 R=16.646m L=1.406n C=0.456p / |Substrate R, L and C Fork Len=0 R=10m L=1nH C=1p / |Bondwire r,l,c from pin A1 to U1, pad #21 Endfork Node U1.21 Fork Len=0 R=10m L=1nH C=1p / |Bondwire r,l,c from pin A1 to U2, pad #21 Endfork Node U2.21 Fork |Bondwire r,l,c from pin A1 to U3, pad #21 Len=0 R=10m L=1nH C=1p Endfork Node U3.21 Fork |Bondwire r,l,c from pin A1 to U4 , pad #21 Len=0 R=10m L=1nH C=1p Endfork Node U4.21 Best Regards Moshiul Haque Micron Technology Inc. |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Fri, 30 Dec 2005 13:51:04 -0800 From: "Tom Dagostino" Subject: RE: [IBIS-Users] Fork-Endfork in IBIS EBD Models There is a great example of this in the EBD section of the IBIS specification, its a good read. Also, you can always make a prototype file and pass it by the IBIS Golden Parser. Which is a good idea whenever you create an IBIS file. 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 mhaque@micron.com Sent: Friday, December 30, 2005 1:33 PM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS-Users] Fork-Endfork in IBIS EBD Models Hi All, When creating IBIS EBD model for multi die package, is multiple fork and endfork statement allowed for one main branch? For example if the device has 4 die and from each pad bondwires are connected to one external ball is it okay to describe the path description as below? Note the last fork-endfork statement. Is it necessary that the original path needs to be continued and therefore the path description has to end with a series path? [Path Description] QUAD_DIE_SIGNAL A1 Len=0 R=16.646m L=1.406n C=0.456p / |Substrate R, L and C Fork Len=0 R=10m L=1nH C=1p / |Bondwire r,l,c from pin A1 to U1, pad #21 Endfork Node U1.21 Fork Len=0 R=10m L=1nH C=1p / |Bondwire r,l,c from pin A1 to U2, pad #21 Endfork Node U2.21 Fork |Bondwire r,l,c from pin A1 to U3, pad #21 Len=0 R=10m L=1nH C=1p Endfork Node U3.21 Fork |Bondwire r,l,c from pin A1 to U4 , pad #21 Len=0 R=10m L=1nH C=1p Endfork Node U4.21 Best Regards Moshiul Haque Micron Technology Inc. |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Fri, 30 Dec 2005 19:23:56 -0800 From: "Mirmak, Michael" Subject: [IBIS-Users] Agenda, IBIS Open Forum teleconference for Jan. 6, 2006 IBIS Open Forum Meeting Agenda for January 6, 2005 Telephone Number Bridge Passcode 1-916-356-2663 1 260-9744 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 December 16, 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 EIA, ANSI Approval Activities Wolff - Status of ICM 1.1 Standardization under ANSI? - Cookbook as GEIA Engineering Bulletin? Summit Status All - Asian IBIS Summit Wrap-Up - DesignCon Summit (Feb. 6 -> 9) - DATE (Mar. 10) Task Group Reports - Quality Haller - Model Review Green - Futures Mirmak International Participation? - Cookbook Mirmak Reported Issues - Macromodeling Library Muranyi New Issues All 8:45 Technical Discussion BIRD97.2: Gate Modulation Effect Muranyi BIRD98: Gate Modulation Effect (table format) Muranyi BIRD100.1: Allow Pure Analog *-AMS Models Dodd/Muranyi BIRD101: Section 6b, Figure 12 Example Note Ross - Call for Vote IBISCHK4 BUG Status All ICMCHK1 BUG Status All New Technical Issues All 9:50 Wrap Up and Next Meeting Plans Mirmak - January 27, 2006 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, 2 Jan 2006 11:16:20 -0700 From: mhaque@micron.com Subject: RE: [IBIS] RE: [IBIS-Users] Fork-Endfork in IBIS EBD Models Hi Tom, Thanks for the information. I have tried with a prototype file and it passes the IBISCHK. The problem is that the description does not show any specific example for the multiple fork-end fork statement and I am not sure if the format of the path description is being interpreted correctly. For example if "Node" in the ebd file if used outside the fork statement it will still pass the IBISCHK parser without generating any warning due to floating node. I am trying to confirm if I use multiple fork and endfork statements the data will interpreted correctly by the EDA simulator or if I have to use a different format for example a dummy series section between every fork endfork statements to make it working properly. Best Regards Moshiul Haque Micron Technology Inc. - -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Tom Dagostino Sent: Friday, December 30, 2005 2:51 PM To: mhaque; ibis-users@eda.org; ibis@eda.org Subject: [IBIS] RE: [IBIS-Users] Fork-Endfork in IBIS EBD Models There is a great example of this in the EBD section of the IBIS specification, its a good read. Also, you can always make a prototype file and pass it by the IBIS Golden Parser. Which is a good idea whenever you create an IBIS file. 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 mhaque@micron.com Sent: Friday, December 30, 2005 1:33 PM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS-Users] Fork-Endfork in IBIS EBD Models Hi All, When creating IBIS EBD model for multi die package, is multiple fork and endfork statement allowed for one main branch? For example if the device has 4 die and from each pad bondwires are connected to one external ball is it okay to describe the path description as below? Note the last fork-endfork statement. Is it necessary that the original path needs to be continued and therefore the path description has to end with a series path? [Path Description] QUAD_DIE_SIGNAL A1 Len=0 R=16.646m L=1.406n C=0.456p / |Substrate R, L and C Fork Len=0 R=10m L=1nH C=1p / |Bondwire r,l,c from pin A1 to U1, pad #21 Endfork Node U1.21 Fork Len=0 R=10m L=1nH C=1p / |Bondwire r,l,c from pin A1 to U2, pad #21 Endfork Node U2.21 Fork |Bondwire r,l,c from pin A1 to U3, pad #21 Len=0 R=10m L=1nH C=1p Endfork Node U3.21 Fork |Bondwire r,l,c from pin A1 to U4 , pad #21 Len=0 R=10m L=1nH C=1p Endfork Node U4.21 Best Regards Moshiul Haque Micron Technology Inc. |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 - ----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.org |with the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Tue, 3 Jan 2006 09:33:38 -0800 From: "Muranyi, Arpad" Subject: [IBIS-Users] RE: [IBIS] Why IO buffer name is limited to a max of 20 characters This is a multi-part message in MIME format. - ------_=_NextPart_001_01C6108B.D56F6C12 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Venu, =20 This is rooted in the earlier versions of the spec when the line length was limited to 80 characters, and therefore we had limited space for each field on the lines of the [Pin] section. Now that the line length limit is 120 characters (if I am not mistaken), we could allow for=20 longer model names, but someone would need to write a BIRD for it. Do you want to volunteer? =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 ________________________________ From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of = Ummalaneni, Venu Babu (Venu) Sent: Thursday, December 22, 2005 5:47 AM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS] Why IO buffer name is limited to a max of 20 characters Hi All, =20 Is there any specific reason exist to restrict the IO buffer name to a = maximum of 20 chars in our IBIS standard? Can't we change this rule to = allow more than 20 chars as buffer name?=20 =20 Recently, I experienced some IO buffers which have more than 20 chars in = their names. So, I have to truncate the IBIS model name to support this = rule. If choice is given I do not want to truncate the IBIS model name.=20 =20 Thanks in advance, =20 Best Regards, Venu =20 - ------_=_NextPart_001_01C6108B.D56F6C12 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hspice vs IBIS model correlation at different = capacitive loads
Venu,
 
This is rooted in the earlier versions of the = spec=20 when
the line length was limited to 80 characters, and = therefore
we had limited space for each field on the = lines of=20 the
[Pin] section.  Now that the line length = limit is=20 120
characters (if I am not mistaken), we could = allow for=20
longer model names, but someone would need to = write=20 a
BIRD for it.  Do you want to=20 volunteer?
 
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
From: owner-ibis@eda.org=20 [mailto:owner-ibis@eda.org] On Behalf Of Ummalaneni, Venu Babu=20 (Venu)
Sent: Thursday, December 22, 2005 5:47 AM
To: = ibis-users@eda.org; ibis@eda.org
Subject: [IBIS] Why IO buffer = name is=20 limited to a max of 20 characters

Hi All,

 

Is there any = specific=20 reason exist to restrict the IO buffer name to a maximum of 20 chars in = our IBIS=20 standard? Can=92t we change this rule to allow more than 20 chars as = buffer name?=20

 

Recently, I = experienced=20 some IO buffers which have more than 20 chars in their names. So, I have = to=20 truncate the IBIS model name to support this rule. If choice is given I = do not=20 want to truncate the IBIS model name.

 

Thanks in=20 advance,

 

Best=20 Regards,

Venu

 

- ------_=_NextPart_001_01C6108B.D56F6C12-- |------------------------------------------------------------------ |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, 3 Jan 2006 10:01:05 -0800 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] RE: [IBIS] Why IO buffer name is limited to a max of 20 characters This is a multi-part message in MIME format. - ------_=_NextPart_001_01C6108F.AB0DF6BD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, the BIRD has already been written by Michael Mirmak it is BIRD93.1 =20 http://www.vhdl.org/pub/ibis/birds/bird93.1.txt =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 =20 ________________________________ From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On = Behalf Of Muranyi, Arpad Sent: Tuesday, January 03, 2006 9:34 AM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS-Users] RE: [IBIS] Why IO buffer name is limited to a max = of 20 characters Venu, =20 This is rooted in the earlier versions of the spec when the line length was limited to 80 characters, and therefore we had limited space for each field on the lines of the [Pin] section. Now that the line length limit is 120 characters (if I am not mistaken), we could allow for=20 longer model names, but someone would need to write a BIRD for it. Do you want to volunteer? =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 ________________________________ From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of = Ummalaneni, Venu Babu (Venu) Sent: Thursday, December 22, 2005 5:47 AM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS] Why IO buffer name is limited to a max of 20 characters Hi All, =20 Is there any specific reason exist to restrict the IO buffer name to a = maximum of 20 chars in our IBIS standard? Can't we change this rule to = allow more than 20 chars as buffer name?=20 =20 Recently, I experienced some IO buffers which have more than 20 chars in = their names. So, I have to truncate the IBIS model name to support this = rule. If choice is given I do not want to truncate the IBIS model name.=20 =20 Thanks in advance, =20 Best Regards, Venu =20 - ------_=_NextPart_001_01C6108F.AB0DF6BD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hspice vs IBIS model correlation at different = capacitive loads
Sorry, the BIRD has already been written by = Michael=20 Mirmak
it is BIRD93.1
 
http://www.vhdl.= org/pub/ibis/birds/bird93.1.txt
 
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
 

From: owner-ibis-users@eda.org=20 [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi,=20 Arpad
Sent: Tuesday, January 03, 2006 9:34 AM
To:=20 ibis-users@eda.org; ibis@eda.org
Subject: [IBIS-Users] RE: = [IBIS] Why=20 IO buffer name is limited to a max of 20 characters

Venu,
 
This is rooted in the earlier versions of the = spec=20 when
the line length was limited to 80 characters, and = therefore
we had limited space for each field on the = lines of=20 the
[Pin] section.  Now that the line length = limit is=20 120
characters (if I am not mistaken), we could = allow for=20
longer model names, but someone would need to = write=20 a
BIRD for it.  Do you want to=20 volunteer?
 
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
From: owner-ibis@eda.org=20 [mailto:owner-ibis@eda.org] On Behalf Of Ummalaneni, Venu Babu=20 (Venu)
Sent: Thursday, December 22, 2005 5:47 AM
To: = ibis-users@eda.org; ibis@eda.org
Subject: [IBIS] Why IO buffer = name is=20 limited to a max of 20 characters

Hi All,

 

Is there any = specific=20 reason exist to restrict the IO buffer name to a maximum of 20 chars in = our IBIS=20 standard? Can=92t we change this rule to allow more than 20 chars as = buffer name?=20

 

Recently, I = experienced=20 some IO buffers which have more than 20 chars in their names. So, I have = to=20 truncate the IBIS model name to support this rule. If choice is given I = do not=20 want to truncate the IBIS model name.

 

Thanks in=20 advance,

 

Best=20 Regards,

Venu

 

- ------_=_NextPart_001_01C6108F.AB0DF6BD-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 04 Jan 2006 11:36:35 +0530 From: Vinayak Ghatawade Subject: Re: [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at different capacitive loads Hi all, I had this query where in if the buffer is going to be used for shorter TL (transmission line) then do we need to generate the V-T data with C-load rather than R-load since the buffer rise time is comparable to TL delay. We have this case where in the *buffer has feedback* and with R-load we see V-T table with lot of ringing(oscillations) when pad has reached steady state. As this is no real situation for us as TL delay that buffer would see in real world is too small comparable to buffer tr/tf. How do we generate the V-T data in this case. Should we use C-load instead of R-load or we release the V-T data with some oscillations when pad reaches steady state. Does simulator really have a problem seeing such V-T data. Thanks vinayak Ummalaneni, Venu Babu (Venu) wrote: >Itzik Peleg and all, > > > >Thank you very much for your help. Please see my answers in line with your comments. > > > >1. This buffer operation is intended for a load resistance of more than 5k ohm. > >2. Yes, you are right. I should allow more transient simulation time for min corner. > >However, reported behavior (correlation of hspice vs IBIS) is for typ corner. > > > >Even I have tried with 50, 100, 500 & 5k ohm terminations for capturing V-t waveforms. But I could not see any improvement in the correlation. I am still investigating this issue. > > > > > > Thanks & Best Regards, > >Venu > > -----Original Message----- > *From:* Itzik Peleg [mailto:itzikpe@marvell.com] > *Sent:* Thursday, December 15, 2005 7:09 PM > *To:* Ummalaneni, Venu Babu (Venu); ibis-users@eda.org; ibis@eda.org > *Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model > correlation at different capacitive loads > > Hello Venu > > Here are my comments reviewing your model: > > 1. The loading condition is 1k ohm !? isn’t this buffer should be used > in 50 ohm environment? If the answer is yes then you should use 50 ohm. > > 2. It seems like the slow didn’t finish the complete transition. You > should allow more time for the V(t) simulation in order that the > response get to steady state (like the maximum case in red). This also > causing the warning that you have when using IBIS check: > > ************************************************************** > > WARNING - Model ATA4N1K000: The [Rising Waveform] > > with [R_fixture]=1000 Ohms and [V_fixture_min]=0V > > has MIN column DC endpoints of 0.00V and 2.78v, but > > an equivalent load applied to the model's I-V tables yields > > different voltages (-0.00V and 2.92V), > > a difference of 0.00% and 4.69%, respectively. > > WARNING - Model ATA4N1K000: The [Falling Waveform] > > with [R_fixture]=1000 Ohms and [V_fixture_min]=3V > > has MIN column DC endpoints of 0.21V and 3.00v, but > > an equivalent load applied to the model's I-V tables yields > > different voltages ( 0.05V and 3.00V), > > a difference of 5.54% and 0.00%, respectively. > > **************************************************************** > > 3. Based on the 2 previous points I can think of a buffer for slow > interface that should be used in 50 ohm environment. If this is the > case you should allow the transient simulation more time on 50 ohm. > > Hope this will halp. > >-- > >Regards > > > >Itzik Peleg > >Board Technology Group > > > >Marvell Semiconductor Israel Ltd > >6 Hamada Street > > > > >Mordot HaCarmel Industrial Park > > > >Yokneam 20692, ISRAEL > > > >Email - itzikpe@marvell.com > >Tel - +972 4 9091192 > >Cell - +972 54 4452482 > >Fax - +972 4 9091501 > >WWW Page: http://www.marvell.com > >======================================================================== > >This message may contain confidential, proprietary or legally privileged > >information. The information is intended only for the use of the > >individual or entity named above. If the reader of this message is not > >the intended recipient, you are hereby notified that any dissemination, > >distribution or copying of this communication is strictly prohibited. > >If you have received this communication in error, please notify us > >immediately by telephone, or by e-mail and delete the message from > >your computer. > > > >Thank you! > >======================================================================== > > ------------------------------------------------------------------------ > > *From:* Ummalaneni, Venu Babu (Venu) [mailto:venubabu@agere.com] > *Sent:* Thursday, December 15, 2005 1:07 PM > *To:* Itzik Peleg; Todd Westerhoff (twesterh); ibis-users@eda.org; > ibis@eda.org > *Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model > correlation at different capacitive loads > >Itzik Peleg, > > > >Thanks for your concern. I think there is no such feedback. > > > >Here, I am attaching the IBIS model. > > > >Thanks & Regards, > >Venu > > -----Original Message----- > *From:* Itzik Peleg [mailto:itzikpe@marvell.com] > *Sent:* Wednesday, December 14, 2005 12:50 PM > *To:* Ummalaneni, Venu Babu (Venu); Todd Westerhoff (twesterh); > ibis-users@eda.org; ibis@eda.org > *Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model > correlation at different capacitive loads > > Hello Venu > > Just to add one more possibility doe’s your buffer has a feedback? > > Could you attached the IBIS model, or show the I(V) and V(t) curves? > >-- > >Regards > > > >Itzik Peleg > >Board Technology Group > > > >Marvell Semiconductor Israel Ltd > >6 Hamada Street > > > > > > > > > > > > > > > > > > > > >Mordot HaCarmel Industrial Park > > > > > > > > > > > > > > > > > > > > > >Yokneam 20692, ISRAEL > > > >Email - itzikpe@marvell.com > >Tel - +972 4 9091192 > >Cell - +972 54 4452482 > >Fax - +972 4 9091501 > >WWW Page: http://www.marvell.com > >======================================================================== > >This message may contain confidential, proprietary or legally privileged > >information. The information is intended only for the use of the > >individual or entity named above. If the reader of this message is not > >the intended recipient, you are hereby notified that any dissemination, > >distribution or copying of this communication is strictly prohibited. > >If you have received this communication in error, please notify us > >immediately by telephone, or by e-mail and delete the message from > >your computer. > > > >Thank you! > >======================================================================== > > ------------------------------------------------------------------------ > > *From:* owner-ibis@eda.org [mailto:owner-ibis@eda.org] *On Behalf Of > *Ummalaneni, Venu Babu (Venu) > *Sent:* Tuesday, December 13, 2005 2:49 PM > *To:* Todd Westerhoff (twesterh); ibis-users@eda.org; ibis@eda.org > *Subject:* [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at > different capacitive loads > > Todd, > > Thanks for your inputs. > > I have verified the programming options of driver and it’s fine. Here, > I am attaching the correlation waveforms of the simulations by using a > 0.1 ohm resistor instead of transmission line in both load (5pF & > 30pF) cases. Still, I am seeing a bad correlation in 30pF case. > > Please ignore my previously attached *.PDF. > > Once again thanks for your response. > > Best Reagrds, > > Venu > > -----Original Message----- > *From:* Todd Westerhoff (twesterh) [mailto:twesterh@cisco.com] > *Sent:* Tuesday, December 13, 2005 5:43 PM > *To:* Ummalaneni, Venu Babu (Venu); ibis-users@eda.org; ibis@eda.org > *Subject:* RE: [IBIS-Users] hspice vs IBIS model correlation at > different capacitive loads > > Venu, > > How long is the transmission line you're using ... about 1ns? > > Your IBIS driver in the 30pf case seems to be taking several > round-trips to charge the load where the HSpice driver doesn't - if > this is a programmable driver, is it possible the driver settings for > the two plots are different? In the top plot for the 30pf case, the > IBIS driver looks like a much weaker output with a faster slew rate to > me ... > > Todd. > > > Todd Westerhoff > High Speed Design Group Manager > Cisco Systems > 1414 Massachusetts Ave > Boxboro, MA 01719 > email:twesterh@cisco.com > ph: 978-936-2149 > ____________________________________________ > "Always do right. > This will gratify some people and astonish the rest." > > - Mark Twain > > ------------------------------------------------------------------------ > > *From:* owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] *On > Behalf Of *Ummalaneni, Venu Babu (Venu) > *Sent:* Tuesday, December 13, 2005 5:38 AM > *To:* ibis-users@eda.org; ibis@eda.org > *Subject:* [IBIS-Users] hspice vs IBIS model correlation at different > capacitive loads > > Hi Gurus, > > I have an ATA* IBIS model and it is correlating well with hspice model > when I am using a 5pF load followed by a transmission line. If I > replace the 5pF load with 30pF correlation is bad (particularly in > 2^nd page waveform of attached PDF). > > Could some one comment on this, where it is going wrong? > > Your comments/inputs are highly appreciated. > > Attachments: ata4nik_5pf.pdf – hspice and IBIS model waveforms > captured using 5pF load > > ata4nik_30pf.pdf – hspice and IBIS model waveforms captured using 30pF > load > > Thanks & Best Regards, > > Venu > > <> <> > |------------------------------------------------------------------ |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, 3 Jan 2006 22:40:33 -0800 From: "Tom Dagostino" Subject: RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at different capacitive loads I've been given many models to "fix" that had a C_fixture in them. Universally, these models showed poor transient response into resistive loads and had even worse problems trying to drive a reactive load. I would strongly recommend not to use a C_fixture in any model. If your transmission line's length is on the order of Tr/Tf then you are really into the range where you will see transmission line effects. If this line is not terminated then I would expect to see a lot of ringing in the simulations. You need to understand why you are seeing the ringing and proceed from there. 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 Vinayak Ghatawade Sent: Tuesday, January 03, 2006 10:07 PM To: ibis-users@eda.org; ibis@eda.org Subject: Re: [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at different capacitive loads Hi all, I had this query where in if the buffer is going to be used for shorter TL (transmission line) then do we need to generate the V-T data with C-load rather than R-load since the buffer rise time is comparable to TL delay. We have this case where in the *buffer has feedback* and with R-load we see V-T table with lot of ringing(oscillations) when pad has reached steady state. As this is no real situation for us as TL delay that buffer would see in real world is too small comparable to buffer tr/tf. How do we generate the V-T data in this case. Should we use C-load instead of R-load or we release the V-T data with some oscillations when pad reaches steady state. Does simulator really have a problem seeing such V-T data. Thanks vinayak Ummalaneni, Venu Babu (Venu) wrote: >Itzik Peleg and all, > > > >Thank you very much for your help. Please see my answers in line with your comments. > > > >1. This buffer operation is intended for a load resistance of more than 5k ohm. > >2. Yes, you are right. I should allow more transient simulation time for min corner. > >However, reported behavior (correlation of hspice vs IBIS) is for typ corner. > > > >Even I have tried with 50, 100, 500 & 5k ohm terminations for capturing V-t waveforms. But I could not see any improvement in the correlation. I am still investigating this issue. > > > > > > Thanks & Best Regards, > >Venu > > -----Original Message----- > *From:* Itzik Peleg [mailto:itzikpe@marvell.com] > *Sent:* Thursday, December 15, 2005 7:09 PM > *To:* Ummalaneni, Venu Babu (Venu); ibis-users@eda.org; ibis@eda.org > *Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model > correlation at different capacitive loads > > Hello Venu > > Here are my comments reviewing your model: > > 1. The loading condition is 1k ohm !? isn’t this buffer should be used > in 50 ohm environment? If the answer is yes then you should use 50 ohm. > > 2. It seems like the slow didn’t finish the complete transition. You > should allow more time for the V(t) simulation in order that the > response get to steady state (like the maximum case in red). This also > causing the warning that you have when using IBIS check: > > ************************************************************** > > WARNING - Model ATA4N1K000: The [Rising Waveform] > > with [R_fixture]=1000 Ohms and [V_fixture_min]=0V > > has MIN column DC endpoints of 0.00V and 2.78v, but > > an equivalent load applied to the model's I-V tables yields > > different voltages (-0.00V and 2.92V), > > a difference of 0.00% and 4.69%, respectively. > > WARNING - Model ATA4N1K000: The [Falling Waveform] > > with [R_fixture]=1000 Ohms and [V_fixture_min]=3V > > has MIN column DC endpoints of 0.21V and 3.00v, but > > an equivalent load applied to the model's I-V tables yields > > different voltages ( 0.05V and 3.00V), > > a difference of 5.54% and 0.00%, respectively. > > **************************************************************** > > 3. Based on the 2 previous points I can think of a buffer for slow > interface that should be used in 50 ohm environment. If this is the > case you should allow the transient simulation more time on 50 ohm. > > Hope this will halp. > >-- > >Regards > > > >Itzik Peleg > >Board Technology Group > > > >Marvell Semiconductor Israel Ltd > >6 Hamada Street > > > > >Mordot HaCarmel Industrial Park > > > >Yokneam 20692, ISRAEL > > > >Email - itzikpe@marvell.com > >Tel - +972 4 9091192 > >Cell - +972 54 4452482 > >Fax - +972 4 9091501 > >WWW Page: http://www.marvell.com > >======================================================================== > >This message may contain confidential, proprietary or legally privileged > >information. The information is intended only for the use of the > >individual or entity named above. If the reader of this message is not > >the intended recipient, you are hereby notified that any dissemination, > >distribution or copying of this communication is strictly prohibited. > >If you have received this communication in error, please notify us > >immediately by telephone, or by e-mail and delete the message from > >your computer. > > > >Thank you! > >======================================================================== > > ------------------------------------------------------------------------ > > *From:* Ummalaneni, Venu Babu (Venu) [mailto:venubabu@agere.com] > *Sent:* Thursday, December 15, 2005 1:07 PM > *To:* Itzik Peleg; Todd Westerhoff (twesterh); ibis-users@eda.org; > ibis@eda.org > *Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model > correlation at different capacitive loads > >Itzik Peleg, > > > >Thanks for your concern. I think there is no such feedback. > > > >Here, I am attaching the IBIS model. > > > >Thanks & Regards, > >Venu > > -----Original Message----- > *From:* Itzik Peleg [mailto:itzikpe@marvell.com] > *Sent:* Wednesday, December 14, 2005 12:50 PM > *To:* Ummalaneni, Venu Babu (Venu); Todd Westerhoff (twesterh); > ibis-users@eda.org; ibis@eda.org > *Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model > correlation at different capacitive loads > > Hello Venu > > Just to add one more possibility doe’s your buffer has a feedback? > > Could you attached the IBIS model, or show the I(V) and V(t) curves? > >-- > >Regards > > > >Itzik Peleg > >Board Technology Group > > > >Marvell Semiconductor Israel Ltd > >6 Hamada Street > > > > > > > > > > > > > > > > > > > > >Mordot HaCarmel Industrial Park > > > > > > > > > > > > > > > > > > > > > >Yokneam 20692, ISRAEL > > > >Email - itzikpe@marvell.com > >Tel - +972 4 9091192 > >Cell - +972 54 4452482 > >Fax - +972 4 9091501 > >WWW Page: http://www.marvell.com > >======================================================================== > >This message may contain confidential, proprietary or legally privileged > >information. The information is intended only for the use of the > >individual or entity named above. If the reader of this message is not > >the intended recipient, you are hereby notified that any dissemination, > >distribution or copying of this communication is strictly prohibited. > >If you have received this communication in error, please notify us > >immediately by telephone, or by e-mail and delete the message from > >your computer. > > > >Thank you! > >======================================================================== > > ------------------------------------------------------------------------ > > *From:* owner-ibis@eda.org [mailto:owner-ibis@eda.org] *On Behalf Of > *Ummalaneni, Venu Babu (Venu) > *Sent:* Tuesday, December 13, 2005 2:49 PM > *To:* Todd Westerhoff (twesterh); ibis-users@eda.org; ibis@eda.org > *Subject:* [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at > different capacitive loads > > Todd, > > Thanks for your inputs. > > I have verified the programming options of driver and it’s fine. Here, > I am attaching the correlation waveforms of the simulations by using a > 0.1 ohm resistor instead of transmission line in both load (5pF & > 30pF) cases. Still, I am seeing a bad correlation in 30pF case. > > Please ignore my previously attached *.PDF. > > Once again thanks for your response. > > Best Reagrds, > > Venu > > -----Original Message----- > *From:* Todd Westerhoff (twesterh) [mailto:twesterh@cisco.com] > *Sent:* Tuesday, December 13, 2005 5:43 PM > *To:* Ummalaneni, Venu Babu (Venu); ibis-users@eda.org; ibis@eda.org > *Subject:* RE: [IBIS-Users] hspice vs IBIS model correlation at > different capacitive loads > > Venu, > > How long is the transmission line you're using ... about 1ns? > > Your IBIS driver in the 30pf case seems to be taking several > round-trips to charge the load where the HSpice driver doesn't - if > this is a programmable driver, is it possible the driver settings for > the two plots are different? In the top plot for the 30pf case, the > IBIS driver looks like a much weaker output with a faster slew rate to > me ... > > Todd. > > > Todd Westerhoff > High Speed Design Group Manager > Cisco Systems > 1414 Massachusetts Ave > Boxboro, MA 01719 > email:twesterh@cisco.com > ph: 978-936-2149 > ____________________________________________ > "Always do right. > This will gratify some people and astonish the rest." > > - Mark Twain > > ------------------------------------------------------------------------ > > *From:* owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] *On > Behalf Of *Ummalaneni, Venu Babu (Venu) > *Sent:* Tuesday, December 13, 2005 5:38 AM > *To:* ibis-users@eda.org; ibis@eda.org > *Subject:* [IBIS-Users] hspice vs IBIS model correlation at different > capacitive loads > > Hi Gurus, > > I have an ATA* IBIS model and it is correlating well with hspice model > when I am using a 5pF load followed by a transmission line. If I > replace the 5pF load with 30pF correlation is bad (particularly in > 2^nd page waveform of attached PDF). > > Could some one comment on this, where it is going wrong? > > Your comments/inputs are highly appreciated. > > Attachments: ata4nik_5pf.pdf – hspice and IBIS model waveforms > captured using 5pF load > > ata4nik_30pf.pdf – hspice and IBIS model waveforms captured using 30pF > load > > Thanks & Best Regards, > > Venu > > <> <> > |------------------------------------------------------------------ |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: Wed, 04 Jan 2006 12:50:50 +0530 From: Vinayak Ghatawade Subject: Re: [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at different capacitive loads Tom, Thanks for the reply. Buffer for which IBIS is been generated will be used with a shorter transmission line in which case c effect is more pronounced than r-load effect. There is no termination in this case at the recieving end since we are making sure the buffer will be used with shorter trace. Can we define transmission line load for V-T. The current V-T data that we have generated has oscillations due to adaptive behaviour of the buffer since this is not real case (might happen with longer trace). Thanks again vinayak Tom Dagostino wrote: >I've been given many models to "fix" that had a C_fixture in them. >Universally, these models showed poor transient response into resistive >loads and had even worse problems trying to drive a reactive load. I would >strongly recommend not to use a C_fixture in any model. > >If your transmission line's length is on the order of Tr/Tf then you are >really into the range where you will see transmission line effects. If this >line is not terminated then I would expect to see a lot of ringing in the >simulations. > >You need to understand why you are seeing the ringing and proceed from >there. > >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 Vinayak Ghatawade >Sent: Tuesday, January 03, 2006 10:07 PM >To: ibis-users@eda.org; ibis@eda.org >Subject: Re: [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at >different capacitive loads > > >Hi all, > >I had this query where in if the buffer is going to be >used for shorter TL (transmission line) then do we need >to generate the V-T data with C-load rather than R-load since the >buffer rise time is comparable to TL delay. > >We have this case where in the *buffer has feedback* and with R-load we see >V-T table with lot of ringing(oscillations) when pad has reached steady >state. >As this is no real situation for us as TL delay that buffer would see in >real world is too small >comparable to buffer tr/tf. > >How do we generate the V-T data in this case. Should we use C-load >instead of R-load >or we release the V-T data with some oscillations when pad reaches >steady state. Does >simulator really have a problem seeing such V-T data. > >Thanks >vinayak > >Ummalaneni, Venu Babu (Venu) wrote: > > > >>Itzik Peleg and all, >> >> >> >>Thank you very much for your help. Please see my answers in line with your >> >> >comments. > > >> >>1. This buffer operation is intended for a load resistance of more than 5k >> >> >ohm. > > >>2. Yes, you are right. I should allow more transient simulation time for >> >> >min corner. > > >>However, reported behavior (correlation of hspice vs IBIS) is for typ >> >> >corner. > > >> >>Even I have tried with 50, 100, 500 & 5k ohm terminations for capturing V-t >> >> >waveforms. But I could not see any improvement in the correlation. I am >still investigating this issue. > > >> >> >> >> Thanks & Best Regards, >> >>Venu >> >>-----Original Message----- >>*From:* Itzik Peleg [mailto:itzikpe@marvell.com] >>*Sent:* Thursday, December 15, 2005 7:09 PM >>*To:* Ummalaneni, Venu Babu (Venu); ibis-users@eda.org; ibis@eda.org >>*Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model >>correlation at different capacitive loads >> >>Hello Venu >> >>Here are my comments reviewing your model: >> >>1. The loading condition is 1k ohm !? isn’t this buffer should be used >>in 50 ohm environment? If the answer is yes then you should use 50 ohm. >> >>2. It seems like the slow didn’t finish the complete transition. You >>should allow more time for the V(t) simulation in order that the >>response get to steady state (like the maximum case in red). This also >>causing the warning that you have when using IBIS check: >> >>************************************************************** >> >>WARNING - Model ATA4N1K000: The [Rising Waveform] >> >>with [R_fixture]=1000 Ohms and [V_fixture_min]=0V >> >>has MIN column DC endpoints of 0.00V and 2.78v, but >> >>an equivalent load applied to the model's I-V tables yields >> >>different voltages (-0.00V and 2.92V), >> >>a difference of 0.00% and 4.69%, respectively. >> >>WARNING - Model ATA4N1K000: The [Falling Waveform] >> >>with [R_fixture]=1000 Ohms and [V_fixture_min]=3V >> >>has MIN column DC endpoints of 0.21V and 3.00v, but >> >>an equivalent load applied to the model's I-V tables yields >> >>different voltages ( 0.05V and 3.00V), >> >>a difference of 5.54% and 0.00%, respectively. >> >>**************************************************************** >> >>3. Based on the 2 previous points I can think of a buffer for slow >>interface that should be used in 50 ohm environment. If this is the >>case you should allow the transient simulation more time on 50 ohm. >> >>Hope this will halp. >> >>-- >> >>Regards >> >> >> >>Itzik Peleg >> >>Board Technology Group >> >> >> >>Marvell Semiconductor Israel Ltd >> >>6 Hamada Street >> >> >> >> >>Mordot HaCarmel Industrial Park >> >> >> >>Yokneam 20692, ISRAEL >> >> >> >>Email - itzikpe@marvell.com >> >>Tel - +972 4 9091192 >> >>Cell - +972 54 4452482 >> >>Fax - +972 4 9091501 >> >>WWW Page: http://www.marvell.com >> >>======================================================================== >> >>This message may contain confidential, proprietary or legally privileged >> >>information. The information is intended only for the use of the >> >>individual or entity named above. If the reader of this message is not >> >>the intended recipient, you are hereby notified that any dissemination, >> >>distribution or copying of this communication is strictly prohibited. >> >>If you have received this communication in error, please notify us >> >>immediately by telephone, or by e-mail and delete the message from >> >>your computer. >> >> >> >>Thank you! >> >>======================================================================== >> >>------------------------------------------------------------------------ >> >>*From:* Ummalaneni, Venu Babu (Venu) [mailto:venubabu@agere.com] >>*Sent:* Thursday, December 15, 2005 1:07 PM >>*To:* Itzik Peleg; Todd Westerhoff (twesterh); ibis-users@eda.org; >>ibis@eda.org >>*Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model >>correlation at different capacitive loads >> >>Itzik Peleg, >> >> >> >>Thanks for your concern. I think there is no such feedback. >> >> >> >>Here, I am attaching the IBIS model. >> >> >> >>Thanks & Regards, >> >>Venu >> >>-----Original Message----- >>*From:* Itzik Peleg [mailto:itzikpe@marvell.com] >>*Sent:* Wednesday, December 14, 2005 12:50 PM >>*To:* Ummalaneni, Venu Babu (Venu); Todd Westerhoff (twesterh); >>ibis-users@eda.org; ibis@eda.org >>*Subject:* RE: [IBIS] RE: [IBIS-Users] hspice vs IBIS model >>correlation at different capacitive loads >> >>Hello Venu >> >>Just to add one more possibility doe’s your buffer has a feedback? >> >>Could you attached the IBIS model, or show the I(V) and V(t) curves? >> >>-- >> >>Regards >> >> >> >>Itzik Peleg >> >>Board Technology Group >> >> >> >>Marvell Semiconductor Israel Ltd >> >>6 Hamada Street >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>Mordot HaCarmel Industrial Park >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>Yokneam 20692, ISRAEL >> >> >> >>Email - itzikpe@marvell.com >> >>Tel - +972 4 9091192 >> >>Cell - +972 54 4452482 >> >>Fax - +972 4 9091501 >> >>WWW Page: http://www.marvell.com >> >>======================================================================== >> >>This message may contain confidential, proprietary or legally privileged >> >>information. The information is intended only for the use of the >> >>individual or entity named above. If the reader of this message is not >> >>the intended recipient, you are hereby notified that any dissemination, >> >>distribution or copying of this communication is strictly prohibited. >> >>If you have received this communication in error, please notify us >> >>immediately by telephone, or by e-mail and delete the message from >> >>your computer. >> >> >> >>Thank you! >> >>======================================================================== >> >>------------------------------------------------------------------------ >> >>*From:* owner-ibis@eda.org [mailto:owner-ibis@eda.org] *On Behalf Of >>*Ummalaneni, Venu Babu (Venu) >>*Sent:* Tuesday, December 13, 2005 2:49 PM >>*To:* Todd Westerhoff (twesterh); ibis-users@eda.org; ibis@eda.org >>*Subject:* [IBIS] RE: [IBIS-Users] hspice vs IBIS model correlation at >>different capacitive loads >> >>Todd, >> >>Thanks for your inputs. >> >>I have verified the programming options of driver and it’s fine. Here, >>I am attaching the correlation waveforms of the simulations by using a >>0.1 ohm resistor instead of transmission line in both load (5pF & >>30pF) cases. Still, I am seeing a bad correlation in 30pF case. >> >>Please ignore my previously attached *.PDF. >> >>Once again thanks for your response. >> >>Best Reagrds, >> >>Venu >> >>-----Original Message----- >>*From:* Todd Westerhoff (twesterh) [mailto:twesterh@cisco.com] >>*Sent:* Tuesday, December 13, 2005 5:43 PM >>*To:* Ummalaneni, Venu Babu (Venu); ibis-users@eda.org; ibis@eda.org >>*Subject:* RE: [IBIS-Users] hspice vs IBIS model correlation at >>different capacitive loads >> >>Venu, >> >>How long is the transmission line you're using ... about 1ns? >> >>Your IBIS driver in the 30pf case seems to be taking several >>round-trips to charge the load where the HSpice driver doesn't - if >>this is a programmable driver, is it possible the driver settings for >>the two plots are different? In the top plot for the 30pf case, the >>IBIS driver looks like a much weaker output with a faster slew rate to >>me ... >> >>Todd. >> >> >>Todd Westerhoff >>High Speed Design Group Manager >>Cisco Systems >>1414 Massachusetts Ave >>Boxboro, MA 01719 >>email:twesterh@cisco.com >>ph: 978-936-2149 >>____________________________________________ >>"Always do right. >>This will gratify some people and astonish the rest." >> >>- Mark Twain >> >>------------------------------------------------------------------------ >> >>*From:* owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] *On >>Behalf Of *Ummalaneni, Venu Babu (Venu) >>*Sent:* Tuesday, December 13, 2005 5:38 AM >>*To:* ibis-users@eda.org; ibis@eda.org >>*Subject:* [IBIS-Users] hspice vs IBIS model correlation at different >>capacitive loads >> >>Hi Gurus, >> >>I have an ATA* IBIS model and it is correlating well with hspice model >>when I am using a 5pF load followed by a transmission line. If I >>replace the 5pF load with 30pF correlation is bad (particularly in >>2^nd page waveform of attached PDF). >> >>Could some one comment on this, where it is going wrong? >> >>Your comments/inputs are highly appreciated. >> >>Attachments: ata4nik_5pf.pdf – hspice and IBIS model waveforms >>captured using 5pF load >> >>ata4nik_30pf.pdf – hspice and IBIS model waveforms captured using 30pF >>load >> >>Thanks & Best Regards, >> >>Venu >> >><> <> >> >> >> > >|------------------------------------------------------------------ >|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: Wed, 4 Jan 2006 16:13:26 +0530 From: "Ummalaneni, Venu Babu \(Venu\)" Subject: RE: [IBIS-Users] RE: [IBIS] Why IO buffer name is limited to a max of 20 characters This is a multi-part message in MIME format. - ------_=_NextPart_001_01C6111B.B19BEEDC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Arpad, =20 Thanks for your message and the pointer. Could you please tell me when/how this BIRD93.1 will come for voting? =20 Best Regards, Venu =20 =20 - -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi, Arpad Sent: Tuesday, January 03, 2006 11:31 PM To: ibis-users@eda.org; ibis@eda.org Subject: RE: [IBIS-Users] RE: [IBIS] Why IO buffer name is limited to a max of 20 characters =20 Sorry, the BIRD has already been written by Michael Mirmak it is BIRD93.1 =20 http://www.vhdl.org/pub/ibis/birds/bird93.1.txt =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 =20 =20 _____ =20 From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf Of Muranyi, Arpad Sent: Tuesday, January 03, 2006 9:34 AM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS-Users] RE: [IBIS] Why IO buffer name is limited to a max of 20 characters Venu, =20 This is rooted in the earlier versions of the spec when the line length was limited to 80 characters, and therefore we had limited space for each field on the lines of the [Pin] section. Now that the line length limit is 120 characters (if I am not mistaken), we could allow for=20 longer model names, but someone would need to write a BIRD for it. Do you want to volunteer? =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 =20 _____ =20 From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Ummalaneni, Venu Babu (Venu) Sent: Thursday, December 22, 2005 5:47 AM To: ibis-users@eda.org; ibis@eda.org Subject: [IBIS] Why IO buffer name is limited to a max of 20 characters Hi All, =20 Is there any specific reason exist to restrict the IO buffer name to a maximum of 20 chars in our IBIS standard? Can't we change this rule to allow more than 20 chars as buffer name?=20 =20 Recently, I experienced some IO buffers which have more than 20 chars in their names. So, I have to truncate the IBIS model name to support this rule. If choice is given I do not want to truncate the IBIS model name.=20 =20 Thanks in advance, =20 Best Regards, Venu =20 - ------_=_NextPart_001_01C6111B.B19BEEDC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hspice vs IBIS model correlation at different capacitive = loads

Arpad,

 

Thanks for your message and the = pointer. Could you please tell me when/how this BIRD93.1 will come for = voting?

 

Best Regards,

Venu

 

 

-----Original = Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On = Behalf Of Muranyi, Arpad
Sent: Tuesday, January = 03, 2006 11:31 PM
To: ibis-users@eda.org; ibis@eda.org
Subject: RE: [IBIS-Users] = RE: [IBIS] Why IO buffer name is limited to a max of 20 = characters

 

Sorry, the BIRD has = already been written by Michael Mirmak

it is = BIRD93.1

 

 

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

 

 

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On = Behalf Of Muranyi, Arpad
Sent: Tuesday, January = 03, 2006 9:34 AM
To: ibis-users@eda.org; ibis@eda.org
Subject: [IBIS-Users] RE: = [IBIS] Why IO buffer name is limited to a max of 20 = characters

Venu,

 

This is rooted in = the earlier versions of the spec when

the line length was = limited to 80 characters, and therefore

we had limited = space for each field on the lines of the

[Pin] = section.  Now that the line length limit is 120

characters (if I am = not mistaken), we could allow for

longer model names, = but someone would need to write a

BIRD for it.  = Do you want to volunteer?

 

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

 

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On = Behalf Of Ummalaneni, Venu Babu (Venu)
Sent: Thursday, December = 22, 2005 5:47 AM
To: ibis-users@eda.org; ibis@eda.org
Subject: [IBIS] Why IO = buffer name is limited to a max of 20 characters

Hi = All,

 

Is there any = specific reason exist to restrict the IO buffer name to a maximum of 20 chars in = our IBIS standard? Can’t we change this rule to allow more than 20 = chars as buffer name?

 

Recently, I = experienced some IO buffers which have more than 20 chars in their names. So, I have = to truncate the IBIS model name to support this rule. If choice is given I do not = want to truncate the IBIS model name.

 

Thanks in = advance,

 

Best = Regards,

Venu

 

- ------_=_NextPart_001_01C6111B.B19BEEDC-- |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 4 Jan 2006 08:41:14 -0800 From: "Muranyi, Arpad" Subject: RE: [IBIS-Users] RE: [IBIS] Why IO buffer name is limited to a max of 20 characters Venu, Reading the top section of the BIRD you will find: "DATE ACCEPTED BY IBIS OPEN FORUM: December 10, 2004" which means that the BIRD has been voted on already. The question really is, which official IBIS spec will include these changes, to which I believe the answer is v4.2, the next one. But don't take this as a promise, I don't want to be held responsible for saying this... Arpad ===================================================== ________________________________ From: Ummalaneni, Venu Babu (Venu) [mailto:venubabu@agere.com] Sent: Wednesday, January 04, 2006 2:43 AM To: Muranyi, Arpad; ibis-users@eda.org; ibis@eda.org Cc: Patel, Nirav (Nirav); Kotikalapudi, Shiva Kumar (Shiva) Subject: RE: [IBIS-Users] RE: [IBIS] Why IO buffer name is limited to a max of 20 characters Arpad, Thanks for your message and the pointer. Could you please tell me when/how this BIRD93.1 will come for voting? Best Regards, Venu |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 4 Jan 2006 11:49:25 -0500 From: "Andrew Ingraham" Subject: [IBIS-Users] Re: hspice vs IBIS model correlation at different capacitive loads Vinayak wrote: > We have this case where in the *buffer has feedback* and with R-load we see > V-T table with lot of ringing(oscillations) when pad has reached steady > state. > As this is no real situation for us as TL delay that buffer would see in > real world is too small > comparable to buffer tr/tf. I think you are saying that you get these oscillations in your simulations with the SPICE model that you used to create your IBIS model; and that you see them only in simulations, not real devices. If that is correct, then I'd investigate why the oscillations happen, and fix it. It isn't just because your buffer has feedback, because real devices also have feedback and they don't oscillate. SPICE is known to occasionally have numeric oscillations when it should be steady-state, which can be fixed by changing to Method=Gear. Oscillations can also happen because things are missing in the SPICE simulation, device models are too ideal and lack resistance, etc. If, on the other hand, your buffer really does oscillate when loaded this way, then you've got a different problem. One fix (not necessarily good) would be to truncate the V/T data just before the oscillations start, and/or smooth out the tail so it approaches the correct final value. Regards, Andy |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993 ------------------------------ Date: Wed, 4 Jan 2006 08:52:58 -0800 From: "Fred Balistreri" Subject: [IBIS-Users] IBIS Summit 2nd announcement This is a multi-part message in MIME format. - ------=_NextPart_000_0096_01C6110C.42A076D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is the second Announcement for the DesignCon 2006 IBIS Summit Meeting held in Santa Clara, California. Note, because of the interest in Monday tutorial sessions, we have moved the IBIS Meeting to Thursday on the last 1/2 day of DesignCon. We are seeking Sponsors for the IBIS meeting to cover the expenses for a Free lunch and refreshments. Also note that discounts are offered for all conference packages through January 13, 2006, and also February 6, 2006 for free exhibit registration. Best Regards, Fred - ----------------------------------------------------------------------- IBIS SUMMIT SECOND CALL FOR PARTICIPATION & PRESENTATIONS - ----------------------------------------------------------------------- I B I S S U M M I T M E E T I N G Time/Date: Thursday, February 9, 2006 8:00 AM to 5:00 PM (MOVED FROM MONDAY) Location: Santa Clara Convention Center Santa Clara, CA Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: Applied Simulation Technology, Cisco Systems, International Engineering Cornsortium (DesignCon) We are seeking more co-sponsors. Please contact Bob Ross . The Benefits to sponsors include recognition at the meeting and acknowledgement in the Calls for Papers and meeting minutes. Your financial support strengthens the organization by allowing IBIS to focus resources on industry activities rather than raising money, and you will receive generous thanks for your support. DesignCon 2006 Conference: February 6 - February 9, 2006 Santa Clara Convention Center Santa Clara, CA Exhibit registration is Free if you register before February 6, 2006, and conference discounts before. =20 http://www.designcon.com/2006/ http://www.designcon.com/2006/registration/ =20 Conference Catalog: http://www.designcon.com/2006/pdf/dc06_catalog.pdf IBIS Booth: Come visit the IBIS Booth to meet attendees and pick up IBIS information. BACKGROUND DesignCon is the premier annual Silicon Valley event for the electronic design automation (EDA) and semiconductor industry. Topics of current interest to the EIA IBIS Open Forum are addressed at DesignCon. This meeting will be conducted as a formal IBIS Summit Meeting. Presentations are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate in the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to: =20 Fred Balistreri Registration deadline is Wednesday, February 1, 2003 to receive the free lunch. =20 CALL FOR PRESENTATIONS We are seeking presentations from individuals who have experiences of interest to the IBIS modeling community. In the past, these have included, but not limited to: Demonstrations of modeling techniques=20 Explanations of behavioral algorithms Descriptions of difficulties encountered Model correlation Modeling building experiences Comparisons to other modeling methods New techologies for modeling buffers and component New technologies for modeling packaging and interconnect etc. Presentations may be addressed to any and all levels of IBIS experience, from beginning to advanced. Presentation Format: =20 A conference laptop with LCD projection. Power Point or Acrobat electronic formats are favored and will pre-loaded on the Windows-basede meeting laptop prior to the meeting. Time: Usually 15-30 Minutes Electronic Archival: Presentations will be archived under the IBIS Summits site and also must be submitted in time for uploading and copying. Final submission deadline is: =20 Wednesday, February 1, 2006 Otherwise, you should bring 50 copies. If you plan a presentation, please supply the following information as soon as possible: Tentative Title: Presenter: E-mail address: Company: Telephone: Estimated Time: =20 Send to: Bob Ross AGENDA The agenda includes presentations, discussions, breaks, and a FREE lunch. The agenda details will be developed as proposals are received. So far, several technical and overview presentations are planned including these subjects: Michael Mirmak, Intel Corp, IBIS Chair's Report and Roadmap Todd Westerhoff, Cisco Systems, Macromodel Committee Update Arpad Muranyi, Intel Corp., Technical Review of the Macromodel Library Bob Ross, Teraspeed Consulting Group, Asian IBIS Summit Feedback LIST OF NEARBY HOTELS The hotel and travel Link provides a conference hotel discount, and use internet search engines other good lodging deals: http://www.designcon.com/2006/conference/hotel_and_travel.html - ----------------------------------------------------------------- - ------=_NextPart_000_0096_01C6110C.42A076D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is the second Announcement for the = DesignCon=20 2006 IBIS Summit
Meeting held in Santa Clara, = California.
 
Note, because of the interest in Monday = tutorial=20 sessions, we have
moved the IBIS Meeting to Thursday on the last 1/2 = day of=20 DesignCon.
 
We are seeking Sponsors for the IBIS = meeting to=20 cover the expenses
for a Free lunch and refreshments.
 
Also note that discounts are offered = for all=20 conference packages
through January 13, 2006, and also February 6, = 2006 for=20 free
exhibit registration.
 
Best Regards,
Fred
 
----------------------------------------------------------------= - -------
          &n= bsp;           &nb= sp;      =20 IBIS=20 SUMMIT
          &nb= sp;           &nbs= p;     =20 SECOND CALL=20 FOR
           =          =20 PARTICIPATION &=20 PRESENTATIONS
--------------------------------------------------------= - ---------------
 

          &nbs= p;  =20 I B I S   S U M M I T   M E E T I N G
 
Time/Date:  Thursday, February 9, 2006 8:00 AM to 5:00=20 PM
            = (MOVED=20 FROM MONDAY)
 
Location:   Santa Clara Convention=20 Center
          &nb= sp;=20 Santa Clara, CA
 
Content:    Presentations and Discussions
 
Purpose:    Solicit and Exchange IBIS Model Related=20 Information=20 and
           = =20 Ideas.
 
Sponsors:   Applied Simulation Technology, Cisco Systems, = International
         &n= bsp; =20 Engineering Cornsortium (DesignCon)
 
            = We are=20 seeking more co-sponsors.  Please contact Bob=20 Ross
           = ;=20 <bob@teraspeed.com>.  The=20 Benefits to sponsors=20 include
          &n= bsp;=20 recognition at the meeting and acknowledgement in the=20 Calls
          &nbs= p; for=20 Papers and meeting minutes.
 
            = Your=20 financial support strengthens the organization=20 by
            = allowing IBIS to focus resources on industry=20 activities
          = ; =20 rather than raising money, and you will receive=20 generous
          &= nbsp;=20 thanks for your support.
 
DesignCon 2006 Conference:
 
            = February=20 6 - February 9,=20 2006
           = ; Santa=20 Clara Convention=20 Center
          &nb= sp;=20 Santa Clara, CA
 
            = Exhibit=20 registration is Free if you register=20 before
          &nb= sp;=20 February 6, 2006, and conference discounts=20 before.
          &n= bsp;=20
           &nb= sp; =20 http://www.designcon.com/2006/
           &n= bsp; =20 http://www.designcon= .com/2006/registration/
    =20
     Conference Catalog:
 
       http://www.de= signcon.com/2006/pdf/dc06_catalog.pdf
 
IBIS Booth: Come visit the IBIS Booth to meet attendees and pick=20 up
            = IBIS=20 information.
 

BACKGROUND
 
DesignCon is the premier annual Silicon Valley event for the=20 electronic
design automation (EDA) and semiconductor industry.  = Topics=20 of current
interest to the EIA IBIS Open Forum are addressed at=20 DesignCon.
 
This meeting will be conducted as a formal IBIS Summit=20 Meeting.
Presentations are expected to be available and archived in = an=20 electronic
format, and minutes of the meeting will be issued. Any = pending=20 formal
decisions (votes) will be announced at least two weeks prior = to=20 the
meeting.
 

CALL FOR PARTICIPANTS
 
People involved in IBIS Model development, EDA tool development,=20 and
digital circuit design are invited to participate in the Summit=20 meeting.
If you plan to participate, please register with the = information=20 below:
 
      =20 Name:
       E-mail=20 address:
      =20 Company:
       Telephone:
 
Send to:
 
       Fred=20 Balistreri  <fred@apsimtech.com>
 
Registration deadline is Wednesday, February 1, 2003 to receive = the
free=20 lunch.
 
 
CALL FOR PRESENTATIONS
 
We are seeking presentations from individuals who have = experiences
of=20 interest to the IBIS modeling community.  In the past, these=20 have
included, but not limited to:
 
       Demonstrations of modeling = techniques=20
       Explanations of behavioral=20 algorithms
       Descriptions of = difficulties=20 encountered
       Model=20 correlation
       Modeling building=20 experiences
       Comparisons to other = modeling methods
       New techologies = for=20 modeling buffers and component
       = New=20 technologies for modeling packaging and=20 interconnect
       etc.
 
Presentations may be addressed to any and all levels of IBIS=20 experience,
from beginning to advanced.
 
Presentation Format:
 
      A = conference laptop with LCD projection.  Power Point or=20 Acrobat
      electronic formats are favored = and=20 will pre-loaded on the
      Windows-basede = meeting=20 laptop prior to the meeting.
 
Time: Usually 15-30 Minutes
 
Electronic Archival:
 
      Presentations will be archived under = the=20 IBIS Summits site
      and also must be = submitted=20 in time for uploading and copying.
      = Final=20 submission deadline is:
 =20
         Wednesday, February = 1,=20 2006
 
      Otherwise, you should bring 50 = copies.
 
If you plan a presentation, please supply the following = information
as=20 soon as possible:
 
      Tentative=20 Title:
     =20 Presenter:
      E-mail=20 address:
     =20 Company:
      Telephone:
 
      Estimated Time:
 
Send = to:
 
      Bob Ross <bob@teraspeed.com>
 

AGENDA
 
The agenda includes presentations, discussions, breaks, and a=20 FREE
lunch.  The agenda details will be developed as proposals=20 are
received.  So far, several technical and overview = presentations=20 are
planned including these subjects:
 
  Michael Mirmak, Intel Corp, IBIS Chair's Report and=20 Roadmap
  Todd Westerhoff, Cisco Systems, Macromodel Committee=20 Update
  Arpad Muranyi, Intel Corp., Technical Review of the = Macromodel=20 Library
  Bob Ross, Teraspeed Consulting Group, Asian IBIS = Summit=20 Feedback
 

LIST OF NEARBY HOTELS
 
The hotel and travel Link provides a conference hotel discount, = and
use=20 internet search engines other good lodging deals:
 
     h= ttp://www.designcon.com/2006/conference/hotel_and_travel.html
 
-----------------------------------------------------------------
 

 
- ------=_NextPart_000_0096_01C6110C.42A076D0-- |------------------------------------------------------------------ |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 #73 ************************