From: owner-ibis-users@eda.org (ibis-users)
To: ibis-users-digest@eda.org
Subject: ibis-users V1 #48
Reply-To: 
Sender: owner-ibis-users@eda.org
Errors-To: owner-ibis-users@eda.org
Precedence: bulk


ibis-users         Thursday, December 30 2004         Volume 01 : Number 048




----------------------------------------------------------------------

Date: Tue, 14 Dec 2004 08:36:27 -0800
From: Bob Ross <bob@teraspeed.com>
Subject: [IBIS-Users] IBIS Summit Meeitng at DesignCon - Second Annoucement

To All:

This message from Syed Huq is being resent because of possible
IBIS reflector problems:

- --------------

DesignCon is offering 20% off all conferences packages through Dec15,
2004:
      http://www.designcon.com/registration/index.html

If you register for the Exhibits before December 15th, registration is
free.

After Dec. 15th, the cost will be $75.  So if you are unsure whether you
will attend, we recommend registering before Dec 15th.


- -----------------------------------------------------------------------
                        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:  Monday January 31st, 2005 8:00 AM to 5 PM

Location:   Santa Clara Convention Center
             Santa Clara, CA

Content:    Presentations and Discussions

Purpose:    Solicit and Exchange IBIS Model Related Information and
             Ideas.

Sponsors:   DesignCon

             If your company would be interested in sponsoring this
             event, please contact Syed Huq <shuq@cisco.com>.
             Benefits to sponsors include formal recognition at the
             meeting and acknowledgement in the Calls for Papers and
             meeting minutes.

             Your financial support strengthens the organization by
             allowing IBIS to focus resources on industry activities
             rather than raising money, and you will receive generous
             thanks for your support.

DesignCon Conference
             January 31- February 3rd, 2005
             Santa Clara Convention Center
             Santa Clara, CA

             Exhibit registration is Free if you register before
             December 15, 2004.  Come and visit IBIS Booth <TBD>.

             See http://www.designcon.com/ for more information.

             Conference Catalog:
             http://www.eda.org/pub/ibis/summits/jan05/DC05_Catalog.pdf


BACKGROUND

DesignCon is the premier annual Silicon Valley event for the electronic
design automation (EDA) and semiconductor industry.  Topics of current
interest to the EIA IBIS Open Forum are addressed at DesignCon.

This meeting will be conducted as a formal IBIS Summit Meeting.
Presentations are expected to be available and archived in an electronic
format, and minutes of the meeting will be issued. Any pending formal
decisions (votes) will be announced at least two weeks prior to the
meeting.


CALL FOR PARTICIPANTS

People involved in IBIS Model development, EDA tool development, and
digital circuit design are invited to participate in the Summit meeting.
If you plan to participate, please register with the information below:

    Name:
    E-mail address:
    Company:
    Telephone:

Send to:
     Syed Huq <shuq@cisco.com>


CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have experiences
of interest to the IBIS modeling community.  In the past, these have
included demonstrations of modeling techniques, explanations of
behavioral algorithms and descriptions of difficulties encountered
in specific applications.  Of particular interest are topics related
to model correlation, modeling building experiences and comparisons
to other modeling methods.  Presentations may be addressed to any
and all levels of IBIS experience, from beginning to advanced.

Format of Presentation:  LCD Projection with Windows laptop.
Time:          15-30 Minutes
Electronic Archival: We request electronic versions so that the
                presentations can be archived and also made
                available to non-attendees.  Formats used in
                the past have been text, Power Point, Word,
                Postscript, and Acrobat.  Electronic
                presentations should be made available by
                January 21, 2005 for uploading and copying to
                the presentation laptop. Presentors are responsible
                for bringing 50 copies if not received by January 21.

If you plan a presentation, please supply

    Title:
    Presenter:
    E-mail address:
    Company:
    Telephone:

    Estimated Time:

Send this to:

   Syed Huq <shuq@cisco.com>


AGENDA

The agenda includes presentations, discussions, breaks, and
a luncheon (which will be provided). This will be developed as
presentation proposals are received. Please pre-register with
Syed Huq(shuq@cisco.com) by January 15, 2005 to reserve a free
lunch spot.


LIST OF NEARBY HOTELS

See <http://www.designcon.com/conference/hotel_8_travel.html> for
travel directions, hotels and other information.
- -----------------------------------------------------------------


- -- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
503-750-6481                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com


|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 13 Dec 2004 10:06:15 -0800
From: Syed Huq <shuq@cisco.com>
Subject: [IBIS-Users] IBIS Summit At DesignCon2005 - Second Call for Paper

DesignCon is offering 20% off all conferences packages through Dec15,
2004:
     http://www.designcon.com/registration/index.html
    
If you register for the Exhibits before December 15th, registration is
free.

After Dec. 15th, the cost will be $75.  So if you are unsure whether you
will attend, we recommend registering before Dec 15th.

- -----------------------------------------------------------------------
                       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:  Monday January 31st, 2005 8:00 AM to 5 PM

Location:   Santa Clara Convention Center
            Santa Clara, CA

Content:    Presentations and Discussions

Purpose:    Solicit and Exchange IBIS Model Related Information and
            Ideas.

Sponsors:   DesignCon

            If your company would be interested in sponsoring this
            event, please contact Syed Huq <shuq@cisco.com>.
            Benefits to sponsors include formal recognition at the
            meeting and acknowledgement in the Calls for Papers and
            meeting minutes.

            Your financial support strengthens the organization by
            allowing IBIS to focus resources on industry activities
            rather than raising money, and you will receive generous
            thanks for your support.

DesignCon Conference
            January 31- February 3rd, 2005
            Santa Clara Convention Center
            Santa Clara, CA

            Exhibit registration is Free if you register before
            December 15, 2004.  Come and visit IBIS Booth <TBD>.
            
            See http://www.designcon.com/ for more information.
            
            Conference Catalog:
            http://www.eda.org/pub/ibis/summits/jan05/DC05_Catalog.pdf


BACKGROUND

DesignCon is the premier annual Silicon Valley event for the electronic
design automation (EDA) and semiconductor industry.  Topics of current
interest to the EIA IBIS Open Forum are addressed at DesignCon.

This meeting will be conducted as a formal IBIS Summit Meeting.
Presentations are expected to be available and archived in an electronic
format, and minutes of the meeting will be issued. Any pending formal
decisions (votes) will be announced at least two weeks prior to the
meeting.


CALL FOR PARTICIPANTS

People involved in IBIS Model development, EDA tool development, and
digital circuit design are invited to participate in the Summit meeting.
If you plan to participate, please register with the information below:

   Name:
   E-mail address:
   Company:
   Telephone:

Send to:
    Syed Huq <shuq@cisco.com>


CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have experiences
of interest to the IBIS modeling community.  In the past, these have
included demonstrations of modeling techniques, explanations of
behavioral algorithms and descriptions of difficulties encountered
in specific applications.  Of particular interest are topics related
to model correlation, modeling building experiences and comparisons
to other modeling methods.  Presentations may be addressed to any
and all levels of IBIS experience, from beginning to advanced.

Format of Presentation:  LCD Projection with Windows laptop.
Time:          15-30 Minutes
Electronic Archival: We request electronic versions so that the
               presentations can be archived and also made
               available to non-attendees.  Formats used in
               the past have been text, Power Point, Word,
               Postscript, and Acrobat.  Electronic 
               presentations should be made available by
               January 21, 2005 for uploading and copying to
               the presentation laptop. Presentors are responsible
               for bringing 50 copies if not received by January 21.

If you plan a presentation, please supply

   Title:
   Presenter:
   E-mail address:
   Company:
   Telephone:

   Estimated Time:

Send this to:

  Syed Huq <shuq@cisco.com>


AGENDA

The agenda includes presentations, discussions, breaks, and
a luncheon (which will be provided). This will be developed as 
presentation proposals are received. Please pre-register with
Syed Huq(shuq@cisco.com) by January 15, 2005 to reserve a free 
lunch spot. 


LIST OF NEARBY HOTELS

See <http://www.designcon.com/conference/hotel_8_travel.html> for
travel directions, hotels and other information.
- -----------------------------------------------------------------
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 13 Dec 2004 13:29:21 -0800
From: Syed Huq <shuq@cisco.com>
Subject: [IBIS-Users] Re: IBIS Summit At DesignCon2005 - Second Call for Paper

- --=-GbQVD2wSrgIt2OwxsA2Z
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

RESENDING - Syed

- --=-GbQVD2wSrgIt2OwxsA2Z
Content-Disposition: inline
Content-Description: Forwarded message - IBIS Summit At DesignCon2005 -
	Second Call for Paper
Content-Type: message/rfc822

Subject: IBIS Summit At DesignCon2005 - Second Call for Paper
From: Syed Huq <shuq@cisco.com>
To: ibis@eda.org, ibis-users@eda.org
Content-Type: text/plain
Organization: Cisco Systems, Inc
Message-Id: <1102961175.578.18.camel@asipd01-lnx.cisco.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Mon, 13 Dec 2004 10:06:15 -0800
Content-Transfer-Encoding: 7bit

DesignCon is offering 20% off all conferences packages through Dec15,
2004:
     http://www.designcon.com/registration/index.html
    
If you register for the Exhibits before December 15th, registration is
free.

After Dec. 15th, the cost will be $75.  So if you are unsure whether you
will attend, we recommend registering before Dec 15th.

- -----------------------------------------------------------------------
                       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:  Monday January 31st, 2005 8:00 AM to 5 PM

Location:   Santa Clara Convention Center
            Santa Clara, CA

Content:    Presentations and Discussions

Purpose:    Solicit and Exchange IBIS Model Related Information and
            Ideas.

Sponsors:   DesignCon

            If your company would be interested in sponsoring this
            event, please contact Syed Huq <shuq@cisco.com>.
            Benefits to sponsors include formal recognition at the
            meeting and acknowledgement in the Calls for Papers and
            meeting minutes.

            Your financial support strengthens the organization by
            allowing IBIS to focus resources on industry activities
            rather than raising money, and you will receive generous
            thanks for your support.

DesignCon Conference
            January 31- February 3rd, 2005
            Santa Clara Convention Center
            Santa Clara, CA

            Exhibit registration is Free if you register before
            December 15, 2004.  Come and visit IBIS Booth <TBD>.
            
            See http://www.designcon.com/ for more information.
            
            Conference Catalog:
            http://www.eda.org/pub/ibis/summits/jan05/DC05_Catalog.pdf


BACKGROUND

DesignCon is the premier annual Silicon Valley event for the electronic
design automation (EDA) and semiconductor industry.  Topics of current
interest to the EIA IBIS Open Forum are addressed at DesignCon.

This meeting will be conducted as a formal IBIS Summit Meeting.
Presentations are expected to be available and archived in an electronic
format, and minutes of the meeting will be issued. Any pending formal
decisions (votes) will be announced at least two weeks prior to the
meeting.


CALL FOR PARTICIPANTS

People involved in IBIS Model development, EDA tool development, and
digital circuit design are invited to participate in the Summit meeting.
If you plan to participate, please register with the information below:

   Name:
   E-mail address:
   Company:
   Telephone:

Send to:
    Syed Huq <shuq@cisco.com>


CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have experiences
of interest to the IBIS modeling community.  In the past, these have
included demonstrations of modeling techniques, explanations of
behavioral algorithms and descriptions of difficulties encountered
in specific applications.  Of particular interest are topics related
to model correlation, modeling building experiences and comparisons
to other modeling methods.  Presentations may be addressed to any
and all levels of IBIS experience, from beginning to advanced.

Format of Presentation:  LCD Projection with Windows laptop.
Time:          15-30 Minutes
Electronic Archival: We request electronic versions so that the
               presentations can be archived and also made
               available to non-attendees.  Formats used in
               the past have been text, Power Point, Word,
               Postscript, and Acrobat.  Electronic 
               presentations should be made available by
               January 21, 2005 for uploading and copying to
               the presentation laptop. Presentors are responsible
               for bringing 50 copies if not received by January 21.

If you plan a presentation, please supply

   Title:
   Presenter:
   E-mail address:
   Company:
   Telephone:

   Estimated Time:

Send this to:

  Syed Huq <shuq@cisco.com>


AGENDA

The agenda includes presentations, discussions, breaks, and
a luncheon (which will be provided). This will be developed as 
presentation proposals are received. Please pre-register with
Syed Huq(shuq@cisco.com) by January 15, 2005 to reserve a free 
lunch spot. 


LIST OF NEARBY HOTELS

See <http://www.designcon.com/conference/hotel_8_travel.html> for
travel directions, hotels and other information.
- -----------------------------------------------------------------

- --=-GbQVD2wSrgIt2OwxsA2Z--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 14 Dec 2004 11:05:36 -0800
From: "Tom Dagostino" <tom@teraspeed.com>
Subject: RE: [IBIS-Users] way to extract rising and falling waveform in differential cells

Akhilesh

A ramp based model simulation will start its transition immediately, there
is no time delay built into the model.  A SPICE simulation will include the
delay of the buffer and other effects you are seeing in the SPICE output.
If you want the two to match you need to include the full waveform models in
the IBIS model.  These waveforms need to be extracted preserving the time
delay of the buffer.  Using the SPICE to IBIS tools available on the IBIS
web page should give you the results you want.

If you need assistance in using this we can help.

Tom Dagostino
Teraspeed Consulting Group LLC
503-430-1065
tom@teraspeed.com
www.teraspeed.com

- -----Original Message-----
From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On
Behalf Of Akhilesh CHANDRA
Sent: Tuesday, December 14, 2004 5:48 AM
To: ibis-users@eda.org
Cc: Akhilesh CHANDRA
Subject: [IBIS-Users] way to extract rising and falling waveform in
differential cells


Hello Friends,

   I am devloping IBIS model of a differential cell having swing 300mv.
when I run simulation at 300mhz then I find out there is a transition
shift between IBIS and spice result. In my model I give just ramp
database dv/dt for transition. In my view this problem may be resolve if
I give complete rising and falling waveform in my models.
  Is anyone know how we can extract rising and falling waveform for a
cell that have differential swing or any other way to reduce this shift.

  My results are attached with the mail.

regards
Akhilesh




|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 14 Dec 2004 20:12:28 -0500
From: "Dr. Edward P. Sayre" <esayre@nesa.com>
Subject: [IBIS-Users] NESA move complete and back in business

Folks:


NESA has completed our move to new quarters and more efficient 
quarters!   New physical address, same phone, fax and email addresses. All 
data is in the signature block below.

Happy Holidays to all our colleagues and friends in the IBIS organization.

Sincerely,

ed sayre & the NESA staff




+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|        NORTH EAST SYSTEMS ASSOCIATES, INC.        |
|       -------------------------------------       |
|      "High Performance Engineering & Design"      |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Dr. Ed Sayre               e-mail: esayre@nesa.com|
| NESA, Inc.                 http://www.nesa.com/   |
| 235 Littleton Road, Ste 2  Tel +1.978.392-8787    |
| Westford, MA  01886        Fax +1.978.392-8686    |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 15 Dec 2004 09:56:23 -0500
From: "Zanella, Fabrizio" <fzanella@enterasys.com>
Subject: [IBIS-Users] Hspice ibischk4 tool

This is a multi-part message in MIME format.

- ------_=_NextPart_001_01C4E2B6.3E68360C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The latest version of Synopsys Hspice, version 2004.09, uses the
ibischk4 tool, version 4.0.1.   In a simulation I ran yesterday, Hspice
reported errors running the v4.0.1 ibischk4 with the rising and falling
waveforms when using an IBIS model as a driver.=20

Here's a sample of the errors:

ERROR - Model osoc2_od: The [Rising Waveform]=20

      with [R_fixture]=3D60 Ohms and [V_fixture]=3D3.3V

      has TYP column DC endpoints of  2.02V and  3.30v, but

      an equivalent load applied to the model's I-V tables yields

      different voltages ( 2.02V and  2.02V),

      a difference of   inf% and   inf%, respectively.

ERROR - Model osoc2_od: The [Falling Waveform]=20

      with [R_fixture]=3D60 Ohms and [V_fixture]=3D3.3V

      has TYP column DC endpoints of  2.02V and  3.30v, but

      an equivalent load applied to the model's I-V tables yields

      different voltages ( 2.02V and  2.02V),

      a difference of   inf% and   inf%, respectively.

=20

An engineer at the device manufacturer said there are no errors when he
uses the ibischk4 v4.0.2 tool.  Can someone explain what the differences
are between versions 4.0.1 and 4.0.2 of the ibischk4 tool and does
anyone know whether Synopsys will be moving to the latest ibischk4 tool
in the Hspice simulator?

Thanks and regards,

=20

Fabrizio Zanella

Signal Integrity

Enterasys Networks

Andover, MA

Phone:  978-684-1340

fzanella@enterasys.com

=20


- ------_=_NextPart_001_01C4E2B6.3E68360C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Narrow";
	panose-1:2 11 5 6 2 2 2 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
- -->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The latest version of Synopsys Hspice, version =
2004.09, uses
the ibischk4 tool, version 4.0.1.&nbsp; &nbsp;In a simulation I ran =
yesterday,
Hspice reported errors running the v4.0.1 ibischk4 with the rising and =
falling
waveforms when using an IBIS model as a driver. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Here&#8217;s a sample of the =
errors:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>ERROR - Model osoc2_od: The [Rising Waveform] =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with =
[R_fixture]=3D60
Ohms and [V_fixture]=3D3.3V<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; has TYP column =
DC
endpoints of&nbsp; 2.02V and&nbsp; 3.30v, =
but<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an equivalent =
load applied
to the model's I-V tables yields<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different =
voltages (
2.02V and&nbsp; 2.02V),<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a difference
of&nbsp;&nbsp; inf% and&nbsp;&nbsp; inf%, =
respectively.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>ERROR - Model osoc2_od: The [Falling =
Waveform] <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with =
[R_fixture]=3D60
Ohms and [V_fixture]=3D3.3V<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; has TYP column =
DC
endpoints of&nbsp; 2.02V and&nbsp; 3.30v, =
but<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an equivalent =
load
applied to the model's I-V tables yields<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different =
voltages (
2.02V and&nbsp; 2.02V),<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a difference
of&nbsp;&nbsp; inf% and&nbsp;&nbsp; inf%, =
respectively.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>An engineer at the device manufacturer said there are =
no
errors when he uses the ibischk4 v4.0.2 tool. &nbsp;Can someone explain =
what
the differences are between versions 4.0.1 and 4.0.2 of the ibischk4 =
tool and does
anyone know whether Synopsys will be moving to the latest ibischk4 tool =
in the
Hspice simulator?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks and regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Arial =
Narrow"><span
style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:navy'>Fabrizio Zanella</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Arial Narrow"><span =
style=3D'font-size:
10.0pt;font-family:"Arial Narrow"'>Signal =
Integrity</span></font><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D2 face=3D"Arial =
Narrow"><span
style=3D'font-size:10.0pt;font-family:"Arial Narrow"'>Enterasys =
Networks</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  face=3D"Arial Narrow"><span =
style=3D'font-size:10.0pt;font-family:"Arial =
Narrow"'>Andover</span></font></st1:City><font
 size=3D2 face=3D"Arial Narrow"><span =
style=3D'font-size:10.0pt;font-family:"Arial Narrow"'>,
 <st1:State =
w:st=3D"on">MA</st1:State></span></font></st1:place><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Arial Narrow"><span =
style=3D'font-size:
10.0pt;font-family:"Arial Narrow"'>Phone:&nbsp; =
978-684-1340</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Arial =
Narrow"><span
style=3D'font-size:10.0pt;font-family:"Arial Narrow";color:black'><a
href=3D"mailto:fzanella@enterasys.com">fzanella@enterasys.com</a></span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

- ------_=_NextPart_001_01C4E2B6.3E68360C--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 15 Dec 2004 08:37:56 -0700
From: rrwolff@micron.com
Subject: [IBIS-Users] [IBIS] Open forum minutes (12/10/04)

This is a multi-part message in MIME format.

- ------_=_NextPart_001_01C4E2BC.0C438C6D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


- ------_=_NextPart_001_01C4E2BC.0C438C6D
Content-Type: text/plain;
	name="m121004.txt"
Content-Transfer-Encoding: base64
Content-Description: m121004.txt
Content-Disposition: attachment;
	filename="m121004.txt"

