From owner-ibis Tue Nov 30 22:51:30 1999 Received: from zukengw.zuken.co.jp (zukengw.zuken.co.jp [202.33.240.18]) by server.eda.org (8.8.5/8.8.3) with ESMTP id WAA08543 for ; Tue, 30 Nov 1999 22:51:29 -0800 (PST) Received: from zuken.co.jp ([160.249.234.114]) by zukengw.zuken.co.jp (8.8.8/3.6W) with ESMTP id PAA14983 for ; Wed, 1 Dec 1999 15:50:20 +0900 (JST) Received: from s4e24.zuken.co.jp (s4e24 [160.249.233.24]) by zuken.co.jp (8.8.8/3.6Wbeta7) with SMTP id PAA22704; Wed, 1 Dec 1999 15:50:19 +0900 (JST) Received: from s4e164 by s4e24.zuken.co.jp (1.38.193.4/6.4J.6-local-1.0) id AA18478; Wed, 1 Dec 1999 15:55:53 +0900 Message-Id: <4.0.1-J.19991201155626.00dd49b0@s4e24> X-Sender: k.mori@zuken.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1-J Date: Wed, 01 Dec 1999 15:57:46 +0900 To: ibis-users@eda.org From: =?ISO-2022-JP?B?GyRCQDkbKEI=?==?ISO-2022-JP?B?IBskQjdyPCEbKEI=?= Subject: about "Waveform","Vmeas","Rref","Cref","Vref" Cc: =?ISO-2022-JP?B?GyRCTlMbKEI=?= Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Hello all Please tell me about the next two items. The first item is about "Waveform". Why was this item made ? And How was this item used ? I often see this item in an IBIS model, but not useful eno ugh. The second item is about "Vmeas", "Rref", "Cref", and "Vref". These items a re used for a propagation delay. So, are these items "TEST LOAD" to get AC characteristics written into IC vendor's data-sheets ? Best Regards k.mori ================================================== $B@9(B $B7r Date: Wed, 01 Dec 1999 10:56:14 -0800 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: IBIS REFLECTOR VIRUS ALERT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To All: If you receive a message shown below, DO NOT OPEN the attached zipped_files.exe file: -------------------------------------------------------------- Hi ! I received your email and I shall send you a reply ASAP. Till then, take a look at the attached zipped docs. bye. <> -------------------------------------------------------------- Many Corporations are already dealing with a new variant of the autospam TROJ_EXPLOREZIP worm: TROJ_EXPZIPWMPAK. Some machines on the IBIS reflector e-mail lists may have already been infected. When you send any e-mail through the IBIS reflectors or directly, you may get the above response sent directly back to you. DO NOT OPEN the attached zipped_files.exe file. Below is part of an explaination sent out on my site: > After a user clicks on the attachment, this destructive trojan > searches hard drives C: through Z:, selecting the Microsoft Word, > Excel and PowerPoint files as well as source code files used by > programmers including C++, C, and Assembler source files and > reduces their file size to zero, making the data unrecoverable. > When executed, TROJ_EXPZIPWMPAK utilizes MAPI enabled email > systems, to automatically reply to any subsequently received > email messages. The email reply will include the infected > attachment with the message shown above. It will use the > subject line of the received email when it replies. > > "TROJ_EXPLOREZIP caused millions of dollars of damage worldwide > the first time since it overwrites files, instead of just deleting > them, it's particularly damaging. Bob Ross Mentor Graphics From owner-ibis Thu Dec 2 14:46:52 1999 Received: from soran.bos.ascend.com (soran.bos.ascend.com [152.148.40.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA23426 for ; Thu, 2 Dec 1999 14:46:51 -0800 (PST) Received: from rawhide.bos.ascend.com (rawhide [152.148.140.32]) by soran.bos.ascend.com (8.9.3/8.9.3) with ESMTP id RAA11693 for ; Thu, 2 Dec 1999 17:44:46 -0500 (EST) Received: from fox.bos.ascend.com (fox.bos.ascend.com [152.148.141.238]) by rawhide.bos.ascend.com (8.8.8+Sun/8.8.4) with ESMTP id RAA26945 for ; Thu, 2 Dec 1999 17:45:30 -0500 (EST) Received: by fox.bos.ascend.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 17:45:14 -0500 Message-ID: From: "Peregrim, Lawrence" To: "'ibis-users@eda.org'" Subject: I/V curves for ECL outputs Date: Thu, 2 Dec 1999 17:45:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I'd like some guidance on how to generate the I/V curves for ECL output (only) buffers. The emitter outputs have to be terminated to properly bias the output transistors, so I'm sure how to handle the DC sweep. The IBIS spec or cookbook are not clear on this issue. Thank you. Lawrence Peregrim peregrim@lucent.com From owner-ibis Mon Dec 6 07:21:48 1999 Received: from smtp.NE.3Com.COM (smtp.ne.3com.com [151.104.25.99]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA12699 for ; Mon, 6 Dec 1999 07:21:47 -0800 (PST) From: Joseph_Nicolaisen@ne.3com.com Received: from usboxmta.ne.3com.com (usboxmta.NE.3Com.COM [151.104.25.34]) by smtp.NE.3Com.COM (Pro-8.9.3/Pro-8.9.3) with SMTP id KAA08338 for ; Mon, 6 Dec 1999 10:20:36 -0500 (EST) Received: by usboxmta.ne.3com.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525683F.005689D1 ; Mon, 6 Dec 1999 10:45:13 -0500 X-Lotus-FromDomain: 3COM To: ibis-users@eda.org cc: David_Feres@ne.3com.com Message-ID: <8525683F.0051D075.00@usboxmta.ne.3com.com> Date: Mon, 6 Dec 1999 10:23:55 -0500 Subject: diff terminations in IBIS Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII All: I am having some difficulty simulating an LVDS receiver which has an interal center-tap differential termination. VI data was manually extracted from simulation of encrypted HSPICE models. HSPICE sims look good, but I can't get IBIS sims to match HSPICE results. I've tried two methods of modeling the termination; One was to model the receiver with an extended [GND clamp] (-3.3V to 6.6V). The other method was to partition the receiver VI data into a [GND clamp] and [POWER clamp] , both with the standard voltage sweeps. Strangely, these two methods produced significantly different results. Neither one resembled HSPICE results. Extraction of all VI data was done with the center tap tied to 1.2V. Without this condition, DC offsets become present in results. Has anyone had success simulating an internal center-tap differential termination with IBIS? Thanks, Joe Nicolaisen From owner-ibis Thu Dec 9 17:31:43 1999 Received: from dns.uei.co.jp (dns.uei.co.jp [210.160.168.194]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA09594; Thu, 9 Dec 1999 17:31:40 -0800 (PST) Received: from duckcad ([192.168.100.33]) by dns.uei.co.jp (8.8.8+2.7Wbeta7/3.6W) with SMTP id KAA24290; Fri, 10 Dec 1999 10:26:29 +0900 (JST) Message-ID: <006301bf42af$7af79860$2164a8c0@uei.co.jp> From: "THAM KOK TONG" To: , Subject: Rising Waveform Date: Fri, 10 Dec 1999 10:40:03 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01BF42FA.EAC54FC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01BF42FA.EAC54FC0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hello All, Anybody can tell me what will happen to the output waveform if my IBIS model which only contain a Rising Waveform for V_fixture=0.0v and Falling Waveform for V_fixture=3.3v? My output waveform disable to reach full amplitude(3.3V), is the Rising Waveform is the main problem? Reagrds, KT.THAM ------=_NextPart_000_005F_01BF42FA.EAC54FC0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hello All,
 
Anybody can tell me what will happen to=20 the output waveform
if my IBIS model which only contain a Rising = Waveform for=20 V_fixture=3D0.0v and Falling Waveform for V_fixture=3D3.3v?
My output waveform disable to reach full = amplitude(3.3V), is=20 the Rising Waveform is the main problem?
 
Reagrds,
KT.THAM
 
------=_NextPart_000_005F_01BF42FA.EAC54FC0-- From owner-ibis Sat Dec 11 06:19:00 1999 Received: from lightyear.aud.alcatel.com (lightyear.aud.alcatel.com [128.251.234.78]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA21340 for ; Sat, 11 Dec 1999 06:19:00 -0800 (PST) Received: from rwasic97.aud.alcatel.com by lightyear.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id IAA08360; Sat, 11 Dec 1999 08:18:16 -0600 (CST) Received: from rwasic59.aud.alcatel.com by rwasic97.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id IAA14162; Sat, 11 Dec 1999 08:18:05 -0600 (CST) Received: (from dresri@localhost) by rwasic59.aud.alcatel.com (8.8.8+Sun/8.8.8) id IAA26302 for ibis-users@eda.org; Sat, 11 Dec 1999 08:13:04 -0600 (CST) Date: Sat, 11 Dec 1999 08:13:04 -0600 (CST) From: "Richard I. Dressman" Message-Id: <199912111413.IAA26302@rwasic59.aud.alcatel.com> To: ibis-users@eda.org Subject: LVDS HSPICE-to-IBIS X-Sun-Charset: US-ASCII Hi. My name is Richard Dressman. I work at Alcatel USA in Richardson TX. I have been using Spice-to-IBIS conversion for several years. I have had a devil of a time getting dV/dT info when attempting to convert LVDS differential input-to-differential output models. The converter will spit out Pull-up and Pull-down info fine, but the dV/dT info will read like 0.00/0.00. HEEEELP!!! Richard Dressman Alcatel USA Ph:972-996-7177 Fax:972-996-7362 From owner-ibis Sat Dec 11 17:48:54 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 RAA23072 for ; Sat, 11 Dec 1999 17:48:54 -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 RAA17946; Sat, 11 Dec 1999 17:47:40 -0800 (PST) Message-Id: <199912120147.RAA17946@jasper.cisco.com> Date: Sat, 11 Dec 1999 17:47:40 -0800 (PST) From: Syed Huq Reply-To: Syed Huq Subject: Re: LVDS HSPICE-to-IBIS To: ibis-users@eda.org, dresri@aud.alcatel.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RBG+axb5qlWBc98+Pgd9jA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Richard, You need to look at the intermediate files(eg, .spi, .out)to understand what may have gone wrong. It seems that the transient analysis failed to switch the device from low-to-high or high-to-low and the resultant dV/dT in the IBIS model had zero entries. You may see files with naming such as: rut5.spi : Ramp Up Typical Pin#5 Spice Input File rdt5.out : Ramp Down Typical Pin#5 Spice Output File run5.spi : Ramp Up Min ... rux5.spi : Ramp Up Max ... An example of a rut5.spi file is(partial): ------------------------------------------ RLOADS2I PAD GND 50 <--- 50 Ohms to GND Rload VCCS2I VDD 0 DC 3.3 VGNDS2I GND 0 DC 0 VENAS2I TS 0 DC 3.3 VINS2I A 0 PULSE(0 3.3 0 3e-11 3e-11 6e-09 1.212e-08) .TEMP 27 .OPTIONS INGOLD=2 .TRAN 3e-11 3e-09 .PRINT TRAN V(PAD) Check to see if your specific .spi makes sense. If it does not, then the header file(.s2i)was not setup properly and you need to fix that. Check the RLOADS2I, PULSE statements, any enable/disable pin setup, .TRAN statement etc.. You could run Spice in a stand alone mode(not using s2ibis2)and perform a transient analysis to make sure the device is switching properly. Then it's a matter of tweaking the s2i file to generate a similiar .spi file such that the translator(s2ibis2)can perform the correct transient anaylysis. Most s2ibis2 users do not setup the header information(.s2i)correctly and Spice fails to generate the proper file. Hope this helps.. Regards, Syed > > Hi. > > My name is Richard Dressman. I work at Alcatel USA in Richardson > TX. I have been using Spice-to-IBIS conversion for several years. > I have had a devil of a time getting dV/dT info when attempting > to convert LVDS differential input-to-differential output models. The > converter will spit out Pull-up and Pull-down info fine, but the > dV/dT info will read like 0.00/0.00. HEEEELP!!! > > Richard Dressman > Alcatel USA > Ph:972-996-7177 > Fax:972-996-7362 > From owner-ibis Wed Dec 15 13:52:04 1999 Received: from soran.bos.ascend.com (soran.bos.ascend.com [152.148.40.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA19965 for ; Wed, 15 Dec 1999 13:52:03 -0800 (PST) Received: from rawhide.bos.ascend.com (rawhide [152.148.140.32]) by soran.bos.ascend.com (8.9.3/8.9.3) with ESMTP id QAA17652 for ; Wed, 15 Dec 1999 16:49:55 -0500 (EST) Received: from fox.bos.ascend.com (fox.bos.ascend.com [152.148.141.238]) by rawhide.bos.ascend.com (8.8.8+Sun/8.8.4) with ESMTP id QAA03784 for ; Wed, 15 Dec 1999 16:50:45 -0500 (EST) Received: by fox.bos.ascend.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Dec 1999 16:50:20 -0500 Message-ID: From: "Peregrim, Lawrence" To: "'ibis-users@eda.org'" Subject: Vref, Rref, & Cref Date: Wed, 15 Dec 1999 16:50:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I have a clarification question regarding the use of the Vref, Rref, & Cref subparameters. If one uses only a capacitor to ground as a test load, does this mean only Cref is included in the IBIS model and not Rref and Vref? Is the absence of Rref the same as Rref = and Vref = , as far as simulation is concerned? Thanks. Lawrence Peregrim peregrim@lucent.com From owner-ibis Fri Dec 17 03:01:54 1999 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by server.eda.org (8.8.5/8.8.3) with ESMTP id DAA04252 for ; Fri, 17 Dec 1999 03:01:48 -0800 (PST) From: Karl.Schroedinger@infineon.com X-Envelope-Sender-Is: Karl.Schroedinger@infineon.com (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id MAA29814 for ; Fri, 17 Dec 1999 12:01:01 +0100 (MET) Received: from mchb0b1w.muc.infineon.com (ldap.muc.infineon.com [190.1.19.229]) by mail1.siemens.de (8.9.3/8.9.3) with ESMTP id MAA22180 for ; Fri, 17 Dec 1999 12:00:56 +0100 (MET) Received: by ldap.muc.infineon.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Dec 1999 12:00:55 +0100 Message-ID: <1153A4191C04D111933100007786D7E101A4C94F@blnw804a.bln.infineon.com> To: ibis-users@eda.org Subject: LVDS IOs Date: Fri, 17 Dec 1999 11:47:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id DAA04253 My question is: Does anybody work on newer type IO-IBIS-models, such as LVDS, SSTL2. I didn't found any of this types in the new Version 3.2. Karl Schrödinger Infineon Technologies FO E IC BLN-S Karl Schrödinger Tel. (030) 386-27953 IC-Development Fax (030) 386-24939 Fiber Optics Engineering Dptm. new: mailto:karl.schroedinger@infineon.com __________________________ From owner-ibis Fri Dec 17 09:06:09 1999 Received: from isis.vlsi.com (relayhost.vlsi.com [63.194.140.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA07914 for ; Fri, 17 Dec 1999 09:06:03 -0800 (PST) Received: (from smtp@localhost) by isis.vlsi.com (8.9.1a/8.9.1) id JAA10395; Fri, 17 Dec 1999 09:05:07 -0800 (PST) X-Authentication-Warning: isis.vlsi.com: smtp set sender to using -f Received: from (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by isis via smap (V2.0) id xma010387; Fri, 17 Dec 99 09:04:42 -0800 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id YM1WDSP1; Fri, 17 Dec 1999 10:04:41 -0700 Sender: dsession@isis.vlsi.com Message-ID: <385A6D28.B8A1678A@vlsi.com> Date: Fri, 17 Dec 1999 10:04:40 -0700 From: "D. C. Sessions" Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ibis-users@eda.org CC: Karl.Schroedinger@infineon.com Subject: Re: LVDS IOs References: <1153A4191C04D111933100007786D7E101A4C94F@blnw804a.bln.infineon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karl.Schroedinger@infineon.com wrote: > > My question is: > Does anybody work on newer type IO-IBIS-models, such as LVDS, SSTL2. I didn't found any of this types in the new Version 3.2. SSTL-2 outputs are easy. SSTL-2 inputs are fair, in that they are differential but not fully characterizable for Hihac, Vihdc, etc. BIRD62 and BIRD63 are intended to address this. Perhaps you'd like to help get them moving? In contrast, LVDS inputs are pretty straightforward differential inputs (although BIRD61 type timing characterization is needed for high speed use) and the outputs are a bit messy given the common-mode feedback and IBIS' lack of true-differential output modeling. -- D. C. Sessions dc.sessions@vlsi.com From owner-ibis Mon Dec 20 04:07:07 1999 Received: from galileo5.galileo.co.il ([192.116.246.130]) by server.eda.org (8.8.5/8.8.3) with ESMTP id EAA17572 for ; Mon, 20 Dec 1999 04:07:02 -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 OAA09535 for ; Mon, 20 Dec 1999 14:06:02 +0200 (GMT-2) Sender: dan@galileo.co.il Message-ID: <385E1BA8.79413F0@galileo.co.il> Date: Mon, 20 Dec 1999 14:06:00 +0200 From: Dan Aleksandrowicz Organization: GALILEO Technology Ltd. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ibis-users@eda.org" Subject: Problems with voltage sweep in S2IBIS Content-Type: multipart/alternative; boundary="------------06BA5FFC916FB17D9E96C937" --------------06BA5FFC916FB17D9E96C937 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Hi All. I am generating buffers from a heavily detailed spice model. The problem is that the spice does not converge for the full sweep of -3.3V -> 6.6V. I tried to trick the s2ibis by setting the Vcc to 2.4V thus reducing the sweep to -2.4 -> 4.8V. But, that of course lead to an offset of 0.9V in the PullUp/PowerClamp curves. I am looking for a method that will enable me to restrict the voltage sweep, without shifting the curves. I though I could restrict the sweep by "fixing" the s2ibis C, but I could not find the right structure. Thanks. -- \\|// (o o) ~~~~~~~~~~~~oOOo~(_)~oOOo~~~~~~~~~~~~~~~~~~~ Dan Aleksandrowicz Galileo Technology Mercaz Ofek 1 (Building B') Northern Industrial Zone, LOD 71293, ISRAEL email:dan@galileo.co.il Tel: +972 8 9247555 (- Ext. 324 |__| |__| #|oo| |--| ___ _ _ |--| | | |\ |oo|) /\ __ \\ \\ |------------\| #|--\ _||- ____\ \__\\_\\__|_||_________________\___| |__v-___ \ / \ "Smoke on the water. Fire in the sky." / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------06BA5FFC916FB17D9E96C937 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All.

I am generating buffers from a heavily detailed spice model.

The problem is that the spice does not converge for the full sweep
of -3.3V -> 6.6V.  I tried to trick the s2ibis by setting the Vcc to 2.4V
thus reducing the sweep to -2.4 -> 4.8V.

But, that of course lead to an offset of 0.9V in the PullUp/PowerClamp
curves.

I am looking for a method that will enable me to restrict the voltage
sweep, without shifting the curves.

I though I could restrict the sweep by "fixing" the s2ibis C, but I
could not find the right structure.

Thanks.
  

-- 
                \\|//
                (o o)
~~~~~~~~~~~~oOOo~(_)~oOOo~~~~~~~~~~~~~~~~~~~
Dan Aleksandrowicz
Galileo Technology 
Mercaz Ofek 1   (Building B') 
Northern Industrial Zone, LOD 71293,  ISRAEL 
email:dan@galileo.co.il
Tel: +972 8 9247555    (-                    
     Ext. 324         |__|
                      |__|
                     #|oo| |--|   ___
           _  _    |--|  | |  |\ |oo|)        /\
       __  \\ \\   |------------\| #|--\     _||-
   ____\ \__\\_\\__|_||_________________\___|   |__v-___
   \                                                   /
    \      "Smoke on the water. Fire in the sky."     /
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  --------------06BA5FFC916FB17D9E96C937-- From owner-ibis Mon Dec 20 07:23:34 1999 Received: from mailhost.dalsemi.com (vector.DALSEMI.COM [198.3.123.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA18683 for ; Mon, 20 Dec 1999 07:23:33 -0800 (PST) Received: from misnts1.dalsemi.com (misnts1.dalsemi.com [180.0.70.41]) by mailhost.dalsemi.com (8.9.3/8.9.3) with ESMTP id JAA03667 for ; Mon, 20 Dec 1999 09:22:45 -0600 (CST) Received: by misnts1.dalsemi.com with Internet Mail Service (5.5.2448.0) id ; Mon, 20 Dec 1999 09:22:45 -0600 Message-ID: <48BBF3423C34D111A67700805F19999207AD67DA@misnts1.dalsemi.com> From: Mike Lander To: "'ibis-users@eda.org'" Subject: SPICE to IBIS conversion vendors Date: Mon, 20 Dec 1999 09:22:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hello, I am looking for a company that can provide HSPICE to IBIS model conversions for several of our ICs. If you can provide this service please respond to me privately. Thank you, Mike Lander Product Manager, Broadband Products Dallas Semiconductor Phone: (972) 371-3723 Fax: (972) 371-3715 mike.lander@dalsemi.com From owner-ibis Wed Dec 22 14:58:10 1999 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA01066 for ; Wed, 22 Dec 1999 14:58:09 -0800 (PST) Received: from xcsbrg5.cs.itc.hp.com (xcsbrg5.cs.itc.hp.com [15.42.64.12]) by atlrel1.hp.com (Postfix) with ESMTP id CFF3D8F63 for ; Wed, 22 Dec 1999 17:57:20 -0500 (EST) Received: by xcsbrg5.cs.itc.hp.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Dec 1999 15:56:48 -0700 Message-ID: From: "CHANG,MARK (HP-SanJose,ex1)" To: "'ibis-users@eda.org'" Subject: HPSpice to IBIS Date: Wed, 22 Dec 1999 15:13:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi! I need to convert HPSpice to IBIS and wanted to check if any users had already written a routine for this or if any users had any suggestions or words of wisdom for this process. Thanks! -Mark From owner-ibis Thu Dec 23 08:42:57 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 IAA05468 for ; Thu, 23 Dec 1999 08:42:57 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id IAA01642; Thu, 23 Dec 1999 08:47:51 -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 IAA21675; Thu, 23 Dec 1999 08:37:06 -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 IAA09161; Thu, 23 Dec 1999 08:19:42 -0800 (PST) Message-Id: <199912231619.IAA09161@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: "CHANG,MARK (HP-SanJose,ex1)" cc: "'ibis-users@eda.org'" Subject: Re: HPSpice to IBIS In-reply-to: Your message of "Wed, 22 Dec 1999 15:13:19 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Dec 1999 08:19:38 -0800 From: Stephen Peters Hello Mark: A spice to IBIS (ver 1.1. and 2.1 only) conversion tool is available for download from the IBIS web page at http://www.eia.org/eig/ibis/tools.htm Just click and seclect your conversion tool of choice. Regards, Stephen Peters Intel Corp. > Hi! > > I need to convert HPSpice to IBIS and wanted to check if any users had > already written a routine for this or if any users had any suggestions or > words of wisdom for this process. > > Thanks! > > -Mark From owner-ibis Tue Dec 28 14:12: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 OAA03942; Tue, 28 Dec 1999 14:12: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.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id OAA13604; Tue, 28 Dec 1999 14:22:49 -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 OAA20534; Tue, 28 Dec 1999 14:12:05 -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 NAA20648; Tue, 28 Dec 1999 13:53:29 -0800 (PST) Message-Id: <199912282153.NAA20648@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: BIRD 61.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Dec 1999 13:53:28 -0800 From: Stephen Peters Hello All: Apologies for the long delay, but here are the updates to the three birds that deal with receiver characterization and specification. For details on the specific changes to each bird, look in the ANALYSIS section at the bottom. Regards, Stephen Peters Intel Corp. ==================== Buffer Issue Resolution Document (BIRD) BIRD ID#: 61.1 ISSUE TITLE: Enhanced Characterization of Receivers REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters, Arpad Muranyi (Intel Corp) DATE SUBMITTED: August 9, 1999, Dec 28, 1999 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The current specification allows the user to describe the static Vinh and Vinl thresholds of a receiver. However, these parameters specify only the DC input thresholds at which the output of a receiver switches state. They do not describe a digital logic receiver's dynamic performance. Dynamic performance includes such items as how a device's setup or hold time varies with input overdrive, or how a receiver behaves when an input waveform rings back into the area between Vinh and Vinl. In addition, the current specification does not support simulation methodologies that rely on specifying the total delay from the input of an output buffer to the output of the receiver. This bird offers a way for the user to specify a receiver's propagation delay and dynamic characteristics in enough detail so that a simulation tool can model a receiver's response to any arbitrary waveform. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined, and is placed in the specification just below the [Rising Waveform] and [Falling Waveform] keyword descriptions |============================================================================= | Keyword: [Receiver Delay] | Required: No | Sub-Params: Vth, Start_point, End_point, Slope | Description: This keyword specifies how the propagation delay of an | input receiver varies as a function of input overdrive or | input waveform slope. | | Usage Rules: The [Receiver Delay] keyword is followed immediately by the | three subparameter names and their arguments. The Start_point | and End_point subparameters define the starting and ending | voltage points of a linear ramp while the Slope parameter | specifies the slope of that ramp. Slope is given in units of | volts per second (V/S). The Vth subparameter is the ideal | input voltage at which the output of a receiver changes | state. The value of the Start_point and End_point | subparameters are always expressed as offsets from this | voltage. All four subparameters are required. | | Subparameter Usage: | The intent of the subparameters is to specify a set of linear | ramps that vary only in starting point, ending point, or | slope. Therefore, when assigning values to the subparameters, | two of the three subparameters must be assigned fixed values, | while the third subparameter uses as its argument the reserved | word TABLE. The use of the word TABLE indicates that this | subparameter is the independent variable in the associated | receiver delay table. The subparameter that uses the TABLE | argument must appear after the other two subparameters and | before the receiver delay table. | | Numerical arguments are separated from their associated | subparameter by an equals sign (=); white space around the | equals sign is optional. The TABLE argument is separate | from its associated subparameter by white space. | | Receiver Delay Table: | Following the subparameters is the receiver delay table itself. | This table consists of four columns. The first column lists | either the starting or ending offset from Vth or the slope | of the linear ramp (i.e. the independent variable as determined | by the subparameter with the TABLE argument). The second thru | fourth columns list the change in the receiver's propagation | delay. This "change in delay" is relative to the receiver's | delay when it is stimulated using the same overdrive and edge | rate conditions used to specify the device's setup and hold | times. The delay columns are arranged in the standard typ, | min, max format. All four entries must be placed on the same | line and must be separated by at least one white space. All | four columns are required. However, data is required only for | the typical column. If minimum or maximum data is not available | use the reserved word NA. Each receiver delay table is limited | to 100 rows and only one receiver delay table is allowed per | [Receiver Delay] keyword. However, there are no restrictions | on the number of [Receiver Delay] keywords per [Model] keyword. | Note that the [Receiver Delay] keyword is not allowed unless | the Model_type of the [Model] is one of the Input or I/O | models types. | | Use of INF as a Receiver Delay: | When building a receiver delay table the user may specify an | input condition that does not result in the receiver's output | changing state. In that case, the receiver delay is considered | infinite, and the reserved word INF is used in the delay | column. See the examples below. | | Other Notes: | It is expected that the user will provide enough [Receiver | Delay] keywords (i.e. characterization data) to allow a CAE | tool to build a model of the input receiver. It is expected | that at least four [Receiver Delay] keywords will be required; | two low to high going ramps and two high to low going ramps. | However, the exact number of ramps and there content is up | to the user and recommendations provided by the various | simulation vendors. | | An example table showing how receiver delay varies vs. overdrive. | Note the use of the reserved word INF. Also note that Start_point | and End_point are expressed as offsets from the Vth parameter. | [Receiver Delay] Vth = 1.5v Start_point = -0.7v Slope = 1v/1ns End_point TABLE |variable typ min max -0.10 INF 7.0ns INF +0.00 INF 5.0ns INF +0.01 INF 3.0ns 10.0ns +0.03 7.0ns 0.0ns 7.0ns +0.05 2.0ns 0.0ns 1.0ns +0.10 0.0ns 0.0ns 0.0ns +0.20 0.0ns 0.0ns 0.0ns +0.50 0.0ns 0.0ns 0.0ns +0.60 0.1ns 0.1ns 0.1ns +1.00 -0.2ns -0.1ns -0.5ns | | A second table that characterizes receiver delay vs. the slope of the | input waveform. | [Receiver Delay] Vth = 1.5v Start_point = -0.7v End_point = +0.5v Slope TABLE |variable typ min max 0.05/1ns -1.0 -3.5 -1.0 0.25/1ns -0.75 -2.0 -0.05 0.50/1ns -0.01 -0.5 -0.0 0.60/1ns 0.0 0.25 0.0 0.75/1ns 0.0 0.0 0.0 1.00/1ns 0.0 0.0 0.0 2.00/1ns +0.5 +0.2 +1.0 | | |2) Item 2 under General Syntax Rules and Guidelines is modified to include |the following reserved words INF - used when a data value is so large it is considered infinite TABLE - used to indicate that a subparameter's value(s) are part of a table. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This bird originated from discussions held at the January '99 IBIS summit regarding the lack of a way to accurately and realistically specify the input thresholds and dynamic performance of a digital logic receiver. At the mid year '99 IBIS summit D.C. Sessions, Stephen Peters, Richard Mellitz and Arpad Muranyi agreed to meet to hammer out a proposal. This bird is one of the results. The technical basis of this bird derives from simulation work done by Richard Mellitz. Updates to 61.1: Added the Vth subparameter, and changed the definition of the Start_point and End_point parameters to be offsets from Vth. Updated/corrected the examples. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From owner-ibis Tue Dec 28 14:14:26 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 OAA03950; Tue, 28 Dec 1999 14:14:25 -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.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id OAA14232; Tue, 28 Dec 1999 14:13:34 -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 OAA20645; Tue, 28 Dec 1999 14:13:33 -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 NAA20659; Tue, 28 Dec 1999 13:54:56 -0800 (PST) Message-Id: <199912282154.NAA20659@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: BIRD 62.1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Dec 1999 13:54:56 -0800 From: Stephen Peters Hello All: Here is the update to bird62. Regards, Stephen Peters Intel Corp. ======================== Buffer Issue Resolution Document (BIRD) BIRD ID#: 62.1 ISSUE TITLE: Enhanced Specification of Receiver Thresholds REQUESTOR: DC Sessions (Philips), Stephen Peters, Richard Melitz, Arpad Muranyi (Intel Corp). DATE SUBMITTED: Aug 24, 1999, Dec 28, 1999 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: When specifying receiver input thresholds the current specification allows only the traditional DC derived Vinh and Vinl parameters. These two parameters are no longer adequate for describing receivers used for high speed designs. This BIRD proposes four new input switching threshold parameters: Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc. These parameters are referenced to an reference point Vth, and this reference is allowed to vary with variations in a supply. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Model Spec] keyword. |============================================================================= | Keyword: [Receiver Thresholds] | Required: No | Sub-Params: Vth, Vth_min, Vth_max, Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc, | Vth_sensitivity, Input_Ref_Supply | Description: The [Receiver Thresholds] keyword defines both a set of | receiver input thresholds as well as their sensitivity to | variations in a referenced supply. The subparameters are | defined as follows: | | Vth, Vth_min and Vth_max are the ideal input threshold voltage | at which the output of a digital logic receiver changes state. | Vth is the nominal input threshold voltage under the voltage, | temperature and process conditions that define 'typ'. Vth_min | is the minimum input threshold voltage at 'typ' conditions | while Vth_max is the maximum input threshold voltage at 'typ' | conditions. | | Vinh_ac is the voltage that a low-to-high going input waveform | must reach in order to guarantee that the receiver's output | has changed state. In other words, reaching Vinh_ac is | sufficient to guarantee a receiver state change. Vinh_ac is | expressed as an offset from Vth. | | Vinh_dc is the voltage that an input waveform must remain | above (more positive than) in order to guarantee that a | receiver output will NOT change state. Vinh_dc is expressed | as an offset from Vth. | | Vinl_ac is the voltage that a high-to-low going input waveform | must reach in order to guarantee that the receiver's output | has changed state. In other words, reaching Vinl_ac is | sufficient to guarantee a receiver state change. Vinl_ac | is expressed as an offset from Vth. | | Vinl_dc is the voltage that an input waveform must remain below | (more negative than) in order to guarantee that a receiver's | output will NOT change state. Vinh_dc is expressed as a | offset from Vth. | | Vth_sensitivity is a unitless number that specifies how Vth | varies with respect to the supply voltage defined by the | Input_Ref_Supply subparameter. Vth_sensitivity is defined | as: | | change in input threshold voltage | Vth_sensitivity = ------------------------------------ | change in referenced supply voltage | | Vth_sensitivity must be entered as a whole number or | decimal, not as a fraction. | | Input_Ref_Supply indicates which supply voltage Vth tracks; | i.e. it indicates which supply voltage change causes a change | in input threshold. The legal arguments to this subparameter | are VOLTAGE_RANGE (the supply voltage defined by the | [Voltage Range] keyword), PULLUP_REF (the supply voltage | defined by the [Pullup Reference] keyword), or EXT (an | external voltage defined by the [External Reference] keyword). | | | Usage Rules: The [Receiver Thresholds] keyword is valid if the model type | includes any reference to input or I/O. The Vinh_ac, Vinh_dc, | Vinl_ac, Vinh_dc and Vth subparameters are required and | override the Vinh, Vinl, Vinh+/- and Vinl+/- subparameters | declared under the [Model] or [Model Spec] keywords. The | Vth_min, Vth_max, Vth_sensitivity and Input_Ref_Supply | subparameters are optional. However, if the Vth_sensitivity | subparameter is present then the Input_Ref_Supply | subparameter must also be present. | | Vth at Minimum or Maximum Operating Conditions: | As described above, the Vth_min and Vth_max subparameters | define the minimum and maximum input threshold values under | typical operating conditions. There is no provision for | directly specifying Vth under minimum or maximum operating | conditions. Instead, these values are calculated using | the following equation: | | Vth(min/max) = Vth* + [(Vth_sensitivity) X (change in supply voltage)] | | where Vth* is either Vth, Vth_min or Vth_max as appropriate, | and the supply voltage is the one indicated by the | Input_Ref_Supply subparameter. | | | Differential Receivers: | For a single ended receiver the numerical values of Vth, | Vth_min and Vth_max are specified with respect to 0v. | However, if the [Receiver Threshold] keyword is describing | a differential receiver (i.e. is part of a [Model] statement | that describes a pin listed in the [Diff Pin] keyword), then | Vth is typically assigned a value of zero volts and the | Vth_min and Vth_max parameters are not used. The values of | Vinh_* and Vinl_* subparameters are still given as an | offset from Vth and become, in effect, the more traditional | Vdiff. | | Examples: | | A basic 3.3v single ended receiver using only the required | subparameters | Vth = 1.5v Vinh_ac = +225mV Vinh_dc = +100mV Vinl_ac = -225mV Vinl_dc = -100mV | | | A single ended receiver using an external threshold reference. In this | case the input threshold is the external reference voltage so | Vth_sensitivity equals 1. | Vth = 1.0v Vth_sensitivity = 1 Input_Ref_Supply = EXT Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | | A fully specified single ended 3.3v CMOS receiver | Vth = 1.5v Vth_min = 1.45v Vth_max = 1.53v Vth_sensitivity = 0.45 Input_Ref_Supply = VOLTAGE_RANGE Vinh_ac = +200mV Vinh_dc = +100mV Vinl_ac = -200mV Vinl_dc = -100mV | | | A differential receiver | Vth = 0.0v Vinh_ac = +50mV Vinh_dc = +25mV Vinl_ac = -50mV Vinl_dc = -25mV 2) The following new keyword is defined and place in the specification following the [GND Clamp Reference] keyword |============================================================================= | Keyword: [External Reference] | Required: Yes, if a receiver's input threshold is determined by an | external reference voltage | Description: Defines a voltage source that supplies the reference voltage | used by a receiver for its input threshold reference. | Usage Notes: Provide actual voltages (not percentages in the typ, min max | format. "NA" is allowed for the min and max values only. |----------------------------------------------------------------------------- | variable typ min max [External Reference] 1.0v 0.95v 1.05v 3) Under section 2 of General Syntax Rules and Guidelines the following words are added to the list of reserved words. EXT - A reference to a voltage defined by the [External Reference] Keyword VOLTAGE_RANGE - A reference to a voltage defined by the [Voltage Range] keyword PULLUP_REFERENCE - A reference to a voltage defined by the [Pullup Reference] keyword ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: This proposal follows the recommendations of the JC-15 committee for specifying SDRAM inputs. Update for 62.1: Specified exactly which [Model] and [Model Spec] parameters are overridden by [Receiver Threshold] and changed the wording of the "Differential Receivers:" to indicate that the numerical value of Vth is *typically* assigned a value of 0v rather than *must* be assigned a value of zero. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Melitz and Aprad Muranyi of Intel Corp. ******************************************************************************* From owner-ibis Tue Dec 28 14:16:46 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 OAA03973; Tue, 28 Dec 1999 14:16:46 -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.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id OAA14536; Tue, 28 Dec 1999 14:15:57 -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 OAA20925; Tue, 28 Dec 1999 14:15:56 -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 NAA20673; Tue, 28 Dec 1999 13:57:19 -0800 (PST) Message-Id: <199912282157.NAA20673@xtg801.pdx.intel.com> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: BIRD 63.1 -- Documentation of Setup and Hold conditions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Dec 1999 13:57:18 -0800 From: Stephen Peters Hello All: Update to bird 63. Regards, Stephen Peters Intel Corp. =================== Buffer Issue Resolution Document (BIRD) BIRD ID#: 63.1 ISSUE TITLE: Documentation of Receiver Setup and Hold Timing Conditions REQUESTOR: D.C. Sessions (Philips), Stephen Peters, Richard Melitz, Arpad Muranyi (Intel Corp.) DATE SUBMITTED: Sept 8, 1999, Dec 27, 1999 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Currently, the edge rate and overdrive conditions under which a receiver's data book setup and hold timings are specified are not documented. This bird provides a way for the model creator to document those conditions in an IBIS file. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: 1) The following new keyword is defined and placed in the specification just below the [Receiver Spec] keyword. |============================================================================= | Keyword: [Tester Spec] | Required: No | Sub-Params: Tester_Vlow, Tester_Vhigh, Tester_Vth, Tester_Slew_Setup, | Tester_Slew_Hold | Description: The [Tester Spec] keyword documents the input overdrive | and tester slew rate conditions under which a device's | input setup and hold times are specified. The subparameters | are defined as follows: | | Tester_Vth is the point on the input waveform from | which an receivers setup and hold time is referenced. It is | usually the input voltage at which the output of a digital | logic receiver changes state. Tester_Vth is used as the | reference voltage for the Tester_Vlow and Tester_Vhigh | parameters. | | Tester_Vlow represents the starting voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the ending voltage of a | high-to-low going waveform. Tester_Vlow is expressed as an | offset from Tester_Vth. | | Tester_Vhigh represents the ending voltage of the low-to-high | going waveform a tester uses when characterizing a receiver's | setup or hold time. It also represents the starting voltage of | a high-to-low going waveform. Tester_Vhigh is expressed as an | offset from Tester_Vth. | | Tester_Slew_Setup is the tester waveform's slew rate at | which a receiver's setup time is specified. For purposes of | this keyword, slew rate is defined as: | | Tester_Vhigh - (Tester_Vlow) | Slew Rate = ------------------------------------------- | Time it takes to swing the above voltage | | Tester_Slew_Setup must be expressed as an explicit ratio | of voltage over time, and not reduced to a decimal number. | | Tester_Slew_Hold is the tester waveform's slew rate at which | a receiver's hold time is specified. Slew rate is defined | as above. Tester_Slew_Hold must be expressed as an explicit | ratio of voltage over time, and not reduced to a decimal | number. | | | Usage Rules: The [Tester Spec] keyword is valid if the model type | includes any reference to input or I/O. All subparameters | are required to be present. When entering a value the | subparameter argument and the subparameter itself must | be separated by an equals sign (=). | | Differential Receivers: | For a single ended receiver the numerical value of | Tester_Vth is specified with respect to 0v. However, if | the [Tester Spec] keyword is describing a differential receiver | (i.e. is part of a [Model] statement that describes a pin | listed in the [Diff Pin] keyword), then the numerical value of | Tester_Vth is typically given as 0v. Tester_Vlow and | Tester_Vhigh are then assumed to represent the difference in | voltage between one input and the other. | | | A basic 3.3v single ended receiver Tester_Vth = 1.5v Tester_Vlow = -1.0v Tester_Vhigh = 2.5v Tester_Slew_setup = 1v/ns Tester_Slew_hold = 1v/ns | | A differential receiver Tester_Vth = 0V Tester_Vlow = -200mV Tester_Vhigh = +200mV Tester_Slew_setup = 1.2v/1ns Tester_Slew_hold = 1.2v/1ns | | ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Like it's companion BIRD #62, this bird is an attempt to better specify and document a receiver's functionality. It follows the convention of the previous BIRDS in that most of the parameter values are specified as an offset from a reference voltage. This technique supports both single ended and differential receivers. Note that there are separate slew rate entries for setup and hold time. When formulating this bird the authors were not sure if receiver hold time was specified under different slew rate conditions than setup time. Thus, separate slew rate entries. These two parameters can be collapsed into one if further information indicates that this is not the case. Updates for 63.1: Corrected "Tester_Skew" to "Tester_Slew" in the examples (typo correction) and fixed up the Slew_rate equation by removing the absolute value markers. Changed Slew_rate so that it is expressed as an explicit ratio and not as a decimal (following the convention of [Ramp Rate]). Clarified the meaning of Tester_Vth. Finally, under "Differential Receivers:" changed the text to indicate that the numerical value of Tester_Vth is *typically* given as 0v rather than *must* be given as zero. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better specification of receivers. The basic form of this bird was discussed at a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen Peters, Richard Melitz and Aprad Muranyi of Intel Corp. *******************************************************************************