From owner-ibis  Tue Aug  3 12:21:55 1999
Received: from fairchild-bh.fairchildsemi.com (fairchild-bh.fairchildsemi.com [192.233.132.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA29956 for <ibis-users@eda.org>; Tue, 3 Aug 1999 12:21:54 -0700 (PDT)
Received: (from uucp@localhost) by fairchild-bh.fairchildsemi.com (8.8.8/8.6.11) id PAA16055 for <ibis-users@eda.org>; Tue, 3 Aug 1999 15:15:34 -0400 (EDT)
Received: from mailsort.fairchildsemi.com(172.21.18.6) by fairchild-bh.fairchildsemi.com via smap (4.1)
	id xma015454; Tue, 3 Aug 99 15:14:45 -0400
Received: from fmis02.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4)
	id PAA09793; Tue, 3 Aug 1999 15:12:29 -0400
Received: from spf.fairchildsemi.com (gconnolly-fm.fairchildsemi.com)
 by spf.fairchildsemi.com (PMDF V5.1-12 #24455)
 with ESMTP id <01JEC2VCEN7W94H211@spf.fairchildsemi.com> for
 ibis-users@eda.org; Tue, 3 Aug 1999 15:15:49 EDT
Date: Tue, 03 Aug 1999 15:15:07 -0400
From: Graham Connolly <graham@spf.fairchildsemi.com>
Subject: IBIS 3.2 Generation tool
To: ibis-users@eda.org
Reply-to: Graham.Connolly@fairchildsemi.com
Message-id: <37A73FBB.D56C440B@spf.fairchildsemi.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en

I am new to IBIS and IBIS model generation and am beginning to use the
NCSU SPICE to IBIS and Hyperlinx tools for validation.

I am looking for information on generating Spice to IBIS for Bus
Switches as covered in IBIS Rev 3.2. Is there a tool out there ? Which
vendor supports such generation? Is the user group looking for funding
to generate the code (NCSU?)


Thank You for assistance

Please advise




Graham Connolly
Fairchild Semiconductor
Applications and Modelling
207-775-4579

From owner-ibis  Fri Aug  6 11:59:16 1999
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA15632 for <ibis-users@eda.org>; Fri, 6 Aug 1999 11:59:16 -0700 (PDT)
Received: from zrtpd004.us.nortel.com (actually nrtpd004) 
          by smtprch1.nortel.com; Fri, 6 Aug 1999 13:45:20 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <QG4L0SWJ>; Fri, 6 Aug 1999 14:52:45 -0400
Message-ID: <FFC64EEE212BD21197690000F80824BED8E3B9@zcrkp000.ca.nortel.com>
From: "Joe Lee" <joelee@nortelnetworks.com>
To: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: Clarification on message from s2ibis2
Date: Fri, 6 Aug 1999 14:52:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
X-Orig: <joelee@americasm01.nt.com>

I am running s2ibis2 on a Sun Solaris Ultra5.
The .spi files, .out and .listing files are created.
No errors are received from the hspice simulator.

I get the following message from s2ibis:
s2ibis2: Data begin marker analysis not found in output file 'filename'.out.

The contents of the .out files are all the same:
--- Starting the script:
	'/pathname to hspice executable'

--- Executing the command:
	hspice 'filename'.spi

--- Exiting the script


As a result the IBIS file contains no data.

What is the problem?

Regards		              Joe  Lee                        Nortel
Networks
----------------------------------------------------------------------------
------
email:  joelee@nortelnetworks.com	       VOICE:  (613) 763-5916
PCP Design Analysis & Verification Prime            FAX:  (613) 763-7241
LAND:P.O.Box 3511,Station C,MS 040 Crk,Ottawa,Canada, K1Y 4H7
   	     Opinions expressed by me are mine.

From owner-ibis  Fri Aug  6 12:09:58 1999
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA15652 for <ibis-users@eda.org>; Fri, 6 Aug 1999 12:09:58 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Fri, 6 Aug 1999 13:55:51 -0500
Received: from zcrkp000.ca.nortel.com ([47.69.128.85]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id P2BGSQPF; Fri, 6 Aug 1999 15:03:17 -0400
Received: from americasm01.nt.com (pcard2wk.ca.nortel.com [47.14.98.206]) 
          by zcrkp000.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id PKGFS6WV; Fri, 6 Aug 1999 15:03:17 -0400
Message-ID: <37AB309A.5FDB9AD1@americasm01.nt.com>
Date: Fri, 06 Aug 1999 14:59:38 -0400
From: mgl7@nt.com
Reply-To: MGL7@nortelnetworks.com
Organization: Nortel Networks
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: ibis-users@eda.org
Subject: Clarification on message from s2ibis2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <joelee@americasm01.nt.com>

I am running s2ibis2 on a Sun Solaris Ultra5.
The .spi files, .out and .listing files are created.
No errors are received from the hspice simulator.

I get the following message from s2ibis:
s2ibis2: Data begin marker analysis not found in output file
'filename'.out.

The contents of the .out files are all the same:
--- Starting the script:
	'/pathname to hspice executable'

--- Executing the command:
	hspice 'filename'.spi

--- Exiting the script


As a result the IBIS file contains no data.

What is the problem?

Regards Joe Lee
email:	joelee@nortelnetworks.com
From owner-ibis  Fri Aug  6 22:56:38 1999
Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id WAA16665 for <ibis-users@eda.org>; Fri, 6 Aug 1999 22:56:38 -0700 (PDT)
Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id WAA00284 for <ibis-users@eda.org>; Fri, 6 Aug 1999 22:50:20 -0700 (PDT)
Received: from zip.Cadence.COM(158.140.103.36) by mailgate.cadence.com via smap (mjr-v1.2)
	id xma934005018.000281; Fri, 6 Aug 99 22:50:19 -0700
Received: from cadence.com (annex-ch-02 [158.140.103.202]) by zip.Cadence.COM (8.7.3/8.7.3) with ESMTP id BAA28886 for <ibis-users@eda.org>; Sat, 7 Aug 1999 01:50:16 -0400 (EDT)
Message-ID: <37ABC86D.8CA3F528@cadence.com>
Date: Sat, 07 Aug 1999 01:47:25 -0400
From: Mike LaBonte <mikelabonte@cadence.com>
Organization: Cadence Design Systems
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: Re: Clarification on message from s2ibis2
References: <FFC64EEE212BD21197690000F80824BED8E3B9@zcrkp000.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

s2ibis is looking for the word 'analysis' in the output file, and is not finding
it. The s2ibis program provides directives to make hspice produce the correct
type of output. Make sure your your input deck does not have directives that
might be altering how output is produced. The correct output from hspice usually
has a header, a copy of the input deck, and then something like:

 ******  transient analysis               tnom=  25.000 temp=  50.000 ******
x

       time    voltage
                   out
   0.          1.200e+00
 2.0000e-10    1.200e+00
 4.0000e-10    1.199e+00
...

Mike

Joe Lee wrote:
> 
> I am running s2ibis2 on a Sun Solaris Ultra5.
> The .spi files, .out and .listing files are created.
> No errors are received from the hspice simulator.
> 
> I get the following message from s2ibis:
> s2ibis2: Data begin marker analysis not found in output file 'filename'.out.
> 
> The contents of the .out files are all the same:
> --- Starting the script:
>         '/pathname to hspice executable'
> 
> --- Executing the command:
>         hspice 'filename'.spi
> 
> --- Exiting the script
> 
> As a result the IBIS file contains no data.
> 
> What is the problem?
> 
> Regards                       Joe  Lee                        Nortel
> Networks
> ----------------------------------------------------------------------------
> ------
> email:  joelee@nortelnetworks.com              VOICE:  (613) 763-5916
> PCP Design Analysis & Verification Prime            FAX:  (613) 763-7241
> LAND:P.O.Box 3511,Station C,MS 040 Crk,Ottawa,Canada, K1Y 4H7
>              Opinions expressed by me are mine.
From owner-ibis  Mon Aug  9 16:58:14 1999
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA27752 for <ibis-users@eda.org>; Mon, 9 Aug 1999 16:58:13 -0700 (PDT)
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63])
	by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA01787;
	Mon, 9 Aug 1999 16:51:23 -0700 (PDT)
Message-Id: <199908092351.QAA01787@jasper.cisco.com>
Date: Mon, 9 Aug 1999 16:51:23 -0700 (PDT)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: Re: Clarification on message from s2ibis2
To: ibis-users@eda.org, joelee@nortelnetworks.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: obBNeFqqKgA7QSJCNgUpmw==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc 

Joe,

I ran into this error message long time ago. Basically when you get
a 'Data begin marker' error, it means the script was unable to find
some of the files you have mentioned in the header file(.s2i).

Check the syntax of this s2i file wherever you mentioned any filenames.

For a quick test, run the example files and see if you get this
same error.

Regards,
Syed
Cisco Systems, Inc

> X-SMAP-Received-From: outside
> From: "Joe Lee" <joelee@nortelnetworks.com>
> To: "'ibis-users@eda.org'" <ibis-users@eda.org>
> Subject: Clarification on message from s2ibis2
> Date: Fri, 6 Aug 1999 14:52:31 -0400
> MIME-Version: 1.0
> X-Orig: <joelee@americasm01.nt.com>
> 
> I am running s2ibis2 on a Sun Solaris Ultra5.
> The .spi files, .out and .listing files are created.
> No errors are received from the hspice simulator.
> 
> I get the following message from s2ibis:
> s2ibis2: Data begin marker analysis not found in output file 'filename'.out.
> 
> The contents of the .out files are all the same:
> --- Starting the script:
> 	'/pathname to hspice executable'
> 
> --- Executing the command:
> 	hspice 'filename'.spi
> 
> --- Exiting the script
> 
> 
> As a result the IBIS file contains no data.
> 
> What is the problem?
> 
> Regards		              Joe  Lee                        Nortel
> Networks
> ----------------------------------------------------------------------------
> ------
> email:  joelee@nortelnetworks.com	       VOICE:  (613) 763-5916
> PCP Design Analysis & Verification Prime            FAX:  (613) 763-7241
> LAND:P.O.Box 3511,Station C,MS 040 Crk,Ottawa,Canada, K1Y 4H7
>    	     Opinions expressed by me are mine.
> 

From owner-ibis  Mon Aug  9 17:37:51 1999
Received: from stellar-g.actel.com (stellar-g.actel.com [204.33.72.20]) by server.eda.org (8.8.5/8.8.3) with SMTP id RAA27871 for <ibis-users@eda.org>; Mon, 9 Aug 1999 17:37:51 -0700 (PDT)
Received: from sv-gw-02.amer.actel.com by stellar-g.actel.com (SMI-8.6/SMI-SVR4)
	id RAA13327; Mon, 9 Aug 1999 17:30:58 -0700
Received: by sv-gw-02.amer.actel.com with Internet Mail Service (5.5.2448.0)
	id <3ZJDMW4Y>; Mon, 9 Aug 1999 17:31:01 -0700
Message-ID: <D03DC0494403D1118AB500A02461E68702E16CF2@sv-msg-01.amer.actel.com>
From: "Montoya, Silvia" <Silvia.Montoya@actel.com>
To: ibis-users@eda.org
Cc: "Montoya, Silvia" <Silvia.Montoya@actel.com>
Subject: RE: Rload
Date: Mon, 9 Aug 1999 17:30:50 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

Hello IBIS modelers and Users.

  I am trying to determine what value to use for Rload.  The default value
is 50 ohms according to the IBIS spec.  
  Why was this value choosen as the default value ?
  Is anyone using a different value and why ?

 Thanks for your input !

  Silvia Montoya      silvia.montoya@actel.com

  

From owner-ibis  Mon Aug  9 17:55:02 1999
Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA27929 for <ibis-users@eda.org>; Mon, 9 Aug 1999 17:55:02 -0700 (PDT)
Received: (from smtp@localhost)
	by osiris.vlsi.com (8.9.1a/8.9.1) id RAA14761
	for <ibis-users@eda.org>; Mon, 9 Aug 1999 17:48:11 -0700 (PDT)
X-Authentication-Warning: osiris.vlsi.com: smtp set sender to <dc.sessions@vlsi.com> using -f
Received: from <dc.sessions@vlsi.com> (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris.vlsi.com via smap (V2.0)
	id xma014753; Mon, 9 Aug 99 17:48:01 -0700
Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id Q1NCKPX3; Mon, 9 Aug 1999 17:48:00 -0700
Sender: dsession@osiris.vlsi.com
Message-ID: <37AF76C0.7A187197@vlsi.com>
Date: Mon, 09 Aug 1999 17:48:00 -0700
From: "D. C. Sessions" <dc.sessions@vlsi.com>
Organization: VLSI Technology Inc.
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis-users@eda.org
CC: ibis-users@eda.org
Subject: Re: Rload
References: <D03DC0494403D1118AB500A02461E68702E16CF2@sv-msg-01.amer.actel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Montoya, Silvia" wrote:
> 
> Hello IBIS modelers and Users.
> 
>   I am trying to determine what value to use for Rload.  The default value
> is 50 ohms according to the IBIS spec.
>   Why was this value choosen as the default value ?
>   Is anyone using a different value and why ?

Rload needs to be small enough to show the driver reaching full current
(ie you don't learn much about the ramp up to 30 mA if you have a 1500
ohm Rload on a 3.3v part).

Rload also needs to be large enough to have a reasonable swing (1 ohm
Rload doesn't wiggle much when you hit it with 4 mA).

Because of the second-order effects (capacitive parasitic feedback from
the output to the predriver) the best accuracy will come from an Rload
near to the actual impedance seen by the driver.  For a reflected-wave
driver this would be Z0.  Another way to look at it is that the terminal
values for the typical VT table should be close to half of supply, which
keeps the min and max from violating the "too small" and "too large"
guidelines.

For most systems this comes to somewhere near 50 ohms, but don't obsess
about it.

-- 
D. C. Sessions
dc.sessions@vlsi.com
From owner-ibis  Tue Aug 10 08:29:14 1999
Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA01325; Tue, 10 Aug 1999 08:29:13 -0700 (PDT)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id IAA25137;
	Tue, 10 Aug 1999 08:22:53 -0700 (PDT)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id IAA16712;
	Tue, 10 Aug 1999 08:22:52 -0700 (PDT)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id IAA04758;
	Tue, 10 Aug 1999 08:22:52 -0700 (PDT)
Message-Id: <199908101522.IAA04758@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: ibis@eda.org, ibis-users@eda.org
Subject: BIRD #61 -- Characterization of Receivers
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 10 Aug 1999 08:22:51 -0700
From: Stephen Peters <sjpeters@ichips.intel.com>


Hello All:

   Following is the first in a series of BIRDS that aim to enhance
IBIS's ability to specifying and characterizing receivers.  Comments
appreciated.

   Regards,
   Stephen Peters
   Intel Corp.

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


                 Buffer Issue Resolution Document  (BIRD)


BIRD ID#:   61
ISSUE TITLE: Enhanced Characterization of Receivers
REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters,
           Arpad Muranyi (Intel Corp)
DATE SUBMITTED: August 9, 1999
DATE ACCEPTED BY IBIS OPEN FORUM: 

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

STATEMENT OF THE ISSUE:  The current specification allows the user to 
describe the static Vinh and Vinl thresholds of a receiver.  However, these
parameters specify only the DC input thresholds at which the output of 
a receiver switches state.  They do not describe a digital logic receiver's
dynamic performance.  Dynamic performance includes such items as how a
device's setup or hold time varies with input overdrive, or how a receiver
behaves when an input waveform rings back into the area between Vinh and
Vinl.  In addition, the current specification does not support simulation
methodologies that rely on specifying the total delay from the input of an
output buffer to the output of the receiver.  This bird offers a way for the
user to specify a receiver's propagation delay and dynamic characteristics in
enough detail so that a simulation tool can model a receiver's response to
any arbitrary waveform.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:  

1) The following new keyword is defined, and is placed in the
specification just below the [Rising Waveform] and [Falling Waveform]
keyword descriptions

|=============================================================================
|      Keyword: [Receiver Delay]
|     Required: No
|   Sub-Params: Start_point, End_point, Slope
|  Description: This keyword specifies how the propagation delay of an 
|               input receiver varies as a function of input overdrive or 
|               input waveform slope.  
|
|  Usage Rules: The [Receiver Delay] keyword is followed immediately by the 
|               three subparameter names and their arguments. The Start_point
|               and End_point subparameters define the starting and ending 
|               voltage points of a linear ramp while the Slope parameter 
|               specifies the slope of that ramp.  Slope is given in units of 
|               volts per second (V/S).  All three subparameters are required.
|
|               Subparameter Usage:
|               The intent of the subparameters is to specify a set of linear 
|               ramps that vary only in starting point, ending point, or 
|               slope.  Therefore, when assigning values to the subparameters,
|               two of the three subparameters must be assigned fixed values,
|               while the third subparameter uses as its argument the reserved 
|               word TABLE.  The use of the word TABLE indicates that this 
|               subparameter is the independent variable in the associated 
|               receiver delay table.  The subparameter that uses the TABLE 
|               argument must appear after the other two subparameters and 
|               before the receiver delay table.  
|
|               Numerical arguments are separated from their associated
|               subparameter by an equals sign (=); white space around the 
|               equals sign is optional.  The TABLE argument is separate
|               from its associated subparameter by white space.
|
|               Receiver Delay Table:
|               Following the subparameters is the receiver delay table itself.
|               This table consists of four columns.  The first column lists
|               either the starting voltage, ending voltage or slope of the
|               linear ramp (i.e. the independent variable) as determined by 
|               the subparameter with the TABLE argument. The second thru
|               fourth columns list the change in the receiver's propagation
|               delay. This "change in delay" is relative to the receiver's
|               delay when it is stimulated using the same overdrive and edge
|               rate conditions used to specify the device's setup and hold
|               times.  The delay columns are arranged in the standard typ, 
|               min, max format.  All four entries must be placed on the same
|               line and must be separated by at least one white space.  All
|               four columns are required.  However, data is required only for
|               the typical column. If minimum or maximum data is not available
|               use the reserved word NA.  Each receiver delay table is limited
|               to 100 rows and only one receiver delay table is allowed per
|               [Receiver Delay] keyword.  However, there are no restrictions
|               on the number of [Receiver Delay] keywords per [Model] keyword.
|               Note that the [Receiver Delay] keyword is not allowed unless
|               the Model_type of the [Model] is one of the Input or I/O
|               models types.
|
|               Use of INF as a Receiver Delay:
|               When building a receiver delay table the user may specify an 
|               input condition that does not result in the receiver's output 
|               changing state.  In that case, the receiver delay is considered
|               infinite, and the reserved word INF is used in the delay
|               column.  See the examples below.
|               
|               Other Notes:
|               It is expected that the user will provide enough [Receiver
|               Delay] keywords (i.e. characterization data) to allow a CAE 
|               tool to build a model of the input receiver.  It is expected
|               that at least four [Receiver Delay] keywords will be required;
|               two low to high going ramps and two high to low going ramps.
|               However, the exact number of ramps and there content is up
|               to the user and recommendations provided by the various
|               simulation vendors.
|
| An example table showing how receiver delay varies vs. overdrive.
| Note the use of the reserved word INF.
|
[Receiver Delay]
Start_point = 0.8v
Slope = 1v/1ns
End_point  TABLE
|variable      typ     min    max
1.4            INF     7.0ns  INF
1.5            INF     5.0ns  INF
1.51           INF     3.0ns  10.0ns
1.53           7.0ns   0.0ns  7.0ns
1.55           2.0ns   0.0ns  1.0ns
1.6            0.0ns   0.0ns  0.0ns
1.7            0.0ns   0.0ns  0.0ns
2.0            0.0ns   0.0ns  0.0ns
2.1            0.1ns   0.1ns  0.1ns
2.5           -0.2ns  -0.1ns -0.5ns
|
| A second table that characterizes receiver delay vs. the slope of the
| input waveform.
|
[Receiver Delay]
Start_point = 0.8v
End_point = 2.0v
Slope  TABLE
|variable      typ     min    max
0.05/1ns      -1.0   -3.5    -1.0
0.25/1ns      -0.75  -2.0    -0.05
0.50/1ns      -0.01  -0.5    -0.0
0.60/1ns       0.0    0.25    0.0
0.75/1ns       0.0    0.0     0.0
1.00/1ns       0.0    0.0     0.0
2.00/1ns      +0.5   +0.2    +1.0
|
|
|2)  Item 2 under General Syntax Rules and Guidelines is modified to include
|the following reserved words

   INF   - used when a data value is so large it is considered infinite
   TABLE - used to indicate that a subparameter's value(s) are part of a
           table.
*******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:  This bird originated from
discussions held at the January '99 IBIS summit regarding the lack of a
way to accurately and realistically specify the input thresholds and 
dynamic performance of a digital logic receiver.  At the mid year '99 IBIS
summit D.C. Sessions, Stephen Peters, Richard Mellitz and Arpad Muranyi
agreed to meet to hammer out a proposal.  This bird is one of the results.
The technical basis of this bird derives from simulation work done by
Richard Mellitz.

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

ANY OTHER BACKGROUND INFORMATION:



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




From owner-ibis  Tue Aug 10 10:35:24 1999
Received: from web125.yahoomail.com (web125.yahoomail.com [205.180.60.193]) by server.eda.org (8.8.5/8.8.3) with SMTP id KAA01631 for <ibis-users@eda.org>; Tue, 10 Aug 1999 10:35:22 -0700 (PDT)
Message-ID: <19990810173012.26175.rocketmail@web125.yahoomail.com>
Received: from [209.67.236.48] by web125.yahoomail.com; Tue, 10 Aug 1999 10:30:12 PDT
Date: Tue, 10 Aug 1999 10:30:12 -0700 (PDT)
From: "C. Kumar" <kumarchi@yahoo.com>
Subject: Re: BIRD #61 -- Characterization of Receivers
To: ibis@eda.org
Cc: ibis-users@eda.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Simulators are not designed for  slope evaluation. The calculated slope
at any time can have substantial errors even though the overall
voltage/current changes will be accurate. 

Tables which depend on slope are asking for trouble. 

--- "D. C. Sessions" <dc.sessions@vlsi.com> wrote:
> Stephen Peters wrote:
> > 
> > Hello All:
> > 
> >    Following is the first in a series of BIRDS
> that aim to enhance
> > IBIS's ability to specifying and characterizing
> receivers.  Comments
> > appreciated.
> 
> Clarification:
> Because these sections are totally meaningless
> without the Vmeas
> parameter, all of the voltages specified are to be
> considered relative
> to Vmeas (or at least that's the way I remember it.)
> 
> That breaks the examples, but I think we can deal
> with that.
> 
> > ===================================
> > 
> >                  Buffer Issue Resolution Document 
> (BIRD)
> > 
> > BIRD ID#:   61
> > ISSUE TITLE: Enhanced Characterization of
> Receivers
> > REQUESTOR: D.C Sessions (Philips), Richard
> Mellitz, Stephen Peters,
> >            Arpad Muranyi (Intel Corp)
> > DATE SUBMITTED: August 9, 1999
> > DATE ACCEPTED BY IBIS OPEN FORUM:
> > 
> >
>
*******************************************************************************
> >
>
*******************************************************************************
> > 
> > STATEMENT OF THE ISSUE:  The current specification
> allows the user to
> > describe the static Vinh and Vinl thresholds of a
> receiver.  However, these
> > parameters specify only the DC input thresholds at
> which the output of
> > a receiver switches state.  They do not describe a
> digital logic receiver's
> > dynamic performance.  Dynamic performance includes
> such items as how a
> > device's setup or hold time varies with input
> overdrive, or how a receiver
> > behaves when an input waveform rings back into the
> area between Vinh and
> > Vinl.  In addition, the current specification does
> not support simulation
> > methodologies that rely on specifying the total
> delay from the input of an
> > output buffer to the output of the receiver.  This
> bird offers a way for the
> > user to specify a receiver's propagation delay and
> dynamic characteristics in
> > enough detail so that a simulation tool can model
> a receiver's response to
> > any arbitrary waveform.
> > 
> >
>
*******************************************************************************
> > 
> > STATEMENT OF THE RESOLVED SPECIFICATIONS:
> > 
> > 1) The following new keyword is defined, and is
> placed in the
> > specification just below the [Rising Waveform] and
> [Falling Waveform]
> > keyword descriptions
> > 
> >
>
|=============================================================================
> > |      Keyword: [Receiver Delay]
> > |     Required: No
> > |   Sub-Params: Start_point, End_point, Slope
> > |  Description: This keyword specifies how the
> propagation delay of an
> > |               input receiver varies as a
> function of input overdrive or
> > |               input waveform slope.
> > |
> > |  Usage Rules: The [Receiver Delay] keyword is
> followed immediately by the
> > |               three subparameter names and their
> arguments. The Start_point
> > |               and End_point subparameters define
> the starting and ending
> > |               voltage points of a linear ramp
> while the Slope parameter
> > |               specifies the slope of that ramp. 
> Slope is given in units of
> > |               volts per second (V/S).  All three
> subparameters are required.
> > |
> > |               Subparameter Usage:
> > |               The intent of the subparameters is
> to specify a set of linear
> > |               ramps that vary only in starting
> point, ending point, or
> > |               slope.  Therefore, when assigning
> values to the subparameters,
> > |               two of the three subparameters
> must be assigned fixed values,
> > |               while the third subparameter uses
> as its argument the reserved
> > |               word TABLE.  The use of the word
> TABLE indicates that this
> > |               subparameter is the independent
> variable in the associated
> > |               receiver delay table.  The
> subparameter that uses the TABLE
> > |               argument must appear after the
> other two subparameters and
> > |               before the receiver delay table.
> > |
> > |               Numerical arguments are separated
> from their associated
> > |               subparameter by an equals sign
> (=); white space around the
> > |               equals sign is optional.  The
> TABLE argument is separate
> > |               from its associated subparameter
> by white space.
> > |
> > |               Receiver Delay Table:
> > |               Following the subparameters is the
> receiver delay table itself.
> > |               This table consists of four
> columns.  The first column lists
> > |               either the starting voltage,
> ending voltage or slope of the
> > |               linear ramp (i.e. the independent
> variable) as determined by
> > |               the subparameter with the TABLE
> argument. The second thru
> > |               fourth columns list the change in
> the receiver's propagation
> > |               delay. This "change in delay" is
> relative to the receiver's
> > |               delay when it is stimulated using
> the same overdrive and edge
> > |               rate conditions used to specify
> the device's setup and hold
> > |               times.  The delay columns are
> arranged in the standard typ,
> > |               min, max format.  All four entries
> must be placed on the same
> > |               line and must be separated by at
> least one white space.  All
> > |               four columns are required. 
> However, data is required only for
> > |               the typical column. If minimum or
> maximum data is not available
> > |               use the reserved word NA.  Each
> receiver delay table is limited
> > |               to 100 rows and only one receiver
> delay table is allowed per
> > |               [Receiver Delay] keyword. 
> However, there are no restrictions
> > |               on the number of [Receiver Delay]
> keywords per [Model] keyword.
> > |               Note that the [Receiver Delay]
> keyword is not allowed unless
> > |               the Model_type of the [Model] is
> one of the Input or I/O
> > |               models types.
> > |
> > |               Use of INF as a Receiver Delay:
> > |               When building a receiver delay
> table the user may specify an
> > |               input condition that does not
> result in the receiver's output
> > |               changing state.  In that case, the
> receiver delay is considered
> > |               infinite, and the reserved word
> INF is used in the delay
> > |               column.  See the examples below.
> > |
> > |               Other Notes:
> > |               It is expected that the user will
> provide enough [Receiver
> > |               Delay] keywords (i.e.
> characterization data) to allow a CAE
> > |               tool to build a model of the input
> receiver.  It is expected
> > |               that at least four [Receiver
> Delay] keywords will be required;
> > |               two low to high going ramps and
> two high to low going ramps.
> > |               However, the exact number of ramps
> and there content is up
> > |               to the user and recommendations
> provided by the various
> > |               simulation vendors.
> > |
> 
=== message truncated ===

_____________________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

From owner-ibis  Tue Aug 10 09:49:50 1999
Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA01538; Tue, 10 Aug 1999 09:49:50 -0700 (PDT)
Received: (from smtp@localhost)
	by osiris.vlsi.com (8.9.1a/8.9.1) id JAA24575;
	Tue, 10 Aug 1999 09:42:55 -0700 (PDT)
X-Authentication-Warning: osiris.vlsi.com: smtp set sender to <dc.sessions@vlsi.com> using -f
Received: from <dc.sessions@vlsi.com> (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris.vlsi.com via smap (V2.0)
	id xma024566; Tue, 10 Aug 99 09:42:26 -0700
Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id Q1NCKQHF; Tue, 10 Aug 1999 09:42:25 -0700
Sender: dsession@osiris.vlsi.com
Message-ID: <37B05671.78DF6ECC@vlsi.com>
Date: Tue, 10 Aug 1999 09:42:25 -0700
From: "D. C. Sessions" <dc.sessions@vlsi.com>
Organization: VLSI Technology Inc.
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Peters <sjpeters@ichips.intel.com>
CC: ibis@eda.org, ibis-users@eda.org
Subject: Re: BIRD #61 -- Characterization of Receivers
References: <199908101522.IAA04758@xtg801.pdx.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Peters wrote:
> 
> Hello All:
> 
>    Following is the first in a series of BIRDS that aim to enhance
> IBIS's ability to specifying and characterizing receivers.  Comments
> appreciated.

Clarification:
Because these sections are totally meaningless without the Vmeas
parameter, all of the voltages specified are to be considered relative
to Vmeas (or at least that's the way I remember it.)

That breaks the examples, but I think we can deal with that.

> ===================================
> 
>                  Buffer Issue Resolution Document  (BIRD)
> 
> BIRD ID#:   61
> ISSUE TITLE: Enhanced Characterization of Receivers
> REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters,
>            Arpad Muranyi (Intel Corp)
> DATE SUBMITTED: August 9, 1999
> DATE ACCEPTED BY IBIS OPEN FORUM:
> 
> *******************************************************************************
> *******************************************************************************
> 
> STATEMENT OF THE ISSUE:  The current specification allows the user to
> describe the static Vinh and Vinl thresholds of a receiver.  However, these
> parameters specify only the DC input thresholds at which the output of
> a receiver switches state.  They do not describe a digital logic receiver's
> dynamic performance.  Dynamic performance includes such items as how a
> device's setup or hold time varies with input overdrive, or how a receiver
> behaves when an input waveform rings back into the area between Vinh and
> Vinl.  In addition, the current specification does not support simulation
> methodologies that rely on specifying the total delay from the input of an
> output buffer to the output of the receiver.  This bird offers a way for the
> user to specify a receiver's propagation delay and dynamic characteristics in
> enough detail so that a simulation tool can model a receiver's response to
> any arbitrary waveform.
> 
> *******************************************************************************
> 
> STATEMENT OF THE RESOLVED SPECIFICATIONS:
> 
> 1) The following new keyword is defined, and is placed in the
> specification just below the [Rising Waveform] and [Falling Waveform]
> keyword descriptions
> 
> |=============================================================================
> |      Keyword: [Receiver Delay]
> |     Required: No
> |   Sub-Params: Start_point, End_point, Slope
> |  Description: This keyword specifies how the propagation delay of an
> |               input receiver varies as a function of input overdrive or
> |               input waveform slope.
> |
> |  Usage Rules: The [Receiver Delay] keyword is followed immediately by the
> |               three subparameter names and their arguments. The Start_point
> |               and End_point subparameters define the starting and ending
> |               voltage points of a linear ramp while the Slope parameter
> |               specifies the slope of that ramp.  Slope is given in units of
> |               volts per second (V/S).  All three subparameters are required.
> |
> |               Subparameter Usage:
> |               The intent of the subparameters is to specify a set of linear
> |               ramps that vary only in starting point, ending point, or
> |               slope.  Therefore, when assigning values to the subparameters,
> |               two of the three subparameters must be assigned fixed values,
> |               while the third subparameter uses as its argument the reserved
> |               word TABLE.  The use of the word TABLE indicates that this
> |               subparameter is the independent variable in the associated
> |               receiver delay table.  The subparameter that uses the TABLE
> |               argument must appear after the other two subparameters and
> |               before the receiver delay table.
> |
> |               Numerical arguments are separated from their associated
> |               subparameter by an equals sign (=); white space around the
> |               equals sign is optional.  The TABLE argument is separate
> |               from its associated subparameter by white space.
> |
> |               Receiver Delay Table:
> |               Following the subparameters is the receiver delay table itself.
> |               This table consists of four columns.  The first column lists
> |               either the starting voltage, ending voltage or slope of the
> |               linear ramp (i.e. the independent variable) as determined by
> |               the subparameter with the TABLE argument. The second thru
> |               fourth columns list the change in the receiver's propagation
> |               delay. This "change in delay" is relative to the receiver's
> |               delay when it is stimulated using the same overdrive and edge
> |               rate conditions used to specify the device's setup and hold
> |               times.  The delay columns are arranged in the standard typ,
> |               min, max format.  All four entries must be placed on the same
> |               line and must be separated by at least one white space.  All
> |               four columns are required.  However, data is required only for
> |               the typical column. If minimum or maximum data is not available
> |               use the reserved word NA.  Each receiver delay table is limited
> |               to 100 rows and only one receiver delay table is allowed per
> |               [Receiver Delay] keyword.  However, there are no restrictions
> |               on the number of [Receiver Delay] keywords per [Model] keyword.
> |               Note that the [Receiver Delay] keyword is not allowed unless
> |               the Model_type of the [Model] is one of the Input or I/O
> |               models types.
> |
> |               Use of INF as a Receiver Delay:
> |               When building a receiver delay table the user may specify an
> |               input condition that does not result in the receiver's output
> |               changing state.  In that case, the receiver delay is considered
> |               infinite, and the reserved word INF is used in the delay
> |               column.  See the examples below.
> |
> |               Other Notes:
> |               It is expected that the user will provide enough [Receiver
> |               Delay] keywords (i.e. characterization data) to allow a CAE
> |               tool to build a model of the input receiver.  It is expected
> |               that at least four [Receiver Delay] keywords will be required;
> |               two low to high going ramps and two high to low going ramps.
> |               However, the exact number of ramps and there content is up
> |               to the user and recommendations provided by the various
> |               simulation vendors.
> |
> | An example table showing how receiver delay varies vs. overdrive.
> | Note the use of the reserved word INF.
> |
> [Receiver Delay]
> Start_point = 0.8v
> Slope = 1v/1ns
> End_point  TABLE
> |variable      typ     min    max
> 1.4            INF     7.0ns  INF
> 1.5            INF     5.0ns  INF
> 1.51           INF     3.0ns  10.0ns
> 1.53           7.0ns   0.0ns  7.0ns
> 1.55           2.0ns   0.0ns  1.0ns
> 1.6            0.0ns   0.0ns  0.0ns
> 1.7            0.0ns   0.0ns  0.0ns
> 2.0            0.0ns   0.0ns  0.0ns
> 2.1            0.1ns   0.1ns  0.1ns
> 2.5           -0.2ns  -0.1ns -0.5ns
> |
> | A second table that characterizes receiver delay vs. the slope of the
> | input waveform.
> |
> [Receiver Delay]
> Start_point = 0.8v
> End_point = 2.0v
> Slope  TABLE
> |variable      typ     min    max
> 0.05/1ns      -1.0   -3.5    -1.0
> 0.25/1ns      -0.75  -2.0    -0.05
> 0.50/1ns      -0.01  -0.5    -0.0
> 0.60/1ns       0.0    0.25    0.0
> 0.75/1ns       0.0    0.0     0.0
> 1.00/1ns       0.0    0.0     0.0
> 2.00/1ns      +0.5   +0.2    +1.0
> |
> |
> |2)  Item 2 under General Syntax Rules and Guidelines is modified to include
> |the following reserved words
> 
>    INF   - used when a data value is so large it is considered infinite
>    TABLE - used to indicate that a subparameter's value(s) are part of a
>            table.
> *******************************************************************************
> 
> ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:  This bird originated from
> discussions held at the January '99 IBIS summit regarding the lack of a
> way to accurately and realistically specify the input thresholds and
> dynamic performance of a digital logic receiver.  At the mid year '99 IBIS
> summit D.C. Sessions, Stephen Peters, Richard Mellitz and Arpad Muranyi
> agreed to meet to hammer out a proposal.  This bird is one of the results.
> The technical basis of this bird derives from simulation work done by
> Richard Mellitz.
> 
> *******************************************************************************
> 
> ANY OTHER BACKGROUND INFORMATION:
> 
> *******************************************************************************

-- 
D. C. Sessions
dc.sessions@vlsi.com
From owner-ibis  Tue Aug 10 11:11:13 1999
Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA01764; Tue, 10 Aug 1999 11:11:13 -0700 (PDT)
Received: (from smtp@localhost)
	by osiris.vlsi.com (8.9.1a/8.9.1) id LAA29952;
	Tue, 10 Aug 1999 11:04:21 -0700 (PDT)
X-Authentication-Warning: osiris.vlsi.com: smtp set sender to <dc.sessions@vlsi.com> using -f
Received: from <dc.sessions@vlsi.com> (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris.vlsi.com via smap (V2.0)
	id xma029933; Tue, 10 Aug 99 11:03:51 -0700
Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id Q1NCKQM1; Tue, 10 Aug 1999 11:03:50 -0700
Sender: dsession@osiris.vlsi.com
Message-ID: <37B06986.E750EF88@vlsi.com>
Date: Tue, 10 Aug 1999 11:03:50 -0700
From: "D. C. Sessions" <dc.sessions@vlsi.com>
Organization: VLSI Technology Inc.
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@eda.org
CC: "C. Kumar" <kumarchi@yahoo.com>, ibis-users@eda.org
Subject: Re: BIRD #61 -- Characterization of Receivers
References: <19990810173012.26175.rocketmail@web125.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"C. Kumar" wrote:
> 
> Simulators are not designed for  slope evaluation. The calculated slope
> at any time can have substantial errors even though the overall
> voltage/current changes will be accurate.
> 
> Tables which depend on slope are asking for trouble.

The problem is that the physical *inputs* are dependent on slope,
and system function (as in, "does it?") depends on the input timing.
We can't just tell ourselves, "slope is hard to deal with in simulaiton,
so we'll ignore its effects."  Mostly because the kind of extreme
conservatism that let us do that in the past would eat all of our
timing budgets and leave nothing for minor details like output delay,
skew, flight, setup, and hold time.

Besides which, I think you're misunderstanding the intent of the tables.
They aren't intended to be used directly; like the VT curves they're
for simulator companies to use in building internal timing estimators
which adjust input timing (offsets only, please note) based on input
waveforms which bear no noticable resemblance to the pretty trapezoids
that we invent to convey characterization.

I suppose that this is a good time to mention that there is a companion
proposal that we discussed to define "golden input waveforms" which are
anything BUT pretty, accompanied by their consequent timing responses.
These will be almost certainly useless for building models, for comparison
to real-world waveforms, and almost everything else EXCEPT providing a
check for the simulator that its inferred timing model isn't too far off
from the manufacturer's characterization.

Watch This Space.

> --- "D. C. Sessions" <dc.sessions@vlsi.com> wrote:
> > Stephen Peters wrote:
> > >
> > > Hello All:
> > >
> > >    Following is the first in a series of BIRDS
> > that aim to enhance
> > > IBIS's ability to specifying and characterizing
> > receivers.  Comments
> > > appreciated.
> >
> > Clarification:
> > Because these sections are totally meaningless
> > without the Vmeas
> > parameter, all of the voltages specified are to be
> > considered relative
> > to Vmeas (or at least that's the way I remember it.)
> >
> > That breaks the examples, but I think we can deal
> > with that.
> >
> > > ===================================
> > >
> > >                  Buffer Issue Resolution Document
> > (BIRD)
> > >
> > > BIRD ID#:   61
> > > ISSUE TITLE: Enhanced Characterization of
> > Receivers
> > > REQUESTOR: D.C Sessions (Philips), Richard
> > Mellitz, Stephen Peters,
> > >            Arpad Muranyi (Intel Corp)
> > > DATE SUBMITTED: August 9, 1999
> > > DATE ACCEPTED BY IBIS OPEN FORUM:
> > >
> > >
> >
> *******************************************************************************
> > >
> >
> *******************************************************************************
> > >
> > > STATEMENT OF THE ISSUE:  The current specification
> > allows the user to
> > > describe the static Vinh and Vinl thresholds of a
> > receiver.  However, these
> > > parameters specify only the DC input thresholds at
> > which the output of
> > > a receiver switches state.  They do not describe a
> > digital logic receiver's
> > > dynamic performance.  Dynamic performance includes
> > such items as how a
> > > device's setup or hold time varies with input
> > overdrive, or how a receiver
> > > behaves when an input waveform rings back into the
> > area between Vinh and
> > > Vinl.  In addition, the current specification does
> > not support simulation
> > > methodologies that rely on specifying the total
> > delay from the input of an
> > > output buffer to the output of the receiver.  This
> > bird offers a way for the
> > > user to specify a receiver's propagation delay and
> > dynamic characteristics in
> > > enough detail so that a simulation tool can model
> > a receiver's response to
> > > any arbitrary waveform.
> > >
> > >
> >
> *******************************************************************************
> > >
> > > STATEMENT OF THE RESOLVED SPECIFICATIONS:
> > >
> > > 1) The following new keyword is defined, and is
> > placed in the
> > > specification just below the [Rising Waveform] and
> > [Falling Waveform]
> > > keyword descriptions
> > >
> > >
> >
> |=============================================================================
> > > |      Keyword: [Receiver Delay]
> > > |     Required: No
> > > |   Sub-Params: Start_point, End_point, Slope
> > > |  Description: This keyword specifies how the
> > propagation delay of an
> > > |               input receiver varies as a
> > function of input overdrive or
> > > |               input waveform slope.
> > > |
> > > |  Usage Rules: The [Receiver Delay] keyword is
> > followed immediately by the
> > > |               three subparameter names and their
> > arguments. The Start_point
> > > |               and End_point subparameters define
> > the starting and ending
> > > |               voltage points of a linear ramp
> > while the Slope parameter
> > > |               specifies the slope of that ramp.
> > Slope is given in units of
> > > |               volts per second (V/S).  All three
> > subparameters are required.
> > > |
> > > |               Subparameter Usage:
> > > |               The intent of the subparameters is
> > to specify a set of linear
> > > |               ramps that vary only in starting
> > point, ending point, or
> > > |               slope.  Therefore, when assigning
> > values to the subparameters,
> > > |               two of the three subparameters
> > must be assigned fixed values,
> > > |               while the third subparameter uses
> > as its argument the reserved
> > > |               word TABLE.  The use of the word
> > TABLE indicates that this
> > > |               subparameter is the independent
> > variable in the associated
> > > |               receiver delay table.  The
> > subparameter that uses the TABLE
> > > |               argument must appear after the
> > other two subparameters and
> > > |               before the receiver delay table.
> > > |
> > > |               Numerical arguments are separated
> > from their associated
> > > |               subparameter by an equals sign
> > (=); white space around the
> > > |               equals sign is optional.  The
> > TABLE argument is separate
> > > |               from its associated subparameter
> > by white space.
> > > |
> > > |               Receiver Delay Table:
> > > |               Following the subparameters is the
> > receiver delay table itself.
> > > |               This table consists of four
> > columns.  The first column lists
> > > |               either the starting voltage,
> > ending voltage or slope of the
> > > |               linear ramp (i.e. the independent
> > variable) as determined by
> > > |               the subparameter with the TABLE
> > argument. The second thru
> > > |               fourth columns list the change in
> > the receiver's propagation
> > > |               delay. This "change in delay" is
> > relative to the receiver's
> > > |               delay when it is stimulated using
> > the same overdrive and edge
> > > |               rate conditions used to specify
> > the device's setup and hold
> > > |               times.  The delay columns are
> > arranged in the standard typ,
> > > |               min, max format.  All four entries
> > must be placed on the same
> > > |               line and must be separated by at
> > least one white space.  All
> > > |               four columns are required.
> > However, data is required only for
> > > |               the typical column. If minimum or
> > maximum data is not available
> > > |               use the reserved word NA.  Each
> > receiver delay table is limited
> > > |               to 100 rows and only one receiver
> > delay table is allowed per
> > > |               [Receiver Delay] keyword.
> > However, there are no restrictions
> > > |               on the number of [Receiver Delay]
> > keywords per [Model] keyword.
> > > |               Note that the [Receiver Delay]
> > keyword is not allowed unless
> > > |               the Model_type of the [Model] is
> > one of the Input or I/O
> > > |               models types.
> > > |
> > > |               Use of INF as a Receiver Delay:
> > > |               When building a receiver delay
> > table the user may specify an
> > > |               input condition that does not
> > result in the receiver's output
> > > |               changing state.  In that case, the
> > receiver delay is considered
> > > |               infinite, and the reserved word
> > INF is used in the delay
> > > |               column.  See the examples below.
> > > |
> > > |               Other Notes:
> > > |               It is expected that the user will
> > provide enough [Receiver
> > > |               Delay] keywords (i.e.
> > characterization data) to allow a CAE
> > > |               tool to build a model of the input
> > receiver.  It is expected
> > > |               that at least four [Receiver
> > Delay] keywords will be required;
> > > |               two low to high going ramps and
> > two high to low going ramps.
> > > |               However, the exact number of ramps
> > and there content is up
> > > |               to the user and recommendations
> > provided by the various
> > > |               simulation vendors.
> > > |
> >
> === message truncated ===
> 
> _____________________________________________________________
> Do You Yahoo!?
> Bid and sell for free at http://auctions.yahoo.com

-- 
D. C. Sessions
dc.sessions@vlsi.com
From owner-ibis  Tue Aug 10 21:28:33 1999
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id VAA04135; Tue, 10 Aug 1999 21:28:33 -0700 (PDT)
Received: from fmsmsx18.intel.com (fmsmsx18.fm.intel.com [132.233.233.232])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id AAA22479;
	Wed, 11 Aug 1999 00:23:20 GMT
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <P56WX6AR>; Tue, 10 Aug 1999 21:22:13 -0700
Message-ID: <4575832C8E71D111AC4100A0C96B512702AC0DB1@fmsmsx36.fm.intel.com>
From: "Mellitz, Richard" <richard.mellitz@intel.com>
To: ibis@eda.org
Cc: ibis-users@eda.org
Subject: RE: BIRD #61 -- Characterization of Receivers
Date: Tue, 10 Aug 1999 21:22:12 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

*Some* simulators have problems with slopes evaluation. I can agree with
that. I understand the waveforms that don't look "pretty" will be tough. So
be it. However there is a LARGE class of buses that we can get a little more
"kick" out of. Modeling and simulation is not reality but just tools to help
us understand our designs so that we can get the most performance and best
reliability. Simulation techniques, methods, and tools need to adapt to meet
technology needs. I have a need. In the past few year I've seen much
innovation by my colleagues. They all are pushing the capabilities of older
(and present) tools. This is really neat stuff. Guess what? We may use a
simulation tool suite and not just one tool. Also... about accuracy... Yes I
*need* to understand the limitation of the tools I use. Its that
understanding that helps define to me what tool to use.

Simple background case:

Some newer busses have receivers that have very high gain differential
amplifiers. Characteristically these have slew rate sensitivities in the ps
range. A couple of years ago, I could care less about few hundred ps.
Source synchronized busses and higher speed changed all that. The beauty of
this proposal is that you can start simple and, at least for some designs,
really gain some reliable performance.

Richard Mellitz, Senior Staff Hardware Engineer
Intel

-----Original Message-----
From: C. Kumar [mailto:kumarchi@yahoo.com]
Sent: Tuesday, August 10, 1999 1:30 PM
To: ibis@eda.org
Cc: ibis-users@eda.org
Subject: Re: BIRD #61 -- Characterization of Receivers


Simulators are not designed for  slope evaluation. The calculated slope
at any time can have substantial errors even though the overall
voltage/current changes will be accurate. 

Tables which depend on slope are asking for trouble. 

--- "D. C. Sessions" <dc.sessions@vlsi.com> wrote:
> Stephen Peters wrote:
> > 
> > Hello All:
> > 
> >    Following is the first in a series of BIRDS
> that aim to enhance
> > IBIS's ability to specifying and characterizing
> receivers.  Comments
> > appreciated.
> 
> Clarification:
> Because these sections are totally meaningless
> without the Vmeas
> parameter, all of the voltages specified are to be
> considered relative
> to Vmeas (or at least that's the way I remember it.)
> 
> That breaks the examples, but I think we can deal
> with that.
> 
> > ===================================
> > 
> >                  Buffer Issue Resolution Document 
> (BIRD)
> > 
> > BIRD ID#:   61
> > ISSUE TITLE: Enhanced Characterization of
> Receivers
> > REQUESTOR: D.C Sessions (Philips), Richard
> Mellitz, Stephen Peters,
> >            Arpad Muranyi (Intel Corp)
> > DATE SUBMITTED: August 9, 1999
> > DATE ACCEPTED BY IBIS OPEN FORUM:
> > 
> >
>
****************************************************************************
***
> >
>
****************************************************************************
***
> > 
> > STATEMENT OF THE ISSUE:  The current specification
> allows the user to
> > describe the static Vinh and Vinl thresholds of a
> receiver.  However, these
> > parameters specify only the DC input thresholds at
> which the output of
> > a receiver switches state.  They do not describe a
> digital logic receiver's
> > dynamic performance.  Dynamic performance includes
> such items as how a
> > device's setup or hold time varies with input
> overdrive, or how a receiver
> > behaves when an input waveform rings back into the
> area between Vinh and
> > Vinl.  In addition, the current specification does
> not support simulation
> > methodologies that rely on specifying the total
> delay from the input of an
> > output buffer to the output of the receiver.  This
> bird offers a way for the
> > user to specify a receiver's propagation delay and
> dynamic characteristics in
> > enough detail so that a simulation tool can model
> a receiver's response to
> > any arbitrary waveform.
> > 
> >
>
****************************************************************************
***
> > 
> > STATEMENT OF THE RESOLVED SPECIFICATIONS:
> > 
> > 1) The following new keyword is defined, and is
> placed in the
> > specification just below the [Rising Waveform] and
> [Falling Waveform]
> > keyword descriptions
> > 
> >
>
|===========================================================================
==
> > |      Keyword: [Receiver Delay]
> > |     Required: No
> > |   Sub-Params: Start_point, End_point, Slope
> > |  Description: This keyword specifies how the
> propagation delay of an
> > |               input receiver varies as a
> function of input overdrive or
> > |               input waveform slope.
> > |
> > |  Usage Rules: The [Receiver Delay] keyword is
> followed immediately by the
> > |               three subparameter names and their
> arguments. The Start_point
> > |               and End_point subparameters define
> the starting and ending
> > |               voltage points of a linear ramp
> while the Slope parameter
> > |               specifies the slope of that ramp. 
> Slope is given in units of
> > |               volts per second (V/S).  All three
> subparameters are required.
> > |
> > |               Subparameter Usage:
> > |               The intent of the subparameters is
> to specify a set of linear
> > |               ramps that vary only in starting
> point, ending point, or
> > |               slope.  Therefore, when assigning
> values to the subparameters,
> > |               two of the three subparameters
> must be assigned fixed values,
> > |               while the third subparameter uses
> as its argument the reserved
> > |               word TABLE.  The use of the word
> TABLE indicates that this
> > |               subparameter is the independent
> variable in the associated
> > |               receiver delay table.  The
> subparameter that uses the TABLE
> > |               argument must appear after the
> other two subparameters and
> > |               before the receiver delay table.
> > |
> > |               Numerical arguments are separated
> from their associated
> > |               subparameter by an equals sign
> (=); white space around the
> > |               equals sign is optional.  The
> TABLE argument is separate
> > |               from its associated subparameter
> by white space.
> > |
> > |               Receiver Delay Table:
> > |               Following the subparameters is the
> receiver delay table itself.
> > |               This table consists of four
> columns.  The first column lists
> > |               either the starting voltage,
> ending voltage or slope of the
> > |               linear ramp (i.e. the independent
> variable) as determined by
> > |               the subparameter with the TABLE
> argument. The second thru
> > |               fourth columns list the change in
> the receiver's propagation
> > |               delay. This "change in delay" is
> relative to the receiver's
> > |               delay when it is stimulated using
> the same overdrive and edge
> > |               rate conditions used to specify
> the device's setup and hold
> > |               times.  The delay columns are
> arranged in the standard typ,
> > |               min, max format.  All four entries
> must be placed on the same
> > |               line and must be separated by at
> least one white space.  All
> > |               four columns are required. 
> However, data is required only for
> > |               the typical column. If minimum or
> maximum data is not available
> > |               use the reserved word NA.  Each
> receiver delay table is limited
> > |               to 100 rows and only one receiver
> delay table is allowed per
> > |               [Receiver Delay] keyword. 
> However, there are no restrictions
> > |               on the number of [Receiver Delay]
> keywords per [Model] keyword.
> > |               Note that the [Receiver Delay]
> keyword is not allowed unless
> > |               the Model_type of the [Model] is
> one of the Input or I/O
> > |               models types.
> > |
> > |               Use of INF as a Receiver Delay:
> > |               When building a receiver delay
> table the user may specify an
> > |               input condition that does not
> result in the receiver's output
> > |               changing state.  In that case, the
> receiver delay is considered
> > |               infinite, and the reserved word
> INF is used in the delay
> > |               column.  See the examples below.
> > |
> > |               Other Notes:
> > |               It is expected that the user will
> provide enough [Receiver
> > |               Delay] keywords (i.e.
> characterization data) to allow a CAE
> > |               tool to build a model of the input
> receiver.  It is expected
> > |               that at least four [Receiver
> Delay] keywords will be required;
> > |               two low to high going ramps and
> two high to low going ramps.
> > |               However, the exact number of ramps
> and there content is up
> > |               to the user and recommendations
> provided by the various
> > |               simulation vendors.
> > |
> 
=== message truncated ===

_____________________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
From owner-ibis  Wed Aug 11 11:00:04 1999
Received: from mailhost.avanticorp.com (uucp@mailhost.avanticorp.com [207.220.204.13]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA10487; Wed, 11 Aug 1999 11:00:03 -0700 (PDT)
From: nikolai@avanticorp.com
Received: (from uucp@localhost)
	by mailhost.avanticorp.com (8.9.3/8.9.3) id KAA21801;
	Wed, 11 Aug 1999 10:53:38 -0700 (PDT)
Received: from splash.src.avanticorp.com(172.18.10.24)
 via SMTP by shamu.avanticorp.com, id smtpdAAAOj1ID_; Wed Aug 11 10:53:19 1999
Received: from iris.src.avanticorp.com (iris.src.avanticorp.com [172.18.5.78])
	by splash.src.avanticorp.com (8.9.3/8.9.3) with ESMTP id KAA27867;
	Wed, 11 Aug 1999 10:52:57 -0700 (PDT)
Received: (from nikolai@localhost)
	by iris.src.avanticorp.com (8.8.8/8.8.8) id KAA12643;
	Wed, 11 Aug 1999 10:44:47 -0700 (PDT)
Date: Wed, 11 Aug 1999 10:44:47 -0700 (PDT)
Message-Id: <199908111744.KAA12643@iris.src.avanticorp.com>
To: ibis@eda.org, ibis-users@eda.org
Subject: Re: BIRD #61 -- Characterization of Receivers
Cc: nikolai@avanticorp.com
X-Sun-Charset: US-ASCII


Hi All,

Can't anyone clarify this new spec. about receivers for me
and what the intention is?

THanks

Nik
nikolai@avanticorp.com


Qestions:

*********
*   1   *
*********

1. What is a receiver? Is it
   a) A part of output buffer which receives controlloing
      signal (in other words, input of output type buffer).
      In this case it can be extended to enable node
      of 3-state and I/O buffers.
   b) That part of Input buffer, which is looking into
      a transmission line and receives signals from
      some output type buffer through the transmission line.

I would expect the unswer should be b). However, the spec.
says:

