From owner-ibis Fri Nov 1 08:09:55 1996 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA07739 for ; Fri, 1 Nov 1996 08:09:54 -0800 (PST) Received: from pyrodactyl.or.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA24045; Fri, 1 Nov 96 07:58:34 -0800 Received: by pyrodactyl.or.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id PAA23063; Fri, 1 Nov 1996 15:58:26 GMT From: jmoll@pyramid.com (Jeff Moll) Message-Id: <199611011558.PAA23063@pyrodactyl.or.pyramid.com> Subject: Re[6]: Ramp Def. ?? (fwd) To: ibis@vhdl.org Date: Fri, 1 Nov 1996 07:58:26 -0800 (PST) Cc: jmoll@pyrodactyl.or.pyramid.com (Jeff Moll) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This is the first time I have responded and not for what I would have liked. We ALL must remember that the level of experience for this reflector site ranges from NCG to Guru. When a reponse is given it should be in the context that is to the point and understandable by a wide audience. What is clear as day to one may not be for MANY others. The reason for this site is to bounce ideas off each other and to EDUCATE others. What has happened in the case below is a side comment has been read as sarcasm, which can be demeaning to the person(s) reading the mail. When I read the original response from Arpad I detected sarcasm whether it was meant or not. Sorry Arpad.... I have noticed a rash of unsubscribe lately, I hope it is for other reasons. Now lets move forward and get on with technical portion of our show..... I concede my soap box... Jeffery.... Forwarded message: > From owner-ibis@vhdl.vhdl.org Thu Oct 31 18:15:32 1996 > Date: Thu, 31 Oct 96 17:12:00 PST > From: Arpad Muranyi > Message-Id: > To: ibis@vhdl.org > Subject: Re[6]: Ramp Def. ?? > > > Text item: > > Ahmed, > > I meant to say that lawyers have a good ability to put things in words so that > noone can misinterpret what they say at a later time. (I could be wrong on that > though). > > Writing a spec in a non-misinterpretable way is very difficult, and I find that > very often what I meant to say gets interpreted differently by someone else, > because they have a different vocabulary, background, mindframe, etc. This is > what might have been the case here too. > > It was totally clear to me that both places were saying the same, and yet you > thought that it meant rail-to-rail in the first place, and 20-80 % in the > second. However, you were the first one I heard this interpretation from... > > Arpad > ================================================================================ > > > Hello Arpad; > > In your last note on this subject you wrote: > > " I quess, this could have been written up a little more clearly, but we are > engineers, not lawyers. And so far I didn't hear that any one else was > confused by this." > > I do not understand! What point or points are you making with that paragraph? > > Regards, Ahmed. > |---------------------------------------+------------------------------------| > |Ahmed Omer | Advanced Interconnect Systems Labs | > |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | > | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | > |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 > | > |Fax: 512-933-5845 | Austin, TX 78721 | > > |---------------------------------------+------------------------------------| > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > X-Sun-Charset: US-ASCII > Subject: Re: Re[4]: Ramp Def. ?? > To: ibis@vhdl.org > Message-Id: <9610311510.AA24827@trailblazer.aisl.aus> > From: omera@trailblazer.sps.mot.com (Ahmed Omer) > Date: Thu, 31 Oct 1996 09:10:01 -0600 > Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) > id AA24827; Thu, 31 Oct 1996 09:10:01 -0600 > Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI- > 4.1/Email-2.0) > id AA11454 for ibis@vhdl.org; Thu, 31 Oct 96 08:09:09 MST > Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 > 10/25/93) > id AA16258 for ibis@vhdl.org; Thu, 31 Oct 96 08:09:13 MST > Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by vhdl. > vhdl.org (8.7.3/8.7.3) with SMTP id HAA09744 for ; Thu, 31 Oct 19 > 96 07:20:34 -0800 (PST) > Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c > om (8.8.2/8.7.3) with ESMTP id HAA18237; Thu, 31 Oct 1996 07:21:31 -0800 (PST) > Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) > by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id HAA12474; Thu, 31 Oct 1996 07: > 18:59 -0800 (PST) > Return-Path: owner-ibis@vhdl.vhdl.org > -- Jeffery L. Moll email: jmoll@pyramid.com Senior Member Technical Staff Pyramid Technology - A Siemens-Nixdorf Company (503) 690-6208 15400 NW Greenbrier Pkwy Suite 200 Fax: (503) 690-7704 Beaverton OR 97006-5783 From owner-ibis Fri Nov 1 09:29:58 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA08356 for ; Fri, 1 Nov 1996 09:29:58 -0800 (PST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id JAA06634 for ; Fri, 1 Nov 1996 09:19:01 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id JAA06678 for ibis@vhdl.org; Fri, 1 Nov 1996 09:18:59 -0800 (PST) Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Fri, 01 Nov 96 09:18:59 PST Date: Fri, 01 Nov 96 09:14:00 PST From: Arpad Muranyi Message-ID: To: scotts@actel.com_at_smtpgate@ccm.hf.intel.com, ibis@vhdl.org Subject: Re[4]: R_Pad? and transistor diodes in HSPICE Text item: Scott and Sascha, It is true that HSPICE does not have an independent parameter for the bulk resistance that you would like to use for just the diode resistance. However, you can get around that problem by inserting a discrete resistor between the bulk node and whatever that connects to. This extra resistor will not effect the currents through the channel, only through the diodes. This way you can achieve a different value for the horizontal and vertical resistances. Sascha, regarding your statement "huge extra expenditure to generate IBIS models", I disagree. You, who want to make an IBIS model, shouldn't have to fix the SPICE model first. That is the responsibility of those who make the SPICE models (and all SPICE vs. IBIS advocates). What you need to decide is whether you are going to take SPICE models or measured data for the basis of your IBIS models. Regarding the missing "IK (forward knee current) parameter", I can't comment, you need to talk to your SPICE tool representative about that. Scott, the above method (using an extra resistor in series with the bulk node) might fix your problem, and then you won't have to "pull out" the diode from the MOSFET model. However, that is your choice. If you feel you can model the diode more accurately with an external diode, you can certainly do that. Just as a side note, in an attempt to fix a similar problem on a third party SPICE model, I couldn't add Drain and Source resistances, because those would have altered the I-V curve in the operating region also (which were good to start out with). Adding the bulk resistance didn't do the job fully either. So I added a "behavioral half sided" resistor (along with a bulk resistor) which acted as a short when the current was flowing in one direction, and acted as a resistor when the current was flowing in the other direction. This way I could avoid the modification of the I-V curve in the operating region, yet I fixed my I-V curve in the clamping region. Here is the "half sided" resistor model: ********************************************************************** .PARAM Res = 10 Eres Pos Neg VOL = 'min(0,I(Eres)*Res)' ********************************************************************** I hope this helps, Arpad Muranyi Intel Corporation ================================================================================ Arpad, I'm just a very beginner in IBIS modelling and I came across the same problem Scott Schlachter rised up. It was very kind if you could tell me how you handle this problem or if I perhaps misunderstood something. In your answer to Scott Schlachters question you wrote: >If you have access to an HSPICE manual, look up the RD, RDC, RS, >RSC, etc. parameters. Don't let yourself get confused that these >are Drain and Source resistance numbers; the currents of parasitic >diodes go through Drain, Source, and Bulk. I think you are absolutely right when saying it is possible to correctly model the resistance of the diodes. But there are some problems with the HSPICE diode implementatation, anyhow. RD, RDC, RSH ... specify the diode resistance. HSIPCE assumes the currend through the drain-bulk diode (for instance) to flow the same way as the drain-source currend does, so only one resistor is used in the HSPICE model (I guess to simplify numerical algorithms). Actually there are two differend resistances to take into account. Rdrain decreases as gate width increases and increases as HDIF+LD+LDD (contact to gate distance) increases but Rdiode decreases as both parameters increase. So I have to manually correlate every transistor diode params with actual measurment. If using only a few transistor types in gate arrays it is possible but otherwise this will cause a huge extra expenditure to generate IBIS models. Additionally there is no IK (forward knee current) parameter; neigther in ACM=0, 1, 2 nor 3. So it becomes impossible to model low and high current charactristics correctly. I was very pleased if you counceled me, much thanks in advance. Kindest regards Sascha Pawel Arpad, In regard to RS, RD, and RSH, it appears that they are representing only the horizontal resistance values associated with the transistor (looking at a cutaway view of the transistor). This does not seem like it is a reasonable resistance to use for the real diode current path, as that path is more of a vertical path through the transistors Drain, followed by a (largely) vertical path through the substrate (N-transistor). How accurate is RD for modeling the Drain resistance verticaly? Also, the resistance through the substrate seems to be completely ignored. It just seems to us at this point that pulling the diode out of the transistor would be a better way to go (allowing for a more accurate diode representation by having it be a seperate component). Under ACM=2, the diode can be surpressed by setting IS, AD, and AS = 0. Perhaps, though, we might be interpreting this model incorrectly. I look forward to your feedback on this matter. Regards, -Scott Schlachter Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Re[2]: R_Pad? To: Arpad_Muranyi@ccm.fm.intel.com Message-Id: <9610302158.AA07220@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Wed, 30 Oct 96 14:58:05 PPE Received: by ricky.sun_net (4.1/SMI-4.1) id AA07220; Wed, 30 Oct 96 14:58:05 PPE Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA28880; Wed, 30 Oct 96 13:58:06 PST Received: from actel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 30 Oct 1996 22:02:16 GMT Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by fm mail.fm.intel.com (8.7.4/8.7.3) with ESMTP id OAA07617 for ; Wed, 30 Oct 1996 14:03:51 -0800 (PST) Return-Path: scotts@actel.com From owner-ibis Fri Nov 1 09:49:19 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA08552 for ; Fri, 1 Nov 1996 09:49:18 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Fri, 1 Nov 1996 17:38:29 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id JAA12138; Fri, 1 Nov 1996 09:36:51 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 01 Nov 96 09:36:50 PST Date: Fri, 01 Nov 96 09:31:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org cc: jmoll@pyrodactyl.or.pyramid.com Subject: Re[7]: Ramp Def. ?? (fwd) Text item: Jeffery, Thanks for your note. You are absolutely right about refraining ourselves from sarcasm. I admit that I some times do write sarcastic things, or some times I am trying to be funny which doesn't always come trhough in a written form. But re-eading the quoted text below, I can't find anything like that. I am not sure if you are referring to the lawyer part or the statement about "you were the first one...", but I meant both in an honest, respectful and serious way. I apologize if I offended anyone with what I wrote, and I will watch my mouth (pen, or keyboard) in the future more carefully. Just a note: We all have a different cultural background; I personally came to the US when I was over 24 years old. Having different experiences in life could cause situations when something I say seriously, might sound funny, or offending to others or vica versa. Again, apologies if I hurt anyone. Sincerely, Arpad Muranyi Intel Corporation ================================================================================ This is the first time I have responded and not for what I would have liked. We ALL must remember that the level of experience for this reflector site ranges from NCG to Guru. When a reponse is given it should be in the context that is to the point and understandable by a wide audience. What is clear as day to one may not be for MANY others. The reason for this site is to bounce ideas off each other and to EDUCATE others. What has happened in the case below is a side comment has been read as sarcasm, which can be demeaning to the person(s) reading the mail. When I read the original response from Arpad I detected sarcasm whether it was meant or not. Sorry Arpad.... I have noticed a rash of unsubscribe lately, I hope it is for other reasons. Now lets move forward and get on with technical portion of our show..... I concede my soap box... Jeffery.... Forwarded message: From owner-ibis@vhdl.vhdl.org Thu Oct 31 18:15:32 1996 Date: Thu, 31 Oct 96 17:12:00 PST From: Arpad Muranyi Message-Id: To: ibis@vhdl.org Subject: Re[6]: Ramp Def. ?? Text item: Ahmed, I meant to say that lawyers have a good ability to put things in words so that noone can misinterpret what they say at a later time. (I could be wrong on that though). Writing a spec in a non-misinterpretable way is very difficult, and I find that very often what I meant to say gets interpreted differently by someone else, because they have a different vocabulary, background, mindframe, etc. This is what might have been the case here too. It was totally clear to me that both places were saying the same, and yet you thought that it meant rail-to-rail in the first place, and 20-80 % in the second. However, you were the first one I heard this interpretation from... Arpad ============================================================================= > > > Hello Arpad; > > In your last note on this subject you wrote: > > " I quess, this could have been written up a little more clearly, but we are > engineers, not lawyers. And so far I didn't hear that any one else was > confused by this." > > I do not understand! What point or points are you making with that paragraph? > > Regards, Ahmed. > |---------------------------------------+------------------------------------ | > |Ahmed Omer | Advanced Interconnect Systems Labs | > |E-MAIL: omera@trailblazer.sps.mot.com | Semiconductor Products Sector | > | : R28450@email.sps.mot.com | M O T O R O L A, Inc. | > |Phone: 512-933-2247 | 3501 Ed Bluestein Blvd MDrop: F36 > | > |Fax: 512-933-5845 | Austin, TX 78721 | > > |---------------------------------------+------------------------------------ | > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > X-Sun-Charset: US-ASCII > Subject: Re: Re[4]: Ramp Def. ?? > To: ibis@vhdl.org > Message-Id: <9610311510.AA24827@trailblazer.aisl.aus> > From: omera@trailblazer.sps.mot.com (Ahmed Omer) > Date: Thu, 31 Oct 1996 09:10:01 -0600 > Received: by trailblazer.aisl.aus (5.x/SMI-SVR4) > id AA24827; Thu, 31 Oct 1996 09:10:01 -0600 > Received: from emailmesa (emailmesa.sps.mot.com) by mogate.sps.mot.com (4.1/SMI- > 4.1/Email-2.0) > id AA11454 for ibis@vhdl.org; Thu, 31 Oct 96 08:09:09 MST > Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 > 10/25/93) > id AA16258 for ibis@vhdl.org; Thu, 31 Oct 96 08:09:13 MST > Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by vhdl. > vhdl.org (8.7.3/8.7.3) with SMTP id HAA09744 for ; Thu, 31 Oct 19 > 96 07:20:34 -0800 (PST) > Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.inte l.c > om (8.8.2/8.7.3) with ESMTP id HAA18237; Thu, 31 Oct 1996 07:21:31 -0800 (PST) > Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4 ]) > by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id HAA12474; Thu, 31 Oct 1996 07: > 18:59 -0800 (PST) > Return-Path: owner-ibis@vhdl.vhdl.org > -- Jeffery L. Moll email: jmoll@pyramid.com Senior Member Technical Staff Pyramid Technology - A Siemens-Nixdorf Company (503) 690-6208 15400 NW Greenbrier Pkwy Suite 200 Fax: (503) 690-7704 Beaverton OR 97006-5783 Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 X-Mailer: ELM [version 2.4 PL25] Cc: jmoll@pyrodactyl.or.pyramid.com (Jeff Moll) Date: Fri, 1 Nov 1996 07:58:26 -0800 (PST) To: ibis@vhdl.org Subject: Re[6]: Ramp Def. ?? (fwd) Message-Id: <199611011558.PAA23063@pyrodactyl.or.pyramid.com> From: jmoll@pyramid.com (Jeff Moll) Received: by pyrodactyl.or.pyramid.com (8.6.12/Pyramid_Internal_Configuration) id PAA23063; Fri, 1 Nov 1996 15:58:26 GMT Received: from pyrodactyl.or.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA24045; Fri, 1 Nov 96 07:58:34 -0800 Received: from gossip.pyramid.com (gossip.pyramid.com [129.214.1.101]) by vhdl.v hdl.org (8.7.3/8.7.3) with SMTP id IAA07739 for ; Fri, 1 Nov 1996 08:09:54 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.7.6/8.7.3) with ESMTP id IAA21435; Fri, 1 Nov 1996 08:05:14 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.4/8.7.3) with ESMTP id IAA21177; Fri, 1 Nov 1996 08:05:15 -0800 (P ST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Fri Nov 1 11:06:22 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id LAA09316 for ; Fri, 1 Nov 1996 11:06:21 -0800 (PST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id KAA27116 for ; Fri, 1 Nov 1996 10:55:30 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id KAA26759 for ibis@vhdl.org; Fri, 1 Nov 1996 10:55:28 -0800 (PST) Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Fri, 01 Nov 96 10:55:27 PST Date: Fri, 01 Nov 96 10:50:00 PST From: Arpad Muranyi Message-ID: To: ahilbers@tulip.nl_at_smtpgate@ccm.hf.intel.com, ibis@vhdl.org Subject: Re[3]: Rising Waveform Loading Effects: smart simulator Text item: Alex, Actually the situation is not as complicated as you might think. I will try to illustrate it with an example. When you do curve fitting to an equation, you usually have an idea whether the curve is exponential, sinusoidal, or whatever. So you pick an equation, and then apply coefficients to it so that it fits the data. With a second order polynomial eqation you would have: k1*x^2 + k2*x + k3 In this equation, the x variables determine the general shape of the curve and the k factors modify it so that it fits the data. This is the principle I have in mund when I talk about the V-t curves. The simulator tools should have their algorythms, which would be the equivalent of the x variables in the above example, and the data, being the equivalent of the k factors, should alter the basic algoruthm to the particular buffer characteristics. I would call a simulator "bad" if it would, for example, simply copy the V-t data to become the output waveform. On the other hand, I would call a simulator "good" if it used the data in its algorythms in a processed "smart" way. However, since I am not a simulator tool programmer, I do not want to go into this topic any further. I will let those take over this conversation, who are experts at it. Arpad ============================================================================== Arpad, concerning your point: "What I mean by this is, that if the simulator is smart enough, it can take the data and modify it, derive new curves, etc. So, if you have an I-V curve and a V-t curve which was generated with 50 Ohm resistive load in the model, a good simulator should derive a new V-t curve that matches the different load resistance in that particular simulation. Taking this further, the simulator could make V-t curves with reactive loads also. In general, then, the simulator can simulate at each iteration with a different set of curves that matches any loading condition, even if the "load" is another non-linear I-V curve. The point here is that the data in the IBIS model is not supposed to be a limiting factor to what the simulator does with it." To me this seems to suggest - correct me if I am wrong - that the non linear time dependant behaviour that is not modelled by the Ibis model is to be derived by a good simulator. Isn't it easier to use a Spice model together with a normal simulator? In that case you don't have to go through the trouble of converting Spice design models into Ibis models, followed by making the simulator 'good'. Conversion may introduce errors and especially derivation of curves looks tricky. In the end this may not be faster than using the Spice models in the first place. Could you give me more insight on this matter? Alex Text item: Ed, Your concern is well taken. However, I would like to point out that an IBIS model is nothing but data. The V-t curve in the IBIS model is not supposed to be the same as the simulation waveforms, unless the load is identical to the load that was used to generate the V-t curve. The simulator can do anything to this data. What I mean by this is, that if the simulator is smart enough, it can take the data and modify it, derive new curves, etc. So, if you have an I-V curve and a V-t curve which was generated with 50 Ohm resistive load in the model, a good simulator should derive a new V-t curve that matches the different load resistance in that particular simulation. Taking this further, the simulator could make V-t curves with reactive loads also. In general, then, the simulator can simulate at each iteration with a different set of curves that matches any loading condition, even if the "load" is another non-linear I-V curve. The point here is that the data in the IBIS model is not supposed to be a limiting factor to what the simulator does with it. Of course this is not the only way things can be done, I was just trying to illustrate the concept. The reason resistive (and not reactive or transmission line) loads are preferred for generating V-t curves is that with a resistive load we get only what the buffer does. With other types of loads we get what the load does also. Why would one want to add all that to the V-t curves when it will have to be taken out anyway to model just the buffer alone? Arpad Muranyi Intel Corporation =============================================================================== = Hello to all, I am concerned about the validity of using IBIS models for general printed circuit board signal analysis in an environment of various types of loads, transmission lines, vias, pads, connectors, various terminations, etc. According to the IBIS specification V2.1 dated Dec. 13, 1995, for a rising waveform (for example), there are various loads specified as L_dut, R_dut, L_fixture, R_fixture, C_dut, and C_fixture. In addition data is to be taken with the effects of C_comp included. There is however no provision for generating curves with a transmission line load which is more typically the case, especially for high speed circuits. in actual circuit boards. It is well known however, that the ramp rate and levels reached will be affected by the loads. For example, changing the values of R_fixture and V_fixture on a typical buffer. (The s2ibis2 program will generate different curves for different values of R_fixture, for example IBIS curves for 50 ohms and 100 ohms is generated from a command file that specified curves for 50 and 100 ohms.) My question is this: If in an actual simulation environment we really have a different loading condition with transmission lines , vias, etc., how can we legitimately use an IBIS model that was generated with a different lumped element loading condition ? I hope someone can help me to understand how the IBIS models will accurately produce the correct physical response with an arbitrary but realistic loading condition, different from the test fixture, at least to a level of accuracy close to that which would result from the original transistor level spice model, say within 5%. Ed Boeckmann, "My comments reflect solely my own opinion!" Intergraph Corp. Huntsville AL 35894 tel. (205)-730-6219 fax (205)-730-6000 email efboeckm@ingr.com Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Encoding: 41 TEXT X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57 Date: Thu, 24 Oct 1996 10:25:42 -0500 Subject: Rising Waveform Loading Effects To: "'ibis@vhdl.org'" From: "Boeckmann, Ed (Edward F)" Message-ID: Received: by hq15.pcmail.ingr.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57) id <01BBC195.E3DA6810@hq15.pcmail.ingr.com>; Thu, 24 Oct 1996 10:26:59 -050 0 Received: from hq15.pcmail.ingr.com (hq15.pcmail.ingr.com [129.135.251.243]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA29698 for ; Thu, 24 O ct 1996 08:37:41 -0700 (PDT) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.7.6/8.7.3) with ESMTP id IAA14618; Thu, 24 Oct 1996 08:30:29 -0700 (PDT) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.4/8.7.3) with ESMTP id IAA00404; Thu, 24 Oct 1996 08:30:29 -0700 ( PDT) Return-Path: owner-ibis@vhdl.vhdl.org Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re[2]: Rising Waveform Loading Effects: smart simulator To: Arpad Muranyi Message-Id: <9609308467.AA846701741@uucpgt.tulip.nl> Encoding: 6326 Text From: "Hilbers, Alex" Date: Wed, 30 Oct 96 10:55:41 Received: from cc:Mail by uucpgt.tulip.nl id AA846701741 Wed, 30 Oct 96 10:55:41 Received: from uucpgt by tulip6.tulip.nl id aa02913; 30 Oct 96 12:04 WET Received: from tulip6 by ns.NL.net (5.65b/NLnet1.3) id AA09526; Wed, 30 Oct 1996 11:07:58 +0100 Received: from ns.NL.net (ns.NL.net [193.78.240.1]) by mailbag.jf.intel.com (8.8 .2/8.7.3) with SMTP id CAA10896 for ; Wed, 30 Oc t 1996 02:55:31 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by fmmail.fm.intel.com (8.7.4/8.7.3) with ESMTP id CAA08890 for ; Wed, 30 Oct 1996 02:52:14 -0800 (PST) Return-Path: ahilbers@tulip.nl From owner-ibis Fri Nov 1 12:10:12 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA09833 for ; Fri, 1 Nov 1996 12:10:11 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Fri, 1 Nov 1996 19:59:22 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id LAA20557; Fri, 1 Nov 1996 11:57:16 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 01 Nov 96 11:57:16 PST Date: Fri, 01 Nov 96 11:25:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org cc: dileep@contec.Apsimtech.COM Subject: Re[2]: Rising Waveform Loading Effects Text item: Dileep, If we go by your suggestion, we would have to specify every simulation algorythm in IBIS. The tool vendors would not subscribe to that, as I see it. Even the way IBIS is now with some of the rules on how I-V curves "must" be handeled was debated at length in the Open Forum meetings. I am referring to the clamp curves being subtracted from the pullup and/or pulldown curves, and the Vcc relative notation, for example. Take, for example, the Vcc-relative curves in IBIS. My intension was to enable GND bounce and Vcc droop simulations by properly referencing which pin these I-V curves get their currents from, with the added benefit of a nice symmetry. Also, with this notation all pullup curves go through the same point when Vds is 0, regardless of what the Vcc voltage is for each given curve (typ., min., max.), just like in the case of pulldown curves. This makes it a lot easier to compare them with each other. However, since it is fairly unusual to say that the origin of the plot is not at the GND potential, but at Vcc, many people have (or had) problems with this notation. (Even though ECL or the old tube technology does basically the same with all those negative voltages). Anyway, this and similar issues prompted lengthy debates on what the "right" way of doing things is. One argument I heared frequently was "give me raw data, and my tool will do the necessary things to it the way I believe is the right way". This is just an example for why you can't specify in the IBIS spec what the tool should do with the data. Tool vendors want to be able to differentiate themselves from others, because they believe they know it better how to do it right. And there is nothing wrong with it. The customer has to figure out which tool he believes before he invests. And, again, IBIS is not a device physics algorythm spec, but a data format spec. Now, if there is something missing in it in order to be able to simulate correctly with the given data, we can consider to add new data definitions to it. One example for this with respect to the V-t curves was the attempt to add a keyword that defined whether the device was CMOS or Bipolar. I don't remember where that issue stands now, but it seems to me that it was dropped. Without trying to be funny or sarcastic(!) this situation is similar to politics. Which is better, dictatorship, or freedom? In dictatorship you loose your freedom, but everything is unified, controlled, etc. In freedom you loose control, and things have a tendency to become caotic, etc. Anyway, since I am getting outside the range of my expertise, I better shut up and let the experts take over this topic. Sincerely, Arpad Muranyi Intel Corporation =============================================================================== Chris Rokusek, Quad Deisgn Technology wrote: > >There are a few "dimensions" of knowledge not explicity present in the >.ibs model which may be useful to a simulator: That is precisely my point. You are making certain assumptions and guesses, which are OUTSIDE the ibis specification. In fact you are trying to guess the information which ibis is trying to hide. What do you do if you encounter some data which does not fit any of your guesses? All the knowledge "dimensions" should be utilized in developing the specification, but once the specification is developed, it should have any loose ends. Let us assume that you have a simulator which can predict waveforms for any arbitrary load, given ONE waveform for one RESISTIVE load. But the ibis specification does not specify that. A model developer can specify a waveform into a general RLC load (as shown in the example on page 19 of 2.1 specification) and claim that they have provided a perfectly legal ibis model and now it is up to the simulator to do the rest. What does the simulator do in this case with the waveform with all the ringing, overshoot, undershoot etc.? The simulator should not place restrictions in ADDITION to the ibis specification. Therefore, if one waveform into one resistive load is all that is required, then it should be stated explicitly. Otherwise different people can make different assumptions and guesses. If certain things are REQUIRED to carry out a simulation, then the ibis model should SPECIFY those things instead of leaving them to guesswork. ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. X-Sun-Charset: US-ASCII Cc: dileep@contec.Apsimtech.COM Subject: Re: Rising Waveform Loading Effects To: ibis@vhdl.org Message-Id: <9610301630.AA20030@contec13.contec.COM> From: dileep@contec.Apsimtech.COM (Dileep Divekar) Date: Wed, 30 Oct 1996 08:30:53 +0800 Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA20030; Wed, 30 Oct 1996 08:30:53 +0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA15156; Wed, 30 Oct 96 08:22:05 PST Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id IAA26120; Wed, 30 Oct 1996 08:27:06 -0800 Received: from netcomsv.netcom.com (uucp7.netcom.com [163.179.3.7]) by vhdl.vhdl .org (8.7.3/8.7.3) with SMTP id IAA13026 for ; Wed, 30 Oct 1996 0 8:53:35 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.2/8.7.3) with ESMTP id IAA21097; Wed, 30 Oct 1996 08:51:43 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.7.4/8.7.3) with ESMTP id IAA21725; Wed, 30 Oct 1996 08: 49:09 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Fri Nov 1 12:50:28 1996 Received: from netcomsv.netcom.com (uucp4.netcom.com [163.179.3.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA10182 for ; Fri, 1 Nov 1996 12:50:28 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id MAA09723; Fri, 1 Nov 1996 12:25:34 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA27374; Fri, 1 Nov 96 12:17:57 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA22832; Fri, 1 Nov 1996 12:26:43 +0800 Date: Fri, 1 Nov 1996 12:26:43 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9611012026.AA22832@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Re[3]: Rising Waveform Loading Effects: smart simulator Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Arpad Muranyi wrote about the simulator being smart enough to fit an equation to the given data. The point I am trying to make is that sufficient data need to be provided. For example, a straight line is the simplest curve in two dimensions. The equation of a straight line has two unknowns. Therefore, at least two data points or two pieces of information are needed. There are infinite ways of drawing a straight line thru a single point. There is no unique way of defining a straight line in this case no matter how smart the fitting method is. Thus, given only one V-t waveform, it is not possible to predict many V-t waveforms for all possible loading conditions. ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Fri Nov 1 13:23:48 1996 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA10458 for ; Fri, 1 Nov 1996 13:23:47 -0800 (PST) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id OAA03060 for ; Fri, 1 Nov 1996 14:12:58 -0700 Received: from cds9258.cadence.com(158.140.32.4) by mailgate.cadence.com via smap (V1.0mjr) id sma846875398.004548; Fri Nov 1 12:09:58 1996 Received: from [158.140.8.75] (mac585.cadence.com [158.140.8.75]) by cds9258.Cadence.COM (8.7.3/8.7.3) with SMTP id LAA20018 for ; Fri, 1 Nov 1996 11:09:56 -0800 (PST) Date: Fri, 1 Nov 1996 11:09:56 -0800 (PST) X-Sender: dmehta@cds9258 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: dmehta@cadence.com (Dee Mehta) subscribe Dee Mehta Systems Core Competency Dmehta@cadence.com (408)428-5178 MS 1B1 From owner-ibis Fri Nov 1 13:43:34 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id NAA10604 for ; Fri, 1 Nov 1996 13:43:34 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Fri, 1 Nov 1996 21:32:44 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id NAA25039; Fri, 1 Nov 1996 13:30:27 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Fri, 01 Nov 96 13:30:27 PST Date: Fri, 01 Nov 96 13:25:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org cc: dileep@contec.Apsimtech.COM Subject: Re[5]: Rising Waveform Loading Effects: smart simulator Text item: Dileep, IBIS allows you to define up to a maximum of 100 waveform tables (V-t curves) in each buffer model. Each of these V-t tables have their own subparameters, such as Rfixture, so you can make a model which provides a series of V-t curves for the various loading conditions. Is that not enough for what you are trying to achieve? Arpad ================================================================================ Arpad Muranyi wrote about the simulator being smart enough to fit an equation to the given data. The point I am trying to make is that sufficient data need to be provided. For example, a straight line is the simplest curve in two dimensions. The equation of a straight line has two unknowns. Therefore, at least two data points or two pieces of information are needed. There are infinite ways of drawing a straight line thru a single point. There is no unique way of defining a straight line in this case no matter how smart the fitting method is. Thus, given only one V-t waveform, it is not possible to predict many V-t waveforms for all possible loading conditions. ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. X-Sun-Charset: US-ASCII Cc: dileep@contec.Apsimtech.COM Subject: Re: Re[3]: Rising Waveform Loading Effects: smart simulator To: ibis@vhdl.org Message-Id: <9611012026.AA22832@contec13.contec.COM> From: dileep@contec.Apsimtech.COM (Dileep Divekar) Date: Fri, 1 Nov 1996 12:26:43 +0800 Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA22832; Fri, 1 Nov 1996 12:26:43 +0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA27374; Fri, 1 Nov 96 12:17:57 PST Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id MAA09723; Fri, 1 Nov 1996 12:25:34 -0800 Received: from netcomsv.netcom.com (uucp4.netcom.com [163.179.3.4]) by vhdl.vhdl .org (8.7.3/8.7.3) with SMTP id MAA10182 for ; Fri, 1 Nov 1996 12 :50:28 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.7.6/8.7.3) with ESMTP id MAA25117; Fri, 1 Nov 1996 12:43:55 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.4/8.7.3) with ESMTP id MAA16766; Fri, 1 Nov 1996 12:43:54 -0800 (P ST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Fri Nov 1 13:51:55 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA10724 for ; Fri, 1 Nov 1996 13:51:54 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 1 Nov 96 13:41 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 1 Nov 96 13:40 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 1 Nov 96 13:43 PST Message-Id: Date: Fri, 1 Nov 96 13:43 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA 11/8/96 IBIS Open Forum Meeting Agenda for 11/8/96 Bridge Number Reservation # Passcode (916) 356-9200 2-104708 1692479 (Note, Starting time is now 16:00Z due to daylight savings time change) All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions Design SuperCon97 IBIS Meeting Huq - Host Company Selection s2ibis2 Plans Ross DAC97 IBIS Meeting Planning Rusher IEC Progress Rusher New Administrative Issues All 8:50 Technical Discussion BIRD39 - SPECIFICATION ENHANCEMENT (VOTE) Ross, All BIRD38 - MAXIMUM VOLTAGE (VOTE) PACKAGE COMMITTEE REPORT Peters BIRD35.2 - MULTI-STAGED OUTPUTS Ross PARSER STATUS Rokusek New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Fri Nov 1 13:52:27 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA10728 for ; Fri, 1 Nov 1996 13:52:26 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id NAA01907 for ; Fri, 1 Nov 1996 13:42:19 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma001745; Fri Nov 1 13:41:55 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA28843 for ibis@vhdl.org; Fri, 1 Nov 96 13:41:10 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA21677; Fri, 1 Nov 96 13:42:09 PST Date: Fri, 1 Nov 96 13:42:09 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9611012142.AA21677@rockie.nsc.com> To: ibis@vhdl.org Subject: National releases LAN IBIS model Cc: alans@lan.nsc.com IBIS fans, National Semiconductor has released the following LAN IBIS model today. This is available from our web site at: http://www.national.com/models/ibis/ibis.html dp83840a.ibs 10/100 Mb/s Ethernet Physical Layer National Semiconductor provides IBISv1.1 and IBISv2.1 models from selected product lines. Refer to www.national.com for the lastest available models. National Semiconductor provides technologies for moving and shaping information. The company focuses on communications, analog, and personal systems markets, and is the fourth largest U.S semiconductor merchant. Regards, Syed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Syed B. Huq huq@rockie.nsc.com ~ ~ National Semiconductor Corp. ~ ~ Tel:(408)721-4874; Fax:(408)721-4785 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-ibis Fri Nov 1 14:52:47 1996 Received: from netcomsv.netcom.com (uucp4.netcom.com [163.179.3.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA11465 for ; Fri, 1 Nov 1996 14:52:46 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA15443; Fri, 1 Nov 1996 14:29:45 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA01377; Fri, 1 Nov 96 14:25:32 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA22876; Fri, 1 Nov 1996 14:34:18 +0800 Date: Fri, 1 Nov 1996 14:34:18 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9611012234.AA22876@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Re[2]: Rising Waveform Loading Effects Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Arpad Muranyi, Intel Corporation wrote: >This is just an example for why you can't specify in the IBIS spec what the tool >should do with the data. Tool vendors want to be able to differentiate >themselves from others, because they believe they know it better how to do it >right. And there is nothing wrong with it. The customer has to figure out >which tool he believes before he invests. >And, again, IBIS is not a device physics algorythm spec, but a data format spec. I am not saying that IBIS should specify WHAT the simulator should do with the data. I am saying that IBIS should make sure that SUFFICIENT data is provided. Thus, it should not be necessary to make assumptions or guesses OUTSIDE of the specification. Again, I am not saying that IBIS should specify the algorithms. The simulator can use any algorithm as long as it makes sure that the characteristics specified in the IBIS model are reproduced. My understanding was that when a model developer makes an IBIS model, it is simulator independent. If IBIS specification does not want to make sure that enough data is provided and it wants to give freedom to the simulators, then is it acceptable for each simulator to have its own requirements, as long as the data is provided in the IBIS data FORMAT? Because some simulators may want to base the simulations on assumptions and guesses, whereas some may want to have more data. Again, going back to the curve fitting example, if the specification provides three data points, then the simulators can have their own algorithms and differentiate themselves by either fitting a straight line thru those three points, or fitting a quadratic. And if they want to be more agressive and make some assumptions and guesses, they can even fit a higher order polynomial. This is where the freedom part comes in. But if the specification provides only one data point, there is clearly insufficient information to do anything BUT only guesswork. ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Fri Nov 1 15:46:18 1996 Received: from netcomsv.netcom.com (uucp4.netcom.com [163.179.3.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA11971 for ; Fri, 1 Nov 1996 15:46:17 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id PAA17454; Fri, 1 Nov 1996 15:12:55 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA01557; Fri, 1 Nov 96 14:49:03 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA22884; Fri, 1 Nov 1996 14:57:49 +0800 Date: Fri, 1 Nov 1996 14:57:49 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9611012257.AA22884@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: Re[5]: Rising Waveform Loading Effects: smart simulator Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Arpad, >IBIS allows you to define up to a maximum of 100 waveform tables (V-t curves) in >each buffer model. Each of these V-t tables have their own subparameters, such >as Rfixture, so you can make a model which provides a series of V-t curves for >the various loading conditions. Is that not enough for what you are trying to >achieve? At the risk of repeating myself, the point I was trying to make was IBIS does ALLOW the model developer to specify 100 waveforms, but does not REQUIRE the waveform tables to follow certain restrictions or conventions. Therefore, is it then acceptable for each simulator to enforce its own REQUIREMENTS making IBIS models simulator dependent? Earlier, it was pointed out that if ONE waveform into ONE RESISTIVE load is specified, it is possible to predict the waveforms into any load. Then that particular simulator HAS to make sure that the waveform is specified into a RESISTIVE load, whereas, the IBIS specification ALLOWS the waveform specification into ANY load. What is the simulator expected to do if the model developer specifies the waveform into ANY load since that is ALLOWED by IBIS and hence it is a legal IBIS model? ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Fri Nov 1 16:49:56 1996 Received: from netcomsv.netcom.com (uucp8.netcom.com [163.179.3.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA12451 for ; Fri, 1 Nov 1996 16:49:56 -0800 (PST) Received: from symdes.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id QAA15890; Fri, 1 Nov 1996 16:30:45 -0800 Received: from taress.symmetry by symmetry.com (4.1/SMI-4.1) id AA20531; Fri, 1 Nov 96 16:07:19 PST Date: Fri, 1 Nov 96 16:07:19 PST From: zheng@symmetry.com (Zheng SHI) Message-Id: <9611020007.AA20531@ symmetry.com> To: ibis@vhdl.org subscribe From owner-ibis Fri Nov 1 18:51:55 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id SAA13362 for ; Fri, 1 Nov 1996 18:51:54 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id SAA05146 for ; Fri, 1 Nov 1996 18:41:03 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id SAA25074; Fri, 1 Nov 1996 18:39:13 -0800 (PST) Message-Id: <199611020239.SAA25074@ichips.intel.com> To: ibis@vhdl.org Subject: Re: Re[6]: Rising Waveform Loading Effects: smart simulator Date: Fri, 01 Nov 1996 18:41:04 -0800 From: Stephen Peters Hello Arpad, Dileep, others: I think Dileep's basic point has been missed, and it really needs to be responed to. Yes, as in Dileeps example of a V/T curve into a complex reactive load, it *is* possible to create a perfectly legal yet totally useless (to him, anyway) IBIS model. It is also possible to make a model that produces different results on different simulators. IBIS models are, to some extent, simulator dependent. However, I'd like to point out that in both these cases the model would also be useless to the model provider (i.e. silicon vendor). The whole point of this exersise it to produce simulation models others can use. It is incumbent upon the model provider to both produce a model that works with industy simultors and to validate/spec whatever model they provide. (That, by the way, goes for both transistor level as well as IBIS model). It is also incumbent upon the simulator vendors to stay current with the spec and the technology. I might also note that the IBIS committee has always relied on the simulator manufactures to tell us what kind of data is required for acurate behavioral simulation. If a simulator vendor belives that the spec is inadiqute(sp), or doesn't provide the right kind of data, they should speak up. By the same token, the IBIS committee should be listening.... Regards, Stephen Peters Intel Corp. Arpad, >IBIS allows you to define up to a maximum of 100 waveform tables (V-t curves) in >each buffer model. Each of these V-t tables have their own subparameters, such >as Rfixture, so you can make a model which provides a series of V-t curves for >the various loading conditions. Is that not enough for what you are trying to >achieve? At the risk of repeating myself, the point I was trying to make was IBIS does ALLOW the model developer to specify 100 waveforms, but does not REQUIRE the waveform tables to follow certain restrictions or conventions. Therefore, is it then acceptable for each simulator to enforce its own REQUIREMENTS making IBIS models simulator dependent? Earlier, it was pointed out that if ONE waveform into ONE RESISTIVE load is specified, it is possible to predict the waveforms into any load. Then that particular simulator HAS to make sure that the waveform is specified into a RESISTIVE load, whereas, the IBIS specification ALLOWS the waveform specification into ANY load. What is the simulator expected to do if the model developer specifies the waveform into ANY load since that is ALLOWED by IBIS and hence it is a legal IBIS model? ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Fri Nov 1 19:18:05 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id TAA13605 for ; Fri, 1 Nov 1996 19:18:05 -0800 (PST) Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQboam18006; Fri, 1 Nov 1996 22:06:44 -0500 (EST) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 1 Nov 1996 22:06:44 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00933; Fri, 1 Nov 96 18:22:52 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA02767; Fri, 1 Nov 96 18:22:51 PST Received: from uucp5.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp5.UU.NET [192.48.96.36]) id QQboai07413; Fri, 1 Nov 1996 21:06:48 -0500 (EST) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Fri, 1 Nov 1996 21:06:48 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00617; Fri, 1 Nov 96 16:33:48 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA01691; Fri, 1 Nov 96 16:33:48 PST Sender: uunet!qdt.com!jonp@uunet.uu.net Message-Id: <327A96EA.167EB0E7@qdt.com> Date: Fri, 01 Nov 1996 16:33:46 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Dileep Divekar Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: Rising Waveform Loading Effects: smart simulator References: <9611012026.AA22832@contec13.contec.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dileep Divekar wrote: > > Arpad Muranyi wrote about the simulator being smart enough > to fit an equation to the given data. The point I am trying > to make is that sufficient data need to be provided. For > example, a straight line is the simplest curve in two dimensions. > The equation of a straight line has two unknowns. Therefore, > at least two data points or two pieces of information are needed. > There are infinite ways of drawing a straight line thru a single > point. There is no unique way of defining a straight line in this > case no matter how smart the fitting method is. Thus, given only > one V-t waveform, it is not possible to predict many V-t waveforms > for all possible loading conditions. > ------------------------------------------------------------ > Dileep Divekar > Applied Simulation Technology, Inc. > 2188 Bering Drive > San Jose, CA 95131 > > Phone - (408)-434-0967 x 100 > Fax - (408)-434-1003 > Email - dileep@apsimtech.com > ------------------------------------------------------------ At Quad Design we use two VT waveforms. For standard CMOS this means one to 5V and one to 0V (it is different for TTL and ECL). We have discussed the fact that this sort of information needs to be put in a cook book but I guess we are all busy feeding our families. regards, jon From owner-ibis Sat Nov 2 21:48:04 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id VAA11259 for ; Sat, 2 Nov 1996 21:48:03 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id VAA06026 for ; Sat, 2 Nov 1996 21:37:56 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma005953; Sat Nov 2 21:37:41 1996 Received: from taux01.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA04269 for ibis@vhdl.org; Sat, 2 Nov 96 21:36:54 -0800 Received: from tasu41.nsc.com by taux01.nsc.com (4.1/SMI-4.1) id AA15149; Sun, 3 Nov 96 07:37:08 IST Received: by tasu41.nsc.com (4.1/SMI-4.1) id AA02737; Sun, 3 Nov 96 07:37:07 IST Date: Sun, 3 Nov 96 07:37:07 IST From: cyblta@taux01.nsc.com (Yaron Blecher) Message-Id: <9611030537.AA02737@tasu41.nsc.com> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From owner-ibis Sun Nov 3 07:32:16 1996 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA01133 for ; Sun, 3 Nov 1996 07:32:15 -0800 (PST) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id IAA03984 for ; Sun, 3 Nov 1996 08:21:24 -0700 Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma847034483.003980; Sun Nov 3 08:21:23 1996 Received: (from cpk@localhost) by hot (8.6.8/8.6.8) id KAA03436 for ibis@vhdl.org; Sun, 3 Nov 1996 10:21:22 -0500 Date: Sun, 3 Nov 1996 10:21:22 -0500 From: "C. Kumar" Message-Id: <199611031521.KAA03436@hot> To: ibis@vhdl.org Subject: Re: IBIS BIRD35.2 MULTI-STAGED OUTPUTS X-Sun-Charset: US-ASCII After some reflection I have the following problems with this bird. 1. Why is it necessary? vt tables taken for different load conditions should give you sufficient insight into the multi stage behavior. And if the data covers the load range, knowing what stage does what is purely academic. 2. By introducing this now we are introducing pseudo (and quite likely ill defined) structural model and moving away from behavioral formulation. 3. Without explicit rise and fall time information, it is easy to introduce inconsistent multistage models with switching discontinuity. To assure continuity the last stage in the rising transition should be first stage while falling and vice versa. - kumar From owner-ibis Mon Nov 4 07:45:29 1996 Received: from hq15.pcmail.ingr.com (hq15.pcmail.ingr.com [129.135.251.243]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA27450 for ; Mon, 4 Nov 1996 07:45:28 -0800 (PST) Received: by hq15.pcmail.ingr.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57) id <01BBCA33.53FAAA60@hq15.pcmail.ingr.com>; Mon, 4 Nov 1996 09:34:08 -0600 Message-ID: From: "Boeckmann, Ed (Edward F)" To: "'ibis@vhdl.org'" Subject: RE:Rising Waveform Loading Effects Date: Mon, 4 Nov 1996 09:33:44 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57 Encoding: 36 TEXT Hello to all, We have had many interesting and informative responses to the subject. I would like to add a comment that I think IBIS is an important and useful modeling technique. We should strive to make it as accurate and useful as possible and especially it should be as simulator independent as possible. In this regard, is there some standard test IBIS model that would produce verified standard responses (Golden Waveforms?) under several different standard conditions if the simulator is working correctly? Best Regards, Eduard Boeckmann Intergraph Corp. Huntsville AL 35894 (205)-730-6219 efboeckm@ingr.com From owner-ibis Mon Nov 4 08:25:41 1996 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA27866 for ; Mon, 4 Nov 1996 08:25:40 -0800 (PST) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA25551; Mon, 4 Nov 1996 09:14:35 -0700 Received: from hot.cadence.com(158.140.103.49) by mailgate.cadence.com via smap (V1.0mjr) id sma847124060.025479; Mon Nov 4 09:14:21 1996 Received: (from cpk@localhost) by hot (8.6.8/8.6.8) id LAA27428; Mon, 4 Nov 1996 11:14:18 -0500 Date: Mon, 4 Nov 1996 11:14:18 -0500 From: "C. Kumar" Message-Id: <199611041614.LAA27428@hot> To: ibis@vhdl.org, efboeckm@ingr.com Subject: RE:Rising Waveform Loading Effects X-Sun-Charset: US-ASCII The v-t curves themselves provide such golden data. But unfortunately it is only one locus. > From owner-ibis@vhdl.vhdl.org Mon Nov 4 10:57 EST 1996 > Received-Date: Mon, 4 Nov 1996 10:57:04 -0500 > From: "Boeckmann, Ed (Edward F)" > To: "'ibis@vhdl.org'" > Subject: RE:Rising Waveform Loading Effects > X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.57 > Encoding: 36 TEXT > Content-Type: text > Content-Length: 640 > X-Lines: 36 > > Hello to all, > > We have had many interesting and informative responses to the subject. > > I would like to add a comment that I think IBIS is an important and > useful modeling technique. > > We should strive to make it as accurate and useful as possible and > especially it should be as simulator independent as possible. In this > regard, is there some standard test IBIS model that would produce > verified standard responses (Golden Waveforms?) under several different > standard conditions if the simulator is working correctly? > > Best Regards, > > Eduard Boeckmann > Intergraph Corp. > Huntsville AL 35894 > (205)-730-6219 > efboeckm@ingr.com > > > > > > > > > > > > > > > > > From owner-ibis Mon Nov 4 09:48:16 1996 Received: from netcomsv.netcom.com (uucp4.netcom.com [163.179.3.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA28651 for ; Mon, 4 Nov 1996 09:48:15 -0800 (PST) Received: from caesars.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id JAA21154; Mon, 4 Nov 1996 09:24:58 -0800 Received: from optest.opti.com by opti.com (4.1/SMI-4.1) id AA07614; Mon, 4 Nov 96 10:23:25 PPE Received: from unixgate.opti.com by optest.opti.com (4.1/SMI-4.1) id AA07458; Mon, 4 Nov 96 10:23:26 PPE Received: from ccMail by unixgate.opti.com id AA847128450 Mon, 04 Nov 96 09:27:30 pst Date: Mon, 04 Nov 96 09:27:30 pst From: "lawrence" Message-Id: <9610048471.AA847128450@unixgate.opti.com> To: ibis@vhdl.org Subject: unsubscribe unsubscribe From owner-ibis Mon Nov 4 12:25:27 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA29935 for ; Mon, 4 Nov 1996 12:25:26 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 4 Nov 96 12:14 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 4 Nov 96 12:14 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 4 Nov 96 12:16 PST Message-Id: Date: Mon, 4 Nov 96 12:16 PST From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.orgA, ibis@vhdl.org Subject: IBIS REFLECTOR USAGE REQUEST Hello: This is a reminder that if you want to SUBSCRIBE or UNSUBSCRIBE, please send the message to ibis-request@vhdl.org If you need further INFORMATION regarding IBIS or want personalized attention to a question, please send the message to ibis-info@vhdl.org There have been much interesting discussion on the TWO IBIS reflectors lately. Most of you are members of both mailing lists, so this is not a major issue. However, I would prefer that OFFICIAL BUSINESS AND TECHNICAL messages be sent to ibis@vhdl.org This includes regular IBIS business including Meetings, Agendas, BIRDs and Issues discussions, Face to Face Meetings, IBIS Utility checking, etc. This can also include CLARIFICATION issues that would normally lead to a change in the standard or to a cookbook clarification. I would also prefer that general USER question, answer, and discussion messages be sent to ibis-users@vhdl.org This includes questions about interpretation of the standard, questions about s2ibis and s2ibis2 setups, modeling questions, Spice and IBIS comparisons and positioning, model library updates, etc. Sometimes a message could go to both reflectors (the mailer is supposed to trap the duplicate addresses.) If in doubt, then use ibis@vhdl.org. Thank you Bob Ross IBIS Open Forum Chair. Interconnectix From owner-ibis Mon Nov 4 12:39:59 1996 Received: from spsgate.sps.mot.com (spsgate.sps.mot.com [192.70.231.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA00171 for ; Mon, 4 Nov 1996 12:39:58 -0800 (PST) Received: from mogate.sps.mot.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA21001 for ibis@vhdl.org; Mon, 4 Nov 96 12:45:46 MST Received: from emailsps (emailsps.sps.mot.com) by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA08113 for ibis@vhdl.org; Mon, 4 Nov 96 12:45:42 MST Message-Id: Date: 4 Nov 1996 13:43:46 U From: "Mike Peters-R14378" Subject: unsubscribe To: ibis@vhdl.org X-Mailer: Mail*Link SMTP-QM 3.0.2 GM Mail*Link(r) SMTP unsubscribe unsubscribe From owner-ibis Mon Nov 4 16:39:25 1996 Received: from aba.nsrc.nus.sg (aba.nsrc.nus.sg [137.132.15.2]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA02435 for ; Mon, 4 Nov 1996 16:39:22 -0800 (PST) Received: (from songjj@localhost) by aba.nsrc.nus.sg (8.8.2/8.8.2) id IAA06827 for ibis@vhdl.org; Tue, 5 Nov 1996 08:28:29 +0800 (SGT) From: Song JJ Message-Id: <199611050028.IAA06827@aba.nsrc.nus.sg> Subject: unsubscribe To: ibis@vhdl.org Date: Tue, 5 Nov 1996 08:28:28 +0800 (SGT) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit unsubscribe Thanks. From owner-ibis Tue Nov 5 09:15:26 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA25532 for ; Tue, 5 Nov 1996 09:15:25 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.7.6/8.7.3) with ESMTP id JAA07800 for ; Tue, 5 Nov 1996 09:04:31 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id JAA20086; Tue, 5 Nov 1996 09:04:28 -0800 (PST) Message-Id: <199611051704.JAA20086@ichips.intel.com> To: ibis@vhdl.org Subject: Packaging proposal -- work in process Date: Tue, 05 Nov 1996 09:04:31 -0800 From: Stephen Peters Hello Fellow IBISains: Over the past couple of weeks the packaging subcommittee has been working on a way to describe connectors and PCB board traces using a simple, non-coupled transmission line description. Our proposal is based on Bird36 (which itself is an extension of the format found in the IC packaging description Bird 37.3), and while it is not complete (it does not yet comprehend coupling) we are at the point where we would like feedback from the wider IBIS community. Please look over the attached proposal -- the packaging subcommittee would like to discuss it at the upcomming teleconference. Again, I'd like to emphasis that, while the propsal is in the form of a bird, this is not intended as the final proposal. The packaging committee feels that any proposal should include a method for describing connector coupling before acceptance as a Bird. Best Regards, Stephen Peters Intel Corp. ============================================================================= Buffer Issue Resolution Document (BIRD) BIRD ID#: working proposal ISSUE TITLE: Electric Descriptions of Boards and Connectors REQUESTER: Stephen Peters, Hank Herrmann DATE SUBMITTED: June 23, 1996, 11/4/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending **************************************************************************** **************************************************************************** STATEMENT OF THE ISSUE: There is a need to describe SIMM modules and related type components that consist of one or more ICs mounted on a PCB board that connects them to a system thru a set of pins. The following BIRD proposes a new type of file called .eid (Electrical Interconnect Description) that addresses this need. A .eid file can also be used to describe connectors and sockets. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following text is placed in the specification after the .pkg file description and before the [End] keyword description. ==================== ELECTRICAL INTERCONNECT DESCRIPTION ==================== An Interconnect Level Component is defined as a part that connects one or more IC packages to another part or board thru a set of user visible pins. For example, a SIMM module is an interconnect level component in that it connects several DRAM packages to a PCB thru an edge connector. To provide a simple electrical description of the connection between the pins of the interconnect level component and the IC packages, an electrical interconnect description file (a .eid file) is defined. The .eid file is also used to describe the electrical characteristics of connectors and sockets. What is, and is not, included in an Electrical Interconnect Description is defined by its boundaries. For the definition of the boundaries, see the Description section under the [Path Description] Keyword. Usage Rules: A .eid file is intended to be a stand alone file, not associated with any .ibs file. Interconnect level component descriptions are stored in a file whose name looks like .eid, where must conform to the naming rules given in the general syntax section of this specification. The .eid extension is mandatory. Contents: A .eid file is structured similar to a standard IBIS file. It must contain the following keywords, as defined in the IBIS specification: [IBIS Ver], [File name], [File rev], and [End]. It may also contain the following optional keywords: [Comment char], [Date], [Source], [Notes], [Disclaimer] and [Copyright]. The actual interconnect level component description is contained between the keywords [Begin Electrical Description] and [End Electrical Description], and includes the keywords listed below. [Begin Electrical Description] [Manufacturer] [Application Info] [Number of Pins] note 1 [Number of Pairs] note 1 [Pin List] note 2 [Pair List] note 2 [Path Description] [Coupled Path Model] note 3 [Reference Designator Map] [Model Data] note 3 [Resistance Matrix] note 3 [Inductance Matrix] note 3 [Capacitance Matrix] note 3 [Bandwidth] note 3 [Row] note 3 [End Model Data] note 3 [End Electrical Description] (Note 1) Either the [Number of Pins] or [Number of Pairs] keyword must be used but not both. (Note 2) Either the [Pin List] or [Pair List] keyword must be used but not both. [Pin List] is used only when the [Number of Pins] keyword has been used and [Pair List] is used only when the [Number of Pairs] keyword has been used. (Note 3) The indicated keywords are reserved for future use in coupled models. More than one [Begin Electrical Description]/[End Electrical Description] keyword pair is allowed in a .eid file. |============================================================================= | Keyword: [Begin Electrical Description] | Required: Yes |Description: Marks the beginning of an Electrical Interconnect description. |Usage Rules: The keyword is followed by the name of the interconnect level | component. If the .eid file contains more than one [Begin | Electrical Description] keyword, then each name must be unique. | The length of the component name must not exceed 40 characters | in length, and blank characters are allowed. For every | [Begin Electrical Description] keyword there must be a | matching [End Electrical Description] keyword. |----------------------------------------------------------------------------- [Begin Electrical Description] 16Meg X 8 Simm Module | |============================================================================= | Keyword: [Manufacturer] | Required: Yes |Description: Declares the manufacturer of the part(s) that use this .eid | file. |Usage Rules: Following the keyword is the manufacturers name. It must not | exceed 40 characters, and can include blank characters. Each | manufacturer must use a consistent name in all .eid files. |---------------------------------------------------------------------------- [Manufacturer] Quality SIMM Corp. | |============================================================================= | Keyword: [Application Info] | Required: Yes, if any subparameters need to be specified. |Description: This keyword provides general model application information. |Sub-params: Min_edge_time, Cpad1, Cpad2 |Usage Rules: This keyword is followed by one to three listed subparameters. | All three subparameters are optional. Subparameters are | followed by an equals sign (=); whitespace around the equals | sign is optional. | | The Min_edge_time subparameter is used to specify the minimum | edge time of a signal for which an interconnect model is | considered accurate. This value is based on the smallest | physical feature that is modeled in the electrical description. | Note that a simulator may choose to produce a warning message | if a signal with a faster edge enters the model. Simulators | should also use this subparameter in determining how to | model a section with non-zero length. | | The Min_edge_time subparameter is a single numeric argument | specifying the 20% to 80% edge time of the fastest pulse the | model will accurately pass. This value will be the minimum | value where the measured signal line impedance is within 10% | of the simulated impedance. The point at which impedance | deviations exceed 10% is where the model needs more structural | detail. This is not the same as dividing a long section into | stages as is required when using lumped values in SPICE. Long | uniform sections should be specified as distributed sections. | (Len <> 0 under [Path Description]) Measured line impedance is | the impedance plot of the part's connection path taken by a | Time Domain Reflectometer (TDR) with the edge time indicated by | the Min_edge_time subparameter. The simulated impedance is the | ratio of the dynamic model input voltage to input current with | the same source waveform and the same configuration as the test. | The usual configuration is to ground all appropriate lines and | use source and load impedances of 50 ohms. | | The Cpad1 subparameter defines the default pad capacitances | for all circuit board edge pads or all pins on the first side | of a connector model. Cpad2 is the default pad capacitance on | the second side of a connector. The first and second sides | refer to the order as used in the pin-pairs of the [Pin List] | keyword. If either is omitted, the default value is zero pF. | Do not omit Cpad1 (set it equal to zero) if Cpad2 is needed. | In all cases the simulator may override the listed or default | value with values extracted from the actual pad dimensions | provided in a physical board description. | |--------------------------------------------------------------------------- | | AN EXAMPLE CONNECTOR DESCRIPTION | Min_edge_time = 1.5n Cpad1 = 0.5p Cpad2 = 1.0p | | AN EXAMPLE PATH ON A SIMM MODULE | Min_edge_time = 1.0n Cpad1 = 1.5p | | ANOTHER EXAMPLE PATH ON A SIMM MODULE | Min_edge_time = 1.5n | |============================================================================= | Keyword: [Number of Pins] | Required: Yes, if the .eid file describes a circuit board, an unmated | connector or similar structure. This keyword must not be | used if the [Number of Pairs] keyword is used. |Description: Tells the parser the number of pins to expect. Pins are any | externally accessible electrical connection to the part. |Usage Rules: The field must be a positive decimal integer. | Note: The simulator must not limit the Number of Pins to any | value less than 1,000. |---------------------------------------------------------------------------- [Number of Pins] 128 | |============================================================================ | Keyword: [Number of Pairs] | Required: Yes, if the .eid file describes a mated connector, socket or | other similar interconnection structure. This keyword must not | be used if the [Number of Pins] keyword is used. |Description: Tells the parser the number of pairs to expect. Pairs are | simply the number of conductive paths in an interconnection. | Pairs are necessary since each path has at least two external | pins; one on each side of the interconnection device. |Usage Rules: The field must be a positive decimal integer. | Note: The simulator must not limit the Number of pin-pairs to | any value less than 1,000. |----------------------------------------------------------------------------- [Number of Pairs] 240 | |============================================================================= | Keyword: [Pin List] | Required: Yes, if the [Number of Pins] keyword has been used. | Either the [Pin List] or [Pair List] keyword must be used but | not both. [Pin List] is used only when the [Number of Pins] | keyword has been used and [Pair List] is used only when the | [Number of Pairs] keyword has been used. |Description: Tells the parser the set of names that are used for the part's | external pins and also defines pin ordering. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest". |Usage Rules: Following the [Pin List] keyword, the names for the pins are | listed. There must be as many entries listed as there are pins | given by the preceding [Number of Pins] keyword. Pin names must | be the alphanumeric external pin names of the part. The pin | names cannot exceed eight characters in length. |----------------------------------------------------------------------------- | | A SIMM CIRCUIT BOARD OR UNMATED CONNECTOR EXAMPLE | [Pin List] A1 A2 A3 | . | . A22 B1 | . | . |etc. | |============================================================================= | Keyword: [Pair List] | Required: Yes, if the [Number of Pairs] keyword has been used. | Either the [Pair List] or [Pin List] keyword must be used but | not both. [Pair List] is used only when the [Number of Pairs] | keyword has been used and [Pin List] is used only when the | [Number of Pins] keyword has been used. |Description: Tells the parser the set of names that are used for the part's | external pins, matches the names that are at opposite sides of | each conductive path and also defines pin ordering. The first | pin name given is the "lowest" pin, and the last pin name given | is the "highest". Pin names are assigned in column order. That | is, first all pin names on one side are assigned in the order | given, then the other side is assigned in the order given. |Usage Rules: Following the [Pair List] keyword, the paired pin names for the | pairs are listed. There must be as many pair entries listed as | there are pairs given by the preceding [Number of Pairs] keyword. | Pin names must be alphanumeric. They provide the internal names | that are used in the [Path Description] keyword. They are | matched to the external pin names of the part. The pin names | cannot exceed eight characters in length. The special pin name, | NC, is reserved to represent no-connection if a pin name is not | used on one side or the other of the interconnection. |----------------------------------------------------------------------------- | | A MATED CONNECTOR EXAMPLE | [Pair List] RA1 PA1 RA2 PA2 RA3 PA3 | . . | . . RA22 PA22 RB1 PB1 | . . | . . |etc. etc. | |============================================================================ | Keyword: [Path Description] | Required: Yes, unless the [Coupled Path Model] Keyword is used. |Description: This keyword allows the user to describe the connection | between the user accessible pins of a part and the pins of | the ICs mounted on that part. If describing a connector, | this keyword is used to describe the path from one pin of a | connector pin-pair to the other pin of the same pair. The | Fork and Endfork subparameters allow branching to other | pin-pair paths. Those connections can also be made through | other components by using the Node subparameter. NOTE that | this means that pin names can appear more than once. | | BOUNDARIES OF MODEL PATHS: | In any system, each part interfaces with another part at some | boundary. Every part model must contain the components | necessary to represent the behavior of the part being modeled | within its boundaries. The boundary definition depends upon | the parts being represented by the model. | | For CARD EDGE CONNECTIONS such as a SIMM or a PC Daughter | Card plugged into a SIMM Socket or Edge Connector, the | boundary should be at the end of the board card edge pads as | they emerge from the connector. The pads need to be included | in the connector model. | | For any THROUGH-HOLE MOUNTED PART, the boundary should be at | the surface of the board on which the part is mounted. This | also applies to an IC plugged into a socket. The portion of | the IC pins that project into the socket must be included in | the socket model. | | SURFACE MOUNTED PART models end at the outboard end of their | recommended surface mount pads. | | CONNECTOR models must be mated connections unless the | connector is commonly used in an unmated condition such as in | a digital bus where all slots are not filled. Unmated | connector models would have only one boundary; the board- | connector boundary. | | Combination models can be made when two parts are always used | together, such as with a Pentium-PRO and its socket. In that | case, the socket-to-board boundary is the only one used. | | Sub-params: Len, L, R, C, Fork, Endfork, Pin, Node |Usage Rules: Each individual connection path (user pin to node(s) | description or connector pin-to-pin description) begins with the | [Path Description] keyword and a path name, followed by the | subparameters used to describe the path topology and the | electrical characteristics of each section of the path. The | path name must not exceed 40 characters, blanks are not allowed, | and each occurrence of the [Path Description] keyword must be | followed by a unique path name. The individual subparameters | are broken up into those that describe a section's electrical | properties, and those that describe the topology of a path. | | SECTION DESCRIPTION SUBPARAMETERS: | The Len, L, R, and C subparameters specify the length, the | series inductance and resistance and the capacitance to ground | of each section in a path description. | Len The physical length of a section. Lengths are given | in terms of arbitrary 'units'. Any non-zero length | requires that the parameters that follow must be | treated as distributed elements by the simulator. | L The series inductance of a section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0nH and the length of the | section is 2 'units', the inductance would be listed | as L = 1.5nH (i.e. 3.0 / 2). | C The capacitance to ground of a section, in terms of | capacitance per unit length. | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. | | TOPOLOGY DESCRIPTION SUBPARAMETERS: | The Fork and Endfork subparameters denote branches from the | main pin-to-node or pin-to-pin connection path. The Node | subparameter is used to reference an external component | description file. The Pin subparameter is used to indicate | the point at which a path connects to a user visible pin. | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main connection path. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a | branch. For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no arguments. | Node pin.reference_designator | This subparameter is used when the connection path | connects to a pin of another, externally defined part. | The arguments of the Node subparameter indicate the pin | and reference designator of the external component. The | pin and reference designator portions of the argument are | separated by a period ("."). The reference designator is | mapped to an external component description (another .eid | file or a .ibs file) by the [Reference Designator Map] | Keyword. | Pin This subparameter is used to mark the point at which | a path description connects to a user accessible pin. | Every path description must contain at least one | occurrence of the Pin subparameter. It may also contain | the reserved word NC. The value of the Pin subparameter | must be one of the pin names listed in the [Pin List] or | [Pair List] section. | | Using The Subparameters to Describe Paths: | A section description begins with the Len subparameter and | ends with the backslash (/) character. The value of the Len, L, | R and C subparameters and the subparameter itself are separated | by an equals sign (=); whitespace around the equals sign is | optional. The Fork, Endfork, Node and Pin subparameters are | placed between section descriptions (i.e. between the concluding | backslash of one section and the 'Len' parameters that starts | another). The arguments of the Pin and Node subparameter are | separated by white space; no equal sign nor backslash (/) | character is used. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. However, as noted below, if a non- | zero length is specified, that section MUST be treated as | distributed elements. | | Legal Subparameter Combinations for Section Descriptions: | | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the Len subparameter | is non-zero, then the L/R/C subparameters represent distributed | elements. | | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a node, | section, another pin or the reserved word, NC. | | C) All paths and subpaths (a path between Fork and Endfork) | end in a Pin, a Node or NC. | |--------------------------------------------------------------------------- | | A TYPICAL CONNECTOR DESCRIPTION EXAMPLE | [Path Description] J1-P1 Pin J1 Len = 2.0 L=8.35n C=3.34p R=0.01 / Len = 0.5 L=1.0n C=2.7p / Pin P1 | | AN EXAMPLE PATH FOR A SIMM MODULE | [Path Description] CAS_2 Pin J25 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node 15.u21 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node 15.u22 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node 15.u23 | | A DESCRIPTION USING THE FORK AND ENDFORK SUBPARAMETERS | [Path Description] PassThru1 Pin B5 Len = 0 L=2.0n / Len = 2.1 L=6.0n C=2.0p / Fork Len = 1.0 L= 1.0 C= 2p Node 15.u23 Endfork Len = 1.0 l = 6.0n C=2.0p / Pin A5 | | A MORE COMPLEX CONNECTOR or BOARD DESCRIPTION EXAMPLE | | A metal part or trace with 2 connections on one side and one | connection on the other side. | +--------------+ | | | | RG1 +====+\ | NC | | L1 | | | R1 | | RG2 +====+/____L2__R2___+====+ PG2 | | | | +--------------+ [Path Description] RG1-NC Pin RG1 Fork Len = 1.0 L=0.3n R=0.01 / Pin RG2 Endfork Pin NC | [Path Description] RG2-PG2 Pin RG2 Len = 1.0 L=1.3n R=0.04 / Pin PG2 | |============================================================================= | Keyword: [Coupled Path Model] | Required: Not at the present time. This keyword is reserved for future use. |Description: This keyword will introduce a coupled model path description in | some format yet to be determined. | Sub-params: TBD |Usage Rules: TBD | |----------------------------------------------------------------------------- | [Coupled Path Model] Example TBD | |============================================================================= | Keyword: [Reference Designator Map] | Required: Yes, if any of the path descriptions use the Node subparameter. |Description: Indicates the linkage between a reference designator and the | external part it represents. |Usage Rules: The [Reference Designator Map] keyword must be followed by a | list of all of the reference designators defined in the Node | subparameter under the [Path Description] keyword. Each | reference designator is followed by the Name of the part to which | it is linked and the terms are separated by whitespace. The part | Name may be another .eid or .ibs model. A referenced .eid model | may be internal to the calling .eid file or it may be an external | file with an appropriately given pathname. |----------------------------------------------------------------------------- [Reference Designator Map] | | EXTERNAL PART REFERENCES | u23 80286.ibs u24 SIMM.eid u25 C:\LIBS\LS244.ibs | | AN INTERNALLY DEFINED .eid MODEL OF A 10K RESISTOR | u26 R10K | |=========================================================================== | Keyword: [Model Data], [End Model Data], [Resistance Matrix], | [Inductance Matrix], [Capacitance Matrix], [Bandwidth], [Row] | Required: Not at the present time. These keywords are reserved for future | use for coupled models. |=========================================================================== | Keyword: [End Electrical Description] | Required: Yes |Description: Marks the end of an Electrical Interconnect Description. |Usage Rules: This keyword must come at the end of each complete electrical | interconnect model description. | | Optionally, a comment may be added after the [End Electrical | Description] keyword to clarify which interconnect model has | ended. |--------------------------------------------------------------------------- [End Electrical Description] | End: 16Meg X 8 Simm Module | **************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: From owner-ibis Tue Nov 5 16:36:18 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA29163; Tue, 5 Nov 1996 16:36:17 -0800 (PST) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA03495; Tue, 5 Nov 96 16:25:13 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA01931; Tue, 5 Nov 96 16:25:12 PST Date: Tue, 5 Nov 96 16:25:12 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9611060025.AA01931@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Serious s2ibis problem? Cc: jem@ricky.actel.com, whauff@ricky.actel.com, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu Hello IBIS folk: We've been trying to figure out why s2ibis produces a Pull-down (and Pull-up) curve that is VERY different from our self-produced tables (from SPICE), in particular at voltages from Vcc to 2*Vcc. This led me to the FAQ under the /man directory of S2IBIS. Here, I found: QUESTION (6): "How does s2ibis generate tables?" ANSWER: s2ibis uses the following scheme for determining what tables need to be generated for a particular pin: 0) For POWER, GND, and NC ... --snip-- 3) For each I/O or 3-state pin... --snip again-- -> pulldown(-5->0):subtract the associated ground clamp table from the pulldown table -> pulldown(0->Vcc): just use the pull-down table as simulated -> pulldown(Vcc->2*Vcc):extrapolate using the point at Vcc and the point five points before Vcc in the pulldown table A similar explanation is provided for pulldown table generation. My questions are: WHY DO THEY DO OPT FOR EXTRAPOLATION WHEN THEY HAVE ALL THE DATA NESSESSARY IN THE SPICE OUTPUT FILES? WHY ISN'T THE TRI-STATE DATA SUBTRACTED FROM THE ENTIRE VOLTAGE RANGE? After reviewing all of the files that are created (and left) by s2ibis, I found that it creates V/I tables (***from -Vcc to 2*Vcc***) for an I/O in: 1)Tri-state (un-enabled) conditions, 2)Pull-up conditions, and 3)Pull-down conditions. In searching through all of the IBIS documentation I could find, the best explanation for how to produce proper Pull-down and Pull-up curves (for either SPICE sim data or real data) was in the V2.1 Spec., under "Other Notes:" of the [Pulldown], [Pullup], [GND Clamp], [Power Clamp] Keyword section: ... The clamp curves of an input or I/O buffer can be measured directly with a curve tracer, with the I/O buffer 3-stated. However, sweeping enabled buffers results in curves that are the sum of the clamping curves and the output structures. Based on the assumption outlined above (which makes sense), the pull-up and the pull-down curves of an IBIS model must represent the DIFFERENCE of the 3-stated and the enabled buffers curves. (Note... ...) This requirement enables the simulator to sum the curves, without the danger of double counting, and arrive at an accurate model in both the 3-stated and enabled conditions. ... This explanation seems good for producing V1.1 tables as well (and perhaps just didn't make it into documentation until the V2.1 Spec). So: Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data from the entire range of both pull-down and pull-up data to derive the corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it takes EXTRA steps to produce seemingly innacurate tables... Is this a serious mistake with s2ibis, or are am I missunderstanding something. Thanks ahead for all feedback. Regards, -Scott Schlachter Design Engineering Actel Corporation Sunnyvale, CA From owner-ibis Tue Nov 5 16:41:49 1996 Received: from netcomsv.netcom.com (uucp8.netcom.com [163.179.3.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA29189 for ; Tue, 5 Nov 1996 16:41:48 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id QAA11049; Tue, 5 Nov 1996 16:27:27 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA23387; Tue, 5 Nov 96 11:07:23 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA24859; Tue, 5 Nov 1996 11:16:06 +0800 Date: Tue, 5 Nov 1996 11:16:06 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9611051916.AA24859@contec13.contec.COM> To: ibis@vhdl.org Subject: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII I missed the earlier discussion on BIRD 35.2 before it got hatched. Could some one please post the discussion on why the waveform table was considered inadequate? Thanks for the help. Dileep ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Tue Nov 5 17:59:59 1996 Received: from via.com.tw ([203.70.217.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA00194 for ; Tue, 5 Nov 1996 17:54:06 -0800 (PST) Received: from sun13.via.com.tw ([203.70.217.103]) by via.com.tw (4.1/SMI-4.1) id AA26112; Wed, 6 Nov 96 09:42:38 CST Message-Id: <327FEEDC.388D@via.com.tw> Date: Wed, 06 Nov 1996 09:50:20 +0800 From: benson Reply-To: benson@via.com.tw Organization: VIA X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: ibis@vhdl.org Subject: [Fwd: unsubscribe] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From owner-ibis Wed Nov 6 09:29:09 1996 Received: from netcomsv.netcom.com (uucp6.netcom.com [163.179.3.6]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA26286 for ; Wed, 6 Nov 1996 09:29:08 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id JAA10281; Wed, 6 Nov 1996 09:07:17 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA08095; Wed, 6 Nov 96 08:59:00 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA25648; Wed, 6 Nov 1996 09:07:43 +0800 Date: Wed, 6 Nov 1996 09:07:43 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9611061707.AA25648@contec13.contec.COM> To: ibis@vhdl.org Subject: Questions about BIRD39 - SPECIFICATION ENHANCEMENT Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII I have some questions about BIRD39 - SPECIFICATION ENHANCEMENT. 1)I do not understand the intended use of the Vinh+,Vinh-, Vinl+ and Vinl- subparameters. Can some one offer more explanation? 2)My understanding was that IBIS is used for analyzing signal integrity effects for rising and falling EDGES. There is no notion of a pulse or pulse width anywhere in the specification. Since there is really no output vs. input information, one can arbitrarily assume the times at which the output transitions can start and hence I do not know how the Pulse_high, Pulse_low and Pulse_time subparameters are to be used. Thank you for your help. Dileep ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Wed Nov 6 12:01:51 1996 Received: from netcomsv.netcom.com (uucp6.netcom.com [163.179.3.6]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA27850 for ; Wed, 6 Nov 1996 12:01:50 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id LAA17608; Wed, 6 Nov 1996 11:47:03 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA08516; Wed, 6 Nov 96 10:23:45 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA25712; Wed, 6 Nov 1996 10:32:26 +0800 Date: Wed, 6 Nov 1996 10:32:26 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9611061832.AA25712@contec13.contec.COM> To: ibis@vhdl.org Subject: Comments and questions about Electrical Descriptions of Boards and Connectors. Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII I have some comments and questions about the BIRD regarding the Electrical Descriptions of Boards and Connectors. 1) | Note: The simulator must not limit the Number of Pins to any | value less than 1,000. I do not understand why any number should be specified. If the maximum allowable limit is 1,000 then many high pin count packages cannot be modeled. 2) |Description: Tells the parser the set of names that are used for the part's | external pins and also defines pin ordering. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest". I do not understand the significance of this. Why is it necessary to define pin ordering? The parser needs only the information about pin names. 3) | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. I think in addition to R, specification of G should be allowed. Since this is an optional specification, for cases where the dielectric loss is not significant, it need not be specified. In fact I would say that we should go even one step further and allow an optional sepcification of high frequency R in addition to the DC value. 4) | A section description begins with the Len subparameter and | ends with the backslash (/) character. The value of the Len, L, The backslash (/) character mentioned above is actually a forward slash character. The backslash is \. 5) | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the Len subparameter | is non-zero, then the L/R/C subparameters represent distributed | elements. I think the specification should say that if non-zero Len is specified, then BOTH L AND C MUST be specified. The R (and G) can be optional. By definition, the physical description of the distributed transmission line has BOTH L and C. 6) | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a node, | section, another pin or the reserved word, NC. | | C) All paths and subpaths (a path between Fork and Endfork) | end in a Pin, a Node or NC. The last sentence in B) and the sentence in C) seem contradictory. B) allows the path to be terminated in a section also. The only possible subparameters under the path description are Len, Pin, Node and Fork/EndFork. I do not see any need to put restrictions on how the path should end. Also, the need and usage of NC is not clear. Off hand, it seems that we can do without it. Is it allowed to have another Fork statement inside a Fork statement before the Endfork? 7) | Node pin.reference_designator This is a minor point, but all the pcb design programs I know, use the convention reference_designator.pin. Most people are used to seeing something like U3.17 as opposed to 17.U3. Some general comments: There are cases where a trace forks into two and then the two traces join again to form a single trace. How does one describe this? It is stated that C is the capacitance to "ground". This assumes that there is only ONE ground for ALL the sections of this board as well as all the other boards connected to this board by virtue of .eid models specified in the Reference Designator Map. This precludes the use of this model for doing ground bounce analysis. Since this is supposed to address the full board description, I just wanted to mention that there is a tendency (particularly in SIMMs and MCMs) to add other components on the boards, in addition to the ICs and connectors. Embedded resistors is an example that comes to mind. Is it possible to include these components in this description? Dileep ------------------------------------------------------------ Dileep Divekar Applied Simulation Technology, Inc. 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-0967 x 100 Fax - (408)-434-1003 Email - dileep@apsimtech.com ------------------------------------------------------------ From owner-ibis Wed Nov 6 14:18:08 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA29261 for ; Wed, 6 Nov 1996 14:18:06 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 6 Nov 96 14:07 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Nov 96 14:07 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Nov 96 14:09 PST Message-Id: Date: Wed, 6 Nov 96 14:09 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Re: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table Dileep, Kumar, Chris, Arpad and IBIS Committee: I have reviewed the recent comments concerning BIRD35.2. You are all perceptive and correct in noting that BIRD35.2 is a departure from the existing external-based-measurement IBIS paradigm. You are correct in questioning the need when IBIS already supports Waveform-based models matching. Also you are correct in noting that there might be some simulator algorithm dependency on how the model might be processed by different vendors. All of these items need to be weighed with respect to the benefit and intent of providing this capability. I can give some historical perspective and also illustrate where such a capablility is (in my opinion) technically needed. At an IBIS face-to-face Summit Meeting in 1993, Jon Powell introduced the notion of multi-staged switching as part of the discussion on how to deal with V/T characteristics. One or two other approaches were also presented. Over time the committee opted to implement the [Rising Waveform] and [Falling Waveform] approach. It provided the broadest coverage and had other advantages. It is currently being used as a reliable way to add model detail. A number of people also felt that [Rising Waveform] and [Falling Waveform] capability might adequately cover the multi- staged driver situations to a sufficient level of modeling accuracy. The multi-staged switching physical architecture has been implemented by a number of silicon vendors. There still exist details in the implementations that make the case for including a simulation capability. In the January 1996 IBIS face-to-face Summit Meeting, we put this capability on the list as one of the priority needs for IBIS Version 3.0. It was not defined then. However, through a number of proposals evolving into the current BIRD35.2, there is now is a [Driver Schedule] proposal. Vendor algorithms to process waveforms are generally good and reliable, in my opinion. However, there are details which are different and which hit a the core or why this added functionality might be required. One nature of multi-staged switching is that there might be a kicker pulse during any of the transitions. This implies a dynamic switching in and out of one or more stages. The overall transition can be non-monotonic. The more important aspect is that within some of the silicon architectures, there is a switched in and out impedance change during the transition as a result of switching in and out of, say, an Open_drain stage. From a modeling perspective, an I/V table gets switched in and out. While V/T tables can give a good model of such a transition provided there are no relections back to the driver during the transition, even this model might not produce the best results if reflections occur at the driver during the transitions while the source impedance has changed. In my opinion, the decomposition of a total circuit is a not a clean process unless there is really some very isolated behavior. Whether you can get overall better results remains to be proven. My position is that there is need for at least the hooks so vendors can put in the extra work (and perhaps iterative) construction to produce an overall better approximation of actual behavior through a driver scheduling method. I would expect this method to be used with models that have [Rising Waveform] and [Falling Waveform] tables to better control the individual shapes. This would not be a requirement, but a practical way of implementing the scheduling so that the results are more predictable between vendors. I look forward to more discussion on BIRD35.2 this Friday. Bob Ross Interconnectix > Date: Tue, 5 Nov 1996 11:16:06 +0800 > From: dileep@contec.Apsimtech.COM (Dileep Divekar) > Message-Id: <9611051916.AA24859@contec13.contec.COM> > To: ibis@vhdl.org > Subject: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table > Cc: dileep@contec.Apsimtech.COM > X-Sun-Charset: US-ASCII > Status: RO > I missed the earlier discussion on BIRD 35.2 before it got hatched. > Could some one please post the discussion on why the waveform table > was considered inadequate? Thanks for the help. > Dileep > ------------------------------------------------------------ > Dileep Divekar > Applied Simulation Technology, Inc. > 2188 Bering Drive > San Jose, CA 95131 > Phone - (408)-434-0967 x 100 > Fax - (408)-434-1003 > Email - dileep@apsimtech.com > ------------------------------------------------------------ From owner-ibis Wed Nov 6 15:36:31 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA29882 for ; Wed, 6 Nov 1996 15:36:30 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 6 Nov 96 15:25 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Nov 96 15:25 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Nov 96 15:27 PST Message-Id: Date: Wed, 6 Nov 96 15:27 PST From: bob@icx.com ( Bob Ross) To: dileep@contec.Apsimtech.COM, ibis@vhdl.org Subject: Re: Questions about BIRD39 - SPECIFICATION ENHANCEMENT Dileep: Good questions. (1) One specific example is the 74XXX132 device with Schmitt trigger (hysteresis) input specification. The high and low state threshold points are specified within a tolerance range. In general, ASIC devices with hysteresis inputs could also benefit from this Specification addition. The proposed Specification addition would allow us more precision in allocating timing paths. Currently with only Vinh and Vinl, we have only a very crude way of approximating hysteresis behavior without any real tolerance mechanism. (2) I also would like feedback on the need and appropriateness of this noise rejection inclusion and how it might be used. The specification is designed to allow simulators to optionally set up tests and trap on glitches at the input to test noise immunity. So an input that is at a low state may see a glitch due to timing or cross talk tolerances that cause it to momentarily exceed the Vinl value. As long as the input remains below Pulse_high and also returns to a value below Vinl, within Pulse_time of the first crossing, the input with such a noise immunity specification is considered to have passed. (This is a first order approximation of a more detailed pulse-width versus pulse amplitude characteristic and is intended to help flag possible weaknesses.) The Pulse_low value operates in a similar manner relative to Vinh when the input is in the high state. Bob Ross Interconnectix > Date: Wed, 6 Nov 1996 09:07:43 +0800 > From: dileep@contec.Apsimtech.COM (Dileep Divekar) > Message-Id: <9611061707.AA25648@contec13.contec.COM> > To: ibis@vhdl.org > Subject: Questions about BIRD39 - SPECIFICATION ENHANCEMENT > Cc: dileep@contec.Apsimtech.COM > I have some questions about BIRD39 - SPECIFICATION ENHANCEMENT. > 1)I do not understand the intended use of the Vinh+,Vinh-, > Vinl+ and Vinl- subparameters. Can some one offer more explanation? > 2)My understanding was that IBIS is used for analyzing signal > integrity effects for rising and falling EDGES. There is no notion > of a pulse or pulse width anywhere in the specification. > Since there is really no output vs. input information, one can > arbitrarily assume the times at which the output transitions can > start and hence I do not know how the Pulse_high, Pulse_low and > Pulse_time subparameters are to be used. > Thank you for your help. > Dileep > ------------------------------------------------------------ > Dileep Divekar > Applied Simulation Technology, Inc. > 2188 Bering Drive > San Jose, CA 95131 > Phone - (408)-434-0967 x 100 > Fax - (408)-434-1003 > Email - dileep@apsimtech.com > ------------------------------------------------------------ From owner-ibis Wed Nov 6 16:49:12 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA00589 for ; Wed, 6 Nov 1996 16:49:09 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 6 Nov 96 16:38 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Nov 96 16:38 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 6 Nov 96 16:40 PST Message-Id: Date: Wed, 6 Nov 96 16:40 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS PARSER ENHANCEMENT BUG REPORTS Hello: As part of the ibischk parser enhancement discussions, Chris Rokusek has formally filed the BUG REPORT forms showing the proposed changes. I have concatenated the three BUG REPORTs for background related to the IBIS meeting discussion on this subject this Friday. The reports are also filed on vhdl.org under /pub/ibis/bugs. Bob Ross Interconnectix ****************************************************************************** ********************* IBIS GOLDEN PARSER BUG REPORT FORM ********************* ****************************************************************************** INSTRUCTIONS To report a bug in the IBIS golden parser. Please fill out the top part of the following form and send the complete form to ibischk-bug@vhdl.org. A list of reported bugs will be maintained on vhdl.org. ****************************************************************************** PARSER VERSION NUMBER: 2.1 PLATFORM (SPARC, HP700, PC, etc.): ALL OS AND VERSION: ALL REPORTED BY: Chris Rokusek, Quad Design DATE: 961105 DESCRIPTION OF BUG: Additional value checking For the following parameters print a warning if they value exceeds the limit. Ramp Times 1 ms R_pkg 1 k R_pin 1 k L_pkg 1 uH L_pin 1 uH C_pkg 1 nF C_pin 1 nF C_comp 1 nF INSERT IBIS FILE DEMONSTRATING THE BUG: [IBIS Ver] 2.1 [File name] big_rlc.ibs [File Rev] 2.0 | [Component] p54c [Manufacturer] fake [Package] | | typ min max R_pkg 1002 1001 1003 L_pkg 1.2E-06 1.1u 1.3E-06 C_pkg 1.2E-09 1.1n 1.1n | |------------------------------------------------------------------ | [Pin] signal_name model_name R_pin L_pin C_pin | 1 sig1 fake_out 1005 1.4u 1.3n 2 sig2 fake_out 999 .99u .99n 3 sig3 fake_out 1008 1.4E-06 1.3E-09 | [Model] fake_out Model_type Output Vinh = 2.0V Vinl = 0.8V | typ min max C_comp 1.01nF 1.02nF 1.03nF | | typ min max [Voltage range] 5.0 4.0 6.0 | | [Pulldown] | voltage I(typ) I(min) I(max) 0.0 0.0 0.0 0.0 3.3V 1mA .5mA 2mA [Pullup] | voltage I(typ) I(min) I(max) 0.0 0.0 0.0 0.0 3.3V -1mA -.5mA -2mA | |Ramp data [Ramp] | typ min max | dV/dt_r 3/1.1m 3/1.2 3/1.3 dV/dt_f 3/1.4m 3/1.5 3/1.6 | | [end] ****************************************************************************** ******************** BELOW FOR ADMINISTRATION AND TRACKING ******************* ****************************************************************************** BUG NUMBER: 5 SEVERITY: [FATAL, SEVERE, MODERATE, ANNOYING, ENHANCEMENT] ENHANCEMENT PRIORITY: [HIGH, MEDIUM, LOW] MEDIUM STATUS: [OPEN, CLOSED, WILL NOT FIX, NOT A BUG] OPEN FIXED VERSION: FIXED DATE: NOTES ON BUG FIX: ****************************************************************************** ****************************************************************************** ****************************************************************************** ********************* IBIS GOLDEN PARSER BUG REPORT FORM ********************* ****************************************************************************** INSTRUCTIONS To report a bug in the IBIS golden parser. Please fill out the top part of the following form and send the complete form to ibischk-bug@vhdl.org. A list of reported bugs will be maintained on vhdl.org. ****************************************************************************** PARSER VERSION NUMBER: 2.1 PLATFORM (SPARC, HP700, PC, etc.): ALL OS AND VERSION: ALL REPORTED BY: Chris Rokusek, Quad Design DATE: 961105 DESCRIPTION OF BUG: Output control Added control where ouput is going rather than stdout. Providing ability to re-direct output to a specified file handle. Default file handle would be 'stdout' to retain backward compatability and not require use of the added function. Please contact me for a new (cleanly) modified errlog.c, crokusek@qdt.com INSERT IBIS FILE DEMONSTRATING THE BUG: ****************************************************************************** ******************** BELOW FOR ADMINISTRATION AND TRACKING ******************* ****************************************************************************** BUG NUMBER: 6 SEVERITY: [FATAL, SEVERE, MODERATE, ANNOYING, ENHANCEMENT] ENHANCEMENT PRIORITY: [HIGH, MEDIUM, LOW] LOW STATUS: [OPEN, CLOSED, WILL NOT FIX, NOT A BUG] OPEN FIXED VERSION: FIXED DATE: NOTES ON BUG FIX: ****************************************************************************** ****************************************************************************** ****************************************************************************** ********************* IBIS GOLDEN PARSER BUG REPORT FORM ********************* ****************************************************************************** INSTRUCTIONS To report a bug in the IBIS golden parser. Please fill out the top part of the following form and send the complete form to ibischk-bug@vhdl.org. A list of reported bugs will be maintained on vhdl.org. ****************************************************************************** PARSER VERSION NUMBER: 2.1 PLATFORM (SPARC, HP700, PC, etc.): ALL OS AND VERSION: ALL REPORTED BY: Chris Rokusek, Quad Design (crokusek@qdt.com) DATE: 961105 DESCRIPTION OF BUG: Check of VI curves against waveforms This check would look at the beginning and ending voltages of a VT Waveform which indicate DC settling points and compare each of these voltages to the given DC VI curves using the load specified for the waveform data. For example, given... [Rising Waveform] R_fixture = 50 V_fixture = 2.5 C_fixture = 50.0pF /* not important for this test */ ...and a waveform like... +V | | | 4.2V | ******** | **** | | * | | first point * | | | * | 2.5V | | * | | | * last point | V * | * 0.5V | ********** | | ------------------------------------- +Time Can use the first point (see above) at 0.5V to check against the low VI curve (see below)... +I | Low State VI Curve | | | V | x LLLLLLLLLLLLLLLLLLLL | x LLLLLLL | x LLL | xLL | LLvx | L v x | L v x | L v x | L v x |L v x <--- slope = -50.0 = R_fixture |L v x L v x _------ Voltage = V_fixture L v x / ----L-------v---------x---------------------- +V L| | | | L 0.0V ?=? 2.5V 5.0V 0.5V? The load line "xxxx" should intersect the low state VI curve "LLLL" at ~= 0.5V indicated by the first point of the [Rising Waveform]. Similarly, the High VI curve can be correlated to the last point of the Rising Waveform. This should be repeated for all waveforms. ** Note that this check requires LOW curve = [PullDown] + [GND_Clamp]. A percentage or some other type of tolerance (TO BE DETERMINED) will be defined as an example of a 2% tolerance for agreement... > > Example Waveform: > > > > Begins: (0ns, 0.0V) > > Ends: (9ns, 4.0V) > > Load: 50 Ohms, 0.0V > > > > > > For 2% agreement, the v_tolerance = 2% * (4.0 - 0) = .08V > > > > So model passes if... > > > > -0.08 < v_dc_low_for_load < 0.08 > > > > AND > > > > 3.92 < v_dc_high_for_load < 4.28 > > I (crokusek@qdt.com) have made changes or added additional modules as follows: Module Did ------ --- ibis.c Added call to acdc_CheckAllModels() within IBIS_Test() acdc.c Added acdc.h Added qry.c Added qry.h Added makefile needs to be updated to include new modules (will not provide as mine is make environment dependent). INSERT IBIS FILE DEMONSTRATING THE BUG: To be provided with code modules after percentage or other method is determined. ****************************************************************************** ******************** BELOW FOR ADMINISTRATION AND TRACKING ******************* ****************************************************************************** BUG NUMBER: 7 SEVERITY: [FATAL, SEVERE, MODERATE, ANNOYING, ENHANCEMENT] ENHANCEMENT PRIORITY: [HIGH, MEDIUM, LOW] MEDIUM STATUS: [OPEN, CLOSED, WILL NOT FIX, NOT A BUG] OPEN FIXED VERSION: FIXED DATE: NOTES ON BUG FIX: ****************************************************************************** ****************************************************************************** From owner-ibis Wed Nov 6 17:37:50 1996 Received: from netcomsv.netcom.com (uucp13.netcom.com [163.179.3.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA01013 for ; Wed, 6 Nov 1996 17:37:49 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id RAA04168; Wed, 6 Nov 1996 17:15:50 -0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA15160; Wed, 6 Nov 96 16:08:54 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA25991; Wed, 6 Nov 1996 16:17:36 +0800 Date: Wed, 6 Nov 1996 16:17:36 +0800 From: dileep@contec.Apsimtech.COM (Dileep Divekar) Message-Id: <9611070017.AA25991@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table Cc: dileep@contec.Apsimtech.COM X-Sun-Charset: US-ASCII Hi Bob, Thanks for filling us in on the background. >I would expect this method to be used with models that >have [Rising Waveform] and [Falling Waveform] tables to >better control the individual shapes. My understanding was that the multi-stage switching specification was an ALTERNATE and may be a more detailed way of specifying the waveforms. Your statement seems to imply that the multi-stage specification is in ADDITION to the waveform specification. If that is the case, I do not see how one can utilize both pieces of information and reconstruct a waveform in the simulator and also I do not see how one can develop a model to isolate these two effects. Dileep Divekar From owner-ibis Thu Nov 7 05:45:54 1996 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id FAA22815 for ; Thu, 7 Nov 1996 05:45:38 -0800 (PST) Received: from Jaxom.Eng.PKO.DEC.Com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA13615; Thu, 7 Nov 1996 08:29:15 -0500 (EST) Received: from exchange.Eng.PKO.DEC.Com by Jaxom.Eng.PKO.DEC.Com; (5.65/1.1.8.2/15Jan96-8.2MAM) id AA03771; Thu, 7 Nov 1996 08:29:15 -0500 Received: by exchange.eng.pko.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBCC85.520CAE20@exchange.eng.pko.dec.com>; Thu, 7 Nov 1996 08:26:06 -0500 Message-Id: From: "Edlund, Greg" To: "'ibis@vhdl.org'" Subject: multi-staged drivers, etc. Date: Thu, 7 Nov 1996 08:26:04 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm jumping into the middle of this discussion, so I plead ignorance if someone has already addressed this question. Does anyone have an overlay of lab and simulation data that quantitatively demonstrates the accuracy of the standard ibis i-v curve method and/or rising waveform method for multi-staged drivers? (My understanding of "multi-staged" is that the output stage is divided up into portions that turn on and off in succession during the excursion from one output level to the other.) I think drivers that employ some kind of feedback mechanism may be interesting to look at, too. It would be necessary to check the waveforms at the driver and receiver for a standard load and maybe a handful of typical net topologies. ---------- Greg Edlund , Principal Engineer Alpha Server Signal Integrity Digital Equipment Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (508) 493-4157 voice (508) 493-0941 FAX edlund@eng.pko.dec.com From owner-ibis Thu Nov 7 08:45:07 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id IAA24507 for ; Thu, 7 Nov 1996 08:45:06 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 7 Nov 1996 16:34:12 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id IAA02678; Thu, 7 Nov 1996 08:32:00 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 07 Nov 96 08:31:59 PST Date: Thu, 07 Nov 96 08:27:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org cc: dileep@contec.Apsimtech.COM Subject: Re[2]: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table Text item: Dileep and Bob, I believe the main reason this BIRD was written was because Jon Powell showed us a few cases for which the V-t curves are NOT adequate. I am only including short excerpts from his description here. (I am shure he would be willing to send the full document to anyone interested). 1) Decreased drive capability. In this example the driver has two output stages. The first stage is High Current Low Voltage (100 mA at 3 V), the second stage is lower driver to 5 V. 2) TTL-CMOS staged output. In this example the driver has two staged outputs, the first is a standard TTL and the secone is standard 5 V CMOS. Arpad ================================================================================ Hi Bob, Thanks for filling us in on the background. >I would expect this method to be used with models that >have [Rising Waveform] and [Falling Waveform] tables to >better control the individual shapes. My understanding was that the multi-stage switching specification was an ALTERNATE and may be a more detailed way of specifying the waveforms. Your statement seems to imply that the multi-stage specification is in ADDITION to the waveform specification. If that is the case, I do not see how one can utilize both pieces of information and reconstruct a waveform in the simulator and also I do not see how one can develop a model to isolate these two effects. Dileep Divekar Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. X-Sun-Charset: US-ASCII Cc: dileep@contec.Apsimtech.COM Subject: Re: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table To: ibis@vhdl.org Message-Id: <9611070017.AA25991@contec13.contec.COM> From: dileep@contec.Apsimtech.COM (Dileep Divekar) Date: Wed, 6 Nov 1996 16:17:36 +0800 Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA25991; Wed, 6 Nov 1996 16:17:36 +0800 Received: from contec13.contec.COM by Apsimtech.COM (4.1/SMI-4.1) id AA15160; Wed, 6 Nov 96 16:08:54 PST Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id RAA04168; Wed, 6 Nov 1996 17:15:50 -0800 Received: from netcomsv.netcom.com (uucp13.netcom.com [163.179.3.13]) by vhdl.vh dl.org (8.7.3/8.7.3) with SMTP id RAA01013 for ; Wed, 6 Nov 1996 17:37:49 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.2/8.7.3) with ESMTP id RAA27301; Wed, 6 Nov 1996 17:49:19 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id RAA10791; Wed, 6 Nov 1996 17:4 6:46 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Thu Nov 7 09:06:15 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA24753 for ; Thu, 7 Nov 1996 09:06:14 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 7 Nov 96 08:55 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Nov 96 08:57 PST Message-Id: Date: Thu, 7 Nov 96 08:57 PST From: chris@icx.com ( Chris Reid) To: ibis@vhdl.org Subject: Multi-staged outputs Hello Ibis World, Well, despite my earlier questions I am now convinced the multi-staged output bird 35.2 is absolutely required to model these devices, and that it is an easily implemented extension for the simulator companies. The time-dependent change in the impedance characteristics of a multi-staged driver must be modeled to get realistic behavior into various loads and to calculate reflections properly. I don't think we will find very many independent modeling companies developing these models because some knowledge of the structure of these devices is needed to get a good model. But that's O.K. since Intel (and hopefully other vendors) will sign up to produce these models for their parts. Chris Reid From owner-ibis Thu Nov 7 11:07:08 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA26048 for ; Thu, 7 Nov 1996 11:07:07 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 7 Nov 96 10:56 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Nov 96 10:56 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Nov 96 10:58 PST Message-Id: Date: Thu, 7 Nov 96 10:58 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: Re[2]: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table To All: Thanks Arpad for your comment. I had actually replied to Dileep's question below but forgot to copy to the reflector or to myself. So I am reconstructing a similar response. Multi-staged switching [Driver Schedule] keyword schedules other [Models]. These scheduled [Models] have all the properties needed to function independently including their own V/T tables. In fact, that would probably be the recommended for models that are scheduled to provide more predictable results for different simulators. So in this sense, the [Driver Schedule] is in addition to the [Rising Waveform] and [Falling Waveform] tables because it calls [Model]s which contain these tables, and the composite response is the summation of the individual staged responses of each [Model]. For downward compatibiltiy and consistency, the [Model] under which [Driver Schedule] is positioned needs to still be a functioning model with overall I/V tables and [Ramp] and possible V/T characteristics. In this sense the [Driver Schedule] is an alterative to the V/T tables and V/I tables contained under this [Model] keyword because these tables are not used. So there is no conflicting information. However, simulators which do not support [Driver Schedule] or need it for a particular application could still use the [Model] if the [Driver Schedule] keyword and table are removed or ignored. Bob Ross Interconnectix > Date: Thu, 07 Nov 96 08:27:00 PST > From: Arpad Muranyi > Message-ID: > To: ibis@vhdl.org > cc: dileep@contec.Apsimtech.COM > Subject: Re[2]: BIRD 35.2 - MULTI-STAGED OUTPUTS vs. V-t table > Status: R > Text item: > Dileep and Bob, > I believe the main reason this BIRD was written was because Jon Powell showed us > a few cases for which the V-t curves are NOT adequate. I am only including > short excerpts from his description here. (I am shure he would be willing to > send the full document to anyone interested). > 1) Decreased drive capability. In this example the driver has two output > stages. The first stage is High Current Low Voltage (100 mA at 3 V), the second > stage is lower driver to 5 V. > 2) TTL-CMOS staged output. In this example the driver has two staged outputs, > the first is a standard TTL and the secone is standard 5 V CMOS. > Arpad > ================================================================================ > Hi Bob, > Thanks for filling us in on the background. > >I would expect this method to be used with models that > >have [Rising Waveform] and [Falling Waveform] tables to > >better control the individual shapes. > My understanding was that the multi-stage switching specification > was an ALTERNATE and may be a more detailed way of specifying the > waveforms. Your statement seems to imply that the multi-stage > specification is in ADDITION to the waveform specification. > If that is the case, I do not see how one can utilize both > pieces of information and reconstruct a waveform in the simulator > and also I do not see how one can develop a model to isolate > these two effects. > Dileep Divekar From owner-ibis Thu Nov 7 11:29:37 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA26229; Thu, 7 Nov 1996 11:29:37 -0800 (PST) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA27237; Thu, 7 Nov 96 11:18:39 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA02423; Thu, 7 Nov 96 11:18:38 PST Date: Thu, 7 Nov 96 11:18:38 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9611071918.AA02423@ricky.sun_net> To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Help, need feedback: Cc: jem@ricky.actel.com, whauff@ricky.actel.com, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu Hello IBIS world, I sent this message out last Tuesday to both IBIS reflectors, as well as all of the contacts at North Carolina State University, and have still recieved no response from anyone. I believe there is a serious problem with the s2ibis program algorythm, where they appear to fudge SPICE results in order to have (more proper looking?) waveforms. I believe that they may have done this as a improper work-around for the reason that SPICE does not seem to properly model the inherent CMOS diodes correctly. They extrapolate data for the pull-down and pull-up curves, instead of calculating it from the full range of I/V data that SPICE produces. I am not trying to repremand NCSU for this, as in all other respects this seems to be an excellent tool for producing IBIS V1.1 files from SPICE. I am still questioning if I am interpreting this correctly, and I really need some feedback from the IBIS community on this. As the ANSI/EIA-656 homepage endorses the use of s2ibis, and it seems that it may very well be a commonly used tool for producing IBIS files, I would think that this might have caught SOMEBODY'S attention... > From scotts Tue Nov 5 16:25:12 1996 > To: ibis@vhdl.org, ibis-users@vhdl.org > Subject: Serious s2ibis problem? > Cc: jem, whauff, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu > Content-Length: 2882 > > Hello IBIS folk: > > We've been trying to figure out why s2ibis produces a Pull-down (and > Pull-up) curve that is VERY different from our self-produced > tables (from SPICE), in particular at voltages from Vcc to 2*Vcc. > This led me to the FAQ under the /man directory of S2IBIS. Here, > I found: > > QUESTION (6): "How does s2ibis generate tables?" > > ANSWER: > s2ibis uses the following scheme for determining what tables > need to be generated for a particular pin: > 0) For POWER, GND, and NC ... > > --snip-- > > 3) For each I/O or 3-state pin... > > --snip again-- > > -> pulldown(-5->0):subtract the associated ground clamp table from > the pulldown table > > -> pulldown(0->Vcc): just use the pull-down table as simulated > > -> pulldown(Vcc->2*Vcc):extrapolate using the point at > Vcc and the point five points before Vcc in the pulldown table > > A similar explanation is provided for pulldown table generation. > My questions are: WHY DO THEY OPT FOR EXTRAPOLATION WHEN THEY HAVE > ALL THE DATA NESSESSARY IN THE SPICE OUTPUT FILES? > WHY ISN'T THE TRI-STATE DATA SUBTRACTED FROM THE > ENTIRE VOLTAGE RANGE? > > After reviewing all of the files that are created (and left) by > s2ibis, I found that it creates V/I tables (***from -Vcc to 2*Vcc***) > for an I/O in: 1)Tri-state (un-enabled) conditions, 2)Pull-up conditions, > and 3)Pull-down conditions. > > In searching through all of the IBIS documentation I could find, the best > explanation for how to produce proper Pull-down and Pull-up curves (for > either SPICE sim data or real data) was in the V2.1 Spec., under > "Other Notes:" of the [Pulldown], [Pullup], [GND Clamp], [Power Clamp] > Keyword section: > > ... The clamp curves of an input or I/O buffer can be measured > directly with a curve tracer, with the I/O buffer 3-stated. > However, sweeping enabled buffers results in curves that are > the sum of the clamping curves and the output structures. > Based on the assumption outlined above (which makes sense), the pull-up > and the pull-down curves of an IBIS model must represent the DIFFERENCE > of the 3-stated and the enabled buffers curves. (Note... ...) > This requirement enables the simulator to sum the curves, without the > danger of double counting, and arrive at an accurate model in both the > 3-stated and enabled conditions. ... > > This explanation seems good for producing V1.1 tables as well (and > perhaps just didn't make it into documentation until the V2.1 Spec). > > So: > Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data > from the entire range of both pull-down and pull-up data to derive the > corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it > takes EXTRA steps to produce seemingly innacurate tables... Is this a > serious mistake with s2ibis, or are am I missunderstanding something. > Thanks ahead for all feedback. > > Regards, > -Scott Schlachter > Design Engineering > Actel Corporation > Sunnyvale, CA > From owner-ibis Thu Nov 7 12:25:42 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA27170; Thu, 7 Nov 1996 12:25:41 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 7 Nov 1996 20:14:48 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id MAA15420; Thu, 7 Nov 1996 12:13:03 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 07 Nov 96 12:13:03 PST Date: Thu, 07 Nov 96 12:10:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Help, need feedback: Text item: Scott, I can't comment on the s2ibis program. I just wanted to correct you in saying it is not that SPICE doesn't model the diodes correctly, it is the people using SPICE who do not bother using some of the SPICE parameters to model the diodes correctly. Arpad =============================================================================== Hello IBIS world, I sent this message out last Tuesday to both IBIS reflectors, as well as all of the contacts at North Carolina State University, and have still recieved no response from anyone. I believe there is a serious problem with the s2ibis program algorythm, where they appear to fudge SPICE results in order to have (more proper looking?) waveforms. I believe that they may have done this as a improper work-around for the reason that SPICE does not seem to properly model the inherent CMOS diodes correctly. They extrapolate data for the pull-down and pull-up curves, instead of calculating it from the full range of I/V data that SPICE produces. I am not trying to repremand NCSU for this, as in all other respects this seems to be an excellent tool for producing IBIS V1.1 files from SPICE. I am still questioning if I am interpreting this correctly, and I really need some feedback from the IBIS community on this. As the ANSI/EIA-656 homepage endorses the use of s2ibis, and it seems that it may very well be a commonly used tool for producing IBIS files, I would think that this might have caught SOMEBODY'S attention... Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: jem@ricky.actel.com, whauff@ricky.actel.com, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu Subject: Help, need feedback: To: ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9611071918.AA02423@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Thu, 7 Nov 96 11:18:38 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA02423; Thu, 7 Nov 96 11:18:38 PST Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA27237; Thu, 7 Nov 96 11:18:39 PST Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8 .7.3/8.7.3) with SMTP id LAA26229; Thu, 7 Nov 1996 11:29:37 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.2/8.7.3) with ESMTP id LAA16705; Thu, 7 Nov 1996 11:25:24 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id LAA08511; Thu, 7 Nov 1996 11:2 2:50 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Thu Nov 7 14:01:22 1996 Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA28224; Thu, 7 Nov 1996 14:01:21 -0800 (PST) Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA29410; Thu, 7 Nov 96 13:51:29 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA02567; Thu, 7 Nov 96 13:51:28 PST Date: Thu, 7 Nov 96 13:51:28 PST From: scotts@actel.com (Scott Schlachter) Message-Id: <9611072151.AA02567@ricky.sun_net> To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org, ibis-users@vhdl.org Subject: Re: Help, need feedback: Arpad, I consider the fact that in order to have SPICE model the correct diode resistance with a MOS transister that you have to "trick" it by either attaching a unidirectional resistor to the drain, attaching a resistor between the bulk and the drain, or negating the inherent diode all together and using an attached discrete component, that there is a fault with the SPICE simulator (or rather just an incomplete model). (Of the above, we are still experimenting as to which will provide the most accurate to the real device). No big deal, as through your help and others, we now have ideas for some possible workarounds, but the SPICE manual did not provide any discussion on this, and listed no apparent way of including the correct vertical resistance associated with the diode (instead it just includes the lateral drain resistance associated with the current path through the transistor). So, I don't think that the users of SPICE are to be blamed so quickly on this point, but more rather the limmitations to modeling the inherent diode associated with MOS transistors in SPICE (why don't they provide for a vertical resistance parameter that would be associated with the diode instead of the drain (or source) resistance?). From our observations so far, just a adding a few ohms of additional resistance in the form of a resistor between the bulk and source has a very significant effect to the IBIS table, specifically in the regions that the diodes start to clamp (between -Vcc to 0V, and Vcc to 2*Vcc). -Scott Schlachter >Scott, > >I can't comment on the s2ibis program. I just wanted to correct you in saying >it is not that SPICE doesn't model the diodes correctly, it is the people using> >SPICE who do not bother using some of the SPICE parameters to model the diodes >correctly. > >Arpad From owner-ibis Thu Nov 7 14:30:22 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA28484; Thu, 7 Nov 1996 14:30:22 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Thu, 7 Nov 1996 22:19:29 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id OAA21914; Thu, 7 Nov 1996 14:17:43 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Thu, 07 Nov 96 14:17:42 PST Date: Thu, 07 Nov 96 14:12:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, ibis-users@vhdl.org Subject: Re[2]: Help, need feedback: Text item: Scott, You are right. At the level of detail you are after SPICE seems to be lacking. What I was referring to was when SPICE modelers don't even go to the extent of using the available drain, source, etc resistance parameters yielding currents in the range of 1.0e+22 Amps at 1 V of forward bias. Arpad ================================================================================ Arpad, I consider the fact that in order to have SPICE model the correct diode resistance with a MOS transister that you have to "trick" it by either attaching a unidirectional resistor to the drain, attaching a resistor between the bulk and the drain, or negating the inherent diode all together and using an attached discrete component, that there is a fault with the SPICE simulator (or rather just an incomplete model). (Of the above, we are still experimenting as to which will provide the most accurate to the real device). No big deal, as through your help and others, we now have ideas for some possible workarounds, but the SPICE manual did not provide any discussion on this, and listed no apparent way of including the correct vertical resistance associated with the diode (instead it just includes the lateral drain resistance associated with the current path through the transistor). So, I don't think that the users of SPICE are to be blamed so quickly on this point, but more rather the limmitations to modeling the inherent diode associated with MOS transistors in SPICE (why don't they provide for a vertical resistance parameter that would be associated with the diode instead of the drain (or source) resistance?). From our observations so far, just a adding a few ohms of additional resistance in the form of a resistor between the bulk and source has a very significant effect to the IBIS table, specifically in the regions that the diodes start to clamp (between -Vcc to 0V, and Vcc to 2*Vcc). -Scott Schlachter >Scott, > >I can't comment on the s2ibis program. I just wanted to correct you in saying >it is not that SPICE doesn't model the diodes correctly, it is the people using> >SPICE who do not bother using some of the SPICE parameters to model the diodes >correctly. > >Arpad Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Help, need feedback: To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org, ibis-users@vhdl.org Message-Id: <9611072151.AA02567@ricky.sun_net> From: scotts@actel.com (Scott Schlachter) Date: Thu, 7 Nov 96 13:51:28 PST Received: by ricky.sun_net (4.1/SMI-4.1) id AA02567; Thu, 7 Nov 96 13:51:28 PST Received: from ricky.sun_net ([192.9.202.221]) by actel.com (4.1/SMI-4.1) id AA29410; Thu, 7 Nov 96 13:51:29 PST Received: from actel.com (rigel-g.actel.com [204.33.232.16]) by vhdl.vhdl.org (8 .7.3/8.7.3) with SMTP id OAA28224; Thu, 7 Nov 1996 14:01:21 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.2/8.7.3) with ESMTP id NAA28684; Thu, 7 Nov 1996 13:59:10 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id NAA08467; Thu, 7 Nov 1996 13:5 6:36 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Thu Nov 7 14:54:47 1996 Received: from SantaClara01.pop.internex.net (SantaClara01.POP.InterNex.Net [205.158.3.18]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA28709 for ; Thu, 7 Nov 1996 14:54:46 -0800 (PST) From: tyc@epswin.com Received: from epswin.com ([205.158.251.162]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with ESMTP id AAA13669 for ; Thu, 7 Nov 1996 14:43:53 -0700 Received: from EPS_USA_NW41/SpoolDir by epswin.com (Mercury 1.21); 7 Nov 96 14:44:12 +1100 Received: from SpoolDir by EPS_USA_NW41 (Mercury 1.21); 7 Nov 96 14:44:08 +1100 Organization: eps To: ibis@vhdl.org Date: Thu, 7 Nov 1996 14:44:05 PST MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ibis ftp site Priority: normal X-mailer: Pegasus Mail for Windows (v2.33) Message-ID: <575332C273D@epswin.com> Hi I like to get some information about ibis and was told that there is a ftp site. Could you please let me know where is the ftp site. Thanks. ************************************************************************** Tai-Yu Chou Express Packaging System, Inc. Tel: (415) 919-0300, x103 1137-B San Antonio Rd. Fax: (415) 919-0303 Palo Alto, CA 94303 email: tyc@epswin.com ************************************************************************** From owner-ibis Thu Nov 7 15:34:59 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA29160 for ; Thu, 7 Nov 1996 15:34:58 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id PAA16650; Thu, 7 Nov 1996 15:24:54 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma016489; Thu Nov 7 15:24:38 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA16005 for ibis@vhdl.org; Thu, 7 Nov 96 15:23:43 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA23639; Thu, 7 Nov 96 15:24:49 PST Date: Thu, 7 Nov 96 15:24:49 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9611072324.AA23639@rockie.nsc.com> To: ibis@vhdl.org, tyc@epswin.com Subject: Re: ibis ftp site HI Chou, The ftp site is vhdl.org(198.31.14.3). This is an anonymous ftp site and you can cd to /pub/ibis for all IBIS related information. You may also use the Web site under ANSI/EIA-656 at http://www.eia.org/eig/ibis/ibis.htm Best Regards, Syed National Semiconductor Corp. > From owner-ibis@vhdl.vhdl.org Thu Nov 7 14:52:36 1996 > From: tyc@epswin.com > Organization: eps > To: ibis@vhdl.org > Date: Thu, 7 Nov 1996 14:44:05 PST > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset=US-ASCII> > Content-Transfer-Encoding: 7BIT > Subject: ibis ftp site > Priority: normal > X-Mailer: Pegasus Mail for Windows (v2.33) > Content-Length: 497 > > Hi > > I like to get some information about ibis and was told that there is > a ftp site. Could you please let me know where is the ftp site. > > Thanks. > > > ************************************************************************** > Tai-Yu Chou > Express Packaging System, Inc. Tel: (415) 919-0300, x103 > 1137-B San Antonio Rd. Fax: (415) 919-0303 > Palo Alto, CA 94303 email: tyc@epswin.com > ************************************************************************** > From owner-ibis Thu Nov 7 18:59:39 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA01558 for ; Thu, 7 Nov 1996 18:59:33 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Thu, 7 Nov 96 18:45 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Nov 96 18:45 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Nov 96 18:47 PST Message-Id: Date: Thu, 7 Nov 96 18:47 PST From: bob@icx.com ( Bob Ross) To: Edlund@EXCHANGE.eng.pko.dec.com, ibis@vhdl.org Subject: Re: multi-staged drivers, etc. Greg: I also agree that it would be nice to see some simulation comparisons of networks using and "identical" model constructed with and without the multi-staged switching capability. Your definition of multi-staged looks good to me. We have not addressed models of drivers with feedback. Bob Ross Interconnectix > From: "Edlund, Greg" > To: "'ibis@vhdl.org'" > Subject: multi-staged drivers, etc. > Date: Thu, 7 Nov 1996 08:26:04 -0500 > X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > Status: RO > I'm jumping into the middle of this discussion, so I plead ignorance if > someone has already addressed this question. > Does anyone have an overlay of lab and simulation data that > quantitatively demonstrates the accuracy of the standard ibis i-v curve > method and/or rising waveform method for multi-staged drivers? (My > understanding of "multi-staged" is that the output stage is divided up > into portions that turn on and off in succession during the excursion > from one output level to the other.) I think drivers that employ some > kind of feedback mechanism may be interesting to look at, too. It would > be necessary to check the waveforms at the driver and receiver for a > standard load and maybe a handful of typical net topologies. > ---------- > Greg Edlund , Principal Engineer > Alpha Server Signal Integrity > Digital Equipment Corp. > 129 Parker St. PKO3-1/20C > Maynard, MA 01754 > (508) 493-4157 voice > (508) 493-0941 FAX > edlund@eng.pko.dec.com From owner-ibis Fri Nov 8 05:12:15 1996 Received: from c11142-335dan.ece.ncsu.edu (c11142-335dan.ece.ncsu.edu [152.1.59.231]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id FAA22114 for ; Fri, 8 Nov 1996 05:12:15 -0800 (PST) Received: by c11142-335dan.ece.ncsu.edu (8.6.9/EC06jan95) id IAA04901; Fri, 8 Nov 1996 08:01:13 -0500 From: "Michael B Steer" Message-Id: <9611080801.ZM4899@eos.ncsu.edu> Date: Fri, 8 Nov 1996 08:01:12 -0500 In-Reply-To: scotts@actel.com (Scott Schlachter) "Help, need feedback:" (Nov 7, 11:18am) References: <9611071918.AA02423@ricky.sun_net> X-Mailer: Z-Mail (3.2.1 10oct95) To: scotts@actel.com (Scott Schlachter) Subject: Re: Help, need feedback: Cc: ibis@vhdl.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Scott, s2ibis is unsupported code. You can do what you like with it. s2ibis was basically done by a few students and myself on their own time I find your comments offensive. Yes there are some inconsistencies in the ibis spec but these are required for efficient behavioral modeling. s2ibis uses its own interpretation. If a user does not know how to use SPICE correctly then s2ibis cannot possibly correct this problem. Michael Steer -- ================================================= Dr. Michael Steer, Professor Dept. of Electrical & Computer Engineering Daniels Hall, Room 335 North Carolina State University Raleigh, NC 27695-7911 phone 919-515-5191 fax: 919-515-5523 email mbs@ncsu.edu url: http://www.ece.ncsu.edu/erl/faculty/mbs.html ================================================= From owner-ibis Fri Nov 8 07:57:30 1996 Received: from c11167-343dan.ece.ncsu.edu (c11167-343dan.ece.ncsu.edu [152.1.59.242]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA23726; Fri, 8 Nov 1996 07:57:29 -0800 (PST) From: awglaser@eos.ncsu.edu Received: by c11167-343dan.ece.ncsu.edu (8.6.9/EC06jan95) id KAA10040; Fri, 8 Nov 1996 10:46:30 -0500 Message-Id: <199611081546.KAA10040@c11167-343dan.ece.ncsu.edu> Subject: Re: Serious s2ibis problem? To: scotts@actel.com (Scott Schlachter) Date: Fri, 8 Nov 1996 10:46:30 -0500 (EST) Cc: ibis@vhdl.org, ibis-users@vhdl.org In-Reply-To: <9611060025.AA01931@ricky.sun_net> from "Scott Schlachter" at Nov 5, 96 04:25:12 pm X-Mailer: ELM [version 2.4 PL24/POP] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data > from the entire range of both pull-down and pull-up data to derive the > corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it > takes EXTRA steps to produce seemingly innacurate tables... Is this a > serious mistake with s2ibis, or are am I missunderstanding something. > Thanks ahead for all feedback. Scott: While I didn't write the version of s2ibis that you refer to, I think I can answer your question. The answer lies in the voltage ranges of the pullup (or pulldown) and power clamp (or ground clamp) curves, and the assumption that a tool will add the pullup and power clamp curves of a tristate device together to get the correct total behavior. If you look at the voltage points in the pullup curve, you'll see that they vary from -Vcc to 2*Vcc, while those in the power clamp curve only vary from Vcc to 2*Vcc. When the simulator adds these two curves together, then, it only adds values to the pullup curve in the range Vcc to 2*Vcc, not the whole range of the curve. If one were to subtract the tristated pullup curve from the active pullup curve over the entire -Vcc to 2*Vcc range, the IBIS tool would be unable to reconstruct the correct behavior of the model, as the required data (i.e. the tristated data from -Vcc to Vcc) would not be present in the IBIS file. Hope that clears things up. Regards, -- Alan Glaser "It's not a competition, ECE Dept. it's just a mint..." - K North Carolina State University From owner-ibis Fri Nov 8 11:39:06 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA25791 for ; Fri, 8 Nov 1996 11:39:03 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 8 Nov 96 11:28 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 8 Nov 96 11:28 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 8 Nov 96 11:30 PST Message-Id: Date: Fri, 8 Nov 96 11:30 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Comments and questions about Electrical Descriptions of Boards and Connectors To IBIS Committee: Here is an apparently bounced message that was supposed to go out to the IBIS committee that was not sent. Sorry about the format. This was how it was received, plus some extra binary stuff at the end which I deleted. (Hank had indicated some mailer changes.) Bob Ross Interconnectix Dileep, I am happy that someone is really reading this material. Thank you for your questions and comments. My response is provided below, following each one of your questions or comments. ---------- From: owner-ibis[SMTP:owner-ibis@vhdl.vhdl.org] Sent: Wednesday, November 06, 1996 10:32 AM To: ibis Cc: dileep Subject: Comments and questions about Electrical Descriptions of Boards and Connectors. I have some comments and questions about the BIRD regarding the Electrical Descriptions of Boards and Connectors. 1) | Note: The simulator must not limit the Number of Pins to any | value less than 1,000. I do not understand why any number should be specified. If the maximum allowable limit is 1,000 then many high pin count packages cannot be modeled. The only reason any number is specified is to prevent an arbitrary limit from being set by a simulator. For example, it would be a problem if this value was limited to an 8 bit integer. 2) |Description: Tells the parser the set of names that are used for the part's | external pins and also defines pin ordering. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest". I do not understand the significance of this. Why is it necessary to define pin ordering? The parser needs only the information about pin names. There needs to be a way for the simulator to match external, or global pin names to the internal pin names used in the model. This is especially important in the case of connectors where there are 2 ends to every contact that need to be appropriately identified and properly connected to the rest of the system. That is the purpose of this statement and it is in agreement with the way it is handled in IBIS version 2.1 (I hope). 3) | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. I think in addition to R, specification of G should be allowed. Since this is an optional specification, for cases where the dielectric loss is not significant, it need not be specified. In fact I would say that we should go even one step further and allow an optional sepcification of high frequency R in addition to the DC value. I do not see any reason that G can not be included as an additional option. I do have some concerns about trying to specify a HF R. 1. First, I would point out that we are dealing with uncoupled models at this time and are after fast, first order accuracy. 2. What frequency would you use for a digital signal and how would that R be calculated? 3. There would be a need to specify a frequency (or bandwidth) for any non-DC resistance. 4. Finally, with respect to connectors in digital signal applications, skin effects are negligible, especially for this first order modeling we are pursuing here, and we want the proper voltage drop across the connector for any DC circuit. 4) | A section description begins with the Len subparameter and | ends with the backslash (/) character. The value of the Len, L, The backslash (/) character mentioned above is actually a forward slash character. The backslash is \. Good point! Got me on that one! I think it should be the 'slash' (/), not the 'backslash' (\). Our syntax experts should check that out. 5) | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the Len subparameter | is non-zero, then the L/R/C subparameters represent distributed | elements. I think the specification should say that if non-zero Len is specified, then BOTH L AND C MUST be specified. The R (and G) can be optional. By definition, the physical description of the distributed transmission line has BOTH L and C. Another good point. I think this can be fixed by the addition of "and at least L and C must be specified" to the end of the last sentence. 6) | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a node, | section, another pin or the reserved word, NC. | | C) All paths and subpaths (a path between Fork and Endfork) | end in a Pin, a Node or NC. The last sentence in B) and the sentence in C) seem contradictory. B) allows the path to be terminated in a section also. The only possible subparameters under the path description are Len, Pin, Node and Fork/EndFork. I do not see any need to put restrictions on how the path should end. Also, the need and usage of NC is not clear. Off hand, it seems that we can do without it. Is it allowed to have another Fork statement inside a Fork statement before the Endfork? The NC and the need for a specific end to a path description covers situations where there may be a stub on a board or a skipped or deleted pin on a connector where there is more than one pin for a given contact such as for a shielding plate. I do see your contradiction, however. Perhaps the word 'section' should be deleted from B) and paragraph C) could be eliminated. As far as Fork/EndFork, there was no intent to limit branching so these parameters can be nested. 7) | Node pin.reference_designator This is a minor point, but all the pcb design programs I know, use the convention reference_designator.pin. Most people are used to seeing something like U3.17 as opposed to 17.U3. Again, this is one for our syntax experts. We certainly want to be as consistent as possible. Some general comments: There are cases where a trace forks into two and then the two traces join again to form a single trace. How does one describe this? The re-connect can be accomplished at any pin or node. It is stated that C is the capacitance to "ground". This assumes that there is only ONE ground for ALL the sections of this board as well as all the other boards connected to this board by virtue of .eid models specified in the Reference Designator Map. This precludes the use of this model for doing ground bounce analysis. Without distributed ground and power planes, there is only one ground for a small board or uncoupled connector. If you need a more detailed model, the board can be described in EDIF format and handled appropriately. Also, without global interconnect models (ones with through paths for every contact and no dedicated ground lines) there is no practical way for any simulator to do ground bounce. Again, please remember we are only dealing with first order uncoupled models at this time. They are complicated enough. Coupled models will be dealt with after we think we can do these so called 'simple ones'. Since this is supposed to address the full board description, I just wanted to mention that there is a tendency (particularly in SIMMs and MCMs) to add other components on the boards, in addition to the ICs and connectors. Embedded resistors is an example that comes to mind. Is it possible to include these components in this description? I refer you to the last example under the [Reference Designator Map] keyword. It calls a resistor pack. The .eid model of that resistor pack could be simply the network of resistors between external pins. I hope these responses are helpful. Again, thank you for your careful review of this interim BIRD 36c. Hank From owner-ibis Fri Nov 8 16:22:25 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA28273 for ; Fri, 8 Nov 1996 16:22:22 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 8 Nov 96 16:05 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 8 Nov 96 16:05 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 8 Nov 96 16:07 PST Message-Id: Date: Fri, 8 Nov 96 16:07 PST From: bob@icx.com ( Bob Ross) To: arpad_muranyi@ccm.fm.intel.com, awglaser@eos.ncsu.edu, ibis@vhdl.org, mbs@ncsu.edu, scotts@actel.com Subject: Re: Help, need feedback: Cc: paulf@ncsu.edu, slipa@eos.ncsu.edu Scott, Arpad, Michael, Alan and IBIS committee: I apologize for not jumping in sooner on this issue since, as you have probably observed, I have been jumping in on other issues. I do need to add some clarification because the particular algorithms in question were based, in part, on some long discussions with me and Steve. First, however, I need to clarify that NSCU has and continues to do an excellent job in developing and supporting s2ibis - BEYOND reasonable expectations. The utilities are complicated because they are designed to cover all or nearly all of the IBIS Version 1.1 and 2.1 functionality. NCSU has no responsiblity to provide user support. If anything, that is our responsibility - the user community. The ibis-users@vhdl.org is an excellent mechanism to raise questions and concerns. Syed Huq has volunteered to track the techical issues and problems that are expected to occur. I want to elaborate on one comment that Alan made concerning addition of clamp curves over specified ranges. I believe most behavioral simulators do LINEAR EXTRAPOLATION beyond the voltage end-points of data contained in the I/V tables. Thus ALL tables are considered to extend from -infinity to +infinity based on the last TWO data points. Spice simulators may also allow for EXTENSIONS beyond the table voltage ranges by using just the LAST data point. These differences were one reason why IBIS initially opted to specify a large range (-Vcc to 2Vcc) of operation so users would not be surprized by the two different methods of analysis in the -Vcc to 0 and Vcc to 2Vcc ranges. Technically the [Gnd Clamp] and [Power Clamp] tables should also have been both specified from -Vcc to 2Vcc. In practice, the [Gnd Clamp] tables and [Power Clamp] tables typically have a value of nearly "0" and a SLOPE of nearly "0" at the IBIS specified range point of Vcc. So the models will function nearly the same in all simulators. You are allowed to specify tables beyond the IBIS mandated minimum ranges. Internal Pullup "resistors" and Pulldown "resistors" in ASICs require extended tables to support all simulators. So if a pullup resistor exists, its effects should be capured in the [Power Clamp] table extending from -Vcc to 2Vcc. Simulators should add the [Power Clamp] and [Gnd Clamp] currents together at ALL voltage points (whether these are from extensions or linear extrapolation). This summation should define the total I/V characteristic of an Input or an output in the 3-stated mode. These currents are added to the [Pulldown] currents at the low state, and to the [Pullup] currents at the high state to form the composite I/V characteristic seen at these two states throughout the entire -Vcc to 2Vcc range. As Michael pointed out, the algorithm is for more effient behavioral modeling. Scott is correct in noting that the mathematical subtraction definition is not implemented. This is one case where, for very apparent reasons, the mathematically pure implementation is inferior to a practical numerical implementation. Take, for example, the [Pulldown] table. A low state sweep of the output between Vcc and 2Vcc will eventually pick up the clamp diode from about Vcc+.7. Both the [Power Clamp] and [Pullup]+[Power Clamp] data that is extracted both may converge to the same VERY large values (particularly if the diode resistance is not handled fully according to recent reflector discussions). The mathematically correct implementation is to simply subtract the two tables, even if the results converge to 0 as a result of numerically subtracting two large values to get a small value. Thus a Linear Extrapolation method was chosen to comply more with the real behavior for the range from Vcc to 2Vcc. Plus, the [Pulldown] table really does not have to be too accurate here because (1) when the output is in the low state, you are really not going to force it to above Vcc in practice, and (2) while this is a simulator algorithm dependent issue, I do not expect any transition algorithm from low to high state or high to low state to depend upon extremely accurate points beyond Vcc or below Gnd. I personally would have preferred the same extrapolation algorithm to apply to the [Pulldown] table region between -Vcc to 0. We compromised on this and used the mathematically pure subtraction of tables to be in technical compliance with the IBIS Version 1.1 Specification. You see the effects of this in many public s2ibis generated [Pulldown] tables showing the currents folding back to "0" at -Vcc. Fortunately, the [Gnd Clamp] dominates, and the summation of currents is monotonic. Most simulators can either process the non-monotonic portion of the [Pulldown] table and translate it into monotonic data, or can do the summation of the two tables and see only the monotonic result during analysis. Scott, I commend you for your perceptive and detailed concern on what appeared to be an algorithm defect. The discussion with you and Arpad and others on the the nature of the diode resistance gave me insite as to why some Spice models may have large diode currents. Best Regards, Bob Ross Interconnectix > Date: Thu, 7 Nov 96 11:18:38 PST > From: scotts@actel.com (Scott Schlachter) > Message-Id: <9611071918.AA02423@ricky.sun_net> > To: ibis@vhdl.org, ibis-users@vhdl.org > Subject: Help, need feedback: > Cc: jem@ricky.actel.com, whauff@ricky.actel.com, mbs@ncsu.edu, paulf@ncsu.edu, > slipa@eos.ncsu.edu > Status: RO > Hello IBIS world, > I sent this message out last Tuesday to both IBIS reflectors, as well as > all of the contacts at North Carolina State University, and have still > recieved no response from anyone. I believe there is a serious problem > with the s2ibis program algorythm, where they appear to fudge SPICE > results in order to have (more proper looking?) waveforms. I believe that > they may have done this as a improper work-around for the reason that SPICE > does not seem to properly model the inherent CMOS diodes correctly. They > extrapolate data for the pull-down and pull-up curves, instead of > calculating it from the full range of I/V data that SPICE produces. > I am not trying to repremand NCSU for this, as in all > other respects this seems to be an excellent tool for producing IBIS V1.1 > files from SPICE. I am still questioning if I am interpreting this > correctly, and I really need some feedback from the IBIS community on this. > As the ANSI/EIA-656 homepage endorses the use of s2ibis, and it seems > that it may very well be a commonly used tool for producing IBIS files, > I would think that this might have caught SOMEBODY'S attention... > > From scotts Tue Nov 5 16:25:12 1996 > > To: ibis@vhdl.org, ibis-users@vhdl.org > > Subject: Serious s2ibis problem? > > Cc: jem, whauff, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu > > Content-Length: 2882 > > > > Hello IBIS folk: > > > > We've been trying to figure out why s2ibis produces a Pull-down (and > > Pull-up) curve that is VERY different from our self-produced > > tables (from SPICE), in particular at voltages from Vcc to 2*Vcc. > > This led me to the FAQ under the /man directory of S2IBIS. Here, > > I found: > > > > QUESTION (6): "How does s2ibis generate tables?" > > > > ANSWER: > > s2ibis uses the following scheme for determining what tables > > need to be generated for a particular pin: > > 0) For POWER, GND, and NC ... > > > > --snip-- > > > > 3) For each I/O or 3-state pin... > > > > --snip again-- > > > > -> pulldown(-5->0):subtract the associated ground clamp table from > > the pulldown table > > > > -> pulldown(0->Vcc): just use the pull-down table as simulated > > > > -> pulldown(Vcc->2*Vcc):extrapolate using the point at > > Vcc and the point five points before Vcc in the pulldown table > > > > A similar explanation is provided for pulldown table generation. > > My questions are: WHY DO THEY OPT FOR EXTRAPOLATION WHEN THEY HAVE > > ALL THE DATA NESSESSARY IN THE SPICE OUTPUT FILES? > > WHY ISN'T THE TRI-STATE DATA SUBTRACTED FROM THE > > ENTIRE VOLTAGE RANGE? > > > > After reviewing all of the files that are created (and left) by > > s2ibis, I found that it creates V/I tables (***from -Vcc to 2*Vcc***) > > for an I/O in: 1)Tri-state (un-enabled) conditions, 2)Pull-up conditions, > > and 3)Pull-down conditions. > > > > In searching through all of the IBIS documentation I could find, the best > > explanation for how to produce proper Pull-down and Pull-up curves (for > > either SPICE sim data or real data) was in the V2.1 Spec., under > > "Other Notes:" of the [Pulldown], [Pullup], [GND Clamp], [Power Clamp] > > Keyword section: > > > > ... The clamp curves of an input or I/O buffer can be measured > > directly with a curve tracer, with the I/O buffer 3-stated. > > However, sweeping enabled buffers results in curves that are > > the sum of the clamping curves and the output structures. > > Based on the assumption outlined above (which makes sense), the pull-up > > and the pull-down curves of an IBIS model must represent the DIFFERENCE > > of the 3-stated and the enabled buffers curves. (Note... ...) > > This requirement enables the simulator to sum the curves, without the > > danger of double counting, and arrive at an accurate model in both the > > 3-stated and enabled conditions. ... > > > > This explanation seems good for producing V1.1 tables as well (and > > perhaps just didn't make it into documentation until the V2.1 Spec). > > > > So: > > Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data > > from the entire range of both pull-down and pull-up data to derive the > > corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it > > takes EXTRA steps to produce seemingly innacurate tables... Is this a > > serious mistake with s2ibis, or are am I missunderstanding something. > > Thanks ahead for all feedback. > > > > Regards, > > -Scott Schlachter > > Design Engineering > > Actel Corporation > > Sunnyvale, CA > > From owner-ibis Fri Nov 8 18:38:53 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id SAA29388 for ; Fri, 8 Nov 1996 18:38:53 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.2/8.7.3) with ESMTP id SAA03589; Fri, 8 Nov 1996 18:27:45 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id SAA00516; Fri, 8 Nov 1996 18:27:14 -0800 (PST) Message-Id: <199611090227.SAA00516@ichips.intel.com> To: ibis@vhdl.org, omf-tech@cfi.org, omf-oec@cfi.org Subject: My mail address has been changed.... Date: Fri, 08 Nov 1996 18:27:47 -0800 From: Stephen Peters Hello All: Just a note to let you know that my e-mail address has been changed to 'sjpeters@ichips.intel.com.' The old address will work for a while, but if you use it you will receive an automatic reminder that it has been changed, so please update your mailling lists accordingly. My phone and address remain the same. Regards, Stephen Peters Intel Corp. From owner-ibis Mon Nov 11 04:21:47 1996 Received: from melcogw.melit.melco.co.jp (melcogw.melit.melco.co.jp [192.218.140.35]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id EAA03816; Mon, 11 Nov 1996 04:21:43 -0800 (PST) Received: by melcogw.melit.melco.co.jp (5.65+1.6W/2.7W) id AA19489; Mon, 11 Nov 96 21:10:40 JST Received: from bhb003 by inetgw.topo.melco.co.jp (1.38.193.5/6.4J.6-inetgw1.0) id AA16878; Mon, 11 Nov 1996 21:10:30 +0900 Received: from ss12 by bhb003.hoku.melco.co.jp (16.8/6.4J.6-hoku01) id AA15882; Mon, 11 Nov 96 21:01:34 +0900 Received: from [161.5.3.79] by ss12.memg2.hoku.melco.co.jp (4.1/6.4J.6-memg2-941124) id AA22537; Mon, 11 Nov 96 21:20:03 JST Date: Mon, 11 Nov 96 21:20:02 JST Message-Id: <9611111220.AA22537@ss12.memg2.hoku.melco.co.jp> To: awglaser@eos.ncsu.edu From: nakamae@memg2.hoku.melco.co.jp (nakamae midori) Subject: Question about Re: Serious s2ibis problem? Cc: hoang@msai.mea.com, ibis@vhdl.org, ibis-users@vhdl.org X-Mailer: Eudora-J(1.3.8.5-J13) Hello Alan Glaser : I am now developing a IBIS model by s2ibis program in Japan. I would like to have a question concerning your answer and make sure IBIS V2.1 spec. Could you please give your response to me ? My question is, Is the following my assumption right ? Is that the algorithm of IBIS simulators ? The following shows my assumption for IBIS simulator's algorithm. IBIS Version 2.1 (8/22/95) spec. say below. --------------------------------------------------------- It is assumed that the simulator sums the clamp curves together with the appropriate pull-up or pull-down curve when a buffer is driving high or low,respectively. From this assumption and the nature of 3-statable buffers, it follows that the data in the clamping curve sections ======================================(A) are handled as constantly present curves and the pull-up and pull-down curves are used only when needed in the simulation. --------------------------------------------------------- IBIS model have 4 tables for 3-state buffer. Pullup table = Pullup(enable High out) - (Disable output) at the range -Vcc~2*Vcc Pulldown table = Pulldown(enable Low out) - (Disable output) at the range -Vcc~2*Vcc GND-clamp table = Disable output at the range -Vcc~Vcc POWER-clamp table = Disable output at the range Vcc~2*Vcc If the ranges are right,IBIS simulator must add GND-clamp table(-Vcc~Vcc) and POWER-clamp table(Vcc~2*Vcc) to constract the full range clamp datas (the data in the clamping curve sections) and handle it as constantly present =====================================(A)(see above IBIS spec.) current, when OUTPUT is disable state , High-Z state or OFF. And IBIS simulator must add the full range clamp datas to Pullup table to construct the full range pull-up curve,when a pullup transistor is ON. Similarly,simulator must add the full range clamp datas to Pulldown table to construct the full range pull-down curve,when a pulldown transistor is ON. Here,my 3-state buffer has n-channel pullup transistor. (Note) My 3-state buffer is not a inverter which consist of P-ch. and N-ch. transistors,but a output buffer which consist of N-ch. pullup transistor and N-ch. pulldown transistor and is able to out High,Low and High-Z. My 3-state buffer have Hogh-out and Low-out I/V curves which exit a big current at the range -VCC~0V. But POWER-clamp table which s2ibis program generated for my 3-state buffer is only at VCC~2*VCC range and "all zero" of course. Is the POWER-clamp table for my buffer right ? If IBIS simulator add pullup table to only POWER-clamp table which expand to the full range,I think it is wrong either s2ibis or simulator. Best Regards, Nakamae. At 10:46 AM 96.11.8 -0500, awglaser@eos.ncsu.edu wrote: > >> Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data >> from the entire range of both pull-down and pull-up data to derive the >> corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it >> takes EXTRA steps to produce seemingly innacurate tables... Is this a >> serious mistake with s2ibis, or are am I missunderstanding something. >> Thanks ahead for all feedback. > > >Scott: > >While I didn't write the version of s2ibis that you refer to, I think I >can answer your question. > >The answer lies in the voltage ranges of the pullup (or pulldown) and >power clamp (or ground clamp) curves, and the assumption that a tool >will add the pullup and power clamp curves of a tristate device together >to get the correct total behavior. > >If you look at the voltage points in the pullup curve, you'll see that >they vary from -Vcc to 2*Vcc, while those in the power clamp curve only >vary from Vcc to 2*Vcc. When the simulator adds these two curves >together, then, it only adds values to the pullup curve in the range Vcc >to 2*Vcc, not the whole range of the curve. > >If one were to subtract the tristated pullup curve from the active >pullup curve over the entire -Vcc to 2*Vcc range, the IBIS tool would be >unable to reconstruct the correct behavior of the model, as the required >data (i.e. the tristated data from -Vcc to Vcc) would not be present in >the IBIS file. > >Hope that clears things up. > >Regards, > >-- >Alan Glaser "It's not a competition, >ECE Dept. it's just a mint..." - K >North Carolina State University From owner-ibis Mon Nov 11 12:53:53 1996 Received: from newsgw.mentorg.com (newsgw.mentorg.com [137.202.128.5]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id MAA16325 for ; Mon, 11 Nov 1996 12:53:50 -0800 (PST) Received: from bvserver.ebv.mentorg.com by newsgw.mentorg.com (8.6.8.1/CF5.22R) id MAA05265; Mon, 11 Nov 1996 12:42:51 -0800 Received: from andre-laptp by bvserver.ebv.mentorg.com (8.6.8.1/CF5.26R) id VAA01036; Mon, 11 Nov 1996 21:42:47 +0100 From: "andre CLOUP" Message-Id: <961111214045.ZM12886@andre-laptp> Date: Mon, 11 Nov 1996 21:40:35 +0200 X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) To: ibis@vhdl.org Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii please unsubscribe me from the ibis reflector. From owner-ibis Mon Nov 11 13:00:30 1996 Received: from gatekeep.ti.com (news.ti.com [192.94.94.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id NAA16411 for ; Mon, 11 Nov 1996 13:00:29 -0800 (PST) Received: from sh-gpl.ti.com ([157.170.61.67]) by gatekeep.ti.com (8.6.13) with ESMTP id OAA27488 for ; Mon, 11 Nov 1996 14:49:03 -0600 Received: from brain.sh-gpl.ti.com (brain.sh-gpl.ti.com [157.170.61.85]) by sh-gpl.ti.com (8.7.6/8.7.3) with ESMTP id OAA27390; Mon, 11 Nov 1996 14:52:04 -0600 (CST) From: Tareq Shahwan Received: (from tareq@localhost) by brain.sh-gpl.ti.com (8.7.6/8.7.3) id OAA26594; Mon, 11 Nov 1996 14:52:02 -0600 (CST) Message-Id: <199611112052.OAA26594@brain.sh-gpl.ti.com> Subject: unsubscribe To: ibis@vhdl.org (ibis @vhdl.org) Date: Mon, 11 Nov 1996 14:52:02 -0600 (CST) Cc: shahwan@ti.com (Tareq Shahwan) Reply-To: tareq@sh-gpl.ti.com Errors-To: tareq@sh-gpl.ti.com X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Please unsubscribe me from the IBIS reflector. Thank you ! Regards, Tareq Shahwan From owner-ibis Mon Nov 11 13:18:29 1996 Received: from mercury.stm.com (root@MERCURY.STM.COM [192.157.33.18]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id NAA16544 for ; Mon, 11 Nov 1996 13:18:27 -0800 (PST) Received: (from root@localhost) by mercury.stm.com (8.7.6/8.7.3) id PAA10905 for ; Mon, 11 Nov 1996 15:05:01 -0600 (CST) Received: from sun4g001.stm.com(167.4.6.13) by mercury.stm.com via smap (V1.3) id sma010888; Mon Nov 11 15:04:56 1996 Received: from sun4c481 by eccsun.COM (4.1/SMI-4.1-DNI-MHS-7.0) id AA25183; Mon, 11 Nov 96 15:08:12 CST Received: by sun4c481 (4.1/SMI-4.1) id AA23414; Mon, 11 Nov 96 13:08:22 PST Date: Mon, 11 Nov 96 13:08:22 PST From: aaronr@mercury.stm.com (Rob Aaron) Message-Id: <9611112108.AA23414@sun4c481> To: ibis@vhdl.org@mercury.stm.com Subject: unsubscribe From owner-ibis Mon Nov 11 14:47:00 1996 Received: from larry.corollary.com (larry.corollary.com [192.132.4.19]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA17384 for ; Mon, 11 Nov 1996 14:46:59 -0800 (PST) Received: from billfpc (billfpc.corollary.com [204.30.136.12]) by larry.corollary.com (8.8.0/8.7.3) with SMTP id OAA17908 for ; Mon, 11 Nov 1996 14:34:05 -0800 Message-Id: <2.2.32.19961111223554.0090f358@moe.corollary.com> X-Sender: billf@moe.corollary.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 14:35:54 -0800 To: ibis@vhdl.org (ibis @vhdl.org) From: Bill Fleites Subject: unsubscribe Please unsubscribe me from the IBIS reflector. Thank you ! Regards, Bill Fleites From owner-ibis Tue Nov 12 03:56:50 1996 Received: from melcogw.melit.melco.co.jp (melcogw.melit.melco.co.jp [192.218.140.35]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id DAA24296; Tue, 12 Nov 1996 03:56:47 -0800 (PST) Received: by melcogw.melit.melco.co.jp (5.65+1.6W/2.7W) id AA15971; Tue, 12 Nov 96 20:45:42 JST Received: from bhb003 by inetgw.topo.melco.co.jp (1.38.193.5/6.4J.6-inetgw1.0) id AA08971; Tue, 12 Nov 1996 20:45:33 +0900 Received: from ss12 by bhb003.hoku.melco.co.jp (16.8/6.4J.6-hoku01) id AA03745; Tue, 12 Nov 96 20:36:33 +0900 Received: from [161.5.3.79] by ss12.memg2.hoku.melco.co.jp (4.1/6.4J.6-memg2-941124) id AA18000; Tue, 12 Nov 96 20:55:02 JST Date: Tue, 12 Nov 96 20:55:01 JST Message-Id: <9611121155.AA18000@ss12.memg2.hoku.melco.co.jp> To: scotts@actel.com (Scott Schlachter) From: nakamae@memg2.hoku.melco.co.jp (nakamae midori) Subject: Re: Question about Re: Serious s2ibis problem? Cc: bob@icx.com, ibis@vhdl.org, ibis-users@vhdl.org X-Mailer: Eudora-J(1.3.8.5-J13) Hello Scott, Thank you for your response. I have been using s2ibis2 version 0.91BETA in this 6 months and have developed about more than 10 IBIS models for memory device. Is it the latest version of s2ibis2 ? Is this version of s2ibis2 different from yours ? My setting of .s2i command file for s2ibis2 shows below. (DQ-buffer is 3-state type IN/OUT(bi-directional) buffer.) ( .s2i command file) --------------------------------------------- [Pin] |pin_name spice_node signal_name model_name 1 23 DOUT DQ_BUF -> input ena 2 2 VDD POWER 3 0 GND GND input 15 DATA DUMMY1 ena 9 ENABLE DUMMY1 | | [Model] DQ_BUF [Model type] 3-state [Polarity] Non-Inverting [Enable] Active-High ------------------------------------------------ Here,when ENABLE is Active-High,I modify my SPICE netlist (.sp file) to tie ENABLE pin thru a resistor(10Kohm and so on) to GND. (It means to set the buffer to be disable.) GND ----- resistor -----ENABLE ----> (to DQ-buffer control) Because,though s2ibis2 set voltage to ena pin for pullup/pulldown (for example,VENAS2I 21 0 DC 0),it does not set for output disable .spi files (for example, ddnout1.spi, ddtout1.spi and ddxout1.spi). I wonder why s2ibis2 does not set voltage for output disable simulation automatically. Then I was able to get the normal end of s2ibis2 program. And It seem s2ibis2 generate a good Pulldown/Pullup tables according to IBIS V2.1 spec.,if my assumptions are right. If you have any other informations concerning s2ibis2 algorythm , please let me know. Thank you. And I insert my another comments below. (P.S.)I don't receive NCSU or IBIS FORUM response yet, though I understand NCSU peoples are busy. I hope that IBIS OPEN FORUM ask some EDA vendor to support and update a s2ibis2 program as well as IBIS simulators. Best Regards, Midori Nakamae Mitsubishi Electric Corp. JAPAN At 10:32 AM 96.11.11 -0800, Scott Schlachter wrote: >Nakamae, > >I have also been using s2ibis to generate IBIS files, and I have talked >to many people about the algorythm that it uses to generate the >tables. Your assumptions apear to be correct, including what you asked >about how the simulators sum the clamp curve data to the pull-up and >pull-down data when the output buffer is active (non-tristate). If you >are using s2ibis (not s2ibis2), then you can also read about the >algorythm that s2ibis uses in the FAQ file, under the /src directory >that gets created when you untar the s2ibis program. > >As for how s2ibis deals with you n-channel pull-up, it really sounds >like it is not set up correctly. You should be getting big values >in your power-clamp curve - and you are getting zeros! s2ibis performs >no subtraction to the power-clamp data that it gets from the spice run >that it performs. It records this data directly to the [Power-clamp] >table in the created .ibs file (after it shifts all of the voltage >values to represent the Vtable = Vcc - Vout requirement). > >If you want to see exactly what the signals are for the Power-clamp (and >what the spice file looks like), look under the file pc.spi, >and the corresponding pc.out output file. For example, >if your pin-name is "One", than the files would be pcOne.spi, and >pcOne.out . These files will only be left behind if you DON'T have the >*[Cleanup] command in your s2ibis input file! > Yes,I know. Thanks. >I would start by examining the FAQ and also the pc---.spi files. If you >don't have the FAQ, let me know and I can email it to you. There has >been a lot of discussion lately in the IBIS community that we should not >bother the people at NCSU too much about the s2ibis programs, as 1) they >provided them for free to the IBIS community, 2) they don't really >have the money or man-power to support the programs (and they never >said they would support them), and finally 3) Alan Glaser and others >there are busy trying to finalize the s2ibis2 program with what little >amount of funds they have. Yes,I understand. > >Hope this helps, >-Scott Schlachter > Design Engineering > Actel Corporation > From owner-ibis Tue Nov 12 16:03:04 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA15988 for ; Tue, 12 Nov 1996 16:03:00 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Tue, 12 Nov 96 15:51 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 12 Nov 96 15:51 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 12 Nov 96 15:53 PST Message-Id: Date: Tue, 12 Nov 96 15:53 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 11/8/96 DATE: November 12, 1996 SUBJECT: 11/08/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann*, Tim Minnick, Russ Moser, Ray Ziesse*, Jeff Walden* Applied Simulation Technology Dileep Divekar*, Norio Matsui, Antonis Orphanou (formerly Contec) Cadence Design C. Kumar* Cypress Bruce Wenniger Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier, Ralf Bruening Intel Corporation Stephen Peters*, Will Hobbs, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet, [Donald Telian], Jim Kruchowski Interconnectix, Inc. Bob Ross*, Chris Reid Meta-Software (Sanjay Gangal) Mitsubushi Tam Cao, Hoang Nguyen Motorola Ahmed Omer National Semiconductor Syed Huq*, [Donald Snyder], Chune-Sin Yeh, [Bill Aronson] NCR (formerly ATT-GIS) Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell, Chris Rokusek* Quantic Laboratories (Mike Ventham) Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia* Veribest Ian Dodd*, David Wiens VLSI Technology Dick Ulmer, Sung Oh, Swami Gangadharan, Daniel Kim, Tom Dockery, D.C. Sessions, Hrish Patel Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: 3M Fran Hart, George Hare Actel Steve Schlachter* Alcatel John Fitzpatrick Altera Vadim von Brzeski Apteq Design System Dan FitzPatrick Compaq Mark Leonard Digital Equipment Corp. Jeff Chu EIA Patti Rusher IC Works Eric Chen Mentor Graphics Kim Owen Micron Technology Brian Johnson MicroSim Ralph Perez Molex Gus Panella North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao Philips Semiconductor Mike Magdaluyo Rockwell Collins Thomas Thurman S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Symmetry Andy Hughes Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison VTC, Inc. Bob Ward Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Participants who have joined another organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 12/06/96 (916) 356-9200 4-35933 6785885 1/10/97 (916) 356-9200 4-35934 5448699 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS Scott Schlachter of Actel has started developing IBIS files for customers and is getting IBIS information to ramp up on all aspects of IBIS. His initial concern is correlating IBIS with measurements from silicon. EIA MEMBERSHIP AND TREASURER'S REPORT Bob Ross indicated that the ledger remains at $9,285 with some deductions pending. MINUTES REPORT, MISC. No changes, all AR's done with Ian Dodd still planning his s2ibis postings and C. Kumar providing more test load discussions. MISCELLANY/ANNOUNCEMENTS None. PRESS AND WEB PAGE UPDATES Bob Ross reported references to IBIS in "Analysis Tools Target PC-Board Design-Cycle Front End" in Electronic Design, October 24, 1996, pp. 40-50. Also, "Tackling the Models Problem" in "Printed Circuit Design, November 1996, pp.14-17 and a VeriBest reference on pg. 36. NEW MODELS Arpad Muranyi plans to submit more Intel models. Jon Powell sent out a reflector note that National has a revised gp612mea.ibs file and Syed Huq sent out a note about a new dp83840a.ibs file on the National "lan" Web page. Bob Ross reported that the IDT shows a list of IBIS models under http://www.idt.com/cross_pl/models/ibs.html OPENS FOR NEW ISSUES Chris Rokusek on Cookbook Ian Dodd on s2ibis Bob Ross on reflector technical issues (covered throughout) DESIGN SUPERCON97 IBIS SUMMIT MEETING Bob Ross asked and received consensus that National Semiconductor be formally chosen as the host company at the Design SuperCon97 IBIS face-to-face meeting on Monday, January 20, 1997 in Santa Clara, California. Later, Syed Huq reported that he will make the local arrangements and will send information on the IBIS reflector. It will be an all day session, probably from 8 AM to 5 PM and either at a hotel or at National. Syed will supply names of local hotels. Syed indicated that there will be technical sessions including those on model development experiences. Soft copies will be put on the vhdl.org directory, and Syed will take care of making copies of presentations to distribute to participants. Bob asked that people who would like to give presentations contact Syed with the topic and time needed. Most presentations are expected to be in the 10 to 20 minute range to promote discussion. Bob and Syed will organize the topics and create the meeting agenda. Stephen Peters asked if our goal is to approve Version 3.0 at that meeting. Bob responded that that would be a good target, but Version 3.0 might get delayed pending how the Electrical Interconnect Description proposal evolves. AR - Syed send out information on the January IBIS Summit meeting. DAC97 PLANNING Bob Ross reported that Patti Rusher has asked for a commitment on whether EIA organizations including the IBIS Open Forum will participate in the booth at DAC97. The minimum level of participation costs $2500 and allows us to show a poster. EIA will have a full booth, as last year. We could supply literature. Bob recommended that we go ahead and commit to this since there is great benefit in being supportive of all standards. Besides, the IBIS Open Forum has received tremendous help from being associated with EIA including administrative help, assistance and credibility to promote IBIS through the national and international standardization processes. Patti Rusher can arrange the IBIS meeting room once we set the date. Stephen Peters questioned how much traffic existed at DAC. Bob did not know. We can still have the "We Like IBIS" and "IBIS Spoken Here" signs at booths. Also we can still investigate having our own booth at some remote location at DAC. We will seek official approval at the next meeting. IEC PROGRESS Patti Rusher has indicated to Bob Ross that she believes IBIS is progressing smoothly. S2IBIS PLANS Bob Ross reported that he had briefly reviewed a new Beta version of s2ibis2 (Version 0.99). Bob felt that it should be put on vhdl.org where others could check the improvements. Reported problems have been addressed, and Spectre support has been added. A number of crash problems from memory leaks have been resolved. Format confusion associated with data that exceeds the numerical scale factor limits has been solved by converting the data to scientific notation. A make file for other platforms including Windows, DOS, AIX, etc has been added, although Alan Glaser is unable to test this. The version will be put on vhdl.org as soon as it is packaged. Scott Schlacter brought up his questions concerning the extrapolation algorithm. Bob mentioned that there was a reason for the algorithm, and he will put a response on the IBIS reflector. Other technical discussion occurred. Scott suggested a subdirectory for s2ibis fixes. After some discussion, Bob felt that we will do that only if there is need. Currently, however, the ibis-users@vhdl.org reflector should be used to report and discuss bugs and get help. Syed Huq, in addition to testing, said he would keep tabs of the bugs. We will send information including any suggested fixes back to NCSU so they can maintain control any source code extensions. Ian Dodd indicated that he is still exploring releasing the Veribest version of Spice to IBIS with some bug fixes and support for NT. This could either be put on vhdl.org or on the Veribest Web site. He still needs to send out a list of bugs/fixes he has done to s2ibis2. COOKBOOK for 2.1 Chris Rokusek raised the point that we have resolved a number of issues as Cookbook additions, but there is no IBIS Version 2.1 Cookbook. One example might be recommended test loads for [Rising Waveform] and [Falling Waveform] keywords. While Version 2.1 supports any test load, the silicon vendor needs guidance of what works best for simulation. Most likely, resistive test loads at various voltages will give the best results. The simulator vendors can supply to Chris what they consider the best test loads. Chris believes that test loads at ground and Vcc were best, with a third test load at the midpoint voltage for validation. Stephen Peters plans an internal Intel Cookbook and can supply a sanitized version to the IBIS Committee by the end of the year. Chris volunteered to head the Cookbook effort and compile the results. Bob Ross will put this on the agenda for regular reports. Chris should work with Kellee Crisafulli, Bob, Stephen and anyone else. BIRD38 - MAXIMUM VOLTAGE Bob Ross called for a vote on BIRD38, which the Specification Committee had recommended be rejected since the contents were covered in BIRD39. BIRD38 was disapproved by unanimous vote. BIRD39 - SPECIFICATION ENHANCEMENT Bob Ross introduced BIRD39 that adds the optional [Model Spec] keyword for adding min and max thresholds, a set of hysteresis thresholds, static and dynamic overshoot and pulse immunity. Dileep Divekar had raised an e-mail question concerning the need for husteresis thresholds, and he was satisfied with the response. Bob also expressed some personal concerns on whether vendors would actually test for pulse immunity. However, there was value in providing a format for this information. Dave Moxley questioned that the overshoot words may be similar to RAIL, but may have different meanings. Bob stated that in RAIL, the overshoot has a different purpose, it is a design rule that may not necessary correlate with any specification value. For example, no overshoot beyond a rail could be specified to force a net to be terminated. BIRD39 was approved by unanimous vote. PACKAGE COMMITTEE REPORT Stephen Peters started the discussion by noting that BIRD36.c was a working proposal to get feedback. It covered only single line models and boards. Coupled models are set aside until some single line issues are resolved, but coupled models are intended to be included. The new name is electrical interconnect descripion (.eid). It includes SIMM models and also for connectors, Min_edge_time and capacitances. I includes the BIRD28.3 and extensions of Fork and EndFork and Pins, Nodes (and reference designators) and Paths. Dileep Divekar raised some questions on the reflector. Hank Herrmann's intended reflector response bounced (possibly due to an AMP mailer change). Hank covered Dileep's comments point-by-point. A synopsis of items covered in Hank's response are: - The numerical limits are minimums for simulator design guidance. - Pin ordering may be needed to identify input and output pins and possible internal references - this needs to be examined. - The suggestion of including G needs to be considered, but there are frequency dependencies and effects that might be beyond the scope of the analysis at this time. Also, we have yet to consider coupled matricies. - The phrase "backslash" needs to be changed to "slash". Also we need to review BIRD37.3 for this correction. [Note - This has been corrected in BIRD37.3 and in wip Version 3.0 drafts.] - Hank agreed that if the Len is not "0" to indicate a discrete component, then both L and C entries are required to create a distributed model. - NC as a method to terminate Paths internally needs to be reexamined to see if it is necessary. - The ref.designator syntax change from, for example, 17.U3 to U3.17 seems reasonable based on standard practice. Other discussions covered the capacitive global ground assumption appropriate for single line models and whether traces could split on the board and join at a different location. Stephen again invited anyone to participate in the Package Committee meetings where these issues are considered in depth. Stephen will publish the minutes on the ibis@vhdl.org relector for information. AR - Bob Ross send out Hank's response [Done]. AR - Stephen Peters set up the Package Committee meeting again for Friday, 8:30 AM to 10 AM. BIRD35.2 - MULTI-STAGED OUTPUTS Bob Ross introduced BIRD35.2 proposing a scheduling method for calling other models for multi-staged output. A number of silicon vendors have devices which physically use phased switching. There has been a lot of reflector discussion on this subject. Bob feels that, as Greg Edlund had wrote, that it would be nice to show a simulation with and without multi-staged switching. Chris Rokusek was not aware of any possible objections to the proposed format. C. Kumar raised some valid concerns that there really may be a very strong dependency on which simulator is used. We did not have time to go into much detail, and this discussion needs to continue on the reflector. Stephen Peters suggested a "golden waveform" for the composite response and have it as part of the [Model] from which the [Driver Schedule] keyword is inserted. BIRD35.2 is scheduled for a vote at the next meeting. PARSER ADDITIONS FOR NUMERICAL CHECKING Chris Rokusek stated that he has implemented all of the proposed changes. He did not know what percentage to select for accuracy and Bob Ross indicated that 2 percent would be a good start. Also, Bob would like the executables built with Static links for broader distribution. Ian Dodd volunteered to help test the code on NT and Windows95 in response to Chris' request for assistance. NEXT MEETING: The next meeting is on Friday, December 6, 1996, 8:00 A.M. to 9:55 A.M. BIRD35.2 is scheduled for a vote. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Sat Nov 16 08:57:11 1996 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id IAA02376 for ; Sat, 16 Nov 1996 08:57:10 -0800 (PST) Received: from robin.itg.ti.com ([172.25.2.75]) by dragon.ti.com (8.6.13) with ESMTP id KAA08797 for ; Sat, 16 Nov 1996 10:45:41 -0600 Received: from itg.ti.com (magic.itg.ti.com [172.25.2.76]) by robin.itg.ti.com (8.7.3/8.6.11) with SMTP id KAA27459 for ; Sat, 16 Nov 1996 10:45:09 -0600 (CST) Received: from dadsparc4.india.ti.com by itg.ti.com (4.1/ITG-1.1) id AA22564; Sat, 16 Nov 96 10:45:05 CST Received: from holmes.india.ti.com (holmes.india.ti.com [134.183.191.57]) by dadsparc4.india.ti.com (8.6.12/8.6.10) with ESMTP id WAA02468 for ; Sat, 16 Nov 1996 22:14:51 +0500 Received: (from aargee@localhost) by holmes.india.ti.com (8.6.12/8.6.10) id LAA10933; Sat, 16 Nov 1996 11:17:24 -0600 Date: Sat, 16 Nov 1996 11:17:24 -0600 Message-Id: <199611161717.LAA10933@holmes.india.ti.com> From: Geetha R To: ibis@vhdl.org Subject: Error Msg of Golden Parser Hello Ibisians, While running the Golden Parser (ibischk2) on some of my .ibs files, it gives an error message. > ERROR - Unable to assemble filename I found that this error occurs only when the pathname to the final ibis file is long. Error occurs if : ibischk2 /<.ibs file> No Error if: ibischk2 <.ibs file> Is there a constraint in the Golden Parser on how big the absolute pathname of the input ibis file can be ? Sorry for the trouble if this has already been clarified earlier in the forum. Any help will be appreciated. * Best Regards, email: aargee@india.ti.com * * Geetha Rangarajan, msgid: GR3 (for TI only) * * Software Design Engineer, phone: 5269451 extn: 163 * * EDA Systems Organisation, * * TII, Bangalore * **************************************************************** From owner-ibis Sat Nov 16 15:07:10 1996 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA05108 for ; Sat, 16 Nov 1996 15:07:09 -0800 (PST) Received: (from kellee@localhost) by montana.nwlink.com (8.8.2/8.7.3) id OAA02734; Sat, 16 Nov 1996 14:56:11 -0800 (PST) Message-Id: <2.2.32.19961116224748.006fd6e0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 16 Nov 1996 14:47:48 -0800 To: Geetha R , ibis@vhdl.org From: Kellee Crisafulli Subject: Re: Error Msg of Golden Parser Hi Greetha, >Is there a constraint in the Golden Parser on how big the absolute >pathname of the input ibis file can be ? I believe there is. I encorporated the ibischk2 code into our Visual IBIS Editor and as I recall I did have to make the path length string large when I ported it to windows. If it is of use; the Visual IBIS Editor is available free on the net at www.hyperlynx.com. --------------------------------------------------------------- Have a great day...Kellee Crisafulli, HyperLynx Inc. --------------------------------------------------------------- From owner-ibis Tue Nov 19 10:07:52 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA22846 for ; Tue, 19 Nov 1996 10:07:51 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id JAA09130 for ; Tue, 19 Nov 1996 09:57:38 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma008819; Tue Nov 19 09:57:12 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA07662 for ibis@vhdl.org; Tue, 19 Nov 96 09:56:15 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA13495; Tue, 19 Nov 96 09:57:33 PST Date: Tue, 19 Nov 96 09:57:33 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9611191757.AA13495@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS face to face meeting Jan20th'97 Cc: huq@rockie.nsc.com IBISfans, The ANSI/EIA-656 IBIS committee will have a face to face meeting this Jan20th '97 Monday in Santa Clara, CA before Design SuperCon97(Jan21-23). National Semiconductor will host the all day meeting. Details of the meeting place, directions will be provided on this reflector. Last year, our meeting was a great success with over 35 companies participating. Since Hotels tend to fill up fast in the bay area. I am providing you with a listing. You may make your own Hotel arrangements. Stay tuned for more detailed information about the Jan20th'97 IBIS meeting. Hotel Information: ------------------- Pls make your reservations as soon as possible. Certain Hotels tend to fill up due to various events going on. Wyndham Garden Hotel 1300 Chesapeake Terrace Sunnyvale (408)747-0999 Santa Clara Marriott Hotel 2700 Mission College Blvd Santa Clara (408)988-1500 Quality Suites 3100 Lakeside Drive Santa Clara (408)748-9800 Days Inn 4200 Great America Parkway Santa Clara (408)980-1525 Westin Hotel 5101 Great America Parkway Santa Clara (408)986-0700 Embassy Suites 2885 Lakeside Drive Santa Clara (408)496-6400 If you need any other assistance or questions you may have, let me know. Best Regards, Syed. Vice-Chair ANSI/EIA-656 National Semiconductor Corp. (408)721-4874 From owner-ibis Wed Nov 20 06:43:04 1996 Received: from natashya.eden.com (root@natashya.eden.com [199.171.21.14]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id GAA17921 for ; Wed, 20 Nov 1996 06:43:03 -0800 (PST) Received: from net-4-129.austin.eden.com (net-4-129.austin.eden.com [206.81.226.129]) by natashya.eden.com (8.8.3/8.8.1) with SMTP id IAA08314 for ; Wed, 20 Nov 1996 08:31:56 -0600 (CST) Message-Id: <199611201431.IAA08314@natashya.eden.com> Date: Wed, 20 Nov 1996 08:37:09 -0800 From: Russell Rapport <"rrapport@eden.com"@realtime.net> Reply-To: "rrapport@eden.com"@realtime.net X-Mailer: Mozilla 3.0Gold (Win16; I) MIME-Version: 1.0 To: ibis@vhdl.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please unsubscribe me at this address and add a subscription to russellr@realtime.com. From owner-ibis Thu Nov 21 09:15:49 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA16260 for ; Thu, 21 Nov 1996 09:15:47 -0800 (PST) Received: from uucp3.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp3.UU.NET [192.48.96.34]) id QQbquu16436; Thu, 21 Nov 1996 12:04:15 -0500 (EST) Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 21 Nov 1996 12:04:15 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00767; Thu, 21 Nov 96 08:58:20 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA17721; Thu, 21 Nov 96 08:58:20 PST Sender: jonp@qdt.com Message-Id: <32948A2C.794BDF32@qdt.com> Date: Thu, 21 Nov 1996 08:58:20 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Syed Huq , ibis@vhdl.org Subject: Re: Avoiding Double Counting References: <9611210130.AA08834@rockie.nsc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I you do not specify the appropriate VI curves for the clamps then the device cannot be tri-stated in the simulation. There are also devices that drive the clamps to different rails (3v devices do this at times). There is also the possibility of the high or low clamp being driven when the device is in the opposite state (low or high). Though unusual, it could happen. If none of these things are a concern then you can combine the clamps. ps: At Quad design, we do not explicitly combine the curves unless the data is non-monotonic. We do not believe that this is always appropriate and that is why I was always against the non-monotonic data in the un-combined waveforms. (though I "gracefully" bowed to public opinion). Jon From owner-ibis Thu Nov 21 11:55:19 1996 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id LAA17760 for ; Thu, 21 Nov 1996 11:55:19 -0800 (PST) Received: (from kellee@localhost) by montana.nwlink.com (8.8.2/8.7.3) id LAA10340; Thu, 21 Nov 1996 11:44:17 -0800 (PST) Message-Id: <2.2.32.19961121193545.006fe27c@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 11:35:45 -0800 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Re: Avoiding Double Counting At 05:30 PM 11/20/96 PST, you wrote: > >It seems that we go thru too much data crunching and Simulators >simply connect the two tables anyway. > >Possible I am missing something very important here. Pls comment. > If as a model developer you can separate the diode characteristics from the output characteristics than you should create two separate tables. If you cannot separate them than only a single table is needed. The reason there are two tables is so the simulators can treat the clamp diodes more accurately and have data on the clamp diode. So... it may be that your method of creating IBIS models does not allow you to separate the clamp diode from the output buffer and that is ok. The simulators can do a slightly better job modeling if clamp diode information is separate and truly represents the clamp diode. --------------------------------------------------------------- Have a great day...Kellee Crisafulli, HyperLynx Inc. --------------------------------------------------------------- From owner-ibis Fri Nov 22 12:14:53 1996 Received: from typhoon.dial.pipex.net (typhoon.dial.pipex.net [158.43.128.46]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA15019 for ; Fri, 22 Nov 1996 12:14:49 -0800 (PST) Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET PIPEX simple 1.28) id QAA22072; Fri, 22 Nov 1996 16:17:56 GMT Received: from typhoon.dial.pipex.net by maelstrom.dial.pipex.net (8.8.2/) id QAA07928; Fri, 22 Nov 1996 16:14:32 GMT Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET PIPEX simple 1.28) id QAA21850; Fri, 22 Nov 1996 16:13:04 GMT Received: from henty by maelstrom.dial.pipex.net (8.8.2/) id QAA07402; Fri, 22 Nov 1996 16:13:36 GMT Message-ID: <3295D067.5EDE@quantic.mb.ca> Date: Fri, 22 Nov 1996 16:10:15 +0000 From: Mike Ventham Reply-To: ventham@quantic.mb.ca Organization: Quantic Laboratories Inc X-Mailer: Mozilla 3.0Gold (WinNT; I) MIME-Version: 1.0 To: ibis@vhdl.org Subject: Use of femto scaling in IBIS models Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ibisians, I have recently found a problem in the parser which affects both versions of the parser when parsing version 1.x IBIS models which contain values scaled using the femto(f) prefix. As far as I know this only affects Intel models as everyone else uses unscaled number in engineering/scientific format. According to the IBIS 1.1 spec, the prefix f is not a legal prefix, pico is the smallest allowed. As the Intel model is set as version 1.1 it is not a valid IBIS model. Also the IBIS2.1 parser does not pick it up as it uses the IBIS v1.1 parser checker. Illegal scale characters in the IBIS file are set to ' ' i.e. scale=1.0 without any error message. I fiexed it by adding the character f to the known_scales array i.e Mkmunp -> Mkmunpf If the IBIS version in the file is set to 2.1 it will work OK as f is recognised. This should only affect simulated models, as measured models are somewhat difficult to measure to that degree of accuracy. I did once see currents of magnitude e+41 in an Intel model which I presumed was simulated otherwise most of California would have been blacked out! Here is a supplementary question. Why is not having the same file name as that in the file classified as an error rather than a warning? Even if the file has the right name and you access it through a full path name you get the error. Regards Mike -- ********PLEASE NOTE NEW ADDRESS AND FAX NUMBER ***************** | Mike Ventham - Vice-President Engineering, | | Quantic Laboratories Inc Headquarters | | Croft House, Chilcompton, 191 Lombard Ave, Winnipeg, | | Somerset, UK, BA3 4JA Manitoba, Canada R3B 0X1 | | Tel: 44 (0)1761 232191 Tel: (204) 942 4000 | | Fax: 44(0)1761 233549 Fax: (204) 957 1158 | | Email: ventham@quantic.mb.ca | From owner-ibis Fri Nov 22 14:20:55 1996 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA16056 for ; Fri, 22 Nov 1996 14:20:55 -0800 (PST) Received: (from kellee@localhost) by montana.nwlink.com (8.8.2/8.7.3) id OAA18891; Fri, 22 Nov 1996 14:09:52 -0800 (PST) Message-Id: <2.2.32.19961122220103.006ff9b0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 14:01:03 -0800 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Re: naming in IBIS models Hi Mike, At 04:10 PM 11/22/96 +0000, you wrote: >Why is not having the same file >name as that in the file classified as an error rather than a warning? >Even if the file has the right name and you access it through a full >path name you get the error. >Mike > One reason I have heard a few times is that a few companies that are constructing models want insurance that the names are not changed so they have more control over naming their own models. On the other hand I don't know that many simulator companies have enforced this requirement in their IBIS reader. The HyperLynx simulation tools don't care what the name is. On the other hand our Visual IBIS editor uses the "standard" IBIS parser code and it does report this as an error if the syntax checker is run. --------------------------------------------------------------- Have a great day...Kellee Crisafulli, HyperLynx Inc. --------------------------------------------------------------- From owner-ibis Fri Nov 22 17:49:07 1996 Received: from hotmail.com (delivery.hotmail.com [206.86.127.236]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA17628 for ; Fri, 22 Nov 1996 17:49:07 -0800 (PST) Received: (http://www.hotmail.com 10194 invoked by uid 0); 23 Nov 1996 01:38:05 -0000 Date: 23 Nov 1996 01:38:05 -0000 Message-ID: <19961123013805.10193.qmail@hotmail.com> Received: from 206.86.127.195 by www.hotmail.com with HTTP; Fri, 22 Nov 1996 17:38:05 PST From: "Jin Man Han" To: ibis-users@vhdl.org Cc: ibis@vhdl.org Subject: I/O switching current? Content-Type: text/plain Hi, I hope somebody can answer this question. Doesn't IBIS have to specify I/O switching current? I think this information is crucial in estimating real situation 'cause given similar I/V characteristics and rise/fall time, I/O switching current can be significantly different. Min/max I/O switching current should be specified in IBIS, I think. Thanks in advance. --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- From owner-ibis Mon Nov 25 10:18:24 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA03398; Mon, 25 Nov 1996 10:18:20 -0800 (PST) Received: from uucp5.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp5.UU.NET [192.48.96.36]) id QQbrjs25435; Mon, 25 Nov 1996 13:04:41 -0500 (EST) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Mon, 25 Nov 1996 13:04:44 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00817; Mon, 25 Nov 96 09:17:51 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09927; Mon, 25 Nov 96 09:17:50 PST Received: from uucp6.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp6.UU.NET [192.48.96.37]) id QQbrjo01557; Mon, 25 Nov 1996 12:06:26 -0500 (EST) Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 25 Nov 1996 12:06:27 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00640; Mon, 25 Nov 96 08:37:05 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA09450; Mon, 25 Nov 96 08:37:04 PST Sender: uunet!qdt.com!jonp@uunet.uu.net Message-Id: <3299CB2F.6201DD56@qdt.com> Date: Mon, 25 Nov 1996 08:37:03 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.3 sun4c) Mime-Version: 1.0 To: Jin Man Han Cc: uunet!uunet!vhdl.org!ibis-users@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net Subject: Re: I/O switching current? References: <19961123013805.10193.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jin Man, If you use the VT curves in the IBIS 2.1 model, it does specify switching current. It just does it in a behavioral fashion using voltage versus time into different loads. If the loads are properly chosen for the target technology it is possible to simulate SSO and other current switching effects. Jon Powell Quad Design From owner-ibis Mon Nov 25 14:55:12 1996 Received: from crl.dec.com (crl.dec.com [192.58.206.2]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA05904 for ; Mon, 25 Nov 1996 14:55:10 -0800 (PST) From: chu@rock.enet.dec.com Received: by crl.dec.com; id AA08611; Mon, 25 Nov 96 17:41:49 -0500 Received: by easynet.crl.dec.com; id AA02399; Mon, 25 Nov 96 17:41:48 -0500 Message-Id: <9611252241.AA02399@easynet.crl.dec.com> Received: from rock.enet; by crl.enet; Mon, 25 Nov 96 17:41:48 EST Date: Mon, 25 Nov 96 17:41:48 EST To: ibis@vhdl.org Cc: chu@rock.enet.dec.com Apparently-To: ibis@vhdl.org Subject: Spice to IBIS Verification Loop Hi: I am interested in knowing if anyone has generated an IBIS model using the Spice to IBIS conversion program by NCSU and simulated the resulting IBIS model in any of the commerically available IBIS simulators and compare the Spice vs. IBIS simulator results. I have done a complete verification loop and found significant discepancy between the two results. If I believe my Spice outputs, either the IBIS model or the simulator is not correct. Or could be the other way around as well. I would like to know if anyone has similar experience and willing to share some of your discoveries. I would love to hear from you. Thank you Jeff Chu Digital Equipment Corp. 77 Reed Road Hudson, MA 01749 (508)568-4197 (508)568-5195 (fax) From owner-ibis Tue Nov 26 17:18:00 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id RAA13655 for ; Tue, 26 Nov 1996 17:17:59 -0800 (PST) Received: from uucp1.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp1.UU.NET [192.48.96.32]) id QQbrom23674; Tue, 26 Nov 1996 20:07:10 -0500 (EST) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Tue, 26 Nov 1996 20:06:51 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00224; Tue, 26 Nov 96 16:05:04 PST Received: from awacs by hal.qdt.com (4.1/SMI-4.1) id AA24669; Tue, 26 Nov 96 16:04:58 PST Sender: crokusek@qdt.com Message-Id: <329B85A8.3F54BC7E@qdt.com> Date: Tue, 26 Nov 1996 16:04:56 -0800 From: Chris Rokusek Organization: Quad Design Technology X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Subject: 1.x vs 2.x Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, The current ibischk2 has a switch inside that upon reading a 1.x ibis file checks if differently (using the older checks) than a 2.x file. If we are truly backward compatible (are we?) then shouldn't we parse and test all .ibs files for the current revision (now 2.1) regardless of the file's ibis version. Q: Should a 2.x parser be able to read 1.x or not? Thanks, -Chris Rokusek From owner-ibis Tue Nov 26 17:35:48 1996 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA13851 for ; Tue, 26 Nov 1996 17:35:47 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id RAA02842; Tue, 26 Nov 1996 17:24:46 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma002789; Tue Nov 26 17:24:41 1996 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA07544 for ibis@vhdl.org; Tue, 26 Nov 96 17:24:25 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA07408; Tue, 26 Nov 96 17:25:52 PST Date: Tue, 26 Nov 96 17:25:52 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9611270125.AA07408@rockie.nsc.com> To: ibis@vhdl.org, crokusek@qdt.com Subject: Re: 1.x vs 2.x Chris, One example: IBISv1.1 parser allows tab characters in the model file. IBISv2.1 does not allow that and the parser gives a Warning. So, if a model file is v1.1, things like checks for tabs are ignored by the parsar. Regards, Syed. > > Hi All, > > The current ibischk2 has a switch inside that upon reading a 1.x ibis > file checks if differently (using the older checks) than a 2.x file. > > If we are truly backward compatible (are we?) then shouldn't we parse > and test all .ibs files for the current revision (now 2.1) regardless of > the file's ibis version. > > Q: Should a 2.x parser be able to read 1.x or not? > > Thanks, > > -Chris Rokusek > From owner-ibis Tue Nov 26 17:53:33 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id RAA13965 for ; Tue, 26 Nov 1996 17:53:33 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.3/8.7.3) with ESMTP id RAA29291 for ; Tue, 26 Nov 1996 17:42:21 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id RAA12303; Tue, 26 Nov 1996 17:42:04 -0800 (PST) Message-Id: <199611270142.RAA12303@ichips.intel.com> To: ibis@vhdl.org Subject: 1.x vs 2.x Date: Tue, 26 Nov 1996 17:42:23 -0800 From: Stephen Peters Hello Chris: If what your asking is "should a 2.x parser should be able to read 1.x files using the newer code" the answer should be yes. However, if I remember correctly the decision was made to continue using the older parser code for 1.x files to make absolutly sure we were backwards compatable. There may have been some small incompatablitly between the two versions, but I don't recall specifically. Hope that helps. Regards, Stephen Hi All, The current ibischk2 has a switch inside that upon reading a 1.x ibis file checks if differently (using the older checks) than a 2.x file. If we are truly backward compatible (are we?) then shouldn't we parse and test all .ibs files for the current revision (now 2.1) regardless of the file's ibis version. Q: Should a 2.x parser be able to read 1.x or not? Thanks, -Chris Rokusek From owner-ibis Tue Nov 26 19:44:18 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id TAA14709 for ; Tue, 26 Nov 1996 19:44:17 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 27 Nov 1996 03:33:13 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id TAA26779 for ibis@vhdl.org; Tue, 26 Nov 1996 19:31:02 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 26 Nov 96 19:31:02 PST Date: Tue, 26 Nov 96 12:29:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re: Use of femto scaling in IBIS models Text item: Mike, Thanks for the information. This issue is clearly an oversight on my part. When I wrote our tool that automates the process of generating IBIS models, I didn't check what the valid prefixes are in IBIS, so I coded my program to use all known prefixes available in the engineering world. Since then, I have a newer revision of the tool which uses engineering notation in the tables (only). Due to time limitations, I cannot commit to fix all the earlier models. One way of getting around the fA problem is to edit the file to be version 2.1, since it is legal in that spec. However, I question whether this is a spec or parser issue. I parsed the 1.1 IBIS file in question with both parsers just now, and neither one of them gave me an error. If this is illegal in 1.1, both parsers should have given me an error. This is why these prefixes slipped in to start out with... At one time we were debating whether in cases like this, when the parser didn't agree with the spec, which one should take precedence. If I remember correctly we voted for the parser. In this light, the Intel models are not illegal. (Someone correct me if I am wrong). So the question is, should we fix the parser, or change the spec to allow for all prefixes. In my opinion it doesn't make sense to have to say 0.01 pA for 10 fA and so on. Even though these kind of numbers are usually noise and outside the usually measurable range, I would still allow them for the sake of consistency and completeness. You never know, someone might even need them in some cases... (especially with capacitances). Arpad ================================================================================ Ibisians, I have recently found a problem in the parser which affects both versions of the parser when parsing version 1.x IBIS models which contain values scaled using the femto(f) prefix. As far as I know this only affects Intel models as everyone else uses unscaled number in engineering/scientific format. According to the IBIS 1.1 spec, the prefix f is not a legal prefix, pico is the smallest allowed. As the Intel model is set as version 1.1 it is not a valid IBIS model. Also the IBIS2.1 parser does not pick it up as it uses the IBIS v1.1 parser checker. Illegal scale characters in the IBIS file are set to ' ' i.e. scale=1.0 without any error message. I fiexed it by adding the character f to the known_scales array i.e Mkmunp -> Mkmunpf If the IBIS version in the file is set to 2.1 it will work OK as f is recognised. This should only affect simulated models, as measured models are somewhat difficult to measure to that degree of accuracy. I did once see currents of magnitude e+41 in an Intel model which I presumed was simulated otherwise most of California would have been blacked out! Here is a supplementary question. Why is not having the same file name as that in the file classified as an error rather than a warning? Even if the file has the right name and you access it through a full path name you get the error. Regards Mike -- ********PLEASE NOTE NEW ADDRESS AND FAX NUMBER ***************** | Mike Ventham - Vice-President Engineering, | | Quantic Laboratories Inc Headquarters | | Croft House, Chilcompton, 191 Lombard Ave, Winnipeg, | | Somerset, UK, BA3 4JA Manitoba, Canada R3B 0X1 | | Tel: 44 (0)1761 232191 Tel: (204) 942 4000 | | Fax: 44(0)1761 233549 Fax: (204) 957 1158 | | Email: ventham@quantic.mb.ca | Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: Use of femto scaling in IBIS models To: ibis@vhdl.org MIME-Version: 1.0 X-Mailer: Mozilla 3.0Gold (WinNT; I) Organization: Quantic Laboratories Inc Reply-To: ventham@quantic.mb.ca From: Mike Ventham Date: Fri, 22 Nov 1996 16:10:15 +0000 Message-ID: <3295D067.5EDE@quantic.mb.ca> Received: from henty by maelstrom.dial.pipex.net (8.8.2/) id QAA07402; Fri, 22 Nov 1996 16:13:36 GMT Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET PIPEX simple 1.28) id QAA21850; Fri, 22 Nov 1996 16:13:04 GMT Received: from typhoon.dial.pipex.net by maelstrom.dial.pipex.net (8.8.2/) id QAA07928; Fri, 22 Nov 1996 16:14:32 GMT Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET PIPEX simple 1.28) id QAA22072; Fri, 22 Nov 1996 16:17:56 GMT Received: from typhoon.dial.pipex.net (typhoon.dial.pipex.net [158.43.128.46]) b y vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA15019 for ; Fri, 2 2 Nov 1996 12:14:49 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.3/8.7.3) with ESMTP id MAA01881; Fri, 22 Nov 1996 12:09:19 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id MAA00672; Fri, 22 Nov 1996 12: 06:45 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Nov 27 06:11:04 1996 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id GAA07144 for ; Wed, 27 Nov 1996 06:11:03 -0800 (PST) Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA21445; Wed, 27 Nov 1996 08:50:11 -0500 (EST) Received: from wrksys.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA07842; Wed, 27 Nov 96 08:33:40 -0500 Message-Id: <9611271333.AA07842@us1rmc.bb.dec.com> Received: from wrksys.enet; by us1rmc.enet; Wed, 27 Nov 96 08:52:14 EST Date: Wed, 27 Nov 96 08:52:14 EST From: Andy Ingraham To: arpad_muranyi@ccm.fm.intel.com Cc: ibis@vhdl.org, ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org, arpad_muranyi@ccm.fm.intel.com Subject: Re: Use of femto scaling in IBIS models > At one time we were debating whether in cases like this, when the parser didn't > agree with the spec, which one should take precedence. If I remember correctly > we voted for the parser. In this light, the Intel models are not illegal. > (Someone correct me if I am wrong). I don't question what may have have been previously discussed ... but in my mind the only correct answer is that the spec ALWAYS takes precedence, no matter what you're talking about. If the spec and the parser disagree, you fix the parser. If you want the parser to have precedence, then make IT the standard with its source code freely available to the world, and make a note in the spec that it is only an example and to refer to the parser. > In my opinion it doesn't make sense to have to say 0.01 pA for 10 > fA and so on. Even though these kind of numbers are usually noise and outside > the usually measurable range, I would still allow them for the sake of > consistency and completeness. You never know, someone might even need them in > some cases... (especially with capacitances). I brought this issue up some two years ago with one or more of you. Will "a" come to mean "alto" (1e-18) some time in the future? (It already does on at least one simulator.) You need to get this nailed down firmly. Otherwise you don't have a spec. Regards, Andy From owner-ibis Wed Nov 27 09:17:35 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA08563; Wed, 27 Nov 1996 09:17:34 -0800 (PST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.3/8.7.3) with ESMTP id JAA10848; Wed, 27 Nov 1996 09:06:26 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.8.2/8.7.3) id JAA14641; Wed, 27 Nov 1996 09:06:24 -0800 (PST) Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Wed, 27 Nov 96 09:06:24 PST Date: Wed, 27 Nov 96 09:03:00 PST From: Will Hobbs Message-ID: To: owner-ibis@vhdl.org, ibis@vhdl.org Subject: Re[2]: Use of femto scaling in IBIS models Text item: Arpad, et al, I know that early on we talked of the parser as the "executable spec," but since we have gone through formal balloting, etc., of IBIS as an ANSI EIA specification, the written spec is the spec. Period. The parser should be as faithful to that spec as possible. If "f" has to be added to the spec, then so be it. That should be a 3.0 issue, and a Bird generated and voted on. Will Mike, Thanks for the information. This issue is clearly an oversight on my part. When I wrote our tool that automates the process of generating IBIS models, I didn't check what the valid prefixes are in IBIS, so I coded my program to use all known prefixes available in the engineering world. Since then, I have a newer revision of the tool which uses engineering notation in the tables (only). Due to time limitations, I cannot commit to fix all the earlier models. One way of getting around the fA problem is to edit the file to be version 2.1, since it is legal in that spec. However, I question whether this is a spec or parser issue. I parsed the 1.1 IBIS file in question with both parsers just now, and neither one of them gave me an error. If this is illegal in 1.1, both parsers should have given me an error. This is why these prefixes slipped in to start out with... At one time we were debating whether in cases like this, when the parser didn't agree with the spec, which one should take precedence. If I remember correctly we voted for the parser. In this light, the Intel models are not illegal. (Someone correct me if I am wrong). So the question is, should we fix the parser, or change the spec to allow for all prefixes. In my opinion it doesn't make sense to have to say 0.01 pA for 10 fA and so on. Even though these kind of numbers are usually noise and outside the usually measurable range, I would still allow them for the sake of consistency and completeness. You never know, someone might even need them in some cases... (especially with capacitances). Arpad =============================================================================== = Ibisians, I have recently found a problem in the parser which affects both versions of the parser when parsing version 1.x IBIS models which contain values scaled using the femto(f) prefix. As far as I know this only affects Intel models as everyone else uses unscaled number in engineering/scientific format. According to the IBIS 1.1 spec, the prefix f is not a legal prefix, pico is the smallest allowed. As the Intel model is set as version 1.1 it is not a valid IBIS model. Also the IBIS2.1 parser does not pick it up as it uses the IBIS v1.1 parser checker. Illegal scale characters in the IBIS file are set to ' ' i.e. scale=1.0 without any error message. I fiexed it by adding the character f to the known_scales array i.e Mkmunp -> Mkmunpf If the IBIS version in the file is set to 2.1 it will work OK as f is recognised. This should only affect simulated models, as measured models are somewhat difficult to measure to that degree of accuracy. I did once see currents of magnitude e+41 in an Intel model which I presumed was simulated otherwise most of California would have been blacked out! Here is a supplementary question. Why is not having the same file name as that in the file classified as an error rather than a warning? Even if the file has the right name and you access it through a full path name you get the error. Regards Mike -- ********PLEASE NOTE NEW ADDRESS AND FAX NUMBER ***************** | Mike Ventham - Vice-President Engineering, | | Quantic Laboratories Inc Headquarters | | Croft House, Chilcompton, 191 Lombard Ave, Winnipeg, | | Somerset, UK, BA3 4JA Manitoba, Canada R3B 0X1 | | Tel: 44 (0)1761 232191 Tel: (204) 942 4000 | | Fax: 44(0)1761 233549 Fax: (204) 957 1158 | | Email: ventham@quantic.mb.ca | Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: Use of femto scaling in IBIS models To: ibis@vhdl.org MIME-Version: 1.0 X-Mailer: Mozilla 3.0Gold (WinNT; I) Organization: Quantic Laboratories Inc Reply-To: ventham@quantic.mb.ca From: Mike Ventham Date: Fri, 22 Nov 1996 16:10:15 +0000 Message-ID: <3295D067.5EDE@quantic.mb.ca> Received: from henty by maelstrom.dial.pipex.net (8.8.2/) id QAA07402; Fri, 22 Nov 1996 16:13:36 GMT Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET PIPEX simple 1.28) id QAA21850; Fri, 22 Nov 1996 16:13:04 GMT Received: from typhoon.dial.pipex.net by maelstrom.dial.pipex.net (8.8.2/) id QAA07928; Fri, 22 Nov 1996 16:14:32 GMT Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET PIPEX simple 1.28) id QAA22072; Fri, 22 Nov 1996 16:17:56 GMT Received: from typhoon.dial.pipex.net (typhoon.dial.pipex.net [158.43.128.46]) b y vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA15019 for ; Fri, 2 2 Nov 1996 12:14:49 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel. c om (8.8.3/8.7.3) with ESMTP id MAA01881; Fri, 22 Nov 1996 12:09:19 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id MAA00672; Fri, 22 Nov 1996 12: 06:45 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Use of femto scaling in IBIS models To: ibis@vhdl.org Message-ID: From: Arpad Muranyi Date: Tue, 26 Nov 96 12:29:00 PST Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 26 Nov 96 19:31:02 PST Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id TAA26 779 for ibis@vhdl.org; Tue, 26 Nov 1996 19:31:02 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 2 7 Nov 1996 03:33:13 GMT Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vh dl.vhdl.org (8.7.3/8.7.3) with ESMTP id TAA14709 for ; Tue, 26 No v 1996 19:44:17 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.8.3/8.7.3) with ESMTP id TAA14747; Tue, 26 Nov 1996 19:35:47 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.8.2/8.7.3) with ESMTP id TAA04657; Tue, 26 Nov 1996 19:35:47 -0800 ( PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Nov 27 09:56:43 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id JAA09078 for ; Wed, 27 Nov 1996 09:56:43 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 27 Nov 1996 17:43:03 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id JAA00412; Wed, 27 Nov 1996 09:40:48 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 27 Nov 96 09:40:47 PST Date: Wed, 27 Nov 96 08:48:00 PST From: Arpad Muranyi Message-ID: cc: ibis@vhdl.org, ingraham@wrksys.enet.dec.com Subject: Re[2]: Use of femto scaling in IBIS models Text item: Andy, This is exactly what we were debating in those conversations I was referring to. Unfortunately, I don't remember for sure what the decision was, but it seems to me that we said that it was the parser that was valid. Could someone with sharper memory comment on this? Regarding the prefixes, I would vote for making all of them valid. Here is the table from the Electronics Engineer's Handbook by Donald Christiansen, 4th edition, 1996, page 8.20. (I am not showing the ones they do not recommend to be used). This is from ANSI/IEEE Standard 268-1992 according to the footnote. Factor Prefix Symbol 10+24 yotta Y 10+21 zetta Z 10+18 exa E 10+15 peta P 10+12 tera T 10+9 giga G 10+6 mega M 10+3 kilo k 10-3 milli m 10-6 micro u (using the Greek symbol mu) 10-9 nano n 10-12 pico p 10-15 femto f 10-18 atto a 10-21 zepto z 10-24 yocto y Unrelated to IBIS matters in general, I also want to mention here (to let my frustration out) that using the proper cases for units and prefixes are important. I see many articles, books in print (including some of the other chapters of the above mentioned handbook) and software where the authors are negligent to follow the rules of proper letter casing leading to confusion and ridiculous or physically impossible units. Lots of examples could be brought up, but some of the most frequent ones I see are: correct unit incorrect spelling and its meaning and its abbreviation second, s "S" conductance, siemens nanosecond, ns "nS" conductance, nanosiemens kilo, k "K" temperature, kelvin kilowatt, kW "KW" (?) kelvinwatt milli, m "M" prefix, mega Mega, M "m" prefix, milli megahertz, MHz "mHz" or Mhz" millihertz or mega-hecto-zepto (?) megabit, Mb "mB" or "mb" etc. millibyte or millibit etc. megabyte MB "Mb" or "mB" etc. megabit or millibyte etc. decibel dB "db" decibit And so on. I wish engineers would take more pride in precision when it comes to spelling in writing. Arpad ===================================================================== I don't question what may have have been previously discussed ... but in my mind the only correct answer is that the spec ALWAYS takes precedence, no matter what you're talking about. If the spec and the parser disagree, you fix the parser. If you want the parser to have precedence, then make IT the standard with its source code freely available to the world, and make a note in the spec that it is only an example and to refer to the parser. I brought this issue up some two years ago with one or more of you. Will "a" come to mean "alto" (1e-18) some time in the future? (It already does on at least one simulator.) You need to get this nailed down firmly. Otherwise you don't have a spec. Regards, Andy Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Use of femto scaling in IBIS models Apparently-To: ibis@vhdl.org, arpad_muranyi@ccm.fm.intel.com Cc: ibis@vhdl.org, ingraham@wrksys.ENET.dec.com To: arpad_muranyi@ccm.fm.intel.com From: Andy Ingraham Date: Wed, 27 Nov 96 08:52:14 EST Received: from wrksys.enet; by us1rmc.enet; Wed, 27 Nov 96 08:52:14 EST Message-Id: <9611271333.AA07842@us1rmc.bb.dec.com> Received: from wrksys.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA07842; Wed, 27 Nov 96 08:33:40 -0500 Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA21445; Wed, 27 Nov 1996 08:50:11 -0500 (EST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by vhdl.v hdl.org (8.7.3/8.7.3) with ESMTP id GAA07144 for ; Wed, 27 Nov 19 96 06:11:03 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.3/8.7.3) with ESMTP id GAA04702; Wed, 27 Nov 1996 06:10:50 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id GAA18028; Wed, 27 Nov 1996 06: 08:16 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Nov 27 10:06:12 1996 Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA09227 for ; Wed, 27 Nov 1996 10:06:11 -0800 (PST) Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 27 Nov 1996 17:55:06 GMT Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id JAA01673; Wed, 27 Nov 1996 09:52:54 -0800 (PST) Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Wed, 27 Nov 96 09:52:53 PST Date: Wed, 27 Nov 96 09:05:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org, crokusek@qdt.com Subject: Re[2]: 1.x vs 2.x Text item: IBIS gurues, I would expect the 2.1 parser to check a 1.1 file according to 1.1 rules, and a 2.1 file according to 2.1 rules. That means, if femto is not legal in 1.1, it should flag it as an error. If I understand Syed's words correctly (below), the 2.1 parser will not flag the femto in 1.1 files because it is allowed in 2.1. I think this is not right. By the way, tabs are allowed in both versions of IBIS. We only added a statement that we strongly discourage its use in 2.1. So the parser should not flag it as an error, only as a warning (maybe). Arpad ================================================================================ Chris, One example: IBISv1.1 parser allows tab characters in the model file. IBISv2.1 does not allow that and the parser gives a Warning. So, if a model file is v1.1, things like checks for tabs are ignored by the parsar. Regards, Syed. > > Hi All, > > The current ibischk2 has a switch inside that upon reading a 1.x ibis > file checks if differently (using the older checks) than a 2.x file. > > If we are truly backward compatible (are we?) then shouldn't we parse > and test all .ibs files for the current revision (now 2.1) regardless of > the file's ibis version. > > Q: Should a 2.x parser be able to read 1.x or not? > > Thanks, > > -Chris Rokusek > Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: 1.x vs 2.x To: ibis@vhdl.org, crokusek@qdt.com Message-Id: <9611270125.AA07408@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Tue, 26 Nov 96 17:25:52 PST Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA07408; Tue, 26 Nov 96 17:25:52 PST Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA07544 for ibis@vhdl.org; Tue, 26 Nov 96 17:24:25 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma002789; Tue Nov 26 17:24:41 1996 Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id RAA0284 2; Tue, 26 Nov 1996 17:24:46 -0800 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl. vhdl.org (8.7.3/8.7.3) with SMTP id RAA13851 for ; Tue, 26 Nov 19 96 17:35:47 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c om (8.8.3/8.7.3) with ESMTP id RAA16389; Tue, 26 Nov 1996 17:29:43 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id RAA19097; Tue, 26 Nov 1996 17: 27:10 -0800 (PST) Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Nov 27 11:28:42 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA09856; Wed, 27 Nov 1996 11:28:40 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 27 Nov 96 11:14 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 27 Nov 96 11:14 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 27 Nov 96 11:16 PST Message-Id: Date: Wed, 27 Nov 96 11:16 PST From: bob@icx.com ( Bob Ross) To: Will_Hobbs@ccm.jf.intel.com, ibis@vhdl.org, owner-ibis@vhdl.org Subject: Re: Re[2]: Use of femto scaling in IBIS models To all: Version 1.1 of IBIS allowed only these scale factors: M, k, m, u, n, and p Version 2.0 added to the list: T, G, and f. Every other letter and case is permitted. So ibis_chk for Version 1.1 and ibischk2 for Version 2.1 will not give any error for any character (lower or upper case) appended to any number. Thus we can add V or v, A or a, S or s, etc. Therefore Version 1.1 files with these factors should either be designated Version 2.1 (even if they contain only the Version 1.1 subset) or else a Version 1.1 compliant set of multipliers (e.g. 0.1p, 1e-10, etc. for 100f.) This will avoid the situation that different simulators will give different results for the same data that is itself not technically what was intended. Best Regards, Bob Ross Interconnectix > Date: Wed, 27 Nov 96 09:03:00 PST > From: Will Hobbs > Message-ID: > To: owner-ibis@vhdl.org, ibis@vhdl.org > Subject: Re[2]: Use of femto scaling in IBIS models > Status: R > Text item: > Arpad, et al, > I know that early on we talked of the parser as the "executable spec," but since > we have gone through formal balloting, etc., of IBIS as an ANSI EIA > specification, the written spec is the spec. Period. The parser should be as > faithful to that spec as possible. If "f" has to be added to the spec, then so > be it. That should be a 3.0 issue, and a Bird generated and voted on. > Will > Mike, > Thanks for the information. This issue is clearly an oversight on my part. > When I wrote our tool that automates the process of generating IBIS models, I > didn't check what the valid prefixes are in IBIS, so I coded my program to use > all known prefixes available in the engineering world. Since then, I have a > newer revision of the tool which uses engineering notation in the > tables (only). > Due to time limitations, I cannot commit to fix all the earlier models. > One way > of getting around the fA problem is to edit the file to be version > 2.1, since it > is legal in that spec. > However, I question whether this is a spec or parser issue. I parsed the 1.1 > IBIS file in question with both parsers just now, and neither one of them gave > me an error. If this is illegal in 1.1, both parsers should have given me an > error. This is why these prefixes slipped in to start out with... > At one time we were debating whether in cases like this, when the > parser didn't > agree with the spec, which one should take precedence. If I remember > correctly > we voted for the parser. In this light, the Intel models are not illegal. > (Someone correct me if I am wrong). > So the question is, should we fix the parser, or change the spec to allow for > all prefixes. In my opinion it doesn't make sense to have to say > 0.01 pA for 10 > fA and so on. Even though these kind of numbers are usually noise and outside > the usually measurable range, I would still allow them for the sake of > consistency and completeness. You never know, someone might even need them in > some cases... (especially with capacitances). > Arpad > =============================================================================== > = > Ibisians, > I have recently found a problem in the parser which affects both > versions of the parser when parsing version 1.x IBIS models which > contain values scaled using the femto(f) prefix. > As far as I know this only affects Intel models as everyone else > uses unscaled number in engineering/scientific format. > According to the IBIS 1.1 spec, the prefix f is not > a legal prefix, pico is the smallest allowed. As the Intel model is > set as version 1.1 it is not a valid IBIS model. > Also the IBIS2.1 parser does not pick it up as it uses the IBIS v1.1 > parser checker. > Illegal scale characters in the IBIS file are set to ' ' i.e. scale=1.0 > without any error message. > I fiexed it by adding the character f to the known_scales array > i.e Mkmunp -> Mkmunpf > If the IBIS version in the file is set to 2.1 it will work OK > as f is recognised. > This should only affect simulated models, as measured models are > somewhat difficult to measure to that degree of accuracy. > I did once see currents of magnitude e+41 in an Intel model which I > presumed was simulated otherwise most of California would have been > blacked out! > Here is a supplementary question. Why is not having the same file > name as that in the file classified as an error rather than a warning? > Even if the file has the right name and you access it through a full > path name you get the error. > Regards > Mike > -- > ********PLEASE NOTE NEW ADDRESS AND FAX NUMBER ***************** > | Mike Ventham - Vice-President Engineering, | > | Quantic Laboratories Inc Headquarters | > | Croft House, Chilcompton, 191 Lombard Ave, Winnipeg, | > | Somerset, UK, BA3 4JA Manitoba, Canada R3B 0X1 | > | Tel: 44 (0)1761 232191 Tel: (204) 942 4000 | > | Fax: 44(0)1761 233549 Fax: (204) 957 1158 | > | Email: ventham@quantic.mb.ca | > Text item: External Message Header > The following mail header is for administrative use > and may be ignored unless there are problems. > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=us-ascii > Subject: Use of femto scaling in IBIS models > To: ibis@vhdl.org > MIME-Version: 1.0 > X-Mailer: Mozilla 3.0Gold (WinNT; I) > Organization: Quantic Laboratories Inc > Reply-To: ventham@quantic.mb.ca > From: Mike Ventham > Date: Fri, 22 Nov 1996 16:10:15 +0000 > Message-ID: <3295D067.5EDE@quantic.mb.ca> > Received: from henty by maelstrom.dial.pipex.net (8.8.2/) > id QAA07402; Fri, 22 Nov 1996 16:13:36 GMT > Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET > PIPEX simple 1.28) > id QAA21850; Fri, 22 Nov 1996 16:13:04 GMT > Received: from typhoon.dial.pipex.net by maelstrom.dial.pipex.net (8.8.2/) > id QAA07928; Fri, 22 Nov 1996 16:14:32 GMT > Received: from maelstrom.dial.pipex.net by typhoon.dial.pipex.net (8.8.2/UUNET > PIPEX simple 1.28) > id QAA22072; Fri, 22 Nov 1996 16:17:56 GMT > Received: from typhoon.dial.pipex.net (typhoon.dial.pipex.net [158.43.128.46]) > b > y vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA15019 for ; > Fri, 2 > 2 Nov 1996 12:14:49 -0800 (PST) > Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel. > c > om (8.8.3/8.7.3) with ESMTP id MAA01881; Fri, 22 Nov 1996 12:09:19 -0800 (PST) > Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) > by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id MAA00672; Fri, 22 > Nov 1996 12: > 06:45 -0800 (PST) > Return-Path: owner-ibis@vhdl.vhdl.org > Text item: External Message Header > The following mail header is for administrative use > and may be ignored unless there are problems. > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > Subject: Re: Use of femto scaling in IBIS models > To: ibis@vhdl.org > Message-ID: > From: Arpad Muranyi > Date: Tue, 26 Nov 96 12:29:00 PST > Received: by ccm.fm.intel.com (ccmgate 3.2 #2) Tue, 26 Nov 96 19:31:02 PST > Received: (from ccmgate@localhost) by fmmail.fm.intel.com (8.7.4/8.7.3) id TAA26 > 779 for ibis@vhdl.org; Tue, 26 Nov 1996 19:31:02 -0800 (PST) > Received: from fmmail.fm.intel.com by marceau.fm.intel.com (8.7.6/10.0i); Wed, 2 > 7 Nov 1996 03:33:13 GMT > Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by vh > dl.vhdl.org (8.7.3/8.7.3) with ESMTP id TAA14709 for ; Tue, 26 No > v 1996 19:44:17 -0800 (PST) > Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( > 8.8.3/8.7.3) with ESMTP id TAA14747; Tue, 26 Nov 1996 19:35:47 -0800 (PST) > Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i > ntel.com (8.8.2/8.7.3) with ESMTP id TAA04657; Tue, 26 Nov 1996 19:35:47 -0800 ( > PST) > Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Wed Nov 27 14:56:32 1996 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id OAA11434 for ; Wed, 27 Nov 1996 14:56:30 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 27 Nov 96 14:44 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 27 Nov 96 14:44 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 27 Nov 96 14:46 PST Message-Id: Date: Wed, 27 Nov 96 14:46 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS BIRD40 OVERSHOOT NOMENCLATURE To IBIS Committee: BIRD40 is a subparameter nomenclature change requested by the RAIL committee to the approved BIRD39 to deal with possible nomenclature confusion. The only modification is to change "Overshoot_high" to "S_overshoot_high", and "Overshoot_low" to "S_overshoot_low" for static overshoot. Bob Ross Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 40 ISSUE TITLE: OVERSHOOT NOMENCLATURE REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 11/27/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Overshoot in approved BIRD39 of IBIS uses Overshoot_high and Overshoot_low for static overshoots. The same notation is used in RAIL for any overshoot rule including maximum overshoot. To avoid confusion, the proposal here is to change the nomenclature to emphasize "static" overshoot. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The [Model Spec] subparameter nomenclature is changed as shown: BIRD39 BIRD40 Overshoot_high S_overshoot_high Overshoot_low S_overshoot_low The whole [Model Spec] keyword is presented here with changes to show the context of the revision. (Changes are noted by "|*" lines.) |============================================================================== | Keywords: [Model Spec] | Required: No |* Sub-params: Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high, |* S_overshoot_low, D_overshoot_high, D_overshoot_low, | D_overshoot_time, Pulse_high, Pulse_low, Pulse_time | |Description: The [Model Spec] keyword defines four columns under which | specification subparameters are defined. | | The following subparamters are defined: | Vinh Input voltage threshold high | Vinl Input voltage threshold low | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- |* S_overshoot_high Static overshoot high voltage |* S_overshoot_low Static overshoot low voltage | D_overshoot_high Dynamic overshoot high voltage | D_overshoot_low Dynamic overshoot low voltage | D_overshoot_time Dynamic overshoot time | Pulse_high Pulse immunity high voltage | Pulse_low Pulse immunity low voltage | Pulse_time Pulse immunity time | | Usage Rules: [Model Spec] must follow all other subparameters under the | [Model] keyword. | | For each subparameter contained in the first column, the | remaining three hold its typical, minimum and maximum values. | The entries of typical, minimum and maximum be must be placed | on a single line and must be separated by at least one white | space or tab or tab character. All four columns are required | under the [Model Spec] keyword. However, data is required | only in the typical column. If minimum and/or maximum values | are not available, the reserved word "NA" must be used | indicating the typical value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage range settings. | | Unless noted below, each subparameter does not require having | any other subparameter. | | Vinh, Vinl rules: | The threshold subparameter lines | provide additional min and max column values, if needed. | The typ column values are still required and would be | expected to override the Vinh and Vinl subparameter values | specified elsewhere. Note: the syntax rule that require | inserting Vinh and Vinl under models remains unchanged | even if the values are defined under the [Model Spec] | keyword. | | To mimic a hysteresis effect, the values of Vinh and Vinl may | interchanged such that the Vinl value is larger than the Vinh | value. However, simulators may process this information | differently or report an error. | | Vinh+, Vinh-, Vinl+, Vinl- rules: | The four hysteresis subparmeters must all be defined before | the hysteresis threshold rules become effective. Otherwise | the standard threshold subparameters remain in effect. The | hysteresis thresholds shall be at the Vinh+ and Vinh- values | for a low-to-high transition, and at the Vinl+ and Vinl- | values for a high-to-low transition. | |* S_overshoot_high, S_overshoot_low rules: | The static overshoot sub-parameters provide the voltage values | for which the component is no longer guaranteed to function | correctly. | | D_overshoot_high, D_overshoot_low, D_overshoot_time rules: | The dynamic overshoot values provide a time window during | which the the overshoot may exceed the static overshoot limits | but be below the dynamic overshoot limits. D_overshoot_time is | required for dynamic overshoot testing. In addition, if |* D_overshoot_high is specified, then S_overshoot_high is | necessary for testing beyond the static limit. Similarly, if |* D_overshoot_low is specified, then S_overshoot_low is necessary | for testing beyond the static limit. | | Pulse_high, Pulse_low, Pulse_time rules: | The pulse immunity values provide a time window during which | a rising pulse may exceed the nearest threshold value but | be below the pulse voltage value and still not cause the | input to switch. Pulse_time is required for pulse immunity | testing. A rising response is tested only if Pulse_high is | specified. Similarly, a falling response is tested only if | Pulse_low is specified. The rising response may exceed the | Vinl value, but remain below the Pulse_high value. Similarily, | the falling response drop below the Vinh value, but remain | above the Pulse_low value. In either case the input is | regarded as immune to switching if the the responses are | within these extended windows. If the hysteresis thresholds | are defined, then the rising response shall use Vinh- as the | reference voltage, and the falling response shall use Vinl+ | as the reference voltage. | |------------------------------------------------------------------------------ [Model Spec] | Subparameter typ min max | | Thresholds | Vinh 3.5 3.15 3.85 | 70% of Vcc Vinl 1.5 1.35 1.65 | 30% of Vcc | | Vinh 3.835 3.335 4.335 | Offset from Vcc | Vinl 3.525 3.025 4.025 | for PECL | | Hysteresis | Vinh+ 2.0 NA NA | Overrides the Vinh- 1.6 NA NA | thresholds Vinl+ 1.1 NA NA Vinl- 0.6 NA NA | All 4 are required | | Overshoot | |* Next two lines are changed S_overshoot_high 5.5 5.0 6.0 | Static overshoot S_overshoot_low -0.5 NA NA D_overshoot_high 6.0 5.5 6.5 | Dynamic overshoot D_overshoot_low -1.0 -1.0 -1.0 | requires | D_overshoot_time D_overshoot_time 20n 20n 20n | & static overshoot | | Pulse Immunity | Pulse_high 3V NA NA | Pulse immunity Pulse_low 0 NA NA | requires Pulse_time 3n NA NA | Pulse_time | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Static overshoot defined as "S_overshoot_high" and "S_overshoot_low" is chosen as the best subparameter name change because it is defined as "static" overshoot in a manner parallel to "dynamic" overshoot for "D_overshoot_high" and "D_overshoot_low". It makes sense to let RAIL use the more generic "Overshoot_high" and "Overshoot_low" for absolute maximum or else for any rule setting that may be unrelated to device characteristics. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: BIRD40 replaces the approved BIRD39 text. Refer to BIRD39 for [Model Spec] Analysis. ****************************************************************************** From owner-ibis Fri Nov 29 15:03:42 1996 Received: from mixer.visi.com (root@mixer.visi.com [204.73.178.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA20535 for ; Fri, 29 Nov 1996 15:03:41 -0800 (PST) From: bobw@visi.com Received: from 192-22.dynamic.visi.com (192-22.dynamic.visi.com [206.11.192.22]) by mixer.visi.com (8.8.3/8.7.5) with SMTP id QAA23367 for ; Fri, 29 Nov 1996 16:52:33 -0600 (CST) Posted-Date: Fri, 29 Nov 1996 16:52:33 -0600 (CST) To: ibis@vhdl.org Subject: RE: 1.x or 2.x Date: Fri, 29 Nov 96 23:01:36 GMT Message-ID: X-Mailer: Quarterdeck Message Center [1.0] All- I remember fondly some of these same discussions when we tried to establish the desired behaviour for ibischk in light of revision 2.x of the spec. We finally came down to the notion that ibischk is more than merely a parser for ibis models. It is a tool to check for adherence to the spec. So if we are building, or attempting to build, verion 1.x compliant models we definitely want the checking tool to test against the syntax and behaviour intended by the version 1.x spec. Period. And absolutely and fully. Similarly if we are testing a model intended to be version 2.x compliant we certainly want all the things both demanded and allowed by the new spec to be demanded or allowed by the tool. Thus the switch and the dual personality of the ibischk tool. It is more than a parser. Now if you start discussing how a parser to be embedded in a simulator should behave, it should be no more demanding than the rest of the simulator insists on. In fact it should be as forgiving as the rest of the simulator code will allow. Thus, for example the Interconnectix version allows some thongs beyond the strict spec, as I remember. ( Bob Ross, please correct me quick if I lied here! :-) ) Just to use it as a specific example. Still if the ibischk tool does not meet the expectations or intentions of the spec, it should change. We intended to free up a lot on the metric suffixes allowed, but we still had a defined set. I suggest that that full set, but no other should be allowed by ibischk, and leave the possibility of more freedom yet to individual parsers attached to tools. Just the $0.02 worth of one who was part of that spec. :-) Thanks, Bob Ward