REFURTogMTIvMTMvMDQNCg0KU1VCSkVDVDogRGVjZW1iZXIgMTAsIDIwMDQgRUlBIElCSVMgT3Bl
biBGb3J1bSBNZWV0aW5nIE1pbnV0ZXMNCg0KVk9USU5HIE1FTUJFUlMgQU5EIDIwMDQgUEFSVElD
SVBBTlRTDQpBbnNvZnQgQ29ycG9yYXRpb24gICAgICAgICAgICAgTWljaGFlbCBCcmVubmVtYW4s
IE1hcnkgVG9saWthcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW0hhbmsgQ2Ft
cGJlbGxdDQpBcHBsaWVkIFNpbXVsYXRpb24gVGVjaG5vbG9neSAgTm9yaW8gTWF0c3VpDQpDYWRl
bmNlIERlc2lnbiBTeXN0ZW1zICAgICAgICAgQy4gS3VtYXIsIFBhdHJpY2sgZG9zIFNhbnRvcywg
TGFuY2UgV2FuZyoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRG9uYWxkIFRlbGlh
bioNCkNpc2NvIFN5c3RlbXMgICAgICAgICAgICAgICAgICBTZXJnaW8gQ2FtZXJsbywgU3llZCBI
dXEqLCBNaWtlIExhQm9udGUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0YW4g
UGVubmVyLCBUb2RkIFdlc3RlcmhvZmYNCkZyZWVzY2FsZSAgICAgICAgICAgICAgICAgICAgICAo
Sm9uIEJ1cm5ldHQpDQpIaXRhY2hpIFVMU0kgU3lzdGVtcyAgICAgICAgICAgS2F6dXlvc2hpIFNo
b2ppDQpIdWF3ZWkgICAgICAgICAgICAgICAgICAgICAgICAgKEppYW5nIFhpYW5nIFpob25nKQ0K
SUJNICAgICAgICAgICAgICAgICAgICAgICAgICAgIChQcmF2aW4gUGF0ZWwpDQpJbnRlbCBDb3Jw
b3JhdGlvbiAgICAgICAgICAgICAgRGF2aWQgS2VhdGVzLCBQZXRlciBULiBMYXJzZW4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgV2lsc29uIExldW5nLCBNaWNoYWVsIE1pcm1hayos
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFycGFkIE11cmFueWksIFN0ZXZlIFBl
dGVyc29uDQpMU0kgTG9naWMgICAgICAgICAgICAgICAgICAgICAgRnJhbmsgR2FzcGFyaWsqDQpN
YXRzdXNoaXRhIChQYW5hc29uaWMpICAgICAgICAgQXRzdWppIEl0bw0KTWVudG9yIEdyYXBoaWNz
ICAgICAgICAgICAgICAgIEpvaG4gQW5ndWxvKiwgR3V5IGRlIEJ1cmdoLA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBXZXN0b24gQmVhbCwgSWFuIERvZGQqLCBHYXJ5IFByYXR0LA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFcmljIFJvbmdlcmUsIFN0ZXBoYW5lIFJv
dXNzZWF1DQpNaWNyb24gVGVjaG5vbG9neSAgICAgICAgICAgICAgUGF1bCBHcmVnb3J5LCBSYW5k
eSBXb2xmZioNCk5FQyBFbGVjdHJpYyBDb3Jwb3JhdGlvbiAgICAgICBUYWtlc2hpIFdhdGFuYWJl
DQpTYW10ZWMgICAgICAgICAgICAgICAgICAgICAgICAgT3R0byBCZW5uaWcNClNpZW1lbnMgQUcg
ICAgICAgICAgICAgICAgICAgICBFY2toYXJkIExlbnNraSosIE1hbmZyZWQgTWF1cmVyDQogICBT
aWVtZW5zIE1lZGljYWwgKEFjdXNvbikgICAgIERhdmlkIExpZWJ5DQpTaWduYWwgSW50ZWdyaXR5
IFNvZnR3YXJlICAgICAgUm9iZXJ0IEhhbGxlciosIEJhcnJ5IEthdHoNClNpZ3JpdHkgICAgICAg
ICAgICAgICAgICAgICAgICBSYXltb25kIENoZW4sIEppYXl1YW4gRmFuZw0KU3lub3BzeXMgICAg
ICAgICAgICAgICAgICAgICAgIFdhcnJlbiBXb25nLiBFZG11bmQgQ2hlbmcNClRleGFzIEluc3Ry
dW1lbnRzICAgICAgICAgICAgICBKZWFuIENsYXVkZSBQZXJyaW4sIEhlY3RvciBUb3JyZXMNClRl
cmFzcGVlZCBDb25zdWx0aW5nIEdyb3VwICAgICBUb20gRGFnb3N0aW5vLCBTY290dCBNY01vcnJv
dywgQm9iIFJvc3MqDQpUaW1lIERvbWFpbiBBbmFseXNpcyBTeXN0ZW1zICAgU3RldmUgQ29yZXkN
Clp1a2VuICgmIEluY2FzZXMpICAgICAgICAgICAgICBSYWxmIEJydWVuaW5nLCBDYXJvbGluZSBM
ZWdlbmRyZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTGFldGl0aWEgU2ltb25p
YW4NCg0KT1RIRVIgUEFSVElDSVBBTlRTIElOIDIwMDQ6DQpBY3RlbCAgICAgICAgICAgICAgICAg
ICAgICAgICAgUHJhYmh1IE1vaGFuDQpBbGNhdGVsICAgICAgICAgICAgICAgICAgICAgICAgSmVh
bi1QaWVycmUgQm91dGhlbXkNCkFwYWNoZSBEZXNpZ24gICAgICAgICAgICAgICAgICBZdSBMaXUN
CkJheXNpZGUgRGVzaWduICAgICAgICAgICAgICAgICBEYW5pZWwgTGFtYmFsb3QsIEtldmluIFJv
c2VsbGUNCkJlZSBUZWNobm9sb2dpZXMgICAgICAgICAgICAgICBUc3V5b3NoaSBIb3JpZ29tZQ0K
Q29uZXhhbnQgICAgICAgICAgICAgICAgICAgICAgIEdhcnJ5IEZlbGtlcg0KQ29ydGluYSBTeXN0
ZW1zICAgICAgICAgICAgICAgIFJvYmVydCBCYWRhbA0KQ3lwcmVzcyBTZW1pY29uZHVjdG9yICAg
ICAgICAgIFRlc3NhIFRyZXRoZXdleQ0KRUFEUyAgICAgICAgICAgICAgICAgICAgICAgICAgIE9s
aXZpZXIgTWF1cmljZQ0KRWRhbGl0eSAgICAgICAgICAgICAgICAgICAgICAgIFJvYiB0ZSBOaWpl
bmh1aXMNCkVGTSAgICAgICAgICAgICAgICAgICAgICAgICAgICBFa2tlaGFyZCBNaWVyc2NoDQpF
eHRyZW1lIE5ldHdvcmtzICAgICAgICAgICAgICAgTGluIFNoZW4NCkZyYXVuaG9mZXIgSVpNICAg
ICAgICAgICAgICAgICBFZ2UgRW5naW4NCkdFSUEgICAgICAgICAgICAgICAgICAgICAgICAgICAo
Q2hyaXMgRGVuaGFtKQ0KR3JlZW4gU3RyZWFrIFByb2dyYW1zICAgICAgICAgIEx5bm5lIEdyZWVu
Kg0KSW5kZXBlbmRlbnQgICAgICAgICAgICAgICAgICAgIEtlbGx5IEdyZWVuLCBLaW0gSGVsbGl3
ZWxsLCBKb24gUG93ZWxsDQpJTlNBICAgICAgICAgICAgICAgICAgICAgICAgICAgRXRpZW5uZSBT
aWNhcmQNCkludGVyZmFjZSBUZWNobm9sb2dpZXMgICAgICAgICBEYW4gV2F0ZXJsb28NCktBVy9V
U0EgICAgICAgICAgICAgICAgICAgICAgICBTaGluaWNoaSBNYWVkYQ0KVGhlIE1hdGhXb3JrcyAg
ICAgICAgICAgICAgICAgIENvbGluIFdhcndpY2ssIFJvYmVydCBaZW5nDQpOZXRsb2dpYyBNaWNy
b3N5c3RlbXMgICAgICAgICAgRXJpYyBIc3UNCk5vcnRoIENhcm9saW5hIFN0YXRlIFVuaXYuICAg
ICBQYXVsIEZyYW56b24sIEFtYnJpc2ggVmFybWENCk5vcnRoIEVhc3QgU3lzdGVtcyBBc3NvY2lh
dGVzICBFZHdhcmQgU2F5cmUNCk5vcnRocnVwIEdydW1tYW4gICAgICAgICAgICAgICBEYW4gQ3Jh
aW4sIEFkcmlhbm5hIFphbW1pdA0KUG9saXRlY25pY28gZGkgVG9yaW5vICAgICAgICAgIElnb3Ig
U3RpZXZhbm8NClNhbXN1bmcgICAgICAgICAgICAgICAgICAgICAgICBJbCBTZW9uZw0KU2lsdmVy
YmFjayBTeXN0ZW1zICAgICAgICAgICAgIEdpbCBHYWZuaQ0KU2ludGVjcyBCViAgICAgICAgICAg
ICAgICAgICAgIEhhbnMgS2xvcw0KWGlsaW54ICAgICAgICAgICAgICAgICAgICAgICAgIFJheSBB
bmRlcnNvbioNCg0KSW4gdGhlIGxpc3QgYWJvdmUsIGF0dGVuZGVlcyBhdCB0aGUgbWVldGluZyBh
cmUgaW5kaWNhdGVkIGJ5ICouDQpQcmluY2lwYWwgbWVtYmVycyBvciBvdGhlciBhY3RpdmUgbWVt
YmVycyB3aG8gaGF2ZSBub3QgYXR0ZW5kZWQgYXJlIGluDQpwYXJlbnRoZXNlcy4gUGFydGljaXBh
bnRzIHdobyBubyBsb25nZXIgYXJlIGluIHRoZSBvcmdhbml6YXRpb24gYXJlIGluDQpzcXVhcmUg
YnJhY2tldHMuDQoNClVQQ09NSU5HIE1FRVRJTkdTDQpUaGUgYnJpZGdlIG51bWJlcnMgZm9yIGZ1
dHVyZSBJQklTIHRlbGVjb25mZXJlbmNlcyBhcmUgYXMgZm9sbG93czoNCg0KICAgICAgIERhdGUg
ICAgICAgICAgVGVsZXBob25lIE51bWJlciAgICBCcmlkZ2UgIyAgICAgUGFzc2NvZGUNCiBKYW51
YXJ5IDcsIDIwMDUgICAgIDEtOTE2LTM1Ni0yNjYzICAgICAgICAgMyAgICAgICAgIDY5NS02MTg5
DQoNCkFsbCBtZWV0aW5ncyBhcmUgODowMCBBTSB0byA5OjU1IEFNIFVTIFBhY2lmaWMgVGltZS4g
IE1lZXRpbmcgYWdlbmRhcw0KYXJlIHR5cGljYWxseSBkaXN0cmlidXRlZCBzZXZlbiBkYXlzIGJl
Zm9yZSBlYWNoIE9wZW4gRm9ydW0uICBNaW51dGVzDQphcmUgdHlwaWNhbGx5IGRpc3RyaWJ1dGVk
IHdpdGhpbiBzZXZlbiBkYXlzIG9mIHRoZSBjb3JyZXNwb25kaW5nDQptZWV0aW5nLiAgV2hlbiBj
YWxsaW5nIGludG8gdGhlIG1lZXRpbmcsIHByb3ZpZGUgdGhlIGJyaWRnZSBudW1iZXIgYW5kDQpw
YXNzY29kZSBhdCB0aGUgYXV0b21hdGVkIHByb21wdHMuICBJZiBhc2tlZCBieSBhbiBvcGVyYXRv
ciwgcGxlYXNlDQpyZXF1ZXN0IHRvIGpvaW4gdGhlIElCSVMgT3BlbiBGb3J1bSBob3N0ZWQgYnkg
TWljaGFlbCBNaXJtYWsuDQpGb3IgaW50ZXJuYXRpb25hbCBkaWFsLWluIG51bWJlcnMsIHBsZWFz
ZSBjb250YWN0IE1pY2hhZWwgTWlybWFrLg0KDQpOT1RFOiAiQVIiID0gQWN0aW9uIFJlcXVpcmVk
Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLU1JTlVURVMtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSU5UUk9EVUNUSU9OUyBBTkQgTUVFVElORyBRVU9SVU0N
CkRvbmFsZCBUZWxpYW4gaW50cm9kdWNlZCBoaW1zZWxmLiAgSGUgd29ya3Mgb24gaGlnaCBzcGVl
ZCBwcm9kdWN0cyBmb3INCkNhZGVuY2UuICBIZSBpcyBqb2luaW5nIGFzIGFub3RoZXIgcmVwcmVz
ZW50YXRpdmUgZm9yIENhZGVuY2UuICBSYXkgQW5kZXJzb24NCmpvaW5lZCB0aGUgbWVldGluZyBh
cyBhIG5ldyBtZW1iZXIgYXMgd2VsbC4gIFJheSBpcyBhIHNpZ25hbCBpbnRlZ3JpdHkNCmVuZ2lu
ZWVyIHdpdGggWGlsaW54LiAgSGUgd29ya3Mgb24gYWR2YW5jZWQgcGFja2FnaW5nIGFuZCB3aWxs
IGJlIGdldHRpbmcNClhpbGlueCdzIG1vZGVsIGxpYnJhcnkgdXAgdG8gZGF0ZSBpbiByZXNwZWN0
IHRvIHBhY2thZ2luZyBwYXJhc2l0aWNzLg0KDQoNCkNBTEwgRk9SIFBBVEVOVFMNCk1pY2hhZWwg
TWlybWFrIGNhbGxlZCBmb3IgYW55IHBhdGVudHMgb3IgcGVuZGluZyBwYXRlbnRzIHJlbGF0ZWQg
dG8gdGhlDQpJQklTIFZlcnNpb24gMy4yLCA0LjAsIDQuMSwgb3IgSUNNIDEuMCBzcGVjaWZpY2F0
aW9ucy4gIE5vIHBhdGVudHMgd2VyZQ0KZGVjbGFyZWQuDQoNCg0KTUVNQkVSU0hJUCBVUERBVEUg
QU5EIFRSRUFTVVJFUidTIFJFUE9SVA0KTWljaGFlbCBNaXJtYWsgcmVwb3J0ZWQgdGhhdCB0aGVy
ZSBpcyBubyB1cGRhdGUgb2YgbWVtYmVyc2hpcCBudW1iZXJzIHNpbmNlDQp0aGUgbGFzdCByZXBv
cnQuICBUaGUgaW52b2ljaW5nIGxpc3QgZm9yIDIwMDUgaXMgYmVpbmcgYXNzZW1ibGVkIGJ5IEdF
SUEsDQphbmQgaW52b2ljZXMgd2lsbCBiZSBzZW50IG91dCBzaG9ydGx5LiAgTWljaGFlbCBlbmNv
dXJhZ2VkIGV2ZXJ5b25lIHRvIGJlDQpzdXJlIHRoYXQgY29udGFjdCBpbmZvcm1hdGlvbiBpcyBj
b3JyZWN0IGFzIGxpc3RlZCBvbiB0aGUgSUJJUyB3ZWJzaXRlLg0KSW52b2ljZXMgd2lsbCBiZSBy
ZWNlaXZlZCBieSBlbWFpbCBmcm9tIE1hcmluYSBTcGl2ZXkgb2YgR0VJQS4NCg0KDQpSRVZJRVcg
T0YgTUlOVVRFUyBBTkQgQVJTDQpNaWNoYWVsIE1pcm1hayByZXZpZXdlZCB0aGUgbWludXRlcyBv
ZiB0aGUgTm92ZW1iZXIgMTksIDIwMDQgSUJJUyBPcGVuIEZvcnVtDQp0ZWxlY29uZmVyZW5jZS4g
IFRoZSBtaW51dGVzIG9mIHRoZSBtZWV0aW5nIHdlcmUgYXBwcm92ZWQgd2l0aG91dCBjaGFuZ2Uu
DQoNCg0KUFJFU1MgQU5EIFdFQiBQQUdFIFVQREFURVMNClN5ZWQgSHVxIHJlcG9ydGVkIHRoYXQg
WGlsaW54IGhhcyBiZWVuIGFkZGVkIHRvIHRoZSByb3N0ZXIgYXMgYSBuZXcgbWVtYmVyDQpmb3Ig
MjAwNS4gUG9zdGVyIGNoYW5nZXMgaGF2ZSBiZWVuIHNlbnQgdG8gR0VJQSBhbmQgc2hvdWxkIGJl
IHVwIHdpdGhpbiBhDQpkYXkuDQoNCg0KTkVXIE1PREVMUyBBVkFJTEFCTEUsIExJQlJBUlkgVVBE
QVRFDQpNaWNoYWVsIE1pcm1hayByZXBvcnRlZCBmb3IgTGFuY2UgV2FuZyB0aGF0IEdFSUEgaGFz
IHJlY2VpdmVkIGFuIHVwZGF0ZWQNCm1vZGVsIGxpYnJhcnkgcGFnZSB3aXRoIG9uZSBjb21wYW55
IGFkZGVkIHdpdGggYSBuZXcgbW9kZWwgbGluay4gIFRoZSBjaGFuZ2UNCndpbGwgYmUgcG9zdGVk
IHNob3J0bHkuDQoNCg0KTUlTQ0VMTEFOWS9BTk5PVU5DRU1FTlRTDQpOb25lLg0KDQoNCk9QRU5T
IEZPUiBORVcgSVNTVUVTDQpCb2IgUm9zcyByZXF1ZXN0ZWQgdGhhdCBhIGRpc2N1c3Npb24gZW5z
dWUgb24gdGhlIElCSVMgQ29tbWl0dGVlIGZ1bmRpbmcNCm1vZGVsIGFzIGFuIG92ZXJ2aWV3IGZv
ciBuZXcgbWVtYmVycy4gIEJvYiBleHBsYWluZWQgdGhhdCBmdW5kaW5nIGlzIHRocm91Z2gNCmR1
ZXMgd2l0aCBtb3N0IGdvaW5nIHRvIGNvdmVyIEdFSUEgZHVlcy4gIEdFSUEgY3JlYXRlcyBhbiBJ
QklTIGFzc2Vzc21lbnQgb2YNCmFib3V0ICQxOCwwMDAgcGVyIHllYXIgdGhhdCBpcyB1c2VkIGJ5
IHRoZSBJQklTIGNvbW1pdHRlZSBkdXJpbmcgdGhlIHllYXIgdG8NCnBheSBmb3IgdmFyaW91cyBl
eHBlbnNlcy4gIFBhcnNlciBkZXZlbG9wbWVudCByZXF1aXJlcyBhZGRpdGlvbmFsIG1vbmV5LCBi
dXQNCmNvbmZlcmVuY2VzIGFyZSBjb3ZlcmVkIGJ5IGR1ZXMgYW5kIHNwb25zb3JzLg0KDQoNCk1B
SUxJTkcgTElTVCBBRE1JTklTVFJBVElPTg0KTm8gdXBkYXRlLg0KDQoNCklOVEVSTkFUSU9OQUwv
RVhURVJOQUwgUFJPR1JFU1MNCk1pY2hhZWwgTWlybWFrIHJlcG9ydGVkIG9uIHdvcmsgZ3JvdXAg
cmVsYXRpb25zIHdpdGggSUVFRS9EQVNDIG9uIFZIREwtQU1TDQphbmQgQWNjZWxsZXJhIG9uIFZl
cmlsb2ctQU1TLiBUaGVyZSBpcyBhIHBvc3NpYmlsaXR5IG9mIGFuIGludHJvZHVjdGlvbiB0bw0K
SUJJUyBhdCBhbiB1cGNvbWluZyBBY2NlbGxlcmEgVmVyaWxvZy1BTVMgbWVldGluZy4gIFRoZXJl
IGhhdmUgYmVlbiBwb3NpdGl2ZQ0KcmVzcG9uc2VzIHNvIGZhciBmcm9tIGJvdGggZ3JvdXBzIG9u
IGNvbnRpbnVpbmcgSUJJUyBpbnRlcmFjdGlvbiB3aXRoIHRoZW0uDQoNCg0KU1VNTUlUUw0KLSBE
ZXNpZ25Db24gSUJJUyBTdW1taXQsIEphbnVhcnkgMzEsIDIwMDUsIFNhbnRhIENsYXJhLCBDQQ0K
DQogIERlc2lnbkNvbiAyMDA1IHdpbGwgdGFrZSBwbGFjZSBKYW51YXJ5IDMxIC0gRmVicnVhcnkg
Mywgd2l0aCBhIFN1bW1pdA0KICBzY2hlZHVsZWQgZm9yIE1vbmRheSwgSmFudWFyeSAzMS4gU3ll
ZCBIdXEgbWVudGlvbmVkIHNlbmRpbmcgb3V0IHRoZSBmaXJzdA0KICBjYWxsIGZvciBwYXBlcnMu
IFN5ZWQgcmVwb3J0ZWQgdGhhdCBmaXZlIHBlb3BsZSBzaWduZWQgdXAsIGJ1dCBhIHF1aWNrDQog
IHBvbGwgYXQgdGhlIG1lZXRpbmcgaW5kaWNhdGVkIGFuIGVzdGltYXRlIG9mIDE1IHBlb3BsZSBz
byBmYXIgd2l0aCBtYW55DQogIG1vcmUgdG8gc2lnbiB1cCBsYXRlci4gIFRoZSBsdW5jaGVvbiBp
bnZvbHZlbWVudCBkZWFkbGluZSBpcyBKYW51YXJ5IDE1Lg0KICBEZXNpZ25Db24gbXVzdCBiZSBu
b3RpZmllZCBvbiB0aGlzIGRhdGUgb2YgdGhlIG51bWJlciBvZiBJQklTIGF0dGVuZGVlcw0KICB0
aGF0IHdpbGwgYmUgZWF0aW5nIGx1bmNoLiAgTWljaGFlbCBNaXJtYWsgbWVudGlvbmVkIHRoYXQg
YSBzaG9ydCBJQklTDQogIGRlc2NyaXB0aW9uIHdpbGwgYmUgaW4gdGhlIERlc2lnbkNvbiBib29r
bGV0IGFzIHdlbGwgYXMgb3RoZXINCiAgcHVibGljYXRpb25zLiAgTWljaGFlbCBpcyB1bnN1cmUg
b2YgdGhlIGJvb3RoIGxvY2F0aW9uLiAgUmVmcmVzaG1lbnRzIGFyZQ0KICBzdGlsbCBiZWluZyBk
aXNjdXNzZWQgd2l0aCBEZXNpZ25Db24uDQoNCi0gREFURSBFdXJvcGVhbiBJQklTIFN1bW1pdCwg
TWFyY2ggMTEsIDIwMDUsIE11bmljaCwgR2VybWFueQ0KDQogIERBVEUgMjAwNSB3aWxsIHRha2Ug
cGxhY2UgaW4gTXVuaWNoLCB3aXRoIGEgU3VtbWl0IHBsYW5uZWQgZm9yIEZyaWRheSwNCiAgTWFy
Y2ggMTEuICBSYWxmIEJydWVuaW5nIG9mIFp1a2VuIGlzIG1ha2luZyBhcnJhbmdlbWVudHMgZm9y
IHRoZSByb29tDQogIGFuZCBvdGhlciBsb2dpc3RpY3MuICBBbiB1cGRhdGUgaXMgbmVlZGVkIGZy
b20gUmFsZi4NCg0KLSBKRUlUQSBBc2lhbiBJQklTIEV2ZW50LCBNYXJjaCAyNCwgMjAwNSwgVG9r
eW8sIEphcGFuDQoNCiAgTWljaGFlbCBNaXJtYWsgcmVwb3J0ZWQgdGhhdCBKRUlUQSBtZW1iZXJz
IGFyZSBzdGlsbCBpbiB0aGUgcGxhbm5pbmcNCiAgc3RhZ2VzLiAgSkVJVEEgd291bGQgbGlrZSB0
byBoYXZlIGFuIElCSVMgcmVsYXRlZCBldmVudCwgYnV0IHRoZXkgd2FudCBpdA0KICB0byBiZSBh
IGNsb3NlZCBtZWV0aW5nIGFuZCBub3QgYSBzdW1taXQuICBUaGVyZSBoYXMgYmVlbiBhIHByb3Bv
c2FsIHRvDQogIG1ha2UgSUJJUyBhdHRlbmRlZXMgZ3Vlc3RzIG9mIEpFSVRBIGFzIElCSVMgZGVs
ZWdhdGVzLg0KDQpTcG9uc29yc2hpcCBvcHBvcnR1bml0aWVzIGZvciBhbGwgdGhlc2UgU3VtbWl0
cyBhcmUgc3RpbGwgYXZhaWxhYmxlLCB3aXRoDQpzcG9uc29ycyByZWNlaXZpbmcgZnJlZSBtZW50
aW9ucyBpbiB0aGUgbWludXRlcywgYWdlbmRhLCBhbmQgb3RoZXINCmFubm91bmNlbWVudHMuDQoN
Cg0KSUJJUyBBTlNJIEJBTExPVCBTVEFUVVMNClJhbmR5IFdvbGZmIHJlcG9ydGVkIHRoYXQgdGhl
IElCSVMgMy4yIHJlYXBwcm92YWwgYmFsbG90cyBhcmUgZHVlIERlY2VtYmVyDQoyMy4gIEdFSUEg
aGFzIHNlbnQgb3V0IG9uZSByZW1pbmRlciBlbWFpbCwgYW5kIG9uZSBtb3JlIGVtYWlsIHdpbGwg
YmUgc2VudA0KYmVmb3JlIHRoZSBiYWxsb3QgY2xvc2VzLiAgSXQgd2FzIG1lbnRpb25lZCB0aGF0
IG9ubHkgSUJJUyBjb21taXR0ZWUgdm90aW5nDQptZW1iZXJzIHZvdGUgb24gdGhlIGJhbGxvdC4g
IE11bHRpcGxlIHBlb3BsZSBmcm9tIGEgbWVtYmVyIGNvbXBhbnkgbWF5DQp2b3RlOyBob3dldmVy
LCB0aGUgdm90ZSBvZiBvbmx5IG9uZSBtZW1iZXIgb2YgZWFjaCBvcmdhbml6YXRpb24gd2lsbCBi
ZQ0KY291bnRlZC4gIFRoaXMgdm90aW5nIG1lbWJlciBpcyBpZGVudGlmaWVkIGJ5IEdFSUEuICBN
aWNoYWVsIE1pcm1haw0KbWVudGlvbmVkIHRoYXQgaGUgaGFkIHJlY2VpdmVkIGEgc3ByZWFkc2hl
ZXQgZnJvbSBHRUlBIHNob3dpbmcgY3VycmVudCB2b3RlDQp0YWxsaWVzIGFuZCBpbmRpY2F0aW5n
IG1lbWJlciBjb21wYW5pZXMgd2l0aCBpbnZhbGlkIGVtYWlsIGFkZHJlc3Nlcy4gIEl0DQp3YXMg
ZGV0ZXJtaW5lZCB0aGF0IHRoZSBJQklTIGNvbW1pdHRlZSB3aWxsIG5lZWQgdG8gdXBkYXRlIGFz
IG1hbnkgb2YgdGhlDQppbnZhbGlkIGVtYWlsIGFkZHJlc3NlcyBhcyBwb3NzaWJsZSBhbmQgZW5z
dXJlIHRoYXQgdGhlc2UgbWVtYmVycyByZWNlaXZlDQp0aGVpciBiYWxsb3RzLiAgUmFuZHksIE1p
Y2hhZWwsIGFuZCBCb2IgUm9zcyB0b29rIHRoZSBBUiBvbiB0aGlzLg0KDQoNClMySUJJUzMgU1RB
VFVTDQpObyB1cGRhdGUuDQoNClMySUJJUzMgYmV0YSBleGVjdXRhYmxlcyBjYW4gYmUgZG93bmxv
YWRlZCBmcm9tOg0KDQogIGh0dHA6Ly93d3cuZWNlLm5jc3UuZWR1L2VybC9pYmlzL3MyaWJpczMv
czJpYmlzMy5odG0NCg0KRmVlZGJhY2sgb24gdGhlIGN1cnJlbnQgdmVyc2lvbiBpcyBhcHByZWNp
YXRlZCBhbmQgZW5jb3VyYWdlZC4NCg0KDQpJQklTIFZFUlNJT04gNC4xIFBBUlNFUiBTVEFUVVMN
CkJvYiBSb3NzIHJlcG9ydGVkIHRoYXQgbW9zdCBpc3N1ZXMgaGF2ZSBiZWVuIHJlc29sdmVkIGFu
ZCBjbG9zZWQgd2l0aA0KcmVzcGVjdCB0byBob3cgSm9obiBQb3dlbGwgd2lsbCBpbnRlcnByZXQg
dGhlIHNwZWNpZmljYXRpb24uICBUaGVyZSBhcmUNCnRocmVlIG9yIGZvdXIgbW9yZSBpc3N1ZXMg
dG8gcmFpc2Ugb24gaG93IHRvIGludGVycHJldCB0aGUgc3BlY2lmaWNhdGlvbg0KZ2l2ZW4gaG93
IHRoZSBwYXJzZXIgaGFzIGJlZW4gZGV2ZWxvcGVkLiAgQm9iIG1heSBiZSBkZXZlbG9waW5nIEJJ
UkRzIHRvDQpjbG9zZSB0aGVzZSBpc3N1ZXMuIFRoZSBwYXJzZXIgaXMgc3RpbGwgb24gc2NoZWR1
bGUgZm9yIHJlbGVhc2UgZWFybHkNCm5leHQgeWVhci4NCg0KDQpJQ00gU1BFQ0lGSUNBVElPTiBB
TkQgUEFSU0VSIFNUQVRVUw0KTWljaGFlbCBNaXJtYWsgcmVwb3J0ZWQgdGhhdCBLZWxseSBHcmVl
biBpcyBhZGRyZXNzaW5nIGEgYnVnIHJlcG9ydGVkIGluDQp0aGUgcGFyc2VyLiAgVGhlcmUgaGF2
ZSBiZWVuIDggSUlSRHMgZmlsZWQsIHdpdGggNSBhcHByb3ZlZCwgMSByZWplY3RlZCwNCmFuZCAy
IHBlbmRpbmcuICBNaWNoYWVsIHByb3Bvc2VkIGN1dHRpbmcgb2ZmIHRoZSBjaGFuZ2VzIGFsbG93
ZWQgd2l0aA0KSUlSRDguMSBpbiBvcmRlciB0byBmaW5pc2ggdGhlIHBhcnNlciBhbmQgbW92ZSBm
b3J3YXJkIHdpdGggSUNNIDEuMSBhcHByb3ZhbA0KYW5kIEFOU0kvR0VJQSBiYWxsb3RpbmcgdG8g
bWFrZSBpdCBhbiBvZmZpY2lhbCBzdGFuZGFyZC4gIFRoZSBjb21taXR0ZWUgaXMNCmluIGFncmVl
bWVudCB3aXRoIE1pY2hhZWwncyBwcm9wb3NhbC4gIEx5bm5lIEdyZWVuIG1lbnRpb25lZCB0aGF0
IHdlIHNob3VsZA0KZW5jb3VyYWdlIHBlb3BsZSB0byBtYWtlIHNvbWUgSUNNIG1vZGVscyB0byBz
ZWUgaG93IHBlb3BsZSBhcmUgaW50ZXJwcmV0aW5nDQp0aGUgc3BlY2lmaWNhdGlvbi4NCg0KDQpJ
QklTIFFVQUxJVFkgQ09NTUlUVEVFDQpCb2IgSGFsbGVyIHJlcG9ydGVkIHRoYXQgdGhlIGNvbW1p
dHRlZSBtZXQgRGVjZW1iZXIgNyBhbmQgY29udGludWVzIHRvIG1lZXQNCm9uIHRoZSBmaXJzdCBU
dWVzZGF5IG9mIGVhY2ggbW9udGguIEFuIGFjdGlvbiBpdGVtIGZyb20gdGhlIGxhc3QgbWVldGlu
ZyBpcw0KZm9yIGVhY2ggY29tbWl0dGVlIG1lbWJlciB0byBjb250YWN0IG9uZSB2ZW5kb3IgYWJv
dXQgYmV0YSB0ZXN0aW5nIHRoZQ0KY2hlY2tsaXN0LiAgVGhlIGNvbW1pdHRlZSBpcyBhbHNvIHRy
eWluZyB0byBmaWd1cmUgb3V0IHdheXMgdG8gYXV0b21hdGUgdGhlDQpjaGVja2xpc3QuICBNaWtl
IExhQm9udGUgaGFzIGdlbmVyYXRlZCBhIGxpc3Qgb2YgY2hlY2tzIHRvIHN1Ym1pdCBhcyBwYXJz
ZXINCmJ1Z3MuICBCb2IgUm9zcyBwcm9wb3NlZCBhIGNvbW1hbmQgbGluZSBzd2l0Y2ggaW4gdGhl
IHBhcnNlciB0byBnZW5lcmF0ZQ0KZXh0cmEgY2F1dGlvbnMgYXMgc3VnZ2VzdGVkIGJ5IHRoZSBx
dWFsaXR5IGNoZWNrbGlzdC4NCg0KDQpJQklTIE1PREVMIFJFVklFVyBDT01NSVRURUUNCkx5bm5l
IEdyZWVuIHJlcG9ydGVkIHJlY2VpdmluZyBxdWVzdGlvbnMgZnJvbSBTVCBNaWNyb2VsZWN0cm9u
aWNzLiAgTHlubmUNCndvdWxkIGxpa2UgdG8gZW5jb3VyYWdlIHRoYXQgcGVvcGxlIHVzZSBhIHBh
cnNlciB2ZXJzaW9uIHRoYXQgaXMgbmV3ZXIgdGhhbg0KMy4yLjcsIHN1Y2ggYXMgNC4wLjIuDQoN
Cg0KRlVUVVJFUyBBTkQgQ09PS0JPT0sgQ09NTUlUVEVFUw0KTWljaGFlbCBNaXJtYWsgcmVwb3J0
ZWQgdGhhdCBib3RoIGNvbW1pdHRlZXMgbWV0IGxhc3QgVGh1cnNkYXkgYW5kIGNvbnRpbnVlDQp0
byBtZWV0IGV2ZXJ5IHR3byB3ZWVrcy4gVGhlIENvb2tib29rIGNvbW1pdHRlZSdzIGxhdGVzdCBj
b29rYm9vayBkcmFmdA0KaW5jbHVkZXMgcmV2aXNpb25zIHRvIHRoZSBbUGluIE1hcHBpbmddIGFu
ZCBbU2VyaWVzICpdIGRlc2NyaXB0aW9ucy4gIEENCm1ham9yIG92ZXJoYXVsIHRvIHRoZSBjbGFt
cCBjdXJ2ZXMgc2VjdGlvbiBpcyBpbiBwcm9ncmVzcy4gIFRoZSBGdXR1cmVzDQpjb21taXR0ZWUg
ZGlzY3Vzc2VkIHBhcnNlciBpc3N1ZXMgb2YgSUJJUyA0LjEgYW5kIHRoZSBoaWVyYXJjaHkgb2YN
CltFeHRlcm5hbCBNb2RlbF0sIFtFeHRlcm5hbCBDaXJjdWl0XSwgYW5kIFtNb2RlbF0ga2V5d29y
ZHMgYXMgd2VsbCBhcw0KaW50ZWdyYXRpb24gb2YgSUNNLiAgU29tZSBCSVJEcyB3aWxsIGJlIGlu
dHJvZHVjZWQgc29vbi4NCg0KDQpSZWNlbnQgY29tbWl0dGVlIG1hdGVyaWFsIGlzIHN0b3JlZCBh
dDoNCg0KICAgaHR0cDovL3d3dy5pYmlzLWluZm9ybWF0aW9uLm9yZy9mdXR1cmVzLw0KDQoNCk5F
VyBBRE1JTklTVFJBVElWRSBJU1NVRVMNCk5vbmUuDQoNCg0KQklSRDkyLjE6IE1VTFRJUExFIFRF
Uk1JTkFUT1IgQU5EIFNFUklFUyBFTEVNRU5UUyBVTkRFUiBbTU9ERUxdDQpNaWNoYWVsIE1pcm1h
ayByZXBvcnRlZCB0aGF0IGEgcXVlc3Rpb24gYXJvc2UgcmVjZW50bHkgb24gaG93IFtPbl0gYW5k
IFtPZmZdDQprZXl3b3JkcyBhcmUgdHJlYXRlZCB3aXRoIHJlc3BlY3QgdG8gW01vZGVsXSB0eXBl
IFNlcmllcyBhbmQgbm90IGp1c3QNClNlcmllc19zd2l0Y2guICBNaWNoYWVsIHNhaWQgdGhhdCB0
aGlzIHdpbGwgbmVlZCB0byBiZSB0aG9yb3VnaGx5IGNoZWNrZWQNCmJlZm9yZSB2b3Rpbmcgb24g
dGhlIEJJUkQuICBWb3Rpbmcgd2FzIHBvc3Rwb25lZC4NCg0KDQpCSVJEOTMuMTogTU9ERUwgQU5E
IFNJR05BTCBOQU1FIExJTUlUIEVYVEVOU0lPTg0KTWljaGFlbCBNaXJtYWsgc3VtbWFyaXplZCB0
aGUgQklSRC4gIEl0IGxlbmd0aGVucyBtb2RlbF9uYW1lIGFuZCBzaWduYWxfbmFtZQ0KZmllbGRz
IGZyb20gMjAgdG8gNDAgY2hhcmFjdGVycy4gIFRoZSBhZGRlZCBsZW5ndGggb2YgdGhlc2UgZmll
bGRzIHN0aWxsDQpmaXRzIHdpdGhpbiB0aGUgMTIwIGNoYXJhY3RlciBsaW5lIGxlbmd0aCBsaW1p
dC4gIERvbmFsZCBUZWxpYW4gd2FzDQpjb25jZXJuZWQgd2l0aCBpbXBsZW1lbnRhdGlvbiBvZiB0
aGlzIGluIHRvb2xzLiAgSW5jcmVhc2luZyB0aGUgbnVtYmVyIG9mDQpjaGFyYWN0ZXJzIGNvdWxk
IHJlcXVpcmUgbGVuZ3RoZW5pbmcgb2YgZmllbGRzIGluIEdVSSBib3hlcy4gIE1pY2hhZWwNCm1l
bnRpb25lZCBtYWtpbmcgc3VnZ2VzdGlvbnMgaW4gdGhlIGNvb2tib29rIHRvIGtlZXAgbmFtZXMg
YXMgc2hvcnQgYXMNCnBvc3NpYmxlLiAgQSB2b3RlIHdhcyBjYWxsZWQgZm9yIGFuZCBzZWNvbmRl
ZC4gIFB1cnN1YW50IHRvIEdFSUEgcnVsZXMsIHRoZQ0Kdm90ZSB0YWxseSBwZXIgb3JnYW5pemF0
aW9uIGlzIG5vdyByZWNvcmRlZCBpbiB0aGUgbWludXRlcy4gIFRoZSBCSVJEIHdhcw0KYXBwcm92
ZWQgd2l0aCB0aGUgZm9sbG93aW5nIHZvdGUgdGFsbHk6DQoNCkNhZGVuY2UgRGVzaWduIFN5c3Rl
bXMgICAgICAgICAgLSBhYnN0YWluDQpJbnRlbCAgICAgICAgICAgICAgICAgICAgICAgICAgIC0g
eWVzDQpMU0kgTG9naWMgICAgICAgICAgICAgICAgICAgICAgIC0geWVzDQpNZW50b3IgR3JhcGhp
Y3MgICAgICAgICAgICAgICAgIC0geWVzDQpNaWNyb24gICAgICAgICAgICAgICAgICAgICAgICAg
IC0geWVzDQpTaWduYWwgSW50ZWdyaXR5IFNvZnR3YXJlICAgICAgIC0geWVzDQpUZXJhc3BlZWQg
Q29uc3VsdGluZyBHcm91cCAgICAgIC0geWVzDQoNCg0KSUlSRDIuMzogRlJFUVVFTkNZIERFUEVO
REVOVCBSTEdDIE1BVFJJQ0VTDQpWb3RlIHBvc3Rwb25lZCBkdWUgdG8gbGFjayBvZiBhdmFpbGFi
bGUgZGlzY3Vzc2lvbiB0aW1lLg0KDQoNCklJUkQ4LjE6IERJU1RJTkNUIE1PREVMX1BJTk1BUCBB
TkQgTU9ERUxfTk9ERU1BUCBOQU1FUw0KQm9iIFJvc3MgcmVwb3J0ZWQgcmVjZWl2aW5nIGEgY29t
bWVudCB0aGF0IHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgc2lkZQ0Kc3VicGFyYW1ldGVyIG5lZWRz
IHRvIGJlIG1hZGUgbW9yZSBjbGVhci4gIFRoZSB2b3RlIHdhcyBwb3N0cG9uZWQgdG8gYWxsb3cN
CmZvciB0aW1lIHRvIGFkZHJlc3MgdGhpcyBjb21tZW50Lg0KDQoNCklCSVNDSEs0IEJVRyBTVEFU
VVMNCk1pY2hhZWwgTWlybWFrIHJlcG9ydGVkIHRoYXQgbm8gQlVHcyBoYXZlIGJlZW4gZmlsZWQu
DQoNCg0KSUNNQ0hLMSBCVUcgU1RBVFVTDQpCVUcxOiBURVhUIEJMT0NLIE9WRVJGTE9XIEZPUiBW
RVJZIFZFUkJPU0UgTU9ERQ0KTWljaGFlbCBNaXJtYWsgcmVwb3J0ZWQgdGhlIGZpbGluZyBvZiB0
aGlzIEJVRy4gIFRoZSB2ZXJ5IHZlcmJvc2UgbW9kZSBpcyBhDQptb2RlIG9mIHRoZSBwYXJzZXIg
dXNlZCBmb3IgZGVidWdnaW5nLiAgVGhlIGxlbmd0aCBvZiBjZXJ0YWluIHRleHQgYmxvY2tzIGlu
DQp0aGUgbW9kZWwgY2F1c2UgdGhlIHBhcnNlciB0byBjcmFzaC4gIEl0IHdhcyBkZXRlcm1pbmVk
IHRoYXQgbm8gaW50ZXJpbQ0KcmVsZWFzZSBvZiB0aGUgcGFyc2VyIGlzIG5lZWRlZCB0byBmaXgg
dGhpcyBCVUcuICBUaGUgQlVHIGNhbiBiZSBmaXhlZCBhbG9uZw0Kd2l0aCBvdGhlciBJSVJEcyBp
biB0aGUgbmV4dCBvZmZpY2lhbCByZWxlYXNlLiBUaGUgQlVHIHJlcG9ydCB3YXMgY2xhc3NpZmll
ZA0KYXMgT3BlbiwgTW9kZXJhdGUsIHdpdGggTWVkaXVtIHByaW9yaXR5Lg0KDQoNCk5FVyBURUNI
TklDQUwgSVNTVUVTDQpOb25lLg0KDQoNCk5FWFQgTUVFVElORw0KQW4gT3BlbiBGb3J1bSB0ZWxl
Y29uZmVyZW5jZSBoYXMgYmVlbiBzY2hlZHVsZWQgZm9yIEphbnVhcnkgNywgMjAwNQ0KZnJvbSA4
OjAwIEFNIHRvIDEwOjAwIEFNIFVTIFBhY2lmaWMgVGltZS4NCg0KDQo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTk9URVMNCg0KSUJJUyBDSEFJUjog
TWljaGFlbCBNaXJtYWsgKDkxNikgMzU2LTQyNjEsIEZheDogKDkxNikgMzc3LTEwNDYNCiAgICAg
ICAgICAgIG1pY2hhZWwubWlybWFrQGludGVsLmNvbQ0KICAgICAgICAgICAgU2VuaW9yIEFuYWxv
ZyBFbmdpbmVlciwgSW50ZWwgQ29ycG9yYXRpb24NCiAgICAgICAgICAgIEZNNi00NQ0KICAgICAg
ICAgICAgMTkwMCBQcmFpcmllIENpdHkgUmQuDQogICAgICAgICAgICBGb2xzb20sIENBICA5NTYz
MA0KDQpWSUNFIENIQUlSOiBTeWVkIEh1cSAoNDA4KSA1MjUtMzM5OSwgRmF4OiAoNDA4KSA1MjYt
NTUwNA0KICAgICAgICAgICAgc2h1cUBjaXNjby5jb20NCiAgICAgICAgICAgIE1hbmFnZXIsIEhh
cmR3YXJlIEVuZ2luZWVyaW5nLCBDaXNjbyBTeXN0ZW1zDQogICAgICAgICAgICAxNzAgV2VzdCBU
YXNtYW4gRHJpdmUNCiAgICAgICAgICAgIFNhbiBKb3NlLCBDQSA5NTEzNC0xNzA2DQoNClNFQ1JF
VEFSWTogIFJhbmR5IFdvbGZmICgyMDgpIDM2My0xNzY0LCBGYXg6ICgyMDgpIDM2OC0zNDc1DQog
ICAgICAgICAgICBycndvbGZmQG1pY3Jvbi5jb20NCiAgICAgICAgICAgIFNpbXVsYXRpb24gRW5n
aW5lZXIsIE1pY3JvbiBUZWNobm9sb2d5LCBJbmMuDQogICAgICAgICAgICA4MDAwIFMuIEZlZGVy
YWwgV2F5DQogICAgICAgICAgICBNYWlsIFN0b3A6IDEtNzExDQogICAgICAgICAgICBCb2lzZSwg
SUQgODM3MDctMDAwNg0KDQpMSUJSQVJJQU46ICBMYW5jZSBXYW5nICg5NzgpIDI2Mi02Njg1LCBG
YXg6ICg5NzgpIDI2Mi02MzYzDQogICAgICAgICAgICBsd2FuZ0BjYWRlbmNlLmNvbQ0KICAgICAg
ICAgICAgU2VuaW9yIE1lbWJlciwgVGVjaG5pY2FsIFN0YWZmLCBDYWRlbmNlIERlc2lnbiBTeXN0
ZW1zLCBJbmMuDQogICAgICAgICAgICAyNzAgQmlsbGVyaWNhIFJvYWQNCiAgICAgICAgICAgIENo
ZWxtc2ZvcmQsIE1BIDAxODI0DQoNCldFQk1BU1RFUjogIFN5ZWQgSHVxICg0MDgpIDUyNS0zMzk5
LCBGYXg6ICg0MDgpIDUyNi01NTA0DQogICAgICAgICAgICBzaHVxQGNpc2NvLmNvbQ0KICAgICAg
ICAgICAgTWFuYWdlciwgSGFyZHdhcmUgRW5naW5lZXJpbmcsIENpc2NvIFN5c3RlbXMNCiAgICAg
ICAgICAgIDE3MCBXZXN0IFRhc21hbiBEcml2ZQ0KICAgICAgICAgICAgU2FuIEpvc2UsIENBIDk1
MTM0LTE3MDYNCg0KUE9TVE1BU1RFUjogQm9iIFJvc3MgKDUwMykgMjQ2LTgwNDgsIEZheCA6ICg1
MDMpIDIzOS00NDAwDQogICAgICAgICAgICBib2JAdGVyYXNwZWVkLmNvbQ0KICAgICAgICAgICAg
U3RhZmYgU2NpZW50aXN0LCBUZXJhc3BlZWQgQ29uc3VsdGluZyBHcm91cA0KICAgICAgICAgICAg
MTAyMzggU1cgTGFuY2FzdGVyIFJvYWQNCiAgICAgICAgICAgIFBvcnRsYW5kLCBPUiA5NzIxOQ0K
DQoNClRoaXMgbWVldGluZyB3YXMgY29uZHVjdGVkIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgR0VJ
QSBMZWdhbCBHdWlkZXMgYW5kDQpHRUlBIE1hbnVhbCBvZiBPcmdhbml6YXRpb24gYW5kIFByb2Nl
ZHVyZS4NCg0KVGhlIGZvbGxvd2luZyBlLW1haWwgYWRkcmVzc2VzIGFyZSB1c2VkOg0KDQogIG1h
am9yZG9tb0BlZGEub3JnDQogICAgICBJbiB0aGUgYm9keSwgZm9yIHRoZSBJQklTIE9wZW4gRm9y
dW0gUmVmbGVjdG9yOg0KICAgICAgc3Vic2NyaWJlIGliaXMgPHlvdXIgZS1tYWlsIGFkZHJlc3M+
DQoNCiAgICAgIEluIHRoZSBib2R5LCBmb3IgdGhlIElCSVMgVXNlcnMnIEdyb3VwIFJlZmxlY3Rv
cjoNCiAgICAgIHN1YnNjcmliZSBpYmlzLXVzZXJzIDx5b3VyIGUtbWFpbCBhZGRyZXNzPg0KDQog
ICAgICBIZWxwIGFuZCBvdGhlciBjb21tYW5kczoNCiAgICAgIGhlbHANCg0KICBpYmlzLXJlcXVl
c3RAZWRhLm9yZw0KICAgICAgVG8gam9pbiwgY2hhbmdlLCBvciBkcm9wIGZyb20gZWl0aGVyIHRo
ZSBJQklTIE9wZW4gRm9ydW0gUmVmbGVjdG9yDQogICAgICAoaWJpc0BlZGEub3JnKSwgdGhlIElC
SVMgVXNlcnMnIEdyb3VwIFJlZmxlY3Rvcg0KICAgICAgKGliaXMtdXNlcnNAZWRhLm9yZykgb3Ig
Ym90aC4gIFN0YXRlIHlvdXIgcmVxdWVzdC4NCg0KICBpYmlzLWluZm9AZWRhLm9yZw0KICAgICAg
VG8gb2J0YWluIGdlbmVyYWwgaW5mb3JtYXRpb24gYWJvdXQgSUJJUywgdG8gYXNrIHNwZWNpZmlj
DQogICAgICBxdWVzdGlvbnMgZm9yIGluZGl2aWR1YWwgcmVzcG9uc2UsIGFuZCB0byBpbnF1aXJl
IGFib3V0IGpvaW5pbmcNCiAgICAgIHRoZSBFSUEtSUJJUyBPcGVuIEZvcnVtIGFzIGEgZnVsbCBN
ZW1iZXIuDQoNCiAgaWJpc0BlZGEub3JnDQogICAgICBUbyBzZW5kIGEgbWVzc2FnZSB0byB0aGUg
Z2VuZXJhbCBJQklTIE9wZW4gRm9ydW0gUmVmbGVjdG9yLiAgVGhpcw0KICAgICAgaXMgdXNlZCBt
b3N0bHkgZm9yIElCSVMgU3RhbmRhcmRpemF0aW9uIGJ1c2luZXNzIGFuZCBmdXR1cmUgSUJJUw0K
ICAgICAgdGVjaG5pY2FsIGVuaGFuY2VtZW50cy4gIEpvYiBwb3N0aW5nIGluZm9ybWF0aW9uIGlz
IG5vdCBwZXJtaXR0ZWQuDQoNCiAgaWJpcy11c2Vyc0BlZGEub3JnDQogICAgICBUbyBzZW5kIGEg
bWVzc2FnZSB0byB0aGUgSUJJUyBVc2VycycgR3JvdXAgUmVmbGVjdG9yLiAgVGhpcyBpcw0KICAg
ICAgdXNlZCBtb3N0bHkgZm9yIElCSVMgY2xhcmlmaWNhdGlvbiwgY3VycmVudCBtb2RlbGluZyBp
c3N1ZXMsIGFuZA0KICAgICAgZ2VuZXJhbCB1c2VyIGNvbmNlcm5zLiAgSm9iIHBvc3RpbmcgaW5m
b3JtYXRpb24gaXMgbm90IHBlcm1pdHRlZC4NCg0KICBpYmlzLWJ1Z0BlZGEub3JnDQogICAgICBU
byByZXBvcnQgaWJpc2NoayBwYXJzZXIgYnVncy4gIFRoZSBCdWcgUmVwb3J0IEZvcm0gUmVzaWRl
cyBvbg0KICAgICAgZWRhLm9yZyBpbiAvcHViL2liaXMvYnVncy9pYmlzX2J1Z3MvYnVnZm9ybS50
eHQgYWxvbmcgd2l0aA0KICAgICAgcmVwb3J0ZWQgYnVncy4NCg0KICBpY20tYnVnQGVkYS5vcmcN
CiAgICAgIFRvIHJlcG9ydCBpY21jaGsxIHBhcnNlciBidWdzLiAgVGhlIEJ1ZyBSZXBvcnQgRm9y
bSBSZXNpZGVzIG9uDQogICAgICBlZGEub3JnIGluIC9wdWIvaWJpcy9idWdzL2ljbV9idWdzL2lj
bV9idWdmb3JtLnR4dCBhbG9uZyB3aXRoDQogICAgICByZXBvcnRlZCBidWdzLg0KDQogICAgICBU
byByZXBvcnQgczJpYmlzLCBzMmliaXMyIGFuZCBzMmlwbHQgYnVncywgdXNlIHRoZSBCdWcgUmVw
b3J0DQogICAgICBGb3JtcyB3aGljaCByZXNpZGUgdW5kZXIgZWRhLm9yZyBpbg0KICAgICAgL3B1
Yi9pYmlzL2J1Z3MvczJpYmlzL2J1Z3MyaS50eHQsDQogICAgICAvcHViL2liaXMvYnVncy9zMmli
aXMyL2J1Z3MyaTIudHh0IGFuZA0KICAgICAgL3B1Yi9pYmlzL2J1Z3MvczJpcGx0L2J1Z3NwbHQu
dHh0IHJlc3BlY3RpdmVseS4NCg0KSW5mb3JtYXRpb24gb24gSUJJUyB0ZWNobmljYWwgY29udGVu
dHMsIElCSVMgcGFydGljaXBhbnRzIGFuZCBhY3R1YWwNCklCSVMgbW9kZWxzIGFyZSBhdmFpbGFi
bGUgb24gdGhlIElCSVMgSG9tZSBwYWdlOg0KDQogIGh0dHA6Ly93d3cuZWlncm91cC5vcmcvaWJp
cy9pYmlzLmh0bQ0KDQpDaGVjayB0aGUgSUJJUyBmaWxlIGRpcmVjdG9yeSBvbiBlZGEub3JnIGZv
ciBtb3JlIGluZm9ybWF0aW9uIG9uDQpwcmV2aW91cyBkaXNjdXNzaW9ucyBhbmQgcmVzdWx0czoN
Cg0KICBodHRwOi8vd3d3LmVkYS5vcmcvcHViL2liaXMvZGlyZWN0b3J5Lmh0bWwNCg0KQWxsIGVk
YS5vcmcgZG9jdW1lbnRzIGNhbiBiZSBhY2Nlc3NlZCB1c2luZyBhIG1pcnJvcjoNCg0KICBodHRw
Oi8vd3d3LmliaXMtaW5mb3JtYXRpb24ub3JnDQoNCk5vdGUgdGhhdCB0aGUgInB1Yi9pYmlzIiB0
ZXh0IHNob3VsZCBiZSByZW1vdmVkIGZyb20gZGlyZWN0b3J5IG5hbWVzDQp3aGVuIHRoaXMgVVJM
IG1pcnJvciBpcyB1c2VkLg0KDQoqIE90aGVyIHRyYWRlbWFya3MsIGJyYW5kcyBhbmQgbmFtZXMg
YXJlIHRoZSBwcm9wZXJ0eSBvZg0KICB0aGVpciByZXNwZWN0aXZlIG93bmVycy4NCg==