===begin===

1) The following new keyword is defined, and is placed in the
specification just below the [Rising Waveform] and [Falling Waveform]
keyword descriptions

=== end ===

But Input buffer has no [Rising Waveform] or [Falling Waveform].
I/O buffer does have, but Input buffer does not have and
we have no place to place [Receiver Delay] keyword.

If the answer is a), then, hey, how we can apply ramp
signal to input of the output buffer, if we do not know
its impedance, Capacitance, etc. ??


*********
*   2   *
*********

2) Examples are confusing. The should give receiver delay.
   What we have in example 1:

===begin===

[Receiver Delay]
Start_point = 0.8v
Slope = 1v/1ns
End_point  TABLE
|variable      typ     min    max
1.4            INF     7.0ns  INF
1.5            INF     5.0ns  INF
1.51           INF     3.0ns  10.0ns
1.53           7.0ns   0.0ns  7.0ns
1.55           2.0ns   0.0ns  1.0ns
1.6            0.0ns   0.0ns  0.0ns
1.7            0.0ns   0.0ns  0.0ns
2.0            0.0ns   0.0ns  0.0ns
2.1            0.1ns   0.1ns  0.1ns
2.5           -0.2ns  -0.1ns -0.5ns

=== end ===

delay is about 1ns, ok

example 2:

