From owner-ibis Mon Mar 1 07:59:25 1999 Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA12521 for ; Mon, 1 Mar 1999 07:59:24 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by smtp8.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id KAA26992 for ; Mon, 1 Mar 1999 10:53:09 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay03.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id KAA264908 for ; Mon, 1 Mar 1999 10:53:32 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256727.0057490F ; Mon, 1 Mar 1999 10:53:23 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <85256727.00574764.00@D51MTA10.pok.ibm.com> Date: Mon, 1 Mar 1999 09:53:31 -0600 Subject: IBIS package modeling questions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello All, My understanding is that there are five levels of package modeling in IBIS: 1. R_pkg, L_pkg, C_pkg 2. R_pin, L_pin, C_pin 3. Coupled lumped model using the [Resistance/Inductance/Capacitance Matrix] keywords 4. Distributed (segmented) package model using subparameters under the [Pin Numbers] keyword 5. EBD Are levels 3 and 4 mutually exclusive, i.e. is it possible to create a coupled, distributed package model? I assume the existence of modeling data at levels 3 and 4 overrides data at levels 1 and 2. Is this true? Thanks for your time. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Mon Mar 1 08:59:56 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA12978 for ; Mon, 1 Mar 1999 08:59:56 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id IAA14502; Mon, 1 Mar 1999 08:53:38 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id IAA24496; Mon, 1 Mar 1999 08:53:36 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA06336; Mon, 1 Mar 99 08:53:36 PST Date: Mon, 1 Mar 99 08:53:36 PST Message-Id: <9903011653.AA06336@bob> To: gedlund@us.ibm.com, ibis-users@vhdl.org Subject: Re: IBIS package modeling questions Greg: My responses are in your text. Bob Ross Mentor Graphics > From owner-ibis@server.eda.org Mon Mar 1 07:59 PST 1999 > From: gedlund@us.ibm.com > To: ibis-users@vhdl.org > Date: Mon, 1 Mar 1999 09:53:31 -0600 > Subject: IBIS package modeling questions > Hello All, > My understanding is that there are five levels of package modeling in IBIS: > 1. R_pkg, L_pkg, C_pkg > 2. R_pin, L_pin, C_pin > 3. Coupled lumped model using the [Resistance/Inductance/Capacitance > Matrix] keywords > 4. Distributed (segmented) package model using subparameters under the > [Pin Numbers] keyword > 5. EBD > Are levels 3 and 4 mutually exclusive, i.e. is it possible to create a > coupled, distributed package model? Levels 3 and 4 as you define them are mutually exclusive. Within the current Version 3.2 level of IBIS you can only have a single stage of coupled package information, or multiple sections (segmented) of uncoupled package information consisting of discrete and distributed elements. > I assume the existence of modeling data at levels 3 and 4 overrides data at > levels 1 and 2. Is this true? Yes. Information in 2 overrides default information in 1. Any information in 3 or 4 overrides information in 1 or 2. > Thanks for your time. > Greg Edlund > Advisory Engineer, Critical Net Analysis > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com From owner-ibis Mon Mar 1 09:18:42 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA13081 for ; Mon, 1 Mar 1999 09:18:41 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id LAA25100 for ; Mon, 1 Mar 1999 11:13:25 -0600 (CST)] Received: [from msgphx1.sps.mot.com (msgphx1.sps.mot.com [216.11.52.1]) by mothost.mot.com (MOT-mothost 1.0) with ESMTP id LAA20501 for ; Mon, 1 Mar 1999 11:13:20 -0600 (CST)] Received: from email.sps.mot.com ([163.4.1.131]) by msgphx1.sps.mot.com (Netscape Messaging Server 3.6) with ESMTP id AAA10CA for ; Mon, 1 Mar 1999 10:13:15 -0700 Message-ID: <36DABCFE.A81F1461@email.sps.mot.com> Date: Mon, 01 Mar 1999 11:15:10 -0500 From: "Robert Goodrich" X-Mailer: Mozilla 4.03C-MOTSPS4.03 (Macintosh; I; PPC) MIME-Version: 1.0 To: "ibis-users@eda.org" Subject: IBIS Training Suggestions?? Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Motorola-Sent-Wireless: 1 To All: I was hoping someone could suggest an IBIS training course that is tailored towards someone in the IC industry that will be heading up the IBIS model creation effort in their group. I have used s2ibis2 to create a model from simulation data and read the spec./cookbook, but feel somewhat inadequate when pressed to explain the finer details of an IBIS model. Also, I would like some exposure to the bigger picture - how IBIS models are used. I have searched out several courses on the web, but would appreciate suggestions. --Rob -- Rob Goodrich Circuit Design - Advanced Imaging Technology (AIT) Motorola SPS, I&E Solutions 6501 William Cannon Drive West MD: OE37 Austin, TX 78735 ra3862@email.sps.mot.com (512) 895-7341 From owner-ibis Mon Mar 1 11:55:21 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 LAA13875 for ; Mon, 1 Mar 1999 11:55:19 -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.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id MAA27722; Mon, 1 Mar 1999 12:00:27 -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 LAA10220; Mon, 1 Mar 1999 11:49:58 -0800 (PST) Received: from ichips.intel.com (loopback.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 LAA17571; Mon, 1 Mar 1999 11:49:58 -0800 (PST) Message-Id: <199903011949.LAA17571@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: "Robert Goodrich" Cc: ibis-users@eda.org Subject: Re: IBIS Training Suggestions?? In-reply-to: Your message of "Mon, 01 Mar 1999 11:15:10 EST." <36DABCFE.A81F1461@email.sps.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Mar 1999 11:49:57 -0800 From: Stephen Peters Hello Bob: The IBIS East Users Group is in the process of putting together an IBIS training course that may address your concerns. I don't know the exact status, but Dr. Ed Sayre of Northeast Systems Assoc. is the head of this effort, and you can contact him thru his admin Kathy Brenda (brenda@nesa.com) (sorry, I can't find his direct contact number right now). Also, you might try contacting your simulation software vendor. I know that many CAE vendors offer IBIS training courses as part of the training on their software. Regards, Stephen Peters Intel Corp. Vice Chair, IBIS Open Forum > To All: > I was hoping someone could suggest an IBIS training course that is > tailored towards someone in the IC industry that will be heading up the > IBIS model creation effort in their group. I have used s2ibis2 to > create a model from simulation data and read the spec./cookbook, but > feel somewhat inadequate when pressed to explain the finer details of an > IBIS model. Also, I would like some exposure to the bigger picture - > how IBIS models are used. > > I have searched out several courses on the web, but would appreciate > suggestions. > --Rob > -- > > Rob Goodrich > Circuit Design - Advanced Imaging Technology (AIT) > Motorola SPS, I&E Solutions > 6501 William Cannon Drive West MD: OE37 > Austin, TX 78735 > ra3862@email.sps.mot.com > (512) 895-7341 > From owner-ibis Mon Mar 1 13:47:44 1999 Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA14149 for ; Mon, 1 Mar 1999 13:47:43 -0800 (PST) Received: from fishbowl02.emc.com (fishbowl02.lss.emc.com [168.159.48.62]) by emcmail.lss.emc.com (8.9.1/8.9.1) with SMTP id QAA29048 for ; Mon, 1 Mar 1999 16:41:17 -0500 (EST) Received: by fishbowl02.emc.com with VINES-ISMTP; Mon, 1 Mar 99 16:41:47 -0500 Date: Mon, 1 Mar 99 16:40:41 -0500 Message-ID: X-Priority: 3 (Normal) To: "Robert Goodrich" , Cc: From: "fabrizio zanella" Reply-To: Errors-to: Subject: Re: IBIS Training Suggestions?? X-Incognito-SN: 1467 X-Incognito-Version: 4.11.23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Bob, Stephen: The Mentor Graphics Interconnectix group offers a 1 day IBIS training class, which I believe is separate from their software, so can be taken by anyone. Regards, Fabrizio Zanella EMC, Hardware Engineering fzanella@emc.com 508-435-2075, x4645 ------------- Original Text From: "Stephen Peters" , on 3/1/99 2:49 PM: To: smtp@Eng@EMCHOP1["Robert Goodrich" ] Cc: smtp@Eng@EMCHOP1[] Hello Bob: The IBIS East Users Group is in the process of putting together an IBIS training course that may address your concerns. I don't know the exact status, but Dr. Ed Sayre of Northeast Systems Assoc. is the head of this effort, and you can contact him thru his admin Kathy Brenda (brenda@nesa.com) (sorry, I can't find his direct contact number right now). Also, you might try contacting your simulation software vendor. I know that many CAE vendors offer IBIS training courses as part of the training on their software. Regards, Stephen Peters Intel Corp. Vice Chair, IBIS Open Forum > To All: > I was hoping someone could suggest an IBIS training course that is > tailored towards someone in the IC industry that will be heading up the > IBIS model creation effort in their group. I have used s2ibis2 to > create a model from simulation data and read the spec./cookbook, but > feel somewhat inadequate when pressed to explain the finer details of an > IBIS model. Also, I would like some exposure to the bigger picture - > how IBIS models are used. > > I have searched out several courses on the web, but would appreciate > suggestions. > --Rob > -- > > Rob Goodrich > Circuit Design - Advanced Imaging Technology (AIT) > Motorola SPS, I&E Solutions > 6501 William Cannon Drive West MD: OE37 > Austin, TX 78735 > ra3862@email.sps.mot.com > (512) 895-7341 > a From owner-ibis Mon Mar 1 14:48:31 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 OAA14358 for ; Mon, 1 Mar 1999 14:48:31 -0800 (PST) Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) 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 WAA02028; Mon, 1 Mar 1999 22:43:15 GMT Message-Id: <199903012243.WAA02028@thalia.fm.intel.com> Received: by FMSMSX27 with Internet Mail Service (5.5.2448.0) id <1RDKFX72>; Mon, 1 Mar 1999 14:43:14 -0800 From: "Muranyi, Arpad" To: "\"ibis-users@eda.org\" " , "\"Robert Goodrich\" " Subject: RE: IBIS Training Suggestions?? Date: Mon, 1 Mar 1999 14:42:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain I will be teaching on the subject of IBIS modeling and model making in a three-day short course mid April. My part will be only half day long (4-hours), the rest will be Signal Integrity, and related items by other presenters. Here is the URL for more information: http://intermix.engr.arizona.edu/~epd/#CSSI Arpad ============================================================================ === To All: I was hoping someone could suggest an IBIS training course that is tailored towards someone in the IC industry that will be heading up the IBIS model creation effort in their group. I have used s2ibis2 to create a model from simulation data and read the spec./cookbook, but feel somewhat inadequate when pressed to explain the finer details of an IBIS model. Also, I would like some exposure to the bigger picture - how IBIS models are used. I have searched out several courses on the web, but would appreciate suggestions. --Rob -- Rob Goodrich Circuit Design - Advanced Imaging Technology (AIT) Motorola SPS, I&E Solutions 6501 William Cannon Drive West MD: OE37 Austin, TX 78735 ra3862@email.sps.mot.com (512) 895-7341 From owner-ibis Tue Mar 2 11:13:28 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA18060; Tue, 2 Mar 1999 11:13:27 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id LAA16660; Tue, 2 Mar 1999 11:07:40 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id LAA01474; Tue, 2 Mar 1999 11:07:37 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA07106; Tue, 2 Mar 99 11:07:38 PST Date: Tue, 2 Mar 99 11:07:38 PST Message-Id: <9903021907.AA07106@bob> To: ibis-users@eda.org, ibis@eda.org, si-list@silab.eng.sun.com Subject: AGENDA - EUROPEAN IBIS SUMMIT MEETING To All: Below is the Agenda showing the planned sequence of presentations. Exact times are not given since we will be flexible to allow discussions, unscheduled topics and questions topics. The General Questions and Discussions Topic shown in the AGENDA may occur at any time. See you in Munich! Best Regards Bob Ross Mentor Graphics A G E N D A E U R O P E A N I B I S S U M M I T M E E T I N G 12 PM - 6 PM, Tuesday, March 9, 1999 ASTRON HOTEL/Neue Messe Eggenfeldener Strasse 100 Munich, Germany Co-sponsored by Mentor Graphics, INCASES, High Design Technology (HDT) AGENDA: 12:00: LUNCH (Provided to all participants) 13:00 MEETING BEGINS Current IBIS Activities and Issues Bob Ross, Mentor Graphics Detecting Typical Bugs in IBIS Models Werner Rissiek, INCASES Engineering Validation of an Enhanced Two Waveform Behavioral Model Bernhard Unger, Siemens AG IBIS Version 3.2 Update Stephen Peters, Intel General Questions and Discussions - IBIS Interpretation 15:00 BREAK IBIS Management and CHECK at Siemens ICN Gerald Bannert, Siemens DOGEN, An Internal Model Library Management Tool Hans Pichlmaier, Siemens IBIS Future Requirements Stephen Peters, Intel Future Requirements on Frequency Dependent Package and MCM Modeling Werner Rissiek, INCASES Engineering General Questions and Discussions - Future Requirements - Any other topic of interest - Meeting Wrapup 18:00 END OF MEETING From owner-ibis Tue Mar 2 12:01: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 MAA18282; Tue, 2 Mar 1999 12:01:38 -0800 (PST) Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) 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 TAA08129; Tue, 2 Mar 1999 19:56:21 GMT Message-Id: <199903021956.TAA08129@thalia.fm.intel.com> Received: by FMSMSX17 with Internet Mail Service (5.5.2232.9) id ; Tue, 2 Mar 1999 11:56:20 -0800 From: "Muranyi, Arpad" To: "\"ibis-users@eda.org\" " , "\"ibis@eda.org\" " , "\"si-list@silab.eng.sun.com\" " Subject: SI opening at Intel, Folsom, CA Date: Tue, 2 Mar 1999 11:55:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Intel Corporation has an immediate opening for a signal integrity engineer at the Platform Component Division (PCD) in Folsom California. If you are qualified and interested please contact and/or send resume to Henri Maramis via EMAIL or phone at henri.maramis@intel.com (916) 356-6413. Responsibilities: Designs and performs analog simulations of system level interconnects for PC based platforms. Prepares I/O buffer models, transmission line models, and packaging parasitic models for accurate correlated simulations. Performs system level critical path timing, pre and post layout analyses. Uses engineering judgment in data analysis to establish design process and CAD tool flow. U.S. typically requires a Bachelor's Degree in Elec. Eng. or Comp. Eng. +3 years experience, or a Master's Degree +2 years experience. Skills: Knowledge/experience with IBIS models and simulation/timing tools, such as HSPICE, Quad Design, Cadence SpecctraQuest, Interconnectix, and Timing Designer. Extended coursework in electromagnetic fields and waves, and transmission line analysis. Knowledge of PC based system architecture, high speed bus interfaces, and high performance signaling techniques. This includes bus and system timing, signal integrity analysis, cross talk analysis, ground bounce analysis, power integrity analysis, as well as board layout techniques. From owner-ibis Wed Mar 3 00:09:11 1999 Received: from galileo5.galileo.co.il ([192.116.246.130]) by server.eda.org (8.8.5/8.8.3) with ESMTP id AAA20066 for ; Wed, 3 Mar 1999 00:09:08 -0800 (PST) Received: from galileo.co.il (galileo89.galileo.co.il [10.3.10.89]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id KAA03131 for ; Wed, 3 Mar 1999 10:01:16 +0200 (GMT-2) Sender: dan@galileo.co.il Message-ID: <36DCEC4A.FF8C52B0@galileo.co.il> Date: Wed, 03 Mar 1999 10:01:14 +0200 From: Dan Aleksandrowicz Organization: GALILEO Technology Ltd. X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: "ibis-users@eda.org" Subject: Re: SI opening at Intel, Folsom, CA References: <199903021956.TAA08129@thalia.fm.intel.com> Content-Type: multipart/alternative; boundary="------------FAEF2BE6BE43CCF9ECA45A5A" --------------FAEF2BE6BE43CCF9ECA45A5A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi There. I know we have discuss this issue in the past in respect of product features. And though this kind head hunting is defiantly IS NOT equivalent to product promotion, I am still a bit reserved about using this open channel for head hunting. If any one disagrees to my opinion, I can definitely understand it. There might be a better solution by using the IBIS web site, though, this might lead to other legal difficulties. I would like if we could find a common solution to this need. Thanks. Muranyi, Arpad wrote: > Intel Corporation has an immediate opening for a signal integrity engineer > at > the Platform Component Division (PCD) in Folsom California. If you are > qualified and interested please contact and/or send resume to Henri Maramis > via > EMAIL or phone at henri.maramis@intel.com (916) 356-6413. > -- \\|// (o o) ~~~~~~~~~~~~oOOo~(_)~oOOo~~~~~~~~~~~~~~~~~~~ Dan Aleksandrowicz Galileo Technology Giron 15, Yahud - Israel email:dan@galileo.co.il Tel: +972 3 6320220 (- Ext. 324 |__| |__| #|oo| |--| ___ _ _ |--| | | |\ |oo|) /\ __ \\ \\ |------------\| #|--\ _||- ____\ \__\\_\\__|_||_________________\___| |__v-___ \ / \ "Smoke on the water. Fire in the sky." / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------FAEF2BE6BE43CCF9ECA45A5A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi There.

I know we have discuss this issue in the past in respect of product features.
And though this kind head hunting is defiantly IS NOT equivalent to product
promotion, I am still a bit reserved about using this open channel for head hunting.

If any one disagrees to my opinion, I can definitely understand it. There might
be a better solution by using the IBIS web site, though, this might lead to other
legal difficulties. I would like if we could find a common solution to this need.

Thanks.
 
 

Muranyi, Arpad wrote:

Intel Corporation has an immediate opening for a signal integrity engineer
at
the Platform Component Division (PCD) in Folsom California.  If you are
qualified and interested please contact and/or send resume to Henri Maramis
via
EMAIL or phone at henri.maramis@intel.com (916) 356-6413.
 
  
-- 
                \\|//
                (o o)