- ------_=_NextPart_001_01C4E2BC.0C438C6D--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 15 Dec 2004 21:42:20 +0530
From: Akhilesh CHANDRA <akhilesh.chandra@st.com>
Subject: Re: [IBIS-Users] way to extract rising and falling waveform in differential cells

Hello Tom,

Is spice to IBIS tool calculate the waveform data for differential cell 
also, means cell have just a swing of 300mv, because till date I am not 
able to see IBIS model of a differential cell that have limted swing 
with waveform information.

With Best regards
Akhilesh

Tom Dagostino wrote:

>Akhilesh
>
>A ramp based model simulation will start its transition immediately, there
>is no time delay built into the model.  A SPICE simulation will include the
>delay of the buffer and other effects you are seeing in the SPICE output.
>If you want the two to match you need to include the full waveform models in
>the IBIS model.  These waveforms need to be extracted preserving the time
>delay of the buffer.  Using the SPICE to IBIS tools available on the IBIS
>web page should give you the results you want.
>
>If you need assistance in using this we can help.
>
>Tom Dagostino
>Teraspeed Consulting Group LLC
>503-430-1065
>tom@teraspeed.com
>www.teraspeed.com
>
>-----Original Message-----
>From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On
>Behalf Of Akhilesh CHANDRA
>Sent: Tuesday, December 14, 2004 5:48 AM
>To: ibis-users@eda.org
>Cc: Akhilesh CHANDRA
>Subject: [IBIS-Users] way to extract rising and falling waveform in
>differential cells
>
>
>Hello Friends,
>
>   I am devloping IBIS model of a differential cell having swing 300mv.
>when I run simulation at 300mhz then I find out there is a transition
>shift between IBIS and spice result. In my model I give just ramp
>database dv/dt for transition. In my view this problem may be resolve if
>I give complete rising and falling waveform in my models.
>  Is anyone know how we can extract rising and falling waveform for a
>cell that have differential swing or any other way to reduce this shift.
>
>  My results are attached with the mail.
>
>regards
>Akhilesh
>
>
>
>
>  
>


|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 15 Dec 2004 09:34:16 -0800
From: Bob Ross <bob@teraspeed.com>
Subject: Re: [IBIS-Users] Hspice ibischk4 tool

Fabrizio:

The difference between ibischk4 Version 4.0.1 and ibischk4 Version 4.0.1
is BUG82.  BUG82 was serious enough to justify a special release of
ibischk4.

   http://eda.org/pub/ibis/bugs/ibischk/index.html

A text list of what verion a bug fix has been implemented exists
in the bugdir.txt file link at the end of this link.

Bob

Zanella, Fabrizio wrote:

> The latest version of Synopsys Hspice, version 2004.09, uses the 
> ibischk4 tool, version 4.0.1.   In a simulation I ran yesterday, Hspice 
> reported errors running the v4.0.1 ibischk4 with the rising and falling 
> waveforms when using an IBIS model as a driver.
> 
> Here’s a sample of the errors:
> 
> ERROR - Model osoc2_od: The [Rising Waveform]
> 
>       with [R_fixture]=60 Ohms and [V_fixture]=3.3V
> 
>       has TYP column DC endpoints of  2.02V and  3.30v, but
> 
>       an equivalent load applied to the model's I-V tables yields
> 
>       different voltages ( 2.02V and  2.02V),
> 
>       a difference of   inf% and   inf%, respectively.
> 
> ERROR - Model osoc2_od: The [Falling Waveform]
> 
>       with [R_fixture]=60 Ohms and [V_fixture]=3.3V
> 
>       has TYP column DC endpoints of  2.02V and  3.30v, but
> 
>       an equivalent load applied to the model's I-V tables yields
> 
>       different voltages ( 2.02V and  2.02V),
> 
>       a difference of   inf% and   inf%, respectively.
> 
>  
> 
> An engineer at the device manufacturer said there are no errors when he 
> uses the ibischk4 v4.0.2 tool.  Can someone explain what the differences 
> are between versions 4.0.1 and 4.0.2 of the ibischk4 tool and does 
> anyone know whether Synopsys will be moving to the latest ibischk4 tool 
> in the Hspice simulator?
> 
> Thanks and regards,
> 
>  
> 
> Fabrizio Zanella
> 
> Signal Integrity
> 
> Enterasys Networks
> 
> Andover, MA
> 
> Phone:  978-684-1340
> 
> fzanella@enterasys.com <mailto:fzanella@enterasys.com>
> 
>  
> 

- -- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
503-750-6481                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com


|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 16 Dec 2004 14:09:44 +0100
From: Ralf Bruening <ralf.bruening@zuken.de>
Subject: [IBIS-Users] European IBIS Summit At DATe 2005 -First  Call for Paper/Call for Participation

To All:
       We have been holding successful European IBIS Summit Meetings for the 
       past seven years.  Next year we are again holding a meeting along with
       DATe 05 on Friday, March 11, 2005.  The purpose is to promote
       communication among users and developers of IBIS models in Europe. 
       The meeting is free and open to everyone.  However, you will have 
       to register for the exhibition at DATe (to get access to the 
       meeting room).  Refreshments are planned. 
       Below is some information on the IBIS Summit and some related events. 
       You are invited to register and also to submit presentation proposals.
       
  Ralf Bruening 
  Product Manager High Speed Design 
  ZUKEN EMC Technology Center 

- ----------------------------------------------------------------------------------- 
  E U R O P E A N   I B I S   S U M M I T   M E E T I N G 
    F I R S T   C A L L   F O R  P A R T I C I P A T I O N
 Time/Date:     9:00 AM - 2:00 PM, Friday, March 11, 2004
 Location:      Meeting room @ ICM Messe Munich (Munich ICM Congress Center)
                Munich, Germany (where DATE 2005 is being held).
                
                Free DATE 2005 exhibition registration for room entry,
                see URL below.
                
 Content:       Presentations and Discussions
 
 Purpose:       Solicit and Exchange IBIS Model Related Information and Ideas 

 Sponsors:      Zuken, Mentor Graphics, Cadence Design
                       Systems/Flowcad, Siemens.
                       
                If your company would be interested in sponsoring this 
                event, please contact or Ralf Bruening
                <ralf.bruening@zuken.de> or Eckard Lenski from
                Siemens AG <eckhard.lenski@siemens.com>
                
                Benefits to sponsors include formal recognition at the 
                meeting and mention 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. 

 DATE 2005 Conference:     March 07-11, 2005.  The IBIS meeting is scheduled
                the day after the DATE 2005 exhibition ends.
                
 Location:      ICM International Congress Center, Munich, Germany
 DATE URL:      http://www.date-conference.com 

 Background: 
                DATE (Design, Automation, and Test in Europe) is the only European 
                event dedicated to electronic system design and test.  Topics of 
                current interest to the EIA IBIS Open Forum are addressed at DATE. 
                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.
                
                Topics and presentations may include (list is 
                open for further contributions): 

                - Submitted Presentations on IBIS Topics (See below) 
                - Information about the most recent IBIS Developments 
                - Less formal Ad Hoc Presentations and Discussions 
                - IBIS and Modelling Questions and Answers
                
                The meeting is free and open to everyone.  However, you will have 
                to register for the exhibition at DATe (to get access to the 
                meeting room).  Refreshments are planned. 
                Below is some information on the IBIS Summit and some related events. 
                You are invited to register and also to submit presentation proposals. 


CALL FOR PARTICIPANTS 
     People involved in IBIS Model development, EDA tool development, and digital 
     circuit design are invited to participate in the European IBIS Summit meeting. 
     If you plan to participate, please register with the information below 
     (deadline, Febrary 25th, 2005):
     
     Name: 
     E-mail address: 
     Company: 
     Telephone: 
 Send to: 
   Ralf Bruening (ralf.bruening@zuken.de) 
   
 CALL FOR PRESENTATIONS 
      We are seeking presentations from individuals who have IBIS experiences 
      or issues.  Some suggested subjects of interest are:
      
      - IBIS Model Development Experiences 
      - Company IBIS Standards and Requirements 
      - Generating and Validating IBIS Models 
      - Future IBIS Requirements 
      - Modelling of dedicated technology issues (i.e.
        connectors, very high speed interfaces)
      - EMC/EMI IBIS Issues 
      - Experiences using IBIS in the PCB Design process 
   
   Format of Presentation:  LCD or Overhead Projections 
   Time:                    15-30 Minutes 
   Electronic Archival:     We request electronic versions so that the 
                            presentations can be archived and also made 
                            available to non-attendees.  Formats used in 
                            the past have been text, Power Point, Word, 
                            Postscript, and Acrobat PDF. 
                            Electronic presentations should be made 
                            available by February the 25th, 2005.
                            Otherwise the presentor will be expected to 
                            provide 30 copies for distribution.
                            
  If you plan a presentation, please supply 
   Title: 
   Presenter: 
   E-mail address: 
   Company: 
   Telephone: 
   Estimate Time: 
 Send this to both: 
   Ralf Bruening  (ralf.bruening@zuken.de) 

AGENDA 
      The agenda includes presentations, discussions, breaks, and 
      a luncheon (which will be provided).  This will be developed as 
      presentation proposals are received. 

LIST OF NEARBY HOTELS 
     See <http://www.date-conference.com/conference/travel.htm> for 
     travel directions, hotels and other information. 

Looking forward to meeting you at DATe 2005 in Munich
   
   Ralf Bruening 

_____________________________________________
 
Ralf Bruening 
Product Manager High Speed Design/Partner & Solution Business
Zuken EMC Technology Center
Vattmannstr.3 
33100 Paderborn  
Germany

 
Tel: ++49 (0) 5251 150 600 (direct -621) 
Fax: ++49 (0) 5251 150 700
Cellular: +49 170 4228512 (alternative: +49 172 9070675)

Email: ralf.bruening@zuken.de 
Web: www.zuken.com 
_____________________________________________
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  If you have
received it in error, please notify the sender immediately and delete
the original.  Any other use of the email by you is prohibited. 

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 16 Dec 2004 16:32:53 -0800
From: "Mirmak, Michael" <michael.mirmak@intel.com>
Subject: [IBIS-Users] BIRD94: Clarifications on [Diff Pin] Parameters

This is a multi-part message in MIME format.

- ------_=_NextPart_001_01C4E3CF.F2C24381
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The enclosed BIRD, Clarifications on [Diff Pin] Parameters, is
distributed on behalf of Arpad Muranyi of Intel Corporation.  It will be
discussed at the January 7, 2005 IBIS Open Forum teleconference.

- - Michael Mirmak
  Intel Corp.
  Chair, EIA IBIS Open Forum




- ------_=_NextPart_001_01C4E3CF.F2C24381
Content-Type: text/plain;
	name="BIRD94.txt"
Content-Transfer-Encoding: base64
Content-Description: BIRD94.txt
Content-Disposition: attachment;
	filename="BIRD94.txt"

KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KQklSRCBJRCM6
ICAgICAgICA5NA0KSVNTVUUgVElUTEU6ICAgICBDbGFyaWZpY2F0aW9ucyBvbiBbRGlmZiBQaW5d
IFBhcmFtZXRlcnMNClJFUVVFU1RFUjogICAgICAgQXJwYWQgTXVyYW55aSwgSW50ZWwgQ29ycC4N
CkRBVEUgU1VCTUlUVEVEOiAgRGVjZW1iZXIgOCwgMjAwNA0KREFURSBBQ0NFUFRFRCBCWSBJQklT
IE9QRU4gRk9SVU06ICBQRU5ESU5HDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqDQoNClNUQVRFTUVOVCBPRiBUSEUgSVNTVUU6DQoNClRoZXJlIGFyZSBhIG51
bWJlciBvZiBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgW0RpZmYgUGluXSBrZXl3b3JkIGluIHRoZSBJ
QklTDQpzcGVjaWZpY2F0aW9uLg0KDQpMaXN0IG9mIGlzc3VlczoNCg0KMSkgIFRoZSBzdGF0ZW1l
bnQ6ICAiVGhlIHRoaXJkIGNvbHVtbiwgdmRpZmYsIGNvbnRhaW5zIHRoZSBzcGVjaWZpZWQgb3V0
cHV0DQogICAgYW5kIGRpZmZlcmVudGlhbCB0aHJlc2hvbGQgdm9sdGFnZSBiZXR3ZWVuIHBpbnMg
aWYgdGhlIHBpbnMgYXJlIElucHV0IG9yDQogICAgSS9PIG1vZGVsIHR5cGVzIiAgVGhlIHByb2Js
ZW0gd2l0aCB0aGlzIHN0YXRlbWVudCBpcyB0aGF0LCBjb250cmFyeSB0bw0KICAgIHdoYXQgaXQg
c2F5cywgdmRpZmYgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBvdXRwdXRzLg0KDQoyYSkgVGhlIHN0
YXRlbWVudDogICJJZiB2ZGlmZiBpcyBub3QgZGVmaW5lZCAuLi4gdmRpZmYgaXMgc2V0IHRvIHRo
ZSBkZWZhdWx0DQogICAgdmFsdWUgb2YgMjAwIG1WIiAgZGlyZWN0bHkgY29udHJhZGljdHMgdGhl
IHN0YXRlbWVudDogICJJZiAiTkEiIGlzDQogICAgZW50ZXJlZCBpbiB0aGUgdmRpZmYsIHRkZWxh
eV90eXAsIG9yIHRkZWxheV9taW4gY29sdW1ucywgaXRzIGVudHJ5IGlzDQogICAgaW50ZXJwcmV0
ZWQgYXMgMCBWIG9yIDAgbnMiLCBzaW5jZSB0aGUgb25seSB3YXkgdmRpZmYgY2FuIGJlICJub3QN
CiAgICBkZWZpbmVkIiBpZiBpdHMgdmFsdWUgY29udGFpbnMgYW4gIk5BIi4NCg0KMmIpIFRoZSBz
dGF0ZW1lbnQ6ICAiSWYgYSBwaW4gaXMgYSBkaWZmZXJlbnRpYWwgaW5wdXQgcGluLCB0aGUgZGlm
ZmVyZW50aWFsDQogICAgaW5wdXQgdGhyZXNob2xkICh2ZGlmZikgb3ZlcnJpZGVzIGFuZCBzdXBl
cnNlZGVzIHRoZSBuZWVkIGZvciBWaW5oIGFuZA0KICAgIFZpbmwiIG9ubHkgdGFsa3MgYWJvdXQg
ImlucHV0IiBwaW5zLCB3aGlsZSB0aGlzIHJ1bGUgaXMgdmFsaWQgZm9yIGFsbA0KICAgIG90aGVy
IG1vZGVsIHR5cGVzIHdoaWNoIGhhdmUgYW4gaW5wdXQsIHN1Y2ggYXMgYW4gSS9PLiAgQWxzbywg
c3RyaWN0bHkNCiAgICBzcGVha2luZyB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzICJhIGRpZmZl
cmVudGlhbCAuLi4gcGluIiAoaW4gc2luZ3VsYXIpLg0KDQozYSkgRXhjZXB0IGZvciB0aGUgW0V4
dGVybmFsIE1vZGVsXSBrZXl3b3JkLCB0aGUgc3BlY2lmaWNhdGlvbiBkb2Vzbid0DQogICAgc3Bl
bGwgb3V0IGFueSByZXF1aXJlbWVudHMgYWJvdXQgd2hhdCBbTW9kZWxdIG5hbWVzIGFuZCBtb2Rl
bCB0eXBlcyBhcmUNCiAgICBhbGxvd2VkIG9uIHRoZSBbUGluXSBsaXN0IGZvciB0aG9zZSBwaW5z
IHdoaWNoIGFyZSBhc3NvY2lhdGVkIGJ5IHRoZQ0KICAgIFtEaWZmIFBpbl0ga2V5d29yZCBhcyBh
IGRpZmZlcmVudGlhbCBwYWlyLiAgQ29uc2VxdWVudGx5LCBoaWdobHkNCiAgICBxdWVzdGlvbmFi
bGUgYW5kIHVubGlrZWx5IGRpZmZlcmVudGlhbCBwYWlycyBjYW4gYmUgY3JlYXRlZCBpZiwgZm9y
DQogICAgZXhhbXBsZSwgb25lIFtNb2RlbF0gb2YgdGhlIHBhaXIgaXMgYW4gaW5wdXQgdHlwZSBh
bmQgdGhlIG90aGVyIGFuDQogICAgb3V0cHV0IHR5cGUuDQoNCjNiKSBVbmRlciB0aGUgW0V4dGVy
bmFsIE1vZGVsXSBrZXl3b3JkLCB0aGUgc2VudGVuY2U6ICAiVGhlIG1vZGVscw0KICAgIHJlZmVy
ZW5jZWQgYnkgZWFjaCBwaW4gbGlzdGVkIHVuZGVyIFtEaWZmIFBpbl0gTVVTVCBiZSB0aGUgc2Ft
ZSIgZG9lcw0KICAgIG5vdCBzdGF0ZSBpdCBjbGVhcmx5IHRoYXQgaXQgaXMgdGhlIG5hbWUgb2Yg
dGhlIFtNb2RlbF0gb3IgW01vZGVsDQogICAgU2VsZWN0b3JdIHdoaWNoIG11c3QgbWF0Y2guICBB
bHNvLCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSBlbnRpcmVzIHVuZGVyDQogICAgYSBbRGlmZiBQ
aW5dIGtleXdvcmQsIHRoaXMgc2VudGVuY2UgY2FuIGVhc2lseSBiZSBtaXNpbnRlcnByZXRlZCB0
byBpbXBseQ0KICAgIHRoYXQgdGhlIGFib3ZlIHJ1bGUgbXVzdCBiZSBlbmZvcmNlZCBmb3IgYWxs
IGVudHJpZXMsIHdoaWxlIHRoZSBpbnRlbnRpb24NCiAgICBmb3IgdGhpcyBydWxlIGlzIHBlciBl
bnRyeSAobGluZSkgb25seS4NCg0KM2MpIFRoZXJlIGlzIG5vIG1lbnRpb24gaW4gdGhlIHNwZWNp
ZmljYXRpb24gaG93IHRoZSBjYXNlIHNob3VsZCBiZSBoYW5kbGVkDQogICAgd2hlbiB0aGVyZSBh
cmUgW01vZGVsIFNlbGVjdG9yXSBuYW1lcyBvbiB0aGUgcGlucyB3aGljaCBhcmUgYXNzb2NpYXRl
ZA0KICAgIGJ5IHRoZSBbRGlmZiBQaW5dIGtleXdvcmQgYXMgYSBkaWZmZXJlbnRpYWwgcGFpci4N
Cg0KM2QpIFRoZSBzcGVjaWZpY2F0aW9uIGRvZXNuJ3QgcHJvaGliaXQgdGhlIGNvbWJpbmF0aW9u
IG9mIGEgW01vZGVsXSBuYW1lDQogICAgd2l0aCBhIFtNb2RlbCBTZWxlY3Rvcl0gbmFtZSBvbiB0
aG9zZSBwaW5zIHdoaWNoIGFyZSBhc3NvY2lhdGVkIGFzIGENCiAgICBkaWZmZXJlbnRpYWwgcGFp
ciBieSB0aGUgW0RpZmYgUGluXSBrZXl3b3JkLg0KDQo0KSAgVGhlIGZvbGxvd2luZyBzdGF0ZW1l
bnQgaGFzIHNldmVyYWwgcHJvYmxlbXM6ICAiSWYgdmRpZmYgaXMgbm90IGRlZmluZWQNCiAgICBm
b3IgYSBwaW4gdGhhdCBpcyBkZWZpbmVkIGFzIHJlcXVpcmluZyBhIFZpbmggYnkgaXRzIFtNb2Rl
bF0gdHlwZSwgdmRpZmYNCiAgICBpcyBzZXQgdG8gdGhlIGRlZmF1bHQgdmFsdWUgb2YgMjAwIG1W
Ig0KDQo0YSkgVmlubCBpcyBub3QgbWVudGlvbmVkLCB5ZXQgVmluaCBhbmQgVmlubCBhcmUgdXN1
YWxseSBhbHdheXMgdXNlZCB0b2dldGhlci4NCg0KNGIpIFZpbmggYW5kIFZpbmwgYXJlIG5vdCBy
ZXF1aXJlZCBieSB0aGUgc3BlY2lmaWNhdGlvbiBldmVuIGZvciBidWZmZXJzDQogICAgd2hpY2gg
aGF2ZSByZWNlaXZlcnMgaW4gdGhlbS4gIERlZmF1bHQgdmFsdWVzIG9mIDAuOCBWIGFuZCAyLjAg
ViBhcmUNCiAgICBkZWZpbmVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgY2FzZSB3aGVu
IFZpbmggYW5kIFZpbmwgYXJlIG1pc3NpbmcNCiAgICBldmVuIGlmIHRoZXkgd291bGQgYmUgbmVl
ZGVkIGFjY29yZGluZyB0byB0aGUgbW9kZWwgdHlwZS4NCg0KNGMpIFRoZSBzdGF0ZW1lbnQgaW1w
bGllcyB0aGF0IHRoZSBwYXJzZXIgYW5kL29yIHNpbXVsYXRvcnMgYXJlIGV4cGVjdGVkIHRvDQog
ICAgbG9vayBpbnNpZGUgdGhlIFtNb2RlbF1zIHdoaWNoIGFyZSBiZWluZyBhc3NvY2lhdGVkIGFz
IGEgZGlmZmVyZW50aWFsDQogICAgcGFpciB0byBmaW5kIG91dCB3aGF0IHRoZSBtb2RlbCB0eXBl
IGlzIGluIG9yZGVyIHRvIGRlY2lkZSB3aGV0aGVyIHZkaWZmDQogICAgc2hvdWxkIGdldCBhIDIw
MCBtViBkZWZhdWx0IHZhbHVlIGluIGNhc2UgdGhlIGVudHJ5IGZvciBpdCBpcyAiTkEiLg0KICAg
IEdpdmVuIHByb2JsZW0gIzMgYWJvdmUsIHRoaXMgY2hlY2sgbWF5IHJldHVybiBlcnJvbmVvdXMg
b3IgY29uZmxpY3RpbmcNCiAgICByZXN1bHRzIGlmIHRoZSBtb2RlbCB0eXBlcyBvZiB0aGUgdHdv
IFtNb2RlbF1zIGFyZSBub3QgdGhlIHNhbWUuDQoNCjRkKSBUaGUgc3BlY2lmaWNhdGlvbiBkb2Vz
bid0IG1lbnRpb24gd2hldGhlciB0aGUgdmFsdWVzIG9mIHRoZSBbRGlmZiBQaW5dDQogICAgcGFy
YW1ldGVycyAoIk5BIiBvciBudW1iZXIpIGhhdmUgYW4gaW1wbGllZCBpbmRpY2F0aW9uIGZvciB0
aGUgbW9kZWwNCiAgICB0eXBlLCBhbmQgd2hldGhlciB0aGlzIG1lYW5pbmcgaGFzIHRvIGNvcnJl
c3BvbmQgdG8gdGhlIG1vZGVsIHR5cGUgb2YNCiAgICB0aGUgW01vZGVsXXMgcmVmZXJlbmNlZCB0
aHJvdWdoIHRoZSBbUGluXSBsaXN0Lg0KDQo1KSAgTm8gbWVhbmluZ2Z1bCBlcnJvciBjaGVja2lu
ZyBjYW4gYmUgZG9uZSBvbiB0aGUgZW50cmllcyBvZiBbRGlmZiBQaW5dLg0KICAgIFRoaXMgaXMg
ZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIHNwZWNpZmljYXRpb24gZGVmaW5lcyBkZWZhdWx0IHZh
bHVlcw0KICAgIGZvciB2ZGlmZiBhbmQgdGhlIHRpbWUgZGVsYXkgcGFyYW1ldGVycyBpbiBjYXNl
IHRoZXkgY29udGFpbiAiTkEiLiAgQXMNCiAgICBhIHJlc3VsdCwgbm8gbWF0dGVyIHdoYXQgdmFs
dWVzIGFyZSBwcmVzZW50IGluIHRoZSBbRGlmZiBQaW5dIHBhcmFtZXRlcg0KICAgIGxpc3QsIHRo
ZSBtb2RlbCB0eXBlIGluIHRoZSBbTW9kZWxdcyBhcmUgdGhlIGRldGVybWluaW5nIGZhY3RvciBm
b3IgaG93DQogICAgYSBkaWZmZXJlbnRpYWwgcGFpciBpcyBzaW11bGF0ZWQuICBGb3Igb25lLCBi
YXNlZCBvbiBpdGVtICMzIGFib3ZlLCB0aGlzDQogICAgY2FuIGJlIGVycm9uZW91cywgYnV0IGl0
IG1heSBhbHNvIGNvbmZsaWN0IHdpdGggdGhlIGludGVudGlvbnMgaW1wbGllZA0KICAgIGJ5IHRo
ZSBjaG9pc2Ugb2YgcGFyYW1ldGVycyB1c2VkIHdpdGggdGhlIFtEaWZmIFBpbl0ga2V5d29yZC4N
Cg0KICAgIFRoZXNlIGRlZmF1bHQgdmFsdWUgYXNzdW1wdGlvbnMgYWxsb3cgYSBzaW11bGF0b3Ig
dG8gY29tcGxldGUgdGhlDQogICAgc2ltdWxhdGlvbnMgc3VjY2Vzc2Z1bGx5IHdpdGhvdXQgYW55
IGVycm9ycyBvciB3YXJuaW5ncyBhbmQgcHJvZHVjZQ0KICAgIHNlZW1pbmdseSBjb3JyZWN0IHJl
c3VsdHMgd2l0aG91dCBjaGVja2luZyBmb3IgYW55IHBvdGVudGlhbCBtaXN0YWtlcw0KICAgIGlu
IHRoZSBJQklTIGZpbGUuICBXaGlsZSB0aGlzIG1heSBiZSBkZXNpcmFibGUgZnJvbSB0aGUgcGVy
c3BlY3RpdmUNCiAgICB0aGF0IHNpbWxhdGlvbnMgd2lsbCBiZSBhbHdheXMgc3VjY2Vzc2Z1bCwg
aXQgaXMgdW5kZXNpcmFibGUgYmVjYXVzZQ0KICAgIHNlcmlvdXMgbWlzdGFrZXMgY2FuIGdvIHVu
ZGV0ZWN0ZWQuDQoNCjYpICBUaGUgYXNzaWdubWVudCBvZiBkZWZhdWx0IHZhbHVlcyB0byB2ZGlm
ZiBhbmQgdGhlIHRpbWUgZGVsYXkgcGFyYW1ldGVycw0KICAgIHdoZW4gdGhlaXIgZW50cnkgaXMg
Ik5BIiBjb25mbGljdHMgd2l0aCB0aGUgbWVhbmluZyBvZiAiTkEiIGluIHRoZQ0KICAgIFtEcml2
ZXIgU2NoZWR1bGVdIGtleXdvcmQsIHdoZXJlIGl0IGhhcyBhIG1lYW5pbmcgb2YgIk5vdCBBdmFp
bGFibGUiDQogICAgaS5lLiBkb2Vzbid0IGV4aXN0LiAgIk5BIiBzaG91bGQgaGF2ZSB0aGUgc2Ft
ZSBpbnRlcnByZXRhdGlvbiBpbiB0aGUNCiAgICBlbnRpcmUgc3BlY2lmaWNhdGlvbiwgcmVnYXJk
bGVzcyBvZiB3aGljaCBrZXl3b3JkIGl0IGlzIHVzZWQgZm9yLg0KDQogICAgQWRkaXRpb25hbGx5
LCBpZiB0aGUgbWVhbmluZyBvZiAiTkEiIHdhcyB0aGUgc2FtZSBmb3IgW0RpZmYgUGluXSAoaS5l
Lg0KICAgICJub3QgYXZhaWxhYmxlIiksIHRoZSBwYXJzZXIgYW5kIHNpbXVsYXRvcnMgY291bGQg
dXNlIHRoZXNlIHBhcmFtZXRlcnMNCiAgICBmb3IgZGV0ZXJtaW5pbmcgd2hldGhlciB0aGUgZGlm
ZmVyZW50aWFsIHBhaXIgaXMgYSByZWNlaXZlciwgZHJpdmVyLCBvcg0KICAgIEkvTyB0eXBlLiAg
SWYgdGhlIHJlc3VsdCBvZiB0aGlzIGNoZWNrIGlzIGluIGNvbmZsaWN0IHdpdGggdGhlIG1vZGVs
IHR5cGUNCiAgICBmb3VuZCBpbiB0aGUgW01vZGVsXXMsIHdhcm5pbmcgb3IgZXJyb3IgbWVzc2Fn
ZXMgY291bGQgYmUgZ2VuZXJhdGVkLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KU1RBVEVN
RU5UIE9GIFRIRSBSRVNPTFZFRCBTUEVDSUZJQ0FUSU9OUzoNCg0KT3JpZ2luYWwgW0RpZmYgUGlu
XSBzZWN0aW9uOg0KDQp8PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnwgICAgIEtleXdvcmQ6ICBbRGlm
ZiBQaW5dDQp8ICAgIFJlcXVpcmVkOiAgTm8NCnwgRGVzY3JpcHRpb246ICBBc3NvY2lhdGVzIGRp
ZmZlcmVudGlhbCBwaW5zLCB0aGVpciBkaWZmZXJlbnRpYWwgdGhyZXNob2xkDQp8ICAgICAgICAg
ICAgICAgdm9sdGFnZXMsIGFuZCBkaWZmZXJlbnRpYWwgdGltaW5nIGRlbGF5cy4NCnwgIFN1Yi1Q
YXJhbXM6ICBpbnZfcGluLCB2ZGlmZiwgdGRlbGF5X3R5cCwgdGRlbGF5X21pbiwgdGRlbGF5X21h
eA0KfCBVc2FnZSBSdWxlczogIEVudGVyIG9ubHkgZGlmZmVyZW50aWFsIHBpbiBwYWlycy4gIFRo
ZSBmaXJzdCBjb2x1bW4sIFtEaWZmDQp8ICAgICAgICAgICAgICAgUGluXSwgY29udGFpbnMgYSBu
b24taW52ZXJ0aW5nIHBpbiBuYW1lLiAgVGhlIHNlY29uZCBjb2x1bW4sDQp8ICAgICAgICAgICAg
ICAgaW52X3BpbiwgY29udGFpbnMgdGhlIGNvcnJlc3BvbmRpbmcgaW52ZXJ0aW5nIHBpbiBuYW1l
IGZvcg0KfCAgICAgICAgICAgICAgIEkvTyBvdXRwdXQuICBFYWNoIHBpbiBuYW1lIG11c3QgbWF0
Y2ggdGhlIHBpbiBuYW1lcyBkZWNsYXJlZA0KfCAgICAgICAgICAgICAgIHByZXZpb3VzbHkgaW4g
dGhlIFtQaW5dIHNlY3Rpb24gb2YgdGhlIElCSVMgZmlsZS4gIFRoZSB0aGlyZA0KfCAgICAgICAg
ICAgICAgIGNvbHVtbiwgdmRpZmYsIGNvbnRhaW5zIHRoZSBzcGVjaWZpZWQgb3V0cHV0IGFuZCBk
aWZmZXJlbnRpYWwNCnwgICAgICAgICAgICAgICB0aHJlc2hvbGQgdm9sdGFnZSBiZXR3ZWVuIHBp
bnMgaWYgdGhlIHBpbnMgYXJlIElucHV0IG9yIEkvTw0KfCAgICAgICAgICAgICAgIG1vZGVsIHR5
cGVzLiAgRm9yIG91dHB1dCBvbmx5IGRpZmZlcmVudGlhbCBwaW5zLCB0aGUgdmRpZmYNCnwgICAg
ICAgICAgICAgICBlbnRyeSBpcyAwIFYuICBUaGUgZm91cnRoLCBmaWZ0aCwgYW5kIHNpeHRoIGNv
bHVtbnMsDQp8ICAgICAgICAgICAgICAgdGRlbGF5X3R5cCwgdGRlbGF5X21pbiwgYW5kIHRkZWxh
eV9tYXgsIGNvbnRhaW4gbGF1bmNoIGRlbGF5cw0KfCAgICAgICAgICAgICAgIG9mIHRoZSBub24t
aW52ZXJ0aW5nIHBpbnMgcmVsYXRpdmUgdG8gdGhlIGludmVydGluZyBwaW5zLiBUaGUNCnwgICAg
ICAgICAgICAgICB2YWx1ZXMgY2FuIGJlIG9mIGVpdGhlciBwb2xhcml0eS4NCnwNCnwgICAgICAg
ICAgICAgICBJZiBhIHBpbiBpcyBhIGRpZmZlcmVudGlhbCBpbnB1dCBwaW4sIHRoZSBkaWZmZXJl
bnRpYWwgaW5wdXQNCnwgICAgICAgICAgICAgICB0aHJlc2hvbGQgKHZkaWZmKSBvdmVycmlkZXMg
YW5kIHN1cGVyc2VkZXMgdGhlIG5lZWQgZm9yIFZpbmgNCnwgICAgICAgICAgICAgICBhbmQgVmlu
bC4NCnwNCnwgICAgICAgICAgICAgICBJZiB2ZGlmZiBpcyBub3QgZGVmaW5lZCBmb3IgYSBwaW4g
dGhhdCBpcyBkZWZpbmVkIGFzIHJlcXVpcmluZw0KfCAgICAgICAgICAgICAgIGEgVmluaCBieSBp
dHMgW01vZGVsXSB0eXBlLCB2ZGlmZiBpcyBzZXQgdG8gdGhlIGRlZmF1bHQgdmFsdWUNCnwgICAg
ICAgICAgICAgICBvZiAyMDAgbVYuDQp8DQp8IE90aGVyIE5vdGVzOiAgVGhlIG91dHB1dCBwaW4g
cG9sYXJpdHkgc3BlY2lmaWNhdGlvbiBpbiB0aGUgdGFibGUgb3ZlcnJpZGVzDQp8ICAgICAgICAg
ICAgICAgdGhlIFtNb2RlbF0gUG9sYXJpdHkgc3BlY2lmaWNhdGlvbiBzdWNoIHRoYXQgdGhlIHBp
biBpbiB0aGUNCnwgICAgICAgICAgICAgICBbRGlmZiBQaW5dIGNvbHVtbiBpcyBOb24tSW52ZXJ0
aW5nIGFuZCB0aGUgcGluIGluIHRoZSBpbnZfcGluDQp8ICAgICAgICAgICAgICAgY29sdW1uIGlz
IEludmVydGluZy4gIFRoaXMgY29udmVudGlvbiBlbmFibGVzIG9uZSAgW01vZGVsXSB0bw0KfCAg
ICAgICAgICAgICAgIGJlIHVzZWQgZm9yIGJvdGggcGlucy4NCnwNCnwgICAgICAgICAgICAgICBU
aGUgY29sdW1uIGxlbmd0aCBsaW1pdHMgYXJlOg0KfCAgICAgICAgICAgICAgICAgICBbRGlmZiBQ
aW5dICAgICA1IGNoYXJhY3RlcnMgbWF4DQp8ICAgICAgICAgICAgICAgICAgIGludl9waW4gICAg
ICAgIDUgY2hhcmFjdGVycyBtYXgNCnwgICAgICAgICAgICAgICAgICAgdmRpZmYgICAgICAgICAg
OSBjaGFyYWN0ZXJzIG1heA0KfCAgICAgICAgICAgICAgICAgICB0ZGVsYXlfdHlwICAgICA5IGNo
YXJhY3RlcnMgbWF4DQp8ICAgICAgICAgICAgICAgICAgIHRkZWxheV9taW4gICAgIDkgY2hhcmFj
dGVycyBtYXgNCnwgICAgICAgICAgICAgICAgICAgdGRlbGF5X21heCAgICAgOSBjaGFyYWN0ZXJz
IG1heA0KfA0KfCAgICAgICAgICAgICAgIEVhY2ggbGluZSBtdXN0IGNvbnRhaW4gZWl0aGVyIGZv
dXIgb3Igc2l4IGNvbHVtbnMuICBJZiAiTkEiIGlzDQp8ICAgICAgICAgICAgICAgZW50ZXJlZCBp
biB0aGUgdmRpZmYsIHRkZWxheV90eXAsIG9yIHRkZWxheV9taW4gY29sdW1ucywgaXRzDQp8ICAg
ICAgICAgICAgICAgZW50cnkgaXMgaW50ZXJwcmV0ZWQgYXMgMCBWIG9yIDAgbnMuICBJZiAiTkEi
IGFwcGVhcnMgaW4gdGhlDQp8ICAgICAgICAgICAgICAgdGRlbGF5X21heCBjb2x1bW4sIGl0cyB2
YWx1ZSBpcyBpbnRlcnByZXRlZCBhcyB0aGUgdGRlbGF5X3R5cA0KfCAgICAgICAgICAgICAgIHZh
bHVlLiAgV2hlbiB1c2luZyBzaXggY29sdW1ucywgdGhlIGhlYWRlcnMgdGRlbGF5X21pbiBhbmQN
CnwgICAgICAgICAgICAgICB0ZGVsYXlfbWF4IG11c3QgYmUgbGlzdGVkLiAgRW50cmllcyBmb3Ig
dGhlIHRkZWxheV9taW4gY29sdW1uDQp8ICAgICAgICAgICAgICAgYXJlIGJhc2VkIG9uIG1pbmlt
dW0gbWFnbml0dWRlczsgYW5kIHRkZWxheV9tYXggY29sdW1uLA0KfCAgICAgICAgICAgICAgIG1h
eGltdW0gbWFnbml0dWRlcy4gIE9uZSBlbnRyeSBvZiB2ZGlmZiwgcmVnYXJkbGVzcyBvZiBpdHMN
CnwgICAgICAgICAgICAgICBwb2xhcml0eSwgaXMgdXNlZCBmb3IgZGlmZmVyZW5jZSBtYWduaXR1
ZGVzLg0KfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbRGlmZiBQaW5dICBpbnZfcGluICB2ZGlmZiAg
dGRlbGF5X3R5cCB0ZGVsYXlfbWluIHRkZWxheV9tYXgNCnwNCiAzICAgICAgICAgICA0ICAgICAg
IDE1MG1WICAgIC0xbnMgICAgICAgMG5zICAgICAgLTJucyAgfCBJbnB1dCBvciBJL08gcGFpcg0K
IDcgICAgICAgICAgIDggICAgICAgICAwViAgICAgIDFucyAgICAgICAgTkEgICAgICAgIE5BICB8
IE91dHB1dCogcGluIHBhaXINCiA5ICAgICAgICAgIDEwICAgICAgICAgTkEgICAgICAgTkEgICAg
ICAgIE5BICAgICAgICBOQSAgfCBPdXRwdXQqIHBpbiBwYWlyDQoxNiAgICAgICAgICAxNSAgICAg
ICAyMDBtViAgICAgMW5zICAgIHwgSW5wdXQgb3IgSS9PIHBpbiBwYWlyDQoyMCAgICAgICAgICAx
OSAgICAgICAgIDBWICAgICAgIE5BICAgIHwgT3V0cHV0KiBwaW4gcGFpciwgdGRlbGF5ID0gMA0K
MjIgICAgICAgICAgMjEgICAgICAgICBOQSAgICAgICBOQSAgICB8IE91dHB1dCosIHRkZWxheSA9
IDANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAqIENvdWxkIGJlIElu
cHV0IG9yIEkvTyB3aXRoIHZkaWZmID0gMA0KfA0KfD09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNClRo
ZSBwcm9wb3NlZCBjaGFuZ2VzIGFyZSBub3RlZCB3aXRoIGEgIioiIGNoYXJhY3RlciBhdCB0aGUg
YmVnaW5uaW5nIG9mIHRoZQ0KbGluZXMuICBUaGUgbnVtYmVycyBvbiB0aGUgbGVmdCBvZiB0aGUg
aW5kZW50ZWQgdGV4dCBpbmRpY2F0ZSB3aGljaCBpc3N1ZSB0aGUNCmNoYW5nZXMgYXJlIGFkZHJl
c3NpbmcuDQoNCnw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KfCAgICAgS2V5d29yZDogIFtEaWZmIFBp
bl0NCnwgICAgUmVxdWlyZWQ6ICBObw0KfCpEZXNjcmlwdGlvbjogIEFzc29jaWF0ZXMgZGlmZmVy
ZW50aWFsIHBpbnMgYW5kIGRlZmluZXMgdGhlaXIgZGlmZmVyZW50aWFsDQp8KiAgICAgICAgICAg
ICAgcmVjZWl2ZXIgdGhyZXNob2xkIHZvbHRhZ2UgYW5kIGRpZmZlcmVudGlhbCBkcml2ZXIgdGlt
aW5nDQp8KiAgICAgICAgICAgICAgZGVsYXlzLg0KfCAgU3ViLVBhcmFtczogIGludl9waW4sIHZk
aWZmLCB0ZGVsYXlfdHlwLCB0ZGVsYXlfbWluLCB0ZGVsYXlfbWF4DQp8IFVzYWdlIFJ1bGVzOiAg
RW50ZXIgb25seSBkaWZmZXJlbnRpYWwgcGluIHBhaXJzLiAgVGhlIGZpcnN0IGNvbHVtbiwgW0Rp
ZmYNCnwgICAgICAgICAgICAgICBQaW5dLCBjb250YWlucyBhIG5vbi1pbnZlcnRpbmcgcGluIG5h
bWUuICBUaGUgc2Vjb25kIGNvbHVtbiwNCnwgICAgICAgICAgICAgICBpbnZfcGluLCBjb250YWlu
cyB0aGUgY29ycmVzcG9uZGluZyBpbnZlcnRpbmcgcGluIG5hbWUgZm9yDQp8ICAgICAgICAgICAg
ICAgSS9PIG91dHB1dC4gIEVhY2ggcGluIG5hbWUgbXVzdCBtYXRjaCB0aGUgcGluIG5hbWVzIGRl
Y2xhcmVkDQp8KiAzYSAtIDNkICAgICAgcHJldmlvdXNseSBpbiB0aGUgW1Bpbl0gc2VjdGlvbiBv
ZiB0aGUgSUJJUyBmaWxlLiAgVGhlIG1vZGVsDQp8KiAzYSAtIDNkICAgICAgbmFtZXMgb3IgW01v
ZGVsIFNlbGVjdG9yXSBuYW1lcyByZWZlcmVuY2VkIGJ5IHRoZSBwaW5zIGxpc3RlZA0KfCogM2Eg
LSAzZCAgICAgIGluIGFuIGVudHJ5IG9mIHRoZSBbRGlmZiBQaW5dIE1VU1QgYmUgdGhlIHNhbWUu
ICBUaGUgdGhpcmQNCnwqIDEgICAgICAgICAgICBjb2x1bW4sIHZkaWZmLCBjb250YWlucyB0aGUg
c3BlY2lmaWVkIGRpZmZlcmVudGlhbCByZWNlaXZlcg0KfCogMSAgICAgICAgICAgIHRocmVzaG9s
ZCB2b2x0YWdlIGJldHdlZW4gdGhlIGludmVydGluZyBhbmQgbm9uLWludmVydGluZw0KfCogMSAg
ICAgICAgICAgIGlucHV0cyBpZiB0aGUgZGlmZmVyZW50aWFsIHBhaXIgaXMgb3IgaGFzIGEgcmVj
ZWl2ZXIgKG1vZGVsDQp8KiAxICAgICAgICAgICAgdHlwZXMgSW5wdXQsIEkvTywgZXRjLikuICBG
b3IgZGlmZmVyZW50aWFsIHBhaXJzIHdoaWNoIGRvDQp8KiA0ZCwgNSwgNiAgICAgbm90IGhhdmUg
YSByZWNlaXZlciAobW9kZWwgdHlwZXMgT3V0cHV0LCBPcGVuX2RyYWluLCBldGMuKSwNCnwqIDRk
LCA1LCA2ICAgICB0aGUgdmRpZmYgZW50cnkgbXVzdCBiZSAiTkEiLCBvdGhlcndpc2UgaXQgbXVz
dCBjb250YWluIGEgDQp8KiA0ZCwgNSwgNiAgICAgbnVtZXJpY2FsIHZhbHVlLg0KfCoNCnwqIDJi
ICAgICAgICAgICBJZiB2ZGlmZiBjb250YWlucyBhIG51bWVyaWNhbCBlbnRyeSwgaXQgb3ZlcnJp
ZGVzIGFuZA0KfCogMmIgICAgICAgICAgIHN1cGVyc2VkZXMgdGhlIG5lZWQgZm9yIFZpbmggYW5k
IFZpbmwgaW4gdGhlIGNvcnJlc3BvbmRpbmcNCnwqIDJiICAgICAgICAgICBbTW9kZWxdcy4NCnwq
DQp8KiAyYSAgICAgICAgICAgKHJlbW92ZWQgcGFyYWdyYXBoKQ0KfCoNCnwqICAgICAgICAgICAg
ICBUaGUgZm91cnRoLCBmaWZ0aCwgYW5kIHNpeHRoIGNvbHVtbnMsIHRkZWxheV90eXAsIHRkZWxh
eV9taW4sDQp8KiAgICAgICAgICAgICAgYW5kIHRkZWxheV9tYXgsIGNvbnRhaW4gbGF1bmNoIGRl
bGF5cyBvZiB0aGUgbm9uLWludmVydGluZw0KfCogICAgICAgICAgICAgIHBpbnMgcmVsYXRpdmUg
dG8gdGhlIGludmVydGluZyBwaW5zIGlmIHRoZSBkaWZmZXJlbnRpYWwgcGFpcg0KfCogICAgICAg
ICAgICAgIGlzIG9yIGhhcyBhIGRyaXZlciAobW9kZWwgdHlwZXMgT3VwdXQsIEkvTywgZXRjLiku
ICBGb3INCnwqICAgICAgICAgICAgICB0aGVzZSBtb2RlbCB0eXBlcywgYXQgbGVhc3QgdGhlIHRk
ZWxheV90eXAgcGFyYW1ldGVyIG11c3QNCnwqIDRkLCA1LCA2ICAgICBjb250YWluIGEgbnVtZXJp
Y2FsIHZhbHVlLiAgRm9yIGRpZmZlcmVudGlhbCBwYWlycyB3aGljaCBkbw0KfCogNGQsIDUsIDYg
ICAgIG5vdCBoYXZlIGEgZHJpdmVyIChtb2RlbCB0eXBlcyBJbnB1dCwgSW5wdXRfRUNMKSwgdGhl
DQp8KiA0ZCwgNSwgNiAgICAgdGRlbGF5X3R5cCwgdGRlbGF5X21pbiwgYW5kIHRkZWxheV9tYXgg
ZW50cmllcyBtdXN0IGJlICJOQSIuDQp8Kg0KfCogICAgICAgICAgICAgIEFsbCBvZiB0aGUgbnVt
ZXJpY2FsIGVudHJpZXMgbWF5IGJlIGEgcG9zaXRpdmUsIHplcm8sIG9yDQp8KiAgICAgICAgICAg
ICAgbmVnYXRpdmUgbnVtYmVyLg0KfA0KfCBPdGhlciBOb3RlczogIFRoZSBvdXRwdXQgcGluIHBv
bGFyaXR5IHNwZWNpZmljYXRpb24gaW4gdGhlIHRhYmxlIG92ZXJyaWRlcw0KfCAgICAgICAgICAg
ICAgIHRoZSBbTW9kZWxdIFBvbGFyaXR5IHNwZWNpZmljYXRpb24gc3VjaCB0aGF0IHRoZSBwaW4g
aW4gdGhlDQp8ICAgICAgICAgICAgICAgW0RpZmYgUGluXSBjb2x1bW4gaXMgTm9uLUludmVydGlu
ZyBhbmQgdGhlIHBpbiBpbiB0aGUgaW52X3Bpbg0KfCAgICAgICAgICAgICAgIGNvbHVtbiBpcyBJ
bnZlcnRpbmcuICBUaGlzIGNvbnZlbnRpb24gZW5hYmxlcyBvbmUgIFtNb2RlbF0gdG8NCnwgICAg
ICAgICAgICAgICBiZSB1c2VkIGZvciBib3RoIHBpbnMuDQp8DQp8ICAgICAgICAgICAgICAgVGhl
IGNvbHVtbiBsZW5ndGggbGltaXRzIGFyZToNCnwgICAgICAgICAgICAgICAgICAgW0RpZmYgUGlu
XSAgICAgNSBjaGFyYWN0ZXJzIG1heA0KfCAgICAgICAgICAgICAgICAgICBpbnZfcGluICAgICAg
ICA1IGNoYXJhY3RlcnMgbWF4DQp8ICAgICAgICAgICAgICAgICAgIHZkaWZmICAgICAgICAgIDkg
Y2hhcmFjdGVycyBtYXgNCnwgICAgICAgICAgICAgICAgICAgdGRlbGF5X3R5cCAgICAgOSBjaGFy
YWN0ZXJzIG1heA0KfCAgICAgICAgICAgICAgICAgICB0ZGVsYXlfbWluICAgICA5IGNoYXJhY3Rl
cnMgbWF4DQp8ICAgICAgICAgICAgICAgICAgIHRkZWxheV9tYXggICAgIDkgY2hhcmFjdGVycyBt
YXgNCnwNCnwgICAgICAgICAgICAgICBFYWNoIGxpbmUgbXVzdCBjb250YWluIGVpdGhlciBmb3Vy
IG9yIHNpeCBjb2x1bW5zLiAgSWYgb25seQ0KfCogNGQsIDUsIDYgICAgIGZvdXIgY29sdW1ucyBh
cmUgcHJlc2VudCwgb3IgIk5BIiBpcyBlbnRlcmVkIGluIHRoZQ0KfCogNGQsIDUsIDYgICAgIHRk
ZWxheV9taW4gb3IgdGRlbGF5X21heCBjb2x1bW5zLCB0aGVpciBlbnRyeSBpcyBpbnRlcnByZXRl
ZA0KfCogNGQsIDUsIDYgICAgIGFzIHRoZSB0ZGVsYXlfdHlwIHZhbHVlLg0KfCAgICAgICAgICAg
ICAgIFdoZW4gdXNpbmcgc2l4IGNvbHVtbnMsIHRoZSBoZWFkZXJzIHRkZWxheV9taW4gYW5kDQp8
ICAgICAgICAgICAgICAgdGRlbGF5X21heCBtdXN0IGJlIGxpc3RlZC4gIEVudHJpZXMgZm9yIHRo
ZSB0ZGVsYXlfbWluIGNvbHVtbg0KfCAgICAgICAgICAgICAgIGFyZSBiYXNlZCBvbiBtaW5pbXVt
IG1hZ25pdHVkZXM7IGFuZCB0ZGVsYXlfbWF4IGNvbHVtbiwNCnwgICAgICAgICAgICAgICBtYXhp
bXVtIG1hZ25pdHVkZXMuICBPbmUgZW50cnkgb2YgdmRpZmYsIHJlZ2FyZGxlc3Mgb2YgaXRzDQp8
ICAgICAgICAgICAgICAgcG9sYXJpdHksIGlzIHVzZWQgZm9yIGRpZmZlcmVuY2UgbWFnbml0dWRl
cy4NCnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW0RpZmYgUGluXSBpbnZfcGluIHZkaWZmIHRkZWxh
eV90eXAgdGRlbGF5X21pbiB0ZGVsYXlfbWF4DQp8DQoqIDMgICAgICAgICA0ICAgICAgMTUwbVYg
LTFucyAgICAgICAwbnMgICAgICAgIC0ybnMgIHwgSS9PIHBhaXINCiogNSAgICAgICAgIDYgICAg
ICAgIDBWICAgMW5zICAgICAgICBOQSAgICAgICAgICBOQSAgfCBJL08gcGFpcg0KKiA4ICAgICAg
ICAgNyAgICAgICAgTkEgICAxbnMgICAgICAgIE5BICAgICAgICAgIE5BICB8IE91dHB1dCBwYWly
DQoqIDkgICAgICAgIDEwICAgICAgIDEwbVYgICBOQSAgICAgICAgTkEgICAgICAgICAgTkEgIHwg
SW5wdXQgcGFpcg0KKjEyICAgICAgICAxMSAgICAgICAgTkEgICAgTkEgICAgICAgIE5BICAgICAg
ICAgIE5BICB8IElsbGVnYWwgY29tYmluYXRpb24NCioxMyAgICAgICAgMTQgICAgICAgIE5BICAg
IE5BICAgICAgIDBucyAgICAgICAgLTJucyAgfCBJbGxlZ2FsIGNvbWJpbmF0aW9uDQoNCioxNiAg
ICAgICAgMTUgICAgICAyMDBtViAgMW5zICAgIHwgSS9PIHBhaXINCioxNyAgICAgICAgMTggICAg
ICAgIE5BICAgMW5zICAgIHwgT3V0cHV0IHBhaXINCioyMCAgICAgICAgMTkgICAgICAgIDBWICAg
IE5BICAgIHwgSW5wdXQgcGFpcg0KKjIyICAgICAgICAyMSAgICAgICAgTkEgICAgTkEgICAgfCBJ
bGxlZ2FsIGNvbWJpbmF0aW9uDQp8DQp8PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQpJbiBhZGRp
dGlvbiwgdGhlIHNlbnRlbmNlIGJlbG93IEZpZyAxMCBpbiB0aGUgVXNhZ2UgUnVsZXMgc2VjdGlv
biBvZiB0aGUgDQpbRXh0ZXJuYWwgTW9kZWxdIGFuZCBbRW5kIEV4dGVybmFsIE1vZGVsXToNCg0K
fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uICBUaGUgbW9kZWxzIHJlZmVyZW5j
ZWQgYnkgZWFjaCBwaW4gbGlzdGVkDQp8ICAgICAgICAgICAgICAgdW5kZXIgW0RpZmYgUGluXSBN
VVNUIGJlIHRoZSBzYW1lLg0KDQpzaG91bGQgYmUgcmVwbGFjZWQgYnk6DQoNCnwqICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC4uLiAgVGhlIFtNb2RlbF0gbmFtZXMgb3IgW01vZGVsIFNl
bGVjdG9yXQ0KfCogICAgICAgICAgICAgIG5hbWVzIHJlZmVyZW5jZWQgYnkgdGhlIHBpbnMgbGlz
dGVkIGluIGFuIGVudHJ5IG9mIHRoZQ0KfCogICAgICAgICAgICAgIFtEaWZmIFBpbl0gTVVTVCBi
ZSB0aGUgc2FtZS4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCkFOQUxZU0lTIFBBVEgvREFU
QSBUSEFUIExFRCBUTyBTUEVDSUZJQ0FUSU9ODQoNClRoZSBhYm92ZSBwcm9wb3NhbCBpcyBhIHJl
c3VsdCBvZiBjYXJlZnVsIGNvbnNpZGVyYXRpb24gb2YgdGhlIHZhcmlvdXMgcnVsZXMNCmFuZCBy
ZWxhdGlvbnNoaXBzIGluIHRoZSBleGlzdGluZyBJQklTIHY0LjEgc3BlY2lmaWNhdGlvbi4gIE1v
c3Qgb2YgdGhlDQpjaGFuZ2VzIGFyZSBhYm91dCBjYXJlZnVsIHNlbGVjdGlvbiBvZiB3b3JkcyB0
byBhdm9pZCBhbnkgYW1iaWd1aXRpZXMgYW5kL29yDQpjb250cmFkaWN0aW9ucy4NCg0KVGhlIHJl
cXVpcmVtZW50IGZvciBtYXRjaGluZyB0aGUgW01vZGVsXSBvciBbTW9kZWwgU2VsZWN0b3JdIG5h
bWVzIGluIHRoZQ0KcHJvcG9zZWQgdGV4dCBhYm92ZSBpcyBhcmd1YWJsZSBiZWNhdXNlIGEgbGVz
cyBzdHJpY3QgcnVsZSBvZiBoYXZpbmcgdG8gbWF0Y2gNCnRoZSBtb2RlbCB0eXBlIG9ubHkgd291
bGQgYWNoaWV2ZSBzaW1pbGFyIHJlc3VsdHMuICBIb3dldmVyLCBpZiBvbmx5IHRoZQ0KbW9kZWwg
dHlwZSB3b3VsZCBiZSByZXF1aXJlZCB0byBtYXRjaCwgdGhlIHBhcnNlciBvciBzaW11bGF0b3Ig
d291bGQgaGF2ZSB0bw0KbG9vayBpbnNpZGUgdGhlIFtNb2RlbF1zIHRvIGZpbmQgb3V0IHRoZWly
IG1vZGVsIHR5cGVzIGlzIGluIG9yZGVyIHRvIGlzc3VlDQphbnkgZXJyb3Igb3Igd2FybmluZyBt
ZXNzYWdlcy4gIEZ1cnRoZXIsIHRoaXMgbGVzcyBzdHJpY3QgcnVsZSB3b3VsZCBhbHNvDQphbGxv
dyB0d28gZGlmZmVyZW50IFtNb2RlbCBTZWxlY3Rvcl0gbmFtZXMgb24gZGlmZmVyZW50aWFsIHBp
biBwYWlycywgd2hpY2gNCndvdWxkIGNyZWF0ZSBmdXJ0aGVyIGNvbXBsaWNhdGlvbnMgaW4gdGhl
IHNpbXVsYXRvcidzIFtNb2RlbCBTZWxlY3Rvcl0gR1VJDQphbmQgdGhlIHJlbGF0ZWQgYWxnb3Jp
dGhtcyB3aGljaCB3b3VsZCBjaGVjayB3aGV0aGVyIHRoZSB1c2VyIHNlbGVjdGVkDQpjb21wYXRp
YmxlIG1vZGVsIHR5cGVzLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIHByb3Bvc2VkIHJ1bGUg
b2YgaGF2aW5nIHRvIG1hdGNoIHRoZSBbTW9kZWxdIG9yIA0KW01vZGVsIFNlbGVjdG9yXSBuYW1l
cyBleGNsdWRlcyB0aGUgcG9zc2liaWxpdHkgb2YgYXNzb2NpYXRpbmcgdHdvIHNsaWdodGx5DQpk
aWZmZXJlbnQgW01vZGVsXXMgKG9mIHRoZSBzYW1lIG1vZGVsIHR5cGUpIGZvciB0aGUgcHVycG9z
ZSBvZiBkZXNjcmliaW5nDQphc3N5bW1ldHJpYyBidWZmZXIgYmVoYXZpb3JzLiAgVGhpcyBjb21w
cm9taXplLCBob3dldmVyLCBjYW4gYmUgb3ZlcmNvbWUgYnkNCnVzaW5nIHRoZSBWZXJpbG9nLUFN
UyBvciBWSERMLUFNUyBsYW5ndWFnZSBleHRlbnNpb25zIGZvciBtb2RlbGluZyBzdWNoDQpidWZm
ZXIgYmVoYXZpb3JzLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpBTlkgT1RIRVIgQkFDS0dS
T1VORCBJTkZPUk1BVElPTjoNCg0KTm9uZS4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo=