===begin===

[Receiver Delay]
Start_point = 0.8v
End_point = 2.0v
Slope  TABLE
|variable      typ     min    max
0.05/1ns      -1.0   -3.5    -1.0
0.25/1ns      -0.75  -2.0    -0.05
0.50/1ns      -0.01  -0.5    -0.0
0.60/1ns       0.0    0.25    0.0
0.75/1ns       0.0    0.0     0.0
1.00/1ns       0.0    0.0     0.0
2.00/1ns      +0.5   +0.2    +1.0

=== end ===

is it a delay about 1s, or data are in Volts, 
or Nano is missing, or what is it?



*********
*   3   *
*********

3) Some delays are negative. This is very very bad.
   Should be always positive. Just from stand point of
   causality. You apply a signal and then 1ns BEFORE that event
   your receiver tells you the signal has arrived.
   Simulators have to add some 'base' delay.
   Simulator_A will add 1ns, Simulator_B will add 10ns, etc.
   Why not IBIS spec add this 'base' delay and all have
   less headahe?


*********
*   4   *
*********

4) Input buffer has Vinl, Vinh. If [Receiver Delay]-s
   are specified, then Vinl, Vinh should be discarded. Right?
   If ONLY 1 [Receiver Delay] is given, say for rising ramp,
   then we still use Vinl, Vinh, right ?
   Vinl, Vinh MUST be always given and BE CONSISTENT with
   [Receiver Delay] if the last is given. Right?


