From qdt!sal!jonp@lmc.com Mon Aug 9 10:50:45 1993 Date: Mon, 9 Aug 93 10:25:34 PDT From: qdt!sal!jonp@lmc.com (Jon Powell) To: ibis@vhdl.org Subject: [jonp@sal: Press Release] Content-Length: 1600 Hi fellow IBISIANS, here are some comments from Quad Design re: the proposed Press release: 1) >> Previous I/O Buffer model development methodologies were based on actual >> circuit designs and revealed detailed information not just about the buffer >> design, but also about the underlying proprietary fabrication processes. In >> contrast, IBIS uses voltage-versus-current characteristics of the buffers along >> with additional circuit, package and timing information. This form of data >> protects the semiconductor vendor's proprietary information about the design >> and process technology while providing a useful model to the end user. Actually, this exact approach has been used by TLC/XTK for 6 years now..... 2) >> specifically for transmission-line simulation, IBIS models can run faster than >> full SPICE models, while maintaining an accuracy down to 1 picosecond. 1 picosecond seems like a somewhat arbitrary number. In practice, IBIS models could lead to better results that SPICE models, especially if better work was done simulating the wires themselves. Also, since the IBIS data is non-proprietary, a higher quality of data may be used that was is often released in "sanitized" spice models. However, I believe the text should just read something like: specifically for transmission-line simulation, IBIS models can run faster than full SPICE models, while maintaining accuracy. 3) I think we should definitely mention parser development. I think the existence of the parser is a big win and will motivate vendors to move on IBIS compliance. take care jon From valhalla.performance.com!bracken@lmc.com Tue Aug 10 11:35:10 1993 From: valhalla.performance.com!bracken@lmc.com To: ibis@vhdl.org Subject: Clarification Date: Tue, 10 Aug 93 14:10:46 -0400 Content-Length: 856 Fellow IBIS'ers: Please let me clarify one point that was raised in the recent correspondence between Quad Design and MetaSoft. I believe that the discussion regarding the tradeoffs between Spice and IBIS models has become somewhat muddled by the introduction of AWE into the debate. The Asymptotic Waveform Evaluation (AWE) technique, mentioned by Stephen Fenstermaker in his message, addresses the task of efficiently and accurately simulating the LINEAR (interconnect) part of the circuit, NOT the nonlinear drivers and receivers. AWE is not a third, "competing" alternative to Spice and IBIS in this sense. AWE is compatible with simulators that use either Spice or IBIS-style behavioral models, and can accelerate the interconnect analysis for both approaches without loss of accuracy. --Eric Bracken Performance Signal Integrity, Inc. From metasw.com!stephenf@lmc.com Tue Aug 10 11:55:05 1993 Date: Tue, 10 Aug 93 11:39:52 PST From: Stephen Fenstermaker To: ibis@vhdl.org, bracken@valhalla.performance.com Subject: Re: Clarification Content-Length: 1069 Well spoken! My only point was to re-emphasize that the speed, accuracy tradeoff for customers is STILL alive and well, and that IBIS breaks new ground mainly as a truly open data interchange format. Stephen Fellow IBIS'ers: Please let me clarify one point that was raised in the recent correspondence between Quad Design and MetaSoft. I believe that the discussion regarding the tradeoffs between Spice and IBIS models has become somewhat muddled by the introduction of AWE into the debate. The Asymptotic Waveform Evaluation (AWE) technique, mentioned by Stephen Fenstermaker in his message, addresses the task of efficiently and accurately simulating the LINEAR (interconnect) part of the circuit, NOT the nonlinear drivers and receivers. AWE is not a third, "competing" alternative to Spice and IBIS in this sense. AWE is compatible with simulators that use either Spice or IBIS-style behavioral models, and can accelerate the interconnect analysis for both approaches without loss of accuracy. --Eric Bracken Performance Signal Integrity, Inc. From ichips.intel.com!speters@lmc.com Wed Aug 18 10:49:43 1993 From: ichips.intel.com!speters@lmc.com To: ibis@vhdl.org Subject: IBIS OD and ECL Date: Wed, 18 Aug 93 10:30:10 PDT Content-Length: 2573 Greetings Gentleman-- I'm back from vacation and have had a chance to read and think about the mail from Siuki Chan and others. I have a few comments and clarifications. 1. The [Voltage HIGH Range] and [Voltage LOW Range] key words that Kellee C. proposed were for a device whose output swings both positive and negative around ground, i.e. a device with 3 supplies: gnd, +V and -V. Siuki Chan is correct in stating that these key words are not strictly necessary for a device with only two supply rails and whose output only swings one way with respect to ground. 2. I agree with Siuki C. that one can theoretically determine, from the point at which current = 0, which supply rail the data in the pullup or pulldown tables is referenced to. However, remember that IBIS requires that the data in the pullup table be 'VCC relative'. This means that for BOTH cases (pullup and pulldown), current = 0 at V = 0 (or there abouts). The unspoken assumption was that in the pullup case V = 0 really meant V = VCC, and in the pulldown case V = 0 really was V = 0. In the case of ECL, the assumption about the pulldown case is violated. That is why I believe we need to make it explicitly known to the simulator that the pulldown curves are referenced to the most positive supply. 3. Their is one more point that Siuki Chan raised earlier that I am now beginning to understand. It may not effect ECL or OD type parts but it is fundamental to complementary pair CMOS type outputs. The rational behind making the data in the pullup table VCC relative was to allow the simulators to be able to handle shifts in VCC. For example, suppose a simulation in run with VCC set to +5.2V, using data from a part whose curve was taken at VCC = 5.0V. The simulator should be able to just shift the data point on the curve by 0.2V, IF THE SIGNIFICANT OPERATING PARAMETERS OF THE PULLUP XSISTOR HAVE NOT CHANGED. Now for ECL, this assumptions holds true. Both the base and collector of the output emitter follower are tied to VCC so neither Vcb or Ib changes. For an open drain or open collector type part again, changes in VCC do not effect the output xsistor. However, for a standard CMOS output, changing VCC changes Vgs on the pullup xsistor. This means that the SHAPE of the V-I curve has changed. The question is whether this change is enough to make a difference. Do any of the simulation vendors care to comment? I hope to hear from everyone at the meeting Friday. Thanks, Stephen Peters Intel Corp. From intelhf.intel.com!ccm!Arpad_Muranyi@lmc.com Thu Aug 19 08:48:38 1993 Date: Thu, 19 Aug 93 08:41:11 PST From: Arpad Muranyi Message-Id: <930819084111_4@ccm.hf.intel.com> To: Don_A_Telian@ccm.hf.intel.com, Will_Hobbs@ccm.hf.intel.com, speters@ichips.intel.com, ibis@vhdl.org Subject: Re: IBIS OD and ECL Greetings, I just want to make a short comment on the last paragraph of Steven's EMAIL below. I agree with Steven's comment regarding the change in the shape of the CMOS V/I curves when the power supply is not stable. I already collected families of curves of a few devices to study the effects of the Vcc voltage change. It seems to me that this change in the V/I curve is proportional for CMOS devices and I am hoping to be able to derive a scaling factor which would allow for using the Vcc as a scaling variable to change the V/I curve on the fly. I also must mention that bipolar devices behave quite differently, which needs some more thought. I would also like to use a similar scaling factor to make adjustments on the V/I curve due to the effects of temperature. This way we could eliminate the need for best and worst case V/I tables and do all of that just by using two scaling factors for Temp. and Vcc variations. Any comments? Arpad Muranyi Intel Corporation Greetings Gentleman-- I'm back from vacation and have had a chance to read and think about the mail from Siuki Chan and others. I have a few comments and clarifications. 1. The [Voltage HIGH Range] and [Voltage LOW Range] key words that Kellee C. proposed were for a device whose output swings both positive and negative around ground, i.e. a device with 3 supplies: gnd, +V and -V. Siuki Chan is correct in stating that these key words are not strictly necessary for a device with only two supply rails and whose output only swings one way with respect to ground. 2. I agree with Siuki C. that one can theoretically determine, from the point at which current = 0, which supply rail the data in the pullup or pulldown tables is referenced to. However, remember that IBIS requires that the data in the pullup table be 'VCC relative'. This means that for BOTH cases (pullup and pulldown), current = 0 at V = 0 (or there abouts). The unspoken assumption was that in the pullup case V = 0 really meant V = VCC, and in the pulldown case V = 0 really was V = 0. In the case of ECL, the assumption about the pulldown case is violated. That is why I believe we need to make it explicitly known to the simulator that the pulldown curves are referenced to the most positive supply. 3. Their is one more point that Siuki Chan raised earlier that I am now beginning to understand. It may not effect ECL or OD type parts but it is fundamental to complementary pair CMOS type outputs. The rational behind making the data in the pullup table VCC relative was to allow the simulators to be able to handle shifts in VCC. For example, suppose a simulation in run with VCC set to +5.2V, using data from a part whose curve was taken at VCC = 5.0V. The simulator should be able to just shift the data point on the curve by 0.2V, IF THE SIGNIFICANT OPERATING PARAMETERS OF THE PULLUP XSISTOR HAVE NOT CHANGED. Now for ECL, this assumptions holds true. Both the base and collector of the output emitter follower are tied to VCC so neither Vcb or Ib changes. For an open drain or open collector type part again, changes in VCC do not effect the output xsistor. However, for a standard CMOS output, changing VCC changes Vgs on the pullup xsistor. This means that the SHAPE of the V-I curve has changed. The question is whether this change is enough to make a difference. Do any of the simulation vendors care to comment? I hope to hear from everyone at the meeting Friday. Thanks, Stephen Peters Intel Corp. From ventham@quantic.mb.ca Thu Aug 19 16:41:15 1993 Return-Path: Received: from canopus.CC.UManitoba.CA by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08886; Thu, 19 Aug 93 16:41:15 PDT Received: from ccu.umanitoba.ca by canopus.CC.UManitoba.CA (4.1/25-eef) id AA29874; Thu, 19 Aug 93 18:40:57 CDT Received: by ccu.umanitoba.ca with UUCP (4.1/25-eef) id AA22725; Thu, 19 Aug 93 18:40:59 CDT Received: by bison.mb.ca (1.65/waf) via UUCP; Thu, 19 Aug 93 19:44:41 CDT for ibis@vhdl.org Received: by quantic.mb.ca (4.1/SMI-4.1) id AA15891; Thu, 19 Aug 93 15:49:34 CDT Date: Thu, 19 Aug 93 15:49:34 CDT From: ventham@quantic.mb.ca (Mike Ventham) Message-Id: <9308192049.AA15891@quantic.mb.ca> To: ibis@vhdl.org Subject: PR, Sim Tech and the Elderly Greetings, IBIS Gentlefolk A few points on various subjects. 1) The press release - Please use Quantic Laboratories for our name, as Quantic Labs is our informal name. I have passed on the text to our Marketing department. [ Randy, please would you add jonathan@quantic.mb.ca to the circulation list for Press releases. Thanks ] 2) I've finally remembered what I meant by the simulation technology for model vendors, which was item 8 on the list and targeted for deletion tomorrow. This was in regards to the situation where a silicon vendor derives the data for an IBIS model from a simulation of the SPICE model rather than by measurement of the actual device. I believe that the circuits used to derive the curves should be standardised as far as possible and documented to make it easy for new silicon vendors to do this. One of the problems is that you can end up with more points than appropriate for an IBIS model as you only want to pick out the salient characteristics of the curve. Putting in the whole set of points leads to additional computation time and the closeness of the points with similar slopes may cause convergence problems in the simulator. We have solved this problem within our VI curve modellor Phidias, by using a curve following cursor and letting the user select the requisite data points. Do other people think that silicon vendors will do this? If they don't then this is not a problem. If they do then it needs clarifying. Do Intel plan to do anything like this. I'd like this briefly discussed to check if it is worthy of further discussion. 3) What about the elderly devices? In conversation with a customer about IBIS, he asked whether the older devices he was using would be provided in IBIS format. As we all know the models availability issue which IBIS finally addresses has been around for quite sometime and SPICE models are still difficult if not impossible for old devices (i.e those over 2 years old!). Also, not every company upgrades to the latest and greatest versions of a chip in their designs, for various reasons including cost, availability and re-design time. Obviously, for Intel, the Pentium and its associated devices were a suitable starting point for this, but do they plan to issue IBIS models of some of their earlier devices? I understand that this will mainly affect the silicon vendors in their efforts to support IBIS, but it is likely to impair the efforts of the simulation vendors to push the IBIS way if only those companies on the leading edge will be able to use the IBIS models. I am sure that not all their designs contain only the latest components. I also realise that there is an awful lot of devices. I'd like to propose this for an agenda item for discussion - I think the result would probably be a policy for IBIS silicon vendors or a decision to leave it up to the individual companies as to how many devices they put into IBIS format. I look forward to comments on the above two points. Mike Ventham P.S We should also agree whether we are IBIS'ers, IBISIans, IBISonians etc., or just the IBIS consortium. From lmsi!milpitas.lmc.com!randyh@UB.com Thu Aug 19 17:11:28 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09042; Thu, 19 Aug 93 17:11:28 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA19451; Thu, 19 Aug 93 17:11:22 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA15606; Thu, 19 Aug 93 17:09:29 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA24128; Thu, 19 Aug 93 17:09:29 PDT Date: Thu, 19 Aug 93 17:09:29 PDT From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9308200009.AA24128@fiji.lmsi.com> To: ibis@vhdl.org Subject: Re: PR, Sim Tech and the Elderly Forwarding: Mail from 'quantic.mb.ca!ventham@lmc.com (Mike Ventham)' dated: Thu, 19 Aug 93 15:49:34 CDT >>From quantic.mb.ca!ventham@lmc.com Thu Aug 19 16:55:18 1993 >To: ibis@vhdl.org >Subject: PR, Sim Tech and the Elderly > >Greetings, IBIS Gentlefolk > >A few points on various subjects. > >1) ... > >2) ... > >3) What about the elderly devices? > In conversation with a customer about IBIS, he asked whether the older > devices he was using would be provided in IBIS format. As we all know > the models availability issue which IBIS finally addresses has been > around for quite sometime and SPICE models are still difficult if not > impossible for old devices (i.e those over 2 years old!). Also, not > every company upgrades to the latest and greatest versions of a chip in > their designs, for various reasons including cost, availability and > re-design time. > Obviously, for Intel, the Pentium and its associated devices were a suitable > starting point for this, but do they plan to issue IBIS models of some of > their earlier devices? I understand that this will mainly affect the > silicon vendors in their efforts to support IBIS, but it is likely to > impair the efforts of the simulation vendors to push the IBIS way if > only those companies on the leading edge will be able to use the IBIS > models. I am sure that not all their designs contain only the latest > components. I also realise that there is an awful lot of devices. > > > I'd like to propose this for an agenda item for discussion - I think > the result would probably be a policy for IBIS silicon vendors or a > decision to leave it up to the individual companies as to how many devices > they put into IBIS format. At Logic Modeling, we are standardizing on a format for delivery of bare die information of which we are encapsulating IBIS inside it. Many of the semi vendors have plans, at least for bare die, to go back and create electronic databases of old parts that are still being sold. Much of this impetus is because the bare die are virtually useless without geometric, pad type, and electrical models. Although we need more accuracy and a lot wider technology support range for the MCM type interconnect modeling than IBIS will provide today; we feel it is a great start and are supporting it to make it easier to go forward. Having many years experienc (and bruises) trying to get semi companies to deliver behavioral models; I would not recommend to anyone to make an agenda item to get any commitment out of any semi company. As one jumps in (Intel), others will follow and market forces will demand what happens. LMC is just glad to help out getting more IBIS models via the bare die requirement. P.S. - if anyone wants info on the bare die spec or industry group, it is also on vhdl.org (die@vhdl.org; files in /bbs/eia/die). The mail archive server is almost working on the machine which will allow you to request the documents (and IBIS ones in /bbs/pub/ibis) via email. This is the solution for those not on Internet (FTP / gopher) and not wanting to modem in to the machine directly. From lmsi!milpitas.lmc.com!siukic@UB.com Tue Aug 24 12:05:07 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07481; Tue, 24 Aug 93 12:05:07 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA05827; Tue, 24 Aug 93 12:04:58 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA06793; Tue, 24 Aug 93 12:02:53 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA26044; Tue, 24 Aug 93 12:02:52 PDT Date: Tue, 24 Aug 93 12:02:52 PDT From: siukic@milpitas.lmc.com (Siuki Chan) Message-Id: <9308241902.AA26044@fiji.lmsi.com> To: Will_Hobbs@ccm.hf.intel.com Subject: Upload and download procedure for IBIS model in vhdl.org Cc: ibis@vhdl.org Will, This is a description of the IBIS model repository set up on the VHDL International: vhdl.org machine. directory structure ------------------- The directory structure for models from different IC vendors under ibis will be: pub/ibis/models/intel <- intel directory /motorola <- motorola directory /ti <- texas instruments Each IC vendor will have a separate directory and each vendor will be responsible for the data within its directory. There is a disclaimer in the models directory so that VHDL International will not be held responsible for the data content in these directories and each vendor is encouraged to have its own disclaimer. A common directory format is set for easier access to the information. Within each directory, a '00README' will list all the files and a short description of the file contents (ie parts) within each file. A file may have more than 1 part. User should get a copy of the '00README' first to decide which file he/she needs without a bulk transfer of all the files in the directory. upload ------ There are several options to upload models into the directory: - the most effective way is for you to become an individual ($100/yr) technical member of VHDL International so that you can get an account on the machine. In that case, you can do all the administration work via Internet access or dialup. - the other method is for the IC vendor emails the model file(s) to me (siukic@vhdl.org) and I can move it to the right place. The file will be updated within 1 week. It is up to the IC vendor to check the directory content in case the email may be lost due to whatever reasons. download -------- These are many easy ways to download models from vhdl.org(IP address 198.31.14.3): The procedures below is not limited to getting models from IBIS, interested public is welcomed to look at the mail archive, past minutes and standard documents in the IBIS area. - via email: There is an automatic procedure which responds to email requests to the archive server. These are the steps for a new user to locate models he/she needs. Within each step, the user emails this message to archive@vhdl.org. The email looks like this, the content will be different as listed within each step. To: archive@vhdl.org Subject: Content: Add this line to the body of the email in every step: path In some case the return address in the email is not efficient or accurate. This is to tell the archive server explicitly where to send the reply. 1. get a list of IC vendors: index pub/ibis/models 2. With the IC vendor name, he/she can get a list of what is in a particular IC vendor directory. For example, intel. send pub/ibis/models/intel/00README index pub/ibis/models/intel This will return a copy of the intel readme of what is available and list of files in the directory. 3. User may get a file in the Intel directory by this message: send pub/ibis/models/intel/abc.ibs 4. To get further help, email a message to the archive server with only the path command. A detailed instruction of how to use the archive server will be returned. - via dial up line: dial (408)945-4170 and login as 'guest'. Use your email address as the password. 'cd pub/ibis' to get in to ibis directory area. File can be download using kermit or xmodem. The data modem is compatible to CCITT V.32 bis, V.32, V.22 bis. - via ftp: If the user has access to internet, he/she can ftp to the vhdl machine by 'ftp vhdl.org' as account 'anonymous'. After he/she has logged in to the machine, "cd pub/ibis/models' and use ftp commands:"get", "cd" and "ls" to retrieve the file. - via gopher: use command 'gopher vhdl.org' if user has access to Internet. gopher navigate the file system hierarchically. User can go to the pub/ibis/models and choose the IC vendor and model file by going down the file system. User can view and then retrieve the right file(s) to his/her local file system. Compared with ftp, gopher is simpler to use. Siuki From lmsi!milpitas.lmc.com!siukic@UB.com Tue Aug 24 17:43:17 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10848; Tue, 24 Aug 93 17:43:17 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA04592; Tue, 24 Aug 93 17:43:08 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA08044; Tue, 24 Aug 93 17:40:35 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA26476; Tue, 24 Aug 93 17:40:35 PDT Date: Tue, 24 Aug 93 17:40:35 PDT From: siukic@milpitas.lmc.com (Siuki Chan) Message-Id: <9308250040.AA26476@fiji.lmsi.com> To: ibis@vhdl.org Subject: Upload and download procedures for IBIS forum IBISian, I have good news and bad news. The good news is: as soon as I sent out the upload and down load procedure, people start requesting information using the archiver server. The bad news is: before IC vendors download their models, there is nothing to offer. The reason I mentioned Motorola and TI is to serve as an example. So far the only directory in the models area is Intel. Since Intel is the founder of IBIS, I expect lots of models from them. By the way, you are encouraged to download files other than the models. So far there are past minutes, ver1.0 disk and email archive available in the IBIS account. This is a list: admin/ email.archive minutes/ models/ ver1.0/ minutes: frm4_23.txt frm5_7.txt frm6_4.txt frm5_21.txt frm6_17.txt frm7_2.txt models: disclaimer intel/ models/intel: ver1.0: n74f244n.ibs* read.me ver1_0.ibs Siuki From qdt!sal!jonp@uunet.UU.NET Wed Aug 25 09:45:13 1993 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17421; Wed, 25 Aug 93 09:45:13 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25785; Wed, 25 Aug 93 12:44:53 -0400 Received: from qdt.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 124249.13884; Wed, 25 Aug 1993 12:42:49 EDT Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00450; Wed, 25 Aug 93 09:02:59 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA29170; Wed, 25 Aug 93 09:02:58 PDT Date: Wed, 25 Aug 93 09:02:58 PDT From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9308251602.AA29170@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA03892; Wed, 25 Aug 93 09:05:03 PDT To: siukic@milpitas.lmc.com Cc: ibis@vhdl.org Subject: ported ibis_chk Siuki, I am sending you (via mailsplit per randy harr) the ported ibis_chk code for inclusion in the archive machine. there is a readme file and a set of subdirectories with each of the executables. I am NOT including source code in this transmission. have a nice day, jon powell From siukic Wed Aug 25 11:42:41 1993 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18364; Wed, 25 Aug 93 11:42:41 PDT Date: Wed, 25 Aug 93 11:42:41 PDT From: siukic (Siuki Chan) Message-Id: <9308251842.AA18364@vhdl.vhdl.org> To: jon@qdt.com, ibis@vhdl.org Subject: ibis_chk version 1.1 binary Gentlemen, Jon Powell of Quad Design has ported ibis_chk to 11 platforms+os. These binary is installed at the ibis area on vhdl.org at: ibis/ver1.1/exec These are the available platform+os under exec: alpha/ apm/ aviion/ dec3100/ hp700/ hp9000/ mips/ rs6000/ sgi/ solaris/ sun4/ Thanks again for Jon's effort. Have a nice day! Siukic@milpitas.lmc.com From bob@icx.com Fri Aug 27 14:04:34 1993 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11040; Fri, 27 Aug 93 14:04:34 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA17105 for ; Fri, 27 Aug 93 16:50:06 -0400 Date: Fri, 27 Aug 93 13:38:06 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA01862; Fri, 27 Aug 93 13:38:06 PDT Message-Id: <9308272038.AA01862@icx.com> To: ibis@vhdl.org Subject: QUESTIONS AND ISSUES Cc: bob@icx.com Greetings IBIS folks: Below are some points in IBIS Version 1.0 which I believe need clarification before Version 2.0 is finalized. Also, some issues are raised which call for some format changes, so I hope these can be resolved quickly. I. PACKAGE MODEL AND PIN MODEL What is the model? DIE----R_pkg----L_pkg----C_pkg----PIN or DIE----R_pkg----C_pkg----L_pkg----PIN The first case is used in the Pentium and PCI models from Intel and the second case exists in the TI Spice models. I would support a more robust model that allows for both cases by replacing R_pkg with C_pkd. DIE----C_pkd----L_pkg----C_pkg----PIN Based on the range of typical values and lack of specification, I believe that R_pkg has an insignificant effect in the analysis and is inserted primarily to assist in convergence when running Spice models. The substitution of "R_pkg" with "C_pkg" would be useful for these reasons: (1) Provide compatiblity with either of the first two models above (zero or NA would be one of the C_pk* entries). (2) Provide the opportunity for a better package model by distributing the C-package value. II. RAMP dV/dt_r AND dV/dt_f "MIN" AND "MAX" A presumption exists that the PULLDOWN, PULLUP, GND_CLAMP and POWER_CLAMP "min" and "max" entries are associated with the "min" and "max" VOLTAGE RANGE values so that the unloaded ramp amplitiude can be obtained from the voltage offset at 0.0 Amps. (1) For consistency and extrapolation purposes, should the "min" and "max" entries of the RAMP dV/dt_r and dV/dt_f also be associated with VOLTAGE RANGE "min" and "max" values? Or (2), should they always be the true min and max dV/dt values? Or (3), should they always correspond to the fastest and slowest time values? I have seen all three cases, but favor (1). III. Vtable DEFINITION For PULLUP and POWER_CLAMP, Vtable is defined as Vtable = Vcc - Voutput This creates an unusual polarity reversal that appears totally unnecessary. A negative entry corresponds to a positive offset from Vcc, and visa-versa. What value does this provide? A better definition would be: Vtable = Voutput - Vcc This will permit the Vtable offset entries to track with Voutput values, providing a more readable and understandable table. Offsets referenced to other supplies such as Vee would follow a similar definition for consistency and also would track with Voutput changes. I would like to see this change made before too many models are generated in compliance with the original definition. Alternatively, Version "1.X" models could conform to the original definition, Version "2.X" and above to the revised definition where the simulator handles the polarity change based on Version number. IV. SPECIFIED VOLTAGE RANGES In section 2) of "NOTES ON DATA DERIVATION METHOD" at the end, no explaination is given why the voltage ranges for the GND_CLAMP and POWER_CLAMP are different. My preference is to relax the voltage range requirements for the 2.0 release and rely on vendors providing reasonable ranges. Simulators easily can do (linear) extrapolation to go beyond the supplied ranges. The required ranges go well beyond what is reasonable for measurement correlation (an explicit goal) and extraction. For example, it is required that a clamp diode (or sensitive ESD circuit) be forward biased to, say, 5 volts in order to extract a 4 Amp current value (20 Watts !!). The "measured" value would normally have to be obtained from extrapolating values at lower voltages since a direct measurement done without using pulsing techniques would damage the device. In general, I do not believe the standard should require data that clearly falls outside a part's maximum ratings. Thanks, Bob Ross (Interconnectix, Inc.) From speters@ichips.intel.com Fri Aug 27 17:16:59 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12573; Fri, 27 Aug 93 17:16:59 PDT Received: from [134.134.16.164] by hermes.intel.com (5.65/10.0i); Fri, 27 Aug 93 17:16:43 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 27 Aug 93 17:16:14 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 27 Aug 93 17:16:10 PDT Message-Id: <9308280016.AA17149@xtg801.intel.com> To: ibis@vhdl.org Cc: speters@ichips.intel.com Subject: IBIS Ver 1.0 Comments Date: Fri, 27 Aug 93 17:16:09 PDT From: speters@ichips.intel.com Greetings IBIS Gentle folk -- I would like to respond to a couple of Bob Ross's comments on Version 1.0 of the specification. 1. In regards to the package and pin model, I believe the IBIS spec assumed the model shown below: DIE-----/\/\/-----CCCCC-------PIN (R) (L) | | --- (C) --- | | GND However, I think the suggestion of removing the series R and distributing the capacitance is right on the mark. It should allow IBIS to handle large ceramic PGA packages (A.K.A. miniature helecoptor landing pads) where the bondwire/leadframes are long enough to be considered transmission lines. My only question is, what exactly is C_pkg and how is it measured (is it a calculated value based on the Zo of the wire)? Please reply. 2. In regards to the specified voltage ranges: The reason that the ranges are (apparently) so extreme is to take into account the effects of driving an unterminated transmission line. Remember that when an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, the power clamp diode on a CMOS (0 to 5v) output could have to clamp a 10v reflection. (Likewise, the gnd clamp diode must be able to handle a -5v reflection). That is the reason for specifying a range of POWER + POWER for the power_clamp and GND - POWER for the grd_clamp. I agree that most everyone is going to extrapolate the clamp diode curves to those ranges when they fill in the table. The effort in the spec was, I believe, to make sure that sufficient data was included (i.e. make sure it went well beyond the knee of the diode curve). Best Regards, Stephen Peters Intel Corp. From 71436.1314@CompuServe.COM Sun Aug 29 23:02:50 1993 Return-Path: <71436.1314@CompuServe.COM> Received: from iha.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02831; Sun, 29 Aug 93 23:02:50 PDT Received: by iha.compuserve.com (5.67/5.930129sam) id AA17017; Mon, 30 Aug 93 02:02:21 -0400 Date: 30 Aug 93 02:00:02 EDT From: Kellee Crisafulli <71436.1314@CompuServe.COM> To: IBIS ALL Subject: R package parameter (why we have it) Message-Id: <930830060001_71436.1314_BHA38-1@CompuServe.COM> Hello IBIS I would like to comment on the past couple of Emails regarding why we have an R package parameter. I agree that it is not exceedingly useful for standard IC packages it is however useful for MCM's. If we get to the point in the near future where more MCM's are treated as IC's by design engineers than we will want to address them with IBIS. Along that vein of thought the R package can now be significant due to the long 'Al' interconnects possible on an MCM -> larger R. The would also need to be distributed. Along the line of treating C package as a distributed element, HyperLynx agree's and has been doing this since day 1 in our model. The C pin is treated as a lump though. Best regards to all; Kellee From bob@icx.com Tue Aug 31 16:35:28 1993 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21815; Tue, 31 Aug 93 16:35:28 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA21839 for ; Tue, 31 Aug 93 19:24:15 -0400 Date: Tue, 31 Aug 93 16:14:55 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA09660; Tue, 31 Aug 93 16:14:55 PDT Message-Id: <9308312314.AA09660@icx.com> To: ibis@vhdl.org Cc: bob@icx.com Greetings IBIS folks: Thank you for your responses so far regarding the recent email clarification issues and concerns. Regarding Steven Peter's comments on the reason for the voltage ranges, the extension of the GND_CLAMP model to POWER in the REVERSED BIASED direction makes sense with repect to handling a reflected wave. However, the POWER_CLAMP range should extend to GND (Rather than just to POWER) for the same reason in the REVERSED BIASED direction. The only reason I can think of for not extending the POWER_CLAMP is that it's characteristics can be concatenated with the GND_CLAMP characteristics to form an INPUT model (or model for I/O or 3-STATE in the input mode). In the FORWARD BIASED clamping direction in a transmission line environment, the algorithm may see initially the full voltage signal, but would eventually converge to a much lower value based on the non-linear VI clamping characteristics in conjunction with the characteristic impedance of the line. If, for example, there is a -5 Volt reflected step signal in a 50 Ohm line, the maximum current seen at the termination end of a GND_CLAMP cannot initially exceed 100 milliAmps, thus eventually causing the convergence to a voltage value at much less than 5 Volts at the clamping end. Since the -5 Volt signal comes from undershoot, it would not normally provide a buildup of voltage across the clamp over several reflection intervals. So I think it is reasonable for IBIS to accomodate a vendor supplied reduced voltage range (e.g., whatever voltage produces a several hundred milliAmp response) in the FORWARD BIASED direction. However, it may be easier for convergence algorithms to have an explicit point at the forward biased POWER value. Regarding the package model, several techniques exist to extract the L and C components ranging from measurement to mathematical extraction based on geometry. When the results are presented as a single LC lump - as is commonly done for only a first order approximation, it might be arbitrary where to place the C. Both choices have appeared in practice. I can accept Kellee Crisafulli's justification on R_pkg for future MCM macomodeling capability. But an alternative might be to include the R characteristics in the PULLUP and PULLDOWN data. However, this solution does not deal with R being distributive. As a final note, please do not interpret my comments as being negative. I think the work done to date has been excellent. Thanks, Bob Ross (Interconnectix, Inc.) From ccm!Arpad_Muranyi@intelhf.intel.com Wed Sep 1 17:40:12 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02018; Wed, 1 Sep 93 17:40:12 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0oY2i7-000MPFC; Wed, 1 Sep 93 17:39 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0oY2nN-00004PC; Wed, 1 Sep 93 17:45 PDT Received: by ccm.hf.intel.com (ccmgate) Wed, 1 Sep 93 17:45:01 PST Date: Wed, 1 Sep 93 17:45:01 PST From: Arpad Muranyi Message-Id: <930901174501_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: response to some IBIS questions Hello IBIS folks, I just want to clarify a few things regarding the packaging circuit and other items mentioned in the recent EMAILs. In regards to the package and pin model, the IBIS spec assumed the following circuit: R L DIE---------RRRRR-----LLLLL-------PIN | | | | === C_comp === C_pkg | | | | GND GND C_comp represents the parasitic capacitance of the output transistors. It is used because the V/I curve based behavioral output structure does not represent any capacitances. Therefore, C_comp can not be omitted. The RLC circuit represents the Ohmic resistance, inductance and capacitance of the bond wire and pin. If you like, you can view it as a lossy transmission line, modeled in a single lump. (The U-lines in HSPICE are done the same way, except one can control the number of lumps with the WLUMP and MAXL parameters). Since the length of the bond wire and pins are relatively short in a normal package, I thought we did not need to complicate matters unnecessarily by distributing the values over many lumps. However, just because IBIS gives the single lumped values, it does not mean that a simulation tool vendor could not distribute them, as HyperLinx did it "from day 1", or model it as a lossy transmission line. Even though its effect is small, I would NOT remove the series resistor, because it is part of the lossyness of the lossy transmission line. Even though I personally have not done these measurements, I know that we (Intel) measure these values (L and C) with an HP 4192 L/F impedance analyzer. Another way to obtain these values is with the IPA310 system (Interconnect Parameter Analyzer) developed by Tectronix recently. That equipment will give you these values directly, but it is also capable of much, much more. Regarding Bob's suggestion about combining R_pkg into pull up and pull down: "I can accept Kellee Crisafulli's justification on R_pkg for future MCM macomodeling capability. But an alternative might be to include the R characteristics in the PULLUP and PULLDOWN data." I do not believe in combining things like that. Package and die modeling should be kept separate (i.e. stay modular) so that if a new revision occurs in one area, e.g. package, it should be easy to change things whithout effecting the other area. Besides, many vendors do it this way already, why should we be different. Voltage ranges, clamping diodes: -------------------------------- Steven Peters is right about explaining the extreme voltage ranges. Simulators usually do not simulate part break down, I mean burn up. Just because a real part might blow up by being continuously forward biased around 2-3 volts, it does not mean that they can not handle short 2-3 V spikes. Since reflections may result in such or even greater voltages, we must define the diodes beyond that range to get the realistic clamping effects. You must also remember that these clamping effects can also be considered as the diode being a driver trying to pull back the signal to where it should be. This "driven clamping edge" goes back down the line as a signal, and can not be ignored. As a bad example, NOT TO BE FOLLOWED, let me bring it up here that I have seen some silicon models where they characterized the device only between -0.6 and Vcc+0.6 volts in such a way that the clamping currents were tens of kilo-Amps (10*10^3 Amps) at about 0.8 - 0.9 volts already when I did a DC sweep on it! This is essencially a perfect clipping, but as I said before, this "clipping edge" goes back down the line as a signal too. Therefore, I believe the best solution is if we define the V/I curve, even if we need to extrapolate it. It is true that simulators can do the extrapolations easily, but they don't all do it. In HSPICE (and maybe other SPICE flavors also) if you define the diode up to let's say 500 mA @ -2 V (using a PWL current source), it will give you 500 mA at all voltages below -2 V. To answer Bob's question: "In section 2) of "NOTES ON DATA DERIVATION METHOD" at the end, no explaination is given why the voltage ranges for the GND_CLAMP and POWER_CLAMP are different", I must say that they were originally the same. They used to be: -POWER to GND for the ground clamp and VCC to VCC+POWER for the vcc clamp. We (IBIS folks) changed this in the meetings to be what it is now, so that the 3-stated leakage currents could be also included some way. Therefore the range between the GND and POWER voltage can be used for this purpose on the ground clamp. To answer Bob's 2nd comment: "Regarding Steven Peter's comments on the reason for the voltage ranges, the extension of the GND_CLAMP model to POWER in the REVERSED BIASED direction makes sense with repect to handling a reflected wave. However, the POWER_CLAMP range should extend to GND (Rather than just to POWER) for the same reason in the REVERSED BIASED direction. The only reason I can think of for not extending the POWER_CLAMP is that it's characteristics can be concatenated with the GND_CLAMP characteristics to form an INPUT model (or model for I/O or 3-STATE in the input mode)". Well, the ground clamp is NOT going to do much with reflected waves in its reverse biased region. When the device in not 3-stated, the pulldown transistor, or the pull up transistor is a lot more active in that region, so they will handle all the reflections without the help of a few uA of lekage current from the diode. When they are 3-stated, a few uA of lekage current is going to look like an open to the reflections. So the real reason to have that additional range there for the ground clamp is to be able to model a 3-stated situation (mostly to find a DC operating point). Bob's statement about: "In the FORWARD BIASED clamping direction in a transmission line environment, the algorithm may see initially the full voltage signal, but would eventually converge to a much lower value based on the non-linear VI clamping characteristics in conjunction with the characteristic impedance of the line. If, for example, there is a -5 Volt reflected step signal in a 50 Ohm line, the maximum current seen at the termination end of a GND_CLAMP cannot initially exceed 100 milliAmps, thus eventually causing the convergence to a voltage value at much less than 5 Volts at the clamping end. Since the -5 Volt signal comes from undershoot, it would not normally provide a buildup of voltage across the clamp over several reflection intervals." Yes, BUT if one has a 10 Ohm line and a week clamping diode, which can give you about 0.5 Amps at -5 volts, then the undershoot will be -5 V, if we calculate as Bob did. Therefore it is better to be safe than sorry, and define the diodes to -5 V (or make sure that all simulators on the world extrapolate the way they should). Regarding the Vtable DEFINITION comments of Bob: ------------------------------------------------ When I designed the behavioral models on HSPICE, I approached this issue from an arbitrary, but somewhat more theoretical viewpoint. I decided to be in the positive voltage range for the active part of the V/I curves and in the negative range for the "clamping" part of the V/I curves. (To clarify myself, by the active region I mean the 0 to 5 volt range of the pull down, and the 5 to 0 volt range for the pull up transistors, these numbers with respect to GND now). Thus as the voltage becomes more and more positive across the transistor, the transistor turns on more and more. This provides a nice symmetry, in my opinion. What does this have to do with "offset from Vcc"? The Vcc-relative approach is not done with the purpose of being in the same offset direction from the Vcc pin. Since Bob's recommendation would just simply turn the polarity around for the voltages in the pull up table, it really does not matter to me whether they are positive or not in the above mentioned active range. Is that really that much easier to read and understand? Does that really give more value to IBIS? If all of our IBIS fellows agree, I don't mind to change it... Don Telian strongly wants to keep it as it is, though, since we already distributed hundresds of models this way. Regarding dV/dt: ---------------- To answer Bob's question: "For consistency and extrapolation purposes, should the 'min' and 'max' entries of the RAMP dV/dt_r and dV/dt_f also be associated with VOLTAGE RANGE 'min' and 'max' values?" YES, this is outlined in IBIS 1.0 towards the end: -------------------------------------------------------------------------------- | 6. Typ, Min, and Max must all be posted, and are derived at the | | same extremes as the V/I curves, which are: | | | | Ramp times for CMOS devices: | | typ = nominal voltage, 50 degrees C, typical process | | min = low voltage tol, 100 degrees C, typical process, minus "Y%" | | max = hi voltage tol, 0 degrees C, typical process, plus "Y%" | -------------------------------------------------------------------------------- Sincerely Arpad Muranyi Intel, Coprporation From lmsi!milpitas.lmc.com!siukic@UB.com Thu Sep 2 11:43:47 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08950; Thu, 2 Sep 93 11:43:47 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA04810; Thu, 2 Sep 93 11:32:59 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA17351; Thu, 2 Sep 93 11:13:42 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA03116; Thu, 2 Sep 93 11:13:41 PDT Date: Thu, 2 Sep 93 11:13:41 PDT From: siukic@milpitas.lmc.com (Siuki Chan) Message-Id: <9309021813.AA03116@fiji.lmsi.com> To: ibis@vhdl.org Subject: Intel PCI ibis v1.1 models available. IBISians, Stephen Peters of Intel just submitted a set of Intel PCI ibis v1.1 models. They are located in /pub/ibis/models/intel. To get a copy of the read.me and a list of file names in the directory, send this message to archive@vhdl.org: path send /pub/ibis/models/intel read.me index /pub/ibis/models/intel Please also read /pub/ibis/models/disclaimer. IBIS model is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Siuki Chan Logic Modeling Corp From speters@xtg801.intel.com Wed Sep 8 09:36:13 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07534; Wed, 8 Sep 93 09:36:13 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 8 Sep 93 09:35:55 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 8 Sep 93 09:35:51 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 8 Sep 93 09:35:51 PDT Message-Id: <9309081635.AA22688@xtg801.intel.com> To: ibis@vhdl.org Cc: speters@ichips.intel.com Subject: Rev 2.0 items for discussion Date: Wed, 08 Sep 1993 09:35:48 -0700 From: Stephen Peters Greetings Gentlemen -- I've been keeping an informal list of the issues we have discussed regarding Rev 2.0 of the spec. The following enhancements have been proposed and, if there are no objections, I believe that we should get closure on (i.e. officially adopt) the first two items below. 1. Proposal to add the key words [Voltage HIGH Range] and [Voltage LOW Range] to be used for devices with dual supplies. For specific details refer to Kellee Crisafulli's e-mail of July 28. 2. Proposal to add the choice of 'ECL' to the Model_type sub-parameter of the [Model] keyword. When this choice is made the [Pullup] and [Pulldown] tables become the 'high logic level' and 'low logic level' output characteristics respectively, and the voltages in both tables are referenced to the most positive (VCC) rail. In addition, the following topics are under active discussion. As best I can summarize: 1. In order to accurately model the effects of changing VCC on the output characteristics of a device, Arpad Murani has suggested using a scaling factor that would enable a simulator to adjust the output curves for VCC (and eventually temperature) on the fly. The scaling factor would eventually replace the 'min, typ, max' type of specification (?). 2. Also under discussion is how to best handle packages whose bond wires/ lead frames are long enough to be considered transmission lines. It has been proposed to distribute the L and C values. My questions is, does the current spec contain all the information needed or is there something else to add. If there is anything I have missed please email the IBIS forum. Hope to hear from everyone Friday. Best Regards, Stephen Peters Intel Corp. From bracken@valhalla.performance.com Wed Sep 8 12:57:57 1993 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08660; Wed, 8 Sep 93 12:57:57 PDT Received: by valhalla.performance.com (4.1/SMI-4.1) id AA14567; Wed, 8 Sep 93 15:56:31 EDT Message-Id: <9309081956.AA14567@valhalla.performance.com> To: Stephen Peters Cc: ibis@vhdl.org Subject: Re: Rev 2.0 items for discussion In-Reply-To: Your message of "Wed, 08 Sep 93 09:35:48 PDT." <9309081635.AA22688@xtg801.intel.com> Date: Wed, 08 Sep 93 15:56:26 -0400 From: bracken@valhalla.performance.com IBIS-onians, Stephen Peters writes: >> Also under discussion is how to best handle packages whose bond wires/ >> lead frames are long enough to be considered transmission lines. It >> has been proposed to distribute the L and C values. My questions is, >> does the current spec contain all the information needed or is there >> something else to add. L & C are fine so long as it's just a single transmission line. It seems to me that if we want to go to this level of detail, using transmission line models for the package, we should also probably be considering the discontinuities that occur as a signal travels from bond wire to lead frame to package pin. These could give rise to reflections, etc. that can't be modeled by a single uniform line. A really rigorous model would have a separate transmission line model for each piece. >> If there is anything I have missed please email the IBIS forum. Crosstalk/noise due to the package: eventually we're going to need to address the mutual inductances/capacitance couplings between pins, lead frame wires and bond wires. This data may be unavailable from some Si vendors, and the tool vendors might be unable to use it immediately, but shouldn't we anticipate this need in the Version 2.0 spec? Eventually the customers will be demanding crosstalk/ground bounce analyses... Have a pleasant day, Eric Bracken Performance Signal Integrity, Inc. From lmsi!milpitas.lmc.com!randyh@UB.com Thu Sep 9 15:28:55 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20798; Thu, 9 Sep 93 15:28:55 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA15322; Thu, 9 Sep 93 15:22:26 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA08787; Thu, 9 Sep 93 15:19:44 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA05050; Thu, 9 Sep 93 15:19:44 PDT Date: Thu, 9 Sep 93 15:19:44 PDT From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9309092219.AA05050@fiji.lmsi.com> To: ibis@vhdl.org Subject: Few clarifications / corrections from minutes a) The vhdl.org machine is worldwide accessable (in fact, as easily accesable via email or Internet as any "local" machine). The only possible accessible drawback is the dial-up access. But this is just an additional service for those without email access. Obviously, everyone on the reflector has email access and thus has full access to vhdl.org. Many countries / states have local companies providing Internet email/net access for a monthly fee. This is a cheaper alternative to those without email and not local to the vhdl.org '408' area code access for dial-up. VI and vhdl.org has as many users from Europe, Middle East, and Asia as the USA. b) An easier method to submit "models" than emailing them to siuki chan is to email them to "incoming@vhdl.org". Then email siuki (siuki.chan@vhdl.org) a message that you sent it there and he can more easily retrieve and install it. The easiest method is to get an account on the machine. Contact CMS about that. c) We setup an ibis-info email alias also. It forwards to Will Hobbs currently but can be changed to simply send a response message (file) to whoever mails to it. d) The BBS has not received the source yet and so, after sending your $500., we cannot give you a password to get to it. The binaries for the golden parser are on-line though. e) CMS's email address is actually merry.bush@vhdl.org. The printed address is not checked as regularly. f) Remember all messages over the reflector are archived in a file named pub/ibis/email.archive (and eventually email.archive.<3Q93, 4Q93, ... or aug, sep, etc. depending on load.) If there are older communications that occurred before this recording started (about mid-august), then email the message text to siuki and he can add it to the file. g) Just for further clarification; public access to the vhdl.org machine archive is as follows: Address Login Name Internet FTP vhdl.org (198.31.14.3) anonymous Internet Telnet vhdl.org " guest Dial-up 408.945.4170 guest email archive@vhdl.org gopher gopher.vhdl.org The password (if required) is simply your email address. h) I let Will and I slip on the press release. Thanks for all the calls of concern as to whether you were included or not. We will be getting back to this shortly. Randolph E. Harr, Logic Modeling Corp., randyh@lmc.com From speters@ichips.intel.com Fri Sep 10 15:08:27 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02010; Fri, 10 Sep 93 15:08:27 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 10 Sep 93 15:08:05 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 10 Sep 93 15:08:02 -0700 Received: by xtg801.intel.com (4.1/10.0i); Fri, 10 Sep 93 15:08:01 PDT Message-Id: <9309102208.AA28813@xtg801.intel.com> To: cpk@cadence.com Cc: ibis@vhdl.org, speters@ichips.intel.com Subject: Primer on ECL logic Date: Fri, 10 Sep 1993 15:08:01 -0700 From: Stephen Peters Hello Fellow Ibisians -- As promised during the open forum: VCC (0v) --------------------------------------------------------- | | | | | | R1 R2 | R1 R2 | R1 R2 | | | / | | | | |---------------------| Q3 | | | | | \ / \ | | | | INPUT ------| Q1 Q2 |--- VREF (-1.4) | | | ---------------- OUTPUT \ / | | | | | | | | | RT ----------------- RT | RT | | | | ----- | Constant current ---- sink VTT (-2v) ----- | | | VEE (-4.5v) The above is a highly simplified schematic of an ECL logic gate. ECL logic levels swing between -.9v to about -1.8v, centered around the VREF voltage reference inside the chip. Assume for a moment that the INPUT is at -.9v. Because Vbe across Q1 is much greater than that across Q2, Q1 supplies the current required by the constant current sink and little current flows thru the collector of Q2. Will little voltage drop across R2, the base of Q3 is pulled towards the positive rail which in turns pulls the OUTPUT node more positive. Now assume that the INPUT node is at -1.8v. Q1 will be close to cutoff and the current required by the constant current sink is supplied by Q2. The voltage drop across R2 increases, thus pulling the base of Q3 low and the OUTPUT node goes along with it. As you can see, the difference between an output in a 'high' (more positive) state and an output in a low (more negative) state is simply the voltage at the base of the output emitter follower xsistor. In fact, in regards to generating VI curves, what you are really graphing is the Ie Vs. Vbe characteristics of the output xsistor; in one case Vb is at -.3v, in the other it is at -1.2v. In either case, the output voltage is always referenced to the VCC rail. I hope this diagram and explanation helps. For those that are really interested I suggest the "MECL Design Handbook" by William Blood from Motorola. Best Regards, Stephen Peters Intel Corp. From cpk@Cadence.COM Mon Sep 13 06:56:56 1993 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26469; Mon, 13 Sep 93 06:56:56 PDT Received: from cadence.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA09708; Mon, 13 Sep 1993 06:55:03 -0700 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA20952; Mon, 13 Sep 93 06:38:08 -0700 Received: by hot (5.65+/1.5) id AA03537; Mon, 13 Sep 93 09:53:05 -0400 Date: Mon, 13 Sep 93 09:53:05 -0400 From: cpk@Cadence.COM (C. Kumar) Message-Id: <9309131353.AA03537@hot> To: speters@ichips.intel.com Subject: Re: Primer on ECL logic Cc: ibis@vhdl.org Thanx for the fast response. Following is my two cents worth: The output current is always a function of both the rail voltages. So it is not enough if ibis specifies that both the v-i are referenced to the most positive rail. There should be an explicit additional specification as to what the other rail voltage is. (Acutally I think in general explicit specification of both the rail voltages at the measurement point is always necessary). - Kumar From lmsi!milpitas.lmc.com!siukic@UB.com Mon Sep 13 09:30:39 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27625; Mon, 13 Sep 93 09:30:39 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA29130; Mon, 13 Sep 93 09:15:19 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA19542; Mon, 13 Sep 93 08:57:48 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA05935; Mon, 13 Sep 93 08:57:47 PDT Date: Mon, 13 Sep 93 08:57:47 PDT From: siukic@milpitas.lmc.com (Siuki Chan) Message-Id: <9309131557.AA05935@fiji.lmsi.com> To: speters@ichips.intel.com Subject: Re: Primer on ECL logic Cc: ibis@vhdl.org Hi Stephen, This is another two cents worth of advice about the difference of CMOS and ECL as I can see: For the CMOS output buffer, without looking inside the circuit, one technique to find the voltage reference is: sweep the output node voltage until the current is 0. The neccessary conditions for this to happen is only one of the device is on, and it is operating in the common-source mode (which means the gate and source voltage determines the on/off of the transistor). In ECL, the output stage in common-emmitter mode and both pull-up and pull-down device are on. Therefore output current will zero somewhere between 0 and VTT, the voltage is around Iq2 * R2 + 0.6, assume Vcc==0. The reference voltage for each state will be a function of Iq2 instead of a voltage. Of course, Iq2 is the function of the input voltage at Q1. Siuki Chan Logic Modeling ----- Begin Included Message ----- From Cadence.COM!cpk@lmc.com Mon Sep 13 07:09:14 1993 Date: Mon, 13 Sep 93 09:53:05 -0400 From: Cadence.COM!cpk@lmc.com (C. Kumar) To: speters@ichips.intel.com Subject: Re: Primer on ECL logic Cc: ibis@vhdl.org Content-Length: 456 Thanx for the fast response. Following is my two cents worth: The output current is always a function of both the rail voltages. So it is not enough if ibis specifies that both the v-i are referenced to the most positive rail. There should be an explicit additional specification as to what the other rail voltage is. (Acutally I think in general explicit specification of both the rail voltages at the measurement point is always necessary). - Kumar ----- End Included Message ----- From squeak@lobby.ti.com Mon Sep 13 11:35:13 1993 Return-Path: Received: from lobby.ti.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00271; Mon, 13 Sep 93 11:35:13 PDT Received: by lobby.ti.com (5.65c/LAI-3.2) id AA26882; Mon, 13 Sep 1993 13:38:26 -0500 Date: Mon, 13 Sep 1993 13:38:26 -0500 From: squeak@lobby.ti.com (Bob Ward) Message-Id: <199309131838.AA26882@lobby.ti.com> To: ibis@vhdl.org Subject: ECL primer As a followup to the observation Siuki makes about finding the reference for a CMOS driver, beware, because you will get to Vth, the threshold voltage of the driver transistor that is on, of the reference voltage and the transistor will turn off. You cannot make assumptions about the magnitude of the threshold voltage as some manufactures back bias the transistors for any number of reassons, which results in shifting the threshold voltage, sometimes quite a lot. So unless you are privy to this circuit detail, you will have an unknown error in this measurement. Even if you know that back bias is present, and if you knew how much, you still can't determine the Vth shift without process details, say from a Spice model. Sincerely, Bob Ward From pzc@Cadence.COM Tue Sep 14 11:51:46 1993 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11510; Tue, 14 Sep 93 11:51:46 PDT Received: from cadence.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA07376; Tue, 14 Sep 1993 11:50:48 -0700 Received: from valideast.cadence.com by cadence.Cadence.COM (5.61/3.14) id AA24291; Tue, 14 Sep 93 11:33:41 -0700 Received: from [158.140.113.2] by valideast.cadence.com (4.1/cosmic.CADENCE.COM/1.6) id AA03744; Tue, 14 Sep 93 14:48:46 EDT Date: Tue, 14 Sep 93 14:48:45 EDT Message-Id: <9309141848.AA03744@valideast.cadence.com> To: ibis@vhdl.org From: pzc@Cadence.COM (Pawel Z. Chadzynski) Subject: Re: Trademark search Cc: bobv@Cadence.COM, ori@Cadence.COM, zaki@Cadence.COM Hello, Judging from the note below we do have a problem with IBIS as a trademark. The search was performed by Cadence staff at no cost. Any suggestions on how to proceed? >The IBIS preliminary search shows several direct "hits" against us adopting >the mark IBIS....therefore, we cannot recommend that you adopt this name. >Please let me know if we can be of further help. > From speters@ichips.intel.com Wed Sep 15 09:06:55 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20040; Wed, 15 Sep 93 09:06:55 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 15 Sep 93 09:06:33 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 15 Sep 93 09:06:26 -0700 Received: by xtg801.intel.com (4.1/10.0i); Wed, 15 Sep 93 09:06:25 PDT Message-Id: <9309151606.AA05968@xtg801.intel.com> To: ibis@vhdl.org Cc: speters@ichips.intel.com Subject: Re: ECL logic Date: Wed, 15 Sep 1993 09:06:25 -0700 From: Stephen Peters Greetings Fellow IBISans -- I like to add a little comment to Kumar's observation (from Siuki Chan's previous email) that "The output current is always a function of both rail voltages" If one is refering to the VEE rail then yes, strictly speaking, the output voltage does vary with VEE, but the sensitivity is on the order of mV/V. Both the VBB reference and the constant current sink are designed to be insensitive to VEE changes (at least in all modern ECL logic families). I do agree that for completeness sake when defining the conditions for MIN and MAX we state at what VEE the measurments are taken. (As an aside, ECL vendors usually publish both dVout/dVEE and dVout/dTEMP specs for their logic families. This is a perfect example illustrating Arpad Muranyi's concept of supplying a V-I curve and then using scalling factors to adjust the output for tempurature or other variations.) Sincerely, Stephen Peters Intel Corp. From ccm!Don_A_Telian@intelhf.intel.com Wed Sep 15 15:44:31 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23157; Wed, 15 Sep 93 15:44:31 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0od5c8-000MOsC; Wed, 15 Sep 93 15:46 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0od5eu-00011sC; Wed, 15 Sep 93 15:49 PDT Received: by ccm.hf.intel.com (ccmgate) Wed, 15 Sep 93 15:49:07 PST Date: Wed, 15 Sep 93 15:49:07 PST From: Don A Telian Message-Id: <930915154907_5@ccm.hf.intel.com> To: John_M_Keifer@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org Cc: Randy_L_Wilhelm@ccm.hf.intel.com Subject: IBIS Issue Resolution Process Howdy, 9/15/93 As discussed in last Friday's Open Forum... The following is your key to getting changes or enhancements into the IBIS specification. It's called a "Buffer Issue Resolution Document" or "BIRD". Issues must be well thought out and clearly documented using this template to be placed on the agenda of a future IBIS Open Forum. Here's how the process works. Write up your issue and submit it to Will. Will's group will do a preliminary check for completeness and (potentially) send your BIRD back to you. If not, Will will post the issue to the reflector. Each issue must be out for review for two weeks before the Open Forum will vote on it. During that time, you will be expected to answer questions related to your BIRD. In each meeting announcement, Will will list those BIRDs that are ready for a vote at that meeting. A BIRD will be accepted if EVERYONE at the meeting agrees with it. Please note that Open Forum time will not be used for detailed BIRD review, but rather for confirming consensus. Detailed review MUST ensue during the two-week review cycle via emails. Dissenters should not wait until the Open Forum to express their opinions. This process is intended to be used only for issues that would alter the IBIS Specification (for example, anything going into 2.0 will use this process). General discussion topics will still be entertained in the Open Forum (and carried on through the reflector) without this level of rigor. So far the group has been exceedingly cooperative, achieving a 1.0 spec in only a couple months. Hopefully this process will allow us to use time more efficiently, while maintaining the same flavor in the larger group setting. Regards, Don Telian NOTE: All text in french brackets is for explanation only and should be deleted. ---------------------------- cut here ----------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: {don't fill in, will be filled in by Will Hobbs for tracking} ISSUE TITLE: {one line description of your issue} REQUESTOR: {your name and company} DATE SUBMITTED: {date you sent to Will} DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: {Place a short description of your issue here. People should be able tell by reading this if they care about this in less than 1 minute.} ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: {For new keywords, write the text EXACTLY AS IT SHOULD APPEAR in a future IBIS specification. If this is a change, state the old text and the new text again EXACTLY AS IT SHOULD APPEAR. Be sure to give intended location in the specification.} ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: {There are many "experts" reviewing this document. Your reasons, analysis, and justifications must be precise and well documented, or your BIRD will be sent back to you. Use this section to show that you've done your homework, and answer all questions that will undoubtedly be asked. If your issue is a change instead of an enhancement, document how backward compatibility is to be addressed.} ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} ******************************************************************************* From ccm!Don_A_Telian@intelhf.intel.com Thu Sep 16 09:43:36 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00723; Thu, 16 Sep 93 09:43:36 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0odMSN-000MPRC; Thu, 16 Sep 93 09:45 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0odMVG-0000teC; Thu, 16 Sep 93 09:48 PDT Received: by ccm.hf.intel.com (ccmgate) Thu, 16 Sep 93 09:48:18 PST Date: Thu, 16 Sep 93 09:48:18 PST From: Don A Telian Message-Id: <930916094818_5@ccm.hf.intel.com> To: ibis@vhdl.org Subject: EDN Article and IBIS Howdy, I don't know how clear it was at the meeting, but I wanted to again point out the article in EDN which I believe is pertinent to IBIS. Please reference "Treat pc-board traces as transmission lines to specify drive buffers", EDN Sept. 2 1993 page 129. The article shows that the best way to design/qualify a buffer for proper AC operation is by referencing its V/I curve (and not its DC sink current). Furthermore, it's the best way to achieve similar drive capabilities across various vendors and processes (a concept I've been able to convince Intel of as we create "compatible" chipsets and processors). For the first time (that I'm aware of) it's quite clear what's meant by a "PCI driver." All of us probably would have seen a lot less manufacturing problems if "LS" or "F" parts were equated through their V/I curves rather than "24mA", "64mA", or some such nonsense, across vendors. And yes, I'm aware that this doesn't work with certain types of buffers (which we feel are handled by T/V/I). But I think it's a good start if people begin looking at where dynamic performance really comes from. And for IBIS, the data and methods are akin to the underlying structure. Comments? Don Telian From ccm!Arpad_Muranyi@intelhf.intel.com Mon Sep 20 19:11:00 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13366; Mon, 20 Sep 93 19:11:00 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0oexDl-000MOgC; Mon, 20 Sep 93 19:12 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0oexH6-0000taC; Mon, 20 Sep 93 19:16 PDT Received: by ccm.hf.intel.com (ccmgate) Mon, 20 Sep 93 19:16:16 PST Date: Mon, 20 Sep 93 19:16:16 PST From: Arpad Muranyi Message-Id: <930920191616_8@ccm.hf.intel.com> To: ibis@vhdl.org Subject: 3D, or I/V/T models Hello IBIS folks, On your request, here is a little summary on the 3D or I/V/T representation of buffers. To simplify the following discussion I will only consider the pulldown part of an output buffer, which is nothing but an Open-Drain output. In this case the Drain of the transistor is connected to the output of the buffer, the Source is connected to GND, and the Gate is driven by the pre-driver circuitry. With the current V/I curve approach we only characterize the DC steady state conditions of the transistor after it has been completely turned on. This means that when we sweep the Drain of the transistor to obtain a V/I curve, its gate voltage is at maximum (5V). If we want to characterize the switching characteristics of the transistor while it is being turned on (i.e. while its gate voltage is transitioning from 0V to 5V), we would have to take a family of V/I curves at various gate voltages. There is nothing new in this idea, most transistor data books publish such family of curves for both FETs and BJTs. Our problem is that it is very difficult or impossible to access the voltage waveform on the gate of an output transistor. However, we can look at the output current on the Drain as a function of two variables which are the Gate-Source and the Drain-source voltages. By the superposition principle, to measure the effects of the Gate-Source voltage on the output current we can keep the Drain-Source voltage constant, and to measure the effects of the Drain-Source voltage we can keep the Gate-Source voltage constant. In practice, this means that I can measure the output current of a transistor with respect to time while keeping the output voltage at a constant level (short circuit into a given voltage) to get the switching characteristics of the transistor (i.e. the effect of the Gate-Source voltage waveform with respect to time). The present V/I measurement method takes care of the other variable, namely the Drain-Source voltage at a constant Gate-Source voltage, since the transistor is in a fully turned on steady state with the Gate-Source voltage being a constant 5V when we sweep it. If we plot the data measured this way, we can actually generate a 3D surface-plot. The two horizontal axis represent the independent variables, one of them being time, and the other the output voltage (Drain-Source voltage). The vertical axis represents the dependent variable, the output current. This is where the name comes from: 3D or I/V/T model. The nice part of this approach is that the device under test does not have to be a MOSFET transistor. In fact, it can be anything and we can treat it as a black box. The surface plot will still fully describe its characteristics. The only difficult part is that we must have a current meter that is extremely fast. There could be several hundred milliamp changes in a couple of nanoseconds. Such current changes are very susceptible to parasitic inductances, therefore a careful measurement methodology must be worked out to obtain correct data. With the widespread use of the various kinds of slew rate controlled buffers in the industry, there is an urgent need to find an accurate modeling method for the switching characteristics. The 3D or I/V/T characterization method could be useful for more accurate modeling of traditional buffers as well as slew rate buffers without turning back to transistor level models. I would be glad to hear your comments and suggestions. Sincerely Arpad Muranyi Intel, Coprporation From lmsi!milpitas.lmc.com!siukic@UB.com Wed Sep 22 10:45:36 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29634; Wed, 22 Sep 93 10:45:36 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA03971; Wed, 22 Sep 93 10:38:23 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA01386; Wed, 22 Sep 93 10:35:27 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA09573; Wed, 22 Sep 93 10:35:26 PDT Date: Wed, 22 Sep 93 10:35:26 PDT From: siukic@milpitas.lmc.com (Siuki Chan) Message-Id: <9309221735.AA09573@fiji.lmsi.com> To: ccm.hf.intel.com!Arpad_Muranyi@lmc.com Subject: Re: 3D, or I/V/T models Cc: ibis@vhdl.org Hi Arpad, This is my understanding of your statement of the problem. See if it helps. > Hello IBIS folks, > > On your request, here is a little summary on the 3D or I/V/T > representation of buffers. > > To simplify the following discussion I will only consider the > pulldown part of an output buffer, which is nothing but an Open-Drain > output. In this case the Drain of the transistor is connected to the > output of the buffer, the Source is connected to GND, and the Gate is > driven by the pre-driver circuitry. > > With the current V/I curve approach we only characterize the DC steady > state conditions of the transistor after it has been completely > turned on. This means that when we sweep the Drain of the transistor > to obtain a V/I curve, its gate voltage is at maximum (5V). > > If we want to characterize the switching characteristics of the > transistor while it is being turned on (i.e. while its gate voltage > is transitioning from 0V to 5V), we would have to take a family of > V/I curves at various gate voltages. There is nothing new in this > idea, most transistor data books publish such family of curves for > both FETs and BJTs. Our problem is that it is very difficult or > impossible to access the voltage waveform on the gate of an output > transistor. Is the difficulty with actual physical measurement such that you cannot probe the input node of the gate? Then how about in spice simulation? I can thinks of a method like this: use the Vds/Ids/Vgs family of curves and Vgs/Time of the input voltage. Mapping Vgs from the curve 1 to Vgs in curve 2, then you can arrive at a Vds/Ids/Time surface. Mathematically, curve 1 is Ids = f(Vds, Vgs) curve 2 is Vgs = g(time) combining both, Ids = f(Vds, g(time)) In physical measurement, curve 1 can be obtained by slowly sweep I/V curve of the output by setting input voltage to a set of fixed values. The only limitation is: you cannot isolate either the pull-up or pull-down. In IBIS [pull-up] and [pull-down] voltage specifications are different. Curve 2 can be obtain by probing the input node voltage get a waveform by an oscilloscope. > > However, we can look at the output current on the Drain as a function > of two variables which are the Gate-Source and the Drain-source > voltages. By the superposition principle, to measure the effects of > the Gate-Source voltage on the output current we can keep the > Drain-Source voltage constant, and to measure the effects of the > Drain-Source voltage we can keep the Gate-Source voltage constant. > > In practice, this means that I can measure the output current of a > transistor with respect to time while keeping the output voltage at a > constant level (short circuit into a given voltage) to get the > switching characteristics of the transistor (i.e. the effect of the > Gate-Source voltage waveform with respect to time). The present V/I > measurement method takes care of the other variable, namely the > Drain-Source voltage at a constant Gate-Source voltage, since the > transistor is in a fully turned on steady state with the Gate-Source > voltage being a constant 5V when we sweep it. > > If we plot the data measured this way, we can actually generate a 3D > surface-plot. The two horizontal axis represent the independent > variables, one of them being time, and the other the output voltage > (Drain-Source voltage). The vertical axis represents the dependent > variable, the output current. This is where the name comes from: 3D > or I/V/T model. > > The nice part of this approach is that the device under test does not > have to be a MOSFET transistor. In fact, it can be anything and we > can treat it as a black box. The surface plot will still fully > describe its characteristics. > I think this may not be as device independent as first appear. In the analysis, the MOS is working in a common-source mode. Source current is a function of (gate-source, drain-source) so that change of drain voltage only affect one variable: the drain-source voltage. In common-emmiter mode, as in ECL output stage, collector current is a function of (base-emitter, collector-emitter) so change of emitter voltage affect both variables. > The only difficult part is that we must have a current meter that is > extremely fast. There could be several hundred milliamp changes in a > couple of nanoseconds. Such current changes are very susceptible to > parasitic inductances, therefore a careful measurement methodology > must be worked out to obtain correct data. This will be a concern for company which does not the kind resources Intel has. Further more, mixing DC and AC parameters in your calculation means you have to take into account all reactive elements and high frequency effects. > > With the widespread use of the various kinds of slew rate controlled > buffers in the industry, there is an urgent need to find an accurate > modeling method for the switching characteristics. The 3D or I/V/T > characterization method could be useful for more accurate modeling of > traditional buffers as well as slew rate buffers without turning back > to transistor level models. I am confused about the purpose of the [RAMP] data in the ibis file. I think its purpose is to construct the waveform of the sending end before any reflection arrives. Does it mean that with the I/V/T characterization method, [RAMP] information is no longer required. > > I would be glad to hear your comments and suggestions. > > Sincerely > Arpad Muranyi > Intel, Coprporation > Best Regards, Siuki Chan Logic Modeling Corp. From speters@ichips.intel.com Wed Sep 22 17:03:34 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02025; Wed, 22 Sep 93 17:03:34 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 22 Sep 93 17:03:06 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 22 Sep 93 17:02:43 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 22 Sep 93 17:02:43 PDT Message-Id: <9309230002.AA26566@xtg801.intel.com> To: ibis@vhdl.org Cc: speters@ichips.intel.com Subject: BIRD for ECL Date: Wed, 22 Sep 1993 17:02:42 -0700 From: Stephen Peters Buffer Issue Resolution Document (BIRD) BIRD ID#: 0001 ISSUE TITLE: ECL Extensions REQUESTER: Stephen Peters, Intel Corp. DATE SUBMITTED: September 22, 1993 DATE ACCEPTED BY IBIS OPEN FORUM: ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: This proposal addresses the need to extend the IBIS specification to include devices with Emitter Coupled Logic (ECL) type output structures. The proposed changes are three in number: (1) Adding one more choice to the [Model] keyword sub-parameter 'Model_type' (2) Lessening the required voltage range over which an ECL output is characterized (3) Explicitly specifying under what output conditions data is gathered for inclusion in the pullup and pulldown tables ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (1) The first change is to add the choice of 'ECL' to the list of allowed choices for the 'Model_type' sub-parameter used with the [Model] keyword. This choice must be used when the device output being described has an ECL type output structure. Specifically, change the description of the [Model] keyword as follows: WAS: [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain | List only one . . . PROPOSED: [Model] model_name Model_type Input, Output, I/O, 3-state, Open_drain, ECL | list only one . . . (2) The second change is to relax (decrease ) the range of voltage values required when tabulating the V-I characteristics of an ECL output. For an ECL device it is proposed the range be decreased to VCC (the most positive power supply) to VCC - 2.2 volts (currently the range is from GND - POWER to 2*POWER). Specifically, add the following to Item 2 in the "NOTES ON DATA DERIVATION METHOD" section of the specification: When tabulating output data for ECL type devices, the voltage points must span the range of VCC to VCC - 2.2V. This range applies to both the pullup and pulldown tables. Note that this range applies ONLY when characterizing an ECL output. (3) Finally, it is proposed to explicitly state in the specification under what output conditions data is gathered for the pullup and pulldown tables and that, in both cases, the voltage data is referenced to VCC. The proposed explanation should be placed in the 'Other Notes' section of the text describing the [Pulldown] and [Pullup] keywords and is as follows: When tabulating data for ECL devices, the data in the pulldown table is measured with the output in the 'logic low' state. In other words, the data in the table represents the V-I characteristics of the output when the output is at the most negative of its two logic levels. Likewise, the data in the pullup table is measured with the output in the 'logic one' state and represents the V-I characteristics when the output is at the most positive logic level. Note that in BOTH these cases the data is referenced to the VCC supply voltage, using the equation Vtable = Vcc - Voutput. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: In the following discussion I am assuming the reader understands the basic operation of an ECL logic gate and the emitter follower output structure. I am also defining VCC to be the most positive supply, while GND as the most negative supply. A "totem-pole" output is the standard type output structure with the source (emitter) of a pullup transistor connected to the drain (collector) of a pulldown transistor. (1) The purpose in requiring the user to specify 'ECL' in the Model_type sub-parameter is to give a simulator an explicit indication that the device being modeled has an ECL type output structure. As far as the IBIS spec is concerned, the fundamental difference between an ECL output and the standard totem-pole or open-drain/collector output is that, for ECL, data in the PULLDOWN table is referenced to VCC and changes in VCC effect the logic low voltage output level. This means when simulating an ECL output a simulator must construct a different model and make different assumptions regarding the output characteristics of the device. The following discussion explains these differences in more detail. Currently, voltage data points in the pulldown table are referenced to GND. This is because in a standard totem-pole type output the output voltage in the logic low state is determined by Vds (or Vce) of the pulldown transistor, and the source (emitter) of this transistor is tied to ground. However, in ECL type outputs the output voltage in the logic low state is determined by the voltage at the base of the output emitter follower, and this voltage is with respect to VCC, not GND. As a specific example, it does not matter whether VCC is defined as 0v or 5v, the output voltage of an ECL gate in the low state is always going to be about 1.7v below the VCC supply. By the same reasoning, a shift in VCC with respect to the other supply will not change the logic low output voltage of a totem-pole output but it will change the logic low level of an ECL type output. Because the simulator cannot, apriori, determine the proper output model (totem-pole or ECL) some indication of the output type is required. One could argue that the simulator could inspect the data in both tables and assume that if the range was 0 to -2.5 it was dealing with an ECL type output, however, I don't believe this is (a) reliable (can we GUARANTEE that no other device will be specified with those voltage ranges) and (b) the IBIS specification should place specific implementation requirements on a simulator. Therefore, the easiest and most reliable way to explicitly specify the output type is with the Model_type sub-parameter. (2) The reason the voltage range over which an ECL output is specified should be relaxed is that, with ECL, one is dealing with much smaller signal swings and terminated transmission lines. The rational for specifying such a large voltage range was to allow for the case of a CMOS output driving an unterminated transmission line. When an incident voltage wave hits the end of an unterminated line it will reflect back to the source at double the amplitude. Thus, a CMOS output that swings rail-to-rail could see a reflection of up to 2*VCC (or -VCC in the negative direction). However, with an ECL output, the output swing is only ~800mv (typically -.9v to -1.7v) and furthermore, because of the vary nature of ECL, any transmission lines will be terminated with an Rt close to the lines Zo. Even in the case where the mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv, and the voltage range at the source due to reflections is -.6 to -2.0v. Therefore, a range of VCC to VCC -2.2v is adequate to specify the output under any reasonable conditions, and should be enough to allow simulators to extrapolate the curves. Note also that there are no gnd or power clamp diodes on ECL outputs (or inputs for that matter) and so those are 'don't care' issues. (3) The third proposal is an effort to make perfectly clear to both the user and the person creating an IBIS specification for a particular part how ECL device are to be handled. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From lmsi!milpitas.lmc.com!siukic@UB.com Fri Sep 24 11:34:01 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17630; Fri, 24 Sep 93 11:34:01 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA04988; Fri, 24 Sep 93 11:16:19 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA11357; Fri, 24 Sep 93 11:13:50 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA10221; Fri, 24 Sep 93 11:13:49 PDT Date: Fri, 24 Sep 93 11:13:49 PDT From: siukic@milpitas.lmc.com (Siuki Chan) Message-Id: <9309241813.AA10221@fiji.lmsi.com> To: speters@ichips.intel.com Subject: about the intel IBIS model Cc: ibis@vhdl.org Hello Stephen, I was looking at the input buffer model in the Intel IBIS files. One item which is missing is the Vinl and Vinh. Are these Sub-Params must be present for full compliant to the version 1.1 specification? If yes, then we may need to update ibis_chk. Best Regards, Siuki Chan Logic Modeling Corp From speters@ichips.intel.com Fri Sep 24 14:12:55 1993 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18552; Fri, 24 Sep 93 14:12:55 PDT Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 24 Sep 93 14:12:25 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 24 Sep 93 14:12:17 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 24 Sep 93 14:12:18 PDT Message-Id: <9309242112.AA04053@xtg801.intel.com> To: siukic@milpitas.lmc.com Cc: ibis@vhdl.org Subject: about the intel IBIS model Date: Fri, 24 Sep 1993 14:12:17 -0700 From: Stephen Peters Hello Siuki -- I ran one of the models thru the ibis_chk program and it passes so, by definition, they are IBIS version 1.1 compliant. This does bring up a good point though. If the Vinl and Vinh parameters were important enough to be include in the written description of the specification, why isn't the parser checking for them? (Did they just fall thru the cracks?). Comments anyone? Best Regards, Stehen Peters Intel Corp. >Hello Stephen, > >I was looking at the input buffer model in the Intel IBIS files. One >item which is missing is the Vinl and Vinh. Are these Sub-Params must >be present for full compliant to the version 1.1 specification? > >If yes, then we may need to update ibis_chk. > >Best Regards, > >Siuki Chan >Logic Modeling Corp From lmsi!milpitas.lmc.com!randyh@UB.com Thu Sep 30 18:44:32 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15099; Thu, 30 Sep 93 18:44:32 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA19761; Thu, 30 Sep 93 18:29:09 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA05553; Thu, 30 Sep 93 18:25:44 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA13021; Thu, 30 Sep 93 18:25:43 PDT Date: Thu, 30 Sep 93 18:25:43 PDT From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9310010125.AA13021@fiji.lmsi.com> To: ibis@vhdl.org Subject: IBIS Press Release and Trademark Search Cc: 71436.1314@compuserve.com, cindim@metasw.com, cjones@performance.com, dino!cjs@UB.com, hobbswil@ccm.hf.intel.com, pzc@cadence.com, randyh@lmc.com, rkelley@tarheel.b23b.ingr.com IBISians: TradeMark Search We completed the trademark and other use searches and discovered that IBIS is probably one of the most overused acronyms / names! The good news is that it is so used (even with registered trademarks and names) that we probably cannot get into trouble. The bad news is some companies with slight relation to our industry (for example, IBIS Software, Inc. of San Francisco) are using it. Suprisingly, the use already by some companies in their press reports did not come up in the "common law" search. The short answer is we might see problems down the road but nothing is of direct enough use to challenge our use in the Press Release. All $500. paid members are welcome to get a copy of the 71 page report by sending me email. It might take 1 week for me to verify through Will and making the copies. Press Release Getting opinions back has been worse than pulling teeth. This has delayed the release by over two months but hopefully you will all agree for the better. Attached is what Will and I hope is the final draft. We are at the point that it needs to be adopted as is and put out. We are asking you to either adopt it as is or we will have to drop your company name from the release. The best copies are available on the vhdl.org machine (pub/ibis/pressrel.rtf, and pub/ibis/pressrel.ps). Below is a text dumped of the formatted copy. WE NEED EACH COMPANY WHO WISHES TO BE LISTED (REMAIN TO BE LISTED OR ADDED) TO SUBMIT A LETTER (FAX OK) ON COMPANY LETTERHEAD DETAILING: a) YOUR APPROVAL FOR USE OF THE COMPANY NAME IN THE RELEASE, and b) A CONTACT NAME AND PHONE NUMBER FOR YOUR COMPANY FOR THE EDITORS. WE NEED THESE BY FRIDAY, 8TH OCT 1993 FROM EACH COMPANY. (Note: for some who submitted them via email or before on earlier drafts, I will need it again in the specified format). ANY COMPANY WHICH DOES NOT GET IT IN WILL BE DROPPED FROM THE RELEASE. (We hope you will all get it in!) Randy Harr, LMC, randyh@milpitas.lmc.com ----------------------------------------------------------------------------- For More Information IBIS Open Forum Will Hobbs 503-696-4369 Jon Powell 805-988-8250 IBIS Signal Integrity Model Specification Announced Emerging Standard Supports Early, Accurate Models for Signal Integrity Simulations of High-Speed Digital Systems BEAVERTON, Oregon -- October 1, 1993 -- A group of Electronic Design Automation and semiconductor companies today announce the development and adoption of Version 1.1 of the IBIS (I/O Buffer Information Specification) standard for signal integrity models. This emerging standard promises to deliver models earlier, with superior simulation performance and accuracy than has been possible with traditional signal integrity model development approaches. As digital system design engineers are increasingly challenged by higher clock speeds and special packaging; signal integrity simulation is becoming imperative. IBIS addresses one of the fundamental simulation issues, that of model availability. IBIS Standard Provides Early Models While Protecting Proprietary Information IBIS is a consistent format which semiconductor vendors can use to specify the analog characteristics of input and output buffers. This essential information is readily transformed into accurate models by end users and simulation tool vendors. The resulting behavioral models allow users to perform high-speed, acccurate signal-integrity simulations of their digital system interconnects. Most existing I/O Buffer model development methodologies are based on actual circuit designs. Such descriptions reveal detailed information not just about the buffer design but also about the underlying, proprietary fabrication processes. In contrast, IBIS uses voltage- versus-current characteristics, along with additional circuit, package and timing information to describe the buffers. This form of data protects the semiconductor vendor's proprietary information about the design and process technology while still providing a highly useful and accurate model for the end user. "By standardizing on a non-proprietary method of specifying models, the industry has a win-win situation," states Jon Powell, Product Manager, Transmission Line Tools from Quad Design. "Semiconductor companies can deliver the information once, EDA tools have a ready and easy source for models, and end users gain high performance, accurate models." Behavioral IBIS Models Are Easy To Generate and Offer Superior Performance The data used to develop an IBIS model can be easily derived from simulations of the actual circuits or measured directly using commonly available laboratory equipment. This easily derivable data includes V-I curves for high and low output transitions; V-I curves for clamp diodes; high/low ramp times; component capacitance; and per-pin package resistance, inductance and capacitance. By simplifying the data collection and removing proprietary issues, the semiconductor vendors can provide IBIS models prior to, or at the same time as, the availability of first components. Because IBIS models are behavioral, simulations run much faster than a corresponding structural model. Speed improvements of 25X are not uncommon. IBIS accomplishes this performance improvement without sacrificing accuracy by incorporating the specification of many non-linear effects of the I/O design, including package parasitics and forward-biased ESD protection diode effects. "We have the opportunity to break open the log jam in model availability for signal integrity analysis by creating accurate, efficient models that can be delivered with the silicon." says Shiv Tasker, vice president, Systems Physical Design at Cadence Design Systems. "The availability of these models will have a major impact on how quickly new parts, introduced by IC vendors, will be designed into new products. It is therefore in customer, IC and EDA vendors' interest to actively encourage adoption of such critical standards as IBIS." First Models Available Intel and the IBIS development group have been working regularly over the last year to refine the specification, benchmark the models that result, and verify the simulations from the models against laboratory measurements of actual circuits. Intel has developed and released IBIS models for the 82420 and 82430 PCIset components. Models of additional Intel chip sets and processors will be available soon. "Accurate signal integrity analysis is virtually impossible without quality silicon models," said John Isaac, director of marketing for Mentor Graphics' PCB Division, San Jose, Calif. "IBIS is the first step towards providing critical behavior information required for complex systems and it will significantly increase the productivity of high- speed board and MCM designers." Participating Companies Form IBIS Open Forum The IBIS Version 1.1 specification was developed through the cooperative efforts of simulator vendors and semiconductor companies who together comprise the IBIS Open Forum. The following participating companies support the specification: AnSoft Corporation, Cadence Design Systems, Contec Microsystems, HyperLynx, Integrity Engineering, Intel Corporation, Intergraph Electronics, IntuSoft, Logic Modeling Corporation, Mentor Graphics Corporation, Meta- Software, MicroSim Corporation, North Carolina State University, Performance Signal Integrity, Quad Design, Quantic Labs, and Texas Instruments. "The widespread support for this new specification removes the barriers that have prevented semiconductor vendors from supplying accurate models to their customers," said Will Hobbs, Models Manager for Intel's Xcceleration Tools Group. "Accuracy, speed of development, speed of execution, protection of intellectual property and support by virtually the entire simulator industry are keys to this breakthrough." Group Plans to Formalize Standard in 1994 Although initially focused on CMOS technologies, the IBIS Open Forum is taking steps to broaden the specification into other technologies and circuits; such as ECL devices and open collector outputs. Such extensions are not perceived to be difficult and are expected to be added quickly. The group intends to develop a robust, comprehensive standard by mid-1994 that can be taken to the standards community for formal adoption. The forum is actively seeking additional participation to support the expansion; especially from semiconductor developers and system designers. For More Information For more information about the IBIS Open Forum, send an email request to ibis-info@vhdl.org or fax to xxx-xxx- xxxx. All of the documents and publicly available models are currently accessible via the public repository of VHDL International's Internet based machine (vhdl.org, 198.31.14.3). FTP, Gopher and public dial-in access methods are all supported. From bracken@valhalla.performance.com Fri Oct 1 08:45:38 1993 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20454; Fri, 1 Oct 93 08:45:38 PDT Received: by valhalla.performance.com (4.1/SMI-4.1) id AA21963; Fri, 1 Oct 93 11:45:45 EDT Message-Id: <9310011545.AA21963@valhalla.performance.com> To: ibis@vhdl.org Subject: Package descriptions--Take 1 Date: Fri, 01 Oct 93 11:45:42 -0400 From: bracken@valhalla.performance.com Dear Friends of IBIS: I've been considering how we can address the package problem. I've written down some of my thoughts here, with the hope that this will generate some useful discussion. As you'll recall, the current Version 1.1 spec has a fairly simple package/die model consisting of: Rpin Lpin +-----+ +-----+ +---------+----| |--| |---+----> to board | | +-----+ +-----+ | +---+---+ | | | i-v | ----- ----- | curve | ----- ----- +---+---+ | Ccomp | Cpin | | | V V V (on-chip grounds?) (off-chip ground?) TRANSMISSION LINES vs. LUMPED MODELS: There's been some question about what to do with the Rpin/Lpin/Cpin; whether to lump them, and if so into how many lumps; or to model them as (lossy) transmission lines. The transmission line models are questionable, for the following reasons: The basic assumption in the transmission line model is that there's a TEM wave propagating along the structure, which requires TWO conductors to support it--one for the signal, and another to act as the "return" path. A trace on a board presumably has a nice ground plane nearby. A wire in the lead frame may too, IF the package contains its own power/ground planes. But in the case of a bond wire or a pin, there's no return path paired with it. You could select another bond wire as the "return", but then the situation is so 3-dimensional that the transmission line approach is hopeless anyway. A lot of special cases begin to come up. IF the package contains power/ground planes, THEN use transmission lines, ELSE use lumped models for the lead frames. Even if transmission lines are used, you might still want to have lumped caps/inductances at either end to model bond wires and pins. Another question is what to do with the "tapering" of the transmission lines and their coupling to one another. It seems unlikely that we could standardize easily on a model. LUMPED PACKAGE MODELS In order to model simultaneous switching noise ("ground bounce," etc.) it becomes necessary to have not only pin inductance/capacitance, but also MUTUAL inductances and coupling capacitances between pins. Depending upon how aggressive the modelling engineer wants to be, and on how high-speed the design is, the number of such mutuals/coupling C's can become very large. Also, a single "connection" might be broken up into separate inductance elements to model the individual characteristics of bond wire, package trace, and pin. This increases the number of internal nodes in the package. The complexity of the resulting model rapidly approaches the point where it can only be described by something like a Spice deck. This is fine with me, but I doubt that everybody feels this way. So I've tried to come up with a fairly simple package description which is based upon SPICE, but includes additional COMMENT-BASED information to make the parsing easier. The way I envision the ".pkg" file is that it would start with a "declarations" section (in SPICE's *-comments) where the modelling engineer would declare (strictly in the following order): 1) the set of node names used in the package model; 2) the set of inductance names used (The point of declaring things this way is to make the parsing as easy as possible. No need to do 2 passes.) Following the declarations, there would be a regular SPICE section containing the R, L, C, and K (mutual inductance) element values. I would recommend that we enhance the SPICE syntax a little bit; we could permit inductances to have a resistance loss value specified in addition to the self-inductance. This would help to cut down on the number of the nodes in the package model. (You very often see series R-L combinations; the "internal" node between the two is really of no interest to anyone.) The format described here is general enough to permit "mutual resistances" as well, which are used by some crazy packaging modelling programs. The mutual resistances could be an additional parameter in the K card. If there are no couplings, then the package model is equivalent to what we have in IBIS already, although admittedly it would be specified in a different way. I tend to think that if the ".pkg" file is specified, the simulator will simply ignore whatever Rpin, Lpin, and Cpin values are specified in the main ".ibs" file. These values would STILL BE AVAILABLE to do less detailed simulation. The package model would be similar to Spice's "subcircuits"--there would be a set of ports connecting the internal package junk to the IBIS I-V curves on the inside, and also to the board on the outside. We'd need a name convention for those port nodes, but I think this isn't a problem. As I've said, I hope these musings inspire some useful discussion on this subject. --Eric From ccm!Arpad_Muranyi@intelhf.intel.com Fri Oct 1 09:14:37 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20726; Fri, 1 Oct 93 09:14:37 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0oin7P-000MOFC; Fri, 1 Oct 93 09:14 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0oinCA-0000FmC; Fri, 1 Oct 93 09:19 PDT Received: by ccm.hf.intel.com (ccmgate) Fri, 1 Oct 93 09:19:01 PST Date: Fri, 1 Oct 93 09:19:01 PST From: Arpad Muranyi Message-Id: <931001091901_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: 3-D model topics Hi Siuki, and all others, Sorry for the delay in responding to your comments on the 3-D model, but here is the way I see it. >> If we want to characterize the switching characteristics of the >> transistor while it is being turned on (i.e. while its gate voltage >> is transitioning from 0V to 5V), we would have to take a family of >> V/I curves at various gate voltages. There is nothing new in this >> idea, most transistor data books publish such family of curves for >> both FETs and BJTs. Our problem is that it is very difficult or >> impossible to access the voltage waveform on the gate of an output >> transistor. > Is the difficulty with actual physical measurement such that you cannot > probe the input node of the gate? Then how about in spice simulation? I > can thinks of a method like this: use the Vds/Ids/Vgs family of curves > and Vgs/Time of the input voltage. Mapping Vgs from the curve 1 to Vgs > in curve 2, then you can arrive at a Vds/Ids/Time surface. > Mathematically, curve 1 is Ids = f(Vds, Vgs) > curve 2 is Vgs = g(time) > combining both, Ids = f(Vds, g(time)) You can do this only on SPICE, but not with real devices... > In physical measurement, curve 1 can be obtained by slowly sweep I/V curve > of the output by setting input voltage to a set of fixed values. The only > limitation is: you cannot isolate either the pull-up or pull-down. In IBIS > [pull-up] and [pull-down] voltage specifications are different. Curve 2 > can be obtain by probing the input node voltage get a waveform by an > oscilloscope. This "only limitation" you mentioned in actually not the only one. Think of an ASIC, for example. You do not have access to buffer inputs in an ASIC or a more complex device to slowly sweep its input. Even if you did, I do not believe that slowly sweeping an input is going to slowly switch the output as well, due to the gain in the pre-driver section. In my opinion, this approach would not work. Anyways, the purpose is not to derive a way to find out what the waveform is on the gate (or base) of the output transistor. (I could not care less about that). It is to see the current / voltage / time relationships on the output of the buffer. For that, we can treat the buffer itself as a black box and forget about the waveforem on the gate or base. >> The nice part of this approach is that the device under test does not >> have to be a MOSFET transistor. In fact, it can be anything and we >> can treat it as a black box. The surface plot will still fully >> describe its characteristics. > > I think this may not be as device independent as first appear. In the > analysis, the MOS is working in a common-source mode. Source current > is a function of (gate-source, drain-source) so that change of drain > voltage only affect one variable: the drain-source voltage. In > common-emmiter mode, as in ECL output stage, collector current is a > function of (base-emitter, collector-emitter) so change of emitter > voltage affect both variables. Without having done too much research on this, I think it actually is device independent. (It needs to be confirmed, though). What you are saying is true if you relate things to the gate voltage waveform. But if you treat the device as a black box, and only look at the current / voltage / time relationship on the output pin, you are actually characterizing the impedance of the buffer at any given time while it is switching and thereafter, regardless whether it is a BJT, MOSFET, open collector, emitter follower, etc... Since this impedance is a function of time and voltage of the output pin, but the voltage is actually a function of the loading impedance and the output current, we can also say that the driver impedance is also a function of the load impedance. >> The only difficult part is that we must have a current meter that is >> extremely fast. There could be several hundred milliamp changes in a >> couple of nanoseconds. Such current changes are very susceptible to >> parasitic inductances, therefore a careful measurement methodology >> must be worked out to obtain correct data. > This will be a concern for company which does not the kind resources > Intel has. Further more, mixing DC and AC parameters in your calculation > means you have to take into account all reactive elements and high > frequency effects. That is why I feel that a good measurement methodology must be worked out by which I also mean that is should be relatively low cost, so that people can afford it. And you are right this involves the reactive elements (packaging also). > I am confused about the purpose of the [RAMP] data in the ibis file. I > think its purpose is to construct the waveform of the sending end before > any reflection arrives. Does it mean that with the I/V/T characterization > method, [RAMP] information is no longer required. Yes, I/V/T would make the ramp stuff meaningless. The ramp times are just kind of a rough description of the switching characteristics of the buffer. If there are any more comments, feel free to EMAIL. This is a new territory for mee too, I would like to hear your reactions. Sincerely Arpad Muranyi Intel, Coprporation From cer@Cadence.COM Fri Oct 1 09:42:34 1993 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20931; Fri, 1 Oct 93 09:42:34 PDT Received: from cadence.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA00483; Fri, 1 Oct 1993 09:38:55 -0700 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA03528; Fri, 1 Oct 93 09:33:08 -0700 Received: by oahu (5.65+/1.5) id AA20055; Fri, 1 Oct 93 12:40:09 -0400 Date: Fri, 1 Oct 93 12:40:09 -0400 From: cer@Cadence.COM (Christopher E. Reid) Message-Id: <9310011640.AA20055@oahu> To: ibis@vhdl.org Subject: Re: Package descriptions--Take 1 Cc: cpk@Cadence.COM, zaki@Cadence.COM Howdy, Eric Bracken writes: _______________________________________________________________________ There's been some question about what to do with the Rpin/Lpin/Cpin; whether to lump them, and if so into how many lumps; or to model them as (lossy) transmission lines. The transmission line models are questionable, for the following reasons: The basic assumption in the transmission line model is that there's a TEM wave propagating along the structure, which requires TWO conductors to support it--one for the signal, and another to act as the "return" path. A trace on a board presumably has a nice ground plane nearby. A wire in the lead frame may too, IF the package contains its own power/ground planes. But in the case of a bond wire or a pin, there's no return path paired with it. You could select another bond wire as the "return", but then the situation is so 3-dimensional that the transmission line approach is hopeless anyway. --------------------------------------------------------------------- Actually, both the transmission-line model and the lumped circuit model assume a TEM mode. Non-TEM implies radiative loss, which no lumped model can account for directly. Besides, the transmission line model is equvalent to lumped circuits if the "lumps" are distributed in a ladder in small enough pieces. I propose we use RLGC matricies to represent package parasitics in the case where mutual parasitics between the pins must be included. A banded-symmetric format for these parasitics could be used to keep the number of entries down. Chris Reid cer@cadence.com From bracken@valhalla.performance.com Fri Oct 1 10:11:30 1993 Return-Path: Received: from valhalla.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21149; Fri, 1 Oct 93 10:11:30 PDT Received: by valhalla.performance.com (4.1/SMI-4.1) id AA22030; Fri, 1 Oct 93 13:11:27 EDT Message-Id: <9310011711.AA22030@valhalla.performance.com> To: cer@cadence.com (Christopher E. Reid) Cc: ibis@vhdl.org Subject: Re: Package descriptions--Take 1 In-Reply-To: Your message of "Fri, 01 Oct 93 12:40:09 EDT." <9310011640.AA20055@oahu> Date: Fri, 01 Oct 93 13:11:23 -0400 From: bracken@valhalla.performance.com Chris, I'm in basic agreement with you. To respond in detail, (>> denotes what Chris wrote): >> Actually, both the transmission-line model and the lumped circuit >> model assume a TEM mode. Non-TEM implies radiative loss, which no >> lumped model can account for directly. Besides, the transmission >> line model is equvalent to lumped circuits if the "lumps" are >> distributed in a ladder in small enough pieces. Depends on what you mean by "TEM"; if you mean no radiation, fine, I agree. (Actually, you CAN define lumped circuit models that have radiation in them, by including "retardation," but it's not worthwhile until the frequencies get REALLY high or the packages VERY big.) My point is simply that transmission line models for a single wire alone in space are not possible. And transmission line models for inherently wiggly 3-D stuff are not worth attempting. >> I propose we use RLGC matricies to represent package parasitics >> in the case where mutual parasitics between the pins must be >> included. A banded-symmetric format for these parasitics could >> be used to keep the number of entries down. I propose the same thing; but I suggest we represent the matrices as a SPICE deck. This is a well-known, industry standard format that everyone understands. The symmetry is implicit in the SPICE. The "banded" (or more generally, "sparse") nature of the matrix will be there if you don't specify the coupling between far-off elements. Finally, the SPICE provides flexibility to describe discontinuities between bond wires, lead frame and pins. --Eric From cer@Cadence.COM Fri Oct 1 11:59:02 1993 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21708; Fri, 1 Oct 93 11:59:02 PDT Received: from cadence.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA04894; Fri, 1 Oct 1993 10:30:38 -0700 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA10493; Fri, 1 Oct 93 10:24:52 -0700 Received: by oahu (5.65+/1.5) id AA20082; Fri, 1 Oct 93 13:31:55 -0400 Date: Fri, 1 Oct 93 13:31:55 -0400 From: cer@Cadence.COM (Christopher E. Reid) Message-Id: <9310011731.AA20082@oahu> To: ibis@vhdl.org Subject: Package Parasitics continued Cc: cpk@Cadence.COM Hello All, Responding to Eric Bracken again, he writes: ______________________________________________________________________ I propose the same thing; but I suggest we represent the matrices as a SPICE deck. This is a well-known, industry standard format that everyone understands. The symmetry is implicit in the SPICE. The "banded" (or more generally, "sparse") nature of the matrix will be there if you don't specify the coupling between far-off elements. Finally, the SPICE provides flexibility to describe discontinuities between bond wires, lead frame and pins. -------------------------------------------------------------------- However, my point is that: 1) RLGC Matricies are much easier to manipulate, for example to compare coupling strengths. 2) RLGC Matricies are easily translated into equivalent SPICE decks. 3) It is difficult to make the translation from SPICE to RLGC matricies since that would entail parsing the SPICE deck, and checking to make sure no other elements were present. Of course SPICE is more generic, but I think that generality is not required here. Chris Reid cer@cadence.com From cpk@Cadence.COM Fri Oct 1 12:10:50 1993 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21806; Fri, 1 Oct 93 12:10:50 PDT Received: from cadence.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA12537; Fri, 1 Oct 1993 12:03:48 -0700 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA19987; Fri, 1 Oct 93 11:58:01 -0700 Received: by hot (5.65+/1.5) id AA13816; Fri, 1 Oct 93 15:05:03 -0400 Date: Fri, 1 Oct 93 15:05:03 -0400 From: cpk@Cadence.COM (C. Kumar) Message-Id: <9310011905.AA13816@hot> To: ibis@vhdl.org, speters@ichips.intel.com Subject: Re: BIRD for ECL Following Oct 1st meeting here are my comments about ECL; 1. Have a field called TECHNOLOGY for example TECHNOLOGY = ECL should be sufficient to indicate that a different type of modelling is necessary. I think a new Technology field is preferable to using the existing Model_Type field 2. May be in the case of ECL we may revert back to using absolute V-I data as found in data books today. The downside of this that another field to indicate explicitly the voltage level of the VCC rail will be necessary. Regards - Kumar From canright@neptune.convex.com Fri Oct 1 13:56:21 1993 Return-Path: Received: from convex.convex.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22367; Fri, 1 Oct 93 13:56:21 PDT Received: from neptune.convex.com by convex.convex.com (5.64/1.35) id AA06553; Fri, 1 Oct 93 15:56:00 -0500 Received: by neptune.convex.com (5.64/1.28) id AA29128; Fri, 1 Oct 93 15:58:05 -0500 From: canright@neptune.convex.com (Robert Canright) Message-Id: <9310012058.AA29128@neptune.convex.com> Subject: Package Parasitics continued (fwd) To: ibis@vhdl.org Date: Fri, 1 Oct 93 15:58:04 CDT Cc: jaynes@neptune.convex.com (Dwight Jaynes) X-Mailer: ELM [version 2.3 PL11] I've just joined this dialog & find it interesting to see you debating something we are discussing in-house. Furthermore, I made a suggestion for a package modeling specification at the February JEDEC JC-15 meeting. I'm trying to get consensus in-house still, but what I have put into my proposed spec is both the RLGC info & a spice deck. The RLGC info is useful for thinking purposes. The spice deck is what we need for simulation. No one wants to build a spice deck from an RLGC matrix. A "cut & paste" approach is needed for productivity. Furthermore, the lumped element spice deck should be made up of 3 lumps. 1 lump introduces distortion. I did not expect IBIS to satisfy all my needs. But my proposed package modeling spec is my wish list for signal integrity. The goal is improved productivity. I was hoping to get the IC manufacturers moving towards giving us more of the information we need to do signal integrity analysis with greater accuracy & less labor. If there is interest, I could share the spec with you when it comes "out of committee". (Perhaps "data requirements" is a better term than "spec".) ---------------------------------------------------------------------- Forwarded message: > From cer@Cadence.COM Fri Oct 1 14:12:38 1993 > Date: Fri, 1 Oct 93 13:31:55 -0400 > From: cer@Cadence.COM (Christopher E. Reid) > Message-Id: <9310011731.AA20082@oahu> > To: ibis@vhdl.org > Subject: Package Parasitics continued > Cc: cpk@Cadence.COM > > Hello All, > > Responding to Eric Bracken again, he writes: > ______________________________________________________________________ > I propose the same thing; but I suggest we represent the matrices as a > SPICE deck. This is a well-known, industry standard format that > everyone understands. The symmetry is implicit in the SPICE. The > "banded" (or more generally, "sparse") nature of the matrix will be > there if you don't specify the coupling between far-off elements. > Finally, the SPICE provides flexibility to describe discontinuities > between bond wires, lead frame and pins. > -------------------------------------------------------------------- > > However, my point is that: > 1) RLGC Matricies are much easier to manipulate, for example to > compare coupling strengths. > 2) RLGC Matricies are easily translated into equivalent SPICE decks. > 3) It is difficult to make the translation from SPICE to > RLGC matricies since that would entail parsing the SPICE deck, > and checking to make sure no other elements were present. > > Of course SPICE is more generic, but I think that generality is not > required here. > > Chris Reid > cer@cadence.com -- Bob Canright Convex Computer Corp. Richardson, Texas 214-497-4474 (desk) canright@convex.com 214-497-4500 (FAX) disclaimer: It's not my typing, the Sun keyboard repeeeatsss. From cer@Cadence.COM Fri Oct 1 14:43:27 1993 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22800; Fri, 1 Oct 93 14:43:27 PDT Received: from cadence.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA19680; Fri, 1 Oct 1993 14:39:35 -0700 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA04564; Fri, 1 Oct 93 14:33:45 -0700 Received: by oahu (5.65+/1.5) id AA22036; Fri, 1 Oct 93 17:40:51 -0400 Date: Fri, 1 Oct 93 17:40:51 -0400 From: cer@Cadence.COM (Christopher E. Reid) Message-Id: <9310012140.AA22036@oahu> To: ibis@vhdl.org Subject: Re: Package Parasitics continued (fwd) Cc: cpk@Cadence.COM Responding to Bob Canright who writes: _____________________________________________________________________ ... what I have put into my proposed spec is both the RLGC info & a spice deck. The RLGC info is useful for thinking purposes. The spice deck is what we need for simulation. No one wants to build a spice deck from an RLGC matrix. A "cut & paste" approach is needed for productivity. ------------------------------------------------------------------ My focus is on automatic tools using this data. Also, some people may indeed want to build a SPICE deck from RLGC matricies if the version of SPICE they are using includes a multi-conductor transmission line simulator, or some other element that uses RLGC matricies directly. I have no objection to allowing SPICE data, but RLGC is essential for automatic processing. Chris Reid From bob@icx.com Fri Oct 1 15:07:05 1993 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22945; Fri, 1 Oct 93 15:07:05 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA12616 for ; Fri, 1 Oct 93 17:51:24 -0400 Date: Fri, 1 Oct 93 14:19:50 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA12096; Fri, 1 Oct 93 14:19:50 PDT Message-Id: <9310012119.AA12096@icx.com> To: ibis@vhdl.org Subject: BIRD1 on ECL Models shown in Motorola Application Note AN1402 "MC10/100H600 Translator Family I/O SPICE Modelling Kit" shows that there are "power" and "ground" clamp circuits at the input and outputs of some ECL interfaces, primarily for ESD protection. The ECL models should allow for including such clamps even though they would be well out of the range of the normal ECL signal transitions. They would be useful for model completeness and perhaps for abnormal situations. Bob Ross Interconnectix, Inc. From ccm!Will_Hobbs@intelhf.intel.com Fri Oct 1 16:29:44 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23553; Fri, 1 Oct 93 16:29:44 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0oituU-000MNeC; Fri, 1 Oct 93 16:29 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0oitzJ-0000VdC; Fri, 1 Oct 93 16:34 PDT Received: by ccm.hf.intel.com (ccmgate) Fri, 1 Oct 93 16:34:12 PST Date: Fri, 1 Oct 93 16:34:12 PST From: Will Hobbs Message-Id: <931001163412_4@ccm.hf.intel.com> To: Stephen_Peters@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, Don_A_Telian@ccm.hf.intel.com, ibis@vhdl.org Subject: IBIS summit Greetings, fellow Ibisers! At our June gathering at DAC, we discussed convening an IBIS summit in the Fall. At the September 10 meeting we tentatively set November 12 in Santa Clara as the time and place, to coincide with the ICCAD conference that week. I have secured a room that can accomodate up to 50 people at an Intel site for such a gathering. I have also secured one for November 11. Please give me your feedback on the following questions: 1. Can you/will you attend? How many will come with you? 2. Is November 12 OK? Is November 11 better (ICCAD will still be in session on the 11th)? 3. Do you have a suggested format (my suggestions appear below). 4. Are you willing to present? Chair a discussion? 5. Do you have any hot topics you would like to see addressed? Suggested format: Morning 8:00 - 8:20 Assemble, mingle, drink coffee, etc. 8:20 - 10:00 3 or 4 individual presentations, 20 to 30 minutes each. 10:00 - 10:20 Break 10:20 - 12:00 3 or 4 individual presentations, 20 to 30 minutes each 12:00 - 1:00 Lunch, mingle, possible showcase (we can have tables set up to show individual vendors' products, etc. Afternoon 1:00 - 2:30 Breakout sessions 2:30 - 2:50 Break 2:50 - 5:00 Breakout sessions Possible topics for individual presentations: * What your company is doing with IBIS, how it is tackling IBIS challenges * Where you think we need to go with IBIS * New technologies/areas you've tackled with IBIS (MCM, ECL, ...) * Customer input, feedback * Plans you would be willing to share * Areas of current exploration (e.g., Arpad's 3D modeling) * Model development, validation methodologies * Auto-extraction of V/I and other IBIS data from SPICE simulations, silicon * Models available * Other (Specify) ___________________ Breakout Sessions There are two ways to handle these: 1. Have panel discussions in the main room in which all participate 2. Have small groups congregate in separate areas of the room to discuss various topics while other topics are being discussed in other small groups. (If the small group breakout is the preference, I may be able to get some other small conference rooms to use for these, but I can't promise it.) 3. Other suggested formats? Potential Break-out topics: 1. .pkg extensions 2. ECL 3. Open-side, pahsed turn-on, turn-off of multiple devices 4. Paser enhancements 5. Monotonicity, hysteresis, etc. 6. Data derivation methodologies (measured and/or simulated), golden load topologies 7. Timing verification 8. Strategies for further adoption of IBIS (more IC vendors, generating press interest, expanding scope to more of the world, Standards Committees, etc.) 9. Other (Specify) _________________ Please send comments to the reflector or directly to me, hobbswil@ccm.hf.intel.com Thanks. Will Hobbs, Intel From qdt!sal!jonp@uunet.UU.NET Mon Oct 4 09:45:57 1993 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17168; Mon, 4 Oct 93 09:45:57 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA12554; Mon, 4 Oct 93 12:45:23 -0400 Received: from qdt.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 124112.11602; Mon, 4 Oct 1993 12:41:12 EDT Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00520; Mon, 4 Oct 93 09:19:21 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA24470; Mon, 4 Oct 93 09:19:20 PDT Date: Mon, 4 Oct 93 09:19:20 PDT From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9310041619.AA24470@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA13457; Mon, 4 Oct 93 09:19:19 PDT To: ibis@vhdl.org Subject: VINH and VINL Fellow IBIS type persons, At the recent IBIS phone call I volunteered to author a BIRD on the subject of requiring VINH and VINL specifications for input devices. This was to avoid the problem of useless but IBIS legal input devices with no logic threshold. Upon studying the problem I noticed that there is actually a larger change required than I had anticipated and I believe I should solicit comments before I actually write the BIRD. The problem is two fold: First. I believe that our current model-types are not sufficiently exclusive. We have INPUT OUTPUT I/O 3-STATE and OPEN_DRAIN. Under what category does a 3-state I/O fall? Second. Do we wish to be able to model devices that are not any of these above things but are still simple reasonable devices. like: Resistor Packs Termination Diode Packs Discrete 2 port devices I believe we need a slight extension of the allowed model-types and then a different way of being able to distinguish between OUTPUTS, INPUTS, and LOADS. comments are requested. jonp@qdt.com From bob@icx.com Mon Oct 4 14:07:13 1993 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18605; Mon, 4 Oct 93 14:07:13 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA16140 for ; Mon, 4 Oct 93 16:51:41 -0400 Date: Mon, 4 Oct 93 12:51:52 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA17593; Mon, 4 Oct 93 12:51:52 PDT Message-Id: <9310041951.AA17593@icx.com> To: ibis@vhdl.org Subject: BIRD1 on ECL IBIS Folk: I am sending this note again in case it did not successfully go out last Friday. Models in Motorola Application Note AN1402 "MC10/100H600 Translator Family I/O SPICE Modelling Kit" show that there are "power" and "ground" clamp circuits at the input and outputs of some ECL interfaces, primarily for ESD protection. The ECL models should allow for including such clamps even though they would be well out of the range of the normal ECL signal transitions. They would be useful for model completeness and for abnormal situations. Bob Ross Interconnectix, Inc. From randyh Tue Oct 5 12:45:04 1993 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27374; Tue, 5 Oct 93 12:45:04 PDT Date: Tue, 5 Oct 93 12:45:04 PDT From: randyh (Randy Harr) Message-Id: <9310051945.AA27374@vhdl.vhdl.org> To: ibis@vhdl.org Subject: Press Release and Last Friday's meeting Cc: ibispr Based on the Friday meeting, the HyperLynx quote was adapted into the existing press release and minor corrections were made to company names, job titles, etc. The slightly edited forms are available, as before, on the repository under the names "pressrel.{rtf,ps}". I have only received two confirming faxes giving a contact name, phone #, and authorization to use a company name. These were received Friday from Ansoft and Quantic. I need the others by Friday for the PR agency. IF YOU THINK THIS IS GOING TO BE A PROBLEM BUT YOU STILL WANT TO GET YOUR COMPANY LISTED, PLEASE LET ME KNOW ASAP. The press release sent out along with the attachment contact names should be available on the repository Monday. Just for clarity, we initially offered to include one page mini-press releases of each company in the PR packet. Because we got ZERO response from the initial request / deadline, we added the few company quotes to beef up the release and are attaching the contact name, phone # sheet to the release. I would think a product brochure / announcement related to IBIS would be appropriate to go in the information packet that Will is putting together though. Plan on putting together a couple hundred to send to Will. He can collect them all for whoever is putting the final packets together. randy From lmsi!milpitas.lmc.com!randyh@UB.com Tue Oct 5 15:44:42 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28389; Tue, 5 Oct 93 15:44:42 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA15436; Tue, 5 Oct 93 15:35:12 PDT Received: from elrond.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA23433; Tue, 5 Oct 93 14:36:19 PDT Received: by elrond.lmsi.com (4.1/SMI-4.1) id AA00909; Tue, 5 Oct 93 14:36:17 PDT Date: Tue, 5 Oct 93 14:36:17 PDT From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9310052136.AA00909@elrond.lmsi.com> To: ibis@vhdl.org Subject: Press Release confirmations Received ok to use Cadence's ok letter from last week. CADLAB is sending one as we "speak". Any more today? randy From stephenf@metasw.com Thu Oct 7 14:33:11 1993 Return-Path: Received: from metasw.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16635; Thu, 7 Oct 93 14:33:11 PDT Received: from bunyip ([192.0.5.10]) by metasw.com (4.1/SMI-4.1) id AA03353; Thu, 7 Oct 93 14:33:17 PDT Received: from cc:Mail by bunyip (1.30/SMTPLink) id A18587; Thu, 07 Oct 93 14:33:28 PST Date: Thu, 07 Oct 93 14:33:28 PST From: Stephen Fenstermaker Message-Id: <9310071433.A18587@bunyip> To: ibis@vhdl.org, randyh@milpitas.lmc.com Subject: Re: Press Release confirmations Meta-Software says OK as well. Could you repeat the fax number for sending company background info. Stephen Fenstermaker Received ok to use Cadence's ok letter from last week. CADLAB is sending one as we "speak". Any more today? randy From ccm!Don_A_Telian@intelhf.intel.com Thu Oct 7 16:47:58 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17373; Thu, 7 Oct 93 16:47:58 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0ol53E-000MQ0C; Thu, 7 Oct 93 16:47 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0ol58o-0001D3C; Thu, 7 Oct 93 16:53 PDT Received: by ccm.hf.intel.com (ccmgate) Thu, 7 Oct 93 16:53:01 PST Date: Thu, 7 Oct 93 16:53:01 PST From: Don A Telian Message-Id: <931007165301_1@ccm.hf.intel.com> To: Will_Hobbs@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, qdt!sal!jonp@uunet.UU.NET, ibis@vhdl.org Subject: Re: VINH and VINL >>>> Howdy, My comments look like this >>>>> , Don Telian >>>> Jon Powell's original memo follows.... Fellow IBIS type persons, At the recent IBIS phone call I volunteered to author a BIRD on the subject of requiring VINH and VINL specifications for input devices. This was to avoid the problem of useless but IBIS legal input devices with no logic threshold. Upon studying the problem I noticed that there is actually a larger change required than I had anticipated and I believe I should solicit comments before I actually write the BIRD. The problem is two fold: First. I believe that our current model-types are not sufficiently exclusive. We have INPUT OUTPUT I/O 3-STATE and OPEN_DRAIN. Under what category does a 3-state I/O fall? >>>>> If it's "i/o", it's got to be "3-state", unless it intends >>>>> to only drive itself. Right? Consequently, "3-state I/O" >>>>> and "I/O" are the same thing. Second. Do we wish to be able to model devices that are not any of these above things but are still simple reasonable devices. like: Resistor Packs Termination Diode Packs Discrete 2 port devices >>>>> This makes a lot of sense. And I think if we're clever we >>>>> can do this with just a couple new "Model_type"s. I believe we need a slight extension of the allowed model-types and then a different way of being able to distinguish between OUTPUTS, INPUTS, and LOADS. >>>>> not sure what you mean here... But sounds like a good BIRD. comments are requested. jonp@qdt.com From qdt!sal!jonp@uunet.UU.NET Thu Oct 7 17:48:25 1993 Return-Path: Received: from relay1.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17923; Thu, 7 Oct 93 17:48:25 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA20118; Thu, 7 Oct 93 20:46:23 -0400 Received: from qdt.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 204408.18864; Thu, 7 Oct 1993 20:44:08 EDT Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00960; Thu, 7 Oct 93 17:24:13 PDT Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA14571; Thu, 7 Oct 93 17:24:13 PDT Date: Thu, 7 Oct 93 17:24:13 PDT From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9310080024.AA14571@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA16687; Thu, 7 Oct 93 17:24:12 PDT To: uunet!ccm.hf.intel.com!Don_A_Telian@uunet.UU.NET Cc: Will_Hobbs@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, ibis@vhdl.org In-Reply-To: Don A Telian's message of Thu, 7 Oct 93 16:53:01 PST <931007165301_1@ccm.hf.intel.com> Subject: VINH and VINL First. I believe that our current model-types are not sufficiently exclusive. We have INPUT OUTPUT I/O 3-STATE and OPEN_DRAIN. Under what category does a 3-state I/O fall? >>>>> If it's "i/o", it's got to be "3-state", unless it intends >>>>> to only drive itself. Right? Consequently, "3-state I/O" >>>>> and "I/O" are the same thing. >>>>>>>>>>>>>>>>> Please refer to SN74ALS641 (and associated parts) >>>>>>>>>>>>>>>>> Open Collector Transceiver. >>>>>>>>>>>>>>>>> Most TI Tri-State parts have OC "twin" >>>>>>>>>>>>>>>>> If we dont need I/O_OPEN_DRAIN and I/O_OPEN_COLLECTOR >>>>>>>>>>>>>>>>> then we don't need OPEN_DRAIN. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> jonp From lmsi!milpitas.lmc.com!randyh@UB.com Fri Oct 8 01:54:10 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21207; Fri, 8 Oct 93 01:54:10 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA14791; Thu, 7 Oct 93 18:35:06 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA03376; Thu, 7 Oct 93 16:07:24 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA02388; Thu, 7 Oct 93 16:07:25 PDT Date: Thu, 7 Oct 93 16:07:25 PDT From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9310072307.AA02388@fiji.lmsi.com> To: ibis@vhdl.org Subject: Press Release (last call) Cc: 71436.1314@compuserve.com, cindim@metasw.com, cjones@performance.com, dino!cjs@UB.com, hobbswil@ccm.hf.intel.com, pzc@cadence.com, randyh@lmc.com, rkelley@tarheel.b23b.ingr.com To date (and time), I have received the following confirmations / ok's to use company names in the IBIS press release with a corresponding contact name(s): Ansoft Corporation Cadence Design Systems Interconnectix, Inc. MicroSim Corporation Performance Signal Integrity Quad Design Quantic Laboratories Inc. Siemens Nixdorf Information Systems AG/Cadlab The following comapnies have informed me or Will Hobbs that the fax is on its way: Intusoft Meta-Software We are still anxciously awaiting to hear anything from: Contec Microelectronics USA Inc. HyperLynx Integrity Engineering Intel Corporation Intergraph Electronics Mentor Graphics Corporation North Carolina State University Texas Instruments Zeelan Technology, Inc. If you know anyone at one of these companies, please ask them to call or email Randy Harr ASAP to avoid being dropped from the release. At least let us know "nay" if that is the answer! Randolph E. Harr, Logic Modeling Corp., randyh@lmc.com 1520 McCandless Drive, Milpitas, CA 95035; 408.957.5241 408.945.9181 (fax) <==============+++++++++++++++++************** From lmsi!milpitas.lmc.com!randyh@UB.com Fri Oct 8 01:59:55 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21593; Fri, 8 Oct 93 01:59:55 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA14956; Thu, 7 Oct 93 18:46:40 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA03821; Thu, 7 Oct 93 18:43:49 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA02408; Thu, 7 Oct 93 18:43:51 PDT Date: Thu, 7 Oct 93 18:43:51 PDT From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9310080143.AA02408@fiji.lmsi.com> To: ibis@vhdl.org Subject: Re: VINH and VINL *** My comments look like this *****, Randy Harr > From intelhf.intel.com!ccm!Don_A_Telian@lmc.com Thu Oct 7 17:15:10 1993 > To: Will_Hobbs@ccm.hf.intel.com, Arpad_Muranyi@ccm.hf.intel.com, qdt!sal!jonp, > ibis@vhdl.org > Subject: Re: VINH and VINL > Content-Length: 1518 > X-Lines: 42 > > > >>>> Howdy, My comments look like this >>>>> , Don Telian > >>>> Jon Powell's original memo follows.... > > > Fellow IBIS type persons, > > At the recent IBIS phone call I volunteered to author a BIRD on the > subject of requiring VINH and VINL specifications for input devices. > This was to avoid the problem of useless but IBIS legal input devices > with no logic threshold. Upon studying the problem I noticed that there > is actually a larger change required than I had anticipated and I > believe I should solicit comments before I actually write the BIRD. > The problem is two fold: > > First. I believe that our current model-types are not sufficiently > exclusive. We have INPUT OUTPUT I/O 3-STATE and OPEN_DRAIN. Under > what category does a 3-state I/O fall? > > >>>>> If it's "i/o", it's got to be "3-state", unless it intends > >>>>> to only drive itself. Right? Consequently, "3-state I/O" > >>>>> and "I/O" are the same thing. > **** No, could be input with open collector and maybe a PUP resistor internal. **** Siuki and I have been having many discussions in this area and feel it **** needs to be clarified between active and passive drivers. Once this is **** done, seemingly simple items like signal direction become clearer to **** define and understand. **** rest of message cut; no additional comment form me From lmsi!milpitas.lmc.com!randyh@UB.com Fri Oct 8 10:01:54 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24399; Fri, 8 Oct 93 10:01:54 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA00636; Fri, 8 Oct 93 09:45:54 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA06962; Fri, 8 Oct 93 09:42:26 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA02621; Fri, 8 Oct 93 09:42:25 PDT Date: Fri, 8 Oct 93 09:42:25 PDT From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9310081642.AA02621@fiji.lmsi.com> To: ibis@vhdl.org Subject: Final day for press release approvals! Cc: rkelley@tarheel.b23b.ingr.com, 71436.1314@compuserve.com, pzc@cadence.com, cindim@metasw.com, sunkist!zed!dino!cjs@sun.com, cjones@performance.com, hobbswil@ccm.hf.intel.com, randyh@lmc.com We are down to the wire and still missing a number of companies. The PR firm is awaiting my final email of companies so they can start production today. I will wait till 4pm PST. Email or call me if I have not heard from you. randy harr, 408.945.9181 (fax), randyh@lmc.com Latest list: To date (9:30am), I have received the following confirmations / ok's to use company names in the IBIS press release with a corresponding contact name(s): Ansoft Corporation Cadence Design Systems Interconnectix, Inc. MicroSim Corporation North Carolina State University Performance Signal Integrity Quad Design Quantic Laboratories Inc. Siemens Nixdorf Information Systems AG/Cadlab The following comapnies have informed me or Will Hobbs that the fax is on its way: Integrity Engineering Intusoft Mentor Graphics Corporation Meta-Software We are still anxciously awaiting to hear anything from: Contec Microelectronics USA Inc. HyperLynx Intel Corporation Intergraph Electronics Texas Instruments Zeelan Technology, Inc. From lmsi!milpitas.lmc.com!randyh@UB.com Fri Oct 8 17:31:07 1993 Return-Path: Received: from ub-gate.UB.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02334; Fri, 8 Oct 93 17:31:07 PDT Received: from lmsi.UUCP by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA17326; Fri, 8 Oct 93 17:23:30 PDT Received: from fiji.lmsi.com by lmsi.milpitas.lmc.com (4.0/SMI-4.1/wfh-930218) id AA08981; Fri, 8 Oct 93 17:21:00 PDT Received: by fiji.lmsi.com (4.1/SMI-4.1) id AA02827; Fri, 8 Oct 93 17:21:00 PDT Date: Fri, 8 Oct 93 17:21:00 PDT From: randyh@milpitas.lmc.com (Randy Harr) Message-Id: <9310090021.AA02827@fiji.lmsi.com> To: ibis@vhdl.org Subject: IBIS PRESS RELEASE IN PRODUCTION! Cc: 71436.1314@compuserve.com, cindim@metasw.com, cjones@performance.com, dino!cjs@UB.com, hobbswil@ccm.hf.intel.com, pzc@cadence.com, randyh@lmc.com, rkelley@tarheel.b23b.ingr.com THE PRESS RELEASE IS IN PRODUCTION !!! Look for info to start appearing the week of 18th October and phone calls to come in by 13th October. Many thanks to Don Tellian for his phone call campaign, to LMC staff for digging up names and phone #'s and putting in frantic calls, and Will Hobbs for running around like a chicken with his head cut off inside Intel to get approvals. We never heard from: Texas Instruments The following comapnies have either voice called or emailed info with followup faxes still on the way: Anacad High Design Technology Intergraph Electronics Intusoft Intel Corporation These companies met the muster and got their faxes to us: Ansoft Corporation Atmel Corp. Cadence Design Systems CONTEC Microelectronics USA Inc. HyperLynx Integrity Engineering Interconnectix, Inc. Mentor Graphics Corporation Meta-Software MicroSim Corporation North Carolina State University Performance Signal Integrity Quad Design Quantic Laboratories Inc. Siemens Nixdorf Information Systems AG/Cadlab Zeelan Technology, Inc. Thanks to all for contributing / participating in this momentus effort -- 21 Companies listed! Randolph E. Harr, Logic Modeling Corp., randyh@lmc.com From wr@apathix.cadlab.de Wed Oct 13 05:51:56 1993 Return-Path: Received: from mail.Germany.EU.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13559; Wed, 13 Oct 93 05:51:56 PDT Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet id eA23676; Wed, 13 Oct 1993 13:48:33 +0100 Received: by cadlab.cadlab.de (5.51/12.71); Wed, 13 Oct 93 13:48:47 +0100 Message-Id: <9310131250.AA06635@apathix.cadlab.de> Received: by apathix.cadlab.de (4.1/12.71); Wed, 13 Oct 93 13:50:33 +0100 Date: Wed, 13 Oct 93 From: Werner Rissiek To: ibis@vhdl.org Subject: 3-D model topics Hello Arpad and all others, this is just a very short comment on our opinion on the 3-D model topic. We completely agree on the necessity to describe the dynamical behavior of an output buffer by a current / voltage / time relationship. Therefore the black box approach seems ok. Based on our experience it is not enough to characterize an output by statical current /voltage curves and some ramp times. For example, when you are looking at the simulation of a buffer together with a transmission line structure you have the problem that the load impedance is a function of time resp. current. This current depends on the behavior of the connected transmission line. Therefore, I agree with your opinion that the driver's output impedance is also a function of the load impedance during the switch of the buffer. So we should work on the definition of the curves that are most suitable to describe these dependencies and on a measurement methodology to derive them. Sincerely Werner Rissiek Siemens Nixdorf / Cadlab From ccm!Will_Hobbs@intelhf.intel.com Tue Oct 26 13:03:22 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19565; Tue, 26 Oct 93 13:03:22 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0oruap-000MQTC; Tue, 26 Oct 93 13:02 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0orugc-0000r2C; Tue, 26 Oct 93 13:08 PDT Received: by ccm.hf.intel.com (ccmgate) Tue, 26 Oct 93 13:08:10 PST Date: Tue, 26 Oct 93 13:08:10 PST From: Will Hobbs Message-Id: <931026130810_4@ccm.hf.intel.com> To: ibis@vhdl.org Subject: 10/1, 10/22 Minutes, 10/29 meeting Hi, all. Our Fax machine chose last week to go out to lunch without telling us. The minutes from the 10/1 Open Forum meeting were only partially sent out, and the result was that the 10/22 meeting was under-attended. We therefore decided to re-convene on 10/29. We faxed out the 10/22 minutes and are re-fax-ing the minutes from the 10/1 meeting, along with BIRD #2. If you are accustomed to getting these faxes and don't get these, please send me mail: hobbswil@ccm.hf.intel.com Thanks. Will From ccm!Will_Hobbs@intelhf.intel.com Tue Oct 26 17:28:23 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22043; Tue, 26 Oct 93 17:28:23 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0oryjI-000MRNC; Tue, 26 Oct 93 17:27 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0oryp7-0000fOC; Tue, 26 Oct 93 17:33 PDT Received: by ccm.hf.intel.com (ccmgate) Tue, 26 Oct 93 17:33:13 PST Date: Tue, 26 Oct 93 17:33:13 PST From: Will Hobbs Message-Id: <931026173313_5@ccm.hf.intel.com> To: ibis@vhdl.org Subject: IBIS Minutes, IBIS 10/29 meeting, re-post ----- Transcript of session follows ----- 550 analog.ingr.com (ether)... 550 Host unknown 554 ... 550 Host unknown (Valid name but no data -[address]) ----- Unsent message follows ----- Received: from vhdl.vhdl.org by ingr.ingr.com (5.65c/1.920611) id AA19896; Tue, 26 Oct 1993 15:04:22 -0500 Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19565; Tue, 26 Oct 93 13:03:22 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0oruap-000MQTC; Tue, 26 Oct 93 13:02 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0orugc-0000r2C; Tue, 26 Oct 93 13:08 PDT Hi, all. This is a re-post of an earlier attempt. I'm not sure if the message got out. Our Fax machine chose last week to go out to lunch without telling us. The minutes from the 10/1 Open Forum meeting were only partially sent out, and the result was that the 10/22 meeting was under-attended. We therefore decided to re-convene on 10/29. We faxed out the 10/22 minutes and are re-fax-ing the minutes from the 10/1 meeting, along with BIRD #2. If you are accustomed to getting these faxes and don't get these, please send me mail: hobbswil@ccm.hf.intel.com Thanks. Will From ccm!Don_A_Telian@intelhf.intel.com Wed Oct 27 14:33:01 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29678; Wed, 27 Oct 93 14:33:01 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0osIT6-000MOvC; Wed, 27 Oct 93 14:31 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0osIYS-0001JwC; Wed, 27 Oct 93 14:37 PDT Received: by ccm.hf.intel.com (ccmgate) Wed, 27 Oct 93 14:37:20 PST Date: Wed, 27 Oct 93 14:37:20 PST From: Don A Telian Message-Id: <931027143720_3@ccm.hf.intel.com> To: Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org Subject: IBIS 10/29 meeting, 10/1, 10/22 Minutes info Hi, all. This is a re-post of an earlier attempt. I'm not sure if the message got out. Our Fax machine chose last week to go out to lunch without telling us. The minutes from the 10/1 Open Forum meeting were only partially sent out, and the result was that the 10/22 meeting was under-attended. We therefore decided to re-convene on 10/29. We faxed out the 10/22 minutes and are re-fax-ing the minutes from the 10/1 meeting, along with BIRD #2. If you are accustomed to getting these faxes and don't get these, please send me mail: hobbswil@ccm.hf.intel.com Thanks. Will From ccm!Cathy_Lundberg@intelhf.intel.com Thu Oct 28 12:15:53 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12208; Thu, 28 Oct 93 12:15:53 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0oscnt-000MNaC; Thu, 28 Oct 93 12:14 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0osctK-0000DTC; Thu, 28 Oct 93 12:20 PDT Received: by ccm.hf.intel.com (ccmgate) Thu, 28 Oct 93 12:20:13 PST Date: Thu, 28 Oct 93 12:20:13 PST From: Cathy Lundberg Message-Id: <931028122013_59@ccm.hf.intel.com> To: Will_Hobbs@ccm.hf.intel.com, ibis@vhdl.org Subject: IBIS minutes from 10/22/93 October 22, 1993 From: Cathy Lundberg (503) 696-4620, fax (503) 696-4904 Will Hobbs (503) 696-4369, fax (503) 696-4210 Subject: Minutes from IBIS Open Forum 10/22/93 To: Anacad Petra Osterman AnSoft Henri Maramis Cadence Design Sandeep Khanna, Chris Reed, Pawel Chadzynski, Kumar Contec Maah Sango*, Dermott Lynch High Design Technology Michael Smith HyperLynx Steve Kaufer, Kellee Crisafulli Integrity Engineering Greg Doyle, Wayne Olhoft Intel Corporation Stephen Peters*, Gary Saunders, Jim Alexander, Don Telia n*, Arpad Muranyi*, Donna Rendon*, Will Hobbs*, Cathy Lundberg* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd IntuSoft Charles Hymowitz Logic Modeling Corp. Siuki Chan, Randy Harr Mentor Graphics Greg Seltzer, Ravender Goyal Meta-Software Stephen Fenstermaker MicroSim Arthur Wong*, Meeling Wei, Jerry Brown, Graham Bell North Carolina State University Paul Franzon PC Ware Paul Munsey Performance Signal Integrity Vivek Raghawan, Eric Bracken* Quad-Design Jon Powell* Quantic Labs Mike Ventham, Zhen Mu Siemens Nixdorf Werner Rissiek Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun Zeelan Technology Hiro Moriyasu, George Opsahl, Samie Samaan, Tay Wu In the list above, attendees at the 10/22 meeting are indicated by * Next Meeting: October 29, 1993, 9:00 AM to 11:00 PDT. Phone number, (415) 904-8800. Reservation number is 550382 (this meeting only). Everyone should dial direct, ask for Will Hobbs in the IBIS Open Forum. Future meetings: November 12, 1993, 8:00-5:00 PST. Phone number: (916)356-9999. Reservation Number: 130639 Please note: If you know of someone new who wants to join the email reflector (ibis@lmc.com), or have updates to your email address, email to ibis-request@vhdl.org. 10/22 Meeting Agenda: 9:00 Check-in 9:10 Press Release Will Hobbs 9:20 Summit Plans Will Hobbs Open Issues: Our sincere apologies for the communication breakdown. Our fax machine didn't send out to everyone, and didn't generate an error message. As a result, we'll be changing the way minutes are sent out. We'll still fax the minutes, but we'll also post a notice on vhdl.org that the minutes have been faxed. If you don't receive them, please notify us. We'll meet next week since so many people didn't get the faxed minutes. We will send out a meeting reminder on the reflector, with bridge numbers, as well as the next several meeting time schedules and bridge numbers. IBIS Agenda, 10/29 9:00 Check-in 9:05 Introductions of new IBIS members 9:10 10/1 Minutes Review, Opens for New Issues Will Hobbs 9:15 Press Release, Trademark issue Randy Harr, Will Hobbs 9:25 Summit Planning Attendees Presenters Discussion Chairs, Topics 9:40 SCVs Will Hobbs, All 9:45 BBS Updates Siuki Chan, Randy Harr 9:50 BIRDS ECL, BIRD #1 Stephen Peters VHI, VIL Input Threshold, Bird #2 Jon Powell 10:20 10/1 Opens #6 Open Side (shelved) Kellee Crisafull i #7 .pkg Eric Bracken #8 Thresholds for Timing Jon Powell #9 Monotonicity Kellee Crisafulli, Arpad Muranyi #10 New Model Types (R-Packs, etc. Jon Powell? 10:50 Wrap-Up Action Items Next Meeting Plans Minutes I. FYI Intel has a graphics artist on retainer and the artist came up with some IBIS logos. AR: Will Hobbs bring IBIS logos to the November 12 IBIS meeting. II. Press Release: The press release was sent out October 13. Will Hobbs got calls from EE Times and Electronics Weekly in England. The list of participating companies was incorrect, TI was listed and shouldn't have been. Editors were called to correct it. EE Times announced IBIS two weeks ago for HyperLynx. The information was in Electronic News this week. The press release is on vhdl.org. III. Summit planning: There will be a bridge so people can call in if they must, and the agenda will have times listed on it. The bridge will have limited capacity and foils will probably not be available ahead of time. Therefore, companies are strongly urged to attend in person. Bridge number: (916)356-9999. Reservation Number: 130639 Summit Agenda: 8:00 - 8:20 Assemble, mingle, drink coffee, etc. 8:20 - 10:00 Presentations:Morning (20 - 30 minutes each) 10:00 - 10:20 Break 10:20 - 12:00 Presentations (20 - 30 minutes each) 12:00 - 1:00 Lunch Special Requirements? Showcases? 1:00 - 1:55 Panel Discussion 2:00 - 2:50 Panel Discussion 3:10 - 4:00 Panel Discussion 4:05 - 5:00 Panel Discussion Morning: presentations, 20-30 minutes each. We are still looking for additional presenters. John Powell - slew control devices Arpad Muranyi - V/I/T Eric Bracken - package parameters (.PKG) Will Hobbs - introductions or a topic Afternoon: The afternoon will be panel discussions rather than breakout sessions. Second round changes to the Golden parser. Slight changes in software would make it easier for companies to adapt for their own use. Don Telian will ask Paul Munsey to attend the summit. How to get active participation by semiconductor vendors. Need a leader. What enhancements do we want to include in 2.0? Hour at the end of the day for closure, BIRD votes. A product showcase is acceptable but up to each individual company. From randyh Fri Oct 29 08:43:04 1993 Return-Path: Received: by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21653; Fri, 29 Oct 93 08:43:04 PDT Date: Fri, 29 Oct 93 08:43:04 PDT From: randyh (Randy Harr) Message-Id: <9310291543.AA21653@vhdl.vhdl.org> To: ibis@vhdl.org Subject: Corrected, Final Press release Is updated and available on the repository. Ask for the files "pressrel.ps" or "pressrel.rtf". Thanks to all for their help. randy harr From cpk@Cadence.COM Fri Oct 29 11:58:41 1993 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24292; Fri, 29 Oct 93 11:58:41 PDT Received: from cadence.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA09934; Fri, 29 Oct 1993 11:52:19 -0700 Received: from hot by cadence.Cadence.COM (5.61/3.14) id AA18521; Fri, 29 Oct 93 11:48:41 -0700 Received: by hot (5.65+/1.5) id AA08687; Fri, 29 Oct 93 14:55:42 -0400 Date: Fri, 29 Oct 93 14:55:42 -0400 From: cpk@Cadence.COM (C. Kumar) Message-Id: <9310291855.AA08687@hot> To: ibis@vhdl.org Subject: suggested data format for handling multiple rail Re: Ibis meeting on Oct 29, 1993 Discussion on multiple voltage rails Ibis specs as of today allows referencing v-i data to either a power or ground rail. Now it has been recognized that multiple rails may exist and there may be components connected to the output whose v-i data may reference these other rails. We at cadence have used a simple representation for v-i data which embeds the rail reference voltage. Something similar, if adopted by ibis will allow much greater flexibility and allow for painless incorporation of multiple rails. Following is a sample of the data format datapoints vi vref=5 -5 -142ma 0.0 -137ma 0.5 -133ma 1 -128ma 1.5 -123ma 2 -118ma 2.5 -110ma 3 -98ma 3.5 -83ma 4 -64ma 4.5 -38ma 5 0 6 64ma 7 98ma 8 118ma 9 126ma 10 137ma end vi At the start of the vi statment the referencing voltage vref is explicitly given. The voltage value in the left column is absolute voltage (referenced to 0). - kumar From ccm!Will_Hobbs@intelhf.intel.com Fri Oct 29 15:12:42 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26486; Fri, 29 Oct 93 15:12:42 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0ot22R-000MO7C; Fri, 29 Oct 93 15:11 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0ot282-0000EbC; Fri, 29 Oct 93 15:17 PDT Received: by ccm.hf.intel.com (ccmgate) Fri, 29 Oct 93 15:17:06 PST Date: Fri, 29 Oct 93 15:17:06 PST From: Will Hobbs Message-Id: <931029151706_2@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Multiple Voltage Rails Message from Cadence Note: I am posting this for Kumar, who is experiencing difficulties accessing vhdl.org. Will To: ibis@vhdl.org Subject: suggested data format for handling multiple rail Re: Ibis meeting on Oct 29, 1993 Discussion on multiple voltage rails Ibis specs as of today allows referencing v-i data to either a power or ground rail. Now it has been recognized that multiple rails may exist and there may be components connected to the output whose v-i data may reference these other rails. We at cadence have used a simple representation for v-i data which embeds the rail reference voltage. Something similar, if adopted by ibis will allow much greater flexibility and allow for painless incorporation of multiple rails. Following is a sample of the data format datapoints vi vref=5 -5 -142ma 0.0 -137ma 0.5 -133ma 1 -128ma 1.5 -123ma 2 -118ma 2.5 -110ma 3 -98ma 3.5 -83ma 4 -64ma 4.5 -38ma 5 0 6 64ma 7 98ma 8 118ma 9 126ma 10 137ma end vi At the start of the vi statment the referencing voltage vref is explicitly given. The voltage value in the left column is absolute voltage (referenced to 0). - kumar From ccm!Cathy_Lundberg@intelhf.intel.com Fri Oct 29 15:27:51 1993 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26775; Fri, 29 Oct 93 15:27:51 PDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0ot2HB-000MOZC; Fri, 29 Oct 93 15:26 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0ot2Mn-0000MUC; Fri, 29 Oct 93 15:32 PDT Received: by ccm.hf.intel.com (ccmgate) Fri, 29 Oct 93 15:32:21 PST Date: Fri, 29 Oct 93 15:32:21 PST From: Cathy Lundberg Message-Id: <931029153221_10@ccm.hf.intel.com> To: ibis@vhdl.org Subject: directions to SC4 The IBIS summit will be held November 12, 1993, from 8:00 to 5:00 in SC4-150. From the San Jose airport, take Guadalupe Parkway North (or west). Guadalupe Parkway ends at Highway 101, go North. Continue on 101 to Great America Parkway, known also as Bowers Avenue to the South. Take Bowers Avenue South and turn left onto Walsh Avenue. Santa Clara 3, 4, and 5 are in the block bordered by Walsh Avenue and Northwestern Parkway, to the northwest of those two streets. The address for Santa Clara 4 is 2625 Walsh Avenue. To have a map faxed to you, please call Donna Rendon at (503) 696-4949 or Cathy Lundberg at (503) 696-4620. From qdt!sal!jonp@uunet.UU.NET Mon Nov 1 17:13:57 1993 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01828; Mon, 1 Nov 93 17:13:57 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11289; Mon, 1 Nov 93 20:13:08 -0500 Received: from qdt.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 201131.25609; Mon, 1 Nov 1993 20:11:31 EST Received: from sal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00989; Mon, 1 Nov 93 17:09:33 PST Received: from f14.qdt.com by sal.qdt.com (4.1/SMI-4.1) id AA20571; Mon, 1 Nov 93 17:09:31 PST Date: Mon, 1 Nov 93 17:09:31 PST From: qdt!sal!jonp@uunet.UU.NET (Jon Powell) Message-Id: <9311020109.AA20571@sal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA04386; Mon, 1 Nov 93 17:09:32 PST To: ibis@vhdl.org Subject: BIRD 2 Hey you IBIS type guys you, Here is the original text for BIRD 2. We had some discussion on this at the last phone call and I believe we will be having more at the upcoming face to face. I would be willing to drop this issue in exchange for a more sweeping "input thresholds" spec, or not. jon Buffer Issue Resolution Document (BIRD) BIRD ID#: 2 ISSUE TITLE: Requiring VIH VIL thresholds for input devices REQUESTOR: Jon Powell, Quad Desgin DATE SUBMITTED: 10/4/93 DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: The V1.1 IBIS specification does not require the presence of input thresholds on input devices. This allows data-generators to omit thresholds and still create "IBIS LEGAL" models. Input devices with no stated digital logic input thresholds would only be usefull if the inputs were totaly analog devices (a condition that is not in the main-stream of IBIS targetted devices). Requiring a low and high threshold for all input devices is therefor a reasonable requirement that adds information without creating undo restrictions. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: No new keywords are required. The following text to be added to the Other Notes section of the [Model] keyword description: The sub-parameters Vinl and Vinh are required for Model_types of: "Input" and "I/O". Omission of Vinl or Vinh for these devices will cause a parser error. Any other device type that contains a Vinl or Vinh parameter will cause a parser warning. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: There are devices that are not Input or Outputs and are not handled by our current set of model types. For instance: Termination Resistor Packs Termination Diode Packs Descrete 2 port devices I believe that more change is needed in this particular area but that that change is large enough that we should discuss it at our meeting as opposed to random email messages. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: {These documents will be archived, so use this section to carry any detail that is not essential to the previous section, but should not be lost.} *******************************************************************************