- ------_=_NextPart_001_01C4E3CF.F2C24381--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Sun, 19 Dec 2004 11:37:09 +0530
From: Akhilesh CHANDRA <akhilesh.chandra@st.com>
Subject: Re: [IBIS-Users] way to extract rising and falling waveform in differential cells

- --------------000205080407090801000002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Fred,

  I want to know how we can simlate rising and falling waveform database 
for a cell that have swing between 0.51v to 1.27V. The supply use are 0V 
to2.5V. During  the extraction I put resistence to 1.76 and 0.51V insted 
of 2.5V to 0V(in typ case). Again my models are good at lower 
frequency(15MHZ) but become worst at high frequency(622Mhz).

  Is any one give ibis models of such type of cells with rising and 
falling database. Is any extra precaution is required to make model for 
a cell that is working till 1GHZ.
 If anyone can send me such type of models it help me.
Regards
Akhilesh
Fred Balistreri wrote:

>Are you asking about the test circuit or a software program that does this?
>
>Best Regards,
>Fred
>----- Original Message ----- 
>From: "Akhilesh CHANDRA" <akhilesh.chandra@st.com>
>To: <ibis-users@eda.org>
>Cc: "Akhilesh CHANDRA" <akhilesh.chandra@st.com>
>Sent: Tuesday, December 14, 2004 5:47 AM
>Subject: [IBIS-Users] way to extract rising and falling waveform in
>differential cells
>
>
>  
>
>>Hello Friends,
>>
>>   I am devloping IBIS model of a differential cell having swing 300mv.
>>when I run simulation at 300mhz then I find out there is a transition
>>shift between IBIS and spice result. In my model I give just ramp
>>database dv/dt for transition. In my view this problem may be resolve if
>>I give complete rising and falling waveform in my models.
>>  Is anyone know how we can extract rising and falling waveform for a
>>cell that have differential swing or any other way to reduce this shift.
>>
>>  My results are attached with the mail.
>>
>>regards
>>Akhilesh
>>
>>
>>
>>    
>>
>
>
>----------------------------------------------------------------------------
>----
>
>
>
>
>
>
>  
>


- --------------000205080407090801000002
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Hello Fred,<br>
<br>
&nbsp; I want to know how we can simlate rising and falling waveform database
for a cell that have swing between 0.51v to 1.27V. The supply use are 0V
to2.5V. During &nbsp;the extraction I put resistence to 1.76 and 0.51V insted
of 2.5V to 0V(in typ case). Again my models are good at lower frequency(15MHZ)
but become worst at high frequency(622Mhz).<br>
<br>
&nbsp; Is any one give ibis models of such type of cells with rising and falling
database. Is any extra precaution is required to make model for a cell that
is working till 1GHZ.<br>
&nbsp;If anyone can send me such type of models it help me.<br>
Regards<br>
Akhilesh<br>
Fred Balistreri wrote:<br>
<blockquote type="cite" cite="mid012a01c4e20b$19248d40$0201a8c0@BIGBOY">
  <pre wrap="">Are you asking about the test circuit or a software program that does this?

Best Regards,
Fred
- ----- Original Message ----- 
From: "Akhilesh CHANDRA" <a class="moz-txt-link-rfc2396E" href="mailto:akhilesh.chandra@st.com">&lt;akhilesh.chandra@st.com&gt;</a>
To: <a class="moz-txt-link-rfc2396E" href="mailto:ibis-users@eda.org">&lt;ibis-users@eda.org&gt;</a>
Cc: "Akhilesh CHANDRA" <a class="moz-txt-link-rfc2396E" href="mailto:akhilesh.chandra@st.com">&lt;akhilesh.chandra@st.com&gt;</a>
Sent: Tuesday, December 14, 2004 5:47 AM
Subject: [IBIS-Users] way to extract rising and falling waveform in
differential cells


  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello Friends,

   I am devloping IBIS model of a differential cell having swing 300mv.
when I run simulation at 300mhz then I find out there is a transition
shift between IBIS and spice result. In my model I give just ramp
database dv/dt for transition. In my view this problem may be resolve if
I give complete rising and falling waveform in my models.
  Is anyone know how we can extract rising and falling waveform for a
cell that have differential swing or any other way to reduce this shift.

  My results are attached with the mail.

regards
Akhilesh



    </pre>
  </blockquote>
  <pre wrap=""><!---->

- ----------------------------------------------------------------------------
- ----






  </pre>
</blockquote>
<br>
</body>
</html>

- --------------000205080407090801000002--

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Sun, 19 Dec 2004 09:21:44 -0500
From: "Andrew Ingraham" <a.ingraham@ieee.org>
Subject: Re: [IBIS-Users] way to extract rising and falling waveform in differential cells

This is a multi-part message in MIME format.

- ------=_NextPart_000_0105_01C4E5AC.284BAC00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Akhilesh,

In the example you gave earlier, the simulation was at 250 MHz (2 ns =
high and 2 ns low) and the waveform had just about reached the other =
state when it was being switched again.  Attempting to simulate this =
much faster (622 MHz or 1 GHz), with IBIS, is probably doomed to failure =
because of IBIS's limitations.  This is sometimes known as =
"over-clocking" the IBIS model, because the model hasn't reached the =
other state yet when it is being clocked again in the other direction.  =
Some simulators handle this situation very poorly, so you could see very =
poor IBIS vs. SPICE correlation at such faster frequencies.

Regards,
Andy


- ------=_NextPart_000_0105_01C4E5AC.284BAC00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Akhilesh,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>In the example you gave earlier, the simulation was =
at 250 MHz=20
(2 ns high and 2 ns low) and the waveform&nbsp;had just =
about&nbsp;reached the=20
other state when it was being switched again.&nbsp; Attempting to =
simulate this=20
much faster (622 MHz or 1 GHz), with IBIS, is probably doomed to failure =
because=20
of IBIS's limitations.&nbsp; </FONT><FONT size=3D2>This is sometimes =
known as=20
"over-clocking" the IBIS model, because the&nbsp;model hasn't reached =
the=20
other&nbsp;state yet when it is being clocked again in the other=20
direction.&nbsp; Some simulators handle this situation very poorly, so=20
you&nbsp;could see very poor IBIS vs. SPICE correlation at&nbsp;such=20
faster&nbsp;frequencies.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2>Andy</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

- ------=_NextPart_000_0105_01C4E5AC.284BAC00--

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Sun, 19 Dec 2004 21:09:35 +0530
From: Akhilesh CHANDRA <akhilesh.chandra@st.com>
Subject: Re: [IBIS-Users] way to extract rising and falling waveform in differential cells

- --------------010001010102090301000302
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Andy,

 That means we can't make IBIS model that work at 1ghz. I think we can 
make IBIS models at such high frequency. Now I put both rising and 
falling database in my model and it is parsed by golden parser without 
any problem but still result are not good at 622Mhz.
  Is this also problem from simulator. I am using eldo (AMS CADENCE)for 
validation.

Regards
Akhilesh

Andrew Ingraham wrote:

> Akhilesh,
>  
> In the example you gave earlier, the simulation was at 250 MHz (2 ns 
> high and 2 ns low) and the waveform had just about reached the other 
> state when it was being switched again.  Attempting to simulate this 
> much faster (622 MHz or 1 GHz), with IBIS, is probably doomed to 
> failure because of IBIS's limitations.  This is sometimes known as 
> "over-clocking" the IBIS model, because the model hasn't reached the 
> other state yet when it is being clocked again in the other 
> direction.  Some simulators handle this situation very poorly, so 
> you could see very poor IBIS vs. SPICE correlation at such 
> faster frequencies.
>  
> Regards,
> Andy
>  
>  



- --------------010001010102090301000302
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Hello Andy,<br>
<br>
&nbsp;That means we can't make IBIS model that work at 1ghz. I think we can make
IBIS models at such high frequency. Now I put both rising and falling database
in my model and it is parsed by golden parser without any problem but still
result are not good at 622Mhz.<br>
&nbsp; Is this also problem from simulator. I am using eldo (AMS CADENCE)for validation.<br>
<br>
Regards<br>
Akhilesh<br>
<br>
Andrew Ingraham wrote:<br>
<blockquote type="cite"
 cite="mid010801c4e5d6$118e0a60$0902a8c0@Ingraham">
  <title></title>
  
  <meta http-equiv="Content-Type" content="text/html; ">
 
  <meta content="MSHTML 6.00.2800.1476" name="GENERATOR">
 
  <style></style>  
  <div><font size="2">Akhilesh,</font></div>
 
  <div>&nbsp;</div>
 
  <div><font size="2">In the example you gave earlier, the simulation was
at 250 MHz  (2 ns high and 2 ns low) and the waveform&nbsp;had just about&nbsp;reached
the  other state when it was being switched again.&nbsp; Attempting to simulate
this  much faster (622 MHz or 1 GHz), with IBIS, is probably doomed to failure
because  of IBIS's limitations.&nbsp; </font><font size="2">This is sometimes
known as  "over-clocking" the IBIS model, because the&nbsp;model hasn't reached
the  other&nbsp;state yet when it is being clocked again in the other  direction.&nbsp;
Some simulators handle this situation very poorly, so  you&nbsp;could see very
poor IBIS vs. SPICE correlation at&nbsp;such  faster&nbsp;frequencies.</font></div>
 
  <div>&nbsp;</div>
 
  <div><font size="2">Regards,</font></div>
 
  <div><font size="2">Andy</font></div>
 
  <div>&nbsp;</div>
 
  <div>&nbsp;</div>
</blockquote>
<br>
</body>
</html>

- --------------010001010102090301000302--

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Sun, 19 Dec 2004 12:11:34 -0800
From: "lgreen" <lgreen22@mindspring.com>
Subject: RE: [IBIS-Users] way to extract rising and falling waveform in differential cells

This is a multi-part message in MIME format.

- ------=_NextPart_000_0038_01C4E5C3.E4EC95B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello, Akilesh,

 

One might build a separate model for each frequency.  However, as Andy
points out, a model built at one frequency will NOT correlate well between
SI simulators and SPICE.  Overclcoked models are handled differently by
different SI simulators, so the quality of comparison would depend on the
simulator.

 

The parser makes few checks on table data.  So models can pass the parser
even when the data is "bad" or incomplete.  You might want to use the IBIS
Quality Checklist, which contains additional checks (some of them
manual).http://www.sisoft.com/ibis-quality/

 

Best regards,

Lynne

 

 