*********
*  end  *
*********




----- Begin Included Message -----



                 Buffer Issue Resolution Document  (BIRD)


BIRD ID#:   61
ISSUE TITLE: Enhanced Characterization of Receivers
REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters,
           Arpad Muranyi (Intel Corp)
DATE SUBMITTED: August 9, 1999
DATE ACCEPTED BY IBIS OPEN FORUM: 

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

STATEMENT OF THE ISSUE:  The current specification allows the user to 
describe the static Vinh and Vinl thresholds of a receiver.  However, these
parameters specify only the DC input thresholds at which the output of 
a receiver switches state.  They do not describe a digital logic receiver's
dynamic performance.  Dynamic performance includes such items as how a
device's setup or hold time varies with input overdrive, or how a receiver
behaves when an input waveform rings back into the area between Vinh and
Vinl.  In addition, the current specification does not support simulation
methodologies that rely on specifying the total delay from the input of an
output buffer to the output of the receiver.  This bird offers a way for the
user to specify a receiver's propagation delay and dynamic characteristics in
enough detail so that a simulation tool can model a receiver's response to
any arbitrary waveform.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:  

1) The following new keyword is defined, and is placed in the
specification just below the [Rising Waveform] and [Falling Waveform]
keyword descriptions

|=============================================================================
|      Keyword: [Receiver Delay]
|     Required: No
|   Sub-Params: Start_point, End_point, Slope
|  Description: This keyword specifies how the propagation delay of an 
|               input receiver varies as a function of input overdrive or 
|               input waveform slope.  
|
|  Usage Rules: The [Receiver Delay] keyword is followed immediately by the 
|               three subparameter names and their arguments. The Start_point
|               and End_point subparameters define the starting and ending 
|               voltage points of a linear ramp while the Slope parameter 
|               specifies the slope of that ramp.  Slope is given in units of 
|               volts per second (V/S).  All three subparameters are required.
|
|               Subparameter Usage:
|               The intent of the subparameters is to specify a set of linear 
|               ramps that vary only in starting point, ending point, or 
|               slope.  Therefore, when assigning values to the subparameters,
|               two of the three subparameters must be assigned fixed values,
|               while the third subparameter uses as its argument the reserved 
|               word TABLE.  The use of the word TABLE indicates that this 
|               subparameter is the independent variable in the associated 
|               receiver delay table.  The subparameter that uses the TABLE 
|               argument must appear after the other two subparameters and 
|               before the receiver delay table.  
|
|               Numerical arguments are separated from their associated
|               subparameter by an equals sign (=); white space around the 
|               equals sign is optional.  The TABLE argument is separate
|               from its associated subparameter by white space.
|
|               Receiver Delay Table:
|               Following the subparameters is the receiver delay table itself.
|               This table consists of four columns.  The first column lists
|               either the starting voltage, ending voltage or slope of the
|               linear ramp (i.e. the independent variable) as determined by 
|               the subparameter with the TABLE argument. The second thru
|               fourth columns list the change in the receiver's propagation
|               delay. This "change in delay" is relative to the receiver's
|               delay when it is stimulated using the same overdrive and edge
|               rate conditions used to specify the device's setup and hold
|               times.  The delay columns are arranged in the standard typ, 
|               min, max format.  All four entries must be placed on the same
|               line and must be separated by at least one white space.  All
|               four columns are required.  However, data is required only for
|               the typical column. If minimum or maximum data is not available
|               use the reserved word NA.  Each receiver delay table is limited
|               to 100 rows and only one receiver delay table is allowed per
|               [Receiver Delay] keyword.  However, there are no restrictions
|               on the number of [Receiver Delay] keywords per [Model] keyword.
|               Note that the [Receiver Delay] keyword is not allowed unless
|               the Model_type of the [Model] is one of the Input or I/O
|               models types.
|
|               Use of INF as a Receiver Delay:
|               When building a receiver delay table the user may specify an 
|               input condition that does not result in the receiver's output 
|               changing state.  In that case, the receiver delay is considered
|               infinite, and the reserved word INF is used in the delay
|               column.  See the examples below.
|               
|               Other Notes:
|               It is expected that the user will provide enough [Receiver
|               Delay] keywords (i.e. characterization data) to allow a CAE 
|               tool to build a model of the input receiver.  It is expected
|               that at least four [Receiver Delay] keywords will be required;
|               two low to high going ramps and two high to low going ramps.
|               However, the exact number of ramps and there content is up
|               to the user and recommendations provided by the various
|               simulation vendors.
|
| An example table showing how receiver delay varies vs. overdrive.
| Note the use of the reserved word INF.
|
[Receiver Delay]
Start_point = 0.8v
Slope = 1v/1ns
End_point  TABLE
|variable      typ     min    max
1.4            INF     7.0ns  INF
1.5            INF     5.0ns  INF
1.51           INF     3.0ns  10.0ns
1.53           7.0ns   0.0ns  7.0ns
1.55           2.0ns   0.0ns  1.0ns
1.6            0.0ns   0.0ns  0.0ns
1.7            0.0ns   0.0ns  0.0ns
2.0            0.0ns   0.0ns  0.0ns
2.1            0.1ns   0.1ns  0.1ns
2.5           -0.2ns  -0.1ns -0.5ns
|
| A second table that characterizes receiver delay vs. the slope of the
| input waveform.
|
[Receiver Delay]
Start_point = 0.8v
End_point = 2.0v
Slope  TABLE
|variable      typ     min    max
0.05/1ns      -1.0   -3.5    -1.0
0.25/1ns      -0.75  -2.0    -0.05
0.50/1ns      -0.01  -0.5    -0.0
0.60/1ns       0.0    0.25    0.0
0.75/1ns       0.0    0.0     0.0
1.00/1ns       0.0    0.0     0.0
2.00/1ns      +0.5   +0.2    +1.0
|
|
|2)  Item 2 under General Syntax Rules and Guidelines is modified to include
|the following reserved words

   INF   - used when a data value is so large it is considered infinite
   TABLE - used to indicate that a subparameter's value(s) are part of a
           table.
*******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:  This bird originated from
discussions held at the January '99 IBIS summit regarding the lack of a
way to accurately and realistically specify the input thresholds and 
dynamic performance of a digital logic receiver.  At the mid year '99 IBIS
summit D.C. Sessions, Stephen Peters, Richard Mellitz and Arpad Muranyi
agreed to meet to hammer out a proposal.  This bird is one of the results.
The technical basis of this bird derives from simulation work done by
Richard Mellitz.

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

ANY OTHER BACKGROUND INFORMATION:



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






----- End Included Message -----

From owner-ibis  Wed Aug 11 13:37:52 1999
Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA10881; Wed, 11 Aug 1999 13:37:50 -0700 (PDT)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA01612;
	Wed, 11 Aug 1999 13:42:02 -0700 (PDT)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id NAA01493;
	Wed, 11 Aug 1999 13:31:26 -0700 (PDT)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id NAA19039;
	Wed, 11 Aug 1999 13:31:25 -0700 (PDT)
Message-Id: <199908112031.NAA19039@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: nikolai@avanticorp.com
cc: ibis@eda.org, ibis-users@eda.org
Subject: Re: BIRD #61 -- Characterization of Receivers 
In-reply-to: Your message of "Wed, 11 Aug 1999 10:44:47 PDT."
             <199908111744.KAA12643@iris.src.avanticorp.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 11 Aug 1999 13:31:25 -0700
From: Stephen Peters <sjpeters@ichips.intel.com>


Hello Nik:

   My comments are below, prefixed by >>>

     Regards,
     Stephen Peters
     Intel Corp.

> 
> Hi All,
> 
> Can't anyone clarify this new spec. about receivers for me
> and what the intention is?
> 
> THanks
> 
> Nik
> nikolai@avanticorp.com
> 
> 
> Qestions:
> 
> *********
> *   1   *
> *********
> 
> 1. What is a receiver? Is it
>    a) A part of output buffer which receives controlloing
>       signal (in other words, input of output type buffer).
>       In this case it can be extended to enable node
>       of 3-state and I/O buffers.
>    b) That part of Input buffer, which is looking into
>       a transmission line and receives signals from
>       some output type buffer through the transmission line.
>

   >>> it's b).  A receiver can be connected to an input-only pin, or
       it can be the 'input' part of an I/O pin.
 
> I would expect the unswer should be b). However, the spec.
> says:
> 
> ===begin===
> 
> 1) The following new keyword is defined, and is placed in the
> specification just below the [Rising Waveform] and [Falling Waveform]
> keyword descriptions

   >>>  The above refers to where the keyword is placed textually within
        the specification document itself, not within a particular
        model.  
> 
> === end ===
> 
> But Input buffer has no [Rising Waveform] or [Falling Waveform].
> I/O buffer does have, but Input buffer does not have and
> we have no place to place [Receiver Delay] keyword.
> 
> If the answer is a), then, hey, how we can apply ramp
> signal to input of the output buffer, if we do not know
> its impedance, Capacitance, etc. ??

    >>> Again, the [Receiver Delay] is used to build a receiver model-- it 
        has nothing to do with an output or the output part of an I/O pin.
> 
> 
> *********
> *   2   *
> *********
> 
> 2) Examples are confusing. The should give receiver delay.

   >>>  No.  The intent was NOT to spec an absolute delay thru
        the buffer, but the *change* in delay due to differing overdrive
        and input waveform slope conditions.  As I detail below, the
        intent is that by detailing the change in propagation delay 
        thru the receiver for various controlled conditions, a simulation
        vendor can construct a model that predicts the receiver's behavior
        for any arbitrary waveform.

        You are correct that the delay columns in the second example are
        missing the "nS" suffix.  This will be fixed.


>    What we have in example 1:
> 
> ===begin===
> 
> [Receiver Delay]
> Start_point = 0.8v
> Slope = 1v/1ns
> End_point  TABLE
> |variable      typ     min    max
> 1.4            INF     7.0ns  INF
> 1.5            INF     5.0ns  INF
> 1.51           INF     3.0ns  10.0ns
> 1.53           7.0ns   0.0ns  7.0ns
> 1.55           2.0ns   0.0ns  1.0ns
> 1.6            0.0ns   0.0ns  0.0ns
> 1.7            0.0ns   0.0ns  0.0ns
> 2.0            0.0ns   0.0ns  0.0ns
> 2.1            0.1ns   0.1ns  0.1ns
> 2.5           -0.2ns  -0.1ns -0.5ns
> 
> === end ===
> 
> delay is about 1ns, ok
> 
> example 2:
> 
> ===begin===
> 
> [Receiver Delay]
> Start_point = 0.8v
> End_point = 2.0v
> Slope  TABLE
> |variable      typ     min    max
> 0.05/1ns      -1.0   -3.5    -1.0
> 0.25/1ns      -0.75  -2.0    -0.05
> 0.50/1ns      -0.01  -0.5    -0.0
> 0.60/1ns       0.0    0.25    0.0
> 0.75/1ns       0.0    0.0     0.0
> 1.00/1ns       0.0    0.0     0.0
> 2.00/1ns      +0.5   +0.2    +1.0
> 
> === end ===
> 
> is it a delay about 1s, or data are in Volts, 
> or Nano is missing, or what is it?
> 
> 
> 
> *********
> *   3   *
> *********
> 
> 3) Some delays are negative. This is very very bad.
>    Should be always positive. Just from stand point of
>    causality. You apply a signal and then 1ns BEFORE that event
>    your receiver tells you the signal has arrived.
>    Simulators have to add some 'base' delay.
>    Simulator_A will add 1ns, Simulator_B will add 10ns, etc.
>    Why not IBIS spec add this 'base' delay and all have
>    less headahe?
> 

     >>> As I pointed out above, the intent is to show the change in
         propagation delay, and a negative change is perfectly OK.  
         Now, you do raise a good issue about 'base delay'.  I do not know
         if base delay is an important variable in constructing a 
         behavioral receiver model, of if different simulators will come
         up with different models because they assumed different base
         delays.  I do assume base delay can be approximated by looking 
         at the setup time specification for a particular pin.  I hesitate,
         however, to have IBIS spec a 'base delay' -- at least not without
         a lot of simulator vendor input.
> 
> *********
> *   4   *
> *********
> 
> 4) Input buffer has Vinl, Vinh. If [Receiver Delay]-s
>    are specified, then Vinl, Vinh should be discarded. Right?
>    If ONLY 1 [Receiver Delay] is given, say for rising ramp,
>    then we still use Vinl, Vinh, right ?
>    Vinl, Vinh MUST be always given and BE CONSISTENT with
>    [Receiver Delay] if the last is given. Right?
>

   >>>  I'm not sure I understand your comment.  The Start_point and 
        End_point parameters are not replacements for Vinh or Vinl.
        Start_point and End_point are in no way "specifications" of 
        switching threshold.  They (and Slope) simply describe a waveform
        applied to a receiver.  Again, the idea is that with the right set of 
        ideal waveforms, a simulator can construct a behavioral model
        of a receiver. 
         

   I hope these responses help clarify the intent of the BIRD
> 
> *********
> *  end  *
> *********
> 
> 
> 
> 

From owner-ibis  Wed Aug 11 11:45:47 1999
Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA10591; Wed, 11 Aug 1999 11:45:46 -0700 (PDT)
Received: (from smtp@localhost)
	by osiris.vlsi.com (8.9.1a/8.9.1) id LAA10977;
	Wed, 11 Aug 1999 11:38:50 -0700 (PDT)
X-Authentication-Warning: osiris.vlsi.com: smtp set sender to <dc.sessions@vlsi.com> using -f
Received: from <dc.sessions@vlsi.com> (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris.vlsi.com via smap (V2.0)
	id xma010947; Wed, 11 Aug 99 11:38:37 -0700
Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id Q1NCKRL8; Wed, 11 Aug 1999 11:38:36 -0700
Sender: dsession@osiris.vlsi.com
Message-ID: <37B1C32C.A58EE28F@vlsi.com>
Date: Wed, 11 Aug 1999 11:38:36 -0700
From: "D. C. Sessions" <dc.sessions@vlsi.com>
Organization: VLSI Technology Inc.
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@eda.org
CC: nikolai@avanticorp.com, ibis-users@eda.org
Subject: Re: BIRD #61 -- Characterization of Receivers
References: <199908111744.KAA12643@iris.src.avanticorp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

nikolai@avanticorp.com wrote:
> 
> Hi All,
> 
> Can't anyone clarify this new spec. about receivers for me
> and what the intention is?



> Qestions:
> 
> *********
> *   1   *
> *********
> 
> 1. What is a receiver? Is it
>    a) A part of output buffer which receives controlloing
>       signal (in other words, input of output type buffer).
>       In this case it can be extended to enable node
>       of 3-state and I/O buffers.
>    b) That part of Input buffer, which is looking into
>       a transmission line and receives signals from
>       some output type buffer through the transmission line.

(B)

> I would expect the unswer should be b). However, the spec.
> says:
> 
> ===begin===
> 
> 1) The following new keyword is defined, and is placed in the
> specification just below the [Rising Waveform] and [Falling Waveform]
> keyword descriptions
> 
> === end ===
> 
> But Input buffer has no [Rising Waveform] or [Falling Waveform].
> I/O buffer does have, but Input buffer does not have and
> we have no place to place [Receiver Delay] keyword.