~~~~~~~~~~~~oOOo~(_)~oOOo~~~~~~~~~~~~~~~~~~~
Dan Aleksandrowicz
Galileo Technology 
Giron 15, Yahud - Israel
email:dan@galileo.co.il
Tel: +972 3 6320220    (-                    
     Ext. 324         |__|
                      |__|
                     #|oo| |--|   ___
           _  _    |--|  | |  |\ |oo|)        /\
       __  \\ \\   |------------\| #|--\     _||-
   ____\ \__\\_\\__|_||_________________\___|   |__v-___
   \                                                   /
    \      "Smoke on the water. Fire in the sky."     /
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  --------------FAEF2BE6BE43CCF9ECA45A5A-- From owner-ibis Wed Mar 3 01:20:35 1999 Received: from exchange2.via.com.tw (exchange2.via.com.tw [202.145.217.249]) by server.eda.org (8.8.5/8.8.3) with ESMTP id BAA20179 for ; Wed, 3 Mar 1999 01:20:33 -0800 (PST) Received: by exchange2.via.com.tw with Internet Mail Service (5.5.2232.9) id ; Wed, 3 Mar 1999 17:19:44 +0800 Message-ID: <9BADB79F06B3D211974800A0C92BD8A0080FE0@exchange2.via.com.tw> From: Weber Chuang To: ibis-users@eda.org Subject: RE : SI opening at Intel, Folsom, CA Date: Wed, 3 Mar 1999 17:19:42 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Dear IBIS gurus, In my memory, most people seem to accept such job openings in si-list if not from head hunters, but might not be in the IBIS Forum. So it would be much better if only si-list is used next time. Thanks! Best Regards Weber Chuang(ChingFu Chuang) Mgr. of SI team. VIA Technologies, Inc. Taipei, Taiwan, ROC TEL : 886-2-22185452 ext : 6522 http://www.via.com.tw Very Innovative Architecture > -----Original Message----- > From: Dan Aleksandrowicz [SMTP:dan@galileo.co.il] > Sent: Wednesday, March 03, 1999 4:01 PM > To: ibis-users@eda.org > Subject: Re: SI opening at Intel, Folsom, CA > > Hi There. > > I know we have discuss this issue in the past in respect of product > features. > And though this kind head hunting is defiantly IS NOT equivalent to > product > promotion, I am still a bit reserved about using this open channel for > head > hunting. > > If any one disagrees to my opinion, I can definitely understand it. There > might > > be a better solution by using the IBIS web site, though, this might lead > to > other > legal difficulties. I would like if we could find a common solution to > this > need. > > Thanks. > > > > Muranyi, Arpad wrote: > > > Intel Corporation has an immediate opening for a signal integrity > engineer > > at > > the Platform Component Division (PCD) in Folsom California. If you are > > qualified and interested please contact and/or send resume to Henri > Maramis > > via > > EMAIL or phone at henri.maramis@intel.com (916) 356-6413. > > > > > > -- > \\|// > (o o) > ~~~~~~~~~~~~oOOo~(_)~oOOo~~~~~~~~~~~~~~~~~~~ > Dan Aleksandrowicz > Galileo Technology > Giron 15, Yahud - Israel > email:dan@galileo.co.il > Tel: +972 3 6320220 (- > Ext. 324 |__| > |__| > #|oo| |--| ___ > _ _ |--| | | |\ |oo|) /\ > __ \\ \\ |------------\| #|--\ _||- > ____\ \__\\_\\__|_||_________________\___| |__v-___ > \ / > \ "Smoke on the water. Fire in the sky." / > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > << File: ATT00001.html >> From owner-ibis Wed Mar 3 04:31:36 1999 Received: from fl51m03.space.honeywell.com (fl51m03.space.honeywell.com [130.181.6.220]) by server.eda.org (8.8.5/8.8.3) with ESMTP id EAA20721 for ; Wed, 3 Mar 1999 04:31:22 -0800 (PST) Received: by fl51m03.space.honeywell.com with Internet Mail Service (5.5.2448.0) id ; Wed, 3 Mar 1999 07:25:10 -0500 Message-ID: From: "Peterson, James F (FL51)" To: Dan Aleksandrowicz , ibis-users@eda.org Subject: RE: SI opening at Intel, Folsom, CA Date: Wed, 3 Mar 1999 07:26:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" hey there, Head hunting hasn't dominated our reflector. If it did I would be concerned. As long as it stays around the current level I believe it's another part of this business we're in (it can even help some of us stay in business). It was correctly described in the subject section so those not interested could delete. Jim Peterson -----Original Message----- From: Dan Aleksandrowicz [mailto:dan@galileo.co.il] Sent: Wednesday, March 03, 1999 3:01 AM To: ibis-users@eda.org Subject: Re: SI opening at Intel, Folsom, CA Hi There. I know we have discuss this issue in the past in respect of product features. And though this kind head hunting is defiantly IS NOT equivalent to product promotion, I am still a bit reserved about using this open channel for head hunting. If any one disagrees to my opinion, I can definitely understand it. There might be a better solution by using the IBIS web site, though, this might lead to other legal difficulties. I would like if we could find a common solution to this need. Thanks. Muranyi, Arpad wrote: Intel Corporation has an immediate opening for a signal integrity engineer at the Platform Component Division (PCD) in Folsom California. If you are qualified and interested please contact and/or send resume to Henri Maramis via EMAIL or phone at henri.maramis@intel.com (916) 356-6413. -- \\|// (o o) ~~~~~~~~~~~~oOOo~(_)~oOOo~~~~~~~~~~~~~~~~~~~ Dan Aleksandrowicz Galileo Technology Giron 15, Yahud - Israel email:dan@galileo.co.il Tel: +972 3 6320220 (- Ext. 324 |__| |__| #|oo| |--| ___ _ _ |--| | | |\ |oo|) /\ __ \\ \\ |------------\| #|--\ _||- ____\ \__\\_\\__|_||_________________\___| |__v-___ \ / \ "Smoke on the water. Fire in the sky." / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ibis Wed Mar 3 07:53:46 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 HAA21211 for ; Wed, 3 Mar 1999 07:53:42 -0800 (PST) Received: (qmail 8344 invoked by alias); 3 Mar 1999 15:48:10 -0000 Delivered-To: fixup-ibis-users@eda.org@fixme Received: (qmail 8328 invoked by uid 0); 3 Mar 1999 15:48:09 -0000 Received: from dialupd246.ptld.uswest.net (HELO vasthorizons.com) (207.225.84.246) by ptldpop1.ptld.uswest.net with SMTP; 3 Mar 1999 15:48:09 -0000 Message-ID: <36DD59C4.F3A08B28@vasthorizons.com> Date: Wed, 03 Mar 1999 07:48:20 -0800 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: ibis-users@eda.org Subject: Re: SI opening at Intel, Folsom, CA References: Content-Type: multipart/mixed; boundary="------------5E8D9AA1D127CBF08542EB19" This is a multi-part message in MIME format. --------------5E8D9AA1D127CBF08542EB19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Openings for a particular position and head hunting are two different matters. I have no problem with someone normally associated with the reflector posting a job. Besides, we take up more channel bandwidth and time discussing the matter each time it comes up than the time it takes to read and discard the message if one is not interested. Scott "Peterson, James F (FL51)" wrote: > hey there, > Head hunting hasn't dominated our reflector. If it did I would be concerned. > As long as it stays around the current level I believe it's another part of > this business we're in (it can even help some of us stay in business). It > was correctly described in the subject section so those not interested could > delete. > Jim Peterson > > > -----Original Message----- > From: Dan Aleksandrowicz [mailto:dan@galileo.co.il] > Sent: Wednesday, March 03, 1999 3:01 AM > To: ibis-users@eda.org > Subject: Re: SI opening at Intel, Folsom, CA > > Hi There. > > I know we have discuss this issue in the past in respect of product > features. > And though this kind head hunting is defiantly IS NOT equivalent to product > promotion, I am still a bit reserved about using this open channel for head > hunting. > > If any one disagrees to my opinion, I can definitely understand it. There > might > be a better solution by using the IBIS web site, though, this might lead to > other > legal difficulties. I would like if we could find a common solution to this > need. > > Thanks. > > > > Muranyi, Arpad wrote: > > Intel Corporation has an immediate opening for a signal integrity engineer > at > the Platform Component Division (PCD) in Folsom California. If you are > qualified and interested please contact and/or send resume to Henri Maramis > via > EMAIL or phone at henri.maramis@intel.com (916) 356-6413. > > > -- > > \\|// > > (o o) > > ~~~~~~~~~~~~oOOo~(_)~oOOo~~~~~~~~~~~~~~~~~~~ > > Dan Aleksandrowicz > > Galileo Technology > > Giron 15, Yahud - Israel > > email:dan@galileo.co.il > > Tel: +972 3 6320220 (- > > Ext. 324 |__| > > |__| > > #|oo| |--| ___ > > _ _ |--| | | |\ |oo|) /\ > > __ \\ \\ |------------\| #|--\ _||- > > ____\ \__\\_\\__|_||_________________\___| |__v-___ > > \ / > > \ "Smoke on the water. Fire in the sky." / > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > --------------5E8D9AA1D127CBF08542EB19 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;fax:503-239-0649 tel;home:503-239-6237 tel;work:503-708-4320 x-mozilla-html:TRUE org:SiQual adr:;;;;;; version:2.1 email;internet:scott@vasthorizons.com title:Principal Engineer fn:Scott McMorrow end:vcard --------------5E8D9AA1D127CBF08542EB19-- From owner-ibis Wed Mar 3 09:10:55 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 JAA21522; Wed, 3 Mar 1999 09:10:55 -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.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA16736; Wed, 3 Mar 1999 09:16:07 -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 JAA29832; Wed, 3 Mar 1999 09:05:38 -0800 (PST) Received: from ichips.intel.com (loopback.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 JAA02076; Wed, 3 Mar 1999 09:05:37 -0800 (PST) Message-Id: <199903031705.JAA02076@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: Job Announcements Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Mar 1999 09:05:37 -0800 From: Stephen Peters Hello All: For everyone's information, the official IBIS open forum policy regarding job postings is as follows (quote is from an earlier e-mail from the IBIS Open Forum Chair): "We have established a policy that the IBIS reflectors are not to be used for recruitment activities because of our membership with EIA (which disallows this) and because the IBIS activity and participation is company sponsored." Remember that the SI list is available for job postings. Thanks for your cooperation. Regards, Stephen Peters Intel Corp. Vice Chair, IBIS Open Forum From owner-ibis Wed Mar 3 10:23:11 1999 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA21686; Wed, 3 Mar 1999 10:23:10 -0800 (PST) Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by calliope1.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 SAA15832; Wed, 3 Mar 1999 18:17:54 GMT Message-Id: <199903031817.SAA15832@calliope1.fm.intel.com> Received: by FMSMSX19 with Internet Mail Service (5.5.2448.0) id ; Wed, 3 Mar 1999 10:17:53 -0800 From: "Muranyi, Arpad" To: "\"ibis@eda.org\" " , "\"ibis-users@eda.org\" " Subject: RE: Job Announcements Date: Wed, 3 Mar 1999 10:17:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain I apologize for the posting on these two reflectors, I was not aware of this policy. Arpad ============================================================================ = Hello All: For everyone's information, the official IBIS open forum policy regarding job postings is as follows (quote is from an earlier e-mail from the IBIS Open Forum Chair): "We have established a policy that the IBIS reflectors are not to be used for recruitment activities because of our membership with EIA (which disallows this) and because the IBIS activity and participation is company sponsored." Remember that the SI list is available for job postings. Thanks for your cooperation. Regards, Stephen Peters Intel Corp. Vice Chair, IBIS Open Forum From owner-ibis Wed Mar 3 11:46:11 1999 Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA21925 for ; Wed, 3 Mar 1999 11:46:10 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by smtp7.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id OAA144308 for ; Wed, 3 Mar 1999 14:40:09 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id OAA217376 for ; Wed, 3 Mar 1999 14:40:20 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256729.006C0BC6 ; Wed, 3 Mar 1999 14:40:09 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <85256729.006C0A22.00@D51MTA10.pok.ibm.com> Date: Wed, 3 Mar 1999 13:40:16 -0600 Subject: IBIS Users Group Minutes 2/26/99 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline IBIS Users Group Minutes 2/26/99 Participants on 2/26/99 Compaq Bob Haller Hyperlynx Matt Flora IBM Mike Cohen, Greg Edlund LSI Logic Scott King Mentor Graphics Bob Ross National Semiconductor Milt Schwartz NESA Ed Sayre TDA Systems Dima Smolyansky Thanks to Bob Ross and Mentor Graphics for funding the phone bridge. Next conference call: Date: 3/19/99 Time: 8:00 - 9:55 am PST Phone number: (805) 240-9673 Passcode: 773000 PART I: IBIS ACCURACY SUBCOMMITTEE Matt Flora, Ed Sayre, and Bob Ross expressed opinions in favor of keeping the name "IBIS Accuracy Subcommittee." The group agreed to keep this name for 1999. The group also agreed that Greg Edlund will continue in his position of chairman of the IBIS Accuracy Subcommittee for 1999 (in the absence of any other interested parties). Greg Edlund will also continue as editor of the IBIS Accuracy Specification document itself. The group decided to leave the meeting time stand at 8:00 PST. IBIS ACCURACY SPECIFICATION 1.2 REVISIONS There are two main improvements in version 1.2 of the IBIS Accuracy Specification: 1) updating the correlation section to reflect the new correlation strategy presented at the DesignCon99 IBIS Summit and 2) updating the measurement section to facilitate future expansions. Greg Edlund will begin work on these changes and distribute a new copy of the spec for review. ACCURACY-RELATED BIRD(S) Bob Ross suggested that we post a note to the reflector soliciting response from the IBIS community on whether or not a BIRD should attempt to define our new test loads in a machine-readable format. Action item taken. EIA APPROVAL Bob Haller will lead the effort to obtain EIA approval for the IBIS Accuracy Specification in 1999. Bob Ross has alerted Patty Rusher to expect the IBIS Accuracy Specification to be submitted to the EIA in 1999. There was discussion around which version of the IBIS Accuracy Specification to submit to the EIA. Bob Ross suggested that we configure the spec so as not to be dependent on a new BIRD and proceed. Greg Edlund argued that we should proceed with version 1.2, including the changes mentioned above. The group did not reach a decision on this point. IBIS ACCURACY SPECIFICATION 2.0 DEVELOPMENT Bob Ross commented that most EDA vendors presently consider IBIS 1.1 datasheets as inaccurate and recommended that we don't focus on which version of IBIS to cover. Mike Cohen highlighted two areas in which his group is seeing the need for accuracy development: VT tables and multi-staged drivers. The IBIS Accuracy Subcommittee needs to come up with a list of possible additions to the IBIS Accuracy Specification and then prioritize the list. TEST BOARD Bob Haller commented that a few simple changes to the test board would bring significant enhancements. Bob Haller and Greg Edlund agreed to exchange ideas for test board changes off-line. Milt Schwartz mentioned that National Semiconductor has a board shop that may be able to help with the test board. He agreed to pursue a quote. There was some discussion about making as many as 50 test boards to distribute to interested parties. Greg Edlund has agreed to write an application note for the test board (someday). Bob Haller said that the current version of the test board could be used as a spring-board to include other part types. ACCURACY ACTION ITEMS 1. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Edit measurement and correlation sections of the IBIS Accuracy Specification and distribute the new document. 2. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Write email to the reflector soliciting input on the contents of an accuracy-related BIRD. At issue is whether or not to include a machine-readable description of the test loads described in the IBIS Accuracy Specification. 3. Status: open. Opened: 2/26/99 Owner: Peter LaFlamme. Make VCX16244 SPICE model and IBIS datasheet available on the accuracy web page. 4. Status: open. Opened: 2/26/99 Owner: Bob Haller, Greg Edlund. Discuss test board changes off-line. 5. Status: open. Opened: 2/26/99 Owner: Milt Schwarz. Get quote for building revision 3 of the test board. 6. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Write test board application note. 7. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Send out a note to the reflector suggesting possible candidates for accuracy development in 1999. PART II: EDUCATION SUBCOMMITTEE Ed Sayre has contacted a university professor who has expressed an interest in developing an IBIS curriculum. Ed estimates the project will take 6-9 months to produce a first cut. He may solicit small grants cover costs. Bob Ross cautioned that any educational effort should have IBIS 2.1 as a baseline. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Thu Mar 4 10:19:44 1999 Received: from mailhost.pii.com (mailhost.pii.com [192.77.209.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA25202 for ; Thu, 4 Mar 1999 10:19:43 -0800 (PST) Received: from nashex.pii.com (nashex.pii.com [192.168.203.242]) by mailhost.pii.com (8.9.1/8.9.1/Praegitzer-antispam) with ESMTP id KAA10951 for ; Thu, 4 Mar 1999 10:14:48 -0800 (PST) Received: by nashex.pii.com with Internet Mail Service (5.5.1960.3) id <19DXY9X2>; Thu, 4 Mar 1999 13:11:38 -0500 Message-ID: <31F863AE4B2DD211A01900A0C9CFAD3C0BF9E7@nashex.pii.com> From: Rick Newell To: ibis-users@eda.org Subject: anything Date: Thu, 4 Mar 1999 13:11:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain subscribe list From owner-ibis Mon Mar 8 08:43:19 1999 Received: from mail.iol.ie (mail2.mail.iol.ie [194.125.2.193]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA06846 for ; Mon, 8 Mar 1999 08:43:18 -0800 (PST) Received: from cmemory.ie ([194.125.127.225]) by mail.iol.ie Sendmail (v8.9.3) with SMTP id QAA90584 for ; Mon, 8 Mar 1999 16:37:27 GMT Message-Id: <199903081637.QAA90584@mail.iol.ie> Date: Mon, 08 Mar 99 16:37:10 +0000 From: "Owen Power" Subject: Compact Flash memory cards Sender: "Owen Power" To: "'ibis-users@eda.org'" MIME-Version: 1.0 Hi does anyone out there know of any test system available to test Compact Flash memory cards (10/20 Mbytes) with 84-Mbit Flash memory Chips. Any information would be greatly appreciated. Regards Owen Power Owen Power Dane-Elec Manufacturing PH: 353-91-504208(Direct) PH: 353-91-553000 FAX: 353-91-504234 power@dane-elec.ie From owner-ibis Mon Mar 8 15:26:31 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 PAA07801 for ; Mon, 8 Mar 1999 15:26:29 -0800 (PST) From: nikolai@avanticorp.com Received: (from uucp@localhost) by mailhost.avanticorp.com (8.9.3/8.9.3) id PAA14261; Mon, 8 Mar 1999 15:21:09 -0800 (PST) Received: from avant250.src.avanticorp.com(172.18.10.12) via SMTP by shamu.avanticorp.com, id smtpdAAA0Qy.VN; Mon Mar 8 15:21:02 1999 Received: from iris.src.avanticorp.com (iris.src.avanticorp.com [172.18.5.78]) by avant250.src.avanticorp.com (8.9.3/8.9.3) with ESMTP id PAA14193; Mon, 8 Mar 1999 15:21:01 -0800 (PST) Received: (from nikolai@localhost) by iris.src.avanticorp.com (8.8.8/8.8.8) id PAA06370; Mon, 8 Mar 1999 15:16:11 -0800 (PST) Date: Mon, 8 Mar 1999 15:16:11 -0800 (PST) Message-Id: <199903082316.PAA06370@iris.src.avanticorp.com> To: ibis_users@eda.org Subject: ibischk3 Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 45 Hi: I am upgraiding ibis 2.1 parser in hspice to ibis 3.2 It seems to me ibischk3 has problems which ibischk2 did not have: namely it has memory leaks and UMR (uninitialised memory read). It does not necesserily mean any error, but it would be certaintly better to avoid any UMR, etc. I have attached 2 randomly taken log files (output of purify) which shows the problems. Any comments suggestions? I did not try to fix this myself. One more thing: The very 1st version of the parser, V01 (files v01.c, v01.c) is used for IBIS 1.1 ( why ??? - it was NOT used in IBIS 2.1 ) in the current release (3.2). It is not good because the same IBIS file may have versions 1.1, or 2.1, or 3.2 (because of the back compatibility). And it should be processed by the same code (othervise subtle differences in the code can result in differences in the way how IBIS files are processed by the purser depending on the version number). IBIS parser 1.1 and 2.1 should be kept for historical purpose only, we do not need 2 or more parsers for the same file. Any comments? thanks Nik -------------------------------------- Nikolai Bannov Avant! Corporation 46871 Bayside Parkway Fremont, CA 94538 tel: 510-413-8634 fax: 510-413-8080 email: nikolai@avanticorp.com -------------------------------------- ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: pure_ibis3_log1 X-Sun-Charset: us-ascii X-Sun-Content-Lines: 267 **** Purify instrumented _pureibs3 (pid 6327 at Mon Mar 8 14:55:40 1999) * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. * For contact information type: "purify -help" * For TTY output, use the option "-windows=no" * Command-line: _pureibs3 test2 * Options settings: -purify \ -purify-home=/net/engage/usr2/CM/pure/purify-4.1-solaris2 * Purify licensed to ADS SOFTWARE INC * Purify checking enabled. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (192 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:501] acdc_CheckModel [cdc.c:539] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (263 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:501] acdc_CheckModel [cdc.c:539] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (192 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:504] acdc_CheckModel [cdc.c:539] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (263 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:504] acdc_CheckModel [cdc.c:539] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (196 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:501] acdc_CheckModel [cdc.c:540] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (278 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:501] acdc_CheckModel [cdc.c:540] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (196 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:504] acdc_CheckModel [cdc.c:540] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (278 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:504] acdc_CheckModel [cdc.c:540] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (193 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:501] acdc_CheckModel [cdc.c:541] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (283 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:501] acdc_CheckModel [cdc.c:541] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (193 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:504] acdc_CheckModel [cdc.c:541] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (283 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessWave [cdc.c:272] acdc_CheckModelProcess [cdc.c:504] acdc_CheckModel [cdc.c:541] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe56c on the stack. * Address 0xefffe56c is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (65 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessTestLoad [cdc.c:196] acdc_CheckModelProcess [cdc.c:506] acdc_CheckModel [cdc.c:539] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe5ec on the stack. * Address 0xefffe5ec is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (56 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessTestLoad [cdc.c:196] acdc_CheckModelProcess [cdc.c:506] acdc_CheckModel [cdc.c:539] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe5ec on the stack. * Address 0xefffe5ec is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (66 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessTestLoad [cdc.c:196] acdc_CheckModelProcess [cdc.c:506] acdc_CheckModel [cdc.c:540] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe5ec on the stack. * Address 0xefffe5ec is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (57 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessTestLoad [cdc.c:196] acdc_CheckModelProcess [cdc.c:506] acdc_CheckModel [cdc.c:540] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe5ec on the stack. * Address 0xefffe5ec is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (65 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessTestLoad [cdc.c:196] acdc_CheckModelProcess [cdc.c:506] acdc_CheckModel [cdc.c:541] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe5ec on the stack. * Address 0xefffe5ec is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** UMR: Uninitialized memory read (57 times): * This is occurring while in: acdc_Interesction [cdc.c:81] acdc_VI_Given_VIC_VR [cdc.c:130] acdc_CheckModelProcessTestLoad [cdc.c:196] acdc_CheckModelProcess [cdc.c:506] acdc_CheckModel [cdc.c:541] acdc_CheckAllModels [cdc.c:562] * Reading 4 bytes from 0xefffe5ec on the stack. * Address 0xefffe5ec is 4 bytes below frame pointer in function acdc_Interesction. **** Purify instrumented _pureibs3 (pid 6327) **** Current file descriptors in use: 5 FIU: file descriptor 0: FIU: file descriptor 1: FIU: file descriptor 2: FIU: file descriptor 26: FIU: file descriptor 27: **** Purify instrumented _pureibs3 (pid 6327) **** Purify: Searching for all memory leaks... Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%) Purify Heap Analysis (combining suppressed and unsuppressed blocks) Blocks Bytes Leaked 0 0 Potentially Leaked 0 0 In-Use 0 0 ---------------------------------------- Total Allocated 0 0 **** Purify instrumented _pureibs3 (pid 6327) **** * Program exited with status code 0. * 18 access errors, 3176 total occurrences. * 0 bytes leaked. * 0 bytes potentially leaked. * Basic memory usage (including Purify overhead): 806204 code 111276 data/bss 352256 heap (peak use) 4408 stack * Shared library memory usage (including Purify overhead): 135729 libm.so.1_pure_p3_c0_410_551 (shared code) 5872 libm.so.1_pure_p3_c0_410_551 (private data) 804233 libc.so.1_pure_p3_c0_410_551 (shared code) 34892 libc.so.1_pure_p3_c0_410_551 (private data) 1640 libdl.so.1_pure_p3_c0_410_551 (shared code) 4 libdl.so.1_pure_p3_c0_410_551 (private data) 9576 libinternal_stubs.so.1 (shared code) 324 libinternal_stubs.so.1 (private data) ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: pure_ibis3_log2 X-Sun-Charset: us-ascii X-Sun-Content-Lines: 81 **** Purify instrumented _pureibs3 (pid 6346 at Mon Mar 8 15:02:57 1999) * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. * For contact information type: "purify -help" * For TTY output, use the option "-windows=no" * Command-line: _pureibs3 series.ibs * Options settings: -purify \ -purify-home=/net/engage/usr2/CM/pure/purify-4.1-solaris2 * Purify licensed to ADS SOFTWARE INC * Purify checking enabled. **** Purify instrumented _pureibs3 (pid 6346) **** Current file descriptors in use: 5 FIU: file descriptor 0: FIU: file descriptor 1: FIU: file descriptor 2: FIU: file descriptor 26: FIU: file descriptor 27: **** Purify instrumented _pureibs3 (pid 6346) **** Purify: Searching for all memory leaks... Memory leaked: 32 bytes (100%); potentially leaked: 0 bytes (0%) MLK: 12 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] CMN_malloc [cmn.c:345] CMN_ArgParsePlus [cmn.c:647] s_parseVds [smos.c:265] SMOS_ReceiveLine [smos.c:138] MDL_ReceiveLine [mdl.c:889] * Block of 4 bytes (3 times); last block at 0x107848 MLK: 12 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] CMN_malloc [cmn.c:345] CMN_ArgParsePlus [cmn.c:687] s_parseVds [smos.c:265] SMOS_ReceiveLine [smos.c:138] MDL_ReceiveLine [mdl.c:889] * Block of 4 bytes (3 times); last block at 0x107ec0 MLK: 8 bytes leaked in 2 blocks * This memory was allocated from: malloc [rtlib.o] CMN_malloc [cmn.c:345] DRVSH_New [drvsh.c:92] MDL_ReceiveLine [mdl.c:713] s_sendLineVer3 [parse.c:817] PARSE [parse.c:416] * Block of 4 bytes (2 times); last block at 0x107b00 Purify Heap Analysis (combining suppressed and unsuppressed blocks) Blocks Bytes Leaked 8 32 Potentially Leaked 0 0 In-Use 0 0 ---------------------------------------- Total Allocated 8 32 **** Purify instrumented _pureibs3 (pid 6346) **** * Program exited with status code 0. * 0 access errors, 0 total occurrences. * 32 bytes leaked. * 0 bytes potentially leaked. * Basic memory usage (including Purify overhead): 806204 code 111276 data/bss 49152 heap (peak use) 4416 stack * Shared library memory usage (including Purify overhead): 135729 libm.so.1_pure_p3_c0_410_551 (shared code) 5872 libm.so.1_pure_p3_c0_410_551 (private data) 804233 libc.so.1_pure_p3_c0_410_551 (shared code) 34892 libc.so.1_pure_p3_c0_410_551 (private data) 1640 libdl.so.1_pure_p3_c0_410_551 (shared code) 4 libdl.so.1_pure_p3_c0_410_551 (private data) 9576 libinternal_stubs.so.1 (shared code) 324 libinternal_stubs.so.1 (private data) From owner-ibis Mon Mar 8 15:38:47 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 PAA07834 for ; Mon, 8 Mar 1999 15:38:47 -0800 (PST) From: nikolai@avanticorp.com Received: (from uucp@localhost) by mailhost.avanticorp.com (8.9.3/8.9.3) id PAA14953; Mon, 8 Mar 1999 15:33:29 -0800 (PST) Received: from avant250.src.avanticorp.com(172.18.10.12) via SMTP by shamu.avanticorp.com, id smtpdAAA0_Wdl4; Mon Mar 8 15:33:24 1999 Received: from iris.src.avanticorp.com (iris.src.avanticorp.com [172.18.5.78]) by avant250.src.avanticorp.com (8.9.3/8.9.3) with ESMTP id PAA14522; Mon, 8 Mar 1999 15:33:22 -0800 (PST) Received: (from nikolai@localhost) by iris.src.avanticorp.com (8.8.8/8.8.8) id PAA06496; Mon, 8 Mar 1999 15:28:33 -0800 (PST) Date: Mon, 8 Mar 1999 15:28:33 -0800 (PST) Message-Id: <199903082328.PAA06496@iris.src.avanticorp.com> To: ibis_users@eda.org Subject: it was my mistake X-Sun-Charset: US-ASCII re: :-) I am upgraiding ibis 2.1 parser in hspice to ibis 3.2 :-) It seems to me ibischk3 has problems which ibischk2 did not :-) have: namely it has memory leaks and :-) UMR (uninitialised memory read). It does not necesserily mean :-) any error, but it would be certaintly better to avoid any UMR, etc. .... etc I think I've sent this to a wrong place, sorry for that Nik From owner-ibis Tue Mar 9 06:41:11 1999 Received: from tellab5.tellabs.com (tellab5.tellabs.com [138.111.243.28]) by server.eda.org (8.8.5/8.8.3) with SMTP id GAA10487 for ; Tue, 9 Mar 1999 06:41:09 -0800 (PST) Received: from sund151.tellabs.com by tellab5.tellabs.com with smtp (Smail3.1.29.1 #4) id m10KNbA-003BXjC; Tue, 9 Mar 99 08:35 CST Received: from sund151 by sund151.tellabs.com (SMI-8.6/1.9) id IAA03257; Tue, 9 Mar 1999 08:35:01 -0600 Sender: laplan@tellabs.com Message-ID: <36E53195.47C4@tellabs.com> Date: Tue, 09 Mar 1999 08:35:01 -0600 From: Sandra Laplanche X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ibis-users@eda.org CC: laplan@tellabs.com Subject: How to model a bidirectional trisate device with the input grounded. Content-Type: multipart/mixed; boundary="------------404E71479D4" This is a multi-part message in MIME format. --------------404E71479D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To whom it may concern: My question is how to create an .s2i file for a bidirectional tristate device connected like this. The input (IN) is connected to GND within the chip, the CIN is directed into the chip and is not accessible to me. The OUT is the output pin and it is the only one that is accessible to me. The OEN line is the output enable which is also internal to the chip hence not accessible and it is active low. Hence, the OEN is the only signal that can cause a transition at the output pin. I need also need the .s2i file to generate an rising and falling curve. I have attached the hspice file. /| CIN____/ |____ \ | | \| | | |\ | IN ____| \_____|_____ OUT | | / ---- |/o -- | | | OEN Pleae reply to laplan@tellabs.com --------------404E71479D4 Content-Type: text/plain; charset=us-ascii; name="fsel.sp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fsel.sp" * Subcircuit pc3b05 PAD I OEN CIN *.SUBCKT pc3b05 PAD I OEN CIN .LIB '/home/tellabf/vlsitool/vlsi_tech_libraries/hspice_vcmn4/vcmn4.lib' TY .INCLUDE '/home/tellabf/vlsitool/vlsi_tech_libraries/hspice_vcmn4/vcmn4.inc' M1 U15_U12_U6_drain U15_oenb VDD VDD P L=.40U + W=12.00U M2 U15_oenb OEN VDD VDD P L=.40U W=12.00U M3 U15_U12_U6_drain U15_oenb VSS VSS N L=.40U W=9.60U M4 U15_U12_U7_drain U15_oenb U15_U12_U6_drain VSS N L=.40U + W=9.60U M5 U15_bulkdriver VDD U15_U12_U7_drain VSS N L=.40U + W=9.60U M6 U15_bulkdriver U15_U12_U6_drain U15_U12_U10_sour VSS N + L=.40U W=9.60U M7 U15_U12_U10_sour U26_padinv U15_oenb VSS N L=.40U + W=9.60U M8 U15_oenb OEN VSS VSS N L=.40U W=9.60U M9 U15_n_gate I VSS VSS N L=.40U W=19.20U M10 U15_p_gate U15_oenb U15_n_gate VSS N L=.40U W=19.20U M11 U15_p_gate I VDD VDD P L=.40U W=24.00U M12 U15_n_gate OEN U15_p_gate VDD P L=.40U W=24.00U M13 U15_n_gate OEN VSS VSS N L=.40U W=9.60U M14 U15_p_gate U15_oenb VDD VDD P L=.40U W=12.00U M15 U18_pad5vtol VDD PAD VSS N L=1.00U W=49.95U M16 U18_floatbulk U15_bulkdriver VDD U18_floatbulk P L=.50U + W=40.00U M17 U15_bulkdriver VDD PAD U18_floatbulk P L=.50U + W=10.00U M18 U16_pfb VDD PAD U18_floatbulk P L=.50U W=10.00U M19 U17_nbw VSS VSS VSS N L=.40U W=48.00U M20 U17_nfb U18_pad5vtol U17_nbw VSS N L=.40U W=48.00U M21 U17_nfb VSS VDD VDD P L=.40U W=6.00U M22 U26_padinv U18_pad5vtol VDD VDD P L=.40U W=24.00U M23 U18_pad5vtol U26_padinv VDD VDD P L=.50U W=.90U M24 CIN U26_padinv VDD VDD P L=.40U W=36.00U M25 U26_padinv U18_pad5vtol VSS VSS N L=.40U W=9.60U M26 CIN U26_padinv VSS VSS N L=.40U W=19.20U M27 U16_pfb PAD U16_M72$5_source U18_floatbulk P L=.50U + W=10.00U M28 U16_pfb PAD U16_M72$4_source U18_floatbulk P L=.50U + W=10.00U M29 U16_pfb PAD U16_M72$3_source U18_floatbulk P L=.50U + W=10.00U M30 U16_pfb PAD U16_M72$2_source U18_floatbulk P L=.50U + W=10.00U M31 U16_pfb PAD U16_M72$1_source U18_floatbulk P L=.50U + W=10.00U M32 U16_pfb PAD U16_M72$0_source U18_floatbulk P L=.50U + W=10.00U M33 U16_M72$5_source VDD VDD U18_floatbulk P L=.50U + W=10.00U M34 U16_M72$4_source VDD VDD U18_floatbulk P L=.50U + W=10.00U M35 U16_M72$3_source VDD VDD U18_floatbulk P L=.50U + W=10.00U M36 U16_M72$2_source VDD VDD U18_floatbulk P L=.50U + W=10.00U M37 U16_M72$1_source VDD VDD U18_floatbulk P L=.50U + W=10.00U M38 U16_M72$0_source VDD VDD U18_floatbulk P L=.50U + W=10.00U M39 U16_U1_drain U15_oenb VSS VSS N L=.40U W=9.60U M40 U16_pfb VDD U16_U1_drain VSS N L=.40U W=9.60U M41 PAD U17_nfb U19_M62$5_source VSS N L=.50U W=54.00U M42 PAD U17_nfb U19_M62$4_source VSS N L=.50U W=54.00U M43 PAD U17_nfb U19_M62$3_source VSS N L=.50U W=54.00U M44 PAD U17_nfb U19_M62$2_source VSS N L=.50U W=54.00U M45 PAD U17_nfb U19_M62$1_source VSS N L=.50U W=54.00U M46 PAD U17_nfb U19_M62$0_source VSS N L=.50U W=54.00U M47 U19_M62$5_source U15_n_gate VSS VSS N L=.50U + W=54.00U M48 U19_M62$4_source U15_n_gate VSS VSS N L=.50U + W=54.00U M49 U19_M62$3_source U15_n_gate VSS VSS N L=.50U + W=54.00U M50 U19_M62$2_source U15_n_gate VSS VSS N L=.50U + W=54.00U M51 U19_M62$1_source U15_n_gate VSS VSS N L=.50U + W=54.00U M52 U19_M62$0_source U15_n_gate VSS VSS N L=.50U + W=54.00U M53 U21_M61$11_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M54 U21_M61$10_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M55 U21_M61$9_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M56 U21_M61$8_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M57 U21_M61$7_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M58 U21_M61$6_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M59 U21_M61$5_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M60 U21_M61$4_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M61 U21_M61$3_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M62 U21_M61$2_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M63 U21_M61$1_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M64 U21_M61$0_drain U15_p_gate VDD U18_floatbulk P L=.50U + W=66.80U M65 PAD U16_pfb U21_M61$11_drain U18_floatbulk P L=.50U + W=66.80U M66 PAD U16_pfb U21_M61$10_drain U18_floatbulk P L=.50U + W=66.80U M67 PAD U16_pfb U21_M61$9_drain U18_floatbulk P L=.50U + W=66.80U M68 PAD U16_pfb U21_M61$8_drain U18_floatbulk P L=.50U + W=66.80U M69 PAD U16_pfb U21_M61$7_drain U18_floatbulk P L=.50U + W=66.80U M70 PAD U16_pfb U21_M61$6_drain U18_floatbulk P L=.50U + W=66.80U M71 PAD U16_pfb U21_M61$5_drain U18_floatbulk P L=.50U + W=66.80U M72 PAD U16_pfb U21_M61$4_drain U18_floatbulk P L=.50U + W=66.80U M73 PAD U16_pfb U21_M61$3_drain U18_floatbulk P L=.50U + W=66.80U M74 PAD U16_pfb U21_M61$2_drain U18_floatbulk P L=.50U + W=66.80U M75 PAD U16_pfb U21_M61$1_drain U18_floatbulk P L=.50U + W=66.80U M76 PAD U16_pfb U21_M61$0_drain U18_floatbulk P L=.50U + W=66.80U M79 U25_MNUN3$1_drai U25_R1_r1 VSS VSS N L=.50U + W=54.00U M80 U25_MNUN3$0_drai U25_R1_r1 VSS VSS N L=.50U + W=54.00U M81 PAD U25_R2_r2 U25_MNUN3$1_drai VSS N L=.50U + W=54.00U M82 PAD U25_R2_r2 U25_MNUN3$0_drai VSS N L=.50U + W=54.00U R77 U25_R1_r1 VSS 1.2000K $[NW] R78 VDD U25_R2_r2 1.2000K $[NW] .END --------------404E71479D4-- From owner-ibis Wed Mar 10 20:52:45 1999 Received: from hotmail.com (law-f63.hotmail.com [209.185.131.126]) by server.eda.org (8.8.5/8.8.3) with SMTP id UAA17031 for ; Wed, 10 Mar 1999 20:52:44 -0800 (PST) Received: (qmail 29850 invoked by uid 65534); 11 Mar 1999 04:46:55 -0000 Message-ID: <19990311044655.29849.qmail@hotmail.com> Received: from 158.140.3.201 by www.hotmail.com with HTTP; Wed, 10 Mar 1999 20:46:54 PST X-Originating-IP: [158.140.3.201] From: "SHRIPAD RAJ" To: ibis-users@eda.org Subject: Getting min max waveforms Date: Wed, 10 Mar 1999 20:46:54 PST Mime-Version: 1.0 Content-type: text/plain IBIS gurus, While generating min and max V-T tables in an IBIS model, is it necessary to change the level and edge rate of the stimulus? Thanks Shripad Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Thu Mar 11 09:05:31 1999 Received: from mta3.snfc21.pbi.net (mta3.snfc21.pbi.net [206.13.28.141]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA18875 for ; Thu, 11 Mar 1999 09:05:30 -0800 (PST) From: jonp@mta1.snfc21.pbi.net Received: from postoffice.pacbell.net (ppp-209-79-182-119.vntrcs.pacbell.net) by mta3.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0F8F00ECEWK8IS@mta3.snfc21.pbi.net> for ibis-users@eda.org; Thu, 11 Mar 1999 09:00:10 -0800 (PST) Date: Thu, 11 Mar 1999 10:59:38 -0800 Subject: Re: Getting min max waveforms To: SHRIPAD RAJ Cc: ibis-users@eda.org Reply-to: jonp@pacbell.net Message-id: <36E81299.4A3DA470@postoffice.pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <19990311044655.29849.qmail@hotmail.com> My thoughts: The level of the stimulus should (at least for CMOS) be 0 to VCC and vary with VCC. If the VT models are going to be accurate, then you should be simulating enough of the output driver that the edge rate should be a secondary effect (ie. if you are close to the internal edge rate of the part then the output answer should not be affected). This is all assuming that you are generating the VT curves from a SPICE or other analog simulation. SHRIPAD RAJ wrote: > IBIS gurus, > > While generating min and max V-T tables in an IBIS model, is it > necessary to change the level and edge rate of the stimulus? > > Thanks > > Shripad > Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Thu Mar 11 15:29:40 1999 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA19816 for ; Thu, 11 Mar 1999 15:29:39 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA17460 for ; Thu, 11 Mar 1999 18:23:28 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id SAA110726 for ; Thu, 11 Mar 1999 18:23:01 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256731.008071F0 ; Thu, 11 Mar 1999 18:22:57 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <85256731.00807009.00@D51MTA10.pok.ibm.com> Date: Thu, 11 Mar 1999 17:23:01 -0600 Subject: accuracy BIRD Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline The IBIS Accuracy Subcommittee has been considering submitting a new BIRD that would allow for a wider variety of golden waveforms to be included in an IBIS datasheet (model). Right now these new golden waveforms would correspond to the additional test loads described in section 3 of the IBIS Accuracy Specification, but we will certainly be adding more test loads to the list as we examine different kinds of I/O buffers and their associated electrical behavior. At the 2/26 IBIS Users Group conference call, Bob Ross suggested we run this by the IBIS reflector to solicit your input, so here it is. The two main questions are: 1) Is it necessary to describe the test loads in a machine-readable fashion, similar to the distributed package model and EBD options already present in IBIS? Or should we opt for the more simple approach of adding a waveform with comments describing the test load? 2) How does one distinguish between a golden waveform (w/ package) and a regular old VT table (w/o package) in IBIS? For those of you who were not at the DesignCon99 Summit, the IBIS Accuracy Subcommittee presented a two-stage approach to documenting the correlation results of an IBIS datasheet. Both stages involve embedding a golden waveform, derived from SPICE, into the IBIS datasheet. The semiconductor vendor can correlate the lab data to these golden waveforms and report the correlation results in the "accuracy trailer," a comment section appended to the IBIS datasheet. Using these same golden waveforms, the user can correlate behavioral simulations and take up any significant discrepancies with the simulator vendor. Question 1 above refers to automating the second step of the correlation process. Of course, the user can always capture the test load manually using the simulator's schematic capture tool. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Thu Mar 11 18:49:14 1999 Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA20207 for ; Thu, 11 Mar 1999 18:49:13 -0800 (PST) Received: from uucp1.uu.net by relay7.UU.NET with SMTP (peer crosschecked as: uucp1.uu.net [192.48.96.81]) id QQggdu18342; Thu, 11 Mar 1999 21:43:46 -0500 (EST) Received: from qdt.UUCP by uucp1.uu.net with UUCP/RMAIL ; Thu, 11 Mar 1999 21:43:45 -0500 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA22288; Thu, 11 Mar 99 18:43:04 PST Received: from chris by qdt.com (4.1/SMI-4.1) id AA27729; Thu, 11 Mar 99 18:42:39 PST Message-Id: <019801be6c31$714ea790$97c2b58b@chris.camarillo.viewlogic.com> From: "Chris Rokusek" To: , Subject: Re: accuracy BIRD Date: Thu, 11 Mar 1999 18:38:42 -0800 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 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Greg, Golden Waveforms are a great idea! >1) Is it necessary to describe the test loads in a machine-readable >fashion, similar to the distributed package model and EBD options already >present in IBIS? Or should we opt for the more simple approach of adding a >waveform with comments describing the test load? A "machine readable" format is prefered in order to facilitate automated validation. You mention using SPICE as the waveform creator so are transmission lines and package info really needed? If you're going to standardize the golden waveform loads, I suggest: 1) No Transmission lines (we're not testing the accuracy of T-Line modeling or T-line extraction parameters are we?). 2) No package parasitics (or they are spelled out explicity within the waveform). 3) A Shunt R to the Positive Rail, the Negative Rail and halfway in between. R should be near the impedence of the Transmission line the driver expects to see. 4) A Shunt C=50pF may prove informative also. >2) How does one distinguish between a golden waveform (w/ package) and a >regular old VT table (w/o package) in IBIS? I claim that a regular old VT table **IS** a golden waveform. It doesn't seem appropriate to place waveforms that use a particular package "within the [Model] block" using IBIS since a particular [Model] block may be used in with different packages. The [Model] block is meant to represent the output stage w/o (independent of) the package parasitics. If waveforms with particular package parameters are generated then they would have to be spelled out in some parseable format at the location of the waveform. Otherwise, there is the danger that someone will edit the package information at the top of the .ibs file and not re-generate the waveforms. Regards, Chris Rokusek Viewlogic Systems From owner-ibis Fri Mar 12 15:06:32 1999 Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA23565 for ; Fri, 12 Mar 1999 15:06:31 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp7.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA36666 for ; Fri, 12 Mar 1999 18:00:34 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id SAA86112 for ; Fri, 12 Mar 1999 18:00:39 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256732.007E653B ; Fri, 12 Mar 1999 18:00:34 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <85256732.007E63ED.00@D51MTA10.pok.ibm.com> Date: Fri, 12 Mar 1999 17:00:39 -0600 Subject: Re: accuracy BIRD Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Fred and Chris, Thanks for taking the time to provide some input. Yes, Fred, what we had in mind was additional VT tables that contain waveforms you would measure at the pin of a DUT, including the package. We have defined some new test loads in section 3 of the IBIS Accuracy Spec, and we would like to describe these test loads as well. Chris, the Accuracy Subcommittee felt it was important to define some more complex loads. We added the open-ended transmission line and the transmission line + receiver loads to facility checking of reflection coefficients and clamp diodes. I think it is necessary to have waveforms that include the package because the package is there when you make the measurements to do the correlation. But we don't need to describe the package since it's already a part of the IBIS datasheet. On the question of "golden waveforms" vs. "regular old VT tables," Stephen Peters mentioned that there is a difference between the two. Golden waveforms have the package while regular old VT tables do not. Is there any syntactical construct within IBIS to differentiate between the two? Care to embellish here, Stephen? Thanks all. Greg gedlund@us.ibm.com wrote: > > The IBIS Accuracy Subcommittee has been considering submitting a new BIRD > that would allow for a wider variety of golden waveforms to be included in > an IBIS datasheet (model). Right now these new golden waveforms would > correspond to the additional test loads described in section 3 of the IBIS > Accuracy Specification, but we will certainly be adding more test loads to > the list as we examine different kinds of I/O buffers and their associated > electrical behavior. At the 2/26 IBIS Users Group conference call, Bob > Ross suggested we run this by the IBIS reflector to solicit your input, so > here it is. The two main questions are: > > 1) Is it necessary to describe the test loads in a machine-readable > fashion, similar to the distributed package model and EBD options already > present in IBIS? Or should we opt for the more simple approach of adding a > waveform with comments describing the test load? I presume you mean another v/t curve in text fashion and the load description along with which package parasitics you are using. IBIS allows up to 100 v/t curves so the bird may be only to add parasitic package information. > > 2) How does one distinguish between a golden waveform (w/ package) and a > regular old VT table (w/o package) in IBIS? This presumably is where you may need an additional key work in the v/t data. Not so hard to do. > > For those of you who were not at the DesignCon99 Summit, the IBIS Accuracy > Subcommittee presented a two-stage approach to documenting the correlation > results of an IBIS datasheet. Both stages involve embedding a golden > waveform, derived from SPICE, into the IBIS datasheet. The semiconductor > vendor can correlate the lab data to these golden waveforms and report the > correlation results in the "accuracy trailer," a comment section appended > to the IBIS datasheet. Using these same golden waveforms, the user can > correlate behavioral simulations and take up any significant discrepancies > with the simulator vendor. Question 1 above refers to automating the > second step of the correlation process. Of course, the user can always > capture the test load manually using the simulator's schematic capture > tool. > > Greg Edlund > Advisory Engineer, Critical Net Analysis > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com Greg, Golden Waveforms are a great idea! >1) Is it necessary to describe the test loads in a machine-readable >fashion, similar to the distributed package model and EBD options already >present in IBIS? Or should we opt for the more simple approach of adding a >waveform with comments describing the test load? A "machine readable" format is prefered in order to facilitate automated validation. You mention using SPICE as the waveform creator so are transmission lines and package info really needed? If you're going to standardize the golden waveform loads, I suggest: 1) No Transmission lines (we're not testing the accuracy of T-Line modeling or T-line extraction parameters are we?). 2) No package parasitics (or they are spelled out explicity within the waveform). 3) A Shunt R to the Positive Rail, the Negative Rail and halfway in between. R should be near the impedence of the Transmission line the driver expects to see. 4) A Shunt C=50pF may prove informative also. >2) How does one distinguish between a golden waveform (w/ package) and a >regular old VT table (w/o package) in IBIS? I claim that a regular old VT table **IS** a golden waveform. It doesn't seem appropriate to place waveforms that use a particular package "within the [Model] block" using IBIS since a particular [Model] block may be used in with different packages. The [Model] block is meant to represent the output stage w/o (independent of) the package parasitics. If waveforms with particular package parameters are generated then they would have to be spelled out in some parseable format at the location of the waveform. Otherwise, there is the danger that someone will edit the package information at the top of the .ibs file and not re-generate the waveforms. Regards, Chris Rokusek Viewlogic Systems From owner-ibis Fri Mar 12 16:06:43 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 QAA23681 for ; Fri, 12 Mar 1999 16:06:43 -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 QAA24887; Fri, 12 Mar 1999 16:00:33 -0800 (PST) Message-Id: <199903130000.QAA24887@jasper.cisco.com> Date: Fri, 12 Mar 1999 16:00:33 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: accuracy BIRD To: ibis-users@vhdl.org, gedlund@us.ibm.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: o4tQztzvGFSVpElS7jEGIg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Hi, Since the V/T tables allow keywords such as C_dut, R_dut, L_dut, doesn't that imply that it DOES use the package numbers. I am a bit confused about Stephen's statement below regarding old VT tables.. Syed. Cisco Systems, Inc > > On the question of "golden waveforms" vs. "regular old VT tables," Stephen > Peters mentioned that there is a difference between the two. Golden > waveforms have the package while regular old VT tables do not. Is there > any syntactical construct within IBIS to differentiate between the two? > Care to embellish here, Stephen? > > Thanks all. > > Greg > > > From owner-ibis Fri Mar 12 20:00:24 1999 Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by server.eda.org (8.8.5/8.8.3) with ESMTP id UAA24110 for ; Fri, 12 Mar 1999 20:00:24 -0800 (PST) From: jonp@pacbell.net Received: from postoffice.pacbell.net (ppp-209-79-182-253.vntrcs.pacbell.net) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0F8I00221LJGUX@mta1.snfc21.pbi.net> for ibis-users@vhdl.org; Fri, 12 Mar 1999 19:54:56 -0800 (PST) Date: Fri, 12 Mar 1999 21:54:22 -0800 Subject: Re: accuracy BIRD To: gedlund@us.ibm.com Cc: ibis-users@vhdl.org Reply-to: jonp@pacbell.net Message-id: <36E9FD8E.E0ADE5BC@postoffice.pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en]C-PBI-NC404 (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <85256732.007E63ED.00@D51MTA10.pok.ibm.com> Actually, I feel that any waveforms that completely describe the test conditions are valid QA applicable "Golden" Waveforms. The important thing is being able to test the simulation back to the original IBIS data. Thus, even the model generation VT curves do supply a certain valuable form of test and QA criterion. Of course, Any additional waveforms with more complex packaging add additional test and sanity. see, I agreed with everyone. jon gedlund@us.ibm.com wrote: > Hi Fred and Chris, > > Thanks for taking the time to provide some input. > > Yes, Fred, what we had in mind was additional VT tables that contain > waveforms you would measure at the pin of a DUT, including the package. We > have defined some new test loads in section 3 of the IBIS Accuracy Spec, > and we would like to describe these test loads as well. > > Chris, the Accuracy Subcommittee felt it was important to define some more > complex loads. We added the open-ended transmission line and the > transmission line + receiver loads to facility checking of reflection > coefficients and clamp diodes. I think it is necessary to have waveforms > that include the package because the package is there when you make the > measurements to do the correlation. But we don't need to describe the > package since it's already a part of the IBIS datasheet. > > On the question of "golden waveforms" vs. "regular old VT tables," Stephen > Peters mentioned that there is a difference between the two. Golden > waveforms have the package while regular old VT tables do not. Is there > any syntactical construct within IBIS to differentiate between the two? > Care to embellish here, Stephen? > > Thanks all. > > Greg > > gedlund@us.ibm.com wrote: > > > > The IBIS Accuracy Subcommittee has been considering submitting a new BIRD > > that would allow for a wider variety of golden waveforms to be included > in > > an IBIS datasheet (model). Right now these new golden waveforms would > > correspond to the additional test loads described in section 3 of the > IBIS > > Accuracy Specification, but we will certainly be adding more test loads > to > > the list as we examine different kinds of I/O buffers and their > associated > > electrical behavior. At the 2/26 IBIS Users Group conference call, Bob > > Ross suggested we run this by the IBIS reflector to solicit your input, > so > > here it is. The two main questions are: > > > > 1) Is it necessary to describe the test loads in a machine-readable > > fashion, similar to the distributed package model and EBD options already > > present in IBIS? Or should we opt for the more simple approach of adding > a > > waveform with comments describing the test load? > > I presume you mean another v/t curve in text fashion and the load > description along > with which package parasitics you are using. IBIS allows up to 100 v/t > curves so the > bird may be only to add parasitic package information. > > > > 2) How does one distinguish between a golden waveform (w/ package) and a > > regular old VT table (w/o package) in IBIS? > > This presumably is where you may need an additional key work in the v/t > data. Not > so hard to do. > > > > For those of you who were not at the DesignCon99 Summit, the IBIS > Accuracy > > Subcommittee presented a two-stage approach to documenting the > correlation > > results of an IBIS datasheet. Both stages involve embedding a golden > > waveform, derived from SPICE, into the IBIS datasheet. The semiconductor > > vendor can correlate the lab data to these golden waveforms and report > the > > correlation results in the "accuracy trailer," a comment section appended > > to the IBIS datasheet. Using these same golden waveforms, the user can > > correlate behavioral simulations and take up any significant > discrepancies > > with the simulator vendor. Question 1 above refers to automating the > > second step of the correlation process. Of course, the user can always > > capture the test load manually using the simulator's schematic capture > > tool. > > > > Greg Edlund > > Advisory Engineer, Critical Net Analysis > > IBM > > 3650 Hwy. 52 N, Dept. HDC > > Rochester, MN 55901 > > gedlund@us.ibm.com > > -- > Fred Balistreri > fred@apsimtech.com > > http://www.apsimtech.com > > Greg, > > Golden Waveforms are a great idea! > > >1) Is it necessary to describe the test loads in a machine-readable > >fashion, similar to the distributed package model and EBD options already > >present in IBIS? Or should we opt for the more simple approach of adding > a > >waveform with comments describing the test load? > > A "machine readable" format is prefered in order to facilitate automated > validation. > > You mention using SPICE as the waveform creator so are transmission lines > and package info really needed? > > If you're going to standardize the golden waveform loads, I suggest: > > 1) No Transmission lines (we're not testing the accuracy of T-Line > modeling or > T-line extraction parameters are we?). > > 2) No package parasitics (or they are spelled out explicity within the > waveform). > > 3) A Shunt R to the Positive Rail, the Negative Rail and halfway in > between. R should be > near the impedence of the Transmission line the driver expects to see. > > 4) A Shunt C=50pF may prove informative also. > > >2) How does one distinguish between a golden waveform (w/ package) and a > >regular old VT table (w/o package) in IBIS? > > I claim that a regular old VT table **IS** a golden waveform. > > It doesn't seem appropriate to place waveforms that use a particular > package > "within the [Model] block" using IBIS since a particular [Model] block may > be used in with different packages. The [Model] block is meant to > represent > the output stage w/o (independent of) the package parasitics. > > If waveforms with particular package parameters are generated then they > would have to be spelled out in some parseable format at the location of > the > waveform. Otherwise, there is the danger that someone will edit the > package > information at the top of the .ibs file and not re-generate the waveforms. > > Regards, > > Chris Rokusek > Viewlogic Systems From owner-ibis Mon Mar 15 09:59:55 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 JAA00672 for ; Mon, 15 Mar 1999 09:59:55 -0800 (PST) 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 RAA15299; Mon, 15 Mar 1999 17:54:33 GMT 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 JAA05500; Mon, 15 Mar 1999 09:54:33 -0800 (PST) Received: from ichips.intel.com (loopback.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 JAA04023; Mon, 15 Mar 1999 09:54:32 -0800 (PST) Message-Id: <199903151754.JAA04023@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: Syed Huq cc: ibis-users@vhdl.org, gedlund@us.ibm.com Subject: Re: accuracy BIRD In-reply-to: Your message of "Fri, 12 Mar 1999 16:00:33 PST." <199903130000.QAA24887@jasper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Mar 1999 09:54:07 -0800 From: Stephen Peters Hello Syed, Greg: Sorry for the delayed response -- I was out of the office back week and am just now getting back to my mail. To elaborate: I was trying to make a distinction between at V/T table that is created by an output driving a pure, non-reactive impedance, and a V/T table created with the output driving a more complex load. The *former* V/T table contains the data the simulator needs/uses when building the output model. Specifically, it describes how the pullup and pulldown transistor turn on/off, and does not -- indeed, should not -- contain any extra time constants due to reactive elements. In the latter case (complex, reactive impedences) the inclusion of these waveforms is a check. Given the model that was build with the first V/T tables, the question is can the simulator produce the waveform of the second case. Hope this helps clarify things. Regards, Stephen Peters Intel Corp. > Hi, > > Since the V/T tables allow keywords such as C_dut, R_dut, L_dut, doesn't > that imply that it DOES use the package numbers. I am a bit confused about > Stephen's statement below regarding old VT tables.. > > Syed. > Cisco Systems, Inc > > > > > On the question of "golden waveforms" vs. "regular old VT tables," Stephen > > Peters mentioned that there is a difference between the two. Golden > > waveforms have the package while regular old VT tables do not. Is there > > any syntactical construct within IBIS to differentiate between the two? > > Care to embellish here, Stephen? > > > > Thanks all. > > > > Greg > > > > > > From owner-ibis Mon Mar 15 10:15:04 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 KAA00727 for ; Mon, 15 Mar 1999 10:15:03 -0800 (PST) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id KAA17535 for ; Mon, 15 Mar 1999 10:09:42 -0800 (PST) Received: from zip.Cadence.COM(158.140.103.36) by mailgate.cadence.com via smap (mjr-v1.2) id xma921521381.017519; Mon, 15 Mar 99 10:09:41 -0800 Received: from cadence.com (d158140105210 [158.140.105.210]) by zip.Cadence.COM (8.7.3/8.7.3) with ESMTP id NAA01045 for ; Mon, 15 Mar 1999 13:09:36 -0500 (EST) Message-ID: <36ED4CA5.9B6E39C4@cadence.com> Date: Mon, 15 Mar 1999 13:08:37 -0500 From: Ken Willis Organization: Cadence Design Systems X-Mailer: Mozilla 4.07 [en] (WinNT; U) MIME-Version: 1.0 To: ibis-users@vhdl.org Subject: job posting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cadence is looking for a software developer at the Chelmsford, MA campus, to work on board and package level high speed interconnect design software. We are looking for familiarity with SPICE and high speed design issues. The open position is focused on software for creating, manipulating, and simulating SI models that use a combination of SPICE and IBIS-style behavioral model constructs, so the ability to develop models is important. Qualifications: - BSEE or MSEE - familiarity with Unix and Microsoft Windows NT - 3+ years of software development experience in C/C++ - experience developing SPICE or behavioral signal integrity models Some travel is required. An engineer that is strong in both signal integrity issues and team software development would be ideal. Please contact me at: Ken Willis Manager, High Speed Interconnect Design R&D Cadence Design Systems Chelmsford, MA 01824 kwillis "at" cadence "dot" com From owner-ibis Mon Mar 15 10:23:42 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 KAA00746 for ; Mon, 15 Mar 1999 10:23:42 -0800 (PST) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id KAA21693 for ; Mon, 15 Mar 1999 10:18:21 -0800 (PST) Received: from zip.Cadence.COM(158.140.103.36) by mailgate.cadence.com via smap (mjr-v1.2) id xma921521899.021664; Mon, 15 Mar 99 10:18:19 -0800 Received: from cadence.com (d158140105210 [158.140.105.210]) by zip.Cadence.COM (8.7.3/8.7.3) with ESMTP id NAA01620 for ; Mon, 15 Mar 1999 13:18:17 -0500 (EST) Message-ID: <36ED4EAE.54A65FE0@cadence.com> Date: Mon, 15 Mar 1999 13:17:18 -0500 From: Ken Willis Organization: Cadence Design Systems X-Mailer: Mozilla 4.07 [en] (WinNT; U) MIME-Version: 1.0 To: ibis-users@vhdl.org Subject: Re: job posting References: <36ED4CA5.9B6E39C4@cadence.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Whoops! I posted this to the reflector I was NOT going to post to. Sorry about that. Ken Ken Willis wrote: > > Cadence is looking for a software developer at the Chelmsford, MA > campus, to work on board and package level high speed interconnect > design software. We are looking for familiarity with SPICE and high > speed design issues. The open position is focused on software for > creating, manipulating, and simulating SI models that use a combination > of SPICE and IBIS-style behavioral model constructs, so the ability > to develop models is important. > > Qualifications: > - BSEE or MSEE > - familiarity with Unix and Microsoft Windows NT > - 3+ years of software development experience in C/C++ > - experience developing SPICE or behavioral signal integrity models > > Some travel is required. An engineer that is strong in both signal > integrity issues and team software development would be ideal. Please > contact me at: > > Ken Willis > Manager, High Speed Interconnect Design R&D > Cadence Design Systems > Chelmsford, MA 01824 > kwillis "at" cadence "dot" com From owner-ibis Mon Mar 15 10:31:01 1999 Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA00769 for ; Mon, 15 Mar 1999 10:31:00 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp8.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id NAA70432 for ; Mon, 15 Mar 1999 13:24:48 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id NAA86270 for ; Mon, 15 Mar 1999 13:25:03 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256735.00652747 ; Mon, 15 Mar 1999 13:24:51 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <85256735.006524BE.00@D51MTA10.pok.ibm.com> Date: Mon, 15 Mar 1999 12:24:50 -0600 Subject: Re: accuracy BIRD Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Stephen, Thanks for the insight. This clears up my question, and I believe Syed's, too. Actually, I went back and re-read section 3.2.2 of the Cookbook, and you said it quite well there. The simulator NEEDS the no-load VT tables to generate a realistic stimulus, if you will. The VT tables with a complex load are icing on the cake and useful for verifying simulator results. What the Accuracy Subcommittee is proposing is some new complex loads that involve transmission lines. (And we'll probably come up with more when we start looking at more advanced drivers.) We can use these extra loads to validate both lab results AND simulator results against the "golden waveforms" in the IBIS datasheet - a cool thing. The real question is, should we add some new keywords and/or subparameters to describe these new loads, thereby facilitating automated simulation and correlation, or should we count on comments to describe the load. I like the automated approach myself, but I agree with Bob Ross: let's not make the IBIS Accuracy Spec dependent on which of the two approaches we choose to use. That way we can proceed with getting it approved. Thank you all for your input. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com ---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on 03/15/99 12:06 PM --------------------------- Stephen Peters on 03/15/99 11:54:07 AM To: Syed Huq cc: ibis-users@vhdl.org, Gregory R Edlund/Rochester/IBM Subject: Re: accuracy BIRD Hello Syed, Greg: Sorry for the delayed response -- I was out of the office back week and am just now getting back to my mail. To elaborate: I was trying to make a distinction between at V/T table that is created by an output driving a pure, non-reactive impedance, and a V/T table created with the output driving a more complex load. The *former* V/T table contains the data the simulator needs/uses when building the output model. Specifically, it describes how the pullup and pulldown transistor turn on/off, and does not -- indeed, should not -- contain any extra time constants due to reactive elements. In the latter case (complex, reactive impedences) the inclusion of these waveforms is a check. Given the model that was build with the first V/T tables, the question is can the simulator produce the waveform of the second case. Hope this helps clarify things. Regards, Stephen Peters Intel Corp. > Hi, > > Since the V/T tables allow keywords such as C_dut, R_dut, L_dut, doesn't > that imply that it DOES use the package numbers. I am a bit confused about > Stephen's statement below regarding old VT tables.. > > Syed. > Cisco Systems, Inc > > > > > On the question of "golden waveforms" vs. "regular old VT tables," Stephen > > Peters mentioned that there is a difference between the two. Golden > > waveforms have the package while regular old VT tables do not. Is there > > any syntactical construct within IBIS to differentiate between the two? > > Care to embellish here, Stephen? > > > > Thanks all. > > > > Greg > > > > > > From owner-ibis Mon Mar 15 12:30:46 1999 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA01152 for ; Mon, 15 Mar 1999 12:30:45 -0800 (PST) Received: from uucp2.uu.net by relay2.UU.NET with SMTP (peer crosschecked as: uucp2.uu.net [192.48.96.82]) id QQggrp22747; Mon, 15 Mar 1999 15:25:22 -0500 (EST) Received: from qdt.UUCP by uucp2.uu.net with UUCP/RMAIL ; Mon, 15 Mar 1999 15:25:17 -0500 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA10510; Mon, 15 Mar 99 12:28:06 PST Received: from chris by qdt.com (4.1/SMI-4.1) id AA22201; Mon, 15 Mar 99 12:27:05 PST Message-Id: <02f401be6f21$a910ffa0$97c2b58b@chris.camarillo.viewlogic.com> From: "Chris Rokusek" To: , Subject: Re: accuracy BIRD Date: Mon, 15 Mar 1999 12:23:16 -0800 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 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Greg, I understand why you want to distinguish between the a waveform with and without packaging parasitics. However, there is a another problem that I think the "Golden Waveforms" specification you are coming up with can solve with little impact. The problem is that many model makers do NOT read the cookbook. Often the most important waveforms (w/o the parasitics) are not present. If there is going to yet another document that model makers will refer to when building models, that document may suffer this same fate as the IBIS Cookbook. A model maker may read one document and not the other. If both documents are referring to the construction of VT waveforms, they should probably be rolled into ONE document so that the "publicity" of one is leveraged by the other. It creates one-stop-shopping for the model maker. We want to make it easy for the model maker. Stephen, do you approve/dissaprove of combining the documents? If you must create a seperate document, then I think the "Golden Waveforms" should INCLUDE the specification for waveforms found in the cookbook (w/o parasitics) as the most important waveforms. So the LEVEL I would be w/o parasitics, LEVEL II be with. At a minimum the new spec must make an "imperative reference" to the cookbook for 3.2.2. The bottom line is if a user only reads this new Accuracy specification and not the Cookbook then all is lost because the maker wouldn't include the most important waveforms and your goals would not be attainable (nor would ours). Thanks for your consideration, Chris Rokusek Viewlogic Systems -----Original Message----- From: gedlund@us.ibm.com To: ibis-users@vhdl.org Date: Monday, March 15, 1999 11:39 AM Subject: Re: accuracy BIRD >Stephen, > >Thanks for the insight. This clears up my question, and I believe Syed's, >too. Actually, I went back and re-read section 3.2.2 of the Cookbook, and >you said it quite well there. The simulator NEEDS the no-load VT tables to >generate a realistic stimulus, if you will. The VT tables with a complex >load are icing on the cake and useful for verifying simulator results. > >What the Accuracy Subcommittee is proposing is some new complex loads that >involve transmission lines. (And we'll probably come up with more when we >start looking at more advanced drivers.) We can use these extra loads to >validate both lab results AND simulator results against the "golden >waveforms" in the IBIS datasheet - a cool thing. The real question is, >should we add some new keywords and/or subparameters to describe these new >loads, thereby facilitating automated simulation and correlation, or should >we count on comments to describe the load. I like the automated approach >myself, but I agree with Bob Ross: let's not make the IBIS Accuracy Spec >dependent on which of the two approaches we choose to use. That way we can >proceed with getting it approved. > >Thank you all for your input. > >Greg Edlund >Advisory Engineer, Critical Net Analysis >IBM >3650 Hwy. 52 N, Dept. HDC >Rochester, MN 55901 >gedlund@us.ibm.com > > >---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on >03/15/99 12:06 PM --------------------------- > > >Stephen Peters on 03/15/99 11:54:07 AM > >To: Syed Huq >cc: ibis-users@vhdl.org, Gregory R Edlund/Rochester/IBM >Subject: Re: accuracy BIRD > > > > > > >Hello Syed, Greg: > > Sorry for the delayed response -- I was out of the office back week and >am just now getting back to my mail. To elaborate: I was trying to make >a distinction between at V/T table that is created by an output driving a >pure, non-reactive impedance, and a V/T table created with the output >driving >a more complex load. The *former* V/T table contains the data the >simulator >needs/uses when building the output model. Specifically, it describes how >the pullup and pulldown transistor turn on/off, and does not -- indeed, >should >not -- contain any extra time constants due to reactive elements. In the >latter case (complex, reactive impedences) the inclusion of these waveforms >is a check. Given the model that was build with the first V/T tables, the >question is can the simulator produce the waveform of the second case. > >Hope this helps clarify things. > > Regards, > Stephen Peters > Intel Corp. > > >> Hi, >> >> Since the V/T tables allow keywords such as C_dut, R_dut, L_dut, doesn't >> that imply that it DOES use the package numbers. I am a bit confused >about >> Stephen's statement below regarding old VT tables.. >> >> Syed. >> Cisco Systems, Inc >> >> > >> > On the question of "golden waveforms" vs. "regular old VT tables," >Stephen >> > Peters mentioned that there is a difference between the two. Golden >> > waveforms have the package while regular old VT tables do not. Is >there >> > any syntactical construct within IBIS to differentiate between the two? >> > Care to embellish here, Stephen? >> > >> > Thanks all. >> > >> > Greg >> > >> > >> > > > > > > > From owner-ibis Mon Mar 15 13:09:29 1999 Received: from InterJet.apsimtech.com (apsimtech.com [209.21.21.35]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA01260 for ; Mon, 15 Mar 1999 13:09:27 -0800 (PST) Received: (from daemon@localhost) by InterJet.apsimtech.com (8.8.5/8.8.5) id MAA07290; Mon, 15 Mar 1999 12:36:24 -0800 (PST) Received: from UNKNOWN(192.168.1.103), claiming to be "apsim3" via SMTP by InterJet.apsimtech.com, id smtpd007285; Mon Mar 15 20:36:19 1999 Sender: fred@apsimtech.com Message-ID: <36ED6F25.7B0C@apsimtech.com> Date: Mon, 15 Mar 1999 12:35:49 -0800 From: Fred Balistreri Organization: Apsim X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: gedlund@us.ibm.com CC: ibis-users@vhdl.org Subject: Re: accuracy BIRD References: <85256735.006524BE.00@D51MTA10.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit gedlund@us.ibm.com wrote: > > Stephen, > > Thanks for the insight. This clears up my question, and I believe Syed's, > too. Actually, I went back and re-read section 3.2.2 of the Cookbook, and > you said it quite well there. The simulator NEEDS the no-load VT tables to > generate a realistic stimulus, if you will. The VT tables with a complex > load are icing on the cake and useful for verifying simulator results. > > What the Accuracy Subcommittee is proposing is some new complex loads that > involve transmission lines. (And we'll probably come up with more when we > start looking at more advanced drivers.) We can use these extra loads to > validate both lab results AND simulator results against the "golden > waveforms" in the IBIS datasheet - a cool thing. The real question is, > should we add some new keywords and/or subparameters to describe these new > loads, thereby facilitating automated simulation and correlation, or should > we count on comments to describe the load. I like the automated approach > myself, but I agree with Bob Ross: let's not make the IBIS Accuracy Spec > dependent on which of the two approaches we choose to use. That way we can > proceed with getting it approved. > > Thank you all for your input. > > Greg Edlund > Advisory Engineer, Critical Net Analysis > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > > ---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on > 03/15/99 12:06 PM --------------------------- > > Stephen Peters on 03/15/99 11:54:07 AM > > To: Syed Huq > cc: ibis-users@vhdl.org, Gregory R Edlund/Rochester/IBM > Subject: Re: accuracy BIRD > > Hello Syed, Greg: > > Sorry for the delayed response -- I was out of the office back week and > am just now getting back to my mail. To elaborate: I was trying to make > a distinction between at V/T table that is created by an output driving a > pure, non-reactive impedance, and a V/T table created with the output > driving > a more complex load. The *former* V/T table contains the data the > simulator > needs/uses when building the output model. Specifically, it describes how > the pullup and pulldown transistor turn on/off, and does not -- indeed, > should > not -- contain any extra time constants due to reactive elements. In the > latter case (complex, reactive impedences) the inclusion of these waveforms > is a check. Given the model that was build with the first V/T tables, the > question is can the simulator produce the waveform of the second case. > > Hope this helps clarify things. > > Regards, > Stephen Peters > Intel Corp. > > > Hi, > > > > Since the V/T tables allow keywords such as C_dut, R_dut, L_dut, doesn't > > that imply that it DOES use the package numbers. I am a bit confused > about > > Stephen's statement below regarding old VT tables.. > > > > Syed. > > Cisco Systems, Inc > > > > > > > > On the question of "golden waveforms" vs. "regular old VT tables," > Stephen > > > Peters mentioned that there is a difference between the two. Golden > > > waveforms have the package while regular old VT tables do not. Is > there > > > any syntactical construct within IBIS to differentiate between the two? > > > Care to embellish here, Stephen? > > > > > > Thanks all. > > > > > > Greg > > > > > > > > > Actually there is always a load on the IBIS models I have seen. The load is typically 50 ohms to gnd or vcc. Because of this the simulation vendors must extrapolate the no load answer. The DC loads are presumably put there to determine turn off and turn on currents. One other comment. The load is always a complex impedance. This is because c_comp is required. Best Regards, -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com From owner-ibis Mon Mar 15 15:23:58 1999 Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA01652 for ; Mon, 15 Mar 1999 15:23:57 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp8.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA26554 for ; Mon, 15 Mar 1999 18:17:45 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id SAA226844 for ; Mon, 15 Mar 1999 18:18:03 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256735.007FFE08 ; Mon, 15 Mar 1999 18:18:00 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <85256735.007FF832.00@D51MTA10.pok.ibm.com> Date: Mon, 15 Mar 1999 17:08:05 -0600 Subject: IBIS Users Group Agenda 3/19/99 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline IBIS Users Group Agenda Date: 3/19/99 Time: 8:00 - 9:55 am PST Phone number: 1-805-240-9673 Pass code: 773000 8:00 CHECK-IN Introduction of new participants Date for next conference call Announcements Corrections to previous meeting's minutes Additions to the agenda 8:15 GENERAL BUSINESS Receive an update from IBIS connector specification group. Discuss need for further face to face IBIS user group meetings. Discuss further project possibilities for the user group. 8:35 EDUCATION Receive update from Ed Sayre. 8:55 IBIS ACCURACY SUBCOMMITTEE Note: The Accuracy Working Group should make decisions and assign work during this meeting. We should strive to conduct actual editing activities off-line for the sake of productivity. IBIS ACCURACY SPECIFICATION 1.2 REVISIONS Greg Edlund will have a first pass at 1.2 available before the next meeting. ACCURACY-RELATED BIRD(S) Discuss reactions from the IBIS community. Decide on direction: 1) write BIRD now WITHOUT machine-readable description of test load 2) write BIRD later WITH machine-readable description of test load In either case, IBIS Accuracy Spec 1.2 could proceed to EIA for approval. EIA APPROVAL Receive update from Bob Haller and Bob Ross. Decide on which version of the spec to bring to EIA for approval. IBIS ACCURACY SPECIFICATION 2.0 DEVELOPMENT Review list of possible topics: 1. VT tables (This is a necessity.) 2. Additional model types, i.e. GTL, ECL, open source, etc. 3. Effect of R_load on simulation accuracy 4. Package modeling and simultaneous switching noise 5. Diode stored charge effects 6. Multi-staged drivers 7. Dynamic clamping Take suggestions and priorities. Proposal from Greg Edlund: Bob Haller, Peter LaFlamme, and Greg Edlund should each run Bob Ross' SPICE deck (from email entitled "IBIS to SPICE Discussion") and understand fully how it works! This will help us understand VT tables. TEST BOARD Receive update from Bob Haller and Greg Edlund. Bob Haller, Greg Edlund, and Peter LaFlamme will compile a list of changes (very limited) should we identify a design resource. Receive update from Milt Schwartz. ACCURACY ACTION ITEMS Review list and add new items. 1. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Edit measurement and correlation sections of the IBIS Accuracy Specification and distribute the new document. 2. Status: CLOSED. Opened: 2/26/99 Owner: Greg Edlund. Write email to the reflector soliciting input on the contents of an accuracy-related BIRD. At issue is whether or not to include a machine-readable description of the test loads described in the IBIS Accuracy Specification. 3. Status: open. Opened: 2/26/99 Owner: Peter LaFlamme. Make VCX16244 SPICE model and IBIS datasheet available on the accuracy web page. 4. Status: CLOSED. Opened: 2/26/99 Owner: Bob Haller, Greg Edlund. Discuss test board changes off-line. 5. Status: open. Opened: 2/26/99 Owner: Milt Schwarz. Get quote for building revision 3 of the test board. 6. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Write test board application note. 7. Status: CLOSED. Opened: 2/26/99 Owner: Greg Edlund. Send out a note to the reflector suggesting possible candidates for accuracy development in 1999. 9:05 EDUCATION Receive update from Ed Sayre. 9:55 SIGN-OFF Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Mon Mar 15 15:33:48 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 PAA01669 for ; Mon, 15 Mar 1999 15:33:45 -0800 (PST) Received: from orsmsx29.jf.intel.com ([192.168.65.29]) 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 XAA00464; Mon, 15 Mar 1999 23:28:16 GMT Message-Id: <199903152328.XAA00464@ganymede.or.intel.com> Received: by ORSMSX29 with Internet Mail Service (5.5.2232.9) id <1CJ2FP7S>; Mon, 15 Mar 1999 15:27:34 -0800 From: "Muranyi, Arpad" To: "\"gedlund@us.ibm.com\" " , "\"Fred Balistreri\" " Cc: "\"ibis-users@vhdl.org\" " Subject: RE: accuracy BIRD Date: Mon, 15 Mar 1999 15:27:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Fred, There is really no such thing as "no load answer". The 50 Ohm resistor was invented because the transmission lines look like a resistor for the time duration while the wave is traveling down the line and back. So the driver really never drives a "no load"... Arpad ============================================================================ = Actually there is always a load on the IBIS models I have seen. The load is typically 50 ohms to gnd or vcc. Because of this the simulation vendors must extrapolate the no load answer. The DC loads are presumably put there to determine turn off and turn on currents. One other comment. The load is always a complex impedance. This is because c_comp is required. Best Regards, -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com From owner-ibis Mon Mar 15 15:42:24 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 PAA01699 for ; Mon, 15 Mar 1999 15:42:23 -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.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id XAA21295; Mon, 15 Mar 1999 23:36:55 GMT Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 15 Mar 1999 15:36:55 -0800 Message-ID: <856592CED9BBD211AC3E00A0C967ED7A2AEBD5@orsmsx51.jf.intel.com> From: "Samaan, Samie" To: "'gedlund@us.ibm.com'" , ibis-users@vhdl.org Subject: unsubscribe Date: Mon, 15 Mar 1999 15:36:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" unsubscribe From owner-ibis Mon Mar 15 16:51:54 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 QAA01878 for ; Mon, 15 Mar 1999 16:51:53 -0800 (PST) From: nikolai@avanticorp.com Received: (from uucp@localhost) by mailhost.avanticorp.com (8.9.3/8.9.3) id QAA23592; Mon, 15 Mar 1999 16:46:28 -0800 (PST) Received: from avant250.src.avanticorp.com(172.18.10.12) via SMTP by shamu.avanticorp.com, id smtpdAAAVTkRY_; Mon Mar 15 16:46:20 1999 Received: from iris.src.avanticorp.com (iris.src.avanticorp.com [172.18.5.78]) by avant250.src.avanticorp.com (8.9.3/8.9.3) with ESMTP id QAA27547; Mon, 15 Mar 1999 16:46:18 -0800 (PST) Received: (from nikolai@localhost) by iris.src.avanticorp.com (8.8.8/8.8.8) id QAA09826; Mon, 15 Mar 1999 16:41:20 -0800 (PST) Date: Mon, 15 Mar 1999 16:41:20 -0800 (PST) Message-Id: <199903160041.QAA09826@iris.src.avanticorp.com> To: ibis-users@vhdl.org Subject: ecl X-Sun-Charset: US-ASCII Hi IbiS Gurus I am wondering if anybody can point me at a site(s) where I can find ibis files with ECL models of all 4 ECL types. If there is an expert in ECL-syntax could you please spend a minute looking at this: this is legal: -------------- |Variable typ min max [Voltage Range] 0.0 0.0 0.0 [Pulldown Reference] 0.0 0.0 0.0 [Power Clamp Reference] 0.0 0.0 0.0 [GND Clamp Reference] -3.3 -3.0 -3.8 this is legal: -------------- |Variable typ min max [Voltage Range] 3.3 3.0 3.8 [Pulldown Reference] 3.3 3.0 3.8 [Power Clamp Reference] 3.3 3.0 3.8 [Gnd Clamp Reference] 0.0 0.0 0.0 howabout this? ------------- |Variable typ min max [Voltage Range] 3.3 3.0 3.8 [Pullup Reference] 3.3 3.0 3.8 [Power Clamp Reference] 3.3 3.0 3.8 [Gnd Clamp Reference] 0.0 0.0 0.0 I changed [Pulldown Reference] -> [Pullup Reference], [Pulldown Reference] is omitted, so it defaults to zero. ibischk3 does not complain, no warnings, no errors what specs say: | When tabulating data for ECL models, the data in the | [Pulldown] table is measured with the output in the 'logic | low' state. In other words, the data in the table represents | the V/I characteristics of the output when the output is at | the most negative of its two logic levels. Likewise, the data | in the [Pullup] table is measured with the output in the | 'logic one' state and represents the V/I characteristics when | the output is at the most positive logic level. Note that in | BOTH of these cases, the data is referenced to the Vcc supply | voltage, using the equation: Vtable = Vcc - Voutput. | It's ambiguous, because we have [Pullup Reference], [Pulldown Reference], [Voltage Range] but not Vcc If my example is legal, there is no use for [Pulldown Reference], and it should be always discarded. If my example is illegal, then specs and parser should be corrected. Any comments? Thanks a lot Nik nikolai@avanticorp.com From owner-ibis Mon Mar 15 23:40:00 1999 Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by server.eda.org (8.8.5/8.8.3) with ESMTP id XAA03787 for ; Mon, 15 Mar 1999 23:39:59 -0800 (PST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.8.7/8.8.7) with ESMTP id IAA01136 for ; Tue, 16 Mar 1999 08:34:05 +0100 (MET) Received: from demchh2msx.icn.siemens.de (root@[132.29.102.62]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA22125 for ; Tue, 16 Mar 1999 08:35:41 +0100 (MET) Received: from oen.siemens.de (pim@h1c1b29.mchh3.oen.siemens.de [132.7.2.136]) by demchh2msx.icn.siemens.de (8.9.1/8.9.1) with ESMTP id IAA03585 for ; Tue, 16 Mar 1999 08:34:32 +0100 (MET) Sender: hans.pichlmaier@icn.siemens.de Message-ID: <36EE0988.7668D7A6@oen.siemens.de> Date: Tue, 16 Mar 1999 08:34:32 +0100 From: Hans Pichlmaier Organization: ET S 23 X-Mailer: Mozilla 4.05 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: ibis-users@vhdl.org Subject: unsubscribe References: <856592CED9BBD211AC3E00A0C967ED7A2AEBD5@orsmsx51.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hans Pichlmaier unsubscribe From owner-ibis Tue Mar 16 08:46:02 1999 Received: from tellab5.tellabs.com (tellab5.tellabs.com [138.111.243.28]) by server.eda.org (8.8.5/8.8.3) with SMTP id IAA05840 for ; Tue, 16 Mar 1999 08:46:00 -0800 (PST) From: laplan@tellabs.com Received: from sund151.tellabs.com by tellab5.tellabs.com with smtp (Smail3.1.29.1 #4) id m10Mwsa-003BZMC; Tue, 16 Mar 99 10:39 CST Received: by sund151.tellabs.com (SMI-8.6/1.9) id KAA22816; Tue, 16 Mar 1999 10:39:35 -0600 Message-Id: <199903161639.KAA22816@sund151.tellabs.com> Subject: Re: How to model a bidirectional trisate device with the input grounded. To: laplan@tellabs.com (Sandra Laplanche) Date: Tue, 16 Mar 1999 10:39:35 -0600 (CST) Cc: ibis-users@eda.org, laplan@tellabs.com In-Reply-To: <36E53195.47C4@tellabs.com> from "Sandra Laplanche" at Mar 9, 99 08:35:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Hi, > > Is anyone looking into my question which is described below? > > > Thanks! > > Sandra > > This is a multi-part message in MIME format. > > --------------404E71479D4 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > To whom it may concern: > > My question is how to create an .s2i file for a bidirectional tristate > device connected like this. The input (IN) is connected to GND within > the chip, the CIN is directed into the chip and is not accessible to me. > The OUT is the output pin and it is the only one that is accessible to > me. The OEN line is the output enable which is also internal to the chip > hence not accessible and it is active low. Hence, the OEN is the only > signal that can cause a transition at the output pin. I need also need > the .s2i file to generate an rising and falling curve. I have attached > the hspice file. > > > > > /| > CIN____/ |____ > \ | | > \| | > | > |\ | > IN ____| \_____|_____ OUT > | | / > ---- |/o > -- | > | > | > OEN > > > > Pleae reply to laplan@tellabs.com > > --------------404E71479D4 > Content-Type: text/plain; charset=us-ascii; name="fsel.sp" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; filename="fsel.sp" > > * Subcircuit pc3b05 PAD I OEN CIN > *.SUBCKT pc3b05 PAD I OEN CIN > > .LIB '/home/tellabf/vlsitool/vlsi_tech_libraries/hspice_vcmn4/vcmn4.lib' TY > .INCLUDE '/home/tellabf/vlsitool/vlsi_tech_libraries/hspice_vcmn4/vcmn4.inc' > > M1 U15_U12_U6_drain U15_oenb VDD VDD P L=.40U > + W=12.00U > M2 U15_oenb OEN VDD VDD P L=.40U W=12.00U > M3 U15_U12_U6_drain U15_oenb VSS VSS N L=.40U W=9.60U > M4 U15_U12_U7_drain U15_oenb U15_U12_U6_drain VSS N L=.40U > + W=9.60U > M5 U15_bulkdriver VDD U15_U12_U7_drain VSS N L=.40U > + W=9.60U > M6 U15_bulkdriver U15_U12_U6_drain U15_U12_U10_sour VSS N > + L=.40U W=9.60U > M7 U15_U12_U10_sour U26_padinv U15_oenb VSS N L=.40U > + W=9.60U > M8 U15_oenb OEN VSS VSS N L=.40U W=9.60U > M9 U15_n_gate I VSS VSS N L=.40U W=19.20U > M10 U15_p_gate U15_oenb U15_n_gate VSS N L=.40U W=19.20U > M11 U15_p_gate I VDD VDD P L=.40U W=24.00U > M12 U15_n_gate OEN U15_p_gate VDD P L=.40U W=24.00U > M13 U15_n_gate OEN VSS VSS N L=.40U W=9.60U > M14 U15_p_gate U15_oenb VDD VDD P L=.40U W=12.00U > M15 U18_pad5vtol VDD PAD VSS N L=1.00U W=49.95U > M16 U18_floatbulk U15_bulkdriver VDD U18_floatbulk P L=.50U > + W=40.00U > M17 U15_bulkdriver VDD PAD U18_floatbulk P L=.50U > + W=10.00U > M18 U16_pfb VDD PAD U18_floatbulk P L=.50U W=10.00U > M19 U17_nbw VSS VSS VSS N L=.40U W=48.00U > M20 U17_nfb U18_pad5vtol U17_nbw VSS N L=.40U W=48.00U > M21 U17_nfb VSS VDD VDD P L=.40U W=6.00U > M22 U26_padinv U18_pad5vtol VDD VDD P L=.40U W=24.00U > M23 U18_pad5vtol U26_padinv VDD VDD P L=.50U W=.90U > M24 CIN U26_padinv VDD VDD P L=.40U W=36.00U > M25 U26_padinv U18_pad5vtol VSS VSS N L=.40U W=9.60U > M26 CIN U26_padinv VSS VSS N L=.40U W=19.20U > M27 U16_pfb PAD U16_M72$5_source U18_floatbulk P L=.50U > + W=10.00U > M28 U16_pfb PAD U16_M72$4_source U18_floatbulk P L=.50U > + W=10.00U > M29 U16_pfb PAD U16_M72$3_source U18_floatbulk P L=.50U > + W=10.00U > M30 U16_pfb PAD U16_M72$2_source U18_floatbulk P L=.50U > + W=10.00U > M31 U16_pfb PAD U16_M72$1_source U18_floatbulk P L=.50U > + W=10.00U > M32 U16_pfb PAD U16_M72$0_source U18_floatbulk P L=.50U > + W=10.00U > M33 U16_M72$5_source VDD VDD U18_floatbulk P L=.50U > + W=10.00U > M34 U16_M72$4_source VDD VDD U18_floatbulk P L=.50U > + W=10.00U > M35 U16_M72$3_source VDD VDD U18_floatbulk P L=.50U > + W=10.00U > M36 U16_M72$2_source VDD VDD U18_floatbulk P L=.50U > + W=10.00U > M37 U16_M72$1_source VDD VDD U18_floatbulk P L=.50U > + W=10.00U > M38 U16_M72$0_source VDD VDD U18_floatbulk P L=.50U > + W=10.00U > M39 U16_U1_drain U15_oenb VSS VSS N L=.40U W=9.60U > M40 U16_pfb VDD U16_U1_drain VSS N L=.40U W=9.60U > M41 PAD U17_nfb U19_M62$5_source VSS N L=.50U W=54.00U > M42 PAD U17_nfb U19_M62$4_source VSS N L=.50U W=54.00U > M43 PAD U17_nfb U19_M62$3_source VSS N L=.50U W=54.00U > M44 PAD U17_nfb U19_M62$2_source VSS N L=.50U W=54.00U > M45 PAD U17_nfb U19_M62$1_source VSS N L=.50U W=54.00U > M46 PAD U17_nfb U19_M62$0_source VSS N L=.50U W=54.00U > M47 U19_M62$5_source U15_n_gate VSS VSS N L=.50U > + W=54.00U > M48 U19_M62$4_source U15_n_gate VSS VSS N L=.50U > + W=54.00U > M49 U19_M62$3_source U15_n_gate VSS VSS N L=.50U > + W=54.00U > M50 U19_M62$2_source U15_n_gate VSS VSS N L=.50U > + W=54.00U > M51 U19_M62$1_source U15_n_gate VSS VSS N L=.50U > + W=54.00U > M52 U19_M62$0_source U15_n_gate VSS VSS N L=.50U > + W=54.00U > M53 U21_M61$11_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M54 U21_M61$10_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M55 U21_M61$9_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M56 U21_M61$8_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M57 U21_M61$7_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M58 U21_M61$6_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M59 U21_M61$5_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M60 U21_M61$4_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M61 U21_M61$3_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M62 U21_M61$2_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M63 U21_M61$1_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M64 U21_M61$0_drain U15_p_gate VDD U18_floatbulk P L=.50U > + W=66.80U > M65 PAD U16_pfb U21_M61$11_drain U18_floatbulk P L=.50U > + W=66.80U > M66 PAD U16_pfb U21_M61$10_drain U18_floatbulk P L=.50U > + W=66.80U > M67 PAD U16_pfb U21_M61$9_drain U18_floatbulk P L=.50U > + W=66.80U > M68 PAD U16_pfb U21_M61$8_drain U18_floatbulk P L=.50U > + W=66.80U > M69 PAD U16_pfb U21_M61$7_drain U18_floatbulk P L=.50U > + W=66.80U > M70 PAD U16_pfb U21_M61$6_drain U18_floatbulk P L=.50U > + W=66.80U > M71 PAD U16_pfb U21_M61$5_drain U18_floatbulk P L=.50U > + W=66.80U > M72 PAD U16_pfb U21_M61$4_drain U18_floatbulk P L=.50U > + W=66.80U > M73 PAD U16_pfb U21_M61$3_drain U18_floatbulk P L=.50U > + W=66.80U > M74 PAD U16_pfb U21_M61$2_drain U18_floatbulk P L=.50U > + W=66.80U > M75 PAD U16_pfb U21_M61$1_drain U18_floatbulk P L=.50U > + W=66.80U > M76 PAD U16_pfb U21_M61$0_drain U18_floatbulk P L=.50U > + W=66.80U > M79 U25_MNUN3$1_drai U25_R1_r1 VSS VSS N L=.50U > + W=54.00U > M80 U25_MNUN3$0_drai U25_R1_r1 VSS VSS N L=.50U > + W=54.00U > M81 PAD U25_R2_r2 U25_MNUN3$1_drai VSS N L=.50U > + W=54.00U > M82 PAD U25_R2_r2 U25_MNUN3$0_drai VSS N L=.50U > + W=54.00U > R77 U25_R1_r1 VSS 1.2000K $[NW] > R78 VDD U25_R2_r2 1.2000K $[NW] > > .END > > > --------------404E71479D4-- > > From owner-ibis Tue Mar 16 09:06:44 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 JAA05914 for ; Tue, 16 Mar 1999 09:06:43 -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.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA14984 for ; Tue, 16 Mar 1999 17:01:21 GMT Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 16 Mar 1999 09:01:20 -0800 Message-ID: <856592CED9BBD211AC3E00A0C967ED7A2AEBDA@orsmsx51.jf.intel.com> From: "Samaan, Samie" Cc: ibis-users@eda.org Subject: unsubscribe Date: Tue, 16 Mar 1999 09:01:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" unsubscribe From owner-ibis Tue Mar 16 09:41:27 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 JAA06027 for ; Tue, 16 Mar 1999 09:41:26 -0800 (PST) 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 RAA09442; Tue, 16 Mar 1999 17:36:02 GMT 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 JAA20480; Tue, 16 Mar 1999 09:36:01 -0800 (PST) Received: from ichips.intel.com (loopback.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 JAA12133; Tue, 16 Mar 1999 09:36:01 -0800 (PST) Message-Id: <199903161736.JAA12133@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: nikolai@avanticorp.com cc: ibis-users@vhdl.org Subject: Re: ecl In-reply-to: Your message of "Mon, 15 Mar 1999 16:41:20 PST." <199903160041.QAA09826@iris.src.avanticorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Mar 1999 09:36:00 -0800 From: Stephen Peters Hello Nik: Very briefly, the examples below are 'legal' in that they are valid syntax. This is why they pass the parser. The question is -- are they correct? Here is how I would describe traditional (positive supply = 0v) 10K or 100K ECL logic. ECL logic has no active pulldown transistor, and it's logic levels are referenced to the most positive supply. Also, remember that if the [Pullup Reference] keyword is not explicitly used, [Voltage Range] becomes the pullup reference. Therefore, the simplest way to set the references would be*: |Variable typ min max [Voltage Range] 0.0 0.0 0.0 | sets the references for both | logic levles [Power Clamp Reference] 0.0 0.0 0.0 | included assuming the device | has an input clamp to VCC The important thing to note is that you do NOT need a pulldown reference. A [Pulldown Reference] is required only when the devices output has an active pulldowns structure (i.e. can sink current), AND the reference for that pulldown device is something other than 0v (traditional ground). With an open-emitter logic family like ECL, the pulldown simply does not apply. (*Alternatively, you may want to use the [Voltage Range] keyword to document the VEE supply conditions. In this case use the [Pullup Reference] keyword as follows: |Variable typ min max [Voltage Range] -4.5 -4.0 -5.0 | 100k ECL [Pullup Reference] 0.0 0.0 0.0 | overrides [Voltage Range] [Power Clamp Reference] 0.0 0.0 0.0 ) Finally, for completeness, a 3.3v PECL device is shown. |Variable typ min max [Voltage Range] 3.3 3.0 3.6 [Power Clamp Reference] 0.0 0.0 0.0 Again, all that needs to be specified is the most positive logic rail, and both the [Pullup] and [Pulldown] curves are referenced against it. Hope this helps. Regards, Stephen Peers Intel Corp. Nikoli wrote: > > Hi IbiS Gurus > > I am wondering if anybody can point me at a site(s) where I can > find ibis files with ECL models of all 4 ECL types. > > If there is an expert in ECL-syntax could you please spend a minute > looking at this: > > this is legal: > -------------- > |Variable typ min max > [Voltage Range] 0.0 0.0 0.0 > [Pulldown Reference] 0.0 0.0 0.0 > [Power Clamp Reference] 0.0 0.0 0.0 > [GND Clamp Reference] -3.3 -3.0 -3.8 > > > this is legal: > -------------- > |Variable typ min max > [Voltage Range] 3.3 3.0 3.8 > [Pulldown Reference] 3.3 3.0 3.8 > [Power Clamp Reference] 3.3 3.0 3.8 > [Gnd Clamp Reference] 0.0 0.0 0.0 > > > howabout this? > ------------- > |Variable typ min max > [Voltage Range] 3.3 3.0 3.8 > [Pullup Reference] 3.3 3.0 3.8 > [Power Clamp Reference] 3.3 3.0 3.8 > [Gnd Clamp Reference] 0.0 0.0 0.0 > > I changed [Pulldown Reference] -> [Pullup Reference], > [Pulldown Reference] is omitted, so it defaults to zero. > > ibischk3 does not complain, no warnings, no errors > > what specs say: > | When tabulating data for ECL models, the data in the > | [Pulldown] table is measured with the output in the 'logic > | low' state. In other words, the data in the table represents > | the V/I characteristics of the output when the output is at > | the most negative of its two logic levels. Likewise, the data > | in the [Pullup] table is measured with the output in the > | 'logic one' state and represents the V/I characteristics when > | the output is at the most positive logic level. Note that in > | BOTH of these cases, the data is referenced to the Vcc supply > | voltage, using the equation: Vtable = Vcc - Voutput. > | > > It's ambiguous, because we have [Pullup Reference], [Pulldown Reference], [Voltage Range] > but not Vcc > > If my example is legal, there is no use for [Pulldown Reference], and it should be > always discarded. If my example is illegal, then specs and parser should > be corrected. > > Any comments? > > Thanks a lot > > Nik > nikolai@avanticorp.com From owner-ibis Tue Mar 16 11:13:02 1999 Received: from InterJet.apsimtech.com (apsimtech.com [209.21.21.35]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA06436; Tue, 16 Mar 1999 11:13:01 -0800 (PST) Received: (from daemon@localhost) by InterJet.apsimtech.com (8.8.5/8.8.5) id KAA14276; Tue, 16 Mar 1999 10:52:53 -0800 (PST) Received: from stud.apsimtech.com(192.168.1.138), claiming to be "apsimtech.com" via SMTP by InterJet.apsimtech.com, id smtpd014274; Tue Mar 16 18:52:51 1999 Message-ID: <36EEA920.2D1E722@apsimtech.com> Date: Tue, 16 Mar 1999 10:55:28 -0800 From: Mark Nguyen Organization: Applied Simulation Tech. Inc., San Jose, CA X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ibis-info@eda.org CC: ibis-users@eda.org Subject: Automation to be removed.... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit from the IBIS-User reflector mailing list. To IBIS-reflector maintenance person: People are using: ibis-users@eda.org and ibis-users@vhdl.org to unsubscribe. Is this the correct method? I thought the correct email address is ibis-request@eda.org. Best regards, Mark Nguyen http://www.apsimtech.com From owner-ibis Tue Mar 16 11:35:35 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 LAA06512 for ; Tue, 16 Mar 1999 11:35:35 -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 LAA09817; Tue, 16 Mar 1999 11:28:42 -0800 (PST) Message-Id: <199903161928.LAA09817@jasper.cisco.com> Date: Tue, 16 Mar 1999 11:28:42 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: How to model a bidirectional trisate device with the input grounded. To: laplan@tellabs.com Cc: ibis-users@eda.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VQ3Cf7MrgssytZ4vO0pQXw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Hello, You could try the following syntax: (Partial .s2i file) | Spice_node signal model_name R_pin L_pin C_pin |------------------------------------------------------- [Pin] 1 0 GND GND 2 PAD MY_IO Trisate -> IN ENBL IN I input dummy1 ENBL OEN enable dummy2 3 VDD PWR POWER | |------------------------------------------------------ | [model] Tristate [model type] I/O [Polarity] Non-Inverting [Enable] active-low [model file] mymodel.typ mymodel.min mymodel.max [Rising waveform] 50 0 NA NA NA NA NA NA NA [Falling waveform] 50 3.3 NA NA NA NA NA NA NA [Rising waveform] 50 3.3 NA NA NA NA NA NA NA [Falling waveform] 50 0.0 NA NA NA NA NA NA NA [model] dummy1 [nomodel] [model] dummy2 [nomodel] The mymodel.typ,min,max refers to your process corner models. You should also refer to the /doc section of s2ibis2 for detailed description of s2i syntax. Also look under the /examples dir and see ex2 and ex3 for Tri-state buffer modeling. Regards, Syed. Cisco Systems, Inc > X-SMAP-Received-From: outside > From: laplan@tellabs.com > Subject: Re: How to model a bidirectional trisate device with the input grounded. > To: laplan@tellabs.com (Sandra Laplanche) > Date: Tue, 16 Mar 1999 10:39:35 -0600 (CST) > Cc: ibis-users@eda.org, laplan@tellabs.com > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > > > Hi, > > > > Is anyone looking into my question which is described below? > > > > > > Thanks! > > > > Sandra > > > > > > > > > > > > This is a multi-part message in MIME format. > > > > --------------404E71479D4 > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > > > To whom it may concern: > > > > My question is how to create an .s2i file for a bidirectional tristate > > device connected like this. The input (IN) is connected to GND within > > the chip, the CIN is directed into the chip and is not accessible to me. > > The OUT is the output pin and it is the only one that is accessible to > > me. The OEN line is the output enable which is also internal to the chip > > hence not accessible and it is active low. Hence, the OEN is the only > > signal that can cause a transition at the output pin. I need also need > > the .s2i file to generate an rising and falling curve. I have attached > > the hspice file. > > > > > > > > > > /| > > CIN____/ |____ > > \ | | > > \| | > > | > > |\ | > > IN ____| \_____|_____ OUT > > | | / > > ---- |/o > > -- | > > | > > | > > OEN > > > > > > > > Pleae reply to laplan@tellabs.com > > > > --------------404E71479D4 > > Content-Type: text/plain; charset=us-ascii; name="fsel.sp" > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline; filename="fsel.sp" > > > > * Subcircuit pc3b05 PAD I OEN CIN > > *.SUBCKT pc3b05 PAD I OEN CIN > > > > .LIB '/home/tellabf/vlsitool/vlsi_tech_libraries/hspice_vcmn4/vcmn4.lib' TY > > .INCLUDE '/home/tellabf/vlsitool/vlsi_tech_libraries/hspice_vcmn4/vcmn4.inc' > > > > M1 U15_U12_U6_drain U15_oenb VDD VDD P L=.40U > > + W=12.00U > > M2 U15_oenb OEN VDD VDD P L=.40U W=12.00U > > M3 U15_U12_U6_drain U15_oenb VSS VSS N L=.40U W=9.60U > > M4 U15_U12_U7_drain U15_oenb U15_U12_U6_drain VSS N L=.40U > > + W=9.60U > > M5 U15_bulkdriver VDD U15_U12_U7_drain VSS N L=.40U > > + W=9.60U > > M6 U15_bulkdriver U15_U12_U6_drain U15_U12_U10_sour VSS N > > + L=.40U W=9.60U > > M7 U15_U12_U10_sour U26_padinv U15_oenb VSS N L=.40U > > + W=9.60U > > M8 U15_oenb OEN VSS VSS N L=.40U W=9.60U > > M9 U15_n_gate I VSS VSS N L=.40U W=19.20U > > M10 U15_p_gate U15_oenb U15_n_gate VSS N L=.40U W=19.20U > > M11 U15_p_gate I VDD VDD P L=.40U W=24.00U > > M12 U15_n_gate OEN U15_p_gate VDD P L=.40U W=24.00U > > M13 U15_n_gate OEN VSS VSS N L=.40U W=9.60U > > M14 U15_p_gate U15_oenb VDD VDD P L=.40U W=12.00U > > M15 U18_pad5vtol VDD PAD VSS N L=1.00U W=49.95U > > M16 U18_floatbulk U15_bulkdriver VDD U18_floatbulk P L=.50U > > + W=40.00U > > M17 U15_bulkdriver VDD PAD U18_floatbulk P L=.50U > > + W=10.00U > > M18 U16_pfb VDD PAD U18_floatbulk P L=.50U W=10.00U > > M19 U17_nbw VSS VSS VSS N L=.40U W=48.00U > > M20 U17_nfb U18_pad5vtol U17_nbw VSS N L=.40U W=48.00U > > M21 U17_nfb VSS VDD VDD P L=.40U W=6.00U > > M22 U26_padinv U18_pad5vtol VDD VDD P L=.40U W=24.00U > > M23 U18_pad5vtol U26_padinv VDD VDD P L=.50U W=.90U > > M24 CIN U26_padinv VDD VDD P L=.40U W=36.00U > > M25 U26_padinv U18_pad5vtol VSS VSS N L=.40U W=9.60U > > M26 CIN U26_padinv VSS VSS N L=.40U W=19.20U > > M27 U16_pfb PAD U16_M72$5_source U18_floatbulk P L=.50U > > + W=10.00U > > M28 U16_pfb PAD U16_M72$4_source U18_floatbulk P L=.50U > > + W=10.00U > > M29 U16_pfb PAD U16_M72$3_source U18_floatbulk P L=.50U > > + W=10.00U > > M30 U16_pfb PAD U16_M72$2_source U18_floatbulk P L=.50U > > + W=10.00U > > M31 U16_pfb PAD U16_M72$1_source U18_floatbulk P L=.50U > > + W=10.00U > > M32 U16_pfb PAD U16_M72$0_source U18_floatbulk P L=.50U > > + W=10.00U > > M33 U16_M72$5_source VDD VDD U18_floatbulk P L=.50U > > + W=10.00U > > M34 U16_M72$4_source VDD VDD U18_floatbulk P L=.50U > > + W=10.00U > > M35 U16_M72$3_source VDD VDD U18_floatbulk P L=.50U > > + W=10.00U > > M36 U16_M72$2_source VDD VDD U18_floatbulk P L=.50U > > + W=10.00U > > M37 U16_M72$1_source VDD VDD U18_floatbulk P L=.50U > > + W=10.00U > > M38 U16_M72$0_source VDD VDD U18_floatbulk P L=.50U > > + W=10.00U > > M39 U16_U1_drain U15_oenb VSS VSS N L=.40U W=9.60U > > M40 U16_pfb VDD U16_U1_drain VSS N L=.40U W=9.60U > > M41 PAD U17_nfb U19_M62$5_source VSS N L=.50U W=54.00U > > M42 PAD U17_nfb U19_M62$4_source VSS N L=.50U W=54.00U > > M43 PAD U17_nfb U19_M62$3_source VSS N L=.50U W=54.00U > > M44 PAD U17_nfb U19_M62$2_source VSS N L=.50U W=54.00U > > M45 PAD U17_nfb U19_M62$1_source VSS N L=.50U W=54.00U > > M46 PAD U17_nfb U19_M62$0_source VSS N L=.50U W=54.00U > > M47 U19_M62$5_source U15_n_gate VSS VSS N L=.50U > > + W=54.00U > > M48 U19_M62$4_source U15_n_gate VSS VSS N L=.50U > > + W=54.00U > > M49 U19_M62$3_source U15_n_gate VSS VSS N L=.50U > > + W=54.00U > > M50 U19_M62$2_source U15_n_gate VSS VSS N L=.50U > > + W=54.00U > > M51 U19_M62$1_source U15_n_gate VSS VSS N L=.50U > > + W=54.00U > > M52 U19_M62$0_source U15_n_gate VSS VSS N L=.50U > > + W=54.00U > > M53 U21_M61$11_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M54 U21_M61$10_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M55 U21_M61$9_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M56 U21_M61$8_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M57 U21_M61$7_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M58 U21_M61$6_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M59 U21_M61$5_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M60 U21_M61$4_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M61 U21_M61$3_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M62 U21_M61$2_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M63 U21_M61$1_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M64 U21_M61$0_drain U15_p_gate VDD U18_floatbulk P L=.50U > > + W=66.80U > > M65 PAD U16_pfb U21_M61$11_drain U18_floatbulk P L=.50U > > + W=66.80U > > M66 PAD U16_pfb U21_M61$10_drain U18_floatbulk P L=.50U > > + W=66.80U > > M67 PAD U16_pfb U21_M61$9_drain U18_floatbulk P L=.50U > > + W=66.80U > > M68 PAD U16_pfb U21_M61$8_drain U18_floatbulk P L=.50U > > + W=66.80U > > M69 PAD U16_pfb U21_M61$7_drain U18_floatbulk P L=.50U > > + W=66.80U > > M70 PAD U16_pfb U21_M61$6_drain U18_floatbulk P L=.50U > > + W=66.80U > > M71 PAD U16_pfb U21_M61$5_drain U18_floatbulk P L=.50U > > + W=66.80U > > M72 PAD U16_pfb U21_M61$4_drain U18_floatbulk P L=.50U > > + W=66.80U > > M73 PAD U16_pfb U21_M61$3_drain U18_floatbulk P L=.50U > > + W=66.80U > > M74 PAD U16_pfb U21_M61$2_drain U18_floatbulk P L=.50U > > + W=66.80U > > M75 PAD U16_pfb U21_M61$1_drain U18_floatbulk P L=.50U > > + W=66.80U > > M76 PAD U16_pfb U21_M61$0_drain U18_floatbulk P L=.50U > > + W=66.80U > > M79 U25_MNUN3$1_drai U25_R1_r1 VSS VSS N L=.50U > > + W=54.00U > > M80 U25_MNUN3$0_drai U25_R1_r1 VSS VSS N L=.50U > > + W=54.00U > > M81 PAD U25_R2_r2 U25_MNUN3$1_drai VSS N L=.50U > > + W=54.00U > > M82 PAD U25_R2_r2 U25_MNUN3$0_drai VSS N L=.50U > > + W=54.00U > > R77 U25_R1_r1 VSS 1.2000K $[NW] > > R78 VDD U25_R2_r2 1.2000K $[NW] > > > > .END > > > > > > --------------404E71479D4-- > > > > > From owner-ibis Tue Mar 16 12:44:20 1999 Received: from jake.hyperlynx.com (root@mail.hyperlynx.com [209.20.148.70]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA06682; Tue, 16 Mar 1999 12:44:16 -0800 (PST) Received: from tensor ([192.168.148.75]) by jake.hyperlynx.com (8.8.8/8.8.8) with SMTP id MAA24905; Tue, 16 Mar 1999 12:45:28 -0800 Message-Id: <3.0.5.32.19990316123849.00b52970@hyperwall> X-Sender: mbflora@hyperwall X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 16 Mar 1999 12:38:49 -0100 To: Mark Nguyen , ibis-info@eda.org From: Matthew Flora Subject: Re: Automation to be removed.... Cc: ibis-users@eda.org In-Reply-To: <36EEA920.2D1E722@apsimtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear Mark Nguyen, >To IBIS-reflector maintenance person: > >People are using: ibis-users@eda.org and ibis-users@vhdl.org >to unsubscribe. Is this the correct method? > >I thought the correct email address is ibis-request@eda.org. You are correct. Unfortunately, messages sent out over the reflectors don't have instructions for unsubscribing appended to them. It would be nice ... Regards, Matthew Flora IBIS Open Forum Secretary (425) 869-2320 PH (425) 881-1008 FAX mbflora@hyperlynx.com HyperLynx, 17641 NE 67th Court, Redmond, WA 98052 USA From owner-ibis Wed Mar 17 05:52:36 1999 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA09929 for ; Wed, 17 Mar 1999 05:52:35 -0800 (PST) Received: from dlep3.itg.ti.com ([157.170.188.62]) by gatekeep.ti.com (8.8.8) with ESMTP id HAA18081 for ; Wed, 17 Mar 1999 07:46:43 -0600 (CST) Received: from paced.sc.ti.com (nba0129621-asic0209.sc.ti.com [156.117.248.129]) by dlep3.itg.ti.com (8.8.8/8.8.8) with SMTP id HAA10511 for ; Wed, 17 Mar 1999 07:46:43 -0600 (CST) Reply-To: From: "Mike Lamson" To: Subject: IBIS Package Model Date: Wed, 17 Mar 1999 07:46:27 -0600 Message-ID: <000301be707c$8ece6860$81f8759c@paced.sc.ti.com> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Does anyone know how to represent RLC in IBIS for a ground plane with multiport nodes? The issues is the capacitance. The inductance and resistance can be described between any two ports of the plane but how to represent the capacitance in IBIS is a mystery. If the total plane capacitance is used, it gets repeated for each port which over estimates it in the model. Thanks, Mike Lamson m-lamson@ti.com From owner-ibis Wed Mar 17 15:47:15 1999 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA11984 for ; Wed, 17 Mar 1999 15:47:14 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA83082 for ; Wed, 17 Mar 1999 18:41:21 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id SAA273676 for ; Wed, 17 Mar 1999 18:41:17 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256737.00819A86 ; Wed, 17 Mar 1999 18:35:37 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <85256737.00819A35.00@D51MTA10.pok.ibm.com> Date: Wed, 17 Mar 1999 17:35:40 -0600 Subject: IBIS Package Model Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Mike, Can you elaborate a little more? It sounds like you're trying to model the ground plane in a package as a non-ideal return path. Usually we make the assumption in transmission line analysis that the return terminals are connected to ideal ground, but this doesn't work when you're modeling power rail collapse on an IC due to package inductance. It sounds like you want a package model with two ports for each signal conductor and more than two ports for the ground conductor. Is this the case? If so, you're talking about a 3-D package model since a package model based on a 2-D cross section would only have two ports for a non-ideal ground. The quick answer is that IBIS can do coupled lumped package models or uncoupled distributed package models, but not coupled distributed package models. In my experience, I've used multiple lumped segments to describe a package; these were based on multiple unique 2-D cross sections with non-ideal grounds. However, I've never seen anyone derive a coupled distributed package model from a 3-D field analysis. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com ---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on 03/17/99 05:21 PM --------------------------- "Mike Lamson" on 03/17/99 07:46:27 AM Please respond to m-lamson@ti.com To: ibis-users@vhdl.org cc: (bcc: Gregory R Edlund/Rochester/IBM) Subject: IBIS Package Model Does anyone know how to represent RLC in IBIS for a ground plane with multiport nodes? The issues is the capacitance. The inductance and resistance can be described between any two ports of the plane but how to represent the capacitance in IBIS is a mystery. If the total plane capacitance is used, it gets repeated for each port which over estimates it in the model. Thanks, Mike Lamson m-lamson@ti.com From owner-ibis Wed Mar 17 15:49:27 1999 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA11989 for ; Wed, 17 Mar 1999 15:49:27 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA22998 for ; Wed, 17 Mar 1999 18:43:34 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id SAA51464 for ; Wed, 17 Mar 1999 18:43:31 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256737.0081D3F0 ; Wed, 17 Mar 1999 18:38:04 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <85256737.0081D26A.00@D51MTA10.pok.ibm.com> Date: Wed, 17 Mar 1999 17:38:06 -0600 Subject: IBIS Accuracy Specification 2.0 development Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline The IBIS Accuracy Subcommittee is planning for version 2.0 of the IBIS Accuracy Specification. It is our intention to bring the IBIS Accuracy Specification up-to-speed with IBIS in the next 1-2 years. However, we will be working with limited resources and will need to prioritize. Here is a list of possible topics to include in version 2.0: 1. VT tables (This is a necessity.) 2. Additional model types, i.e. GTL, ECL, open source, etc. 3. Effect of R_load on simulation accuracy 4. Package modeling and simultaneous switching noise 5. Diode stored charge effects 6. Multi-staged drivers 7. Dynamic clamping I generated this list from browsing through IBIS 3.2 and reading "Practical Issues with IBIS Models," by Bob Ross. If you can think of things to add to this list or have any thoughts on how to prioritize it, please email the users reflector. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Wed Mar 17 18:09:37 1999 Received: from InterJet.apsimtech.com (apsimtech.com [209.21.21.35]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA12260 for ; Wed, 17 Mar 1999 18:09:35 -0800 (PST) Received: (from daemon@localhost) by InterJet.apsimtech.com (8.8.5/8.8.5) id RAA24268; Wed, 17 Mar 1999 17:16:40 -0800 (PST) Received: from UNKNOWN(192.168.1.103), claiming to be "apsim3" via SMTP by InterJet.apsimtech.com, id smtpd024266; Thu Mar 18 01:16:37 1999 Sender: fred@apsimtech.com Message-ID: <36F053D1.2ADD@apsimtech.com> Date: Wed, 17 Mar 1999 17:16:01 -0800 From: Fred Balistreri Organization: Apsim X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: gedlund@us.ibm.com CC: ibis-users@vhdl.org Subject: Re: IBIS Package Model References: <85256737.00819A35.00@D51MTA10.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit gedlund@us.ibm.com wrote: > > Mike, > > Can you elaborate a little more? It sounds like you're trying to model the > ground plane in a package as a non-ideal return path. Usually we make the > assumption in transmission line analysis that the return terminals are > connected to ideal ground, but this doesn't work when you're modeling power > rail collapse on an IC due to package inductance. It sounds like you want > a package model with two ports for each signal conductor and more than two > ports for the ground conductor. Is this the case? If so, you're talking > about a 3-D package model since a package model based on a 2-D cross > section would only have two ports for a non-ideal ground. > > The quick answer is that IBIS can do coupled lumped package models or > uncoupled distributed package models, but not coupled distributed package > models. In my experience, I've used multiple lumped segments to describe a > package; these were based on multiple unique 2-D cross sections with > non-ideal grounds. However, I've never seen anyone derive a coupled > distributed package model from a 3-D field analysis. > > Greg Edlund > Advisory Engineer, Critical Net Analysis > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > > ---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on > 03/17/99 05:21 PM --------------------------- > > "Mike Lamson" on 03/17/99 07:46:27 AM > > Please respond to m-lamson@ti.com > > To: ibis-users@vhdl.org > cc: (bcc: Gregory R Edlund/Rochester/IBM) > Subject: IBIS Package Model > > Does anyone know how to represent RLC in IBIS for a ground plane with > multiport nodes? The issues is the capacitance. The inductance and > resistance can be described between any two ports of the plane but how to > represent the capacitance in IBIS is a mystery. If the total plane > capacitance is used, it gets repeated for each port which over estimates it > in the model. > > Thanks, > > Mike Lamson > m-lamson@ti.com Full wave solvers will give you S parameters. These can be interpreted into SPICE Laplace transfer functions that retain the frequency effects. Therefore its possible to have the behavior of the system modeled in a simulator accurately. Other approaches involve FDTD and similiar methods. However Mike's question pertains to IBIS. In that regard Greg's answer seems correct. Lumped RLC circuits from 3d analysis can become large and hard to handle by time domain simulation. Best Regards, -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com From owner-ibis Thu Mar 18 06:33:14 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 GAA14797 for ; Thu, 18 Mar 1999 06:33:13 -0800 (PST) Received: from dlep3.itg.ti.com ([157.170.188.62]) by jester.ti.com (8.8.8) with ESMTP id IAA07587 for ; Thu, 18 Mar 1999 08:26:59 -0600 (CST) Received: from paced.sc.ti.com (nba0129621-asic0209.sc.ti.com [156.117.248.129]) by dlep3.itg.ti.com (8.8.8/8.8.8) with SMTP id IAA14342 for ; Thu, 18 Mar 1999 08:27:20 -0600 (CST) Reply-To: From: "Mike Lamson" To: Subject: FW: IBIS Package Model Date: Thu, 18 Mar 1999 08:27:01 -0600 Message-ID: <000001be714b$64560f00$81f8759c@paced.sc.ti.com> 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 Sorry for not providing enough info. Yes, it is 3D model with signals, a power plane, and a ground plane. A certain set of loads on the chip bring current in the power plane and return it on the ground plane (ignore the signals for this case). I can represent a number of input and output ports on the ground and power planes with RL elements (both self and mutual). There is a capacitance between the planes. If I try to represent these paths in IBIS, the meaning of the capacitance becomes an issue (I can't use the total plane capacitance for each path). This still may not be clear but someone once said that if you can phrase a good question, you already know the answer. Regards, Mike Lamson -----Original Message----- From: Fred Balistreri [mailto:owner-ibis@server.eda.org] Sent: Wednesday, March 17, 1999 9:48 PM To: gedlund@us.ibm.com Cc: ibis-users@vhdl.org Subject: Re: IBIS Package Model -MSG M#= 973754 FR=MS1P TO=MIKL SENT=03/17/99 09:48 PM TYPE=N R#=067 ST=C DIV=0003 CC=06960 BY=MS1P AT=03/17/99 09:48 PM To: gedlund@us.ibm.com Copy: ibis-users@vhdl.org From: Fred Balistreri Subj: Re: IBIS Package Model gedlund@us.ibm.com wrote: > > Mike, > > Can you elaborate a little more? It sounds like you're trying to model the > ground plane in a package as a non-ideal return path. Usually we make the > assumption in transmission line analysis that the return terminals are > connected to ideal ground, but this doesn't work when you're modeling power > rail collapse on an IC due to package inductance. It sounds like you want > a package model with two ports for each signal conductor and more than two > ports for the ground conductor. Is this the case? If so, you're talking > about a 3-D package model since a package model based on a 2-D cross > section would only have two ports for a non-ideal ground. > > The quick answer is that IBIS can do coupled lumped package models or > uncoupled distributed package models, but not coupled distributed package > models. In my experience, I've used multiple lumped segments to describe a > package; these were based on multiple unique 2-D cross sections with > non-ideal grounds. However, I've never seen anyone derive a coupled > distributed package model from a 3-D field analysis. > > Greg Edlund > Advisory Engineer, Critical Net Analysis > IBM > 3650 Hwy. 52 N, Dept. HDC > Rochester, MN 55901 > gedlund@us.ibm.com > > ---------------------- Forwarded by Gregory R Edlund/Rochester/IBM on > 03/17/99 05:21 PM --------------------------- > > "Mike Lamson" on 03/17/99 07:46:27 AM > > Please respond to m-lamson@ti.com > > To: ibis-users@vhdl.org > cc: (bcc: Gregory R Edlund/Rochester/IBM) > Subject: IBIS Package Model > > Does anyone know how to represent RLC in IBIS for a ground plane with > multiport nodes? The issues is the capacitance. The inductance and > resistance can be described between any two ports of the plane but how to > represent the capacitance in IBIS is a mystery. If the total plane > capacitance is used, it gets repeated for each port which over estimates it > in the model. > > Thanks, > > Mike Lamson > m-lamson@ti.com Full wave solvers will give you S parameters. These can be interpreted into SPICE Laplace transfer functions that retain the frequency effects. Therefore its possible to have the behavior of the system modeled in a simulator accurately. Other approaches involve FDTD and similiar methods. However Mike's question pertains to IBIS. In that regard Greg's answer seems correct. Lumped RLC circuits from 3d analysis can become large and hard to handle by time domain simulation. Best Regards, -- Fred Balistreri fred@apsimtech.com http://www.apsimtech.com From owner-ibis Fri Mar 19 05:30:02 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 FAA19401 for ; Fri, 19 Mar 1999 05:30:02 -0800 (PST) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id FAA21056 for ; Fri, 19 Mar 1999 05:24:40 -0800 (PST) Received: from zip.Cadence.COM(158.140.103.36) by mailgate.cadence.com via smap (mjr-v1.2) id xma921849878.021054; Fri, 19 Mar 99 05:24:38 -0800 Received: from cadence.com (d158140105210 [158.140.105.210]) by zip.Cadence.COM (8.7.3/8.7.3) with ESMTP id IAA04720 for ; Fri, 19 Mar 1999 08:24:37 -0500 (EST) Message-ID: <36F24FD0.F46AF071@cadence.com> Date: Fri, 19 Mar 1999 08:23:28 -0500 From: Mike LaBonte Organization: Cadence Design Systems X-Mailer: Mozilla 4.07 [en] (WinNT; U) MIME-Version: 1.0 To: IBIS Users Subject: duplicate models in a Driver Schedule Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It is not clear to me whether or not model names that appear in the [Driver Schedule] section of an IBIS file must be unique. In the IBIS spec example, a different model name is used on each line. But the description text does not require that they must be unique. So my question is, could a [Driver Schedule] section legally use the same model name twice? Something like this: [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA MODEL_OUT 0.5ns NA 0.5ns NA In other words, what if both stages turn on/off at different times, but are otherwise identical? Mike LaBonte P.S. Here is the ver_3.0.ibs example, for reference: [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high | Bus-hold stage M_O_DRAIN3 NA 1.0n NA 0.5n | high (high-Z) to low low to high (high-Z) From owner-ibis Fri Mar 19 13:36:51 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA21056 for ; Fri, 19 Mar 1999 13:36:50 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA14125; Fri, 19 Mar 1999 13:30:56 -0800 (PST) Received: from bob by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA12936; Fri, 19 Mar 1999 13:30:56 -0800 (PST) From: bob_ross@mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA17508; Fri, 19 Mar 99 13:30:55 PST Date: Fri, 19 Mar 99 13:30:55 PST Message-Id: <9903192130.AA17508@bob> To: ibis-users@eda.org, mikelabonte@cadence.com Subject: Re: duplicate models in a Driver Schedule Mike: It is permitted to use the same model several times under [Driver Schedule], as you have shown. There is no statement in the Specification that prohibits this. Also, ibischk3 permits this syntax. Bob Ross Mentor Graphics > Date: Fri, 19 Mar 1999 08:23:28 -0500 > From: Mike LaBonte > To: IBIS Users > Subject: duplicate models in a Driver Schedule > It is not clear to me whether or not model names that appear in the > [Driver Schedule] section of an IBIS file must be unique. In the IBIS > spec example, a different model name is used on each line. But the > description text does not require that they must be unique. > So my question is, could a [Driver Schedule] section legally use > the same model name twice? Something like this: > [Driver Schedule] > | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly > MODEL_OUT 0.0ns NA 0.0ns NA > MODEL_OUT 0.5ns NA 0.5ns NA > In other words, what if both stages turn on/off at different times, > but are otherwise identical? > Mike LaBonte > P.S. Here is the ver_3.0.ibs example, for reference: > [Driver Schedule] > | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly > MODEL_OUT 0.0ns NA 0.0ns NA > | > | Examples of added multi-staged transitions > M_O_SOURCE1 0.5ns NA 0.5ns NA > | low (high-Z) to high high to low (high-Z) > M_O_SOURCE2 0.5n 1.5n NA NA > | low to high to low low (high-Z) > M_O_DRAIN1 1.0n NA 1.5n NA > | low to high (high-Z) high (high-Z) to low > M_O_DRAIN2 NA NA 1.5n 2.0n > | high (high-Z) high to low to high > | Bus-hold stage > M_O_DRAIN3 NA 1.0n NA 0.5n > | high (high-Z) to low low to high (high-Z) From owner-ibis Thu Mar 25 11:59:39 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 LAA10894 for ; Thu, 25 Mar 1999 11:59:39 -0800 (PST) From: nikolai@avanticorp.com Received: (from uucp@localhost) by mailhost.avanticorp.com (8.9.3/8.9.3) id LAA07413; Thu, 25 Mar 1999 11:54:06 -0800 (PST) Received: from avant250.src.avanticorp.com(172.18.10.12) via SMTP by shamu.avanticorp.com, id smtpdAAA0NEgZe; Thu Mar 25 11:53:59 1999 Received: from iris.src.avanticorp.com (iris.src.avanticorp.com [172.18.5.78]) by avant250.src.avanticorp.com (8.9.3/8.9.3) with ESMTP id LAA19735; Thu, 25 Mar 1999 11:53:58 -0800 (PST) Received: (from nikolai@localhost) by iris.src.avanticorp.com (8.8.8/8.8.8) id LAA01341; Thu, 25 Mar 1999 11:48:45 -0800 (PST) Date: Thu, 25 Mar 1999 11:48:45 -0800 (PST) Message-Id: <199903251948.LAA01341@iris.src.avanticorp.com> To: ibis-users@eda.org Subject: For ecl- buffers experts X-Sun-Charset: US-ASCII To ecl- buffers experts: For ecl buffers, can we have an ibis file with 2 rising and 2 falling waveforms (RWF/FWF) ? I would answer, why not? However, IBIS specs contains Sec 9, "Notes on data derivation methods", which specify how to derive rising/falling waveforms. This part specifies, that for ecl buffers, the termination voltage, Vterm = Vcc - 2V. The only one termination voltage suggests only one waveform. Unlike ECL part, CMOS buffers part recommends 2 termination voltages to use: Vdd and Vss, hence we can derive 2 FWFs and 2 RWFs. Any comments, suggestions Thanks a lot ------------------------------- Nikolai Bannov Avant! Corporation 46871 Bayside Parkway Fremont, CA 94538 tel: 510-413-8634 fax: 510-413-8080 email: nikolai@avanticorp.com ------------------------------- From owner-ibis Thu Mar 25 14:36:41 1999 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA11433 for ; Thu, 25 Mar 1999 14:36:40 -0800 (PST) From: gedlund@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id RAA23148 for ; Thu, 25 Mar 1999 17:30:01 -0500 Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id RAA166150 for ; Thu, 25 Mar 1999 17:30:42 -0500 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 8525673F.007BA858 ; Thu, 25 Mar 1999 17:30:40 -0500 X-Lotus-FromDomain: IBMUS To: ibis-users@vhdl.org Message-ID: <8525673F.007BA72A.00@D51MTA10.pok.ibm.com> Date: Thu, 25 Mar 1999 16:30:33 -0600 Subject: IBIS Users Group Minutes 3/19/99 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline IBIS Users Group Minutes 3/19/99 Participants on 3/19/99 Greg Edlund, IBM Bob Haller, Compaq Bob Ross, Mentor Grpahics Fabrizio Zanella, EMC Dima Smolyansky, TDA Systems Next conference call: Date: 4/9/99 Time: 8:00 - 9:55 am PST Phone number: to be announced Pass code: to be announced CHECK-IN There were no announcements, corrections to previous meeting's minutes, or additions to the agenda. GENERAL BUSINESS Kellee Crisafulli provided an update from the Connector Group via email and Fabrizio Zanella provided an update during the call. The Connector Group has met since DesignCon99. They are currently discussing the topic of frequency-dependent losses and are currently leaning toward not including them in the first version of the connector BIRD. This question needs to be settled before issuing a BIRD. Ed Sayre requested a discussion of the need for future face-to-face Users Group meetings. Bob Haller said he thought the last meeting was well-attended and productive. He goes on record as being in favor of a face-to-face meeting. Bob Haller will call Ed Sayre to set up the next meeting. PART I: IBIS ACCURACY SUBCOMMITTEE IBIS ACCURACY SPECIFICATION 1.2 REVISIONS Greg Edlund will distribute version 1.2 of the spec in MS Word format during the week of March 29. IBIS Accuracy participants should review version 1.2 and come prepared to discuss the changes during the next Users Group conference call. The group discussed what the version number should be. Bob Haller reminded us that the IBIS Accuracy Subcommittee had decided last year to make the version of the IBIS Accuracy Spec track the version of IBIS itself. Bob Haller is in favor of keeping this convention. Greg Edlund argued that we may someday be mixing features from IBIS 2.1 and 3.2 in the same version of the IBIS Accuracy spec, which might add confusion if we say we're tracking with IBIS. Bob Ross suggested that we keep bumping the version from 1.1 to 1.2, etc. until we are ready to take the spec to the Open Forum for a vote. ACCURACY-RELATED BIRD(S) There was some productive feedback from the IBIS users list regarding the possibility of issuing a new BIRD that would describe the test loads outlined in the IBIS Accuracy Spec. Several people expressed opinions in favor of a machine-readable format. This is ultimately the direction in which the IBIS Accuracy Subcommittee would like to go because it would facilitate automated computation of behavioral vs. golden waveform correlation metrics. However, a new BIRD would entail more discussion at the Open Forum. Since we want to focus on approval of the IBIS Accuracy Spec first, we decided to put off an new BIRD until later this year. In the meantime, we can use the existing VT capabilities of IBIS to capture our new golden waveforms. APPROVAL PROCESS Getting approval of the IBIS Accuracy Specification is a two-step process, according to Bob Ross. First, we need to bring the document before the Open Forum for a vote. Second, we proceed with formal approval by the EIA. The group decided to take version 1.2 of the spec to the Open Forum, which will be ready for review before the next Users Group conference call. IBIS ACCURACY SPECIFICATION DEVELOPMENT The group decided to put off any work on the next generation of the IBIS Accuracy Specification until the first version is well into the approval process. Greg Edlund already sent an email to the users reflector on this topic; this was a bit premature. Action item #7 will remain open until it is appropriate to bring this topic up for discussion again. TEST BOARD Bob Haller and Greg Edlund discussed the test board in a private conversation and concluded that they did not have the bandwidth to pursue changes in the test board at this time. However, the changes that need to be made are very minor and would probably only take 1-2 days of board design time. If National is able to volunteer some design (and/or fab) resources, Bob and Greg would put in the necessary effort to help turn the board design. Greg Edlund notes that the test board tar file on the web contains a list of errata. ACCURACY ACTION ITEMS: 5 open, 3 closed Review list and add new items. 1. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Edit measurement and correlation sections of the IBIS Accuracy Specification and distribute the new document. 2. Status: CLOSED. Opened: 2/26/99 Owner: Greg Edlund. Write email to the reflector soliciting input on the contents of an accuracy-related BIRD. At issue is whether or not to include a machine-readable description of the test loads described in the IBIS Accuracy Specification. 3. Status: open. Opened: 2/26/99 Owner: Peter LaFlamme. Make VCX16244 SPICE model and IBIS datasheet available on the accuracy web page. 4. Status: CLOSED. Opened: 2/26/99 Owner: Bob Haller, Greg Edlund. Discuss test board changes off-line. 5. Status: open. Opened: 2/26/99 Owner: Milt Schwarz. Get quote for building revision 3 of the test board. 6. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Write test board application note. 7. Status: open. Opened: 2/26/99 Owner: Greg Edlund. Send out a note to the reflector suggesting possible candidates for accuracy development in 1999. 8. Status: open: Opened 3/19/99 Owner: Bob Haller. Call Ed Sayre to set up next face-to-face Users Group meeting. PART II: EDUCATION SUBCOMMITTEE There was no discussion about education as Ed Sayre was not present for the call. Greg Edlund Advisory Engineer, Critical Net Analysis IBM 3650 Hwy. 52 N, Dept. HDC Rochester, MN 55901 gedlund@us.ibm.com From owner-ibis Thu Mar 25 16:55:09 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 QAA11886 for ; Thu, 25 Mar 1999 16:55:09 -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.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA13590; Thu, 25 Mar 1999 17:00:02 -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 QAA00174; Thu, 25 Mar 1999 16:49:29 -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 QAA28716; Thu, 25 Mar 1999 16:49:29 -0800 (PST) Message-Id: <199903260049.QAA28716@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: nikolai@avanticorp.com cc: ibis-users@eda.org Subject: Re: For ecl- buffers experts In-reply-to: Your message of "Thu, 25 Mar 1999 11:48:45 PST." <199903251948.LAA01341@iris.src.avanticorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Mar 1999 16:49:28 -0800 From: Stephen Peters > > To ecl- buffers experts: > > For ecl buffers, can we have an ibis file with > 2 rising and 2 falling waveforms (RWF/FWF) ? > > I would answer, why not? And I would reply, what's the point? An ECL output is not a totem-pole (pullup/pulldown) structure. The two waveform approach is designed specifically to isolate a pullup xsistors characteristics from a pulldown xsistor characteristics, as well as determine the amount of time between one turning off and the other turning on. This simply just doesn't apply to the open-emitter output of an ECL device. Regards, Stephen Peters Intel Corp. > > However, IBIS specs contains Sec 9, "Notes on > data derivation methods", which specify how to derive > rising/falling waveforms. This part specifies, that > for ecl buffers, the termination voltage, Vterm = Vcc - 2V. > The only one termination voltage suggests only one > waveform. > > Unlike ECL part, CMOS buffers part recommends > 2 termination voltages to use: Vdd and Vss, hence > we can derive 2 FWFs and 2 RWFs. > > Any comments, suggestions > > Thanks a lot > > ------------------------------- > Nikolai Bannov > Avant! Corporation > 46871 Bayside Parkway > Fremont, CA 94538 > > tel: 510-413-8634 > fax: 510-413-8080 > email: nikolai@avanticorp.com > ------------------------------- From owner-ibis Fri Mar 26 03:46:24 1999 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by server.eda.org (8.8.5/8.8.3) with ESMTP id DAA14224 for ; Fri, 26 Mar 1999 03:46:23 -0800 (PST) Received: from pkoengims.eng.pko.dec.com (pkoengims.eng.pko.dec.com [16.118.112.10]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id GAA32148 for ; Fri, 26 Mar 1999 06:40:57 -0500 (EST) Received: by pkoengims.eng.pko.dec.com with Internet Mail Service (5.5.1960.3) id ; Fri, 26 Mar 1999 06:40:56 -0500 Message-ID: From: Andrew Ingraham To: ibis-users@eda.org Subject: RE: For ecl- buffers experts Date: Fri, 26 Mar 1999 06:40:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain The pulldown is a required part of ECL; it doesn't operate without one. ECL wouldn't work if you used a pullup to Vdd (Vcc) instead. For CMOS, the pullups/pulldowns just give the buffer a load to work into; and unlike ECL, CMOS can both source and sink output current. Regards, Andy From owner-ibis Fri Mar 26 11:16:30 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 LAA15608 for ; Fri, 26 Mar 1999 11:16:29 -0800 (PST) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id LAA11423 for ; Fri, 26 Mar 1999 11:11:05 -0800 (PST) Received: from zip.Cadence.COM(158.140.103.36) by mailgate.cadence.com via smap (mjr-v1.2) id xma922475460.011380; Fri, 26 Mar 99 11:11:01 -0800 Received: from cadence.com (d158140105210 [158.140.105.210]) by zip.Cadence.COM (8.7.3/8.7.3) with ESMTP id OAA22080 for ; Fri, 26 Mar 1999 14:10:59 -0500 (EST) Message-ID: <36FBDBB6.C19AD0D1@cadence.com> Date: Fri, 26 Mar 1999 14:10:46 -0500 From: Mike LaBonte Organization: Cadence Design Systems X-Mailer: Mozilla 4.07 [en] (WinNT; U) MIME-Version: 1.0 To: ibis-users@vhdl.org Subject: Re: BIRD 58 References: <199903022127.VAA29901@thalia.fm.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Regarding the c_comp issue discussed in the Mar 26 IBIS meeting, related to BIRD 58, I would like to register my opinion in favor of allowing for the use of separate c_comp values attributed to each Driver Schedule stage. Although c_comp may be named as such because of the original intention that it encapsulate an overall component level capacitance, the practical matter is that Driver Schedule stages are most likely to correspond to actual transistors in an IO section. Each transistor does have it's own effective die capacitance. The designer of the stage buffers may (should) have validated their behavior individually, with c_comp intact. To then use them in a scenario where the c_comp values are not used may not make sense. (insert discussion of the aggregate capacitance for a cluster of transistors vs. sum of individually calculated capacitances here). Furthermore, IBIS could gain maximum flexibility by stating that the c_comp values of individual stages are used in addition to the c_comp that might be specified for the top-level model. In this way, model designers can specify c_comp=0 for any portion that is not to be used. This part of the proposal is debatable in my own mind, simply because I have some difficulty producing an elegant explanation of what the top-level capacitance represents, when the`"transistor" capacitance is already accounted for. But it offers flexibility. And it eliminates the requirement that simulators ignore c_comp data present in the Model, which users may not be aware of. Mike LaBonte Muranyi, Arpad wrote: > > **************************************************************************** > ** > **************************************************************************** > ** > > BIRD ID#: 58 > ISSUE TITLE: Driver Schedule keyword clarification > REQUESTER: Arpad Muranyi, Intel Corporation > DATE SUBMITTED: 3/2/99 > DATE ACCEPTED BY IBIS OPEN FORUM: pending > > **************************************************************************** > ** > **************************************************************************** > ** > > STATEMENT OF THE ISSUE: > > The [Driver Schedule] section of the latest IBIS specification (v3.2) does > not provide enough information to the model maker and EDA tool vendor on > essential details of this keyword. The spec. can be interpreted in several > different ways which can lead to serious discrepancies and consequences. > > **************************************************************************** > ** > > STATEMENT OF THE RESOLVED SPECIFICATIONS: > > One paragraph from BIRD35.3 is included in the [Driver Schedule] usage rules > section of the specification. This portion seems to have been > inadvertently left out from the spec. and explains the gray areas. > > The additional words do not change the original intent behind this keyword. > It is only added to spell out how the keyword must be used so that the model > maker and EDA tool vendor could be in agreement on how the model works. > > The new section is marked with a "*" character at the beginning of each > line. > > |=========================================================================== > == > | Keyword: [Driver Schedule] > | Required: No > | Description: Describes the relative model switching sequence for > referenced > | models to produce a multi-staged driver. > | Usage Rules: The [Driver schedule] keyword establishes a hierarchical > order > | between models and should be placed under the [Model] which > | acts as the top-level model. The scheduled models are then > | referenced from the top-level [Model] by the [Driver > Schedule] > | keyword. > | > |* The [Driver Schedule] keyword overrides any existing > [Pullup], > |* [Pulldown] and [Ramp] or [Rising Waveform] and [Falling > |* Waveform] data for that model. However, the required tables > |* for [Model] are still required for backwards compatibility > |* reasons for simulators which do not support multi-staged > |* switching. This information can be used as a composite > model > |* cross-check, although the resulting model may not perform in > |* the same manner as the multi-stage model. > | > | The [Driver Schedule] table consists of five columns. The > | first column contains the model names of other models that > | exists in the .ibs file. The remaining four columns > describe > | delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and > | Falling_off_dly. All values are referenced to 0 seconds for > | the start of the rising transition and 0 seconds for the > start > | of the falling transition. All delays must be equal to or > | greater than 0. > | > | The Rise_on_dly entry gives the beginning of the low-to-high > > | transition. The Rise_off_dly entry may be given to end the > | low-to-high transition and initiate a high-to-low transition > > | during the rising cycle. Similarly, the Fall_on_dly gives > | the beginning of the high-to-low transition. The > Fall_off_dly > | may be given to end the high-to-low transition and initiate > a > | low-to-high transition. > | > | Use 'NA' when no transition is applicable. For each model, > | the transition sequence must be complete, i.e., it must > start > | and end at the same state. > | > | Only the [Pulldown] and [Pullup] tables and transition data > | [Ramp] or [Rising Waveform] and [Falling Waveform] data are > | used from each model that is referenced. The [Model] > keyword > | provides the specification information, [GND Clamp] and > [POWER > | Clamp], and C_comp, regardless of information contained in > | the referenced models. > | > | It is recommended that a "golden waveform" for the device > | consisting of a [Rising Waveform] table and a [Falling > | Waveform] table be supplied under the [Model] keyword to > | serve as a reference for validation. > | > | No [Driver Schedule] may reference a model which itself has > | within it a [Driver Schedule] table keyword. > | > | Other Notes: The added models typically consist of Open_sink (Open_drain) > > | or Open_source models to provide sequentially increased > drive > | strengths. The added drive may be removed within the same > | transition for a momentary boost or during the opposite > | transition. > | > | The syntax also allows for reducing the drive strength. > | > | Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, > | Fall_off_dly parameters are single value parameters, so > | typical, minimum and maximum conditions cannot be described > | with them directly. In order to account for those effects, > | one can refer to the fastest waveform table with the delay > | number and then insert an appropriate amount of horizontal > | lead in section in those waveforms which need more delay. > | > | Note: In a future release, the [Driver Schedule] keyword may > | be replaced by a newer method of specification that is > | consistent with some other planned extensions. However, the > | [Driver Schedule] syntax will continue to be supported. > |--------------------------------------------------------------------------- > -- > [Driver Schedule] > | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly > MODEL_OUT 0.0ns NA 0.0ns NA > | > | Examples of added multi-staged > transitions > M_O_SOURCE1 0.5ns NA 0.5ns NA > | low (high-Z) to high high to low (high-Z) > M_O_SOURCE2 0.5n 1.5n NA NA > | low to high to low low (high-Z) > M_O_DRAIN1 1.0n NA 1.5n NA > | low to high (high-Z) high (high-Z) to low > M_O_DRAIN2 NA NA 1.5n 2.0n > | high (high-Z) high to low to high > | > |=========================================================================== > == > > **************************************************************************** > ** > > ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: > > An attempt to build an IBIS 3.2 buffer model for a three-stage buffer using > the [Driver Schedule] keyword failed. The initial testing of this model > with the tools of two EDA vendors showed only two of the three stages > working. This happened because the first stage of the buffer was placed > into the "main" [Model] section of the IBIS model due to a personal > interpretation of the IBIS 3.2 spec. After consulting with several people, > it became apparent that the specification does not mention some of the key > information that is necessary to build a correct IBIS model for this kind of > a buffer. > > The following paragraph in BIRD35.3 contains the missing information which > is necessary for making correct IBIS models using the [Driver Schedule] > keyword. This section seems to have been accidentally left out from the > specification, and should be pasted into the appropriate location as shown > above. (Note that the first and second sentences are deleted because they > do not provide new information in the context above). > > "The new keyword [Driver Schedule] provides a syntax for sequencing other > models. This is given as a keyword under the [Model] keyword. It overrides > any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and > [Falling Waveform] data for that model. However, the required tables for > [Model] are still required for backwards compatibility reasons for > simulators > which do not support multi-staged switching. This information can be used > as a composite model cross-check, although the resulting model may not > perform in the same manner as the multi-stage model." > > **************************************************************************** > ** > > ANY OTHER BACKGROUND INFORMATION: > > Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS > specification is missing the description of some of the usage rules which > were documented in BIRD35.3 and was implemented accordingly in ICX. > > **************************************************************************** > ** From owner-ibis Fri Mar 26 17:10:39 1999 Received: from hotmail.com (law-f195.hotmail.com [209.185.130.105]) by server.eda.org (8.8.5/8.8.3) with SMTP id RAA16575 for ; Fri, 26 Mar 1999 17:10:39 -0800 (PST) Received: (qmail 36179 invoked by uid 0); 27 Mar 1999 01:04:56 -0000 Message-ID: <19990327010456.36178.qmail@hotmail.com> Received: from 163.181.251.1 by www.hotmail.com with HTTP; Fri, 26 Mar 1999 17:04:55 PST X-Originating-IP: [163.181.251.1] From: "dennis lee" To: ibis-users@eda.org Subject: Problems with S2IBIS2 Modelling Date: Fri, 26 Mar 1999 17:04:55 PST Mime-Version: 1.0 Content-type: text/plain Hi IBIS Users, I'm relatively new at modelling IBIS and am using S2IBIS2 utility from NCSU. I'm currently having problems with the below. 1. I have an IO buffer that have 4 input ports and one IO port. How do I model this in S2IBIS file?? 2. When I use a Open_sink model type, the returned results are only for [Pulldown] and [dV/dt]. Why aren't there results returned for [Power Clamps] and [Ground Clamps] as specified in the IBIS 2.1 specification?? Appreciate any help from any current S2IBIS2 users. Regards, Dennis Get Your Private, Free Email at http://www.hotmail.com From owner-ibis Mon Mar 29 09:16:57 1999 Received: from aix2.uottawa.ca (s1136121@aix2.uottawa.ca [137.122.6.18]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA22691 for ; Mon, 29 Mar 1999 09:16:57 -0800 (PST) Received: from localhost (s1136121@localhost) by aix2.uottawa.ca (8.8.8/8.8.8) with SMTP id MAA22056 for ; Mon, 29 Mar 1999 12:11:23 -0500 Date: Mon, 29 Mar 1999 12:11:23 -0500 (EST) From: Ghanem Ghandour To: ibis-users@vhdl.org Subject: Seeking more information. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Sir or Madam: I am a University graduate in Electrical Engineering. I am very interested in learning more about IBIS modeling. If you would please let me know where I can get more information about this subject. Your input is really apriciated. Sincerely, Ghanem Ghandour From owner-ibis Mon Mar 29 12:14:14 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 MAA23703 for ; Mon, 29 Mar 1999 12:14:13 -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.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id MAA14662; Mon, 29 Mar 1999 12:19:14 -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 MAA13399; Mon, 29 Mar 1999 12:08:43 -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 MAA28030; Mon, 29 Mar 1999 12:08:42 -0800 (PST) Message-Id: <199903292008.MAA28030@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: Ghanem Ghandour cc: ibis-users@vhdl.org Subject: Re: Seeking more information. In-reply-to: Your message of "Mon, 29 Mar 1999 12:11:23 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Mar 1999 12:08:41 -0800 From: Stephen Peters > Dear Sir or Madam: > > I am a University graduate in Electrical Engineering. I am very interested > in learning more about IBIS modeling. If you would please let me know > where I can get more information about this subject. > > Your input is really apriciated. > > Sincerely, > Ghanem Ghandour Hello Ghanem: Please visit the IBIS web site at http://www.eia.org/eig/ibis/ibis.htm There you will find articles on IBIS, an FAQ, cookbooks and copies of the IBIS specification itself. Best Regards, Stephen Peters Intel Corp. Vice Chair, EIA IBIS Open Forum From owner-ibis Mon Mar 29 18:11:05 1999 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA25029; Mon, 29 Mar 1999 18:11:05 -0800 (PST) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id SAA17171; Mon, 29 Mar 1999 18:05:09 -0800 (PST) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id SAA00653; Mon, 29 Mar 1999 18:05:08 -0800 (PST) Sender: bob_ross@mentorg.com Message-ID: <37003154.9105651B@mentor.com> Date: Mon, 29 Mar 1999 18:05:08 -0800 From: Bob Ross X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Mike LaBonte , ibis@eda.org, ibis-users@eda.org Subject: Re: BIRD 58 References: <199903022127.VAA29901@thalia.fm.intel.com> <36FBDBB6.C19AD0D1@cadence.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike: Thank you for your input. You have some valid points regarding allowing C_comp to be distributed. This will work for creating driver models as the summation of individual drivers. The problem is that if the top-level model is an I/O model, we would normally not put in a C_comp value = 0. Then in the Input mode, we would have to add up all of the C_comps in the lower level models to come up with the effective C_comp. This is a possible workable solution that does not require any Specification syntax change - just a few more words of interpretation. It would also support moving all of the C_comp to the top-level for another method of building a behavioral buffer by construction. We will have to consider this. Bob Ross Mentor Graphics Subject: Re: BIRD 58 Date: Fri, 26 Mar 1999 14:10:46 -0500 From: Mike LaBonte To: ibis-users@vhdl.org Regarding the c_comp issue discussed in the Mar 26 IBIS meeting, related to BIRD 58, I would like to register my opinion in favor of allowing for the use of separate c_comp values attributed to each Driver Schedule stage. Although c_comp may be named as such because of the original intention that it encapsulate an overall component level capacitance, the practical matter is that Driver Schedule stages are most likely to correspond to actual transistors in an IO section. Each transistor does have it's own effective die capacitance. The designer of the stage buffers may (should) have validated their behavior individually, with c_comp intact. To then use them in a scenario where the c_comp values are not used may not make sense. (insert discussion of the aggregate capacitance for a cluster of transistors vs. sum of individually calculated capacitances here). Furthermore, IBIS could gain maximum flexibility by stating that the c_comp values of individual stages are used in addition to the c_comp that might be specified for the top-level model. In this way, model designers can specify c_comp=0 for any portion that is not to be used. This part of the proposal is debatable in my own mind, simply because I have some difficulty producing an elegant explanation of what the top-level capacitance represents, when the`"transistor" capacitance is already accounted for. But it offers flexibility. And it eliminates the requirement that simulators ignore c_comp data present in the Model, which users may not be aware of. Mike LaBonte From owner-ibis Wed Mar 31 08:14:14 1999 Received: from motgate2.mot.com (motgate2.mot.com [129.188.136.102]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA04818 for ; Wed, 31 Mar 1999 08:14:13 -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 KAA16227 for ; Wed, 31 Mar 1999 10:10:08 -0600 (CST)] Received: [from msgphx1.sps.mot.com (msgphx1.sps.mot.com [216.11.52.1]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA04563 for ; Wed, 31 Mar 1999 10:08:40 -0600 (CST)] Received: from email.sps.mot.com ([163.4.1.131]) by msgphx1.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA5457 for ; Wed, 31 Mar 1999 09:08:39 -0700 Message-ID: <37023AF1.1FA7206E@email.sps.mot.com> Date: Wed, 31 Mar 1999 10:12:32 -0500 From: "Robert Goodrich" X-Mailer: Mozilla 4.03C-MOTSPS4.03 (Macintosh; I; PPC) MIME-Version: 1.0 To: "ibis-users@eda.org" Subject: C_comp Confusion Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Motorola-Sent-Wireless: 1 OK, just when I think I know what C_comp is supposed to be I am led to suspect a misunderstanding. At the risk of asking a stupid question - I think it is important for me to know the "bottom line" definition since I am currently creating models for use by our customers. The ver3_2 spec. (and previous versions) define C_comp as Si die capacitance. From the terminator model (and cookbook) I have assumed that meant the DC capacitance to GND (substrate) looking at the actual pad (pad meaning metal actually deposited on Si) for a given I, I/O, O etc. looking into the placed and routed buffer. From other sources (classes, people, email) I keep hearing C_comp referred to as "component" Si die capacitance. This was recently described to me as total Si "chip" capacitance. Now, I don't know what that means - but it doesn't sound like my assumption. Is my understanding of what C_comp is supposed to represent correct? Thanks, --Rob -- Rob Goodrich Circuit Design - Advanced Imaging Technology (AIT) Motorola SPS, I&E Solutions 6501 William Cannon Drive West MD: OE37 Austin, TX 78735 ra3862@email.sps.mot.com (512) 895-7341 From owner-ibis Wed Mar 31 08:31:19 1999 Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA04880 for ; Wed, 31 Mar 1999 08:31:19 -0800 (PST) Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) by calliope1.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 IAA22921; Wed, 31 Mar 1999 08:25:40 -0800 (PST) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 31 Mar 1999 08:25:39 -0800 Message-ID: <4575832C8E71D111AC4100A0C96B512703BB0AFA@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'Robert Goodrich'" , ibis-users@eda.org Subject: RE: C_comp Confusion Date: Wed, 31 Mar 1999 08:25:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Rob, C_comp is everything that you see when you look into the chip at the pad. That includes pad capacitance, metal capacitance, transistor parasitics, and everything you can think of. Does this answer your question? Arpad ========================================================================= -----Original Message----- From: Robert Goodrich [mailto:ra3862@email.sps.mot.com] Sent: Wednesday, March 31, 1999 7:13 AM To: ibis-users@eda.org Subject: C_comp Confusion OK, just when I think I know what C_comp is supposed to be I am led to suspect a misunderstanding. At the risk of asking a stupid question - I think it is important for me to know the "bottom line" definition since I am currently creating models for use by our customers. The ver3_2 spec. (and previous versions) define C_comp as Si die capacitance. From the terminator model (and cookbook) I have assumed that meant the DC capacitance to GND (substrate) looking at the actual pad (pad meaning metal actually deposited on Si) for a given I, I/O, O etc. looking into the placed and routed buffer. From other sources (classes, people, email) I keep hearing C_comp referred to as "component" Si die capacitance. This was recently described to me as total Si "chip" capacitance. Now, I don't know what that means - but it doesn't sound like my assumption. Is my understanding of what C_comp is supposed to represent correct? Thanks, --Rob -- Rob Goodrich Circuit Design - Advanced Imaging Technology (AIT) Motorola SPS, I&E Solutions 6501 William Cannon Drive West MD: OE37 Austin, TX 78735 ra3862@email.sps.mot.com (512) 895-7341 From owner-ibis Wed Mar 31 09:12:06 1999 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA05009 for ; Wed, 31 Mar 1999 09:12:01 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id LAA21993 for ; Wed, 31 Mar 1999 11:06:25 -0600 (CST)] Received: [from msgphx1.sps.mot.com (msgphx1.sps.mot.com [216.11.52.1]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA08438 for ; Wed, 31 Mar 1999 11:06:24 -0600 (CST)] Received: from email.sps.mot.com ([163.4.1.131]) by msgphx1.sps.mot.com (Netscape Messaging Server 3.61) with ESMTP id AAA44D8; Wed, 31 Mar 1999 10:06:22 -0700 Message-ID: <37024878.F00F10B9@email.sps.mot.com> Date: Wed, 31 Mar 1999 11:10:21 -0500 From: "Robert Goodrich" X-Mailer: Mozilla 4.03C-MOTSPS4.03 (Macintosh; I; PPC) MIME-Version: 1.0 To: "Muranyi, Arpad" , "ibis-users@eda.org" Subject: Re: C_comp Confusion References: <4575832C8E71D111AC4100A0C96B512703BB0AFA@fmsmsx36.fm.intel.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Motorola-Sent-Wireless: 1 Yes it does - and thanks, now I don't have to change any of my models . . . --Rob Muranyi, Arpad wrote: > Rob, > > C_comp is everything that you see when you look into the chip at the pad. > That includes pad capacitance, metal capacitance, transistor parasitics, > and everything you can think of. > > Does this answer your question? > > Arpad > ========================================================================= > > -----Original Message----- > From: Robert Goodrich [mailto:ra3862@email.sps.mot.com] > Sent: Wednesday, March 31, 1999 7:13 AM > To: ibis-users@eda.org > Subject: C_comp Confusion > > OK, just when I think I know what C_comp is supposed to be I am led to > suspect a misunderstanding. At the risk of asking a stupid question - I > think it is important for me to know the "bottom line" definition since > I am currently creating models for use by our customers. The ver3_2 > spec. (and previous versions) define C_comp as Si die capacitance. From > the terminator model (and cookbook) I have assumed that meant the DC > capacitance to GND (substrate) looking at the actual pad (pad meaning > metal actually deposited on Si) for a given I, I/O, O etc. looking into > the placed and routed buffer. From other sources (classes, people, > email) I keep hearing C_comp referred to as "component" Si die > capacitance. This was recently described to me as total Si "chip" > capacitance. Now, I don't know what that means - but it doesn't sound > like my assumption. Is my understanding of what C_comp is supposed to > represent correct? > > Thanks, > --Rob > -- > > Rob Goodrich > Circuit Design - Advanced Imaging Technology (AIT) > Motorola SPS, I&E Solutions > 6501 William Cannon Drive West MD: OE37 > Austin, TX 78735 > ra3862@email.sps.mot.com > (512) 895-7341 -- Rob Goodrich Circuit Design - Advanced Imaging Technology (AIT) Motorola SPS, I&E Solutions 6501 William Cannon Drive West MD: OE37 Austin, TX 78735 ra3862@email.sps.mot.com (512) 895-7341