"IBIS training when you need it, where you need it."

 

Dr. Lynne Green

Green Streak Programs

http://www.greenstreakprograms.com

425-788-0412

lgreen22@mindspring.com

 

 

  _____  

From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On Behalf
Of Akhilesh CHANDRA
Sent: Sunday, December 19, 2004 7:40 AM
To: Andrew Ingraham
Cc: ibis-users@eda.org; Akhilesh CHANDRA
Subject: Re: [IBIS-Users] way to extract rising and falling waveform in
differential cells

 

Hello Andy,

 That means we can't make IBIS model that work at 1ghz. I think we can make
IBIS models at such high frequency. Now I put both rising and falling
database in my model and it is parsed by golden parser without any problem
but still result are not good at 622Mhz.
  Is this also problem from simulator. I am using eldo (AMS CADENCE)for
validation.

Regards
Akhilesh

Andrew Ingraham wrote:



Akhilesh,

 

In the example you gave earlier, the simulation was at 250 MHz (2 ns high
and 2 ns low) and the waveform had just about reached the other state when
it was being switched again.  Attempting to simulate this much faster (622
MHz or 1 GHz), with IBIS, is probably doomed to failure because of IBIS's
limitations.  This is sometimes known as "over-clocking" the IBIS model,
because the model hasn't reached the other state yet when it is being
clocked again in the other direction.  Some simulators handle this situation
very poorly, so you could see very poor IBIS vs. SPICE correlation at such
faster frequencies.

 

Regards,

Andy

 

 

 


- ------=_NextPart_000_0038_01C4E5C3.E4EC95B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
- -->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hello, =
Akilesh,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One might build a separate model =
for each
frequency.&nbsp; However, as Andy points out, a model built at one =
frequency
will NOT correlate well between SI simulators and SPICE.&nbsp; =
Overclcoked
models are handled differently by different SI simulators, so the =
quality of
comparison would depend on the simulator.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The parser makes few checks on =
table data.&nbsp;
So models can pass the parser even when the data is &#8220;bad&#8221; or
incomplete.&nbsp; You might want to use the IBIS Quality Checklist, =
which
contains additional checks (some of them =
manual).http://www.sisoft.com/ibis-quality/<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Best =
regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Lynne<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&quot;IBIS training when you need it, where you need =
it.&quot;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Dr. Lynne Green<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Green Streak Programs<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>http://www.greenstreakprograms.com<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>425-788-0412<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>lgreen22@mindspring.com<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter =
style=3D'margin-left:.5in;text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Akhilesh CHANDRA<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Sunday, December =
19, 2004
7:40 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Andrew Ingraham<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> ibis-users@eda.org; =
Akhilesh
CHANDRA<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [IBIS-Users] =
way to
extract rising and falling waveform in differential =
cells</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>Hello Andy,<br>
<br>
&nbsp;That means we can't make IBIS model that work at 1ghz. I think we =
can
make IBIS models at such high frequency. Now I put both rising and =
falling
database in my model and it is parsed by golden parser without any =
problem but
still result are not good at 622Mhz.<br>
&nbsp; Is this also problem from simulator. I am using eldo (AMS =
CADENCE)for
validation.<br>
<br>
Regards<br>
Akhilesh<br>
<br>
Andrew Ingraham wrote:<br>
<br>
<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>Akhilesh,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>In the example you gave earlier, the =
simulation was at
250 MHz (2 ns high and 2 ns low) and the waveform&nbsp;had just
about&nbsp;reached the other state when it was being switched =
again.&nbsp;
Attempting to simulate this much faster (622 MHz or 1 GHz), with IBIS, =
is
probably doomed to failure because of IBIS's limitations.&nbsp; This is
sometimes known as &quot;over-clocking&quot; the IBIS model, because
the&nbsp;model hasn't reached the other&nbsp;state yet when it is being =
clocked
again in the other direction.&nbsp; Some simulators handle this =
situation very
poorly, so you&nbsp;could see very poor IBIS vs. SPICE correlation =
at&nbsp;such
faster&nbsp;frequencies.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>Regards,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt'>Andy</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

- ------=_NextPart_000_0038_01C4E5C3.E4EC95B0--


|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

------------------------------

Date: Sun, 19 Dec 2004 13:34:23 -0800
From: "Tom Dagostino" <tom@teraspeed.com>
Subject: RE: [IBIS-Users] way to extract rising and falling waveform in differential cells

This is a multi-part message in MIME format.

- ------=_NextPart_000_0089_01C4E5CF.73AA2D20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Are you terminating both sides of the differential driver when you extract
the VT waveforms?  Many times differential buffers will not operate properly
if they do not have the proper termination on both outputs.

Tom Dagostino
Teraspeed Consulting Group LLC
503-430-1065
tom@teraspeed.com
www.teraspeed.com

  -----Original Message-----
  From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org]On Behalf
Of Akhilesh CHANDRA
  Sent: Sunday, December 19, 2004 7:40 AM
  To: Andrew Ingraham
  Cc: ibis-users@eda.org; Akhilesh CHANDRA
  Subject: Re: [IBIS-Users] way to extract rising and falling waveform in
differential cells


  Hello Andy,

   That means we can't make IBIS model that work at 1ghz. I think we can
make IBIS models at such high frequency. Now I put both rising and falling
database in my model and it is parsed by golden parser without any problem
but still result are not good at 622Mhz.
    Is this also problem from simulator. I am using eldo (AMS CADENCE)for
validation.

  Regards
  Akhilesh

  Andrew Ingraham wrote:

    Akhilesh,

    In the example you gave earlier, the simulation was at 250 MHz (2 ns
high and 2 ns low) and the waveform had just about reached the other state
when it was being switched again.  Attempting to simulate this much faster
(622 MHz or 1 GHz), with IBIS, is probably doomed to failure because of
IBIS's limitations.  This is sometimes known as "over-clocking" the IBIS
model, because the model hasn't reached the other state yet when it is being
clocked again in the other direction.  Some simulators handle this situation
very poorly, so you could see very poor IBIS vs. SPICE correlation at such
faster frequencies.

    Regards,
    Andy




- ------=_NextPart_000_0089_01C4E5CF.73AA2D20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D874403021-19122004><FONT face=3DArial color=3D#0000ff =
size=3D2>Are=20
you terminating both sides of the differential driver when you extract =
the VT=20
waveforms?&nbsp; Many times differential buffers will not operate =
properly if=20
they do not have the proper termination on both =
outputs.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=3D2>Tom Dagostino<BR>Teraspeed Consulting Group=20
LLC<BR>503-430-1065<BR>tom@teraspeed.com<BR>www.teraspeed.com =
</FONT></P>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
owner-ibis-users@eda.org=20
  [mailto:owner-ibis-users@eda.org]<B>On Behalf Of </B>Akhilesh=20
  CHANDRA<BR><B>Sent:</B> Sunday, December 19, 2004 7:40 =
AM<BR><B>To:</B> Andrew=20
  Ingraham<BR><B>Cc:</B> ibis-users@eda.org; Akhilesh =
CHANDRA<BR><B>Subject:</B>=20
  Re: [IBIS-Users] way to extract rising and falling waveform in =
differential=20
  cells<BR><BR></FONT></DIV>Hello Andy,<BR><BR>&nbsp;That means we can't =
make=20
  IBIS model that work at 1ghz. I think we can make IBIS models at such =
high=20
  frequency. Now I put both rising and falling database in my model and =
it is=20
  parsed by golden parser without any problem but still result are not =
good at=20
  622Mhz.<BR>&nbsp; Is this also problem from simulator. I am using eldo =
(AMS=20
  CADENCE)for validation.<BR><BR>Regards<BR>Akhilesh<BR><BR>Andrew =
Ingraham=20
  wrote:<BR>
  <BLOCKQUOTE cite=3Dmid010801c4e5d6$118e0a60$0902a8c0@Ingraham =
type=3D"cite">
    <STYLE></STYLE>

    <DIV><FONT size=3D2>Akhilesh,</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT size=3D2>In the example you gave earlier, the simulation =
was at 250=20
    MHz (2 ns high and 2 ns low) and the waveform&nbsp;had just=20
    about&nbsp;reached the other state when it was being switched =
again.&nbsp;=20
    Attempting to simulate this much faster (622 MHz or 1 GHz), with =
IBIS, is=20
    probably doomed to failure because of IBIS's limitations.&nbsp; =
</FONT><FONT=20
    size=3D2>This is sometimes known as "over-clocking" the IBIS model, =
because=20
    the&nbsp;model hasn't reached the other&nbsp;state yet when it is =
being=20
    clocked again in the other direction.&nbsp; Some simulators handle =
this=20
    situation very poorly, so you&nbsp;could see very poor IBIS vs. =
SPICE=20
    correlation at&nbsp;such faster&nbsp;frequencies.</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT size=3D2>Regards,</FONT></DIV>
    <DIV><FONT size=3D2>Andy</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV>&nbsp;</DIV></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

- ------=_NextPart_000_0089_01C4E5CF.73AA2D20--


|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 21 Dec 2004 13:47:47 +0800
From: slwu <Shulong.Wu@synopsys.com>
Subject: Re: [IBIS-Users] Hspice ibischk4 tool

Hi All,

Does anybody know whether BUG82 is also fixed in ibischk4 Version 4.1.0beta
?

Thanks
slwu

Bob Ross wrote:

> Fabrizio:
>
> The difference between ibischk4 Version 4.0.1 and ibischk4 Version 4.0.1
> is BUG82.  BUG82 was serious enough to justify a special release of
> ibischk4.
>
>    http://eda.org/pub/ibis/bugs/ibischk/index.html
>
> A text list of what verion a bug fix has been implemented exists
> in the bugdir.txt file link at the end of this link.
>
> Bob
>
> Zanella, Fabrizio wrote:
>
> > The latest version of Synopsys Hspice, version 2004.09, uses the
> > ibischk4 tool, version 4.0.1.   In a simulation I ran yesterday, Hspice
> > reported errors running the v4.0.1 ibischk4 with the rising and falling
> > waveforms when using an IBIS model as a driver.
> >
> > Here?s a sample of the errors:
> >
> > ERROR - Model osoc2_od: The [Rising Waveform]
> >
> >       with [R_fixture]=60 Ohms and [V_fixture]=3.3V
> >
> >       has TYP column DC endpoints of  2.02V and  3.30v, but
> >
> >       an equivalent load applied to the model's I-V tables yields
> >
> >       different voltages ( 2.02V and  2.02V),
> >
> >       a difference of   inf% and   inf%, respectively.
> >
> > ERROR - Model osoc2_od: The [Falling Waveform]
> >
> >       with [R_fixture]=60 Ohms and [V_fixture]=3.3V
> >
> >       has TYP column DC endpoints of  2.02V and  3.30v, but
> >
> >       an equivalent load applied to the model's I-V tables yields
> >
> >       different voltages ( 2.02V and  2.02V),
> >
> >       a difference of   inf% and   inf%, respectively.
> >
> >
> >
> > An engineer at the device manufacturer said there are no errors when he
> > uses the ibischk4 v4.0.2 tool.  Can someone explain what the differences
> > are between versions 4.0.1 and 4.0.2 of the ibischk4 tool and does
> > anyone know whether Synopsys will be moving to the latest ibischk4 tool
> > in the Hspice simulator?
> >
> > Thanks and regards,
> >
> >
> >
> > Fabrizio Zanella
> >
> > Signal Integrity
> >
> > Enterasys Networks
> >
> > Andover, MA
> >
> > Phone:  978-684-1340
> >
> > fzanella@enterasys.com <mailto:fzanella@enterasys.com>
> >
> >
> >
>
> --
> Bob Ross
> Teraspeed Consulting Group LLC     Teraspeed Labs
> 121 North River Drive              13610 SW Harness Lane
> Narragansett, RI 02882             Beaverton, OR 97008
> 503-750-6481                       503-430-1065
> http://www.teraspeed.com           503-246-8048 Direct
> bob@teraspeed.com
>
> |------------------------------------------------------------------
> |For help or to subscribe/unsubscribe, email majordomo@eda.org
> |with just 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 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       <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 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, 20 Dec 2004 21:52:34 -0800
From: Bob Ross <bob@teraspeed.com>
Subject: Re: [IBIS-Users] Hspice ibischk4 tool

Hello Shulong:

Yes BUG82 should be fixed since Ver 4.0.2 served as the
baseline for Versio 4.1X developement underway.

Bob

slwu wrote:

> Hi All,
> 
> Does anybody know whether BUG82 is also fixed in ibischk4 Version 4.1.0beta
> ?
> 
> Thanks
> slwu
> 
> Bob Ross wrote:
> 
> 
>>Fabrizio:
>>
>>The difference between ibischk4 Version 4.0.1 and ibischk4 Version 4.0.1
>>is BUG82.  BUG82 was serious enough to justify a special release of
>>ibischk4.
>>
>>   http://eda.org/pub/ibis/bugs/ibischk/index.html
>>
>>A text list of what verion a bug fix has been implemented exists
>>in the bugdir.txt file link at the end of this link.
>>
>>Bob
>>
>>Zanella, Fabrizio wrote:
>>
>>
>>>The latest version of Synopsys Hspice, version 2004.09, uses the
>>>ibischk4 tool, version 4.0.1.   In a simulation I ran yesterday, Hspice
>>>reported errors running the v4.0.1 ibischk4 with the rising and falling
>>>waveforms when using an IBIS model as a driver.
>>>
>>>Here?s a sample of the errors:
>>>
>>>ERROR - Model osoc2_od: The [Rising Waveform]
>>>
>>>      with [R_fixture]=60 Ohms and [V_fixture]=3.3V
>>>
>>>      has TYP column DC endpoints of  2.02V and  3.30v, but
>>>
>>>      an equivalent load applied to the model's I-V tables yields
>>>
>>>      different voltages ( 2.02V and  2.02V),
>>>
>>>      a difference of   inf% and   inf%, respectively.
>>>
>>>ERROR - Model osoc2_od: The [Falling Waveform]
>>>
>>>      with [R_fixture]=60 Ohms and [V_fixture]=3.3V
>>>
>>>      has TYP column DC endpoints of  2.02V and  3.30v, but
>>>
>>>      an equivalent load applied to the model's I-V tables yields
>>>
>>>      different voltages ( 2.02V and  2.02V),
>>>
>>>      a difference of   inf% and   inf%, respectively.
>>>
>>>
>>>
>>>An engineer at the device manufacturer said there are no errors when he
>>>uses the ibischk4 v4.0.2 tool.  Can someone explain what the differences
>>>are between versions 4.0.1 and 4.0.2 of the ibischk4 tool and does
>>>anyone know whether Synopsys will be moving to the latest ibischk4 tool
>>>in the Hspice simulator?
>>>
>>>Thanks and regards,
>>>
>>>
>>>
>>>Fabrizio Zanella
>>>
>>>Signal Integrity
>>>
>>>Enterasys Networks
>>>
>>>Andover, MA
>>>
>>>Phone:  978-684-1340
>>>
>>>fzanella@enterasys.com <mailto:fzanella@enterasys.com>


- -- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
503-750-6481                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com


|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 24 Dec 2004 18:53:12 -0800
From: Bob Ross <bob@teraspeed.com>
Subject: [IBIS-Users] IIRD8.2 - Distinct Model_pinmap and Model_nodemap Names

This is a multi-part message in MIME format.
- --------------050704000901020401070700
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

To All:

IIRD8.2 containng some editorial revisions is attached to
be considered at the next IBIS Meeting.

Bob
- -- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
503-750-6481                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com

- --------------050704000901020401070700
Content-Type: text/plain;
 name="iird8.2.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="iird8.2.txt"

                ICM Issue Resolution Document  (IIRD)

IIRD ID#:        8.2
ISSUE TITLE:     Distinct Model_pinmap and Model_nodemap Names
REQUESTOR:       Bob Ross, Teraspeed Consulting Group
DATE SUBMITTED:  September 22, 2004
DATE REVISED:    November 21, 2004, December 24, 2004
DATE ACCEPTED BY IBIS OPEN FORUM: PENDING

****************************************************************************
****************************************************************************

STATEMENT OF THE ISSUE:

Model_pinmap and Model_nodemap names under [Tree Path Description] and
[Nodal Path Description] need to be distinct to allow interfacing with IBIS
or other types of connections.  If the names are reused, then a method
is needed for EDA tools to identify the specific name for connections.

****************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Statements are added that the Model_pinmap and Model_nodemap names must
either be distinct or else differentiated by a new subparameter "Side"
under [Tree Path Description] and [Nodal Path Description].

Change instruction lines are identified by |**
Changes are identified by |*, |***, |**** lines.
Some unchanged portions are omitted.


|** MODIFY THE TREE DIAGRAM IN THE PORTION BELOW


|--/--[Begin ICM Family]                  | (see Chapter 7)
|  |  |--[Manufacturer]
|  |  |--[ICM Family Description]
|  |  |--[ICM Model List] 
|  |  
|  |--/--[Begin ICM Model]
|  |  |  |  ICM_model_type
|  |  |  |  SGR
|  |  |  |  Ref_impedance
|  |  |  |--[ICM Model Description]
|  |  |  |--[Tree Path Description]
|  |  |  |     Model_pinmap

|** Add this line
|  |  |  |     Side
|** End of addition

|  |  |  |     Fork, Endfork
|  |  |  |     Section
|  |  |  |--[Nodal Path Description]
|  |  |  |     Model_nodemap

|** Add this line
|  |  |  |     Side
|** End of addition

|  |  |  |     N_section
|  |  |  |--[ICM Swath Parameters]        | (optional, for swaths)
|  |  |  |     Left_edge
|  |  |  |     Right_edge
|  |  |  |     Top_edge
|  |  |  |     Bottom_edge
|  |  |  |--[ICM Swath Pin Numbers]       | (optional, for swaths)
|  |  \--[End ICM Model]
|  |
|  |--[ICM Pin Map]                       | Pins to Physical
|  |    Pin_order
|  |    Num_of_columns
|  |    Num_of_rows
|  |    Pin_list
|  |--[ICM Node Map]                      | Nodes to Physical
|  \--[End ICM Family]
|


|** MAKE CHANGES TO THE [Tree Path Description] KEYWORD SHOWN BELOW:

=============================================================================
     Keyword: [Tree Path Description]
    Required: Yes, if [Nodal Path Description] does not exist

|** Delete this line
  Sub-params: Model_pinmap, Section, Fork, Endfork
|** Add this line
  Sub-params: Model_pinmap, Side, Section, Fork, Endfork
|** End of addition

     Used By: [Begin ICM Model]
        Uses: [ICM Pin Map]
 Description: This keyword describes the connection path between the pin or 
              pins on one side of the interconnect and the corresponding set
              of pins on the other side.  This pin to pin interconnect is
              divided into one or more "sections", where each section consists 
              of RLGC data.  Sections are generally cascaded in series, but   
              the Fork and Endfork subparameters allow sections to branch off 
              the main interconnect path as a stub or tee.
Usage Rules:  A [Tree Path Description] is used when all of the sections in a
              given interconnect have one-to-one mapping.  In other words, 
              each pin is electrically connected to at least one other pin of 
              the interconnect through a conductor.  Topologies where physical 
              crossing of one conductor over or under another occurs shall not 
              be described using [Tree Path Description]. 

|** Several paragraphs are omitted .....


              The [Tree Path Description] keyword line is followed by at least 
              one Model_pinmap and one Section subparameters which describe 
              the pin-to-conductor mapping, and the topology of the 
              interconnect.  The electrical properties of an interconnect 
              section are described in the matrices under the 
              [Begin ICM Section] keyword which are referenced by the Section 
              subparameter(s), discussed below.  Branches or "T" connections 
              are indicated by the "Fork" and "Endfork" subparameters.  Tree
              path descriptions are terminated with a Model_pinmap 
              subparameter.

              These subparameters are described in detail below.  


              Model_pinmap

              A path description begins with the required subparameter 
              Model_pinmap.  This subparameter is followed by the name of a 
              "pin map" which names the pins on that end of the interconnect.  
              A second Model_pinmap is used at the end of the path description 
              to reference the pin map used for the other end of the 
              interconnect.  The Model_pinmap subparameter can also be used to 
              reference a pin map for the pins at the end of any Fork.  Note 
              that the pin map name given as an argument to a Model_pinmap 
              subparameter must match the name of a pin map defined by a 
              subsequent [ICM Pin Map] keyword.

              The argument to the Model_pinmap subparameter and the sub-
              parameter itself are separated by whitespace.  There can be as 
              many Model_pinmap subparameters as required, but each must be on 
              a single line.

|* Delete this paragraph:

              In general, an interconnect will have a single pin map that is 
              referenced at the beginning and end of a path description.

|** Replace with this paragraph:

|****         One or more Model_pinmap lines can exist, but each pin map
|****         name must be unique and reference a different [ICM Pin Map]
|****         description even if the content is dentical.  Alternatively,
|****         the same Model_pinmap may be used, but the subparameter Side
|****         described below must follow next.

|** End of replacement paragrapth

|** Add new sub-section

              Side

|****         If a Model_pinmap pin map name is repeated within a
              [Tree Path Description] keyword, the Side subparameter is
              required and positioned as the next line under the Model_pinmap
|****         subparameter.  The Side subparameter is followed a unique side
|****         name to allow tools to identify which of the identical pin maps
|****         to make the connection.
              
              The Side subparameter is required for all Model_pinmap lines with
              identical pin map names.  The Side subparameter is optional when
              the pin map name is unique.

|** End of sub-section addition


|** MODIFY THE EXAMPLE AS SHOWN BELOW

- -----------------------------------------------------------------------------
"ICM Model" Examples 
- -----------------------------------------------------------------------------
Example 1: A simple single line model with one section

        SectA
Port1 >--------< Port2

[Begin ICM Model] MyModelExample1
ICM_model_type SLM_general
SGR 3:1
Ref_impedance=50

[Tree Path Description]
Model_pinmap  Example1_pinmap

|** Add these lines
Side A           | The Model_pinmap name is reused, so Side and a unique
                 | side name is required
|** End of addition

  Section Mult=1 Diagonal_matrix1
Model_pinmap  Example1_pinmap

|** Add these lines
Side B           | The Model_pinmap name is reused, so Side and a unique
                 | side name is required
|** End of addition

  .
  .
  .
[End ICM Model]


|** Remainder of the Example is omitted ...


|** MAKE CHANGES TO THE [Nodal Path Description] KEYWORD SHOWN BELOW:

=============================================================================
     Keyword: [Nodal Path Description]
    Required: Yes, if [Tree Path Description] does not exist

|** Delete this line
  Sub-params: N_section, Model_nodemap
|** Add this line
  Sub-params: N_section, Model_nodemap, Side
|** End of addition

     Used By: [Begin ICM Model]
        Uses: [ICM Node Map]
 Description: This keyword marks the beginning of a nodal path description. 
              It contains the information on how two or more nodes are 
              connected.  The nodal description style allows for any arbitrary 
              topologies to be described.

              Nodes define the connection points where the conductors of two
              or more sections are joined together, or where the path is
              interfaced to the outside world.  Please note that single
              connections (dangling ends) at nodes are also permitted.  Thus
              nodes can represent any connection points, including pins (on
              either side of connectors, packages, or sockets), pads and
              bumps of a die (where the connections to the package or printed 
              circuit board are made), or the ends of either side of 
              interconnect sections of printed circuit boards.

              An interconnect path may have one or more sections where each
              section is described by RLGC or S-parameter matrices.  Multiple 
              sections within a path description may be connected in any 
              arbitrary manner by using the usual node naming techniques.  
              Please note that the swath features cannot be used with this 
              keyword.  Also note that the use of both RLGC and S-parameter 
              matrix data for sections within the same 
              [Nodal Path Description] is prohibited.
 Usage Rules: The [Nodal Path Description] keyword may appear multiple times
              in the file, however it may appear only once between each pair 
              of [Begin ICM Model]/[End ICM Model] keywords.

|** Several paragraphs are omitted .....


              Model_nodemap

              The required subparameter Model_nodemap is used to reference the 
              [ICM Node Map] keyword which provides a mapping between the 
              actual data book pin (or signal) names and the node names used 
              in the path description.

              A path description must have at least one occurrence of the
              required subparameter Model_nodemap, but can have as many
              Model_nodemap subparameters as needed to adequately describe
              the interconnect.  The number of Model_nodemap subparameters  
              used in a path description would be typically the same as the
              number of ends or sides in a connector or interconnect.  Each
              Model_nodemap subparameter must be on a single line.

              The Model_nodemap subparameter is followed by one argument,  
              which the name of a node map.  The argument must match the name 
              of a node map defined by a subsequent [ICM Node Map] keyword.  
              The argument and the subparameter must be separated by at least 
              one white space.

|** Add this paragraph:

|****         One or more Model_nodemap lines can exist, but each node map
|****         name must be unique and reference a different [ICM Node Map]
|****         description even if the content is identical.  Alternatively,
|****         the same Model_nodemap may be used, but the subparameter Side
|****         described below must follow next.

|** End of added paragraph


|** Add new sub-section

              Side

|****         If a Model_nodemap pin map name is repeated within a
              [Nodal Path Description] keyword, the Side subparameter is
|****         required and positioned as the next line under the
|****         Model_nodemap subparameter.  The Side subparameter is followed
|****         by a unique side name to allow tools to identify which of the
|****         identical node maps to make the connection.
              
              The Side subparameter is required for all Model_nodemap lines
              with identical node map names.  The Side subparameter is
|****         optional when the node map name is unique.

|** End of sub-section addition


****************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Originally it was assumed that if the pinout at each end of an interconnect
such as a connector had the same pin numbers, then the same [ICM Pin Map]
table could be used as referenced by the Model_pinmap.

However, this leads to ambiguous begin-end conditions for straight through
paths and possible ambiguity for splitter topologies possible in both the
Tree Path Description] and [Nodal Path Description] when a specific end
needs to be connected externally.  So unique Model_pinmap and Model_nodemap
names are explicitly specified to assist in the correct connection.

This prepares ICM for a possible IBIS BIRD to connect IBIS with ICM using
the multi-lingual format.

The language is not changed regarding possible single Model_pinmap and
Model_nodemap lines.  And Unmated model will have a single Model_*map line.

IIRD8.1:

A new subparameter "Side" is introduced so that the same Model_pinmap name
can be used several times without requiring coping an entire [ICM Pin Map]
table.  It is also introduced for Model_nodemap for the same reason.
This option was chosen among the following:

(1) Do nothing - NO syntax change, compatible with 1.0
    wasteful for large connectors
(2) Devise an extension convention Example1_A, EXample1_B ... Example1/A.
    Extension may conflict with an actual naming convention. 
(3) Introduce Optional subparameter or second column OR single SPACE
    Example1 Side A   or Example1 A
    However, calling routine must work with/without extension.
(4) Perhaps introduce in the [ICM Pin Map] and [ICM Node Map]
    a) multiple names 
    b) Another_name   xxxxx  subparameter syntax

Option (3) with a distinct subparameter Side is chosen as as the method
that is consistent with the rest of the specification.

IIRD8.2

Some editorial changes per Arpad Muranyi's comments are made and noted
by |**** lines

****************************************************************************

ANY OTHER BACKGROUND INFORMATION:

IIRD8 assumes that IIRD6 will be rejected.

The golden parser must be corrected to accept only one Model_*map or else
test that the arguments of several are unique.

IIRD8 was discussed at the October 29, 2004 IBIS meeting and the Novemeber
4, 2004 IBIS Futures Meeting.  The action item was to investigate a better
method of differentiating the terminals by some name, extension or name
and subparameter to avoid the need to provide large, identical pin tables.

****************************************************************************


- --------------050704000901020401070700--


|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 24 Dec 2004 22:58:48 -0800
From: "Mirmak, Michael" <michael.mirmak@intel.com>
Subject: [IBIS-Users] BIRD95: Power Integrity Analysis Using IBIS

This is a multi-part message in MIME format.

- ------_=_NextPart_001_01C4EA4F.34D0DCBA
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


The enclosed BIRD, Power Integrity Analysis Using IBIS, is submitted on
behalf of Syed Huq, Vinu Arumugham and Zhiping Yang of Cisco Systems.
It will be discussed at the January 7, 2005 IBIS Open Forum
teleconference.

- - Michael Mirmak
  Intel Corp.
  Chair, EIA IBIS Open Forum






- ------_=_NextPart_001_01C4EA4F.34D0DCBA
Content-Type: text/plain;
	name="BIRD95.txt"
Content-Transfer-Encoding: base64
Content-Description: BIRD95.txt
Content-Disposition: attachment;
	filename="BIRD95.txt"

KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KQklSRCBJRCM6
ICAgICAgIDk1DQpJU1NVRSBUSVRMRTogICAgUG93ZXIgSW50ZWdyaXR5IEFuYWx5c2lzIFVzaW5n
IElCSVMNClJFUVVFU1RFUjogICAgICBTeWVkIEh1cSwgVmludSBBcnVtdWdoYW0sIFpoaXBpbmcg
WWFuZyAtIENpc2NvIFN5c3RlbXMsIEluYw0KREFURSBTVUJNSVRURUQ6IERlY2VtYmVyIDIzdGgs
IDIwMDQgIA0KREFURSBBQ0NFUFRFRCBCWSBJQklTIE9QRU4gRk9SVU06IFBFTkRJTkcgDQoNCioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNClNUQVRFTUVOVCBP
RiBUSEUgSVNTVUU6DQoNClBvd2VyIEludGVncml0eSBBbmFseXNpcyB3aGljaCBpbmNsdWRlcyBD
dXJyZW50IHN3aXRjaGluZyBwcm9maWxlIG9mIHRoZSBDb3JlDQphcyB3ZWxsIGFzIFNpbXVsdGFu
ZW91cyBTd2l0Y2hpbmcgTm9pc2UgKFNTTikgb2YgdGhlIElucHV0L091dHB1dCAoSS9PKQ0Kc3Rh
Z2VzIG9mIGEgYnVmZmVyIG5lZWRzIHRvIGJlIGFuYWx5emVkIHRocm91Z2ggSUJJUy4gVGhpcyBC
SVJEIHByb3Bvc2VzDQphIG1vZGVsaW5nIHNjaGVtZSB0byBzb2x2ZSB0aGlzLg0KDQoqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioNCg0KU1RBVEVNRU5UIE9GIFRIRSBSRVNPTFZFRCBTUEVDSUZJQ0FUSU9O
UzoNCg0KUG93ZXIgSW50ZWdyaXR5IEFuYWx5c2lzIGZyb20gYSBtb2RlbGluZyBwZXJzcGVjdGl2
ZSBoYXMgYmVlbiBzcGxpdCBpbnRvIA0KdHdvIHRhc2tzLiANCg0KMSlTb2x2aW5nIHRoZSBTaW11
bHRhbmVvdXMgU3dpdGNoaW5nIE5vaXNlIChTU04pIG9uIHRoZSBJL08gbGV2ZWwgdXNpbmcgY3Vy
cmVudCANCiAgYW5kIGZ1dHVyZSBJQklTIHN5bnRheC4gVGhpcyB3aWxsIGJlIGFjaGlldmVkIHRo
cm91Z2ggSXZzVCB0YWJsZXMuDQogIA0KMilTb2x2aW5nIHRoZSBDb3JlIEN1cnJlbnQgU3dpdGNo
aW5nIHByb2ZpbGUgdXNpbmcgdGhlIElDRU0gKEludGVncmF0ZWQgY2lyY3VpdHMgDQogIEVsZWN0
cmljYWwgTW9kZWwgc3BlY2lmaWNhdGlvbiwgUHJvamVjdCBudW1iZXIgNjIwMTQtMykuIFRoaXMg
d2lsbCBiZSBhY2hpZXZlZCANCiAgYnkgYSBjYWxsIHN0YXRlbWVudCB3aXRoaW4gSUJJUyBjYWxs
aW5nIGFuIElDRU0gbW9kZWwuIFVzaW5nIHY0LjEgSUJJUyBzeW50YXguDQoNCkN1cnJlbnQgaW50
byB0aGUgcG93ZXIgYW5kIGdyb3VuZCByYWlscyBhcmUgbmVlZGVkIHRvIGdpdmUgYSBtb3JlIGFj
Y3VyYXRlDQphbmFseXNpcyBmb3IgZ3JvdW5kIGFuZCBwb3dlciBib3VuY2UgYW5hbHlzaXMgYXNz
b2NpYXRlZCB3aXRoIHNpbXVsdGFuZW91cw0Kc3dpdGNoaW5nIG5vaXNlLg0KfA0KfD09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PQ0KfCAgICAgS2V5d29yZHM6ICAgICBbU2VyaWVzIENvbXBvc2l0ZSBDdXJy
ZW50XSAgDQp8ICAgICBSZXF1aXJlZDogICAgIE5vDQp8ICAgICBEZXNjcmlwdGlvbjogIERlc2Ny
aWJlcyB0aGUgc2hhcGUgb2YgdGhlIHJpc2luZyBhbmQgZmFsbGluZyBlZGdlDQp8ICAgICAgICAg
ICAgICAgICAgIGN1cnJlbnQgd2F2ZWZvcm1zIGZyb20gdGhlIHBvd2VyIHN1cHBseSBtZWFzdXJl
ZCB0aHJvdWdoDQp8ICAgICAgICAgICAgICAgICAgIFJfVkREKHNlZSBkaWFncmFtKS4gVGhpcyBp
bmNsdWRlcyBQcmUtZHJpdmVyLCBDcm93LWJhciBjdXJyZW50LA0KfCAgICAgICAgICAgICAgICAg
ICBvbi1kaWUgSV9ieXBhc3MgYW5kIElfdGVybShzZWUgZGlhZ3JhbSkuDQp8ICAgICBVc2FnZSBS
dWxlczogIFRoZSBbU2VyaWVzIENvbXBvc2l0ZSBDdXJyZW50XSBrZXl3b3JkIGlzDQp8ICAgICAg
ICAgICAgICAgICAgIHBvc2l0aW9uZWQgdW5kZXIgdGhlIFtSaXNpbmcgV2F2ZWZvcm1dIChmb3Ig
cmlzaW5nDQp8ICAgICAgICAgICAgICAgICAgIHdhdmVmb3JtIGN1cnJlbnRzKSBhbmQgW0ZhbGxp
bmcgV2F2ZWZvcm0gKGZvciBmYWxsaW5nDQp8ICAgICAgICAgICAgICAgICAgIHdhdmVmb3JtIGN1
cnJlbnRzLiAgVGhlIGtleXdvcmRzIGFyZSBmb2xsb3dlZCBieSBhIHRhYmxlDQp8ICAgICAgICAg
ICAgICAgICAgIG9mIHRpbWUgdnMuIGN1cnJlbnQgcG9pbnRzIHRoYXQgZGVzY3JpYmUgdGhlIHNo
YXBlIG9mIGEgDQp8ICAgICAgICAgICAgICAgICAgIGN1cnJlbnQgd2F2ZWZvcm0uICBUaGVzZSB0
aW1lL2N1cnJlbnQgdGFibGVzIGluaGVyaXQgdGhlIA0KfCAgICAgICAgICAgICAgICAgICBmaXh0
dXJlIHRlc3QgbG9hZCBvZiB0aGUgW1Jpc2luZyBXYXZlZm9ybV0gb3IgW0ZhbGxpbmcgV2F2ZWZv
cm1dDQp8ICAgICAgICAgICAgICAgICAgIFIvTC9DL1ZfZml4dHVyZSBhbmQgUi9ML0NfZHV0IHN1
YnBhcmFtZXRlcnMuDQp8DQp8ICAgICAgICAgICAgICAgICAgIFRoZSByZWNvbW1lbmRlZCBsb2Fk
aW5nIGNvbmRpdGlvbiBpcyA1MCBPaG1zIHRvIFZkZCBhbmQNCnwJCSAgICA1MCBPaG1zIHRvIEdu
ZCBmb3IgZWFjaCBbUmlzaW5nIFdhdmVmb3JtXSBhbmQgW0ZhbGxpbmcNCnwJCSAgICBbV2F2ZWZv
cm1dLg0KfAkJICAgIA0KfAkJICAgIFRoZSByZWNvbW1lbmRlZCBuby1sb2FkIGNvbmRpdGlvbiBp
cyBhIFJfZml4dHVyZSBvZiAxLjBNZWcNCnwJCSAgICBPaG1zIG1pbmltdW0gZm9yIGVhY2ggW1Jp
c2luZyBXYXZlZm9ybV0gYW5kIFtGYWxsaW5nDQp8CQkgICAgW1dhdmVmb3JtXS4NCnwJCSAgICAg
DQp8ICAgICAgICAgICAgICAgICAgIFRoZSB0YWJsZSBpdHNlbGYgY29uc2lzdHMgb2Ygb25lIGNv
bHVtbiBvZiB0aW1lIHBvaW50cywgdGhlbiANCnwJCSAgICB0aHJlZSBjb2x1bW5zIG9mIGN1cnJl
bnQgcG9pbnRzIGluIHRoZSBzdGFuZGFyZCB0eXAsIG1pbiwgYW5kIA0KfAkJICAgIG1heCBmb3Jt
YXQuVGhlIGZvdXIgZW50cmllcyBtdXN0IGJlIHBsYWNlZCBvbiBhIHNpbmdsZSBsaW5lIGFuZA0K
fCAgICAgICAgICAgICAgICAgICBtdXN0IGJlIHNlcGFyYXRlZCBieSBhdCBsZWFzdCBvbmUgd2hp
dGUgc3BhY2UuICBBbGwgZm91ciANCnwgICAgICAgICAgICAgICAgICAgY29sdW1ucyBhcmUgcmVx
dWlyZWQuICBIb3dldmVyLCBkYXRhIGlzIG9ubHkgcmVxdWlyZWQgaW4gdGhlIA0KfAkJICAgIHR5
cGljYWwgY29sdW1uLiAgSWYgbWluaW11bSBvciBtYXhpbXVtIGRhdGEgaXMgbm90IGF2YWlsYWJs
ZSwgDQp8CQkgICAgdXNlIHRoZSByZXNlcnZlZCB3b3JkICJOQSIuICBUaGUgZmlyc3QgdmFsdWUg
aW4gdGhlIHRpbWUgY29sdW1uIA0KfAkJICAgIG5lZWQgbm90IGJlICcwJy4gVGltZSB2YWx1ZXMg
bXVzdCBpbmNyZWFzZSBhcyBvbmUgcGFyc2VzIGRvd24gDQp8CQkgICAgdGhlIHRhYmxlLiBUaGUg
d2F2ZWZvcm0gdGFibGUgY2FuIGNvbnRhaW4gYSBtYXhpbXVtIG9mIDEwMDAgZGF0YQ0KfCAgICAg
ICAgICAgICAgICAgICBwb2ludHMuICBBIG1heGltdW0gb2YgMTAwIHdhdmVmb3JtIHRhYmxlcyBh
cmUgYWxsb3dlZCBwZXINCnwgICAgICAgICAgICAgICAgICAgbW9kZWwuDQp8DQp8ICAgICAgICAg
ICAgICAgICAgIFRoZSBkaWFncmFtIGJlbG93IGlsbHVzdHJhdGVzIHRoZSBjb21wbGV0ZSBtb2Rl
bCB3aXRoDQp8ICAgICAgICAgICAgICAgICAgIHJlc3BlY3QgdG8gdGhlIFtSaXNpbmcgV2F2ZWZv
cm1dIGFuZCBbRmFsbGluZyBXYXZlZm9ybV0NCnwgICAgICAgICAgICAgICAgICAgc3VicGFyYW1l
dGVycy4gDQp8DQp8ICAgICAgICAgICAgICAgICAgIFRoZSAnZml4dHVyZScgc3VicGFyYW1ldGVy
cyBzcGVjaWZ5IHRoZSBsb2FkaW5nDQp8ICAgICAgICAgICAgICAgICAgIGNvbmRpdGlvbnMgdW5k
ZXIgd2hpY2ggdGhlIHdhdmVmb3JtIGlzIHRha2VuLiAgVGhlIFJfZHV0LA0KfCAgICAgICAgICAg
ICAgICAgICBDX2R1dCwgYW5kIExfZHV0IHN1YnBhcmFtZXRlcnMgYXJlIGFuYWxvZ291cyB0byB0
aGUNCnwgICAgICAgICAgICAgICAgICAgcGFja2FnZSBwYXJhbWV0ZXJzIFJfcGtnLCBDX3BrZywg
YW5kIExfcGtnIGFuZCBhcmUgdXNlZA0KfCAgICAgICAgICAgICAgICAgICBpZiB0aGUgd2F2ZWZv
cm0gaW5jbHVkZXMgdGhlIGVmZmVjdHMgb2YgcGluDQp8ICAgICAgICAgICAgICAgICAgIGluZHVj
dGFuY2UvY2FwYWNpdGFuY2UuDQp8DQp8DQp8ICAgICAgICANCnwgICAgICAgICAgICAgIHwNCnwg
ICAgICAgICAgICAgIHwNCnwgICAgICAgICAgICAgIHwNCnwgICAgICAgICAgICAgIHwgICAgICAg
ICAgUEFDS0FHRSAgICAgICAgICAgIHwgICBURVNUIEZJWFRVUkUNCnwgICAgICAgICAgX19fX3xf
X19fICAgICAgICAgICAgICAgICAgICAgICAgIHwNCnwgICAgICAgICB8ICBEVVQgICAgfCAgIExf
ZHV0ICAgUl9kdXQgICAgICAgIHwgTF9maXh0dXJlICBSX2ZpeHR1cmUNCnwgICAgICAgICB8ICBk
aWUgICAgfC0tLUBAQEBALS0vXC9cL1wtLW8tLS0tLXwtLUBAQEAtLS1vLS0tL1wvXC9cLS0tIFZf
Zml4dHVyZQ0KfCAgICAgICAgIHxfX19fX19fX198ICAgICAgICAgICAgICAgICAgfCAgICAgfCAg
ICAgICAgIHwNCnwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIHwg
ICAgICAgICB8DQp8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB8
ICAgICAgICAgfA0KfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICBDX2R1dCA9PT0gICAg
fCAgICAgICAgPT09IENfZml4dHVyZQ0KfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgfCAgICAgfCAgICAgICAgIHwNCnwgICAgICAgICAgICAgIHxfX19fX19fX19fX19fX19f
X19fX19fX3xfX19fX3xfX19fX19fX198X19fIA0KfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHTkQNCnwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgDQp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KfCAg
ICANCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIC0tLS0tLS0tIC0tLS0tLS0tICgqKikNCnwgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8IHwgICAgICB8PC0tLQ0K
fCAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19ffExfVkREUXxffFJfVkREUXxfX1ZERFENCnwgICAgICAgICAgICAgfCAgICAgICAgICAgICAg
ICAgICB8ICAgICAgICAgfCAgICAgfCAgICAgICB8IHwgICAgICB8IHwgICAgICB8ICAgICAgICAg
IA0KfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICB8ICAg
ICAgIHwgLS0tLS0tLS0gLS0tLS0tLS0NCnwgICAgICAgICAgIC0tLS0tICAgICAgICAgICAgICAg
ICB8ICAgICAgICAgfCAgICAgfCAgICAgICB8ICAgDQp8CSAgICB8IEUgfCAgICAgICAgICAgICAg
ICAgfCAgICAgICAgIC8gICAgIHwgICAgICAgfA0KfCAgICAgICAgICAgfCBTIHwgICAgICAgIC0t
LS0tLS0tLS0tLS0tLS0gICBcICAgUF98ICAgICAgLS0tIFBvd2VyQ2xhbXANCnwgICAgICAgICAg
IHwgUiB8ICAgICAgICB8ICBQcmUtRHJpdmVyICB8ICAgLyB8fCAgICAgICAgIC8gXA0KfCAgICAg
ICAgICAgLS0tLS0gICAgICAgIHwgICBDaXJjdWl0ICAgIHwgICBcIHx8X18gICAgICAgLS0tDQp8
ICAgICAgICAgICAgIHwgICAgICAgICAgfCAgcG93ZXJlZCBieSAgfCAgIHwgICAgIHwgICAgICAg
fA0KfCAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgIFZERFEgICAgIHwgICB8ICAgICB8ICB8
ICAgIHwgICBJX3NpZw0KfCAgICAgICAgICAgLS0tLS0gICAgICAgIC0tLS0tLS0tLS0tLS0tLS0g
ICB8ICAgICB8ICB8ICAgIHwgICAtLS0tLS0tPg0KfCAgICAgICAgICAgfCBFIHwgICAgICAgICAg
ICAgICAgIHwgICAgICAgICBvLS0tLS1vLS18LS0tLW8tLS0tLS0tLS0tDQp8ICAgICAgICAgICB8
IFMgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgIHwgIHwgICAgfA0KfAkgfCAgfCBM
IHwgICAgICAgICAgICB8ICAgIHwgICAgICB8ICAvICAgICB8ICB8ICAgIHwNCnxJX2J5cGFzc3wg
IC0tLS0tICAgICAgIElfcHJlfCAgICB8SV90ZXJtfCAgXCAgIE5ffCAgdiAgIC0tLSBHTkRDbGFt
cA0KfAkgfCAgICB8ICAgICAgICAgICAgICB8ICAgIHwgICAgICB8ICAvICB8fCAgIElfY2IgLyBc
DQp8CSB2ICAgIHwgICAgICAgICAgICAgIHYgICAgfCAgICAgIHYgIFwgIHx8XyAgICAgICAtLS0N
CnwJICAgIC0tLS0tICAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgfCAgICAgICB8ICAg
LS0tLS0tICAtLS0tLS0tDQp8CSAgICAtLS0tLSBDX3ArYiAgICAgICAgICAgfCAgICAgICAgIHwg
ICAgIHwgICAgICAgfCAgIHwgICAgIHwgfCAgICAgfA0KfAkgICAgICB8X19fX19fX19fX19fX19f
X19fX3xfX19fX19fX198X19fX198X19fX19fX3xfX198TF9HTkR8X3xSX0dORHxfX0dORA0KfCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgICB8IHwgICAgIHwNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tICAtLS0tLS0tDQp8DQp8ICAgICAgICAgICAg
SV9ieXBhc3MgLSBCeXBhc3MgY3VycmVudA0KfCAgICAgICAgICAgIElfcHJlICAgIC0gUHJlLURy
aXZlciBjdXJyZW50DQp8ICAgICAgICAgICAgSV9jYiAgICAgLSBDcm93LWJhciBjdXJyZW50DQp8
ICAgICAgICAgICAgSV90ZXJtICAgLSBUZXJtaW5hdGlvbiBjdXJyZW50IChvcHRpb25hbCkNCnwg
ICAgICAgICAgICBMX1ZERFEgICAtIE9uLWRpZSBpbmR1Y3RhbmNlIG9mIEkvTyBQb3dlcg0KfCAg
ICAgICAgICAgIFJfVkREUSAgIC0gT24tZGllIHJlc2lzdGFuY2Ugb2YgSS9PIFBvd2VyDQp8ICAg
ICAgICAgICAgTF9HTkQgICAgLSBPbi1kaWUgaW5kdWN0YW5jZSBvZiBHcm91bmQNCnwgICAgICAg
ICAgICBSX0dORCAgICAtIE9uLWRpZSByZXNpc3RhbmNlIG9mIEdyb3VuZA0KfCAgICAgICAgICAg
IENfcCtiICAgIC0gQnlwYXNzICsgUGFyYXNpdGljIENhcGFjaXRhbmNlDQp8ICAgICAgICAgICAg
RVNSICAgICAgLSBFcXVpdmFsZW50IFNlcmllcyBSZXNpc3RhbmNlIGZvciBvbi1kaWUgRGVjYXAN
CnwgICAgICAgICAgICBFU0wgICAgICAtIEVxdWl2YWxlbnQgU2VyaWVzIEluZHVjdGFuY2UgZm9y
IG9uLWRpZSBEZWNhcA0KfA0KfCAgICAgICAgICAgICgqKikgICAgIC0gQ3VycmVudCBtZWFzdXJl
IHBvaW50DQp8DQp8DQp8PT09PT09PT09PT09PT09PT09PT09PT09IEV4YW1wbGUgPT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09DQp8CQkJDQpbUmlzaW5nIFdhdmVmb3JtXSAJCQkNClJfZml4
dHVyZSA9IDUwLjANClZfZml4dHVyZSA9IDEuOA0KfCAuLi4NCnwgLi4uICAgICAgICAgICAgfCBS
aXNpbmcgV2F2ZWZvcm0gdGFibGUNCnwgLi4uCQkJCQkJDQpbU2VyaWVzIENvbXBvc2l0ZSBDdXJy
ZW50XQ0KfA0KfAkJDQp8IFRpbWUgICAgICAgICAgICBJKHR5cCkgICAgICBJKG1pbikgICBJKG1h
eCkNCjAJCTQuMjQzRS0wNQlOQQlOQQ0KNC4wMEUtMTEJNC4yNDRFLTA1CU5BCU5BDQo4LjAwRS0x
MQk0LjI0MkUtMDUJTkEJTkENCjEuMjBFLTEwCTQuMjY1RS0wNQlOQQlOQQ0KMS42MEUtMTAJMy42
MTBFLTA1CU5BCU5BDQoyLjAwRS0xMAkzLjkwM0UtMDMJTkEJTkENCi4NCi4NCi4NCjMuODBFLTA5
CTUuMTA2RS0wNQlOQQlOQQ0KMy44NEUtMDkJNS4wMTNFLTA1CU5BCU5BDQozLjg4RS0wOQk0Ljkx
OUUtMDUJTkEJTkENCjMuOTJFLTA5CTQuODI2RS0wNQlOQQlOQQ0KMy45NkUtMDkJNC43MzNFLTA1
CU5BCU5BDQo0LjAwRS0wOQk1LjEwOEUtMDUJTkEJTkENCnwJCQkNCltSaXNpbmcgV2F2ZWZvcm1d
IAkJCQ0KUl9maXh0dXJlID0gNTAuMA0KVl9maXh0dXJlID0gMC4wDQp8IC4uLg0KfCAuLi4gICAg
ICAgICAgICB8IFJpc2luZyBXYXZlZm9ybSB0YWJsZQ0KfCAuLi4JCQkJCQkNCltTZXJpZXMgQ29t
cG9zaXRlIEN1cnJlbnRdCQkJCQkJDQp8IFRpbWUgICAgICAgICAgICBJKHR5cCkgICAgICBJKG1p
bikgIEkobWF4KQ0KMAkJNC4yNDNFLTA1CU5BCU5BDQo0LjAwRS0xMQk0LjI0NEUtMDUJTkEJTkEN
CjguMDBFLTExCTQuMjQyRS0wNQlOQQlOQQ0KMS4yMEUtMTAJNC4yNjVFLTA1CU5BCU5BDQoxLjYw
RS0xMAkzLjYxMEUtMDUJTkEJTkENCjIuMDBFLTEwCTMuOTAzRS0wMwlOQQlOQQ0KLg0KLg0KLg0K
My44MEUtMDkJMi4wMTJFLTAyCU5BCU5BDQozLjg0RS0wOQkyLjAxMkUtMDIJTkEJTkENCjMuODhF
LTA5CTIuMDEyRS0wMglOQQlOQQ0KMy45MkUtMDkJMi4wMTJFLTAyCU5BCU5BDQozLjk2RS0wOQky
LjAxMkUtMDIJTkEJTkENCjQuMDBFLTA5CTIuMDEyRS0wMglOQQlOQQ0KfAkJCQ0KW0ZhbGxpbmcg
V2F2ZWZvcm1dIAkJCQ0KUl9maXh0dXJlID0gNTAuMA0KVl9maXh0dXJlID0gMS44DQp8IC4uLg0K
fCAuLi4gICAgICAgICAgICB8IFJpc2luZyBXYXZlZm9ybSB0YWJsZQ0KfCAuLi4JCQkJCQkNCltT
ZXJpZXMgQ29tcG9zaXRlIEN1cnJlbnRdCQkJCQkJDQp8IFRpbWUgICAgICAgICAgICBJKHR5cCkg
ICAgICBJKG1pbikgIEkobWF4KQkNCjAJCTQuMzAyRS0wNQlOQQlOQQ0KNC4wMEUtMTEJNC4yOTlF
LTA1CU5BCU5BDQo4LjAwRS0xMQk0LjMwNEUtMDUJTkEJTkENCjEuMjBFLTEwCTQuMjg3RS0wNQlO
QQlOQQ0KMS42MEUtMTAJNC43ODJFLTA1CU5BCU5BDQoyLjAwRS0xMAkxLjQ1OUUtMDQJTkEJTkEN
Ci4NCi4NCi4NCjMuODBFLTA5CTQuOTMzRS0wNQlOQQlOQQ0KMy44NEUtMDkJNS4yMTFFLTA1CU5B
CU5BDQozLjg4RS0wOQk1LjQ5MEUtMDUJTkEJTkENCjMuOTJFLTA5CTUuNDQxRS0wNQlOQQlOQQ0K
My45NkUtMDkJNC44NDJFLTA1CU5BCU5BDQo0LjAwRS0wOQk0LjI0NEUtMDUJTkEJTkENCnwNCltG
YWxsaW5nIFdhdmVmb3JtXSAJCQkNClJfZml4dHVyZSA9IDUwLjANClZfZml4dHVyZSA9IDAuMA0K
fCAuLi4NCnwgLi4uICAgICAgICAgICAgfCBGYWxsaW5nIFdhdmVmb3JtIHRhYmxlDQp8IC4uLgkJ
CQkJCQ0KW1NlcmllcyBDb21wb3NpdGUgQ3VycmVudF0JCQkJCQkNCnwgVGltZSAgICAgICAgICAg
IEkodHlwKSAgICAgIEkobWluKSAgSShtYXgpCQ0KMAkJMi4wMTFFLTAyCU5BCU5BDQo0LjAwRS0x
MQkyLjAxMUUtMDIJTkEJTkENCjguMDBFLTExCTIuMDExRS0wMglOQQlOQQ0KMS4yMEUtMTAJMi4w
MTFFLTAyCU5BCU5BDQoxLjYwRS0xMAkyLjAxMkUtMDIJTkEJTkENCjIuMDBFLTEwCTIuMDIyRS0w
MglOQQlOQQ0KLg0KLg0KLg0KMy44MEUtMDkJNC44NzBFLTA1CU5BCU5BDQozLjg0RS0wOQk0Ljky
OUUtMDUJTkEJTkENCjMuODhFLTA5CTQuOTg5RS0wNQlOQQlOQQ0KMy45MkUtMDkJNS4wNDhFLTA1
CU5BCU5BDQozLjk2RS0wOQk1LjEwOEUtMDUJTkEJTkENCjQuMDBFLTA5CTQuODQzRS0wNQlOQQlO
QQ0KfA0KfA0KW1Jpc2luZyBXYXZlZm9ybV0gCQkJDQpSX2ZpeHR1cmUgPSAxLjBNZWcNClZfZml4
dHVyZSA9IDAuMA0KfCAuLi4NCnwgLi4uICAgICAgICAgICAgfCBSaXNpbmcgV2F2ZWZvcm0gdGFi
bGUNCnwgLi4uDQpbU2VyaWVzIENvbXBvc2l0ZSBDdXJyZW50XQ0KfAkJDQp8IFRpbWUgICAgICAg
ICAgICBJKFR5cCkgICAgIEkoTWluKSAgIEkoTWF4KQ0KMAkJNC4yNDNFLTA1CU5BCU5BDQo0LjAw
RS0xMQk0LjI0NEUtMDUJTkEJTkENCjguMDBFLTExCTQuMjQyRS0wNQlOQQlOQQ0KMS4yMEUtMTAJ
NC4yNjVFLTA1CU5BCU5BDQoxLjYwRS0xMAkzLjYxMEUtMDUJTkEJTkENCjIuMDBFLTEwCTMuOTAz
RS0wMwlOQQlOQQ0KLg0KLg0KLg0KMy44MEUtMDkJNS42NzFFLTA1CU5BCU5BDQozLjg0RS0wOQk1
LjYzOUUtMDUJTkEJTkENCjMuODhFLTA5CTUuNjA3RS0wNQlOQQlOQQ0KMy45MkUtMDkJNS41NTdF
LTA1CU5BCU5BDQozLjk2RS0wOQk1LjQ4MUUtMDUJTkEJTkENCjQuMDBFLTA5CTUuNDA1RS0wNQlO
QQlOQQ0KfAkJCQkJCQ0KW0ZhbGxpbmcgV2F2ZWZvcm1dIAkJCQ0KUl9maXh0dXJlID0gMS4wTWVn
DQpWX2ZpeHR1cmUgPSAwLjANCnwgLi4uDQp8IC4uLiAgICAgICAgICAgIHwgRmFsbGluZyBXYXZl
Zm9ybSB0YWJsZQ0KfCAuLi4JDQpbU2VyaWVzIENvbXBvc2l0ZSBDdXJyZW50XQ0KfAkJCQkJDQp8
IFRpbWUgICAgICAgICAgICBJKFR5cCkgICAgIEkoTWluKSAgICBJKE1heCkNCjAJCTQuMzA0RS0w
NQlOQQlOQQ0KNC4wMEUtMTEJNC4zMDBFLTA1CU5BCU5BDQo4LjAwRS0xMQk0LjMwNkUtMDUJTkEJ
TkENCjEuMjBFLTEwCTQuMjg4RS0wNQlOQQlOQQ0KMS42MEUtMTAJNC43ODRFLTA1CU5BCU5BDQoy
LjAwRS0xMAkxLjQ1OUUtMDQJTkEJTkENCi4NCi4NCi4NCjMuODBFLTA5CTEuMjM5RS0wNAlOQQlO
QQ0KMy44NEUtMDkJOS4yNzlFLTA1CU5BCU5BDQozLjg4RS0wOQk2LjE2OEUtMDUJTkEJTkENCjMu
OTJFLTA5CTMuMDU3RS0wNQlOQQlOQQ0KMy45NkUtMDkJNS4zNzNFLTA3CU5BCU5BDQo0LjAwRS0w
OQkzLjE2NUUtMDUJTkEJTkENCnwNCnwgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnwNCnwgQ2FsbHMgdG8gSUNFTSBTUElDRSBt
b2RlbDoNCnwNCnwNCnwNCltDaXJjdWl0IENhbGxdIElFQ00xDQp8IG1hcHBpbmcgICAgIHBvcnQg
ICAgbm9kZQ0KfA0KUG9ydF9tYXAgICAgICB2ZGRfaWMgIDExDQpQb3J0X21hcCAgICAgIHZzc19p
YyAgMTINCnwNCltFbmQgQ2lyY3VpdCBDYWxsXSB8IENvbm5lY3RpbmcgdmRkX2ljIHRvIHBpbiAx
MSBhbmQgdnNzX2ljIHRvIHBpbiAxMg0KfA0KfA0KW0V4dGVybmFsIENpcmN1aXRdIElDRU0xDQpM
YW5ndWFnZSBTUElDRQ0KfCBDb3JuZXIgICAgICAgQ29ybmVyX25hbWUgICAgZmlsZV9uYW1lICAg
ICBjaXJjdWl0X25hbWUNCkNvcm5lciAgICAgICAgIFRZUCAgICAgICAgICAgIGljZW1fY29yZTEu
c3BpICBpY2VtX3R5cDENCkNvcm5lciAgICAgICAgIE1JTiAgICAgICAgICAgIGljZW1fY29yZTEu
c3BpICBpY2VtX21pbjENCkNvcm5lciAgICAgICAgIE1BWCAgICAgICAgICAgIGljZW1fY29yZTEu
c3BpICBpY2VtX21heDENCnwgUG9ydHMgYXJlIGluIHRoZSBzYW1lIG9yZGVyIGFzIGRlZmluZWQg
aW4gU1BJQ0UNClBvcnRzICAgICAgICAgIHZkZF9pYyAgICAgICB2c3NfaWMNCnwNCnwNCnwgQ2Fs
bHMgdG8gSUNFTSBBTVMgbW9kZWw6IA0KfA0KW0NpcmN1aXQgQ2FsbF0gSUNFTTINCnBvcnRfbWFw
ICB2ZGRfaWMgICAgMjENCnBvcnRfbWFwICB2c3NfaWMgICAgMjINCltFbmQgQ2lyY3VpdCBDYWxs
XQ0KfA0KfA0KW0V4dGVybmFsIENpcmN1aXRdICBJQ0VNMg0KTGFuZ3VhZ2UgIFZIREwtQU1TDQp8
DQp8IENvcm5lciAgY29ybmVyX25hbWUgIGZpbGVfbmFtZSAgc3ViY2t0X25hbWUNCkNvcm5lciAg
ICBUeXAgICAgaWNlbV9jb3JlMi52aGQgaWNlbV90eXAyDQpDb3JuZXIgICAgTWluICAgIGljZW1f
Y29yZTIudmhkIGljZW1fbWluMg0KQ29ybmVyICAgIE1heCAgICBpY2VtX2NvcmUzLnZoZCBpY2Vt
X21heDINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpQb3J0cyAgdmRkX2ljIHZzc19p
Yw0KfA0KW0VuZCBFeHRlcm5hbCBDaXJjdWl0XQ0KfA0KfA0KfC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KQU5BTFlTSVMgUEFUSC9EQVRBIFRIQVQgTEVE
IFRPIFNQRUNJRklDQVRJT046DQoNClBvd2VyIEludGVncml0eSBBbmFseXNpcyBoYXMgYmVjb21l
IGEgc2lnbmlmaWNhdCBwYXJ0IG9mIFNpZ25hbCBJbnRlZ3JpdHkgDQpTaW11bGF0aW9ucyBhbmQg
QW5hbHlzaXMuIENvcmUgdm9sdGFnZXMgYXJlIGdvaW5nIGRvd24gd2l0aCANCnByb2Nlc3MgZW5o
YWNlbWVudGFuZCwgSS9PIHNwZWVkcyBhcmUgaW5jcmVhc2luZywgaXQgaXMgY3JpdGljYWwgdGhh
dCANCmhpZ2gtc3BlZWQgYXBwbGljYXRpb25zIHNvbHZlIFBvd2VyIEludGVncml0eSBpc3N1ZXMg
b24gdGhlIGRpZSwgcGFja2FnZSANCmFuZCBQQ0JzIGNvbWJpbmVkLiBTeXN0ZW0gZmFpbHVyZXMg
Y2FuIGJlIHRyYWNlZCB0byBwb29yIFBvd2VyIEludGVncml0eSANCkRlc2lnbnMuDQoNCkR1cmlu
ZyB0aGUgRGVzaWduQ29uMjAwNCBQb3dlciBJbnRlZ3JpdHkgUGFuZWwsIHRoZXNlIGlzc3VlcyB3
ZXJlIGRpc2N1c3NlZC4NCkl0IHdhcyBzdWdnZXN0ZWQgdG8gZXhwbG9yZSBhIHNvbHV0aW9uIHRo
cm91Z2ggdGhlIElCSVMgY29tbWl0ZWUgYW5kIGhlbmNlDQp0aGlzIEJJUkQgcHJvcG9zYWwuDQoN
ClNldmVyYWwgZGlzY3Vzc2lvbnMgd2VyZSBjb25kdWN0ZWQoMy8xMiw1LzE0LDYvOCw3LzE2LDgv
MjQpd2l0aCB0aGUgSUJJUw0KRnV0dXJlcyBNZWV0aW5ncy4gDQotLS0tDQoNCioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKg0KDQpBTlkgT1RIRVIgQkFDS0dST1VORCBJTkZPUk1BVElPTjoNCg0KVGhpcyBw
cm9wb3NhbCBpcyBiYXNlZCBvbiB2YXJpb3VzIHBhc3Qgd29yayBkb25lIGJ5IG1hbnkgSUJJUyBj
b250cmlidXRvcnMgYW5kIA0KdGhleSBhcmUgbGlzdGVkIGluIG5vIHBhcnRpY3VsYXIgb3JkZXIu
IExpbmtzIHRvIElDRU0gYXJlIGFsc28gbGlzdGVkOgkNCg0KRGVzaWduQ29uMjAwNCBQRE4gU2lt
dWxhdGlvbiBwYW5lbCBwcm9jZWVkaW5ncyBtYXRlcmlhbCBhbmQgc2xpZGVzOg0KaHR0cDovL2hv
bWUuYXR0Lm5ldC9+aXN0dmFuLm5vdmFrL3BhcGVycy5odG1sDQoNCkJJUkQ0Mi4zOiBNb2RlbGlu
ZyBDdXJyZW50IFdhdmVmb3Jtcw0KICAgICAgICAgIEMuS3VtYXIsIEJvYiBSb3NzDQpJQklTIGFu
ZCBJQ0VNIGludGVyYWN0aW9uOiBCLlJvc3MsIE1pY3JvZWxlY3Ryb25pYyBKb3VybmFsIE5vdjE2
LDIwMDMNCg0KSUNFTToJIA0KLS0tLQ0KRU1DIGZvciBDb21wb25lbnQsIEludGVncmF0ZWQgY2ly
Y3VpdHMgRWxlY3RyaWNhbCBNb2RlbChJQ0VNKQ0KICAgICAgICAgICAgICAgIDkzL1hYL0NEQywg
UHJvamVjdCBudW1iZXIgNjIwMTQtMw0KQ29va2Jvb2sgZm9yIEludGVncmF0ZWQgQ2lyY3VpdCBt
b2RlbCBJQ0VNLCBQcm9qZWN0IG51bWJlciA2MjAxNC0zDQoNCklCSVMgU3VtbWl0czogDQotLS0t
LS0tLS0tLS0tDQpFTUMgbW9kZWwgZm9yIHByZWRpY3Rpb24gb2YgcGFyYXNpdGljIGVtaXNzaW9u
LCBFLlNpY2FyZCwgTWFyMjAwMQ0KRWxlY3Ryb21hZ25ldGljIENvbXBhdGliaWxpdHkgc2ltdWxh
dGlvbiBvZiBQcmludGVkIENpcmN1aXQgQm9hcmQsIE0uQ2hyaXN0aWFuLCBNYXIyMDAxDQpJQ0VN
IC0gUHJvcG9zYWwgSUVDNjIwMTQtMywgSi5DLlBlcnJpbiwgTWFyMjAwMQ0KQWR2YW5jZXMgb2Yg
dGhlIElDRU0gbW9kZWwgZm9yIEVtaXNzaW9uIG9mIEludGVncmF0ZWQgQ2lyY3VpdCwgUy5DYWx2
ZXQsIEphbjIwMDENCkFkZGluZyBPbi1DaGlwIENhcGFjaXRhbmNlIGluIElCSVMgRm9ybWF0IGZv
ciBTU08gU2ltdWxhdGlvbiwgUi5DaGVuLCBKYW4yMDA0DQpTaW11bHRhbmVvdXMgU3dpdGNoaW5n
IE5vaXNlKFNTTilNb2RlbGluZywgQi5VbmdlciBKYW4yMDAwDQpDcm9zc2Jhci1jdXJyZW50IG91
dCBvZiBDTU9TLUlCSVMtTW9kZWxzLCBLLktvbGxlciAmIEcuQmFubmVydCwgTWFyMjAwMg0KSUMt
RW1pdCBDb21wYXJpbmcgU2ltdWxhdGVkL01lYXN1cmVkIElDIEVtaXNzaW9uIFNwZWN0cnVtLCBF
LlNpY2FyZCAmIEEuU291YmV5cmFuIEZlYjIwMDQNCg0KKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
DQo=