Keep in mind that IBIS specifications are relatively free-form.  Within
a given [Model] there are few constraints on where you place a given
keyword; the paragraph you quoted is purely editorial and describes the
location where the new text will appear in the revised IBIS standard
document.

> *********
> *   2   *
> *********
> 
> 2) Examples are confusing. The should give receiver delay.
>    What we have in example 1:
> 
> ===begin===
> 
> [Receiver Delay]
> Start_point = 0.8v
> Slope = 1v/1ns
> End_point  TABLE
> |variable      typ     min    max
> 1.4            INF     7.0ns  INF
> 1.5            INF     5.0ns  INF
> 1.51           INF     3.0ns  10.0ns
> 1.53           7.0ns   0.0ns  7.0ns
> 1.55           2.0ns   0.0ns  1.0ns
> 1.6            0.0ns   0.0ns  0.0ns
> 1.7            0.0ns   0.0ns  0.0ns
> 2.0            0.0ns   0.0ns  0.0ns
> 2.1            0.1ns   0.1ns  0.1ns
> 2.5           -0.2ns  -0.1ns -0.5ns

NB: SP got caught by the usual gotcha and has max=slow instead
of max=fast

> === end ===
> 
> delay is about 1ns, ok

No, delay isn't specified at all here.  What this table says is that if
your input waveform rises at 1v/ns from 0.8v to 2.0v (the databook
test condition) then there is no change in the input delay from the data
book timing (DUH!)  OTOH, if the input rises from 0.8v to 1.55v at 1v/ns
then the input delay under slow conditions is unchanged, the delay under
typical conditions is 2.0ns longer than databook, and the delay under
fast conditions is 1.0ns slower than databook.  (OK, so these are mixed up.
See above.)

> example 2:
> 
> ===begin===
> 
> [Receiver Delay]
> Start_point = 0.8v
> End_point = 2.0v
> Slope  TABLE
> |variable      typ     min    max
> 0.05/1ns      -1.0   -3.5    -1.0
> 0.25/1ns      -0.75  -2.0    -0.05
> 0.50/1ns      -0.01  -0.5    -0.0
> 0.60/1ns       0.0    0.25    0.0
> 0.75/1ns       0.0    0.0     0.0
> 1.00/1ns       0.0    0.0     0.0
> 2.00/1ns      +0.5   +0.2    +1.0
> 
> === end ===
> 
> is it a delay about 1s, or data are in Volts,
> or Nano is missing, or what is it?

Again, these are relative rather than absolute delays.
And you're correct that the dimensions in the table entries
should be nanoseconds.

> *********
> *   3   *
> *********
> 
> 3) Some delays are negative. This is very very bad.
>    Should be always positive. Just from stand point of
>    causality. You apply a signal and then 1ns BEFORE that event
>    your receiver tells you the signal has arrived.
>    Simulators have to add some 'base' delay.
>    Simulator_A will add 1ns, Simulator_B will add 10ns, etc.
>    Why not IBIS spec add this 'base' delay and all have
>    less headahe?

The delays are adjustments to databook timing, so negative numbers are
not a problem.  As for 'base', IBIS is not intended to contain an
entire part data sheet.  If we were to try THAT, we'd need to specify
the setup time to arbitrary signals (eg setup to end of RESET) and so
forth, which is far, far, farther into the functional space than we
can go.  Not gonna happen.

Instead, this BIRD just applies signal-integrity adjustments to the
timing already described in some other format (eg databook).  For
instance, DDR SDRAM devices are characterized with input waveforms
swinging from Vil(ac) to Vih(ac) at 1v/ns (or the reverse).  In real
applications, though, some inputs could actually slew faster and this
might result in a hold-time violation.  The proposed BIRD allows system
designers to refine their timing analyses based on input wave SHAPE as
well as threshold crossing.

> *********
> *   4   *
> *********
> 
> 4) Input buffer has Vinl, Vinh. If [Receiver Delay]-s
>    are specified, then Vinl, Vinh should be discarded. Right?
>    If ONLY 1 [Receiver Delay] is given, say for rising ramp,
>    then we still use Vinl, Vinh, right ?
>    Vinl, Vinh MUST be always given and BE CONSISTENT with
>    [Receiver Delay] if the last is given. Right?

Vinh and Vinl are holdovers from TTL data sheets.  They have some minor
utility as extreme-worst-case noise margin specs; they are quite
useless for timing analysis.  Vmeas is much more relevant, and in
these tables have no effect on its use.  In fact, they depend on it.

We would hope that based on the information in these tables simulator
companies would refine their noise analysis models to recognize that
a transient that (e.g.) rang back to 200mV above a Vinl of 800mV for
250ps in reality has no chance of causing a logic violation.

> *********
> *  end  *
> *********
> 
> ----- Begin Included Message -----
> 
>                  Buffer Issue Resolution Document  (BIRD)
> 
> BIRD ID#:   61
> ISSUE TITLE: Enhanced Characterization of Receivers
> REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters,
>            Arpad Muranyi (Intel Corp)
> DATE SUBMITTED: August 9, 1999
> DATE ACCEPTED BY IBIS OPEN FORUM:
> 
> *******************************************************************************
> *******************************************************************************
> 
> STATEMENT OF THE ISSUE:  The current specification allows the user to
> describe the static Vinh and Vinl thresholds of a receiver.  However, these
> parameters specify only the DC input thresholds at which the output of
> a receiver switches state.  They do not describe a digital logic receiver's
> dynamic performance.  Dynamic performance includes such items as how a
> device's setup or hold time varies with input overdrive, or how a receiver
> behaves when an input waveform rings back into the area between Vinh and
> Vinl.  In addition, the current specification does not support simulation
> methodologies that rely on specifying the total delay from the input of an
> output buffer to the output of the receiver.  This bird offers a way for the
> user to specify a receiver's propagation delay and dynamic characteristics in
> enough detail so that a simulation tool can model a receiver's response to
> any arbitrary waveform.
> 
> *******************************************************************************
> 
> STATEMENT OF THE RESOLVED SPECIFICATIONS:
> 
> 1) The following new keyword is defined, and is placed in the
> specification just below the [Rising Waveform] and [Falling Waveform]
> keyword descriptions
> 
> |=============================================================================
> |      Keyword: [Receiver Delay]
> |     Required: No
> |   Sub-Params: Start_point, End_point, Slope
> |  Description: This keyword specifies how the propagation delay of an
> |               input receiver varies as a function of input overdrive or
> |               input waveform slope.
> |
> |  Usage Rules: The [Receiver Delay] keyword is followed immediately by the
> |               three subparameter names and their arguments. The Start_point
> |               and End_point subparameters define the starting and ending
> |               voltage points of a linear ramp while the Slope parameter
> |               specifies the slope of that ramp.  Slope is given in units of
> |               volts per second (V/S).  All three subparameters are required.
> |
> |               Subparameter Usage:
> |               The intent of the subparameters is to specify a set of linear
> |               ramps that vary only in starting point, ending point, or
> |               slope.  Therefore, when assigning values to the subparameters,
> |               two of the three subparameters must be assigned fixed values,
> |               while the third subparameter uses as its argument the reserved
> |               word TABLE.  The use of the word TABLE indicates that this
> |               subparameter is the independent variable in the associated
> |               receiver delay table.  The subparameter that uses the TABLE
> |               argument must appear after the other two subparameters and
> |               before the receiver delay table.
> |
> |               Numerical arguments are separated from their associated
> |               subparameter by an equals sign (=); white space around the
> |               equals sign is optional.  The TABLE argument is separate
> |               from its associated subparameter by white space.
> |
> |               Receiver Delay Table:
> |               Following the subparameters is the receiver delay table itself.
> |               This table consists of four columns.  The first column lists
> |               either the starting voltage, ending voltage or slope of the
> |               linear ramp (i.e. the independent variable) as determined by
> |               the subparameter with the TABLE argument. The second thru
> |               fourth columns list the change in the receiver's propagation
> |               delay. This "change in delay" is relative to the receiver's
> |               delay when it is stimulated using the same overdrive and edge
> |               rate conditions used to specify the device's setup and hold
> |               times.  The delay columns are arranged in the standard typ,
> |               min, max format.  All four entries must be placed on the same
> |               line and must be separated by at least one white space.  All
> |               four columns are required.  However, data is required only for
> |               the typical column. If minimum or maximum data is not available
> |               use the reserved word NA.  Each receiver delay table is limited
> |               to 100 rows and only one receiver delay table is allowed per
> |               [Receiver Delay] keyword.  However, there are no restrictions
> |               on the number of [Receiver Delay] keywords per [Model] keyword.
> |               Note that the [Receiver Delay] keyword is not allowed unless
> |               the Model_type of the [Model] is one of the Input or I/O
> |               models types.
> |
> |               Use of INF as a Receiver Delay:
> |               When building a receiver delay table the user may specify an
> |               input condition that does not result in the receiver's output
> |               changing state.  In that case, the receiver delay is considered
> |               infinite, and the reserved word INF is used in the delay
> |               column.  See the examples below.
> |
> |               Other Notes:
> |               It is expected that the user will provide enough [Receiver
> |               Delay] keywords (i.e. characterization data) to allow a CAE
> |               tool to build a model of the input receiver.  It is expected
> |               that at least four [Receiver Delay] keywords will be required;
> |               two low to high going ramps and two high to low going ramps.
> |               However, the exact number of ramps and there content is up
> |               to the user and recommendations provided by the various
> |               simulation vendors.
> |
> | An example table showing how receiver delay varies vs. overdrive.
> | Note the use of the reserved word INF.
> |
> [Receiver Delay]
> Start_point = 0.8v
> Slope = 1v/1ns
> End_point  TABLE
> |variable      typ     min    max
> 1.4            INF     7.0ns  INF
> 1.5            INF     5.0ns  INF
> 1.51           INF     3.0ns  10.0ns
> 1.53           7.0ns   0.0ns  7.0ns
> 1.55           2.0ns   0.0ns  1.0ns
> 1.6            0.0ns   0.0ns  0.0ns
> 1.7            0.0ns   0.0ns  0.0ns
> 2.0            0.0ns   0.0ns  0.0ns
> 2.1            0.1ns   0.1ns  0.1ns
> 2.5           -0.2ns  -0.1ns -0.5ns
> |
> | A second table that characterizes receiver delay vs. the slope of the
> | input waveform.
> |
> [Receiver Delay]
> Start_point = 0.8v
> End_point = 2.0v
> Slope  TABLE
> |variable      typ     min    max
> 0.05/1ns      -1.0   -3.5    -1.0
> 0.25/1ns      -0.75  -2.0    -0.05
> 0.50/1ns      -0.01  -0.5    -0.0
> 0.60/1ns       0.0    0.25    0.0
> 0.75/1ns       0.0    0.0     0.0
> 1.00/1ns       0.0    0.0     0.0
> 2.00/1ns      +0.5   +0.2    +1.0
> |
> |
> |2)  Item 2 under General Syntax Rules and Guidelines is modified to include
> |the following reserved words
> 
>    INF   - used when a data value is so large it is considered infinite
>    TABLE - used to indicate that a subparameter's value(s) are part of a
>            table.
> *******************************************************************************
> 
> ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:  This bird originated from
> discussions held at the January '99 IBIS summit regarding the lack of a
> way to accurately and realistically specify the input thresholds and
> dynamic performance of a digital logic receiver.  At the mid year '99 IBIS
> summit D.C. Sessions, Stephen Peters, Richard Mellitz and Arpad Muranyi
> agreed to meet to hammer out a proposal.  This bird is one of the results.
> The technical basis of this bird derives from simulation work done by
> Richard Mellitz.
> 
> *******************************************************************************
> 
> ANY OTHER BACKGROUND INFORMATION:
> 
> *******************************************************************************
> 
> ----- End Included Message -----

-- 
D. C. Sessions
dc.sessions@vlsi.com
From owner-ibis  Wed Aug 11 15:47:16 1999
Received: from mail.nesa.com (mail.nesa.com [204.240.29.34]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA11146 for <ibis-users@eda.org>; Wed, 11 Aug 1999 15:47:15 -0700 (PDT)
Received: from porky (porky.nesa.com [204.240.29.45])
	by mail.nesa.com (8.9.3/8.9.3) with SMTP id RAA32700;
	Wed, 11 Aug 1999 17:00:21 -0400
Message-Id: <3.0.5.32.19990811170446.009ef100@mail.nesa.com>
X-Sender: breda@mail.nesa.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 11 Aug 1999 17:04:46 -0400
To: ibis-users@eda.org
From: Kathy Breda <breda@nesa.com>
Subject: IBIS User's Group Meeting WEDS. 9/15/99 @ 3:00 pm @ NESA
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"


IBIS Users Group:

The summer is winding up and it is time to move IBIS activities
forward again.  We also need to discuss the upcoming IBIS Summit
being held at the Marlboro Holiday Inn on October 14th.


Date:     WEDNESDAY - September 15, 1999
Time:     3:00 pm - 5:00 pm
Location: North East Systems Associates, Inc.(NESA), Stow, MA

Let me know if you'll be joining us and if you would like
to connect by telephone conference.

Regards,

   Kathy Breda



+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|       NORTH EAST SYSTEMS ASSOCIATES, INC.       |
|      -------------------------------------      |
|     "High Performance Engineering & Design"     |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Kathy Breda             e-mail: breda@nesa.com  |
| NESA, Inc.              http://www.nesa.com/    |
| 636 Great Road          Tel +1.978.897-8787     |
| Stow, MA 01775 USA      Fax +1.978.897-5359     |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
From owner-ibis  Wed Aug 11 16:00:17 1999
Received: from mail.nesa.com (mail.nesa.com [204.240.29.34]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA11163; Wed, 11 Aug 1999 16:00:16 -0700 (PDT)
Received: from porky (porky.nesa.com [204.240.29.45])
	by mail.nesa.com (8.9.3/8.9.3) with SMTP id RAA32733;
	Wed, 11 Aug 1999 17:13:31 -0400
Message-Id: <3.0.5.32.19990811171756.00982d00@mail.nesa.com>
X-Sender: breda@mail.nesa.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 11 Aug 1999 17:17:56 -0400
To: ibis-users@eda.org, ibis@eda.org, si-list@silab.Eng.Sun.COM
From: Kathy Breda <breda@nesa.com>
Subject: IBIS SUMMIT - October 14, 1999 -
  Attendance/Presentations/Sponsors
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Greetings:

The third annual east-coast IBIS Summit is rapidly approaching.

Thursday, October 14, 1999, 8:30 - 4:00
Marlborough Holiday Inn, Marlborough, Massachusetts

					
We're looking for your assistance---+
						|						
						v
					ACTIONS (respond to breda@nesa.com)

*  	Are you interested in attending the summit?
	
*	Are you interested in presenting an IBIS related topic?

*     Is your company interested in helping to sponsor this event?

	Would you/your company like to be a sponsor for one
	of the following?  The Meeting Room 
				 Morning Break Refreshments
				 Lunch
                         Afternoon Break Refreshments
      Cost estimates can be provided if you are interested in
      sponsorship. (breda@nesa.com)


Thank you,

   Kathy Breda


+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|       NORTH EAST SYSTEMS ASSOCIATES, INC.       |
|      -------------------------------------      |
|     "High Performance Engineering & Design"     |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Kathy Breda             e-mail: breda@nesa.com  |
| NESA, Inc.              http://www.nesa.com/    |
| 636 Great Road          Tel +1.978.897-8787     |
| Stow, MA 01775 USA      Fax +1.978.897-5359     |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
From owner-ibis  Thu Aug 12 06:39:57 1999
Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA15518; Thu, 12 Aug 1999 06:39:56 -0700 (PDT)
Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id GAA20794; Thu, 12 Aug 1999 06:33:36 -0700 (PDT)
Received: from zip.Cadence.COM(158.140.103.36) by mailgate.cadence.com via smap (mjr-v1.2)
	id xma934464814.020789; Thu, 12 Aug 99 06:33:34 -0700
Received: from cadence.com (d15814010553 [158.140.105.53]) by zip.Cadence.COM (8.7.3/8.7.3) with ESMTP id JAA15465; Thu, 12 Aug 1999 09:33:33 -0400 (EDT)
Message-ID: <37B2CC65.99F996C@cadence.com>
Date: Thu, 12 Aug 1999 09:30:13 -0400
From: Mike LaBonte <mikelabonte@cadence.com>
Organization: Cadence Design Systems
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Peters <sjpeters@ichips.intel.com>
CC: ibis@eda.org, ibis-users@eda.org
Subject: Re: BIRD #61 -- Characterization of Receivers
References: <199908101522.IAA04758@xtg801.pdx.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From what I have read so far, BIRD #61 specifies a timing *correction* table
mechanism, as opposed to a more sophisticated algorithm for dynamically
determining when a receiver has switched. The way I see it, a simulator would
have to:

1) Determine switch times at a receiver using good 'ol Vmeas.
2) Analyze the waveform around the Vmeas switch point and use the [Receiver
   Delay] info to determine a correction factor.
3) Offset the switch time by the correction factor and use this in timing
   measurements.

This seems OK for signal integrity style simulations, in which propagation of
a signal through interconnect is analyzed, but propagation through components
is not. However, a more functional style of simulation in which the received
signal propagates through a component and into another piece of interconnect
would not be served well by this BIRD. This limitation is OK for analysis of
common clock designs, in which the output buffer transition start times are
governed more by the system clock than anything else.

However, with source synchronous designs we may find ourselves wanting to
analyze some reasonable subset of the design, at least a few nets that
participate in a tight bus protocol, in a functional manner. At this time
the simulator would have to accurately model the propagation time(s) through
the component. The only reason I bring this up is because we seem to agree
that the seemingly endless stream of enhancements that IBIS needs to keep up
with technology, is causing us pain. We can at least try to make our changes
last a little longer. OK, now I can return to discussing what this BIRD *does*
address (steps down from soap box).

Are IBIS models limited to having only one [Receiver Delay] table? If so,
how do we specify separate corrections for rising and falling inputs? I would
expect that at least two tables would be required, one with Start_point less
than End_point (rise), and one with Start_point greater than End_point (fall).
It is not clear to me that this would be allowed, and I would expect the
specification to have an example showing both rise and fall. I would not expect
to use a single table "in reverse" to determine falling switch time corrections.

Mike

