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 ; 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 ; 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 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 ; 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 ; Fri, 6 Aug 1999 14:52:45 -0400 Message-ID: From: "Joe Lee" To: "'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: 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 ; 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: 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 ; 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 ; 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 ; 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 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'" Subject: Re: Clarification on message from s2ibis2 References: 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 ; 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 Reply-To: Syed Huq 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" > To: "'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: > > 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 ; 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: From: "Montoya, Silvia" To: ibis-users@eda.org Cc: "Montoya, Silvia" 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 ; 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 ; Mon, 9 Aug 1999 17:48:11 -0700 (PDT) X-Authentication-Warning: osiris.vlsi.com: smtp set sender to using -f Received: from (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" 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: 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 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 ; 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" 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" 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 using -f Received: from (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" 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 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 using -f Received: from (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" 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" , 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" 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 ; Tue, 10 Aug 1999 21:22:13 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512702AC0DB1@fmsmsx36.fm.intel.com> From: "Mellitz, Richard" 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" 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 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 using -f Received: from (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" 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 ; 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 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 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 Organization: Cadence Design Systems X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Peters 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 ; 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 Reply-To: Syed Huq 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 ; 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 ; 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 Subject: V/T Question To: "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 ; 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 using -f Received: from (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" 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: Christian Klein 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: 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 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 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 ; 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 ; 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 ; 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 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 ; 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 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 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 ; 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: From: "Wilco Hamhuis" To: "Ibis-Users" 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 ; 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" 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 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 ; 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" To: Cc: "Ibis-Users" 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 ; 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" From: Kellee Crisafulli 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 ; 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 ; 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 Reply-To: y9672232@bupt.edu.cn To: "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 ; 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 Reply-To: Syed Huq 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