- ------_=_NextPart_001_01C4EA4F.34D0DCBA--
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 28 Dec 2004 10:30:42 -0800
From: Syed Huq <shuq@cisco.com>
Subject: Re: [IBIS-Users] BIRD95: Power Integrity Analysis Using IBIS

Hi Matsui-san,

Thanks for your questions/comments on BIRD95. We are including our 
responses below. Pls feel free to let us know if you have more
questions.

Regards,
Syed-- 
IBIS Vice-Chair & Webmaster
Cisco Systems, Inc


On Sun, 2004-12-26 at 09:00, Mirmak, Michael wrote:
> Comments from Matsui-san on BIRD95.
>  
> - MM
> 
> ______________________________________________________________________
> From: matsui [mailto:matsui@apsimtech.com] 
> 
> My comments and thoughts on SSO and EMI models are below.
> 
>   1.  If I_bypass is described as a current source, it may not be
> right.
>        Series current source always feed the same current to out side.
>        I think the I_bypass and C_p+b may be in parallel. Or voltage 
> source 
>        is OK.  All current source models must have admittance or
> device models
>        in parallel.  The current waveforms will be varied by loads and
> admittance/
>        impedance of switching transistors. The admittance/impedance
> consists
>        of  linear power rails and nonlinear transistors.  I remember
> Arpad has 
>        presented nonlinear model of C_comp.

Cisco:(1)
I_bypass is not a current source. I_bypass simply represents current
that flows through the bypass components.


>   2.  There are two types of  core models.  One is shown in the bird.
>         The other (I think this is more popular) type of core logic is
> not connected
>         to I/O buffer.  I/O core logic may be connected to lower
> voltage sources 
>         with no I/O.

Cisco:(2)
We have internally discussed that I/O and core voltages can be different
and the pre-driver can be supplied with either.


>   3.  SSO needs time domain model.  EMI needs frequency domain model
> and time
>         domain model.  The frequency domain model means linearized
> model and it
>         is an approximation.  Current sources should be described in
> real and imaginary
>         parts at various frequencies.  The parallel admittance, if it
> is a macro model, may 
>         be approximated as real and imaginary parts at various
> frequencies. 
>        Time domain model of cores is more preferable for SSO and EMI,
> because 
>        switching transistors have strong non linearity.  Current
> source model is a kind of
>        linear approximation.  Current waveforms are results.  Constant
> external voltage 
>        sources are switched by nonlinear transistors.  Only current
> sources can't describe
>        load effects.  They need nonlinear admittance / impedance. 
> Transistor or behavioral
>        model may describe these effects.

Cisco:(3 and 6)
Again BIRD95 has no current sources. BIRD95 based simulations will have
more accurate EMI results than pre-BIRD95 simulations. However, BIRD95
is not specifically directed towards EMI simulations. EMI simulations
are best addressed with the ICEM model.


>  4.   How to simplify the models of power rails on a chip and a
> package is another 
>        serious issue.  Even for a package, number of die pads and
> balls for power/ground 
>        I/O.  ICM and SPICE may be OK, but too complex model with too
> many terminals are
>        not good for simulation.  
>  5.   All the core logic is connected to common power rails with some
> different DC levels
>        and the power/ground rails are connected to number of die pads
> and  package balls.
>        A figure of Bird 95 seems to consist of one I/O and one core
> logic. I think the starting
>        point may be  more realistic structures of an LSI chip.

Cisco:(4 and 5)
Common Spice package models are scaled down to a slice of the package
with a handful of drivers. It should be possible to scale the model down
to a single buffer.

>  6.   I think there is a big difference between SSO and EMI models.  A
> simple EMI simulation
>        does not need individual power I/O pin models. But accurate EMI
> simulation may not
>        accept this model.
> 
> Best Regards,
> Norio Matsui
> 
> 

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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, 29 Dec 2004 17:51:24 +0800
From: =?big5?B?QW5kcmV3X0NoaWVuXCjCsrFSpndcKQ==?= <Andrew_Chien@HTC.COM.TW>
Subject: [IBIS-Users] Basic questions about IBIS

Hi, experts,

    I am a hand-held device hardward engineer who just study IBIS simulation for serveral months.
    I have some basic questions:

1. Is it possible to simulate setup/hold time using IBIS model?
    I know that we can obtain the delay difference between "test load" and "trace", but I don't know whether it is possible to ask chip vendors to provide the "gate delay + test load" of each signal.

2. What item is the main purpose of signal integrity simulation works? Overshoot, ringback, transition time, or crosstalk?

3. Is measurement-based IBIS model more accurate that SPICE simulation-based IBIS model?
    One of our chip vendor said it, and we do obtain more accurate results from measurement-based IBIS model. However, they said that it takes 3-4 months to generate a measurement-based IBIS model, so they are not willing to generate the IBIS model of the other I/O buffers on the same device for us.
    Is it possible to generate an accurate enough IBIS model in a short time?

4. When we want to generate a measurement-based IBIS model How can we select the max, min, typ buffer strength chip?

5. In IBIS, the "max" curves are measured / simulated under the condition "maximum buffer strength + lowest temperature + largest voltage"
         and the "min" curves are measured / simulated under the condition "minimum buffer strength + highest temperature + smallest voltage".
    I think it is not sufficient to simulate the ringback: as I know the ringing caused  by maximum buffer strength is much larger the minimum buffer strength, but "smallest voltage - VIH" is smaller than "largest voltage - VIH", we cannot make sure whether the ringback margin is sufficient even if the simulation results of min and max passed. (Because the smallest ringback margin should be under the condition "maximum buffer strength + lowest temperature + smallest voltage")

6. Chip vendors usually set the largest and smallest voltage according to their maximum tolerance (for example 20%), however, the voltage error rate of our regulator is usually not so large.  So the worst cases in IBIS model are not the same with the worst cases in our PCBA.  Furthermore, sometimes the typical voltage we use is not the same with the original.  I would like to know whether there is a method to generate the IBIS model we need.

     Any help will be apreciated, Thanks in Advance.

Best regards
Andrew

CONFIDENTIALITY NOTE : The information in this e-mail is confidential and privileged; it is intended for use solely by the individual or entity named as the recipient hereof. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient is strictly prohibited and may violate applicable laws. If you have received this e-mail in error, please delete the original message and notify us by return email or collect call immediately. Thank you.   High Tech Computer Corporation

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <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 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, 29 Dec 2004 11:07:57 -0500
From: "Andrew Ingraham" <a.ingraham@ieee.org>
Subject: [IBIS-Users] Re: Basic questions about IBIS

>     I know that we can obtain the delay difference between "test load" and
> "trace", but I don't know whether it is possible to ask chip vendors to
> provide the "gate delay + test load" of each signal.

For chip outputs, gate delays should always be specified with the test load.
That's the purpose of the test load.  Check the data sheet; it should say
somewhere that output delays are specified with the load.


> 2. What item is the main purpose of signal integrity simulation works?
> Overshoot, ringback, transition time, or crosstalk?

Yes!  To all, and more.  :-)

I would not try to say which one of these is most important, because it
depends on the situation.


> 3. Is measurement-based IBIS model more accurate that SPICE
> simulation-based IBIS model?

That depends.

Obviously, a measurement-based model can accurately represent (one sample
of a) real device.  The SPICE model might or might not bear much similarity
to reality.  If not, then clearly the measurement-based model can be better.
It depends on the care that went into making the SPICE model, whether they
bothered to correlate it with measurements, etc.

The IBIS model should have min and max characteristics, but they might not
have sample parts of both extremes.  Thus, some extrapolation (based on best
guesses) may be required.  Of course the same is true of SPICE models too.

Measurement-based models tend to have some "noise" that may need to be
smoothed out.  A lot of fine noise in the tables can lead to odd behavior in
the simulator.

Many SPICE models are created from expectations of what the chip vendor
thinks he ought to get from his new process, and the targets can be wrong.

Plus, oftentimes there are difficulties extracting SPICE models from certain
structures (particularly in the I/O area), and it is easy to get a lousy
SPICE model; one that's totally missing the clamp devices, or has the wrong
drive strength, or whatever.

Depending on the frequencies of interest, it can take a lot of skill to
correctly measure and model the characteristics of the device.  This is one
area where a SPICE-derived model may have the advantage (assuming, of
course, that the SPICE model was good at those frequencies).


>     One of our chip vendor said it, and we do obtain more accurate results
> from measurement-based IBIS model. However, they said that it takes 3-4
> months to generate a measurement-based IBIS model, so they are not willing
> to generate the IBIS model of the other I/O buffers on the same device for
> us.
>     Is it possible to generate an accurate enough IBIS model in a short
> time?

Yes.

The 3-4 months includes the time to schedule the work, assign personnel and
equipment, get up to speed, some padding in case something goes wrong and
they need to start over, write up reports, etc.  They probably don't have
someone sitting around with nothing to do who can start on your devices
today.  Hence the extra time.


> 4. When we want to generate a measurement-based IBIS model How can we
> select the max, min, typ buffer strength chip?

You can adjust the supply voltages and perhaps the temperature when making
these measurements, but there's nothing YOU can do to represent a best-case
or worst-case chip from the fab.  The IC manufacturer can do this, but it's
not cheap.

Either you get samples that are certified by the vendor to represent the
likely extremes of the fab process, or you take samples, hope that they are
typical, and margin the curves by some amount.

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       <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 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, 30 Dec 2004 15:17:27 +0800
From: "Andrew_Chien\(???\)" <Andrew_Chien@HTC.COM.TW>
Subject: [IBIS-Users] RE: [IBIS] Re: Basic questions about IBIS

Dear Mr. Ingraham,

     Thanks so much for your kindly answer. You really give me an elaboration about me questions.

About 1, I should ask our chip vendor to fill out the "TBD" values in their specification.

About 3,
               A. So, chips are usually not made according to SPICE file; On the contrary, SPICE files are extracted from chip and guess. 
                    Thus, SPICE-derived IBIS model and encrypted SPICE model are not as accurate as measurement-based IBIS model. (except some situation)
               B. So, the extremes of SPICE-derived model are only expectations. And only if chip vendor spend a lot of money and  a lot of time to screen the extreme chips from manufacture process and then use a long time to measure it, we cannot get a accurate IBIS model.  I am afraid that the schedule of IBIS model is too slow to let us prevent SI problems in advance...
               C. If everything is optimized, how long will it usually take to generate a IBIS3.2 model of one I/O buffer?

About 4,
            A. I would like to know whether the influence from fab process is smaller than the influence from temperature and voltage or not.
                i.e. if chip vendors didn't spend their resource to select the typical and extreme chips, how much will the simulation result be influenced?
            B. For most IBIS model, the typical temperature is room temperature, however, for some chips (ex: CPU), the temperature is much higher than room temperature.
                 Is it reasonable to ask chip vendors to change the typical temperature.

Could you also give some comments to the rest two questions if it is conveniet for you? Thank you in advance.

Best regards
Andrew Chien

- -----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org]On Behalf Of Andrew Ingraham
Sent: Thursday, December 30, 2004 12:08 AM
To: ibis@eda.org; ibis-users@eda.org
Subject: [IBIS] Re: Basic questions about IBIS


>     I know that we can obtain the delay difference between "test load" and
> "trace", but I don't know whether it is possible to ask chip vendors to
> provide the "gate delay + test load" of each signal.

For chip outputs, gate delays should always be specified with the test load.
That's the purpose of the test load.  Check the data sheet; it should say
somewhere that output delays are specified with the load.


> 2. What item is the main purpose of signal integrity simulation works?
> Overshoot, ringback, transition time, or crosstalk?

Yes!  To all, and more.  :-)

I would not try to say which one of these is most important, because it
depends on the situation.


> 3. Is measurement-based IBIS model more accurate that SPICE
> simulation-based IBIS model?

That depends.

Obviously, a measurement-based model can accurately represent (one sample
of a) real device.  The SPICE model might or might not bear much similarity
to reality.  If not, then clearly the measurement-based model can be better.
It depends on the care that went into making the SPICE model, whether they
bothered to correlate it with measurements, etc.

The IBIS model should have min and max characteristics, but they might not
have sample parts of both extremes.  Thus, some extrapolation (based on best
guesses) may be required.  Of course the same is true of SPICE models too.

Measurement-based models tend to have some "noise" that may need to be
smoothed out.  A lot of fine noise in the tables can lead to odd behavior in
the simulator.

Many SPICE models are created from expectations of what the chip vendor
thinks he ought to get from his new process, and the targets can be wrong.

Plus, oftentimes there are difficulties extracting SPICE models from certain
structures (particularly in the I/O area), and it is easy to get a lousy
SPICE model; one that's totally missing the clamp devices, or has the wrong
drive strength, or whatever.

Depending on the frequencies of interest, it can take a lot of skill to
correctly measure and model the characteristics of the device.  This is one
area where a SPICE-derived model may have the advantage (assuming, of
course, that the SPICE model was good at those frequencies).


>     One of our chip vendor said it, and we do obtain more accurate results
> from measurement-based IBIS model. However, they said that it takes 3-4
> months to generate a measurement-based IBIS model, so they are not willing
> to generate the IBIS model of the other I/O buffers on the same device for
> us.
>     Is it possible to generate an accurate enough IBIS model in a short
> time?

Yes.

The 3-4 months includes the time to schedule the work, assign personnel and
equipment, get up to speed, some padding in case something goes wrong and
they need to start over, write up reports, etc.  They probably don't have
someone sitting around with nothing to do who can start on your devices
today.  Hence the extra time.


> 4. When we want to generate a measurement-based IBIS model How can we
> select the max, min, typ buffer strength chip?

You can adjust the supply voltages and perhaps the temperature when making
these measurements, but there's nothing YOU can do to represent a best-case
or worst-case chip from the fab.  The IC manufacturer can do this, but it's
not cheap.

Either you get samples that are certified by the vendor to represent the
likely extremes of the fab process, or you take samples, hope that they are
typical, and margin the curves by some amount.

Regards,
Andy



CONFIDENTIALITY NOTE : The information in this e-mail is confidential and privileged; it is intended for use solely by the individual or entity named as the recipient hereof. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient is strictly prohibited and may violate applicable laws. If you have received this e-mail in error, please delete the original message and notify us by return email or collect call immediately. Thank you.   High Tech Computer Corporation

|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <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 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, 30 Dec 2004 13:20:55 -0800
From: Syed Huq <shuq@cisco.com>
Subject: [Fwd: RE: [IBIS] Re: [IBIS-Users] BIRD95: Power Integrity Analysis Using IBIS]

Mike,

Our responses below to your questions. 
Happy Holidays,

Syed
- -- 
IBIS Vice-Chair & Webmaster
Cisco Systems, Inc

On Wed, 2004-12-29 at 08:33, Mike LaBonte wrote:
> BIRD95 reminds us of the difficulties associated with the current profile
> issue, but hopefully this time we can work it through to a conclusion. My
> comments:
> 
> 1) Norio Matsui may have raised the most important issue, the fact that
> there may not be exactly one bypass capacitor and one pre-driver section
> associated with one buffer, all sharing current from one supply. In fact
> this case seems quite unlikely. Scaling the total bypass capacitance,
> pre-driver current and output current for an arbitrary slice of a component
> down to one of it's buffers should a model that is likely not very accurate
> for any single buffer, or for any collection of buffers unless the
> collection happens to be equal to those in the slice. And a single current
> profile still doesn't solve the correct apportionment of current to paths
> from distinct power supply voltages.
> 

Cisco:
BIRD95 only addresses the case where the pre-driver and buffer share the
same power rail.
If a bypass capacitor is shared, it has to be scaled. Pre-driver and
output current need no scaling because they will be obtained from Spice
simulation of a single buffer. Since only one power rail is modeled, a
single current profile is sufficient.

Our proposal is mainly for the last stage of I/O power
supply which we called VDDQ.  The IvsT table is only associated with
VDDQ at this time.  For the VDDQ net within one I/O buffer, We didn't
see the need to seperate the currents go through the different bypass
capactiors or different pre-drive circuit.  One lumped current should be
good enough.

This brings up the point of how even a regular IBIS buffer model is to
be derived. Should the IBIS model be derived from Spice that includes a
bypass network or a perfect supply?

If a pre-driver is connected to core Vdd, it needs to be integrated into
the ICEM core current profile model.

> 2) Accepting for the moment that we are attempting to represent multiple
> current paths with a single table here, why not specify ground current
> instead of power current? Isn't it more likely that all of these currents
> flow through a single ground plane than through a single power plane?
> 

Cisco:
The reasons why we only provide the current from VDDQ not GND are: #1.
VDDQ noise is what we care for SSO simulation. #2.There could be other
power supplies with the I/O buffer, so the GND current is the
combination (in a certain degree) of the all power supplies current. It
is impossible to seperate the I_VDDQ from the total current when there
is only one IvsT table is provided.

> 3) Although the IBIS specification limits itself with regard to explaining
> how a simulator might use the data, I feel that some effort might be
> warranted here to advance the cause of consistency among simulators. For
> starters, should we have some words of wisdom explaining that the current
> out of the pad can be determined, and represents the difference between the
> current into the power supply (if there is only one) and out through ground
> (if there is only one). Digging deeper, how will the simulator decide how
> much of the current passing through ground is "crowbarred" through the
> pullup and pulldown, versus passing through the other current path formed by
> the bypass capacitors and pre-drivers? This has a bearing on the turn-on/off
> rates chosen for the pullup/pulldown. Mainly I would like to see some
> discussion of this from simulator people, to validate that the simulation
> outcome is deterministic. Even if there has been discussion already within
> the IBIS committee, it would be good to make a record in the IBIS
> specification for future implementers.
> 

Cisco:
For a majority of the cases, we think the simulator does not have to
know how much of the current is crowbar and how much is pre-driver.
If this becomes important it may have to be handled in a future
enhancement over BIRD95.

> 4) I think the text should clarify that positive values represent current
> flowing into the buffer.
> 

Cisco:
Agreed.

> 5) Although it may seem obvious, maybe the specification should clarify that
> in the case of open_XXX models, where current is supplied by the test
> fixture, that current is not to be accounted for in the [Series Composite
> Current].
> 

Cisco:
We should be able to do this.

> 6) What would the [Series Composite Current] profile look like for a
> differential output buffer? Presumably these must be taken as a pair, and
> the total current for the pair ideally remains nearly static. Should we
> require the measurements to be taken this way, or should we allow model
> makers to provide separate P and N models with different current profiles?
> 

Cisco:
If IBIS always models differential buffers as two single-ended ones, the
power modeling will do the same. If IBIS can handle true differential
buffer, we could add IvsT table for that case later. SSN impact with Diff
buffers may not be as significant compared to single-ended buffers.

> 7) The proposed [Series Composite Current] keyword associates itself with a
> preceding [XXX Waveform] keyword, and is thus position dependent. Some
> existing IBIS keywords are position dependent. For example, [Ramp] is part
> of a second level of hierarchy under [Model]. But I think [Series Composite
> Current] would be a third level of hierarchy, being under [XXX Waveform],
> which is under [Model]. Is this OK, or would it be better to simply add 3
> more columns to the [XXX Waveform] tables?
> 

Cisco:
We would prefer not to add 3 more colums to the [XXX Waveform] but we
are open to suggestions. This is more of a format/keyword placement
issue.

> 8) Can the [Series Composite Current] keyword follow only some [XXX
> Waveform] tables and not others?
> 

Cisco:
Yes. In the case of Open_Drain, some of the tables will no longer be
present.

> 9) The text describes [Series Composite Current] as current flowing through
> R_VDD, but the circuit diagram calls it R_VDDQ.
> 

Cisco:
We will fix this.

> 10) More nit picking: I had to modify the ASCII circuit diagram to make it
> line up right.
> 

Cisco:
Is this because of the width settings on your Email client. We can fix
any format issues.



|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 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 #48
************************