Stephen Peters wrote:
> 
> Hello All:
> 
>    Following is the first in a series of BIRDS that aim to enhance
> IBIS's ability to specifying and characterizing receivers.  Comments
> appreciated.
> 
>    Regards,
>    Stephen Peters
>    Intel Corp.
> 
> ===================================
> 
>                  Buffer Issue Resolution Document  (BIRD)
> 
> BIRD ID#:   61
> ISSUE TITLE: Enhanced Characterization of Receivers
> REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters,
>            Arpad Muranyi (Intel Corp)
> DATE SUBMITTED: August 9, 1999
> DATE ACCEPTED BY IBIS OPEN FORUM:
> 
> *******************************************************************************
...
From owner-ibis  Thu Aug 12 16:35:27 1999
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA17100 for <ibis-users@eda.org>; Thu, 12 Aug 1999 16:35:26 -0700 (PDT)
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63])
	by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA25380;
	Thu, 12 Aug 1999 16:28:35 -0700 (PDT)
Message-Id: <199908122328.QAA25380@jasper.cisco.com>
Date: Thu, 12 Aug 1999 16:28:34 -0700 (PDT)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: Re: IBIS 3.2 Generation tool
To: ibis-users@eda.org, Graham.Connolly@fairchildsemi.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: jXhIgf/kRpOwiijqLasTEA==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc 

Graham,

I am not sure if you got an answer to this ques below. A sub committee has been formed
to look into the next generation SPICE-to-IBIS conversion pgm. I am part of the team
and we are addressing various aspect to this issue. Funding is one of them.

Syed
Cisco Systems, Inc

> Is the user group looking for funding
> to generate the code (NCSU?)
> 
> 
> Thank You for assistance
> 
> Please advise
> 
> 
> 
> 
> Graham Connolly
> Fairchild Semiconductor
> Applications and Modelling
> 207-775-4579
> 

