From owner-ibis Tue Nov 2 12:36:40 1999 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA08476 for ; Tue, 2 Nov 1999 12:36:39 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id OAA11028 for ; Tue, 2 Nov 1999 14:36:14 -0600 (CST)] Received: [from msgphx4.sps.mot.com (msgphx4.sps.mot.com [216.11.52.4]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA03201 for ; Tue, 2 Nov 1999 14:36:14 -0600 (CST)] Received: from email.sps.mot.com ([222.83.248.138]) by msgphx4.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA6186 for ; Tue, 2 Nov 1999 13:36:13 -0700 Message-ID: <381F4B3B.78DD8FB7@email.sps.mot.com> Date: Tue, 02 Nov 1999 14:36:12 -0600 From: "Benjie Zeller" X-Mailer: Mozilla 4.06 [en]C-MOTSPS405U (WinNT; I) MIME-Version: 1.0 To: ibis-users@eda.org Subject: S2IBIS2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Motorola-Sent-Wireless: 1 I am having some problems with defining some dummy input signals and power planes in a S2IBIS2 template I am using. Can anyone help? I have specifics, I just didn't want to send a long email to everyone on the list. Benj -- Benjie Zeller Motorola NSD FSRAM Apps. Engineer 3501 Ed Bluestein Blvd MD:TX11/K16 Austin, TX 78721 (W)(512)933-7181 (H)(512)372-8236 (Fax)(512)933-3851 Pager - 1(800)SKYTEL2 id.-5853680 From owner-ibis Fri Nov 5 08:55:38 1999 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA05376 for ; Fri, 5 Nov 1999 08:55:32 -0800 (PST) Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id LAA04443 for ibis-users@eda.org; Fri, 5 Nov 1999 11:54:43 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdHAAa04104; Fri Nov 5 11:53:28 1999 Received: from [138.120.52.16] by kanata-mh1.ca.newbridge.com for ibis-users@eda.org; Fri, 5 Nov 1999 11:53:19 -0500 Received: by nomad1.newbridge (SMI-8.6/SMI-SVR4) id LAA03189; Fri, 5 Nov 1999 11:42:52 -0500 Date: Fri, 5 Nov 1999 11:42:52 -0500 From: fbellami@nomad1 (Fethi Bellamine) Message-Id: <199911051642.LAA03189@nomad1.newbridge> To: ibis-users@eda.org Subject: Voltage dop (QA of XTK models) HI, After converting my IBIS model to an XTK model and checking for the validity of the model as a driver, for example, I noticed there is a voltage drop (the driver is differential) more than 1V. I would expect a voltage drop of 0.6-0.8V but not over 1V. So I am wondering what accounts for the voltage drop? Thank you. Fethi Bellamine EMC/SI enginner Newbridge Networks From owner-ibis Mon Nov 8 16:19:38 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 QAA23176 for ; Mon, 8 Nov 1999 16:19:38 -0800 (PST) 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.10 1999/10/20 18:19:05 spurcell Exp $) with ESMTP id UAA06562 for ; Mon, 8 Nov 1999 20:19:33 GMT Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 8 Nov 1999 16:19:09 -0800 Message-ID: <99BAA0EF4B10D211AC4000A0C95BF9400386BEEE@fmsmsx45.fm.intel.com> From: "Trinh, Viet" To: "'ibis-users@vhdl.org'" Subject: s2ibis ! Date: Mon, 8 Nov 1999 16:19:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" i have a problem to run the s2ibis_zip.exe file. i tried to drag my file into the s2ibis.exe file.it was not working in that way. would you show me how to run it, i really appreciate that viet trinh, From owner-ibis Fri Nov 12 12:50:02 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 MAA22676; Fri, 12 Nov 1999 12:49:58 -0800 (PST) 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.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id NAA11198; Fri, 12 Nov 1999 13:00:09 -0800 (PST) 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 MAA09157; Fri, 12 Nov 1999 12:49:25 -0800 (PST) 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 MAA08505; Fri, 12 Nov 1999 12:42:06 -0800 (PST) Message-Id: <199911122042.MAA08505@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: IBIS-X proposal Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Nov 1999 12:42:05 -0800 From: Stephen Peters Hello All: At the recent IBIS summit there was a fair amount of discussion regarding the future of IBIS. Among the issues the IBIS community has been wrestling with are: 1. the growth in complexity of the specification, 2. support for power/gnd and return path modeling 3. receiver modeling, and 4. the need for a general escape mechanism that allows simulators to incorporate user created models (models that the simulator may not otherwise support). So far, there has been a proposal for incorporating an API (application programming interface) into IBIS, which addresses point four above. However, to fully support an API I belive that the current IBIS description would have to change. Specifically, models would have to become multi-ported entities with explicit power and ground ports tied to component pins. In fact, I belive to in order to fully address the problems of complexity (added keywords for every new type of buffer) and return path modeling there needs to be a new, general buffer description language, one that supports IBIS type simulators but also allows a model to be used directly by a circuit simulator. To that end I'm making a proposal called IBIS-X. I am aware that this is a fairly radical proposal (for example, it is not backwards compatible with the existing IBIS specification), but I belive it does address directly both the needs of those producing models as well as those designing high speed electrical interconnects. Please look it over and make your comments. This will be on the agenda at the next IBIS phone conference. Best Regards, Stephen Peters Intel Corp. ----------- cut here ----------- The following is a proposal for a new format to be used for creating and specifying I/O buffer models. This format is an evolution of the current IBIS description, and provides a couple of fundamental enhancements when compared with the current specification. Specifically: a) IBIS-X provides for much greater flexibility in model descriptions. Buffers can be described using either the traditional IBIS prototype model or the user may create their own buffer model by using a set of passive and behavioral elements connected together nodally. Nodal descriptions provide a direct path into circuit simulators, and nodal descriptions are also used to build arbitrary package models around a buffer. b) IBIS-X provides support for return path modeling. Component power and gnd pins are connected directly to a model instance, thus allowing true system level simulations that incorporate board decoupling effects, ground return effects, etc. c) The IBIS-X proposal provides the necessary hooks that enable simulators to incorporate an external models thru an API. IBIS-X COMPARED TO IBIS As with the original IBIS specification, the IBIS-X description is targeted towards transmission line and board level SI simulators. To this end IBIS-X sticks with the "component centric" format -- each pin of a component is listed, and pins are attached to a model witch can be used over and over again. Furthermore, each pin (model) is explicitly declared as a driver or receiver and each model contains the 'data book' information (timing test loads, Vinh/Vinl, etc.) that allows for automatic SI and flight time analysis. The biggest difference is that the IBIS-X description allows a buffer/receiver model to connect not just to an I/O pin, but also to power/gnd pin(s). It does this by making the [Model] a multi-port entity. By allowing a model to have explicit power ports a circuit type simulator (or an enhanced behavioral simulator) can modulate the power and ground rails of a behavioral model, thus incorporating the effects of board level power distribution (including ground return paths) into a simulation (i.e. enables true system level simulation). As mentioned above, the IBIS-X spec allows the model maker a choice of descriptions. Model makers should be able to model a driver or receiver to the level of detail required and/or appropriate. Traditional I/V,V/T descriptions are still very useful and the IBIS-X proposal fully supports a pure behavioral description of an driver or receiver. In other cases, the user may want to model a buffer behaviorally, but surround the buffer with a package model consisting of a network of R/L/Cs (a SPICE like description). Therefore, the IBIS-X proposal allows the guts of a model to be a nodal network consisting of passive components, some basic independent and dependent sources, and submodels. In turn, a submodel can consist of behavioral descriptions, nodal networks, more submodels, or a coupling matrix (used to describe pin coupling). By using a approach based on nodal description and submodels, it should be straightforward to incorporate a package model around a buffer, or to group buffers together to simulation SSO effects, etc. Finally, the IBIS-X proposal prepares the way for a behavioral simulator to execute transistor level models by allowing a model or submodel to call an external model which is executed via an API. I should point out that adding an API to the existing IBIS specification is possible, but to make it useful there still needs to be some mechanism to define/declare a multi-port model and associate those ports with the various [Voltage] keywords of the current spec and the pins of the component. ========= Details, and a shot at syntax ============== FILE HEADER The file header info remains pretty much the same as in the current IBIS spec. [Template Version] version # [Comment Char] | by default [File Name] file name.ibx [Date] date [Source] ASCII text [Notes] ASCII text [Disclaimer] ASCII text [Copyright] ASCII text COMPONENT SECTION The major function of the component section is to map the component pins to a model. However, instead of calling out just a model the [Pin] keyword connects pins to a specific port on a model. The [Model Selector] functionality is retained, along with the [Diff Pin] keyword. However, the [Diff Pin] keywords function has been changed to list only skew between differential outputs only. (Note: To aid parsing each "section" of the spec begins with a [Begin "Section Name"] keyword and ends with an [End "Section Name"] keyword. [Begin Component] [Component] component name [Manufacture] manufactures name [Pin] pin_name signal_name model_name port_name R_pin L_pin C_pin (Note: only a *model_name* is allowed, not a submodel name. To support IBIS compatible descriptions NC, PWR and GND are legal pin connections, and a generic R_pin, L_pin and C_pin can be included.) [Diff Pin] inverting_pin non_inverting skew_typ skew_typ skew_max [Model Selector] [End Component] MODEL SECTION The purpose of the model section is to identify the top model type (input, output, bidir, etc.), list the data book specs that support SI simulators and board level timing products (timing test loads, input parameters, etc.), define the ports of the model and finally, provide a place to put the guts of a model. [Begin Model] model_name model_type = select from list C_comp* = I/O capacitance value [Temperature_Range] typ min max [Pullup Reference] typ min max [Pulldown Reference] typ min max [POWER Clamp Reference] typ min max [GND Clamp Reference] typ min max [Receiver Reference] type min max (The voltage range keywords are used a bit differently than in IBIS. These keywords indicate the voltage at the associated model port. For a traditional behavioral simulator these value still end up being the references for the I/V curves. For an IBIS-X simulator they would be a fixed voltage at the pins, and a structural description can be used to put a package model in between the pin (port) and the buffer model itself. For a pure SPICE simulator (where the board level power distribution is modeled) these keywords serve mostly as documentation.) [Driver Spec] (timing test loads, Vmeas, etc. Use if a model is an output or I/O) [Receiver Spec] (input thresholds, overshoot/undershoot thresholds, etc. Use if a model is a receiver or I/O) [Port list] port_name port_type (port types are: primary_io | primary I/O pin pullup_ref | power connection pin pulldown_ref | power connection pin pwrclamp_ref | power connection pin gndclamp_ref | power connection pin rcvr_ref | power connection pin gnd | reference pin ctl | a digital (1/0) control pin analog | an analog control pin stim_in | external stimulus (not a component pin) recevier_out | output of a receiver (not a component pin) ) [Begin Model Description] description_type = behavioral | structural (put the guts of the model here) [End Model Description] [End Model] MODEL DESCRIPTIONS A model can be described in one of three forms: A conventional behavioral (IBIS) description, a nodal description that interconnects submodels and passive components, or a call to an external file. For a traditional IBIS description, the following keywords are supported (initial list). [Pullup]/[Pulldown]/[POWER Clamp]/[GND Clamp] [Rising Waveform]/[Falling Waveform] [Ramp] [TTgnd]/[TTpower] [Driver Schedule] (replace by IBIS submodel mechanism?) [Add Submodel] [SubModel] (Note: The keywords that support series switches, series devices, or terminator networks have not been included. Given that these devices are adequately supported in IBIS, or could be described using a circuit description, I have not included them in the initial list.) A nodal description connects passive components, submodels and independent voltage and current sources together. Transistors are not supported, but a general three terminal device is included. Syntax would be some most common denominator of the existing SPICE variants. Rxxx node1 node2 value= explicit value or equation (resistance) Lxxx node1 node2 value= explicit value or equation (inductance) Cxxx node1 node2 value= explicit value or equation (capacitance) Vxxx node1 node2 value= explicit value, equation or table (V source) Ixxx node1 node2 value= explicit value, equation or table (I source) Sxxx node1 node2 node3 value = equation or table(s) (three terminal device) Xxxx port1=>node1, port2=>node2, ...parameter1=>value,... (submodel) Finally, the guts of a model (or a submodel in a nodal or IBIS description) could be a call to an externally defined model that the simulator executes via an API (applications programming interface). The syntax of the call has yet to be worked out, but one would expect something like Xxxx port1=>node1, port2=>port2,... parameter1=>"path to model file", ...) One question that has been puzzling me is the mechanism used to apply stimulus to the external model. Does the simulator simply flip the stim_in node from '0' to '1', or does the user have to attach an explicit stimulus source? SUBMODELS Submodels are used both by behavioral descriptions ([Submodel] statements) and nodal descriptions (Xxxx calls). Submodels are a lot like top level [Models], but they do not include any of the top level simulation information nor can they connect directly to a component pin. Again, behavioral, structural and calls to external models are supported. In addition, a submodel can support a matrix type description of a passive network. [Begin Submodel] submodel_name description_type = behavioral | structural | matrix [Port List] (port name, but do we need a description??) (put description of submodel here) [End Submodel] [End] From owner-ibis Fri Nov 12 13:22:48 1999 Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA22852; Fri, 12 Nov 1999 13:22:48 -0800 (PST) From: apanella@molex.com Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id PAA04791; Fri, 12 Nov 1999 15:22:17 -0600 (CST) Received: from smtp2.molex.com(150.150.15.101) by molexinc-bh.molex.com via smap (4.1) id xma004698; Fri, 12 Nov 99 15:21:24 -0600 Received: from ccMail by smtp2.molex.com (IMA Internet Exchange 3.0 Enterprise) id 000750D7; Fri, 12 Nov 99 15:18:46 +0000 Mime-Version: 1.0 Date: Fri, 12 Nov 1999 15:18:15 +0000 Message-ID: <000750D7.CE21031@molex.com> Subject: Re:IBIS-X proposal To: ibis@eda.org, ibis-users@eda.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Stephen and other "IBISians" For what it is worth.... When I initially started with the IBISCnn specification (IBISCnn = IBIS Connector Specification).... I really tried to incorporate a nodal methods. And, for what it is worth, I still think it would be a powerful addition. However, at the time (and maybe still) there seemed to be a lot of resistance to incorporating a "SPICE deck like approach" in the IBIS specification. Further, I really like the inclusion of the PWR/GND (or maybe more specifically, current return path) references. For what it is worth, these have been included in the IBISCnn specification (soon to be available for your critical reviews). As such, after IBISCnn is available, I would greatly appreciate your comments. If it would help the group, I would also suggest that the IBISCnn RLCs interconnection metodology may address Stephans: "package model consisting of a network of R/L/Cs (a SPICE like description). Therefore, the IBIS-X proposal allows the guts of a model to be a nodal network consisting of passive components". As such, maybe it may also be possible to represent " some basic independent and dependent sources" in the same "matrix" format. Also, it is important to know that the IBISCnn specification does incorporate "NO GROUND" models. Unfortunately, this functionality is lost if a simulator insists on having "perfect ground" reference points on both sides of a connector. Best Regards, _gus ____________________Reply Separator____________________ Subject: IBIS-X proposal Author: Stephen Peters Date: 11/12/99 12:42 PM Hello All: At the recent IBIS summit there was a fair amount of discussion regarding the future of IBIS. Among the issues the IBIS community has been wrestling with are: 1. the growth in complexity of the specification, 2. support for power/gnd and return path modeling 3. receiver modeling, and 4. the need for a general escape mechanism that allows simulators to incorporate user created models (models that the simulator may not otherwise support). So far, there has been a proposal for incorporating an API (application programming interface) into IBIS, which addresses point four above. However, to fully support an API I belive that the current IBIS description would have to change. Specifically, models would have to become multi-ported entities with explicit power and ground ports tied to component pins. In fact, I belive to in order to fully address the problems of complexity (added keywords for every new type of buffer) and return path modeling there needs to be a new, general buffer description language, one that supports IBIS type simulators but also allows a model to be used directly by a circuit simulator. To that end I'm making a proposal called IBIS-X. I am aware that this is a fairly radical proposal (for example, it is not backwards compatible with the existing IBIS specification), but I belive it does address directly both the needs of those producing models as well as those designing high speed electrical interconnects. Please look it over and make your comments. This will be on the agenda at the next IBIS phone conference. Best Regards, Stephen Peters Intel Corp. From owner-ibis Fri Nov 12 21:26:12 1999 Received: from ptldpop1.ptld.uswest.net (ptldpop1.ptld.uswest.net [198.36.160.1]) by server.eda.org (8.8.5/8.8.3) with SMTP id VAA24991 for ; Fri, 12 Nov 1999 21:26:11 -0800 (PST) Received: (qmail 15458 invoked by alias); 13 Nov 1999 05:25:35 -0000 Delivered-To: fixup-ibis-users@eda.org@fixme Received: (qmail 15446 invoked by uid 0); 13 Nov 1999 05:25:34 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by ptldpop1.ptld.uswest.net with SMTP; 13 Nov 1999 05:25:34 -0000 Message-ID: <382CF64F.6CD2D131@vasthorizons.com> Date: Fri, 12 Nov 1999 21:25:36 -0800 From: Scott McMorrow Reply-To: scott@vasthorizons.com Organization: SiQual X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis , Jim Bell , Richard Gaunt , bernard , Darrel Baker , mike Tchou , Dave Macemon , Wis Macomson Subject: [Model Spec] Vref Addition. Content-Type: multipart/mixed; boundary="------------EC2FE05C7413B71C28CBD109" This is a multi-part message in MIME format. --------------EC2FE05C7413B71C28CBD109 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I would like to submit the following Bird on behalf of SiQual to modify the current [Model Spec]. It is attached below regards, scott Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com ****************************************************************************** ****************************************************************************** BIRD ID#: ISSUE TITLE: [Model Spec] Vref Addition REQUESTER: Scott McMorrow, SiQual DATE SUBMITTED: November 12, 1999 DATE ACCEPTED BY IBIS OPEN FORUM: xxxx ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Vref may need to be different for min and max columns. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Changes and additions to the [Model Spec] keyword are shown by the |* lines to add Vref with typ-min-max values: |============================================================================= | Keyword: [Model Spec] | Required: No | Sub-Params: Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high, | S_overshoot_low, D_overshoot_high, D_overshoot_low, | D_overshoot_time, Pulse_high, Pulse_low, Pulse_time, Vmeas |* Vref | Description: The [Model Spec] keyword defines four columns under which | specification subparameters are defined. | | The following subparameters are defined: | Vinh Input voltage threshold high | Vinl Input voltage threshold low | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- | S_overshoot_high Static overshoot high voltage | S_overshoot_low Static overshoot low voltage | D_overshoot_high Dynamic overshoot high voltage | D_overshoot_low Dynamic overshoot low voltage | D_overshoot_time Dynamic overshoot time | Pulse_high Pulse immunity high voltage | Pulse_low Pulse immunity low voltage | Pulse_time Pulse immunity time | | Vmeas Measurement voltage for timing measurements |* Vref Timing specification test load voltage | | Usage Rules: [Model Spec] must follow all other subparameters under the | [Model] keyword. | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum be must be placed | on a single line and must be separated by at least one white | space or tab character. All four columns are required under | the [Model Spec] keyword. However, data is required only in | the typical column. If minimum and/or maximum values are not | available, the reserved word "NA" must be used indicating the | typical value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage Range settings. | | Unless noted below, each subparameter does not require having | any other subparameter. | | Vinh, Vinl rules: | | The threshold subparameter lines provide additional min and | max column values, if needed. The typ column values are still | required and would be expected to override the Vinh and Vinl | subparameter values specified elsewhere. Note: the syntax | rule that require inserting Vinh and Vinl under models remains | unchanged even if the values are defined under the [Model | Spec] keyword. | | To mimic a hysteresis effect, the values of Vinh and Vinl may | be interchanged such that the Vinl value is larger than the | Vinh value. However, simulators may process this information | differently or report an error. | | Vinh+, Vinh-, Vinl+, Vinl- rules: | | The four hysteresis subparmeters must all be defined before | the hysteresis threshold rules become effective. Otherwise | the standard threshold subparameters remain in effect. The | hysteresis thresholds shall be at the Vinh+ and Vinh- values | for a low-to-high transition, and at the Vinl+ and Vinl- | values for a high-to-low transition. | | S_overshoot_high, S_overshoot_low rules: | | The static overshoot subparameters provide the voltage values | for which the model is no longer guaranteed to function | correctly. | | D_overshoot_high, D_overshoot_low, D_overshoot_time rules: | | The dynamic overshoot values provide a time window during | which the overshoot may exceed the static overshoot limits | but be below the dynamic overshoot limits. D_overshoot_time | is required for dynamic overshoot testing. In addition, if | D_overshoot_high is specified, then S_overshoot_high is | necessary for testing beyond the static limit. Similarly, if | D_overshoot_low is specified, then S_overshoot_low is | necessary for testing beyond the static limit. | | Pulse_high, Pulse_low, Pulse_time rules: | | The pulse immunity values provide a time window during which | a rising pulse may exceed the nearest threshold value but | be below the pulse voltage value and still not cause the | input to switch. Pulse_time is required for pulse immunity | testing. A rising response is tested only if Pulse_high is | specified. Similarly, a falling response is tested only if | Pulse_low is specified. The rising response may exceed the | Vinl value, but remain below the Pulse_high value. | Similarly, the falling response may drop below the Vinh value, | but remain above the Pulse_low value. In either case the | input is regarded as immune to switching if the responses | are within these extended windows. If the hysteresis | thresholds are defined, then the rising response shall use | Vinh- as the reference voltage, and the falling response shall | use Vinl+ as the reference voltage. | | Vmeas rules: | | The Vmeas values under the [Model Spec] keyword override the | Vmeas entry elsewhere. |* |* Vref rules: |* The Vref values under the [Model Spec] keyword override the |* Vref entry elsewhere |----------------------------------------------------------------------------- [Model Spec] | Subparameter typ min max | | Thresholds | Vinh 3.5 3.15 3.85 | 70% of Vcc Vinl 1.5 1.35 1.65 | 30% of Vcc | | Vinh 3.835 3.335 4.335 | Offset from Vcc | Vinl 3.525 3.025 4.025 | for PECL | | Hysteresis | Vinh+ 2.0 NA NA | Overrides the Vinh- 1.6 NA NA | thresholds Vinl+ 1.1 NA NA Vinl- 0.6 NA NA | All 4 are required | | Overshoot | S_overshoot_high 5.5 5.0 6.0 | Static overshoot S_overshoot_low -0.5 NA NA D_overshoot_high 6.0 5.5 6.5 | Dynamic overshoot D_overshoot_low -1.0 -1.0 -1.0 | requires | | D_overshoot_time D_overshoot_time 20n 20n 20n | & static overshoot | | Pulse Immunity | Pulse_high 3V NA NA | Pulse immunity Pulse_low 0 NA NA | requires Pulse_time 3n NA NA | Pulse_time | | Timing Thresholds | Vmeas 3.68 3.18 4.68 | A 5 volt PECL | | example | |*** ADDED EXAMPLE BELOW: | Timing test load voltage reference example | Vref 1.25 1.15 1.35 | An SSTL-2 example | |*** END OF ADDED EXAMPLE |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRDxx is issued because the Timing specification test load voltage value Vref defined under the [Model] keyword changes with the Vcc reference voltage for some technologies (such as SSTL-2) when used for the min or max column. This will cause incorrect timing test load corrections to be created for the min and max corners. Adding Vref to the [Model Spec] section is necessary to correctly simulate output timing and skew across the entire process range. A simple typical Vref value, as is currently used, will cause some simulators to report incorrect delay due to improper measurement of the output timing parameters. Device output timing specifications for SSTL-2 for DDR devices are guaranteed into the following standard load for the typical case: Cref = 30.000000pF Vref = 1.50000V Rref = 50.000000 For the minimum case: Cref = 30.000000pF Vref = 1.15000V Rref = 50.000000 For the maximum case: Cref = 30.000000pF Vref = 1.35000V Rref = 50.000000 It is impossible to correlate device output performance to only a typical test load with the current method. This enhancement to the [Model Spec] was incorrectly excluded from the previous BIRD 55. The inclusion of a simple timing measurement threshold region should also be considered for inclusion into this bird. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** --------------EC2FE05C7413B71C28CBD109 Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf" begin:vcard n:McMorrow;Scott tel;work:503-708-4320 x-mozilla-html:FALSE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:scott@vasthorizons.com title:Principal Engineer note:asdfsdaf fn:Scott McMorrow end:vcard --------------EC2FE05C7413B71C28CBD109-- From owner-ibis Fri Nov 12 21:52:56 1999 Received: from ptldpop1.ptld.uswest.net (ptldpop1.ptld.uswest.net [198.36.160.1]) by server.eda.org (8.8.5/8.8.3) with SMTP id VAA25065 for ; Fri, 12 Nov 1999 21:52:55 -0800 (PST) Received: (qmail 9541 invoked by alias); 13 Nov 1999 05:52:22 -0000 Delivered-To: fixup-ibis-users@eda.org@fixme Received: (qmail 9523 invoked by uid 0); 13 Nov 1999 05:52:22 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.1) by ptldpop1.ptld.uswest.net with SMTP; 13 Nov 1999 05:52:22 -0000 Message-ID: <382CFC92.14EB1877@vasthorizons.com> Date: Fri, 12 Nov 1999 21:52:18 -0800 From: Scott McMorrow Reply-To: scott@vasthorizons.com Organization: SiQual X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis Subject: IBIS Bird 64 - Package Model Selector suggested changes Content-Type: multipart/mixed; boundary="------------1CEDB8873D88051E438C6ED3" This is a multi-part message in MIME format. --------------1CEDB8873D88051E438C6ED3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, SiQual would like to suggest that we add min, typ and max columns to the Bird 64 - Package Model Selector. This will allow a simple mechanism for defining multiple package corners that are logically associated with a particular package type. A simulator would select a package type using the Package Type column. A simulator would select a package corner using the Typ, Min and Max columns. These selections can be made independently within the simulator in order to "sweep" the entire design space. See below. regards, scott -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com | [Package Model Selector] | | Package Type typ min max | Documentation of 208-BGA package model typ, min and max corner extractions. |208-BGA-pkg-single BGA - Single switched line equivalent package | All other lines quiescent |208-BGA-pkg-odd BGA - Odd mode single line equivalent package |208-BGA-pkg-even BGA - Even mode single line equivalent package | 208-BGA 208-BGA-pkg-single 208-BGA-pkg-odd 208-BGA-pkg-even | | |Documentation of 208-PQFP package model typ, min and max corner extractions. |208-PQFP-pkg-single PQFP - Single switched line equivalent package | All other lines quiescent |208-PQFP-pkg-odd PQFP - Odd mode single line equivalent package |208-PQFP-pkg-even PQFP - Even mode single line equivalent package | 208-PQFP 208-PQFP-pkg-single 208-PQFP-pkg-odd 208-PQFP-pkg-even | --------------1CEDB8873D88051E438C6ED3 Content-Type: text/x-vcard; charset=us-ascii; name="scott.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott McMorrow Content-Disposition: attachment; filename="scott.vcf" begin:vcard n:McMorrow;Scott tel;work:503-708-4320 x-mozilla-html:FALSE url:www.siqual.com org:SiQual, Signal Quality Engineering adr:;;18735 SW Boones Ferry Road;Tualatin ;OR;97062-3090;USA version:2.1 email;internet:scott@vasthorizons.com title:Principal Engineer note:asdfsdaf fn:Scott McMorrow end:vcard --------------1CEDB8873D88051E438C6ED3-- From owner-ibis Mon Nov 15 13:25:10 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 NAA05533; Mon, 15 Nov 1999 13:25:10 -0800 (PST) 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 NAA10261; Mon, 15 Nov 1999 13:24:08 -0800 (PST) Message-Id: <199911152124.NAA10261@jasper.cisco.com> Date: Mon, 15 Nov 1999 13:24:07 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: IBIS connector specification released to open forum To: ibis@eda.org, apanella@molex.com, kellee@hyperlynx.com Cc: ibis-users@eda.org, shuq@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: ECMkTI1XuoicW0eMQ77Uww== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by server.eda.org id NAA05534 The IBIS website has been updated with a link 'Connector Info' on the main page http://www.eia.org/eig/ibis/ibis.htm. Select the link. Then download the two document(ver 0.92): IbisConSpec_v092.txt IbisConUpdates_v092.txt Regards, Syed Webmaster Cisco Systems, Inc > > Hi IBIS fans, > > The IBIS connector sub-group today completed work > on the final draft of the connector specification V0.92. > > I forwarded the specification along with a changes document > to Syed to have it placed on the IBIS web site. > > Please accept this email as the official notification from > the connector sub-group to the IBIS open forum that we are > releasing the connector specification to you. > > I chose not to send the entire specification to the whole > IBIS group as it is around 1600 lines long. It should be > available to the general public as soon as Syed can get it > put on the web site. > > NOTICE: This is not a released specification! This version is > the release from the sub-group to the full group. > > What remains to be done: > > 1) Full open forum must comment and changes if any included > in the document. > 2) It must be voted on and approved by the open forum. > 3) A Golden parser must be written to insure that models developed > have no syntax errors. Along with this development the existing > golden example models provided by the connector sub group must be > improved to comply with the current specification. > 4) Existing connector model creation and simulation methods should > be enhanced to support the new IBIS connector format. > This might effect connector manufacturers as well as CAE tool suppliers. > > This is the end of a nearly 2 year project for the people involved. > I know many of you will not be 100% happy with > the result but please don't forget that we are a large group and > must forge a result that is acceptable to the majority. > Also consider that this specification is long over due and it is the > 2nd attempt by the IBIS group to create a connector specification. > So please be gentle in your criticism .... > > Please direct your comments to the normal IBIS reflector > both Gus and I will be watching for your questions > and will do our best to answer them. > > best wishes... > Kellee Crisafulli, PADS software/Hyperlynx > Gus Panella, Mollex > > *************************************************************** > Members of the IBIS connector sub-group and others that have > assisted with developing with this specification. > Eric Bogatin, Ansoft/Bogatin Enterprises > Steve Chau, AMP > Kellee Crisafulli, PADS software/HyperLynx > John Ellis, Berg > Mark Gailus, Teradyne > Fran Hart, Dell > Bob Haller, Compaq > Jay Diepenbrock, IBM > Mikhail Khusid, Teradyne > Igor Kochikov, PADS software/HyperLynx > Gus Panella, Mollex Inc. > Katie Rothstein, Teradyne > Guy de Burgh, Viewlogic Systems > Jeff Walden, AMP/Foxconn > Fabrizio Zanella, EMC corp > > --------------------------------------------------------- > Have a great day.... > Kellee Crisafulli > HyperLynx, a division of Pads Software Inc. > SI,EMC,X-talk and IBIS tools for the Windows platform > E-mail: > web:   > --------------------------------------------------------- > > From owner-ibis Tue Nov 16 08:24:48 1999 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA11842 for ; Tue, 16 Nov 1999 08:24:48 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA88144; Tue, 16 Nov 1999 11:23:25 -0500 Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id LAA159356; Tue, 16 Nov 1999 11:24:11 -0500 Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525682B.005A16E7 ; Tue, 16 Nov 1999 11:24:01 -0500 X-Lotus-FromDomain: IBMUS To: si-list@silab.eng.sun.com cc: ibis-users@vhdl.org Message-ID: <8525682B.005A12F0.00@D51MTA05.pok.ibm.com> Date: Tue, 16 Nov 1999 10:23:36 -0600 Subject: IBIS datasheets for PCI and DDR Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello All, My modeling group has a need for a generic IBIS datasheet that would represent the full range of the PCI spec. I guess it would be pretty easy to make from the spec (except the VT tables), but I figured why reinvent the wheel. A behavioral HSPICE model would be nice, too. We're planning to use these models in simulations to evaluate spec compliance. I'm also looking for the same thing for the DDR SDRAM spec. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Tue Nov 16 10:44:26 1999 Received: from mail.3pardata.com (dnai-216-15-110-218.cust.dnai.com [216.15.110.218]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA12548 for ; Tue, 16 Nov 1999 10:44:26 -0800 (PST) Received: from [192.168.1.112] (HELO moonrise) by mail.3pardata.com (CommuniGate Pro SMTP 3.1b4) with SMTP id 199010; Tue, 16 Nov 1999 12:48:57 -0800 From: "Chris Cheng" To: Cc: Subject: RE: [SI-LIST] : IBIS datasheets for PCI and DDR Date: Tue, 16 Nov 1999 10:41:27 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <8525682B.005A12F0.00@D51MTA05.pok.ibm.com> try this for DDR model http://www.micron.com/mti/msp/models/index.html spice only for DDR i/o but then again, why do u need ibis if u have the full spice...... chris > -----Original Message----- > From: owner-si-list@silab.eng.sun.com > [mailto:owner-si-list@silab.eng.sun.com]On Behalf Of gedlund@us.ibm.com > Sent: Tuesday, November 16, 1999 8:24 AM > To: si-list@silab.eng.sun.com > Cc: ibis-users@vhdl.org > Subject: [SI-LIST] : IBIS datasheets for PCI and DDR > > > Hello All, > > My modeling group has a need for a generic IBIS datasheet that would > represent the full range of the PCI spec. I guess it would be pretty easy > to make from the spec (except the VT tables), but I figured why reinvent > the wheel. A behavioral HSPICE model would be nice, too. We're planning > to use these models in simulations to evaluate spec compliance. > > I'm also looking for the same thing for the DDR SDRAM spec. > > Greg Edlund > Advisory Engineer, Critical Net Analysis > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > > > > **** To unsubscribe from si-list: send e-mail to > majordomo@silab.eng.sun.com. In the BODY of message put: > UNSUBSCRIBE si-list, for more help, put HELP. si-list archives > are accessible at http://www.qsl.net/wb6tpu/si-list **** > > From owner-ibis Mon Nov 22 12:32:06 1999 Received: from osiris.vlsi.com ([63.194.140.25]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA23053 for ; Mon, 22 Nov 1999 12:32:01 -0800 (PST) Received: (from smtp@localhost) by osiris.vlsi.com (8.9.1a/8.9.1) id MAA12476; Mon, 22 Nov 1999 12:31:25 -0800 (PST) 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 via smap (V2.0) id xma012463; Mon, 22 Nov 99 12:31:06 -0800 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 XCVTM5PT; Mon, 22 Nov 1999 13:31:05 -0700 Sender: dsession@osiris.vlsi.com Message-ID: <3839A809.720ECED6@vlsi.com> Date: Mon, 22 Nov 1999 13:31:05 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: gedlund@us.ibm.com CC: si-list@silab.eng.sun.com, ibis-users@vhdl.org Subject: Re: IBIS datasheets for PCI and DDR References: <8525682B.005A12F0.00@D51MTA05.pok.ibm.com> Content-Type: multipart/mixed; boundary="------------745FA3F7A16517A621904AA5" This is a multi-part message in MIME format. --------------745FA3F7A16517A621904AA5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit gedlund@us.ibm.com wrote: > > Hello All, > > My modeling group has a need for a generic IBIS datasheet that would > represent the full range of the PCI spec. I guess it would be pretty easy > to make from the spec (except the VT tables), but I figured why reinvent > the wheel. A behavioral HSPICE model would be nice, too. We're planning > to use these models in simulations to evaluate spec compliance. > > I'm also looking for the same thing for the DDR SDRAM spec. > > Greg Edlund > Advisory Engineer, Critical Net Analysis > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com I've attached some behavioral HSPICE models for DDR 4x; the same approach should work for PCI. -- D. C. Sessions dc.sessions@vlsi.com --------------745FA3F7A16517A621904AA5 Content-Type: text/plain; charset=us-ascii; name="vi_functions.inc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vi_functions.inc" * AGP 2.0 V/I curve functions * Source: * AGP specification rev. 2.0 Figure 4-29 (3.3v) * AGP specification rev. 2.0 Figure 4-30 (1.5v) * AGP specification rev. 2.0 Figure 4-33 (1.5v) * Maximum pullup current at 3.3v .SUBCKT ioh33max pad vddq vssq E1 vddq offs + VOL='0.3*v(vddq,vssq)' E2 offs pad + VOL='((i(E1)/54m)*v(vddq,vssq)/(v(pad,vssq)+(0.4*v(vddq,vssq))))-v(vddq,offs)' + MAX=0 .ENDS ioh33max * Maximum pulldown current at 3.3v .SUBCKT iol33max pad vddq vssq E1 offs vssq + VOL='0.18*v(vddq,vssq)' E2 pad offs + VOL='((i(E1)/141m)*v(vddq,vssq)/v(vddq,pad))-v(offs,vssq)' + MAX=0 .ENDS iol33max * Minimum pullup current at 3.3v .SUBCKT ioh33min pad vddq vssq .PARAM + rline = '0.7/9m' E1 vddq offs VOL='0.1*v(vddq,vssq)' E2 offs pad + VOL='(i(E2)*rline)-v(vddq,offs)' + MIN=0 MAX=4 G1 offs pad + CUR='(v(vddq,vssq)*0.7/rline)-i(E2)' MIN=-50m MAX=0 R1 vddq pad 1e8 .ENDS ioh33min * Minimum pulldown current at 3.3v .SUBCKT iol33min pad vddq vssq .PARAM + rline = '0.6/12m' E1 offs vssq VOL='0.1*v(vddq,vssq)' E2 pad offs + VOL='(i(E2)*rline)-v(offs,vssq)' + MIN=0 MAX=4 G1 pad offs + CUR='(v(vddq,vssq)*0.6/rline)-i(E2)' + MIN=-50m MAX=0 R1 pad vssq 1e8 .ENDS iol33min * 1.5v constraint curves * Maximum pullup current at 1.5v (per 4-30) .SUBCKT ioh15max1 pad vddq vssq E1 vddq offs + VOL='0.3*v(vddq,vssq)' E2 offs pad + VOL='((i(E1)/111m)*v(vddq,vssq)/v(pad,vssq))-v(vddq,offs)' + MAX=0 .ENDS ioh15max1 * Maximum pulldown current at 1.5v (per 4-30) .SUBCKT iol15max1 pad vddq vssq E1 offs vssq + VOL='0.3*v(vddq,vssq)' E2 pad offs + VOL='((i(E1)/111m)*v(vddq,vssq)/v(vddq,pad))-v(offs,vssq)' + MAX=0 .ENDS iol15max1 * Minimum pullup current at 1.5v (per 4-30) .SUBCKT ioh15min1 pad vddq vssq .PARAM + rline = '0.675/11m' E1 vddq offs VOL='0.1*v(vddq,vssq)' E2 offs pad + VOL='(i(E2)*rline)-v(vddq,offs)' + MIN=0 MAX=2 G1 offs pad + CUR='(v(vddq,vssq)*0.675/rline)-i(E2)' MIN=-50m MAX=0 R1 vddq pad 1e8 .ENDS ioh15min1 * Minimum pulldown current at 1.5v (per 4-30) .SUBCKT iol15min1 pad vddq vssq .PARAM + rline = '0.675/11m' E1 offs vssq VOL='0.1*v(vddq,vssq)' E2 pad offs + VOL='(i(E2)*rline)-v(offs,vssq)' + MIN=0 MAX=2 G1 pad offs + CUR='(v(vddq,vssq)*0.675/rline)-i(E2)' + MIN=-50m MAX=0 R1 pad vssq 1e8 .ENDS iol15min1 * Maximum pullup current at 1.5v (per 4-33) .SUBCKT ioh15max2 pad vddq vssq .PARAM + ib1 = '200m/9' E1 vddq pad2 VOL='MIN(v(vddq,pad),v(vddq,vssq)/2) G1 vddq pad + CUR='ib1*(v(vddq,pad)+(v(pad2,vssq)*v(vddq,pad2)/v(vddq,vssq)))' R1 vddq pad 1e8 .ENDS ioh15max2 * Maximum pulldown current at 1.5v (per 4-33) .SUBCKT iol15max2 pad vddq vssq .PARAM + ib1 = '200m/9' E1 pad2 vssq VOL='MIN(v(pad,vssq),v(vddq,vssq)/2) G1 pad vssq + CUR='ib1*(v(pad,vssq)+(v(pad2,vssq)*v(vddq,pad2)/v(vddq,vssq)))' R1 pad vssq 1e8 .ENDS iol15max2 * Minimum pullup current at 1.5v (per 4-33) .SUBCKT ioh15min2 pad vddq vssq .PARAM + k1 = 48 $ 1/20.833m + k2 = 600 $ 1/1.667m + k3 = 'k2-k1' E1 n1 vddq VOL='MIN(-0.15*v(vddq,vssq),48*i(E1))' E2 pad n1 VOL='MIN(0,k3*(i(E1)+(0.5*v(vddq,vssq)/k1)))' .ENDS ioh15min2 * Minimum pulldown current at 1.5v (per 4-33) .SUBCKT iol15min2 pad vddq vssq .PARAM + k1 = 48 $ 1/20.833m + k2 = 600 $ 1/1.667m + k3 = 'k2-k1' E1 n1 vssq VOL='MAX(0.15*v(vddq,vssq),48*i(E1))' E2 pad n1 VOL='MAX(0,k3*(i(E1)-(0.5*v(vddq,vssq)/k1)))' .ENDS iol15min2 --------------745FA3F7A16517A621904AA5-- From owner-ibis Wed Nov 24 08:58:08 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 IAA06618 for ; Wed, 24 Nov 1999 08:58:07 -0800 (PST) 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 IAA09768; Wed, 24 Nov 1999 08:57:02 -0800 (PST) Message-Id: <199911241657.IAA09768@jasper.cisco.com> Date: Wed, 24 Nov 1999 08:57:02 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: Help To: ibis-users@eda.org, ibis@vhdl.org, sunweifeng@huawei.com.cn MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uKQMIZ5MzcT+OkLST8jPOA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Look at your 'putout.out' or 'putout.st0' file for errors.. Syed > Date: Wed, 24 Nov 1999 20:54:50 +0800 > From: sunweifeng > MIME-Version: 1.0 > To: ibis-users , "ibis-vhdl.org" > Subject: Help > X-SMTP-HELO: server.eda.org > X-SMTP-MAIL-FROM: owner-ibis@server.eda.org > X-SMAP-Received-From: outside > X-SMTP-PEER-INFO: server.eda.org [171.64.101.101] > > Hi Sir, > > I used the s2ibis2 to transit the spice model to ibis model. I run the > demo under the directory ex1, and there following note when run > "s2ibis2.solaris buffer.s2i" : > s2ibis2.solaris v1.1 -- North Carolina State University > s2ibis2.solaris: Reading input file buffer...done. > s2ibis2.solaris: Analyzing component MCM Driver . > s2ibis2.solaris: Starting HSpice job with input putout.spi. > s2ibis2.solaris: Error in executing HSpice. > s2ibis2.solaris: Error 0 > s2ibis2.solaris: Fatal error. > However it is OK when run "hspice buffer.sp", would please tell me > why? > Thank you very much. > > Best Regards, > > > Sun Weifeng From owner-ibis Tue Nov 30 08:06:36 1999 Received: from vlad.eng.mcd.mot.com (ftfservr.phx.mcd.mot.com [144.191.26.101]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA05402 for ; Tue, 30 Nov 1999 08:06:36 -0800 (PST) Received: from eng.mcd.mot.com (horizon.phx.mcd.mot.com [144.191.12.156]) by vlad.eng.mcd.mot.com (Postfix) with ESMTP id A9682180E for ; Tue, 30 Nov 1999 09:05:54 -0700 (MST) Sender: gtruong@eng.mcd.mot.com Message-ID: <3843F336.F0D4E10B@eng.mcd.mot.com> Date: Tue, 30 Nov 1999 08:54:31 -0700 From: gerald_truong X-Mailer: Mozilla 4.5 [en] (X11; I; AIX 4.1) X-Accept-Language: en MIME-Version: 1.0 To: ibis-users@eda.org Subject: s2ibis2 problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I am currently trying to get acquainted with the s2ibis2 utility but I am running into some problems. I am using Star-Hspice 98.2 as my simulator. On the second example, the tristate buffer, I keep getting errors and hspice aborting the simulation. The errors deal with non-convergence but I do not know how to fix them, I have already added a 1 ohm resistor on the output as advised by Alan Glaser the author of s2ibis2. Hspice craps out when trying to gather the data for the max pulldown output disabled curve, it then gives the following error: **warning** both nodes of source 0:vgnds2i are connected together **warning** negative-mos conductance = 0:mx24 iter= 21 vds,vgs,vbs = 24.3 0.594 -3.67 gm,gds,gmbs,ids= 4.697E-04 3.444E-05 -4.614E-06 2.122E-04 convergence problems in dc sweep curves at -0.30000 resimulating with dc convergence controls **diagnostic** dc convergence failure, resetting dcon option to 1 and retrying **diagnostic** dc convergence failure, resetting dcon option to 2 and retrying. *** error ***: no convergence in dc sweep curves at -0.30000 The first warning does not stop hspice from completing the simulation but I would like to know what it means and how can it be fixed. Thank you for your time. Long live IBIS! Gerald Truong Motorola Computer Group (602)438-3525. From owner-ibis Tue Nov 30 09:07:07 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 JAA05733 for ; Tue, 30 Nov 1999 09:07:07 -0800 (PST) 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 JAA18559; Tue, 30 Nov 1999 09:05:25 -0800 (PST) Message-Id: <199911301705.JAA18559@jasper.cisco.com> Date: Tue, 30 Nov 1999 09:05:24 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: s2ibis2 problems To: ibis-users@eda.org, gtruong@eng.mcd.mot.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: AF8EPDAaCJhXajZeu0u6lg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc This is a very typical problem. For example, most devices will fail DC convergence if you are sweeping at the extreme ranges required for IBIS(ie, -Vdd to +2Vdd). You need to tweak your sweep range. At -0.3V, it fails to converge. You can do this by editing your .spi file and manually changing the sweep range. Try a range from 0.0 to 3.3V Regards, Syed Cisco Systems, Inc > convergence problems in dc sweep curves at -0.30000 > resimulating with dc convergence controls > > > **diagnostic** dc convergence failure, > resetting dcon option to 1 and retrying > > > **diagnostic** dc convergence failure, > resetting dcon option to 2 and retrying. > > > > > *** error ***: no convergence in dc sweep curves at -0.30000 > From owner-ibis Tue Nov 30 22:51:30 1999 Received: from zukengw.zuken.co.jp (zukengw.zuken.co.jp [202.33.240.18]) by server.eda.org (8.8.5/8.8.3) with ESMTP id WAA08543 for ; Tue, 30 Nov 1999 22:51:29 -0800 (PST) Received: from zuken.co.jp ([160.249.234.114]) by zukengw.zuken.co.jp (8.8.8/3.6W) with ESMTP id PAA14983 for ; Wed, 1 Dec 1999 15:50:20 +0900 (JST) Received: from s4e24.zuken.co.jp (s4e24 [160.249.233.24]) by zuken.co.jp (8.8.8/3.6Wbeta7) with SMTP id PAA22704; Wed, 1 Dec 1999 15:50:19 +0900 (JST) Received: from s4e164 by s4e24.zuken.co.jp (1.38.193.4/6.4J.6-local-1.0) id AA18478; Wed, 1 Dec 1999 15:55:53 +0900 Message-Id: <4.0.1-J.19991201155626.00dd49b0@s4e24> X-Sender: k.mori@zuken.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1-J Date: Wed, 01 Dec 1999 15:57:46 +0900 To: ibis-users@eda.org From: =?ISO-2022-JP?B?GyRCQDkbKEI=?==?ISO-2022-JP?B?IBskQjdyPCEbKEI=?= Subject: about "Waveform","Vmeas","Rref","Cref","Vref" Cc: =?ISO-2022-JP?B?GyRCTlMbKEI=?= Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Hello all Please tell me about the next two items. The first item is about "Waveform". Why was this item made ? And How was this item used ? I often see this item in an IBIS model, but not useful eno ugh. The second item is about "Vmeas", "Rref", "Cref", and "Vref". These items a re used for a propagation delay. So, are these items "TEST LOAD" to get AC characteristics written into IC vendor's data-sheets ? Best Regards k.mori ================================================== $B@9(B $B7r