From owner-ibis Mon Dec 2 10:34:25 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA21099 for ; Mon, 2 Dec 1996 10:34:10 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 2 Dec 96 10:22 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 2 Dec 96 10:22 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 2 Dec 96 10:24 PST Message-Id: Date: Mon, 2 Dec 96 10:24 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA 12/6/96 IBIS Open Forum Meeting Agenda for 12/6/96 Bridge Number Reservation # Passcode (916) 356-9200 4-35933 6785885 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions Design SuperCon97 IBIS Meeting Huq s2ibis2 Huq/Ross DAC97 IBIS Meeting Planning (Vote) Rusher IEC Progress Rusher Cookbook Rokusek Model Test Load Recommendations Muranyi New Administrative Issues All 8:50 Technical Discussion BIRD35.2 - MULTI-STAGED OUTPUTS (Vote) Ross Package Committee Report Peters Parser Status Rokusek BIRD40 - OVERSHOOT NOMENCLATURE Ross New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Mon Dec 2 11:24:34 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA21479 for ; Mon, 2 Dec 1996 11:24:34 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA16100 for ; Mon, 2 Dec 1996 11:13:36 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma015757; Mon Dec 2 11:13:06 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA13850 for ibis@vhdl.org; Mon, 2 Dec 96 11:12:40 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA16982; Mon, 2 Dec 96 11:14:12 PST Date: Mon, 2 Dec 96 11:14:12 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9612021914.AA16982@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS Summit Call for Presentation - Jan20th 1997 Cc: huq@rockie.nsc.com, john.goldie@nsc.com, mbristol@rockie.nsc.com IBIS fans, IBIS Summit Call for Presentation Jan20th 1997 Santa Clara, CA ------------------------------------------------------------------------- The ANSI/EIA-656 IBIS Committee will have a summit meeting on Monday Jan20th 1997. The meeting will be hosted by National Semiconductor and details of place,time,directions etc will be provided on a seperate E-mail. This is an open meeting to share information, discuss technical challenges, future directions of IBIS etc. We would like the summit to address experiences, success stories, technical challenges etc from the Users, Model providers, EDA vendors and any interested groups. So, here is the call for presentation. We would like to keep the format similar to the last year's meeting. Meaning, each speaker will get 15 to 20 minutes to present. You do not have to be a member to attend the meeting. Some ideas for topics: * What your company is doing with IBIS * Where you think we need to go with IBIS version 3.0 * New technologies/areas you've tacked with IBIS(RFI,EMC MCM etc) * Customer inputs/feedback * Areas of current exploration(eg. Connector modeling etc) * Model development/validation techniques * Model usage, wishes, shortcomings * Modeling methods(Simulation vs Data derivations) * SPICE vs IBIS questions * Are EDA tools 'IBIS certified', will I get various results based on which tools I use ? * Modeling issues on a complex device(eg. feedback etc) Pls forward your presentation ideas and the amount of time you will need to either Bob Ross(bob@icx.com) Interconnectix Syed Huq(huq@rockie.nsc.com) National Semiconductor Corp Jon Powell(jon@qdt.com) Quad Design We will put an agenda together based on topics to be covered and the number of papers to be presented. Pls send your paper ideas by DEC20th(!). We would like to receive them before the Holidays begin. Also note that, a hardcopy/softcopy of all presentation materials MUST be send to me by Jan6th(!). This will allow National to make 45 sets of copies each to be distributed on meeting day. If you fail to send your paper by Jan6th, then pls carry 45 copies of your presentation along with you. Your active participation can make this summit very successful. We were very pleased with last years participation and I am sure 1997 will be a great summit too. Best Regards, Syed Huq Vice-Chair ANSI/EIA-656 National Semiconductor Corp. From owner-ibis Mon Dec 2 11:32:41 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id LAA21563 for ; Mon, 2 Dec 1996 11:32:40 -0800 (PST) Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbsjt07093; Mon, 2 Dec 1996 14:20:24 -0500 (EST) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 2 Dec 1996 14:20:08 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01198; Mon, 2 Dec 96 11:21:56 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA02825; Mon, 2 Dec 96 11:21:56 PST Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbsjs04742; Mon, 2 Dec 1996 14:13:48 -0500 (EST) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 2 Dec 1996 14:13:33 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00517; Mon, 2 Dec 96 10:11:00 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA01056; Mon, 2 Dec 96 10:10:59 PST Sender: uunet!qdt.com!jonp@uunet.uu.net Message-Id: <32A31BAA.167EB0E7@qdt.com> Date: Mon, 02 Dec 1996 10:10:50 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Stephen Peters Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: 1.x vs 2.x References: <199611270142.RAA12303@ichips.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry if anyone got this twice: Should the 2.1 parser read 1.0 files. We may have a problem with this. As far as ANSI STANDARD 656 is concerned, there is NO 1.x version. IBIS 2.1 is the only ANSI/EIA approved standard and this does not accept 1.0 type model things that conflict with 2.1 terminology. Because of this I really do not believe that anyone should be creating models with 1.0 versioning. If they want to make linear simple 2.1 models, fine, but not old style 1.0 version models. comments? Jon From owner-ibis Mon Dec 2 11:39:26 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id LAA21620 for ; Mon, 2 Dec 1996 11:39:24 -0800 (PST) Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbsjt07098; Mon, 2 Dec 1996 14:20:25 -0500 (EST) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 2 Dec 1996 14:20:09 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01205; Mon, 2 Dec 96 11:22:00 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA02828; Mon, 2 Dec 96 11:22:00 PST Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbsjs04756; Mon, 2 Dec 1996 14:13:50 -0500 (EST) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 2 Dec 1996 14:13:35 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00525; Mon, 2 Dec 96 10:13:14 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA01112; Mon, 2 Dec 96 10:13:14 PST Sender: uunet!qdt.com!jonp@uunet.uu.net Message-Id: <32A31C31.2781E494@qdt.com> Date: Mon, 02 Dec 1996 10:13:05 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Andy Ingraham Cc: uunet!uunet!ccm.fm.intel.com!arpad_muranyi@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: Use of femto scaling in IBIS models References: <9611271333.AA07842@us1rmc.bb.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > At one time we were debating whether in cases like this, when the parser didn't > > agree with the spec, which one should take precedence. If I remember correctly > > we voted for the parser. In this light, the Intel models are not illegal. > > (Someone correct me if I am wrong). > > I don't question what may have have been previously discussed ... but > in my mind the only correct answer is that the spec ALWAYS takes > precedence, no matter what you're talking about. If the spec and the > parser disagree, you fix the parser. We did vote to make the parser the spec. But when we went for ANSI standarization, the whole "the parser is the spec" thing went out the window. Now the voted spec is the bible and the parser must be changed or considered wrong. (this is my opinion but I bet that ANSI/EIA would hold us to this). Jon From owner-ibis Mon Dec 2 14:37:42 1996 Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA23007 for ; Mon, 2 Dec 1996 14:37:41 -0800 (PST) Received: from ormail.intel.com by relay7.UU.NET with ESMTP (peer crosschecked as: ormail.intel.com [134.134.248.3]) id QQbskf21468; Mon, 2 Dec 1996 17:20:58 -0500 (EST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.3/8.7.3) with ESMTP id OAA00507; Mon, 2 Dec 1996 14:20:36 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.8.2/8.7.3) id OAA05895; Mon, 2 Dec 1996 14:20:34 -0800 (PST) Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Mon, 02 Dec 96 14:20:33 PST Date: Mon, 02 Dec 96 14:35:00 PST From: Will Hobbs Message-ID: To: owner-ibis@vhdl.org, uunet!uunet!wrksys.ENET.dec.com!ingraham@uunet.uu.net cc: uunet!uunet!ccm.fm.intel.com!arpad_muranyi@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re[2]: Use of femto scaling in IBIS models Text item: Jon, et al, I sent out a message in complete agreement with this a couple of weeks ago, but it apparently bounced. Here is what I said: I know that early on we talked of the parser as the "executable spec," but since we have gone through formal balloting, etc., of IBIS as an ANSI EIA specification, the written spec is the spec. Period. The parser should be as faithful to that spec as possible. Regards, Will > > At one time we were debating whether in cases like this, when the parser didn't > > agree with the spec, which one should take precedence. If I remember correctly > > we voted for the parser. In this light, the Intel models are not illegal. > > (Someone correct me if I am wrong). > > I don't question what may have have been previously discussed ... but > in my mind the only correct answer is that the spec ALWAYS takes > precedence, no matter what you're talking about. If the spec and the > parser disagree, you fix the parser. We did vote to make the parser the spec. But when we went for ANSI standarization, the whole "the parser is the spec" thing went out the window. Now the voted spec is the bible and the parser must be changed or considered wrong. (this is my opinion but I bet that ANSI/EIA would hold us to this). Jon Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii References: <9611271333.AA07842@us1rmc.bb.dec.com> Subject: Re: Use of femto scaling in IBIS models Cc: uunet!uunet!ccm.fm.intel.com!arpad_muranyi@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net To: Andy Ingraham Mime-Version: 1.0 X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) From: Jon Powell Date: Mon, 02 Dec 1996 10:13:05 -0800 Message-Id: <32A31C31.2781E494@qdt.com> Sender: uunet!qdt.com!jonp@uunet.uu.net Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA01112; Mon, 2 Dec 96 10:13:14 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00525; Mon, 2 Dec 96 10:13:14 PST Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 2 Dec 1996 14:13:35 -0500 Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbsjs04756; Mon, 2 Dec 1996 14:13:50 -0500 (EST) Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA02828; Mon, 2 Dec 96 11:22:00 PST Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01205; Mon, 2 Dec 96 11:22:00 PST Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 2 Dec 1996 14:20:09 -0500 Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbsjt07098; Mon, 2 Dec 1996 14:20:25 -0500 (EST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8. 7.3/8.7.3) with ESMTP id LAA21620 for ; Mon, 2 Dec 1996 11:39:24 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.3/8.7.3) with ESMTP id MAA15864; Mon, 2 Dec 1996 12:30:27 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id MAA12786; Mon, 2 Dec 1996 12:2 7:54 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Mon Dec 2 16:49:07 1996 Received: from c11167-343dan.ece.ncsu.edu (c11167-343dan.ece.ncsu.edu [152.1.59.242]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA23970; Mon, 2 Dec 1996 16:49:06 -0800 (PST) From: awglaser@eos.ncsu.edu Received: by c11167-343dan.ece.ncsu.edu (8.6.9/EC06jan95) id TAA02658; Mon, 2 Dec 1996 19:37:58 -0500 Message-Id: <199612030037.TAA02658@c11167-343dan.ece.ncsu.edu> Subject: New version of s2ibis2 To: ibis-users@vhdl.org, ibis@vhdl.org Date: Mon, 2 Dec 1996 19:37:57 -0500 (EST) X-Mailer: ELM [version 2.4 PL24/POP] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit IBISGurus: The v1.0 release of s2ibis2 is now available. This version fixes many bugs, and implements several new features. There are also new examples of how to use the various commands. The new version of s2ibis2 can be obtained via ftp at ftp://ftp.vhdl.org/pub/ibis/s2ibis/s2ibis2_v1.0 as well as ftp://ftp.eos.ncsu.edu/pub/vlsi/techreports/s2ibis2.tar.Z It can also be obtained using a Web browser at http://www2.ncsu.edu/eos/project/erl_html/erl_software.html#s2ibis2 (Click on "S2ibis2" to download.) Questions and comments are welcome; send them to awglaser@eos.ncsu.edu. Regards, -- Alan Glaser "It's not a competition, ECE Dept. it's just a mint..." - K North Carolina State University From owner-ibis Tue Dec 3 12:58:49 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA20079 for ; Tue, 3 Dec 1996 12:58:48 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id MAA15316 for ; Tue, 3 Dec 1996 12:47:47 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma015203; Tue Dec 3 12:47:37 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA19794 for ibis@vhdl.org; Tue, 3 Dec 96 12:47:10 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA17589; Tue, 3 Dec 96 12:48:40 PST Date: Tue, 3 Dec 96 12:48:40 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9612032048.AA17589@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS face to face meeting Jan20th'97- Details ! Cc: huq@rockie.nsc.com IBIS fans: ANSI/EIA-656 (IBIS) Summit 1997 Place: Westin Hotel (Santa Cruz conference Room - 1st floor) 5101 Great America Parkway Santa Clara, California (408)986-0700 Date: Jan 20th Monday(one day) Time: 8am - 5pm National Semiconductor will host the meeting. For those of you who attended last year's meeting, this is the same location. Since breakfast and lunch will be provided, we need to get a headcount. Pls RSVP to me by Jan3rd 1997 !!!! Non-members of ANSI/EIA can attend but membership to the ANSI/EIA-656 is highly recommended. Westin Hotel is connected to the Santa Clara Convention Center, the site for Design SuperCon97(http://www.supercon.com). Design SuperCon is from Tue(21st) through Thurs(23rd). You can save some registration fee by registering before Jan3rd 1997. Directions: ----------- >From San Jose Airport: ---------------------- Take Guadalupe Expressway to '101 San Francisco' Exit 'Great America Parkway' (turn right on exit) Westin Hotel is at the corner of Tasman and Great America Parkway. Santa Clara Convention Center(Design SuperCon'97) and Westin Hotel are next to each other. >From San Francisco Airport: --------------------------- Take '101 San Jose' Exit Great America Parkway Westin Hotel is at the corner of Tasman and Great America Parkway. Hotel Information: ------------------- "Pls make your reservations as soon as possible. Certain Hotels tend to fill up due to various events going on." Wyndham Garden Hotel 1300 Chesapeake Terrace Sunnyvale (408)747-0999 Santa Clara Marriott Hotel 2700 Mission College Blvd Santa Clara (408)988-1500 Quality Suites 3100 Lakeside Drive Santa Clara (408)748-9800 Days Inn 4200 Great America Parkway Santa Clara (408)980-1525 Westin Hotel 5101 Great America Parkway Santa Clara (408)986-0700 Embassy Suites 2885 Lakeside Drive Santa Clara (408)496-6400 If you need any other assistance or questions you may have, let me know. Best Regards, Syed. Vice-Chair ANSI/EIA-656 National Semiconductor Corp. (408)721-4874 From owner-ibis Wed Dec 4 10:29:02 1996 Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA15901 for ; Wed, 4 Dec 1996 10:29:02 -0800 (PST) Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id NAA16641 for ; Wed, 4 Dec 1996 13:17:44 -0500 Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma016516; Wed Dec 4 13:16:38 1996 Received: from classical.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA01814; Wed, 4 Dec 96 13:22:43 EST Received: (from kweldon@localhost) by classical.ctron.com (8.6.12/8.6.12) id NAA05183 for ibis@vhdl.org; Wed, 4 Dec 1996 13:16:57 -0500 Date: Wed, 4 Dec 1996 13:16:57 -0500 From: Kevin Weldon Message-Id: <199612041816.NAA05183@classical.ctron.com> To: ibis@vhdl.org Subject: High Frequency Limit Hello IBIS fans, I was wondering if you could inform me of the high frequency limit of the current IBIS model and what forces these limits on the model. Thank You Kevin Weldon From owner-ibis Wed Dec 4 11:08:58 1996 Received: from stout.cisco.com (stout.cisco.com [171.69.1.157]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA16285 for ; Wed, 4 Dec 1996 11:08:58 -0800 (PST) Received: from ajit-pc.cisco.com (ajit-pc.cisco.com [171.69.20.14]) by stout.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id KAA14007 for ; Wed, 4 Dec 1996 10:57:17 -0800 Message-Id: <2.2.32.19961204185540.006ed06c@stout.cisco.com> X-Sender: akulkarn@stout.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 10:55:40 -0800 To: ibis@vhdl.org From: Ajit Kulkarni Subject: subscribe Please add me to the reflector. Ajit Kulkarni ------------- From owner-ibis Wed Dec 4 13:40:40 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA17598; Wed, 4 Dec 1996 13:40:39 -0800 (PST) Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA08918; Wed, 4 Dec 96 13:30:45 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA00584; Wed, 4 Dec 96 13:30:44 PST Date: Wed, 4 Dec 96 13:30:44 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9612042130.AA00584@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Help: Programable outputs Ibis folks, I guess this question is mainly aimed at the simulation vendor folks, but feedback is welcome from everyone: (Our products are programmable logic devices, for those who are not familiar with Actel) For a component that has a programable behavior for the I/O pins, what might be the preferred way of presenting the data for the different possible configurations? Specifically, let's say that a pin can be programmed to be either: 1) Tristateable I/O with a fast slew rate 2) " " " " slow slew rate 3) Open Drain output (data input to the output buffer is programmed to be tied to the enable of the buffer) Would it be better to actually make a main IBIS file that contains all of the I/Os in condition (1), with 2 extra IBIS files that contain only one pin in them each for conditions (2) and (3)? Or, perhaps only make one IBIS file with all of the pins configured in condition (1) and commented out sections for conditions (2) and (3). Or, even another possibility of dividing the I/Os into 3 equal sections, one for each configuration? All comments/suggestions welcome, and please forgive me if this has been discussed already. Thanks, -Scott Schlachter scotts@actel.com Actel Corporation Sunnyvale, CA. From owner-ibis Wed Dec 4 16:39:23 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA18963; Wed, 4 Dec 1996 16:39:22 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id QAA09939; Wed, 4 Dec 1996 16:28:26 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma009697; Wed Dec 4 16:28:00 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA05990 for ibis@vhdl.org; Wed, 4 Dec 96 16:27:34 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA22056; Wed, 4 Dec 96 16:29:10 PST Date: Wed, 4 Dec 96 16:29:10 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9612050029.AA22056@rockie.nsc.com> To: ibis@vhdl.org, ibis-users@vhdl.org, scotts@actel.com Subject: Re: Help: Programable outputs Scott, I have a device with a programmble slew rate spec. Slew rate is controlled by an external pin tied to a variable resistor. There are may ways to do this until we see Arpad's BIRD30.2(Programmable Buffer)in IBIS3.0. So,we have to figure work arounds til then. I added ALL the possible buffer combinations in ONE IBIS model file. THen thru the pin list, I comment out the model names I do not need to run. This manual commenting and uncommenting of model names need to be explained up on top under [Notes] for a customer to understand what to do. Best Regards, Syed. National Semiconductor Corp. > > For a component that has a programable behavior for the I/O pins, what > might be the preferred way of presenting the data for the different > possible configurations? Specifically, let's say that a pin can be > programmed to be either: > 1) Tristateable I/O with a fast slew rate > 2) " " " " slow slew rate > 3) Open Drain output (data input to the output buffer is > programmed to be tied to the enable of the buffer) > > Would it be better to actually make a main IBIS file that contains all > of the I/Os in condition (1), with 2 extra IBIS files that contain only > one pin in them each for conditions (2) and (3)? Or, perhaps only make > one IBIS file with all of the pins configured in condition (1) and > commented out sections for conditions (2) and (3). Or, even another > possibility of dividing the I/Os into 3 equal sections, one for each > configuration? All comments/suggestions welcome, and please forgive me > if this has been discussed already. Thanks, From owner-ibis Wed Dec 4 17:41:32 1996 Received: from mailsorter-2.alma.webtv.net (mailsorter-2.isp.alma.webtv.net [205.180.153.86]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id RAA19405 for ; Wed, 4 Dec 1996 17:41:31 -0800 (PST) Received: from mailtod-1.alma.webtv.net (mailtod-1.iap.alma.webtv.net [207.76.180.81]) by mailsorter-2.alma.webtv.net (8.7.5/8.7.3) with ESMTP id RAA27316 for ; Wed, 4 Dec 1996 17:30:24 -0800 (PST) Received: (from production@localhost) by mailtod-1.alma.webtv.net (8.7.5/8.7.3) id RAA13142; Wed, 4 Dec 1996 17:30:23 -0800 (PST) Message-Id: <199612050130.RAA13142@mailtod-1.alma.webtv.net> From: BBY299@webtv.net (best buy 299) Date: Wed, 4 Dec 1996 20:30:22 -0500 To: ibis@vhdl.org Subject: IBIS Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 (WebTV 1.0) subscribe me pleeze to ibis From owner-ibis Wed Dec 4 17:47:46 1996 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id RAA19468 for ; Wed, 4 Dec 1996 17:47:45 -0800 (PST) Received: (from kellee@localhost) by montana.nwlink.com (8.8.2/8.7.3) id RAA10882; Wed, 4 Dec 1996 17:36:36 -0800 (PST) Message-Id: <3.0.32.19961204172727.0070edf0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Dec 1996 17:27:29 -0800 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Programable slew outputs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Scott, Syed, IBIS >> Would it be better to actually make a main IBIS file that contains all >> of the I/Os in condition (1), with 2 extra IBIS files that contain only >> one pin in them each for conditions (2) and (3)? Or, perhaps only make >> one IBIS file with all of the pins configured in condition (1) and >> commented out sections for conditions (2) and (3). Or, even another >> possibility of dividing the I/Os into 3 equal sections, one for each >> configuration? All comments/suggestions welcome, and please forgive me >> if this has been discussed already. Thanks, > If the device has many (more than 2) options than I like one file with several options commented out, the default option being the most commonly used. If the device has only 2 options (e.g. slow/fast) than 2 separate IBIS files might be a reasonable choice. The comment field should explain what's going on to the user. It is also important that the default choice at least work and not be dead or unreasonable. Some of the IBIS models we have seen have the default be something that prevents the model from being used or is designed to alert the customer that it is dead. It is my experience that this simply frustrates the customers into thinking the model is completely broken. It is better to have them come back after they see reasonable working results and question how to change it. Kellee, HyperLynx. --------------------------------------------------------------- Have a great day...Kellee Crisafulli, HyperLynx Inc. --------------------------------------------------------------- From owner-ibis Wed Dec 4 18:12:26 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id SAA19674; Wed, 4 Dec 1996 18:12:26 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 5 Dec 1996 02:01:17 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id RAA02957; Wed, 4 Dec 1996 17:58:56 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 04 Dec 96 17:58:56 PST Date: Wed, 04 Dec 96 14:28:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Help: Programable outputs Text item: Scott, BIRD30.2 addresses the problem you have. Hopefully it will be implemented in IBIS3.0 soon. Untill then, in our models we use comments. Spceifically, I put everything that is legal in BIRD30.2 into the IBIS file with comment characters in front of each line. This and an explanation gives enough information to the user to know how to edit the IBIS file for the various conditions. When IBIS3.0 arrives, all they need to do is to rmove the comment characters. Arpad =============================================================================== Ibis folks, I guess this question is mainly aimed at the simulation vendor folks, but feedback is welcome from everyone: (Our products are programmable logic devices, for those who are not familiar with Actel) For a component that has a programable behavior for the I/O pins, what might be the preferred way of presenting the data for the different possible configurations? Specifically, let's say that a pin can be programmed to be either: 1) Tristateable I/O with a fast slew rate 2) " " " " slow slew rate 3) Open Drain output (data input to the output buffer is programmed to be tied to the enable of the buffer) Would it be better to actually make a main IBIS file that contains all of the I/Os in condition (1), with 2 extra IBIS files that contain only one pin in them each for conditions (2) and (3)? Or, perhaps only make one IBIS file with all of the pins configured in condition (1) and commented out sections for conditions (2) and (3). Or, even another possibility of dividing the I/Os into 3 equal sections, one for each configuration? All comments/suggestions welcome, and please forgive me if this has been discussed already. Thanks, -Scott Schlachter scotts@actel.com Actel Corporation Sunnyvale, CA. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Help: Programable outputs To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9612042130.AA00584@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Wed, 4 Dec 96 13:30:44 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA00584; Wed, 4 Dec 96 13:30:44 PST Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA08918; Wed, 4 Dec 96 13:30:45 PST Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8 .7.3/8.7.3) with SMTP id NAA17598; Wed, 4 Dec 1996 13:40:39 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.8.3/8.7.3) with ESMTP id NAA19804; Wed, 4 Dec 1996 13:36:55 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.8.2/8.7.3) with ESMTP id NAA10202; Wed, 4 Dec 1996 13:37:03 -0800 (P ST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Thu Dec 5 17:45:16 1996 Received: from netcomsv.netcom.com (uucp6.netcom.com [163.179.3.6]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA16316; Thu, 5 Dec 1996 17:45:16 -0800 (PST) Received: from symdes.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id RAA22230; Thu, 5 Dec 1996 17:01:55 -0800 Received: from taress.symmetry by symmetry.com (4.1/SMI-4.1) id AA15758; Thu, 5 Dec 96 16:59:01 PST Date: Thu, 5 Dec 96 16:59:01 PST From: zheng@symmetry.com (Zheng SHI) Message-Id: <9612060059.AA15758@ symmetry.com> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Questions of Polarity and Enable Hi, Ibis folks: Can anyone tell me what the sub-param Polarity and Enable of keyword [Model] really means? Is Polarity used only on diff pins? Is Enable used only on tri-state pins? How can I decide the Polarity and Enable of an input or output pin? I can't find such detail information from IBIS2.1 Specification, can anyone give me some advices, or tell me where i can find the answer? Thanks a lot, -Zheng Shi zheng@symmetry.com Los Altos, CA. From owner-ibis Fri Dec 6 11:18:12 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA10719 for ; Fri, 6 Dec 1996 11:18:12 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA21325 for ; Fri, 6 Dec 1996 11:07:15 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma020951; Fri Dec 6 11:06:44 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA00177 for ibis@vhdl.org; Fri, 6 Dec 96 11:06:08 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA13060; Fri, 6 Dec 96 11:07:42 PST Date: Fri, 6 Dec 96 11:07:42 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9612061907.AA13060@rockie.nsc.com> To: ibis@vhdl.org Subject: Who is using these ? Hi, This is an open question to ANY Model provider: Is anyone providing model data on the parameters mentioned below ? If yes, Can you pls send me an E-mail, I would like to understand how they are used. If NO reponse is received, my assumptions would be, even though these keywords are part of the IBISv2.1 spec, they are not being used at all. [Package Model] Defines package param in Matrix format [Pin Mapping] [Pullup Reference] [Pulldown Reference] [POWER Clamp Reference] [GND Clamp Reference] [Rgnd] [Rpower] [Rac] [Cac] Defines a Terminator Model Regards, Syed National Semiconductor Corp. From owner-ibis Fri Dec 6 12:04:52 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA11105 for ; Fri, 6 Dec 1996 12:04:51 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.7.3) with ESMTP id LAA26956 for ; Fri, 6 Dec 1996 11:53:38 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id LAA24742; Fri, 6 Dec 1996 11:51:58 -0800 (PST) Message-Id: <199612061951.LAA24742@ichips.intel.com> To: ibis@vhdl.org Subject: Who is using these ? Date: Fri, 06 Dec 1996 11:53:41 -0800 From: Stephen Peters Hello Syed: We use the following as shown below. Regards, Stephen Peters Intel Corp. [Package Model] NO [Pin Mapping] NO [Pullup Reference] YES [Pulldown Reference] NO [POWER Clamp Reference] YES [GND Clamp Reference] NO [Rgnd] [Rpower] [Rac] [Cac] NO Hi, This is an open question to ANY Model provider: Is anyone providing model data on the parameters mentioned below ? If yes, Can you pls send me an E-mail, I would like to understand how they are used. If NO reponse is received, my assumptions would be, even though these keywords are part of the IBISv2.1 spec, they are not being used at all. [Package Model] Defines package param in Matrix format [Pin Mapping] [Pullup Reference] [Pulldown Reference] [POWER Clamp Reference] [GND Clamp Reference] [Rgnd] [Rpower] [Rac] [Cac] Defines a Terminator Model Regards, Syed National Semiconductor Corp. From owner-ibis Fri Dec 6 12:55:58 1996 Received: from user1.channel1.com (user1.channel1.com [199.1.13.9]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA11489 for ; Fri, 6 Dec 1996 12:55:56 -0800 (PST) Received: from pc-port.viewlogic.com (pc-port.viewlogic.com [139.181.3.106]) by user1.channel1.com (8.6.12/8.6.9) with SMTP id PAA17979; Fri, 6 Dec 1996 15:45:02 -0500 Received: by pc-port.viewlogic.com with Microsoft Mail id <01BBE38C.0A953DA0@pc-port.viewlogic.com>; Fri, 6 Dec 1996 15:42:09 -0500 Message-ID: <01BBE38C.0A953DA0@pc-port.viewlogic.com> From: Haruny To: "'Syed Huq'" , "ibis@vhdl.org" Subject: RE: Who is using these ? Date: Fri, 6 Dec 1996 15:42:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [Package Model] Yes... sometimes [Pin Mapping] No [Pullup Reference] Yes [Pulldown Reference] Yes [POWER Clamp Reference] Yes [GND Clamp Reference] Yes [Rgnd] [Rpower] [Rac] [Cac] Yes ---------- From: Syed Huq[SMTP:huq@rockie.nsc.com] Sent: Friday, December 06, 1996 2:07 PM To: ibis@vhdl.org Subject: Who is using these ? Hi, This is an open question to ANY Model provider: Is anyone providing model data on the parameters mentioned below ? If yes, Can you pls send me an E-mail, I would like to understand how they are used. If NO reponse is received, my assumptions would be, even though these keywords are part of the IBISv2.1 spec, they are not being used at all. [Package Model] Defines package param in Matrix format [Pin Mapping] [Pullup Reference] [Pulldown Reference] [POWER Clamp Reference] [GND Clamp Reference] [Rgnd] [Rpower] [Rac] [Cac] Defines a Terminator Model Regards, Syed National Semiconductor Corp. From owner-ibis Fri Dec 6 13:56:51 1996 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA11975 for ; Fri, 6 Dec 1996 13:56:50 -0800 (PST) Received: from wpgate.cae.ca by bhole with SMTP (DuhMail/2.0) id QAA12520; Fri, 6 Dec 1996 16:38:27 -0500 Received: from CAE_Montreal-Message_Server by wpgate.cae.ca with Novell_GroupWise; Fri, 06 Dec 1996 16:38:15 -0400 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Fri, 06 Dec 1996 16:38:36 -0400 From: Real Mongrain To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Who is using these ? -Reply Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Syed, I can tell you that there's a big difference between simulation results using a model having the [Pin Mapping] field and the same model without any pin mapping. Of course the simulator have to support it. Most of the model i got don't have the Pin Mapping field and i have to add it to the model because it gives more accurate results in multi-line simulations. Real Mongrain Jr. CAE Electronics Ltd. >>> Syed Huq 12/06/96 03:07pm >>> Hi, This is an open question to ANY Model provider: Is anyone providing model data on the parameters mentioned below ? If yes, Can you pls send me an E-mail, I would like to understand how they are used. If NO reponse is received, my assumptions would be, even though these keywords are part of the IBISv2.1 spec, they are not being used at all. [Package Model] Defines package param in Matrix format [Pin Mapping] [Pullup Reference] [Pulldown Reference] [POWER Clamp Reference] [GND Clamp Reference] [Rgnd] [Rpower] [Rac] [Cac] Defines a Terminator Model Regards, Syed National Semiconductor Corp. From owner-ibis Fri Dec 6 14:42:44 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA12385; Fri, 6 Dec 1996 14:42:43 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.7.3) with ESMTP id OAA27682; Fri, 6 Dec 1996 14:31:30 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id OAA11827; Fri, 6 Dec 1996 14:29:50 -0800 (PST) Message-Id: <199612062229.OAA11827@ichips.intel.com> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Questions of Polarity and Enable Date: Fri, 06 Dec 1996 14:31:33 -0800 From: Stephen Peters On Thu, 5 Dec 96 16:59:01 PST Zheng Shi of Symmetry wrote: >Hi, Ibis folks: > >Can anyone tell me what the sub-param Polarity and Enable of >keyword [Model] really means? Is Polarity used only on diff >pins? Is Enable used only on tri-state pins? How can I decide >the Polarity and Enable of an input or output pin? > >I can't find such detail information from IBIS2.1 Specification, >can anyone give me some advices, or tell me where i can find >the answer? > >Thanks a lot, > >-Zheng Shi > zheng@symmetry.com > Los Altos, CA. I belive the original intent was to support SSI logic components (74OO series TTL and the like) by allowing the user to include information on the outputs' logic operation. For example, the model provider could specify if the the path from input to output was inverting or non-inverting or if the enable on a tri-state output pin was high or low. However, for a lot of components (microprocessors, PALS/FPGAS, RAMS, etc.) these parameters don't seem to make much sense (to me, anyway). Unless you were modeling an SSI component where this made since, I would just default them to positive polarity and Active_high. Ibis old-timmers, any other comments? Best Regards, Stephen Peters Intel Corp. From owner-ibis Fri Dec 6 16:04:46 1996 Received: from netcomsv.netcom.com (uucp9.netcom.com [163.179.3.9]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA13221 for ; Fri, 6 Dec 1996 16:04:45 -0800 (PST) Received: from symdes.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA29638; Fri, 6 Dec 1996 15:31:13 -0800 Received: from symcom by symmetry.com (4.1/SMI-4.1) id AA17569; Fri, 6 Dec 96 15:24:59 PST Message-Id: <9612062324.AA17569@ symmetry.com> Received: by symcom (1.39.111.2/16.2) id AA136224552; Fri, 6 Dec 1996 15:22:32 -0800 Date: Fri, 6 Dec 1996 15:22:32 -0800 From: Cathy XU To: ibis@vhdl.org, huq@rockie.nsc.com Subject: Re: Who is using these ? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: waeiYYf3D/HEt8elnc57FA== Hi, We use [GND Clamp Reference] and [Power Clamp Reference] for PECL and ECL buffer models. Cathy Xu Symmetry Design Systems > From owner-ibis@vhdl.vhdl.org Fri Dec 6 13:01 MST 1996 > Received: from symdes by hp715 with SMTP (1.38.193.4/16.2) id AA14124; Fri, 6 Dec 1996 13:01:44 -0700 > Return-Path: > Received: by symmetry.com (4.1/SMI-4.1) id AA17180; Fri, 6 Dec 96 12:04:38 PST > Received: from vhdl.vhdl.org by netcomsv.netcom.com with ESMTP (8.6.12/SMI-4.1) id LAA21054; Fri, 6 Dec 1996 11:11:32 -0800 > Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA10719 for ; Fri, 6 Dec 1996 11:18:12 -0800 (PST) > Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id LAA21325 for ; Fri, 6 Dec 1996 11:07:15 -0800 > Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma020951; Fri Dec 6 11:06:44 1996 > Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA00177 for ibis@vhdl.org; Fri, 6 Dec 96 11:06:08 -0800 > Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA13060; Fri, 6 Dec 96 11:07:42 PST > Date: Fri, 6 Dec 96 11:07:42 PST > From: huq@rockie.nsc.com (Syed Huq) > Message-Id: <9612061907.AA13060@rockie.nsc.com> > To: ibis@vhdl.org > Subject: Who is using these ? > Content-Length: 612 > Status: RO > > Hi, > > This is an open question to ANY Model provider: > > Is anyone providing model data on the parameters mentioned below ? > > If yes, Can you pls send me an E-mail, I would like to understand > how they are used. > > If NO reponse is received, my assumptions would be, even though these > keywords are part of the IBISv2.1 spec, they are not being used at all. > > [Package Model] Defines package param in Matrix format > [Pin Mapping] > [Pullup Reference] > [Pulldown Reference] > [POWER Clamp Reference] > [GND Clamp Reference] > [Rgnd] [Rpower] [Rac] [Cac] Defines a Terminator Model > > Regards, > Syed > National Semiconductor Corp. > > From owner-ibis Fri Dec 6 15:20:28 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA12718; Fri, 6 Dec 1996 15:20:27 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id PAA21486; Fri, 6 Dec 1996 15:09:31 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma021365; Fri Dec 6 15:09:21 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA26257 for ibis@vhdl.org; Fri, 6 Dec 96 15:08:53 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA18011; Fri, 6 Dec 96 15:10:30 PST Date: Fri, 6 Dec 96 15:10:30 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9612062310.AA18011@rockie.nsc.com> To: ibis@vhdl.org, ibis-users@vhdl.org, sjpeters@ichips.intel.com Subject: Re: Questions of Polarity and Enable Hi, If you are creating an IBIS model based on s2ibis utility, Polarity and Enable are key in making the conversion work. For Model_type Input, Polarity=1 sets the input for inverting while Polarity=0 for non-inverting. For Model_type I/O or 3-state, both Polarity and Enable fields are expected. Enable specifies the pin number that enables the associated output. Regards, Syed National Semiconductor Corp. > > > On Thu, 5 Dec 96 16:59:01 PST Zheng Shi of Symmetry wrote: > > >Hi, Ibis folks: > > > >Can anyone tell me what the sub-param Polarity and Enable of > >keyword [Model] really means? Is Polarity used only on diff > >pins? Is Enable used only on tri-state pins? How can I decide > >the Polarity and Enable of an input or output pin? > > > >I can't find such detail information from IBIS2.1 Specification, > >can anyone give me some advices, or tell me where i can find > >the answer? > > > >Thanks a lot, > > > >-Zheng Shi > > zheng@symmetry.com > > Los Altos, CA. > > I belive the original intent was to support SSI logic components > (74OO series TTL and the like) by allowing the user to include > information on the outputs' logic operation. For example, the model provider > could specify if the the path from input to output was inverting or > non-inverting or if the enable on a tri-state output pin was high or > low. However, for a lot of components (microprocessors, PALS/FPGAS, RAMS, > etc.) these parameters don't seem to make much sense (to me, anyway). Unless > you were modeling an SSI component where this made since, I would > just default them to positive polarity and Active_high. > > Ibis old-timmers, any other comments? > > Best Regards, > Stephen Peters > Intel Corp. > > From owner-ibis Fri Dec 6 16:28:45 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA13551 for ; Fri, 6 Dec 1996 16:28:45 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.7.3) with ESMTP id QAA17582 for ; Fri, 6 Dec 1996 16:17:31 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id QAA23388; Fri, 6 Dec 1996 16:15:50 -0800 (PST) Message-Id: <199612070015.QAA23388@ichips.intel.com> To: ibis@vhdl.org Subject: RE: Who is using these ? Date: Fri, 06 Dec 1996 16:17:33 -0800 From: Stephen Peters Hello Syed: We use the following: [Package Model] NO [Pin Mapping] NO [Pullup Reference] YES [Pulldown Reference] NO [POWER Clamp Reference] YES [GND Clamp Reference] NO [Rgnd] [Rpower] [Rac] [Cac] NO Regards, Stephen Peters Intel Corp. From owner-ibis Fri Dec 6 16:41:52 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA13723; Fri, 6 Dec 1996 16:41:51 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Sat, 7 Dec 1996 00:30:41 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id QAA28099; Fri, 6 Dec 1996 16:28:18 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 06 Dec 96 16:28:18 PST Date: Fri, 06 Dec 96 15:44:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Questions of Polarity and Enable Text item: Stephen, and Zheng, If the use of the Polarity (and other) sub-parameter doesn't make sense, don't use it. It is not a required sub-parameter. Arpad =============================================================================== On Thu, 5 Dec 96 16:59:01 PST Zheng Shi of Symmetry wrote: >Hi, Ibis folks: > >Can anyone tell me what the sub-param Polarity and Enable of >keyword [Model] really means? Is Polarity used only on diff >pins? Is Enable used only on tri-state pins? How can I decide >the Polarity and Enable of an input or output pin? > >I can't find such detail information from IBIS2.1 Specification, >can anyone give me some advices, or tell me where i can find >the answer? > >Thanks a lot, > >-Zheng Shi > zheng@symmetry.com > Los Altos, CA. I belive the original intent was to support SSI logic components (74OO series TTL and the like) by allowing the user to include information on the outputs' logic operation. For example, the model provider could specify if the the path from input to output was inverting or non-inverting or if the enable on a tri-state output pin was high or low. However, for a lot of components (microprocessors, PALS/FPGAS, RAMS, etc.) these parameters don't seem to make much sense (to me, anyway). Unless you were modeling an SSI component where this made since, I would just default them to positive polarity and Active_high. Ibis old-timmers, any other comments? Best Regards, Stephen Peters Intel Corp. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. From: Stephen Peters Date: Fri, 06 Dec 1996 14:31:33 -0800 Subject: Questions of Polarity and Enable To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <199612062229.OAA11827@ichips.intel.com> Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id OAA11827; Fri, 6 Dec 1996 14:29:50 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.in tel.com (8.8.4/8.7.3) with ESMTP id OAA27682; Fri, 6 Dec 1996 14:31:30 -0800 (PS T) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl. org (8.7.3/8.7.3) with ESMTP id OAA12385; Fri, 6 Dec 1996 14:42:43 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.8.4/8.7.3) with ESMTP id OAA28257; Fri, 6 Dec 1996 14:34:13 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.8.2/8.7.3) with ESMTP id OAA17422; Fri, 6 Dec 1996 14:34:14 -0800 (P ST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Fri Dec 6 16:42:19 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA13728; Fri, 6 Dec 1996 16:42:18 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Sat, 7 Dec 1996 00:31:09 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id QAA28139; Fri, 6 Dec 1996 16:28:45 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 06 Dec 96 16:28:45 PST Date: Fri, 06 Dec 96 15:47:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re[2]: Questions of Polarity and Enable Text item: Syed, Again, these sub-parameters are not required in IBIS. They may be used in the s2ibis conversion tool, but IBIS doesn't require them, so people don't have to use them if it doesn't make sense for them. Arpad ============================================================================== Hi, If you are creating an IBIS model based on s2ibis utility, Polarity and Enable are key in making the conversion work. For Model_type Input, Polarity=1 sets the input for inverting while Polarity=0 for non-inverting. For Model_type I/O or 3-state, both Polarity and Enable fields are expected. Enable specifies the pin number that enables the associated output. Regards, Syed National Semiconductor Corp. > > > On Thu, 5 Dec 96 16:59:01 PST Zheng Shi of Symmetry wrote: > > >Hi, Ibis folks: > > > >Can anyone tell me what the sub-param Polarity and Enable of > >keyword [Model] really means? Is Polarity used only on diff > >pins? Is Enable used only on tri-state pins? How can I decide > >the Polarity and Enable of an input or output pin? > > > >I can't find such detail information from IBIS2.1 Specification, > >can anyone give me some advices, or tell me where i can find > >the answer? > > > >Thanks a lot, > > > >-Zheng Shi > > zheng@symmetry.com > > Los Altos, CA. > > I belive the original intent was to support SSI logic components > (74OO series TTL and the like) by allowing the user to include > information on the outputs' logic operation. For example, the model provider > could specify if the the path from input to output was inverting or > non-inverting or if the enable on a tri-state output pin was high or > low. However, for a lot of components (microprocessors, PALS/FPGAS, RAMS, > etc.) these parameters don't seem to make much sense (to me, anyway). Unless > you were modeling an SSI component where this made since, I would > just default them to positive polarity and Active_high. > > Ibis old-timmers, any other comments? > > Best Regards, > Stephen Peters > Intel Corp. > > Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Questions of Polarity and Enable To: ibis@vhdl.org, ibis-users@vhdl.org, sjpeters@ichips.intel.com Message-Id: <9612062310.AA18011@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Fri, 6 Dec 96 15:10:30 PST Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA18011; Fri, 6 Dec 96 15:10:30 PST Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA26257 for ibis@vhdl.org; Fri, 6 Dec 96 15:08:53 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma021365; Fri Dec 6 15:09:21 1996 Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id PAA2148 6; Fri, 6 Dec 1996 15:09:31 -0800 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl. vhdl.org (8.7.3/8.7.3) with SMTP id PAA12718; Fri, 6 Dec 1996 15:20:27 -0800 (PS T) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.8.4/8.7.3) with ESMTP id PAA05424; Fri, 6 Dec 1996 15:12:26 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.8.2/8.7.3) with ESMTP id PAA24443; Fri, 6 Dec 1996 15:12:27 -0800 (P ST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Sat Dec 7 05:55:08 1996 Received: from pimaia4w.prodigy.com (pimaia4w.prodigy.com [198.83.18.139]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id FAA05263; Sat, 7 Dec 1996 05:55:06 -0800 (PST) Received: from mime3.prodigy.com (mime3.prodigy.com [192.168.253.27]) by pimaia4w.prodigy.com (8.6.10/8.6.9) with ESMTP id IAA33562; Sat, 7 Dec 1996 08:30:52 -0500 Received: (from root@localhost) by mime3.prodigy.com (8.6.10/8.6.9) id IAA11880; Sat, 7 Dec 1996 08:24:51 -0500 Message-Id: <199612071324.IAA11880@mime3.prodigy.com> X-Mailer: Prodigy Internet GW(v0.9beta) - ae02dm02sc06 From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) Date: Sat, 7 Dec 1996 08:24:50, -0500 To: ibis@vhdl.org, ibis-users@vhdl.org cc: cottrell@cfi.org, john_beatty@vnet.ibm.com Date: 07 Dec 96 To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Help: Programmable Outputs MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii -- [ From: Ron Christopher * EMC.Ver #2.5.1 ] -- It seems like the proposed BIRD will have the user manually edit the IBIS model for each different condition. The IBIS model is in the category of rules data when processing at the higher level package. Would you require each user to have their own copy of the IBIS model in an MCM or board design shop? Can this proposal support a user who needs the IBIS model set one way for one net and a different way for a different net in the same higher level package being processed? Would a standardized filter identifier associated with the pin in the design data base improve the proposal? The filter identifier would identify to the programs which subset of the IBIS model to use for each instance of a pin. The standardized identifier can then be used by other functions such as system level delay or tristate rules checking etc. One could perhaps write a checker that checked that the standardized identifier was correct for the conditions which might require tracing a couple of levels of logic through the network. Ron Christopher ================== Text item: Scott, BIRD30.2 addresses the problem you have. Hopefully it will be implemented in IBIS3.0 soon. Untill then, in our models we use comments. Spceifically, I put everything that is legal in BIRD30.2 into the IBIS file with comment characters in front of each line. This and an explanation gives enough information to the user to know how to edit the IBIS file for the various conditions. When IBIS3.0 arrives, all they need to do is to rmove the comment characters. Arpad ======================================================================== ======= Ibis folks, I guess this question is mainly aimed at the simulation vendor folks, but feedback is welcome from everyone: (Our products are programmable logic devices, for those who are not familiar with Actel) For a component that has a programable behavior for the I/O pins, what might be the preferred way of presenting the data for the different possible configurations? Specifically, let's say that a pin can be programmed to be either: 1) Tristateable I/O with a fast slew rate 2) " " " " slow slew rate 3) Open Drain output (data input to the output buffer is programmed to be tied to the enable of the buffer) Would it be better to actually make a main IBIS file that contains all of the I/Os in condition (1), with 2 extra IBIS files that contain only one pin in them each for conditions (2) and (3)? Or, perhaps only make one IBIS file with all of the pins configured in condition (1) and commented out sections for conditions (2) and (3). Or, even another possibility of dividing the I/Os into 3 equal sections, one for each configuration? All comments/suggestions welcome, and please forgive me if this has been discussed already. Thanks, -Scott Schlachter scotts@actel.com Actel Corporation Sunnyvale, CA. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Help: Programable outputs To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9612042130.AA00584@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Wed, 4 Dec 96 13:30:44 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA00584; Wed, 4 Dec 96 13:30:44 PST Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA08918; Wed, 4 Dec 96 13:30:45 PST Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl. vhdl.org (8 .7.3/8.7.3) with SMTP id NAA17598; Wed, 4 Dec 1996 13:40:39 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.8.3/8.7.3) with ESMTP id NAA19804; Wed, 4 Dec 1996 13:36:55 -0800 (PST) Received: from ormail.intel.com (ormail.intel. com [134.134.248.3]) by relay.jf.i ntel.com (8.8.2/8.7.3) with ESMTP id NAA10202; Wed, 4 Dec 1996 13:37:03 -0800 (P ST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Mon Dec 9 07:30:35 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA28855; Mon, 9 Dec 1996 07:30:35 -0800 (PST) Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA22981; Mon, 9 Dec 96 07:20:41 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA01859; Mon, 9 Dec 96 07:20:40 PST Date: Mon, 9 Dec 96 07:20:40 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9612091520.AA01859@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Questions of Polarity and Enable Good morning IBIS world, The nessessity of having Enable and Polarity specified for the s2ibis utilities is clear to me. However, I too was wondering why they are required in the specs. It almost seems like unnesessary data to require to be listed for all of the types of pins. It SHOULD be required to specify the enable pin, IF the enable for an I/O is an external pin itself; such with, it should also have its (the enable pin's) polarity specified. But, if the enable is only available internally, why specify it? And, if it is not specifically an external enable pin, why does the pin's polarity matter to the simulation tools? Thanks, -Scott Schlachter Actel Corporation scotts@actel.com Sunnyvale, CA > Hi, > > If you are creating an IBIS model based on s2ibis utility, Polarity > and Enable are key in making the conversion work. > > For Model_type Input, Polarity=1 sets the input for inverting while > Polarity=0 for non-inverting. > > For Model_type I/O or 3-state, both Polarity and Enable fields are > expected. Enable specifies the pin number that enables the associated > output. > > Regards, > Syed > National Semiconductor Corp. > > > > > > > On Thu, 5 Dec 96 16:59:01 PST Zheng Shi of Symmetry wrote: > > > > >Hi, Ibis folks: > > > > > >Can anyone tell me what the sub-param Polarity and Enable of > > >keyword [Model] really means? Is Polarity used only on diff > > >pins? Is Enable used only on tri-state pins? How can I decide > > >the Polarity and Enable of an input or output pin? > > > > > >I can't find such detail information from IBIS2.1 Specification, > > >can anyone give me some advices, or tell me where i can find > > >the answer? > > > > > >Thanks a lot, > > > > > >-Zheng Shi > > > zheng@symmetry.com > > > Los Altos, CA. > > > > I belive the original intent was to support SSI logic components > > (74OO series TTL and the like) by allowing the user to include > > information on the outputs' logic operation. For example, the model provider > > could specify if the the path from input to output was inverting or > > non-inverting or if the enable on a tri-state output pin was high or > > low. However, for a lot of components (microprocessors, PALS/FPGAS, RAMS, > > etc.) these parameters don't seem to make much sense (to me, anyway). Unless > > you were modeling an SSI component where this made since, I would > > just default them to positive polarity and Active_high. > > > > Ibis old-timmers, any other comments? > > > > Best Regards, > > Stephen Peters > > Intel Corp. > > > > > From owner-ibis Mon Dec 9 07:47:35 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA28974; Mon, 9 Dec 1996 07:47:34 -0800 (PST) Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA23063; Mon, 9 Dec 96 07:37:41 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA01865; Mon, 9 Dec 96 07:37:40 PST Date: Mon, 9 Dec 96 07:37:40 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9612091537.AA01865@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Re[2]: Questions of Polarity and Enable Please disregard my last email. I just realized that these parameters are not actually required. My appologies, -Scott > Syed, > > Again, these sub-parameters are not required in IBIS. They may be used in the > s2ibis conversion tool, but IBIS doesn't require them, so people don't have to > use them if it doesn't make sense for them. > > Arpad > ============================================================================== From owner-ibis Mon Dec 9 07:59:22 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id HAA29053; Mon, 9 Dec 1996 07:59:21 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Mon, 9 Dec 1996 15:48:09 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id HAA08680; Mon, 9 Dec 1996 07:45:42 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Mon, 09 Dec 96 07:45:42 PST Date: Mon, 09 Dec 96 07:37:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re[2]: Questions of Polarity and Enable Text item: Scott, It seems to me that my respnse didn't make it through the reflector. The sub-parameters Enable and Polarity are NOT required in an IBIS model according to the spec. So I don't understand what all the fuss is about this. If you don't need it, don't use it... Arpad ============================================================================== Good morning IBIS world, The nessessity of having Enable and Polarity specified for the s2ibis utilities is clear to me. However, I too was wondering why they are required in the specs. It almost seems like unnesessary data to require to be listed for all of the types of pins. It SHOULD be required to specify the enable pin, IF the enable for an I/O is an external pin itself; such with, it should also have its (the enable pin's) polarity specified. But, if the enable is only available internally, why specify it? And, if it is not specifically an external enable pin, why does the pin's polarity matter to the simulation tools? Thanks, -Scott Schlachter Actel Corporation scotts@actel.com Sunnyvale, CA Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Questions of Polarity and Enable To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9612091520.AA01859@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Mon, 9 Dec 96 07:20:40 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA01859; Mon, 9 Dec 96 07:20:40 PST Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA22981; Mon, 9 Dec 96 07:20:41 PST Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8 .7.3/8.7.3) with SMTP id HAA28855; Mon, 9 Dec 1996 07:30:35 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.4/8.7.3) with ESMTP id HAA20447; Mon, 9 Dec 1996 07:29:22 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id HAA11128; Mon, 9 Dec 1996 07:2 6:48 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Mon Dec 9 10:01:23 1996 Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA00242 for ; Mon, 9 Dec 1996 10:01:22 -0800 (PST) Received: from salope.cse.tek.com by inet1.tek.com id ; Mon, 9 Dec 1996 09:49:40 -0800 Received: from mdhost.cse.tek.com (localhost [127.0.0.1]) by salope.cse.tek.com (8.7.5/8.7.3) with ESMTP id JAA14197; Mon, 9 Dec 1996 09:49:39 -0800 (PST) Message-Id: <199612091749.JAA14197@salope.cse.tek.com> To: huq@rockie.nsc.com (Syed Huq) cc: ibis@vhdl.org, brockh@mdhost.cse.tek.com Subject: Re: Who is using these ? In-reply-to: Your message of "Fri, 06 Dec 1996 11:07:42 PST." <9612061907.AA13060@rockie.nsc.com> Date: Mon, 09 Dec 1996 09:49:39 -0800 From: Brock Hannibal Hi, When I provide models for in house developed ASIC's to other design engineers here at TEK, all of the keywords you listed have been used especially the References. >[Package Model] Defines package param in Matrix format >[Pin Mapping] >[Pullup Reference] >[Pulldown Reference] >[POWER Clamp Reference] >[GND Clamp Reference] >[Rgnd] [Rpower] [Rac] [Cac] Defines a Terminator Model Brock Hannibal Design Engineer Tektronix, Inc. From owner-ibis Tue Dec 10 10:36:39 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA28597; Tue, 10 Dec 1996 10:36:38 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.8.4/10.0i); Tue, 10 Dec 1996 18:25:19 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id KAA16460; Tue, 10 Dec 1996 10:22:51 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 10 Dec 96 10:22:51 PST Date: Tue, 10 Dec 96 08:12:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org cc: cottrell@cfi.org, john_beatty@vnet.ibm.com Subject: Re[2]: Help: Programmable Outputs Text item: Ron, First, the proposed bird (30.2) does not require any manual edits by the user. The whole point was to provide a mechanizm that the simulation software would be able to use in a user friendly interface or dialog box, etc. Through this the user would not have to edit the IBIS model, the user will have to make selections in the simulation software. If no selections are made, the default will be in effect, but the software will still be able to simulate. Second, you are using some kind of a software jargon in your suggestion that I don't understand ("standardized filter identifier"). Since I don't understand, I cant comment on it. Would you care to elaborate a little more? Arpad =============================================================================== -- [ From: Ron Christopher * EMC.Ver #2.5.1 ] -- It seems like the proposed BIRD will have the user manually edit the IBIS model for each different condition. The IBIS model is in the category of rules data when processing at the higher level package. Would you require each user to have their own copy of the IBIS model in an MCM or board design shop? Can this proposal support a user who needs the IBIS model set one way for one net and a different way for a different net in the same higher level package being processed? Would a standardized filter identifier associated with the pin in the design data base improve the proposal? The filter identifier would identify to the programs which subset of the IBIS model to use for each instance of a pin. The standardized identifier can then be used by other functions such as system level delay or tristate rules checking etc. One could perhaps write a checker that checked that the standardized identifier was correct for the conditions which might require tracing a couple of levels of logic through the network. Ron Christopher ================== Text item: Scott, BIRD30.2 addresses the problem you have. Hopefully it will be implemented in IBIS3.0 soon. Untill then, in our models we use comments. Spceifically, I put everything that is legal in BIRD30.2 into the IBIS file with comment characters in front of each line. This and an explanation gives enough information to the user to know how to edit the IBIS file for the various conditions. When IBIS3.0 arrives, all they need to do is to rmove the comment characters. Arpad ======================================================================== ======= Ibis folks, I guess this question is mainly aimed at the simulation vendor folks, but feedback is welcome from everyone: (Our products are programmable logic devices, for those who are not familiar with Actel) For a component that has a programable behavior for the I/O pins, what might be the preferred way of presenting the data for the different possible configurations? Specifically, let's say that a pin can be programmed to be either: 1) Tristateable I/O with a fast slew rate 2) " " " " slow slew rate 3) Open Drain output (data input to the output buffer is programmed to be tied to the enable of the buffer) Would it be better to actually make a main IBIS file that contains all of the I/Os in condition (1), with 2 extra IBIS files that contain only one pin in them each for conditions (2) and (3)? Or, perhaps only make one IBIS file with all of the pins configured in condition (1) and commented out sections for conditions (2) and (3). Or, even another possibility of dividing the I/Os into 3 equal sections, one for each configuration? All comments/suggestions welcome, and please forgive me if this has been discussed already. Thanks, -Scott Schlachter scotts@actel.com Actel Corporation Sunnyvale, CA. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Help: Programable outputs To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9612042130.AA00584@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Wed, 4 Dec 96 13:30:44 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA00584; Wed, 4 Dec 96 13:30:44 PST Received: from ricky.sun_net ([190.9.2.228]) by actel.com (4.1/SMI-4.1) id AA08918; Wed, 4 Dec 96 13:30:45 PST Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl. vhdl.org (8 .7.3/8.7.3) with SMTP id NAA17598; Wed, 4 Dec 1996 13:40:39 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.8.3/8.7.3) with ESMTP id NAA19804; Wed, 4 Dec 1996 13:36:55 -0800 (PST) Received: from ormail.intel.com (ormail.intel. com [134.134.248.3]) by relay.jf.i ntel.com (8.8.2/8.7.3) with ESMTP id NAA10202; Wed, 4 Dec 1996 13:37:03 -0800 (P ST) Return-Path: owner-ibis@vhdl.vhdl.org Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-type: text/plain; charset=us-ascii MIME-Version: 1.0 Subject: Re: Help: Programmable Outputs To: ibis@vhdl.org, ibis-users@vhdl.org Date: 07 Dec 96 cc: cottrell@cfi.org, john_beatty@vnet.ibm.com To: ibis@vhdl.org, ibis-users@vhdl.org Date: Sat, 7 Dec 1996 08:24:50, -0500 From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER) X-Mailer: Prodigy Internet GW(v0.9beta) - ae02dm02sc06 Message-Id: <199612071324.IAA11880@mime3.prodigy.com> Received: (from root@localhost) by mime3.prodigy.com (8.6.10/8.6.9) id IAA11880; Sat, 7 Dec 1996 08:24:51 -0500 Received: from mime3.prodigy.com (mime3.prodigy.com [192.168.253.27]) by pimaia4 w.prodigy.com (8.6.10/8.6.9) with ESMTP id IAA33562; Sat, 7 Dec 1996 08:30:52 -0 500 Received: from pimaia4w.prodigy.com (pimaia4w.prodigy.com [198.83.18.139]) by vh dl.vhdl.org (8.7.3/8.7.3) with SMTP id FAA05263; Sat, 7 Dec 1996 05:55:06 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.4/8.7.3) with ESMTP id FAA03566; Sat, 7 Dec 1996 05:52:35 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id FAA01760; Sat, 7 Dec 1996 05:5 0:02 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Dec 11 18:27:56 1996 Received: from netcomsv.netcom.com (uucp7.netcom.com [163.179.3.7]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA00712; Wed, 11 Dec 1996 18:27:55 -0800 (PST) Received: from symdes.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id SAA24158; Wed, 11 Dec 1996 18:01:44 -0800 Received: from taress.symmetry by symmetry.com (4.1/SMI-4.1) id AA25809; Wed, 11 Dec 96 17:38:53 PST Date: Wed, 11 Dec 96 17:38:53 PST From: zheng@symmetry.com (Zheng SHI) Message-Id: <9612120138.AA25809@ symmetry.com> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Package Model? Hi, Ibis folks: Thank you all for reading and answering my last question about Polarity and Enable sub-param. This time I met another problem, an I/O pin has a package model as below: INT------ o----/\/\/\----o----/\/\/\----o------ EXT | | | o----@@@@@@@---o----@@@@@@@---o | | | | | | === === === | | | | | | GND GND GND It doesn't fit the default ibis package model, so I can't choose the R_pkg, L_pkg and C_pkg. Still, I can't find ways using [Define Package Model] to deal with it. Can anyone give me a help? Thanks a lot, -Zheng Shi zheng@symmetry.com Los Altos, CA. From owner-ibis Thu Dec 12 09:43:35 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA27199 for ; Thu, 12 Dec 1996 09:43:34 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 12 Dec 96 09:32 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 12 Dec 96 09:34 PST Message-Id: Date: Thu, 12 Dec 96 09:34 PST From: chris@icx.com ( Chris Reid) To: ibis@vhdl.org Subject: Re: Package Model? Zheng SHI writes: > Hi, Ibis folks: > Thank you all for reading and answering my last question > about Polarity and Enable sub-param. This time I met another > problem, an I/O pin has a package model as below: > INT------ o----/\/\/\----o----/\/\/\----o------ EXT > | | | > o----@@@@@@@---o----@@@@@@@---o > | | | > | | | > === === === > | | | > | | | > GND GND GND > It doesn't fit the default ibis package model, so I can't > choose the R_pkg, L_pkg and C_pkg. Still, I can't find > ways using [Define Package Model] to deal with it. It appears from the schematic that the purpose of the resistors in parallel with the inductors is to approximately model a skin-effect resistance. One possibility here is to model the pins as transmission lines (without the resistors) and use a simulator that handles skin-effect directly. I suggest you analyze the behavior of this network at frequencies up to ~5/rise-time and see if the resistors are actually needed to get the results you need. Since your schematic does not include values my comments are only a guess at the purpose. Christopher Reid Interconnectix From owner-ibis Thu Dec 12 11:21:02 1996 Received: from netcomsv.netcom.com (uucp9.netcom.com [163.179.3.9]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA29129 for ; Thu, 12 Dec 1996 11:21:01 -0800 (PST) Received: from symdes.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id LAA06967; Thu, 12 Dec 1996 11:01:03 -0800 Received: from taress.symmetry by symmetry.com (4.1/SMI-4.1) id AA27181; Thu, 12 Dec 96 10:45:33 PST Date: Thu, 12 Dec 96 10:45:33 PST From: zheng@symmetry.com (Zheng SHI) Message-Id: <9612121845.AA27181@ symmetry.com> To: ibis@vhdl.org Subject: Re: Package Model? ----- Begin Included Message ----- From cpk@cadence.com Thu Dec 12 10:34:17 1996 Date: Thu, 12 Dec 1996 09:33:43 -0500 From: "C. Kumar" To: zheng@symmetry.com Subject: Re: Package Model? X-Sun-Charset: US-ASCII Content-Length: 515 The package model seems to be modelling frequecny depedndent resistor. (skin effect). Unfortunately IBIS package model syntax is not sufficient to do that (including the new segment oriented package model syntax (yet another syntax ..sigh..)) . However the modelling can be easily accomplished if you are allowed to include spice subcircuits which I am a proponent of. If you beleive enabling spice subcircuits is important I urge you to raise it in the IBIS meeting (which is announced ) directly. - kumar ----- End Included Message ----- From owner-ibis Thu Dec 12 15:47:38 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA04468 for ; Thu, 12 Dec 1996 15:47:33 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 12 Dec 96 15:36 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 12 Dec 96 15:36 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 12 Dec 96 15:38 PST Message-Id: Date: Thu, 12 Dec 96 15:38 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Minutes 12/6/96 DATE: December 12, 1996 SUBJECT: 12/06/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann, Tim Minnick, Russ Moser, Ray Ziesse*, Jeff Walden* Applied Simulation Technology Dileep Divekar*, Norio Matsui, Antonis Orphanou (formerly Contec) Cadence Design C. Kumar Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier*, Ralf Bruening Intel Corporation Stephen Peters*, Will Hobbs, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet, [Donald Telian], Jim Kruchowski Interconnectix Bob Ross*, Chris Reid Meta-Software (Sanjay Gangal) Mitsubushi Tam Cao, Hoang Nguyen Motorola Ahmed Omer National Semiconductor Syed Huq*, [Donald Snyder], Chune-Sin Yeh, [Bill Aronson] NCR (formerly ATT-GIS) Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell, Chris Rokusek Quantic Laboratories Mike Ventham* Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia Veribest Ian Dodd, David Wiens VLSI Technology Dick Ulmer, Sung Oh, Swami Gangadharan, Daniel Kim, Tom Dockery, D.C. Sessions, Hrish Patel Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: 3M Fran Hart, George Hare Actel Scott Schlachter Alcatel John Fitzpatrick* Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard Digital Equipment Corp. Jeff Chu EIA Patti Rusher* IC Works Eric Chen Mentor Graphics Kim Owen Micron Technology Brian Johnson MicroSim Ralph Perez Molex Gus Panella North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Philips Semiconductor Mike Magdaluyo Rockwell Collins Thomas Thurman S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Symmetry Andy Hughes Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison VTC, Inc. Bob Ward Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Participants who have joined another organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 1/10/97 (916) 356-9200 4-35934 5448699 1/20/97 FACE TO FACE MEETING All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS Mike Ventham (an original member) from Quantic Laboratories phoned in from England. EIA MEMBERSHIP AND TREASURER'S REPORT Patti Rusher indicated no change ($9,285). MINUTES REPORT, MISC. Scott Schlacter's name was corrected from Steve in the participants list. MISCELLANY/ANNOUNCEMENTS Patti Rusher announced that the Compact Model Council is joining EIA. PRESS AND WEB PAGE UPDATES Syed Huq reported an article to be published in Electronic Design Dec. 2, 1996 issue "Ease System Simulation with IBIS Device Models" by Syed. NEW MODELS None OPENS FOR NEW ISSUES Bob Ross on Parser Bug Stephen Peters on Version 3.0 Goal DESIGN SUPERCON97 IBIS SUMMIT MEETING Syed Huq reported sending out two e-mails, one for a call for presentations and one for details of the meeting. It is scheduled from 8 AM to 5 PM on Monday, January 20. Breakfast and lunch are included. AR - RSVP to Syed Huq if you plan to attend. AR - Send Syed Huq or Bob Ross or Jon Powell the presentation idea proposal and estimated length of time. Bob Reported that several proposals have been received. Syed will send out another mailing January 2, 1997. S2IBIS2 Bob Ross reported that s2ibis2_version1.0, the first non-beta release is on vhdl.org under /pub/ibis/s2ibis. DAC97 PLANNING Bob Ross initiated discussion regarding participation in Joint EDA standards booth. Bob suggested minimum level (poster) for $2500. Dave Moxely asked who would staff it, and Patti Rusher indicated that it would be staffed by EDA people. Voted that we sign the commitment letter. AR - Bob Ross send the commitment letter to Patti Rusher. IEC PROGRESS Patti Rusher indicated that IBIS is being circulated internationally. COOKBOOK for 2.1 Chris Rokusek had sent a note requesting vendors supply the best test loads for Waveform based tables. Arpad Muranyi lead the discussion questioning dependency base on one or two resistor loads. Dileep Divekar was concerned that results based on 50 ohms would not be accurate at, say 80 ohms. Different simulators may give different results based on algorithms. The nature of IBIS models is that it has data, but the simulator algorithms determine the operation. The discussion evolved to should simulator algorithms be standardized? The ultimate reference is the transition characteristics of device itself, which cannot be standardized as an algorithm for the IBIS elements. The waveform data in a model should match the results for that load, so the question is what are the best loads be specified? Stephen Peters felt this is a cookbook issue concerning recommendations. Bob Ross felt 50 ohms to ground and Vcc provided the best load. One guidance would be to use resistive loads since loads with capacitance do not give good results in transmission line environments. AR - Simulator Vendors send to Chris Rokusek crokusek@qdt.com the best test loads for the simulator and a test load for validation. PARSER BUG DISCUSSION In response to a parser error when reserved keywords (power, gnd, nc, na) were used as pin numbers, the parser reported an error. Syed Huq felt this was correct, Bob Ross felt that is was incorrect and not the intent. This problem exists both in ibis_chk for Version 1.1 and ibischk2 for Version 2.1. After some discussion we felt this was a parser bug. AR - Bob Ross file a parser bug report. IBIS VERSION 3.0 RATIFICATION Stephen Peters raised the question of whether Version 3.0 would be ratified at the face-to-face meeting. A number of BIRDS have been approved including Buffer selection, Package model extension, Stored Charge, Specification enhancements. The Multi-staged switching and electrical interconnect descriptions are pending. Arpad Muranyi would like to see quick switch series resistance. A proposal is needed if it is to be included. After some discussion of the logistics, the goal will be to have all of the BIRDS for Version 3.0 approved by the face-to-face meeting. BIRD35.2 - MULTI-STAGED OUTPUTS (VOTE) Bob Ross introduced BIRD35.2 proposing a scheduling method for calling other models for multi-staged output. Bob Ross would add to the BIRD35.2 a recommendation that the golden waveform also be included in the [Model] description from which [Driver Schedule] is called. It could serve as a reference, although it would not be used. This would be in the Usage Rules to produce BIRD35.3. Arpad Muranyi has two cases sent by Jon Powell showing a compelling need for this capability. (A 3.3V and 5V driver pair, and TTL/CMOS driver pair) Other needs could not be discussed, but it was stressed that multi-staged switching was embedded in driver architectures. BIRD35.3 was approved 6 to 1 with Dileep Divekar dissenting. We discussed whether we would approve this with dissent - first for IBIS. We agreed to keeping this approved, but with further discussion as part of Version 3.0 adoption. PACKAGE COMMITTEE REPORT Stephen Peters reported that Dileep Divekar's comments were being considered. The syntax was focused on a single line model. It has node based descriptions. Coupled models are under discussion. Bob Ross indicated that coupled models would probably be too controversial to standardize. So single ground models would be used. The focus of the effort is to wrap up BIRD36 for reissue. AR - Stephen Peters set up the Package Committee meeting again for Friday, 8:30 AM to 10 AM. PARSER ADDITIONS FOR NUMERICAL CHECKING (Not Discussed) BIRD40 - SPECIFICATION ENHANCEMENT Bob Ross introduced BIRD40 in response to a RAIL committee request that the overshoot names in both IBIS and RAIL be different since they have different definitions. The only change is Overshoot_high and Overshoot low be changed to S_overshoot_high and S_overshoot_low. Dave Moxley had questioned the similarity of words with different meanings at the last IBIS meeting. BIRD40 will be scheduled for vote at the next meeting. NEXT MEETING: The next meeting is on Friday, January 10, 1996, 8:00 A.M. to 9:55 A.M. BIRD40 is scheduled for a vote. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Thu Dec 12 18:45:06 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA06283 for ; Thu, 12 Dec 1996 18:45:03 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 12 Dec 96 18:33 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 12 Dec 96 18:33 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 12 Dec 96 18:35 PST Message-Id: Date: Thu, 12 Dec 96 18:35 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD35.3 MULTI-STAGED OUTPUTS To IBIS Committee: BIRD35.3 was approved at the December 6, 1996 meeting by a 6-1 vote based on a real and compelling need to have this functionality. The change here is to add a statement in the usage rules for recommending a "golden waveform" reference [Rising Waveform] and [Falling Waveform] table to assist in validation. Remaining comments were are the same as previously posted. The change is noted by the "|*" lines. BIRD35.2 is a complete revision of BIRD35.1 to reflect the IBIS Committee's request for a [Model] based scheduling mechanism. BIRD35.1 focused on scheduling a sequence of new [Pullup(n)] and [Pulldown(n) tables. BIRD35.2 now schedules other [Model]s directly. The key aspects of BIRD35.2 are: 1. Each [Model] can contain the [Driver Schedule] keyword to override using the [Pullup] and [Pulldown] and transition and use that data form the referenced models. Even though it is overrided, this information is still needed, as required for downward compatibility for simulators which do not support the multi-staged [Driver Schedule] keyword. 2. The [Model] keyword subparameters for specifications (Vinl, Vinh, Vmeas, Vref, Rref, Cref) and C_comp override any data contained in models that are referenced in the [Driver Schedule] table. 3. Only the [Power Clamp] and [Gnd Clamp] tables under [Model] are used. 4. The [Driver Schedule] consists of 5 columns for defining the referenced Model_name, its rising_on, rising_off, falling_on and falling_off delays. All four columns are required. A value of zero implies no delay. A value of NA implies that no response occurs for that part of the transition. This could occur, for example, if an Open_source model is used for an extra bit of source current for a small period of time for the rising transition, but has no effect for the falling transition. For background: The multi-staged switching functionality has been on the priority list for Version 3.0 addtions. BIRD35.2 is another proposal to address this issue. Unlike exiting IBIS keywords, the new tables cannot be measured directly or even be produced easily by direct decomposition and simulation of Spice elements because of too much internal interaction. The actual construction would be by trial and validation and based on the known architectural intent. Bob Ross Interconnectix ****************************************************************************** ****************************************************************************** BIRD ID#: 35.3 ISSUE TITLE: Multi-staged Outputs REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 5/13/96, 6/21/96, 10/16/96 DATE ACCEPTED BY IBIS OPEN FORUM: 12/6/96 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Modeling output transitions of buffers consisting of several sequentially switched internal devices has been a long standing request. The addition of the [Rising Waveform] and [Falling Waveform] keywords partially addresses the issue by waveform shaping control. However, these keywords do not model the dynamic impedance changes during transitions. The more direct solution is to add IBIS keywords which allow modeling the internal architecture more closely. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The [Driver Schedule] keyword is introduced as a keyword under the [Model] keyword to construct a multi-staged driver from other existing driver models. |============================================================================== | Keywords: [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] table consists of five columns. The | first column is the model names of other models that exist | in the .ibs file. The remaining four columns describe | delays: rising_delay_on, rising_delay_off, falling_delay_on | and falling_delay_off. 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 begining of the low-to-high | transition. The Rise_off_dly entry may be given to end the | low-to-high transition and intiate a high-to-low transition | during the rising cycle. Similarily, the Fall_on_dly gives | the begining 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. |------------------------------------------------------------------------------ | [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) | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The proposal is designed to add to the existing IBIS structures and retain as much existing meaning as possible. The new "stage" tables follow all of the conventions of the existing non-staged tables. For that reason, even the subparameters R_dut, L_dut, and C_dut are permitted, although they are not relevant nor are expected to be used. The overall structure is to connect independently controlled stages to a common output node. The relative relationhips between waveform controls are used to produce phased turn-on and turn-off models. The structure can be also be used to model other internal artifacts. These may include providing an extra boost pulse or providing bus hold modeling. A general objection to these structures is that they do not relate to any externally obtained extraction. The intent of these structures is to give a format for modeling a known architecture with behavioral blocks and to also add some detail to existing models. BIRD35.1 introduces a [Rising Sequence] and [Falling Sequence] tables to control the sequencing of individual stages. This is in response to Jon Powell's comment to make the sequencing of waveforms easier to understand and modify. So each [Rising Waveform(n)] and [Falling Waveform(n)] table has its start time controlled by the Sequence tables. One technical limitation is that the Sequencing is the same for typ, min, and max columns. Any internal shifting within the typ, min, and max columns for the stage must be taken into account within the Waveform columns for that stage. BIRD35.2 removes the numbered [Pullup(n)], [Pulldown(n)], [Rising Waveform(n)] and [Falling Waveform(n)] syntax. Instead, references by Model_name is introduced so that existing [Model] syntax can be used. 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 model that is referenced may itself be a complete model. This creates a problem if several complete models are referenced and they contain common information such as specification data, C_comp, and clamping information. Some of this information can be conflicting such as timing test loads and thresholds. The simplist resolution is to rely only on the information withing the [Model] keyword itself. Then it can be found easily. Also, there is no confusion whether data in other models is "added". For example, would all of the C_comp values be added? The syntax allows for a reduction rather than an addition in driver strength by using the "*_off_dly". This can be used to turn off the boost with the transition to initiate an out of phase boost. Not all simulators may support this feature. This feature could be used to model a bus-hold output stage. The prohibition of [Driver Schedule] table referencing other models which contain the [Driver Schedule] keyword is added to keep all of the scheduling within one table for clarity and to avoid the need to test for models referencing each other. BIRD35.3 adds a note to recommend a "golden waveform" to serve as a reference for validation. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Jon Powell provided syntax of an existing implementation. This proposal is intended to be compatible with it. ****************************************************************************** From owner-ibis Fri Dec 13 10:08:49 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA29381 for ; Fri, 13 Dec 1996 10:08:48 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.7.3) with ESMTP id JAA02808 for ; Fri, 13 Dec 1996 09:57:30 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id JAA08810; Fri, 13 Dec 1996 09:54:52 -0800 (PST) Message-Id: <199612131754.JAA08810@ichips.intel.com> To: ibis@vhdl.org Subject: Simulator support for multi-board simulation Date: Fri, 13 Dec 1996 09:57:33 -0800 From: Stephen Peters Hello All: At the packaging committee meeting today the question was raised regarding how many simulator companies support "automatic" multi-board simulation. By this I mean, do any simulator companies support the ability to do a simulation on a trace that goes from one board, thru a connector, then onto another board without manually creating a netlist that patch the two boards together? Just wondering.... Regards, Stephen From owner-ibis Fri Dec 13 10:33:44 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA29586 for ; Fri, 13 Dec 1996 10:33:43 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id KAA26988 for ; Fri, 13 Dec 1996 10:22:49 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma026703; Fri Dec 13 10:22:25 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA29272 for ibis@vhdl.org; Fri, 13 Dec 96 10:21:48 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA26765; Fri, 13 Dec 96 10:23:33 PST Date: Fri, 13 Dec 96 10:23:33 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9612131823.AA26765@rockie.nsc.com> To: ibis@vhdl.org Subject: New IBIS models from National Semiconductor Cc: huq@rockie.nsc.com IBIS fans, National Semiconductor has released the following IBIS models. These are available from our web site at: http://www.national.com/models/ibis/ibis.html ds36c200.ibs Dual High-speed Bi-directional ..../models/ibis/interface.html Differential Transceiver lm78.ibs uP System Hardware Monitor ..../models/ibis/dataacq.html pc87338.ibs SuperI/O .../models/ibis/superio.html National Semiconductor provides technologies for moving and shaping information. The company focuses on communications, analog, and personal systems markets, and is the fourth largest U.S semiconductor merchant. Regards, Syed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Syed B. Huq huq@rockie.nsc.com ~ ~ National Semiconductor Corp. ~ ~ Tel:(408)721-4874; Fax:(408)721-4785 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ibis Fri Dec 13 11:04:37 1996 Received: from fedex.engwest.baynetworks.com.engwest.baynetworks.com (screen2r.BayNetworks.COM [134.177.4.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA29954 for ; Fri, 13 Dec 1996 11:04:36 -0800 (PST) Received: from cinderella.engwest (cinderella.engwest.baynetworks.com) by fedex.engwest.baynetworks.com.engwest.baynetworks.com (4.1/SMI-4.1) id AA21694; Fri, 13 Dec 96 10:52:51 PST Received: by cinderella.engwest (4.1/SMI-4.1) id AA09489; Fri, 13 Dec 96 10:52:50 PST Date: Fri, 13 Dec 96 10:52:50 PST From: lfung@baynetworks.com (Laurie Fung) Message-Id: <9612131852.AA09489@cinderella.engwest> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From owner-ibis Fri Dec 13 15:27:28 1996 Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA03447 for ; Fri, 13 Dec 1996 15:27:26 -0800 (PST) From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) Content-Type: text Message-Id: <9612131818.ZM17299@eagle> Date: Fri, 13 Dec 1996 18:18:06 -0500 In-Reply-To: Stephen Peters "Simulator support for multi-board simulation" (Dec 13, 9:57am) References: <199612131754.JAA08810@ichips.intel.com> X-Mailer: Z-Mail (2.1.4 02apr93) To: ibis@vhdl.org Subject: Re: Simulator support for multi-board simulation Steven, We regularly use Quad Design tools to do full system analog simulations that include board and connector coupling. We even do SSO on a system wide level on signals that approach design margins. I wouldn't call it automatic. It A LOT of work. The capability is there. The circuit data comes from the layout tools. The connectors models are extracted from spice or 3d modeling and I wish I could get all my device models from IBIS :-) ... Rich On Dec 13, 9:57am, Stephen Peters wrote: > Subject: Simulator support for multi-board simulation > > Hello All: > > At the packaging committee meeting today the > question was raised regarding how many simulator > companies support "automatic" multi-board simulation. > By this I mean, do any simulator companies support > the ability to do a simulation on a trace that goes > from one board, thru a connector, then onto another > board without manually creating a netlist that patch > the two boards together? Just wondering.... > > Regards, > Stephen >-- End of excerpt from Stephen Peters From owner-ibis Fri Dec 13 16:14:04 1996 Received: from fedex.engwest.baynetworks.com.engwest.baynetworks.com (screen2r.BayNetworks.COM [134.177.4.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA04288 for ; Fri, 13 Dec 1996 16:14:03 -0800 (PST) Received: from cinderella.engwest (cinderella.engwest.baynetworks.com) by fedex.engwest.baynetworks.com.engwest.baynetworks.com (4.1/SMI-4.1) id AA24831; Fri, 13 Dec 96 16:02:19 PST Received: by cinderella.engwest (4.1/SMI-4.1) id AA09545; Fri, 13 Dec 96 16:02:18 PST Date: Fri, 13 Dec 96 16:02:18 PST From: lfung@baynetworks.com (Laurie Fung) Message-Id: <9612140002.AA09545@cinderella.engwest> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From owner-ibis Fri Dec 13 16:25:40 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA04528 for ; Fri, 13 Dec 1996 16:25:38 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 13 Dec 96 16:14 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 13 Dec 96 16:16 PST Message-Id: Date: Fri, 13 Dec 96 16:16 PST From: chris@icx.com ( Chris Reid) To: ibis@vhdl.org Subject: Simulator support for multi-board simulation Stephen, The Interconnectix tools (ISMB + IS) support automatic multiboard analysis simply by specifying a connector using an extension of the BIRD 28.1 RLG matrix models. Signoise + Allegro does a similar job (although our's is of course better, even if I did design both of them). Chris Reid Interconnectix From owner-ibis Sun Dec 15 21:37:17 1996 Received: from kaw.co.jp ([202.218.183.130]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id VAA03501 for ; Sun, 15 Dec 1996 21:37:15 -0800 (PST) From: mthai@kaw.co.jp Received: from kj46 (kj46.kaw.co.jp [202.218.183.147]) by kaw.co.jp (8.6.12+2.5Wb7/3.4W2) with SMTP id OAA10511 for ; Mon, 16 Dec 1996 14:29:53 +0900 Received: by kj46 (4.1/3.4W2) id AA19370; Mon, 16 Dec 96 14:22:00 JST Date: Mon, 16 Dec 96 14:22:00 JST Message-Id: <9612160522.AA19370@kj46> To: ibis@vhdl.org Subject: Re: Simulator support for multi-board simulation Dear Stephen, UniCAD's UniSolve analysis tools support multi-board level analysis (with linear and IBIS models). Minh B. Thai Keihin Art Work. > From owner-ibis@vhdl.vhdl.org Sat Dec 14 04:30:31 1996 > To: ibis@vhdl.org > Subject: Simulator support for multi-board simulation > Content-Length: 467 > X-Lines: 14 > > > Hello All: > > At the packaging committee meeting today the > question was raised regarding how many simulator > companies support "automatic" multi-board simulation. > By this I mean, do any simulator companies support > the ability to do a simulation on a trace that goes > from one board, thru a connector, then onto another > board without manually creating a netlist that patch > the two boards together? Just wondering.... > > Regards, > Stephen > From owner-ibis Mon Dec 16 15:54:44 1996 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA00480 for ; Mon, 16 Dec 1996 15:54:43 -0800 (PST) From: dmehta@cadence.com Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id PAA02197 for ; Mon, 16 Dec 1996 15:14:32 -0800 Received: from hi-av2.cadence.com(158.140.128.32) by mailgate.Cadence.COM via smap (V1.0mjr) id sma850778070.002185; Mon Dec 16 15:14:30 1996 Received: from [158.140.7.111] (mac585.Cadence.COM [158.140.7.111]) by mailhub.Cadence.COM (8.7.3/8.7.3) with SMTP id PAA03218 for ; Mon, 16 Dec 1996 15:13:38 -0800 (PST) Date: Mon, 16 Dec 1996 15:13:38 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org Subject: Re: Simulator support for multi-board simulation ON Dec 13th Stephen Peters wrote........... >>how many simulator > companies support "automatic" multi-board simulation. > By this I mean, do any simulator companies support > the ability to do a simulation on a trace that goes > from one board, thru a connector, then onto another > board without manually creating a netlist that patch > the two boards together? Just wondering.... > >Stephen, >Your question is a very good one. We at Cadence come across >this multi-board simulation requirement all the time, in fact our experience is that the environment of multi-board is becoming dominant and designers are looking for a cleaner and transparent solution. Our Performance Engineering offering (BoardQuest, SigXplorer and SigNoise) support this multi-board simulation capability in a straight forward and automatic fashion. Yes- circuit topologies are extracted and built on the fly for mulit-board designs. No messy editing or mucking of netlist etc.... Thanks for asking >Regards >Dee Mehta > > > >From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) >Date: Fri, 13 Dec 1996 18:18:06 -0500 >To: ibis@vhdl.org >Subject: Re: Simulator support for multi-board simulation > >Steven, > >We regularly use Quad Design tools to do full system >analog simulations that include board and connector coupling. >We even do SSO on a system wide level on signals that approach >design margins. I wouldn't call it automatic. It A LOT of work. >The capability is there. The circuit data comes from the layout >tools. The connectors models are extracted from spice or 3d modeling and >I wish I could get all my device models from IBIS :-) > >... Rich > > >On Dec 13, 9:57am, Stephen Peters wrote: > Subject: Simulator support for multi-board simulation > > Hello All: > > At the packaging committee meeting today the > question was raised regarding how many simulator > companies support "automatic" multi-board simulation. > By this I mean, do any simulator companies support > the ability to do a simulation on a trace that goes > from one board, thru a connector, then onto another > board without manually creating a netlist that patch > the two boards together? Just wondering.... > > Regards, > Stephen >-- End of excerpt from Stephen Peters > > Dee Mehta Systems Core Competency Dmehta@cadence.com (408)428-5178 MS 1B1 From owner-ibis Tue Dec 17 02:23:52 1996 Received: from ds9.Dortmund.loca.net (bin@ds9.Dortmund.loca.net [194.39.202.133]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id CAA06145 for ; Tue, 17 Dec 1996 02:23:44 -0800 (PST) From: duffy@pad.incases.com Received: (from bin@localhost) by ds9.Dortmund.loca.net (8.7.5/8.7.3) id LAA28093; Tue, 17 Dec 1996 11:11:06 +0100 (MET) X-Authentication-Warning: ds9.Dortmund.loca.net: bin set sender to using -f Received: from isdn.pad.incases.com(194.64.13.226) by ds9.Dortmund.loca.net via smap (V1.3) id sma028091; Tue Dec 17 11:10:57 1996 Received: from ganymed.incases.com by mail.pad.incases.com with smtp (Smail3.1.28.1 #3) id m0vZwTR-00046DC; Tue, 17 Dec 96 11:10 MET Received: by ganymed.incases.com (5.x) id AA15621; Tue, 17 Dec 1996 11:10:05 +0100 Date: Tue, 17 Dec 1996 11:10:05 +0100 Message-Id: <9612171010.AA15621@ganymed.incases.com> To: ibis@vhdl.org, sjpeters@ichips.intel.com Subject: Re: Simulator support for multi-board simulation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: twk/oavV0g2sYTpeYfGLcQ== Hello, within the INCASES-EMC-Workbench it is possible either to define the connection across a PCB within the PCB input structures from the PCB design system or to connect different PCB's (optional designed with different design systems) in a convinient manner by graphical connecting the connectors in the geometry extraction and visualisation module LDE. Nets across connectors may then be simulated (using automatically attached Connector Models) by our signal integrity simulator FREACS (Fast REflection And Crosstalk Simulator). hope this helps and sorry for the late posting Ralf Bruening Product Manager R+D EMC From owner-ibis Tue Dec 17 10:17:52 1996 Received: from mailsorter-2.alma.webtv.net (mailsorter-2.isp.alma.webtv.net [205.180.153.86]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA25157 for ; Tue, 17 Dec 1996 10:17:52 -0800 (PST) Received: from mailtod-2.alma.webtv.net (mailtod-2.iap.alma.webtv.net [207.76.180.82]) by mailsorter-2.alma.webtv.net (8.7.5/8.7.3) with ESMTP id KAA13815; Tue, 17 Dec 1996 10:06:33 -0800 (PST) Received: (from production@localhost) by mailtod-2.alma.webtv.net (8.7.5/8.7.3) id KAA20721; Tue, 17 Dec 1996 10:06:31 -0800 (PST) Message-Id: <199612171806.KAA20721@mailtod-2.alma.webtv.net> From: BBY299@webtv.net (Best Buy 299) Date: Tue, 17 Dec 1996 13:06:31 -0500 To: ibis@vhdl.org Subject: unsubscibe Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 (WebTV 1.0) unsubscribe From owner-ibis Wed Dec 18 16:45:42 1996 Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA26199 for ; Wed, 18 Dec 1996 16:45:41 -0800 (PST) From: KARL_KACHIGAN@HP-Sonoma-om1.om.hp.com Received: from hpcc39.corp.hp.com (hpcc39.corp.hp.com [15.0.120.39]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id QAA01665 for ; Wed, 18 Dec 1996 16:34:14 -0800 (PST) Received: from by hpcc39.corp.hp.com with SMTP (1.37.109.16/15.5+ECS 3.4 Openmail) id AA202305653; Wed, 18 Dec 1996 16:34:13 -0800 X-Openmail-Hops: 1 Date: Wed, 18 Dec 96 16:33:43 -0800 Message-Id: Subject: IBIS Modeling Survey To: ibis@vhdl.org Item Subject: ibissurv.txt 12/16/96 11:52A Hello, Hewlett-Packard is interested in better understanding the state of IBIS model development. There are several approaches in use today -- measurement, extraction from Spice models, etc. If you've had experience in developing IBIS models we would appreciate your answer to this survey (please respond by January 6, 1996). It is our intent to review this information at a future IBIS meeting. You can send your reply directly to: karlk@sr.hp.com Regards, Karl Kachigan HP EEsof Division IBIS Model Development Survey ============================= 1. Tell us about yourself and your company: Name: Company: Key responsibility: Email address: 2. What situation caused you to develop IBIS models? 3. How did you go about developing the IBIS models? 4. What factors hindered your ability to develop IBIS models? 5. What were the rewards for developing IBIS models? 6. What would have been the consequences of not developing IBIS models? 7. Will you be continuing to develop IBIS models? 8. What new approaches or enabling factors would you like to see to enhance your IBIS model development? Many thanks for taking the time to let us know your thoughts.