From owner-ibis  Fri Aug 13 06:26:30 1999
Received: from fairchild-bh.fairchildsemi.com (fairchild-bh.fairchildsemi.com [192.233.132.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA21327 for <ibis-users@eda.org>; Fri, 13 Aug 1999 06:26:30 -0700 (PDT)
Received: (from uucp@localhost) by fairchild-bh.fairchildsemi.com (8.8.8/8.6.11) id JAA12354 for <ibis-users@eda.org>; Fri, 13 Aug 1999 09:20:08 -0400 (EDT)
Received: from mailsort.fairchildsemi.com(172.21.18.6) by fairchild-bh.fairchildsemi.com via smap (4.1)
	id xma012145; Fri, 13 Aug 99 09:19:38 -0400
Received: from fmis02.fairchildsemi.com by fairchildsemi.com (SMI-8.6/SMI-SVR4)
	id JAA10991; Fri, 13 Aug 1999 09:17:19 -0400
Received: from fairchildsemi.com (cklein-fm.fairchildsemi.com)
 by spf.fairchildsemi.com (PMDF V5.1-12 #24455)
 with ESMTP id <01JEPPDO8TNM94HIPB@spf.fairchildsemi.com> for
 ibis-users@eda.org; Fri, 13 Aug 1999 09:20:49 EDT
Date: Fri, 13 Aug 1999 09:19:37 -0400
From: Christian Klein <Christian.Klein@fairchildsemi.com>
Subject: V/T Question
To: "ibis-users@eda.org" <ibis-users@eda.org>
Message-id: <37B41B69.D34C00D3@fairchildsemi.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
Content-type: multipart/mixed; boundary="------------32792B530DBE207093A6541D"
X-Accept-Language: en,pt-BR

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

Greetings everyone I am new to this list and IBIS, so I have a few
questions regarding model making.
One question is on extracting rising and falling waveforms.  In the
cookbook (pg. 11)  it says: "If the device does not have enough drive
capability to make a significant output transition then a higher value
of load resistance may be used,..."
I am unsure about the words "significant output transition".   Does it
mean not reaching the Data Sheet Vol or Voh?

Thanks in advance,

Christian Klein

--------------32792B530DBE207093A6541D
Content-Type: text/x-vcard; charset=us-ascii;
 name="Christian.Klein.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christian Klein
Content-Disposition: attachment;
 filename="Christian.Klein.vcf"

begin:vcard 
n:Klein;Christian
tel;work:(207) 761-6242
x-mozilla-html:FALSE
org:Fairchild Semiconductor
adr:;;;;;;
version:2.1
email;internet:Christian.Klein@fairchildsemi.com
title:Applications Engineer
fn:Christian Klein
end:vcard

--------------32792B530DBE207093A6541D--

From owner-ibis  Fri Aug 13 07:43:27 1999
Received: from osiris.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA21492 for <ibis-users@eda.org>; Fri, 13 Aug 1999 07:43:26 -0700 (PDT)
Received: (from smtp@localhost)
	by osiris.vlsi.com (8.9.1a/8.9.1) id HAA07038;
	Fri, 13 Aug 1999 07:36:31 -0700 (PDT)
X-Authentication-Warning: osiris.vlsi.com: smtp set sender to <dc.sessions@vlsi.com> using -f
Received: from <dc.sessions@vlsi.com> (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by osiris.vlsi.com via smap (V2.0)
	id xma007032; Fri, 13 Aug 99 07:36:28 -0700
Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id Q1NCKTAS; Fri, 13 Aug 1999 07:36:27 -0700
Sender: dsession@osiris.vlsi.com
Message-ID: <37B42D6B.8B484547@vlsi.com>
Date: Fri, 13 Aug 1999 07:36:27 -0700
From: "D. C. Sessions" <dc.sessions@vlsi.com>
Organization: VLSI Technology Inc.
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: "ibis-users@eda.org" <ibis-users@eda.org>
CC: Christian Klein <Christian.Klein@fairchildsemi.com>
Subject: Re: V/T Question
References: <37B41B69.D34C00D3@fairchildsemi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christian Klein wrote:
> 
> Greetings everyone I am new to this list and IBIS, so I have a few
> questions regarding model making.
> One question is on extracting rising and falling waveforms.  In the
> cookbook (pg. 11)  it says: "If the device does not have enough drive
> capability to make a significant output transition then a higher value
> of load resistance may be used,..."
> I am unsure about the words "significant output transition".   Does it
> mean not reaching the Data Sheet Vol or Voh?

Nothing so clear-cut.

It means that if the peak delta-V is MUCH less than the open-circuit swing
(supply voltage) then you've lost too much detail and should change the
loading to get more.  A pretty good target is to have they TYP swing
be about half of supply.

-- 
D. C. Sessions
dc.sessions@vlsi.com
From owner-ibis  Sun Aug 15 15:07:02 1999
Received: from gonzo.wolfenet.com (root@sea-pm3-3-p218.wolfenet.com [206.159.28.218]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA26934; Sun, 15 Aug 1999 15:06:55 -0700 (PDT)
Received: (from green@localhost)
	by gonzo.wolfenet.com (8.9.3/8.9.3) id OAA12848;
	Sun, 15 Aug 1999 14:59:00 -0700
Message-ID: <XFMail.990815145900.green@wolfenet.com>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199908112031.NAA19039@xtg801.pdx.intel.com>
Date: Sun, 15 Aug 1999 14:59:00 -0700 (PDT)
Reply-To: green@wolfenet.com
Sender: green@gonzo.wolfenet.com
From: Lynne Green <green@wolfenet.com>
To: lgreen@hyperlnx.com
Subject: Re: BIRD #61 -- Characterization of Receivers
Cc: ibis-users@eda.org, ibis@eda.org, nikolai@avanticorp.com


>> 
A NEGATIVE delay is possible for ANY logic circuit. Example: a simple inverter,
with its threshold at any level except exactly Vcc/2.  Apply a slow ramp, and
measure the 50% to 50% delay.  It will be negative for either the rising or
falling edge (depending on whether the threshold was under/over Vcc/2).  
This happens because logic gates switch when they reach a voltage threshold
determined by transistor sizing.

While I would not expect a negative delay for most I/O, it is certainly not
forbidden at light loading.  And a negative increment in delay is almost certain
at light loading, as pointed out by others.

Lynne Green
HyperLynx


>> *********
>> *   3   *
>> *********
>> 
>> 3) Some delays are negative. This is very very bad.
>>    Should be always positive. Just from stand point of
>>    causality. You apply a signal and then 1ns BEFORE that event
>>    your receiver tells you the signal has arrived.
>>    Simulators have to add some 'base' delay.
>>    Simulator_A will add 1ns, Simulator_B will add 10ns, etc.
>>    Why not IBIS spec add this 'base' delay and all have
>>    less headahe?
>> 
> 
>      >>> As I pointed out above, the intent is to show the change in
>          propagation delay, and a negative change is perfectly OK.  
>          Now, you do raise a good issue about 'base delay'.  I do not know
>          if base delay is an important variable in constructing a 
>          behavioral receiver model, of if different simulators will come
>          up with different models because they assumed different base
>          delays.  I do assume base delay can be approximated by looking 
>          at the setup time specification for a particular pin.  I hesitate,
>          however, to have IBIS spec a 'base delay' -- at least not without
>          a lot of simulator vendor input.
>> 

----------------------------------
E-Mail: Lynne Green <green@wolfenet.com>
Date: 15-Aug-99
Time: 14:46:38

This message was sent by XFMail
----------------------------------
From owner-ibis  Fri Aug 20 06:13:53 1999
Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA26251 for <ibis-users@eda.org>; Fri, 20 Aug 1999 06:13:53 -0700 (PDT)
Received: from fedex.micro.ti.com ([158.218.57.246])
	by jester.ti.com (8.9.3/8.9.3) with ESMTP id IAA05493
	for <ibis-users@eda.org>; Fri, 20 Aug 1999 08:06:50 -0500 (CDT)
Received: from micro.ti.com (ravens.micro.ti.com [158.218.57.36])
	by fedex.micro.ti.com (8.9.3/8.9.3) with ESMTP id IAA29324
	for <ibis-users@eda.org>; Fri, 20 Aug 1999 08:06:56 -0500 (CDT)
Sender: fscales@micro.ti.com
Message-ID: <37BD52E9.BA2384AA@micro.ti.com>
Date: Fri, 20 Aug 1999 08:06:49 -0500
From: Fanny scales <fscales@micro.ti.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis-users@eda.org
Subject: From Spice to IBIS model
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Good morning,

I would like to generate IBIs model from  Spice simualtion ( print file)

Currently,I'm generating spice simulation  with input buffer or output
buffer
to extract the  current  . But  I need to understand which current I
have to take  in account
I would like to extract the current values:
for input buffer:GND_clamp and Power Clamp
for ouput buffer: GND_clamp, Power_clamp ,Pullup ,Pulldown

Could you tell me where I have to observe the current for each  Spice
simulation ?
thank you for your help.
Could you send me an example  of  spice deck files  to have a global
idea    ?

regards
Fanny

From owner-ibis  Fri Aug 20 08:26:01 1999
Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA26815 for <ibis-users@eda.org>; Fri, 20 Aug 1999 08:26:00 -0700 (PDT)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id IAA09109;
	Fri, 20 Aug 1999 08:30:11 -0700 (PDT)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id IAA17823;
	Fri, 20 Aug 1999 08:19:35 -0700 (PDT)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id IAA02749;
	Fri, 20 Aug 1999 08:19:34 -0700 (PDT)
Message-Id: <199908201519.IAA02749@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: Fanny scales <fscales@micro.ti.com>
cc: ibis-users@eda.org
Subject: Re: From Spice to IBIS model 
In-reply-to: Your message of "Fri, 20 Aug 1999 08:06:49 CDT."
             <37BD52E9.BA2384AA@micro.ti.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 20 Aug 1999 08:19:34 -0700
From: Stephen Peters <sjpeters@ichips.intel.com>


Hello Fanny:

   I have a couple of suggestions.  One would be to get a copy of the
IBIS cookbook.  The cookbook gives a general outline of how to extract
the data for building an IBIS model using SPICE simulations.  Once you
understand the process you could also download s2ibis.  This is an
program that automates the extraction process.  Both the cookbook and
s2ibis are available at the IBIS web site

   www.eia.org/eig/ibis/ibis.htm

  Regards,
  Stephen Peters
  Intel Corp.

> Good morning,
> 
> I would like to generate IBIs model from  Spice simualtion ( print file)
> 
> Currently,I'm generating spice simulation  with input buffer or output
> buffer
> to extract the  current  . But  I need to understand which current I
> have to take  in account
> I would like to extract the current values:
> for input buffer:GND_clamp and Power Clamp
> for ouput buffer: GND_clamp, Power_clamp ,Pullup ,Pulldown
> 
> Could you tell me where I have to observe the current for each  Spice
> simulation ?
> thank you for your help.
> Could you send me an example  of  spice deck files  to have a global
> idea    ?
> 
> regards
> Fanny


From owner-ibis  Mon Aug 23 07:01:23 1999
Received: from yalta.NL.net (yalta.NL.net [193.67.79.154]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA20743 for <ibis-users@eda.org>; Mon, 23 Aug 1999 07:01:21 -0700 (PDT)
Received: from 1Cust208.tnt8.dial.ams3.nl.uu.net ([212.136.248.208]:60421 "HELO portis" ident: "NO-IDENT-SERVICE[2]") by yalta.NL.net with SMTP id <14744-28327>; Mon, 23 Aug 1999 15:54:34 +0200
Reply-To: <w.hamhuis@easeurope.com>
From: "Wilco Hamhuis" <w.hamhuis@easeurope.com>
To: "Ibis-Users" <ibis-users@eda.org>
Subject: USB connector model
Date: Mon, 23 Aug 1999 15:55:04 +0200
Message-ID: <008601beed6f$1a29eaa0$993557c0@portis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

I have two short questions: Is IBIS capable of describing a (coupled)
connector? Are there IBIS USB connector models available? I am currently
analysing a high speed board (app. 500 MHz) and I want to take the effect of
connectors into account.

Kind regards,
Wilco Hamhuis
___________________________________________________
Wilco Hamhuis
HSSD Consulting Engineer
tel: +31 (0)547 367 347     fax: +31 (0)547 367 340
EASEurope   Goorseweg 5
7475 BB Markelo, the Netherlands
Website: www.EASEurope.com
___________________________________________________


From owner-ibis  Mon Aug 23 10:19:15 1999
Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA21351 for <ibis-users@eda.org>; Mon, 23 Aug 1999 10:19:14 -0700 (PDT)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id KAA01857;
	Mon, 23 Aug 1999 10:23:21 -0700 (PDT)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id KAA28498;
	Mon, 23 Aug 1999 10:12:44 -0700 (PDT)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id KAA26592;
	Mon, 23 Aug 1999 10:12:43 -0700 (PDT)
Message-Id: <199908231712.KAA26592@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: w.hamhuis@easeurope.com
cc: "Ibis-Users" <ibis-users@eda.org>
Subject: Re: USB connector model 
In-reply-to: Your message of "Mon, 23 Aug 1999 15:55:04 +0200."
             <008601beed6f$1a29eaa0$993557c0@portis> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 23 Aug 1999 10:12:42 -0700
From: Stephen Peters <sjpeters@ichips.intel.com>


Wilco Hamhuis writes:
> I have two short questions: Is IBIS capable of describing a (coupled)
> connector? Are there IBIS USB connector models available? I am currently
> analysing a high speed board (app. 500 MHz) and I want to take the effect of
> connectors into account.

  There is an IBIS working group that has proposed an IBIS extension for
connectors that supports coupling, but it has not yet become
a part of the official standard.  If you are interested, a copy of the 
proposal is on the Hyperlynx website at www.hyperlynx.com.  As for your
specific need, I am not aware of any IBIS USB connector models, but others
may know of some.


   Regards,
   Stephen Peters
   Intel Corp.
   Vice Chair, EIA/IBIS Open Forum

From owner-ibis  Mon Aug 23 10:35:31 1999
Received: from hazard.hyperlynx.com (root@[209.20.246.211]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA21427 for <ibis-users@eda.org>; Mon, 23 Aug 1999 10:35:30 -0700 (PDT)
Received: from squidge ([192.168.148.61])
	by hazard.hyperlynx.com (8.9.3/8.9.3) with SMTP id KAA31147;
	Mon, 23 Aug 1999 10:26:21 -0700
Message-ID: <000601beed8c$f97373d0$3d94a8c0@hyperlynx.com>
From: "Matthew Flora" <mbflora@hyperlynx.com>
To: <w.hamhuis@easeurope.com>
Cc: "Ibis-Users" <ibis-users@eda.org>
References: <199908231712.KAA26592@xtg801.pdx.intel.com>
Subject: Re: USB connector model 
Date: Mon, 23 Aug 1999 10:28:54 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

> Wilco Hamhuis writes:
> > I have two short questions: Is IBIS capable of describing a (coupled)
> > connector? Are there IBIS USB connector models available? I am currently
> > analysing a high speed board (app. 500 MHz) and I want to take the effect
of
> > connectors into account.
>
>   There is an IBIS working group that has proposed an IBIS extension for
> connectors that supports coupling, but it has not yet become
> a part of the official standard.  If you are interested, a copy of the
> proposal is on the Hyperlynx website at www.hyperlynx.com.  As for your
> specific need, I am not aware of any IBIS USB connector models, but others
> may know of some.

Actually, the proposed IBIS extension for connectors can best be found at:
ftp://ftp.eda.org/pub/ibis/connector/

Regards,
Matthew Flora
IBIS Open Forum Postmaster
(425) 869-2320 PH
(425) 881-1008 FAX
mbflora@hyperlynx.com
HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA


From owner-ibis  Mon Aug 23 11:09:25 1999
Received: from rgate.ricochet.net (rgate1.ricochet.net [204.179.143.6]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA21614 for <ibis-users@eda.org>; Mon, 23 Aug 1999 11:09:20 -0700 (PDT)
Received: from hyperstar (mg-206191146-116.ricochet.net [206.191.146.116])
	by rgate.ricochet.net (8.9.3/8.9.3) with SMTP id NAA24585;
	Mon, 23 Aug 1999 13:02:49 -0500 (CDT)
Message-Id: <199908231802.NAA24585@rgate.ricochet.net>
X-Sender: kellee@pop.nwlink.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 23 Aug 1999 10:56:02 -0700
To: ibis-users@eda.org, "Matthew Flora" <mbflora@hyperlynx.com>
From: Kellee Crisafulli <kellee@hyperlynx.com>
Subject: Re: USB connector model 
In-Reply-To: <000601beed8c$f97373d0$3d94a8c0@hyperlynx.com>
References: <199908231712.KAA26592@xtg801.pdx.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi Ibisians, Matt,

  Matt thanks for giving the correct web address for the preliminary
connector specification.

FYI.. The only outstanding item in the connector specification is to agree
on the
wording of the RLC matrix description.  I have asked several industry
experts to
write it and have not received one from anyone yet.  If someone else out their
would like to contribute a technically correct RLC matrix description that
would
allow someone "skilled in the art" to understand which type of RLC matrix
is being
used I am interested.  If I end up with more than one I would be extremely
happy.
It must have a simple included example of both a physical cross section and
the
resulting matrices.  Ideally it would explain things like what the diagonal
is and
why there are sometimes negative signs.
When we receive this and the connector sub-group reviews it and accepts it
I believe we are ready to give it to the IBIS group as a bird.

At 10:28 AM 8/23/99 -0700, you wrote:
>> Wilco Hamhuis writes:
>> > I have two short questions: Is IBIS capable of describing a (coupled)
>> > connector? Are there IBIS USB connector models available? I am currently
>> > analysing a high speed board (app. 500 MHz) and I want to take the effect
>of
>> > connectors into account.
>>
>>   There is an IBIS working group that has proposed an IBIS extension for
>> connectors that supports coupling, but it has not yet become
>> a part of the official standard.  If you are interested, a copy of the
>> proposal is on the Hyperlynx website at www.hyperlynx.com.  As for your
>> specific need, I am not aware of any IBIS USB connector models, but others
>> may know of some.
>
>Actually, the proposed IBIS extension for connectors can best be found at:
>ftp://ftp.eda.org/pub/ibis/connector/
>
>Regards,
>Matthew Flora
>IBIS Open Forum Postmaster
>(425) 869-2320 PH
>(425) 881-1008 FAX
>mbflora@hyperlynx.com
>HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA
> 
From owner-ibis  Tue Aug 24 01:59:59 1999
Received: from noya.bupt.edu.cn (noya.bupt.edu.cn [202.112.96.2]) by server.eda.org (8.8.5/8.8.3) with ESMTP id BAA01222 for <ibis-users@eda.org>; Tue, 24 Aug 1999 01:59:52 -0700 (PDT)
Received: from apony ([202.112.109.69])
	by noya.bupt.edu.cn (8.9.3/8.9.1) with SMTP id QAA08805
	for <ibis-users@eda.org>; Tue, 24 Aug 1999 16:48:54 +0900 (CDT)
Message-Id: <199908240748.QAA08805@noya.bupt.edu.cn>
Date: Tue, 24 Aug 1999 16:56:39 +0800
From: Jinghong Ma <y9672232@bupt.edu.cn>
Reply-To: y9672232@bupt.edu.cn
To: "ibis-users@eda.org" <ibis-users@eda.org>
Subject: KG75's IBIS model
Organization: BUPT
X-mailer: FoxMail 2.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Sir,

       My Inc. of GWTT is developing systems with SAMSUNG's KG75. 
Now I need its IBIS model to do Signal Integrity Analysis with XTK. I 
cannot find it from www.eia.org, nor can I find it from Samsung's web 
page. Somebody suggested me seek advice from you, can you give 
me some help?

      Thanks very much.


Sincerely,

      Jinghong Ma
      GW Telecom. Tech.

From owner-ibis  Tue Aug 24 14:00:15 1999
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA04043 for <ibis-users@eda.org>; Tue, 24 Aug 1999 14:00:14 -0700 (PDT)
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63])
	by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA04044;
	Tue, 24 Aug 1999 13:53:18 -0700 (PDT)
Message-Id: <199908242053.NAA04044@jasper.cisco.com>
Date: Tue, 24 Aug 1999 13:53:17 -0700 (PDT)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: Re: KG75's IBIS model
To: ibis-users@eda.org, y9672232@bupt.edu.cn
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: T7TsLaVh7S+kmupvKPifAQ==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc 

Jinghong,

Your best bet would be to talk to the manufacturer directly. I believe that
would be Samsung. Sometimes if the product is in development and not released
to production, it may not be available on the web but could be obtained from
the vendor directly.

Regards,
Syed
Cisco Systems, Inc

> X-SMAP-Received-From: outside
> Date: Tue, 24 Aug 1999 16:56:39 +0800
> From: Jinghong Ma <y9672232@bupt.edu.cn>
> To: "ibis-users@eda.org" <ibis-users@eda.org>
> Subject: KG75's IBIS model
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> Dear Sir,
> 
>        My Inc. of GWTT is developing systems with SAMSUNG's KG75. 
> Now I need its IBIS model to do Signal Integrity Analysis with XTK. I 
> cannot find it from www.eia.org, nor can I find it from Samsung's web 
> page. Somebody suggested me seek advice from you, can you give 
> me some help?
> 
>       Thanks very much.
> 
> 
> Sincerely,
> 
>       Jinghong Ma
>       GW Telecom. Tech.
> 

From owner-ibis  Wed Aug 25 17:32:38 1999
Received: from corvia.com ([206.86.192.114]) by server.eda.org (8.8.5/8.8.3) with SMTP id RAA11179 for <ibis-users@eda.org>; Wed, 25 Aug 1999 17:32:38 -0700 (PDT)
Received: (qmail+freegate 20878 invoked by alias); 26 Aug 1999 00:26:11 -0000
Received: from ws103-n0.hq.uniant.com (HELO dan) (192.168.10.103)
  by hq.uniant.com with SMTP; 26 Aug 1999 00:26:11 -0000
Message-ID: <011001beef49$29426220$670aa8c0@hq.uniant.com>
From: "Dan Bostan" <dan@uniant.com>
To: <ibis-users@eda.org>
Subject: subscribe
Date: Wed, 25 Aug 1999 17:28:31 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_010D_01BEEF1F.405FFE10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_010D_01BEEF1F.405FFE10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






------=_NextPart_000_010D_01BEEF1F.405FFE10
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>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2><BR></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_010D_01BEEF1F.405FFE10--

From owner-ibis  Wed Aug 25 17:33:25 1999
Received: from corvia.com ([206.86.192.114]) by server.eda.org (8.8.5/8.8.3) with SMTP id RAA11188 for <ibis-users@eda.org>; Wed, 25 Aug 1999 17:33:25 -0700 (PDT)
Received: (qmail+freegate 20893 invoked by alias); 26 Aug 1999 00:26:59 -0000
Received: from ws103-n0.hq.uniant.com (HELO dan) (192.168.10.103)
  by hq.uniant.com with SMTP; 26 Aug 1999 00:26:59 -0000
Message-ID: <011901beef49$456bb410$670aa8c0@hq.uniant.com>
From: "Dan Bostan" <dan@uniant.com>
To: <ibis-users@eda.org>
Subject: BTE models
Date: Wed, 25 Aug 1999 17:29:18 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0116_01BEEF1F.5C8669D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0116_01BEEF1F.5C8669D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Does anybody have IBIS/Viewlogic/HSpice models for SN74ABTE16245 and
SN74ABTE16246 (TI)?
If yes, may I get them?
Thank you.

Dan Bostan
Engineer                                           =20
Corvia Networks                           e-mail: dan@corvia.com
212 Gibraltar Dr.                          ph:      408.752.0550/x111
Sunnyvale, CA 94089                  fax:     408.752.0551




------=_NextPart_000_0116_01BEEF1F.5C8669D0
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>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Does anybody have IBIS/Viewlogic/HSpice models for=20
SN74ABTE16245 and<BR>SN74ABTE16246 (TI)?<BR>If yes, may I get =
them?<BR>Thank=20
you.<BR></FONT></DIV>
<DIV><FONT size=3D2>Dan=20
Bostan<BR>Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>Corvia=20
Networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
e-mail: <A href=3D"mailto:dan@corvia.com">dan@corvia.com</A><BR>212 =
Gibraltar=20
Dr.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
ph:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 408.752.0550/x111<BR>Sunnyvale, CA=20
94089&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
fax:&nbsp;&nbsp;&nbsp;&nbsp; 408.752.0551</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2><BR></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0116_01BEEF1F.5C8669D0--

From owner-ibis  Wed Aug 25 19:54:28 1999
Received: from exchtp02.via.com.tw (exchange2.via.com.tw [202.145.217.249]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA11583 for <ibis-users@eda.org>; Wed, 25 Aug 1999 19:54:27 -0700 (PDT)
Received: by EXCHANGE2 with Internet Mail Service (5.5.2232.9)
	id <QP92F7R3>; Thu, 26 Aug 1999 10:47:37 +0800
Message-ID: <9BADB79F06B3D211974800A0C92BD8A00163AADF@EXCHANGE2>
From: Tina Wu <TinaWu@via.com.tw>
To: "'Kellee Crisafulli'" <kellee@hyperlynx.com>
Cc: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: RE: USB connector model 
Date: Thu, 26 Aug 1999 10:47:36 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="BIG5"



-----Original Message-----
From: Kellee Crisafulli [mailto:kellee@hyperlynx.com]
Sent: Tuesday, August 24, 1999 1:56 AM
To: ibis-users@eda.org; Matthew Flora
Subject: Re: USB connector model 


Hi Ibisians, Matt,

  Matt thanks for giving the correct web address for the preliminary
connector specification.

FYI.. The only outstanding item in the connector specification is to agree
on the
wording of the RLC matrix description.  I have asked several industry
experts to
write it and have not received one from anyone yet.  If someone else out
their
would like to contribute a technically correct RLC matrix description that
would
allow someone "skilled in the art" to understand which type of RLC matrix
is being
used I am interested.  If I end up with more than one I would be extremely
happy.
It must have a simple included example of both a physical cross section and
the
resulting matrices.  Ideally it would explain things like what the diagonal
is and
why there are sometimes negative signs.


It said that no coupling, so the matrix is diagonal .
And  capacitors are negative signs, because those are 
coefficients of induction ( cij ), we must convert them to
mutual partial capacitances ( Cij = -cij ) 


When we receive this and the connector sub-group reviews it and accepts it
I believe we are ready to give it to the IBIS group as a bird.

At 10:28 AM 8/23/99 -0700, you wrote:
>> Wilco Hamhuis writes:
>> > I have two short questions: Is IBIS capable of describing a (coupled)
>> > connector? Are there IBIS USB connector models available? I am
currently
>> > analysing a high speed board (app. 500 MHz) and I want to take the
effect
>of
>> > connectors into account.
>>
>>   There is an IBIS working group that has proposed an IBIS extension for
>> connectors that supports coupling, but it has not yet become
>> a part of the official standard.  If you are interested, a copy of the
>> proposal is on the Hyperlynx website at www.hyperlynx.com.  As for your
>> specific need, I am not aware of any IBIS USB connector models, but
others
>> may know of some.
>
>Actually, the proposed IBIS extension for connectors can best be found at:
>ftp://ftp.eda.org/pub/ibis/connector/
>
>Regards,
>Matthew Flora
>IBIS Open Forum Postmaster
>(425) 869-2320 PH
>(425) 881-1008 FAX
>mbflora@hyperlynx.com
>HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA
> 
From owner-ibis  Wed Aug 25 23:24:46 1999
Received: from btmplq.god.bel.alcatel.be (gate.alcatel.be [195.207.101.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id XAA12038 for <ibis-users@eda.org>; Wed, 25 Aug 1999 23:24:44 -0700 (PDT)
Received: from btm04u.sh.bel.alcatel.be (btm04u.sh.bel.alcatel.be [138.203.194.104])
	by btmplq.god.bel.alcatel.be (8.9.1a/8.9.1) with ESMTP id IAA15546
	for <ibis-users@eda.org>; Thu, 26 Aug 1999 08:18:04 +0200 (MET DST)
Received: from sh.bel.alcatel.be (btmp8u [138.203.193.195]) by btm04u.sh.bel.alcatel.be (8.7/8.7) with ESMTP id IAA21201 for <ibis-users@eda.org>; Thu, 26 Aug 1999 08:20:28 +0200 (MET DST)
Sender: bervoett@sh.bel.alcatel.be
Message-ID: <37C4DCAB.68B9173A@sh.bel.alcatel.be>
Date: Thu, 26 Aug 1999 08:20:27 +0200
From: Tom Bervoets <bervoett@sh.bel.alcatel.be>
Organization: Alcatel
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4m)
MIME-Version: 1.0
To: ibis-users@eda.org
Subject: unsubsribe
Content-Type: multipart/alternative; boundary="------------0203CCD289A73E42D8A0FA74"


--------------0203CCD289A73E42D8A0FA74
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



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

<HTML>

<PRE></PRE>
&nbsp;</HTML>

--------------0203CCD289A73E42D8A0FA74--

From owner-ibis  Thu Aug 26 01:28:18 1999
Received: from exch-staff.livjm.ac.uk (exch-staff.livjm.ac.uk [150.204.254.54]) by server.eda.org (8.8.5/8.8.3) with ESMTP id BAA13468 for <ibis-users@eda.org>; Thu, 26 Aug 1999 01:28:17 -0700 (PDT)
Received: from edam11 (nowrec11.livjm.ac.uk [150.204.52.11]) by exch-staff.livjm.ac.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10)
	id Q4JYGAS5; Thu, 26 Aug 1999 09:21:25 +0100
Message-ID: <000e01beef9c$4d5d7660$0b34cc96@livjm.ac.uk>
From: "Tommy Wong" <eeemwong@livjm.ac.uk>
To: <ibis-users@eda.org>
Subject: unsubscribe
Date: Thu, 26 Aug 1999 09:23:40 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01BEEFA4.AF173000"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01BEEFA4.AF173000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



------=_NextPart_000_000B_01BEEFA4.AF173000
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>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000B_01BEEFA4.AF173000--

From owner-ibis  Fri Aug 27 10:15:42 1999
Received: from tekincisnts-4.teklogix.com (mail.teklogix.com [207.219.2.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA20744 for <ibis-users@eda.org>; Fri, 27 Aug 1999 10:15:41 -0700 (PDT)
Received: by TEKINCISNTS-4 with Internet Mail Service (5.5.2232.9)
	id <RP0DK8VM>; Fri, 27 Aug 1999 13:08:39 -0400
Message-ID: <CB0B58CCDF98D111923E0060B03C5C5064AE65@TEKINCISNTS-4>
From: Larry Forsythe <lforsyth@mail.teklogix.com>
To: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: IBIS in simulation
Date: Fri, 27 Aug 1999 13:08:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain

I'm confused about how IBIS is used in actual simulations. I haven't seen
any articles about this (please indicate if there are some). What I'm
confused about is how can a few static I-V curves and some V-T curves done
at specific loads be used to simulate other loads. The I-V curves involve
fully on transistors. The V-T curves involve partially turned-on transistors
driving a specific load. Is it valid to scale the I-V curves using the V-T
curves in order to derive the response to driving other loads? Can the I-V
curves and V-T curves be used to determine the characteristics of a
partially turned on transistor driving a different load-I guess that is the
source of my confusion.

Please unconfuse me.

Thanks

Larry Forsythe
lforsyth@teklogix.com
From owner-ibis  Mon Aug 30 11:01:52 1999
Received: from mail01-oak.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA02308 for <ibis-users@eda.org>; Mon, 30 Aug 1999 11:01:51 -0700 (PDT)
Received: from idt.com (unknown-5-20.idt.com [157.165.5.20] (may be forged)) by mail01-oak.pilot.net with ESMTP id KAA19962 for <ibis-users@eda.org>; Mon, 30 Aug 1999 10:55:21 -0700 (PDT)
Received: from Eng.idt.com (root@maxwell.Eng.idt.com [157.165.21.24]) by idt.com (8.8.5/8.7.5) with ESMTP id KAA20358 for <ibis-users@eda.org>; Mon, 30 Aug 1999 10:55:19 -0700 (PDT)
Received: from mig.Eng.idt.com (mig.Eng.idt.com [157.165.31.143]) by Eng.idt.com (8.8.5/8.6.12) with ESMTP id KAA10630 for <ibis-users@eda.org> ; Mon, 30 Aug 1999 10:55:19 -0700 (PDT)
From: Roy Gao <Roy.Gao@idt.com>
Received: (rgao@localhost) by mig.Eng.idt.com (8.6.12/8.6.12) id KAA15030 for ibis-users@eda.org; Mon, 30 Aug 1999 10:55:21 -0700
Date: Mon, 30 Aug 1999 10:55:21 -0700
Message-Id: <199908301755.KAA15030@mig.Eng.idt.com>
To: ibis-users@eda.org
Subject: IBIS questions.

Dr Mr.,

I usually use Hspice for IBIS model creation. Now I'd like to use spectre, I wonder if you can tell me the syntax of '[Spice command]'?

Should it be like hspice?

[Spice command]		spectre %s %s > %s


Thanks.
From owner-ibis  Mon Aug 30 11:14:34 1999
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA02381 for <ibis-users@eda.org>; Mon, 30 Aug 1999 11:14:34 -0700 (PDT)
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63])
	by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id LAA12243;
	Mon, 30 Aug 1999 11:07:36 -0700 (PDT)
Message-Id: <199908301807.LAA12243@jasper.cisco.com>
Date: Mon, 30 Aug 1999 11:07:35 -0700 (PDT)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: Re: IBIS questions.
To: ibis-users@eda.org, Roy.Gao@idt.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: OO45In/BDUmIO0Ae1bn9Qg==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc 

I have not used Spectre but src/s2istrng.h mentions the following usage:

spectre -f nutascii -c 132 %s -r %s >%s

Regards,
Syed.
Cisco Systems, Inc

> X-SMAP-Received-From: outside
> From: Roy Gao <Roy.Gao@idt.com>
> Date: Mon, 30 Aug 1999 10:55:21 -0700
> To: ibis-users@eda.org
> Subject: IBIS questions.
> 
> Dr Mr.,
> 
> I usually use Hspice for IBIS model creation. Now I'd like to use spectre, I 
wonder if you can tell me the syntax of '[Spice command]'?
> 
> Should it be like hspice?
> 
> [Spice command]		spectre %s %s > %s
> 
> 
> Thanks.

From owner-ibis  Mon Aug 30 18:48:20 1999
Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA03495 for <ibis-users@eda.org>; Mon, 30 Aug 1999 18:48:19 -0700 (PDT)
Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id SAA27000
	for <ibis-users@eda.org>; Mon, 30 Aug 1999 18:52:26 -0700 (PDT)
Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0)
	id <RK8H63F2>; Mon, 30 Aug 1999 18:41:50 -0700
Message-ID: <B277BC01AFFAD211AC4E00A0C95D74033E93B5@fmsmsx66.fm.intel.com>
From: "Mirmak, Michael" <michael.mirmak@intel.com>
To: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: Series MOSFET modeling questions...
Date: Mon, 30 Aug 1999 18:41:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BEF351.FE220EB7"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BEF351.FE220EB7
Content-Type: text/plain;
	charset="iso-8859-1"


IBIS Experts,

I have created a template (enclosed) showing what I believe to be the proper
way to model a series MOSFET switch IC (yes, it passes the 3.2 parser!).
However, before I start using the template to create real models, I would
like to settle a few questions:

1) Is the selection of the Vds level for the IV table arbitrary?  Or is this
Vds level connected in some way to the pass voltage of the switch at Vcc?

2) It seems to me that the only way to model the enable pins of a switch --
the pins connected to the gates of the FET switches through internal logic
-- is either as "NC" or Terminator pins.  Is this correct?  Or is there some
other way to model the enable pins so that their function is preserved?

3) The latest parser did not flag errors when I created a model which had
the same sets of pin number pairs assigned to more than one control group
under the [Series Pin Mapping] keyword.  Is this intentional?

Thanks in advance!

- Michael Mirmak, Intel Corp.
  FM6-45
  1900 Prairie City Rd.
  Folsom, CA  95630
  (916) 356-4261
  (916) 377-1046 (FAX)
  michael.mirmak@intel.com


 <<s_switch.ibs>> 


------_=_NextPart_000_01BEF351.FE220EB7
Content-Type: application/octet-stream;
	name="s_switch.ibs"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="s_switch.ibs"

|
[IBIS Ver] 3.2
[File Name] s_switch.ibs
[File Rev] 0.0
[Date] August 28, 1999
[Source] From a silicon SPICE model simulation.
[Notes]=20
[Disclaimer] This is an example IBIS file only, for educational =
purposes,
| and is not to be used for system simulation.
[Copyright] 1999, Intel Corp.
[Component] GenericSeriesSwitch
| This is modeled on the industry standard x3384 pinout, 5V supply =
part.
| The VI curves are copied directly from the IBIS 3.2 specification!
[Manufacturer] Intel Corp.
|
[Package]=20
|             Typ    Min    Max
R_pkg         0.5    NA     NA
L_pkg         0.5nH  NA     NA
C_pkg         0.5pF  NA     NA
|
[Pin]       signal_name    model_name   R_pin   L_pin      C_pin
1           EA#            NC           | This is an enable pin     =20
2           B0             switch_terminator
3           A0             switch_terminator
4           A1             switch_terminator
5           B1             switch_terminator
6           B2             switch_terminator
7           A2             switch_terminator
8           A3             switch_terminator
9           B3             switch_terminator
10          B4             switch_terminator
11          A4             switch_terminator
12          GND            GND
13          EB#            NC           | This is an enable pin
14          A5             switch_terminator
15          B5             switch_terminator
16          B6             switch_terminator
17          A6             switch_terminator
18          B7             switch_terminator
19          A7             switch_terminator
20          B8             switch_terminator
21          A8             switch_terminator
22          A9             switch_terminator
23          B9             switch_terminator
24          VCC            POWER
|
[Series Pin Mapping]    pin_2       model_name         =
function_table_group
|
3                        2          switch_FET             EA
4                        5          switch_FET             EA
7                        6          switch_FET             EA
8                        9          switch_FET             EA
11                       10         switch_FET             EA
14                       15         switch_FET             EB
17                       16         switch_FET             EB
19                       18         switch_FET             EB
21                       20         switch_FET             EB
8                        9          switch_FET             EA
22                       23         switch_FET             EB
|
[Series Switch Groups]   =20
Off EA /
On  EA /
Off EB /
On  EB /
|******************************************************************
[Model]      switch_FET
Model_type   Series_switch
Enable       Active-Low
Vinl  =3D 0.8V
Vinh  =3D 2.0V
|         variable         typ        min       max
C_comp                     1.0pF      NA        NA
|
|                     typ             min            max
[Temperature Range]   25              100            0
[Voltage Range]       5.0             4.75           5.25
[On]
[Series MOSFET]
Vds =3D 1.0
| Voltage  I(typ)   I(min)    I(max)
5.0V       257.9m   153.3m    399.5m
4.0V       203.0m   119.4m    317.3m
3.0V       129.8m   74.7m     205.6m
2.0V       31.2m    16.6m      51.0m
1.0V       52.7p     46.7p     56.7p  =20
0.0V         0.0p    0.0p       0.0p
|
[Series MOSFET]
Vds =3D 0.8
| Voltage  I(typ)   I(min)    I(max)
5.0V       257.9m   153.3m    399.5m
4.0V       203.0m   119.4m    317.3m
3.0V       129.8m   74.7m     205.6m
2.0V       31.2m    16.6m      51.0m
1.0V       52.7p     46.7p     56.7p  =20
0.0V         0.0p    0.0p       0.0p
|
[Series MOSFET]
Vds =3D 1.3
| Voltage  I(typ)   I(min)    I(max)
5.0V       257.9m   153.3m    399.5m
4.0V       203.0m   119.4m    317.3m
3.0V       129.8m   74.7m     205.6m
2.0V       31.2m    16.6m      51.0m
1.0V       52.7p     46.7p     56.7p  =20
0.0V         0.0p    0.0p       0.0p
|
[Off]
[Series Current]
|this may require translation
|voltage       I(typ)           I(min)          I(max)
5.0V            0.01u             NA              1u
0.0V            0.01u             NA              1u
-1V               0               NA              0

|******************************************************************
|
|******************************************************************
[Model]      switch_terminator
Model_type   Terminator
Enable       Active-Low
|            variable         typ        min       max
C_comp                     1.0pF      NA        NA
|
|                     typ             min            max
[Temperature Range]   25              100            0
[Voltage Range]       5.0             4.75           5.25
|
[Rac]                 0               0            0
[Cac]                 0.5            NA            NA
|******************************************************************
[End]

------_=_NextPart_000_01BEF351.FE220EB7--
From owner-ibis  Tue Aug 31 13:28:23 1999
Received: from mail.nesa.com (mail.nesa.com [204.240.29.34]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA08414; Tue, 31 Aug 1999 13:28:19 -0700 (PDT)
Received: from porky (porky.nesa.com [204.240.29.45])
	by mail.nesa.com (8.9.3/8.9.3) with SMTP id PAA04258;
	Tue, 31 Aug 1999 15:53:16 -0400
Message-Id: <3.0.5.32.19990831155903.00987440@mail.nesa.com>
X-Sender: breda@mail.nesa.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 31 Aug 1999 15:59:03 -0400
To: ibis@eda.org, ibis-users@eda.org
From: Kathy Breda <breda@nesa.com>
Subject: IBIS SUMMIT 10/14/99 - CALL FOR PARTICIPATION, PRESENTATIONS &
  SPONSORSHIP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------------------------------------
IBIS SUMMIT 
	CALL FOR 
		PARTICIPATION, 
			PRESENTATIONS 
				& SPONSORSHIP!!!!
-------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

             I B I S   S U M M I T   M E E T I N G

Time/Date:      8:30 AM - 5:00 PM, Thursday, October 14, 1999

Location:       Marlboro Holiday Inn (NEW LOCATION FROM PAST 2 YEARS)
                265 Lakeside Ave. 
                Marlboro, MA
                Tel:  (508) 481-3000
                Fax:  (508) 480-8530
               
Content:        Presentations and Discussions

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

Sponsors:       North East Systems Associates, Inc. (NESA),
                Praegitzer Design (PII), 
                IBIS Users Group, 
                WE ARE LOOKING FOR ADDITIONAL SPONSORS! (contact Kathy
Breda, breda@nesa.com
                or Bob Ross, bob_ross@mentororg.com)

PCB Conference: October 11-15, 1999
East            Royal Plaza Trade Center
                Marlborough, Massachusetts
                See http://www.pcbeast.com/ for more information.

BACKGROUND

The IBIS Users Group (IBIS East) has been formed under the leadership of  
Dr. Edward Sayre from North East Systems Associates, Inc. (NESA) and has
been meeting
for a year to consider and forward IBIS model user concerns.  As a result of
regular East coast meetings, the group has developed an IBIS Accuracy
Specification document and has done work on formatting Connector Models.
These topic plus others of current interest to the EIA IBIS Open Forum
will be discussed at this meeting.

This meeting will be conducted as a formal IBIS Summit meeting.  Presentation
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 to the Summit meeting.  If you plan
to participate, please register with the information below:

  Name:
  E-mail address:
  Company:
  Telephone:

Send to:

  Kathy Breda (breda@nesa.com)
  

CALL FOR PRESENTATIONS

We are seeking presentations from individuals who have IBIS experiences
or issues.

Format of Presentation:  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.  Electronic presentations
                         should be made available by October 8, 1999.
                         Otherwise the presenter will be expected to provide
                         50 copies for distribution.


If you plan a presentation, please supply

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

  Estimate Time:

Send this to:

  Kathy Breda (breda@nesa.com)


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

Boxboro Holiday Inn.  
One Adams Place
Boxboro, MA
Tel:  (978) 263-8701
Fax:  (978) 263-0518

Royal Plaza Hotel 
  (PCB Conference East Rates guaranteed until September 12, 1998)
181 Boston Post road West
Marlborough, MA 01752
Tel:  (508) 460-0700

Marlboro Holiday Inn
265 Lakeside Ave. 
Marlboro, MA
Tel:  (508)481-3000

Radisson Inn
75 Felton St.
Marlboro, MA
Tel:  (508) 480-0015

Embassy Suites Hotels
123 Boston Post Rd.
West Marlboro, MA
(508) 485-5900

Amerscot House
61 West Acton Road
Stow, MA  01775
email: doreen@amerscot.com, web site http://www.amerscot.com
Tel: (508)897-0666, FAX (508)897-6914

Westford Regency Inn
219 Littleton Rd. (exit 32 off I-495)
Westford, MA
Tel:  (978) 692-8200



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

Directions to the Marlborough, MA Holiday Inn

From Boston:  Take Massachusetts Turnpike (I-90) to
exit 11A, Route 495.  Take Route 495 North and
follow to exit 24A (Route 20 East).  At the top of the
ramp, Holiday Inn is on the left.

From Cape Cod:  Take Route 495 North and
follow to exit 24A (Route 20 East).  At the top of the
ramp, Holiday Inn is on the left.

From Connecticut:  Take Massachusetts Turnpike (I-90) East to
exit 11A, Route 495 (North or South).  Take Route 495 North and
follow to exit 24A (Route 20 East).  At the top of the
ramp, Holiday Inn is on the left.

From New Hampshire: Take Route 495 South to exit 24A, Route 20 East.
You will cross back over 495 and the Holiday Inn is on the left.

From Worcester, MA: Take Route 290 East to Exit 26A, Route 495 South.
Follow Route 495 South to exit 24A, Route 20 East.
You will cross back over 495 and the Holiday Inn is on the left.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|       NORTH EAST SYSTEMS ASSOCIATES, INC.       |
|      -------------------------------------      |
|     "High Performance Engineering & Design"     |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Kathy Breda             e-mail: breda@nesa.com  |
| NESA, Inc.              http://www.nesa.com/    |
| 636 Great Road          Tel +1.978.897-8787     |
| Stow, MA 01775 USA      Fax +1.978.897-5359     |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
From owner-ibis  Tue Aug 31 19:14:18 1999
Received: from mail02-oak.pilot.net (mail-oak-2.pilot.net [198.232.147.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA09689 for <ibis-users@eda.org>; Tue, 31 Aug 1999 19:14:18 -0700 (PDT)
Received: from idt.com (unknown-5-20.idt.com [157.165.5.20] (may be forged)) by mail02-oak.pilot.net with ESMTP id TAA24629 for <ibis-users@eda.org>; Tue, 31 Aug 1999 19:07:48 -0700 (PDT)
Received: from Eng.idt.com (root@maxwell.Eng.idt.com [157.165.21.24]) by idt.com (8.8.5/8.7.5) with ESMTP id TAA20173 for <ibis-users@eda.org>; Tue, 31 Aug 1999 19:07:45 -0700 (PDT)
Received: from mig.Eng.idt.com (mig.Eng.idt.com [157.165.31.143]) by Eng.idt.com (8.8.5/8.6.12) with ESMTP id SAA28747 for <ibis-users@eda.org> ; Tue, 31 Aug 1999 18:46:56 -0700 (PDT)
From: Roy Gao <Roy.Gao@idt.com>
Received: (rgao@localhost) by mig.Eng.idt.com (8.6.12/8.6.12) id SAA15580 for ibis-users@eda.org; Tue, 31 Aug 1999 18:46:59 -0700
Date: Tue, 31 Aug 1999 18:46:59 -0700
Message-Id: <199909010146.SAA15580@mig.Eng.idt.com>
To: ibis-users@eda.org
Subject: IBIS problem.

Dear everyone,

I am a new user of IBIS. When I use "ibischk2" to check the IBIS model file I created (of a output buffer), I get the following message:

ERROR - Model iobuf: Pulldown has Decreasing Current
ERROR - Model iobuf: Pullup has Increasing Curren

I don't know if it is an model issue or my fault, I wonder if you have met this kind of problem?

In addition, do you know where can I find the source code of file "ibischk2"?

Thanks for help from everyone who mention it.

Roy

From owner-ibis  Tue Aug 31 19:31:50 1999
Received: from exchtp02.via.com.tw (exchange2.via.com.tw [202.145.217.249]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA09735 for <ibis-users@eda.org>; Tue, 31 Aug 1999 19:31:49 -0700 (PDT)
Received: by EXCHANGE2 with Internet Mail Service (5.5.2232.9)
	id <QP92GBA6>; Wed, 1 Sep 1999 10:24:59 +0800
Message-ID: <9BADB79F06B3D211974800A0C92BD8A0018B89A3@EXCHANGE2>
From: Weber Chuang <WeberChuang@via.com.tw>
To: "'Roy Gao'" <Roy.Gao@idt.com>, ibis-users@eda.org
Subject: RE: IBIS problem.
Date: Wed, 1 Sep 1999 10:24:57 +0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="BIG5"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id TAA09736

Hi ,

  I guess you are setting wrong polarity in generating IBIS. And there is
ibischk3 ready on the net.

  Best Regards 
    Weber Chuang( ²ø´º²e)
 Signal Integrity Engineer,
 VIA Technologies, Inc.  Taipei, Taiwan, ROC 
 TEL : 886-2-22185452  ext : 6522
 mailto:weber@via.com.tw
 http://www.via.com.tw
 Very Innovative Architecture


-----Original Message-----
From: Roy Gao [mailto:Roy.Gao@idt.com]
Sent: Wednesday, September 01, 1999 9:47 AM
To: ibis-users@eda.org
Subject: IBIS problem.


Dear everyone,

I am a new user of IBIS. When I use "ibischk2" to check the IBIS model file
I created (of a output buffer), I get the following message:

ERROR - Model iobuf: Pulldown has Decreasing Current
ERROR - Model iobuf: Pullup has Increasing Curren

I don't know if it is an model issue or my fault, I wonder if you have met
this kind of problem?

In addition, do you know where can I find the source code of file
"ibischk2"?

Thanks for help from everyone who mention it.

Roy
From owner-ibis  Tue Aug 31 19:35:53 1999
Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA09748 for <ibis-users@eda.org>; Tue, 31 Aug 1999 19:35:53 -0700 (PDT)
Received: by mailext04.compaq.com (Postfix, from userid 60001)
	id 215B2104C44; Tue, 31 Aug 1999 21:29:24 -0500 (CDT)
Received: from mailext04.compaq.com (localhost [127.0.0.1])
	by mailext04.compaq.com (Postfix) with ESMTP
	id 1F29BFB101; Tue, 31 Aug 1999 21:29:24 -0500 (CDT)
Received: from mailint02.im.hou.compaq.com([not looked up])
        (peer mailint02.compaq.com[207.18.199.35])
        by mailext04.compaq.com with ESMTP
        id rcv024811; Tue, 31 Aug 1999 21:29:23 -0500 (CDT)
Received: by mailint02.im.hou.compaq.com (Postfix, from userid 60001)
	id E5F6CBC4C6; Tue, 31 Aug 1999 21:29:21 -0500 (CDT)
Received: from mail.compaq.com (localhost [127.0.0.1])
	by mailint02.im.hou.compaq.com (Postfix) with ESMTP
	id DD524B2A42; Tue, 31 Aug 1999 21:29:21 -0500 (CDT)
Received: from exctay-gh01.bb.dec.com([not looked up])
        (peer exctay-gh01.bb.dec.com[16.52.48.15])
        by mail.compaq.com with ESMTP
        id rcv026075; Tue, 31 Aug 1999 21:29:18 -0500 (CDT)
Received: by exctay-gh01.bb.dec.com with Internet Mail Service (5.5.2559.0)
	id <R77CDA3B>; Tue, 31 Aug 1999 22:29:17 -0400
Message-ID: <D5210908318AD211A3F20000F8062CCD8F45D4@excpko-02.pko.dec.com>
From: "Ingraham, Andrew" <Andrew.Ingraham@compaq.com>
To: "'Larry Forsythe'" <lforsyth@mail.teklogix.com>
Cc: "'ibis-users@eda.org'" <ibis-users@eda.org>
Subject: RE: IBIS in simulation
Date: Tue, 31 Aug 1999 22:29:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2559.0)
Content-Type: text/plain

Larry Forsythe wrote:

>I'm confused about how IBIS is used in actual simulations. I haven't seen
>any articles about this (please indicate if there are some).

And you might not find any that go into much detail.  The actual algorithm
used by each simulator, especially as to how it handles the V-T data, might
be a guarded secret.

> What I'm
>confused about is how can a few static I-V curves and some V-T curves done
>at specific loads be used to simulate other loads. The I-V curves involve
>fully on transistors. The V-T curves involve partially turned-on
transistors
>driving a specific load.

Typically, an output buffer interacts with its load over a period of several
nanoseconds while the signal rattles around and eventually settles.  Yet the
time it spends actually changing -- the time for the drive to its output
transistors to switch -- is much less, perhaps a few hundred picoseconds.
It is a fair approximation to treat the output buffer as if it were static
(defined by one I-V curve or the other) almost all of the time.  In between
the two, it makes some sort of transition from one I-V curve to another, in
a relatively short interval, the effects of which might be swamped by the
interaction with the load.

> Is it valid to scale the I-V curves using the V-T
>curves in order to derive the response to driving other loads?

Here's where you get into the proprietary details of each simulator's
vendor.

If you're lucky, the load for the V-T curves is close to the trace
characteristic impedance.

> Can the I-V
>curves and V-T curves be used to determine the characteristics of a
>partially turned on transistor driving a different load-I guess that is the
>source of my confusion.

To varying degrees, apparently yes.

Regards,
Andy Ingraham